即构科技在线抓娃娃H5方案剖析
硬件方案——娃娃机整机、摄像头和硬件板子等。
软件方案——用户终端的抓娃娃H5源码、娃娃机摄像头推流方案、娃娃机天车控制方案、实时视频传输网络、实时信令控制网络和内容分发网络等。
图1、图2分别是即构科技在线抓娃娃H5方案的抓娃娃模式和围观模式的系统架构图。

作者:ZEGO即构
链接:https://www.jianshu.com/p/476ac6c2efc8
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
硬件方案——娃娃机整机、摄像头和硬件板子等。
软件方案——用户终端的抓娃娃H5源码、娃娃机摄像头推流方案、娃娃机天车控制方案、实时视频传输网络、实时信令控制网络和内容分发网络等。
图1、图2分别是即构科技在线抓娃娃H5方案的抓娃娃模式和围观模式的系统架构图。
原标题:Web-based voice command recognitions
上一次我们将音频buffer转成了图像,这一次,我们将采取这些图像,并使用deeplearn.js训练一个神经网络。结果是一个浏览器上的demo,你可以说出“yes”或者“no”的指令,然后像这样实时的显示出识别结果:
虽然它离完美还差的很远,但却是在网上进行各种音频识别的一个很好的起点。现在让我们深入了解一下这是如何工作的。
快速入门:培训和测试一个指令识别器
下面是如何训练yes/no分类器的方法:
1. 跳转到模型训练页。这会花一点时间来下载训练数据(yes/no)。
2. 点击训练按钮,你会看到一个显示训练进度的图表。一旦你准备好了(会花一点时间,具体时间长短取决于你的硬件),停止训练,并且点击保存权重(文件)按钮。这会下载一个JSON文件。
原标题:Computer Vision on the Web with WebRTC and TensorFlow
前文连接:利用WebRTC和TensorFlow通过网络实现计算机视觉1;利用WebRTC和TensorFlow通过网络实现计算机视觉2
第3部分——浏览器端
开始之前,请先在项目的根目录位置创建一个static目录。我们将从这里提供HTML和JavaScript。
现在,我们首先使用WebRTC的getUserMedia抓取一个本地摄像头Feed。从这里,我们需要将该Feed的快照发送到刚刚创建的对象检测Web API,获取结果,然后使用画布实时地在视频上显示这些结果。
HTML
我们先创建local.html文件:
当你入门 WebRTC 之后,很快就会接触到一个名词,叫做:SFU,你可能很容易就在网上寻找到很多 SFU 的开源实现,并并兴致勃勃地开始编译、部署和测试这些服务器,但是可曾想过,为啥我们的 WebRTC 应用需要 SFU 服务器 ?
1 WebRTC P2P 通话的网络模型
人类一直以来都在努力寻找与别人沟通的新方式,但即使我们不断获得进展,像共享文件这种至关重要的事情仍然非常繁琐。我们总是需要将文件上传到服务器上,然后再发回给我们以备后用。所以我们需要面对现实,文件传输并不像发送消息给对方那样简单,总会涉及到一些其他方面的问题。但是,由于WebRTC数据通道所提供的能力,这种情况正在发生变化。在本篇文章中,我希望通过一个简单的点对点连接来建立聊天以及建立基本的文件传输,为你提供一个更清晰的WebRTC数据通道工作方式。
近年来,超分辨率(简称超分)在图像增强、去噪、细节恢复、图像放大方面展现出广阔的应用前景,成为计算机视觉领域的研究热点,受到学术界和工业界的关注和重视,业界也纷纷举办超分竞赛,比如优酷的视频超分竞赛、声网的图像超分竞赛和深圳市政府举办的AI+4K HDR竞赛,旨在吸引更多的人参与超分算法的研究和促进超分算法的落地。因为超分算法的大规模应用落地还存在一些亟需解决的问题。
移动端实时超分的难点
目前,移动端实时音视频应用目前存在的一个痛点问题是传输的视频分辨偏低,而终端显示屏的分辨率高,存在分辨率不匹配的问题。实时传输的视频分辨率普遍偏低,是由于受到传输带宽的限制和实时性的要求。低分辨率视频不能有效的展现图像细节,因而带来的用户体验有限。为了解决传输视频与终端显示屏分辨率不匹配的问题,通常的做法是将低分辨率视频进行放大。
传统最常用的放大方法是插值法,如bicubic、nearest、bilinear等,优点是速度快,但缺点也很明显,即图像放大后,图像存在模糊、细节丢失的现象。
低延时、地卡顿、高音画质是直播技术方向追求的方向,webrtc属于业内良心开源项目,绝大多数连麦直播技术基于此项目,连麦技术架构有Mesh、MCU、SFU三种技术架构。三种技术架构优缺点各异,大家可以自行查阅。但是基于目前的直播状况,现在最合适的,也是使用比较多的是SFU架构。但是SFU架构除了客户端的webrtc需要完成,更重要的服务器也需要搭建。
此处使用到的WebRTC皆为H5的API,实际上调用的是封装在浏览器的WebRTC的库,用于获取实时视频数据,传输数据则是使用WebSocket实现。
其中的实例语法只用到原生JS,版本为ES6,可能需要较高版本的浏览器支持(IE一般不支持)。
1.获取音视频数据
方法:navigator.mediaDevices.getUserMedia
1.1前置条件
基于浏览器的安全策略,通过WebRTC(具体为getUserMedia)调用摄像头和麦克风获取音视频数据,只能是在HTTPS下的网页,或者是本地localhost下才能调用,需要先校验。
function validate(){
var isSecureOrigin = location.protocol === 'https:' ||
location.hostname === 'localhost';
if (!isSecureOrigin) {
alert('getUserMedia() must be run from a secure origin: HTTPS or localhost.' +'\n\nChanging protocol to HTTPS');
location.protocol = 'HTTPS';
1, 首先支持webrtc的chrome浏览器需要扩展插件,chrome官方提供的插件由于里面配置信息问题,无法使用,可下载经修改后的插件安装包http://download.csdn.net/download/yunjinwang/10167051。可参考https://github.com/webrtc/samples/tree/gh-pages/src/content/extensions/desktopcapture;
2, 下载后,在chrome浏览器中加载此插件,“设置”->更多工具->扩展程序,在页面选中“开发者模式”,点击“加载已解压的扩展程序”,浏览到前面下载的插件解压后的目录最后一层desktopCapture_chrome_plugin,确定加载后就在“扩展程序”下面看到已加载screenCapturing插件,至此,插件安装完成;
技术上来说,从IP摄像头实现在线广播并不需要WebRTC。IP摄像头本身就是服务器,可以自行连接路由器并传输视频内容。既然这样,我们为什么还需要WebRTC?
有两个原因:
1.随着观看以太网广播的观众增加,他们会逐步感受到带宽的不足,然后是摄像头资源,如果观众持续增加的话;
2.如上面提到的,一个IP摄像头就是一个服务器。但是它使用什么协议传输视频到浏览器或者移动设备?一个使用HTTP的摄像头很有可能基于HTTP传输视频帧或者JPEG图像。但是,HTTP流并不完全适用于实时视频传输。对于请求式视频,它确实工作良好,但是仅限于互动性和延迟要求不高的场合。确实,如果你在线观看一部电影,延迟5-10秒确实不太重要。好吧,除非你在和其他人同时观看:“oh,不,杰克谋杀了她!”爱丽丝给鲍勃发送信息10s之后,鲍勃才看到了这一幕悲剧。
另外一个选项是RTSP/RTP加上H.264。但是这种情况下浏览器需要安装一个视频播放插件,例如VLC或者QuickTime。这类插件将会接受并播放视频,就像播放器一样。但我们需要真实的基于浏览器的流,不需要任何附加的工具。
好,现在让我们“sniff”我们的IP摄像头,学习一下它到底向浏览器发送了什么。我们采用D-Link DCS 7010L来做测试:
你在下载的时候,有没有体验过 P2P 下载,能够让你的网速从 10KB 直接提升到 10MB? 你在企业内传输文件的时候,有没有体验过文件秒传? 你在看直播的时候,想不想用别人的流量看直播呢? ...
能做到上面这些场景的技术,叫做 P2P。P2P 技术中,最出名的叫做 WebRTC。WebRTC 是一个含金量非常高的技术。做好的话你可以养活一家公司,做不好,那就只能是一个 demo。
WebRTC 虽然能做很多事,但是并不是所有场景都适合。最大的使用场景是 两个终端在同一个 NAT 内,简单来说,都在一个 wifi 内。这个场景中,最显著的效果就是带宽无限并且高速,你走的就是内部的线路,根本不消耗运营商的流量。
P2P 技术在基于 WebRTC 标准下,可以做很多事情:
WebRTC网关服务器的上线意味着即构的音视频能力可以全面支持网页端视频互动场景。
作为实时音视频领域最火的开源技术,WebRTC 点对点的架构模式,无法支持大规模并发。如何在架构中引入服务端,一直是开发者关注的热点。5月20日,即构科技资深音视频架构师黄开宁在WebRTCon大会上带来了他的经验分享,以下是对他演讲内容的整理。
WebRTC 实现了多个 Web API 接口,其中三个重要的 Web API 分别是:
这里大致介绍一下这三个 API:
MediaStream API 为 WebRTC 提供了从设备的摄像头、话筒获取视频、音频流数据的功能.
对于实时通讯来说WebRTC技术是一个革命性的存在,主要基于WebRTC开启软MCU的零客户端新时代,例如谷歌、英特尔、华为、微软、阿里、甲骨文、腾讯、奥科等国际巨头,投入都纷纷布局5G时代下的视频通信市场,本篇帖子,重点介绍英特尔在WebRTC方面的研发成果。
Google 的 Chrome 浏览器实验室展示了很多基于 HTML5 和 JavaScript 的创意实验项目,里面的例子都很独特,让人惊叹。我从未想过结合 HTML 和 JavaScript 能实现这么强大的效果。其中很多实验项目使用了前沿的 WebGL 技术,为了能体验到绚丽的效果,建议在最新的 Chrome 浏览器中浏览(部分 WebGL 实验项目需要显卡支持)。
webrtc的前世今生、编译方法、行业应用、最佳实践等技术与产业类的文章在网上卷帙浩繁,重复的内容我不再赘述。对我来讲,webrtc的概念可以有三个角度去解释:
(1).一个W3C和IETF制定的标准,约定了Web间实时音视频通信机制,通过该标准可开发基于浏览器的、无插件的web多媒体应用(一般是js),该标准仅设定了点对点无中心的实时会话场景,没有强制约束信令协议与内容,没有要求有媒体处理的中心服务器,主要目标是形成开发者与浏览器厂商良好的生态环境,并积极向HTML5靠拢争取被纳入进去;
(2).一群音视频算法和网络适应性算法,这些算法囊括了视频会议几乎所有的核心技术,包括音视频的采集、编解码、网络传输、播放显示、安全等功能,还提供了操作系统系统调用跨平台封装的实现,包含Windows,Linux,Mac,Android,iOS;
(3).一个开源工程,核心由c++实现,可通过修改、封装、提取代码等方式实现一套视频会议系统,客户端可实现为Web js、App或Windows应用程序等多种形式,服务端可实现包括业务外的所有服务,包括媒体服务、信令服务、穿墙服务、中继服务等等,这些服务稍微调整后可轻易支持分布式部署、容器部署、云部署等。
对webrtc的理解与使用,我认为有三个境界:
今天,我们很自豪地宣布我们最新的WebRTC创新:Mantis,一种用于WebRTC平台上的OpenTok的云扩展基础架构。
对于TokBox团队来说,这是向前迈出的又一大步,我们将继续追求为应用程序开发人员提供简单而强大的API的目标。API不仅利用最新标准来提供最佳体验,而且还具有可扩展的智能云作为后盾,该云支持跨各种端点的互操作性。
仅仅六个多月前,我们在WebRTC平台上启动了OpenTok。从那时起,我们一直在努力工作,不断在WebRTC的功能和性能上突破OpenTok的界限。我们推出了首个用于WebRTC的iOS SDK,引入了跨平台和设备支持,并通过跨平台TURN支持改善了连接性等等。
WebRTC上的适用于OpenTok的Mantis充当OpenTok云中所有WebRTC流的中央交换站。螳螂可以:
本次实验使用windows平台,其他平台如html5、android、ios、linux、mac等思路大同小异,上一篇文章已经提及,在此不再赘述。
最近在做WebRTC相关的移动端视频会议,看了一下相关文档和一些Demo,总结一下构建webRtc应用流程。
相关文档连接:
1.一篇不错的中文文档,好像网上好多demo都是基于这个的http://segmentfault.com/a/1190000000439103
2.htmlRock里也有一些Sample,http://www.html5rocks.com/en/tutorials/webrtc/basics/
通过这2篇文档的学习,基本就差不多了解了相关内容
一、基本介绍
自WebRTC编解码器战争以缓和告终以来,已经有几年时间了。H.264也已经存在了超过15年,因此很容易掩盖运用中的多种复杂问题。
|pipe| CTO Tim Panton正在研究一个无人机项目,他需要为WebRTC提供一个轻量级H.264堆栈,而他决定自己构建一个。这当然不是我推荐给大多数人的一个运用,但Tim表示,如果不是一个简单的运用,那么这可能是一种启发性的体验。在这篇文章中,Tim一步步地向我们展示了他在努力让视频播放时的发现。除了阅读H.264介绍的RFCs规范之外,还可以通过它获得一个有趣的替换方案!
编译WebRTC之Android版本(AppRTC工程编译)
前言
准备工作
下载源码
编译依赖库
总结
前言
最近有项目需要用到android与web互通音视频,甚至与原生windows互通,很久没编译过了,所以今天亲自编译一下,并记录下来。
Stun服务器
: 服务器用于获取设备的外部网络地址 Turn服务器
: 服务器是在点对点失败后用于通信中继 信令服务器
: 负责端到端的连接。两端在连接之初,需要交换信令,如sdp、candidate等,都是通过信令服务器 进行转发交换的。iOS
PC BroswerMediaStream
:通过MediaStream的API能够通过设备的摄像头及话筒获得视频、音频的同步流RTCPeerConnection
:RTCPeerConnection是WebRTC用于构建点对点之间稳定、高效的流传输的组件RTCDataChannel
:RTCDataChannel使得浏览器之间(点对点)建立一个高吞吐量、低延时的信道,用于传输任意数据。 其中RTCPeerConnection
是我们WebRTC的核心组件。作为开发者,我们需要有一个服务器来支持新视频行业的互联网化,有哪个开源方案能支持新爆发的业务?该方案需要支持哪些关键的能力或需求?本文由自阿里云RTC服务器团队负责人杨成立在LiveVideoStack线上分享的内容整理而成。
文 / 杨成立
整理 / LiveVideoStack
视频回放:
https://www2.tutormeetplus.com/v2/render/playback?mode=playback&token=7955f5f3e1c942fa9ae4314b991beb1c
大家好,我是来自阿里云的杨成立,本次分享将会和大家详细介绍开源流媒体服务器的关键技术及未来发展。
我从2009年开始从事FFmpeg流媒体相关工作,2012年开始参与流媒体服务器的开发,2013年开始做开源流媒体服务器SRS,至今也有七年多的时间了。在这短短几年间,随着视频直播的爆发,SRS也迎来了快速增长。2017年我来到阿里云之后换成了WebRTC方向。我们可以看到目前Live WebRTC在整个视频的应用非常广,包括在线办公、在线教育、在线娱乐等各个行业都大展拳脚,音视频已经成为当前互联网交流与信息传播不可或缺的媒介手段。
这次的分享内容将主要围绕SRS的诞生与历程、SRS接下来的发展计划等,带领大家深入研究SRS存在的价值与意义。
得益于我国通信基础设施的日趋完善,尤其是Wi-Fi、4G网络的下沉普及,我国互联网市场音视频产品服务在2015~2018年经历了爆发式增长。当时消费者普遍拥有的可以观看视频的带宽大约为1M,网络环境较为稳定。
直播背后的技术早在功能机时代就落地成熟。例如2010~2012年,消费者主要通过PC上的Flash来观看网络直播视频,因为Flash可以跨主流PC端浏览器。而移动端尽管也支持Flash,但效果很不好。移动端如Android或iOS则主要支持HLS,早期Android对HLS的支持效果并不佳,后面有明显改善。
webrtc的前世今生、编译方法、行业应用、最佳实践等技术与产业类的文章在网上卷帙浩繁,重复的内容我不再赘述。对我来讲,webrtc的概念可以有三个角度去解释:
(1).一个W3C和IETF制定的标准,约定了Web间实时音视频通信机制,通过该标准可开发基于浏览器的、无插件的web多媒体应用(一般是js),该标准仅设定了点对点无中心的实时会话场景,没有强制约束信令协议与内容,没有要求有媒体处理的中心服务器,主要目标是形成开发者与浏览器厂商良好的生态环境,并积极向HTML5靠拢争取被纳入进去;
(2).一群音视频算法和网络适应性算法,这些算法囊括了视频会议几乎所有的核心技术,包括音视频的采集、编解码、网络传输、播放显示、安全等功能,还提供了操作系统系统调用跨平台封装的实现,包含Windows,Linux,Mac,Android,iOS;
(3).一个开源工程,核心由c++实现,可通过修改、封装、提取代码等方式实现一套视频会议系统,客户端可实现为Web js、App或Windows应用程序等多种形式,服务端可实现包括业务外的所有服务,包括媒体服务、信令服务、穿墙服务、中继服务等等,这些服务稍微调整后可轻易支持分布式部署、容器部署、云部署等。
对webrtc的理解与使用,我认为有三个境界:
在最开始,我们在产品方面做出了用户可以感受到的改变,这让你与朋友玩游戏时,Discord非常适合你们之间的语音交流。这些决定让我们在资源有限并且团队比较小的情况下扩大了经营。
本文简要介绍了Discord使用的不同技术,来让视频音频交流达到接近现实的效果。
为了区分,我们将会使用guild来代表一组用户和频道-在客户端它们被称为servers. Server被用来描述我们的后端架构。
Discord中所有音频视频交流都是多方的。支持大规模组内交流需要客户端-服务器的网络架构因为当参与者人数增多时,点对点网络变得非常昂贵。
通过Discord servers发送你所有的数据同样确保在输入文本,声音或视频时你的IP地址不会被泄露,这防止了其他人找到你的IP地址并且创建DDoS来攻击你。通过媒体服务器发送具有其它优势,例如对于使人讨厌的参与者,管理员可以选择禁止他的音频视频交流。