學習日誌六：影音格式的回顧(二)
目錄
⦿ RMVB的沒落與串流
⦿ 播放器的歷史
⦿ 網路與軟硬體發展
⦿ 封裝細節
⦿ 資料交換技術
⦿ 使用經驗
⦿ 再談RMVB
⦿ 結語RMVB的沒落與串流
最近在討論板看到有人問為何 rmvb 檔消失了，心中湧起滿滿回憶，與上篇相同，試著從各個面向切入，一窺影音格式的神秘面紗。
在那則討論串裡，網友們對 rmvb 這個檔案格式的回應，發現了一個關鍵，經驗上，大家使用 rmvb 都不是拿來看網路影片的。
為什麼特別提到這個關鍵？
因為當初 rmvb 被制定出來時竟是為了串流，相當有趣，以它的後綴來說，vb，variable bitrate，變化的流量，是不是令你想起了串流技術中的 ABS（adaptive bitrate streaming，自適應串流）呢？是的。
在我的另篇文章中有提到，串流是將影片切割成 .ts 檔，並用 m3u8 檔來記錄 .ts 檔的長度、開始與結束時間等，文章中在 iOS 上實作了解析 m3u8 檔案的網址，並將串流影片播放出來。
播放器的歷史
現在打開任何一款播放器，我們都可從資料路徑去找到本機檔案直接播放（白話就是播放你電腦或網芳上的影片），也可從需輸入 URL 的地方去播放網路影片，其實我對使用 Real Player 播放網路影片的印象相當薄弱，但使用 Media Player 播放網路影片的記憶卻相當強烈。
這並不是因為 Real Player使用者較少，或 Media Player 是內建於 Windows 而大家都被強迫推銷的關係，要知道，你所見的影音播放器戰爭，到了今天大概就剩幾大家，一是 PotPlayer，一是 VLC，或再加個 GOM 吧；音樂播放器的話，過去還有千千靜聽、Winamp、Foobar 等，現在也許是 Foobar 2000 獨大，回頭看當時的 Real Player、Media Player 就是播放器兩大陣營。
網路與軟硬體發展
主要是網路、軟硬體發展有沒有在相應的時間搭上，現在的串流是隨時可以跳到你想要觀看的時間，使用相對短的緩衝時間，看到這時間的片段；然而過去在收看網路新聞影片時（串流當時常應用在新聞影片上），例如兩分鐘的新聞影片，你想從一分半開始看，Media Player 的藍綠色進度條就會從頭開始讀，接著，你會看到下方的 buffering precentage，數字緩慢增大，直到能夠收看（未必是呈現 100 % 才能開始收看）。
而在你看到 1 分 35 秒，發現太囉唆，又想加個 10 秒，跳到 1 分 45 秒時，完蛋了！又得從頭開始讀取，因為前面的影片並無分別載入 cache，是以覆蓋 cache 的方式，因此會重複前一次的操作。
在過去，我們稱這樣的影片是網路影片，無論是從播放器輸入 URL，或播放網站中嵌入播放器的影片都是，不像現在的 Youtube、bilibili、Niconico 這麼流暢，當時所謂的網路影片早已捲入發展的洪流中。
繼續閱讀｜回目錄封裝細節
當時接觸的 rmvb 檔，它的封裝方式保留了彩度，甚至增強了彩度，卻喪失了非常多的聲音細節，在那個硬碟容量尚小的年代，不若現在隨便都買得到 1 T、2 T，rmvb 由於壓縮比高，檔案小，所以流通方便。
以當時閱聽眾對影音檔案的重視程度，是影像大於聲音這樣的使用習慣，毫不意外地，rmvb 一度成為廣受歡迎的格式，再加上當時 LCD 螢幕尚未普及，以 CRT 來說，小尺寸螢幕搭配 640 x 480 的解析度是相當足夠了。
當然網路起飛後，硬碟與記憶體越來越大，LCD 螢幕也開始普及，甚至編解碼技術漸長，rmvb 也不意外地消失了，就算我們最終見過 1280 x 720 的 rmvb，或後來的新格式 rmhd，現在，我們已不見 rm 家族的蹤影了，估計尚存的 rmvb 只用於快速轉檔後，丟上 Youtube 為了交差罷了。
資料交換技術
然而，影音封裝格式不僅僅受到網路技術的影響，或者說，前面說網路技術是以應用層面來看，如何傳播這樣的封裝格式也是相當重要的。
你還記得 P2P 嗎？
Peer to peer，P2P，是網路發展初期就提出的一種資料交換的技術，並非只基於 OSI 的任何一層。國內大家所熟知的其中一款 BT 軟體 — — Foxy，就採這技術，雖然說此技術發揚光大，就聲音檔而言是 Napster（The Social Network，社群網戰這部電影裡有提到 Napster 創辦人與 Facebook 創辦人的愛恨情仇），就影片檔來說是 Kazaa 以降，再到 eDonkey 及其繼任者，還有現在你看到的其他 BT 軟體了，不過 Napster 時間上早得多，如果你曾用 KKBOX 抓過音樂，國外就是用 Napster。
使用經驗
我大學時就用過 Kazaa，那時抓到的影片以短片為主，當時 Kazaa 的使用者多數想抓一些平時較難接觸到的東西，打個比方，如果中國的金盾系統是用來提高翻牆的門檻，那麼，Kazaa 是用來降低人們接觸暗網的門檻。
在 Kazaa 上面除了歐美謎片外，另有一些血腥畫面在流通，接下來會講點 18 禁的東西，因為這裡說的謎片不只是謎片，內容可能有人獸交、奶油犬、未成年女性與破處、兩女一杯等等；以血腥畫面來說，可能有砍頭與其他酷刑的片段，不過這些影片都難辨真假，畢竟以當時的畫質，說用數位造假也不容易，但畫面上的噁心片段卻又不夠清晰，那是個人們才剛拓展網路視野的年代。
繼續閱讀｜回目錄再談RMVB
回到 rmvb，初接觸時已是許久以後我在用 eMule（eDonkey 的繼任軟體）的時候了。
其實就 rmvb 的體質來說，用來傳播動畫是最適合的，當時動畫還在 4 : 3 與 SD（720 x 576），前面提到 rmvb 會增強彩度，並且在動態影像表現不俗，就資料傳播（流通）而言，動畫 DVD 轉檔成 rmvb 是相當不錯的選擇，當然，在前篇文章一直強調的，編碼與容器是不同的，但是你只需要關注一件事，rmvb 並不能使用所有編碼，或者當時也沒有足夠好的編碼。
這就好比 PS3 在播放 BD 時，影像、聲音都要求特定編碼（Sony 搞特規的歷史沿革）一樣，容器或播放器自有其限制，去到後來，現今容器幾乎以 avi、mkv、mp4、mov 為主流，實際上，早期的盜版電影，DVDrip 還是大宗，那正是 Divx 與 Xvid 糾葛中，與參照 h264 的 x264 跳出來的時期。
繼續閱讀｜回目錄結語
再提串流技術
現在無論在 BT、免空，或者雲端空間，rmvb 幾乎是沒看到了，有的話可能是比例為 4 : 3 動畫還在用這種格式，但多數也早已轉成 avi 或 mkv 了。
就像現在的串流已與早期不同，傳輸層採用 UDP、TCP，應用層則分別採用 RTP、HTTP，又基於防火牆對 UDP 的不友善，應用層的 RTP 反而需要 HTTP 的技術，不過 Google 為了 UDP 設計了 Quic，所以未來還很難說。
傳輸層與應用層趨勢
不過以傳輸層跟應用層的趨勢來看，live streaming / broadcasting 採用了 RTMP，播放也從 Flash player 再到 HTML5 player（等著看 FLV 也消失），其他串流如各家 OTT 平台就都採用 HTTP。像 Apple 的 HLS 或 Mpeg 的 Dash（後者開源），且 HLS 跟 Dash 是在 ABS（或稱 ABR，Adaptive Bitrate Streaming，自適應串流），因為 HTTP 有 TLS 的優勢，加上現在的頻寬足夠而採用串流技術。
在串流技術中，從 RTP 發展到 TCP，大致是因為頻寬趕上了，也不怕 loading，加上加密（HTTPS、RTMPS）的需求；與之相反的技術發展，是同樣基於 TCP 的 webSocket，webSocket 簡單說是保持長連接的雙向溝通，所以相當適合用在通訊軟體中，這特性不若在直播時掉封包也沒關係的應用（UDP）。
文章完畢，感謝您的閱讀。
繼續閱讀｜回目錄以下 Reference：