Re: [FFmpeg-devel] [PATCH] fate: add tests for xHE-AAC

[Paul B Mahol]

On Tue, May 21, 2024 at 4:05 AM Lynne via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:

> Starting off small with a few features.
> Samples and reference decoded files copied from the official ISO
> reference suite.
>

Sorry for my ignorance, but is such copy allowed from them?

---
> Samples and references: https://files.lynne.ee/xhe_refs/
>
>  tests/fate/aac.mak | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/tests/fate/aac.mak b/tests/fate/aac.mak
> index 817944773d..ff58392ad9 100644
> --- a/tests/fate/aac.mak
> +++ b/tests/fate/aac.mak
> @@ -62,6 +62,14 @@ FATE_AAC += fate-aac-ap05_48
>  fate-aac-ap05_48: CMD = pcm -i $(TARGET_SAMPLES)/aac/ap05_48.mp4
>  fate-aac-ap05_48: REF = $(SAMPLES)/aac/ap05_48.s16
>
> +FATE_AAC += fate-aac-fd_2_c1_ms_0x01
> +fate-aac-fd_2_c1_ms_0x01: CMD = pcm -i
> $(TARGET_SAMPLES)/aac/Fd_2_c1_Ms_0x01.mp4
> +fate-aac-fd_2_c1_ms_0x01: REF = $(SAMPLES)/aac/Fd_2_c1_Ms_0x01.s16
> +
> +FATE_AAC += fate-aac-fd_2_c1_ms_0x04
> +fate-aac-fd_2_c1_ms_0x04: CMD = pcm -i
> $(TARGET_SAMPLES)/aac/Fd_2_c1_Ms_0x04.mp4
> +fate-aac-fd_2_c1_ms_0x04: REF = $(SAMPLES)/aac/Fd_2_c1_Ms_0x04.s16
> +
>  FATE_AAC += fate-aac-er_ad6000np_44_ep0
>  fate-aac-er_ad6000np_44_ep0: CMD = pcm -i
> $(TARGET_SAMPLES)/aac/er_ad6000np_44_ep0.mp4
>  fate-aac-er_ad6000np_44_ep0: REF = $(SAMPLES)/aac/er_ad6000np_44.s16
> --
> 2.43.0.381.gb435a96ce8
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v3 1/3] avfilter/af_volumedetect.c: Move logdb function

[Paul B Mahol]

On Mon, May 20, 2024 at 10:25 PM Yigithan Yigit <
yigithanyigitde...@gmail.com> wrote:

> ---
>  libavfilter/af_volumedetect.c | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
> index 8b001d1cf2..327801a7f9 100644
> --- a/libavfilter/af_volumedetect.c
> +++ b/libavfilter/af_volumedetect.c
> @@ -24,6 +24,8 @@
>  #include "avfilter.h"
>  #include "internal.h"
>
> +#define MAX_DB 91
> +
>

That is only true for 16bit input files, not for floats.


>  typedef struct VolDetectContext {
>  /**
>   * Number of samples at each PCM value.
> @@ -33,6 +35,14 @@ typedef struct VolDetectContext {
>  uint64_t histogram[0x10001];
>  } VolDetectContext;
>
> +static inline double logdb(uint64_t v)
> +{
> +double d = v / (double)(0x8000 * 0x8000);
> +if (!v)
> +return MAX_DB;
> +return -log10(d) * 10;
> +}
> +
>  static int filter_frame(AVFilterLink *inlink, AVFrame *samples)
>  {
>  AVFilterContext *ctx = inlink->dst;
> @@ -56,16 +66,6 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *samples)
>  return ff_filter_frame(inlink->dst->outputs[0], samples);
>  }
>
> -#define MAX_DB 91
> -
> -static inline double logdb(uint64_t v)
> -{
> -double d = v / (double)(0x8000 * 0x8000);
> -if (!v)
> -return MAX_DB;
> -return -log10(d) * 10;
> -}
> -
>  static void print_stats(AVFilterContext *ctx)
>  {
>  VolDetectContext *vd = ctx->priv;
> --
> 2.44.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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v3 1/3] avfilter/af_volumedetect.c: Move logdb function

[Paul B Mahol]

On Tue, May 21, 2024 at 9:20 AM Paul B Mahol  wrote:

>
>
> On Mon, May 20, 2024 at 10:25 PM Yigithan Yigit <
> yigithanyigitde...@gmail.com> wrote:
>
>> ---
>>  libavfilter/af_volumedetect.c | 20 ++--
>>  1 file changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
>> index 8b001d1cf2..327801a7f9 100644
>> --- a/libavfilter/af_volumedetect.c
>> +++ b/libavfilter/af_volumedetect.c
>> @@ -24,6 +24,8 @@
>>  #include "avfilter.h"
>>  #include "internal.h"
>>
>> +#define MAX_DB 91
>> +
>>
>
> That is only true for 16bit input files, not for floats.
>

Ignore this, its just split patch

>
>
>>  typedef struct VolDetectContext {
>>  /**
>>   * Number of samples at each PCM value.
>> @@ -33,6 +35,14 @@ typedef struct VolDetectContext {
>>  uint64_t histogram[0x10001];
>>  } VolDetectContext;
>>
>> +static inline double logdb(uint64_t v)
>> +{
>> +double d = v / (double)(0x8000 * 0x8000);
>> +if (!v)
>> +return MAX_DB;
>> +return -log10(d) * 10;
>> +}
>> +
>>  static int filter_frame(AVFilterLink *inlink, AVFrame *samples)
>>  {
>>  AVFilterContext *ctx = inlink->dst;
>> @@ -56,16 +66,6 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
>> *samples)
>>  return ff_filter_frame(inlink->dst->outputs[0], samples);
>>  }
>>
>> -#define MAX_DB 91
>> -
>> -static inline double logdb(uint64_t v)
>> -{
>> -double d = v / (double)(0x8000 * 0x8000);
>> -if (!v)
>> -return MAX_DB;
>> -return -log10(d) * 10;
>> -}
>> -
>>  static void print_stats(AVFilterContext *ctx)
>>  {
>>  VolDetectContext *vd = ctx->priv;
>> --
>> 2.44.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 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] area changed: scdet filter

[Paul B Mahol]

On Tue, May 28, 2024 at 9:51 AM  wrote:

> > -Original Message-
> > From: radu.taraib...@gmail.com 
> > Sent: duminică, 19 mai 2024 19:05
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: RE: [PATCH] area changed: scdet filter
> >
> >
> > > -Original Message-
> > > From: radu.taraib...@gmail.com 
> > > Sent: luni, 13 mai 2024 18:52
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: [PATCH] area changed: scdet filter
> > >
> > > Previous observations:
> > >
> > >  - Inconsistent code style with other filters. (Mostly using
> > > AVFilterLink* link instead of AVFilterLink *link).
> > > I hope it's fine now.
> > >
> > >  - Unrelated changes, please split trivial unrelated changes into
> > > separate patches.
> > > Removed trivial changes from this patch.
> > >
> > >  - Can't tables be generated at .init/.config_props time? No point in
> > > storing them into binary.
> > > Done.
> > >
> > >  - Adding extra delay is not backward compatible change, it should be
> > > implemented properly by adding option for users to select mode: next &
> > prev
> > > frame or just next or prev frame.
> > > Added legacy option to the mode parameter.
> > >
> > >  - Could split frame clone change into earlier separate patch.
> > > Cannot be done. It's either frame clone or 1 frame delay.
> > >
> > >  - Where are results of improvements with accuracy so it can be
> confirmed?
> > > Here are my test results with manual labeling of scene changes:
> > > 2379Full length movie
> > >
> > > Method  Threshold   TP  FP  FN  Precision
> > > Recall  F
> > > Cubic   7   2357423 22  0.847841727
> 0.990752417
> > > 0.913742973
> > > Cubic   10  2297200 82  0.919903885
> 0.965531736
> > > 0.94216571
> > > Cubic   12  2217146 162 0.938214135
> 0.931904161
> > > 0.935048503
> > > Cubic   15  2049101 330 0.953023256
> 0.861286255
> > > 0.904835505
> > > Linear  2.8 2357106022  0.689786362
> > 0.990752417
> > > 0.813319531
> > > Linear  8   2099236 280 0.898929336
> > 0.882303489
> > > 0.890538821
> > > Linear  10  1886173 493 0.91597863
> > 0.792770071
> > > 0.849932402
> > > Legacy  5   22351260144 0.639484979
> > 0.939470366
> > > 0.760980592
> > > Legacy  8   1998414 381 0.828358209
> > 0.839848676
> > > 0.83406387
> > > Legacy  10  1743193 636 0.900309917
> > 0.732660782
> > > 0.80787949
> > >
> > > 15  HDR10Plus_PB_EAC3JOC
> > > https://mega.nz/file/nehDka6Z#C5_OPbSZkONdOp1jRmc09C9-
> > > viDc3zMj8ZHruHcWKyA
> > >
> > > Method  Threshold   TP  FP  FN  Precision
> > > Recall  F
> > > Cubic   10  15  0   0   1   1   1
> > > Linear  5   13  1   2   0.928571429
> > 0.86667
> > > 0.896551724
> > > Legacy  5   12  2   3   0.857142857 0.8
> > > 0.827586207
> > >
> > > 21  (HDR HEVC 10-bit BT.2020 24fps) Exodus Sample
> > >
> > https://mega.nz/file/Sfw1hDpK#ErxCOpQDVjcI1gq6ZbX3vIfdtXZompkFe0jq47E
> > > hR2o
> > >
> > > Method  Threshold   TP  FP  FN  Precision
> > > Recall  F
> > > Cubic   10  21  0   0   1   1   1
> > > Linear  4   20  0   1   1   0.952380952
> > > 0.975609756
> > > Legacy  4   19  0   2   1   0.904761905
> > 0.95
> > >
> > > 94  Bieber Grammys
> > > https://mega.nz/#!c9dhAaKA!MG5Yi-
> > > MJNATE2_KqcnNJZCRKtTWvdjJP1NwG8Ggdw3E
> > >
> > > Method  Threshold   TP  FP  FN  Precision
> > > Recall  F
> > > Cubic   15  91  23  3   0.798245614
> 0.968085106
> > > 0.875
> > > Cubic   18  85  9   9   0.904255319
> 0.904255319
> > > 0.904255319
> > > Linear  7   79  49  15  0.6171875
> > 0.840425532
> > > 0.711711712
> > > Linear  8   74  28  20  0.725490196
> > 0.787234043
> > > 0.755102041
> > > Legacy  7   74  40  20  0.649122807
> > 0.787234043
> > > 0.711538462
> > > Legacy  8   71  26  23  0.731958763
> > 0.755319149
> > > 0.743455497
> > >
> > >
> > > Improve scene detection accuracy by comparing frame with both previous
> > > and next frame (creates one frame delay).
> > > Add new mode parameter and new method to compute the frame difference
> > > using cubic square to increase the weight of small changes and new
> > > mean formula.
> > > This improves accuracy significantly. Slightly improve performance by
> > > not using frame clone.
> > > Add legacy mode for backward compatibility.
> > >
> > > Signed-off-by: raduct 
> > > ---
> > >  doc/filters.texi   

Re: [FFmpeg-devel] [PATCH v4 1/4] doc: Explain what "context" means

[Paul B Mahol]

On Wed, May 29, 2024 at 12:50 PM Andrew Sayers 
wrote:

> Posting this separately, as these are practical "how does FFmpeg work"
> issues
> vaguely inspired by recent discussions.
>
>
> *How do namespaces work in FFmpeg?*
>
> We've talked a bit about function namespaces recently.  One reason I've
> suggested they're a weak signal is because they aren't really addressed in
> the
> documentation.  How about adding something like this to the context doc:
>
> Most FFmpeg functions are grouped into namespaces, usually indicated by
> prefixes (e.g. `av_format_*`) but sometimes indicated by infixes
> (e.g. av_alloc_format_context()).  Namespaces group functions by
> *topic*,
> which doesn't always correlate with *context*.  For example,
> `av_find_*`
> functions search for information across various contexts.
>
>
> *Should external API devs treat Sw{r,s}Context as AVClass context
> structures?*
>
> This is probably an uninteresting edge case, but just to be sure...
>
> The website says Sw{r,s}Context start with AVClass[1], they have _get_class
> functions, are shown in `ffmpeg -h full`, and I haven't found anything
> that says
> to treat them differently to e.g. AVCodecContext.  So I'm pretty sure these
> are AVClass context structures, at least as far as internal devs are
> concerned.
>
> But their definitions are only in the private interface, so the layout is
> just
> an implementation detail that can change without even a major version bump.
> AVFrame used to have a _get_class function despite never having an actual
> AVClass member, so that's not a signal to external API devs.  And
> `URLContext`
> appears in `ffmpeg -h full` despite having being made private long ago,
> so that's not much of a signal either.
>
> My guess is that the above should be addressed with a patch like:
>
> +/**
> + * @brief Context for SWResampler
> + *
> + * @note The public ABI only guarantees this is an AVOptions-enabled
> struct.
> + * Its size and other members are not a part of the public ABI.
> + *
> + * @see
> + * - @ref Context
> + */
>  struct SwrContext {
>
> Let me know if the above is on the right track.  If so, I'll queue up a
> patch
> for after the context document is done.
>
>
> *Are AVOptions just command-line options?*
>
> I have trouble with statements like "AVOptions is a framework for options",
> both because it's circular and because the term "option" is too broad to be
> meaningful.
>
> I've previously pushed the word "reflection" on the assumption that options
> can be used anywhere variables are used.  For example, imagine a decoder
> that
> could be reconfigured on-the-fly to reduce CPU usage at the cost of
> displaying
> blurier images.  That can't be part of the public interface because it's
> codec-specific, but I could imagine updating some kind of "output_quality"
> AVOption as a user slides a slider up and down.
>
> But the CLI tools are largely non-interactive, so have I just
> misunderstood?
>
> How about saying "AVOptions is a framework for command-line options"?
>

ffmpeg is cli tool

libavfilter is library

AVOptions is certainly and primarily not framework for command-line options.


>
> [1] https://ffmpeg.org/doxygen/trunk/structSwrContext.html
> ___
> 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] [RFC] STF 2025

[Paul B Mahol]

On Tue, Jun 4, 2024 at 8:53 AM Vittorio Giovara 
wrote:

> On Tue, Jun 4, 2024 at 3:01 AM Cosmin Stejerean via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
>
> > > Reposting my question/comment here since Thilo hasn't had a chance to
> > > respond, but shouldn't these kinds of requests go through the GA? If
> > > anybody can do whatever they want with the ffmpeg name, then what's the
> > > point of voting and following the established process?
> >
> > Probably? I'm not actually sure what the process is for getting an FFmpeg
> > booth at a conference. Is there a documented process somewhere for how
> this
> > should be done? If not this might be a good opportunity to create one.
> >
>
> Agreed, do you have a draft you could share as a base of discussion? Once
> defined, we could have the GA vote on it
>
>
> > It might also make for a good topic of discussion at VDD. For how much
> > drama there was about NAB on the list I was surprised there was zero
> > discussion about it at FOSDEM.
> >
>
> There were probably more important topics to discuss and the lingering hope
> that the problematic points would have been handled better than by calling
> people trolls
>
>
> > Regarding the "or you" part, I wasn't involved in securing sponsorship
> for
> > NAB or IBC. I did volunteer to help with NAB because I happen to live in
> > Vegas and I enjoy spending time with other ffmpeg developers. I'm happy
> to
> > help at NAB next year as well should it happen again.
> >
>
> Noted, it should have said "or anybody willing to host/help a booth"
>
> I have no plans to attend IBC and no involvement with the FFmpeg booth at
> > IBC. I am merely trying to correct the perception that NAB was
> > cost-problematic, since no money was paid by the project for NAB.
> >
>
> I don't think anybody is suggesting that booths are cost-problematic, but
> rather they are lacking in process (one shouldn't allowed use ffmpeg name
> "just because") and in scope (aka "the why" and what kind of results are
> expected by investing time in said booth)
>

Said by prominent LibAV developer.


> --
> Vittorio
> ___
> 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] [RFC] STF 2025

[Paul B Mahol]

On Tue, Jun 4, 2024 at 9:09 AM Vittorio Giovara 
wrote:

> On Tue, Jun 4, 2024 at 8:55 AM Paul B Mahol  wrote:
>
> > On Tue, Jun 4, 2024 at 8:53 AM Vittorio Giovara <
> > vittorio.giov...@gmail.com>
> > wrote:
> >
> > > On Tue, Jun 4, 2024 at 3:01 AM Cosmin Stejerean via ffmpeg-devel <
> > > ffmpeg-devel@ffmpeg.org> wrote:
> > >
> > > > > Reposting my question/comment here since Thilo hasn't had a chance
> to
> > > > > respond, but shouldn't these kinds of requests go through the GA?
> If
> > > > > anybody can do whatever they want with the ffmpeg name, then what's
> > the
> > > > > point of voting and following the established process?
> > > >
> > > > Probably? I'm not actually sure what the process is for getting an
> > FFmpeg
> > > > booth at a conference. Is there a documented process somewhere for
> how
> > > this
> > > > should be done? If not this might be a good opportunity to create
> one.
> > > >
> > >
> > > Agreed, do you have a draft you could share as a base of discussion?
> Once
> > > defined, we could have the GA vote on it
> > >
> > >
> > > > It might also make for a good topic of discussion at VDD. For how
> much
> > > > drama there was about NAB on the list I was surprised there was zero
> > > > discussion about it at FOSDEM.
> > > >
> > >
> > > There were probably more important topics to discuss and the lingering
> > hope
> > > that the problematic points would have been handled better than by
> > calling
> > > people trolls
> > >
> > >
> > > > Regarding the "or you" part, I wasn't involved in securing
> sponsorship
> > > for
> > > > NAB or IBC. I did volunteer to help with NAB because I happen to live
> > in
> > > > Vegas and I enjoy spending time with other ffmpeg developers. I'm
> happy
> > > to
> > > > help at NAB next year as well should it happen again.
> > > >
> > >
> > > Noted, it should have said "or anybody willing to host/help a booth"
> > >
> > > I have no plans to attend IBC and no involvement with the FFmpeg booth
> at
> > > > IBC. I am merely trying to correct the perception that NAB was
> > > > cost-problematic, since no money was paid by the project for NAB.
> > > >
> > >
> > > I don't think anybody is suggesting that booths are cost-problematic,
> but
> > > rather they are lacking in process (one shouldn't allowed use ffmpeg
> name
> > > "just because") and in scope (aka "the why" and what kind of results
> are
> > > expected by investing time in said booth)
> > >
> >
> > Said by prominent LibAV developer.
> >
>
> reported to CC :)
>

CC is fully controlled by prominent LibAV developers.


> --
> Vittorio
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v3] avcodec: add farbfeld encoder

[Paul B Mahol]

Encoder without decoder?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [RFC] STF 2025

[Paul B Mahol]

On Tue, Jun 4, 2024 at 12:59 PM Vittorio Giovara 
wrote:

> On Tue, Jun 4, 2024 at 12:09 PM Paul B Mahol  wrote:
>
> > On Tue, Jun 4, 2024 at 9:09 AM Vittorio Giovara <
> > vittorio.giov...@gmail.com>
> > wrote:
> >
> > > On Tue, Jun 4, 2024 at 8:55 AM Paul B Mahol  wrote:
> > >
> > > > On Tue, Jun 4, 2024 at 8:53 AM Vittorio Giovara <
> > > > vittorio.giov...@gmail.com>
> > > > wrote:
> > > >
> > > > > On Tue, Jun 4, 2024 at 3:01 AM Cosmin Stejerean via ffmpeg-devel <
> > > > > ffmpeg-devel@ffmpeg.org> wrote:
> > > > >
> > > > > > > Reposting my question/comment here since Thilo hasn't had a
> > chance
> > > to
> > > > > > > respond, but shouldn't these kinds of requests go through the
> GA?
> > > If
> > > > > > > anybody can do whatever they want with the ffmpeg name, then
> > what's
> > > > the
> > > > > > > point of voting and following the established process?
> > > > > >
> > > > > > Probably? I'm not actually sure what the process is for getting
> an
> > > > FFmpeg
> > > > > > booth at a conference. Is there a documented process somewhere
> for
> > > how
> > > > > this
> > > > > > should be done? If not this might be a good opportunity to create
> > > one.
> > > > > >
> > > > >
> > > > > Agreed, do you have a draft you could share as a base of
> discussion?
> > > Once
> > > > > defined, we could have the GA vote on it
> > > > >
> > > > >
> > > > > > It might also make for a good topic of discussion at VDD. For how
> > > much
> > > > > > drama there was about NAB on the list I was surprised there was
> > zero
> > > > > > discussion about it at FOSDEM.
> > > > > >
> > > > >
> > > > > There were probably more important topics to discuss and the
> > lingering
> > > > hope
> > > > > that the problematic points would have been handled better than by
> > > > calling
> > > > > people trolls
> > > > >
> > > > >
> > > > > > Regarding the "or you" part, I wasn't involved in securing
> > > sponsorship
> > > > > for
> > > > > > NAB or IBC. I did volunteer to help with NAB because I happen to
> > live
> > > > in
> > > > > > Vegas and I enjoy spending time with other ffmpeg developers. I'm
> > > happy
> > > > > to
> > > > > > help at NAB next year as well should it happen again.
> > > > > >
> > > > >
> > > > > Noted, it should have said "or anybody willing to host/help a
> booth"
> > > > >
> > > > > I have no plans to attend IBC and no involvement with the FFmpeg
> > booth
> > > at
> > > > > > IBC. I am merely trying to correct the perception that NAB was
> > > > > > cost-problematic, since no money was paid by the project for NAB.
> > > > > >
> > > > >
> > > > > I don't think anybody is suggesting that booths are
> cost-problematic,
> > > but
> > > > > rather they are lacking in process (one shouldn't allowed use
> ffmpeg
> > > name
> > > > > "just because") and in scope (aka "the why" and what kind of
> results
> > > are
> > > > > expected by investing time in said booth)
> > > > >
> > > >
> > > > Said by prominent LibAV developer.
> > > >
> > >
> > > reported to CC :)
> > >
> >
> > CC is fully controlled by prominent LibAV developers.
> >
>
> Not only is this factually incorrect, it's also unrelated to the topic at
> hand. No worries, this infringement is being reported to the CC as well,
> but please try to make an effort at doing better at least.
> Thank you
>

Do not trust LibAV developers even when they are giving you gifts.


> --
> Vittorio
> ___
> 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] [RFC] STF 2025

[Paul B Mahol]

On Tue, Jun 4, 2024 at 2:53 PM Vittorio Giovara 
wrote:

> On Tue, Jun 4, 2024 at 2:02 PM Paul B Mahol  wrote:
>
> > On Tue, Jun 4, 2024 at 12:59 PM Vittorio Giovara <
> > vittorio.giov...@gmail.com>
> > wrote:
> >
> > > On Tue, Jun 4, 2024 at 12:09 PM Paul B Mahol  wrote:
> > >
> > > > On Tue, Jun 4, 2024 at 9:09 AM Vittorio Giovara <
> > > > vittorio.giov...@gmail.com>
> > > > wrote:
> > > >
> > > > > On Tue, Jun 4, 2024 at 8:55 AM Paul B Mahol 
> > wrote:
> > > > >
> > > > > > On Tue, Jun 4, 2024 at 8:53 AM Vittorio Giovara <
> > > > > > vittorio.giov...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > On Tue, Jun 4, 2024 at 3:01 AM Cosmin Stejerean via
> ffmpeg-devel
> > <
> > > > > > > ffmpeg-devel@ffmpeg.org> wrote:
> > > > > > >
> > > > > > > > > Reposting my question/comment here since Thilo hasn't had a
> > > > chance
> > > > > to
> > > > > > > > > respond, but shouldn't these kinds of requests go through
> the
> > > GA?
> > > > > If
> > > > > > > > > anybody can do whatever they want with the ffmpeg name,
> then
> > > > what's
> > > > > > the
> > > > > > > > > point of voting and following the established process?
> > > > > > > >
> > > > > > > > Probably? I'm not actually sure what the process is for
> getting
> > > an
> > > > > > FFmpeg
> > > > > > > > booth at a conference. Is there a documented process
> somewhere
> > > for
> > > > > how
> > > > > > > this
> > > > > > > > should be done? If not this might be a good opportunity to
> > create
> > > > > one.
> > > > > > > >
> > > > > > >
> > > > > > > Agreed, do you have a draft you could share as a base of
> > > discussion?
> > > > > Once
> > > > > > > defined, we could have the GA vote on it
> > > > > > >
> > > > > > >
> > > > > > > > It might also make for a good topic of discussion at VDD. For
> > how
> > > > > much
> > > > > > > > drama there was about NAB on the list I was surprised there
> was
> > > > zero
> > > > > > > > discussion about it at FOSDEM.
> > > > > > > >
> > > > > > >
> > > > > > > There were probably more important topics to discuss and the
> > > > lingering
> > > > > > hope
> > > > > > > that the problematic points would have been handled better than
> > by
> > > > > > calling
> > > > > > > people trolls
> > > > > > >
> > > > > > >
> > > > > > > > Regarding the "or you" part, I wasn't involved in securing
> > > > > sponsorship
> > > > > > > for
> > > > > > > > NAB or IBC. I did volunteer to help with NAB because I happen
> > to
> > > > live
> > > > > > in
> > > > > > > > Vegas and I enjoy spending time with other ffmpeg developers.
> > I'm
> > > > > happy
> > > > > > > to
> > > > > > > > help at NAB next year as well should it happen again.
> > > > > > > >
> > > > > > >
> > > > > > > Noted, it should have said "or anybody willing to host/help a
> > > booth"
> > > > > > >
> > > > > > > I have no plans to attend IBC and no involvement with the
> FFmpeg
> > > > booth
> > > > > at
> > > > > > > > IBC. I am merely trying to correct the perception that NAB
> was
> > > > > > > > cost-problematic, since no money was paid by the project for
> > NAB.
> > > > > > > >
> > > > > > >
> > > > > > > I don't think anybody is suggesting that booths are
> > > cost-problematic,
> > > > > but
> > > > > > > rather they are lacking in pr

Re: [FFmpeg-devel] [PATCH] lavu/opt: Mention that AVOptions is not reentrant

[Paul B Mahol]

On Wed, Jun 5, 2024 at 3:18 PM Andrew Sayers 
wrote:

> An external API developer might think they can use AVOptions to modify
> values
> during playback (e.g. putting a playback quality slider next to the volume
> slider).  Make it clear that behaviour is not recommended.
>

There are options that can be changed at runtime,
And it works just fine.


>
> Include the warning in the group description and the text for every
> function
> that sets options, but leave it implicit in functions that get options.
> This reflects the fact that *modifying* options is likely to cause weird
> bugs,
> while *reading* options isn't guaranteed but is likely to be safe.
> ---
>  libavutil/opt.h | 30 --
>  1 file changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/libavutil/opt.h b/libavutil/opt.h
> index 07e27a9208..13292c6473 100644
> --- a/libavutil/opt.h
> +++ b/libavutil/opt.h
> @@ -53,11 +53,16 @@
>   * question is allowed to access the field. This allows us to extend the
>   * semantics of those fields without breaking API compatibility.
>   *
> + * Note that AVOptions functions are not reentrant, and options may be
> accessed
> + * from internal FFmpeg threads.  Unless otherwise noted, it is best to
> avoid
> + * modifying options once a struct has been initialized.
> + *
>   * @section avoptions_scope Scope of AVOptions
>   *
>   * AVOptions is designed to support any set of multimedia configuration
> options
> - * that can be defined at compile-time.  Although it is mainly used to
> expose
> - * FFmpeg options, you are welcome to adapt it to your own use case.
> + * that can be defined at compile-time and set at object creation time.
> Although
> + * it is mainly used to expose FFmpeg options, you are welcome to adapt it
> + * to your own use case.
>   *
>   * No single approach can ever fully solve the problem of configuration,
>   * but please submit a patch if you believe you have found a problem
> @@ -483,6 +488,9 @@ typedef struct AVOptionRanges {
>  /**
>   * Set the values of all AVOption fields to their default values.
>   *
> + * Note: like all AVOptions functions, this is not reentrant.  Unless
> + * otherwise noted, it should only be used before initializing the struct.
> + *
>   * @param s an AVOption-enabled struct (its first member must be a
> pointer to AVClass)
>   */
>  void av_opt_set_defaults(void *s);
> @@ -492,6 +500,9 @@ void av_opt_set_defaults(void *s);
>   * AVOption fields for which (opt->flags & mask) == flags will have their
>   * default applied to s.
>   *
> + * Note: like all AVOptions functions, this is not reentrant.  Unless
> + * otherwise noted, it should only be used before initializing the struct.
> + *
>   * @param s an AVOption-enabled struct (its first member must be a
> pointer to AVClass)
>   * @param mask combination of AV_OPT_FLAG_*
>   * @param flags combination of AV_OPT_FLAG_*
> @@ -661,6 +672,9 @@ enum {
>   * key. ctx must be an AVClass context, storing is done using
>   * AVOptions.
>   *
> + * Note: like all AVOptions functions, this is not reentrant.  Unless
> + * otherwise noted, it should only be used before initializing the struct.
> + *
>   * @param opts options string to parse, may be NULL
>   * @param key_val_sep a 0-terminated list of characters used to
>   * separate key from value
> @@ -679,6 +693,9 @@ int av_set_options_string(void *ctx, const char *opts,
>   * Parse the key-value pairs list in opts. For each key=value pair found,
>   * set the value of the corresponding option in ctx.
>   *
> + * Note: like all AVOptions functions, this is not reentrant.  Unless
> + * otherwise noted, it should only be used before initializing the struct.
> + *
>   * @param ctx  the AVClass object to set options on
>   * @param opts the options string, key-value pairs separated by a
>   * delimiter
> @@ -709,6 +726,9 @@ int av_opt_set_from_string(void *ctx, const char *opts,
>  /**
>   * Set all the options from a given dictionary on an object.
>   *
> + * Note: like all AVOptions functions, this is not reentrant.  Unless
> + * otherwise noted, it should only be used before initializing the struct.
> + *
>   * @param obj a struct whose first element is a pointer to AVClass
>   * @param options options to process. This dictionary will be freed and
> replaced
>   *by a new one containing all options not found in obj.
> @@ -726,6 +746,9 @@ int av_opt_set_dict(void *obj, struct AVDictionary
> **options);
>  /**
>   * Set all the options from a given dictionary on an object.
>   *
> + * Note: like all AVOptions functions, this is not reentrant.  Unless
> + * otherwise noted, it should only be used before initializing the struct.
> + *
>   * @param obj a struct whose first element is a pointer to AVClass
>   * @param options options to process. This dictionary will be freed and
> replaced
>   *by a new one containing all options not found in obj.
> @@ -764,6 +787,9 @@ int a

Re: [FFmpeg-devel] [RFC] STF 2025

[Paul B Mahol]

On Wed, Jun 5, 2024 at 11:31 AM Rémi Denis-Courmont  wrote:

>
>
> Le 5 juin 2024 12:18:57 GMT+03:00, "Rémi Denis-Courmont" 
> a écrit :
> >But by reacting *only* to Vittorio trying to defend himself and
> explicitly (and ineffectively) asking for help from the CC, you look like
> you are attacking the victim and defending the troll.
>
> I should have said "the one doing the trolling". But whatever, the CC is
> free to ban me for calling someone a troll.
>

I'm so devastated by you and others calling me a troll. I will remove
myself from this place of abyss immediately.


> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] lavu/opt: Mention that AVOptions is not reentrant

[Paul B Mahol]

On Wed, Jun 5, 2024 at 3:44 PM Andrew Sayers 
wrote:

> On Wed, Jun 05, 2024 at 03:34:50PM +0200, Paul B Mahol wrote:
> > On Wed, Jun 5, 2024 at 3:18 PM Andrew Sayers <
> ffmpeg-de...@pileofstuff.org>
> > wrote:
> >
> > > An external API developer might think they can use AVOptions to modify
> > > values
> > > during playback (e.g. putting a playback quality slider next to the
> volume
> > > slider).  Make it clear that behaviour is not recommended.
> > >
> >
> > There are options that can be changed at runtime,
> > And it works just fine.
>
> How would an external developer know which options can be safely changed
> (preferably including in future versions of FFmpeg) vs. ones where their
> tests
> got lucky and happened not to trigger a read during a non-atomic write?
>

See this flag:

#define AV_OPT_FLAG_RUNTIME_PARAM   (1 << 15)

What is the point/gain in changing options from multiple threads
concurrently?



> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] aacdec_usac: correctly set and use the layout map

[Paul B Mahol]

On Wed, Jun 5, 2024 at 7:41 PM Lynne via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:

> ---
>  libavcodec/aac/aacdec_usac.c | 105 +--
>  1 file changed, 63 insertions(+), 42 deletions(-)
>
> diff --git a/libavcodec/aac/aacdec_usac.c b/libavcodec/aac/aacdec_usac.c
> index 04dd5facff..561734f930 100644
> --- a/libavcodec/aac/aacdec_usac.c
> +++ b/libavcodec/aac/aacdec_usac.c
> @@ -268,17 +268,25 @@ int ff_aac_usac_reset_state(AACDecContext *ac,
> OutputConfiguration *oc)
>  /* Initialize state */
>  for (int i = 0; i < usac->nb_elems; i++) {
>  AACUsacElemConfig *e = &usac->elems[i];
> -if (e->type != ID_USAC_SCE && e->type != ID_USAC_CPE)
> +if (e->type == ID_USAC_EXT)
>  continue;
>
> -if (e->type == ID_USAC_SCE) {
> +switch (e->type) {
> +case ID_USAC_SCE:
>  ch = 1;
>  type = TYPE_SCE;
>  id = elem_id[0]++;
> -} else {
> +break;
> +case ID_USAC_CPE:
>  ch = 2;
>  type = TYPE_CPE;
>  id = elem_id[1]++;
> +break;
> +case ID_USAC_LFE:
> +ch = 1;
> +type = TYPE_LFE;
> +id = elem_id[2]++;
> +break;
>  }
>
>  che = ff_aac_get_che(ac, type, id);
> @@ -318,7 +326,8 @@ int ff_aac_usac_config_decode(AACDecContext *ac,
> AVCodecContext *avctx,
>  AACUSACConfig *usac = &oc->usac;
>  int elem_id[3 /* SCE, CPE, LFE */];
>
> -uint8_t layout_map[MAX_ELEM_ID*4][3];
> +int map_pos_set = 0;
> +uint8_t layout_map[MAX_ELEM_ID*4][3] = { 0 };
>
>  memset(usac, 0, sizeof(*usac));
>
> @@ -391,6 +400,8 @@ int ff_aac_usac_config_decode(AACDecContext *ac,
> AVCodecContext *avctx,
>  /* Fill in the number of expected channels */
>  for (int i = 0; i < nb_elements; i++)
>  nb_channels += layout_map[i][0] == TYPE_CPE ? 2 : 1;
> +
> +map_pos_set = 1;
>  }
>
>  /* UsacDecoderConfig */
> @@ -404,12 +415,12 @@ int ff_aac_usac_config_decode(AACDecContext *ac,
> AVCodecContext *avctx,
>  }
>
>  for (int i = 0; i < usac->nb_elems; i++) {
> +int map_count = elem_id[0] + elem_id[1] + elem_id[2];
>  AACUsacElemConfig *e = &usac->elems[i];
>  memset(e, 0, sizeof(*e));
>
>  e->type = get_bits(gb, 2); /* usacElementType */
> -if (e->type != ID_USAC_EXT &&
> -(elem_id[0] + elem_id[1] + elem_id[2] + 1) > nb_channels) {
> +if (e->type != ID_USAC_EXT && (map_count + 1) > nb_channels) {
>  av_log(ac->avctx, AV_LOG_ERROR, "Too many channels for the
> channel "
>  "configuration\n");
>  usac->nb_elems = 0;
> @@ -425,30 +436,31 @@ int ff_aac_usac_config_decode(AACDecContext *ac,
> AVCodecContext *avctx,
>  decode_usac_element_core(e, gb, sbr_ratio);
>  if (e->sbr.ratio > 0)
>  decode_usac_sbr_data(e, gb);
> -layout_map[i][0] = TYPE_SCE;
> -layout_map[i][1] = i;
> -layout_map[i][2] = AAC_CHANNEL_FRONT;
> -elem_id[0]++;
> +layout_map[map_count][0] = TYPE_SCE;
> +layout_map[map_count][1] = elem_id[0]++;
> +if (!map_pos_set)
> +layout_map[map_count][2] = AAC_CHANNEL_FRONT;
>
>  break;
>  case ID_USAC_CPE: /* UsacChannelPairElementConf */
>  /* UsacCoreConfig */
>  decode_usac_element_core(e, gb, sbr_ratio);
>  decode_usac_element_pair(e, gb);
> -layout_map[i][0] = TYPE_CPE;
> -layout_map[i][1] = i;
> -layout_map[i][2] = AAC_CHANNEL_FRONT;
> -elem_id[1]++;
> +layout_map[map_count][0] = TYPE_CPE;
> +layout_map[map_count][1] = elem_id[1]++;
> +if (!map_pos_set)
> +layout_map[map_count][2] = AAC_CHANNEL_FRONT;
>
>  break;
>  case ID_USAC_LFE: /* LFE */
>  /* LFE has no need for any configuration */
>  e->tw_mdct = 0;
>  e->noise_fill = 0;
> -layout_map[i][0] = TYPE_LFE;
> -layout_map[i][1] = i;
> -layout_map[i][2] = AAC_CHANNEL_LFE;
> -elem_id[2]++;
> +layout_map[map_count][0] = TYPE_LFE;
> +layout_map[map_count][1] = elem_id[2]++;
> +if (!map_pos_set)
> +layout_map[map_count][2] = AAC_CHANNEL_LFE;
> +
>  break;
>  case ID_USAC_EXT: /* EXT */
>  ret = decode_usac_extension(ac, e, gb);
> @@ -458,7 +470,8 @@ int ff_aac_usac_config_decode(AACDecContext *ac,
> AVCodecContext *avctx,
>  };
>  }
>
> -ret = ff_aac_output_configure(ac, layout_map, elem_id[0] + elem_id[1]
> + elem_id[2], OC_GLOBAL_HDR, 0);
> +ret = ff_aac_output_configure(ac, layout_map, elem_id[0] + elem_id[1]
> + elem_id[2],
> 

Re: [FFmpeg-devel] [PATCH 1/2] lavu/bswap: remove some inline assembler

[Paul B Mahol]

On Tue, Jun 11, 2024 at 5:57 PM Michael Niedermayer 
wrote:

> On Tue, Jun 11, 2024 at 12:38:37PM -0300, James Almer wrote:
> > On 6/11/2024 10:15 AM, Michael Niedermayer wrote:
> > > On Fri, Jun 07, 2024 at 09:19:46PM +0300, Rémi Denis-Courmont wrote:
> > > > C code or compiler built-ins are preferable over inline assembler for
> > > > byte-swaps as it allows for better optimisations (e.g. instruction
> > > > scheduling) which would otherwise be impossible.
> > > >
> > > > As with f64c2e710fa1a7b59753224e717f57c48462076f for x86 and Arm,
> > > > this removes the inline assembler on GCC (and Clang) since we now
> > > > require recent enough compiler versions (this indeed seems to work on
> > > > AArch64).
> > > > ---
> > > >   libavutil/aarch64/bswap.h | 56
> ---
> > > >   libavutil/avr32/bswap.h   | 44 --
> > > >   libavutil/bswap.h |  8 +-
> > > >   libavutil/sh4/bswap.h | 48 -
> > >
> > > As you are writing that this preferrable for better optimisations
> > > Please provide benchmarks (for sh4, avr32)
> >
> > This is a ridiculous request, considering nobody has such hardware at
> all.
>
> Then I think its a ridiculous claim that this optimizes the code
>
> I mean, at some point there was hardware and these optimisations did
> improve
> speed.
>
> This patch is not removing the code because its a rare (or dead) platform,
> it removes
> it with the claim that this would "allows for better optimisations"
> Iam sorry but i do not see why asking for the claim in the commit message
> to be backed up with facts being ridiculous
> The claim in the commit message may be ridiculous
>

But at same time keeping sonic State of Art of audio codec compression and
maintaining it and responding to high user demand for its new features is
virtue of this project.


>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> No great genius has ever existed without some touch of madness. --
> Aristotle
> ___
> 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] Add Mediacodec audio decoders support

[Paul B Mahol]

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

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

Re: [FFmpeg-devel] [PATCH] avfilter: add sdlvsink for video display

[Paul B Mahol]

On Wed, Jun 12, 2024 at 9:52 PM Stefano Sabatini  wrote:

> On date Tuesday 2024-06-11 21:13:48 +0800, Shiqi Zhu wrote:
> > On Fri, 7 Jun 2024 at 19:55, Rémi Denis-Courmont 
> wrote:
> > > Le 7 juin 2024 12:53:51 GMT+03:00, Michael Niedermayer <
> mich...@niedermayer.cc> a écrit :
> > > >We can require anything from an API that we are able to change and
> extend
> > > >Of course we can decide not to allow such requirment even if optional
> > > >but we surely _could_ add such a feature if we choose to do so
> > >
> > > Sure. You can also require infinite memory or an oracle be provided.
> That's just not going to happen though. And having libraries depend on the
> main thread is a well-documented malpractice.
> > >
> > > I don't think we should add maintenance burden with code that can't be
> used safely.
> >
> > Thank you all for your attention to this patch; I greatly appreciate it.
> >
> > I'd like to provide a brief recap of the issue we've been discussing,
> > with the following points:
> >
> > 1. Addition of sink type in the filter:
> > This enhancement is primarily based on the existing avfilter mechanism
> > and serves as a strengthening module. Using SDL as the sink doesn't
> > seem to be a good fit, as I'll attempt to rectify in the following
> > patch.
> >
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240611130310.1131755-1-hiccup...@gmail.com/
> >
> > 2. Utilizing SDL as an implementation for the sink:
> > Before submitting the patch, I hadn't considered many aspects. During
> > the intense discussions, I retested the patch on different operating
> > systems, with the following results, hoping it may assist those
> > interested in this issue:
> >
> > Command: ./ffmpeg -lavfi
> > "testsrc2=size=300x200:rate=25:duration=500,format=yuv420p,sdlvsink"
> > -f null /dev/null
>
> In addition to this, I wonder if adding a vsink for each different
> output device is the correct way.
>
> We have a movie source which can be used to read from
> libavformat/libavdevice, probablhy we should have a movie sink to be
> used to write to libavformat/libavdevice, meaning that a single sink
> would enable access to all the supported libavformat/libavdevice
> outputs.
>
> I started having a look in that direction a looot of time ago. This
> was never finalized because I was not sure about ways to pass options
> to encoders and muxers, and about dealing with a variable number of
> outputs, I'm attaching this very old proof-of-concept patch for
> reference.
>
> This approach would be possibly much more complex, but should provide
> a single bridge in place of having a different sink for every output
> device or muxer.
>


Pointless as real plan is to get rid of immature libavdevice API.


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

[FFmpeg-devel] [BROKEN] apad causes infinite hang

[Paul B Mahol]

Just try with:

ffmpeg -f lavfi -i sine=d=30 -af apad -f null -

Pressing 'q' will not stop it at all, because current ffmpeg code will try
to flush all frames, but because pad filter never receives EOF from next
filter in chain (sink) it will happily produce frame forever.

Tried to fix ffmpeg.c related code but quickly realized rewrite just made
it 10 times worse to debug this.

Most clean solution is adding av_buffersink_close()
___
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] avcodec/h264dec: Remove ff_h264_draw_horiz_band

[Paul B Mahol]

On Fri, Jun 14, 2024 at 2:41 PM Kieran Kunhya via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:

> On Sun, Jun 9, 2024 at 2:39 AM Andreas Rheinhardt
>  wrote:
> >
> > The H.264 decoder does not support draw_horiz_band (it does not have
> > the AV_CODEC_CAP_DRAW_HORIZ_BAND), making ff_h264_draw_horiz_band()
> > legally dead. The function here always calls draw_horiz_band
> > in coded order, although the default case is display order.
>
> Why would you want a low latency decode mode with reordering?
> I have no idea about hwaccel, but I believe with low latency encoded
> video this does work.
>

Since when?

See 0da71265d84b587c7159cd82708ca60ad050dd4c from 2003.

flag remain commented out from then to this day.


> Kieran
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avcodec/iirfilter: Move ff_iir_filter() to lavc/tests/iirfilter.c

[Paul B Mahol]

On Sun, Jun 16, 2024 at 2:07 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> It is only used by the test.
>
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/iirfilter.c   | 14 --
>  libavcodec/iirfilter.h   | 15 ---
>  libavcodec/tests/iirfilter.c | 17 -
>  3 files changed, 16 insertions(+), 30 deletions(-)
>
> diff --git a/libavcodec/iirfilter.c b/libavcodec/iirfilter.c
> index 727a370444..cefe35ab6e 100644
> --- a/libavcodec/iirfilter.c
> +++ b/libavcodec/iirfilter.c
> @@ -277,20 +277,6 @@ av_cold struct FFIIRFilterState
> *ff_iir_filter_init_state(int order)
>  }
>\
>  }
>
> -void ff_iir_filter(const struct FFIIRFilterCoeffs *c,
> -   struct FFIIRFilterState *s, int size,
> -   const int16_t *src, ptrdiff_t sstep,
> -   int16_t *dst, ptrdiff_t dstep)
> -{
> -if (c->order == 2) {
> -FILTER_O2(int16_t, S16)
> -} else if (c->order == 4) {
> -FILTER_BW_O4(int16_t, S16)
> -} else {
> -FILTER_DIRECT_FORM_II(int16_t, S16)
> -}
> -}
> -
>  /**
>   * Perform IIR filtering on floating-point input samples.
>   *
> diff --git a/libavcodec/iirfilter.h b/libavcodec/iirfilter.h
> index d6b8fe2782..8ab8ae68c6 100644
> --- a/libavcodec/iirfilter.h
> +++ b/libavcodec/iirfilter.h
> @@ -28,7 +28,6 @@
>  #define AVCODEC_IIRFILTER_H
>
>  #include 
> -#include 
>
>  struct FFIIRFilterCoeffs;
>  struct FFIIRFilterState;
> @@ -114,18 +113,4 @@ void ff_iir_filter_free_coeffsp(struct
> FFIIRFilterCoeffs **coeffs);
>   */
>  void ff_iir_filter_free_statep(struct FFIIRFilterState **state);
>
> -/**
> - * Perform IIR filtering on signed 16-bit input samples.
> - *
> - * @param coeffs pointer to filter coefficients
> - * @param state  pointer to filter state
> - * @param size   input length
> - * @param srcsource samples
> - * @param sstep  source stride
> - * @param dstfiltered samples (destination may be the same as input)
> - * @param dstep  destination stride
> - */
> -void ff_iir_filter(const struct FFIIRFilterCoeffs *coeffs, struct
> FFIIRFilterState *state,
> -   int size, const int16_t *src, ptrdiff_t sstep, int16_t
> *dst, ptrdiff_t dstep);
> -
>  #endif /* AVCODEC_IIRFILTER_H */
> diff --git a/libavcodec/tests/iirfilter.c b/libavcodec/tests/iirfilter.c
> index 60cc6fc43d..e03e842b85 100644
> --- a/libavcodec/tests/iirfilter.c
> +++ b/libavcodec/tests/iirfilter.c
> @@ -23,10 +23,25 @@
>  #include "libavutil/libm.h"
>
>  #include "libavcodec/iirfilter.h"
> +#include "libavcodec/iirfilter.c"
>
>  #define FILT_ORDER 4
>  #define SIZE 1024
>
> +static void iir_filter_int16(const struct FFIIRFilterCoeffs *c,
> + struct FFIIRFilterState *s, int size,
> + const int16_t *src, ptrdiff_t sstep,
> + int16_t *dst, ptrdiff_t dstep)
> +{
> +if (c->order == 2) {
> +FILTER_O2(int16_t, S16)
> +} else if (c->order == 4) {
> +FILTER_BW_O4(int16_t, S16)
> +} else {
> +FILTER_DIRECT_FORM_II(int16_t, S16)
> +}
> +}
> +
>  int main(void)
>  {
>  struct FFIIRFilterCoeffs *fcoeffs = NULL;
> @@ -43,7 +58,7 @@ int main(void)
>  for (i = 0; i < SIZE; i++)
>  x[i] = lrint(0.75 * INT16_MAX * sin(0.5 * M_PI * i * i / SIZE));
>
> -ff_iir_filter(fcoeffs, fstate, SIZE, x, 1, y, 1);
> +iir_filter_int16(fcoeffs, fstate, SIZE, x, 1, y, 1);
>
>  for (i = 0; i < SIZE; i++)
>  printf("%6d %6d\n", x[i], y[i]);
> --
> 2.40.1
>
>
Unrelated to this patch, the iir >=2 order done by Direct II form for fixed
point integers is very bad idea.


> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v3 0/3] s/RUNTIME/POST_INIT_SETTABLE/

[Paul B Mahol]

Pointless. Commit log spam.
___
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] Development process for explaining contexts (was Re: [PATCH v6 1/4] doc: Explain what "context" means)

[Paul B Mahol]

Avoid filling some of bellow points:

https://erikbern.com/2023/12/13/simple-sabotage-for-software.html

Especially part of rewriting public or internal API just for rewrite.
___
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/2] avutil/executor: Allowing thread_count be zero

[Paul B Mahol]

On Mon, Jun 17, 2024 at 9:05 AM Anton Khirnov  wrote:

> Quoting Zhao Zhili (2024-06-17 07:19:26)
> > From: Zhao Zhili 
> >
> > When thread_count be zero, it will be run on current thread like
> > !HAVE_THREADS.
>
> Other APIs treat zero to mean "auto".
>

Agreed, this approach for 0 to mean do it on same thread is questionable at
best.
And no real reasoning for such approach was given as explanation in this
patch.


>
> --
> Anton Khirnov
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 7/9] MAINTAINERS: Update the entries for the release maintainer for FFmpeg

[Paul B Mahol]

On Mon, Jun 17, 2024 at 1:09 AM Michael Niedermayer 
wrote:

> Ive been told that someone at the BCN video tech meetup claimed to be the
> "release maintainer for FFmpeg".
>
>
That is nothing, I see many claims in many such videos and on many
platforms that they are developer/maintainer of FFmpeg while in fact they
develop/maintain only their closed source business.

Do not tell lies, or half lies, it does not help you on long run.


> If you have any doubt who maintains releases, just do something like the
> following and look at the output:
> VER=5.1
> echo commiters ; git shortlog  --group=committer -s  n$VER..release/$VER
> -n ;\
> echo authors   ; git shortlog-s  n$VER..release/$VER -n
>
> Signed-off-by: Michael Niedermayer 
> ---
>  MAINTAINERS | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 41a98744adf..a82fa58c69f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -536,10 +536,12 @@ wm4
>  Releases
>  
>
> +7.0 Michael Niedermayer
> +6.1 Michael Niedermayer
> +5.1 Michael Niedermayer
> +4.4 Michael Niedermayer
> +3.4 Michael Niedermayer
>  2.8 Michael Niedermayer
> -2.7 Michael Niedermayer
> -2.6 Michael Niedermayer
> -2.5 Michael Niedermayer
>
>  If you want to maintain an older release, please contact us
>
> --
> 2.45.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 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] [BROKEN] apad causes infinite hang

[Paul B Mahol]

On Mon, Jun 17, 2024 at 9:24 AM Anton Khirnov  wrote:

> Quoting Paul B Mahol (2024-06-14 14:19:13)
> > Just try with:
> >
> > ffmpeg -f lavfi -i sine=d=30 -af apad -f null -
> >
> > Pressing 'q' will not stop it at all, because current ffmpeg code will
> try
> > to flush all frames, but because pad filter never receives EOF from next
> > filter in chain (sink) it will happily produce frame forever.
> >
> > Tried to fix ffmpeg.c related code but quickly realized rewrite just made
> > it 10 times worse to debug this.
> >
> > Most clean solution is adding av_buffersink_close()
>
> I think it would be cleaner to have an API for closing a _source_ (or
> any filter that can produce unbounded amounts of output with no new
> input).
>

What do you mean by closing a _source_ ?

av_buffersrc_close() already exist.

This bug is fixed in Librempeg.

Adding a call to close random filter is certainly possible, but such
approach is very
frowned upon in multi-threaded environments.

And once you close all buffersinks the EOF will and must propagate backward
to all not-closed filters and their in/out pads.

If there is better internal API for filters, feel free to present it to
wider audience.


>
> --
> Anton Khirnov
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 8/9] avcodec/smcenc: width < 4 is unsupported

[Paul B Mahol]

On Mon, Jun 17, 2024 at 1:09 AM Michael Niedermayer 
wrote:

> Fixes: out of array read
> Fixes:
> 68939/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SMC_fuzzer-587804104884224
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
> ---
>  libavcodec/smcenc.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/smcenc.c b/libavcodec/smcenc.c
> index 789aef4f770..d70cce900ec 100644
> --- a/libavcodec/smcenc.c
> +++ b/libavcodec/smcenc.c
> @@ -537,6 +537,9 @@ static int smc_encode_frame(AVCodecContext *avctx,
> AVPacket *pkt,
>  uint8_t *pal;
>  int ret;
>
> +if (avctx->width < 4)
> +return AVERROR_PATCHWELCOME;
> +
>

I just enabled address sanitizer for smc encoder and i do not get any
errors.
Where is log of where overread happens?



>  ret = ff_alloc_packet(avctx, pkt, 8LL * avctx->height * avctx->width);
>  if (ret < 0)
>  return ret;
> --
> 2.45.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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/3] avfilter/af_volumedetect.c: Add 32bit float audio support

[Paul B Mahol]

On Mon, Jun 17, 2024 at 4:52 PM Rémi Denis-Courmont  wrote:

>
>
> Le 17 juin 2024 13:18:11 GMT+02:00, Yigithan Yigit <
> yigithanyigitde...@gmail.com> a écrit :
> >---
> > libavfilter/af_volumedetect.c | 159 --
> > 1 file changed, 133 insertions(+), 26 deletions(-)
> >
> >diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c
> >index 327801a7f9..dbbcd037a5 100644
> >--- a/libavfilter/af_volumedetect.c
> >+++ b/libavfilter/af_volumedetect.c
> >@@ -20,27 +20,51 @@
> >
> > #include "libavutil/channel_layout.h"
> > #include "libavutil/avassert.h"
> >+#include "libavutil/mem.h"
> > #include "audio.h"
> > #include "avfilter.h"
> > #include "internal.h"
> >
> >+#define MAX_DB_FLT 1024
> > #define MAX_DB 91
> >+#define HISTOGRAM_SIZE 0x1
> >+#define HISTOGRAM_SIZE_FLT (MAX_DB_FLT*2)
> >
> > typedef struct VolDetectContext {
> >-/**
> >- * Number of samples at each PCM value.
> >- * histogram[0x8000 + i] is the number of samples at value i.
> >- * The extra element is there for symmetry.
> >- */
> >-uint64_t histogram[0x10001];
> >+uint64_t* histogram; ///< for integer number of samples at each PCM
> value, for float number of samples at each dB
> >+uint64_t nb_samples; ///< number of samples
> >+double sum2; ///< sum of the squares of the samples
> >+double max;  ///< maximum sample value
> >+int is_float;///< true if the input is in floating point
> > } VolDetectContext;
> >
> >-static inline double logdb(uint64_t v)
> >+static inline double logdb(double v, enum AVSampleFormat sample_fmt)
> > {
> >-double d = v / (double)(0x8000 * 0x8000);
> >-if (!v)
> >-return MAX_DB;
> >-return -log10(d) * 10;
> >+if (sample_fmt == AV_SAMPLE_FMT_FLT) {
> >+if (!v)
> >+return MAX_DB_FLT;
> >+return -log10(v) * 10;
> >+} else {
> >+double d = v / (double)(0x8000 * 0x8000);
> >+if (!v)
> >+return MAX_DB;
> >+return -log10(d) * 10;
> >+}
> >+}
> >+
> >+static void update_float_stats(VolDetectContext *vd, float *audio_data)
> >+{
> >+double sample;
> >+int idx;
> >+if(!isnormal(*audio_data))
> >+return;
>
> Do we really need to classify floats here? That's probably going to hurt
> perfs badly, and makes an otherwise very vectorisable function not so
> easily vectored.
>

This is fast, it should translate to checking few bits of memory.


>
> >+sample = fabsf(*audio_data);
> >+if (sample > vd->max)
> >+vd->max = sample;
> >+vd->sum2 += sample * sample;
> >+idx = lrintf(floorf(logdb(sample * sample, AV_SAMPLE_FMT_FLT))) +
> MAX_DB_FLT;
>
> You're recomputing the same value again, and you seem to be rounding twice
> in a row?
>
> >+vd->histogram[idx]++;
> >+vd->nb_samples++;
> > }
> >
> > static int filter_frame(AVFilterLink *inlink, AVFrame *samples)
> >@@ -51,18 +75,41 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *samples)
> > int nb_channels = samples->ch_layout.nb_channels;
> > int nb_planes   = nb_channels;
> > int plane, i;
> >-int16_t *pcm;
> >+int planar = 0;
> >
> >-if (!av_sample_fmt_is_planar(samples->format)) {
> >-nb_samples *= nb_channels;
> >+planar = av_sample_fmt_is_planar(samples->format);
> >+if (!planar)
> > nb_planes = 1;
> >+if (vd->is_float) {
> >+float *audio_data;
> >+for (plane = 0; plane < nb_planes; plane++) {
> >+audio_data = (float *)samples->extended_data[plane];
> >+for (i = 0; i < nb_samples; i++) {
> >+if (planar) {
> >+update_float_stats(vd, &audio_data[i]);
> >+} else {
> >+for (int j = 0; j < nb_channels; j++)
> >+update_float_stats(vd, &audio_data[i *
> nb_channels + j]);
> >+}
> >+}
> >+}
> >+} else {
> >+int16_t *pcm;
> >+for (plane = 0; plane < nb_planes; plane++) {
> >+pcm = (int16_t *)samples->extended_data[plane];
> >+for (i = 0; i < nb_samples; i++) {
> >+if (planar) {
> >+vd->histogram[pcm[i] + 0x8000]++;
> >+vd->nb_samples++;
> >+} else {
> >+for (int j = 0; j < nb_channels; j++) {
> >+vd->histogram[pcm[i * nb_channels + j] +
> 0x8000]++;
> >+vd->nb_samples++;
> >+}
> >+}
> >+}
> >+}
>
> Can't we pick the correct implementation (planar/packed and float/int)
> once and for all whilst configuring the filter?
>
> > }
> >-for (plane = 0; plane < nb_planes; plane++) {
> >-pcm = (int16_t *)samples->extended_data[plane];
> >-for (i = 0; i < nb_samples; i++)
> >-vd->histogram[pcm[i] + 0x8000]++;
> >-}
> >-
> > retur

Re: [FFmpeg-devel] [PATCH 8/9] avcodec/smcenc: width < 4 is unsupported

[Paul B Mahol]

Fixed by making nx/ny always >= 0.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/3] avfilter/af_volumedetect.c: Add 32bit float audio support

[Paul B Mahol]

On Tue, Jun 18, 2024 at 8:56 AM Rémi Denis-Courmont  wrote:

>
>
> Le 17 juin 2024 19:52:10 GMT+02:00, Paul B Mahol  a
> écrit :
> >On Mon, Jun 17, 2024 at 4:52 PM Rémi Denis-Courmont 
> wrote:
> >
> >>
> >>
> >> Le 17 juin 2024 13:18:11 GMT+02:00, Yigithan Yigit <
> >> yigithanyigitde...@gmail.com> a écrit :
> >> >---
> >> > libavfilter/af_volumedetect.c | 159 --
> >> > 1 file changed, 133 insertions(+), 26 deletions(-)
> >> >
> >> >diff --git a/libavfilter/af_volumedetect.c
> b/libavfilter/af_volumedetect.c
> >> >index 327801a7f9..dbbcd037a5 100644
> >> >--- a/libavfilter/af_volumedetect.c
> >> >+++ b/libavfilter/af_volumedetect.c
> >> >@@ -20,27 +20,51 @@
> >> >
> >> > #include "libavutil/channel_layout.h"
> >> > #include "libavutil/avassert.h"
> >> >+#include "libavutil/mem.h"
> >> > #include "audio.h"
> >> > #include "avfilter.h"
> >> > #include "internal.h"
> >> >
> >> >+#define MAX_DB_FLT 1024
> >> > #define MAX_DB 91
> >> >+#define HISTOGRAM_SIZE 0x1
> >> >+#define HISTOGRAM_SIZE_FLT (MAX_DB_FLT*2)
> >> >
> >> > typedef struct VolDetectContext {
> >> >-/**
> >> >- * Number of samples at each PCM value.
> >> >- * histogram[0x8000 + i] is the number of samples at value i.
> >> >- * The extra element is there for symmetry.
> >> >- */
> >> >-uint64_t histogram[0x10001];
> >> >+uint64_t* histogram; ///< for integer number of samples at each
> PCM
> >> value, for float number of samples at each dB
> >> >+uint64_t nb_samples; ///< number of samples
> >> >+double sum2; ///< sum of the squares of the samples
> >> >+double max;  ///< maximum sample value
> >> >+int is_float;///< true if the input is in floating point
> >> > } VolDetectContext;
> >> >
> >> >-static inline double logdb(uint64_t v)
> >> >+static inline double logdb(double v, enum AVSampleFormat sample_fmt)
> >> > {
> >> >-double d = v / (double)(0x8000 * 0x8000);
> >> >-if (!v)
> >> >-return MAX_DB;
> >> >-return -log10(d) * 10;
> >> >+if (sample_fmt == AV_SAMPLE_FMT_FLT) {
> >> >+if (!v)
> >> >+return MAX_DB_FLT;
> >> >+return -log10(v) * 10;
> >> >+} else {
> >> >+double d = v / (double)(0x8000 * 0x8000);
> >> >+if (!v)
> >> >+return MAX_DB;
> >> >+return -log10(d) * 10;
> >> >+}
> >> >+}
> >> >+
> >> >+static void update_float_stats(VolDetectContext *vd, float
> *audio_data)
> >> >+{
> >> >+double sample;
> >> >+int idx;
> >> >+if(!isnormal(*audio_data))
> >> >+return;
> >>
> >> Do we really need to classify floats here? That's probably going to hurt
> >> perfs badly, and makes an otherwise very vectorisable function not so
> >> easily vectored.
> >>
> >
> >This is fast, it should translate to checking few bits of memory.
>
> Sure but the branch is what irks me here, not the classification per se.
> And I don't get why it's needed here, where most of the code base seems to
> assume that floats are always numeric. It's also not clear why subnormals
> are disallowed here.
>

HUGE floats get out of range easily, there is probably nicer way to add
them to some kind of "non-uniform non-linear" histogram.


>
> IMO all that needs justification in the commit message which I find
> lacking. Or if it's unjustified then it shouldn't be there.
>
> >> >+sample = fabsf(*audio_data);
> >> >+if (sample > vd->max)
> >> >+vd->max = sample;
> >> >+vd->sum2 += sample * sample;
> >> >+idx = lrintf(floorf(logdb(sample * sample, AV_SAMPLE_FMT_FLT))) +
> >> MAX_DB_FLT;
> >>
> >> You're recomputing the same value again, and you seem to be rounding
> twice
> >> in a row?
> ___
> 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] [RFC]] swscale modernization proposal

[Paul B Mahol]

On Sun, Jun 23, 2024 at 7:46 PM Michael Niedermayer 
wrote:

> On Sun, Jun 23, 2024 at 12:19:13AM +0200, Vittorio Giovara wrote:
> > On Sat, Jun 22, 2024 at 3:22 PM Niklas Haas  wrote:
> >
> > > Hey,
> > >
> > > As some of you know, I got contracted (by STF 2024) to work on
> improving
> > > swscale, over the course of the next couple of months. I want to share
> my
> > > current plans and gather feedback + measure sentiment.
> > >
> > > ## Problem statement
> > >
> > > The two issues I'd like to focus on for now are:
> > >
> > > 1. Lack of support for a lot of modern formats and conversions (HDR,
> ICtCp,
> > >IPTc2, BT.2020-CL, XYZ, YCgCo, Dolby Vision, ...)
> > > 2. Complicated context management, with cascaded contexts, threading,
> > > stateful
> > >configuration, multi-step init procedures, etc; and related bugs
> > >
> > > In order to make these feasible, some amount of internal
> re-organization of
> > > duties inside swscale is prudent.
> > >
> > > ## Proposed approach
> > >
> > > The first step is to create a new API, which will (tentatively) live in
> > > . This API will initially start off as a
> near-copy
> > > of the
> > > current swscale public API, but with the major difference that I want
> it
> > > to be
> > > state-free and only access metadata in terms of AVFrame properties. So
> > > there
> > > will be no independent configuration of the input chroma location etc.
> like
> > > there is currently, and no need to re-configure or re-init the context
> when
> > > feeding it frames with different properties. The goal is for users to
> be
> > > able
> > > to just feed it AVFrame pairs and have it internally cache expensive
> > > pre-processing steps as needed. Finally, avscale_* should ultimately
> also
> > > support hardware frames directly, in which case it will dispatch to
> some
> > > equivalent of scale_vulkan/vaapi/cuda or possibly even libplacebo.
> (But I
> > > will
> > > defer this to a future milestone)
> > >
> > > After this API is established, I want to start expanding the
> functionality
> > > in
> > > the following manner:
> > >
> > > ### Phase 1
> > >
> > > For basic operation, avscale_* will just dispatch to a sequence of
> > > swscale_*
> > > invocations. In the basic case, it will just directly invoke swscale
> with
> > > minimal overhead. In more advanced cases, it might resolve to a
> *sequence*
> > > of
> > > swscale operations, with other operations (e.g. colorspace conversions
> a la
> > > vf_colorspace) mixed in.
> > >
> > > This will allow us to gain new functionality in a minimally invasive
> way,
> > > and
> > > will let API users start porting to the new API. This will also serve
> as a
> > > good
> > > "selling point" for the new API, allowing us to hopefully break up the
> > > legacy
> > > swscale API afterwards.
> > >
> > > ### Phase 2
> > >
> > > After this is working, I want to cleanly separate swscale into two
> distinct
> > > components:
> > >
> > > 1. vertical/horizontal scaling
> > > 2. input/output conversions
> > >
> > > Right now, these operations both live inside the main SwsContext, even
> > > though
> > > they are conceptually orthogonal. Input handling is done entirely by
> the
> > > abstract callbacks lumToYV12 etc., while output conversion is currently
> > > "merged" with vertical scaling (yuv2planeX etc.).
> > >
> > > I want to cleanly separate these components so they can live inside
> > > independent
> > > contexts, and be considered as semantically distinct steps. (In
> particular,
> > > there should ideally be no more "unscaled special converters", instead
> > > this can
> > > be seen as a special case where there simply is no vertical/horizontal
> > > scaling
> > > step)
> > >
> > > The idea is for the colorspace conversion layer to sit in between the
> > > input/output converters and the horizontal/vertical scalers. This all
> > > would be
> > > orchestrated by the avscale_* abstraction.
> > >
> > > ## Implementation details
> > >
> > > To avoid performance loss from separating "merged" functions into their
> > > constituents, care needs to be taken such that all intermediate data,
> in
> > > addition to all involved look-up tables, will fit comfortably inside
> the L1
> > > cache. The approach I propose, which is also (afaict) used by zscale,
> is to
> > > loop over line segments, applying each operation in sequence, on a
> small
> > > temporary buffer.
> > >
> > > e.g.
> > >
> > > hscale_row(pixel *dst, const pixel *src, int img_width)
> > > {
> > > const int SIZE = 256; // or some other small-ish figure, possibly a
> > > design
> > >   // constant of the API so that SIMD
> > > implementations
> > >   // can be appropriately unrolled
> > >
> > > pixel tmp[SIZE];
> > > for (i = 0; i < img_width; i += SIZE) {
> > > int pixels = min(SIZE, img_width - i);
> > >
> > > { /* inside read input callback */
> > > unpack_input(tmp, src, pixels);
> > >   

Re: [FFmpeg-devel] [PATCH] libavformat/vapoursynth: Update to API version 4, load library at runtime

[Paul B Mahol]

On Tue, Jun 25, 2024 at 11:10 AM Anton Khirnov  wrote:

> Quoting Stefan Oltmanns via ffmpeg-devel (2024-06-22 03:37:03)
> > Hello,
> >
> > this is my first patch, I hope I got all the formalities correct.
> >
> > The current VapourSynth implementation is rarely used, as it links the
> > VapourSynth library at build time, making the resulting build unable to
> > run when VapourSynth is not installed. Therefore barely anyone compiles
> > with VapourSynth activated.
> >
> > I changed it, so that it loads the library at runtime when a VapourSynth
> > script should be opened, just like AviSynth does.
> > On Windows the DLL from VapourSynth is not installed in the system
> > directory, but the location is stored in the Registry. Therefore I added
> > some code to read that information from the registry.
> >
> > As the V4 API is designed with dynamic loading in mind (only a single
> > import), I updated the implementation to V4 (changes are mostly
> > superficial, no structural changes). The V4 API is already several years
> > old, fully supported since R55 released in 2021.
> >
> > I copied the two needed header files directly in a vapoursynth.h,
> > removing the need to install VapourSynth on the build machine
> > (VapourSynth is also LGPL 2.1 or later, so no license issue). I updated
> > the configure so that it checks for the ability to load libraries at
> > runtime for VapourSynth, just like AviSynth and activate it if not
> disabled.
> >
> > make fate runs without any issue. I tested VapourSynth input scripts
> > with various color formats on different platforms:
> >
> > Ubuntu 22.04
> > macOS 13 (x86_64)
> > macOS 13 (arm64)
> > Windows 10 (msys2/gcc)
> >
> > It compiles on these platforms without any warning and runs without any
> > issues.
>
> Sorry, this is entirely unacceptable.
> Especially the part instaling atexit handlers and bundling downstream
> headers, but overall we prefer to avoid dlopen.
>

Dunno what 'we' means here.

$ grep dlopen */*.c
libavcodec/amfenc.c:ctx->library = dlopen(AMF_DLL_NAMEA, RTLD_NOW |
RTLD_LOCAL);
libavcodec/mediacodec_wrapper.c:format->libmedia =
dlopen("libmediandk.so", RTLD_NOW);
libavcodec/mediacodec_wrapper.c:codec->libmedia = dlopen(lib_name,
RTLD_NOW);
libavcodec/mfenc.c:c->library = dlopen("mfplat.dll", 0);
libavcodec/omx.c:s->lib2 = dlopen(libname2, RTLD_NOW | RTLD_GLOBAL);
libavcodec/omx.c:s->lib = dlopen(libname, RTLD_NOW | RTLD_GLOBAL);
libavfilter/af_ladspa.c:ret = dlopen(path, RTLD_LOCAL|RTLD_NOW);
libavfilter/af_ladspa.c:s->dl_handle = dlopen(s->dl_name,
RTLD_LOCAL|RTLD_NOW);
libavfilter/vf_frei0r.c:*handle_ptr = dlopen(path, RTLD_NOW|RTLD_LOCAL);
libavfilter/vf_telecine.c: * @file telecine filter, heavily based from
mpv-player:TOOLS/vf_dlopen/telecine.c by
libavfilter/vsrc_ddagrab.c:user32_module = dlopen("user32.dll", 0);
libavformat/avisynth.c:avs_library.library = dlopen(AVISYNTH_LIB,
RTLD_NOW | RTLD_LOCAL);
libavutil/hwcontext_d3d11va.c:d3dlib  = dlopen("d3d11.dll", 0);
libavutil/hwcontext_d3d11va.c:dxgilib = dlopen("dxgi.dll", 0);
libavutil/hwcontext_d3d12va.c:priv->d3d12lib = dlopen("d3d12.dll", 0);
libavutil/hwcontext_d3d12va.c:priv->dxgilib  = dlopen("dxgi.dll", 0);
libavutil/hwcontext_dxva2.c:priv->d3dlib = dlopen("d3d9.dll", 0);
libavutil/hwcontext_dxva2.c:priv->dxva2lib = dlopen("dxva2.dll", 0);
libavutil/hwcontext_mediacodec.c:s->libmedia = dlopen("libmediandk.so",
RTLD_NOW);
libavutil/hwcontext_vaapi.c:HANDLE dxgi = dlopen("dxgi.dll", 0);
libavutil/hwcontext_vulkan.c:p->libvulkan = dlopen(lib_names[i],
RTLD_NOW | RTLD_LOCAL);
libavutil/macos_kperf.c:av_assert0(kperf =
dlopen("/System/Library/PrivateFrameworks/kperf.framework/Versions/A/kperf",
RTLD_LAZY));




>
> --
> Anton Khirnov
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avfilter: add v360_vulkan filter

[Paul B Mahol]

On Tue, Jun 25, 2024 at 2:47 PM Dennis Mungai  wrote:

> On Sun, 28 Jun 2020 at 16:59, James Almer  wrote:
>
> > On 6/27/2020 7:54 AM, Paul B Mahol wrote:
> > > On 6/26/20, James Almer  wrote:
> > >> On 6/26/2020 4:16 PM, Lynne wrote:
> > >>> Jun 26, 2020, 19:05 by jamr...@gmail.com:
> > >>>
> > >>>> On 6/26/2020 1:58 PM, Paul B Mahol wrote:
> > >>>>
> > >>>>> On 6/26/20, James Almer  wrote:
> > >>>>>
> > >>>>>> On 6/26/2020 1:13 PM, Paul B Mahol wrote:
> > >>>>>>
> > >>>>>>> On 6/26/20, Paul B Mahol  wrote:
> > >>>>>>>
> > >>>>>>>> On 6/24/20, Paul B Mahol  wrote:
> > >>>>>>>>
> > >>>>>>>>> Signed-off-by: Paul B Mahol 
> > >>>>>>>>> ---
> > >>>>>>>>> Please test it and reports benchmark results on non toyish
> GPUs.
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> Please, I really need it!
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Why nobody wants to help?
> > >>>>>>>
> > >>>>>>> This makes me really really sad.
> > >>>>>>>
> > >>>>>>
> > >>>>>> I can try. Can you give an example command line with a publicly
> > >>>>>> available sample?
> > >>>>>>
> > >>>>>
> > >>>>> You can use any sample, samples are irrelevant. just report
> > resolution
> > >>>>> used.
> > >>>>> Also compare with CPU solution with just v360 filter.
> > >>>>>
> > >>>>> For yuv420p inputs:
> > >>>>>
> > >>>>> ffmpeg -init_hw_device vulkan=vulkan -i INPUT -filter_hw_device
> > vulkan
> > >>>>> -vf
> > >>>>>
> >
> hwupload,v360_vulkan=fisheye:e:ih_fov=180:iv_fov=180:w=2048:h=1024,hwdownload,format=yuv420p
> > >>>>> -f null -
> > >>>>>
> > >>>>> ffmpeg -i INPUT -vf
> > v360=fisheye:e:ih_fov=180:iv_fov=180:w=2048:h=1024
> > >>>>> -f null -
> > >>>>>
> > >>>>> Just make sure that you get same output resolution in both cases.
> If
> > >>>>> not, adjust w/h accordingly.
> > >>>>>
> > >>>>
> > >>>> I'm getting a segfault on vkGetInstanceProcAddr, and i don't know if
> > >>>> it's your filter or some issue in the driver. gdb is not being
> > helpful.
> > >>>> ___
> > >>>> 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".
> > >>>>
> > >>>
> > >>> Can you test again but replace EXT_EXTERNAL_HOST_MEMORY in
> > >>> optional_device_exts
> > >>> with EXT_NO_FLAG?
> > >>
> > >> Applying
> > >>
> > >>> diff --git a/libavutil/hwcontext_vulkan.c
> > b/libavutil/hwcontext_vulkan.c
> > >>> index 5e51d0390f..49fb7827ba 100644
> > >>> --- a/libavutil/hwcontext_vulkan.c
> > >>> +++ b/libavutil/hwcontext_vulkan.c
> > >>> @@ -228,7 +228,7 @@ static const VulkanOptExtension
> > optional_device_exts[]
> > >>> = {
> > >>>  { VK_EXT_EXTERNAL_MEMORY_DMA_BUF_EXTENSION_NAME,
> > >>> EXT_EXTERNAL_DMABUF_MEMORY, },
> > >>>  { VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_EXTENSION_NAME,
> > >>> EXT_DRM_MODIFIER_FLAGS, },
> > >>>  { VK_KHR_EXTERNAL_SEMAPHORE_FD_EXTENSION_NAME,
> > >>> EXT_EXTERNAL_FD_SEM,},
> > >>> -{ VK_EXT_EXTERNAL_MEMORY_HOST_EXTENSION_NAME,
> > >>> EXT_EXTERNAL_HOST_MEMORY,   },
> > >>> +{ VK_EXT_EXTERNAL_MEMORY_HOST_EXTENSION_NAME,
> > >>> EXT_NO_FLAG,   

Re: [FFmpeg-devel] [PATCH 1/2 v2] fftools/ffmpeg: support applying container level cropping

[Paul B Mahol]

On Tue, Jun 25, 2024 at 3:12 PM Anton Khirnov  wrote:

> Quoting James Almer (2024-06-25 14:38:58)
> > On 6/25/2024 7:25 AM, Anton Khirnov wrote:
> > > Quoting James Almer (2024-05-31 01:22:51)
> > >> @@ -1000,11 +1001,21 @@ int ist_filter_add(InputStream *ist,
> InputFilter *ifilter, int is_simple,
> > >>   ist->filters[ist->nb_filters - 1] = ifilter;
> > >>
> > >>   if (ist->par->codec_type == AVMEDIA_TYPE_VIDEO) {
> > >> +const AVPacketSideData *sd =
> av_packet_side_data_get(ist->par->coded_side_data,
> > >> +
>  ist->par->nb_coded_side_data,
> > >> +
>  AV_PKT_DATA_FRAME_CROPPING);
> > >>   if (ist->framerate.num > 0 && ist->framerate.den > 0) {
> > >>   opts->framerate = ist->framerate;
> > >>   opts->flags |= IFILTER_FLAG_CFR;
> > >>   } else
> > >>   opts->framerate = av_guess_frame_rate(d->f.ctx,
> ist->st, NULL);
> > >> +if (sd && sd->size == sizeof(uint32_t) * 4) {
> > >> +opts->crop_top= AV_RL32(sd->data +  0);
> > >> +opts->crop_bottom = AV_RL32(sd->data +  4);
> > >> +opts->crop_left   = AV_RL32(sd->data +  8);
> > >> +opts->crop_right  = AV_RL32(sd->data + 12);
> > >> +opts->flags  |= IFILTER_FLAG_CROP;
> > >> +}
> > >>   } else if (ist->par->codec_type == AVMEDIA_TYPE_SUBTITLE) {
> > >>   /* Compute the size of the canvas for the subtitles stream.
> > >>  If the subtitles codecpar has set a size, use it.
> Otherwise use the
> > >> @@ -1241,6 +1252,9 @@ static int ist_add(const OptionsContext *o,
> Demuxer *d, AVStream *st)
> > >>   ds->autorotate = 1;
> > >>   MATCH_PER_STREAM_OPT(autorotate, i, ds->autorotate, ic, st);
> > >>
> > >> +ds->apply_cropping = 1;
> > >> +MATCH_PER_STREAM_OPT(apply_cropping, i, ds->apply_cropping, ic,
> st);
> > >> +
> > >>   MATCH_PER_STREAM_OPT(codec_tags, str, codec_tag, ic, st);
> > >>   if (codec_tag) {
> > >>   uint32_t tag = strtol(codec_tag, &next, 0);
> > >> @@ -1362,6 +1376,8 @@ static int ist_add(const OptionsContext *o,
> Demuxer *d, AVStream *st)
> > >>
> > >>   ds->dec_opts.flags |= DECODER_FLAG_BITEXACT * !!o->bitexact;
> > >>
> > >> +av_dict_set_int(&ds->decoder_opts, "apply_cropping",
> ds->apply_cropping, 0);
> > >
> > > If I'm reading it right, this new option now applies only to decoder
> > > cropping (breaking syntax, because AVOptions always take an argument),
> > > while container cropping is always applied unconditionally.
> > >
> > > That seems wrong.
> >
> > Yeah, for some reason i missed a "* !!ds->apply_cropping" next to the
> > IFILTER_FLAG_CROP above. With it container cropping is applied depending
> > on the value of apply_cropping.
> >
> > And how can i work around the ffmpeg option shadowing the avcodec one of
> > the same name? Using a different name for container cropping option
> > exclusively in ffmpeg is not really nice for the user. They either care
> > about cropping no matter the source, or no cropping.
>
> I expect plenty of broken files from various sources where the user will
> want to selectively ignore either codec or container cropping.
> So we could make this an enum option, with values
> none/all/codec/container, mapping to 0/1/2/3 respectively. That should
> keep compatibility with current syntax.
>

Enum? Why not flags?


>
> --
> Anton Khirnov
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avfilter: add v360_vulkan filter

[Paul B Mahol]

On Tue, Jun 25, 2024 at 3:17 PM Dennis Mungai  wrote:

> On Tue, 25 Jun 2024 at 16:07, Paul B Mahol  wrote:
>
> > On Tue, Jun 25, 2024 at 2:47 PM Dennis Mungai  wrote:
> >
> > > On Sun, 28 Jun 2020 at 16:59, James Almer  wrote:
> > >
> > > > On 6/27/2020 7:54 AM, Paul B Mahol wrote:
> > > > > On 6/26/20, James Almer  wrote:
> > > > >> On 6/26/2020 4:16 PM, Lynne wrote:
> > > > >>> Jun 26, 2020, 19:05 by jamr...@gmail.com:
> > > > >>>
> > > > >>>> On 6/26/2020 1:58 PM, Paul B Mahol wrote:
> > > > >>>>
> > > > >>>>> On 6/26/20, James Almer  wrote:
> > > > >>>>>
> > > > >>>>>> On 6/26/2020 1:13 PM, Paul B Mahol wrote:
> > > > >>>>>>
> > > > >>>>>>> On 6/26/20, Paul B Mahol  wrote:
> > > > >>>>>>>
> > > > >>>>>>>> On 6/24/20, Paul B Mahol  wrote:
> > > > >>>>>>>>
> > > > >>>>>>>>> Signed-off-by: Paul B Mahol 
> > > > >>>>>>>>> ---
> > > > >>>>>>>>> Please test it and reports benchmark results on non toyish
> > > GPUs.
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> Please, I really need it!
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>>
> > > > >>>>>>> Why nobody wants to help?
> > > > >>>>>>>
> > > > >>>>>>> This makes me really really sad.
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>> I can try. Can you give an example command line with a
> publicly
> > > > >>>>>> available sample?
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>> You can use any sample, samples are irrelevant. just report
> > > > resolution
> > > > >>>>> used.
> > > > >>>>> Also compare with CPU solution with just v360 filter.
> > > > >>>>>
> > > > >>>>> For yuv420p inputs:
> > > > >>>>>
> > > > >>>>> ffmpeg -init_hw_device vulkan=vulkan -i INPUT -filter_hw_device
> > > > vulkan
> > > > >>>>> -vf
> > > > >>>>>
> > > >
> > >
> >
> hwupload,v360_vulkan=fisheye:e:ih_fov=180:iv_fov=180:w=2048:h=1024,hwdownload,format=yuv420p
> > > > >>>>> -f null -
> > > > >>>>>
> > > > >>>>> ffmpeg -i INPUT -vf
> > > > v360=fisheye:e:ih_fov=180:iv_fov=180:w=2048:h=1024
> > > > >>>>> -f null -
> > > > >>>>>
> > > > >>>>> Just make sure that you get same output resolution in both
> cases.
> > > If
> > > > >>>>> not, adjust w/h accordingly.
> > > > >>>>>
> > > > >>>>
> > > > >>>> I'm getting a segfault on vkGetInstanceProcAddr, and i don't
> know
> > if
> > > > >>>> it's your filter or some issue in the driver. gdb is not being
> > > > helpful.
> > > > >>>> ___
> > > > >>>> 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".
> > > > >>>>
> > > > >>>
> > > > >>> Can you test again but replace EXT_EXTERNAL_HOST_MEMORY in
> > > > >>> optional_device_exts
> > > > >>> with EXT_NO_FLAG?
> > > > >>
> > > > >> Applying
> > > > >>
> > > > >>> diff --git a/libavutil/hwcontext_vulkan.c
> > >

Re: [FFmpeg-devel] [PATCH 1/3] avformat/cafdec: sanity check channels and bps

[Paul B Mahol]

On Thu, Jun 27, 2024 at 1:50 AM Michael Niedermayer 
wrote:

> On Tue, Jun 25, 2024 at 09:27:55PM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2024-06-25 21:25:46)
> > > On Thu, Mar 28, 2024 at 12:27:02AM +0100, Michael Niedermayer wrote:
> > > > On Wed, Mar 27, 2024 at 08:39:17AM +0100, Anton Khirnov wrote:
> > > > > Quoting Michael Niedermayer (2024-03-23 00:08:16)
> > > > > > Fixes: Timeout
> > > > > > Fixes:
> 67044/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-5791144363491328
> > > > > >
> > > > > > Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > > > > Signed-off-by: Michael Niedermayer 
> > > > > > ---
> > > > > >  libavformat/cafdec.c | 5 +
> > > > > >  1 file changed, 5 insertions(+)
> > > > > >
> > > > > > diff --git a/libavformat/cafdec.c b/libavformat/cafdec.c
> > > > > > index 426c56b9bd..334077efb5 100644
> > > > > > --- a/libavformat/cafdec.c
> > > > > > +++ b/libavformat/cafdec.c
> > > > > > @@ -33,6 +33,7 @@
> > > > > >  #include "isom.h"
> > > > > >  #include "mov_chan.h"
> > > > > >  #include "libavcodec/flac.h"
> > > > > > +#include "libavcodec/internal.h"
> > > > > >  #include "libavutil/intreadwrite.h"
> > > > > >  #include "libavutil/intfloat.h"
> > > > > >  #include "libavutil/dict.h"
> > > > > > @@ -87,6 +88,10 @@ static int read_desc_chunk(AVFormatContext *s)
> > > > > >  st->codecpar->ch_layout.nb_channels = avio_rb32(pb);
> > > > > >  st->codecpar->bits_per_coded_sample = avio_rb32(pb);
> > > > > >
> > > > > > +if (st->codecpar->ch_layout.nb_channels >
> FF_SANE_NB_CHANNELS ||
> > > > >
> > > > > I dislike this.
> > > >
> > > > I dislike it too
> > >
> > > so what do we do about this ?
> >
> > About what? What is the actual problem that needs addressed?
>
> 67044/clusterfuzz-testcase-minimized-ffmpeg_dem_CAF_fuzzer-5791144363491328
>
>
> >
> > > any objections to apply this ?
> >
> > yes, FF_SANE_NB_CHANNELS is a hack that should be removed, not spread
>
> a maximum number for each theoretically unlimited parameter is desirable
> This can be a user setable value or a compile time value when such is
> preferred.
>

Cant you check if so many channels are actually available in stream?
Or there is some silly loop that goes unchecked up to INT32_MAX ?


>
> We can take this to the TC if you want.
>
> The same way as the number of files or number of bytes used by some cache
> needs limits, so do channels, and number of pixels.
>
> One can remove them but users and companies concious about security and
> efficiency with untrusted input in an (semi-) automated environment will
> likely
> choose the codebase providing such features.
>

"Sure."


>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The day soldiers stop bringing you their problems is the day you have
> stopped
> leading them. They have either lost confidence that you can help or
> concluded
> you do not care. Either case is a failure of leadership. - Colin Powell
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 3/4] avformat/img2dec: ensure input padding is zeroed

[Paul B Mahol]

On Thu, Jun 27, 2024 at 3:57 AM Kacper Michajłow  wrote:

> Fixes use of uninitialized value, reported by MSAN. Specifically in
> jpegxl parser.
>
> Found by OSS-Fuzz.
>
> Signed-off-by: Kacper Michajłow 
> ---
>  libavformat/img2dec.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> index ba52353074..c667d8574c 100644
> --- a/libavformat/img2dec.c
> +++ b/libavformat/img2dec.c
> @@ -549,6 +549,8 @@ int ff_img_read_packet(AVFormatContext *s1, AVPacket
> *pkt)
>  }
>  }
>
> +memset(pkt->data + pkt->size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
> +
>  if (ret[0] <= 0 || ret[1] < 0 || ret[2] < 0) {
>  if (ret[0] < 0) {
>  res = ret[0];
> --
> 2.43.0
>
>
Isn't this done generically already?
Otherwise this fix is just fixing one single case of numerous others not
covered.


> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avfilter/asubprocess: add audio subprocess filter

[Paul B Mahol]

I do not want to comment code.

But this concept/idea/whatever is plain nonsense.
___
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: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".

[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];

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 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<data[0] + 
y * dst_linesize);\
@@ -339,10 +342,10 @@ static inline int selective_color_##nbits(AVFilterContext 
*ctx, ThreadData *td,
 const int b = src[x + boffset];
 \
 const int min_color = FFMIN3(r, g, b); 
 \
 const int max_color = FFMAX3(r, g, b); 
 \
-const int is_white   = (r > 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<nb_process_ranges; i++) {   
 \
-- 
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 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 = (1<data[0] + 
y * dst_linesize);\
-const uint##nbits##_t *src = (const uint##nbits##_t *)( in->data[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);  

[FFmpeg-devel] [PATCH 1] avfilter/vf_avgblur: switch to faster algorithm

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavfilter/vf_avgblur.c  | 311 ++
 tests/ref/fate/filter-refcmp-psnr-yuv |  80 +++
 2 files changed, 211 insertions(+), 180 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++) {  

Re: [FFmpeg-devel] [PATCH 1/3] avfilter/vf_swaprect: Use ff_formats_pixdesc_filter()

[Paul B Mahol]

lgtm
___
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] avutil/utils: Remove racy check from avutil_version()

[Paul B Mahol]

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

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

Re: [FFmpeg-devel] [PATCH 2/2] avutil/tests/opt: Set AVClass.version

[Paul B Mahol]

lgtm
___
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/2] avutil/opt: Remove outdated version check

[Paul B Mahol]

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

[Paul B Mahol]

On Sun, Sep 26, 2021 at 1:27 PM myp...@gmail.com  wrote:

> On Sun, Sep 26, 2021 at 4:11 PM Paul B Mahol  wrote:
> >
> > Signed-off-by: Paul B Mahol 
> > ---
> >  libavfilter/vf_avgblur.c  | 311 ++
> >  tests/ref/fate/filter-refcmp-psnr-yuv |  80 +++
> >  2 files changed, 211 insertions(+), 180 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;
>\
> > -}
>\
> > -
>   \
> > -for (; x < width; x++) {
>   \
> > -acc -= src[x - r

Re: [FFmpeg-devel] [PATCH 1/4] libavfilter/x86/vf_hflip: add ff_flip_byte/short_avx512()

[Paul B Mahol]

On Mon, Sep 27, 2021 at 8:48 AM Wu, Jianhua  wrote:

> Ping.
> Jianhua wrote:
> >
> > Ping.
> >
> > Jianhua wrote:
> > > From: ffmpeg-devel  On Behalf Of
> > Wu,
> > > Jianhua
> > > Sent: Tuesday, September 14, 2021 1:02 PM
> > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH 1/4] libavfilter/x86/vf_hflip: add
> > > ff_flip_byte/short_avx512()
> > >
> > >
> > > It seemed that there is no one with objection over the past two weeks.
> > > Are the patches able to be applied?
> > >
> >
> Hi there,
>
> Looks like one month elapsed. Any update?
>

No rushing needed.


> Thanks,
> Jianhua
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avfilter/elbg: Extend filter to include alpha values in the quantization procedure

[Paul B Mahol]

On Mon, Sep 27, 2021 at 5:30 PM Michael Niedermayer 
wrote:

> On Sun, Sep 26, 2021 at 05:56:36PM +, Soft Works wrote:
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of
> > > Michael Niedermayer
> > > Sent: Sunday, 26 September 2021 18:52
> > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH] avfilter/elbg: Extend filter to
> > > include alpha values in the quantization procedure
> > >
> > > On Sun, Sep 26, 2021 at 04:57:25AM +, Soft Works wrote:
> > > > 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(-)
> > >
> > > will apply
> >
> > Thank you.
> >
> > Please allow me another note: I think the naming of this filter
> > is terrible. I've gone through the list of all ffmpeg filters
> > many more times than the typical user, but without the specific
> > pointers I had gotten from you and a few other devs, I would
> > have never identified the "elbg" filter as something that
> > would do what I'm looking for.
>
> i would tend to agree, yes, in fact i think
> finding filters based on what they do is hard
> and iam not sure their names alone should be how they need to be found
>

Every filter have short description. So next time use grep or search
feature.


>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Old school: Use the lowest level language in which you can solve the
> problem
> conveniently.
> New school: Use the highest level language in which the latest
> supercomputer
> can solve the problem without the user falling asleep waiting.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: fix loosing gaps between audio frame timestamps when filtering

[Paul B Mahol]

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

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

Re: [FFmpeg-devel] [PATCH] avfilter/elbg: Extend filter to include alpha values in the quantization procedure

[Paul B Mahol]

On Tue, Sep 28, 2021 at 5:43 PM Soft Works  wrote:

>
>
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > Paul B Mahol
> > Sent: Monday, 27 September 2021 18:37
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH] avfilter/elbg: Extend filter to
> > include alpha values in the quantization procedure
> >
> > On Mon, Sep 27, 2021 at 5:30 PM Michael Niedermayer
> > 
> > wrote:
> >
> > > On Sun, Sep 26, 2021 at 05:56:36PM +, Soft Works wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: ffmpeg-devel  On Behalf
> > Of
> > > > > Michael Niedermayer
> > > > > Sent: Sunday, 26 September 2021 18:52
> > > > > To: FFmpeg development discussions and patches  > > > > de...@ffmpeg.org>
> > > > > Subject: Re: [FFmpeg-devel] [PATCH] avfilter/elbg: Extend
> > filter to
> > > > > include alpha values in the quantization procedure
> > > > >
> > > > > On Sun, Sep 26, 2021 at 04:57:25AM +, Soft Works wrote:
> > > > > > 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(-)
> > > > >
> > > > > will apply
> > > >
> > > > Thank you.
> > > >
> > > > Please allow me another note: I think the naming of this filter
> > > > is terrible. I've gone through the list of all ffmpeg filters
> > > > many more times than the typical user, but without the specific
> > > > pointers I had gotten from you and a few other devs, I would
> > > > have never identified the "elbg" filter as something that
> > > > would do what I'm looking for.
> > >
> > > i would tend to agree, yes, in fact i think
> > > finding filters based on what they do is hard
> > > and iam not sure their names alone should be how they need to be
> > found
> > >
>
> The names can't be it alone, but good naming would be a helpful
> element.
>
>
> > Every filter have short description. So next time use grep or search
> > feature.
>
> You have added a large range of audio filters and I'm sure many of
> them are very useful, but I'm afraid that often I do not have the
> slightest clue about what they are doing, not even when reading the
> description text ;-)
>

Are you audio engineer? Follow documentation.


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

[FFmpeg-devel] [PATCH] avfilter: add huesaturation filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi   |  56 
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/vf_huesaturation.c | 485 +
 4 files changed, 543 insertions(+)
 create mode 100644 libavfilter/vf_huesaturation.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 237629fb5d..a2e463d913 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -13853,6 +13853,62 @@ If the specified expression is not valid, it is kept 
at its current
 value.
 @end table
 
+@section huesaturation
+Apply hue-saturation-intensity adjusments to input video stream.
+
+This filter operates in RGB colorspace.
+
+This filter accepts the following options:
+
+@table @option
+@item hue
+Set the hue shift in degrees to apply. Default is 0.
+Allowed range is from -180 to 180.
+
+@item saturation
+Set the saturation shift. Default is 0.
+Allowed range is from -1 to 1.
+
+@item intensity
+Set the intensity shift. Default is 0.
+Allowed range is from -1 to 1.
+
+@item colors
+Set which primary and complementary colors are going to be adjusted.
+This options is set by proving one or multiple values.
+This can select multiple colors at once. By default all colors are selected.
+@table @samp
+@item r
+Adjust reds.
+@item y
+Adjust yellows.
+@item g
+Adjust greens.
+@item c
+Adjust cyans.
+@item b
+Adjust blues.
+@item m
+Adjust magentas.
+@item a
+Adjust all colors.
+@end table
+
+@item strength
+Set strength of filtering. Allowed range is from 0 to 100.
+Default value is 1.
+
+@item rw, gw, bw
+Set weight for each RGB component. Allowed range is from 0 to 1.
+By default is set to 0.333, 0.334, 0.333.
+Those options are used in saturation and lightess processing.
+
+@item lightness
+Set preserving lightness, by default is disabled.
+Adjusting hues can change lightness from original RGB triplet,
+with this option enabled lightness is kept at same value.
+@end table
+
 @section hysteresis
 
 Grow first stream into second stream by connecting components.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 06e01da38e..ec4e8acafb 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -307,6 +307,7 @@ OBJS-$(CONFIG_HSTACK_FILTER) += vf_stack.o 
framesync.o
 OBJS-$(CONFIG_HSVHOLD_FILTER)+= vf_hsvkey.o
 OBJS-$(CONFIG_HSVKEY_FILTER) += vf_hsvkey.o
 OBJS-$(CONFIG_HUE_FILTER)+= vf_hue.o
+OBJS-$(CONFIG_HUESATURATION_FILTER)  += vf_huesaturation.o
 OBJS-$(CONFIG_HWDOWNLOAD_FILTER) += vf_hwdownload.o
 OBJS-$(CONFIG_HWMAP_FILTER)  += vf_hwmap.o
 OBJS-$(CONFIG_HWUPLOAD_CUDA_FILTER)  += vf_hwupload_cuda.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 10dfe72131..d414b46948 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -292,6 +292,7 @@ extern const AVFilter ff_vf_hstack;
 extern const AVFilter ff_vf_hsvhold;
 extern const AVFilter ff_vf_hsvkey;
 extern const AVFilter ff_vf_hue;
+extern const AVFilter ff_vf_huesaturation;
 extern const AVFilter ff_vf_hwdownload;
 extern const AVFilter ff_vf_hwmap;
 extern const AVFilter ff_vf_hwupload;
diff --git a/libavfilter/vf_huesaturation.c b/libavfilter/vf_huesaturation.c
new file mode 100644
index 00..d9b822a9c2
--- /dev/null
+++ b/libavfilter/vf_huesaturation.c
@@ -0,0 +1,485 @@
+/*
+ * 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/opt.h"
+#include "libavutil/imgutils.h"
+#include "avfilter.h"
+#include "drawutils.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+#define R 0
+#define G 1
+#define B 2
+
+#define REDS 0
+#define YELLOWS  1
+#define GREENS   2
+#define CYANS3
+#define BLUES4
+#define MAGENTAS 5
+
+#define RED (1 << REDS)
+#define YELLOW  (1 << YELLOWS)
+#define GREEN   (1 << GREENS)
+#define CYAN(1 << CYANS)
+#define BLUE(1 << BLUES)
+#define MAGENTA (1 << MAGENTAS)
+#define ALL  0x3F
+
+typedef struct HueSaturationContext {
+const AVClass *class;
+
+float hue;
+float saturation;
+float intensity;
+float stre

Re: [FFmpeg-devel] [PATCH] avfilter/elbg: Extend filter to include alpha values in the quantization procedure

[Paul B Mahol]

On Tue, Sep 28, 2021 at 7:16 PM Soft Works  wrote:

>
>
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > Paul B Mahol
> > Sent: Tuesday, 28 September 2021 18:05
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH] avfilter/elbg: Extend filter to
> > include alpha values in the quantization procedure
> >
> > On Tue, Sep 28, 2021 at 5:43 PM Soft Works 
> > wrote:
> >
> > >
> > >
> > > > -Original Message-
> > > > From: ffmpeg-devel  On Behalf Of
> > > > Paul B Mahol
> > > > Sent: Monday, 27 September 2021 18:37
> > > > To: FFmpeg development discussions and patches  > > > de...@ffmpeg.org>
> > > > Subject: Re: [FFmpeg-devel] [PATCH] avfilter/elbg: Extend filter
> > to
> > > > include alpha values in the quantization procedure
> > > >
> > > > On Mon, Sep 27, 2021 at 5:30 PM Michael Niedermayer
> > > > 
> > > > wrote:
> > > >
> > > > > On Sun, Sep 26, 2021 at 05:56:36PM +, Soft Works wrote:
> > > > > >
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: ffmpeg-devel  On
> > Behalf
> > > > Of
> > > > > > > Michael Niedermayer
> > > > > > > Sent: Sunday, 26 September 2021 18:52
> > > > > > > To: FFmpeg development discussions and patches  > > > > > > de...@ffmpeg.org>
> > > > > > > Subject: Re: [FFmpeg-devel] [PATCH] avfilter/elbg: Extend
> > > > filter to
> > > > > > > include alpha values in the quantization procedure
> > > > > > >
> > > > > > > On Sun, Sep 26, 2021 at 04:57:25AM +, Soft Works wrote:
> > > > > > > > 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(-)
> > > > > > >
> > > > > > > will apply
> > > > > >
> > > > > > Thank you.
> > > > > >
> > > > > > Please allow me another note: I think the naming of this
> > filter
> > > > > > is terrible. I've gone through the list of all ffmpeg filters
> > > > > > many more times than the typical user, but without the
> > specific
> > > > > > pointers I had gotten from you and a few other devs, I would
> > > > > > have never identified the "elbg" filter as something that
> > > > > > would do what I'm looking for.
> > > > >
> > > > > i would tend to agree, yes, in fact i think
> > > > > finding filters based on what they do is hard
> > > > > and iam not sure their names alone should be how they need to
> > be
> > > > found
> > > > >
> > >
> > > The names can't be it alone, but good naming would be a helpful
> > > element.
> > >
> > >
> > > > Every filter have short description. So next time use grep or
> > search
> > > > feature.
> > >
> > > You have added a large range of audio filters and I'm sure many of
> > > them are very useful, but I'm afraid that often I do not have the
> > > slightest clue about what they are doing, not even when reading the
> > > description text ;-)
> > >
> >
> > Are you audio engineer? Follow documentation.
>
> Accidentally, I'm quite familiar with audio production and studio
> technology, that's why I'm sure that even for audio engineers it's
> not always clear what the filters are doing. The documentation is
> often too minimal and it would be nice when it would include
> example use cases and example command lines.
> Same as for the elbg filter, I don't mean it in a negative way.
> What I mean is that it's somewhat unfortunate to put so much effort
> in developing those filters, when their benefits remain to be invisible
> for the majority of users.
>

Give examples, propose improvements, elbg is not only filter.



>
> 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] [PATCH] avfilter: add morpho filter

[Paul B Mahol]

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

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/siren: Check available bits at frame start

[Paul B Mahol]

On Tue, Sep 28, 2021 at 8:09 PM James Almer  wrote:

> On 9/28/2021 3:03 PM, Michael Niedermayer wrote:
> > On Tue, Sep 28, 2021 at 09:44:01PM +1000, Peter Ross wrote:
> >> On Tue, Sep 28, 2021 at 12:07:49AM -0300, James Almer wrote:
> >>> On 9/27/2021 7:37 PM, Michael Niedermayer wrote:
>  Fixes: Timeout
>  Fixes:
> 39089/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MSNSIREN_fuzzer-6677219854909440
> 
>  Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>  Signed-off-by: Michael Niedermayer 
>  ---
> libavcodec/siren.c | 3 +++
> 1 file changed, 3 insertions(+)
> 
>  diff --git a/libavcodec/siren.c b/libavcodec/siren.c
>  index 7f2b4678608..708990d6654 100644
>  --- a/libavcodec/siren.c
>  +++ b/libavcodec/siren.c
>  @@ -718,6 +718,9 @@ static int siren_decode(AVCodecContext *avctx,
> void *data,
> if ((ret = init_get_bits8(gb, avpkt->data, avpkt->size)) < 0)
> return ret;
>  +if (s->sample_rate_bits + 4 > get_bits_left(gb))
>  +return AVERROR_INVALIDDATA;
> >>>
> >>> This is not enough. You'll inevitably get another timeout in the future
> >>> unless you add a get_bits_left(gb) > 0 condition to the loop in
> >>> decode_envelope().
> >>> And there should be at least four bits left after decode_envelope()
> returns,
> >>> so check for that too.
> >
> > I tend not to add more checks than needed for timeouts because
> > it increases the risk the patch gets rejected because it breaks
> something and
> > then the reporter refuses to share any details.  Or someone is offended
> because
> > too many ugly/hacky timeout checks are added. So my patches are a bit
> > minimalistic (less work and less friction).
> > But that now offends others who want more complete fixes :(
> >
> > added a check in the loop, ill post the new patch
>
> Nothing you did offended me. I'm just saying that your patch fixes the
> timeout for that specific bitstream created by the fuzzer, but the core
> issue is in that loop, and it'd be better to fix it there instead.
>
> If you don't want to add the check after decode_envelope() then that's ok.
>

I prefer James solution, instead of heuristic nonsense.


>
> >
> >
> >>
> >> suggest increasing the threshold to include:
> >>
> >
> >>  s->sample_rate_bits + s->number_of_regions + 4 + s->checksum_bits
> > get_bits_left(gb)
> >
> > changed
> >
> >
> >>
> >>
> >> hey michael are you only fuzzing AV_CODEC_ID_MSNSIREN?
> >> i would expect this issue to occur for for the vanilla SIREN codec too?
> >
> > The fuzzer is supposed to fuzz all decoders,
> > sometimes it has difficulty with some decoders, when for example theres
> no
> > seed file or something else special is needed for the codec. For example
> > a codec may need a specific codec_tag or extradata set ...
> >
> > thx
> >
> > [...]
> >
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> >
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] doc/filters: added possible values to @item win_func

[Paul B Mahol]

On Wed, Sep 29, 2021 at 12:51 PM Arif Driessen  wrote:

> Here's your patch for `afftfilt` win_func. (copied from the surround
> filter, but checked against the code to ensure it's correct). If you like
> it, I'll do it for all the win_funcs.
>

Better add separate section, and than link to it with each filter docs,
instead copy paste lines 100 times.

>
> ---
>  doc/filters.texi | 27 ++-
>  1 file changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 568c2995bc..60403a628e 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -1325,7 +1325,32 @@ Set window size. Allowed range is from 16 to 131072.
>  Default is @code{4096}
>
>  @item win_func
> -Set window function. Default is @code{hann}.
> +Set window function.
> +
> +It accepts the following values:
> +@table @samp
> +@item rect
> +@item bartlett
> +@item hann, hanning
> +@item hamming
> +@item blackman
> +@item welch
> +@item flattop
> +@item bharris
> +@item bnuttall
> +@item bhann
> +@item sine
> +@item nuttall
> +@item lanczos
> +@item gauss
> +@item tukey
> +@item dolph
> +@item cauchy
> +@item parzen
> +@item poisson
> +@item bohman
> +@end table
> +Default is @code{hann}.
>
>  @item overlap
>  Set window overlap. If set to 1, the recommended overlap for selected
> --
> 2.30.2
>
>
>
> On Tue, Sep 28, 2021 at 4:56 PM Gyan Doshi  wrote:
>
> >
> >
> > On 2021-09-28 07:29 pm, Arif Driessen wrote:
> > >> These should be formatted like they are in the surround filter for the
> > > option with the same name.
> > >
> > > Good catch! Looking around, I see there are other filters too with a
> > > win_func option. When I next get a moment (either later today or more
> > > likely tomorrow) I'll double check with the code,
> > > and add documentation for those too. if that sounds good to you.
> > Sure. But let's start with this one.
> >
> > Regards,
> > Gyan
> > ___
> > 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".
>
___
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] avfilter/vf_avgblur: switch to faster algorithm

[Paul B Mahol]

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

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

Re: [FFmpeg-devel] [PATCH] doc/filters: added possible values to @item win_func

[Paul B Mahol]

On Wed, Sep 29, 2021 at 7:52 PM Arif Driessen  wrote:

> > Better add separate section, and than link to it with each filter docs,
> instead copy paste lines 100 times.
>
> If we do add a separate section, I'm not sure where to put it. Perhaps
> under "@chapter See Also"?
>
> I thought about something like a "@chapter Common Filter Options", but this
> makes it sound like they are common to all filters.
>

Name it various windowing functions, as it may be used for both video and
audio.


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

[FFmpeg-devel] [PATCH] avformat/mux: fix overflow in case one of dts in not set

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavformat/mux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mux.c b/libavformat/mux.c
index 2053a5636e..583328b123 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -949,7 +949,7 @@ int ff_interleave_packet_per_dts(AVFormatContext *s, 
AVPacket *out,
 last_dts = av_rescale_q(last->pkt.dts,
 st->time_base,
 AV_TIME_BASE_Q);
-delta_dts = FFMAX(delta_dts, last_dts - top_dts);
+delta_dts = FFMAX(delta_dts, (top_dts == AV_NOPTS_VALUE || 
last_dts == AV_NOPTS_VALUE) ? 0 : last_dts - top_dts);
 }
 
 if (delta_dts > s->max_interleave_delta) {
-- 
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] [PATCH] doc/filters: added possible values to @item win_func

[Paul B Mahol]

On Thu, Sep 30, 2021 at 10:53 AM Gyan Doshi  wrote:

>
> On 2021-09-30 02:19 pm, Arif Driessen wrote:
> > Okay. But is it a @chapter Various Windowing Functions (placed at the end
> > just before @chapter See Also and @chapter Authors) or a @section Various
> > Windowing Functions, that has to live under some chapter? (...Which?)
>
> Just keep the current patch for now. I'll push and then consolidate.
>

Please revert your commit, I haven't approved your changes that duplicates
lines unneceassary.


>
> >
> > On Wed, Sep 29, 2021 at 8:17 PM Paul B Mahol  wrote:
> >
> >> On Wed, Sep 29, 2021 at 7:52 PM Arif Driessen 
> wrote:
> >>
> >>>> Better add separate section, and than link to it with each filter
> docs,
> >>> instead copy paste lines 100 times.
> >>>
> >>> If we do add a separate section, I'm not sure where to put it. Perhaps
> >>> under "@chapter See Also"?
> >>>
> >>> I thought about something like a "@chapter Common Filter Options", but
> >> this
> >>> makes it sound like they are common to all filters.
> >>>
> >> Name it various windowing functions, as it may be used for both video
> and
> >> audio.
> >>
> >>
> >>> ___
> >>> 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".
> >>
> > ___
> > 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".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] doc/filters: added possible values to @item win_func

[Paul B Mahol]

On Thu, Sep 30, 2021 at 12:51 PM Gyan Doshi  wrote:

>
>
> On 2021-09-30 04:20 pm, Paul B Mahol wrote:
> > On Thu, Sep 30, 2021 at 10:53 AM Gyan Doshi  wrote:
> >
> >> On 2021-09-30 02:19 pm, Arif Driessen wrote:
> >>> Okay. But is it a @chapter Various Windowing Functions (placed at the
> end
> >>> just before @chapter See Also and @chapter Authors) or a @section
> Various
> >>> Windowing Functions, that has to live under some chapter? (...Which?)
> >> Just keep the current patch for now. I'll push and then consolidate.
> >>
> > Please revert your commit, I haven't approved your changes that
> duplicates
> > lines unneceassary.
> You don't maintain docs, I do.
>

You are self proclaimed maintainer only.
If you do not fix docs soon i will do it instead of you, with above commit
reverted.


>
> Regards,
> Gyan
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v1 1/1] avformat/amr: Return PATCHWELCOME on stereo files

[Paul B Mahol]

On Thu, Sep 30, 2021 at 5:05 AM Sun Zhenliang 
wrote:

> ping for review.
>

have amr-wb mc stereo sample?


> 在 2021年9月27日 +0800 09:48，Sun Zhenliang ，写道：
> > 在 2021年9月26日 +0800 20:40，myp...@gmail.com ，写道：
> > > On Thu, Sep 16, 2021 at 11:24 AM sunzhenliang
> > >  wrote:
> > > >
> > > > Signed-off-by: sunzhenliang 
> > > > ---
> > > > libavformat/amr.c | 22 ++
> > > > 1 file changed, 18 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/libavformat/amr.c b/libavformat/amr.c
> > > > index 836b276fd5..2762010ebe 100644
> > > > --- a/libavformat/amr.c
> > > > +++ b/libavformat/amr.c
> > > > @@ -36,8 +36,10 @@ typedef struct {
> > > > uint64_t block_count;
> > > > } AMRContext;
> > > >
> > > > -static const char AMR_header[] = "#!AMR\n";
> > > > -static const char AMRWB_header[] = "#!AMR-WB\n";
> > > > +static const char AMR_header[] = "#!AMR\n";
> > > > +static const char AMR_MC_header[] = "#!AMR_MC1.0\n";
> > > > +static const char AMRWB_header[] = "#!AMR-WB\n";
> > > > +static const char AMRWB_MC_header[] = "#!AMR-WB_MC1.0\n";
> > > I don't think you need to format the AMR_header[] and AMRWB_header[]
> > > in the patch
> > I just think aligning the equals sign will look neat, which can't be
> reflected in the email.
> > > >
> > > > static const uint8_t amrnb_packed_size[16] = {
> > > > 13, 14, 16, 18, 20, 21, 27, 32, 6, 1, 1, 1, 1, 1, 1, 1
> > > > @@ -82,7 +84,7 @@ static int amr_read_header(AVFormatContext *s)
> > > > {
> > > > AVIOContext *pb = s->pb;
> > > > AVStream *st;
> > > > - uint8_t header[9];
> > > > + uint8_t header[15];
> > > >
> > > > if (avio_read(pb, header, 6) != 6)
> > > > return AVERROR_INVALIDDATA;
> > > > @@ -94,7 +96,19 @@ static int amr_read_header(AVFormatContext *s)
> > > > if (avio_read(pb, header + 6, 3) != 3)
> > > > return AVERROR_INVALIDDATA;
> > > > if (memcmp(header, AMRWB_header, 9)) {
> > > > - return -1;
> > > > + if (avio_read(pb, header + 6 + 3, 3) != 3)
> > > > + return AVERROR_INVALIDDATA;
> > > > + if (memcmp(header, AMR_MC_header, 12)) {
> > > > + if (avio_read(pb, header + 6 + 3 + 3, 3) != 3)
> > > > + return AVERROR_INVALIDDATA;
> > > > + if (memcmp(header, AMRWB_MC_header, 15)) {
> > > > + return -1;
> > > > + }
> > > > + avpriv_report_missing_feature(s, "multi-channel AMRWB");
> > > > + return AVERROR_PATCHWELCOME;
> > > > + }
> > > > + avpriv_report_missing_feature(s, "multi-channel AMR");
> > > > + return AVERROR_PATCHWELCOME;
> > > > }
> > > >
> > > > st->codecpar->codec_tag = MKTAG('s', 'a', 'w', 'b');
> > > > --
> > > > 2.25.1
> > > >
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > > To unsubscribe, visit link above, or email
> > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avformat/mux: fix overflow in case one of dts in not set

[Paul B Mahol]

On Thu, Sep 30, 2021 at 1:54 PM Michael Niedermayer 
wrote:

> On Thu, Sep 30, 2021 at 12:36:17PM +0200, Paul B Mahol wrote:
> > Signed-off-by: Paul B Mahol 
> > ---
> >  libavformat/mux.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/mux.c b/libavformat/mux.c
> > index 2053a5636e..583328b123 100644
> > --- a/libavformat/mux.c
> > +++ b/libavformat/mux.c
> > @@ -949,7 +949,7 @@ int ff_interleave_packet_per_dts(AVFormatContext *s,
> AVPacket *out,
> >  last_dts = av_rescale_q(last->pkt.dts,
> >  st->time_base,
> >  AV_TIME_BASE_Q);
> > -delta_dts = FFMAX(delta_dts, last_dts - top_dts);
> > +delta_dts = FFMAX(delta_dts, (top_dts == AV_NOPTS_VALUE ||
> last_dts == AV_NOPTS_VALUE) ? 0 : last_dts - top_dts);
> >  }
>
> In which case are packets without DTS interleaved by DTS ?
>

In many cases, for example few of them being exposed by FATE, and
--enable-ftrapv
See fate.ffmpeg.org


>
> thx
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Dictatorship: All citizens are under surveillance, all their steps and
> actions recorded, for the politicians to enforce control.
> Democracy: All politicians are under surveillance, all their steps and
> actions recorded, for the citizens to enforce control.
> ___
> 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".

[FFmpeg-devel] [PATCH] avcodec: add amr parser

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/Makefile |   1 +
 libavcodec/amr_parser.c | 103 
 libavcodec/parsers.c|   1 +
 libavformat/amr.c   |  63 +---
 4 files changed, 117 insertions(+), 51 deletions(-)
 create mode 100644 libavcodec/amr_parser.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 829ff88e1d..d3b6db0b49 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1079,6 +1079,7 @@ OBJS-$(CONFIG_AAC_PARSER)  += aac_parser.o 
aac_ac3_parser.o \
   mpeg4audio.o
 OBJS-$(CONFIG_AC3_PARSER)  += ac3tab.o aac_ac3_parser.o
 OBJS-$(CONFIG_ADX_PARSER)  += adx_parser.o adx.o
+OBJS-$(CONFIG_AMR_PARSER)  += amr_parser.o
 OBJS-$(CONFIG_AV1_PARSER)  += av1_parser.o
 OBJS-$(CONFIG_AVS2_PARSER) += avs2_parser.o
 OBJS-$(CONFIG_AVS3_PARSER) += avs3_parser.o
diff --git a/libavcodec/amr_parser.c b/libavcodec/amr_parser.c
new file mode 100644
index 00..dc622f65f3
--- /dev/null
+++ b/libavcodec/amr_parser.c
@@ -0,0 +1,103 @@
+/*
+ * Copyright (c) 2021 Paul B Mahol
+ *
+ * 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
+ */
+
+/**
+ * @file
+ * ADX audio parser
+ *
+ * Splits packets into individual blocks.
+ */
+
+#include "libavutil/intreadwrite.h"
+#include "parser.h"
+
+static const uint8_t amrnb_packed_size[16] = {
+13, 14, 16, 18, 20, 21, 27, 32, 6, 1, 1, 1, 1, 1, 1, 1
+};
+static const uint8_t amrwb_packed_size[16] = {
+18, 24, 33, 37, 41, 47, 51, 59, 61, 6, 1, 1, 1, 1, 1, 1
+};
+
+typedef struct AMRParseContext {
+ParseContext pc;
+uint64_t cumulated_size;
+uint64_t block_count;
+int remaining;
+} AMRParseContext;
+
+static int amr_parse(AVCodecParserContext *s1,
+ AVCodecContext *avctx,
+ const uint8_t **poutbuf, int *poutbuf_size,
+ const uint8_t *buf, int buf_size)
+{
+AMRParseContext *s = s1->priv_data;
+ParseContext *pc = &s->pc;
+int next = END_NOT_FOUND;
+
+*poutbuf_size = 0;
+*poutbuf = NULL;
+
+if (s1->flags & PARSER_FLAG_COMPLETE_FRAMES) {
+next = buf_size;
+} else {
+if (s->remaining) {
+next = s->remaining;
+} else {
+int mode = (buf[0] >> 3) & 0x0F;
+
+if (avctx->codec_id == AV_CODEC_ID_AMR_NB) {
+next = amrnb_packed_size[mode];
+} else if (avctx->codec_id == AV_CODEC_ID_AMR_WB) {
+next = amrwb_packed_size[mode];
+}
+}
+
+s->remaining = next - FFMIN(buf_size, next);
+if (s->remaining)
+next = END_NOT_FOUND;
+
+if (next != END_NOT_FOUND) {
+if (s->cumulated_size < UINT64_MAX - next) {
+s->cumulated_size += next;
+/* Both AMR formats have 50 frames per second */
+avctx->bit_rate = s->cumulated_size / ++s->block_count * 8 * 
50;
+}
+}
+
+if (ff_combine_frame(pc, next, &buf, &buf_size) < 0) {
+*poutbuf  = NULL;
+*poutbuf_size = 0;
+return buf_size;
+}
+}
+
+s1->duration = avctx->codec_id == AV_CODEC_ID_AMR_NB ? 160 : 320;
+
+*poutbuf = buf;
+*poutbuf_size = buf_size;
+return next;
+}
+
+const AVCodecParser ff_amr_parser = {
+.codec_ids  = { AV_CODEC_ID_AMR_NB, AV_CODEC_ID_AMR_WB },
+.priv_data_size = sizeof(AMRParseContext),
+.parser_parse   = amr_parse,
+.parser_close   = ff_parse_close,
+};
diff --git a/libavcodec/parsers.c b/libavcodec/parsers.c
index 5ab1a226d9..6b40c18d80 100644
--- a/libavcodec/parsers.c
+++ b/libavcodec/parsers.c
@@ -24,6 +24,7 @@ extern const AVCodecParser ff_aac_parser;
 extern const AVCodecParser ff_aac_latm_parser;
 extern const AVCodecParser ff_ac3_parser;
 extern const AVCodecParser ff_adx_parser;
+extern const AVCodecParser ff_amr_parser;
 extern const AVCodecParser ff_av1_parser;
 extern const AVCodecParser ff_avs2_parser;
 extern const AVCodecParser ff_avs3_parser;
diff --git a/libavformat/amr.c b/l

Re: [FFmpeg-devel] [PATCH 1/3] swscale/swscale_internal: Avoid unsigned for slice parameters

[Paul B Mahol]

LGTM
___
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 v1 1/1] avformat/amr: Return PATCHWELCOME on stereo files

[Paul B Mahol]

On Thu, Sep 30, 2021 at 4:42 PM Sun Zhenliang 
wrote:

> 在 2021年9月30日 +0800 19:56，Paul B Mahol ，写道：
> > On Thu, Sep 30, 2021 at 5:05 AM Sun Zhenliang <
> hisunzhenli...@outlook.com>
> > wrote:
> >
> > > ping for review.
> > >
> >
> > have amr-wb mc stereo sample?
> yes, here are the stereo amr-wb/nb files.
>

where is specification, its exact name for those stereo files?

>
>
> https://github.com/HiSunzhenliang/patch/blob/main/ffmpeg/avformat-amr-Return-PATCHWELCOME-on-stereo-files/stereo.amr-wb
> patch/stereo.amr-wb
> <https://github.com/HiSunzhenliang/patch/blob/main/ffmpeg/avformat-amr-Return-PATCHWELCOME-on-stereo-files/stereo.amr-wbpatch/stereo.amr-wb>
>
>
> https://github.com/HiSunzhenliang/patch/blob/main/ffmpeg/avformat-amr-Return-PATCHWELCOME-on-stereo-files/stereo.amr-nb
> patch/stereo.amr-nb
> <https://github.com/HiSunzhenliang/patch/blob/main/ffmpeg/avformat-amr-Return-PATCHWELCOME-on-stereo-files/stereo.amr-nbpatch/stereo.amr-nb>
> >
> >
> > > 在 2021年9月27日 +0800 09:48，Sun Zhenliang  >，写道：
> > > > 在 2021年9月26日 +0800 20:40，myp...@gmail.com ，写道：
> > > > > On Thu, Sep 16, 2021 at 11:24 AM sunzhenliang
> > > > >  wrote:
> > > > > >
> > > > > > Signed-off-by: sunzhenliang 
> > > > > > ---
> > > > > > libavformat/amr.c | 22 ++
> > > > > > 1 file changed, 18 insertions(+), 4 deletions(-)
> > > > > >
> > > > > > diff --git a/libavformat/amr.c b/libavformat/amr.c
> > > > > > index 836b276fd5..2762010ebe 100644
> > > > > > --- a/libavformat/amr.c
> > > > > > +++ b/libavformat/amr.c
> > > > > > @@ -36,8 +36,10 @@ typedef struct {
> > > > > > uint64_t block_count;
> > > > > > } AMRContext;
> > > > > >
> > > > > > -static const char AMR_header[] = "#!AMR\n";
> > > > > > -static const char AMRWB_header[] = "#!AMR-WB\n";
> > > > > > +static const char AMR_header[] = "#!AMR\n";
> > > > > > +static const char AMR_MC_header[] = "#!AMR_MC1.0\n";
> > > > > > +static const char AMRWB_header[] = "#!AMR-WB\n";
> > > > > > +static const char AMRWB_MC_header[] = "#!AMR-WB_MC1.0\n";
> > > > > I don't think you need to format the AMR_header[] and
> AMRWB_header[]
> > > > > in the patch
> > > > I just think aligning the equals sign will look neat, which can't be
> > > reflected in the email.
> > > > > >
> > > > > > static const uint8_t amrnb_packed_size[16] = {
> > > > > > 13, 14, 16, 18, 20, 21, 27, 32, 6, 1, 1, 1, 1, 1, 1, 1
> > > > > > @@ -82,7 +84,7 @@ static int amr_read_header(AVFormatContext *s)
> > > > > > {
> > > > > > AVIOContext *pb = s->pb;
> > > > > > AVStream *st;
> > > > > > - uint8_t header[9];
> > > > > > + uint8_t header[15];
> > > > > >
> > > > > > if (avio_read(pb, header, 6) != 6)
> > > > > > return AVERROR_INVALIDDATA;
> > > > > > @@ -94,7 +96,19 @@ static int amr_read_header(AVFormatContext *s)
> > > > > > if (avio_read(pb, header + 6, 3) != 3)
> > > > > > return AVERROR_INVALIDDATA;
> > > > > > if (memcmp(header, AMRWB_header, 9)) {
> > > > > > - return -1;
> > > > > > + if (avio_read(pb, header + 6 + 3, 3) != 3)
> > > > > > + return AVERROR_INVALIDDATA;
> > > > > > + if (memcmp(header, AMR_MC_header, 12)) {
> > > > > > + if (avio_read(pb, header + 6 + 3 + 3, 3) != 3)
> > > > > > + return AVERROR_INVALIDDATA;
> > > > > > + if (memcmp(header, AMRWB_MC_header, 15)) {
> > > > > > + return -1;
> > > > > > + }
> > > > > > + avpriv_report_missing_feature(s, "multi-channel AMRWB");
> > > > > > + return AVERROR_PATCHWELCOME;
> > > > > > + }
> > > > > > + avpriv_report_missing_feature(s, "multi-channel AMR");
> > > > > > + return AVERROR_PATCHWELCOME;
> > > > > > }
> > > > > >
> > > > > > st->codecpar->codec_tag = MKTAG('s', 'a', 'w', 'b');
> > > > > > --
> > > &

[FFmpeg-devel] [PATCH 1/2] avcodec: add amr parser

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/Makefile |   1 +
 libavcodec/amr_parser.c | 103 
 libavcodec/parsers.c|   1 +
 libavformat/amr.c   |  63 +---
 4 files changed, 117 insertions(+), 51 deletions(-)
 create mode 100644 libavcodec/amr_parser.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 829ff88e1d..d3b6db0b49 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1079,6 +1079,7 @@ OBJS-$(CONFIG_AAC_PARSER)  += aac_parser.o 
aac_ac3_parser.o \
   mpeg4audio.o
 OBJS-$(CONFIG_AC3_PARSER)  += ac3tab.o aac_ac3_parser.o
 OBJS-$(CONFIG_ADX_PARSER)  += adx_parser.o adx.o
+OBJS-$(CONFIG_AMR_PARSER)  += amr_parser.o
 OBJS-$(CONFIG_AV1_PARSER)  += av1_parser.o
 OBJS-$(CONFIG_AVS2_PARSER) += avs2_parser.o
 OBJS-$(CONFIG_AVS3_PARSER) += avs3_parser.o
diff --git a/libavcodec/amr_parser.c b/libavcodec/amr_parser.c
new file mode 100644
index 00..2659cb40d7
--- /dev/null
+++ b/libavcodec/amr_parser.c
@@ -0,0 +1,103 @@
+/*
+ * Copyright (c) 2021 Paul B Mahol
+ *
+ * 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
+ */
+
+/**
+ * @file
+ * AMR audio parser
+ *
+ * Splits packets into individual blocks.
+ */
+
+#include "libavutil/intreadwrite.h"
+#include "parser.h"
+
+static const uint8_t amrnb_packed_size[16] = {
+13, 14, 16, 18, 20, 21, 27, 32, 6, 1, 1, 1, 1, 1, 1, 1
+};
+static const uint8_t amrwb_packed_size[16] = {
+18, 24, 33, 37, 41, 47, 51, 59, 61, 6, 1, 1, 1, 1, 1, 1
+};
+
+typedef struct AMRParseContext {
+ParseContext pc;
+uint64_t cumulated_size;
+uint64_t block_count;
+int remaining;
+} AMRParseContext;
+
+static int amr_parse(AVCodecParserContext *s1,
+ AVCodecContext *avctx,
+ const uint8_t **poutbuf, int *poutbuf_size,
+ const uint8_t *buf, int buf_size)
+{
+AMRParseContext *s = s1->priv_data;
+ParseContext *pc = &s->pc;
+int next = END_NOT_FOUND;
+
+*poutbuf_size = 0;
+*poutbuf = NULL;
+
+if (s1->flags & PARSER_FLAG_COMPLETE_FRAMES) {
+next = buf_size;
+} else {
+if (s->remaining) {
+next = s->remaining;
+} else {
+int mode = (buf[0] >> 3) & 0x0F;
+
+if (avctx->codec_id == AV_CODEC_ID_AMR_NB) {
+next = amrnb_packed_size[mode];
+} else if (avctx->codec_id == AV_CODEC_ID_AMR_WB) {
+next = amrwb_packed_size[mode];
+}
+}
+
+s->remaining = next - FFMIN(buf_size, next);
+if (s->remaining)
+next = END_NOT_FOUND;
+
+if (next != END_NOT_FOUND) {
+if (s->cumulated_size < UINT64_MAX - next) {
+s->cumulated_size += next;
+/* Both AMR formats have 50 frames per second */
+avctx->bit_rate = s->cumulated_size / ++s->block_count * 8 * 
50;
+}
+}
+
+if (ff_combine_frame(pc, next, &buf, &buf_size) < 0) {
+*poutbuf  = NULL;
+*poutbuf_size = 0;
+return buf_size;
+}
+}
+
+s1->duration = avctx->codec_id == AV_CODEC_ID_AMR_NB ? 160 : 320;
+
+*poutbuf = buf;
+*poutbuf_size = buf_size;
+return next;
+}
+
+const AVCodecParser ff_amr_parser = {
+.codec_ids  = { AV_CODEC_ID_AMR_NB, AV_CODEC_ID_AMR_WB },
+.priv_data_size = sizeof(AMRParseContext),
+.parser_parse   = amr_parse,
+.parser_close   = ff_parse_close,
+};
diff --git a/libavcodec/parsers.c b/libavcodec/parsers.c
index 5ab1a226d9..6b40c18d80 100644
--- a/libavcodec/parsers.c
+++ b/libavcodec/parsers.c
@@ -24,6 +24,7 @@ extern const AVCodecParser ff_aac_parser;
 extern const AVCodecParser ff_aac_latm_parser;
 extern const AVCodecParser ff_ac3_parser;
 extern const AVCodecParser ff_adx_parser;
+extern const AVCodecParser ff_amr_parser;
 extern const AVCodecParser ff_av1_parser;
 extern const AVCodecParser ff_avs2_parser;
 extern const AVCodecParser ff_avs3_parser;
diff --git a/libavformat/amr.c b/l

[FFmpeg-devel] [PATCH 2/2] avcodec/amr*dec: add multichannel support

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/amr_parser.c | 39 ++
 libavcodec/amrnbdec.c   | 54 +++-
 libavcodec/amrwbdec.c   | 59 +--
 libavformat/amr.c   | 61 +
 4 files changed, 143 insertions(+), 70 deletions(-)

diff --git a/libavcodec/amr_parser.c b/libavcodec/amr_parser.c
index 2659cb40d7..222d8e05e9 100644
--- a/libavcodec/amr_parser.c
+++ b/libavcodec/amr_parser.c
@@ -39,6 +39,7 @@ typedef struct AMRParseContext {
 ParseContext pc;
 uint64_t cumulated_size;
 uint64_t block_count;
+int current_channel;
 int remaining;
 } AMRParseContext;
 
@@ -57,21 +58,35 @@ static int amr_parse(AVCodecParserContext *s1,
 if (s1->flags & PARSER_FLAG_COMPLETE_FRAMES) {
 next = buf_size;
 } else {
-if (s->remaining) {
-next = s->remaining;
-} else {
-int mode = (buf[0] >> 3) & 0x0F;
-
-if (avctx->codec_id == AV_CODEC_ID_AMR_NB) {
-next = amrnb_packed_size[mode];
-} else if (avctx->codec_id == AV_CODEC_ID_AMR_WB) {
-next = amrwb_packed_size[mode];
+int offset = 0;
+
+for (int ch = s->current_channel; ch < avctx->channels; ch++) {
+if (s->remaining) {
+next = s->remaining;
+} else {
+int mode = (buf[offset] >> 3) & 0x0F;
+
+if (avctx->codec_id == AV_CODEC_ID_AMR_NB) {
+next = amrnb_packed_size[mode];
+} else if (avctx->codec_id == AV_CODEC_ID_AMR_WB) {
+next = amrwb_packed_size[mode];
+}
+}
+
+offset += next;
+if (offset >= buf_size) {
+s->remaining = offset - buf_size;
+next = END_NOT_FOUND;
+s->current_channel = ch;
+break;
+} else {
+s->remaining = 0;
+s->current_channel = 0;
 }
 }
 
-s->remaining = next - FFMIN(buf_size, next);
-if (s->remaining)
-next = END_NOT_FOUND;
+if (s->remaining == 0)
+next = offset;
 
 if (next != END_NOT_FOUND) {
 if (s->cumulated_size < UINT64_MAX - next) {
diff --git a/libavcodec/amrnbdec.c b/libavcodec/amrnbdec.c
index e366a09976..472fa85f87 100644
--- a/libavcodec/amrnbdec.c
+++ b/libavcodec/amrnbdec.c
@@ -145,6 +145,10 @@ typedef struct AMRContext {
 
 } AMRContext;
 
+typedef struct AMRChannelsContext {
+AMRContext ch[2];
+} AMRChannelsContext;
+
 /** Double version of ff_weighted_vector_sumf() */
 static void weighted_vector_sumd(double *out, const double *in_a,
  const double *in_b, double weight_coeff_a,
@@ -159,20 +163,24 @@ static void weighted_vector_sumd(double *out, const 
double *in_a,
 
 static av_cold int amrnb_decode_init(AVCodecContext *avctx)
 {
-AMRContext *p = avctx->priv_data;
+AMRChannelsContext *s = avctx->priv_data;
 int i;
 
-if (avctx->channels > 1) {
-avpriv_report_missing_feature(avctx, "multi-channel AMR");
+if (avctx->channels > 2) {
+avpriv_report_missing_feature(avctx, ">2 channel AMR");
 return AVERROR_PATCHWELCOME;
 }
 
-avctx->channels   = 1;
-avctx->channel_layout = AV_CH_LAYOUT_MONO;
+if (!avctx->channels) {
+avctx->channels   = 1;
+avctx->channel_layout = AV_CH_LAYOUT_MONO;
+}
 if (!avctx->sample_rate)
 avctx->sample_rate = 8000;
-avctx->sample_fmt = AV_SAMPLE_FMT_FLT;
+avctx->sample_fmt = AV_SAMPLE_FMT_FLTP;
 
+for (int ch = 0; ch < avctx->channels; ch++) {
+AMRContext *p = &s->ch[ch];
 // p->excitation always points to the same position in p->excitation_buf
 p->excitation = &p->excitation_buf[PITCH_DELAY_MAX + LP_FILTER_ORDER + 1];
 
@@ -188,6 +196,7 @@ static av_cold int amrnb_decode_init(AVCodecContext *avctx)
 ff_acelp_vectors_init(&p->acelpv_ctx);
 ff_celp_filter_init(&p->celpf_ctx);
 ff_celp_math_init(&p->celpm_ctx);
+}
 
 return 0;
 }
@@ -949,25 +958,30 @@ static int amrnb_decode_frame(AVCodecContext *avctx, void 
*data,
   int *got_frame_ptr, AVPacket *avpkt)
 {
 
-AMRContext *p = avctx->priv_data;// pointer to private data
+AMRChannelsContext *s = avctx->priv_data;// pointer to private data
 AVFrame *frame = data;
 const uint8_t *buf = avpkt->data;
 int buf_size   = avpkt->size;
-float *buf_out;  // pointer to the output data 
buffer
-int i, subframe, ret;
-float fixed_gai

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/amr*dec: add multichannel support

[Paul B Mahol]

On Fri, Oct 1, 2021 at 3:17 AM Sun Zhenliang 
wrote:

>
> Sent with a Spark
> 2021年10月1日 +0800 05:01 Paul B Mahol ，写道：
> > Signed-off-by: Paul B Mahol 
> > ---
> > libavcodec/amr_parser.c | 39 ++
> > libavcodec/amrnbdec.c | 54 +++-
> > libavcodec/amrwbdec.c | 59 +--
> > libavformat/amr.c | 61 +
> > 4 files changed, 143 insertions(+), 70 deletions(-)
> >
> > diff --git a/libavcodec/amr_parser.c b/libavcodec/amr_parser.c
> > index 2659cb40d7..222d8e05e9 100644
> > --- a/libavcodec/amr_parser.c
> > +++ b/libavcodec/amr_parser.c
> > @@ -39,6 +39,7 @@ typedef struct AMRParseContext {
> > ParseContext pc;
> > uint64_t cumulated_size;
> > uint64_t block_count;
> > + int current_channel;
> > int remaining;
> > } AMRParseContext;
> >
> > @@ -57,21 +58,35 @@ static int amr_parse(AVCodecParserContext *s1,
> > if (s1->flags & PARSER_FLAG_COMPLETE_FRAMES) {
> > next = buf_size;
> > } else {
> > - if (s->remaining) {
> > - next = s->remaining;
> > - } else {
> > - int mode = (buf[0] >> 3) & 0x0F;
> > -
> > - if (avctx->codec_id == AV_CODEC_ID_AMR_NB) {
> > - next = amrnb_packed_size[mode];
> > - } else if (avctx->codec_id == AV_CODEC_ID_AMR_WB) {
> > - next = amrwb_packed_size[mode];
> > + int offset = 0;
> > +
> > + for (int ch = s->current_channel; ch < avctx->channels; ch++) {
> > + if (s->remaining) {
> > + next = s->remaining;
> > + } else {
> > + int mode = (buf[offset] >> 3) & 0x0F;
> > +
> > + if (avctx->codec_id == AV_CODEC_ID_AMR_NB) {
> > + next = amrnb_packed_size[mode];
> > + } else if (avctx->codec_id == AV_CODEC_ID_AMR_WB) {
> > + next = amrwb_packed_size[mode];
> > + }
> > + }
> > +
> > + offset += next;
> > + if (offset >= buf_size) {
> > + s->remaining = offset - buf_size;
> > + next = END_NOT_FOUND;
> > + s->current_channel = ch;
> > + break;
> > + } else {
> > + s->remaining = 0;
> > + s->current_channel = 0;
> > }
> > }
> >
> > - s->remaining = next - FFMIN(buf_size, next);
> > - if (s->remaining)
> > - next = END_NOT_FOUND;
> > + if (s->remaining == 0)
> > + next = offset;
> >
> > if (next != END_NOT_FOUND) {
> > if (s->cumulated_size < UINT64_MAX - next) {
> > diff --git a/libavcodec/amrnbdec.c b/libavcodec/amrnbdec.c
> > index e366a09976..472fa85f87 100644
> > --- a/libavcodec/amrnbdec.c
> > +++ b/libavcodec/amrnbdec.c
> > @@ -145,6 +145,10 @@ typedef struct AMRContext {
> >
> > } AMRContext;
> >
> > +typedef struct AMRChannelsContext {
> > + AMRContext ch[2];
> > +} AMRChannelsContext;
> > +
> > /** Double version of ff_weighted_vector_sumf() */
> > static void weighted_vector_sumd(double *out, const double *in_a,
> > const double *in_b, double weight_coeff_a,
> > @@ -159,20 +163,24 @@ static void weighted_vector_sumd(double *out,
> const double *in_a,
> >
> > static av_cold int amrnb_decode_init(AVCodecContext *avctx)
> > {
> > - AMRContext *p = avctx->priv_data;
> > + AMRChannelsContext *s = avctx->priv_data;
> > int i;
> >
> > - if (avctx->channels > 1) {
> > - avpriv_report_missing_feature(avctx, "multi-channel AMR");
> > + if (avctx->channels > 2) {
> > + avpriv_report_missing_feature(avctx, ">2 channel AMR");
> > return AVERROR_PATCHWELCOME;
> > }
> >
> > - avctx->channels = 1;
> > - avctx->channel_layout = AV_CH_LAYOUT_MONO;
> > + if (!avctx->channels) {
> > + avctx->channels = 1;
> > + avctx->channel_layout = AV_CH_LAYOUT_MONO;
> > + }
> > if (!avctx->sample_rate)
> > avctx->sample_rate = 8000;
> > - avctx->sample_fmt = AV_SAMPLE_FMT_FLT;
> > + avctx->sample_fmt = AV_SAMPLE_FMT_FLTP;
> >
> > + for (int ch = 0; ch < avctx->channels; ch++) {
> > + AMRContext *p = &s->ch[ch];
> > // p->excitation always points to the same position in p->excitation_buf
> > p->excitation = &p->excitation_buf[PITCH_DELAY_MAX + LP_FILTER_ORDER +
> 1];
> >
> > @@ -188,6 +196,7 @@ static av_cold int amrnb_decode_init(AVCodecContext
> *avctx)
> > ff_acelp_vectors_init(&p->acelpv_ctx);
> > ff_celp_filter_init(&p->celpf_ctx);
> > ff_celp_math_init(&p->celpm_ctx);
&

Re: [FFmpeg-devel] [PATCH 001/218] avfilter/f_reverse: Don't use redundant query_formats function

[Paul B Mahol]

lgtm
___
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 v11 10/14] avfilter/textmod: Add textmod, censor and show_speaker filters

[Paul B Mahol]

Please remove '_' from all your filters names. It is not needed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/amr*dec: add multichannel support

[Paul B Mahol]

On Fri, Oct 1, 2021 at 4:03 PM Sun Zhenliang 
wrote:

> 2021年10月1日 +0800 14:41 Paul B Mahol ，写道：
> > On Fri, Oct 1, 2021 at 3:17 AM Sun Zhenliang  >
> > wrote:
> >
> > >
> > > Sent with a Spark
> > > 2021年10月1日 +0800 05:01 Paul B Mahol ，写道：
> > > > Signed-off-by: Paul B Mahol 
> > > > ---
> > > > libavcodec/amr_parser.c | 39 ++
> > > > libavcodec/amrnbdec.c | 54 +++-
> > > > libavcodec/amrwbdec.c | 59 +--
> > > > libavformat/amr.c | 61 +
> > > > 4 files changed, 143 insertions(+), 70 deletions(-)
> > > >
> > > > diff --git a/libavcodec/amr_parser.c b/libavcodec/amr_parser.c
> > > > index 2659cb40d7..222d8e05e9 100644
> > > > --- a/libavcodec/amr_parser.c
> > > > +++ b/libavcodec/amr_parser.c
> > > > @@ -39,6 +39,7 @@ typedef struct AMRParseContext {
> > > > ParseContext pc;
> > > > uint64_t cumulated_size;
> > > > uint64_t block_count;
> > > > + int current_channel;
> > > > int remaining;
> > > > } AMRParseContext;
> > > >
> > > > @@ -57,21 +58,35 @@ static int amr_parse(AVCodecParserContext *s1,
> > > > if (s1->flags & PARSER_FLAG_COMPLETE_FRAMES) {
> > > > next = buf_size;
> > > > } else {
> > > > - if (s->remaining) {
> > > > - next = s->remaining;
> > > > - } else {
> > > > - int mode = (buf[0] >> 3) & 0x0F;
> > > > -
> > > > - if (avctx->codec_id == AV_CODEC_ID_AMR_NB) {
> > > > - next = amrnb_packed_size[mode];
> > > > - } else if (avctx->codec_id == AV_CODEC_ID_AMR_WB) {
> > > > - next = amrwb_packed_size[mode];
> > > > + int offset = 0;
> > > > +
> > > > + for (int ch = s->current_channel; ch < avctx->channels; ch++) {
> > > > + if (s->remaining) {
> > > > + next = s->remaining;
> > > > + } else {
> > > > + int mode = (buf[offset] >> 3) & 0x0F;
> > > > +
> > > > + if (avctx->codec_id == AV_CODEC_ID_AMR_NB) {
> > > > + next = amrnb_packed_size[mode];
> > > > + } else if (avctx->codec_id == AV_CODEC_ID_AMR_WB) {
> > > > + next = amrwb_packed_size[mode];
> > > > + }
> > > > + }
> > > > +
> > > > + offset += next;
> > > > + if (offset >= buf_size) {
> > > > + s->remaining = offset - buf_size;
> > > > + next = END_NOT_FOUND;
> > > > + s->current_channel = ch;
> > > > + break;
> > > > + } else {
> > > > + s->remaining = 0;
> > > > + s->current_channel = 0;
> > > > }
> > > > }
> > > >
> > > > - s->remaining = next - FFMIN(buf_size, next);
> > > > - if (s->remaining)
> > > > - next = END_NOT_FOUND;
> > > > + if (s->remaining == 0)
> > > > + next = offset;
> > > >
> > > > if (next != END_NOT_FOUND) {
> > > > if (s->cumulated_size < UINT64_MAX - next) {
> > > > diff --git a/libavcodec/amrnbdec.c b/libavcodec/amrnbdec.c
> > > > index e366a09976..472fa85f87 100644
> > > > --- a/libavcodec/amrnbdec.c
> > > > +++ b/libavcodec/amrnbdec.c
> > > > @@ -145,6 +145,10 @@ typedef struct AMRContext {
> > > >
> > > > } AMRContext;
> > > >
> > > > +typedef struct AMRChannelsContext {
> > > > + AMRContext ch[2];
> > > > +} AMRChannelsContext;
> > > > +
> > > > /** Double version of ff_weighted_vector_sumf() */
> > > > static void weighted_vector_sumd(double *out, const double *in_a,
> > > > const double *in_b, double weight_coeff_a,
> > > > @@ -159,20 +163,24 @@ static void weighted_vector_sumd(double *out,
> > > const double *in_a,
> > > >
> > > > static av_cold int amrnb_decode_init(AVCodecContext *avctx)
> > > > {
> > > > - AMRContext *p = avctx->priv_data;
> > > > + AMRChannelsContext *s = avctx->priv_data;
> > > > int i;
> > > >
> > > > - if (avctx->channels > 1) {
> > > > - avpriv_report_missing_feature(avctx, "multi-channel AMR");
> > > > + if (avctx->channels > 2) {
> > > > + avpriv_rep

Re: [FFmpeg-devel] [PATCH v11 10/14] avfilter/textmod: Add textmod, censor and show_speaker filters

[Paul B Mahol]

On Fri, Oct 1, 2021 at 9:43 PM Soft Works  wrote:

>
>
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > Paul B Mahol
> > Sent: Friday, 1 October 2021 10:57
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH v11 10/14] avfilter/textmod: Add
> > textmod, censor and show_speaker filters
> >
> > Please remove '_' from all your filters names. It is not needed
>
> Yes ok, will do.
>
> Should I also rename: overlay_graphicsubs => overlaygraphicsubs ?
>

that is really very long, maybe overlayvsubs vs overlaytsubs

>
> Any other suggestions about filter naming, do you think they are fine?
>
> Thanks,
> 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] [PATCH 1/2] avfilter/avfilter: Remove unused buffer

[Paul B Mahol]

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

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

Re: [FFmpeg-devel] [PATCH] avfilter: add (a)latency filters

[Paul B Mahol]

will apply soon
___
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 06/20] avformat/sccdec: Don't use uninitialized data, fix crash, simplify logic

[Paul B Mahol]

lgtm i guess
___
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 07/20] avformat/sccdec: Remove redundant check

[Paul B Mahol]

lgtm i guess
___
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 08/20] avformat/sccdec: Fix position of returned subtitle packets

[Paul B Mahol]

maybe ok
___
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 10/20] avformat/sccdec: Avoid zero-terminating unnecessarily

[Paul B Mahol]

probably fine
___
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 17/20] fate/subtitles: Add scc remux test

[Paul B Mahol]

ok
___
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 15/20] fate/subtitles: Add remuxing test for lrc

[Paul B Mahol]

ok
___
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 20/20] avformat/lrcenc: Remove unnecessary header

[Paul B Mahol]

lgtm
___
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/20] avutil/md5: Avoid av_unused variable

[Paul B Mahol]

ok
___
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 01/20] libpostproc/postprocess_template: Don't reimplement FFSWAP

[Paul B Mahol]

ok
___
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 12/20] avformat/(lrc|scc)enc: Use avio_w8() to write a single char

[Paul B Mahol]

lgtm
___
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 19/20] avformat/lrcenc: Unify writing timestamps

[Paul B Mahol]

probably ok
___
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 18/20] avformat/lrcenc: Avoid allocations for writing packet data

[Paul B Mahol]

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

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

Re: [FFmpeg-devel] [PATCH 11/20] avformat/subtitles: Honour ff_subtitles_read_line() documentation

[Paul B Mahol]

lgtm
___
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 16/20] fftools/ffmpeg_opt: Remove write-only variable

[Paul B Mahol]

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

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

Re: [FFmpeg-devel] [PATCH 09/20] avformat/sccdec: Make constants more intelligible

[Paul B Mahol]

probably ok i guess
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_floodfill: constify the AVFrame parameter in is_same() and pick_pixel() functions

[Paul B Mahol]

lgtm
___
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/2] avcodec: add amr parser

[Paul B Mahol]

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

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

Re: [FFmpeg-devel] [PATCH 3/3] swscale/swscale: Pass slice location into unscaled code also for dst scaling

[Paul B Mahol]

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

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

Re: [FFmpeg-devel] [PATCH 2/3] swscale/alphablend: Fix slice handling

[Paul B Mahol]

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

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

Re: [FFmpeg-devel] [PATCH] doc/filters: added possible values to @item win_func

[Paul B Mahol]

On Thu, Sep 30, 2021 at 1:04 PM Gyan Doshi  wrote:

>
>
> On 2021-09-30 04:28 pm, Paul B Mahol wrote:
> > On Thu, Sep 30, 2021 at 12:51 PM Gyan Doshi  wrote:
> >
> >>
> >> On 2021-09-30 04:20 pm, Paul B Mahol wrote:
> >>> On Thu, Sep 30, 2021 at 10:53 AM Gyan Doshi  wrote:
> >>>
> >>>> On 2021-09-30 02:19 pm, Arif Driessen wrote:
> >>>>> Okay. But is it a @chapter Various Windowing Functions (placed at the
> >> end
> >>>>> just before @chapter See Also and @chapter Authors) or a @section
> >> Various
> >>>>> Windowing Functions, that has to live under some chapter? (...Which?)
> >>>> Just keep the current patch for now. I'll push and then consolidate.
> >>>>
> >>> Please revert your commit, I haven't approved your changes that
> >> duplicates
> >>> lines unneceassary.
> >> You don't maintain docs, I do.
> >>
> > You are self proclaimed maintainer only.
> > If you do not fix docs soon i will do it instead of you, with above
> commit
> > reverted.
>
> Check the MAINTAINERS file.
>

That file is seriously obsolete.


> Like I said earlier, I'll make a separate section soon.
>

Time it ticking.



>
> Regards,
> Gyan
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avfilter/x86/vf_blend: unify indentation format

[Paul B Mahol]

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

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

Re: [FFmpeg-devel] [PATCH 2/4] libavfilter/x86/vf_threshold_init: remove condition s->depth == 16

[Paul B Mahol]

NAK, the x86 code is not working correctly with other depths, as there is
fixed 0x80 (for 8bit and 0x8000 for 16bit) variable.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/4] libavfilter/x86/vf_threshold_init: remove condition s->depth == 16

[Paul B Mahol]

I can not test avx512 so someone lese needs to apply it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: GEM Raster image decoder

[Paul B Mahol]

probably ok
___
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".