如果你正在使用WebRTC进行开发，那你需要特别注意浏览器版本的更新。因为这些版本可能会破坏你的应用程序。下面我会谈谈我是如何处理这个问题的。 过去一周内，我不止一次被问到WebRTC的向后兼容性如何。这是一个内涵丰富的话题，我们用一个比喻来说明WebRTC的开发过程，请看下面这个视频。 Saudi’s Again Changing Wheels Tyres while driving
浏览器端JavaScript 以下是PeerFetch类中 get(url, params) 方法的几行内容： async get ({ url = ‘/’, params = {} }) { console.debug(‘PeerFetch.get enter’, { url, params }) var esc = encodeURIComponent var query = Object.k
在初始配对过程中，UI应用程序和Edge设备都要找信令服务器询问房间ID。信令服务器使用每个客户端的公共IP和一个秘密字符串来计算sha1哈希值。这会使不同家庭中的客户端很难得到同一个匹配房间ID。 UI和Edge一旦获得本地房间ID便会加入房间，并向信令服务器询问房间成员列表。这是UI和Edge首次且唯一一次发现彼此（由加密UUID4生成）ID的地方。 端对端连接协商 从那时起，U
提到WebRTC大多数人会想到视频通信。而家庭监视通常与视频流相关联。这就是为什么我听到一个家庭安全项目不是将WebRTC用于视频流，而是DataChannel时很惊讶的原因。WebRTC的DataChannel可能不能实现视频通话，但是如您所见，它可以很方便地设置端到端的信息传输。 IvelinIvanov是RedHat、Mobicents和Telestax等各种项目和组织的长期开源贡献者。最近
在多年辉煌过后，Flash迎来了2020年——Chrome官方支持其操作的最后一年。 Flash是直播技术领域发展的基石。通过使用RTMP协议，Flash为现在的技术发展奠定了基础。在转为游戏流媒体平台Twitch之前的通用流媒体平台Justin TV是由Flash驱动的。随着视频直播需求增长，Flash被证明有一定局限性（依赖插件、专利技术、性能问题等），会阻碍实时流媒体的发展。 值得一提的是，
Google Stadia 对于Google Stadia，Google使用QUIC代替SCTP作为控件，用WebRTC进行实时流式传输。 但这还不够。Google Stadia需要更低的WebRTC延迟。因此，Stadia添加了一个Chrome实验来减少WebRTC中的播放延迟。我的一些客户已经采用了这项实验，并对自己用例的结果感到满意。 Google还调整和改进了VP9解码器，
是否使用WebRTC Meet、Duo和Stadia似乎是Google使用WebRTC的主要目的，而不是用其来处理社区的投诉和反馈。 Google Meet Google Meet使用VP9来进行操作。VP9是可进行大规模生产的群体呼叫服务商之一。通过WebRTC和其路线图，Google可以比其他人更快地进行实验并构建其服务。 关于这点，去年有两个很有趣的事例： 在2018 Kranky Geek
Duo Duo是Google针对Apple FaceTime推出的一款软件。 它是一款可在Android和iOS上使用的独立视频通话应用程序。但是大多数智能手机均未默认安装该软件。用户需要自己找到它、安装并决定使用它。所以其操作上来说并不简单。 为什么Google没把它设为Android的默认程序呢？可能是Google不想影响用户的使用感（以及Google与用户的关系）。否则对于Google来说，
Google内部发布的WebRTC路线图表明：Google或是已经改变了其WebRTC计划，或是准备公布了。 WebRTC内涵丰富。 一方面，它是W3C的标准规范（1.0版本很成功）。另一方面，它是一个开源项目。虽然现在也有一些同类项目，其中最重要的还是Google的webrtc.org。因为它是进入Chrome的代码，被许多人采用（因为它针对主要场景进行了高度优化，并且是免费的）。 企业可以很简
基于REMB的解决方案 我们试着用一种不同方法来解决上述问题。REMB在服务器端工作，它计算所有传入流的传入比特率，计算其与均值的偏差，通过RTCP协议发送专门的REMB指令，来通知浏览器在明显分散的情况下降低比特率。浏览器收到通知后，将视频编码器的比特率降低为推荐值，来防止通道过载和传入流降级。这样，服务器端就实现了比特率计算机制。我们通过卡尔曼滤波器来确定均值和分散。这样在任何时间我们都能获得
WebRTC 中文社区由
运营