Re: GStreamer Elements

[Murray Cumming <murrayc murrayc com>]

On Sun, 2008-03-02 at 09:25 +0100, Milosz Derezynski wrote:
> Hi All,
> 
> With GStreamermm progressing, we need to look at how to access
> individual elements in a C++-ish fashion.
> I'll make a small introduction into the topic here:
> 
> GStreamer is based on a plugin based architecture, this means that it
> in itself is only a framework, and individual plugins exist which
> range from source elements (which provide data to be decoded) to
> decoders, demuxers, processors, and output plugins. GST terminology
> calls these "elements".
> 
> Elements can have a lot of signals and properties, which are simply
> GLib signals and GLib object properties and are important for coding
> with GStreamer (they can not just be ignored for gstmm).
> 
> How i thought of accessing them is using a code generator: It would
> scan the relevant element and generate a shallow wrapper class e.g.
> GstElementFilesrc ( : public GstElement ) with the relevant properties
> and signals present; this could then be added to the project's code
> and used to access this element.

This seems like the best way to make that API available. It's awkward,
but people have lived with the same idea with CORBA and COM until now.
Other languages such as Python can create API dynamically at runtime,
but I'd rather have the compile-time type-safety of C++ than that
strangeness.

However, I think it would be sensible to find out how other gstreamer
language bindings deal with this.

> Firstly it might seem problematic to do this, namely, to create code
> with a generator on the developer's computer, and then distribute this
> code with the entire source package, but, in practice, there seems to
> be no problem:
> 
> - GStreamer never creates backwards incompatibility in elements with
> progressing version numbers; if anything then a new element is created
> instead which is incompatible (e.g. decodebin2 for incompatible
> decodebin changes)
> 
> - If an element will not wrap correctly into the generated code then
> it would be also incompatible using the C interface, just that the C
> interface is much more lax (g_signal_connect failing with g_warnings,
> g_object_set/get as well), but either way the program wouldn't be
> guaranteed anymore to run correctly, hence using a precreated wrapper
> class for C++ doesn't really make a difference in this regard; if
> anything then we have stricter checking whether the user's installed
> system will be compatible with the program
> 
> The code for this generator could be based on gst-inspect, which
> prints the properties, signals and other information about elements
> through inspection.
> 
> Comments are welcome :)

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com