Re: gstreamer camerabin

[Filippo Argiolas <fargiolas gnome org>]

2009/4/23 Stefan Kost <ensonic hora-obscura de>:
> I wonder if you had a look at camerabin in gst-plugins-bad. This is
> still beeing worked on mostly by nokia people to be used on the maemo
> platform. The idea is to have a high level image/video capture api.

First of all, let's say I took a quick look and it seems pretty nice.
It would be great to use something like that in cheese so that we
could get rid of some of the messy (IMHO not that much) code in
cheese-webcam.

The thing I don't like that much is that it takes control of
everything, from the v4l source to the videosink, aiming to manage the
whole camera stuff. I would have much more liked a camerasourcebin
with some extended videosaving and photosaving capability but with no
video display feature. As far as I can tell there are a couple of
entry points/properties to insert custom videodisplay and
postprocessing elements but it looses most of gstreamer versatility
this way.

My main concern is that it could collide, at least at a first look,
with my plan about the future cheese.
With the new effect selector/clutter display stuff I'm working on in
the spare time (ever less lately,
http://cgit.freedesktop.org/~fargiolas/cheese-stage/) the pipeline
structure as it is now will be radically changed.
There is some sketch in the TODO file in that repository but it's
quite outdated so let me summarize it quickly.

There will be basically two pipelines that will be dinamically
linked-unlinked to the source bin using pad blocking.
One, the effects preview, will be something like:
videoscale ! videorate ! tee ! filter-1 ! sink-1
                             ! filter-2 ! sink-2
                             ...
                             ! filter-n ! sink-n
This will display several effect previews at the same time. The
downrate and downscale elements will help to remove some load from the
cpu (for old effects) or gpu (for gleffects).
When an effect will be selected sourcebin src pad will be blocked, and
only a single display bin (basically effect + sink) will be relinked.
This way there will be no need to stop, relink, play the whole
pipeline (as we do now) and the whole experience will smoother.

Will this be achievable with camerabin? as far as I can tell, I don't think so.
Correct me if I'm wrong. Development is still at a early stage so it's
better to take a decision *now* about camerabin.

Cheers,
Filippo