aboutsummaryrefslogtreecommitdiffstats
path: root/presets/libvpx-1080p.ffpreset
diff options
context:
space:
mode:
authorNiklas Haas <git@haasn.dev>2022-06-28 14:25:15 +0200
committerNiklas Haas <git@haasn.dev>2022-07-30 11:42:06 +0200
commit61ffa23c2e42887b32d469d9e69e9eb887b29e9c (patch)
tree623b89e032f132f05ac78654606e05e44d56454f /presets/libvpx-1080p.ffpreset
parent1cbd4552fe3bcdc36b76304d11b883d061cc23ee (diff)
downloadffmpeg-61ffa23c2e42887b32d469d9e69e9eb887b29e9c.tar.gz
avcodec/codec_internal: add cap for ICC profile support
Codecs that can read/write ICC profiles deserve a special capability so the common logic in encode.c/decode.c can decide whether or not there needs to be any special handling for ICC profiles. The motivation here is to be able to use it to decide whether or not an ICC profile needs to be generated in the encode path, but it might as well get added to decoders as well for purely informative reasons. It's not entirely clear to me whether the "thp" and "smvjpeg" variants of "mjpeg" should have this capability set or not, given that the code technically supports it but I somehow doubt these files may contain them. In either case, this cap is purely informative for decoders so it doesn't matter too much either way. It's also not entirely clear whether the "amv" encoder should signal ICC profile support, but again erring on the side of caution, we probably *shouldn't* be generating (and encoding!) ICC profiles for this type of media file. Signed-off-by: Niklas Haas <git@haasn.dev>
Diffstat (limited to 'presets/libvpx-1080p.ffpreset')
0 files changed, 0 insertions, 0 deletions