服务器接收到‘’准备好了‘’的信息并通过发送同样信息通知第一个参与者。这就开始了被称作发信的交换信息过程，因此我们需要添加相应的handlers到client.js文件中。 当第一个参与者接收到准备好了的信息时，它的反馈创建了一个RTCPeerConnection对象，设置对象的onicecandidate和onaddstream listeners为相应的onIceCandidate和onAdd
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
原作者：Lasse Lumiaho，Varun Singh（原文链接） 翻译：刘通 根据科技博物馆的近期研究所示，人类大约在100,000年前就具备了语言交流的能力。千百年间，通讯的媒介随着社会的发展壮大而不断改变。例如，人类用过陶板，纸张记录，演讲，演绎，烽火，击鼓，绘画来作为通讯的媒介，而现今在互
Philipp Hancke 又来死磕数据了。。。这次我们来探讨一下从调用getUserMedia到成功回调之间的时间。为什么这点这么重要值得单独拿出来讨论呢？绝大多数情况中这是用户与WebRTC所进行的第一次交互行为。而且就像我之前的同时Lynn Fisher在一篇超精彩的博客中所写到的那样，“为用户做好这次交互的准备是十分重要
Paul Sawers Skype在7月13号公布了全新的Linux版本，这项微软拥有的VoIP应用正在其他平台上追逐其他竞争对手。 现在Linux上app的用户总是抱怨Linux上的软件要落后于Windows和Mac上的版本。缺少更新和不可靠这点是大家共同的抱怨之处—最新一次更新还是在两年多前—所以7月13号的更新会得到期待已久的用户们的迎接。 在最新的Li
Amir Zmora 加快了H.264和DTLS的认证速度 Chrome 52 beta的更新日志中写道此次更新修复了超过30个bug，并且在Chrome中支持H.264，以及改变了DTLS默认认证生成算法以获得更好的私密性和更出色的表现。这个版本会在7月26号那天发布给你的浏览器。 浏览器支持WebRTC H.264是IETF所要求的，并且对浏览器的互操作性以及和传统视频系统的连接性都十分的重要
延时在很多的视频直播应用软件中都是一项十分重要的特征。 任何一类视频通信应用软件，像会议、辩论、竞标、直播、医学会诊，或者娱乐圈人士可以跟粉丝互动的应用，都要求延时一定要低。 什么是延时？ 延时是接收到视频帧到播放此帧之间的时间差。 对于网络流应用来说，延时可以来源于任何工作流程，比如摄像头/编码器，上游网络，流服务器，下游网络，或者观看者的视频播放器都可以产生延时。 通常延时都是在缓存视频帧的时
WebRTC 中文社区由
运营