用于移动P2P的HLS（HttpLiveStreaming）与UDP上的RTP（实时传输协议）？

Question

我正在测试移动设备之间的音频/视频P2P连接。

学习WebRTC，我注意到NAT遍历（使用STUN服务器）和UDP-hole-punching是使P2P成为可能的关键。

另一方面，我注意到iOS设备上的HLS（HttpLiveStreaming）针对A / V直播流进行了优化，即使使用Android4.x（3.x不稳定）也可以广泛使用

所以，这是我的问题如果我使用HLS进行移动P2P ：

a）HLS是TCP（HTTP）上的协议而不是UDP，所以不存在性能缺陷吗？

请参阅：TCP vs UDP on video stream

b）NAT遍历怎么样？因为HLS是HTTP（端口：80）会更容易吗？ 我已阅读维基百科http://en.wikipedia.org/wiki/HTTP_Live_Streaming

  

由于其请求仅使用标准HTTP事务，HTTP Live   Streaming能够遍历任何防火墙或代理服务器   允许通过标准HTTP流量，不像基于UDP的协议，如   RTP。这也允许广泛提供内容   的CDN。

c）Android设备兼容性如何？调用StreamingLive分发有很多问题吗？

感谢。

Answer 1

通过UDP / RTP比较HTTP直播流与P2P视频流几乎就像比较苹果和橙子。更像是橘子和橘子......继续阅读。

HTTP Live Streaming被设计为客户端 - 服务器协议，没有P2P或NAT遍历考虑。这个想法是流媒体服务器已经通过HTTP / TCP并且可以从公共互联网访问，就像它只是一个普通的Web服务器一样。 HLS的主要功能是它能够根据客户端接收流的速度动态切换比特率。如果客户端与服务器的连接打乱了尝试流式传输1080p视频，它可以透明地切换到发送较低比特率的视频（如果网络条件改善，可能会以更高的比特率切换回流式传输）。很好的例子：Netflix。

WebRTC和ICE旨在在可能位于NAT后面的设备之间双向传输实时视频。因此，通过UDP遍历NAT比TCP更容易。 UDP比TCP更实用（更少的延迟）。大多数视频聊天客户端（ala Skype）都在其编解码器和协议中内置了动态带宽调整，以实现类似于HLS的功能。

我想你可以将TCP NAT traveral和HLS结合在一起。通过UDP执行HLS意味着您可以在UDP流之上构建类似TCP的可靠性层。

希望这有帮助

Answer 2

防火墙不是HLS的问题的原因是它是一个客户端 - 服务器协议，其中所有请求都通过端口80上的HTTP完成。如果您正在实施P2P应用程序，您将无法将其附加到除非您具有root权限，否则低于1024的端口。

这意味着通过HLS（端口80）交换数据不适用于P2P。除非你的中间有翻译服务器，否则会破坏P2P的目的。

Answer 3

http://www.garymcgath.com/streamingprotocols.html

  

HTTP直播

     

流媒体的新趋势是使用带有协议的HTTP   支持自适应比特率。 这在理论上是不合适的，因为HTTP   使用TCP / IP是为了可靠的交付而不是保持一致   稳定的流量，但随着高速连接的普遍存在   它并不重要。 Apple的条目是HTTP Live Streaming，   又名HLS或Cupertino流媒体。它是由Apple为iOS和iOS开发的   在Apple的产品之外并没有广泛支持。长尾视频   提供测试页面以确定浏览器是否支持HLS。   其规范以互联网草案的形式提供。草案   包含专有材料，出版衍生作品是   禁止的。

     

唯一允许的播放列表格式是M3U Extended（.m3u或.m3u8），但流的格式仅受实现限制。

Answer 4

我可以在Android上使用WebRTC在Mozilla Firefox浏览器和另外两个桌面浏览器（Chrome和Firefox）上使用WebRTC实现P2P。

以下是我在大学上发表的演示文稿的屏幕截图：https://www.dropbox.com/s/zyfgs4o8al9ovd0/Screenshot%202014-07-17%2019.58.15.png

此屏幕截图是通过访问http://bem.tv/demo.html制作的。

如果您想了解更多信息，请参阅我的硕士项目，并在http://bem.tv和http://github.com/bemtv上发布我的进展。