Hi Hans, On Sun, Feb 23, 2014 at 12:45:28PM +0100, Hans Verkuil wrote: > On 02/15/2014 09:53 PM, Sakari Ailus wrote: > > Timestamp buffer flags are constant at the moment. Document them so that 1) > > they're always valid and 2) not changed by the drivers. This leaves room to > > extend the functionality later on if needed. > > > > Signed-off-by: Sakari Ailus <sakari.ailus@xxxxxx> > > --- > > Documentation/DocBook/media/v4l/io.xml | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml > > index fbd0c6e..4f76565 100644 > > --- a/Documentation/DocBook/media/v4l/io.xml > > +++ b/Documentation/DocBook/media/v4l/io.xml > > @@ -653,6 +653,16 @@ plane, are stored in struct <structname>v4l2_plane</structname> instead. > > In that case, struct <structname>v4l2_buffer</structname> contains an array of > > plane structures.</para> > > > > + <para>Dequeued video buffers come with timestamps. These > > + timestamps can be taken from different clocks and at different > > + part of the frame, depending on the driver. Please see flags in > > + the masks <constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant> and > > + <constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant> in <xref > > + linkend="buffer-flags">. These flags are guaranteed to be always > > + valid and will not be changed by the driver autonomously. Changes > > + in these flags may take place due as a side effect of > > + &VIDIOC-S-INPUT; or &VIDIOC-S-OUTPUT; however.</para> > > There is one exception to this: if the timestamps are copied from the output > buffer to the capture buffer (TIMESTAMP_COPY), then it can change theoretically > for every buffer since it entirely depends on what is being sent to it. The > value comes from userspace and you simply don't have any control over that. Yes; I agree. And a good point as well --- the timestamp source flags currently come from __fill_v4l2_buffer() which takes them from q->timestamp. This isn't right for m2m devices. I'll fix and resend (3rd patch most likely). > I'm stress testing vb2 in lots of different ways, including timestamp handling. > It's not a pretty sight, I'm afraid. Expect a looong list of patches in the > coming week. :-) -- 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
