客户端架构和WebRTC

了解更多关于WebRTC的信息流媒体东部.

看完整的视频和其他亮点从流媒体西部连接上流媒体的YouTube频道.

阅读这段视频的完整文本:

罗伯特•莱因哈特: 让我们谈谈您在使用WebRTC时可能遇到的客户端架构问题, 这是其他体系结构所没有的. 就像我说过的大多数传统应用一样, 那些牲畜拍卖, 还有葡萄酒拍卖, 它们都是RTMP, 只有TCP协议. 那是我们唯一的选择. TCP可能会随着时间的推移而开始延迟. 这并不是说RTMP没有问题, 但是当涉及到端口和访问防火墙时, 这是一个更简单的方程. 我记得所有这些. 有多少人记得RTMP刚出现时的问题? 当我在洛杉矶的Schematic工作时.A., 一家为迪士尼做项目的大公司, 美国广播公司, 和NBC, 总是, 如果有什么是基于rtmp的, 一些大人物在公司防火墙后面，RTMP无法通过.

So, 当他们开始从RTMP转向HTTP流时, 这产生了巨大的影响, 因为HTTP会通过大多数防火墙. 除非他们正在进行数据包自省，并准确地查看通过该端口和该协议的内容, 但WebRTC是TCP和UDP的混合体. UDP会给你最低的延迟. 如果您没有正确的TURN实现，UDP可能会有问题. 如果我在用手机，躲在不对称网络后面, 那么作为正在进行的WebRTC会议的一部分可能会有问题. 但TURN服务器有助于缓解这一问题. 但是，有些供应商不支持TURN. 这就是问题所在. 所以你要确保你做了你的尽职调查.

供应商锁定:WebRTC是一个没有单一正确实现的规范. 我一会儿会讲到这个. 我要重点介绍的是. Alex Gouailliard已经看到了一些牵引移动到更一致的实现, 至少从客户的角度来看是这样.

自适应比特率——一些浏览器支持联播. 就像我已经提到的，VP8 SPC可能是未来的选择. 一般来说，SVC作为一个概念，可以是一种选择. 如果我们开始看到它出来 ... 你必须记住，WebRTC起源于最初的P2P概念. 所以服务器, 如果他们参与其中的话, 仅仅是目瞪口呆的服务器来协商IP，而客户端可以通过P2P直接相互交谈吗.

无服务器基础设施——如果需要的话, 然后，当你试图向那些无法收到高质量信息的人提供高质量信息时，你就只有这么多的选择了, 你打算怎么做? 如果你的P2P是一对一的，你就有更多的选择. 但是如果你的P2P会话涉及不止一个人, 两方以上, 事情会变得复杂起来.

摄像头和麦克风访问——这更多的是一个UX的东西, 但是再一次, 你必须玩的东西, 就像flash应用程序一样. 你可以在那里看到很多WebRTC的例子, 你必须进入浏览器设置来更改摄像头和麦克风. 当然，您可以在JavaScript中公开它, 但这是你需要注意的事情. 选择相机，选择麦克风，调整它们的属性.

Flash有自己的学习曲线. 我并不是说WebRTC更困难，但这是我的抱怨之一. 我经常和客户一起工作, web开发者——如果你是其中一员，请不要误解这一点——希望总是有一个SDK. 但是我不得不在没有真正的sdk的情况下进行大量的开发. 你必须从头开始用ActionScript构建东西. 你必须使用本地类，建立自己的东西.

我以后会讲到这点. 当我与web开发人员和WebRTC合作时，我发现这可能是最大的痛点之一, 这是媒体捕捉吗, 通过比特率获得所有正确的参数, 帧率. 将这些控制措施落实到位可能是个大问题，因为这需要时间. 如果你习惯用SDK让事情变得简单. 你已经习惯了，“嘿，我要去找一个web应用开发者. 我知道怎么做X Y和Z.你开始和他们讨论媒体捕捉api. 这就是特色菜的发展方向, 但如果你需要马上开始工作，而你又没有时间去经历那些学习曲线, 那么这可能会影响你决定如何构建下一个WebRTC应用程序.