Android视频直播02——直播不得知道的基础
- Android视频直播02直播不得知道的基础
- 一直播的基本结构
- 二采集
- 1 音频采集
- 2 图像采集
- 三处理
- 四编码和封装
- 1 视频编码的意义
- 2 基本原理
- 3 编码器的选择
- 31 H264 简介
- 32 HEVCH265 简介
- 33 VP8 简介
- 34 VP9 简介
- 五推流
- 1 RTMP
- 2 WebRTC
- 3 基于 UDP 的私有协议
- 六参考
Android视频直播02——直播不得知道的基础
我们前面查看了直播的基本形式，或者说我们自己搭建了一个直播系统。下面我们来了解一下直播中的一些基础问题。
一、直播的基本结构
上面可以看到我们我们直播主要操作如下：
- 采集
- 处理
- 编码和封装
- 推流到服务器
- 服务器分发流
- 流播放
二、采集
2.1 音频采集
音频数据既能与图像结合组合成视频数据，也能以纯音频的方式采集播放，后者在很多成熟的应用场景如在线电台和语音电台等起着非常重要的作用。音频的采集过程主要通过设备将环境中的模拟信号采集成 PCM 编码的原始数据，然后编码压缩成 MP3 等格式的数据分发出去。常见的音频压缩格式有：MP3，AAC，OGG，WMA，Opus，FLAC，APE，m4a 和 AMR 等。
音频采集和编码主要面临的挑战在于：延时敏感、卡顿敏感、噪声消除（Denoise）、回声消除（AEC）、静音检测（VAD）和各种混音算法等。
在音频采集阶段，参考的主要技术参数有 ：
| 参 数 | 说明 |
|---|---|
| 采样率（samplerate） | 采样就是把模拟信号数字化的过程，采样频率越高，记录这一段音频信号所用的数据量就越大，同时音频质量也就越高。 |
| 位宽 | 每一个采样点都需要用一个数值来表示大小，这个数值的数据类型大小可以是：4bit、8bit、16bit、32bit 等等，位数越多，表示得就越精细，声音质量自然就越好，而数据量也会成倍增大。我们在音频采样过程中常用的位宽是 8bit 或者 16bit。 |
| 声道数（channels） | 由于音频的采集和播放是可以叠加的，因此，可以同时从多个音频源采集声音，并分别输出到不同的扬声器，故声道数一般表示声音录制时的音源数量或回放时相应的扬声器数量。声道数为 1 和 2 分别称为单声道和双声道，是比较常见的声道参数。 |
| 音频帧（frame） | 音频跟视频很不一样，视频每一帧就是一张图像，而从上面的正玄波可以看出，音频数据是流式的，本身没有明确的一帧帧的概念，在实际的应用中，为了音频算法处理/传输的方便，一般约定俗成取 2.5ms~60ms 为单位的数据量为一帧音频。这个时间被称之为“采样时间”，其长度没有特别的标准，它是根据编解码器和具体应用的需求来决定的。 |
根据以上定义，我们可以计算一下一帧音频帧的大小。假设某音频信号是采样率为 8kHz、双通道、位宽为 16bit，20ms 一帧，则一帧音频数据的大小为：
size = 8000 x 2 x 16bit x 0.02s = 5120 bit = 640 byte2.2 图像采集
图像采集的图片结果组合成一组连续播放的动画，即构成视频中可肉眼观看的内容。图像的采集过程主要由摄像头等设备拍摄成 YUV 编码的原始数据，然后经过编码压缩成 H.264 等格式的数据分发出去。常见的视频封装格式有：MP4、3GP、AVI、MKV、WMV、MPG、VOB、FLV、SWF、MOV、RMVB 和 WebM 等。
图像由于其直观感受最强并且体积也比较大，构成了一个视频内容的主要部分。图像采集和编码面临的主要挑战在于：设备兼容性差、延时敏感、卡顿敏感以及各种对图像的处理操作如美颜和水印等。
在图像采集阶段，参考的主要技术参数有：
| 参数 | 说明 |
|---|---|
| 图像传输格式 | 通用影像传输格式（Common Intermediate Format）是视讯会议（video conference）中常使用的影像传输格式。 |
| 图像格式 | 通常采用 YUV 格式存储原始数据信息，其中包含用 8 位表示的黑白图像灰度值，以及可由 RGB 三种色彩组合成的彩色图像。 |
| 传输通道 | 正常情况下视频的拍摄只需 1 路通道，随着 VR 和 AR 技术的日渐成熟，为了拍摄一个完整的 360°视频，可能需要通过不同角度拍摄，然后经过多通道传输后合成。 |
| 分辨率 | 随着设备屏幕尺寸的日益增多，视频采集过程中原始视频分辨率起着越来越重要的作用，后续处理环节中使用的所有视频分辨率的定义都以原始视频分辨率为基础。视频采集卡能支持的最大点阵反映了其分辨率的性能。 |
| 采样频率 | 采样频率反映了采集卡处理图像的速度和能力。在进行高度图像采集时，需要注意采集卡的采样频率是否满足要求。采样率越高，图像质量越高，同时保存这些图像信息的数据量也越大。 |
三、处理
如上图所示，处理环节中分为音频和视频处理，音频处理中具体包含混音、降噪和声音特效等处理，视频处理中包含美颜、水印、以及各种自定义滤镜等处理。
四、编码和封装
4.1 视频编码的意义
- 原始视频数据存储空间大，一个 1080P 的 7 s 视频需要 817 MB
- 原始视频数据传输占用带宽大，10 Mbps 的带宽传输上述 7 s 视频需要 11 分钟
而经过 H.264 编码压缩之后，视频大小只有 708 k ,10 Mbps 的带宽仅仅需要 500 ms ，可以满足实时传输的需求，所以从视频采集传感器采集来的原始视频势必要经过视频编码。
4.2 基本原理
那为什么巨大的原始视频可以编码成很小的视频呢？这其中的技术是什么呢？核心思想就是去除冗余信息：
空间冗余：图像相邻像素之间有较强的相关性
时间冗余：视频序列的相邻图像之间内容相似
编码冗余：不同像素值出现的概率不同
视觉冗余：人的视觉系统对某些细节不敏感
知识冗余：规律性的结构可由先验知识和背景知识得到
视频本质上讲是一系列图片连续快速的播放，最简单的压缩方式就是对每一帧图片进行压缩，例如比较古老的 MJPEG 编码就是这种编码方式，这种编码方式只有帧内编码，利用空间上的取样预测来编码。形象的比喻就是把每帧都作为一张图片，采用 JPEG 的编码格式对图片进行压缩，这种编码只考虑了一张图片内的冗余信息压缩除了空间冗余和时间冗余的压缩，主要还有编码压缩和视觉压缩，下面是一个编码器主要的流程图：
帧内编码
帧间编码
从图上看到的主要区别就是第一步不相同，其实这两个流程也是结合在一起的，我们通常说的 I 帧和 P 帧就是分别采用了帧内编码和帧间编码。
4.3 编码器的选择
4.3.1 H.264 简介
H.264/AVC 项目意图创建一种视频标准。与旧标准相比，它能够在更低带宽下提供优质视频（换言之，只有 MPEG-2，H.263 或 MPEG-4 第 2 部分的一半带宽或更少），也不增加太多设计复杂度使得无法实现或实现成本过高。另一目的是提供足够的灵活性以在各种应用、网络及系统中使用，包括高、低带宽，高、低视频分辨率，广播，DVD 存储，RTP/IP 网络，以及 ITU-T 多媒体电话系统
4.3.2 HEVC/H.265 简介
高效率视频编码（High Efficiency Video Coding，简称 HEVC）是一种视频压缩标准，被视为是 ITU-T H.264/MPEG-4 AVC 标准的继任者。2004 年开始由 ISO/IEC Moving Picture Experts Group（MPEG）和 ITU-T Video Coding Experts Group（VCEG）作为 ISO/IEC 23008-2 MPEG-H Part 2 或称作 ITU-T H.265 开始制定。第一版的 HEVC/H.265 视频压缩标准在 2013 年 4 月 13 日被接受为国际电信联盟（ITU-T）的正式标准。HEVC 被认为不仅提升视频质量，同时也能达到 H.264/MPEG-4 AVC 两倍之压缩率（等同于同样画面质量下比特率减少了 50%），可支持 4K 分辨率甚至到超高清电视（UHDTV），最高分辨率可达到 8192×4320（8K 分辨率）。
4.3.3 VP8 简介
VP8 是一个开放的视频压缩格式，最早由 On2 Technologies 开发，随后由 Google 发布。同时 Google 也发布了 VP8 编码的实做库：libvpx，以 BSD 授权条款的方式发行，随后也附加了专利使用权。而在经过一些争论之后，最终 VP8 的授权确认为一个开放源代码授权。
目前支持 VP8 的网页浏览器有 Opera、Firefox 和 Chrome。
4.3.4 VP9 简介
VP9 的开发从 2011 年第三季开始，目标是在同画质下，比 VP8 编码减少 50% 的文件大小，另一个目标则是要在编码效率上超越 HEVC 编码。
2012 年 12 月 13 日，Chromium 浏览器加入了 VP9 编码的支持。Chrome 浏览器则是在 2013 年 2 月 21 日开始支持 VP9 编码的视频播放。
Google 宣布会在 2013 年 6 月 17 日完成 VP9 编码的制定工作，届时 Chrome 浏览器将会把 VP9 编码默认引导。2014 年 3 月 18 日，Mozilla 在 Firefox 浏览器中加入了 VP9 的支持。
2015 年 4 月 3 日，谷歌发布了libvpx1.4.0 增加了对 10 位和 12 位的比特深度支持、4:2:2 和 4:4:4 色度抽样，并 VP9 多核心编/解码。
五、推流
推送协议
RTMP
WebRTC
基于 UDP 的私有协议
5.1 RTMP
RTMP 是 Real Time Messaging Protocol（实时消息传输协议）的首字母缩写。该协议基于 TCP，是一个协议族，包括 RTMP 基本协议及 RTMPT/RTMPS/RTMPE 等多种变种。RTMP 是一种设计用来进行实时数据通信的网络协议，主要用来在 Flash/AIR 平台和支持 RTMP 协议的流媒体/交互服务器之间进行音视频和数据通信。支持该协议的软件包括 Adobe Media Server/Ultrant Media Server/red5 等。
RTMP 是目前主流的流媒体传输协议，广泛用于直播领域，可以说市面上绝大多数的直播产品都采用了这个协议。
优点
- CDN 支持良好，主流的 CDN 厂商都支持
- 协议简单，在各平台上实现容易
缺点
- 基于 TCP ，传输成本高，在弱网环境丢包率高的情况下问题显著
- 不支持浏览器推送
- Adobe 私有协议，Adobe 已经不再更新
5.2 WebRTC
WebRTC，名称源自网页即时通信（英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的 API。它于 2011 年 6 月 1 日开源并在 Google、Mozilla、Opera 支持下被纳入万维网联盟的 W3C 推荐标准。
目前主要应用于视频会议和连麦中，协议分层如下：
优点
- W3C 标准，主流浏览器支持程度高
- Google 在背后支撑，并在各平台有参考实现
- 底层基于 SRTP 和 UDP，弱网情况优化空间大
- 可以实现点对点通信，通信双方延时低
缺点
- ICE,STUN,TURN 传统 CDN 没有类似的服务提供
5.3 基于 UDP 的私有协议
有些直播应用会使用 UDP 做为底层协议开发自己的私有协议，因为 UDP 在弱网环境下的优势通过一些定制化的调优可以达到比较好的弱网优化效果，但同样因为是私有协议也势必有现实问题：
优点
- 更多空间进行定制化优化
缺点
- 开发成本高
- CDN 不友好，需要自建 CDN 或者和 CDN 达成协议
- 独立作战，无法和社区一起演进
六、参考
严重说明：上面的内容来自下面文字的摘选，如果需要深入，请看下面的文章
《视频直播技术详解》系列之一：开篇
《视频直播技术详解》系列之二：采集
《视频直播技术详解》系列之三：处理
《视频直播技术详解》系列之四：编码和封装
《视频直播技术详解》系列之五：推流和传输
《视频直播技术详解》系列之六：延迟优化
《视频直播技术详解》系列之七：现代播放器原理