[gst-devel] Re: libvisual / GStreamer

[Dennis Smit]

(CC me, i'm not on the list)


> For the rest:
> Libvisual takes audio data and produces data in the desired format using
> any visualization plugin it supports (or combinations thereof). This is
> done by having 3 types of plugins: input (for getting audio data), actors
> (the visualizations) and video (for doing transforms of the video, like
> colorspace transforms, centering, fading from one visualization to
> another...)

The (not yet online) newer version of libvisual has 3 types of plugins,
being input (with support for an in app callback function when you
don't want to load an actual plugin), The Actor (the visual plugin) and 
Morph plugins (Transistion from one actor to another).

Video help is done within the libvisual core, the reason why i provide
depth transformation routines is because i, in the end want libvisual to
provide an image in nearly any case. This to make it incredible simple
for the application developer, however fine grained access to the
libvisual elements is also provided ofcourse.


> The point here is that GStreamer does input and video plugins itself
> (colorspace and audio input are certainly far better in gst than in
> libvisual), so I've just wrapped the actors, since it's all that we need.
> But it might be quite a bit more complicated to do some things, 

Without doubt the colorspace and audio stuff is way better than within
libvisual.

> like setup
> a smooth transform from one visualization to another (you'd need to setup
> the pipeline yourself where you do this - would look something like audio
> ! tee ! vis1 ! colorspace ! merge  tee0. ! vis2 ! colorspace ! merge0. )
> which is apparently not just as easy as calling 2 functions or so on
> libvisual.

I'm not really very familair with gstreamer internals but, is it
possible to notify an element of things, WHILE the pipe runs. In that
case you could create an 'managed' bin, extract the input and set
an load callback and let libvisual manage it's own stuff. When you've
done this you could notify the gst-libvisual element with something
like "switch actor", "oinksie" where libvisual calls 
visual_switch_actor_by_name (bin, name);

Remember that libvisual in very early stage of development, and i'll
willing to do things differently when they should done so (and i agree).

> OTOH libvisual builds pipelines internally so all it does is really
> nothing more than could be done by writing a special visualization element
> for GStreamer.

With the local stuff i've got here it's possible to let libvisual manage
it pipe but still access every element within the pipe.

> Maybe it's an idea to do 2 things: a) wrap the actors and b) wrap the
> whole libvisual thing, so you can chose between fine-grained control and
> just using the big blob.
> I'm not sure really. It would have been much easier had you just written a
> fancy GSTreamer element in the first place ;)

Yeah well, i don't want to just support gstreamer :), i want to support
everyone, but when you encounter problems, contact me and i'll be very
willingly to look into them, investigate them and if needed change
libvisual or add things to libvisual to suite you guys better.

Keep in mind that my motivation behind libvisual is to set a framework
where everyone can easily get access to visualisation plugins and every
visaul writter doesn't have to hack support for a dozen players. To keep
this really going we need some sort of standard and gstreamer supporting
libvisual instead of just the actors really helps regarding this :).

Remember that the snapshots you've been working against are already
outdated, i'll be putting up new snapshots next week!

Cheers, and thanks for your interest in libvisual in the first
place!