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

wm4 nfxjfg at googlemail.com
Thu Sep 24 13:28:02 CEST 2015


On Wed, 23 Sep 2015 22:03:56 +0000
Joseph Ashwood <ashwood at msn.com> wrote:

> 
> 
> > Date: Wed, 23 Sep 2015 21:27:16 +0200
> > From: nfxjfg at googlemail.com
> > Subject: Re: [Matroska-devel] New Matroska field: chroma range/pixel format
> 
> > On Wed, 23 Sep 2015 18:00:58 +0200
> > Steve Lhomme <slhomme at matroska.org> wrote:
> 
> > > We currently have a ColourSpace field 
> > > When storing raw video, the pixels are stored in a certain way and
> > > decoding the pixels need some conversion from this encoding to
> > > whatever your screen is using. Right now we don't have all the fields
> > > needed to describe these raw data.
> 
> Actually I think it is of significant value beyond just raw video.
> Certain codecs only support certain color spaces. I see no reason that Matroska cannot store a field that labels the correct color space/gamut/etc. for the output. The fields will need to be very flexible because the list of color spaces/gamuts just keeps growing. We are now seeing even near consumer cameras that support enough variability for tens of thousands of different space and gamut combinations. As an example the Sony a7s mark 2 has one hundred different combinations just for the standard gamuts, with the ability to configure more. Being able to store those accurately, without any space/gamut conversion will lead to better picture. 

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. What if the container sets a specific parameter,
and the codec also does? What if the codec's changes mid-stream? 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.


More information about the Matroska-devel mailing list