GNOME Bugzilla – Bug 729058
Porting gst-launch raw video UDP stream pipeline from 0.10 to 1.0 is inconsistent
Last modified: 2014-04-28 12:54:24 UTC
I have a pair of pipelines from 0.10 that have issues under 1.0. To replicate, use the following : System information : I've tested using the following gstreamer versions (distributed via Ubuntu 14.04) : gst-launch-0.10 version 0.10.36 gst-launch-1.0 version 1.2.3 The tests were performed on on a HP z600 Dual Quad-Xeon with 24GB ram (speedy!) using the on-board BCM5764M gigabit ethernet (eth0) on a netgear ethernet switch with the following multicast route configured : route add -net 224.0.0.0 netmask 240.0.0.0 eth0 Common config for send and receive : export MULTICAST_ADDR=239.192.1.254 export PORT=5004 export WIDTH=1024 export HEIGHT=768 Create send and receive using GStreamer 0.10 : gst-launch-0.10 videotestsrc ! \ "video/x-raw-yuv,framerate=30/1,width=$WIDTH,height=$HEIGHT" ! \ queue ! rtpvrawpay ! udpsink host=$MULTICAST_ADDR port=$PORT auto-multicast=true gst-launch-0.10 udpsrc uri=udp://${MULTICAST_ADDR}:${PORT} ! \ queue ! \ "application/x-rtp,media=(string)video,clock-rate=(int)90000," \ "encoding-name=(string)RAW,sampling=(string)YCbCr-4:2:2," \ "depth=(string)8,width=(string)${WIDTH},height=(string)${HEIGHT}," \ "colorimetry=(string)SMPTE240M,payload=(int)96" ! \ queue ! \ rtpvrawdepay ! \ "video/x-raw-yuv,width=(int)${WIDTH},height=(int)${HEIGHT}" ! \ queue ! \ fpsdisplaysink Create send and receive using GStreamer 1.0 : gst-launch-1.0 videotestsrc ! \ "video/x-raw,format=UYVY,framerate=30/1,width=$WIDTH,height=$HEIGHT" ! \ queue ! rtpvrawpay ! udpsink host=$MULTICAST_ADDR port=$PORT auto-multicast=true gst-launch-1.0 udpsrc uri=udp://${MULTICAST_ADDR}:${PORT} ! \ queue ! \ "application/x-rtp,media=(string)video,clock-rate=(int)90000," \ "encoding-name=(string)RAW,sampling=(string)YCbCr-4:2:2," \ "depth=(string)8,width=(string)${WIDTH},height=(string)${HEIGHT}," \ "colorimetry=(string)SMPTE240M,payload=(int)96" ! \ queue ! \ rtpvrawdepay ! \ "video/x-raw,format=UYVY,width=(int)${WIDTH},height=(int)${HEIGHT}" ! \ queue ! \ fpsdisplaysink Note that the only changes are changing from : video/x-raw-yuv to : video/x-raw,format=UYVY as suggested. If you stream 0.10 -> 0.10 it streams OK, and if you stream 1.0 - 1.0 it also streams OK. If you mix and match 0.10 and 1.0 send/receive the video format mismatches and you get a corrupted video stream in pinks and greens. I have two standalone pieces of hardware that stream raw yuv in this manner (I was using gstreamer as a local test harness) one made by myself, one by another vendor. Both display correctly when using the 0.10 pipeline but not with 1.0 so I'm assuming that this version must have introduced a but OR that there's another change required.
In 0.10, video/x-raw-yuv can mean any YUV format and it may not be choosing UYVY. The 0.10 equivalent of 'video/x-raw,format=UYVY' was 'video/x-raw-yuv,format=(fourcc)UYVY'
Can you make a dump of such a stream available (and of course mention the parameters of it, like the width and height)?
(In reply to comment #1) > In 0.10, video/x-raw-yuv can mean any YUV format and it may not be choosing > UYVY. The 0.10 equivalent of 'video/x-raw,format=UYVY' was > 'video/x-raw-yuv,format=(fourcc)UYVY' I'm 99% sure it was picking UYVY correctly as the receiver pipeline displays correctly (which was set up for UYVY). I've added the ",format=(fourcc)UYVY" into the 0.10 example as above and verified that the behaviour is the same still.
(In reply to comment #2) > Can you make a dump of such a stream available (and of course mention the > parameters of it, like the width and height)? The parameters used are quoted in the report above - if you use those it will reproduce my scenario. I've tested it on a couple of machines and a VM and it's consistent. Does it not reproduce in your environment? What kind of capture would you like? 5 frames of each version in .pcap format?
Created attachment 275325 [details] GStreamer-0.10 capture example Test #1 : GStreamer 0.10 # Capture line sudo tcpdump -nn dst host 239.192.1.254 and dst port 5004 -i eth0 -s0 -w capture-$(date +"%Y%m%d-%H%M%S").pcap # GStreamer command export MULTICAST_ADDR=239.192.1.254 export PORT=5004 export WIDTH=1024 export HEIGHT=768 gst-launch-0.10 videotestsrc num-buffers=1 ! \ "video/x-raw-yuv,framerate=30/1,width=$WIDTH,height=$HEIGHT" ! \ queue ! rtpvrawpay ! udpsink host=$MULTICAST_ADDR port=$PORT auto-multicast=true # Produces : capture-20140428-130844.pcap.gz
Created attachment 275326 [details] GStreamer-1.0 capture example Test #2 : GStreamer 1.0 # Capture line sudo tcpdump -nn dst host 239.192.1.254 and dst port 5004 -i eth0 -s0 -w capture-$(date +"%Y%m%d-%H%M%S").pcap # GStreamer command export MULTICAST_ADDR=239.192.1.254 export PORT=5004 export WIDTH=1024 export HEIGHT=768 gst-launch-1.0 videotestsrc num-buffers=1 ! \ "video/x-raw,format=UYVY,framerate=30/1,width=$WIDTH,height=$HEIGHT" ! \ queue ! rtpvrawpay ! udpsink host=$MULTICAST_ADDR port=$PORT auto-multicast=true # Produces : capture-20140428-130855.pcap.gz
Created attachment 275328 [details] GStreamer 0.10 Test + format=(fourcc)UYVY Test #3 : GStreamer 0.10 + format=(fourcc)UYVY # Capture line sudo tcpdump -nn dst host 239.192.1.254 and dst port 5004 -i eth0 -s0 -w capture-$(date +"%Y%m%d-%H%M%S").pcap # GStreamer command export MULTICAST_ADDR=239.192.1.254 export PORT=5004 export WIDTH=1024 export HEIGHT=768 gst-launch-0.10 videotestsrc num-buffers=1 ! \ "video/x-raw-yuv,format=(fourcc)UYVY,framerate=30/1,width=$WIDTH,height=$HEIGHT" ! \ queue ! rtpvrawpay ! udpsink host=$MULTICAST_ADDR port=$PORT auto-multicast=true # Produces : capture-20140428-131510.pcap.gz
If you create some plain text dumps for convenience : tcpdump -x -r capture-20140428-130844.pcap > capture-20140428-130844.pcap.dump tcpdump -x -r capture-20140428-130855.pcap > capture-20140428-130855.pcap.dump tcpdump -x -r capture-20140428-131510.pcap > capture-20140428-131510.pcap.dump 1) You'll see that the format= makes no difference : diff capture-20140428-130844.pcap.dump capture-20140428-131510.pcap.dump 2) If you compare the 0.10 vs 1.0 streams it looks like the format is definitely different... : diff capture-20140428-130844.pcap.dump capture-20140428-130855.pcap.dump
It's a bug in the 1.0 pay/depayloaders. I'll push a fix soon
commit 9994ff2c6c4c1e25d96627cd8edf2cdcad736e47 Author: Wim Taymans <wtaymans@redhat.com> Date: Mon Apr 28 14:41:10 2014 +0200 rtpvraw: use plane pointers when needed Pack/unpack planar formats to/from the first plane. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=729058