GStreamer bindings landed in CVS



Aloha,

I added GStreamer bindings to our CVS repository.  They live in
gtk2-perl-xs/GStreamer.  They require HEAD of Glib for a patch I
committed a few minutes ago.  I'd love it if everybody interested would
try them out and report any and all issues back to me or the list.

The bindings are supposed to work with every 0.8.x release of GStreamer,
but I only tested it with 0.8.9 -- so if you see any compilation or test
failures with another 0.8.x version, please report that too.

Most of the base GStreamer stuff is wrapped.  All examples from the
manual[1] also work in Perl.  (See GStreamer/examples/manual.)  There
are still some issues, though:

* Much of the stuff that uses 64bit integers doesn't work as expected.
This seems to be a general problem with our bindings.  We use the T_IV
typemap for the 64bit types (gin64 and guint64), but at least on my
system, this typemap doesn't provide enough storage to hold 64bit values
(it seems to use simple long's here).  As a workaround I locally changed
the typemap to be T_NV, which strictly speaking is not really correct
but seems to work nevertheless since it uses 64 bits to store the value.

* Things that use GStreamer::Buffer and GStreamer::Data are still a bit
fragile, mostly because this is a very binding-unfriendly type.  See for
example the fakesrc.pl example.  The window is supposed to blink black
and white.

* The usual function <-> method issue.  Everything in GStreamer::Format
and GStreamer::Query is currently wrapped as functions, but you could
also argue that those things work on a global object and should thus be
class static methods.  Then there are GStreamer::Structure::from_string
and GStreamer::Structure::to_string and the equivalents in the
GStreamer::Caps namespace.  The former two are wrapped as functions
mainly because GStreamer::Structure's are simple, unblessed hash
references.  The latter two are wrapped as methods; $caps->to_string()
just plain makes sense, and GStreamer::Caps->from_string(...) looks a
lot like a constructor which we always wrap as a class static method.
Obviously, these four shouldn't have different semantics.  And lastly
there's GStreamer::Parse::launch which looks a lot like a helper
function but also has properties of a constructor (it's wrapped as a
function currently).

* Quite a bit of API is not wrapped yet (a TODO file will follow soon).

* Finally, I don't know how to handle doc generation for all the
plugins.  They are proper GObject's which means our doc tools can very
well generate fine documentation for them (including signals,
properties, and the hierarchy), but for that to work, a Perl wrapper
would have to be specified for every single plugin (in the maps file)
and the corresponding header would have to be included in gst2perl.h.
That's a) a lot of work and b) not really guaranteed to work everywhere
since not all plugins are present on every system.

Any help and/or advice on any of those points is of course highly
appreciated.  Now, go and have some fun with GStreamer. :-)

-- 
Bye,
-Torsten

[1]
http://gstreamer.freedesktop.org/data/doc/gstreamer/stable/manual/html/index.html




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]