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

#5419(avformat:new): HLS EXT-X-DISCONTINUITY tag is not supported
by FFmpeg 05 Aug '25

05 Aug '25

#5419: HLS EXT-X-DISCONTINUITY tag is not supported -----------------------------------+--------------------------------------- Reporter: xyq204101 | Type: enhancement Status: new | Priority: normal Component: avformat | Version: git-master Keywords: hls | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -----------------------------------+--------------------------------------- Summary of the bug: I'm trying to read input from HLS and output to RTMP, this works fine if the HLS segments are all in one time sequence. However if the time changes e.g. segments generated from two video files, ffmpeg got error 'Non- monotonous DTS in output stream 0:1;'. According to the HLS documentation, EXT-X-DISCONTINUITY should be used when time sequence changes. (https://tools.ietf.org/html/draft-pantos- http-live-streaming-13#section-3.4.11) But I still got the same error after I added that tag to the m3u8 file. Look at hls.c file in libavformat, it doesn't handle EXT-X-DISCONTINUITY tag. How to reproduce: {{{ ffmpeg -re -i http://hls-server/playlist.m3u8 -acodec copy -vcodec copy -bsf:a aac_adtstoasc -f flv rtmp://rtmp-server/app }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/5419> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 35

#11659(avutil:new): Regression: cannot use frames with alpha channel on vulkan
by FFmpeg 05 Aug '25

05 Aug '25

#11659: Regression: cannot use frames with alpha channel on vulkan -------------------------------------+------------------------------------- Reporter: bermond | Type: defect Status: new | Priority: normal Component: avutil | Version: git- Keywords: vulkan | master alpha | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Vulkan cannot be used anymore with frames that have an alpha channel. It looks like there is a failure when allocating Vulkan frames, giving the message `No memory type found for flags 0x1`. How to reproduce: {{{ $ ffmpeg -init_hw_device vulkan=gpu:0 -filter_hw_device gpu -f lavfi -i 'color=color=white:size=1280x720' -vf 'format=bgra,hwupload,hwdownload,format=bgra' -t 20 -f null - ffmpeg version N-120203-geb52251c0a Copyright (c) 2000-2025 the FFmpeg developers built with gcc 15.1.1 (GCC) 20250425 configuration: --prefix=/usr --disable-debug --disable-static --disable- stripping --enable-amf --enable-avisynth --enable-cuda-llvm --enable-lto --enable-fontconfig --enable-frei0r --enable-gmp --enable-gnutls --enable- gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libdav1d --enable-libdrm --enable-libdvdnav --enable-libdvdread --enable-libfreetype --enable-libfribidi --enable- libglslang --enable-libgsm --enable-libharfbuzz --enable-libiec61883 --enable-libjack --enable-libjxl --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libplacebo --enable-libpulse --enable-librav1e --enable-librsvg --enable-librubberband --enable- libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable- libssh --enable-libsvtav1 --enable-libtheora --enable-libv4l2 --enable- libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpl --enable- libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq --enable-nvdec --enable-nvenc --enable-opencl --enable-opengl --enable- shared --enable-vapoursynth --enable-version3 --enable-vulkan libavutil 60. 4.101 / 60. 4.101 libavcodec 62. 5.100 / 62. 5.100 libavformat 62. 1.101 / 62. 1.101 libavdevice 62. 0.100 / 62. 0.100 libavfilter 11. 1.100 / 11. 1.100 libswscale 9. 0.100 / 9. 0.100 libswresample 6. 0.100 / 6. 0.100 Input #0, lavfi, from 'color=color=white:size=1280x720': Duration: N/A, start: 0.000000, bitrate: N/A Stream #0:0: Video: wrapped_avframe, yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 25 tbn Stream mapping: Stream #0:0 -> #0:0 (wrapped_avframe (native) -> wrapped_avframe (native)) Press [q] to stop, [?] for help [Vulkan @ 0x562c35258e00] No memory type found for flags 0x1 [hwupload @ 0x7f33380046c0] Failed to allocate frame to upload to. [vf#0:0 @ 0x562c353fa5c0] Error while filtering: Cannot allocate memory [vf#0:0 @ 0x562c353fa5c0] Task finished with error code: -12 (Cannot allocate memory) [vf#0:0 @ 0x562c353fa5c0] Terminating thread with return code -12 (Cannot allocate memory) [vost#0:0/wrapped_avframe @ 0x562c353f9c80] [enc:wrapped_avframe @ 0x562c353fa0c0] Could not open encoder before EOF [vost#0:0/wrapped_avframe @ 0x562c353f9c80] Task finished with error code: -22 (Invalid argument) [vost#0:0/wrapped_avframe @ 0x562c353f9c80] Terminating thread with return code -22 (Invalid argument) [out#0/null @ 0x562c353f9900] 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 elapsed=0:00:00.00 Conversion failed! }}} This same command works nice with FFmpeg 7.1.1 and also with commit bddb9c232dbdfa2c1402c7c56f77e5e6c7fda60f (the last usable one before the soname version bumps), but fails in the current git master. So, it seems to be a regression. A git bisect shows the offending commit as being: a9b2c10eee9cf28ecbce2f1972564f4aa826a855. Notice that the offending commit does not compile, needing a fix from commit 3ac7d70291838d71a28cd31a5774bb69745d4216, which also fails to use frames with alpha channel on Vulkan. System information: - OS: Arch Linux - Vulkan Headers: 1.4.313.0 - Vulkan ICD Loader: 1.4.313.0 - Vulkan GPU Hardware: NVIDIA RTX 3060 - GPU driver: 575.64.03 (NVIDIA open source driver) -- Ticket URL: <https://trac.ffmpeg.org/ticket/11659> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 2

#11570(avdevice:new): v4l2 1.30 breaks build of 7.1.1
by FFmpeg 05 Aug '25

05 Aug '25

#11570: v4l2 1.30 breaks build of 7.1.1 ----------------------------------+--------------------------------------- Reporter: bbhtt | Type: defect Status: new | Priority: normal Component: avdevice | Version: unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ----------------------------------+--------------------------------------- Summary of the bug: 7.1.1 build is broken with v4l2 1.30 {{{ libavdevice/v4l2.c: In function ‘device_open’: libavdevice/v4l2.c:141:17: error: assignment to ‘int (*)(int, long unsigned int, ...)’ from incompatible pointer type ‘int (*)(int, int, ...)’ [-Wincompatible-pointer-types] 141 | s->ioctl_f = prefix ## ioctl; \ | ^ libavdevice/v4l2.c:149:9: note: in expansion of macro ‘SET_WRAPPERS’ 149 | SET_WRAPPERS(v4l2_); | ^~~~~~~~~~~~ In file included from libavdevice/v4l2.c:52: /usr/include/libv4l2.h:67:19: note: ‘v4l2_ioctl’ declared here 67 | LIBV4L_PUBLIC int v4l2_ioctl(int fd, int request, ...); | ^~~~~~~~~~ }}} See the attached file for the full build log. How to reproduce: Build with v4l2 1.30 -- Ticket URL: <https://trac.ffmpeg.org/ticket/11570> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 6

#11403(undetermined:new): Recording with kmsgrab can't be stopped properly
by FFmpeg 04 Aug '25

04 Aug '25

#11403: Recording with kmsgrab can't be stopped properly -------------------------------------+------------------------------------- Reporter: superded | Type: defect Status: new | Priority: normal Component: | Version: undetermined | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Recording stops only after several Ctrl+C with muxing error. Tested in tty and wayland. First commit with this bug d119ae2fd82a494d9430ff4d4fc262961a68c598. Log: https://pastebin.com/c5rGYV9k -- Ticket URL: <https://trac.ffmpeg.org/ticket/11403> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 3

#11653(undetermined:new): -c copy does not copy track names
by FFmpeg 04 Aug '25

04 Aug '25

#11653: -c copy does not copy track names -------------------------------------+------------------------------------- Reporter: Steven | Type: defect Allan Spielber | Status: new | Priority: critical Component: | Version: undetermined | unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- ffmpeg -i input.mp4 -map 0 -c copy -movflags +faststart output.mp4 does not copy track names -- Ticket URL: <https://trac.ffmpeg.org/ticket/11653> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 13

#11606(avcodec:new): avcodec/dvbsubenc: Broken dvb_encode_rle8
by FFmpeg 03 Aug '25

03 Aug '25

#11606: avcodec/dvbsubenc: Broken dvb_encode_rle8 ---------------------------------+--------------------------------------- Reporter: pbk | Type: defect Status: new | Priority: normal Component: avcodec | Version: unspecified Keywords: | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | ---------------------------------+--------------------------------------- The rle8 encoding (256 color table) is corrupted. The end of 8-bit/pixel_code_string shall be 2 zeroes (not one): Current code: *q++ = 0x00; *q++ = 0xf0; Correct code: *q++ = 0x00; *q++ = 0x00; *q++ = 0xf0; -- Ticket URL: <https://trac.ffmpeg.org/ticket/11606> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 4

Re: [FFmpeg-trac] #2909(avcodec:new): Make dvbsubs more compliant among stb's
by FFmpeg 03 Aug '25

03 Aug '25

#2909: Make dvbsubs more compliant among stb's -------------------------------------+----------------------------------- Reporter: Tommy2d | Owner: (none) Type: enhancement | Status: new Priority: normal | Component: avcodec Version: 1.2.2 | Resolution: Keywords: dvbsub | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+----------------------------------- Comment (by waider): It looks like the reserved bits can be 1 or 0 depending on where they are. The current spec (https://www.etsi.org/deliver/etsi_en/300700_300799/300743/01.06.01_60/en_30…) says: > reserved: When used in a clause defining the coded bit stream, this field indicates that the value may be used for extensions in the future. Unless specified otherwise within the present document, all "reserved" bits are expected to be set to "1". > reserved_zero_future_use: When used in clauses defining the coded bit stream, this field indicates that the value may be used in future revisions for ETSI-defined extensions. All "reserved_zero_future_use" bits are expected to be set to "0". (Yes, adding an note to a 12-year-old bug report. I happened to be poking in the spec for something else.) -- Ticket URL: <https://trac.ffmpeg.org/ticket/2909#comment:9> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 0

#10966(undetermined:new): Regression - Memory leak when muxing raw h264 streams
by FFmpeg 02 Aug '25

02 Aug '25

#10966: Regression - Memory leak when muxing raw h264 streams -------------------------------------+------------------------------------- Reporter: Francesco | Type: defect Bucciantini | Status: new | Priority: normal Component: | Version: git- undetermined | master Keywords: h264 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Summary of the bug: When raw h264 streams (i.e raw_video.h264 files) are being muxed in a container, FFMpeg keeps allocating RAM with no clear progress until it goes into paging files on Windows or swap on Linux and then eventually crashes. How to reproduce: Step 1) Create a simple Colorbars script with Avisynth and call it "AVS Script.avs" {{{ ColorBars(1920, 1080, pixel_type="YUV422P16") }}} Step 2) Encode the colorbars with x264 to create a raw_video.h264 stream {{{ x264-10b.exe "AVS Script.avs" --preset medium --profile high422 --level 4.1 --opencl --keyint 1 --no-cabac --avcintra 100 --avcintra-flavor panasonic --deblock -1:-1 --tff --overscan show --colormatrix bt709 --range tv --log-level info --thread-input --transfer bt709 --colorprim bt709 --videoformat component --nal-hrd cbr --output-depth 10 --output-csp i422 --output "raw_video.h264" }}} Step 3) Mux the newly produced raw_video.h264 into any container you like, be it mkv or mxf or whatever {{{ ffmpeg.exe -hide_banner -i "raw_video.h264" -map 0:0 -c:v copy -f mxf "output.mxf" }}} Expected behavior: FFMpeg muxes the file in mxf or whatever container you pick. Actual behavior: FFMpeg keeps allocating RAM until it crashes with no clear progress. In the following example, I'm trying to use the newly encoded H264 stream and the audio from Avisynth on a real file to then re-encode the audio in PCM 24bit 48000Hz little endian and mux the whole thing in mxf [[Image(https://i.imgur.com/NJGfFUV.png)]] [[Image(https://i.imgur.com/jTPU3OZ.png)]] [[Image(https://i.imgur.com/LjoFkkQ.png)]] That's the latest master from today, namely N-114842-g639013aafc from the 17th of April 2024. Using version N-97504-g1128aa8 from 2020 works instead with the exact same commands, which points to a regression. -- Ticket URL: <https://trac.ffmpeg.org/ticket/10966> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 1

#5413(ffmpeg:new): Image size, pixel format cannot be detected ( 0x0, -1 ) for short h264 video
by FFmpeg 02 Aug '25

02 Aug '25

#5413: Image size, pixel format cannot be detected ( 0x0,-1 ) for short h264 video -------------------------------------+------------------------------------- Reporter: sadensmol | Type: defect Status: new | Priority: normal Component: ffmpeg | Version: Keywords: image size | unspecified 0x0 | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Cannot convert video which plays fine with Windows Media Player. ffmpeg parameters ( splitted by comma) -probesize,100M,-analyzeduration,100M,-i,00443.MTS,-an,-y,-c:v,mjpeg,-q:v,8,frame%d.jpg ffmpeg output: [mpegts @ 0x7ffcd9808800] Could not find codec parameters for stream 0 (Video: h264 (HDMV / 0x564D4448), none): unspecified size Consider increasing the value for the 'analyzeduration' and 'probesize' options Input #0, mpegts, from '/Users/saden/Documents/asimon/simplevideoed/test/folder8/00443.MTS': Duration: 00:00:00.51, start: 1.033367, bitrate: 9216 kb/s Program 1 Stream #0:0[0x1011]: Video: h264 (HDMV / 0x564D4448), none, 29.97 fps, 29.97 tbr, 90k tbn, 180k tbc Stream #0:1[0x1100]: Audio: ac3 (AC-3 / 0x332D4341), 48000 Hz, 5.1(side), fltp, 448 kb/s Stream #0:2[0x1200]: Subtitle: hdmv_pgs_subtitle ([144][0][0][0] / 0x0090), 1920x1080 [buffer @ 0x7ffcd96013c0] Unable to parse option value "0x0" as image size [buffer @ 0x7ffcd96013c0] Unable to parse option value "-1" as pixel format [buffer @ 0x7ffcd96013c0] Unable to parse option value "0x0" as image size [buffer @ 0x7ffcd96013c0] Error setting option video_size to value 0x0. [graph 0 input from stream 0:0 @ 0x7ffcd9601500] Error applying options to the filter. This problem is easily reproducible with the latest version of ffmpeg on both OSX and windows systems. At the same time exiftool returns correct values for size. -- Ticket URL: <https://trac.ffmpeg.org/ticket/5413> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 9

#11295(avcodec:new): Decoding p1_03.j2k returns a warning
by FFmpeg 02 Aug '25

02 Aug '25

#11295: Decoding p1_03.j2k returns a warning -------------------------------------+------------------------------------- Reporter: Pierre- | Type: Anthony Lemieux | enhancement Status: new | Priority: normal Component: avcodec | Version: git- | master Keywords: j2k | Blocked By: Blocking: | Reproduced by developer: 1 Analyzed by developer: 0 | -------------------------------------+------------------------------------- Reported by Osamu Watanabe <owatanab(a)es.takushoku-u.ac.jp> Decoding p1_03.j2k (a test codestream defined in the ISO/IEC 15444-4) returns the following warning: {{{ [jpeg2000 @ 0x12d7079a0] Mid mismatch 1 in pass 18 of 22 }}} This message comes from the lines: https://github.com/ffmpeg/ffmpeg/blob/2eb9c35010fe2c65a6d0f9a420332bca369c5… The cause of the warning should be investigated to suppress the warning. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11295> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker

1 1