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? -- Anton Khirnov _______________________________________________ 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".
