Re: [Cellar] Colour Format proposal

2016-01-06 23:30 GMT+01:00 Frank Galligan <[email protected]>:
>
>
> On Tue, Jan 5, 2016 at 1:58 PM, Jerome Martinez <[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 remuxing an older file. Either from Matroska source or AVI or other.

Now if elements are mandatory with a default value to "unknown" it's fine.

> 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.
>>
>>
>>
>>
>> Element Name: ChromaSubsampling
>> Level:        5
>> ID:           [55][A3]
>> Mandatory:    ma
>> Multiple:     -
>> Default:      0
>> Type:         u
>> Description:  (0: 4:2:0, 2: 4:2:2, 4: 4:4:4)
>>
>>
>> FFV1, for example, permits "weird" chroma values, more possibilities.
>> And the following chroma values were seen at least once in some specs:
>> 4:4:4
>> 4:2:2
>> 4:2:1
>> 4:1:1
>> 4:2:0
>> 4:1:0
>> 3:1:1
>>
>> So having a list is maybe not the solution.
>> I like the way it is done in FFV1, except the power of 2 (so 3 can not be
>> expressed).
>> I propose to find a way for describing Chroma subsampling (e.g.
>> h_chroma_subsample and v_chroma_subsample; a ratio per plane with any number
>> of plane, think to alpha channel with a subsampling).
>
> I'm fine with coming up with a more extensible solution (Micheal asked for
> that as well).
>>
>>
>>
>>
>>
>>
>> Element Name: ColourRange
>> Level:        5
>> ID:           [55][A4]
>> Mandatory:    ma
>> Multiple:     -
>> Default:      1
>> Type:         u
>> Description:  (0: Unspecified, 1: Defined by
>> ColourMatrix/TransferFunction,
>>               2: Full range)
>>
>>
>> I don't understand the 1 value.
>> in at least AVC and HEVC, range is orthogonal to
>> ColourMatrix/TransferFunction.
>> I propose 0: unspecified 1: Broadcast range 1: Full range
>> and Default:0
>
> I thought someone mentioned to me before that the range could change based
> on the matrix and transfer function. I'm fine with your proposal.
>
>>
>>
>>
>> I got requests for having information about "Capture Gamma Equation" (or
>> "Tone Curve"), e.g. "same as transfer characteristic", Scene Linear, S-Log,
>> Cine-Log, Log-C...
>> I am not an expert of this domain, but looks like it is sometimes
>> important.
>
> Someone who knows more about  this should propose something to this list to
> be included.
>
>>
>> there are also other colour ideas with e.g. EBU Tech 3349.
>
> If this is important to people, then we could add this as well.
>>
>>
>>
>>
>>
>>
>> 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.
>
>>
>> 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.
>
>
>
> _______________________________________________
> Cellar mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/cellar
>



-- 
Steve Lhomme
Matroska association Chairman
_______________________________________________
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