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

[ChristianHJW]

"Michael Niedermayer" <michaelni at gmx.at> schrieb im Newsbeitrag
news:200302090030.38845.michaelni at gmx.at...
> 1. matroska is much too complex
> c++ lib

Steve LHomme choose to use C++ because he felt that object based programming
is much better suited to code a container library, plus we wanted something
working fast and Steve was convinced he can code and maintain the code
faster if he used C++.
However, we already were posting a job proposal on sourceforge asking for
people wanting to help with porting the existing EBML code ( matroska
backbone ) to C, and i already have an email from a volunteer, so you may
expect a C version of the library also.
In the meantime i fail to see whats wrong about a C++ library with a C API.
After all we are doing the library to allow easy support of the format, at
least for the basic functions, so why should anybody *using the library*
care what language we were using to make it, other than making a political
question out of this.

> 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.

> i even see SHA1+MD5+RSA+eliptic stuff mentioned?! why?
> i would like to know whats the advantage of using these, it would
certainly
> mean a 5-10x amount of time needed to support these in some simple
> environments (embeded cpus with limited memory & slow cpu & no fpu,
perhaps
> with no available c++ compiler)
> there are many other formats (ogg,mpeg,avi,asf,nut :) ) which dont need
these
> so what can be done so much better with them?

All this stuff is not mandatory, but optional. The MD5 hash of block headers
could be used to 'sign' a file with a unique ID number, ideal to avoid fakes
on p2p networks, if the app developers choose to support this feature ( both
encoder and p2p app ).
Please note that we invested *A LOT OF TIME* into these specs to be able to
cover all potential use for the container.

> it contains fields for forw / bakw reference frames, thats nice, but h264
uses
> more then 2 reference frames, its allso not obvious why the container
format
> needs to store these, i have the feeling that storing b frames in this
will
> be very very complex, i hope iam wrong
> Michael

There were recent changes made to the matroska specs because of excellent
input from Nicolas ( the author of the Rududu wavelet based video codec ) to
the uci-devel list. These changes were not necessary to support today's
MPEG4 implementations, but if you plan to support future codecs like Toby
'GLDM' Hudon's *WARP* codec, that will load up to 256 frames into buffer and
perform a special, biomechanic inspired, wavelet based alog on those you
sure get into trouble with todays usage.

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
to become a replacement for

VOB ( DVD )
WAV/RIFF
AVI

And we are still convinced we did a very good job in balancing out

- compexity
- features
- overhead
- extensability for future use

Sorry if you cant agree on this idea of ours and prefer more 'simple'
containers instead. After all, when reading all the ideas and suggestions
made to this list about your new container, i cant help but get a kind of
'deja vu' effect. Many of the stuff you are talking and discussing about
right now has been talked about more than one year ago .... on the MCF and
later matroska mailing lists.

Regards

ChristianHJW
http://matroska.org