moritz at bunkus.org
Fri Sep 17 11:49:52 CEST 2004
> So what you are asking is a new element, equivalent to Tracks ?
Nope. Let me draw a picture that will hopefully make clear what I
propose: (best viewed with a fixed-width font)
TrackUID 20406080 <-+
TrackType 1 ( = video) |
TrackSubID 0 <-- new
FlagDefault 1 |
Name 'The main angle' |
CodecID 'V_MS/VFW/FOURCC' |
CodecPrivate ... |
PixelWidth 640 |
PixelHeight 480 |
DisplayWidth 640 |
DisplayHeight 480 |
TrackNumber 2 |
TrackUID 1357924680 |
TrackType 101 ( = associated to another track) <-- new |
TrackAssociation 20406080 <-- new <-+
TrackSubID 1 <-- new
Name 'A second angle'
[CodecID and Video etc are missing, so copy them from the associated
The first one (TrackNumber 1) is the one I call 'associated to', the
second one the one I call 'associatee'.
> 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".
My thing IS a track, it just has a type that's not used yet.
> Actually you want to mix track numbers with sub-track numbers.
No, definitely not! Such associated tracks have their own track
number. Each of the associated tracks and the main track have a new
element called 'sub-ID' which would probably contain the angle ID in our
case. The sub-IDs and TrackNumber and TrackUID number spaces are all
distinct. TrackNumber and TrackUID are unique throughout the segment,
while sub-ID is unique over all tracks that belong to one association
> 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
I do say it because all those splitters where not spec compliant. 64bit
floats have been part of the specs since the beginning. What I want is:
"if a parser is bug free and spec compliant at the moment then it should
play such new files (at least the main angle) without problems". The
Matroska dogma is "ignore elements that where not part of the specs at
the time the demuxer was written". New files should not break parsers
that follow this rule.
With my proposal old charsers at least stand a chance of working
properly. If they don't then we're not off worse than with other
proposals because the parsers would then have to be updated in either
> 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.
Ok, the resolution change might be necessary. If the 'associatee' does
not contain certain track header elements like PixelWidth etc then those
are copied from the 'associated to' track.
> >>- You can't use different codecs.
> No, just a limitation. That's an advantage for the coders.
:) Yes. But it doesn't gain you THAT much imho. Anyway, with my updated
proposal you could put a CodecID into the 'associatee' and have
different codecs that way. If not the demuxer must create several
instances of the same codec because...
> 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.
...of this. You're right, of course.
> Again, I don't see where my 2 main options would break anything.
They partially "break" in the sense that e.g. half empty video tracks
(in the case "just add another track") will confuse players, I
guess. This is not really "breaking", but it's not nice.
Btw. Adding a new "BlockGroupVersion" element for each block group would
cause 3 bytes overhead for _each and every frame_. Unacceptable, IMHO,
even though we don't define ourselves through the overhead alone.
With my proposal one big advantage is that you don't have to modify the
BlockGroup, nor do you have to introduce a new Block element at all. The
angle ID is contained in the track's SubID element.
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