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

#11674(undetermined:new): Cuda sometimes outputs green line
by FFmpeg 23 Jul '25

23 Jul '25

#11674: Cuda sometimes outputs green line -------------------------------------+------------------------------------- Reporter: Jason Dove | Type: defect Status: new | Priority: normal Component: | Version: git- undetermined | master Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: Sometimes when overlaying content using overlay_cuda, there is a green line at the bottom of the output, and the output height is 1088 instead of 1080. Using a software decoder avoids the issue, using a software encoder avoids the issue, and for whatever reason seeking .001 seconds into the test input (before -i) also avoids the issue. How to reproduce: {{{ % ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i https://test- videos.co.uk/vids/bigbuckbunny/mp4/h264/1080/Big_Buck_Bunny_1080_10s_5MB.mp4 -i https://peach.blender.org/wp-content/themes/bf- bunny/graphics/header1.jpg -filter_complex '[0:0]scale_cuda=format=yuv420p[v];[1:0]hwupload_cuda[wm];[v][wm]overlay_cuda[ov]' -map '[ov]' -t 00:00:05 -c:v h264_nvenc -y green-line.mkv ffmpeg version N-120352-gda18c2a373-20250722 Copyright (c) 2000-2025 the FFmpeg developers built with gcc 15.1.0 (crosstool-NG 1.27.0.42_35c1e72) configuration: --prefix=/ffbuild/prefix --pkg-config-flags=--static --pkg- config=pkg-config --cross-prefix=x86_64-ffbuild-linux-gnu- --arch=x86_64 --target-os=linux --enable-gpl --enable-version3 --disable-debug --enable- iconv --enable-zlib --enable-libfribidi --enable-gmp --enable-libxml2 --enable-openssl --enable-lzma --enable-fontconfig --enable-libharfbuzz --enable-libfreetype --enable-libvorbis --enable-opencl --enable-libpulse --enable-libvmaf --enable-libxcb --enable-xlib --enable-amf --enable- libaom --enable-libaribb24 --enable-avisynth --enable-chromaprint --enable-libdav1d --enable-libdavs2 --enable-libdvdread --enable-libdvdnav --disable-libfdk-aac --enable-ffnvcodec --enable-cuda-llvm --enable-frei0r --enable-libgme --enable-libkvazaar --enable-libaribcaption --enable- libass --enable-libbluray --enable-libjxl --enable-libmp3lame --enable- libopus --enable-librist --enable-libssh --enable-libtheora --enable- libvpx --enable-libwebp --enable-libzmq --enable-lv2 --enable-libvpl --enable-openal --enable-liboapv --enable-libopencore-amrnb --enable- libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable- libopenmpt --enable-librav1e --enable-librubberband --disable-schannel --enable-sdl2 --enable-libsnappy --enable-libsoxr --enable-libsrt --enable-libsvtav1 --enable-libtwolame --enable-libuavs3d --enable-libdrm --enable-vaapi --enable-libvidstab --enable-vulkan --enable-libshaderc --enable-libplacebo --enable-libvvenc --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libzimg --enable-libzvbi --extra-cflags=-DLIBTWOLAME_STATIC --extra-cxxflags= --extra-libs='-ldl -lgomp' --extra-ldflags=-pthread --extra-ldexeflags=-pie --cc=x86_64 -ffbuild-linux-gnu-gcc --cxx=x86_64-ffbuild-linux-gnu-g++ --ar=x86_64 -ffbuild-linux-gnu-gcc-ar --ranlib=x86_64-ffbuild-linux-gnu-gcc-ranlib --nm=x86_64-ffbuild-linux-gnu-gcc-nm --extra-version=20250722 libavutil 60. 6.100 / 60. 6.100 libavcodec 62. 8.100 / 62. 8.100 libavformat 62. 1.103 / 62. 1.103 libavdevice 62. 0.100 / 62. 0.100 libavfilter 11. 3.100 / 11. 3.100 libswscale 9. 0.100 / 9. 0.100 libswresample 6. 0.100 / 6. 0.100 }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/11674> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 6

#11660(ffmpeg:new): Importing ffmetadata file into MP4 supports chapters but ignores global tags
by FFmpeg 22 Jul '25

22 Jul '25

#11660: Importing ffmetadata file into MP4 supports chapters but ignores global tags ------------------------------------+-------------------------------------- Reporter: LigH | Type: defect Status: new | Priority: normal Component: ffmpeg | Version: git-master Keywords: ffmetadata | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ------------------------------------+-------------------------------------- Summary of the bug: I can add an ffmetadata file to an MP4 file to include movie chapters. But global tags for the whole movie, like title and comment, in the same file are not added. How to reproduce: (Windows 10 64bit) > qaac64 -V 64 -q 1 -o PAL.m4a PAL.avs > x264 --crf 25 --preset slow --nr 500 --colormatrix bt709 --transfer bt709 --colorprim bt709 --qpfile PAL.qp -o PAL.v.mp4 PAL.avs > ren PAL.v.mp4 PAL.m4v > ffmpeg -i PAL.m4v -i PAL.m4a -i PAL.ffmetadata -map_metadata 1 -c:v copy -c:a copy -movflags +faststart PAL.mp4 Chapters are read from the file PAL.ffmetadata, successfully inserted in the MP4 file, media players can handle the chapters (the "Menu" entry is reported even **twice** - is that necessary at all?), but global tags "title" and "comment" in the same file are ignored. Sample files and some console outputs (analysis logs by "MediaInfo -f" and "MP4Box -infox") are attached in a ZIP archive. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11660> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 4

#11672(avcodec:new): [bug] colorspace bt709 error for ycgco
by FFmpeg 22 Jul '25

22 Jul '25

#11672: [bug] colorspace bt709 error for ycgco ------------------------------------+------------------------------------- Reporter: von | Type: defect Status: new | Priority: important Component: avcodec | Version: 7.1 Keywords: colorspace | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ------------------------------------+------------------------------------- ffmpeg 7.1.1 command: {{{ ./ffmpeg7 -y -i de.mp4 -colorspace bt709 -an -f mp4 de-264.mp4 }}} de.mp4: {{{ color_range=tv color_space=ycgco color_primaries=bt709 color_transfer=bt709 }}} get error: {{{ Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto_scale_0' [vf#0:0 @ 0x558741629500] Error reinitializing filters! [vf#0:0 @ 0x558741629500] Task finished with error code: -38 (Function not implemented) [vf#0:0 @ 0x558741629500] Terminating thread with return code -38 (Function not implemented) [vost#0:0/libx264 @ 0x55874165c440] Could not open encoder before EOF [vost#0:0/libx264 @ 0x55874165c440] Task finished with error code: -22 (Invalid argument) [vost#0:0/libx264 @ 0x55874165c440] Terminating thread with return code -22 (Invalid argument) [out#0/mp4 @ 0x55874161db40] Nothing was written into output file, because at least one of its streams received no packets. frame= 0 fps=0.0 q=0.0 Lsize= 0KiB time=N/A bitrate=N/A speed=N/A Conversion failed! }}} If I remove -colorspace bt709, this works fine. Please someone help me. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11672> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 3

#11668(undetermined:new): Audio being much longer than video will make -shortest clamp to 1 second
by FFmpeg 21 Jul '25

21 Jul '25

#11668: Audio being much longer than video will make -shortest clamp to 1 second --------------------------------------+---------------------------------- Reporter: RavenWorks | Type: defect Status: new | Priority: normal Component: undetermined | Version: 7.1 Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | --------------------------------------+---------------------------------- Summary of the bug: Feeding (for example) a 0.15 sec video file and a 50 sec audio file into ffmpeg with -shortest will produce a 1 sec file (a length that doesn't correspond to EITHER input). Notably though, a 0.15 sec video and **5** sec audio will give the correct output (0.15 sec file). I first encountered this with anullsrc for the audio source, but I reproduced it with regular wav files just to be certain that it wasn't something about anullsrc in particular. Don't mind the fact that I'm recompressing the video for nothing in this example; in the original context I need to be recompressing the video for unrelated reasons (and, notably, the bug *doesn't* occur when using -c:v copy.) It might be hard to even see the video files in VLC due to their shortness; MPV and Firefox can both loop them fine. How to reproduce: {{{ % ffmpeg -y -i .\50sec.wav -i .\no_audio.mp4 -shortest silent_audio.mp4 ffmpeg version 7.1.1-full_build-www.gyan.dev Copyright (c) 2000-2025 the FFmpeg developers built with gcc 14.2.0 (Rev1, Built by MSYS2 project) configuration: --enable-gpl --enable-version3 --enable-static --disable- w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-lcms2 --enable-libxml2 --enable-gmp --enable- bzlib --enable-lzma --enable-libsnappy --enable-zlib --enable-librist --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-libbluray --enable-libcaca --enable-libdvdnav --enable-libdvdread --enable-sdl2 --enable-libaribb24 --enable-libaribcaption --enable- libdav1d --enable-libdavs2 --enable-libopenjpeg --enable-libquirc --enable-libuavs3d --enable-libxevd --enable-libzvbi --enable-libqrencode --enable-librav1e --enable-libsvtav1 --enable-libvvenc --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxeve --enable-libxvid --enable-libaom --enable-libjxl --enable-libvpx --enable- mediafoundation --enable-libass --enable-frei0r --enable-libfreetype --enable-libfribidi --enable-libharfbuzz --enable-liblensfun --enable- libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda- llvm --enable-cuvid --enable-dxva2 --enable-d3d11va --enable-d3d12va --enable-ffnvcodec --enable-libvpl --enable-nvdec --enable-nvenc --enable- vaapi --enable-libshaderc --enable-vulkan --enable-libplacebo --enable- opencl --enable-libcdio --enable-libgme --enable-libmodplug --enable- libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable- libshine --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libcodec2 --enable-libilbc --enable-libgsm --enable-liblc3 --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable- libvorbis --enable-ladspa --enable-libbs2b --enable-libflite --enable- libmysofa --enable-librubberband --enable-libsoxr --enable-chromaprint libavutil 59. 39.100 / 59. 39.100 libavcodec 61. 19.101 / 61. 19.101 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 [aist#0:0/pcm_s16le @ 000001cccab59200] Guessed Channel Layout: mono Input #0, wav, from '.\50sec.wav': Duration: 00:00:50.00, bitrate: 705 kb/s Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, mono, s16, 705 kb/s Input #1, mov,mp4,m4a,3gp,3g2,mj2, from '.\no_audio.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf61.7.100 Duration: 00:00:00.15, start: 0.000000, bitrate: 157 kb/s Stream #1:0[0x1](und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p(progressive), 256x64, 110 kb/s, 60 fps, 60 tbr, 15360 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0] encoder : Lavc61.19.101 libx264 Stream mapping: Stream #1:0 -> #0:0 (h264 (native) -> h264 (libx264)) Stream #0:0 -> #0:1 (pcm_s16le (native) -> aac (native)) Press [q] to stop, [?] for help [libx264 @ 000001cccaac7e00] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 [libx264 @ 000001cccaac7e00] profile High, level 1.2, 4:2:0, 8-bit [libx264 @ 000001cccaac7e00] 264 - core 164 r3204 373697b - H.264/MPEG-4 AVC codec - Copyleft 2003-2025 - http://www.videolan.org/x264.html - options: cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1 psy_rd=1.00:0.00 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-2 threads=2 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40 intra_refresh=0 rc_lookahead=40 rc=crf mbtree=1 crf=23.0 qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00 Output #0, mp4, to 'silent_audio.mp4': Metadata: encoder : Lavf61.7.100 Stream #0:0(und): Video: h264 (avc1 / 0x31637661), yuv420p(tv, progressive), 256x64, q=2-31, 60 fps, 15360 tbn (default) Metadata: handler_name : VideoHandler vendor_id : [0][0][0][0] encoder : Lavc61.19.101 libx264 Side data: cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A Stream #0:1: Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, mono, fltp, 69 kb/s Metadata: encoder : Lavc61.19.101 aac [out#0/mp4 @ 000001cccaabf1c0] video:2KiB audio:9KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: 15.732564% frame= 9 fps=0.0 q=-1.0 Lsize= 13KiB time=00:00:00.11 bitrate= 880.7kbits/s speed=5.52x [libx264 @ 000001cccaac7e00] frame I:4 Avg QP:31.54 size: 243 [libx264 @ 000001cccaac7e00] frame P:5 Avg QP:22.03 size: 71 [libx264 @ 000001cccaac7e00] mb I I16..4: 11.7% 74.6% 13.7% [libx264 @ 000001cccaac7e00] mb P I16..4: 0.0% 2.8% 3.4% P16..4: 4.7% 0.0% 0.0% 0.0% 0.0% skip:89.1% [libx264 @ 000001cccaac7e00] 8x8 transform intra:72.5% inter:100.0% [libx264 @ 000001cccaac7e00] coded y,uvDC,uvAC intra: 8.5% 0.0% 0.0% inter: 0.2% 0.0% 0.0% [libx264 @ 000001cccaac7e00] i16 v,h,dc,p: 10% 0% 90% 0% [libx264 @ 000001cccaac7e00] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 45% 1% 53% 1% 0% 0% 0% 0% 0% [libx264 @ 000001cccaac7e00] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 16% 21% 38% 8% 3% 3% 3% 4% 4% [libx264 @ 000001cccaac7e00] i8c dc,h,v,p: 100% 0% 0% 0% [libx264 @ 000001cccaac7e00] Weighted P-Frames: Y:0.0% UV:0.0% [libx264 @ 000001cccaac7e00] ref P L0: 46.7% 0.0% 26.7% 26.7% [libx264 @ 000001cccaac7e00] kb/s:70.93 [aac @ 000001cccb099ac0] Qavg: 32.825 }}} And just to be clear: {{{ % ffmpeg -y -i .\5sec.wav -i .\no_audio.mp4 -shortest silent_audio.mp4 }}} produces an output that is NOT bugged (provided to demonstrate that the problem seems to be related to audio length). -- Ticket URL: <https://trac.ffmpeg.org/ticket/11668> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 11

#8349(avcodec:new): Dolby AC-4 Support
by FFmpeg 21 Jul '25

21 Jul '25

#8349: Dolby AC-4 Support ----------------------------------+--------------------------------------- Reporter: Nomis101 | Type: enhancement Status: new | Priority: normal Component: avcodec | Version: git-master Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ----------------------------------+--------------------------------------- It would be nice to support the detection, muxing and demuxing of Dolby AC-4 audio streams (in MP4 and MKV). Information: https://dolbyac4.com/ Specs: https://www.dolby.com/us/en/technologies/ac-4/Next-Generation- Entertainment-Services.pdf Sample files: http://testassets.dashif.org/#testcase/details/586fb3879ae9045678eab64f MediaInfo 19.09 added support for AC-4, so it would be nice to have support in FFmpeg as well. https://mediaarea.net/MediaInfo/ChangeLog -- Ticket URL: <https://trac.ffmpeg.org/ticket/8349> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 102

#11268(undetermined:new): -use_wallclock_as_timestamps 1 not working with piped input
by FFmpeg 20 Jul '25

20 Jul '25

#11268: -use_wallclock_as_timestamps 1 not working with piped input -------------------------------------+------------------------------------- Reporter: Wes Castro | Type: defect Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: When piping a raw H264 stream to FFmpeg with `-use_wallclock_as_timestamps 1`, wallclock times are not used. If the pipe is opened for say 10 seconds, it's expected that the output's duration will be ~10 seconds. Instead it seems to use timing info from the input stream. I didn't test with other types of piped inputs The issue was introduced in FFmpeg 6.1 and repros on the master branch. How to reproduce: {{{ ffmpeg -y -f lavfi -i testsrc=duration=1:size=1280x720:rate=30 -f h264 ~/1second.h264 (cat ~/1second.h264; sleep 10; cat ~/1second.h264) | ffmpeg -use_wallclock_as_timestamps 1 -i pipe: -f mp4 ~/test.mp4 -y }}} Here are the durations reported by FFprobe when using various FFmpeg versions for the second line: * FFmpeg 6.0: 11.5s * FFmpeg 6.1: 2.0s * FFmpeg 7.1: 2.0s * master branch (08b1bffa49715a9615acc025dfbea252d8409e1f): 2.0s -- Ticket URL: <https://trac.ffmpeg.org/ticket/11268> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 3

#11217(ffmpeg:new): -ss causing a substantial memory increase
by FFmpeg 19 Jul '25

19 Jul '25

#11217: -ss causing a substantial memory increase -------------------------------------+------------------------------------- Reporter: Bryce | Type: defect Chester Newman | Status: new | Priority: important Component: ffmpeg | Version: 7.1 Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: There appears to be a behavior change or bug introduced between FFmpeg 6.1 and 7.0/7.1 when using the “-ss” argument that is causing a substantial memory increase. Running the command below using FFmpeg 6.1 memory usage is about 500MB – which is expected. Running the command below using FFmpeg 7.0/7.1 memory usage is about 3GB – which is not expected. If I remove the “-ss” argument when running on FFmepg 7.0 or 7.1 the memory footprint is the same as 6.1. I can reproduce this on Linux(Ubuntu) and Apple M2. I can reproduce the memory increase using .mxf, mov and .mp4 as an input file. How to reproduce: {{{ ffmpeg -report -v 9 -loglevel 99 -y -i 1951279840.mov \ -filter_complex "[0:v:0]scale='768:432':force_original_aspect_ratio=decrease:force_divisible_by=2[jpg-600];[0:v:0]scale='1280:640'[mp4-640]" \ -map "[jpg-600]" -ss 67 -f image2 -q:v 5 -update 1 -frames:v 1 /tmp/jpg-600-123456.jpg \ -map "[mp4-640]" -map_metadata -1 -f mp4 -vcodec libx264 -profile:v main -level 3.1 -crf 23 -b:v 2500K -movflags faststart -refs 4 -pix_fmt yuv420p -color_primaries bt709 -color_trc bt709 -colorspace bt709 -preset medium /tmp/mp4-640-23456.mp4 }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/11217> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 36

#11673(avformat:new): Incorrect written MP4 Sample Description Entry for DTS codec family
by FFmpeg 18 Jul '25

18 Jul '25

#11673: Incorrect written MP4 Sample Description Entry for DTS codec family -------------------------------------+------------------------------------- Reporter: rix | Type: defect Status: new | Priority: normal Component: avformat | Version: | unspecified Keywords: DTS mp4 mov | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: According to ETSI TS 102 114 Annex E, and ETSI TS 103 491 Annex B, DTS codec family should be signaled with specific Sample Description Entry boxes and DTSSpecificBox. FFmpeg currently does not produce files conforming to these specs, making these files unplayable on playback systems following the spec. Please refer to ETSI TS 102 114 Table E-1 and ETSI TS 103 491 Table B-1 for the Sample Description Entry tag mapping for different DST codecs. How to reproduce: {{{ % ffmpeg -i https://fate-suite.ffmpeg.org/dts/dts.ts -c:a copy dts.mp4 }}} Inspect the resulting MP4 shows the Sample Description Entry has {{{mp4a}}} tag instead of {{{dtsc}}}, and no {{ddts}} box. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11673> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

#11669(undetermined:new): Compatibility issue with RTMP push from Dahua cameras
by FFmpeg 16 Jul '25

16 Jul '25

#11669: Compatibility issue with RTMP push from Dahua cameras -------------------------------------+------------------------------------- Reporter: mms | Type: defect Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: RTMP dahua | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: Dahua cameras do not send a videocodecid in the RTMP handshake metadata. FFMPEG in -listen mode currently fails to accept video streams from these cameras, it disconnects. This would be a workaround fix. When videocodecid is missing, one simple workaround is to check for width metadata which the camera does send and proceed as if the videocodecid was sent, assuming h264. This was done with this library, line 35 reader.go: https://github.com/bluenviron/mediamtx/pull/2298/commits/1d5994e75f3668e154… Perhaps a way for ffmpeg to take parameters and run in a non-strict mode, taking default values hints for codec from the command line would be best general solution. No ideal solution here, in the end it means millions of cameras out there (that will not be updated) are unusable with ffmpeg. How to reproduce: Run ffmpeg in -listen mode for rtmp connections and watch the connection drop right away when a Dahua camera connects. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11669> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 5

#11418(undetermined:new): stack-buffer-overflow on libavcodec/aacenc_tns.c
by FFmpeg 15 Jul '25

15 Jul '25

#11418: stack-buffer-overflow on libavcodec/aacenc_tns.c -------------------------------------+------------------------------------- Reporter: 0x20z | Type: defect Status: new | Priority: important Component: | Version: git- undetermined | master Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: {{{ I have discovered a stack-buffer-overflow vulnerability. The POC file is attached to the session, and the version of ffmpeg is the main branch. Please confirm. }}} How to reproduce: {{{ git clone https://github.com/FFmpeg/FFmpeg.git cd FFmpeg ./configure --cc=clang --cxx=clang++ --toolchain=clang-asan --extra- cflags="-I$HOME/ffmpeg_build/include -O0 -fno-omit-frame-pointer -g" --extra-cxxflags="-O0 -fno-omit-frame-pointer -g" --extra- ldflags="-L$HOME/ffmpeg_build/include -fsanitize=address -fsanitize=undefined -lubsan" --disable-optimizations --disable-stripping --enable-cross-compile make -j30 ./ffmpeg -i poc -aac_pred true -profile:a aac_low output.mpd }}} log： {{{ ================================================================= ==1108156==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f286b5fe998 at pc 0x572aadc11f35 bp 0x7f286b5fe8e0 sp 0x7f286b5fe8d0 READ of size 4 at 0x7f286b5fe998 thread T1 (enc0:0:aac) #0 0x572aadc11f34 in ff_aac_search_for_tns libavcodec/aacenc_tns.c:204 #1 0x572aacede67e in aac_encode_frame libavcodec/aacenc.c:1020 #2 0x572aaaa197e2 in ff_encode_encode_cb libavcodec/encode.c:254 #3 0x572aaaa1b896 in encode_simple_internal libavcodec/encode.c:340 #4 0x572aaaa1bbfb in encode_simple_receive_packet libavcodec/encode.c:354 #5 0x572aaaa1cb13 in encode_receive_packet_internal libavcodec/encode.c:388 #6 0x572aaaa1e97e in avcodec_send_frame libavcodec/encode.c:531 #7 0x572aa7edbe65 in encode_frame fftools/ffmpeg_enc.c:643 #8 0x572aa7edf861 in frame_encode fftools/ffmpeg_enc.c:812 #9 0x572aa7ee0a09 in encoder_thread fftools/ffmpeg_enc.c:899 #10 0x572aa7fb17b2 in task_wrapper fftools/ffmpeg_sched.c:2534 #11 0x7f286f094ac2 in start_thread nptl/pthread_create.c:442 #12 0x7f286f12684f (/usr/lib/x86_64-linux-gnu/libc.so.6+0x12684f) Address 0x7f286b5fe998 is located in stack of thread T1 (enc0:0:aac) at offset 40 in frame #0 0x572aadc1038a in ff_aac_search_for_tns libavcodec/aacenc_tns.c:162 This frame has 2 object(s): [32, 40) 'en' (line 183) <== Memory access at offset 40 overflows this variable [64, 320) 'coefs' (line 165) HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp and C++ exceptions *are* supported) Thread T1 (enc0:0:aac) created by T0 here: #0 0x7f286fc58685 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cpp:216 #1 0x572aa7f8ad4b in task_start fftools/ffmpeg_sched.c:414 #2 0x572aa7fa09d7 in sch_start fftools/ffmpeg_sched.c:1615 #3 0x572aa8006dea in transcode fftools/ffmpeg.c:864 #4 0x572aa80081a8 in main fftools/ffmpeg.c:992 #5 0x7f286f029d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58 SUMMARY: AddressSanitizer: stack-buffer-overflow libavcodec/aacenc_tns.c:204 in ff_aac_search_for_tns }}} Found by： {{{ 0x20z }}} Thank you for your time and attention -- Ticket URL: <https://trac.ffmpeg.org/ticket/11418> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 6