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@xxxxxx
--
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
