我制作的媒体播放器基本上可以播放通过文本文件安排的任何内容。播放器也可以在多台机器（PC）上播放完全相同的剪辑。问题是同步。同样的视频开始在每台机器上播放，但它们出现了大约400毫秒，这看起来很糟糕，如果有声音则更糟糕。
我现在所做的是：
一台机器设置为主机，所有其他机器设置为从机。主人决定将播放什么项目。它等待来自每个从服务器的消息，一旦所有从服务器连接（或超时后），它就会广播需要播放的文件的项目ID。然后所有机器都开始播放该文件。
我也尝试过：
我认为文件加载时间可能是同步不匹配的主要驱动因素，所以我找到了代码来执行以下操作。
主人仍然决定要播放什么文件。它等待来自每个从站的连接消息（或超时），并传输要播放的文件的项目ID。所有机器都开始播放该文件，但会立即暂停。然后主设备再次等待来自每个从设备的就绪消息。一旦所有从站响应，主站就会向所有从站发送播放消息。然后所有机器继续该文件。
遗憾的是，这并没有改善这个问题。我现在很确定同步不匹配是由于网络延迟造成的。我怎么能补偿这个？或者也许确定每个奴隶的延迟？
所有网络通信都是使用winsock完成的。
非常感谢任何想法或想法。
答案 0 :(得分：2)
就我而言，完全同步它们的最接近的近似值就是这个。
部分解决方案：
Master：将带有时间戳的播放消息发送给客户 客户端：收到播放消息时，请回复确认。读取时间戳，计算消息到达的时间长度，并按该时间差延迟开始播放 Master：收到确认消息后，立即播放。
问题是你仍然会有多个确认，所以如果往返时间的平均偏差太高，你仍然会有很大的去同步。对此的一个解决方案可能是为每个客户跟踪某种平滑的往返时间估计。
替代解决方案：
Master：当您发送播放消息时，发送开始时间（所有客户端中的最高往返时间）以便客户端开始播放，并应安排播放所提供的时间。
客户端：当收到播放消息时，他们应该按照提供的时间安排播放。
答案 1 :(得分：1)
您可以使用已知的流媒体协议（例如RTP（或其他））来完成这项工作。通过网络读取文件（这似乎是你正在做的事情）容易出现网络延迟，如果所需的精度是毫秒级的话 - 你就会有实时限制。
答案 2 :(得分：1)
你可以从主设备ping掉奴隶机器以获得延迟偏移...如果它全部是本地的，它可能没有什么区别。
此外，您可能会使用您的消息循环播放该文件，因此根据您首先说话的机器，这也会引入延迟。
您可以同时向所有听音机广播，以避免这种情况。