slhomme at matroska.org
Mon Feb 21 18:48:09 CET 2011
On Mon, Feb 21, 2011 at 7:22 AM, Dan Haddix <dan6992 at hotmail.com> wrote:
> The page ID for the packets wouldn't be stripped, it would simply be reset
> to 1 for all packets. That way there is no need to store the composition or
> ancillary IDs in the MKV container because every packet belonging to a DVB
> subtitle track in MKV would always belong exclusively to that track. And if
So, I don't understand, it's not stripped but there is no need to
store ? To me it's means exactly the same thing, that this
Language+Composition Page ID+Ancillary Page ID are not stored in the
packets as they are already implied.
> you want to start using the TrackOperation method in the future it will
> still be compatible because the page ID for all packets will be 1, and the
> demuxer will intelligently combine the packets from the common track and the
> subtitle track into a single stream which the decoder recognizes exactly the
> same way.
> I think that doing it this way will allow applications to start using the
> duplication method immediately and then in the future add support for the
> TrackOperation method as it's implemented into the muxers/demuxers.
> Do you agree? If so I'll add support for this to VideoReDo right away. I
> also think that adding playback support to VLC would be relatively easy as
> well. All we need to do is make VLC aware of the new format (i.e. S_DVBSUB),
> and set it's internal variables so the composition and ancillary IDs are
> always 1 for MKV DVB subtitle tracks. Everything else should be pretty much
If the decoder is done properly there should be a level that doesn't
deal with this 3 informations and just decode the bitmaps. That's
where the data out of Matroska should go to.
Matroska association Chairman
More information about the Matroska-devel