gst-omx decoding H264 from Logitech C920 stream

Tue Apr 7 12:21:40 PDT 2015

To my suggestion for using tcp to test the RaspPi decoding of the H.264
stream using TCP rather than UDP to eliminate errors in the decoder lement,
suggesting port 6000 is obviously a bad choice, just in case you try.

On Tue, Apr 7, 2015 at 8:23 PM, Peter Maersk-Moller <pmaersk at gmail.com>
wrote:

> 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/e24996fa/attachment.html>