Multimedia Frameworks (was Re: aRts documentation)

[Tim Jansen]

On Tuesday 22 October 2002 21:00, Zack Rusin wrote:
> b) Tim, is the inability to write plugins with your GStreamer wrappers
> their biggest shortcoming? (as I don't think it's such a huge problem)

Yes, it's the biggest problem. In order to create GStreamer objects you would 
need to be able to implement GObjects... Therefore I ommitted classes that 
are not used by 'regular' apps, like GstBuffer.

Smaller problems are:
- dparams (Dynamic parameter) are not implemented. I hesitated to implement 
them, because the API was (and still is?) not stable
- GStreamer plugins/elements can define their own signals and emit them. These 
signals are regular C callbacks. I have only wrapped the signals of the 
common elements. But if you want to implement the signal of a plugin, you 
need to create a function or static class method that handles this callback 
with its raw (C API) arguments and wrap them yourself. Usually not a big 
deal: just use QGst::Element::wrap() to convert a C GstObject in a C++ 
QGst::Element. But when you do this you are exposed to the raw C API
- there is no KIO input/output element. The only file I/O elements are the 
filesrc/-sink (supports only local files) and gnomevfssrc/-sink (requires 
Gnome and supports fewer protocols than KIO). Using NetAccess for large media 
files is not a good idea, so a KIO I/O element for GStreamer is desirable
- it's possible that I missed a few of the newer GStreamer API functions, and 
I ommitted a number of GObject functions that I didn't need. It's no big deal 
to add them though

bye...