[MPlayer-dev-eng] Synchronization of players in LAN
James Courtier-Dutton
James at superbug.demon.co.uk
Thu Nov 20 17:06:29 CET 2003
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
More information about the MPlayer-dev-eng
mailing list