Hi Sakari,
On 11/21/2012 08:39 PM, Sakari Ailus wrote:
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.
Yes, that's an another ambiguity that might need to be resolved.
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?
Yes, it makes sense to me to report with the buffer flag that the source of
timestamp is just an OUTPUT buffer. At least this would solve the reporting
part of the issue. Oh wait, could applications tell by setting buffer flag
what timestamping behaviour they expect from a driver ?
I can't see an important use of timestamping m2m buffers at device drivers.
Performance measurement can probably be done in user space with sufficient
accuracy as well. However, it wouldn't be difficult for drivers to
implement
multiple time stamping techniques, e.g. OUTPUT -> CAPTURE timestamp copying
or getting timestamps from monotonic clock at frame processing beginning and
end for OUTPUT and CAPTURE respectively.
I believe the buffer flags might be a good solution.
--
Regards,
Sylwester
--
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
