[FFmpeg-devel] Towards YUVJ removal

[Niklas Haas]

On Fri, 09 Dec 2022 13:10:02 +0100 Andreas Rheinhardt <andreas.rheinhardt at outlook.com> wrote:
> This is incorrect: Here are the pixel formats advertised by the mjpeg
> encoder:
> 
>     .p.pix_fmts     = (const enum AVPixelFormat[]) {
>         AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P,
>         AV_PIX_FMT_YUV420P,  AV_PIX_FMT_YUV422P,  AV_PIX_FMT_YUV444P,
>         AV_PIX_FMT_NONE
>     },
> 
> ffmpeg only inserts the swscale filters, because said list is overridden
> in get_compliance_normal_pix_fmts() in fftools/ffmpeg_filter.c. See
> 059fc2d9da5364627613fb3e6424079e14dbdfd3.
> Also notice that the encoder errors out if fed with limited range data
> depending upon strict_std_compliance (see
> ff_mjpeg_encode_check_pix_fmt()), which is very similar to the first
> approach below; the override being in fftools implies that the breakage
> of the first approach would be confined to users of fftools.

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)