camerabin2 is now on -bad

[Thiago Sousa Santos]

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


------------------------------------------------------------------------------
This SF Dev2Dev email is sponsored by:

WikiLeaks The End of the Free Internet
http://p.sf.net/sfu/therealnews-com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[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

------------------------------------------------------------------------------
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Clark, Rob]

On Fri, Dec 10, 2010 at 2:47 AM, Vartiainen Markus.T (Nokia-MS/Tampere) <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel