Re: [PATCH] [media] exynos-gsc: propagate timestamps from src to dst buffers

[Sylwester Nawrocki <sylvester.nawrocki@gmail.com>]

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