gst-omx decoding H264 from Logitech C920 stream

Tue Apr 7 11:23:28 PDT 2015

Hi Paulo

A couple of things worth mentioning.

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.

2) UDP packets are not resent, so if lost on the internal USB, they stay
lost.

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.

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.

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.

That said, you could try to test

1) Test a lower much lower bandwidth and geometry. Try 1024x576 at 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.

2) Test using a tcpserver/tcpclient. That works for me.

... h264parse ! matroskamux streamable=true ! queue ! tcpserversink
port=6000 host=0.0.0.0 sync-method=2 recover-policy=keyframe

and on the RaspPi

gst-launch-1.0 -v tcpclientsrc port=6000 host=A.B.C.D ! queue !
matroskademux ! h264parse ! omxh264dec ! queue ! autovideosink sync=false

or something like that. This works for me because lost packets are resend.

Best regards
Peter Maersk-Moller

On Tue, Apr 7, 2015 at 5:35 PM, Paulo Neves <ptsneves at gmail.com> wrote:

> Thornton, Keith: I am not sure I understand what the difference is.
> The sample h264 that was successfully tested can be found in apple's
> site:
>
>
> http://a1408.g.akamai.net/5/1408/1388/2005110403/1a1a1ad948be278cff2d96046ad90768d848b41947aa1986/sample_iPod.m4v.zip
>
> In the camera description page it says the camera does AVC h264
> compression:
> http://www.logitech.com/en-gb/product/hd-pro-webcam-c920
>
> If you can tell me a way to peek at this information I can do it.
>
> Regarding the pipelines tried here are some examples, I am sorry I omitted
> them:
>
> I am streaming the camera video from a remote computer with the
> following pipeline:
>
> gst-launch-1.0 -v -e v4l2src device=/dev/video0 !
> video/x-h264,width=1920,height=1080,framerate=30/1 ! h264parse !
> rtph264pay pt=127 config-interval=8 ! udpsink host=192.168.1.109
> port=6000
>
> For the h264 video coming from the file the only thing that changes is
> the source of the video on the remote computer and the addition of the
> demuxer:
>
> gst-launch-1.0 -v -e filesrc location=~/Downloads/sample_iPod.m4v !
> qtdemux ! h264parse ! rtph264pay pt=127 config-interval=8 ! udpsink
> host=192.168.1.109 port=6000
>
> Receiving on the Raspberry PI (omx decoder) is done, for both cases
> through this pipeline:
>
> gst-launch-1.0 udpsrc port=6000 !  application/x-rtp, payload=127 !
> rtph264depay ! h264parse ! omxh264dec ! queue ! autovideosink
> sync=false
>
> To test that the omxh264dec works well with the omxh264enc i tried the
> following pipeline:
>
> gst-launch-1.0 videotestsrc ! omxh264enc ! h264parse ! omxh264dec !
> autovideosink sync=false
>
> To further test if different encoders would produce different
> renderings in a remote computer I encoded videotestsrc and apple's
> file(pipeline below) with x264enc:
>
> gst-launch-1.0 -v -e filesrc location=~/Downloads/sample_iPod.m4v !
> qtdemux ! h264parse ! avdec_h264 ! x264enc tune=zerolatency !
> rtph264pay pt=127 config-interval=1 ! queue ! udpsink
> host=192.168.1.109 port=6000
>
> In this test no corruption seemed to appear while preparing the
> pipelines for this email contrary to my previous email. I have not
> tried another movie with more scene change so this might be a fluke.
>
> In the following link you can also find a video of the corruption
> which I am talking about:
> https://youtu.be/JxOvCCan3Ro
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150407/d0688cd5/attachment.html>