2016-04-28 35 views
1

我通过试图使这个网络真正影响直播流而学会了。例如,如果您将4096字节的MP3流式传输到0,则缓慢连接将缓冲并跳过,因为快速连接将缓冲到快速并大大失去同步。 shoutcast/icescast如何解释这个问题?icecast/shoutcast如何同步多个连接的音频?

回答

1

简短的回答是:他们不是

流式播放通常会漂移5-60秒。这是这种类型的流媒体固有的,而不是一个错误/问题。

传统的广播收音机也会有类似的效果。不同发射机(频率)之间的延迟可能存在差异,并且如果通过卫星或DAB /数字地面广播同时广播,则将其与例如卫星或DAB /数字地面广播相比将会有显着的延迟。 '模拟FM'。当然,所有使用相同方法/频率的接收机将大致同步。

如您注意到的那样,HTTP流式传输的技术原因在缓冲区中。最大的影响是由于客户端缓冲区大小。如果运行缓冲区(例如,由于连接不良/拥塞),播放器软件通常会显着增加缓冲区大小。

这就是说,当然有非常基本的“同步”,即在同一时间连接的两个客户端将从相同的时间点发送比特流,而稍后连接的客户端将发送与其他客户端匹配的比特流两个客户在当时正在接收。这意味着,从更大的角度来看,客户端几乎同时都处于大致相同的点,并且几乎同时接收相同的数据 - 这是因为它是一个“实时流”,如果它是静态文件,则每个客户端将从一开始就开始,并且根本没有关系。 PS:如果您正在寻找一种与墙上时钟同步的硬参考解决方案,那么与VoIP相关的技术就可以走了。对于本地网络,有各种协议可以将接收机同步到信号相位。

+0

我知道由于多种因素,完全同步是不可能的。但是,shoutcast/icecast似乎在几秒钟内关闭,有时甚至是几分钟。我试过创建一个FPS系统,但我仍然无法像其他人那样得到相同的结果。我无法真正理解icecast编码的语言,所以查看它的来源只会让我迷失方向。我所知道的唯一语言是python/js/Lua,但似乎没有任何可以参考的语言。 –

+0

非常基本的底层概念是*循环缓冲区*。它以(简化)恒定速率从源客户端填充。当一个客户端连接它时,它会被挂接在结束指针的位置附近,并在它进入的同时开始接收数据。如果由于某种原因客户端无法跟上接收数据的速度,那么它可能会落后在这个缓冲区内,然后可能再次赶上。如果在任何时候它到达缓冲区的起始指针(从它的角度来看都是'空'),它会被丢弃,因为服务器不能确保数据的连续性。 – TBR