频道栏目
首页 > 程序开发 > 移动开发 > Android > 正文
ffmpeg开发之旅(7):Android视频直播核心技术(架构)详解
2017-08-10 10:36:35      个评论    来源:蒋东国的博客  
收藏   我要投稿

ffmpeg开发之旅(7):Android视频直播核心技术(架构)详解

一、直播架构解析

目前主流的直播架构中主要有两种方案,即流媒体转发、P2P。流媒体转发,是一种在视频直播中以流的方式将连续的音、视频数据经编码压缩后传输到流媒体服务器,用户实时从服务器获取流媒体资源,而不必要等待整个文件下载文件完毕的C/S架构视频直播方案;P2P直播,是一种建立在P2P技术基础上的视频直播方案,它规定客户端之间使用一定协议来交换和共享直播数据,通过减少对服务器的数据请求,以降低服务端的I/O带宽等方面压力,从而削减服务器带宽成本,降低客户端卡播率。
1. 流媒体转发
(1) YUV/RGB颜色格式
类似于RGB,YUV也是一种颜色格式,通常我们手机摄像头采集的每一帧图像就是YUV格式的,它分别由Y、U、V分量组成,其中“Y”表示明亮度(Luminance或Luma),也就是灰阶值;而“U”和“V”表示的则是色度(Chrominance或Chroma),作用是描述影像色彩及饱和度,用于指定像素的颜色。 因此,YUV是一种亮度信号Y和色度信号U、V是分离的色彩空间,它主要用于优化彩色视频信号的传输,使其向后相容老式黑白电视,且与RGB要求三个独立的视频信号同时传输相比,它最大的优点在于只需占用极少的频宽,非常适用于流媒体传输。
YUV格式分为两种类型,即Packet(包)和Plannar(平面)。Packet类型是将Y、U、V分量存储在同一个数组中,每个像素点的Y、U、V是连续交错存储的,常见的采样格式有NV21、NV12;Plannar类型是将Y、U、V分量分别存储在三个独立的数组中,且先连续存储所有像素点的Y分量,紧接着存储所有像素点的U分量,最后存储所有像素点的V分量,常见的采样格式有YV12、I420。关于YUV颜色格式深度分析。
(2) H.264视频编码技术
H.264是MPEG-4的第十部分,是由VCEG和MPEG联合提出的高度压缩数字视频编码器标准,它的出现就是为了更大程度地对原始YUV图像进行压缩编码,同时能够保证视频传输性能和画面质量。H.264具有低码率、高压缩、高质量的图像、容错能力强、网络适应性强等特点,它最大的优势拥有很高的数据压缩比率,在同等图像质量的条件下,H.264的压缩比是MPEG-2的两倍以上。
H.264编码框架分为两层:VCL、NAL。VCL(Video Coding Layer,视频编码层),负责高效的视频内容表示;NAL(Network Abstraction Layer,网络抽象层),负责以网络所要求的恰当的方式对数据进行打包和传送。在H.264协议里定义了三种帧,完整编码的帧叫I帧(关键帧),参考之前的I帧生成的只包含差异部分编码的帧叫P帧,还有一种参考前后的帧编码的帧叫B帧。H.264编码采用的核心算法是帧内压缩和帧间压缩。其中,帧内压缩是生成I帧的算法,它的原理是当压缩一帧图像时,仅考虑本帧的数据而不用考虑相邻帧之间的冗余信息,由于帧内压缩是编码一个完整的图像,所以可以独立的解码显示;帧间压缩是生成P、B帧的算法,它的原理是通过对比相邻两帧之间的数据进行压缩,进一步提高压缩量,减少压缩比。关于H.264深度分析。
(3) H.265视频编码技术
H.265,又称HEVC(High Efficiency Video Coding,高效视频编码),是继H.264之后所制定的新的视频编码标准,它是对H.264编码标准的改进,包括提高压缩效率、提高鲁棒性和错误恢复能力、减少实时的时延、降低复杂度等,其目的是旨在在有限带宽下传输更高质量的网络视频,仅需原先的一半带宽即可播放相同质量的视频。比如H.263在传输码率为2~4Mbps时只能传输标清视频,H.264可以以低于2Mbps的传输码率传输标清视频,而H.264在低于1.5Mbps的传输码率情况下就能传输1080P全高清视频,并且同等分辨率情况下,码率减少51-74%时H.265编码视频的质量还能与H.264编码视频近似,甚至效果更好。不同编码方式复杂度和所需传输码率对比如下图:
(4) AAC音频编码技术
高级音频编码(AdvancedAudio Coding,AAC)一种基于MPEG-4的音频编码技术,它由杜比实验室、AT&T等公司共同研发,目的是替换MP3编码方式。作为一种高压缩比的音频压缩算法,AAC的数据压缩比约为18:1,压缩后的音质可以同未压缩的CD音质相媲美。因此,相对于MP3、WMA等音频编码标准来说,在相同质量下码率更低,有效地节约了传输带宽,被广泛得应用于互联网流媒体、IPTV等领域(低码率,高音质)。
音频数据在压缩编码之前,要先进行采样与量化,以样值的形式存在。音频压缩编码的输出码流,以音频帧的形式存在。每个音频帧包含若干个音频采样的压缩数据,AAC的一个音频帧包含960或1024个样值,这些压缩编码后的音频帧称为原始数据块(RawData Block),由于原始数据块以帧的形式存在,即简称为原始帧。原始帧是可变的,如果对原始帧进行ADTS的封装,得到的原始帧为ADTS帧。 ADTS封装格式的码流以帧为单位,一个ADTS帧由帧头、帧净荷组成。其中,帧头定义了音频采样率、音频声道数、帧长度等关键信息,它由两部分组成,共占7个字节:固定头信息adts_fixed_header、可变头信息adts_variable_header。固定头信息中的数据每一帧都相同,而可变头信息则在帧与帧之间可变;帧净荷主要由1~4个原始帧组成,它包含的数据用于解析与解码。关于AAC格式解析。
a) 帧率
帧率是指在每秒内传输的图像帧数量,单位为fps,它的大小影响画面流畅度,且画面流畅程度成正比。通常,帧率越大画面越流畅,帧率越小画面越有跳动感(卡顿)。
b) 分辨率
就是屏幕图像的精密度,显示器所能显示的像素的多少。可以把整个图像想象成是一个大型的棋盘,而分辨率的表示方式就是所有经线和纬线交叉点的数目。以分辨率为1024×768的屏幕来说,(即每一条水平线上包含有1024个像素点,共有768条线,总像素1024x768个),即扫描列数为1024列,行数为768行。分辨率影响图像大小,与图像大小成正比:分辨率越高,图像越大;分辨率越低,图像越小。
c) 码率(视频)/比特率(音频)
视频中比特率又被称为码率,是指码率就是数据传输时单位时间传送的数据位数,单位是Kbps即千位每秒(=1000*1bps)。它表示经过编码(压缩)后的音、视频数据每秒钟需要用多少个比特来表示。比特率越高,传输数据就越大,音、视频的质量就越好,但编码后的文件就越大。
d) 采样率
采样率定义了每秒从连续信号中提取并组成离散信号的采样个数,它用赫兹(Hz)来表示。针对于音频而言,采样率则为计算机每秒钟采集声音样本的数量,数量越大声音质量就越好,体积随之也会增大。常见的有8000HZ、22050HZ、44100HZ、16000HZ、96000Hz等。
e) 采样精度
每一个采样点都需要用一个数值来表示大小,这个数值的数据类型大小可以是4bit、8bit、16bit、32bit等,位数越多,表示得就越精细,声音质量自然就越好。由于受人的器官的机能限制,16bit(位)的声音已经是普通人类的极限了,更高位数就只能靠仪器才能分辨出来。

2. P2P视频直播

3. 两者优缺点对比
(1) P2P点对点

P2P视频直播是客户端之间使用一定协议,交换和共享直播数据,通过减少对服务器的数据请求,来降低服务端的I/O带宽等方面压力,从而削减服务器带宽成本,降低客户端卡播率。在整个网络网框架中,每个客户端(节点)是对等的,即同时具有Client和Server的特点。常见开源框架:WebRTC
优点:服务器压力小,节省带宽成本,延时低,响应快,秒传,适合非实时的数据传输;
缺点:最多4~8个人同时在线观看,对节点带宽要求较高,服务器视频录制不好处理。IPv4网络环境制约,UDP打洞穿透效率问题,打洞不通要服务器relay;
应用场景:安防
(2) 流媒体转发
常见流媒体直播协议都属于C/S型,即所有客户端通过指定协议,从服务端获取直播数据。当客户端数量达到一定规模后,服务端将承受巨大的I/O和带宽压力。若服务器无法及时处理客户请求,客户端卡播率急剧上升,从而影响用户观看体验。常见开源框架:ffmpeg
优点:稳定可靠,支持量大,可以实现一个人播,百万人同时在线观看,且服务器可以进行视频录制存储,用户体验好;
缺点:用户数量增加后,对服务器的资源和带宽等压力大幅增加,服务器成本高,1~3秒延时;
应用场景:视频会议


二、流媒体协议架构解析
1. RTP协议
RTP(Real-time Transport Protocol,实时传输协议)是一种基于UDP的网络传输协议,它介于应用层和传输层之间,负责对流媒体数据进行封包并实现媒体流的实时传输。RTP数据协议本身并不能按顺序传送数据包提供可靠的传送机制,也不提供流量控制或拥塞控制,它依靠RTCP提供这些控制服务。对于那些丢失的数据包,不存在由于超时检测而带来的延时,而丢失的包也可以由上层根据其重要性来选择性重传。比如对于I帧、P帧、B帧数据,当丢失的是P帧或B帧时,可以不用选择重传,这样画面只会短暂的不清晰,但是却保障了传输的实时性。
(1) RTP工作机制
当应用程序与流媒体服务器建立一个RTP会话后,应用程序会确定一对目的传输地址,它由一个网络地址和一对端口组成。其中,这一对端口将分别分配给RTP包和RTCP包,通常RTP数据包发向偶数的UDP端口,而对应的控制信号RTCP数据发向相邻的奇数端口。RTP包发送过程:
首先,RTP协议从上层获取编码好的流媒体信息码流,如H.264、AAC,封装成RTP数据包;RTCP协议从上层接收控制信息,封装成RTCP控制包;
然后,RTP将RTP 数据包发往UDP端口对中偶数端口;RTCP将RTCP控制包发往UDP端口对中的接收端口;
(2) RTP分组首部格式
2. RTCP协议
RTCP(Real-Time Transport Control Potocol,实时传输控制协议)是RTP协议的姐妹协议,它本身并不传输数据,而是与RTP各占一个端口,一起协作将流媒体数据进行打包发送,为RTP流媒体流提供信道外控制。由于RTP本身无法按序传输数据包提供可靠保证,也不提供流量控制和拥塞控制,这些都由RTCP来负责完成。通常RTCP会采用与RTP相同的分发机制,向会话中的 所有成员周期性地发送控制信息,应用程序通过接收这些数据,从中获取会话参与者的相关资料,以及网络状况、分组丢失概率等反馈信息,从而能够对服务质量进 行控制或者对网络状况进行诊断。因此,各参与者可以利用这些信息动态地改变传输速率,甚至改变有效载荷类型。RTP和RTCP配合使用,它们能以有效的反馈和最小的开销使传输效率最佳化,因而特别适合传送网上的实时数据。总之,RTSP发起/终结流媒体、RTP传输流媒体数据 、RTCP对RTP进行控制,同步。
RTCP也是用UDP来传送的,但RTCP封装的仅仅是一些控制信息,因而分组很短,所以可以将多个RTCP分组封装在一个UDP包中。RTCP有如下五种分组类型。
类型缩写表示用途200SR(Sender Report)发送端报告201RR(Receiver Report)接收端报告202SDES(Source Description Items)源点描述203BYE结束传输204APP特定应用
3. RTSP协议
RTSP(Real Time Stream Protocol,实时流协议)是一种基于文本的应用层协议,主要用于C/S模型建立实时流会话。RTSP协议是一个多媒体播放控制协议,用于控制具有实时特性的数据发送,但它本身并不传输数据,而是对流媒体提供诸如播放、暂停、快进等操作。RTSP协议定义了一对多应用程序如何有效地通过IP网络传送流媒体信息数据,它在TCP/IP体系中位于RTP和RTCP协议之上,主要通过TCP或RTP/RTCP完成数据传输,具有易解析、安全、独立于传输、多服务器支持等特点。
(1) RTSP URL语法结构
玩过VCL的朋友应该知道,当在PC或移动端点播实时流媒体时,我们需要在VCL或点播APP中输入URL地址才能观看实时视频。VCL中配置RTSP URL如下:
格式:(“rtsp:”| “rtspu:”) “//” host [“:”port”] /[abs_path]/content_name
rtsp : 表示协议类型,类似于http
host: 表示流媒体服务器IP地址或有效的域名,如192.192.191.104;
port: 表示端口号,rtsp协议的缺省端口号为554;
abs_path : 表示流媒体服务器中媒体流资源标识,如123456;
(2) RTSP报文结构
与Http协议类似,RTSP也是一种基于文本的协议,它的报文类型同样包括请求报文和响应报文。RTSP报文由三部分组成,即开始行、首部行和实体主体,请求报文是指从客户向服务器发送请求报文,响应报文是指从服务器到客户的回答。
RTSP请求报文结构如下,RTSP请求报文的方法包括:OPTIONS、DESCRIBE、SETUP、TEARDOWN、PLAY、PAUSE、GET_PARAMETER和SET_PARAMETER。

响应报文的开始行是状态行,RTSP响应报文的结构如下:
(3) RTSP会话基本过程
首先,客户端向服务器发送一个RTSP描述命令(DESCRIBE),流媒体服务器确认收到后将向客户端返回一个SDP描述来进行反馈,反馈的信息包括流量数、媒体类型等;
其次,客户端接收到SDP后对其进行分析,并未会话中的每一个流发送一个RTSP建立命令,RTSP建立命令告诉服务器端用于接收流媒体数据的端口,至此RTSP会话建立完成;
第三,客户端向流媒体服务器发送一个播放命令(PLAY),服务器就开始在UDP上传送媒体流(RTP包)到客户端。在播放过程中,客户端可以向服务器发送命令来控制快进、快退、暂停等操作;
第四,客户端向服务器发送终止命令(TERADOWN)结束流媒体会话。
Wireshark抓包情况如下:
4. RTMP协议
RTMP(Real Time Messaging Protocol,实时消息传输协议)属于五层TCP/IP体系中的应用层,它是基于TCP传输的流媒体协议,默认端口为1935,是一个协议族,包括RTMP基本协议及RTMPT、RTMPS、REMPE等多种变种。RTMP协议是Adobe System公司为Flash播放器和FMS服务器之间音视频和数据传输开发的私有协议,用来解决多媒体数据传输流的多路复用(Multiplexing)和分包(packetizing)的问题,基于此协议,abobe提供完善的音视频解决方案,比如点播、直播、互动。
(1) RTMP协议传输原理
RTMP传输媒体数据的过程中,会先后经历"握手-建立连接-建立流-播放"步骤。发送端首先把媒体数据封装成消息,然后把消息分割成消息块,最后将分割后的消息块通过TCP协议发送出去。接收端在通过TCP协议收到数据后,首先把消息块重新组合成消息,然后通过对消息进行解封装处理就可以恢复出媒体数据。
消息(Message)
消息是RTMP协议中基本的数据单元。不同种类的消息包含不同的Message Type ID,代表不同的功能。RTMP协议中一共规定了十多种消息类型,分别发挥着不同的作用。例如,Message Type ID在1-7的消息用于协议控制,这些消息一般是RTMP协议自身管理要使用的消息,用户一般情况下无需操作其中的数据。Message Type ID为8,9的消息分别用于传输音频和视频数据。Message Type ID为15-20的消息用于发送AMF编码的命令,负责用户与服务器之间的交互,比如播放,暂停等等。消息首部(Message Header)有四部分组成:标志消息类型的Message Type ID,标志消息长度的Payload Length,标识时间戳的Timestamp,标识消息所属媒体流的Stream ID。消息的报文结构如下图所示:

消息块(Message Chunk)
在网络上传输数据时,消息需要被拆分成较小的数据块,才适合在相应的网络环境上传输。RTMP协议中规定,消息在网络上传输时被拆分成消息块(Chunk),默认大小为128字节。消息块首部(Chunk Header)有三部分组成:用于标识本块的Chunk Basic Header,用于标识本块负载所属消息的Chunk Message Header,以及当时间戳溢出时才出现的Extended Timestamp。消息块的报文结构如下图所示:

(2) RTMP协议"握手"流程分析
一个RTMP连接以"握手"开始,双方会分辨发送带下固定的三个消息块(数据块),比如客户端会向服务器发送C0、C1、C2消息块,服务器收到客户端发来的消息块后,会向客户端发送S1、S2、S3消息块,具体流程如下:
首先,客户端向服务器发送C0、C1消息块,服务器收到C0或C1后,会向客户端发送S0和S1;
其次,当客户端收齐S0、S1消息块后,再向服务器发送C2消息块。当服务器收齐C0和C1后,再向客户端发送S2消息块;
最后,当客户端和服务器分别收到S2和C2后,握手完成。

5. RTMP协议、RTSP协议、HTTP协议区别
这三个协议都属于TCP/IP五层体系中应用层协议,通常RTMP、RTSP协议用于直播,HTTP用于点播。它们的主要区别如下:
(1) RTMP协议
a) 是流媒体协议;
b) RTMP协议是Adobe的私有协议,未完全公开;
c) RTMP协议一般传输flv、f4v格式的流式文件;
d) RTMP使用TCP传输,只需要1个通道上传命令和数据;
(2) RTSP协议
a) 是流媒体协议,RTSP为每个会话保持状态;
b) RTSP协议是共有协议,有专门机构做维护;
c) RTSP协议一般传输ts、mp4格式的数据,但mp4不是流式文件,必须有索引才能任意seek;
d) RTSP使用UDP传输,需要2-3个通道来传输命令和数据,即数据和命令通道分离;
(3) HTTP协议
a) 不是流媒体协议,HTTP是无状态协议;
b) HTTP协议是共有协议,有专门机构做维护;
c) HTTP协议没有特定的传输流;
d) HTTP一般在TCP一个通道上传输命令和数据;

点击复制链接 与好友分享!回本站首页
上一篇:Android相机预览方向
下一篇:android兼容emoji显示以及检测是否支持emoji
相关文章
图文推荐

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站