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

[J.A. Gutierrez]

On Thu, Nov 20, 2003 at 04:06:29PM +0000, James Courtier-Dutton wrote:
> 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 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.

	According to my experiments, using NTP, gettimeofday
	returns differences below 40 ms:

# sec:usec = 1069231417:653136
# sec:usec = 1069231417:653433
# sec:usec = 1069231417:656074
# sec:usec = 1069231417:653073
# sec:usec = 1069231417:653663
# sec:usec = 1069231417:653664

	so it seems it could be enough accurate for 25 fps.
	(these measures are taken after 5 days uptime)

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

	and then, if the player is not synchronising with any
	audio signal, all of them would would keep in sync?
> 
> 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.)

	maybe running the player with high (real time) priority would
	help?

> 
> (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.

	Well, having identical hardware/software for all the slaves
	will help here.
> 
> 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.

	I think NTP take care of all these questions; it seems too
	complex to add all these features to mplayer...

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

	I don't have too much time to dedicate to this problem, so
	I'll start looking to NTP / internal clock synchronisation,
	and then, maybe the other solution using audio broadcast...


-- 
finger spd at shiva.cps.unizar.es for PGP      /
.mailcap tip of the day:                   /             La vida es una carcel
application/ms-tnef; cat '%s' > /dev/null /           con las puertas abiertas
text/x-vcard; cat '%s' > /dev/null       /            (A. Calamaro)