steve.lhomme at free.fr
Fri Sep 17 12:59:46 CEST 2004
Moritz Bunkus a écrit :
>>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)
> TrackNumber 1
> TrackUID 20406080 <-+
> TrackType 1 ( = video) |
> TrackSubID 0 <-- new
> FlagDefault 1 |
> Name 'The main angle' |
> CodecID 'V_MS/VFW/FOURCC' |
> CodecPrivate ... |
> Video |
> PixelWidth 640 |
> PixelHeight 480 |
> DisplayWidth 640 |
> DisplayHeight 480 |
> TrackEntry |
> 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
I get the idea. IMO TrackOverlay == TrackSubID. I don't get what the
TrackAssociation is about.
What you are also asking, is changes in the specs for :
which all mandatory elements and all of a sudden are not present in some
cases. I don't see how this solution is less breaking than others. I
think there is 50% chances that MPC and other players will b0rk with
messages like "dunno how to render track XYZ" because there's not even a
codec set. Maybe even mkvmerge could have pb with that. TrackOverlay has
been in the specs from the start and any responsible coder who encounter
the element should at least trigger a warning somewhere stating he
doesn't know how to support such a track. It's the same as some coders
who forgot about 64 bits floats that have been there from the start.
>>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.
It is a track that has a whole new meaning, quite different that what
has been said all the time.
>>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.
Same goes for TrackOverlay. It's been there from the start, is quite
clear, and has never been marked as "version2".
> 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
IMO using the TrackOverlay the way it was supposed to be will create
less problems than other solutions (let alone the alternative
>>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.
Let's not put a lot of if() everywhere and use what has been specified
already. The use of angle will, for the moment, be dependant on the DVD
source, and we'll support just that. If people use different codec (IMO
that should be allowed, for example some codec would do fine on Anime
and bad on camera shots) and resolutions, they might have problem
>>>>- 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...
Yes, several instances of codec for each track (including the
overlay/angle ones) because of IPB frames, at least. So in this context,
other codecs could be used too...
>>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.
Mh, I'm not sure which one you're talking about here. Because the half
empty track that will be confusing for old players is what you propose.
> 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.
Nop, only for the frames that have different angle. But it's true for a
solution that would use only Block2... So apparently the discussion is
now between a standard Track with TrackOverlay or a semi-Track with
robUx4 on blog <http://robux4.blogspot.com/>
More information about the Matroska-devel