[Matroska-devel] S_DVBSUB

Dan Haddix dan6992 at hotmail.com
Sat Feb 26 10:32:01 CET 2011


> Date: Sat, 26 Feb 2011 08:43:45 +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 Sat, Feb 26, 2011 at 1:21 AM, Dan Haddix <dan6992 at hotmail.com> wrote:
> >> 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.
> 
> I'm not sure we should allow both. If some players need the info, at
> muxing time you have no way to know and should not restrict the plyer
> use, especially if the Codec ID is the same. So I think it should
> always be there.
> 
> > 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.
> 
> Correct
> -- 
> Steve Lhomme
> Matroska association Chairman

OK I think we have a plan. I'm going to lay it out one more time just for posterity... 

If a DVB subtitle stream contains more then one substream then the muxer must separate each substream into individual MKV tracks. This can be done by either... a) creating a copy of each segment who's page ID corresponds to either the composition or the ancillary ID of the substream to that track or b) using the TrackOperation tag to create a virtual track which automatically combines segments from two other tracks which contain the ancillary data and the composition data respectively.

In addition each MKV track will contain 8 bytes of CodecPrivate data which will contain the following information...

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

No default values are assumed for these variables so if the CodecPrivate data is missing, or malformed, then the track will be treated as invalid and rejected by the player/demuxer.

If that sounds right then I will add support to VRD for the next release. I can also help add playback support to VLC. Although I can't currently build VLC so someone else will need to build the changes and test them out. Any volunteers?

Now that we're done with this do we want to discuss how best to store 608/708 captions and Teletext? :)

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


More information about the Matroska-devel mailing list