* Omap3 ISP + Gstreamer v4l2src
@ 2011-12-07 8:02 Adam Pledger
2011-12-07 10:34 ` Laurent Pinchart
2011-12-08 21:27 ` Sakari Ailus
0 siblings, 2 replies; 6+ messages in thread
From: Adam Pledger @ 2011-12-07 8:02 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linux-media
Hi Laurent,
Firstly, please accept my apologies, for what is very probably a naive
question. I'm new to V4L2 and am just getting to grips with how things work.
I'm using a tvp5151 in bt656 mode with the Omap3 ISP, as described in
this thread (Your YUV support tree + some patches for bt656, based on
2.6.39):
http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/39539
I am able to capture some frames using yavta, using the media-ctl
configuration as follows:
media-ctl -v -r -l '"tvp5150 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3
ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'
media-ctl -v --set-format '"tvp5150 3-005d":0 [UYVY2X8 720x625]'
media-ctl -v --set-format '"OMAP3 ISP CCDC":0 [UYVY2X8 720x625]'
media-ctl -v --set-format '"OMAP3 ISP CCDC":1 [UYVY2X8 720x625]'
This yields this:
Opening media device /dev/media0
Enumerating entities
Found 16 entities
Enumerating pads and links
Media controller API version 0.0.0
Media device information
------------------------
driver omap3isp
model TI OMAP3 ISP
serial
bus info
hw revision 0x0
driver version 0.0.0
Device topology
- entity 1: OMAP3 ISP CCP2 (2 pads, 2 links)
type V4L2 subdev subtype Unknown
device node name /dev/v4l-subdev0
pad0: Sink [SGRBG10 4096x4096]
<- "OMAP3 ISP CCP2 input":0 []
pad1: Source [SGRBG10 4096x4096]
-> "OMAP3 ISP CCDC":0 []
- entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link)
type Node subtype V4L
device node name /dev/video0
pad0: Source
-> "OMAP3 ISP CCP2":0 []
- entity 3: OMAP3 ISP CSI2a (2 pads, 2 links)
type V4L2 subdev subtype Unknown
device node name /dev/v4l-subdev1
pad0: Sink [SGRBG10 4096x4096]
pad1: Source [SGRBG10 4096x4096]
-> "OMAP3 ISP CSI2a output":0 []
-> "OMAP3 ISP CCDC":0 []
- entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link)
type Node subtype V4L
device node name /dev/video1
pad0: Sink
<- "OMAP3 ISP CSI2a":1 []
- entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
type V4L2 subdev subtype Unknown
device node name /dev/v4l-subdev2
pad0: Sink [UYVY2X8 720x625]
<- "OMAP3 ISP CCP2":1 []
<- "OMAP3 ISP CSI2a":1 []
<- "tvp5150 3-005d":0 [ENABLED]
pad1: Source [UYVY2X8 720x625]
-> "OMAP3 ISP CCDC output":0 [ENABLED]
-> "OMAP3 ISP resizer":0 []
pad2: Source [UYVY2X8 720x624]
-> "OMAP3 ISP preview":0 []
-> "OMAP3 ISP AEWB":0 [ENABLED,IMMUTABLE]
-> "OMAP3 ISP AF":0 [ENABLED,IMMUTABLE]
-> "OMAP3 ISP histogram":0 [ENABLED,IMMUTABLE]
- entity 6: OMAP3 ISP CCDC output (1 pad, 1 link)
type Node subtype V4L
device node name /dev/video2
pad0: Sink
<- "OMAP3 ISP CCDC":1 [ENABLED]
- entity 7: OMAP3 ISP preview (2 pads, 4 links)
type V4L2 subdev subtype Unknown
device node name /dev/v4l-subdev3
pad0: Sink [SGRBG10 4096x4096 (8,4)/4082x4088]
<- "OMAP3 ISP CCDC":2 []
<- "OMAP3 ISP preview input":0 []
pad1: Source [YUYV 4082x4088]
-> "OMAP3 ISP preview output":0 []
-> "OMAP3 ISP resizer":0 []
- entity 8: OMAP3 ISP preview input (1 pad, 1 link)
type Node subtype V4L
device node name /dev/video3
pad0: Source
-> "OMAP3 ISP preview":0 []
- entity 9: OMAP3 ISP preview output (1 pad, 1 link)
type Node subtype V4L
device node name /dev/video4
pad0: Sink
<- "OMAP3 ISP preview":1 []
- entity 10: OMAP3 ISP resizer (2 pads, 4 links)
type V4L2 subdev subtype Unknown
device node name /dev/v4l-subdev4
pad0: Sink [YUYV 4095x4095 (0,6)/4094x4082]
<- "OMAP3 ISP CCDC":1 []
<- "OMAP3 ISP preview":1 []
<- "OMAP3 ISP resizer input":0 []
pad1: Source [YUYV 3312x4095]
-> "OMAP3 ISP resizer output":0 []
- entity 11: OMAP3 ISP resizer input (1 pad, 1 link)
type Node subtype V4L
device node name /dev/video5
pad0: Source
-> "OMAP3 ISP resizer":0 []
- entity 12: OMAP3 ISP resizer output (1 pad, 1 link)
type Node subtype V4L
device node name /dev/video6
pad0: Sink
<- "OMAP3 ISP resizer":1 []
- entity 13: OMAP3 ISP AEWB (1 pad, 1 link)
type V4L2 subdev subtype Unknown
device node name /dev/v4l-subdev5
pad0: Sink
<- "OMAP3 ISP CCDC":2 [ENABLED,IMMUTABLE]
- entity 14: OMAP3 ISP AF (1 pad, 1 link)
type V4L2 subdev subtype Unknown
device node name /dev/v4l-subdev6
pad0: Sink
<- "OMAP3 ISP CCDC":2 [ENABLED,IMMUTABLE]
- entity 15: OMAP3 ISP histogram (1 pad, 1 link)
type V4L2 subdev subtype Unknown
device node name /dev/v4l-subdev7
pad0: Sink
<- "OMAP3 ISP CCDC":2 [ENABLED,IMMUTABLE]
- entity 16: tvp5150 3-005d (1 pad, 1 link)
type V4L2 subdev subtype Unknown
device node name /dev/v4l-subdev8
pad0: Source [UYVY2X8 720x625]
-> "OMAP3 ISP CCDC":0 [ENABLED]
The following works nicely:
yavta -f UYVY -s 720x625 -n 4 --capture=4 -F /dev/video2
The problem comes when I try to use gstreamer to capture from
/dev/video2, using the following:
gst-launch v4l2src device="/dev/video2" !
'video/x-raw-yuv,width=720,height=625' ! filesink location=sample.yuv
This fails with:
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed
getting controls attributes on device '/dev/video2'.
Additional debug info:
v4l2_calls.c(267): gst_v4l2_fill_lists ():
/GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
Failed querying control 9963776 on device '/dev/video2'. (25 -
Inappropriate ioctl for device)
My question is, should this "just work"? It was my understanding that
once the pipeline was configured with media-ctl then the CCDC output pad
should behave like a standard V4L2 device node.
I realise that this might be something borked with my build dependencies
(although I'm pretty certain that v4l2src is being built against the
latest libv42) or gstreamer. Before I start digging through the code to
work out what is going on with the ioctl handling, I thought I would
check to see whether this should work, or whether I am doing something
fundamentally silly.
Many Thanks,
Adam
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Omap3 ISP + Gstreamer v4l2src
2011-12-07 8:02 Omap3 ISP + Gstreamer v4l2src Adam Pledger
@ 2011-12-07 10:34 ` Laurent Pinchart
2011-12-07 11:01 ` Michael Jones
2011-12-08 21:27 ` Sakari Ailus
1 sibling, 1 reply; 6+ messages in thread
From: Laurent Pinchart @ 2011-12-07 10:34 UTC (permalink / raw)
To: Adam Pledger; +Cc: linux-media
Hi Adam,
On Wednesday 07 December 2011 09:02:42 Adam Pledger wrote:
> Hi Laurent,
>
> Firstly, please accept my apologies, for what is very probably a naive
> question. I'm new to V4L2 and am just getting to grips with how things
> work.
No worries.
> I'm using a tvp5151 in bt656 mode with the Omap3 ISP,
Please note that BT.656 support is still experimental, so issues are not
unexpected.
> as described in this thread (Your YUV support tree + some patches for bt656,
> based on 2.6.39):
> http://comments.gmane.org/gmane.linux.drivers.video-input-
infrastructure/39539
>
> I am able to capture some frames using yavta, using the media-ctl
> configuration as follows:
> media-ctl -v -r -l '"tvp5150 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3
> ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'
> media-ctl -v --set-format '"tvp5150 3-005d":0 [UYVY2X8 720x625]'
> media-ctl -v --set-format '"OMAP3 ISP CCDC":0 [UYVY2X8 720x625]'
> media-ctl -v --set-format '"OMAP3 ISP CCDC":1 [UYVY2X8 720x625]'
>
> This yields this:
[snip]
Looks good.
> The following works nicely:
> yavta -f UYVY -s 720x625 -n 4 --capture=4 -F /dev/video2
>
> The problem comes when I try to use gstreamer to capture from
> /dev/video2, using the following:
> gst-launch v4l2src device="/dev/video2" !
> 'video/x-raw-yuv,width=720,height=625' ! filesink location=sample.yuv
>
> This fails with:
> ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed
> getting controls attributes on device '/dev/video2'.
> Additional debug info:
> v4l2_calls.c(267): gst_v4l2_fill_lists ():
> /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
> Failed querying control 9963776 on device '/dev/video2'. (25 -
> Inappropriate ioctl for device)
>
> My question is, should this "just work"? It was my understanding that
> once the pipeline was configured with media-ctl then the CCDC output pad
> should behave like a standard V4L2 device node.
That's more or less correct. There have been a passionate debate regarding
what a "standard V4L2 device node" is. Not all V4L2 ioctls are mandatory, and
no driver implements them all. The OMAP3 ISP driver implements a very small
subset of the V4L2 API, and it wasn't clear whether that still qualified as
V4L2. After discussions we decided that the V4L2 specification will document
profiles, with a set of required ioctls for each of them. The OMAP3 ISP
implements the future video streaming profile.
I'm not sure what ioctls v4l2src consider as mandatory. The above error
related to a CTRL ioctl (possibly VIDIOC_QUERYCTRL), which isn't implemented
by the OMAP3 ISP driver and will likely never be. I don't think that should be
considered as mandatory.
I think that v4l2src requires the VIDIOC_ENUMFMT ioctl, which isn't
implemented in the OMAP3 ISP driver. That might change in the future, but I'm
not sure yet whether it will. In any case, you might have to modify v4l2src
and/or the OMAP3 ISP driver for now. Some patches have been posted a while ago
to this mailing list.
> I realise that this might be something borked with my build dependencies
> (although I'm pretty certain that v4l2src is being built against the
> latest libv42) or gstreamer. Before I start digging through the code to
> work out what is going on with the ioctl handling, I thought I would
> check to see whether this should work, or whether I am doing something
> fundamentally silly.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Omap3 ISP + Gstreamer v4l2src
2011-12-07 10:34 ` Laurent Pinchart
@ 2011-12-07 11:01 ` Michael Jones
2011-12-07 11:44 ` Adam Pledger
2011-12-18 21:52 ` Laurent Pinchart
0 siblings, 2 replies; 6+ messages in thread
From: Michael Jones @ 2011-12-07 11:01 UTC (permalink / raw)
To: Adam Pledger; +Cc: Laurent Pinchart, linux-media
Hi Adam,
On 12/07/2011 11:34 AM, Laurent Pinchart wrote:
> Hi Adam,
>
> On Wednesday 07 December 2011 09:02:42 Adam Pledger wrote:
>> Hi Laurent,
>>
>> Firstly, please accept my apologies, for what is very probably a naive
>> question. I'm new to V4L2 and am just getting to grips with how things
>> work.
>
> No worries.
>
>> I'm using a tvp5151 in bt656 mode with the Omap3 ISP,
>
> Please note that BT.656 support is still experimental, so issues are not
> unexpected.
>
>> as described in this thread (Your YUV support tree + some patches for bt656,
>> based on 2.6.39):
>> http://comments.gmane.org/gmane.linux.drivers.video-input-
> infrastructure/39539
>>
>> I am able to capture some frames using yavta, using the media-ctl
>> configuration as follows:
>> media-ctl -v -r -l '"tvp5150 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3
>> ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'
>> media-ctl -v --set-format '"tvp5150 3-005d":0 [UYVY2X8 720x625]'
>> media-ctl -v --set-format '"OMAP3 ISP CCDC":0 [UYVY2X8 720x625]'
>> media-ctl -v --set-format '"OMAP3 ISP CCDC":1 [UYVY2X8 720x625]'
>>
>> This yields this:
>
> [snip]
>
> Looks good.
>
>> The following works nicely:
>> yavta -f UYVY -s 720x625 -n 4 --capture=4 -F /dev/video2
>>
>> The problem comes when I try to use gstreamer to capture from
>> /dev/video2, using the following:
>> gst-launch v4l2src device="/dev/video2" !
>> 'video/x-raw-yuv,width=720,height=625' ! filesink location=sample.yuv
>>
>> This fails with:
>> ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed
>> getting controls attributes on device '/dev/video2'.
>> Additional debug info:
>> v4l2_calls.c(267): gst_v4l2_fill_lists ():
>> /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
>> Failed querying control 9963776 on device '/dev/video2'. (25 -
>> Inappropriate ioctl for device)
>>
>> My question is, should this "just work"? It was my understanding that
>> once the pipeline was configured with media-ctl then the CCDC output pad
>> should behave like a standard V4L2 device node.
>
> That's more or less correct. There have been a passionate debate regarding
> what a "standard V4L2 device node" is. Not all V4L2 ioctls are mandatory, and
> no driver implements them all. The OMAP3 ISP driver implements a very small
> subset of the V4L2 API, and it wasn't clear whether that still qualified as
> V4L2. After discussions we decided that the V4L2 specification will document
> profiles, with a set of required ioctls for each of them. The OMAP3 ISP
> implements the future video streaming profile.
>
> I'm not sure what ioctls v4l2src consider as mandatory. The above error
> related to a CTRL ioctl (possibly VIDIOC_QUERYCTRL), which isn't implemented
> by the OMAP3 ISP driver and will likely never be. I don't think that should be
> considered as mandatory.
>
> I think that v4l2src requires the VIDIOC_ENUMFMT ioctl, which isn't
> implemented in the OMAP3 ISP driver. That might change in the future, but I'm
> not sure yet whether it will. In any case, you might have to modify v4l2src
> and/or the OMAP3 ISP driver for now. Some patches have been posted a while ago
> to this mailing list.
Here was my submission for ENUM_FMT support:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg29640.html
I submitted this in order to be able to use the omap3-isp with
GStreamer. I missed the discussion about V4L2 "profiles", but when I
submitted that patch we discussed whether ENUM_FMT was mandatory. After
I pointed out that the V4L2 spec states plainly that it _is_ mandatory,
I thought Laurent basically agreed that it was reasonable.
Laurent, what do you think about adding ENUM_FMT support now?
>
>> I realise that this might be something borked with my build dependencies
>> (although I'm pretty certain that v4l2src is being built against the
>> latest libv42) or gstreamer. Before I start digging through the code to
>> work out what is going on with the ioctl handling, I thought I would
>> check to see whether this should work, or whether I am doing something
>> fundamentally silly.
>
-Michael
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler
Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Omap3 ISP + Gstreamer v4l2src
2011-12-07 11:01 ` Michael Jones
@ 2011-12-07 11:44 ` Adam Pledger
2011-12-18 21:52 ` Laurent Pinchart
1 sibling, 0 replies; 6+ messages in thread
From: Adam Pledger @ 2011-12-07 11:44 UTC (permalink / raw)
To: Michael Jones, Laurent Pinchart; +Cc: linux-media
Hi Laurent, Michael,
<snip>
>> Please note that BT.656 support is still experimental, so issues are not
>> unexpected.
Yes, I was aware that this is not yet fully baked.
<snip>
>>> My question is, should this "just work"? It was my understanding that
>>> once the pipeline was configured with media-ctl then the CCDC output
>>> pad
>>> should behave like a standard V4L2 device node.
>>
>>
>> That's more or less correct. There have been a passionate debate
>> regarding
>> what a "standard V4L2 device node" is. Not all V4L2 ioctls are
>> mandatory, and
>> no driver implements them all. The OMAP3 ISP driver implements a very
>> small
>> subset of the V4L2 API, and it wasn't clear whether that still
>> qualified as
>> V4L2. After discussions we decided that the V4L2 specification will
>> document
>> profiles, with a set of required ioctls for each of them. The OMAP3 ISP
>> implements the future video streaming profile.
>>
>> I'm not sure what ioctls v4l2src consider as mandatory. The above error
>> related to a CTRL ioctl (possibly VIDIOC_QUERYCTRL), which isn't
>> implemented
>> by the OMAP3 ISP driver and will likely never be. I don't think that
>> should be
>> considered as mandatory.
>>
>> I think that v4l2src requires the VIDIOC_ENUMFMT ioctl, which isn't
>> implemented in the OMAP3 ISP driver. That might change in the future,
>> but I'm
>> not sure yet whether it will. In any case, you might have to modify
>> v4l2src
>> and/or the OMAP3 ISP driver for now. Some patches have been posted a
>> while ago
>> to this mailing list.
>
> Here was my submission for ENUM_FMT support:
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg29640.html
>
> I submitted this in order to be able to use the omap3-isp with
> GStreamer. I missed the discussion about V4L2 "profiles", but when I
> submitted that patch we discussed whether ENUM_FMT was mandatory.
> After I pointed out that the V4L2 spec states plainly that it _is_
> mandatory, I thought Laurent basically agreed that it was reasonable.
>
> Laurent, what do you think about adding ENUM_FMT support now?
Thank you both for clarifying the current situation regarding omap3isp /
MCF (and Michael for the previous patch, which I will take a look at).
This addresses quite a few questions that I have been mulling over in
the last few days.
<snip>
Best Regards
Adam
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Omap3 ISP + Gstreamer v4l2src
2011-12-07 8:02 Omap3 ISP + Gstreamer v4l2src Adam Pledger
2011-12-07 10:34 ` Laurent Pinchart
@ 2011-12-08 21:27 ` Sakari Ailus
1 sibling, 0 replies; 6+ messages in thread
From: Sakari Ailus @ 2011-12-08 21:27 UTC (permalink / raw)
To: Adam Pledger; +Cc: Laurent Pinchart, linux-media
Hi Adam,
On Wed, Dec 07, 2011 at 08:02:42AM +0000, Adam Pledger wrote:
> Hi Laurent,
>
> Firstly, please accept my apologies, for what is very probably a
> naive question. I'm new to V4L2 and am just getting to grips with
> how things work.
>
> I'm using a tvp5151 in bt656 mode with the Omap3 ISP, as described
> in this thread (Your YUV support tree + some patches for bt656,
> based on 2.6.39):
> http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/39539
>
> I am able to capture some frames using yavta, using the media-ctl
> configuration as follows:
> media-ctl -v -r -l '"tvp5150 3-005d":0->"OMAP3 ISP CCDC":0[1],
> "OMAP3 ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'
> media-ctl -v --set-format '"tvp5150 3-005d":0 [UYVY2X8 720x625]'
> media-ctl -v --set-format '"OMAP3 ISP CCDC":0 [UYVY2X8 720x625]'
> media-ctl -v --set-format '"OMAP3 ISP CCDC":1 [UYVY2X8 720x625]'
>
> This yields this:
> Opening media device /dev/media0
> Enumerating entities
> Found 16 entities
> Enumerating pads and links
> Media controller API version 0.0.0
>
> Media device information
> ------------------------
> driver omap3isp
> model TI OMAP3 ISP
> serial
> bus info
> hw revision 0x0
> driver version 0.0.0
>
> Device topology
> - entity 1: OMAP3 ISP CCP2 (2 pads, 2 links)
> type V4L2 subdev subtype Unknown
> device node name /dev/v4l-subdev0
> pad0: Sink [SGRBG10 4096x4096]
> <- "OMAP3 ISP CCP2 input":0 []
> pad1: Source [SGRBG10 4096x4096]
> -> "OMAP3 ISP CCDC":0 []
>
> - entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link)
> type Node subtype V4L
> device node name /dev/video0
> pad0: Source
> -> "OMAP3 ISP CCP2":0 []
>
> - entity 3: OMAP3 ISP CSI2a (2 pads, 2 links)
> type V4L2 subdev subtype Unknown
> device node name /dev/v4l-subdev1
> pad0: Sink [SGRBG10 4096x4096]
> pad1: Source [SGRBG10 4096x4096]
> -> "OMAP3 ISP CSI2a output":0 []
> -> "OMAP3 ISP CCDC":0 []
>
> - entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link)
> type Node subtype V4L
> device node name /dev/video1
> pad0: Sink
> <- "OMAP3 ISP CSI2a":1 []
>
> - entity 5: OMAP3 ISP CCDC (3 pads, 9 links)
> type V4L2 subdev subtype Unknown
> device node name /dev/v4l-subdev2
> pad0: Sink [UYVY2X8 720x625]
> <- "OMAP3 ISP CCP2":1 []
> <- "OMAP3 ISP CSI2a":1 []
> <- "tvp5150 3-005d":0 [ENABLED]
> pad1: Source [UYVY2X8 720x625]
> -> "OMAP3 ISP CCDC output":0 [ENABLED]
> -> "OMAP3 ISP resizer":0 []
> pad2: Source [UYVY2X8 720x624]
> -> "OMAP3 ISP preview":0 []
> -> "OMAP3 ISP AEWB":0 [ENABLED,IMMUTABLE]
> -> "OMAP3 ISP AF":0 [ENABLED,IMMUTABLE]
> -> "OMAP3 ISP histogram":0 [ENABLED,IMMUTABLE]
>
> - entity 6: OMAP3 ISP CCDC output (1 pad, 1 link)
> type Node subtype V4L
> device node name /dev/video2
> pad0: Sink
> <- "OMAP3 ISP CCDC":1 [ENABLED]
>
> - entity 7: OMAP3 ISP preview (2 pads, 4 links)
> type V4L2 subdev subtype Unknown
> device node name /dev/v4l-subdev3
> pad0: Sink [SGRBG10 4096x4096 (8,4)/4082x4088]
> <- "OMAP3 ISP CCDC":2 []
> <- "OMAP3 ISP preview input":0 []
> pad1: Source [YUYV 4082x4088]
> -> "OMAP3 ISP preview output":0 []
> -> "OMAP3 ISP resizer":0 []
>
> - entity 8: OMAP3 ISP preview input (1 pad, 1 link)
> type Node subtype V4L
> device node name /dev/video3
> pad0: Source
> -> "OMAP3 ISP preview":0 []
>
> - entity 9: OMAP3 ISP preview output (1 pad, 1 link)
> type Node subtype V4L
> device node name /dev/video4
> pad0: Sink
> <- "OMAP3 ISP preview":1 []
>
> - entity 10: OMAP3 ISP resizer (2 pads, 4 links)
> type V4L2 subdev subtype Unknown
> device node name /dev/v4l-subdev4
> pad0: Sink [YUYV 4095x4095 (0,6)/4094x4082]
> <- "OMAP3 ISP CCDC":1 []
> <- "OMAP3 ISP preview":1 []
> <- "OMAP3 ISP resizer input":0 []
> pad1: Source [YUYV 3312x4095]
> -> "OMAP3 ISP resizer output":0 []
>
> - entity 11: OMAP3 ISP resizer input (1 pad, 1 link)
> type Node subtype V4L
> device node name /dev/video5
> pad0: Source
> -> "OMAP3 ISP resizer":0 []
>
> - entity 12: OMAP3 ISP resizer output (1 pad, 1 link)
> type Node subtype V4L
> device node name /dev/video6
> pad0: Sink
> <- "OMAP3 ISP resizer":1 []
>
> - entity 13: OMAP3 ISP AEWB (1 pad, 1 link)
> type V4L2 subdev subtype Unknown
> device node name /dev/v4l-subdev5
> pad0: Sink
> <- "OMAP3 ISP CCDC":2 [ENABLED,IMMUTABLE]
>
> - entity 14: OMAP3 ISP AF (1 pad, 1 link)
> type V4L2 subdev subtype Unknown
> device node name /dev/v4l-subdev6
> pad0: Sink
> <- "OMAP3 ISP CCDC":2 [ENABLED,IMMUTABLE]
>
> - entity 15: OMAP3 ISP histogram (1 pad, 1 link)
> type V4L2 subdev subtype Unknown
> device node name /dev/v4l-subdev7
> pad0: Sink
> <- "OMAP3 ISP CCDC":2 [ENABLED,IMMUTABLE]
>
> - entity 16: tvp5150 3-005d (1 pad, 1 link)
> type V4L2 subdev subtype Unknown
> device node name /dev/v4l-subdev8
> pad0: Source [UYVY2X8 720x625]
> -> "OMAP3 ISP CCDC":0 [ENABLED]
>
> The following works nicely:
> yavta -f UYVY -s 720x625 -n 4 --capture=4 -F /dev/video2
>
> The problem comes when I try to use gstreamer to capture from
> /dev/video2, using the following:
> gst-launch v4l2src device="/dev/video2" !
> 'video/x-raw-yuv,width=720,height=625' ! filesink
> location=sample.yuv
>
> This fails with:
> ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
> Failed getting controls attributes on device '/dev/video2'.
> Additional debug info:
> v4l2_calls.c(267): gst_v4l2_fill_lists ():
> /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
> Failed querying control 9963776 on device '/dev/video2'. (25 -
> Inappropriate ioctl for device)
>
> My question is, should this "just work"? It was my understanding
> that once the pipeline was configured with media-ctl then the CCDC
> output pad should behave like a standard V4L2 device node.
>
> I realise that this might be something borked with my build
> dependencies (although I'm pretty certain that v4l2src is being
> built against the latest libv42) or gstreamer. Before I start
> digging through the code to work out what is going on with the ioctl
> handling, I thought I would check to see whether this should work,
> or whether I am doing something fundamentally silly.
An alternative to what Laurent and Michael already suggested, is to use
subdevsrc (or subdevsrc2). Subdevsrc should be usable without camerabin, and
if you like camerabin2, then subdevsrc2 is the way to go.
It takes the pipeline configuration from a configuration file.
I'd _think_ this is the latest subdevsrc branch:
<URL:http://meego.gitorious.org/maemo-multimedia/gst-nokia-videosrc/commits/gen1-pr12>
Subdevsrc2 is in the master branch.
In either one, use the mcsrc; it's got no unpleasant dependencies.
Cheers,
--
Sakari Ailus
e-mail: sakari.ailus@iki.fi jabber/XMPP/Gmail: sailus@retiisi.org.uk
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Omap3 ISP + Gstreamer v4l2src
2011-12-07 11:01 ` Michael Jones
2011-12-07 11:44 ` Adam Pledger
@ 2011-12-18 21:52 ` Laurent Pinchart
1 sibling, 0 replies; 6+ messages in thread
From: Laurent Pinchart @ 2011-12-18 21:52 UTC (permalink / raw)
To: Michael Jones; +Cc: Adam Pledger, linux-media
Hi Michael,
On Wednesday 07 December 2011 12:01:17 Michael Jones wrote:
> On 12/07/2011 11:34 AM, Laurent Pinchart wrote:
> > On Wednesday 07 December 2011 09:02:42 Adam Pledger wrote:
> >> Hi Laurent,
> >>
> >> Firstly, please accept my apologies, for what is very probably a naive
> >> question. I'm new to V4L2 and am just getting to grips with how things
> >> work.
> >
> > No worries.
> >
> >> I'm using a tvp5151 in bt656 mode with the Omap3 ISP,
> >
> > Please note that BT.656 support is still experimental, so issues are not
> > unexpected.
> >
> >> as described in this thread (Your YUV support tree + some patches for
> >> bt656, based on 2.6.39):
> >> http://comments.gmane.org/gmane.linux.drivers.video-input-
> >
> > infrastructure/39539
> >
> >> I am able to capture some frames using yavta, using the media-ctl
> >> configuration as follows:
> >> media-ctl -v -r -l '"tvp5150 3-005d":0->"OMAP3 ISP CCDC":0[1], "OMAP3
> >> ISP CCDC":1->"OMAP3 ISP CCDC output":0[1]'
> >> media-ctl -v --set-format '"tvp5150 3-005d":0 [UYVY2X8 720x625]'
> >> media-ctl -v --set-format '"OMAP3 ISP CCDC":0 [UYVY2X8 720x625]'
> >> media-ctl -v --set-format '"OMAP3 ISP CCDC":1 [UYVY2X8 720x625]'
> >
> >> This yields this:
> > [snip]
> >
> > Looks good.
> >
> >> The following works nicely:
> >> yavta -f UYVY -s 720x625 -n 4 --capture=4 -F /dev/video2
> >>
> >> The problem comes when I try to use gstreamer to capture from
> >> /dev/video2, using the following:
> >> gst-launch v4l2src device="/dev/video2" !
> >> 'video/x-raw-yuv,width=720,height=625' ! filesink location=sample.yuv
> >>
> >> This fails with:
> >> ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed
> >> getting controls attributes on device '/dev/video2'.
> >> Additional debug info:
> >> v4l2_calls.c(267): gst_v4l2_fill_lists ():
> >> /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
> >> Failed querying control 9963776 on device '/dev/video2'. (25 -
> >> Inappropriate ioctl for device)
> >>
> >> My question is, should this "just work"? It was my understanding that
> >> once the pipeline was configured with media-ctl then the CCDC output pad
> >> should behave like a standard V4L2 device node.
> >
> > That's more or less correct. There have been a passionate debate
> > regarding what a "standard V4L2 device node" is. Not all V4L2 ioctls are
> > mandatory, and no driver implements them all. The OMAP3 ISP driver
> > implements a very small subset of the V4L2 API, and it wasn't clear
> > whether that still qualified as V4L2. After discussions we decided that
> > the V4L2 specification will document profiles, with a set of required
> > ioctls for each of them. The OMAP3 ISP implements the future video
> > streaming profile.
> >
> > I'm not sure what ioctls v4l2src consider as mandatory. The above error
> > related to a CTRL ioctl (possibly VIDIOC_QUERYCTRL), which isn't
> > implemented by the OMAP3 ISP driver and will likely never be. I don't
> > think that should be considered as mandatory.
> >
> > I think that v4l2src requires the VIDIOC_ENUMFMT ioctl, which isn't
> > implemented in the OMAP3 ISP driver. That might change in the future, but
> > I'm not sure yet whether it will. In any case, you might have to modify
> > v4l2src and/or the OMAP3 ISP driver for now. Some patches have been
> > posted a while ago to this mailing list.
>
> Here was my submission for ENUM_FMT support:
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg29640.html
>
> I submitted this in order to be able to use the omap3-isp with
> GStreamer. I missed the discussion about V4L2 "profiles", but when I
> submitted that patch we discussed whether ENUM_FMT was mandatory. After
> I pointed out that the V4L2 spec states plainly that it _is_ mandatory,
> I thought Laurent basically agreed that it was reasonable.
>
> Laurent, what do you think about adding ENUM_FMT support now?
I'm OK with it, but we need to discuss the details. During the latest V4L2
meeting in Prague we decided to create a "streaming" profile for V4L2 device
nodes such as the ones created by the OMAP3 ISP driver. We now need to decide
which ioctls will be mandatory in that profile (ENUM_FMT will likely be), and
what they should return exactly. That's on my to-do list (but handling my e-
mail backlog comes first :-)).
> >> I realise that this might be something borked with my build dependencies
> >> (although I'm pretty certain that v4l2src is being built against the
> >> latest libv42) or gstreamer. Before I start digging through the code to
> >> work out what is going on with the ioctl handling, I thought I would
> >> check to see whether this should work, or whether I am doing something
> >> fundamentally silly.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-12-18 21:52 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-12-07 8:02 Omap3 ISP + Gstreamer v4l2src Adam Pledger
2011-12-07 10:34 ` Laurent Pinchart
2011-12-07 11:01 ` Michael Jones
2011-12-07 11:44 ` Adam Pledger
2011-12-18 21:52 ` Laurent Pinchart
2011-12-08 21:27 ` Sakari Ailus
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox