Frame rate enumeration ioctl

["Martin Rubli" <martin_rubli (at) logitech.com>]

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. :-)

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.

Cheers,
Martin

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