【发布时间】：2016-04-28 22:20:39
【问题描述】：
通过尝试使网络真正影响直播流，我学到了这一点。例如，如果您以 4096 字节流式传输 MP3 直到 0。慢速连接将缓冲并跳过，因为快速连接将缓冲到快速并大大失去同步。呐喊/icescast 是如何解释这一点的？
【问题讨论】：
标签： http-live-streaming shoutcast icecast
【发布时间】：2016-04-28 22:20:39
【问题描述】：
简短的回答是：他们没有。
流播放通常会相差 5-60 秒。这是这种类型的流媒体所固有的，而不是错误/问题。
传统广播电台也有类似的效果。不同发射机（频率）之间的延迟可能存在差异，如果通过卫星或 DAB/数字地面广播进行联播，则与例如'模拟调频'。当然，所有使用相同方法/频率的接收器将大致同步。
如您所见，HTTP 流的技术原因在于缓冲区。最大的影响是由于客户端缓冲区大小。如果播放器软件在运行缓冲区时（例如由于连接不良/拥塞），通常会显着增加缓冲区大小。
这就是说当然有非常基本的“同步”，即同时连接的两个客户端将从同一时间点发送比特流，而稍后连接的客户端将发送与其他两个匹配的比特流客户在那个时间点收到。这意味着从更大的范围来看，所有客户端都在大致相同的点并几乎同时接收相同的数据 - 这是因为它是一个 “实时流”，如果它是静态文件，每个客户端都会从头开始，根本没有关系。
PS：如果您正在寻找与挂钟硬参考同步的解决方案，那么 VoIP 相关技术是您的最佳选择。对于本地网络，有多种协议可以将接收器同步到信号相位。
【讨论】：
-
我知道由于多种因素，完全同步是不可能的。但是，shoutcast/icecast 似乎关闭了几秒钟，而我有时关闭了几分钟。我已经尝试创建一个 FPS 系统，但我似乎仍然无法获得与其他系统相同的结果。我无法真正理解 icecast 的编码语言，所以查看它的源代码只会让我迷失方向。我知道的唯一语言是 python/js/Lua，但似乎没有任何我可以参考的语言。
-
最基本的基本概念是循环缓冲区。它以（简化的）恒定速率从源客户端填充。当客户端连接时，它会在结束指针的附近/位置连接，并在它进入的同时开始接收数据。如果由于某种原因客户端无法跟上接收数据，那么它可能会落后在这个缓冲区内，然后可能再次赶上。如果在任何时候它到达缓冲区的起始指针（从它的角度来看是“空”），它就会被丢弃，因为服务器无法确保数据的连续性。