Hi Kamil, On Thu, Nov 22, 2012 at 10:32:09AM +0100, Kamil Debski wrote: > Hi Sakari, > > > From: Sakari Ailus [mailto:sakari.ailus@xxxxxx] > > Sent: Wednesday, November 21, 2012 8:40 PM > > > > Hi Sylwester and Shaik, > > > > On Mon, Nov 19, 2012 at 11:06:34PM +0100, Sylwester Nawrocki wrote: > > > On 11/07/2012 07:40 AM, Shaik Ameer Basha wrote: > > > >Make gsc-m2m propagate the timestamp field from source to > > destination > > > >buffers > > > > > > We probably need some means for letting know the mem-to-mem drivers > > > and applications whether timestamps are copied from OUTPUT to CAPTURE > > or not. > > > Timestamps at only OUTPUT interface are normally used to control > > > buffer processing time [1]. > > > > > > > > > "struct timeval timestamp > > > > > > For input streams this is the system time (as returned by the > > > gettimeofday() > > > function) when the first data byte was captured. For output streams > > > > Thanks for notifying me; this is going to be dependent on the timestamp > > type. > > > > Also most drivers use the time the buffer is finished rather than when > > the "first data byte was captured", but that's separate I think. > > > > > the data > > > will not be displayed before this time, secondary to the nominal > > frame > > > rate determined by the current video standard in enqueued order. > > > Applications can > > > for example zero this field to display frames as soon as possible. > > > The driver > > > stores the time at which the first data byte was actually sent out in > > > the timestamp field. This permits applications to monitor the drift > > > between the video and system clock." > > > > > > In some use cases it might be useful to know exact frame processing > > > time, where driver would be filling OUTPUT and CAPTURE value with > > > exact monotonic clock values corresponding to a frame processing > > start and end time. > > > > Shouldn't this always be done in memory-to-memory processing? I could > > imagine only performance measurements can benefit from other kind of > > timestamps. > > > > We could use different timestamp type to tell the timestamp source > > isn't any system clock but an input buffer. > > I hope that by input buffer you mean the OUTPUT buffer. > So the timestamp is copied from the OUTPUT buffer to the corresponding > CAPTURE buffer. Correct. Input for the device. I think the OMAP 3 ISP also uses these names; should it, that's another question. OUTPUT and CAPTURE are good. > > > > What do you think? > > Definite yes, if my assumption above is true. I did reply to your RFC > suggesting to include this, but got no reply whatsoever. Maybe it got > lost somewhere. Could be. Anyway, I think we can then say that we agree. :-) Who will write the patch? :-) -- 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
