[Matroska-devel] S_DVBSUB

Dan Haddix dan6992 at hotmail.com
Thu Feb 17 22:26:37 CET 2011




> Date: Thu, 17 Feb 2011 20:54:25 +0100
> Subject: Re: [Matroska-devel] S_DVBSUB
> From: slhomme at matroska.org
> To: matroska-devel at lists.matroska.org
> CC: dan6992 at hotmail.com
> 
> On Wed, Feb 16, 2011 at 10:57 PM, Dan Haddix <dan6992 at hotmail.com> wrote:
> > I'm new to this list, and MKV in general, but I've just read the threads
> > about how you plan to handle the new S_DVBSUB type and I completely disagree
> > with the design. I understand the reasoning behind it, since MKV was not
> > designed to hold multiple sub-streams in a single track, but you're
> > basically redesigning an established, widely used, standard because it
> > doesn't fit into MKVs normal usage. The method you've proposed is going to
> > force muxers to parse the real DVB packets into separate tracks for storage
> > inside the MKV and then the player/demuxer to recombine those tracks back
> > into their original format so that their decoders, which were written to
> > handle the packets as they are stored in TS, can properly parse them. This
> > seems like a very arrogant way to handle it. The TS format wasn't really
> > designed to hold multiple sub-streams on a single PID either, but the DVB
> > subtitle format still does it. Why should MKV get to redesign the format
> > just because you guys disagree with the established design?
> 
> Luckily S_DVBSUB supported has not been implemented or formally
> defined yet. So there is plenty of room for discussion.
> 
> Now one thing you have to know is that in Matroska we remove all
> traces of other containers. Not for fun, but because we only want to
> keep the actual data. A good example is Vorbis which is usually
> handled via an Ogg parser. But we removed that part because it used
> too much space for no real use. In the end readers adapt well. A codec
> should *never* be tied to a particular container (Vorbis is the
> closest to that).
> 
> > I personally think that DVB subtitle packets should be stored in a single
> > MKV track as-is with the CodecPrivate data set to the same data used in the
> > descriptor section of the TS PMT. This will allow applications that already
> > support the TS DVB subtitle format to easily add support for DVB subtitles
> > in MKV because they wont have to do any special parsing other then decoding
> > the CodecPrivate to simulate a TS PMT entry. I think that making it this
> > simple will increase the chances the format will be adopted by standalone
> > players and applications which are not written by the open source community.
> 
> From I read again from the old discussion we had here, the PID is an
> MPEG TS variable. And thus DVBSUB is tightly linked. Imagine you put
> that as-is in Matroska. From what I understand you can have more than
> one "track" inside an DVBSUB packet. How is a regular Matroska player
> supposed to know there are actually plenty of subtitle tracks possible
> within than one S_DVBSUB track ? It could be described in the
> CodecPrivate data, but as the name suggests, the player is not
> supposed to know what's inside these data. So if we kept the packets
> unchanged only one of the many tracks inside that "track" would likely
> be presented to the user. Not a very good idea as it's killing one
> important feature of DVBSUB.
> 
> Also the case of Vorbis described above supported by a lot of hardware
> is a proof by the example that it's not such a big deal in the end.
> 
> > Anyway that's my opinion. If you disagree then I purpose that you add a new
> > format called S_DVBSUB/TS which stores the packets as described above. We'll
> > see which one catches on faster.
> 
> If you're removing the 'many tracks' feature of DVBSUB I doubt it will
> be used much.
> 
> If you want compatibility with existing DVBSUB parsers, I supposed
> "muxing" (or simply adding the extra container bits) would bring back
> that compatibility. And still use Matroska tracks they way they are,
> allowing add/removing other tracks in parallel or just keeping one of
> the tracks that are otherwise forever combined.
> 
> And again, it's to be pedantic or arrogant that we want to do it with
> TrackOperation. In fact it's a lot of work for many of us to add this
> new system in our tools/players. But it's because it's the correct
> long term way of doing it. We try to avoid bad legacy as much as
> possible, that means not going for the quick & easy solution and then
> regretting it later.
> 
> -- 
> Steve Lhomme
> Matroska association Chairman

The PID in TS is basically a track ID. Each TS packet contains a PID as part of it's header so that the demuxer knows which stream the packet belongs to. The Program Map Table, aka PMT, is a special packet inserted several time per second which contains a map of these PIDs and information about the streams they point to. Just like MKV, a TS file can hold pretty much any audio/video format, even if it's unknown to the demuxing application. It does this by using a unique descriptor tag in the PMT and then putting any addition information needed to properly parse the format in to the descriptor buffer, which is basically akin to the the CodecPrivate buffer in MKV. If the demuxer understands the descriptor tag then it parses the associated packets, if not then it ignores them. DVB subtitles are stored in a sort of unique way. If there are multiple subtitle tracks which share data then they are stored in the same PID, but each demuxed data payload contains another header, specific to the DVB subtitle format, which contains a page ID value. This page ID value tells the decoder which sub stream the packet belongs to and the decoder decides whether or not to display it based on the user selection. If the subtitle streams do not share data then they are simply stored as separate PIDs. In the vast majority of situations each subtitle stream is stored in a unique PID and the data stored in the descriptor buffer is mostly unnecessary. However on some occasions there will be two tracks attached to a single PID. This typically happens when there is a normal subtitle track, which only displays spoken words, and another for the hearing impaired which also describes ambient noises like phones ringing, dogs barking, etc... They do this to save space, since the majority of the data is shared (i.e. the spoken words) and only a small subset of the data is specific to the hearing impaired track. The decoder knows which track is selected and displays all packets designated as specific to that track or shared amongst all tracks, the rest are simply ignored.

Now just to be clear I'm not purposing we store any part of the TS packet, or the PES packet, in the MKV container. I'm only suggesting that we store the data payload of the PES packets, which is the DVB subtitle data, in the MKV chunk. I then suggest that we store the data from the TS PMT descriptor buffer, which describes any sub-streams, in the CodecPrivate portion of the track. This way the playing app can simply pass the CodecPrivate portion of the track along to the decoder so that it knows if this particular track contains multiple sub-streams or not. The demuxer itself does not need to know about, or care about, what is stored in the CodecPrivate portion of the track. It is up to the the decoder or playing app to parse that and display the track selection to the user as necessary. And if it's missing or the playing app fails to parse it then the decoder will still default to displaying all common packets and simply ignore those intended for a specific sub-stream. 

Here's the deal... I work as a developer for VideoReDo, a relatively popular video editing application which is specifically designed to edit TV programs. I have already added support for DVB subtitles in MKV using the method I've outlined and it works really well. I've also looked at the source code for VLC and I believe it will be relatively simple to add support for this method there as well. (I actually already wrote the code, but I can't get VLC to build so I haven't been able to test it yet) So basically if you go with my suggestion then there will be at least one app to create these files and one to play them back immediately. Using the TrackOperation method would require changes to the MKV muxers/demuxer in both applications, which I'm not capable of making, and would also require special processing of the DVB subtitle packets themselves during reading/writing which would require additional work to handle in VideoReDo and I'm not sure when/if I'd be able to add support.

I know that the whole sub-stream portion of DVB subs is not congruent with how things are normally done in MKV, but this is a unique case where you'll be supporting an established format in a way that applications designed to handle it will already be setup to understand. In fact I'd argue that using the TrackOperation method is actually worse since it will require the demuxer to recognize the format and recombine the sub-streams back into the established DVB subtitle data format. Where as doing it my way would put that burden on the decoder, which is most likely already designed to handle it.

Dan
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20110217/38a64c43/attachment.html>


More information about the Matroska-devel mailing list