GNOME Bugzilla – Bug 626300
v4l2src: support capturing MPEG
Last modified: 2012-10-26 22:49:10 UTC
gst-launch-0.10 playbin uri="file:///dev/video0" Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstPulseSinkClock WARNING: from element /GstPlayBin:playbin0/GstBin:vbin/GstAutoVideoSink:videosink/GstXvImageSink:videosink-actual-sink-xvimage: A lot of buffers are being dropped. Additional debug info: 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. WARNING: from element /GstPlayBin:playbin0/GstBin:vbin/GstAutoVideoSink:videosink/GstXvImageSink:videosink-actual-sink-xvimage: A lot of buffers are being dropped. Additional debug info: 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. WARNING: from element /GstPlayBin:playbin0/GstBin:vbin/GstAutoVideoSink:videosink/GstXvImageSink:videosink-actual-sink-xvimage: A lot of buffers are being dropped. Additional debug info: 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. WARNING: from element /GstPlayBin:playbin0/GstBin:vbin/GstAutoVideoSink:videosink/GstXvImageSink:videosink-actual-sink-xvimage: A lot of buffers are being dropped. Additional debug info: 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. ^CCaught interrupt -- handling interrupt. Interrupt: Stopping pipeline ... Execution ended after 30944172470 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ... gstreamer-0.10.30-1.fc14.x86_64 gstreamer-ffmpeg-0.10.11-1.fc14.x86_64 gstreamer-java-1.4-2.fc14.noarch gstreamer-plugins-bad-0.10.19-1.fc14.x86_64 gstreamer-plugins-bad-free-0.10.19-6.fc14.x86_64 gstreamer-plugins-base-0.10.30-2.fc14.x86_64 gstreamer-plugins-good-0.10.24-1.fc14.x86_64 gstreamer-plugins-ugly-0.10.15-2.fc14.x86_64 gstreamer-python-0.10.16-2.fc14.x86_64 gstreamer-rtsp-0.10.5-2.fc14.x86_64 gstreamer-tools-0.10.30-1.fc14.x86_64 PackageKit-gstreamer-plugin-0.6.6-3.fc14.x86_64 phonon-backend-gstreamer-4.4.2-1.fc14.x86_64 alsa-plugins-pulseaudio-1.0.22-1.fc13.x86_64 pulseaudio-0.9.21-6.fc13.x86_64 pulseaudio-gdm-hooks-0.9.21-6.fc13.x86_64 pulseaudio-libs-0.9.21-6.fc13.x86_64 pulseaudio-libs-glib2-0.9.21-6.fc13.x86_64 pulseaudio-libs-zeroconf-0.9.21-6.fc13.x86_64 pulseaudio-module-bluetooth-0.9.21-6.fc13.x86_64 pulseaudio-module-gconf-0.9.21-6.fc13.x86_64 pulseaudio-module-lirc-0.9.21-6.fc13.x86_64 pulseaudio-module-x11-0.9.21-6.fc13.x86_64 pulseaudio-utils-0.9.21-6.fc13.x86_64 kernel-2.6.35-3.fc14.x86_64
*** Bug 583685 has been marked as a duplicate of this bug. ***
Created attachment 167306 [details] LANG=C G_DEBUG=fatal_warnings gdb --args gst-launch -v playbin uri="file:///dev/video0" gdb trace
Created attachment 167307 [details] dmesg
Created attachment 167308 [details] lspci
Created attachment 167309 [details] Xorg.0.log
gst-play does not handle mpeg2 v4l2src sources so there's no way to invoke it this way (unless someone can propose a pipeline)
Created attachment 167310 [details] cat /proc/asound/*/pcm*p/sub*/* while playing
Created attachment 167315 [details] /proc/cpuinfo
Does it work if you save some content from /dev/video0 to a file and try to play that?
(In reply to comment #9) > Does it work if you save some content from /dev/video0 to a file and try to > play that? This part works perfectly (or the symptoms occur after a lot more time than when playing video live)
Drat, it's stuck in needinfo now :(
Well, this is just not really how you're supposed to use /dev/videoN. 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. 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'
(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
> > 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.) > > 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 ? > > 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.)
(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
Created attachment 167328 [details] LANG=C GST_DEBUG=v4l2*:5 gst-launch-0.10 v4l2src num-buffers=1 ! fakesink
Seems like the pipeline causes you to capture BGR3 because libv4l claims it can emulate it, but it turns out it lies and just gives you back mpeg.. Making gstreamer somewhat unhappy. If you apply the patch from dcea1b2dfcdad92c381281aafd09786a7abe8a83 that should work around it. (The real bug is in libv4l though).
Reopening as I think the requested information has been provided.
Not sure what to do with this. v4l2src advertises mpegts now, so I guess it supports it at least somewhat. The patch mentioned in comment #17 has been committed, which should workaround the last issue which is not a GNOME issue anyway as I understand it. Let's close this as OBSOLETE. I'm sure someone will file a new bug if there's still support for something missing. Please re-open or file a new bug if this still doesn't work with GStreamer 1.x.