[gst-devel] possibility to add another source pad to v4l2src
Clark, Rob
rob at ti.com
Wed Jul 14 16:13:57 CEST 2010
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:rob at ti.com]
> 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:rob at ti.com]
>>> 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
>>>> gstreamer-devel at lists.sourceforge.net
>>>> 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
>>> gstreamer-devel at lists.sourceforge.net
>>> 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
>>> gstreamer-devel at lists.sourceforge.net
>>> 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
>> gstreamer-devel at lists.sourceforge.net
>> 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
> gstreamer-devel at lists.sourceforge.net
> 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
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
More information about the gstreamer-devel
mailing list