Re: [PATCH v2 1/1] v4l: Document timestamp behaviour to correspond to reality

[Sakari Ailus <sakari.ailus@iki.fi>]

Hi Laurent,

Laurent Pinchart wrote:
...
>>>>> @@ -745,13 +718,9 @@ applications when an output stream.</entry>
>>>>>
>>>>>   	    byte was captured, as returned by the
>>>>>   	    <function>clock_gettime()</function> function for the relevant
>>>>>   	    clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in
>>>>>
>>>>> -	    <xref linkend="buffer-flags" />. For output streams 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
>>>>> -	    <structfield>timestamp</structfield> field. This permits
>>>>> +	    <xref linkend="buffer-flags" />. For output streams he driver
>>>>
>>>> 'he' -> 'the'
>>>>
>>>>> +	   stores the time at which the first data byte was actually sent
>>>>> out
>>>>> +	   in the  <structfield>timestamp</structfield> field. This permits
>>>>
>>>> Not true: the timestamp is taken after the whole frame was transmitted.
>>>>
>>>> Note that the 'timestamp' field documentation still says that it is the
>>>> timestamp of the first data byte for capture as well, that's also wrong.
>>>
>>> I know we've already discussed this, but what about devices, such as
>>> uvcvideo, that can provide the time stamp at which the image has been
>>> captured ? I don't think it would be worth it making this configurable,
>>> or even reporting the information to userspace, but shouldn't we give
>>> some degree of freedom to drivers here ?
>>
>> Hmm. That's a good question --- if we allow variation then we preferrably
>> should also provide a way for applications to know which case is which.
>>
>> Could the uvcvideo timestamps be meaningfully converted to the frame end
>> time instead? I'd suppose that a frame rate dependent constant would
>> suffice. However, how to calculate this I don't know.
>
> I don't think that's a good idea. The time at which the last byte of the image
> is received is meaningless to applications. What they care about, for
> synchronization purpose, is the time at which the image has been captured.
>
> I'm wondering if we really need to care for now. I would be enclined to leave
> it as-is until an application runs into a real issue related to timestamps.

What do you mean by "image has been captured"? Which part of it?

What I was thinking was the possibility that we could change the 
definition so that it'd be applicable to both cases: the time the whole 
image is fully in the system memory is of secondary importance in both 
cases anyway. As on embedded systems the time between the last pixel of 
the image is fully captured to it being in the host system memory is 
very, very short the two can be considered the same in most situations.

I wonder if this change would have any undesirable consequences.

-- 
Cheers,

Sakari Ailus
sakari.ailus@iki.fi