Re: [FFmpeg-devel] [PATCH v2] libavdevice: Improve example in deprecation message for opengl and sdl
On 2024-04-29 23:53 +0200, Alexander Strasser via ffmpeg-devel wrote: > When piping ffmpeg into ffplay both programs write a status line in > the terminal. That causes flickering and invisibility of one or the > other status line. > > As compromise set ffplay log level to warning, so it doesn't show > the status line. > > The user is usually testing ffmpeg command lines and want's a > preview of the result. This way the user can see the ffmpeg output > and still see errors and warnings from ffplay, should they occur. > > Additionally set PTS to zero in ffplay to lessen the delay until > the frames are displayed. Without it delay is quite observable > when e.g. live capturing with low frame rates. > --- > > Same as previous patch, but with setpts=0 in ffplay as suggested by > Nicolas George. > > > libavdevice/opengl_enc.c | 2 +- > libavdevice/sdl2.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavdevice/opengl_enc.c b/libavdevice/opengl_enc.c > index 6f7a30ff9e..93d3959880 100644 > --- a/libavdevice/opengl_enc.c > +++ b/libavdevice/opengl_enc.c > @@ -1067,7 +1067,7 @@ static av_cold int opengl_write_header(AVFormatContext > *h) > av_log(opengl, AV_LOG_WARNING, > "The opengl output device is deprecated due to being > fundamentally incompatible with libavformat API. " > "For monitoring purposes in ffmpeg you can output to a file or > use pipes and a video player.\n" > -"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -\n" > +"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay > -loglevel warning -vf setpts=0 -\n" > ); > opengl->warned = 1; > } > diff --git a/libavdevice/sdl2.c b/libavdevice/sdl2.c > index 779c8e08b0..491c8dafe8 100644 > --- a/libavdevice/sdl2.c > +++ b/libavdevice/sdl2.c > @@ -167,7 +167,7 @@ static int sdl2_write_header(AVFormatContext *s) > av_log(sdl, AV_LOG_WARNING, > "The sdl output device is deprecated due to being fundamentally > incompatible with libavformat API. " > "For monitoring purposes in ffmpeg you can output to a file or > use pipes and a video player.\n" > -"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -\n" > +"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay > -loglevel warning -vf setpts=0 -\n" > ); > sdl->warned = 1; > } > -- Will try to push soon'ish if I don't hear any objections. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] lavu/float_dsp: add double-precision scalar product
On 2024-05-29 18:51 +0300, Rémi Denis-Courmont wrote: > Le keskiviikkona 29. toukokuuta 2024, 18.44.13 EEST Andreas Rheinhardt a écrit > : > > > +static double ff_scalarproduct_double_c(const double *v1, > > > Don't use an ff_ prefix for a static function. > > I can see over 300 such identifiers in the code base (many but not all > inline), > and I don't see why that would be a problem. I agree that it's not a problem regarding on the functional side, OTOH regarding coding conventions we try to consistently follow it's misleading as the ff_ prefix indicates a bigger scope of sharing. Maybe I'm missing something, but it looks to me that more than half of those over 300 instances are correct (the inline ones in the headers). I think Andreas remark is correct and it would be better to not use ff_ prefix wrongly when adding new code. Best regards, Alexander [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] lavu/float_dsp: add double-precision scalar product
On 2024-06-02 13:30 +0300, Rémi Denis-Courmont wrote: > Le sunnuntaina 2. kesäkuuta 2024, 13.04.05 EEST Alexander Strasser via ffmpeg- > devel a écrit : > > On 2024-05-29 18:51 +0300, Rémi Denis-Courmont wrote: > > > Le keskiviikkona 29. toukokuuta 2024, 18.44.13 EEST Andreas Rheinhardt a > > > écrit> > > > > > +static double ff_scalarproduct_double_c(const double *v1, > > > > > > > > Don't use an ff_ prefix for a static function. > > > > > > I can see over 300 such identifiers in the code base (many but not all > > > inline), and I don't see why that would be a problem. > > > > I agree that it's not a problem regarding on the functional side, > > OTOH regarding coding conventions we try to consistently follow it's > > misleading as the ff_ prefix indicates a bigger scope of sharing. > > Anybody can see the 'static' qualifier literally in front to see the function > is not in a bigger scope of sharing. And if you do somehow miss and try to use > the function, you will get a linker error. > > The only case where this *actually* matters is in debugging. And exactly then > it is much better to use the ff_ prefix *because* all symbols, including local > ones like this, end up sharing the namespace. But not at the call site? > > I think Andreas remark is correct and it would be better to not use ff_ > > prefix wrongly when adding new code. > > IMO, it is worse. I tend to disagree here as it makes the meaning of the ff_ prefix arbitrary. Anyway if you want to challenge this convention we are using since many years in this code base, I suggest to do it in a separate discussion thread. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] fftools/ffmpeg and libavdevice/sdl issue
On 2023-12-14 01:47 +0100, Stefano Sabatini wrote: > On date Wednesday 2023-12-13 10:08:45 +0100, Anton Khirnov wrote: > > Quoting Zhao Zhili (2023-12-12 18:27:39) > [...] > > Honestly I don't see how this could be done in ffmpeg CLI without > > disgusting hacks, but before that the question is: > > > why is there an SDL > > "muxer" and why would anyone want to use it in ffmpeg CLI? What actual > > use cases does it serve that cannot be better handled otherwise? > > As the author of the first sdl.c muxer, maybe I can answer to this > question. It was done partly as an exercise and for fun, but also > because this was useful extremely handy for testing (e.g. to display > the output of a filterchain from ffmpeg, or to display a streamed > video in realtime). That is what I used it for countless times as well. It has a lot of merit in handling compared to piping to a player, where one needs to run 2 processes in one command line with all the drawbacks that come with it. > The final goal was (still is) to unify all the tools as very thin > instances of the library. Even if this might be not practical, I think > it is a good final design plan (e.g. ffprobe might be turned to a > custom muxer, ffplay would be the realtime output of a filtergraph > connected to a rendering device, ffmpeg would be a data filtergraph > processor, and you can mix rendering and encoding if you add a movie > sink to the game). I agree to this perspective. Making most of the functionality available through the FFmpeg libs and therefore available for wider application of a broader audience seems valuable. Such a big goal that cannot be reached in a predictable time frame should be challenged over the years and the plans, in so far they exist, need to be adjusted accordingly. Still that doesn't mean the goal is not worthwhile or not achievable. On an ending note: I don't like at all the way this discussion unraveled: 1. Someone wants to fix a reported problem after the new threading changes 2. It is questioned why a feature that exists for over a decade is there I hope this can get back on a more constructive rail. Otherwise I fear it just sets precedence for more to come :( Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavdevice: Improve example in deprecation message for opengl and sdl
When piping ffmpeg into ffplay both programs write a status line in the terminal. That causes flickering and invisibility of one or the other status line. As compromise set ffplay log level to warning, so it doesn't show the status line. The user is usually testing ffmpeg command lines and want's a preview of the result. This way the user can see the ffmpeg output and still see errors and warnings from ffplay, should they occur. --- libavdevice/opengl_enc.c | 2 +- libavdevice/sdl2.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libavdevice/opengl_enc.c b/libavdevice/opengl_enc.c index 6f7a30ff9e..c50d02870a 100644 --- a/libavdevice/opengl_enc.c +++ b/libavdevice/opengl_enc.c @@ -1067,7 +1067,7 @@ static av_cold int opengl_write_header(AVFormatContext *h) av_log(opengl, AV_LOG_WARNING, "The opengl output device is deprecated due to being fundamentally incompatible with libavformat API. " "For monitoring purposes in ffmpeg you can output to a file or use pipes and a video player.\n" -"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -\n" +"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -loglevel warning -\n" ); opengl->warned = 1; } diff --git a/libavdevice/sdl2.c b/libavdevice/sdl2.c index 779c8e08b0..59e3182df8 100644 --- a/libavdevice/sdl2.c +++ b/libavdevice/sdl2.c @@ -167,7 +167,7 @@ static int sdl2_write_header(AVFormatContext *s) av_log(sdl, AV_LOG_WARNING, "The sdl output device is deprecated due to being fundamentally incompatible with libavformat API. " "For monitoring purposes in ffmpeg you can output to a file or use pipes and a video player.\n" -"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -\n" +"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -loglevel warning -\n" ); sdl->warned = 1; } -- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fate: allow https for git URLs
On 2024-04-24 22:01 +0200, Timo Rothenpieler wrote:
> ---
> tests/fate.sh | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tests/fate.sh b/tests/fate.sh
> index c5ee18de80..4081e865ae 100755
> --- a/tests/fate.sh
> +++ b/tests/fate.sh
> @@ -30,14 +30,14 @@ lock(){
> checkout(){
> case "$repo" in
> file:*|/*) src="${repo#file:}" ;;
> -git:*) git clone --quiet --branch "$branch" "$repo" "$src" ;;
> +git:*|https:*) git clone --quiet --branch "$branch" "$repo" "$src" ;;
> esac
> }
>
> update()(
> cd ${src} || return
> case "$repo" in
> -git:*) git fetch --quiet --force && git reset --quiet --hard
> "origin/$branch" ;;
> +git:*|https:*) git fetch --quiet --force && git reset --quiet --hard
> "origin/$branch" ;;
> esac
> )
Should be OK if tested to work with both git and https URLs in repo.
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fate: allow https for git URLs
On 2024-04-24 22:26 +0200, Timo Rothenpieler wrote:
> On 24.04.2024 22:12, Alexander Strasser via ffmpeg-devel wrote:
> > On 2024-04-24 22:01 +0200, Timo Rothenpieler wrote:
> > > ---
> > > tests/fate.sh | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/tests/fate.sh b/tests/fate.sh
> > > index c5ee18de80..4081e865ae 100755
> > > --- a/tests/fate.sh
> > > +++ b/tests/fate.sh
> > > @@ -30,14 +30,14 @@ lock(){
> > > checkout(){
> > > case "$repo" in
> > > file:*|/*) src="${repo#file:}" ;;
> > > -git:*) git clone --quiet --branch "$branch" "$repo" "$src" ;;
> > > +git:*|https:*) git clone --quiet --branch "$branch" "$repo"
> > > "$src" ;;
> > > esac
> > > }
> > >
> > > update()(
> > > cd ${src} || return
> > > case "$repo" in
> > > -git:*) git fetch --quiet --force && git reset --quiet --hard
> > > "origin/$branch" ;;
> > > +git:*|https:*) git fetch --quiet --force && git reset --quiet
> > > --hard "origin/$branch" ;;
> > > esac
> > > )
> >
>
> If you manually clone the repo, you can use whatever you like anyway, since
Sorry my initial wording was probably ambiguous.
I meant in the repo variable in a fate_config.sh
> it never actually uses the URL for anything after the initial clone.
The URL isn't used per se, but it's used to decide whether to
git fetch or not inside the call to update, isn't it?
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] libavdevice: Improve example in deprecation message for opengl and sdl
When piping ffmpeg into ffplay both programs write a status line in the terminal. That causes flickering and invisibility of one or the other status line. As compromise set ffplay log level to warning, so it doesn't show the status line. The user is usually testing ffmpeg command lines and want's a preview of the result. This way the user can see the ffmpeg output and still see errors and warnings from ffplay, should they occur. Additionally set PTS to zero in ffplay to lessen the delay until the frames are displayed. Without it delay is quite observable when e.g. live capturing with low frame rates. --- Same as previous patch, but with setpts=0 in ffplay as suggested by Nicolas George. libavdevice/opengl_enc.c | 2 +- libavdevice/sdl2.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/libavdevice/opengl_enc.c b/libavdevice/opengl_enc.c index 6f7a30ff9e..93d3959880 100644 --- a/libavdevice/opengl_enc.c +++ b/libavdevice/opengl_enc.c @@ -1067,7 +1067,7 @@ static av_cold int opengl_write_header(AVFormatContext *h) av_log(opengl, AV_LOG_WARNING, "The opengl output device is deprecated due to being fundamentally incompatible with libavformat API. " "For monitoring purposes in ffmpeg you can output to a file or use pipes and a video player.\n" -"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -\n" +"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -loglevel warning -vf setpts=0 -\n" ); opengl->warned = 1; } diff --git a/libavdevice/sdl2.c b/libavdevice/sdl2.c index 779c8e08b0..491c8dafe8 100644 --- a/libavdevice/sdl2.c +++ b/libavdevice/sdl2.c @@ -167,7 +167,7 @@ static int sdl2_write_header(AVFormatContext *s) av_log(sdl, AV_LOG_WARNING, "The sdl output device is deprecated due to being fundamentally incompatible with libavformat API. " "For monitoring purposes in ffmpeg you can output to a file or use pipes and a video player.\n" -"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -\n" +"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -loglevel warning -vf setpts=0 -\n" ); sdl->warned = 1; } -- ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavdevice: Improve example in deprecation message for opengl and sdl
On 2024-04-14 21:24 +0200, Nicolas George wrote: > Nicolas George (12024-04-14): > > Either we find options to make ffplay display frames as fast as > > possible, or we must document to the user that no adequate replacement > > exists. > > Please add “-vf setpts=0”. It still has a little more latency than a > built-in device, but at least the feature is not *completely* broken. Thank for your feedback. I sent a v2 with `-vf setpts=0`. > > Or we make a point of fixing the devices that were broken. > > We still should. As long as we are not able to get it fixed, an improved suggestion in the deprecation message seems better than what we have now. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] configure: support msvc build inside WSL
On 2024-04-27 22:14 +0200, Timo Rothenpieler wrote:
> ---
> configure | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/configure b/configure
> index 8101b4fce6..89af5f75e7 100755
> --- a/configure
> +++ b/configure
> @@ -5036,7 +5036,12 @@ probe_cc(){
> else
> _ident=$($_cc --version 2>/dev/null | head -n1 | tr -d '\r')
> fi
> -_DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< 2>&1 | awk
> '\''/including/ { sub(/^.*file: */, ""); gsub(/\\/, "/"); if (!match($$0, /
> /)) print "$@:", $$0 }'\'' > $(@:.o=.d)'
> +if [ -x "$(command -v wslpath)" ]; then
> +_DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< 2>&1 |
> awk '\''/including/ { sub(/^.*file: */, ""); if (!match($$0, / /)) { print
> $$0 } }'\'' | xargs -d\\n -n1 wslpath -u | awk '\''BEGIN { printf "%s:", "$@"
> }; { sub(/\r/,""); printf " %s", $$0 }; END { print "" }'\'' > $(@:.o=.d)'
> +
> +else
> +_DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< 2>&1 |
> awk '\''/including/ { sub(/^.*file: */, ""); gsub(/\\/, "/"); if (!match($$0,
> / /)) print "$@:", $$0 }'\'' > $(@:.o=.d)'
> +fi
> _DEPFLAGS='$(CPPFLAGS) $(CFLAGS) -showIncludes -Zs'
> _cflags_speed="-O2"
> _cflags_size="-O1"
> --
Should be good enough if it doesn't break MSVC builds outside of WSL.
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/bsf: add a showinfo filter
On 2024-01-29 19:42 +0100, Anton Khirnov wrote:
[...]
> --- a/doc/bitstream_filters.texi
> +++ b/doc/bitstream_filters.texi
> @@ -887,6 +887,10 @@ For example, to set PTS equal to DTS (not recommended if
> B-frames are involved):
> ffmpeg -i INPUT -c:a copy -bsf:a setts=pts=DTS out.mkv
> @end example
>
> +@section showinfo
> +Log basic packet information. Mainly useful for testing, debugging,
> +and development.
> +
Maybe it's a good idea to state something about the stability of
the output format. I assume it's to be treated like other logging
and is not expected to stay stable. Not sure how much it helps to
state it clearly, but it can't hurt IMHO.
[...]
> --- /dev/null
> +++ b/libavcodec/bsf/showinfo.c
[...]
> +static int showinfo_filter(AVBSFContext *ctx, AVPacket *pkt)
> +{
> +ShowinfoContext *priv = ctx->priv_data;
> +
> +while (1) {
> +int ret;
> +
> +ret = ff_bsf_get_packet_ref(ctx, pkt);
> +if (ret < 0)
> +return ret;
> +
> +av_log(ctx, AV_LOG_INFO,
> + "n:%7"PRIu64" "
> + "size:%7d "
> + "pts:%s pt:%s "
> + "dts:%s dt:%s "
> + "ds:%"PRId64" d:%s "
> + "\n",
> + priv->nb_packets, pkt->size,
> + av_ts2str(pkt->pts), av_ts2timestr(pkt->pts,
> &ctx->time_base_in),
> + av_ts2str(pkt->dts), av_ts2timestr(pkt->dts,
> &ctx->time_base_in),
> + pkt->duration, av_ts2timestr(pkt->duration,
> &ctx->time_base_in));
> +
> +priv->nb_packets++;
> +
> +return 0;
> +}
> +}
It's late here and I surely must be missing something. Anyway,
why do we use a while loop here?
Best regards,
Alexander
[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec: remove sonic lossy/lossless audio
On 2024-02-28 19:36 +0100, Jean-Baptiste Kempf wrote: > > On Wed, 28 Feb 2024, at 18:55, James Almer wrote: > > On 2/28/2024 10:31 AM, J. Dekker wrote: > >> > >> Michael Niedermayer writes: > >> > >>> [[PGP Signed Part:Undecided]] > >>> On Wed, Feb 28, 2024 at 01:56:10PM +0100, J. Dekker wrote: > This was an experimental/research codec of which ffmpeg is the only > encoder and decoder, > >>> > >>> > development has stalled > >>> > >>> Thats not true, there was private dicussion making sonic the most > >>> advanced audio codec in FFmpeg a few months ago. > >>> Iam not saying that will happen, i am just saying there was a > >>> discussion about it. And that iam in principle interrested in > >>> working on this. Its possible i will not have enough time ... > >>> > >> > >> The last commit which actually changed the codec was > >> 6026a5ad4f135476c7a1f51f8cfa7f4cc2ca0283 by you in 2013 which is over 10 > >> years ago. For an experimental codec I think it's pretty safe to say > >> that development has stalled. > >> > >> Keeping the codec around based on 'what if?'s doesn't seem > >> reasonable. Besides, if you do make sonic the most advanced audio codec > >> in FFmpeg there's nothing which says you couldn't re-add it at a later > >> date when it's being actively developed again. > > > > Does it hurt keeping it around? If it can at some point be developed > > again, then removing the codec id to re-add it later will be a bit dirty. > > > > IMO, just disable both modules by default during configure, or tag the > > encoder as experimental to prevent new streams to be created unless > > explicitly requested knowing that it's an unfinished format. > > +1 +1 But if it stays it should be regularly compiled (at least on a fate client). Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] libavdevice: Improve example in deprecation message for opengl and sdl
On 2024-06-02 11:27 +0200, Alexander Strasser via ffmpeg-devel wrote: > On 2024-04-29 23:53 +0200, Alexander Strasser via ffmpeg-devel wrote: > > When piping ffmpeg into ffplay both programs write a status line in > > the terminal. That causes flickering and invisibility of one or the > > other status line. > > > > As compromise set ffplay log level to warning, so it doesn't show > > the status line. > > > > The user is usually testing ffmpeg command lines and want's a > > preview of the result. This way the user can see the ffmpeg output > > and still see errors and warnings from ffplay, should they occur. > > > > Additionally set PTS to zero in ffplay to lessen the delay until > > the frames are displayed. Without it delay is quite observable > > when e.g. live capturing with low frame rates. > > --- > > > > Same as previous patch, but with setpts=0 in ffplay as suggested by > > Nicolas George. > > > > > > libavdevice/opengl_enc.c | 2 +- > > libavdevice/sdl2.c | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/libavdevice/opengl_enc.c b/libavdevice/opengl_enc.c > > index 6f7a30ff9e..93d3959880 100644 > > --- a/libavdevice/opengl_enc.c > > +++ b/libavdevice/opengl_enc.c > > @@ -1067,7 +1067,7 @@ static av_cold int > > opengl_write_header(AVFormatContext *h) > > av_log(opengl, AV_LOG_WARNING, > > "The opengl output device is deprecated due to being > > fundamentally incompatible with libavformat API. " > > "For monitoring purposes in ffmpeg you can output to a file or > > use pipes and a video player.\n" > > -"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -\n" > > +"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay > > -loglevel warning -vf setpts=0 -\n" > > ); > > opengl->warned = 1; > > } > > diff --git a/libavdevice/sdl2.c b/libavdevice/sdl2.c > > index 779c8e08b0..491c8dafe8 100644 > > --- a/libavdevice/sdl2.c > > +++ b/libavdevice/sdl2.c > > @@ -167,7 +167,7 @@ static int sdl2_write_header(AVFormatContext *s) > > av_log(sdl, AV_LOG_WARNING, > > "The sdl output device is deprecated due to being > > fundamentally incompatible with libavformat API. " > > "For monitoring purposes in ffmpeg you can output to a file or > > use pipes and a video player.\n" > > -"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -\n" > > +"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay > > -loglevel warning -vf setpts=0 -\n" > > ); > > sdl->warned = 1; > > } > > -- > > > Will try to push soon'ish if I don't hear any objections. Finally pushed. Was way more "ish" than "soon"... Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/imgutils: av_image_check_size2() ensure width and height fit in 32bit
On 2024-07-10 15:51 +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2024-07-10 15:44:47) > > Do you still object to a 32bit check on width and height ? > > If not i intend to apply a patch adding such limits > > If you object i will take this to the TC > > In my first reply in this thread I asked for a very simple thing - > justify this commit, as the commit message provided ZERO arguments for > why is this done and what it actually improves. > > Instead of answering the question you keep painting ever wordier walls > of text. I'm not reading all that. Just answer the question, in the form > suitable for a commit message. As most of the time a communications problem AFAICS :( The answer Anton was probably looking for: The intention of av_image_check_size2 (and it it's predecessors) always was to use a bigger integer type (64bit) to check width and height fit into the limits of the next smaller integer type (32bit). Unfortunately it wasn't spelled out explicitly in the commit message back then, and the implementation incorrectly assumed that INT_MAX would always refer to 32bit signed max. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] libavcodec/dnxuc_parser: Use av_fourcc2str instead of av_fourcc_make_string
On 2024-10-12 23:36 +0200, martin schitter wrote: > On 12.10.24 23:18, epira...@gmail.com wrote: > > Maybe just squash them into one commit. > > Yes -- this looks like the most desirable solution. > > And thanks to Alex for the suggested improvement! Thank you Martin and Marvin for the quick response! Pushed a squashed version with a reworded commit message. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] lavc/dnxuc_parser: Adhere to av_fourcc_make_string API
The documentation of av_fourcc_make_string states the passed in
buffer must be of at least the size of AV_FOURCC_MAX_STRING_SIZE
Also move the buffer into inner scope where it is used.
Fixes: CID 1632380
---
libavcodec/dnxuc_parser.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/dnxuc_parser.c b/libavcodec/dnxuc_parser.c
index 55d576345c..896758c794 100644
--- a/libavcodec/dnxuc_parser.c
+++ b/libavcodec/dnxuc_parser.c
@@ -68,7 +68,6 @@ static int dnxuc_parse(AVCodecParserContext *s,
const uint8_t **poutbuf, int *poutbuf_size,
const uint8_t *buf, int buf_size)
{
-char fourcc_buf[5];
const int HEADER_SIZE = 37;
int icmp_offset = 0;
@@ -96,6 +95,8 @@ static int dnxuc_parse(AVCodecParserContext *s,
pc->nr_bytes = AV_RL32(buf+29+icmp_offset) - 8;
if (!avctx->codec_tag) {
+char fourcc_buf[AV_FOURCC_MAX_STRING_SIZE];
+
av_fourcc_make_string(fourcc_buf, pc->fourcc_tag);
av_log(avctx, AV_LOG_INFO, "dnxuc_parser: '%s' %dx%d %dbpp %d\n",
fourcc_buf,
--
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] libavcodec/dnxuc_parser: Use av_fourcc2str instead of av_fourcc_make_string
The string representation of the FourCC is only used once for logging.
---
Could also merge this with the first patch in this series and make
it a single patch.
Or drop this one.
I don't have a strong opinion on these details.
libavcodec/dnxuc_parser.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/libavcodec/dnxuc_parser.c b/libavcodec/dnxuc_parser.c
index 896758c794..12472c7a2d 100644
--- a/libavcodec/dnxuc_parser.c
+++ b/libavcodec/dnxuc_parser.c
@@ -95,11 +95,8 @@ static int dnxuc_parse(AVCodecParserContext *s,
pc->nr_bytes = AV_RL32(buf+29+icmp_offset) - 8;
if (!avctx->codec_tag) {
-char fourcc_buf[AV_FOURCC_MAX_STRING_SIZE];
-
-av_fourcc_make_string(fourcc_buf, pc->fourcc_tag);
av_log(avctx, AV_LOG_INFO, "dnxuc_parser: '%s' %dx%d %dbpp %d\n",
-fourcc_buf,
+av_fourcc2str(pc->fourcc_tag),
pc->width, pc->height,
(pc->nr_bytes*8)/(pc->width*pc->height),
pc->nr_bytes);
--
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/4] fftools/opt_common: stop accessing a private field
On 2024-10-14 19:22 +0200, Anton Khirnov wrote:
> Quoting Alexander Strasser via ffmpeg-devel (2024-10-14 18:27:24)
> > On 2024-10-14 17:52 +0200, Michael Niedermayer wrote:
> > > On Mon, Oct 14, 2024 at 01:36:46PM +0200, Anton Khirnov wrote:
> > > > ---
> > > > fftools/opt_common.c | 4 +---
> > > > 1 file changed, 1 insertion(+), 3 deletions(-)
> > > >
> > > > diff --git a/fftools/opt_common.c b/fftools/opt_common.c
> > > > index 021ed75272..34da2cee7d 100644
> > > > --- a/fftools/opt_common.c
> > > > +++ b/fftools/opt_common.c
> > > > @@ -808,7 +808,6 @@ int show_filters(void *optctx, const char *opt,
> > > > const char *arg)
> > > > printf("Filters:\n"
> > > > " T.. = Timeline support\n"
> > > > " .S. = Slice threading\n"
> > > > - " ..C = Command support\n"
> > > > " A = Audio input/output\n"
> > > > " V = Video input/output\n"
> > > > " N = Dynamic number and/or type of input/output\n"
> > > > @@ -833,10 +832,9 @@ int show_filters(void *optctx, const char *opt,
> > > > const char *arg)
> > > >( i && (filter->flags &
> > > > AVFILTER_FLAG_DYNAMIC_OUTPUTS))) ? 'N' : '|';
> > > > }
> > > > *descr_cur = 0;
> > > > -printf(" %c%c%c %-17s %-10s %s\n",
> > > > +printf(" %c%c %-17s %-10s %s\n",
> > > > filter->flags & AVFILTER_FLAG_SUPPORT_TIMELINE ? 'T' :
> > > > '.',
> > > > filter->flags & AVFILTER_FLAG_SLICE_THREADS? 'S' :
> > > > '.',
> > > > - filter->process_command? 'C' :
> > > > '.',
> > > > filter->name, descr, filter->description);
> > > > }
> > > > #else
> > >
> > > The commit message is not describing this change accurately
> > >
> > > Its not just "not accessing a priavte field", it removes information
> > > from the printed filter list
> >
> > Learning question: How can we see this is a private field?
>
> It is documented in the header.
I figured as much but couldn't find a hint in in avfilter.h
You changed it in a previous patch of this series or am I reading it wrong?
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/4] fftools/opt_common: stop accessing a private field
On 2024-10-14 22:35 +0200, Anton Khirnov wrote: > Quoting Alexander Strasser via ffmpeg-devel (2024-10-14 22:21:38) > > > It is documented in the header. > > > > I figured as much but couldn't find a hint in in avfilter.h > > > > You changed it in a previous patch of this series or am I reading it wrong? > > I don't follow, I changed what? No, I don't mean you did sth. I'm just too stupid to read where in avfilter.h it is documented to be private. So I'm asking what is written where that indicates this. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/4] fftools/opt_common: stop accessing a private field
On 2024-10-15 10:37 +0200, epira...@gmail.com wrote: > > > On 15 Oct 2024, at 10:30, Anton Khirnov wrote: > > > Quoting Alexander Strasser via ffmpeg-devel (2024-10-15 07:34:26) > >> On 2024-10-14 22:35 +0200, Anton Khirnov wrote: > >>> Quoting Alexander Strasser via ffmpeg-devel (2024-10-14 22:21:38) > >>>>> It is documented in the header. > >>>> > >>>> I figured as much but couldn't find a hint in in avfilter.h > >>>> > >>>> You changed it in a previous patch of this series or am I reading it > >>>> wrong? > >>> > >>> I don't follow, I changed what? > >> > >> No, I don't mean you did sth. > >> > >> I'm just too stupid to read where in avfilter.h it is documented > >> to be private. > >> > >> So I'm asking what is written where that indicates this. > > > > Here: > > http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/avfilter.h;h=b88b31a834094f15d3159b017438499f1809b82f;hb=HEAD#l247 > > > > Of course experience shows that such warnings do not really work, as > > users ignore or fail to notice them. > > Yes because approaches like „everything below this line“ > falls apart horribly in Doxygen as it is completely lost there. > > Same for IntelliSense-like things in editors. Thanks Anton for pointing to the exact line. Now it all makes sense. I was looking at the header and the AVFilter struct multiple times. First at the beginning of the struct, then searching and later out of paranoia paging up and down. The thing is, I didn't expect nor see that comment as it was just somewhere in between and looking like documentation of some other field. Then I went to the HTML rendered by Doxygen and like epirat07 pointed out, of course couldn't find any hint either... > > Which is why we have been switching > > to an approach that outright removes private information from public > > headers, but that first requires to eliminate its use. Sure, I agree to that direction. Still that functionality is useful and while it can be improved I would hope for a solution that doesn't drop the feature now and hopes for it to comeback at some later point. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/4] fftools/opt_common: stop accessing a private field
On 2024-10-15 15:09 +0200, Anton Khirnov wrote: > Quoting James Almer (2024-10-15 14:54:08) > > On 10/15/2024 6:57 AM, Anton Khirnov wrote: > > > avfilter_process_command() may or may not return ENOSYS whether that > > > flag is set or not, so I don't see what exactly would it be useful for. > > > > I see, although I wouldn't expect ENOSYS for any other case than > > "unsupported". If a command fails, imo it would be EINVAL, or maybe ENOMEM. > > Correct, but > * some commands work on all filters; for now it's just "ping", but we > can add more in the future; > * the "enable" command works on all filters flagged with > AVFILTER_FLAG_SUPPORT_TIMELINE; again, we may add more such > "semi-generic" commands in the future; > * filters that do implement the process_command() callback will still > return ENOSYS when you send them a command they do not support. > > So checking for the existence of process_command() does not really tell > you anything specific, and the same would hold for the hypothetical flag > that would replace it. > > > > > > Same holds for printing the capability in fftools - just what is the > > > user expected to do with that information? > > > > Know they can use the send command interrupt for a given filter without > > having it unconditionally fail, i guess. But for that matter, is the > > list of supported commands available anywhere for the user? Is there an > > API to query them, or is it expected to be only in the documentation? > > If there's no API, then maybe printing this is pointless. > > There is no such API, which I agree would be useful - but if it did > exist we would again not need the flag. For me that flag is more about if some filter brings commands of its own. Generic stuff that we will add should not be indicated with the C flag. Though adding more flags for the generic stuff like we have with T now should be fine for some time to come before it gets unwieldy. Listing and querying of filter caps has much room for improvement, but as long as no one has particular interest in doing that, at least I don't see it as very important right now. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] configure: suggest installing nasm/yasm before using --disable-x86asm
On 2024-10-03 04:04 +0200, Lynne via ffmpeg-devel wrote: > On 01/10/2024 15:24, vipyne wrote: > > --- > > configure | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/configure b/configure > > index c8fb49a7a4..d178ef59dc 100755 > > --- a/configure > > +++ b/configure > > @@ -6460,7 +6460,7 @@ EOF > > for program in $x86asmexe nasm yasm; do > > probe_x86asm $program && break > > done > > -disabled x86asm && die "nasm/yasm not found or too old. Use > > --disable-x86asm for a crippled build." > > +disabled x86asm && die "nasm/yasm not found or too old. Please > > install/update nasm or yasm or use --disable-x86asm for a slower build." > > X86ASMFLAGS="-f $objformat" > > test -n "$extern_prefix" && append X86ASMFLAGS "-DPREFIX" > > case "$objformat" in > > Could you remove the yasm mention? Its been holding us back and we've > discussed dropping support for it enough in recent time to go ahead and do > it any day now. > Otherwise LGTM. No opinion on yasm, but IMHO the new wording proposal regarding the build is a little bit ambigous. What do you think about the following? ...use --disable-x86asm for a build without hand-optimized assembly. I would hope it's clearer and more precise. Best regards, Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [RFC PATCH 3/2] FIXUP
--- Sorry I forgot this fixup to the previous patch, that I had in my work tree but not committed... tests/fate-run.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/fate-run.sh b/tests/fate-run.sh index 72251ec571..bed8f7127c 100755 --- a/tests/fate-run.sh +++ b/tests/fate-run.sh @@ -652,7 +652,7 @@ if test -e "$ref" || test $cmp = "oneline" || test $cmp = "null" || test $cmp = null) cat "$outfile">$cmpfile ;; esac cmperr=$? -if test -e "$ref".alt && !(test $cmp = "oneline" || test $cmp = "null" || test $cmp = "grep") ; then +if test $cmperr != 0 && test -e "$ref".alt && !(test $cmp = "oneline" || test $cmp = "null" || test $cmp = "grep") ; then case $cmp in diff) diff -u -b "$ref".alt "$outfile">$cmpfile ;; rawdiff)diff -u"$ref".alt "$outfile">$cmpfile ;; -- ___ ffmpeg-devel mailing list ffmpeg-devel@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] [RFC PATCH 1/2] Reapply "tests/fate: disable compression for zlib-based codecs"
The problems that caused the revert will be fixed with the follow-up change right after this commit. This reverts commit e206e72b83a0e512e21694a43af4df2b53f6d045. --- tests/fate/cover-art.mak | 6 ++-- tests/fate/image.mak | 4 +-- tests/fate/lavf-image.mak | 5 +-- tests/fate/lavf-video.mak | 4 +-- tests/fate/mov.mak| 2 +- tests/fate/vcodec.mak | 4 ++- tests/ref/fate/copy-apng | 4 +-- tests/ref/fate/cover-art-aiff-id3v2-remux | 6 ++-- tests/ref/fate/cover-art-flac-remux | 6 ++-- tests/ref/fate/cover-art-mp3-id3v2-remux | 6 ++-- tests/ref/fate/mov-cover-image| 6 ++-- tests/ref/fate/png-icc| 6 ++-- tests/ref/fate/png-mdcv | 4 +-- tests/ref/lavf/apng | 4 +-- tests/ref/lavf/apng.png | 4 +-- tests/ref/lavf/gray16be.png | 4 +-- tests/ref/lavf/png| 4 +-- tests/ref/lavf/rgb48be.png| 4 +-- tests/ref/seek/vsynth_lena-flashsv| 40 +++ tests/ref/vsynth/vsynth1-flashsv | 4 +-- tests/ref/vsynth/vsynth1-mpng | 4 +-- tests/ref/vsynth/vsynth1-zlib | 4 +-- tests/ref/vsynth/vsynth2-flashsv | 4 +-- tests/ref/vsynth/vsynth2-mpng | 4 +-- tests/ref/vsynth/vsynth2-zlib | 4 +-- tests/ref/vsynth/vsynth3-flashsv | 4 +-- tests/ref/vsynth/vsynth3-mpng | 4 +-- tests/ref/vsynth/vsynth3-zlib | 4 +-- tests/ref/vsynth/vsynth_lena-flashsv | 4 +-- tests/ref/vsynth/vsynth_lena-mpng | 4 +-- tests/ref/vsynth/vsynth_lena-zlib | 4 +-- 31 files changed, 87 insertions(+), 84 deletions(-) diff --git a/tests/fate/cover-art.mak b/tests/fate/cover-art.mak index faa2182745..7f8958e33f 100644 --- a/tests/fate/cover-art.mak +++ b/tests/fate/cover-art.mak @@ -37,14 +37,14 @@ FATE_COVER_ART_REMUX-$(call ALLYES, FILE_PROTOCOL FLAC_DEMUXER MJPEG_DECODER \ AIFF_DEMUXER BMP_DECODER PNG_DECODER \ FRAMECRC_MUXER PIPE_PROTOCOL)\ += fate-cover-art-aiff-id3v2-remux -fate-cover-art-aiff-id3v2-remux: CMD = transcode flac $(TARGET_SAMPLES)/cover_art/cover_art.flac aiff "-map 0 -map 0:v -map 0:v -map 0:v -c:a pcm_s16be -c:v:0 copy -filter:v:1 scale -c:v:1 png -filter:v:2 scale -c:v:2 bmp -c:v:3 copy -write_id3v2 1 -metadata:g unknown_key=unknown_value -metadata compilation=foo -metadata:s:v:0 title=first -metadata:s:v:1 title=second -metadata:s:v:1 comment=Illustration -metadata:s:v:2 title=third -metadata:s:v:2 comment=Conductor -metadata:s:v:3 title=fourth -metadata:s:v:3 comment=Composer" "-map 0 -c copy -t 0.1" "-show_entries format_tags:stream_tags:stream_disposition=attached_pic:stream=index,codec_name" +fate-cover-art-aiff-id3v2-remux: CMD = transcode flac $(TARGET_SAMPLES)/cover_art/cover_art.flac aiff "-map 0 -map 0:v -map 0:v -map 0:v -c:a pcm_s16be -c:v:0 copy -filter:v:1 scale -c:v:1 png -compression_level:v:1 0 -filter:v:2 scale -c:v:2 bmp -c:v:3 copy -write_id3v2 1 -metadata:g unknown_key=unknown_value -metadata compilation=foo -metadata:s:v:0 title=first -metadata:s:v:1 title=second -metadata:s:v:1 comment=Illustration -metadata:s:v:2 title=third -metadata:s:v:2 comment=Conductor -metadata:s:v:3 title=fourth -metadata:s:v:3 comment=Composer" "-map 0 -c copy -t 0.1" "-show_entries format_tags:stream_tags:stream_disposition=attached_pic:stream=index,codec_name" FATE_COVER_ART_REMUX-$(call ALLYES, FILE_PROTOCOL MP3_DEMUXER MJPEG_DECODER \ SCALE_FILTER PNG_ENCODER BMP_ENCODER\ MP3_MUXER BMP_DECODER PNG_DECODER \ FRAMECRC_MUXER PIPE_PROTOCOL) \ += fate-cover-art-mp3-id3v2-remux -fate-cover-art-mp3-id3v2-remux: CMD = transcode mp3 $(TARGET_SAMPLES)/exif/embedded_small.mp3 mp3 "-map 0 -map 0:v -map 0:v -c:a copy -filter:v:0 scale -filter:v:2 scale -c:v:0 bmp -c:v:1 copy -c:v:2 png -metadata:s:v:0 comment=Band/Orchestra" "-map 0 -c copy -t 0.1" "-show_entries stream_tags:stream_disposition=attached_pic:stream=index,codec_name" +fate-cover-art-mp3-id3v2-remux: CMD = transcode mp3 $(TARGET_SAMPLES)/exif/embedded_small.mp3 mp3 "-map 0 -map 0:v -map 0:v -c:a copy -filter:v:0 scale -filter:v:2 scale -c:v:0 bmp -c:v:1 copy -c:v:2 png -compression_level:v:2 0 -metadata:s:v:0 comment=Band/Orchestra" "-map 0 -c copy -t 0.1" "-show_entries stream_tags:stream_disposition=attached_pic:stream=index,codec_name" # Also covers muxing and demuxing of nonstandard channel layouts into FLAC # as well as the unorthodox multi_dim_quant option of the FLAC encoder. @@ -55,7 +55,7 @@ FATE_COVER_ART_REMUX-$(call
Re: [FFmpeg-devel] [RFC PATCH 0/2] Make fate tests succeed with zlib-ng
On 2024-10-18 21:02 +0200, Michael Niedermayer wrote: > On Fri, Oct 18, 2024 at 02:02:48PM +0200, Alexander Strasser via ffmpeg-devel > wrote: > > This is as subject notes an RFC. I wanted to send it out quickly. > > Didn't actually test on zlib systems yet (old and new). > > > > So it is not that heavily tested yet and maybe has rough edges I > > didn't notice. > > > > I hope this would help to unbreak zlib-ng systems and not disturb > > systems with older zlib versions. > > > > The strategy is > > > > 1. re-apply Ramiro's patch to use compression level 0 > > 2. fix the 2 tests that fail with older zlib with extra ref file > > > > The mechanism should only be used when other solutions are not > > available. The alternative files could be dropped in the future > > e.g. when no more fate clients fail because of it. [...] > --- ./tests/ref/fate/mov-cover-image.alt 2024-10-18 20:58:45.047495704 > +0200 > +++ tests/data/fate/mov-cover-image 2024-10-18 20:59:42.975941144 +0200 > @@ -20,7 +20,7 @@ > 0, -1088, -1088, 1024,6, 0x027e00e8, F=0x5 > 0,-64,-64, 1024,6, 0x027e00e8 > 1, 0, 0,0,25441, 0xe82503b0 > -2, 0, 0,0, 1084000, 0x70fc8139 > +2, 0, 0,0, 1084000, 0x413c7ee9 > 0,960,960, 1024,6, 0x027e00e8 > 0, 1984, 1984, 1024,6, 0x027e00e8 > 0, 3008, 3008, 1024,6, 0x027e00e8 > Test mov-cover-image failed. Look at tests/data/fate/mov-cover-image.err for > details. > make: *** [tests/Makefile:311: fate-mov-cover-image] Error 1 Ah sorry, my bad. I forgot to apply the second hunk of the diff to the .alt ref file. I would assume with that change added it should work. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/4] fftools/opt_common: stop accessing a private field
On 2024-10-18 13:16 +0200, Anton Khirnov wrote: > Quoting Alexander Strasser via ffmpeg-devel (2024-10-18 12:55:49) > > FTR and FWIW it was useful for me for identifying filters that can do > > more with commands than timeline enable/disable. > > And then what do you do with this list of filters? I look at the results of that query and look into those filters that interest me individually. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC PATCH 2/2] fate: Make it possible to have alternative reference files
On 2024-10-18 16:36 +0200, Lynne via ffmpeg-devel wrote: > On 18/10/2024 14:41, Hendrik Leppkes wrote: > > On Fri, Oct 18, 2024 at 2:09 PM Alexander Strasser via ffmpeg-devel > > wrote: > > > This caused differences > > > with 2 fate tests depending on the zlib version used. > > > > 2 fate tests? > > https://fate.ffmpeg.org/report.cgi?time=20241016173824&slot=x86_32-msvc14-dll-md-windows-native > > > > This entire approach feels extremely brittle for the future. > > > > - Hendrik > > Yeah, definitely. > These days, other libraries like miniz are getting used as well, so > hardcoding each case separately is no better than what we have currently. Hmm not sure about the build from Hendrik. This was with a build with zlib and compression level 0? What I tried to do and describe is to account for a bug in older zlib versions. I didn't want to have alternative refs for every implementation. I actually oppose to that! Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [RFC PATCH 2/2] fate: Make it possible to have alternative reference files
Sometimes deps (external from FFmpeg) can cause different results
either because of bugs or because of drop in replacements.
This feature of alternate reference files should only be used
where absolutely necessary because other solutions are not
feasible in practice. Maintaining two reference files is a
burden and updating one or the other can easily be forgotten.
We currently have this problem with zlib-ng. On systems where
the zlib-ng is used the results are different.
In commit bce5855afb25d318e090c2e6c16117f065458356 we avoided the
problem by using compression level 0. That fixed the problem, but
introduced a problem with original zlib. This caused differences
with 2 fate tests depending on the zlib version used.
See zlib commit 8ba393e70d984d902b15b9e6876f4d0d38ae4be8 .
After re-applying bce5855afb25d318e090c2e6c16117f065458356 this
patch fixes the 2 mentioned cases for older zlib versions by
allowing an alternative reference file. The files accommodate
for the bug in the older version.
---
tests/fate-run.sh | 10 +++
tests/ref/fate/mov-cover-image.alt | 42 ++
tests/ref/fate/png-mdcv.alt| 22
3 files changed, 74 insertions(+)
create mode 100644 tests/ref/fate/mov-cover-image.alt
create mode 100644 tests/ref/fate/png-mdcv.alt
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 309ab85134..72251ec571 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -652,6 +652,16 @@ if test -e "$ref" || test $cmp = "oneline" || test $cmp =
"null" || test $cmp =
null) cat "$outfile">$cmpfile ;;
esac
cmperr=$?
+if test -e "$ref".alt && !(test $cmp = "oneline" || test $cmp = "null" ||
test $cmp = "grep") ; then
+case $cmp in
+diff) diff -u -b "$ref".alt "$outfile">$cmpfile ;;
+rawdiff)diff -u"$ref".alt "$outfile">$cmpfile ;;
+oneoff) oneoff "$ref".alt "$outfile">$cmpfile ;;
+stddev) stddev "$ref".alt "$outfile">$cmpfile ;;
+esac
+cmperr=$?
+fi
+
test $err = 0 && err=$cmperr
if [ "$report_type" = "ignore" ]; then
test $err = 0 || echo "IGNORE\t${test}" && err=0 && unset sig
diff --git a/tests/ref/fate/mov-cover-image.alt
b/tests/ref/fate/mov-cover-image.alt
new file mode 100644
index 00..bb94b86939
--- /dev/null
+++ b/tests/ref/fate/mov-cover-image.alt
@@ -0,0 +1,42 @@
+ad553810e0ce362697a2b21544daebde *tests/data/fate/mov-cover-image.mp4
+2063262 tests/data/fate/mov-cover-image.mp4
+#extradata 0:2, 0x00340022
+#tb 0: 1/44100
+#media_type 0: audio
+#codec_id 0: aac
+#sample_rate 0: 44100
+#channel_layout_name 0: stereo
+#tb 1: 1/9
+#media_type 1: video
+#codec_id 1: mjpeg
+#dimensions 1: 600x600
+#sar 1: 96/96
+#tb 2: 1/9
+#media_type 2: video
+#codec_id 2: png
+#dimensions 2: 600x600
+#sar 2: 1/1
+0, -2112, -2112, 1024,6, 0x027e00e8, F=0x5, S=1, 10
+0, -1088, -1088, 1024,6, 0x027e00e8, F=0x5
+0,-64,-64, 1024,6, 0x027e00e8
+1, 0, 0,0,25441, 0xe82503b0
+2, 0, 0,0, 1084000, 0x70fc8139
+0,960,960, 1024,6, 0x027e00e8
+0, 1984, 1984, 1024,6, 0x027e00e8
+0, 3008, 3008, 1024,6, 0x027e00e8
+0, 4032, 4032, 1024,6, 0x027e00e8
+[STREAM]
+index=0
+codec_name=aac
+DISPOSITION:attached_pic=0
+[/STREAM]
+[STREAM]
+index=1
+codec_name=mjpeg
+DISPOSITION:attached_pic=1
+[/STREAM]
+[STREAM]
+index=2
+codec_name=png
+DISPOSITION:attached_pic=1
+[/STREAM]
diff --git a/tests/ref/fate/png-mdcv.alt b/tests/ref/fate/png-mdcv.alt
new file mode 100644
index 00..1339fe3a46
--- /dev/null
+++ b/tests/ref/fate/png-mdcv.alt
@@ -0,0 +1,22 @@
+b674209fd9cd8eff945a6bc1a4b306d3 *tests/data/fate/png-mdcv.image2pipe
+2774240 tests/data/fate/png-mdcv.image2pipe
+#tb 0: 1/25
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 1280x720
+#sar 0: 0/1
+0, 0, 0,1, 2764800, 0x2bfc7b42
+frames.frame.0.side_data_list.side_data.0.side_data_type="Content light level
metadata"
+frames.frame.0.side_data_list.side_data.0.max_content=1000
+frames.frame.0.side_data_list.side_data.0.max_average=200
+frames.frame.0.side_data_list.side_data.1.side_data_type="Mastering display
metadata"
+frames.frame.0.side_data_list.side_data.1.red_x="13250/5"
+frames.frame.0.side_data_list.side_data.1.red_y="7500/5"
+frames.frame.0.side_data_list.side_data.1.green_x="34000/5"
+frames.frame.0.side_data_list.side_data.1.green_y="16000/5"
+frames.frame.0.side_data_list.side_data.1.blue_x="2/5"
+frames.frame.0.side_data_list.side_data.1.blue_y="0/5"
+frames.frame.0.side_data_list.side_data.1.white_point_x="15635/5"
+frames.frame.0.side_data_list.side_data.1.white_point_y
[FFmpeg-devel] [RFC PATCH 0/2] Make fate tests succeed with zlib-ng
This is as subject notes an RFC. I wanted to send it out quickly. Didn't actually test on zlib systems yet (old and new). So it is not that heavily tested yet and maybe has rough edges I didn't notice. I hope this would help to unbreak zlib-ng systems and not disturb systems with older zlib versions. The strategy is 1. re-apply Ramiro's patch to use compression level 0 2. fix the 2 tests that fail with older zlib with extra ref file The mechanism should only be used when other solutions are not available. The alternative files could be dropped in the future e.g. when no more fate clients fail because of it. Best regards, Alexander Alexander Strasser (2): Reapply "tests/fate: disable compression for zlib-based codecs" fate: Make it possible to have alternative reference files tests/fate-run.sh | 10 ++ tests/fate/cover-art.mak | 6 ++-- tests/fate/image.mak | 4 +-- tests/fate/lavf-image.mak | 5 +-- tests/fate/lavf-video.mak | 4 +-- tests/fate/mov.mak| 2 +- tests/fate/vcodec.mak | 4 ++- tests/ref/fate/copy-apng | 4 +-- tests/ref/fate/cover-art-aiff-id3v2-remux | 6 ++-- tests/ref/fate/cover-art-flac-remux | 6 ++-- tests/ref/fate/cover-art-mp3-id3v2-remux | 6 ++-- tests/ref/fate/mov-cover-image| 6 ++-- tests/ref/fate/mov-cover-image.alt| 42 +++ tests/ref/fate/png-icc| 6 ++-- tests/ref/fate/png-mdcv | 4 +-- tests/ref/fate/png-mdcv.alt | 22 tests/ref/lavf/apng | 4 +-- tests/ref/lavf/apng.png | 4 +-- tests/ref/lavf/gray16be.png | 4 +-- tests/ref/lavf/png| 4 +-- tests/ref/lavf/rgb48be.png| 4 +-- tests/ref/seek/vsynth_lena-flashsv| 40 ++--- tests/ref/vsynth/vsynth1-flashsv | 4 +-- tests/ref/vsynth/vsynth1-mpng | 4 +-- tests/ref/vsynth/vsynth1-zlib | 4 +-- tests/ref/vsynth/vsynth2-flashsv | 4 +-- tests/ref/vsynth/vsynth2-mpng | 4 +-- tests/ref/vsynth/vsynth2-zlib | 4 +-- tests/ref/vsynth/vsynth3-flashsv | 4 +-- tests/ref/vsynth/vsynth3-mpng | 4 +-- tests/ref/vsynth/vsynth3-zlib | 4 +-- tests/ref/vsynth/vsynth_lena-flashsv | 4 +-- tests/ref/vsynth/vsynth_lena-mpng | 4 +-- tests/ref/vsynth/vsynth_lena-zlib | 4 +-- 34 files changed, 161 insertions(+), 84 deletions(-) create mode 100644 tests/ref/fate/mov-cover-image.alt create mode 100644 tests/ref/fate/png-mdcv.alt -- ___ ffmpeg-devel mailing list ffmpeg-devel@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 PATCH 0/2] Make fate tests succeed with zlib-ng
On 2024-10-18 15:55 +0100, Derek Buitenhuis wrote: > On 10/18/2024 1:02 PM, Alexander Strasser via ffmpeg-devel wrote: > > Alexander Strasser (2): > > Reapply "tests/fate: disable compression for zlib-based codecs" > > fate: Make it possible to have alternative reference files > > I want to add this here, since I brought it up on IRC. > > I think this entire saga has been pretty silly, and a workaround for > what is fundementally a bad test. Testing the exact contents and size > of encoded output here is fundementally the wrong thing to test and > provides no value as a test. I'd argue it provides negative value. > > For a lossles encoder, especially one that uses external deps, but this > applies to internal ones too, almost no value is provided by ensuring > that its output is bit-exact - I'd actually consider it negative value. [...] Regarding especially the general assertion, there is still the question: How should the tests be done? With which software? Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/hw_base_encode: fix use after free on close
On 2024-10-17 20:23 +0200, Marvin Scholz wrote:
> The way the linked list of images was freed caused a
> use after free, by accessing pic->next after pic was
> already freed.
>
> Regression from 48a1a12968345bf673db1e1cbb5c64bd3529c50c
>
> Fix CID1633236
> ---
> libavcodec/hw_base_encode.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
> index 912c707a68f..4d8bf4fe71d 100644
> --- a/libavcodec/hw_base_encode.c
> +++ b/libavcodec/hw_base_encode.c
> @@ -802,14 +802,14 @@ int ff_hw_base_encode_init(AVCodecContext *avctx,
> FFHWBaseEncodeContext *ctx)
> return 0;
> }
>
> int ff_hw_base_encode_close(FFHWBaseEncodeContext *ctx)
> {
> -FFHWBaseEncodePicture *pic;
> -
> -for (pic = ctx->pic_start; pic; pic = pic->next)
> +for (FFHWBaseEncodePicture *pic = ctx->pic_start, *next_pic = pic; pic;
> pic = next_pic) {
> +next_pic = pic->next;
> base_encode_pic_free(pic);
> +}
LGTM
I think it would be better to name next_pic just next.
So the line would look like:
next = pic->next;
That would be in line with the other 2 similar loops in the file.
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/4] fftools/opt_common: stop accessing a private field
On 2024-10-15 21:24 +0200, Anton Khirnov wrote: > Quoting Alexander Strasser via ffmpeg-devel (2024-10-15 21:05:54) > > Still that functionality is useful > > How is it useful? It gives you no actionable information. Seems this was just applied already. FTR and FWIW it was useful for me for identifying filters that can do more with commands than timeline enable/disable. Mostly changing filter options via commands. Not saying that the discoverability and help for filter commands cannot be improved further, but removing something that was already there does not help either. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/4] fftools/opt_common: stop accessing a private field
On 2024-10-14 17:52 +0200, Michael Niedermayer wrote:
> On Mon, Oct 14, 2024 at 01:36:46PM +0200, Anton Khirnov wrote:
> > ---
> > fftools/opt_common.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/fftools/opt_common.c b/fftools/opt_common.c
> > index 021ed75272..34da2cee7d 100644
> > --- a/fftools/opt_common.c
> > +++ b/fftools/opt_common.c
> > @@ -808,7 +808,6 @@ int show_filters(void *optctx, const char *opt, const
> > char *arg)
> > printf("Filters:\n"
> > " T.. = Timeline support\n"
> > " .S. = Slice threading\n"
> > - " ..C = Command support\n"
> > " A = Audio input/output\n"
> > " V = Video input/output\n"
> > " N = Dynamic number and/or type of input/output\n"
> > @@ -833,10 +832,9 @@ int show_filters(void *optctx, const char *opt, const
> > char *arg)
> >( i && (filter->flags &
> > AVFILTER_FLAG_DYNAMIC_OUTPUTS))) ? 'N' : '|';
> > }
> > *descr_cur = 0;
> > -printf(" %c%c%c %-17s %-10s %s\n",
> > +printf(" %c%c %-17s %-10s %s\n",
> > filter->flags & AVFILTER_FLAG_SUPPORT_TIMELINE ? 'T' : '.',
> > filter->flags & AVFILTER_FLAG_SLICE_THREADS? 'S' : '.',
> > - filter->process_command? 'C' : '.',
> > filter->name, descr, filter->description);
> > }
> > #else
>
> The commit message is not describing this change accurately
>
> Its not just "not accessing a priavte field", it removes information
> from the printed filter list
Learning question: How can we see this is a private field?
This information was useful. How can we bring it back if we decide it's
not OK too test if this field is NULL?
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 1/3] Reapply "tests/fate: disable compression for zlib-based codecs"
This reverts commit e206e72b83a0e512e21694a43af4df2b53f6d045. --- tests/fate/cover-art.mak | 6 ++-- tests/fate/image.mak | 4 +-- tests/fate/lavf-image.mak | 5 +-- tests/fate/lavf-video.mak | 4 +-- tests/fate/mov.mak| 2 +- tests/fate/vcodec.mak | 4 ++- tests/ref/fate/copy-apng | 4 +-- tests/ref/fate/cover-art-aiff-id3v2-remux | 6 ++-- tests/ref/fate/cover-art-flac-remux | 6 ++-- tests/ref/fate/cover-art-mp3-id3v2-remux | 6 ++-- tests/ref/fate/mov-cover-image| 6 ++-- tests/ref/fate/png-icc| 6 ++-- tests/ref/fate/png-mdcv | 4 +-- tests/ref/lavf/apng | 4 +-- tests/ref/lavf/apng.png | 4 +-- tests/ref/lavf/gray16be.png | 4 +-- tests/ref/lavf/png| 4 +-- tests/ref/lavf/rgb48be.png| 4 +-- tests/ref/seek/vsynth_lena-flashsv| 40 +++ tests/ref/vsynth/vsynth1-flashsv | 4 +-- tests/ref/vsynth/vsynth1-mpng | 4 +-- tests/ref/vsynth/vsynth1-zlib | 4 +-- tests/ref/vsynth/vsynth2-flashsv | 4 +-- tests/ref/vsynth/vsynth2-mpng | 4 +-- tests/ref/vsynth/vsynth2-zlib | 4 +-- tests/ref/vsynth/vsynth3-flashsv | 4 +-- tests/ref/vsynth/vsynth3-mpng | 4 +-- tests/ref/vsynth/vsynth3-zlib | 4 +-- tests/ref/vsynth/vsynth_lena-flashsv | 4 +-- tests/ref/vsynth/vsynth_lena-mpng | 4 +-- tests/ref/vsynth/vsynth_lena-zlib | 4 +-- 31 files changed, 87 insertions(+), 84 deletions(-) diff --git a/tests/fate/cover-art.mak b/tests/fate/cover-art.mak index faa2182745..7f8958e33f 100644 --- a/tests/fate/cover-art.mak +++ b/tests/fate/cover-art.mak @@ -37,14 +37,14 @@ FATE_COVER_ART_REMUX-$(call ALLYES, FILE_PROTOCOL FLAC_DEMUXER MJPEG_DECODER \ AIFF_DEMUXER BMP_DECODER PNG_DECODER \ FRAMECRC_MUXER PIPE_PROTOCOL)\ += fate-cover-art-aiff-id3v2-remux -fate-cover-art-aiff-id3v2-remux: CMD = transcode flac $(TARGET_SAMPLES)/cover_art/cover_art.flac aiff "-map 0 -map 0:v -map 0:v -map 0:v -c:a pcm_s16be -c:v:0 copy -filter:v:1 scale -c:v:1 png -filter:v:2 scale -c:v:2 bmp -c:v:3 copy -write_id3v2 1 -metadata:g unknown_key=unknown_value -metadata compilation=foo -metadata:s:v:0 title=first -metadata:s:v:1 title=second -metadata:s:v:1 comment=Illustration -metadata:s:v:2 title=third -metadata:s:v:2 comment=Conductor -metadata:s:v:3 title=fourth -metadata:s:v:3 comment=Composer" "-map 0 -c copy -t 0.1" "-show_entries format_tags:stream_tags:stream_disposition=attached_pic:stream=index,codec_name" +fate-cover-art-aiff-id3v2-remux: CMD = transcode flac $(TARGET_SAMPLES)/cover_art/cover_art.flac aiff "-map 0 -map 0:v -map 0:v -map 0:v -c:a pcm_s16be -c:v:0 copy -filter:v:1 scale -c:v:1 png -compression_level:v:1 0 -filter:v:2 scale -c:v:2 bmp -c:v:3 copy -write_id3v2 1 -metadata:g unknown_key=unknown_value -metadata compilation=foo -metadata:s:v:0 title=first -metadata:s:v:1 title=second -metadata:s:v:1 comment=Illustration -metadata:s:v:2 title=third -metadata:s:v:2 comment=Conductor -metadata:s:v:3 title=fourth -metadata:s:v:3 comment=Composer" "-map 0 -c copy -t 0.1" "-show_entries format_tags:stream_tags:stream_disposition=attached_pic:stream=index,codec_name" FATE_COVER_ART_REMUX-$(call ALLYES, FILE_PROTOCOL MP3_DEMUXER MJPEG_DECODER \ SCALE_FILTER PNG_ENCODER BMP_ENCODER\ MP3_MUXER BMP_DECODER PNG_DECODER \ FRAMECRC_MUXER PIPE_PROTOCOL) \ += fate-cover-art-mp3-id3v2-remux -fate-cover-art-mp3-id3v2-remux: CMD = transcode mp3 $(TARGET_SAMPLES)/exif/embedded_small.mp3 mp3 "-map 0 -map 0:v -map 0:v -c:a copy -filter:v:0 scale -filter:v:2 scale -c:v:0 bmp -c:v:1 copy -c:v:2 png -metadata:s:v:0 comment=Band/Orchestra" "-map 0 -c copy -t 0.1" "-show_entries stream_tags:stream_disposition=attached_pic:stream=index,codec_name" +fate-cover-art-mp3-id3v2-remux: CMD = transcode mp3 $(TARGET_SAMPLES)/exif/embedded_small.mp3 mp3 "-map 0 -map 0:v -map 0:v -c:a copy -filter:v:0 scale -filter:v:2 scale -c:v:0 bmp -c:v:1 copy -c:v:2 png -compression_level:v:2 0 -metadata:s:v:0 comment=Band/Orchestra" "-map 0 -c copy -t 0.1" "-show_entries stream_tags:stream_disposition=attached_pic:stream=index,codec_name" # Also covers muxing and demuxing of nonstandard channel layouts into FLAC # as well as the unorthodox multi_dim_quant option of the FLAC encoder. @@ -55,7 +55,7 @@ FATE_COVER_ART_REMUX-$(call ALLYES, FILE_PROTOCOL MOV_DEMUXER OGG_DEMUXER \ FLAC_MUXER FL
[FFmpeg-devel] [PATCH v2 2/3] fate: Make it possible to have alternative reference files
Sometimes deps (external from FFmpeg) can cause different results
either because of bugs or because of drop in replacements.
This feature of alternate reference files should only be used
where absolutely necessary because other solutions are not
feasible in practice. Maintaining two reference files is a
burden and updating one or the other can easily be forgotten.
Signed-off-by: Alexander Strasser
---
tests/fate-run.sh | 10 ++
1 file changed, 10 insertions(+)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index c61a4dc992..5e9acb253d 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -687,6 +687,16 @@ if test -e "$ref" || test $cmp = "oneline" || test $cmp =
"null" || test $cmp =
null) cat "$outfile">$cmpfile ;;
esac
cmperr=$?
+if test $cmperr != 0 && test -e "$ref".alt && !(test $cmp = "oneline" ||
test $cmp = "null" || test $cmp = "grep") ; then
+case $cmp in
+diff) diff -u -b "$ref".alt "$outfile">$cmpfile ;;
+rawdiff)diff -u"$ref".alt "$outfile">$cmpfile ;;
+oneoff) oneoff "$ref".alt "$outfile">$cmpfile ;;
+stddev) stddev "$ref".alt "$outfile">$cmpfile ;;
+esac
+cmperr=$?
+fi
+
test $err = 0 && err=$cmperr
if [ "$report_type" = "ignore" ]; then
test $err = 0 || echo "IGNORE\t${test}" && err=0 && unset sig
--
___
ffmpeg-devel mailing list
ffmpeg-devel@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 v2 0/3] Make fate tests succeed with zlib-ng
This is a fixed up version of the series I sent before. This worked for me on Ubuntu 20.04 but probably will break with older zlib versions as Hendrik pointed out in the previous thread. Either we must update zlib on affected FATE clients or add more .alt files to them as well. We could also go the further the "no_file_checksums" as was demonstrated by James' series. I still prefer this way because it's simpler and retains the value of the tests. Of course I'm not opposing to implement zlib compression in FFmpeg, but until that happens FATE should also work on zlib-ng systems IMHO. Best regards, Alexander Alexander Strasser (3): Reapply "tests/fate: disable compression for zlib-based codecs" fate: Make it possible to have alternative reference files fate: Add .alt files so all tests pass on Ubuntu 20.04 tests/fate-run.sh | 10 ++ tests/fate/cover-art.mak | 6 ++-- tests/fate/image.mak | 4 +-- tests/fate/lavf-image.mak | 5 +-- tests/fate/lavf-video.mak | 4 +-- tests/fate/mov.mak| 2 +- tests/fate/vcodec.mak | 4 ++- tests/ref/fate/copy-apng | 4 +-- tests/ref/fate/cover-art-aiff-id3v2-remux | 6 ++-- tests/ref/fate/cover-art-flac-remux | 6 ++-- tests/ref/fate/cover-art-mp3-id3v2-remux | 6 ++-- tests/ref/fate/mov-cover-image| 6 ++-- tests/ref/fate/mov-cover-image.alt| 42 +++ tests/ref/fate/png-icc| 6 ++-- tests/ref/fate/png-mdcv | 4 +-- tests/ref/fate/png-mdcv.alt | 22 tests/ref/lavf/apng | 4 +-- tests/ref/lavf/apng.png | 4 +-- tests/ref/lavf/gray16be.png | 4 +-- tests/ref/lavf/png| 4 +-- tests/ref/lavf/rgb48be.png| 4 +-- tests/ref/seek/vsynth_lena-flashsv| 40 ++--- tests/ref/vsynth/vsynth1-flashsv | 4 +-- tests/ref/vsynth/vsynth1-mpng | 4 +-- tests/ref/vsynth/vsynth1-zlib | 4 +-- tests/ref/vsynth/vsynth2-flashsv | 4 +-- tests/ref/vsynth/vsynth2-mpng | 4 +-- tests/ref/vsynth/vsynth2-zlib | 4 +-- tests/ref/vsynth/vsynth3-flashsv | 4 +-- tests/ref/vsynth/vsynth3-mpng | 4 +-- tests/ref/vsynth/vsynth3-zlib | 4 +-- tests/ref/vsynth/vsynth_lena-flashsv | 4 +-- tests/ref/vsynth/vsynth_lena-mpng | 4 +-- tests/ref/vsynth/vsynth_lena-zlib | 4 +-- 34 files changed, 161 insertions(+), 84 deletions(-) create mode 100644 tests/ref/fate/mov-cover-image.alt create mode 100644 tests/ref/fate/png-mdcv.alt -- ___ ffmpeg-devel mailing list ffmpeg-devel@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 v2 3/3] fate: Add .alt files so all tests pass on Ubuntu 20.04
In commit bce5855afb25d318e090c2e6c16117f065458356 we avoided the problem by using compression level 0. That fixed the problem, but introduced a problem with older versioins of original zlib. This caused differences 2 or more fate tests depending on the zlib version used. See e.g. zlib commit 8ba393e70d984d902b15b9e6876f4d0d38ae4be8 . After re-applying bce5855afb25d318e090c2e6c16117f065458356 this patch fixes the 2 mentioned cases for older zlib versions by allowing an alternative reference file. The files accommodate for the bug in the older version. Signed-off-by: Alexander Strasser --- tests/ref/fate/mov-cover-image.alt | 42 ++ tests/ref/fate/png-mdcv.alt| 22 2 files changed, 64 insertions(+) create mode 100644 tests/ref/fate/mov-cover-image.alt create mode 100644 tests/ref/fate/png-mdcv.alt diff --git a/tests/ref/fate/mov-cover-image.alt b/tests/ref/fate/mov-cover-image.alt new file mode 100644 index 00..0c99cf7ae7 --- /dev/null +++ b/tests/ref/fate/mov-cover-image.alt @@ -0,0 +1,42 @@ +ad553810e0ce362697a2b21544daebde *tests/data/fate/mov-cover-image.mp4 +2063262 tests/data/fate/mov-cover-image.mp4 +#extradata 0:2, 0x00340022 +#tb 0: 1/44100 +#media_type 0: audio +#codec_id 0: aac +#sample_rate 0: 44100 +#channel_layout_name 0: stereo +#tb 1: 1/9 +#media_type 1: video +#codec_id 1: mjpeg +#dimensions 1: 600x600 +#sar 1: 96/96 +#tb 2: 1/9 +#media_type 2: video +#codec_id 2: png +#dimensions 2: 600x600 +#sar 2: 1/1 +0, -2112, -2112, 1024,6, 0x027e00e8, F=0x5, S=1, 10 +0, -1088, -1088, 1024,6, 0x027e00e8, F=0x5 +0,-64,-64, 1024,6, 0x027e00e8 +1, 0, 0,0,25441, 0xe82503b0 +2, 0, 0,0, 1084000, 0x413c7ee9 +0,960,960, 1024,6, 0x027e00e8 +0, 1984, 1984, 1024,6, 0x027e00e8 +0, 3008, 3008, 1024,6, 0x027e00e8 +0, 4032, 4032, 1024,6, 0x027e00e8 +[STREAM] +index=0 +codec_name=aac +DISPOSITION:attached_pic=0 +[/STREAM] +[STREAM] +index=1 +codec_name=mjpeg +DISPOSITION:attached_pic=1 +[/STREAM] +[STREAM] +index=2 +codec_name=png +DISPOSITION:attached_pic=1 +[/STREAM] diff --git a/tests/ref/fate/png-mdcv.alt b/tests/ref/fate/png-mdcv.alt new file mode 100644 index 00..1339fe3a46 --- /dev/null +++ b/tests/ref/fate/png-mdcv.alt @@ -0,0 +1,22 @@ +b674209fd9cd8eff945a6bc1a4b306d3 *tests/data/fate/png-mdcv.image2pipe +2774240 tests/data/fate/png-mdcv.image2pipe +#tb 0: 1/25 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 1280x720 +#sar 0: 0/1 +0, 0, 0,1, 2764800, 0x2bfc7b42 +frames.frame.0.side_data_list.side_data.0.side_data_type="Content light level metadata" +frames.frame.0.side_data_list.side_data.0.max_content=1000 +frames.frame.0.side_data_list.side_data.0.max_average=200 +frames.frame.0.side_data_list.side_data.1.side_data_type="Mastering display metadata" +frames.frame.0.side_data_list.side_data.1.red_x="13250/5" +frames.frame.0.side_data_list.side_data.1.red_y="7500/5" +frames.frame.0.side_data_list.side_data.1.green_x="34000/5" +frames.frame.0.side_data_list.side_data.1.green_y="16000/5" +frames.frame.0.side_data_list.side_data.1.blue_x="2/5" +frames.frame.0.side_data_list.side_data.1.blue_y="0/5" +frames.frame.0.side_data_list.side_data.1.white_point_x="15635/5" +frames.frame.0.side_data_list.side_data.1.white_point_y="16450/5" +frames.frame.0.side_data_list.side_data.1.min_luminance="50/1" +frames.frame.0.side_data_list.side_data.1.max_luminance="1000/1" -- ___ ffmpeg-devel mailing list ffmpeg-devel@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 a target for listing failed tests
Hi Martin!
On 2024-11-07 11:36 +0200, Martin Storsjö wrote:
> If running tests with "make -j fate", the execution will stop
> after the first failing test. To get an overview of the whole
> test suite, one rather would run "make -k -j fate", which then
> again buries the results about what tests actually failed further
> up in the console log.
>
> Add a target so one can run "make fate-list-failing", to see a list
> of all tests that failed the last time they were executed.
>
> Also add a companion target "fate-clear-results" which removes all
> the old test results. (When executing a subset of tests, the result
> files of all tests that aren't executed stay untouched. This also
> allows getting rid of results for tests that no longer are present
> in the testsuite.)
Looks good and useful to me.
Just a few ideas follow:
> ---
> So far, I've always just manually run
> "cat tests/data/fate/*.rep | cut -f 1-2 -d : | grep -v :0", but
> perhaps we should at least wrap it up in something more convenient
> for the other developers.
> ---
> doc/build_system.txt | 6 ++
> doc/fate.texi| 7 +++
> tests/Makefile | 6 ++
> 3 files changed, 19 insertions(+)
>
> diff --git a/doc/build_system.txt b/doc/build_system.txt
> index 0b1b0c2054..91c7a5e9af 100644
> --- a/doc/build_system.txt
> +++ b/doc/build_system.txt
> @@ -30,6 +30,12 @@ fate
> fate-list
> List all fate/regression test targets.
>
> +fate-list-failing
> +List the fate tests that failed the last time they were executed.
> +
> +fate-clear-results
> +Remove the test results from previous test executions.
> +
Would it be better to use the same description as int fate.texi ?
> install
> Install headers, libraries and programs.
>
> diff --git a/doc/fate.texi b/doc/fate.texi
> index 17644ce65a..bf01816af8 100644
> --- a/doc/fate.texi
> +++ b/doc/fate.texi
> @@ -208,6 +208,13 @@ Download/synchronize sample files to the configured
> samples directory.
> @item fate-list
> Will list all fate/regression test targets.
>
> +@item fate-list-failing
> +List the fate tests that failed the last time they were executed.
> +
> +@item fate-clear-results
> +Remove the test results from previous test executions (getting rid of
> +potentially stale results from fate-list-failing).
> +
> @item fate
> Run the FATE test suite (requires the fate-suite dataset).
> @end table
> diff --git a/tests/Makefile b/tests/Makefile
> index 9b70145015..adb0799328 100644
> --- a/tests/Makefile
> +++ b/tests/Makefile
> @@ -313,6 +313,12 @@ $(FATE): $(FATE_UTILS:%=tests/%$(HOSTEXESUF)) |
> $(FATE_OUTDIRS)
> fate-list:
> @printf '%s\n' $(sort $(FATE))
>
> +fate-list-failing:
> + @cat tests/data/fate/*.rep | cut -f 1-2 -d : | grep -v :0 | sed
> 's/:.*//;s/^/fate-/'
> +
> +fate-clear-results:
> + @rm -f tests/data/fate/*.rep
> +
> coverage.info: TAG = LCOV
> coverage.info:
> $(M)lcov -q -d $(CURDIR) -b $(patsubst src%,./,$(SRC_LINK)) --capture |
> \
> --
Maybe the attached patch would make sense on top of your changes?
Best regards,
Alexander
From 130ca8d85dcb1fecace596e1f23e0414d56348ef Mon Sep 17 00:00:00 2001
From: Alexander Strasser
Date: Sun, 1 Dec 2024 15:06:53 +0100
Subject: [PATCH] fate: Simplify implementation for target fate-list-failing
Make it a little easier to read and use one awk invocation as opposed
to a combination of cat, cut, grep, and sed.
Signed-off-by: Alexander Strasser
---
tests/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/Makefile b/tests/Makefile
index adb0799328..2c4ad7c18f 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -314,7 +314,7 @@ fate-list:
@printf '%s\n' $(sort $(FATE))
fate-list-failing:
- @cat tests/data/fate/*.rep | cut -f 1-2 -d : | grep -v :0 | sed
's/:.*//;s/^/fate-/'
+ @awk -F: '$$2 != 0 { print "fate-" $$1 }' tests/data/fate/*.rep
fate-clear-results:
@rm -f tests/data/fate/*.rep
--
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/cbs_h266: Fix typo
Introduced in commit 98698ed3c24bfd0b1e6e6db943b5f25f6046cee7
Fixes: CID1635788 CID1635789
Signed-off-by: Alexander Strasser
---
Just picked this up because of Coverity.
Not sure how to verify/test this change, but it seems plausible.
Alexander
libavcodec/cbs_h266_syntax_template.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/cbs_h266_syntax_template.c
b/libavcodec/cbs_h266_syntax_template.c
index 43def9220f..029fbd5e4f 100644
--- a/libavcodec/cbs_h266_syntax_template.c
+++ b/libavcodec/cbs_h266_syntax_template.c
@@ -1151,7 +1151,7 @@ static int FUNC(sps)(CodedBitstreamContext *ctx,
RWContext *rw,
else
infer(sps_subpic_width_minus1[0], max_width_minus1);
if (current->sps_pic_height_max_in_luma_samples > ctb_size_y)
-us(hlen, sps_subpic_height_minus1[0], 0, max_width_minus1, 1,
0);
+us(hlen, sps_subpic_height_minus1[0], 0, max_height_minus1, 1,
0);
else
infer(sps_subpic_height_minus1[0], max_height_minus1);
if (!current->sps_independent_subpics_flag) {
--
___
ffmpeg-devel mailing list
ffmpeg-devel@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 a target for listing failed tests
On 2024-12-04 16:07 +0200, Martin Storsjö wrote: > On Sun, 1 Dec 2024, Alexander Strasser via ffmpeg-devel wrote: [...] > > > > Would it be better to use the same description as int fate.texi ? > > Sure, I can add that extra parenthesis. Thanks. [...] > > > +fate-clear-results: > > > + @rm -f tests/data/fate/*.rep > > > + > > > coverage.info: TAG = LCOV > > > coverage.info: > > > $(M)lcov -q -d $(CURDIR) -b $(patsubst src%,./,$(SRC_LINK)) --capture | > > > \ > > > -- > > > > Maybe the attached patch would make sense on top of your changes? > > Nice, thanks. I'm not very familiar with awk so I seldom write such things > myself, but this does indeed seem neater. > > As a second question, do you have any opinion on the fate target names? > Should the second be "fate-clear-failing" to match the list-failing one? But > technically it's not only about clearing the failing ones but clearing all > results... I think fate-clear-results is better, because it more accurately describes what it does. Maybe fate-clear-reports would be even more precise. That is if I recall correctly that the `.rep` suffix was chosen as an abbrevation for report. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/png{dec, enc}: update mDCV and cLLI chunk capitalization
Hi Leo!
On 2024-12-01 09:20 -0500, Leo Izen wrote:
> The PNGv3 Specification Draft [1] has changed the capitalization
> of mDCV and cLLI chunks (formerly mDCv and cLLi). This patch updates
> FFmpeg to work with the new chunk names while retaining decode-side
> compatibility with files created using the old names.
>
> [1]: https://w3c.github.io/png/
>
> Signed-off-by: Leo Izen
> ---
> libavcodec/pngdec.c | 12 +++-
> libavcodec/pngenc.c | 4 ++--
> tests/ref/fate/png-mdcv | 2 +-
> 3 files changed, 10 insertions(+), 8 deletions(-)
LGTM.
Your changes are sensible and complete as far as I could check.
Only problem I could think of is being to fast, as it isn't
in the latest published version of the W3C yet.
If I understood chunk naming conventions correctly they marked
those 2 chunks unsafe to copy, which will probably stay that
way. So I think the patch can be pushed.
Best regards,
Alexander
> diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> index c5b32c166d..f8cb61775e 100644
> --- a/libavcodec/pngdec.c
> +++ b/libavcodec/pngdec.c
> @@ -757,7 +757,7 @@ static int populate_avctx_color_fields(AVCodecContext
> *avctx, AVFrame *frame)
> if (clli) {
> /*
> * 0.0001 divisor value
> - * see: https://www.w3.org/TR/png-3/#cLLi-chunk
> + * see: https://www.w3.org/TR/png-3/#cLLI-chunk
> */
> clli->MaxCLL = s->clli_max / 1;
> clli->MaxFALL = s->clli_avg / 1;
> @@ -1566,18 +1566,20 @@ static int decode_frame_common(AVCodecContext *avctx,
> PNGDecContext *s,
>
> break;
> }
> -case MKTAG('c', 'L', 'L', 'i'):
> +case MKTAG('c', 'L', 'L', 'i'): /* legacy spelling, for backwards
> compat */
> +case MKTAG('c', 'L', 'L', 'I'):
> if (bytestream2_get_bytes_left(&gb_chunk) != 8) {
> -av_log(avctx, AV_LOG_WARNING, "Invalid cLLi chunk size:
> %d\n", bytestream2_get_bytes_left(&gb_chunk));
> +av_log(avctx, AV_LOG_WARNING, "Invalid cLLI chunk size:
> %d\n", bytestream2_get_bytes_left(&gb_chunk));
> break;
> }
> s->have_clli = 1;
> s->clli_max = bytestream2_get_be32u(&gb_chunk);
> s->clli_avg = bytestream2_get_be32u(&gb_chunk);
> break;
> -case MKTAG('m', 'D', 'C', 'v'):
> +case MKTAG('m', 'D', 'C', 'v'): /* legacy spelling, for backward
> compat */
> +case MKTAG('m', 'D', 'C', 'V'):
> if (bytestream2_get_bytes_left(&gb_chunk) != 24) {
> -av_log(avctx, AV_LOG_WARNING, "Invalid mDCv chunk size:
> %d\n", bytestream2_get_bytes_left(&gb_chunk));
> +av_log(avctx, AV_LOG_WARNING, "Invalid mDCV chunk size:
> %d\n", bytestream2_get_bytes_left(&gb_chunk));
> break;
> }
> s->have_mdcv = 1;
> diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
> index cb79c04e11..37e8d5bfcf 100644
> --- a/libavcodec/pngenc.c
> +++ b/libavcodec/pngenc.c
> @@ -445,7 +445,7 @@ static int encode_headers(AVCodecContext *avctx, const
> AVFrame *pict)
> AVContentLightMetadata *clli = (AVContentLightMetadata *)
> side_data->data;
> AV_WB32(s->buf, clli->MaxCLL * 1);
> AV_WB32(s->buf + 4, clli->MaxFALL * 1);
> -png_write_chunk(&s->bytestream, MKTAG('c', 'L', 'L', 'i'), s->buf,
> 8);
> +png_write_chunk(&s->bytestream, MKTAG('c', 'L', 'L', 'I'), s->buf,
> 8);
> }
>
> side_data = av_frame_get_side_data(pict,
> AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
> @@ -460,7 +460,7 @@ static int encode_headers(AVCodecContext *avctx, const
> AVFrame *pict)
> AV_WB16(s->buf + 14, PNG_Q2D(mdcv->white_point[1], 5));
> AV_WB32(s->buf + 16, PNG_Q2D(mdcv->max_luminance, 1));
> AV_WB32(s->buf + 20, PNG_Q2D(mdcv->min_luminance, 1));
> -png_write_chunk(&s->bytestream, MKTAG('m', 'D', 'C', 'v'),
> s->buf, 24);
> +png_write_chunk(&s->bytestream, MKTAG('m', 'D', 'C', 'V'),
> s->buf, 24);
> }
> }
>
> diff --git a/tests/ref/fate/png-mdcv b/tests/ref/fate/png-mdcv
> index c524a94ded..4328c56349 100644
> --- a/tests/ref/fate/png-mdcv
> +++ b/tests/ref/fate/png-mdcv
> @@ -1,4 +1,4 @@
> -fc68fe6c8c72343b96d2695f6913995b *tests/data/fate/png-mdcv.image2pipe
> +b1837f5557ad969a3f9763840480d5c0 *tests/data/fate/png-mdcv.image2pipe
> 439248 tests/data/fate/png-mdcv.image2pipe
> #tb 0: 1/25
> #media_type 0: video
> --
___
ffmpeg-devel mailing list
ffmpeg-devel@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] [ANNOUNCE] upcoming vote: TC election
On 2024-11-28 15:29 +0100, Anton Khirnov wrote: > > the current Technical Committee (TC) was elected on 2023-12-05 and its > mandate lasts for one year, so we should hold a new election soon. If > there are no unforeseen circumstances, I would like to start the vote on > Monday 2024-12-09. > > As a reminder, the TC is in charge of resolving technical disputes. If > you would like to be a TC member, please say so in a reply to this > email. I volunteer to be a TC member. Some random facts in random order to spice this up a little: * I have been around for more than 20 years * I love reading source code * I have a nag at studying languages be it natural ones or programming languages * My day job is not related to FFmpeg or audio/video projects Best regards, Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] web: Add link to conferences page
On 2024-12-08 12:36 +0100, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > src/template_head2 | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/template_head2 b/src/template_head2 > index 0394ace..51da347 100644 > --- a/src/template_head2 > +++ b/src/template_head2 > @@ -29,6 +29,7 @@ >Forums >Bug Reports >https://trac.ffmpeg.org";>Wiki > + href="https://trac.ffmpeg.org/wiki/Conferences";>Conferences > > >Developers > -- Should probably be fine. Maybe wait a few more days for comments. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] configure: Include quotes around pkg_version
On 2024-12-28 12:56 +0100, Alexander Strasser via ffmpeg-devel wrote: > On 2024-12-27 08:13 -0500, Leo Izen wrote: [...] > > > > I did a bit of testing and I believe the issue is >=, specifically, it's > > being interpreted as a redirect-out to a file named "=". pkg-config works on > > my system if I run `pkg-config --libs 'aom >= 2.0'` but also it works if I > > run `pkg-config --libs aom '>=' 2.0` but if I don't quote the redirect, the > > shell expands it. > > > > I could not say why MSYS appears to be interpreting the redirect differently > > when expanding the variable, but if I had to guess, it may be a bug in its > > path-mangling (i.e. converting /foo/bar to C:\foo\bar) where it's > > interpreting "=" as a filename. I could not say for certain if this is the > > case. > > Leo's theory seems to provide a plausible explanation of the behavior. > > According to POSIX[1] the high level algo goes like this: > > 4. For each word within a command, the shell processes -escape >sequences inside dollar-single-quotes (see 2.2.4 Dollar-Single-Quotes) >and then performs various word expansions (see 2.6 Word Expansions). >In the case of a simple command, the results usually include a list of >pathnames and fields to be treated as a command name and arguments; >see 2.9 Shell Commands. > > 5. The shell performs redirection (see 2.7 Redirection) and removes > redirection >operators and their operands from the parameter list. > > To my understanding word expansions in step 4 should quote results > and thus >= shouldn't have an effect like it seems it now has on MSYS. > Presumably that is caused by the suspected MSYS path mangling mechanisms. > > > > In either case, I don't see issue with quoting it as that works on every > > system. > > I would like to look a bit more into this. Especially what is > documented for pkg-config regarding its argument syntax. > > If it's accepting the single argument syntax since a long time, > than I see no harm in including your patch Joe and would push > it soon'ish. Pushed. The one argument syntax seems to be supported for a long long time. See the details in the modified commit message. Thanks for the patch Joe. Might still make sense to report at MSYS. Maybe pointing to this discussion. Best regards, Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_grayworld: Use the correct pointer for av_log()
On 2025-01-06 05:22 +0100, Michael Niedermayer wrote:
> Fixes: crash
>
> Found-by: Elias Myllymäki
> Signed-off-by: Michael Niedermayer
> ---
> libavfilter/vf_grayworld.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/vf_grayworld.c b/libavfilter/vf_grayworld.c
> index a6a51dcb7db..91b097a4b80 100644
> --- a/libavfilter/vf_grayworld.c
> +++ b/libavfilter/vf_grayworld.c
> @@ -266,10 +266,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *in)
> }
> /* input and output transfer will be linear */
> if (in->color_trc == AVCOL_TRC_UNSPECIFIED) {
> -av_log(s, AV_LOG_WARNING, "Untagged transfer, assuming linear
> light.\n");
> +av_log(ctx, AV_LOG_WARNING, "Untagged transfer, assuming linear
> light.\n");
> out->color_trc = AVCOL_TRC_LINEAR;
> } else if (in->color_trc != AVCOL_TRC_LINEAR) {
> -av_log(s, AV_LOG_WARNING, "Gray world color correction works on
> linear light only.\n");
> +av_log(ctx, AV_LOG_WARNING, "Gray world color correction works on
> linear light only.\n");
> }
>
> td.in = in;
> --
LGTM
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC PATCH] avformat/rtpdec: fix another int overflow in start_time_realtime
Hi Jonathan! On 2025-01-05 04:26 -0500, Jonathan Baudanza wrote: > > > On Tue, Nov 26, 2024, at 1:35 AM, j...@jonb.org wrote: > > > > This patch replaces av_rescale, which operates on int64_t, with > > ff_parse_ntp_time, which operates on uint65_t. This will give the correct > > values for timestamps back around the NTP epoch and present day timestamps. > > > > Any feedback on this one-liner? Patch looks plausible except for the uint65_t typo and the long lines in the commit message. Will give it a try and push if it works and there are no objections from other developers. Thanks for submitting this patch! Best regards, Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/ipfsgateway: fix capitalizaton mistake
On 2025-01-07 14:18 -0500, Leo Izen wrote: > Fix the incorrect capitalization of the project name in a comment. > The project is named FFmpeg, not FFMpeg. > > Signed-off-by: Leo Izen > Reported-by: NyanMaths > --- > libavformat/ipfsgateway.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/ipfsgateway.c b/libavformat/ipfsgateway.c > index 9a15bcf93b..1a8382d7be 100644 > --- a/libavformat/ipfsgateway.c > +++ b/libavformat/ipfsgateway.c > @@ -290,7 +290,7 @@ static int translate_ipfs_to_http(URLContext *h, const > char *uri, int flags, AVD > goto err; > } > > -// Pass the URL back to FFMpeg's protocol handler. > +// Pass the URL back to FFmpeg's protocol handler. > ret = ffurl_open_whitelist(&c->inner, fulluri, flags, > &h->interrupt_callback, options, > h->protocol_whitelist, > -- Not super urgent but LGTM ;-) Isn't the patch authored by NyanMaths though? Best regards, Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/mov: merge stts and ctts arrays into one
On 2025-01-07 10:55 -0300, James Almer wrote: > Should reduce memory usage as well as remove code duplication. > > Signed-off-by: James Almer > --- > libavformat/isom.h | 15 +- > libavformat/mov.c| 579 --- > tests/ref/fate/quickdraw | 2 +- > 3 files changed, 251 insertions(+), 345 deletions(-) [...] > diff --git a/tests/ref/fate/quickdraw b/tests/ref/fate/quickdraw > index 44610498c8..5746929502 100644 > --- a/tests/ref/fate/quickdraw > +++ b/tests/ref/fate/quickdraw > @@ -9,7 +9,7 @@ > 0, 3, 3,1, 921600, 0xc0e68764 > 0, 4, 4,1, 921600, 0xc0e68764 > 0, 5, 5,1, 921600, 0xc0e68764 > -0, 7, 7,2, 921600, 0x01a16629 > +0, 7, 7,1, 921600, 0x01a16629 Why did the duration change? Is it intended? If yes I think it would be better to explain it in the commit message. > 0, 9, 9,1, 921600, 0x01a16629 > 0, 10, 10,1, 921600, 0x01a16629 > 0, 11, 11,1, 921600, 0x01a16629 > -- Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/4] doc/faq: Anwser some questions about he GA, which keep popping up
Hi Ronald, hi Michael, hi all! On 2025-01-07 22:32 +0100, Michael Niedermayer wrote: > Hi Ronald > > On Tue, Jan 07, 2025 at 01:30:36PM -0500, Ronald S. Bultje wrote: > > On Tue, Jan 7, 2025 at 7:02 AM Michael Niedermayer > > wrote: > > > > > Hi Ronald > > > > > > On Mon, Jan 06, 2025 at 09:38:27PM -0500, Ronald S. Bultje wrote: > > > > On Mon, Jan 6, 2025 at 6:23 PM Michael Niedermayer < > > > mich...@niedermayer.cc> > > > > wrote: > > > > > > > > > +@subsection Can votes be bought? > > > > > > > > > > > > > Really? This is necessary? :-( > > > > > > "This" as in, "talking about the problems of the GA governance system" ? > > > > > > yes, it is necessary to talk about a problem to solve the problem and > > > build a > > > better system. > > > > > > > > > "This" as in, "adding it to our FAQ like that" > > > > > > no, its not necessary to add it. > > > > > > > It's a reflection of bad faith, we can do so much better than this. Let's > > try to be better, not worse, than what we claim "the other side" (??) is. > > This patch is unnecessary. > > Iam not able to parse what you wrote at all. In fact none of this paragraph > I see no sides, none of this. > I think you are somehow reading this patch in a unintended way First of all NAK at this patch. Second @Michael, I think the, let's say creative, way you brought up these problems, doesn't ring well with well or get thru as intended with many people. Third, AFAIU this was to start discussing that issue, but I think it's rather weird to to that in this mixed patch series. Not sure how to proceed, but I would think it's better to at least change the subject when discussing this further or maybe start a new thread by optionally quoting this patch. [...] Best regards, Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/4] doc/faq: Document the plan ahead for Governance
On 2025-01-07 00:23 +0100, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > doc/faq.texi | 8 > 1 file changed, 8 insertions(+) > > diff --git a/doc/faq.texi b/doc/faq.texi > index 54c3fbb41fe..70002a8156d 100644 > --- a/doc/faq.texi > +++ b/doc/faq.texi > @@ -702,4 +702,12 @@ In recent years, a significant number of developers > contributing to the project > unlike in the past. These employees are often compensated for specific > tasks, and the voting rights, > much like the copyrights, can typically be controlled by their employers. > > +@section What is the future plan for FFmpeg Governance? > + > +Governance has 2 goals, 1st to make good decissions for FFmpeg. And 2nd is > to create > +an inclusive and motivating environment where contributors feel valued and > inspired to > +collaborate. The plan is to find out how to achieve these goals. > +For example for a system to make good decissions it needs to be hard to > manipulate > + > + Similar to patch 2/4, I think this is not a good change for the FAQ. 1. At best it doesn't really help the people reading it 2. The average reader might think, oh probably one of those outdated FAQ entries or similar 3. At worst people might understand it in any of the countless unintended ways Thus I assume this the same approach as with 2/4 to uncommonly but somehow concretely bring up open points for discussion. And would advise the same to proceed here (change subject or start new thread). Best regards, Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/frame.h: improve documentation for AV_FRAME_FLAG_LOSSLESS
On 2025-01-07 20:13 -0500, Leo Izen wrote:
> It should be more clear what this flag is indicating with a more
> verbose comment documenting it.
>
> Signed-off-by: Leo Izen
> ---
> libavutil/frame.h | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 993fa6b65a..e3657f193f 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -666,7 +666,13 @@ typedef struct AVFrame {
> */
> #define AV_FRAME_FLAG_TOP_FIELD_FIRST (1 << 4)
> /**
> - * A flag to mark frames which were encoded losslessly from the input.
> + * A flag to mark frames that a decoder has determined were originally
> encoded
> + * losslessly.
> + *
> + * For coding bitstream formats which support both lossless and lossy
> + * encoding, it is sometimes possible for a decoder to determine which method
> + * was used when the bitsream was encoded.
> Frames marked with this flag
> + * have been identified by a decoder as having been losslessly encoded,
> originally.
Personally I would drop this last sentence.
It's a bit verbose and adds nothing new AFAICT.
> */
> #define AV_FRAME_FLAG_LOSSLESS(1 << 5)
> /**
> --
LGTM maybe Marton can also comment.
Thanks,
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/ffmpeg.texi: replace use of uncommon unicode characters
Hi James! On 2024-12-25 20:54 -0300, James Almer wrote: > Addresses ticket #11372 > > Signed-off-by: James Almer > --- > doc/ffmpeg.texi | 64 - > 1 file changed, 32 insertions(+), 32 deletions(-) > LGTM (mabye one of documentation maintainers also want to comment) Looked at it in the terminal and via man and also the HTML versions in chromium and firfox. Might depend on many things how things are actually rendered, including final font decisions etc. but at least here the in the browsers it looked also better aligned with the new symbols. Alexander [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] configure: Include quotes around pkg_version
Hi Leo and Joe! On 2024-12-27 08:13 -0500, Leo Izen wrote: > On 12/26/24 6:12 PM, J Shiff wrote: > > On Wed, Dec 25, 2024 at 5:03 PM Alexander Strasser via ffmpeg-devel > > wrote: > > > > > > On 2024-12-21 19:29 -0500, J Shiff wrote: > > > > On Sat, Dec 21, 2024 at 5:44 PM Alexander Strasser via ffmpeg-devel > > > > wrote: > > > > > > > > > > On 2024-12-16 16:19 -0500, Joe Schiffler wrote: > > > > > > Since $pkg_version includes spaces, builds can fail in some MSYS > > > > > > environments. > > > > > > > > > > Could you show what the pkg_version with spaces was in your case? > > > > > > > > The value of pkg_version would be: `aom >= 2.0.0` > > > > > > Ok, thanks for coming back to this! > > > > > > What is still strange about it: What changed and where? > > > > > > These values for pkg_version should come up on every platform > > > and AFAICT it works just fine for me and many others. > > > > > > Didn't spot any relevant changes in ffmpeg configure on a quick > > > look. > > > > > > Would be better to understand why it fails only in some > > > environments and not others. > > > > Thank you for showing interest in this topic. > > > > Yeah, I also find it strange. > > If you have any recommendations for narrowing it down further, I'm > > open to suggestions. > > > > I did a bit of testing and I believe the issue is >=, specifically, it's > being interpreted as a redirect-out to a file named "=". pkg-config works on > my system if I run `pkg-config --libs 'aom >= 2.0'` but also it works if I > run `pkg-config --libs aom '>=' 2.0` but if I don't quote the redirect, the > shell expands it. > > I could not say why MSYS appears to be interpreting the redirect differently > when expanding the variable, but if I had to guess, it may be a bug in its > path-mangling (i.e. converting /foo/bar to C:\foo\bar) where it's > interpreting "=" as a filename. I could not say for certain if this is the > case. Leo's theory seems to provide a plausible explanation of the behavior. According to POSIX[1] the high level algo goes like this: 4. For each word within a command, the shell processes -escape sequences inside dollar-single-quotes (see 2.2.4 Dollar-Single-Quotes) and then performs various word expansions (see 2.6 Word Expansions). In the case of a simple command, the results usually include a list of pathnames and fields to be treated as a command name and arguments; see 2.9 Shell Commands. 5. The shell performs redirection (see 2.7 Redirection) and removes redirection operators and their operands from the parameter list. To my understanding word expansions in step 4 should quote results and thus >= shouldn't have an effect like it seems it now has on MSYS. Presumably that is caused by the suspected MSYS path mangling mechanisms. > In either case, I don't see issue with quoting it as that works on every > system. I would like to look a bit more into this. Especially what is documented for pkg-config regarding its argument syntax. If it's accepting the single argument syntax since a long time, than I see no harm in including your patch Joe and would push it soon'ish. Alexander 1. https://pubs.opengroup.org/onlinepubs/9799919799/ ___ ffmpeg-devel mailing list ffmpeg-devel@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/vvc_mc: reduce sequential dependency in R-V V sad
On 2024-12-30 20:25 +0200, Rémi Denis-Courmont wrote: > Le tiistaina 24. joulukuuta 2024, 15.30.00 EET Nuo Mi a écrit : > > On Mon, Dec 23, 2024 at 11:18 PM flow gg wrote: > > > Hi, It looks like you submitted your review comments not long after the > > > patch was merged. > > > > > > Previously, regarding the VVC avg patch, you mentioned "LGTM for the > > > RISC-V > > > side. No clue about the VVC side", > > > so I contacted Nuomi in the hope that he could help merge the patch that > > > had been pending for a while. > > > > Hi Remi, > > Yes, v2 has been on the mailing list for about two weeks. > > Yes but there was only a day and a half between v2_2 and my comments, and > that's way too short. Misunderstandings can (and probably will) always happen. In case they do, as a maintainer, you should revert the parts that you consider wrong, if you feel that is better than waiting for a patch to fix the remaining problems. In some situations if a partial revert is too hard, even a full revert can be considered. Should be judged based on something like the impact you estimate and the number of users potentially affected. In any case why a patch set was reverted and how big you estimated the problems should be part of the message of the revert commit. What must not happen of course is "revert wars", but generally quickly reverting things once, should be considered instead of leaving things knowingly broken for an undetermined amount of time. I hope other developers agree to my reasoning here. If not please raise your voice. If there is no disagreement, we should maybe extend our documentation. Will have a look into that. Also there is a case for committing security relevant fixes, even if the maintainer couldn't ack them yet. IMHO we should not let those wait too long because the maintainer is not quick to respond. It's another topic, but should probably also be documented if it isn't. Also it's the lived practice of the recent decades of FFmpeg development I think. Alexander [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/vqf: Propagate errors from add_metadata()
Hi Michael!
On 2024-12-31 04:36 +0100, Michael Niedermayer wrote:
> Suggested-by: Marton Balint
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/vqf.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/libavformat/vqf.c b/libavformat/vqf.c
> index 79deb33744b..5094724240e 100644
> --- a/libavformat/vqf.c
> +++ b/libavformat/vqf.c
> @@ -51,23 +51,24 @@ static int vqf_probe(const AVProbeData *probe_packet)
> return AVPROBE_SCORE_EXTENSION;
> }
>
> -static void add_metadata(AVFormatContext *s, uint32_t tag,
> +static int add_metadata(AVFormatContext *s, uint32_t tag,
> unsigned int tag_len, unsigned int remaining)
> {
> int len = FFMIN(tag_len, remaining);
> char *buf, key[5] = {0};
>
> if (len == UINT_MAX)
> -return;
> +return AVERROR(ENOMEM);
>
> buf = av_malloc(len+1);
> if (!buf)
> -return;
> +return AVERROR(ENOMEM);
> if (len != avio_read(s->pb, buf, len))
> -return;
> +return len < 0 ? len : AVERROR_INVALIDDATA;
This looks wrong if I understood this function correctly.
The variable *len* is only set at the beginning of the function.
If I understand the intent correctly we should either always return
AVERROR_INVALIDDATA or we should store the return value of avio_read
and return that if it's negative.
[...]
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] SCaLE booth
Hi Rémi! On 2024-11-19 19:10 +0200, Rémi Denis-Courmont wrote: > > I plan to solicit an FFmpeg booth at SCaLE 22x to be held early next March. > Booths for open-source communities are free and include 5 full conference > passes. The exhibition area is open, and needs to be manned, on Friday > afternoon (14-18), Saturday (10-18) and Sunday morning (10-14). > > If anyone is interested in participating, please contact me off list. Please > note that: > 1) Although I don't expect any issue, this is not confirmed yet. > 2) SCaLE will not sponsor anyone. If you need sponsorship, please check with > FFmpeg's treasurer (who is not me). Sounds cool! Did you ask for a both? If you did it would be best to add an entry in the conferences page: https://trac.ffmpeg.org/wiki/Conferences Greetings, Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/5] lavc/container_fifo: move to lavu and make public
On 2024-12-11 15:05 +0100, Anton Khirnov wrote:
> This can be useful in other places, e.g. it can replace objpool in
> fftools.
>
> The API is modified in the following nontrivial ways:
> * opaque pointers can be passed through to all user callbacks
> * read and write were previously separate callbacks in order to
> accomodate the caller wishing to write a new reference to the FIFO and
> keep the original one; the two callbacks are now merged into one, and
> a flags argument is added that allows to request such behaviour on a
> per-call basis
> * new peek and drain functions
> ---
> doc/APIchanges | 5 +-
> libavcodec/Makefile| 2 +-
> libavcodec/container_fifo.h| 89 --
> libavcodec/hevc/hevcdec.c | 10 +-
> libavcodec/hevc/hevcdec.h | 2 +-
> libavcodec/hevc/refs.c | 4 +-
> libavutil/Makefile | 2 +
> {libavcodec => libavutil}/container_fifo.c | 116 ++
> libavutil/container_fifo.h | 130 +
> 9 files changed, 215 insertions(+), 145 deletions(-)
> delete mode 100644 libavcodec/container_fifo.h
> rename {libavcodec => libavutil}/container_fifo.c (51%)
> create mode 100644 libavutil/container_fifo.h
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 13789fcea4..5d75b6077d 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -2,10 +2,13 @@ The last version increases of all libraries were on
> 2024-03-07
>
> API changes, most recent first:
>
> -2024-12-xx - xx - lavu 59.50.100 - refstruct.h
> +2024-12-xx - xx - lavu 59.50.100 - refstruct.h container_fifo.h
>Add a new public header refstruct.h with new API for
>reference-counted objects.
>
> + Add a new public header container_fifo.h with new API for
> + a FIFO of container objects (e.g. AVFrame or AVPacket).
I see this was already pushed.
I wanted to comment mainly because of the naming. Didn't deeply
check the series as a whole, but AFAICS it looks legit.
I find the "container" part of the naming consusing, especially in
a multimedia project.
Didn't yet have brilliant ideas.
Some suggestions to get started follow in no particular order:
* objpool_fifo
* reusable_obj_fifo
* refstruct_fifo
Best regards,
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 0/3] Make fate tests succeed with zlib-ng
On 2024-12-16 22:02 -0500, Leo Izen wrote: > On 12/16/24 5:50 PM, Michael Niedermayer wrote: [...] > > > (e): Find a input that encodes to max 2 variants and store 2 checksums > > Doesn't fix the problem, which is that need to be aware of all the known > variants and create hacks to work with them instead of doing something more > future proof. I may be misunderstanding sth, but this is what my series does, right? > > I dont think (e) is the best solution, but if it works for all cases, > > my point is, that it is a valid solution > > > > It really isn't, because it doesn't work in all cases. It works for a > specific list of known cases. This is not the same thing. Why do you think it is not future proof? Do you expect there will be more zlib (or alternative implementation bugs) for compression level zero? My idea was to remove the .alt files after at least all fate clients have been updated to zlib implementations that don't need it anymore. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] checkasm: Print benchmarks of C-only functions
Hi Martin! On 2024-12-11 10:47 +0200, Martin Storsjö wrote: > On Wed, 23 Oct 2024, Martin Storsjö wrote: > > > This corresponds to commit 9278a14cf406f8edb5052c42b83750112bf5b515 > > in dav1d. > > > > Omitting the C-only functions doesn't speed up benchmarking > > anyway (as those has to be benchmarked before we know if we have > > any corresponding assembly functions), and being able to benchmark > > those functions without corresponding assembly can be valuable in > > a number of cases. > > --- > > tests/checkasm/checkasm.c | 48 +++ > > 1 file changed, 23 insertions(+), 25 deletions(-) > > Will push soon. > > The only concern about this change I heard was from Ramiro on irc, who > wasn't familiar with how to use the --bench= parameter for limiting > the set of functions to actually benchmark. > > (This patch doesn't cause checkasm to benchmark more than it did before, it > just prints the numbers that already were benchmarked.) > > I'll also go ahead and backport this to the 7.1 branch. It's obviously not a > regression fix or anything like that, but the change adds value for being > able to use checkasm to benchmark compiler performance. LGTM. Tested on aarch64 . Total run times match. Output had only additional lines which all were for functions ending in `_c` Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 0/3] Make fate tests succeed with zlib-ng
On 2024-12-14 11:09 +0100, Anton Khirnov wrote: > Quoting Alexander Strasser via ffmpeg-devel (2024-12-01 21:13:56) > > This is a fixed up version of the series I sent before. > > > > This worked for me on Ubuntu 20.04 but probably will break > > with older zlib versions as Hendrik pointed out in the > > previous thread. Either we must update zlib on affected > > FATE clients or add more .alt files to them as well. > > > > We could also go the further the "no_file_checksums" as > > was demonstrated by James' series. > > > > I still prefer this way because it's simpler and retains > > the value of the tests. > > This seems like a hack to me. Depends on what you precisely mean by hack. It is a way to accommodate for shortcomings in older, but still widely used zlib versions. > We should not be testing for bitexact output from code that is not under > our control and does not guarantee bitexactness. Ideally! OTOH we also indirectly test that other code like C std lib functions work as expected. In this case short of bugs in zlib/zlib-ng I do not see why the output should differ with compression level 0. Maybe I'm missing something I didn't look that deep into how zlib exactly works. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Fwd: Your message to ffmpeg-devel awaits moderator approval
On 2024-12-19 06:46 -1000, compn wrote: > On Thu, 19 Dec 2024 13:16:23 -0300, James Almer wrote: > > > On 12/19/2024 1:12 PM, compn wrote: > > > On Thu, 19 Dec 2024 10:04:53 -0300, James Almer wrote: > > >> I have no idea who added the rule for "upcoming vote", but i just > > >> removed it. > > >> > > > > > > i added upcoming vote to mod as devs were getting personal about booths > > > and whatnot. as you've removed it, now we see the flames on the list. > > > > You can't silently and unilaterally add a filter to stop a thread in its > > tracks. That is something that needs to go through the CC, and publicly > > announced. > > could you link me to the actual rules that state any of this? > > none of what you said is in the ffmpeg code of conduct. > https://ffmpeg.org/community.html > > if you cannot link me to rules that show any of what you said i broke > the rules of, i would like an apology. > > > It speaks poorly of how you would perform as part of the CC if you think > > acting alone and making bad use of your ml admin privileges is ok. > > keeping out flames is part of the ml admin duties. see for ex: > emergency moderation, moderate all users, mod individual, spam filtering > options. > > these stop flames duties were told to me by previous roots > (gabu, diego) and current roots (michael, alex). I agree that ml admins are needed and need to take action sometimes. I *fully disagree* with silent action like it happened in this case. If such an action is taken, that should be clearly communicated right here; and what it is about, how long it will last and what's going to happen with the queued emails. The decentralized/freedom aspects of email are a strong part about what makes email good. Thank you Kieran for complaining about this by opening this thread! Alexander > > reading the mails stuck in the moderation queue and clearing the > moderation queue is also part of the duties of the ml admin. > > -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_scale: remove systematic PAL8 hack
On 2024-12-20 19:38 +0100, Michael Niedermayer wrote: > On Fri, Dec 20, 2024 at 02:56:54PM +0100, Niklas Haas wrote: > > On Fri, 20 Dec 2024 08:37:40 -0500 "Ronald S. Bultje" > > wrote: [...] > > > Assuming you agree with that - which is hard to argue with - don't you > > > agree that for now, we should at the very least inform users that - if > > > this > > > is what they're doing - what they're doing is inferior > > > (sws-palette-generation) and that there's a superior solution in-place > > > already (palettegen). For commandline users, this will be a string change > > > in their invocation. For API users, it's a bit more work but nothing > > > major. > > > I can integrate libavfilter in my application in a few minutes. I have > > > posted sample code on stackoverflow doing that. > > > > > > For now, this is just an informative message (at loglevel=warning) telling > > > our users about this superior experience. At some point in the future > > > (this > > > is probably 2 years from now?), the warning turns into an error. That > > > provides a clear timeline for this hypothetical swscale feature to be > > > implemented - or not. Both would be a great improvement for the vast > > > majority of our users who don't read their messages from their commandline > > > invocations until they fail. > > > > > > I only see positives here. And the best is: all of this already exists - > > > right there in FFmpeg, the toolkit which we all love. We only have to > > > inform our users about all this greatness. You must be excited about this, > > > no? > > > > > It would also be fairly straightforward to expose the palettegen > > functionality > > internally inside libavfilter and then add it directly to vf_scale. This > > would > > improve the status quo without anybody having to be the wiser. > > yes > > > > > > While it would be nice to have better palette-based dithering directly in > > libswscale as well, there is some risk of unnecessarily duplicating code at > > best, and reinventing a worse version of libavfilter at worst. Either way, > > that > > is something to consider *after* the ongoing rewrite of the core scaling > > functionality. > > yes > I do think libswscale should do any image -> image convert (its kind of what > its > intended to do) > if pal8 is left out, that seems like drawing the seperation at the wrong place > to me. > also the code from libavfilter can be moved into libswscale while libavfilter > can then depend on it and continue to present it to the user as it did before > > > > > I can't help but wonder if the better long-term solution here isn't to just > > improve the way libavfilter auto-inserts conversion filters, such that it > > could > > automatically insert a paletteuse filter when downstream requires PAL8. > > PAL8 is tricky, encoders may benefit from similarities in palettes between > frames > for others it might not matter. So automatic insertion may require some > "intelligence" to make the best choice Adding an informative message about palettegen/paletteuse is fine IMHO. Depending on future development and decisions in sws the message can be removed *or* a deprecation added at some point in the future. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] fate: Add a target for listing failed tests
Hi Martin,
still looks good to me.
On 2024-12-04 16:08 +0200, Martin Storsjö wrote:
[...]
> --- a/tests/Makefile
> +++ b/tests/Makefile
> @@ -313,6 +313,12 @@ $(FATE): $(FATE_UTILS:%=tests/%$(HOSTEXESUF)) |
> $(FATE_OUTDIRS)
> fate-list:
> @printf '%s\n' $(sort $(FATE))
>
> +fate-list-failing:
> + @awk -F: '$$2 != 0 { print "fate-" $$1 }' tests/data/fate/*.rep
Unfortunately there is a small problem when calling
fate-list-failing target when no .rep files are present.
The target fails because we cannot open `tests/data/fate/*.rep`.
No output on stdout, which is correct because no test failed,
but we get error messages on stderr and a non-zero exit status.
This was also present in v1, but I just spotted it only today.
For now I found this way to solve it:
@! ls tests/data/fate/*.rep >/dev/null 2>&1 || awk -F: '$$2 != 0 { print
"fate-" $$1 }' tests/data/fate/*.rep
It's a bit expensive, but I couldn't think of something better so far.
Maybe it's good enough for now if there is no better idea?
Could be improved later on if needed.
Best regards,
Alexander
> +
> +fate-clear-results:
> + @rm -f tests/data/fate/*.rep
> +
> coverage.info: TAG = LCOV
> coverage.info:
> $(M)lcov -q -d $(CURDIR) -b $(patsubst src%,./,$(SRC_LINK)) --capture |
> \
> --
___
ffmpeg-devel mailing list
ffmpeg-devel@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] configure: Include quotes around pkg_version
On 2024-12-16 16:19 -0500, Joe Schiffler wrote:
> Since $pkg_version includes spaces, builds can fail in some MSYS environments.
Could you show what the pkg_version with spaces was in your case?
Alexander
> Build passing with quotes:
> https://github.com/JoeSchiff/pyav-ffmpeg/actions/runs/12358403929
>
> Build failing without quotes:
> https://github.com/JoeSchiff/pyav-ffmpeg/actions/runs/12360472377
>
> Signed-off-by: Joe Schiffler
> ---
> configure | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/configure b/configure
> index bf55ba67fa..bb1263a8ce 100755
> --- a/configure
> +++ b/configure
> @@ -1521,7 +1521,7 @@ test_pkg_config(){
> funcs="$4"
> shift 4
> disable $name
> -test_cmd $pkg_config --exists --print-errors $pkg_version || return
> +test_cmd $pkg_config --exists --print-errors "$pkg_version" || return
> pkg_cflags=$($pkg_config --cflags $pkg_config_flags $pkg)
> pkg_libs=$($pkg_config --libs $pkg_config_flags $pkg)
> pkg_incdir=$($pkg_config --variable=includedir $pkg_config_flags $pkg)
> @@ -1541,7 +1541,7 @@ test_pkg_config_cpp(){
> cond="$4"
> shift 4
> disable $name
> -test_cmd $pkg_config --exists --print-errors $pkg_version || return
> +test_cmd $pkg_config --exists --print-errors "$pkg_version" || return
> pkg_cflags=$($pkg_config --cflags $pkg_config_flags $pkg)
> pkg_incdir=$($pkg_config --variable=includedir $pkg_config_flags $pkg)
> pkg_incflags=$($pkg_config --cflags-only-I $pkg_config_flags $pkg)
> --
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mpegvideo_enc: Check FLV1 resolution limits
On 2025-01-08 05:13 +0100, Michael Niedermayer wrote:
> Found-by: Elias Myllymäki
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/mpegvideo_enc.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
> index c5f20c2d855..09df2f52a6c 100644
> --- a/libavcodec/mpegvideo_enc.c
> +++ b/libavcodec/mpegvideo_enc.c
> @@ -567,6 +567,12 @@ av_cold int ff_mpv_encode_init(AVCodecContext *avctx)
> av_log(avctx, AV_LOG_ERROR, "H.263 does not support resolutions
> above 2048x1152\n");
> return AVERROR(EINVAL);
> }
> +if (s->codec_id == AV_CODEC_ID_FLV1 &&
> +(avctx->width > 65535 ||
> + avctx->height > 65535 )) {
> +av_log(avctx, AV_LOG_ERROR, "FLV does not support resolutions above
> 16bit\n");
> +return AVERROR(EINVAL);
> +}
> if ((s->codec_id == AV_CODEC_ID_H263 ||
> s->codec_id == AV_CODEC_ID_H263P ||
> s->codec_id == AV_CODEC_ID_RV20) &&
> --
LGTM
Just out of curiosity, did this just produce broken video streams
before this patch?
Something else only a little related to this patch, but somehow
to this one and all that came before. As this is in ff_mpv_encode_init
and there are dozens of checks like this and the whole function
is around 600 lines, it would be good to refactor this into a
more readable and potentially stronger form.
Best regards,
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/rtpdec: int overflow in start_time_realtime
On 2025-01-10 12:10 +0200, Martin Storsjö wrote:
> On Wed, 8 Jan 2025, j...@jonb.org wrote:
>
> > From: Jonathan Baudanza
> >
> > This was previously adjusted by me in 6b3f9c2e92b.
> > Unfortunately, I traded one integer overflow bug for
> > another.
> >
> > Currently, NTP timestamps that exceed INT64_MAX
> > (~Jan 20, 1968) will cause an overflow when passed
> > to av_rescale.
> >
> > This patch replaces av_rescale, which operates on
> > int64_t, with ff_parse_ntp_time, which operates on
> > uint64_t. This will give the correct values for
> > timestamps back around the NTP epoch and present day
> > timestamps.
> > ---
> > libavformat/rtsp.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> > index c48fa26d90..5ea471b40c 100644
> > --- a/libavformat/rtsp.c
> > +++ b/libavformat/rtsp.c
> > @@ -2320,7 +2320,7 @@ redo:
> > }
> > // Make real NTP start time available in AVFormatContext
> > if (s->start_time_realtime == AV_NOPTS_VALUE) {
> > -s->start_time_realtime = av_rescale
> > (rtpctx->first_rtcp_ntp_time, 100, 1LL << 32) - NTP_OFFSET_US;
> > +s->start_time_realtime =
> > ff_parse_ntp_time(rtpctx->first_rtcp_ntp_time) - NTP_OFFSET_US;
> > if (rtpctx->st) {
> > s->start_time_realtime -=
> > av_rescale_q (rtpctx->rtcp_ts_offset,
> > rtpctx->st->time_base, AV_TIME_BASE_Q);
> > --
> > 2.41.0
>
> Looks ok - I've managed to reproduce this now.
>
> I'll apply this, and backport it to the 7.1 branch.
Thanks Martin!
FTR: I could also reproduce and confirm the fix locally.
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/mov: merge stts and ctts arrays into one
On 2025-01-10 10:40 -0300, James Almer wrote: > On 1/10/2025 10:05 AM, James Almer wrote: > > On 1/7/2025 6:50 PM, Alexander Strasser via ffmpeg-devel wrote: > > > On 2025-01-07 10:55 -0300, James Almer wrote: > > > > Should reduce memory usage as well as remove code duplication. > > > > > > > > Signed-off-by: James Almer > > > > --- > > > > libavformat/isom.h | 15 +- > > > > libavformat/mov.c | 579 --- > > > > tests/ref/fate/quickdraw | 2 +- > > > > 3 files changed, 251 insertions(+), 345 deletions(-) > > > > > > [...] > > > > > > > diff --git a/tests/ref/fate/quickdraw b/tests/ref/fate/quickdraw > > > > index 44610498c8..5746929502 100644 > > > > --- a/tests/ref/fate/quickdraw > > > > +++ b/tests/ref/fate/quickdraw > > > > @@ -9,7 +9,7 @@ > > > > 0, 3, 3, 1, 921600, 0xc0e68764 > > > > 0, 4, 4, 1, 921600, 0xc0e68764 > > > > 0, 5, 5, 1, 921600, 0xc0e68764 > > > > -0, 7, 7, 2, 921600, 0x01a16629 > > > > +0, 7, 7, 1, 921600, 0x01a16629 > > > > > > Why did the duration change? > > > Is it intended? > > > If yes I think it would be better to explain it in the > > > commit message. > > > > Packet durations after this change are all taken from stts entries > > instead of calculated. This sample however is very strange as it has > > five sample entries alongside a longer edit list with unusual values. > > Oh, i found a tiny mistake in the patch that made it take the value from > stts, and as such change the test result. Still, i don't really know what is > more correct here, since the edit list is just weird. But better not change > the behavior for now. Ah cool. Thanks for clarifying. I also agree keeping the behavior shall be better until the matter is understood. > Pushed. Nice simplification! Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] swscale/cms, graph, lut3d: Use ff_-prefix, don't export, internal functions
Hi Andreas! On 2025-01-11 20:40 +0100, Andreas Rheinhardt wrote: > Andreas Rheinhardt: > > Patch attached > > Will apply this patch and my other patches tomorrow unless there are > objections. LGTM from my side (not maintaining any of the affected areas) I just reviewed them and partially tested locally. Nice clean ups. Thank you! Best regards, Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] ffbuild/bin2c: misc fix
On 2025-01-08 19:42 +0800, Jun Zhao wrote:
> From: Jun Zhao
>
> close the input file if open output fail
>
> Signed-off-by: Jun Zhao
> ---
> ffbuild/bin2c.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/ffbuild/bin2c.c b/ffbuild/bin2c.c
> index dfeedd7669..168b0c658d 100644
> --- a/ffbuild/bin2c.c
> +++ b/ffbuild/bin2c.c
> @@ -38,8 +38,10 @@ int main(int argc, char **argv)
> return -1;
>
> output = fopen(argv[2], "wb");
> -if (!output)
> +if (!output) {
> +fclose(input);
> return -1;
> +}
>
> if (argc == 4) {
> name = argv[3];
Not urgent because it's return from main. Anyway LGTM :)
There is another similar instance of this problem down at
the end of the function. Maybe you could also review/test
my attached patch and push on top.
Thanks,
Alexander
From cd8d74d3eddb5ed447e8d59d2288ed1eb328f5e9 Mon Sep 17 00:00:00 2001
From: Alexander Strasser
Date: Sun, 12 Jan 2025 13:52:52 +0100
Subject: [PATCH] ffbuild/bin2c: Also close input stream in case of read errors
Signed-off-by: Alexander Strasser
---
ffbuild/bin2c.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/ffbuild/bin2c.c b/ffbuild/bin2c.c
index 168b0c658d..91f2d81e5b 100644
--- a/ffbuild/bin2c.c
+++ b/ffbuild/bin2c.c
@@ -69,8 +69,10 @@ int main(int argc, char **argv)
fclose(output);
-if (ferror(input) || !feof(input))
+if (ferror(input) || !feof(input)) {
+fclose(input);
return -1;
+}
fclose(input);
--
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avcodec/ffv1enc: Fix handling of 32bit unsigned sambols
On 2025-01-10 05:06 +0100, Michael Niedermayer wrote:
> This may be needed for floats
>
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/ffv1enc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
> index 1a0413895a1..e2db1b41640 100644
> --- a/libavcodec/ffv1enc.c
> +++ b/libavcodec/ffv1enc.c
> @@ -199,7 +199,7 @@ static av_always_inline av_flatten void
> put_symbol_inline(RangeCoder *c,
> } while (0)
>
> if (v) {
> -const int a = FFABS(v);
> +const unsigned a = is_signed ? FFABS(v) : v;
> const int e = av_log2(a);
> put_rac(c, state + 0, 0);
> if (e <= 9) {
> --
LGTM but s/sambols/symbols/ in the Subject/Git-short-message I suspect.
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_opt: Remove audio_drift_threshold
On 2025-01-12 22:19 +0100, Andreas Rheinhardt wrote: > Patch attached > From 1abad60fe2eba199845db35c92e27dbc4d35b93f Mon Sep 17 00:00:00 2001 > From: Andreas Rheinhardt > Date: Sun, 12 Jan 2025 20:40:31 +0100 > Subject: [PATCH] fftools/ffmpeg_opt: Remove audio_drift_threshold > > Forgotten in 5a04aae82193d75b8f8814dc7e35f4cc84b1beba. > > Signed-off-by: Andreas Rheinhardt > --- > fftools/ffmpeg_opt.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c > index 5777c71236..3c0c682594 100644 > --- a/fftools/ffmpeg_opt.c > +++ b/fftools/ffmpeg_opt.c > @@ -52,7 +52,6 @@ HWDevice *filter_hw_device; > > char *vstats_filename; > > -float audio_drift_threshold = 0.1; > float dts_delta_threshold = 10; > float dts_error_threshold = 3600*30; > > -- LGTM (and should be non-controversial to push at this point) Thanks, Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: minor spell fix
On 2025-01-13 19:42 +0100, Leandro Santiago wrote:
> Signed-off-by: Leandro Santiago
> ---
> libavfilter/dnn/dnn_backend_openvino.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/dnn/dnn_backend_openvino.c
> b/libavfilter/dnn/dnn_backend_openvino.c
> index 2f6706dcd4..ec46e29b8a 100644
> --- a/libavfilter/dnn/dnn_backend_openvino.c
> +++ b/libavfilter/dnn/dnn_backend_openvino.c
> @@ -1331,7 +1331,7 @@ static int get_output_ov(DNNModel *model, const char
> *input_name, int input_widt
> #endif
> ret = init_model_ov(ov_model, input_name, output_name ? &output_name
> : NULL, 1);
> if (ret != 0) {
> -av_log(ctx, AV_LOG_ERROR, "Failed init OpenVINO exectuable
> network or inference request\n");
> +av_log(ctx, AV_LOG_ERROR, "Failed init OpenVINO executable
> network or inference request\n");
> return ret;
> }
> }
> @@ -1487,7 +1487,7 @@ static int dnn_execute_model_ov(const DNNModel *model,
> DNNExecBaseParams *exec_p
> ret = init_model_ov(ov_model, exec_params->input_name,
> exec_params->output_names,
> exec_params->nb_output);
> if (ret != 0) {
> -av_log(ctx, AV_LOG_ERROR, "Failed init OpenVINO exectuable
> network or inference request\n");
> +av_log(ctx, AV_LOG_ERROR, "Failed init OpenVINO executable
> network or inference request\n");
> return ret;
> }
> }
> --
LGTM, will push it soon'ish if Guo doesn't beat me to it.
Thanks,
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavutil/avstring: av_match_list: Update API documentation
Since av_match_list was added in commit 0d92b0d5f445d4f2 , this function changed its semantics shortly after, especially with commit 3c0b98dced394da3 . Signed-off-by: Alexander Strasser --- libavutil/avstring.h | 18 +++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/libavutil/avstring.h b/libavutil/avstring.h index fc095349d2..133d021632 100644 --- a/libavutil/avstring.h +++ b/libavutil/avstring.h @@ -409,9 +409,21 @@ int av_utf8_decode(int32_t *codep, const uint8_t **bufp, const uint8_t *buf_end, unsigned int flags); /** - * Check if a name is in a list. - * @returns 0 if not found, or the 1 based index where it has been found in the - *list. + * Check if one of the given names is in a list. + * + * Check if any of the names, given in parameter name, is found at least + * once in the parameter list. + * + * In both parameters, multiple names must be separated by the character + * given in parameter separator. + * + * This is in line e.g. with the rule used for naming demuxers. + * + * @param name Contains names searched for in list. + * @param list List of names that is searched in. + * @param separator Character that separates items in the given lists. + * + * @returns 0 if no match was found, otherwise 1. */ int av_match_list(const char *name, const char *list, char separator); -- ___ ffmpeg-devel mailing list ffmpeg-devel@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] libavutil/avstring: av_match_list: Update API documentation
On 2025-01-22 23:19 +0100, epira...@gmail.com wrote: > > On 22 Jan 2025, at 22:59, Alexander Strasser via ffmpeg-devel wrote: > > > Since av_match_list was added in commit 0d92b0d5f445d4f2 , this > > function changed its semantics shortly after, especially with > > commit 3c0b98dced394da3 . > > > > Signed-off-by: Alexander Strasser > > --- > > libavutil/avstring.h | 18 +++--- > > 1 file changed, 15 insertions(+), 3 deletions(-) > > > > diff --git a/libavutil/avstring.h b/libavutil/avstring.h > > index fc095349d2..133d021632 100644 > > --- a/libavutil/avstring.h > > +++ b/libavutil/avstring.h > > @@ -409,9 +409,21 @@ int av_utf8_decode(int32_t *codep, const uint8_t > > **bufp, const uint8_t *buf_end, > > unsigned int flags); > > > > /** > > - * Check if a name is in a list. > > - * @returns 0 if not found, or the 1 based index where it has been found > > in the > > - *list. > > + * Check if one of the given names is in a list. > > + * > > + * Check if any of the names, given in parameter name, is found at least > > You can use @p to refer to parameters, like: "given in @p name". Good idea! Sent v2. [...] Thanks Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/signalstats: add NULL_IF_CONFIG_SMALL
Hi Abdulrahman!
I fixed up and tested your patch locally and your change looks fine :)
Will include when it when I push my next batch of changes soon'ish.
Depending on how it goes it will take a couple of days from now.
For your information I will outline the broken parts inline below:
On 2025-01-22 20:31 +0200, Abdulrahman Saber wrote:
> On Tue, Jan 14, 2025 at 2:02 PM Abdulrahman Saber
> wrote:
> >
> > Signed-off-by: abdo
> > ---
> > libavfilter/vf_signalstats.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavfilter/vf_signalstats.c b/libavfilter/vf_signalstats.c
> > index b1451cc465..9b6af8becd 100644
> > --- a/libavfilter/vf_signalstats.c
> > +++ b/libavfilter/vf_signalstats.c
> > @@ -20,6 +20,7 @@
> >* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> > 02110-1301 USA
The above line was broken into 2 in your mail.
> >*/
> > +#include "libavutil/internal.h"
> > #include "libavutil/intreadwrite.h"
> > #include "libavutil/mem.h"
> > #include "libavutil/opt.h"
> > @@ -829,7 +830,7 @@ static const AVFilterPad signalstats_outputs[] = {
> >const FFFilter ff_vf_signalstats = {
> > .p.name= "signalstats",
> > -.p.description = "Generate statistics from video analysis.",
> > +.p.description = NULL_IF_CONFIG_SMALL("Generate statistics from
> > video analysis."),
Same here.
> > .p.priv_class = &signalstats_class,
> > .p.flags = AVFILTER_FLAG_SLICE_THREADS,
> > .init = init,
> > --
> > 2.25.1
> >
>
> Ping
Seems like your mail client/editor does it (automatically?) to avoid
overly long lines, which might be fine for email texts but isn't in
patches.
Hope you can find the setting for easier contribution in the future.
Another approach for single patches or small series is to attach them.
Usually mailers don't mess with attachments.
Best regards,
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] libavutil/avstring: av_match_list: Update API documentation
Since av_match_list was added in commit 0d92b0d5f445d4f2 , this function changed its semantics shortly after, especially with commit 3c0b98dced394da3 . Signed-off-by: Alexander Strasser --- Diff to v1: * use @p as suggested by ePirat * clarify that the hint about demuxer names is about FFmpeg libavutil/avstring.h | 18 +++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/libavutil/avstring.h b/libavutil/avstring.h index fc095349d2..1a5405581a 100644 --- a/libavutil/avstring.h +++ b/libavutil/avstring.h @@ -409,9 +409,21 @@ int av_utf8_decode(int32_t *codep, const uint8_t **bufp, const uint8_t *buf_end, unsigned int flags); /** - * Check if a name is in a list. - * @returns 0 if not found, or the 1 based index where it has been found in the - *list. + * Check if one of the given names is in a list. + * + * Check if any of the names, given in @p name, is found at least + * once in @p list. + * + * In both parameters, multiple names must be separated by the character + * given in @p separator. + * + * This is in line e.g. with the rule used for naming demuxers in FFmpeg. + * + * @param name Contains names searched for in list. + * @param list List of names that is searched in. + * @param separator Character that separates items in the given lists. + * + * @returns 0 if no match was found, otherwise 1. */ int av_match_list(const char *name, const char *list, char separator); -- ___ ffmpeg-devel mailing list ffmpeg-devel@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/7] avutil/frame: add a param change side data type
On 2025-01-22 21:18 +0100, Nicolas George wrote:
> James Almer (12025-01-22):
> > Ok, will implement a new struct.
>
> Thanks.
>
> I think this code would work:
>
> typedef struct AVSideDataParamChange
> …
> intmax_t end_padding;
> } AVSideDataSomethingType;
>
> static const AVSideDataParamChange default = { ... };
>
>
> AVSideDataParamChange pc;
> av_assert0(sd->size > sizeof(pc.end_padding));
> size_t s = FFMIN(sd->size - sizeof(pc.end_padding), sizeof(pc));
> memcpy(&pc, sd->data, s);
> memcpy((char *)&pc + s, (char *)&default + s, sizeof(pc) - s);
>
> After this code, pc contains the fields from the side data if they are
> present in the version known by the caller and the fields from default
> otherwise.
>
> I am rather sure this is valid C unless there we add a field with
> individual size greater than end_padding, hence intmax_t.
Sorry, couldn't really follow the problem and this solution idea yet.
Just think we shouldn't use intmax_t as I think it wasn't a good idea
to have it in the C standard at all.
Is it essential for your idea?
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] Backporting makefile targets fate-list-failing and fate-clear-reports
Hi all!
I'm thinking about backporting commit 1e76bd2f394a01c1 [1] to all releases
listed on our download page.
It is a new feature for the build system, but not used to build ffmpeg
or otherwise related to the generated binaries.
It's of utility when doing backports because it makes it easy to run
all fate tests with -k and to get a list of the failed tests after.
Are there any objections to backporting this convenience fate feature?
Best regards,
Alexander
1. commit 1e76bd2f394a01c19073160c380adbcaa779f474 on master:
```
Author: Martin Storsjö
Date: Thu Nov 7 11:31:40 2024 +0200
fate: Add a target for listing failed tests
If running tests with "make -j fate", the execution will stop
after the first failing test. To get an overview of the whole
test suite, one rather would run "make -k -j fate", which then
again buries the results about what tests actually failed further
up in the console log.
Add a target so one can run "make fate-list-failing", to see a list
of all tests that failed the last time they were executed.
Also add a companion target "fate-clear-reports" which removes all
the old test reports. (When executing a subset of tests, the report
files of all tests that aren't executed stay untouched. This also
allows getting rid of reports for tests that no longer are present
in the testsuite.)
Co-authored-by: Alexander Strasser
Signed-off-by: Martin Storsjö
diff --git a/doc/build_system.txt b/doc/build_system.txt
index 0b1b0c2054..053d449862 100644
--- a/doc/build_system.txt
+++ b/doc/build_system.txt
@@ -30,6 +30,13 @@ fate
fate-list
List all fate/regression test targets.
+fate-list-failing
+List the fate tests that failed the last time they were executed.
+
+fate-clear-reports
+Remove the test reports from previous test executions (getting rid of
+potentially stale results from fate-list-failing).
+
install
Install headers, libraries and programs.
diff --git a/doc/fate.texi b/doc/fate.texi
index 17644ce65a..7a2e0edfcc 100644
--- a/doc/fate.texi
+++ b/doc/fate.texi
@@ -208,6 +208,13 @@ Download/synchronize sample files to the configured
samples directory.
@item fate-list
Will list all fate/regression test targets.
+@item fate-list-failing
+List the fate tests that failed the last time they were executed.
+
+@item fate-clear-reports
+Remove the test reports from previous test executions (getting rid of
+potentially stale results from fate-list-failing).
+
@item fate
Run the FATE test suite (requires the fate-suite dataset).
@end table
diff --git a/tests/Makefile b/tests/Makefile
index 9b70145015..f9f5fc07f3 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -313,6 +313,12 @@ $(FATE): $(FATE_UTILS:%=tests/%$(HOSTEXESUF)) |
$(FATE_OUTDIRS)
fate-list:
@printf '%s\n' $(sort $(FATE))
+fate-list-failing:
+ @! ls tests/data/fate/*.rep >/dev/null 2>&1 || awk -F: '$$2 != 0 {
print "fate-" $$1 }' tests/data/fate/*.rep
+
+fate-clear-reports:
+ @rm -f tests/data/fate/*.rep
+
coverage.info: TAG = LCOV
coverage.info:
$(M)lcov -q -d $(CURDIR) -b $(patsubst src%,./,$(SRC_LINK)) --capture |
\
```
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avformat/vqf: Propagate errors from add_metadata()
On 2025-01-01 06:15 +0100, Michael Niedermayer wrote:
> Suggested-by: Marton Balint
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/vqf.c | 21 ++---
> 1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/libavformat/vqf.c b/libavformat/vqf.c
> index 79deb33744b..58b1546f531 100644
> --- a/libavformat/vqf.c
> +++ b/libavformat/vqf.c
> @@ -51,23 +51,28 @@ static int vqf_probe(const AVProbeData *probe_packet)
> return AVPROBE_SCORE_EXTENSION;
> }
>
> -static void add_metadata(AVFormatContext *s, uint32_t tag,
> +static int add_metadata(AVFormatContext *s, uint32_t tag,
> unsigned int tag_len, unsigned int remaining)
> {
> int len = FFMIN(tag_len, remaining);
> char *buf, key[5] = {0};
> +int ret;
>
> if (len == UINT_MAX)
> -return;
> +return AVERROR_INVALIDDATA;
>
> buf = av_malloc(len+1);
> if (!buf)
> -return;
> -if (len != avio_read(s->pb, buf, len))
> -return;
> +return AVERROR(ENOMEM);
> +
> +ret = avio_read(s->pb, buf, len);
> +if (ret < 0)
> +return ret;
> +if (len != ret)
> +return AVERROR_INVALIDDATA;
> buf[len] = 0;
> AV_WL32(key, tag);
> -av_dict_set(&s->metadata, key, buf, AV_DICT_DONT_STRDUP_VAL);
> +return av_dict_set(&s->metadata, key, buf, AV_DICT_DONT_STRDUP_VAL);
> }
>
> static const AVMetadataConv vqf_metadata_conv[] = {
> @@ -165,7 +170,9 @@ static int vqf_read_header(AVFormatContext *s)
> avio_skip(s->pb, FFMIN(len, header_size));
> break;
> default:
> -add_metadata(s, chunk_tag, len, header_size);
> +ret = add_metadata(s, chunk_tag, len, header_size);
> +if (ret < 0)
> +return ret;
> break;
> }
>
> --
LGTM regarding my review comments.
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avfilter/vf_addroi: Add missing NULL termination to addroi_var_names[]()
On 2025-01-05 05:44 +0100, Michael Niedermayer wrote:
> Fixes: out of array read
>
> Found-by: Elias Myllymäki
> Signed-off-by: Michael Niedermayer
> ---
> libavfilter/vf_addroi.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavfilter/vf_addroi.c b/libavfilter/vf_addroi.c
> index de857eced44..d6765e9d8cb 100644
> --- a/libavfilter/vf_addroi.c
> +++ b/libavfilter/vf_addroi.c
> @@ -39,6 +39,7 @@ enum {
> static const char *const addroi_var_names[] = {
> "iw",
> "ih",
> +NULL,
> };
>
> typedef struct AddROIContext {
> --
LGTM
Thanks,
Alexander
P.S.
It's a bit funny how we talk in allmost all filters about
variables because these are called constants when it comes
down to the av_expr_parse_and_eval call.
Guess it's a point of view thing. From filter POV they
can be variable, from the POV of the single expression
evaluation they are constant :)
___
ffmpeg-devel mailing list
ffmpeg-devel@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] configure: Include quotes around pkg_version
On 2024-12-21 19:29 -0500, J Shiff wrote: > On Sat, Dec 21, 2024 at 5:44 PM Alexander Strasser via ffmpeg-devel > wrote: > > > > On 2024-12-16 16:19 -0500, Joe Schiffler wrote: > > > Since $pkg_version includes spaces, builds can fail in some MSYS > > > environments. > > > > Could you show what the pkg_version with spaces was in your case? > > The value of pkg_version would be: `aom >= 2.0.0` Ok, thanks for coming back to this! What is still strange about it: What changed and where? These values for pkg_version should come up on every platform and AFAICT it works just fine for me and many others. Didn't spot any relevant changes in ffmpeg configure on a quick look. Would be better to understand why it fails only in some environments and not others. Alexander > However, this was because aom was the first package included in the build. > If I disabled aom, then the next package (dav1d) would give a similar > error, and so on. > > I get this error message found in ffbuild/config.log: > `Can't find >=.pc in any of` ... > > The message should be: > `Can't find aom.pc in any of` ... > > The ellipsis represents the value of the PKG_CONFIG_PATH environment variable. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/5] lavc/container_fifo: move to lavu and make public
On 2024-12-15 22:20 +0100, Alexander Strasser via ffmpeg-devel wrote:
> On 2024-12-11 15:05 +0100, Anton Khirnov wrote:
> > This can be useful in other places, e.g. it can replace objpool in
> > fftools.
> >
> > The API is modified in the following nontrivial ways:
> > * opaque pointers can be passed through to all user callbacks
> > * read and write were previously separate callbacks in order to
> > accomodate the caller wishing to write a new reference to the FIFO and
> > keep the original one; the two callbacks are now merged into one, and
> > a flags argument is added that allows to request such behaviour on a
> > per-call basis
> > * new peek and drain functions
> > ---
> > doc/APIchanges | 5 +-
> > libavcodec/Makefile| 2 +-
> > libavcodec/container_fifo.h| 89 --
> > libavcodec/hevc/hevcdec.c | 10 +-
> > libavcodec/hevc/hevcdec.h | 2 +-
> > libavcodec/hevc/refs.c | 4 +-
> > libavutil/Makefile | 2 +
> > {libavcodec => libavutil}/container_fifo.c | 116 ++
> > libavutil/container_fifo.h | 130 +
> > 9 files changed, 215 insertions(+), 145 deletions(-)
> > delete mode 100644 libavcodec/container_fifo.h
> > rename {libavcodec => libavutil}/container_fifo.c (51%)
> > create mode 100644 libavutil/container_fifo.h
> >
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index 13789fcea4..5d75b6077d 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -2,10 +2,13 @@ The last version increases of all libraries were on
> > 2024-03-07
> >
> > API changes, most recent first:
> >
> > -2024-12-xx - xx - lavu 59.50.100 - refstruct.h
> > +2024-12-xx - xx - lavu 59.50.100 - refstruct.h container_fifo.h
> >Add a new public header refstruct.h with new API for
> >reference-counted objects.
> >
> > + Add a new public header container_fifo.h with new API for
> > + a FIFO of container objects (e.g. AVFrame or AVPacket).
>
> I see this was already pushed.
>
> I wanted to comment mainly because of the naming. Didn't deeply
> check the series as a whole, but AFAICS it looks legit.
>
> I find the "container" part of the naming consusing, especially in
> a multimedia project.
>
> Didn't yet have brilliant ideas.
> Some suggestions to get started follow in no particular order:
>
> * objpool_fifo
> * reusable_obj_fifo
> * refstruct_fifo
Polite ping.
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] Pausing the heated discussions
Hi all! I'm unhappy with what ensued here on the FFmpeg development mailing list; especially in the recent months. With the current culminations, and the stress and influx of mails it caused for all subscribers espescially in this for many of us rather busy time of the family year, I would like to see a pause of all personal attacks and project political mails until at least 2025-01-15 UTC. Of course I would ideally like to see no more personal attacks in the future, but that hasn't worked out so far, so I expect at least some outliers will unfortunately turn up once discussions start again. I hope for collaboration from you all and support of the newly elected Community Committee (CC). Wish all of you a happy new year (later or now for all of you that are already in 2025)! Best regards, Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc: Remove libav-merge.txt
--- Begin Message --- Hi Derek, I didn't see this before commenting on your libav-merge-next-commit removal patch. Should be OK if there is nothing of use in left in the section TODO/FIXME/UNMERGED . On 2025-06-23 21:15 +0100, Derek Buitenhuis wrote: > He's dead, Jim. I would appreciate it if you could change the commit message to something that is a bit more boring (tho yours is kind of funny if one gets the reference). Or maybe just combine this with libav-merge-next-commit removal. Best regards, Alexander > Signed-off-by: Derek Buitenhuis > --- > doc/libav-merge.txt | 115 > 1 file changed, 115 deletions(-) > delete mode 100644 doc/libav-merge.txt > > diff --git a/doc/libav-merge.txt b/doc/libav-merge.txt > deleted file mode 100644 > index bcd0aacba5..00 > --- a/doc/libav-merge.txt > +++ /dev/null > @@ -1,115 +0,0 @@ > -CONTEXT > -=== > - > -The FFmpeg project merges all the changes from the Libav project > -(https://libav.org) since the origin of the fork (around 2011). > - > -With the exceptions of some commits due to technical/political disagreements > or > -issues, the changes are merged on a more or less regular schedule (daily for > -years thanks to Michael, but more sparse nowadays). > - > -WHY > -=== > - > -The majority of the active developers believe the project needs to keep this > -policy for various reasons. > - > -The most important one is that we don't want our users to have to choose > -between two distributors of libraries of the exact same name in order to > have a > -different set of features and bugfixes. By taking the responsibility of > -unifying the two codebases, we allow users to benefit from the changes from > the > -two teams. > - > -Today, FFmpeg has a much larger user database (we are distributed by every > -major distribution), so we consider this mission a priority. > - > -A different approach to the merge could have been to pick the changes we are > -interested in and drop most of the cosmetics and other less important > changes. > -Unfortunately, this makes the following picks much harder, especially since > the > -Libav project is involved in various deep API changes. As a result, we decide > -to virtually take everything done there. > - > -Any Libav developer is of course welcome anytime to contribute directly to > the > -FFmpeg tree. Of course, we fully understand and are forced to accept that > very > -few Libav developers are interested in doing so, but we still want to > recognize > -their work. This leads us to create merge commits for every single one from > -Libav. The original commit appears totally unchanged with full authorship in > -our history (and the conflict are solved in the merge one). That way, not a > -single thing from Libav will be lost in the future in case some reunification > -happens, or that project disappears one way or another. > - > -DOWNSIDES > -= > - > -Of course, there are many downsides to this approach. > - > -- It causes a non negligible merge commits pollution. We make sure there are > - not several level of merges entangled (we do a 1:1 merge/commit), but it's > - still a non-linear history. > - > -- Many duplicated work. For instance, we added libavresample in our tree to > - keep compatibility with Libav when our libswresample was already covering > the > - exact same purpose. The same thing happened for various elements such as > the > - ProRes support (but differences in features, bugs, licenses, ...). There > are > - many work to do to unify them, and any help is very much welcome. > - > -- So much manpower from both FFmpeg and Libav is lost because of this mess. > We > - know it, and we don't know how to fix it. It takes incredible time to do > - these merges, so we have even less time to work on things we personally > care > - about. The bad vibes also do not help with keeping our developers > motivated. > - > -- There is a growing technical risk factor with the merges due to the > codebase > - differing more and more. > - > -MERGE GUIDELINES > - > - > -The following gives developer guidelines on how to proceed when merging > Libav commits. > - > -Before starting, you can reduce the risk of errors on merge conflicts by > using > -a different merge conflict style: > - > -$ git config --global merge.conflictstyle diff3 > - > -tools/libav-merge-next-commit is a script to help merging the next commit in > -the queue. It assumes a remote named libav. It has two modes: merge, and > noop. > -The noop mode creates a merge with no change to the HEAD. You can pass a hash > -as extra argument to reference a justification (it is common that we already > -have the change done in FFmpeg). > - > -Also see tools/murge, you can copy and paste a 3 way conflict into its stdin > -and it will display colored diffs. Any arguments to murge (like ones to > suppress > -whitespace differences) are passed into colordiff. > - >
Re: [FFmpeg-devel] [PATCH] Changelog: mention dropping OpenSSL < 1.1.0
--- Begin Message --- On 2025-07-07 15:57 +0200, Marvin Scholz wrote: > --- > Changelog | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Changelog b/Changelog > index f5ec9eafc3..0beefb73f6 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 : > +- Drop support for OpenSSL < 1.1.0 > - yasm support dropped, users need to use nasm > - VVC VAAPI decoder > - RealVideo 6.0 decoder LGTM and in line with your recent pushes Thanks, Alexander --- End Message --- ___ ffmpeg-devel mailing list ffmpeg-devel@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 v8 14/18] swscale/ops_memcpy: add 'memcpy' backend for plane->plane copies
On 2025-07-12 12:44 +0200, Niklas Haas wrote:
> From: Niklas Haas
>
> Provides a generic fast path for any operation list that can be decomposed
> into a series of memcpy and memset operations.
>
> 25% faster than the x86 backend for yuv444p -> yuva444p
> 33% faster than the x86 backend for gray -> yuvj444p
> ---
> libswscale/Makefile | 1 +
> libswscale/ops.c| 2 +
> libswscale/ops_memcpy.c | 132
> 3 files changed, 135 insertions(+)
> create mode 100644 libswscale/ops_memcpy.c
>
> diff --git a/libswscale/Makefile b/libswscale/Makefile
> index d3cb7bc555..0fed799542 100644
> --- a/libswscale/Makefile
> +++ b/libswscale/Makefile
> @@ -18,6 +18,7 @@ OBJS = alphablend.o \
> ops.o\
> ops_backend.o\
> ops_chain.o \
> + ops_memcpy.o \
> ops_optimizer.o \
> options.o\
> output.o \
> diff --git a/libswscale/ops.c b/libswscale/ops.c
> index 2d8f9e6084..76423f631e 100644
> --- a/libswscale/ops.c
> +++ b/libswscale/ops.c
> @@ -28,8 +28,10 @@
> #include "ops_internal.h"
>
> extern SwsOpBackend backend_c;
> +extern SwsOpBackend backend_murder;
>
> const SwsOpBackend * const ff_sws_op_backends[] = {
> +&backend_murder,
> &backend_c,
> NULL
> };
> diff --git a/libswscale/ops_memcpy.c b/libswscale/ops_memcpy.c
> new file mode 100644
> index 00..ef4784faa4
> --- /dev/null
> +++ b/libswscale/ops_memcpy.c
[...]
> +
> +SwsOpBackend backend_murder = {
> +.name= "memcpy",
> +.compile = compile,
> +};
Is this intentional?
While everything is name `memcpy` the variables are namend `_murder`?
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] Introducing policies regarding "AI" contributions
--- Begin Message --- On 2025-07-01 16:50 +0530, Gyan Doshi wrote: > > On 2025-07-01 04:28 pm, Alexander Strasser via ffmpeg-devel wrote: > > > Thus I want this thread to start a discussion, that eventually leads > > to a policy about submitting and integrating "AI" generated content. > > In practice. unless a patch(set) is explicitly marked or has telltale signs > of being AI-generated,the project can't stop such AI code getting in. > At best, we can require disclosure and for the human submitter to assume > responsibility. That's true. It's impossible to completely enforce adherence to a policy that bans "AI" generated code. I guess it would still be worthwhile to just do what you said. From what I have looked at in the other projects so far (musl, gentoo, llvm), they acknowledge too that they cannot enforce it. In a way it's nothing new and actually since forever we would not want to accept contributions of dubious or license-incompatible origins. Just the current times seem to warrant spelling this out, I fear. So maybe just generically writing about it and explicitly mentioning "AI" would be the better way to achieve the goal. Thanks for commenting! Best regards, Alexander --- End Message --- ___ ffmpeg-devel mailing list ffmpeg-devel@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] Introducing policies regarding "AI" contributions
--- Begin Message --- On 2025-07-03 02:16 +0200, Gerion Entrup wrote: > Am Dienstag, 1. Juli 2025, 12:58:23 Mitteleuropäische Sommerzeit schrieb > Alexander Strasser via ffmpeg-devel: [...] > > Thus I want this thread to start a discussion, that eventually leads > > to a policy about submitting and integrating "AI" generated content. > > > > Leaving all ethical issues aside for a moment I still see 2 very big > > problems with AI generated code: > > > > * looks generally plausible but is often subtly wrong > > * leading to more work, regressions and costs > > * which often lands on a different group of people (other > > projects, reviewers, bug finders, bug fixers, etc.) > > * which are sometimes delayed for quite some time increasing > > the costs of fixing them > > * license/copyright violations > > * this might be sometimes a non-issue with small changes > > * but especially for complete components the risk seems high > > > > There is a lot more to the topic and I probably forgot to bring up > > many more important aspects and details. Please feel free to bring > > more things up in the discussion! > > > > There was a preparation in the musl project to put up a policy[2], > > it has not yet been finalized and realized as far as I understand. > > Just to link it here. Remembers me on the Gentoo Linux discussion: > https://archives.gentoo.org/gentoo-dev/9007c921a8a57655ecb2027eb4be4bff02673af4.ca...@zougloub.eu/T/#t > https://wiki.gentoo.org/wiki/Project:Council/AI_policy Thanks for the links to the Gentoo discussion and policy! IMHO the discussion and the resulting policy is interesting and maybe something similar would be appropriate for FFmpeg. I also became aware of LLVM policy: https://llvm.org/docs/DeveloperPolicy.html#ai-generated-contributions But I must say I do not like it as much. To cite the most critical part: As such, the LLVM policy is that contributors are permitted to use artificial intelligence tools to produce contributions, provided that they have the right to license that code under the project license. Contributions found to violate this policy will be removed just like any other offending contribution. For "AI" (in the LLM sense) I think it's usually not at all easy to say if one has the right to license the code given it's trained on a huge corpus of copyrighted and particularly licensed code. Anyway they agree on license/copyright concern I raised. As does Gentoo. And the LLVM policy also comes to a similar conclusions, as does Gentoo, regarding waste of project resources: We encourage contributors to review all generated code before sending it for review to verify its correctness and to understand it so that they can answer questions during code review. Reviewing and maintaining generated code that the original contributor does not understand is not a good use of limited project resources. If anyone has more examples at hand, it would probably be interesting to know and take a look. Best regards, Alexander > > It also brings up the point, that it is not really related to > > recent "AI" tech, but more to the origin of work and its handling. > > Unfortunately "AI" made problems with this a lot more common. > > > > > > Best regards, > > Alexander > > > > 1. https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-April/342146.html > > 2. https://www.openwall.com/lists/musl/2024/10/19/3 --- End Message --- ___ ffmpeg-devel mailing list ffmpeg-devel@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] Introducing policies regarding "AI" contributions
--- Begin Message --- On 2025-07-01 14:44 +0200, Kacper Michajlow wrote: > On Tue, 1 Jul 2025 at 12:58, Alexander Strasser via ffmpeg-devel [...] > > > > I do not like the branding of the LLMs as AI, thus I will for now > > continue to call it "AI" in quotes. I'm open for better terms. > > > > It was just yesterday brought up on IRC in #ffmpeg-devel that there > > was at least one, marked attempt to include "AI" generated code[1]. > > > > At least I would say that this particular patch series was rejected, > > but there were was no explicit discussion and clear statement about > > "AI" generated content; especially code. > > > > Thus I want this thread to start a discussion, that eventually leads > > to a policy about submitting and integrating "AI" generated content. > > I don't think labeling code as "AI" matters that much. Let's ignore > licensing/legal issues for now. OK, but I really don't think we can ignore the legal consequences for FFmpeg, as it is Open Source software, and we would put all users of FFmpeg, individuals and companies, at risk. > What's important is the code itself and its quality. It doesn't matter > how it was created. Whether by a human, "AI" or something else. The > key is the final product. "AI" is just a tool, and like any tool, it > can be used well or poorly. How you use it may be completely different > between "operators". > > I think the "AI" label exists because the code that LLMs produce is > often incomplete, low quality, and a pile of spaghetti that somehow > works for a single use case. but is far from being a sane, production > ready implementation. Anyone who has used these tools knows their > limitations and what they can or cannot do. > > That said, if "AI" code means low quality code, then by all means, it > should be rejected. This applies to human, alien, or "AI" generated > code. There shouldn't be a different metric for "AI" code. If "AI" > (and its "operator") produces high quality code, there's no reason to > reject it. > > After all, how can you even detect "AI" code? If the code, regardless > of who or what wrote it, follows project guidelines and is overall > high quality, that's all that matters. I kind of agree that good code is good code, but it's not enough. Important is also having people around that truly understand the good code. To find out if it is truly good code someone needs to review it very deeply, which is extra hard if it is "AI" generated code as it tends to look very plausible; which could waste a lot of time for the people looking at it and reviewing it. This also diminishes the actual value of the use of "AI" in the first place. Taking that for granted there is the open question for submissions by maintainers (with git push access), who could submit "AI" generated code and push it themselves after a considerable push warning. > P.S. I don't like those "This code was fully made by an LLM" > statements and the like. Who cares? Maybe some investor who's pushing > this. But from a technical point of view, there's no difference. After > all, you don't start your patchset by saying, "This code was written > in Vim with on Arch Linux, on an ergonomic split > keyboard, with an XYZ monitor.". [...] Thanks for your feed back! Greetings, Alexander --- End Message --- ___ ffmpeg-devel mailing list ffmpeg-devel@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] Introducing policies regarding "AI" contributions
--- Begin Message --- On 2025-07-05 14:20 +0300, Rémi Denis-Courmont wrote: > Le tiistaina 1. heinäkuuta 2025, 13.58.23 Itä-Euroopan kesäaika Alexander > Strasser via ffmpeg-devel a écrit : > > (...) I want this thread to start a discussion, that eventually leads > > to a policy about submitting and integrating "AI" generated content. > > Well, you can define a policy and/or make a public statement on FFmpeg.org, > but > as others said, just like we can't prevent someone misattributing their > contributions and violating copyrights, we can't credibly prevent (mis)use of > LLMs to generate code. Yes, that's what I had in mind. At least it provides a place where we could point people to when we detect such submissions. Also I believe it will help on its own as far as people find it and read it. > There is also a problem of definition. While I don't personally use computer > assistance, I think it's fine to use language servers to automatically > generate > or suggests boilerplate, possible contextual completions, etc. While this > sort > of technology predates LLMs and is clearly distinct from it **at the > moment**, > it's going to be hard to define "AI" and where to draw a line. I don't think this has the same problems. My intention was to cover "AI" in the current form where it means LLMs trained on a huge corpus of code under many licenses and probably a lot without license at at all. > Ultimately, I think you need to define the problem(s) as far as FFmpeg-devel > is > concerned. Potential copyright violations are not new, and I think the > current > policies and license terms are adequate, regardless of AI. > > Low quality patches are also not really a new problem, and they can be > rejected with the current processes too. > > *Maybe* LLM usage will (willingly or unwittingly) lead to a denial of service > attacks on the review capacity and motivation of the FFmpeg-devel, TC and GA > membership, but that remains highly speculative, and I think we don't need to > solve that what-if problem yet. And again, this attack does not necessarily > need an LLM to be carried. I fear that could happen. In general the usage of LLMs for codegen mostly shifts the line of work in an unfavourable way :( It also makes it possible with little effort to create a lot of code. Code in itself is not really valuable though. Having people that understand the code and maintain it are! I agree that we might not need to react to that ahead of time, but in general the review capacity in FFmpeg is too low since a long time. So I guess it's better to watch closely. Best regards, Alexander --- End Message --- ___ ffmpeg-devel mailing list ffmpeg-devel@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] Introducing policies regarding "AI" contributions
--- Begin Message --- Hi Michael! On 2025-07-04 12:15 +0200, Michael Niedermayer wrote: > The use of tools to assist developers is growing and will > continue to grow. Its not going away. > And what one can and cannot do with these tools will evolve > > I dont think i understand the thought process behind this policy. I did not propose any policy in particular yet. So I'm not sure what you are referring to. > Licenses need to be complied to, code needs to be of good quality. With the way the technology works, I can't see how the quality goals should be reached, but maybe someone else can explain it. Sure it can support. Or give inspiration like Nicolas mentioned and you rewrite it almost completely before submission. More importantly I see no way for the license part to work out automagically. In how far is the result a derivative other works? How would we apply attribution where original works demand it? How do we now the generated code is not just a mostly exact copy of the original training material? We cannot just relicense e.g. GPL as LGPL. So I would say at least some policy stating the obvious and that it also applies to LLM outputs is in order. It's not about being able to control it, but to make it more visible and also what I replied to Remi. Pointing people to it and increasing awareness. Maybe encouraging marking of LLM generated content be it in code (docs), tickets or mails would also be a good idea. [Remainder of your mail skipped that seems not relevant to this discussion] Best regards, Alexander --- End Message --- ___ ffmpeg-devel mailing list ffmpeg-devel@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 v8 14/18] swscale/ops_memcpy: add 'memcpy' backend for plane->plane copies
Hi Niklas!
On 2025-07-14 10:51 +0200, Niklas Haas wrote:
> On Sun, 13 Jul 2025 19:04:21 +0200 Alexander Strasser via ffmpeg-devel
> wrote:
> > On 2025-07-12 12:44 +0200, Niklas Haas wrote:
[...]
> > > +
> > > +SwsOpBackend backend_murder = {
> > > +.name= "memcpy",
> > > +.compile = compile,
> > > +};
> >
> > Is this intentional?
> > While everything is name `memcpy` the variables are namend `_murder`?
>
> It's an (IMO) harmless joke. I can remove it if you'd prefer.
I would prefer it, but if you want to keep it that's also fine with me!
If you do change it, don't re-send the series only because of that change.
Just wanted to make sure it's intentional. Personally I'm fine with such
things, it just is a bit weird when you don't get the joke.
I don't dare to ask about the joke, because of the usual disclaimers for
explaining jokes *lol
Jokes aside; one rather minor thing it definitely makes a bit worse is
text searching for `backend_memcpy` where you won't find where it is
registered because you failed to search for `backend_murder` instead.
Best regards,
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [POLL] [VOTE] code.ffmpeg.org
On 2025-07-13 13:43 +0200, Michael Niedermayer wrote: > Hi all > > Do people want Forgejo or Gitlab on code.ffmpeg.org for testing? > > F. code.ffmpeg.org should run Forgejo > G. code.ffmpeg.org should run Gitlab F. * the UI is more intuitive IMHO and I suspect it will be to the majority of newcomers * Gitlab follows the Open Core model which is prone to all kinds of unwanted developments * I actually did look a little at the sources and didn't get far with Gitlab where in Forgejo I could find my way around easily For Gitlab it was hard to find the source to begin with, when starting at their website. After multiple hops and wading through lists I ended up here: https://gitlab.com/gitlab-org/gitlab/ Later I randomly found out - by inspecting the README going to one of their web pages because of a different reason - that there is also: https://gitlab.com/gitlab-org/gitlab-foss/ For Forgejo it's scrolling down the home page and click a button or on every page in the footer via "Community Code". You are instantly on the repo hosted on Codeberg: https://codeberg.org/forgejo/forgejo Some superficial stats from a bit of line counting to get a feeling: | SLOC without comments | backend | frontend | --- | - | --- | | gitlab |~4_600_000 | 70% | 30% | gitlab-foss |~2_900_000 | 70% | 30% | forgejo | ~416_440 | 90% | 10% | To be fair, I didn't do any deeper analysis and be sure to take this numbers with a grain of salt. There is a mismatch of features etc. between these code bases and so we cannot just compare them easily. There are lots of features in Gitlab that we probably would never use. The ancestor of Forgejo is Gogs. Gogs initially achieved something quite remarkable. It provided a lot with very little. As far as I can judge this also transferred and to its forks Gitea/Forgejo and still mostly holds. If the Forgejo code base and project is the best in 5 years or in 10 years is not easily to be predicted today, but I would say the project has good chances to be in good shape. Currently I don't see any clearly better alternatives. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [RFC] Introducing policies regarding "AI" contributions
--- Begin Message --- Hi all, I do not like the branding of the LLMs as AI, thus I will for now continue to call it "AI" in quotes. I'm open for better terms. It was just yesterday brought up on IRC in #ffmpeg-devel that there was at least one, marked attempt to include "AI" generated code[1]. At least I would say that this particular patch series was rejected, but there were was no explicit discussion and clear statement about "AI" generated content; especially code. Thus I want this thread to start a discussion, that eventually leads to a policy about submitting and integrating "AI" generated content. Leaving all ethical issues aside for a moment I still see 2 very big problems with AI generated code: * looks generally plausible but is often subtly wrong * leading to more work, regressions and costs * which often lands on a different group of people (other projects, reviewers, bug finders, bug fixers, etc.) * which are sometimes delayed for quite some time increasing the costs of fixing them * license/copyright violations * this might be sometimes a non-issue with small changes * but especially for complete components the risk seems high There is a lot more to the topic and I probably forgot to bring up many more important aspects and details. Please feel free to bring more things up in the discussion! There was a preparation in the musl project to put up a policy[2], it has not yet been finalized and realized as far as I understand. It also brings up the point, that it is not really related to recent "AI" tech, but more to the origin of work and its handling. Unfortunately "AI" made problems with this a lot more common. Best regards, Alexander 1. https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2025-April/342146.html 2. https://www.openwall.com/lists/musl/2024/10/19/3 --- End Message --- ___ ffmpeg-devel mailing list ffmpeg-devel@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] configure: Make MSVC version grabbing more robust
--- Begin Message ---
On 2025-06-21 00:03 +0200, Kacper Michajlow wrote:
> On Fri, 20 Jun 2025 at 22:26, Hendrik Leppkes
> wrote:
> >
> > On Fri, Jun 20, 2025 at 9:25 PM Timo Rothenpieler
> > wrote:
> > >
> > > On 19.06.2025 22:21, Martin Storsjö wrote:
> > > > On Fri, 13 Jun 2025, Martin Storsjö wrote:
> > > >
> > > >> When running plain "cl", to get the MSVC version, it prints the
> > > >> version header on stderr, while the usage instructions are printed
> > > >> on stdout. Usually, the version on stderr gets flushed first,
> > > >> so "head -n1" gets the line it expects, but some times (in particular
> > > >> when running MSVC wrapped in wine), it can get the usage line
> > > >> first.
> > > >>
> > > >> Redirect stdout to /dev/null, so we only grab the version among
> > > >> the lines printed to stderr. This should make the version number
> > > >> grabbing more robust.
> > > >>
> > > >> At least all relevant versions of MSVC seem to print this specifically
> > > >> to stderr, not stdout (so we don't risk to miss it); checked down
> > > >> to MSVC 2010.
> > > >> ---
> > > >> This should avoid the occasionally misdetected version number lines
> > > >> as seen at
> > > >> https://fate.ffmpeg.org/history.cgi?slot=x86_64-msvc2022-wine.
> > > >> ---
> > > >> configure | 5 -
> > > >> 1 file changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > Will push.
> > >
> > > Likely this patch broke multiple fate runners in a silent way.
> > > On mine, configure simply never returns, and just sits there
> > > indefinitely, with no CPU usage or any activity whatsoever.
> > >
> > > nevcairiel confirmed seeing the same behaviour on IRC.
> > >
> > > The msys+clang builds from within the same environment work fine.
> > >
> > >
> > > Didn't verify completely if it's caused by this patch, but nothing else
> > > happened with configure since the last successful run.
> >
> > I did some digging, and it happens when probe_cc probes link.exe
> >
> > link.exe has an interactive help output (its paginated) - previously
> > piping stdout disabled the pagination automatically - but redirecting
> > it to devnull does not, and it gets stuck waiting for input.
> > Additionally, link.exe outputs the ident on stdout, so there is no
> > result on stderr (not super bad, as LD_IDENT is never used - yet)
>
> Instead of redirecting to devnull, we could use the same condition as
> in if. We already look for specific ident line, so no need to head.
> _ident=$($_cc -nologo- 2>&1 | grep ^Microsoft | tr -d '\r')
> should work, no? I would be happy to see a better solution, though.
I think making sure to only use the first line that starts with
Microsoft is more robust; there could be (in the future) more lines
that start with Microsoft.
> btw. running cl.exe 3 times to just get its name is interesting :)
Yes, so that as well. Could be optimized, but is probably not so
relevant in total.
I propose the attached patch.
Alexander
From f97df3657ab73573659d7738ac55d688c5744bf9 Mon Sep 17 00:00:00 2001
From: Alexander Strasser
Date: Sat, 21 Jun 2025 11:13:22 +0200
Subject: [PATCH] configure: Fix a regression when probing link.exe
The version ident is printed on stdout for link.exe and redirecting
stdout to /dev/null will cause the output of link.exe to be paged.
---
configure | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index 708ecd9025..ce027d3845 100755
--- a/configure
+++ b/configure
@@ -5130,10 +5130,9 @@ probe_cc(){
elif $_cc -nologo- 2>&1 | grep -q ^Microsoft || { $_cc -v 2>&1 | grep -q
clang && $_cc -? > /dev/null 2>&1; }; then
_type=msvc
if $_cc -nologo- 2>&1 | grep -q ^Microsoft; then
-# The version number is printed on the first line on stderr, stdout
-# gets the usage instructions. Only include stderr, to avoid
-# potential ordering race conditions.
-_ident=$($_cc 2>&1 >/dev/null | head -n1 | tr -d '\r')
+# Depending on the tool (cl.exe or link.exe), the version number
+# is printed on the first line of stderr or stdout
+_ident=$($_cc 2>&1 | grep ^Microsoft | head -n1 | tr -d '\r')
else
_ident=$($_cc --version 2>/dev/null | head -n1 | tr -d '\r')
fi
--
2.49.0
--- End Message ---
___
ffmpeg-devel mailing list
ffmpeg-devel@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] configure: Make MSVC version grabbing more robust
--- Begin Message ---
Hi Martin!
On 2025-06-21 13:37 +0300, Martin Storsjö wrote:
> > On 21. Jun 2025, at 12.20, Alexander Strasser via ffmpeg-devel
> > wrote:
> >
> >
> > On 2025-06-21 00:03 +0200, Kacper Michajlow wrote:
> >> On Fri, 20 Jun 2025 at 22:26, Hendrik Leppkes
> >> wrote:
> >>>
> >>> On Fri, Jun 20, 2025 at 9:25 PM Timo Rothenpieler
> >>> wrote:
> >>>>
> >>>> Likely this patch broke multiple fate runners in a silent way.
> >>>> On mine, configure simply never returns, and just sits there
> >>>> indefinitely, with no CPU usage or any activity whatsoever.
> >>>>
> >>>> nevcairiel confirmed seeing the same behaviour on IRC.
> >>>>
> >>>> The msys+clang builds from within the same environment work fine.
> >>>>
> >>>>
> >>>> Didn't verify completely if it's caused by this patch, but nothing else
> >>>> happened with configure since the last successful run.
> >>>
> >>> I did some digging, and it happens when probe_cc probes link.exe
> >>>
> >>> link.exe has an interactive help output (its paginated) - previously
> >>> piping stdout disabled the pagination automatically - but redirecting
> >>> it to devnull does not, and it gets stuck waiting for input.
> >>> Additionally, link.exe outputs the ident on stdout, so there is no
> >>> result on stderr (not super bad, as LD_IDENT is never used - yet)
> >>
> >> Instead of redirecting to devnull, we could use the same condition as
> >> in if. We already look for specific ident line, so no need to head.
> >> _ident=$($_cc -nologo- 2>&1 | grep ^Microsoft | tr -d '\r')
> >> should work, no? I would be happy to see a better solution, though.
> >
> > I think making sure to only use the first line that starts with
> > Microsoft is more robust; there could be (in the future) more lines
> > that start with Microsoft.
> >
> >> btw. running cl.exe 3 times to just get its name is interesting :)
> >
> > Yes, so that as well. Could be optimized, but is probably not so
> > relevant in total.
> >
> > I propose the attached patch.
> >
> >
> > Alexander
> > <0001-configure-Fix-a-regression-when-probing-link.exe.patch>
>
> Thanks, this patch looks good to me, feel free to push! (And I can push it
> later today if nobody else does it before that.)
>
> If you want to, one can also extend the commit message further to say more
> explicitly, that 45a30e03613a3c63d74a40f7ac86ce28dce14ff8 caused configure to
> hang in some configurations, which this fixes.
I have attached an updated version. Hope you like the commit message
better.
I can push it tomorrow or you can do earlier.
Thanks,
Alexander
From d71f2bd07a9a723158fb1ec59ec7398fe7aee577 Mon Sep 17 00:00:00 2001
From: Alexander Strasser
Date: Sat, 21 Jun 2025 11:13:22 +0200
Subject: [PATCH] configure: Fix a regression when probing link.exe
The version ident is printed on stdout for link.exe and redirecting
stdout to /dev/null will cause the output of link.exe to be paged.
This caused configure to hang for some configurations and by
extension some FATE clients. You might want to check if you run
affected configurations automated in FATE clients or similar setups.
Fixes: 45a30e03613a3c63d74a40f7ac86ce28dce14ff8
---
configure | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/configure b/configure
index 708ecd9025..ce027d3845 100755
--- a/configure
+++ b/configure
@@ -5130,10 +5130,9 @@ probe_cc(){
elif $_cc -nologo- 2>&1 | grep -q ^Microsoft || { $_cc -v 2>&1 | grep -q
clang && $_cc -? > /dev/null 2>&1; }; then
_type=msvc
if $_cc -nologo- 2>&1 | grep -q ^Microsoft; then
-# The version number is printed on the first line on stderr, stdout
-# gets the usage instructions. Only include stderr, to avoid
-# potential ordering race conditions.
-_ident=$($_cc 2>&1 >/dev/null | head -n1 | tr -d '\r')
+# Depending on the tool (cl.exe or link.exe), the version number
+# is printed on the first line of stderr or stdout
+_ident=$($_cc 2>&1 | grep ^Microsoft | head -n1 | tr -d '\r')
else
_ident=$($_cc --version 2>/dev/null | head -n1 | tr -d '\r')
fi
--
--- End Message ---
___
ffmpeg-devel mailing list
ffmpeg-devel@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] tools: Remove libav-merge-next-commit
--- Begin Message --- Hi Derek! On 2025-06-23 22:40 +0100, Derek Buitenhuis wrote: > Libav is no longer extant. ^ Seems I just learned a new English word... IMHO removal is OK. Should be no longer needed in this specific form. I see the tool is still mentioned in doc/libav-merge.txt . Not sure but maybe it can be removed as well? Or the parts of the file that reference libav-merge-next-commit? Best regards, Alexander > Signed-off-by: Derek Buitenhuis > --- > tools/libav-merge-next-commit | 22 -- > 1 file changed, 22 deletions(-) > delete mode 100755 tools/libav-merge-next-commit > > diff --git a/tools/libav-merge-next-commit b/tools/libav-merge-next-commit > deleted file mode 100755 > index 9bd03fabf8..00 > --- a/tools/libav-merge-next-commit > +++ /dev/null > @@ -1,22 +0,0 @@ > -#!/bin/sh > - > -if [ "$1" != "merge" -a "$1" != "noop" ]; then > -printf "Usage: $0 \n" > -exit 0 > -fi > - > -[ "$1" = "noop" ] && merge_opts="-s ours" > - > -nextrev=$(git rev-list libav/master --not master --no-merges | tail -n1) > -if [ -z "$nextrev" ]; then > -printf "Nothing to merge..\n" > -exit 0 > -fi > -printf "Merging $(git log -n 1 --oneline $nextrev)\n" > -git merge --no-commit $merge_opts --no-ff --log $nextrev > - > -if [ "$1" = "noop" -a -n "$2" ]; then > -printf "\nThis commit is a noop, see $2\n" >> .git/MERGE_MSG > -fi > - > -printf "\nMerged-by: $(git config --get user.name) <$(git config --get > user.email)>\n" >> .git/MERGE_MSG > -- > 2.49.0 --- End Message --- ___ ffmpeg-devel mailing list ffmpeg-devel@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] Revert "avformat/tls_openssl: properly get new BIO index"
On 2025-07-31 00:02 +0200, Nicolas George wrote: > Niklas Haas (HE12025-07-30): > > What you pointed out is pointess nitpicking, and I could point you to > > plenty of other comments by "experienced" FFmpeg developers who have done > > the same in the past, presumably without having sat through diatribes. > > Where they argued that they were right instead of admitting “my bad”? I > doubt it, but you can try. I don't understand what the issue with the commit message is? Read the message multiple times and it is above average for commit messages in general and especially for reverts. 1. It spells out why the revert was done 2. It gives reference to where the problem was discovered 3. It cites corresponding relevant parts of the OpenSSL docs inline Nicolas, can you clear this up? What am I missing? Best regards, Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v5] gcc: Don't disable '-ftree-vectorize' if gcc version higher than 13.
On 2025-07-18 17:42 +0200, Kacper Michajlow wrote: > On Fri, 11 Jul 2025 at 23:41, Michael Niedermayer > wrote: > > On Thu, Jul 10, 2025 at 02:35:10PM +0300, Martin Storsjö wrote: [...] > > > > > I'm unsure if we should allow it everywhere, and just single out loongarch > > > as a case where it is known broken, or if we should only let GCC enable it > > > on the major architectures that we've tested. > > > > I think for architectures where there is an active maintainer, > > that maintainer should decide. > > > > For architectures where there is noone looking after them, its > > safer to leave it disabled. Otherwsie users could be having > > complex to debug issues to deal with and noone in ffmpeg able to > > replicate > > I agree. In a perfect world we would enable it everywhere, but if > there is a worry that GCC is not a mature enough compiler to enable > it, it's better to gradually roll it out on an opt-in basis. We can > start with major architectures and for other architectures allow > maintainers to decide. > > Alternatively enable it everywhere for start and selectively disable > it, once issues are identified. This may cause breakage, but is easy > to workaround (by adding a compiler flag), and will likely identify > issues with GCC faster. > > Bottom line is that adding `-fno-tree-vectorize` in current year is > quite a heavy hammer to avoid possible issues and especially on major > architectures like x86 it should be safe to enable vectorization. It > also currently gives clang and advantage over gcc if we compare pure c > code in some cases. Do we have concrete numbers how much better it is? I mean pure C versions of FFmpeg were never really recommended. Would also need the numbers per architecture. Otherwise I would argue people that care about it because they don't have Assembly implementations for their target or use more C code because of other reasons should just enable vectorization as well if they think it works for them. Anyway I see no problem to enable compiler vectorization for compilers and architectures where it works correctly and active maintainers agree on it. And act, should it ever break again. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] forgejo merge vs approve
On 2025-08-03 17:04 +0200, Timo Rothenpieler wrote: > On 8/3/2025 3:26 PM, Michael Niedermayer wrote: > > On Sun, Aug 03, 2025 at 01:45:17PM +0200, Timo Rothenpieler wrote: > > > On 8/3/2025 9:41 AM, Michael Niedermayer wrote: > > > > Hi > > > > > > > > can we have a tag that causes "automerge on approve" ? > > > > > > > > so that if i open a pr i can set that tag and if someone approves it, > > > > its > > > > merged and i dont have to come back and click that button ? > > > > > > That is how it should already work normally. > > > If there is no approval, the merge button turns into a "Auto-Merge when > > > checks succeed", and "at least one approval" is said check. > > > > > > Not sure if being an admin lets you bypass that, but at least I also see > > > the > > > "Rebase then fw (When checks succeed)" button. > > > > ok lets see if that works > > I saw one button and i clicked it on > > "https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20093"; > > > > lets see if it waits for an approval :) > > > > btw how exactly does that work when a pull request crosses the area > > of knowledge of 5 people ? > > You probably shouldn't mark such PRs for auto-merge on approval. > I'd only use it on more or less obvious/trivial things. Fully agree with Timo. One should act responsibly and only use auto-merge on very small, mostly trivial changes. For bigger stuff I think it's best to let either the main author or the main reviewer do the merge. Where the author is only possible when they have write access and with main reviewer I mean a reviewer that fully reviewed the changes and not only partially. This is usually the best option because they have a better mental model of how things work and what gets changed and don't want to introduce errors themselves when actively merging the changes. So things that might have been not found yet still have a good chance to pop up last minute. Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
