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.