我们很难抉择应该给WebRTC应用选哪一款音视频编解码器。VP8？H.264? VP9？还是使用AV1？HEVC呢？ 有关WebRTC视频编解码器的温馨提示 曾几何时WebRTC世界很简单，只有VP8、Opus和G.711。G.711被划掉是因为我不推荐使用它。真的没有理由这样做。后来，H.264作为必须实现的视频编解码器加入。WebRTC进展顺利。 之后，谷歌决定在Chrome中引入VP9，将其
声网Aogra 开源了自研的 SOLO 编解码器，面向所有音视频、WebRTC 开发者。本系列源码解读将讲解底层核心技术，并分享如何集成到自己的 WebRTC 应用中。本文为第一篇。 SOLO 在 Silk 的基础上扩展了带宽扩展模块，用来分别处理低频信息（0-8kHz 采样部分）和高频信息（8-16kHz 采样部分），在编码端，两者使用两套耦合的分析编码系统进行码流生成。在解码端，利用低频信号和
WebRTC SFU的职责之一是接收和发送RTCP数据包。RTCP数据包包括关于音频和视频流的不同类型的反馈，并且最重要的RTCP数据包是接收器报告(RR). RR数据包从媒体流接收器发送到该媒体流的发送者。在SFU的情况下，RR由SFU产生，并发送到媒体流发送器，并且还从每个流接收器发送到SFU。(如图1)。 RR数据包内发送的反馈包括用于计算网络引入的往返时间延迟，抖动和信息丢失。 这些RR数
从事电视广播行业的人都了解，每十年就会出现新一代的视频压缩方案，可以提供比前几代更高的效率。 MPEG-2编码在1990年代拔得头筹，H.264（AVC）在2000年代中期独领风骚，之后H.265（HEVC）扬言从2012年开始淘汰其它同类产品，但其并没有成为新一代“最普遍的编码”。这并不能归咎于编码技术不可靠——无可否认的是，HEVC在付费电视运营和流媒体服务方面做得很好。而4K超高清技术的出现
WebRTC的狂野世界 在过去的五年中，已经有太多的方式使得网页和App中支持视频会议。 Facebook,WhatsApp,FaceTime和Signal是其中几种用户可以用来在网络中进行视频，音频通话的方式。尽管很多研究已经开始转为对视频会议的加密和隐私保护，关于这些平台的易受攻击程度的信息却很少。我们查阅了三个最为广泛使用的视频会议实现方式。在本文中，我们会对此描述。 这一部分将会讨论的We
QUIC自从2013年为人所知，最近两年一直是网络会议讨论的热门话题。原因是，QUIC作为传输层协议发挥了TCP，UDP的最佳效果，添加了加密，速度倍增，其它方面也有改进，使得设备上部署速度和更新速度较之前都有提升。如果你想大概了解QUIC，wikipedia是一个不错的选择。进一步的了解可以通过IETF工作组获得更多详细信息。 简介 你可能认为传输层协议应该与在它上面运行的App分开设计，QUI
抓取WebRTC流量看起来相对简单，大多数情况下确实是这样：你只需要在其中一人的机器上安装类似tcpdump或wireshark的抓包工具，然后查看产生的文件，大多数情况会是.pcap或.pcapng文件。这些活动对于诊断连接问题或其它与WebRTC相关的问题很有用：实际上，wireshark可以自动检测出STUN，DTLS之类的标准协议，这些是WebRTC PeerConnections所关注的
Zoom的Web客户端可以在用户不下载它们App的情况下加入会议。Chris Koehncke很高兴能看到它是如何工作的。这确实有效，不必花时间下载App.并且视频质量可以接受，对此我们愉快的讨论了半小时。 打开 chrome://webrtc-internals只看到了getUserMedia被用来获取摄像头和麦克风，但是没有看到RTCPeerConnection的使用。这激起了我的兴趣，它们是
WebRTC vs Zoom? WebRTC很不错， 但是你早就知道了,不是么？ 我们不止一次被告知这个视频会议供应商或者那个供应商很不错。它们提供最好的画质，最好的体验。它们的视频会议效果可以比别人更好。 我甚至曾经接到了一个公司的电话，向我解释他是如何提供一个比Skype或者Google Hangouts更好的1对1视频质量。它们使用WebRTC实现。 但是我偏离话题了。 就像其他人一样，我被
最佳实践1：选择一个视频方案，可以监测视频质量并且调整带宽。 当视频会议超出可获得带宽上限后，将会导致画面中断，低画质，视频音频不同步等等问题，并且伴随有丢包现象，这将会影响视频会议的质量。这就是为什么你需要选择一个可以监测通话质量和对丢包现象，网络拥堵，延迟等等可以做出相应调整的系统。 第一步，当网络状况变坏时，许多视频会议系统将会降低帧数。这是一个好办法并且通常可以维持视频会议的
WebRTC 中文社区由
运营