在完美的世界里,每个病人和医疗机构都将随时随刻获得可靠高速的，与强大设备的互联网连接。然而，考虑到今天人们生活高度移动的特性，还有在许多乡村和第三世界群体中的宽带连接的缺失，这使得通过互联网连接来进行远程医疗视频会议变得极其困难。 在本文中，我们将测试各种各样可能降低视频会议质量和可靠性的情况，还有当你选择视频会议提供商时的最好选择，来确保不论病人或卫生保健机构的设备或位置如何，你都
原文标题：Multi-Party WebRTC Option 2: MCU 作者：'Hector Zelaya , ' 多方WebRTC选择2：MCU 对于多方WebRTC一个不错的选择是MCU。MCU表示多点控制单元，又被称为混合，实现多方WebRTC交流的另一种策略。伴随着MCU，想法由使用peer建立连接变为只需要连接到中心服务器，中心服务器反过来发送信息到其它peers，并
原文标题：Multi-Party WebRTC Option 1: Mesh 作者：'Hector Zelaya , ' 多方WebRTC选择1：Mesh 有了WebRTC,对于为了建立多方视频通话而向连接中添加不止一个用户这件事你有很多种选择。Mesh可能是其中最明显的解决方法。就像你已经知道的，为了使连接成为可能，每一个使用RTCPeerConnectionAPI的peer必须
WebRTC 1.0 之后，还将有哪些变革? 作者: “Varun Singh“ 在6月19日至20日，WebRTC 工作组进行了一次临时会议，讨论 WebRTC 的未来。 所有浏览器供应厂商都对WebRTC v1.0做出了很正向的评价。WebRTC v1.0在2018年6月更新修复了多个 bug。WebRTC v1.0新 API 包括： 1.RTCRtpSender.setStreams() 2
原文标题：Adaptive Codecs — Good for Users, Bad for Networks 作者: “Sorell“ 自适应编解码—对用户友好，对网络糟糕 对于一些企业用户来说，使用基于云端的团队合作工具的体验是糟糕的，这需要改变。 网络管理员有责任为公司提供高效，可靠，安全的网络，但是他们对网络运行的控制越来越小。与网络管理员讨论他的三大主要问题，团队合作工具属于
原文标题：H.264 finally a first class citizen in WebRTC stacks 作者: “agouaillard“ H.264被列入了WebRTC所需的编码器 WebRTC 把H264和VP8都列入了WebRTC所必需要支持的视频编码器。同时联播可以同时使用多个编码器提供同一个媒体不同的分辨率来供人们选择以适应带宽波动（和其它）。不幸的是，libwebrtc没有
原文标题：Chrome Screensharing Blues – preparing for getDisplayMedia 作者: “Philipp Hancke“ 使用getDisplayMedia实现在Chrome中屏幕共享 Chrome网上商店已经决定停止允许Chrome扩展部件的内联安装，这对WebRTC应用有着极大的影响，因为目前在Chrome中屏幕共享需要扩展部件。GetDispl
作者：AGOUAILLARD（原文链接） 翻译：刘通 原标题：Webrtc Codec vs Media Engines: Implementation Status and why you should care. 前文链接：WebRTC编解码器vs媒体引擎-1，WebRTC编解码器vs媒体引擎-2 抖动及丢包 这些是最难处理的问题。抖动比较容易解决，首先创建一个缓冲区，由于所有的数据包都是编了
作者：AGOUAILLARD（原文链接） 翻译：刘通 原标题：Webrtc Codec vs Media Engines: Implementation Status and why you should care. 前文链接：WebRTC编解码器vs媒体引擎-1 3. 编解码器到媒体引擎：逻辑中断 实时媒体与普通媒体有着近乎相同的目标，但是其优先级有着非常大的区别： &
不同的浏览器支持哪个或者哪种编解码器。对于每个想要定义产品期望和路线的产品经理来说这都是一个棘手的问题。我应该只支持VP8/H264吗？我应该等待VP9吗？这些编解码器的多流，同播和SVC版本都是什么？除了所有这些问题还有：我什么时候可以告诉我的客户我能够分别支持桌面浏览器，Android和iOS系统？如果不能做到这点的话，那么我应该有一个原生app。本篇博文旨在讨论所有问题的本质。
WebRTC 中文社区由
运营