[gst-devel] Re: Common Opensource codec API
christian at matroska.org
Mon Dec 29 11:53:42 CET 2003
D Richard Felker III wrote:
> On Sun, Jun 29, 2003 at 11:36:52PM +0200, Guenter Bartsch wrote:
>>>>I was working with this kind of design before, but
>>>>nobody seemed interested in doing it. Basicly the
>>>>language of the API layer is immaterial, what
>>>>matters is the messages and data getting passed
>>>>through it (my system used a message/struct 2
>>>>parameter function for everything).
>>>So we basically wrap this in CORBA then? ;)
>>*lol* ... yeah, overengineering seems to be quite common in those
>>"do-the-right-thing-fixed-forever-joined-effort" style aproaches :>
> This is beyond just "lol". It's more to the point of "let's commit the
> drone who wrote such madness to an asylum". At the risk of getting
> flamed, may I ask if the person who wrote this was a Matroska
Toby is not a matroska developer. He is the developer of a codec called
WARP ( http://corecodec.org/projects/warp ), and he was not capable of
finishing the codec because he was fighting months with the crappy,
limited and inflexible VfW API.
WARP needs an interface that does allow it to load a big number of
frames into a huge buffer, as the main compression algo of WARP will
work in the time domaine, means on the variation of a single pixel over
a number of frames.
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.
After all, all our discussions are, again and again, basically going
about the same matter :
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.
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 .... ??
>>>Seriously: We need a simple little set of functions that a plugin needs to
>>>implement. If it is not dead simple, nobody will implement it.
>>>That was the important part: If it is not dead simple, nobody will
>>>implement it. And that goes for apps _and_ plugins.
>>my point exactly. this is just about defining simple, easy-to-use apis
>>for various multimedia plugins/modules. i too think we should just
>>define a basic set of functions which each plugin type should support,
>>not more. the api should be extensible, though - both, individual
>>implementations should be able to add fields and functions as well as
>>there should be a possibility to add (probably optional) functions
>>to the api in the future
> 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
deal with today's filters, how could you expect the API to hold longer
than 2 years, with respect to today's development speed ?
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 ....
>>over the weekend i have looked through mplayer g2's and xine's stream/input
>>and demux module apis and found them to be quite similar - it should
>>definitely be possible to define a common interface here. i'm planning
>>to set up a little website documenting the two aproaches, maybe i'll
>>also look at other media players (not sure how many aproaches i'll be
>>able to keep in my mind simultaneously ;) ). hope this will be a good
>>starting point for a common api
> There will be no common api, unless xine wants to adopt mplayer api.
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.
If the mplayer people will not be interested to set up a specific
mailing list for that, we will do so soon.
> 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.
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 . ....
matroska project admin
More information about the gstreamer-devel