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

#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

#10742(ffmpeg:new): Add Wayland/Pipewire support for Screen Recording
by FFmpeg 25 May '25

25 May '25

#10742: Add Wayland/Pipewire support for Screen Recording -------------------------------------+------------------------------------- Reporter: Lucas | Type: Varsky | enhancement Status: new | Priority: important Component: ffmpeg | Version: | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Ffmpeg's screen recording capabilities are in my experience the most efficient on Linux, allowing under-powered devices such as laptops to screen record effectively. But this functionality is hampered by being X11 only due to using x11grab and probably more technical parts I'm not aware of. I am a user, not a developer, I'm sure I missed technical details, eitherway. This is the ideal moment for adding support for screen recording using the Linux Wayland stack (Pipewire, XDG Portals) as most Linux developers are desperate to complete the migration from X11 to Wayland, going as far as removing X11 from Fedora KDE in the next version. They feel it's ready for widespread use and time for porting is running out before bug trackers get flooded with bug reports. The current behavior of screen recording with ffmpeg on wayland is a black screen as output. -- Ticket URL: <https://trac.ffmpeg.org/ticket/10742> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 3

#4448(avformat:new): Properly support cover art in ogg
by FFmpeg 22 May '25

22 May '25

#4448: Properly support cover art in ogg --------------------------------------+---------------------------------- Reporter: llogan | Owner: Type: defect | Status: new Priority: normal | Component: avformat Version: git-master | Keywords: ogg Blocked By: | Blocking: Reproduced by developer: 0 | Analyzed by developer: 0 --------------------------------------+---------------------------------- {{{ $ ./ffmpeg -i ../fate-suite/cover_art/cover_art.flac ../out.ogg ffmpeg version N-71319-g43b4342 Copyright (c) 2000-2015 the FFmpeg developers built with gcc 4.9.2 (GCC) 20150304 (prerelease) configuration: --enable-gpl --disable-doc libavutil 54. 22.100 / 54. 22.100 libavcodec 56. 34.100 / 56. 34.100 libavformat 56. 29.100 / 56. 29.100 libavdevice 56. 4.100 / 56. 4.100 libavfilter 5. 13.101 / 5. 13.101 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 1.100 / 1. 1.100 libpostproc 53. 3.100 / 53. 3.100 Input #0, flac, from '../fate-suite/cover_art/cover_art.flac': Metadata: RATING : 0 ALBUM : Ангелофрения ARTIST : Мельница TITLE : Дороги TRACKTOTAL : 11 TOTALTRACKS : 11 GENRE : Folk DATE : 2012 track : 2 Duration: 00:03:09.05, start: 0.000000, bitrate: 1 kb/s Stream #0:0: Audio: flac, 44100 Hz, stereo, s16 Stream #0:1: Video: mjpeg, yuvj420p(pc, bt470bg/unknown/unknown), 350x350 [SAR 1:1 DAR 1:1], 90k tbr, 90k tbn, 90k tbc Metadata: comment : Other Output #0, ogg, to '../out.ogg': Metadata: RATING : 0 ALBUM : Ангелофрения ARTIST : Мельница TITLE : Дороги TRACKTOTAL : 11 TOTALTRACKS : 11 GENRE : Folk DATE : 2012 track : 2 Stream #0:0: Video: theora, none, q=2-31, 128 kb/s Metadata: comment : Other Stream #0:1: Audio: flac, 0 channels, 128 kb/s Stream mapping: Stream #0:1 -> #0:0 (mjpeg (native) -> ? (?)) Stream #0:0 -> #0:1 (flac (native) -> flac (native)) Encoder (codec theora) not found for output stream #0:0 }}} Of course if Theora is supported by the build then a Theora video stream will be outputted (90k frame rate in this case). Possibly related to #4442 since I assume the cover art mechanics would be similar: https://wiki.xiph.org/VorbisComment#Cover_art -- Ticket URL: <https://trac.ffmpeg.org/ticket/4448> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 15

#10668(avcodec:new): cuvid regression creates jerky output
by FFmpeg 21 May '25

21 May '25

#10668: cuvid regression creates jerky output -------------------------------------+------------------------------------- Reporter: Jason Dove | Type: defect Status: new | Priority: important Component: avcodec | Version: git- Keywords: cuvid | master decoder nvidia | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: Using the h264_cuvid decoder with certain content will cause the output to be jerky. How to reproduce: {{{ % ffmpeg -c:v h264_cuvid -i input.mkv -c:v libx264 -y output.mkv ffmpeg version N-112777-g08e97dae20 Copyright (c) 2000-2023 the FFmpeg developers built with gcc 13.2.1 (GCC) 20230801 configuration: --prefix=/usr --extra-cflags=-I/opt/cuda/include --extra- ldflags=-L/opt/cuda/lib64 --enable-lto --disable-rpath --enable-gpl --enable-version3 --enable-nonfree --enable-shared --disable-static --disable-stripping --disable-htmlpages --enable-gray --enable-alsa --enable-avisynth --enable-bzlib --enable-chromaprint --enable-frei0r --enable-gcrypt --enable-gmp --enable-gnutls --enable-iconv --enable- ladspa --enable-lcms2 --enable-libaom --enable-libaribb24 --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcelt --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libdavs2 --enable-libdc1394 --enable-libfdk-aac --enable-libflite --enable- libfontconfig --enable-libfreetype --enable-libfribidi --enable- libharfbuzz --enable-libglslang --enable-libgme --enable-libgsm --enable- libiec61883 --enable-libilbc --enable-libjack --enable-libjxl --enable- libklvanc --enable-libkvazaar --enable-liblensfun --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --disable-libopencv --enable-libopenh264 --enable-libopenjpeg --enable- libopenmpt --enable-libopenvino --enable-libopus --enable-libplacebo --enable-libpulse --enable-librabbitmq --enable-librav1e --enable-librist --enable-librsvg --enable-librubberband --enable-librtmp --enable-libshine --enable-libsmbclient --enable-libsnappy --enable-libsoxr --enable- libspeex --enable-libsrt --enable-libssh --enable-libsvtav1 --enable- libsvthevc --enable-libsvtvp9 --disable-libtensorflow --enable- libtesseract --enable-libtheora --disable-libtls --enable-libtwolame --enable-libuavs3d --enable-libv4l2 --enable-libvidstab --enable-libvmaf --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable- libwebp --enable-libx264 --enable-libx265 --enable-libxavs --enable- libxavs2 --enable-libxcb --enable-libxcb-shm --enable-libxcb-xfixes --enable-libxcb-shape --enable-libxvid --enable-libxml2 --enable-libzimg --enable-libzmq --enable-libzvbi --enable-lv2 --enable-lzma --enable- decklink --disable-mbedtls --enable-libmysofa --enable-openal --enable- opencl --enable-opengl --disable-openssl --disable-pocketsphinx --enable- sndio --enable-sdl2 --enable-vapoursynth --enable-vulkan --enable-xlib --enable-zlib --enable-amf --enable-cuda-nvcc --enable-cuda-llvm --enable- cuvid --enable-ffnvcodec --enable-libdrm --enable-libvpl --enable-libnpp --enable-nvdec --enable-nvenc --enable-omx --enable-rkmpp --enable- v4l2-m2m --enable-vaapi --enable-vdpau libavutil 58. 32.100 / 58. 32.100 libavcodec 60. 33.100 / 60. 33.100 libavformat 60. 17.100 / 60. 17.100 libavdevice 60. 4.100 / 60. 4.100 libavfilter 9. 13.100 / 9. 13.100 libswscale 7. 6.100 / 7. 6.100 libswresample 4. 13.100 / 4. 13.100 libpostproc 57. 4.100 / 57. 4.100 Input #0, matroska,webm, from 'input.mkv': Metadata: ENCODER : Lavf60.17.100 Duration: 00:00:20.25, start: 0.000000, bitrate: 5560 kb/s Stream #0:0: Video: h264 (Main), yuv420p(tv, bt709, progressive), 1918x814 [SAR 1:1 DAR 959:407], 23.98 fps, 23.98 tbr, 1k tbn (default) Metadata: DURATION : 00:00:20.250000000 Stream #0:1: Audio: aac (LC), 48000 Hz, stereo, fltp (default) Metadata: DURATION : 00:00:20.031000000 Stream mapping: Stream #0:0 -> #0:0 (h264 (h264_cuvid) -> h264 (libx264)) Stream #0:1 -> #0:1 (aac (native) -> vorbis (libvorbis)) Press [q] to stop, [?] for help [libx264 @ 0x55640793d640] using SAR=1/1 [libx264 @ 0x55640793d640] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2 [libx264 @ 0x55640793d640] profile High, level 4.0, 4:2:0, 8-bit [libx264 @ 0x55640793d640] 264 - core 164 r3108 31e19f9 - H.264/MPEG-4 AVC codec - Copyleft 2003-2023 - 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=18 lookahead_threads=3 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=23 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, matroska, to 'output.mkv': Metadata: encoder : Lavf60.17.100 Stream #0:0: Video: h264 (H264 / 0x34363248), nv12(tv, bt709, progressive), 1918x814 [SAR 1:1 DAR 959:407], q=2-31, 23.98 fps, 1k tbn (default) Metadata: DURATION : 00:00:20.250000000 encoder : Lavc60.33.100 libx264 Side data: cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A Stream #0:1: Audio: vorbis (oV[0][0] / 0x566F), 48000 Hz, stereo, fltp (default) Metadata: DURATION : 00:00:20.031000000 encoder : Lavc60.33.100 libvorbis [out#0/matroska @ 0x556407921100] video:5317kB audio:191kB subtitle:0kB other streams:0kB global headers:4kB muxing overhead: 0.264545% frame= 482 fps= 75 q=-1.0 Lsize= 5523kB time=00:00:20.02 bitrate=2259.5kbits/s speed=3.11x [libx264 @ 0x55640793d640] frame I:15 Avg QP:18.37 size: 29181 [libx264 @ 0x55640793d640] frame P:307 Avg QP:20.27 size: 14622 [libx264 @ 0x55640793d640] frame B:160 Avg QP:17.28 size: 3236 [libx264 @ 0x55640793d640] consecutive B-frames: 53.5% 5.4% 3.7% 37.3% [libx264 @ 0x55640793d640] mb I I16..4: 43.4% 53.1% 3.5% [libx264 @ 0x55640793d640] mb P I16..4: 10.8% 20.1% 0.2% P16..4: 39.2% 3.2% 3.1% 0.0% 0.0% skip:23.3% [libx264 @ 0x55640793d640] mb B I16..4: 1.8% 2.0% 0.0% B16..8: 13.9% 1.0% 0.1% direct: 3.2% skip:78.0% L0:58.0% L1:41.1% BI: 0.9% [libx264 @ 0x55640793d640] 8x8 transform intra:62.3% inter:93.8% [libx264 @ 0x55640793d640] coded y,uvDC,uvAC intra: 27.7% 53.5% 3.0% inter: 10.0% 27.8% 0.0% [libx264 @ 0x55640793d640] i16 v,h,dc,p: 29% 33% 17% 21% [libx264 @ 0x55640793d640] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 19% 46% 2% 2% 2% 3% 2% 2% [libx264 @ 0x55640793d640] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 27% 21% 3% 6% 5% 7% 3% 2% [libx264 @ 0x55640793d640] i8c dc,h,v,p: 52% 25% 21% 2% [libx264 @ 0x55640793d640] Weighted P-Frames: Y:9.1% UV:4.9% [libx264 @ 0x55640793d640] ref P L0: 41.1% 4.1% 26.2% 26.1% 2.4% [libx264 @ 0x55640793d640] ref B L0: 55.2% 26.6% 18.2% [libx264 @ 0x55640793d640] ref B L1: 61.4% 38.6% [libx264 @ 0x55640793d640] kb/s:2139.92 ffmpeg -c:v h264_cuvid -i input.mkv -c:v libx264 -y output.mkv 59.59s user 0.61s system 888% cpu 6.777 total }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/10668> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 17

#9285(avcodec:new): Excessive GPU memory usage with nvdec hwaccel
by FFmpeg 21 May '25

21 May '25

#9285: Excessive GPU memory usage with nvdec hwaccel -------------------------------------+------------------------------------- Reporter: Ridley | Type: defect Combs | Status: new | Priority: normal Component: avcodec | Version: Keywords: nvdec | unspecified nvidia | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 1 | -------------------------------------+------------------------------------- When decoding video using the CUDA hwaccel, `ff_nvdec_decode_init()` sets both `ulNumDecodeSurfaces` and `ulNumOutputSurfaces` to `frames_ctx->initial_pool_size`, which in turn is set by `ff_nvdec_decode_init` to `dpb_size + 2`, which in turn has 3 added by `ff_decode_get_hw_frames_ctx()` and `extra_hw_frames` + `thread_count` added by `avcodec_get_hw_frames_parameters`. This is excessive. Only `ulNumDecodeSurfaces` needs additional frames based on thread count (the output surfaces are only used in `nvdec_retrieve_data`, which runs on the consumer's single thread), while only `ulNumOutputSurfaces` needs the 3 additional output frames from `ff_decode_get_hw_frames_ctx()` or the ones from `extra_hw_frames` (the decode surfaces are never exposed to the consumer). I'm not sure what the best way to handle this is. Maybe nvdec should ignore what the generic code sets `initial_pool_size` to altogether and instead calculate its buffer counts internally, duplicating the generic code's behavior only where appropriate? The `initial_pool_size` value seems to be designed for systems where the decoder's internal buffered frames are returned directly to the user, but that's not the case here. Additionally, it doesn't seem like multithreading in CUDA actually serves any purpose; I see no performance gain when using multiple threads vs 1. Is it useful with any hardware decoder? Should we be defaulting multithreading off when using a hwaccel, or forcing it off unless the hwaccel fails and software fallback occurs? This can result in some pretty hefty memory usage for no reason by default on many-core machines. -- Ticket URL: <https://trac.ffmpeg.org/ticket/9285> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 2

#10663(avcodec:new): Vaapi hardware decoding 444 HEVC failure
by FFmpeg 20 May '25

20 May '25

#10663: Vaapi hardware decoding 444 HEVC failure -------------------------------------+------------------------------------- Reporter: kebs00n | Type: defect Status: new | Priority: important Component: avcodec | Version: 6.0 Keywords: VAAPI | Blocked By: ffmpeg-vaapi avcodec hw_decode | decoder Intel | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Hello. I'm trying to hardware decode 444 HEVC video frame using VAAPI, but it always fallback in software decoding with this error {{{Hardware does not offer any usable surface formats}}}. See attached logs How to reproduce: {{{ % ./ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -y -i blackwhite_yuv444p-frame.hevc 444.yuv -v debug }}} FFmpeg configuration: {{{ % ffmpeg version n6.0.1 Copyright (c) 2000-2023 the FFmpeg developers built with gcc 10 (Debian 10.2.1-6) configuration: --prefix=/home/mou/Documents/Dev/FFmpeg/build libavutil 58. 2.100 / 58. 2.100 libavcodec 60. 3.100 / 60. 3.100 libavformat 60. 3.100 / 60. 3.100 libavdevice 60. 1.100 / 60. 1.100 libavfilter 9. 3.100 / 9. 3.100 libswscale 7. 1.100 / 7. 1.100 libswresample 4. 10.100 / 4. 10.100 }}} OS information: {{{ % _,met$$$$$gg. mou@debianMou ,g$$$$$$$$$$$$$$$P. ------------------------ ,g$$P" """Y$$.". OS: Debian GNU/Linux 11 (bullseye) x86_64 ,$$P' `$$$. Host: Prestige 14 A11SCS REV:1.0 ',$$P ,ggs. `$$b: Kernel: 5.10.0-26-amd64 `d$$' ,$P"' . $$$ Uptime: 5 hours, 6 mins $$P d$' , $$P Packages: 3503 (dpkg), 8 (flatpak) $$: $$. - ,d$$' Shell: zsh 5.8 $$; Y$b._ _,d$P' Resolution: 1920x1080, 2560x1440 Y$$. `.`"Y$$$$P"' DE: Plasma 5.20.5 `$$b "-.__ WM: KWin `Y$$ WM Theme: Breeze `Y$$. Theme: Breeze Dark [Plasma], Breeze [GTK2/3] `$$b. Icons: breeze-dark [Plasma], breeze-dark [GTK2/3] `Y$$b. Terminal: yakuake `"Y$b._ CPU: 11th Gen Intel i7-1165G7 (8) @ 4.700GHz `""" GPU: NVIDIA GeForce GTX 1650 Ti Mobile GPU: Intel TigerLake GT2 [Iris Xe Graphics] Memory: 5889MiB / 15697MiB }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/10663> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 7

#9020(avformat:new): http BUFFER_SIZE too small
by FFmpeg 18 May '25

18 May '25

#9020: http BUFFER_SIZE too small ----------------------------------+--------------------------------------- Reporter: jtojnar | Type: defect Status: new | Priority: normal Component: avformat | Version: unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ----------------------------------+--------------------------------------- Summary of the bug: When making a HTTP request with a large authorization cookie, the execution fails with “overlong headers” error. The limit was increased to 8192 bytes in https://github.com/FFmpeg/FFmpeg/commit/d29c42974487d5fa0a5c1b05a09da5c5818… (part of ffmpeg 4.3.1) but that is still not enough for authorization headers required for downloading videos from Microsoft Stream (the cookie header alone is almost 8kiB). How to reproduce: {{{ $ ffmpeg -headers "Cookie: Authorization_Api=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%XX%XX; Signature_Api=XX%XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%XXXXXXXX%XXXX; UserSession_Api=XXXXXXXXX=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX&XXXXXXX=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX; Authorization=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%XX%XX; Signature=XX%XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%XXXXXXXX%XXXX; Extra- dummy-data-representing-the-rest-of-headers: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX; XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" -i "http://example.com/" ffmpeg version 4.3.1 Copyright (c) 2000-2020 the FFmpeg developers built with gcc 9.3.0 (GCC) configuration: --disable-static --prefix=/nix/store /n77nwda6g2b9iaxxwk8mdzardxzgz7dl-ffmpeg-4.3.1 --arch=x86_64 --target_os=linux --enable-gpl --enable-version3 --enable-shared --enable- pic --enable-runtime-cpudetect --enable-hardcoded-tables --enable-pthreads --disable-w32threads --disable-os2threads --enable-network --enable- pixelutils --enable-ffmpeg --disable-ffplay --enable-ffprobe --enable- avcodec --enable-avdevice --enable-avfilter --enable-avformat --enable- avresample --enable-avutil --enable-postproc --enable-swresample --enable- swscale --disable-doc --enable-libass --enable-bzlib --enable-gnutls --enable-fontconfig --enable-libfreetype --enable-libmp3lame --enable- iconv --enable-libtheora --enable-libssh --enable-vaapi --enable-libdrm --enable-vdpau --enable-libvorbis --enable-libvpx --enable-lzma --disable- opengl --disable-libmfx --disable-libaom --enable-libpulse --enable-sdl2 --enable-libsoxr --enable-libx264 --enable-libxvid --enable-zlib --enable- libopus --enable-libspeex --enable-libx265 --enable-libdav1d --disable- debug --enable-optimizations --disable-extra-warnings --disable-stripping libavutil 56. 51.100 / 56. 51.100 libavcodec 58. 91.100 / 58. 91.100 libavformat 58. 45.100 / 58. 45.100 libavdevice 58. 10.100 / 58. 10.100 libavfilter 7. 85.100 / 7. 85.100 libavresample 4. 0. 0 / 4. 0. 0 libswscale 5. 7.100 / 5. 7.100 libswresample 3. 7.100 / 3. 7.100 libpostproc 55. 7.100 / 55. 7.100 [http @ 0x1f7e480] No trailing CRLF found in HTTP header. Adding it. [http @ 0x1f7e480] overlong headers http://example.com/: Invalid argument }}} I managed to fix it locally by patching ffmpeg with a bigger buffer size (https://github.com/ytdl-org/youtube-dl/pull/24649#issuecomment-738002126) but ideally, ffmpeg would use dynamic allocation for the headers. -- Ticket URL: <https://trac.ffmpeg.org/ticket/9020> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 12

#10659(undetermined:new): Converting to ass subtitles results in overlap.
by FFmpeg 14 May '25

14 May '25

#10659: Converting to ass subtitles results in overlap. -------------------------------------+------------------------------------- Reporter: typological | 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 converting to ass subtitles from srt or vtt, there are some overlaps that weren't there, probably due to wrong rounding. How to reproduce: {{{ % ffmpeg -i sub.srt sub.ass ffmpeg version n6.0 Copyright (c) 2000-2023 the FFmpeg developers built with gcc 13.2.1 (GCC) 20230801 }}} sub.srt (input): {{{ 1 00:00:29,566 --> 00:00:34,332 test 1 2 00:00:34,333 --> 00:00:38,833 test 2 3 00:00:38,833 --> 00:00:39,833 test 3 }}} sub.ass (actual output): {{{ ... [Events] Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text Dialogue: 0,0:00:29.57,0:00:34.34,Default,,0,0,0,,test 1 Dialogue: 0,0:00:34.33,0:00:38.83,Default,,0,0,0,,test 2 Dialogue: 0,0:00:38.83,0:00:39.83,Default,,0,0,0,,test 3 }}} sub.ass (expected output): {{{ ... [Events] Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text Dialogue: 0,0:00:29.57,0:00:34.33,Default,,0,0,0,,test 1 Dialogue: 0,0:00:34.33,0:00:38.83,Default,,0,0,0,,test 2 Dialogue: 0,0:00:38.83,0:00:39.83,Default,,0,0,0,,test 3 }}} (note the 34, that should've been 33, at the first Dialogue line) the same happens if I use sub.vtt as input with the command {{{ ffmpeg -i sub.vtt sub.ass }}} with sub.vtt (input) {{{ WEBVTT Kind: captions Language: en 00:00:29.566 --> 00:00:34.332 test 1 00:00:34.333 --> 00:00:38.833 test 2 00:00:38.833 --> 00:00:39.833 test 3 }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/10659> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 7