Hi Hans, On Tue, Feb 25, 2014 at 06:28:06PM +0100, Hans Verkuil wrote: > On 02/25/2014 06:08 PM, Sakari Ailus wrote: > > 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). > > You'll want to reference this patch I posted today: > > [RFCv1 PATCH 16/20] vb2: fix timecode and flags handling for output buffers > > Also available in this git repo: > > http://git.linuxtv.org/hverkuil/media_tree.git/shortlog/refs/heads/vb2-part4 > > The current implementation in vb2 is actually broken (which is one of the > things fixed by this patch): if you prepare a buffer (VIDIOC_PREPARE_BUF) > and only then call VIDIOC_QBUF with a timestamp, that timestamp will be > lost since it will use the one set by PREPARE_BUF (either that or it is > zeroed, I've forgotten which of the two it was). > > If you want to take that patch and add your own changes to it, then that's > fine by me. It should be pretty much standalone. I'll keep that as-is and write another to pass the timestamp source flags when needed. Would it be ok if I prepend the patch to the set? -- 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
