| Message ID | 1392925276-20412-1-git-send-email-sakari.ailus@iki.fi (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 02/20/2014 08:41 PM, Sakari Ailus wrote: > Some devices do not produce timestamps that correspond to the end of the > frame. The user space should be informed on the matter. This patch achieves > that by adding buffer flags (and a mask) for timestamp sources since more > possible timestamping points are expected than just two. > > A three-bit mask is defined (V4L2_BUF_FLAG_TSTAMP_SRC_MASK) and two of the > eight possible values is are defined V4L2_BUF_FLAG_TSTAMP_SRC_EOF for end of > frame (value zero) V4L2_BUF_FLAG_TSTAMP_SRC_SOE for start of exposure (next > value). Sorry, but I still have two small notes: > Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> > --- > since v5: > - Add a note on software generated timestamp inaccuracy. > > Documentation/DocBook/media/v4l/io.xml | 38 +++++++++++++++++++++++++----- > drivers/media/v4l2-core/videobuf2-core.c | 4 +++- > include/media/videobuf2-core.h | 2 ++ > include/uapi/linux/videodev2.h | 4 ++++ > 4 files changed, 41 insertions(+), 7 deletions(-) > > diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml > index 46d24b3..22b87bc 100644 > --- a/Documentation/DocBook/media/v4l/io.xml > +++ b/Documentation/DocBook/media/v4l/io.xml > @@ -653,12 +653,6 @@ 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>For timestamp types that are sampled from the system clock > -(V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC) it is guaranteed that the timestamp is > -taken after the complete frame has been received (or transmitted in > -case of video output devices). For other kinds of > -timestamps this may vary depending on the driver.</para> > - > <table frame="none" pgwide="1" id="v4l2-buffer"> > <title>struct <structname>v4l2_buffer</structname></title> > <tgroup cols="4"> > @@ -1119,6 +1113,38 @@ in which case caches have not been used.</entry> > <entry>The CAPTURE buffer timestamp has been taken from the > corresponding OUTPUT buffer. This flag applies only to mem2mem devices.</entry> > </row> > + <row> > + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant></entry> > + <entry>0x00070000</entry> > + <entry>Mask for timestamp sources below. The timestamp source > + defines the point of time the timestamp is taken in relation to > + the frame. Logical and operation between the > + <structfield>flags</structfield> field and > + <constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant> produces the > + value of the timestamp source.</entry> > + </row> > + <row> > + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_EOF</constant></entry> > + <entry>0x00000000</entry> > + <entry>End Of Frame. The buffer timestamp has been taken > + when the last pixel of the frame has been received or the > + last pixel of the frame has been transmitted. In practice, > + software generated timestamps will typically be read from > + the clock a small amount of time after the last pixel has > + been received, depending on the system and other activity s/been received/been received or transmitted/ > + in it.</entry> > + </row> > + <row> > + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_SOE</constant></entry> > + <entry>0x00010000</entry> > + <entry>Start Of Exposure. The buffer timestamp has been > + taken when the exposure of the frame has begun. In > + practice, software generated timestamps will typically be > + read from the clock a small amount of time after the last > + pixel has been received, depending on the system and other > + activity in it. This is only valid for buffer type > + <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>.</entry> I would move the last sentence up to just before "In practice...". The way it is now it looks like an afterthought. I am also not sure whether the whole "In practice" sentence is valid here. Certainly the bit about "the last pixel" isn't since this is the "SOE" case and not the End Of Frame. In the case of the UVC driver (and that's the only one using this timestamp source) the timestamps come from the hardware as I understand it, so the "software generated" bit doesn't apply. I would actually be inclined to drop it altogether for this particular timestamp source. But it's up to Laurent. Regards, Hans > + </row> > </tbody> > </tgroup> > </table> > diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c > index 5a5fb7f..6e314b0 100644 > --- a/drivers/media/v4l2-core/videobuf2-core.c > +++ b/drivers/media/v4l2-core/videobuf2-core.c > @@ -2195,7 +2195,9 @@ int vb2_queue_init(struct vb2_queue *q) > WARN_ON(!q->io_modes) || > WARN_ON(!q->ops->queue_setup) || > WARN_ON(!q->ops->buf_queue) || > - WARN_ON(q->timestamp_type & ~V4L2_BUF_FLAG_TIMESTAMP_MASK)) > + WARN_ON(q->timestamp_type & > + ~(V4L2_BUF_FLAG_TIMESTAMP_MASK | > + V4L2_BUF_FLAG_TSTAMP_SRC_MASK))) > return -EINVAL; > > /* Warn that the driver should choose an appropriate timestamp type */ > diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h > index bef53ce..b6b992d 100644 > --- a/include/media/videobuf2-core.h > +++ b/include/media/videobuf2-core.h > @@ -312,6 +312,8 @@ struct v4l2_fh; > * @buf_struct_size: size of the driver-specific buffer structure; > * "0" indicates the driver doesn't want to use a custom buffer > * structure type, so sizeof(struct vb2_buffer) will is used > + * @timestamp_type: Timestamp flags; V4L2_BUF_FLAGS_TIMESTAMP_* and > + * V4L2_BUF_FLAGS_TSTAMP_SRC_* > * @gfp_flags: additional gfp flags used when allocating the buffers. > * Typically this is 0, but it may be e.g. GFP_DMA or __GFP_DMA32 > * to force the buffer allocation to a specific memory zone. > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h > index e9ee444..82e8661 100644 > --- a/include/uapi/linux/videodev2.h > +++ b/include/uapi/linux/videodev2.h > @@ -695,6 +695,10 @@ struct v4l2_buffer { > #define V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN 0x00000000 > #define V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC 0x00002000 > #define V4L2_BUF_FLAG_TIMESTAMP_COPY 0x00004000 > +/* Timestamp sources. */ > +#define V4L2_BUF_FLAG_TSTAMP_SRC_MASK 0x00070000 > +#define V4L2_BUF_FLAG_TSTAMP_SRC_EOF 0x00000000 > +#define V4L2_BUF_FLAG_TSTAMP_SRC_SOE 0x00010000 > > /** > * struct v4l2_exportbuffer - export of video buffer as DMABUF file descriptor > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Sakari, On 02/20/2014 09:36 PM, Hans Verkuil wrote: > On 02/20/2014 08:41 PM, Sakari Ailus wrote: >> Some devices do not produce timestamps that correspond to the end of the >> frame. The user space should be informed on the matter. This patch achieves >> that by adding buffer flags (and a mask) for timestamp sources since more >> possible timestamping points are expected than just two. >> >> A three-bit mask is defined (V4L2_BUF_FLAG_TSTAMP_SRC_MASK) and two of the >> eight possible values is are defined V4L2_BUF_FLAG_TSTAMP_SRC_EOF for end of >> frame (value zero) V4L2_BUF_FLAG_TSTAMP_SRC_SOE for start of exposure (next >> value). > > Sorry, but I still have two small notes: > >> Signed-off-by: Sakari Ailus<sakari.ailus@iki.fi> >> --- >> since v5: >> - Add a note on software generated timestamp inaccuracy. >> >> Documentation/DocBook/media/v4l/io.xml | 38 +++++++++++++++++++++++++----- >> drivers/media/v4l2-core/videobuf2-core.c | 4 +++- >> include/media/videobuf2-core.h | 2 ++ >> include/uapi/linux/videodev2.h | 4 ++++ >> 4 files changed, 41 insertions(+), 7 deletions(-) >> >> diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml >> index 46d24b3..22b87bc 100644 >> --- a/Documentation/DocBook/media/v4l/io.xml >> +++ b/Documentation/DocBook/media/v4l/io.xml >> @@ -653,12 +653,6 @@ 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>For timestamp types that are sampled from the system clock >> -(V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC) it is guaranteed that the timestamp is >> -taken after the complete frame has been received (or transmitted in >> -case of video output devices). For other kinds of >> -timestamps this may vary depending on the driver.</para> >> - >> <table frame="none" pgwide="1" id="v4l2-buffer"> >> <title>struct<structname>v4l2_buffer</structname></title> >> <tgroup cols="4"> >> @@ -1119,6 +1113,38 @@ in which case caches have not been used.</entry> >> <entry>The CAPTURE buffer timestamp has been taken from the >> corresponding OUTPUT buffer. This flag applies only to mem2mem devices.</entry> >> </row> >> + <row> >> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant></entry> >> + <entry>0x00070000</entry> >> + <entry>Mask for timestamp sources below. The timestamp source >> + defines the point of time the timestamp is taken in relation to >> + the frame. Logical and operation between the Perhaps s/and/AND ? >> + <structfield>flags</structfield> field and >> + <constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant> produces the >> + value of the timestamp source.</entry> >> + </row> >> + <row> >> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_EOF</constant></entry> >> + <entry>0x00000000</entry> >> + <entry>End Of Frame. The buffer timestamp has been taken >> + when the last pixel of the frame has been received or the >> + last pixel of the frame has been transmitted. In practice, >> + software generated timestamps will typically be read from >> + the clock a small amount of time after the last pixel has >> + been received, depending on the system and other activity > > s/been received/been received or transmitted/ > >> + in it.</entry> >> + </row> >> + <row> >> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_SOE</constant></entry> V4L2_BUF_FLAG_TSTAMP_SRC_SOF (Start Of Frame) wouldn't fit here ? >> + <entry>0x00010000</entry> >> + <entry>Start Of Exposure. The buffer timestamp has been >> + taken when the exposure of the frame has begun. In >> + practice, software generated timestamps will typically be >> + read from the clock a small amount of time after the last >> + pixel has been received, depending on the system and other >> + activity in it. This is only valid for buffer type >> + <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>.</entry> > > I would move the last sentence up to just before "In practice...". The > way it is now it looks like an afterthought. > > I am also not sure whether the whole "In practice" sentence is valid > here. Certainly the bit about "the last pixel" isn't since this is the > "SOE" case and not the End Of Frame. In the case of the UVC driver (and that's > the only one using this timestamp source) the timestamps come from the > hardware as I understand it, so the "software generated" bit doesn't > apply. I agree, not it looks like a copy & paste from the "End Of Frame" paragraph. I guess for SOE it should have been, e.g. "...read from the clock a small amount of time after the _first_ pixel has been received" ? > I would actually be inclined to drop it altogether for this particular > timestamp source. But it's up to Laurent. Yup, the "a small amount of time" concept seems a bit vague here. It's not clear how long period it could be and the tolerance would like very across the hardware. > Regards, > > Hans > >> + </row> >> </tbody> >> </tgroup> >> </table> >> diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c >> index 5a5fb7f..6e314b0 100644 >> --- a/drivers/media/v4l2-core/videobuf2-core.c >> +++ b/drivers/media/v4l2-core/videobuf2-core.c >> @@ -2195,7 +2195,9 @@ int vb2_queue_init(struct vb2_queue *q) >> WARN_ON(!q->io_modes) || >> WARN_ON(!q->ops->queue_setup) || >> WARN_ON(!q->ops->buf_queue) || >> - WARN_ON(q->timestamp_type& ~V4L2_BUF_FLAG_TIMESTAMP_MASK)) >> + WARN_ON(q->timestamp_type& >> + ~(V4L2_BUF_FLAG_TIMESTAMP_MASK | >> + V4L2_BUF_FLAG_TSTAMP_SRC_MASK))) >> return -EINVAL; >> >> /* Warn that the driver should choose an appropriate timestamp type */ >> diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h >> index bef53ce..b6b992d 100644 >> --- a/include/media/videobuf2-core.h >> +++ b/include/media/videobuf2-core.h >> @@ -312,6 +312,8 @@ struct v4l2_fh; >> * @buf_struct_size: size of the driver-specific buffer structure; >> * "0" indicates the driver doesn't want to use a custom buffer >> * structure type, so sizeof(struct vb2_buffer) will is used >> + * @timestamp_type: Timestamp flags; V4L2_BUF_FLAGS_TIMESTAMP_* and nit: s/Timestamp/timestamp ? >> + * V4L2_BUF_FLAGS_TSTAMP_SRC_* >> * @gfp_flags: additional gfp flags used when allocating the buffers. >> * Typically this is 0, but it may be e.g. GFP_DMA or __GFP_DMA32 >> * to force the buffer allocation to a specific memory zone. >> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h >> index e9ee444..82e8661 100644 >> --- a/include/uapi/linux/videodev2.h >> +++ b/include/uapi/linux/videodev2.h >> @@ -695,6 +695,10 @@ struct v4l2_buffer { >> #define V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN 0x00000000 >> #define V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC 0x00002000 >> #define V4L2_BUF_FLAG_TIMESTAMP_COPY 0x00004000 >> +/* Timestamp sources. */ >> +#define V4L2_BUF_FLAG_TSTAMP_SRC_MASK 0x00070000 >> +#define V4L2_BUF_FLAG_TSTAMP_SRC_EOF 0x00000000 >> +#define V4L2_BUF_FLAG_TSTAMP_SRC_SOE 0x00010000 >> >> /** >> * struct v4l2_exportbuffer - export of video buffer as DMABUF file descriptor -- Regards, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/20/2014 10:10 PM, Sylwester Nawrocki wrote: >> I would actually be inclined to drop it altogether for this particular >> timestamp source. But it's up to Laurent. > > Yup, the "a small amount of time" concept seems a bit vague here. > It's not clear how long period it could be and the tolerance would like > very across the hardware. Sorry, I meant "would likely vary". -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Hans, On Thursday 20 February 2014 21:36:51 Hans Verkuil wrote: > On 02/20/2014 08:41 PM, Sakari Ailus wrote: > > Some devices do not produce timestamps that correspond to the end of the > > frame. The user space should be informed on the matter. This patch > > achieves > > that by adding buffer flags (and a mask) for timestamp sources since more > > possible timestamping points are expected than just two. > > > > A three-bit mask is defined (V4L2_BUF_FLAG_TSTAMP_SRC_MASK) and two of the > > eight possible values is are defined V4L2_BUF_FLAG_TSTAMP_SRC_EOF for end > > of frame (value zero) V4L2_BUF_FLAG_TSTAMP_SRC_SOE for start of exposure > > (next value). > > Sorry, but I still have two small notes: > > Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> > > --- > > since v5: > > - Add a note on software generated timestamp inaccuracy. > > > > Documentation/DocBook/media/v4l/io.xml | 38 +++++++++++++++++++++---- > > drivers/media/v4l2-core/videobuf2-core.c | 4 +++- > > include/media/videobuf2-core.h | 2 ++ > > include/uapi/linux/videodev2.h | 4 ++++ > > 4 files changed, 41 insertions(+), 7 deletions(-) > > > > diff --git a/Documentation/DocBook/media/v4l/io.xml > > b/Documentation/DocBook/media/v4l/io.xml index 46d24b3..22b87bc 100644 > > --- a/Documentation/DocBook/media/v4l/io.xml > > +++ b/Documentation/DocBook/media/v4l/io.xml > > @@ -653,12 +653,6 @@ 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>For timestamp types that are sampled from the system clock > > -(V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC) it is guaranteed that the timestamp > > is > > -taken after the complete frame has been received (or transmitted in > > -case of video output devices). For other kinds of > > -timestamps this may vary depending on the driver.</para> > > - > > > > <table frame="none" pgwide="1" id="v4l2-buffer"> > > > > <title>struct <structname>v4l2_buffer</structname></title> > > <tgroup cols="4"> > > > > @@ -1119,6 +1113,38 @@ in which case caches have not been used.</entry> > > <entry>The CAPTURE buffer timestamp has been taken from the > > corresponding OUTPUT buffer. This flag applies only to mem2mem > > devices.</entry> > > </row> > > + <row> > > + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant></entry> > > + <entry>0x00070000</entry> > > + <entry>Mask for timestamp sources below. The timestamp source > > + defines the point of time the timestamp is taken in relation to > > + the frame. Logical and operation between the > > + <structfield>flags</structfield> field and > > + <constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant> produces the > > + value of the timestamp source.</entry> > > + </row> > > + <row> > > + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_EOF</constant></entry> > > + <entry>0x00000000</entry> > > + <entry>End Of Frame. The buffer timestamp has been taken > > + when the last pixel of the frame has been received or the > > + last pixel of the frame has been transmitted. In practice, > > + software generated timestamps will typically be read from > > + the clock a small amount of time after the last pixel has > > + been received, depending on the system and other activity > > s/been received/been received or transmitted/ > > > + in it.</entry> > > + </row> > > + <row> > > + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_SOE</constant></entry> > > + <entry>0x00010000</entry> > > + <entry>Start Of Exposure. The buffer timestamp has been > > + taken when the exposure of the frame has begun. In > > + practice, software generated timestamps will typically be > > + read from the clock a small amount of time after the last > > + pixel has been received, depending on the system and other > > + activity in it. This is only valid for buffer type > > + <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>.</entry> > > I would move the last sentence up to just before "In practice...". The > way it is now it looks like an afterthought. > > I am also not sure whether the whole "In practice" sentence is valid > here. Certainly the bit about "the last pixel" isn't since this is the > "SOE" case and not the End Of Frame. In the case of the UVC driver (and > that's the only one using this timestamp source) the timestamps come from > the hardware as I understand it, so the "software generated" bit doesn't > apply. > > I would actually be inclined to drop it altogether for this particular > timestamp source. But it's up to Laurent. What do you mean, drop what altogether ? > > + </row> > > </tbody> > > </tgroup> > > </table>
On 02/21/2014 12:30 AM, Laurent Pinchart wrote: > Hi Hans, > > On Thursday 20 February 2014 21:36:51 Hans Verkuil wrote: >> On 02/20/2014 08:41 PM, Sakari Ailus wrote: >>> Some devices do not produce timestamps that correspond to the end of the >>> frame. The user space should be informed on the matter. This patch >>> achieves >>> that by adding buffer flags (and a mask) for timestamp sources since more >>> possible timestamping points are expected than just two. >>> >>> A three-bit mask is defined (V4L2_BUF_FLAG_TSTAMP_SRC_MASK) and two of the >>> eight possible values is are defined V4L2_BUF_FLAG_TSTAMP_SRC_EOF for end >>> of frame (value zero) V4L2_BUF_FLAG_TSTAMP_SRC_SOE for start of exposure >>> (next value). >> >> Sorry, but I still have two small notes: >>> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> >>> --- >>> since v5: >>> - Add a note on software generated timestamp inaccuracy. >>> >>> Documentation/DocBook/media/v4l/io.xml | 38 +++++++++++++++++++++---- >>> drivers/media/v4l2-core/videobuf2-core.c | 4 +++- >>> include/media/videobuf2-core.h | 2 ++ >>> include/uapi/linux/videodev2.h | 4 ++++ >>> 4 files changed, 41 insertions(+), 7 deletions(-) >>> >>> diff --git a/Documentation/DocBook/media/v4l/io.xml >>> b/Documentation/DocBook/media/v4l/io.xml index 46d24b3..22b87bc 100644 >>> --- a/Documentation/DocBook/media/v4l/io.xml >>> +++ b/Documentation/DocBook/media/v4l/io.xml >>> @@ -653,12 +653,6 @@ 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>For timestamp types that are sampled from the system clock >>> -(V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC) it is guaranteed that the timestamp >>> is >>> -taken after the complete frame has been received (or transmitted in >>> -case of video output devices). For other kinds of >>> -timestamps this may vary depending on the driver.</para> >>> - >>> >>> <table frame="none" pgwide="1" id="v4l2-buffer"> >>> >>> <title>struct <structname>v4l2_buffer</structname></title> >>> <tgroup cols="4"> >>> >>> @@ -1119,6 +1113,38 @@ in which case caches have not been used.</entry> >>> <entry>The CAPTURE buffer timestamp has been taken from the >>> corresponding OUTPUT buffer. This flag applies only to mem2mem >>> devices.</entry> >>> </row> >>> + <row> >>> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant></entry> >>> + <entry>0x00070000</entry> >>> + <entry>Mask for timestamp sources below. The timestamp source >>> + defines the point of time the timestamp is taken in relation to >>> + the frame. Logical and operation between the >>> + <structfield>flags</structfield> field and >>> + <constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant> produces the >>> + value of the timestamp source.</entry> >>> + </row> >>> + <row> >>> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_EOF</constant></entry> >>> + <entry>0x00000000</entry> >>> + <entry>End Of Frame. The buffer timestamp has been taken >>> + when the last pixel of the frame has been received or the >>> + last pixel of the frame has been transmitted. In practice, >>> + software generated timestamps will typically be read from >>> + the clock a small amount of time after the last pixel has >>> + been received, depending on the system and other activity >> >> s/been received/been received or transmitted/ >> >>> + in it.</entry> >>> + </row> >>> + <row> >>> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_SOE</constant></entry> >>> + <entry>0x00010000</entry> >>> + <entry>Start Of Exposure. The buffer timestamp has been >>> + taken when the exposure of the frame has begun. In >>> + practice, software generated timestamps will typically be >>> + read from the clock a small amount of time after the last >>> + pixel has been received, depending on the system and other >>> + activity in it. This is only valid for buffer type >>> + <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>.</entry> >> >> I would move the last sentence up to just before "In practice...". The >> way it is now it looks like an afterthought. >> >> I am also not sure whether the whole "In practice" sentence is valid >> here. Certainly the bit about "the last pixel" isn't since this is the >> "SOE" case and not the End Of Frame. In the case of the UVC driver (and >> that's the only one using this timestamp source) the timestamps come from >> the hardware as I understand it, so the "software generated" bit doesn't >> apply. >> >> I would actually be inclined to drop it altogether for this particular >> timestamp source. But it's up to Laurent. > > What do you mean, drop what altogether ? The "In practice ... activity in it." sentence. Regards, Hans > >>> + </row> >>> </tbody> >>> </tgroup> >>> </table> > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Hans, Hans Verkuil wrote: > On 02/20/2014 08:41 PM, Sakari Ailus wrote: >> Some devices do not produce timestamps that correspond to the end of the >> frame. The user space should be informed on the matter. This patch achieves >> that by adding buffer flags (and a mask) for timestamp sources since more >> possible timestamping points are expected than just two. >> >> A three-bit mask is defined (V4L2_BUF_FLAG_TSTAMP_SRC_MASK) and two of the >> eight possible values is are defined V4L2_BUF_FLAG_TSTAMP_SRC_EOF for end of >> frame (value zero) V4L2_BUF_FLAG_TSTAMP_SRC_SOE for start of exposure (next >> value). > > Sorry, but I still have two small notes: > >> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> >> --- >> since v5: >> - Add a note on software generated timestamp inaccuracy. >> >> Documentation/DocBook/media/v4l/io.xml | 38 +++++++++++++++++++++++++----- >> drivers/media/v4l2-core/videobuf2-core.c | 4 +++- >> include/media/videobuf2-core.h | 2 ++ >> include/uapi/linux/videodev2.h | 4 ++++ >> 4 files changed, 41 insertions(+), 7 deletions(-) >> >> diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml >> index 46d24b3..22b87bc 100644 >> --- a/Documentation/DocBook/media/v4l/io.xml >> +++ b/Documentation/DocBook/media/v4l/io.xml >> @@ -653,12 +653,6 @@ 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>For timestamp types that are sampled from the system clock >> -(V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC) it is guaranteed that the timestamp is >> -taken after the complete frame has been received (or transmitted in >> -case of video output devices). For other kinds of >> -timestamps this may vary depending on the driver.</para> >> - >> <table frame="none" pgwide="1" id="v4l2-buffer"> >> <title>struct <structname>v4l2_buffer</structname></title> >> <tgroup cols="4"> >> @@ -1119,6 +1113,38 @@ in which case caches have not been used.</entry> >> <entry>The CAPTURE buffer timestamp has been taken from the >> corresponding OUTPUT buffer. This flag applies only to mem2mem devices.</entry> >> </row> >> + <row> >> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant></entry> >> + <entry>0x00070000</entry> >> + <entry>Mask for timestamp sources below. The timestamp source >> + defines the point of time the timestamp is taken in relation to >> + the frame. Logical and operation between the >> + <structfield>flags</structfield> field and >> + <constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant> produces the >> + value of the timestamp source.</entry> >> + </row> >> + <row> >> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_EOF</constant></entry> >> + <entry>0x00000000</entry> >> + <entry>End Of Frame. The buffer timestamp has been taken >> + when the last pixel of the frame has been received or the >> + last pixel of the frame has been transmitted. In practice, >> + software generated timestamps will typically be read from >> + the clock a small amount of time after the last pixel has >> + been received, depending on the system and other activity > > s/been received/been received or transmitted/ I'll fix that. >> + in it.</entry> >> + </row> >> + <row> >> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_SOE</constant></entry> >> + <entry>0x00010000</entry> >> + <entry>Start Of Exposure. The buffer timestamp has been >> + taken when the exposure of the frame has begun. In >> + practice, software generated timestamps will typically be >> + read from the clock a small amount of time after the last >> + pixel has been received, depending on the system and other >> + activity in it. This is only valid for buffer type >> + <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>.</entry> > > I would move the last sentence up to just before "In practice...". The > way it is now it looks like an afterthought. Same here. > I am also not sure whether the whole "In practice" sentence is valid > here. Certainly the bit about "the last pixel" isn't since this is the > "SOE" case and not the End Of Frame. In the case of the UVC driver (and that's > the only one using this timestamp source) the timestamps come from the > hardware as I understand it, so the "software generated" bit doesn't > apply. Indeed. I don't know how the timestamp is even produced by the hardware. It's possible to calculate it (decrementing the readout time + exposure time from the end of frame timestamp) and that's what the devices supposedly do. The pre-frame exposure time isn't available to the host, so the end of frame timestamp cannot be calculated by the host from the camera generated timestamp. However the link to the host is USB which has a lot more latency than almost anything else which makes even hardware generated timestamps a little imprecise.
Hi Sylwester, Thanks for the comments. Sylwester Nawrocki wrote: ... > On 02/20/2014 09:36 PM, Hans Verkuil wrote: >> On 02/20/2014 08:41 PM, Sakari Ailus wrote: >>> Some devices do not produce timestamps that correspond to the end of the >>> frame. The user space should be informed on the matter. This patch >>> achieves >>> that by adding buffer flags (and a mask) for timestamp sources since >>> more >>> possible timestamping points are expected than just two. >>> >>> A three-bit mask is defined (V4L2_BUF_FLAG_TSTAMP_SRC_MASK) and two >>> of the >>> eight possible values is are defined V4L2_BUF_FLAG_TSTAMP_SRC_EOF for >>> end of >>> frame (value zero) V4L2_BUF_FLAG_TSTAMP_SRC_SOE for start of exposure >>> (next >>> value). >> >> Sorry, but I still have two small notes: >> >>> Signed-off-by: Sakari Ailus<sakari.ailus@iki.fi> >>> --- >>> since v5: >>> - Add a note on software generated timestamp inaccuracy. >>> >>> Documentation/DocBook/media/v4l/io.xml | 38 >>> +++++++++++++++++++++++++----- >>> drivers/media/v4l2-core/videobuf2-core.c | 4 +++- >>> include/media/videobuf2-core.h | 2 ++ >>> include/uapi/linux/videodev2.h | 4 ++++ >>> 4 files changed, 41 insertions(+), 7 deletions(-) >>> >>> diff --git a/Documentation/DocBook/media/v4l/io.xml >>> b/Documentation/DocBook/media/v4l/io.xml >>> index 46d24b3..22b87bc 100644 >>> --- a/Documentation/DocBook/media/v4l/io.xml >>> +++ b/Documentation/DocBook/media/v4l/io.xml >>> @@ -653,12 +653,6 @@ 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>For timestamp types that are sampled from the system clock >>> -(V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC) it is guaranteed that the >>> timestamp is >>> -taken after the complete frame has been received (or transmitted in >>> -case of video output devices). For other kinds of >>> -timestamps this may vary depending on the driver.</para> >>> - >>> <table frame="none" pgwide="1" id="v4l2-buffer"> >>> <title>struct<structname>v4l2_buffer</structname></title> >>> <tgroup cols="4"> >>> @@ -1119,6 +1113,38 @@ in which case caches have not been used.</entry> >>> <entry>The CAPTURE buffer timestamp has been taken from the >>> corresponding OUTPUT buffer. This flag applies only to >>> mem2mem devices.</entry> >>> </row> >>> + <row> >>> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant></entry> >>> + <entry>0x00070000</entry> >>> + <entry>Mask for timestamp sources below. The timestamp source >>> + defines the point of time the timestamp is taken in relation to >>> + the frame. Logical and operation between the > > Perhaps s/and/AND ? Is there a particular reason why? :-) >>> + <structfield>flags</structfield> field and >>> + <constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant> produces the >>> + value of the timestamp source.</entry> >>> + </row> >>> + <row> >>> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_EOF</constant></entry> >>> + <entry>0x00000000</entry> >>> + <entry>End Of Frame. The buffer timestamp has been taken >>> + when the last pixel of the frame has been received or the >>> + last pixel of the frame has been transmitted. In practice, >>> + software generated timestamps will typically be read from >>> + the clock a small amount of time after the last pixel has >>> + been received, depending on the system and other activity >> >> s/been received/been received or transmitted/ >> >>> + in it.</entry> >>> + </row> >>> + <row> >>> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_SOE</constant></entry> > > V4L2_BUF_FLAG_TSTAMP_SRC_SOF (Start Of Frame) wouldn't fit here ? That's different. Uvc devices provide a special start of exposure timestamp which is generated in camera itself. This is start of frame - exposure time (which, if AE is enabled, is a per-frame value). >>> + <entry>0x00010000</entry> >>> + <entry>Start Of Exposure. The buffer timestamp has been >>> + taken when the exposure of the frame has begun. In >>> + practice, software generated timestamps will typically be >>> + read from the clock a small amount of time after the last >>> + pixel has been received, depending on the system and other >>> + activity in it. This is only valid for buffer type >>> + <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>.</entry> >> >> I would move the last sentence up to just before "In practice...". The >> way it is now it looks like an afterthought. >> >> I am also not sure whether the whole "In practice" sentence is valid >> here. Certainly the bit about "the last pixel" isn't since this is the >> "SOE" case and not the End Of Frame. In the case of the UVC driver >> (and that's >> the only one using this timestamp source) the timestamps come from the >> hardware as I understand it, so the "software generated" bit doesn't >> apply. > > I agree, not it looks like a copy & paste from the "End Of Frame" > paragraph. I guess for SOE it should have been, e.g. It is. :-) I shouldn't have written this so late in the evening... I'll remove it. > "...read from the clock a small amount of time after the _first_ > pixel has been received" ? > >> I would actually be inclined to drop it altogether for this particular >> timestamp source. But it's up to Laurent. > > Yup, the "a small amount of time" concept seems a bit vague here. > It's not clear how long period it could be and the tolerance would like > very across the hardware. This is very system and device specific so we can't say it'd be exactly within certain limits. What we say instead is that we don't know, which is true. I think Hans's comment was related to this particular timestamp type; the same text is still present for the EOF timestamp.
Hi Sakari, On Friday 21 February 2014 11:31:38 Sakari Ailus wrote: > Hans Verkuil wrote: > > On 02/20/2014 08:41 PM, Sakari Ailus wrote: > >> Some devices do not produce timestamps that correspond to the end of the > >> frame. The user space should be informed on the matter. This patch > >> achieves that by adding buffer flags (and a mask) for timestamp sources > >> since more possible timestamping points are expected than just two. > >> > >> A three-bit mask is defined (V4L2_BUF_FLAG_TSTAMP_SRC_MASK) and two of > >> the > >> eight possible values is are defined V4L2_BUF_FLAG_TSTAMP_SRC_EOF for end > >> of frame (value zero) V4L2_BUF_FLAG_TSTAMP_SRC_SOE for start of exposure > >> (next value). > > > > Sorry, but I still have two small notes: > >> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> > >> --- > >> since v5: > >> - Add a note on software generated timestamp inaccuracy. > >> > >> Documentation/DocBook/media/v4l/io.xml | 38 > >> +++++++++++++++++++++++++----- > >> drivers/media/v4l2-core/videobuf2-core.c | 4 +++- > >> include/media/videobuf2-core.h | 2 ++ > >> include/uapi/linux/videodev2.h | 4 ++++ > >> 4 files changed, 41 insertions(+), 7 deletions(-) > >> > >> diff --git a/Documentation/DocBook/media/v4l/io.xml > >> b/Documentation/DocBook/media/v4l/io.xml index 46d24b3..22b87bc 100644 > >> --- a/Documentation/DocBook/media/v4l/io.xml > >> +++ b/Documentation/DocBook/media/v4l/io.xml > >> @@ -653,12 +653,6 @@ 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>For timestamp types that are sampled from the system clock > >> -(V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC) it is guaranteed that the timestamp > >> is > >> -taken after the complete frame has been received (or transmitted in > >> -case of video output devices). For other kinds of > >> -timestamps this may vary depending on the driver.</para> > >> - > >> > >> <table frame="none" pgwide="1" id="v4l2-buffer"> > >> > >> <title>struct <structname>v4l2_buffer</structname></title> > >> <tgroup cols="4"> > >> > >> @@ -1119,6 +1113,38 @@ in which case caches have not been used.</entry> > >> > >> <entry>The CAPTURE buffer timestamp has been taken from the > >> corresponding OUTPUT buffer. This flag applies only to mem2mem > >> devices.</entry>>> > >> </row> > >> > >> + <row> > >> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant></entry> > >> + <entry>0x00070000</entry> > >> + <entry>Mask for timestamp sources below. The timestamp source > >> + defines the point of time the timestamp is taken in relation to > >> + the frame. Logical and operation between the > >> + <structfield>flags</structfield> field and > >> + <constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant> produces the > >> + value of the timestamp source.</entry> > >> + </row> > >> + <row> > >> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_EOF</constant></entry> > >> + <entry>0x00000000</entry> > >> + <entry>End Of Frame. The buffer timestamp has been taken > >> + when the last pixel of the frame has been received or the > >> + last pixel of the frame has been transmitted. In practice, > >> + software generated timestamps will typically be read from > >> + the clock a small amount of time after the last pixel has > >> + been received, depending on the system and other activity > > > > s/been received/been received or transmitted/ > > I'll fix that. > > >> + in it.</entry> > >> + </row> > >> + <row> > >> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_SOE</constant></entry> > >> + <entry>0x00010000</entry> > >> + <entry>Start Of Exposure. The buffer timestamp has been > >> + taken when the exposure of the frame has begun. In > >> + practice, software generated timestamps will typically be > >> + read from the clock a small amount of time after the last > >> + pixel has been received, depending on the system and other > >> + activity in it. This is only valid for buffer type > >> + <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>.</entry> > > > > I would move the last sentence up to just before "In practice...". The > > way it is now it looks like an afterthought. > > Same here. > > > I am also not sure whether the whole "In practice" sentence is valid > > here. Certainly the bit about "the last pixel" isn't since this is the > > "SOE" case and not the End Of Frame. In the case of the UVC driver (and > > that's the only one using this timestamp source) the timestamps come from > > the hardware as I understand it, so the "software generated" bit doesn't > > apply. > > Indeed. I don't know how the timestamp is even produced by the hardware. In practice I don't know either, as that's hidden in the device firmware. The UVC specification just describes the timestamp as "The source clock time in native device clock units when the raw frame capture begins." Let's face it, I'm pretty sure many devices don't care much and will send a time stamp that's taken at some other, possibly semi-random, time. > It's possible to calculate it (decrementing the readout time + exposure > time from the end of frame timestamp) and that's what the devices > supposedly do. The pre-frame exposure time isn't available to the host, > so the end of frame timestamp cannot be calculated by the host from the > camera generated timestamp. > > However the link to the host is USB which has a lot more latency than > almost anything else which makes even hardware generated timestamps a > little imprecise. Why so ? There will be a jitter in frame arrival, but the hardware timestamp should be accurate (at least if properly generated by the camera firmware).
Hi Laurent, On Fri, Feb 21, 2014 at 12:58:58PM +0100, Laurent Pinchart wrote: ... > > It's possible to calculate it (decrementing the readout time + exposure > > time from the end of frame timestamp) and that's what the devices > > supposedly do. The pre-frame exposure time isn't available to the host, > > so the end of frame timestamp cannot be calculated by the host from the > > camera generated timestamp. > > > > However the link to the host is USB which has a lot more latency than > > almost anything else which makes even hardware generated timestamps a > > little imprecise. > > Why so ? There will be a jitter in frame arrival, but the hardware timestamp > should be accurate (at least if properly generated by the camera firmware). Yes, the hardware timestamp should be accurate on its own, but as there's delay and jitter converting that into something that's relevant on the host adds some uncertainty. AFAIR the accuracy of the camera generated timestamp was still much better than that of the driver generated one, right?
Hi Sakari, On Friday 21 February 2014 15:04:48 Sakari Ailus wrote: > Hi Laurent, > > On Fri, Feb 21, 2014 at 12:58:58PM +0100, Laurent Pinchart wrote: > ... > > > > It's possible to calculate it (decrementing the readout time + exposure > > > time from the end of frame timestamp) and that's what the devices > > > supposedly do. The pre-frame exposure time isn't available to the host, > > > so the end of frame timestamp cannot be calculated by the host from the > > > camera generated timestamp. > > > > > > However the link to the host is USB which has a lot more latency than > > > almost anything else which makes even hardware generated timestamps a > > > little imprecise. > > > > Why so ? There will be a jitter in frame arrival, but the hardware > > timestamp should be accurate (at least if properly generated by the > > camera firmware). > > Yes, the hardware timestamp should be accurate on its own, but as there's > delay and jitter converting that into something that's relevant on the host > adds some uncertainty. AFAIR the accuracy of the camera generated timestamp > was still much better than that of the driver generated one, right? Yes it is, as the conversion mechanism is stats-based and takes jitter and delays into account.
diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 46d24b3..22b87bc 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -653,12 +653,6 @@ 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>For timestamp types that are sampled from the system clock -(V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC) it is guaranteed that the timestamp is -taken after the complete frame has been received (or transmitted in -case of video output devices). For other kinds of -timestamps this may vary depending on the driver.</para> - <table frame="none" pgwide="1" id="v4l2-buffer"> <title>struct <structname>v4l2_buffer</structname></title> <tgroup cols="4"> @@ -1119,6 +1113,38 @@ in which case caches have not been used.</entry> <entry>The CAPTURE buffer timestamp has been taken from the corresponding OUTPUT buffer. This flag applies only to mem2mem devices.</entry> </row> + <row> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant></entry> + <entry>0x00070000</entry> + <entry>Mask for timestamp sources below. The timestamp source + defines the point of time the timestamp is taken in relation to + the frame. Logical and operation between the + <structfield>flags</structfield> field and + <constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant> produces the + value of the timestamp source.</entry> + </row> + <row> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_EOF</constant></entry> + <entry>0x00000000</entry> + <entry>End Of Frame. The buffer timestamp has been taken + when the last pixel of the frame has been received or the + last pixel of the frame has been transmitted. In practice, + software generated timestamps will typically be read from + the clock a small amount of time after the last pixel has + been received, depending on the system and other activity + in it.</entry> + </row> + <row> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_SOE</constant></entry> + <entry>0x00010000</entry> + <entry>Start Of Exposure. The buffer timestamp has been + taken when the exposure of the frame has begun. In + practice, software generated timestamps will typically be + read from the clock a small amount of time after the last + pixel has been received, depending on the system and other + activity in it. This is only valid for buffer type + <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>.</entry> + </row> </tbody> </tgroup> </table> diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index 5a5fb7f..6e314b0 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -2195,7 +2195,9 @@ int vb2_queue_init(struct vb2_queue *q) WARN_ON(!q->io_modes) || WARN_ON(!q->ops->queue_setup) || WARN_ON(!q->ops->buf_queue) || - WARN_ON(q->timestamp_type & ~V4L2_BUF_FLAG_TIMESTAMP_MASK)) + WARN_ON(q->timestamp_type & + ~(V4L2_BUF_FLAG_TIMESTAMP_MASK | + V4L2_BUF_FLAG_TSTAMP_SRC_MASK))) return -EINVAL; /* Warn that the driver should choose an appropriate timestamp type */ diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h index bef53ce..b6b992d 100644 --- a/include/media/videobuf2-core.h +++ b/include/media/videobuf2-core.h @@ -312,6 +312,8 @@ struct v4l2_fh; * @buf_struct_size: size of the driver-specific buffer structure; * "0" indicates the driver doesn't want to use a custom buffer * structure type, so sizeof(struct vb2_buffer) will is used + * @timestamp_type: Timestamp flags; V4L2_BUF_FLAGS_TIMESTAMP_* and + * V4L2_BUF_FLAGS_TSTAMP_SRC_* * @gfp_flags: additional gfp flags used when allocating the buffers. * Typically this is 0, but it may be e.g. GFP_DMA or __GFP_DMA32 * to force the buffer allocation to a specific memory zone. diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h index e9ee444..82e8661 100644 --- a/include/uapi/linux/videodev2.h +++ b/include/uapi/linux/videodev2.h @@ -695,6 +695,10 @@ struct v4l2_buffer { #define V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN 0x00000000 #define V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC 0x00002000 #define V4L2_BUF_FLAG_TIMESTAMP_COPY 0x00004000 +/* Timestamp sources. */ +#define V4L2_BUF_FLAG_TSTAMP_SRC_MASK 0x00070000 +#define V4L2_BUF_FLAG_TSTAMP_SRC_EOF 0x00000000 +#define V4L2_BUF_FLAG_TSTAMP_SRC_SOE 0x00010000 /** * struct v4l2_exportbuffer - export of video buffer as DMABUF file descriptor
Some devices do not produce timestamps that correspond to the end of the frame. The user space should be informed on the matter. This patch achieves that by adding buffer flags (and a mask) for timestamp sources since more possible timestamping points are expected than just two. A three-bit mask is defined (V4L2_BUF_FLAG_TSTAMP_SRC_MASK) and two of the eight possible values is are defined V4L2_BUF_FLAG_TSTAMP_SRC_EOF for end of frame (value zero) V4L2_BUF_FLAG_TSTAMP_SRC_SOE for start of exposure (next value). Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> --- since v5: - Add a note on software generated timestamp inaccuracy. Documentation/DocBook/media/v4l/io.xml | 38 +++++++++++++++++++++++++----- drivers/media/v4l2-core/videobuf2-core.c | 4 +++- include/media/videobuf2-core.h | 2 ++ include/uapi/linux/videodev2.h | 4 ++++ 4 files changed, 41 insertions(+), 7 deletions(-)