一. 直播流程总览

目前主流的直播架构中主要有两种方案，即流媒体转发、P2P。流媒体转发，是一种在视频直播中以流的方式将连续的音、视频数据经编码压缩后传输到流媒体服务器，用户实时从服务器获取流媒体资源。而不必要等待整个文件下载文件完毕的C/S架构视频直播方案；P2P直播，是一种建立在P2P技术基础上的视频直播方案，它规定客户端之间使用一定协议来交换和共享直播数据，通过减少对服务器的数据请求，以降低服务端的I/O带宽等方面压力，从而削减服务器带宽成本，降低客户端卡播率。

一个直播功能通用的基础架构涉及三个部分，即音视频采集端、云服务端和音视频播放端。

直播app架构图
可以看到直播的流程可以分为如下几步：
音视频采集 —>音视频处理—>音视频编码和封装—>推流到服务器—>服务器流分发—>播放器流播放
image.png

如下图，是一个APP直播功能的架构：

img

从上图中我们可以看到，每一个部分都有各自要处理的一些工作。

总体来说，视频直播类功能的整体流程包括以下内容：

1. 音视频采集
2. 音视频处理
3. 音视频编码和封装
4. 推流
5. 流媒体服务器处理
6. 拉流
7. 音视频解码
8. 音视频播放

二. 音视频采集

在音视频采集阶段会包括：音频采集和图像采集。

在音频采集时，除了上面我们说到的采样率、量化级数和声道数参数外，还需要音频帧。

音频跟视频很不一样，视频每一帧就是一张图像，而从声音的正玄波可以看出：音频数据是流式的，没有明确的一帧帧的概念。在实际的应用中，为了音频算法处理/传输的方便，一般约定俗成取 2.5ms~60ms 为单位的数据量为一帧音频。

这个时间被称之为“采样时间”，其长度没有特别的标准，它是根据编解码器和具体应用的需求来决定的。

如果某音频信号是采样率为 8kHz、双通道、量化级数是16bit，采样时间是20ms，则一帧音频数据的大小为：8000 * 2 * 16bit * 0.02s = 5120 bit = 640 byte

在图像采集中，采集的图片结果会组合成一组连续播放的动画，即构成视频中可肉眼观看的内容。

图像的采集过程主要由摄像头等设备拍摄成 YUV 编码的原始数据，然后经过编码压缩成 H.264 等格式的数据分发出去。在图像采集阶段，涉及的主要技术参数包括：图像传输格式、图像格式、传输通道、分辨率以及采样率。

在音视频的采集阶段，常用的采集源包括摄像头，比如手机的前后置摄像头；游戏直播中使用的屏幕录制；和电视节目中视频文件的直接推流。

采集是整个视频推流过程中的第一个环节，它从系统的采集设备中获取原始视频数据，将其输出到下一个环节。视频的采集涉及两方面数据的采集：音频采集和图像采集，它们分别对应两种完全不同的输入源和数据格式。

音频采集

音频数据既能与图像结合组合成视频数据，也能以纯音频的方式采集播放，后者在很多成熟的应用场景如在线电台和语音电台等起着非常重要的作用。音频的采集过程主要通过设备将环境中的模拟信号采集成 PCM 编码的原始数据，然后编码压缩成 MP3 等格式的数据分发出去。常见的音频压缩格式有：MP3，AAC，HE-AAC，Opus，FLAC，Vorbis (Ogg)，Speex 和 AMR等。
音频采集和编码主要面临的挑战在于：延时敏感、卡顿敏感、噪声消除（Denoise）、回声消除（AEC）、静音检测（VAD）和各种混音算法等。

图像采集

将图像采集的图片结果组合成一组连续播放的动画，即构成视频中可肉眼观看的内容。图像的采集过程主要由摄像头等设备拍摄成 YUV 编码的原始数据，然后经过编码压缩成 H.264 等格式的数据分发出去。常见的视频封装格式有：MP4、3GP、AVI、MKV、WMV、MPG、VOB、FLV、SWF、MOV、RMVB 和 WebM 等。
图像由于其直观感受最强并且体积也比较大，构成了一个视频内容的主要部分。图像采集和编码面临的主要挑战在于：设备兼容性差、延时敏感、卡顿敏感以及各种对图像的处理操作如美颜和水印等。

视频采集的采集源主要有 摄像头采集、屏幕录制和从视频文件推流。

三. 音视频处理

音视频处理会分为：视频处理和音频处理。

视频处理包括：美颜、滤镜、面部识别、水印、剪辑拼接等。音频处理包括：混音、降噪、声音特效等。

下面我们简要描述一下美颜和视频水印的基本原理：

美颜的主要原理是通过【磨皮】+【美白】来达到整体美颜效果的。磨皮的技术术语是去噪，也就是对图像中的噪点进行去除或者模糊化处理，常见的去噪算法有均值模糊、高斯模糊和中值滤波等。这个环节中也涉及到人脸和皮肤检测技术。

视频水印包括播放器水印和视频内嵌水印两种方式。对于播放器水印来说，如果没有有效的防盗措施，对于没有播放鉴权的推流，客户端拿到直播流之后可以在任何一个不带水印的播放器里面播放，因此也就失去了视频保护的能力。所以，一般来说会选择视频内嵌水印的方式打水印，这样，水印就会内嵌到视频之内，在视频播放的过程中持续显示。

再多聊一些，视频内嵌水印也会应用在软件中，软件中播出企业内部版权保护的动画段视频时，会应用到内嵌水印的技术。

视频或者音频完成采集之后得到原始数据，为了增强一些现场效果或者加上一些额外的效果，我们一般会在将其编码压缩前进行处理，比如打上时间戳或者公司 Logo 的水印，祛斑美颜和声音混淆等处理。在主播和观众连麦场景中，主播需要和某个或者多个观众进行对话，并将对话结果实时分享给其他所有观众，连麦的处理也有部分工作在推流端完成。

这里写图片描述

如上图所示，处理环节中分为音频和视频处理，音频处理中具体包含混音、降噪和声音特效等处理，视频处理中包含美颜、水印、以及各种自定义滤镜等处理。

四. 音视频编码和封装

音视频的编码以及视频的封装在上述基础知识部分已经介绍过了，这里不再赘述。

在这里说一下编码器的知识。上文中我们了解了H.264的编码技术，编码流程是要基于编码器进行的。

编码器的主要流程是：帧内预测（去除空间冗余）/帧间预测（去除时间冗余）——变换（去除空间冗余）——量化（去除视觉冗余）——熵编码（去除编码冗余）。通过该流程，即可完成音视频的编码步骤。

（1）编码

如果把整个流媒体比喻成一个物流系统，那么编解码就是其中配货和装货的过程，这个过程非常重要，它的速度和压缩比对物流系统的意义非常大，影响物流系统的整体速度和成本。同样，对流媒体传输来说，编码也非常重要，它的编码性能、编码速度和编码压缩比会直接影响整个流媒体传输的用户体验和传输成本。

视频编码的意义
原始视频数据存储空间大，一个 1080P 的 7 s 视频需要 817 MB
原始视频数据传输占用带宽大，10 Mbps 的带宽传输上述 7 s 视频需要 11 分钟
而经过 H.264 编码压缩之后，视频大小只有 708 k ，10 Mbps 的带宽仅仅需要 500 ms ，可以满足实时传输的需求，所以从视频采集传感器采集来的原始视频势必要经过视频编码。

基本原理
为什么巨大的原始视频可以编码成很小的视频呢?这其中的技术是什么呢?核心思想就是去除冗余信息：
1）空间冗余：图像相邻像素之间有较强的相关性
2）时间冗余：视频序列的相邻图像之间内容相似
3）编码冗余：不同像素值出现的概率不同
4）视觉冗余：人的视觉系统对某些细节不敏感
5）知识冗余：规律性的结构可由先验知识和背景知识得到

编码器的选择
视频编码器经历了数十年的发展，已经从开始的只支持帧内编码演进到现如今的 H.265 和 VP9 为代表的新一代编码器，下面是一些常见的视频编码器：
1）H.264/AVC
2）HEVC/H.265
3）VP8
4）VP9
5）FFmpeg
注：音频编码器有Mp3, AAC等。

（2）封装
沿用前面的比喻，封装可以理解为采用哪种货车去运输，也就是媒体的容器。
所谓容器，就是把编码器生成的多媒体内容(视频，音频，字幕，章节信息等)混合封装在一起的标准。容器使得不同多媒体内容同步播放变得很简单，而容器的另一个作用就是为多媒体内容提供索引，也就是说如果没有容器存在的话一部影片你只能从一开始看到最后，不能拖动进度条，而且如果你不自己去手动另外载入音频就没有声音。下面是几种常见的封装格式：
1）AVI 格式(后缀为 .avi)
2）DV-AVI 格式(后缀为 .avi)
3）QuickTime File Format 格式(后缀为 .mov)
4）MPEG 格式(文件后缀可以是 .mpg .mpeg .mpe .dat .vob .asf .3gp .mp4等)
5）WMV 格式(后缀为.wmv .asf)
6）Real Video 格式(后缀为 .rm .rmvb)
7）Flash Video 格式(后缀为 .flv)
8）Matroska 格式(后缀为 .mkv)
9）MPEG2-TS 格式 (后缀为 .ts)
目前，我们在流媒体传输，尤其是直播中主要采用的就是 FLV 和 MPEG2-TS 格式，分别用于 RTMP/HTTP-FLV 和 HLS 协议。

四.音视频推流

推流就是将处理过的音频和视频数据通过流媒体协议发送到流媒体服务器。
直播的推流对这个直播链路影响非常大，如果推流的网络不稳定，无论如何做优化，观众的体验都会很糟糕。推送协议主要有三种：

• 1. RTSP（Real Time Streaming Protocol）：实时流传送协议，是用来控制声音或影像的多媒体串流协议, 由Real Networks和Netscape共同提出的；
• 2. RTMP(Real Time Messaging Protocol)：实时消息传送协议，是Adobe公司为Flash播放器和服务器之间音频、视频和数据传输 开发的开放协议；
• 3. HLS(HTTP Live Streaming)：是苹果公司(Apple Inc.)实现的基于HTTP的流媒体传输协议；

1：RTSP RTMP HTTP都是在应用应用层。

2： 理论上RTSP RTMPHTTP都可以做直播和点播，但一般做直播用RTSP RTMP，做点播用HTTP。做视频会议的时候原来用SIP协议，现在基本上被RTMP协议取代了。

推流所遵循的协议有RTMP、WebRTC和基于UDP的私有协议。

• RTMP协议是基于TCP协议的，RTMP 是目前主流的流媒体传输协议，广泛用于直播领域，市面上绝大多数的直播产品都采用了这个协议。但是，由于基于TCP协议，传输成本高，在弱网环境下丢包率高，不支持浏览器推送。
• WebRTC是一个支持网页浏览器进行实时语音对话或视频对话的 API，主要应用于视频会议。它的主流浏览器支持度高，并且底层基于SRTP和UDP，弱网情况优化空间大。
• 基于UDP的私有协议。有些直播应用会使用 UDP 做为底层协议开发自己的私有协议，因为 UDP在弱网环境下的优势通过一些定制化的调优可以达到比较好的弱网优化效果，但是开发成过高。

区别：

1：HTTP: 即超文本传送协议(ftp即文件传输协议)。

2：HTTP将所有的数据作为文件做处理。http协议不是流媒体协议。
3：RTMP协议是Adobe的私有协议,未完全公开，RTSP协议和HTTP协议是共有协议，并有专门机构做维护。

4：RTMP协议一般传输的是flv，f4v格式流，RTSP协议一般传输的是ts,mp4格式的流。HTTP没有特定的流。

5：RTSP传输一般需要2-3个通道，命令和数据通道分离，HTTP和RTMP一般在TCP一个通道上传输命令和数据。

RTMP 是目前主流的流媒体传输协议，广泛用于直播领域，可以说市面上绝大多数的直播产品都采用了这个协议，也有部分使用HLS协议。

推流可选方案：

利用FFmpeg进行直播推流（优点：对技术开发者来说，会有在不断的填坑过程中，提升自我；缺点：产品稳定性差，延迟大）；

利用第三方SDK（优点：延迟小，非常稳定，适用于产品快速上线，有专人维护；缺点：商业授权需要一定费用）。

五.服务器流分发

流媒体服务器的作用是负责直播流的发布和转播分发功能。

常用服务器

• SRS: 一款国人开发的优秀开源流媒体服务器系统
• BMS: 也是一款流媒体服务器系统，但不开源，是SRS的商业版，比SRS功能更多
• nginx: 免费开源Web服务器，常用来配置流媒体服务器

自建流媒体服务器局限性很大，费用也比较高昂，建议交给CDN服务商。

CDN：

推出去的流媒体要给各个地理位置的观众看，那么这里就需要CDN网络了。CDN就是为了解决用户访问网络资源慢而产生的技术。

CDN包括边缘节点、二级节点和源站。内容提供方可以将内容放到源站上，用户从边缘节点获取数据，而CDN的二级节点则用于缓存，减轻源站压力。

在直播领域中，CDN要支持的服务如下：

• 流媒体协议的支持。比如RTMP等；
• 首屏秒开。从用户点击到播放控制在秒级以内；
• 1~3 延迟控制。从推流端到播放端，延迟控制在 1~3 秒之间；
• 全球全网智能路由。可以利用整个CDN网络内的所有节点为某一单一用户服务，不受地域限制。

流媒体服务器处理

流媒体服务器要做的事情包括：数据分发（CDN）、支持上述CDN的一些服务、实时转码以及内容的检测（鉴黄）等。

转码

即构提供了实时转码技术，将用户推流码率较高（比如720P）实时转成较低清晰度（比如360P）的流以适应播放端的需求。

如果要自己搭建实时转码系统，这个成本是极高的，一台8核设备只能实时转10路流，一个规模中等的直播平台假设有1000路流，就需要100台设备，加上后期的运维成本，一般的公司是难以负担的。

鉴黄

目前市面上提供鉴黄服务的方案主要有两种，第一种是对视频进行截图，然后对图片进行鉴黄，返回鉴黄结果和分值，相关企业有阿里（绿网）、图普科技等。

第二种是和CDN结合，直接对直播流进行分析，识别结果分为色情、疑似色情、性感和正常，业务系统根据识别结果直接控制直播流，代表企业有Viscovery等。

六. 拉流播放

拉流就是客户端从流媒体服务器上拉取获得上述步骤中的音视频数据。同理，这个过程也是要基于上述的协议和CDN。
指服务器已有直播内容，用指定地址进行拉取的过程。根据协议类型（如RTMP、RTP、RTSP、HTTP等），与服务器建立连接并接收数据
流程如下：

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

根据不同的封装格式（如FLV、TS）解复用（demux）；

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

使用硬解码（对应系统的API）或软解码（FFMpeg）来解压音视频数据；

经过解码后得到原始的视频数据（YUV）和音频数据（AAC）；

因为音频和视频解码是分开的，所以我们得把它们同步起来，否则会出现音视频不同步的现象，比如别人说话会跟口型对不上；

最后把同步的音频数据送到耳机或外放，视频数据送到屏幕上显示。

主要是实现直播节目在终端上的展现。因为我这里使用的传输协议是RTMP， 所以只要支持 RTMP 流协议的播放器都可以使用

主要是实现直播节目在终端上的展现。因为我这里使用的传输协议是RTMP， 所以只要支持 RTMP 流协议的播放器都可以使用，譬如：

电脑端：VLC等
手机端：Vitamio以及ijkplayer等
一般情况下我们把上面流程的前四步称为第一部分，即视频主播端的操作。视频采集处理后推流到流媒体服务器，第一部分功能完成。第二部分就是流媒体服务器，负责把从第一部分接收到的流进行处理并分发给观众。第三部分就是观众啦，只需要拥有支持流传输协议的播放器即可。

在上述H.264编码的介绍中，说到了SPS/PPS是解码必备的数据。此步骤就是需要对拉流下来已编码的音视频数据进行解码。

解码过程就是编码的逆过程，这个过程包括：熵解码、变换解码、预测解码。

H.264规范规定了解码器的结构，解码的过程大体如下：以宏块为单位，依次进行熵解码、反量化、反变换，得到残差数据。再结合宏块里面的预测信息，找到已解码的被参考块，进而结合已解码被参考块和本块残差数据，得到本块的实际数据。宏块解码后，组合出片，片再进而组合出图像。

这里要说明的是：如果H264码流中I帧错误或丢失，就会导致错误传递，单独的P帧或B帧是完成不了解码工作的。I帧所保留的是一张完整的视频帧，是解码的关键所在。

8. 音视频播放

在完成了音视频数据的解码后，就可以通过硬件设备（手机或PC）上的播放器对音视频文件进行渲染播放了。

那么，上述架构图中的信令服务器是干什么的呢？

——信令服务器是用来处理主播端和用户端的一些信令指令的。

在网络中传输着各种信号，其中一部分是我们需要的（例如：打电话的语音，上网的数据包等等），而另外一部分是我们不需要的（只能说不是直接需要）它用来专门控制电路的，这一类型的信号我们就称之为信令（摘自百度百科）。也就是说，信令是指通信系统中的控制指令。

我们基于此，再来描述一下这整个的流程：

1. 主播共享端发起一个信令，比如：创建房间（或聊天、发送礼物等），到达信令服务器；信令服务器处理并且创建一个房间，同时返回给主播共享端一个流媒体云的地址。
2. 接下来，主播共享端采集数据（音视频的采集、处理以及编码封装流程）形成RTMP流推送到CDN网络（推流）。
3. 观众要进行观看时，客户端会发送信令到信令服务器，信令服务器将该观众加入到主播的房间中，同时也会返回一个流媒体云的地址（该地址就是之前主播端的流媒体云地址）。
4. 客户端拿到此流媒体云地址后，就会到流媒体云服务器拉取到该媒体流（拉流和解码），从而看到要观看的直播节目（播放器播放）。

七. P2P视频

(1) P2P点对点
P2P视频直播是客户端之间使用一定协议，交换和共享直播数据，通过减少对服务器的数据请求，来降低服务端的I/O带宽等方面压力，从而削减服务器带宽成本，降低客户端卡播率。在整个网络网框架中，每个客户端(节点)是对等的，即同时具有Client和Server的特点。常见开源框架：WebRTC
优点：服务器压力小，节省带宽成本，延时低，响应快，秒传，适合非实时的数据传输；
缺点：最多4~8个人同时在线观看，对节点带宽要求较高，服务器视频录制不好处理。IPv4网络环境制约，UDP打洞穿透效率问题，打洞不通要服务器relay；
应用场景：安防
(2) 流媒体转发
常见流媒体直播协议都属于C/S型，即所有客户端通过指定协议，从服务端获取直播数据。当客户端数量达到一定规模后，服务端将承受巨大的I/O和带宽压力。若服务器无法及时处理客户请求，客户端卡播率急剧上升，从而影响用户观看体验。常见开源框架：ffmpeg
优点：稳定可靠，支持量大，可以实现一个人播，百万人同时在线观看，且服务器可以进行视频录制存储，用户体验好；
缺点：用户数量增加后，对服务器的资源和带宽等压力大幅增加，服务器成本高，1~3秒延时；
应用场景：视频会议

八. 总结

本文通过直播类应用的架构，介绍了一些音视频技术方面的知识，并且详述了直播类功能的整体流程。
音视频技术是一个高深的领域，本文只是做了一些基础知识的总结，如果大家想要深入了解更多的音视频技术，我推荐大家可以学习一下雷神（雷霄骅）的博客。

参考资料：
Android直播解决方案
关于音视频直播技术的总结
视频直播的技术原理和实现思路方案整理
Android直播解决方案
关于音视频直播技术的总结
视频直播的技术原理和实现思路方案整理
webrtc可以做直播吗
webrtc进阶-信令篇-之三：信令、stun、turn、ice
WebRTC学习总结
因直播了解webRTC
Android WebRTC简介
Android 直播 直播架构技术浅析
像花椒，映客，来疯这种直播app，技术实现难度在哪？需要什么样技术人才，还有就是服务器带宽要求及成本？
RTMP、WebRTC、UDP 三种互动直播方案的优劣比较
WebRTC 研究系列 二、打通webrtc与rtmp
音视频篇 - Android 图像处理技术简介
老司机带你深入了解移动直播技术基础知识
Android视频直播的实现
Android视频直播的实现
Android直播开发之旅(7)：Android视频直播核心技术(架构)详解