我正在制作一个应用程序,它需要将视频提要从一个单一的源发送到服务器,在那里它可以被桌面浏览器和移动应用程序访问。
到目前为止,我一直在使用5和一个活动的RTMP流。这使我在桌面浏览器上延迟了大约2.5秒,这使我没有对iOS的原生支持,但我可以选择使用Air为iOS导出应用程序,这至少会产生5-6秒的延迟。
iOS文档强烈建议使用,它将流分割成块,并使用.m3u8文件中的动态播放列表提供服务。这样做会在桌面浏览器和移动设备中产生15+第二次延迟。谷歌搜索似乎表明,这是预期从HLS。
如果可能的话,我需要在所有设备上最多延迟2-4秒.我和沃扎的成绩很差,但我愿意重新考虑。FFMpeg看起来效率很低,但是如果有人已经取得了很好的效果,我也会接受的。有人有什么建议吗?提前谢谢。
我甚至还没有开始找到最有效的方式流到Android,所以在这个部门的任何帮助都是非常感谢的。
编辑:只是想说清楚,我的计划是制作一个iOS应用程序,无论它是本地编写的还是在Air中编写的。Android也是如此,但我还没有开始。
发布于 2014-06-17 13:37:02
在ios浏览器中,HLS是提供实时视频的唯一方式。绝对最低的延迟将是在清单中使用2个段窗口的2秒段。这将给您在客户机上的4秒延迟,以及服务器上的另一个2-4秒的延迟。如果不编写应用程序,就没有办法做得更好。
发布于 2014-08-04 12:35:19
对于HLS流来说,15秒延迟是很好的,为了提供更低的延迟,您需要使用不同的流协议。RTP/RTSP将为您提供最低的延迟,通常用于VoIP和视频会议,但您将发现很难在多个移动和WiFi网络上使用(其中一些网络无意中阻止RTP)。如果您可以编写一个支持RTMP的iOS应用程序,那么这是最简单的方法,并且也应该在Android上工作(只有老的Android系统支持Flash/RTMP本地版本)。软件解码会导致电池续航能力差。还有一些iOS应用程序不使用HLS进行流处理,但我认为您需要将其限制在您的服务上(而不是普通的视频播放器)。
另外,请记住,更高的延迟意味着更高的视频质量,更少的缓冲,更好的用户体验等等,所以不要不必要地减少延迟。
https://stackoverflow.com/questions/24259391
复制相似问题