WebRTC学习笔记_Demo收集
编辑：www.fx114.net
本篇文章主要介绍了"WebRTC学习笔记_Demo收集 "，主要涉及到WebRTC学习笔记_Demo收集 方面的内容，对于WebRTC学习笔记_Demo收集 感兴趣的同学可以参考一下。
本人最早接触WebRTC是在2011年底，那时Google已经在Android源代码中增加了webrtc源代码，放在/external/webrtc/，可是Android并没实用到它，更没有被浏览器使用。当时试图在Android
2.3（Gingerbread）高通平台的手机上用H.264&硬件codec替换掉WebRTC缺省使用的VP8软codec，费了不少劲勉强换掉后效果非常差仅仅得放弃。
近期得知Google最新版的Chrome for Android已经支持WebRTC，应老板的要求搭一个手机浏览器上视频通信的demo，为此在网上搜集各种资料，发现经过一年多的发展，国内外研究和使用WebRTC的人明显多起来，可用的demo也非常多。在此做一个笔记，留作日后參考。
眼下基于WebRTC的开发事实上有两个方向，一个是基于浏览器的WebRTC应用开发，编程语言主要是JavaScript、HTML等，这也是WebRTC作为HTML5标准的组成部分原本的目的；还有一个是C层面的移植和开发，作为一款非常强大的开源软件，非常多领域的软件项目都能够利用到WebRTC的音视频通信和处理能力，这些场合的应用程序可能是C语言写的，也不一定与浏览器有关。本文是属于前一种方向。
基本概念学习
WebRTC的官方资料能够从其官网和W
3C站点上看到。
学习WebRTC基础知识比較好的站点是《Getting Started with WebRTC》，网址是，这个也是官网上推荐的。
对浏览器来说，WebRTC事实上就是提供了3个API：
MediaStream (即getUserMedia)，用于获取媒体数据，比如来自摄像头和麦克风的视频流和音频流；
RTCPeerConnection，用于peer跟peer之间呼叫和建立连接以便传输音视频数据流；
RTCDataChannel，用于peer跟peer之间传输音视频之外的一般数据。
须要注意的是这几个API的名称在不同浏览器及同一浏览器的不同版本号之间略有差异，比方PeerConnection在FireFox上叫做mozRTCPeerConnection，而在当前版本号的Chrome上叫做webkitRTCPeerConnection，将来WebRTC标准化完毕后会把这些前缀去掉使用统一的名称。
眼下网上找到的WebRTC demo都仅仅用到了getUserMedia和RTCPeerConnection这两个API，还有一个API即RTCDataChannel似乎眼下还不太成熟。
WebRTC是实现peer to peer的实时通信（可以两个或多个peer之间），在可以通信前peer跟peer之间必须建立连接，这是RTCPeerConnection的任务，为此须要借助一个信令server（signaling
server）来进行，信令包含3种类型的信息：
Session control messages:&初始化和关闭通信，及报告错误；
Network configuration:&两方的IP地址和port号（局域网内部IP地址需转换为外部的IP地址）；
Media capabilities:&两方的浏览器支持使用何种codecs以及多高的视频分辨率。
WebRTC并未规定使用何种信令机制和消息协议，象SIP、XMPP、XHR、WebSocket这些技术都能够用作WebRTC的信令通信。
除了信令server，peer跟peer建立连接还须要借助还有一种server（称为STUN
server）实现NAT/Firewall穿越，由于非常多peer是处于私有局域网中，使用私有IP地址，必须转换为公有IP地址才干相互之间数据传输。这当中涉及到一些专业术语包含STUN、TURN、ICE等，详细的本人还有待学习。网上找到的WebRTC
demo好象都用的是Google提供的STUN server。
peer跟peer之间一旦建立连接就能够直接传输音视频数据流，并不须要借助第三方server中转。
WebRTC的目的是为了简化基于浏览器的实时数据通信的开发工作量，但实际应用编程还是有点复杂，尤其调用RTCPeerConnection必须对怎样建立连接、交换信令的流程和细节有较深入的理解。因此有高人为我们开发了WebRTC封装库，将WebRTC的调用细节封装起来，包装成更简单的API，使开发应用程序更简单。封装库的还有一个目的是为了屏蔽不同浏览器之间的差异，比如上面说的API名称的差异。当然，这些库都是开源的，能够依据自己的须要又一次改动。
眼下网上找到的有两种WebRTC封装库，一个是webrtc.io，网址是，上面有具体说明和用法，有非常多demo使用它；还有一个是SimpleWebRTC，网址是，貌似比webrtc.io用起来更简单。
网上能够找到一堆WebRTC demo，在上也能找到不少WebRTC应用项目的源代码。有些demo是直接调用WebRTC
API开发的，但大多数是调用上述两种WebRTC封装库开发的。因为WebRTC API的名称在不同浏览器及同一浏览器的不同版本号之间存在差异，所以不是全部demo都能执行在全部浏览器上。
为了找到一个可在公司局域网环境中跑在手机上的WebRTC demo，本人试用了不少demo，以下选几个有代表性的介绍，当中有两个经改动后已在本人公司的局域网环境中执行成功。
先说一下本人的測试环境：手机上的浏览器是Chrome for Android 26.0.1410.49，执行在Android
4.1.2上，这个Chrome版本号本身是beta版，支持WebRTC但缺省是关闭WebRTC功能的，须要在chrome://flags中使能WebRTC并重新启动Chrome，或者在启动Chrome时添加命令行选项--enable-webrtc。本人在PC上执行WebRTC的浏览器是Chrome
26.0.1410.43，操作系统是Windows 7。
这是官方的demo，功能非常全，可惜不知为何这个网址已经连不上了，只是其源代码还是能够下载到的，在。此demo没实用不论什么封装库。
这个demo所使用的信令机制使用了XHR和Google
App Engine Channel API&，详细我不懂。
在我的公司局域网环境里无法执行该demo。
据说是第一个基于浏览器的WebRTC视频通信demo，爱立信为此还开发了一个浏览器用于支持WebRTC，好象也是基于WebKit的，叫做Bowser
browser（当时市场上可能还没有支持WebRTC的浏览器），该项目网址是。这个Bowser
browser好象仅仅支持Ubuntu 11.04 and 11.10（见）。
该demo的网址是。
在我的公司局域网环境里无法执行该demo。
利用WebRTC的getUserMedia从摄像头获取图像进行人脸识别的demo，比如这两个：
这两个demo在PC和手机上的Chrome上都可执行。
这个demo演示HTML, CSS and JavaScript的各种feature和用法，包含WebRTC的3个API：getUserMedia、RTCPeerConnection、RTCDataChannel的演示，但遗憾的是RTCPeerConnection的演示仅仅是本地camera的画面传回给本地，并没有实现真正的设备之间音视频通信。
该项目的源代码在。
这是一个基于WebRTC实现屏幕共享（screensharing）的Chrome扩展，源代码在，有关介绍可參考这篇文章：。
本人没有试用过。
这个demo是基于库webrtc.io实现的，是webrtc.io官方的demo，使用WebSocket作为信令手段。
在我的公司局域网环境里无法执行该demo；在家里无线路由器环境下可成功执行，但仅仅能单向传输视频。
国内牛人做的，相当于是汉化版的，自然也是基于webrtc.io实现的，但使用的webrtc.io版本号较老，不支持新版本号Chrome所使用的API名称webkitRTCPeerConnection，所以无法在新版本号Chrome上执行。详细介绍在。
这个demo是基于库SimpleWebRTC实现的，是SimpleWebRTC官方的demo，使用WebSocket作为信令手段。
在我的公司局域网环境里无法执行该demo；在家里无线路由器环境下可成功执行，且可双向传视频，支持多个peer同一时候视频通信。
经改动后在本人公司局域网成功执行，试过两个手机和一个笔记本电脑同一时候视频通信OK。改动和执行步骤：
1.&从http://www.nodejs.org/download/下载nodejs最新版并安装，我是在Windows7
64位上安装的；
2.&在命令行下依次执行例如以下命令（安装执行signaling
server所需的模块）：
npm install express
npm install yetify
npm install getconfig
npm install node-uuid
npm install socket.io
3.&从/andyet/signalmaster下载信令server源代码，该信令server是SimpleWebRTC缺省使用的，解开该源代码后执行node
server.js，该服务器监听8888port，通过WebSocket与浏览器通信。
4.&在同一台PC上执行apache
server，将从上（可在Chrome浏览器中打开然后鼠标右键单击在菜单中选“另存为”、“网页，所有”就可以），改动当中的&index.html&和&simplewebrtc.js，将当中&url&改为'http://10.100.156.83:8888'（当中IP地址是我的PC在公司局域网中的IP地址）。
5.&在同一局域网中的其它设备上打开Chrome浏览器，地址栏输入，输入同样的room名称（随便起）就可以開始多方视频通信，也可改动上述index.html中的“var
room”一行，设定为固定的room名称，就不须要每次在每一个设备上手工输入room名称了。
这个demo是国内牛人赵书剑开发的视频聊天室，基于webrtc.io实现。
该项目源代码和文档下载地址是，源代码在。
经改动后在本人公司局域网成功执行，试过两个手机和一个笔记本电脑同一时候视频通信OK。改动和执行步骤：
1.&从下载webrtc.chatdemo.zip，解压缩，改动当中public\javascripts\client.js中的rtc.connect一行，将实际的server地址写进去，比如改为：rtc.connect(&ws://10.100.156.83:8001&,
2.&同上文3.8节步骤1、2安装nodejs
3.&执行node
app.js，注意该demo本身已包括http server，不须要其它的比方apache
4.&在同一局域网中的其它设备上打开Chrome浏览器，地址栏输入，输入同样的room名称（随便起）就可以開始多方视频通信。
转自：.cn/s/blog_69a04cf.html
本人使用3.8在本地调试执行成功。
本文标题：
本页链接：heX：用HTML5和Node.JS开发桌面应用 | heX Blog
简介：，一个允许你采用前端技术（HTML，CSS，JavaScript）开发桌面应用软件的跨平台解决方案。是你开发桌面应用的一种新的选择，意在解决传统桌面应用开发中繁琐的UI和交互开发工作，使其变的简单而高效。特别适合重UI，重交互的桌面应用软件。
一、项目背景
近几年，移动应用和web2.0大行其道，相比之下，传统桌面应用程序开发显得相对冷清（包括该领域技术人才的后继力量），但在一些场景下，它依然有其不可替代的优势。探索中我们尝试了一种新的办法，并给它取名，将HTML5和Node.JS的技术优势，应用于桌面应用程序开发，使得工作变得简单而高效。
2012年前后，一位研发工程师（外号6哥，精通web前端和桌面应用开发），先后参与了两个传统桌面应用程序UI改版工作（和），任务是把软件界面中部分区域的浏览器渲染引擎，由IE内核替换为webkit，在这个过程中，有一种强烈的欲望：把整个软件界面的渲染都交由浏览器引擎来完成，这样一来，UI和交互部分都可以用前端技术来实现，那么，开发过程将变的简单许多，而客户端开发人员的主要精力也可放在业务逻辑上，何乐而不为！
为此，我们做了大量的调研，经反复尝试，最终确定通过整合Chromium和Node.JS，来解决桌面应用开发中遇到的大量繁琐的UI和交互开发工作。期间，发现一款类似的开源项目node-webkit，调研的结论是它暂时还无法用于正式的项目，所以，于2012年6月，我们正式成立一人开发小组（确实够小），经3个月的努力，终有小成，现已经应用于有道词典最新版。
简要介绍下选择Chromium和Node.JS的原因，同时，也在这里对他们表示感谢。
选择Chromium，是因为它对HTML5的支持非常优秀，其内嵌的V8引擎，更是业内效率最好的JavaScript脚本引擎之一，且其项目开源，又有专门的社区和团队维护，作为UI渲染引擎，它是不二之选，体验上，你可以试用下google chrome浏览器，基本一致。
选择Node.JS，是因为开发桌面应用，本地资源操作是必备的能力，这方面JavaScript无能为力，而Node.JS则很好的解决了这个问题，它使得JavaScript操作本地资源变的毫无障碍。另一方面，Node.JS核心也是采用V8引擎，使得其与Chromium的整合变得更顺理成章。
二、用heX开发桌面应用的优势
HTML5这几年很火，在成熟产品中的应用却极少，受各浏览器和平台的软/硬件性能问题的限制，整体感觉总是难以舒展（用的不踏实），具体原因网上可以找到一大堆，这里列举一个移动web app相关的，中英对照版，推荐抽空看一看:
尽管如此，HTML5的优势依然很明显，普及程度也正逐年提高，我们对它的未来信心十足。好东西，都值得我们主动去尝试，heX做的一个事情，就是提前把它应用于桌面应用开发，而不用顾忌它的兼容性和平台性能问题（）。
用HTML5开发桌面应用，到底有什么样的优势呢？这里列举几项：
精准还原UI设计。现在客户端软件UI设计用native方式来实现的成本越来越高，对HTML5来说却很容易，对后续的维护也非常的友好；
用户体验。如果你不清楚HTML5所能做到的体验效果，可以看看Chrome Experiments（）；
开发调试便利。heX保留了开发者工具（Chrome Developer Tools），让你在开发调试过程中，就如同web开发一样便利；
学习成本。相比传统桌面应用开发，web技术的入门成本明显偏低，你不用担心团队成员的离开，而苦于寻找后续开发力量。
桌面应用开发，本地资源操作能力必不可少，Node.JS提供了丰富的自带API，让你免于逐个封装C++实现，就能在heX环境下的html页面中直接使用，如：本地文件系统操作，二进制数据处理，方便的创建子进程等等，详见。
在桌面应用开发中用Node.JS的好处（一部分来自于heX的努力）：
直接用JavaScript对本地资源进行操作，相比C/C++，你无需编译，即写即用；
页面交互逻辑，窗体行为操作，与C++通信，用JavaScript都能搞定，开发一个桌面应用，你无需在语言之间来回切换；
Node.JS丰富的第三扩展，你都可以直接使用，无需从零开始；
继承于Node.JS优秀的扩展能力，以及它所遵循的规范，代码管理也将变的方便和易于控制。
从技术角度来讲，选择一个新生事物，我们持谨慎态度，需要经过充分的调研，考虑的因素众多，比如：性能，用户体验，开发效率，是否有团队在维护，文档是否完备，是否开源（如果是商业用处，还需考虑它的开源协议）等等。
而heX作为桌面应用开发的一种新的选择，它在这些方面的表现如何呢？前面已经讲到一些，这里再补充几点：
性能和体验，heX的基础由Chromium和Node.JS整合而成，整合后这两者的性能表现不受影响，体验方面，你可以参考google chrome浏览器，基本保持一致；
开发效率，如果你有过web前端开发经历，现在仅要求你支持最新版的chrome浏览器，你觉得如何？睡着了都能笑醒的事，heX做到了；
heX即将开源，请大家关注
一种东西，只能解决一方面的需求，heX亦非万能，亦有它适合的使用场景，最适合重UI、重交互的桌面应用，比如即将推出的新版有道词典（亿级桌面应用软件）beta版，就是采用heX作为其界面的解决方案。
三、如何用heX开始一个桌面应用程序
采用heX开发桌面应用程序，有两种方式：
直接基于heX做开发，针对web前端开发者，不要求桌面应用开发经验；
以模块形式引入到现在桌面工程中，针对传统桌面应用开发者，适合有一定历史的项目，或仅在界面中局部区域支持即可的项目。
不管采用哪种方式，开发过程都很简单，这里就第一种方式，从零开始，一起来制作一个 hello word，如下：
1、下载heX二进制包（），解压到本地，打开后目录结构如下图所示，其中“hexclient.exe”是主程序文件，双击即可运行heX，“manifest.json”是heX的配置文件，可配置入口文件，窗口初始大小、位置等信息
2、创建一个用于写hello word程序的测试目录“test”，同时在其中新建html、js文件，如下图所示
3、修改manifest.json文件，入口改为test/index.html，如下图所示
4、双击 hexclient.exe，运行，一秒后界面由“……”变为“Hello Word！”，如下图所示，到此为止，一个简单的桌面应用就搞定了
正式产品案例：目前已经应用于新版有道词典（亿级桌面客户端软件）beta版，下图的整个界面和交互都是基于heX实现，欢迎下载体验：
了解更多heX信息欢迎微博 或访问
本条目发布于。属于分类。作者是。一份 ruby web 进阶的名词和问题，欢迎补充 & 社区 & Ruby China
rack中间件
rake任务构建工具
sinatra framework
padrino framework（基于sinatra）
camping（非阻塞式，类似nodejs）
grape gem（用于构建api）
goliath（构建api的杀手级产品）（EventMachine）
SwaggerUI（api的ui界面）
devise（登录注册gem）
god gem（进程监控）
God vs. Monit（）
god vs monit vs supervisord（）
supervisord python的进程管理工具，配合nginx（supervisord的弊端）
压力测试工具siege和ab
passenger+apache/nginx(首选)
ansible，FPM打包成deb
markdown浏览器端解决方案：
markdown.min.js()
diaspora社交网站
关于测试：
docker（文章）
parallels tools（搭配vagrant，虚拟机与主机直接共享文件和剪贴板）
puppet（C/S架构集中配置管理系统）
chef（简化服务器配置）英文书籍：
mina（作用同Capistrano）
capistrano（）
Twitter如何在數千台伺服器上快速部署程式碼（BitTorrent）
curb适合json类通信的数据
mechanize适合少js和少iframe类页面的抓取
watir适合测试，虽然完全模拟浏览器行为，但是性能是个大问题
验证码：rtesseract
py的Scrapy（大名鼎鼎）
hadoop（java）海量数据处理，但不具有实时性。本质上是一个批处理系统（HDFS，mapreduce，hbase）google三大论文
hadoop应用案例（）例如处理千万级的六度人脉，即好友推荐；联通的电话记录和流量记录查询
storm（Clojure）实时处理模型，比如把Twitter上的热门话题发送到浏览器中，目前来看，优于S4
OpenStack（python）为建设公共云计算和私有云计算建立通用基础的开源项目。
1.Facebook（）
hhvm+WordPress（）
1.数据库读写分离
2.数据库主从架构
vines(ruby)
ejabberd(erlang)
openfire(java)
strophe.js（bosh）
集成架构:social stream（重点研究对象）
实时websocket
faye(node和ruby两个版本)
socket.io(nodejs websocket)
node-webkit（开发桌面应用,基于Chromium与NodeJS的应用程序运行器，）
webRPC(WebRTC实现了基于网页的视频会议，标准是WHATWG 协议)
对于实时通信（视频和音频），使用WebRTC会是更好的选择
sse协议（w3c html5标准），websocket的简化版，工作于http/https
ruby websocket server
em-websocket()
Websocket-Rails()
EventMachine(fast, simple event-processing library for Ruby programs)
纯java的websocket实现
websocket解析库（自己实现websocket服务器）
LibWebSockets（c）
WebSocket-Node（nodejs）
PyWebSocket（python）
ImageMagick
wkhtmltoimage（）适合建立全局网页快照
wkhtmltopdf
PhantomJS（适合建立全局网页快照）
CasperJS（可以部分截屏）建议采用他，使用方便
slimerjs(据说字体支持比较好)
txt2img gem
imgkit（ 基于wkhtmltoimage，可搭配rails，可以使用css截图，不错的gem）
最后实现：rmagick+casperjs，效果类似
现在也可以考虑imgkit+rmagick，都是gem
thor（构建命令行接口的gem）
ElasticSearch（）
solr + sunspot（）
elasticsearch + tire
adminica（）
移动端js框架
quojs 各种手势事件
bulid jquery mobie app the easy way（）
富文本编辑器
pagedown+simditor
codemiror编辑器
nodejs其他应用
node-webkit（）
nodejs 论坛
nodebb（GPLv3）
nodejs博客ghost（MIT）
meteor（案例：telescope）
代码行统计工具：CLOC浏览器内核
fig(python)
泛域名解析()
Dokku 一个迷你版的Heroku
中国省市区（china-city）
fat_free_crm
odoo(python)
项目管理系统
邮件服务器
sendcloud(搜狐)
amazon ses
1.开发rails一直用bundle install，他是怎么工作的？
小测试：手动构建基于Gemfile的sinatra app
2.rake and rack你是否搞混？
小测试：基于config.ru部署1中的sinatra app(生产环境)
3.能否自己手动构建最佳实践？
最佳实践使用方便，但是对于新手却隐藏了太多细节，不妨试着用sinatra构建一个最佳实践。
小测试：基于sinatra构建最佳实践（可参考）
4.能开发gem了吗？
小测试：写一个简单的豆瓣api的gem（部分api即可）
官方文档：
我的渣渣翻译：
路还很长，欢迎补充。
第一个就被打出一个暴击，洒家没用过sinatra啊
哈哈，最近接触的也就只有这些了。他们都比较有名。
很喜欢这样的list。
不错，长见识了
后回复方可回复, 如果你还没有账号你可以
一个帐号。
共收到 5 条回复