Re: cheese three zero

[Filippo Argiolas <fargiolas gnome org>]

On Tue, Oct 20, 2009 at 10:55 PM, daniel g. siegel <dgsiegel gnome org> wrote:
> hello cheese developers, contributors, users and ice cream eaters!
>
> gnome 3.0 is coming nearer and as cheese in its current state isnt that
> customizable or enhancable, we had the thought of doing a cheese three
> zero, which should get our lives easier.
>
> the basic idea is to split cheese into 2 parts:
>
> a) libcheese, which does all the webcam handling, the gstreamer

Not too much to say, obviously I agree (I coauthored the idea, how I
couldn't :P).

Here are some random things that I'd like to address in this designing phase:
- what's our position about GstCameraBin? I expressed some concerns in
the past about it being too high level for our purposes leaving you
little chance to customize the prebuilt pipeline, I don't know if
they've been addressed now but I don't believe so. Anyway, most of my
positions were based on my experiments with a new clutter based
interface, please look at the linked thread[1], maybe you (other
developers) have different concerns/expectations and like camerabin
instead.

- how does the backend interact with the UI?
I'd say everything has to be done async, say the UI requests a photo,
the backend does everything to take it and the signals it (or we pass
a callback in the set_photo method). Same for video recording.

- how does the frontend take the video preview? will we expose a
"give-me-a-window" signal when gstxoverlay wants it?

- do we have any information about possible future users of this
library? What do empathy developers think? Will they use it? Do they
have any particular request? Designing a webcam library for us is one
thing, designing it to be as general purpose as to be used in a video
chat program is quite different IMHO. E.g. a "collaboran"[2] already
said that camerabin isn't probably suited for empathy, maybe our
libcheese won't fit it as well. Knowing it from the start would be
good.

- can we converge about the kind of api we would want *before* writing
the code? it'll probably change during the actual coding work but
would be great to have something to aim to instead of blindly copying
the current code and refactor it later. We have a chance to get this
right right from the start, we can get rid of everything we didn't
like in CheeseWebcam and make it nice and more usable.
I'll try to write down some idea in the wiki as soon as possible.

There are then a couple of things I always wanted to have in
CheeseWebcam but never had the time to implement, there is no strict
need to address these now, but would be probably more difficult to
implement them later:
- PLAYING pipeline relinking via pad blocking. I.e. you can
temporarily block an element pad while the pipeline is PLAYING and
unlink/relink downstream elements while data flow is blocked[3]. This
would allow switching effects without stopping the pipeline.
- Live effects preview. See my clutter experiments [4]. The idea is
that we can have several windows each displaying a tee branch of the
pipeline with a different effect applied. Then those windows can be
turned into several clutter actors or into several GtkDrawingAreas to
display live previews of all the effects. The cpu load can be highly
reduced downscaling and downrating the previews. I'm able to display
up to 9 ximagesink windows (640x480 downscaled to 160x120) each with a
different effectv effect applied with almost no speed loss on a n270
atom netbook.


Ciao,
Filippo


1. http://mail.gnome.org/archives/cheese-list/2009-May/msg00019.html
2. http://www.nabble.com/Camera-pipelines-td26032525.html
3. http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/design/part-block.txt
4. http://cgit.freedesktop.org/~fargiolas/cheese-stage/