[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 #15 from Nicolas Mailhot <Nicolas.Mailhot at LaPoste.net> 2010-08-07 17:08:31 UTC ---
(In reply to comment #14)
> > > 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) 
> 
> Because filesrc is not suited for live input.
> 
> When did what work exactly? With what versions? (Even if, it doesn't change the
> fact that this is not how you're supposed to use this kind of input with
> GStreamer.)

Seems I already had the hardware in december 2005 (how time flies), so that
would have been gstreamer 0.8.11. Tried to resist the system PA-isation as long
as I could, but once it was done, gstreamer didn't seem to recover direct
/dev/video streaming

> > > 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
> 
> Have you tried v4l2src? Does it support the format or not? Can you attach the
> log from
> 
>  $ GST_DEBUG=v4l2*:5 gst-launch-0.10 v4l2src num-buffers=1 ! fakesink
> 
> ?

ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Device
'/dev/video0' cannot capture in the specified format
Additional debug info:
gstv4l2object.c(1958): gst_v4l2_object_set_format ():
/GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
Tried to capture in BGR3, but device returned format MPEG

> > > 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
> 
> Right, you'd need to do the same for the audio sink if there's sound. (Note
> however, that this is still not really the right way to do this, just a
> work-around to demonstrate the problem.)

Can you suggest a command to type? gst-launch-0.10 does not like the attempts I
tried before

-- 
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.