On Fri, 09 Dec 2022 13:10:02 +0100 Andreas Rheinhardt <andreas.rheinha...@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) _______________________________________________ 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".