“Blog 的新位置在 http://mmdays.com,本Blog將在 12/22 號之後,不同步更新。還請網友轉往新站留言:)”
Posted by Mr. Friday
大家都有看到板上的Joost吧! 有沒有覺得很炫呢? 其實, 除去Joost超炫的操作畫面, 它的本質 — “網路電視”的概念, 從很早以前就有了, 但一直到最近才急速竄起吸引大眾的目光. 說起背後的原因, 其實也要感謝一下BT, 因為若不是BT利用P2P的原理達到前所未有的檔案快速傳輸效果, 進而帶動網路電視媒體業者在P2P方面的研究, 恐怕網路電視(IPTV)的普及到現在都還是遙不可及的夢哩!
前一陣子Mr. Friday看到了一篇流量分析報告, 作者在同一時間內觀察了PPStream, PPLive, Sopcast與TVants的效能與網路流量表. 這對Mr. Friday來說可謂如獲至寶, 因為從該流量表中不但清楚可見這四項軟體的整體表現到底誰好, 更重要的是它隱隱透露出了這些軟體的設計原理! 要知道這些軟體的設計過程通通是商業機密, 外人無從得知, 但是從這幾張流量表, 還是可以大概猜想得出它們的運作原理, 進而知道軟體的效能如何.
在進行解讀之前, 還是有一些基本的背景知識要讓大家知道一下. 學術上對P2P網路電視的研究其實自1999年來就一直沒有斷過, 不過大多都是假設僅有源頭本身與少數頻寬強大的使用者加入分流的行列, 所以多半是呈一個固定的樹狀:
在此類的階層式架構中, 主要的研究議題是網路中該有幾個階層(本圖有三層)? 太多層會造成檔案從源頭傳到一般使用者的時間要很久, 而太少層的話則每個分流者(源頭與超級使用者)的分擔會變重,因為要分流的對象變多了. 另外, 若有一個超級使用者下線, 則底下的一般使用者通通會掛點, 必須自己重新尋找另一個上源. 此類的代表是NICE, Zigzag.
另外一種的分享方式則有別於固定的樹狀結構, 每個使用者並沒有固定的檔案來源, 也沒有一定的傳輸對象, 就如同BT的分享方式. (直接把前幾天畫的圖拿來用=,=…)
這類的代表是2000年的Narada以及2005年的CoolStreaming(學術論文叫DONet). 不過這類的概念雖然類似BT, 但是在實作上的效能往往極差, 畢竟串流媒體與檔案不同, 檔案可以下載完再開, 但是串流媒體卻有時間的限制–檔案必須要在時間內傳送到使用者手上, 否則觀眾看到的檔案就會一頓一頓的. 也因此, P2P網路電視在架構設計上需要比BT更有效率的訊息交流方式(Narada與CoolStreaming在這方面可謂極差), 以確保不會發生上述的情況.
在上述兩者中間還有一些不同的機制, 比如說把影片檔案切成好幾組, 每一組用不同的樹架構來進行傳送. 下圖是假設源頭把一個檔案切成三組, 用不同的方式傳送給 A, B, C三個人:
這個方法的好處在於每個人的上傳頻寬都會被用到, 而且假如A斷線了, 會受到影響的只有檔案片段1, 檔案片段2與3的傳輸仍然不受影響. 至於檔案片段1~3要怎麼切呢? 有兩種常見的切法:
- 利用Layered Encoding來作切割: Layered Encoding的概念是, 把一個畫質很好的影片切成幾個畫質較差的小檔案, 待使用者收到後再組合為原來的影片. 舉例來說, 有一個檔案畫質較高, 取樣頻率有100K, 今天切成3個檔, 第一個檔的畫質30K, 第二個檔畫質45K, 第三個檔畫質25K. 若使用者3個檔都有收到, 則可將三個檔組合還原為100K高畫質影片; 若只收到第1與2個檔, 則只能組合為畫質30K+45K=75K的檔案. Layered Encoding的缺點是, 每一個檔案片段都是一個patch(補強檔), 會需要上一個檔案片段才能作用; 檔案3需要檔案2才能作用, 檔案2需要檔案1才能作用, 因此若今天收到的檔案1&3, 則畫質仍然只有30K. 若今天收到檔案2&3, 則根本連看都不能看.
- 將第n秒的檔案歸類為檔案片段1, 第n+1秒的檔案歸類為片段2, 第n+3秒的為片段3. 這就是所謂 MDC (Multiple Description Coding)的概念. 假如我們把時間間隔切得非常小, 比如說, 每個檔案片段只相差0.1秒, 那麼若其中一個檔案片段在傳輸過程中不見了, 對使用者來講只會覺得停格了0.1秒.
與1相較之下, 2的作法是比較理想的. 如果使用者A斷線了, B與C並不會感受到撥放不順, 頂多只是在某段時間內定格個零點幾秒而已. 這種做法理論上也不需要特別的檔案格式才能做到, 常見的mpg, avi, wmv, rmvb…通通可以這樣做, 但詭異的來了, 現行的影片解碼器在開發的過程中幾乎都不支援MDC的功能, 為什麼哩 ? 沒有人清楚, 或許對於撰寫影片編解碼的人來說, 支援MDC功能會大大增加他們的工作複雜度, 在影片壓縮上也有負面影響吧.
這類的網路電視代表也不少, MSNBC推出的CoopNet, 或是SplitStream等等都屬於這種.
講了半天, 那麼PPStream, PPLive…它們又屬於上述哪一種呢? 效能又是誰勝出? 別心急, 下一篇就讓我們來看看流量表怎麼說吧!
延伸閱讀:


















[...] P2P網路電視測試報告(上) - 現行基本原理介紹 [...]
我對網路不是很有研究,但最近為了課程的期中報告所以在讀DONet那篇paper,據paper上的敘述,它的實作效能似乎不錯,但和您講的「Narada與CoolStreaming在這方面可謂極差」有些出入,讓我有點困惑…不知道是什麼原因呢?
To Ruio,
我看不出DONet的演算法有針對scalability的考量來做任何網路topology上的調整. 它的演算法只是單純的與身邊人交換檔案而已, 非常類似BT, 但是Video streaming所需要兼顧的時效性, 在paper中也未提到如何保證速度.
DONet Paper本身的實驗都跑在校園網路裡面, 而且使用者都相當少量, 所以從paper本身可能看不出缺點. 但事實上DONet早在2004年就以CoolStreaming的名義出現在網路上, 您可以去網路上問問當年CoolStreaming人數破千之後, 速度有多麼緩慢…. (更何況所謂的scalability應該要以人數破萬為考量)
Thank you~~!
[...] P2P網路電視測試報告解讀(上) - 現行基本原理介紹 [...]
[...] P2P網路電視測試報告解讀(上) - 現行基本原理介紹 [...]
http://0rz.tw/b72Gf
針對H.264/AVC標準之多重描述視訊編碼 蘇哲群
…
多重描述編碼(Multiple Description Coding, MDC)技術能夠有效抵抗資料經由網路傳輸過程中產生的封包遺失,並具有優秀的錯誤更正能力。利用多重描述編碼技術,可以在易發生錯誤的封包網路上提供穩定的影像傳輸:首先,視訊信號在發送端會被壓縮並利用冗餘編碼(Redundancy Coding)成為許多條可以獨立解碼的位元流,接著利用封包網路上不同的路徑傳送至接收端,而根據傳送到的各個位元流的錯誤情形,解碼器將可重建出不同品質的影像,由於可獨立解碼的特性,只要收到某一條位元流,即能重建出可接受的畫質,而接收到越多的位元流,重建出來的影像畫質也越高;當某些位元流發生封包遺失或錯誤時,亦可利用其他完整位元流的資訊達到較好的錯誤更正。
…
[...] P2P網路電視測試報告解讀(上) - 現行基本原理介紹 [...]