[FFmpeg-devel] Towards YUVJ removal

[Diederick C. Niehorster]

On Fri, Dec 9, 2022 at 1:45 PM Niklas Haas <ffmpeg at haasn.xyz> wrote:

> Oh, you are right. So that presents an alternative to 4 - rather than an
> encoder flag, we can tie the auto-conversion in fftools to be tied to
> the strict_std_compliance check.
>
> I will try implementing this approach, it may be the best compromise in
> that it presents a clear upgrade path that doesn't break the common
> case.
>
> That said, there still is an encoder that has this problem: "amv".
> Currently, this only advertises YUVJ, but after YUVJ removal, it would
> be treated equivalently to mjpeg when `strict_std_compliance` is enabled.
>
> But given that this is a less common format, I think, such a regression
> would not be as big a concern. (And we can still special-case it in
> fftools, if we want to)
>

As a user of the API, I do not think hacking fftools is the way to go. I
vote option 3, filter negotiation also takes color_range (etc) info into
account, and auto-inserts a scale where needed. But that is only half the
solution, and actually not the important part. If i have a frame source and
another sink that both have declared pixel formats, i can easily check
whether conversion needs to happen at all, and if so, just set up an empty
filter chain and have it auto-insert the required scale filter (super!).
Now i would have to also be able to:
1. have settings in the filter context (i guess) for color_range, etc, and
corresponding syntax for the args argument of
avfilter_graph_create_filter() and/or corresponding options to set, so that
filter input and output sides can be provided with correct info
2. query my sink for what it actually provides (a bunch more functions
ala av_buffersink_get_format() are needed to get color_range, etc)

I probably don't oversee the problem, so may be missing more that needs to
be done, or be off the mark here.

I also agree with Henrik that a way to query encoders for what they support
besides formats is critical, and that this should ideally be
context-senstive (so you can set certain options, and then query what
remains of supported pix_fmts, color_range, etc).

All the best,
Dee