On Fri, Oct 20, 2023 at 03:54:16PM +0200, Anton Khirnov wrote: > Quoting Niklas Haas (2023-10-14 13:46:34) > > > 3. I don't see how the MJPEG encoder behaviour where the valid formats > > > de facto depend upon strictness can be encoded in this way; isn't the > > > aim to get rid of the necessity of the workaround in ffmpeg cli? > > > > Note that ffmpeg cli presently initializes the filter graph well before > > the AVCodecContext is set up with options, let alone opened. (Presently, > > the logic for overriding the pixfmt list directly looks up the "strict" > > field in the options dict) > > > > So that limits the design space somewhat for elegant solutions here. > > Either we make the "return list of supported formats" callback in > > AVCodec simply accept the strict_std_compliance setting directly, or we > > extend the static list of colorspaces itself by an extra strictness > > field. Probably the former is better than the latter of these two > > approaches. > > FWIW I find that behaviour to be a disgusting hack and the cleanest way > to address it would IMO be a separate mjpeg_experimental AVCodec > instance. That is assuming anyone actually needs this functionality. > Maybe we could also just drop it?
The usecase i remember was lossless jpeg, but this seems to support it by default now If there is still a usecase, then i agree *jpeg_experimental would be an option. or maybe jpeg_somethingrange maybe this is usefull for encoding some mjpeg variants. Somehow i think they didnt all use the same range thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Elect your leaders based on what they did after the last election, not based on what they say before an election.
signature.asc
Description: PGP signature
_______________________________________________ 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".
