直播流程总结

一.简述总体内容
1.直播流程介绍
2.Mac搭建nginx+rtmp服务器(模拟推流拉流)
3.简单的集成推流拉流(实用篇)
4.好的博客推荐

二.直播流程介绍

1.简单的流程图

2.直播流程

屏幕采集.摄像头采集.可扩展采集->(YUV/RGB.PCM)->美颜.水印.滤镜.可扩展处理->(YUV/RGB.PCM)->[H.265].[H.264].[VP9]->H.264/H.265.ACC->推流->RTMP.FLVTag->流分发->RTMP.HLS/FLV->流播放

3.视频直播,可以分为采集,前处理(美颜等等),编码.推流和传输,服务器处理,解码拉流

1)采集:采集是整个视频推流过程中的第一个环节,它从系统的采集设备中获取原始视频数据,将其输出到下一个环节.视频的采集涉及两个方面数据的采集:音频采集和图像采集,它们分别对应两种完全不同的输入源和数据格式.ios系统因为软硬件种类不多,硬件适配性比较好,所以比较简单.而Android端市面上机型众多,要做些机型的适配工作.PC端是最麻烦的,各种奇葩摄像头驱动.所以现在很多的中小型直播平台,都放弃了PC直播,更有些直播平台直播ios端的视频直播

2)前处理:美颜算法,视频的模糊效果,水印等都是在这个环节做.目前ios端最著名开源框架是GPUImage.其中内置了125种渲染效果,还支持各种脚本自定义.GPUImage所有滤镜介绍都说[80%的主播没有美颜根本没法看],美颜是直播产品中最常用的功能之一
美颜的理解
处理[视频 (美颜.水印.自定义滤镜.自定义处理)][音频(混音.降噪.声音特效.自定义处理)]

3)编码:对流媒体传输来说,编码也非常重要,它的编码性能.编码速度和编码压缩比会直接影响整个流媒体传输的用户体验和传输成本.重难点在于要在分辨率,频率,GOP等参数设计上找到最佳平衡点.ios8之后,Apple开发了VideoToolBox.framework,可以直接进行硬编码,这也是为什么现在大多数直播平台最低只支持ios8的原因之一,iOS端硬件兼容性比较好,可以直接采取硬编码,常用的编码有:H265

4)推流和传输:这块一般都是交给CDN服务商.CDN只提供带宽和服务器之间的传输,发送端和接收端的网络连接抖动缓存还是要自己实现的.目前国内最大的CDN服务商应该是网宿.传输协议一般是RTMP,HLS,FLV

5)服务器处理:需要在服务器做一些处理工作,让推送上来的流适配各个平台各种不同的协议,比如:RTMP,HLS,FLV…

6)解码拉流:推流需要编码,同样的拉流解码是必须的.iOS端兼容较好,Android依然大坑.这块的难点在于音画同步,目前很多直播平台这块是硬伤.国内比较好的开源项目应该是B站开源的ijkplayer.斗鱼就是基于ijkplayer的,本项目也是基于ijkplayer的.

7)延时优化

编码优化

_1.确保Codec开启了最低延迟的设置.Codec一般都会有低延迟优化的开启,对于H.264来说其效果尤其明显.很多人可能不知道H.264的解码器正常情况下会在显示之前缓存一定的视频帧,对于QCIF分辨率大小的视频(176 x 144)一般会缓存16帧,对于720p的视频则缓存5帧.对于第一帧的读取来说,这是一个很大的延迟.如果你的视频不是使用H.264来编码压缩的,确保没有使用B帧,它对延迟也会有较大的影响,因为视频中B帧的解码依赖于前后的视频帧,会增加延迟.

_2.编码器一般都会有码控造成的延迟,一般也叫做初始化延迟或者视频缓存验证器VBV的缓存大小,把它当成编码器和解码器比特流之间的缓存,在不影响视频质量的情况下可以将其设置得尽可能小也可以降低延迟.

_3.如果是仅仅优化首开延迟,可以在视频帧间插入较多的关键帧,这样客户端收到视频流之后可以尽快解码.但如果需要优化传输过程中的累计延迟,尽可能少使用关键帧也就是I帧(GOP变大),在保证同等视频质量的情况下,I帧越多,码率越大,传输所需的网络宽带越多,也就意味着累计延迟可能越大.这个优化效果可能在秒级延迟的系统中不是很明显,但是在100ms甚至更低的系统中就会非常明显.同时,尽量使用ACC-LC codec来编码音频,HE-ACC或者HE-ACC2虽然编码效率高,但是编码所需要时间更长,而产生更大体积的音频造成的传输延迟对于视频流的传输来说影响更小.

_4.不使用视频MJPEG的视频压缩格式,至少使用不带B帧的MPEG4视频压缩格式(Simple profile),甚至最好使用H.264baseline proile(X264还有一个[-tune zerolatency]的优化开关).这样一个简单的优化可以降低延迟,因为它能够以更低的码率编码全帧率视频.

_5.如果使用了FFmpeg,降低[-probesize]和[-analyze duration]参数的值,这两个值用于视频帧信息监测和用于监测的时长,这两个值越大对编码越延迟的影响越大,在直播场景下对于视频流来说analyzeduration参数甚至没有必要设定.

_6.固定码率编码CBR可以一定程度上消除网络抖动影响,如果能够使用可变码率编码VBR可以节省一些不必要的网络宽带,降低一定的延迟.因此建议尽量使用VBR进行编码

#

传输协议优化

_1.在服务端节点和节点之间尽量使用RTMP而非基于HTTP的HLS协议进行传输,这样可以降低整体的传输延迟.这个主要针对终端用户使用HLS进行播放的情况.
_2.如果终端用户使用RTMP来播放,尽量在靠近推流端的收流节点进行转码,这样传输的视频流比原始视频流更小.
_3.如果有必要,可以使用定制的UDP协议来替换TCP协议,省去弱网环节下的丢包重传可以降低延迟,它的主要缺点在于,基于UDP协议进行定制的协议的视频流的传输和分发不够通用,CDN厂商支持的是标准的传输协议.另一个缺点在于可能出现丢包导致的花屏或者模糊(缺少关键帧的解码参考),这就要求协议定制方在UDP基础之上做好丢包控制.

#

传输网络优化

_1.我们曾经介绍过七牛直播的实时流传输网络,它是一种新型的节点自组织的网状传输网络,既适合国内多运营商网络条件下的传输优化,也适合众多海外直播的需求.
_2.在服务端节点中缓存当前GOP,适合播放器端优化视频首开时间.
_3.服务端实时记录每个视频流流向每个环节时的秒级帧率和码率,实时监控码率和帧率的波动.
_4.客户端(推流和播放)通过查询服务端准实时获取当前最优节点(5秒一次),准实时下线当前故障节点和线路.

#

推流丶播放优化

_1.考察发送端系统自带的网络buffer大小,系统可能在发送数据之前缓存数据,这个参数的调优也需要找到一个平衡点.
_2.播放端缓存控制对于视频的首开延迟也有较大影响,如果仅优化首开延迟,可以在0缓存情况下在数据到达的时候立即解码.但如果在弱网环境下为了消除网络抖动造成的影响,设置一定的缓存也有必要,因此需要在直播的稳定性和首开延迟优化上找到平衡,调整优化缓冲区大小这个值.
_3.播放端动态buffer策略,这是上面播放端缓存控制的改进版本,如果只是0缓存和固定大小的缓存之间进行选择找到平衡,最终还是会选择一个固定大小缓存,这对亿级的移动互联网终端用户来说并不公平,他们不同的网路状况决定了这个固定大小的缓存并不完全适合.因此,我们可以考虑一种[动态buffer策略],在播放器开启的时候采用非常小甚至0缓存策略,通过对下载首片视频的耗时来决定下一个时间片的缓存大小,同事在播放过程中实时监测当前网络,实时调整播放过程中缓存的大小.这样即可做到极低的首开时间,又可能够尽量消耗网络抖动造成的影响.
_4.动态码率播放策略.除了动态调整buffer大小的策略之外,也可以利用实时监测的网路信息来动态调整播放过程中的码率,在网络带宽不足的情况下降低码率进行播放,减少延迟.