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

[Enrico Weigelt]

* ChristianHJW <christian at matroska.org> [2003-12-28 10:09:44 +0100]:


<snip>
> This codec is very unusual in his basic functionality and Toby had to 
> fight with a limited codec API to be able to work with it, so you might 
> think that the developer behind it would know how a codec API should be 
> looking like to be future compatible.

So we should ask him, what exactly he needs to get it working.
At a first look, I only see, he needs a really large buffering/read ahead.
The input layer must be aware of this (i.e being able to buffer a large
gap between audio and video playback)

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

Well, I'm working w/ a very old PII / 400 MHz. Mplayer is able to play
many VCDs w/o big trouble on it. I really dont like to miss this.

What you're talking shows the typical argumentation of 'busines' software 
industry: "hardware resources are available and cheap, work is very expensive"
(well, thats why HP was not able to get a cellphone accounting application 
running - they've tried to put millions over millions of records into 
a huge oracle cluster running on 10 huge HP-Netservers ... by thinking
before working, i would have built it on a couple of cheap pizza boxes, 
but for those folks this is to good to be true ... )

<snip>
> 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 .... ??
But we're living _now_ and not in 10 years.
You cant really develop software for computers which do not yet exist.
Maybe someday people will find it good, but today (and also the next 5
years) resources are too limited for that. You cant expect evryone to 
buy new hardware once a year!

And also you should think about embedded platforms. Soon cellphones will
have enough power for playing movies in quite high quality. I would really
like to see the our discussed mm framework running on them. Thats why I
also wanna have support for video conferencing (or the possibility to
use it for that) included.

<snip>
> >This is stupid. You can just wrap the code instead. A basic/dumb
> >filter will be easy to wrap, and a more complicated one will not
> >easily fit into a common api anyway.
> 
> Again the same conflict. In your 'boneheaded' concentration on 
> simplicity and performance, you are prefering to have an API that cant 
> deal with some special filters. For us, a filter API that cant deal with 
> *ANY* possible filter we can think of today, is just crap. If it cant 
_WHAT_ kind of filter are you thinking of ?

> deal with today's filters, how could you expect the API to hold longer 
> than 2 years, with respect to today's development speed ?
Well, where's the problem when a larger API is wrapping around a smaller
one (i.e. mplayer's audio output layer makes use of the OSS-, ALSA- and
the esd api) ?!

<snip>
> 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 ....
5 years are a quite long time ...
Maybe then someone has written a new player, which fully supports it. 
But then this 'future-player' may also easily make use of the work we're
doing now. 

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

I personally want to continue working on such an API, at least for some
parts like audio or video playback. But still I wanna have to focus on 
efficiency and modularity.

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

Well, you're mixing some things, which do not really belong together.
A good API for codecs and IO is (IMHO) necessary for the future. But I
would take directshow as the last candidate.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact at metux.de
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/