[Matroska-devel] Re: DRAFT: new elements for compression/encryption

Pamel paul at msn.com
Fri Oct 17 01:18:36 CEST 2003


"Moritz Bunkus" <moritz at bunkus.org> wrote...
> KaxContentEncoding: A master containing the aforementioned children. Can
> be used multiple times. Order is important! The order in which the
> multiple KaxContentEncoding elements are stored in the file is the same
> order that the data manipulation has been done during encoding/muxing,
> so a decoder/demuxer would have to reverse this order.

Bad!  Order sensetive data is a nono in EBML.  In theory you should be able to
reorganize randomized elements into a 'normal' file.  An easy way to do this
would be to add another element for priority.   KaxContentEncodingPriority
maybe?  The first KaxContentEncoding that you make will have a priority of 0,
next would be 1, then 2, etc.  Then when go to playback, you just start at the
highest priority.

> * KaxContentEncodingType: Tells the kind of modification
> done. Predefined values:
> 0 - compression
> 1 - encryption
> Default value is 0.

Maybe instead use:
0 - none
1 - compression
2 - encryption
Default value is 0.

> For compression:
> 0 - zlib (each frame's contents were compressed with the zlib library)
> 1 - bzlib (each frame's contents were compressed with the zlib library)
>
> For encryption:
> 0 - ... (not yet specified; possible algorithms include DES, 3DES, AES,
> ElGammal...)
>
> Default value is 0.

Again, wouldn't 0 be 'none' ?

> * KaxContentEncodingScope: Tell whether the frame contents, the track's
> private data or both have been modified in this way.
> 0 - only the frame contents
> 1 - only the track's private data
> 2 - both
> Default value is 0.

I like that, its clever.  I can imagine that people would just start using one
all of the time, but this saves us the trouble of deciding which that would be.

> * KaxContentEncodingSettings: Additional information for the method
> used. Could be the ID of the key used in an asymmetric encryption method
> (aka. public key cryptography).

Some thought will need to be put into this, but not right now, as long as the
element is defined.  Before defining exactly how this element is defined you
should probably talk to someone experienced in cryptography and DRM.

> Please send comments/suggestions as soon as possible - I'd like to make
> this permanent this weekend!

It looks pretty solid to me with the exception of the 'order sensitive
elements'.


Pamel






More information about the Matroska-devel mailing list