ffmpeg开发之旅(7)：Android视频直播核心技术(架构)详解
(转载请声明出处：http://blog.csdn.net/andrexpert/article/details/76919535)
一、直播架构解析
目前主流的直播架构中主要有两种方案，即流媒体转发、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颜色格式深度分析，参见我这篇博文：视频直播YUV颜色格式完全解析。
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深度分析，参见我这篇博文：深度解析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格式解析，参见我这篇博文：AAC编码格式分析与MP4文件封装
(5) 重要参数
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(位)的声音已经是普通人类的极限了，更高位数就只能靠仪器才能分辨出来。
其他参数可参考我这篇博文：浅析Camera视频实时采集中涉及的参数配置
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一个通道上传输命令和数据；
参考资料
(1) 详解P2P技术与前景展望
(2)
H.265百度百科
(3) H.265深度解析
(4)
视频直播系统的P2P方式
(5) RTMP、RTSP、HTTP协议区别
(6)
流媒体传输控制协议(RTSP RTP SDP)详解之RTP
(7)
流媒体传输控制协议(RTSP RTP SDP)详解之RTSP
(8)
带你吃透RTMP
(9)
RTMP协议学习总结
(10)
rtmp 协议分析及交互过程