[gst-devel] camerabin2 is now on -bad

[Clark, Rob]

On Fri, Dec 10, 2010 at 2:47 AM, Vartiainen Markus.T (Nokia-MS/Tampere) <
markus.t.vartiainen at nokia.com> wrote:

> On 12/08/2010 09:13 PM, ext Thiago Sousa Santos wrote:
> > Hello,
> >
> > for those not on the commits mailing list, camerabin2 prototype is now
> > on the gst-plugins-bad module on Freedesktop (official repository). It
> > is marked as experimental and in order to build it and its tests/example
> > you need to pass '--enable-experimental' to configure.
> >
> > There is still lots of work to do, if you'd like to contribute you can
> > put patches on https://bugzilla.gnome.org/ . In case you don't know
> > exactly what/where to help, ping me (thiagoss) on #gstreamer and I can
> > show a TODO list. The more people we can gather developing it from the
> > start, the better code gets and we make sure it will cover more use
> > cases from different applications.
> >
> > If you prefer to use gitorious, I'll keep my 'work in progress' branch
> > on http://gitorious.org/gstreamer-camerabin2/gst-plugins-bad , so feel
> > free to fork from there and send pull requests. I'll review from there
> > and then push upstream.
> >
> > Regarding the meeting we had yesterday, I've uploaded the logs here:
> > http://people.collabora.co.uk/~thiagoss/camerabin2_20101207.log
> >
> > --
> > Thiago
>
> Hi,
>
> Thanks for this heads-up. The IRC meeting log enlightens nicely the
> context we're talking about, but it also makes it obvious that it is not
> an easy task to respond to all varying needs and hardware/use-case
> combinations.
>
> (Btw, are the actual meeting notes / TODO items available publicly
> somewhere?)
>
> I'll throw some more ingredients into the soup regarding what I
> discussed with Tommi Myöhänen (main contributor to camera source on
> Nokia side).
>
> In camerabin, with the single pad camera source, it has been obvious
> that we can only get either viewfinder frames, video frames or still
> images out of the camera source, one at a time. This imposes some
> limitations, but also provides a simple abstraction of what a camera
> source can provide.
>
> In camerabin2, with the three-pad camera source, it is not obvious any
> more what combinations of simultaneous streams can be expected out from
> the camera source at the same time, and how differently the streams in
> different source pads can be configured, and how much that might affect
> performance. This depends at least to some extent to the capabilities of
> the underlying hardware.
>


I think in image capture mode, the camsrcbin would be expected to push on vf
pad and img pad.  In video capture mode, vf pad and vid pad.  (It would be
nice to somehow, if the camera supports it, have image+video capture mode
where you are pushing on all three pads.)

Internally, within camsrcbin implementation, I think it would be
implementation dependent if you are actually pushing the same captured frame
from the camera on multiple pads (perhaps after a vscale), or if you are
just reconfiguring the camera device and capturing successive frames at
different resolutions.

BR,
-R


>
> At least from the mobile basic camera application point of view, these
> capabilities are directly related to what can be feasibly provided for
> the application user. Some capabilities affect the feature set, while
> some might affect the quality of the features.
>
> Our conclusion was that a way to provide this information to the
> camerabin2 user is necessary.
>
> The questions regarding this, could be:
>
> 1. What are the features that all camera sources are expected to provide
> by default?
>
> 2. What are the optional features that should be reported by the camera
> source?
>
> 3. What is the interface/API/language to access this information?
>
> 4. Whether to provide an extension method for this information, and how
> to implement it?
>
> (5. How much slack we are willing to give in the specification, i.e. how
> much the camerabin2 user "just needs to know" in each case, depending on
> the environment and use-case?)
>
> I'm trying to come up with some of the answers myself, once I learn a
> bit more around the subject.
>
> Regards,
>
>   Markus Vartiainen
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20101210/fea94457/attachment.htm>