流媒體視頻圖像保存的研究與實現(xiàn)

薛瑩瑩

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

1 引言

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

2 流媒體常見文件格式

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

2.1 RM格式

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

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

2.1.1 報頭部分（Section）

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

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

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

2.1.3 索引部分（Index Section）

RM文件的索引部分由索引塊報頭和索引記錄2部分組成。

2.2 ASF格式

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

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

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

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

2.3 MOV格式

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

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

2.3.1 原子

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

2.3.2 QuickTime原子容器

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

3 三種文件格式的特性對照

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

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

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

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

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

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

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

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

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

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

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

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

4.2 文件格式的識別

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

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

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

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

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

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

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

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

5 展望

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

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

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

［3］齊開悅，陳劍波，田鶴.一種基于ASF的新型多媒體流格式［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ī)應(yīng)用.1998，18（3）:13-15.