移动端直播相关技术总结

一、直播APP原理

二、直播APP架构

三、直播APP实现流程

四、流媒体开发

流媒体模块架构

流媒体相关基础知识

帧：每一帧代表一幅静止的图像

GOP：Group of Pictures，画面组，一个GOP就是一组连续的画面，很多帧的集合

码率：比特率，单位时间内视频或音频的数据量

帧率：每秒显示的图片数量，帧率越大，画面越流畅。帧率大于16人眼就会认为是连贯的

压缩比：压缩前的码率/压缩后码率

视频文件格式：文件的后缀，.wmv、.mp4、.mov、.avi

视频封装格式：存储视频信息的容器，流式封装（TS、FLV）、索引式封装（MP4、MOV、AVI）

五、直播基础知识、原理

1．音视频采集

1.1 音视频采集编码框架

AVFoundation：用于处理音频、视频和图像的捕获、播放、编辑和导出等功能，提供一套强大的API接口来操作这些视听数据。

1.2 音视频硬件设备

CCD：图像传感器，用于图像采集和处理的过程，把图像转换成电信号。

拾音器：声音传感器，用于声音采集和处理的过程，把声音转换成电信号。

音频采样数据：一般为PCM格式。

视频采样数据：一般为YUV或RGB格式。（YUV 主要用于视频压缩和传输，通过减少色度分量的采样来实现较好的压缩效果；而 RGB 主要用于图像处理和显示，能够准确表示每个像素的颜色。）

2．视频处理（美颜，水印）

视频处理原理：视频是通过GPU，一帧一帧渲染到屏幕上的，所以我们可以利用OpenGL ES，对视频帧进行各种加工，从而视频各种不同的效果。美颜和视频添加特效可以利用GPUImage这个框架实现的。

GPUImage：GPUImage是一个基于OpenGL ES的一个强大的图像/视频处理框架，封装好了各种滤镜同时也可以编写自定义的滤镜。

OpenGL：Open Graphics Library是个定义了一个跨编程语言、跨平台的编程接口的规格，它用于二维、三维图象。OpenGL是个专业的图形程序接口，是一个功能强大，调用方便的底层图形库。

OpenGL ES：OpenGL for Embedded Systems是 OpenGL三维图形 API 的子集，针对手机、PDA和游戏主机等嵌入式设备而设计。

3．视频编码解码

3.1 视频编码框架

FFmpeg：是一个跨平台的开源视频框架，能实现视频编码、解码、转码、串流、播放等丰富

的功能。其几乎支持包含了所有音视频编解码、封装格式以及播放协议。

x264：开源的高性能视频编码器，把视频原数据YUV编码压缩成H.264格式。

VideoToolbox：苹果自带的视频硬编解码API，在iOS8之后才开放。

AudioToolbox：苹果自带的音频硬编解码API，在iOS8之后才开放。

3.2 视频编码技术

视频压缩编码标准：对视频进行压缩或者解压缩的编码技术，如MPEG、H.264。

主要作用：将视频像素数据压缩成为视频码流，从而降低视频的数据量。如果视频不经过压缩

编码的话，体积通常是非常大的，一部电影可能就要上百G的空间。

MPEG：它采用了帧间压缩，仅存储连续帧之间有差别的地方，从而达到较大的压缩比。

H.264/AVC：采用事先预测和与MPEG中的P-B帧一样的帧预测方法压缩，它可以根据需要产生适合网络情况传输的视频流，还有更高的压缩比，有更好的图像质量。

MPEG和H.264对比：如果是从单个画面清晰度比较，MPEG4有优势；从动作连贯性上的清晰度，H.264有优势；H.264的算法较复杂，需要更多的处理器和内存资源。

H.265/HEVC：基于H.264，保留原来的某些技术，同时对一些相关的技术加以改进，以改善码流、编码质量、延时和算法复杂度之间的关系，达到最优化设置。

H.265 是一种更为高效的编码标准，能够在同等画质效果下将内容的体积压缩得更小，传输时更快更省带宽。

H.264和H.265对比：H.265 相对于 H.264 在压缩效率和视频质量方面有较大的优势，尤其在高分辨率和大带宽环境下表现更为出色。然而，由于 H.265 存在处理复杂度和兼容性问题。

直播的数据，就是一组图片，包括I帧、P帧、B帧。

用户第一次观看的时候，播放器会到服务器寻找最近的I帧反馈给用户。

I帧：关键帧，保留一副完整的画面，解码时只需要本帧数据就可以完成。

P帧：差别帧，保留这一帧跟之前帧的差别，解码时需要用之前缓存的画面叠加上本帧定义的差别，生成最终画面。（P帧没有完整画面数据，只有与前一帧的画面差别的数据）

B帧：双向差别帧，保留的是本帧与前后帧的差别，解码B帧，不仅要取得之前的缓存画面，还要解码之后的画面，通过前后画面的与本帧数据的叠加取得最终的画面。B帧压缩率高，但是解码时更加消耗CPU。

帧内压缩：当压缩一帧图像时，仅考虑本帧的数据而不考虑相邻帧之间的冗余信息。帧内一般采用有损压缩算法。

帧间压缩：时间压缩，它通过比较时间轴上不同帧之间的数据进行压缩。帧间压缩一般是无损的。

muxing（合成）：将视频流、音频流甚至是字幕流封装到一个文件中（容器格式FLV、TS），作为一个信号进行传输。

3.3 音频编码技术

常见的音频编码格式：MP3、AAC、Speex、Opux等。

特点	MP3	AAC	Opus
压缩效率	中等	较高	非常高
音频质量	中等	较好	很好
支持比特率范围	较窄（中等、较高）	较窄（中等、较高）	广泛（低、中、高）
主要应用	音乐、广播等	各种音频应用	流媒体、视频会议
兼容性	非常高	高	相对较低

3.4 码率控制

多码率：观众所处的网络情况是非常复杂的，有可能是WiFi，有可能5G、4G、甚至3G，那么怎么满足多方需求呢？多定义几条线路，根据当前网络环境自定义码率。

例如：高清，标清，流畅等，指的就是各种码率。

3.5 视频封装格式

TS：一种流媒体封装格式，流媒体封装有一个好处，就是不需要加载索引再播放，大大减少了首次载入的延迟，如果片子比较长，mp4文件的索引相当大，影响用户体验。而且两个TS片段可以无缝拼接，播放器能连续播放。

FLV：一种流媒体封装格式，由于它形成的文件极小、加载速度极快，使得在线观看视频文件成为可能，因此FLV格式成为了当今主流视频格式。

4．推流

4.1 数据传输框架

librtmp：一个开源的 C 库，用于实现 RTMP协议的客户端功能，包括 RTMP 连接建立、握手过程、数据交互、音视频传输等。

4.2 流媒体数据传输协议

RTMP：Real-Time Messaging Protocol，实时消息传输协议，由Adobe公司开发，基于TCP

协议，用于对象、视频、音频的传输。

RTMP工作原理：

握手：客户端和服务器之间进行握手，以建立连接。握手过程中包括版本协商和密钥交换等步骤，确保双方能够正常通信。

建立流：客户端发送一个命令给服务器，请求建立一个流（Stream）。一个流可以包含一个或多个音视频轨道。

数据交互：客户端和服务器通过建立的流进行音视频数据的传输。RTMP 会将音视频数据分割成小的消息进行传输，每个消息包含一个时间戳和有效负载。

控制信息：RTMP 还支持发送控制信息，用于控制音视频的播放、暂停、快进等操作。这些控制信息被封装在特定的消息类型中，如 SetChunkSize、Play、Pause 等。

5．流媒体服务器

5.1 常用服务器

NGINX-RTMP：基于 Nginx 服务器的一个第三方模块，支持直播和点播。

Microsoft Azure Media Services：微软提供的云端流媒体解决方案。

腾讯云：云直播（Cloud Live）、点播（VOD）、直播连麦（RTC）。

5.2 数据分发

CDN：Content Delivery Network，内容分发网络，是一种分布式的网络架构，它将内容缓存到离用户最近的节点服务器上，可以帮助加速音视频内容的传输，减少加载时间，提高用户访问网站的响应速度和观看体验，另外CDN 还能分担源站点的负载压力，提高系统的可扩展性和稳定性。

CDN工作原理：代理服务器，相当于一个中介。例如：请求流媒体数据时

5.3 CDN链路

传统CND链路——树形网络拓扑：

Cache 系统是整个 CDN 系统中的成本所在，设计树形结构可以最大化的节省 Cache 系统的资本投入。因为只有中心节点需要保持所有的 Cache 副本，向下逐级减少，到了边缘节点只需要少量的热点 Cache 就可以命中大部分 CDN 访问请求，这样极大的降低了 CDN 网络的成本。

网状网络拓扑结构：

直播业务是流式业务，很少涉及到 Cache 系统，播完就可以释放掉存储资源，对于存储的投入相对非常低，而且不要求存储在所有节点中，只要保证数据可回溯即可。

用户的可选择链路变为：无向图的指定两点间的所有路径，数量非常大。

回源：当有用户访问某一个URL的时候，如果被解析到的那个CDN节点没有缓存响应的内容，或者是缓存已经到期，就会回源站去获取搜索。如果没有访问，那么CDN节点不会主动去源站拿。

带宽：在固定的时间可传输的数据总量，比如64位、800MHz的前端总线，它的数据传输率就等于64bit×800MHz÷8(Byte)=6.4GB/s。

QoS：带宽管理，限制每一个组群的带宽，让有限的带宽发挥最大的效用。

集群、分布式、负载均衡：由多台服务器以对称的方式组成一个服务器集合，每台服务器都具有等价的地位，都可以单独对外提供服务而无须其他服务器的辅助。通过某种负载分担技术，将外部发送来的请求均匀分配到对称结构中的某一台服务器上，而接收到请求的服务器独立地回应客户的请求。解决大量并发访问服务问题。

6．拉流

6.1 RTMP

1>RTMP协议

RTMP协议是基于TCP长连接，既可推流又可以拉流的协议，地址是rtmp://开头的，并且推流地址和播放地址是一样的，高并发下可能会出现一些不稳定的问题，所以一般只用作直播源推流、推流到CDN等场景。

2>RTMP强制切片

强制切片也一定程度上保证了实时性，有一定的弱网抵抗能力，因为每个数据包都不会太大，当数据包校验失败时，重新发送的成本不会太大，但合并数据包需要CPU的性能消耗。

6.2 HTTP-FLV

1>HTTP-FLV协议

HTTP-FLV协议基于HTTP长连接，可以看作是RTMP的HTTP版本，与RTMP的工作原理相似，延迟为1-3s，比RTMP协议延迟略高，HTTP-FLV协议一般只用作客户端拉流观看。

2>HTTP-FLV播放

3>HTTP-FLV流媒体播放器

4>流行的方案：

6.3 HLS

1>HLS协议

HLS基于HTTP短连接，一般只用于拉流观看，但严格地说HLS协议并不是流式协议，工作原理是通过HTTP协议下载静态文件，HLS协议的文件由两部分组成，一是多个几秒长度的ts碎片视频文件，另一个是记录这些视频文件地址的m3u8索引文件，这些静态文件都是直接写入磁盘的。

HLS观看地址是以https://开头.m3u8结尾的，实际上这个地址就是索引文件地址，客户端获取到索引文件后，就可以下载对应的碎片视频并开始播放了，由于HLS协议实际上是通过HTTP协议请求文件的，且HLS相关文件是直接写入磁盘的，所以不需要特殊的流媒体服务软件，使用Nginx的HTTP服务就可以了，网页加入HLS的js插件就可以播放了。

苹果设备是原生支持HLS协议的，点播的情况，也就是普通网络视频观看的场景下，m3u8索引文件会记录所有的碎片视频文件地址。

2>点播场景

HLS在点播的情况下优势更加明显，由于HLS的相关文件是无状态的静态文件，且每个文件的大小是有限的，所以负载均衡、CDN加速的效果更佳明显，HLS的点播视频会比mp4、FLV的视频更快的播放出来，并且在加载中跳转视频也会更佳顺滑。

3>直播场景

直播的场景下，转码软件可以直接生成HLS相关文件到磁盘，客户端通过HTTP服务下载文件即可；另外可以在Nginx加入RTMP插件，转码软件以及RTMP协议推流到Nginx，再由Nginx生成HLS相关文件，第2种方案对于前期研发和后期对接直播CND的过度更加顺滑。

4>直播的HLS文件

直播场景下的HLS文件与点播有些不同，视频流数据每几秒会打包成一个以ts为后缀的碎片视频文件，每生成一个新的视频文件都会同步更新m3u8索引文件，且碎片视频文件的个数是有上限的，当达到上限后，默认将最旧的视频文件删除且更新m3u8索引文件所以在直播的场景下，客户端也需要不断定时重新获取m3u8索引文件。

5>HLS协议的优缺点

HLS由于要生成静态文件，延迟很大5-30s，也可能会有1分钟延迟。

HLS的直播优势是ts视频碎片文件可以一直保留不删除，不需要花额外的性能保存录像；直播转点播、录播都是更加简单的，只需要修改m3u8索引文件即可，不需要重新花费性能编解码。

6>二级索引

m3u8索引文件支持二级索引，就是高清、标清、流畅、等多个观看地址可以整合到一个索引文件中，播放器可以根据带宽自动切换不同的观看地址，很多网页播放器的“自动”也是因为这个。

7>缓解磁盘压力

由于HLS协议的视频文件、索引文件都是直接写入磁盘的，如果长时间且多个直播流同时处理，会造成磁盘写入压力过大，机械磁盘可能出现磁盘损坏，固态硬盘寿命衰减，最好挂载一段内存空间作为HLS相关文件的写入位置。

挂载一段内存空间作为写入位置

Linux命令：mount -t tmpfs -o size=10g tmpfs /data

把文件写入/data，即可写入内存，而非磁盘

重启数据会消失，但可以做一些定时保存的措施

6.4 WebRTC

1>WebRTC协议

WebRTC是一种点对点的视频/语音通话协议，基于UDP，建立通信后，会不断的以流式发送数据，延迟要比RTMP还要低1s内，再一些交互型较高的直播场景，例如直播带货。

2>WebRTC服务器

Webrtc地址一般是webrtc:/开头的，推流和拉流地址一般也是一样的，它是点对点的协议，用在直播中需要搭建WebRTC服务器。

例如：一个基于 WebRTC 协议实现多方实时通讯。

6.5 RTSP

RTSP实时流传输协议,定义了一对多应用程序如何有效地通过IP网络传送多媒体数据，一般用在摄像头、监控等硬件设备的实时视频流观看、推送上。

RTSP协议有诸多优点：TCP/UDP切换，支持推流/拉流，支持点播/直播，但是Web领域一般不使用RTSP，现代浏览器不支持播放。

7．解码

7.1 解封装

Demultiplexing（分离）：将复合音视频流(容器格式FLV、TS)中的多个单独的音频、视频、字幕或其他媒体流分离出来各自进行解码的过程。

7.2 音频编码框架

FDK-AAC：出色的音频编解码器，PCM音频数据和AAC音频数据互转，高音质、低延迟。

7.3 解码方式对比

特点	硬解码	软解码
原理	利用专用的硬件解码器（GPU）来解码视频数据	使用通用的软件算法（CPU）来解码视频数据
性能	高性能，播放流畅	性能较低，在播放高分辨率、高比特率的视频时可能出现卡顿
解码速度	快	慢
资源消耗	CPU占用低	CPU占用较高
兼容性	较差，受硬件平台限制	较好
适用场景	适用于资源有限的移动设备和嵌入式系统等	适用于处理能力较为强大的计算机或服务器等