我正在开发一款应用，需要将视频供稿从单一来源发送到服务器，桌面浏览器和移动应用可以访问该服务器。
到目前为止，我一直在使用带有实时RTMP流的Adobe Media Server 5。这给了我大约2.5秒的桌面浏览器延迟，这让我没有iOS的本机支持，但让我可以选择使用Air导出iOS的应用程序，这会产生至少5-6秒的延迟。
iOS文档强烈建议使用HTTP Live Streaming将流分段为块并使用.m3u8文件中的动态播放列表提供服务。这样做会在桌面浏览器和移动设备上产生15秒的延迟。谷歌搜索似乎表明这是HLS的预期。
如果可能，我需要在所有设备上最多延迟2-4秒。我对Wowza的结果很差，但我很乐意重新审视它。 FFMpeg似乎效率低下，但如果有人用它取得好成绩，我也会对此持开放态度。有人有什么建议吗？提前谢谢。
我甚至没有找到最有效的流式传输到Android的方式，因此非常感谢该部门的任何帮助。
编辑：为了清楚起见，我的计划是创建一个iOS应用程序，无论是本地编写还是在Air编写。 Android也是如此，但我还没有开始。
答案 0 :(得分：1)
在ios浏览器中，HLS是提供实时视频的唯一方式。绝对最低延迟将是使用清单中具有2个段窗口的2秒段。这将在客户端上提供4秒延迟，在服务器上再提供2到4个延迟。没有编写应用程序就没有办法做得更好。
答案 1 :(得分：0)
15 HLS流的第二次延迟非常好，可以提供使用不同流式传输协议所需的更低延迟。 RTP / RTSP将为您提供最低延迟，通常用于VoIP和视频会议，但您会发现很难在多个移动和WiFi网络（其中一些无意中阻止RTP）上使用。 如果您可以编写支持RTMP的iOS应用程序，那么这是最简单的方法，也应该适用于Android（只有旧的Androids本身支持Flash / RTMP）。软件解码将导致电池寿命缩短。还有其他iOS应用程序不使用HLS进行流式传输，但我认为您需要将其限制为您的服务（不是通用视频播放器）。
另外请记住，更高的延迟等于更高的视频质量，更少的缓冲，更好的用户体验等。所以不要不必要地减少延迟。