[gst-devel] Re: [Matroska-devel] Common Opensource codec API

[ChristianHJW]

Hi again,

this email is the last one that i will x-post to several lists. We set 
up a new ML specifically for the subject of the new media API, email 
adress of the list is

media-api AT lists.matroska.org

For subscription goto http://lists.matroska.org ( mailman ), and 
everybody who is really interested in this subject is invited to do so. 
One of the biggest benefits of this new list is that Mr. Felker will 
hopefully not subscribe to it, so i dont have to read his brainless and 
insulting '... we mplayer devs are the best, all others suck... ' BS.

Marco Gaddoni wrote:
 > mmm ... a programmer not striving for simplicity ....
 > I fear your code.
 > I am unsatisfied with ogm and wanted to give a try
 > to the mkv thing but now i am thinking again.
 > (Has anyone tryed quicktime .mov or mp4 ?)
 > I humbly suggest you (and every other programmer
 > that has not yet done) to read
 >
 > The Practice of Programming
 > by Brian W. Kernighan (Author), Rob Pike (Author)
 > ISBN: 020161586X

Marco,
to make this clear, i am *NOT* a developer myself. I am just a helping 
hand for the matroska team, and i care about the website from time to 
time ( yes, i know it needs an update badly ;-) ). I know i am talking 
with a different language than you developers sometimes, but this is 
simply because i see things with the eyes of the *USER*, and i hope the 
matroska devs will confirm that this is sometimes pretty helpful. After 
all, its the *USERS* who decide if a program is good or bad, not the 
developers making it or the coding style that was used.
About the book you were suggesting, i can tell you that the people 
working in the matroska team are certainly aware of the principles of 
good programming. But, if we have to make a decision between a powerful 
container, feature rich and user friendly, with full unicode support for 
international use, and a poor and simple extension to the current MPEG 
container with low CPU usage, we know what we are going for.
I made a couple of test. I was loading a normal MKV, with one XviD video 
track, one audio track and 2 subtitle tracks, in VirtualdubMod, and 
remuxed it into a new MKV file by leaving away one of the subs tracks. 
This requires a complete demux/mux , as the new file will have a 
different number of tracks and therefore completely new headers, etc. 
Here the result of the tests on my PIII 800 Mhz with a normal SD-RAM :
Muxing Speed : 850 fps
CPU load : ca. 30% ( for both demux and mux with libmatroska in both 
cases, plus editing in VirtualdubMod )
In short, i think its allowed to say that under normal circumstances the 
playback of this file with 25 fps will use less than 1% CPU in any case, 
and this was if 'bloated' libmatroska was used for that. In reality 
there are at least 4 existing faster playback libs now, and 3 of them 
are in C ( soon in FFMPEG ). So, if anybody tells you that matroska is 
bloated and playback is using too much CPU power, tell him to shut up.
For your information, since last week there is an alpha of PocketMVP 
with matroska support, using BBB's C library. So, matroska playback on 
PocketPCs should soon become reality. Any more doubts with respect to 
'performance' ???

Attila Kinali wrote:
 > ROTFL
 > Sorry, but that's just...
 > You may dont know that computer components cost more (2-3 times more)
 > in countries like Turkey than they do here (not to mention that they
 > earn 10 times less). Your comment reminds me Marie Anntoinette's
 > "Why dont they eat cakes if they dont have bread ?". It has the same
 > ignorant and arrogant sound.

Sorry, i didnt mean to sound arrogant, not at all. Just as a quick test, 
i was installing the latest matroska packs on the laptop of my son ( 
PIII 650, 128 MB RAM, 12 GB HDD, 16 MB video ) that i had bought him for 
his learning programs for his 5th b-day ( did cost me 150,- €, used and 
in bad shape, from my company ). I could easily play a MKV file with RV9 
( RealVideo 9 ) in 708 x 432 ( anamorphic ) and HE-AAC. CPU load was 
constantly above 80%, true, but the file played fine. As stated above, 
even PocketPCs can now play MKV files, admittedly using a nice and slim 
C lib and not libmatroska, so what more do you guys want ?

Anyhow, in my original email i wanted to make clear that a common API 
might help to improve development of opensource projects a lot, and this 
means not only players, but also codecs and editors, and the possible 
constraints on performance should be neglectible, and well worth the 
advantages we get.

Again, this was my personal opinion, and everybody sharing it is happily 
invited to continue discussion on the new mailing list mentioned on the 
top of this email.

Best regards

Christian
matroska project admin
http://www.matroska.org