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://

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


Why is this happening?


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.

  • Try using something else than UDP - Like RTSP or TCP? Also, possibly VLC is messing up the packets with incorrect MUX or there is a buffering issue with OMXplayer.
    – Piotr Kula
    Commented Nov 4, 2013 at 20:01
  • I tried it with http, though not with that config file, and it had similar problems. I don't know what rtsp is, nor what 'incorrect MUX' means.
    – puk
    Commented Nov 4, 2013 at 20:21
  • MUX means the incorrect encoding or packet envolping. It might be taking the h264 data and telling omxplayer its something else and it just goes crazy. Best bet is to keep the settings to a minimal or try mpegts over UDP - That worked for me sending RaspiCamera Module to Windows VLC in a very nice stream- But I needed a special filter to encode the frames for UDP. (That is coming sometime in the raspivid source code... sometime they test it)
    – Piotr Kula
    Commented Nov 4, 2013 at 20:26
  • @ppumkin god da%$it I hate linux sometimes. I can't even recreate the above example to try out your suggestion.
    – puk
    Commented Nov 4, 2013 at 20:48
  • @ppumkin ok got it to work. Could you give a MWE of your above suggestion please (ie. mpegts over UDP)
    – puk
    Commented Nov 4, 2013 at 20:55

1 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.)

  • This turned up in a U&L question. Why are you using a named pipe here? Why not nc -l -p 1234 | omxplayer --live /dev/stdin? Commented Jul 5, 2015 at 12:24
  • TCP avoids packet loss altogether: if a packet is lost along the way, it's retransmitted by the system, the application doesn't need to do anything and doesn't even know about packet loss. The reason it's not always good for streaming media is that sometimes it's better to forget about a lost packet rather than delay for a few seconds until it's retransmitted. Commented Jul 5, 2015 at 12:26
  • Good point, I hadn't thought of using /dev/stdin.
    – kiko
    Commented Jul 5, 2015 at 16:12
  • More fundamentally, TCP provides a natural rate limiting effect by way of the transmission handshake; as ACKs get delayed or never make it back the network stack on the sender side adjusts to send less data.There is no equivalent mechanism in UDP.
    – kiko
    Commented Jul 5, 2015 at 16:16
  • I tried using /dev/stdin and failed. I ran "nc -l -p 1234 | omxplayer --live /dev/stdin" but omxplayer acted as though no data ever appeared, and I couldn't figure out why.
    – kiko
    Commented Jul 9, 2015 at 16:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.