[Matroska-devel] S_DVBSUB

Andreas Öman andreas at lonelycoder.com
Sat Feb 26 12:48:23 CET 2011


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.
>
> 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
>

Makes sense but I guess it would be preferred if applications also sets the
normal track language tag?
Also, which one should take precedence if they differ during demuxing? I
would expect that the native matroska tag is preferred in those cases?


>
> 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/3d0408c7/attachment.html>


More information about the Matroska-devel mailing list