[FFmpeg-devel] Towards YUVJ removal

[Paul B Mahol]

On 12/9/22, Niklas Haas <ffmpeg at haasn.xyz> wrote:
> 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)

Sounds too much hackish.