HTTP 渐进式流的工作原理是在一个连续的流中简单地发送数据,而接收端则在数据进入时播放数据。网络的本质是数据以块的形式出现,而不是完全连续的,因此客户端播放音频有几秒钟的缓冲区,可以在周期性的数据突发中存活。
为了避免一分钟的丢失,客户端将来必须接收超过一分钟的数据。这是通过在服务器上缓冲一分钟的数据,然后在连接时尽快将该缓冲区刷新到客户端来实现的。虽然它不会同时到达客户端,但它应该相当快地到达那里,然后您将拥有可以在断开连接后幸存的缓冲区。也就是说,如果您的服务器比客户端领先一分钟,而具有完整 1 分钟缓冲区的客户端失去连接,它可以继续播放大约一分钟,然后不得不退出。
这只是问题的一半。当你重新连接时你会做什么?客户端如何与服务器同步?不幸的是,没有支持同步方式的实时 HTTP 渐进式公共服务器。我已经用Range 标头对自己进行了一些试验,什么不起作用,但需要一个自定义客户端。 (VLC 确实可以工作......)
您还必须考虑音频立即停止的原因。如果您试图通过打开飞行模式来模拟网络中断或慢点,这不是一个合适的测试。操作系统禁用网络接口,这会立即断开所有 TCP 连接,立即终止通向应用程序的管道。大多数应用程序将在此时停止播放,除非无论网络连接如何,它们都有一些额外的缓冲区。在您的网络连接质量受到影响的情况下,TCP 连接实际上很少被丢弃......数据包只是延迟导致音频最终随着缓冲区用完而停止。
根据您的需要,有两种解决方案:
在网络质量变化的情况下存活,TCP 连接存活
这很简单。增加刷新到客户端的服务器端缓冲区。我通常使用 20 秒。
请注意,并非所有客户端都会接受如此大的缓冲区。有些会降低 TCP 窗口大小,防止服务器发送过多的音频数据。
(注意:如果你不知道如何使用现有的流媒体服务器,buffer configuration is available on the AudioPump CDN 我创建了它。它还不是普遍可用的,但你可以给我发电子邮件brad@audiopump.co 试试看。)
经受住IP地址变化,TCP连接保证丢失
对于这种情况,您需要一个全新的流协议。 HLS 就是你想要的。
HLS 通过对必须由多个 HTTP 请求请求的流进行分段来工作。因此,客户端可以更改地址(例如从移动网络转到 WiFi),并且流仍然可以工作。
不幸的是,客户端对 HLS 的支持并不好,但服务器端很容易。大多数情况下,任何 HTTP 服务器都可以。编码器是需要更改的,用于编码和上传片段。