[Matroska-devel] Multi-Angle

Steve Lhomme steve.lhomme at free.fr
Fri Sep 17 11:05:43 CEST 2004

Moritz Bunkus a écrit :

> Hi,
>>We already have tracks that can be associated with others using 
>>"u-integer  	Specify that this track is an overlay track for the Track 
>>specified (in the u-integer)."
> That's not what I meant. I want a new track type, not use another
> element and have a normal track. Again the argument that a current
> parser will be greatly confused by this.

So what you are asking is a new element, equivalent to Tracks ? 
TrackEntry ? or something else ? IMO that's quite ugly to have tracks, 
and "oh BTW, don't forget to read this thing that is a track and not a 
track at the same time, which numbers will hopefully not use another 
number by regular tracks". Actually you want to mix track numbers with 
sub-track numbers. You think it's clean to have a Matroska file with 
tracks that older parsers have no knowledge about ? How would current 
mkvmerge behave which such files that you claim are backward compatible ?

BTW, about backward playability. In newer mkvmerge you forced the use of 
64 bits floats even when it's not needed (only audio-only files need 
that), and that makes new files not playable in a few players including 
MPC. So don't say too loud that backward playability is a vital feature.

>>And besides they may use different codec.
> Ooooooooooooh my god! And different resolution, too, I guess? Is this
> possible on a DVD, too!? If not then we shouldn't allow this
> either. This is VERY complicated to handle. No one will ever support
> this (apart from Haali).

Well, I'm not 100% sure for DVD, but I think you can have letter-box and 
non-letterbox cells in the same video track, ie not the same resolution. 
But that's also a feature of MPEG2. And none of our solutions would 
handle that anyway. Using TrackOverlay can allow that feature.

>>- You can't use different codecs.
> That's actually an advantage.

No, just a limitation. That's an advantage for the coders.

>>- The track can't be used without the main track (not true for DVD)
> That's not a disadvantage. You either have both tracks (main and
> associated) in the same file or the application that copies such an
> associated track out of the main file has to 'fill in' the codec data
> from the main track.

I'm mixed on that supposed easeness. Because I'm not sure some codec 
would not have problems if you put frames from another track in there. 
I'd prefer one codec instance per track (using TrackOverlay) and the 
overlaying is done after the codec stage. That would allow IPB frames at 
different locations for each track. Which seem very logical from a codec 
point of view (efficiency) and also to seek in the file on I frames.

>>or more specifically a new BlockGroup type (actually a
>>BlockGroupVersion that would have value 2 in this case).
> But this breaks things. Again. Every current parser would ignore the
> BlockGroupVersion element because it doesn't know it and would parse the
> block in the wrong way.

And would only read the Block as it used to do. Only other angles could 
make use of the new Block. We can also have BlockGroupVersion = 3 that 
would only use Block2, and people would know the files would not be 
backward compatible.

>>- when extractting to DVD (see dvd->mkv->dvd) it looks better to output 
>>different angles in a BlockGroup into different angle cells, than 
>>parsing all possible tracks
> Well... This will only be true if we break things.

Neither TrackOverlay nor the BlockGroupVersion would break anything. 
Just adding things.

>>- The file can be easily remuxed to keep only one angle
> Only if we break things. Otherwise it's just as simple/hard as my
> proposal.

Again, I don't see where my 2 main options would break anything.

More information about the Matroska-devel mailing list