[gst-devel] Re: [patch] gstreamer v4l2 source frame rate detection

[Edgard Lima]

 > I'm not aware of any devices that dynamically change the
 > frame rate, so I think there's no point. If such devices do exist, 
please
 > correct me! :-)

Yes, framerate could change, for example if you change the current input 
(Television, Composite1, S-Video) it may change the norm (PALM, NTSC, 
...) or else you change the norm by hand.

BR,
Edgard


ext Edgard Lima wrote:

>
>
> BTW: in the meantime, to use your webcam with v4l2src use 
> use-fixed-fps=false, I hope it works.
>
> []s
> Edgard
>
>
> ext Edgard Lima wrote:
>
>>
>> Hi Martin,
>>
>> Thanks. I'm coding v4l2src right now. I ll put credits for you when 
>> commiting it.
>> Ive have a tv-card here, but a webcam, so we could test together :)
>>
>> BR,
>> Edgard - alima
>> edgard.lima at indt.org.br
>>
>>
>> ext Martin_Rubli at logitech.com wrote:
>>
>>> Hi Edgard,
>>>
>>> I've been working with the author of the Linux UVC driver
>>> (http://linux-uvc.berlios.de/) on a few issues and when we did some 
>>> tests
>>> with the GStreamer v4l2 source we discovered a problem with the 
>>> frame rate
>>> detection.
>>>
>>> The gst_v4l2src_get_fps function relies on the driver's video standard
>>> announcements, something that's not usually available in webcams 
>>> (and it
>>> certainly isn't in the UVC driver). If the norm cannot be detected, it
>>> bails out and capturing fails. Instead, VIDIOC_G_PARM should be used in
>>> such cases.
>>>
>>> Something else that stroke me as a little weird was the fact that 
>>> the frame
>>> rate gets queried before every frame (actually twice, once in 
>>> 'buffer_new'
>>> and once in 'create'). In the original case where the frame rate 
>>> came from
>>> a cached list of video standards, the overhead is minimal, yet present.
>>> When the frame rate comes from a G_PARM ioctl request, the overhead is
>>> somewhat higher. I'm not aware of any devices that dynamically 
>>> change the
>>> frame rate, so I think there's no point. If such devices do exist, 
>>> please
>>> correct me! :-)
>>>
>>> The first version of the patch only adds G_PARM support to the get_fps
>>> function. The second one is a superset of the first one and caches 
>>> the fps
>>> numerator and denominator in the _GstV4l2Src structure after 
>>> querying it in
>>> the capture_init method to avoid repeated ioctls. The changes allow UVC
>>> devices to work with GStreamer.
>>>
>>> Unfortunately, I don't have a TV card here that I could test it 
>>> with, but I
>>> think the patch shouldn't break anything. Please let me know, if you 
>>> have
>>> any questions/suggestions.
>>>
>>> Cheers,
>>> Martin
>>>
>>>
>>> (See attached file: 01-webcam_framerate.patch)(See attached file:
>>> 02-webcam_framerate.patch)
>>>
>>
>>
>>
>> -------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, 
>> security?
>> Get stuff done quickly with pre-integrated technology to make your 
>> job easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache 
>> Geronimo
>> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> gstreamer-devel mailing list
>> gstreamer-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>
>
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job 
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache 
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel