5

I have made a media player that plays basically anything that's scheduled to it via a text file. The player can also play the exact same clip on multiple machines(PC's). The problem is the syncing. The same video starts playing on each of the machines, but they are out by about 400ms, which looks crap and if there's sound it's even worse.

What I do at the moment is:

One machine is set up as the master and all other machines are set up as slaves. The master decides what item will be played. It waits for a message from each of the slaves, once all slaves are connected (or after the timeout), it broadcasts the item id of the file that needs to be played. All machines then start playing that file.

What I also tried:

I thought that the file loading time might be the major driving factor in the sync mismatch, so I chankged the code to do the following.

The master still decides what file to play. It waits for the connect message from each slave (or timeout) and transmits the item id of the file to play. All machines start playing that file but pauses it immediately. The master then again waits for a ready message from each of the slaves. As soon as all slaves responded the master sends a play message to all slaves. All machines then continue the file.

This unfortunately did not improve the problem. I am now pretty sure the sync mismatch is due to network delay. How can I compensate for this? Or maybe determine the delay to each slave?

All network comms are done with winsock.

Any thoughts or ideas is much appreciated.

Nemesis
  • 109
  • 1
  • 1
  • 8

3 Answers3

2

The closest approximation to perfectly syncing them, as far as I figure, is this.

Partial Solution:

Master: Send the play message with a timestamp to clients.
Clients: When the play message is received, respond with an acknowledgment . Read the timestamp, calculate how long the message took to arrive, and delay starting the playback by that time difference.
Master: When the acknowledgment message is received, play immediately.

The problem is that you'll still have multiple acknowledgments, so if the average deviation in round-trip-time to is too high, you'll still have a large de-synchronization. One solution for this might be to keep track of some kind of smoothed round-trip-time estimator for each client.

Alternative Solution:

Master: When you send a play message, send a start time (the highest round-trip-time among all clients) for the clients to begin playback, and should schedule playback for the provided time.
Clients: When the play message is received, they should schedule playback for the provided time.

Sion Sheevok
  • 4,057
  • 2
  • 21
  • 37
  • Thought about this as well. For this to work, all machines' time have to be synced (to less than 100ms), which usually is not the case. However, the Windows Time Service cannot maintain the system time more accurately than about a 1-2 second range. – Nemesis Mar 11 '11 at 11:11
1

You can use the known streaming protocols, such as RTP (or others) to do the job. Reading a file over the network (which is what it seems that you're doing) is prone to network delays, and if the precision required is in milliseconds - you've got real time constraints there.

littleadv
  • 20,100
  • 2
  • 36
  • 50
  • I am not streaming. The file that plays is stored locally on each machine. The master just informs the slaves to which file to play and when. Only messages are being sent over the network. I can live with a delay of 100ms or less. – Nemesis Mar 11 '11 at 09:45
  • @Nemesis - then it's even easier. Use NTP to sync the clocks, and you're good to go. – littleadv Mar 11 '11 at 19:41
  • the Windows Time Service cannot maintain the system time more accurately than about a 1-2 second range. – Nemesis Mar 14 '11 at 08:27
  • Did I say "Windows Time Service"? Sorry, I meant "NTP". – littleadv Mar 14 '11 at 17:52
  • Thanks @littleadv. But I seriously do not want to implement a complete NTP. The windows time service syncs to an NTP server, I thought that that is what you meant. – Nemesis Mar 23 '11 at 09:49
  • Aren't there any ready NTP implementations? I used NTP clients on Windows, I vaguely remember it was freeware, and was much more precise than 1-2 secs. Don't remember what it was now, but do google some, you don't need to reinvent the wheel. – littleadv Mar 23 '11 at 18:40
  • Thanks for all your help. I timed the network delay and it is a lot less than I expected and, I'm now sure, not the major delay in my syncing problem. The major driving factor is the time it takes the file to load. All machines aren't the same and thus the syncing problem occurs. To solve I'm gonna do the following. Each slave determines it's latency to the master and compensates for that. Also, the most important, I will load the file on all machines and immediatly pause it. Once all machines are ready again, they start playing, thus reducing or hopefully removing the sync mismatch. – Nemesis Mar 29 '11 at 09:18
  • I am selecting yours as the correct answer. Even though I didn't use RTP to stream video to the slaves, I did use RTP to inform the clients of the position of the video file the master is currently at. I actually used multicast, so could have just used UDP, but I found a very decent and easy to use RTP library with threads and everything allready built in. [JRTPLIB](http://research.edm.uhasselt.be/jori/jrtplib/jrtplib.html) – Nemesis Jul 06 '11 at 11:50
1

you could ping the slave machines from the master to get a delay offset... if it's all local it might not make a difference.

Also you're probably going round robin with your message to play the file, so that would introduce a delay too depending on which machines you speak to first.

You could maybe broadcast to all listening machines at the same time to avoid this.

TonyM
  • 186
  • 2
  • 11
  • 1
    if it's always the same pc's in the same order, just send a sleep before unpause time to each client which factors that in – TonyM Jun 15 '11 at 16:39