[MPlayer-dev-eng] Re: Re: [MPlayer-users] Re: lavc-Options for*BEST*

[Michael Niedermayer]

Hi

On Sunday 09 February 2003 07:04, ChristianHJW wrote:
> "Michael Niedermayer" <michaelni at gmx.at> schrieb im Newsbeitrag
> news:200302090030.38845.michaelni at gmx.at...
> > xml whatever?!
> > float types?!
>
> EBML is a binary form of XML, and the main idea was brought up in a
> discussion between Steve and Frank Klemm, the author of MPC ( musepack )
> audio codec, and certainly one of the brightest people in the whole
> multimedia development scene. You will maybe have to invest more than just
> one minute to fully understand the beauty of using it ( as i am not a coder
> i am still struggling BTW ;) ), but pls. believe that many other developers
> we talked to had the very same objections in the beginning, but changed
> their mind after having talked to us.
>
> The EBML structure is offering similar possibilities than the 'atoms' in
> Mp4/Mov do offer. Allthough we are lucky to have codec developers being
> subscribed to our lists and we get a lot of precious input about the
> requirements for a container for the needs of tomorrows codecs, we still
> dont know what the future will bring. EBML gives us the extensability to
> add more elements to the container, without breaking backwards
> compatibility.
hmm, thats all nice but what is the advantage to store keys in the format, in 
addition to values?!, the order uniquely identifies which value is which (in 
all other formats). i dont want to mention the complexity caused by the fact 
that demuxers need to be able to parse that stuff which could be encoded in 
any order

if u now say its extendible then thats surely correct but that isnt the 
question, the question is why a simple format which can be extended by adding 
new packets or append more fields at the end of packets is not enough

[...]

>
> We want this container to last for 10 years. We dont want something 'nice
> and easy' as a quick temporary solution, until the next bad hackery has to
> be done, like what happened to AVI. After all i still dont understand what
> the benefit of having an 'easy' container is. You as a developer may be
> impressed by a container being 'easy' = 'less complex' = 'elegant to code'
> , but what are the users gaining by using it ? Do they have any benefits by
> using such a container, when compared to matroska ? Our container is trying
yes, if we remove all features which are useless (storing keys for values 
/EBML/XML, c++, floats, frame reference info, ...) and remove all features 
which can be added easily later (chapters/multiangle/interactivity stuff...) 
then we have a simpler format -> easy to implement, less bugs, sooner 
finished, ...)

[...]

Michael