[MPlayer-dev-eng] Synchronization of players in LAN

[James Courtier-Dutton]

J.A. Gutierrez wrote:
> 	Hello
> 
> 	I'm trying to synchronise several players running on several
> 	computers connected to a dedicated 10/100 Ethernet switch. Each
> 	one reads a different movie (video only) from its internal hard
> 	disk, and resolution will be 768x576.
> 
> 	I'm thinking of a simple solution:
> 
> 	- Add some code at mplayer startup so it will wait for an UDP
> 	broadcast packet (sent by a central master in the LAN). This
> 	way all the players would start at the same time.
> 
> 	- Use NTP to keep in sync all the computers' clocks, and trust
> 	mplayer's rtc synchronisation feature.
> 
> 
> 	With this simple setup, could we be sure all the players would
> 	keep the synchronisation? Or should the master computer track
> 	them all and take control on their speeds?
> 	How difficult would be to add code so all the player synchronise
> 	using the LAN? Or should I use some external clock connected to
> 	all serial ports? Or use a totally different approach?
> 
> 
> 	Thanks.
> 

I have thought about this problem before, but never actually implemented it.
Problems to overcome: -
1) All players will have to work from the same global clock so a method 
to accurately set all the local system clocks from a single central 
clock needs to happen.
2) How much can the different system clocks vary before the viewer notices.
3) The media player must have an interface to the following command:
   Start playing stream X at global time Y, with the first video frame 
of stream X being displayed at exactly time Y.

Of the above requirements, (2) is about the most important bit of 
information, because it will decide for us wether we care about CPU 
scheduling latencies of not. (i.e. are CPU scheduling latencies small 
enought to not bother us.)

(2) is also needed in order to decide what is best for (1).
Although (1) could be designed just to be as accurate as possible, and 
then hope for the best.

(3) is also important because we would need to see what the delay 
between sending an image to the video card and it actually being 
displayed. Different video cards and different versions of drivers might 
change this figure.

For (1), one approach would be to let all PCs transmit a clock packet 
over the ethernet. That clock packet would contain a unique PC id, 
together with all the clock values from all the other PCs it has heard 
from. Then, all PCs on the network will have an idea of how well all the 
other PCs are synced together. Then the PC that is most out of time 
adjusts it's own time to the average of all the other PCs. The process 
continues, to a point where all the PCs are in sync. For the purposes of 
control, one might need the control PC to never change it's time, and 
thus require all the other PCs to fall in line with it.
Certain problems occur here. One of which is ethernet packet latency and 
jitter, and the possiblilty of delays in the transmit and receive queues 
of the respective network cards/drivers. The proper study of scatter 
averaging distributions would be required to decide which jitter/latency 
correction algorith is used.

Another method for (1), is to have a single master clock, and use NTP to 
sync to it. The NTP will have to be the version of NTP that does 
jitter/latency correction after taking multiple samples over time.

A lot of the answers to the about problems would probably be achieved by 
experiment.

Cheers
James