|
From: David M. <dc...@MI...> - 2006-03-16 06:12:52
|
Just thought I'd chime in here... The V4L2 buffer will end up being the same size regardless of frame rate (at least for this implementation), right? So even if the application chooses the frame rate after choosing the image size, the buffer size as returned by VIDIOC_S_FMT would still be correct. UVC would still have to renegotiate the size of its isochronous USB buffers after changing the frame rate, but those buffers are independent from the V4L2 queue if I understand correctly. I agree that the V4L2 api is deficient in this respect, but in the case of UVC, it seems to me like the current API is still workable, at least in the short term. What do you think? -David Laurent Pinchart wrote: > Hi Phil, > > > Quick question.. is it possible to control the frame rate of a UVC > > device? I had a quick look at the spec but I didn't see anything. It's > > probable I'm missing the obvious... > > It's possible, but not implemented yet due to a problem with the V4L2 specs. > The issue is that UVC negociates the image size before the frame rate, while > V4L2 negociates the frame rate before the image size (this is not entirely > true, you can set the image size before the frame rate, but the required > buffer length is returned by the image size negociation process, but UVC > devices return the required buffer length when negociating the frame rate and > compression quality). This has been discussed on the V4L2 mailing list, and I > still have to write a proposal for a new IOCTL. This means applications will > need to be upgraded to support the new interface. > > Laurent Pinchart |