Hi Jacob, sorry for the late reply, I haven't had a second of free time this week :-S
On Friday 02 October 2009 20:43:00 Jacob Fehr wrote: > Hey Laurent, > > What do think about making a couple enhancements to the UVC driver? I would > be willing to write the code and send it your way. I'm all for it of course, especially if you write the code :-) > v4l2_buffer.timestamp Accuracy > > The first change that I'm looking into is enhancing the accuracy of > v4l2_buffer.timestamp. Currently, the driver stamps this with the system > time. An URB reads data off of the bus for a period of time that is > determined by the number of isochronous packets in the URB. The problem is > that video frames do not always fall on URB boundaries. The average error > in the timestamp is equal to urb.number_of_packets x urb.interval / 8 / 2 > milliseconds. The maximum error is 4 ms because UVC_MAX_PACKETS is set to > 32. > > To correct this I was thinking of offsetting v4l2_buffer.timestamp by > searching through the ISO packet array in the URB, keeping track of the > index in usb_iso_packet_descriptor where the device toggles the FID and/or > sets the EOF flag and then adjusting v4l2_buffer.timestamp by 125 > microseconds x the index into the urb. > > Another way to correct this would be to use the PTS, SCR, urb.start_frame > and gettimeofday() values to create a timestamp that would be accurate to > 125 microseconds. This would require quite a bit more math than the method > I mentioned above but it would be more accurate. I like the second method better. That's what the PTS and SCR fields are for, and the uvcvideo driver should really use them. The first solution be a bit simpler but it sounds more like a hack. > UVC_CTRL_CONTROL_TIMEOUT > > Currently this is hardcoded to 300 ms. I have a device with an extension > unit with a control that takes up to ¾ of a second. What do you think > about creating a custom IO control that could be used to set this? Would a module parameter do ? > UVCIOC_CTRL_MAP/UVCIOC_CTRL_ADD requiring root permissions > > What do you think about lifting this restriction? It's not difficult to > work around this but it does require handshaking of some sort between two > processes. Any application that needs to access the XU of any camera will > always need to be divided into two components. A component that runs as > root and a component that runs as a normal user. Or it would need to be > one component that runs as root. How much value is there in protecting the > extension units in UVC cameras? This goes hand-in-hand with the next > suggestion. > > UVCIOC_CTRL_MAP/UVCIOC_CTRL_ADD has global scope > > I have noticed these IO controls affect the driver not the device. Would it > make sense to change this to device scope? I may have two different UVC > cameras each with different extension units that I may want to configure. The UVCIOC_CTRL_MAP and UVCIOC_CTRL_ADD were not designed to be used by regular video streaming applications. They should instead be used by a helper application working hand in hand with udev (or hal) to create mappings when a new device is plugged in. One such application is called uvcdynctrl. It can be found in the libwebcam repository (see http://www.quickcamteam.net/software/libwebcam). The 0.1.1 package is really outdated, you should downloaded the latest version from SVN instead. uvcdynctrl gets information about extension units from XML files. XML configuration files for Logitech webcams are provided. There's also a sample udev script in the repository. -- Regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
