Re: cheese three zero

see you tomorrow!


On So, 2009-10-25 at 08:05 +0100, Filippo Argiolas wrote:
> 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.
> 2.
> 3.
> 4.

this mail was sent using 100% recycled electrons
daniel g. siegel <dgsiegel gnome org>
gnupg key id: 0x6EEC9E62
fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62
encrypted email preferred

Attachment: signature.asc
Description: This is a digitally signed message part

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