流媒體/流媒體檔案格式詳解

摘  要   流媒體檔案格式在流媒體系統中佔有重要地位，設計合理的檔案格式是提高流媒體伺服器工作效率最直接和最有效辦法。該文在剖析常用流媒體系統和檔案格式的基礎上，特別地對美國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)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儲存在同一個檔案中，也可以在一個單獨的檔案或者在幾個檔案中。