[gst-devel] Fwd: Re: [UCI-Devel] Re: Common Opensource codec API

[Toby Hudon]

----- Original Message -----
From: Ronald Bultje <rbultje at ronald.bitfreak.net>
Date: 30 Jun 2003 23:17:44 +0200 
To: Toby Hudon <gldm at mail.com>
Subject: Re: [gst-devel] Fwd: Re: [UCI-Devel] Re: Common Opensource codec API

> But that's the whole issue, the messages. You're just moving the problem
> over from linkage space to message space. The problem here is actually
> to define how all this works. ;).
>

Well it's got to be somewhere. There's obviously a fairly big number of things to do, get frames, configure things, get keyframes, etc. It's got to be somewhere, and I figured defined message constants are easier to type than function calls and their parameters without errors. Also if we're going to assume that for simplicity not everyone will have to implement every possible function, what happens when an app calls a function that a component doesn't support? Does the system bomb or what? With the message system the caller just looks at the return value to know what's going on, there's no chance of hitting a function without a definition.

Unless you expect people to have say, 200 functions most of which are empty... that seems kinda redundant to me when a switch's default case is alot cleaner and has the same effect.
 
> Funnily, you're taking XVID as an example, but xvid is horrible. Look at
> the API. There's one struct per message. No extendibility. No
> configurability. Perfect for a one-task API, but not at all usable for a
> generic API.
> 

Sorry I just picked a codec name at random, I haven't looked at their API that much but from what I've seen trying to write my VFW code based on theirs it's most likely a mess as you say.

> GStreamer (GObject)'s way of defining all this is easier. Make
> name/value pairs, make a standard doc that describes which types support
> what base properties. Since there's no limit on name/value pairs,
> there's no limit in extendibility. Making this two-way allows the
> application to view these properties, too.
> And, even better, this method doesn't depend on GStreamer or GObject at
> all. GStreamer just implements it in that specific way.
> 

Never seen it, or even heard of it for that matter. What do you mean by name/value pairs, you mean just variables? How is this better or different than what I was talking about? You'd still need to define a standard doc (i.e. a bunch of constants defined for messages and their data structs/docs), and as for what supports what you find out when you try to pass a message, if it returns 0 it's unsupported. You as the caller get the job of handling it if that's a problem.

> The good thing of your approach is actually its simplicity, and I like
> that. However, I wouldn't vote for sticking to one function, since that
> only moves the definition problem over from linkage space to message
> space, and that has no advantage, imho. However, the idea of using as
> little functions as possible up to a certain amount sounds good, I'll
> try sticking to that. :).
> 

Well I could see segregating different types of operations into different functions, such as the linking of dynamic libraries, and I've already said that'd probably want to be seperate. But for the actual video processing itself, why would you put it in multiple functions? Since filters, codecs, etc all have similar needs, doesn't it make more sense for them to just be able to pick and choose from the defined operations instead of forcing them to implmement functions they might not need? I still don't know what happens when you call a function that isn't there, can you please tell me? I haven't tried this but I'd suspect it isn't pretty.

> > If you have a simpler idea please let me know, and BTW what is 
> > CORBA?
> 
> Something like COM, but for Unix/Linux.
> 

What's COM?

-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup