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

[D Richard Felker III]

On Sun, Dec 28, 2003 at 10:09:44AM +0100, ChristianHJW wrote:
> 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
> >developer?
> 
> 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.

None of this has anything to do with the API. Ultimately, all codecs
already have a common api consisting of a single function that takes
encoded data as an argument and returns a decoded frame (or vice versa
for an encoder). No XML/CORBA/hell required.

For initial development, your friend can just allocate all the buffers
he needs himself, and export the pointers to the next output frame to
the calling program. Later on, he'd be advised to extend his code to
allow the caller to provide the buffers via a callback function (see
libavcodec get_buffer). Or, if he's really incompetent when it comes
to performance (sounds that way) he should just write a slow reference
implementation, and let the ffmpeg team write a proper, fast
implementation once the codec has proven itself with respect to
performance.

The rest of your post, as usual, was too idiotic to even deserve a
reply. It's pure trolling. Please leave this list, forever. I'll
recommend a ban from the list if you don't get lost willingly -- it's
annoying when MPlayer devs waste their time responding to your piles
of shit.

Rich