http://home.cs.tum.edu/~siegel/news/2009_11_09-cheese_3.0 see you tomorrow! daniel 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. 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/ -- this mail was sent using 100% recycled electrons ================================================ daniel g. siegel <dgsiegel gnome org> http://home.cs.tum.edu/~siegel 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