dan6992 at hotmail.com
Wed Feb 16 22:57:25 CET 2011
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?
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Matroska-devel