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

review
by Kumar, Pradeep 06 Aug '26

06 Aug '26

Hi Team, Please review this. This is done in context to save time for customer when flush is happened. -thanks Pradeep Kumar

1 1

[PATCH] fftools/ffmpeg_sched: do not print error code
by Nicolas George 27 Jul '26

27 Jul '26

The error codes are meaningless to users, especially the ones that do not come from standard errno codes. Signed-off-by: Nicolas George <george(a)nsup.org> --- fftools/ffmpeg_sched.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/fftools/ffmpeg_sched.c b/fftools/ffmpeg_sched.c index 3180367576..ba9708b65b 100644 --- a/fftools/ffmpeg_sched.c +++ b/fftools/ffmpeg_sched.c @@ -2534,7 +2534,7 @@ static void *task_wrapper(void *arg) ret = task->func(task->func_arg); if (ret < 0) av_log(task->func_arg, AV_LOG_ERROR, - "Task finished with error code: %d (%s)\n", ret, av_err2str(ret)); + "Task finished with error: %s\n", av_err2str(ret)); err = task_cleanup(sch, task->node); ret = err_merge(ret, err); @@ -2549,9 +2549,12 @@ static void *task_wrapper(void *arg) pthread_mutex_unlock(&sch->finish_lock); } - av_log(task->func_arg, ret < 0 ? AV_LOG_ERROR : AV_LOG_VERBOSE, - "Terminating thread with return code %d (%s)\n", ret, - ret < 0 ? av_err2str(ret) : "success"); + if (ret < 0) + av_log(task->func_arg, AV_LOG_ERROR, + "Terminating thread with error: %s\n", av_err2str(ret)); + else + av_log(task->func_arg, AV_LOG_VERBOSE, + "Terminating thread with success\n"); return (void*)(intptr_t)ret; } -- 2.47.2

2 3

[PATCH] avformat/demux: avoid unconditional ID3v2 tag consumption
by Nil Fons Miret 10 Jul '26

10 Jul '26

I have found a few instances of rawvideo files that coincidentally start with a header matching the ID3v2 header format, and ffmpeg consumes the header before demuxing, causing a decoding error. This happens even if "-f rawvideo" is specified. This patch limits the formats for which this automatic consuming of ID3v2 headers is done. Note: I am not an expert in ID3v2 by any means, and I'm happy to accept suggestions, both on the scope and mechanism of the solution. To reproduce, you can easily generate an example as follows: ``` ( echo "49 44 33 2B 98 3A 49 44 33 2B 98 3A 6A 44 54 2B" | xxd -r -p dd if=/dev/zero bs=1 count=115184 2>/dev/null ) > id3v2_320x240_yuv420p.yuv ffmpeg -f rawvideo -s 320x240 -pix_fmt yuv420p -i id3v2_320x240_yuv420p.yuv -f null - ``` This generates a 320x240 yuv420p file with a 16-byte header that matches the ID3v2 header format (this was copied from a real case I saw) and completed with zeroes for a total of 115200 bytes, the right size for this resolution and pixel format. On the master branch, I see: ``` [...] ID3v2.43 tag skipped, cannot handle version [...] [out#0/null @ 0x15700a6e0] Output file is empty, nothing was encoded(check -ss / -t / -frames parameters if used) frame= 0 fps=0.0 q=0.0 Lsize=N/A time=N/A bitrate=N/A speed=N/A ``` After the changes: it decodes as expected. ``` [...] frame= 1 fps=0.0 q=-0.0 Lsize=N/A time=00:00:00.04 bitrate=N/A speed=16.5x elapsed=0:00:00.00 ``` Thanks in advance, Nil

3 6

[PATCH] ffbuild/common.mak: ensure target directories are created before running shell redirects into them
by Alexander Kanavin 19 Jun '26

19 Jun '26

Otherwise, occasional build races have been observed: https://autobuilder.yoctoproject.org/valkyrie/#/builders/37/builds/3001/ste… /bin/sh: 4: cannot create fftools/resources/graph.css.min: Directory nonexistent mkdir -p fftools/graph /bin/sh: 1: cannot create fftools/resources/graph.html.gz: Directory nonexistent make: *** [/srv/pokybuild/.../ffmpeg-8.0.1/ffbuild/common.mak:165: fftools/resources/graph.html.gz] Error 2 make: *** Waiting for unfinished jobs.... make: *** [/srv/pokybuild/.../ffmpeg-8.0.1/ffbuild/common.mak:145: fftools/resources/graph.css.min] Error 2 There's a separate rule for making those directories, but unfortunately it's racing with the rules that expect the directories to exist. Rather than add a Makefile dependency, I've injected the dir creation directly in front of commands that can otherwise fail - a proper fix would probably add the rule rather. Signed-off-by: Alexander Kanavin <alex(a)linutronix.de> --- ffbuild/common.mak | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ffbuild/common.mak b/ffbuild/common.mak index 89c0c413e1..7f223297b8 100644 --- a/ffbuild/common.mak +++ b/ffbuild/common.mak @@ -125,8 +125,8 @@ $(BIN2CEXE): ffbuild/bin2c_host.o $(HOSTLD) $(HOSTLDFLAGS) $(HOSTLD_O) $^ $(HOSTEXTRALIBS) RUN_BIN2C = $(BIN2C) $(patsubst $(SRC_PATH)/%,$(SRC_LINK)/%,$<) $@ $(subst .,_,$(basename $(notdir $@))) -RUN_GZIP = $(M)gzip -nc9 $(patsubst $(SRC_PATH)/%,$(SRC_LINK)/%,$<) >$@ -RUN_MINIFY = $(M)sed 's!/\\*.*\\*/!!g' $< | tr '\n' ' ' | tr -s ' ' | sed 's/^ //; s/ $$//' > $@ +RUN_GZIP = mkdir -p $(dir $@) && $(M)gzip -nc9 $(patsubst $(SRC_PATH)/%,$(SRC_LINK)/%,$<) >$@ +RUN_MINIFY = mkdir -p $(dir $@) && $(M)sed 's!/\\*.*\\*/!!g' $< | tr '\n' ' ' | tr -s ' ' | sed 's/^ //; s/ $$//' > $@ %.gz: TAG = GZIP %.min: TAG = MINIFY -- 2.47.3

2 1

[PATCH] avformat/mpjpegdec: add support for X-Timestamp and X-Framerate headers
by Vladimir Sobolev 11 Jun '26

11 Jun '26

From 31d73c6774c1ea6d621db57f26439e297cc23c3d Mon Sep 17 00:00:00 2001 From: Vladimir Sobolev <v.sobolev(a)gmail.com> Date: Sun, 9 Nov 2025 02:28:13 +0200 Subject: [PATCH] avformat/mpjpegdec: add support for X-Timestamp and X-Framerate headers Add support for parsing X-Timestamp and X-Framerate headers from HTTP multipart MJPEG streams. These headers allow servers to provide accurate timestamps and framerate information for each frame. Changes: - Parse X-Timestamp header (in seconds) and set packet PTS/DTS - Parse X-Framerate/X-FrameRate header and update stream framerate - Maintain backward compatibility (defaults to 25 fps if not provided) - Add debug logging for parsed header values This enables proper timestamp handling for MJPEG streams that provide timing information in HTTP headers, improving synchronization accuracy. --- libavformat/mpjpegdec.c | 69 ++++++++++++++++++++++++++++++++++++++--- 1 file changed, 65 insertions(+), 4 deletions(-) diff --git a/libavformat/mpjpegdec.c b/libavformat/mpjpegdec.c index 125b17585e..c90d7a2ad4 100644 --- a/libavformat/mpjpegdec.c +++ b/libavformat/mpjpegdec.c @@ -22,6 +22,9 @@ #include "libavutil/avstring.h" #include "libavutil/mem.h" #include "libavutil/opt.h" +#include "libavutil/parseutils.h" +#include "libavutil/eval.h" +#include "libavutil/intfloat.h" #include "avformat.h" #include "demux.h" @@ -34,6 +37,11 @@ typedef struct MPJPEGDemuxContext { char *searchstr; int searchstr_len; int strict_mime_boundary; + AVRational framerate; /* framerate from X-Framerate header */ + int64_t timestamp; /* timestamp from X-Timestamp header */ + int has_timestamp; /* flag indicating if timestamp was set */ + int framerate_set; /* flag indicating if framerate was set in header */ + int framerate_applied; /* flag indicating if framerate was applied to stream */ } MPJPEGDemuxContext; static void trim_right(char *p) @@ -97,7 +105,8 @@ static int split_tag_value(char **tag, char **value, char *line) static int parse_multipart_header(AVIOContext *pb, int* size, const char* expected_boundary, - void *log_ctx); + void *log_ctx, + MPJPEGDemuxContext *mpjpeg); static int mpjpeg_read_close(AVFormatContext *s) { @@ -118,7 +127,7 @@ static int mpjpeg_read_probe(const AVProbeData *p) ffio_init_read_context(&pb, p->buf, p->buf_size); - ret = (parse_multipart_header(&pb.pub, &size, "--", NULL) >= 0) ? AVPROBE_SCORE_MAX : 0; + ret = (parse_multipart_header(&pb.pub, &size, "--", NULL, NULL) >= 0) ? AVPROBE_SCORE_MAX : 0; return ret; } @@ -146,6 +155,12 @@ static int mpjpeg_read_header(AVFormatContext *s) st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO; st->codecpar->codec_id = AV_CODEC_ID_MJPEG; + /* Default framerate is 25 fps, will be updated from headers if available */ + MPJPEGDemuxContext *mpjpeg = s->priv_data; + mpjpeg->framerate = (AVRational){25, 1}; + mpjpeg->framerate_set = 0; + mpjpeg->framerate_applied = 0; + mpjpeg->has_timestamp = 0; avpriv_set_pts_info(st, 60, 1, 25); avio_seek(s->pb, pos, SEEK_SET); @@ -167,7 +182,8 @@ static int parse_content_length(const char *value) static int parse_multipart_header(AVIOContext *pb, int* size, const char* expected_boundary, - void *log_ctx) + void *log_ctx, + MPJPEGDemuxContext *mpjpeg) { char line[128]; int found_content_type = 0; @@ -235,6 +251,33 @@ static int parse_multipart_header(AVIOContext *pb, av_log(log_ctx, AV_LOG_WARNING, "Invalid Content-Length value : %s\n", value); + } else if (mpjpeg && !av_strcasecmp(tag, "X-Timestamp")) { + double ts = av_strtod(value, NULL); + if (!isnan(ts) && isfinite(ts)) { + /* X-Timestamp is in seconds, convert to AV_TIME_BASE */ + mpjpeg->timestamp = (int64_t)(ts * AV_TIME_BASE); + mpjpeg->has_timestamp = 1; + if (log_ctx) + av_log(log_ctx, AV_LOG_DEBUG, + "Parsed X-Timestamp: %s -> %"PRId64" (%.6f seconds)\n", + value, mpjpeg->timestamp, ts); + } else if (log_ctx) { + av_log(log_ctx, AV_LOG_WARNING, + "Invalid X-Timestamp value : %s\n", value); + } + } else if (mpjpeg && (!av_strcasecmp(tag, "X-Framerate") || !av_strcasecmp(tag, "X-FrameRate"))) { + AVRational fps = {0}; + if (av_parse_video_rate(&fps, value) >= 0 && fps.num > 0 && fps.den > 0) { + mpjpeg->framerate = fps; + mpjpeg->framerate_set = 1; + if (log_ctx) + av_log(log_ctx, AV_LOG_DEBUG, + "Parsed X-Framerate: %s -> %d/%d fps\n", + value, fps.num, fps.den); + } else if (log_ctx) { + av_log(log_ctx, AV_LOG_WARNING, + "Invalid X-Framerate value : %s\n", value); + } } } @@ -311,10 +354,21 @@ static int mpjpeg_read_packet(AVFormatContext *s, AVPacket *pkt) mpjpeg->searchstr_len = strlen(mpjpeg->searchstr); } - ret = parse_multipart_header(s->pb, &size, mpjpeg->boundary, s); + /* Reset timestamp flag for each packet */ + mpjpeg->has_timestamp = 0; + + ret = parse_multipart_header(s->pb, &size, mpjpeg->boundary, s, mpjpeg); if (ret < 0) return ret; + /* Update framerate if it was set in header and hasn't been applied yet */ + if (mpjpeg->framerate_set && !mpjpeg->framerate_applied && s->nb_streams > 0) { + AVStream *st = s->streams[0]; + st->avg_frame_rate = mpjpeg->framerate; + avpriv_set_pts_info(st, 60, mpjpeg->framerate.den, mpjpeg->framerate.num); + mpjpeg->framerate_applied = 1; + } + if (size > 0) { /* size has been provided to us in MIME header */ ret = av_get_packet(s->pb, pkt, size); @@ -353,6 +407,13 @@ static int mpjpeg_read_packet(AVFormatContext *s, AVPacket *pkt) } } + /* Set timestamp from X-Timestamp header if available */ + if (ret >= 0 && mpjpeg->has_timestamp && s->nb_streams > 0) { + AVStream *st = s->streams[0]; + pkt->pts = av_rescale_q(mpjpeg->timestamp, AV_TIME_BASE_Q, st->time_base); + pkt->dts = pkt->pts; + } + return ret; } -- 2.50.1 (Apple Git-155)

2 11

[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