March 2026 - ffmpeg-devel - lists.ffmpeg.org

[PATCH] avfilter: enhance command processing with chain propagation and direction control. (PR #20731)
by cenzhanquan1 05 Jun '26

05 Jun '26

PR #20731 opened by cenzhanquan1 URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20731 Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20731.patch The existing avfilter_process_command and avfilter_graph_send_command havelimitations in command propagation: they only handle commands for individualfilters and lack the ability to propagate commands through the entire filterchain, nor do they support directional traversal of the filter graph. Thismakes it difficult to control multiple filters in a chain (e.g., adjustingvolume for all related filters or enabling/disabling a series of filters)with a single command. This patch enhances the command processing logic to address these issues: Add two new flags to control command propagation: AVFILTER_CMD_FLAG_CHAIN: Enables command propagation through the entire filter chain. After processing the current filter, it traverses all associated links (inputs/outputs based on direction) and recursively forwards the command to subsequent filters, covering the full filter topology. AVFILTER_CMD_FLAG_REVERSE: Works with AVFILTER_CMD_FLAG_CHAIN to control traversal direction. Default (forward) follows data flow (source → destination filters), while reverse traversal goes against data flow (destination → source filters). Refactor avfilter_process_command to integrate chain propagation logic: Process the command for the current filter first, then check if chain propagation is enabled. Traverse all relevant links (inputs for reverse, outputs for forward) and recursively forward the command to next-level filters. Track processing status (processed) to determine if any filter in the chain handled the command. Respect AVFILTER_CMD_FLAG_ONE to stop propagation once a filter processes the command, and propagate critical errors. Improve command handling for built-in commands ("ping" and "enable") to workseamlessly with the new propagation logic, ensuring consistent behavioracross the chain. These changes enable flexible command control over entire filter chains,supporting use cases like batch adjustment of filters, topology-wide statuschecks (via "ping"), and coordinated enable/disable operations, whilemaintaining compatibility with existing filter command implementations. Signed-off-by: cenzhanquan1 <cenzhanquan1(a)xiaomi.com> From 9dba682222bd55c952e14e71789a7084529a74f7 Mon Sep 17 00:00:00 2001 From: cenzhanquan1 <cenzhanquan1(a)xiaomi.com> Date: Tue, 21 Oct 2025 17:34:22 +0800 Subject: [PATCH] avfilter: enhance command processing with chain propagation and direction control. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The existing avfilter_process_command and avfilter_graph_send_command havelimitations in command propagation: they only handle commands for individualfilters and lack the ability to propagate commands through the entire filterchain, nor do they support directional traversal of the filter graph. Thismakes it difficult to control multiple filters in a chain (e.g., adjustingvolume for all related filters or enabling/disabling a series of filters)with a single command. This patch enhances the command processing logic to address these issues: Add two new flags to control command propagation: AVFILTER_CMD_FLAG_CHAIN: Enables command propagation through the entire filter chain. After processing the current filter, it traverses all associated links (inputs/outputs based on direction) and recursively forwards the command to subsequent filters, covering the full filter topology. AVFILTER_CMD_FLAG_REVERSE: Works with AVFILTER_CMD_FLAG_CHAIN to control traversal direction. Default (forward) follows data flow (source → destination filters), while reverse traversal goes against data flow (destination → source filters). Refactor avfilter_process_command to integrate chain propagation logic: Process the command for the current filter first, then check if chain propagation is enabled. Traverse all relevant links (inputs for reverse, outputs for forward) and recursively forward the command to next-level filters. Track processing status (processed) to determine if any filter in the chain handled the command. Respect AVFILTER_CMD_FLAG_ONE to stop propagation once a filter processes the command, and propagate critical errors. Improve command handling for built-in commands ("ping" and "enable") to workseamlessly with the new propagation logic, ensuring consistent behavioracross the chain. These changes enable flexible command control over entire filter chains,supporting use cases like batch adjustment of filters, topology-wide statuschecks (via "ping"), and coordinated enable/disable operations, whilemaintaining compatibility with existing filter command implementations. Signed-off-by: cenzhanquan1 <cenzhanquan1(a)xiaomi.com> --- libavfilter/avfilter.c | 75 +++++++++++++++++++++++++++++++++--------- libavfilter/avfilter.h | 10 ++++-- 2 files changed, 67 insertions(+), 18 deletions(-) diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c index 169c2baa42..68ec9f6f6a 100644 --- a/libavfilter/avfilter.c +++ b/libavfilter/avfilter.c @@ -607,25 +607,68 @@ static int set_enable_expr(FFFilterContext *ctxi, const char *expr) return 0; } -int avfilter_process_command(AVFilterContext *filter, const char *cmd, const char *arg, char *res, int res_len, int flags) +int avfilter_process_command(AVFilterContext *filter, const char *cmd, const char *arg, + char *res, int res_len, int flags) { - if(!strcmp(cmd, "ping")){ - char local_res[256] = {0}; + int direction = flags & AVFILTER_CMD_FLAG_REVERSE; + int ret = AVERROR(ENOSYS); + int processed = 0; - if (!res) { - res = local_res; - res_len = sizeof(local_res); - } - av_strlcatf(res, res_len, "pong from:%s %s\n", filter->filter->name, filter->name); - if (res == local_res) - av_log(filter, AV_LOG_INFO, "%s", res); - return 0; - }else if(!strcmp(cmd, "enable")) { - return set_enable_expr(fffilterctx(filter), arg); - }else if (fffilter(filter->filter)->process_command) { - return fffilter(filter->filter)->process_command(filter, cmd, arg, res, res_len, flags); + int process_flags = flags & ~AVFILTER_CMD_FLAG_CHAIN; + if (!strcmp(cmd, "ping")) { + char local_res[256] = {0}; + char *res_buf = res ? res : local_res; + size_t buf_len = res ? res_len : sizeof(local_res); + av_strlcatf(res_buf, buf_len, "pong from:%s %s\n", + filter->filter->name, filter->name ? filter->name : "unknown"); + if (!res) + av_log(filter, AV_LOG_INFO, "%s", res_buf); + ret = 0; + } else if (!strcmp(cmd, "enable")) { + ret = set_enable_expr(fffilterctx(filter), arg); + } else if (fffilter(filter->filter)->process_command) { + ret = fffilter(filter->filter)->process_command(filter, cmd, arg, res, res_len, process_flags); + } else { + ret = AVERROR(ENOSYS); } - return AVERROR(ENOSYS); + + if (ret != AVERROR(ENOSYS)) { + processed = 1; + if ((flags & AVFILTER_CMD_FLAG_ONE) || ret < 0) { + return ret; + } + } + + if (!(flags & AVFILTER_CMD_FLAG_CHAIN)) { + return processed ? 0 : AVERROR(ENOSYS); + } + + av_log(filter, AV_LOG_DEBUG, + "cmd_chain: [%s] dir:%s -> '%s' '%s' (forwarding)\n", + filter->name ? filter->name : "unknown", + direction ? "reverse" : "forward", + cmd, arg ? arg : ""); + + unsigned nb_links = direction ? filter->nb_inputs : filter->nb_outputs; + for (int i = 0; i < nb_links; i++) { + AVFilterLink *link = direction ? filter->inputs[i] : filter->outputs[i]; + AVFilterContext *next_filter = direction ? (link ? link->src : NULL) : (link ? link->dst : NULL); + + if (!link || !next_filter) { + av_log(filter, AV_LOG_DEBUG, "Invalid %s link at pad %d\n", + direction ? "input" : "output", i); + continue; + } + + ret = avfilter_process_command(next_filter, cmd, arg, res, res_len, flags); + if (ret >= 0) { + processed = 1; + } else if (ret != AVERROR(ENOSYS)) { + return ret; + } + } + + return processed ? 0 : AVERROR(ENOSYS); } unsigned avfilter_filter_pad_count(const AVFilter *filter, int is_output) diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h index 02b58c42c2..fde3811dc3 100644 --- a/libavfilter/avfilter.h +++ b/libavfilter/avfilter.h @@ -466,8 +466,14 @@ struct AVFilterLink { int avfilter_link(AVFilterContext *src, unsigned srcpad, AVFilterContext *dst, unsigned dstpad); -#define AVFILTER_CMD_FLAG_ONE 1 ///< Stop once a filter understood the command (for target=all for example), fast filters are favored automatically -#define AVFILTER_CMD_FLAG_FAST 2 ///< Only execute command when its fast (like a video out that supports contrast adjustment in hw) +#define AVFILTER_CMD_FLAG_ONE 1 ///< Stop once a filter understood the command (for target=all for example), fast filters are favored automatically +#define AVFILTER_CMD_FLAG_FAST 2 ///< Only execute command when its fast (like a video out that supports contrast adjustment in hw) +#define AVFILTER_CMD_FLAG_CHAIN 4 ///< Propagate the command through the entire filter chain. After processing the current filter, + /// traverse all its associated links (inputs or outputs, based on direction) and recursively + /// forward the command to subsequent filters, covering the full filter topology. +#define AVFILTER_CMD_FLAG_REVERSE 8 ///< Only effective when paired with AVFILTER_CMD_FLAG_CHAIN. Changes the command's traversal + /// direction in the chain: default (forward) follows data flow (source → destination filters), + /// while reverse traversal opposes data flow (destination → source filters). /** * Make the filter instance process a command. -- 2.49.1

5 11

[PATCH] avcodec/x86/h264_intrapred: add AVX2 for 10-bit pred16x16 functions
by ZaneHam 12 May '26

12 May '26

Add AVX2 implementations for 10-bit H.264 16x16 intra prediction: - pred16x16_vertical_10 - pred16x16_horizontal_10 - pred16x16_dc_10 - pred16x16_top_dc_10 - pred16x16_left_dc_10 - pred16x16_128_dc_10 10-bit 16x16 blocks are 32 bytes per row, perfectly matching AVX2's 256-bit YMM registers, allowing single-instruction row operations versus two XMM operations with SSE2. checkasm benchmarks on Zen3 (cycles, lower is better): C SSE2 AVX2 pred16x16_dc_10 65.7 40.3 27.3 (1.48x vs SSE2) pred16x16_128_dc_10 31.1 28.1 21.4 (1.31x vs SSE2) pred16x16_horizontal 67.8 28.1 21.6 (1.30x vs SSE2) pred16x16_left_dc_10 55.6 35.0 22.9 (1.53x vs SSE2) pred16x16_top_dc_10 49.5 32.3 21.8 (1.48x vs SSE2) pred16x16_vertical_10 32.3 28.3 24.1 (1.17x vs SSE2) --- libavcodec/x86/h264_intrapred_10bit.asm | 186 ++++++++++++++++++++++++ libavcodec/x86/h264_intrapred_init.c | 14 ++ 2 files changed, 200 insertions(+) diff --git a/libavcodec/x86/h264_intrapred_10bit.asm b/libavcodec/x86/h264_intrapred_10bit.asm index 2f30807332..78e2f263bc 100644 --- a/libavcodec/x86/h264_intrapred_10bit.asm +++ b/libavcodec/x86/h264_intrapred_10bit.asm @@ -1117,3 +1117,189 @@ cglobal pred16x16_128_dc_10, 2,3 dec r2d jg .loop RET + +;----------------------------------------------------------------------------- +; AVX2 versions of pred16x16 10-bit functions +; For 10-bit: 16 pixels * 2 bytes = 32 bytes = 1 YMM register (perfect match\!) +;----------------------------------------------------------------------------- + +%if HAVE_AVX2_EXTERNAL + +;----------------------------------------------------------------------------- +; void ff_pred16x16_vertical_10_avx2(pixel *src, ptrdiff_t stride) +;----------------------------------------------------------------------------- +INIT_YMM avx2 +cglobal pred16x16_vertical_10, 2, 4 + sub r0, r1 + movu m0, [r0] ; Load all 16 pixels (32 bytes) from top row + mov r2d, 4 + lea r3, [r1*3] +.loop: + movu [r0+r1*1], m0 + movu [r0+r1*2], m0 + movu [r0+r3 ], m0 + lea r0, [r0+r1*2] + movu [r0+r1*2], m0 + lea r0, [r0+r1*2] + dec r2d + jg .loop + RET + +;----------------------------------------------------------------------------- +; void ff_pred16x16_horizontal_10_avx2(pixel *src, ptrdiff_t stride) +;----------------------------------------------------------------------------- +INIT_YMM avx2 +cglobal pred16x16_horizontal_10, 2, 4 + lea r2, [r1*3] + mov r3d, 4 +.loop: + vpbroadcastw m0, [r0-2] + movu [r0], m0 + vpbroadcastw m0, [r0+r1-2] + movu [r0+r1], m0 + vpbroadcastw m0, [r0+r1*2-2] + movu [r0+r1*2], m0 + vpbroadcastw m0, [r0+r2-2] + movu [r0+r2], m0 + lea r0, [r0+r1*4] + dec r3d + jg .loop + RET + +;----------------------------------------------------------------------------- +; void ff_pred16x16_dc_10_avx2(pixel *src, ptrdiff_t stride) +; DC = (sum of 16 top pixels + sum of 16 left pixels + 16) >> 5 +;----------------------------------------------------------------------------- +INIT_YMM avx2 +cglobal pred16x16_dc_10, 2, 6 + mov r5, r0 ; Save dest pointer + sub r0, r1 + movu m0, [r0] ; Load top row (32 bytes) + vextracti128 xm1, m0, 1 ; Get high 128 bits + paddw xm0, xm1 ; Sum to 8 words + phaddw xm0, xm0 ; 4 words + phaddw xm0, xm0 ; 2 words + phaddw xm0, xm0 ; 1 word (top sum in low word) + movd r3d, xm0 + and r3d, 0xFFFF ; Keep only low 16 bits + + ; Sum left column using lea-based pointer advancement + lea r0, [r0+r1-2] ; Point to left pixel of row 0 + movzx r4d, word [r0] + add r3d, r4d + movzx r4d, word [r0+r1] + add r3d, r4d +%rep 7 + lea r0, [r0+r1*2] + movzx r4d, word [r0] + add r3d, r4d + movzx r4d, word [r0+r1] + add r3d, r4d +%endrep + add r3d, 16 ; Rounding + shr r3d, 5 ; Divide by 32 + + movd xm0, r3d + vpbroadcastw m0, xm0 ; Broadcast to all 16 words + + ; Fill all 16 rows + mov r3d, 4 + lea r4, [r1*3] +.loop: + movu [r5+r1*0], m0 + movu [r5+r1*1], m0 + movu [r5+r1*2], m0 + movu [r5+r4 ], m0 + lea r5, [r5+r1*4] + dec r3d + jg .loop + RET + +;----------------------------------------------------------------------------- +; void ff_pred16x16_top_dc_10_avx2(pixel *src, ptrdiff_t stride) +; DC = (sum of 16 top pixels + 8) >> 4 +;----------------------------------------------------------------------------- +INIT_YMM avx2 +cglobal pred16x16_top_dc_10, 2, 4 + sub r0, r1 + movu m0, [r0] ; Load top row + vextracti128 xm1, m0, 1 + paddw xm0, xm1 + phaddw xm0, xm0 + phaddw xm0, xm0 + phaddw xm0, xm0 + paddw xm0, [pw_8] ; Add 8 for rounding + psrlw xm0, 4 ; Divide by 16 + vpbroadcastw m0, xm0 + + mov r2d, 4 + lea r3, [r1*3] +.loop: + movu [r0+r1*1], m0 + movu [r0+r1*2], m0 + movu [r0+r3 ], m0 + lea r0, [r0+r1*2] + movu [r0+r1*2], m0 + lea r0, [r0+r1*2] + dec r2d + jg .loop + RET + +;----------------------------------------------------------------------------- +; void ff_pred16x16_left_dc_10_avx2(pixel *src, ptrdiff_t stride) +; DC = (sum of 16 left pixels + 8) >> 4 +;----------------------------------------------------------------------------- +INIT_YMM avx2 +cglobal pred16x16_left_dc_10, 2, 5 + mov r4, r0 ; Save dest pointer + + ; Sum left column using lea-based pointer advancement + sub r0, 2 ; Point to left pixel of row 0 + movzx r2d, word [r0] + movzx r3d, word [r0+r1] +%rep 7 + lea r0, [r0+r1*2] + movzx eax, word [r0] + add r2d, eax + movzx eax, word [r0+r1] + add r3d, eax +%endrep + lea r2d, [r2+r3+8] ; Sum with rounding + shr r2d, 4 ; Divide by 16 + + movd xm0, r2d + vpbroadcastw m0, xm0 + + ; Fill all 16 rows + mov r2d, 4 + lea r3, [r1*3] +.loop: + movu [r4+r1*0], m0 + movu [r4+r1*1], m0 + movu [r4+r1*2], m0 + movu [r4+r3 ], m0 + lea r4, [r4+r1*4] + dec r2d + jg .loop + RET + +;----------------------------------------------------------------------------- +; void ff_pred16x16_128_dc_10_avx2(pixel *src, ptrdiff_t stride) +; Fill with constant 512 (1 << 9 for 10-bit midpoint) +;----------------------------------------------------------------------------- +INIT_YMM avx2 +cglobal pred16x16_128_dc_10, 2, 4 + vpbroadcastw m0, [pw_512] + mov r2d, 4 + lea r3, [r1*3] +.loop: + movu [r0+r1*0], m0 + movu [r0+r1*1], m0 + movu [r0+r1*2], m0 + movu [r0+r3 ], m0 + lea r0, [r0+r1*4] + dec r2d + jg .loop + RET + +%endif ; HAVE_AVX2_EXTERNAL diff --git a/libavcodec/x86/h264_intrapred_init.c b/libavcodec/x86/h264_intrapred_init.c index aa9bc721f0..6918c7f985 100644 --- a/libavcodec/x86/h264_intrapred_init.c +++ b/libavcodec/x86/h264_intrapred_init.c @@ -97,6 +97,12 @@ PRED16x16(128_dc, 10, sse2) PRED16x16(left_dc, 10, sse2) PRED16x16(vertical, 10, sse2) PRED16x16(horizontal, 10, sse2) +PRED16x16(dc, 10, avx2) +PRED16x16(top_dc, 10, avx2) +PRED16x16(128_dc, 10, avx2) +PRED16x16(left_dc, 10, avx2) +PRED16x16(vertical, 10, avx2) +PRED16x16(horizontal, 10, avx2) /* 8-bit versions */ PRED16x16(vertical, 8, sse) @@ -328,5 +334,13 @@ av_cold void ff_h264_pred_init_x86(H264PredContext *h, int codec_id, h->pred8x8l[VERT_RIGHT_PRED ] = ff_pred8x8l_vertical_right_10_avx; h->pred8x8l[HOR_UP_PRED ] = ff_pred8x8l_horizontal_up_10_avx; } + if (EXTERNAL_AVX2(cpu_flags)) { + h->pred16x16[DC_PRED8x8 ] = ff_pred16x16_dc_10_avx2; + h->pred16x16[TOP_DC_PRED8x8 ] = ff_pred16x16_top_dc_10_avx2; + h->pred16x16[DC_128_PRED8x8 ] = ff_pred16x16_128_dc_10_avx2; + h->pred16x16[LEFT_DC_PRED8x8 ] = ff_pred16x16_left_dc_10_avx2; + h->pred16x16[VERT_PRED8x8 ] = ff_pred16x16_vertical_10_avx2; + h->pred16x16[HOR_PRED8x8 ] = ff_pred16x16_horizontal_10_avx2; + } } } -- 2.51.0.windows.2

2 1

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

Contributing with command-line alone
by Nicolas George 29 Apr '26

29 Apr '26

Hi. First, an introduction. As part of my job, in the recent months, I had to assist a blind person in getting a braille display to work with modern desktop environments. He was perfectly happy to use mutt and vim to exchange mails and edit files and to use lynx to browse the web. Unfortunately, new administrative requirements demand procedures that only work within a javascript-enabled graphical web browser. Let me tell you, the support for blind people in GNOME is absolute crap: the focus gets lost, the braille display gets desynchronized. Even when it works, navigating between widgets with only the feedback of the braille display is a nightmare. This person is a brilliant mathematician. Had he been on the other side of the corridor, he would have been a brilliant computer scientist and a member of a team who uses FFmpeg in its workflow. The switch to Forgejo as is would have slammed the door at his potential contributions. A few days ago, a friend, who has very poor eyesight without being blind, was telling me that at the zoom level he needs to be able to read the text, most web applications become unusable. Their layout do not scale properly or the widgets take all the place and leave none for the contents. This is a consequence of poor design of the browser APIs with regard to zoomability and poor usage of these APIs by web developers who are thinking about disability only in an abstract matter. These issues are not anecdotal. Sight disabilities are very common. They come for almost everybody with old age. Note that both can be true at the same time: web interfaces can be a progress in visual accessibility over paper procedures, because of zoom and screen readers, and at the same time web interfaces can be a regress in visual accessibility over older tools used by early adopters, that are not encumbered by the flashiness of recent interfaces and have maturated in accessibility over years. The problems with accessibility are not only visual, they are also about the use of the mouse. There are multiple physical and motor disabilities that affect the use of the mouse more than the use of the keyboard, from arthritis to Parkinson's. I know somebody who got a permanent shoulder tendinitis from using the mouse over students' back: she can use a keyboard fine, but using a mouse, even the normal way, is painful. Touchpads or trackballs can help in some cases, they can be worse in other cases. Navigating in a graphical interface without the mouse, mostly with the tab key, can be extremely laborious and frustrating. It is even more so in web applications because the two layers of GUI interfere with each other, and caret browsing can only mitigate it a little. On some web applications, not using the mouse can even just be impossible when developers whip out their own widgets from elements the browser doesn't consider active and on which they just connect onmouse events. These accessibility problems exist in all web-based applications. They exist even more when the web application is young or lesser known, like Forgejo, because mature and famous applications will get pressure to fix them as much as possible. And these accessibility problems map directly to efficiency problems: it can be true at the same time that a web-based patch review system is a progress for people who only know the mail editor of GMail or Thunderbird and a regress for people who have the habit to reply to mail in the very same editor we use for development — Vim or Emacs typically. This is why it is extremely important that all the features of a web-based service be available also as low-level interfaces that can be plugged into more accessible tools. And it needs to be real. Lots of projects have this kind of things as APIs, but so little used that when people try to use them they realize that (1) it takes reimplementing a non-negligible part of the web-app just to reach the ability to use a basic feature and/or (2) the API they need does not work because of limitations or bugs, sometimes reported to the tracker years ago and not fixed. That leads me to the second part of this mail: practical questions about using Forgejo purely in command-line. It is something that was promised by people in favor of using this tool: that everything we could do in command-line, we would still be able to do in command-line, and that they would document how to do it. Time has passed, and that promise has still not been kept. So, proponents of Forgejo, please answer these questions: 1. How do we get a notification for every comment made on any pull request or issue, including threading information about who answers to whom? 2. How do we get notifications for actions done on the project, especially approving or closing a pull request? 3. How do we reply to one of the comments? 4. How do we close a pull request? 5. How do we approve a pull request to have it merged? Regards, -- Nicolas George

5 10

[PATCH] MAINTAINERS: add myself for libavfilter
by Nicolas George 25 Apr '26

25 Apr '26

I have been maintaining the framework and orphaned filters for ages but apparently it was never recorded in this file. Signed-off-by: Nicolas George <george(a)nsup.org> --- MAINTAINERS | 4 ++++ 1 file changed, 4 insertions(+) … but it was common knowledge. diff --git a/MAINTAINERS b/MAINTAINERS index fe4bcc69b0..1d74bcb512 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -316,6 +316,10 @@ libavfilter =========== Generic parts: + + Famework and orphaned filters Nicolas George + (except hardware acceleration) + graphdump.c Nicolas George motion_estimation.c Davinder Singh -- 2.47.2

3 4

[PATCH] configure: use ./src instead of src
by Nicolas George 25 Apr '26

25 Apr '26

Fix “do "src/doc/t2h.pm" failed, '.' is no longer in @INC; did you mean do "./src/doc/t2h.pm"?” when we have such a symlink. Signed-off-by: Nicolas George <george(a)nsup.org> --- configure | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure b/configure index 998b0292b8..46ae0297a3 100755 --- a/configure +++ b/configure @@ -4392,7 +4392,7 @@ mkdir -p ffbuild if test -f configure; then source_path=. elif test -f src/configure; then - source_path=src + source_path=./src else source_path=$(cd $(dirname "$0"); pwd) case "$source_path" in @@ -6220,7 +6220,7 @@ link_name=$(mktemp -u $TMPDIR/name_XXXXXXXX) mkdir "$link_dest" $ln_s "$link_dest" "$link_name" touch "$link_dest/test_file" -if [ "$source_path" != "." ] && [ "$source_path" != "src" ] && ([ ! -d src ] || [ -L src ]) && [ -e "$link_name/test_file" ]; then +if [ "$source_path" != "." ] && [ "$source_path" != "./src" ] && ([ ! -d src ] || [ -L src ]) && [ -e "$link_name/test_file" ]; then # create link to source path [ -e src ] && rm src $ln_s "$source_path" src -- 2.51.0

2 2

[PR] avformat/mxfdec: require keyframes to have random-access bit set (PR #22668)
by deadbeef84 21 Apr '26

21 Apr '26

PR #22668 opened by deadbeef84 URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/22668 Patch URL: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/22668.patch Not all I-frames can be used for random-access, we should also respect bit 7 of the index table entry flags which indicates random access. Refs: https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/22467 From c144fc9da34923fc5235fba77bb8ad450b172a86 Mon Sep 17 00:00:00 2001 From: Jesper Ek <deadbeef84(a)gmail.com> Date: Tue, 31 Mar 2026 15:52:27 +0200 Subject: [PATCH] avformat/mxfdec: require keyframes to have random-access bit set Not all I-frames can be used for random-access, we should also respect bit 7 of the index table entry flags which indicates random access. Refs: https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/22467 --- libavformat/mxfdec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c index 59b9b43a22..2d0849637e 100644 --- a/libavformat/mxfdec.c +++ b/libavformat/mxfdec.c @@ -2101,7 +2101,7 @@ static int mxf_compute_ptses_fake_index(MXFContext *mxf, MXFIndexTable *index_ta break; } - flags[x] = !(s->flag_entries[j] & 0x30) ? AVINDEX_KEYFRAME : 0; + flags[x] = !(s->flag_entries[j] & 0x30) && (s->flag_entries[j] & 0x80) ? AVINDEX_KEYFRAME : 0; if (index < 0 || index >= index_table->nb_ptses) { av_log(mxf->fc, AV_LOG_ERROR, -- 2.52.0

2 1

[GSoC 2026] Proposal/Mentorship Request: VVC x86 SIMD Optimization
by Hank Li 14 Apr '26

14 Apr '26

Hello, I'm a bit late to the party, but I'm interested in proposing a GSoC project on VVC x86 SIMD optimization. This was on the 2025 ideas list but there are currently no SIMD overrides for itx or intra_pred in avcodec/x86/vvc/dsp_init.c, only ALF and inter prediction have x86 assembly. I would like to propose implementing: -AVX2 inverse transforms for DCT-II, DST-VII, and DCT-VIII -Intra prediction for DC, planar, and angular modes -Corresponding checkasm tests and benchmarks For qualification, I'm currently working on a checkasm test for VVC inverse transforms (tests/checkasm/vvc_itx.c). I've emailed Nuo Mi about mentoring since he mentored the VVC SIMD projects in 2023 and 2024. If anyone else is interested in mentoring or has thoughts, I'd appreciate it. Best, Hankang Li

5 7

[PATCH] avcodec/x86/h264_intrapred: Replace pred8x8_top_dc_8_mmxext with SSE2
by Zuxy Meng 07 Apr '26

07 Apr '26

From: zuxy <zuxy.meng(a)gmail.com> More about deprecating MMX than any performance gain; nearly identical performance numbers on my Zen 4 (1.36x vs c), but llvm-mca predicts >60% perf gain on Intel CPUs newer than Skylake. Signed-off-by: Zuxy Meng <zuxy.meng(a)gmail.com> --- libavcodec/x86/h264_intrapred.asm | 44 ++++++++++++---------------- libavcodec/x86/h264_intrapred_init.c | 9 ++++-- 2 files changed, 25 insertions(+), 28 deletions(-) diff --git a/libavcodec/x86/h264_intrapred.asm b/libavcodec/x86/h264_intrapred.asm index a8a630dbe6..2e4a46ae76 100644 --- a/libavcodec/x86/h264_intrapred.asm +++ b/libavcodec/x86/h264_intrapred.asm @@ -606,37 +606,31 @@ INIT_MMX ssse3 PRED8x8_H ;----------------------------------------------------------------------------- -; void ff_pred8x8_top_dc_8_mmxext(uint8_t *src, ptrdiff_t stride) +; void ff_pred8x8_top_dc_8_sse2(uint8_t *src, ptrdiff_t stride) ;----------------------------------------------------------------------------- -INIT_MMX mmxext +INIT_XMM sse2 cglobal pred8x8_top_dc_8, 2,5 sub r0, r1 - movq mm0, [r0] - pxor mm1, mm1 - pxor mm2, mm2 + movq xmm0, [r0] + pxor xmm1, xmm1 lea r2, [r0+r1*2] - punpckhbw mm1, mm0 - punpcklbw mm0, mm2 - psadbw mm1, mm2 ; s1 + punpcklbw xmm0, xmm1 + psadbw xmm0, xmm1 ; s0,0,0,0,s1,0,0,0 (w) lea r3, [r2+r1*2] - psadbw mm0, mm2 ; s0 - psrlw mm1, 1 - psrlw mm0, 1 - pavgw mm1, mm2 - lea r4, [r3+r1*2] - pavgw mm0, mm2 - pshufw mm1, mm1, 0 - pshufw mm0, mm0, 0 ; dc0 (w) - packuswb mm0, mm1 ; dc0,dc1 (b) - movq [r0+r1*1], mm0 - movq [r0+r1*2], mm0 + psrlw xmm0, 1 + pavgw xmm0, xmm1 + pshuflw xmm0, xmm0, 0 ; dc0,dc0,dc0,dc0,dc1,0,0,0 + pshufhw xmm0, xmm0, 0 ; dc0,dc1 (w) + packuswb xmm0, xmm1 ; dc0,dc1 (b) + movq [r0+r1*1], xmm0 + movq [r0+r1*2], xmm0 lea r0, [r3+r1*2] - movq [r2+r1*1], mm0 - movq [r2+r1*2], mm0 - movq [r3+r1*1], mm0 - movq [r3+r1*2], mm0 - movq [r0+r1*1], mm0 - movq [r0+r1*2], mm0 + movq [r2+r1*1], xmm0 + movq [r2+r1*2], xmm0 + movq [r3+r1*1], xmm0 + movq [r3+r1*2], xmm0 + movq [r0+r1*1], xmm0 + movq [r0+r1*2], xmm0 RET ;----------------------------------------------------------------------------- diff --git a/libavcodec/x86/h264_intrapred_init.c b/libavcodec/x86/h264_intrapred_init.c index aa9bc721f0..0476980a57 100644 --- a/libavcodec/x86/h264_intrapred_init.c +++ b/libavcodec/x86/h264_intrapred_init.c @@ -113,7 +113,7 @@ PRED16x16(plane_svq3, 8, ssse3) PRED16x16(tm_vp8, 8, sse2) PRED16x16(tm_vp8, 8, avx2) -PRED8x8(top_dc, 8, mmxext) +PRED8x8(top_dc, 8, sse2) PRED8x8(dc_rv40, 8, mmxext) PRED8x8(dc, 8, mmxext) PRED8x8(vertical, 8, sse2) @@ -187,7 +187,6 @@ av_cold void ff_h264_pred_init_x86(H264PredContext *h, int codec_id, } if (codec_id == AV_CODEC_ID_SVQ3 || codec_id == AV_CODEC_ID_H264) { if (chroma_format_idc <= 1) { - h->pred8x8[TOP_DC_PRED8x8 ] = ff_pred8x8_top_dc_8_mmxext; h->pred8x8[DC_PRED8x8 ] = ff_pred8x8_dc_8_mmxext; } } @@ -210,8 +209,12 @@ av_cold void ff_h264_pred_init_x86(H264PredContext *h, int codec_id, h->pred8x8l [VERT_RIGHT_PRED ] = ff_pred8x8l_vertical_right_8_sse2; h->pred8x8l [VERT_LEFT_PRED ] = ff_pred8x8l_vertical_left_8_sse2; h->pred8x8l [HOR_DOWN_PRED ] = ff_pred8x8l_horizontal_down_8_sse2; - if (chroma_format_idc <= 1) + if (chroma_format_idc <= 1) { h->pred8x8 [VERT_PRED8x8 ] = ff_pred8x8_vertical_8_sse2; + if (codec_id == AV_CODEC_ID_SVQ3 || codec_id == AV_CODEC_ID_H264) { + h->pred8x8 [TOP_DC_PRED8x8] = ff_pred8x8_top_dc_8_sse2; + } + } if (codec_id == AV_CODEC_ID_VP7 || codec_id == AV_CODEC_ID_VP8) { h->pred16x16[PLANE_PRED8x8 ] = ff_pred16x16_tm_vp8_8_sse2; h->pred8x8 [PLANE_PRED8x8 ] = ff_pred8x8_tm_vp8_8_sse2; -- 2.43.0

3 5

[PATCH v2] web: add contributor onboarding page
by marcos ashton 05 Apr '26

05 Apr '26

Add contributing.html covering building FFmpeg, submitting patches via Forgejo, the review process, and writing FATE tests for libavutil, libavfilter, and libavcodec. Sidebar nav left unchanged to avoid breaking bookmarks. Signed-off-by: marcos ashton <marcosashiglesias(a)gmail.com> --- Makefile | 2 +- src/contributing | 416 +++++++++++++++++++++++++++++++++++++++++ src/contributing_js | 0 src/contributing_title | 1 + 4 files changed, 418 insertions(+), 1 deletion(-) create mode 100644 src/contributing create mode 100644 src/contributing_js create mode 100644 src/contributing_title diff --git a/Makefile b/Makefile index dd681e4..4f5c187 100644 --- a/Makefile +++ b/Makefile @@ -1,6 +1,6 @@ # ffmpeg.org HTML generation from source files -SRCS = about bugreports consulting contact donations documentation download \ +SRCS = about bugreports consulting contact contributing donations documentation download \ olddownload index legal shame security spi archive HTML_TARGETS = $(addsuffix .html,$(addprefix htdocs/,$(SRCS))) diff --git a/src/contributing b/src/contributing new file mode 100644 index 0000000..505884e --- /dev/null +++ b/src/contributing @@ -0,0 +1,416 @@ + + This page covers everything a first-time contributor needs to get + started: building FFmpeg, submitting patches, understanding code review, + and writing tests. + + + + For the full developer reference, see + <a href="developer.html">Developer Documentation</a> and + <a href="git-howto.html">Using Git to Develop FFmpeg</a>. + + + + +<h3 id="BuildSetup"> + +   + + Building FFmpeg</h3> + + + Clone the repository and build: + + +<pre> +git clone https://git.ffmpeg.org/ffmpeg.git +cd ffmpeg +./configure +make -j$(nproc)</pre> + + + This builds ffmpeg, ffplay, and ffprobe. Run + <code>./configure --help</code> to see all options. + + + + For development, you probably want debug symbols and test coverage: + + +<pre> +./configure --toolchain=gcov --assert-level=2 +make -j$(nproc)</pre> + + + Verify your build: + + +<pre> +./ffmpeg -version</pre> + + + +<h3 id="SubmittingPatches"> + +   + + Submitting Patches</h3> + + + The preferred way to submit patches is through + <a href="https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls">Forgejo</a> + at code.ffmpeg.org. You can also send patches to the + <a href="https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel/">ffmpeg-devel</a> + mailing list using <code>git format-patch</code> or + <code>git send-email</code>. + + + + GitHub pull requests are not part of the review process and will be ignored. + + +Via Forgejo (recommended) + +<ol> + <li>Create an account at + <a href="https://code.ffmpeg.org">code.ffmpeg.org</a>.</li> + <li>Fork the FFmpeg repository.</li> + <li>Push your branch to your fork.</li> + <li>Open a pull request against the main FFmpeg repository.</li> +</ol> + +Via mailing list + + + Generate and send patches: + + +<pre> +git send-email --to ffmpeg-devel(a)ffmpeg.org origin/master</pre> + + + Subscribe to ffmpeg-devel first. Patches from non-subscribers are held + for moderation and may be delayed. See + <a href="git-howto.html">Using Git to Develop FFmpeg</a> for + setup instructions. + + +Commit message format + + + The first line must follow this format: + + +<pre> +area/component: short description of what changed</pre> + + + Then a blank line, then the body explaining why the change is needed. + The diff shows what changed; the message should explain why. + End with a Signed-off-by line (<code>git commit -s</code>). + + + + Full example: + + +<pre> +avcodec/libx264: fix memory leak in parameter parsing + +The options dictionary was not freed on the error path when +x264_param_parse() returned a failure code. + +Signed-off-by: Your Name <your(a)email.com></pre> + + + Keep the first line under 72 characters. Each patch should be a single + logical change. Do not mix cosmetic changes with functional changes. + Run <code>tools/patcheck</code> on your patch before sending. + + + + +<h3 id="ReviewProcess"> + +   + + The Review Process</h3> + + + Every patch is reviewed by other developers, whether you submit via + Forgejo or the mailing list. Here is what to expect: + + +<ol> + <li>A reviewer reads your patch and leaves comments. This may take + a few days. If you have not heard back after a week, send a + polite reminder or ask on <code>#ffmpeg-devel</code> on + <a href="https://libera.chat/">Libera Chat</a>.</li> + <li>Address every comment. If you disagree with a suggestion, explain + your reasoning. Ignoring review comments will stall your patch.</li> + <li>Submit a revised version. On Forgejo, push to your branch. On the + mailing list, send a new version with <code>[PATCH v2]</code> in + the subject.</li> + <li>Repeat until the reviewer is satisfied. Simple patches may land + after one round. Larger patches often go through several + revisions.</li> + <li>Once approved, a developer with commit access pushes it to + master.</li> +</ol> + + + Reviewing other people's patches is one of the best ways to get your + own patches reviewed faster. Everyone is welcome to review. + + + + +<h3 id="BeforeYouSubmit"> + +   + + Before You Submit</h3> + + + Run the FATE test suite to make sure nothing is broken: + + +<pre> +make fate</pre> + + + Many tests require sample media files that are not included in the + source tree. Download them from + <a href="https://fate.ffmpeg.org">fate.ffmpeg.org</a> (rsync + is the fastest method): + + +<pre> +rsync -a --no-inc-recursive rsync://fate.ffmpeg.org/fate-suite/ fate-suite/</pre> + + + Then tell <code>./configure</code> where the samples live, either + at configure time: + + +<pre> +./configure --samples=/path/to/fate-suite</pre> + + + or as a make variable: + + +<pre> +make fate SAMPLES=/path/to/fate-suite</pre> + + + Without sample files, tests that depend on them are skipped rather + than failed, so your basic build will still pass. But if your patch + touches a codec, demuxer, or filter that has sample-based tests, run + with samples to make sure nothing regressed. + + + + If your patch changes expected output, update the reference files. + If your patch adds a new module (decoder, encoder, filter, muxer, + demuxer, parser, or bitstream filter), add a FATE test for it. + + + + Check your patch for common issues: + + +<pre> +tools/patcheck your-patch.diff</pre> + + + See the + <a href="developer.html#Patch-submission-checklist">Patch Submission Checklist</a> + for the full list. + + + + +<h3 id="WritingFATETests"> + +   + + Writing FATE Tests</h3> + + + FATE (FFmpeg Automated Testing Environment) is the regression test + suite. Tests are defined in <code>tests/fate/*.mak</code> files. + Reference outputs live in <code>tests/ref/fate/</code>. There are + three common patterns. + + +C unit tests (libavutil) + + + For testing utility functions, write a standalone C program that + exercises the API and prints results to stdout. + + + + Create the test at <code>libavutil/tests/yourtest.c</code>: + + +<pre> +#include "libavutil/yourheader.h" + +int main(void) +{ + int ret = 0; + + /* call the functions you want to test */ + if (!result) { + fprintf(stderr, "some_function: FAIL\n"); + ret = 1; + } else { + printf("some_function: OK\n"); + } + return ret; +}</pre> + + + Add it to <code>libavutil/Makefile</code>: + + +<pre> +TESTPROGS += yourtest</pre> + + + Register it in <code>tests/fate/libavutil.mak</code>: + + +<pre> +FATE_LIBAVUTIL += fate-yourtest +fate-yourtest: libavutil/tests/yourtest$(EXESUF) +fate-yourtest: CMD = run libavutil/tests/yourtest$(EXESUF)</pre> + + + Generate the reference output: + + +<pre> +make fate-yourtest GEN=1</pre> + + + This creates <code>tests/ref/fate/yourtest</code>. If your test only + checks exit codes and produces no meaningful stdout, add + <code>CMP = null</code>. + + +Filter tests (libavfilter) + + + Filter tests run a filter chain and compare per-frame CRC checksums + against a reference. They go in + <code>tests/fate/filter-audio.mak</code> or + <code>tests/fate/filter-video.mak</code>. + + + + Example for an audio filter: + + +<pre> +FATE_AFILTER-$(call FILTERDEMDECENCMUX, YOURFILTER, WAV, PCM_S16LE, PCM_S16LE, WAV) += fate-filter-yourfilter +fate-filter-yourfilter: tests/data/asynth-44100-2.wav +fate-filter-yourfilter: SRC = $(TARGET_PATH)/tests/data/asynth-44100-2.wav +fate-filter-yourfilter: CMD = framecrc -i $(SRC) -af yourfilter</pre> + + + The <code>FILTERDEMDECENCMUX</code> macro checks that all required + components are compiled in. The <code>framecrc</code> command computes + a CRC for each output frame. Generate the reference: + + +<pre> +make fate-filter-yourfilter GEN=1</pre> + + + This writes the reference to + <code>tests/ref/fate/filter-yourfilter</code>. To test multiple + format variants, add separate entries with suffixes like + <code>fate-filter-yourfilter-fltp</code>. + + +Codec roundtrip tests (libavcodec) + + + These encode audio or video with a codec, decode it back, and compare + the result against a reference. They live in + <code>tests/fate/acodec.mak</code>, + <code>tests/fate/vcodec.mak</code>, or a codec-specific + <code>.mak</code> file. + + + + The generic template in <code>tests/fate/acodec.mak</code> handles + most audio codecs. To use it, add a single line: + + +<pre> +FATE_ACODEC_LOSSLESS-$(call ENCDEC, YOURCODEC, WAV) += yourcodec</pre> + + + This encodes <code>tests/data/asynth-44100-2.wav</code>, decodes it + back to PCM, and compares against + <code>tests/ref/acodec/yourcodec</code>. + + + + For codecs that need custom options or lossy comparison: + + +<pre> +FATE_ACODEC-$(call ENCDEC, YOURCODEC, WAV) += fate-acodec-yourcodec +fate-acodec-yourcodec: CMD = enc_dec_pcm yourformat wav s16le $(SRC) -c:a yourcodec -b:a 128k +fate-acodec-yourcodec: REF = $(SRC) +fate-acodec-yourcodec: CMP = stddev +fate-acodec-yourcodec: CMP_TARGET = 500</pre> + + + <code>CMP = stddev</code> allows lossy comparison. The + <code>CMP_TARGET</code> value is the maximum allowed standard + deviation between original and decoded samples. + + + + +<h3 id="GettingHelp"> + +   + + Getting Help</h3> + +<div class="well"> + <div class="list-group"> + <a class="list-group-item" href="irc://irc.libera.chat/ffmpeg-devel"> + #ffmpeg-devel on Libera Chat + Real-time discussion about FFmpeg development. Good for quick + questions and checking on patch status. + </a> + <a class="list-group-item" href="https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel/"> + ffmpeg-devel mailing list + Patch submission, review, and development discussion. + Subscribe before posting. + </a> + <a class="list-group-item" href="https://code.ffmpeg.org"> + Forgejo (code.ffmpeg.org) + The preferred platform for submitting pull requests. + </a> + <a class="list-group-item" href="https://trac.ffmpeg.org/wiki"> + FFmpeg Wiki + Community-maintained documentation, guides, and how-tos. + </a> + </div>  +</div>  + + + See also: + <a href="developer.html">Developer Documentation</a>, + <a href="git-howto.html">Using Git to Develop FFmpeg</a>, and + <a href="fate.html">FATE</a>. + diff --git a/src/contributing_js b/src/contributing_js new file mode 100644 index 0000000..e69de29 diff --git a/src/contributing_title b/src/contributing_title new file mode 100644 index 0000000..cde9230 --- /dev/null +++ b/src/contributing_title @@ -0,0 +1 @@ +Contributing to FFmpeg \ No newline at end of file -- 2.53.0

2 1