直播技术基础知识

直播原理

通过计算机上的音视频输入设备或者手机端摄像头和麦克风实时录制的音视频流，编号码后通过直播协议将数据包实时发送给服务器端，服务器端通过流媒体协议把实时流分发出去，其他终端通过直播协议实时请求数据包，并进行解码播放，这就是直播原理。

直播架构

直播架构主要两块，第一块是采集数据推流过程，包括对数据进行编码，通过流媒体协议传输到服务器上。第二块是服务器端收到推流数据后，进行内容分发及中间转存处理。最后一块是播放器进行拉流操作。这其中不只是播放音视频，还可以做一些实时美颜和滤镜效果。

直播过程

直播过程主要涉及采集数据、渲染处理、编码数据、推流、CDN分发、拉流、播放流数据等。

采集数据

采集数据时从不同平台的设备中获取原始音视频数据，用于美颜或编码处理。数据采集涉及音视频采集和图像采集。

音频采集

音频数据既能与图像结合组合成视频数据，也支持单纯的音频数据输出(如电台)。音频的采集过程主要是通过设备设置采样率、采样数，将音频信号采集为PCM编码的原始数据，然后编码压缩成MP3、AC3等封装格式的数据分发出去。常见的音频封装格式有MP3、AAC、OGG、WMA、Opus、FLAC、APE、M4A和AMR等。音频采集和编码面临的主要挑战于去噪、回声消除(AEC)、静音检测(VAD)和各种在音频采集阶段，参考的主要技术参数如下。

采样率(Samplerate):采样率越高，数据量越大，音质越好。需注意的是，并不是采样率越高、效果越好，不同声音效果的采样率有一定的阈值。

位宽:位宽表示一次能传递的数据宽度。位宽越大，一次性能处理的数据就越多。音频采样过程中常用的位宽有8位或者16位。

声道数(Channel):声道是指声音在录制或播放时在不同空间位置采集或回放的相互独立的音频信号，声道数是声音录制时的音源数量或回放时相应的扬声器数量。声道数为1和2分别称为单声道和双声道，是比较常见的声道参数。

图像采集

图像采集就是通过摄像头或者可以采集图像的设备，获取一段时间内的图像内容。如手机摄像头采集的NV21(一种YUV格式)格式数据，然后经过编码压缩成H.264等格式的数据，随后可以编码成不同的封装格式(如FLV)传递或者直接通过流媒体议(如RTMP协议)传递到服务器端。

在图像采集阶段，参考的主要技术参数如下。

图像格式：常采用YUV格式存储原始数据信息，其中含用8位表示的黑白图像灰度值，以及可由RGB共3种色彩组成的彩色图像

传输通道：传输通道就是数据在传输时所利用的媒介，包括获取模块数据类型模块、传输模块。如可以使用TCP传输或UDP传输。

分辨率：代表图像中存储的信息量，指每英寸图像内有多少个像素，图像分辨率的表达方式为“水平像素数×垂直像素数”。  

采样频率(采样率):指每秒从连续信号中提取并组成离散信号的采样个数，如采样720像素视频，还是540像素视频，不同的采样个数应的分辨率不一样，文件大小也不一样。

fts:指画面每秒传输的帧数，通俗来讲就是动画或视频的画面数。直播一般设置为 15-20fps。

渲染处理

渲染处理，主要是对从相机中采集来的数据进行二次处理。

美颜的基本概念：通过一定的算法对原始图像数据进行二次处理并强化图像效果，不限于去掉不协调区域、边缘检测等。

GPU工作原理：GPU指图像运算工作的微处理器，GPU主要利用显对卡图像的顶坐标，通过图元组配，进行光栅化、顶点着色、片元着色等一系列管线操作。

OpenGL ES (Open Graphics Library for Embedded Systems ，开源嵌入式系统图形处理框

架): 一套图形与硬件的接口，用于把处理好的图像显示到屏幕上。

 GPUlImage:是一个基于OpenGL ES 2.0图像和视频处理的跨平台框架，提供了各种各样的图像处理滤镜，支持相机和摄像机的实时滤镜，内置120多种滤镜效果，并且能够自定义图像滤镜。

滤镜处理的原理：就是把静态图像或者视频的每一帧进行图形变换后显示出来。它的本质是像素点的坐标和颜色变化。

 GPUImage处理画面的原理如下。

 GPUImage采用链式方式处理画面，通过 add Target函数为链条添加每个环节的对象。处理完一个 target,,就会把上一个环节处理好的图像数据传递给下一个 target去处理，这被称为 GPUImage处理链。

编码数据

视频编码是指通过特定的压缩技术，将某个视频格式文件转换成另一种视频格式的方式。

压缩原理，核心思想就是去除冗余信息，如下所述。

1）空间冗余：图像相邻像素之间有较强的相关性。

2）时间冗余：视频序列的相邻图像之间内容相似。

3）编码冗余：不同像素值出现的概率不同。

4）视觉冗余：人的视觉系统对某些细节不敏感。

5）知识冗余：规律性的结构可由先验知识和背景知识得到。

推流

1.RTMP是 Real Time Messaging Protocol(实消息传输协议)的首母缩写。该协议基于TCP,是一个协议族，包括RTMP基本协议及RTMPT、RTMPS、RTMPE等多个变种协议。RTMP是一种被设计用来进行实时数据通信的网络协议，主要用在 Flash平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。支持该协议的软件包括 Adobe Media Server, Ultrant Media Server、red5等。

优点：

1)对CDN友好，主流的CDN厂商都支持该协议。

2)协议简单，在各平台上实现容易。

缺点：

1)基于TCP传输成高，在弱网环境丢包率高的情况下问题明显。

2)不支持浏览器推送。   

3)Adobe私有协议，Adobe已经不再更新该协议。

2.WebRTC, Web Real Time Communication(网络即时通信),是一个支持Web浏览器进行实时语音对话或视频对话的API。

优点：

1)W3C标准,主流浏览器支持程度高。

2)google在背后支撑，并针对各平台有参考实现。

3)底层基于SRTP和UDP，在弱网情况下优化空间大。

4)可以实现点对点通信，通信双方延迟长。

缺点：

ICE、STUN、TURN等传统CDN没有提供类似的服务。

3.基于UDP的私有协议

有些直播应用会使用UDP作为底层协议开发自己的私有协议。由于UDP在弱网环境下的优势，因此通过一些定制化的调优可以达到比较好的弱网优化效果；但同样因为其是私有协议，故势必有现实问题。

优点

有更多的空间进行定制化优化。

缺点：

1)开发成本高。
2)对CDN不友好，需要自建CDN或者和CDN达成协议。
3)独立作战，无法和社区一起演进。

推流过程就是把编码后的数据打包并通过直播协议发送给流媒体服务器的过程。

1)经过输出设备得到原始采样数据视频数据YUV和音频数据PCM。

2)使用硬编码( MediaCodec)或软编码( FFmpeg)来编码压缩音视频数据。

3)分别得到已编码的H.264视频数据和AAC音频数据。

4)将已编码的音视频数据封装成不同的视频封装格式的数据文件(如FLV、TS、MPEG-TS)。

5)使用HLS协议的时候加上这一步(HLS分段生成策略及m3u8索引文件)。

6)通过流媒体协议上传到服务器。

7)服务器通过相关协议对内容进行分发。

推流优化

在推流过程中经常会遭遇网络不好、断流的情况，所以需要一定的策略。在推流端ping视频中心地址，测试是否有丢包现象。同时在网络抖动时，需要动态调整一些参数以便推流。在网络断后重连时，需要新优先发送音频数据，保证用户能听到声音。视频数据随后到达，使观众看到画面变化，并逐步回归到音视频同步。

CDN分发，请各位读者自行去了解。

拉流

根据协议类型(如RTMP、RTP、RTSP、HTTP等),与服务器建立连接并接收数据。 

1)解析二进制数据，从中找到相关流信息。

2)根据不同的封装格式(如FLV、TS)解复用。

3)分别得到已编码的H.264视频数据和AAC音频数据。

4)使用硬解码( MediaCodec)或软解码( FFmpeg)来解压音视频数据。

5)经过解码后得到原的视频数据(YUV)和音频数据(PCM)。

6)因为音频和视频解码是分开的，所以在解码后，需要做音视频同步。通常有一些音视频同

步算法。如在FFmpeg,以音频作为参考时钟，视频用于比较当前时钟和音频时钟的差值，如果快了，就需要增大延时，以便下一帧显示得晚些；如果慢了，就需要减少延时，加快显示下一帧。

7)最后把同步的音频数据发送到耳机或外放设备上播放，将视频数据发送到屏幕上显示。

播放流数据

播放流数据，一般涉及几个过程。首先进行access操作，也就是获取数据流；然后进行demux操作，也就是解复用，将数据流分离成音频流和视频流；接着将音频流送入音频解码器，将视频流送入视频解码器：最后进行音视频同步输出。通常直接使用第三方播放器，仅仅了解API调用就行，其他的则交由播放内核去做。

软解码

优点：

1)兼容性强，对系统版本要求低，出错情况少。

2)解码方面，软解码的色彩一般比硬解码的柔和。

3)编码的课操作空间大，自由度高。

缺点：

1)CPU消耗较大。

2)机器容易发热。

3)较高。

硬解码

优点：

功耗低、执行效率低。

缺点：

1)不同型号的芯片对编解码的实现不同，并不能保证编解码效果与其他机型一样或不出错。

2)可控性差，依赖底层编解码实现。

感谢各位关注