slhomme at matroska.org
Sat Feb 19 12:54:06 CET 2011
On Fri, Feb 18, 2011 at 11:19 PM, Dan Haddix <dan6992 at hotmail.com> wrote:
> I understand that you want to express every "track" in the file at the
> container level so that programs can know which tracks are available by
> simply parsing the MKV header. However I'd argue that the sub-streams in a
> DVB subtitle streams are not really separate "tracks". It's more like a flag
> in each frame which tells the decoder to display or ignore each packet
> depending on a filter. If the decoder had no knowledge of the sub-streams it
> wold still simply display all the common frames and ignore all frames which
> belonged to a sub-stream.
> Another problem I have with separating the packets into multiple MKV
> "tracks" is that the sub-streams have no meaning without the master stream.
> So if an application was to remove the master track, but not the sub-stream
> track, then sub-stream track would basically be useless. There is a reason
> these sub-streams are coupled together into a single PID in the TS format,
> because they are not really independent streams.
Can you explain a bit more about this dependency ? In Matroska we can
handle 2 cases (which are better handled at the container level):
- sub packets that may or may not be decoded
(for example for hybrid Wavpack)
- TrackOperation that can "join" 2 tracks to make a third one. It's a
new feature and doesn't define what happens when Blocks have the same
Maybe DVBSUB doesn't fall in any of these categories. Right now there
is nothing that defines what packets from BlockAddition are describing
exactly. There's only a value in the Track that says there will be
additional data to the packet
It's up to the codec to interpret these data. For Wavpack it turns a
lossy version of the stream into a lossless one. There is a plan to
use BlockAdditions to add transparency support to VP8 as well... The
idea of BlockAddition is that it can be stripped by a muxer and the
stream will still play fine.
> If you really insist on having separate tracks for every sub-stream then I
> suggest we store a copy of all common packets in both tracks, rather then
> using TrackOperation method. This will create some redundant data but at
> least each stream will be self contained and can be added/removed from the
> MKV file without effecting the other streams. Plus doing this would require
> no special modification to the muxers/demuxers currently in use. It would
> only require the creation application to copy the common packets to all
> tracks and flip a few bits on the sub-stream packets so they they would then
> appear as if they were common packets for that track. To the reading
> application they would simply appear as separate PIDs with no sub-streams.
That could be done with TrackOperation. It's possible to join more
than 2 tracks to make a new 'virtual' one. Again that depends how much
the data of different sub-streams are interdependent.
Matroska association Chairman
More information about the Matroska-devel