[gst-devel] camerabin2 is now on -bad

[Vartiainen Markus.T (Nokia-MS/Tampere)]

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.

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