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. What do you think? -- 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
