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

#10990(undetermined:new): "Assertion best_input >= 0 failed" IFF upsampling AND complex filtergraph
by FFmpeg 02 Aug '25

02 Aug '25

#10990: "Assertion best_input >= 0 failed" IFF upsampling AND complex filtergraph -------------------------------------+------------------------------------- Reporter: Hunter | Type: defect Hogan | 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: If resampler is invoked at the start of the filtergraph to upsample, an error will be thrown at the very end despite the output file being successfully written. `Assertion best_input >= 0 failed at src/fftools/ffmpeg_filter.c:2075` How to reproduce: I reproduced it with a few different wav files, including a white noise file. All were stereo, however. Batch file and 22 logs attached. Only 4 logs have the error. The other logs are to compare changing only one variable but not getting an error. These quick tests all have filtergraphs loaded from a textfile, and I don't think I tested it without a text file. These tests all use `-/complex_filter` syntax, but I got the same error with the old syntax. I did not test downsampling at the start of the filtergraph. I first encountered this a couple of weeks ago after building version 7. Prior to that, however, I don't think I ever had a filtergraph that included upsampling and multiple input and/or output pads, so I am not claiming the error was recently introduced. If I recall correctly, originally, FFmpeg would crash, throw the error, and not write a usable file. IIRC, the output file was the size I expected (in bytes), but nothing could read it: ffprobe, ffmpeg, Goldwave all said the file was garbage. I interpreted it to mean that the "headers" were malformed. (By "headers", I probably mean metadata, but I don't know the precise term here.) I worked around it by scripting: 1. upsample my input file to a temp output file 2. filter as I want, output to a new temp 3. downsample IIRC, it was necessary for me to downsample in a different filtergraph. But, it now looks like downsampling doesn't throw an error. Today, I rebuilt, and noticed the differences. {{{ % FFmpeg -hide_banner -loglevel warning -stats -i test_input_44100_2ch.wav -/filter_complex test_filter.txt -map "[Z0Z_out]" -codec:a pcm_f32le "output\\test_input_44100_2ch.wav_filtergraph_192000.wav" }}} ffmpeg version: media autobuilder suite, built today on Windows {{{ ffmpeg version N-115035-g192f5b58b7-gb7debef3cc+4 Copyright (c) 2000-2024 the FFmpeg developers built with gcc 13.2.0 (Rev6, Built by MSYS2 project) configuration: --pkg-config=pkgconf --cc='ccache gcc' --cxx='ccache g++' --ld='ccache g++' --extra-cxxflags=-fpermissive --extra-cflags=-Wno-int- conversion --disable-autodetect --enable-amf --enable-bzlib --enable- d3d11va --enable-dxva2 --enable-iconv --enable-lzma --enable-zlib --enable-sdl2 --enable-libmp3lame --enable-libopus --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libdav1d --enable-libaom --disable-debug --enable-libfdk-aac --enable-fontconfig --enable-libass --enable-libfreetype --enable-libmysofa --enable- libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvo-amrwbenc --enable- libwebp --enable-libxml2 --enable-libzimg --enable-libshine --enable-gpl --enable-avisynth --enable-libxvid --enable-libopenmpt --enable-version3 --enable-librav1e --enable-libgsm --enable-libvmaf --enable-libsvtav1 --enable-chromaprint --enable-frei0r --enable-libaribb24 --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libflite --enable-libfribidi --enable-libgme --enable-libilbc --enable-libsvthevc --enable-libsvtvp9 --enable-libkvazaar --enable-libmodplug --enable-librtmp --enable- librubberband --enable-libtesseract --enable-libxavs --enable-libzmq --enable-libzvbi --enable-openal --enable-libcodec2 --enable-ladspa --enable-libglslang --enable-vulkan --enable-libdavs2 --enable-libxavs2 --enable-libuavs3d --enable-opengl --enable-libopenh264 --enable- libharfbuzz --enable-libfontconfig --enable-openssl --extra- cflags=-DLIBTWOLAME_STATIC --extra-cflags=-DCACA_STATIC --extra- cflags=-DMODPLUG_STATIC --extra-cflags=-DCHROMAPRINT_NODLL --extra- cflags=-DZMQ_STATIC --extra-libs=-lpsapi --extra-cflags=-DLIBXML_STATIC --extra-libs=-liconv --disable-w32threads --extra-cflags=-DKVZ_STATIC_LIB --enable-nonfree --extra-cflags=-DAL_LIBTYPE_STATIC --extra- cflags='-IC:/apps/media-autobuild_suite/local64/include' --extra- cflags='-IC:/apps/media-autobuild_suite/local64/include/AL' libavutil 59. 16.101 / 59. 16.101 libavcodec 61. 5.103 / 61. 5.103 libavformat 61. 3.103 / 61. 3.103 libavdevice 61. 2.100 / 61. 2.100 libavfilter 10. 2.101 / 10. 2.101 libswscale 8. 2.100 / 8. 2.100 libswresample 5. 2.100 / 5. 2.100 libpostproc 58. 2.100 / 58. 2.100 }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/10990> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 4

#10988(undetermined:new): Acrossover crash
by FFmpeg 02 Aug '25

02 Aug '25

#10988: Acrossover crash -------------------------------------+------------------------------------- Reporter: JamesBond | Type: defect Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Setup: Windows 7 x64, FFMPEG g08781ebe1-2024-04-29 x64 Source: song.dsf https://fastupload.io/en/8hp1Dg1K3KNY3Zc/file Command: ffmpeg -i song.dsf -af "volume=6dB,aresample=96000:resampler=soxr:precision=28:osf=s32:dither_method=triangular_hp,acrossover=24000:order=8th[low][high];[low]anull;[high]anullsink" out.flac When the encoding is almost done, the red line appears. It says “Assertion best_input >= 0 failed at fftools/ffmpeg_filter.c:2075”. Then I see a GUI window that says “ffmpeg.exe has stopped working” with a button “Close the program”. An incomplete FLAC file remains on the disk, i.e. flac -t song.flac says “FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC” and “ FLAC__STREAM_DECODER_END_OF_STREAM”. If I remove that acrossover filter, then the encoding goes fine. -- Ticket URL: <https://trac.ffmpeg.org/ticket/10988> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 5

#11047(undetermined:new): Compressing to yuv422p10le with x264 errors
by FFmpeg 01 Aug '25

01 Aug '25

#11047: Compressing to yuv422p10le with x264 errors -------------------------------------+------------------------------------- Reporter: Mads | Type: defect Johansen | Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: libx264, | Blocked By: yuv422p10le | Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: Compressing to x264 with yuv422p10le triggers unplayable file, but with different results depending on resolution. As I see it, there is a bug with 1080 and 2160 in vertical resolutions, because 1440x1080,1920x1080,2048x1080 and 3840x2160 all has errors. The complete logs are below, identified by (n), where n is an integer. Result 1: Works perfectly: ffmpeg -f lavfi -i mandelbrot -t 5 -pix_fmt yuv422p10le mandelbrot.mov (1) ffmpeg -f lavfi -i mandelbrot=s=640x480 -t 5 -pix_fmt yuv422p10le mandelbrot640x480.mov (ruling out the size parameter) Result 2: Errors in playback: ffmpeg -f lavfi -i mandelbrot=s=1920x1080 -t 5 -pix_fmt yuv422p10le 1080p.mov (2) ffmpeg -f lavfi -i mandelbrot=s=3840x2160 -t 5 -pix_fmt yuv422p10le 2160p.mov (3) ffmpeg -f lavfi -i mandelbrot=s=2048x1080 -t 5 -pix_fmt yuv422p10le 2048x1080.mov (20) ffmpeg -i 2048x1080.mov (21) There are oddities with resolutions though: ffmpeg -f lavfi -i mandelbrot=s=1922x1082 -t 5 -pix_fmt yuv422p10le 1082p.mov gives a perfectly working file. (4) Just to make sure that it’s not my player, I did ffmpeg -i 1080.mov, with [h264 @ 00000245b2270500] deblocking_filter_idc 6 out of range [h264 @ 00000245b2270500] decode_slice_header error [h264 @ 00000245b2270500] no frame! See more at (5) Same for 2160p.mov: [h264 @ 000002025a890500] non-existing PPS 0 referenced Last message repeated 1 times [h264 @ 000002025a890500] decode_slice_header error [h264 @ 000002025a890500] no frame! See (6) In the interest of being thorough I have tested with old versions of ffmpeg from https://github.com/BtbN/FFmpeg- Builds/releases/tag/autobuild-2022-07-31-12-37 Same results: (7), (8), (9) and (10) That means it’s not a recent problem. I have also tested if it is lavfi -> codec that is a problem. Create the same test file into cineform and ffv1: ffmpeg -f lavfi -i mandelbrot=s=1920x1080 -t 5 -c:v cfhd cfhd1080p.mov ffmpeg -f lavfi -i mandelbrot=s=1920x1080 -t 5 -c:v ffv1 ffv11080p.mov (11), (12) Then converting the intermediate file into x264 yuv422p10le: ffmpeg -i cfhd1080p.mov -pix_fmt yuv422p10le cfhd_x264yuv422p10le.mov ffmpeg -i ffv11080p.mov -pix_fmt yuv422p10le ffv1_x264yuv422p10le.mov (13), (14) Same result (a broken file). Verified with ffmpeg -i cfhd_x264yuv422p10le.mov ffmpeg -i ffv1_x264yuv422p10le.mov Same results as with lavfi above. (15), (16) That means it’s not a lavfi problem. So far I’ve trusted that libx264 supports yuv422p10le. Verified by ffmpeg -h encoder=libx264 Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p yuvj444p nv12 nv16 nv21 yuv420p10le yuv422p10le yuv444p10le nv20le gray gray10le That means it’s not an unsupported format. To confirm it’s an ffmpeg problem I’ve downloaded x264-r3191-4613ac3.exe from https://artifacts.videolan.org/x264/release-win64/ To create a supported file, I created ffmpeg -f lavfi -i mandelbrot=s=1920x1080 -t 5 -strict -1 -pix_fmt yuv422p10 ffmpeg_y4m.y4m (17) Then I converted the output file with x264-r3191-4613ac3.exe to yuv422p10le with x264-r3191-4613ac3 --profile high422 --output-depth 10 --output-csp i422 -o x264.mov ffmpeg_y4m.y4m (18) And the file works and plays back with no problems. Stream #0:0: Video: h264 (High 4:2:2), yuv422p10le(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 50 tbr, 1200k tbn (19) What will the next steps be? Best regards Mads Johansen -- Ticket URL: <https://trac.ffmpeg.org/ticket/11047> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 7

#9195(avfilter:new): vibrance (video filter) incorrect defaults for luma
by FFmpeg 31 Jul '25

31 Jul '25

#9195: vibrance (video filter) incorrect defaults for luma -------------------------------------+------------------------------------- Reporter: Jim | Type: defect DeLaHunt | Status: new | Priority: normal Component: avfilter | Version: git- | master Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: The "vibrance" video filter appears to have incorrect default values for the luma coefficient parameters "rlum" and "blum". They appear to be swapped. How to reproduce: {{{ % ffmpeg -h filter=vibrance ffmpeg version 4.4 Copyright (c) 2000-2021 the FFmpeg developers built with Apple LLVM version 10.0.0 (clang-1000.10.44.4) configuration: --prefix=/opt/local --enable-swscale --enable-avfilter --enable-avresample --enable-libmp3lame --enable-libvorbis --enable- libopus --enable-librsvg --enable-libtheora --enable-libopenjpeg --enable- libmodplug --enable-libvpx --enable-libsoxr --enable-libspeex --enable- libass --enable-libbluray --enable-lzma --enable-gnutls --enable- fontconfig --enable-libfreetype --enable-libfribidi --disable-libjack --disable-libopencore-amrnb --disable-libopencore-amrwb --disable- indev=jack --enable-opencl --disable-outdev=xv --enable-audiotoolbox --enable-videotoolbox --enable-sdl2 --disable-securetransport --mandir=/opt/local/share/man --enable-shared --enable-pthreads --cc=/usr/bin/clang --enable-libdav1d --arch=x86_64 --enable-x86asm --enable-libx265 --enable-gpl --enable-postproc --enable-libx264 --enable- libxvid libavutil 56. 70.100 / 56. 70.100 libavcodec 58.134.100 / 58.134.100 libavformat 58. 76.100 / 58. 76.100 libavdevice 58. 13.100 / 58. 13.100 libavfilter 7.110.100 / 7.110.100 libavresample 4. 0. 0 / 4. 0. 0 libswscale 5. 9.100 / 5. 9.100 libswresample 3. 9.100 / 3. 9.100 libpostproc 55. 9.100 / 55. 9.100 Filter vibrance Boost or alter saturation. slice threading supported Inputs: #0: default (video) Outputs: #0: default (video) vibrance AVOptions: intensity <float> ..FV.....T. set the intensity value (from -2 to 2) (default 0) rbal <float> ..FV.....T. set the red balance value (from -10 to 10) (default 1) gbal <float> ..FV.....T. set the green balance value (from -10 to 10) (default 1) bbal <float> ..FV.....T. set the blue balance value (from -10 to 10) (default 1) rlum <float> ..FV.....T. set the red luma coefficient (from 0 to 1) (default 0.072186) glum <float> ..FV.....T. set the green luma coefficient (from 0 to 1) (default 0.715158) blum <float> ..FV.....T. set the blue luma coefficient (from 0 to 1) (default 0.212656) alternate <boolean> ..FV.....T. use alternate colors (default false) This filter has support for timeline through the 'enable' option. }}} The vibrance filter is documented at https://ffmpeg.org/ffmpeg- filters.html#vibrance . It looks like coefficients "rlum", "glum", and "blum" are supposed to match the luma computation as defined in BT.709-6 (https://en.wikipedia.org/wiki/Rec._709) or something similar. Wikipedia gives this formula as: > R’G’B’ coefficients 0.2126, 0.7152, and 0.0722 (together they add to 1) So, `luma = 0.2126 * r + 0.7152 * g + 0.0722 * b`, a value in [0.0, 1.0] for r, g, b in [0.0, 1.0] But the default values I see in the FFmpeg vibrance filter are (per output above): > rlum (default 0.072186), glum (default 0.715158), blum (default 0.212656) Thus it looks like the default values for rlum and blum are swapped. Vibrance would still compute a luma a value in a range of [0.0, 1.0], but it wouldn't be the correct value per BT.709. Since the vibrance adjustments are relative to luma, they might be slightly off. I believe the fix would be the simple, obvious exchange of default values in ffmpeg/libavfilter/vf_vibrance.c:372-374. But I haven't tried this. Present code: {{{ { "rlum", "set the red luma coefficient", OFFSET(lcoeffs[2]), AV_OPT_TYPE_FLOAT, {.dbl=0.072186}, 0, 1, VF }, { "glum", "set the green luma coefficient", OFFSET(lcoeffs[0]), AV_OPT_TYPE_FLOAT, {.dbl=0.715158}, 0, 1, VF }, { "blum", "set the blue luma coefficient", OFFSET(lcoeffs[1]), AV_OPT_TYPE_FLOAT, {.dbl=0.212656}, 0, 1, VF }, }}} Code with possible fix: {{{ { "rlum", "set the red luma coefficient", OFFSET(lcoeffs[2]), AV_OPT_TYPE_FLOAT, {.dbl=0.212656}, 0, 1, VF }, { "glum", "set the green luma coefficient", OFFSET(lcoeffs[0]), AV_OPT_TYPE_FLOAT, {.dbl=0.715158}, 0, 1, VF }, { "blum", "set the blue luma coefficient", OFFSET(lcoeffs[1]), AV_OPT_TYPE_FLOAT, {.dbl=0.072186}, 0, 1, VF }, }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/9195> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 5

#10209(undetermined:new): EBUR128 and LOUDNORM filters compute LRA differently
by FFmpeg 25 Jul '25

25 Jul '25

#10209: EBUR128 and LOUDNORM filters compute LRA differently --------------------------------------+---------------------------------- Reporter: hsn | Type: defect Status: new | Priority: normal Component: undetermined | Version: 5.1.2 Keywords: LRA, ebur128 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | --------------------------------------+---------------------------------- Summary of the bug: How to reproduce: {{{ ffmpeg -i song192k.mp4 -af ebur128,loudnorm=print_format=summary -f null - }}} Outputs: {{{ [Parsed_ebur128_0 @ 000001f413d21a40] Summary: Integrated loudness: I: -14.0 LUFS Threshold: -24.1 LUFS Loudness range: LRA: 3.6 LU Threshold: -33.9 LUFS LRA low: -15.6 LUFS LRA high: -12.0 LUFS [Parsed_loudnorm_1 @ 000001f413fc4e40] Input Integrated: -14.2 LUFS Input True Peak: +0.1 dBTP Input LRA: 5.9 LU Input Threshold: -24.3 LUFS }}} One LRA is ''5.9'' and second is ''3.6''. Song analysed by https://youlean.co/file-loudness-meter/ returns: {{{ Momentary Max = -9.81 LUFS Short Term Max = -11.50 LUFS Integrated = -14.00 LUFS }}} LRA definition is here: https://tech.ebu.ch/docs/tech/tech3342v2_0.pdf -- Ticket URL: <https://trac.ffmpeg.org/ticket/10209> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 12

#11582(ffmpeg:new): Please add an option to make the new "elapsed" stat optional
by FFmpeg 25 Jul '25

25 Jul '25

#11582: Please add an option to make the new "elapsed" stat optional -----------------------------------+--------------------------------------- Reporter: Anton1699 | Type: enhancement Status: new | Priority: wish Component: ffmpeg | Version: unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -----------------------------------+--------------------------------------- [https://github.com/FFmpeg/FFmpeg/commit/1a083a4d90bc4cf26f06d3f62d75da3d49a… This commit] added the elapsed time to the output of `-stats`. I would like to propose an option like `-stats_print_elapsed_time <bool>` (enabled by default) to disable this new behavior. I also don't think the elapsed time should be the first data point, it's not as important as the actual progress being made. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11582> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 7

#11446(undetermined:new): Intermittent Vulkan encoding failures with 4060TI(driver 550), Ubuntu 24.04, Vulkan SDK 1.4.304.0
by FFmpeg 24 Jul '25

24 Jul '25

#11446: Intermittent Vulkan encoding failures with 4060TI(driver 550), Ubuntu 24.04, Vulkan SDK 1.4.304.0 -------------------------------------+------------------------------------- Reporter: Marth64 | Type: defect Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Given the following environment - Install NVIDIA RTX 4060TI GPU - Install Xubuntu 24.04 - Install nvidia-driver-550 via Ubuntu Additional Drivers widget - Install Vulkan SDK 1.4.304.0 via apt (from LunarG) - Provide an MPEG-2 source (720x480, 29.9fps) or H264 source (1920x1080, 40fps) [this is only what I have tested with, but 3 diverse ones] - FFmpeg head as of 957eb2323a924aa0b148927889eae581185c367b Then run: {{{ ffmpeg -init_hw_device vulkan=vk:0 -y -i "$IN" -filter:v "format=nv12,hwupload" -c:v h264_vulkan sample_h264_vulkan.mkv }}} Observe that the operation will sometimes work but then intermittently fail with various error codes. I tried to av_err2str() the codes, but only their numeric value is still printed as a fallback since they are not known. The error codes appear to be random, here are a few: -1851303552 -1776594112 -1241304448 -1195352896 -1474912192 -1080228480 {{{ ffmpeg version N-118406-g957eb2323a Copyright (c) 2000-2025 the FFmpeg developers built with gcc 13 (Ubuntu 13.3.0-6ubuntu2~24.04) configuration: --enable-debug=3 --enable-ffplay --enable-gpl --enable- nonfree --enable-ffnvcodec --enable-vulkan --enable-libx264 --enable- libfdk_aac --enable-openssl --enable-version3 --enable-demuxer=dvdvideo --enable-libdvdread --enable-libdvdnav --samples=fate-suite/ libavutil 59. 56.100 / 59. 56.100 libavcodec 61. 32.100 / 61. 32.100 libavformat 61. 9.106 / 61. 9.106 libavdevice 61. 4.100 / 61. 4.100 libavfilter 10. 9.100 / 10. 9.100 libswscale 8. 13.100 / 8. 13.100 libswresample 5. 4.100 / 5. 4.100 libpostproc 58. 4.100 / 58. 4.100 Input #0, matroska,webm, from 'MyDVD.mkv': Metadata: ENCODER : Lavf61.9.106 Duration: 00:06:00.14, start: 0.000000, bitrate: 7790 kb/s Stream #0:0: Video: mpeg2video (Main), yuv420p(tv, smpte170m, progressive), 720x480 [SAR 32:27 DAR 16:9], 29.97 fps, 29.97 tbr, 1k tbn Metadata: DURATION : 00:06:00.143000000 Side data: cpb: bitrate max/min/avg: 9800000/0/0 buffer size: 1835008 vbv_delay: N/A Stream #0:1(eng): Audio: ac3, 48000 Hz, 5.1(side), fltp, 448 kb/s Metadata: DURATION : 00:06:00.006000000 Stream mapping: Stream #0:0 -> #0:0 (mpeg2video (native) -> h264 (h264_vulkan)) Stream #0:1 -> #0:1 (ac3 (native) -> ac3 (native)) Press [q] to stop, [?] for help [h264_vulkan @ 0x64d194ac7540] No rate control settings specified, using fixed QP = 18 Output #0, matroska, to 'sample_h264_vulkan.mkv': Metadata: encoder : Lavf61.9.106 Stream #0:0: Video: h264 (High) (H264 / 0x34363248), vulkan(tv, smpte170m, progressive), 720x480 [SAR 32:27 DAR 16:9], q=2-31, 29.97 fps, 1k tbn Metadata: encoder : Lavc61.32.100 h264_vulkan DURATION : 00:06:00.143000000 Stream #0:1(eng): Audio: ac3 ([0] [0][0] / 0x2000), 48000 Hz, 5.1(side), fltp, 448 kb/s Metadata: encoder : Lavc61.32.100 ac3 DURATION : 00:06:00.006000000 [h264_vulkan @ 0x64d194ac7540] Encode failed: -1851303552. [vost#0:0/h264_vulkan @ 0x64d191a6a380] [enc:h264_vulkan @ 0x64d1918e0e00] Error submitting video frame to the encoder [vost#0:0/h264_vulkan @ 0x64d191a6a380] [enc:h264_vulkan @ 0x64d1918e0e00] Error encoding a frame: Error number -1851303552 occurred [vost#0:0/h264_vulkan @ 0x64d191a6a380] Task finished with error code: -1851303552 (Error number -1851303552 occurred) [vost#0:0/h264_vulkan @ 0x64d191a6a380] Terminating thread with return code -1851303552 (Error number -1851303552 occurred) [out#0/matroska @ 0x64d191a68840] video:0KiB audio:51KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: 1.939655% frame= 0 fps=0.0 q=0.0 Lsize= 52KiB time=N/A bitrate=N/A speed=N/A Conversion failed! }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/11446> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 5

#11059(undetermined:new): FFmpeg cannot load files with non-latin characters by DirectShowSource2 of AviSynth+
by FFmpeg 23 Jul '25

23 Jul '25

#11059: FFmpeg cannot load files with non-latin characters by DirectShowSource2 of AviSynth+ -------------------------------------+------------------------------------- Reporter: syehoonkim | 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: How to reproduce: {{{ % ffmpeg -i input.avs ... output ffmpeg version N-115575-g4e120fbbbd-ffmpeg-windows-build-helpers Copyright (c) 2000-2024 the FFmpeg developers built with gcc 10.2.0 (GCC) configuration: --pkg-config=pkg-config --pkg-config-flags=--static --extra-version=ffmpeg-windows-build-helpers --enable-version3 --disable- debug --disable-w32threads --arch=x86_64 --target-os=mingw32 --cross- prefix=/home/syehoon/repos/ffmpeg-windows-build- helpers/sandbox/cross_compilers/mingw-w64-x86_64/bin/x86_64-w64-mingw32- --enable-libcaca --enable-gray --enable-libtesseract --enable-fontconfig --enable-gmp --enable-libass --enable-libbluray --enable-libbs2b --enable- libflite --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libilbc --enable-libmodplug --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopus --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libtheora --enable-libtwolame --enable-libvo-amrwbenc --enable-libvorbis --enable- libwebp --enable-libzimg --enable-libzvbi --enable-libmysofa --enable- libopenjpeg --enable-libopenh264 --enable-libvmaf --enable-libsrt --enable-libxml2 --enable-opengl --enable-libdav1d --enable-gnutls --enable-libsvtav1 --enable-libvpx --enable-libaom --enable-nvenc --enable-nvdec --extra-libs=-lz --extra-libs=-lpng --extra-libs=-lm --extra-libs=-lfreetype --extra-libs=-lshlwapi --extra-libs=-lmpg123 --extra-libs=-lpthread --extra-cflags=-DLIBTWOLAME_STATIC --extra- cflags=-DMODPLUG_STATIC --extra-cflags=-DCACA_STATIC --enable-amf --enable-libmfx --enable-libaribcaption --enable-gpl --enable-frei0r --enable-librubberband --enable-libvidstab --enable-libx264 --enable- libx265 --enable-avisynth --enable-libaribb24 --enable-libxvid --enable- libdavs2 --enable-libxavs2 --enable-libxavs --extra- cflags='-mtune=generic' --extra-cflags=-O3 --enable-static --disable- shared --prefix=/home/syehoon/repos/ffmpeg-windows-build- helpers/sandbox/cross_compilers/mingw-w64-x86_64/x86_64-w64-mingw32 --enable-nonfree --enable-libfdk-aac --enable-decklink libavutil 59. 21.100 / 59. 21.100 libavcodec 61. 6.100 / 61. 6.100 libavformat 61. 3.104 / 61. 3.104 libavdevice 61. 2.100 / 61. 2.100 libavfilter 10. 2.102 / 10. 2.102 libswscale 8. 2.100 / 8. 2.100 libswresample 5. 2.100 / 5. 2.100 libpostproc 58. 2.100 / 58. 2.100 [avisynth @ 000002488fa24ac0] DSS2: Can't open "D:/sample_video/진신우부장 님/DJI_0077.MOV" Add Source: (80004005) �d�� 7�Դϴ� (frameserver.avs, line 2) [in#0 @ 000002488fa246c0] Error opening input: Unknown error occurred Error opening input file frameserver.avs. Error opening input files: Unknown error occurred }}} The input.avs loads the file by the command {{{ DSS2("D:/sample_video/진신우부장님/DJI_0077.MOV") }}} If I move the file to the directory which doesn't include non-latin characters, FFmpeg works fine. With DirectShowSource() function, there is no problem. I suspect that FFmpeg has some problem on dealing with unicode in processing AviSynth+'s DSS2() function. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11059> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 1

#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