近日有研究预估，经WebRTC传输的实时视频流量会暴涨。这再次表明，在未来几年内，大规模、交互式视频流注定会得到更多用户垂青。 Rethink Technology Research预测；到2025年，“纯WebRTC”流媒体将达到650 EB（2020年该项数据为16.8 EB）。根据研究人员评估，到2024年底，通过内容交付网络（CDN）交付的实时视频将达到约3628EB；到2025年，纯We
我们很难抉择应该给WebRTC应用选哪一款音视频编解码器。VP8？H.264? VP9？还是使用AV1？HEVC呢？ 有关WebRTC视频编解码器的温馨提示 曾几何时WebRTC世界很简单，只有VP8、Opus和G.711。G.711被划掉是因为我不推荐使用它。真的没有理由这样做。后来，H.264作为必须实现的视频编解码器加入。WebRTC进展顺利。 之后，谷歌决定在Chrome中引入VP9，将其
本文首发于 InfoQ，由声网 Agora 开发者社区 与 InfoQ 联合策划，并由 InfoQ 审校。 WebRTC 在今年 1 月被 W3C 和 IETF 发布为正式标准。从开源至今，十年的时间，倾注了众多开发者的贡献。本文由 Google WebRTC 产品经理 Huib Kleinhout 基于在由声网举办的 RTE 大会上的分享汇总整理，并增加了其近期对于 WebRTC 前景的看法。
什么是WebRTC，它是如何开始的？ 近20年来，人们已经清楚地认识到“语音通话的未来”将不再仅是电话通话，而是发展出更多样化的应用和用例。之前的企业软电话、IP联络中心、音视频会议和协作工具大多很粗糙，用户体验不佳。 VoIP应用或视频浏览器扩展的表现时好时坏，使得用户对其失望，会话效率低。而那时VoIP信令、声学和图像处理技能还是不多见的专业 “黑科技”。 十年前，也就
2019年1月29日，我们在FaceTime群聊中发现了一个严重漏洞。该漏洞使黑客能呼叫目标设备，且在没有与目标进行用户交互的情况下强制连接呼叫，这样一来，即使没有获得目标同意或目标毫不知情，黑客也能够监听其有关信息。该bug不仅运行机制奇特，造成的危害也较大。它能在没有获得代码执行的情况下强制目标设备向黑客设备传输音频，这样不寻常的漏洞前所未有。此外，该漏洞是FaceTime调用状态机中的一个逻
从依靠文字短信的延迟通信，到潜力无限的实时通信多媒体平台，我们在线通信协作这一领域的成就十分可观。 得益于谷歌及其开源平台WebRTC，我们可以在浏览器内使用HTML和纯JavaScript来开发像Skype、Whatsapp等视频聊天应用。 谷歌提及WebAssembly适配其最近Chrome的WebRTC音频管道以及未来WebRTC NV的建设。Low Level APIs说明了WebAsse
WebRTC在2020年逐渐开始解绑。随着差异化时代到来，这样的新举措似乎预示着WebRTC的终结。 WebRTC丰富了我们的生活。曾几何时，它是能在浏览器运行实时媒体的唯一方法。之后，其他同类服务层出不穷，但都没有正式发布。 现在，是WebRTC 1.0正式发行的时候了。 走向差异化 要用图表解释WebRTC的发展之路的话，看起来是这样子的： 2020年开启了WebRTC差异化阶段 从2019年
顾名思义，WebRTC即网络实时通信允许开发人员使用WebRTC为实时视频和数据传输提供支持。另外，Web意味着上述操作可以直接在主流Web浏览器中进行。 单击即可开启的视频通话是最常见的WebRTC应用程序。但其用例并不仅限于此。本文会为大家介绍本年度该技术的多种商业用途。 视频通话 我们都知道，视频聊天是WebRTC的立身之本。该框架已经在Slack、Google Hangouts、Faceb
因为疫情，我们暂时不能享受影院之夜。更雪上加霜的是，应为社交隔离服务的群体流技术表现并不尽如人意。 如今，类似Netflix Party和Scener等线上影院之夜的服务和应用程序层出不穷。而且很多做的都相当不错。但这些都不能代替朋友们聚在一起看电视的快乐体验。 好消息是，噩梦般的一年总会过去。分组流媒体可以、应该并且可能会变得更好。 考虑到六个月之前大家都不会想到如今需要分组流媒体播放，所以我们
首先，如果你还没有看过该系列文章的上篇，请移步这里。在下篇中我要讨论的是：为什么我认为音视频会议时长会解构，以及由此产生的大好机遇。 上篇文章的内容如图所示： 除此之外，我们还有一个棘手的问题需要解决。当然，你可以很快组建一个用户体验更好、功能更齐全的会议平台。但是无论你的屏幕共享效果如何，平台的音频和视频信令处理性能总归是一塌糊涂，你的客户会感到失望。做好信号处理需要专业人士和大量投资，但现在没
WebRTC 中文社区由
运营