薛瑩瑩

（河南博物院，河南 鄭州450002）

1 引言

流媒體技術(shù)已經(jīng)成為現(xiàn)在最熱門的技術(shù)之一，它不同于傳統(tǒng)媒體，改變了以往人們獲取多媒體信息是需要等待多媒體文件全部下載之后再播放的方式。用戶可以一邊解壓播放前傳送過來的數(shù)據(jù)包，一邊下載后續(xù)的數(shù)據(jù)包，不必等待整個(gè)文件下載完畢。目前，流媒體以其特有的廣泛性和交互性逐漸成為互聯(lián)網(wǎng)應(yīng)用的主流。因此，開展流媒體相關(guān)理論的研究，不僅可以促進(jìn)流媒體理論本身的發(fā)展，而且對(duì)音視頻直播、點(diǎn)播的發(fā)展也具有重要的推動(dòng)作用。

2 流媒體常見文件格式

實(shí)現(xiàn)流式在線直播視頻文件的保存需要對(duì)流媒體的文件格式進(jìn)行識(shí)別，所以必須深入了解常見流媒體文件的內(nèi)部組成結(jié)構(gòu)，從而獲取每一種文件區(qū)別于其他文件的特征信息，以保證不同格式的文件按照其相應(yīng)的規(guī)范進(jìn)行保存。

2.1 RM格式

RM（RealMedia）文件由3部分內(nèi)容組成：報(bào)頭部分、數(shù)據(jù)部分和索引部分[1-2]。其基本組成單位是塊（chunk），如圖1所示，每個(gè)塊包括以下字段：四字節(jié)的文件標(biāo)識(shí)符、四字節(jié)的數(shù)據(jù)大小和數(shù)據(jù)塊部分。

圖1 RM文件塊示意圖[2]

2.1.1 報(bào)頭部分（Section）

RM的報(bào)頭包括以下4種：RM文件報(bào)頭(RealMedia文件的第一個(gè)塊)、屬性報(bào)頭（PropertiesHeader）、媒體屬性報(bào)頭（Media Properties Header）、內(nèi)容描述報(bào)頭（Content Description Header）。由 于RM文 件 使 用 四 字 符 編 碼（.RMF）來標(biāo)識(shí)文件，所以RM文件報(bào)頭必須是媒體文件的第一個(gè)塊。

2.1.2 數(shù)據(jù)部分（Data Section）

RM文件的數(shù)據(jù)部分由標(biāo)志數(shù)據(jù)塊開始的數(shù)據(jù)部分報(bào)頭和包含媒體數(shù)據(jù)的媒體數(shù)據(jù)包2部分組成。

2.1.3 索引部分（Index Section）

RM文件的索引部分由索引塊報(bào)頭和索引記錄2部分組成。

2.2 ASF格式

ASF（Advanced Streaming Format）是Microsoft公司推出的，在Internet上實(shí)時(shí)傳播多媒體的技術(shù)標(biāo)準(zhǔn)[3-4]。

ASF文件由文件頭對(duì)象（Head Object），數(shù)據(jù)對(duì)象（Data Object）和可選 的索 引 對(duì)象（Index Object）3部分組成[5]。ASF文件組成結(jié)構(gòu)如圖2所示。

圖2 ASF文件結(jié)構(gòu)[3-4]

文件頭對(duì)象用于描述文件的全局信息，并且是文件中唯一一個(gè)可以嵌套其它次級(jí)對(duì)象的頂級(jí)對(duì)象。數(shù)據(jù)對(duì)象以固定大小的數(shù)據(jù)包來存儲(chǔ)多媒體數(shù)據(jù)，通常包含一個(gè)音頻流和若干個(gè)視頻流。索引對(duì)象為可選項(xiàng)，用于保存時(shí)間與媒體數(shù)據(jù)位置的映射信息，以便實(shí)現(xiàn)電影播放時(shí)的拖放功能。

2.3 MOV格式

MOV（Movie digitalvideo technology）是由Apple公司推出的流媒體視頻格式，使用這種文件格式不僅可以存儲(chǔ)單個(gè)的媒體內(nèi)容，而且能夠保存對(duì)該媒體作品的完整描述[6]。

QuickTime基本的存儲(chǔ)結(jié)構(gòu)有2種：標(biāo)準(zhǔn)原子（Classic Atom）和QT原子（QuickTime Atom）。QT原子容器（QuickTime Atom Containers）是QT原子的屬性分層結(jié)構(gòu)，提供在QuickTime中存儲(chǔ)信息的基本結(jié)構(gòu)。

2.3.1 原子

原子分為報(bào)頭和原子數(shù)據(jù)2部分。其中報(bào)頭又包含數(shù)據(jù)類型和數(shù)據(jù)大小信息。

2.3.2 QuickTime原子容器

QuickTime原子容器是QT原子的屬性分層結(jié)構(gòu)。每個(gè)QT原子包含數(shù)據(jù)或其它原子。如果一個(gè)原子包含其他原子，那么它就是雙親原子（ParentAtom），被包含的原子叫做子原子（Child Atom）。每個(gè)雙親原子的子原子由Atom類型和Atom ID唯一標(biāo)志。包含數(shù)據(jù)的QT原子叫做葉原子（Leaf Atom）。

3 三種文件格式的特性對(duì)照

下面將從以下幾個(gè)方面對(duì)上述3種常見的流媒體文件格式的特性進(jìn)行比較分析：

通過以上分析可以發(fā)現(xiàn)：

①跨平臺(tái)：MOV格式和RM格式不受系統(tǒng)平臺(tái)的約束，可以跨平臺(tái)應(yīng)用。而ASF文件只支持Windows平臺(tái)。

②支持的類型：Real Network能支持其他2種格式，而微軟和Apple公司則堅(jiān)持死守自己的陣地。

③擴(kuò)展性：MOV文件和ASF文件采用的是將媒體信息和媒體數(shù)據(jù)分開的方式，便于擴(kuò)展。RM擴(kuò)展性較差。

④復(fù)雜性：MOV文件中原子之間為樹狀結(jié)構(gòu)，這種樹狀結(jié)構(gòu)給MOV文件帶來強(qiáng)大的功能和兼容性的同時(shí)也使得文件結(jié)構(gòu)變的復(fù)雜、冗余較多。RM文件和ASF文件結(jié)構(gòu)相對(duì)簡(jiǎn)單。

4 文件格式識(shí)別與數(shù)據(jù)存儲(chǔ)模塊的實(shí)現(xiàn)

4.1 緩沖區(qū)設(shè)計(jì)

緩沖區(qū)是實(shí)現(xiàn)流媒體數(shù)據(jù)存儲(chǔ)的重要基礎(chǔ)，它的結(jié)構(gòu)直接決定了流媒體視頻圖像的保存系統(tǒng)中媒體數(shù)據(jù)的讀寫方式。為了適合網(wǎng)絡(luò)傳輸?shù)奶攸c(diǎn)，本文設(shè)計(jì)了環(huán)形隊(duì)列緩沖區(qū)，滿足了在緩沖區(qū)內(nèi)對(duì)數(shù)據(jù)進(jìn)行讀寫操作的需要。

該緩沖區(qū)是一個(gè)先進(jìn)先出隊(duì)列，包括讀指針和寫指針2個(gè)指針。通過移動(dòng)讀指針和寫指針來實(shí)現(xiàn)緩沖區(qū)數(shù)據(jù)的讀取和寫入。

該環(huán)形隊(duì)列的特點(diǎn)是：內(nèi)存空間大小固定，不需要對(duì)內(nèi)存進(jìn)行動(dòng)態(tài)的釋放和分配，并且內(nèi)存空間可以反復(fù)使用。隊(duì)列滿的情況：Front追上Rear時(shí)；隊(duì)列為空的情況：Rear追上Front時(shí)。

對(duì)該緩沖區(qū)開辟了排序線程和存儲(chǔ)線程2個(gè)線程。排序線程的主要功能是負(fù)責(zé)將已經(jīng)過濾的數(shù)據(jù)包放入緩沖區(qū)中，并判斷其傳輸層協(xié)議是TCP還是UDP。如果是TCP數(shù)據(jù)包，則對(duì)TCP數(shù)據(jù)包進(jìn)行排序；反之，直接進(jìn)行解析保存。存儲(chǔ)線程的主要功能是對(duì)已經(jīng)有序數(shù)據(jù)包進(jìn)行解析，去除首部，提取出音視頻數(shù)據(jù)并將數(shù)據(jù)寫入視頻文件。

4.2 文件格式的識(shí)別

文件格式的識(shí)別是實(shí)現(xiàn)在線直播視頻文件實(shí)時(shí)接收的重要環(huán)節(jié)。只有正確識(shí)別了服務(wù)器所傳輸?shù)奈募袷讲拍軐⒂行лd荷按照相應(yīng)的文件格式進(jìn)行存儲(chǔ)。通過對(duì)目前常見文件格式的分析可知，每種文件格式都有其特殊標(biāo)志，不隨文件擴(kuò)展名以及采用的音視頻壓縮算法改變，即文件格式是一種帶有特殊標(biāo)識(shí)的“容器”。因此本文通過提取每個(gè)媒體文件的唯一特征標(biāo)識(shí)符，來實(shí)現(xiàn)對(duì)流媒體文件格式的識(shí)別。流程圖如圖3所示。

4.3 數(shù)據(jù)包出錯(cuò)或亂序處理

UDP協(xié)議是無連接的不可靠傳輸協(xié)議，對(duì)數(shù)據(jù)包的到達(dá)順序以及是否正確并不關(guān)心，協(xié)議本身并不能保證所有數(shù)據(jù)包都能夠順利到達(dá)客戶端。所以對(duì)UDP數(shù)據(jù)包出現(xiàn)缺失的情況，采用的是直接丟棄的方法。

TCP協(xié)議是面向連接的可靠傳輸協(xié)議，在網(wǎng)絡(luò)傳輸過程中，由于各個(gè)IP數(shù)據(jù)包經(jīng)過的路由不同，有可能先（后）發(fā)送的數(shù)據(jù)包后（先）到達(dá)，導(dǎo)致數(shù)據(jù)包有可能出現(xiàn)亂序的情況，所以需要對(duì)IP數(shù)據(jù)包進(jìn)行排序。這就需要首先解析出TCP首部，再根據(jù)TCP中的信息進(jìn)行排序。本文為此設(shè)計(jì)了暫存隊(duì)列和斷點(diǎn)保存隊(duì)列，分別用于暫存捕獲的數(shù)據(jù)包和用于保存缺少數(shù)據(jù)包的序號(hào)。

4.4 文件頭部的重構(gòu)

文件頭部包含了整個(gè)媒體文件的重要信息。通過實(shí)驗(yàn)發(fā)現(xiàn)，文件的頭部并沒有在媒體數(shù)據(jù)傳輸階段進(jìn)行傳輸，而是在服務(wù)器與客戶端控制信息交互階段使用TCP協(xié)議進(jìn)行傳輸，并且采用了Base64編碼。這是因?yàn)镽TP協(xié)議并沒有規(guī)定文件頭部傳輸時(shí)機(jī)，可以在控制信息交互階段進(jìn)行傳輸也可以在實(shí)際數(shù)據(jù)傳輸階段進(jìn)行傳輸。

Base64是一種數(shù)據(jù)編碼算法。Base64編碼被設(shè)計(jì)用來對(duì)數(shù)據(jù)內(nèi)容進(jìn)行編碼以適合網(wǎng)絡(luò)傳輸，編碼后不易直接識(shí)別，編碼效率高，速度快。

Base64最初應(yīng)用在Email領(lǐng)域，早期的一些郵件網(wǎng)關(guān)只識(shí)別ASCII，如果發(fā)現(xiàn)郵件里有其它字符，就會(huì)將其過濾掉，這樣中文郵件和有圖片附件的郵件在這些網(wǎng)關(guān)上就會(huì)發(fā)生問題，于是將中文和圖片都使用base64編碼以后再傳輸，就能解決這個(gè)問題了。在網(wǎng)絡(luò)傳輸中將較長(zhǎng)的標(biāo)識(shí)信息（例如ASF的GUID）編碼為字符串，將非ASCII字符轉(zhuǎn)換為ASCII字符，更適合網(wǎng)絡(luò)傳輸。

5 展望

本文在深入研究流媒體文件格式的基礎(chǔ)上，對(duì)比分析了3種常見的流媒體文件格式的特性，并對(duì)媒體數(shù)據(jù)存儲(chǔ)的具體實(shí)現(xiàn)過程進(jìn)行了詳細(xì)的闡述。目前基于P2P的流媒體技術(shù)已經(jīng)從成長(zhǎng)期步入成熟期，由于時(shí)間等方面的原因，本文并沒有對(duì)其進(jìn)行深入的研究，未來如果能在P2P傳輸模式下，實(shí)現(xiàn)對(duì)流媒體數(shù)據(jù)的實(shí)時(shí)接收和保存將具有重要的理論意義和實(shí)用價(jià)值。

［1］馬杰，田金文，柳鍵.流媒體技術(shù)及其文件格式[J].計(jì)算機(jī)工程與應(yīng)用，2003，39（23）：49-52.

［2］曹攻靖，楊征，等.Real與Media流媒體技術(shù)比較［J］.計(jì)算機(jī)應(yīng)用研究，2001，18（6）：103-105.

［3］齊開悅，陳劍波，田鶴.一種基于ASF的新型多媒體流格式［J］.計(jì)算機(jī)應(yīng)用于軟件，2004，21（3）：70-72.

［4］D WU，T Hour，W Zhu et a1.Streaming Video over the intermit:Approaches and Directions.IEEE Tram Circuits Sys Video Techno，2001，11:282-300.

［5］Advanced System Format（ASF）Specification Revision［S］.Microsoft Coroporation，2015.

［6］范鎮(zhèn)元.Quicktime VR技術(shù)及其文件格式［J］計(jì)算機(jī)應(yīng)用.1998，18（3）:13-15.