Re: [FFmpeg-devel] Scaling PAL8 images with alpha

[Paul B Mahol]

On Sat, Sep 25, 2021 at 5:00 AM Soft Works  wrote:

>
>
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > Soft Works
> > Sent: Friday, 24 September 2021 19:03
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> >
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of
> > Michael
> > > Niedermayer
> > > Sent: Friday, 24 September 2021 17:40
> > > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> > >
> > > On Fri, Sep 24, 2021 at 10:30:31AM +, Soft Works wrote:
> > > > Hi,
> > > >
> > > > for a new filter, I want to rescale PAL8 subtitle bitmaps where
> > the palette
> > > includes
> > > > colors with alpha.
> > > >
> > > > From what I’ve seen, swscale doesn’t support PAL8-to-PAL8, only
> > PAL8-to-
> > > BGR8
> > > > which doesn’t support alpha and the palette is fixed with 256
> > entries
> > > defined by
> > > > convention, while I would ideally like to be able to allow the
> > following:
> > > >
> > > > - constrain the output to use the same palette as the input
> > > > - adaptively quantize it to a palette with a configurable number
> > of colors
> > > >
> > > > Thus it's about the palette quantization (with or without
> > dithering) after
> > > > scaling in RGBA. (or some cool algorithmic trick I'm not aware
> > of)
> > > >
> > > > Is there any existing code that I could reuse? The closest I
> > could find
> > > > is pngenc, but I'm wondering whether there's something
> > else/better
> > > > somewhere in the ffmpeg libs that I haven't seen?
> > >
> > > There are some non linear scaling filters which may make sense when
> > you do
> > > not have the full linear space available see:
> > > hqx, epx, xbr
> > > you could also try some neural net stuff
> >
> > Photoshop can perfectly do what is needed, but their algorithms are
> > not
> > public.
>
> I've put a few thing together to illustrate what I'm talking about:
>
> https://gist.github.com/softworkz/deef5c2a43d3d629c3e17f9e21544a8f
>
>
> Meanwhile I found what I need: https://github.com/ImageOptim/libimagequant
>
> Interestingly, they are comparing their lib specifically to the
> Photoshop feature that I mentioned: https://pngquant.org/vsphotoshop.html
> In the 2000's, the PS implementation for image quantization, optimization
> and compression (profanely named "Save for Web") had remained
> unparalleled for years, that's why it was one of my first thoughts.
>
> I hadn't heard about libimagequant before, but it seems to do exactly
> what is needed for rescaling PAL8 to PAL8 at a high quality.
>
> Before spending any time on it, I wanted ask whether that library
> would be acceptable for adding it as a (GPLv3) reference to the
> project and as a dependency to my filter?
>
>
I'm against more GPLv3 dependency in lavfi.


> Kind regards,
> softworkz
>
>
> ___
> 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] Scaling PAL8 images with alpha

[Hendrik Leppkes]

On Sat, Sep 25, 2021 at 5:00 AM Soft Works  wrote:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > Soft Works
> > Sent: Friday, 24 September 2021 19:03
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> >
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of
> > Michael
> > > Niedermayer
> > > Sent: Friday, 24 September 2021 17:40
> > > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> > >
> > > On Fri, Sep 24, 2021 at 10:30:31AM +, Soft Works wrote:
> > > > Hi,
> > > >
> > > > for a new filter, I want to rescale PAL8 subtitle bitmaps where
> > the palette
> > > includes
> > > > colors with alpha.
> > > >
> > > > From what I’ve seen, swscale doesn’t support PAL8-to-PAL8, only
> > PAL8-to-
> > > BGR8
> > > > which doesn’t support alpha and the palette is fixed with 256
> > entries
> > > defined by
> > > > convention, while I would ideally like to be able to allow the
> > following:
> > > >
> > > > - constrain the output to use the same palette as the input
> > > > - adaptively quantize it to a palette with a configurable number
> > of colors
> > > >
> > > > Thus it's about the palette quantization (with or without
> > dithering) after
> > > > scaling in RGBA. (or some cool algorithmic trick I'm not aware
> > of)
> > > >
> > > > Is there any existing code that I could reuse? The closest I
> > could find
> > > > is pngenc, but I'm wondering whether there's something
> > else/better
> > > > somewhere in the ffmpeg libs that I haven't seen?
> > >
> > > There are some non linear scaling filters which may make sense when
> > you do
> > > not have the full linear space available see:
> > > hqx, epx, xbr
> > > you could also try some neural net stuff
> >
> > Photoshop can perfectly do what is needed, but their algorithms are
> > not
> > public.
>
> I've put a few thing together to illustrate what I'm talking about:
>
> https://gist.github.com/softworkz/deef5c2a43d3d629c3e17f9e21544a8f
>
>
> Meanwhile I found what I need: https://github.com/ImageOptim/libimagequant
>
> Interestingly, they are comparing their lib specifically to the
> Photoshop feature that I mentioned: https://pngquant.org/vsphotoshop.html
> In the 2000's, the PS implementation for image quantization, optimization
> and compression (profanely named "Save for Web") had remained
> unparalleled for years, that's why it was one of my first thoughts.
>
> I hadn't heard about libimagequant before, but it seems to do exactly
> what is needed for rescaling PAL8 to PAL8 at a high quality.
>
> Before spending any time on it, I wanted ask whether that library
> would be acceptable for adding it as a (GPLv3) reference to the
> project and as a dependency to my filter?
>

External dependencies for what is supposed to be a rather base feature
are not ideal.
I know people have done some work in the past for palette generation
for GIF encoding, which looked like it was generating decent images.
Ideally that should be used and improved if necessary.

- Hendrik
___
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/3] avcodec/siren: prevent getbitcontext overread

[Peter Ross]

On Sat, Sep 18, 2021 at 08:01:38PM +1000, Peter Ross wrote:
> ---
>  libavcodec/siren.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/siren.c b/libavcodec/siren.c
> index 2161b29a2c..3b0ad7b642 100644
> --- a/libavcodec/siren.c
> +++ b/libavcodec/siren.c
> @@ -608,12 +608,16 @@ static int decode_vector(SirenContext *s, int 
> number_of_regions,
>  
>  index >>= 1;
>  
> -if (error == 0 && get_bits_left(gb) >= 0) {
> +if (error == 0) {
>  for (j = 0; j < vector_dimension[category]; j++) {
>  decoded_value = mlt_quant[category][index & ((1 << 
> index_table[category]) - 1)];
>  index >>= index_table[category];
>  
>  if (decoded_value) {
> +if (get_bits_left(gb) <= 0) {
> +error = 1;
> +break;
> +}
>  if (!get_bits1(gb))
>  decoded_value *= 
> -decoder_standard_deviation[region];
>  else

ping

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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] avfilter/vf_avgblur: switch to faster algorithm

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavfilter/vf_avgblur.c | 311 +--
 1 file changed, 171 insertions(+), 140 deletions(-)

diff --git a/libavfilter/vf_avgblur.c b/libavfilter/vf_avgblur.c
index 3e222a43fa..a838285bb4 100644
--- a/libavfilter/vf_avgblur.c
+++ b/libavfilter/vf_avgblur.c
@@ -20,6 +20,7 @@
  * SOFTWARE.
  */
 
+#include "libavutil/avassert.h"
 #include "libavutil/imgutils.h"
 #include "libavutil/opt.h"
 #include "libavutil/pixdesc.h"
@@ -36,13 +37,15 @@ typedef struct AverageBlurContext {
 int planes;
 
 int depth;
+int max;
+int area;
 int planewidth[4];
 int planeheight[4];
-float *buffer;
+void *buffer;
+uint16_t lut[256 * 256 * 256];
 int nb_planes;
 
-int (*filter_horizontally)(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs);
-int (*filter_vertically)(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs);
+int (*filter[2])(AVFilterContext *ctx, void *arg, int jobnr, int nb_jobs);
 } AverageBlurContext;
 
 #define OFFSET(x) offsetof(AverageBlurContext, x)
@@ -60,124 +63,138 @@ AVFILTER_DEFINE_CLASS(avgblur);
 typedef struct ThreadData {
 int height;
 int width;
-uint8_t *ptr;
-int linesize;
+const void *ptr;
+void *dptr;
+int linesize, dlinesize;
 } ThreadData;
 
-#define HORIZONTAL_FILTER(name, type)  
   \
-static int filter_horizontally_##name(AVFilterContext *ctx, void *arg, int 
jobnr, int nb_jobs)\
-{  
   \
-AverageBlurContext *s = ctx->priv; 
   \
-ThreadData *td = arg;  
   \
-const int height = td->height; 
   \
-const int width = td->width;   
   \
-const int slice_start = (height *  jobnr   ) / nb_jobs;
   \
-const int slice_end   = (height * (jobnr+1)) / nb_jobs;
   \
-const int radius = FFMIN(s->radius, width / 2);
   \
-const int linesize = td->linesize / sizeof(type);  
   \
-float *buffer = s->buffer; 
   \
-const type *src;   
   \
-float *ptr;
   \
-int y, x;  
   \
-   
   \
-/* Filter horizontally along each row */   
   \
-for (y = slice_start; y < slice_end; y++) {
   \
-float acc = 0; 
   \
-int count = 0; 
   \
-   
   \
-src = (const type *)td->ptr + linesize * y;
   \
-ptr = buffer + width * y;  
   \
-   
   \
-for (x = 0; x < radius; x++) { 
   \
-acc += src[x]; 
   \
-}  
   \
-count += radius;   
   \
-   
   \
-for (x = 0; x <= radius; x++) {
   \
-acc += src[x + radius];
   \
-count++;   
   \
-ptr[x] = acc / count;  
   \
-}  
   \
-   
   \
-for (; x < width - radius; x++) {  
   \
-acc += src[x + radius] - src[x - radius - 1];  
   \
-ptr[x] = acc / count;  

Re: [FFmpeg-devel] [PATCH v2 6/6] avcodec/libsvtav1: support constant quality mode

[Jan Ekström]

On Sat, Sep 25, 2021 at 4:06 AM  wrote:
>
> On Thu, Sep 23, 2021 at 09:45:48AM -0400, Christopher Degawa wrote:
> > On Sun, Sep 19, 2021 at 2:02 PM Christopher Degawa 
> > wrote:
> >
> > >
> > >
> > > On Fri, Sep 17, 2021 at 9:28 PM  wrote:
> > >
> > >> From: Limin Wang 
> > >>
> > >> Signed-off-by: Limin Wang 
> > >>
> > > As a note, I personally favor this patch over mine since I don't think
> > > `enable_tpl_la` is worth exposing to the user if its main role is to 
> > > switch
> > > between crf and cqp
> > >
> >
> > Ping on this patch, this has been requested on SVT-AV1's side as well
>
> For Jan haven't further comments, I Will apply the patchset tomorrow unless
> there are objections.

There are probably patches in this set which can be applied (like the
open/closed GOP thing, IIRC), but please do not apply the whole set.

It's kind of important we don't make this wrapper even more of a mess
than it is right now.

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

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

Re: [FFmpeg-devel] [PATCH v2 1/6] avcodec/libsvtav1: Fix override setting of caps_internal

[Jan Ekström]

On Sat, Sep 18, 2021 at 4:27 AM  wrote:
>
> From: Limin Wang 
>
> Signed-off-by: Limin Wang 

I'd prefer the wording "fix duplicate definition of caps_internal",
but otherwise this patch is LGTM.

Good catch.

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

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

Re: [FFmpeg-devel] [PATCH v2 2/6] avcodec/libsvtav1: make coded GOP type configurable

[Jan Ekström]

On Sat, Sep 18, 2021 at 4:27 AM  wrote:
>
> From: Limin Wang 
>
> Reviewed-by: Jan Ekström 
> Signed-off-by: Limin Wang 

I still hate how SVT-AV1 has no enum/defines for these, but so be it :)

LGTM.

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

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

Re: [FFmpeg-devel] [PATCH v2 3/6] doc: update for libsvtav1 encoder

[Jan Ekström]

On Sat, Sep 18, 2021 at 4:27 AM  wrote:
>
> From: Limin Wang 
>
> Signed-off-by: Limin Wang 
> ---

Hi,

"doc/encoders: add available values for libsvtav1 options"

would possibly be better as a commit message?

>  doc/encoders.texi | 44 
>  1 file changed, 44 insertions(+)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index 8fccd73..64d604e 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -1750,12 +1750,56 @@ You need to explicitly configure the build with 
> @code{--enable-libsvtav1}.
>  @table @option
>  @item profile
>  Set the encoding profile.
> +@table @samp
> +@item main
> +@item high
> +@item professional
> +@end table
>
>  @item level
>  Set the operating point level.
> +@table @samp
> +@item 2.0
> +@item 2.1
> +@item 2.2
> +@item 2.3
> +@item 3.0
> +@item 3.1
> +@item 3.2
> +@item 3.3
> +@item 4.0
> +@item 4.1
> +@item 4.2
> +@item 4.3
> +@item 5.0
> +@item 5.1
> +@item 5.2
> +@item 5.3
> +@item 6.0
> +@item 6.1
> +@item 6.2
> +@item 6.3
> +@item 7.0
> +@item 7.1
> +@item 7.2
> +@item 7.3
> +@end table
> +

The levels list is somewhat long, and it's specific to AV1 and not
this encoder. I don't think we list H.264/HEVC etc levels, either?

So I'm not 100% sure on this bit, possibly just noting "Set the
operating point level, f.ex. '4.0'." is good enough?

> +@item hielevel
> +Set the Hierarchical prediction levels.
> +@table @samp
> +@item 3level
> +@item 4level, This is the default.

You probably mean this to be on a separate line. Right now it ends up
as part of the entry on the list a la: ‘4level, This is the default.’

Noticed through the HTML documentation output (ffmpeg-codecs.html).

> +@end table
>
>  @item tier
>  Set the operating point tier.
> +@table @samp
> +@item main
> +The main tier was designed for most applications. This is the default.
> +@item high
> +The high tier was designed for very demanding applications.
> +@end table
>

Looking at https://aomediacodec.github.io/av1-spec/av1-spec.pdf , it
seems like the high tier only enable higher bit rates/lower
compression ratios in levels.

I think explaining it like that is probably more understandable than
vague references for "most applications" and "very demanding
applications". Or only explaining which one is the default, as I would
expect a person who needs to set this flag to know what the tier flags
in AV1 bit stream mean.

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

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

Re: [FFmpeg-devel] [PATCH v2 4/6] avcodec/libsvtav1: Fix CQP mode doesn't work as expection

[Jan Ekström]

On Sat, Sep 18, 2021 at 4:27 AM  wrote:
>
> From: Limin Wang 
>
> Signed-off-by: Limin Wang 
> ---

Commit message should probably be something along the lines of

"""
avcodec/libsvtav1: properly enforce CQP mode when set in wrapper

SVT-AV1 seems to have switched their default from CQP to CRF in February,
so enforce the controlling option accordingly.
"""

>  libavcodec/libsvtav1.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
> index 0dc25ca..b029e01 100644
> --- a/libavcodec/libsvtav1.c
> +++ b/libavcodec/libsvtav1.c
> @@ -208,6 +208,8 @@ static int config_enc_params(EbSvtAv1EncConfiguration 
> *param,
>  if (param->rate_control_mode) {
>  param->max_qp_allowed   = avctx->qmax;
>  param->min_qp_allowed   = avctx->qmin;
> +} else {
> +param->enable_tpl_la = 0; /* CQP need turn off enable_tp_la */

As the default changing in the underlying library has now shown us, I
think (for now) it's better to move this next to
param->rate_control_mode earlier in the function, and then do
something like:

param->enable_tpl_la = !!param->rate_control_mode;

(I would have utilized param->enable_tpl_la = param->rate_control_mode
== SVTAV1_RC_MODE_CQP;` but alas SVT-AV1 does not have such
enums/defines that make such things more readable).

This way the parameter is set correctly no matter if the default is
switched over at SVT-AV1. In the future the wrapper can be reworked so
that by default SVT-AV1's own rate control defaults are utilized, and
then if either bit rate or cqp or something like that is set, we can
start enforcing that.

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

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

Re: [FFmpeg-devel] [PATCH v2 5/6] avcodec/libsvtav1: Fix the max range for rc_mode

[Jan Ekström]

On Sat, Sep 18, 2021 at 4:27 AM  wrote:
>
> From: Limin Wang 
>
> Signed-off-by: Limin Wang 
> ---

Probably something like "avcodec/libsvtav1: fix value range for
rc_mode" is a bit better as a commit message?

>  libavcodec/libsvtav1.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
> index b029e01..509d92d 100644
> --- a/libavcodec/libsvtav1.c
> +++ b/libavcodec/libsvtav1.c
> @@ -522,7 +522,7 @@ static const AVOption options[] = {
>  #undef LEVEL
>
>  { "rc", "Bit rate control mode", OFFSET(rc_mode),
> -  AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 3, VE , "rc"},
> +  AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 2, VE , "rc"},

And here we have another example of why bare numbers are bad :) .
Thanks for catching this.

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

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

Re: [FFmpeg-devel] [PATCH v2 6/6] avcodec/libsvtav1: support constant quality mode

[Jan Ekström]

On Thu, Sep 23, 2021 at 6:08 PM  wrote:
>
> On Thu, Sep 23, 2021 at 05:11:49PM +0300, Jan Ekström wrote:
> > On Thu, Sep 23, 2021 at 4:46 PM Christopher Degawa  
> > wrote:
> > >
> > > On Sun, Sep 19, 2021 at 2:02 PM Christopher Degawa 
> > > wrote:
> > >
> > > >
> > > >
> > > > On Fri, Sep 17, 2021 at 9:28 PM  wrote:
> > > >
> > > >> From: Limin Wang 
> > > >>
> > > >> Signed-off-by: Limin Wang 
> > > >>
> > > > As a note, I personally favor this patch over mine since I don't think
> > > > `enable_tpl_la` is worth exposing to the user if its main role is to 
> > > > switch
> > > > between crf and cqp
> > > >
> > >
> > > Ping on this patch, this has been requested on SVT-AV1's side as well
> >
> > I think my further comments on the previous version were mostly to
> > move off from the rc option for rate control, which has become more
> > and more seemingly unnecessary (and different from most other encoders
> > for no obvious reason).
> >
> > The only option that with a quick look doesn't match just setting
> > quantizer|bit rate|CRF is "cvbr", but it doesn't seem to be impossible
> > to either rework "rc" for it, or to utilize a separate option for it.
>
> Do you think it's OK to remove the rc option? to match other encoders,
> We can choose the rate control by the related parameters like:
>
> if (crf >= 0)
> choose crf rate control;
> else if (bitrate > 0)
> choose cvbr rate control;
> else if (cqp >=0 )
> choose cqp rate control;
>

In general that is the idea, yes (except bit rate would mean either
vbr or cvbr). It would be nice to follow whatever is the default on
SVT-AV1's side by default, and then if the user specifies a rate
control mode that is not the default, his selection is honored. Not
sure what the best way for that is to be honest. Possibly the style of
setting AVCodecDefault a la libx265?

For the rc option, given how much SVT-AV1 itself is in flux, I would
be OK with removing the option, or making it an option that decides
between cvbr and vbr (essentially making it "VBR bit rate control
mode"). I wish cvbr would instead be something like VBV/HRD elsewhere,
so we could just utilize maxrate&bufsize for controlling it, instead
of having it as another discrete rate control mode.

As these things change, I also hope that SVT-AV1 will soon get a
key=value style of option API, that way the wrapper will not have to
be updated constantly according to the changes in the library :) . As
I feel SVT-AV1 will be changed quite a bit in the future (due to its
recent age).

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

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

Re: [FFmpeg-devel] [PATCH v2 1/6] avcodec/libsvtav1: Fix override setting of caps_internal

[lance . lmwang]

On Sat, Sep 25, 2021 at 01:00:20PM +0300, Jan Ekström wrote:
> On Sat, Sep 18, 2021 at 4:27 AM  wrote:
> >
> > From: Limin Wang 
> >
> > Signed-off-by: Limin Wang 
> 
> I'd prefer the wording "fix duplicate definition of caps_internal",
> but otherwise this patch is LGTM.

No problem, will update with your wording.

> 
> Good catch.
> 
> Jan
> ___
> 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".

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

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

Re: [FFmpeg-devel] [PATCH v2 1/6] avcodec/libsvtav1: Fix override setting of caps_internal

[Jan Ekström]

On Sat, Sep 25, 2021 at 3:49 PM  wrote:
>
> On Sat, Sep 25, 2021 at 01:00:20PM +0300, Jan Ekström wrote:
> > On Sat, Sep 18, 2021 at 4:27 AM  wrote:
> > >
> > > From: Limin Wang 
> > >
> > > Signed-off-by: Limin Wang 
> >
> > I'd prefer the wording "fix duplicate definition of caps_internal",
> > but otherwise this patch is LGTM.
>
> No problem, will update with your wording.
>

For the record, those where the only comment is regarding the commit
message, I think it's at this point fair to just pull those in, so we
can make this patch set smaller on the ML :) .

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

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

Re: [FFmpeg-devel] [PATCH v2 3/6] doc: update for libsvtav1 encoder

[lance . lmwang]

On Sat, Sep 25, 2021 at 02:32:43PM +0300, Jan Ekström wrote:
> On Sat, Sep 18, 2021 at 4:27 AM  wrote:
> >
> > From: Limin Wang 
> >
> > Signed-off-by: Limin Wang 
> > ---
> 
> Hi,
> 
> "doc/encoders: add available values for libsvtav1 options"
> 
> would possibly be better as a commit message?

Sure, I'll change that.

> 
> >  doc/encoders.texi | 44 
> >  1 file changed, 44 insertions(+)
> >
> > diff --git a/doc/encoders.texi b/doc/encoders.texi
> > index 8fccd73..64d604e 100644
> > --- a/doc/encoders.texi
> > +++ b/doc/encoders.texi
> > @@ -1750,12 +1750,56 @@ You need to explicitly configure the build with 
> > @code{--enable-libsvtav1}.
> >  @table @option
> >  @item profile
> >  Set the encoding profile.
> > +@table @samp
> > +@item main
> > +@item high
> > +@item professional
> > +@end table
> >
> >  @item level
> >  Set the operating point level.
> > +@table @samp
> > +@item 2.0
> > +@item 2.1
> > +@item 2.2
> > +@item 2.3
> > +@item 3.0
> > +@item 3.1
> > +@item 3.2
> > +@item 3.3
> > +@item 4.0
> > +@item 4.1
> > +@item 4.2
> > +@item 4.3
> > +@item 5.0
> > +@item 5.1
> > +@item 5.2
> > +@item 5.3
> > +@item 6.0
> > +@item 6.1
> > +@item 6.2
> > +@item 6.3
> > +@item 7.0
> > +@item 7.1
> > +@item 7.2
> > +@item 7.3
> > +@end table
> > +
> 
> The levels list is somewhat long, and it's specific to AV1 and not
> this encoder. I don't think we list H.264/HEVC etc levels, either?
> 
> So I'm not 100% sure on this bit, possibly just noting "Set the
> operating point level, f.ex. '4.0'." is good enough?

Yes, I think it's too long also. I can update by your idea.

> 
> > +@item hielevel
> > +Set the Hierarchical prediction levels.
> > +@table @samp
> > +@item 3level
> > +@item 4level, This is the default.
> 
> You probably mean this to be on a separate line. Right now it ends up
> as part of the entry on the list a la: ‘4level, This is the default.’
> 
> Noticed through the HTML documentation output (ffmpeg-codecs.html).

OK, will change that

> 
> > +@end table
> >
> >  @item tier
> >  Set the operating point tier.
> > +@table @samp
> > +@item main
> > +The main tier was designed for most applications. This is the default.
> > +@item high
> > +The high tier was designed for very demanding applications.
> > +@end table
> >
> 
> Looking at https://aomediacodec.github.io/av1-spec/av1-spec.pdf , it
> seems like the high tier only enable higher bit rates/lower
> compression ratios in levels.
> 
> I think explaining it like that is probably more understandable than
> vague references for "most applications" and "very demanding
> applications". Or only explaining which one is the default, as I would
> expect a person who needs to set this flag to know what the tier flags
> in AV1 bit stream mean.

OK, will only explaining which one is the default.

> 
> Jan
> ___
> 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".

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

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

Re: [FFmpeg-devel] [PATCH v2 4/6] avcodec/libsvtav1: Fix CQP mode doesn't work as expection

[lance . lmwang]

On Sat, Sep 25, 2021 at 03:06:23PM +0300, Jan Ekström wrote:
> On Sat, Sep 18, 2021 at 4:27 AM  wrote:
> >
> > From: Limin Wang 
> >
> > Signed-off-by: Limin Wang 
> > ---
> 
> Commit message should probably be something along the lines of
> 
> """
> avcodec/libsvtav1: properly enforce CQP mode when set in wrapper
> 
> SVT-AV1 seems to have switched their default from CQP to CRF in February,
> so enforce the controlling option accordingly.
> """

Sure, I'll update it by your suggestion.

> 
> >  libavcodec/libsvtav1.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
> > index 0dc25ca..b029e01 100644
> > --- a/libavcodec/libsvtav1.c
> > +++ b/libavcodec/libsvtav1.c
> > @@ -208,6 +208,8 @@ static int config_enc_params(EbSvtAv1EncConfiguration 
> > *param,
> >  if (param->rate_control_mode) {
> >  param->max_qp_allowed   = avctx->qmax;
> >  param->min_qp_allowed   = avctx->qmin;
> > +} else {
> > +param->enable_tpl_la = 0; /* CQP need turn off enable_tp_la */
> 
> As the default changing in the underlying library has now shown us, I
> think (for now) it's better to move this next to
> param->rate_control_mode earlier in the function, and then do
> something like:
> 
> param->enable_tpl_la = !!param->rate_control_mode;

Yes, It's better idea. I'll update by your suggestion.

> 
> (I would have utilized param->enable_tpl_la = param->rate_control_mode
> == SVTAV1_RC_MODE_CQP;` but alas SVT-AV1 does not have such
> enums/defines that make such things more readable).
> 
> This way the parameter is set correctly no matter if the default is
> switched over at SVT-AV1. In the future the wrapper can be reworked so
> that by default SVT-AV1's own rate control defaults are utilized, and
> then if either bit rate or cqp or something like that is set, we can
> start enforcing that.
> 
> Jan
> ___
> 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".

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

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

Re: [FFmpeg-devel] [PATCH v2 5/6] avcodec/libsvtav1: Fix the max range for rc_mode

[lance . lmwang]

On Sat, Sep 25, 2021 at 03:14:34PM +0300, Jan Ekström wrote:
> On Sat, Sep 18, 2021 at 4:27 AM  wrote:
> >
> > From: Limin Wang 
> >
> > Signed-off-by: Limin Wang 
> > ---
> 
> Probably something like "avcodec/libsvtav1: fix value range for
> rc_mode" is a bit better as a commit message?

OK, will change that.

> 
> >  libavcodec/libsvtav1.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
> > index b029e01..509d92d 100644
> > --- a/libavcodec/libsvtav1.c
> > +++ b/libavcodec/libsvtav1.c
> > @@ -522,7 +522,7 @@ static const AVOption options[] = {
> >  #undef LEVEL
> >
> >  { "rc", "Bit rate control mode", OFFSET(rc_mode),
> > -  AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 3, VE , "rc"},
> > +  AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 2, VE , "rc"},
> 
> And here we have another example of why bare numbers are bad :) .
> Thanks for catching this.
> 
> Jan
> ___
> 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".

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

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

Re: [FFmpeg-devel] [PATCH v2 1/6] avcodec/libsvtav1: Fix override setting of caps_internal

[lance . lmwang]

On Sat, Sep 25, 2021 at 03:59:20PM +0300, Jan Ekström wrote:
> On Sat, Sep 25, 2021 at 3:49 PM  wrote:
> >
> > On Sat, Sep 25, 2021 at 01:00:20PM +0300, Jan Ekström wrote:
> > > On Sat, Sep 18, 2021 at 4:27 AM  wrote:
> > > >
> > > > From: Limin Wang 
> > > >
> > > > Signed-off-by: Limin Wang 
> > >
> > > I'd prefer the wording "fix duplicate definition of caps_internal",
> > > but otherwise this patch is LGTM.
> >
> > No problem, will update with your wording.
> >
> 
> For the record, those where the only comment is regarding the commit
> message, I think it's at this point fair to just pull those in, so we
> can make this patch set smaller on the ML :) .

Sure, I'll applied patch 1,2,5, other patchset will update for reviewing

> 
> Jan
> ___
> 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".

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

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

Re: [FFmpeg-devel] [PATCH v2 6/6] avcodec/libsvtav1: support constant quality mode

[lance . lmwang]

On Sat, Sep 25, 2021 at 03:35:53PM +0300, Jan Ekström wrote:
> On Thu, Sep 23, 2021 at 6:08 PM  wrote:
> >
> > On Thu, Sep 23, 2021 at 05:11:49PM +0300, Jan Ekström wrote:
> > > On Thu, Sep 23, 2021 at 4:46 PM Christopher Degawa  
> > > wrote:
> > > >
> > > > On Sun, Sep 19, 2021 at 2:02 PM Christopher Degawa 
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > > On Fri, Sep 17, 2021 at 9:28 PM  wrote:
> > > > >
> > > > >> From: Limin Wang 
> > > > >>
> > > > >> Signed-off-by: Limin Wang 
> > > > >>
> > > > > As a note, I personally favor this patch over mine since I don't think
> > > > > `enable_tpl_la` is worth exposing to the user if its main role is to 
> > > > > switch
> > > > > between crf and cqp
> > > > >
> > > >
> > > > Ping on this patch, this has been requested on SVT-AV1's side as well
> > >
> > > I think my further comments on the previous version were mostly to
> > > move off from the rc option for rate control, which has become more
> > > and more seemingly unnecessary (and different from most other encoders
> > > for no obvious reason).
> > >
> > > The only option that with a quick look doesn't match just setting
> > > quantizer|bit rate|CRF is "cvbr", but it doesn't seem to be impossible
> > > to either rework "rc" for it, or to utilize a separate option for it.
> >
> > Do you think it's OK to remove the rc option? to match other encoders,
> > We can choose the rate control by the related parameters like:
> >
> > if (crf >= 0)
> > choose crf rate control;
> > else if (bitrate > 0)
> > choose cvbr rate control;
> > else if (cqp >=0 )
> > choose cqp rate control;
> >
> 
> In general that is the idea, yes (except bit rate would mean either
> vbr or cvbr). It would be nice to follow whatever is the default on
> SVT-AV1's side by default, and then if the user specifies a rate
> control mode that is not the default, his selection is honored. Not
> sure what the best way for that is to be honest. Possibly the style of
> setting AVCodecDefault a la libx265?
> 
> For the rc option, given how much SVT-AV1 itself is in flux, I would
> be OK with removing the option, or making it an option that decides
> between cvbr and vbr (essentially making it "VBR bit rate control
> mode"). I wish cvbr would instead be something like VBV/HRD elsewhere,
> so we could just utilize maxrate&bufsize for controlling it, instead
> of having it as another discrete rate control mode.

Yes, I think it's preferable to use utilize maxrate&bufsize to control
cbr and vbr as most of encoder. Then I'll follow this direction to update
the patch.

> 
> As these things change, I also hope that SVT-AV1 will soon get a
> key=value style of option API, that way the wrapper will not have to
> be updated constantly according to the changes in the library :) . As
> I feel SVT-AV1 will be changed quite a bit in the future (due to its
> recent age).
>

Yes, it's good to add svtav1-opts so that we can utilize the update options
directly. 

> Jan
> ___
> 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".

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

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

Re: [FFmpeg-devel] [PATCH v2 6/6] avcodec/libsvtav1: support constant quality mode

[Jan Ekström]

On Sat, Sep 25, 2021 at 4:35 PM  wrote:
>
> On Sat, Sep 25, 2021 at 03:35:53PM +0300, Jan Ekström wrote:
> > On Thu, Sep 23, 2021 at 6:08 PM  wrote:
> > >
> > > On Thu, Sep 23, 2021 at 05:11:49PM +0300, Jan Ekström wrote:
> > > > On Thu, Sep 23, 2021 at 4:46 PM Christopher Degawa 
> > > >  wrote:
> > > > >
> > > > > On Sun, Sep 19, 2021 at 2:02 PM Christopher Degawa 
> > > > > 
> > > > > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Sep 17, 2021 at 9:28 PM  wrote:
> > > > > >
> > > > > >> From: Limin Wang 
> > > > > >>
> > > > > >> Signed-off-by: Limin Wang 
> > > > > >>
> > > > > > As a note, I personally favor this patch over mine since I don't 
> > > > > > think
> > > > > > `enable_tpl_la` is worth exposing to the user if its main role is 
> > > > > > to switch
> > > > > > between crf and cqp
> > > > > >
> > > > >
> > > > > Ping on this patch, this has been requested on SVT-AV1's side as well
> > > >
> > > > I think my further comments on the previous version were mostly to
> > > > move off from the rc option for rate control, which has become more
> > > > and more seemingly unnecessary (and different from most other encoders
> > > > for no obvious reason).
> > > >
> > > > The only option that with a quick look doesn't match just setting
> > > > quantizer|bit rate|CRF is "cvbr", but it doesn't seem to be impossible
> > > > to either rework "rc" for it, or to utilize a separate option for it.
> > >
> > > Do you think it's OK to remove the rc option? to match other encoders,
> > > We can choose the rate control by the related parameters like:
> > >
> > > if (crf >= 0)
> > > choose crf rate control;
> > > else if (bitrate > 0)
> > > choose cvbr rate control;
> > > else if (cqp >=0 )
> > > choose cqp rate control;
> > >
> >
> > In general that is the idea, yes (except bit rate would mean either
> > vbr or cvbr). It would be nice to follow whatever is the default on
> > SVT-AV1's side by default, and then if the user specifies a rate
> > control mode that is not the default, his selection is honored. Not
> > sure what the best way for that is to be honest. Possibly the style of
> > setting AVCodecDefault a la libx265?
> >
> > For the rc option, given how much SVT-AV1 itself is in flux, I would
> > be OK with removing the option, or making it an option that decides
> > between cvbr and vbr (essentially making it "VBR bit rate control
> > mode"). I wish cvbr would instead be something like VBV/HRD elsewhere,
> > so we could just utilize maxrate&bufsize for controlling it, instead
> > of having it as another discrete rate control mode.
>
> Yes, I think it's preferable to use utilize maxrate&bufsize to control
> cbr and vbr as most of encoder. Then I'll follow this direction to update
> the patch.
>

Unfortunately that was just wishful thinking :) .

Unless you can set the buffer size and max rate in SVT-AV1, of course.
With the limited looking I've done CVBR just uses the bit rate for
each GOP instead of average over the whole clip.

> >
> > As these things change, I also hope that SVT-AV1 will soon get a
> > key=value style of option API, that way the wrapper will not have to
> > be updated constantly according to the changes in the library :) . As
> > I feel SVT-AV1 will be changed quite a bit in the future (due to its
> > recent age).
> >
>
> Yes, it's good to add svtav1-opts so that we can utilize the update options
> directly.
>

Let's go with -params ;) Since that is what modules seem to have
standardized on (x264|x265|rav1e|aom) :)

But that is anyways in the future, since SVT-AV1 doesn't have such an
API yet (as far as I know).

Jan
___
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 v3 1/2] doc/encoders: add available values for libsvtav1 options

[lance . lmwang]

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 doc/encoders.texi | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 8fccd73..8a7589c 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1750,12 +1750,30 @@ You need to explicitly configure the build with 
@code{--enable-libsvtav1}.
 @table @option
 @item profile
 Set the encoding profile.
+@table @samp
+@item main
+@item high
+@item professional
+@end table
 
 @item level
-Set the operating point level.
+Set the operating point level. For example: '4.0'
+
+@item hielevel
+Set the Hierarchical prediction levels.
+@table @samp
+@item 3level
+@item 4level
+This is the default.
+@end table
 
 @item tier
 Set the operating point tier.
+@table @samp
+@item main
+This is the default.
+@item high
+@end table
 
 @item rc
 Set the rate control mode to use.
-- 
1.8.3.1

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

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

[FFmpeg-devel] [PATCH v3 2/2] avcodec/libsvtav1: properly enforce CQP mode when set in wrapper

[lance . lmwang]

From: Limin Wang 

SVT-AV1 seems to have switched their default from CQP to CRF in February,
so enforce the controlling option accordingly.

Signed-off-by: Limin Wang 
---
 libavcodec/libsvtav1.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index a02ba6a..6196da2 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -205,6 +205,7 @@ static int config_enc_params(EbSvtAv1EncConfiguration 
*param,
 param->frame_rate_denominator = avctx->time_base.num * 
avctx->ticks_per_frame;
 }
 
+param->enable_tpl_la = !!param->rate_control_mode;
 if (param->rate_control_mode) {
 param->max_qp_allowed   = avctx->qmax;
 param->min_qp_allowed   = avctx->qmin;
-- 
1.8.3.1

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

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

Re: [FFmpeg-devel] [PATCH v2 6/6] avcodec/libsvtav1: support constant quality mode

[lance . lmwang]

On Sat, Sep 25, 2021 at 04:51:58PM +0300, Jan Ekström wrote:
> On Sat, Sep 25, 2021 at 4:35 PM  wrote:
> >
> > On Sat, Sep 25, 2021 at 03:35:53PM +0300, Jan Ekström wrote:
> > > On Thu, Sep 23, 2021 at 6:08 PM  wrote:
> > > >
> > > > On Thu, Sep 23, 2021 at 05:11:49PM +0300, Jan Ekström wrote:
> > > > > On Thu, Sep 23, 2021 at 4:46 PM Christopher Degawa 
> > > > >  wrote:
> > > > > >
> > > > > > On Sun, Sep 19, 2021 at 2:02 PM Christopher Degawa 
> > > > > > 
> > > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Sep 17, 2021 at 9:28 PM  wrote:
> > > > > > >
> > > > > > >> From: Limin Wang 
> > > > > > >>
> > > > > > >> Signed-off-by: Limin Wang 
> > > > > > >>
> > > > > > > As a note, I personally favor this patch over mine since I don't 
> > > > > > > think
> > > > > > > `enable_tpl_la` is worth exposing to the user if its main role is 
> > > > > > > to switch
> > > > > > > between crf and cqp
> > > > > > >
> > > > > >
> > > > > > Ping on this patch, this has been requested on SVT-AV1's side as 
> > > > > > well
> > > > >
> > > > > I think my further comments on the previous version were mostly to
> > > > > move off from the rc option for rate control, which has become more
> > > > > and more seemingly unnecessary (and different from most other encoders
> > > > > for no obvious reason).
> > > > >
> > > > > The only option that with a quick look doesn't match just setting
> > > > > quantizer|bit rate|CRF is "cvbr", but it doesn't seem to be impossible
> > > > > to either rework "rc" for it, or to utilize a separate option for it.
> > > >
> > > > Do you think it's OK to remove the rc option? to match other encoders,
> > > > We can choose the rate control by the related parameters like:
> > > >
> > > > if (crf >= 0)
> > > > choose crf rate control;
> > > > else if (bitrate > 0)
> > > > choose cvbr rate control;
> > > > else if (cqp >=0 )
> > > > choose cqp rate control;
> > > >
> > >
> > > In general that is the idea, yes (except bit rate would mean either
> > > vbr or cvbr). It would be nice to follow whatever is the default on
> > > SVT-AV1's side by default, and then if the user specifies a rate
> > > control mode that is not the default, his selection is honored. Not
> > > sure what the best way for that is to be honest. Possibly the style of
> > > setting AVCodecDefault a la libx265?
> > >
> > > For the rc option, given how much SVT-AV1 itself is in flux, I would
> > > be OK with removing the option, or making it an option that decides
> > > between cvbr and vbr (essentially making it "VBR bit rate control
> > > mode"). I wish cvbr would instead be something like VBV/HRD elsewhere,
> > > so we could just utilize maxrate&bufsize for controlling it, instead
> > > of having it as another discrete rate control mode.
> >
> > Yes, I think it's preferable to use utilize maxrate&bufsize to control
> > cbr and vbr as most of encoder. Then I'll follow this direction to update
> > the patch.
> >
> 
> Unfortunately that was just wishful thinking :) .
> 
> Unless you can set the buffer size and max rate in SVT-AV1, of course.
> With the limited looking I've done CVBR just uses the bit rate for
> each GOP instead of average over the whole clip.

As it's not very clear yet, so I'll not update this patch anymore.

> 
> > >
> > > As these things change, I also hope that SVT-AV1 will soon get a
> > > key=value style of option API, that way the wrapper will not have to
> > > be updated constantly according to the changes in the library :) . As
> > > I feel SVT-AV1 will be changed quite a bit in the future (due to its
> > > recent age).
> > >
> >
> > Yes, it's good to add svtav1-opts so that we can utilize the update options
> > directly.
> >
> 
> Let's go with -params ;) Since that is what modules seem to have
> standardized on (x264|x265|rav1e|aom) :)
> 
> But that is anyways in the future, since SVT-AV1 doesn't have such an
> API yet (as far as I know).

I think I have tried to add new options half year again, there are willing to
hold and let to wait for the params API.

> 
> Jan
> ___
> 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".

-- 
Thanks,
Limin Wang
___
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] Scaling PAL8 images with alpha

[Michael Niedermayer]

On Sat, Sep 25, 2021 at 10:23:56AM +0200, Hendrik Leppkes wrote:
> On Sat, Sep 25, 2021 at 5:00 AM Soft Works  wrote:
> >
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of
> > > Soft Works
> > > Sent: Friday, 24 September 2021 19:03
> > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: ffmpeg-devel  On Behalf Of
> > > Michael
> > > > Niedermayer
> > > > Sent: Friday, 24 September 2021 17:40
> > > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> > > >
> > > > On Fri, Sep 24, 2021 at 10:30:31AM +, Soft Works wrote:
> > > > > Hi,
> > > > >
> > > > > for a new filter, I want to rescale PAL8 subtitle bitmaps where
> > > the palette
> > > > includes
> > > > > colors with alpha.
> > > > >
> > > > > From what I’ve seen, swscale doesn’t support PAL8-to-PAL8, only
> > > PAL8-to-
> > > > BGR8
> > > > > which doesn’t support alpha and the palette is fixed with 256
> > > entries
> > > > defined by
> > > > > convention, while I would ideally like to be able to allow the
> > > following:
> > > > >
> > > > > - constrain the output to use the same palette as the input
> > > > > - adaptively quantize it to a palette with a configurable number
> > > of colors
> > > > >
> > > > > Thus it's about the palette quantization (with or without
> > > dithering) after
> > > > > scaling in RGBA. (or some cool algorithmic trick I'm not aware
> > > of)
> > > > >
> > > > > Is there any existing code that I could reuse? The closest I
> > > could find
> > > > > is pngenc, but I'm wondering whether there's something
> > > else/better
> > > > > somewhere in the ffmpeg libs that I haven't seen?
> > > >
> > > > There are some non linear scaling filters which may make sense when
> > > you do
> > > > not have the full linear space available see:
> > > > hqx, epx, xbr
> > > > you could also try some neural net stuff
> > >
> > > Photoshop can perfectly do what is needed, but their algorithms are
> > > not
> > > public.
> >
> > I've put a few thing together to illustrate what I'm talking about:
> >
> > https://gist.github.com/softworkz/deef5c2a43d3d629c3e17f9e21544a8f
> >
> >
> > Meanwhile I found what I need: https://github.com/ImageOptim/libimagequant
> >
> > Interestingly, they are comparing their lib specifically to the
> > Photoshop feature that I mentioned: https://pngquant.org/vsphotoshop.html
> > In the 2000's, the PS implementation for image quantization, optimization
> > and compression (profanely named "Save for Web") had remained
> > unparalleled for years, that's why it was one of my first thoughts.
> >
> > I hadn't heard about libimagequant before, but it seems to do exactly
> > what is needed for rescaling PAL8 to PAL8 at a high quality.
> >
> > Before spending any time on it, I wanted ask whether that library
> > would be acceptable for adding it as a (GPLv3) reference to the
> > project and as a dependency to my filter?
> >
> 
> External dependencies for what is supposed to be a rather base feature
> are not ideal.

+1

i see no reason why this would need an external dependancy
we have filters implementing much more complex things than scaling a pal8
image

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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] Scaling PAL8 images with alpha

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Michael Niedermayer
> Sent: Saturday, 25 September 2021 16:30
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> 
> On Sat, Sep 25, 2021 at 10:23:56AM +0200, Hendrik Leppkes wrote:
> > On Sat, Sep 25, 2021 at 5:00 AM Soft Works 
> wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: ffmpeg-devel  On Behalf
> Of
> > > > Soft Works
> > > > Sent: Friday, 24 September 2021 19:03
> > > > To: FFmpeg development discussions and patches  > > > de...@ffmpeg.org>
> > > > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: ffmpeg-devel  On
> Behalf Of
> > > > Michael
> > > > > Niedermayer
> > > > > Sent: Friday, 24 September 2021 17:40
> > > > > To: FFmpeg development discussions and patches  > > > de...@ffmpeg.org>
> > > > > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> > > > >
> > > > > On Fri, Sep 24, 2021 at 10:30:31AM +, Soft Works wrote:
> > > > > > Hi,
> > > > > >
> > > > > > for a new filter, I want to rescale PAL8 subtitle bitmaps
> where
> > > > the palette
> > > > > includes
> > > > > > colors with alpha.
> > > > > >
> > > > > > From what I’ve seen, swscale doesn’t support PAL8-to-PAL8,
> only
> > > > PAL8-to-
> > > > > BGR8
> > > > > > which doesn’t support alpha and the palette is fixed with
> 256
> > > > entries
> > > > > defined by
> > > > > > convention, while I would ideally like to be able to allow
> the
> > > > following:
> > > > > >
> > > > > > - constrain the output to use the same palette as the input
> > > > > > - adaptively quantize it to a palette with a configurable
> number
> > > > of colors
> > > > > >
> > > > > > Thus it's about the palette quantization (with or without
> > > > dithering) after
> > > > > > scaling in RGBA. (or some cool algorithmic trick I'm not
> aware
> > > > of)
> > > > > >
> > > > > > Is there any existing code that I could reuse? The closest
> I
> > > > could find
> > > > > > is pngenc, but I'm wondering whether there's something
> > > > else/better
> > > > > > somewhere in the ffmpeg libs that I haven't seen?
> > > > >
> > > > > There are some non linear scaling filters which may make
> sense when
> > > > you do
> > > > > not have the full linear space available see:
> > > > > hqx, epx, xbr
> > > > > you could also try some neural net stuff
> > > >
> > > > Photoshop can perfectly do what is needed, but their algorithms
> are
> > > > not
> > > > public.
> > >
> > > I've put a few thing together to illustrate what I'm talking
> about:
> > >
> > >
> https://gist.github.com/softworkz/deef5c2a43d3d629c3e17f9e21544a8f
> > >
> > >
> > > Meanwhile I found what I need:
> https://github.com/ImageOptim/libimagequant
> > >
> > > Interestingly, they are comparing their lib specifically to the
> > > Photoshop feature that I mentioned:
> https://pngquant.org/vsphotoshop.html
> > > In the 2000's, the PS implementation for image quantization,
> optimization
> > > and compression (profanely named "Save for Web") had remained
> > > unparalleled for years, that's why it was one of my first
> thoughts.
> > >
> > > I hadn't heard about libimagequant before, but it seems to do
> exactly
> > > what is needed for rescaling PAL8 to PAL8 at a high quality.
> > >
> > > Before spending any time on it, I wanted ask whether that library
> > > would be acceptable for adding it as a (GPLv3) reference to the
> > > project and as a dependency to my filter?
> > >
> >
> > External dependencies for what is supposed to be a rather base
> feature
> > are not ideal.
> 
> +1
> 
> i see no reason why this would need an external dependancy
> we have filters implementing much more complex things than scaling a
> pal8
> image

I dislike GPL3 as well and needing a library for this might 
seem to be a bit too much for solving the problem.
I'm just not sure whether it can be solved easily. I mean it
can easily be solved in a basic way, but I'm not sure whether
it would be possible to achieve the same quality in results.

I've put up here some examples and also a comparison of results
from palettegen+paletteuse and Photoshop(which I assume to 
be at the same level of quality like libimagequant).

https://gist.github.com/softworkz/deef5c2a43d3d629c3e17f9e21544a8f


Earlier versions of the library were published under a BSD-like
license. Assuming it would do the job, would it be possible
to include that code? (I'm not an expert in these things)


Kind regards,
softworkz



___
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] Scaling PAL8 images with alpha

[Paul B Mahol]

On Sat, Sep 25, 2021 at 5:46 PM Soft Works  wrote:

>
>
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > Michael Niedermayer
> > Sent: Saturday, 25 September 2021 16:30
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> >
> > On Sat, Sep 25, 2021 at 10:23:56AM +0200, Hendrik Leppkes wrote:
> > > On Sat, Sep 25, 2021 at 5:00 AM Soft Works 
> > wrote:
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: ffmpeg-devel  On Behalf
> > Of
> > > > > Soft Works
> > > > > Sent: Friday, 24 September 2021 19:03
> > > > > To: FFmpeg development discussions and patches  > > > > de...@ffmpeg.org>
> > > > > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: ffmpeg-devel  On
> > Behalf Of
> > > > > Michael
> > > > > > Niedermayer
> > > > > > Sent: Friday, 24 September 2021 17:40
> > > > > > To: FFmpeg development discussions and patches  > > > > de...@ffmpeg.org>
> > > > > > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> > > > > >
> > > > > > On Fri, Sep 24, 2021 at 10:30:31AM +, Soft Works wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > for a new filter, I want to rescale PAL8 subtitle bitmaps
> > where
> > > > > the palette
> > > > > > includes
> > > > > > > colors with alpha.
> > > > > > >
> > > > > > > From what I’ve seen, swscale doesn’t support PAL8-to-PAL8,
> > only
> > > > > PAL8-to-
> > > > > > BGR8
> > > > > > > which doesn’t support alpha and the palette is fixed with
> > 256
> > > > > entries
> > > > > > defined by
> > > > > > > convention, while I would ideally like to be able to allow
> > the
> > > > > following:
> > > > > > >
> > > > > > > - constrain the output to use the same palette as the input
> > > > > > > - adaptively quantize it to a palette with a configurable
> > number
> > > > > of colors
> > > > > > >
> > > > > > > Thus it's about the palette quantization (with or without
> > > > > dithering) after
> > > > > > > scaling in RGBA. (or some cool algorithmic trick I'm not
> > aware
> > > > > of)
> > > > > > >
> > > > > > > Is there any existing code that I could reuse? The closest
> > I
> > > > > could find
> > > > > > > is pngenc, but I'm wondering whether there's something
> > > > > else/better
> > > > > > > somewhere in the ffmpeg libs that I haven't seen?
> > > > > >
> > > > > > There are some non linear scaling filters which may make
> > sense when
> > > > > you do
> > > > > > not have the full linear space available see:
> > > > > > hqx, epx, xbr
> > > > > > you could also try some neural net stuff
> > > > >
> > > > > Photoshop can perfectly do what is needed, but their algorithms
> > are
> > > > > not
> > > > > public.
> > > >
> > > > I've put a few thing together to illustrate what I'm talking
> > about:
> > > >
> > > >
> > https://gist.github.com/softworkz/deef5c2a43d3d629c3e17f9e21544a8f
> > > >
> > > >
> > > > Meanwhile I found what I need:
> > https://github.com/ImageOptim/libimagequant
> > > >
> > > > Interestingly, they are comparing their lib specifically to the
> > > > Photoshop feature that I mentioned:
> > https://pngquant.org/vsphotoshop.html
> > > > In the 2000's, the PS implementation for image quantization,
> > optimization
> > > > and compression (profanely named "Save for Web") had remained
> > > > unparalleled for years, that's why it was one of my first
> > thoughts.
> > > >
> > > > I hadn't heard about libimagequant before, but it seems to do
> > exactly
> > > > what is needed for rescaling PAL8 to PAL8 at a high quality.
> > > >
> > > > Before spending any time on it, I wanted ask whether that library
> > > > would be acceptable for adding it as a (GPLv3) reference to the
> > > > project and as a dependency to my filter?
> > > >
> > >
> > > External dependencies for what is supposed to be a rather base
> > feature
> > > are not ideal.
> >
> > +1
> >
> > i see no reason why this would need an external dependancy
> > we have filters implementing much more complex things than scaling a
> > pal8
> > image
>
> I dislike GPL3 as well and needing a library for this might
> seem to be a bit too much for solving the problem.
> I'm just not sure whether it can be solved easily. I mean it
> can easily be solved in a basic way, but I'm not sure whether
> it would be possible to achieve the same quality in results.
>
> I've put up here some examples and also a comparison of results
> from palettegen+paletteuse and Photoshop(which I assume to
> be at the same level of quality like libimagequant).
>
> https://gist.github.com/softworkz/deef5c2a43d3d629c3e17f9e21544a8f
>
>
> Earlier versions of the library were published under a BSD-like
> license. Assuming it would do the job, would it be possible
> to include that code? (I'm not an expert in these things)
>
>
So this is actually same thing? Why not improve existing filters in
libavfilter ins

[FFmpeg-devel] [PATCH v3 1/5] avformat/matroskadec: Parse Block Additional Mapping elements

[quietvoid]

Most of the implementation was done by the Plex developers.

Signed-off-by: quietvoid 
---
 libavformat/matroska.h|  7 +++
 libavformat/matroskadec.c | 44 +--
 2 files changed, 49 insertions(+), 2 deletions(-)

diff --git a/libavformat/matroska.h b/libavformat/matroska.h
index 2d04a6838b..4b2a3310a4 100644
--- a/libavformat/matroska.h
+++ b/libavformat/matroska.h
@@ -111,6 +111,7 @@
 #define MATROSKA_ID_TRACKCONTENTENCODING 0x6240
 #define MATROSKA_ID_TRACKTIMECODESCALE 0x23314F
 #define MATROSKA_ID_TRACKMAXBLKADDID 0x55EE
+#define MATROSKA_ID_TRACKBLKADDMAPPING 0x41E4
 
 /* IDs in the trackvideo master */
 #define MATROSKA_ID_VIDEOFRAMERATE 0x2383E3
@@ -189,6 +190,12 @@
 #define MATROSKA_ID_ENCODINGSIGKEYID 0x47E4
 #define MATROSKA_ID_ENCODINGSIGNATURE 0x47E3
 
+/* IDs in the block addition mapping master */
+#define MATROSKA_ID_BLKADDIDVALUE 0x41F0
+#define MATROSKA_ID_BLKADDIDNAME 0x41A4
+#define MATROSKA_ID_BLKADDIDTYPE 0x41E7
+#define MATROSKA_ID_BLKADDIDEXTRADATA 0x41ED
+
 /* ID in the cues master */
 #define MATROSKA_ID_POINTENTRY 0xBB
 
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 500c83ac3a..74c3fbc2a4 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -239,6 +239,13 @@ typedef struct MatroskaTrackOperation {
 EbmlList combine_planes;
 } MatroskaTrackOperation;
 
+typedef struct MatroskaBlockAdditionMapping {
+uint64_t value;
+char *name;
+uint64_t type;
+EbmlBin extradata;
+} MatroskaBlockAdditionMapping;
+
 typedef struct MatroskaTrack {
 uint64_t num;
 uint64_t uid;
@@ -269,6 +276,7 @@ typedef struct MatroskaTrack {
 int ms_compat;
 int needs_decoding;
 uint64_t max_block_additional_id;
+EbmlList block_addition_mappings;
 
 uint32_t palette[AVPALETTE_COUNT];
 int has_palette;
@@ -419,8 +427,8 @@ typedef struct MatroskaDemuxContext {
 // incomplete type (6.7.2 in C90, 6.9.2 in C99).
 // Removing the sizes breaks MSVC.
 static EbmlSyntax ebml_syntax[3], matroska_segment[9], 
matroska_track_video_color[15], matroska_track_video[19],
-  matroska_track[32], matroska_track_encoding[6], 
matroska_track_encodings[2],
-  matroska_track_combine_planes[2], 
matroska_track_operation[2], matroska_tracks[2],
+  matroska_track[33], matroska_track_encoding[6], 
matroska_track_encodings[2],
+  matroska_track_combine_planes[2], 
matroska_track_operation[2], matroska_block_addition_mapping[5], 
matroska_tracks[2],
   matroska_attachments[2], matroska_chapter_entry[9], 
matroska_chapter[6], matroska_chapters[2],
   matroska_index_entry[3], matroska_index[2], matroska_tag[3], 
matroska_tags[2], matroska_seekhead[2],
   matroska_blockadditions[2], matroska_blockgroup[8], 
matroska_cluster_parsing[8];
@@ -570,6 +578,14 @@ static EbmlSyntax matroska_track_operation[] = {
 CHILD_OF(matroska_track)
 };
 
+static EbmlSyntax matroska_block_addition_mapping[] = {
+{ MATROSKA_ID_BLKADDIDVALUE,  EBML_UINT, 0, 0, 
offsetof(MatroskaBlockAdditionMapping, value) },
+{ MATROSKA_ID_BLKADDIDNAME,   EBML_STR,  0, 0, 
offsetof(MatroskaBlockAdditionMapping, name) },
+{ MATROSKA_ID_BLKADDIDTYPE,   EBML_UINT, 0, 0, 
offsetof(MatroskaBlockAdditionMapping, type) },
+{ MATROSKA_ID_BLKADDIDEXTRADATA,  EBML_BIN,  0, 0, 
offsetof(MatroskaBlockAdditionMapping, extradata) },
+CHILD_OF(matroska_track)
+};
+
 static EbmlSyntax matroska_track[] = {
 { MATROSKA_ID_TRACKNUMBER,   EBML_UINT,  0, 0, 
offsetof(MatroskaTrack, num) },
 { MATROSKA_ID_TRACKNAME, EBML_UTF8,  0, 0, 
offsetof(MatroskaTrack, name) },
@@ -593,6 +609,7 @@ static EbmlSyntax matroska_track[] = {
 { MATROSKA_ID_TRACKOPERATION,EBML_NEST,  0, 0, 
offsetof(MatroskaTrack, operation),{ .n = matroska_track_operation } },
 { MATROSKA_ID_TRACKCONTENTENCODINGS, EBML_NEST,  0, 0, 0,  
   { .n = matroska_track_encodings } },
 { MATROSKA_ID_TRACKMAXBLKADDID,  EBML_UINT,  0, 0, 
offsetof(MatroskaTrack, max_block_additional_id), { .u = 0 } },
+{ MATROSKA_ID_TRACKBLKADDMAPPING,EBML_NEST,  0, 
sizeof(MatroskaBlockAdditionMapping), offsetof(MatroskaTrack, 
block_addition_mappings), { .n = matroska_block_addition_mapping } },
 { MATROSKA_ID_SEEKPREROLL,   EBML_UINT,  0, 0, 
offsetof(MatroskaTrack, seek_preroll), { .u = 0 } },
 { MATROSKA_ID_TRACKFLAGENABLED,  EBML_NONE },
 { MATROSKA_ID_TRACKFLAGLACING,   EBML_NONE },
@@ -2306,6 +2323,25 @@ static int mkv_parse_video_projection(AVStream *st, 
const MatroskaTrack *track,
 return 0;
 }
 
+static int mkv_parse_block_addition_mappings(AVFormatContext *s, AVStream *st, 
const MatroskaTrack *track)
+{
+const EbmlList *mappings_list = &track->block_addition_mappings;
+MatroskaBlockAdditionMapping *mappings = mappings_list->elem;
+
+ 

[FFmpeg-devel] [PATCH v3 2/5] avformat/matroskadec: Parse dvcC/dvvC block additional mapping

[quietvoid]

The parsing was implemented in a new dovi_isom file for the
unification of the mov/mpegts DOVI parsing into one function, in a following 
patch.

Most of the Matroska elements implementation was done by Plex developers.

Signed-off-by: quietvoid 
---
 libavformat/Makefile  |  2 +-
 libavformat/dovi_isom.c   | 80 +++
 libavformat/dovi_isom.h   | 29 ++
 libavformat/matroskadec.c | 15 
 4 files changed, 125 insertions(+), 1 deletion(-)
 create mode 100644 libavformat/dovi_isom.c
 create mode 100644 libavformat/dovi_isom.h

diff --git a/libavformat/Makefile b/libavformat/Makefile
index c45caa3eed..61a1fecf6c 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -313,7 +313,7 @@ OBJS-$(CONFIG_M4V_MUXER) += rawenc.o
 OBJS-$(CONFIG_MATROSKA_DEMUXER)  += matroskadec.o matroska.o  \
 flac_picture.o isom_tags.o 
rmsipr.o \
 oggparsevorbis.o vorbiscomment.o \
-qtpalette.o replaygain.o
+qtpalette.o replaygain.o 
dovi_isom.o
 OBJS-$(CONFIG_MATROSKA_MUXER)+= matroskaenc.o matroska.o \
 av1.o avc.o hevc.o isom_tags.o \
 flacenc_header.o avlanguage.o \
diff --git a/libavformat/dovi_isom.c b/libavformat/dovi_isom.c
new file mode 100644
index 00..2c0a49c993
--- /dev/null
+++ b/libavformat/dovi_isom.c
@@ -0,0 +1,80 @@
+/*
+ * DOVI ISO Media common code
+ * Copyright (c) 2021 quietvoid
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/dovi_meta.h"
+
+#include "avformat.h"
+#include "dovi_isom.h"
+
+int ff_isom_parse_dvcc_dvvc(AVFormatContext *s, AVStream *st, const uint8_t 
*buf_ptr, uint64_t size)
+{
+uint32_t buf;
+AVDOVIDecoderConfigurationRecord *dovi;
+size_t dovi_size;
+int ret;
+
+if (size > (1 << 30) || size < 4)
+return AVERROR_INVALIDDATA;
+
+dovi = av_dovi_alloc(&dovi_size);
+if (!dovi)
+return AVERROR(ENOMEM);
+
+dovi->dv_version_major = *buf_ptr++;// 8 bits
+dovi->dv_version_minor = *buf_ptr++;// 8 bits
+
+buf = *buf_ptr++ << 8;
+buf |= *buf_ptr++;
+
+dovi->dv_profile= (buf >> 9) & 0x7f;// 7 bits
+dovi->dv_level  = (buf >> 3) & 0x3f;// 6 bits
+dovi->rpu_present_flag  = (buf >> 2) & 0x01;// 1 bit
+dovi->el_present_flag   = (buf >> 1) & 0x01;// 1 bit
+dovi->bl_present_flag   =  buf   & 0x01;// 1 bit
+
+// Has enough remaining data
+if (size >= 5) {
+dovi->dv_bl_signal_compatibility_id = ((*buf_ptr++) >> 4) & 0x0f; // 4 
bits
+} else {
+// 0 stands for None
+// Dolby Vision V1.2.93 profiles and levels
+dovi->dv_bl_signal_compatibility_id = 0;
+}
+
+ret = av_stream_add_side_data(st, AV_PKT_DATA_DOVI_CONF,
+  (uint8_t *)dovi, dovi_size);
+if (ret < 0) {
+av_free(dovi);
+return ret;
+}
+
+av_log(s, AV_LOG_TRACE, "DOVI, version: %d.%d, profile: %d, level: %d, "
+   "rpu flag: %d, el flag: %d, bl flag: %d, compatibility id: %d\n",
+   dovi->dv_version_major, dovi->dv_version_minor,
+   dovi->dv_profile, dovi->dv_level,
+   dovi->rpu_present_flag,
+   dovi->el_present_flag,
+   dovi->bl_present_flag,
+   dovi->dv_bl_signal_compatibility_id
+);
+
+return 0;
+}
diff --git a/libavformat/dovi_isom.h b/libavformat/dovi_isom.h
new file mode 100644
index 00..4c313046a7
--- /dev/null
+++ b/libavformat/dovi_isom.h
@@ -0,0 +1,29 @@
+/*
+ * DOVI ISO Media common code
+ * Copyright (c) 2021 quietvoid
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied w

[FFmpeg-devel] [PATCH v3 3/5] avformat/matroskaenc: Write dvcC/dvvC block additional mapping

[quietvoid]

When muxing to Matroska, write the Block Additional Mapping
if there is AV_PKT_DATA_DOVI_CONF side data present.
Most of the code was implemented by Plex developers.

Since the type (dvcC/dvvC) can change depending on the caller,
the logic was separated from ff_isom_put_dvcc_dvvc.
In this case, movenc uses MKTAG while matroskaenc uses MKBETAG.
This would allow refactoring movenc in the future.

Signed-off-by: quietvoid 
---
 libavformat/Makefile  |  2 +-
 libavformat/dovi_isom.c   | 40 
 libavformat/dovi_isom.h   |  6 ++
 libavformat/matroskaenc.c | 43 +++
 4 files changed, 90 insertions(+), 1 deletion(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 61a1fecf6c..680030014d 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -317,7 +317,7 @@ OBJS-$(CONFIG_MATROSKA_DEMUXER)  += matroskadec.o 
matroska.o  \
 OBJS-$(CONFIG_MATROSKA_MUXER)+= matroskaenc.o matroska.o \
 av1.o avc.o hevc.o isom_tags.o \
 flacenc_header.o avlanguage.o \
-vorbiscomment.o wv.o
+vorbiscomment.o wv.o dovi_isom.o
 OBJS-$(CONFIG_MCA_DEMUXER)   += mca.o
 OBJS-$(CONFIG_MCC_DEMUXER)   += mccdec.o subtitles.o
 OBJS-$(CONFIG_MD5_MUXER) += hashenc.o
diff --git a/libavformat/dovi_isom.c b/libavformat/dovi_isom.c
index 2c0a49c993..747ffc8b2c 100644
--- a/libavformat/dovi_isom.c
+++ b/libavformat/dovi_isom.c
@@ -21,6 +21,8 @@
 
 #include "libavutil/dovi_meta.h"
 
+#include "libavcodec/put_bits.h"
+
 #include "avformat.h"
 #include "dovi_isom.h"
 
@@ -78,3 +80,41 @@ int ff_isom_parse_dvcc_dvvc(AVFormatContext *s, AVStream 
*st, const uint8_t *buf
 
 return 0;
 }
+
+int ff_isom_put_dvcc_dvvc(AVFormatContext *s, uint8_t 
out[ISOM_DVCC_DVVC_SIZE], uint64_t size,
+ AVDOVIDecoderConfigurationRecord *dovi)
+{
+PutBitContext pb;
+init_put_bits(&pb, out, size);
+
+if (size < ISOM_DVCC_DVVC_SIZE)
+return AVERROR(EINVAL);
+
+put_bits(&pb, 8, dovi->dv_version_major);
+put_bits(&pb, 8, dovi->dv_version_minor);
+put_bits(&pb, 7, dovi->dv_profile);
+put_bits(&pb, 6, dovi->dv_level);
+put_bits(&pb, 1, dovi->rpu_present_flag);
+put_bits(&pb, 1, dovi->el_present_flag);
+put_bits(&pb, 1, dovi->bl_present_flag);
+put_bits(&pb, 4, dovi->dv_bl_signal_compatibility_id);
+
+put_bits(&pb, 28, 0); /* reserved */
+put_bits32(&pb, 0); /* reserved */
+put_bits32(&pb, 0); /* reserved */
+put_bits32(&pb, 0); /* reserved */
+put_bits32(&pb, 0); /* reserved */
+flush_put_bits(&pb);
+
+av_log(s, AV_LOG_DEBUG, "DOVI in %s box, version: %d.%d, profile: %d, 
level: %d, "
+   "rpu flag: %d, el flag: %d, bl flag: %d, compatibility id: %d\n",
+   dovi->dv_profile > 7 ? "dvvC" : "dvcC",
+   dovi->dv_version_major, dovi->dv_version_minor,
+   dovi->dv_profile, dovi->dv_level,
+   dovi->rpu_present_flag,
+   dovi->el_present_flag,
+   dovi->bl_present_flag,
+   dovi->dv_bl_signal_compatibility_id);
+
+return put_bytes_output(&pb);
+}
diff --git a/libavformat/dovi_isom.h b/libavformat/dovi_isom.h
index 4c313046a7..8ff59ef495 100644
--- a/libavformat/dovi_isom.h
+++ b/libavformat/dovi_isom.h
@@ -22,8 +22,14 @@
 #ifndef AVFORMAT_DOVI_ISOM_H
 #define AVFORMAT_DOVI_ISOM_H
 
+#include "libavutil/dovi_meta.h"
+
 #include "avformat.h"
 
+#define ISOM_DVCC_DVVC_SIZE 24
+
 int ff_isom_parse_dvcc_dvvc(AVFormatContext *s, AVStream *st, const uint8_t 
*buf_ptr, uint64_t size);
+int ff_isom_put_dvcc_dvvc(AVFormatContext *s, uint8_t 
out[ISOM_DVCC_DVVC_SIZE], uint64_t size,
+ AVDOVIDecoderConfigurationRecord *dovi);
 
 #endif /* AVFORMAT_DOVI_ISOM_H */
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 039f20988a..067474d8ed 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -54,6 +54,8 @@
 #include "libavcodec/xiph.h"
 #include "libavcodec/mpeg4audio.h"
 
+#include "libavformat/dovi_isom.h"
+
 /* Level 1 elements we create a SeekHead entry for:
  * Info, Tracks, Chapters, Attachments, Tags (potentially twice) and Cues */
 #define MAX_SEEKHEAD_ENTRIES 7
@@ -1115,6 +1117,41 @@ static int mkv_write_stereo_mode(AVFormatContext *s, 
AVIOContext *pb,
 return 0;
 }
 
+static int mkv_write_dovi(AVFormatContext *s, AVIOContext *pb, AVStream *st)
+{
+int ret;
+AVDOVIDecoderConfigurationRecord *dovi = (AVDOVIDecoderConfigurationRecord 
*)
+ av_stream_get_side_data(st, 
AV_PKT_DATA_DOVI_CONF, NULL);
+
+if (dovi) {
+ebml_master mapping;
+uint8_t buf[ISOM_DVCC_DVVC_SIZE];
+uint32_t type;
+
+uint64_t size;
+uint64_t expected_size = (2 + 1

[FFmpeg-devel] [PATCH v3 4/5] avformat/mov: Refactor DOVI box parsing to use ff_isom_parse_dvcc_dvvc

[quietvoid]

Read at most 24 bytes, but in reality only 5 bytes are used for parsing.
The rest of the bytes are reserved in the specification.

Signed-off-by: quietvoid 
---
 libavformat/mov.c | 51 ++-
 1 file changed, 10 insertions(+), 41 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index bbb45864df..6667d551b8 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -61,6 +61,8 @@
 #include "mov_chan.h"
 #include "replaygain.h"
 
+#include "libavformat/dovi_isom.h"
+
 #if CONFIG_ZLIB
 #include 
 #endif
@@ -6799,58 +6801,25 @@ static int mov_read_dmlp(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 static int mov_read_dvcc_dvvc(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 {
 AVStream *st;
-uint32_t buf;
-AVDOVIDecoderConfigurationRecord *dovi;
-size_t dovi_size;
+uint8_t buf[ISOM_DVCC_DVVC_SIZE + AV_INPUT_BUFFER_PADDING_SIZE];
 int ret;
+int64_t read_size = atom.size;
 
 if (c->fc->nb_streams < 1)
 return 0;
 st = c->fc->streams[c->fc->nb_streams-1];
 
-if ((uint64_t)atom.size > (1<<30) || atom.size < 4)
-return AVERROR_INVALIDDATA;
-
-dovi = av_dovi_alloc(&dovi_size);
-if (!dovi)
-return AVERROR(ENOMEM);
-
-dovi->dv_version_major = avio_r8(pb);
-dovi->dv_version_minor = avio_r8(pb);
-
-buf = avio_rb16(pb);
-dovi->dv_profile= (buf >> 9) & 0x7f;// 7 bits
-dovi->dv_level  = (buf >> 3) & 0x3f;// 6 bits
-dovi->rpu_present_flag  = (buf >> 2) & 0x01;// 1 bit
-dovi->el_present_flag   = (buf >> 1) & 0x01;// 1 bit
-dovi->bl_present_flag   =  buf   & 0x01;// 1 bit
-if (atom.size >= 24) {  // 4 + 4 + 4 * 4
-buf = avio_r8(pb);
-dovi->dv_bl_signal_compatibility_id = (buf >> 4) & 0x0f; // 4 bits
-} else {
-// 0 stands for None
-// Dolby Vision V1.2.93 profiles and levels
-dovi->dv_bl_signal_compatibility_id = 0;
+// At most 24 bytes
+if (read_size > ISOM_DVCC_DVVC_SIZE) {
+read_size = ISOM_DVCC_DVVC_SIZE;
 }
 
-ret = av_stream_add_side_data(st, AV_PKT_DATA_DOVI_CONF,
-  (uint8_t *)dovi, dovi_size);
-if (ret < 0) {
-av_free(dovi);
+if ((ret = ffio_read_size(pb, buf, read_size)) < 0)
 return ret;
-}
 
-av_log(c, AV_LOG_TRACE, "DOVI in dvcC/dvvC box, version: %d.%d, profile: 
%d, level: %d, "
-   "rpu flag: %d, el flag: %d, bl flag: %d, compatibility id: %d\n",
-   dovi->dv_version_major, dovi->dv_version_minor,
-   dovi->dv_profile, dovi->dv_level,
-   dovi->rpu_present_flag,
-   dovi->el_present_flag,
-   dovi->bl_present_flag,
-   dovi->dv_bl_signal_compatibility_id
-);
+read_size = ret;
 
-return 0;
+return ff_isom_parse_dvcc_dvvc(c->fc, st, buf, read_size);
 }
 
 static const MOVParseTableEntry mov_default_parse_table[] = {
-- 
2.33.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 v3 5/5] avformat/mpegts: Refactor DOVI descriptor parsing to use ff_isom_parse_dvcc_dvvc

[quietvoid]

Also fixes incorrect parsing of dv_bl_signal_compatibility_id,
which was often set to zero instead of the actual value, for mpegts only.

Signed-off-by: quietvoid 
---
 libavformat/mpegts.c | 44 
 1 file changed, 4 insertions(+), 40 deletions(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index da8eee2414..75ef59d186 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -39,6 +39,9 @@
 #include "avio_internal.h"
 #include "mpeg.h"
 #include "isom.h"
+
+#include "libavformat/dovi_isom.h"
+
 #if CONFIG_ICONV
 #include 
 #endif
@@ -2162,49 +2165,10 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
AVStream *st, int stream_type
 break;
 case 0xb0: /* DOVI video stream descriptor */
 {
-uint32_t buf;
-AVDOVIDecoderConfigurationRecord *dovi;
-size_t dovi_size;
 int ret;
-if (desc_end - *pp < 4) // (8 + 8 + 7 + 6 + 1 + 1 + 1) / 8
-return AVERROR_INVALIDDATA;
-
-dovi = av_dovi_alloc(&dovi_size);
-if (!dovi)
-return AVERROR(ENOMEM);
 
-dovi->dv_version_major = get8(pp, desc_end);
-dovi->dv_version_minor = get8(pp, desc_end);
-buf = get16(pp, desc_end);
-dovi->dv_profile= (buf >> 9) & 0x7f;// 7 bits
-dovi->dv_level  = (buf >> 3) & 0x3f;// 6 bits
-dovi->rpu_present_flag  = (buf >> 2) & 0x01;// 1 bit
-dovi->el_present_flag   = (buf >> 1) & 0x01;// 1 bit
-dovi->bl_present_flag   =  buf   & 0x01;// 1 bit
-if (desc_end - *pp >= 20) {  // 4 + 4 * 4
-buf = get8(pp, desc_end);
-dovi->dv_bl_signal_compatibility_id = (buf >> 4) & 0x0f; // 4 
bits
-} else {
-// 0 stands for None
-// Dolby Vision V1.2.93 profiles and levels
-dovi->dv_bl_signal_compatibility_id = 0;
-}
-
-ret = av_stream_add_side_data(st, AV_PKT_DATA_DOVI_CONF,
-  (uint8_t *)dovi, dovi_size);
-if (ret < 0) {
-av_free(dovi);
+if ((ret = ff_isom_parse_dvcc_dvvc(fc, st, *pp, desc_len)) < 0)
 return ret;
-}
-
-av_log(fc, AV_LOG_TRACE, "DOVI, version: %d.%d, profile: %d, 
level: %d, "
-   "rpu flag: %d, el flag: %d, bl flag: %d, compatibility id: 
%d\n",
-   dovi->dv_version_major, dovi->dv_version_minor,
-   dovi->dv_profile, dovi->dv_level,
-   dovi->rpu_present_flag,
-   dovi->el_present_flag,
-   dovi->bl_present_flag,
-   dovi->dv_bl_signal_compatibility_id);
 }
 break;
 default:
-- 
2.33.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] Scaling PAL8 images with alpha

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Paul B Mahol
> Sent: Saturday, 25 September 2021 17:51
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> 
> On Sat, Sep 25, 2021 at 5:46 PM Soft Works 
> wrote:
> 
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of
> > > Michael Niedermayer
> > > Sent: Saturday, 25 September 2021 16:30
> > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> > >
> > > On Sat, Sep 25, 2021 at 10:23:56AM +0200, Hendrik Leppkes wrote:
> > > > On Sat, Sep 25, 2021 at 5:00 AM Soft Works
> 
> > > wrote:
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: ffmpeg-devel  On
> Behalf
> > > Of
> > > > > > Soft Works
> > > > > > Sent: Friday, 24 September 2021 19:03
> > > > > > To: FFmpeg development discussions and patches  > > > > > de...@ffmpeg.org>
> > > > > > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: ffmpeg-devel  On
> > > Behalf Of
> > > > > > Michael
> > > > > > > Niedermayer
> > > > > > > Sent: Friday, 24 September 2021 17:40
> > > > > > > To: FFmpeg development discussions and patches  > > > > > de...@ffmpeg.org>
> > > > > > > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with
> alpha
> > > > > > >
> > > > > > > On Fri, Sep 24, 2021 at 10:30:31AM +, Soft Works
> wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > for a new filter, I want to rescale PAL8 subtitle
> bitmaps
> > > where
> > > > > > the palette
> > > > > > > includes
> > > > > > > > colors with alpha.
> > > > > > > >
> > > > > > > > From what I’ve seen, swscale doesn’t support PAL8-to-
> PAL8,
> > > only
> > > > > > PAL8-to-
> > > > > > > BGR8
> > > > > > > > which doesn’t support alpha and the palette is fixed
> with
> > > 256
> > > > > > entries
> > > > > > > defined by
> > > > > > > > convention, while I would ideally like to be able to
> allow
> > > the
> > > > > > following:
> > > > > > > >
> > > > > > > > - constrain the output to use the same palette as the
> input
> > > > > > > > - adaptively quantize it to a palette with a
> configurable
> > > number
> > > > > > of colors
> > > > > > > >
> > > > > > > > Thus it's about the palette quantization (with or
> without
> > > > > > dithering) after
> > > > > > > > scaling in RGBA. (or some cool algorithmic trick I'm
> not
> > > aware
> > > > > > of)
> > > > > > > >
> > > > > > > > Is there any existing code that I could reuse? The
> closest
> > > I
> > > > > > could find
> > > > > > > > is pngenc, but I'm wondering whether there's something
> > > > > > else/better
> > > > > > > > somewhere in the ffmpeg libs that I haven't seen?
> > > > > > >
> > > > > > > There are some non linear scaling filters which may make
> > > sense when
> > > > > > you do
> > > > > > > not have the full linear space available see:
> > > > > > > hqx, epx, xbr
> > > > > > > you could also try some neural net stuff
> > > > > >
> > > > > > Photoshop can perfectly do what is needed, but their
> algorithms
> > > are
> > > > > > not
> > > > > > public.
> > > > >
> > > > > I've put a few thing together to illustrate what I'm talking
> > > about:
> > > > >
> > > > >
> > >
> https://gist.github.com/softworkz/deef5c2a43d3d629c3e17f9e21544a8f
> > > > >
> > > > >
> > > > > Meanwhile I found what I need:
> > > https://github.com/ImageOptim/libimagequant
> > > > >
> > > > > Interestingly, they are comparing their lib specifically to
> the
> > > > > Photoshop feature that I mentioned:
> > > https://pngquant.org/vsphotoshop.html
> > > > > In the 2000's, the PS implementation for image quantization,
> > > optimization
> > > > > and compression (profanely named "Save for Web") had remained
> > > > > unparalleled for years, that's why it was one of my first
> > > thoughts.
> > > > >
> > > > > I hadn't heard about libimagequant before, but it seems to do
> > > exactly
> > > > > what is needed for rescaling PAL8 to PAL8 at a high quality.
> > > > >
> > > > > Before spending any time on it, I wanted ask whether that
> library
> > > > > would be acceptable for adding it as a (GPLv3) reference to
> the
> > > > > project and as a dependency to my filter?
> > > > >
> > > >
> > > > External dependencies for what is supposed to be a rather base
> > > feature
> > > > are not ideal.
> > >
> > > +1
> > >
> > > i see no reason why this would need an external dependancy
> > > we have filters implementing much more complex things than
> scaling a
> > > pal8
> > > image
> >
> > I dislike GPL3 as well and needing a library for this might
> > seem to be a bit too much for solving the problem.
> > I'm just not sure whether it can be solved easily. I mean it
> > can easily be solved in a basic way, but I'm not sure whether
> > it would be possible to achieve

[FFmpeg-devel] [PATCH 1/2] avfilter/vf_selectivecolor: refactor some repeating calculations

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavfilter/vf_selectivecolor.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/libavfilter/vf_selectivecolor.c b/libavfilter/vf_selectivecolor.c
index ebbba9157f..9d789a6d8b 100644
--- a/libavfilter/vf_selectivecolor.c
+++ b/libavfilter/vf_selectivecolor.c
@@ -328,6 +328,9 @@ static inline int selective_color_##nbits(AVFilterContext 
*ctx, ThreadData *td,
 const uint8_t goffset = s->rgba_map[G];
 \
 const uint8_t boffset = s->rgba_map[B];
 \
 const uint8_t aoffset = s->rgba_map[A];
 \
+const int mid = 1<<(nbits-1);  
 \
+const int max = (1 1<<(nbits-1) && g > 1<<(nbits-1) && b 
> 1<<(nbits-1));  \
+const int is_white   = (r > mid && g > mid && b > mid);
 \
 const int is_neutral = (r || g || b) &&
 \
-   (r != (1

[FFmpeg-devel] [PATCH 2/2] avfilter/vf_selectivecolor: reduce number of operations with r/g/b/a pointers

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavfilter/vf_selectivecolor.c | 41 +++--
 1 file changed, 29 insertions(+), 12 deletions(-)

diff --git a/libavfilter/vf_selectivecolor.c b/libavfilter/vf_selectivecolor.c
index 9d789a6d8b..398d4bec0d 100644
--- a/libavfilter/vf_selectivecolor.c
+++ b/libavfilter/vf_selectivecolor.c
@@ -322,24 +322,31 @@ static inline int selective_color_##nbits(AVFilterContext 
*ctx, ThreadData *td,
 const int width  = in->width;  
 \
 const int slice_start = (height *  jobnr   ) / nb_jobs;
 \
 const int slice_end   = (height * (jobnr+1)) / nb_jobs;
 \
-const int dst_linesize = out->linesize[0]; 
 \
-const int src_linesize =  in->linesize[0]; 
 \
+const int dst_linesize = out->linesize[0] / ((nbits + 7) / 8); 
 \
+const int src_linesize =  in->linesize[0] / ((nbits + 7) / 8); 
 \
 const uint8_t roffset = s->rgba_map[R];
 \
 const uint8_t goffset = s->rgba_map[G];
 \
 const uint8_t boffset = s->rgba_map[B];
 \
 const uint8_t aoffset = s->rgba_map[A];
 \
+uint##nbits##_t *dst = (uint##nbits##_t *)out->data[0] + slice_start * 
dst_linesize;\
+const uint##nbits##_t *src = (const uint##nbits##_t *)in->data[0] + 
slice_start * src_linesize; \
+const uint##nbits##_t *src_r = (const uint##nbits##_t *)src + roffset; 
 \
+const uint##nbits##_t *src_g = (const uint##nbits##_t *)src + goffset; 
 \
+const uint##nbits##_t *src_b = (const uint##nbits##_t *)src + boffset; 
 \
+const uint##nbits##_t *src_a = (const uint##nbits##_t *)src + aoffset; 
 \
+uint##nbits##_t *dst_r = (uint##nbits##_t *)dst + roffset; 
 \
+uint##nbits##_t *dst_g = (uint##nbits##_t *)dst + goffset; 
 \
+uint##nbits##_t *dst_b = (uint##nbits##_t *)dst + boffset; 
 \
+uint##nbits##_t *dst_a = (uint##nbits##_t *)dst + aoffset; 
 \
 const int mid = 1<<(nbits-1);  
 \
 const int max = (1data[0] + 
y * src_linesize);\
-   
 \
 for (x = 0; x < width * s->step; x += s->step) {   
 \
-const int r = src[x + roffset];
 \
-const int g = src[x + goffset];
 \
-const int b = src[x + boffset];
 \
+const int r = src_r[x];
 \
+const int g = src_g[x];
 \
+const int b = src_b[x];
 \
 const int min_color = FFMIN3(r, g, b); 
 \
 const int max_color = FFMAX3(r, g, b); 
 \
 const int is_white   = (r > mid && g > mid && b > mid);
 \
@@ -382,13 +389,23 @@ static inline int selective_color_##nbits(AVFilterContext 
*ctx, ThreadData *td,
 }  
 \

 \
 if (!direct || adjust_r || adjust_g || adjust_b) { 
 \
-dst[x + roffset] = av_clip_uint##nbits(r + adjust_r);  
 \
-dst[x + goffset] = av_clip_uint##nbits(g + adjust_g);  
 \
-dst[x + boffset] = av_clip_uint##nbits(b + adjust_b);  
 \
+dst_r[x] = av_clip_uint##nbits(r + adjust_r);

Re: [FFmpeg-devel] Scaling PAL8 images with alpha

[Michael Niedermayer]

On Sat, Sep 25, 2021 at 03:46:25PM +, Soft Works wrote:
> 
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > Michael Niedermayer
> > Sent: Saturday, 25 September 2021 16:30
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> > 
> > On Sat, Sep 25, 2021 at 10:23:56AM +0200, Hendrik Leppkes wrote:
> > > On Sat, Sep 25, 2021 at 5:00 AM Soft Works 
> > wrote:
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: ffmpeg-devel  On Behalf
> > Of
> > > > > Soft Works
> > > > > Sent: Friday, 24 September 2021 19:03
> > > > > To: FFmpeg development discussions and patches  > > > > de...@ffmpeg.org>
> > > > > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: ffmpeg-devel  On
> > Behalf Of
> > > > > Michael
> > > > > > Niedermayer
> > > > > > Sent: Friday, 24 September 2021 17:40
> > > > > > To: FFmpeg development discussions and patches  > > > > de...@ffmpeg.org>
> > > > > > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> > > > > >
> > > > > > On Fri, Sep 24, 2021 at 10:30:31AM +, Soft Works wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > for a new filter, I want to rescale PAL8 subtitle bitmaps
> > where
> > > > > the palette
> > > > > > includes
> > > > > > > colors with alpha.
> > > > > > >
> > > > > > > From what I’ve seen, swscale doesn’t support PAL8-to-PAL8,
> > only
> > > > > PAL8-to-
> > > > > > BGR8
> > > > > > > which doesn’t support alpha and the palette is fixed with
> > 256
> > > > > entries
> > > > > > defined by
> > > > > > > convention, while I would ideally like to be able to allow
> > the
> > > > > following:
> > > > > > >
> > > > > > > - constrain the output to use the same palette as the input
> > > > > > > - adaptively quantize it to a palette with a configurable
> > number
> > > > > of colors
> > > > > > >
> > > > > > > Thus it's about the palette quantization (with or without
> > > > > dithering) after
> > > > > > > scaling in RGBA. (or some cool algorithmic trick I'm not
> > aware
> > > > > of)
> > > > > > >
> > > > > > > Is there any existing code that I could reuse? The closest
> > I
> > > > > could find
> > > > > > > is pngenc, but I'm wondering whether there's something
> > > > > else/better
> > > > > > > somewhere in the ffmpeg libs that I haven't seen?
> > > > > >
> > > > > > There are some non linear scaling filters which may make
> > sense when
> > > > > you do
> > > > > > not have the full linear space available see:
> > > > > > hqx, epx, xbr
> > > > > > you could also try some neural net stuff
> > > > >
> > > > > Photoshop can perfectly do what is needed, but their algorithms
> > are
> > > > > not
> > > > > public.
> > > >
> > > > I've put a few thing together to illustrate what I'm talking
> > about:
> > > >
> > > >
> > https://gist.github.com/softworkz/deef5c2a43d3d629c3e17f9e21544a8f
> > > >
> > > >
> > > > Meanwhile I found what I need:
> > https://github.com/ImageOptim/libimagequant
> > > >
> > > > Interestingly, they are comparing their lib specifically to the
> > > > Photoshop feature that I mentioned:
> > https://pngquant.org/vsphotoshop.html
> > > > In the 2000's, the PS implementation for image quantization,
> > optimization
> > > > and compression (profanely named "Save for Web") had remained
> > > > unparalleled for years, that's why it was one of my first
> > thoughts.
> > > >
> > > > I hadn't heard about libimagequant before, but it seems to do
> > exactly
> > > > what is needed for rescaling PAL8 to PAL8 at a high quality.
> > > >
> > > > Before spending any time on it, I wanted ask whether that library
> > > > would be acceptable for adding it as a (GPLv3) reference to the
> > > > project and as a dependency to my filter?
> > > >
> > >
> > > External dependencies for what is supposed to be a rather base
> > feature
> > > are not ideal.
> > 
> > +1
> > 
> > i see no reason why this would need an external dependancy
> > we have filters implementing much more complex things than scaling a
> > pal8
> > image
> 
> I dislike GPL3 as well and needing a library for this might 
> seem to be a bit too much for solving the problem.
> I'm just not sure whether it can be solved easily. I mean it
> can easily be solved in a basic way, but I'm not sure whether
> it would be possible to achieve the same quality in results.
> 
> I've put up here some examples and also a comparison of results
> from palettegen+paletteuse and Photoshop(which I assume to 
> be at the same level of quality like libimagequant).
> 
> https://gist.github.com/softworkz/deef5c2a43d3d629c3e17f9e21544a8f

is this comparing RGB vs RGBA palettes ?
I would imagine that for smooth edges of subtitles you need partly
transparent pixels. I am not sure palettegen supports that

please fix palettegen if that is the issue. Limiting a palette to
0% transparent and having 

Re: [FFmpeg-devel] Scaling PAL8 images with alpha

[Michael Niedermayer]

On Sat, Sep 25, 2021 at 10:34:32PM +0200, Michael Niedermayer wrote:
> On Sat, Sep 25, 2021 at 03:46:25PM +, Soft Works wrote:
> > 
> > 
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of
> > > Michael Niedermayer
> > > Sent: Saturday, 25 September 2021 16:30
> > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> > > 
> > > On Sat, Sep 25, 2021 at 10:23:56AM +0200, Hendrik Leppkes wrote:
> > > > On Sat, Sep 25, 2021 at 5:00 AM Soft Works 
> > > wrote:
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: ffmpeg-devel  On Behalf
> > > Of
> > > > > > Soft Works
> > > > > > Sent: Friday, 24 September 2021 19:03
> > > > > > To: FFmpeg development discussions and patches  > > > > > de...@ffmpeg.org>
> > > > > > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: ffmpeg-devel  On
> > > Behalf Of
> > > > > > Michael
> > > > > > > Niedermayer
> > > > > > > Sent: Friday, 24 September 2021 17:40
> > > > > > > To: FFmpeg development discussions and patches  > > > > > de...@ffmpeg.org>
> > > > > > > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> > > > > > >
> > > > > > > On Fri, Sep 24, 2021 at 10:30:31AM +, Soft Works wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > for a new filter, I want to rescale PAL8 subtitle bitmaps
> > > where
> > > > > > the palette
> > > > > > > includes
> > > > > > > > colors with alpha.
> > > > > > > >
> > > > > > > > From what I’ve seen, swscale doesn’t support PAL8-to-PAL8,
> > > only
> > > > > > PAL8-to-
> > > > > > > BGR8
> > > > > > > > which doesn’t support alpha and the palette is fixed with
> > > 256
> > > > > > entries
> > > > > > > defined by
> > > > > > > > convention, while I would ideally like to be able to allow
> > > the
> > > > > > following:
> > > > > > > >
> > > > > > > > - constrain the output to use the same palette as the input
> > > > > > > > - adaptively quantize it to a palette with a configurable
> > > number
> > > > > > of colors
> > > > > > > >
> > > > > > > > Thus it's about the palette quantization (with or without
> > > > > > dithering) after
> > > > > > > > scaling in RGBA. (or some cool algorithmic trick I'm not
> > > aware
> > > > > > of)
> > > > > > > >
> > > > > > > > Is there any existing code that I could reuse? The closest
> > > I
> > > > > > could find
> > > > > > > > is pngenc, but I'm wondering whether there's something
> > > > > > else/better
> > > > > > > > somewhere in the ffmpeg libs that I haven't seen?
> > > > > > >
> > > > > > > There are some non linear scaling filters which may make
> > > sense when
> > > > > > you do
> > > > > > > not have the full linear space available see:
> > > > > > > hqx, epx, xbr
> > > > > > > you could also try some neural net stuff
> > > > > >
> > > > > > Photoshop can perfectly do what is needed, but their algorithms
> > > are
> > > > > > not
> > > > > > public.
> > > > >
> > > > > I've put a few thing together to illustrate what I'm talking
> > > about:
> > > > >
> > > > >
> > > https://gist.github.com/softworkz/deef5c2a43d3d629c3e17f9e21544a8f
> > > > >
> > > > >
> > > > > Meanwhile I found what I need:
> > > https://github.com/ImageOptim/libimagequant
> > > > >
> > > > > Interestingly, they are comparing their lib specifically to the
> > > > > Photoshop feature that I mentioned:
> > > https://pngquant.org/vsphotoshop.html
> > > > > In the 2000's, the PS implementation for image quantization,
> > > optimization
> > > > > and compression (profanely named "Save for Web") had remained
> > > > > unparalleled for years, that's why it was one of my first
> > > thoughts.
> > > > >
> > > > > I hadn't heard about libimagequant before, but it seems to do
> > > exactly
> > > > > what is needed for rescaling PAL8 to PAL8 at a high quality.
> > > > >
> > > > > Before spending any time on it, I wanted ask whether that library
> > > > > would be acceptable for adding it as a (GPLv3) reference to the
> > > > > project and as a dependency to my filter?
> > > > >
> > > >
> > > > External dependencies for what is supposed to be a rather base
> > > feature
> > > > are not ideal.
> > > 
> > > +1
> > > 
> > > i see no reason why this would need an external dependancy
> > > we have filters implementing much more complex things than scaling a
> > > pal8
> > > image
> > 
> > I dislike GPL3 as well and needing a library for this might 
> > seem to be a bit too much for solving the problem.
> > I'm just not sure whether it can be solved easily. I mean it
> > can easily be solved in a basic way, but I'm not sure whether
> > it would be possible to achieve the same quality in results.
> > 
> > I've put up here some examples and also a comparison of results
> > from palettegen+paletteuse and Photoshop(which I assume to 
> > be at the same level of quality like libima

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/siren: prevent getbitcontext overread

[Michael Niedermayer]

On Sat, Sep 18, 2021 at 08:01:38PM +1000, Peter Ross wrote:
> ---
>  libavcodec/siren.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

probably ok 

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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 02/27] avformat/chromaprint: Add deinit function

[Andreas Rheinhardt]

Andreas Rheinhardt:
> Fixes memleaks in case the trailer is never written.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/chromaprint.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/chromaprint.c b/libavformat/chromaprint.c
> index 399de725d3..b7a943e126 100644
> --- a/libavformat/chromaprint.c
> +++ b/libavformat/chromaprint.c
> @@ -47,8 +47,10 @@ typedef struct ChromaprintMuxContext {
>  #endif
>  } ChromaprintMuxContext;
>  
> -static void cleanup(ChromaprintMuxContext *cpr)
> +static void deinit(AVFormatContext *s)
>  {
> +ChromaprintMuxContext *const cpr = s->priv_data;
> +
>  if (cpr->ctx) {
>  ff_lock_avformat();
>  chromaprint_free(cpr->ctx);
> @@ -107,7 +109,6 @@ static int write_header(AVFormatContext *s)
>  
>  return 0;
>  fail:
> -cleanup(cpr);
>  return AVERROR(EINVAL);
>  }
>  
> @@ -156,7 +157,6 @@ fail:
>  chromaprint_dealloc(fp);
>  if (enc_fp)
>  chromaprint_dealloc(enc_fp);
> -cleanup(cpr);
>  return ret;
>  }
>  
> @@ -187,6 +187,7 @@ const AVOutputFormat ff_chromaprint_muxer = {
>  .write_header  = write_header,
>  .write_packet  = write_packet,
>  .write_trailer = write_trailer,
> +.deinit= deinit,
>  .flags = AVFMT_NOTIMESTAMPS,
>  .priv_class= &chromaprint_class,
>  };
> 

Will apply the rest of this patchset tomorrow unless there are objections.

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

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

Re: [FFmpeg-devel] [PATCH 03/11] avcodec/tests/avcodec: Test AVCodec and AVCodecDescriptor consistency

[Andreas Rheinhardt]

Michael Niedermayer:
> On Fri, Sep 24, 2021 at 06:37:11PM +0200, Andreas Rheinhardt wrote:
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  libavcodec/tests/avcodec.c | 11 ++-
>>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> This and also the other patches adding checks LGTM
> 

Then I'll apply this patchset tomorrow unless there are objections.

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

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

Re: [FFmpeg-devel] [PATCH] webp: fix transforms after a palette with pixel packing.

[James Zern]

On Mon, Sep 20, 2021 at 5:44 PM James Zern  wrote:
>
> On Wed, Sep 8, 2021 at 6:46 PM James Zern  wrote:
> >
> > On Mon, Aug 30, 2021 at 5:11 AM Maryla  
> > wrote:
> > >
> > > When a color indexing transform with 16 or fewer colors is used,
> > > WebP uses "pixel packing", i.e. storing several pixels in one byte,
> > > which virtually reduces the width of the image (see WebPContext's
> > > reduced_width field). This reduced_width should always be used when
> > > reading and applying subsequent transforms.
> > >
> > > Updated patch with added fate test.
> > > The source image dual_transform.webp can be downloaded by cloning
> > > https://chromium.googlesource.com/webm/libwebp-test-data/
> > >
> > > Fixes: 9368
> > > ---
> > >  libavcodec/webp.c | 34 ++-
> > >  tests/fate/image.mak  |  3 ++
> > >  .../fate/webp-rgb-lossless-palette-predictor  |  6 
> > >  3 files changed, 27 insertions(+), 16 deletions(-)
> > >  create mode 100644 tests/ref/fate/webp-rgb-lossless-palette-predictor
> > >
> >
> > This works locally and matches the output from libwebp. I sent a
> > request to samples-request@ to add the file. This should have a micro
> > version bump for libavcodec/version.h; I've added that locally.
> >
>
> The sample addition is still pending. I've verified the pam output of
> this file and lossless* from the webp test set match libwebp. I'll
> submit this soon with the fate test disabled if there aren't any
> comments.
>

Applied with the test disabled. Thanks for the patch.
___
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/3] avfilter/vf_swaprect: Use ff_formats_pixdesc_filter()

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/vf_swaprect.c | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/libavfilter/vf_swaprect.c b/libavfilter/vf_swaprect.c
index 4a5f4a12a6..fff9b53dc4 100644
--- a/libavfilter/vf_swaprect.c
+++ b/libavfilter/vf_swaprect.c
@@ -22,7 +22,6 @@
 #include "libavutil/eval.h"
 #include "libavutil/imgutils.h"
 #include "libavutil/opt.h"
-#include "libavutil/pixdesc.h"
 
 #include "avfilter.h"
 #include "formats.h"
@@ -59,16 +58,13 @@ AVFILTER_DEFINE_CLASS(swaprect);
 static int query_formats(AVFilterContext *ctx)
 {
 AVFilterFormats *pix_fmts = NULL;
-int fmt, ret;
-
-for (fmt = 0; av_pix_fmt_desc_get(fmt); fmt++) {
-const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(fmt);
-if (!(desc->flags & AV_PIX_FMT_FLAG_PAL ||
-  desc->flags & AV_PIX_FMT_FLAG_HWACCEL ||
-  desc->flags & AV_PIX_FMT_FLAG_BITSTREAM) &&
-(ret = ff_add_format(&pix_fmts, fmt)) < 0)
-return ret;
-}
+int ret;
+
+ret = ff_formats_pixdesc_filter(&pix_fmts, 0, AV_PIX_FMT_FLAG_PAL |
+  AV_PIX_FMT_FLAG_HWACCEL |
+  AV_PIX_FMT_FLAG_BITSTREAM);
+if (ret < 0)
+return ret;
 
 return ff_set_common_formats(ctx, pix_fmts);
 }
-- 
2.30.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 2/3] avfilter/formats: Make ff_formats_pixdesc_filter return AVFilterFormats*

[Andreas Rheinhardt]

Up until now, it has returned the AVFilterFormats list via
an AVFilterFormats** parameter; the actual return value was an int
that was always AVERROR(ENOMEM) on error. The AVFilterFormats**
argument was a pure output parameter which was only documented
by naming the parameter rfmts. Yet nevertheless all callers
initialized the underlying AVFilterFormats* to NULL.

This commit changes this to return a pointer to AVFilterFormats
directly. This is more in line with the API in general, as it
allows to avoid checks for intermediate values.

Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/formats.c   |  9 -
 libavfilter/formats.h   |  2 +-
 libavfilter/vf_copy.c   |  9 +
 libavfilter/vf_crop.c   |  8 ++--
 libavfilter/vf_detelecine.c | 13 -
 libavfilter/vf_fieldhint.c  | 13 -
 libavfilter/vf_hwdownload.c |  9 -
 libavfilter/vf_il.c | 10 ++
 libavfilter/vf_mix.c| 13 -
 libavfilter/vf_stack.c  | 13 -
 libavfilter/vf_swaprect.c   | 13 -
 libavfilter/vf_telecine.c   | 15 +--
 libavfilter/vf_untile.c | 15 +--
 libavfilter/vf_weave.c  | 10 ++
 14 files changed, 46 insertions(+), 106 deletions(-)

diff --git a/libavfilter/formats.c b/libavfilter/formats.c
index 1bf7d36195..59ea966424 100644
--- a/libavfilter/formats.c
+++ b/libavfilter/formats.c
@@ -452,7 +452,7 @@ AVFilterFormats *ff_all_formats(enum AVMediaType type)
 return ret;
 }
 
-int ff_formats_pixdesc_filter(AVFilterFormats **rfmts, unsigned want, unsigned 
rej)
+AVFilterFormats *ff_formats_pixdesc_filter(unsigned want, unsigned rej)
 {
 unsigned nb_formats, fmt, flags;
 AVFilterFormats *formats = NULL;
@@ -476,18 +476,17 @@ int ff_formats_pixdesc_filter(AVFilterFormats **rfmts, 
unsigned want, unsigned r
 }
 if (formats) {
 av_assert0(formats->nb_formats == nb_formats);
-*rfmts = formats;
-return 0;
+return formats;
 }
 formats = av_mallocz(sizeof(*formats));
 if (!formats)
-return AVERROR(ENOMEM);
+return NULL;
 formats->nb_formats = nb_formats;
 if (nb_formats) {
 formats->formats = av_malloc_array(nb_formats, 
sizeof(*formats->formats));
 if (!formats->formats) {
 av_freep(&formats);
-return AVERROR(ENOMEM);
+return NULL;
 }
 }
 }
diff --git a/libavfilter/formats.h b/libavfilter/formats.h
index 471cb42bc4..42fe068765 100644
--- a/libavfilter/formats.h
+++ b/libavfilter/formats.h
@@ -230,7 +230,7 @@ AVFilterFormats *ff_all_formats(enum AVMediaType type);
  * properties
  */
 av_warn_unused_result
-int ff_formats_pixdesc_filter(AVFilterFormats **rfmts, unsigned want, unsigned 
rej);
+AVFilterFormats *ff_formats_pixdesc_filter(unsigned want, unsigned rej);
 
 //* format is software, non-planar with sub-sampling
 #define FF_PIX_FMT_FLAG_SW_FLAT_SUB (1 << 24)
diff --git a/libavfilter/vf_copy.c b/libavfilter/vf_copy.c
index 16fbe438a1..0ed61324e7 100644
--- a/libavfilter/vf_copy.c
+++ b/libavfilter/vf_copy.c
@@ -29,14 +29,7 @@
 
 static int query_formats(AVFilterContext *ctx)
 {
-AVFilterFormats *formats = NULL;
-int ret;
-
-ret = ff_formats_pixdesc_filter(&formats, 0,
-AV_PIX_FMT_FLAG_HWACCEL);
-if (ret < 0)
-return ret;
-return ff_set_common_formats(ctx, formats);
+return ff_set_common_formats(ctx, ff_formats_pixdesc_filter(0, 
AV_PIX_FMT_FLAG_HWACCEL));
 }
 
 static int filter_frame(AVFilterLink *inlink, AVFrame *in)
diff --git a/libavfilter/vf_crop.c b/libavfilter/vf_crop.c
index 76d375cdfc..27ae1b8118 100644
--- a/libavfilter/vf_crop.c
+++ b/libavfilter/vf_crop.c
@@ -93,13 +93,9 @@ typedef struct CropContext {
 
 static int query_formats(AVFilterContext *ctx)
 {
-AVFilterFormats *formats = NULL;
-int ret;
+int reject_flags = AV_PIX_FMT_FLAG_BITSTREAM | FF_PIX_FMT_FLAG_SW_FLAT_SUB;
 
-ret = ff_formats_pixdesc_filter(&formats, 0, AV_PIX_FMT_FLAG_BITSTREAM | 
FF_PIX_FMT_FLAG_SW_FLAT_SUB);
-if (ret < 0)
-return ret;
-return ff_set_common_formats(ctx, formats);
+return ff_set_common_formats(ctx, ff_formats_pixdesc_filter(0, 
reject_flags));
 }
 
 static av_cold void uninit(AVFilterContext *ctx)
diff --git a/libavfilter/vf_detelecine.c b/libavfilter/vf_detelecine.c
index 7f34a88217..e36e1a6245 100644
--- a/libavfilter/vf_detelecine.c
+++ b/libavfilter/vf_detelecine.c
@@ -124,16 +124,11 @@ static av_cold int init(AVFilterContext *ctx)
 
 static int query_formats(AVFilterContext *ctx)
 {
-AVFilterFormats *formats = NULL;
-int ret;
+int reject_flags = AV_PIX_FMT_FLAG_BITSTREAM |
+   AV_PIX_FMT_FLAG_PAL   |
+   AV_PIX_FMT_FLAG_HWACCEL;
 
-ret = ff_formats_pixdesc_filter(&formats, 0,
-  

[FFmpeg-devel] [PATCH 3/3] avfilter/formats: Avoid reallocations for video in ff_all_formats()

[Andreas Rheinhardt]

Up until now, the list of pixfmts is reallocated every time an entry
is added to it; there are currently 196 pixel formats, so this matters:
It causes 5541704 calls to av_realloc_array() in a typical FATE run,
which is the majority for said function (8095768 calls) and even
a large chunk of the calls to av_realloc() itself (12589508 calls).

Fix this by using ff_formats_pixdesc_filter() instead.

Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/formats.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/libavfilter/formats.c b/libavfilter/formats.c
index 59ea966424..1d2a51c0af 100644
--- a/libavfilter/formats.c
+++ b/libavfilter/formats.c
@@ -435,11 +435,7 @@ AVFilterFormats *ff_all_formats(enum AVMediaType type)
 AVFilterFormats *ret = NULL;
 
 if (type == AVMEDIA_TYPE_VIDEO) {
-const AVPixFmtDescriptor *desc = NULL;
-while ((desc = av_pix_fmt_desc_next(desc))) {
-if (ff_add_format(&ret, av_pix_fmt_desc_get_id(desc)) < 0)
-return NULL;
-}
+return ff_formats_pixdesc_filter(0, 0);
 } else if (type == AVMEDIA_TYPE_AUDIO) {
 enum AVSampleFormat fmt = 0;
 while (av_get_sample_fmt_name(fmt)) {
-- 
2.30.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] Scaling PAL8 images with alpha

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Michael Niedermayer
> Sent: Saturday, 25 September 2021 22:47
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> 
> On Sat, Sep 25, 2021 at 10:34:32PM +0200, Michael Niedermayer wrote:
> > On Sat, Sep 25, 2021 at 03:46:25PM +, Soft Works wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: ffmpeg-devel  On Behalf
> Of
> > > > Michael Niedermayer
> > > > Sent: Saturday, 25 September 2021 16:30
> > > > To: FFmpeg development discussions and patches  > > > de...@ffmpeg.org>
> > > > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> > > >
> > > > On Sat, Sep 25, 2021 at 10:23:56AM +0200, Hendrik Leppkes
> wrote:
> > > > > On Sat, Sep 25, 2021 at 5:00 AM Soft Works
> 
> > > > wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: ffmpeg-devel  On
> Behalf
> > > > Of
> > > > > > > Soft Works
> > > > > > > Sent: Friday, 24 September 2021 19:03
> > > > > > > To: FFmpeg development discussions and patches  > > > > > > de...@ffmpeg.org>
> > > > > > > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with
> alpha
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > -Original Message-
> > > > > > > > From: ffmpeg-devel  On
> > > > Behalf Of
> > > > > > > Michael
> > > > > > > > Niedermayer
> > > > > > > > Sent: Friday, 24 September 2021 17:40
> > > > > > > > To: FFmpeg development discussions and patches  > > > > > > de...@ffmpeg.org>
> > > > > > > > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with
> alpha
> > > > > > > >
> > > > > > > > On Fri, Sep 24, 2021 at 10:30:31AM +, Soft Works
> wrote:
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > for a new filter, I want to rescale PAL8 subtitle
> bitmaps
> > > > where
> > > > > > > the palette
> > > > > > > > includes
> > > > > > > > > colors with alpha.
> > > > > > > > >
> > > > > > > > > From what I’ve seen, swscale doesn’t support PAL8-to-
> PAL8,
> > > > only
> > > > > > > PAL8-to-
> > > > > > > > BGR8
> > > > > > > > > which doesn’t support alpha and the palette is fixed
> with
> > > > 256
> > > > > > > entries
> > > > > > > > defined by
> > > > > > > > > convention, while I would ideally like to be able to
> allow
> > > > the
> > > > > > > following:
> > > > > > > > >
> > > > > > > > > - constrain the output to use the same palette as the
> input
> > > > > > > > > - adaptively quantize it to a palette with a
> configurable
> > > > number
> > > > > > > of colors
> > > > > > > > >
> > > > > > > > > Thus it's about the palette quantization (with or
> without
> > > > > > > dithering) after
> > > > > > > > > scaling in RGBA. (or some cool algorithmic trick I'm
> not
> > > > aware
> > > > > > > of)
> > > > > > > > >
> > > > > > > > > Is there any existing code that I could reuse? The
> closest
> > > > I
> > > > > > > could find
> > > > > > > > > is pngenc, but I'm wondering whether there's
> something
> > > > > > > else/better
> > > > > > > > > somewhere in the ffmpeg libs that I haven't seen?
> > > > > > > >
> > > > > > > > There are some non linear scaling filters which may
> make
> > > > sense when
> > > > > > > you do
> > > > > > > > not have the full linear space available see:
> > > > > > > > hqx, epx, xbr
> > > > > > > > you could also try some neural net stuff
> > > > > > >
> > > > > > > Photoshop can perfectly do what is needed, but their
> algorithms
> > > > are
> > > > > > > not
> > > > > > > public.
> > > > > >
> > > > > > I've put a few thing together to illustrate what I'm
> talking
> > > > about:
> > > > > >
> > > > > >
> > > >
> https://gist.github.com/softworkz/deef5c2a43d3d629c3e17f9e21544a8f
> > > > > >
> > > > > >
> > > > > > Meanwhile I found what I need:
> > > > https://github.com/ImageOptim/libimagequant
> > > > > >
> > > > > > Interestingly, they are comparing their lib specifically to
> the
> > > > > > Photoshop feature that I mentioned:
> > > > https://pngquant.org/vsphotoshop.html
> > > > > > In the 2000's, the PS implementation for image
> quantization,
> > > > optimization
> > > > > > and compression (profanely named "Save for Web") had
> remained
> > > > > > unparalleled for years, that's why it was one of my first
> > > > thoughts.
> > > > > >
> > > > > > I hadn't heard about libimagequant before, but it seems to
> do
> > > > exactly
> > > > > > what is needed for rescaling PAL8 to PAL8 at a high
> quality.
> > > > > >
> > > > > > Before spending any time on it, I wanted ask whether that
> library
> > > > > > would be acceptable for adding it as a (GPLv3) reference to
> the
> > > > > > project and as a dependency to my filter?
> > > > > >
> > > > >
> > > > > External dependencies for what is supposed to be a rather
> base
> > > > feature
> > > > > are not ideal.
> > > >
> > > > +1
> > > >
> > > > i see no reason why this would need an external dependancy
> > > > we have filters implementing 

[FFmpeg-devel] [PATCH] avfilter/palettegen, paletteuse: Extend the palette conversion filters to support palettes with alpha

[Soft Works]

Usage example:

ffmpeg -y -loglevel verbose -i "..\fate-suite\apng\o_sample.png" 
-filter_complex 
"split[split1][split2];[split1]palettegen=max_colors=254:use_alpha=1[pal1];[split2][pal1]paletteuse=use_alpha=1"
 -frames:v 1 out.png

Signed-off-by: softworkz 
---
 doc/filters.texi|   8 ++
 libavfilter/vf_palettegen.c | 140 ++
 libavfilter/vf_paletteuse.c | 225 +---
 3 files changed, 233 insertions(+), 140 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 36113e5c4b..7e4806235c 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -16454,6 +16454,9 @@ Compute new histogram for each frame.
 @end table
 
 Default value is @var{full}.
+@item use_alpha
+Create a palette of colors with alpha components.
+Setting this, will automatically disable 'reserve_transparent'.
 @end table
 
 The filter also exports the frame metadata @code{lavfi.color_quant_ratio}
@@ -16532,6 +16535,11 @@ will be treated as completely opaque, and values below 
this threshold will be
 treated as completely transparent.
 
 The option must be an integer value in the range [0,255]. Default is @var{128}.
+
+@item use_alpha
+Apply the palette by taking alpha values into account. Only useful with 
+palettes that are containing multiple colors with alpha components.
+Setting this will automatically disable 'alpha_treshold'.
 @end table
 
 @subsection Examples
diff --git a/libavfilter/vf_palettegen.c b/libavfilter/vf_palettegen.c
index 4c2fbd36d7..7a74a3752f 100644
--- a/libavfilter/vf_palettegen.c
+++ b/libavfilter/vf_palettegen.c
@@ -59,7 +59,7 @@ enum {
 };
 
 #define NBITS 5
-#define HIST_SIZE (1<<(3*NBITS))
+#define HIST_SIZE (1<<(4*NBITS))
 
 typedef struct PaletteGenContext {
 const AVClass *class;
@@ -67,6 +67,7 @@ typedef struct PaletteGenContext {
 int max_colors;
 int reserve_transparent;
 int stats_mode;
+int use_alpha;
 
 AVFrame *prev_frame;// previous frame used for the 
diff stats_mode
 struct hist_node histogram[HIST_SIZE];  // histogram/hashtable of the 
colors
@@ -88,6 +89,7 @@ static const AVOption palettegen_options[] = {
 { "full", "compute full frame histograms", 0, AV_OPT_TYPE_CONST, 
{.i64=STATS_MODE_ALL_FRAMES}, INT_MIN, INT_MAX, FLAGS, "mode" },
 { "diff", "compute histograms only for the part that differs from 
previous frame", 0, AV_OPT_TYPE_CONST, {.i64=STATS_MODE_DIFF_FRAMES}, INT_MIN, 
INT_MAX, FLAGS, "mode" },
 { "single", "compute new histogram for each frame", 0, 
AV_OPT_TYPE_CONST, {.i64=STATS_MODE_SINGLE_FRAMES}, INT_MIN, INT_MAX, FLAGS, 
"mode" },
+{ "use_alpha", "create a palette including alpha values", 
OFFSET(use_alpha), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, FLAGS },
 { NULL }
 };
 
@@ -113,15 +115,16 @@ static int cmp_##name(const void *pa, const void *pb)   \
 {   \
 const struct color_ref * const *a = pa; \
 const struct color_ref * const *b = pb; \
-return   (int)((*a)->color >> (8 * (2 - (pos))) & 0xff)  \
-   - (int)((*b)->color >> (8 * (2 - (pos))) & 0xff); \
+return   (int)((*a)->color >> (8 * (3 - (pos))) & 0xff)  \
+   - (int)((*b)->color >> (8 * (3 - (pos))) & 0xff); \
 }
 
-DECLARE_CMP_FUNC(r, 0)
-DECLARE_CMP_FUNC(g, 1)
-DECLARE_CMP_FUNC(b, 2)
+DECLARE_CMP_FUNC(a, 0)
+DECLARE_CMP_FUNC(r, 1)
+DECLARE_CMP_FUNC(g, 2)
+DECLARE_CMP_FUNC(b, 3)
 
-static const cmp_func cmp_funcs[] = {cmp_r, cmp_g, cmp_b};
+static const cmp_func cmp_funcs[] = {cmp_a, cmp_r, cmp_g, cmp_b};
 
 /**
  * Simple color comparison for sorting the final palette
@@ -143,6 +146,17 @@ static av_always_inline int diff(const uint32_t a, const 
uint32_t b)
 return dr*dr + dg*dg + db*db;
 }
 
+static av_always_inline int diff_alpha(const uint32_t a, const uint32_t b)
+{
+const uint8_t c1[] = {a >> 24 & 0xff, a >> 16 & 0xff, a >> 8 & 0xff, a & 
0xff};
+const uint8_t c2[] = {b >> 24 & 0xff, b >> 16 & 0xff, b >> 8 & 0xff, b & 
0xff};
+const int da = c1[0] - c2[0];
+const int dr = c1[1] - c2[1];
+const int dg = c1[2] - c2[2];
+const int db = c1[3] - c2[3];
+return da*da + dr*dr + dg*dg + db*db;
+}
+
 /**
  * Find the next box to split: pick the one with the highest variance
  */
@@ -164,7 +178,10 @@ static int get_next_box_id_to_split(PaletteGenContext *s)
 
 for (i = 0; i < box->len; i++) {
 const struct color_ref *ref = s->refs[box->start + i];
-variance += diff(ref->color, box->color) * ref->count;
+if (s->use_alpha)
+variance += (int64_t)diff_alpha(ref->color, 
box->color) * ref->count;
+else
+variance += (int64_t)diff(ref->color, box->color) * 
ref->count;
 }
 box->variance = variance;
 }
@@ -184,24 +201,31 @@ static int get_next_box_id_to_split(Palett

[FFmpeg-devel] [PATCH] avformat/argo_asf: Use memcpy to copy string without its NUL

[Andreas Rheinhardt]

This avoids a -Wstringop-truncation warning from GCC which takes
issue with the fact that the destination might not be NUL terminated.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/argo_asf.c | 20 +++-
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/libavformat/argo_asf.c b/libavformat/argo_asf.c
index 5adafb7230..0ef970df8a 100644
--- a/libavformat/argo_asf.c
+++ b/libavformat/argo_asf.c
@@ -356,25 +356,19 @@ static int argo_asf_write_header(AVFormatContext *s)
 .num_chunks= 1,
 .chunk_offset  = ASF_FILE_HEADER_SIZE
 };
+const char *name = ctx->name, *end;
+size_t len;
 
 /*
  * If the user specified a name, use it as is. Otherwise take the
  * basename and lop off the extension (if any).
  */
-if (ctx->name) {
-strncpy(fhdr.name, ctx->name, sizeof(fhdr.name));
-} else {
-const char *start = av_basename(s->url);
-const char *end   = strrchr(start, '.');
-size_t  len;
-
-if (end)
-len = end - start;
-else
-len = strlen(start);
+if (name || !(end = strrchr(name = av_basename(s->url), '.'))) {
+len = strlen(name);
+} else
+len = end - name;
 
-memcpy(fhdr.name, start, FFMIN(len, sizeof(fhdr.name)));
-}
+memcpy(fhdr.name, name, FFMIN(len, sizeof(fhdr.name)));
 
 chdr.num_blocks= 0;
 chdr.num_samples   = ASF_SAMPLE_COUNT;
-- 
2.30.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] avfilter/elbg: Extend filter to include alpha values in the quantization procedure

[Soft Works]

Usage example:

ffmpeg -y -loglevel verbose -i "..\fate-suite\apng\o_sample.png" 
-filter_complex "elbg=pal8=1:use_alpha=1" -frames:v 1 out.png

Signed-off-by: softworkz 
---
 doc/filters.texi  |  4 
 libavfilter/vf_elbg.c | 25 -
 2 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 7e4806235c..fa450b3eb4 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11396,6 +11396,10 @@ will try to use a good random seed on a best effort 
basis.
 @item pal8
 Set pal8 output pixel format. This option does not work with codebook
 length greater than 256. Default is disabled.
+
+@item use_alpha
+Include alpha values in the quantization calculation. Allows creating
+palettized output images (e.g. PNG8) with multiple alpha smooth blending.
 @end table
 
 @section entropy
diff --git a/libavfilter/vf_elbg.c b/libavfilter/vf_elbg.c
index 0bebcdbda5..7f40be6092 100644
--- a/libavfilter/vf_elbg.c
+++ b/libavfilter/vf_elbg.c
@@ -46,6 +46,7 @@ typedef struct ELBGFilterContext {
 int codebook_length;
 const AVPixFmtDescriptor *pix_desc;
 uint8_t rgba_map[4];
+int use_alpha;
 int pal8;
 } ELBGFilterContext;
 
@@ -60,6 +61,7 @@ static const AVOption elbg_options[] = {
 { "seed", "set the random seed", OFFSET(lfg_seed), AV_OPT_TYPE_INT64, 
{.i64 = -1}, -1, UINT32_MAX, FLAGS },
 { "s","set the random seed", OFFSET(lfg_seed), AV_OPT_TYPE_INT64, { 
.i64 = -1 }, -1, UINT32_MAX, FLAGS },
 { "pal8", "set the pal8 output", OFFSET(pal8), AV_OPT_TYPE_BOOL, { .i64 = 
0 }, 0, 1, FLAGS },
+{ "use_alpha", "use alpha channel for mapping", OFFSET(use_alpha), 
AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, FLAGS },
 { NULL }
 };
 
@@ -105,7 +107,7 @@ static int query_formats(AVFilterContext *ctx)
 return 0;
 }
 
-#define NB_COMPONENTS 3
+#define NB_COMPONENTS 4
 
 static int config_input(AVFilterLink *inlink)
 {
@@ -138,6 +140,7 @@ static int config_input(AVFilterLink *inlink)
 #define R 0
 #define G 1
 #define B 2
+#define A 3
 
 static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
 {
@@ -148,6 +151,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*frame)
 const uint8_t r_idx  = elbg->rgba_map[R];
 const uint8_t g_idx  = elbg->rgba_map[G];
 const uint8_t b_idx  = elbg->rgba_map[B];
+const uint8_t a_idx  = elbg->rgba_map[A];
 
 /* build the codeword */
 p0 = frame->data[0];
@@ -155,9 +159,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*frame)
 for (i = 0; i < inlink->h; i++) {
 p = p0;
 for (j = 0; j < inlink->w; j++) {
-elbg->codeword[k++] = p[r_idx];
-elbg->codeword[k++] = p[g_idx];
 elbg->codeword[k++] = p[b_idx];
+elbg->codeword[k++] = p[g_idx];
+elbg->codeword[k++] = p[r_idx];
+elbg->codeword[k++] = elbg->use_alpha ? p[a_idx] : 0xff;
 p += elbg->pix_desc->nb_components;
 }
 p0 += frame->linesize[0];
@@ -188,10 +193,11 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*frame)
 p0 = (uint8_t *)out->data[0];
 
 for (i = 0; i < elbg->codebook_length; i++) {
-pal[i] =  0xFFU << 24  |
- (elbg->codebook[i*3  ] << 16) |
- (elbg->codebook[i*3+1] <<  8) |
-  elbg->codebook[i*3+2];
+const int al =  elbg->use_alpha ? elbg->codebook[i*4+3] : 0xff;
+pal[i] =  al<< 24  |
+ (elbg->codebook[i*4+2] << 16) |
+ (elbg->codebook[i*4+1] <<  8) |
+  elbg->codebook[i*4  ];
 }
 
 k = 0;
@@ -214,9 +220,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*frame)
 p = p0;
 for (j = 0; j < inlink->w; j++) {
 int cb_idx = NB_COMPONENTS * 
elbg->codeword_closest_codebook_idxs[k++];
-p[r_idx] = elbg->codebook[cb_idx];
+p[b_idx] = elbg->codebook[cb_idx];
 p[g_idx] = elbg->codebook[cb_idx+1];
-p[b_idx] = elbg->codebook[cb_idx+2];
+p[r_idx] = elbg->codebook[cb_idx+2];
+p[a_idx] = elbg->use_alpha ? elbg->codebook[cb_idx+3] : 0xFFu;
 p += elbg->pix_desc->nb_components;
 }
 p0 += frame->linesize[0];
-- 
2.30.2.windows.1

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

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

Re: [FFmpeg-devel] Scaling PAL8 images with alpha

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Soft Works
> Sent: Sunday, 26 September 2021 01:00
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> 
> 
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > Michael Niedermayer
> > Sent: Saturday, 25 September 2021 22:47
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> >
> > On Sat, Sep 25, 2021 at 10:34:32PM +0200, Michael Niedermayer
> wrote:
> > > On Sat, Sep 25, 2021 at 03:46:25PM +, Soft Works wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: ffmpeg-devel  On
> Behalf
> > Of
> > > > > Michael Niedermayer
> > > > > Sent: Saturday, 25 September 2021 16:30
> > > > > To: FFmpeg development discussions and patches  > > > > de...@ffmpeg.org>
> > > > > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with alpha
> > > > >
> > > > > On Sat, Sep 25, 2021 at 10:23:56AM +0200, Hendrik Leppkes
> > wrote:
> > > > > > On Sat, Sep 25, 2021 at 5:00 AM Soft Works
> > 
> > > > > wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > -Original Message-
> > > > > > > > From: ffmpeg-devel  On
> > Behalf
> > > > > Of
> > > > > > > > Soft Works
> > > > > > > > Sent: Friday, 24 September 2021 19:03
> > > > > > > > To: FFmpeg development discussions and patches  > > > > > > > de...@ffmpeg.org>
> > > > > > > > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with
> > alpha
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > -Original Message-
> > > > > > > > > From: ffmpeg-devel 
> On
> > > > > Behalf Of
> > > > > > > > Michael
> > > > > > > > > Niedermayer
> > > > > > > > > Sent: Friday, 24 September 2021 17:40
> > > > > > > > > To: FFmpeg development discussions and patches
>  > > > > > > > de...@ffmpeg.org>
> > > > > > > > > Subject: Re: [FFmpeg-devel] Scaling PAL8 images with
> > alpha
> > > > > > > > >
> > > > > > > > > On Fri, Sep 24, 2021 at 10:30:31AM +, Soft Works
> > wrote:
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > for a new filter, I want to rescale PAL8 subtitle
> > bitmaps
> > > > > where
> > > > > > > > the palette
> > > > > > > > > includes
> > > > > > > > > > colors with alpha.
> > > > > > > > > >
> > > > > > > > > > From what I’ve seen, swscale doesn’t support PAL8-
> to-
> > PAL8,
> > > > > only
> > > > > > > > PAL8-to-
> > > > > > > > > BGR8
> > > > > > > > > > which doesn’t support alpha and the palette is
> fixed
> > with
> > > > > 256
> > > > > > > > entries
> > > > > > > > > defined by
> > > > > > > > > > convention, while I would ideally like to be able
> to
> > allow
> > > > > the
> > > > > > > > following:
> > > > > > > > > >
> > > > > > > > > > - constrain the output to use the same palette as
> the
> > input
> > > > > > > > > > - adaptively quantize it to a palette with a
> > configurable
> > > > > number
> > > > > > > > of colors
> > > > > > > > > >
> > > > > > > > > > Thus it's about the palette quantization (with or
> > without
> > > > > > > > dithering) after
> > > > > > > > > > scaling in RGBA. (or some cool algorithmic trick
> I'm
> > not
> > > > > aware
> > > > > > > > of)
> > > > > > > > > >
> > > > > > > > > > Is there any existing code that I could reuse? The
> > closest
> > > > > I
> > > > > > > > could find
> > > > > > > > > > is pngenc, but I'm wondering whether there's
> > something
> > > > > > > > else/better
> > > > > > > > > > somewhere in the ffmpeg libs that I haven't seen?
> > > > > > > > >
> > > > > > > > > There are some non linear scaling filters which may
> > make
> > > > > sense when
> > > > > > > > you do
> > > > > > > > > not have the full linear space available see:
> > > > > > > > > hqx, epx, xbr
> > > > > > > > > you could also try some neural net stuff
> > > > > > > >
> > > > > > > > Photoshop can perfectly do what is needed, but their
> > algorithms
> > > > > are
> > > > > > > > not
> > > > > > > > public.
> > > > > > >
> > > > > > > I've put a few thing together to illustrate what I'm
> > talking
> > > > > about:
> > > > > > >
> > > > > > >
> > > > >
> > https://gist.github.com/softworkz/deef5c2a43d3d629c3e17f9e21544a8f
> > > > > > >
> > > > > > >
> > > > > > > Meanwhile I found what I need:
> > > > > https://github.com/ImageOptim/libimagequant
> > > > > > >
> > > > > > > Interestingly, they are comparing their lib specifically
> to
> > the
> > > > > > > Photoshop feature that I mentioned:
> > > > > https://pngquant.org/vsphotoshop.html
> > > > > > > In the 2000's, the PS implementation for image
> > quantization,
> > > > > optimization
> > > > > > > and compression (profanely named "Save for Web") had
> > remained
> > > > > > > unparalleled for years, that's why it was one of my first
> > > > > thoughts.
> > > > > > >
> > > > > > > I hadn't heard about libimagequant before, but it seems
> to
> > do
> > > > > exactly
> >

Re: [FFmpeg-devel] [PATCH] avformat/argo_asf: Use memcpy to copy string without its NUL

[Zane van Iperen]

On 26/9/21 1:09 pm, Andreas Rheinhardt wrote:

This avoids a -Wstringop-truncation warning from GCC which takes
issue with the fact that the destination might not be NUL terminated.

Signed-off-by: Andreas Rheinhardt 
---
  libavformat/argo_asf.c | 20 +++-
  1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/libavformat/argo_asf.c b/libavformat/argo_asf.c
index 5adafb7230..0ef970df8a 100644
--- a/libavformat/argo_asf.c
+++ b/libavformat/argo_asf.c
@@ -356,25 +356,19 @@ static int argo_asf_write_header(AVFormatContext *s)
  .num_chunks= 1,
  .chunk_offset  = ASF_FILE_HEADER_SIZE
  };
+const char *name = ctx->name, *end;
+size_t len;
  
  /*

   * If the user specified a name, use it as is. Otherwise take the
   * basename and lop off the extension (if any).
   */
-if (ctx->name) {
-strncpy(fhdr.name, ctx->name, sizeof(fhdr.name));
-} else {
-const char *start = av_basename(s->url);
-const char *end   = strrchr(start, '.');
-size_t  len;
-
-if (end)
-len = end - start;
-else
-len = strlen(start);
+if (name || !(end = strrchr(name = av_basename(s->url), '.'))) {
+len = strlen(name);
+} else
+len = end - name;
  
-memcpy(fhdr.name, start, FFMIN(len, sizeof(fhdr.name)));

-}
+memcpy(fhdr.name, name, FFMIN(len, sizeof(fhdr.name)));
  


Minor formatting nits:
* The first statement has braces, the second doesn't.
* A set of parentheses around "name = av_basename(s->url)" would make things 
clearer.

Otherwise, lgtm.

Zane
___
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] avcodec/qsvenc: Fix leak and crash when encoding H.264 due to A53_CC

[Andreas Rheinhardt]

Since commit 3bbe0c210b05fc6fbd7b1d4bbd8479db7f2cf957, the Payloads
array of every QSVFrame leaks as soon as the frame is reused;
the leak is small and not very noticeable, but if there is an attempt
to use said array the ensuing crash is much more noticeable.
This happens when encoding H.264 with A53 CC side data.

Furthermore, if said array can not be allocated at all, an AVFrame
leaks.

Fix all of this by not allocating the array separately at all; put it
in QSVFrame instead and restore the Payloads array upon reusing the
frame.

Finally, use av_freep() instead of av_free() to free the payload
entries.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/qsv_internal.h |  2 ++
 libavcodec/qsvenc.c   | 10 +++---
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/libavcodec/qsv_internal.h b/libavcodec/qsv_internal.h
index 8090b748b3..fe9d5319c4 100644
--- a/libavcodec/qsv_internal.h
+++ b/libavcodec/qsv_internal.h
@@ -76,6 +76,8 @@ typedef struct QSVFrame {
 mfxExtDecodedFrameInfo dec_info;
 mfxExtBuffer *ext_param;
 
+mfxPayload *payloads[QSV_MAX_ENC_PAYLOAD]; ///< used for enc_ctrl.Payload
+
 int queued;
 int used;
 
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 06f55604b5..66f79bb021 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -1259,7 +1259,7 @@ static void free_encoder_ctrl_payloads(mfxEncodeCtrl* 
enc_ctrl)
 if (enc_ctrl) {
 int i;
 for (i = 0; i < enc_ctrl->NumPayload && i < QSV_MAX_ENC_PAYLOAD; i++) {
-av_free(enc_ctrl->Payload[i]);
+av_freep(&enc_ctrl->Payload[i]);
 }
 enc_ctrl->NumPayload = 0;
 }
@@ -1273,6 +1273,7 @@ static void clear_unused_frames(QSVEncContext *q)
 free_encoder_ctrl_payloads(&cur->enc_ctrl);
 //do not reuse enc_ctrl from previous frame
 memset(&cur->enc_ctrl, 0, sizeof(cur->enc_ctrl));
+cur->enc_ctrl.Payload = cur->payloads;
 if (cur->frame->format == AV_PIX_FMT_QSV) {
 av_frame_unref(cur->frame);
 }
@@ -1309,11 +1310,7 @@ static int get_free_frame(QSVEncContext *q, QSVFrame **f)
 av_freep(&frame);
 return AVERROR(ENOMEM);
 }
-frame->enc_ctrl.Payload = av_mallocz(sizeof(mfxPayload*) * 
QSV_MAX_ENC_PAYLOAD);
-if (!frame->enc_ctrl.Payload) {
-av_freep(&frame);
-return AVERROR(ENOMEM);
-}
+frame->enc_ctrl.Payload = frame->payloads;
 *last = frame;
 
 *f = frame;
@@ -1615,7 +1612,6 @@ int ff_qsv_enc_close(AVCodecContext *avctx, QSVEncContext 
*q)
 while (cur) {
 q->work_frames = cur->next;
 av_frame_free(&cur->frame);
-av_free(cur->enc_ctrl.Payload);
 av_freep(&cur);
 cur = q->work_frames;
 }
-- 
2.30.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 2/6] avcodec/qsvenc: Fix leak of A53 data

[Andreas Rheinhardt]

Up until now, it has only been freed when the QSVFrame is reused,
so that the last one contained in it leaked at the end.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/qsvenc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 66f79bb021..e5d09752cb 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -1612,6 +1612,7 @@ int ff_qsv_enc_close(AVCodecContext *avctx, QSVEncContext 
*q)
 while (cur) {
 q->work_frames = cur->next;
 av_frame_free(&cur->frame);
+free_encoder_ctrl_payloads(&cur->enc_ctrl);
 av_freep(&cur);
 cur = q->work_frames;
 }
-- 
2.30.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 3/6] avcodec/qsvenc: Properly flush the FIFO on close

[Andreas Rheinhardt]

Freeing the new H.264 specific fields has been forgotten.
(This leak only appears in case the encoder has not been completely
drained.)

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/qsvenc.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index e5d09752cb..26a94cd419 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -1626,6 +1626,14 @@ int ff_qsv_enc_close(AVCodecContext *avctx, 
QSVEncContext *q)
 av_fifo_generic_read(q->async_fifo, &sync, sizeof(sync), NULL);
 av_fifo_generic_read(q->async_fifo, &bs,   sizeof(bs),   NULL);
 
+#if QSV_VERSION_ATLEAST(1, 26)
+if (avctx->codec_id == AV_CODEC_ID_H264) {
+mfxExtBuffer **enc_buf = bs->ExtParam;
+mfxExtAVCEncodedFrameInfo *enc_info = (mfxExtAVCEncodedFrameInfo 
*)(*bs->ExtParam);
+av_freep(&enc_info);
+av_freep(&enc_buf);
+}
+#endif
 av_freep(&sync);
 av_freep(&bs);
 av_packet_unref(&pkt);
-- 
2.30.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 4/6] avcodec/qsvenc: Combine multiple allocations

[Andreas Rheinhardt]

It makes the cleanup code smaller (and reduces the amount of
allocations).

Signed-off-by: Andreas Rheinhardt 
---
Better naming suggestions for the structures welcome.

One could also stop using an av_fifo altogether and use an ordinary
array (that is only allocated once) with FIFO semantics.
Or one could combine the AVPacket and the pointer to the new structure
to one structure, so that one can read and write it from/to the FIFO
in one call.

 libavcodec/qsvenc.c | 111 ++--
 1 file changed, 46 insertions(+), 65 deletions(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 26a94cd419..1650d89a17 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -111,6 +111,19 @@ static const struct {
 #endif
 };
 
+typedef struct QSVTmp {
+mfxBitstream bs;
+mfxSyncPoint sync;
+} QSVTmp;
+
+#if QSV_VERSION_ATLEAST(1, 26)
+typedef struct QSVH264Tmp {
+QSVTmp common;
+mfxExtAVCEncodedFrameInfo enc_info;
+mfxExtBuffer *enc_buf;
+} QSVH264Tmp;
+#endif
+
 static const char *print_ratecontrol(mfxU16 rc_mode)
 {
 int i;
@@ -1110,7 +1123,7 @@ static int qsvenc_init_session(AVCodecContext *avctx, 
QSVEncContext *q)
 
 static inline unsigned int qsv_fifo_item_size(void)
 {
-return sizeof(AVPacket) + sizeof(mfxSyncPoint*) + sizeof(mfxBitstream*);
+return sizeof(AVPacket) + sizeof(QSVTmp*);
 }
 
 static inline unsigned int qsv_fifo_size(const AVFifoBuffer* fifo)
@@ -1414,16 +1427,12 @@ static int encode_frame(AVCodecContext *avctx, 
QSVEncContext *q,
 const AVFrame *frame)
 {
 AVPacket new_pkt = { 0 };
-mfxBitstream *bs = NULL;
-#if QSV_VERSION_ATLEAST(1, 26)
-mfxExtAVCEncodedFrameInfo *enc_info = NULL;
-mfxExtBuffer **enc_buf = NULL;
-#endif
+QSVTmp *tmp_struct;
 
 mfxFrameSurface1 *surf = NULL;
-mfxSyncPoint *sync = NULL;
 QSVFrame *qsv_frame = NULL;
 mfxEncodeCtrl* enc_ctrl = NULL;
+size_t alloc_size;
 int ret;
 
 if (frame) {
@@ -1443,34 +1452,36 @@ static int encode_frame(AVCodecContext *avctx, 
QSVEncContext *q,
 enc_ctrl->FrameType |= MFX_FRAMETYPE_IDR;
 }
 }
-
 ret = av_new_packet(&new_pkt, q->packet_size);
 if (ret < 0) {
 av_log(avctx, AV_LOG_ERROR, "Error allocating the output packet\n");
 return ret;
 }
-
-bs = av_mallocz(sizeof(*bs));
-if (!bs)
-goto nomem;
-bs->Data  = new_pkt.data;
-bs->MaxLength = new_pkt.size;
+alloc_size = sizeof(QSVTmp);
+#if QSV_VERSION_ATLEAST(1, 26)
+if (avctx->codec_id == AV_CODEC_ID_H264)
+alloc_size = sizeof(QSVH264Tmp);
+#endif
+tmp_struct = av_mallocz(alloc_size);
+if (!tmp_struct) {
+ret = AVERROR(ENOMEM);
+goto free;
+}
+tmp_struct->bs.Data  = new_pkt.data;
+tmp_struct->bs.MaxLength = new_pkt.size;
 
 #if QSV_VERSION_ATLEAST(1, 26)
 if (avctx->codec_id == AV_CODEC_ID_H264) {
-enc_info = av_mallocz(sizeof(*enc_info));
-if (!enc_info)
-goto nomem;
+QSVH264Tmp *const h264_tmp_struct = (QSVH264Tmp*)tmp_struct;
+mfxExtAVCEncodedFrameInfo *const enc_info = &h264_tmp_struct->enc_info;
+mfxExtBuffer **const enc_buf = &h264_tmp_struct->enc_buf;
 
 enc_info->Header.BufferId = MFX_EXTBUFF_ENCODED_FRAME_INFO;
 enc_info->Header.BufferSz = sizeof (*enc_info);
-bs->NumExtParam = 1;
-enc_buf = av_mallocz(sizeof(mfxExtBuffer *));
-if (!enc_buf)
-goto nomem;
+tmp_struct->bs.NumExtParam = 1;
 enc_buf[0] = (mfxExtBuffer *)enc_info;
 
-bs->ExtParam = enc_buf;
+tmp_struct->bs.ExtParam = enc_buf;
 }
 #endif
 
@@ -1478,12 +1489,9 @@ static int encode_frame(AVCodecContext *avctx, 
QSVEncContext *q,
 q->set_encode_ctrl_cb(avctx, frame, &qsv_frame->enc_ctrl);
 }
 
-sync = av_mallocz(sizeof(*sync));
-if (!sync)
-goto nomem;
-
 do {
-ret = MFXVideoENCODE_EncodeFrameAsync(q->session, enc_ctrl, surf, bs, 
sync);
+ret = MFXVideoENCODE_EncodeFrameAsync(q->session, enc_ctrl, surf,
+  &tmp_struct->bs, 
&tmp_struct->sync);
 if (ret == MFX_WRN_DEVICE_BUSY)
 av_usleep(500);
 } while (ret == MFX_WRN_DEVICE_BUSY || ret == MFX_WRN_IN_EXECUTION);
@@ -1502,27 +1510,16 @@ static int encode_frame(AVCodecContext *avctx, 
QSVEncContext *q,
 
 ret = 0;
 
-if (*sync) {
+if (tmp_struct->sync) {
 av_fifo_generic_write(q->async_fifo, &new_pkt, sizeof(new_pkt), NULL);
-av_fifo_generic_write(q->async_fifo, &sync,sizeof(sync),NULL);
-av_fifo_generic_write(q->async_fifo, &bs,  sizeof(bs),NULL);
+av_fifo_generic_write(q->async_fifo, &tmp_struct, sizeof(tmp_struct), 
NULL);
 } else {
 free:
-av_freep(&sync);
+av_freep(&tmp_struct);
 av_packet_unref(&new_pkt);
-av_freep(&bs);
-#if QSV_VERSIO

[FFmpeg-devel] [PATCH 5/6] avutil/hwcontext_qsv: Fix leak of AVBuffer and AVBufferRef

[Andreas Rheinhardt]

This av_buffer_create() does nothing but leak an AVBuffer and an
AVBufferRef (except on allocation error).

Fixes Coverity issue 1491393.

Signed-off-by: Andreas Rheinhardt 
---
 libavutil/hwcontext_qsv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index c18747f7eb..4ed50a31a0 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -235,8 +235,6 @@ static AVBufferRef *qsv_pool_alloc(void *opaque, size_t 
size)
 
 if (s->nb_surfaces_used < hwctx->nb_surfaces) {
 s->nb_surfaces_used++;
-av_buffer_create((uint8_t*)(s->handle_pairs_internal + 
s->nb_surfaces_used - 1),
-sizeof(*s->handle_pairs_internal), 
qsv_pool_release_dummy, NULL, 0);
 return av_buffer_create((uint8_t*)(s->surfaces_internal + 
s->nb_surfaces_used - 1),
 sizeof(*hwctx->surfaces), 
qsv_pool_release_dummy, NULL, 0);
 }
-- 
2.30.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] avutil/hwcontext_qsv: Remove redundant check

[Andreas Rheinhardt]

It has already been checked immediately before that said
AVDictionaryEntry exists; checking again is redundant.
Furthermore, av_hwdevice_find_type_by_name() requires its argument
to be non-NULL, so adding a codepath that automatically calls it
with that parameter is nonsense. The same goes for the argument
corresponding to %s.

Fixes Coverity issue 1491394.

Signed-off-by: Andreas Rheinhardt 
---
If one wanted to sanitize something here, one should check for
"if (e && e->value)" instead. Or unconditionally error out if (e &&
!e->value).

 libavutil/hwcontext_qsv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index 4ed50a31a0..268be9f8a1 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -1463,10 +1463,10 @@ static int qsv_device_create(AVHWDeviceContext *ctx, 
const char *device,
 
 e = av_dict_get(opts, "child_device_type", NULL, 0);
 if (e) {
-child_device_type = av_hwdevice_find_type_by_name(e ? e->value : NULL);
+child_device_type = av_hwdevice_find_type_by_name(e->value);
 if (child_device_type == AV_HWDEVICE_TYPE_NONE) {
 av_log(ctx, AV_LOG_ERROR, "Unknown child device type "
-   "\"%s\".\n", e ? e->value : NULL);
+   "\"%s\".\n", e->value);
 return AVERROR(EINVAL);
 }
 } else if (CONFIG_VAAPI) {
-- 
2.30.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".