[MPlayer-dev-eng] Re: Common Opensource codec API

[Attila Kinali]

On Sun, 28 Dec 2003 10:09:44 +0100
ChristianHJW <christian at matroska.org> wrote:


> You guys always want to keep things extremely simple and performant, and 
> i have no idea why that is. Maybe you cant afford new PCs with 
> state-of-the-art CPUs, and are running your boxes on AMD K6's or 
> similar, dont know. I have a pretty old Pentium III system, only 800 
> MHz, with a 32 MB 4xAGP videocard, and even with crappy, bloated Windows 
> + plus even more bloated, even more crappier matroska i was never ever 
> close to have CPU performance problems. So, there seems to be a clear 
> conflict of interests, for whatever reason.

ROTFL

Sorry, but that's just...
You know, a program needs to run as fast as possible, no matter what
it does, otherwise we end up waiting for the computer and justify
Wirth's law ("programs slow down faster than computers get faster").
Beside, not everyone has the money to buy a top computer like you do.
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.

> matroska people are primarily not interested in the performance of our 
> code, not at all. We are thinking 10 years ahead, and compared to the 
> necessary decoding power to play a HDTV ( 1280 x 960 ) h.264 ( AVC, 
> MPEG4-10 ) video, the CPU cycles you will need to parse a matroska file 
> or to use a CORBA wrapped codec API, will just be peanuts, so why should 
> we care at all .... ??

Yes, we also design for the future, but keep in mind that the time
for THz processors hasn't yet come. A good engineer always gets
the best performance out of a machine without sacrifizing functionality,
but at the same time he doesnt overcomplicate things just because
it might be usefull in an unknown future.


 
> I cant get rid of my impression that at least *some* devs here are so 
> proud they finally understood how MPEG works ( i dont ;-) ), they are 
> now much too focussed on the MPEG way and how things are generally done 
> today. You may call matroska bloated and non-performant. Well, maybe 
> thats the case. However, i promise you matroska will be still here in 5 
> years, it will be looking completely different than today as we had to 
> adapt it to the needs of tomorrow, but all old files will still be 100% 
> compatible thanks to the very flexible ( = bloated, in your opinion ) 
> underlying EBML structure. We'll see ....

Ok, just have a look a the code (i hope you can read code)
demux_avi.c is around 850 lines of code and contains everything
needed for avi demuxing.
demux_mkv.c is over 3100 lines of code, which are mostly hard to understand
(IMHO) and is only a wrapper for the matroska libs which themself contain
again about 10k lines of code. I know, mkvs functionality is much higher
than avis, but imho it doesnt justify 13k lines of code (in comparison to
this, demux_nut.c from G2 is just 500 loc and has about the same functionality)
and a 1:3 ratio of loc in the libs and corresbonding code in the program itself
is for me sign that something fundamental went wrong. Maybe someone (with
the heart of an engineer) should write a pure c implementation of your 
libs to see whether it's the design of mkv or just the libs.

 
> Fortunately, you are not the one deciding this. I am glad the discussion 
> was started again, mainly with respect to Atilla's planned video 
> developer meeting in Switzerland next year. I sincerely hope that the 
> conversation about a new API will not stop, and that we can move things 
> forward until then.

Just go on...
 

> > Common api means the EXACT same thing as a common player. If mplayer
> > and xine are using the same stream layer, the same demuxer layer, the
> > same codec and filter layer, and the same output modules, then the
> > ONLY difference between the two is the 10 lines of wrapper code in
> > main.c to put it all together. This is beyond idiotic. MPlayer is
> > better than the stupid windows crap because it _doesn't_ just wrap
> > DirectShow with gui widgets, but instead implements everything itself,
> > and does so much more efficiently and more correctly. 
> > Rich
> 
> Yes, maybe. So finally Linux players could start to improve and try to 
> offer all the functionalities that are standard in the Windows world 
> since ages. Why that is ? Because the main playback function, however 
> crappy and bloated it is implemented, is done nicely by DirectShow and 
> player developers can concentrate on improving the user interface and 
> add more features, like live capturing, playlists, timeshifting, remote 
> control, etc . ....

Then why do more and more windows user use mplayer eventhough there
is no nice gui available on windows ? 


				Attila Kinali
-- 
egp ist vergleichbar mit einem ikea bausatz fuer flugzeugtraeger
			-- reeler in +kaosu