[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