date:20241015

[FFmpeg-devel] [RFC] AVFilter

2024-10-15 Thread Michael Niedermayer

Hi all

This is a quick RFC about peoples oppinions on AVFilter

The question: Should anyone be able to write a filter (which
other people can use) ?
Or should only we be able to add filters ?

(This relates to what parts of the API are publically accessable)

So whats the point of this RFC ?

If we want a public API that allows writing filters then work on the API
has to be compatible with that direction.

"compatible" for example would be, "Adding whats missing to the public API"
or "deprecating existing API and writing a better API that makes all needed
parts public"

"incompatible" for example is "making bits and pieces private that are needed
by filters

Some of the currently pending patches seem to fall into the "incompatible"
category, while iam not sure what peoples oppinions is on the direction
of AVfilter, which is why iam bringing this up

Thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is a danger to trust the dream we wish for rather than
the science we have, -- Dr. Kenneth Brown


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] hw_base_encode: Free pictures on close

2024-10-15 Thread David Rosca

Fixes leaking recon surfaces with VAAPI.
---
 libavcodec/hw_base_encode.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
index 7b6ec97d3b..912c707a68 100644
--- a/libavcodec/hw_base_encode.c
+++ b/libavcodec/hw_base_encode.c
@@ -804,6 +804,11 @@ int ff_hw_base_encode_init(AVCodecContext *avctx, 
FFHWBaseEncodeContext *ctx)
 
 int ff_hw_base_encode_close(FFHWBaseEncodeContext *ctx)
 {
+FFHWBaseEncodePicture *pic;
+
+for (pic = ctx->pic_start; pic; pic = pic->next)
+base_encode_pic_free(pic);
+
 av_fifo_freep2(&ctx->encode_fifo);
 
 av_frame_free(&ctx->frame);
-- 
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".

Re: [FFmpeg-devel] [PATCH 1/4] lavu/pixfmt: add AV_PIX_FMT_RGBA128

2024-10-15 Thread Lynne via ffmpeg-devel


On 15/10/2024 03:50, James Almer wrote:

On 10/14/2024 10:41 PM, Lynne via ffmpeg-devel wrote:

On 14/10/2024 17:24, James Almer wrote:

On 10/14/2024 12:11 PM, Lynne via ffmpeg-devel wrote:

On 12/10/2024 01:01, Lynne wrote:

This format is useful for doing certain lossless transforms on images,
RCT in particular, which require you to escalate the size from 16 to
32 bits to avoid overflows.

APIchanges will be done alongside when comitting.
---
  libavutil/pixdesc.c | 27 +++
  libavutil/pixfmt.h  |  5 +
  2 files changed, 32 insertions(+)

diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 43b9c08e14..8736e4f47d 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -2803,6 +2803,33 @@ static const AVPixFmtDescriptor 
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {

  .flags = AV_PIX_FMT_FLAG_RGB | AV_PIX_FMT_FLAG_FLOAT |
   AV_PIX_FMT_FLAG_ALPHA,
  },
+    [AV_PIX_FMT_RGBA128BE] = {
+    .name = "rgba128be",
+    .nb_components = 4,
+    .log2_chroma_w = 0,
+    .log2_chroma_h = 0,
+    .comp = {
+    { 0, 16,  0, 0, 32 },  /* R */
+    { 0, 16,  4, 0, 32 },  /* G */
+    { 0, 16,  8, 0, 32 },  /* B */
+    { 0, 16, 12, 0, 32 },  /* A */
+    },
+    .flags = AV_PIX_FMT_FLAG_BE | AV_PIX_FMT_FLAG_RGB |
+ AV_PIX_FMT_FLAG_ALPHA,
+    },
+    [AV_PIX_FMT_RGBA128LE] = {
+    .name = "rgba128le",
+    .nb_components = 4,
+    .log2_chroma_w = 0,
+    .log2_chroma_h = 0,
+    .comp = {
+    { 0, 16,  0, 0, 32 },  /* R */
+    { 0, 16,  4, 0, 32 },  /* G */
+    { 0, 16,  8, 0, 32 },  /* B */
+    { 0, 16, 12, 0, 32 },  /* A */
+    },
+    .flags = AV_PIX_FMT_FLAG_RGB | AV_PIX_FMT_FLAG_ALPHA,
+    },
  [AV_PIX_FMT_P212BE] = {
  .name = "p212be",
  .nb_components = 3,
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 3caa183ba0..f03e4d701d 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -448,6 +448,9 @@ enum AVPixelFormat {
  AV_PIX_FMT_V30XBE,  ///< packed VYUX 4:4:4 like XV30, 
32bpp, (msb)10V 10Y 10U 2X(lsb), big-endian
  AV_PIX_FMT_V30XLE,  ///< packed VYUX 4:4:4 like XV30, 
32bpp, (msb)10V 10Y 10U 2X(lsb), little-endian
+    AV_PIX_FMT_RGBA128BE,   ///< packed RGBA 32:32:32:32, 128bpp, 
RGBARGBA..., big-endian
+    AV_PIX_FMT_RGBA128LE,   ///< packed RGBA 32:32:32:32, 128bpp, 
RGBARGBA..., little-endian

+
  AV_PIX_FMT_NB ///< number of pixel formats, DO NOT 
USE THIS if you want to link with shared libav* because the number 
of formats might differ between versions

  };
@@ -558,6 +561,8 @@ enum AVPixelFormat {
  #define AV_PIX_FMT_RGBF32 AV_PIX_FMT_NE(RGBF32BE, RGBF32LE)
  #define AV_PIX_FMT_RGBAF32    AV_PIX_FMT_NE(RGBAF32BE, RGBAF32LE)
+#define AV_PIX_FMT_RGBA128    AV_PIX_FMT_NE(RGBA128BE, RGBA128LE)
+
  /**
    * Chromaticity coordinates of the source primaries.
    * These values match the ones defined by ISO/IEC 23091-2_2019 
subclause 8.1 and ITU-T H.273.


Planning to push this patchset tomorrow unless there are comments.


Support for these in swscale will require considerable changes 
afaics, since they'd be the first non-float formats that use more 
than 16 bits per component.


I'm hoping that the rewrite/sws v2 will make this simpler.
For now, do you have issues with this landing?


Not really. If they are useful without sws support then it's fine.


Thanks. Pushed with APIchanges and fate-sws/imgutils bits.



OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital 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] hw_base_encode: Free pictures on close

2024-10-15 Thread Lynne via ffmpeg-devel


On 15/10/2024 16:49, David Rosca wrote:

Fixes leaking recon surfaces with VAAPI.
---
  libavcodec/hw_base_encode.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
index 7b6ec97d3b..912c707a68 100644
--- a/libavcodec/hw_base_encode.c
+++ b/libavcodec/hw_base_encode.c
@@ -804,6 +804,11 @@ int ff_hw_base_encode_init(AVCodecContext *avctx, 
FFHWBaseEncodeContext *ctx)
  
  int ff_hw_base_encode_close(FFHWBaseEncodeContext *ctx)

  {
+FFHWBaseEncodePicture *pic;
+
+for (pic = ctx->pic_start; pic; pic = pic->next)
+base_encode_pic_free(pic);
+
  av_fifo_freep2(&ctx->encode_fifo);
  
  av_frame_free(&ctx->frame);


I've noticed this happening with Vulkan as well.

LGTM, I'll push this after testing it in a few hours


OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital 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 3/4] fftools/opt_common: stop accessing a private field

2024-10-15 Thread James Almer


On 10/15/2024 6:57 AM, Anton Khirnov wrote:

Quoting James Almer (2024-10-14 22:48:12)

On 10/14/2024 1:27 PM, Alexander Strasser via ffmpeg-devel wrote:

On 2024-10-14 17:52 +0200, Michael Niedermayer wrote:

On Mon, Oct 14, 2024 at 01:36:46PM +0200, Anton Khirnov wrote:

---
   fftools/opt_common.c | 4 +---
   1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/fftools/opt_common.c b/fftools/opt_common.c
index 021ed75272..34da2cee7d 100644
--- a/fftools/opt_common.c
+++ b/fftools/opt_common.c
@@ -808,7 +808,6 @@ int show_filters(void *optctx, const char *opt, const char 
*arg)
   printf("Filters:\n"
  "  T.. = Timeline support\n"
  "  .S. = Slice threading\n"
-   "  ..C = Command support\n"
  "  A = Audio input/output\n"
  "  V = Video input/output\n"
  "  N = Dynamic number and/or type of input/output\n"
@@ -833,10 +832,9 @@ int show_filters(void *optctx, const char *opt, const char 
*arg)
 ( i && (filter->flags & 
AVFILTER_FLAG_DYNAMIC_OUTPUTS))) ? 'N' : '|';
   }
   *descr_cur = 0;
-printf(" %c%c%c %-17s %-10s %s\n",
+printf(" %c%c %-17s %-10s %s\n",
  filter->flags & AVFILTER_FLAG_SUPPORT_TIMELINE ? 'T' : '.',
  filter->flags & AVFILTER_FLAG_SLICE_THREADS? 'S' : '.',
-   filter->process_command? 'C' : '.',
  filter->name, descr, filter->description);
   }
   #else


The commit message is not describing this change accurately

Its not just "not accessing a priavte field", it removes information
from the printed filter list


Learning question: How can we see this is a private field?

This information was useful. How can we bring it back if we decide it's
not OK too test if this field is NULL?


A new flag AVFILTER_FLAG_SUPPORT_COMMANDS that the user can check to
ensure a call to avfilter_process_command() will not return ENOSYS could
be added. And of course, to print the C in here.


avfilter_process_command() may or may not return ENOSYS whether that
flag is set or not, so I don't see what exactly would it be useful for.


I see, although I wouldn't expect ENOSYS for any other case than 
"unsupported". If a command fails, imo it would be EINVAL, or maybe ENOMEM.



Same holds for printing the capability in fftools - just what is the
user expected to do with that information?


Know they can use the send command interrupt for a given filter without 
having it unconditionally fail, i guess. But for that matter, is the 
list of supported commands available anywhere for the user? Is there an 
API to query them, or is it expected to be only in the documentation?

If there's no API, then maybe printing this is pointless.



OpenPGP_signature.asc
Description: OpenPGP digital 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 3/4] fftools/opt_common: stop accessing a private field

2024-10-15 Thread Anton Khirnov

Quoting James Almer (2024-10-15 14:54:08)
> On 10/15/2024 6:57 AM, Anton Khirnov wrote:
> > avfilter_process_command() may or may not return ENOSYS whether that
> > flag is set or not, so I don't see what exactly would it be useful for.
> 
> I see, although I wouldn't expect ENOSYS for any other case than 
> "unsupported". If a command fails, imo it would be EINVAL, or maybe ENOMEM.

Correct, but
* some commands work on all filters; for now it's just "ping", but we
  can add more in the future;
* the "enable" command works on all filters flagged with
  AVFILTER_FLAG_SUPPORT_TIMELINE; again, we may add more such
  "semi-generic" commands in the future;
* filters that do implement the process_command() callback will still
  return ENOSYS when you send them a command they do not support.

So checking for the existence of process_command() does not really tell
you anything specific, and the same would hold for the hypothetical flag
that would replace it.

> 
> > Same holds for printing the capability in fftools - just what is the
> > user expected to do with that information?
> 
> Know they can use the send command interrupt for a given filter without 
> having it unconditionally fail, i guess. But for that matter, is the 
> list of supported commands available anywhere for the user? Is there an 
> API to query them, or is it expected to be only in the documentation?
> If there's no API, then maybe printing this is pointless.

There is no such API, which I agree would be useful - but if it did
exist we would again not need the flag.

-- 
Anton Khirnov
___
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 3/4] fftools/opt_common: stop accessing a private field

2024-10-15 Thread Alexander Strasser via ffmpeg-devel

On 2024-10-15 10:37 +0200, epira...@gmail.com wrote:
>
>
> On 15 Oct 2024, at 10:30, Anton Khirnov wrote:
>
> > Quoting Alexander Strasser via ffmpeg-devel (2024-10-15 07:34:26)
> >> On 2024-10-14 22:35 +0200, Anton Khirnov wrote:
> >>> Quoting Alexander Strasser via ffmpeg-devel (2024-10-14 22:21:38)
> > It is documented in the header.
> 
>  I figured as much but couldn't find a hint in in avfilter.h
> 
>  You changed it in a previous patch of this series or am I reading it 
>  wrong?
> >>>
> >>> I don't follow, I changed what?
> >>
> >> No, I don't mean you did sth.
> >>
> >> I'm just too stupid to read where in avfilter.h it is documented
> >> to be private.
> >>
> >> So I'm asking what is written where that indicates this.
> >
> > Here:
> > http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/avfilter.h;h=b88b31a834094f15d3159b017438499f1809b82f;hb=HEAD#l247
> >
> > Of course experience shows that such warnings do not really work, as
> > users ignore or fail to notice them.
>
> Yes because approaches like „everything below this line“
> falls apart horribly in Doxygen as it is completely lost there.
>
> Same for IntelliSense-like things in editors.

Thanks Anton for pointing to the exact line.

Now it all makes sense.

I was looking at the header and the AVFilter struct multiple times.

First at the beginning of the struct, then searching and later out
of paranoia paging up and down.

The thing is, I didn't expect nor see that comment as it was just
somewhere in between and looking like documentation of some other
field.

Then I went to the HTML rendered by Doxygen and like epirat07 pointed
out, of course couldn't find any hint either...

> > Which is why we have been switching
> > to an approach that outright removes private information from public
> > headers, but that first requires to eliminate its use.

Sure, I agree to that direction.

Still that functionality is useful and while it can be improved I
would hope for a solution that doesn't drop the feature now and
hopes for it to comeback at some later point.

  Alexander
___
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 3/4] fftools/opt_common: stop accessing a private field

2024-10-15 Thread Alexander Strasser via ffmpeg-devel

On 2024-10-15 15:09 +0200, Anton Khirnov wrote:
> Quoting James Almer (2024-10-15 14:54:08)
> > On 10/15/2024 6:57 AM, Anton Khirnov wrote:
> > > avfilter_process_command() may or may not return ENOSYS whether that
> > > flag is set or not, so I don't see what exactly would it be useful for.
> >
> > I see, although I wouldn't expect ENOSYS for any other case than
> > "unsupported". If a command fails, imo it would be EINVAL, or maybe ENOMEM.
>
> Correct, but
> * some commands work on all filters; for now it's just "ping", but we
>   can add more in the future;
> * the "enable" command works on all filters flagged with
>   AVFILTER_FLAG_SUPPORT_TIMELINE; again, we may add more such
>   "semi-generic" commands in the future;
> * filters that do implement the process_command() callback will still
>   return ENOSYS when you send them a command they do not support.
>
> So checking for the existence of process_command() does not really tell
> you anything specific, and the same would hold for the hypothetical flag
> that would replace it.
>
> >
> > > Same holds for printing the capability in fftools - just what is the
> > > user expected to do with that information?
> >
> > Know they can use the send command interrupt for a given filter without
> > having it unconditionally fail, i guess. But for that matter, is the
> > list of supported commands available anywhere for the user? Is there an
> > API to query them, or is it expected to be only in the documentation?
> > If there's no API, then maybe printing this is pointless.
>
> There is no such API, which I agree would be useful - but if it did
> exist we would again not need the flag.

For me that flag is more about if some filter brings commands of its own.

Generic stuff that we will add should not be indicated with the C flag.
Though adding more flags for the generic stuff like we have with T now
should be fine for some time to come before it gets unwieldy.

Listing and querying of filter caps has much room for improvement, but
as long as no one has particular interest in doing that,  at least I
don't see it as very important right now.


  Alexander
___
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 3/4] fftools/opt_common: stop accessing a private field

2024-10-15 Thread Anton Khirnov

Quoting Alexander Strasser via ffmpeg-devel (2024-10-15 21:05:54)
> Still that functionality is useful

How is it useful? It gives you no actionable information.

-- 
Anton Khirnov
___
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/vf_subtitles: Respect YCbCr Matrix header

2024-10-15 Thread Ridley Combs via ffmpeg-devel



> On Oct 13, 2024, at 05:45, arch1t3cht  wrote:
> 
> As specified in libass's ass_types.h, the colors or ASS_Images
> should be converted to YCbCr using the matrix/range specified in
> the track's YCbCrMatrix field (unless that field is set to YCBCR_NONE,
> and defaulting to TV.601 if the header is missing).
> 
> This does not affect any subtitles generated or transcoded by ffmpeg,
> since these contain a 'YCbCrMatrix: None' header.
> 
> Signed-off-by: arch1t3cht 
> ---
> libavfilter/vf_subtitles.c | 38 +-
> 1 file changed, 37 insertions(+), 1 deletion(-)
> 
> diff --git a/libavfilter/vf_subtitles.c b/libavfilter/vf_subtitles.c
> index de1cfa7d9e..ed1d12ca76 100644
> --- a/libavfilter/vf_subtitles.c
> +++ b/libavfilter/vf_subtitles.c
> @@ -88,6 +88,40 @@ static const int ass_libavfilter_log_level_map[] = {
> [7] = AV_LOG_DEBUG, /* MSGL_DBG2 */
> };
> 
> +static enum AVColorSpace ass_get_color_space(ASS_YCbCrMatrix ass_matrix, 
> enum AVColorSpace inlink_space) {
> +switch (ass_matrix) {
> +case YCBCR_NONE:return inlink_space;
> +case YCBCR_SMPTE240M_TV:
> +case YCBCR_SMPTE240M_PC:return AVCOL_SPC_SMPTE240M;
> +case YCBCR_FCC_TV:
> +case YCBCR_FCC_PC:  return AVCOL_SPC_FCC;
> +case YCBCR_BT709_TV:
> +case YCBCR_BT709_PC:return AVCOL_SPC_BT709;
> +case YCBCR_BT601_TV:
> +case YCBCR_BT601_PC:
> +case YCBCR_DEFAULT:
> +case YCBCR_UNKNOWN:
> +default:return AVCOL_SPC_SMPTE170M;
> +}
> +}
> +
> +static enum AVColorRange ass_get_color_range(ASS_YCbCrMatrix ass_matrix, 
> enum AVColorRange inlink_range) {
> +switch (ass_matrix) {
> +case YCBCR_NONE:return inlink_range;
> +case YCBCR_SMPTE240M_PC:
> +case YCBCR_FCC_PC:
> +case YCBCR_BT709_PC:
> +case YCBCR_BT601_PC:return AVCOL_RANGE_JPEG;
> +case YCBCR_SMPTE240M_TV:
> +case YCBCR_FCC_TV:
> +case YCBCR_BT709_TV:
> +case YCBCR_BT601_TV:
> +case YCBCR_DEFAULT:
> +case YCBCR_UNKNOWN:
> +default:return AVCOL_RANGE_MPEG;
> +}
> +}
> +
> static void ass_log(int ass_level, const char *fmt, va_list args, void *ctx)
> {
> const int ass_level_clip = av_clip(ass_level, 0,
> @@ -147,7 +181,9 @@ static int config_input(AVFilterLink *inlink)
> {
> AssContext *ass = inlink->dst->priv;
> 
> -ff_draw_init2(&ass->draw, inlink->format, inlink->colorspace, 
> inlink->color_range,
> +ff_draw_init2(&ass->draw, inlink->format,
> +  ass_get_color_space(ass->track->YCbCrMatrix, 
> inlink->colorspace),
> +  ass_get_color_range(ass->track->YCbCrMatrix, 
> inlink->color_range),
>   ass->alpha ? FF_DRAW_PROCESS_ALPHA : 0);
> 
> ass_set_frame_size  (ass->renderer, inlink->w, inlink->h);
> -- 
> 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".

LGTM; will push on Friday if nobody objects.

___
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 3/4] fftools/opt_common: stop accessing a private field

2024-10-15 Thread epirat07



On 15 Oct 2024, at 10:30, Anton Khirnov wrote:

> Quoting Alexander Strasser via ffmpeg-devel (2024-10-15 07:34:26)
>> On 2024-10-14 22:35 +0200, Anton Khirnov wrote:
>>> Quoting Alexander Strasser via ffmpeg-devel (2024-10-14 22:21:38)
> It is documented in the header.

 I figured as much but couldn't find a hint in in avfilter.h

 You changed it in a previous patch of this series or am I reading it wrong?
>>>
>>> I don't follow, I changed what?
>>
>> No, I don't mean you did sth.
>>
>> I'm just too stupid to read where in avfilter.h it is documented
>> to be private.
>>
>> So I'm asking what is written where that indicates this.
>
> Here:
> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/avfilter.h;h=b88b31a834094f15d3159b017438499f1809b82f;hb=HEAD#l247
>
> Of course experience shows that such warnings do not really work, as
> users ignore or fail to notice them.

Yes because approaches like „everything below this line“
falls apart horribly in Doxygen as it is completely lost there.

Same for IntelliSense-like things in editors.

> Which is why we have been switching
> to an approach that outright removes private information from public
> headers, but that first requires to eliminate its use.
>
> -- 
> Anton Khirnov
> ___
> 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] doc/APIchanges: add missing entry for adding RGBF16

2024-10-15 Thread Anton Khirnov

Quoting Martin Schitter (2024-10-15 03:18:19)
> The missing APIchanges entry requested by A.Khirnov.
> 
> Martin
> 
> ---
>  doc/APIchanges | 3 +++
>  1 file changed, 3 insertions(+)

Pushed, thanks
-- 
Anton Khirnov
___
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 1/1] avfilter/framesync: fix forward EOF pts

2024-10-15 Thread Anton Khirnov

Quoting Dennis Mungai (2024-10-13 14:14:06)
> On Sun, Oct 13, 2024, 15:09 Anton Khirnov  wrote:
> 
> > Pushed.
> >
> > Thanks and sorry it took so long,
> > --
> > Anton Khirnov
> >
> 
> 
> Does this affect the release point versions, say FFmpeg/7.1? If so, is a
> backport to the release point(s) required?

Backported to 7.1

-- 
Anton Khirnov
___
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/bsf/dovi_rpu: remove EL when stripping dovi metadata

2024-10-15 Thread gnattu via ffmpeg-devel

When RPU is removed EL should also be removed. This only applies to
HEVC as AV1 based Profile 10 does not support EL at all.

Signed-off-by: Gnattu OC 
---
 libavcodec/bsf/dovi_rpu.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/bsf/dovi_rpu.c b/libavcodec/bsf/dovi_rpu.c
index ae04d16360f..b4f80588e99 100644
--- a/libavcodec/bsf/dovi_rpu.c
+++ b/libavcodec/bsf/dovi_rpu.c
@@ -84,7 +84,8 @@ static int dovi_rpu_update_fragment_hevc(AVBSFContext *bsf, 
AVPacket *pkt,
 uint8_t *rpu = NULL;
 int rpu_size, ret;
 
-if (!nal || nal->type != HEVC_NAL_UNSPEC62)
+// HEVC_NAL_UNSPEC62 is Dolby Vision PRU and HEVC_NAL_UNSPEC63 is Dolby 
Vision EL
+if (!nal || (nal->type != HEVC_NAL_UNSPEC62 && nal->type != 
HEVC_NAL_UNSPEC63))
 return 0;
 
 if (s->strip) {
@@ -92,6 +93,10 @@ static int dovi_rpu_update_fragment_hevc(AVBSFContext *bsf, 
AVPacket *pkt,
 return 0;
 }
 
+if (nal->type == HEVC_NAL_UNSPEC63) {
+return 0;
+}
+
 ret = update_rpu(bsf, pkt, 0, nal->data + 2, nal->data_size - 2, &rpu, 
&rpu_size);
 if (ret < 0)
 return ret;
-- 
2.39.5 (Apple Git-154)

___
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] [Uncompressed MP4] RFC - Draft Encoder

2024-10-15 Thread Devon Sookhoo

This updated patch registers the 'uncv' tag in the isom_tags.c
ff_codec_movvideo_tags[] list. However, I still need to specify the tag
with the "-tag:v uncv" option. I hoped this change would set 'uncv' as the
default tag for raw mp4 video, but I'm not sure what the issue is.

I'm also looking into passing FATE and adding additional test cases to
cover this new code. The documentation is helpful, but there's still a
steep learning curve to get all this put together.

Any help would be greatly appreciated.

On Sat, Oct 12, 2024 at 1:59 AM Tomas Härdin  wrote:

> ons 2024-10-09 klockan 20:08 -0600 skrev Devon Sookhoo:
> > Sounds good, I'll look into adding rawvideo to the list of
> > movcodec_tags.
> >
> > Looking at the AVPixFmtDescriptor, I noticed: AVComponentDescriptor
> > comp[4]; Does this line limit the component count to only four?
> > Encoding
> > video with many components is an important use case.
>
> I am aware of no pixel format with more than 4 components so probably.
> I've never seen hyperspectral imagery used in this project. I've worked
> with it before though
>
> > Complex pixels are used in applications that involve both amplitude
> > and
> > phase information, particularly in signal processing and imaging
> > techniques
> > where the Fourier transform is frequently applied. Examples include
> > Synthetic Aperture Radar (SAR), MRI scans, and radio astronomy.
>
> Yep, suspected as much
>
> /Tomas
> ___
> 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".
>
From c5211cba38f3ec4d64c6c07304a2d947d033ca82 Mon Sep 17 00:00:00 2001
From: dukesook 
Date: Tue, 24 Sep 2024 12:27:31 -0600
Subject: [PATCH] Encode RGB interleaved 8 bit uncompressed mp4

---
 libavcodec/rawenc.c | 18 +
 libavformat/isom_tags.c |  1 +
 libavformat/movenc.c| 88 +
 3 files changed, 107 insertions(+)

diff --git a/libavcodec/rawenc.c b/libavcodec/rawenc.c
index 8c577006d9..abb4a46886 100644
--- a/libavcodec/rawenc.c
+++ b/libavcodec/rawenc.c
@@ -77,6 +77,24 @@ static int raw_encode(AVCodecContext *avctx, AVPacket *pkt,
 AV_WB64(&pkt->data[8 * x], v << 48 | v >> 16);
 }
 }
+else if (avctx->codec_tag == AV_RL32("uncv") && ret > 0 &&
+frame->format == AV_PIX_FMT_RGB24) {
+int x, y;
+uint8_t *dst = pkt->data;
+uint8_t *src = frame->data[0];
+
+for (y = 0; y < frame->height; y++) {
+for (x = 0; x < frame->width; x++) {
+dst[0] = src[0];  // Red component
+dst[1] = src[1];  // Green component
+dst[2] = src[2];  // Blue component
+src += 3;
+dst += 3;
+}
+src += frame->linesize[0] - frame->width * 3;
+}
+}
+
 *got_packet = 1;
 return 0;
 }
diff --git a/libavformat/isom_tags.c b/libavformat/isom_tags.c
index 5dd72d570e..ffdb412ee6 100644
--- a/libavformat/isom_tags.c
+++ b/libavformat/isom_tags.c
@@ -29,6 +29,7 @@
 const AVCodecTag ff_codec_movvideo_tags[] = {
 /*  { AV_CODEC_ID_, MKTAG('I', 'V', '5', '0') }, *//* Indeo 5.0 */
 
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('u', 'n', 'c', 'v') },
 { AV_CODEC_ID_RAWVIDEO, MKTAG('r', 'a', 'w', ' ') }, /* uncompressed RGB */
 { AV_CODEC_ID_RAWVIDEO, MKTAG('y', 'u', 'v', '2') }, /* uncompressed YUV422 */
 { AV_CODEC_ID_RAWVIDEO, MKTAG('2', 'v', 'u', 'y') }, /* uncompressed 8-bit 4:2:2 */
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index d20e45cf81..1e85b06b64 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -2602,6 +2602,90 @@ static int mov_write_aux_tag(AVIOContext *pb, const char *aux_type)
 return update_size(pb, pos);
 }
 
+static int mov_write_uncC_component(AVIOContext *pb, uint16_t index, uint8_t bit_depth, uint8_t format, uint8_t align_size) {
+avio_wb16(pb, index);
+avio_w8(pb, bit_depth-1);
+avio_w8(pb, format); // 0 = unsigned integer. 1 = floating point. 2 = complex
+avio_w8(pb, align_size);
+return 0;
+}
+
+static int mov_write_uncC_tag(AVFormatContext *s, AVIOContext *pb, MOVMuxContext *mov, MOVTrack *track) {
+int64_t pos = avio_tell(pb);
+uint8_t version = 0x0;
+const AVPixFmtDescriptor *pixdesc = av_pix_fmt_desc_get(s->streams[0]->codecpar->format);
+const uint32_t nb_components = (uint32_t) pixdesc->nb_components;
+uint8_t bit_depth = 8; // TODO: Read correct bit depth
+   // track->par->bits_per_coded_sample;
+   // track->par->bits_per_raw_sample;
+
+avio_wb32(pb, 0); /* size */
+ffio_wfourcc(pb, "uncC");
+
+avio_w8(pb, 0x00);   // Flags
+avio_wb24(pb, 0x00); // Version
+
+avio_wb32(pb, 0x); // profile
+
+if (version == 1) {
+
+}
+else if

[FFmpeg-devel] [PATCH 21/21] lavfi/vsrc_perlin: convert to query_func2()

2024-10-15 Thread Anton Khirnov

---
 libavfilter/vsrc_perlin.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vsrc_perlin.c b/libavfilter/vsrc_perlin.c
index f736d2b97c..9f6f000da5 100644
--- a/libavfilter/vsrc_perlin.c
+++ b/libavfilter/vsrc_perlin.c
@@ -142,11 +142,13 @@ static int request_frame(AVFilterLink *outlink)
 return ff_filter_frame(outlink, picref);
 }
 
-static int query_formats(AVFilterContext *ctx)
+static int query_formats(const AVFilterContext *ctx,
+ AVFilterFormatsConfig **cfg_in,
+ AVFilterFormatsConfig **cfg_out)
 {
 enum AVPixelFormat pix_fmts[] = { AV_PIX_FMT_GRAY8, AV_PIX_FMT_NONE };
 
-return ff_set_common_formats_from_list(ctx, pix_fmts);
+return ff_set_common_formats_from_list2(ctx, cfg_in, cfg_out, pix_fmts);
 }
 
 static const AVFilterPad perlin_outputs[] = {
@@ -166,5 +168,5 @@ const AVFilter ff_vsrc_perlin = {
 .init  = init,
 .inputs= NULL,
 FILTER_OUTPUTS(perlin_outputs),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 };
-- 
2.43.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 17/21] lavfi/vf_weave: convert to query_func2()

2024-10-15 Thread Anton Khirnov

---
 libavfilter/vf_weave.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/libavfilter/vf_weave.c b/libavfilter/vf_weave.c
index 598779d1cf..9595865320 100644
--- a/libavfilter/vf_weave.c
+++ b/libavfilter/vf_weave.c
@@ -52,11 +52,14 @@ static const AVOption weave_options[] = {
 
 AVFILTER_DEFINE_CLASS_EXT(weave, "(double)weave", weave_options);
 
-static int query_formats(AVFilterContext *ctx)
+static int query_formats(const AVFilterContext *ctx,
+ AVFilterFormatsConfig **cfg_in,
+ AVFilterFormatsConfig **cfg_out)
 {
 int reject_flags = AV_PIX_FMT_FLAG_PAL | AV_PIX_FMT_FLAG_HWACCEL;
 
-return ff_set_common_formats(ctx, ff_formats_pixdesc_filter(0, 
reject_flags));
+return ff_set_common_formats2(ctx, cfg_in, cfg_out,
+  ff_formats_pixdesc_filter(0, reject_flags));
 }
 
 static int config_props_output(AVFilterLink *outlink)
@@ -209,7 +212,7 @@ const AVFilter ff_vf_weave = {
 .uninit= uninit,
 FILTER_INPUTS(weave_inputs),
 FILTER_OUTPUTS(weave_outputs),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 .flags = AVFILTER_FLAG_SLICE_THREADS,
 };
 
@@ -232,6 +235,6 @@ const AVFilter ff_vf_doubleweave = {
 .uninit= uninit,
 FILTER_INPUTS(weave_inputs),
 FILTER_OUTPUTS(weave_outputs),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 .flags = AVFILTER_FLAG_SLICE_THREADS,
 };
-- 
2.43.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 15/21] lavfi/vf_vmafmotion: convert to query_func2()

2024-10-15 Thread Anton Khirnov

---
 libavfilter/vf_vmafmotion.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_vmafmotion.c b/libavfilter/vf_vmafmotion.c
index a8adc67019..7c18473a3c 100644
--- a/libavfilter/vf_vmafmotion.c
+++ b/libavfilter/vf_vmafmotion.c
@@ -263,7 +263,9 @@ int ff_vmafmotion_init(VMAFMotionData *s,
 return 0;
 }
 
-static int query_formats(AVFilterContext *ctx)
+static int query_formats(const AVFilterContext *ctx,
+ AVFilterFormatsConfig **cfg_in,
+ AVFilterFormatsConfig **cfg_out)
 {
 AVFilterFormats *fmts_list = NULL;
 int format, ret;
@@ -278,7 +280,7 @@ static int query_formats(AVFilterContext *ctx)
 return ret;
 }
 
-return ff_set_common_formats(ctx, fmts_list);
+return ff_set_common_formats2(ctx, cfg_in, cfg_out, fmts_list);
 }
 
 static int config_input_ref(AVFilterLink *inlink)
@@ -359,5 +361,5 @@ const AVFilter ff_vf_vmafmotion = {
 .flags = AVFILTER_FLAG_METADATA_ONLY,
 FILTER_INPUTS(vmafmotion_inputs),
 FILTER_OUTPUTS(ff_video_default_filterpad),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 };
-- 
2.43.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 14/21] lavfi/vf_v360: convert to query_func2()

2024-10-15 Thread Anton Khirnov

---
 libavfilter/vf_v360.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/libavfilter/vf_v360.c b/libavfilter/vf_v360.c
index 12e40205ba..04dc03bee7 100644
--- a/libavfilter/vf_v360.c
+++ b/libavfilter/vf_v360.c
@@ -172,9 +172,11 @@ static const AVOption v360_options[] = {
 
 AVFILTER_DEFINE_CLASS(v360);
 
-static int query_formats(AVFilterContext *ctx)
+static int query_formats(const AVFilterContext *ctx,
+ AVFilterFormatsConfig **cfg_in,
+ AVFilterFormatsConfig **cfg_out)
 {
-V360Context *s = ctx->priv;
+const V360Context *s = ctx->priv;
 static const enum AVPixelFormat pix_fmts[] = {
 // YUVA444
 AV_PIX_FMT_YUVA444P,   AV_PIX_FMT_YUVA444P9,
@@ -250,7 +252,8 @@ static int query_formats(AVFilterContext *ctx)
 AV_PIX_FMT_NONE
 };
 
-return ff_set_common_formats_from_list(ctx, s->alpha ? alpha_pix_fmts : 
pix_fmts);
+return ff_set_common_formats_from_list2(ctx, cfg_in, cfg_out,
+s->alpha ? alpha_pix_fmts : 
pix_fmts);
 }
 
 #define DEFINE_REMAP1_LINE(bits, div)  
  \
@@ -5000,7 +5003,7 @@ const AVFilter ff_vf_v360 = {
 .uninit= uninit,
 FILTER_INPUTS(inputs),
 FILTER_OUTPUTS(outputs),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 .priv_class= &v360_class,
 .flags = AVFILTER_FLAG_SLICE_THREADS,
 .process_command = process_command,
-- 
2.43.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 03/21] lavfi/vf_shuffleplanes: convert to query_func2()

2024-10-15 Thread Anton Khirnov

---
 libavfilter/vf_shuffleplanes.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/libavfilter/vf_shuffleplanes.c b/libavfilter/vf_shuffleplanes.c
index c9cbd472ef..7bfa4fe782 100644
--- a/libavfilter/vf_shuffleplanes.c
+++ b/libavfilter/vf_shuffleplanes.c
@@ -41,10 +41,12 @@ typedef struct ShufflePlanesContext {
 int copy;
 } ShufflePlanesContext;
 
-static int query_formats(AVFilterContext *ctx)
+static int query_formats(const AVFilterContext *ctx,
+ AVFilterFormatsConfig **cfg_in,
+ AVFilterFormatsConfig **cfg_out)
 {
 AVFilterFormats *formats = NULL;
-ShufflePlanesContext *s = ctx->priv;
+const ShufflePlanesContext *s = ctx->priv;
 int fmt, ret, i;
 
 for (fmt = 0; av_pix_fmt_desc_get(fmt); fmt++) {
@@ -70,7 +72,7 @@ static int query_formats(AVFilterContext *ctx)
 }
 }
 
-return ff_set_common_formats(ctx, formats);
+return ff_set_common_formats2(ctx, cfg_in, cfg_out, formats);
 }
 
 static av_cold int shuffleplanes_config_input(AVFilterLink *inlink)
@@ -161,6 +163,6 @@ const AVFilter ff_vf_shuffleplanes = {
 .priv_class   = &shuffleplanes_class,
 FILTER_INPUTS(shuffleplanes_inputs),
 FILTER_OUTPUTS(ff_video_default_filterpad),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 .flags= AVFILTER_FLAG_SUPPORT_TIMELINE_GENERIC,
 };
-- 
2.43.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 19/21] lavfi/vsrc_life: avoid modifying the context in query_formats()

2024-10-15 Thread Anton Khirnov

It is supposed to be free of side effects. Do it in init instead.
---
 libavfilter/vsrc_life.c | 125 
 1 file changed, 63 insertions(+), 62 deletions(-)

diff --git a/libavfilter/vsrc_life.c b/libavfilter/vsrc_life.c
index a624dbb63c..b5b4626e20 100644
--- a/libavfilter/vsrc_life.c
+++ b/libavfilter/vsrc_life.c
@@ -160,6 +160,58 @@ static void show_life_grid(AVFilterContext *ctx)
 }
 #endif
 
+static void fill_picture_monoblack(AVFilterContext *ctx, AVFrame *picref)
+{
+LifeContext *life = ctx->priv;
+uint8_t *buf = life->buf[life->buf_idx];
+int i, j, k;
+
+/* fill the output picture with the old grid buffer */
+for (i = 0; i < life->h; i++) {
+uint8_t byte = 0;
+uint8_t *p = picref->data[0] + i * picref->linesize[0];
+for (k = 0, j = 0; j < life->w; j++) {
+byte |= (buf[i*life->w+j] == ALIVE_CELL)<<(7-k++);
+if (k==8 || j == life->w-1) {
+k = 0;
+*p++ = byte;
+byte = 0;
+}
+}
+}
+}
+
+// divide by 255 and round to nearest
+// apply a fast variant: (X+127)/255 = ((X+127)*257+257)>>16 = 
((X+128)*257)>>16
+#define FAST_DIV255(x) x) + 128) * 257) >> 16)
+
+static void fill_picture_rgb(AVFilterContext *ctx, AVFrame *picref)
+{
+LifeContext *life = ctx->priv;
+uint8_t *buf = life->buf[life->buf_idx];
+int i, j;
+
+/* fill the output picture with the old grid buffer */
+for (i = 0; i < life->h; i++) {
+uint8_t *p = picref->data[0] + i * picref->linesize[0];
+for (j = 0; j < life->w; j++) {
+uint8_t v = buf[i*life->w + j];
+if (life->mold && v != ALIVE_CELL) {
+const uint8_t *c1 = life-> mold_color;
+const uint8_t *c2 = life->death_color;
+int death_age = FFMIN((0xff - v) * life->mold, 0xff);
+*p++ = FAST_DIV255((c2[0] << 8) + ((int)c1[0] - (int)c2[0]) * 
death_age);
+*p++ = FAST_DIV255((c2[1] << 8) + ((int)c1[1] - (int)c2[1]) * 
death_age);
+*p++ = FAST_DIV255((c2[2] << 8) + ((int)c1[2] - (int)c2[2]) * 
death_age);
+} else {
+const uint8_t *c = v == ALIVE_CELL ? life->life_color : 
life->death_color;
+AV_WB24(p, c[0]<<16 | c[1]<<8 | c[2]);
+p += 3;
+}
+}
+}
+}
+
 static int init_pattern_from_file(AVFilterContext *ctx)
 {
 LifeContext *life = ctx->priv;
@@ -259,6 +311,13 @@ static av_cold int init(AVFilterContext *ctx)
 return ret;
 }
 
+if (life->mold || memcmp(life-> life_color, "\xff\xff\xff", 3)
+   || memcmp(life->death_color, "\x00\x00\x00", 3)) {
+life->draw = fill_picture_rgb;
+} else {
+life->draw = fill_picture_monoblack;
+}
+
 av_log(ctx, AV_LOG_VERBOSE,
"s:%dx%d r:%d/%d rule:%s stay_rule:%d born_rule:%d stitch:%d 
seed:%"PRId64"\n",
life->w, life->h, life->frame_rate.num, life->frame_rate.den,
@@ -345,58 +404,6 @@ static void evolve(AVFilterContext *ctx)
 life->buf_idx = !life->buf_idx;
 }
 
-static void fill_picture_monoblack(AVFilterContext *ctx, AVFrame *picref)
-{
-LifeContext *life = ctx->priv;
-uint8_t *buf = life->buf[life->buf_idx];
-int i, j, k;
-
-/* fill the output picture with the old grid buffer */
-for (i = 0; i < life->h; i++) {
-uint8_t byte = 0;
-uint8_t *p = picref->data[0] + i * picref->linesize[0];
-for (k = 0, j = 0; j < life->w; j++) {
-byte |= (buf[i*life->w+j] == ALIVE_CELL)<<(7-k++);
-if (k==8 || j == life->w-1) {
-k = 0;
-*p++ = byte;
-byte = 0;
-}
-}
-}
-}
-
-// divide by 255 and round to nearest
-// apply a fast variant: (X+127)/255 = ((X+127)*257+257)>>16 = 
((X+128)*257)>>16
-#define FAST_DIV255(x) x) + 128) * 257) >> 16)
-
-static void fill_picture_rgb(AVFilterContext *ctx, AVFrame *picref)
-{
-LifeContext *life = ctx->priv;
-uint8_t *buf = life->buf[life->buf_idx];
-int i, j;
-
-/* fill the output picture with the old grid buffer */
-for (i = 0; i < life->h; i++) {
-uint8_t *p = picref->data[0] + i * picref->linesize[0];
-for (j = 0; j < life->w; j++) {
-uint8_t v = buf[i*life->w + j];
-if (life->mold && v != ALIVE_CELL) {
-const uint8_t *c1 = life-> mold_color;
-const uint8_t *c2 = life->death_color;
-int death_age = FFMIN((0xff - v) * life->mold, 0xff);
-*p++ = FAST_DIV255((c2[0] << 8) + ((int)c1[0] - (int)c2[0]) * 
death_age);
-*p++ = FAST_DIV255((c2[1] << 8) + ((int)c1[1] - (int)c2[1]) * 
death_age);
-*p++ = FAST_DIV255((c2[2] << 8) + ((int)c1[2] - (int)c2[2]) * 
death_age);
-} else {
-const uint8_t *c = v == ALIVE_CELL ? life->life

[FFmpeg-devel] [PATCH 20/21] lavfi/vsrc_life: convert to query_func2()

2024-10-15 Thread Anton Khirnov

---
 libavfilter/vsrc_life.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/libavfilter/vsrc_life.c b/libavfilter/vsrc_life.c
index b5b4626e20..5506e3bc90 100644
--- a/libavfilter/vsrc_life.c
+++ b/libavfilter/vsrc_life.c
@@ -422,15 +422,17 @@ static int request_frame(AVFilterLink *outlink)
 return ff_filter_frame(outlink, picref);
 }
 
-static int query_formats(AVFilterContext *ctx)
+static int query_formats(const AVFilterContext *ctx,
+ AVFilterFormatsConfig **cfg_in,
+ AVFilterFormatsConfig **cfg_out)
 {
-LifeContext *life = ctx->priv;
+const LifeContext *life = ctx->priv;
 const enum AVPixelFormat pix_fmts[] = {
 life->draw == fill_picture_rgb ? AV_PIX_FMT_RGB24 : 
AV_PIX_FMT_MONOBLACK,
 AV_PIX_FMT_NONE
 };
 
-return ff_set_common_formats_from_list(ctx, pix_fmts);
+return ff_set_common_formats_from_list2(ctx, cfg_in, cfg_out, pix_fmts);
 }
 
 static const AVFilterPad life_outputs[] = {
@@ -451,5 +453,5 @@ const AVFilter ff_vsrc_life = {
 .uninit= uninit,
 .inputs= NULL,
 FILTER_OUTPUTS(life_outputs),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 };
-- 
2.43.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 18/21] lavfi/vf_zscale: convert to query_func2()

2024-10-15 Thread Anton Khirnov

---
 libavfilter/vf_zscale.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index b0316f5bb8..4ba059064b 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -183,9 +183,11 @@ static av_cold int init(AVFilterContext *ctx)
 
 static enum AVColorRange convert_range_from_zimg(enum zimg_pixel_range_e 
color_range);
 
-static int query_formats(AVFilterContext *ctx)
+static int query_formats(const AVFilterContext *ctx,
+ AVFilterFormatsConfig **cfg_in,
+ AVFilterFormatsConfig **cfg_out)
 {
-ZScaleContext *s = ctx->priv;
+const ZScaleContext *s = ctx->priv;
 AVFilterFormats *formats;
 static const enum AVPixelFormat pixel_fmts[] = {
 AV_PIX_FMT_YUV410P, AV_PIX_FMT_YUV411P,
@@ -212,27 +214,27 @@ static int query_formats(AVFilterContext *ctx)
 };
 int ret;
 
-ret = ff_formats_ref(ff_make_format_list(pixel_fmts), 
&ctx->inputs[0]->outcfg.formats);
+ret = ff_formats_ref(ff_make_format_list(pixel_fmts), &cfg_in[0]->formats);
 if (ret < 0)
 return ret;
-ret = ff_formats_ref(ff_make_format_list(pixel_fmts), 
&ctx->outputs[0]->incfg.formats);
+ret = ff_formats_ref(ff_make_format_list(pixel_fmts), 
&cfg_out[0]->formats);
 if (ret < 0)
 return ret;
 
-if ((ret = ff_formats_ref(ff_all_color_spaces(), 
&ctx->inputs[0]->outcfg.color_spaces)) < 0 ||
-(ret = ff_formats_ref(ff_all_color_ranges(), 
&ctx->inputs[0]->outcfg.color_ranges)) < 0)
+if ((ret = ff_formats_ref(ff_all_color_spaces(), 
&cfg_in[0]->color_spaces)) < 0 ||
+(ret = ff_formats_ref(ff_all_color_ranges(), 
&cfg_in[0]->color_ranges)) < 0)
 return ret;
 
 formats = s->colorspace != ZIMG_MATRIX_UNSPECIFIED && s->colorspace > 0
 ? ff_make_formats_list_singleton(s->colorspace)
 : ff_all_color_spaces();
-if ((ret = ff_formats_ref(formats, &ctx->outputs[0]->incfg.color_spaces)) 
< 0)
+if ((ret = ff_formats_ref(formats, &cfg_out[0]->color_spaces)) < 0)
 return ret;
 
 formats = s->range != -1
 ? ff_make_formats_list_singleton(convert_range_from_zimg(s->range))
 : ff_all_color_ranges();
-if ((ret = ff_formats_ref(formats, &ctx->outputs[0]->incfg.color_ranges)) 
< 0)
+if ((ret = ff_formats_ref(formats, &cfg_out[0]->color_ranges)) < 0)
 return ret;
 
 return 0;
@@ -1133,7 +1135,7 @@ const AVFilter ff_vf_zscale = {
 .uninit  = uninit,
 FILTER_INPUTS(avfilter_vf_zscale_inputs),
 FILTER_OUTPUTS(avfilter_vf_zscale_outputs),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 .process_command = process_command,
 .flags   = AVFILTER_FLAG_SLICE_THREADS,
 };
-- 
2.43.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 07/21] lavfi/vf_swaprect: convert to query_func2()

2024-10-15 Thread Anton Khirnov

---
 libavfilter/vf_swaprect.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_swaprect.c b/libavfilter/vf_swaprect.c
index 71869cf53a..95214132d7 100644
--- a/libavfilter/vf_swaprect.c
+++ b/libavfilter/vf_swaprect.c
@@ -56,13 +56,16 @@ static const AVOption swaprect_options[] = {
 
 AVFILTER_DEFINE_CLASS(swaprect);
 
-static int query_formats(AVFilterContext *ctx)
+static int query_formats(const AVFilterContext *ctx,
+ AVFilterFormatsConfig **cfg_in,
+ AVFilterFormatsConfig **cfg_out)
 {
 int reject_flags = AV_PIX_FMT_FLAG_PAL |
AV_PIX_FMT_FLAG_HWACCEL |
AV_PIX_FMT_FLAG_BITSTREAM;
 
-return ff_set_common_formats(ctx, ff_formats_pixdesc_filter(0, 
reject_flags));
+return ff_set_common_formats2(ctx, cfg_in, cfg_out,
+  ff_formats_pixdesc_filter(0, reject_flags));
 }
 
 static const char *const var_names[] = {   "w",   "h",   "a",   "n",   "t",
@@ -251,7 +254,7 @@ const AVFilter ff_vf_swaprect = {
 .uninit= uninit,
 FILTER_INPUTS(inputs),
 FILTER_OUTPUTS(ff_video_default_filterpad),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 .flags = AVFILTER_FLAG_SUPPORT_TIMELINE_GENERIC,
 .process_command = ff_filter_process_command,
 };
-- 
2.43.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 16/21] lavfi/vf_vpp_qsv: convert to query_func2()

2024-10-15 Thread Anton Khirnov

---
 libavfilter/vf_vpp_qsv.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
index 7f05f1fab0..37d41aa44b 100644
--- a/libavfilter/vf_vpp_qsv.c
+++ b/libavfilter/vf_vpp_qsv.c
@@ -932,9 +932,11 @@ static const AVOption vpp_options[] = {
 { NULL }
 };
 
-static int vpp_query_formats(AVFilterContext *ctx)
+static int vpp_query_formats(const AVFilterContext *ctx,
+ AVFilterFormatsConfig **cfg_in,
+ AVFilterFormatsConfig **cfg_out)
 {
-VPPContext *vpp = ctx->priv;
+const VPPContext *vpp = ctx->priv;
 int ret, i = 0;
 static const enum AVPixelFormat in_pix_fmts[] = {
 AV_PIX_FMT_YUV420P,
@@ -951,7 +953,7 @@ static int vpp_query_formats(AVFilterContext *ctx)
 static enum AVPixelFormat out_pix_fmts[4];
 
 ret = ff_formats_ref(ff_make_format_list(in_pix_fmts),
- &ctx->inputs[0]->outcfg.formats);
+ &cfg_in[0]->formats);
 if (ret < 0)
 return ret;
 
@@ -968,10 +970,10 @@ static int vpp_query_formats(AVFilterContext *ctx)
 out_pix_fmts[i++] = AV_PIX_FMT_NONE;
 
 return ff_formats_ref(ff_make_format_list(out_pix_fmts),
-  &ctx->outputs[0]->incfg.formats);
+  &cfg_out[0]->formats);
 }
 
-DEFINE_QSV_FILTER(vpp, vpp, "VPP", FILTER_QUERY_FUNC(vpp_query_formats));
+DEFINE_QSV_FILTER(vpp, vpp, "VPP", FILTER_QUERY_FUNC2(vpp_query_formats));
 
 #endif
 
-- 
2.43.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 04/21] lavfi/vf_stack: convert to query_func2()

2024-10-15 Thread Anton Khirnov

---
 libavfilter/vf_stack.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/libavfilter/vf_stack.c b/libavfilter/vf_stack.c
index 8328048649..19c6c2971f 100644
--- a/libavfilter/vf_stack.c
+++ b/libavfilter/vf_stack.c
@@ -63,18 +63,22 @@ typedef struct StackContext {
 FFFrameSync fs;
 } StackContext;
 
-static int query_formats(AVFilterContext *ctx)
+static int query_formats(const AVFilterContext *ctx,
+ AVFilterFormatsConfig **cfg_in,
+ AVFilterFormatsConfig **cfg_out)
 {
-StackContext *s = ctx->priv;
+const StackContext *s = ctx->priv;
 int reject_flags = AV_PIX_FMT_FLAG_BITSTREAM |
AV_PIX_FMT_FLAG_HWACCEL   |
AV_PIX_FMT_FLAG_PAL;
 
 if (s->fillcolor_enable) {
-return ff_set_common_formats(ctx, ff_draw_supported_pixel_formats(0));
+return ff_set_common_formats2(ctx, cfg_in, cfg_out,
+  ff_draw_supported_pixel_formats(0));
 }
 
-return ff_set_common_formats(ctx, ff_formats_pixdesc_filter(0, 
reject_flags));
+return ff_set_common_formats2(ctx, cfg_in, cfg_out,
+  ff_formats_pixdesc_filter(0, reject_flags));
 }
 
 static av_cold int init(AVFilterContext *ctx)
@@ -462,7 +466,7 @@ const AVFilter ff_vf_hstack = {
 .priv_class= &stack_class,
 .priv_size = sizeof(StackContext),
 FILTER_OUTPUTS(outputs),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 .init  = init,
 .uninit= uninit,
 .activate  = activate,
@@ -479,7 +483,7 @@ const AVFilter ff_vf_vstack = {
 .priv_class= &stack_class,
 .priv_size = sizeof(StackContext),
 FILTER_OUTPUTS(outputs),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 .init  = init,
 .uninit= uninit,
 .activate  = activate,
@@ -507,7 +511,7 @@ const AVFilter ff_vf_xstack = {
 .priv_size = sizeof(StackContext),
 .priv_class= &xstack_class,
 FILTER_OUTPUTS(outputs),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 .init  = init,
 .uninit= uninit,
 .activate  = activate,
-- 
2.43.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 02/21] lavfi/vf_showpalette: convert to query_func2()

2024-10-15 Thread Anton Khirnov

---
 libavfilter/vf_showpalette.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/libavfilter/vf_showpalette.c b/libavfilter/vf_showpalette.c
index e887d07092..db1a224f04 100644
--- a/libavfilter/vf_showpalette.c
+++ b/libavfilter/vf_showpalette.c
@@ -41,17 +41,19 @@ static const AVOption showpalette_options[] = {
 
 AVFILTER_DEFINE_CLASS(showpalette);
 
-static int query_formats(AVFilterContext *ctx)
+static int query_formats(const AVFilterContext *ctx,
+ AVFilterFormatsConfig **cfg_in,
+ AVFilterFormatsConfig **cfg_out)
 {
 static const enum AVPixelFormat in_fmts[]  = {AV_PIX_FMT_PAL8,  
AV_PIX_FMT_NONE};
 static const enum AVPixelFormat out_fmts[] = {AV_PIX_FMT_RGB32, 
AV_PIX_FMT_NONE};
 int ret = ff_formats_ref(ff_make_format_list(in_fmts),
- &ctx->inputs[0]->outcfg.formats);
+ &cfg_in[0]->formats);
 if (ret < 0)
 return ret;
 
 return ff_formats_ref(ff_make_format_list(out_fmts),
-  &ctx->outputs[0]->incfg.formats);
+  &cfg_out[0]->formats);
 }
 
 static int config_output(AVFilterLink *outlink)
@@ -116,6 +118,6 @@ const AVFilter ff_vf_showpalette = {
 .priv_size = sizeof(ShowPaletteContext),
 FILTER_INPUTS(showpalette_inputs),
 FILTER_OUTPUTS(showpalette_outputs),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 .priv_class= &showpalette_class,
 };
-- 
2.43.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 13/21] lavfi/vf_untile: convert to query_func2()

2024-10-15 Thread Anton Khirnov

---
 libavfilter/vf_untile.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_untile.c b/libavfilter/vf_untile.c
index 486cce31ee..0feedc7a05 100644
--- a/libavfilter/vf_untile.c
+++ b/libavfilter/vf_untile.c
@@ -61,13 +61,16 @@ static av_cold int init(AVFilterContext *ctx)
 return 0;
 }
 
-static int query_formats(AVFilterContext *ctx)
+static int query_formats(const AVFilterContext *ctx,
+ AVFilterFormatsConfig **cfg_in,
+ AVFilterFormatsConfig **cfg_out)
 {
 int reject_flags = AV_PIX_FMT_FLAG_HWACCEL   |
AV_PIX_FMT_FLAG_BITSTREAM |
FF_PIX_FMT_FLAG_SW_FLAT_SUB;
 
-return ff_set_common_formats(ctx, ff_formats_pixdesc_filter(0, 
reject_flags));
+return ff_set_common_formats2(ctx, cfg_in, cfg_out,
+  ff_formats_pixdesc_filter(0, reject_flags));
 }
 
 static int config_output(AVFilterLink *outlink)
@@ -182,6 +185,6 @@ const AVFilter ff_vf_untile = {
 .priv_size = sizeof(UntileContext),
 FILTER_INPUTS(ff_video_default_filterpad),
 FILTER_OUTPUTS(untile_outputs),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 .priv_class= &untile_class,
 };
-- 
2.43.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 01/21] lavfi/vf_setparams: convert to query_func2()

2024-10-15 Thread Anton Khirnov

---
 libavfilter/vf_setparams.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/libavfilter/vf_setparams.c b/libavfilter/vf_setparams.c
index 14a16477c9..3943fd3c2d 100644
--- a/libavfilter/vf_setparams.c
+++ b/libavfilter/vf_setparams.c
@@ -136,22 +136,23 @@ static const AVOption setparams_options[] = {
 
 AVFILTER_DEFINE_CLASS(setparams);
 
-static int query_formats(AVFilterContext *ctx)
+static int query_formats(const AVFilterContext *ctx,
+ AVFilterFormatsConfig **cfg_in,
+ AVFilterFormatsConfig **cfg_out)
 {
-SetParamsContext *s = ctx->priv;
-AVFilterLink *outlink = ctx->outputs[0];
+const SetParamsContext *s = ctx->priv;
 int ret;
 
 if (s->colorspace >= 0) {
 ret = ff_formats_ref(ff_make_formats_list_singleton(s->colorspace),
- &outlink->incfg.color_spaces);
+ &cfg_out[0]->color_spaces);
 if (ret < 0)
 return ret;
 }
 
 if (s->color_range >= 0) {
 ret = ff_formats_ref(ff_make_formats_list_singleton(s->color_range),
- &outlink->incfg.color_ranges);
+ &cfg_out[0]->color_ranges);
 if (ret < 0)
 return ret;
 }
@@ -217,7 +218,7 @@ const AVFilter ff_vf_setparams = {
 .flags   = AVFILTER_FLAG_METADATA_ONLY,
 FILTER_INPUTS(inputs),
 FILTER_OUTPUTS(ff_video_default_filterpad),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 };
 
 #if CONFIG_SETRANGE_FILTER
@@ -258,7 +259,7 @@ const AVFilter ff_vf_setrange = {
 .flags   = AVFILTER_FLAG_METADATA_ONLY,
 FILTER_INPUTS(inputs),
 FILTER_OUTPUTS(ff_video_default_filterpad),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 };
 #endif /* CONFIG_SETRANGE_FILTER */
 
-- 
2.43.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 05/21] lavfi/vf_stereo3d: convert to query_func2()

2024-10-15 Thread Anton Khirnov

---
 libavfilter/vf_stereo3d.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/libavfilter/vf_stereo3d.c b/libavfilter/vf_stereo3d.c
index dc9cc33556..95e750d1c6 100644
--- a/libavfilter/vf_stereo3d.c
+++ b/libavfilter/vf_stereo3d.c
@@ -279,9 +279,11 @@ static const enum AVPixelFormat other_pix_fmts[] = {
 AV_PIX_FMT_NONE
 };
 
-static int query_formats(AVFilterContext *ctx)
+static int query_formats(const AVFilterContext *ctx,
+ AVFilterFormatsConfig **cfg_in,
+ AVFilterFormatsConfig **cfg_out)
 {
-Stereo3DContext *s = ctx->priv;
+const Stereo3DContext *s = ctx->priv;
 const enum AVPixelFormat *pix_fmts;
 
 switch (s->out.format) {
@@ -305,7 +307,7 @@ static int query_formats(AVFilterContext *ctx)
 pix_fmts = other_pix_fmts;
 }
 
-return ff_set_common_formats_from_list(ctx, pix_fmts);
+return ff_set_common_formats_from_list2(ctx, cfg_in, cfg_out, pix_fmts);
 }
 
 static inline uint8_t ana_convert(const int *coeff, const uint8_t *left, const 
uint8_t *right)
@@ -1116,7 +1118,7 @@ const AVFilter ff_vf_stereo3d = {
 .uninit= uninit,
 FILTER_INPUTS(stereo3d_inputs),
 FILTER_OUTPUTS(stereo3d_outputs),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 .priv_class= &stereo3d_class,
 .flags = AVFILTER_FLAG_SLICE_THREADS,
 };
-- 
2.43.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 10/21] lavfi/vf_tile: convert to query_func2()

2024-10-15 Thread Anton Khirnov

---
 libavfilter/vf_tile.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_tile.c b/libavfilter/vf_tile.c
index 2af97fee75..312a9826ae 100644
--- a/libavfilter/vf_tile.c
+++ b/libavfilter/vf_tile.c
@@ -111,9 +111,12 @@ static av_cold int init(AVFilterContext *ctx)
 return 0;
 }
 
-static int query_formats(AVFilterContext *ctx)
+static int query_formats(const AVFilterContext *ctx,
+ AVFilterFormatsConfig **cfg_in,
+ AVFilterFormatsConfig **cfg_out)
 {
-return ff_set_common_formats(ctx, ff_draw_supported_pixel_formats(0));
+return ff_set_common_formats2(ctx, cfg_in, cfg_out,
+  ff_draw_supported_pixel_formats(0));
 }
 
 static int config_props(AVFilterLink *outlink)
@@ -292,6 +295,6 @@ const AVFilter ff_vf_tile = {
 .priv_size = sizeof(TileContext),
 FILTER_INPUTS(tile_inputs),
 FILTER_OUTPUTS(tile_outputs),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 .priv_class= &tile_class,
 };
-- 
2.43.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 09/21] lavfi/vf_telecine: convert to query_func2()

2024-10-15 Thread Anton Khirnov

---
 libavfilter/vf_telecine.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_telecine.c b/libavfilter/vf_telecine.c
index 77f62f3e8c..107d379c66 100644
--- a/libavfilter/vf_telecine.c
+++ b/libavfilter/vf_telecine.c
@@ -99,13 +99,16 @@ static av_cold int init(AVFilterContext *ctx)
 return 0;
 }
 
-static int query_formats(AVFilterContext *ctx)
+static int query_formats(const AVFilterContext *ctx,
+ AVFilterFormatsConfig **cfg_in,
+ AVFilterFormatsConfig **cfg_out)
 {
 int reject_flags = AV_PIX_FMT_FLAG_BITSTREAM |
AV_PIX_FMT_FLAG_HWACCEL   |
AV_PIX_FMT_FLAG_PAL;
 
-return ff_set_common_formats(ctx, ff_formats_pixdesc_filter(0, 
reject_flags));
+return ff_set_common_formats2(ctx, cfg_in, cfg_out,
+  ff_formats_pixdesc_filter(0, reject_flags));
 }
 
 static int config_input(AVFilterLink *inlink)
@@ -326,5 +329,5 @@ const AVFilter ff_vf_telecine = {
 .uninit= uninit,
 FILTER_INPUTS(telecine_inputs),
 FILTER_OUTPUTS(telecine_outputs),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 };
-- 
2.43.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 08/21] lavfi/vf_swapuv: convert to query_func2()

2024-10-15 Thread Anton Khirnov

---
 libavfilter/vf_swapuv.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_swapuv.c b/libavfilter/vf_swapuv.c
index 5c7c69494e..866d0824f4 100644
--- a/libavfilter/vf_swapuv.c
+++ b/libavfilter/vf_swapuv.c
@@ -67,7 +67,9 @@ static int is_planar_yuv(const AVPixFmtDescriptor *desc)
 return 1;
 }
 
-static int query_formats(AVFilterContext *ctx)
+static int query_formats(const AVFilterContext *ctx,
+ AVFilterFormatsConfig **cfg_in,
+ AVFilterFormatsConfig **cfg_out)
 {
 AVFilterFormats *formats = NULL;
 int fmt, ret;
@@ -78,7 +80,7 @@ static int query_formats(AVFilterContext *ctx)
 return ret;
 }
 
-return ff_set_common_formats(ctx, formats);
+return ff_set_common_formats2(ctx, cfg_in, cfg_out, formats);
 }
 
 static const AVFilterPad swapuv_inputs[] = {
@@ -95,6 +97,6 @@ const AVFilter ff_vf_swapuv = {
 .description   = NULL_IF_CONFIG_SMALL("Swap U and V components."),
 FILTER_INPUTS(swapuv_inputs),
 FILTER_OUTPUTS(ff_video_default_filterpad),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 .flags = AVFILTER_FLAG_SUPPORT_TIMELINE_GENERIC,
 };
-- 
2.43.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 12/21] lavfi/vf_transpose: convert to query_func2()

2024-10-15 Thread Anton Khirnov

---
 libavfilter/vf_transpose.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_transpose.c b/libavfilter/vf_transpose.c
index d2836246b5..79e80cb000 100644
--- a/libavfilter/vf_transpose.c
+++ b/libavfilter/vf_transpose.c
@@ -52,7 +52,9 @@ typedef struct TransContext {
 TransVtable vtables[4];
 } TransContext;
 
-static int query_formats(AVFilterContext *ctx)
+static int query_formats(const AVFilterContext *ctx,
+ AVFilterFormatsConfig **cfg_in,
+ AVFilterFormatsConfig **cfg_out)
 {
 AVFilterFormats *pix_fmts = NULL;
 const AVPixFmtDescriptor *desc;
@@ -68,7 +70,7 @@ static int query_formats(AVFilterContext *ctx)
 }
 
 
-return ff_set_common_formats(ctx, pix_fmts);
+return ff_set_common_formats2(ctx, cfg_in, cfg_out, pix_fmts);
 }
 
 static inline void transpose_block_8_c(uint8_t *src, ptrdiff_t src_linesize,
@@ -412,6 +414,6 @@ const AVFilter ff_vf_transpose = {
 .priv_class= &transpose_class,
 FILTER_INPUTS(avfilter_vf_transpose_inputs),
 FILTER_OUTPUTS(avfilter_vf_transpose_outputs),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 .flags = AVFILTER_FLAG_SLICE_THREADS,
 };
-- 
2.43.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 06/21] lavfi/vf_subtitles: convert to query_func2()

2024-10-15 Thread Anton Khirnov

---
 libavfilter/vf_subtitles.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/libavfilter/vf_subtitles.c b/libavfilter/vf_subtitles.c
index de1cfa7d9e..d7f61d2f22 100644
--- a/libavfilter/vf_subtitles.c
+++ b/libavfilter/vf_subtitles.c
@@ -138,9 +138,12 @@ static av_cold void uninit(AVFilterContext *ctx)
 ass_library_done(ass->library);
 }
 
-static int query_formats(AVFilterContext *ctx)
+static int query_formats(const AVFilterContext *ctx,
+ AVFilterFormatsConfig **cfg_in,
+ AVFilterFormatsConfig **cfg_out)
 {
-return ff_set_common_formats(ctx, ff_draw_supported_pixel_formats(0));
+return ff_set_common_formats2(ctx, cfg_in, cfg_out,
+  ff_draw_supported_pixel_formats(0));
 }
 
 static int config_input(AVFilterLink *inlink)
@@ -255,7 +258,7 @@ const AVFilter ff_vf_ass = {
 .uninit= uninit,
 FILTER_INPUTS(ass_inputs),
 FILTER_OUTPUTS(ff_video_default_filterpad),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 .priv_class= &ass_class,
 };
 #endif
@@ -510,7 +513,7 @@ const AVFilter ff_vf_subtitles = {
 .uninit= uninit,
 FILTER_INPUTS(ass_inputs),
 FILTER_OUTPUTS(ff_video_default_filterpad),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 .priv_class= &subtitles_class,
 };
 #endif
-- 
2.43.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 11/21] lavfi/vf_tpad: convert to query_func2()

2024-10-15 Thread Anton Khirnov

---
 libavfilter/vf_tpad.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/libavfilter/vf_tpad.c b/libavfilter/vf_tpad.c
index 0b156772c8..73449147ea 100644
--- a/libavfilter/vf_tpad.c
+++ b/libavfilter/vf_tpad.c
@@ -76,13 +76,17 @@ static int needs_drawing(const TPadContext *s) {
 );
 }
 
-static int query_formats(AVFilterContext *ctx)
+static int query_formats(const AVFilterContext *ctx,
+ AVFilterFormatsConfig **cfg_in,
+ AVFilterFormatsConfig **cfg_out)
 {
-TPadContext *s = ctx->priv;
+const TPadContext *s = ctx->priv;
 if (needs_drawing(s))
-return ff_set_common_formats(ctx, ff_draw_supported_pixel_formats(0));
+return ff_set_common_formats2(ctx, cfg_in, cfg_out,
+  ff_draw_supported_pixel_formats(0));
 
-return ff_set_common_formats(ctx, ff_all_formats(AVMEDIA_TYPE_VIDEO));
+return ff_set_common_formats2(ctx, cfg_in, cfg_out,
+  ff_all_formats(AVMEDIA_TYPE_VIDEO));
 }
 
 static int activate(AVFilterContext *ctx)
@@ -240,5 +244,5 @@ const AVFilter ff_vf_tpad = {
 .uninit= uninit,
 FILTER_INPUTS(tpad_inputs),
 FILTER_OUTPUTS(ff_video_default_filterpad),
-FILTER_QUERY_FUNC(query_formats),
+FILTER_QUERY_FUNC2(query_formats),
 };
-- 
2.43.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".

Re: [FFmpeg-devel] [PATCH 3/4] fftools/opt_common: stop accessing a private field

2024-10-15 Thread Anton Khirnov

Quoting James Almer (2024-10-14 22:48:12)
> On 10/14/2024 1:27 PM, Alexander Strasser via ffmpeg-devel wrote:
> > On 2024-10-14 17:52 +0200, Michael Niedermayer wrote:
> >> On Mon, Oct 14, 2024 at 01:36:46PM +0200, Anton Khirnov wrote:
> >>> ---
> >>>   fftools/opt_common.c | 4 +---
> >>>   1 file changed, 1 insertion(+), 3 deletions(-)
> >>>
> >>> diff --git a/fftools/opt_common.c b/fftools/opt_common.c
> >>> index 021ed75272..34da2cee7d 100644
> >>> --- a/fftools/opt_common.c
> >>> +++ b/fftools/opt_common.c
> >>> @@ -808,7 +808,6 @@ int show_filters(void *optctx, const char *opt, const 
> >>> char *arg)
> >>>   printf("Filters:\n"
> >>>  "  T.. = Timeline support\n"
> >>>  "  .S. = Slice threading\n"
> >>> -   "  ..C = Command support\n"
> >>>  "  A = Audio input/output\n"
> >>>  "  V = Video input/output\n"
> >>>  "  N = Dynamic number and/or type of input/output\n"
> >>> @@ -833,10 +832,9 @@ int show_filters(void *optctx, const char *opt, 
> >>> const char *arg)
> >>> ( i && (filter->flags & 
> >>> AVFILTER_FLAG_DYNAMIC_OUTPUTS))) ? 'N' : '|';
> >>>   }
> >>>   *descr_cur = 0;
> >>> -printf(" %c%c%c %-17s %-10s %s\n",
> >>> +printf(" %c%c %-17s %-10s %s\n",
> >>>  filter->flags & AVFILTER_FLAG_SUPPORT_TIMELINE ? 'T' : 
> >>> '.',
> >>>  filter->flags & AVFILTER_FLAG_SLICE_THREADS? 'S' : 
> >>> '.',
> >>> -   filter->process_command? 'C' : 
> >>> '.',
> >>>  filter->name, descr, filter->description);
> >>>   }
> >>>   #else
> >>
> >> The commit message is not describing this change accurately
> >>
> >> Its not just "not accessing a priavte field", it removes information
> >> from the printed filter list
> > 
> > Learning question: How can we see this is a private field?
> > 
> > This information was useful. How can we bring it back if we decide it's
> > not OK too test if this field is NULL?
> 
> A new flag AVFILTER_FLAG_SUPPORT_COMMANDS that the user can check to 
> ensure a call to avfilter_process_command() will not return ENOSYS could 
> be added. And of course, to print the C in here.

avfilter_process_command() may or may not return ENOSYS whether that
flag is set or not, so I don't see what exactly would it be useful for.
Same holds for printing the capability in fftools - just what is the
user expected to do with that information?

-- 
Anton Khirnov
___
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] doc/ffmpeg: improve -disposition, -stats, and -progress documentation

2024-10-15 Thread Anton Khirnov

Quoting Soma Lucz (2024-10-13 15:18:49)
> ('-' prefixes between disposition flags have no effect in this case).

This is not entirely true, you could have +foo+bar-foo that evaluates to
bar.

Otherwise looks good to me.

-- 
Anton Khirnov
___
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 v6 1/2] configure, lavu, lavc, lavfi: Remove libva 1.x support

2024-10-15 Thread fei . w . wang-at-intel . com

From: Mark Thompson 

libva 2.0 was released in 2017 and the 2.x versions are included in all
supported distributions nowadays.  Various features no longer need any
configure check after this change, including all codecs except AV1.
Note that the libva version is the API version plus one, so this is
removing support for VAAPI 0.x and requiring VAAPI 1.x.

Signed-off-by: Fei Wang 
---
Fixes comments in v5:
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=12062

 configure  | 29 -
 libavcodec/vaapi_decode.c  | 39 ++---
 libavcodec/vaapi_encode.c  | 78 ++
 libavcodec/vaapi_encode.h  | 20 +
 libavcodec/vaapi_encode_h264.c | 21 -
 libavcodec/vaapi_encode_h265.c |  2 -
 libavfilter/vaapi_vpp.c| 22 --
 libavutil/hwcontext_vaapi.c| 22 --
 8 files changed, 42 insertions(+), 191 deletions(-)

diff --git a/configure b/configure
index 8803148ab7..39bb890b14 100755
--- a/configure
+++ b/configure
@@ -2636,7 +2636,6 @@ CONFIG_EXTRA="
 texturedsp
 texturedspenc
 tpeldsp
-vaapi_1
 vaapi_encode
 vc1dsp
 videodsp
@@ -3211,7 +3210,7 @@ hevc_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_HEVC"
 hevc_dxva2_hwaccel_select="hevc_decoder"
 hevc_nvdec_hwaccel_deps="nvdec"
 hevc_nvdec_hwaccel_select="hevc_decoder"
-hevc_vaapi_hwaccel_deps="vaapi VAPictureParameterBufferHEVC"
+hevc_vaapi_hwaccel_deps="vaapi"
 hevc_vaapi_hwaccel_select="hevc_decoder"
 hevc_vdpau_hwaccel_deps="vdpau VdpPictureInfoHEVC"
 hevc_vdpau_hwaccel_select="hevc_decoder"
@@ -3283,7 +3282,7 @@ vp9_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_VP9"
 vp9_dxva2_hwaccel_select="vp9_decoder"
 vp9_nvdec_hwaccel_deps="nvdec"
 vp9_nvdec_hwaccel_select="vp9_decoder"
-vp9_vaapi_hwaccel_deps="vaapi VADecPictureParameterBufferVP9_bit_depth"
+vp9_vaapi_hwaccel_deps="vaapi"
 vp9_vaapi_hwaccel_select="vp9_decoder"
 vp9_vdpau_hwaccel_deps="vdpau VdpPictureInfoVP9"
 vp9_vdpau_hwaccel_select="vp9_decoder"
@@ -3393,7 +3392,6 @@ hevc_qsv_decoder_select="hevc_mp4toannexb_bsf qsvdec"
 hevc_qsv_encoder_select="hevcparse qsvenc"
 hevc_rkmpp_decoder_deps="rkmpp"
 hevc_rkmpp_decoder_select="hevc_mp4toannexb_bsf"
-hevc_vaapi_encoder_deps="VAEncPictureParameterBufferHEVC"
 hevc_vaapi_encoder_select="atsc_a53 cbs_h265 vaapi_encode"
 hevc_vulkan_encoder_select="atsc_a53 cbs_h265 vulkan_encode"
 hevc_v4l2m2m_decoder_deps="v4l2_m2m hevc_v4l2_m2m"
@@ -3403,7 +3401,6 @@ mjpeg_cuvid_decoder_deps="cuvid"
 mjpeg_qsv_decoder_select="qsvdec"
 mjpeg_qsv_encoder_deps="libmfx"
 mjpeg_qsv_encoder_select="qsvenc"
-mjpeg_vaapi_encoder_deps="VAEncPictureParameterBufferJPEG"
 mjpeg_vaapi_encoder_select="cbs_jpeg jpegtables vaapi_encode"
 mp3_mf_encoder_deps="mediafoundation"
 mp3_mediacodec_decoder_deps="mediacodec"
@@ -3434,7 +3431,6 @@ vp8_mediacodec_decoder_deps="mediacodec"
 vp8_mediacodec_encoder_deps="mediacodec"
 vp8_qsv_decoder_select="qsvdec"
 vp8_rkmpp_decoder_deps="rkmpp"
-vp8_vaapi_encoder_deps="VAEncPictureParameterBufferVP8"
 vp8_vaapi_encoder_select="vaapi_encode"
 vp8_v4l2m2m_decoder_deps="v4l2_m2m vp8_v4l2_m2m"
 vp8_v4l2m2m_encoder_deps="v4l2_m2m vp8_v4l2_m2m"
@@ -3443,7 +3439,6 @@ vp9_mediacodec_decoder_deps="mediacodec"
 vp9_mediacodec_encoder_deps="mediacodec"
 vp9_qsv_decoder_select="qsvdec"
 vp9_rkmpp_decoder_deps="rkmpp"
-vp9_vaapi_encoder_deps="VAEncPictureParameterBufferVP9"
 vp9_vaapi_encoder_select="vaapi_encode"
 vp9_qsv_encoder_deps="libmfx MFX_CODEC_VP9"
 vp9_qsv_encoder_select="qsvenc"
@@ -3996,17 +3991,17 @@ xfade_vulkan_filter_deps="vulkan spirv_compiler"
 yadif_cuda_filter_deps="ffnvcodec"
 yadif_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
 yadif_videotoolbox_filter_deps="metal corevideo videotoolbox"
-hstack_vaapi_filter_deps="vaapi_1"
-vstack_vaapi_filter_deps="vaapi_1"
-xstack_vaapi_filter_deps="vaapi_1"
+hstack_vaapi_filter_deps="vaapi"
+vstack_vaapi_filter_deps="vaapi"
+xstack_vaapi_filter_deps="vaapi"
 hstack_qsv_filter_deps="libmfx"
 hstack_qsv_filter_select="qsvvpp"
 vstack_qsv_filter_deps="libmfx"
 vstack_qsv_filter_select="qsvvpp"
 xstack_qsv_filter_deps="libmfx"
 xstack_qsv_filter_select="qsvvpp"
-pad_vaapi_filter_deps="vaapi_1"
-drawbox_vaapi_filter_deps="vaapi_1"
+pad_vaapi_filter_deps="vaapi"
+drawbox_vaapi_filter_deps="vaapi VAProcPipelineCaps_blend_flags"
 
 # examples
 avio_http_serve_files_deps="avformat avutil fork"
@@ -7289,7 +7284,7 @@ enabled libdrm &&
 check_pkg_config libdrm_getfb2 libdrm "xf86drmMode.h" drmModeGetFB2
 
 enabled vaapi &&
-check_pkg_config vaapi "libva >= 0.35.0" "va/va.h" vaInitialize
+check_pkg_config vaapi "libva >= 1.0.0" "va/va.h" vaInitialize
 
 if enabled vaapi; then
 case $target_os in
@@ -7305,18 +7300,10 @@ if enabled vaapi; then
 check_pkg_config vaapi_x11 "libva-x11" "va/va_x11.h" vaGetDisplay
 fi
 
-check_cpp_condition vaapi_1 "va/va.h" "VA_CHECK_VERSION(1, 0, 0)"
-
-check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"

[FFmpeg-devel] [PATCH v6 2/2] hwcontext_vaapi: Deprecate quirks

2024-10-15 Thread fei . w . wang-at-intel . com

From: Mark Thompson 

These only apply to obsolete drivers which do not work with the
now-required libva 2.x.

Signed-off-by: Fei Wang 
---
 libavutil/hwcontext_vaapi.c | 123 ++--
 libavutil/hwcontext_vaapi.h |  17 +
 2 files changed, 52 insertions(+), 88 deletions(-)

diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index c1a67a36c7..d9e9f70445 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -243,8 +243,7 @@ static int vaapi_frames_get_constraints(AVHWDeviceContext 
*hwdev,
 unsigned int fourcc;
 int err, i, j, attr_count, pix_fmt_count;
 
-if (config &&
-!(hwctx->driver_quirks & AV_VAAPI_DRIVER_QUIRK_SURFACE_ATTRIBUTES)) {
+if (config) {
 attr_count = 0;
 vas = vaQuerySurfaceAttributes(hwctx->display, config->config_id,
0, &attr_count);
@@ -367,23 +366,6 @@ fail:
 return err;
 }
 
-static const struct {
-const char *friendly_name;
-const char *match_string;
-unsigned int quirks;
-} vaapi_driver_quirks_table[] = {
-{
-"Intel iHD",
-"ubit",
-AV_VAAPI_DRIVER_QUIRK_ATTRIB_MEMTYPE,
-},
-{
-"VDPAU wrapper",
-"Splitted-Desktop Systems VDPAU backend for VA-API",
-AV_VAAPI_DRIVER_QUIRK_SURFACE_ATTRIBUTES,
-},
-};
-
 static int vaapi_device_init(AVHWDeviceContext *hwdev)
 {
 VAAPIDeviceContext *ctx = hwdev->hwctx;
@@ -436,36 +418,6 @@ static int vaapi_device_init(AVHWDeviceContext *hwdev)
 if (vendor_string)
 av_log(hwdev, AV_LOG_VERBOSE, "VAAPI driver: %s.\n", vendor_string);
 
-if (hwctx->driver_quirks & AV_VAAPI_DRIVER_QUIRK_USER_SET) {
-av_log(hwdev, AV_LOG_VERBOSE, "Using quirks set by user (%#x).\n",
-   hwctx->driver_quirks);
-} else {
-// Detect the driver in use and set quirk flags if necessary.
-hwctx->driver_quirks = 0;
-if (vendor_string) {
-for (i = 0; i < FF_ARRAY_ELEMS(vaapi_driver_quirks_table); i++) {
-if (strstr(vendor_string,
-   vaapi_driver_quirks_table[i].match_string)) {
-av_log(hwdev, AV_LOG_VERBOSE, "Matched driver string "
-   "as known nonstandard driver \"%s\", setting "
-   "quirks (%#x).\n",
-   vaapi_driver_quirks_table[i].friendly_name,
-   vaapi_driver_quirks_table[i].quirks);
-hwctx->driver_quirks |=
-vaapi_driver_quirks_table[i].quirks;
-break;
-}
-}
-if (!(i < FF_ARRAY_ELEMS(vaapi_driver_quirks_table))) {
-av_log(hwdev, AV_LOG_VERBOSE, "Driver not found in known "
-   "nonstandard list, using standard behaviour.\n");
-}
-} else {
-av_log(hwdev, AV_LOG_VERBOSE, "Driver has no vendor string, "
-   "assuming standard behaviour.\n");
-}
-}
-
 av_free(image_list);
 return 0;
 fail:
@@ -562,48 +514,43 @@ static int vaapi_frames_init(AVHWFramesContext *hwfc)
 }
 
 if (!hwfc->pool) {
-if (!(hwctx->driver_quirks & 
AV_VAAPI_DRIVER_QUIRK_SURFACE_ATTRIBUTES)) {
-int need_memory_type = !(hwctx->driver_quirks & 
AV_VAAPI_DRIVER_QUIRK_ATTRIB_MEMTYPE);
-int need_pixel_format = 1;
-for (i = 0; i < avfc->nb_attributes; i++) {
-if (avfc->attributes[i].type == VASurfaceAttribMemoryType)
-need_memory_type  = 0;
-if (avfc->attributes[i].type == VASurfaceAttribPixelFormat)
-need_pixel_format = 0;
-}
-ctx->nb_attributes =
-avfc->nb_attributes + need_memory_type + need_pixel_format;
+int need_memory_type  = 1;
+int need_pixel_format = 1;
+for (i = 0; i < avfc->nb_attributes; i++) {
+if (avfc->attributes[i].type == VASurfaceAttribMemoryType)
+need_memory_type  = 0;
+if (avfc->attributes[i].type == VASurfaceAttribPixelFormat)
+need_pixel_format = 0;
+}
+ctx->nb_attributes =
+avfc->nb_attributes + need_memory_type + need_pixel_format;
 
-ctx->attributes = av_malloc(ctx->nb_attributes *
-sizeof(*ctx->attributes));
-if (!ctx->attributes) {
-err = AVERROR(ENOMEM);
-goto fail;
-}
+ctx->attributes = av_malloc(ctx->nb_attributes *
+sizeof(*ctx->attributes));
+if (!ctx->attributes) {
+err = AVERROR(ENOMEM);
+goto fail;
+}
 
-for (i = 0; i < avfc->nb_attributes; i++)
-ctx->attributes[i] = avfc->attributes[i];
-if (need_memory_type) {
-

Re: [FFmpeg-devel] [PATCH 3/4] fftools/opt_common: stop accessing a private field

2024-10-15 Thread Nicolas George

Anton Khirnov (12024-10-15):
> headers, but that first requires to eliminate its use.

Not an excuse to remove the feature it was used for at the same time,
especially without warning about it.

-- 
  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 3/4] fftools/opt_common: stop accessing a private field

2024-10-15 Thread Anton Khirnov

Quoting Alexander Strasser via ffmpeg-devel (2024-10-15 07:34:26)
> On 2024-10-14 22:35 +0200, Anton Khirnov wrote:
> > Quoting Alexander Strasser via ffmpeg-devel (2024-10-14 22:21:38)
> > > > It is documented in the header.
> > >
> > > I figured as much but couldn't find a hint in in avfilter.h
> > >
> > > You changed it in a previous patch of this series or am I reading it 
> > > wrong?
> >
> > I don't follow, I changed what?
> 
> No, I don't mean you did sth.
> 
> I'm just too stupid to read where in avfilter.h it is documented
> to be private.
> 
> So I'm asking what is written where that indicates this.

Here:
http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/avfilter.h;h=b88b31a834094f15d3159b017438499f1809b82f;hb=HEAD#l247

Of course experience shows that such warnings do not really work, as
users ignore or fail to notice them. Which is why we have been switching
to an approach that outright removes private information from public
headers, but that first requires to eliminate its use.

-- 
Anton Khirnov
___
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] [RFC] AVFilter

2024-10-15 Thread Devin Heitmueller

On Tue, Oct 15, 2024 at 12:12 PM Michael Niedermayer
 wrote:
>
> Hi all
>
> This is a quick RFC about peoples oppinions on AVFilter
>
> The question: Should anyone be able to write a filter (which
> other people can use) ?
> Or should only we be able to add filters ?

For what it's worth, I pretty much assumed that filters could only be
done in-tree, in particular after the avfilter_register() APIs were
removed a few years ago.

Personally I would really like to be able to maintain certain filters
in a separate git tree and be able to compile them against libavfilter
and add them in at runtime.  This isn't because of anything to do with
licensing (my entire ffmpeg tree is already public on github), but
simply these are filters which do stuff I strongly believe nobody else
would care about or wouldn't be accepted upstream for any number of
reasons.  Keeping my filters outside the main ffmpeg tree makes it
easier to rebase against newer versions of the ffmpeg libraries.

Now I realize this increases the maintenance burden in some cases, as
it means the APIs are public and hence there are issues with
maintaining backward compatibility.  And since I'm not the one who is
doing that work it wouldn't be appropriate for me to say, "it's worth
it".  But as a user of the libraries I will say it would indeed be
very nice if I could have out-of-tree filters.

Devin

-- 
Devin Heitmueller, Senior Software Engineer
LTN Global Communications
o: +1 (301) 363-1001
w: https://ltnglobal.com  e: devin.heitmuel...@ltnglobal.com
___
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] [RFC] AVFilter

2024-10-15 Thread Michael Niedermayer

On Tue, Oct 15, 2024 at 01:20:31PM -0300, James Almer wrote:
> On 10/15/2024 1:12 PM, Michael Niedermayer wrote:
> > Hi all
> > 
> > This is a quick RFC about peoples oppinions on AVFilter
> > 
> > The question: Should anyone be able to write a filter (which
> > other people can use) ?
> > Or should only we be able to add filters ?
> > 
> > (This relates to what parts of the API are publically accessable)
> > 
> > So whats the point of this RFC ?
> > 
> > If we want a public API that allows writing filters then work on the API
> > has to be compatible with that direction.
> > 
> > "compatible" for example would be, "Adding whats missing to the public API"
> > or "deprecating existing API and writing a better API that makes all needed
> > parts public"
> > 
> > "incompatible" for example is "making bits and pieces private that are 
> > needed
> > by filters
> > 
> > Some of the currently pending patches seem to fall into the "incompatible"

> No bits or fields are being made private in pending patches afaics.

[FFmpeg-devel] [PATCH 3/4] fftools/opt_common: stop accessing a private field

The only field this stops accessing is

-   filter->process_command? 'C' : '.',

but id say this is supposed to be a public field, its needed to be
accessed by filters.

(its also defined in the main public header, yes below a line that was added 
later
 saying its private so its not really public but also not really private)

I think before these fields are moved into a private header, it is a good idea
to disscuss, if the community wants "creating filters" to be possible though the
API (as it was originally intended) or to only allow for us and noone else to 
add
filters
(thats why i send that RFC, iam sorry if i worded something in a confusing way, 
i just
 think we need to discuss the direction before starting to march)

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- 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] [RFC] AVFilter

2024-10-15 Thread James Almer


On 10/15/2024 1:12 PM, Michael Niedermayer wrote:

Hi all

This is a quick RFC about peoples oppinions on AVFilter

The question: Should anyone be able to write a filter (which
other people can use) ?
Or should only we be able to add filters ?

(This relates to what parts of the API are publically accessable)

So whats the point of this RFC ?

If we want a public API that allows writing filters then work on the API
has to be compatible with that direction.

"compatible" for example would be, "Adding whats missing to the public API"
or "deprecating existing API and writing a better API that makes all needed
parts public"

"incompatible" for example is "making bits and pieces private that are needed
by filters

Some of the currently pending patches seem to fall into the "incompatible"

No bits or fields are being made private in pending patches afaics.



OpenPGP_signature.asc
Description: OpenPGP digital 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 v3] fate/png: add mDCv and cLLi read and write test

2024-10-15 Thread 金波

> -原始邮件-
> 发件人: "Leo Izen" 
> 发送时间:2024-07-16 10:23:51 (星期二)
> 收件人: ffmpeg-devel@ffmpeg.org
> 抄送: "Jan Ekström" , "Andreas Rheinhardt" 
> , "Leo Izen" 
> 主题: [FFmpeg-devel] [PATCH v3] fate/png: add mDCv and cLLi read and write test
> 
> This test confirms that we can write mDCv and cLLi chunks and read them
> back via the png decoder. It uses an HEVC conformance sample with this
> metadata as the base source for the side data in the frames.
> 
> Signed-off-by: Leo Izen 
> Reported-by: Jan Ekström 
> Reviewed-by: Jan Ekström 
> Reviewed-by: Andreas Rheinhardt 
> ---
>  tests/fate/image.mak|  6 ++
>  tests/ref/fate/png-mdcv | 22 ++
>  2 files changed, 28 insertions(+)
>  create mode 100644 tests/ref/fate/png-mdcv
> 
> diff --git a/tests/fate/image.mak b/tests/fate/image.mak
> index 753936ec20..042cf6438f 100644
> --- a/tests/fate/image.mak
> +++ b/tests/fate/image.mak
> @@ -416,6 +416,12 @@ FATE_PNG_PROBE-$(call ALLYES, LCMS2) += 
> fate-png-icc-parse
>  fate-png-icc-parse: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_frames \
>  -flags2 icc_profiles $(TARGET_SAMPLES)/png1/lena-int_rgb24.png
>  
> +FATE_PNG_TRANSCODE-$(call TRANSCODE, PNG HEVC, IMAGE2PIPE HEVC, \
> +IMAGE_PNG_PIPE_DEMUXER HEVC_PARSER PNG_DECODER SCALE_FILTER) += 
> fate-png-mdcv
> +fate-png-mdcv: CMD = transcode hevc 
> $(TARGET_SAMPLES)/hevc/hdr10_plus_h265_sample.hevc image2pipe \
> +"-pix_fmt rgb24 -vf scale -c png" "" \
> +"-show_frames -show_entries frame=side_data_list -of flat"
> +
>  FATE_PNG-$(call DEMDEC, IMAGE2, PNG) += $(FATE_PNG)
>  FATE_PNG_PROBE-$(call DEMDEC, IMAGE2, PNG) += $(FATE_PNG_PROBE)
>  FATE_IMAGE_FRAMECRC += $(FATE_PNG-yes)
> diff --git a/tests/ref/fate/png-mdcv b/tests/ref/fate/png-mdcv
> new file mode 100644
> index 00..c524a94ded
> --- /dev/null
> +++ b/tests/ref/fate/png-mdcv
> @@ -0,0 +1,22 @@
> +fc68fe6c8c72343b96d2695f6913995b *tests/data/fate/png-mdcv.image2pipe
> +439248 tests/data/fate/png-mdcv.image2pipe
> +#tb 0: 1/25
> +#media_type 0: video
> +#codec_id 0: rawvideo
> +#dimensions 0: 1280x720
> +#sar 0: 0/1
> +0,  0,  0,1,  2764800, 0x2bfc7b42
> +frames.frame.0.side_data_list.side_data.0.side_data_type="Content light 
> level metadata"
> +frames.frame.0.side_data_list.side_data.0.max_content=1000
> +frames.frame.0.side_data_list.side_data.0.max_average=200
> +frames.frame.0.side_data_list.side_data.1.side_data_type="Mastering display 
> metadata"
> +frames.frame.0.side_data_list.side_data.1.red_x="13250/5"
> +frames.frame.0.side_data_list.side_data.1.red_y="7500/5"
> +frames.frame.0.side_data_list.side_data.1.green_x="34000/5"
> +frames.frame.0.side_data_list.side_data.1.green_y="16000/5"
> +frames.frame.0.side_data_list.side_data.1.blue_x="2/5"
> +frames.frame.0.side_data_list.side_data.1.blue_y="0/5"
> +frames.frame.0.side_data_list.side_data.1.white_point_x="15635/5"
> +frames.frame.0.side_data_list.side_data.1.white_point_y="16450/5"
> +frames.frame.0.side_data_list.side_data.1.min_luminance="50/1"
> +frames.frame.0.side_data_list.side_data.1.max_luminance="1000/1"
> -- 
> 2.45.2

Hi，all：
fate fails sinc e30bc8a963eab1097bfb985351ca7eaf1f272ba6. I tested on Arm and 
X86, there existed, too. Or, maybe I missed something else ? I am not 
knowlegeable enough to fix this. Thx.

//error
+++ tests/data/fate/png-mdcv2024-10-16 14:35:19.264696951 +0800
@@ -1,5 +1,5 @@
-4001769a41d37d567c4cc0c532e20b54 *tests/data/fate/png-mdcv.image2pipe
-2774225 tests/data/fate/png-mdcv.image2pipe
+b674209fd9cd8eff945a6bc1a4b306d3 *tests/data/fate/png-mdcv.image2pipe
+2774240 tests/data/fate/png-mdcv.image2pipe
 #tb 0: 1/25
 #media_type 0: video
 #codec_id 0: rawvideo
Test png-mdcv failed. Look at tests/data/fate/png-mdcv.err for details.



本邮件及其附件含有龙芯中科的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息。如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。
 
This email and its attachments contain confidential information from Loongson 
Technology , which is intended only for the person or entity whose address is 
listed above. Any use of the information contained herein in any way 
(including, but not limited to, total or partial disclosure, reproduction or 
dissemination) by persons other than the intended recipient(s) is prohibited. 
If you receive this email in error, please notify the sender by phone or email 
immediately and delete it. 


___
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/6] swscale/output: add AYUV64BE output support

2024-10-15 Thread James Almer

Signed-off-by: James Almer 
---
 libswscale/output.c  | 47 +++-
 libswscale/utils.c   |  2 +-
 tests/ref/fate/filter-pixdesc-ayuv64be   |  1 +
 tests/ref/fate/filter-pixfmts-copy   |  1 +
 tests/ref/fate/filter-pixfmts-crop   |  1 +
 tests/ref/fate/filter-pixfmts-field  |  1 +
 tests/ref/fate/filter-pixfmts-fieldorder |  1 +
 tests/ref/fate/filter-pixfmts-hflip  |  1 +
 tests/ref/fate/filter-pixfmts-il |  1 +
 tests/ref/fate/filter-pixfmts-null   |  1 +
 tests/ref/fate/filter-pixfmts-scale  |  1 +
 tests/ref/fate/filter-pixfmts-transpose  |  1 +
 tests/ref/fate/filter-pixfmts-vflip  |  1 +
 13 files changed, 49 insertions(+), 11 deletions(-)
 create mode 100644 tests/ref/fate/filter-pixdesc-ayuv64be

diff --git a/libswscale/output.c b/libswscale/output.c
index c46ac51099..6d61e886ee 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -2564,12 +2564,19 @@ yuv2ya8_X_c(SwsContext *c, const int16_t *lumFilter,
 }
 }
 
-static void
-yuv2ayuv64le_X_c(SwsContext *c, const int16_t *lumFilter,
- const int16_t **_lumSrc, int lumFilterSize,
- const int16_t *chrFilter, const int16_t **_chrUSrc,
- const int16_t **_chrVSrc, int chrFilterSize,
- const int16_t **_alpSrc, uint8_t *dest, int dstW, int y)
+#define output_pixels(pos, val) \
+if (is_be) { \
+AV_WB16(pos, val); \
+} else { \
+AV_WL16(pos, val); \
+}
+
+static av_always_inline void
+yuv2ayuv64_X_c(SwsContext *c, const int16_t *lumFilter,
+   const int16_t **_lumSrc, int lumFilterSize,
+   const int16_t *chrFilter, const int16_t **_chrUSrc,
+   const int16_t **_chrVSrc, int chrFilterSize,
+   const int16_t **_alpSrc, uint8_t *dest, int dstW, int y, int 
is_be)
 {
 const int32_t **lumSrc  = (const int32_t **) _lumSrc,
   **chrUSrc = (const int32_t **) _chrUSrc,
@@ -2606,13 +2613,30 @@ yuv2ayuv64le_X_c(SwsContext *c, const int16_t 
*lumFilter,
 V = 0x8000 + av_clip_int16(V >> 15);
 A = 0x8000 + av_clip_int16(A >> 15);
 
-AV_WL16(dest + 8 * i, hasAlpha ? A : 65535);
-AV_WL16(dest + 8 * i + 2, Y);
-AV_WL16(dest + 8 * i + 4, U);
-AV_WL16(dest + 8 * i + 6, V);
+output_pixels(dest + 8 * i, hasAlpha ? A : 65535);
+output_pixels(dest + 8 * i + 2, Y);
+output_pixels(dest + 8 * i + 4, U);
+output_pixels(dest + 8 * i + 6, V);
 }
 }
 
+#undef output_pixels
+
+#define YUV2AYUV64(BE_LE, is_be) \
+static void \
+yuv2ayuv64 ## BE_LE ##_X_c(SwsContext *c, const int16_t *lumFilter, \
+   const int16_t **lumSrc, int lumFilterSize, \
+   const int16_t *chrFilter, const int16_t **chrUSrc, \
+   const int16_t **chrVSrc, int chrFilterSize, \
+   const int16_t **alpSrc, uint8_t *dest, int dstW, int y) \
+{ \
+yuv2ayuv64_X_c(c, lumFilter, lumSrc, lumFilterSize, \
+   chrFilter, chrUSrc, chrVSrc, chrFilterSize, \
+   alpSrc, dest, dstW, y, is_be); \
+}
+
+YUV2AYUV64(le, 0)
+YUV2AYUV64(be, 1)
 
 static av_always_inline void
 yuv2v30_X_c_template(SwsContext *c, const int16_t *lumFilter,
@@ -3597,6 +3621,9 @@ av_cold void ff_sws_init_output_funcs(SwsContext *c,
 case AV_PIX_FMT_AYUV64LE:
 *yuv2packedX = yuv2ayuv64le_X_c;
 break;
+case AV_PIX_FMT_AYUV64BE:
+*yuv2packedX = yuv2ayuv64be_X_c;
+break;
 case AV_PIX_FMT_AYUV:
 *yuv2packed1 = yuv2ayuv_1_c;
 *yuv2packed2 = yuv2ayuv_2_c;
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 09d96b2292..9b23df4dbb 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -231,7 +231,7 @@ static const FormatEntry format_entries[] = {
 [AV_PIX_FMT_XYZ12BE] = { 1, 1, 1 },
 [AV_PIX_FMT_XYZ12LE] = { 1, 1, 1 },
 [AV_PIX_FMT_AYUV64LE]= { 1, 1},
-[AV_PIX_FMT_AYUV64BE]= { 1, 0},
+[AV_PIX_FMT_AYUV64BE]= { 1, 1 },
 [AV_PIX_FMT_P010LE]  = { 1, 1 },
 [AV_PIX_FMT_P010BE]  = { 1, 1 },
 [AV_PIX_FMT_P012LE]  = { 1, 1 },
diff --git a/tests/ref/fate/filter-pixdesc-ayuv64be 
b/tests/ref/fate/filter-pixdesc-ayuv64be
new file mode 100644
index 00..2af583d670
--- /dev/null
+++ b/tests/ref/fate/filter-pixdesc-ayuv64be
@@ -0,0 +1 @@
+pixdesc-ayuv64bea4311bdc59c9b7a48d911647845d8214
diff --git a/tests/ref/fate/filter-pixfmts-copy 
b/tests/ref/fate/filter-pixfmts-copy
index 7e1259d182..c12dcd814e 100644
--- a/tests/ref/fate/filter-pixfmts-copy
+++ b/tests/ref/fate/filter-pixfmts-copy
@@ -3,6 +3,7 @@
 abgr023ecf6396d324edb113e4a483b79ba2
 argbf003b555ef429222005d33844cca9325
 ayuv631859cdc018cd9671482e435a87becc
+ayuv64be553477ffeeaf59d54fa12012ff13c783
 ayuv64le07b9c969dfbe4add4c0626773b151d4f
 bgr06fcd67c8e6cec723dab21c70c

[FFmpeg-devel] [PATCH 3/6] swscale/output: add X36VBE output support

2024-10-15 Thread James Almer

Signed-off-by: James Almer 
---
 libswscale/output.c  | 46 +++-
 libswscale/utils.c   |  2 +-
 tests/ref/fate/filter-pixdesc-xv36be |  1 +
 tests/ref/fate/filter-pixfmts-copy   |  1 +
 tests/ref/fate/filter-pixfmts-crop   |  1 +
 tests/ref/fate/filter-pixfmts-field  |  1 +
 tests/ref/fate/filter-pixfmts-fieldorder |  1 +
 tests/ref/fate/filter-pixfmts-hflip  |  1 +
 tests/ref/fate/filter-pixfmts-il |  1 +
 tests/ref/fate/filter-pixfmts-null   |  1 +
 tests/ref/fate/filter-pixfmts-scale  |  1 +
 tests/ref/fate/filter-pixfmts-transpose  |  1 +
 tests/ref/fate/filter-pixfmts-vflip  |  1 +
 13 files changed, 49 insertions(+), 10 deletions(-)
 create mode 100644 tests/ref/fate/filter-pixdesc-xv36be

diff --git a/libswscale/output.c b/libswscale/output.c
index 3b954e28a2..c46ac51099 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -2661,12 +2661,19 @@ static void yuv2 ## name ## _X_c(SwsContext *c, const 
int16_t *lumFilter, \
 V30LE_WRAPPER(xv30le, 0)
 V30LE_WRAPPER(v30xle, 2)
 
+#define output_pixels(pos, val, shift, bits, output_shift) \
+if (is_be) { \
+AV_WB16(pos, av_clip_uintp2(val >> shift, bits) << output_shift); \
+} else { \
+AV_WL16(pos, av_clip_uintp2(val >> shift, bits) << output_shift); \
+}
+
 static void
-yuv2xv36le_X_c(SwsContext *c, const int16_t *lumFilter,
-   const int16_t **lumSrc, int lumFilterSize,
-   const int16_t *chrFilter, const int16_t **chrUSrc,
-   const int16_t **chrVSrc, int chrFilterSize,
-   const int16_t **alpSrc, uint8_t *dest, int dstW, int y)
+yuv2xv36_X_c(SwsContext *c, const int16_t *lumFilter,
+ const int16_t **lumSrc, int lumFilterSize,
+ const int16_t *chrFilter, const int16_t **chrUSrc,
+ const int16_t **chrVSrc, int chrFilterSize,
+ const int16_t **alpSrc, uint8_t *dest, int dstW, int y, int is_be)
 {
 int i;
 for (i = 0; i < dstW; i++) {
@@ -2681,13 +2688,31 @@ yuv2xv36le_X_c(SwsContext *c, const int16_t *lumFilter,
 V += chrVSrc[j][i] * chrFilter[j];
 }
 
-AV_WL16(dest + 8 * i + 2, av_clip_uintp2(Y >> 15, 12) << 4);
-AV_WL16(dest + 8 * i + 0, av_clip_uintp2(U >> 15, 12) << 4);
-AV_WL16(dest + 8 * i + 4, av_clip_uintp2(V >> 15, 12) << 4);
-AV_WL16(dest + 8 * i + 6, A << 4);
+output_pixels(dest + 8 * i + 2, Y, 15, 12, 4)
+output_pixels(dest + 8 * i + 0, U, 15, 12, 4)
+output_pixels(dest + 8 * i + 4, V, 15, 12, 4)
+AV_WN16(dest + 8 * i + 6, A << 4);
 }
 }
 
+#undef output_pixels
+
+#define YUV2XV36(BE_LE, is_be) \
+static void \
+yuv2xv36 ## BE_LE ##_X_c(SwsContext *c, const int16_t *lumFilter, \
+ const int16_t **lumSrc, int lumFilterSize, \
+ const int16_t *chrFilter, const int16_t **chrUSrc, \
+ const int16_t **chrVSrc, int chrFilterSize, \
+ const int16_t **alpSrc, uint8_t *dest, int dstW, int 
y) \
+{ \
+yuv2xv36_X_c(c, lumFilter, lumSrc, lumFilterSize, \
+ chrFilter, chrUSrc, chrVSrc, chrFilterSize, \
+ alpSrc, dest, dstW, y, is_be); \
+}
+
+YUV2XV36(le, 0)
+YUV2XV36(be, 1)
+
 #define output_pixels(pos, A, Y, U, V) \
 if (target == AV_PIX_FMT_AYUV) { \
 dest[pos + 0] = A; \
@@ -3594,6 +3619,9 @@ av_cold void ff_sws_init_output_funcs(SwsContext *c,
 case AV_PIX_FMT_XV36LE:
 *yuv2packedX = yuv2xv36le_X_c;
 break;
+case AV_PIX_FMT_XV36BE:
+*yuv2packedX = yuv2xv36be_X_c;
+break;
 case AV_PIX_FMT_Y210LE:
 *yuv2packedX = yuv2y210le_X_c;
 break;
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 5b2ca8bf1d..227550451b 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -272,7 +272,7 @@ static const FormatEntry format_entries[] = {
 [AV_PIX_FMT_RGBF32LE]= { 1, 0 },
 [AV_PIX_FMT_XV30LE]  = { 1, 1 },
 [AV_PIX_FMT_XV36LE]  = { 1, 1 },
-[AV_PIX_FMT_XV36BE]  = { 1, 0 },
+[AV_PIX_FMT_XV36BE]  = { 1, 1 },
 [AV_PIX_FMT_AYUV]= { 1, 1 },
 [AV_PIX_FMT_UYVA]= { 1, 1 },
 [AV_PIX_FMT_VYU444]  = { 1, 1 },
diff --git a/tests/ref/fate/filter-pixdesc-xv36be 
b/tests/ref/fate/filter-pixdesc-xv36be
new file mode 100644
index 00..76929c3ea7
--- /dev/null
+++ b/tests/ref/fate/filter-pixdesc-xv36be
@@ -0,0 +1 @@
+pixdesc-xv36be  94d17b770b2a519e30952bdeb4e46391
diff --git a/tests/ref/fate/filter-pixfmts-copy 
b/tests/ref/fate/filter-pixfmts-copy
index 8bff815408..7e1259d182 100644
--- a/tests/ref/fate/filter-pixfmts-copy
+++ b/tests/ref/fate/filter-pixfmts-copy
@@ -106,6 +106,7 @@ vyu444  93912234400a4373b1a6b5c4e4b1a4ef
 x2bgr10le   550c0d190cf695afa4eaacb644db6b75
 x2rgb10le   c1e3ac21be04a16bb157b22784524520
 xv30le  718bf0

[FFmpeg-devel] [PATCH 4/6] swscale/input: add AYUV64BE input support

2024-10-15 Thread James Almer

Signed-off-by: James Almer 
---
 libswscale/input.c | 34 ++
 libswscale/utils.c |  1 +
 2 files changed, 35 insertions(+)

diff --git a/libswscale/input.c b/libswscale/input.c
index 6ac76f6752..bb5e31a428 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -665,6 +665,13 @@ static void read_ayuv64le_Y_c(uint8_t *dst, const uint8_t 
*src, const uint8_t *u
 AV_WN16(dst + i * 2, AV_RL16(src + i * 8 + 2));
 }
 
+static void read_ayuv64be_Y_c(uint8_t *dst, const uint8_t *src, const uint8_t 
*unused0, const uint8_t *unused1, int width,
+   uint32_t *unused2, void *opq)
+{
+int i;
+for (i = 0; i < width; i++)
+AV_WN16(dst + i * 2, AV_RB16(src + i * 8 + 2));
+}
 
 static void read_ayuv64le_UV_c(uint8_t *dstU, uint8_t *dstV, const uint8_t 
*unused0, const uint8_t *src,
const uint8_t *unused1, int width, uint32_t 
*unused2, void *opq)
@@ -676,6 +683,16 @@ static void read_ayuv64le_UV_c(uint8_t *dstU, uint8_t 
*dstV, const uint8_t *unus
 }
 }
 
+static void read_ayuv64be_UV_c(uint8_t *dstU, uint8_t *dstV, const uint8_t 
*unused0, const uint8_t *src,
+   const uint8_t *unused1, int width, uint32_t 
*unused2, void *opq)
+{
+int i;
+for (i = 0; i < width; i++) {
+AV_WN16(dstU + i * 2, AV_RB16(src + i * 8 + 4));
+AV_WN16(dstV + i * 2, AV_RB16(src + i * 8 + 6));
+}
+}
+
 static void read_ayuv64le_A_c(uint8_t *dst, const uint8_t *src, const uint8_t 
*unused0, const uint8_t *unused1, int width,
   uint32_t *unused2, void *opq)
 {
@@ -684,6 +701,14 @@ static void read_ayuv64le_A_c(uint8_t *dst, const uint8_t 
*src, const uint8_t *u
 AV_WN16(dst + i * 2, AV_RL16(src + i * 8));
 }
 
+static void read_ayuv64be_A_c(uint8_t *dst, const uint8_t *src, const uint8_t 
*unused0, const uint8_t *unused1, int width,
+  uint32_t *unused2, void *opq)
+{
+int i;
+for (i = 0; i < width; i++)
+AV_WN16(dst + i * 2, AV_RB16(src + i * 8));
+}
+
 static void read_vuyx_UV_c(uint8_t *dstU, uint8_t *dstV, const uint8_t 
*unused0, const uint8_t *src,
const uint8_t *unused1, int width, uint32_t 
*unused2, void *opq)
 {
@@ -1684,6 +1709,9 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c,
 case AV_PIX_FMT_AYUV64LE:
 *chrToYV12 = read_ayuv64le_UV_c;
 break;
+case AV_PIX_FMT_AYUV64BE:
+*chrToYV12 = read_ayuv64be_UV_c;
+break;
 case AV_PIX_FMT_UYVA:
 *chrToYV12 = read_uyva_UV_c;
 break;
@@ -2116,6 +2144,9 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c,
 case AV_PIX_FMT_AYUV64LE:
 *lumToYV12 = read_ayuv64le_Y_c;
 break;
+case AV_PIX_FMT_AYUV64BE:
+*lumToYV12 = read_ayuv64be_Y_c;
+break;
 case AV_PIX_FMT_XV36LE:
 *lumToYV12 = read_xv36le_Y_c;
 break;
@@ -2324,6 +2355,9 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c,
 case AV_PIX_FMT_AYUV64LE:
 *alpToYV12 = read_ayuv64le_A_c;
 break;
+case AV_PIX_FMT_AYUV64BE:
+*alpToYV12 = read_ayuv64be_A_c;
+break;
 case AV_PIX_FMT_PAL8 :
 *alpToYV12 = palToA_c;
 break;
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 227550451b..09d96b2292 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -231,6 +231,7 @@ static const FormatEntry format_entries[] = {
 [AV_PIX_FMT_XYZ12BE] = { 1, 1, 1 },
 [AV_PIX_FMT_XYZ12LE] = { 1, 1, 1 },
 [AV_PIX_FMT_AYUV64LE]= { 1, 1},
+[AV_PIX_FMT_AYUV64BE]= { 1, 0},
 [AV_PIX_FMT_P010LE]  = { 1, 1 },
 [AV_PIX_FMT_P010BE]  = { 1, 1 },
 [AV_PIX_FMT_P012LE]  = { 1, 1 },
-- 
2.46.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".

[FFmpeg-devel] [PATCH 1/6] swscale/output: fill all the xv36le alpha bits

2024-10-15 Thread James Almer

In xv36 case, the alpha plane bits are undefined, but the format still defines
the component as 12bits, with the other 4 bits zeroed, so set only the valid
bits.

Signed-off-by: James Almer 
---
 libswscale/output.c  | 4 ++--
 tests/ref/fate/filter-pixfmts-copy   | 2 +-
 tests/ref/fate/filter-pixfmts-crop   | 2 +-
 tests/ref/fate/filter-pixfmts-field  | 2 +-
 tests/ref/fate/filter-pixfmts-fieldorder | 2 +-
 tests/ref/fate/filter-pixfmts-hflip  | 2 +-
 tests/ref/fate/filter-pixfmts-il | 2 +-
 tests/ref/fate/filter-pixfmts-null   | 2 +-
 tests/ref/fate/filter-pixfmts-scale  | 2 +-
 tests/ref/fate/filter-pixfmts-transpose  | 2 +-
 tests/ref/fate/filter-pixfmts-vflip  | 2 +-
 11 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/libswscale/output.c b/libswscale/output.c
index 314dc8333f..3b954e28a2 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -2670,7 +2670,7 @@ yuv2xv36le_X_c(SwsContext *c, const int16_t *lumFilter,
 {
 int i;
 for (i = 0; i < dstW; i++) {
-int Y = 1 << 14, U = 1 << 14, V = 1 << 14, A = 255;
+int Y = 1 << 14, U = 1 << 14, V = 1 << 14, A = 65535;
 int j;
 
 for (j = 0; j < lumFilterSize; j++)
@@ -2684,7 +2684,7 @@ yuv2xv36le_X_c(SwsContext *c, const int16_t *lumFilter,
 AV_WL16(dest + 8 * i + 2, av_clip_uintp2(Y >> 15, 12) << 4);
 AV_WL16(dest + 8 * i + 0, av_clip_uintp2(U >> 15, 12) << 4);
 AV_WL16(dest + 8 * i + 4, av_clip_uintp2(V >> 15, 12) << 4);
-AV_WL16(dest + 8 * i + 6, A);
+AV_WL16(dest + 8 * i + 6, A << 4);
 }
 }
 
diff --git a/tests/ref/fate/filter-pixfmts-copy 
b/tests/ref/fate/filter-pixfmts-copy
index dbc9947a47..8bff815408 100644
--- a/tests/ref/fate/filter-pixfmts-copy
+++ b/tests/ref/fate/filter-pixfmts-copy
@@ -106,7 +106,7 @@ vyu444  93912234400a4373b1a6b5c4e4b1a4ef
 x2bgr10le   550c0d190cf695afa4eaacb644db6b75
 x2rgb10le   c1e3ac21be04a16bb157b22784524520
 xv30le  718bf036d13f9f1ea8804c2658dd53fa
-xv36le  6b8e46832aa8537a774e93dd7503c700
+xv36le  e08dcbde02f1c28a3554f372ad1278e2
 xyz12be a1ef56bf746d71f59669c28e48fc8450
 xyz12le 831ff03c1ba4ef19374686f16a064d8c
 y210le  0736b017e0814daf38d3350c42796f7a
diff --git a/tests/ref/fate/filter-pixfmts-crop 
b/tests/ref/fate/filter-pixfmts-crop
index ef2fa68db0..c4ca776ade 100644
--- a/tests/ref/fate/filter-pixfmts-crop
+++ b/tests/ref/fate/filter-pixfmts-crop
@@ -103,7 +103,7 @@ vyu444  5d976b25782ff69e4b3b18453fa1447b
 x2bgr10le   84de725b85662c362862820dc4a309aa
 x2rgb10le   f4265aca7a67dbfa9354370098ca6f33
 xv30le  efebde9ca614024cd7ed95c7c02e9281
-xv36le  567af630bf0209e026e0909b3ca9c436
+xv36le  778286003497f92b84d0bd8258d6b85d
 xyz12be cb4571f9aaa7b59f999ef327276104b7
 xyz12le cd6aae8d26b18bdb4b9d068586276d91
 ya16be  a3d18014454942a96f15a49947c0c55d
diff --git a/tests/ref/fate/filter-pixfmts-field 
b/tests/ref/fate/filter-pixfmts-field
index 6e500bdff7..67ebe64c4f 100644
--- a/tests/ref/fate/filter-pixfmts-field
+++ b/tests/ref/fate/filter-pixfmts-field
@@ -106,7 +106,7 @@ vyu444  b139fb4ddaef12a7542a68277211efa7
 x2bgr10le   dbe21538d7cb1744914f6bd46ec09b55
 x2rgb10le   a18bc4ae5274e0a8cca9137ecd50c677
 xv30le  298f6f14c5bfc18587cd1c3225287a39
-xv36le  e05a99fc3edc8f26cb2dbd287c0a0fcf
+xv36le  ba99f258370f2a56993e8760e6b30194
 xyz12be d2fa69ec91d3ed862f2dac3f8e7a3437
 xyz12le 02bccd5e0b6824779a1f848b0ea3e3b5
 y210le  025beb25f047a762e3788dbea4b60864
diff --git a/tests/ref/fate/filter-pixfmts-fieldorder 
b/tests/ref/fate/filter-pixfmts-fieldorder
index 890b9191c6..91106cbf39 100644
--- a/tests/ref/fate/filter-pixfmts-fieldorder
+++ b/tests/ref/fate/filter-pixfmts-fieldorder
@@ -95,7 +95,7 @@ vyu444  3ddab207d561a3ee5efae09e504207f2
 x2bgr10le   86474d84f26c5c51d6f75bf7e1de8da8
 x2rgb10le   cdf6a9e8a8d081aa768c6ae2e6221676
 xv30le  bfd6693b5e995f65b130d963a972c34e
-xv36le  1f054a1ba4c8f8875ffd15d3d1baccba
+xv36le  bcceffc985aaa8414c4b8072aa0889bd
 xyz12be 15f5cda71de5fef9cec5e75e3833b6bc
 xyz12le 7be6c8781f38c21a6b8f602f62ca31e6
 y210le  ee45acfb1386288af98af5313162ff3e
diff --git a/tests/ref/fate/filter-pixfmts-hflip 
b/tests/ref/fate/filter-pixfmts-hflip
index e12999a15a..18b9fe76fe 100644
--- a/tests/ref/fate/filter-pixfmts-hflip
+++ b/tests/ref/fate/filter-pixfmts-hflip
@@ -103,7 +103,7 @@ vyu444  7b72337f92a7223fd115265e2f769276
 x2bgr10le   827cc659f29378e00c5a7d2c0ada8f9a
 x2rgb10le   d4a8189b65395a88d0a38a7053f3359f
 xv30le  79c6fe0c957d4fdc7bd6d056b13d7ceb
-xv36le  6e9c3d2334f9fe2a0e6156615e53e272
+xv36le

[FFmpeg-devel] [PATCH 2/6] swscale/input: add X36VBE input support

2024-10-15 Thread James Almer

Signed-off-by: James Almer 
---
 libswscale/input.c | 25 +
 libswscale/utils.c |  1 +
 2 files changed, 26 insertions(+)

diff --git a/libswscale/input.c b/libswscale/input.c
index 9beb72b8ec..6ac76f6752 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -822,6 +822,25 @@ static void read_xv36le_UV_c(uint8_t *dstU, uint8_t *dstV, 
const uint8_t *unused
 }
 }
 
+static void read_xv36be_Y_c(uint8_t *dst, const uint8_t *src, const uint8_t 
*unused0, const uint8_t *unused1, int width,
+   uint32_t *unused2, void *opq)
+{
+int i;
+for (i = 0; i < width; i++)
+AV_WN16(dst + i * 2, AV_RB16(src + i * 8 + 2) >> 4);
+}
+
+
+static void read_xv36be_UV_c(uint8_t *dstU, uint8_t *dstV, const uint8_t 
*unused0, const uint8_t *src,
+   const uint8_t *unused1, int width, uint32_t 
*unused2, void *opq)
+{
+int i;
+for (i = 0; i < width; i++) {
+AV_WN16(dstU + i * 2, AV_RB16(src + i * 8 + 0) >> 4);
+AV_WN16(dstV + i * 2, AV_RB16(src + i * 8 + 4) >> 4);
+}
+}
+
 /* This is almost identical to the previous, end exists only because
  * yuy2ToY/UV)(dst, src + 1, ...) would have 100% unaligned accesses. */
 static void uyvyToY_c(uint8_t *dst, const uint8_t *src, const uint8_t 
*unused1, const uint8_t *unused2,  int width,
@@ -1671,6 +1690,9 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c,
 case AV_PIX_FMT_XV36LE:
 *chrToYV12 = read_xv36le_UV_c;
 break;
+case AV_PIX_FMT_XV36BE:
+*chrToYV12 = read_xv36be_UV_c;
+break;
 case AV_PIX_FMT_P010LE:
 case AV_PIX_FMT_P210LE:
 case AV_PIX_FMT_P410LE:
@@ -2097,6 +2119,9 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c,
 case AV_PIX_FMT_XV36LE:
 *lumToYV12 = read_xv36le_Y_c;
 break;
+case AV_PIX_FMT_XV36BE:
+*lumToYV12 = read_xv36be_Y_c;
+break;
 case AV_PIX_FMT_YUYV422:
 case AV_PIX_FMT_YVYU422:
 case AV_PIX_FMT_YA8:
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 992d7f01b7..5b2ca8bf1d 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -272,6 +272,7 @@ static const FormatEntry format_entries[] = {
 [AV_PIX_FMT_RGBF32LE]= { 1, 0 },
 [AV_PIX_FMT_XV30LE]  = { 1, 1 },
 [AV_PIX_FMT_XV36LE]  = { 1, 1 },
+[AV_PIX_FMT_XV36BE]  = { 1, 0 },
 [AV_PIX_FMT_AYUV]= { 1, 1 },
 [AV_PIX_FMT_UYVA]= { 1, 1 },
 [AV_PIX_FMT_VYU444]  = { 1, 1 },
-- 
2.46.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".

[FFmpeg-devel] [PATCH 6/6] avfilter/vsrc_testsrc: add support for XV36 and AYUV64

2024-10-15 Thread James Almer

Signed-off-by: James Almer 
---
Maybe the fourth component in the descriptor can be filled with the relevant
values instead, for use cases like this one?

 libavfilter/vsrc_testsrc.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/libavfilter/vsrc_testsrc.c b/libavfilter/vsrc_testsrc.c
index 7f8db39f84..d57464a6c0 100644
--- a/libavfilter/vsrc_testsrc.c
+++ b/libavfilter/vsrc_testsrc.c
@@ -1159,6 +1159,7 @@ static void yuvtest_put_pixel(uint8_t *dstp[4], int 
dst_linesizep[4],
   uint8_t ayuv_map[4])
 {
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(fmt);
+int shift = 0;
 uint32_t n;
 
 switch (fmt) {
@@ -1173,6 +1174,15 @@ static void yuvtest_put_pixel(uint8_t *dstp[4], int 
dst_linesizep[4],
 (v << ((desc->comp[2].offset*8) + desc->comp[2].shift));
 AV_WL32(&dstp[0][i*4 + j*dst_linesizep[0]], n);
 break;
+case AV_PIX_FMT_XV36:
+shift = 4; // hardcoded as the alpha component in the descriptor has 
no values we can use
+// fall-through
+case AV_PIX_FMT_AYUV64:
+AV_WN16(&dstp[0][i*8 + ayuv_map[Y]*2 + j*dst_linesizep[0]], y << 
desc->comp[0].shift);
+AV_WN16(&dstp[0][i*8 + ayuv_map[U]*2 + j*dst_linesizep[0]], u << 
desc->comp[1].shift);
+AV_WN16(&dstp[0][i*8 + ayuv_map[V]*2 + j*dst_linesizep[0]], v << 
desc->comp[2].shift);
+AV_WN16(&dstp[0][i*8 + ayuv_map[A]*2 + j*dst_linesizep[0]], UINT16_MAX 
<<  shift);
+break;
 case AV_PIX_FMT_UYVA:
 case AV_PIX_FMT_VUYA:
 case AV_PIX_FMT_VUYX:
@@ -1235,9 +1245,9 @@ static const enum AVPixelFormat yuvtest_pix_fmts[] = {
 AV_PIX_FMT_YUV444P9, AV_PIX_FMT_YUV444P10,
 AV_PIX_FMT_YUV444P12, AV_PIX_FMT_YUV444P14,
 AV_PIX_FMT_YUV444P16, AV_PIX_FMT_VYU444,
-AV_PIX_FMT_AYUV, AV_PIX_FMT_UYVA,
+AV_PIX_FMT_AYUV, AV_PIX_FMT_UYVA, AV_PIX_FMT_AYUV64,
 AV_PIX_FMT_VUYA, AV_PIX_FMT_VUYX,
-AV_PIX_FMT_XV30LE, AV_PIX_FMT_V30XLE,
+AV_PIX_FMT_XV30LE, AV_PIX_FMT_V30XLE, AV_PIX_FMT_XV36,
 AV_PIX_FMT_NONE
 };
 
-- 
2.46.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] [RFC] AVFilter

2024-10-15 Thread Anton Khirnov

Quoting Michael Niedermayer (2024-10-15 19:40:12)
> I think before these fields are moved into a private header, it is a good idea
> to disscuss, if the community wants "creating filters" to be possible though 
> the
> API (as it was originally intended)

It was NEVER possible for avfilter API users to create their own
filters. We were also never even close to it, as there was never a clear
interface between filters and the core, so simply exporting the
appropriate headers would effectively freeze core development as any
change could potentially break some filter.

I also think you're misunderstanding or misinterpreting the direction of
my work. I am trying to make the external and internal interfaces of
avfilter more clear and well-defined, which makes external filters
(should we decide to allow them) easier, not harder.

-- 
Anton Khirnov
___
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] lavu/common: Fix AV_CEIL_RSHIFT for unsigned LHS

2024-10-15 Thread Frank Plowman

On 14/10/2024 23:26, Michael Niedermayer wrote:
> On Sat, Oct 05, 2024 at 03:38:05PM -0700, Frank Plowman wrote:
>> The first branch of this ternary expression was intended to avoid
>> having two shift operations in the case the RHS is not known at
>> compile time.  It only works if the LHS has a signed type however,
>> otherwise the result is invalid.
> 
> If the expression is faster, why not check if its signed ?
> 
> if its not faster, then the argument could be that its not
> faster and removes complexity
> 
> thx
> 

In a quick microbenchmark (clang 16, AArch64), the bithack is 10% faster
with -O0 but there is no significant difference with -O1 and up.

Cheers,
-- 
Frank

___
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] nuv1 in avi

2024-10-15 Thread Andrew Randrianasulu

вс, 13 окт. 2024 г., 14:40 Anton Khirnov :

> Quoting Andrew Randrianasulu (2024-10-08 14:03:13)
> > I was experimenting with mencoder
> >
> > 
> >
> > what do you think? ;)
>
> why oh oh god why?
>

Because mplayer (and mencoder) was first program I successfully compiled
many, many years back and I used mencoder on underpowered ~400 Mhz Celeron
for capturing some video

https://randrianasulu.livejournal.com/13569.html

now it may considered obsolete, but underpowered hardware still exist. For
example, PinePhone I was reading about have some 4*1.1 GHz ARM, so ffmpeg
was used there via cli anyway, surprisingly no-one showed mpeg2 line? It
was mjpeg or vp8 (9) or x264 ultrafast 

https://www.reddit.com/r/PINE64official/comments/18awye8/pinephone_video_recording/

now, x86 and ARM surely different, but if something can be scaled back to
non-MMX Pentium it probably will work on many "obsolete" devices where
latest SIMD sets not available. I actually used some version of Indeo codec
back in ~2001 for recording in ... 176*144 ? on exactly Pentium 1 150Mhz.
Under win 9x, from VirtualDub. I was surprised it worked at all (with
preview!).

So, I set my AMD FX to 1400 Mhz, fired up mplayer/mencoder under qemu-i386
to see how it performs with some binary mjpeg encoder (MainConcept's mjpeg,
claimed to reach realtime 640*480 on PII 300 Mhz (from settings probably
one field only)). Found mencoder was doing 25 fps with binary encoder dll,
ffmpeg 0.5.15 was doing up to 40 fps in mjpeg/i420 if compiled for i486,
ffmpeg 4.4/latest was doing up to 20 fps. Not sure why, but it was
interesting! nuv without rtjpeg compression beat them all at 75 fps. Still
20 mb vs 30 mb for completely uncompressed yuv420p.








> --
> Anton Khirnov
> ___
> 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 2/2] libavcodec/ffv1: Support storing LSB raw

2024-10-15 Thread Lynne via ffmpeg-devel


On 16/10/2024 01:17, Michael Niedermayer wrote:

This makes a 16bit RGB raw sample 25% faster at a 2% loss of compression with 
rawlsb=4

Please test and comment

This stores the LSB through non binary range coding, this is simpler than using 
a
separate coder
For cases where range coding is not wanted its probably best to use golomb rice
for everything.

We also pass the LSB through the decorrelation and context stages (which is 
basically free)
this leads to slightly better compression than separating them earlier.

Signed-off-by: Michael Niedermayer 
---
  libavcodec/ffv1.h |  2 ++
  libavcodec/ffv1_template.c| 19 ++-
  libavcodec/ffv1dec.c  |  2 ++
  libavcodec/ffv1dec_template.c | 16 +---
  libavcodec/ffv1enc.c  | 15 ++-
  libavcodec/ffv1enc_template.c | 17 +++--
  libavcodec/rangecoder.h   | 20 
  libavcodec/tests/rangecoder.c |  9 +
  8 files changed, 85 insertions(+), 15 deletions(-)

diff --git a/libavcodec/ffv1.h b/libavcodec/ffv1.h
index 4f5a8ab2be7..02bfc33f680 100644
--- a/libavcodec/ffv1.h
+++ b/libavcodec/ffv1.h
@@ -83,6 +83,7 @@ typedef struct FFV1SliceContext {
  int slice_coding_mode;
  int slice_rct_by_coef;
  int slice_rct_ry_coef;
+int rawlsb;
  
  // RefStruct reference, array of MAX_PLANES elements

  PlaneContext *plane;
@@ -139,6 +140,7 @@ typedef struct FFV1Context {
  int key_frame_ok;
  int context_model;
  int qtable;
+int rawlsb;
  
  int bits_per_raw_sample;

  int packed_at_lsb;
diff --git a/libavcodec/ffv1_template.c b/libavcodec/ffv1_template.c
index abb90a12e49..10206702ee8 100644
--- a/libavcodec/ffv1_template.c
+++ b/libavcodec/ffv1_template.c
@@ -30,24 +30,25 @@ static inline int RENAME(predict)(TYPE *src, TYPE *last)
  }
  
  static inline int RENAME(get_context)(const int16_t quant_table[MAX_CONTEXT_INPUTS][MAX_QUANT_TABLE_SIZE],

-  TYPE *src, TYPE *last, TYPE *last2)
+  TYPE *src, TYPE *last, TYPE *last2, int 
rawlsb)
  {
  const int LT = last[-1];
  const int T  = last[0];
  const int RT = last[1];
  const int L  = src[-1];
+const int rawoff = (1<> 1;
  
  if (quant_table[3][127] || quant_table[4][127]) {

  const int TT = last2[0];
  const int LL = src[-2];
-return quant_table[0][(L - LT) & MAX_QUANT_TABLE_MASK] +
-   quant_table[1][(LT - T) & MAX_QUANT_TABLE_MASK] +
-   quant_table[2][(T - RT) & MAX_QUANT_TABLE_MASK] +
-   quant_table[3][(LL - L) & MAX_QUANT_TABLE_MASK] +
-   quant_table[4][(TT - T) & MAX_QUANT_TABLE_MASK];
+return quant_table[0][(L - LT + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[1][(LT - T + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[2][(T - RT + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[3][(LL - L + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[4][(TT - T + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK];
  } else
-return quant_table[0][(L - LT) & MAX_QUANT_TABLE_MASK] +
-   quant_table[1][(LT - T) & MAX_QUANT_TABLE_MASK] +
-   quant_table[2][(T - RT) & MAX_QUANT_TABLE_MASK];
+return quant_table[0][(L - LT + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[1][(LT - T + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[2][(T - RT + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK];
  }
  
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c

index 5c099e49ad4..fc96bfb4cea 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -249,6 +249,8 @@ static int decode_slice_header(const FFV1Context *f,
  return AVERROR_INVALIDDATA;
  }
  }
+if (f->micro_version > 2)
+sc->rawlsb = get_symbol(c, state, 0);
  }
  
  return 0;

diff --git a/libavcodec/ffv1dec_template.c b/libavcodec/ffv1dec_template.c
index 2da6bd935dc..dbdcad7768e 100644
--- a/libavcodec/ffv1dec_template.c
+++ b/libavcodec/ffv1dec_template.c
@@ -60,8 +60,13 @@ RENAME(decode_line)(FFV1Context *f, FFV1SliceContext *sc,
  return AVERROR_INVALIDDATA;
  }
  
-context = RENAME(get_context)(quant_table,

-  sample[1] + x, sample[0] + x, sample[1] 
+ x);
+if (sc->rawlsb) {
+context = RENAME(get_context)(quant_table,
+  sample[1] + x, sample[0] + x, sample[1] 
+ x, sc->rawlsb);
+} else {
+context = RENAME(get_context)(quant_table,
+  sample[1] + x, sample[0] + x, 
sample[1] + x, 0);
+}
  if (context < 0) {
  context = -context;
  sign= 1;
@@ -71,7 +76,12 @@ RENAME(

Re: [FFmpeg-devel] [RFC] AVFilter

2024-10-15 Thread Michael Niedermayer

On Tue, Oct 15, 2024 at 07:14:27PM -0400, Sean McGovern wrote:
> Hi,
> 
> 
> On Tue, Oct 15, 2024, 12:19 Michael Niedermayer 
> wrote:
> 
> > Hi all
> >
> > This is a quick RFC about peoples oppinions on AVFilter
> >
> > The question: Should anyone be able to write a filter (which
> > other people can use) ?
> > Or should only we be able to add filters ?
> >
> > (This relates to what parts of the API are publically accessable)
> >
> > So whats the point of this RFC ?
> >
> > If we want a public API that allows writing filters then work on the API
> > has to be compatible with that direction.
> >
> > "compatible" for example would be, "Adding whats missing to the public API"
> > or "deprecating existing API and writing a better API that makes all needed
> > parts public"
> >
> > "incompatible" for example is "making bits and pieces private that are
> > needed
> > by filters
> >
> > Some of the currently pending patches seem to fall into the "incompatible"
> > category, while iam not sure what peoples oppinions is on the direction
> > of AVfilter, which is why iam bringing this up
> >
> > Thx
> >
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > It is a danger to trust the dream we wish for rather than
> > the science we have, -- Dr. Kenneth Brown
> > ___
> > 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".
> >
> 
> We should strive to make it easy and desirable to merge filters in to
> FFmpeg proper.

that sounds good until one realizes its not even the right place

As a filter author i want to be able to write a filter and have
users be able to use it.
Same as a C source code author i want github to host my code so
others can find and use the code.

If every change to my github repository would need to be reviewed by github
staff who on top of that have never used or intend to ever use the code
i would not use github.

And with libavfilter and filters, theres nothing equivalent to github
Thats as if every C code author would have to get his program approved
by the people maintaining the C spec.
(Who then of course arent interrested in every area someone wants to
 write a C program for ...)

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] [RFC] AVFilter

2024-10-15 Thread Sean McGovern

Hi,


On Tue, Oct 15, 2024, 12:19 Michael Niedermayer 
wrote:

> Hi all
>
> This is a quick RFC about peoples oppinions on AVFilter
>
> The question: Should anyone be able to write a filter (which
> other people can use) ?
> Or should only we be able to add filters ?
>
> (This relates to what parts of the API are publically accessable)
>
> So whats the point of this RFC ?
>
> If we want a public API that allows writing filters then work on the API
> has to be compatible with that direction.
>
> "compatible" for example would be, "Adding whats missing to the public API"
> or "deprecating existing API and writing a better API that makes all needed
> parts public"
>
> "incompatible" for example is "making bits and pieces private that are
> needed
> by filters
>
> Some of the currently pending patches seem to fall into the "incompatible"
> category, while iam not sure what peoples oppinions is on the direction
> of AVfilter, which is why iam bringing this up
>
> Thx
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> It is a danger to trust the dream we wish for rather than
> the science we have, -- Dr. Kenneth Brown
> ___
> 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".
>

We should strive to make it easy and desirable to merge filters in to
FFmpeg proper.

-- Sean McGovern

>
___
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/ffv1: add a named constant for the quant table size

2024-10-15 Thread Michael Niedermayer

Signed-off-by: Michael Niedermayer 
---
 libavcodec/ffv1.h  |  4 +++-
 libavcodec/ffv1_template.c | 18 +-
 libavcodec/ffv1enc.c   |  6 +++---
 3 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/libavcodec/ffv1.h b/libavcodec/ffv1.h
index 18f002c6312..4f5a8ab2be7 100644
--- a/libavcodec/ffv1.h
+++ b/libavcodec/ffv1.h
@@ -44,6 +44,8 @@
 #define CONTEXT_SIZE 32
 
 #define MAX_QUANT_TABLES 8
+#define MAX_QUANT_TABLE_SIZE 256
+#define MAX_QUANT_TABLE_MASK (MAX_QUANT_TABLE_SIZE - 1)
 #define MAX_CONTEXT_INPUTS 5
 
 #define AC_GOLOMB_RICE  0
@@ -124,7 +126,7 @@ typedef struct FFV1Context {
 const AVFrame *cur_enc_frame;
 int plane_count;
 int ac;  ///< 1=range coder <-> 0=golomb rice
-int16_t quant_tables[MAX_QUANT_TABLES][MAX_CONTEXT_INPUTS][256];
+int16_t 
quant_tables[MAX_QUANT_TABLES][MAX_CONTEXT_INPUTS][MAX_QUANT_TABLE_SIZE];
 int context_count[MAX_QUANT_TABLES];
 uint8_t state_transition[256];
 uint8_t (*initial_states[MAX_QUANT_TABLES])[32];
diff --git a/libavcodec/ffv1_template.c b/libavcodec/ffv1_template.c
index d15ad11021a..abb90a12e49 100644
--- a/libavcodec/ffv1_template.c
+++ b/libavcodec/ffv1_template.c
@@ -29,7 +29,7 @@ static inline int RENAME(predict)(TYPE *src, TYPE *last)
 return mid_pred(L, L + T - LT, T);
 }
 
-static inline int RENAME(get_context)(const int16_t 
quant_table[MAX_CONTEXT_INPUTS][256],
+static inline int RENAME(get_context)(const int16_t 
quant_table[MAX_CONTEXT_INPUTS][MAX_QUANT_TABLE_SIZE],
   TYPE *src, TYPE *last, TYPE *last2)
 {
 const int LT = last[-1];
@@ -40,14 +40,14 @@ static inline int RENAME(get_context)(const int16_t 
quant_table[MAX_CONTEXT_INPU
 if (quant_table[3][127] || quant_table[4][127]) {
 const int TT = last2[0];
 const int LL = src[-2];
-return quant_table[0][(L - LT) & 0xFF] +
-   quant_table[1][(LT - T) & 0xFF] +
-   quant_table[2][(T - RT) & 0xFF] +
-   quant_table[3][(LL - L) & 0xFF] +
-   quant_table[4][(TT - T) & 0xFF];
+return quant_table[0][(L - LT) & MAX_QUANT_TABLE_MASK] +
+   quant_table[1][(LT - T) & MAX_QUANT_TABLE_MASK] +
+   quant_table[2][(T - RT) & MAX_QUANT_TABLE_MASK] +
+   quant_table[3][(LL - L) & MAX_QUANT_TABLE_MASK] +
+   quant_table[4][(TT - T) & MAX_QUANT_TABLE_MASK];
 } else
-return quant_table[0][(L - LT) & 0xFF] +
-   quant_table[1][(LT - T) & 0xFF] +
-   quant_table[2][(T - RT) & 0xFF];
+return quant_table[0][(L - LT) & MAX_QUANT_TABLE_MASK] +
+   quant_table[1][(LT - T) & MAX_QUANT_TABLE_MASK] +
+   quant_table[2][(T - RT) & MAX_QUANT_TABLE_MASK];
 }
 
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 5e2a9fe2275..0dbfebc1a1a 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -317,7 +317,7 @@ static void write_quant_table(RangeCoder *c, int16_t 
*quant_table)
 uint8_t state[CONTEXT_SIZE];
 memset(state, 128, sizeof(state));
 
-for (i = 1; i < 128; i++)
+for (i = 1; i < MAX_QUANT_TABLE_SIZE/2; i++)
 if (quant_table[i] != quant_table[i - 1]) {
 put_symbol(c, state, i - last - 1, 0);
 last = i;
@@ -326,7 +326,7 @@ static void write_quant_table(RangeCoder *c, int16_t 
*quant_table)
 }
 
 static void write_quant_tables(RangeCoder *c,
-   int16_t quant_table[MAX_CONTEXT_INPUTS][256])
+   int16_t 
quant_table[MAX_CONTEXT_INPUTS][MAX_QUANT_TABLE_SIZE])
 {
 int i;
 for (i = 0; i < 5; i++)
@@ -726,7 +726,7 @@ static av_cold int encode_init(AVCodecContext *avctx)
 s->state_transition[i] = c.one_state[i];
 }
 
-for (i = 0; i < 256; i++) {
+for (i = 0; i < MAX_QUANT_TABLE_SIZE; i++) {
 s->quant_table_count = 2;
 if ((s->qtable == -1 && s->bits_per_raw_sample <= 8) || s->qtable == 
1) {
 s->quant_tables[0][0][i]=   quant11[i];
-- 
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 2/2] libavcodec/ffv1: Support storing LSB raw

2024-10-15 Thread Michael Niedermayer

This makes a 16bit RGB raw sample 25% faster at a 2% loss of compression with 
rawlsb=4

Please test and comment

This stores the LSB through non binary range coding, this is simpler than using 
a
separate coder
For cases where range coding is not wanted its probably best to use golomb rice
for everything.

We also pass the LSB through the decorrelation and context stages (which is 
basically free)
this leads to slightly better compression than separating them earlier.

Signed-off-by: Michael Niedermayer 
---
 libavcodec/ffv1.h |  2 ++
 libavcodec/ffv1_template.c| 19 ++-
 libavcodec/ffv1dec.c  |  2 ++
 libavcodec/ffv1dec_template.c | 16 +---
 libavcodec/ffv1enc.c  | 15 ++-
 libavcodec/ffv1enc_template.c | 17 +++--
 libavcodec/rangecoder.h   | 20 
 libavcodec/tests/rangecoder.c |  9 +
 8 files changed, 85 insertions(+), 15 deletions(-)

diff --git a/libavcodec/ffv1.h b/libavcodec/ffv1.h
index 4f5a8ab2be7..02bfc33f680 100644
--- a/libavcodec/ffv1.h
+++ b/libavcodec/ffv1.h
@@ -83,6 +83,7 @@ typedef struct FFV1SliceContext {
 int slice_coding_mode;
 int slice_rct_by_coef;
 int slice_rct_ry_coef;
+int rawlsb;
 
 // RefStruct reference, array of MAX_PLANES elements
 PlaneContext *plane;
@@ -139,6 +140,7 @@ typedef struct FFV1Context {
 int key_frame_ok;
 int context_model;
 int qtable;
+int rawlsb;
 
 int bits_per_raw_sample;
 int packed_at_lsb;
diff --git a/libavcodec/ffv1_template.c b/libavcodec/ffv1_template.c
index abb90a12e49..10206702ee8 100644
--- a/libavcodec/ffv1_template.c
+++ b/libavcodec/ffv1_template.c
@@ -30,24 +30,25 @@ static inline int RENAME(predict)(TYPE *src, TYPE *last)
 }
 
 static inline int RENAME(get_context)(const int16_t 
quant_table[MAX_CONTEXT_INPUTS][MAX_QUANT_TABLE_SIZE],
-  TYPE *src, TYPE *last, TYPE *last2)
+  TYPE *src, TYPE *last, TYPE *last2, int 
rawlsb)
 {
 const int LT = last[-1];
 const int T  = last[0];
 const int RT = last[1];
 const int L  = src[-1];
+const int rawoff = (1<> 1;
 
 if (quant_table[3][127] || quant_table[4][127]) {
 const int TT = last2[0];
 const int LL = src[-2];
-return quant_table[0][(L - LT) & MAX_QUANT_TABLE_MASK] +
-   quant_table[1][(LT - T) & MAX_QUANT_TABLE_MASK] +
-   quant_table[2][(T - RT) & MAX_QUANT_TABLE_MASK] +
-   quant_table[3][(LL - L) & MAX_QUANT_TABLE_MASK] +
-   quant_table[4][(TT - T) & MAX_QUANT_TABLE_MASK];
+return quant_table[0][(L - LT + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[1][(LT - T + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[2][(T - RT + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[3][(LL - L + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[4][(TT - T + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK];
 } else
-return quant_table[0][(L - LT) & MAX_QUANT_TABLE_MASK] +
-   quant_table[1][(LT - T) & MAX_QUANT_TABLE_MASK] +
-   quant_table[2][(T - RT) & MAX_QUANT_TABLE_MASK];
+return quant_table[0][(L - LT + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[1][(LT - T + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[2][(T - RT + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK];
 }
 
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index 5c099e49ad4..fc96bfb4cea 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -249,6 +249,8 @@ static int decode_slice_header(const FFV1Context *f,
 return AVERROR_INVALIDDATA;
 }
 }
+if (f->micro_version > 2)
+sc->rawlsb = get_symbol(c, state, 0);
 }
 
 return 0;
diff --git a/libavcodec/ffv1dec_template.c b/libavcodec/ffv1dec_template.c
index 2da6bd935dc..dbdcad7768e 100644
--- a/libavcodec/ffv1dec_template.c
+++ b/libavcodec/ffv1dec_template.c
@@ -60,8 +60,13 @@ RENAME(decode_line)(FFV1Context *f, FFV1SliceContext *sc,
 return AVERROR_INVALIDDATA;
 }
 
-context = RENAME(get_context)(quant_table,
-  sample[1] + x, sample[0] + x, sample[1] 
+ x);
+if (sc->rawlsb) {
+context = RENAME(get_context)(quant_table,
+  sample[1] + x, sample[0] + x, 
sample[1] + x, sc->rawlsb);
+} else {
+context = RENAME(get_context)(quant_table,
+  sample[1] + x, sample[0] + x, 
sample[1] + x, 0);
+}
 if (context < 0) {
 context = -context;
 sign= 1;
@@ -71,7 +76,12 @@ RENAME(decode_line)(FFV1Context *f, FFV1SliceContext *sc,
 av_assert2(context < p->context_count);

Re: [FFmpeg-devel] [RFC] AVFilter

2024-10-15 Thread Michael Niedermayer

On Tue, Oct 15, 2024 at 09:44:06PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-10-15 18:12:21)
> > Hi all
> > 
> > This is a quick RFC about peoples oppinions on AVFilter
> > 
> > The question: Should anyone be able to write a filter (which
> > other people can use) ?
[...]

>
> IS a matter of opinion.

yes thats why i was asking with that mail here

> Mine is "maybe",

 :)

> but at the very
> least a huge a mount of work on avfilter internals is needed to make
> that feasible.

iam not truly convinced that a "huge a mount of work" is needed
but iam not disputing that a "huge a mount of work" might be needed

If you or someone else wants to work on this and wants my vote for
having this funded, i would of course vote in favor of such a thing
being funded, be that through STF or something else.

I do belive it would expand what ffmpegs libavfilter can be used for
and would give libavfilter an edge against other filter frameworks

thx

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

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA

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 3/4] fftools/opt_common: stop accessing a private field

2024-10-15 Thread Anton Khirnov

Quoting Alexander Strasser via ffmpeg-devel (2024-10-15 21:16:28)
> On 2024-10-15 15:09 +0200, Anton Khirnov wrote:
> > Quoting James Almer (2024-10-15 14:54:08)
> > > On 10/15/2024 6:57 AM, Anton Khirnov wrote:
> > > > avfilter_process_command() may or may not return ENOSYS whether that
> > > > flag is set or not, so I don't see what exactly would it be useful for.
> > >
> > > I see, although I wouldn't expect ENOSYS for any other case than
> > > "unsupported". If a command fails, imo it would be EINVAL, or maybe 
> > > ENOMEM.
> >
> > Correct, but
> > * some commands work on all filters; for now it's just "ping", but we
> >   can add more in the future;
> > * the "enable" command works on all filters flagged with
> >   AVFILTER_FLAG_SUPPORT_TIMELINE; again, we may add more such
> >   "semi-generic" commands in the future;
> > * filters that do implement the process_command() callback will still
> >   return ENOSYS when you send them a command they do not support.
> >
> > So checking for the existence of process_command() does not really tell
> > you anything specific, and the same would hold for the hypothetical flag
> > that would replace it.
> >
> > >
> > > > Same holds for printing the capability in fftools - just what is the
> > > > user expected to do with that information?
> > >
> > > Know they can use the send command interrupt for a given filter without
> > > having it unconditionally fail, i guess. But for that matter, is the
> > > list of supported commands available anywhere for the user? Is there an
> > > API to query them, or is it expected to be only in the documentation?
> > > If there's no API, then maybe printing this is pointless.
> >
> > There is no such API, which I agree would be useful - but if it did
> > exist we would again not need the flag.
> 
> For me that flag is more about if some filter brings commands of its own.

Most filters implementing the process_command() callback just use
the generic implementation - ff_filter_process_command(). So what
information does that flag actually give you?

-- 
Anton Khirnov
___
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] doc/ffmpeg: improve -disposition, -stats, and -progress documentation

2024-10-15 Thread Lucz Soma

Right, thanks! I’ll remove that. Even if it were true, still a bit superfluous.

Soma

> On 2024. Oct 15., at 12:04, Anton Khirnov  wrote:
> 
> Quoting Soma Lucz (2024-10-13 15:18:49)
>> ('-' prefixes between disposition flags have no effect in this case).
> 
> This is not entirely true, you could have +foo+bar-foo that evaluates to
> bar.
> 
> Otherwise looks good to me.
> 
> --
> Anton Khirnov
> ___
> 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 3/4] fftools/opt_common: stop accessing a private field

2024-10-15 Thread Nicolas George

Anton Khirnov (12024-10-15):
> Most filters implementing the process_command() callback just use
> the generic implementation - ff_filter_process_command(). So what
> information does that flag actually give you?

It gives the information that the filter is ready to deal with what
ff_filter_process_command() does, i.e. change the value of options on
the fly.

Note: commands are not a part I am familiar with, I had to check and it
took me less than 30 seconds. You could have done the same.

-- 
  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] [RFC] AVFilter

2024-10-15 Thread Anton Khirnov

Quoting Michael Niedermayer (2024-10-15 18:12:21)
> Hi all
> 
> This is a quick RFC about peoples oppinions on AVFilter
> 
> The question: Should anyone be able to write a filter (which
> other people can use) ?

The question whether libavfilter API currently allows external users to
implement their own AVFilter instances is not a matter of opinion -
there is a very clear objective answer, which is NO, because the
necessary APIs are not exported from the library and the relevant
headers are not installed.

The question whether we should eventually change the above fact is more
complicated and IS a matter of opinion. Mine is "maybe", but at the very
least a huge a mount of work on avfilter internals is needed to make
that feasible.

-- 
Anton Khirnov
___
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".

65 matches

Mail list logo