January 2023 - FFmpeg-trac - lists.ffmpeg.org

Re: [FFmpeg-trac] #667(undetermined:reopened): Error when decoding TrueHD 1.0 track that also contains AC-3
by FFmpeg 31 Jan '23

31 Jan '23

#667: Error when decoding TrueHD 1.0 track that also contains AC-3 -------------------------------------+------------------------------------- Reporter: Chouonsoku | Owner: (none) Type: defect | Status: reopened Priority: minor | Component: | undetermined Version: git-master | Resolution: Keywords: thd ac3 | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Chouonsoku): Replying to [comment:14 Balling]: > >Each file plays back correctly. > > Can you send me that? This link should work, didn't realize the previous one was one use. https://easyupload.io/dzt1pl Password: ffmpeg -- Ticket URL: <https://trac.ffmpeg.org/ticket/667#comment:15> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

Re: [FFmpeg-trac] #667(undetermined:reopened): Error when decoding TrueHD 1.0 track that also contains AC-3
by FFmpeg 31 Jan '23

31 Jan '23

#667: Error when decoding TrueHD 1.0 track that also contains AC-3 -------------------------------------+------------------------------------- Reporter: Chouonsoku | Owner: (none) Type: defect | Status: reopened 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): >Each file plays back correctly. Can you send me that? -- Ticket URL: <https://trac.ffmpeg.org/ticket/667#comment:14> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

Re: [FFmpeg-trac] #667(undetermined:reopened): Error when decoding TrueHD 1.0 track that also contains AC-3
by FFmpeg 31 Jan '23

31 Jan '23

#667: Error when decoding TrueHD 1.0 track that also contains AC-3 -------------------------------------+------------------------------------- Reporter: Chouonsoku | Owner: (none) Type: defect | Status: reopened Priority: minor | Component: | undetermined Version: git-master | Resolution: Keywords: thd ac3 | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Chouonsoku): Replying to [comment:12 Balling]: > >have extracted and shared here what should be an identically formatted track > > Can you extract normal truehd with a newer version of eac3to that is playable? because this looks like eac3to bug with mono thd then, and we can close this. Yes, the version I first had success with was eac3to v3.31 and I was able to demux the thd+ac3 tracks from the source m2ts, demux only the thd without the ac3 core, and decode the thd to wav. I was able to repeat that with v3.34 today when extracting the submitted full thd+ac3 track. ffmpeg handles the track without error as expected. Each file plays back correctly. -- Ticket URL: <https://trac.ffmpeg.org/ticket/667#comment:13> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

Re: [FFmpeg-trac] #667(undetermined:reopened): Error when decoding TrueHD 1.0 track that also contains AC-3
by FFmpeg 31 Jan '23

31 Jan '23

#667: Error when decoding TrueHD 1.0 track that also contains AC-3 -------------------------------------+------------------------------------- Reporter: Chouonsoku | Owner: (none) Type: defect | Status: reopened 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): >have extracted and shared here what should be an identically formatted track Can you extract normal truehd with a newer version of eac3to that is playable? because this looks like eac3to bug with mono thd then, and we can close this. -- Ticket URL: <https://trac.ffmpeg.org/ticket/667#comment:12> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

Re: [FFmpeg-trac] #667(undetermined:reopened): Error when decoding TrueHD 1.0 track that also contains AC-3
by FFmpeg 30 Jan '23

30 Jan '23

#667: Error when decoding TrueHD 1.0 track that also contains AC-3 -------------------------------------+------------------------------------- Reporter: Chouonsoku | Owner: (none) Type: defect | Status: reopened Priority: minor | Component: | undetermined Version: git-master | Resolution: Keywords: thd ac3 | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Comment (by Chouonsoku): Hello, I think this can be closed again as invalid. Some years ago now I was eventually able to decode this file with ffmpeg when extracted with a newer version of eac3to. I don't know where in the chain anything got fixed, whether it was an issue at the decryption level, eac3to, ffmpeg, etc. I no longer have the original disc the reported track was extracted from but I have a similar one in the same series and have extracted and shared here what should be an identically formatted track: https://file.io/96dpWxzLRYhx -- Ticket URL: <https://trac.ffmpeg.org/ticket/667#comment:11> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

Re: [FFmpeg-trac] #667(undetermined:reopened): Error when decoding TrueHD 1.0 track that also contains AC-3
by FFmpeg 30 Jan '23

30 Jan '23

#667: Error when decoding TrueHD 1.0 track that also contains AC-3 -------------------------------------+------------------------------------- Reporter: Chouonsoku | Owner: (none) Type: defect | Status: reopened 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): >Do you have the full japanese.thd? Repeating the question. -- Ticket URL: <https://trac.ffmpeg.org/ticket/667#comment:10> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

#7274(undetermined:new): ffmpeg ignores padding when decoding DTS-HD MA stream in DTSHD container
by FFmpeg 30 Jan '23

30 Jan '23

#7274: ffmpeg ignores padding when decoding DTS-HD MA stream in DTSHD container -------------------------------------+------------------------------------- Reporter: Rollinnn | 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: I took wav file 24 bit 96 kHz, encoded it to DTS-HD MA in DTSHD container using DTS-HD Master Audio Suite encoder. Then i re-encoded my *.dtshd file to flac using ffmpeg. Then i did binary comparison (i used foobar2000 with plugin foo_bitcompare, but probably there exist other tools for this) of resulting flac against source wav and found that resulted flac is offsetted by 2048 samples. If i use dcadec (https://github.com/foo86/dcadec/releases) to decode *.dtshd file to wav, then resulted wav is bit-identical with source wav. If i use dcadec with option -S (Don't strip padding samples for streams within DTS-HD container), then resulted wav is also offsetted by 2048 samples. So it seems that ffmpeg just ignores padding for DTS-HD MA stream in DTSHD container. Attached zip archive contains source wav file and dtshd file. How to reproduce: {{{ ffmpeg -i C:\0000000000000\DTSENC.dtshd C:\0000000000000\DTSENC.flac ffmpeg version N-91330-ga990184007 Copyright (c) 2000-2018 the FFmpeg developers built with gcc 7.3.0 (GCC) configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable- bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable- libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable- libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable- nvenc --enable-nvdec --enable-dxva2 --enable-avisynth libavutil 56. 18.102 / 56. 18.102 libavcodec 58. 20.103 / 58. 20.103 libavformat 58. 17.100 / 58. 17.100 libavdevice 58. 4.101 / 58. 4.101 libavfilter 7. 25.100 / 7. 25.100 libswscale 5. 2.100 / 5. 2.100 libswresample 3. 2.100 / 3. 2.100 libpostproc 55. 2.100 / 55. 2.100 Input #0, dtshd, from 'C:\0000000000000\DTSENC.dtshd': Metadata: fileinfo : : Duration: 00:00:00.77, bitrate: 3909 kb/s Stream #0:0: Audio: dts (DTS-HD MA), 96000 Hz, stereo, s32p (24 bit) Stream mapping: Stream #0:0 -> #0:0 (dts (dca) -> flac (native)) Press [q] to stop, [?] for help Output #0, flac, to 'C:\0000000000000\DTSENC.flac': Metadata: fileinfo : : encoder : Lavf58.17.100 Stream #0:0: Audio: flac, 96000 Hz, stereo, s32 (24 bit), 128 kb/s Metadata: encoder : Lavc58.20.103 flac size= 307kB time=00:00:00.76 bitrate=3276.5kbits/s speed=27.4x video:0kB audio:299kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 2.711299% }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/7274> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 6

#9310(build system:new): ffmpeg configure ignores CC and CXX environment variables
by FFmpeg 30 Jan '23

30 Jan '23

#9310: ffmpeg configure ignores CC and CXX environment variables -------------------------------------+------------------------------------- Reporter: Simon Toth | Type: defect Status: new | Priority: normal Component: build | Version: system | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: How to reproduce: Run: `CC=clang CXX=clang++ ./configure` Configure script reports: `C Compiler gcc` This is a blocker for compiling ffmpeg inside sandboxes (such as part of Bazel) where the path to the compiler is injected by the runtime. -- Ticket URL: <https://trac.ffmpeg.org/ticket/9310> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 6

#4534(avcodec:new): Voxware metasound sounds broken
by FFmpeg 30 Jan '23

30 Jan '23

#4534: Voxware metasound sounds broken --------------------------------------+--------------------------------- Reporter: cehoyos | Owner: Type: defect | Status: new Priority: normal | Component: avcodec Version: git-master | Keywords: voxware Blocked By: | Blocking: Reproduced by developer: 0 | Analyzed by developer: 0 --------------------------------------+--------------------------------- (videolan ticket 14540) A Voxware Metasound avi sample was uploaded that sounds worse with current FFmpeg than with {{{mplayer -ac voxware}}}. {{{ $ ffmpeg -i Voxware_codec_cut.avi ffmpeg version N-71902-g858f81f Copyright (c) 2000-2015 the FFmpeg developers built with gcc 4.7 (SUSE Linux) configuration: --enable-gpl libavutil 54. 23.101 / 54. 23.101 libavcodec 56. 37.100 / 56. 37.100 libavformat 56. 31.102 / 56. 31.102 libavdevice 56. 4.100 / 56. 4.100 libavfilter 5. 16.101 / 5. 16.101 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 1.100 / 1. 1.100 libpostproc 53. 3.100 / 53. 3.100 [avi @ 0x2c1b460] Estimating duration from bitrate, this may be inaccurate Input #0, avi, from 'Voxware_codec_cut.avi': Metadata: encoder : Lavf56.31.102 Duration: 00:03:26.21, start: 0.000000, bitrate: 80 kb/s Stream #0:0: Audio: metasound (u[0][0][0] / 0x0075), 44100 Hz, stereo, fltp, 80 kb/s At least one output file must be specified }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/4534> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 14

#9140(ffmpeg:new): aac gapless fail
by FFmpeg 30 Jan '23

30 Jan '23

#9140: aac gapless fail -------------------------------------+------------------------------------- Reporter: | Type: defect MarmiteSandwich | Status: new | Priority: normal Component: ffmpeg | Version: | unspecified Keywords: aac gapless | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: I would like to be able to play all aac audio files (.m4a) gaplessly , i.e. without gaps or other interruptions. Occasionally, the transition from one file to another is not smooth, and I am supplying sample media where this is the case. I am submitting the 2 files referenced below, along with more details in "aacGaplessFail.txt". Version unknown, because I am experiencing this via mpd which uses an ffmpeg decoder plugin with unknown origin. Reproducing quote below supplied by mpd developer. How to reproduce: {{{ ffmpeg -f concat -safe 0 -i concat.txt -c copy out.m4a ... where concat.txt contains: file '01 Track01 aac gapless fail.m4a' file '02 Track02 aac gapless fail.m4a' When I played out.m4a, I heard the same glitch as with MPD }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/9140> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 12