steve.lhomme at free.fr
Fri Sep 17 11:05:43 CEST 2004
Moritz Bunkus a écrit :
>>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
>>- 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
Again, I don't see where my 2 main options would break anything.
More information about the Matroska-devel