v4l2src: fix 'hang' with some cameras caused by bad timestamping if no framerate is available

For cameras/drivers that don't support e.g. VIDIOC_G_PARM we'd end up without
a framerate and would try to divide by 0, causing run-time warnings and all
frames to be timestamped with 0, which makes sinks that sync against the clock
drop them, causing 'hangs' (observed with the pwc driver and a Logitech QuickCam
Pro 4000). So if we do not know the framerate, simply don't adjust the
timestamps. Fixes #591451.

1 files changed, 11 insertions, 9 deletions

diff --git a/sys/v4l2/gstv4l2src.c b/sys/v4l2/gstv4l2src.c
index 2f0fef9e..463bef3a 100644
--- a/sys/v4l2/gstv4l2src.c
+++ b/sys/v4l2/gstv4l2src.c
@@ -916,20 +916,22 @@ gst_v4l2src_create (GstPushSrc * src, GstBuffer ** buf)
     GST_OBJECT_UNLOCK (v4l2src);
 
     if (clock) {
-      GstClockTime latency;
-
       /* the time now is the time of the clock minus the base time */
       timestamp = gst_clock_get_time (clock) - timestamp;
       gst_object_unref (clock);
 
-      latency =
-          gst_util_uint64_scale_int (GST_SECOND, v4l2src->fps_d,
-          v4l2src->fps_n);
+      /* if we have a framerate adjust timestamp for frame latency */
+      if (v4l2src->fps_n > 0 && v4l2src->fps_d > 0) {
+        GstClockTime latency;
+
+        latency = gst_util_uint64_scale_int (GST_SECOND, v4l2src->fps_d,
+            v4l2src->fps_n);
 
-      if (timestamp > latency)
-        timestamp -= latency;
-      else
-        timestamp = 0;
+        if (timestamp > latency)
+          timestamp -= latency;
+        else
+          timestamp = 0;
+      }
     }
 
     /* FIXME: use the timestamp from the buffer itself! */