> On 23 Aug 2020, at 23:33, Mark Thompson <s...@jkqxz.net> wrote:
>
> ---
> Setting HDR properties is a useful feature, but it's very unclear what we
> want it to actually look like to the user. Not all encoders and decoders
> support it, so it's essentially required that the implementation happen at
> the bitstream filter level so that we can support all codecs in the same way.
> This is several patches mashed together to invite comments on a bitstream
> filter approach.
Mastering display data behaves similarly to color_range, color_primaries,
color_trc and colorspace in that some formats allow use to set it on frame,
some on the stream, some on the container but it is a property of the contained
pictures. I notice that color data can be set per frame and per stream already
and I don’t fully understand how these interact if converting between data in
frame (e.g HEVC SEI in stream in hev1) or data in header (e.g. MOV mdcv tag or
HEVC SEI in hvc1 format).
Content light level data is a little different as it describes the stream in
which the image is contained and ffmpeg image filters would affect it. It it
however still a property of the whole stream.
I guess my question is how to provide a good experience converting between
hvc1, hev1, prores in movs, av1 etc etc when the data has to be moved between
frame and stream.
>
> […]
>
> Thoughts invited on any of this.
As you point out MDCV and CLLI are relevant to so many codecs and container
formats that anything with hevc_ etc would be confusing as adapting configs for
different formats would require extra work (e.g. read from av1, write to hevc
bitstream filters).
I an pretty new to FFMPEG to please ignore any of this that makes no sense :)
Harry
_______________________________________________
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".
