GNOME Bugzilla – Bug 758219
uvch264src freezes when using its "vidsrc"
Last modified: 2018-11-03 13:42:47 UTC
Created attachment 315732 [details] Output of using both sources. When starting the following chain: gst-launch-1.0 -v -e uvch264src device=/dev/video1 name=src auto-start=true \ src.vfsrc ! queue ! video/x-raw,format=\(string\)YUY2,width=320,height=240,framerate=10/1 ! xvimagesink sync=false \ src.vidsrc ! queue ! video/x-h264,width=1280,height=720,framerate=30/1 ! h264parse ! avdec_h264 ! xvimagesink sync=false the sresult is only the viewfinder (vfsrc) emitting a single frame. If I remove the vidsrc part, the result is (as expected) a live preview of the camera: gst-launch-1.0 -v -e uvch264src device=/dev/video1 name=src auto-start=true \ src.vfsrc ! queue ! video/x-raw,format=\(string\)YUY2,width=320,height=240,framerate=10/1 ! xvimagesink sync=false 1st machine tested: Linux 3.16.7-ckt11 GStreamer 1.7.0 (GIT) Logitec C920-C 2nd machine: Linux 3.16.0-4-amd64 GStreamer 1.4.4 Logitec C930 I attached the file with the output of: gst-launch-1.0 -vvv --gst-debug=uvch264src:5 -e uvch264src device=/dev/video1 name=src auto-start=true src.vfsrc ! queue ! video/x-raw,format=\(string\)YUY2,width=320,height=240,framerate=10/1 ! xvimagesink sync=false src.vidsrc ! queue ! video/x-h264,width=1280,height=720,framerate=30/1 ! h264parse ! avdec_h264 ! xvimagesink sync=false Already described here: http://gstreamer-devel.966125.n4.nabble.com/uvch264src-Only-broken-examples-td4665446.html I just noticed this issue is already flagged as invalid in https://bugzilla.gnome.org/show_bug.cgi?id=756776 -- but no, 1.4.5 did not fix it as I'm experiencing it with 1.7.
I just tested here, kernel 4.3 with a C920, it works for me. This looks like a kernel bug to me. Could you retest with a different kernel ? My current setup is (Fedora 22 based): Kernel 4.3.0-0.rc3 (I was testing something else) libusb-0.1.5-5 libgudev1-219-25
I dist-upgraded the 2nd machine to Debian testing with kernel 4.2. Linux 4.2.0-1-amd64 libusb-1.0-0 libusb-0.1-4 (I don't know when is this one used) libgudev-1.0-0 This works fine: gst-launch-1.0 -vvv -e uvch264src device=/dev/video0 name=src src.vfsrc ! video/x-raw,format=I420,width=1920,height=1080,framerate=24/1 ! queue ! vaapiencode_h264 rate-control=2 bitrate=3500 keyframe-period=50 tune=1 ! video/x-h264,profile=constrained-baseline ! mp4mux ! filesink location="a.mp4" But adding vidsrc with a fakesink will produce a zero-length file. (This is a headless machine, could not use the xvimagesink to test it). gst-launch-1.0 -vvv -e uvch264src device=/dev/video0 name=src src.vfsrc ! video/x-raw,format=I420,width=1920,height=1080,framerate=24/1 ! queue ! vaapiencode_h264 rate-control=2 bitrate=3500 keyframe-period=50 tune=1 ! video/x-h264,profile=constrained-baseline ! mp4mux ! filesink location="a.mp4" src.vidsrc ! queue ! video/x-h264,format=I420,width=1920,height=1080,framerate=24/1 ! h264parse ! fakesink The first machine also has: libusb-1.0-0 libusb-0.1-4 libgudev-1.0-0
(that's a really weird pipeline, why do you encode the raw stream, and trash the encoded stream ?) Are you sure you aren't saturating on a USB2 connection ?
The first pipline is the only one that currently works: reading raw from the vfsrc. My goal is of course to use the h264 from the vidsrc, but even hooking a fakesink to it will stop the whole (otherwise functional) chain from working. I don't think USB bandwidth is an issue I'm getting the same result by running the following pipeline (window with a single frozen frame): gst-launch-1.0 -v -e uvch264src device=/dev/video1 initial-bitrate=2000000 average-bitrate=2000000 iframe-period=3000 name=src auto-start=true src.vfsrc ! queue ! video/x-raw,format=\(string\)YUY2,width=320,height=240,framerate=10/1 ! xvimagesink sync=false src.vidsrc ! queue ! video/x-h264,width=320,height=240,framerate=30/1 ! h264parse ! avdec_h264 ! xvimagesink sync=false (This is the example from http://oz9aec.net/index.php/gstreamer/487-using-the-logitech-c920-webcam-with-gstreamer-12 but with lowered resolution and bitrate parameters for uvch264src).
Created attachment 332105 [details] GST_DEBUG=*:6 output of same behavior. I have the same problem. OS is Ubuntu 16.04, kernel is "Linux python 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux", gstreamer is 1.9.1 with all 1.9.1 plugins built natively. Camera is a Logitech C930e. v4l2-ctl --all says: Driver Info (not using libv4l2): Driver name : uvcvideo Card type : Logitech Webcam C930e Bus info : usb-0000:00:14.0-3 Driver version: 4.4.13 Capabilities : 0x84200001 Video Capture Streaming Extended Pix Format Device Capabilities Device Caps : 0x04200001 Video Capture Streaming Extended Pix Format Priority: 2 Video input : 0 (Camera 1: ok) Format Video Capture: Width/Height : 320/240 Pixel Format : 'YUYV' Field : None Bytes per Line : 640 Size Image : 153600 Colorspace : sRGB Transfer Function : Default YCbCr Encoding : Default Quantization : Default Flags : Crop Capability Video Capture: Bounds : Left 0, Top 0, Width 320, Height 240 Default : Left 0, Top 0, Width 320, Height 240 Pixel Aspect: 1/1 Selection: crop_default, Left 0, Top 0, Width 320, Height 240 Selection: crop_bounds, Left 0, Top 0, Width 320, Height 240 Streaming Parameters Video Capture: Capabilities : timeperframe Frames per second: 10.000 (10/1) Read buffers : 0 brightness (int) : min=0 max=255 step=1 default=128 value=128 contrast (int) : min=0 max=255 step=1 default=128 value=128 saturation (int) : min=0 max=255 step=1 default=128 value=128 white_balance_temperature_auto (bool) : default=1 value=1 gain (int) : min=0 max=255 step=1 default=0 value=185 power_line_frequency (menu) : min=0 max=2 default=2 value=2 white_balance_temperature (int) : min=2000 max=7500 step=1 default=4000 value=3168 flags=inactive sharpness (int) : min=0 max=255 step=1 default=128 value=128 backlight_compensation (int) : min=0 max=1 step=1 default=0 value=0 exposure_auto (menu) : min=0 max=3 default=3 value=1 exposure_absolute (int) : min=3 max=2047 step=1 default=250 value=666 exposure_auto_priority (bool) : default=0 value=1 pan_absolute (int) : min=-36000 max=36000 step=3600 default=0 value=-36000 tilt_absolute (int) : min=-36000 max=36000 step=3600 default=0 value=0 focus_absolute (int) : min=0 max=255 step=5 default=0 value=35 flags=inactive focus_auto (bool) : default=1 value=1 zoom_absolute (int) : min=100 max=400 step=1 default=100 value=100 Command line is: DEBUG="*:6" GST_DEBUG=$DEBUG GST_DEBUG_NO_COLOR=1 /home/hpeyerl/gst/runtime/bin/gst-launch-1.0 -v -e uvch264src initial-bitrate=5000000 average-bitrate=5000000 iframe-period=3000 \ device=/dev/video0 name=src auto-start=true \ src.vfsrc ! queue ! video/x-raw,format=\(string\)YUY2,width=320,height=240,framerate=10/1 ! xvimagesink sync=false \ src.vidsrc ! queue ! video/x-h264,width=1920,height=1080,framerate=30/1 ! h264parse ! avdec_h264 ! xvimagesink sync=false guvcview can successfully display the h264 stream at 1920x1080x30 with almost no perceptible latency and low CPU.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/324.