[Matroska-devel] S_DVBSUB

Andreas Öman andreas at lonelycoder.com
Sun Aug 29 22:55:25 CEST 2010


On 08/23/2010 09:16 PM, Steve Lhomme wrote:
> Mh, that's an interresting case. I don't understand the difference
> between the composition ID and the ancillary ID (and the PID in your
> example is twice the same, is it normal?).

I've no idea how common it is to share data between tracks.
But assuming two subtitle tracks would share data the PID would
have to be the same (or they have nothing in common to share from)

The composition ID and ancillary ID can just be thought of as filters.
If a subtitle packet with an ID matches any of those two IDs it would
be displayed.

Reading the spec PDF i posted in my previous mail may clarify a bit.



>
> But it's clear that the goal of sharing data between tracks is an
> interresting one. In clean Matroska there could be different ways to do
> that:
>
> - use 2 tracks and "chapter codec" to switch between one track or the
> other given the position. That's quite inconvenient to handle and not
> really in the stream itself. So I don't think it should be done that way.
>
> - use virtual tracks, or rather regular tracks but with virtual blocks.
> There used to be BlockVirtual for that. But the design is not clean and
> is deprecated. Plus it's not exactly what we want here. So we need
> something new. We recently added TrackDepdency for 3D playback. That's a
> way to combine 2 "mono" tracks to make a "stereo" one. The same could be
> done with subtitles. The TrackDependency creating a new track on its
> own, by combining 2 existing tracks.
>
> So in this case there would be 3 actual tracks:
> - 1: english
> - 2: english for hearing impaired
> - 3: common data between 1 and 2
>
> None of these tracks are really usable as they are and should be marked
> as such (the Track FlagEnabled set to 0). And 2 TrackDependency would
> define the actual mix of 1+3 and 2+3 for actual playback. That means
> TrackDependency has to be enhanced/tuned to allow something like this.
>
> Did I miss anything or didn't understand correctly the goal here ?

No, I think you got it.

As I said I've no idea how common it is to share data between tracks
in the DVB real world. My gut feeling is that it isn't that common (I've
never seen it in the wild). My suggestion is to leave the track sharing
out of the picture for subtitles (which, after all, isn't that data
intensive).

One alternative would be to make the Codec Private Data optional
basically saying that:

- If no Private Data is present the packets must be pre-filtered by the
muxing application

- If Privade Data is present (4 bytes with 2 x 16bit of those IDs) the
decoder should apply filtering.

The only opensource decoder I've used for decoding DVB subtitles
(FFmpeg) already works in exactly this way.





>
> Steve
>
> On Mon, Aug 23, 2010 at 10:33 AM, Andreas Öman <andreas at lonelycoder.com
> <mailto:andreas at lonelycoder.com>> wrote:
>
>     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
>     "English"
>       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.
>
>     http://broadcasting.ru/pdf-standard-specifications/subtitling/dvb-sub/en300743.v1.2.1.pdf
>
>
>         Regards,
>         Mosu
>
>
>
>
>
>         _______________________________________________
>         Matroska-devel mailing list
>         Matroska-devel at lists.matroska.org
>         <mailto: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
>
>
>     _______________________________________________
>     Matroska-devel mailing list
>     Matroska-devel at lists.matroska.org
>     <mailto: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
>
>
>
>
> _______________________________________________
> 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