GStreamer-devel

possibility to add another source pad to v4l2src

Classic

List

Threaded

8 messages Options

Hu, Gang A

possibility to add another source pad to v4l2src

Hi,

In my platform, there are two data streams from the camera, one(/dev/video0) is for view finder and the other(/dev/video1) is for image and video capture.

My original design is to use a modified v4l2src and add one source pad tor v4l2src to support dual stream support. V4l2src read data from /dev/video0 and /dev/video1 and push the data stream to source pad0 and source pad1.

As V4l2src is inherited from pushsrc, and there is only one source pad in v4l2src, is it possible to add the other source pad without modifying the pushsrc? What should I take care if I need to design that way? How to set the getrange function for the new added source pad?

Many thanks.

Best Regards!

Hu Gang

Kapil Agrawal

Re: possibility to add another source pad to v4l2src

Hello,

If I am right there is only one srcpad that can be created by elements using pushsrc baseclass. There could be 2 ways of having 2 srcpads,
1) Create a Capture bin with 2 v4l2src elements (Better option)
2) Rewrite the v4l2src element to not use pushsrc (not suggested)

Not sure if there are more options.

Regards
kapil

On Sun, Jul 11, 2010 at 11:25 AM, Hu, Gang A <gang.a.hu@intel.com> wrote:

Hi,

In my platform, there are two data streams from the camera, one(/dev/video0) is for view finder and the other(/dev/video1) is for image and video capture.

My original design is to use a modified v4l2src and add one source pad tor v4l2src to support dual stream support. V4l2src read data from /dev/video0 and /dev/video1 and push the data stream to source pad0 and source pad1.

As V4l2src is inherited from pushsrc, and there is only one source pad in v4l2src, is it possible to add the other source pad without modifying the pushsrc? What should I take care if I need to design that way? How to set the getrange function for the new added source pad?

Many thanks.

Best Regards!

Hu Gang

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

--
www.mediamagictechnologies.com (Gstreamer, ffmpeg, Red5, Streaming)
twitter handle: @gst_kaps
http://www.linkedin.com/in/kapilagrawal

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Clark, Rob

Re: possibility to add another source pad to v4l2src

In reply to this post by Hu, Gang A

fyi, you might want to have a look at:

http://gstreamer.freedesktop.org/wiki/CameraBin

I am in the process of refactoring camerabin to look more like this, so you could (for example) have a separate viewfinder port and capture port.. I have it working basically as the "future" picture on that wiki page looks, at least for video capture. A bit needs to be done still for image capture, and some cleanup is still needed.

It doesn't quite help for what you want to do with v4l2src, but you could perhaps instead create a camsrc bin element containing multiple v4l2src elements and some glue logic to coordinate between them.. I think camerabin provides a better, higher level abstraction for applications to target for SoC's with advanced ISP's, compared to using v4l2src directly.

BR,
-R

On Jul 11, 2010, at 12:55 AM, Hu, Gang A wrote:

> Hi,
> In my platform, there are two data streams from the camera, one(/dev/video0) is for view finder and the other(/dev/video1) is for image and video capture.
> My original design is to use a modified v4l2src and add one source pad tor v4l2src to support dual stream support. V4l2src read data from /dev/video0 and /dev/video1 and push the data stream to source pad0 and source pad1.
> As V4l2src is inherited from pushsrc, and there is only one source pad in v4l2src, is it possible to add the other source pad without modifying the pushsrc? What should I take care if I need to design that way? How to set the getrange function for the new added source pad?
> Many thanks.
>
> Best Regards!
> Hu Gang
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Hu, Gang A

Re: possibility to add another source pad to v4l2src

Hi, Rob
Thanks for your suggestion. It looks much easier to support dual stream in camerasrcbin. I plan to design the dual stream support like this.
+-------------------------------------------------------------------------------------------------+
| +------------------+ +----------------------+ Camerasrcbin |
| | v4l2camsrc | | other elements | |
|sink src--- sink src--------------------------------------->vfsrc
| +------------------+ +----------------------+ |
| +--------------+ |
| +------------------+ +----------------------+ | Tee | |
| | v4l2camsrc | | other elements | | tee_image--->image_src
|sink src-----sink src-------sink | |
| +------------------+ +----------------------+ +------------tee_video---->vidoe_src
| |
+--------------------------------------------------------------------------------------------------+
The first pipeline is for view finder and read data from /dev/vidoe0. The second pipeline is for image and video capture. It read data from /dev/video1.
Is it possible to implement this design in camerabin?
Thanks.

-----Original Message-----
From: Rob Clark [mailto:[hidden email]]
Sent: Monday, July 12, 2010 5:14 AM
To: Discussion of the development of GStreamer
Subject: Re: [gst-devel] possibility to add another source pad to v4l2src

fyi, you might want to have a look at:

http://gstreamer.freedesktop.org/wiki/CameraBin

I am in the process of refactoring camerabin to look more like this, so you could (for example) have a separate viewfinder port and capture port.. I have it working basically as the "future" picture on that wiki page looks, at least for video capture. A bit needs to be done still for image capture, and some cleanup is still needed.

It doesn't quite help for what you want to do with v4l2src, but you could perhaps instead create a camsrc bin element containing multiple v4l2src elements and some glue logic to coordinate between them.. I think camerabin provides a better, higher level abstraction for applications to target for SoC's with advanced ISP's, compared to using v4l2src directly.

BR,
-R

On Jul 11, 2010, at 12:55 AM, Hu, Gang A wrote:

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Stefan Sauer

Re: possibility to add another source pad to v4l2src

On 12.07.2010 05:40, Hu, Gang A wrote:

> Hi, Rob
> Thanks for your suggestion. It looks much easier to support dual stream in camerasrcbin. I plan to design the dual stream support like this.
> +-------------------------------------------------------------------------------------------------+
> | +------------------+ +----------------------+ Camerasrcbin |
> | | v4l2camsrc | | other elements | |
> |sink src--- sink src--------------------------------------->vfsrc
> | +------------------+ +----------------------+ |
> | +--------------+ |
> | +------------------+ +----------------------+ | Tee | |
> | | v4l2camsrc | | other elements | | tee_image--->image_src
> |sink src-----sink src-------sink | |
> | +------------------+ +----------------------+ +------------tee_video---->vidoe_src
> | |
> +--------------------------------------------------------------------------------------------------+
> The first pipeline is for view finder and read data from /dev/vidoe0. The second pipeline is for image and video capture. It read data from /dev/video1.
> Is it possible to implement this design in camerabin?
> Thanks.
>

Thats the goal of the refactoring rob pointed out. Support more complex
source. Feedback on his branches are very welcome. Regarding your
camersrc, you can't easily subclass from pushsrc anymore, but you will
need to copy the implementation from there. Then you can either start
one task for each src-pad or use one task to drive all pads (for the
later you need to use an fdset to poll on multiple descriptors).

Stefan

> -----Original Message-----
> From: Rob Clark [mailto:[hidden email]]
> Sent: Monday, July 12, 2010 5:14 AM
> To: Discussion of the development of GStreamer
> Subject: Re: [gst-devel] possibility to add another source pad to v4l2src
>
> fyi, you might want to have a look at:
>
> http://gstreamer.freedesktop.org/wiki/CameraBin
>
> I am in the process of refactoring camerabin to look more like this, so you could (for example) have a separate viewfinder port and capture port.. I have it working basically as the "future" picture on that wiki page looks, at least for video capture. A bit needs to be done still for image capture, and some cleanup is still needed.
>
> It doesn't quite help for what you want to do with v4l2src, but you could perhaps instead create a camsrc bin element containing multiple v4l2src elements and some glue logic to coordinate between them.. I think camerabin provides a better, higher level abstraction for applications to target for SoC's with advanced ISP's, compared to using v4l2src directly.
>
> BR,
> -R
>
> On Jul 11, 2010, at 12:55 AM, Hu, Gang A wrote:
>
>
>> Hi,
>> In my platform, there are two data streams from the camera, one(/dev/video0) is for view finder and the other(/dev/video1) is for image and video capture.
>> My original design is to use a modified v4l2src and add one source pad tor v4l2src to support dual stream support. V4l2src read data from /dev/video0 and /dev/video1 and push the data stream to source pad0 and source pad1.
>> As V4l2src is inherited from pushsrc, and there is only one source pad in v4l2src, is it possible to add the other source pad without modifying the pushsrc? What should I take care if I need to design that way? How to set the getrange function for the new added source pad?
>> Many thanks.
>>
>> Best Regards!
>> Hu Gang
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>

Clark, Rob

Re: possibility to add another source pad to v4l2src

On Jul 12, 2010, at 7:11 AM, Stefan Kost wrote:

> On 12.07.2010 05:40, Hu, Gang A wrote:
>> Hi, Rob
>> Thanks for your suggestion. It looks much easier to support dual stream in camerasrcbin. I plan to design the dual stream support like this.
>> +-------------------------------------------------------------------------------------------------+
>> | +------------------+ +----------------------+ Camerasrcbin |
>> | | v4l2camsrc | | other elements | |
>> |sink src--- sink src--------------------------------------->vfsrc
>> | +------------------+ +----------------------+ |
>> | +--------------+ |
>> | +------------------+ +----------------------+ | Tee | |
>> | | v4l2camsrc | | other elements | | tee_image--->image_src
>> |sink src-----sink src-------sink | |
>> | +------------------+ +----------------------+ +------------tee_video---->vidoe_src
>> | |
>> +--------------------------------------------------------------------------------------------------+
>> The first pipeline is for view finder and read data from /dev/vidoe0. The second pipeline is for image and video capture. It read data from /dev/video1.
>> Is it possible to implement this design in camerabin?
>> Thanks.
>>
>
> Thats the goal of the refactoring rob pointed out. Support more complex
> source. Feedback on his branches are very welcome. Regarding your
> camersrc, you can't easily subclass from pushsrc anymore, but you will
> need to copy the implementation from there. Then you can either start
> one task for each src-pad or use one task to drive all pads (for the
> later you need to use an fdset to poll on multiple descriptors).

I guess I should point out that my branch can be found here:

http://gitorious.org/robclark-gstreamer/gst-plugins-bad/commits/camerabin-cleanup

:-)

-----

btw, about subclassing pushsrc for multiple src pads.. I suppose it is actually possible, so long as it is ok to couple reading from the different camera srcs. You're one create() method could read and push as many buffers it wants, but you loose the functionality of the base classes to create and manage the extra src pads. And if you will be getting buffers at different framerates from the different v4l2 devices, it isn't a good idea.. in that scenario it would be better to have a different task per v4l2 device.

BR,
-R

>
> Stefan
>
>> -----Original Message-----
>> From: Rob Clark [mailto:[hidden email]]
>> Sent: Monday, July 12, 2010 5:14 AM
>> To: Discussion of the development of GStreamer
>> Subject: Re: [gst-devel] possibility to add another source pad to v4l2src
>>
>> fyi, you might want to have a look at:
>>
>> http://gstreamer.freedesktop.org/wiki/CameraBin
>>
>> I am in the process of refactoring camerabin to look more like this, so you could (for example) have a separate viewfinder port and capture port.. I have it working basically as the "future" picture on that wiki page looks, at least for video capture. A bit needs to be done still for image capture, and some cleanup is still needed.
>>
>> It doesn't quite help for what you want to do with v4l2src, but you could perhaps instead create a camsrc bin element containing multiple v4l2src elements and some glue logic to coordinate between them.. I think camerabin provides a better, higher level abstraction for applications to target for SoC's with advanced ISP's, compared to using v4l2src directly.
>>
>> BR,
>> -R
>>
>> On Jul 11, 2010, at 12:55 AM, Hu, Gang A wrote:
>>
>>
>>> Hi,
>>> In my platform, there are two data streams from the camera, one(/dev/video0) is for view finder and the other(/dev/video1) is for image and video capture.
>>> My original design is to use a modified v4l2src and add one source pad tor v4l2src to support dual stream support. V4l2src read data from /dev/video0 and /dev/video1 and push the data stream to source pad0 and source pad1.
>>> As V4l2src is inherited from pushsrc, and there is only one source pad in v4l2src, is it possible to add the other source pad without modifying the pushsrc? What should I take care if I need to design that way? How to set the getrange function for the new added source pad?
>>> Many thanks.
>>>
>>> Best Regards!
>>> Hu Gang
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Sprint
>>> What will you do first with EVO, the first 4G phone?
>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________
>>> gstreamer-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

Hu, Gang A

Re: possibility to add another source pad to v4l2src

Hi, Rob
Thanks for your sharing. What is the status of the refactoring of camerabin? Is it very close to http://gstreamer.freedesktop.org/wiki/CameraBin ?
Do you have any plan to add the dual stream support to camerabin?
Thanks.

-----Original Message-----
From: Rob Clark [mailto:[hidden email]]
Sent: Monday, July 12, 2010 8:41 PM
To: Discussion of the development of GStreamer
Subject: Re: [gst-devel] possibility to add another source pad to v4l2src

On Jul 12, 2010, at 7:11 AM, Stefan Kost wrote:

Clark, Rob

Re: possibility to add another source pad to v4l2src

On Jul 14, 2010, at 4:31 AM, Hu, Gang A wrote:

> Hi, Rob
> Thanks for your sharing. What is the status of the refactoring of camerabin? Is it very close to http://gstreamer.freedesktop.org/wiki/CameraBin ?
> Do you have any plan to add the dual stream support to camerabin?
> Thanks.

status is that it works for video encode pipelines.. a bit more work is needed for image capture pipelines. And some cleanups here and there and lots of testing are needed.

The base camsrc class is to the point where you could subclass it and begin implementing your dual stream camera element.. I'm not planning to do this. I'm just planning to implement support for normal "legacy" v4l2src, and for our own OMX based (multi-src) camera.

BR,
-R

>
> -----Original Message-----
> From: Rob Clark [mailto:[hidden email]]
> Sent: Monday, July 12, 2010 8:41 PM
> To: Discussion of the development of GStreamer
> Subject: Re: [gst-devel] possibility to add another source pad to v4l2src
>
>
> On Jul 12, 2010, at 7:11 AM, Stefan Kost wrote:
>
>> On 12.07.2010 05:40, Hu, Gang A wrote:
>>> Hi, Rob
>>> Thanks for your suggestion. It looks much easier to support dual stream in camerasrcbin. I plan to design the dual stream support like this.
>>> +-------------------------------------------------------------------------------------------------+
>>> | +------------------+ +----------------------+ Camerasrcbin |
>>> | | v4l2camsrc | | other elements | |
>>> |sink src--- sink src--------------------------------------->vfsrc
>>> | +------------------+ +----------------------+ |
>>> | +--------------+ |
>>> | +------------------+ +----------------------+ | Tee | |
>>> | | v4l2camsrc | | other elements | | tee_image--->image_src
>>> |sink src-----sink src-------sink | |
>>> | +------------------+ +----------------------+ +------------tee_video---->vidoe_src
>>> | |
>>> +--------------------------------------------------------------------------------------------------+
>>> The first pipeline is for view finder and read data from /dev/vidoe0. The second pipeline is for image and video capture. It read data from /dev/video1.
>>> Is it possible to implement this design in camerabin?
>>> Thanks.
>>>
>>
>> Thats the goal of the refactoring rob pointed out. Support more complex
>> source. Feedback on his branches are very welcome. Regarding your
>> camersrc, you can't easily subclass from pushsrc anymore, but you will
>> need to copy the implementation from there. Then you can either start
>> one task for each src-pad or use one task to drive all pads (for the
>> later you need to use an fdset to poll on multiple descriptors).
>
>
> I guess I should point out that my branch can be found here:
>
> http://gitorious.org/robclark-gstreamer/gst-plugins-bad/commits/camerabin-cleanup
>
> :-)
>
>
> -----
>
> btw, about subclassing pushsrc for multiple src pads.. I suppose it is actually possible, so long as it is ok to couple reading from the different camera srcs. You're one create() method could read and push as many buffers it wants, but you loose the functionality of the base classes to create and manage the extra src pads. And if you will be getting buffers at different framerates from the different v4l2 devices, it isn't a good idea.. in that scenario it would be better to have a different task per v4l2 device.
>
>
> BR,
> -R
>
>
>>
>> Stefan
>>
>>> -----Original Message-----
>>> From: Rob Clark [mailto:[hidden email]]
>>> Sent: Monday, July 12, 2010 5:14 AM
>>> To: Discussion of the development of GStreamer
>>> Subject: Re: [gst-devel] possibility to add another source pad to v4l2src
>>>
>>> fyi, you might want to have a look at:
>>>
>>> http://gstreamer.freedesktop.org/wiki/CameraBin
>>>
>>> I am in the process of refactoring camerabin to look more like this, so you could (for example) have a separate viewfinder port and capture port.. I have it working basically as the "future" picture on that wiki page looks, at least for video capture. A bit needs to be done still for image capture, and some cleanup is still needed.
>>>
>>> It doesn't quite help for what you want to do with v4l2src, but you could perhaps instead create a camsrc bin element containing multiple v4l2src elements and some glue logic to coordinate between them.. I think camerabin provides a better, higher level abstraction for applications to target for SoC's with advanced ISP's, compared to using v4l2src directly.
>>>
>>> BR,
>>> -R
>>>
>>> On Jul 11, 2010, at 12:55 AM, Hu, Gang A wrote:
>>>
>>>
>>>> Hi,
>>>> In my platform, there are two data streams from the camera, one(/dev/video0) is for view finder and the other(/dev/video1) is for image and video capture.
>>>> My original design is to use a modified v4l2src and add one source pad tor v4l2src to support dual stream support. V4l2src read data from /dev/video0 and /dev/video1 and push the data stream to source pad0 and source pad1.
>>>> As V4l2src is inherited from pushsrc, and there is only one source pad in v4l2src, is it possible to add the other source pad without modifying the pushsrc? What should I take care if I need to design that way? How to set the getrange function for the new added source pad?
>>>> Many thanks.
>>>>
>>>> Best Regards!
>>>> Hu Gang
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> This SF.net email is sponsored by Sprint
>>>> What will you do first with EVO, the first 4G phone?
>>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________
>>>> gstreamer-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Sprint
>>> What will you do first with EVO, the first 4G phone?
>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by Sprint
>>> What will you do first with EVO, the first 4G phone?
>>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>>> _______________________________________________
>>> gstreamer-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> gstreamer-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel