WebRTC面临的挑战：大规模广播

　　CTI论坛(ctiforum.com)（编译/老秦）: 在围绕WebRTC周围的所有炒作和动能中，有一些事情没有很好地考虑到。在大型实况直播的情况下，它需要很多的帮助。当公司从一个简单的点对点视频转到多人会议和大规模广播时，像分布、延迟和镜像等问题都出现了。加入一些转换代码和其他东西等方式咋看起来是令人生畏的。

　　围绕着WebRTC广播的很多目前的讨论是去年底由于TokBox推出它的聚焦互动广播解决方案之后引发的。它被设计成可多方参与、可视频参与，并可扩展到数百名观众。个人可以加入直播，请求加入广播，并允许实时与一个或多个主持人以及所有观众交流。

　　福克斯体育利用TokBox建立了它的每周实况橄榄球焦点访谈节目。TokBox的优势包括不需要插件或第三方应用程序而是通过使用WebRTC；通过一个可定制用户界面的“最小”开发工作，所以很容易将广播解决方案嵌入到现有的网站和应用程序之中；和一个直观的制片人工作流，包括可以在社会化媒体分发视频内容的内置录音功能。

　　今天，从WebRTC到转码成不同格式的广播服务可以将“简单的”图片分发给大众。对于实时直播节目来说，从原始的WebRTC格式转换为其他格式的转码增加了延迟，包括任何在VP8 / VP9和H。264之间的代码转换。

　　把一个单一视频和镜像乘以成千上万的用户，这样规模的量也意味着需要提供必要的相应带宽和服务。这意味着与当前WebRTC媒介堆栈相比要繁重的多。

　　摆脱延迟意味着要从代码转换上下功夫，这是似乎诸如Flash的一种共识，苹果的HLS和MPEG应该作为中间步骤而被清除。由于大多数浏览器支持WebRTC本身，在未来支持其他流媒体格式就失去了意义。获得的好处是，复杂的和代价高昂的不同格式的转码将会消失。

　　扩展到成千上万影响着基础设施。当前内容分发网络（CDN）在分发视频业务中不支持WebRTC。在未来，这将被改变。

　　在“即服务”领域里可能将有更大的玩家出现，提供大规模WebRTC广播增值服务，包括从数百到数千的实时流，包括低延迟、最少的网间跳转，地理位置分散的服务器和对面向正常运行时间和延迟服的务水平协议（SLAs）。

　　并不是每个人都需要一个可伸缩的播放选项，但是那些愿意为高可靠性和最佳的体验而付费的人可以拥有。