A couple of weeks ago, Finland took the penultimate step to get rid of DVB-T. Since years, we had DVB-T and DVB-T2 running in parallel. The DVB-T transponders should be shut down in 2025.
The step was to introduce a second free-to-air DVB-T2 bouquet to carry some channels that were previously only available with DVB-T and MPEG-2. The VDR channel search failed to find this transponder; I ran a patched version of https://github.com/mighty-p/t2scan/pull/15/ to generate a new channels.conf. (Is this a bug of VDR, or a feature? I remember that when I originally set up VDR, I had to get a channels.conf from tscan or t2scan.)
Unlike our first free-to-air DVB-T2 bouquet, which uses MPEG-4 H.264 video with AC3 audio, the second one uses H.264 video and HE-AAC audio, also known as LATM or LOAS. This had to be explicitly enabled for my output device: https://github.com/reufer/rpihddevice/issues/20
The HE-AAC support in rpihddevice is experimental, maybe because the sampling rate is hard-coded as 48 kHz and the number of channels as 2. Unlike AC3, it does not look like these parameters would be available in any audio frame header. As far I understood from a NorDig.org specification, the sampling rate would always be 48 kHz, but the number of channels could be identified by something in the container, specifically, Table 12.28 and Table 12.29 at page 164 of https://nordig.org/wp-content/uploads/2016/03/NorDig-Unified-Requirements-ve...
What would have to be changed in VDR or rpihddevice or both to correctly switch between 2-channel and 5.1-channel HE-AAC audio? This is mostly an academic question and exercise, because I only have stereo audio hardware and don't know if any programming is actually available with multichannel audio.
Best regards,
Marko
Am 06.12.24 um 21:32 schrieb Marko Mäkelä:
A couple of weeks ago, Finland took the penultimate step to get rid of DVB-T. Since years, we had DVB-T and DVB-T2 running in parallel. The DVB-T transponders should be shut down in 2025.
same here but h.265 video and aac audio.
The step was to introduce a second free-to-air DVB-T2 bouquet to carry some channels that were previously only available with DVB-T and MPEG-2. The VDR channel search failed to find this transponder; I ran a patched version of https://github.com/mighty-p/t2scan/pull/15/ to generate a new channels.conf. (Is this a bug of VDR, or a feature? I remember that when I originally set up VDR, I had to get a channels.conf from tscan or t2scan.)
have You tried the latest git version of scan in dvb-utils @linuxtx.org repo?
Unlike our first free-to-air DVB-T2 bouquet, which uses MPEG-4 H.264 video with AC3 audio, the second one uses H.264 video and HE-AAC audio, also known as LATM or LOAS. This had to be explicitly enabled for my output device: https://github.com/reufer/rpihddevice/issues/20
The HE-AAC support in rpihddevice is experimental,
as it has been in ffmpeg until today and rpihddevive is based on it?
maybe because the sampling rate is hard-coded as 48 kHz and the number of channels as 2. Unlike AC3, it does not look like these parameters would be available in any audio frame header. As far I understood from a NorDig.org specification, the sampling rate would always be 48 kHz, but the number of channels could be identified by something in the container, specifically, Table 12.28 and Table 12.29 at page 164 of https://nordig.org/wp-content/uploads/2016/03/NorDig-Unified- Requirements-ver.-3.2.1.pdf
Have You tried the latest git ffprobe version, does it detect the aac flavor of Your dvb-t2 DVB channels correctly?
Have You tried latest git mediainfo?
What would have to be changed in VDR or rpihddevice or both to correctly switch between 2-channel and 5.1-channel HE-AAC audio? This is mostly an academic question and exercise, because I only have stereo audio hardware and don't know if any programming is actually available with multichannel audio.
Not at all academic. Since AVRs do not implement Fraunhofer codecs we need a HDNI PCM Multichannel driver for the raspberry pi to playback 5.1 channel aac without transcoding it to ac3 which can be done with mplayer on the fly.
I've made a HDMI PCM Multichannel output to AVR driver patch for the Allwinner SoC alsa audio driver, look for it on the alsa-dev list archives.
Best regards,
Marko
y tom
Fri, Dec 06, 2024 at 10:31:06PM +0100, schorpp wrote:
Am 06.12.24 um 21:32 schrieb Marko Mäkelä:
A couple of weeks ago, Finland took the penultimate step to get rid of DVB-T. Since years, we had DVB-T and DVB-T2 running in parallel. The DVB-T transponders should be shut down in 2025.
same here but h.265 video and aac audio.
Right, it's H.265 video in Germany. I found somewhere a reference to something that would transcode H.265 into H.264 on the fly on a Raspberry Pi 3, so that the Videocore GPU could play it in real time.
The VDR channel search failed to find this transponder; I ran a patched version of https://github.com/mighty-p/t2scan/pull/15/ to generate a new channels.conf. (Is this a bug of VDR, or a feature? I remember that when I originally set up VDR, I had to get a channels.conf from tscan or t2scan.)
have You tried the latest git version of scan in dvb-utils @linuxtx.org repo?
At https://git.linuxtv.org/v4l-utils.git I found a reference to the command dvbv5-scan. An "apt search dvbv5-scan" on my Debian Sid as well as on Raspbian 12.8 yielded two packages: dvb-tools and w-scan-cpp. I vaguely remember that I had used the latter one a few years ago. I just invoked the following on the Raspberry Pi:
w_scan_cpp -c FI
The output during scanning looks convincing, but the program seems to get stuck waiting for something at the end, for several minutes.
I also tried to invoke dvbv5-scan from dvb-tools, but it seems to require a file that contains some initial parameters.
Anyway, I was mainly wondering if it is normal that the EPG update in VDR did not find the new transponder. I guess it is; the search space would be huge if it had to cover satellite, cable, terrestrial and some IPTV sources as well.
The HE-AAC support in rpihddevice is experimental,
as it has been in ffmpeg until today and rpihddevive is based on it?
As in:
#ifdef ENABLE_AAC_LATM #warning "experimental AAC-LATM frame parser enabled, only 2ch/48kHz supported!" #endif
Have You tried the latest git ffprobe version, does it detect the aac flavor of Your dvb-t2 DVB channels correctly?
I only have 2-channel recordings or DVB-T2 streams available to me. Those already play without any problems. But I don't have any recording with multichannel audio. I would like to implement correct detection and playback of multichannel HE-AAC audio, so that the AAC audio support could be enabled by default in rpihddevice.
Have You tried latest git mediainfo?
I was reading the libmediainfo source code a few days ago. I guess I should just have executed mediainfo on an MPEG-4 TS file inside a debugger, to find out how and where exactly it detects the audio parameters.
Not at all academic. Since AVRs do not implement Fraunhofer codecs we need a HDNI PCM Multichannel driver for the raspberry pi to playback 5.1 channel aac without transcoding it to ac3 which can be done with mplayer on the fly.
Right, also according to the NorDig specification, some transcoding of audio is mandatory for some audio output options.
I've made a HDMI PCM Multichannel output to AVR driver patch for the Allwinner SoC alsa audio driver, look for it on the alsa-dev list archives.
Sorry, I could not find it. I figured out that AVR here must refer to Audio Video Receiver. The only HDMI output devices that I have are displays with 2 built-in speakers. I believe that I am currently using 2-channel PCM audio output.
Are there any sample MPEG TS recordings with 5.1 channel AAC audio? That would be very helpful. In a 2-channel setup, would it be customary to pass through only the first 2 channels and ignore the rest?
Marko
Am 09.12.24 um 18:23 schrieb Marko Mäkelä:
Fri, Dec 06, 2024 at 10:31:06PM +0100, schorpp wrote:
Am 06.12.24 um 21:32 schrieb Marko Mäkelä:
A couple of weeks ago, Finland took the penultimate step to get rid of DVB-T. Since years, we had DVB-T and DVB-T2 running in parallel. The DVB-T transponders should be shut down in 2025.
same here but h.265 video and aac audio.
Right, it's H.265 video in Germany. I found somewhere a reference to something that would transcode H.265 into H.264 on the fly on a Raspberry Pi 3, so that the Videocore GPU could play it in real time.
Get a 4B at no cost. h.265 h/w decoding supported (at least with libreelec).
The VDR channel search failed to find this transponder; I ran a patched version of https://github.com/mighty-p/t2scan/pull/15/ to generate a new channels.conf. (Is this a bug of VDR, or a feature? I remember that when I originally set up VDR, I had to get a channels.conf from tscan or t2scan.)
have You tried the latest git version of scan in dvb-utils @linuxtx.org repo?
At https://git.linuxtv.org/v4l-utils.git I found a reference to the command dvbv5-scan. An "apt search dvbv5-scan" on my Debian Sid as well as on Raspbian 12.8 yielded two packages: dvb-tools and w-scan-cpp. I vaguely remember that I had used the latter one a few years ago. I just invoked the following on the Raspberry Pi:
w_scan_cpp -c FI
The output during scanning looks convincing, but the program seems to get stuck waiting for something at the end, for several minutes.
I also tried to invoke dvbv5-scan from dvb-tools, but it seems to require a file that contains some initial parameters.
Anyway, I was mainly wondering if it is normal that the EPG update in VDR did not find the new transponder. I guess it is; the search space would be huge if it had to cover satellite, cable, terrestrial and some IPTV sources as well.
The HE-AAC support in rpihddevice is experimental,
as it has been in ffmpeg until today and rpihddevive is based on it?
As in:
#ifdef ENABLE_AAC_LATM #warning "experimental AAC-LATM frame parser enabled, only 2ch/48kHz supported!" #endif
Maybe subscribe and CC the ffmpeg-devel list, the alsa guys look too busy.
Have You tried the latest git ffprobe version, does it detect the aac flavor of Your dvb-t2 DVB channels correctly?
I only have 2-channel recordings or DVB-T2 streams available to me. Those already play without any problems. But I don't have any recording with multichannel audio. I would like to implement correct detection and playback of multichannel HE-AAC audio, so that the AAC audio support could be enabled by default in rpihddevice.
Have You tried latest git mediainfo?
I was reading the libmediainfo source code a few days ago. I guess I should just have executed mediainfo on an MPEG-4 TS file inside a debugger, to find out how and where exactly it detects the audio parameters.
Not at all academic. Since AVRs do not implement Fraunhofer codecs we need a HDNI PCM Multichannel driver for the raspberry pi to playback 5.1 channel aac without transcoding it to ac3 which can be done with mplayer on the fly.
Right, also according to the NorDig specification, some transcoding of audio is mandatory for some audio output options.
I've made a HDMI PCM Multichannel output to AVR driver patch for the Allwinner SoC alsa audio driver, look for it on the alsa-dev list archives.
Sorry, I could not find it.
I not too. strange, as i've reactivated my account some weeks before there it was there. Maybe some list admin removed it, I can remember license issues with Allwinner.
I've attached the patch for You here, it was easy to implement, but the driver frontend is incomplete but pulseaudio pavucontrol corrects it, I've provided a detailed setup description on alsa-devel mailinglist.
-Attachment 1: sunxi Allwinner HDMI driver Multichannel PCM patch-
I figured out that AVR here must refer to Audio Video Receiver. The only HDMI output devices that I have are displays with 2 built-in speakers. I believe that I am currently using 2-channel PCM audio output.
Get the cheapest DENON AVR for ~200 EUR! Surround Sound is great, without HDTV and bluray is nothing and many stereo sources are dolby pro logic 2 encoded allowing AVR DSPs decoding to 5.1 channel :)
Are there any sample MPEG TS recordings with 5.1 channel AAC audio?
Search Fraunhofer websites for reference samples.
I've a huge archive of dvd backups here, aac 5.1 sample is attached.
Imported with GPAC, if You like the ffmpeg encoders backup a DD/DTS5.1 audio dvd ;)
-Attachment 2: mp4 sample file-
But it's AAC LC if detected correctly:
schorpp@tom3:~$ ffprobe /mnt/data/filme/AAC51channel-sample.mp4 ffprobe version 4.4.5 Copyright (c) 2007-2024 the FFmpeg developers built with gcc 10 (Debian 10.2.1-6) configuration: --disable-decoder=amrnb --disable-decoder=libopenjpeg --disable-gnutls --disable-liblensfun --disable-libopencv --disable-podpages --disable-sndio --disable-stripping --enable-avfilter --enable-avresample --enable-chromaprint --enable-frei0r --enable-gcrypt --enable-gpl --enable-ladspa --enable-libaom --enable-libaribb24 --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libdavs2 --enable-libdc1394 --enable-libdrm --enable-libfdk-aac --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libiec61883 --enable-libjack --enable-libkvazaar --enable-libmp3lame --enable-libmysofa --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librabbitmq --enable-librist --enable-librsvg --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libsvtav1 --enable-libtesseract --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq --enable-libzvbi --enable-lv2 --enable-nonfree --enable-openal --enable-opencl --enable-opengl --enable-openssl --enable-postproc --enable-pthreads --enable-shared --enable-version3 --enable-vulkan --incdir=/usr/include/x86_64-linux-gnu --libdir=/usr/lib/x86_64-linux-gnu --prefix=/usr --toolchain=hardened --enable-vaapi --enable-libmfx --enable-libvmaf --enable-libilbc --disable-altivec --shlibdir=/usr/lib/x86_64-linux-gnu libavutil 56. 70.100 / 56. 70.100 libavcodec 58.134.100 / 58.134.100 libavformat 58. 76.100 / 58. 76.100 libavdevice 58. 13.100 / 58. 13.100 libavfilter 7.110.100 / 7.110.100 libavresample 4. 0. 0 / 4. 0. 0 libswscale 5. 9.100 / 5. 9.100 libswresample 3. 9.100 / 3. 9.100 libpostproc 55. 9.100 / 55. 9.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/mnt/data/filme/AAC51channel-sample.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf58.76.100 Duration: 00:01:00.01, start: 0.000000, bitrate: 408 kb/s Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, 5.1, fltp, 407 kb/s (default) Metadata: handler_name : SoundHandler vendor_id : [0][0][0][0] schorpp@tom3:~$
That would be very helpful. In a 2-channel setup, would it be customary to pass through only the first 2 channels and ignore the rest?
VLC is easiest to configure multichannel audio with 5.1 audio output devices and 5.1 to stereo downmix.
Marko
y tom
Tue, Dec 10, 2024 at 04:13:21AM +0100, schorpp wrote:
Get a 4B at no cost. h.265 h/w decoding supported (at least with libreelec).
Thanks, I already got a Pi 4, but luckily rpihddevice on the Raspberry Pi 2 or 3 is sufficient for my needs (the DVB-T2 here only uses H.264). My only "production" VDR setup is on the Pi 2; I have a spare setup with a Pi 3, but without an MPEG-2 decoding license that would be necessary for watching DVB-T recordings. I have been waiting if the requirement to buy a license key for the VideoCore 4 firmware would disappear in 2025, when the patents will have expired in all jurisdictions.
I've a huge archive of dvd backups here, aac 5.1 sample is attached.
Thank you. I renamed the file to 00001.ts within a directory name that VDR recognizes. As expected, there was no audio (or video) output whatsoever from VDR+rpihddevice. In Totem, the audio played fine via the built-in 2 speakers on my laptop.
I finally spent some time debugging mediainfo and ffprobe on the 5.1 channel audio sample that you provided. The mediainfo/libmediainfo code base is written in what I would call stereotypical "bloatware C++". Lots of objects (including wchar_t strings) are being created, copied, and destroyed, which makes it very hard to follow the data flow.
With "rr record ffprobe 00001.ts" and "rr replay", I got closer to determining where the audio format is actually being parsed. It took a few distinct data watchpoints ("watch -l") and "reverse-continue", because the metadata was being copied a few times:
Hardware watchpoint 5: -location ac->oc[1].ch_layout.nb_channels
Old value = 0x6 New value = 0x0 0x00007fe048c2bb30 in av_channel_layout_from_mask () from /lib/x86_64-linux-gnu/libavutil.so.59 (rr) bt #0 0x00007fe048c2bb30 in av_channel_layout_from_mask () from /lib/x86_64-linux-gnu/libavutil.so.59 #1 0x00007fe049e87c5e in ff_aac_output_configure (ac=ac@entry=0x55841cc02a00, layout_map=layout_map@entry=0x7fff1e8604e0, tags=<optimized out>, oc_type=oc_type@entry=OC_GLOBAL_HDR, get_new_frame=get_new_frame@entry=0x0) at src/libavcodec/aac/aacdec.c:508 #2 0x00007fe049f0b115 in decode_ga_specific_config (ac=ac@entry=0x55841cc02a00, avctx=avctx@entry=0x55841cbf2fc0, gb=gb@entry=0x7fff1e860850, get_bit_alignment=get_bit_alignment@entry=0x0, m4ac=m4ac@entry=0x55841cc081d8, channel_config=<optimized out>) at src/libavcodec/aac/aacdec.c:890 #3 0x00007fe049f0bce6 in decode_audio_specific_config_gb (ac=0x55841cc02a00, avctx=0x55841cbf2fc0, oc=0x55841cc081d8, gb=0x7fff1e860850, get_bit_alignment=0x0, sync_extension=0x1) at src/libavcodec/aac/aacdec.c:1040 #4 decode_audio_specific_config (ac=ac@entry=0x55841cc02a00, avctx=avctx@entry=0x55841cbf2fc0, oc=oc@entry=0x55841cc081d8, data=<optimized out>, bit_size=<optimized out>, sync_extension=0x1) at src/libavcodec/aac/aacdec.c:1095 #5 0x00007fe049e87ce1 in ff_aac_decode_init (avctx=0x55841cbf2fc0) at src/libavcodec/aac/aacdec.c:1189 #6 0x00007fe049feacc7 in avcodec_open2 (avctx=avctx@entry=0x55841cbf2fc0, codec=codec@entry=0x7fe04ae07ac0 <ff_aac_decoder>, options=options@entry=0x55841cbf7580) at src/libavcodec/avcodec.c:336 #7 0x00007fe04b49b982 in avformat_find_stream_info (ic=0x55841cbf21c0, options=0x55841cbf7580) at src/libavformat/demux.c:2603 #8 0x00005583e525791f in open_input_file (ifile=0x7fff1e860ef0, filename=0x55841cbeefb0 "00001.ts", print_filename=<optimized out>) at src/fftools/ffprobe.c:3901 #9 probe_file (wctx=0x55841cbef000, filename=0x55841cbeefb0 "00001.ts", print_filename=<optimized out>) at src/fftools/ffprobe.c:4011 #10 main (argc=<optimized out>, argv=<optimized out>) at src/fftools/ffprobe.c:4765
Because this watchpoint was hit in "reverse-continue" and not "continue", the "Old value" and "New value" are swapped (the number of channels was actually changed from 0 to 6 at that point). I didn't install libavutil-dbgsym, but it is clear from reading the ffmpeg source code that ff_aac_output_configure() and its callers are the more interesting part of the call stack.
Once I have fully understood the parsing logic in libavcodec, I will determine if I'll improve cRpiAudioDecoder::cParser::Parse() a little, or if I'd make it use more of libavcodec, which rpihddevice already depends on for the actual decoding.
Best regards,
Marko
Am 30.12.24 um 11:26 schrieb Marko Mäkelä:
Tue, Dec 10, 2024 at 04:13:21AM +0100, schorpp wrote:
Get a 4B at no cost. h.265 h/w decoding supported (at least with libreelec).
Thanks, I already got a Pi 4, but luckily rpihddevice on the Raspberry Pi 2 or 3 is sufficient for my needs (the DVB-T2 here only uses H.264). My only "production" VDR setup is on the Pi 2; I have a spare setup with a Pi 3, but without an MPEG-2 decoding license that would be necessary for watching DVB-T recordings. I have been waiting if the requirement to buy a license key for the VideoCore 4 firmware would disappear in 2025, when the patents will have expired in all jurisdictions.
What? Your PI3/2 software decoders are too slow for h.262 (MPEG2) but fast enough for h.264 needing ~ x4 cpu/fpu power?
I've a huge archive of dvd backups here, aac 5.1 sample is attached.
Thank you. I renamed the file to 00001.ts within a directory name that VDR recognizes. As expected, there was no audio (or video) output whatsoever from VDR+rpihddevice. In Totem, the audio played fine via the built-in 2 speakers on my laptop.
Same here with xineliboutput media player, no audio from AAC 5.1 MP4 files.
Latest yt-dlp extracted AAC 2.0 and LATM dvb-c radio broadcasters play fine.
Lyngsat claims HE-AAC, femon plugin says LATM.
https://www.lyngsat.com/muxes/Astra-1M_Europe_10891-H.html
I finally spent some time debugging mediainfo and ffprobe on the 5.1 channel audio sample that you provided. The mediainfo/libmediainfo code base is written in what I would call stereotypical "bloatware C++". Lots of objects (including wchar_t strings) are being created, copied, and destroyed, which makes it very hard to follow the data flow.
Try an UML Modeling C++ reverse engineering app like e.g. Rational Rose or Umbrella (Linux) successors.
With "rr record ffprobe 00001.ts" and "rr replay", I got closer to determining where the audio format is actually being parsed. It took a few distinct data watchpoints ("watch -l") and "reverse-continue", because the metadata was being copied a few times:
Hardware watchpoint 5: -location ac->oc[1].ch_layout.nb_channels
Old value = 0x6 New value = 0x0 0x00007fe048c2bb30 in av_channel_layout_from_mask () from /lib/x86_64- linux-gnu/libavutil.so.59 (rr) bt #0 0x00007fe048c2bb30 in av_channel_layout_from_mask () from /lib/ x86_64-linux-gnu/libavutil.so.59 #1 0x00007fe049e87c5e in ff_aac_output_configure (ac=ac@entry=0x55841cc02a00, layout_map=layout_map@entry=0x7fff1e8604e0, tags=<optimized out>, oc_type=oc_type@entry=OC_GLOBAL_HDR, get_new_frame=get_new_frame@entry=0x0) at src/libavcodec/aac/aacdec.c:508 #2 0x00007fe049f0b115 in decode_ga_specific_config (ac=ac@entry=0x55841cc02a00, avctx=avctx@entry=0x55841cbf2fc0, gb=gb@entry=0x7fff1e860850, get_bit_alignment=get_bit_alignment@entry=0x0, m4ac=m4ac@entry=0x55841cc081d8, channel_config=<optimized out>) at src/ libavcodec/aac/aacdec.c:890 #3 0x00007fe049f0bce6 in decode_audio_specific_config_gb (ac=0x55841cc02a00, avctx=0x55841cbf2fc0, oc=0x55841cc081d8, gb=0x7fff1e860850, get_bit_alignment=0x0, sync_extension=0x1) at src/libavcodec/aac/aacdec.c:1040 #4 decode_audio_specific_config (ac=ac@entry=0x55841cc02a00, avctx=avctx@entry=0x55841cbf2fc0, oc=oc@entry=0x55841cc081d8, data=<optimized out>, bit_size=<optimized out>, sync_extension=0x1) at src/libavcodec/aac/aacdec.c:1095 #5 0x00007fe049e87ce1 in ff_aac_decode_init (avctx=0x55841cbf2fc0) at src/libavcodec/aac/aacdec.c:1189 #6 0x00007fe049feacc7 in avcodec_open2 (avctx=avctx@entry=0x55841cbf2fc0, codec=codec@entry=0x7fe04ae07ac0 <ff_aac_decoder>, options=options@entry=0x55841cbf7580) at src/ libavcodec/avcodec.c:336 #7 0x00007fe04b49b982 in avformat_find_stream_info (ic=0x55841cbf21c0, options=0x55841cbf7580) at src/libavformat/demux.c:2603 #8 0x00005583e525791f in open_input_file (ifile=0x7fff1e860ef0, filename=0x55841cbeefb0 "00001.ts", print_filename=<optimized out>) at src/fftools/ffprobe.c:3901 #9 probe_file (wctx=0x55841cbef000, filename=0x55841cbeefb0 "00001.ts", print_filename=<optimized out>) at src/fftools/ffprobe.c:4011 #10 main (argc=<optimized out>, argv=<optimized out>) at src/fftools/ ffprobe.c:4765
Because this watchpoint was hit in "reverse-continue" and not "continue", the "Old value" and "New value" are swapped (the number of channels was actually changed from 0 to 6 at that point). I didn't install libavutil-dbgsym, but it is clear from reading the ffmpeg source code that ff_aac_output_configure() and its callers are the more interesting part of the call stack.
Once I have fully understood the parsing logic in libavcodec, I will determine if I'll improve cRpiAudioDecoder::cParser::Parse() a little, or if I'd make it use more of libavcodec, which rpihddevice already depends on for the actual decoding.
Cool. The FFMPEG guys will surely appreciate it.
But there're still PCM Multichannel HDMI drivers missing for many devices.
Best regards,
Marko
y tom
Mon, Dec 30, 2024 at 12:21:18PM +0100, schorpp wrote:
What? Your PI3/2 software decoders are too slow for h.262 (MPEG2) but fast enough for h.264 needing ~ x4 cpu/fpu power?
The CPU cores in the Pi 2 and possibly also in the Pi 3 are too slow for decoding any video in real time.
Raspberry OS includes closed source Videocore IV GPU firmware that implements H.262 and H.264 decoding. That's what the rpihddevice plugin is using for decoding video. Audio is being decoded by FFMPEG. The H.262 decoder requires a license key to be purchased, while the H.264 decoder does not.
Try an UML Modeling C++ reverse engineering app like e.g. Rational Rose or Umbrella (Linux) successors.
No thanks, I am not a fan of any GUI software.
Once I have fully understood the parsing logic in libavcodec, I will determine if I'll improve cRpiAudioDecoder::cParser::Parse() a little, or if I'd make it use more of libavcodec, which rpihddevice already depends on for the actual decoding.
Cool. The FFMPEG guys will surely appreciate it.
I am hoping it to be easy to play 2 channels of the 5.1 channel audio, once the correct parameters have been determined. I may be too optimistic about this. Playing all 5.1 channels is probably much trickier.
Marko
-
Klaus Schmidinger -
Marko Mäkelä -
schorpp