June 2025 - 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

Re: [FFmpeg-trac] #979(swscale:open): Abnormal colorspace conversion of BGR -> YUV comparing the RGB variant
by FFmpeg 08 Jun '25

08 Jun '25

#979: Abnormal colorspace conversion of BGR -> YUV comparing the RGB variant ------------------------------------+----------------------------------- Reporter: natt | Owner: (none) Type: defect | Status: open Priority: normal | Component: swscale Version: git-master | Resolution: Keywords: scale | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ------------------------------------+----------------------------------- Comment (by Balling): https://patchwork.ffmpeg.org/project/ffmpeg/patch/mailman.2596.1749417834.1… .ffmpeg-devel(a)ffmpeg.org/ Yay! -- Ticket URL: <https://trac.ffmpeg.org/ticket/979#comment:27> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

#11630(avcodec:new): Regression: hevcdec with videotoolbox hwaccel aborts on broken frames after commit 79afc45c03abfb7f1d9dc2cc758ec162bfade1a0
by FFmpeg 08 Jun '25

08 Jun '25

#11630: Regression: hevcdec with videotoolbox hwaccel aborts on broken frames after commit 79afc45c03abfb7f1d9dc2cc758ec162bfade1a0 -------------------------------------+------------------------------------- Reporter: gnattu | Type: defect Status: new | Priority: normal Component: avcodec | Version: git- Keywords: | master videotoolbox hevc | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: Since commit `79afc45c03abfb7f1d9dc2cc758ec162bfade1a0` (lavc/hevcdec: use a ContainerFifo to hold frames scheduled for output), the behavior of the HEVC decoder (`hevcdec`) with videotoolbox hardware acceleration has changed. When decoding input files that contain broken frames, the decoder now aborts early instead of continuing to decode subsequent good frames, as it did before. This is verified by bisecting from 7.0.2 to 7.1.1: {{{ 79afc45c03abfb7f1d9dc2cc758ec162bfade1a0 is the first bad commit commit 79afc45c03abfb7f1d9dc2cc758ec162bfade1a0 Author: Anton Khirnov <anton(a)khirnov.net> Date: Thu Jun 20 21:01:49 2024 +0200 lavc/hevcdec: use a ContainerFifo to hold frames scheduled for output Instead of a single AVFrame. Will be useful in future commits, where we will want to produce multiple output frames for a single coded frame. libavcodec/Makefile | 2 +- libavcodec/hevc/hevcdec.c | 31 +++++++++++++++++++++---------- libavcodec/hevc/hevcdec.h | 4 ++-- libavcodec/hevc/refs.c | 12 ++++-------- 4 files changed, 28 insertions(+), 21 deletions(-) }}} How to reproduce: 1. Download this sample, which contains broken frames at the beginning: https://drive.usercontent.google.com/download?id=1z5dRzJ1PMSTphUqXa379Ourm1… 2. Run the following command: {{{ ./ffmpeg -hide_banner -hwaccel videotoolbox -hwaccel_output_format videotoolbox_vld -i './LG Cymatic Jazz 4K Demo.ts' -vcodec h264_videotoolbox -an -sn -dn test.mp4 }}} You should observe the bug, where decoding aborts after encountering broken frames instead of continuing: {{{ [hevc @ 0x142e1e860] No frame decoded? [vist#0:0/hevc @ 0x144004b90] [dec:hevc @ 0x142e17820] Error submitting packet to decoder: Generic error in an external library [vist#0:0/hevc @ 0x144004b90] [dec:hevc @ 0x142e17820] Error submitting packet to decoder: Unknown error occurred [vist#0:0/hevc @ 0x144004b90] [dec:hevc @ 0x142e17820] A decoder returned an unexpected error code. This is a bug, please report it. [vist#0:0/hevc @ 0x144004b90] [dec:hevc @ 0x142e17820] Error processing packet in decoder: Internal bug, should not have happened [vist#0:0/hevc @ 0x144004b90] [dec:hevc @ 0x142e17820] Task finished with error code: -558323010 (Internal bug, should not have happened) [vist#0:0/hevc @ 0x144004b90] [dec:hevc @ 0x142e17820] Terminating thread with return code -558323010 (Internal bug, should not have happened) }}} In 7.0.2, it will continue decoding past the broken frames, despite the log is also flooded with decode errors: {{{ [hevc @ 0x150e1efa0] Could not find ref with POC 38 [hevc @ 0x150e175b0] vt decoder cb: output image buffer is null: -17694 [hevc @ 0x150e1efa0] hardware accelerator failed to decode picture [vist#0:0/hevc @ 0x150e08d30] [dec:hevc @ 0x150e16020] Error submitting packet to decoder: Unknown error occurred Last message repeated 7 times }}} A temporary workaround is to change line 127 of `videotoolbox.c` to not return `AVERROR_EXTERNAL` if no frame was decoded, but to return 0 after unreffing the frame. This allows decoding to continue with invalid frame warning: {{{ [hevc @ 0x11a604f40] An invalid frame was output by a decoder. This is a bug, please report it. }}} But this is probably not the best way to restore the old behavior, and therefore I created this ticket. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11630> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

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

07 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 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

#11494(avcodec:new): Encoding to ffv1 produces broken bitstream for specific sample with specific settings
by FFmpeg 06 Jun '25

06 Jun '25

#11494: Encoding to ffv1 produces broken bitstream for specific sample with specific settings -------------------------------------+------------------------------------- Reporter: Damian | Type: defect Höster | Status: new | Priority: normal Component: avcodec | Version: | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- **How to reproduce:** Download br2049-00006.mkv from here: https://mega.nz/file/UCw1AQ7D #-oQ_Hcob_VByBC-KSqvJ2xuV7GZkvkCJ-XOrU00zQeg Reencode like this: ffmpeg -i br2049-00006.mkv -vcodec ffv1 -pass 1 -coder 1 -context 1 -slices 24 -f null /dev/null && ffmpeg -i br2049-00006.mkv -vcodec ffv1 -pass 2 -coder 1 -context 1 -slices 24 broken-ffv1.mkv Then try to decode. I get errors like these: {{{ [ffv1 @ 0x57b2744be500] CRC mismatch F9B52803! }}} {{{ [vist#0:0/ffv1 @ 0x57b2744dec00] [dec:ffv1 @ 0x57b2744e0f40] Error while opening decoder: Invalid data found when processing input }}} ffmpeg version N-118655-g696ea1c223 on Arch Linux -- Ticket URL: <https://trac.ffmpeg.org/ticket/11494> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 1

#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

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

06 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

Re: [FFmpeg-trac] #1357(undetermined:closed): Memleak when avformat_open_input used together with avio_context
by FFmpeg 06 Jun '25

06 Jun '25

#1357: Memleak when avformat_open_input used together with avio_context -------------------------------------+------------------------------------- Reporter: xire | Owner: (none) Type: defect | Status: closed Priority: normal | Component: | undetermined Version: unspecified | Resolution: invalid Keywords: leak | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Changes (by mkver): * resolution: => invalid * status: new => closed Comment: Not a bug: When using custom IO via a preallocated AVIOContext, the user is supposed to free the AVIOContext himself (as you do (although this should be done via avio_context_free()) and this includes freeing the corresponding read buffer (which you only free if one uncomments these three lines which makes the leak go away). -- Ticket URL: <https://trac.ffmpeg.org/ticket/1357#comment:2> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0