By Date: <-- -->
By Thread: <-- -->

Frame rate enumeration ioctl

Em Seg, 2006-05-22 às 10:29 -0700, Martin Rubli escreveu:
> On Mon, 22 May 2006 03:48:30 -0700, michel Xhaard <mxhaard (at) magic.fr> wrote:
> 
> > Le Mardi 16 Mai 2006 00:41, Martin Rubli a écrit :
> >> Hi all,
> >>
> >> We've been trying to improve the way that the GStreamer V4L2 source
> >> handles frame rates when used with webcams. Given that GStreamer uses
> >> capability negotiation, we ran into the problem of retrieving a list of
> >> supported framerates.
> >>
> >> Currently, there seems no way (except for trial and error) of  
> >> enumerating
> >> the frame rates that a device supports.
> >>
> >> We'd like to propose a new ioctl that allows enumerating the supported
> >> frame rates for the currently used capture format (e.g.
> >> VIDIOC_ENUM_FRAMERATE). If there's interest, we can write up a draft. It
> >> would greatly simplify things for applications like GStreamer, Ekiga,  
> >> etc.
> >> that work with webcams.
> >>
> >> Thanks in advance for any comments ...
> >>
> >> Cheers,
> >> Martin
> >>
> >> --
> >> video4linux-list mailing list
> >> Unsubscribe  
> >> mailto:video4linux-list-request (at) redhat.com?subject=unsubscribe
> >> https://www.redhat.com/mailman/listinfo/video4linux-list
> > Martin,
> > Instead of create a new ioctl() as v4l2 have a lot :) why not used
> > VIDIOC_ENUM_FMT to pass parameters the apps need to know from the  
> > hardware ?
> > If we know that the hardware support for example YUYV for 1024 x 768 is a
> > range of framerate min to max is enought ?
> > Cheers,
> 
> In addition to what Laurent mentioned in his post, VIDIOC_ENUM_FMT is  
> about image _formats_. I personally don't see the frame rate as part of  
> the video format. (But that might just be me. :-)
Hmm... good point. Currently, this API call brings back two
informations: 1) Video standard; 2) frameperiod (rate).

For analalog TV, those two informations are linked. However, makes no
sense for digital streams (even when produced by analog boards).

Hans is proposing some changes at API to handle MPEG streams. MPEG
encoders may generate streams on other non-standard rates, using
temporal decimation algorithms. On his proposal, there is an extended
control:

"V4L2_CID_COMP_VIDEO_TEMPORAL_DECIMATION
 INT: For each frame captured, skip specified number of frames."

We should notice that there are also two ioctls to get/change frame rate
(along other changes at the video stream):
VIDIOC_G_PARM, VIDIOC_S_PARM



> 
> The concept of video formats is not entirely suitable for digital devices  
> like webcams, so it might be better to introduce a new ioctl that takes  
> these changes into account. Note that we also lack an elegant way of doing  
> image resolution enumeration. From an application developer's point of  
> view it is preferable to know the natively supported resolutions  
> beforehand (and possibly give the user a choice) instead of just relying  
> on a closest match scheme.
> 
> As far as the VIDIOC_ENUM_FMT call is concerned, I guess the 'reserved'  
> field would leave a way open to extend the struct in a backward compatible  
> manner. Nevertheless, it doesn't feel like the right way to me.
We might use the reserved field, but, imho, it is not the right place.
Better to break it on a separate stuff. One possibility is, instead of
having another ioctl for it, to have an extended control. 

Hans,

Maybe we should consider having an ENUM for extended controls, showing
the acceptable values.
> 
> Cheers,
> Martin
> 
> --
> video4linux-list mailing list
> Unsubscribe mailto:video4linux-list-request (at) redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/video4linux-list
Cheers, 
Mauro.

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request (at) redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list