July 2024 - FFmpeg-trac - lists.ffmpeg.org

#9751(swscale:new): Incorrect YUV->RGB24 conversion results on IBM Power9
by FFmpeg 09 Jun '25

09 Jun '25

#9751: Incorrect YUV->RGB24 conversion results on IBM Power9 -------------------------------------+------------------------------------- Reporter: gciaparrone | Type: defect Status: new | Priority: normal Component: swscale | Version: git- | master Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Converting a YUV frame into an RGB24 image seems to produce incorrect results on an IBM Power9 processor. Compiling ffmpeg with --disable- altivec solves the issue. The problem might be related to this old issue pointed out by Hong Bo Peng here: https://trac.ffmpeg.org/ticket/7124#comment:7 This can be more easily seen by converting a completely black image from RGB to YUV and then back to RGB on an IBM Power9 (or possibly on any Little Endian processor with ALTIVEC support?). The output image has all pixels set to [16, 16, 16] instead of [0, 0, 0]. The issue spans multiple versions of ffmpeg, including the current git master version. Using --disable-altivec or running the command on a non-ALTIVEC processor outputs the correct image with all [0, 0, 0] pixels. Input image: Output image (IBM Power9): Output image (AMD Ryzen 5 1600X processor): Output image (IBM Power9, --disable-altivec): How to reproduce: {{{ # convert RGB image to YUV420p $ ffmpeg -i black.png -pix_fmt yuv420p black.yuv # convert it back to RGB $ ffmpeg -s:v 64x64 -pix_fmt yuv420p -i black.yuv -frames:v 1 -pix_fmt rgb24 reblack.png }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/9751> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 16

#9996(ffmpeg:new): When remuxing dolby atmos mkv to mp4, complexity index is not present.
by FFmpeg 09 Jun '25

09 Jun '25

#9996: When remuxing dolby atmos mkv to mp4, complexity index is not present. -----------------------------------+--------------------------------------- Reporter: BlueWindy | Type: defect Status: new | Priority: normal Component: ffmpeg | Version: unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -----------------------------------+--------------------------------------- Summary of the bug: Here is a Dolby Atmos sample file with an EAC3-JOC audio stream : https://we.tl/jxvi4Pgwz9 source : https://thedigitaltheater.com/dolby-trailers/ From this, if I demux the EAC3-JOC, as you can see the complexity index is set correctly. <img width="346" alt="demuxed eac3-joc" src="https://user- images.githubusercontent.com/40682277/198607696-cace19e5-ea56-4544-a1a7-676…"> However, when I remux MKV to MP4, the complexity index is not present. <img width="338" alt="MKV to MP4" src="https://user- images.githubusercontent.com/40682277/198609017-02fc30f6-d458-4412-81d5-2ba…"> The reason this bug needs to be resolved is that, in the case of a smartphone that supports Dolby Atmos, the Dolby Atmos virtualizer is automatically activated only when the complexity index is presented. How to reproduce: {{{ ffmpeg -i DD+Atmos.mkv -c copy DD+Atmos.mp4 ffmpeg version N-108886-g79508ee523-20221028 Copyright (c) 2000-2022 the FFmpeg developers built with gcc 12.2.0 (crosstool-NG 1.25.0.90_cf9beb1) configuration: --prefix=/ffbuild/prefix --pkg-config-flags=--static --pkg-config=pkg-config --cross-prefix=x86_64-w64-mingw32- --arch=x86_64 --target-os=mingw32 --enable-gpl --enable-version3 --disable-debug --disable-w32threads --enable-pthreads --enable-iconv --enable-libxml2 --enable-zlib --enable-libfreetype --enable-libfribidi --enable-gmp --enable-lzma --enable-fontconfig --enable-libvorbis --enable-opencl --disable-libpulse --enable-libvmaf --disable-libxcb --disable-xlib --enable-amf --enable-libaom --enable-libaribb24 --enable-avisynth --enable-libdav1d --enable-libdavs2 --disable-libfdk-aac --enable- ffnvcodec --enable-cuda-llvm --enable-frei0r --enable-libgme --enable- libkvazaar --enable-libass --enable-libbluray --enable-libjxl --enable- libmp3lame --enable-libopus --enable-librist --enable-libssh --enable- libtheora --enable-libvpx --enable-libwebp --enable-lv2 --disable-libmfx --enable-libvpl --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopenmpt --enable- librav1e --enable-librubberband --enable-schannel --enable-sdl2 --enable- libsoxr --enable-libsrt --enable-libsvtav1 --enable-libtwolame --enable- libuavs3d --disable-libdrm --disable-vaapi --enable-libvidstab --enable- vulkan --enable-libshaderc --enable-libplacebo --enable-libx264 --enable- libx265 --enable-libxavs2 --enable-libxvid --enable-libzimg --enable- libzvbi --extra-cflags=-DLIBTWOLAME_STATIC --extra-cxxflags= --extra- ldflags=-pthread --extra-ldexeflags= --extra-libs=-lgomp --extra- version=20221028 libavutil 57. 39.101 / 57. 39.101 libavcodec 59. 51.100 / 59. 51.100 libavformat 59. 34.101 / 59. 34.101 libavdevice 59. 8.101 / 59. 8.101 libavfilter 8. 49.101 / 8. 49.101 libswscale 6. 8.112 / 6. 8.112 libswresample 4. 9.100 / 4. 9.100 libpostproc 56. 7.100 / 56. 7.100 Input #0, matroska,webm, from 'DD+Atmos.mkv': Metadata: encoder : libebml v1.3.4 + libmatroska v1.4.5 creation_time : 2018-03-08T15:37:18.000000Z Duration: 00:01:51.03, start: 0.000000, bitrate: 9165 kb/s Stream #0:0: Video: h264 (High), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 30 fps, 30 tbr, 1k tbn (default) Metadata: BPS : 8719852 BPS-eng : 8719852 DURATION : 00:01:50.966000000 DURATION-eng : 00:01:50.966000000 NUMBER_OF_FRAMES: 3329 NUMBER_OF_FRAMES-eng: 3329 NUMBER_OF_BYTES : 120950899 NUMBER_OF_BYTES-eng: 120950899 _STATISTICS_WRITING_APP: mkvmerge v12.0.0 ('Trust / Lust') 64bit _STATISTICS_WRITING_APP-eng: mkvmerge v12.0.0 ('Trust / Lust') 64bit _STATISTICS_WRITING_DATE_UTC: 2018-03-08 15:37:18 _STATISTICS_WRITING_DATE_UTC-eng: 2018-03-08 15:37:18 _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES Stream #0:1(eng): Audio: eac3, 48000 Hz, 5.1(side), fltp, 448 kb/s (default) Metadata: BPS : 448000 BPS-eng : 448000 DURATION : 00:01:50.944000000 DURATION-eng : 00:01:50.944000000 NUMBER_OF_FRAMES: 3467 NUMBER_OF_FRAMES-eng: 3467 NUMBER_OF_BYTES : 6212864 NUMBER_OF_BYTES-eng: 6212864 _STATISTICS_WRITING_APP: mkvmerge v12.0.0 ('Trust / Lust') 64bit _STATISTICS_WRITING_APP-eng: mkvmerge v12.0.0 ('Trust / Lust') 64bit _STATISTICS_WRITING_DATE_UTC: 2018-03-08 15:37:18 _STATISTICS_WRITING_DATE_UTC-eng: 2018-03-08 15:37:18 _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES [mp4 @ 000001d3e2ed6980] track 1: codec frame size is not set Output #0, mp4, to 'DD+Atmos.mp4': Metadata: encoder : Lavf59.34.101 Stream #0:0: Video: h264 (High) (avc1 / 0x31637661), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 30 fps, 30 tbr, 16k tbn (default) Metadata: BPS : 8719852 BPS-eng : 8719852 DURATION : 00:01:50.966000000 DURATION-eng : 00:01:50.966000000 NUMBER_OF_FRAMES: 3329 NUMBER_OF_FRAMES-eng: 3329 NUMBER_OF_BYTES : 120950899 NUMBER_OF_BYTES-eng: 120950899 _STATISTICS_WRITING_APP: mkvmerge v12.0.0 ('Trust / Lust') 64bit _STATISTICS_WRITING_APP-eng: mkvmerge v12.0.0 ('Trust / Lust') 64bit _STATISTICS_WRITING_DATE_UTC: 2018-03-08 15:37:18 _STATISTICS_WRITING_DATE_UTC-eng: 2018-03-08 15:37:18 _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES Stream #0:1(eng): Audio: eac3 (ec-3 / 0x332D6365), 48000 Hz, 5.1(side), fltp, 448 kb/s (default) Metadata: BPS : 448000 BPS-eng : 448000 DURATION : 00:01:50.944000000 DURATION-eng : 00:01:50.944000000 NUMBER_OF_FRAMES: 3467 NUMBER_OF_FRAMES-eng: 3467 NUMBER_OF_BYTES : 6212864 NUMBER_OF_BYTES-eng: 6212864 _STATISTICS_WRITING_APP: mkvmerge v12.0.0 ('Trust / Lust') 64bit _STATISTICS_WRITING_APP-eng: mkvmerge v12.0.0 ('Trust / Lust') 64bit _STATISTICS_WRITING_DATE_UTC: 2018-03-08 15:37:18 _STATISTICS_WRITING_DATE_UTC-eng: 2018-03-08 15:37:18 _STATISTICS_TAGS: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES Stream mapping: Stream #0:0 -> #0:0 (copy) Stream #0:1 -> #0:1 (copy) Press [q] to stop, [?] for help frame= 3329 fps=0.0 q=-1.0 Lsize= 124269kB time=00:01:50.93 bitrate=9176.7kbits/s speed= 995x video:118116kB audio:6067kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.068845% }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/9996> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 22

#10342(ffmpeg:new): memory leak in fftools/ffmpeg_opt.c file's opt_map_channel function
by FFmpeg 06 Jun '25

06 Jun '25

#10342: memory leak in fftools/ffmpeg_opt.c file's opt_map_channel function -------------------------------------+------------------------------------- Reporter: Hripsime | Type: defect Status: new | Priority: important Component: ffmpeg | Version: git- | master Keywords: memory leak | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 1 | -------------------------------------+------------------------------------- The opt_map_channel function in the fftools/ffmpeg_opt.c source file appears to contain a memory leak. Specifically, memory is allocated using av_strdup() in line 472: mapchan = av_strdup(arg); However, the function contains multiple exit_program() calls that terminate the program without freeing the allocated memory in lines 507, 513, 519, and 533. -- Ticket URL: <https://trac.ffmpeg.org/ticket/10342> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 4

#4908(avformat:new): Memory leak in ff_img_read_header() with custom io
by FFmpeg 06 Jun '25

06 Jun '25

#4908: Memory leak in ff_img_read_header() with custom io -------------------------------------+------------------------------------- Reporter: | Type: defect personalmountains | Priority: normal Status: new | Version: Component: avformat | unspecified Keywords: memory leak | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- [https://github.com/FFmpeg/FFmpeg/commit/726e253b004de9511f63625ce95feee4d9a… This patch] changed `probe_buffer` from an array to a pointer allocated with `av_realloc()`. It was correctly freed at the end of the block. However, [https://github.com/FFmpeg/FFmpeg/commit/6691eee48c7f08caf479ce3562a1c834475… that one] buried the `av_free()` call into `ffio_rewind_with_probe_data()`. Unsurprisingly, [https://github.com/FFmpeg/FFmpeg/commit/e6e8cc8ce9c2a398fbb51254a5067f4bd3c… a subsequent patch] made it so this call is skipped in the case of custom io, so the buffer is never freed. A simple `av_free()` after the call to `avio_seek()` on [https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/img2dec.c#L346 img2dec.c:346] might do the job. {{{ int probe_buffer_size = 2048; uint8_t *probe_buffer = av_realloc(NULL, probe_buffer_size + AVPROBE_PADDING_SIZE); // ... if (s1->flags & AVFMT_FLAG_CUSTOM_IO) { // this leaks probe_buffer because av_free() isn't called avio_seek(s1->pb, 0, SEEK_SET); } else ffio_rewind_with_probe_data(s1->pb, &probe_buffer, probe_buffer_size); }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/4908> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 2

#10374(avcodec:new): Problems to decode certain h264 keyframes with D3D11VA and DXVA2 hw acceleration
by FFmpeg 05 Jun '25

05 Jun '25

#10374: Problems to decode certain h264 keyframes with D3D11VA and DXVA2 hw acceleration -------------------------------------+------------------------------------- Reporter: Florian | Type: defect Grill | Status: new | Priority: normal Component: avcodec | Version: 6.0 Keywords: H264 dxva2 | Blocked By: d3d11va | Blocking: | Reproduced by developer: 1 Analyzed by developer: 1 | -------------------------------------+------------------------------------- Summary of the bug: I'm currently developing a streaming app for Windows and for my project I use the javacv project to use the native ffmpeg libraries [https://github.com/bytedeco/javacv] Developing the first prototype was quite easy but upon further testing on different machines with different hardware decoders I noticed some strange effects with the D3D11VA and DXVA2 video decoder. It was just not possible to decode certain keyframes but cuvid or the software decoder had no problem to do so. On these problematic keyframes I always received an error when calling {{{ final int err = avcodec_send_packet(this.m_VideoDecoderCtx, this.pkt); }}} The logs printed out ''"Invalid data found when processing input"'' but I was 100% sure that the data was correct so I started to dig into source code and did some research on the internet and I found the issue. It seems that in h264dec.h there is a variable called MAX_SLICES which is set to 32. [https://github.com/FFmpeg/FFmpeg/blob/release/6.0/libavcodec/h264dec.h#L62] This MAX_SLICES value is used here dxva2_h264.c [https://github.com/FFmpeg/FFmpeg/blob/release/6.0/libavcodec/dxva2_h264.c#L…] which leads to the fact that frames with larger slices simply can't be processed. This is strange limitation if you ask me. Other popular ffmpeg forks already increased this limit, e.g. [https://git.1f0.de/gitweb/?p=ffmpeg.git;a=commit;h=550cf548b546d386a6c63435…] In my example I used {{{ this.m_VideoDecoderCtx.err_recognition(this.m_VideoDecoderCtx.err_recognition() | AV_EF_EXPLODE); }}} to get a proper error output but for testing I removed it and the frame that was processed and displayed looked like that [[Image(https://github.com/grill2010/ExampleDXVA2/blob/main/example_data/test…]] This behaviour can be easily reproduced with the latest ffmpeg version. The example h264 keyframe can be downloaded from here [https://github.com/grill2010/ExampleDXVA2/blob/main/example_data/example.h2…] How to reproduce: {{{ % .\ffmpeg.exe -hwaccel dxva2 -i .\example.h264 test.jpg or % .\ffmpeg.exe -hwaccel d3d11va -i .\example.h264 test.jpg ffmpeg version 6.0 and latest SNAPSHOT built via https://www.gyan.dev/ffmpeg/builds/ }}} On the ffmpeg version of javacv there was recently a patch for this small numbers of slices [https://github.com/bytedeco/javacpp- presets/commit/63acf680ef0d95cbdda1b3840450e4333a78bde0] and I can confirm that this fixes the issue completely (at least for D3D11VA). Btw. I found another ticket which might be related to this problem [https://trac.ffmpeg.org/ticket/9771] ---- Like I said a fix was applied to the javacv ffmpeg version so I tried to compile this ffmpeg version for Windows x86_x64 with this increased MAX_SLICES for further testing. D3D11VA works perfectly fine now but I noticed another issue with DXVA2. Still on certain keyframes I received an error but this time a different one. When calling {{{ final int err = avcodec_send_packet(this.m_VideoDecoderCtx, this.pkt); }}} I receive now {{{ [h264 @ 0000027a270a1680] Buffer for type 5 was too small. size: 58752, dxva_size: 55296 [h264 @ 0000027a270a1680] Failed to add bitstream or slice control buffer [h264 @ 0000027a270a1680] hardware accelerator failed to decode picture Error while decoding stream #0:0: Operation not permitted }}} Upon further investigation it turned out that the decoding of these certain keyframes fail because the buffer returned from the IDirectXVideoDecoder_GetBuffer function was too small. And I don't have any explanation why. DXVA2 works perfectly fine btw for h265 (not affected by the MAX_SLICES problem and not by the too small buffer problem). [https://github.com/FFmpeg/FFmpeg/blob/9d70e74d255dbe37af52b0efffc0f93fd7cb6…] I tested this behaviour now on 4 different PCs and the pattern I found is that it works on PCs with AMD or Intel GPUs but if you have an NVIDIA GPU you get this small buffer problem. How to reproduce: {{{ % .\ffmpeg.exe -hwaccel dxva2 -i .\example.h264 test.jpg ffmpeg version with a patch which sets MAX_SLICES in dxva2_h264.c to 256 built via javacv (java-presets build process) }}} I have provided here a Windows x64 ffmpeg build with that MAX_SLICES patch [https://github.com/grill2010/ExampleDXVA2/tree/main/example_data] ---- I know that these are probably two bug reports in one but for me these things are related. The first problem with these small slices are probably an easy fix, the question is why is it like that in the first place? Other hw decoder for example like the dxva2 hevc decoder are overriding this small slice value but not dxva2 h264? Any reason for that? This is actually quite limiting the h264 hw acceleration for DXVA2 and D3D11VA. For the second problem with the too small buffer on DXVA2 I have absolutely no idea what could cause this issue and why it (seemingly) only occur on devices with an NVIDIA GPU. I would like to start some further testing but no idea where to start. I tried to provide as much details as possible if there are any questions just let me know. -- Ticket URL: <https://trac.ffmpeg.org/ticket/10374> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 11

#10830(undetermined:new): Bug: MPEG-1/2 encoder output video missing end code
by FFmpeg 02 Jun '25

02 Jun '25

#10830: Bug: MPEG-1/2 encoder output video missing end code -------------------------------------+------------------------------------- Reporter: Nebulas | Type: defect Status: new | Priority: important Component: | Version: undetermined | unspecified Keywords: mpegvideo | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: When the MPEG-1/MPEG-2 (PS) video stream file (*.m1v/*.m2v) is encoded by the mpegvideo encoder, the end code of the video sequence (sequence_end_code, As defined in ISO/IEC 11172-2 2.4.2.2, or ISO/IEC 13818-2 6.2.2, “the bit string '000001B7' in hexadecimal”) in the output file is missing. How to reproduce: {{{% ffmpeg -i in.mp4 -an -c:v mpeg1video out.m1v}}} or {{{% ffmpeg -i in.mp4 -an out.m2v}}} ffmpeg version: Windows builts from gyan.dev, “ffmpeg-2024-01-24-git- 00b288da73-full_build” -- Ticket URL: <https://trac.ffmpeg.org/ticket/10830> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 3

#11020(ffmpeg:new): Invalid color range error on ffmpeg 7.0
by FFmpeg 30 May '25

30 May '25

#11020: Invalid color range error on ffmpeg 7.0 --------------------------------+------------------------------------- Reporter: Marius | Type: defect Status: new | Priority: important Component: ffmpeg | Version: 7.0 Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | --------------------------------+------------------------------------- **Summary of the bug:** I'm trying to transcode a video with h264, but I've also tried h265 having the same output. **How to reproduce:** {{{ ffmpeg -i https://vid.connatix.com/mmid-545c8cbb- f0f5-119b-2687-29df00ef32c7/original.mp4 -c:v libx264 -c:a aac output.mp4 }}} **ffmpeg version:** {{{ any 7.0 build }}} **Platform:** {{{ windows, mac and linux }}} **Output:** {{{ [graph 0 input from stream 0:0 @ 0x6000005fc420] Invalid color range [vf#0:0 @ 0x6000000ff9f0] Error reinitializing filters! [vf#0:0 @ 0x6000000ff9f0] Task finished with error code: -22 (Invalid argument) [vf#0:0 @ 0x6000000ff9f0] Terminating thread with return code -22 (Invalid argument) [vost#0:0/libx264 @ 0x12fe11870] Could not open encoder before EOF [vost#0:0/libx264 @ 0x12fe11870] Task finished with error code: -22 (Invalid argument) [vost#0:0/libx264 @ 0x12fe11870] Terminating thread with return code -22 (Invalid argument) [out#0/mp4 @ 0x6000007fc000] Nothing was written into output file, because at least one of its streams received no packets. }}} I've also tried specifying `-color_primaries 1`, `-color_trc 1` and `-colorspace 1` with no success. This error is not reproducible on any of the mentioned platforms when using ffmpeg version 6.1. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11020> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 10

#9471(ffmpeg:new): EAC3 native encoder is only gapless in the beginning, not in the end
by FFmpeg 27 May '25

27 May '25

#9471: EAC3 native encoder is only gapless in the beginning, not in the end -------------------------------------+------------------------------------- Reporter: Balling | Type: defect Status: new | Priority: normal Component: ffmpeg | Version: git- Keywords: mp4 eac3 | master editlist gapless | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: edts atmos (editlist) has media time and media duration, yet even though media time is correctly written for EAC3 and AAC (native EAC3 encoder has 256 sample of silence (a.k.a. encoder delay) that are then removed from the beginning with native encoder and native AAC has 1024 samples that are also working great) the media duration is not correctly written. Even if it were to be correctly written media duration is not applied on decoding even for AAC, see for example https://bugs.chromium.org/p/chromium/issues/detail?id=668999 that is still present in git-master!!! How to reproduce: {{{ % ffmpeg -f lavfi -i "sine=frequency=1000:duration=5" -c:a eac3 outeac3.mp4 ffmpeg version N-104341-g933765aa0e-20211013 Copyright (c) 2000-2021 the FFmpeg developers built with gcc 10-win32 (GCC) 20210408 configuration: --prefix=/ffbuild/prefix --pkg-config-flags=--static --pkg-config=pkg-config --cross-prefix=x86_64-w64-mingw32- --arch=x86_64 --target-os=mingw32 --enable-gpl --enable-version3 --disable-debug --enable-shared --disable-static --disable-w32threads --enable-pthreads --enable-iconv --enable-libxml2 --enable-zlib --enable-libfreetype --enable-libfribidi --enable-gmp --enable-lzma --enable-fontconfig --enable-libvorbis --enable-opencl --enable-libvmaf --enable-vulkan --disable-libxcb --disable-xlib --enable-amf --enable-libaom --enable- avisynth --enable-libdav1d --enable-libdavs2 --disable-libfdk-aac --enable-ffnvcodec --enable-cuda-llvm --enable-frei0r --enable-libglslang --enable-libgme --enable-libass --enable-libbluray --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvpx --enable-libwebp --enable-lv2 --enable-libmfx --enable-libopencore-amrnb --enable- libopencore-amrwb --enable-libopenjpeg --enable-librav1e --enable- librubberband --enable-schannel --enable-sdl2 --enable-libsoxr --enable- libsrt --enable-libsvtav1 --enable-libtwolame --enable-libuavs3d --disable-libdrm --disable-vaapi --enable-libvidstab --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libzimg --enable-libzvbi --extra-cflags=-DLIBTWOLAME_STATIC --extra-cxxflags= --extra-ldflags=-pthread --extra-ldexeflags= --extra-libs=-lgomp --extra- version=20211013 libavutil 57. 7.100 / 57. 7.100 libavcodec 59. 12.100 / 59. 12.100 libavformat 59. 6.100 / 59. 6.100 libavdevice 59. 0.101 / 59. 0.101 libavfilter 8. 14.100 / 8. 14.100 libswscale 6. 1.100 / 6. 1.100 libswresample 4. 0.100 / 4. 0.100 libpostproc 56. 0.100 / 56. 0.100 Input #0, lavfi, from 'sine=frequency=1000:duration=5': Duration: N/A, start: 0.000000, bitrate: 705 kb/s Stream #0:0: Audio: pcm_s16le, 44100 Hz, mono, s16, 705 kb/s Stream mapping: Stream #0:0 -> #0:0 (pcm_s16le (native) -> eac3 (native)) Press [q] to stop, [?] for help Output #0, mp4, to 'outeac3.mp4': Metadata: encoder : Lavf59.6.100 Stream #0:0: Audio: eac3 (ec-3 / 0x332D6365), 44100 Hz, mono, fltp, 96 kb/s Metadata: encoder : Lavc59.12.100 eac3 size= 60kB time=00:00:05.00 bitrate= 98.2kbits/s speed= 487x video:0kB audio:59kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 2.166617% }}} {{{ Track duration: 5010 (0x00001392) - 5010 (0x1392) ms Media time: 256 (0x00000100) - 256 (0x100) ms Media rate: 65536 (0x00010000) - 1.000 }}} Now compare it to aac: ffmpeg -f lavfi -i "sine=frequency=1000:duration=5" -c:a aac fileaac.mp4: {{{ Track duration: 5000 (0x00001388) - 5000 (0x1388) ms Media time: 1024 (0x00000400) - 1024 (0x400) Media rate: 65536 (0x00010000) - 1.000 }}} Unfortunately a) Mediainfo tracer is buggy in that part: https://github.com/MediaArea/MediaInfoLib/issues/1441 b) I am not sure that media duration is really buggy since it is not applied anyway! c) I checked it all decoding to wav and checking in Audacity. d) I dunno whether sbgp and sgpd are needed (whether EAC3 depends on previous frames) Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker. -- Ticket URL: <https://trac.ffmpeg.org/ticket/9471> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 10

#3643(undetermined:new): XYZ to RGB color space
by FFmpeg 27 May '25

27 May '25

#3643: XYZ to RGB color space -------------------------------------+------------------------------------- Reporter: tteam | Type: Status: new | enhancement Component: | Priority: normal undetermined | Version: Keywords: more XYZ to | unspecified RGB matrix | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: XYZ to RGB colorspace conversion use only sRGB matrix and sometimes the conversion is deffected in red channel and the picture is dark. Hi all! Is it possible to add more color space matrix (in option) to XYZ to RGB conversion? Because the FFMPEG use only one matrix (sRGB) but lots of available, and best if the user can choose one. Because the problem is: sometimes the conversion is deffected the red is much more and the picture is dark. If possible please add some from this list. The default is the sRGB but optional the others. XYZ to RGB matrices: http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html Thanks -- Ticket URL: <https://trac.ffmpeg.org/ticket/3643> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 8

#7337(undetermined:new): FFmpeg not recognizing WebVTT subtitle stream from HLS playlist
by FFmpeg 26 May '25

26 May '25

#7337: FFmpeg not recognizing WebVTT subtitle stream from HLS playlist -------------------------------------+------------------------------------- Reporter: newsfanatic | Type: defect Status: new | Priority: normal Component: | Version: git- undetermined | master Keywords: | Blocked By: WebVTT,HLS,m3u8,playlist,subtitles | Reproduced by developer: 0 Blocking: | Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: When trying to ingest an HLS playlist from an m3u8 endpoint online to an mkv container, the subtitle stream is not being picked up at all. I can confirm that all other audio and video streams are being recognized, whilst the subtitle stream is not. I can also confirm that WebVTT is listed as a supported subtitle codec from ```ffmpeg -codecs```. Specifying ```-map 0``` also fails to pick up the subtitle stream. Am I just forgetting a flag or option? How to reproduce: {{{ % ffmpeg -report -i https://ajo.prod.reuters.tv/rest/v2/xato/playlist/assets/57630,163881,16382… -c copy reuters.mkv ffmpeg version 4.0.2 Copyright (c) 2000-2018 the FFmpeg developers built with Apple LLVM version 9.0.0 (clang-900.0.39.2) configuration: --prefix=/usr/local/Cellar/ffmpeg/4.0.2 --enable-shared --enable-pthreads --enable-version3 --enable-hardcoded-tables --enable- avresample --cc=clang --host-cflags= --host-ldflags= --enable-gpl --enable-libmp3lame --enable-libx264 --enable-libxvid --enable-opencl --enable-videotoolbox --disable-lzma libavutil 56. 14.100 / 56. 14.100 libavcodec 58. 18.100 / 58. 18.100 libavformat 58. 12.100 / 58. 12.100 libavdevice 58. 3.100 / 58. 3.100 libavfilter 7. 16.100 / 7. 16.100 libavresample 4. 0. 0 / 4. 0. 0 libswscale 5. 1.100 / 5. 1.100 libswresample 3. 1.100 / 3. 1.100 libpostproc 55. 1.100 / 55. 1.100 }}} Subtitles are specified in the M3U8 manifest with the #EXT-X-MEDIA tag. M3U8 manifest: {{{ #EXTM3U #EXT-X-VERSION:4 #EXT-X-MEDIA:TYPE=SUBTITLES,GROUP- ID="subs",NAME="English",DEFAULT=YES,AUTOSELECT=YES,FORCED=NO,URI="https://ajo.prod.reuters.tv/rest/v2/captions/vtt/assets/57630,163881,163829…" #EXT-X-STREAM- INF:BANDWIDTH=360800,CODECS="mp4a.40.2,avc1.64000D",RESOLUTION=320x180,SUBTITLES="subs" https://ajo.prod.reuters.tv/rest/v2/playlist/assets/57630,163881,163829,574… #EXT-X-STREAM- INF:BANDWIDTH=499400,CODECS="mp4a.40.2,avc1.640015",RESOLUTION=512x288,SUBTITLES="subs" https://ajo.prod.reuters.tv/rest/v2/playlist/assets/57630,163881,163829,574… #EXT-X-STREAM- INF:BANDWIDTH=984500,CODECS="mp4a.40.2,avc1.64001E",RESOLUTION=640x360,SUBTITLES="subs" https://ajo.prod.reuters.tv/rest/v2/playlist/assets/57630,163881,163829,574… #EXT-X-STREAM- INF:BANDWIDTH=1490500,CODECS="mp4a.40.2,avc1.64001F",RESOLUTION=854x480,SUBTITLES="subs" https://ajo.prod.reuters.tv/rest/v2/playlist/assets/57630,163881,163829,574… #EXT-X-STREAM- INF:BANDWIDTH=2006400,CODECS="mp4a.40.2,avc1.64001F",RESOLUTION=960x540,SUBTITLES="subs" https://ajo.prod.reuters.tv/rest/v2/playlist/assets/57630,163881,163829,574… #EXT-X-STREAM- INF:BANDWIDTH=3020600,CODECS="mp4a.40.2,avc1.64001F",RESOLUTION=1024x576,SUBTITLES="subs" https://ajo.prod.reuters.tv/rest/v2/playlist/assets/57630,163881,163829,574… #EXT-X-STREAM- INF:BANDWIDTH=4021600,CODECS="mp4a.40.2,avc1.64001F",RESOLUTION=1280x720,SUBTITLES="subs" https://ajo.prod.reuters.tv/rest/v2/playlist/assets/57630,163881,163829,574… #EXT-X-STREAM- INF:BANDWIDTH=4998400,CODECS="mp4a.40.2,avc1.640028",RESOLUTION=1920x1080,SUBTITLES="subs" https://ajo.prod.reuters.tv/rest/v2/playlist/assets/57630,163881,163829,574… #EXT-X-STREAM-INF:BANDWIDTH=113300,CODECS="mp4a.40.2",SUBTITLES="subs" https://ajo.prod.reuters.tv/rest/v2/playlist/assets/57630,163881,163829,574… }}} WebVTT asset manifest: {{{ #EXTM3U #EXT-X-VERSION:4 #EXT-X-TARGETDURATION:96 #EXTINF:5.5666, no desc https://ajo.prod.reuters.tv/rest/v2/captions/vtt/asset/57630 #EXT-X-DISCONTINUITY #EXTINF:4.4, no desc https://ajo.prod.reuters.tv/rest/v2/captions/vtt/asset/163881 #EXT-X-DISCONTINUITY #EXTINF:4.9667, no desc https://ajo.prod.reuters.tv/rest/v2/captions/vtt/asset/163829 #EXT-X-DISCONTINUITY #EXTINF:4.6333, no desc https://ajo.prod.reuters.tv/rest/v2/captions/vtt/asset/57447 #EXT-X-DISCONTINUITY #EXTINF:2.3, no desc https://ajo.prod.reuters.tv/rest/v2/captions/vtt/asset/127691 #EXT-X-DISCONTINUITY #EXTINF:2.3, no desc https://ajo.prod.reuters.tv/rest/v2/captions/vtt/asset/127676 #EXT-X-DISCONTINUITY #EXTINF:65.2, no desc https://ajo.prod.reuters.tv/rest/v2/captions/vtt/asset/163830 #EXT-X-DISCONTINUITY #EXTINF:2.3, no desc https://ajo.prod.reuters.tv/rest/v2/captions/vtt/asset/127649 #EXT-X-DISCONTINUITY #EXTINF:95.7, no desc https://ajo.prod.reuters.tv/rest/v2/captions/vtt/asset/163855 #EXT-X-DISCONTINUITY #EXTINF:5.0, no desc https://ajo.prod.reuters.tv/rest/v2/captions/vtt/asset/57635 #EXT-X-ENDLIST }}} Sample WebVTT blob: {{{ WEBVTT X-TIMESTAMP-MAP=MPEGTS:900000,LOCAL:00:00:00.000 1 00:00:00.370 --> 00:00:01.700 line:-3 You're watching Reuters TV. 2 00:00:02.790 --> 00:00:04.270 line:-3 Here are your top stories. }}} FFmpeg input report: {{{ Input #0, hls,applehttp, from 'https://ajo.prod.reuters.tv/rest/v2/xato/playlist/assets/57630,163881,16382…': Duration: 00:03:12.37, start: 10.000000, bitrate: N/A Program 0 Metadata: variant_bitrate : 360800 Stream #0:0: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp Metadata: variant_bitrate : 360800 Stream #0:1: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 320x180 [SAR 1:1 DAR 16:9], 30 fps, 30 tbr, 90k tbn, 60 tbc Metadata: variant_bitrate : 360800 Program 1 Metadata: variant_bitrate : 499400 Stream #0:2: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp Metadata: variant_bitrate : 499400 Stream #0:3: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 512x288 [SAR 1:1 DAR 16:9], 30 fps, 30 tbr, 90k tbn, 60 tbc Metadata: variant_bitrate : 499400 Program 2 Metadata: variant_bitrate : 984500 Stream #0:4: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp Metadata: variant_bitrate : 984500 Stream #0:5: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 640x360 [SAR 1:1 DAR 16:9], 30 fps, 30 tbr, 90k tbn, 60 tbc Metadata: variant_bitrate : 984500 Program 3 Metadata: variant_bitrate : 1490500 Stream #0:6: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp Metadata: variant_bitrate : 1490500 Stream #0:7: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 854x480 [SAR 1280:1281 DAR 16:9], 30 fps, 30 tbr, 90k tbn, 60 tbc Metadata: variant_bitrate : 1490500 Program 4 Metadata: variant_bitrate : 2006400 Stream #0:8: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp Metadata: variant_bitrate : 2006400 Stream #0:9: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 960x540 [SAR 1:1 DAR 16:9], 30 fps, 30 tbr, 90k tbn, 60 tbc Metadata: variant_bitrate : 2006400 Program 5 Metadata: variant_bitrate : 3020600 Stream #0:10: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp Metadata: variant_bitrate : 3020600 Stream #0:11: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1024x576 [SAR 1:1 DAR 16:9], 30 fps, 30 tbr, 90k tbn, 60 tbc Metadata: variant_bitrate : 3020600 Program 6 Metadata: variant_bitrate : 4021600 Stream #0:12: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp Metadata: variant_bitrate : 4021600 Stream #0:13: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 30 fps, 30 tbr, 90k tbn, 60 tbc Metadata: variant_bitrate : 4021600 Program 7 Metadata: variant_bitrate : 4998400 Stream #0:14: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp Metadata: variant_bitrate : 4998400 Stream #0:15: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 30 fps, 30 tbr, 90k tbn, 60 tbc Metadata: variant_bitrate : 4998400 Program 8 Metadata: variant_bitrate : 113300 Stream #0:16: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp Metadata: variant_bitrate : 113300 }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/7337> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 12