直播理论

简介 完整的直播可以分为以下几块: 视频录制端: 电脑上的音视频输入设备或者手机端的摄像头或者麦克风,目前以移动端的手机视频为主。 视频播放端:可以是电脑上的播放器,手机端的 Native 播放器,还有 H5 的 video 标签等,我们主要做的就是浏览器的播放,依赖H5 流媒体服务器端 用来接受视频录制端提供的视频源,同时提供给视频播放端流服务。目前开源的流媒体有RED5,CRTMPD,NGINX-RTMP,SRS。

介绍


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

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

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

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

    

视频直播流程 

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

 

图片1.png


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


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

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


    将图像采集的图片结果组合成一组连续播放的动画,即构成视频中可肉眼观看的内容。图像的采集过程主要由摄像头等设备拍摄成 YUV 编码的原始数据,然后经过编码压缩成 H.264 等格式的数据分发出去。常见的视频封装格式有:MP43GPAVIMKVWMVMPGVOBFLVSWFMOVRMVB WebM 等。

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




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

 

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


 压缩

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

 

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

 

·视频编码的意义

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

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

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

 

·基本原理

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

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

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

3)编码冗余:不同像素值出现的概率不同

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

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

 

封装

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

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

1AVI 格式(后缀为 .avi)

2DV-AVI 格式(后缀为 .avi)

3QuickTime File Format 格式(后缀为 .mov)

4MPEG 格式(文件后缀可以是 .mpg .mpeg .mpe .dat .vob .asf .3gp .mp4)

5WMV 格式(后缀为.wmv .asf)

6Real Video 格式(后缀为 .rm .rmvb)

7Flash Video 格式(后缀为 .flv)

8Matroska 格式(后缀为 .mkv)

9MPEG2-TS 格式 (后缀为 .ts)

目前,我们在流媒体传输,尤其是直播中主要采用的就是 FLV MPEG2-TS 格式,分别用于 RTMP/HTTP-FLV HLS 协议。




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

 

推送协议主要有三种:

 

·RTSPReal Time Streaming Protocol):实时流传送协议,是用来控制声音或影像的多媒体串流协议, Real NetworksNetscape共同提出的;

·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中的视/音频数据。一个单一的连接可以通过不同的通道传输多路网络流。这些通道中的包都是按照固定大小的包传输的。


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

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


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

 

电脑端:VLC

手机端:Vitamio以及ijkplayer

 

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


图片2.png



常见直播协议

RTMP: 底层基于TCP,在浏览器端依赖Flash

HTTP-FLV: 基于HTTP流式IO传输FLV,依赖浏览器支持播放FLV

WebSocket-FLV: 基于WebSocket传输FLV,依赖浏览器支持播放FLVWebSocket建立在HTTP之上,建立WebSocket连接前还要先建立HTTP连接。

HLS: Http Live Streaming,苹果提出基于HTTP的流媒体传输协议。HTML5可以直接打开播放。

RTP: 基于UDP,延迟1秒,浏览器不支持。

常见直播协议延迟与性能数据

传输协议

播放器

延迟

内存

CPU

RTMP

Flash

1s

430M

11%

HTTP-FLV

Video

1s

310M

4.4%

HLS

Video

20s

205M

3%

WebSocket-FLV

H5-FLV

410M

8%

在支持浏览器的协议里,延迟排序是:
WebSocket-FLVRTMP = HTTP-FLV
而性能排序恰好相反:
RTMP > =WebSocket-FLV >HTTP-FLV> HLS
也就是说延迟小的性能不好。

可以看出在浏览器里做直播,使用HTTP-FLV或者websocket-flv协议是不错的,性能优于RTMP+Flash,延迟可以做到和RTMP+Flash一样甚至更好。

 

HLS

HLS 全称是 HTTP Live Streaming。这是 Apple 提出的直播流协议。(其实,Adobe 公司 FLV 播放器的没落,苹果也是幕后黑手之一。)

 

HLS 由两部分构成,一个是 .m3u8 文件,一个是 .ts 视频文件(TS 是视频文件格式的一种)。整个过程是,浏览器会首先去请求 .m3u8 的索引文件,然后解析 m3u8,找出对应的 .ts 文件链接,并开始下载。

HLS缺点

HLS 啥都好,就是延迟性太大了,估计苹果一开始设计的时候,并不在乎它的延时性。HLS 中的延时包括:

TCP 握手

m3u8 文件下载

m3u8 文件下所有 ts 文件下载

 

这里,我们先假设每个 ts 文件播放时长为 5s,每个 m3u8 最多可携带的 ts 文件数为 3~8。那么最大的延迟则为 40s。注意,只有当一个 m3u8 文件下所有的 ts 文件下载完后,才能开始播放。这里还不包括 TCP 握手,DNS 解析,m3u8 文件下载。所以,HLS 总的延时是非常令人绝望的。那解决办法有吗? 有,很简单,要么减少每个 ts 文件播放时长,要么减少 m3u8 的中包含 ts 的数量。如果超过平衡点,那么每次请求新的 m3u8 文件时,都会加上一定的延时,所以,这里需要根据业务指定合适的策略。当然,现在由于 mediaSource 的普及,自定义一个播放器也没有多大的难度,这样就可以保证直播延迟性的同时,完成直播的顺利进行。

 

RTMP

RTMP 全称为:Real-Time Messaging Protocol。它是基于 FLV 格式进行开发的

 

是的,在现在设备中,由于 FLV 的不支持,基本上 RTMP 协议在 Web 中,根本用不到。不过,由于 MSEMediaSource Extensions)的出现,在 Web 上直接接入 RTMP 也不是不可能的。基本思路是根据 WebSocket 直接建立长连接进行数据的交流和监听。这里,我们就先不细说了。我们主要目的是讲概念,讲框架。RTMP 协议根据不同的套层,也可以分为:

 

RTMP: 直接通过 TCP 连接,端口为 1935

RTMPS: RTMP + TLS/SSL,用于安全性的交流。

RTMPE: RTMP + encryption。在 RTMP 原始协议上使用,Adobe 自身的加密方法

RTMPT: RTMP + HTTP。使用 HTTP 的方式来包裹 RTMP 流,这样能直接通过防火墙。不过,延迟性比较大。

RTMFP: RMPT + UDP。该协议常常用于 P2P 的场景中,针对延时有变态的要求。

 

RTMP 内部是借由 TCP 长连接协议传输相关数据,所以,它的延时性非常低。并且,该协议灵活性非常好(所以,也很复杂),它可以根据 message stream ID 传输数据,也可以根据 chunk stream ID 传递数据。两者都可以起到流的划分作用。流的内容也主要分为:视频,音频,相关协议包等。 

HTTP-FLV

该协议和 RTMP 比起来其实差别不大,只是落地部分有些不同:

 

RTMP 是直接将流的传输架在 RTMP 协议之上,而 HTTP-FLV 是在 RTMP 和客户端之间套了一层转码的过程 

 

由于,每个 FLV 文件是通过 HTTP 的方式获取的,所以,它通过抓包得出的协议头需要使用 chunked 编码。

 


Content-Type:video/x-flv

Expires:Fri, 10 Feb 2017 05:24:03 GMT

Pragma:no-cache

Transfer-Encoding:chunked

 

它用起来比较方便,不过后端实现的难度和直接使用 RTMP 来说还是比较大的。

上面简单介绍了一下种协议,具体选择哪种协议,还是需要和具体的业务相关

前端音视频流

我们常见的avi,rmvb,mp4,flv,mkv等格式的视频,他们的后缀代表的是他们的封装格式的不同,就是把视频数据和音频数据按照既定的规范进行打包个和规范。但是这个后缀只是一种简单的方式我们并不能发现他其中的编码标准

 

视频压缩格式和视频格式具体的区别就是,它是将原始的视频码流变为可用的数字编码。因为,原始的视频流非常大,打个比方就是,你直接使用手机录音,你会发现你几分钟的音频会比市面上出现的 MP3 音频大小大很多,这就是压缩格式起的主要作用。


首先,由原始数码设备提供相关的数字信号流,然后经由视频压缩算法,大幅度的减少流的大小,然后交给视频盒子,打上相应的 dtspts 字段,最终生成可用的视频文件。常用的视频格式和压缩格式


视频音频流解析播放过程


图片3.png


文章评论