在Eede之后，Chrome是第二个通过navigator.getDisplayMedia()添加符合标准的屏幕捕捉的浏览器。 Chrome70的简介在八月宣布，并在十月的discuss-webrtc Google group中确认下来。 这个特点目前设置在一个标示下，你需要更新到Chrome70，然后进入chrome://flags/开启网络试验平台。 之后仿照本文范例你就可以在Chrome扩展
WebRTC是一个协议，允许人们使用JavaScript在两点之间创建实时通讯。 我们可以用这个结构使两个或更多浏览器之间实现直接交流，而不需要中心服务器。 服务器只需要在连接的时候被使用，因此每个客户端知道如何连接彼此。 我们可以使用这个特性创建什么类型的App呢？例如，直接网络摄像头连接。点对点通话，文件共享，还有更多。 本教程我会介绍一个当你第一次使用的时候，会发出惊呼的App
部署WebRTC的媒体服务器有两个主要挑战，从一台服务器开始扩展，并且优化参加会议的用户的媒体延迟。尽管简单的碎片化方法像‘将X会议中的所有用户发送到服务器Y’容易实现水平扩展，在用户体验中，媒体延迟是一个关键因素，在这方面，此方法还远远不能达到最优效果。 将视频会议分布在距离用户很近的许多服务器上并且保持相互连接，同时解决了两个问题。来自Jitsi团队的Boris Grozev深度描述了级联SF
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通话，你可能会以SFU结束。计划如何分配容量比较困难-通常会进行估计，SFU应该放在哪里，它们将会消耗多少带宽，你需要何种服务器。 为了帮助网络架构和WebRTC工程师作出决定，Alex博士和他的CoSMo Softwae团队将负载测试元件放在一起来测量负载和视频质量。他们公布了所有主流的开源WebRTC SFU的测试结果。这个元件基于KITE并且在webrtc.or
WebRTC vs Zoom? WebRTC很不错， 但是你早就知道了,不是么？ 我们不止一次被告知这个视频会议供应商或者那个供应商很不错。它们提供最好的画质，最好的体验。它们的视频会议效果可以比别人更好。 我甚至曾经接到了一个公司的电话，向我解释他是如何提供一个比Skype或者Google Hangouts更好的1对1视频质量。它们使用WebRTC实现。 但是我偏离话题了。 就像其他人一样，我被
八月以来，Reuters报道了FBI和Facebook之间关于窃听Messenger通话的秘密合法斗争。The verge网站在2015年关于Messenger逆向工程的文章中经过分析发现了一系列的问题。很难找到与此相关的技术信息，因此我无法深入交流关于窃听的具体细节。 Reuters现在宣布Facebook不再被强制监听Messenger通话，并且FBI声明：目前没有实际的方法可令
最佳实践1：选择一个视频方案，可以监测视频质量并且调整带宽。 当视频会议超出可获得带宽上限后，将会导致画面中断，低画质，视频音频不同步等等问题，并且伴随有丢包现象，这将会影响视频会议的质量。这就是为什么你需要选择一个可以监测通话质量和对丢包现象，网络拥堵，延迟等等可以做出相应调整的系统。 第一步，当网络状况变坏时，许多视频会议系统将会降低帧数。这是一个好办法并且通常可以维持视频会议的
WebRTC 中文社区由
运营