[Matroska-devel] Re: format of CodecIDs

DaveEL at leffe.dnsalias.com DaveEL at leffe.dnsalias.com
Wed Oct 1 12:38:36 CEST 2003

> Message: 4
> Date: Tue, 30 Sep 2003 10:56:09 +0200
> From: Moritz Bunkus <moritz at bunkus.org>
> Subject: [Matroska-devel] format of CodecIDs
> To: Matroska devel <matroska-devel at lists.matroska.org>
> Message-ID: <20030930085609.GG13138 at bunkus.org>
> Content-Type: text/plain; charset=us-ascii
> Hi.
> Right now we've reached a critical point in the Matroska development,
> and we need to make a decision about how to store some additional
> information.
> The thing I'm talking about is compression (e.g. zlib compressed
> VobSubs) and encryption (jcsston has just implemented something with AES
> encryption). The problem is that we have to store these facts somehow.
> Here we have two choices:
> 1) Append the information to the CodecID.
> 2) Introduce new track information elements.
> So far I've assumed that we would chose 1) and have acted accordingly
> and introduced S_VOBSUB/ZLIB as the CodecID for compressed
> VobSubs. Please note that NO release of mkvtoolnix so far featured this
> compression, so there are NO files that use this CodecID out in the
> open. Therefore we can still change it.
> The drawback with this CodecID is that I've just appended '/ZLIB' to the
> CodecID. But if we want to do this the right way then we have to
> separate the content type (S_VOBSUB) from the modifications it went
> through (compression with ZLIB). A 'standard CodecID' could look like
> this:
> 1) Track type, followed by an underscore,
> 2) Content type, may be grouped, separator is the forward slash '/',
> 3) Optional flags indicating modifications, separator is some character
> that won't occur otherwise, e.g. the at sign '@'.
> 4) Each flag consists of a descriptor and a value, separated by a colon
> ':'.
> 5) Order of the flags is important. The first flag to occur is the first
> modification used when it was put into the container. Demuxers have to
> apply those counter-modifications from back to front.
> Example:
> Normal VobSubs: S_VOBSUB
> Compressed VobSubs: S_VOBSUB at COMPRESSION:ZLIB
> VobSubs that have been compressed first and then encoded with AES:
> Obvious drawback: The CodecID gets pretty unreadable. And it might not
> be very Matroska-like.
> Second approach: introduce new track info elements. This approach is
> more Matroska-like. Possible names could be KaxContentCompression and
> KaxContentEncryption, each being an unsigned integer.
> As I said: we have to be quick about this! Compressed VobSubs should be
> a reality soon, and we need a concise system by then.
> Thoughts? Other ideas?
> --
>  ==> Ciao, Mosu (Moritz Bunkus)

Ok ive got loads of stuff to do today so i can't type this idea up
correctly so ill just post the irc log. :)

[11:22] <DaveEL> my personal oppinion by using content-coding elements
rather then compression and encryption would be better as long as you can
have multiple content codng elements per stream
[11:23] <MosuAtWork> huh? :)
[11:23] <MosuAtWork> please explain :)
[11:29] <DaveEL> reading mailing list yesterday
[11:30] <DaveEL> about using codec ids like s_vobsub/lzo etc
[11:30] <MosuAtWork> so you propose to have only one new element,
[11:30] <MosuAtWork> which could be added multiple times for different
[11:30] <MosuAtWork> ?
[11:31] <DaveEL> well as long as you can have multiple ordered
[11:31] <DaveEL> yeah
[11:31] <DaveEL> its more general then encription and compression :)
[11:33] <DaveEL> but its just an idea
[11:33] <DaveEL> but that was certainly my first reaction when i read your
post yesterday
[11:34] <MosuAtWork> you can have multiple entities, and the order
definitely can have a significance
[11:34] <MosuAtWork> maybe it'd be better to introduce a new subtree
[11:34] <MosuAtWork> KaxContentCoding
[11:34] <MosuAtWork> \- KaxCodingOrder
[11:34] <MosuAtWork>  + KaxCodingType
[11:34] <MosuAtWork>  + KaxCodingSettings
[11:34] <MosuAtWork> or whatever
[11:35] <MosuAtWork> order being a uint telling when it was used during
[11:35] <MosuAtWork> that would erase any ambiguitiy
[11:35] <MosuAtWork> -i
[11:35] <MosuAtWork> why don't you reply on the ml with your idea? :)


More information about the Matroska-devel mailing list