GNOME Bugzilla – Bug 732910
v4l2src: Dectect and workaround decreasing HW timestamp
Last modified: 2015-05-16 22:28:27 UTC
This is a potential future enhancement, some buggy HW (like 2008 iSight) gives decreasing time-stamp from time to time. It would be nice enhancement if we could detect, and fallback somehow to avoid the disaster. One way to detect that, is through excessive latency. V4L2 timestamp are usually taken form MONOTOINIC clock, but may on older kernel come from wall clock. So we'd have to watch the diff, which and fallback is it makes no sense anymore. Kernel maintainers are informed, and are also looking for a workaround.
Created attachment 285487 [details] [review] Detect bad drivers timesamp This is a first attempt, works nicely with the buggy and non-buggy camera I owned, but would really appreciate some feedback if anyone owns buggy cameras.
Comment on attachment 285487 [details] [review] Detect bad drivers timesamp commit b706103fab54d38136ca234cb6013d782651d59f Author: Nicolas Dufresne <nicolas.dufresne@collabora.co.uk> Date: Fri Sep 5 08:29:20 2014 -0400 v4l2: Detect bad drivers timestamps Even though the UVC driver do a great deal of effort to prevent bad timestamp to be sent to userspace, there still exist UVC hardware that are so buggy that the timestamp endup nearly random. This code detect and ignore timestamp from these drivers, making these camera usable. This has been tested on both invalid and valid cameras, making sure it does not trigger for valid cameras. https://bugzilla.gnome.org/show_bug.cgi?id=732910
This patch makes feed from well known camera, like the C920, work nicely. I am tempted to back port this patch to 1.4, any comment ?