[gstreamer-bugs] [Bug 626300] gstbasesink.c(2686): gst_base_sink_is_too_late (): /GstPlayBin:playbin0/GstBin:vbin/GstAutoVideoSink:videosink/GstXvImageSink:videosink-actual-sink-xvimage: There may be a timestamping problem, or this computer is too slow.

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=626300
  GStreamer | don't know | 0.10.30

--- Comment #13 from Nicolas Mailhot <Nicolas.Mailhot at LaPoste.net> 2010-08-07 15:51:53 UTC ---
(In reply to comment #12)
> Well, this is just not really how you're supposed to use /dev/videoN.

Why not? If I wanted static content, I'd be using a dvd not a capture card. It
worked perfectly when the hardware was bought (before the software stack was
"improved" by PA and other rewrites) 

> If the input is live, you should be using a source element that handles that
> properly, e.g. v4l2src. If v4l2src doesn't support your format of choice, you
> should add support for that.

It's an MPEG2 capture card. Is there anything more common or better supported
by gstreamer (real video not timestamp-like webcams)? IIRC ivtv is the most
complete v4l2 driver in the kernel tree

> Your problems stem from the fact that the source is live and there's a latency,
> but no element in the pipeline answers the latency query properly, so the sink
> doesn't know it needs to adjust for live input. You can work around that by
> using xvimagesink sync=false, e.g:
> 
>  gst-launch-0.10 playbin2 uri=file:///dev/video0 video-sink='xvimagesink
> sync=false'

That removes video stuttering completely, but the sound dies at about the same
time video used to freeze, and it does not recover at all, so functionnally
this is no better

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.