[Matroska-devel] New Matroska field: chroma range/pixel format

Jerome Martinez jerome at mediaarea.net
Thu Sep 24 17:22:16 CEST 2015

Le 24/09/2015 17:11, wm4 a écrit :
> On Thu, 24 Sep 2015 16:18:00 +0200
> Jerome Martinez <jerome at mediaarea.net> wrote:
>> Le 24/09/2015 13:28, wm4 a écrit :
>>> [...]
>>> This is exactly what I don't want to have. There will be a mess of
>>> which parameters (codec or container) are preferred for which codec and
>>> in which situation.
>> Isn't it already the case with PixelWidth and PixelHeight?
>> Do you mean that you want them to be removed, in order not to have to
>> deal with a situation with incoherent values, and so many codecs already
>> have such metadata? ;-).
> No, for these the codec parameters definitely win, should they be
> ambiguous at all.
> But for inconsistent container/codec aspect ratios, there are at least 3
> different methods used by real world players. This means if you play
> the same Matroska file in 3 different players, you will get 3 different
> results. I'm repeating this point, since you seem to have ignored this.

I did not ignored it, I agree with it.
and this is the reason I propose a standardized (=in specs) behavior in 
case of incoherency.

>>>    What if the container sets a specific parameter,
>>> and the codec also does? What if the codec's changes mid-stream?
>> Same about PixelWidth and PixelHeight.
>>>    We
>>> already have a VERY BAD mess with aspect ratios, and I know 3 different
>>> players which handle this in 3 different ways.
>>> I'd rather have Matroska lacking certain features than dealing with such
>>> a mess.
>> :(.
>> On my side, I prefer having some features even if there are issues to
>> deal with than preventing Matroska to be more widely used.
>> Here we also speak of formats which do **not** have the possibility to
>> store such parameter in the codec, and I think it would be a pity to
>> block standardization of some Matroska metadata only due to potential
>> incoherences between container and codec.
>> We could explicitly say that such Matroska metadata has lower priority
>> than codec metadata.
> Yes, you could say that, except that this isn't true for some existing
> parameters.

I don't understand: I spoke of these new metadata only, the new ones.
for other (old) metadatas, we could define in IETF specs what is 
expected (which metadata has priority) in case of incoherency then write 
to projects which do not conform in order to make them have the same 
behavior (before asking them to change, let's agree here, during IETF 
spec writing, about what should be the right behavior).

More information about the Matroska-devel mailing list