[Matroska-devel] S_DVBSUB

Dan Haddix dan6992 at hotmail.com
Sat Feb 19 22:50:42 CET 2011


> Date: Sat, 19 Feb 2011 12:54:06 +0100
> Subject: Re: [Matroska-devel] S_DVBSUB
> From: slhomme at matroska.org
> To: dan6992 at hotmail.com
> CC: matroska-devel at lists.matroska.org
> 
> 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
> (http://www.matroska.org/technical/specs/index.html#BlockAdditions)
> (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
> timecode
> 
> 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
> (http://www.matroska.org/technical/specs/index.html#BlockAdditionID).
> 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.
> 
> Steve
> 
> -- 
> Steve Lhomme
> Matroska association Chairman


OK so the PMT entry for each PID has attached to it an array which describes the language, composition page ID and ancillary page ID for each of the sub-streams. So a PID with multiple sub-streams might look something like this...

Language = English
Composition Page ID = 1
Ancillary Page ID = 3

Language = English for hearing impaired
Composition Page ID = 2
Ancillary Page ID = 3

When each packet comes along it carries just a single page ID value. If the page ID for the packet is 3 then it would be displayed if either sub-stream was selected. If the page ID was either 1 or 2 then it would only be displayed if that specific sub-stream was selected. Typically how this is used is that the majority of data is stored with a page ID 3. Only packets which need to be displayed differently for either sub-stream are stored with page IDs of 1 or 2. In most cases the hearing impaired track would simply carry extra captions, aimed for display in a separate area, to describe noises that are displayed at the same time as the common packets. However on occasion both tracks will require the display of the same text in slightly different ways so they will each have their own packet for that specific frame.

As you can see by the design separating these into MKV tracks isn't really easy because the common data doesn't really belong to either track. And if somehow it was removed it would make the other two tracks useless. 

After thinking about it more I think the best way to do this is to copy the common data to both tracks and then reset the page ID for each packet to a single value. That way the MKV container does not need to have a concept of composition and ancillary page IDs, we can just assume that both are always set to 1, and each sub-stream can be represented in the MKV as a separate track which is completely independent of any other tracks.

With that approach storing DVB subs in an MKV would still be relatively simple for the output application, only requiring minor parsing to reset the page ID and copy the data to all tracks, and reading them would be completely transparent to the player/demuxer. We wouldn't even need any CodecPrivate data.

Dan
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20110219/8cd0a388/attachment.html>


More information about the Matroska-devel mailing list