流媒體的實現過程思考 [轉貼]

流媒體:
由於原來小搞過一點點DirectSound的經驗,外加一點點小小的網路實踐.自己想出一個套路.從檔案格式,DS,壓縮加密,協議命令,以及各種伺服器技術似乎都要涉及.(簡單為主,不掙錢的活誰幹,除非自己喜歡..)

首先,如果不藉助其他sdk或者聲音引擎的話,基本上很難自己開發.DirectSound可以滿足"自訂"的聲音,可以自己寫入緩衝區然後lock播放.可以在此之前添加各種慮鏡(好像有人叫DFS還是什麼來著,都是類似的,我叫慮鏡習慣了..)

其次,如果你不打算使用wav的話(廢話,體積那麼大)需要自己涉及一套適合網路傳輸的協議,不要給我說zip那類,我們要得是即時的,或者說是有損的,我們的buffer應該盡量的小.相反的,網路緩衝要盡量的大,這樣才能保證"不卡"(至少點播的時候有用,比如realone的綠條,可以用總是緩衝)

第三,有了自己的壓縮格式,最終為了播放還要還原成riff進行ds緩衝區的填充.當然不壓縮也可以,畢竟僅僅是為了探討他的實現,壓縮部分點到即止就可以了,同樣的,加密也是在這裡做手腳,比如我們全部mask一個hash(如果直接播放的話也能聽見...不過這種慮鏡加的....)

第四,用戶端建立足夠的網路緩衝,根據點播以及廣播的不同,略有一點點不同,廣播的延遲不能太大(也就是說,我們的廣播不是直播,速度還是要慢幾秒的)

第五,伺服器.多人的比較麻煩.對了,大家還記得IE跟IIS嗎.他們用的是http協議,用Media Player Classic或者其他播放器也是可以點播的,而且不是下載整個檔案的,不信你可以試試.協議的最終目的還是更好的傳輸資料.同時說明如果你不想使用自己的協議,可以參照其他協議,然後你自己做一個用戶端讀取資料也行.但是,貌似自己做一個簡單的協議比使用http的要簡單很多(個人看法)直接建立socket然後發送簡單的get seek find..就夠用了.連接埠可以臨時new,實際上對於伺服器的效能而言,幾百人也就是極限了,實在不行一開始就直接全部用數組建立也行,還能少不少麻煩.(-_-b 貌似扯遠了)

第六,協同起來.伺服器就是傳輸資料的,如果說做的更多,無非就是負載平衡,多線程之類複雜的東西了,那個就....要慢慢研究了,不是難不難的問題,而是過程複雜.整體無非就是以下步驟:
1伺服器開始監聽
2用戶端啟動
3使用者輸入
4用戶端向伺服器發出請求
5建立串連開始傳輸,同時根據客戶的需求選擇相應的壓縮(音質不同)
6.1 伺服器發送資料 6.2用戶端填充網路緩衝區
7用戶端開始播放,同時保持串連繼續傳輸資料
8停止,中斷連線(完畢,異常)
9用戶端播放緩衝區剩餘的內容(或者停止)

整體似乎就是這麼簡單,我打算用VB.NET(2k3)+ DX9SDK(05summer)做.中間用的就是wav的網路播放,雖然看起來是p2p的,但是畢竟還是CS啊.最多同時支援兩個使用者,因為不想牽扯多socket多線程太多.

如果要想設計的更加合理一點,那麼各種外掛程式都要預留介面,比如那個壓縮,完全可以獨立出來,然後根據客戶的請求選擇相應的壓縮/加密dll.這個就是架構設計了.我們用的是1服務端,2伺服器,目的是要討論實現,所以那種大型架構不用考慮...(哪有那麼多時間...再說幾百人也就是極限了)

原文：http://blog.csdn.net/a11s