Why can't OMXplayer display streamed movies well?

Question

I am running a comparison on a 720p HD video of running it directly:

omxplayer Shame.mkv

and off of a vlc server configured like so:

new channel1 broadcast enabled 
   setup channel1 input /path/to/Shame.mkv loop
   setup channel1 output #rtp{access=udp,mux=ts,dst=raspi1,port=1234,sdp=sap,sap,group="Video",name="Shame"}

control channel1 play

executed on the server like so:

vlc -I telnet --vlm-conf ~/vlc.streaming.conf

and called like so on the client:

omxplayer udp://192.168.1.102:1235

Now bear in mind that the file Shame.mkv is stored on the server and accessed by the client via NFS, so it is identical in both cases, and is using the same physical cat5e cable in both cases. When I run it locally on the client, it works flawlessly, not a single problem. When I try to run it via the udp stream, it is terrible. There are big digital boxes everywhere, the bottom half of the screen is sometimes green boxes, other times completely white, sometimes it looks like that RGB effect on old TVS, sometimes it hangs for 5-10 seconds... It's a nightmare

Question:

Why is this happening?

Motivation:

In case anyone is wondering why I am even bothering with this stream it is because I want to synchronize multiple raspi/TVs (see here) which omxplayer can't do. I tried installing vlc as mentioned here and described here but building it was a nightmare, and I still have not got it to work in any meaningful way, and even if I do get it to work, even the guy who hacked it admits that the raspi has to be overclocked for it to work. Finally, xiaobai suggested (here) I modify omxplayer's source code to allow for synchronization, but it just should not have to be this difficult. It seems like everytime I get close to a solution, raspi manages to shut me down.

Answer 1

I am assuming the machine you are using to send is an x86 machine with gigabit ethernet; if it is, the underlying problem you are seeing is likely to be what I am asking about in my more recent question -- UDP packet loss. This is a common problem when using UDP between hosts with different bitrates, and workarounds include:

• Enabling flow control on sender, receiver and corresponding switch ports. However, it's not clear to me whether the RPi supports flow control.
• Reducing or controlling the bitrate in the application, which for avconv/ffmpeg could include using the -crf and -b:v and ?buffer_size options.
• Increasing buffers and queues on the sender and receiver side, both in the kernel and in your application.

It's unfortunate that there doesn't seem to be a single thing you can tweak to make the problem go away.

Having said that, you can work around your problem if you use TCP instead. There's a patch which configures omxplayer to stream over TCP, but even simpler is having omxplayer read from a named pipe created with mkfifo like this:

# on the pi side
mkfifo tcp.stream
nc -l -p 1234 > tcp.stream | omxplayer --live tcp.stream

and streaming with TCP from the server (here's a document that explains how to do so with vlc, and avconf/ffmpeg can be similarly configured).

I'm not sure if using TCP avoids packet loss altogether or just papers over it; either way I was surprised just how good the stream is over TCP when I tried it the first time. I realize using TCP has its downsides, including greater overhead and no multicast support, but if you weren't intending on using multicast in the first place that might not be a showstopper.

(Finally, I don't have enough reputation to note that there is a slight mistake in your examples: you specify port 1235 in the omxplayer commandline, but port 1234 in your vlc configuration. And there are now a few forks of omxplayer which have support for synchronizing between clients; look for omxplayer-sync or pwomxplayer.)