Re: [RFCv2 API PATCH 12/28] v4l2-core: Add new V4L2_CAP_MONOTONIC_TS capability.
On Thu, Sep 13, 2012 at 10:56:41PM +0200, Hans Verkuil wrote: On Thu September 13 2012 22:50:32 Laurent Pinchart wrote: Hi Sakari, On Thursday 13 September 2012 23:38:14 Sakari Ailus wrote: On Fri, Sep 07, 2012 at 03:29:12PM +0200, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com Add a new flag that tells userspace that the monotonic clock is used for timestamps and update the documentation accordingly. We decided on this new flag during the 2012 Media Workshop. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/io.xml | 10 +++--- Documentation/DocBook/media/v4l/vidioc-dqevent.xml |3 ++- Documentation/DocBook/media/v4l/vidioc-querycap.xml |7 +++ include/linux/videodev2.h |1 + 4 files changed, 17 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 2dc39d8..b680d66 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -582,10 +582,14 @@ applications when an output stream./entry entrystruct timeval/entry entrystructfieldtimestamp/structfield/entry entry/entry - entryparaFor input streams this is the + entryparaThis is either the system time (as returned by the functiongettimeofday()/function -function) when the first data byte was captured. For output streams -the data will not be displayed before this time, secondary to the +function) or a monotonic timestamp (as returned by the +functionclock_gettime(CLOCK_MONOTONIC, amp;ts)/function function). +A monotonic timestamp is used if the constantV4L2_CAP_MONOTONIC_TS/constant +capability is set, otherwise the system time is used. +For input streams this is the timestamp when the first data byte was captured. +For output streams the data will not be displayed before this time, secondary to the I have an alternative proposal. The type of the desired timestamps depend on the use case, not the driver used to capture the buffers. Thus we could also give the choice to the user by means of e.g. a control. Or a buffer flag. I will need something similar to select device-specific timestamps. However, for wall clock vs. monotonic clock, I don't think there's a reason to let applications decide to use the wall clock. It would be a broken use case. I don't think we should let applications decide in this case. I agree. How about the raw monotonic clock then? You can also tell clock_gettime() what kind of timestamp you're interested in. It's also true monotonic timestamps are being used elsewhere, so the selection should apply there as well. On the other hand, reporting a timespec instead of a timeval would be a good idea. I'm tempted. Microsecond precision seems more than sufficient to me for video frames. I see no good reason for messing around with the v4l2_buffer struct just to get a timespec in. The extra precision could be confusing for some existing users. Another thing, however not related to this patch, is that the spec mentions the timestamp is taken when the first data byte is captured. In practice many (if not most) drivers produce the timestamp when the buffer is ready. The reason is that some hardware simply does not produce interrupts at when the reception of the frame starts. What kind of timestamps should be used in that case? The frame start event can be used to get information on when the frame starts. Regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 12/28] v4l2-core: Add new V4L2_CAP_MONOTONIC_TS capability.
On Fri 14 September 2012 11:02:22 Sakari Ailus wrote: On Thu, Sep 13, 2012 at 10:56:41PM +0200, Hans Verkuil wrote: On Thu September 13 2012 22:50:32 Laurent Pinchart wrote: Hi Sakari, On Thursday 13 September 2012 23:38:14 Sakari Ailus wrote: On Fri, Sep 07, 2012 at 03:29:12PM +0200, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com Add a new flag that tells userspace that the monotonic clock is used for timestamps and update the documentation accordingly. We decided on this new flag during the 2012 Media Workshop. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/io.xml | 10 +++--- Documentation/DocBook/media/v4l/vidioc-dqevent.xml |3 ++- Documentation/DocBook/media/v4l/vidioc-querycap.xml |7 +++ include/linux/videodev2.h |1 + 4 files changed, 17 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 2dc39d8..b680d66 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -582,10 +582,14 @@ applications when an output stream./entry entrystruct timeval/entry entrystructfieldtimestamp/structfield/entry entry/entry - entryparaFor input streams this is the + entryparaThis is either the system time (as returned by the functiongettimeofday()/function -function) when the first data byte was captured. For output streams -the data will not be displayed before this time, secondary to the +function) or a monotonic timestamp (as returned by the +functionclock_gettime(CLOCK_MONOTONIC, amp;ts)/function function). +A monotonic timestamp is used if the constantV4L2_CAP_MONOTONIC_TS/constant +capability is set, otherwise the system time is used. +For input streams this is the timestamp when the first data byte was captured. +For output streams the data will not be displayed before this time, secondary to the I have an alternative proposal. The type of the desired timestamps depend on the use case, not the driver used to capture the buffers. Thus we could also give the choice to the user by means of e.g. a control. Or a buffer flag. I will need something similar to select device-specific timestamps. However, for wall clock vs. monotonic clock, I don't think there's a reason to let applications decide to use the wall clock. It would be a broken use case. I don't think we should let applications decide in this case. I agree. How about the raw monotonic clock then? You can also tell clock_gettime() what kind of timestamp you're interested in. It's also true monotonic timestamps are being used elsewhere, so the selection should apply there as well. ALSA only has wallclock time and monotonic clock, not raw monotonic. The important thing right now is that apps can tell that a driver uses a monotonic clock. In the future we might want to refine that, but such efforts should be done together with ALSA. In other words, let's not add stuff that does not have any users. Regards, Hans On the other hand, reporting a timespec instead of a timeval would be a good idea. I'm tempted. Microsecond precision seems more than sufficient to me for video frames. I see no good reason for messing around with the v4l2_buffer struct just to get a timespec in. The extra precision could be confusing for some existing users. Another thing, however not related to this patch, is that the spec mentions the timestamp is taken when the first data byte is captured. In practice many (if not most) drivers produce the timestamp when the buffer is ready. The reason is that some hardware simply does not produce interrupts at when the reception of the frame starts. What kind of timestamps should be used in that case? The frame start event can be used to get information on when the frame starts. Regards, -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 12/28] v4l2-core: Add new V4L2_CAP_MONOTONIC_TS capability.
On Friday 07 September 2012 15:29:12 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com Add a new flag that tells userspace that the monotonic clock is used for timestamps and update the documentation accordingly. We decided on this new flag during the 2012 Media Workshop. Signed-off-by: Hans Verkuil hans.verk...@cisco.com Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 12/28] v4l2-core: Add new V4L2_CAP_MONOTONIC_TS capability.
Hi Hans, Thanks for the patch! On Fri, Sep 07, 2012 at 03:29:12PM +0200, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com Add a new flag that tells userspace that the monotonic clock is used for timestamps and update the documentation accordingly. We decided on this new flag during the 2012 Media Workshop. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/io.xml | 10 +++--- Documentation/DocBook/media/v4l/vidioc-dqevent.xml |3 ++- Documentation/DocBook/media/v4l/vidioc-querycap.xml |7 +++ include/linux/videodev2.h |1 + 4 files changed, 17 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 2dc39d8..b680d66 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -582,10 +582,14 @@ applications when an output stream./entry entrystruct timeval/entry entrystructfieldtimestamp/structfield/entry entry/entry - entryparaFor input streams this is the + entryparaThis is either the system time (as returned by the functiongettimeofday()/function -function) when the first data byte was captured. For output streams -the data will not be displayed before this time, secondary to the +function) or a monotonic timestamp (as returned by the +functionclock_gettime(CLOCK_MONOTONIC, amp;ts)/function function). +A monotonic timestamp is used if the constantV4L2_CAP_MONOTONIC_TS/constant +capability is set, otherwise the system time is used. +For input streams this is the timestamp when the first data byte was captured. +For output streams the data will not be displayed before this time, secondary to the I have an alternative proposal. The type of the desired timestamps depend on the use case, not the driver used to capture the buffers. Thus we could also give the choice to the user by means of e.g. a control. If we'd make it configurable (applications would still get the wallclock time unless they ask for monotonic time), we'd have a chance to add more precision by using struct timespec (ns precision) instead of struct timeval (us precision). struct timespec is also used by V4L2 events. Adding support for CLOCK_MONOTONIC_RAW would also be a non-issue. Additional helper function could be used to generate the timestamp of the desired type. What do you think? Cheers, -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 12/28] v4l2-core: Add new V4L2_CAP_MONOTONIC_TS capability.
Hi Sakari, On Thursday 13 September 2012 23:38:14 Sakari Ailus wrote: On Fri, Sep 07, 2012 at 03:29:12PM +0200, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com Add a new flag that tells userspace that the monotonic clock is used for timestamps and update the documentation accordingly. We decided on this new flag during the 2012 Media Workshop. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/io.xml | 10 +++--- Documentation/DocBook/media/v4l/vidioc-dqevent.xml |3 ++- Documentation/DocBook/media/v4l/vidioc-querycap.xml |7 +++ include/linux/videodev2.h |1 + 4 files changed, 17 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 2dc39d8..b680d66 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -582,10 +582,14 @@ applications when an output stream./entry entrystruct timeval/entry entrystructfieldtimestamp/structfield/entry entry/entry - entryparaFor input streams this is the + entryparaThis is either the system time (as returned by the functiongettimeofday()/function -function) when the first data byte was captured. For output streams -the data will not be displayed before this time, secondary to the +function) or a monotonic timestamp (as returned by the +functionclock_gettime(CLOCK_MONOTONIC, amp;ts)/function function). +A monotonic timestamp is used if the constantV4L2_CAP_MONOTONIC_TS/constant +capability is set, otherwise the system time is used. +For input streams this is the timestamp when the first data byte was captured. +For output streams the data will not be displayed before this time, secondary to the I have an alternative proposal. The type of the desired timestamps depend on the use case, not the driver used to capture the buffers. Thus we could also give the choice to the user by means of e.g. a control. Or a buffer flag. I will need something similar to select device-specific timestamps. However, for wall clock vs. monotonic clock, I don't think there's a reason to let applications decide to use the wall clock. It would be a broken use case. I don't think we should let applications decide in this case. On the other hand, reporting a timespec instead of a timeval would be a good idea. I'm tempted. If we'd make it configurable (applications would still get the wallclock time unless they ask for monotonic time), we'd have a chance to add more precision by using struct timespec (ns precision) instead of struct timeval (us precision). struct timespec is also used by V4L2 events. Adding support for CLOCK_MONOTONIC_RAW would also be a non-issue. Additional helper function could be used to generate the timestamp of the desired type. What do you think? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 12/28] v4l2-core: Add new V4L2_CAP_MONOTONIC_TS capability.
On Thu September 13 2012 22:50:32 Laurent Pinchart wrote: Hi Sakari, On Thursday 13 September 2012 23:38:14 Sakari Ailus wrote: On Fri, Sep 07, 2012 at 03:29:12PM +0200, Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com Add a new flag that tells userspace that the monotonic clock is used for timestamps and update the documentation accordingly. We decided on this new flag during the 2012 Media Workshop. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- Documentation/DocBook/media/v4l/io.xml | 10 +++--- Documentation/DocBook/media/v4l/vidioc-dqevent.xml |3 ++- Documentation/DocBook/media/v4l/vidioc-querycap.xml |7 +++ include/linux/videodev2.h |1 + 4 files changed, 17 insertions(+), 4 deletions(-) diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 2dc39d8..b680d66 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -582,10 +582,14 @@ applications when an output stream./entry entrystruct timeval/entry entrystructfieldtimestamp/structfield/entry entry/entry - entryparaFor input streams this is the + entryparaThis is either the system time (as returned by the functiongettimeofday()/function -function) when the first data byte was captured. For output streams -the data will not be displayed before this time, secondary to the +function) or a monotonic timestamp (as returned by the +functionclock_gettime(CLOCK_MONOTONIC, amp;ts)/function function). +A monotonic timestamp is used if the constantV4L2_CAP_MONOTONIC_TS/constant +capability is set, otherwise the system time is used. +For input streams this is the timestamp when the first data byte was captured. +For output streams the data will not be displayed before this time, secondary to the I have an alternative proposal. The type of the desired timestamps depend on the use case, not the driver used to capture the buffers. Thus we could also give the choice to the user by means of e.g. a control. Or a buffer flag. I will need something similar to select device-specific timestamps. However, for wall clock vs. monotonic clock, I don't think there's a reason to let applications decide to use the wall clock. It would be a broken use case. I don't think we should let applications decide in this case. I agree. On the other hand, reporting a timespec instead of a timeval would be a good idea. I'm tempted. Microsecond precision seems more than sufficient to me for video frames. I see no good reason for messing around with the v4l2_buffer struct just to get a timespec in. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv2 API PATCH 12/28] v4l2-core: Add new V4L2_CAP_MONOTONIC_TS capability.
On 09/07/2012 03:29 PM, Hans Verkuil wrote: From: Hans Verkuilhans.verk...@cisco.com Add a new flag that tells userspace that the monotonic clock is used for timestamps and update the documentation accordingly. We decided on this new flag during the 2012 Media Workshop. Signed-off-by: Hans Verkuilhans.verk...@cisco.com Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
