流媒體/流媒體文件格式詳解

摘  要   流媒體文件格式在流媒體系統中佔有重要地位，設計合理的文件格式是提高流媒體服務器工作效率最直接和最有效的辦法。該文在剖析常用流媒體系統和文件格式的基礎上，特別地對美國xiph.org基金會的開源流媒體工程Ogg文件格式子項目做了深入的分析，指出Ogg格式對媒體編碼數據的存儲讀取和傳輸具有簡潔性，Ogg格式的映射與逆映射與媒體編碼數據具有相對獨立性，能夠有效提高流媒體服務器的工作效率。

 

1 引言

 

     流媒體是指在Internet/Intranet中使用流式傳輸技術的連續時基媒體，如音頻、視頻等多媒體文件。文件格式和傳輸協議是流媒體應用的主要技術。從不同的角度看，流媒體數據有三種格式：壓縮格式、文件格式、發佈格式。其中壓縮格式描述了流媒體文件中媒體數據的編碼、解碼方式；流媒體文件格式是指服務器端待傳輸的流媒體組織形式，文件格式爲數據交換提供了標準化的方式；流媒體發佈格式是一種呈現給客戶端的媒體安排方式。本文所討論的格式是指第二種：流媒體文件格式。特別地分析了一種開源流媒體文件格式：Ogg。它是美國xiph.org基金會開發的開源流媒體工程的一個子項目，它是應其開源音/視頻媒體壓縮編碼格式Vorbis/Theora等的存儲與傳輸需要而設計的。

    本文在研究和分析已有流媒體系統的基礎上，結合在研發新的流媒體系統中的經驗和教訓，對流媒體文件格式做系統和深入的剖析，旨在深入理解流媒體系統和找到提高流媒體系統工作效率的方法。

2 流媒體文件格式分析

2.1 文件格式在流媒體系統中的重要性

     一個簡化的流媒體系統由流媒體服務器、客戶端和傳輸網絡組成，流媒體系統的核心是流媒體服務器。隨着流媒體技術研究的深入和流媒體應用的擴展，如何提高流媒體系統的工作效率，主要指標體現爲如何提高服務器併發媒體流的數量，這是一個被廣泛關注的課題。它取決於服務器處理每個流的效率，決定了一個服務器能夠同時爲多少客戶服務，其成果不但具有理論價值，更具有極大的經濟價值。 

    圖1的圓圈內標出了影響流媒體系統性能的一些主要因素。如果對其中每個因素仔細分析判斷，可以發現對於一個現有的流媒體服務器而言，能有效提高其效率的手段並不多。例如：提升客戶端、服務器端的硬件配置，只能獲得性能提高，工作效率沒有得到提高；實時傳輸、控制協議是人們經過多年的大量應用實踐總結，由IETF因特網工程任務組確認的媒體流傳輸共同標準，是必須遵守的標準，是無法輕易改變的；節目源的質量、壓縮方式等因素對於服務器而言是不可預知或者是不可控制的。那麼在這些客觀因素無法改變的情況下，優化流媒體文件格式爲提高流媒體服務器的工作效率提供了可能。

    流媒體文件格式能夠對服務器的工作效率產生影響是由流服務器工作方式的特點決定的。流服務器的主要工作任務是通過直播或點播的方式向用戶提供流媒體內容，它輸入磁盤上存儲的流媒體文件，然後進行實時傳輸協議封裝後再通過 IP網絡輸出給客戶端。簡言之，其工作流程爲3 步：讀取、封裝、發送。由於每發送一個媒體流都需要啓動一個流程，並且所有流程都需要實時進行，可見當一個流服務器併發幾千個流時，每個流程工作效率的細小區別都會對服務器工作效率造成很大的影響。

 圖1  簡化的流媒體系統結構及其影響因素

    每個工作流程的輸入是流媒體文件，輸出是媒體數據包。輸入、輸出數據的內容是沒有改變的，都是多媒體壓縮碼流，兩者之間只有格式的不同，所以從數據流角度來看，服務器的主要工作其實是一個格式轉換的過程。由於媒體數據包的格式是由傳輸協議事先確定的，那麼流媒體文件格式是否能夠方便服務器讀取、封裝就決定了服務器的工作量。

2.2  流媒體文件格式的分析與比較

    流媒體文件在流媒體系統中具有重要地位，文獻[2]分析了具有代表性的QuickTime電影文件(mov)和 Microsoft Media Server的電影文件（asf），對其文件格式和相關環節做了深入剖析。發現這些文件格式對服務器工作效率存在如下負面影響：

    (1)磁盤控制器訪問吞吐量低。每次封裝一個媒體數據包需要讀取一幀數據,一般每幀大小爲1K左右,每秒需要25幀,這造成對磁盤頻繁訪問,吞吐量低。

    (2)對於QuickTime Mov文件格式,媒體數據沒有經過預處理,服務器每發一個包都需要從hint軌中獲得打包時需要的相關參數,實時讀取媒體數據、封裝、發送,對CPU佔用率很大。

    (3)對於Microsoft Asf文件格式,媒體數據在Packet中時已經是mms包的半成品,服務器節省了截取媒體流的時間,但仍然需要服務器選擇媒體流來組織mms包。並且,Packet中的數據不全是需要發送的數據,浪費了內存空間和磁盤IO時間。  

    文獻[3]提出了一種新的流媒體文件格式NMF,該格式具有如下基本結構(如圖2所示)和特點:

圖2 NMF文件結構

    NMF流媒體文件由頭文件和體文件構成。頭文件主要包含文件描述、媒體描述、流描述等必要的信息；體文件包含全部的媒體數據。一個NMF由一個頭文件和若干個體文件構成,同一媒體源不同的流(不同的傳輸協議或不同的碼速率)存放在不同的體文件中,此結構用來實現多碼速率切換/智能流技術和兼容現有的流媒體播放器。頭文件和體文件的功能劃分原則是：當服務器和客戶建立連接時(在發送媒體數據之前),只需要從頭文件中讀數據；當服務器和客戶建立連接後,只需要從文件體中讀取媒體數據。這樣,服務器中各個模塊間耦合減少,效率提高。由於頭文件和體文件的相對獨立,使文件具有很強的可擴展性,並且使得利用硬件進行封裝、發送也成爲可能。

    NMF的核心思想就是充分利用預處理過程,將原始媒體文件組織成方便服務器處理的格式,減少實時封裝和發送時的工作量,同時增加文件結構的兼容性和可擴展性,以提高流服務器的工作效率,增加併發流數量。

3  Ogg 文件格式結構

3.1 文件格式在流媒體系統中的重要性

     邏輯流以頁（page）爲單位組織鏈接成物理流,如圖3所示：

 

圖3   Ogg 文件的組織形式

    圖3中的文件鏈接了兩個物理流，A、B和C三個邏輯流組成一個物理流，邏輯流D單獨是一個物理流。一個物理流中的所有邏輯流的bos_page都必須在物理位置上相鄰，如圖3所示*A*、*B*、*C*三個bos_page的位置。

    bos：beginning of stream;    eos：end of stream

    映射到Ogg格式的媒體(如vorbis音頻,Theora視頻)有相關詳細定義，這些定義使得這些媒體之間有更具體的約束關係。Ogg 本身並沒詳細說明多個併發媒體流之間的時間關係，這需要併發媒體流在映射到Ogg格式的時刻來指定，通常他們之間的交錯關係是按他們產生的時間先後順序來排列。

3.2 Ogg page 頁結構

    每個頁之間相互獨立，都包含了各自應有的信息，頁的大小是可變的，通常爲4K－8KB，最大值不能超過65307bytes（27＋255＋255*255=65307）。頁頭部格式如圖4。

    頁頭部各字段域詳細說明參見文獻[4]：（小端字節序列格式LSB）。

    ⑴ capture_pattern: 模式捕獲域，4個字節,表示頁的開始，其作用是分離Ogg封裝格式還原媒體編碼時識別新頁的作用，它包含了四個幻數（ASCII字符集）：

0x4f 'O'    0x67 'g'    0x67 'g'     0x53 'S'

    ⑵ stream_structure_version:1個字節，表示當前Ogg文件格式的版本,目前爲0。

圖4 Ogg頁頭部結構

    ⑶ header_type_flag:頭部類型標識，1個字節。標識當前頁具體類型。其設置分三種情況：

    *  bit 0x01  若已設置，頁包含的媒體編碼數據於前一頁同屬於一個邏輯流的同一packet。若未設置，本頁是一個新的packet。

    *  bit 0x02   設置，表示邏輯流的第一個頁bos。未設，不是第一個頁。

    *  bit 0x04   設置，表示邏輯流的最後一頁eos。未設，不是最後一頁。

    ⑷ granule_position:8個字節（字節6－字節13），包含了媒體編碼相關參數信息。對於音頻流，包含了到本頁爲止邏輯流在PCM中採樣編碼的總次數。對於視頻流，包含了邏輯流到本頁爲止視頻幀編碼的總次數。其值若爲－1，則說明到此頁爲止，邏輯流的packet還未結束。

    ⑸ bitstream_serial_number:流序列號，4字節，表示本頁所屬邏輯流與其他邏輯流相區別的序號。

    ⑹ page_sequence_number: 表明了本頁在邏輯流中的序列號，Ogg解碼器能據此識別有無頁丟失。

    ⑺ CRC_checksum: 循環冗餘校驗碼校驗和，4字節域，包含頁的32bit CRC校驗和（包括頁頭部零CRC校驗和頁數據校驗），它的產生多項式爲：0x04c11db7。

    ⑻ number_page_segments:1字節，給定了在本頁的segment_tabale域中所出現的segement個數，其最大值爲255segments(每片255個字節)，即頁頭部第26個字節的取值範圍爲:0x00-0xff (0-255)。頁最大物理尺寸爲65307bytes,小於64KB。

    ⑼ segment_table:邏輯流中的每個packet每個segment長度的取值（lacing values，除了每個packet的最後一個segment小於255外，其它segment都爲255），這些值以segment出現的先後順序依次排列。此域的字節數爲number_page_segments域所表示的數字（即在0－255之間）。

byte     value

 27       0xff (255)

      [.................  ]

      n-1      0xff (255)

n        0x00-0xfe (0-254, n=num_segments+26)

頁頭部長度的字節數:

  header_size = 27 + number_page_segments [Byte]  

  即頁頭部長度爲上述9個域名所表述佔據的字節數之和。

頁的總長度：

  page_size = header_size + sum(lacing_values: 1...number_page_segments)   [Byte]

即頁的總長度爲頁頭部長度加上緊隨其後的若干segments長度之和（淨載荷長度）。

 3.3  Ogg封裝處理過程

    (1)音視頻編碼在提供給Ogg封裝之前是以具有包邊界的“Packets”形式呈現的，包邊界依賴於具體的編碼格式。如圖5所示。

    (2)將邏輯流的各個包進行分片segmentation，每片大小固定爲255Byte,但包的最後一個segment通常小於255字節。因爲packet的大小可以是任意長度，由具體的媒體編碼器來決定。

    (3)進行頁封裝，每頁都被加上頁頭，每頁的長度可不等，由具體情況而確定。頁頭部segment_table域告知了 “lacing_value”值的大小，即頁中最後一個segment的長度（可以爲0，或小於255）。一次處理一個packet，此packet被封裝成一個或多個page頁（page的長度設定了上限，一般爲4kB）；下一個packet必須用新的page開始封裝，由首部字段域header_type_flag的設置規定來表示。

    (4)多個已被頁格式封裝好的邏輯流（如語音、文本、圖片、音頻、視頻等）按應用要求的時序關係合成物理流。

3.4  Ogg文件的映射與逆映射

    用Ogg文件格式封裝好壓縮編碼媒體流可用於存儲（磁盤文件）或直接傳輸（TCP或管道），這是因爲Ogg比特流格式提供了封裝/同步、差錯同步捕獲、尋找標記以及其它足夠的信息使得這種分散開的數據能夠完全地還原爲封裝之前的具有包邊界“packet”形式的壓縮編碼媒體流，恢復到這種原來媒體流就具有的包邊界形式不需要依賴於針對壓縮編碼的解碼器。也就是說Ogg映射與逆映射和媒體流的壓縮編碼、解碼具有相對獨立性。

圖5  Ogg封裝流程示意圖

    Ogg文件需要解封裝的情況有兩種：（1）播放器要對媒體流解碼之前；（2）對媒體流進行RTP/UDP傳輸之前。解封裝的過程就是ogg逆映射過程，即還原爲具有包邊界“packet”形式的媒體流，同時以預先填充好了的RTP首部字段與相應一段媒體數據捆綁，形成RTP封包。此過程便是媒體流從Ogg格式到RTP格式的轉換過程。

    將以packet爲單元的媒體流映射爲以page爲單元的Ogg格式比特流，其中間經過了segment的劃分和重組環節，但方便了對媒體流的存儲與傳輸（TCP）。對源緩衝區媒體數據(packet)的操作，需建立幾個中間環節的數據結構，只需將切割的媒體數據在內存移動一次，操作指向媒體數據的指針便能達到媒體數據遷移到目的緩衝區（page）的意圖,其過程可用兩個函數轉換來表述：

ogg_stream_packetin()àogg_stream_pageout()。 將Ogg格式比特流逆映射還原爲packets媒體流，以備播放解碼或以RTP封裝進行UDP傳輸 。其中間環節是把page中的segment單元數據按順序重組爲packet,同樣媒體數據在內存中的複製只有一次，其過程可用三個函數轉換來表述：ogg_sync_pageout（）à ogg_stream_pagein （）à ogg_stream_packetout（）,媒體數據複製發生在第一個函數ogg_sync_pageout（）。

Ogg映射與逆映射的功能都體現在ogg函數庫中,當前最新版本爲libogg-1.1.3。

4 結束語    

    Ogg格式是在吸收其它流媒體文件格式優點的基礎上針對具有“packet”包邊界形式的媒體流而制定的利於其存儲和傳輸的開源流媒體文件格式，在icecast流服務器的傳輸中得到了很好的應用；根據icecast官方網站公佈其測試結果，在GB主幹網的條件下對Oggvorbis音頻傳輸的客戶端併發流可達14000個。更爲重要的是,作爲流媒體技術的核心環節，大多數流媒體文件格式至今仍沒有完全公開，且受專利保護。要在流媒體技術和應用飛速發展的今天佔得一席之地，遵從GNU/GPL協定，走開源之路，發展不受知識產權約束的流媒體文件格式是緊追先進流媒體技術的較佳選擇。

 

幾種常見的流媒體格式文件：

微軟高級流格式ASF簡介

　　Microsoft公司的Windows Media的核心是ASF（Advanced Stream Format）。微軟將ASF 定義爲同步媒體的統一容器文件格式。ASF是一種數據格式，音頻、視頻、圖像以及控制命令腳本等多媒體信息通過這種格式，以網絡數據包的形式傳輸，實現流式多媒體內容發佈。

　　ASF最大優點就是體積小，因此適合網絡傳輸，使用微軟公司的最新媒體播放器（Microsoft Windows Media Player）可以直接播放該格式的文件。用戶可以將圖形、聲音和動畫數據組合成一個ASF格式的文件，當然也可以將其他格式的視頻和音頻轉換爲ASF格式，而且用戶還可以通過聲卡和視頻捕獲卡將諸如麥克風、錄像機等等外設的數據保存爲ASF格式。另外，ASF格式的視頻中可以帶有命令代碼，用戶指定在到達視頻或音頻的某個時間後觸發某個事件或操作。

　　ASF的特徵

可擴展的媒體類型- ASF文件允許製作者很容易地定義新的媒體類型。ASF格式提供了非常有效的靈活地定義符合ASF文件格式定義的新的媒體流類型。任一存儲的媒體流邏輯上都是獨立於其他媒體流的，除非在文件頭部分明顯地定義了其與另一媒體流的關係。

　　部件下載-特定的有關播放部件的信息（如，解壓縮算法和播放器）能夠存儲在ASF 文件頭部分，這些信息能夠爲客戶機用來找到合適的所需的播放部件的版本---如果它們沒有在客戶機上安裝。

　　可伸縮的媒體類型- ASF是設計用來表示可伸縮的媒體類型的"帶寬"之間的依賴關係。ASF存儲各個帶寬就像一個單獨的媒體流。媒體流之間的依賴關係存儲在文件頭部分，爲客戶機以一個獨立於壓縮的方式解釋可伸縮的選項提供了豐富的信息流的優先級化- 現代的多媒體傳輸系統能夠動態地調整以適應網絡資源緊張的情況（如，帶寬不足）。多媒體內容的製作者要能夠根據流的優先級表達他們的參考信息，如最低保證音頻流的傳輸。隨着可伸縮媒體類型的出現，流的優先級的安排變得複雜起來，因爲在製作的時候很難決定各媒體流的順序。ASF允許內容製作者有效地表達他們的意見（有關媒體的優先級），甚至在可伸縮的媒體類型出現的情況下也可以.

　　多語言- ASF設計爲支持多語言。媒體流能夠可選地指示所含媒體的語言。這個功能常用於音頻和文本流。一個多語言ASF文件指的是包含不同語言版本的同一內容的一系列媒體流，其允許客戶機在播放的過程中選擇最合適的版本。

　　目錄信息- ASF提供可繼續擴展的目錄信息的功能，該功能的擴展性和靈活性都非常好。所有的目錄信息都以無格式編碼的形式存儲在文件頭部分，並且支持多語言，如果需要，目錄信息既可預先定義(如,作者和標題)，也可以是製作者自定義。目錄信息功能既可以用於整個文件也可以用於單個媒體流。

　　RealSystem的RealMedia文件格式

RealNetworks公司的RealMedia包括RealAudio、RealVideo和RealFlash三類文件，其中RealAudio用來傳輸接近CD音質的音頻數據，RealVideo用來傳輸不間斷的視頻數據，RealFlash則是RealNetworks公司與Macromedia公司新近聯合推出的一種高壓縮比的動畫格式RealMedia文件格式的引入了，它使得RealSystem可以通過各種網絡傳送高質量的多媒體內容。第三方開發者可以通過RealNetworks公司提供的SDK將它們的媒體格式轉換成RealMedia文件格式。

　　QuickTime電影(Movie)文件格式

Apple公司的QuickTime電影文件現已成爲是數字媒體領域的工業標準。 QuickTime電影文件格式定義了存儲數字媒體內容的標準方法，使用這種文件格式不僅可以存儲單個的媒體內容(如視頻幀或音頻採樣)，而且能保存對該媒體作品的完整描述；QuickTime文件格式被設計用來適應爲與數字化媒體一同工作需要存儲的各種數據。因爲這種文件格式能用來描述幾乎所有的媒體結構，所以它是應用程序間（不管運行平臺如何）交換數據的理想格式。QuickTime文件格式中媒體描述和媒體數據是分開存儲的，媒體描述或元數據（meta-data）叫做電影（movie）,包含軌道數目、視頻壓縮格式和時間信息。同時movie包含媒體數據存儲區域的索引。媒體數據是所有的採樣數據，如視頻幀和音頻採樣，媒體數據可以與QuickTime movie存儲在同一個文件中，也可以在一個單獨的文件或者在幾個文件中。