通过网络同步视频播放
我制作了一个媒体播放器，基本上可以播放通过文本文件安排的任何内容。播放器还可以在多台机器（PC）上播放完全相同的剪辑。问题是同步。同样的视频开始在每台机器上播放，但延迟了大约 400 毫秒，这看起来很糟糕，如果有声音那就更糟了。
我现在所做的是：
将一台机器设置为主机，将所有其他机器设置为从机。大师决定播放什么项目。它等待来自每个从属设备的消息，一旦所有从属设备都连接起来（或超时后），它就会广播需要播放的文件的项目 ID。然后所有机器开始播放该文件。
我还尝试过：
我认为文件加载时间可能是同步不匹配的主要驱动因素，因此我更改了代码以执行以下操作。
主机仍然决定播放什么文件。它等待来自每个从属设备的连接消息（或超时）并传输要播放的文件的项目 ID。所有机器都开始播放该文件，但立即暂停。然后主设备再次等待来自每个从设备的就绪消息。一旦所有从设备响应，主设备就会向所有从设备发送播放消息。然后所有机器继续该文件。
不幸的是，这并没有改善问题。我现在很确定同步不匹配是由于网络延迟造成的。我该如何弥补这一点？或者也许确定每个从站的延迟？
所有网络通信均通过winsock 完成。
任何想法或想法都非常感激。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
据我所知，最接近完美同步它们的就是这个。
部分解决方案：
Master：将带有时间戳的播放消息发送给客户端。
客户端：收到播放消息后，以确认响应。读取时间戳，计算消息到达需要多长时间，并按该时间差延迟开始播放。
Master：收到确认消息后，立即播放。
问题是您仍然会有多个确认，因此如果往返时间的平均偏差太高，您仍然会出现很大的不同步。一种解决方案可能是跟踪每个客户端的某种平滑往返时间估计器。
替代解决方案：
Master：当您发送播放消息时，发送一个开始时间（所有客户端中最长的往返时间）以便客户端开始播放，并应安排在提供的时间播放.
客户端：收到播放消息后，应安排在提供的时间播放。
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.
您可以使用已知的流协议，例如 RTP（或其他）来完成这项工作。通过网络读取文件（这似乎是您正在做的事情）很容易出现网络延迟，并且如果所需的精度以毫秒为单位 - 您就会受到实时限制。
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.
你可以从主机上 ping 从机来获取延迟偏移...如果都是本地的，则可能不会产生任何影响。
此外，您可能会循环播放文件的消息，因此这也会导致延迟，具体取决于您首先与哪些机器通话。
您可以同时向所有收听机器广播以避免这种情况。
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.