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
