[Matroska-devel] S_DVBSUB

Dan Haddix dan6992 at hotmail.com
Sat Feb 26 01:21:44 CET 2011


> Date: Fri, 25 Feb 2011 14:15:52 +0100
> Subject: Re: [Matroska-devel] S_DVBSUB
> From: slhomme at matroska.org
> To: dan6992 at hotmail.com
> CC: matroska-devel at lists.matroska.org; andreas at lonelycoder.com
> 
> On Thu, Feb 24, 2011 at 12:02 AM, Dan Haddix <dan6992 at hotmail.com> wrote:
> > The page ID of the segments have to match either the composition or
> > ancillary ID set for the track or the decoder will ignore them. Some
> > decoders may have the ability to be set to a "decode all" mode and ignore
> > the page ID, but there is no standard way of doing that so I'm not sure we
> > can depend on it always being available in every application. Plus we also
> > have to think about applications, like VideoReDo, which have the ability to
> > convert from MKV to TS. A TS file needs to have the proper composition and
> > ancillary IDs stored in it's PMT. If we don't reset the page IDs of every
> > segment to a static, known, value or store the original composition and
> > ancillary IDs in the MKV somewhere then we'd have to scan the entire file
> > checking every segment just to determine the proper values. That is far from
> > ideal.
> >
> > Maybe we should just go back to my original idea of storing the original PMT
> > data in CodecPrivate. If the playing app knows how to read that then it can,
> > if not then it can just set it's DVB subtitle decoder to "decode all" and it
> > will still work. That way we don't have to mess with the page ID in the
> > original segments and we'll have the proper composition and ancillary IDs
> > available for applications that want to convert to TS.
> 
> Yes, that won't hurt much and if some decoders need it, then it's there.
> 
> -- 
> Steve Lhomme
> Matroska association Chairman

OK so the only stipulation I would have is that if the muxer is not going to store composition and ancillary IDs in CodecPrivate then they MUST reset the page ID on all segments to a single known value. (0 would be OK) That way programs that need those values can default to known value if the CodecPrivate data does not exist.

Also are we agreed that the CodecPrivate will contain data in the same format as the descriptor data from the TS PMT? It has the following format...

ISO_639_language_code - 24 bits
subtitling_type                - 8 bits
composition_page_id      - 16 bits
ancillary_page_id           - 16 bits

Normally this is stored as an array for each substream, but since we're only allowing a single stream to be stored in each MKV track we could stipulate that the CodecPrivate can only contain these 8 bytes. 

Dan
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.matroska.org/pipermail/matroska-devel/attachments/20110226/3283eeb7/attachment.html>


More information about the Matroska-devel mailing list