Android直播技术之(三) : 推流

1. 首先我们先介绍下推流协议以及他们在直播领域的现状和优缺点
   *RTMP
   *WebRTC
   *基于UDP的私有协议

(1 : RTMP):
它是Real Time Messaging Protocol(实时消息传输协议)的字母缩写.该协议基于TCP,是一个协议族,包括RTMP及本协议及RTMPT/RTMPS/RTMPE等多个变种协议.RTMP是一种被设计用来进行实时数据通信的网络协议,主要用在Flash平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信.支持该协议的软件包括Adobe Media Server/Ultrant Media Server/Red5等
RTMP是目前主流的流媒体传输协议,广泛应用于直播领域,可以说市面上绝大多数的直播产品都采用了这个协议
优点:
(1)对CDN友好,主流的CDN厂商都支持该协议
(2)协议简单,在各个平台上容易实现
缺点:
(1)基于TCP,传输成本高,在弱网环境丢包率高的情况问题明显
(2)不支持浏览器推送
(3)Adobe私有协议,Adobe已经不再更新该协议

(2 : WebRTC):
WebRTC名称源自Web Real Time Communication (网页即时通信),是一个支持Web浏览器进行实时语音或视频对话的API,它于2011年开源,并在Google/Mozilla等支持下被纳入万维网联盟的W3C推荐标准,目前主要应用于视频会议和连麦中,WebRTC协议分层如图:

优点:
(1)W3C标准,主流浏览器支持程度较高
(2)Google背后支撑,并针对各平台有参考实现
(3)底层基于SRTP和UDP,在弱网情况下优化空间大
(4)可以实现点对点通信,通信双方延时低
缺点:
ICE/STUN/TURN等传统CDN没有提供类似的服务

(3 : 基于UDP的私有协议)
有些直播应用会使用UDP作为底层协议开发自己的私有协议,由于UDP在弱网环境下的优势,因此实现一些定制化的调优可以比较好的优化弱网效果,但同样因为其是私有协议会有现实问题.
优点:
有更多的空间进行定制化优化
缺点
(1)开发成本高
(2)对CDN不友好,需要自建CDN或与CDN达成协议
(3)独立作战,无法和社区一起演进

2. 我们再来聊聊推流过程
   推流过程就是把编码后的数据打包并通过直播协议发送给流媒体服务器的过程,如下图:
   
   (1)经过输出设备得到原始采样数据-------视频数据(YUV)和音频数据(PCM)
   (2)使用硬编码或软编码来编码音视频数据
   (3)分别得到已编码的H.264视频数据和AAC音频数据
   (4)将以编码的音视频数据封装成不同的视频封装格式的数据文件(如:FLV/TS/MPEG-TS)
   (5)使用HLS协议的时候加上这一步(HLS分段生成策略及m3u8索引文件)
   (6)通过流媒体协议上传到服务器
   (7)服务器通过相关协议对内容进行分发
   以上就是推流过程了

3. 最后再说一下推流优化
   在推流过程中我们经常会早于网络不好/断流的情况,所以需要一定的策略.在推流端ping视频中心地址,测试是否有丢包现象,同事在网络抖动时需要动态调整一些参数以便推流,在网络断后重连时,需要重新优化发送音频数据,保证用户能听到声音.视频数据岁后到达,使观众看到画面变化,并逐步回归到音视频同步