[Matroska-devel] Multi-Angle

Moritz Bunkus moritz at bunkus.org
Fri Sep 17 10:25:09 CEST 2004


Hi,

> We already have tracks that can be associated with others using 
> TrackOverlay.
> "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.

> Then IMO it should be specified. Otherwise that would make tracks with 
> full info and the others without.

That's my idea. Have the main track contain all the codec information
and have the others not contain them.

> 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).

> - You can't use different codecs.

That's actually an advantage.

> - 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.

> - you don't know if it's an audio, video or whatever track by looking
>   at it

Just look at the associated track. This is really a non-issue.

> You forgot to talk about my proposition for a new Block,

Having a complete new Block might be ok (although it would be hell to
handle with libmatroska) if it is ONLY used for the non-default angle
packets. Old parsers could simply skip those.

> 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.

> Advantages :
> - no need for a track for each angle

How is that a disadvantage? Track headers are cheap ( = small), UIDs and
track IDs are plenty.

> - you can have 9 angles on one part of the movie and 15 later

How is that a problem? Ok, it can be a problem because the muxing app
has to know the maximum number up front, but that's all.

> - the parser is always looking for the same track

The new one. The old one, too, and it'll BREAK because it finds much
more packets or unknown block types.

> * the main angle (corresponds to the main track in the other option) 
> could keep the Block as it is now to keep full backward compatibility

Yes, that's ok, but not your BlockTypeVersion approach. We have to use a
new element for that.

> - 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.

> - avoid having blocks for an angle in another cluster than the main
>   track

Ok, this one's valid.

> - 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.


> Disadvantages:
> 
> - You can't use different codecs.

Again, that's an advantage ;)

Mosu

-- 
If Darl McBride was in charge, he'd probably make marriage
unconstitutional too, since clearly it de-emphasizes the commercial
nature of normal human interaction, and probably is a major impediment
to the commercial growth of prostitution. - Linus Torvalds



More information about the Matroska-devel mailing list