[Matroska-devel] New Matroska field: chroma range/pixel format
nfxjfg at googlemail.com
Thu Sep 24 17:11:56 CEST 2015
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.
> > 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
More information about the Matroska-devel