[Matroska-devel] S_DVBSUB

Steve Lhomme slhomme at matroska.org
Thu Feb 17 20:54:25 CET 2011

On Wed, Feb 16, 2011 at 10:57 PM, Dan Haddix <dan6992 at hotmail.com> wrote:
> I'm new to this list, and MKV in general, but I've just read the threads
> about how you plan to handle the new S_DVBSUB type and I completely disagree
> with the design. I understand the reasoning behind it, since MKV was not
> designed to hold multiple sub-streams in a single track, but you're
> basically redesigning an established, widely used, standard because it
> doesn't fit into MKVs normal usage. The method you've proposed is going to
> force muxers to parse the real DVB packets into separate tracks for storage
> inside the MKV and then the player/demuxer to recombine those tracks back
> into their original format so that their decoders, which were written to
> handle the packets as they are stored in TS, can properly parse them. This
> seems like a very arrogant way to handle it. The TS format wasn't really
> designed to hold multiple sub-streams on a single PID either, but the DVB
> subtitle format still does it. Why should MKV get to redesign the format
> just because you guys disagree with the established design?

Luckily S_DVBSUB supported has not been implemented or formally
defined yet. So there is plenty of room for discussion.

Now one thing you have to know is that in Matroska we remove all
traces of other containers. Not for fun, but because we only want to
keep the actual data. A good example is Vorbis which is usually
handled via an Ogg parser. But we removed that part because it used
too much space for no real use. In the end readers adapt well. A codec
should *never* be tied to a particular container (Vorbis is the
closest to that).

> I personally think that DVB subtitle packets should be stored in a single
> MKV track as-is with the CodecPrivate data set to the same data used in the
> descriptor section of the TS PMT. This will allow applications that already
> support the TS DVB subtitle format to easily add support for DVB subtitles
> in MKV because they wont have to do any special parsing other then decoding
> the CodecPrivate to simulate a TS PMT entry. I think that making it this
> simple will increase the chances the format will be adopted by standalone
> players and applications which are not written by the open source community.

>From I read again from the old discussion we had here, the PID is an
MPEG TS variable. And thus DVBSUB is tightly linked. Imagine you put
that as-is in Matroska. From what I understand you can have more than
one "track" inside an DVBSUB packet. How is a regular Matroska player
supposed to know there are actually plenty of subtitle tracks possible
within than one S_DVBSUB track ? It could be described in the
CodecPrivate data, but as the name suggests, the player is not
supposed to know what's inside these data. So if we kept the packets
unchanged only one of the many tracks inside that "track" would likely
be presented to the user. Not a very good idea as it's killing one
important feature of DVBSUB.

Also the case of Vorbis described above supported by a lot of hardware
is a proof by the example that it's not such a big deal in the end.

> Anyway that's my opinion. If you disagree then I purpose that you add a new
> format called S_DVBSUB/TS which stores the packets as described above. We'll
> see which one catches on faster.

If you're removing the 'many tracks' feature of DVBSUB I doubt it will
be used much.

If you want compatibility with existing DVBSUB parsers, I supposed
"muxing" (or simply adding the extra container bits) would bring back
that compatibility. And still use Matroska tracks they way they are,
allowing add/removing other tracks in parallel or just keeping one of
the tracks that are otherwise forever combined.

And again, it's to be pedantic or arrogant that we want to do it with
TrackOperation. In fact it's a lot of work for many of us to add this
new system in our tools/players. But it's because it's the correct
long term way of doing it. We try to avoid bad legacy as much as
possible, that means not going for the quick & easy solution and then
regretting it later.

Steve Lhomme
Matroska association Chairman

More information about the Matroska-devel mailing list