[Matroska-devel] S_DVBSUB

Steve Lhomme slhomme at matroska.org
Sat Feb 26 08:43:45 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.

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.

Steve Lhomme
Matroska association Chairman

More information about the Matroska-devel mailing list