[FFmpeg-user] [Cin] FranceBB's LUT collection

[Erik Dobberkau]

Is it all right to 'talk' about the picture stream? For the various
> permutations of OETF (in camera), what comes out the decoder? I assume that
> for BT2020 SMPTE2084 it's HDR10 PQ, and for BT2100 it's either HDR10 PQ or
> HDR10 HLG. In other words, the decoder just makes pictures but doesn't do
> color transforms. To the best of your knowledge, is that correct?
>
>>
>>
It depends. For 'raw' streams (not meaning the camera .RAW format here),
one should not assume the stream to carry metadata about the encoding
characteristics, it's just pixel data. Non-raw streams usually provide data
fields to store such information, but then it depends on the encoder and
decoder whether these fields are filled and read according to the spec (if
one exists). For some file formats, the information may also be stored as
metadata in the file wrapper, and the same 'advice for caution' as for
streams applies. But in the end, it depends on the implementation of the
software making use of said readers/writers and en-/decoders what results
are delivered by default, i.e. what is ignored/dropped or
overridden/re-interpreted and what is propagated through the processing
pipeline, and then how the pipeline responds, based on its capabilities,
and if you as a user have one or more ways to control/override this.
So yes, the video decoder's job is to consume data packets and produce
image frames, but if the pipeline's frame data structures allow to
propagate additional frame information from the decoder, a decent decoder
should make these data fields accessible for pulling them into the
pipeline, or rather, a decently integrated decoder will push this data into
the pipeline. I have not yet come across a decoder which would
automatically apply a color transformation, as this is a different task
subject to other requirements and preferences, which the en-/decoder's
developers prefer to not be burdened with.