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

作者:ZEGO即构
链接:https://www.jianshu.com/p/476ac6c2efc8
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
硬件方案——娃娃机整机、摄像头和硬件板子等。
软件方案——用户终端的抓娃娃H5源码、娃娃机摄像头推流方案、娃娃机天车控制方案、实时视频传输网络、实时信令控制网络和内容分发网络等。
图1、图2分别是即构科技在线抓娃娃H5方案的抓娃娃模式和围观模式的系统架构图。
本文以Linux/Mac平台为例,简单归纳总结WebRTC本地C++开发的基本步骤。
Google使用一个脚本工具集depot_tools进行代码检出、下载管理、代码审查、代码提交等日常开发工作[1]。该工具集中的常用工具包括gclient,gcl,git-cl,repo等等。在Linux/Mac平台上安装depot_tools工具集非常简单[2]:下载源代码并添加到PATH中即可:
git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
export PATH=`pwd`/depot_tools:"$PATH"
需要注意的是,我们要把depot_tools放在PATH的最前端,否则gcl命令会指向GNU Common Lisp编译器。另外,export这一句最好添加到.bashrc中,这样就不必每次都设置。
对于Ubuntu/Debian系统,除安装depot_tools工具集,还有另外一项先决条件:在获取WebRTC源代码后,需要运行源代码中的install-build-deps.sh脚本安装一系列依赖软件:
网络拥塞是基于IP协议的数据报交换网络中常见的一种网络传输问题,它对网络传输的质量有严重的影响, 网络拥塞是导致网络吞吐降低, 网络丢包等的主要原因之一, 这些问题使得上层应用无法有效的利用网络带宽获得高质量的网络传输效果。特别是在通信领域, 网络拥塞导致的丢包, 延迟, 抖动等问题, 严重的影响了通信质量, 如果不能很好的解决这些问题, 一个通信产品就无法在现实环境中正常使用。 在这方面WebRTC中的网络拥塞控制算法给我们提供了一个可供参考的实现,这篇小文会尽量详细的介绍WebRTC中的拥塞控制算法---GCC的实现方式。
●●●
WebRTC简介
WebRTC是一个Web端的实时通信解决方案, 它可以做到在不借助外部插件的情况下, 在浏览器中实现点对点的实时通信。 WebRTC已经由W3C和IETF标准化,最早推出和支持这项技术的浏览器是Chrome, 其他主流浏览器也正在陆续支持。Chrome中集成的WebRTC代码已全部开源, 同时Chrome提供了一套LibWebRTC的代码库, 使得这套RTC架构可以移植到其他APP当中,提供实时通信功能。
rfc5766-turn-server是谷歌推荐的turn开源项目,经常作WebRTC的服务器端使用。 该开源项目是包含TURN与STUN功能于一体,默认TURN与STUN监听端口为3478。
支持tcp, udp, tls, dtls 连接.tls为基于TCP的安全层传输协议,dtls为基于udp的安全传输层协议。
注意:TLS和DTLS需要安装证书。
在 RTC 2019 第五届实时互联网大会的编解码技术专场上,声网开源了自研抗丢包音频编解码器Agora SOLO。
目前,编解码器的源代码已经开源在 Github 上:https://github.com/AgoraIO-Community/Solo
这个开源项目兼容 WebRTC,可集成于多种场景下的实时音视频应用中,比如在线课堂、直播社交、游戏语音开黑、IoT 等。在分析它的特性之前,首先要讲一下它名字中的一个关键词,丢包。
尽管很多人开始使用 WebRTC 了,但是其中有不少人都对「丢包」的概念不是很熟悉。所以,首先我们要解释一下。由于 SOLO 是音频编解码器,我们接下来讲的场景,主要是指其中的实时音频部分。
webrtc可以用于将一台机器上的桌面投射到另外一台机器上,通过浏览器实现桌面分享。然而其延迟时间是一个关键问题,即我们在源桌面上做一个操作,经过多长时间能够在目的桌面上看到。接下来,将根据查找到的资料对导致延迟的因素做简要介绍。
想了解更多可以查看:抖动和延迟之间的区别
以下是计算WebRTC呼叫总等待时间的关键因素:
(1)网络延时。取决于网络连接质量和通信距离(在一个国家内部应该小于50毫秒,国家之间可能大于100毫秒)。
(2)网络带宽和服务质量。丢包或者带宽不足可能触发更多的延时。
(3)声音延迟。取决于操作系统、音频硬件和驱动(在windows和ios上小于20毫秒,在android和linux上可能更多)。
(4)抖动缓冲。每种VoIP软件维持一个大小不一的抖动缓冲器,以补偿网络延迟(通常在0到100毫秒)。
(5)回声消除和前向纠错。回声消除和前向纠错可能引入一个数据包的延迟(通常在20毫秒)。
(6)其他因素。还有其他因素对延迟有影响,例如CPU占用率过高以及软件实现细节等。
如果通话双方在一个国家内部,总的延迟应当小于300毫秒,如果通过webrtc打长距离的跨国电话,总的延迟可能高达600毫秒。
如之前的总述文章所述,rtc::Thread类封装了WebRTC中线程的一般功能,比如设置线程名称,启动线程执行用户代码,线程的join,sleep,run,stop等方法;同时也提供了线程内部的消息循环,以及线程之间以同步、异步方式投递消息,同步方式在目标线程执行方法并返回结果等线程之间交互的方式;另外,每个线程均持有SocketServer类成员对象,该类实现了IO多路复用功能。
本文将针对rtc::Thread类所提供的基础线程功能来进行介绍,Thread类在rtc_base目录下的thread.h中声明,如下(删除了其他非线程基础功能的API,其他的API将于另外的文章中分析):
rtc:: Thread及其相关类,ThreadManager、MessageQueue,Runnable等等一起提供了如下的基础功能:
基于ios native api自己写客户端得出的大概流程,WebRTC的API接口和例子都是oc版本,因为我最讨厌最恶心的语言就是oc,所以我使用swift来编写客户端。我本身不是搞ios开发的,以前稍微用过oc,至于swift前段时间看过一点,现学现卖,就是转换oc的过程实在是折磨死我了。
音视频客户端会话的整体流程
WebRTC主要是客户端技术,尽量使用p2p点对点流媒体传输。