slhomme at matroska.org
Sun Feb 20 09:54:50 CET 2011
On Sat, Feb 19, 2011 at 10:50 PM, Dan Haddix <dan6992 at hotmail.com> wrote:
> OK so the PMT entry for each PID has attached to it an array which describes
> the language, composition page ID and ancillary page ID for each of the
> sub-streams. So a PID with multiple sub-streams might look something like
> Language = English
> Composition Page ID = 1
> Ancillary Page ID = 3
> Language = English for hearing impaired
> Composition Page ID = 2
> Ancillary Page ID = 3
> When each packet comes along it carries just a single page ID value. If the
> page ID for the packet is 3 then it would be displayed if either sub-stream
> was selected. If the page ID was either 1 or 2 then it would only be
> displayed if that specific sub-stream was selected. Typically how this is
> used is that the majority of data is stored with a page ID 3. Only packets
> which need to be displayed differently for either sub-stream are stored with
> page IDs of 1 or 2. In most cases the hearing impaired track would simply
> carry extra captions, aimed for display in a separate area, to describe
> noises that are displayed at the same time as the common packets. However on
> occasion both tracks will require the display of the same text in slightly
> different ways so they will each have their own packet for that specific
OK, so the packets are not combined together. That's the one case
Matroska cannot handle at the container level.
> As you can see by the design separating these into MKV tracks isn't really
> easy because the common data doesn't really belong to either track. And if
> somehow it was removed it would make the other two tracks useless.
Correct. This would be the case for now as tool usually don't support
TrackOperation yet. Although that would be the long term clean way to
handle it. The 'common' track would be marked as disabled, but could
still be 'pulled' when selecting one of the tracks that depend on it.
> After thinking about it more I think the best way to do this is to copy the
> common data to both tracks and then reset the page ID for each packet to a
> single value. That way the MKV container does not need to have a concept of
> composition and ancillary page IDs, we can just assume that both are always
> set to 1, and each sub-stream can be represented in the MKV as a separate
> track which is completely independent of any other tracks.
I suppose that could be another proper way to do it. There would be a
lot of data copied but at least its remuxing safe.
> With that approach storing DVB subs in an MKV would still be relatively
> simple for the output application, only requiring minor parsing to reset the
> page ID and copy the data to all tracks, and reading them would be
> completely transparent to the player/demuxer. We wouldn't even need any
> CodecPrivate data.
Not sure if you imply that the page ID is stripped from the packets,
but that should be the case. If the decoder on platform X insists on
having such ideas for decoding it's very easy to add a fake one back
out of the demuxer.
So are we all clear now ?
In both ways (double common data & TrackOperation) S_DVBSUB would work
exactly the same and should be stored the same way. Not need for the
PMT data and the Page ID in the packets header.
Matroska association Chairman
More information about the Matroska-devel