September 2021 - FFmpeg-trac - lists.ffmpeg.org

Re: [FFmpeg-trac] #1726(undetermined:closed): Mono TrueHD file fails to decode
by FFmpeg 02 Sep '21

02 Sep '21

#1726: Mono TrueHD file fails to decode -------------------------------------+------------------------------------- Reporter: Carl Eugen | Owner: (none) Hoyos | Type: defect | Status: closed Priority: important | Component: | undetermined Version: git-master | Resolution: fixed Keywords: thd | Blocked By: regression mlp | Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Balling): Interesting, so even now with 16 samples present, the reencoded file is larger (13866334 bytes vs 11141326 bytes) but also no longer has flags to drop the second channel and does not print with -v debug "Mono stream with 2 substreams, ignoring 2nd". P.S. It is not printing stereo, but it creates wrong wav with 2 channels with second channel zeroed out in both source and reencoded file (when ffmpeg recognized the file as mono, the result was the same, two channel in wav). P.S.2 WHAT IS VERY IMPORTANT is that LG C9 which uses hardware decoder for Truehd and Truehd + Atmos (yep, it decodes Atmos packed in MAT 2.0 by Lavfilters even on the internal speackers and signals Atmos) thinks that the reencoded truehd file is not longer mono: when you select Right+Right in the LG C9 sound menu it plays nothing on reencoded file (because reencoded file has nothing in the right channel and is not tagged as mono) while on source file Right+Right is the same as L+R and L+L, since mono is being played on all speakers. What is also a problem is that reencoded file is so much less loud and also that it loses sound when you select only one speacker (R+R is no sound as I said but left+left is less loud again). That may be a difference between stereo and mono or DRC (Dynamic range compression) that is not supported in mlpenc (while eac3 and ac3 do support it). -- Ticket URL: <https://trac.ffmpeg.org/ticket/1726#comment:5> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

Re: [FFmpeg-trac] #779(avcodec:closed): Channels swapping when decode TrueHD 6.1
by FFmpeg 02 Sep '21

02 Sep '21

#779: Channels swapping when decode TrueHD 6.1 ------------------------------------+----------------------------------- Reporter: TDiTP_ | Owner: (none) Type: defect | Status: closed Priority: important | Component: avcodec Version: git-master | Resolution: fixed Keywords: thd | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | ------------------------------------+----------------------------------- Comment (by Balling): This is still good (checked wav in audition 2021, Center surround has sound in the end and compared to original many wav's), but of course the encoder does not support 6.1 and uses 5.1 while reencoding; is writing Center surround (that is only present in 6.1 not in 5.1) in both left and right surround. -- Ticket URL: <https://trac.ffmpeg.org/ticket/779#comment:3> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

Re: [FFmpeg-trac] #667(undetermined:closed): Error when decoding TrueHD 1.0 track that also contains AC-3
by FFmpeg 02 Sep '21

02 Sep '21

#667: Error when decoding TrueHD 1.0 track that also contains AC-3 -------------------------------------+------------------------------------- Reporter: Chouonsoku | Owner: (none) Type: defect | Status: closed Priority: minor | Component: | undetermined Version: git-master | Resolution: invalid Keywords: thd ac3 | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Changes (by Elon Musk): * status: open => closed * resolution: => invalid Comment: File is broken, created by broken tool. Nothing to fix here. -- Ticket URL: <https://trac.ffmpeg.org/ticket/667#comment:5> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

#6722(avcodec:new): XMA/WMAPro decoder: gapless problems
by FFmpeg 02 Sep '21

02 Sep '21

#6722: XMA/WMAPro decoder: gapless problems -------------------------------------+------------------------------------- Reporter: bnnm | Type: defect Status: new | Priority: normal Component: avcodec | Version: git- Keywords: xma, wmapro | master Blocking: | Blocked By: Analyzed by developer: 0 | Reproduced by developer: 0 -------------------------------------+------------------------------------- XMA first/last output is slightly incorrect, notably breaking gapless files. Haven't tested WMAPro files as much but I believe also applies. ---- From tests with Microsoft's XMA encoder (xmaencode.exe): - FFmpeg decodes 128(?) samples late, and xmaencode adds 128 samples at output start (1 subframe of "setup_samples"?), making last subframe in a file incorrect. Basically the first and last output is off (samples in the middle look fine). - FFmpeg ignores "start skip" (samples to discard at the beginning) and "end skip" (same at the end), see wmaprodec.c@1443. Both used in decodes and applied after the first 128 "extra" samples. start_skip is usually set to frame_samples and end_skip to <frame_samples, but if manually changed (ex. to 100 or 0) xmaencode will honor the values. If >frame_size it clamps the value (512 in XMA), and end_skip seems to be always included even if 0. ex. final samples output of 10 frames: FFmpeg = 10*512; xmaencode = 128 + 1*512 - start_skip + 9*512 - end_skip ---- Example files: https://mega.nz/#!DBAFGY4C!Jb0Y8gtDpm_V12DSqz5LP63k7xkqq_L9fMNn0Fc0Qv4 test_20.xma (20 PCM samples) - xmaencode encodes 1 frame (512) file - xmaencode decodes 128 + 512 - 512 start_skip (leaving last 128 from the frame) - 108 end_skip = 20 samples - FFmpeg just outputs 512, and the waveform isn't correct (last 128 are wrong) Screenshot: original PCM vs xmaencode vs ffmpeg vs xmaencode manually removing the skips from the file. test_322.xma: same with 2 frames, see how FFmpeg starts "late", and the second frame now decodes like the first frame should in test_20.xma: Both files are less than one packet, so it isn't a bug in the bit reservoir. I encoded those but the issues are present in all "real" files AFAIK. ---- Console output: {{{ % ffmpeg -i test_20.xma test_20.wav -v debug ffmpeg version N-87353-g183fd30 Copyright (c) 2000-2017 the FFmpeg developers built with gcc 7.2.0 (GCC) configuration: --enable-gpl --enable-version3 --enable-cuda --enable- cuvid --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-nvenc --enable-avisynth --enable-bzlib --enable-fontconfig --enable-frei0r --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libfreetype --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopus --enable-librtmp --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis --enable- libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable- libx265 --enable-libxavs --enable-libxvid --enable-libxml2 --enable- libzimg --enable-lzma --enable-zlib libavutil 55. 76.100 / 55. 76.100 libavcodec 57.106.101 / 57.106.101 libavformat 57. 82.101 / 57. 82.101 libavdevice 57. 8.101 / 57. 8.101 libavfilter 6.105.100 / 6.105.100 libswscale 4. 7.103 / 4. 7.103 libswresample 2. 8.100 / 2. 8.100 libpostproc 54. 6.100 / 54. 6.100 Splitting the commandline. Reading option '-i' ... matched as input url with argument 'test_20.xma'. Reading option 'test_20.wav' ... matched as output url. Reading option '-v' ... matched as option 'v' (set logging level) with argument 'debug'. Finished splitting the commandline. Parsing a group of options: global . Applying option v (set logging level) with argument debug. Successfully parsed a group of options. Parsing a group of options: input url test_20.xma. Successfully parsed a group of options. Opening an input file: test_20.xma. [NULL @ 00367800] Opening 'test_20.xma' for reading [file @ 00367f20] Setting default whitelist 'file,crypto' [wav @ 00367800] Format wav probed with size=2048 and score=99 [wav @ 00367800] Before avformat_find_stream_info() pos: 60 bytes read:2128 seeks:0 nb_streams:1 [wav @ 00367800] parser not found for codec xma1, packets or times may be invalid. [xma1 @ 03231580] extradata: [xma1 @ 03231580] [d6] [10] [0] [0] [1] [0] [0] [2] [80] [2d] [7] [0] [44] [ac] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [1] [1] [0] [wav @ 00367800] parser not found for codec xma1, packets or times may be invalid. [wav @ 00367800] After avformat_find_stream_info() pos: 2128 bytes read:2128 seeks:0 frames:1 Guessed Channel Layout for Input Stream #0.0 : mono Input #0, wav, from 'test_20.xma': Duration: N/A, bitrate: N/A Stream #0:0, 1, 1/44100: Audio: xma1 (e[1][0][0] / 0x0165), 44100 Hz, mono, fltp Successfully opened the file. Parsing a group of options: output url test_20.wav. Successfully parsed a group of options. Opening an output file: test_20.wav. [file @ 0036df00] Setting default whitelist 'file,crypto' Successfully opened the file. [xma1 @ 03231c00] extradata: [xma1 @ 03231c00] [d6] [10] [0] [0] [1] [0] [0] [2] [80] [2d] [7] [0] [44] [ac] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [0] [1] [1] [0] Stream mapping: Stream #0:0 -> #0:0 (xma1 (native) -> pcm_s16le (native)) Press [q] to stop, [?] for help cur_dts is invalid (this is harmless if it occurs once at the start per stream) detected 2 logical cores [graph_0_in_0_0 @ 032b5260] Setting 'time_base' to value '1/44100' [graph_0_in_0_0 @ 032b5260] Setting 'sample_rate' to value '44100' [graph_0_in_0_0 @ 032b5260] Setting 'sample_fmt' to value 'fltp' [graph_0_in_0_0 @ 032b5260] Setting 'channels' to value '1' [graph_0_in_0_0 @ 032b5260] tb:1/44100 samplefmt:fltp samplerate:44100 chlayout:(null) [format_out_0_0 @ 032b56e0] Setting 'sample_fmts' to value 's16' [format_out_0_0 @ 032b56e0] auto-inserting filter 'auto_resampler_0' between the filter 'Parsed_anull_0' and the filter 'format_out_0_0' [AVFilterGraph @ 032b4a00] query_formats: 4 queried, 6 merged, 3 already done, 0 delayed [auto_resampler_0 @ 032b5e20] [SWR @ 032b6ea0] Using fltp internally between filters [auto_resampler_0 @ 032b5e20] ch:1 chl:1 channels fmt:fltp r:44100Hz -> ch:1 chl:1 channels fmt:s16 r:44100Hz Output #0, wav, to 'test_20.wav': Metadata: ISFT : Lavf57.82.101 Stream #0:0, 0, 1/44100: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, 1 channels, s16, 705 kb/s Metadata: encoder : Lavc57.106.101 pcm_s16le [out_0_0 @ 032b55a0] EOF on sink link out_0_0:default. No more output streams to write to, finishing. size= 1kB time=00:00:00.01 bitrate= 759.3kbits/s speed= 5.8x video:0kB audio:1kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 7.617188% Input file #0 (test_20.xma): Input stream #0:0 (audio): 1 packets read (2048 bytes); 1 frames decoded (512 samples); Total: 1 packets (2048 bytes) demuxed Output file #0 (test_20.wav): Output stream #0:0 (audio): 1 frames encoded (512 samples); 1 packets muxed (1024 bytes); Total: 1 packets (1024 bytes) muxed 1 frames successfully decoded, 0 decoding errors [AVIOContext @ 03290060] Statistics: 4 seeks, 4 writeouts [AVIOContext @ 0036ca40] Statistics: 2128 bytes read, 0 seeks }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/6722> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 2

#8281(undetermined:new): memory leaks from options.c:158 in avcodec_alloc_context3
by FFmpeg 01 Sep '21

01 Sep '21

#8281: memory leaks from options.c:158 in avcodec_alloc_context3 -------------------------------------+------------------------------------- Reporter: Suhwan | Type: defect Status: new | Priority: normal Component: | Version: git- undetermined | master Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: There are memory leaks maybe from options.c:158 in avcodec_alloc_context3 How to reproduce: {{{ % ffmpeg_g -y -i $PoC -loglevel 0 -vbsf h264_mp4toannexb -c:a:139 msmpeg4 -disposition:s:11 utvideo -aframes 84 -r 96 -ar 22050 tmp.dnxhd ffmpeg version N-95385-ge1b89c76f6 Copyright (c) 2000-2019 the FFmpeg developers built with clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final) }}} Valgrind log. {{{ ==46857== ==46857== ==46857== HEAP SUMMARY: ==46857== in use at exit: 1,096 bytes in 2 blocks ==46857== total heap usage: 2,770 allocs, 2,768 frees, 3,927,957 bytes allocated ==46857== ==46857== 1,064 bytes in 1 blocks are definitely lost in loss record 2 of 2 ==46857== at 0x9D3BE76: memalign (in /usr/lib/valgrind /vgpreload_memcheck-amd64-linux.so) ==46857== by 0x9D3BF91: posix_memalign (in /usr/lib/valgrind /vgpreload_memcheck-amd64-linux.so) ==46857== by 0x590E23D: av_malloc (mem.c:87) ==46857== by 0x2D4E740: avcodec_alloc_context3 (options.c:158) ==46857== by 0x2153CFC: ff_frame_thread_encoder_init (frame_thread_encoder.c:198) ==46857== by 0x344D15F: avcodec_open2 (utils.c:740) ==46857== by 0x4A67F1: init_output_stream (ffmpeg.c:3507) ==46857== by 0x4BFF95: reap_filters (ffmpeg.c:1442) ==46857== by 0x48D611: transcode_step (ffmpeg.c:4638) ==46857== by 0x48D611: transcode (ffmpeg.c:4682) ==46857== by 0x487D53: main (ffmpeg.c:4884) ==46857== ==46857== LEAK SUMMARY: ==46857== definitely lost: 1,064 bytes in 1 blocks ==46857== indirectly lost: 0 bytes in 0 blocks ==46857== possibly lost: 0 bytes in 0 blocks ==46857== still reachable: 32 bytes in 1 blocks ==46857== suppressed: 0 bytes in 0 blocks ==46857== Reachable blocks (those to which a pointer was found) are not shown. ==46857== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==46857== ==46857== For counts of detected and suppressed errors, rerun with: -v ==46857== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/8281> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 3

Re: [FFmpeg-trac] #667(undetermined:open): Error when decoding TrueHD 1.0 track that also contains AC-3
by FFmpeg 01 Sep '21

01 Sep '21

#667: Error when decoding TrueHD 1.0 track that also contains AC-3 -------------------------------------+------------------------------------- Reporter: Chouonsoku | Owner: (none) Type: defect | Status: open Priority: minor | Component: | undetermined Version: git-master | Resolution: Keywords: thd ac3 | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Balling): Yet with ffprobe -f ac3 m2ts it does recognize it as E-AC3!!! {{{ [ac3 @ 0000021cebdadd00] Estimating duration from bitrate, this may be inaccurate Input #0, ac3, from 'C:\Users\ZAQU\stwqab.m2ts': Duration: 00:00:51.03, start: 0.000000, bitrate: 94 kb/s Stream #0:0: Audio: eac3, 48000 Hz, mono, fltp, 94 kb/s }}} So IMHO, this has ac3 core and eac3 dependent stream! Ah, and yes, this no longer decodes at all with ffmpeg -f ac3 -i TrueHDAC3.thd. This is a recent regression but before August 2020. -- Ticket URL: <https://trac.ffmpeg.org/ticket/667#comment:4> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

Re: [FFmpeg-trac] #667(undetermined:open): Error when decoding TrueHD 1.0 track that also contains AC-3
by FFmpeg 01 Sep '21

01 Sep '21

#667: Error when decoding TrueHD 1.0 track that also contains AC-3 -------------------------------------+------------------------------------- Reporter: Chouonsoku | Owner: (none) Type: defect | Status: open Priority: minor | Component: | undetermined Version: git-master | Resolution: Keywords: thd ac3 | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Balling): After -c copy to m2ts it does not properly recognize ac3... {{{ Input #0, mpegts, from 'C:\Users\xxxx\stwqab.m2ts': Duration: 00:00:05.31, start: 1.400000, bitrate: 906 kb/s Program 1 Metadata: service_name : Service01 service_provider: FFmpeg Stream #0:0[0x1100]: Audio: truehd ([131][0][0][0] / 0x0083), 48000 Hz, stereo, s32 (24 bit) No Program Stream #0:1[0x1100]: Audio: ac3, 0 channels, fltp }}} So... -- Ticket URL: <https://trac.ffmpeg.org/ticket/667#comment:3> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0