[Matroska-devel] S_DVBSUB

Andreas Öman andreas at lonelycoder.com
Mon Aug 23 10:33:41 CEST 2010

On 08/23/2010 09:10 AM, Moritz Bunkus wrote:
> Hey ho,
> On Monday 23 August 2010 09:00:06 Andreas Öman wrote:
>> I also suggest (based on some discussion on IRC) that no extradata is
>> added with composition and ancillary ID, but rather that the muxing
>> application must filter the subtitle segments before muxing.
> With "extradata" he means the following:
> In a MPEG transport stream DVBSUBs are prefixed with four bytes of data
> providing a sub-stream ID. That way several streams inside that DVBSUB
> stream can be identified. Think of tracks in tracks.

Not really, those 4 bytes (2 16bit values) are from the PMT.

> For Matroska I objected to storing streams that way as you only have one
> logical track in a Matroska track. Therefore the proposal to drop those
> four bytes and to use only one DVBSUB sub-stream in a single Matroska
> track.
> I totally agree with that :)
>> As this is my first contact with the list; Did I miss anything?
> Does that codec need any codec extra data (Matroska element
> 'CodecPrivate')?

That was the "extradata" i was referring to above.

Perhaps a bit of clarification is in place.

The reason for having these composition-ID and ancillary-ID
discriminators is to allow sharing of subtitle data between tracks.

A good use of this is subtitles for hearing impaired.
An example how this works (with MPEG TS multiplexing):

In the MPEG PMT you would have two subtitle streams
   PID 1234
   composition ID = 1
   ancillary ID = 0

"English for hearing impaired"
   PID 1234
   composition ID = 1
   ancillary ID = 2

Thus, in PID 1234 you would send normal text segments with
segment ID 1 and hearing impaired related segments with ID 2.
Effectively allowing two tracks to share most of the data.

Now, when re-multiplexing this into the MKV container you
have a few options.

1) Write down all packets in two tracks and attach the
composition and ancillary ID as 4 bytes of codec private data.
This is obviously a bit inefficient when it comes to file size.

2) Pre-filter the data so the packet only contain segments
assigned to the track and disallow any codec private data.

3) Use codec private data and somehow share packets between
tracks. I don't think that's possible with Matroska? Even so,
would any player actually support it?

Note that the term 'segment' here refers to "subpackets" in the
DVB subtitle packet.

Also, if anyone is further interested here is a URL to the spec.

> Regards,
> Mosu
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel at lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel

More information about the Matroska-devel mailing list