Hi Laurent, On Fri, Aug 30, 2013 at 01:31:44PM +0200, Laurent Pinchart wrote: > Hi Sakari, > > On Thursday 29 August 2013 14:33:39 Sakari Ailus wrote: > > On Thu, Aug 29, 2013 at 01:25:05AM +0200, Laurent Pinchart wrote: > > > On Wednesday 28 August 2013 19:39:19 Sakari Ailus wrote: > > > > On Wed, Aug 28, 2013 at 06:14:44PM +0200, Laurent Pinchart wrote: > > > > ... > > > > > > > > > > > UVC devices timestamp frames when the frame is captured, not when > > > > > > > the first pixel is transmitted. > > > > > > > > > > > > I.e. we shouldn't set the SOF flag? "When the frame is captured" > > > > > > doesn't say much, or almost anything in terms of *when*. The frames > > > > > > have exposure time and rolling shutter makes a difference, too. > > > > > > > > > > The UVC 1.1 specification defines the timestamp as > > > > > > > > > > "The source clock time in native deviceclock units when the raw frame > > > > > capture begins." > > > > > > > > > > What devices do in practice may differ :-) > > > > > > > > I think that this should mean start-of-frame - exposure time. I'd really > > > > wonder if any practical implementation does that however. > > > > > > It's start-of-frame - exposure time - internal delays (UVC webcams are > > > supposed to report their internal delay value as well). > > > > Do they report it? How about the exposure time? > > It's supposed to be configurable. Is the exposure reported with the frame so it could be used to construct the per-frame SOF timestamp? > > If you know them all you can calculate the SOF timestamp. The fewer > > timestamps are available for user programs the better. > > > > It's another matter then if there are webcams that report these values > > wrong. > > There most probably are :-) > > > Then you could get timestamps that are complete garbage. But I guess you > > could compare them to the current monotonic timestamp and detect such cases. > > > > > > What's your suggestion; should we use the SOF flag for this or do you > > > > prefer the end-of-frame timestamp instead? I think it'd be quite nice > > > > for drivers to know which one is which without having to guess, and > > > > based on the above start-of-frame comes as close to that definition as > > > > is meaningful. > > > > > > SOF is better than EOF. Do we need a start-of-capture flag, or could we > > > document SOF as meaning start-of-capture or start-of-reception depending > > > on what the device can do ? > > > > One possibility is to dedicate a few flags for this; by using three bits > > we'd get eight different timestamps already. But I have to say that fewer is > > better. :-) > > Does it really need to be a per-buffer flag ? This seems to be a driver-wide > (or at least device-wide) behaviour to me. Same goes for timestamp clock sources. It was concluded to use buffer flags for those as well. Using a control for the purpose would however require quite non-zero amount of initialisation code from each driver so that would probably need to be sorted out first. -- Kind regards, Sakari Ailus e-mail: sakari.ailus@xxxxxx XMPP: sailus@xxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
