turingmachine
commented
10 years ago How do you determine "it comes across as a binary file"? it is executable yes, and the shebang will determine what interpreter to use. Many programs in e.g. /usr/bin are scripts, executable and don't have a file extension.
The reason the binaries are called like the original ones is, that they are just a replacement for the them. This way the omxplayer-sync works with both players. With the next release it will be possible to use the pre-packaged omxplayer from http://omxplayer.sconde.net. My own fork does now only adjust values for seek times in order to achieve faster initial sync times. The USAGE section indeed has a typo in in it, thank you for pointing that out.
The settings in the omxplayer-sync have sensible default values. You normally don't need to change them.
I, personally, find the README file a little bit misleading. Here are a few reasons why, in case any one wants to address these issues:
1) omxplayer-sync comes across as a binary file like the original omxplayer, when it is in fact a python script. This leads to problems with 2). It might help to rename it as will be described in 3) 2) the version of omxplayer that you need to build/download for this to work is also called omxplayer. My initial understanding was that one first builds that version of omxplayer, then using that they build a second version which is what is stored here as this repo. 3) It might help to rename you version of omxplayer as omxplayer-sync-build (or something like that) and then call this "script" omxplayer-sync-script 4) Under USAGE it has
$ ./omxplayer-sync -h ...
But then under examples it has
master
omxplayer -v -m -x 255.255.255.255 movie.mp4 slave
omxplayer -v -l movie.mp4
I am assuming those, too, are supposed to be omxplayer-sync and NOT omxplayer, correct?
5) The settings at the very bottom do not match with the settings in the actual script. Which are the correct ones to use?