Receive h264 multicast on IMX53

[woutervh]

Hello all.

My setup contains a imx53 using the onboard FEC. I'm using it to receive a 1080p rtp stream via multicast.

As the bus is shared between the VPU and ethernet interface, I'm getting problems while viewing this stream on the fly.

I did already tests writing the h264 to a filesink and playing it afterwards. This worsk flawlessly. Also http or NFS work perfectly.

What I do notice is that the jitterbuffer reports a huge amount of packet loss while playing the RTP stream. I suspect the streaming nature of the H264 stream to be the cause of this problem. Where HTTP/File access is really more like "give me data, decode data, give me data, decode data" is RTP more like "here is your data continuously and try to catch up..."

I already did tests with a USB to ethernet device, and here I don't get packet loss any longer.

Is there a way to do some "time multiplexing" or do other tweaks on this network/VPU bus?

Thanks

[woutervh]

I still had no succes.

Now I went for a complete new approach and took the latest yocto and build me a new filesystem.

I used following pipelines which I found here on the imxcommunity also, whicht were told to work. However, with me, I have a lot of dropped frames, and warnings about computer to slow.

I only have a screen refresh every second or so. What can be wrong?

It's also the case that I'm working on a custom 800Mhz board (industrial grade).

Any help appreciated. Especially if you have any experience with playing an RTP stream on an imx53 board.

# SOURCE FROM PC

gst-launch-0.10 gstrtpbin name=rtpbin \

            videotestsrc ! ffmpegcolorspace ! "video/x-raw-yuv,format=(fourcc)I420,width=352,height=288,framerate=(fraction)90000/3000" ! x264enc byte-stream=true ! queue ! rtph264pay ! rtpbin.send_rtp_sink_0 \

                  rtpbin.send_rtp_src_0 ! udpsink port=5000 host=10.112.98.90                           \

                  rtpbin.send_rtcp_src_0 ! udpsink port=5001 sync=false async=false host=10.112.98.90   \

                  udpsrc port=5005 ! rtpbin.recv_rtcp_sink_0

#SINK FROM IMX53

gst-launch -v gstrtpbin name=rtpbin                                          \

    udpsrc caps="application/x-rtp,media=(string)video,clock-rate=(int)90000,encoding-name=H264" buffer-size=500000 \

            port=5000 ! rtpbin.recv_rtp_sink_0                                \

        rtpbin. ! queue max-size-buffers=1000000 ! rtph264depay ! queue max-size-buffers=1000000 ! mfw_vpudecoder ! "mfw_v4lsink"                    \

     udpsrc port=5001 ! rtpbin.recv_rtcp_sink_0                               \

     rtpbin.send_rtcp_src_0 ! udpsink port=5005 sync=false async=false

[timothybean]

Can you post your pipeline? I am assuming you are using Gstreamer... The RTP is trickier because you have no control over buffering the video, it is just being shoved at you... There are some ways to manage this though. I had a hard time and have spent a lot of time getting just right for my application (network decoder).

Can you tell me the format/bitrate of the video?

Tim

[woutervh]

Current receiving pipeline is:

gst-launch-0.10 udpsrc auto-multicast=true multicast-iface=eth0 multicast-group=                                                                                                                                                                                                                                             239.0.0.10 port=10000 caps="application/x-rtp,media=video,clock-rate=90000,encod                                                                                                                                                                                                                                             ing-name=H264,payload=96" ! gstrtpjitterbuffer ! rtph264depay ! video/x-h264,lev                                                                                                                                                                                                                                             el=3.1,profile=constrained-baseline,stream-format=avc,alignment=au,width=1920,he                                                                                                                                                                                                                                             ight=1080,framerate=30/1,parsed=true ! h264parse ! mfw_vpudecoder parser=false d                                                                                                                                                                                                                                             bkenable=true profiling=true framedrop=true ! mfw_v4lsink sync=false

The video is just a 1920x1080 30fps h264 baseline profile

[timothybean]

gst-launch-0.10 udpsrc auto-multicast=true multicast-iface=eth0 multicast-group=                                                                                                                                                                                                                                             239.0.0.10 port=10000 caps="application/x-rtp,media=video,clock-rate=90000,encod                                                                                                                                                                                                                                             ing-name=(String)H264,payload=96" ! gstrtpjitterbuffer drop-on-latency=true do-lost=true ! rtph264depay ! h264parse ! queue max-size-time=0 ! mfw_vpudecoder parser=false d                                                                                                                                                                                                                                             bkenable=true profiling=true framedrop=true ! queue max-size-time=0 ! mfw_v4lsink sync=true

Try the above pipeline. I think some of it around mfw_vpudecoder got clipped, so fill it back in.

drop-on-latency will drop packets that are too late and do-lost will pass that down the pipeline so the other elements know about it. See if starting there gets some better results, then you can tweak it a bit further.

Let me know how that goes.

Tim