Re: [Cellar] Colour Format proposal

Le 06/01/2016 23:30, Frank Galligan a écrit :
>
>
> On Tue, Jan 5, 2016 at 1:58 PM, Jerome Martinez <[email protected] 
> <mailto:[email protected]>> wrote:
>
>     Thanks for your detailed proposal.
>     It is a lot of items, I am not expert in all domains but I have
>     some comments:
>
> Neither am I, but I figured we might as well start from a proposal and 
> iterate from there.
>
>     Name: MatrixCoefficients (or Matrix. You don't use "Colour" with
>     "Primaries" element, so I would not use it here too)
>
>  Sounds good to me.
>
>
>
>>
>>
>>     Element Name: BitsPerChannel
>>     Level:      5
>>     ID:     [55][A2]
>>     Mandatory:    ma
>>     Multiple:     -
>>     Default:      8
>>     Type:     u
>>     Description:  Number of bits per channel. This number may be less
>>     for specific
>>         channels depending on the ColourFormat and ChromaSubsampling.
>
>
>     BitsPerChannel is misleading, used to be the technical count of bits.
>     I propose QuantizationBits or ValidBitsPerChannel
>     Not mandatory, not default (this value is often unknown)
>
> When authoring the video, I'm not sure why the software would not know 
> the bits per channel. Can you describe a use case where the this is 
> unknown?

When you don't author the video (e.g. when you transcode a video from a 
source you don't handle and without such information).
Just take any QuickTime file with FFV1, you want to move to 
Matroska/FFV1, you have Colour Primaries from QuickTime container so you 
want to keep it so you save this colour Element (else you lose 
metadata), how should be filled this mandatory element.
FFV1 bit depth (the one we get from FFV1) is not always the real number 
of bits per channel (it is possible to transform a 8-bit stream to a 
12-bit stream, nothing prevents that), so I don't see where is this 
piece of information.

That said, I am now not sure about the purpose of this element:
- do you mean the real count of valid bits (e.g. this is a 8-bit stream 
oversampled to 10-bit)? In that case, we can not always know if it is 
oversampled and having it mandatory without "unknown" info is blocking.
- do you mean the bits per channel technically in the bitstream? I don't 
see any reason to have such element (useless, we get the info from the 
bitstream, risk of incoherencies)

>
> I really think we should make this mandatory and have authoring 
> software populate the element (or default) vs software thinking this 
> was non-mandatory and not populating this element because the 
> developer didn't think it was needed.
>
> [...]
>
>
>
>>
>>
>>
>>     I can post a link to a formatted document if that would
>>     be easier. For Matrix, Range, and Primaries, I'm pretty much
>>     using values that map directly to values defined in FFmpeg.
>
>     I don't like the idea to use the source code of a piece of
>     software for lists. Too much subjective, may have historical flaws.
>     Lists from FFmpeg are nearly same as the ones in H.26x, I think I
>     prefer we base our list on their list (I don't think there are
>     copyright issues with such list) directly.
>
> I don't know the H.26x list. I started with my own, but then switched 
> to FFmpeg as they already had an extensive list and assumed they have 
> seen a lot of the video already.
>
> If deciding between H.26x and FFmpeg, my guess is that FFmpeg would be 
> better as it handles a lot more video than H.26x.

FFmpeg is made by volunteers, and some parts (e.g. colours) may be not 
so perfect (there was another example in other emails: DPX. the list is 
different, FFmpeg does not support it).
Thinking more about it, maybe we need 2 bytes (or something else): the 
source of the list (MPEG, DPX...) + the list itself.
I am reluctant to create a list from scratch, developers may have issues 
for doing the mapping between lists from different sources.
Anyway, if we create our own list, the question is what to do when MPEG 
add an element to their list: will we be fast enough to update our list 
before people complain that they can not map the new element from their 
source to Matroska? MPEG has numbers 11..255 reserved for future usages, 
I think it is good to reserve something for the future usages from MPEG.
Maybe I go too far and a Matroska-specific list, based on FFmpeg (But 
FFmpeg is not the "reference decoder"...), is enough.

List from H.265 is available at:
https://www.itu.int/rec/T-REC-H.265-201504-I/en
starting page 347 (no paywall)


>     Or that we have a prefix with the origin of the list (e.g. ARIB
>     STD-B67, from Japan, is not in ITU/ISO list, a 18 will be used in
>     the future for something in ITU/ISO)
>
> Yeah HLG is relatively new, but has been requested by a few people.
>
>

_______________________________________________
Matroska-devel mailing list
[email protected]
http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel