Re: [FFmpeg-devel] [PATCH 14/25] avfilter/vf_format: re-use AVFilterList for pix_fmt parsing

[Anton Khirnov]

Quoting Niklas Haas (2023-11-09 13:19:46)
>Subject: avfilter/vf_format: re-use AVFilterList for pix_fmt parsing
 
You mean AVFilterFormats

> From: Niklas Haas 
> 
> Rewrite the format parsing code to make it more easily generalizable. In
> particular, `invert_formats` does not depend on the type of format list
> passed to it, which allows me to re-use this helper in an upcoming
> commit.
> 
> Slightly shortens the code, at the sole cost of doing several malloc
> (ff_add_format) instead of a single malloc.
> ---
>  libavfilter/vf_format.c | 103 +---
>  1 file changed, 43 insertions(+), 60 deletions(-)
> 
> diff --git a/libavfilter/vf_format.c b/libavfilter/vf_format.c
> index 1189bd61c2..b137e3075e 100644
> --- a/libavfilter/vf_format.c
> +++ b/libavfilter/vf_format.c
> @@ -41,25 +41,48 @@ typedef struct FormatContext {
>  const AVClass *class;
>  char *pix_fmts;
>  
> -/**
> - * pix_fmts parsed into AVPixelFormats and terminated with
> - * AV_PIX_FMT_NONE
> - */
> -enum AVPixelFormat *formats;
> +AVFilterFormats *formats; ///< parsed from `pix_fmts`
>  } FormatContext;
>  
>  static av_cold void uninit(AVFilterContext *ctx)
>  {
>  FormatContext *s = ctx->priv;
> -av_freep(&s->formats);
> +ff_formats_unref(&s->formats);
> +}
> +
> +static av_cold int invert_formats(AVFilterFormats **fmts,
> +   AVFilterFormats *allfmts)

This would look better with AVFilterFormats vertically aligned as well.

Looks ok otherwise, though I'm slightly surprised we don't seem to have
a function for "is format in list?".

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

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

Re: [FFmpeg-devel] [PATCH v2 7/7] avcodec: add AV_CODEC_FLAG_CLEAR

[Anton Khirnov]

Quoting Marton Balint (2023-12-12 19:37:57)
> 
> 
> On Tue, 12 Dec 2023, Anton Khirnov wrote:
> 
> > Quoting Marton Balint (2023-12-08 00:11:21)
> >> Wipe reminds me of the wipe effect. How about 'predecode_clear'?
> >
> > Fine with me I guess.
> >
> >>>
>  + */
>  +#define AV_CODEC_FLAG_CLEAR   (1 << 12)
>   /**
>    * Only decode/encode grayscale.
>    */
>  diff --git a/libavcodec/decode.c b/libavcodec/decode.c
>  index 2cfb3fcf97..f9b18a2c35 100644
>  --- a/libavcodec/decode.c
>  +++ b/libavcodec/decode.c
>  @@ -1675,6 +1675,12 @@ FF_ENABLE_DEPRECATION_WARNINGS
> 
>   validate_avframe_allocation(avctx, frame);
> 
>  +if (avctx->flags & AV_CODEC_FLAG_CLEAR && avctx->codec_type == 
>  AVMEDIA_TYPE_VIDEO) {
>  +uint32_t color[4] = {0};
>  +ptrdiff_t linesize[4] = {frame->linesize[0], 
>  frame->linesize[1], frame->linesize[2], frame->linesize[3]};
>  +av_image_fill_color(frame->data, linesize, frame->format, 
>  color, frame->width, frame->height);
> >>>
> >>> Should this check for errors?
> >>
> >> Lack of error checking is intentional. av_image_fill_color might not
> >> support all pixel formats, definitely not support hwaccel formats. It
> >> might make sense to warn the user once, but I don't think propagating the
> >> error back is needed here.
> >>
> >> I primarily thought of this as a QC feature (even thought about making the
> >> color fill green by default to make it more noticeable (YUV green happens
> >> to be 0,0,0), but for that I'd need similar checks for colorspaces to
> >> what I have for fill_black())...
> >
> > As Mark said, I expect people to want to use it as a security feature.
> > So either it should work reliably, or it should be made very clear that
> > it's for debugging only.
> >
> > For non-hwaccel pixel formats, you can fall back on memsetting the
> > buffer to 0.
> 
> IMHO for security you don't need to clear every frame, only new ones in 
> the buffer pool. Considering that it only affects the first few 
> frames, we might want to do that unconditionally, and not based on a 
> flag. And it is better to do this on the buffer level (because you might 
> not overwrite some bytes because of alignment with a color fill).
> 
> So for this flag, I'd rather make it clear it is not security-related, and 
> also that it has performance impact.

So then maybe make a FF_EC flag?

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

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

Re: [FFmpeg-devel] [RFC] fftools/ffmpeg and libavdevice/sdl issue

[Anton Khirnov]

Quoting Zhao Zhili (2023-12-12 18:27:39)
> Now it's time to talk about the libavdevice/sdl issue.
> 
> SDL output is broken with ffmpeg multithread refactor. SDL 'muxer' 
> write_header
> and write_packet must be run in the same thread. And to make it work portable
> and reliable, SDL 'muxer' must be run in main thread. It's a common 
> requirement
> for render to be run in main thread.
> 
> There are at least two trac tickets for the same issue: #10644 and #10649.
> 
> And there are two patches for the issue:
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230918063728.198377-1-haihao.xi...@intel.com/
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20231101090115.10655-1-angus.c...@intel.com/
> 
> There patches might work on Linux, but not portable.
> 
> A simple workaround is pipe the output of ffmpeg to ffplay:
> 
> ./ffmpeg -re -i /e/video/cctv.mp4 -an -f yuv4mpegpipe - |ffplay -
> 
> To fix it, another thread can be used to drive transcode rather than main 
> thread.
> A main loop should be created on main thread, and prepared to handle any 
> special
> tasks like render. It sounds a lot of work. I'm not sure if it worth for a 
> single use case.
> However, maybe we can have a libavfilter/vsink_preview after that.
> 
> What should we do?

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?

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

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

Re: [FFmpeg-devel] [RFC] fftools/ffmpeg and libavdevice/sdl issue

[Zhao Zhili]

> On Dec 13, 2023, at 17:08, Anton Khirnov  wrote:
> 
> Quoting Zhao Zhili (2023-12-12 18:27:39)
>> Now it's time to talk about the libavdevice/sdl issue.
>> 
>> SDL output is broken with ffmpeg multithread refactor. SDL 'muxer' 
>> write_header
>> and write_packet must be run in the same thread. And to make it work portable
>> and reliable, SDL 'muxer' must be run in main thread. It's a common 
>> requirement
>> for render to be run in main thread.
>> 
>> There are at least two trac tickets for the same issue: #10644 and #10649.
>> 
>> And there are two patches for the issue:
>> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230918063728.198377-1-haihao.xi...@intel.com/
>> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20231101090115.10655-1-angus.c...@intel.com/
>> 
>> There patches might work on Linux, but not portable.
>> 
>> A simple workaround is pipe the output of ffmpeg to ffplay:
>> 
>> ./ffmpeg -re -i /e/video/cctv.mp4 -an -f yuv4mpegpipe - |ffplay -
>> 
>> To fix it, another thread can be used to drive transcode rather than main 
>> thread.
>> A main loop should be created on main thread, and prepared to handle any 
>> special
>> tasks like render. It sounds a lot of work. I'm not sure if it worth for a 
>> single use case.
>> However, maybe we can have a libavfilter/vsink_preview after that.
>> 
>> What should we do?
> 
> 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?

I pasted wrong tickets, they are #10625 and #10649.
https://trac.ffmpeg.org/ticket/10625

The use case is realtime preview. The function lavd/sdl2 provides is limited. A 
vsink_preview
filter is more appropriate. It has the same thread issue with libavfilter.

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

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

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

Re: [FFmpeg-devel] [RFC] fftools/ffmpeg and libavdevice/sdl issue

[Nicolas George]

Anton Khirnov (12023-12-13):
> Honestly I don't see how this could be done in ffmpeg CLI without
> disgusting hacks,

As I said: do not expect it to be fixed.

Or we could revert the whole half-baked series.

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

No, not “before that”. You have no authority to demand an answer to
that question before helping fixing the feature you broke.

That feature was added. That means its usefulness was obvious to the
person who spent efforts implementing it, and to the persons who
discussed it at the time and helped it happen. Its usefulness is also
useful to the person who is trying to fix it right now. The fact that
the usefulness is not evident to YOU is a failure of your imagination,
not a characteristic of the feature.

If you are curious, you can ask, POLITELY, that people tell you what
they use it for.

But despite what your behavior seems to imply, you are not FFmpeg's
dictator, you cannot demand people convince YOU to keep a feature or
decide to remove or break it.

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

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

Re: [FFmpeg-devel] [PATCH v2] gdigrab: Allow capturing a window by its handle

[Nicolas George]

Rémi Denis-Courmont (12023-12-12):
> ...and test for overflow errors in errno.m (which shall have been
> zeroed beforehand). AFAIK, you need to do both if you want strict
> error detection.

Or we can consider that 30064771114 is just another valid way if writing
42 = 042 = 0x2a. It would be better to check, but it is less critical
than checking for garbage at the and, which itself is less critical than
checking that the number is entirely absent.

> Don't some distros forbid the use of the n specifier for (debatable)
> "security reasons"? Or is that only for formatting, and not in
> scanning?

First time I ear of that. We use %n in quite a few places — not only
code by me — and we did not have a problem.

If there is a real security consideration about %n, I would like a
pointer to the explanations; but I strongly doubt there are, it is just
another conversion specifier with all the usual caveats. If not, and
there are distros who forbid it for no valid reason, then I say to hell
with them.

Regards,

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

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

Re: [FFmpeg-devel] [RFC] fftools/ffmpeg and libavdevice/sdl issue

[Anton Khirnov]

Quoting Zhao Zhili (2023-12-13 10:31:38)
> 
> > On Dec 13, 2023, at 17:08, Anton Khirnov  wrote:
> > 
> > Quoting Zhao Zhili (2023-12-12 18:27:39)
> >> Now it's time to talk about the libavdevice/sdl issue.
> >> 
> >> SDL output is broken with ffmpeg multithread refactor. SDL 'muxer' 
> >> write_header
> >> and write_packet must be run in the same thread. And to make it work 
> >> portable
> >> and reliable, SDL 'muxer' must be run in main thread. It's a common 
> >> requirement
> >> for render to be run in main thread.
> >> 
> >> There are at least two trac tickets for the same issue: #10644 and #10649.
> >> 
> >> And there are two patches for the issue:
> >> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230918063728.198377-1-haihao.xi...@intel.com/
> >> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20231101090115.10655-1-angus.c...@intel.com/
> >> 
> >> There patches might work on Linux, but not portable.
> >> 
> >> A simple workaround is pipe the output of ffmpeg to ffplay:
> >> 
> >> ./ffmpeg -re -i /e/video/cctv.mp4 -an -f yuv4mpegpipe - |ffplay -
> >> 
> >> To fix it, another thread can be used to drive transcode rather than main 
> >> thread.
> >> A main loop should be created on main thread, and prepared to handle any 
> >> special
> >> tasks like render. It sounds a lot of work. I'm not sure if it worth for a 
> >> single use case.
> >> However, maybe we can have a libavfilter/vsink_preview after that.
> >> 
> >> What should we do?
> > 
> > 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?
> 
> I pasted wrong tickets, they are #10625 and #10649.
> https://trac.ffmpeg.org/ticket/10625
> 
> The use case is realtime preview. The function lavd/sdl2 provides is limited. 
> A vsink_preview
> filter is more appropriate. It has the same thread issue with libavfilter.

The submitter claims that piping to ffplay suffers from latency, which
should not be there and so is either a bug or an improper setup.

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

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

Re: [FFmpeg-devel] [PATCH] Add new vf_tiltandshift filter

[Vittorio Giovara]

On Tue, Dec 12, 2023 at 3:00 AM Nicolas George  wrote:

> Vittorio Giovara (12023-12-11):
> > This is an older filter I wrote and never got around publishing.
> > It can be used to generate a distortion effect like
> > https://vimeo.com/104938599?share=copy
> > Please see attached.
>
> Your code is doing in request_frame() what should be done in
> filter_frame(). That will work in simple linear graphs but not in
> graphs with branches and/or time shifts. See doc/filter_design.txt for
> details.
>

Thanks for the review, attached the proposed changes.
-- 
Vittorio


0001-Add-new-vf_tiltandshift-filter.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://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

[Zhao Zhili]

> On Dec 13, 2023, at 18:06, Anton Khirnov  wrote:
> 
> Quoting Zhao Zhili (2023-12-13 10:31:38)
>> 
>>> On Dec 13, 2023, at 17:08, Anton Khirnov  wrote:
>>> 
>>> Quoting Zhao Zhili (2023-12-12 18:27:39)
 Now it's time to talk about the libavdevice/sdl issue.
 
 SDL output is broken with ffmpeg multithread refactor. SDL 'muxer' 
 write_header
 and write_packet must be run in the same thread. And to make it work 
 portable
 and reliable, SDL 'muxer' must be run in main thread. It's a common 
 requirement
 for render to be run in main thread.
 
 There are at least two trac tickets for the same issue: #10644 and #10649.
 
 And there are two patches for the issue:
 https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230918063728.198377-1-haihao.xi...@intel.com/
 https://patchwork.ffmpeg.org/project/ffmpeg/patch/20231101090115.10655-1-angus.c...@intel.com/
 
 There patches might work on Linux, but not portable.
 
 A simple workaround is pipe the output of ffmpeg to ffplay:
 
 ./ffmpeg -re -i /e/video/cctv.mp4 -an -f yuv4mpegpipe - |ffplay -
 
 To fix it, another thread can be used to drive transcode rather than main 
 thread.
 A main loop should be created on main thread, and prepared to handle any 
 special
 tasks like render. It sounds a lot of work. I'm not sure if it worth for a 
 single use case.
 However, maybe we can have a libavfilter/vsink_preview after that.
 
 What should we do?
>>> 
>>> 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?
>> 
>> I pasted wrong tickets, they are #10625 and #10649.
>> https://trac.ffmpeg.org/ticket/10625
>> 
>> The use case is realtime preview. The function lavd/sdl2 provides is 
>> limited. A vsink_preview
>> filter is more appropriate. It has the same thread issue with libavfilter.
> 
> The submitter claims that piping to ffplay suffers from latency, which
> should not be there and so is either a bug or an improper setup.

The latency issue may be real or not, I’m concerned with performance. 
Colorspace is easy to
be handled in the same process than pipe to ffplay, although it’s missing in 
current implementation.

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

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

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

Re: [FFmpeg-devel] [RFC] fftools/ffmpeg and libavdevice/sdl issue

[Nicolas George]

Zhao Zhili (12023-12-13):
> The latency issue may be real or not

The latency is obviously real and obviously unavoidable, since there is
a muxer, a protocol, an OS buffer, a protocol and a demuxer in the chain
that are not necessary with a device. We can try to make it as small as
possible, but there will always be some extra latency.

Plus, ffplay does a lot of things that might interfere with the use,
like keeping the frames in sync with their announced timestamps, like a
-re option that cannot be disabled.

Also, the long-term plan for people who work on lavd has always been to
try to replace SDL in ffplay by lavd. It has not progressed very fast,
but it is a goal. This is a step in the wrong direction.

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

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

Re: [FFmpeg-devel] [RFC] fftools/ffmpeg and libavdevice/sdl issue

[Anton Khirnov]

Quoting Zhao Zhili (2023-12-13 11:37:52)
> 
> 
> > On Dec 13, 2023, at 18:06, Anton Khirnov  wrote:
> > 
> > Quoting Zhao Zhili (2023-12-13 10:31:38)
> >> 
> >>> On Dec 13, 2023, at 17:08, Anton Khirnov  wrote:
> >>> 
> >>> Quoting Zhao Zhili (2023-12-12 18:27:39)
>  Now it's time to talk about the libavdevice/sdl issue.
>  
>  SDL output is broken with ffmpeg multithread refactor. SDL 'muxer' 
>  write_header
>  and write_packet must be run in the same thread. And to make it work 
>  portable
>  and reliable, SDL 'muxer' must be run in main thread. It's a common 
>  requirement
>  for render to be run in main thread.
>  
>  There are at least two trac tickets for the same issue: #10644 and 
>  #10649.
>  
>  And there are two patches for the issue:
>  https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230918063728.198377-1-haihao.xi...@intel.com/
>  https://patchwork.ffmpeg.org/project/ffmpeg/patch/20231101090115.10655-1-angus.c...@intel.com/
>  
>  There patches might work on Linux, but not portable.
>  
>  A simple workaround is pipe the output of ffmpeg to ffplay:
>  
>  ./ffmpeg -re -i /e/video/cctv.mp4 -an -f yuv4mpegpipe - |ffplay -
>  
>  To fix it, another thread can be used to drive transcode rather than 
>  main thread.
>  A main loop should be created on main thread, and prepared to handle any 
>  special
>  tasks like render. It sounds a lot of work. I'm not sure if it worth for 
>  a single use case.
>  However, maybe we can have a libavfilter/vsink_preview after that.
>  
>  What should we do?
> >>> 
> >>> 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?
> >> 
> >> I pasted wrong tickets, they are #10625 and #10649.
> >> https://trac.ffmpeg.org/ticket/10625
> >> 
> >> The use case is realtime preview. The function lavd/sdl2 provides is 
> >> limited. A vsink_preview
> >> filter is more appropriate. It has the same thread issue with libavfilter.
> > 
> > The submitter claims that piping to ffplay suffers from latency, which
> > should not be there and so is either a bug or an improper setup.
> 
> The latency issue may be real or not, I’m concerned with performance. 
> Colorspace is easy to
> be handled in the same process than pipe to ffplay, although it’s missing in 
> current implementation.

I would think piping yuv4mpeg to ffplay should have very little overhead
compared to actual encoding.

IMO ffmpeg is just not a GUI program and trying to use it as one will
just unavoidably lead to tears. It's not an email client either btw.

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

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

Re: [FFmpeg-devel] [PATCH 15/25] avfilter/vf_format: add color_ranges/spaces

[Anton Khirnov]

Quoting Niklas Haas (2023-11-09 13:19:47)
> From: Niklas Haas 
> 
> Needed for fftools/ffmpeg_filter to be able to force specific output
> formats via the filter chain.
> ---
>  doc/filters.texi|  8 
>  libavfilter/vf_format.c | 44 +
>  2 files changed, 48 insertions(+), 4 deletions(-)
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 55a333680c..4599d575a6 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -14241,6 +14241,14 @@ It accepts the following parameters:
>  A '|'-separated list of pixel format names, such as
>  "pix_fmts=yuv420p|monow|rgb24".
>  
> +@item color_spaces
> +A '|'-separated list of color space names, such as
> +"color_spaces=bt709|bt470bg|bt2020nc".
> +
> +@item color_ranges
> +A '|'-separated list of color rangee names, such as
  ^
extra e

> +"color_spaces=tv|pc".
> +
>  @end table
>  
>  @subsection Examples
> diff --git a/libavfilter/vf_format.c b/libavfilter/vf_format.c
> index b137e3075e..d1bb9daa97 100644
> --- a/libavfilter/vf_format.c
> +++ b/libavfilter/vf_format.c
> @@ -40,18 +40,24 @@
>  typedef struct FormatContext {
>  const AVClass *class;
>  char *pix_fmts;
> +char *csps;
> +char *ranges;
>  
>  AVFilterFormats *formats; ///< parsed from `pix_fmts`
> +AVFilterFormats *color_spaces; ///< parsed from `csps`
> +AVFilterFormats *color_ranges; ///< parsed from `ranges`
>  } FormatContext;
>  
>  static av_cold void uninit(AVFilterContext *ctx)
>  {
>  FormatContext *s = ctx->priv;
>  ff_formats_unref(&s->formats);
> +ff_formats_unref(&s->color_spaces);
> +ff_formats_unref(&s->color_ranges);
>  }
>  
>  static av_cold int invert_formats(AVFilterFormats **fmts,
> -   AVFilterFormats *allfmts)
> +  AVFilterFormats *allfmts)
>  {
>  if (!allfmts)
>  return AVERROR(ENOMEM);
> @@ -99,13 +105,35 @@ static av_cold int init(AVFilterContext *ctx)
>  return ret;
>  }
>  
> +for (char *sep, *cur = s->csps; cur; cur = sep) {
> +sep = strchr(cur, '|');
> +if (sep && *sep)
> +*sep++ = 0;
> +if ((ret = av_color_space_from_name(cur)) < 0 ||
> +(ret = ff_add_format(&s->color_spaces, ret)) < 0)

I find this style of assigning inside a condition far more error-prone
and harder to read. Especially when you have three of them in a single
if() below.

Otherwise looks ok.

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

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

Re: [FFmpeg-devel] [PATCH 16/25] avfilter/vf_format: allow empty pix_fmts list

[Anton Khirnov]

Quoting Niklas Haas (2023-11-09 13:19:48)
> From: Niklas Haas 
> 
> Which will impose no restriction. This makes sense when using e.g.
> `color_ranges=pc` to limit the color range, without also limiting the
> pixel format.
> ---
>  libavfilter/vf_format.c | 9 ++---
>  1 file changed, 2 insertions(+), 7 deletions(-)

Looks ok

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

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

Re: [FFmpeg-devel] [PATCH 2/5] fftools/ffmpeg: move parsing of -stats_* specifiers to lavu/parseutils

[Anton Khirnov]

Quoting Thilo Borgmann via ffmpeg-devel (2023-12-11 16:07:22)
> ---
>  fftools/ffmpeg.h  |  31 +--
>  fftools/ffmpeg_enc.c  |   3 +-
>  fftools/ffmpeg_mux_init.c | 152 +++-
>  libavutil/parseutils.c| 176 ++
>  libavutil/parseutils.h| 102 ++
>  libavutil/version.h   |   2 +-
>  6 files changed, 296 insertions(+), 170 deletions(-)

Absolutely not.

This is application code and does not belong in the libraries.

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

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

Re: [FFmpeg-devel] [PATCH 2/5] fftools/ffmpeg: move parsing of -stats_* specifiers to lavu/parseutils

[Thilo Borgmann via ffmpeg-devel]

Am 13.12.23 um 13:00 schrieb Anton Khirnov:

Quoting Thilo Borgmann via ffmpeg-devel (2023-12-11 16:07:22)

---
  fftools/ffmpeg.h  |  31 +--
  fftools/ffmpeg_enc.c  |   3 +-
  fftools/ffmpeg_mux_init.c | 152 +++-
  libavutil/parseutils.c| 176 ++
  libavutil/parseutils.h| 102 ++
  libavutil/version.h   |   2 +-
  6 files changed, 296 insertions(+), 170 deletions(-)


Absolutely not.

This is application code and does not belong in the libraries.


How else do we not have a redundant copy of all that and make sure that 
-stats_* options and the filter understand the same {..} directives?

-Thilo

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://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] fftools/ffmpeg: move parsing of -stats_* specifiers to lavu/parseutils

[Anton Khirnov]

Quoting Thilo Borgmann via ffmpeg-devel (2023-12-13 13:05:35)
> Am 13.12.23 um 13:00 schrieb Anton Khirnov:
> > Quoting Thilo Borgmann via ffmpeg-devel (2023-12-11 16:07:22)
> >> ---
> >>   fftools/ffmpeg.h  |  31 +--
> >>   fftools/ffmpeg_enc.c  |   3 +-
> >>   fftools/ffmpeg_mux_init.c | 152 +++-
> >>   libavutil/parseutils.c| 176 ++
> >>   libavutil/parseutils.h| 102 ++
> >>   libavutil/version.h   |   2 +-
> >>   6 files changed, 296 insertions(+), 170 deletions(-)
> > 
> > Absolutely not.
> > 
> > This is application code and does not belong in the libraries.
> 
> How else do we not have a redundant copy of all that and make sure that 
> -stats_* options and the filter understand the same {..} directives?

Why does that filter need to understand the same directives? No other
filter does.

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

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

Re: [FFmpeg-devel] [PATCH 2/5] fftools/ffmpeg: move parsing of -stats_* specifiers to lavu/parseutils

[Nicolas George]

Thilo Borgmann via ffmpeg-devel (12023-12-11):
> ---
>  fftools/ffmpeg.h  |  31 +--
>  fftools/ffmpeg_enc.c  |   3 +-
>  fftools/ffmpeg_mux_init.c | 152 +++-
>  libavutil/parseutils.c| 176 ++
>  libavutil/parseutils.h| 102 ++
>  libavutil/version.h   |   2 +-
>  6 files changed, 296 insertions(+), 170 deletions(-)

LGTM

Regards,

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

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

Re: [FFmpeg-devel] [PATCH 2/5] fftools/ffmpeg: move parsing of -stats_* specifiers to lavu/parseutils

[Thilo Borgmann via ffmpeg-devel]

Am 13.12.23 um 13:08 schrieb Anton Khirnov:

Quoting Thilo Borgmann via ffmpeg-devel (2023-12-13 13:05:35)

Am 13.12.23 um 13:00 schrieb Anton Khirnov:

Quoting Thilo Borgmann via ffmpeg-devel (2023-12-11 16:07:22)

---
   fftools/ffmpeg.h  |  31 +--
   fftools/ffmpeg_enc.c  |   3 +-
   fftools/ffmpeg_mux_init.c | 152 +++-
   libavutil/parseutils.c| 176 ++
   libavutil/parseutils.h| 102 ++
   libavutil/version.h   |   2 +-
   6 files changed, 296 insertions(+), 170 deletions(-)


Absolutely not.

This is application code and does not belong in the libraries.


How else do we not have a redundant copy of all that and make sure that 
-stats_* options and the filter understand the same {..} directives?


Why does that filter need to understand the same directives? No other
filter does.


Because it is meant to use the file(s) the -stats_* option writes out. The most 
convenient and most error resilient way is to use the very same format string 
for -stats_* option as well as for the filter.

Otherwise it could be a 'usual' scanf-format, but then the user has to 
translate it from one format into the other - without making mistakes.
But that would also mean to update the filter (if someone realizes it) if the 
option ever changes.

-Thilo

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://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] fftools/ffmpeg: move parsing of -stats_* specifiers to lavu/parseutils

[Anton Khirnov]

Quoting Thilo Borgmann via ffmpeg-devel (2023-12-13 13:15:27)
> Am 13.12.23 um 13:08 schrieb Anton Khirnov:
> > Quoting Thilo Borgmann via ffmpeg-devel (2023-12-13 13:05:35)
> >> Am 13.12.23 um 13:00 schrieb Anton Khirnov:
> >>> Quoting Thilo Borgmann via ffmpeg-devel (2023-12-11 16:07:22)
>  ---
> fftools/ffmpeg.h  |  31 +--
> fftools/ffmpeg_enc.c  |   3 +-
> fftools/ffmpeg_mux_init.c | 152 +++-
> libavutil/parseutils.c| 176 ++
> libavutil/parseutils.h| 102 ++
> libavutil/version.h   |   2 +-
> 6 files changed, 296 insertions(+), 170 deletions(-)
> >>>
> >>> Absolutely not.
> >>>
> >>> This is application code and does not belong in the libraries.
> >>
> >> How else do we not have a redundant copy of all that and make sure that 
> >> -stats_* options and the filter understand the same {..} directives?
> > 
> > Why does that filter need to understand the same directives? No other
> > filter does.
> 
> Because it is meant to use the file(s) the -stats_* option writes out. The 
> most convenient and most error resilient way is to use the very same format 
> string for -stats_* option as well as for the filter.
> 
> Otherwise it could be a 'usual' scanf-format, but then the user has to 
> translate it from one format into the other - without making mistakes.
> But that would also mean to update the filter (if someone realizes it) if the 
> option ever changes.

Why does it need a dynamic format at all? Just postulate a fixed format
for its input like every other filter and none of this complexity is
needed.

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

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

Re: [FFmpeg-devel] [PATCH 2/5] fftools/ffmpeg: move parsing of -stats_* specifiers to lavu/parseutils

[Thilo Borgmann via ffmpeg-devel]

Am 13.12.23 um 13:39 schrieb Anton Khirnov:

Quoting Thilo Borgmann via ffmpeg-devel (2023-12-13 13:15:27)

Am 13.12.23 um 13:08 schrieb Anton Khirnov:

Quoting Thilo Borgmann via ffmpeg-devel (2023-12-13 13:05:35)

Am 13.12.23 um 13:00 schrieb Anton Khirnov:

Quoting Thilo Borgmann via ffmpeg-devel (2023-12-11 16:07:22)

---
fftools/ffmpeg.h  |  31 +--
fftools/ffmpeg_enc.c  |   3 +-
fftools/ffmpeg_mux_init.c | 152 +++-
libavutil/parseutils.c| 176 ++
libavutil/parseutils.h| 102 ++
libavutil/version.h   |   2 +-
6 files changed, 296 insertions(+), 170 deletions(-)


Absolutely not.

This is application code and does not belong in the libraries.


How else do we not have a redundant copy of all that and make sure that 
-stats_* options and the filter understand the same {..} directives?


Why does that filter need to understand the same directives? No other
filter does.


Because it is meant to use the file(s) the -stats_* option writes out. The most 
convenient and most error resilient way is to use the very same format string 
for -stats_* option as well as for the filter.

Otherwise it could be a 'usual' scanf-format, but then the user has to 
translate it from one format into the other - without making mistakes.
But that would also mean to update the filter (if someone realizes it) if the 
option ever changes.


Why does it need a dynamic format at all? Just postulate a fixed format
for its input like every other filter and none of this complexity is
needed.


That would unnecessarily limit the user of the -stats_* option to a specific 
format if the user also wants to use this filter later.
Either sacrificing the other info the user wanted to process from the file 
created or having to run the same command (with distinct format strings for the 
-stats_* option) twice. Or do the conversion from his extensive format into the 
fixed format manually - without errors.

-Thilo

___
ffmpeg-devel mailing list
ffmpeg-devel@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] configure: check VTPixelTransferSessionCreate for scale_vt

[Zhao Zhili]

From: Zhao Zhili 

It's available on macOS since 10.8, but not available on iOS until
16.0.
---
 configure | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 7d2ee66000..8b99af223d 100755
--- a/configure
+++ b/configure
@@ -3836,7 +3836,7 @@ zmq_filter_deps="libzmq"
 zoompan_filter_deps="swscale"
 zscale_filter_deps="libzimg const_nan"
 scale_vaapi_filter_deps="vaapi"
-scale_vt_filter_deps="videotoolbox"
+scale_vt_filter_deps="videotoolbox VTPixelTransferSessionCreate"
 scale_vulkan_filter_deps="vulkan spirv_compiler"
 vpp_qsv_filter_deps="libmfx"
 vpp_qsv_filter_select="qsvvpp"
@@ -6501,6 +6501,7 @@ check_headers termios.h
 check_headers unistd.h
 check_headers valgrind/valgrind.h
 check_func_headers VideoToolbox/VTCompressionSession.h 
VTCompressionSessionPrepareToEncodeFrames -framework VideoToolbox
+check_func_headers VideoToolbox/VideoToolbox.h VTPixelTransferSessionCreate 
-framework VideoToolbox
 check_func_headers VideoToolbox/VideoToolbox.h VTPixelRotationSessionCreate 
-framework VideoToolbox
 check_headers windows.h
 check_headers asm/types.h
-- 
2.42.0

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

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

[FFmpeg-devel] [PATCH v2 00/15] YUV colorspace filter negotiation

[Niklas Haas]

Split off from my YUVJ removal series. This implements all of the
libavfilter changes needed to fully deprecate YUVJ, but does not yet
remove YUVJ, nor add an AVCodec API for advertising colorspace support.

Update includes all of the feedback that was brought up by Anton. the
major change from v1 is that YUV metadata configured on a link is no
longer strictly required to be consistent with the frames, simply to
avoid breaking users that don't set this link metadata. Effectively,
this allows us to have a grace period where the field functions more
like a hint than an authoritative field.

___
ffmpeg-devel mailing list
ffmpeg-devel@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 01/15] avfilter/formats: document ff_default_query_formats

[Niklas Haas]

From: Niklas Haas 

In particular, make it clear that this function will not touch format
lists which were already set by the caller before calling into this
function.
---
 libavfilter/formats.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavfilter/formats.h b/libavfilter/formats.h
index 4dce2d..d44890109e 100644
--- a/libavfilter/formats.h
+++ b/libavfilter/formats.h
@@ -198,6 +198,10 @@ void ff_channel_layouts_unref(AVFilterChannelLayouts 
**ref);
 void ff_channel_layouts_changeref(AVFilterChannelLayouts **oldref,
   AVFilterChannelLayouts **newref);
 
+/**
+ * Sets all remaining unset filter lists for all inputs/outputs to their
+ * corresponding `ff_all_*()` lists.
+ */
 av_warn_unused_result
 int ff_default_query_formats(AVFilterContext *ctx);
 
-- 
2.43.0

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

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

[FFmpeg-devel] [PATCH v2 02/15] avfilter: always call ff_default_query_formats

[Niklas Haas]

From: Niklas Haas 

Even if a query func is set. This is safe to do, because
ff_default_query_formats is documented not to touch any filter lists
that were already set by the query func.

The reason to do this is because it allows us to extend
AVFilterFormatsConfig without having to touch every filter in existence.
An alternative implementation of this commit would be to explicitly add
a `ff_default_query_formats` call at the end of every query_formats
function, but that would end up functionally equivalent to this change
while touching a whole lot more code paths for no reason.

As a bonus, eliminates some code/logic duplication from this function.
---
 libavfilter/avfiltergraph.c | 39 -
 1 file changed, 12 insertions(+), 27 deletions(-)

diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c
index 68daa93e61..625cbc022e 100644
--- a/libavfilter/avfiltergraph.c
+++ b/libavfilter/avfiltergraph.c
@@ -341,33 +341,21 @@ static int filter_check_formats(AVFilterContext *ctx)
 static int filter_query_formats(AVFilterContext *ctx)
 {
 int ret;
-AVFilterFormats *formats;
-AVFilterChannelLayouts *chlayouts;
-enum AVMediaType type = ctx->inputs  && ctx->inputs [0] ? ctx->inputs 
[0]->type :
-ctx->outputs && ctx->outputs[0] ? 
ctx->outputs[0]->type :
-AVMEDIA_TYPE_VIDEO;
-
-if ((ret = ctx->filter->formats.query_func(ctx)) < 0) {
-if (ret != AVERROR(EAGAIN))
-av_log(ctx, AV_LOG_ERROR, "Query format failed for '%s': %s\n",
-   ctx->name, av_err2str(ret));
-return ret;
-}
-ret = filter_check_formats(ctx);
-if (ret < 0)
-return ret;
 
-formats = ff_all_formats(type);
-if ((ret = ff_set_common_formats(ctx, formats)) < 0)
-return ret;
-if (type == AVMEDIA_TYPE_AUDIO) {
-if ((ret = ff_set_common_all_samplerates(ctx)) < 0)
+if (ctx->filter->formats_state == FF_FILTER_FORMATS_QUERY_FUNC) {
+if ((ret = ctx->filter->formats.query_func(ctx)) < 0) {
+if (ret != AVERROR(EAGAIN))
+av_log(ctx, AV_LOG_ERROR, "Query format failed for '%s': %s\n",
+   ctx->name, av_err2str(ret));
 return ret;
-chlayouts = ff_all_channel_layouts();
-if ((ret = ff_set_common_channel_layouts(ctx, chlayouts)) < 0)
+}
+
+ret = filter_check_formats(ctx);
+if (ret < 0)
 return ret;
 }
-return 0;
+
+return ff_default_query_formats(ctx);
 }
 
 static int formats_declared(AVFilterContext *f)
@@ -416,10 +404,7 @@ static int query_formats(AVFilterGraph *graph, void 
*log_ctx)
 AVFilterContext *f = graph->filters[i];
 if (formats_declared(f))
 continue;
-if (f->filter->formats_state == FF_FILTER_FORMATS_QUERY_FUNC)
-ret = filter_query_formats(f);
-else
-ret = ff_default_query_formats(f);
+ret = filter_query_formats(f);
 if (ret < 0 && ret != AVERROR(EAGAIN))
 return ret;
 /* note: EAGAIN could indicate a partial success, not counted yet */
-- 
2.43.0

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

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

[FFmpeg-devel] [PATCH v2 03/15] avfilter: add negotiation API for color space/range

[Niklas Haas]

From: Niklas Haas 

Motivated by YUVJ removal. This change will allow full negotiation
between color ranges and matrices as needed. By default, all ranges and
matrices are marked as supported.

Because grayscale formats are currently handled very inconsistently (and
in particular, assumed as forced full-range by swscale), we exclude them
from negotiation altogether for the time being, to get this API merged.

After filter negotiation is available, we can relax the
grayscale-is-forced-jpeg restriction again, when it will be more
feasible to do so without breaking a million test cases.

Note that this commit updates one FATE test as a consequence of the
sanity fallback for non-YUV formats. In particular, the test case now
writes rgb24(pc, gbr/unspecified/unspecified) to the matroska file,
instead of rgb24(unspecified/unspecified/unspecified) as before.
---
 doc/APIchanges  |   3 +
 libavfilter/avfilter.c  |  17 +++-
 libavfilter/avfilter.h  |  28 ++
 libavfilter/avfiltergraph.c | 173 +++-
 libavfilter/formats.c   | 122 -
 libavfilter/formats.h   |  54 +++
 libavfilter/internal.h  |   6 ++
 libavfilter/vaapi_vpp.c |   4 +
 libavfilter/video.c |   2 +
 tests/ref/fate/shortest-sub |   4 +-
 10 files changed, 404 insertions(+), 9 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 4a2dc1c44f..2f6ea50f63 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
 
 API changes, most recent first:
 
+2023-11-xx - xx - lavf 58.14.100 - avfilter.h
+  Add AVFilterLink.colorspace, AVFilterLink.color_range
+
 2023-11-08 - b82957a66a7 - lavu 58.32.100 - channel_layout.h
   Add AV_CH_LAYOUT_7POINT2POINT3 and AV_CHANNEL_LAYOUT_7POINT2POINT3.
   Add AV_CH_LAYOUT_9POINT1POINT4_BACK and AV_CHANNEL_LAYOUT_9POINT1POINT4_BACK.
diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index bde1c33d07..31300bb515 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -185,6 +185,7 @@ int avfilter_link(AVFilterContext *src, unsigned srcpad,
 link->type= src->output_pads[srcpad].type;
 av_assert0(AV_PIX_FMT_NONE == -1 && AV_SAMPLE_FMT_NONE == -1);
 link->format  = -1;
+link->colorspace = AVCOL_SPC_UNSPECIFIED;
 ff_framequeue_init(&link->fifo, &src->graph->internal->frame_queues);
 
 return 0;
@@ -286,6 +287,12 @@ int avfilter_insert_filter(AVFilterLink *link, 
AVFilterContext *filt,
 if (link->outcfg.formats)
 ff_formats_changeref(&link->outcfg.formats,
  &filt->outputs[filt_dstpad_idx]->outcfg.formats);
+if (link->outcfg.color_spaces)
+ff_formats_changeref(&link->outcfg.color_spaces,
+ 
&filt->outputs[filt_dstpad_idx]->outcfg.color_spaces);
+if (link->outcfg.color_ranges)
+ff_formats_changeref(&link->outcfg.color_ranges,
+ 
&filt->outputs[filt_dstpad_idx]->outcfg.color_ranges);
 if (link->outcfg.samplerates)
 ff_formats_changeref(&link->outcfg.samplerates,
  
&filt->outputs[filt_dstpad_idx]->outcfg.samplerates);
@@ -730,6 +737,10 @@ static void free_link(AVFilterLink *link)
 
 ff_formats_unref(&link->incfg.formats);
 ff_formats_unref(&link->outcfg.formats);
+ff_formats_unref(&link->incfg.color_spaces);
+ff_formats_unref(&link->outcfg.color_spaces);
+ff_formats_unref(&link->incfg.color_ranges);
+ff_formats_unref(&link->outcfg.color_ranges);
 ff_formats_unref(&link->incfg.samplerates);
 ff_formats_unref(&link->outcfg.samplerates);
 ff_channel_layouts_unref(&link->incfg.channel_layouts);
@@ -987,9 +998,9 @@ int ff_filter_frame(AVFilterLink *link, AVFrame *frame)
 strcmp(link->dst->filter->name, "idet") &&
 strcmp(link->dst->filter->name, "null") &&
 strcmp(link->dst->filter->name, "scale")) {
-av_assert1(frame->format == link->format);
-av_assert1(frame->width   == link->w);
-av_assert1(frame->height   == link->h);
+av_assert1(frame->format== link->format);
+av_assert1(frame->width == link->w);
+av_assert1(frame->height== link->h);
 }
 
 frame->sample_aspect_ratio = link->sample_aspect_ratio;
diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
index d69381aed4..246d000251 100644
--- a/libavfilter/avfilter.h
+++ b/libavfilter/avfilter.h
@@ -301,6 +301,14 @@ typedef struct AVFilter {
  * @ref AVFilterFormatsConfig.formats "incfg.formats"
  * on every output link to a list of pixel/sample formats that the 
filter
  * supports on that link.
+ * For video links, this filter may also set
+ * @ref AVFilterFormatsConfig.color_spaces "incfg.color_spaces"
+ *  /
+ 

[FFmpeg-devel] [PATCH v2 04/15] fftools/ffmpeg_filter: don't clear buffersrc params

[Niklas Haas]

From: Niklas Haas 

This memset is bogus, it accomplishes nothing in the best case and
regresses future additions to AVBufferSrcParameters in the worst case.
---
 fftools/ffmpeg_filter.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index ada235b084..e5b00123f2 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -1461,11 +1461,8 @@ static int configure_input_video_filter(FilterGraph *fg, 
InputFilter *ifilter,
 int ret, pad_idx = 0;
 int64_t tsoffset = 0;
 AVBufferSrcParameters *par = av_buffersrc_parameters_alloc();
-
 if (!par)
 return AVERROR(ENOMEM);
-memset(par, 0, sizeof(*par));
-par->format = AV_PIX_FMT_NONE;
 
 if (ist->dec_ctx->codec_type == AVMEDIA_TYPE_AUDIO) {
 av_log(fg, AV_LOG_ERROR, "Cannot connect video filter to audio 
input\n");
-- 
2.43.0

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

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

[FFmpeg-devel] [PATCH v2 14/15] avfilter/vf_format: add color_ranges/spaces

[Niklas Haas]

From: Niklas Haas 

Needed for fftools/ffmpeg_filter to be able to force specific output
formats via the filter chain.
---
 doc/filters.texi|  8 
 libavfilter/vf_format.c | 42 ++---
 2 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index f182dc2ddb..4be4dbf270 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -14323,6 +14323,14 @@ It accepts the following parameters:
 A '|'-separated list of pixel format names, such as
 "pix_fmts=yuv420p|monow|rgb24".
 
+@item color_spaces
+A '|'-separated list of color space names, such as
+"color_spaces=bt709|bt470bg|bt2020nc".
+
+@item color_ranges
+A '|'-separated list of color range names, such as
+"color_spaces=tv|pc".
+
 @end table
 
 @subsection Examples
diff --git a/libavfilter/vf_format.c b/libavfilter/vf_format.c
index 59832b7768..d1bb9daa97 100644
--- a/libavfilter/vf_format.c
+++ b/libavfilter/vf_format.c
@@ -40,14 +40,20 @@
 typedef struct FormatContext {
 const AVClass *class;
 char *pix_fmts;
+char *csps;
+char *ranges;
 
 AVFilterFormats *formats; ///< parsed from `pix_fmts`
+AVFilterFormats *color_spaces; ///< parsed from `csps`
+AVFilterFormats *color_ranges; ///< parsed from `ranges`
 } FormatContext;
 
 static av_cold void uninit(AVFilterContext *ctx)
 {
 FormatContext *s = ctx->priv;
 ff_formats_unref(&s->formats);
+ff_formats_unref(&s->color_spaces);
+ff_formats_unref(&s->color_ranges);
 }
 
 static av_cold int invert_formats(AVFilterFormats **fmts,
@@ -99,13 +105,35 @@ static av_cold int init(AVFilterContext *ctx)
 return ret;
 }
 
+for (char *sep, *cur = s->csps; cur; cur = sep) {
+sep = strchr(cur, '|');
+if (sep && *sep)
+*sep++ = 0;
+if ((ret = av_color_space_from_name(cur)) < 0 ||
+(ret = ff_add_format(&s->color_spaces, ret)) < 0)
+return ret;
+}
+
+for (char *sep, *cur = s->ranges; cur; cur = sep) {
+sep = strchr(cur, '|');
+if (sep && *sep)
+*sep++ = 0;
+if ((ret = av_color_range_from_name(cur)) < 0 ||
+(ret = ff_add_format(&s->color_ranges, ret)) < 0)
+return ret;
+}
+
 if (!strcmp(ctx->filter->name, "noformat")) {
-if ((ret = invert_formats(&s->formats, 
ff_all_formats(AVMEDIA_TYPE_VIDEO))) < 0)
+if ((ret = invert_formats(&s->formats,  
ff_all_formats(AVMEDIA_TYPE_VIDEO))) < 0 ||
+(ret = invert_formats(&s->color_spaces, ff_all_color_spaces())) < 
0 ||
+(ret = invert_formats(&s->color_ranges, ff_all_color_ranges())) < 
0)
 return ret;
 }
 
 /* hold on to a ref for the lifetime of the filter */
-if ((ret = ff_formats_ref(s->formats, &s->formats)) < 0)
+if ((ret = ff_formats_ref(s->formats, &s->formats)) < 0 ||
+s->color_spaces && (ret = ff_formats_ref(s->color_spaces, 
&s->color_spaces)) < 0 ||
+s->color_ranges && (ret = ff_formats_ref(s->color_ranges, 
&s->color_ranges)) < 0)
 return ret;
 
 return 0;
@@ -114,14 +142,22 @@ static av_cold int init(AVFilterContext *ctx)
 static int query_formats(AVFilterContext *ctx)
 {
 FormatContext *s = ctx->priv;
+int ret;
+
+if ((ret = ff_set_common_formats(ctx, s->formats)) < 0 ||
+s->color_spaces && (ret = ff_set_common_color_spaces(ctx, 
s->color_spaces)) < 0 ||
+s->color_ranges && (ret = ff_set_common_color_ranges(ctx, 
s->color_ranges)) < 0)
+return ret;
 
-return ff_set_common_formats(ctx, s->formats);
+return 0;
 }
 
 
 #define OFFSET(x) offsetof(FormatContext, x)
 static const AVOption options[] = {
 { "pix_fmts", "A '|'-separated list of pixel formats", OFFSET(pix_fmts), 
AV_OPT_TYPE_STRING, .flags = AV_OPT_FLAG_VIDEO_PARAM | 
AV_OPT_FLAG_FILTERING_PARAM },
+{ "color_spaces", "A '|'-separated list of color spaces", OFFSET(csps), 
AV_OPT_TYPE_STRING, .flags = AV_OPT_FLAG_VIDEO_PARAM | 
AV_OPT_FLAG_FILTERING_PARAM },
+{ "color_ranges", "A '|'-separated list of color ranges", OFFSET(ranges), 
AV_OPT_TYPE_STRING, .flags = AV_OPT_FLAG_VIDEO_PARAM | 
AV_OPT_FLAG_FILTERING_PARAM },
 { NULL }
 };
 
-- 
2.43.0

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

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

[FFmpeg-devel] [PATCH v2 13/15] avfilter/vf_format: re-use AVFilterFormats for pix_fmt parsing

[Niklas Haas]

From: Niklas Haas 

Rewrite the format parsing code to make it more easily generalizable. In
particular, `invert_formats` does not depend on the type of format list
passed to it, which allows me to re-use this helper in an upcoming
commit.

Slightly shortens the code, at the sole cost of doing several malloc
(ff_add_format) instead of a single malloc.
---
 libavfilter/vf_format.c | 103 +---
 1 file changed, 43 insertions(+), 60 deletions(-)

diff --git a/libavfilter/vf_format.c b/libavfilter/vf_format.c
index 1189bd61c2..59832b7768 100644
--- a/libavfilter/vf_format.c
+++ b/libavfilter/vf_format.c
@@ -41,25 +41,48 @@ typedef struct FormatContext {
 const AVClass *class;
 char *pix_fmts;
 
-/**
- * pix_fmts parsed into AVPixelFormats and terminated with
- * AV_PIX_FMT_NONE
- */
-enum AVPixelFormat *formats;
+AVFilterFormats *formats; ///< parsed from `pix_fmts`
 } FormatContext;
 
 static av_cold void uninit(AVFilterContext *ctx)
 {
 FormatContext *s = ctx->priv;
-av_freep(&s->formats);
+ff_formats_unref(&s->formats);
+}
+
+static av_cold int invert_formats(AVFilterFormats **fmts,
+  AVFilterFormats *allfmts)
+{
+if (!allfmts)
+return AVERROR(ENOMEM);
+if (!*fmts) {
+/* empty fmt list means no restriction, regardless of filter type */
+ff_formats_unref(&allfmts);
+return 0;
+}
+
+for (int i = 0; i < allfmts->nb_formats; i++) {
+for (int j = 0; j < (*fmts)->nb_formats; j++) {
+if (allfmts->formats[i] == (*fmts)->formats[j]) {
+/* format is forbidden, remove it from allfmts list */
+memmove(&allfmts->formats[i], &allfmts->formats[i+1],
+(allfmts->nb_formats - (i+1)) * 
sizeof(*allfmts->formats));
+allfmts->nb_formats--;
+i--; /* repeat loop with same idx */
+break;
+}
+}
+}
+
+ff_formats_unref(fmts);
+*fmts = allfmts;
+return 0;
 }
 
 static av_cold int init(AVFilterContext *ctx)
 {
 FormatContext *s = ctx->priv;
-char *cur, *sep;
-int nb_formats = 1;
-int i;
+enum AVPixelFormat pix_fmt;
 int ret;
 
 if (!s->pix_fmts) {
@@ -67,64 +90,24 @@ static av_cold int init(AVFilterContext *ctx)
 return AVERROR(EINVAL);
 }
 
-/* count the formats */
-cur = s->pix_fmts;
-while ((cur = strchr(cur, '|'))) {
-nb_formats++;
-if (*cur)
-cur++;
-}
-
-s->formats = av_malloc_array(nb_formats + 1, sizeof(*s->formats));
-if (!s->formats)
-return AVERROR(ENOMEM);
-
-/* parse the list of formats */
-cur = s->pix_fmts;
-for (i = 0; i < nb_formats; i++) {
+for (char *sep, *cur = s->pix_fmts; cur; cur = sep) {
 sep = strchr(cur, '|');
-if (sep)
+if (sep && *sep)
 *sep++ = 0;
-
-if ((ret = ff_parse_pixel_format(&s->formats[i], cur, ctx)) < 0)
+if ((ret = ff_parse_pixel_format(&pix_fmt, cur, ctx)) < 0 ||
+(ret = ff_add_format(&s->formats, pix_fmt)) < 0)
 return ret;
-
-cur = sep;
 }
-s->formats[nb_formats] = AV_PIX_FMT_NONE;
 
 if (!strcmp(ctx->filter->name, "noformat")) {
-const AVPixFmtDescriptor *desc = NULL;
-enum AVPixelFormat *formats_allowed;
-int nb_formats_lavu = 0, nb_formats_allowed = 0;
-
-/* count the formats known to lavu */
-while ((desc = av_pix_fmt_desc_next(desc)))
-nb_formats_lavu++;
-
-formats_allowed = av_malloc_array(nb_formats_lavu + 1, 
sizeof(*formats_allowed));
-if (!formats_allowed)
-return AVERROR(ENOMEM);
-
-/* for each format known to lavu, check if it's in the list of
- * forbidden formats */
-while ((desc = av_pix_fmt_desc_next(desc))) {
-enum AVPixelFormat pix_fmt = av_pix_fmt_desc_get_id(desc);
-
-for (i = 0; i < nb_formats; i++) {
-if (s->formats[i] == pix_fmt)
-break;
-}
-if (i < nb_formats)
-continue;
-
-formats_allowed[nb_formats_allowed++] = pix_fmt;
-}
-formats_allowed[nb_formats_allowed] = AV_PIX_FMT_NONE;
-av_freep(&s->formats);
-s->formats = formats_allowed;
+if ((ret = invert_formats(&s->formats, 
ff_all_formats(AVMEDIA_TYPE_VIDEO))) < 0)
+return ret;
 }
 
+/* hold on to a ref for the lifetime of the filter */
+if ((ret = ff_formats_ref(s->formats, &s->formats)) < 0)
+return ret;
+
 return 0;
 }
 
@@ -132,7 +115,7 @@ static int query_formats(AVFilterContext *ctx)
 {
 FormatContext *s = ctx->priv;
 
-return ff_set_common_formats_from_list(ctx, s->formats);
+return ff_set_common_formats(ctx, s->formats);
 }
 
 
-- 
2.43.0

___
ffmpeg

[FFmpeg-devel] [PATCH v2 15/15] avfilter/vf_format: allow empty pix_fmts list

[Niklas Haas]

From: Niklas Haas 

Which will impose no restriction. This makes sense when using e.g.
`color_ranges=pc` to limit the color range, without also limiting the
pixel format.
---
 libavfilter/vf_format.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/libavfilter/vf_format.c b/libavfilter/vf_format.c
index d1bb9daa97..3a353bbb0d 100644
--- a/libavfilter/vf_format.c
+++ b/libavfilter/vf_format.c
@@ -91,11 +91,6 @@ static av_cold int init(AVFilterContext *ctx)
 enum AVPixelFormat pix_fmt;
 int ret;
 
-if (!s->pix_fmts) {
-av_log(ctx, AV_LOG_ERROR, "Empty output format string.\n");
-return AVERROR(EINVAL);
-}
-
 for (char *sep, *cur = s->pix_fmts; cur; cur = sep) {
 sep = strchr(cur, '|');
 if (sep && *sep)
@@ -131,7 +126,7 @@ static av_cold int init(AVFilterContext *ctx)
 }
 
 /* hold on to a ref for the lifetime of the filter */
-if ((ret = ff_formats_ref(s->formats, &s->formats)) < 0 ||
+if (s->formats  && (ret = ff_formats_ref(s->formats,  
&s->formats)) < 0 ||
 s->color_spaces && (ret = ff_formats_ref(s->color_spaces, 
&s->color_spaces)) < 0 ||
 s->color_ranges && (ret = ff_formats_ref(s->color_ranges, 
&s->color_ranges)) < 0)
 return ret;
@@ -144,7 +139,7 @@ static int query_formats(AVFilterContext *ctx)
 FormatContext *s = ctx->priv;
 int ret;
 
-if ((ret = ff_set_common_formats(ctx, s->formats)) < 0 ||
+if (s->formats  && (ret = ff_set_common_formats(ctx,  s->formats)) 
< 0 ||
 s->color_spaces && (ret = ff_set_common_color_spaces(ctx, 
s->color_spaces)) < 0 ||
 s->color_ranges && (ret = ff_set_common_color_ranges(ctx, 
s->color_ranges)) < 0)
 return ret;
-- 
2.43.0

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

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

[FFmpeg-devel] [PATCH v2 05/15] avfilter/buffersrc: add color_space/range parameters

[Niklas Haas]

From: Niklas Haas 

To allow adding proper negotiation, in particular, to fftools.

These values will simply be negotiated downstream for YUV formats, and
ignored otherwise.
---
 doc/filters.texi| 10 ++
 libavfilter/buffersrc.c | 74 -
 libavfilter/buffersrc.h |  6 
 3 files changed, 82 insertions(+), 8 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 6d00ba2c3f..f182dc2ddb 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -28025,6 +28025,16 @@ Specify the timebase assumed by the timestamps of the 
buffered frames.
 @item frame_rate
 Specify the frame rate expected for the video stream.
 
+@item colorspace
+A string representing the color space of the buffered video frames.
+It may be a number corresponding to a color space, or a color space
+name.
+
+@item range
+A string representing the color range of the buffered video frames.
+It may be a number corresponding to a color range, or a color range
+name.
+
 @item pixel_aspect, sar
 The sample (pixel) aspect ratio of the input video.
 
diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
index b0a905d455..1c5db94696 100644
--- a/libavfilter/buffersrc.c
+++ b/libavfilter/buffersrc.c
@@ -28,6 +28,7 @@
 #include "libavutil/channel_layout.h"
 #include "libavutil/common.h"
 #include "libavutil/frame.h"
+#include "libavutil/hwcontext.h"
 #include "libavutil/imgutils.h"
 #include "libavutil/internal.h"
 #include "libavutil/opt.h"
@@ -50,6 +51,8 @@ typedef struct BufferSourceContext {
 /* video only */
 int   w, h;
 enum AVPixelFormat  pix_fmt;
+enum AVColorSpace color_space;
+enum AVColorRange color_range;
 AVRationalpixel_aspect;
 
 AVBufferRef *hw_frames_ctx;
@@ -65,10 +68,13 @@ typedef struct BufferSourceContext {
 int64_t last_pts;
 } BufferSourceContext;
 
-#define CHECK_VIDEO_PARAM_CHANGE(s, c, width, height, format, pts)\
-if (c->w != width || c->h != height || c->pix_fmt != format) {\
-av_log(s, AV_LOG_INFO, "filter context - w: %d h: %d fmt: %d, incoming 
frame - w: %d h: %d fmt: %d pts_time: %s\n",\
-   c->w, c->h, c->pix_fmt, width, height, format, 
av_ts2timestr(pts, &s->outputs[0]->time_base));\
+#define CHECK_VIDEO_PARAM_CHANGE(s, c, width, height, format, csp, range, pts)\
+if (c->w != width || c->h != height || c->pix_fmt != format ||\
+c->color_space != csp || c->color_range != range) {\
+av_log(s, AV_LOG_INFO, "filter context - w: %d h: %d fmt: %d csp: %s 
range: %s, incoming frame - w: %d h: %d fmt: %d csp: %s range: %s pts_time: 
%s\n",\
+   c->w, c->h, c->pix_fmt, av_color_space_name(c->color_space), 
av_color_range_name(c->color_range),\
+   width, height, format, av_color_space_name(csp), 
av_color_range_name(range),\
+   av_ts2timestr(pts, &s->outputs[0]->time_base));\
 av_log(s, AV_LOG_WARNING, "Changing video frame properties on the fly 
is not supported by all filters.\n");\
 }
 
@@ -89,6 +95,8 @@ AVBufferSrcParameters *av_buffersrc_parameters_alloc(void)
 return NULL;
 
 par->format = -1;
+par->color_range = AVCOL_RANGE_UNSPECIFIED;
+par->color_space = AVCOL_SPC_UNSPECIFIED;
 
 return par;
 }
@@ -119,6 +127,10 @@ int av_buffersrc_parameters_set(AVFilterContext *ctx, 
AVBufferSrcParameters *par
 if (!s->hw_frames_ctx)
 return AVERROR(ENOMEM);
 }
+if (param->color_space != AVCOL_SPC_UNSPECIFIED)
+s->color_space = param->color_space;
+if (param->color_range != AVCOL_RANGE_UNSPECIFIED)
+s->color_range = param->color_range;
 break;
 case AVMEDIA_TYPE_AUDIO:
 if (param->format != AV_SAMPLE_FMT_NONE) {
@@ -206,7 +218,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
 switch (ctx->outputs[0]->type) {
 case AVMEDIA_TYPE_VIDEO:
 CHECK_VIDEO_PARAM_CHANGE(ctx, s, frame->width, frame->height,
- frame->format, frame->pts);
+ frame->format, frame->colorspace,
+ frame->color_range, frame->pts);
 break;
 case AVMEDIA_TYPE_AUDIO:
 /* For layouts unknown on input but known on link after 
negotiation. */
@@ -303,10 +316,11 @@ static av_cold int init_video(AVFilterContext *ctx)
 return AVERROR(EINVAL);
 }
 
-av_log(ctx, AV_LOG_VERBOSE, "w:%d h:%d pixfmt:%s tb:%d/%d fr:%d/%d 
sar:%d/%d\n",
+av_log(ctx, AV_LOG_VERBOSE, "w:%d h:%d pixfmt:%s tb:%d/%d fr:%d/%d 
sar:%d/%d csp:%s range:%s\n",
c->w, c->h, av_get_pix_fmt_name(c->pix_fmt),
c->time_base.num, c->time_base.den, c->frame_rate.num, 
c->frame_rate.den,
-   c->pixel_aspect.num, c->pixel_aspect.den);
+   c->pixel_aspect.num, c->pixel_aspect.den,
+   av_color_space_name(c->color_space), 
av_color_range_name(c->color_range));
 
 return 0;

[FFmpeg-devel] [PATCH v2 06/15] fftools/ffmpeg_filter: configure buffersrc with csp/range

[Niklas Haas]

From: Niklas Haas 

Propagates input metadata to the input filter graph.
---
 fftools/ffmpeg_filter.c | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index e5b00123f2..2da6d307a0 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -126,6 +126,8 @@ typedef struct InputFilterPriv {
 
 int width, height;
 AVRational sample_aspect_ratio;
+enum AVColorSpace color_space;
+enum AVColorRange color_range;
 
 int sample_rate;
 AVChannelLayout ch_layout;
@@ -146,6 +148,8 @@ typedef struct InputFilterPriv {
 int width;
 int height;
 AVRational  sample_aspect_ratio;
+enum AVColorSpace   color_space;
+enum AVColorRange   color_range;
 
 int sample_rate;
 AVChannelLayout ch_layout;
@@ -257,6 +261,8 @@ static int sub2video_get_blank_frame(InputFilterPriv *ifp)
 frame->width  = ifp->width;
 frame->height = ifp->height;
 frame->format = ifp->format;
+frame->colorspace = ifp->color_space;
+frame->color_range = ifp->color_range;
 
 ret = av_frame_get_buffer(frame, 0);
 if (ret < 0)
@@ -833,6 +839,8 @@ static InputFilter *ifilter_alloc(FilterGraph *fg)
 ifp->index   = fg->nb_inputs - 1;
 ifp->format  = -1;
 ifp->fallback.format = -1;
+ifp->color_space = ifp->fallback.color_space = AVCOL_SPC_UNSPECIFIED;
+ifp->color_range = ifp->fallback.color_range = AVCOL_RANGE_UNSPECIFIED;
 
 ifp->frame_queue = av_fifo_alloc2(8, sizeof(AVFrame*), 
AV_FIFO_FLAG_AUTO_GROW);
 if (!ifp->frame_queue)
@@ -1485,9 +1493,11 @@ static int configure_input_video_filter(FilterGraph *fg, 
InputFilter *ifilter,
 av_bprint_init(&args, 0, AV_BPRINT_SIZE_AUTOMATIC);
 av_bprintf(&args,
  "video_size=%dx%d:pix_fmt=%d:time_base=%d/%d:"
- "pixel_aspect=%d/%d",
+ "pixel_aspect=%d/%d:colorspace=%s:range=%s",
  ifp->width, ifp->height, ifp->format,
- ifp->time_base.num, ifp->time_base.den, sar.num, sar.den);
+ ifp->time_base.num, ifp->time_base.den, sar.num, sar.den,
+ av_color_space_name(ifp->color_space),
+ av_color_range_name(ifp->color_range));
 if (fr.num && fr.den)
 av_bprintf(&args, ":frame_rate=%d/%d", fr.num, fr.den);
 snprintf(name, sizeof(name), "graph %d input from stream %d:%d", fg->index,
@@ -1831,6 +1841,8 @@ int ifilter_parameters_from_dec(InputFilter *ifilter, 
const AVCodecContext *dec)
 ifp->fallback.width  = dec->width;
 ifp->fallback.height = dec->height;
 ifp->fallback.sample_aspect_ratio= dec->sample_aspect_ratio;
+ifp->fallback.color_space= dec->colorspace;
+ifp->fallback.color_range= dec->color_range;
 } else if (dec->codec_type == AVMEDIA_TYPE_AUDIO) {
 int ret;
 
@@ -1871,6 +1883,8 @@ static int ifilter_parameters_from_frame(InputFilter 
*ifilter, const AVFrame *fr
 ifp->width   = frame->width;
 ifp->height  = frame->height;
 ifp->sample_aspect_ratio = frame->sample_aspect_ratio;
+ifp->color_space = frame->colorspace;
+ifp->color_range = frame->color_range;
 
 ifp->sample_rate = frame->sample_rate;
 ret = av_channel_layout_copy(&ifp->ch_layout, &frame->ch_layout);
@@ -2543,6 +2557,8 @@ static int send_eof(FilterGraphThread *fgt, InputFilter 
*ifilter,
 ifp->width  = ifp->fallback.width;
 ifp->height = ifp->fallback.height;
 ifp->sample_aspect_ratio= ifp->fallback.sample_aspect_ratio;
+ifp->color_space= ifp->fallback.color_space;
+ifp->color_range= ifp->fallback.color_range;
 
 ret = av_channel_layout_copy(&ifp->ch_layout,
  &ifp->fallback.ch_layout);
@@ -2586,7 +2602,9 @@ static int send_frame(FilterGraph *fg, FilterGraphThread 
*fgt,
 break;
 case AVMEDIA_TYPE_VIDEO:
 need_reinit |= ifp->width  != frame->width ||
-   ifp->height != frame->height;
+   ifp->height != frame->height ||
+   ifp->color_space != frame->colorspace ||
+   ifp->color_range != frame->color_range;
 break;
 }
 
-- 
2.43.0

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

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

[FFmpeg-devel] [PATCH v2 07/15] vf_scale: use colorspace negotiation API

[Niklas Haas]

From: Niklas Haas 

This filter will always accept any input format, even if the user sets
a specific in_range/in_color_matrix. This is to preserve status quo with
current behavior, where passing a specific in_color_matrix merely
overrides the incoming frames' attributes. (Use `vf_format` to force
a specific input range)

Because changing colorspace and color_range now requires reconfiguring
the link, we can lift sws_setColorspaceDetails out of scale_frame and
into config_props. (This will also get re-called if the input frame
properties change)
---
 libavfilter/vf_scale.c | 188 ++---
 1 file changed, 103 insertions(+), 85 deletions(-)

diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index b45035907b..44dc1f2bf8 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -143,7 +143,6 @@ typedef struct ScaleContext {
 int out_color_matrix;
 
 int in_range;
-int in_frame_range;
 int out_range;
 
 int out_h_chr_pos;
@@ -292,6 +291,18 @@ static av_cold int preinit(AVFilterContext *ctx)
 return 0;
 }
 
+static const int sws_colorspaces[] = {
+AVCOL_SPC_UNSPECIFIED,
+AVCOL_SPC_RGB,
+AVCOL_SPC_BT709,
+AVCOL_SPC_BT470BG,
+AVCOL_SPC_SMPTE170M,
+AVCOL_SPC_FCC,
+AVCOL_SPC_SMPTE240M,
+AVCOL_SPC_BT2020_NCL,
+-1
+};
+
 static av_cold int init(AVFilterContext *ctx)
 {
 ScaleContext *scale = ctx->priv;
@@ -332,6 +343,19 @@ static av_cold int init(AVFilterContext *ctx)
 if (ret < 0)
 return ret;
 
+if (scale->in_color_matrix != -1 &&
+!ff_fmt_is_in(scale->in_color_matrix, sws_colorspaces)) {
+av_log(ctx, AV_LOG_ERROR, "Unsupported input color matrix '%s'\n",
+   av_color_space_name(scale->in_color_matrix));
+return AVERROR(EINVAL);
+}
+
+if (!ff_fmt_is_in(scale->out_color_matrix, sws_colorspaces)) {
+av_log(ctx, AV_LOG_ERROR, "Unsupported output color matrix '%s'\n",
+   av_color_space_name(scale->out_color_matrix));
+return AVERROR(EINVAL);
+}
+
 av_log(ctx, AV_LOG_VERBOSE, "w:%s h:%s flags:'%s' interl:%d\n",
scale->w_expr, scale->h_expr, (char 
*)av_x_if_null(scale->flags_str, ""), scale->interlaced);
 
@@ -356,8 +380,6 @@ static av_cold int init(AVFilterContext *ctx)
 if (!threads)
 av_opt_set_int(scale->sws_opts, "threads", 
ff_filter_get_nb_threads(ctx), 0);
 
-scale->in_frame_range = AVCOL_RANGE_UNSPECIFIED;
-
 return 0;
 }
 
@@ -376,6 +398,7 @@ static av_cold void uninit(AVFilterContext *ctx)
 
 static int query_formats(AVFilterContext *ctx)
 {
+ScaleContext *scale = ctx->priv;
 AVFilterFormats *formats;
 const AVPixFmtDescriptor *desc;
 enum AVPixelFormat pix_fmt;
@@ -407,6 +430,28 @@ static int query_formats(AVFilterContext *ctx)
 if ((ret = ff_formats_ref(formats, &ctx->outputs[0]->incfg.formats)) < 0)
 return ret;
 
+/* accept all supported inputs, even if user overrides their properties */
+if ((ret = ff_formats_ref(ff_make_format_list(sws_colorspaces),
+  &ctx->inputs[0]->outcfg.color_spaces)) < 0)
+return ret;
+
+if ((ret = ff_formats_ref(ff_all_color_ranges(),
+  &ctx->inputs[0]->outcfg.color_ranges)) < 0)
+return ret;
+
+/* propagate output properties if overridden */
+formats = scale->out_color_matrix != AVCOL_SPC_UNSPECIFIED
+? ff_make_formats_list_singleton(scale->out_color_matrix)
+: ff_make_format_list(sws_colorspaces);
+if ((ret = ff_formats_ref(formats, &ctx->outputs[0]->incfg.color_spaces)) 
< 0)
+return ret;
+
+formats = scale->out_range != AVCOL_RANGE_UNSPECIFIED
+? ff_make_formats_list_singleton(scale->out_range)
+: ff_all_color_ranges();
+if ((ret = ff_formats_ref(formats, &ctx->outputs[0]->incfg.color_ranges)) 
< 0)
+return ret;
+
 return 0;
 }
 
@@ -497,6 +542,7 @@ static int config_props(AVFilterLink *outlink)
 const AVPixFmtDescriptor *outdesc = av_pix_fmt_desc_get(outfmt);
 ScaleContext *scale = ctx->priv;
 uint8_t *flags_val = NULL;
+int in_range, in_colorspace;
 int ret;
 
 if ((ret = scale_eval_dimensions(ctx)) < 0)
@@ -521,6 +567,14 @@ static int config_props(AVFilterLink *outlink)
 if (outfmt == AV_PIX_FMT_PAL8) outfmt = AV_PIX_FMT_BGR8;
 scale->output_is_pal = av_pix_fmt_desc_get(outfmt)->flags & 
AV_PIX_FMT_FLAG_PAL;
 
+in_range = scale->in_range;
+if (in_range == AVCOL_RANGE_UNSPECIFIED)
+in_range = inlink0->color_range;
+
+in_colorspace = scale->in_color_matrix;
+if (in_colorspace == -1 /* auto */)
+in_colorspace = inlink0->colorspace;
+
 if (scale->sws)
 sws_freeContext(scale->sws);
 if (scale->isws[0])
@@ -530,8 +584,8 @@ static int config_props(AVFilterLink *outlink)
 scale->isws[0] = scale->isws[1] = scale->sws = NULL;
 if (inlink0->w

[FFmpeg-devel] [PATCH v2 08/15] avfilter/vf_zscale: remove unused variables

[Niklas Haas]

From: Niklas Haas 

Only assigned, never read.
---
 libavfilter/vf_zscale.c | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index 788870ffaf..f76c9954cd 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -132,12 +132,6 @@ typedef struct ZScaleContext {
 zimg_graph_builder_params alpha_params, params;
 zimg_graph_builder_params alpha_params_tmp, params_tmp;
 zimg_filter_graph *alpha_graph[MAX_THREADS], *graph[MAX_THREADS];
-
-enum AVColorSpace in_colorspace, out_colorspace;
-enum AVColorTransferCharacteristic in_trc, out_trc;
-enum AVColorPrimaries in_primaries, out_primaries;
-enum AVColorRange in_range, out_range;
-enum AVChromaLocation in_chromal, out_chromal;
 } ZScaleContext;
 
 typedef struct ThreadData {
@@ -816,15 +810,6 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
 link->dst->inputs[0]->h  = in->height;
 
 s->nb_threads = av_clip(FFMIN(ff_filter_get_nb_threads(ctx), 
FFMIN(link->h, outlink->h) / MIN_TILESIZE), 1, MAX_THREADS);
-s->in_colorspace = in->colorspace;
-s->in_trc = in->color_trc;
-s->in_primaries = in->color_primaries;
-s->in_range = in->color_range;
-s->out_colorspace = out->colorspace;
-s->out_trc = out->color_trc;
-s->out_primaries = out->color_primaries;
-s->out_range = out->color_range;
-
 slice_params(s, out->height, in->height);
 
 zimg_image_format_default(&s->src_format, ZIMG_API_VERSION);
-- 
2.43.0

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

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

[FFmpeg-devel] [PATCH v2 09/15] avfilter/vf_zscale: switch to colorspace negotiation API

[Niklas Haas]

From: Niklas Haas 

Following the same design as vf_scale.
---
 libavfilter/vf_zscale.c | 44 +++--
 1 file changed, 34 insertions(+), 10 deletions(-)

diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index f76c9954cd..3b14ce4f33 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -187,8 +187,12 @@ static av_cold int init(AVFilterContext *ctx)
 return 0;
 }
 
+static enum AVColorRange convert_range_from_zimg(enum zimg_pixel_range_e 
color_range);
+
 static int query_formats(AVFilterContext *ctx)
 {
+ZScaleContext *s = ctx->priv;
+AVFilterFormats *formats;
 static const enum AVPixelFormat pixel_fmts[] = {
 AV_PIX_FMT_YUV410P, AV_PIX_FMT_YUV411P,
 AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P,
@@ -217,7 +221,27 @@ static int query_formats(AVFilterContext *ctx)
 ret = ff_formats_ref(ff_make_format_list(pixel_fmts), 
&ctx->inputs[0]->outcfg.formats);
 if (ret < 0)
 return ret;
-return ff_formats_ref(ff_make_format_list(pixel_fmts), 
&ctx->outputs[0]->incfg.formats);
+ret = ff_formats_ref(ff_make_format_list(pixel_fmts), 
&ctx->outputs[0]->incfg.formats);
+if (ret < 0)
+return ret;
+
+if ((ret = ff_formats_ref(ff_all_color_spaces(), 
&ctx->inputs[0]->outcfg.formats)) < 0 ||
+(ret = ff_formats_ref(ff_all_color_ranges(), 
&ctx->inputs[0]->outcfg.formats)) < 0)
+return ret;
+
+formats = s->colorspace != ZIMG_MATRIX_UNSPECIFIED && s->colorspace > 0
+? ff_make_formats_list_singleton(s->colorspace)
+: ff_all_color_spaces();
+if ((ret = ff_formats_ref(formats, &ctx->outputs[0]->incfg.formats)) < 0)
+return ret;
+
+formats = s->range != -1
+? ff_make_formats_list_singleton(convert_range_from_zimg(s->range))
+: ff_all_color_ranges();
+if ((ret = ff_formats_ref(formats, &ctx->outputs[0]->incfg.formats)) < 0)
+return ret;
+
+return 0;
 }
 
 static void slice_params(ZScaleContext *s, int out_h, int in_h)
@@ -678,15 +702,9 @@ fail:
 
 static void update_output_color_information(ZScaleContext *s, AVFrame *frame)
 {
-if (s->colorspace != -1)
-frame->colorspace = (int)s->dst_format.matrix_coefficients;
-
 if (s->primaries != -1)
 frame->color_primaries = (int)s->dst_format.color_primaries;
 
-if (s->range != -1)
-frame->color_range = 
convert_range_from_zimg(s->dst_format.pixel_range);
-
 if (s->trc != -1)
 frame->color_trc = (int)s->dst_format.transfer_characteristics;
 
@@ -775,6 +793,8 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
 if ((link->format != outlink->format) ||
 (link->w != outlink->w) ||
 (link->h != outlink->h) ||
+(link->colorspace != outlink->colorspace) ||
+(link->color_range != outlink->color_range) ||
 s->first_time ||
 (s->src_format.chroma_location != s->dst_format.chroma_location) ||
 (s->src_format.color_family !=s->dst_format.color_family) ||
@@ -796,6 +816,8 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
 goto fail;
 
 av_frame_copy_props(out, in);
+out->colorspace = outlink->colorspace;
+out->color_range = outlink->color_range;
 
 if ((ret = realign_frame(desc, &in, 1)) < 0)
 goto fail;
@@ -805,9 +827,11 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
 snprintf(buf, sizeof(buf)-1, "%d", outlink->h);
 av_opt_set(s, "h", buf, 0);
 
-link->dst->inputs[0]->format = in->format;
-link->dst->inputs[0]->w  = in->width;
-link->dst->inputs[0]->h  = in->height;
+link->dst->inputs[0]->format  = in->format;
+link->dst->inputs[0]->w   = in->width;
+link->dst->inputs[0]->h   = in->height;
+link->dst->inputs[0]->colorspace  = in->colorspace;
+link->dst->inputs[0]->color_range = in->color_range;
 
 s->nb_threads = av_clip(FFMIN(ff_filter_get_nb_threads(ctx), 
FFMIN(link->h, outlink->h) / MIN_TILESIZE), 1, MAX_THREADS);
 slice_params(s, out->height, in->height);
-- 
2.43.0

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

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

[FFmpeg-devel] [PATCH v2 10/15] avfilter/vf_libplacebo: don't force dovi frames to bt.2020-ncl

[Niklas Haas]

From: Niklas Haas 

This is at odds with the YUV matrix negotiation API, in which such
dynamic changes in YUV encoding are no longer easily possible. There is
also no really strong motivating reason to do this, since the choice of
YUV matrix is essentially arbitrary and not actually related to the
Dolby Vision decoding process.
---
 libavfilter/vf_libplacebo.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavfilter/vf_libplacebo.c b/libavfilter/vf_libplacebo.c
index 8534945ba6..b6e82a61e0 100644
--- a/libavfilter/vf_libplacebo.c
+++ b/libavfilter/vf_libplacebo.c
@@ -888,7 +888,6 @@ static int output_frame(AVFilterContext *ctx, int64_t pts)
 if (s->apply_dovi && av_frame_get_side_data(ref, 
AV_FRAME_DATA_DOVI_METADATA)) {
 /* Output of dovi reshaping is always BT.2020+PQ, so infer the correct
  * output colorspace defaults */
-out->colorspace = AVCOL_SPC_BT2020_NCL;
 out->color_primaries = AVCOL_PRI_BT2020;
 out->color_trc = AVCOL_TRC_SMPTE2084;
 }
-- 
2.43.0

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

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

[FFmpeg-devel] [PATCH v2 12/15] avfilter/buffersink: add color space/range accessors

[Niklas Haas]

From: Niklas Haas 

Needed for fftools.
---
 doc/APIchanges   | 3 +++
 libavfilter/buffersink.c | 2 ++
 libavfilter/buffersink.h | 2 ++
 libavfilter/version.h| 2 +-
 4 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 2f6ea50f63..578c2c4641 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
 
 API changes, most recent first:
 
+2023-11-xx - xx - lavf 58.15.100 - buffersink.h
+  Add av_buffersink_get_colorspace and av_buffersink_get_color_range.
+
 2023-11-xx - xx - lavf 58.14.100 - avfilter.h
   Add AVFilterLink.colorspace, AVFilterLink.color_range
 
diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
index 3da3331159..6ba2970dd5 100644
--- a/libavfilter/buffersink.c
+++ b/libavfilter/buffersink.c
@@ -209,6 +209,8 @@ MAKE_AVFILTERLINK_ACCESSOR(AVRational   , frame_rate
 )
 MAKE_AVFILTERLINK_ACCESSOR(int  , w  )
 MAKE_AVFILTERLINK_ACCESSOR(int  , h  )
 MAKE_AVFILTERLINK_ACCESSOR(AVRational   , sample_aspect_ratio)
+MAKE_AVFILTERLINK_ACCESSOR(enum AVColorSpace, colorspace)
+MAKE_AVFILTERLINK_ACCESSOR(enum AVColorRange, color_range)
 
 #if FF_API_OLD_CHANNEL_LAYOUT
 FF_DISABLE_DEPRECATION_WARNINGS
diff --git a/libavfilter/buffersink.h b/libavfilter/buffersink.h
index 64e08de53e..a9374b8b4f 100644
--- a/libavfilter/buffersink.h
+++ b/libavfilter/buffersink.h
@@ -117,6 +117,8 @@ AVRational   av_buffersink_get_frame_rate  
(const AVFilterContext *c
 int  av_buffersink_get_w   (const AVFilterContext 
*ctx);
 int  av_buffersink_get_h   (const AVFilterContext 
*ctx);
 AVRational   av_buffersink_get_sample_aspect_ratio (const AVFilterContext 
*ctx);
+enum AVColorSpace av_buffersink_get_colorspace (const AVFilterContext 
*ctx);
+enum AVColorRange av_buffersink_get_color_range(const AVFilterContext 
*ctx);
 
 int  av_buffersink_get_channels(const AVFilterContext 
*ctx);
 #if FF_API_OLD_CHANNEL_LAYOUT
diff --git a/libavfilter/version.h b/libavfilter/version.h
index 7642b670d1..59330858bd 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -31,7 +31,7 @@
 
 #include "version_major.h"
 
-#define LIBAVFILTER_VERSION_MINOR  14
+#define LIBAVFILTER_VERSION_MINOR  15
 #define LIBAVFILTER_VERSION_MICRO 100
 
 
-- 
2.43.0

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

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

[FFmpeg-devel] [PATCH v2 11/15] avfilter/vf_libplacebo: switch to colorspace negotiation API

[Niklas Haas]

From: Niklas Haas 

---
 libavfilter/vf_libplacebo.c | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/libavfilter/vf_libplacebo.c b/libavfilter/vf_libplacebo.c
index b6e82a61e0..a9a3d884ce 100644
--- a/libavfilter/vf_libplacebo.c
+++ b/libavfilter/vf_libplacebo.c
@@ -882,6 +882,8 @@ static int output_frame(AVFilterContext *ctx, int64_t pts)
 out->pts = pts;
 out->width = outlink->w;
 out->height = outlink->h;
+out->colorspace = outlink->colorspace;
+out->color_range = outlink->color_range;
 if (s->fps.num)
 out->duration = 1;
 
@@ -892,22 +894,11 @@ static int output_frame(AVFilterContext *ctx, int64_t pts)
 out->color_trc = AVCOL_TRC_SMPTE2084;
 }
 
-if (s->colorspace >= 0)
-out->colorspace = s->colorspace;
-if (s->color_range >= 0)
-out->color_range = s->color_range;
 if (s->color_trc >= 0)
 out->color_trc = s->color_trc;
 if (s->color_primaries >= 0)
 out->color_primaries = s->color_primaries;
 
-/* Sanity colorspace overrides */
-if (outdesc->flags & AV_PIX_FMT_FLAG_RGB) {
-out->colorspace = AVCOL_SPC_RGB;
-} else if (out->colorspace == AVCOL_SPC_RGB) {
-out->colorspace = AVCOL_SPC_UNSPECIFIED;
-}
-
 changed_csp = ref->colorspace  != out->colorspace ||
   ref->color_range != out->color_range||
   ref->color_trc   != out->color_trc  ||
@@ -1203,6 +1194,18 @@ static int libplacebo_query_format(AVFilterContext *ctx)
 for (int i = 0; i < s->nb_inputs; i++)
 RET(ff_formats_ref(infmts, &ctx->inputs[i]->outcfg.formats));
 RET(ff_formats_ref(outfmts, &ctx->outputs[0]->incfg.formats));
+
+/* Set colorspace properties */
+RET(ff_formats_ref(ff_all_color_spaces(), 
&ctx->inputs[0]->outcfg.color_spaces));
+RET(ff_formats_ref(ff_all_color_ranges(), 
&ctx->inputs[0]->outcfg.color_ranges));
+
+outfmts = s->colorspace > 0 ? ff_make_formats_list_singleton(s->colorspace)
+: ff_all_color_spaces();
+RET(ff_formats_ref(outfmts, &ctx->outputs[0]->incfg.color_spaces));
+
+outfmts = s->color_range > 0 ? 
ff_make_formats_list_singleton(s->color_range)
+ : ff_all_color_ranges();
+RET(ff_formats_ref(outfmts, &ctx->outputs[0]->incfg.color_ranges));
 return 0;
 
 fail:
-- 
2.43.0

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

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/flvdec: support enhanced flv PacketTypeMetadata

[朱鹏飞 via ffmpeg-devel]

> 2023年12月5日 05:32，James Almer  写道：
> 
> On 11/15/2023 11:40 AM, zhupengfei via ffmpeg-devel wrote:
>> From: Zhu Pengfei <411294...@qq.com>
>> Signed-off-by: Zhu Pengfei <411294...@qq.com>
>> ---
>>  libavformat/flvdec.c | 171 ++-
>>  1 file changed, 170 insertions(+), 1 deletion(-)
>> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
>> index e25b5bd163..46bb0825ca 100644
>> --- a/libavformat/flvdec.c
>> +++ b/libavformat/flvdec.c
>> @@ -34,6 +34,7 @@
>>  #include "libavutil/intfloat.h"
>>  #include "libavutil/intreadwrite.h"
>>  #include "libavutil/mathematics.h"
>> +#include "libavutil/mastering_display_metadata.h"
>>  #include "avformat.h"
>>  #include "demux.h"
>>  #include "internal.h"
>> @@ -45,6 +46,28 @@
>>#define MAX_DEPTH 16  ///< arbitrary limit to prevent unbounded 
>> recursion
>>  +typedef struct FLVMasteringMeta {
>> +double r_x;
>> +double r_y;
>> +double g_x;
>> +double g_y;
>> +double b_x;
>> +double b_y;
>> +double white_x;
>> +double white_y;
>> +double max_luminance;
>> +double min_luminance;
>> +} FLVMasteringMeta;
>> +
>> +typedef struct FLVMetaVideoColor {
>> +uint64_t matrix_coefficients;
>> +uint64_t transfer_characteristics;
>> +uint64_t primaries;
>> +uint64_t max_cll;
>> +uint64_t max_fall;
>> +FLVMasteringMeta mastering_meta;
>> +} FLVMetaVideoColor;
>> +
>>  typedef struct FLVContext {
>>  const AVClass *class; ///< Class for private options.
>>  int trust_metadata;   ///< configure streams according onMetaData
>> @@ -80,6 +103,8 @@ typedef struct FLVContext {
>>  int64_t time_offset;
>>  int64_t time_pos;
>>  +FLVMetaVideoColor *metaVideoColor;
>> +int meta_color_info_flag;
>>  } FLVContext;
>>/* AMF date type */
>> @@ -524,6 +549,7 @@ static int amf_parse_object(AVFormatContext *s, AVStream 
>> *astream,
>>  FLVContext *flv = s->priv_data;
>>  AVIOContext *ioc;
>>  AMFDataType amf_type;
>> +FLVMetaVideoColor *meta_video_color = flv->metaVideoColor;
>>  char str_val[1024];
>>  double num_val;
>>  amf_date date;
>> @@ -655,6 +681,36 @@ static int amf_parse_object(AVFormatContext *s, 
>> AVStream *astream,
>>  } else if (!strcmp(key, "height") && vpar) {
>>  vpar->height = num_val;
>>  }
>> +} else if (!strcmp(key, "colorPrimaries") && 
>> meta_video_color) {
> 
> You should put this inside an "else if (meta_video_color)" block, instead of 
> checking for meta_video_color with every single string.
> 
> See how it's done for flv->trust_metadata above.
> 
>> +meta_video_color->primaries = num_val;
>> +} else if (!strcmp(key, "transferCharacteristics") && 
>> meta_video_color) {
>> +meta_video_color->transfer_characteristics = num_val;
>> +} else if (!strcmp(key, "matrixCoefficients") && 
>> meta_video_color) {
>> +meta_video_color->matrix_coefficients = num_val;
>> +} else if (!strcmp(key, "maxFall") && meta_video_color) {
>> +meta_video_color->max_fall = num_val;
>> +} else if (!strcmp(key, "maxCLL") && meta_video_color) {
>> +meta_video_color->max_cll = num_val;
>> +} else if (!strcmp(key, "redX") && meta_video_color) {
>> +meta_video_color->mastering_meta.r_x = num_val;
>> +} else if (!strcmp(key, "redY") && meta_video_color) {
>> +meta_video_color->mastering_meta.r_y = num_val;
>> +} else if (!strcmp(key, "greenX") && meta_video_color) {
>> +meta_video_color->mastering_meta.g_x = num_val;
>> +} else if (!strcmp(key, "greenY") && meta_video_color) {
>> +meta_video_color->mastering_meta.g_y = num_val;
>> +} else if (!strcmp(key, "blueX") && meta_video_color) {
>> +meta_video_color->mastering_meta.b_x = num_val;
>> +} else if (!strcmp(key, "blueY") && meta_video_color) {
>> +meta_video_color->mastering_meta.b_y = num_val;
>> +} else if (!strcmp(key, "whitePointX") && meta_video_color) 
>> {
>> +meta_video_color->mastering_meta.white_x = num_val;
>> +} else if (!strcmp(key, "whitePointY") && meta_video_color) 
>> {
>> +meta_video_color->mastering_meta.white_y = num_val;
>> +} else if (!strcmp(key, "maxLuminance") && 
>> meta_video_color) {
>> +meta_video_color->mastering_meta.max_luminance = 
>> num_val;
>> +} else if (!strcmp(key, "minLuminance") && 
>> meta_video_color) {
>> +meta_video_color->mastering_meta.min_luminance = 
>> num_val;
>>  }
>>  }
>>  if (amf_type == AM

Re: [FFmpeg-devel] [PATCH 2/5] fftools/ffmpeg: move parsing of -stats_* specifiers to lavu/parseutils

[Anton Khirnov]

Quoting Thilo Borgmann via ffmpeg-devel (2023-12-13 13:50:09)
> Am 13.12.23 um 13:39 schrieb Anton Khirnov:
> > Quoting Thilo Borgmann via ffmpeg-devel (2023-12-13 13:15:27)
> >> Am 13.12.23 um 13:08 schrieb Anton Khirnov:
> >>> Quoting Thilo Borgmann via ffmpeg-devel (2023-12-13 13:05:35)
>  Am 13.12.23 um 13:00 schrieb Anton Khirnov:
> > Quoting Thilo Borgmann via ffmpeg-devel (2023-12-11 16:07:22)
> >> ---
> >> fftools/ffmpeg.h  |  31 +--
> >> fftools/ffmpeg_enc.c  |   3 +-
> >> fftools/ffmpeg_mux_init.c | 152 +++-
> >> libavutil/parseutils.c| 176 
> >> ++
> >> libavutil/parseutils.h| 102 ++
> >> libavutil/version.h   |   2 +-
> >> 6 files changed, 296 insertions(+), 170 deletions(-)
> >
> > Absolutely not.
> >
> > This is application code and does not belong in the libraries.
> 
>  How else do we not have a redundant copy of all that and make sure that 
>  -stats_* options and the filter understand the same {..} directives?
> >>>
> >>> Why does that filter need to understand the same directives? No other
> >>> filter does.
> >>
> >> Because it is meant to use the file(s) the -stats_* option writes out. The 
> >> most convenient and most error resilient way is to use the very same 
> >> format string for -stats_* option as well as for the filter.
> >>
> >> Otherwise it could be a 'usual' scanf-format, but then the user has to 
> >> translate it from one format into the other - without making mistakes.
> >> But that would also mean to update the filter (if someone realizes it) if 
> >> the option ever changes.
> > 
> > Why does it need a dynamic format at all? Just postulate a fixed format
> > for its input like every other filter and none of this complexity is
> > needed.
> 
> That would unnecessarily limit the user of the -stats_* option to a
> specific format if the user also wants to use this filter later.
> Either sacrificing the other info the user wanted to process from the
> file created or having to run the same command (with distinct format
> strings for the -stats_* option) twice. Or do the conversion from his
> extensive format into the fixed format manually - without errors.

It is bad practice to design library features around the needs and
limitations of a single specific caller.

Many of the directives supported by -stats* make sense only in the
context of the ffmpeg CLI, and we may want to add many more in the
future. We definitely do not want to hardcode them into libavutil public
API.

If the problem is limiting ffmpeg CLI users to a specific stats format,
then you could extend these options to allow writing multiple stats
files with different formats.

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

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

Re: [FFmpeg-devel] [PATCH v2 7/7] avcodec: add AV_CODEC_FLAG_CLEAR

[Marton Balint]

On Wed, 13 Dec 2023, Anton Khirnov wrote:


Quoting Marton Balint (2023-12-12 19:37:57)



On Tue, 12 Dec 2023, Anton Khirnov wrote:


Quoting Marton Balint (2023-12-08 00:11:21)

Wipe reminds me of the wipe effect. How about 'predecode_clear'?


Fine with me I guess.




+ */
+#define AV_CODEC_FLAG_CLEAR   (1 << 12)
 /**
  * Only decode/encode grayscale.
  */
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 2cfb3fcf97..f9b18a2c35 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1675,6 +1675,12 @@ FF_ENABLE_DEPRECATION_WARNINGS

 validate_avframe_allocation(avctx, frame);

+if (avctx->flags & AV_CODEC_FLAG_CLEAR && avctx->codec_type == 
AVMEDIA_TYPE_VIDEO) {
+uint32_t color[4] = {0};
+ptrdiff_t linesize[4] = {frame->linesize[0], frame->linesize[1], 
frame->linesize[2], frame->linesize[3]};
+av_image_fill_color(frame->data, linesize, frame->format, color, 
frame->width, frame->height);


Should this check for errors?


Lack of error checking is intentional. av_image_fill_color might not
support all pixel formats, definitely not support hwaccel formats. It
might make sense to warn the user once, but I don't think propagating the
error back is needed here.

I primarily thought of this as a QC feature (even thought about making the
color fill green by default to make it more noticeable (YUV green happens
to be 0,0,0), but for that I'd need similar checks for colorspaces to
what I have for fill_black())...


As Mark said, I expect people to want to use it as a security feature.
So either it should work reliably, or it should be made very clear that
it's for debugging only.

For non-hwaccel pixel formats, you can fall back on memsetting the
buffer to 0.


IMHO for security you don't need to clear every frame, only new ones in
the buffer pool. Considering that it only affects the first few
frames, we might want to do that unconditionally, and not based on a
flag. And it is better to do this on the buffer level (because you might
not overwrite some bytes because of alignment with a color fill).

So for this flag, I'd rather make it clear it is not security-related, and
also that it has performance impact.


So then maybe make a FF_EC flag?


I thought about using that, but there are plenty of error concealment 
code which only checks if avctx->error_concealment is nonzero or zero, and 
not specific EC flags. So unless that is fixed (which might break existing 
behaviour) one cannot introduce a new EC flag and disable error 
concealment at the same time...


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

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

[FFmpeg-devel] Mailinglist conduct [was: [RFC] fftools/ffmpeg and libavdevice/sdl issue]

[Ronald S. Bultje]

Hi Nicolas,

On Tue, Dec 12, 2023 at 1:04 PM Nicolas George  wrote:

> But do not expect it to be fixed, they have hated lavd for ever and now
> they have all the control.
>

Your message promotes conspiracy theories ("they have all control", "they
have hated lavd for ever", etc.) and suggests that individual members are
part of this conspiracy to destroy FFmpeg (ad hominem attack). This is not
appropriate conduct on any of our project's mailing lists; there are plenty
better ways to bring up your technical concerns. Your CC requests that in
your messages to the FFmpeg developer list, you will not engage in ad
hominem attacks or conspiracy theories. Your CC also suggests trying to
assume good faith even during disagreements.

Unanimously signed,
your CC [Anton, James, Jean-Baptiste, Michael, Ronald, The Illuminati :-)]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/libjxlenc: Move JxlBasicInfo to LibJxlEncodeContext

[Zsolt Vadász via ffmpeg-devel]

On Tuesday, December 12th, 2023 at 9:17 PM, Leo Izen  wrote:
> On 12/11/23 12:05, Zsolt Vadász via ffmpeg-devel wrote:
> 
> > ---
> > libavcodec/libjxlenc.c | 45 +-
> > 1 file changed, 23 insertions(+), 22 deletions(-)
> > 
> > diff --git a/libavcodec/libjxlenc.c b/libavcodec/libjxlenc.c
> > index d707f3a61b..92a458d51a 100644
> 
> 
> Why?
My apologies, I have to admit this patch set has a lot of things left over from 
me figuring out how to go about patching the code. Will clean it up for V2.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://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] fftools/ffmpeg: move parsing of -stats_* specifiers to lavu/parseutils

[Thilo Borgmann via ffmpeg-devel]

Am 13.12.23 um 17:28 schrieb Anton Khirnov:

Quoting Thilo Borgmann via ffmpeg-devel (2023-12-13 13:50:09)

Am 13.12.23 um 13:39 schrieb Anton Khirnov:

Quoting Thilo Borgmann via ffmpeg-devel (2023-12-13 13:15:27)

Am 13.12.23 um 13:08 schrieb Anton Khirnov:

Quoting Thilo Borgmann via ffmpeg-devel (2023-12-13 13:05:35)

Am 13.12.23 um 13:00 schrieb Anton Khirnov:

Quoting Thilo Borgmann via ffmpeg-devel (2023-12-11 16:07:22)

---
 fftools/ffmpeg.h  |  31 +--
 fftools/ffmpeg_enc.c  |   3 +-
 fftools/ffmpeg_mux_init.c | 152 +++-
 libavutil/parseutils.c| 176 ++
 libavutil/parseutils.h| 102 ++
 libavutil/version.h   |   2 +-
 6 files changed, 296 insertions(+), 170 deletions(-)


Absolutely not.

This is application code and does not belong in the libraries.


How else do we not have a redundant copy of all that and make sure that 
-stats_* options and the filter understand the same {..} directives?


Why does that filter need to understand the same directives? No other
filter does.


Because it is meant to use the file(s) the -stats_* option writes out. The most 
convenient and most error resilient way is to use the very same format string 
for -stats_* option as well as for the filter.

Otherwise it could be a 'usual' scanf-format, but then the user has to 
translate it from one format into the other - without making mistakes.
But that would also mean to update the filter (if someone realizes it) if the 
option ever changes.


Why does it need a dynamic format at all? Just postulate a fixed format
for its input like every other filter and none of this complexity is
needed.


That would unnecessarily limit the user of the -stats_* option to a
specific format if the user also wants to use this filter later.
Either sacrificing the other info the user wanted to process from the
file created or having to run the same command (with distinct format
strings for the -stats_* option) twice. Or do the conversion from his
extensive format into the fixed format manually - without errors.


It is bad practice to design library features around the needs and
limitations of a single specific caller.


The callers here would be the CLI and this filter.
Very much like for av_parse_ratio().
In contrast to av_get_known_color_name() which actually has just one specific 
caller, the CLI.

Other parsing functions have more callers, some including the CLI.
And it makes only sense if we offer the same format anywhere for 
reading/writing the same thing.

This approach follows what we already do.



Many of the directives supported by -stats* make sense only in the
context of the ffmpeg CLI, and we may want to add many more in the
future. We definitely do not want to hardcode them into libavutil public
API.


At least three of them are already useful for this filter outside of the CLI.
Others might be useful for other/new uses cases as well and all of them would 
be useful if you'd want e.g. overlay them on top of the video.



If the problem is limiting ffmpeg CLI users to a specific stats format,
then you could extend these options to allow writing multiple stats
files with different formats.


This would allow for the same use-case without moving the code to libavutil for 
the price of a less versatile filter.
And some non-standard behaviour in the CLI where multiple equal options 
override each other, usually.
I find this even less preferable than a fixed forced format.

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

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

[FFmpeg-devel] [PATCH 1/2] avcodec/mjpegdec: use memset to clear alpha

[Marton Balint]

Signed-off-by: Marton Balint 
---
 libavcodec/mjpegdec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 8676155ecf..8191606f43 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -2793,8 +2793,8 @@ the_end:
 dst[0][j] = g*257 >> 16;
 dst[1][j] = b*257 >> 16;
 dst[2][j] = r*257 >> 16;
-dst[3][j] = 255;
 }
+memset(dst[3], 255, w);
 }
 }
 if (s->adobe_transform == 2 && s->avctx->pix_fmt == AV_PIX_FMT_YUVA444P) {
@@ -2816,8 +2816,8 @@ the_end:
 dst[0][j] = r*257 >> 16;
 dst[1][j] = (g*257 >> 16) + 128;
 dst[2][j] = (b*257 >> 16) + 128;
-dst[3][j] = 255;
 }
+memset(dst[3], 255, w);
 }
 }
 
-- 
2.35.3

___
ffmpeg-devel mailing list
ffmpeg-devel@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] avcodec/mjpegdec: avoid indirection when accessing avctx

[Marton Balint]

Signed-off-by: Marton Balint 
---
 libavcodec/mjpegdec.c | 38 +++---
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 8191606f43..81f724d230 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -2422,7 +2422,7 @@ redo_for_pal8:
 }
 
 s->start_code = start_code;
-if (s->avctx->debug & FF_DEBUG_STARTCODE)
+if (avctx->debug & FF_DEBUG_STARTCODE)
 av_log(avctx, AV_LOG_DEBUG, "startcode: %X\n", start_code);
 
 /* process markers */
@@ -2486,9 +2486,9 @@ redo_for_pal8:
 case SOF0:
 case SOF1:
 if (start_code == SOF0)
-s->avctx->profile = AV_PROFILE_MJPEG_HUFFMAN_BASELINE_DCT;
+avctx->profile = AV_PROFILE_MJPEG_HUFFMAN_BASELINE_DCT;
 else
-s->avctx->profile = 
AV_PROFILE_MJPEG_HUFFMAN_EXTENDED_SEQUENTIAL_DCT;
+avctx->profile = 
AV_PROFILE_MJPEG_HUFFMAN_EXTENDED_SEQUENTIAL_DCT;
 s->lossless= 0;
 s->ls  = 0;
 s->progressive = 0;
@@ -2496,7 +2496,7 @@ redo_for_pal8:
 goto fail;
 break;
 case SOF2:
-s->avctx->profile = AV_PROFILE_MJPEG_HUFFMAN_PROGRESSIVE_DCT;
+avctx->profile = AV_PROFILE_MJPEG_HUFFMAN_PROGRESSIVE_DCT;
 s->lossless= 0;
 s->ls  = 0;
 s->progressive = 1;
@@ -2504,8 +2504,8 @@ redo_for_pal8:
 goto fail;
 break;
 case SOF3:
-s->avctx->profile = AV_PROFILE_MJPEG_HUFFMAN_LOSSLESS;
-s->avctx->properties |= FF_CODEC_PROPERTY_LOSSLESS;
+avctx->profile = AV_PROFILE_MJPEG_HUFFMAN_LOSSLESS;
+avctx->properties |= FF_CODEC_PROPERTY_LOSSLESS;
 s->lossless= 1;
 s->ls  = 0;
 s->progressive = 0;
@@ -2513,8 +2513,8 @@ redo_for_pal8:
 goto fail;
 break;
 case SOF48:
-s->avctx->profile = AV_PROFILE_MJPEG_JPEG_LS;
-s->avctx->properties |= FF_CODEC_PROPERTY_LOSSLESS;
+avctx->profile = AV_PROFILE_MJPEG_JPEG_LS;
+avctx->properties |= FF_CODEC_PROPERTY_LOSSLESS;
 s->lossless= 1;
 s->ls  = 1;
 s->progressive = 0;
@@ -2549,8 +2549,8 @@ eoi_parser:
 s->got_picture = 0;
 goto the_end_no_picture;
 }
-if (s->avctx->hwaccel) {
-ret = FF_HW_SIMPLE_CALL(s->avctx, end_frame);
+if (avctx->hwaccel) {
+ret = FF_HW_SIMPLE_CALL(avctx, end_frame);
 if (ret < 0)
 return ret;
 
@@ -2621,7 +2621,7 @@ fail:
 return ret;
 the_end:
 
-is16bit = av_pix_fmt_desc_get(s->avctx->pix_fmt)->comp[0].step > 1;
+is16bit = av_pix_fmt_desc_get(avctx->pix_fmt)->comp[0].step > 1;
 
 if (AV_RB32(s->upscale_h)) {
 int p;
@@ -2640,7 +2640,7 @@ the_end:
avctx->pix_fmt == AV_PIX_FMT_GBRP ||
avctx->pix_fmt == AV_PIX_FMT_GBRAP
   );
-ret = av_pix_fmt_get_chroma_sub_sample(s->avctx->pix_fmt, &hshift, 
&vshift);
+ret = av_pix_fmt_get_chroma_sub_sample(avctx->pix_fmt, &hshift, 
&vshift);
 if (ret)
 return ret;
 
@@ -2720,7 +2720,7 @@ the_end:
avctx->pix_fmt == AV_PIX_FMT_GBRP ||
avctx->pix_fmt == AV_PIX_FMT_GBRAP
);
-ret = av_pix_fmt_get_chroma_sub_sample(s->avctx->pix_fmt, &hshift, 
&vshift);
+ret = av_pix_fmt_get_chroma_sub_sample(avctx->pix_fmt, &hshift, 
&vshift);
 if (ret)
 return ret;
 
@@ -2750,7 +2750,7 @@ the_end:
 }
 }
 if (s->flipped && !s->rgb) {
-ret = av_pix_fmt_get_chroma_sub_sample(s->avctx->pix_fmt, &hshift, 
&vshift);
+ret = av_pix_fmt_get_chroma_sub_sample(avctx->pix_fmt, &hshift, 
&vshift);
 if (ret)
 return ret;
 
@@ -2766,7 +2766,7 @@ the_end:
 }
 }
 
-if (s->avctx->pix_fmt == AV_PIX_FMT_GBRP) {
+if (avctx->pix_fmt == AV_PIX_FMT_GBRP) {
 av_assert0(s->nb_components == 3);
 FFSWAP(uint8_t *, frame->data[0], frame->data[2]);
 FFSWAP(uint8_t *, frame->data[0], frame->data[1]);
@@ -2774,7 +2774,7 @@ the_end:
 FFSWAP(int, frame->linesize[0], frame->linesize[1]);
 }
 
-if (s->adobe_transform == 0 && s->avctx->pix_fmt == AV_PIX_FMT_GBRAP) {
+if (s->adobe_transform == 0 && avctx->pix_fmt == AV_PIX_FMT_GBRAP) {
 int w = s->picture_ptr->width;
 int h = s->picture_ptr->height;
 av_assert0(s->nb_components == 4);
@@ -2797,7 +2797,7 @@ the_end:
 memset(dst[3], 255, w);
 }
 }
-if (s->adobe_transform == 2 && s->avctx->pix_fmt == AV_PIX_FMT_YUVA444P) {
+if

Re: [FFmpeg-devel] [PATCH] fate: Allow running multiple rounds of tests with differing settings

[Rémi Denis-Courmont]

Le tiistaina 12. joulukuuta 2023, 0.14.06 EET Martin Storsjö a écrit :
> This can be used to run tests multple times, with e.g. differing
> QEMU settings, by adding something like this to the FATE configuration
> file:
> 
> target_exec="qemu-aarch64-static"
> fate_targets="fate-checkasm fate-cpu"
> 
> fate_environments="sve128 sve256 sve512"
> sve128_env="QEMU_CPU=max,sve128=on"
> sve256_env="QEMU_CPU=max,sve256=on"
> sve512_env="QEMU_CPU=max,sve512=on"

I'm fine with that, but for the sake of generality, shouldn't rather the entire 
target_exec prefix be indirected? Some runners may want to use command line 
flags rather than environment variables.


-- 
Rémi Denis-Courmont
http://www.remlab.net/



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

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

[FFmpeg-devel] [PATCH 02/12] fftools/ffmpeg: replace InputStream.file_index by a pointer

[Anton Khirnov]

Reduces the need to use the input_files global array.
---
 fftools/ffmpeg.c  |  6 +++---
 fftools/ffmpeg.h  |  4 +++-
 fftools/ffmpeg_dec.c  | 10 +-
 fftools/ffmpeg_demux.c|  9 -
 fftools/ffmpeg_filter.c   | 14 +++---
 fftools/ffmpeg_mux_init.c | 10 +-
 6 files changed, 27 insertions(+), 26 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 30b594fd97..3aab302c27 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -390,7 +390,7 @@ OutputStream *ost_iter(OutputStream *prev)
 
 InputStream *ist_iter(InputStream *prev)
 {
-int if_idx  = prev ? prev->file_index : 0;
+int if_idx  = prev ? prev->file->index : 0;
 int ist_idx = prev ? prev->index + 1  : 0;
 
 for (; if_idx < nb_input_files; if_idx++) {
@@ -752,7 +752,7 @@ static void print_stream_maps(void)
 for (int j = 0; j < ist->nb_filters; j++) {
 if (!filtergraph_is_simple(ist->filters[j]->graph)) {
 av_log(NULL, AV_LOG_INFO, "  Stream #%d:%d (%s) -> %s",
-   ist->file_index, ist->index, ist->dec ? ist->dec->name 
: "?",
+   ist->file->index, ist->index, ist->dec ? ist->dec->name 
: "?",
ist->filters[j]->name);
 if (nb_filtergraphs > 1)
 av_log(NULL, AV_LOG_INFO, " (graph %d)", 
ist->filters[j]->graph->index);
@@ -781,7 +781,7 @@ static void print_stream_maps(void)
 }
 
 av_log(NULL, AV_LOG_INFO, "  Stream #%d:%d -> #%d:%d",
-   ost->ist->file_index,
+   ost->ist->file->index,
ost->ist->index,
ost->file_index,
ost->index);
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 69bd23f576..d7b6e689fc 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -333,7 +333,9 @@ typedef struct Decoder Decoder;
 typedef struct InputStream {
 const AVClass *class;
 
-int file_index;
+/* parent source */
+struct InputFile *file;
+
 int index;
 
 AVStream *st;
diff --git a/fftools/ffmpeg_dec.c b/fftools/ffmpeg_dec.c
index 5dde82a276..219bcf39e4 100644
--- a/fftools/ffmpeg_dec.c
+++ b/fftools/ffmpeg_dec.c
@@ -193,7 +193,7 @@ static void audio_ts_process(void *logctx, Decoder *d, 
AVFrame *frame)
 static int64_t video_duration_estimate(const InputStream *ist, const AVFrame 
*frame)
 {
 const Decoder *d = ist->decoder;
-const InputFile   *ifile = input_files[ist->file_index];
+const InputFile   *ifile = ist->file;
 int64_t codec_duration = 0;
 
 // XXX lavf currently makes up frame durations when they are not provided 
by
@@ -455,7 +455,7 @@ static int transcode_subtitles(InputStream *ist, const 
AVPacket *pkt,
 
 static int packet_decode(InputStream *ist, AVPacket *pkt, AVFrame *frame)
 {
-const InputFile *ifile = input_files[ist->file_index];
+const InputFile *ifile = ist->file;
 Decoder *d = ist->decoder;
 AVCodecContext *dec = ist->dec_ctx;
 const char *type_desc = av_get_media_type_string(dec->codec_type);
@@ -504,7 +504,7 @@ static int packet_decode(InputStream *ist, AVPacket *pkt, 
AVFrame *frame)
 update_benchmark(NULL);
 ret = avcodec_receive_frame(dec, frame);
 update_benchmark("decode_%s %d.%d", type_desc,
- ist->file_index, ist->index);
+ ifile->index, ist->index);
 
 if (ret == AVERROR(EAGAIN)) {
 av_assert0(pkt); // should never happen during flushing
@@ -550,7 +550,7 @@ static int packet_decode(InputStream *ist, AVPacket *pkt, 
AVFrame *frame)
 ret = video_frame_process(ist, frame);
 if (ret < 0) {
 av_log(NULL, AV_LOG_FATAL, "Error while processing the decoded 
"
-   "data for stream #%d:%d\n", ist->file_index, 
ist->index);
+   "data for stream #%d:%d\n", ifile->index, ist->index);
 return ret;
 }
 }
@@ -568,7 +568,7 @@ static int packet_decode(InputStream *ist, AVPacket *pkt, 
AVFrame *frame)
 static void dec_thread_set_name(const InputStream *ist)
 {
 char name[16];
-snprintf(name, sizeof(name), "dec%d:%d:%s", ist->file_index, ist->index,
+snprintf(name, sizeof(name), "dec%d:%d:%s", ist->file->index, ist->index,
  ist->dec_ctx->codec->name);
 ff_thread_setname(name);
 }
diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
index 91cd7a1125..61fb856106 100644
--- a/fftools/ffmpeg_demux.c
+++ b/fftools/ffmpeg_demux.c
@@ -463,8 +463,7 @@ static int input_packet_process(Demuxer *d, AVPacket *pkt, 
unsigned *send_flags)
av_ts2str(pkt->pts), av_ts2timestr(pkt->pts, &pkt->time_base),
av_ts2str(pkt->dts), av_ts2timestr(pkt->dts, &pkt->time_base),
av_ts2str(pkt->duration), av_ts2timestr(pkt->duration, 
&pkt->time_base),
-   av_ts2str(input_files[ist->file_index]->ts_offset),
-  

[FFmpeg-devel] [PATCH 04/12] fftools/ffmpeg: move InputStream.discard to private data

[Anton Khirnov]

It is not used outside of ffmpeg_demux.
---
 fftools/ffmpeg.h   |  1 -
 fftools/ffmpeg_demux.c | 23 +++
 2 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 63e72e4fbc..0bab44cefc 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -339,7 +339,6 @@ typedef struct InputStream {
 int index;
 
 AVStream *st;
-int discard; /* true if stream data should be discarded */
 int user_set_discard;
 int decoding_needed; /* non zero if the packets must be decoded in 
'raw_fifo', see DECODING_FOR_* */
 #define DECODING_FOR_OST1
diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
index 61fb856106..9779580819 100644
--- a/fftools/ffmpeg_demux.c
+++ b/fftools/ffmpeg_demux.c
@@ -63,6 +63,9 @@ typedef struct DemuxStream {
 
 double ts_scale;
 
+/* true if stream data should be discarded */
+int discard;
+
 // scheduler returned EOF for this stream
 int finished;
 
@@ -136,7 +139,8 @@ static Demuxer *demuxer_from_ifile(InputFile *f)
 InputStream *ist_find_unused(enum AVMediaType type)
 {
 for (InputStream *ist = ist_iter(NULL); ist; ist = ist_iter(ist)) {
-if (ist->par->codec_type == type && ist->discard &&
+DemuxStream *ds = ds_from_ist(ist);
+if (ist->par->codec_type == type && ds->discard &&
 ist->user_set_discard != AVDISCARD_ALL)
 return ist;
 }
@@ -556,11 +560,14 @@ static void discard_unused_programs(InputFile *ifile)
 AVProgram *p = ifile->ctx->programs[j];
 int discard  = AVDISCARD_ALL;
 
-for (int k = 0; k < p->nb_stream_indexes; k++)
-if (!ifile->streams[p->stream_index[k]]->discard) {
+for (int k = 0; k < p->nb_stream_indexes; k++) {
+DemuxStream *ds = ds_from_ist(ifile->streams[p->stream_index[k]]);
+
+if (!ds->discard) {
 discard = AVDISCARD_DEFAULT;
 break;
 }
+}
 p->discard = discard;
 }
 }
@@ -637,7 +644,7 @@ static void *input_thread(void *arg)
dynamically in stream : we ignore them */
 ds = pkt->stream_index < f->nb_streams ?
  ds_from_ist(f->streams[pkt->stream_index]) : NULL;
-if (!ds || ds->ist.discard || ds->finished) {
+if (!ds || ds->discard || ds->finished) {
 report_new_stream(d, pkt);
 av_packet_unref(pkt);
 continue;
@@ -689,7 +696,7 @@ static void demux_final_stats(Demuxer *d)
 DemuxStream  *ds = ds_from_ist(ist);
 enum AVMediaType type = ist->par->codec_type;
 
-if (ist->discard || type == AVMEDIA_TYPE_ATTACHMENT)
+if (ds->discard || type == AVMEDIA_TYPE_ATTACHMENT)
 continue;
 
 total_size+= ds->data_size;
@@ -777,8 +784,8 @@ static int ist_use(InputStream *ist, int decoding_needed)
 ds->sch_idx_stream = ret;
 }
 
-if (ist->discard) {
-ist->discard = 0;
+if (ds->discard) {
+ds->discard = 0;
 d->nb_streams_used++;
 }
 
@@ -1024,7 +1031,7 @@ static int ist_add(const OptionsContext *o, Demuxer *d, 
AVStream *st)
 
 ist = &ds->ist;
 
-ist->discard = 1;
+ds->discard = 1;
 st->discard  = AVDISCARD_ALL;
 ds->first_dts   = AV_NOPTS_VALUE;
 ds->next_dts= AV_NOPTS_VALUE;
-- 
2.42.0

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

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

[FFmpeg-devel] [PATCH 01/12] fftools/ffmpeg_filter: move FilterGraph.graph to FilterGraphThread

[Anton Khirnov]

The AVFilterGraph is fully owned by the filtering thread and should
never be accessed outside of it.
---
 fftools/ffmpeg.h|   2 -
 fftools/ffmpeg_filter.c | 120 +---
 2 files changed, 64 insertions(+), 58 deletions(-)

diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index ba82b7490d..69bd23f576 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -322,8 +322,6 @@ typedef struct FilterGraph {
 const AVClass *class;
 intindex;
 
-AVFilterGraph *graph;
-
 InputFilter   **inputs;
 int  nb_inputs;
 OutputFilter **outputs;
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index ada235b084..3b0d457cc2 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -80,6 +80,8 @@ static const FilterGraphPriv *cfgp_from_cfg(const FilterGraph 
*fg)
 
 // data that is local to the filter thread and not visible outside of it
 typedef struct FilterGraphThread {
+AVFilterGraph *graph;
+
 AVFrame *frame;
 
 // Temporary buffer for output frames, since on filtergraph reset
@@ -850,7 +852,6 @@ void fg_free(FilterGraph **pfg)
 return;
 fgp = fgp_from_fg(fg);
 
-avfilter_graph_free(&fg->graph);
 for (int j = 0; j < fg->nb_inputs; j++) {
 InputFilter *ifilter = fg->inputs[j];
 InputFilterPriv *ifp = ifp_from_ifilter(ifilter);
@@ -1213,7 +1214,8 @@ static int insert_filter(AVFilterContext **last_filter, 
int *pad_idx,
 return 0;
 }
 
-static int configure_output_video_filter(FilterGraph *fg, OutputFilter 
*ofilter, AVFilterInOut *out)
+static int configure_output_video_filter(FilterGraph *fg, AVFilterGraph *graph,
+ OutputFilter *ofilter, AVFilterInOut 
*out)
 {
 OutputFilterPriv *ofp = ofp_from_ofilter(ofilter);
 OutputStream *ost = ofilter->ost;
@@ -1228,7 +1230,7 @@ static int configure_output_video_filter(FilterGraph *fg, 
OutputFilter *ofilter,
 snprintf(name, sizeof(name), "out_%d_%d", ost->file_index, ost->index);
 ret = avfilter_graph_create_filter(&ofp->filter,
avfilter_get_by_name("buffersink"),
-   name, NULL, NULL, fg->graph);
+   name, NULL, NULL, graph);
 
 if (ret < 0)
 return ret;
@@ -1248,7 +1250,7 @@ static int configure_output_video_filter(FilterGraph *fg, 
OutputFilter *ofilter,
 snprintf(name, sizeof(name), "scaler_out_%d_%d",
  ost->file_index, ost->index);
 if ((ret = avfilter_graph_create_filter(&filter, 
avfilter_get_by_name("scale"),
-name, args, NULL, fg->graph)) 
< 0)
+name, args, NULL, graph)) < 0)
 return ret;
 if ((ret = avfilter_link(last_filter, pad_idx, filter, 0)) < 0)
 return ret;
@@ -1267,7 +1269,7 @@ static int configure_output_video_filter(FilterGraph *fg, 
OutputFilter *ofilter,
 
 ret = avfilter_graph_create_filter(&filter,
avfilter_get_by_name("format"),
-   "format", pix_fmts, NULL, 
fg->graph);
+   "format", pix_fmts, NULL, graph);
 av_bprint_finalize(&bprint, NULL);
 if (ret < 0)
 return ret;
@@ -1292,7 +1294,8 @@ static int configure_output_video_filter(FilterGraph *fg, 
OutputFilter *ofilter,
 return 0;
 }
 
-static int configure_output_audio_filter(FilterGraph *fg, OutputFilter 
*ofilter, AVFilterInOut *out)
+static int configure_output_audio_filter(FilterGraph *fg, AVFilterGraph *graph,
+ OutputFilter *ofilter, AVFilterInOut 
*out)
 {
 OutputFilterPriv *ofp = ofp_from_ofilter(ofilter);
 OutputStream *ost = ofilter->ost;
@@ -1306,7 +1309,7 @@ static int configure_output_audio_filter(FilterGraph *fg, 
OutputFilter *ofilter,
 snprintf(name, sizeof(name), "out_%d_%d", ost->file_index, ost->index);
 ret = avfilter_graph_create_filter(&ofp->filter,
avfilter_get_by_name("abuffersink"),
-   name, NULL, NULL, fg->graph);
+   name, NULL, NULL, graph);
 if (ret < 0)
 return ret;
 if ((ret = av_opt_set_int(ofp->filter, "all_channel_counts", 1, 
AV_OPT_SEARCH_CHILDREN)) < 0)
@@ -1320,7 +1323,7 @@ static int configure_output_audio_filter(FilterGraph *fg, 
OutputFilter *ofilter,
 \
 ret = avfilter_graph_create_filter(&filt_ctx,   \
avfilter_get_by_name(filter_name),   \
-   filter_name, arg, NULL, fg->graph);  \
+   filter_name, arg, NULL, graph);

[FFmpeg-devel] [PATCH 03/12] fftools/ffmpeg: replace OutputStream.file_index by a pointer

[Anton Khirnov]

Reduces the need to use the output_files global array.
---
 fftools/ffmpeg.c  | 12 ++--
 fftools/ffmpeg.h  |  4 +++-
 fftools/ffmpeg_enc.c  | 21 +++--
 fftools/ffmpeg_filter.c   | 22 +++---
 fftools/ffmpeg_mux.c  | 11 +--
 fftools/ffmpeg_mux_init.c | 12 ++--
 6 files changed, 42 insertions(+), 40 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 3aab302c27..8077248254 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -374,7 +374,7 @@ static void ffmpeg_cleanup(int ret)
 
 OutputStream *ost_iter(OutputStream *prev)
 {
-int of_idx  = prev ? prev->file_index : 0;
+int of_idx  = prev ? prev->file->index : 0;
 int ost_idx = prev ? prev->index + 1  : 0;
 
 for (; of_idx < nb_output_files; of_idx++) {
@@ -515,7 +515,7 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 if (vid && ost->type == AVMEDIA_TYPE_VIDEO) {
 av_bprintf(&buf, "q=%2.1f ", q);
 av_bprintf(&buf_script, "stream_%d_%d_q=%.1f\n",
-   ost->file_index, ost->index, q);
+   ost->file->index, ost->index, q);
 }
 if (!vid && ost->type == AVMEDIA_TYPE_VIDEO && ost->filter) {
 float fps;
@@ -527,7 +527,7 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 av_bprintf(&buf_script, "frame=%"PRId64"\n", frame_number);
 av_bprintf(&buf_script, "fps=%.2f\n", fps);
 av_bprintf(&buf_script, "stream_%d_%d_q=%.1f\n",
-   ost->file_index, ost->index, q);
+   ost->file->index, ost->index, q);
 if (is_last_report)
 av_bprintf(&buf, "L");
 
@@ -765,7 +765,7 @@ static void print_stream_maps(void)
 if (ost->attachment_filename) {
 /* an attached file */
 av_log(NULL, AV_LOG_INFO, "  File %s -> Stream #%d:%d\n",
-   ost->attachment_filename, ost->file_index, ost->index);
+   ost->attachment_filename, ost->file->index, ost->index);
 continue;
 }
 
@@ -775,7 +775,7 @@ static void print_stream_maps(void)
 if (nb_filtergraphs > 1)
 av_log(NULL, AV_LOG_INFO, " (graph %d)", 
ost->filter->graph->index);
 
-av_log(NULL, AV_LOG_INFO, " -> Stream #%d:%d (%s)\n", 
ost->file_index,
+av_log(NULL, AV_LOG_INFO, " -> Stream #%d:%d (%s)\n", 
ost->file->index,
ost->index, ost->enc_ctx->codec->name);
 continue;
 }
@@ -783,7 +783,7 @@ static void print_stream_maps(void)
 av_log(NULL, AV_LOG_INFO, "  Stream #%d:%d -> #%d:%d",
ost->ist->file->index,
ost->ist->index,
-   ost->file_index,
+   ost->file->index,
ost->index);
 if (ost->enc_ctx) {
 const AVCodec *in_codec= ost->ist->dec;
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index d7b6e689fc..63e72e4fbc 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -514,7 +514,9 @@ typedef struct OutputStream {
 
 enum AVMediaType type;
 
-int file_index;  /* file index */
+/* parent muxer */
+struct OutputFile *file;
+
 int index;   /* stream index in the output file */
 
 /**
diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
index 320df2dee7..9b013af2fe 100644
--- a/fftools/ffmpeg_enc.c
+++ b/fftools/ffmpeg_enc.c
@@ -172,7 +172,7 @@ int enc_open(void *opaque, const AVFrame *frame)
 AVCodecContext *enc_ctx = ost->enc_ctx;
 AVCodecContext *dec_ctx = NULL;
 const AVCodec  *enc = enc_ctx->codec;
-OutputFile  *of = output_files[ost->file_index];
+OutputFile  *of = ost->file;
 FrameData *fd;
 int frame_samples = 0;
 int ret;
@@ -188,7 +188,7 @@ int enc_open(void *opaque, const AVFrame *frame)
 fd = (FrameData*)frame->opaque_ref->data;
 }
 
-ret = set_encoder_id(output_files[ost->file_index], ost);
+ret = set_encoder_id(of, ost);
 if (ret < 0)
 return ret;
 
@@ -374,7 +374,7 @@ int enc_open(void *opaque, const AVFrame *frame)
 
 static int check_recording_time(OutputStream *ost, int64_t ts, AVRational tb)
 {
-OutputFile *of = output_files[ost->file_index];
+OutputFile *of = ost->file;
 
 if (of->recording_time != INT64_MAX &&
 av_compare_ts(ts, tb, of->recording_time, AV_TIME_BASE_Q) >= 0) {
@@ -413,8 +413,8 @@ static int do_subtitle_out(OutputFile *of, OutputStream 
*ost, const AVSubtitle *
 
 /* shift timestamp to honor -ss and make check_recording_time() work with 
-t */
 pts = sub->pts;
-if (output_files[ost->file_index]->start_time != AV_NOPTS_VALUE)
-pts -= output_files[ost->file_index]->start_time;
+if (of->start_time != AV_NOPTS_VALUE)
+pts -= of->start_time;
 for (i = 0; i < nb; i++) {
 AV

[FFmpeg-devel] [PATCH 11/12] fftools/ffmpeg: update the reported timestamp at the end

[Anton Khirnov]

Reported-by: microchip
---
 fftools/ffmpeg.c   |  2 +-
 fftools/ffmpeg_sched.c | 13 -
 fftools/ffmpeg_sched.h |  2 +-
 3 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 8077248254..4c706eb46a 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -926,7 +926,7 @@ static int transcode(Scheduler *sch)
 print_report(0, timer_start, cur_time, transcode_ts);
 }
 
-ret = sch_stop(sch);
+ret = sch_stop(sch, &transcode_ts);
 
 /* write the trailer if needed */
 for (i = 0; i < nb_output_files; i++) {
diff --git a/fftools/ffmpeg_sched.c b/fftools/ffmpeg_sched.c
index ab14d6233e..b1c7db776e 100644
--- a/fftools/ffmpeg_sched.c
+++ b/fftools/ffmpeg_sched.c
@@ -423,7 +423,7 @@ static void task_init(Scheduler *sch, SchTask *task, enum 
SchedulerNodeType type
 task->func_arg  = func_arg;
 }
 
-static int64_t trailing_dts(const Scheduler *sch)
+static int64_t trailing_dts(const Scheduler *sch, int count_finished)
 {
 int64_t min_dts = INT64_MAX;
 
@@ -433,7 +433,7 @@ static int64_t trailing_dts(const Scheduler *sch)
 for (unsigned j = 0; j < mux->nb_streams; j++) {
 const SchMuxStream *ms = &mux->streams[j];
 
-if (ms->source_finished)
+if (ms->source_finished && !count_finished)
 continue;
 if (ms->last_dts == AV_NOPTS_VALUE)
 return AV_NOPTS_VALUE;
@@ -445,7 +445,7 @@ static int64_t trailing_dts(const Scheduler *sch)
 return min_dts == INT64_MAX ? AV_NOPTS_VALUE : min_dts;
 }
 
-int sch_stop(Scheduler *sch)
+int sch_stop(Scheduler *sch, int64_t *finish_ts)
 {
 int ret = 0, err;
 
@@ -492,6 +492,9 @@ int sch_stop(Scheduler *sch)
 ret = err_merge(ret, err);
 }
 
+if (finish_ts)
+*finish_ts = trailing_dts(sch, 1);
+
 return ret;
 }
 
@@ -502,7 +505,7 @@ void sch_free(Scheduler **psch)
 if (!sch)
 return;
 
-sch_stop(sch);
+sch_stop(sch, NULL);
 
 for (unsigned i = 0; i < sch->nb_demux; i++) {
 SchDemux *d = &sch->demux[i];
@@ -1194,7 +1197,7 @@ static void schedule_update_locked(Scheduler *sch)
 if (atomic_load(&sch->terminate))
 return;
 
-dts = trailing_dts(sch);
+dts = trailing_dts(sch, 0);
 
 atomic_store(&sch->last_dts, dts);
 
diff --git a/fftools/ffmpeg_sched.h b/fftools/ffmpeg_sched.h
index 94bbd30e98..b167d8d158 100644
--- a/fftools/ffmpeg_sched.h
+++ b/fftools/ffmpeg_sched.h
@@ -127,7 +127,7 @@ Scheduler *sch_alloc(void);
 void sch_free(Scheduler **sch);
 
 int sch_start(Scheduler *sch);
-int sch_stop(Scheduler *sch);
+int sch_stop(Scheduler *sch, int64_t *finish_ts);
 
 /**
  * Wait until transcoding terminates or the specified timeout elapses.
-- 
2.42.0

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

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

[FFmpeg-devel] [PATCH 12/12] fftools/ffmpeg_sched: track dts+duration as last_dts

[Anton Khirnov]

This should be slightly (probably negligibly) more accurate for
scheduling, but mainly it improves the final reported time.

Reported-by: Paul B Mahol
---
 fftools/ffmpeg_sched.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fftools/ffmpeg_sched.c b/fftools/ffmpeg_sched.c
index b1c7db776e..263b0094ca 100644
--- a/fftools/ffmpeg_sched.c
+++ b/fftools/ffmpeg_sched.c
@@ -192,7 +192,7 @@ typedef struct SchMuxStream {
 
 // The following are protected by Scheduler.schedule_lock //
 
-/* dts of the last packet sent to this stream
+/* dts+duration of the last packet sent to this stream
in AV_TIME_BASE_Q */
 int64_t last_dts;
 // this stream no longer accepts input
@@ -1619,8 +1619,8 @@ static int send_to_mux(Scheduler *sch, SchMux *mux, 
unsigned stream_idx,
AVPacket *pkt)
 {
 SchMuxStream *ms = &mux->streams[stream_idx];
-int64_t dts = (pkt && pkt->dts != AV_NOPTS_VALUE)?
-  av_rescale_q(pkt->dts, pkt->time_base, AV_TIME_BASE_Q) :
+int64_t dts = (pkt && pkt->dts != AV_NOPTS_VALUE)  
  ?
+  av_rescale_q(pkt->dts + pkt->duration, pkt->time_base, 
AV_TIME_BASE_Q) :
   AV_NOPTS_VALUE;
 
 // queue the packet if the muxer cannot be started yet
-- 
2.42.0

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

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

[FFmpeg-devel] [PATCH 05/12] fftools/ffmpeg: move InputStream.codec_desc to private data

[Anton Khirnov]

It is not used outside of ffmpeg_demux.
---
 fftools/ffmpeg.h   | 1 -
 fftools/ffmpeg_demux.c | 8 +---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 0bab44cefc..f214e4efcb 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -353,7 +353,6 @@ typedef struct InputStream {
 Decoder *decoder;
 AVCodecContext *dec_ctx;
 const AVCodec *dec;
-const AVCodecDescriptor *codec_desc;
 
 AVRational framerate_guessed;
 
diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
index 9779580819..865c1e7d2f 100644
--- a/fftools/ffmpeg_demux.c
+++ b/fftools/ffmpeg_demux.c
@@ -83,6 +83,8 @@ typedef struct DemuxStream {
 ///< dts of the last packet read for this stream (in AV_TIME_BASE units)
 int64_t   dts;
 
+const AVCodecDescriptor *codec_desc;
+
 /* number of packets successfully read for this stream */
 uint64_t nb_packets;
 // combined size of all the packets read
@@ -320,8 +322,8 @@ static int ist_dts_update(DemuxStream *ds, AVPacket *pkt)
  (AVRational){ 2, 1 });
 int fields = 2;
 
-if (ist->codec_desc &&
-(ist->codec_desc->props & AV_CODEC_PROP_FIELDS) &&
+if (ds->codec_desc &&
+(ds->codec_desc->props & AV_CODEC_PROP_FIELDS) &&
 av_stream_get_parser(ist->st))
 fields = 1 + av_stream_get_parser(ist->st)->repeat_pict;
 
@@ -1252,7 +1254,7 @@ static int ist_add(const OptionsContext *o, Demuxer *d, 
AVStream *st)
 return ret;
 }
 
-ist->codec_desc = avcodec_descriptor_get(ist->par->codec_id);
+ds->codec_desc = avcodec_descriptor_get(ist->par->codec_id);
 
 return 0;
 }
-- 
2.42.0

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

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

[FFmpeg-devel] [PATCH 10/12] fftools/ffmpeg_sched: move trailing_dts() higher up

[Anton Khirnov]

Will be useful in following commit.
---
 fftools/ffmpeg_sched.c | 44 +-
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/fftools/ffmpeg_sched.c b/fftools/ffmpeg_sched.c
index 69f8c0c3c0..ab14d6233e 100644
--- a/fftools/ffmpeg_sched.c
+++ b/fftools/ffmpeg_sched.c
@@ -423,6 +423,28 @@ static void task_init(Scheduler *sch, SchTask *task, enum 
SchedulerNodeType type
 task->func_arg  = func_arg;
 }
 
+static int64_t trailing_dts(const Scheduler *sch)
+{
+int64_t min_dts = INT64_MAX;
+
+for (unsigned i = 0; i < sch->nb_mux; i++) {
+const SchMux *mux = &sch->mux[i];
+
+for (unsigned j = 0; j < mux->nb_streams; j++) {
+const SchMuxStream *ms = &mux->streams[j];
+
+if (ms->source_finished)
+continue;
+if (ms->last_dts == AV_NOPTS_VALUE)
+return AV_NOPTS_VALUE;
+
+min_dts = FFMIN(min_dts, ms->last_dts);
+}
+}
+
+return min_dts == INT64_MAX ? AV_NOPTS_VALUE : min_dts;
+}
+
 int sch_stop(Scheduler *sch)
 {
 int ret = 0, err;
@@ -1162,28 +1184,6 @@ int sch_mux_sub_heartbeat_add(Scheduler *sch, unsigned 
mux_idx, unsigned stream_
 return 0;
 }
 
-static int64_t trailing_dts(const Scheduler *sch)
-{
-int64_t min_dts = INT64_MAX;
-
-for (unsigned i = 0; i < sch->nb_mux; i++) {
-const SchMux *mux = &sch->mux[i];
-
-for (unsigned j = 0; j < mux->nb_streams; j++) {
-const SchMuxStream *ms = &mux->streams[j];
-
-if (ms->source_finished)
-continue;
-if (ms->last_dts == AV_NOPTS_VALUE)
-return AV_NOPTS_VALUE;
-
-min_dts = FFMIN(min_dts, ms->last_dts);
-}
-}
-
-return min_dts == INT64_MAX ? AV_NOPTS_VALUE : min_dts;
-}
-
 static void schedule_update_locked(Scheduler *sch)
 {
 int64_t dts;
-- 
2.42.0

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

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

[FFmpeg-devel] [PATCH 06/12] fftools/ffmpeg: drop unused InputFile.eof_reached

[Anton Khirnov]

---
 fftools/ffmpeg.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index f214e4efcb..3db3d87dfe 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -407,7 +407,6 @@ typedef struct InputFile {
 int format_nots;
 
 AVFormatContext *ctx;
-int eof_reached;  /* true if eof reached */
 int64_t input_ts_offset;
 int input_sync_ref;
 /**
-- 
2.42.0

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

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

[FFmpeg-devel] [PATCH 07/12] fftools/ffmpeg_demux: move InputFile.readrate to private data

[Anton Khirnov]

It is not used outside of ffmpeg_demux.
---
 fftools/ffmpeg.h   |  1 -
 fftools/ffmpeg_demux.c | 19 ++-
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 3db3d87dfe..2963d2d5d4 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -423,7 +423,6 @@ typedef struct InputFile {
 InputStream **streams;
 intnb_streams;
 
-float readrate;
 int accurate_seek;
 } InputFile;
 
diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
index 865c1e7d2f..f9c71f5b9a 100644
--- a/fftools/ffmpeg_demux.c
+++ b/fftools/ffmpeg_demux.c
@@ -117,6 +117,7 @@ typedef struct Demuxer {
 /* number of streams that the user was warned of */
 int nb_streams_warn;
 
+float  readrate;
 double readrate_initial_burst;
 
 Scheduler*sch;
@@ -491,7 +492,7 @@ static void readrate_sleep(Demuxer *d)
 int64_t stream_ts_offset, pts, now;
 stream_ts_offset = FFMAX(ds->first_dts != AV_NOPTS_VALUE ? 
ds->first_dts : 0, file_start);
 pts = av_rescale(ds->dts, 100, AV_TIME_BASE);
-now = (av_gettime_relative() - d->wallclock_start) * f->readrate + 
stream_ts_offset;
+now = (av_gettime_relative() - d->wallclock_start) * d->readrate + 
stream_ts_offset;
 if (pts - burst_until > now)
 av_usleep(pts - burst_until - now);
 }
@@ -667,7 +668,7 @@ static void *input_thread(void *arg)
 if (ret < 0)
 break;
 
-if (f->readrate)
+if (d->readrate)
 readrate_sleep(d);
 
 ret = demux_send(d, ds, pkt, send_flags);
@@ -1582,19 +1583,19 @@ int ifile_open(const OptionsContext *o, const char 
*filename, Scheduler *sch)
 
 f->format_nots = !!(ic->iformat->flags & AVFMT_NOTIMESTAMPS);
 
-f->readrate = o->readrate ? o->readrate : 0.0;
-if (f->readrate < 0.0f) {
-av_log(d, AV_LOG_ERROR, "Option -readrate is %0.3f; it must be 
non-negative.\n", f->readrate);
+d->readrate = o->readrate ? o->readrate : 0.0;
+if (d->readrate < 0.0f) {
+av_log(d, AV_LOG_ERROR, "Option -readrate is %0.3f; it must be 
non-negative.\n", d->readrate);
 return AVERROR(EINVAL);
 }
 if (o->rate_emu) {
-if (f->readrate) {
-av_log(d, AV_LOG_WARNING, "Both -readrate and -re set. Using 
-readrate %0.3f.\n", f->readrate);
+if (d->readrate) {
+av_log(d, AV_LOG_WARNING, "Both -readrate and -re set. Using 
-readrate %0.3f.\n", d->readrate);
 } else
-f->readrate = 1.0f;
+d->readrate = 1.0f;
 }
 
-if (f->readrate) {
+if (d->readrate) {
 d->readrate_initial_burst = o->readrate_initial_burst ? 
o->readrate_initial_burst : 0.5;
 if (d->readrate_initial_burst < 0.0) {
 av_log(d, AV_LOG_ERROR,
-- 
2.42.0

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

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

[FFmpeg-devel] [PATCH 08/12] fftools/ffmpeg_mux: move OutputStream.sq_idx_mux to private data

[Anton Khirnov]

It should not be accessed outside of ffmpeg_mux*
---
 fftools/ffmpeg.h  |  2 --
 fftools/ffmpeg_mux.c  | 12 ++--
 fftools/ffmpeg_mux.h  |  2 ++
 fftools/ffmpeg_mux_init.c | 12 ++--
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 2963d2d5d4..5c061ef0f4 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -586,8 +586,6 @@ typedef struct OutputStream {
 /* packet quality factor */
 atomic_int quality;
 
-int sq_idx_mux;
-
 EncStats enc_stats_pre;
 EncStats enc_stats_post;
 
diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
index fdedc550e1..06db55a6d4 100644
--- a/fftools/ffmpeg_mux.c
+++ b/fftools/ffmpeg_mux.c
@@ -168,12 +168,12 @@ fail:
 return ret;
 }
 
-static int sync_queue_process(Muxer *mux, OutputStream *ost, AVPacket *pkt, 
int *stream_eof)
+static int sync_queue_process(Muxer *mux, MuxStream *ms, AVPacket *pkt, int 
*stream_eof)
 {
 OutputFile *of = &mux->of;
 
-if (ost->sq_idx_mux >= 0) {
-int ret = sq_send(mux->sq_mux, ost->sq_idx_mux, SQPKT(pkt));
+if (ms->sq_idx_mux >= 0) {
+int ret = sq_send(mux->sq_mux, ms->sq_idx_mux, SQPKT(pkt));
 if (ret < 0) {
 if (ret == AVERROR_EOF)
 *stream_eof = 1;
@@ -198,7 +198,7 @@ static int sync_queue_process(Muxer *mux, OutputStream 
*ost, AVPacket *pkt, int
 return ret;
 }
 } else if (pkt)
-return write_packet(mux, ost, pkt);
+return write_packet(mux, &ms->ost, pkt);
 
 return 0;
 }
@@ -268,14 +268,14 @@ static int mux_packet_filter(Muxer *mux, MuxThreadContext 
*mt,
 if (!bsf_eof)
 ms->bsf_pkt->time_base = ms->bsf_ctx->time_base_out;
 
-ret = sync_queue_process(mux, ost, bsf_eof ? NULL : ms->bsf_pkt, 
stream_eof);
+ret = sync_queue_process(mux, ms, bsf_eof ? NULL : ms->bsf_pkt, 
stream_eof);
 if (ret < 0)
 goto mux_fail;
 }
 *stream_eof = 1;
 return AVERROR_EOF;
 } else {
-ret = sync_queue_process(mux, ost, pkt, stream_eof);
+ret = sync_queue_process(mux, ms, pkt, stream_eof);
 if (ret < 0)
 goto mux_fail;
 }
diff --git a/fftools/ffmpeg_mux.h b/fftools/ffmpeg_mux.h
index 5d7cf3fa76..d0be8a51ea 100644
--- a/fftools/ffmpeg_mux.h
+++ b/fftools/ffmpeg_mux.h
@@ -50,6 +50,8 @@ typedef struct MuxStream {
 int sch_idx_enc;
 int sch_idx_src;
 
+int sq_idx_mux;
+
 int64_t max_frames;
 
 // timestamp from which the streamcopied streams should start,
diff --git a/fftools/ffmpeg_mux_init.c b/fftools/ffmpeg_mux_init.c
index 455876d456..f527a083db 100644
--- a/fftools/ffmpeg_mux_init.c
+++ b/fftools/ffmpeg_mux_init.c
@@ -1923,7 +1923,7 @@ static int setup_sync_queues(Muxer *mux, AVFormatContext 
*oc, int64_t buf_size_u
 MuxStream *ms = ms_from_ost(ost);
 enum AVMediaType type = ost->type;
 
-ost->sq_idx_mux= -1;
+ms->sq_idx_mux  = -1;
 
 nb_interleaved += IS_INTERLEAVED(type);
 nb_av_enc  += IS_AV_ENC(ost, type);
@@ -1992,13 +1992,13 @@ static int setup_sync_queues(Muxer *mux, 
AVFormatContext *oc, int64_t buf_size_u
 if (!IS_INTERLEAVED(type))
 continue;
 
-ost->sq_idx_mux = sq_add_stream(mux->sq_mux,
-of->shortest || ms->max_frames < 
INT64_MAX);
-if (ost->sq_idx_mux < 0)
-return ost->sq_idx_mux;
+ms->sq_idx_mux = sq_add_stream(mux->sq_mux,
+   of->shortest || ms->max_frames < 
INT64_MAX);
+if (ms->sq_idx_mux < 0)
+return ms->sq_idx_mux;
 
 if (ms->max_frames != INT64_MAX)
-sq_limit_frames(mux->sq_mux, ost->sq_idx_mux, ms->max_frames);
+sq_limit_frames(mux->sq_mux, ms->sq_idx_mux, ms->max_frames);
 }
 }
 
-- 
2.42.0

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

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

[FFmpeg-devel] [PATCH 09/12] fftools/ffmpeg: drop OutputFile.sq_encode

[Anton Khirnov]

It is unused since d119ae2fd82a494d9430ff4d4fc262961a68c598
---
 fftools/ffmpeg.h | 2 --
 fftools/ffmpeg_mux.c | 1 -
 2 files changed, 3 deletions(-)

diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 5c061ef0f4..b7ec6085d3 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -607,8 +607,6 @@ typedef struct OutputFile {
 OutputStream **streams;
 int nb_streams;
 
-SyncQueue *sq_encode;
-
 int64_t recording_time;  ///< desired length of the resulting file in 
microseconds == AV_TIME_BASE units
 int64_t start_time;  ///< start time in microseconds == AV_TIME_BASE 
units
 
diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
index 06db55a6d4..383ca4ecef 100644
--- a/fftools/ffmpeg_mux.c
+++ b/fftools/ffmpeg_mux.c
@@ -777,7 +777,6 @@ void of_free(OutputFile **pof)
 return;
 mux = mux_from_of(of);
 
-sq_free(&of->sq_encode);
 sq_free(&mux->sq_mux);
 
 for (int i = 0; i < of->nb_streams; i++)
-- 
2.42.0

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

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

[FFmpeg-devel] [PATCH] avcodec/bitpacked_dec: optimize bitpacked_decode_yuv422p10

[Marton Balint]

From: Devin Heitmueller 

Rework the code a bit to speed up the 10-bit bitpacked decoding
routine.  This is probably about as fast as I can get it without
switching to assembly language.

Demonstratable with:

./ffmpeg -f lavfi -i "smptehdbars=size=3840x2160" -c bitpacked -f image2 
-frames:v 1 source.yuv
./ffmpeg -f bitpacked -pix_fmt yuv422p10le -s 3840x2160 -c:v bitpacked -i 
source.yuv -pix_fmt yuv422p10le out.yuv

On my development system, it went from 80ms for a 2160p frame
down to 20ms (i.e. a 4X speedup).  Good enough for now, I hope...

Comments from Marton:

Originally on my system better performance could be achieved by simply
switching to the cached bitstream reader, but for Devin it was slower than
his direct byte operations.

I changed the order of writing output from u/y/v/y to u/v/y/y, and that made
the code faster than the cached bitstream reader on my system as well.

TIMER measurement of the decode loop on Ryzen 5 3600 with command line:

./ffmpeg -stream_loop 256 -threads 1 -f bitpacked -pix_fmt yuv422p10le -s 
3840x2160 -c:v bitpacked -i source.yuv -pix_fmt yuv422p10le -f null none 
-loglevel error

Before: 823204127 decicycles in YUV, 256 runs,  0 skips
After:  315070524 decicycles in YUV, 256 runs,  0 skips

Signed-off-by: Devin Heitmueller 
Signed-off-by: Marton Balint 
---
 libavcodec/bitpacked_dec.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/libavcodec/bitpacked_dec.c b/libavcodec/bitpacked_dec.c
index c88f861993..54c008bd86 100644
--- a/libavcodec/bitpacked_dec.c
+++ b/libavcodec/bitpacked_dec.c
@@ -28,7 +28,6 @@
 
 #include "avcodec.h"
 #include "codec_internal.h"
-#include "get_bits.h"
 #include "libavutil/imgutils.h"
 #include "thread.h"
 
@@ -65,7 +64,7 @@ static int bitpacked_decode_yuv422p10(AVCodecContext *avctx, 
AVFrame *frame,
 {
 uint64_t frame_size = (uint64_t)avctx->width * (uint64_t)avctx->height * 
20;
 uint64_t packet_size = (uint64_t)avpkt->size * 8;
-GetBitContext bc;
+uint8_t *src;
 uint16_t *y, *u, *v;
 int ret, i, j;
 
@@ -79,20 +78,18 @@ static int bitpacked_decode_yuv422p10(AVCodecContext 
*avctx, AVFrame *frame,
 if (avctx->width % 2)
 return AVERROR_PATCHWELCOME;
 
-ret = init_get_bits(&bc, avpkt->data, avctx->width * avctx->height * 20);
-if (ret)
-return ret;
-
+src = avpkt->data;
 for (i = 0; i < avctx->height; i++) {
 y = (uint16_t*)(frame->data[0] + i * frame->linesize[0]);
 u = (uint16_t*)(frame->data[1] + i * frame->linesize[1]);
 v = (uint16_t*)(frame->data[2] + i * frame->linesize[2]);
 
 for (j = 0; j < avctx->width; j += 2) {
-*u++ = get_bits(&bc, 10);
-*y++ = get_bits(&bc, 10);
-*v++ = get_bits(&bc, 10);
-*y++ = get_bits(&bc, 10);
+*u++ = (src[0] << 2) | (src[1] >> 6);
+*v++ = ((src[2] << 6) | (src[3] >> 2)) & 0x3ff;
+*y++ = ((src[1] << 4) | (src[2] >> 4)) & 0x3ff;
+*y++ = ((src[3] << 8) | (src[4]))  & 0x3ff;
+src += 5;
 }
 }
 
-- 
2.35.3

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

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

Re: [FFmpeg-devel] [PATCH] [WIP] [RFC] dvdvideo: initial contribution (DVD demuxer)

[Nicolas George]

Marth64 (12023-12-09):
> I am hoping and willing to improve this to be a robust demuxer
> wherever possible, but to that extent there is still an issue I can't
> figure out how to solve: Dealing with DTS discontinuities and PTS
> generation.

The dvd2concat script manages it by shifting the times of the segments
defined in the index. You can probably do the same.

Interesting work, thanks.

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] fate: Allow running multiple rounds of tests with differing settings

[Martin Storsjö]

On Wed, 13 Dec 2023, Rémi Denis-Courmont wrote:


Le tiistaina 12. joulukuuta 2023, 0.14.06 EET Martin Storsjö a écrit :

This can be used to run tests multple times, with e.g. differing
QEMU settings, by adding something like this to the FATE configuration
file:

target_exec="qemu-aarch64-static"
fate_targets="fate-checkasm fate-cpu"

fate_environments="sve128 sve256 sve512"
sve128_env="QEMU_CPU=max,sve128=on"
sve256_env="QEMU_CPU=max,sve256=on"
sve512_env="QEMU_CPU=max,sve512=on"


I'm fine with that, but for the sake of generality, shouldn't rather the 
entire target_exec prefix be indirected? Some runners may want to use 
command line flags rather than environment variables.


Yes - that's also doable. One can e.g. do this:

---
target_exec="qemu-aarch64-static -cpu \$(MY_CPU)"
fate_targets="fate-checkasm fate-cpu"

fate_environments="sve128 sve256 sve512"
sve128_env="MY_CPU=max,sve128=on"
sve256_env="MY_CPU=max,sve256=on"
sve512_env="MY_CPU=max,sve512=on"
---

That way, one can also make the whole target_exec be e.g. \$(EXEC_CMD) and 
set the full command via the individual envs. It's not quite as 
comfortable, but should be doable and allow fully generic setups.


(One could also consider just doing feat1_env="TARGET_EXEC=..." and not 
setting target_exec in the fate config at all - however that's probably 
not a good option and it has one surprising gotcha. The makefile level 
TARGET_EXEC variable needs to have a trailing space when it is set to a 
nonempty value, and injecting that might be annoying or ugly.)


// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@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/1] avcodec/libjxlenc: Add libjxl_animated encoder

[Zsolt Vadász via ffmpeg-devel]

This patchset adds support for encoding animated JPEG XL images via a
new encoder (libjxl_animated). When using the encoder, the output format
needs to be set to raw video, as shown below:
`ffmpeg -i sample.gif -c:v libjxl_animated -f rawvideo out.jxl`

V2 changes:
- This version doesn't move the JxlBasicInfo struct into
LibJxlEncodeContext (the JxlPixelFormat struct is still in the encoder context 
because
it's used in multiple functions, while the encode callbacks only use
the `ysize` from the JxlBasicInfo, which is just `frame-height`)
- It also doesn't overwrite `avctx->time_base`
- Builds that disable libjxl now succeed

Zsolt Vadasz (1):
  avcodec/libjxlenc: Add libjxl_animated encoder

 configure  |   1 +
 libavcodec/allcodecs.c |   1 +
 libavcodec/libjxlenc.c | 214 +
 3 files changed, 177 insertions(+), 39 deletions(-)

-- 
2.43.0

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

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

[FFmpeg-devel] [PATCH v2 1/1] avcodec/libjxlenc: Add libjxl_animated encoder

[Zsolt Vadász via ffmpeg-devel]

---
 configure  |   1 +
 libavcodec/allcodecs.c |   1 +
 libavcodec/libjxlenc.c | 214 +
 3 files changed, 177 insertions(+), 39 deletions(-)

diff --git a/configure b/configure
index 7d2ee66000..a334a9b1e0 100755
--- a/configure
+++ b/configure
@@ -3418,6 +3418,7 @@ libilbc_decoder_deps="libilbc"
 libilbc_encoder_deps="libilbc"
 libjxl_decoder_deps="libjxl libjxl_threads"
 libjxl_encoder_deps="libjxl libjxl_threads"
+libjxl_animated_encoder_deps="libjxl libjxl_threads"
 libkvazaar_encoder_deps="libkvazaar"
 libmodplug_demuxer_deps="libmodplug"
 libmp3lame_encoder_deps="libmp3lame"
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index b0f004e15c..e6733b0d4f 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -784,6 +784,7 @@ extern const FFCodec ff_libilbc_encoder;
 extern const FFCodec ff_libilbc_decoder;
 extern const FFCodec ff_libjxl_decoder;
 extern const FFCodec ff_libjxl_encoder;
+extern const FFCodec ff_libjxl_animated_encoder;
 extern const FFCodec ff_libmp3lame_encoder;
 extern const FFCodec ff_libopencore_amrnb_encoder;
 extern const FFCodec ff_libopencore_amrnb_decoder;
diff --git a/libavcodec/libjxlenc.c b/libavcodec/libjxlenc.c
index d707f3a61b..bf44307a34 100644
--- a/libavcodec/libjxlenc.c
+++ b/libavcodec/libjxlenc.c
@@ -39,6 +39,7 @@
 #include "avcodec.h"
 #include "encode.h"
 #include "codec_internal.h"
+#include "internal.h"
 
 #include 
 #include 
@@ -49,11 +50,15 @@ typedef struct LibJxlEncodeContext {
 void *runner;
 JxlEncoder *encoder;
 JxlEncoderFrameSettings *options;
+JxlPixelFormat jxl_fmt;
 int effort;
 float distance;
 int modular;
 uint8_t *buffer;
 size_t buffer_size;
+/* Only used by libjxl_animated */
+int animated;
+AVFrame *last;
 } LibJxlEncodeContext;
 
 /**
@@ -183,6 +188,8 @@ static av_cold int libjxl_encode_init(AVCodecContext *avctx)
 return AVERROR(ENOMEM);
 }
 
+ctx->animated = 0;
+
 return 0;
 }
 
@@ -237,28 +244,19 @@ static int libjxl_populate_primaries(void *avctx, 
JxlColorEncoding *jxl_color, e
 return 0;
 }
 
-/**
- * Encode an entire frame. Currently animation, is not supported by
- * this encoder, so this will always reinitialize a new still image
- * and encode a one-frame image (for image2 and image2pipe).
- */
-static int libjxl_encode_frame(AVCodecContext *avctx, AVPacket *pkt, const 
AVFrame *frame, int *got_packet)
+static int libjxl_encode_init_image(AVCodecContext *avctx, const AVFrame 
*frame)
 {
 LibJxlEncodeContext *ctx = avctx->priv_data;
 AVFrameSideData *sd;
 const AVPixFmtDescriptor *pix_desc = av_pix_fmt_desc_get(frame->format);
 JxlBasicInfo info;
 JxlColorEncoding jxl_color;
-JxlPixelFormat jxl_fmt;
+JxlPixelFormat *jxl_fmt = &ctx->jxl_fmt;
 int bits_per_sample;
 #if JPEGXL_NUMERIC_VERSION >= JPEGXL_COMPUTE_NUMERIC_VERSION(0, 8, 0)
 JxlBitDepth jxl_bit_depth;
 #endif
-JxlEncoderStatus jret;
 int ret;
-size_t available = ctx->buffer_size;
-size_t bytes_written = 0;
-uint8_t *next_out = ctx->buffer;
 
 ret = libjxl_init_jxl_encoder(avctx);
 if (ret) {
@@ -268,23 +266,30 @@ static int libjxl_encode_frame(AVCodecContext *avctx, 
AVPacket *pkt, const AVFra
 
 /* populate the basic info settings */
 JxlEncoderInitBasicInfo(&info);
-jxl_fmt.num_channels = pix_desc->nb_components;
+jxl_fmt->num_channels = pix_desc->nb_components;
 info.xsize = frame->width;
 info.ysize = frame->height;
-info.num_extra_channels = (jxl_fmt.num_channels + 1) % 2;
-info.num_color_channels = jxl_fmt.num_channels - info.num_extra_channels;
-bits_per_sample = av_get_bits_per_pixel(pix_desc) / jxl_fmt.num_channels;
+info.num_extra_channels = (jxl_fmt->num_channels + 1) % 2;
+info.num_color_channels = jxl_fmt->num_channels - info.num_extra_channels;
+bits_per_sample = av_get_bits_per_pixel(pix_desc) / jxl_fmt->num_channels;
 info.bits_per_sample = avctx->bits_per_raw_sample > 0 && !(pix_desc->flags 
& AV_PIX_FMT_FLAG_FLOAT)
? avctx->bits_per_raw_sample : bits_per_sample;
 info.alpha_bits = (info.num_extra_channels > 0) * info.bits_per_sample;
 if (pix_desc->flags & AV_PIX_FMT_FLAG_FLOAT) {
 info.exponent_bits_per_sample = info.bits_per_sample > 16 ? 8 : 5;
 info.alpha_exponent_bits = info.alpha_bits ? 
info.exponent_bits_per_sample : 0;
-jxl_fmt.data_type = info.bits_per_sample > 16 ? JXL_TYPE_FLOAT : 
JXL_TYPE_FLOAT16;
+jxl_fmt->data_type = info.bits_per_sample > 16 ? JXL_TYPE_FLOAT : 
JXL_TYPE_FLOAT16;
 } else {
 info.exponent_bits_per_sample = 0;
 info.alpha_exponent_bits = 0;
-jxl_fmt.data_type = info.bits_per_sample <= 8 ? JXL_TYPE_UINT8 : 
JXL_TYPE_UINT16;
+jxl_fmt->data_type = info.bits_per_sample <= 8 ? JXL_TYPE_UINT8 : 
JXL_TYPE_UINT16;
+}
+if(ctx->animated) {
+info.have_animatio

Re: [FFmpeg-devel] [FFmpeg-cvslog] fftools/ffmpeg: convert to a threaded architecture

[Michael Niedermayer]

On Tue, Dec 12, 2023 at 07:41:18AM +, Anton Khirnov wrote:
> ffmpeg | branch: master | Anton Khirnov  | Tue Jul 18 
> 16:37:52 2023 +0200| [d119ae2fd82a494d9430ff4d4fc262961a68c598] | committer: 
> Anton Khirnov
> 
> fftools/ffmpeg: convert to a threaded architecture
> 
> Change the main loop and every component (demuxers, decoders, filters,
> encoders, muxers) to use the previously added transcode scheduler. Every
> instance of every such component was already running in a separate
> thread, but now they can actually run in parallel.
> 
> Changes the results of ffmpeg-fix_sub_duration_heartbeat - tested by
> JEEB to be more correct and deterministic.
> 
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=d119ae2fd82a494d9430ff4d4fc262961a68c598
> ---

infinite loops this: (most of the time)

ffmpeg -i tickets///2531/interlaced_top.wmv -t 10 -bitexact -vcodec ffv1 -level 
0 -y  file..avi

https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2531/interlaced_top.wmv

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] fftools/ffmpeg: convert to a threaded architecture

[Michael Niedermayer]

On Thu, Dec 14, 2023 at 12:16:14AM +0100, Michael Niedermayer wrote:
> On Tue, Dec 12, 2023 at 07:41:18AM +, Anton Khirnov wrote:
> > ffmpeg | branch: master | Anton Khirnov  | Tue Jul 18 
> > 16:37:52 2023 +0200| [d119ae2fd82a494d9430ff4d4fc262961a68c598] | 
> > committer: Anton Khirnov
> > 
> > fftools/ffmpeg: convert to a threaded architecture
> > 
> > Change the main loop and every component (demuxers, decoders, filters,
> > encoders, muxers) to use the previously added transcode scheduler. Every
> > instance of every such component was already running in a separate
> > thread, but now they can actually run in parallel.
> > 
> > Changes the results of ffmpeg-fix_sub_duration_heartbeat - tested by
> > JEEB to be more correct and deterministic.
> > 
> > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=d119ae2fd82a494d9430ff4d4fc262961a68c598
> > ---
> 
> infinite loops this: (most of the time)
> 
> ffmpeg -i tickets///2531/interlaced_top.wmv -t 10 -bitexact -vcodec ffv1 
> -level 0 -y  file..avi
> 
> https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2531/interlaced_top.wmv

also infinite loops rtmp using old rtmplite/rtmp.py as server
and
ffmpeg -bitexact -rtmp_app myapp -rtmp_live 0 -i rtmp://127.0.0.1/try -bitexact 
-t 5 file-sp.avi

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [RFC] fftools/ffmpeg and libavdevice/sdl issue

[Stefano Sabatini]

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

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).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] fftools/ffmpeg: convert to a threaded architecture

[Michael Niedermayer]

On Thu, Dec 14, 2023 at 12:16:14AM +0100, Michael Niedermayer wrote:
> On Tue, Dec 12, 2023 at 07:41:18AM +, Anton Khirnov wrote:
> > ffmpeg | branch: master | Anton Khirnov  | Tue Jul 18 
> > 16:37:52 2023 +0200| [d119ae2fd82a494d9430ff4d4fc262961a68c598] | 
> > committer: Anton Khirnov
> > 
> > fftools/ffmpeg: convert to a threaded architecture
> > 
> > Change the main loop and every component (demuxers, decoders, filters,
> > encoders, muxers) to use the previously added transcode scheduler. Every
> > instance of every such component was already running in a separate
> > thread, but now they can actually run in parallel.
> > 
> > Changes the results of ffmpeg-fix_sub_duration_heartbeat - tested by
> > JEEB to be more correct and deterministic.
> > 
> > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=d119ae2fd82a494d9430ff4d4fc262961a68c598
> > ---
> 
> infinite loops this: (most of the time)
> 
> ffmpeg -i tickets///2531/interlaced_top.wmv -t 10 -bitexact -vcodec ffv1 
> -level 0 -y  file..avi
> 
> https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2531/interlaced_top.wmv

also a related question
is there a way to make things execute serially in a predictive manner ?

For example running this twice
./ffmpeg -threads 1 -v repeat+verbose -nostats -y -report -i mm-short.mpg 
-bitexact -t 1 /tmp/file...avi
and cleaning addresses out with sed 's/@ 0x[0-9a-f]*//g'

produces 2 reports that still differ by ordering significantly

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 1/4] libavfilter/vf_dnn_detect: Fix an incorrect expression

[wenbin . chen-at-intel . com]

From: Wenbin Chen 

Signed-off-by: Wenbin Chen 
---
 libavfilter/vf_dnn_detect.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_dnn_detect.c b/libavfilter/vf_dnn_detect.c
index 7ac3bb0b58..b82916ce6d 100644
--- a/libavfilter/vf_dnn_detect.c
+++ b/libavfilter/vf_dnn_detect.c
@@ -106,7 +106,7 @@ static int dnn_detect_parse_anchors(char *anchors_str, 
float **anchors)
 i++;
 }
 nb_anchor++;
-anchors_buf = av_mallocz(nb_anchor * sizeof(*anchors));
+anchors_buf = av_mallocz(nb_anchor * sizeof(**anchors));
 if (!anchors_buf) {
 return 0;
 }
-- 
2.34.1

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

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

[FFmpeg-devel] [PATCH 2/4] libavfilter/vf_dnn_detect: Add NULL pointer check

[wenbin . chen-at-intel . com]

From: Wenbin Chen 

Signed-off-by: Wenbin Chen 
---
 libavfilter/vf_dnn_detect.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavfilter/vf_dnn_detect.c b/libavfilter/vf_dnn_detect.c
index b82916ce6d..b2e9b8d4c6 100644
--- a/libavfilter/vf_dnn_detect.c
+++ b/libavfilter/vf_dnn_detect.c
@@ -112,6 +112,10 @@ static int dnn_detect_parse_anchors(char *anchors_str, 
float **anchors)
 }
 for (int i = 0; i < nb_anchor; i++) {
 token = av_strtok(anchors_str, "&", &saveptr);
+if (!token) {
+av_freep(&anchors_buf);
+return 0;
+}
 anchors_buf[i] = strtof(token, NULL);
 anchors_str = NULL;
 }
-- 
2.34.1

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

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

[FFmpeg-devel] [PATCH 3/4] libavfilter/vf_dnn_detect: Fix uninitialized variables error

[wenbin . chen-at-intel . com]

From: Wenbin Chen 

Signed-off-by: Wenbin Chen 
---
 libavfilter/vf_dnn_detect.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vf_dnn_detect.c b/libavfilter/vf_dnn_detect.c
index b2e9b8d4c6..5668b8b017 100644
--- a/libavfilter/vf_dnn_detect.c
+++ b/libavfilter/vf_dnn_detect.c
@@ -139,7 +139,8 @@ static int dnn_detect_parse_yolo_output(AVFrame *frame, 
DNNData *output, int out
 {
 DnnDetectContext *ctx = filter_ctx->priv;
 float conf_threshold = ctx->confidence;
-int detection_boxes, box_size, cell_w, cell_h, scale_w, scale_h;
+int detection_boxes, box_size;
+int cell_w = 0, cell_h = 0, scale_w = 0, scale_h = 0;
 int nb_classes = ctx->nb_classes;
 float *output_data = output[output_index].data;
 float *anchors = ctx->anchors;
-- 
2.34.1

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

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

[FFmpeg-devel] [PATCH 4/4] libavfilter/vf_dnn_detect: Set used pointer to NULL

[wenbin . chen-at-intel . com]

From: Wenbin Chen 

Set used pointer to NULL in case it leaks the storage.

Signed-off-by: Wenbin Chen 
---
 libavfilter/vf_dnn_detect.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavfilter/vf_dnn_detect.c b/libavfilter/vf_dnn_detect.c
index 5668b8b017..3464af86c8 100644
--- a/libavfilter/vf_dnn_detect.c
+++ b/libavfilter/vf_dnn_detect.c
@@ -223,6 +223,7 @@ static int dnn_detect_parse_yolo_output(AVFrame *frame, 
DNNData *output, int out
 av_freep(&bbox);
 return AVERROR(ENOMEM);
 }
+bbox = NULL;
 }
 }
 return 0;
-- 
2.34.1

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

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

Re: [FFmpeg-devel] [PATCH v2 03/15] avfilter: add negotiation API for color space/range

[Michael Niedermayer]

On Wed, Dec 13, 2023 at 02:12:00PM +0100, Niklas Haas wrote:
> From: Niklas Haas 
> 
> Motivated by YUVJ removal. This change will allow full negotiation
> between color ranges and matrices as needed. By default, all ranges and
> matrices are marked as supported.
> 
> Because grayscale formats are currently handled very inconsistently (and
> in particular, assumed as forced full-range by swscale), we exclude them
> from negotiation altogether for the time being, to get this API merged.
> 
> After filter negotiation is available, we can relax the
> grayscale-is-forced-jpeg restriction again, when it will be more
> feasible to do so without breaking a million test cases.
> 
> Note that this commit updates one FATE test as a consequence of the
> sanity fallback for non-YUV formats. In particular, the test case now
> writes rgb24(pc, gbr/unspecified/unspecified) to the matroska file,
> instead of rgb24(unspecified/unspecified/unspecified) as before.
> ---
>  doc/APIchanges  |   3 +
>  libavfilter/avfilter.c  |  17 +++-
>  libavfilter/avfilter.h  |  28 ++
>  libavfilter/avfiltergraph.c | 173 +++-
>  libavfilter/formats.c   | 122 -
>  libavfilter/formats.h   |  54 +++
>  libavfilter/internal.h  |   6 ++
>  libavfilter/vaapi_vpp.c |   4 +
>  libavfilter/video.c |   2 +
>  tests/ref/fate/shortest-sub |   4 +-
>  10 files changed, 404 insertions(+), 9 deletions(-)

segfaults

./ffmpeg -f lavfi -i 
"amovie=fate-suite/wavpack/num_channels/eva_2.22_6.1_16bit-partial.wv,asplit=3[out1][a][b];
 [a]showwaves=s=340x240,pad=iw:ih*2[waves]; 
[b]showspectrum=s=340x240[spectrum]; [waves][spectrum] overlay=0:h [out0]"  -t 
0.1 -qscale 2 -bitexact /tmp/file-waves.avi

Thread 1 "ffmpeg_g" received signal SIGSEGV, Segmentation fault.
0x557a7c07 in query_formats ()
(gdb) bt
#0  0x557a7c07 in query_formats ()
#1  0x557a84d5 in avfilter_graph_config ()
#2  0x5569ac0a in lavfi_read_header ()
#3  0x55a7bd61 in avformat_open_input ()
#4  0x5574cb43 in ifile_open ()
#5  0x55763c49 in open_files.isra ()
#6  0x55765327 in ffmpeg_parse_options ()
#7  0x557442b4 in main ()

(i can provide better backtrace if you cannot reproduce ...)

thx

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] fftools/ffmpeg: convert to a threaded architecture

[Anton Khirnov]

Quoting Michael Niedermayer (2023-12-14 00:16:14)
> On Tue, Dec 12, 2023 at 07:41:18AM +, Anton Khirnov wrote:
> > ffmpeg | branch: master | Anton Khirnov  | Tue Jul 18 
> > 16:37:52 2023 +0200| [d119ae2fd82a494d9430ff4d4fc262961a68c598] | 
> > committer: Anton Khirnov
> > 
> > fftools/ffmpeg: convert to a threaded architecture
> > 
> > Change the main loop and every component (demuxers, decoders, filters,
> > encoders, muxers) to use the previously added transcode scheduler. Every
> > instance of every such component was already running in a separate
> > thread, but now they can actually run in parallel.
> > 
> > Changes the results of ffmpeg-fix_sub_duration_heartbeat - tested by
> > JEEB to be more correct and deterministic.
> > 
> > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=d119ae2fd82a494d9430ff4d4fc262961a68c598
> > ---
> 
> infinite loops this: (most of the time)
> 
> ffmpeg -i tickets///2531/interlaced_top.wmv -t 10 -bitexact -vcodec ffv1 
> -level 0 -y  file..avi
> 
> https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2531/interlaced_top.wmv

Did you test this and the other loop with 7cc4b306eb? I cannot reproduce
it here.

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

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] fftools/ffmpeg: convert to a threaded architecture

[Anton Khirnov]

Quoting Michael Niedermayer (2023-12-14 03:07:13)
> On Thu, Dec 14, 2023 at 12:16:14AM +0100, Michael Niedermayer wrote:
> > On Tue, Dec 12, 2023 at 07:41:18AM +, Anton Khirnov wrote:
> > > ffmpeg | branch: master | Anton Khirnov  | Tue Jul 18 
> > > 16:37:52 2023 +0200| [d119ae2fd82a494d9430ff4d4fc262961a68c598] | 
> > > committer: Anton Khirnov
> > > 
> > > fftools/ffmpeg: convert to a threaded architecture
> > > 
> > > Change the main loop and every component (demuxers, decoders, filters,
> > > encoders, muxers) to use the previously added transcode scheduler. Every
> > > instance of every such component was already running in a separate
> > > thread, but now they can actually run in parallel.
> > > 
> > > Changes the results of ffmpeg-fix_sub_duration_heartbeat - tested by
> > > JEEB to be more correct and deterministic.
> > > 
> > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=d119ae2fd82a494d9430ff4d4fc262961a68c598
> > > ---
> > 
> > infinite loops this: (most of the time)
> > 
> > ffmpeg -i tickets///2531/interlaced_top.wmv -t 10 -bitexact -vcodec ffv1 
> > -level 0 -y  file..avi
> > 
> > https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2531/interlaced_top.wmv
> 
> also a related question
> is there a way to make things execute serially in a predictive manner ?

You should be able to make it effectively serial with something like
schedtool -a 0x1 -F -p 1 -e ./ffmpeg ...
It still won't be deterministic across runs though.

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

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

Re: [FFmpeg-devel] [PATCH 2/5] fftools/ffmpeg: move parsing of -stats_* specifiers to lavu/parseutils

[Anton Khirnov]

Quoting Thilo Borgmann via ffmpeg-devel (2023-12-13 19:17:04)
> Am 13.12.23 um 17:28 schrieb Anton Khirnov:
> > It is bad practice to design library features around the needs and
> > limitations of a single specific caller.
> 
> The callers here would be the CLI and this filter.

First, public APIs should be designed for general classes of use cases,
not specific callers.

Second, you just said above that the reason you are moving this code
into libavutil is specifically because ffmpeg CLI currently behaves in a
certain way. This is the opposite of proper design, AKA an ad-hoc hack.

> Very much like for av_parse_ratio().
> In contrast to av_get_known_color_name() which actually has just one specific 
> caller, the CLI.

No, not at all like any of these. A ratio or a color are generic
concepts that are not tied to a specific use. By contrast this code is
very much speficic to current ffmpeg CLI processing model. I know this,
because I wrote it.

> Other parsing functions have more callers, some including the CLI.
> And it makes only sense if we offer the same format anywhere for 
> reading/writing the same thing.
> 
> This approach follows what we already do.

It most certainly does not. It _might_ make slightly more sense if it
were a generic pattern decoupled from specific properties being parsed
and used across many filters and/or other modules. But that's now what
is happening here.

> > Many of the directives supported by -stats* make sense only in the
> > context of the ffmpeg CLI, and we may want to add many more in the
> > future. We definitely do not want to hardcode them into libavutil public
> > API.
> 
> At least three of them are already useful for this filter outside of
> the CLI.

Out of 18.

> Others might be useful for other/new uses cases as well and
> all of them would be useful if you'd want e.g. overlay them on top of
> the video.

"Someone might want to use it somehow" is generically true of any
definable value at all, and so does not work as an argument for why
these specific values should be particularly useful to users of this
specific API.

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

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

Re: [FFmpeg-devel] [RFC] fftools/ffmpeg and libavdevice/sdl issue

[Anton Khirnov]

Quoting Stefano Sabatini (2023-12-14 01:47:44)
> 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).

As mentioned elsewhere in the thread, you can just as well pipe raw
video in yuv4mpeg or nut to the video player of your choice and thus
avoid all these hacks.

> 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 have to strongly disagree. This is neither practically workable,
nor a good goal to aim at. This mindset IMO inevitably leads to (among
other problems):
* endless scope creep
* bloated, inefficient, and buggy libraries, trying (and failing) to
  support every use case under the sun
* myopic API design aimed at fulfilling the needs of precisely one
  caller; this is a problem e.g avfilter badly suffers from, and to a
  lesser extent avformat

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

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