基于GStreamer的Smooth Streaming插件开发
大幅度的压缩。
AAC 可以支持1 到48 路之间任意数目的音频声道组合、包括15 路低频效果声道、配音/多语音声道，以及15路数据。它可同时传送16套节目，每套节目的音频及数据结构可任意规定。在码率为64kbps 的条件下，AAC 可以提供较好的声音质量。为提高音频编码效率，AAC 采用了许多技术，如霍夫曼编码、相关立体声、声道耦合、反向自适应预测、时域噪声整形、修正离散余弦变换（MDCT）、及混合滤波器组等。
2.3.2 AAC系统的框架
为了允许在音频质量、存储器和处理能力需求之间进行折中，MPEG-2 AAC系统提供了以下三层框架(Profile)：
1.主框架（Main Profile）：在这层框架中，AAC系统能对任何给定的数据率提供质量最好的重建音频。除了增益控制模块以外，AAC系统包含了其他所有模块，使其对于存储器和CPU处理能力的要求是三种框架中最高的。同时，主框架AAC解码器能够对采用低复杂度框架的码流进行解码。
2.低复杂度框架（Low Complexity-LC Profile）：在这层框架中，系统不包括时域预测和增益控制(预处理)模块，并且TNS的阶数也受到限制。低复杂度框架在音频质量很高时，对存储器和CPU处理能力的要求比主框架小。
3.可分级采样频率框架（Scaleable Sampling Rate-SSR Profile）：在这层框架中，增益控制模块是必需的，同时没有预测模块，并且TNS的阶数和信号带宽受限。该框架的复杂度比如前所述的两个框架都要低，而且它能产生一个频率可分级的信号。
2.3.3 AAC音频文件格式的种类
1.音频数据交换格式
音频数据交换格式（ADIF：Audio Data Interchange Format）的特征是可以确定的找到这个音频数据的开始，不需进行在音频数据流中间开始的解码，即它的解码必须在明确定义的开始处进行。故这种格式常用在磁盘文件中。ADIF
12
基于GStreamer的Smooth Streaming插件开发
的数据结构如图2-10所示：
图2-10 ADIF数据结构图
其中结构中的header()为ADIF帧数据的帧头，raw_data_stream()为实际的音频帧数据。ADIF的帧头结构如下图2-11所示[1]：
图2-11 ADIF帧头结构图
2.音频数据传输流格式
音频数据传输流（ADTS：Audio Data Transport Stream）的特征是它是一个有同步字的比特流，解码可以在这个流中任何位置开始。它的特征类似于mp3数据流格式。其数据结构如图2-12所示：
图2-12 ADTS数据结构图
其中syncword为同步字，header()为其帧头结构，error_check()为检错机制，raw_data_block()为实际的ADTS音频帧数据。ADTS格式的帧头结构分为两个部分：固定的帧头结构和可变的帧头结构。
⑴固定帧头。固定头信息中的数据每一帧都相同，都为同步字syncword，帧同步目的在于找出帧头在比特流中的位置，13818-7规定，AAC ADTS格式的帧头为12比特的“1111 1111 1111”。其结构如图2-13所示：
13
基于GStreamer的Smooth Streaming插件开发
图2-13 ADTS固定帧头格式
数据结构中重要属性值的描述：ID为MPEG标示符；protection_absent属性为是否进行误码校验；profile属性即为AAC可供选择的三种框架；sampling_frequency_index
属性为该音频数据的采样率；
channel_configuration属性为该音频数据具有的声道的个数。
⑵可变帧头。可变帧头头信息则在帧与帧之间是变化的。它主要是描述该音频帧数据的长度等相关信息。其数据结构如图2-14所示：
图2-14 ADTS可变帧头格式
其中frame_length属性即为一个ADTS帧数据的长度，包括帧头的长度和帧数据的长度；adts_buffer_fullness属性为帧与帧之间码流的变化；number_of_raw_data_blocks_in_frame属性是描述ADTS帧头中有多少个AAC原始帧。
2.4 流媒体服务器
本文中所使用的媒体服务器是基于HTTP协议由IIS Live Smooth Streaming构建的，然后安装Microsoft Expression Encoder 4软件，该软件实现对源媒体文件按照不同的音视频压缩技术进行编码，最终生成媒体数据片段用于传输。
由于本文主要研究Smooth Streaming协议的通信，故本文中采用的是IIS Smooth Streaming输出格式的媒体数据片段，这些片段采用类似于MP4封装的
14
基于GStreamer的Smooth Streaming插件开发
BOX封装技术进行切片得到的。打开服务器媒体数据文件夹，其结构如图2-15所示：
图2-15 媒体服务器文件结构图
这些文件主要包含视讯清单和具体的媒体数据。媒体服务器中的视讯清单是对该媒体数据中的视频与音频数据的描述，图2-15中7.ismc文件即为该视讯清单；而服务器中的媒体数据是根据不同的视讯品质等级和解析度编码生成的多个视讯档案，其中每个档案的数据以片段的MP4媒体容器格式储存，如图中7_1644.ismv、7_1241.ismv、7_937.ismv、7_708.ismv、7_534.ismv、7_403.ismv、7_305.ismv、7_230.ismv等文件，其中7_1644.ismv为比特率最高的视频数据档案。
该服务器是采用H.264格式对视频数据进行编码的，采用AAC音频中的ADTS格式对音频数据进行编码的。因此在解码过程中，需要用对应的解码格式对视频与音频数据进行解码，才能实现视频的播放。
第三章 流媒体传输协议
3.1 RTP/RTCP传输协议
UDP协议可靠性问题，需要由应用层协议提供相应的差错控制机制给予解决。实时传输协议RTP/RTCP就是为了辅助UDP协议进行实时数据的传输而制定
15
基于GStreamer的Smooth Streaming插件开发
出来的。为了支持网络实时传输服务，提供数据实时传输的标准，1996年IETF(Intemet Engineering Task Force)的视频/音频工作组制订了RTP实时传输协议，并被写入了RFCl889。在RFCl889中RTP被定义为紧密相关的两部分：
(1)实时传输协议RTP(Real—time Transport Protocol)，用来传输具有实时特点的数据。
(2)实时传输控制协议RTCP(RTP Control Protocol)，用来控制服务指令，并在正在进行的会话里传送参加方的信息。
3.1.1 RTP协议的基本概念
RTP协议基于多播或单播网络为用户提供连续媒体数据的实时传输服务，用于实时监控数据传输质量，RTP协议与TCP协议十分相似，只是当差错造成分组丢失时，不要求重发。RTP协议位于传输层之上，它没有连接的概念，虽然它既可以建立在面向连接的协议上，也可以建立在面向无连接的协议上，但是一般来说，RTP是作为实时数据传输而设计的，建立在UDP协议之上，可将它看成一个应用层的协议。
RTP/RTCP/UDP协议一起用于视频音频流的实时传输。其层次结构如图3-1所示：
图3-1 RTP/RTCP协议层次图
RTP为音频、视频等实时数据提供了端对端的网络传输服务，这些服务包括负载类型识别、顺序号、时间戳及传输控制等等。RTP不能提供资源预留服务，而依赖于下层服务来实现。RTP不保证传输的及时性和顺序性，也不假定下层网络是可靠和按序传输的，但是具体的应用可以根据RTP提供的信息自行设定符合应用的特定算法和控制策略。RTP协议一般有两个部分组成：数据报文部分(RTP
16