Cheese works fine - GStreamer does not

I am having problems having any camera work properly with gstreamer on the Xavier. Have tried various Microsoft webcams and also Magewell USB HDMI capture dongles that works fine with gstreamer on TX2 without any drivers.

They all work fine in Cheese on Xavier - but not in GStreamer.

Running 4.9.108-tegra

nvidia@jetson-0423818077279:~$ v4l2-ctl -d /dev/video0 --list-formats-ext
	Index       : 0
	Type        : Video Capture
	Pixel Format: 'YUYV'
	Name        : YUYV 4:2:2
		Size: Discrete 640x360
			Interval: Discrete 0.017s (60.000 fps)
			Interval: Discrete 0.017s (59.940 fps)

Showing with format I420 works pretty much all the time for all kinds of cameras on TX2. But here I get this error:

gst-launch-1.0 v4l2src device=/dev/video0 ! 'video/x-raw, format=I420,framerate=30/1'  ! autovideosink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal data stream error.
Additional debug info:
gstbasesrc.c(3055): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
streaming stopped, reason not-negotiated (-4)
Execution ended after 0:00:00.001231982
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

YUYV also gives error.

nvidia@jetson-0423818077279:~$ gst-launch-1.0 v4l2src device=/dev/video0 ! 'video/x-raw, format=YUYV,framerate=30/1'  ! autovideosink
WARNING: erroneous pipeline: could not link v4l2src0 to autovideosink0, v4l2src0 can't handle caps video/x-raw, format=(string)YUYV, framerate=(fraction)30/1
nvidia@jetson-0423818077279:~$ lsusb
Bus 002 Device 004: ID 0bda:8153 Realtek Semiconductor Corp. 
Bus 002 Device 002: ID 05e3:0612 Genesys Logic, Inc. 
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 03f0:604a Hewlett-Packard 
Bus 001 Device 003: ID 03f0:034a Hewlett-Packard Elite Keyboard
Bus 001 Device 008: ID 045e:0812 Microsoft Corp. 
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Anyone got any tips?

You may try using format ‘YUY2’ in gstreamer for YUYV:

gst-launch-1.0 v4l2src device=/dev/video0 ! 'video/x-raw,format=YUY2,width=640,height=360,framerate=60/1' ! xvimagesink

Thanks, this worked!

gst-launch-1.0 -v v4l2src device=/dev/video0 ! 'video/x-raw,format=YUY2'  ! nvvidconv ! xvvideosink

UDP sink also works fine.

But autovideosink and nvoverlaysink does not work…


v4l2-ctl -d /dev/video0 --list-formats-ext

show other formats for your sensor ?

You may also specify size and framerate:

# Just to be sure the camera is configured working
gst-launch-1.0 v4l2src device=/dev/video0 ! 'video/x-raw,format=YUY2,width=640,height=360,framerate=60/1' ! nvvidconv ! autovideosink

# Now try I420 instead
gst-launch-1.0 v4l2src device=/dev/video0 ! 'video/x-raw,format=I420,width=640,height=360,framerate=60/1' ! nvvidconv ! autovideosink

If this doesn’t work, you might also retry with NV12 instead of I420.
[EDIT: This was advised from a TX2 R28.2.0 where it was working. Now trying this on Xavier with a ZED camera, it doesn’t work with I420 nor NV12 format, and framerate above 15fps shows big green dots lines flickering. My ZED is connected through an unpowered USB3.0 hub, and furthermore it doesn’t have been updated with last firmware.]

If this doesn’t improve, the following is pure speculation: maybe older version drivers were able to provide more pixel formats to v4l api. Otherwise, the difference may be in gstreamer version (such as v4l2src plugin). Someone with better knowledge may shed some light on these fuzzy speculations.

You may just use your sensor native format and choose the best way to convert it into your processing requirements.

@Honey_Patouceul YUY2 worked fine - but I had to use xvimagesink. Udpsink is also fine.

Autovideosink and nvoverlaysink does not work at all.

Hopefully this will get corrected in future versions.

If you were remotely logged into Xavier, it would explain this. Although X is able to forward (for example using ssh -Y) to host for xvimagesink, I think that autovideosink just selects and uses nvoverlaysink that requires a local display.

If you were locally logged into Xavier with monitor atteched, then it looks weird. Check if environment variable DISPLAY is set to something else than ‘:0’.