[Matroska-devel] S_DVBSUB

Dan Haddix dan6992 at hotmail.com
Tue Feb 22 12:46:01 CET 2011


> Date: Tue, 22 Feb 2011 09:21:22 +0100
> Subject: Re: [Matroska-devel] S_DVBSUB
> From: slhomme at matroska.org
> To: dan6992 at hotmail.com; matroska-devel at lists.matroska.org
> 
> On Mon, Feb 21, 2011 at 10:51 PM, Dan Haddix <dan6992 at hotmail.com> wrote:
> > You can't just strip the page ID. It's part of a header which also contains
> > information such as the color pallet and region, which are vital for proper
> > display of the bitmap data. Resetting the page ID to 1 basically makes all
> > the packets in a given track appear to the decoder as if they are part of
> > the common stream which in turn means they will be displayed. This is how
> > DVB subtitle streams which do not have sub-streams are stored in TS, with
> > all packets set to page ID 1. So all we're doing here is saying that MKV
> > does not support sub-streams in a single track and forcing the muxer to
> > separate the sub-streams into distinct tracks. (or use TrackOperation to
> > make them appear as if they are all part of a distinct track) Basically
> > we're eliminating the need for the equivalent of a PMT in MKV, but leaving
> > the DVB subtitle packets intact so that they wont require special processing
> > by the playing application to decode them.
> >
> > I really think this is the best way to handle it. If we start stripping
> > headers to save a few bits we're just going to make it harder for the
> > demuxer/player to decode the subtitles. I think we should just stick with
> > the packet format outlined by the specification so that we can make
> > implementation of the format as simple as possible for everyone.
> 
> If it's the first 4 bytes it could be done. Otherwise header stripping
> can just kick in in advanced muxers as well. So OK, let's just go with
> keeping these data in the Blocks.
> 
> Does it mean we don't need any Codec Private (as Andreas asked) ?
> 
> -- 
> Steve Lhomme
> Matroska association Chairman

With this system we will not need any CodecPrivate data. As long as we agree that an MKV track can only contain a single sub-stream, and that every packet in that stream will have it's page ID reset to 1, then the playing application will not need any additional information to decode the subtitles. (a language code and display name are usually associated with each sub-stream as well, but I assume that can be stored in the MKV track data)

I don't think that header stripping is very practical with DVB subtitle packets. DVB subtitle packets do not contain a single header right at the start that is used for the entire packet. In fact DVB subtitle packets aren't really packets at all, they are an array of "segments" each having it's own header. This header includes some redundant information, like the page ID, but it also contains information which is specific to each segment such as the segment type and segment length. The page ID is right in the middle of this header and would be difficult to strip without upsetting the other variables. Plus doing this would mean that the demuxer would then need to reapply the page ID during output or the stream would not make sense to the DVB decoder. This would put an extra, unnecessary, burden on the player/demuxer just to save a few KB per hour of video. I think we should just keep it simple and store the packets as-is so that the whole process is completely transparent to the player/demuxer. By doing this we will make it easier to implement and increase it's chances for adoption into more players.

Dan
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20110222/7d30a5ff/attachment.html>


More information about the Matroska-devel mailing list