All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: "Paulo Assis" <pj.assis@gmail.com>,
	"Rémi Denis-Courmont" <remi@remlab.net>,
	"Grazvydas Ignotas" <notasas@gmail.com>,
	"Linux Media Mailing List" <linux-media@vger.kernel.org>,
	"Hans Verkuil" <hans.verkuil@cisco.com>,
	"Mauro Carvalho Chehab" <mchehab@redhat.com>
Subject: Re: (bisected) Logitech C920 (uvcvideo) stutters since 3.9
Date: Fri, 05 Dec 2014 16:58:50 +0200	[thread overview]
Message-ID: <4697151.yGpSQ7NaTv@avalon> (raw)
In-Reply-To: <20141105161147.GW3136@valkosipuli.retiisi.org.uk>

Hi Sakari,

On Wednesday 05 November 2014 18:11:47 Sakari Ailus wrote:
> On Wed, Nov 05, 2014 at 10:13:45AM +0000, Paulo Assis wrote:
> > 2014-11-04 23:32 GMT+00:00 Sakari Ailus <sakari.ailus@iki.fi>:
> >> Sakari Ailus wrote:
> >>> yavta does, for example, print both the monotonic timestamp from the
> >>> buffer and the time when the buffer has been dequeued:
> >>> 
> >>> <URL:http://git.ideasonboard.org/yavta.git>
> >>> 
> >>>       $ yavta -c /dev/video0
> >>> 
> >>> should do it. The first timestamp is the buffer timestamp, and the
> >>> latter is the one is taken when the buffer is dequeued (by yavta).
> > 
> > I've done exaclty this with guvcview, and uvcvideo timestamps are
> > completly unreliable, in some devices they may have just a bit of
> > jitter, but in others, values go back and forth in time, making them
> > totally unusable.
> > Honestly I wouldn't trust device firmware to provide correct
> > timestamps, or at least I would have the driver perform a couple of
> > tests to make sure these are at least reasonable: within an expected
> > interval (maybe comparing it to a reference monotonic clock) or at the
> > very least making sure the current frame timestamp is not lower than
> > the previous one.
> 
> Using the hardware timestamps provides much better accuracy than the
> software ones --- the real time capabilities of the USB aren't exactly the
> same as on some other busses.
> 
> Freel free to try the follow-up patches; I've only compile tested them so
> far.
> 
> It might be possible to add some heuristics to detect bad implementations
> but perhaps we could simply flag them for now. If heuristics would be used,
> then one would likely have a few bad timestamps every time the device is
> accessed the first time anyway. Besides, the timestamp type changes as a
> result.
> 
> I wonder what Laurent thinks. :-)

I've been toying with the idea of a heuristic, but decided to delay the 
implementation until needed. I'd like to find the root cause of the issue 
first before deciding how to fix it.

-- 
Regards,

Laurent Pinchart


  parent reply	other threads:[~2014-12-05 14:58 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-02  2:03 (bisected) Logitech C920 (uvcvideo) stutters since 3.9 Grazvydas Ignotas
2014-11-02 22:57 ` Sakari Ailus
2014-11-03 23:16   ` Grazvydas Ignotas
2014-11-04 11:58     ` Sakari Ailus
2014-11-04 12:42       ` Rémi Denis-Courmont
2014-11-04 15:02         ` Paulo Assis
2014-11-04 15:36           ` Sakari Ailus
2014-11-04 23:32             ` Sakari Ailus
2014-11-05 10:13               ` Paulo Assis
2014-11-05 14:05                 ` Laurent Pinchart
2014-11-05 22:29                   ` Paulo Assis
2014-11-05 16:11                 ` Sakari Ailus
2014-11-05 16:12                   ` [RFC 1/2] uvc: Add a quirk flag for cameras that do not produce correct timestamps Sakari Ailus
2014-11-05 16:12                     ` [RFC 2/2] uvc: Use UVC_QUIRK_BAD_TIMESTAMP quirk flag for Logitech C920 Sakari Ailus
2015-11-09 16:18                     ` [RFC 1/2] uvc: Add a quirk flag for cameras that do not produce correct timestamps Laurent Pinchart
2014-12-05 14:58                   ` Laurent Pinchart [this message]
2014-11-04 20:41         ` (bisected) Logitech C920 (uvcvideo) stutters since 3.9 Rémi Denis-Courmont
2014-11-05 14:05           ` Laurent Pinchart
2014-11-05 22:29             ` Grazvydas Ignotas
2014-11-17 15:36               ` Grazvydas Ignotas
2014-11-18  8:39                 ` Hans Verkuil
2014-12-05 11:46               ` Laurent Pinchart
2014-12-06  0:25                 ` Grazvydas Ignotas
2014-12-07 19:23                   ` Laurent Pinchart
2014-12-07 21:23                     ` Grazvydas Ignotas
2015-03-29 20:59                       ` Milos Ivanovic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4697151.yGpSQ7NaTv@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=hans.verkuil@cisco.com \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@redhat.com \
    --cc=notasas@gmail.com \
    --cc=pj.assis@gmail.com \
    --cc=remi@remlab.net \
    --cc=sakari.ailus@iki.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.