由于p2p视频通讯不支持定向ip流量,
所以,做了一个基于mediasoup框架的sfu转发服务器和简单的web客户端(给安卓端和ios端提前踩坑)
涉及到的技术:
-
mediasoup(官网)
-
Nodejs
-
React
-
WebPackv
网络视频直播存在已有很长一段时间,随着移动上下行带宽提升及资费的下调,视频直播被赋予了更多娱乐和社交的属性,人们享受随时随地进行直播和观看,主播不满足于单向的直播,观众则更渴望互动,直播的打开时间和延迟变成了影响产品功能发展重要指标。那么,问题来了:如何实现低延迟、秒开的直播?
先来看看视频直播的5个关键的流程:录制->编码->网络传输->解码->播放,每个环节对于直播的延迟都会产生不同程度的影响。这里重点分析移动设备的情况。受限于技术的成熟度、硬件环境等,我们针对移动场景简单总结出直播延迟优化的4个点:网络、协议、编解码、移动终端,并将分四期来一一解密UCloud直播云实现低延迟、秒开的技术细节。
本文主要讲述UCloud直播云实现接入网络优化的技术细节。
投屏技术已经被大量用在身边的产品, 比如电视投屏, 投影仪, 视频会议产品中. 在iOS平台外的其他平台中都已经有非常成熟的标准和实现. 但在封闭的苹果iOS和Mac系统中, 苹果使用私有的Airplay协议进行多屏互动,
只开放给自己生态中的产品. 对此相关技术限制比较严格,甚至在iOS9中加上了更严格的加密算法, 直接导致很多投屏的产品不可用.
iOS中的投屏方案:
1, ReplayKit
iOS9中引入了ReplayKit, 让开发者有了一定的获取屏幕数据的能力. 并在iOS10和iOS11中继续扩展了ReplayKit的能力. 但还是有很大的限制, 比如在使用ReplayKit的api时只能录制当前应用的应用, 无法在应用进入后
台之后继续录屏. 如果使用系统级别的屏幕录制,又无法获得每一帧的数据,只能获得最后录取的单个视频. 这样对第三方的开发有了非常大的限制.
2, Airplay
Airplay是苹果提供的一种多屏互动技术, 可以将音频照片,视频, 屏幕从iOS设备或者Mac电脑上投射到支持airplay接受的设备上,如Apple TV。这样可以将小屏映射到大屏,可以无线音乐,可以图片分享等等.
但是Airplay属于苹果私有协议方案,设备间的协商与传输过程都进行了加密处理,并不能用于其他平台中。我们已经完整的逆向了Airplay的全部协议栈,并破解了其加密方案,可以提供跨平台Airplay接收方案。
这样可以方便实现跨平台的多屏共享。
同时,通过研究,我们也可以通过Airplay Mirroring技术,做到在iPhone上把自己的屏幕的内容投送给当前iPhone,在某些情况下这种airplay的破解却非常有用处,比如手游直播。
这中投屏方案使用了iOS原生的投屏能力,并且是完全的软件方案,非常方便进行集成和使用。
下面将介绍Airplay Mirroring接收端的实现原理,并揭示相关协议交互过程。
硬件方案——娃娃机整机、摄像头和硬件板子等。
软件方案——用户终端的抓娃娃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毫秒。