Re: [FFmpeg-devel] [PATCH] RISC-V:update ff_get_cpu_flags_riscv for RVV

[Rémi Denis-Courmont]

Hi,

Le 14 mars 2025 17:32:57 GMT+07:00, daichengr...@iscas.ac.cn a écrit :
>From: daichengrong 
>
>Availability of RVV and ZVBB should be determined with dl_hwcap.

No. That's completely superfluous since we already check for kernel support 
with hwprobe().

And we can't check for Zb* and Zv* with hwcap anyhow.

>As those extensions rely on vector registers, kernel vector support 
>is required to save the state of context switching.

No. Kernel context switching is already ascertained. And we don't care about 
libc context support, since vectors are clobbered by function calls, e.g. for 
long jumps or ucontext.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] lavc/vvc: Fix NumEntryPoints derivation

[Nuo Mi]

On Thu, Mar 6, 2025 at 2:40 AM Frank Plowman  wrote:

> If pps_single_slice_per_subpic_flag is 1,
> slice_{width,height}_in_tiles are undefined and we must instead get the
> dimensions of the slice by referring to the corresponding subpicture.


> Signed-off-by: Frank Plowman 
> ---
> Changes since v1:
> * slice_height_in_tiles is also undefined if
>   pps->pps_single_slice_per_subpic_flag is 1,
>   so also derive that from the subpic info.
> ---
>  libavcodec/cbs_h266_syntax_template.c | 49 +++
>  1 file changed, 43 insertions(+), 6 deletions(-)
>
Applied.
Thank you, Frank.

>
> diff --git a/libavcodec/cbs_h266_syntax_template.c
> b/libavcodec/cbs_h266_syntax_template.c
> index 58211026bb..05634bc19c 100644
> --- a/libavcodec/cbs_h266_syntax_template.c
> +++ b/libavcodec/cbs_h266_syntax_template.c
> @@ -3440,13 +3440,50 @@ static int FUNC(slice_header)
> (CodedBitstreamContext *ctx, RWContext *rw,
>  for (i = 0; i < current->curr_subpic_idx; i++) {
>  slice_idx += pps->num_slices_in_subpic[i];
>  }
> -width_in_tiles =
> -pps->pps_slice_width_in_tiles_minus1[slice_idx] + 1;
>
> -if (entropy_sync)
> -height = pps->slice_height_in_ctus[slice_idx];
> -else
> -height = pps->pps_slice_height_in_tiles_minus1[slice_idx]
> + 1;
> +if (pps->pps_single_slice_per_subpic_flag) {
> +const int width_in_ctus =
> sps->sps_subpic_width_minus1[slice_idx] + 1;
> +const int subpic_l =
> sps->sps_subpic_ctu_top_left_x[slice_idx];
> +const int subpic_r = subpic_l + width_in_ctus;
> +
> +int ctb_x = 0, tile_x = 0;
> +for (; ctb_x < subpic_l && tile_x <
> pps->num_tile_columns; tile_x++)
> +ctb_x += pps->col_width_val[tile_x];
> +
> +width_in_tiles = 0;
> +for (; ctb_x < subpic_r && tile_x <
> pps->num_tile_columns; tile_x++) {
> +ctb_x += pps->col_width_val[tile_x];
> +width_in_tiles++;
> +}
> +
> +if (entropy_sync)
> +height = sps->sps_subpic_height_minus1[slice_idx] + 1;
> +else {
> +const int height_in_ctus =
> sps->sps_subpic_height_minus1[slice_idx] + 1;
> +const int subpic_t =
> sps->sps_subpic_ctu_top_left_y[slice_idx];
> +const int subpic_b = subpic_t + height_in_ctus;
> +
> +int ctb_y = 0, tile_y = 0, height_in_tiles;
> +for (; ctb_y < subpic_t && tile_y <
> pps->num_tile_rows; tile_y++)
> +ctb_y += pps->row_height_val[tile_y];
> +
> +height_in_tiles = 0;
> +for (; ctb_y < subpic_b && tile_y <
> pps->num_tile_rows; tile_y++) {
> +ctb_y += pps->row_height_val[tile_y];
> +height_in_tiles++;
> +}
> +
> +height = height_in_tiles;
> +}
> +} else {
> +width_in_tiles =
> +pps->pps_slice_width_in_tiles_minus1[slice_idx] + 1;
> +
> +if (entropy_sync)
> +height = pps->slice_height_in_ctus[slice_idx];
> +else
> +height =
> pps->pps_slice_height_in_tiles_minus1[slice_idx] + 1;
> +}
>
>  current->num_entry_points = width_in_tiles * height;
>  } else {
> --
> 2.47.0
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 5/5] avcodec/ffv1dec: Fix a YUVA issue with remaping

[Michael Niedermayer]

Untested

Signed-off-by: Michael Niedermayer 
---
 libavcodec/ffv1dec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index 968c386f897..6ec9e229f3b 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -371,7 +371,8 @@ static int decode_slice(AVCodecContext *c, void *arg)
 decode_plane(f, sc, &gb, p->data[2] + ps*cx+cy*p->linesize[2], 
chroma_width, chroma_height, p->linesize[2], 1, 2, 1, ac);
 }
 if (f->transparency)
-decode_plane(f, sc, &gb, p->data[3] + ps*x + y*p->linesize[3], 
width, height, p->linesize[3], (f->version >= 4 && !f->chroma_planes) ? 1 : 2, 
2, 1, ac);
+decode_plane(f, sc, &gb, p->data[3] + ps*x + y*p->linesize[3], 
width, height, p->linesize[3], (f->version >= 4 && !f->chroma_planes) ? 1 : 2,
+   
   (f->version >= 4 && !f->chroma_planes) ? 1 : 3, 1, 
ac);
 } else if (f->colorspace == 0) {
  decode_plane(f, sc, &gb, p->data[0] + ps*x + y*p->linesize[0] 
 , width, height, p->linesize[0], 0, 0, 2, ac);
  decode_plane(f, sc, &gb, p->data[0] + ps*x + y*p->linesize[0] + 
(ps>>1), width, height, p->linesize[0], 1, 1, 2, ac);
-- 
2.48.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] av1dec: update hwaccel decode_params on AV1_OBU_SEQUENCE_HEADER

[Lynne]

Previously, the callback was only called on init. This makes it
get called on every frame.

We should switch to VK_KHR_video_maintenance2 and provide all params
upfront, but almost nothing supports it yet.
---
 libavcodec/av1dec.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index baa9dea0f7..ed00278ed3 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -1329,6 +1329,15 @@ static int av1_receive_frame_internal(AVCodecContext 
*avctx, AVFrame *frame)
 
 s->pix_fmt = AV_PIX_FMT_NONE;
 
+if (FF_HW_HAS_CB(avctx, decode_params)) {
+ret = FF_HW_CALL(avctx, decode_params, AV1_OBU_SEQUENCE_HEADER,
+ s->seq_data_ref->data, s->seq_data_ref->size);
+if (ret < 0) {
+av_log(avctx, AV_LOG_ERROR, "HW accel decode params 
fail.\n");
+return ret;
+}
+}
+
 break;
 case AV1_OBU_REDUNDANT_FRAME_HEADER:
 if (s->raw_frame_header)
-- 
2.47.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec: Mark init and close functions as av_cold

[Andreas Rheinhardt]

Andreas Rheinhardt:
> Patch attached.
> 
> - Andreas
> 

Now truely attached.

- Andreas
From ccb9413d8408e8b1b0a786af683042609cddd177 Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt 
Date: Thu, 6 Mar 2025 18:28:57 +0100
Subject: [PATCH] avcodec: Mark init and close functions as av_cold

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/d3d12va_av1.c| 4 ++--
 libavcodec/d3d12va_decode.c | 4 ++--
 libavcodec/d3d12va_h264.c   | 2 +-
 libavcodec/d3d12va_hevc.c   | 2 +-
 libavcodec/d3d12va_mpeg2.c  | 2 +-
 libavcodec/d3d12va_vc1.c| 2 +-
 libavcodec/d3d12va_vp9.c| 2 +-
 libavcodec/dcaenc.c | 2 +-
 libavcodec/dvdsubenc.c  | 2 +-
 libavcodec/dxv.c| 4 ++--
 libavcodec/dxva2_av1.c  | 2 +-
 libavcodec/ffv1enc.c| 2 +-
 libavcodec/libaribb24.c | 4 ++--
 libavcodec/libaribcaption.c | 4 ++--
 libavcodec/libvorbisdec.c   | 6 --
 libavcodec/lscrdec.c| 6 +++---
 libavcodec/mfenc.c  | 2 +-
 libavcodec/microdvddec.c| 2 +-
 libavcodec/movtextdec.c | 6 +++---
 libavcodec/rasc.c   | 2 +-
 libavcodec/rkmppdec.c   | 6 +++---
 libavcodec/rpzaenc.c| 4 ++--
 libavcodec/sbcdec.c | 2 +-
 libavcodec/smcenc.c | 4 ++--
 libavcodec/textdec.c| 2 +-
 libavcodec/vaapi_av1.c  | 4 ++--
 libavcodec/vdpau.c  | 6 +++---
 libavcodec/vdpau_av1.c  | 2 +-
 libavcodec/vdpau_h264.c | 2 +-
 libavcodec/vdpau_hevc.c | 2 +-
 libavcodec/vdpau_mpeg12.c   | 4 ++--
 libavcodec/vdpau_mpeg4.c| 2 +-
 libavcodec/vdpau_vc1.c  | 2 +-
 libavcodec/vdpau_vp9.c  | 2 +-
 34 files changed, 54 insertions(+), 52 deletions(-)

diff --git a/libavcodec/d3d12va_av1.c b/libavcodec/d3d12va_av1.c
index 4a4d207b4f..83e7e53a55 100644
--- a/libavcodec/d3d12va_av1.c
+++ b/libavcodec/d3d12va_av1.c
@@ -151,7 +151,7 @@ static int d3d12va_av1_end_frame(AVCodecContext *avctx)
 return ret;
 }
 
-static int d3d12va_av1_decode_init(AVCodecContext *avctx)
+static av_cold int d3d12va_av1_decode_init(AVCodecContext *avctx)
 {
 D3D12VADecodeContext*ctx = D3D12VA_DECODE_CONTEXT(avctx);
 D3D12AV1DecodeContext   *av1_ctx = D3D12_AV1_DECODE_CONTEXT(avctx);
@@ -179,7 +179,7 @@ static int d3d12va_av1_decode_init(AVCodecContext *avctx)
 return 0;
 }
 
-static int d3d12va_av1_decode_uninit(AVCodecContext *avctx)
+static av_cold int d3d12va_av1_decode_uninit(AVCodecContext *avctx)
 {
 D3D12AV1DecodeContext   *ctx = D3D12_AV1_DECODE_CONTEXT(avctx);
 
diff --git a/libavcodec/d3d12va_decode.c b/libavcodec/d3d12va_decode.c
index 3b8978635e..312d6e1ed7 100644
--- a/libavcodec/d3d12va_decode.c
+++ b/libavcodec/d3d12va_decode.c
@@ -280,7 +280,7 @@ int ff_d3d12va_common_frame_params(AVCodecContext *avctx, AVBufferRef *hw_frames
 return 0;
 }
 
-int ff_d3d12va_decode_init(AVCodecContext *avctx)
+av_cold int ff_d3d12va_decode_init(AVCodecContext *avctx)
 {
 int ret;
 AVHWFramesContext *frames_ctx;
@@ -370,7 +370,7 @@ fail:
 return AVERROR(EINVAL);
 }
 
-int ff_d3d12va_decode_uninit(AVCodecContext *avctx)
+av_cold int ff_d3d12va_decode_uninit(AVCodecContext *avctx)
 {
 int num_allocator = 0;
 D3D12VADecodeContext *ctx = D3D12VA_DECODE_CONTEXT(avctx);
diff --git a/libavcodec/d3d12va_h264.c b/libavcodec/d3d12va_h264.c
index b2fe2955c8..9ccbe9d5a8 100644
--- a/libavcodec/d3d12va_h264.c
+++ b/libavcodec/d3d12va_h264.c
@@ -173,7 +173,7 @@ static int d3d12va_h264_end_frame(AVCodecContext *avctx)
 return ret;
 }
 
-static int d3d12va_h264_decode_init(AVCodecContext *avctx)
+static av_cold int d3d12va_h264_decode_init(AVCodecContext *avctx)
 {
 D3D12VADecodeContext *ctx = D3D12VA_DECODE_CONTEXT(avctx);
 DXVA_PicParams_H264 pp;
diff --git a/libavcodec/d3d12va_hevc.c b/libavcodec/d3d12va_hevc.c
index 7686f0eb6c..26c67dcfbd 100644
--- a/libavcodec/d3d12va_hevc.c
+++ b/libavcodec/d3d12va_hevc.c
@@ -160,7 +160,7 @@ static int d3d12va_hevc_end_frame(AVCodecContext *avctx)
scale ? &ctx_pic->qm : NULL, scale ? sizeof(ctx_pic->qm) : 0, update_input_arguments);
 }
 
-static int d3d12va_hevc_decode_init(AVCodecContext *avctx)
+static av_cold int d3d12va_hevc_decode_init(AVCodecContext *avctx)
 {
 D3D12VADecodeContext *ctx = D3D12VA_DECODE_CONTEXT(avctx);
 DXVA_PicParams_HEVC pp;
diff --git a/libavcodec/d3d12va_mpeg2.c b/libavcodec/d3d12va_mpeg2.c
index 86a7d97b34..d2eb77797f 100644
--- a/libavcodec/d3d12va_mpeg2.c
+++ b/libavcodec/d3d12va_mpeg2.c
@@ -150,7 +150,7 @@ static int d3d12va_mpeg2_end_frame(AVCodecContext *avctx)
 return ret;
 }
 
-static int d3d12va_mpeg2_decode_init(AVCodecContext *avctx)
+static av_cold int d3d12va_mpeg2_decode_init(AVCodecContext *avctx)
 {
 D3D12VADecodeContext  *ctx = D3D12VA_DECODE_CONTEXT(avctx);
 
diff --git a/libavcodec/d3d12va_vc1.c b/libavcodec/d3d12va_vc1.c
index dccc0fbffa..73f2cf71ad 100644
--- a/libavcodec/d3d12va_vc1.c
+++ b/libavcodec/d3d12va_vc1.c
@@ -162,7 +162,7 @@ static int d3d12va_vc1_end_frame(AVCodecContext *avctx)
 

Re: [FFmpeg-devel] [PATCH v4 01/16] pixfmt: add AV_PIX_FMT_GBRAP32

[Michael Niedermayer]

On Thu, Mar 13, 2025 at 06:03:33PM +0100, Lynne wrote:
> This commit adds a 32-bit *integer* planar RGBA format.
> Vulkan FFv1 decoding is best performed on separate planes, rather than
> packed RGBA (i.e. RGBA128), hence this is useful as an intermediate format.
> ---
>  libavutil/pixdesc.c | 28 
>  libavutil/pixfmt.h  |  4 
>  2 files changed, 32 insertions(+)

breaks fate

--- ./tests/ref/fate/imgutils   2025-03-14 00:56:35.182435551 +0100
+++ tests/data/fate/imgutils2025-03-14 16:12:30.642340871 +0100
@@ -296,6 +296,8 @@
 yaf32le planes: 1, linesizes: 512   0   0   0, plane_sizes: 24576 
0 0 0, plane_offsets: 0 0 0, total_size: 24576
 yaf16be planes: 1, linesizes: 256   0   0   0, plane_sizes: 12288 
0 0 0, plane_offsets: 0 0 0, total_size: 12288
 yaf16le planes: 1, linesizes: 256   0   0   0, plane_sizes: 12288 
0 0 0, plane_offsets: 0 0 0, total_size: 12288
+gbrap32be   planes: 4, linesizes: 256 256 256 256, plane_sizes: 12288 
12288 12288 12288, plane_offsets: 12288 12288 12288, total_size: 49152
+gbrap32le   planes: 4, linesizes: 256 256 256 256, plane_sizes: 12288 
12288 12288 12288, plane_offsets: 12288 12288 12288, total_size: 49152

 image_fill_black tests
 yuv420p total_size:   4608,  black_unknown_crc: 0xd00f6cc6,  
black_tv_crc: 0xd00f6cc6,  black_pc_crc: 0x234969af
@@ -539,3 +541,5 @@
 yaf32le total_size:  24576,  black_unknown_crc: 0xfd900236,  
black_tv_crc: 0xfd900236,  black_pc_crc: 0xdcaf0cb1
 yaf16be total_size:  12288,  black_unknown_crc: 0x7afe9aae,  
black_tv_crc: 0x7afe9aae,  black_pc_crc: 0x0fc0a5d0
 yaf16le total_size:  12288,  black_unknown_crc: 0x94c0068b,  
black_tv_crc: 0x94c0068b,  black_pc_crc: 0xc05ce449
+gbrap32be   total_size:  49152,  black_unknown_crc: 0x7bd30c95,  
black_tv_crc: 0x7bd30c95,  black_pc_crc: 0x7bd30c95
+gbrap32le   total_size:  49152,  black_unknown_crc: 0x7bd30c95,  
black_tv_crc: 0x7bd30c95,  black_pc_crc: 0x7bd30c95
Test imgutils failed. Look at tests/data/fate/imgutils.err for details.
make: *** [tests/Makefile:311: fate-imgutils] Error 1

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter: POC: enable out-of-tree filters

[Lynne]

On 13/03/2025 13:18, Leandro Santiago wrote:

This is a POC/prototype that aims to enable out of tree filters on
FFmpeg.

Here I name them "extra filters".

It introduces the program `jq` as a new build dependency.

To test it, create a directory, for instance, /tmp/my-shiny-filter/ and
inside it, create the following files:

`filter.json`, with the content:


This is a pointless patch and a pointlessly complex addition to the 
build system. I wouldn't accept something like this.
Those who for some reason have custom filters simply distribute their 
own branch with properly integrated filters. This also lets them 
upstream it if they want to.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter: POC: enable out-of-tree filters

[Leandro Santiago]

On 3/14/25 19:21, Nicolas George wrote:

Lynne (HE12025-03-14):

This is a pointless patch and a pointlessly complex addition to the build
system. I wouldn't accept something like this.
Those who for some reason have custom filters simply distribute their own
branch with properly integrated filters.

That works for third-party from one third-party. This feature helps
users who want to use filters from multiple third-party. With what you
describe, they would have to merge the branches, which might not be
trivial.

On the other hand, the JSON in this makes it look like it was designed
by looking at how fashionable languages NIHed their own f5g package
system.


Thx for the review and to make it clear:

it was not my intention to suggest my implementation (using json and so 
on) as the final one or to be mainlined.


I notice now my lack of netiquette, as it seems I was not clear on 
saying that this is a proof of concept (POC, in the subject): I wanted 
to try something (support for non mainlined filters), and wanted to 
check whether that was possible or not, and finally get feedback.


Using json+jq was the quickest, dirtiest way to accomplished that.

I personally conclude that the POC was successful: I managed to get a 
new filter, not mainlined, to be built into ffmpeg. Next steps would be 
throw the code away and implement it properly


Obviously I need the agreement from you experienced ffmpeg devs for such 
conclusion.


I should probably have called it a RFC or similar. My mistake. I still 
struggle with using the mailing list contribution model, as in a PR/MR 
model I would simply keep a WIP request until it gets to a good shape. 
With the ML model, I feel doing so is very error prone, but this is 
probably my lack of experience with it.


My goal now is to know whether there is any interest from the ffmpeg 
devs on having such feature (regardless of the implementation), as there 
seems to be lots of disagreement.


I am personally interested on it, due to the fact I am writing a filter 
in Rust that is very unlikely to ever me mainlined. Right now I need to 
constantly rebase branches, but I'd be way happier if I could simply 
rely on some "official" support in the ffmpeg codebase to use it.


Another benefit could be moving out some filters that are "not very 
loved" or that tend to "get rotten". My impression/opinion is that the 
DNN stuff could very well be moved out, to evolve independently from the 
main ffmpeg repo. I totally respect the developers who worked on it, to 
be very clear. I benefit from the DNN code and want to keep it working well.




If instead it was designed by asking “what would a ffmpeg developer do”,
it would just have configure run ext/*/configure and then Makefile
include $(CONFIG_EXT_WHATEVER).


Thank you for the feedback. I requested some thoughts on the topic a few 
days ago [1], and I see that probably the message was not clear.


I find this `simply run ext/configure approach` interesting and will 
have a look at it and later let you know my findings.


[1] https://ffmpeg.org/pipermail/ffmpeg-devel/2025-March/340895.html



Regards,


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [FFmpeg-cvslog] swscale: use 16-bit intermediate precision for RGB/XYZ conversion

[Niklas Haas]

On Fri, 14 Mar 2025 01:09:30 +0100 Niklas Haas  wrote:
> On Fri, 14 Mar 2025 00:54:25 +0100 Michael Niedermayer 
>  wrote:
> > Hi
> >
> > On Sun, Jan 26, 2025 at 07:26:59PM +0100, Michael Niedermayer wrote:
> > > On Thu, Dec 26, 2024 at 07:33:23PM +, Niklas Haas wrote:
> > > > ffmpeg | branch: master | Niklas Haas  | Mon Dec 16 
> > > > 14:49:39 2024 +0100| [af6d52eec66961f6a502b0f2f390c12226d087cd] | 
> > > > committer: Niklas Haas
> > > >
> > > > swscale: use 16-bit intermediate precision for RGB/XYZ conversion
> > > >
> > > > The current logic uses 12-bit linear light math, which is woefully 
> > > > insufficient
> > > > and leads to nasty postarization artifacts. This patch simply switches 
> > > > the
> > > > internal logic to 16-bit precision.
> > > >
> > > > This raises the memory requirement of these tables from 32 kB to 272 kB.
> > > >
> > > > All relevant FATE tests updated for improved accuracy.
> > > >
> > > > Fixes: #4829
> > > > Signed-off-by: Niklas Haas 
> > > > Sponsored-by: Sovereign Tech Fund
> > > >
> > > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=af6d52eec66961f6a502b0f2f390c12226d087cd
> > > > ---
> > >
> > > this breaks on x86-32
> >
> > ping
> >
> > the fate tests for a major architecture are broken since this
> > This impacts future bisections over that range for example
>
> My bad, missed this email for some reason.
>
> Will investigate and fix tomorrow.

So, I found the bug, but I don't know how to fix it properly.

The problem is that tha XYZ/RGB conversion tables are calculated using excess
precision from the x87 FPU. This results in slightly different rounding behavior
in exactly one case (i == 3415).

Fixing this requires setting -mfpmath=sse at compile time. Strangely, I was
not able to force the compiler to discard the excess precision even with
forcing -fexcess-precision=standard and storing every single subexpression to
a `volatile double`.

How do we deal with such cases generally? I can think of several options, such
as hard-coding the table values (unappealing), or somehow using integer math
(very unappealing, how do we calculate an integer power without massive loss
of precision?)

>
> >
> > you can trivially test this on x86-64 with something like:
> > --cross-prefix=/usr/i686-linux-gnu/bin/ --cc='ccache i686-linux-gnu-gcc-7' 
> > --arch=x86_32  --target-os=linux --enable-cross-compile
> > if you have the correponding packages installed
> >
> > before af6d52eec66961f6a502b0f2f390c12226d087cd
> > TESTfilter-pixdesc-xyz12be
> >
> > after af6d52eec66961f6a502b0f2f390c12226d087cd:
> > --- src/tests/ref/fate/filter-pixdesc-xyz12be   2025-03-14 
> > 00:46:40.445681223 +0100
> > +++ tests/data/fate/filter-pixdesc-xyz12be  2025-03-14 00:47:08.301903796 
> > +0100
> > @@ -1 +1 @@
> > -pixdesc-xyz12be 1508a33dea936c45d9ee13f7743af00d
> > +pixdesc-xyz12be 198f43f452bc55f4ca1e0e0171de5c4c
> > Test filter-pixdesc-xyz12be failed. Look at 
> > tests/data/fate/filter-pixdesc-xyz12be.err for details.
> > make: *** [src/tests/Makefile:311: fate-filter-pixdesc-xyz12be] Error 1
> >
> > in master:
> > --- src/tests/ref/fate/filter-pixdesc-xyz12be   2025-03-14 
> > 00:46:40.445681223 +0100
> > +++ tests/data/fate/filter-pixdesc-xyz12be  2025-03-14 00:48:43.042660972 
> > +0100
> > @@ -1 +1 @@
> > -pixdesc-xyz12be 1508a33dea936c45d9ee13f7743af00d
> > +pixdesc-xyz12be 198f43f452bc55f4ca1e0e0171de5c4c
> > Test filter-pixdesc-xyz12be failed. Look at 
> > tests/data/fate/filter-pixdesc-xyz12be.err for details.
> > make: *** [src/tests/Makefile:315: fate-filter-pixdesc-xyz12be] Error 1
> >
> >
> > thx
> >
> > [...]
> >
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Never trust a computer, one day, it may think you are the virus. -- Compn
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/2] avcodec/mpeg12dec: Use saturated addition when combining, error_count

[Andreas Rheinhardt]

Patches attached.

- Andreas
From e79b422c0ed3732ec15bd25bdf2ad87f45dbddfd Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt 
Date: Fri, 14 Mar 2025 19:10:57 +0100
Subject: [PATCH 1/2] avcodec/mpeg12dec: Use saturated addition when combining
 error_count

Fixes undefined integer overflows. The overflows could always
happen, yet before 4d8b706b1d33e75eb30b289c152280d4535c40e6
it was not undefined because the code implicitly used atomic
types, for which signed integer overflow is defined.

Reported-by: Kacper Michajlow 
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpeg12dec.c | 62 ++
 1 file changed, 33 insertions(+), 29 deletions(-)

diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index ffe0710470..efb66ef956 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -2233,6 +2233,36 @@ static int mpeg_decode_gop(AVCodecContext *avctx,
 return 0;
 }
 
+static void mpeg12_execute_slice_threads(AVCodecContext *avctx,
+ Mpeg1Context *const s)
+{
+if (HAVE_THREADS && (avctx->active_thread_type & FF_THREAD_SLICE) &&
+!avctx->hwaccel) {
+MpegEncContext *const s2 = &s->mpeg_enc_ctx;
+int error_count = 0;
+av_assert0(avctx->thread_count > 1);
+
+avctx->execute(avctx, slice_decode_thread,
+   s2->thread_context, NULL,
+   s->slice_count, sizeof(void *));
+
+for (int i = 0; i < s->slice_count; i++) {
+MpegEncContext *const slice = s2->thread_context[i];
+int slice_err = atomic_load_explicit(&slice->er.error_count,
+ memory_order_relaxed);
+// error_count can get set to INT_MAX on serious errors.
+// So use saturated addition.
+if ((unsigned)slice_err > INT_MAX - error_count) {
+error_count = INT_MAX;
+break;
+}
+error_count += slice_err;
+}
+atomic_store_explicit(&s2->er.error_count, error_count,
+  memory_order_relaxed);
+}
+}
+
 static int decode_chunks(AVCodecContext *avctx, AVFrame *picture,
  int *got_output, const uint8_t *buf, int buf_size)
 {
@@ -2250,22 +2280,7 @@ static int decode_chunks(AVCodecContext *avctx, AVFrame *picture,
 buf_ptr = avpriv_find_start_code(buf_ptr, buf_end, &start_code);
 if (start_code > 0x1ff) {
 if (!skip_frame) {
-if (HAVE_THREADS &&
-(avctx->active_thread_type & FF_THREAD_SLICE) &&
-!avctx->hwaccel) {
-int error_count = 0;
-int i;
-av_assert0(avctx->thread_count > 1);
-
-avctx->execute(avctx, slice_decode_thread,
-   &s2->thread_context[0], NULL,
-   s->slice_count, sizeof(void *));
-for (i = 0; i < s->slice_count; i++)
-error_count += atomic_load_explicit(&s2->thread_context[i]->er.error_count,
-memory_order_relaxed);
-atomic_store_explicit(&s2->er.error_count, error_count,
-  memory_order_relaxed);
-}
+mpeg12_execute_slice_threads(avctx, s);
 
 ret = slice_end(avctx, picture, got_output);
 if (ret < 0)
@@ -2324,19 +2339,8 @@ static int decode_chunks(AVCodecContext *avctx, AVFrame *picture,
 s2->intra_dc_precision= 3;
 s2->intra_matrix[0]= 1;
 }
-if (HAVE_THREADS && (avctx->active_thread_type & FF_THREAD_SLICE) &&
-!avctx->hwaccel && s->slice_count) {
-int error_count = 0;
-int i;
-
-avctx->execute(avctx, slice_decode_thread,
-   s2->thread_context, NULL,
-   s->slice_count, sizeof(void *));
-for (i = 0; i < s->slice_count; i++)
-error_count += atomic_load_explicit(&s2->thread_context[i]->er.error_count,
-memory_order_relaxed);
-atomic_store_explicit(&s2->er.error_count, error_count,
-  memory_order_relaxed);
+if (s->slice_count) {
+mpeg12_execute_slice_threads(avctx, s);
 s->slice_count = 0;
 }
 if (last_code == 0 || last_code == SLICE_MIN_START_CODE) {
-- 
2.45.2

From 12d3af209ed16a136d917f8b12e8547213fef52f Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt 
Date: Fri, 14 Mar 2025 20:18:37 +0100
Subject: [PATCH 2/2] avcodec/mpeg12dec: Don't assert on thread_count

Nothing in this decoder would break if the generic cod

Re: [FFmpeg-devel] Misc mpegvideo patches

[Andreas Rheinhardt]

Andreas Rheinhardt:
> Kacper Michajlow:
>> On Thu, 6 Mar 2025 at 14:31, Andreas Rheinhardt
>>  wrote:
>>>
>>> Andreas Rheinhardt:
 Ramiro Polla:
> On Tue, Mar 4, 2025 at 6:05 PM Andreas Rheinhardt
>  wrote:
>> Ramiro Polla:
>>>
>>> On 3/4/25 14:42, Andreas Rheinhardt wrote:
 (Mostly trivial) patches attached. A branch is at
 https://github.com/mkver/FFmpeg/tree/mpegvideo_misc
>>>
>>>
>>> [PATCH 10/40] avcodec/mpegvideo_enc: Move default_mv_penalty to 
>>> h261enc.c
>>>
 diff --git a/libavcodec/h261enc.c b/libavcodec/h261enc.c
 index dabab9d80a..e33bf35a8a 100644
 --- a/libavcodec/h261enc.c
 +++ b/libavcodec/h261enc.c
 @@ -46,6 +46,7 @@ static struct VLCLUT {
  uint16_t code;
  } vlc_lut[H261_MAX_RUN + 1][32 /* 0..2 * H261_MAX_LEN are used */];

 +static uint8_t mv_penalty[MAX_FCODE + 1][MAX_DMV * 2 + 1];
  static uint8_t uni_h261_rl_len [64 * 128];
  static uint8_t uni_h261_rl_len_last[64 * 128];
  static uint8_t h261_mv_codes[64][2];
 @@ -370,6 +371,8 @@ av_cold int ff_h261_encode_init(MpegEncContext *s)
  s->max_qcoeff   = 127;
  s->ac_esc_length= H261_ESC_LEN;

 +s->me.mv_penalty = mv_penalty;
 +
  s->intra_ac_vlc_length  = s->inter_ac_vlc_length  =
 uni_h261_rl_len;
  s->intra_ac_vlc_last_length = s->inter_ac_vlc_last_length =
 uni_h261_rl_len_last;
  ff_thread_once(&init_static_once, h261_encode_init_static);
>>>
>>> This global mv_penalty doesn't seem to be ever initialized; it could be
>>> declared const.
>>
>> But then it would no longer be placed in .bss, but instead in .rodata
>> and increase binary size.
>
> Wow, that's a huge array.
>
>>> But it also makes me think that whatever code is using this mv_penalty,
>>> which is always set to zero, might be calculating things wrong.
>>>
>>
>> It is obviously done to avoid branches for the codecs that matter. H.261
>> does not matter much. Apart from that, it is a very cheap workaround
>> given that this table is .bss.
>
> Could you add some comments (either next to the declaration or the
> commit message) to reflect this? (save space from .rodata, and this
> being a noop for h.261, which doesn't matter that much)
>
>>> [PATCH 15/40] avcodec/ituh263enc: Make SVQ1+Snowenc stop calling
>>> ff_h263_encode_init()
>>>
 diff --git a/libavcodec/ituh263enc.c b/libavcodec/ituh263enc.c
 index 02da090ba4..8313b2c2c1 100644
 --- a/libavcodec/ituh263enc.c
 +++ b/libavcodec/ituh263enc.c
 @@ -65,6 +65,127 @@ static uint8_t  uni_h263_inter_rl_len [64*64*2*2];
>>> [...]
 +static av_cold void h263_encode_init_static(void)
 +{
 +static uint8_t rl_intra_table[2][2 * MAX_RUN + MAX_LEVEL + 3];
 +
 +ff_rl_init(&ff_rl_intra_aic, rl_intra_table);
 +ff_h263_init_rl_inter();
 +
 +init_uni_h263_rl_tab(&ff_rl_intra_aic,  
 uni_h263_intra_aic_rl_len);
 +init_uni_h263_rl_tab(&ff_h263_rl_inter, uni_h263_inter_rl_len);
 +
 +init_mv_penalty_and_fcode();
 +}
 +
 +av_cold const uint8_t (*ff_h263_get_mv_penalty(void))[MAX_DMV*2+1]
 +{
 +static AVOnce init_static_once = AV_ONCE_INIT;
 +
 +ff_thread_once(&init_static_once, h263_encode_init_static);
 +
 +return mv_penalty;
 +}
 +
>>>
>>> This approach kind of hides the rest of h263_encode_init_static() inside
>>> ff_h263_get_mv_penalty(), so the name is a bit misleading. I'd expect
>>> h263 to still call some init function and ff_h263_get_mv_penalty(), and
>>> SVQ1 and Snow to only call ff_h263_get_mv_penalty(), which would only
>>> take care of the mv_penalty table.
>>>
>>
>> This would entail using another AVOnce etc. and this level of
>> granularity is just not worth it.
>
> Ok.
>
>> The name is chosen for what it does for an outsider (i.e. from the
>> perspective of svq1enc or snowenc, not the actual H.263 based encoders).
>
> I'm still not quite happy with the name and how it's used, but it's
> good enough so I won't insist.
>
>>> [PATCH 20/40] avcodec/mpeg4video: Split ff_mpeg4_pred_dc()
>>>
 diff --git a/libavcodec/mpeg4videoenc.c b/libavcodec/mpeg4videoenc.c
 index 64fb96a0cf..26f9b40ff7 100644
 --- a/libavcodec/mpeg4videoenc.c
 +++ b/libavcodec/mpeg4videoenc.c
 @@ -806,8 +806,14 @@ void ff_mpeg4_encode_mb(MpegEncContext *s,
 int16_t block[6][64],
  const uint8_t *scan_table[6];
  int i;

 -for (i = 0; i < 6; 

Re: [FFmpeg-devel] [PATCH] avfilter: POC: enable out-of-tree filters

[Nicolas George]

Lynne (HE12025-03-14):
> This is a pointless patch and a pointlessly complex addition to the build
> system. I wouldn't accept something like this.
> Those who for some reason have custom filters simply distribute their own
> branch with properly integrated filters.

That works for third-party from one third-party. This feature helps
users who want to use filters from multiple third-party. With what you
describe, they would have to merge the branches, which might not be
trivial.

On the other hand, the JSON in this makes it look like it was designed
by looking at how fashionable languages NIHed their own f5g package
system.

If instead it was designed by asking “what would a ffmpeg developer do”,
it would just have configure run ext/*/configure and then Makefile
include $(CONFIG_EXT_WHATEVER).

Regards,

-- 
  Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 09/12] avcodec/sanm: codec4/5/33/34 decoder

[Manuel Lauss]

Servus Andreas,

On Fri, Mar 14, 2025 at 1:08 AM Andreas Rheinhardt
 wrote:

> > +static int old_codec4(SANMVideoContext *ctx, int left, int top, int w, int 
> > h,
> > +  uint8_t param, uint16_t param2, int codec)
> > +{
> > +const uint16_t p = ctx->pitch;
> > +const uint32_t maxpxo = ctx->height * p;
> > +uint8_t mask, bits, idx, *gs, *dst = (uint8_t *)ctx->frm0;
> > +int i, j, k, l, bit, ret;
> > +int32_t pxoff, pxo2;
> > +

> > +for (j = 0; j < w; j += 4) {
>
> Why don't you use loop-scope for iterators?

Personal preference, really.I'll change it if you want me to.

Manuel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] RISC-V:update ff_get_cpu_flags_riscv for RVV

[daichengrong]

From: daichengrong 

Availability of RVV and ZVBB should be determined with dl_hwcap.

As those extensions rely on vector registers, kernel vector support 
is required to save the state of context switching.

FFmpeg requires hwprobe for hardware capability detection, and cooperates 
with dl_hwcap to detect whether the kernel supports vector.

---
 libavutil/riscv/cpu.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/libavutil/riscv/cpu.c b/libavutil/riscv/cpu.c
index 163e4fc14a..fad63eccea 100644
--- a/libavutil/riscv/cpu.c
+++ b/libavutil/riscv/cpu.c
@@ -55,6 +55,10 @@ int ff_get_cpu_flags_riscv(void)
 { RISCV_HWPROBE_KEY_CPUPERF_0, 0 },
 };
 
+#if HAVE_GETAUXVAL || HAVE_ELF_AUX_INFO
+const unsigned long hwcap = ff_getauxval(AT_HWCAP);
+#endif
+
 if (__riscv_hwprobe(pairs, FF_ARRAY_ELEMS(pairs), 0, NULL, 0) == 0) {
 if (pairs[0].value & RISCV_HWPROBE_BASE_BEHAVIOR_IMA)
 ret |= AV_CPU_FLAG_RVI;
@@ -62,6 +66,12 @@ int ff_get_cpu_flags_riscv(void)
 if (pairs[1].value & RISCV_HWPROBE_IMA_V)
 ret |= AV_CPU_FLAG_RVV_I32 | AV_CPU_FLAG_RVV_I64
  | AV_CPU_FLAG_RVV_F32 | AV_CPU_FLAG_RVV_F64;
+#if HAVE_GETAUXVAL || HAVE_ELF_AUX_INFO
+/* The V extension implies all Zve* functional subsets */
+if (!(hwcap & HWCAP_RV('V')))
+ret &= ~(AV_CPU_FLAG_RVV_I32 | AV_CPU_FLAG_RVV_I64
+ | AV_CPU_FLAG_RVV_F32 | AV_CPU_FLAG_RVV_F64);
+#endif
 #endif
 #ifdef RISCV_HWPROBE_EXT_ZBB
 if (pairs[1].value & RISCV_HWPROBE_EXT_ZBB)
@@ -76,6 +86,10 @@ int ff_get_cpu_flags_riscv(void)
 #ifdef RISCV_HWPROBE_EXT_ZVBB
 if (pairs[1].value & RISCV_HWPROBE_EXT_ZVBB)
 ret |= AV_CPU_FLAG_RV_ZVBB;
+#if HAVE_GETAUXVAL || HAVE_ELF_AUX_INFO
+if (!(hwcap & HWCAP_RV('V')))
+ret &= ~AV_CPU_FLAG_RV_ZVBB;
+#endif
 #endif
 switch (pairs[2].value & RISCV_HWPROBE_MISALIGNED_MASK) {
 case RISCV_HWPROBE_MISALIGNED_FAST:
-- 
2.25.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter: POC: enable out-of-tree filters

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Lynne
> Sent: Freitag, 14. März 2025 17:58
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: POC: enable out-of-tree
> filters
> 
> On 13/03/2025 13:18, Leandro Santiago wrote:
> > This is a POC/prototype that aims to enable out of tree filters on
> > FFmpeg.
> >
> > Here I name them "extra filters".
> >
> > It introduces the program `jq` as a new build dependency.
> >
> > To test it, create a directory, for instance, /tmp/my-shiny-filter/
> and
> > inside it, create the following files:
> >
> > `filter.json`, with the content:
> 
> This is a pointless patch and a pointlessly complex addition to the
> build system. I wouldn't accept something like this.
> Those who for some reason have custom filters simply distribute their
> own branch with properly integrated filters. This also lets them
> upstream it if they want to.
> ___

Hi Lynne,

as someone who is using a number of custom filters, I can say that the "own 
branch with properly integrated filters" approach is a continuing source of 
trouble when rebasing or trying to apply it to different base branches. Even 
though these aren't really 3rd party filters, having a mechanism for it would 
make it much easier to maintain additional filters.
I don't want to argue about the specific approach as other will know better 
than me, but I'm sure that it's possible to find a nice non-complex way, no?

sw




___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/5] avcodec/ffv1: fix remap without chroma planes

[Michael Niedermayer]

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer 
---
 libavcodec/ffv1dec.c | 3 +--
 libavcodec/ffv1enc.c | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index e534583d8d6..d702e36625a 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -252,10 +252,9 @@ static void slice_set_damaged(FFV1Context *f, 
FFV1SliceContext *sc)
 
 static int decode_remap(FFV1Context *f, FFV1SliceContext *sc)
 {
-int transparency = f->transparency;
 int flip = sc->remap == 2 ? 0x7FFF : 0;
 
-for (int p= 0; p<3 + transparency; p++) {
+for (int p= 0; p < 1 + 2*f->chroma_planes + f->transparency; p++) {
 int j = 0;
 int lu = 0;
 uint8_t state[2][32];
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 5d3daef15ec..b8ccda469ec 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -1159,10 +1159,9 @@ static void choose_rct_params(const FFV1Context *f, 
FFV1SliceContext *sc,
 
 static void encode_remap(FFV1Context *f, FFV1SliceContext *sc)
 {
-int transparency = f->transparency;
 int flip = sc->remap == 2 ? 0x7FFF : 0;
 
-for (int p= 0; p<3 + transparency; p++) {
+for (int p= 0; p < 1 + 2*f->chroma_planes + f->transparency; p++) {
 int j = 0;
 int lu = 0;
 uint8_t state[2][32];
-- 
2.48.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/5] avcodec/ffv1: Add GRAYF16 support

[Michael Niedermayer]

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer 
---
 libavcodec/ffv1_parse.c |  5 -
 libavcodec/ffv1dec.c| 27 +++
 libavcodec/ffv1enc.c|  2 ++
 3 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/libavcodec/ffv1_parse.c b/libavcodec/ffv1_parse.c
index a49f1eb6cef..9745f9de694 100644
--- a/libavcodec/ffv1_parse.c
+++ b/libavcodec/ffv1_parse.c
@@ -288,7 +288,10 @@ int ff_ffv1_parse_header(FFV1Context *f, RangeCoder *c, 
uint8_t *state)
 f->pix_fmt = AV_PIX_FMT_GRAY14;
 } else if (f->avctx->bits_per_raw_sample == 16) {
 f->packed_at_lsb = 1;
-f->pix_fmt = AV_PIX_FMT_GRAY16;
+if (f->flt) {
+f->pix_fmt = AV_PIX_FMT_GRAYF16;
+} else
+f->pix_fmt = AV_PIX_FMT_GRAY16;
 } else if (f->avctx->bits_per_raw_sample < 16) {
 f->pix_fmt = AV_PIX_FMT_GRAY16;
 } else
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index e24c6b8d3a2..968c386f897 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -125,16 +125,27 @@ static int decode_plane(FFV1Context *f, FFV1SliceContext 
*sc,
 int ret = decode_line(f, sc, gb, w, sample, plane_index, 
f->avctx->bits_per_raw_sample, ac);
 if (ret < 0)
 return ret;
-if (sc->remap)
-for (x = 0; x < w; x++)
-sample[1][x] = sc->fltmap[remap_index][sample[1][x]];
-if (f->packed_at_lsb) {
-for (x = 0; x < w; x++) {
-((uint16_t*)(src + stride*y))[x*pixel_stride] = 
sample[1][x];
+
+if (sc->remap) {
+if (f->packed_at_lsb || f->avctx->bits_per_raw_sample == 16) {
+for (x = 0; x < w; x++) {
+((uint16_t*)(src + stride*y))[x*pixel_stride] = 
sc->fltmap[remap_index][sample[1][x] & 0x];
+}
+} else {
+for (x = 0; x < w; x++) {
+int v = sc->fltmap[remap_index][sample[1][x] & 0x];
+((uint16_t*)(src + stride*y))[x*pixel_stride] = v << 
(16 - f->avctx->bits_per_raw_sample) | v >> (2 * f->avctx->bits_per_raw_sample 
- 16);
+}
 }
 } else {
-for (x = 0; x < w; x++) {
-((uint16_t*)(src + stride*y))[x*pixel_stride] = 
sample[1][x] << (16 - f->avctx->bits_per_raw_sample) | ((uint16_t 
**)sample)[1][x] >> (2 * f->avctx->bits_per_raw_sample - 16);
+if (f->packed_at_lsb || f->avctx->bits_per_raw_sample == 16) {
+for (x = 0; x < w; x++) {
+((uint16_t*)(src + stride*y))[x*pixel_stride] = 
sample[1][x];
+}
+} else {
+for (x = 0; x < w; x++) {
+((uint16_t*)(src + stride*y))[x*pixel_stride] = 
sample[1][x] << (16 - f->avctx->bits_per_raw_sample) | ((uint16_t 
**)sample)[1][x] >> (2 * f->avctx->bits_per_raw_sample - 16);
+}
 }
 }
 }
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 9fb98c37584..3879d1b19a1 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -842,6 +842,7 @@ av_cold int ff_ffv1_encode_setup_plane_info(AVCodecContext 
*avctx,
 case AV_PIX_FMT_YUVA444P16:
 case AV_PIX_FMT_YUVA422P16:
 case AV_PIX_FMT_YUVA420P16:
+case AV_PIX_FMT_GRAYF16:
 case AV_PIX_FMT_YAF16:
 if (!avctx->bits_per_raw_sample && !s->bits_per_raw_sample) {
 s->bits_per_raw_sample = 16;
@@ -1565,6 +1566,7 @@ const FFCodec ff_ffv1_encoder = {
 AV_PIX_FMT_YUV420P14, AV_PIX_FMT_YUV422P14, AV_PIX_FMT_YUV444P14,
 AV_PIX_FMT_YUV440P10, AV_PIX_FMT_YUV440P12,
 AV_PIX_FMT_YAF16,
+AV_PIX_FMT_GRAYF16,
 AV_PIX_FMT_GBRPF16),
 .color_ranges   = AVCOL_RANGE_MPEG,
 .p.priv_class   = &ffv1_class,
-- 
2.48.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/vlc: Reduce debug logging

[Michael Niedermayer]

Hi

On Fri, Mar 14, 2025 at 03:46:35AM +, Soft Works wrote:
> 
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > Michael Niedermayer
> > Sent: Freitag, 14. März 2025 01:28
> > To: FFmpeg development discussions and patches 
> > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/vlc: Reduce debug logging
> > 
> > Hi
> > 
> > On Wed, Mar 12, 2025 at 03:48:20AM +, softworkz wrote:
> > > From: softworkz 
> > >
> > > Signed-off-by: softworkz 
> > > ---
> > > avcodec/vlc: Reduce debug logging
> > >
> > > It made it hardly possible to enable debug logging for viewing
> > other log
> > > lines due to the excessive output created by this.
> > >
> > > Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-
> > ffstaging-60%2Fsoftworkz%2Fsubmit_vlclogging-v1
> > > Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-
> > ffstaging-60/softworkz/submit_vlclogging-v1
> > > Pull-Request: https://github.com/ffstaging/FFmpeg/pull/60
> > >
> > >  libavcodec/vlc.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > will apply
> 
> Thanks!
> 
> 
> > btw, speaking of excessive output,
> > valgrind_backtrace (which is enabled by default when optimizations are
> > disabled)
> 
> Only when you have it installed I suppose..? 

yes

Combine that with myself often lazyly throwing av_log(0,0, ...) in as a quick
debug fprintf(stderr, ...
and the 0 log level then triggers the valgrind backtrace
For me its 99% of the time not what i want.

I wonder if other people use that backtrace feature ?
or if it would be better switched off by default, or
switched off for log_level == 0

or maybe i should just stop using av_log(0,0, ...

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec: Mark init and close functions as av_cold

[Andreas Rheinhardt]

Patch attached.

- Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 11/12] avcodec/sanm: change GetByteContext member to pointer

[Michael Niedermayer]

Hi Manuel

On Thu, Mar 13, 2025 at 12:15:04PM +0100, Manuel Lauss wrote:
> In order do properly support the ANIM STOR/FTCH system, the FTCH
> must replay a stored FOBJ and change the SANMContext's "GetByteContext"
> member temporarily.
> 
> Signed-off-by: Manuel Lauss 
> ---
>  libavcodec/sanm.c | 394 +++---
>  1 file changed, 198 insertions(+), 196 deletions(-)
> 
> diff --git a/libavcodec/sanm.c b/libavcodec/sanm.c
> index a8a3e04156..207db4a8fb 100644
> --- a/libavcodec/sanm.c
> +++ b/libavcodec/sanm.c

[...]

> @@ -2114,10 +2114,12 @@ static int decode_frame(AVCodecContext *avctx, 
> AVFrame *frame,
>  int *got_frame_ptr, AVPacket *pkt)
>  {
>  SANMVideoContext *ctx = avctx->priv_data;
> +GetByteContext gb;
>  int i, ret;
>  
>  ctx->frame = frame;
> -bytestream2_init(&ctx->gb, pkt->data, pkt->size);
> +bytestream2_init(&gb, pkt->data, pkt->size);
> +ctx->gb = &gb;

Having a context pointer point to the local stack is fragile
Because the context and pointer have a longer lifetime than the stack

So for a long portion of the time this pointer is totally invalid

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 11/12] avcodec/sanm: change GetByteContext member to pointer

[Manuel Lauss]

Michael

On Fri, Mar 14, 2025 at 9:31 PM Michael Niedermayer
 wrote:
>
> Hi Manuel
>
> On Thu, Mar 13, 2025 at 12:15:04PM +0100, Manuel Lauss wrote:
> > In order do properly support the ANIM STOR/FTCH system, the FTCH
> > must replay a stored FOBJ and change the SANMContext's "GetByteContext"
> > member temporarily.
> >
> > Signed-off-by: Manuel Lauss 
> > ---
> >  libavcodec/sanm.c | 394 +++---
> >  1 file changed, 198 insertions(+), 196 deletions(-)
> >
> > diff --git a/libavcodec/sanm.c b/libavcodec/sanm.c
> > index a8a3e04156..207db4a8fb 100644
> > --- a/libavcodec/sanm.c
> > +++ b/libavcodec/sanm.c
>
> [...]
>
> > @@ -2114,10 +2114,12 @@ static int decode_frame(AVCodecContext *avctx, 
> > AVFrame *frame,
> >  int *got_frame_ptr, AVPacket *pkt)
> >  {
> >  SANMVideoContext *ctx = avctx->priv_data;
> > +GetByteContext gb;
> >  int i, ret;
> >
> >  ctx->frame = frame;
> > -bytestream2_init(&ctx->gb, pkt->data, pkt->size);
> > +bytestream2_init(&gb, pkt->data, pkt->size);
> > +ctx->gb = &gb;
>
> Having a context pointer point to the local stack is fragile
> Because the context and pointer have a longer lifetime than the stack
>
> So for a long portion of the time this pointer is totally invalid

I see your point, however the GetByteContext is only ever used during
this decode_frame() function, never outside of it.
But, I'll think of something else.

Danke dir!
 Manuel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter: POC: enable out-of-tree filters

[Michael Niedermayer]

On Fri, Mar 14, 2025 at 05:13:23PM +0100, Leandro Santiago wrote:
[...]
> > 
> > also there is the quite intriguing option of using "git merge" to include
> > external filters
> > What i mean here is that there could be a script lets call it ffmerge

> How would it work when using release tarballs, without git?

it would tell the user to run it in a git checkout or an empty directory.
The script would already have the ability to merge external filter repos
so also pulling mainline is no real extra complexity


> > "ffmerge available" would check some online repository and list whats
> > compatible with the current checkout
> > 
> > "ffmerge merge shiny_filter" would then merge the shiny filter 
> > repository/branch

> Wouldn't it put more burden over the devs to maintain such
> catalog/repository and the tooling around it? I am fine with that, I just
> wonder how the community would accept it. Having no filter catalog/repo
> feels to be the simplest step one could take at the moment.

theres no need for such catalog. I just think that if external filter
support is added, that someone will then likely start maintaining a catalog
of these filters.


thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [FFmpeg-cvslog] swscale: use 16-bit intermediate precision for RGB/XYZ conversion

[Michael Niedermayer]

On Fri, Mar 14, 2025 at 12:54:25AM +0100, Michael Niedermayer wrote:
> Hi
> 
> On Sun, Jan 26, 2025 at 07:26:59PM +0100, Michael Niedermayer wrote:
> > On Thu, Dec 26, 2024 at 07:33:23PM +, Niklas Haas wrote:
> > > ffmpeg | branch: master | Niklas Haas  | Mon Dec 16 
> > > 14:49:39 2024 +0100| [af6d52eec66961f6a502b0f2f390c12226d087cd] | 
> > > committer: Niklas Haas
> > > 
> > > swscale: use 16-bit intermediate precision for RGB/XYZ conversion
> > > 
> > > The current logic uses 12-bit linear light math, which is woefully 
> > > insufficient
> > > and leads to nasty postarization artifacts. This patch simply switches the
> > > internal logic to 16-bit precision.
> > > 
> > > This raises the memory requirement of these tables from 32 kB to 272 kB.
> > > 
> > > All relevant FATE tests updated for improved accuracy.
> > > 
> > > Fixes: #4829
> > > Signed-off-by: Niklas Haas 
> > > Sponsored-by: Sovereign Tech Fund
> > > 
> > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=af6d52eec66961f6a502b0f2f390c12226d087cd
> > > ---
> > 
> > this breaks on x86-32
> 
> ping
> 
> the fate tests for a major architecture are broken since this
> This impacts future bisections over that range for example

It also prevents others from easily seeing other failures as x86-32 is
already broken

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/vlc: Reduce debug logging

[Michael Niedermayer]

Hi

On Wed, Mar 12, 2025 at 03:48:20AM +, softworkz wrote:
> From: softworkz 
> 
> Signed-off-by: softworkz 
> ---
> avcodec/vlc: Reduce debug logging
> 
> It made it hardly possible to enable debug logging for viewing other log
> lines due to the excessive output created by this.
> 
> Published-As: 
> https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-60%2Fsoftworkz%2Fsubmit_vlclogging-v1
> Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg 
> pr-ffstaging-60/softworkz/submit_vlclogging-v1
> Pull-Request: https://github.com/ffstaging/FFmpeg/pull/60
> 
>  libavcodec/vlc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

will apply

btw, speaking of excessive output,
valgrind_backtrace (which is enabled by default when optimizations are disabled)
is also a feature that is rarely useful but very annoying noise wise
(just saying in case anyone wants to reduce noise in general)

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 00/12] avcodec/sanm: various improvements

[Manuel Lauss]

Hi Michael,

On Fri, Mar 14, 2025 at 1:06 AM Michael Niedermayer
 wrote:
>
> Hi Manuel
>
> please add yourself to the MAINTAINER file for sanm with a patch
> you are already maintaining sanm, its just not written in the file

Fine, I'll add a patch for this in a v2 patchset.

Manuel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [FFmpeg-cvslog] tests/fate/pixfmt: add conversion tests with semi planar YUV formats

[Martin Storsjö]

On Thu, 13 Mar 2025, James Almer wrote:


ffmpeg | branch: master | James Almer  | Sun Mar  9 23:16:18 
2025 -0300| [c3b60e0df73b85306c17de43063c43ea7ea82a05] | committer: James Almer

tests/fate/pixfmt: add conversion tests with semi planar YUV formats

Signed-off-by: James Almer 


http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=c3b60e0df73b85306c17de43063c43ea7ea82a05

---


pixfmt-p410-p416le is failing in a large number of configurations.

// Martin

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] gitattributes: End merge conflicts in Changelog

[Michael Niedermayer]

Similar could be done with other lists that generally are appended to

Signed-off-by: Michael Niedermayer 
---
 .gitattributes | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitattributes b/.gitattributes
index a900528e474..b64bbed2eb4 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -1 +1,2 @@
 *.pnm -diff -text
+Changelogmerge=union
-- 
2.48.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 01/16] pixfmt: add AV_PIX_FMT_GBRAP32

[Lynne]

On 14/03/2025 16:13, Michael Niedermayer wrote:

On Thu, Mar 13, 2025 at 06:03:33PM +0100, Lynne wrote:

This commit adds a 32-bit *integer* planar RGBA format.
Vulkan FFv1 decoding is best performed on separate planes, rather than
packed RGBA (i.e. RGBA128), hence this is useful as an intermediate format.
---
  libavutil/pixdesc.c | 28 
  libavutil/pixfmt.h  |  4 
  2 files changed, 32 insertions(+)


breaks fate

--- ./tests/ref/fate/imgutils   2025-03-14 00:56:35.182435551 +0100
+++ tests/data/fate/imgutils2025-03-14 16:12:30.642340871 +0100
@@ -296,6 +296,8 @@
  yaf32le planes: 1, linesizes: 512   0   0   0, plane_sizes: 24576 
0 0 0, plane_offsets: 0 0 0, total_size: 24576
  yaf16be planes: 1, linesizes: 256   0   0   0, plane_sizes: 12288 
0 0 0, plane_offsets: 0 0 0, total_size: 12288
  yaf16le planes: 1, linesizes: 256   0   0   0, plane_sizes: 12288 
0 0 0, plane_offsets: 0 0 0, total_size: 12288
+gbrap32be   planes: 4, linesizes: 256 256 256 256, plane_sizes: 12288 
12288 12288 12288, plane_offsets: 12288 12288 12288, total_size: 49152
+gbrap32le   planes: 4, linesizes: 256 256 256 256, plane_sizes: 12288 
12288 12288 12288, plane_offsets: 12288 12288 12288, total_size: 49152

  image_fill_black tests
  yuv420p total_size:   4608,  black_unknown_crc: 0xd00f6cc6,  
black_tv_crc: 0xd00f6cc6,  black_pc_crc: 0x234969af
@@ -539,3 +541,5 @@
  yaf32le total_size:  24576,  black_unknown_crc: 0xfd900236,  
black_tv_crc: 0xfd900236,  black_pc_crc: 0xdcaf0cb1
  yaf16be total_size:  12288,  black_unknown_crc: 0x7afe9aae,  
black_tv_crc: 0x7afe9aae,  black_pc_crc: 0x0fc0a5d0
  yaf16le total_size:  12288,  black_unknown_crc: 0x94c0068b,  
black_tv_crc: 0x94c0068b,  black_pc_crc: 0xc05ce449
+gbrap32be   total_size:  49152,  black_unknown_crc: 0x7bd30c95,  
black_tv_crc: 0x7bd30c95,  black_pc_crc: 0x7bd30c95
+gbrap32le   total_size:  49152,  black_unknown_crc: 0x7bd30c95,  
black_tv_crc: 0x7bd30c95,  black_pc_crc: 0x7bd30c95
Test imgutils failed. Look at tests/data/fate/imgutils.err for details.
make: *** [tests/Makefile:311: fate-imgutils] Error 1


I know. Was planning on fixing fate tests when I push, since it makes 
rebasing easier.

I always keep my branch up to date:
https://github.com/cyanreg/FFmpeg/tree/vulkan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter: POC: enable out-of-tree filters

[Leandro Santiago]

On 3/14/25 16:04, Michael Niedermayer wrote:

Hi

On Thu, Mar 13, 2025 at 01:18:49PM +0100, Leandro Santiago wrote:

This is a POC/prototype that aims to enable out of tree filters on
FFmpeg.

Here I name them "extra filters".


Thinking now, "extra filters" is not a good name. Maybe "external" or "oot"

It introduces the program `jq` as a new build dependency.

I dont think this dependency is needed to achieve linking to filters
in another directory
To make it clear, the "extra filters" are linked in the same way the 
current filters are: direct as part libavfilter.(so|a). They are not 
dynamically linked.

i think its worth the few hours extra time to find a clean/nice way to do it
with no new depeandancies


I used json as a quick way to define the filter metadata (thus the usage 
of JQ to query them), but I confess it could have been any other format. 
I used json to get the proof of concept done :-)


Ideally it would be written in a native format to the build system, if 
something like CMake or Meson was being used.


Maybe the metadata could even be in a Makefile or spread over multiple 
files with no structure. The use of json was for pure convenience. Would 
you have any format to suggest? Is there anything similar in the 
codebase I could have a look at?


This is an example of metadata file at the moment:

{
"ldflags":"-ljson-c",
"cflags":"-DFOO=234",
"check":"require_pkg_config json json-c json-c/json.h json_c_version_num",
"symbols":["ff_vf_foo","ff_vf_bar"]
}

A simpler way to represent it would be put each field in a different 
pure text file, for instance:


symbols.txt:

ff_vf_foo ff_vf_bar

The most important aspect here is that the filter metadata (symbols, 
names, flags) need to be in a format easy to parse from the `configure` 
script.


I did some improvements on my patch and I managed to get the filter to 
pass extra flags on building.


Although the use of forgejo is not yet official, I am keeping my changes 
on it for now, as I still struggle with the email workflow:


https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/13

The "example" filter can be found at:

https://gitlab.com/leandrosansilva/ffmpeg-extra-filter-example/

To use it, simply clone this repo and build ffmpeg with 
`--extra-filter=/path/to/ffmpeg-extra-filter-example`.




also there is the quite intriguing option of using "git merge" to include
external filters
What i mean here is that there could be a script lets call it ffmerge

How would it work when using release tarballs, without git?

"ffmerge available" would check some online repository and list whats
compatible with the current checkout

"ffmerge merge shiny_filter" would then merge the shiny filter repository/branch
Wouldn't it put more burden over the devs to maintain such 
catalog/repository and the tooling around it? I am fine with that, I 
just wonder how the community would accept it. Having no filter 
catalog/repo feels to be the simplest step one could take at the moment.


Advanatge would be that this is more powerfull than just linking external
filters.
Disadvantage is that for this to work care needs to be taken that conflicts
do not occur


I see that simply keeping the filter outside and linking them at build 
time put almost no burden on the ffmpeg devs.


As, provided there is no promise of a stable API, it's up to the 
developers of the "extra" filters to make their filters build.




thx

[...]


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 01/16] pixfmt: add AV_PIX_FMT_GBRAP32

[Marton Balint]

On Fri, 14 Mar 2025, Lynne wrote:


On 14/03/2025 16:13, Michael Niedermayer wrote:

 On Thu, Mar 13, 2025 at 06:03:33PM +0100, Lynne wrote:

 This commit adds a 32-bit *integer* planar RGBA format.
 Vulkan FFv1 decoding is best performed on separate planes, rather than
 packed RGBA (i.e. RGBA128), hence this is useful as an intermediate
 format.
 ---
   libavutil/pixdesc.c | 28 
   libavutil/pixfmt.h  |  4 
   2 files changed, 32 insertions(+)


 breaks fate

 --- ./tests/ref/fate/imgutils  2025-03-14 00:56:35.182435551 +0100
 +++ tests/data/fate/imgutils   2025-03-14 16:12:30.642340871 +0100
 @@ -296,6 +296,8 @@
   yaf32le planes: 1, linesizes: 512   0   0   0, plane_sizes:
   24576 0 0 0, plane_offsets: 0 0 0, total_size:
   24576
   yaf16be planes: 1, linesizes: 256   0   0   0, plane_sizes:
   12288 0 0 0, plane_offsets: 0 0 0, total_size:
   12288
   yaf16le planes: 1, linesizes: 256   0   0   0, plane_sizes:
   12288 0 0 0, plane_offsets: 0 0 0, total_size:
   12288
 +gbrap32be   planes: 4, linesizes: 256 256 256 256, plane_sizes: 12288
 12288 12288 12288, plane_offsets: 12288 12288 12288, total_size: 49152
 +gbrap32le   planes: 4, linesizes: 256 256 256 256, plane_sizes: 12288
 12288 12288 12288, plane_offsets: 12288 12288 12288, total_size: 49152

   image_fill_black tests
   yuv420p total_size:   4608,  black_unknown_crc: 0xd00f6cc6,
   black_tv_crc: 0xd00f6cc6,  black_pc_crc: 0x234969af
 @@ -539,3 +541,5 @@
   yaf32le total_size:  24576,  black_unknown_crc: 0xfd900236,
   black_tv_crc: 0xfd900236,  black_pc_crc: 0xdcaf0cb1
   yaf16be total_size:  12288,  black_unknown_crc: 0x7afe9aae,
   black_tv_crc: 0x7afe9aae,  black_pc_crc: 0x0fc0a5d0
   yaf16le total_size:  12288,  black_unknown_crc: 0x94c0068b,
   black_tv_crc: 0x94c0068b,  black_pc_crc: 0xc05ce449
 +gbrap32be   total_size:  49152,  black_unknown_crc: 0x7bd30c95,
 black_tv_crc: 0x7bd30c95,  black_pc_crc: 0x7bd30c95
 +gbrap32le   total_size:  49152,  black_unknown_crc: 0x7bd30c95,
 black_tv_crc: 0x7bd30c95,  black_pc_crc: 0x7bd30c95
 Test imgutils failed. Look at tests/data/fate/imgutils.err for details.
 make: *** [tests/Makefile:311: fate-imgutils] Error 1


I know. Was planning on fixing fate tests when I push, since it makes 
rebasing easier.


I don't think this is a good practice. It makes patch review or testing 
harder, the fact that a patch changes fate is useful information for 
reviewer. Not to mention that you can easily forgot to update the fate 
references before push, and a pushed commit which fails fate is a bad 
thing. So please, do not send patches which fails to pass fate.


Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] ffv1: implement remap for encode/decode_plane()

[Michael Niedermayer]

On Tue, Mar 11, 2025 at 04:06:58PM -0300, James Almer wrote:
> 
> 
> On 3/11/2025 11:13 AM, James Almer wrote:
> > On 3/10/2025 9:59 PM, Michael Niedermayer wrote:
> > > On Mon, Mar 10, 2025 at 06:48:29PM +0100, Lynne wrote:
> > > > On 10/03/2025 01:45, Michael Niedermayer wrote:
> > > > > Sponsored-by: Sovereign Tech Fund
> > > > > Signed-off-by: Michael Niedermayer 
> > > > > ---
> > > > >    libavcodec/ffv1dec.c | 20 -
> > > > >    libavcodec/ffv1enc.c | 67
> > > > > + +--
> > > > >    2 files changed, 71 insertions(+), 16 deletions(-)
> > > > > 
> > > > > diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
> > > > > index 9738e4e9c9f..72c93fcf0cd 100644
> > > > > --- a/libavcodec/ffv1dec.c
> > > > > +++ b/libavcodec/ffv1dec.c
> > > > > @@ -92,7 +92,7 @@ static int is_input_end(RangeCoder *c,
> > > > > GetBitContext *gb, int ac)
> > > > >    static int decode_plane(FFV1Context *f, FFV1SliceContext *sc,
> > > > >    GetBitContext *gb,
> > > > >    uint8_t *src, int w, int h, int
> > > > > stride, int plane_index,
> > > > > -    int pixel_stride, int ac)
> > > > > +    int remap_index, int pixel_stride, int ac)
> > > > >    {
> > > > >    int x, y;
> > > > >    int16_t *sample[2];
> > > > > @@ -116,12 +116,18 @@ static int decode_plane(FFV1Context
> > > > > *f, FFV1SliceContext *sc,
> > > > >    int ret = decode_line(f, sc, gb, w, sample,
> > > > > plane_index, 8, ac);
> > > > >    if (ret < 0)
> > > > >    return ret;
> > > > > +    if (sc->remap)
> > > > > +    for (x = 0; x < w; x++)
> > > > > +    sample[1][x] = sc->fltmap[remap_index]
> > > > > [sample[1][x]];
> > > > >    for (x = 0; x < w; x++)
> > > > >    src[x*pixel_stride + stride * y] = sample[1][x];
> > > > >    } else {
> > > > >    int ret = decode_line(f, sc, gb, w, sample,
> > > > > plane_index, f->avctx->bits_per_raw_sample, ac);
> > > > >    if (ret < 0)
> > > > >    return ret;
> > > > > +    if (sc->remap)
> > > > > +    for (x = 0; x < w; x++)
> > > > > +    sample[1][x] = sc->fltmap[remap_index]
> > > > > [sample[1][x]];
> > > > >    if (f->packed_at_lsb) {
> > > > >    for (x = 0; x < w; x++) {
> > > > >    ((uint16_t*)(src +
> > > > > stride*y))[x*pixel_stride] = sample[1][x];
> > > > > @@ -347,17 +353,17 @@ static int decode_slice(AVCodecContext
> > > > > *c, void *arg)
> > > > >    if (f->colorspace == 0 && (f->chroma_planes || !f-
> > > > > >transparency)) {
> > > > >    const int cx    = x >> f->chroma_h_shift;
> > > > >    const int cy    = y >> f->chroma_v_shift;
> > > > > -    decode_plane(f, sc, &gb, p->data[0] + ps*x + y*p-
> > > > > >linesize[0], width, height, p->linesize[0], 0, 1, ac);
> > > > > +    decode_plane(f, sc, &gb, p->data[0] + ps*x + y*p-
> > > > > >linesize[0], width, height, p->linesize[0], 0, 0, 1, ac);
> > > > >    if (f->chroma_planes) {
> > > > > -    decode_plane(f, sc, &gb, p->data[1] +
> > > > > ps*cx+cy*p- >linesize[1], chroma_width, chroma_height,
> > > > > p->linesize[1], 1, 1, ac);
> > > > > -    decode_plane(f, sc, &gb, p->data[2] +
> > > > > ps*cx+cy*p- >linesize[2], chroma_width, chroma_height,
> > > > > p->linesize[2], 1, 1, ac);
> > > > > +    decode_plane(f, sc, &gb, p->data[1] +
> > > > > ps*cx+cy*p- >linesize[1], chroma_width, chroma_height,
> > > > > p->linesize[1], 1, 1, 1, ac);
> > > > > +    decode_plane(f, sc, &gb, p->data[2] +
> > > > > ps*cx+cy*p- >linesize[2], chroma_width, chroma_height,
> > > > > p->linesize[2], 1, 2, 1, ac);
> > > > >    }
> > > > >    if (f->transparency)
> > > > > -    decode_plane(f, sc, &gb, p->data[3] + ps*x +
> > > > > y*p- >linesize[3], width, height, p->linesize[3],
> > > > > (f->version >= 4 && !f- >chroma_planes) ? 1 : 2, 1, ac);
> > > > > +    decode_plane(f, sc, &gb, p->data[3] + ps*x +
> > > > > y*p- >linesize[3], width, height, p->linesize[3],
> > > > > (f->version >= 4 && !f- >chroma_planes) ? 1 : 2, 2, 1, ac);
> > > > >    } else if (f->colorspace == 0) {
> > > > > - decode_plane(f, sc, &gb, p->data[0] + ps*x + y*p-
> > > > > >linesize[0]    , width, height, p->linesize[0], 0, 2, ac);
> > > > > - decode_plane(f, sc, &gb, p->data[0] + ps*x + y*p-
> > > > > >linesize[0] + 1, width, height, p->linesize[0], 1, 2, ac);
> > > > > + decode_plane(f, sc, &gb, p->data[0] + ps*x + y*p-
> > > > > >linesize[0]    , width, height, p->linesize[0], 0, 0, 2,
> > > > > ac);
> > > > > + decode_plane(f, sc, &gb, p->data[0] + ps*x + y*p-
> > > > > >linesize[0] + 1, width, height, p->linesize[0], 1, 1, 2,
> > > > > ac);
> > > > >  

Re: [FFmpeg-devel] [PATCH 1/7] avcodec/pcm: Remove always-false check

[Andreas Rheinhardt]

Ramiro Polla:
> 
> On 3/13/25 06:49, Andreas Rheinhardt wrote:
>> Patches attached.
> 
> 
> [PATCH 2/7] avcodec/pcm: Cache sample_size value
> 
>> diff --git a/libavcodec/pcm.c b/libavcodec/pcm.c
>> index 5d8dcb8ff0..620acf0f46 100644
>> --- a/libavcodec/pcm.c
>> +++ b/libavcodec/pcm.c
>> @@ -328,17 +335,14 @@ static int pcm_decode_frame(AVCodecContext
>> *avctx, AVFrame *frame,
>>  int buf_size   = avpkt->size;
>>  PCMDecode *s   = avctx->priv_data;
>>  int channels   = avctx->ch_layout.nb_channels;
>> -    int sample_size, c, n, ret, samples_per_block;
>> +    int sample_size = s->sample_size, c, n, ret, samples_per_block;
>>  uint8_t *samples;
>>  int32_t *dst_int32_t;
> 
> Could you put sample_size on its own line? It gets a little confusing
> with the first variable being initialized, but the subsequent variables
> being uninitialized.
> 

Sure.

> 
> [PATCH 3/7] avcodec/pcm: Remove duplication from FFCodec define macros
> 
>> diff --git a/libavcodec/pcm.c b/libavcodec/pcm.c
>> index 620acf0f46..6c1feecca3 100644
>> --- a/libavcodec/pcm.c
>> +++ b/libavcodec/pcm.c
> [...]
>> +//   AV_CODEC_ID_*   pcm_* name
>> +// AV_SAMPLE_FMT_*   long name
>> +PCM_CODEC  (ALAW, S16, alaw, "PCM A-law / G.711 A-law");
>> +PCM_DECODER(F16LE,    FLT, f16le,    "PCM 16.8 floating point
>> little-endian");
> 
> The labels don't align with the fields.

I actually made it so that the field is below the middle of the label.
You prefer the following I presume:
//AV_CODEC_ID_*pcm_* name
//  AV_SAMPLE_FMT_*  long name
PCM_CODEC  (ALAW, S16, alaw, "PCM A-law / G.711 A-law");

> 
> And in the next patch ([PATCH 4/7] avcodec/pcm: Don't allocate LUT when
> unused), with the introduction of PCM_CODEC_EXT(), the alignment of
> PCM_CODEC/PCM_DECODER/PCM_CODEC_EXT is lost.
> 

Only for a few codecs and only for the first field. Is this really so
important? I'd consider it worse if there were "PCM_CODEC(" instead
of "PCM_CODEC  (" everywhere else. (Of course, this point were moot if
you had an idea for macro name shorter than PCM_CODEC_EXT.)

- Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".