After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 591451 - [v4l2] causes hanging stream when VIDIOC_G_PARM is not supported
[v4l2] causes hanging stream when VIDIOC_G_PARM is not supported
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.15
Other Linux
: Normal blocker
: 0.10.16
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-08-11 14:16 UTC by Hans de Goede
Modified: 2009-08-14 12:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
PATCH: v4l2 plugin causes hanging stream when VIDIOC_G_PARM is not supported (1.22 KB, patch)
2009-08-11 14:18 UTC, Hans de Goede
committed Details | Review

Description Hans de Goede 2009-08-11 14:16:00 UTC
Hi,

I've been debugging this:
https://bugzilla.redhat.com/show_bug.cgi?id=467961

A little (and yes it still happens with up2date everything), the problem is
that the pwc driver does not support the VIDIOC_G_PARM call, which
results in gv4l2src_calls.c: st_v4l2src_set_capture() not setting v4l2src->
fps_n / fps_d, so they stay 0.

However gstv4l2src.c: gst_v4l2src_create() calls gst_util_uint64_scale_int()
using v4l2src->fps_n / fps_d unconditionally.

This causes cheese, which uses the following pipeline:
v4l2src name=video_source device=/dev/video1 ! capsfilter name=capsfilter caps=video/x-raw-rgb,width=640,height=480,framerate=15/1;video/x-raw-yuv,width=640,height=480,framerate=15/1 ! identity

To hang, while filling the terminal it was started from with:
(cheese:5273): GStreamer-CRITICAL **: gst_util_uint64_scale_int: assertion `denom > 0' failed

(cheese:5273): GStreamer-CRITICAL **: gst_util_uint64_scale_int: assertion `denom > 0' failed

(cheese:5273): GStreamer-CRITICAL **: gst_util_uint64_scale_int: assertion `denom > 0' failed

The attached patch fixes this by making the substraction of the latency from the timestamp conditional.
Comment 1 Hans de Goede 2009-08-11 14:18:58 UTC
Created attachment 140441 [details] [review]
PATCH: v4l2 plugin causes hanging stream when VIDIOC_G_PARM is not supported
Comment 2 Tim-Philipp Müller 2009-08-12 23:03:03 UTC
Hrm, that's bad. Guess we should be doing something about this before the release, so marking as blocker for now.

I presume the 'hang' was caused by all buffers being timestamped with a timestamp of 0 (which then get dropped by the sink)?
Comment 3 Hans de Goede 2009-08-13 07:26:50 UTC
(In reply to comment #2)
> I presume the 'hang' was caused by all buffers being timestamped with a
> timestamp of 0 (which then get dropped by the sink)?
> 

Yes I think so, I didn't investigate further, fixing the timestamp generation
code to work when we have no known framerate fixes things.
Comment 4 Tim-Philipp Müller 2009-08-14 12:32:02 UTC
Committed, thanks:

commit 10d41286d5bf738a8a7f7537682958b085990e86
Author: Hans de Goede <jwrdegoede@fedoraproject.org>
Date:   Fri Aug 14 12:44:06 2009 +0100

    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.