[Matroska-devel] Re: Re: EBML

[Paul Bryson]

I was writing this originally and stopped most of the way through to take a
shower.  When I got back my system was locked and I had to reboot.  So if some
of the ideas seem short, that is why.

"Martin Nilsson" wrote...
> What I do like to see is a reduced library dependency. To completely
> support matroska I would have to support RSA and ECDSA. SHA1 and MD5.

These are all part of the Signature and are there only to verify data integrity.
There definately isn't any requirement to have this in a lib as you don't need
to use it to decode any of the data.  Regardless, it was removed for the version
1.0 specs.  It is not used yet, and can definately be reworked.

> z-compression, bz-compression and lzo-compression. DES, 3DES, Twofish,
> Blowfish and AES. To name a few standards.

This is a little bit different and shouldn't be a library dependancy anyway.
The way that this should work is through a plugin system that allows chaining.
For example, you COULD have an MPEG-4 stream that was compressed with ZLIB, then
encrypted with AES, and then compressed with LZO1x.  On playback, the data would
be decompressed, decrypted, and then decompressed again before being handed to
the MPEG-4 decoder.  While there are different reasons to use the generic
compression methods, one of the only reasons to use encryption is for DRM.  And
because DRM will likely never be added directly in the lib, a plugin system
NEEDS to be developed so that a new plugin could be added, independantly of the
lib so that new DRM methods can be used.

Because (to my knowledge) this system has never been developed, deciding on how
exactly to handle it in the lib has been slow.  But it is obvious it needs to be
plugin based.

> I don't think there is something wrong with deciding for the user in
> some of these issues. AES is proven better than the other cipher
> algorithms. SHA1 is proven better than MD5. The NIST reports are there
> for everyone to read, so there is really no technical reason to allow
> all of these algorithms.

Its all about options.  When deciding which compression method would be best for
storing VobSubs, Mosu tested not only the encoding and decoding speed of
different libraries, but also how well they handled errors.  Even if a method is
technically better, existing libraries my make a different method more
practical.  And as time progresses, the options change.  So, instead we leave
the options up to developers for what to use.  Matroska is a general purpose
container.  The idea is that if two people store the same type of data in
Matroska, they should both be able to decode each others work.  We don't define
WHAT to store in it, but rather HOW to store it.

An excellent example can be seen from looking at current Matroska files in the
wild.  The majority of them use RV9 video with AC3 and Vorbis audio, as well as
UTF-8 subtitles.  There is no way that we could have predicted that RV9 would
have become one of the most popular choices.  If we had limited it, then we
would have missed this boost in popularity as well as our goals to be a general
container that can store anything.

> Similarly when something can be normalized into one unit or format I
> think it should. Why allow for DisplayUnit to be both centimeters and
> inches? Inch is _defined_ in centimeters.

Yes, storing the exact same data in two different formats is pretty redundant.
However, since the Height and Width are both u-integer, perhaps a finer unit of
measurement should be used?  Maybe millimeter?

> Or why have support for five
> different subtitle formats when two would be enough; One format which
> the textual formats could be normalized into (EBML based?) and one
> bitmap format (perhaps based on PNG with alpha channels?). I realize
> that this is something that must have been up for discussion (sorry, I
> have not had the time to read up in the list archive either), but I'll
> just use these specific examples to back my general suggestion: reduce
> dependencies, e.g. by disallowing things and normalizing data.

Limiting the number of subtitle formats definately wouldn't decrease the size of
the lib.  Subtitles are just another generic form of data in Matroska.  The same
as Video and Audio.  Its all generic.  Matroska doesn't care what it is, it
depends on whatever system is being used to decode the data in the proper way.

On a different note, PNG would be very desireable with its 255 levels of alpha.
Current systems are not strong enough to be depended on to decode PNG subtitles
without causing a pause in the video.  But, in the next couple of years this
could become a real possibility.  Jory has already designed a PNG video codec
that supports RGB, YUV, and YV12, so we know it is possible.

> The
> smaller libmatroska gets the less you'll have to pay for your
> matroska-aware DVD-player.

I agree.  But remember, that DVD players will never be able to handle most
Matroska files that are already out there.  I am pretty sure that no DVD player
will ever play back RV9 or RV10.  Also, it is not likely that any will ever
provide full UTF-8 support as the full Arial font is around 20MB.  The things
that DVD players might possibly support are MPEG-1/2/4 in Matroska with VobSub
subtitles, as well as Matroska audio-only files using formats that they already
support.


Pamel