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

Frame rate enumeration ioctl

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

I don't like that. A control should really stay a control, not a streaming 
parameter. Otherwise we could replace G_FMT/S_FMT with controls as well, and 
everything would become a control. Back to the starting point, with another 
naming scheme :-) Or do we actually want to go that way ?

We need to define the concept of "control". What is a control ? How does it 
differ from, say, the frame size ?

> Hans,
>
> Maybe we should consider having an ENUM for extended controls, showing
> the acceptable values.

Once again, are the frame size and the frame rate controls ? If the later is a 
control, the __s32 value field in struct v4l2_ext_control is already not 
enough, as we need to pass a fraction.

One possible definition of control vs streaming parameter would be that a 
control can be changed without stopping streaming, while a streaming 
parameter can't. Therefore the frame size, frame rate, MPEG and MJPEG 
compression parameters would be streaming parameters and not controls.

I'm waiting for opinions and comments (and please remember I'm not trying to 
break the current proposal, but just to make sure it will cover our needs for 
today and the near future :-)).

Laurent Pinchart

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