土豆網擁有國內最大的海量視頻數據流媒體，截至當前，累計原創UGC視頻超過6000萬，每天2-2.5億視頻播放量，千萬級用戶訪問行爲和視頻播放需求，如何能夠更好地滿足用戶對於視頻流的播放需求，基於互聯網架構的流媒體服務應該具有哪些特點，未來的挑戰是什麼？
什麼是完整的多媒體視頻文件？
一個完整的多媒體文件是由音頻和視頻兩部分組成的，H264、Xvid等就是視頻編碼格式，MP3、AAC等就是音頻編碼格式，字幕文件只是附加文件。
要將視頻編碼和音頻編碼打包成一個完整的多媒體文件，可以有不同的方式，這種方式便是所謂的封裝方式，不同的封裝方式有不同的後綴。由於有些封裝方式具有很強的靈活性，它可以把各種不同的音視頻文件打包成一個文件，因此會出現這麼一種情況，雖然文件後綴是相同的，但有些文件可以正常播放而有些卻不能播放，畢竟任何一種播放軟件都不是萬能的。部分先進的封裝方式還可以同時封裝多個音頻編碼文件，甚至同時封裝進字幕文件，如MKV （MKV文件可以做到一個文件包括多種語種發音，多語字幕以適合不同的人觀看）封裝方式。
多媒體視頻文件的常見組合方式
|
封裝格式 |
視頻流編碼格式 |
音頻流編碼格式 |
|
AVI |
Xvid |
MP3 |
|
AVI |
Divx |
MP3 |
|
Matroska（後綴就是MKV） |
Xvid |
MP3 |
|
Matroska（後綴就是MKV） |
Xvid |
AAC |
|
Matroska（後綴就是MKV） |
H264 |
AAC |
|
MP4 |
Xvid |
MP3 |
|
MP4 |
H264 |
AAC |
|
3GP |
H.263 |
AAC |
|
flv |
H.263 |
AAC |
|
f4v |
H.264 |
AAC |
表1：多媒體視頻文件組合方式
封裝格式(也叫容器)：所謂封裝格式就是將已經編碼壓縮好的視頻軌和音頻軌按照一定的格式放到一個文件中，就是說僅僅是一個外殼，或者把它當成一個放視頻軌和音頻軌的文件夾也可以。說通俗點，視頻流媒體相當於飯，而音頻流媒體相當於菜，封裝格式是選擇什麼樣的容器（碗或鍋），用來盛放某種視頻流和音頻流的組合。
視頻流編碼格式：
- mpeg1：早期vcd使用的就是這種編碼格式，分辨率是352*288，壓縮比低。
- mpeg2：早期DVD使用，有NTSC(720480)和PAL（720576），和mpeg1一樣屬於即將被淘汰的編碼格式。
- mpeg4：目前使用最多的技術，avi文件，大大提高壓縮比，而質量堪比4倍DVD畫質。
- divx：基於mpeg4開發的，進行了一定的算法優化。
- xvid：相當於divx的開源版本，也是基於mpeg4的編碼技術更先進，採用開放源碼，畫質更好。
- h.261：早期低碼率編碼，應用於352x288和176x144，現在被淘汰了。
- h.263：在低碼率下能夠提供比H.261更好的圖像效果，算法進行了部分優化。
- h.263+：h.263的改進型，亮點不多。
- h.264 ：H.264集中了以往標準的優點，高效壓縮，high profile的壓縮比例，目前最流行的編碼方式。
- RV.10 RV.13 RV.20 RV.30 RV40： real 公司推出的應用於網絡的高壓縮編碼，rm是固定碼率和rmvb是動態碼率。
流媒體播放協議
以“流(Streaming)”的形式在基於IP協議的互聯網中進行多媒體數據的實時、連續傳播，客戶端在播放前並不需要下載整個媒體文件，而是在將緩存區中已經收到的媒體數據進行播放的同時，媒體流的剩餘部分仍持續不斷地從服務器遞送到客戶端，即所謂的“邊下載，邊播放”。
RTSP(實時流媒體會話協議)： 協議全稱：Real-Time Stream Protocol，是一種基於文本的應用層協議，在語法及一些消息參數等方面，RTSP協議與HTTP協議類似。RTSP被用於建立的控制媒體流的傳輸，它爲多媒體服務扮演“網絡遠程控制”的角色。儘管有時可以把RTSP控制信息和媒體數據流交織在一起傳送，但一般情況RTSP本身並不用於轉送媒體流數據。媒體數據的傳送可通過RTP/RTCP等協議來完成。
MMS（多媒體短息服務）： 協議全稱Multimedia Messaging Service，它最大的特色就是支持多媒體功能。多媒體信息使具有功能全面的內容和信息得以傳遞，這些信息包括圖像、音頻信息、視頻信息、數據以及文本等多媒體信息，可以支持語音、因特網瀏覽、電子郵件、會議電視等多種高速數據業務，在GPRS網絡的支持下，以WAP無線應用協議爲載體傳送視頻片段、圖片、聲音和文字。多媒體信息業務可實現即時的手機端到端、手機終端到互聯網或互聯網到手機終端的多媒體信息傳送。
HTTP協議： 大衆化的通信協議，在這裏不做詳細解釋。
在線流媒體視頻服務
在線流媒體的服務根據視頻播放器的不同設備要求，需要輸出不同的封裝視頻格式：
|
封裝容器 |
視頻流編碼格式 |
音頻流編碼格式 |
Flash Player |
HTML5的video控件 |
PC端player |
手機端player |
ios player |
|
AVI |
Xvid |
MP3 |
不支持 |
不支持 |
支持 |
不支持 |
不支持 |
|
AVI |
Divx |
MP3 |
不支持 |
不支持 |
支持 |
不支持 |
不支持 |
|
MKV |
Xvid |
MP3 |
不支持 |
不支持 |
支持 |
不支持 |
不支持 |
|
MKV |
Xvid |
AAC |
不支持 |
不支持 |
支持 |
不支持 |
不支持 |
|
MKV |
H.264 |
AAC |
不支持 |
不支持 |
支持 |
不支持 |
不支持 |
|
MP4 |
H.264 |
AAC |
支持 |
支持 |
支持 |
支持 |
不支持 |
|
3GP |
H.263 |
AAC |
不支持 |
不支持 |
支持 |
不支持 |
不支持 |
|
3GP |
H.264 |
AAC |
支持 |
不支持 |
支持 |
不支持 |
不支持 |
|
FLV |
Sorenson Spark |
MP3 |
支持 |
不支持 |
支持 |
不支持 |
不支持 |
|
FLV |
On2 VP6 |
MP3 |
支持 |
不支持 |
支持 |
不支持 |
不支持 |
|
F4V |
H.264 |
AAC |
支持 |
不支持 |
支持 |
不支持 |
不支持 |
|
TS |
H.264 |
AAC |
不支持 |
支持 |
支持 |
不支持 |
支持 |
表2 不同封裝格式的視頻播放參照表
從上表的分析結果能夠看到，大部分的播放器產品對於H.264+AAC的MP4編碼格式支持最好，但是MP4也有很多的缺點，比如視頻header很大，影響在線視頻網站的初次加載時間，爲了降低頭部體積，需要進行視頻本身的物理分段等等，所以很多在線視頻網站在帶寬耗費的壓力下，主要選擇的是adobe公司提供的FLV或F4V， FLV是流媒體封裝格式，可將其數據看爲二進制字節流，其字節編碼格式爲 BigEndianUnicode 。總體上看，FLV包括文件頭（File Header）和文件體（File Body）兩部分，其中文件體由一系列的Tag及Tag Size對組成。
所以，爲了能夠提供各類設備的在線視頻播放需求，對於在線視頻流媒體服務，提出了很多需求，對於早期建立的視頻網站（土豆，優酷，ku6等）都只提供一種視頻流媒體格式（FLV）的支持，我們稱之爲單一的流媒體服務架構，如圖：
圖1 ：單一流媒體服務的架構圖
但是，在實際業務運營中遇到了很多問題：
1） 視頻存儲的壓力很大
同一種視頻碼流（h.264）,因爲針對不同平臺應用設備（如表2）的播放需求，需要不同的封裝格式，需要將產生大量重複視頻流存儲的壓力，視頻網站的視頻量巨大，多支持一種格式將產生幾百TB級的存儲壓力，從機房到機櫃，視頻流同步等環節負載和壓力都是巨大的。
2） 封裝後的視頻格式是否真的被播放
視頻流封裝完成後，同步到各地的中心節點後，是否真的有視頻流請求產生，還是僅僅處於視頻準備狀態，是否會影響中心節點的磁盤佔用，緩存節點的命中率不高。
3） 封裝格式的功能性升級，導致老視頻再次封裝
封裝格式的不斷髮展，TS流，HTTP live Stream的不斷優化，將導致現有的視頻流不斷需要翻新或重複封裝。 爲了解決上述各類問題，視頻網站流媒體服務的研發工程師進行了多格式的流媒體服務架構探索，提供了各類視頻封裝格式的流媒體封裝反向代理接口，該接口能夠通過URL的請求，完成對特定視頻編碼格式（h.264）的封裝。
圖2：多格式的流媒體服務架構：
如圖所示，“流媒體容器封裝服務“成爲多格式視頻流服務的核心，對於這個流媒體的封裝服務，通過對h.264的視頻編碼流進行不同格式的封裝，提供了多種視頻流的推送。對於這個服務，我們希望能夠儘快爲視頻的cache服務推送視頻流，所以，在硬盤方面，選擇了每分鐘15000轉的SAS硬盤，降低同一視頻流的不同封裝請求的IO延遲等待。
分析與比較
作爲最簡單和原始的流媒體解決方案，單一流媒體服務架構唯一顯著的優點在於它僅需要維護一個標準的視頻流文件，而這樣的服務器基礎設施在互聯網中已經普遍存在，其安裝和維護的工作量和複雜性比起多格式流媒體服務架構來說要簡單和容易的多。然而其缺點和不足卻也很多，首先是維護的工作量較大，多份相同視頻文件由於封裝格式不相同，需要同時維護多個實體的碼流文件，大量的佔用磁盤的空間，再次，轉碼集羣需要針對多種不同的封裝格式，進行多次的視頻轉碼，搶佔很多資源，缺乏靈活的控制功能和擴展機制。