On 12/9/22, Niklas Haas <ffm...@haasn.xyz> wrote: > 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)
Sounds too much hackish. _______________________________________________ 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".