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

#9473(ffmpeg:new): gdigrab screen captures are interrupted by secure desktop pop-ups
by FFmpeg 15 Jun '25

15 Jun '25

#9473: gdigrab screen captures are interrupted by secure desktop pop-ups -----------------------------------+-------------------------------------- Reporter: leopold84 | Type: defect Status: new | Priority: important Component: ffmpeg | Version: git-master Keywords: gdigrab | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -----------------------------------+-------------------------------------- '''Summary of the bug:''' If you start screen capture with gdigrab and any secure desktop pop-up will appear (UAC or anything else), capture immediately stops. '''How to reproduce:''' 1. Start screen capture using '''gdigrab''' device as input {{{ ffmpeg -f gdigrab -framerate 30 -i desktop output.mkv }}} 2. Launch any program as administrator or make a secure desktop to appear any other way 3. Once returned to the normal desktop, you will see that capture has stopped with the error similar to this one {{{ Failed to capture image (error 5)trate= 2.2kbits/s speed=0.54x desktop: I/O error }}} '''Expect result:''' If it's not possible to capture secure desktop with gdigrab, at least make it so recording doesn't stop and capture a black screen instead of secure desktop -- Ticket URL: <https://trac.ffmpeg.org/ticket/9473> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 7

#10385(undetermined:new): ddagrab fails on Windows if adapter ID is specified
by FFmpeg 12 Jun '25

12 Jun '25

#10385: ddagrab fails on Windows if adapter ID is specified -------------------------------------+------------------------------------- Reporter: Jøger | Type: defect Hansegård | Status: new | Priority: normal Component: | Version: 6.0 undetermined | Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: Screen capturing on Windows with ddagrab fails if adapter id is specified on non-UWP build. Root cause is likely that CreateDXGIFactory is used, not CreateDXGIFactory1. Desktop duplication API appears to be incompatible with DXGI factories prior to 1.1. See also https://learn.microsoft.com/en-us/windows/win32/api/dxgi1_2/nf- dxgi1_2-idxgioutput1-duplicateoutput which specifies that IDXGIOutput1::DuplicateOutput fails with E_INVALIDARG if the device was not created from IDXGIFactory1 (or a later version of a DXGI factory interface that inherits from IDXGIFactory1). How to reproduce: {{{ ffmpeg -init_hw_device d3d11va:0 -filter_complex ddagrab -c:v h264_nvenc -cq:v 20 output.mkv -loglevel debug ffmpeg version 6.0 built on Windows, MSYS2 }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/10385> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 1

#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

#11398(undetermined:new): AVFoundation audio recordings have audible ticks and are missing samples
by FFmpeg 08 Jun '25

08 Jun '25

#11398: AVFoundation audio recordings have audible ticks and are missing samples -------------------------------------+------------------------------------- Reporter: drobinson | Type: defect Status: new | Priority: normal Component: | Version: 7.1 undetermined | Keywords: | Blocked By: avfoundation audio dropouts | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: I am using macOS 15.1 (Sequoia) on a 2021 Apple M1 Pro MacBook Pro 14-inch laptop, running FFmpeg version 7.1 installed via Homebrew. Audio captured using AVFoundation through any audio codec (AAC, MP3, PCM, or -c:a copy) produces audible glitches in the form of missing samples. This issue occurs regardless of the sound device selected (built-in audio, USB audio, etc.). Originally, I ran into this issue while attempting to capture both video and audio and encode them using libx264 and AAC. However, I found that the issue persists even in the most basic use case—just recording audio without video encoding. Steps to Reproduce: 1. Record a known waveform with the following command: {{{ ffmpeg -f avfoundation -i ":0" -c:a copy output.wav }}} 2. Listen to output.wav. I notice frequent random audible ticks. 3. Inspect the waveform of output.wav in an audio editing tool (e.g., Reaper). I observed that the waveform exhibits discontinuities, where a sequence of input samples, such as (1, 2, 3, 4, 5, 6, 7, 8, 9), results in an output sequence like (1, 2, 3, 8, 9). In this example, samples 4, 5, 6, and 7 are missing, and sample 8 immediately follows sample 3. These missing samples occur randomly, typically every 3000-10000 samples, with no discernible pattern. Here is an example of a ramp waveform I used with the glitch circled in red: [[Image(https://i.ibb.co/rysLqqW/glitch.png)]] And up close: [[Image(https://i.ibb.co/hmKp3hT/glitch-close.png)]] Expected Behavior: The output audio should accurately represent the input without any missing or skipped samples. Actual Behavior: There are consistent audio dropouts, where specific sections of audio are completely missing, resulting in a glitchy sound. This happens with every audio codec tested (AAC, MP3, PCM) and with different sound devices (built-in, USB, etc.). Details: {{{ % ffmpeg -f avfoundation -i ":0" -c:a copy output.wav ffmpeg version 7.1 Copyright (c) 2000-2024 the FFmpeg developers built with Apple clang version 16.0.0 (clang-1600.0.26.4) configuration: --prefix=/opt/homebrew/Cellar/ffmpeg/7.1_4 --enable- shared --enable-pthreads --enable-version3 --cc=clang --host-cflags= --host-ldflags='-Wl,-ld_classic' --enable-ffplay --enable-gnutls --enable- gpl --enable-libaom --enable-libaribb24 --enable-libbluray --enable- libdav1d --enable-libharfbuzz --enable-libjxl --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librist --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtesseract --enable-libtheora --enable-libvidstab --enable- libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable- libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable- libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable- libopenjpeg --enable-libspeex --enable-libsoxr --enable-libzmq --enable- libzimg --disable-libjack --disable-indev=jack --enable-videotoolbox --enable-audiotoolbox --enable-neon libavutil 59. 39.100 / 59. 39.100 libavcodec 61. 19.100 / 61. 19.100 libavformat 61. 7.100 / 61. 7.100 libavdevice 61. 3.100 / 61. 3.100 libavfilter 10. 4.100 / 10. 4.100 libswscale 8. 3.100 / 8. 3.100 libswresample 5. 3.100 / 5. 3.100 libpostproc 58. 3.100 / 58. 3.100 }}} {{{ Input #0, avfoundation, from ':0': Duration: N/A, start: 10114.532792, bitrate: 3072 kb/s Stream #0:0: Audio: pcm_f32le, 48000 Hz, stereo, flt, 3072 kb/s File 'output.wav' already exists. Overwrite? [y/N] y Stream mapping: Stream #0:0 -> #0:0 (copy) Output #0, wav, to 'output.wav': Metadata: ISFT : Lavf61.7.100 Stream #0:0: Audio: pcm_f32le ([3][0][0][0] / 0x0003), 48000 Hz, stereo, flt, 3072 kb/s Press [q] to stop, [?] for help size= 1792KiB time=00:00:07.71 bitrate=1903.5kbits/s speed=1.28x }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/11398> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 8

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

07 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 07 Jun '25

07 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

#11332(avformat:new): ffio_open_whitelist leaks memory
by FFmpeg 07 Jun '25

07 Jun '25

#11332: ffio_open_whitelist leaks memory ----------------------------------+---------------------------------- Reporter: oarfish | Type: defect Status: new | Priority: normal Component: avformat | Version: 7.1 Keywords: leak | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ----------------------------------+---------------------------------- I suspect that ffio_open_whitelist is leaking an URLContext. In this line, a context is declared https://github.com/FFmpeg/FFmpeg/blob/7c1e732ad2e240af5afe9ffea443c91bb233a… and then allocated by ffurl_open_whitelist at https://github.com/FFmpeg/FFmpeg/blob/7c1e732ad2e240af5afe9ffea443c91bb233a… However, I don't see it being freed anywhere. In my program, this causes the leak sanitizer to report a leak: {{{ Indirect leak of 234 byte(s) in 1 object(s) allocated from: #0 0x7faaaa89565f in __interceptor_posix_memalign ../../../../src/libsanitizer/lsan/lsan_interceptors.cpp:110 #1 0x557e4562f3df in av_malloc libavutil/mem.c:107 #2 0x557e4562f7f3 in av_mallocz libavutil/mem.c:258 #3 0x557e458b85d0 in url_alloc_for_protocol libavformat/avio.c:139 #4 0x557e458b9271 in ffurl_alloc libavformat/avio.c:356 #5 0x557e458b92e6 in ffurl_open_whitelist libavformat/avio.c:369 #6 0x557e458b988c in ffio_open_whitelist libavformat/avio.c:480 #7 0x557e4588b767 in io_open_default libavformat/options.c:153 #8 0x557e45875a27 in init_input libavformat/demux.c:178 #9 0x557e45875d35 in avformat_open_input libavformat/demux.c:248 }}} I did not manage to reproduce this repro this yet in a minimal executable, will update once i can. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11332> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 1

#11164(avcodec:new): visual macroblock error with mpeg2video encoding
by FFmpeg 06 Jun '25

06 Jun '25

#11164: visual macroblock error with mpeg2video encoding ------------------------------------+---------------------------------- Reporter: dave rice | Type: defect Status: new | Priority: normal Component: avcodec | Version: 6.1.1 Keywords: mpeg2video | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ------------------------------------+---------------------------------- Summary of the bug: I've been using ffmpeg to create XDCam QuickTime files and found a regression or change in going from ffmpeg 5 to 6. The simplest command I can create to demonstrate this problem is below. The ffmpeg@5 output looks fine and represents the input well, the ffmpeg@6 output shows some abundant macroblock errors. How to reproduce: This ffmpeg@5 output looks okay: {{{ % ffmpeg -y -i test.mp4 -c:v mpeg2video -non_linear_quant 1 -qmin 1 -pix_fmt yuv422p -vtag xd5b -q:v 1 -qmax 8 good.mov ffmpeg version 5.1.2 Copyright (c) 2000-2022 the FFmpeg developers built with Apple clang version 13.0.0 (clang-1300.0.29.30) configuration: --prefix=/usr/local/Cellar/ffmpeg/5.1.2_6 --enable-shared --enable-pthreads --enable-version3 --cc=clang --host-cflags= --host- ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libaribb24 --enable-libbluray --enable-libdav1d --enable- libmp3lame --enable-libopus --enable-librav1e --enable-librist --enable- librubberband --enable-libsnappy --enable-libsrt --enable-libsvtav1 --enable-libtesseract --enable-libtheora --enable-libvidstab --enable- libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable- libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable- libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable- libopenjpeg --enable-libspeex --enable-libsoxr --enable-libzmq --enable- libzimg --disable-libjack --disable-indev=jack --enable-videotoolbox libavutil 57. 28.100 / 57. 28.100 libavcodec 59. 37.100 / 59. 37.100 libavformat 59. 27.100 / 59. 27.100 libavdevice 59. 7.100 / 59. 7.100 libavfilter 8. 44.100 / 8. 44.100 libswscale 6. 7.100 / 6. 7.100 libswresample 4. 7.100 / 4. 7.100 libpostproc 56. 6.100 / 56. 6.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf60.16.100 Duration: 00:00:05.07, start: 0.000000, bitrate: 6680 kb/s Stream #0:0[0x1](eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1920x1080, 4908 kb/s, 23.98 fps, 23.98 tbr, 24k tbn (default) Metadata: handler_name : ?Mainconcept Video Media Handler vendor_id : [0][0][0][0] encoder : AVC Coding Stream #0:1[0x2](eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 189 kb/s (default) Metadata: handler_name : #Mainconcept MP4 Sound Media Handler vendor_id : [0][0][0][0] Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> mpeg2video (native)) Stream #0:1 -> #0:1 (aac (native) -> aac (native)) Press [q] to stop, [?] for help Output #0, mov, to 'good.mov': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf59.27.100 Stream #0:0(eng): Video: mpeg2video (4:2:2) (xd5b / 0x62356478), yuv422p(tv, bt709, progressive), 1920x1080, q=2-31, 200 kb/s, 23.98 fps, 24k tbn (default) Metadata: handler_name : ?Mainconcept Video Media Handler vendor_id : [0][0][0][0] encoder : Lavc59.37.100 mpeg2video Side data: cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: N/A Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default) Metadata: handler_name : #Mainconcept MP4 Sound Media Handler vendor_id : [0][0][0][0] encoder : Lavc59.37.100 aac frame= 121 fps=0.0 q=1.0 Lsize= 17383kB time=00:00:05.01 bitrate=28405.3kbits/s speed=11.9x video:17298kB audio:81kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.022841% [aac @ 0x7fc93af05d40] Qavg: 565.772 }}} This ffmpeg@6 output has visual artifacts. {{{ % ffmpeg -y -i test.mp4 -c:v mpeg2video -non_linear_quant 1 -qmin 1 -pix_fmt yuv422p -vtag xd5b -q:v 1 -qmax 8 bad.mov ffmpeg version 6.1.2 Copyright (c) 2000-2024 the FFmpeg developers built with Apple clang version 14.0.0 (clang-1400.0.29.202) configuration: --prefix='/opt/homebrew/Cellar/ffmpeg(a)6/6.1.2_1' --enable-shared --enable-pthreads --enable-version3 --cc=clang --host- cflags= --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libaribb24 --enable-libbluray --enable-libdav1d --enable-libharfbuzz --enable-libjxl --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librist --enable-librubberband --enable- libsnappy --enable-libsrt --enable-libssh --enable-libsvtav1 --enable- libtesseract --enable-libtheora --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable- libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopenvino --enable-libspeex --enable-libsoxr --enable-libzmq --enable-libzimg --disable-libjack --disable-indev=jack --enable- videotoolbox --enable-audiotoolbox --enable-neon libavutil 58. 29.100 / 58. 29.100 libavcodec 60. 31.102 / 60. 31.102 libavformat 60. 16.100 / 60. 16.100 libavdevice 60. 3.100 / 60. 3.100 libavfilter 9. 12.100 / 9. 12.100 libswscale 7. 5.100 / 7. 5.100 libswresample 4. 12.100 / 4. 12.100 libpostproc 57. 3.100 / 57. 3.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'test.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf60.16.100 Duration: 00:00:05.07, start: 0.000000, bitrate: 6680 kb/s Stream #0:0[0x1](eng): Video: h264 (Main) (avc1 / 0x31637661), yuv420p(tv, bt709, progressive), 1920x1080, 4908 kb/s, 23.98 fps, 23.98 tbr, 24k tbn (default) Metadata: handler_name : ?Mainconcept Video Media Handler vendor_id : [0][0][0][0] encoder : AVC Coding Stream #0:1[0x2](eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 189 kb/s (default) Metadata: handler_name : #Mainconcept MP4 Sound Media Handler vendor_id : [0][0][0][0] Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> mpeg2video (native)) Stream #0:1 -> #0:1 (aac (native) -> aac (native)) Press [q] to stop, [?] for help Output #0, mov, to 'bad.mov': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf60.16.100 Stream #0:0(eng): Video: mpeg2video (4:2:2) (xd5b / 0x62356478), yuv422p(tv, bt709, progressive), 1920x1080, q=2-31, 200 kb/s, 23.98 fps, 24k tbn (default) Metadata: handler_name : ?Mainconcept Video Media Handler vendor_id : [0][0][0][0] encoder : Lavc60.31.102 mpeg2video Side data: cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: N/A Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default) Metadata: handler_name : #Mainconcept MP4 Sound Media Handler vendor_id : [0][0][0][0] encoder : Lavc60.31.102 aac [out#0/mov @ 0x14a705d10] video:17378kB audio:82kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.022736% frame= 121 fps=0.0 q=1.0 Lsize= 17464kB time=00:00:04.99 bitrate=28658.8kbits/s speed=13.1x [aac @ 0x14a65b480] Qavg: 566.517 }}} Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11164> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 7

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

06 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