[gst-devel] [PATCH] RFC: v4l2: add norm property
Clark, Rob
rob at ti.com
Tue Mar 23 21:00:35 CET 2010
On Mar 23, 2010, at 1:20 PM, Guennadi Liakhovetski wrote:
> (did you drop the list from CC on purpose?)
>
oh, opps.. my bad
> On Tue, 23 Mar 2010, Clark, Rob wrote:
>
>>
>> On Mar 23, 2010, at 12:17 PM, Guennadi Liakhovetski wrote:
>>
>>> On Sun, 21 Mar 2010, Rob Clark wrote:
>>>
>>>> Based on a patch by Guennadi Liakhovetski.
>>>>
>>>> Note: I don't actually have a device supporting tuner, so I can't really
>>>> test this myself. I'd appreciate if someone with a tuner device could give
>>>> this a try.
>>>
>>> I'm afraid, this didn't work out of the box. I think, the actual call to
>>> gst_v4l2_set_norm() is missing. Attached my enum-based version of the
>>> patch for your reference.
>>>
>>
>> what I wonder, is if querying the supported formats of the driver is
>> working.. if it doesn't end up in the list of supported GstTunerNorm's,
>> then it won't be picked..
>>
>> Since I can't really replicate, could you run w/ GST_DEBUG="*v4l2*:5"
>> and send me the log? Thx
>
> Attached, but a question in the meantime - you're repeatedly referring to
> "tuner," whereas G_STD and S_STD V4L2 ioctls are applicable not only to
> tuners. Can it be, that gstreamer only wants to apply norm ioctl()s to
> tners? I.e., to v4l2 devices, advertising tuner capability
> (V4L2_CAP_TUNER)?
Actually, as far as I can tell, it doesn't care about V4L2_CAP_TUNER... but it does care that that the element implements GstTuner interface, which I omitted to add to v4l2sink.
I'll send an updated patch in a bit.
BR,
-R
>
>>
>>
>> BR,
>> -R
>>
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/<gst-norm.log.bz2>
More information about the gstreamer-devel
mailing list