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 = >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 = >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 = >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] 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] [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: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 

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 process (one shouldn't allowed us

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] [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 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] [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] [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] [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 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 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] 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] area changed: scdet filter

[Paul B Mahol]

On Sun, May 12, 2024 at 1:05 PM  wrote:

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

Inconsistent code style with other filters. (Mostly using AVFilterLink*
link instead of AVFilterLink *link).

Unrelated changes, please split trivial unrelated changes into separate
patches.

Can't tables be generated at .init/.config_props time? No point in storing
them into binary.

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.

Could split frame clone change into earlier separate patch.

Where are results of improvements with accuracy so it can be confirmed?



> Signed-off-by: raduct 
> ---
>  doc/filters.texi|  13 +++
>  libavfilter/scene_sad.c | 167 +++-
>  libavfilter/scene_sad.h |   2 +
>  libavfilter/vf_scdet.c  | 150 
>  tests/fate/filter-video.mak |   3 +
>  5 files changed, 281 insertions(+), 54 deletions(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index bfa8ccec8b..de83a5e322 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -21797,6 +21797,19 @@ Default value is @code{10.}.
>  @item sc_pass, s
>  Set the flag to pass scene change frames to the next filter. Default value
> is @code{0}
>  You can enable it if you want to get snapshot of scene change frames only.
> +
> +@item mode
> +Set the scene change detection method. Default value is @code{0}
> +Available values are:
> +
> +@table @samp
> +@item 0
> +Regular sum of absolute linear differences.
> +
> +@item 1
> +Sum of mean of cubic root differences.
> +
> +@end table
>  @end table
>
>  @anchor{selectivecolor}
> diff --git a/libavfilter/scene_sad.c b/libavfilter/scene_sad.c
> index caf911eb5d..5280e356cc 100644
> --- a/libavfilter/scene_sad.c
> +++ b/libavfilter/scene_sad.c
> @@ -65,9 +65,174 @@ ff_scene_sad_fn ff_scene_sad_get_fn(int depth)
>  if (!sad) {
>  if (depth == 8)
>  sad = ff_scene_sad_c;
> -if (depth == 16)
> +else if (depth == 16)
>  sad = ff_scene_sad16_c;
>  }
>  return sad;
>  }
>
> +/*
> +* Lookup table for 40.25*pow(i,1/3) - a.k.a cubic root extended to 0 - 255
> interval
> +* Increase the weight of small differences compared to linear
> +*/
> +static const uint8_t cbrtTable[256] = {
> +0,   40,  51,  58,  64,  69,  73,  77,  81,  84,  87,  90,  92,  95,  97,
> 99,
> +101, 103, 105, 107, 109, 111, 113, 114, 116, 118, 119, 121, 122, 124, 125,
> 126,
> +128, 129, 130, 132, 133, 134, 135, 136, 138, 139, 140, 141, 142, 143, 144,
> 145,
> +146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 158, 159,
> 160,
> +161, 162, 163, 163, 164, 165, 166, 167, 167, 168, 169, 170, 170, 171, 172,
> 173,
> +173, 174, 175, 176, 176, 177, 178, 178, 179, 180, 180, 181, 182, 182, 183,
> 184,
> +184, 185, 186, 186, 187, 187, 188, 189, 189, 190, 190, 191, 192, 192, 193,
> 193,
> +194, 195, 195, 196, 196, 197, 197, 198, 199, 199, 200, 200, 201, 201, 202,
> 202,
> +203, 203, 204, 204, 205, 205, 206, 206, 207, 207, 208, 208, 209, 209, 210,
> 210,
> +211, 211, 212, 212, 213, 213, 214, 214, 215, 215, 216, 216, 217, 217, 218,
> 218,
> +219, 219, 219, 220, 220, 221, 221, 222, 222, 223, 223, 223, 224, 224, 225,
> 225,
> +226, 226, 226, 227, 227, 228, 228, 229, 229, 229, 230, 230, 231, 231, 231,
> 232,
> +232, 233, 233, 233, 234, 234, 235, 235, 235, 236, 236, 237, 237, 237, 238,
> 238,
> +238, 239, 239, 240, 240, 240, 241, 241, 242, 242, 242, 243, 243, 243, 244,
> 244,
> +244, 245, 245, 246, 246, 246, 247, 247, 247, 248, 248, 248, 249, 249, 249,
> 250,
> +250, 250, 251, 251, 252, 252, 252, 253, 253, 253, 254, 254, 254, 255, 255,
> 255 };
> +
> +/*
> +* Lookup table for 101.52*pow(i,1/3) - a.k.a cubic root extended to 0 -
> 1023 interval
> +* Increase the weight of small differences compared to linear
> +*/
> +static const uint16_t cbrtTable10[1024] = {
> +  0, 102, 128, 146, 161, 174, 184, 194, 203, 211, 219, 226, 232, 239, 245,
> 250, 256, 261, 266, 271, 276, 280, 284, 289, 293, 297, 301, 305, 308, 312,
> 315, 319,
> +322, 326, 329, 332, 335, 338, 341, 344, 347, 350, 353, 356, 358, 361, 364,
> 366, 369, 371, 374, 376, 379, 381, 384, 386, 388, 391, 393, 395, 397, 400,
> 402, 404,
> +406, 408, 410, 412, 414, 416, 418, 420, 422, 424, 426, 428, 430, 432, 434,
> 436, 437, 439, 441, 443, 445, 446, 448, 450, 452, 453, 455, 457, 458, 460,
> 462, 463,
> +465, 466, 468, 470, 471, 473, 474, 476, 477, 479, 480, 482, 483, 485, 486,
> 488, 489, 491, 492, 494, 495, 497, 498, 499, 501, 502, 504, 505, 506, 508,
> 509, 510,
> +512, 513, 514, 516, 517, 

Re: [FFmpeg-devel] [PATCH] avfilter/src_movie: Remove align dimension to fix crash

[Paul B Mahol]

On Sat, May 11, 2024 at 3:24 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> Paul B Mahol:
> > On Sat, May 11, 2024 at 5:28 AM James Almer  wrote:
> >
> >> On 5/10/2024 6:26 PM, Paul B Mahol wrote:
> >>> On Fri, May 10, 2024 at 10:56 AM Zhao Zhili 
> >> wrote:
> >>>
> >>>> From: Zhao Zhili 
> >>>>
> >>>> The alignment is handled by ff_default_get_video_buffer2. We
> >>>> shouldn't use the aligned width/height as FFFramePool width/height.
> >>>> It cause recreate FFFramePool inside ff_default_get_video_buffer2.
> >>>> The recreate of FFFramePool together with multi-threads decoding
> >>>> leading to data race and crash, for example,
> >>>> ./ffplay -f lavfi -i movie=foo.mp4,drawtext=text=bar
> >>>> ---
> >>>>   libavfilter/src_movie.c | 1 -
> >>>>   1 file changed, 1 deletion(-)
> >>>>
> >>>> diff --git a/libavfilter/src_movie.c b/libavfilter/src_movie.c
> >>>> index e2cdcf17db..5099012100 100644
> >>>> --- a/libavfilter/src_movie.c
> >>>> +++ b/libavfilter/src_movie.c
> >>>> @@ -187,7 +187,6 @@ static int get_buffer(AVCodecContext *avctx,
> AVFrame
> >>>> *frame, int flags)
> >>>>
> >>>>   switch (avctx->codec_type) {
> >>>>   case AVMEDIA_TYPE_VIDEO:
> >>>> -avcodec_align_dimensions2(avctx, , , linesize_align);
> >>>>
> >>>
> >>> Left unused linesize_align[].
> >>>
> >>> With locking introduced, cant you remove copy check hack above and
> force
> >>> new_pool every time?
> >>
> >> Can't this just always use avcodec_default_get_buffer2() (So in short,
> >> not set a custom get_buffer2() callback at all), since it also has its
> >> own buffer pool? Much like it's being used for AV_CODEC_CAP_DR1
> >> decoders, it can be used for all of them.
> >>
> >> ff_default_get_{video,audio}_buffer() don't seem like they bring any
> >> benefit here. In fact, not using them may be an improvement considering
> >> they allocate a whole new AVFrame forcing the callback to copy props,
> >> move the reference and then free the superfluous AVFrame afterwards.
> >>
> >
> > In that case frame is always not part of frame pool and thus not
> writable,
>
> What makes you think that frames that are not part of a frame pool are
> not writable?
>

Any next filter after (a)movie filter that calls ff_null_get_video_buffer()
will not? work and using
ff_default_get_video_buffer() will allocate new frame.

Original idea was/is to improve performance by using DR support provided by
decoders.


>
> > any next
> > filter that needs writable frames will just allocate and sometimes even
> > copy whole frame data.
> > The original idea is to avoid that copy.
> >
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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/src_movie: Remove align dimension to fix crash

[Paul B Mahol]

On Sat, May 11, 2024 at 5:28 AM James Almer  wrote:

> On 5/10/2024 6:26 PM, Paul B Mahol wrote:
> > On Fri, May 10, 2024 at 10:56 AM Zhao Zhili 
> wrote:
> >
> >> From: Zhao Zhili 
> >>
> >> The alignment is handled by ff_default_get_video_buffer2. We
> >> shouldn't use the aligned width/height as FFFramePool width/height.
> >> It cause recreate FFFramePool inside ff_default_get_video_buffer2.
> >> The recreate of FFFramePool together with multi-threads decoding
> >> leading to data race and crash, for example,
> >> ./ffplay -f lavfi -i movie=foo.mp4,drawtext=text=bar
> >> ---
> >>   libavfilter/src_movie.c | 1 -
> >>   1 file changed, 1 deletion(-)
> >>
> >> diff --git a/libavfilter/src_movie.c b/libavfilter/src_movie.c
> >> index e2cdcf17db..5099012100 100644
> >> --- a/libavfilter/src_movie.c
> >> +++ b/libavfilter/src_movie.c
> >> @@ -187,7 +187,6 @@ static int get_buffer(AVCodecContext *avctx, AVFrame
> >> *frame, int flags)
> >>
> >>   switch (avctx->codec_type) {
> >>   case AVMEDIA_TYPE_VIDEO:
> >> -avcodec_align_dimensions2(avctx, , , linesize_align);
> >>
> >
> > Left unused linesize_align[].
> >
> > With locking introduced, cant you remove copy check hack above and force
> > new_pool every time?
>
> Can't this just always use avcodec_default_get_buffer2() (So in short,
> not set a custom get_buffer2() callback at all), since it also has its
> own buffer pool? Much like it's being used for AV_CODEC_CAP_DR1
> decoders, it can be used for all of them.
>
> ff_default_get_{video,audio}_buffer() don't seem like they bring any
> benefit here. In fact, not using them may be an improvement considering
> they allocate a whole new AVFrame forcing the callback to copy props,
> move the reference and then free the superfluous AVFrame afterwards.
>

In that case frame is always not part of frame pool and thus not writable,
any next
filter that needs writable frames will just allocate and sometimes even
copy whole frame data.
The original idea is to avoid that copy.


> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] FFmpeg, zlib based modules' FATE tests expecting bit-exact and Fedora switching to zlib-ng

[Paul B Mahol]

On Fri, May 10, 2024 at 10:38 PM Jan Ekström  wrote:

> Hi,
>
> As of Fedora 40, the zlib provider has been switched to zlib-ng
> (https://fedoraproject.org/wiki/Changes/ZlibNGTransition). This has
> reared the ugly fact that we expect that the usage of zlib APIs is
> bit-exact.
>
> Some of these tests such as copy-apng that only do remux can be moved
> from transcode shell command to stream_remux (which does not output a
> hash and the exact file size), but then there are such that f.ex.
> encode PNG for cover art handling or so. An example of switching is
> for example the patch in
> https://github.com/jeeb/ffmpeg/commits/zlib_ng_fixups .
>
> Thus my question to the community is, how do we handle this? Currently
> on Fedora 40 there's a bunch of failures which makes actual
> development somewhat harder as you need to ignore these (or always
> have a commit updating the references in your working branch).
>
> One alternative is to check for zlib-ng in configure, and then have
> two separate reference files, but if zlib-ng is still an active
> project, its behavior might change in the future? I mean, zlib hasn't
> changed for the same parameters for quite a while, so there is a
> precedent for it, but somehow it feels imperfect.
>
> So I'd love to hear any ideas for how to handle this.
>
> The list of current failures is as follows:
>
> diff --git a/tests/ref/fate/copy-apng b/tests/ref/fate/copy-apng
> index 3057573cee..c180273c9f 100644
> --- a/tests/ref/fate/copy-apng
> +++ b/tests/ref/fate/copy-apng
> @@ -1,5 +1,5 @@
> -a4c46fad7716ad094eb3c78b74ca0244 *tests/data/fate/copy-apng.apng
> -6209864 tests/data/fate/copy-apng.apng
> +d726bd22bfa94786c1294b882df09109 *tests/data/fate/copy-apng.apng
> +6207936 tests/data/fate/copy-apng.apng
>  #tb 0: 1/25
>  #media_type 0: video
>  #codec_id 0: rawvideo
> diff --git a/tests/ref/fate/cover-art-aiff-id3v2-remux
> b/tests/ref/fate/cover-art-aiff-id3v2-remux
> index a59ba37c65..8e29b3a102 100644
> --- a/tests/ref/fate/cover-art-aiff-id3v2-remux
> +++ b/tests/ref/fate/cover-art-aiff-id3v2-remux
> @@ -1,5 +1,5 @@
> -330ad2bf538e91a31752b38024461df1
> *tests/data/fate/cover-art-aiff-id3v2-remux.aiff
> -608914 tests/data/fate/cover-art-aiff-id3v2-remux.aiff
> +b8982155c5d711d99fbeb0e3140ad691
> *tests/data/fate/cover-art-aiff-id3v2-remux.aiff
> +614766 tests/data/fate/cover-art-aiff-id3v2-remux.aiff
>  #tb 0: 1/44100
>  #media_type 0: audio
>  #codec_id 0: pcm_s16be
> @@ -27,7 +27,7 @@
>  #sar 4: 1/1
>  0,  0,  0, 1024, 4096, 0xdac4695d
>  1,  0,  0,0,19650, 0xd5662610
> -2,  0,  0,0,   184497, 0xc33f8d44
> +2,  0,  0,0,   190348, 0x84b5e334
>  3,  0,  0,0,   368254, 0xfa7f4bd8
>  4,  0,  0,0,19650, 0xd5662610
>  0,   1024,   1024, 1024, 4096, 0xad05c909
> diff --git a/tests/ref/fate/cover-art-flac-remux
> b/tests/ref/fate/cover-art-flac-remux
> index fa91975881..b46e0cc4d4 100644
> --- a/tests/ref/fate/cover-art-flac-remux
> +++ b/tests/ref/fate/cover-art-flac-remux
> @@ -1,5 +1,5 @@
> -6defc5081a59ab12c8a5f9e263b25068
> *tests/data/fate/cover-art-flac-remux.flac
> -1098537 tests/data/fate/cover-art-flac-remux.flac
> +248679bc3add689963c5aef23cfca4f4
> *tests/data/fate/cover-art-flac-remux.flac
> +1108011 tests/data/fate/cover-art-flac-remux.flac
>  #extradata 0:   34, 0x8d830abd
>  #tb 0: 1/44100
>  #media_type 0: audio
> @@ -38,7 +38,7 @@
>  #channel_layout_name 6: 2 channels (FL+FC)
>  0,  0,  0, 4608,   14, 0x242b036d
>  1,  0,  0,0,66888, 0x1fd72743
> -2,  0,  0,0,   438706, 0x8bcb753b
> +2,  0,  0,0,   448180, 0xe9f12350
>  3,  0,  0,0,21671, 0x7d1c6030
>  4,  0,  0,0,   522758, 0x7a63572f
>  5,  0,  0,0,21671, 0x7d1c6030
> diff --git a/tests/ref/fate/cover-art-mp3-id3v2-remux
> b/tests/ref/fate/cover-art-mp3-id3v2-remux
> index 52b7e72a56..1b7b3584a6 100644
> --- a/tests/ref/fate/cover-art-mp3-id3v2-remux
> +++ b/tests/ref/fate/cover-art-mp3-id3v2-remux
> @@ -1,5 +1,5 @@
> -94946f0efd5f9bb0061ac1fbff7d731f
> *tests/data/fate/cover-art-mp3-id3v2-remux.mp3
> -399346 tests/data/fate/cover-art-mp3-id3v2-remux.mp3
> +0659a01f91ad6ca205d462da37f64b1d
> *tests/data/fate/cover-art-mp3-id3v2-remux.mp3
> +404814 tests/data/fate/cover-art-mp3-id3v2-remux.mp3
>  #tb 0: 1/14112000
>  #media_type 0: audio
>  #codec_id 0: mp3
> @@ -23,7 +23,7 @@
>  0,-353590,-353590,   368640,  417, 0x15848290, S=1,   10
>  1,  0,  0,0,   208350, 0x291b44d1
>  2,  0,  0,0,15760, 0x71d5c418
> -3,  0,  0,0,   165671, 0x7c1c8070
> +3,  0,  0,0,   171139, 0x0bcc57ba
>  0,  15050,  15050,   368640,  418, 0x46f684a4
>  0, 

Re: [FFmpeg-devel] [PATCH] avfilter/src_movie: Remove align dimension to fix crash

[Paul B Mahol]

On Fri, May 10, 2024 at 10:56 AM Zhao Zhili  wrote:

> From: Zhao Zhili 
>
> The alignment is handled by ff_default_get_video_buffer2. We
> shouldn't use the aligned width/height as FFFramePool width/height.
> It cause recreate FFFramePool inside ff_default_get_video_buffer2.
> The recreate of FFFramePool together with multi-threads decoding
> leading to data race and crash, for example,
> ./ffplay -f lavfi -i movie=foo.mp4,drawtext=text=bar
> ---
>  libavfilter/src_movie.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/libavfilter/src_movie.c b/libavfilter/src_movie.c
> index e2cdcf17db..5099012100 100644
> --- a/libavfilter/src_movie.c
> +++ b/libavfilter/src_movie.c
> @@ -187,7 +187,6 @@ static int get_buffer(AVCodecContext *avctx, AVFrame
> *frame, int flags)
>
>  switch (avctx->codec_type) {
>  case AVMEDIA_TYPE_VIDEO:
> -avcodec_align_dimensions2(avctx, , , linesize_align);
>

Left unused linesize_align[].

With locking introduced, cant you remove copy check hack above and force
new_pool every time?


>  new = ff_default_get_video_buffer(outlink, w, h);
>  break;
>  case AVMEDIA_TYPE_AUDIO:
> --
> 2.42.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] [RFC] 5 year plan & Inovation

[Paul B Mahol]

On Sun, May 5, 2024 at 10:14 AM Rémi Denis-Courmont  wrote:

> Le lauantaina 4. toukokuuta 2024, 23.35.34 EEST Michael Niedermayer a
> écrit :
> > now compare to the linux kernel
> > It uses mailing lists
>
> Sorry but that is at best misleading, and at worse, plain wrong.
>
> The top-level work flow for the Linux kernel is neither mailing list, nor
> web
> forge, but CLI pull/merge. The mailing list is used to discuss and to
> notify
> pending merge requests.
>
> As far as I know, some subgroups still use mailing list for actual patch
> submission and review, and some subgroups have already switched to web
> forges.
> And there are people complaining about the difficulty and exclusivity of
> the
> mailing list-based flow.
>
> > linux is not affraid to innovate to abadon tradition where new things
> > need to be tried.
>
> Well, yes, and accordingly some of the Linux maintainers have switched to
> web
> forges, AFAIU.
>
> > linux is strong as ever
>
> This is hardly a point of comparison. Linux gets support from hardware
> design
> and vending companies as well as from large users. Linux is pretty much an
> exception more than a rule in the overall OSS ecosystem.
>
> If you want to compare FFmpeg, take a low-level middleware project of
> similar
> age and size. For instance, QEMU switched to Gitlab.com a few years ago.
>
> > If you want to be like linux you need to be like linux.
>
> FFmpeg cannot and never will be like Linux. This is a silly argument.
> Nobody
> suggested moving FFmpeg to a tiered merge flow like what Linus Torvalds
> uses.
> The scale and scope of Linux is just so much larger.
>

Merge SDR into FFmpeg, FFmpeg scale and scope, suddenly becomes now much
higher than it was before.

If the project wants to stay relatively relevant and absolutely non-obscure
than it shall just keep continuing current policy of not accepting real new
features,
like native decoders and native demuxers and native filters, and keep only
funding maintenance work, also keep gate-keeping certain contributors,
also splitting contributors into different groups and polarizing those
groups by valuing them differently,
also associating some project contributors into new agencies where
contributing values back to the project is not main factor,
also doing questionable refactoring of working code with results of
questionable performance changes and questionable refactored code design
and quality,
also generally ignoring regressions and new or old bug and feature-request
user's reports,
also leaving the project fast without any notice for selfish reasons,
also using communication prone to different interpretations,
also not valuing new research and better and faster algorithms,
also still associating self as the project developer when major last
contribution to the project was in previous decade,
also not properly valuing writing native solutions that are better than
current state of art available in open source or in general,
also using real-life meetings between selected contributors for ensuring
unrelated personal business growth and/or increasing self net-worth for
selfish reasons,
also using obscure social-channels while attempting to raise the project
relevance and ensure future funding for the project to keep personal
business alive,
also not maintaining current infrastructure and investing in new
infrastructure to reduce new regressions and bugs popping up,
also labeling and name-calling and discrediting other contributors and even
their work for selfish and short-sighted reasons,
also accepting only some radically and obscurely strict technical process
of contributing and also labeling and alienating developers and developing
process non-conforming with that technical process.

This is the project recipe for success and relevance growth and fast
advance in popularity and real progress moving forward and for healthy and
prolific project future at all dimensions and fronts.


>
> --
> Rémi Denis-Courmont
> http://www.remlab.net/
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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 5/5] avcodec/atrac9dec: Check init_get_bits8() for failure

[Paul B Mahol]

On Sun, Apr 28, 2024 at 11:31 PM Michael Niedermayer 
wrote:

> Fixes: CID1439569 Unchecked return value
> Fixes: CID1439578 Unchecked return value
>
> Sponsored-by: Sovereign Tech Fund
>

And they paid you for this low effort work!

Applause!



> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/atrac9dec.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/atrac9dec.c b/libavcodec/atrac9dec.c
> index df68407af92..e375f46fd04 100644
> --- a/libavcodec/atrac9dec.c
> +++ b/libavcodec/atrac9dec.c
> @@ -802,7 +802,9 @@ static int atrac9_decode_frame(AVCodecContext *avctx,
> AVFrame *frame,
>  if (ret < 0)
>  return ret;
>
> -init_get_bits8(, avpkt->data, avpkt->size);
> +ret = init_get_bits8(, avpkt->data, avpkt->size);
> +if (ret < 0)
> +return ret;
>
>  for (int i = 0; i < frames; i++) {
>  for (int j = 0; j < s->block_config->count; j++) {
> @@ -922,7 +924,9 @@ static av_cold int atrac9_decode_init(AVCodecContext
> *avctx)
>  return AVERROR_INVALIDDATA;
>  }
>
> -init_get_bits8(, avctx->extradata + 4, avctx->extradata_size);
> +err = init_get_bits8(, avctx->extradata + 4,
> avctx->extradata_size);
> +if (err < 0)
> +return err;
>
>  if (get_bits(, 8) != 0xFE) {
>  av_log(avctx, AV_LOG_ERROR, "Incorrect magic byte!\n");
> --
> 2.43.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 WIP 0/9] Refactor DNN

[Paul B Mahol]

Extremely low quality filters, both in source code quality and
performance/security and output quality should be queued for removal.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] 5 year plan & Inovation

[Paul B Mahol]

On Sat, Apr 20, 2024 at 12:31 AM James Almer  wrote:

> On 4/19/2024 7:28 PM, Paul B Mahol wrote:
> > On Fri, Apr 19, 2024 at 11:58 PM Vittorio Giovara <
> > vittorio.giov...@gmail.com> wrote:
> >
> >> On Fri, Apr 19, 2024 at 12:48 PM Ronald S. Bultje 
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> On Fri, Apr 19, 2024 at 2:06 PM Vittorio Giovara <
> >>> vittorio.giov...@gmail.com>
> >>> wrote:
> >>>
> >>>> On Fri, Apr 19, 2024 at 11:00 AM Diederick C. Niehorster <
> >>>> dcni...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> If i recall correctly, there was a conversation not too long ago
> >> about
> >>>> what
> >>>>> to do with all the SPI money. This seems to be a perfect use for it.
> >>>>> 1. Set up and manage a gitlab instance
> >>>>> 2. Move tickets from trac to there (possibly)
> >>>>> 3. Move fate running to there
> >>>>>
> >>>>
> >>>> +1
> >>>>
> >>>> Another good idea would be to show negative influences the door, and
> >> not
> >>>> being afraid to ban them when needed.
> >>>> Currently the CC is supposed to decide that but idk how many and which
> >>>> people have access to the mailing list control panel.
> >>>>
> >>>
> >>> The CC does not have authority to permanently ban people. See (
> >>> https://ffmpeg.org/community.html#Community-Committee-1): "The CC can
> >>> remove privileges of offending members, including [..] temporary ban
> from
> >>> the community. [..] Indefinite bans from the community must be
> confirmed
> >> by
> >>> the General Assembly, in a majority vote."
> >>>
> >>> Enough of us have access to the ML admin interface to assume this will
> >> not
> >>> be an issue.
> >>>
> >>
> >> Thanks for the clarification, it's good to know. So correct me if I'm
> >> wrong, the theoretical banning process is that a repeated offender is
> >> reported enough times, the CC notices that the temporary bans have had
> no
> >> effects and decides to invoke the GA to confirm a ban?
> >>
> >
> > By that time, if not already, GA will be majority of active bots or
> > majority of active controlled figures.
>
> What bots? That makes no sense.
>

Current situation in FFmpeg makes no sense.
Could someone explain current FFmpeg situation?


>
> >
> > So in that hypothetical case, (I hope it does not happen), 0 transparency
> > and 0 innovations,
> > with questionable commits and contributors will remain in project, if not
> > already happening.
> >
> > Its 2024 year, and FFmpeg still does not have proper subtitle support.
> > I could continue writing and adding more to the list, but I'm very
> generous
> > today.
> >
> >
> >> --
> >> 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".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] 5 year plan & Inovation

[Paul B Mahol]

On Fri, Apr 19, 2024 at 11:58 PM Vittorio Giovara <
vittorio.giov...@gmail.com> wrote:

> On Fri, Apr 19, 2024 at 12:48 PM Ronald S. Bultje 
> wrote:
>
> > Hi,
> >
> > On Fri, Apr 19, 2024 at 2:06 PM Vittorio Giovara <
> > vittorio.giov...@gmail.com>
> > wrote:
> >
> > > On Fri, Apr 19, 2024 at 11:00 AM Diederick C. Niehorster <
> > > dcni...@gmail.com>
> > > wrote:
> > >
> > > > If i recall correctly, there was a conversation not too long ago
> about
> > > what
> > > > to do with all the SPI money. This seems to be a perfect use for it.
> > > > 1. Set up and manage a gitlab instance
> > > > 2. Move tickets from trac to there (possibly)
> > > > 3. Move fate running to there
> > > >
> > >
> > > +1
> > >
> > > Another good idea would be to show negative influences the door, and
> not
> > > being afraid to ban them when needed.
> > > Currently the CC is supposed to decide that but idk how many and which
> > > people have access to the mailing list control panel.
> > >
> >
> > The CC does not have authority to permanently ban people. See (
> > https://ffmpeg.org/community.html#Community-Committee-1): "The CC can
> > remove privileges of offending members, including [..] temporary ban from
> > the community. [..] Indefinite bans from the community must be confirmed
> by
> > the General Assembly, in a majority vote."
> >
> > Enough of us have access to the ML admin interface to assume this will
> not
> > be an issue.
> >
>
> Thanks for the clarification, it's good to know. So correct me if I'm
> wrong, the theoretical banning process is that a repeated offender is
> reported enough times, the CC notices that the temporary bans have had no
> effects and decides to invoke the GA to confirm a ban?
>

By that time, if not already, GA will be majority of active bots or
majority of active controlled figures.

So in that hypothetical case, (I hope it does not happen), 0 transparency
and 0 innovations,
with questionable commits and contributors will remain in project, if not
already happening.

Its 2024 year, and FFmpeg still does not have proper subtitle support.
I could continue writing and adding more to the list, but I'm very generous
today.


> --
> 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] 5 year plan & Inovation

[Paul B Mahol]

On Fri, Apr 19, 2024 at 9:45 PM James Almer  wrote:

> On 4/19/2024 4:05 PM, Paul B Mahol wrote:
> > On Fri, Apr 19, 2024 at 8:06 PM Vittorio Giovara <
> vittorio.giov...@gmail.com>
> > wrote:
> >
> >> On Fri, Apr 19, 2024 at 11:00 AM Diederick C. Niehorster <
> >> dcni...@gmail.com>
> >> wrote:
> >>
> >>> If i recall correctly, there was a conversation not too long ago about
> >> what
> >>> to do with all the SPI money. This seems to be a perfect use for it.
> >>> 1. Set up and manage a gitlab instance
> >>> 2. Move tickets from trac to there (possibly)
> >>> 3. Move fate running to there
> >>>
> >>
> >> +1
> >>
> >> Another good idea would be to show negative influences the door, and not
> >> being afraid to ban them when needed.
> >> Currently the CC is supposed to decide that but idk how many and which
> >> people have access to the mailing list control panel.
> >>
> >
> > Welcome to the New LibAV Order!
>
> Paul, please, can you stop with this?
>

I stand for Truth And Justice.

You all stand for Force And Power.


> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] 5 year plan & Inovation

[Paul B Mahol]

On Fri, Apr 19, 2024 at 8:06 PM Vittorio Giovara 
wrote:

> On Fri, Apr 19, 2024 at 11:00 AM Diederick C. Niehorster <
> dcni...@gmail.com>
> wrote:
>
> > If i recall correctly, there was a conversation not too long ago about
> what
> > to do with all the SPI money. This seems to be a perfect use for it.
> > 1. Set up and manage a gitlab instance
> > 2. Move tickets from trac to there (possibly)
> > 3. Move fate running to there
> >
>
> +1
>
> Another good idea would be to show negative influences the door, and not
> being afraid to ban them when needed.
> Currently the CC is supposed to decide that but idk how many and which
> people have access to the mailing list control panel.
>

Welcome to the New LibAV Order!

-- 
> 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] 5 year plan & Inovation

[Paul B Mahol]

On Fri, Apr 19, 2024 at 1:19 AM Michael Niedermayer 
wrote:

> On Thu, Apr 18, 2024 at 06:13:40PM -0300, James Almer wrote:
> > On 4/18/2024 5:53 PM, Michael Niedermayer wrote:
> > > On Thu, Apr 18, 2024 at 04:02:07PM +0200, Niklas Haas wrote:
> > > > On Wed, 17 Apr 2024 15:58:32 +0200 Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
> > > > > Hi all
> > > > >
> > > > > The pace of inovation in FFmpeg has been slowing down.
> > > > > Most work is concentarted nowadays on code refactoring, and adding
> > > > > support for new codecs and formats.
> > > > >
> > > > > Should we
> > > > > * make a list of longer term goals
> > > > > * vote on them
> > > > > * and then together work towards implementing them
> > > > > ?
> > > > >
> > > > > (The idea here is to increase the success of larger efforts
> > > > >   than adding codecs and refactoring code)
> > > > > It would then also not be possible for individuals to object
> > > > > to a previously agreed goal.
> > > > > And it would add ideas for which we can try to get funding/grants
> for
> > > > >
> > > > > (larger scale changes need consensus first that we as a whole want
> > > > >   them before we would be able to ask for funding/grants for them)
> > > > >
> > > > > Some ideas and why they would help FFmpeg:
> > > > >
> > > > > * Switch to a plugin architecture
> > > > >  (Increase the number of developers willing to contribute and
> reduce
> > > > >   friction as the team and community grows)
> > > >
> > > > This would almost surely hurt productivity
> > >
> > > i dont agree, ill elaborae below
> > >
> > >
> > > > as it will require exposing,
> > > > versioning, documenting and maintaining a vast number of internal
> APIs
> > >
> > > yes to some extend that is needed. It can be more or less depending
> > > on how things are implemented
> > >
> > >
> > > > which we are currently at the liberty of modifying freely.
> > >
> > > we are modifying these APIs for decades. That modification of APIs
> > > their documentation and all code using them costs time.
> >
> > The AVCodec hooks being internal allowed us to add autoinserted bsfs and
> to
> > painlessly rewrite the decouple I/O callbacks to work as a pure pull
> based
> > interface. Were said internals public, that wouldn't have been possible.
>
> A decoder API needs packet in, frame out.
> AVPacket and AVFrame are public.
> (and a bunch of key-value data like width / height / timebase /
> pixelformat / aspect / ...
>  teh struct for that is also public since a long time)
> I dont see the problem.
>
> you have the decoder API facing the user, that causes no problems,
> i dont agree that having a decoder API (or encoder, muxer, demuxer, ...)
> facing a plugin would be a bigger problem than the APIs we already have
> public
> sure there are details, sure there are things that need one to think about
> and sleep over and all that but these are from a high level point of
> view simple and also the same interfaces to what we already have public
>
>
> >
> > >
> > > More so we have issues with patch-management. And i claim this is
> > > not the mailing list but a lack of time and in some cases a lack of
> > > interrest in many areas.
> > >
> > > A plugin system moves this patch-management to people who actually
> > > care, that is the authors of the codecs and (de)muxers.
> > >
> > > Our productivity as is, is not good, many patches are ignored.
> >
> > A lot of patches fall through the cracks rather than being ignored.
> > There are people that send patchsets unthreaded (Because of misconfigured
> > git send-email i suppose), and it makes browsing your mailbox hard.
>
> well i can say that i dont review many patches anymore because i just dont
> have
> the time, its not that i cant keep track of what i wanted to review.
>
> either i make a note in a TODO list or i keep the patch marked as NEW
> in my mail user agent.
>
> trac in some sense or patchwork are just more public TODO lists
> that can be shared between people so if one doesnt do it another
> developer sees it and can do it.
>
>
> >
> > > The people caring about these patches are their Authors and yet they
> > > are powerless as they must sometimes wait many months for reviews
> > > Besides that, developers are leaving for various reasons and they
> > > are forced to setup full forks not being able to maintain their
> > > code in any other way.
> > > IMO A plugin system would improve productivity as everyone could work
> > > on their own terms.
> >
> > You say the ML is not the problem, but it sort of is. An MR based
> > development would greatly improve this problem.
>
> People historically where very opposed to merge requests
>
> But, having a public git repo (that people already have)
> asking for it to be merged. You get a merge commit and someone will
> probably
> feel offended by that. (thats not what you meant i guess)
> but i would 100% support doing git merge requests.
> (there are good arguments from people much smarter than me why
> 

Re: [FFmpeg-devel] resignation from CC

[Paul B Mahol]

On Sat, Apr 13, 2024 at 12:29 PM Steven Liu  wrote:

> Anton Khirnov  于2024年4月13日周六 17:58写道：
> >
> > Hi all,
> > I am hereby resigning from my position as a CC member, since I do not
> > want to be associated with the CC's utter lack of initiative and
> > meaningful action.
> What's happened? Perhaps have some misunderstand with some body or some
> things?
>
>
Also some more prominent figures just left ffmpeg-devel IRC channel.
Some very serious internal fights, nothing like external-public troll-fest.


>
> Thanks
> Steven
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] 5 year plan & Inovation

[Paul B Mahol]

On Thu, Apr 18, 2024 at 4:22 AM Aidan  wrote:

> The best option is to figure stuff out.
>
> I don't see positive stuff in this mailing list - I lurk a lot in these
> emails.
>
> I see what you mean. I somewhat disagree/agree. New codecs or new formats
> is innovative to a certain extent.
>
> There is no creativity or motivation here to improve the functionality of
> FFmpeg. Just arguing!
>

And potentially taking your money.


> Having a Native VVC decoder is great. Most of us will be using it after a
> few years once the codec becomes used.
>
> I use FFmpeg to download HLS streams from the internet or convert files
> like probably most people do. FFmpeg is the ultimate way of doing this
> because there is no better option.
>
> But there are issues:
> 1. "#ext-x-discontinuity" exists. Makes FFmpeg completely unable to
> function with HLS depending on the circumstance.
> 2. TTML is used a lot on the internet as subtitles. FFmpeg doesn't have a
> decoder at all. TTML is rarely supported other than browsers. There is no
> way to convert and preserve formatting.
> 3. There is no encoder for cea-608 subtitles. Tons of services support
> decoding but there's no way to encode it.
> 4. Services selling HLS encoder services. FFmpeg can generate an HLS
> playlist. However, it's an important part: the web server.
>
> I submitted a patch for a TTML decoder because I thought it would be great.
> It was completely ignored.
> If my patch was seriously bad, then fine. But seriously *no one cared*.
>
> Y'all can disagree with me. You are slowly digging a pit.
>
> Kind regards,
> Aidan / TheDaChicken
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] FFmpeg table at NAB

[Paul B Mahol]

On Wed, Apr 17, 2024 at 1:21 AM Devin Heitmueller <
devin.heitmuel...@ltnglobal.com> wrote:

> Hello all,
>
> I wasn't looking to start trouble, but I didn't see any discussion of
> this on the mailing list so wanted to bring it to the developer
> community's attention.
>
> I attended the NAB conference and went by the "ffmpeg" booth on
> Sunday.  What I found was a single table with the official ffmpeg
> banner hanging right next to a banner for the GPAC project, and two
> salespeople from GPAC handing out marketing literature and trying to
> educate me on why I should use their framework for my next project.
>
> I'm not saying that GPAC shouldn't be able to have a table at the
> conference, but it feels pretty misleading to have an "ffmpeg" booth
> listed in the conference materials, with a table prominently
> displaying the ffmpeg logo, with zero people from ffmpeg and people
> pushing users to use an alternative framework that some might actually
> considered to be a competitor to ffmpeg.
>
>
Agreed, forget about FFmpeg.

Use Librempeg.


> Devin
>
> --
> Devin Heitmueller, Senior Software Engineer
> LTN Global Communications
> o: +1 (301) 363-1001
> w: https://ltnglobal.com  e: devin.heitmuel...@ltnglobal.com
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavf/matroskaenc: sort options by name

[Paul B Mahol]

On Wed, Apr 10, 2024 at 11:08 AM Stefano Sabatini 
wrote:

> On date Sunday 2024-04-07 16:01:27 +0800, Zhao Zhili wrote:
> >
> > > On Apr 7, 2024, at 14:16, Anton Khirnov  wrote:
> > >
> > > Quoting Andreas Rheinhardt (2024-04-06 13:25:49)
> > >> See
> https://ffmpeg.org/pipermail/ffmpeg-devel/2024-February/320849.html
> > >> Additionally I do not agree that sorting options by name is the best
> > >> way; it should be sorted by what are (believed to be) the most
> commonly
> > >> used options.
> > >
> > > +1
> >
> >
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240106165246.274472-1-stefa...@gmail.com/
> >
> > I have the same consideration in another patch. Maybe group related
> > options together than sort whole options.
>
> This hardly works for the aforementioned reasons, no objective
> criteria means that there will be never a consistent way to sort the
> options. What happens in practice is that options are added more or
> less randomly, which doesn't help readability and discoverability
> especially when there are many options.
>

We have TC now. Oh yes, I completely forgot what is TC.


> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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 v2 16/17] fftools/ffmpeg_filter: propagate codec yuv metadata to filters

[Paul B Mahol]

On Wed, Apr 10, 2024 at 3:12 PM Nicolas George  wrote:

> Niklas Haas (12024-04-10):
> > I think a greedy algorithm (not requiring juggling multiple random
> > passes) can still work,
>
> It does not work for audio. Have you studied what works for audio? It is
> quite subtle and full of pitfalls.
>

This is ultra-vague. And needs further explanations.


>
> Regards,
>
> --
>   Nicolas George
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Query from Reuters on XZ, open source, and Microsoft

[Paul B Mahol]

On Thu, Apr 11, 2024 at 5:59 AM Vittorio Giovara 
wrote:

> On Wed, Apr 10, 2024 at 9:19 PM Michael Niedermayer <
> mich...@niedermayer.cc>
> wrote:
>
> > Hi
> >
> > On Tue, Apr 09, 2024 at 03:57:02PM -0500, Romain Beauxis wrote:
> > > [Apologies for continuing the conversation, Rémi]
> > >
> > > Le mar. 9 avr. 2024 à 14:05, Tomas Härdin  a écrit :
> > >
> > > > mån 2024-04-08 klockan 13:13 -0500 skrev Romain Beauxis:
> > [...]
> > >
> > > > Also as someone who had to maintain a Gitlab instance at uni for a
> > > > couple of years, I agree with Rémi's points
> > > >
> > >
> > > My initial contribution was motivated by the argument presented in the
> > > original talk that bringing new blood is critical to the survival of
> the
> > > project.
> > >
> > > If so, then I do believe that there must be a compromise to be made
> > between
> > > being easier to join for new developers and changing the existing
> > workflow.
> > > I'm also aware that changing the existing workflow has been discussed
> > > before.
> > >
> > > I don't think that media is not cool anymore, as argued in the talk. I
> > see
> > > a _lot_ of interested developers in my other projects and all over the
> > open
> > > source landscape. That's why I believe that it's also important to
> > consider
> > > other reasons than the talk's argument.
> >
> > To bring some of the new blood into the project the project needs to
> > first understand why they dont. And asking thouse who manage with
> > difficulty
> > to join could be a biased oppinion.
> >
>
> In my experience this boils down to three points
> 1. there is a legit barrier of entry in a large codebase such as ffmpeg,
> but over time newcomers can learn about it
>

Yes, external and internal API is complicated mess in all libs,
Most libs code is out of date with current State of Art found in other
projects.
Also contributors came and go, you can not force them to stay and maintain
code mess.


> 2. the review process can be though and it's easy to miss a ping and
> patches get lost, very defeating for a new developer
>

Specially when single patch get lost in twenty trivial refactoring patches
that spam the list.
There should be at least separate list for refactoring patches, and keep
this list only for important stuff like new features and bug fixes, if no
switch to Github/Gitlab is wanted.


> 3. there is net negative help from trolls who spread toxic poison, which is
> confusing and uninteresting for the new blood
>

That is internal community reaction to 1. and 2. points. Think it about
like auto-immune reaction to state of human body.


>
> 2 out of 3 can be solved technically, while the last one needs a cultural
> shift - overall I think we're doing a good job at slowly changing pace and
> having a bit of a better structure to solve situations when they arise, but
> there is still a lot of work to do
>

Cultural shift - Cancel culture.

The only point I agree about above is very last part of very last sentence.


> --
> 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] bsf: use standard include paths

[Paul B Mahol]

And the New Dictator have Risen!

On Wed, Apr 10, 2024 at 4:12 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> Andrew Kelley:
> > Removes the special -I flag specified in the avcodec/bsf/ subdirectory.
> >
> > This makes code copy-pastable to other parts of the ffmpeg codebase, as
> > well as simplifying the build script.
>
> If you want to make the code copy-pastable to other parts, you need to
> disallow using the ordinary relative-path header inclusion. And I don't
> see a simplification of the Makefile.
>
> >
> > It also reduces ambiguity, since there are many instances of same-named
> > header files existing in both libavformat/ and libavcodec/
> > subdirectories.
>
> What ambiguity? As said above, said ambiguity emanates from using
> inclusions with relative paths (and from using the same header
> filenames) and not adding an -I for the parent folder for the files in a
> subfolder. (It would be different if we did something nuts like adding
> -Ilibavcodec to the compilation of libavformat files).
>
> - Andreas
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Query from Reuters on XZ, open source, and Microsoft

[Paul B Mahol]

On Tue, Apr 9, 2024 at 10:57 PM Romain Beauxis 
wrote:

> [Apologies for continuing the conversation, Rémi]
>
> Le mar. 9 avr. 2024 à 14:05, Tomas Härdin  a écrit :
>
> > mån 2024-04-08 klockan 13:13 -0500 skrev Romain Beauxis:
> > > On Wed, Apr 3, 2024, 11:39 Kieran Kunhya via ffmpeg-devel <
> > > ffmpeg-devel@ffmpeg.org> wrote:
> > >
> > > > Hi Raphael,
> > > >
> > > > I was the author of the tweet and I gave a short talk about this
> > > > topic at
> > > > Demuxed at a video conference last year:
> > > > https://m.youtube.com/watch?v=OIyOEuQQsCQ=930s
> > > >
> > > > That said this is a community project and it would be best to
> > > > continue the
> > > > discussion on this mailing list unless agreed otherwise.
> > > >
> > >
> > > Thank you for sharing your talk. It's indeed unfortunate that large
> > > companies are not more generous with the projects they depend on
> > > _heavily_
> > >
> > > I would like to offer a constructive feedback really not intended as
> > > trolling. I believe that supporting a more modern development
> > > workflow such
> > > as the GitHub PR or gitlab MR would go very long way in helping
> > > onboarding
> > > new developers.
> >
> > Considering which company owns GitHub and which company was the target
> > of Kieran's criticism, this seems ill-adviced
> >
>
> Would you mind explaining what you mean exactly? I want to respond but I'm
> not sure if I fully understand your point here.
>
>
Kieran's criticism is trolling, as Kieran and rest of FFmpeg devs use
regularly and passionately Various Big Corpo products all the time.

Kieran's criticism is unfounded one. As I, originally 'volunteered' in that
now 'famous' ticket about Certain Big Corpo bug report and kindly replied
in friendly manner to bug reporter and give reporter free support, me still
see no issues in that mine action.

I strictly do make difference between collective and single specific person.


>
> > Also as someone who had to maintain a Gitlab instance at uni for a
> > couple of years, I agree with Rémi's points
> >
>
> My initial contribution was motivated by the argument presented in the
> original talk that bringing new blood is critical to the survival of the
> project.
>

Projects go and die, and new ones rise up, all the time.


>
> If so, then I do believe that there must be a compromise to be made between
> being easier to join for new developers and changing the existing workflow.
> I'm also aware that changing the existing workflow has been discussed
> before.
>
> I don't think that media is not cool anymore, as argued in the talk. I see
> a _lot_ of interested developers in my other projects and all over the open
> source landscape. That's why I believe that it's also important to consider
> other reasons than the talk's argument.
>
> Being someone actually trying to contribute, with years of developers
> experience and involvement in other communities, I was thinking that I may
> be able to bring in more new context to the topic.
>
> If there's interest in continuing the discussion, could you or Rémi be
> willing to explain what kind of burden gitlab would add?
>

Infrastructure maintenance, no volunteers for gitlab repo admin.
Extra steps to setup account and X-factor authentication.


>
> Also, Rémi said this would make it harder to join the project, in which way
> exactly?
>
> Otherwise, I'm happy to let this die and return to trying to get my patch
> committed.. 
>
> Thanks,
> -- Romain
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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/mpegvideo_enc: Fix 1 line and one column images

[Paul B Mahol]

On Mon, Apr 8, 2024 at 6:49 PM Michael Niedermayer 
wrote:

> Fixes: Ticket10952
> Fixes: poc21ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/mpegvideo_enc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
> index d1b19178247..40844b2f682 100644
> --- a/libavcodec/mpegvideo_enc.c
> +++ b/libavcodec/mpegvideo_enc.c
> @@ -1199,8 +1199,8 @@ static int load_input_picture(MpegEncContext *s,
> const AVFrame *pic_arg)
>  ptrdiff_t dst_stride = i ? s->uvlinesize : s->linesize;
>  int h_shift = i ? s->chroma_x_shift : 0;
>  int v_shift = i ? s->chroma_y_shift : 0;
> -int w = s->width  >> h_shift;
> -int h = s->height >> v_shift;
> +int w = -((-s->width)  >> h_shift);
> +int h = -((-s->height) >> v_shift);
>  const uint8_t *src = pic_arg->data[i];
>  uint8_t *dst = pic->f->data[i];
>  int vpad = 16;
>

What that does? Its not same as aligned rshift macro?


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

Re: [FFmpeg-devel] [EXT] Re: Query from Reuters on XZ, open source, and Microsoft

[Paul B Mahol]

On Mon, Apr 8, 2024 at 4:41 PM Nicolas George  wrote:

> Tomas Härdin (12024-04-08):
> > We could always start licensing the project under a less permissive
> > license like the GPL or the AGPL and then charge for exceptions. This
> > tactic goes by the name of license trolling, and was successfully used
> > by FFmbc for a while.
>
> Why do you say that when you know perfectly well than some of the
> developers holding copyright on the core code of the project will never
> let you do it and the project currently does not have the talent to
> rewrite everything?
>
> > We also don't need to support every use case.
>
> This, sadly, your ilk has the power to enforce. I am ancient enough in
> the project to remember the time where supporting every use case was
> almost an official motto, and lucid enough to realise that it was the
> main reason for the success of the project.
>

And the demise of LibAV, history repeats over and over again.


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

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

Re: [FFmpeg-devel] FFmpeg TC input needed

[Paul B Mahol]

How dare you to question LibAV overlords decisions here!

On Mon, Apr 8, 2024 at 3:12 PM Gyan Doshi  wrote:

> Ping x2.
>
> On 2024-04-02 10:55 am, Gyan Doshi wrote:
> > Ping.
> >
> > As the TC rules matter has been concluded, this should go ahead.
> >
> > Regards,
> > Gyan
> >
> >
> > On 2024-02-17 05:15 pm, Gyan Doshi wrote:
> >> Issue:
> >>
> >> Patch: avcodec/s302m: enable non-PCM decoding
> >> URL:
> >>
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240127103854.9971-1-ffm...@gyani.pro/
> >>
> >> The issue needing resolution is whether the patch should be added to
> >> the existing s302m decoder or should that decoder
> >> be removed and all old and new patched features inlined into the
> >> mpeg-ts demuxer.
> >>
> >> Summary:
> >>
> >> SMPTE ST 302 specifies for carriage of LPCM media in MPEG-TS. SMPTE
> >> ST 337 enables this for non-PCM codecs. The payload
> >> has a custom layout so it can't be directly processed hence
> >> lavc/s302m decodes the packet data to yield LPCM media. But
> >> it can only deal at present with LPCM payloads, meaning that non-PCM
> >> payloads need to be exported to a raw bytestream
> >> format and then decoded in a 2nd step, which prohibits direct
> >> transcoding of live/streaming inputs. This patch corrects
> >> the identification process for non-PCM payloads, reformats the
> >> payload and then carries out in-place decoding by calling
> >> a nested decoder similar to the ftr or imm5 decoders in lavc.
> >>
> >> In the v1 patch review, Andreas, in response to the proposed doc
> >> entry describing the feature capability of multiple
> >> or differing payloads in a s302m stream, suggested[1] that s302m
> >> should be a bitstream filter instead, but I did not
> >> see that as an actionable suggestion as he immediately listed the bsf
> >> limitations preventing the possibility. I also
> >> had not seen an actual sample of s302m with multiple embedded
> >> streams. Kieran also observed[2] that he had not seen
> >> such a stream in the wild. So the added features of this patch,
> >> wherever they are ultimately located, shall not yield
> >> more than one media stream. Anton suggested[3] that the decoder
> >> should instead be a demuxer. I saw no other objections
> >> to the architecture of the patch.
> >>
> >> I posted the v2 patch, incorporating some changes suggested by
> >> Andreas, 4 days later. This had gone uncommented for
> >> over two weeks when I posted a notice stating an intention to push.
> >> Anton posted[4] a new objection that "If it
> >> dynamically generates nested decoders, then it's not a proper codec
> >> in our model". This new objection is not connected
> >> to multiple streams but only to a codec 'model' that I don't see
> >> described anywhere and which contradicts the
> >> implementations of multiple decoders with a nested decoder, including
> >> the ftr and imm5 decoders, which are most similar
> >> in design to the patched s302m decoder. Anton later on mentioned[5]
> >> that nested decoders are "a constant source of
> >> issues". However, I didn't find anything on trac reporting an issue
> >> with the nested decoders of ftr and imm5 nor
> >> anything on ffmpeg-devel-ml or ffmpeg-user-ml. Nothing in their
> >> commit history either points to architectural bugs.
> >> These decoders have been around for 6 years among themselves. The
> >> testing of the patched s302m decoder over the past
> >> month by myself, an OTT provider and others shows no issues either.
> >> Finally, Anton speculates[6] that the burden of
> >> fixes will likely fall upon him. In none of his objections, till the
> >> time of writing, did I see specific concerns with
> >> the patch.
> >>
> >> There are some limitations in shifting this decoder wholesale to
> >> inside the MPEG-TS demuxer. A s302m stream may contain
> >> some non-media payload accompanying non-PCM media i.e. S-ADM
> >> metadata. At present, I have neither the samples nor the
> >> specification needed in order to locate and extract or parse this
> >> metadata. Formatting the payload data inside the
> >> demuxer will lead to irrevocable loss of such metadata if present.
> >> However, a decoder patch allows simultaneuous output
> >> of both a decoded stream alongside a copied stream. The end-user can
> >> then do with the raw data whatever they wish.
> >>
> >> Ultimately, s302m is specified an an elementary stream inside a
> >> MPEG-TS container. Its internal handling is better left
> >> to a dedicated module like a decoder. A bitstream filter might be a
> >> better fit if s302m streams with multiple media
> >> payloads ever start appearing - none have, so far - but for single
> >> media payloads, a decoder remains the best place.
> >>
> >> Regards,
> >> Gyan
> >>
> >> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/320119.html
> >> [2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/320321.html
> >> [3]: https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/320258.html
> >> [4]:
> 

Re: [FFmpeg-devel] 7.0 Name

[Paul B Mahol]

LibAV yet again!

On Fri, Apr 5, 2024 at 12:25 AM Michael Niedermayer 
wrote:

> On Mon, Apr 01, 2024 at 10:00:47PM +0200, Michael Niedermayer wrote:
> > Hi all
> >
> > I think we didnt decide on a name for 7.0 yet
> >
> > Previously suggested names:
> > Darwin,
> > De broglie,
> > Dijkstra,
> > Galois,
> > Gauss,
> > Jacobi,
> > Jemison
> > Johnson
> > Leavitt
> > Maxwell,
> > Mellin,
> > Perelman,
> > Poincaré,
> > Ramanujan,
> > Sagan,
> > Ting
> > Viterbi,
> > Voltaire,
> > de Sitter,
> >
> > Please reply with what you prefer or add more to the list.
> > If we end in a tie, previously suggested names will be favoured
> > I will vote last so that i can resolve a tie if one occurs.
>
> I think the outcome is quite clear
>
> Dijkstra got 7 votes, every other name had only 1
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Take away the freedom of one citizen and you will be jailed, take away
> the freedom of all citizens and you will be congratulated by your peers
> in Parliament.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] 7.0 Name

[Paul B Mahol]

On Mon, Apr 1, 2024 at 10:01 PM Michael Niedermayer 
wrote:

> Hi all
>
> I think we didnt decide on a name for 7.0 yet
>
> Previously suggested names:
> Darwin,
> De broglie,
> Dijkstra,
> Galois,
> Gauss,
> Jacobi,
> Jemison
> Johnson
> Leavitt
> Maxwell,
> Mellin,
> Perelman,
> Poincaré,
> Ramanujan,
> Sagan,
> Ting
> Viterbi,
> Voltaire,
> de Sitter,
>
> Please reply with what you prefer or add more to the list.
> If we end in a tie, previously suggested names will be favoured
> I will vote last so that i can resolve a tie if one occurs.
>

Anton


>
> thx
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> No snowflake in an avalanche ever feels responsible. -- Voltaire
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] clarifying the TC conflict of interest rule

[Paul B Mahol]

On Mon, Apr 1, 2024 at 4:59 PM Michael Niedermayer 
wrote:

> On Mon, Apr 01, 2024 at 01:16:48PM +0200, Anton Khirnov wrote:
> > Hi all,
> >
> > the vote has now ended with 23 votes cast, results are available at
> > https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_a6be1eb156d0e589
> >
> > The winning option is 'Anton', i.e. my proposal. Voting data as reported
> > by CIVS is attached to this email for future reference.
>
> Congratulations! :)
>
>
Next time prepare more voting bots than opponent, than you will surely win
again.


> thx
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I have often repented speaking, but never of holding my tongue.
> -- Xenocrates
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] clarifying the TC conflict of interest rule

[Paul B Mahol]

On Mon, Apr 1, 2024 at 1:17 PM Anton Khirnov  wrote:

> Hi all,
>
> the vote has now ended with 23 votes cast, results are available at
> https://vote.ffmpeg.org/cgi-bin/civs/results.pl?id=E_a6be1eb156d0e589
>
> The winning option is 'Anton', i.e. my proposal. Voting data as reported
> by CIVS is attached to this email for future reference.
>

As expected...


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

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/lc3: Add file format for LC3/LC3plus transport

[Paul B Mahol]

On Sat, Mar 30, 2024 at 10:51 PM Antoine Soulier 
wrote:

> I am not sure about the block:
>
>> +lc3->timestamp += lc3->dt;
>> +if (lc3->timestamp > lc3->length) {
>> +pkt->duration -= lc3->timestamp - lc3->length;
>> +lc3->timestamp = lc3->length;
>> +}
>
>
> The purpose is to reduce the duration of the last packet.
> When converting a file, the last frame can contain "zeros" (or irrelevant)
> samples that are not present in the source file (alignment to frame
> boundary). These samples should be discarded.
> > If I remove the "read_seek()" implementation, I lose the PTS / timestamp
> information, and I don't know how to detect the last frame in the stream.
> Do you know how I can handle a reduced duration for the last frame without
> having an implementation of "read_seek()"?
>
> (I can play with the position and EOF information, but can lead to strange
> behaviors if the encoder adds extra frames at the end).
>

Looks like format limitation. If duration is not stored in each packet than
demuxer can not do it and no spagetti code can fix it in demuxer. Still
output frame duration is set by decoder too when decoding, so make sure
that decoder outputs valid output and timestamps/durations.
So its not really possible to have also correct and robust duration of last
packet returned by demuxer. Even more the file may be manipulated in such
way that its no longer correct to derive last packet duration from full
duration stored in header when the EOF reached.


>
>
> On Sat, Mar 30, 2024 at 4:46 AM Paul B Mahol  wrote:
>
>>
>>
>> On Fri, Mar 29, 2024 at 6:30 PM Antoine Soulier via ffmpeg-devel <
>> ffmpeg-devel@ffmpeg.org> wrote:
>>
>>> A file format is described in Bluetooth SIG LC3 and ETSI TS 103 634, for
>>> test purpose. This is the format implemented here.
>>>
>>> Signed-off-by: Antoine Soulier 
>>> ---
>>>  Changelog|   1 +
>>>  doc/muxers.texi  |   6 ++
>>>  libavformat/Makefile |   2 +
>>>  libavformat/allformats.c |   2 +
>>>  libavformat/lc3dec.c | 164 +++
>>>  libavformat/lc3enc.c | 100 
>>>  6 files changed, 275 insertions(+)
>>>  create mode 100644 libavformat/lc3dec.c
>>>  create mode 100644 libavformat/lc3enc.c
>>>
>>> diff --git a/Changelog b/Changelog
>>> index 83a4cf7888..08c200a41d 100644
>>> --- a/Changelog
>>> +++ b/Changelog
>>> @@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to
>>> youngest within each release,
>>>  releases are sorted from youngest to oldest.
>>>
>>>  version :
>>> +- LC3/LC3plus demuxer and muxer
>>>  - LC3/LC3plus decoding/encoding using external library liblc3
>>>
>>>
>>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>>> index a10a8e216f..9687746c30 100644
>>> --- a/doc/muxers.texi
>>> +++ b/doc/muxers.texi
>>> @@ -2612,6 +2612,12 @@ WebDAV server every second:
>>>  ffmpeg -f x11grab -framerate 1 -i :0.0 -q:v 6 -update 1 -protocol_opts
>>> method=PUT http://example.com/desktop.jpg
>>>  @end example
>>>
>>> +@section lc3
>>> +Bluetooth SIG Low Complexity Communication Codec audio (LC3), or
>>> +ETSI TS 103 634 Low Complexity Communication Codec plus (LC3plus).
>>> +
>>> +This muxer accepts a single @code{lc3} audio stream.
>>> +
>>>  @section matroska
>>>
>>>  Matroska container muxer.
>>> diff --git a/libavformat/Makefile b/libavformat/Makefile
>>> index 44aa485029..4961c42852 100644
>>> --- a/libavformat/Makefile
>>> +++ b/libavformat/Makefile
>>> @@ -332,6 +332,8 @@ OBJS-$(CONFIG_KVAG_DEMUXER)  += kvag.o
>>>  OBJS-$(CONFIG_KVAG_MUXER)+= kvag.o rawenc.o
>>>  OBJS-$(CONFIG_LAF_DEMUXER)   += lafdec.o
>>>  OBJS-$(CONFIG_LATM_MUXER)+= latmenc.o rawenc.o
>>> +OBJS-$(CONFIG_LC3_DEMUXER)   += lc3dec.o
>>> +OBJS-$(CONFIG_LC3_MUXER) += lc3enc.o
>>>  OBJS-$(CONFIG_LMLM4_DEMUXER) += lmlm4.o
>>>  OBJS-$(CONFIG_LOAS_DEMUXER)  += loasdec.o rawdec.o
>>>  OBJS-$(CONFIG_LUODAT_DEMUXER)+= luodatdec.o
>>> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
>>> index 9df42bb87a..0b36a7c3eb 100644
>>> --- a/libavformat/allformats.c
>>> +++ b/libavformat/allformats.c
>

Re: [FFmpeg-devel] [PATCH 2/2] avformat/lc3: Add file format for LC3/LC3plus transport

[Paul B Mahol]

On Fri, Mar 29, 2024 at 6:30 PM Antoine Soulier via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:

> A file format is described in Bluetooth SIG LC3 and ETSI TS 103 634, for
> test purpose. This is the format implemented here.
>
> Signed-off-by: Antoine Soulier 
> ---
>  Changelog|   1 +
>  doc/muxers.texi  |   6 ++
>  libavformat/Makefile |   2 +
>  libavformat/allformats.c |   2 +
>  libavformat/lc3dec.c | 164 +++
>  libavformat/lc3enc.c | 100 
>  6 files changed, 275 insertions(+)
>  create mode 100644 libavformat/lc3dec.c
>  create mode 100644 libavformat/lc3enc.c
>
> diff --git a/Changelog b/Changelog
> index 83a4cf7888..08c200a41d 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest
> within each release,
>  releases are sorted from youngest to oldest.
>
>  version :
> +- LC3/LC3plus demuxer and muxer
>  - LC3/LC3plus decoding/encoding using external library liblc3
>
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index a10a8e216f..9687746c30 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -2612,6 +2612,12 @@ WebDAV server every second:
>  ffmpeg -f x11grab -framerate 1 -i :0.0 -q:v 6 -update 1 -protocol_opts
> method=PUT http://example.com/desktop.jpg
>  @end example
>
> +@section lc3
> +Bluetooth SIG Low Complexity Communication Codec audio (LC3), or
> +ETSI TS 103 634 Low Complexity Communication Codec plus (LC3plus).
> +
> +This muxer accepts a single @code{lc3} audio stream.
> +
>  @section matroska
>
>  Matroska container muxer.
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 44aa485029..4961c42852 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -332,6 +332,8 @@ OBJS-$(CONFIG_KVAG_DEMUXER)  += kvag.o
>  OBJS-$(CONFIG_KVAG_MUXER)+= kvag.o rawenc.o
>  OBJS-$(CONFIG_LAF_DEMUXER)   += lafdec.o
>  OBJS-$(CONFIG_LATM_MUXER)+= latmenc.o rawenc.o
> +OBJS-$(CONFIG_LC3_DEMUXER)   += lc3dec.o
> +OBJS-$(CONFIG_LC3_MUXER) += lc3enc.o
>  OBJS-$(CONFIG_LMLM4_DEMUXER) += lmlm4.o
>  OBJS-$(CONFIG_LOAS_DEMUXER)  += loasdec.o rawdec.o
>  OBJS-$(CONFIG_LUODAT_DEMUXER)+= luodatdec.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 9df42bb87a..0b36a7c3eb 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -252,6 +252,8 @@ extern const FFInputFormat  ff_kvag_demuxer;
>  extern const FFOutputFormat ff_kvag_muxer;
>  extern const FFInputFormat  ff_laf_demuxer;
>  extern const FFOutputFormat ff_latm_muxer;
> +extern const FFInputFormat  ff_lc3_demuxer;
> +extern const FFOutputFormat ff_lc3_muxer;
>  extern const FFInputFormat  ff_lmlm4_demuxer;
>  extern const FFInputFormat  ff_loas_demuxer;
>  extern const FFInputFormat  ff_luodat_demuxer;
> diff --git a/libavformat/lc3dec.c b/libavformat/lc3dec.c
> new file mode 100644
> index 00..74d6794d00
> --- /dev/null
> +++ b/libavformat/lc3dec.c
> @@ -0,0 +1,164 @@
> +/*
> + * LC3 demuxer
> + * Copyright (C) 2024  Antoine Soulier 
> + *
> + * 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
> + * Based on the file format specified by :
> + *
> + * - Bluetooth SIG - Low Complexity Communication Codec Test Suite
> + *
> https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=502301
> + *   3.2.8.2 Reference LC3 Codec Bitstream Format
> + *
> + * - ETSI TI 103 634 V1.4.1 - Low Complexity Communication Codec plus
> + *
> https://www.etsi.org/deliver/etsi_ts/103600_103699/103634/01.04.01_60/ts_103634v010401p.pdf
> + *   LC3plus conformance script package
> + */
> +
> +#include "libavcodec/packet.h"
> +#include "libavutil/intreadwrite.h"
> +
> +#include "avformat.h"
> +#include "avio.h"
> +#include "demux.h"
> +#include "internal.h"
> +
> +typedef struct LC3DemuxContext {
> +int dt, delay;
> +int64_t timestamp;
> +int64_t length;
> +} LC3DemuxContext;
> +
> +static int lc3_read_header(AVFormatContext *s)
> +{
> +LC3DemuxContext *lc3 = s->priv_data;
> +AVStream *st = NULL;
> +uint16_t tag, 

Re: [FFmpeg-devel] [PATCH 2/3] lavf/srtdec: Permit streaming input

[Paul B Mahol]

On Sat, Mar 30, 2024 at 9:31 AM Tomas Härdin  wrote:

> lör 2024-03-30 klockan 00:35 +0100 skrev Michael Niedermayer:
> > breaks fate here:
> >
> > --- ./tests/ref/fate/sub-srt-madness-timeshift  2024-03-29
> > 20:43:34.617419731 +0100
> > +++ tests/data/fate/sub-srt-madness-timeshift   2024-03-30
>
> Sorry but this file is utter crap and shouldn't be part of FATE. Look
> at this:
>
> > 53
> > 00:00:01,111 --> 00:00:02,222
> > okay, let's make things easy
> >
> > 21 lol jk
> > 00:00:03,333 --> 00:00:04,444
> > hello
> > 5
> >
> >
> > don't forget me.
> > 3
> >
> >
> > 00:00:05,555 --> 00:00:06,666
> >
> >
> > no.
> > let's add some fun
> > 44 yes we can
> > 00:00:07,777 --> 00:00:06,666
> > let's do it in reverse bc wtf not
> >
>
> This file is crafted to test srtdec as it is, rather than following
> what passes for an SRT spec (that doom9 forum post[1] and the videolan
> wiki[2]). We should remove it, or keep it as a sample that should fail
> parsing.
>
> More interesting is fate-sub-srt-badsyntax. Despite the name it doesn't
> really have bad syntax, but its cues are in a random order. I guess it
> exists to test the cue sorting logic. But should subtitle demuxers
> really sort subtitles in this way? We don't do that for other formats
> that can have non-decreasing timestamps. For comparison, the WebVTT
> spec explicitly disallows decreasing timestamps. I also wonder how this
> file was created. My guess is "via a text editor" since it seems to
> consist of bits from different SRT files. There's little reason to
> support such deliberately broken files, at least having a bunch of
> sorting logic just for it. There's no reason we couldn't output packets
> in stored order.
>
> The rest of the subtitle test cases pass.
>

I agree, current subtitles not being handled in streamed way is bad
practice.
If some subtitle have wrong order of items, than new generic subtitle
filter could be implemented
which would fix that by either using queue or seeking around in subtitle
stream.


>
> /Tomas
>
> [1] https://forum.doom9.org/showthread.php?p=470941#post470941
> [2] https://wiki.videolan.org/SubRip/
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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/lc3: Add file format for LC3/LC3plus transport

[Paul B Mahol]

On Thu, Mar 28, 2024 at 5:40 PM Antoine Soulier  wrote:

> I don't think it's "easy" seekable.
> We cannot move to an arbitrary position:
> - There is no start-code
>

Not relevant.


> - The frame size can be variable (not generated by the proposed encoder
> implementation, but allowed).
>

Not relevant.


>
> The only possibility I see is checking that the frame size looks valid for
> multiple frames.
>

Not relevant, the only needed feature is known stored number of samples in
each packet for proper pts/timestamp generation.

The range of valid frame sizes is large (20 to 625 Bytes), so I can only
> validate 6 bits for each 16 bits packet size read.
>
> This format is not really designed to be seekable.
> Do you think we will need it?
>

I cant force you do to correct implementation.

Seeking is possible, just you are not aware of actual solution.
Hint: see other demuxers.


>
>
> On Thu, Mar 28, 2024 at 2:33 AM Paul B Mahol  wrote:
>
>> This format actually supports seeking.
>>
>> The proposed solution here is sub-optimal.
>>
>> On Wed, Mar 27, 2024 at 11:22 PM Antoine Soulier via ffmpeg-devel <
>> ffmpeg-devel@ffmpeg.org> wrote:
>>
>>> A file format is described in Bluetooth SIG LC3 and ETSI TS 103 634, for
>>> test purpose. This is the format implemented here.
>>>
>>> Signed-off-by: Antoine Soulier 
>>> ---
>>>  doc/muxers.texi  |   6 ++
>>>  libavformat/Makefile |   2 +
>>>  libavformat/allformats.c |   2 +
>>>  libavformat/lc3dec.c | 135 +++
>>>  libavformat/lc3enc.c | 102 +
>>>  5 files changed, 247 insertions(+)
>>>  create mode 100644 libavformat/lc3dec.c
>>>  create mode 100644 libavformat/lc3enc.c
>>>
>>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>>> index a10a8e216f..9687746c30 100644
>>> --- a/doc/muxers.texi
>>> +++ b/doc/muxers.texi
>>> @@ -2612,6 +2612,12 @@ WebDAV server every second:
>>>  ffmpeg -f x11grab -framerate 1 -i :0.0 -q:v 6 -update 1 -protocol_opts
>>> method=PUT http://example.com/desktop.jpg
>>>  @end example
>>>
>>> +@section lc3
>>> +Bluetooth SIG Low Complexity Communication Codec audio (LC3), or
>>> +ETSI TS 103 634 Low Complexity Communication Codec plus (LC3plus).
>>> +
>>> +This muxer accepts a single @code{lc3} audio stream.
>>> +
>>>  @section matroska
>>>
>>>  Matroska container muxer.
>>> diff --git a/libavformat/Makefile b/libavformat/Makefile
>>> index 44aa485029..4961c42852 100644
>>> --- a/libavformat/Makefile
>>> +++ b/libavformat/Makefile
>>> @@ -332,6 +332,8 @@ OBJS-$(CONFIG_KVAG_DEMUXER)  += kvag.o
>>>  OBJS-$(CONFIG_KVAG_MUXER)+= kvag.o rawenc.o
>>>  OBJS-$(CONFIG_LAF_DEMUXER)   += lafdec.o
>>>  OBJS-$(CONFIG_LATM_MUXER)+= latmenc.o rawenc.o
>>> +OBJS-$(CONFIG_LC3_DEMUXER)   += lc3dec.o
>>> +OBJS-$(CONFIG_LC3_MUXER) += lc3enc.o
>>>  OBJS-$(CONFIG_LMLM4_DEMUXER) += lmlm4.o
>>>  OBJS-$(CONFIG_LOAS_DEMUXER)  += loasdec.o rawdec.o
>>>  OBJS-$(CONFIG_LUODAT_DEMUXER)+= luodatdec.o
>>> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
>>> index e15d0fa6d7..e225354faf 100644
>>> --- a/libavformat/allformats.c
>>> +++ b/libavformat/allformats.c
>>> @@ -252,6 +252,8 @@ extern const FFInputFormat  ff_kvag_demuxer;
>>>  extern const FFOutputFormat ff_kvag_muxer;
>>>  extern const FFInputFormat  ff_laf_demuxer;
>>>  extern const FFOutputFormat ff_latm_muxer;
>>> +extern const FFInputFormat  ff_lc3_demuxer;
>>> +extern const FFOutputFormat ff_lc3_muxer;
>>>  extern const FFInputFormat  ff_lmlm4_demuxer;
>>>  extern const FFInputFormat  ff_loas_demuxer;
>>>  extern const FFInputFormat  ff_luodat_demuxer;
>>> diff --git a/libavformat/lc3dec.c b/libavformat/lc3dec.c
>>> new file mode 100644
>>> index 00..9ca9825f1b
>>> --- /dev/null
>>> +++ b/libavformat/lc3dec.c
>>> @@ -0,0 +1,135 @@
>>> +/*
>>> + * LC3 demuxer
>>> + * Copyright (C) 2024  Antoine Soulier 
>>> + *
>>> + * 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 So

Re: [FFmpeg-devel] [PATCH 3/4] avformat/lc3: Add file format for LC3/LC3plus transport

[Paul B Mahol]

This format actually supports seeking.

The proposed solution here is sub-optimal.

On Wed, Mar 27, 2024 at 11:22 PM Antoine Soulier via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:

> A file format is described in Bluetooth SIG LC3 and ETSI TS 103 634, for
> test purpose. This is the format implemented here.
>
> Signed-off-by: Antoine Soulier 
> ---
>  doc/muxers.texi  |   6 ++
>  libavformat/Makefile |   2 +
>  libavformat/allformats.c |   2 +
>  libavformat/lc3dec.c | 135 +++
>  libavformat/lc3enc.c | 102 +
>  5 files changed, 247 insertions(+)
>  create mode 100644 libavformat/lc3dec.c
>  create mode 100644 libavformat/lc3enc.c
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index a10a8e216f..9687746c30 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -2612,6 +2612,12 @@ WebDAV server every second:
>  ffmpeg -f x11grab -framerate 1 -i :0.0 -q:v 6 -update 1 -protocol_opts
> method=PUT http://example.com/desktop.jpg
>  @end example
>
> +@section lc3
> +Bluetooth SIG Low Complexity Communication Codec audio (LC3), or
> +ETSI TS 103 634 Low Complexity Communication Codec plus (LC3plus).
> +
> +This muxer accepts a single @code{lc3} audio stream.
> +
>  @section matroska
>
>  Matroska container muxer.
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 44aa485029..4961c42852 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -332,6 +332,8 @@ OBJS-$(CONFIG_KVAG_DEMUXER)  += kvag.o
>  OBJS-$(CONFIG_KVAG_MUXER)+= kvag.o rawenc.o
>  OBJS-$(CONFIG_LAF_DEMUXER)   += lafdec.o
>  OBJS-$(CONFIG_LATM_MUXER)+= latmenc.o rawenc.o
> +OBJS-$(CONFIG_LC3_DEMUXER)   += lc3dec.o
> +OBJS-$(CONFIG_LC3_MUXER) += lc3enc.o
>  OBJS-$(CONFIG_LMLM4_DEMUXER) += lmlm4.o
>  OBJS-$(CONFIG_LOAS_DEMUXER)  += loasdec.o rawdec.o
>  OBJS-$(CONFIG_LUODAT_DEMUXER)+= luodatdec.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index e15d0fa6d7..e225354faf 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -252,6 +252,8 @@ extern const FFInputFormat  ff_kvag_demuxer;
>  extern const FFOutputFormat ff_kvag_muxer;
>  extern const FFInputFormat  ff_laf_demuxer;
>  extern const FFOutputFormat ff_latm_muxer;
> +extern const FFInputFormat  ff_lc3_demuxer;
> +extern const FFOutputFormat ff_lc3_muxer;
>  extern const FFInputFormat  ff_lmlm4_demuxer;
>  extern const FFInputFormat  ff_loas_demuxer;
>  extern const FFInputFormat  ff_luodat_demuxer;
> diff --git a/libavformat/lc3dec.c b/libavformat/lc3dec.c
> new file mode 100644
> index 00..9ca9825f1b
> --- /dev/null
> +++ b/libavformat/lc3dec.c
> @@ -0,0 +1,135 @@
> +/*
> + * LC3 demuxer
> + * Copyright (C) 2024  Antoine Soulier 
> + *
> + * 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
> + * Based on the file format specified by :
> + *
> + * - Bluetooth SIG - Low Complexity Communication Codec Test Suite
> + *
> https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=502301
> + *   3.2.8.2 Reference LC3 Codec Bitstream Format
> + *
> + * - ETSI TI 103 634 V1.4.1 - Low Complexity Communication Codec plus
> + *
> https://www.etsi.org/deliver/etsi_ts/103600_103699/103634/01.04.01_60/ts_103634v010401p.pdf
> + *   LC3plus conformance script package
> + */
> +
> +#include "libavcodec/packet.h"
> +#include "libavutil/intreadwrite.h"
> +
> +#include "avformat.h"
> +#include "avio.h"
> +#include "demux.h"
> +#include "internal.h"
> +
> +typedef struct LC3DemuxContext {
> +int frame_samples;
> +int64_t position;
> +int64_t length;
> +} LC3DemuxContext;
> +
> +static int lc3_read_header(AVFormatContext *s)
> +{
> +LC3DemuxContext *lc3 = s->priv_data;
> +AVStream *st = NULL;
> +uint16_t tag, hdr_size;
> +uint16_t frame_us;
> +uint32_t length;
> +int ep_mode, hr_mode;
> +int srate_hz, channels, bit_rate;
> +int num_extra_params, ret;
> +
> +tag = avio_rb16(s->pb);
> +hdr_size = avio_rl16(s->pb);
> +
> +if (tag != 0x1ccc || hdr_size < 9 * sizeof(uint16_t))
> +return 

Re: [FFmpeg-devel] [PATCH 3/5] avformat/lc3: Add file format for LC3/LC3plus transport

[Paul B Mahol]

Demuxer does not support seeking at all.
___
ffmpeg-devel mailing list
ffmpeg-devel@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/5] configure: Add option for enabling LC3/LC3plus wrapper

[Paul B Mahol]

On Tue, Mar 26, 2024 at 6:07 PM Antoine Soulier  wrote:

> What do you mean by sub-optimal?
> It's stacked by prime factors, and unrolled for FFT3 and FF5.
> The butterfly implementations of FFT3 and FF5, gives me slightly slower
> computation. FFT5 is done first, so it takes advantage of sin()/cos()
> values of 0 or 1.
> There are also no reordering steps (this stage is completely removed), but
> cannot run in-place.
> Benchmarks I made show that it runs slightly faster.
>

Compared with what?
Where is at least x86 SIMD for that MDCT?


>
> On Tue, Mar 26, 2024 at 9:59 AM Paul B Mahol  wrote:
>
>>
>> Isn't this using sub-optimal MDCT implementation?
>>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@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/5] configure: Add option for enabling LC3/LC3plus wrapper

[Paul B Mahol]

Isn't this using sub-optimal MDCT implementation?
___
ffmpeg-devel mailing list
ffmpeg-devel@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/af_volumedetect.c: Add 32bit float audio support

[Paul B Mahol]

On Sat, Mar 23, 2024 at 3:28 PM Yiğithan Yiğit 
wrote:

> Hi,
>
> According to your advices, I made some changes of mine last patch. I feel
> like this one way more better. I removed trivial calculations but I want to
> say I am not proud of how I handled histogram in float despite 16 bit
> integer histogram. I am storing dB values instead of storing samples. I
> feel this one is more convenient. Still I am open to advices.
>
>
I see no patch at all.

volumedetect displays histogram typically with 1dB steps, so build
histogram with 1dB range between each bin.
for float, only use normal values, no +inf/subnormals/nans etc.
I bet there is less than current 2^16 entries in histogram table of filter
context to fill.
There is no need to convert each input sample to dB scale. Just to
calculate ranges for each 1dB entry calculate range in linear space and
every such sample that is in such range get added to such histogram bin
entry.
Or if you calculate in dB scale anyway than just round(ceilf/floorf/lrintf)
dB value (removing fractional parts) and add it into histogram table, do
not forget to count >+/-1.0 values too. (ones with >0dB values), you can
use normal mean/max/peak calculations (do not use histogram to calculate
them for float/double).



> Thank you.
> Yigithan
>
>
> 
>
> > On Mar 21, 2024, at 11:30 PM, Paul B Mahol  wrote:
> >
> > On Wed, Mar 20, 2024 at 11:55 PM Yiğithan Yiğit <
> yigithanyigi...@gmail.com <mailto:yigithanyigi...@gmail.com>>
> > wrote:
> >
> >>
> >>> On Mar 21, 2024, at 12:10 AM, Paul B Mahol  wrote:
> >>>
> >>> Why? This is pointless.
> >>>
> >>> volumedetect have histogram output, float patch does not have it at
> all.
> >>> Use astats filter.
> >>>
> >>> On Wed, Mar 20, 2024 at 9:47 PM Yiğithan Yiğit <
> >> yigithanyigi...@gmail.com>
> >>> wrote:
> >>>
> >>>> ___
> >>>> ffmpeg-devel mailing list
> >>>> ffmpeg-devel@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”.
> >>
> >> I am a beginner/student also new at open source but I love FFmpeg and
> >> using in my daily life. From my perspective volumedetect way more user
> >> friendly. I believe adding this patch would be useful to people such as
> >> #9613. The reason lack of histogram output for float mostly for my
> >> indecision about range of the histogram. I am open the suggestions and
> >> after that I can make a new patch.
> >>
> >
> > It is trivial (to some people) to add histogram per dB for float/double
> > inputs.
> > But this patch just does some extremely trivial math calculations so that
> > float input have completely different output from integer ones.
> > That is very odd and unfriendly from my perspective.
> >
> > Besides if you only interested in discrete sample audio peak finder in
> > audio input use astats and measure_overall=Peak_level options.
> > Yes they are not default on. Because more statistics are more important
> > than single number.
> >
> > I'm not against adding proper and useful and correct float/double support
> > to volumedetect, but it needs to have same/similar structure of output as
> > integer sample format input audio, otherwise it just looks lazy and prone
> > for users wondering what is going on when they use different sample
> formats
> > in theirs graphs.
> >
> >
> >>
> >> Best Regards
> >> Yigithan
> >>
> >>
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org <mailto:ffmpeg-devel@ffmpeg.org>
> >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >> To unsubscribe, visit link above, or email
> >> ffmpeg-devel-requ...@ffmpeg.org <mailto:ffmpeg-devel-requ...@ffmpeg.org>
> with subject "unsubscribe".
> >>
> > ___
> &

Re: [FFmpeg-devel] [PATCH 2/6] avfilter/af_channelmap: fix mapping if in_channel was a string but out_channel was not specified

[Paul B Mahol]

Please add coverage for regression cases in FATE.
___
ffmpeg-devel mailing list
ffmpeg-devel@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/af_volumedetect.c: Add 32bit float audio support

[Paul B Mahol]

On Wed, Mar 20, 2024 at 11:55 PM Yiğithan Yiğit 
wrote:

>
> > On Mar 21, 2024, at 12:10 AM, Paul B Mahol  wrote:
> >
> > Why? This is pointless.
> >
> > volumedetect have histogram output, float patch does not have it at all.
> > Use astats filter.
> >
> > On Wed, Mar 20, 2024 at 9:47 PM Yiğithan Yiğit <
> yigithanyigi...@gmail.com>
> > wrote:
> >
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@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”.
>
> I am a beginner/student also new at open source but I love FFmpeg and
> using in my daily life. From my perspective volumedetect way more user
> friendly. I believe adding this patch would be useful to people such as
> #9613. The reason lack of histogram output for float mostly for my
> indecision about range of the histogram. I am open the suggestions and
> after that I can make a new patch.
>

It is trivial (to some people) to add histogram per dB for float/double
inputs.
But this patch just does some extremely trivial math calculations so that
float input have completely different output from integer ones.
That is very odd and unfriendly from my perspective.

Besides if you only interested in discrete sample audio peak finder in
audio input use astats and measure_overall=Peak_level options.
Yes they are not default on. Because more statistics are more important
than single number.

I'm not against adding proper and useful and correct float/double support
to volumedetect, but it needs to have same/similar structure of output as
integer sample format input audio, otherwise it just looks lazy and prone
for users wondering what is going on when they use different sample formats
in theirs graphs.


>
> Best Regards
> Yigithan
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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/af_volumedetect.c: Add 32bit float audio support

[Paul B Mahol]

Why? This is pointless.

volumedetect have histogram output, float patch does not have it at all.
Use astats filter.

On Wed, Mar 20, 2024 at 9:47 PM Yiğithan Yiğit 
wrote:

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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 v2 9/9] avformat/pcm: decrease target audio frame per sec to 10

[Paul B Mahol]

On Thu, Mar 14, 2024 at 11:30 PM Marton Balint  wrote:

>
>
> On Thu, 14 Mar 2024, Paul B Mahol wrote:
>
> > This is just ugly hack for workaround around broken ffmpeg threading.
>
> This actually improves single threaded performance as well, check it with
> ffprobe if you want. Sure, the reason I turned my attention to this is
> the speed loss of ffmpeg.c because of threaded processing, but this is an
> improvement regardless of threaded or non-threaded use.
>

The single thread improvement is less drastic than multi-threading drop
with small packets.
Just compare with using API directly and avoiding ffmpeg.c threading mess.


>
> Regards,
> Marton
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@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 9/9] avformat/pcm: decrease target audio frame per sec to 10

[Paul B Mahol]

This is just ugly hack for workaround around broken ffmpeg threading.

On Thu, Mar 14, 2024 at 9:10 AM Tobias Rapp  wrote:

> On 08/03/2024 01:53, Marton Balint wrote:
>
> > This makes the wav and pcm demuxer demux bigger packets, which is more
> > efficient.
> >
> > Signed-off-by: Marton Balint
> > ---
> >   libavformat/pcm.c |   2 +-
> >   tests/ref/acodec/pcm-s16be|   2 +-
> >   tests/ref/acodec/pcm-s16be_planar |   4 +-
> >   tests/ref/acodec/pcm-s16le_planar |   4 +-
> >   tests/ref/acodec/pcm-s24be|   2 +-
> >   tests/ref/acodec/pcm-s24le_planar |   4 +-
> >   tests/ref/acodec/pcm-s32be|   2 +-
> >   tests/ref/acodec/pcm-s32le_planar |   4 +-
> >   tests/ref/acodec/pcm-s8_planar|   4 +-
> >   tests/ref/acodec/pcm-u16be|   4 +-
> >   tests/ref/acodec/pcm-u16le|   4 +-
> >   tests/ref/acodec/pcm-u24be|   4 +-
> >   tests/ref/acodec/pcm-u24le|   4 +-
> >   tests/ref/acodec/pcm-u32be|   4 +-
> >   tests/ref/acodec/pcm-u32le|   4 +-
> >   tests/ref/acodec/s302m|   8 +-
> >   tests/ref/fate/dcinema-encode |  63 +-
> >   tests/ref/fate/filter-acrossfade  | 623 --
> >   tests/ref/fate/filter-adelay  | 324 ++---
> >   tests/ref/fate/filter-aecho   | 324 ++---
> >   tests/ref/fate/filter-aemphasis-50fm  | 324 ++---
> >   tests/ref/fate/filter-aemphasis-75kf  | 324 ++---
> >   tests/ref/fate/filter-afade-esin  | 324 ++---
> >   tests/ref/fate/filter-afade-exp   | 324 ++---
> >   tests/ref/fate/filter-afade-hsin  | 324 ++---
> >   tests/ref/fate/filter-afade-iqsin | 324 ++---
> >   tests/ref/fate/filter-afade-log   | 324 ++---
> >   tests/ref/fate/filter-afade-qsin  | 324 ++---
> >   tests/ref/fate/filter-agate   | 324 ++---
> >   tests/ref/fate/filter-alimiter| 324 ++---
> >   tests/ref/fate/filter-amerge  | 324 ++---
> >   tests/ref/fate/filter-anequalizer | 324 ++---
> >   tests/ref/fate/filter-apad| 324 ++---
> >   .../ref/fate/filter-asegment-samples-absolute | 324 ++---
> >   .../ref/fate/filter-asegment-samples-relative | 324 ++---
> >   .../fate/filter-asegment-timestamps-absolute  | 326 ++---
> >   .../fate/filter-asegment-timestamps-relative  | 326 ++---
> >   tests/ref/fate/filter-asetrate|  40 +-
> >   tests/ref/fate/filter-atrim-mixed |   4 +-
> >   tests/ref/fate/filter-atrim-time  |   5 +-
> >   tests/ref/fate/filter-chorus  |  20 +-
> >   tests/ref/fate/filter-compand |  40 +-
> >   tests/ref/fate/filter-crystalizer | 324 ++---
> >   tests/ref/fate/filter-dcshift |  40 +-
> >   tests/ref/fate/filter-earwax  |  40 +-
> >   tests/ref/fate/filter-extrastereo |  40 +-
> >   tests/ref/fate/filter-pan-downmix1|  40 +-
> >   tests/ref/fate/filter-pan-downmix2|  40 +-
> >   tests/ref/fate/filter-pan-mono1   |  40 +-
> >   tests/ref/fate/filter-pan-mono2   |  40 +-
> >   tests/ref/fate/filter-pan-stereo1 |  40 +-
> >   tests/ref/fate/filter-pan-stereo2 |  40 +-
> >   tests/ref/fate/filter-pan-stereo3 |  40 +-
> >   tests/ref/fate/filter-pan-stereo4 |  40 +-
> >   tests/ref/fate/filter-pan-upmix1  |  40 +-
> >   tests/ref/fate/filter-pan-upmix2  |  40 +-
> >   tests/ref/fate/filter-stereotools |  40 +-
> >   tests/ref/fate/flcl1905   | 612 -
> >   tests/ref/fate/g722-encode| 282 +++-
> >   tests/ref/fate/g726-encode-2bit   | 282 +++-
> >   tests/ref/fate/g726-encode-3bit   | 282 +++-
> >   tests/ref/fate/g726-encode-4bit   | 282 +++-
> >   tests/ref/fate/g726-encode-5bit   | 282 +++-
> >   tests/ref/fate/matroska-move-cues-to-front|  18 +-
> >   tests/ref/fate/mov-channel-description|   4 +-
> >   tests/ref/fate/mov-mp4-pcm|   4 +-
> >   tests/ref/fate/mov-mp4-pcm-float  |   2 +-
> >   tests/ref/lavf/ast|   4 +-
> >   tests/ref/lavf/mov|  12 +-
> >   tests/ref/lavf/mov_rtphint|   4 +-
> >   tests/ref/lavf/s16.voc|   4 +-
> >   tests/ref/lavf/smjpeg |   6 +-
> >   tests/ref/lavf/voc|   4 +-
> >   

Re: [FFmpeg-devel] Indefinite ban request [RFC] Was: Re: [FFmpeg-trac] #10882(undetermined:new): swscale wastefully scales luma during yuv420p -> yuv422p

[Paul B Mahol]

On Tue, Mar 12, 2024 at 7:11 PM Kieran Kunhya  wrote:

> >
> > Dear LibAV core developer, thank you for this transcript.
> >
>
> If you feel like trolling, at least get your facts correct.
>

Dear minor contributor, can you give link to fact checker to use?


>
> 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] Indefinite ban request [RFC] Was: Re: [FFmpeg-trac] #10882(undetermined:new): swscale wastefully scales luma during yuv420p -> yuv422p

[Paul B Mahol]

On Tue, Mar 12, 2024 at 6:15 PM Ronald S. Bultje  wrote:

> Hello,
>
> On Sat, Mar 9, 2024 at 8:25 PM Michael Niedermayer  >
> wrote:
>
> > Some members of the CC want to indefinitely ban Balling
> > from trac. And as our doc/community.texi says:
> > "Indefinite bans from the community must be confirmed by the General
> > Assembly, in a majority vote."
> >
> > Thus some CC member wishes to involve the public here
> > (really theres no other option, the GA cannot discuss/vote on what it
> > doesnt know)
> >
> > Also people have asked for more transparency and i strongly agree with
> > transparency.
> >
>
> For reference, Anton and I banned "balling" from IRC in November. We
> (FFmpeg's CC) have since then received a request to ban him from trac as
> well.
>
> The ban on IRC was following what happened in #ffmpeg-devel on 11/23/2023 (
> https://libera.irclog.whitequark.org/ffmpeg-devel/2023-11-23)
> I've copied the logs from that link between 14:43 and 18:53 below here for
> reference. My nick is "BBB", and Anton's nick is "elenril". We also
> received help from jess, one of Libera's admins.
>
> 14:43  is Valerii Zapodovnikov the same person that was trolling
> here earlier?
> 14:44  yes
> 14:44  valzapod is his other nickname
> 14:57  okay so he's active in VLC and placebo too
> 14:57  yea
> 14:57  and many other projects which haven't banned him yet
> 15:56  and you will not be able to ban me
> 15:56  You want the Moscow trollfarm?
> 15:57  You will get it
> 15:57  Just do not forget I own copyright in ffmpeg too.
> 15:58  implying someone here asked for it. you're the one behaving
> how you are. maybe you feel you're completely OK, but alas that is not a
> view shared by many. maybe you're much better IRL, but no-one here has had
> the chance of experiencing that.
> 15:59  BTW, I really am surprised. I helped you trac progress as
> Balling and now that is what I get? LOL, maybe start with trac then, Biden
> libtard voters. Is the Russian collusion in the room with right now?
> 15:59  *with us
> 16:00  courmisch I am active also on wireshark, libtorrent
> 16:00  gnuradio (was), rtl-sdr project, all Intel libraries,
> clang now too.
> 16:01  Are you going and try to ban be there too? You will lose.
> Just like Biden lost the election, admit it
> 16:03  BTW, banning all VPNs is nice. Are you using same filter
> as wikipedia? Cool. But again, github servers do no use VPNs, they are
> real. And so are all different virtual machines.
> 16:03  Oh, and I web.archived that discussion on github
> 16:05  on vlc's gitlab, I mean
> 16:06  Biden lost the election, can you LOL???
> 16:06  another maroon
> 16:07  JEEB: I am the same in real life, BTW. You just cannot
> ban a person in real life, only kill. Like that woman that said All lives
> matter in USA.
> 16:09 zadedfqul was kicked from #ffmpeg-devel by elenril [zadedfqul]
> 16:09  pls do NOT engage the troll
> 16:10  I blame TypX this time, but he did not "know"
> 16:13  Banning is also engaging, Anton
> 16:14  Just like your knowledge in top posting.
> 16:14  https://i.imgur.com/3tv4c5x.jpg
> 16:15 wsqacadq was kicked from #ffmpeg-devel by elenril [wsqacadq]
> 16:19  man that dude is persistent :)
> 16:19  does he not have something better to do with his life
> 16:19  takes commitment to contract a VPN just for trolling
> opensoars
> 16:20  or maybe it's provided for official Mordor public service
> use
> 16:20  :)
> 16:20  we'll keep banning the balling
> 16:20  every time I saw that, I hear the dwarfs from the hobbit
> 16:20  courmisch: to be honest the location from which a person is
> does not matter at all
> 16:21  s/is/comes/
> 16:21  untrue
> 16:21  were he from a civilized country, we could use their law
> enforcement services
> 16:21  yea, but someone being an asshole or troll is not is a person
> problem
> 16:21  asdf
> 16:21  I was alluding to troll farms. Not every country has
> them, especially not on the scale of the Russian federation
> 16:21  *is* a person problem
> 16:22  obviously some devs over there are reasonable people
> 16:26  BTW, Trump just needed 44000 votes to win
> 16:27  i thought you said he won? be consistent
> 16:27  And so as there are up to a million ballot that were
> not observed he really did win.
> 16:27 ukrainesucks was banned on #ffmpeg-devel by BBB [*!~
> ukrainesu@195.189.226.40]
> 16:27 ukrainesucks was kicked from #ffmpeg-devel by BBB [Your behavior is
> not conducive to the desired environment.]
> 16:27  psykose: i mean it
> 16:27  do NOT engage the troll
> 16:28  Also, Clinton was fined for Steele dossier
> 16:28 ukrainesuccxxks was banned on #ffmpeg-devel by BBB [*!~
> ukrainesu@91.193.19.147]
> 16:28 ukrainesuccxxks was kicked from #ffmpeg-devel by BBB [Your behavior
> is not conducive to the desired environment.]
> 16:29  +r already
> 16:29  nah
> 16:29  I'm personally fine with +r
> 16:29  but if others object I won't insist on it
> 16:30  I don't think it's anywhere bad enough to require +r
> 16:30  (yet?)
> 

Re: [FFmpeg-devel] Indefinite ban request [RFC] Was: Re: [FFmpeg-trac] #10882(undetermined:new): swscale wastefully scales luma during yuv420p -> yuv422p

[Paul B Mahol]

On Sun, Mar 10, 2024 at 10:24 AM Kieran Kunhya  wrote:

> On Sun, 10 Mar 2024, 01:25 Michael Niedermayer, 
> wrote:
>
> > Hi everyone
> >
> > Some members of the CC want to indefinitely ban Balling
> > from trac. And as our doc/community.texi says:
> > "Indefinite bans from the community must be confirmed by the General
> > Assembly, in a majority vote."
> >
> > Thus some CC member wishes to involve the public here
> > (really theres no other option, the GA cannot discuss/vote on what it
> > doesnt know)
> >
> > Also people have asked for more transparency and i strongly agree with
> > transparency.
> >
> > As reference, and to make it possible for the community to discuss
> > this easily without too much google searching. Ive attached the
> > list of all changes in trac done by Balling.
> >
> > I do not and never did support permanently banning contributors.
> >
> > In summary: since 2019
> > 842 comment0' changed
> > 389 comment1' changed
> > 176 comment2' changed
> >  87 comment3' changed
> >  49 comment4' changed
> >  24 comment5' changed
> >  12 comment6' changed
> >   6 comment7' changed
> >   4 comment8' changed
> >   3 comment9' changed
> >2194 comment' changed
> >  10 component' changed
> >  12 description' changed
> >  29 keywords' changed
> >  37 owner' changed
> >   8 priority' changed
> >   7 reproduced' changed
> > 291 resolution' changed
> > 537 status' changed
> >  32 summary' changed
> >   2 type' changed
> >  11 version' changed
> >
> >
> > On Sat, Mar 02, 2024 at 10:23:32PM +0100, Michael Niedermayer wrote:
> > > The CC has no authority for permanent bans
> > > "Indefinite bans from the community must be confirmed by the General
> > Assembly, in a majority vote."
> > >
> > > I checked and it seems there are over 4800 events in trac from Balling,
> > 3783 match the word "comment"
> > > since 2019
> > >
> > > By what rules does the CC deal out warnings and bans ?
> > >
> > > I think this needs to be put in writing in the docs because
> > > currently its pretty much arbitrary. Some people get multiple
> > > warnings, some people get nothing, some people are suggested to be
> > > just banned with no prior warning
> >
> >
> > On Sat, Mar 09, 2024 at 11:06:39AM +0100, Jean-Baptiste Kempf wrote:
> > > Hello,
> > >
> > > On Sat, 9 Mar 2024, at 08:30, Anton Khirnov wrote:
> > > > Quoting Michael Niedermayer (2024-03-06 13:56:39)
> > > >> Balling does have a quite different style in his language. Not sure
> > > >> what is a good term, street style, ghetto style?
> > > >>
> > > >> He used the same style of language towards me 10 days ago:
> > > >> https://trac.ffmpeg.org/ticket/10824#comment:18
> > > >
> > > > This is not a "style", he understands perfectly well what he is
> doing.
> > >
> > > Come on, the guy is a troll.
> > > We're not talking about a developer from FFmpeg, but an external troll,
> > contributing nothing.
> > > Kick him out.
> >
>
> Do you have permission to post private CC discussion on the ML?
>

Yes, As approved by new supreme leader Anton.


>
> 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] avfilter/fifo: Remove (a)fifo filters

[Paul B Mahol]

On Sat, Mar 9, 2024 at 2:09 AM Muhammad Faiz  wrote:

> On Fri, Mar 8, 2024 at 10:30 PM Paul B Mahol  wrote:
>
> > On Fri, Mar 8, 2024 at 4:18 PM Muhammad Faiz  wrote:
> >
> > > On Fri, Mar 8, 2024 at 5:40 PM Andreas Rheinhardt <
> > > andreas.rheinha...@outlook.com> wrote:
> > >
> > > > Muhammad Faiz:
> > > > > On Tue, Feb 6, 2024 at 3:58 PM Andreas Rheinhardt <
> > > > > andreas.rheinha...@outlook.com> wrote:
> > > > >
> > > > >> Andreas Rheinhardt:
> > > > >>> Obsolete since 4ca1fb9d2a91757c8c4c34dd456abf340e3f765f.
> > > > >>>
> > > > >>> Signed-off-by: Andreas Rheinhardt <
> andreas.rheinha...@outlook.com>
> > > > >>> ---
> > > > >>>  doc/filters.texi |   9 ---
> > > > >>>  libavfilter/Makefile |   1 -
> > > > >>>  libavfilter/allfilters.c |   2 -
> > > > >>>  libavfilter/fifo.c   | 165
> > > ---
> > > > >>>  4 files changed, 177 deletions(-)
> > > > >>>  delete mode 100644 libavfilter/fifo.c
> > > > >>>
> > > > >>
> > > > >> Will apply in a few days unless there are objections.
> > > > >>
> > > > >> - Andreas
> > > > >>
> > > > >>
> > > > > This breaks backward compatibility.
> > > > >
> > > > > Please revert.
> > > > >
> > > > > Thank's.
> > > >
> > > > What breaks that can't simply be fixed by removing the (a)fifo filter
> > > > from the filterchain?
> > > >
> > > > - Andreas
> > > >
> > > >
> > > I use afifo to optimize memory usage.
> > >
> >
> > That statement sync with reality is questionable, fifo filters were
> mainly
> > used before .activate was added,
> > for cases filters used >1 inputs. Now they should be irrelevant, unless
> > there are bugs in code than this filters just hide more bugs.
> >
>
> Yes, I've used it before .activate was added, and it worked, and still
> works.
> Although maybe the bugs have been fixed by .activate, what's wrong if
> (a)fifo still exist?
>

As already wrote, lets repeat it again, hiding real bugs. Hiding is not
correct word,
it just adds yet another layer in filtergraph to accumulate memory/frames,
with extra allocations per each frame for linking between prev and next
frame.
Which is pointless, as libavfilter internal code already have own queue
mechanism.
Check for which filters used after afifo, afifo count of queued frames
reach > 1 than
such filters needs fixing. Personally, my mpv visualizer modified script is
not using afifo filters, and it works fine.


>
> Thank's
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] lavc: replace ff_thread_get_buffer() with ff_get_buffer()

[Paul B Mahol]

On Fri, Mar 8, 2024 at 4:21 PM Vittorio Giovara 
wrote:

> On Fri, Mar 8, 2024 at 4:10 PM Sean McGovern  wrote:
>
> > On Fri, Mar 8, 2024, 08:20 Nicolas George  wrote:
> >
> > > Andreas Rheinhardt (12024-03-08):
> > > > What maintenance cost and complexity are you referring to? I checked
> > and
> > > > could not find a single commit where one had to fix an
> ff_get_buffer()
> > > > to ff_thread_get_buffer() because it has been forgotten when the
> > decoder
> > > > has been declared to support frame threading.
> > >
> > > Welcome to the new FFmpeg, where absolute consistency, i.e. catering
> for
> > > hypothetical mediocre contributors, is more important than easy
> > > optimizations and new approaches.
> > >
> > > And if you do not like it, “shut up, I'm on the TC and I won't recuse”.
> > >
> > > And if you do not like that, “shut up, I'm on the CC too”.
> > >
> > > Regards,
> > >
> > > --
> > >   Nicolas George
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > > To unsubscribe, visit link above, or email
> > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> > >
> >
> > Everybody can we *please* keep the responses civil/professional on the
> ML.
> >
>
> I'd just be happy with "on-topic" but it seems like people with agendas
> like to project on unrelated threads.
>

LibAV actions speak more than words once again.


> --
> 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] avfilter/fifo: Remove (a)fifo filters

[Paul B Mahol]

On Fri, Mar 8, 2024 at 4:18 PM Muhammad Faiz  wrote:

> On Fri, Mar 8, 2024 at 5:40 PM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
>
> > Muhammad Faiz:
> > > On Tue, Feb 6, 2024 at 3:58 PM Andreas Rheinhardt <
> > > andreas.rheinha...@outlook.com> wrote:
> > >
> > >> Andreas Rheinhardt:
> > >>> Obsolete since 4ca1fb9d2a91757c8c4c34dd456abf340e3f765f.
> > >>>
> > >>> Signed-off-by: Andreas Rheinhardt 
> > >>> ---
> > >>>  doc/filters.texi |   9 ---
> > >>>  libavfilter/Makefile |   1 -
> > >>>  libavfilter/allfilters.c |   2 -
> > >>>  libavfilter/fifo.c   | 165
> ---
> > >>>  4 files changed, 177 deletions(-)
> > >>>  delete mode 100644 libavfilter/fifo.c
> > >>>
> > >>
> > >> Will apply in a few days unless there are objections.
> > >>
> > >> - Andreas
> > >>
> > >>
> > > This breaks backward compatibility.
> > >
> > > Please revert.
> > >
> > > Thank's.
> >
> > What breaks that can't simply be fixed by removing the (a)fifo filter
> > from the filterchain?
> >
> > - Andreas
> >
> >
> I use afifo to optimize memory usage.
>

That statement sync with reality is questionable, fifo filters were mainly
used before .activate was added,
for cases filters used >1 inputs. Now they should be irrelevant, unless
there are bugs in code than this filters just hide more bugs.


> And backward incompatible change should only be allowed with deprecation
> periods and major version bump.
>
> Thank's
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] lavc: replace ff_thread_get_buffer() with ff_get_buffer()

[Paul B Mahol]

On Fri, Mar 8, 2024 at 2:20 PM Nicolas George  wrote:

> Andreas Rheinhardt (12024-03-08):
> > What maintenance cost and complexity are you referring to? I checked and
> > could not find a single commit where one had to fix an ff_get_buffer()
> > to ff_thread_get_buffer() because it has been forgotten when the decoder
> > has been declared to support frame threading.
>
> Welcome to the new FFmpeg, where absolute consistency, i.e. catering for
> hypothetical mediocre contributors, is more important than easy
> optimizations and new approaches.
>
> And if you do not like it, “shut up, I'm on the TC and I won't recuse”.
>
> And if you do not like that, “shut up, I'm on the CC too”.
>

Is this first time I 100% agree on something with my archenemy?


>
> Regards,
>
> --
>   Nicolas George
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@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] clarifying the TC conflict of interest rule

[Paul B Mahol]

On Thu, Mar 7, 2024 at 3:01 PM Vittorio Giovara 
wrote:

> On Thu, Mar 7, 2024 at 12:25 AM Michael Niedermayer via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
>
> > > instead of backroom deals, for a
> > > change.
> >
> > iam sorry, but these accusations are not acceptable
> > The application was and is on a public wiki
> > the SoWs where collected by pierre and it was publically announced
> before.
> > I tried to contact all people before the deadline who had incomplete
> > submissions.
> >
>
> I think the backroom deals is referring to the months of silence between
> *some people* knowing and the community being informed, plus the rushed 2
> weeks voting time
>
>
> > I think for a change you should say thanks to tara, pierre, SPI, STF and
> > others
> > doing all the work. Instead of accusations.
> >
>
> I don't see anybody thanking Anton for the work trying to solve the
> contentious point on the rules
> If anything he keeps being disparaged by conspiracy theorists, and getting
> the discussion derailed
>
>
> > And you should submit a proposal with SoW and all needed information
> > next time. Similarly others should too. The idea of this was never to
> have
> > just 2 people submit SoWs
> >
> >
> > >
> > > The application has apparently been submitted, with no public
> > > announcement that it even happened, much less what was in it.
> >
> > whats in it, should simlpy be what was on the wiki application
> > plus the fixes and cleanups mentioned above
> >
>
> Can you guys open a separate thread for these points? They have nothing to
> do with the case at hand.
>

Thanks for confirming complete lack of transparency on all aspects in this
undead project.


> --
>
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] clarifying the TC conflict of interest rule

[Paul B Mahol]

Send warmly welcomes to old/new tyrants of FFmpeg.
___
ffmpeg-devel mailing list
ffmpeg-devel@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 0/2] Remove SDL2 output devices

[Paul B Mahol]

On Wed, Feb 7, 2024 at 6:40 PM Vittorio Giovara 
wrote:

> On Wed, Feb 7, 2024 at 6:38 PM Nicolas George  wrote:
>
> > Anton Khirnov (12024-02-07):
> > > ...so they are precisely broken by design.
> >
> > Words words words.
> >
> > Words to try and hide that something used to work for people and now you
> > are done with it it no longer works.
> >
> > Exactly the kind of attitude that killed libav, killing FFmpeg now.
> >
> >
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> --
> 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".
>

What about subtitles support, they are also very broken.

When subtitles support will be removed soonTM?
___
ffmpeg-devel mailing list
ffmpeg-devel@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] vvcdec: Mark as experimental

[Paul B Mahol]

On Wed, Feb 7, 2024 at 10:13 PM Kieran Kunhya  wrote:

> $subj
>
> As discussed at FOSDEM.
>

Author of this patch above is forced to FUZZ this decoder until
experimental flag is removed.


>
> 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] STF SoWs

[Paul B Mahol]

On Tue, Feb 6, 2024 at 7:17 PM Michael Niedermayer 
wrote:

> Hi
>
> On Tue, Feb 06, 2024 at 12:02:51PM -0500, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Tue, Feb 6, 2024 at 11:05 AM Niklas Haas  wrote:
> >
> > > On Tue, 06 Feb 2024 10:21:21 -0500 "Ronald S. Bultje" <
> rsbul...@gmail.com>
> > > wrote:
> > > > Hi,
> > > >
> > > > On Tue, Feb 6, 2024 at 10:15 AM Michael Niedermayer <
> > > mich...@niedermayer.cc>
> > > > wrote:
> > > >
> > > > > On Tue, Feb 06, 2024 at 09:18:20AM -0500, Ronald S. Bultje wrote:
> > > > > > Hi,
> > > > > >
> > > > > > On Mon, Feb 5, 2024 at 9:06 PM Michael Niedermayer <
> > > > > mich...@niedermayer.cc>
> > > > > > wrote:
> > > > > >
> > > > > > >   2. Deliverables
> > > > > > > Patches submitted for review to the FFMPEG dev mailing list.
> > > > > > >
> > > > > >
> > > > > > I think the goal is to get patches merged, not submitted.
> > > > >
> > > > > Yes but the individual developer cannot gurantee that.
> > > > >
> > > >
> > > > In a bad situation, someone could send unmergeable patches and they
> will
> > > > satisfy the legal requirement above for being paid out. I'm
> suggesting to
> > > > protect the project against that situation.
> > >
> > > Unless I misunderstood you, what you are proposing protects the
> > > Sovereign Tech Fund (aka German government), not the FFmpeg project.
> > > This would only be a concern if we were funding work directly from the
> > > (non-existant) FFmpeg treasury.
> > >
> >
> > It was more about project reputation and the goals being pro-project
> rather
> > than pro-developer. Look at it this way: if patches get submitted but not
> > merged, is FFmpeg helped? Probably not. But money was spent using
> FFmpeg's
> > reputation to secure the funding. Subsequent funding rounds will be more
> > difficult.
>
> > Requiring a merge protects the project against this bad
> > situation.
>
> "Requiring a merge" does not do that
> because lets assume we have a SoW that says "merge to git master" is needed
> now this merge is blocked by someone successfully
> That means the SoW is not fullfilled, the developer is not payed and STF
> has paid SPI. That would ruin FFmpegs reputation even more as
> STF is unhappy (they paid and didnt get what was written in the SoW)
> the developer was not paid, so she would definitly be unhappy
> SPI as the one in the middle would also be in a very uncomfortable
> position.
>
> So i think we should make sure the conditions in the SoW are guranteed to
> be
> achievable
>
>
> >
> > I understand that, hypothetically, if STF had funded SDR, this would be
> > problematic, because no payment is possible for work a majority of the
> > project's constituents doesn't want in. But maybe that ensures project
> > funding is requested for conservative sets of tasks that everyone agrees
> > are good for FFmpeg. So I don't see it as all bad. I don't think anyone
> is
> > realistically planning to find a GA or TC majority to block patches that
> > fix problems found by a static analyzer from going in, purely because it
> is
> > known that work was paid for? That doesn't sound realistic to me. We've
> > historically approved such patches without knowing it being declared
> > whether they were paid for or not.
>
> We have had multiple fixes blocked from going in.
> There was the "i have a file this breaks, i will not share the file" cases
> There where timeout fixes blocked because someone did not like some check
> There was even general argumentation about OOM/Timeout fixes to be better
> not done and rather running ffmpeg in a VM (which does not solve the
> problem
> that the timeouts slow the fuzzer down)
> Some fixes involving checking file extensions and similar also where not
> popular
> There was a time some people tried to block bugfixes if they printed an
> error
> message. (thats why now none of my fixes prints an error message unless
> similar
> cases do already)
> I even remember that a paid bugfix in a demuxer (mov?) was rejected, the
> customer
> was perfectly ok with that and paid me. I think i pointed it out to him
> prior like i do with everyone nowadays that merge to git master cannot be
> guranteed.
> This is just what i remember at the spot.
>
> Assuming the TC will solve it is brave because the TC is new and predates
> most of the examples above.
>
> I disencourage people from putting "merge into git master" as a
> deliverable. It can get you burned in FFmpeg.
>
>
> >
> > But look at it from a higher level: you guys are asking for review of the
> > STF task proposals, and I'm trying to find problems where they exist. I
> > don't think the problem I find - or solution I propose (s/submit/merge/)
> -
> > is crazy. I'm OK with different "fixes" for this problem I'm pointing
> out.
> > But saying that it's not a problem... I disagree with that.
>
> if "merge to git master" is a requirement then iam not participating
> in this. The risk simply outweights the gain. I wont work for months to
> then be at the mercy of not 

Re: [FFmpeg-devel] [PATCH] x86/tx_float: enable SIMD for sizes over 131072

[Paul B Mahol]

Please push this ASAP, my all private projects depends on 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] [RFC] Vote STF/SPI 2024-02

[Paul B Mahol]

On Sun, Feb 4, 2024 at 1:42 AM Michael Niedermayer 
wrote:

> On Sat, Feb 03, 2024 at 04:37:54AM +0100, Michael Niedermayer wrote:
> > On Thu, Feb 01, 2024 at 05:29:26AM +0100, Michael Niedermayer wrote:
> > > Hi all
> > >
> > > To do the STF/SPI thing properly, and make sure we do what the
> Community wants.
> > > We should do this vote: (unless lots of people reply and say we should
> skip the vote)
> > > (i am also CCing jonatan to make sure the option in the vote actually
> ask the GA the
> > >  right question)
> > >
> > > The vote description will be as follows:
> > > The STF/SPI has suggested us to submit an Application / Scope of work
> before their february meeting.
> > > There are about 2 weeks left.
> > > The minimum grant is 150 000 €
> > > The next STF meeting is expected to be in may. If we submit in
> february and are not selected
> > > we can probably try again in may. Which would increase our chances
> > > If we do not submit in february we can probably submit in may.
> > > There is no guarantee that money will be available in may, for example
> between october 2023
> > > and february 2024 no funds where available AFAIK.
> > > Wiki page is here:
> https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024
> > >
> > >
> > > Option A. The Application and Scope of Work from the WIKI shall be
> submitted to STF/SPI before the february 2024 meeting, disagreements in it
> shall be decided by the TC. To achieve continuity, submission shall be done
> by the same person as previous if possible.
> > >
> > > Option B. No Application and Scope of Work shall be submitted in
> february 2024
> > >
> > >
> > > This is a RFC, so if you see errors in it please suggest changes
> >
> > I intend to start the vote in teh next 24h or so.
>
> Vote started, you should have received a mail if you are in the GA
> and you should not have received a mail if you are not in the GA
> 50 mails where sent and there are 50 in the script output.
> I hope that no messup happened in this vote
>
> Please Vote!
>

Never vote for dead project. Controlled by money.


>
> thx
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The bravest are surely those who have the clearest vision
> of what is before them, glory and danger alike, and yet
> notwithstanding go out to meet it. -- Thucydides
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] Sovereign Tech Fund

[Paul B Mahol]

On Sun, Feb 4, 2024 at 11:03 AM J. Dekker  wrote:

>
>
> On Sun, Feb 4, 2024, at 10:49, Rémi Denis-Courmont wrote:
> > Hi,
> >
> > I don't believe it is appropriate to hold the vote before Derek's
> > question is addressed.
> >
> > We don't really know what we're voting on here.
> >
> > Le 1 février 2024 20:22:14 GMT+01:00, Derek Buitenhuis
> >  a écrit :
> >>On 1/31/2024 9:44 PM, Derek Buitenhuis wrote:
> >>> On 1/30/2024 1:48 AM, Michael Niedermayer wrote:
>  https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024
> >>>
> >>> Not to derail this fine thread, but what forks does the Merge Forks
> >>> project refer to?
> >>
> >>I do not believe this has been answered.
> >>
> >>- Derek
>
>
> The vote is unclear for me and also it was not explained who ‘the same
> person as before’ is, no reply or answer to this either. Hope Michael can
> clear this up.
>
> - jd
>


FFmpeg project is dead.


> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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 0/2] Remove SDL2 output devices

[Paul B Mahol]

FFmpeg project leader never left, it is still Michael.
But now there are his minions like Anton and others.

FFmpeg is already dead project.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavc/dxv: fix incorrect back-reference index calculation in DXT5 decoding

[Paul B Mahol]

On Thu, Feb 1, 2024 at 9:41 PM Connor Worley 
wrote:

> Got some confirmation that this patch fixes
> https://trac.ffmpeg.org/ticket/10264
>
>
Thanks for the fix. I had encountered similar artifacts but failed to fix
it, and then removed files long ago, but i got them from the web so will
recheck if this indeed fixes it too.


> --
> Connor Worley
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] Meeting at FOSDEM

[Paul B Mahol]

On Tue, Jan 30, 2024 at 9:22 AM Anton Khirnov  wrote:

> Quoting Jean-Baptiste Kempf (2024-01-28 23:31:45)
> > Hello Folks,
> >
> > FOSDEM is upon us, in a few days.
> >
> > It would be a great idea to meet for a FFmpeg discussion, since quite a
> few of us will be there.
> > So please bring your technical topics with you :)
>
> Some topics currently in my head:
> * switching to C11
> * internally
> * in public headers
> * entangled ABI between lavf and lavd
> * libavio
>
*libavcore
*rename FFmpeg to Libav

>
> --
> 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 v2 1/1] avfilter/vf_vpp_qsv: apply 3D LUT from file.

[Paul B Mahol]

On Sun, Jan 28, 2024 at 11:31 AM Anton Khirnov  wrote:

> Quoting Chen Yufei (2024-01-25 17:16:46)
> > On Wed, Jan 24, 2024 at 7:39 PM Anton Khirnov  wrote:
> > >
> > > Quoting Chen Yufei (2024-01-20 16:14:29)
> > > > Usage: "vpp_qsv=lut3d_file="
> > >
> > > Passing file paths to a filter and having the filter load the file is
> > > not recommended, it is generally preferable to have an
> > > AV_OPT_TYPE_BINARY option, with IO performed by the caller.
> > >
> > > E.g. in ffmpeg CLI you can do
> > >  -filter vpp_qsv=/lut3d=
> > > to load the option value from a file.
> >
> > I searched for code using `AV_OPT_TYPE_BINARY`.
> > `vf_libplacebo.c` gives me a good example.
> >
> > The LUT parsing code is took from `libavfilter/vf_lut3d.c`.
> > It's mainly text processing which calls functions on `FILE*`.
> > Using `AV_OPT_TYPE_BINARY` would require many changes in LUT paring
> > code, and also need to change the command line option of `vf_lut3d`.
> > So I'd keep the lut file option as is.
>
> Your patch is rejected then.
>

Thanks for stating that very clearly.

Yours sincerely, obsequious ex-contributor.


>
> --
> 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] Hardware purchase request: AVX512-capable laptop

[Paul B Mahol]

On Thu, Jan 18, 2024 at 10:57 AM Kieran Kunhya  wrote:

> On Thu, 18 Jan 2024 at 09:55, Paul B Mahol  wrote:
>
> > On Thu, Jan 18, 2024 at 10:53 AM Kieran Kunhya  wrote:
> >
> > > > >> It's a high-spec 4-core machine with 16Gb of RAM, and still very
> > > > >> usable these days, but it'll take around 400 dollars to repair,
> > > > >> as a new original screen is expensive (290), battery isn't cheap
> > (60),
> > > > >> and parts are in general in demand as it's out of support by now.
> > > > >>
> > > > >
> > > > > well i would certainly support ffmpeg-SPI paying for these parts
> > > > > if it helps you.
> > > > >
> > > >
> > > > Right, thanks. But would the main two currently objecting agree?
> > > > I don't think they monitor this thread anymore, but their objections
> > > stand.
> > > >
> > >
> > > I object to buying parts that may not work, or the install may not go
> > well
> > > (I tried repairing my old XPS and it was not simple and I broke the
> > > screen).
> > > I don't think "worth a try" is fair to FFmpeg donors.
> > >
> >
> > Just kill the project and take all the money already.
> >
>
> How would buying parts even work, hardware is the property of SPI. How can
> SPI own half a laptop?
>

So SPI actually own FFmpeg money any anything bought with such money.

Wonders of modern world...


> For reference all the hardware I host for FFmpeg reimbursed by SPI has a
> "property of FFmpeg project" sticker on it.
>
> Regards,
> Kieran Kunhya
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] Hardware purchase request: AVX512-capable laptop

[Paul B Mahol]

On Thu, Jan 18, 2024 at 10:53 AM Kieran Kunhya  wrote:

> > >> It's a high-spec 4-core machine with 16Gb of RAM, and still very
> > >> usable these days, but it'll take around 400 dollars to repair,
> > >> as a new original screen is expensive (290), battery isn't cheap (60),
> > >> and parts are in general in demand as it's out of support by now.
> > >>
> > >
> > > well i would certainly support ffmpeg-SPI paying for these parts
> > > if it helps you.
> > >
> >
> > Right, thanks. But would the main two currently objecting agree?
> > I don't think they monitor this thread anymore, but their objections
> stand.
> >
>
> I object to buying parts that may not work, or the install may not go well
> (I tried repairing my old XPS and it was not simple and I broke the
> screen).
> I don't think "worth a try" is fair to FFmpeg donors.
>

Just kill the project and take all the money already.


>
> 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] Hardware purchase request: AVX512-capable laptop

[Paul B Mahol]

On Tue, Jan 16, 2024 at 11:06 AM Kieran Kunhya  wrote:

> >
> > A ticket doesn't have durability.
> >
>
> A Ryzen 5 vs Ryzen 7 in the same laptop chassis doesn't change its
> durability, it only doubles the laptop's price.
>

Are you CEO of FFmpeg or FFlabs now?


>
> 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] Hardware purchase request: AVX512-capable laptop

[Paul B Mahol]

On Mon, Jan 15, 2024 at 5:01 PM Rémi Denis-Courmont  wrote:

> Le maanantaina 15. tammikuuta 2024, 16.06.32 EET Paul B Mahol a écrit :
> > > I agree with Remi's objections to this.
> > >
> > > Kieran
> >
> > Poor and irrelevant devs object and want to keep money for themself.
>
> Neither of us are poor, which makes this defamatory.
>
> While we may subjectively be irrelavant, that is completely inappropriate
> wording. For you reference, Nicolas was able to articulate that
> characterisation in a much more business-compatible fashion.
>

Business? Why is then this discussion public?


>
> So this is being reported to the CC.
>


You cant report anything, it just show how poor you are.


>
> --
> 雷米‧德尼-库尔蒙
> http://www.remlab.net/
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] Hardware purchase request: AVX512-capable laptop

[Paul B Mahol]

On Mon, Jan 15, 2024 at 9:58 AM Kieran Kunhya  wrote:

> On Sun, 14 Jan 2024, 17:24 Lynne,  wrote:
>
> > Jan 9, 2024, 19:57 by d...@lynne.ee:
> >
> > > Jan 3, 2024, 04:30 by d...@lynne.ee:
> > >
> > >> Jan 3, 2024, 04:04 by d...@lynne.ee:
> > >>
> > >>> Jan 3, 2024, 02:22 by jamr...@gmail.com:
> > >>>
> >  On 1/2/2024 9:56 PM, Lynne wrote:
> > 
> > > As some of you know, my laptop died nearly 2 years ago, and
> > > I've been working on a desktop machine, which is currently a Zen 3.
> > > AVX512 has become more popular in the meantime, with Zen 4
> > > and future AMD CPUs shipping with it, but currently, we have very
> > > little AVX512.
> > > In short, I'd like a machine which runs an AVX512-capable
> > > AMD CPU, and as the world is opening up more and more, I'd
> > > like for it to be portable.
> > >
> > > I've looked around a lot, but as Intel still has a firm monopoly,
> > > the options are limited (7940H(S), 7945HX, 7845HX, 8945HS).
> > > What I think I've settled for is an ASUS Vivobook Pro 15, with a
> > > 7940HS CPU (the second least powerful Zen 4 mobile CPU),
> > >
> > 
> >  7940HS is the highest Ryzen 9 model from the 7040 series. Not sure
> > where you got second least powerful from.
> > 
> > 
> >
> https://en.wikipedia.org/wiki/List_of_AMD_Ryzen_processors#Phoenix_(7040_series,_Zen_4/RDNA3_based)
> > 
> > >>>
> > >>> Was reading Wikipedia, and thought it was a Zen 3, my mistake
> > >>> (and AMD's mistake for making 4 versioning formats):
> > >>> https://en.wikipedia.org/wiki/List_of_AMD_Ryzen_processors
> > >>>
> > >>>
> > > currently trading for 1999.0 EUR on amazon.de.
> > >
> > >
> >
> https://www.amazon.de/-/en/Vivobook-Display-R9-7940HS-Windows-Keyboard/dp/B0BRYTS8MR
> > >
> > > The other alternative I've found is a Lenovo Legion 7 Pro, but
> > > it's more expensive at 2399 EUR (currently seems temporarily
> > > discounted due to the holidays).
> > >
> > 
> >  I see a Lenovo Yoga Pro 7 available for 1099 EUR.
> >
> https://www.amazon.de/-/en/Lenovo-Display-Graphics-Blue-Green-Premium/dp/B0CGLPVQHK/
> > 
> >  Same amount of RAM, screen resolution and storage, and a Ryzen 7.
> > 
> > >>>
> > >>> It's a good suggestion, but I have a better one, that's somewhat more
> > expensive,
> > >>> but has a better screen, better build quality, and is cheaper than
> the
> > Vivobook:
> > >>>
> > >>> A Lenovo ThinkPad P14s Gen 4 with the following options:
> > >>>  - Windows 14 Home (if you don't pick Windows, the OLED display is
> not
> > available for no reason)
> > >>>  - 32Gb of RAM
> > >>>  - 1Tb "performance" SSD (it's 70 EUR more, but twice the size)
> > >>>  - 2880x1800 OLED monitor
> > >>>  - 4-cell battery (only 10 EUR more)
> > >>>  - English (EU) keyboard, without backlighting
> > >>>
> > >>>
> >
> https://www.lenovo.com/de/de/configurator/cto/index.html?bundleId=21K9CTO1WWDE2
> > >>>
> > >>
> > >> Correction: link I pasted was for the P16s, not the P14s, this is the
> > correct link:
> > >>
> >
> https://www.lenovo.com/de/de/configurator/cto/index.html?bundleId=21K5CTO1WWDE2
> > >>
> > >
> > > Ping. So far I have one approval from Michael.
> > >
> >
> > Ping.
> >
>
> I agree with Remi's objections to this.
>
> Kieran
>

Poor and irrelevant devs object and want to keep money for themself.


>
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] fate/audio: add ADX demux and decode test

[Paul B Mahol]

http://coverage.ffmpeg.org/

*Is this really needed? Does it improves coverage at all?*

On Thu, Jan 11, 2024 at 11:02 PM Marth64  wrote:

> Necessary samples to fate-samples/adx :
> https://ufile.io/f/v306q
>
> Samples are re-encodes of luckynight from FATE suite.
> d3a67e1d21bbaa7afc8e3bd089545ad44685e0c7a4212a75f7d115b0b8d656eb
> luckynight.adx
> f994367773da8cadc5a41d7eab680a3f24685211d3564d8a806857cab47bdf25
> luckynight.pcm
>
> Signed-off-by: Marth64 
> ---
>  tests/fate/audio.mak | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/tests/fate/audio.mak b/tests/fate/audio.mak
> index 65317c8d45..1c0f48ae0d 100644
> --- a/tests/fate/audio.mak
> +++ b/tests/fate/audio.mak
> @@ -1,3 +1,8 @@
> +FATE_SAMPLES_AUDIO-$(call DEMDEC, ADX, ADPCM_ADX) += fate-adx
> +fate-adx: CMD = pcm -i $(TARGET_SAMPLES)/adx/luckynight.adx
> +fate-adx: CMP = oneoff
> +fate-adx: REF = $(SAMPLES)/adx/luckynight.pcm
> +
>  FATE_SAMPLES_AUDIO-$(call TRANSCODE, APTX, APTX, WAV_DEMUXER
> PCM_S16LE_DECODER ARESAMPLE_FILTER) += fate-aptx
>  fate-aptx: CMD = transcode wav
> $(TARGET_SAMPLES)/audio-reference/luckynight_2ch_44kHz_s16.wav aptx "-af
> aresample -c aptx" "-af aresample -c:a pcm_s16le -t 0.25" "" "" "-f aptx
> -sample_rate 44100"
>
> --
> 2.34.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".

Re: [FFmpeg-devel] Hardware purchase request: AVX512-capable laptop

[Paul B Mahol]

On Wed, Jan 10, 2024 at 3:56 AM Lynne  wrote:

> Jan 10, 2024, 03:31 by mich...@niedermayer.cc:
>
> > On Sat, Jan 06, 2024 at 06:42:40PM +0100, Michael Niedermayer wrote:
> >
> >> Hi
> >>
> >> On Wed, Jan 03, 2024 at 01:56:12AM +0100, Lynne wrote:
> >> > As some of you know, my laptop died nearly 2 years ago, and
> >>
> >> Why/how did the laptop die ?
> >> is it unrepearable ?
> >>
> >
> > ping
> >
>
> It was a 4th gen Thinkpad X1 Carbon. A few drops of water got in
> between the caps lock before I noticed, by the time I did, it was too late.
> Battery circuitry is dead so it only runs on AC, frequency controller is
> dying so it runs at fixed Pentium II 350Mhz speeds, keyboard controller
> sees keys pressed all the time, touchpad is dead, USB is dead.
> The motherboard crammed essential components on the periphery
> and non-essential replaceable components like wifi and 4g modem
> right next to the CPU, so it was not great engineering.
> It did live a long life for 7 years, but only the shell remains mostly
> usable.
> I may not be able to put it back together as it was, since I lost some
> screws,
> as I kept working on it for months.
>

NAK, FFmpeg developers do not need hardware.


> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] Mailinglist conduct [was: Re: [PATCH] lavc: remove the QOA decoder]

[Paul B Mahol]

On Wed, Dec 27, 2023 at 12:53 AM James Almer  wrote:

>
> On 12/26/2023 7:40 PM, Paul B Mahol wrote:
> > On Tue, Dec 26, 2023 at 11:20 PM Ronald S. Bultje 
> > wrote:
> >
> >> Paul,
> >>
> >> On Thu, Dec 21, 2023 at 3:05 PM Paul B Mahol  wrote:
> >>
> >>> Say what serious feature you contributed ? - Nothing.
> >>>
> >>
> >> the CC requests that you please refrain from attacking fellow FFmpeg
> >> contributors ("what serious feature [have] you contributed? - Nothing")
> on
> >> the mailinglist.
> >>
> >
> > I object here to your dictatorship trolling.
> >
> > Your are selectively picking what to comment and censor.
>
> What did the phrase Ronald quoted add to the conversation? Do you
> consider that being civil? Because pretty much no one does.
> Why can't people discuss and exchange opinions without talking shit to
> each other?
>
> This ML has a very bad reputation because things like that are rampant,
> so it has to stop. How will anyone want to contribute if the threat of
> being shit talked for no reason is always looming?
>

Talk with Thardin, cowboy coding subtle calling and triggering begin with
that entity mails.


> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] Mailinglist conduct [was: Re: [PATCH] lavc: remove the QOA decoder]

[Paul B Mahol]

On Tue, Dec 26, 2023 at 11:20 PM Ronald S. Bultje 
wrote:

> Paul,
>
> On Thu, Dec 21, 2023 at 3:05 PM Paul B Mahol  wrote:
>
> > Say what serious feature you contributed ? - Nothing.
> >
>
> the CC requests that you please refrain from attacking fellow FFmpeg
> contributors ("what serious feature [have] you contributed? - Nothing") on
> the mailinglist.
>

I object here to your dictatorship trolling.

Your are selectively picking what to comment and censor.

Your cowboy show is over!


>
> Signed unanimously,
> the CC illuminati (Anton, James, Jean-Baptiste, Michael, Ronald)
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] lavc: remove the QOA decoder

[Paul B Mahol]

On Sun, Dec 24, 2023 at 6:22 PM Michael Niedermayer 
wrote:

> On Sun, Dec 24, 2023 at 04:11:30PM +0100, Nicolas George wrote:
> > Tomas Härdin (12023-12-24):
> > > Nah, NIH is bad.
> >
> > Then you need to find a different project. FFmpeg exists because a
> > genius hacker decided to NIH a MPEG software decoder.
>
> Please stop attacking Tomas!
>
> FFmpeg exists because many people, many who have different
> views work together.
>
> About MXF i agree with you and disagree with Tomas but that can be
> stated in a technical way without offending anyone.
>
> And just recently Tomas helped with jpeg2000, you can find the patches
> he reviewed ...
>
> theres absolutely no sense in this personal attack on others!
>
> PS (off topic): if you want everyone to work on one MXF codebase, everyone
> is
> welcome to join FFmpeg :)
>

Merry Christmas !


>
> thx
>
> PS: we have christmess (and happy christmess btw to everyone)
> 12-24 is not holmgang ;)
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Rewriting code that is poorly written but fully understood is good.
> Rewriting code that one doesnt understand is a sign that one is less smart
> than the original author, trying to rewrite it will not make it better.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] lavc: remove the QOA decoder

[Paul B Mahol]

On Sun, Dec 24, 2023 at 3:33 PM Tomas Härdin  wrote:

> sön 2023-12-24 klockan 13:12 +0100 skrev Nicolas George:
> > Tomas Härdin (12023-12-24):
> > > But I'd prefer if it were replaced by bmxlib.
> >
> > Yes, we know that you have not understood that the raison d'être of
> > FFmpeg is to IMPLEMENT natively all multimedia formats and protocols
> > and
> > the utility code they need, not be a mere collection of wrappers.
>
> Nah, NIH is bad. It is a waste of labour power. It cuts down on hammock
> time.
>

Yes, you are always correct, not.
___
ffmpeg-devel mailing list
ffmpeg-devel@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/af_stereowiden: Check length

[Paul B Mahol]

This is highly suboptimal, use rounding-up.
See librempeg code.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Add new vf_tiltandshift filter

[Paul B Mahol]

On Fri, Dec 22, 2023 at 4:41 PM Ronald S. Bultje  wrote:

> Hi Paul,
>
> On Fri, Dec 22, 2023 at 10:33 AM Paul B Mahol  wrote:
>
> > There are some serious issues in this code.
> >
>
> While already very insightful, it would be enormously helpful if you could
> expand on this statement with more detail, such as a list of issues as they
> exist in this code.
>

Librempeg.


>
> Ronald
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] Add new vf_tiltandshift filter

[Paul B Mahol]

There are some serious issues in this code.
Also missing tests.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavc: remove the QOA decoder

[Paul B Mahol]

On Fri, Dec 22, 2023 at 7:28 AM Anton Khirnov  wrote:

> Hi Paul,
> Quoting Paul B Mahol (2023-12-21 21:05:18)
> > Say what serious feature you contributed ? - Nothing.
>
> this is a personal attach. Personal attacks are not allowed on this
> mailing list. Please refrain from them in the future.
>

Sorry to personally attach you, but best coding cowboy in current FFmpeg is
you.


>
> --
> Anton Khirnov
> (CC member)
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] lavc: remove the QOA decoder

[Paul B Mahol]

On Thu, Dec 21, 2023 at 8:43 PM Tomas Härdin  wrote:

> ons 2023-12-20 klockan 20:11 +0100 skrev Michael Niedermayer:
> > On Wed, Dec 20, 2023 at 05:57:40PM +0100, Tomas Härdin wrote:
> > > tis 2023-12-19 klockan 15:02 +0100 skrev Nicolas George:
> > [...]
> > > [...] , but every line of code
> > > carries with it a non-zero maintenance burden
> >
> > Assuming you mean with "non-zero" a "larger than zero" maintenance
> > burden
> >
> > then we can proof this to be false
>
> Doubt
>
> > What iam trying to say is, the maintaince burden resulting from a
> > change
> > is complex
>
> Indeed
>
> > In this specific case here we have a patch proposing the removial of
> > a decoder
> > missing a test.
> > Its easy to say the burden is less when the decoder is removed
> > But its author recently left the project too
>
> This is one problem. But the careless attitude to shoving more features
> into the codebase is far more serious. Every line of code is a CVE
> waiting to happen. Apparently this is a difficult thing to grasp for
> some contributors. It's an attitude I expect only from junior
> developers.
>
> Ensuring C code is correct and safe is *hard*. I have spent time
> formally verifying embedded C code for spaceflight. The lessons learned
> from this has made me supremely suspicious of cowboy coding.
>
> I have raised this issue multiple times in this project to no avail. I
> do not expect things to change.
>

Say what serious feature you contributed ? - Nothing.
___
ffmpeg-devel mailing list
ffmpeg-devel@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 13/13 v3] fftools/ffmpeg: convert to a threaded architecture

[Paul B Mahol]

On Thu, Dec 7, 2023 at 6:26 PM Paul B Mahol  wrote:

>
>
> On Wed, Dec 6, 2023 at 2:38 PM Nicolas George  wrote:
>
>> James Almer (12023-12-06):
>> > I honestly can't believe you're arguing this.
>>
>> Yet I do, so I suggest you think a little harder to understand why I do.
>>
>> > And being condescending will not help your case.
>>
>> Can you tell that to Anton too please?
>>
>> > If i request -bitexact, i want bitexact output, regardless of running
>> on a
>> > core i3 or a Threadripper. There's nothing more to it.
>>
>> I had not noticed the -bitexact on the test command line. I will grant
>> the change is acceptable if bit-exact is requested.
>>
>> > Calling random output that happens to be "acceptable" within the
>> subjective
>> > expectations of the user as useful sounds to me like you're trying to
>> find
>> > an excuse to keep buggy code with unpredictable results around, just
>> because
>> > it's been there for a long time.
>>
>> Well, you are wrong, and what I explained is the real reason: most
>> subtitles are not timed that accurately. The subtitles on HBO's Last
>> Week Tonight, for example, can randomly lag or be early by several
>> seconds. Even serious subtitles, like the ones for scripted shows on
>> Netflix/Amazon/Crunchyroll/whatever vary by a few tenths of seconds,
>> i.e. several frames.
>>
>> And I have used this code. And I look carefully at subtitles. If the
>> result was lower quality than the source material, I would have noticed
>> and I would have endeavored to fix it. There never was need.
>>
>> Now, can Anton claim similar experience working with subtitles from the
>> real world? Most of this discussions points to the answer being no.
>>
>> > So, like Anton has asked several times, suggest a way to keep
>> deterministic
>> > and bitexact output without exponentially increasing memory consumption
>> due
>> > to buffering.
>>
>> I will spend time and effort searching for a solution when we agree to
>> work together.
>>
>> “Do this or I will break your code” is an unacceptable behavior, whether
>> it is directed at me or at Paul or at anybody else, and I do not spend
>> effort when unacceptable behavior is tolerated.
>>
>>
> From 3.4 version of ffmpeg to 6.1 version demuxing  truehd (-c:a copy)
> files dropped by factor of 2x speed.
> But simple transcode from doc/examples is still several times faster than
> that.
>
> I bet using mutexes and condition variables is far from perfect solution
> or fftools/ code is buggy.
>
> This is similar to -lavfi sources dropouts in performance but more used by
> users of truehd/any small packets format.
>

I found out if I increase queue size of thread for frames/packets in
fftools/ from 1 to >1 it increases speed in decoding by 10%.
Looks like other numbers greater than 2 do not make much any difference.

Still current state is sub-optimal.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] web: remove myself from FFmpeg consulting page

[Paul B Mahol]

On Sat, Dec 16, 2023 at 3:49 PM James Almer  wrote:

> On 12/16/2023 11:47 AM, Paul B Mahol wrote:
> > On Sat, Dec 16, 2023 at 3:45 PM James Almer  wrote:
> >
> >> On 12/16/2023 11:43 AM, Paul B Mahol wrote:
> >>> On Sat, Dec 16, 2023 at 3:41 PM James Almer  wrote:
> >>>
> >>>> On 12/16/2023 11:34 AM, Paul B Mahol wrote:
> >>>>> Can someone commit this already?
> >>>>
> >>>> You still have commit rights.
> >>>>
> >>>
> >>> For web?
> >>
> >> Yes, The ssh key you use for ffmpeg.git should work for ffmpeg-web.git
> too.
> >>
> >
> > Dunno what is git url.
>
> Push url should be g...@git.ffmpeg.org:ffmpeg-web.git


Cloning into 'ffmpeg-web'...
Enter passphrase for key '/home/computer/.ssh/id_rsa':
FATAL: R any ffmpeg-web durandal DENIED by fallthru
(or you mis-spelled the reponame)
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] web: remove myself from FFmpeg consulting page

[Paul B Mahol]

On Sat, Dec 16, 2023 at 3:45 PM James Almer  wrote:

> On 12/16/2023 11:43 AM, Paul B Mahol wrote:
> > On Sat, Dec 16, 2023 at 3:41 PM James Almer  wrote:
> >
> >> On 12/16/2023 11:34 AM, Paul B Mahol wrote:
> >>> Can someone commit this already?
> >>
> >> You still have commit rights.
> >>
> >
> > For web?
>
> Yes, The ssh key you use for ffmpeg.git should work for ffmpeg-web.git too.
>

Dunno what is git url.


> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] web: remove myself from FFmpeg consulting page

[Paul B Mahol]

On Sat, Dec 16, 2023 at 3:41 PM James Almer  wrote:

> On 12/16/2023 11:34 AM, Paul B Mahol wrote:
> > Can someone commit this already?
>
> You still have commit rights.
>

For web?


> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] web: remove myself from FFmpeg consulting page

[Paul B Mahol]

Can someone commit this already?
___
ffmpeg-devel mailing list
ffmpeg-devel@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 13/13 v3] fftools/ffmpeg: convert to a threaded architecture

[Paul B Mahol]

On Wed, Dec 6, 2023 at 2:38 PM Nicolas George  wrote:

> James Almer (12023-12-06):
> > I honestly can't believe you're arguing this.
>
> Yet I do, so I suggest you think a little harder to understand why I do.
>
> > And being condescending will not help your case.
>
> Can you tell that to Anton too please?
>
> > If i request -bitexact, i want bitexact output, regardless of running on
> a
> > core i3 or a Threadripper. There's nothing more to it.
>
> I had not noticed the -bitexact on the test command line. I will grant
> the change is acceptable if bit-exact is requested.
>
> > Calling random output that happens to be "acceptable" within the
> subjective
> > expectations of the user as useful sounds to me like you're trying to
> find
> > an excuse to keep buggy code with unpredictable results around, just
> because
> > it's been there for a long time.
>
> Well, you are wrong, and what I explained is the real reason: most
> subtitles are not timed that accurately. The subtitles on HBO's Last
> Week Tonight, for example, can randomly lag or be early by several
> seconds. Even serious subtitles, like the ones for scripted shows on
> Netflix/Amazon/Crunchyroll/whatever vary by a few tenths of seconds,
> i.e. several frames.
>
> And I have used this code. And I look carefully at subtitles. If the
> result was lower quality than the source material, I would have noticed
> and I would have endeavored to fix it. There never was need.
>
> Now, can Anton claim similar experience working with subtitles from the
> real world? Most of this discussions points to the answer being no.
>
> > So, like Anton has asked several times, suggest a way to keep
> deterministic
> > and bitexact output without exponentially increasing memory consumption
> due
> > to buffering.
>
> I will spend time and effort searching for a solution when we agree to
> work together.
>
> “Do this or I will break your code” is an unacceptable behavior, whether
> it is directed at me or at Paul or at anybody else, and I do not spend
> effort when unacceptable behavior is tolerated.
>
>
From 3.4 version of ffmpeg to 6.1 version demuxing  truehd (-c:a copy)
files dropped by factor of 2x speed.
But simple transcode from doc/examples is still several times faster than
that.

I bet using mutexes and condition variables is far from perfect solution or
fftools/ code is buggy.

This is similar to -lavfi sources dropouts in performance but more used by
users of truehd/any small packets format.


> --
>   Nicolas George
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@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] [ANNOUNCEMENT] Left FFmpeg; starting Librempeg

[Paul B Mahol]

On Thu, Dec 7, 2023 at 10:27 AM Lynne  wrote:

> Dec 7, 2023, 09:51 by one...@gmail.com:
>
> > On Thu, Dec 7, 2023 at 9:23 AM Lynne  wrote:
> >
> >> Dec 6, 2023, 21:27 by one...@gmail.com:
> >>
> >> > Today, effectively immediately, I officially Ieft the FFmpeg project.
> >> >
> >> > For new
> >> >
> decoders/encoders/muxers/demuxers/filters/fixes/speedups/tests/cleanups
> >> > etc. look at Librempeg project on github, source code will appear soon
> >> > there.
> >> >
> >>
> >> Calm down, there's no need to leave over such silly reasons. Tests
> >> can wait, and someone else can add them.
> >> Besides, I need someone to review my FFT patches which I plan to post in
> >> a few hours, and there's still the AC-4 decoder that I'll help you
> finish
> >> up.
> >> Take a few days off if you have to, log back into IRC and we'll talk it
> >> through?
> >>
> >
> > Sorry to disappoint you but that hit just top of iceberg.
> >
> > For FFT/RDFT x86 improvements and testing you can send PR to Librempeg
> > project directly.
> >
>
> I think it would be easier to just work together here.
> If you're unhappy with the rules, like requiring patches to sit
> on the ML for review for 3 days before pushing, even if the code is your
> own,
> we can change that.
> There's nothing that cannot be fixed.
>

Its over. sooner you accept that its better.

Already removed libpostproc cruft, and couple others (sonic) are planned
for removal too.



> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] [ANNOUNCEMENT] Left FFmpeg; starting Librempeg

[Paul B Mahol]

On Thu, Dec 7, 2023 at 9:23 AM Lynne  wrote:

> Dec 6, 2023, 21:27 by one...@gmail.com:
>
> > Today, effectively immediately, I officially Ieft the FFmpeg project.
> >
> > For new
> > decoders/encoders/muxers/demuxers/filters/fixes/speedups/tests/cleanups
> > etc. look at Librempeg project on github, source code will appear soon
> > there.
> >
>
> Calm down, there's no need to leave over such silly reasons. Tests
> can wait, and someone else can add them.
> Besides, I need someone to review my FFT patches which I plan to post in
> a few hours, and there's still the AC-4 decoder that I'll help you finish
> up.
> Take a few days off if you have to, log back into IRC and we'll talk it
> through?
>

Sorry to disappoint you but that hit just top of iceberg.

For FFT/RDFT x86 improvements and testing you can send PR to Librempeg
project directly.


> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] web: remove myself from FFmpeg consulting page

[Paul B Mahol]

Attached.
From dbee6548020b42f4559042fd6a50fa4fa35121ff Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Thu, 7 Dec 2023 08:45:23 +0100
Subject: [PATCH] remove myself from FFmpeg consulting page

---
 src/consulting | 12 
 1 file changed, 12 deletions(-)

diff --git a/src/consulting b/src/consulting
index 70a88e5..1e205b5 100644
--- a/src/consulting
+++ b/src/consulting
@@ -82,18 +82,6 @@ E.g.:

  
 
-  
-
-  Paul B Mahol
-  
-Paul is located in Croatia and is available for contracting work. He has
-worked on FFmpeg since 2011 and has been a maintainer since 2012. He has
-experience with various codecs, containers, filters and reverse
-engineering. You can contact him by email at
-onemda at gmail dot com.
-  
- 
-   
   
 
   Thilo Borgmann
-- 
2.42.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".