I would like to synchronize one feed (ie. this super maly fight scene from Puss and Boots...lets assume I have it on disk and in .h264) across 3 raspis (via a network) each connected to one HD monitor for a total of 3 HD monitors. I can easily do this via mplayer as described here and via VLC as described here, but neither of those run on raspi in any useful way as they do not exploit hardware acceleration.

What are my options, either with OMXplayer (Raspbian OS), Raspbmc (Raspbmc OS) or with XBMC (XBMC OS)

  • 1
    Now people have added H/W video playback to vlc successfully: raspberrypi.stackexchange.com/questions/3399/… – Penghe Geng Oct 19 '13 at 5:02
  • @xiaobai when you said that, all I heard was a divine "aaaaaaaaa" – puk Oct 19 '13 at 5:11
  • @xiaobai To anyone thinking of installing vlc, it is a major PITA. I have been at it for over 10 days and nights and the best I have gotten is to actually install the thing without it finding any codecs. – puk Nov 1 '13 at 7:31
  • Can't you just use the compiled VLC binary this guy proivded? intensecode.blogspot.com/2013/10/… – Penghe Geng Nov 1 '13 at 14:06
  • @xiaobai I tried that and it still did not work. – puk Nov 1 '13 at 19:28

omxplayer is not as nearly feature rich as mplayer or vlc. I don't believe the synchronization feature is internal to the current version of omxplayer. You may be able to achieve some level of synchronization between different stations with some manual methods as described below:

The current (github) version of omxplayer can be controlled through dbus. (The stock version from raspbian wheezy is an old version without this capability last time when I checked). So one approach might be writing a small program which 1) sits on the network receiving UDP commands from your controling device. then 2) sends appropriate dbus messages to the omxplayer process.

If you just want to do it quick and dirty, you can add your own UDP server thread in omxplayer, inject plain control messages (like KeyConfig::ACTION_PAUSE) directly to OMXControl::getEvent().

In order to sync multiple raspi's in this way, you need to modify omxplayer source code to make the player pause in the verying beginning of the playback. Then your controlling device broadcasts a Pause command which make all omxplayers start to play at the same time. All later commands will be broadcasted to all Raspberry Pi's so they will remain synchronized.

  • Thanks I will look into this, and if I get it to work, I will post it as an answere here – puk Oct 18 '13 at 17:54
  • So I have actually been busy looking for a solution to this (udp streaming, vlc for raspi, omxplayer-sync, and launching omxplayer at same time) and none have worked really. Going to try your suggestion here, but could you please address some of these issues: is there something wrong with the dbus approach or are paragraphs 2 and 3 part of same solution? Basically, are paragraphs 2,3 and 4 all different solutions? – puk Nov 5 '13 at 20:29
  • Also, do you mean this version of omxplayer: github.com/popcornmix/omxplayer – puk Nov 5 '13 at 20:51
  • @puk nothing wrong with the dbus approach. It's just you need another small program to handle the inter-Pi UDP communication. Paragraph 2 & 3 are two solutions, and paragraph 4 applies to both. – Penghe Geng Nov 5 '13 at 22:06
  • I am against using anything when omxplayer is running. omxplayer-sync for example lags even on 720p github.com/turingmachine/omxplayer-sync – puk Nov 5 '13 at 22:17

There is a project I seen posted at www.raspberrypi.org that was creating a video wall. The project page is at www.piwall.co.uk. Might be useful, I have not tried it myself.


I added synchronizing capabilities to omxplayer, you can checkout the repo here. Note this is still in development, however, to the best of my knowledge, it is the only way to get reliable synchronization across multiple raspis.


Look at https://github.com/turingmachine/omxplayer-sync , it's synchronize multiples pi with unmodified omxplayer, only a python program.


You could make it easily with Gstreamer and its fully supported. There are precompiled packages on Rasbpian that you can use.

From server, you could stream file with rtp. On clients you can just run simple playbin and that is it. All 3 in the same time.

  • Thank you for the information. Could you please provide some more, for example, what exactly is Gstreamer, are these 'precompiled packages' of gstreamer or synched omxplayer with gstreamer, what is rtp, what is playbin, and 'all 3' what? =) – puk Oct 18 '13 at 18:57
  • Ah, welcome to beautiful world. As idea is somehow special, you should use special software - like Gstreamer. For start, I would suggest to install it on your PC and try to run gst-launch-1.0 playbin uri=file:///home/user/your/movie.mp4. Then, use google to find out that you can build various pipelines in command line. Pipelines can stream, play, convert or [you choose]. If you are using Raspbian on rpi, you can follow this link (raspberrypi.org/phpBB3/viewtopic.php?p=293634#p293634) for packages that support gstreamer-1.0 and playback without starting X. – 10robinho Oct 18 '13 at 19:17
  • And rtp is just a protocol that you have to use for network streaming of h264 file. You build rtp in pipeline (google it). By 'all 3' I meant all 3 of your rpis in network. – 10robinho Oct 18 '13 at 19:21
  • I didn't try gstreamer but I tried streaming from vlc (on a desktop) and it was disastrous, like watching the scrambled Adult channels in the early 90's. I came across a thread where someone had a similar problem, and it apparently had something to do with the memory constraints of the raspi. Can you possibly comment before I go invest yet another 100 hours of my life into a linux venture =) Thanks – puk Nov 5 '13 at 20:32

I found one potential solution, though it is not perfect. I have a test script up on git hub which tries to launch, in my case 2, threads, which each eventually call omxplayer on two different raspis. The program picks a time in the future to sychronize the launch of omxplayer, ie. (12:00:00 exactly, or 5 seconds from now), then a shell script waits as best it can and then, hopefully, the two raspis launch at the same time. Currently, 90% of the trials launch with less than 100ms difference between the two, however, the audio delay is still noticeable. I take this to mean that either the human ear is extremely sensitive, or launching omxplayer and playing the movie are two different things.

Also, I am assuming that once started, and with smooth playback, the two raspis will play the video at the same exact speed.

If you plan on playing audio from only a single source (ie. a home theater system), this solution should suffice.


As is, the code has a bug whereby every 1 in a 100 times it just hangs.

  • 1
    This is not a good solution. Even when it works, after 30 minutes the drift will be noticeable – puk Dec 9 '13 at 20:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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