视频直播理论

  因为现在我们在上视频直播的课程，后面会讲微服务，写这个日志也是给大家提供一个思路，不定期会更新流媒体服务器的安装，转码工具的使用等相关的文章，有些来自于网络收集有些就是自己总结

 

 

1.HTML5与直播的发展

 

我们可以来看看HTML5在视频直播中的发展

 

从这个可以看出直播的应用越来越广从 PC 到一直发展到移动端，越来越多的直播类 App 上线，同时移动直播进入了前所未有的爆发阶段，但是对于大多数移动直播来说，还是要以 Native 客户端实现为主，但是 H5 在移动直播端也承载着不可替代的作用，例如 H5 有着传播快、易发布的优势，同时最为关键的是 H5 同样可以播放直播视频。

 

 

 

完整的直播可以分为以下几块：

视频录制端：
电脑上的音视频输入设备或者手机端的摄像头或者麦克风，目前以移动端的手机视频为主。

视频播放端：可以是电脑上的播放器，手机端的 Native 播放器，还有 H5 的 video 标签等，我们主要做的就是浏览器的播放，依赖H5

流媒体服务器端
用来接受视频录制端提供的视频源，同时提供给视频播放端流服务。目前开源的流媒体有RED5，CRTMPD，NGINX-RTMP，SRS。

 

2.视频直播流程

采集 —>处理—>编码和封装—>推流到服务器—>服务器流分发—>播放器流播放

 

2.1采集

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

 

 

2.1.1 音频采集

音频数据既能与图像结合组合成视频数据，也能以纯音频的方式采集播放，后者在很多成熟的应用场景如在线电台和语音电台等起着非常重要的作用。音频的采集过程主要通过设备将环境中的模拟信号采集成 PCM 编码的原始数据，然后编码压缩成 MP3 等格式的数据分发出去。常见的音频压缩格式有：MP3，AAC，HE-AAC，Opus，FLAC，Vorbis (Ogg)，Speex 和 AMR等。

音频采集和编码主要面临的挑战在于：延时敏感、卡顿敏感、噪声消除（Denoise）、回声消除（AEC）、静音检测（VAD）和各种混音算法等。

 

2.1.2 图像采集

将图像采集的图片结果组合成一组连续播放的动画，即构成视频中可肉眼观看的内容。图像的采集过程主要由摄像头等设备拍摄成 YUV 编码的原始数据，然后经过编码压缩成 H.264 等格式的数据分发出去。常见的视频封装格式有：MP4、3GP、AVI、MKV、WMV、MPG、VOB、FLV、SWF、MOV、RMVB 和 WebM 等。

图像由于其直观感受最强并且体积也比较大，构成了一个视频内容的主要部分。图像采集和编码面临的主要挑战在于：设备兼容性差、延时敏感、卡顿敏感以及各种对图像的处理操作如美颜和水印等

 

2.2处理

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

 

处理的过程主要是美颜和滤镜了，重点说说美颜，美颜有两步，一个是磨皮，一个是美白，要想正确美颜，所以还需要加上人脸识别技术和皮肤识别技术。

 

2.3 压缩编码和封装

压缩：

首先，要知道的是，一个视频是由一个个画面组成的，多个画面连续运动便构成了动画，也就是视频，一个个画面我们称为帧(笔者想起小时候玩的小玩具，一个小本本，里面有很多相似的图画，然后像翻书那样快速翻过，形成了动画)。

 

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

 

·视频编码的意义

原始视频数据存储空间大，一个 1080P 的 7 s 视频需要 817 MB

原始视频数据传输占用带宽大，10 Mbps 的带宽传输上述 7 s 视频需要 11 分钟

而经过 H.264 编码压缩之后，视频大小只有 708 k ，10 Mbps 的带宽仅仅需要 500 ms ，可以满足实时传输的需求，所以从视频采集传感器采集来的原始视频势必要经过视频编码。

 

·基本原理

为什么巨大的原始视频可以编码成很小的视频呢?这其中的技术是什么呢?核心思想就是去除冗余信息：

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

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

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

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

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

 

封装：

沿用前面的比喻，封装可以理解为采用哪种货车去运输，也就是媒体的容器。

所谓容器，就是把编码器生成的多媒体内容(视频，音频，字幕，章节信息等)混合封装在一起的标准。容器使得不同多媒体内容同步播放变得很简单，而容器的另一个作用就是为多媒体内容提供索引，也就是说如果没有容器存在的话一部影片你只能从一开始看到最后，不能拖动进度条，而且如果你不自己去手动另外载入音频就没有声音。下面是几种常见的封装格式：

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 协议。

2.4 推流到服务器

推流是直播的第一公里，直播的推流对这个直播链路影响非常大，如果推流的网络不稳定，无论我们如何做优化，观众的体验都会很糟糕。所以也是我们排查问题的第一步，如何系统地解决这类问题需要我们对相关理论有基础的认识。

 

推送协议主要有三种：

·RTSP（Real Time Streaming Protocol）：实时流传送协议，是用来控制声音或影像的多媒体串流协议, 由Real Networks和Netscape共同提出的；

·RTMP(Real Time Messaging Protocol)：实时消息传送协议，是Adobe公司为Flash播放器和服务器之间音频、视频和数据传输 开发的开放协议；

·HLS(HTTP Live Streaming)：是苹果公司(Apple Inc.)实现的基于HTTP的流媒体传输协议；

 

RTMP协议基于 TCP，是一种设计用来进行实时数据通信的网络协议，主要用来在 flash/AIR 平台和支持 RTMP 协议的流媒体/交互服务器之间进行音视频和数据通信。支持该协议的软件包括 Adobe Media Server/Ultrant Media Server/red5 等。

 

它有三种变种：

RTMP工作在TCP之上的明文协议，使用端口1935；

RTMPT封装在HTTP请求之中，可穿越防火墙；

RTMPS类似RTMPT，但使用的是HTTPS连接；

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

 

RTMP协议就像一个用来装数据包的容器，这些数据可以是AMF格式的数据,也可以是FLV中的视/音频数据。一个单一的连接可以通过不同的通道传输多路网络流。这些通道中的包都是按照固定大小的包传输的。

              

 

 

2.5 服务器流分发

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

  流媒体服务器有诸多选择，如商业版的Wowza。但我选择的是srs，它是一款优秀的免费Web服务器，后面我会详细介绍如何搭建srs服务器。

 

2.6 播放器流播放

 

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

电脑端：VLC等

手机端：Vitamio以及ijkplayer等

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