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

Steve Lhomme slhomme at matroska.org
Sun Oct 4 17:23:42 CEST 2015


2015-10-01 15:14 GMT+02:00 Dave Rice <dave at dericed.com>:
>
>> On Sep 24, 2015, at 11:22 AM, Jerome Martinez <Jerome at MediaArea.net> wrote:
>>
>> 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.
>
> I think I'm most familiar with the container's data being used over the codec's data in the case of a container/codec conflict, though this is mostly from seeing QuickTime container metadata overruling codec data within QuickTime based applications. The Matroska specification doesn't seem to speak to container/codec conflict but perhaps we should move this to another thread to draft a statement saying something like "explicit container data should supersede conflicting container data except in these circumstances..."

Agreed. At least for the cropping the idea is that supersedes the
values written in the codec. So you just have to edit your Matroska
file to change the visible area. The cropped value coming from the
codec should correspond to the PixelWidth/PixelHeight value, so the
value doesn't need to know how it's coded internally.

>>>>>   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.
>
> Right. I think it's important to consider these new fields for Matroska so that it can properly handle uncompressed video and other codecs that don't well document themselves. But the objective of such efforts is really to prevent the presentation discrepancies that wm4 mentions. If there are 3 different methods of handling aspect ratios then either the 2 players have a bug and/or the specification is not clear enough.
>
> [...]
>
> I wasn't able to find documentation on the one hundred distinct color matrices for the Sony a7s mark 2, but suggest that this effort start with the most common chroma matrices such as bt601, bt709, bt2020. And for sample range document if the video is full range or broadcast range.
> Best Regards,
> Dave Rice
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel



-- 
Steve Lhomme
Matroska association Chairman


More information about the Matroska-devel mailing list