<div dir="ltr"><div><div><div><div><div><div><div><div>Hi Paulo<br><br></div>A couple of things worth mentioning.<br><br></div>1) RaspPi has its ethernet port connected to its USB internal bus and due to a hardware bug/feature, it is notoriously known to  loose packets on the USB bus. Loss increases with load. Streaming a 1080p @30fps stream from the C920 is by default more than a a couple of Mbps and packets may/will be lost.<br><br></div><div>2) UDP packets are not resent, so if lost on the internal USB, they stay lost.<br><br></div></div>3) I think, meaning I am not sure, the udpsink module can not (easily) know max MTU on a connection less network path. Depending on GStreamer version, perhaps all (or none), udpsink does NOT send info on max packet size upstream. The module rtph264pay can therefor not know the max MTU, but perhaps bye default it uses something less than 1500 minus transport headers .. perhaps. You could add the module chopmydate with maxsize set, but it may not be needed and h264pay must know how to break up longer packets.<br><br></div>4) I my self could never get RaspPi to play a TS encapsulated UDP stream reliable probably due to things listed above. It produce something similar to what you have in your video, but so far I did not persue it further, which I of course should.<br><br>5) You see the problem when you have motion in the picture and the C920 generates a stream of at least 4-6Mbps or more with motion and much less with a still picture, so this is consistent with loosing packets.<br><br></div>That said, you could try to test<br><br></div>1) Test a lower much lower bandwidth and geometry. Try 1024x576@25fps and see if the problem gets smaller. If it does, you quite likely loose packets although I admit it could be a problem with the load of the decoder.<br><br></div>2) Test using a tcpserver/tcpclient. That works for me.<br><br><div style="margin-left:40px">... h264parse ! matroskamux streamable=true ! queue ! tcpserversink port=6000 host=0.0.0.0 sync-method=2 recover-policy=keyframe<br><br></div>and on the RaspPi<br><div><div style="margin-left:40px"><br></div><div style="margin-left:40px">gst-launch-1.0 -v tcpclientsrc port=6000 host=A.B.C.D ! queue ! matroskademux ! h264parse ! omxh264dec ! queue ! autovideosink sync=false<br><br></div>or something like that. This works for me because lost packets are resend.<br><div><br></div><div>Best regards<br></div><div>Peter Maersk-Moller<br></div><div><div><div><div><div><br><br><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 7, 2015 at 5:35 PM, Paulo Neves <span dir="ltr"><<a href="mailto:ptsneves@gmail.com" target="_blank">ptsneves@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thornton, Keith: I am not sure I understand what the difference is.<br>
The sample h264 that was successfully tested can be found in apple's<br>
site:<br>
<br>
<a href="http://a1408.g.akamai.net/5/1408/1388/2005110403/1a1a1ad948be278cff2d96046ad90768d848b41947aa1986/sample_iPod.m4v.zip" target="_blank">http://a1408.g.akamai.net/5/1408/1388/2005110403/1a1a1ad948be278cff2d96046ad90768d848b41947aa1986/sample_iPod.m4v.zip</a><br>
<br>
In the camera description page it says the camera does AVC h264 compression:<br>
<a href="http://www.logitech.com/en-gb/product/hd-pro-webcam-c920" target="_blank">http://www.logitech.com/en-gb/product/hd-pro-webcam-c920</a><br>
<br>
If you can tell me a way to peek at this information I can do it.<br>
<br>
Regarding the pipelines tried here are some examples, I am sorry I omitted them:<br>
<br>
I am streaming the camera video from a remote computer with the<br>
following pipeline:<br>
<br>
gst-launch-1.0 -v -e v4l2src device=/dev/video0 !<br>
video/x-h264,width=1920,height=1080,framerate=30/1 ! h264parse !<br>
rtph264pay pt=127 config-interval=8 ! udpsink host=192.168.1.109<br>
port=6000<br>
<br>
For the h264 video coming from the file the only thing that changes is<br>
the source of the video on the remote computer and the addition of the<br>
demuxer:<br>
<br>
gst-launch-1.0 -v -e filesrc location=~/Downloads/sample_iPod.m4v !<br>
qtdemux ! h264parse ! rtph264pay pt=127 config-interval=8 ! udpsink<br>
host=192.168.1.109 port=6000<br>
<br>
Receiving on the Raspberry PI (omx decoder) is done, for both cases<br>
through this pipeline:<br>
<br>
gst-launch-1.0 udpsrc port=6000 !  application/x-rtp, payload=127 !<br>
rtph264depay ! h264parse ! omxh264dec ! queue ! autovideosink<br>
sync=false<br>
<br>
To test that the omxh264dec works well with the omxh264enc i tried the<br>
following pipeline:<br>
<br>
gst-launch-1.0 videotestsrc ! omxh264enc ! h264parse ! omxh264dec !<br>
autovideosink sync=false<br>
<br>
To further test if different encoders would produce different<br>
renderings in a remote computer I encoded videotestsrc and apple's<br>
file(pipeline below) with x264enc:<br>
<br>
gst-launch-1.0 -v -e filesrc location=~/Downloads/sample_iPod.m4v !<br>
qtdemux ! h264parse ! avdec_h264 ! x264enc tune=zerolatency !<br>
rtph264pay pt=127 config-interval=1 ! queue ! udpsink<br>
host=192.168.1.109 port=6000<br>
<br>
In this test no corruption seemed to appear while preparing the<br>
pipelines for this email contrary to my previous email. I have not<br>
tried another movie with more scene change so this might be a fluke.<br>
<br>
In the following link you can also find a video of the corruption<br>
which I am talking about:<br>
<a href="https://youtu.be/JxOvCCan3Ro" target="_blank">https://youtu.be/JxOvCCan3Ro</a><br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote></div><br></div></div></div></div></div></div></div></div>