[matroska-devel] Re: Matroska Tags

Pamel Paul at msn.com
Fri Apr 11 04:57:12 CEST 2003


"Steve Lhomme" <steve.lhomme at free.fr> wrote
> BTW, what do you call MultiEntity ?

Your MultiEntity element in the specs.

> I agree with most of the tags (now we have to define where and how they
> will go).

I'm currently making up an excel spreadsheet that lists all of the elements
that will need to be created.  There will be a lot (I am guessing <50).  I
think we should make a link to a seperate web page to list all of the tags
with full descriptions.  Some of the descriptions are really vague on the
other specs pages, so it was difficult to tell what they were talking about.

I was thinking about listing most of the elements as UTF-8.  I was also
thinking about storing the URL's as UTF-8 as eventually they are going to
start using non-ascii charaters in DNS entries.  Two articles from slashdot
are here:
http://www.theregister.co.uk/content/6/29058.html
http://fr.news.yahoo.com/030201/35/30bn2.html (in french)
http://developers.slashdot.org/article.pl?sid=03/02/02/066207&mode=thread&ti
d=95

But this would only be an option if all URL entries in Matroska went to
UTF-8.  Otherwise I obviously have to stick with string.

> Also you said that each element could have a name, URL, comment, etc ? So
the
> idea it to create a matroska specific type (like UInteger, UnicodeString,
etc).
> That will be used internally by matroska-aware softwares... That is
necessary
> not to define 3xNumber of elements Matroska IDs. Instead you define an ID
for
> each of your element and it's defined as binary from an EBML point of
view. Then
> the binary inside could/should also be in EBML format :
[ID][length][data]. Then
> you define an internal ID for : URL, Name, Comment, UInteger value, etc.
You
> will save space in the file and in the specs :) And become more
extensible, more
> consistent in the code, etc... That's an object-oriented approach to the
problem :D

Adding an element to contain EBML'd data?  That sounds like it would just be
adding another layer of abstraction for the data, without adding any
features.  You might as well just have them in the main tree.  Sticking them
together in their own 'thing' would separate them from the main specs.  You
could even branch them off into their own project, ala ID3. I think this
would be bad though, and we all know how much I like having things modular.
Its just asking for more bloat.

I'll do my best to keep the total number of new elements to a minimum, but
don't expect the number of supported tags to drop.


Pamel



http://www.matroska.org



More information about the Matroska-devel mailing list