April 2026 - ffmpeg-devel - lists.ffmpeg.org

[PATCH] avcodec/cbs_h266: fix wrong condition for chroma MTT depth in PH
by Mou Fan 07 May '26

07 May '26

In the picture header parser, the chroma branch incorrectly tested sps_max_mtt_hierarchy_depth_intra_slice_chroma to decide whether to parse ph_log2_diff_max_{bt,tt}_min_qt_intra_slice_chroma. Per ITU-T H.266 (V4, 01/2026) section 7.3.2.8 "Picture header structure syntax", the condition is on the just-parsed ph_max_mtt_hierarchy_depth_intra_slice_chroma, exactly mirroring the luma branch a few lines above and the inter-slice branch below. sps_partition_constraints_override_enabled_flag allows the picture header to override the SPS values, so testing the SPS field is incorrect and desynchronises the parser whenever the PH override changes the chroma MTT depth from/to zero. Signed-off-by: Mou Fan <moufan17(a)126.com> --- libavcodec/cbs_h266_syntax_template.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/cbs_h266_syntax_template.c b/libavcodec/cbs_h266_syntax_template.c index 98a8954943..fc79ba46c7 100644 --- a/libavcodec/cbs_h266_syntax_template.c +++ b/libavcodec/cbs_h266_syntax_template.c @@ -2819,7 +2819,7 @@ static int FUNC(picture_header) (CodedBitstreamContext *ctx, RWContext *rw, 0, FFMIN(6, ctb_log2_size_y) - min_cb_log2_size_y); ue(ph_max_mtt_hierarchy_depth_intra_slice_chroma, 0, 2 * (ctb_log2_size_y - min_cb_log2_size_y)); - if (sps->sps_max_mtt_hierarchy_depth_intra_slice_chroma != 0) { + if (current->ph_max_mtt_hierarchy_depth_intra_slice_chroma != 0) { unsigned int min_qt_log2_size_intra_c = current->ph_log2_diff_min_qt_min_cb_intra_slice_chroma + min_cb_log2_size_y; -- 2.39.3

3 3

Re: [FFmpeg-devel] [PATCH 2/3] libavcodec: add NETINT Quadra HW decoders & encoders
by Desmond Liu 04 May '26

04 May '26

Hi Kieran, > Roughly one year ago I tried to buy one of these and I was asked to sign an > NDA. That was a "bug". You do not need to sign an NDA. If you have difficulty obtaining our hardware, contact me. Desmond

2 10

RFC: Resolution change in filter graphs
by Nicolas George 02 May '26

02 May '26

Hi. I am trying to decide the right way to fix the design flaw behind this reported crash: https://lists.ffmpeg.org/lore/ffmpeg-devel/20260410120900.1757473-1-hurtsec… Preamble: Proper support for format change in a filter graph is not for tomorrow. It requires sub-graph renegotiation, which in turns requires identifying exactly the parts of the graph that need renegotiation or reinitialization. (And in particular it requires that format conversion happen at single places.) But right now, we have a quick-and-dirty support for resolution changes that works when filters do not care about changes because they do not pre-allocate or pre-compute things at init time. There are enough to be useful. But quick-and-so-dirty-it-crashes is not acceptable, so we need to cleat this up a bit. Right now, the template for filters that actively support and can cause resolution changes is the scale filter, and it works like that: (1) it detects resolution changes by the mismatch of width and/or height values between the input frame and the input link; (2) when a resolution changes happens, either from input or from the logic of the filter (“eval=frame” and formulas that depend on t or n), it updates the value of both input and output links. But if two filters using that logic are directly connected together, the second one will miss the change because the first one will have updated the values on their shared link. You can observe it by inserting some debug message in vf_scale.c:scale_frame() to report frame_changed. Here is an example filter graph: testsrc2=s=640x480, scale=32*(1+15*mod(n\,2)):24*(16-15*mod(n\,2)):eval=frame, showinfo, scale=640:480 Remove showinfo and the debug message in the second scale filter no longer reports any change. The solution I am inclined to favor is: never update the resolution on the links, just leave it at what it was at init time. - If filters do not care about resolution change, then let them just use the resolution from the frame. - If filters need to detect resolution change, let them make the comparison with something in their own private context. I checked, and it seems the frame pool system will work with that, it does not use the resolution from the link, only from the get_buffer() calls. Optionally, we could have the framework set the resolution to an invalid value, 0×0 or -1×-1: that way, if the code reaches a pace it should not, the error will stand out. Before I start working on that, I would appreciate comments by other people who know the code. It is possible I am missing something. Regards, -- Nicolas George

2 3

[PATCH 1/2] lavfi/vf_scale: simplify indirections
by Nicolas George 02 May '26

02 May '26

link is always input[0]. Signed-off-by: Nicolas George <george(a)nsup.org> --- libavfilter/vf_scale.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) Very low-hanging fruit while I am looking at how to handle format changes. Will probably push without waiting a lot. diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c index d113298ff0..4acfe573aa 100644 --- a/libavfilter/vf_scale.c +++ b/libavfilter/vf_scale.c @@ -799,14 +799,14 @@ static int scale_frame(AVFilterLink *link, AVFrame **frame_in, scale->var_values[VAR_T] = TS2T(in->pts, link->time_base); } - link->dst->inputs[0]->format = in->format; - link->dst->inputs[0]->w = in->width; - link->dst->inputs[0]->h = in->height; - link->dst->inputs[0]->colorspace = in->colorspace; - link->dst->inputs[0]->color_range = in->color_range; - - link->dst->inputs[0]->sample_aspect_ratio.den = in->sample_aspect_ratio.den; - link->dst->inputs[0]->sample_aspect_ratio.num = in->sample_aspect_ratio.num; + link->format = in->format; + link->w = in->width; + link->h = in->height; + link->colorspace = in->colorspace; + link->color_range = in->color_range; + + link->sample_aspect_ratio.den = in->sample_aspect_ratio.den; + link->sample_aspect_ratio.num = in->sample_aspect_ratio.num; if ((ret = config_props(outlink)) < 0) goto err; -- 2.53.0

1 2

.caf container missing from the new ffmpeg 8.1
by Klaus Jakobsen 02 May '26

02 May '26

Hi all, I have just updated to the new shared version of ffmpeg, and I'm noticing that the .caf container is now missing. This container was present in the 8.0 version of ffmpeg. The .caf format is very useful, it is the only container which allows opus audio on a lot of older iPhone models. Can't the 8.0 code be used in the 8.1 version? I get this when trying to output Opus audio in a .caf format using ffmpeg 8.1 15:30:46.402 [00000A40] [caf @ 000002285B296200] [Error] muxing codec currently unsupported 15:30:46.402 [00000A40] [out#0/caf @ 000002285B2B0D00] [Error] Could not write header (incorrect codec parameters ?): Not yet implemented in FFmpeg, patches welcome 15:30:46.402 [00000A40] [af#0:0 @ 000002285B294180] [Error] Error sending frames to consumers: Not yet implemented in FFmpeg, patches welcome 15:30:46.404 [00000A40] [af#0:0 @ 000002285B294180] [Error] Task finished with error code: -1163346256 (Not yet implemented in FFmpeg, patches welcome) 15:30:46.404 [00000A40] [af#0:0 @ 000002285B294180] [Error] Terminating thread with return code -1163346256 (Not yet implemented in FFmpeg, patches welcome) 15:30:46.404 [00002868]* [out#0/caf @ 000002285B2B0D00] [Error] Nothing was written into output file, because at least one of its streams received no packets. Best regards, /Klaus Jakobsen /

3 6

[PATCH 1/3] Revert "avfilter/avfiltergraph: always retry format negotiation after auto-filters"
by Nicolas George 01 May '26

01 May '26

This reverts commit 978a0821eeb909d7b2cb777bed03a8fc380e9503. The stability of the negotiation process has never been studied with multiple rounds. It has always been documented to users that scale was the filter to insert to manage format conversions. A second filter for a specific type of conversion should never have been added: the proper fix for the issue that this commit tried to fix is to give scale the ability to handle premultiplication too. Signed-off-by: Nicolas George <george(a)nsup.org> --- libavfilter/avfiltergraph.c | 9 ++++----- tests/fate/filter-video.mak | 3 --- tests/ref/fate/filter-scale-premultiply | 15 --------------- 3 files changed, 4 insertions(+), 23 deletions(-) delete mode 100644 tests/ref/fate/filter-scale-premultiply Out of courtesy, I refrain from writing in the commit message that this patch was pushed despite my objections and after only a review by somebody who does not know the code. diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c index ad81d91bbc..f1abcc80b4 100644 --- a/libavfilter/avfiltergraph.c +++ b/libavfilter/avfiltergraph.c @@ -701,11 +701,10 @@ retry: } } - /* if there is an auto filter, we may need another round to fully - * settle formats due to possible cross-incompatibilities between - * the auto filters themselves, or between the auto filters and - * a different attribute of the filter they are modifying */ - if (num_conv) + /* if there is more than one auto filter, we may need another round + * to fully settle formats due to possible cross-incompatibilities + * between the auto filters themselves */ + if (num_conv > 1) goto retry; } } diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak index 5016ea9d4d..d11de0ce86 100644 --- a/tests/fate/filter-video.mak +++ b/tests/fate/filter-video.mak @@ -849,9 +849,6 @@ FATE_FILTER-$(call ALLYES, TESTSRC2_FILTER SPLIT_FILTER AVGBLUR_FILTER \ METADATA_FILTER WRAPPED_AVFRAME_ENCODER NULL_MUXER \ PIPE_PROTOCOL) += $(FATE_FILTER_REFCMP_METADATA-yes) -FATE_FILTER-$(call FILTERFRAMECRC, TESTSRC SCALE PREMULTIPLY, LAVFI_INDEV) += fate-filter-scale-premultiply -fate-filter-scale-premultiply: CMD = framecrc -auto_conversion_filters -lavfi "testsrc,format=rgba,setparams=alpha_mode=premultiplied,format=rgba:alpha_modes=straight" -frames:v 10 - FATE_SAMPLES_FFPROBE += $(FATE_METADATA_FILTER-yes) FATE_SAMPLES_FFMPEG += $(FATE_FILTER_SAMPLES-yes) FATE_FFPROBE += $(FATE_FILTER_FFPROBE-yes) diff --git a/tests/ref/fate/filter-scale-premultiply b/tests/ref/fate/filter-scale-premultiply deleted file mode 100644 index 13fd79310a..0000000000 --- a/tests/ref/fate/filter-scale-premultiply +++ /dev/null @@ -1,15 +0,0 @@ -#tb 0: 1/25 -#media_type 0: video -#codec_id 0: rawvideo -#dimensions 0: 320x240 -#sar 0: 1/1 -0, 0, 0, 1, 307200, 0x73a3b71f -0, 1, 1, 1, 307200, 0x3f05f047 -0, 2, 2, 1, 307200, 0x50382370 -0, 3, 3, 1, 307200, 0x41a15136 -0, 4, 4, 1, 307200, 0xbc8c78ee -0, 5, 5, 1, 307200, 0x19839e1b -0, 6, 6, 1, 307200, 0x8545b93b -0, 7, 7, 1, 307200, 0x4a4acf07 -0, 8, 8, 1, 307200, 0xefa1dee4 -0, 9, 9, 1, 307200, 0x22dae9ca -- 2.53.0

2 4

Threading generalization
by Nicolas George 01 May '26

01 May '26

Hi. I had started a long mail with all my thoughts about it, then I procrastinated finished it. Let me make it short. We already have multiple threading subsystems: frame and slice threading in lavc, slice threading in lavfi, the UDP thread, I must be forgetting one or two. Before somebody considers adding one, like inter-filter threading in lavfi, I hope we will discuss unifying all that into a single multi-threaded event loop and tasks scheduler. We also need that for non-trivial network protocols. It is a very big task, but I think it is the necessary next step for our code. Regards, -- Nicolas George

3 4

[ANNOUNCE] Forgejo Fairy
by Michael Niedermayer 01 May '26

01 May '26

Hi everyone Last easterbunny brought eggs and in one egg there was a life fairy. She said her name is forgejo fairy and she wants to help the project and community. She is still quite young so please be gentle with her, ATM what she can do is * scan pull requests for ones that are stale. More precissely + No activity for 7 days and + open and + not WIP and + CI passes and + mergable = no conflicts and + no open change requests and + activity since the last fairy reaction or no previous and * she can read the patches, files patched and around 5000 files from FFmpeg git HEAD as well as all past comments in the PR * she will try to review the changes and write a clean and concise comment also considering past comments so as no to add redudant information * if EVERYTHING lines up she will approve the PR this will not on its own trigger any merge. Only if some human developer clicks the merge/rebase button or has previously set the PR to auto merge will that trigger a merge (this affects ATM at maximum 6 PRs) * you can add her to the reviewer of a PR and that will decrease the "No activity" time to 1 day for that PR Initially, i will set the "No activity time" to 56 days so she will only process teh very stalest PRs and then slowly decrease it Also it will be run by hand not by cron job first and manually supervised. (that means i should be able to stop anything outrageous but i certainly will not recognize incorrect reviews) My expectation is that >50% of the reviews will be usefull As she grows she will gain more abilities How to opt out? Get a human review before the 7-56 days Examples: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20005#issuecomment-36271 https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20059#issuecomment-36273 Thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf

11 32

[PR] avformat/avidec: validate INFO list size before parsing (PR #22978)
by michaelni 30 Apr '26

30 Apr '26

PR #22978 opened by michaelni URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/22978 Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/22978.patch Reject INFO list chunks that are too small to contain the expected 4-byte list type field before calling ff_read_riff_info(). The parser subtracts 4 from the list size when handing the remaining payload to ff_read_riff_info(). If the chunk is smaller than 4 bytes, that underflows the expected structure and should be treated as invalid input. Fixes: DFVULN-607 *Vulnerability reported by Zhenpeng (Leo) Lin at depthfirst* *Patch validated by Zheng Yu at depthfirst* From 4e183d2d1c0a79100384c5ceb443ad9ab66b760f Mon Sep 17 00:00:00 2001 From: "depthfirst-dev[bot]" <1012587+depthfirst-dev[bot](a)users.noreply.github.com> Date: Thu, 23 Apr 2026 02:47:11 +0000 Subject: [PATCH] avformat/avidec: validate INFO list size before parsing Reject INFO list chunks that are too small to contain the expected 4-byte list type field before calling ff_read_riff_info(). The parser subtracts 4 from the list size when handing the remaining payload to ff_read_riff_info(). If the chunk is smaller than 4 bytes, that underflows the expected structure and should be treated as invalid input. Fixes: DFVULN-607 *Vulnerability reported by Zhenpeng (Leo) Lin at depthfirst* *Patch validated by Zheng Yu at depthfirst* --- libavformat/avidec.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/libavformat/avidec.c b/libavformat/avidec.c index eb9bfb15ea..db01244853 100644 --- a/libavformat/avidec.c +++ b/libavformat/avidec.c @@ -562,9 +562,11 @@ static int avi_read_header(AVFormatContext *s) avi->movi_end = avi->fsize; av_log(s, AV_LOG_TRACE, "movi end=%"PRIx64"\n", avi->movi_end); goto end_of_header; - } else if (tag1 == MKTAG('I', 'N', 'F', 'O')) + } else if (tag1 == MKTAG('I', 'N', 'F', 'O')) { + if (size < 4) + return AVERROR_INVALIDDATA; ff_read_riff_info(s, size - 4); - else if (tag1 == MKTAG('n', 'c', 'd', 't')) + } else if (tag1 == MKTAG('n', 'c', 'd', 't')) avi_read_nikon(s, list_end); break; -- 2.52.0

1 0

[PR] avformat/rtpdec_jpeg: check qtable_len (PR #22977)
by michaelni 30 Apr '26

30 Apr '26

PR #22977 opened by michaelni URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/22977 Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/22977.patch Fixes: out of array access Fixes: 605/pc.py Based-on patch by depthfirst *Reporter: Zhenpeng (Leo) Lin at depthfirst* From 244148030682f182f388b2c632db055e03dd6a33 Mon Sep 17 00:00:00 2001 From: Michael Niedermayer <michael(a)niedermayer.cc> Date: Thu, 23 Apr 2026 00:23:57 +0000 Subject: [PATCH] avformat/rtpdec_jpeg: check qtable_len Fixes: out of array access Fixes: 605/pc.py Based-on patch by depthfirst *Reporter: Zhenpeng (Leo) Lin at depthfirst* --- libavformat/rtpdec_jpeg.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/libavformat/rtpdec_jpeg.c b/libavformat/rtpdec_jpeg.c index 4d9ee0d754..1e35378094 100644 --- a/libavformat/rtpdec_jpeg.c +++ b/libavformat/rtpdec_jpeg.c @@ -276,6 +276,12 @@ static int jpeg_parse_packet(AVFormatContext *ctx, PayloadContext *jpeg, av_log(ctx, AV_LOG_WARNING, "Only 8-bit precision is supported.\n"); if (qtable_len > 0) { + if (qtable_len != 128) { + av_log(ctx, AV_LOG_ERROR, "Invalid RTP/JPEG packet. Invalid qtable length %d.\n", qtable_len); + if (qtable_len%64 || qtable_len > 4*64) + return AVERROR_INVALIDDATA; + } + if (len < qtable_len) { av_log(ctx, AV_LOG_ERROR, "Too short RTP/JPEG packet.\n"); return AVERROR_INVALIDDATA; -- 2.52.0

1 0