作者：Adam Ullman（原文链接） 翻译：刘通 最近Snapchat首次公开募股，我就想到了如果使用WebRTC自己建一个跟Snapchat差不多的应用肯定是一件特别有意思的事情。好消息是感谢现在浏览器（Firefox和Chrome）的一些新的特性，我们完全可以自己写一个自己的“Snapchat”。 在这个网页上可以看到我的demo，http://aullman.github.io/snapchat-killer. 你也可以在这里看到源代码，https://github.com/aullman/snapchat-killer。 特点 首先让我们来看看这个像Snapchat的应用有什么特点？在我的应用中，我希望你能够： 1 拍摄快照（点击拍摄按钮） 2 录制小视频（持续按住拍摄按钮） 3
原作者：Chris Kranky（原文链接） 翻译：刘通 有很多人都问过我有关4K视频和WebRTC的问题。各种设备和服务的供应商都在吹嘘和兜售他们可以支持4K视频。但是现在让我来组织这种疯狂的想法。 WebRTC支持4K视频吗？简单的回答，是的WebRTC支持4K视频（至少Chrome电脑版支持GetUserMedia的4K视频请求）。但是实现起来现实吗？答案是否定的。 4K视频的分辨率是4096 x 2160（或者3840 x 2160）。如果你想要推一个4K的视频流的话，你需要至少有15Mbps的网速，如果想要达到30fps的帧速那么网速最好达到20Mbps。对于一个视频会议来说，你的网络连接需要以上述的网速，进行双方的长时间长举例通信传输。如果是多方会议的话，对网络的要求会更
原文链接 翻译：刘通 摘要 网页实时通信技术（简称WebRTC）是目前网页应用技术的一大发展趋势，WebRTC承诺不需要安装任何形式的插件或者程序就可以让浏览器获得进行实时通信的能力。但是，其开源的特点可能会造成潜在的安全隐患。此篇论文将要细节地对WebRTC的安全性展开讨论。 1 引言 WebRTC是一项开源的基于网页的应用技术，其允许用户在不安装任何插件的情况下就可以发送实时媒体流。使用适当的浏览器就可以简单地通过相关网页给另一方拨打网络电话。 下面列举了一下WebRTC的主要应用方向： # 实时音视频通话 # 网络会议 # 直接数据传输 与大多数实时系统（比如SIP）
作者：Anatoli Davidson（原文链接） 翻译：刘通 M57 WebRTC技术M57分支。 概述 WebRTC M57，目前已经登录Chrome测试版中，并且Android和iOS本地库已经包括超过40种新的功能，超过60个bug被修复，以及各种稳定性和其他方面的改进。正如之前的几个版本，我们建议开发者运行各个版本的Chrome，并且及时上报遇到的问题。请大家阅读这个网页，其中有链接将你引导到不同的bug上传页面。任何反馈对我们来说都是十分重要的。 各个版本的Chrome发布日期可以在这里看到。 重要的声明 默认RTCRtpMuxPolicy现在是“强制” &nb
如何使用getUserMedia()接入用户输入设备的简单教程 作者：Sebastian Patron（原文链接） 翻译：刘通 很多年来，通过浏览器的低层接入只能够通过复杂的flash软件或者Java程序来完成。随着flash和Java小程序的渐渐没落，我们需要一个新的解决办法来接入用户电脑的低层部分。这个新方法就是WebRTC，一个允许很简单地接入用户输入设备并且产生点对点连接的JavaScript框架。 WebRTC因为简化了浏览器之间的点到点连接而与众不同。这点对发送信息，视频聊天，甚至是文件分享软件都十分有用。为了做到这点，WebRTC包括了一系列的协议和api来简便的开展实时通信。我们在这篇文章中想做到的是，使用getUserMedia API来十分容易的获取用户的内置摄像头，为我们的自拍软件捕捉图像。 WebRTC的限制 &nbs
作者：Chris Ward（原文链接） 翻译：刘通 我最近在我们最新的视频会议应用Locus中加入了屏幕共享功能。为了实现这项功能，我在网上找了很多有用的资源，但是很散乱，很多都是过时的文章。在这里我想要把近期的内容总结一下，希望能够帮助到后来的开发者。我不想自称为专家，有可能有比我这种更好的方法来实现这项功能，但是下面写的内容对我来说是有用的。 访问视频捕捉流 Chrome和Firefox目前都在其电脑版浏览器中内置了屏幕捕捉功能。据我所知，移动端并不支持屏幕共享（手机可以接收共享的屏幕内容）。在这两个浏览器中，屏幕捕捉是通过MediaDevices.getUserMedia() （gUM）借口来实现的。gUM可以被调用来获得用户的音频/视频流，二次调用可以获得屏幕流。不好的一点是这个过程在不同浏览器之间的细节是不一样
原作者：Levent-Levi（原文链接） 翻译：刘通 为了确保这篇文章所写内容尽可能的准确，我决定请来Philipp Hancke来作为此篇文章的共同作者。 当你想要找到你WebRTC产品中的问题时，webrtc-internals是一个非常棒的工具，因为你需要用它测试WebRTC以及debug，或者你需要对你的配置进行微调。 如何获得webrtc-internals的数据转储（stats dump）？ 如果你对这个工具不熟悉的话，那么打开你Chrome浏览器里的WebRTC段，在这段里打开另一个表单并且将其指向这个内部（internal）URL：chrome://webrtc-internals/ &nbs
原作者：Cold Brew（原文链接） 翻译：刘通 一步一步指导如何搭建你的第一个WebRTC数据通道服务。 当我们初次接触WebRTC的时候，由于缺少合适的资源和资料，所以入门的门槛非常非常高。所有内容不是太复杂了，就是基于过于简单的WebRTC框架，或者就是太精密了以至于我们之前所学的东西在搭建实际工程的时候都用不上。 作为现在最令人激动的科技之一，这些缺点都是WebRTC难以启齿的地方。我们相信这项技术的价值是被低估了的，部分原因是对于开发者来说想要用WebRTC搭建任何一个有实际意义的工程都是十分困难的。 本文的目的是揭开WebRTC软件开发的神秘面纱。我们希望当你仔细读完整片文章之后，你会对WebRTC有一个整体的认识，也会知道如何开发一个端到端通信的应用。
Salvatore Loreto, Simon Pietro Romano 信令 自从WebRTC出现以来，就有一个在WebRTC设计的中心思想就得到了充分的指定，如何在尽可能保持信令平面留在应用层的前提下控制媒体平面。基本原理是不同的应用会倾向使用不同的标准信令协议（比如SIP或者XMPP）或者甚至使用一些定制的东西。在这种方法中，浏览器间必须交换的重要信息是多媒体会话描述，其指定了传输（以及交互式连通性建立[ICE]）信息和媒体种类，格式，以及建立媒体通道需要的所有相关媒体配置参数。 以会话描述协议（SDP）“大物件”的形式交换会话描述信息的这种最初想法有着很多缺点，其中一些会很难寻址。因此，IETF任务组正在进行JavaScript会话建立协议的标准化工作。JSEP提供了一个应用所需要的接口来处理的协商本地与远端会话描述，与应用和ICE状态机互动的标准化方法一起。JSEP把驱动信令状态机的任务完全交给了应用。不是简单的转发浏览器发射给远端的信息，应用必须在正确的时间调用正确的API，并且转换会话描述和相关的ICE信息到它选择的信令协议中的已定义信息中去。
WebRTC 中文社区由
运营