Hi Hans, Thanks for the comments. Hans Verkuil wrote: > On 02/07/2014 11:52 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 | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml >> index 451626f..f523725 100644 >> --- a/Documentation/DocBook/media/v4l/io.xml >> +++ b/Documentation/DocBook/media/v4l/io.xml >> @@ -654,6 +654,14 @@ 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>Buffers that have been dequeued 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.</para> > > That's a bit too strong. Different inputs or outputs may have different timestamp Fixed. > sources. Also add a note that the SOE does not apply to outputs (there is no The flags are already documented separately, but I can add that to make it explicit. > exposure there after all). For EOF the formulation for outputs should be: > "..last pixel of the frame has been transmitted." Added. > For the COPY mode I think the SRC_MASK bits should be copied as well. That should > be stated in the documentation. Good point. I'll make that a separate patch as it changes a number of drivers. Perhaps this could be a good occasion to clean up some timecode field usage from those drivers, too. -- Kind regards, 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
