search

turingmachine / omxplayer-sync

OMXPlayer-Sync facilitates synchronization of multiple OMXPlayer instances over the network in a master/slave fashion.
194 stars 70 forks source link

Asset Bitrate, encoding & auto launch (using init.d or .profile) #57

Closed alcomposer closed 6 years ago

alcomposer commented 7 years ago

I would like to know if you can share with me the best encoding format for omxplayer-sync.

I have read that it best to be a low bit rate- however I can't find confirmation of that.

Also I am interested in investigating if we can run the sync over WiFi as opposed to Ethernet, so as to reduce our hardware costs, and also to make it more fault tolerant. (unplugged cables etc)

I have tried to get the omxplayer-sync working as an init.d service, (so that it can start at system boot)- however I had lots of issues with it not having access to network etc, and have currently placed a .sh hook into the .profile file. Which works very well actually- albeit no crash respawn. If there is a simpler, or better way, please let me know.

turingmachine commented 7 years ago

There is a testfile in the root of the project directory. Using the same container and encoding is one way to go. @magdesign Can you give some insights about what the container and encoding options for best results are?

WiFI is far less stable than Ethernet in terms of latency, especially in crowded places with lot's of AP's and clients. The network delay must be and is already compensated in the code. With wired Ethernet the latency of the communications is within a very narrow range and I suspect that this range will be much broader with wireless Ethernet. The compensation in the code is a static value. So you will get different results based on different latencies. But still worth to try out!

The easiest way to start omxplayer-sync on startup is to use /etc/rc.local on raspbian. Just place the same command line in there as you would use on the the terminal. omxplayer-sync already does respawn omxplayer if it crashes.

alcomposer commented 7 years ago

Thank you! Absolutely amazing!

I would like to really push the quality as far as I can, as the video screens will be close to viewers, and also the video will be highly intricate. (Geometric lines etc). Can the format simply be the highest that omxplayer allows? Or are there somehow restrictions imposed by omxplayer-sync? (I don't see how)

Thanks once again! Great info!

magdesign commented 7 years ago

About the compression: It depends on the speed of your SD card.

You can go as big as your omxplayer can handle. I recommend max.1920x1080pixel, h264, mp4, bitrate of max. 20mbit/s, most of the time 11-15mbit/s is perfect. To get good sync rates make your video minimum 2minutes long. Report back here about your settings!

About startup: I call it from /etc/rc.local at startup, if you want it from init.d, make sure the script is named with z as the first letter, to load it at last. There is also a "wait for network on boot" setting in raspi-config.

vanDemonian commented 7 years ago

I'm having success with 1920x1080 h264 at 50 Mbps for highly intricate animations. Am also using /etc/rc.local to run a python script at start up. Combined with a shutdown script, and two momentary switches (one on headers to trigger shut down, the other on the run headers to trigger restart) the system is now automatic.

exidyboy commented 7 years ago

On 10/05/2017, at 10:49 AM, Martin Walch wrote:

I'm having success with 1920x1080 h264 at 50 Mbps for highly intricate animations.

Are you using CBR or VBR and what is configuration of your wall ? What sort of median values are getting for sync ? - I can't seem to get below 0.02 which is enough delay to be visible during mechanical transitions.

Michael