手機流媒體開發的總結

發布時間：20090410  作者：MaxBlog   轉載出處：MaxBlog的BLOG　推薦人：念雪

前一階段的手機線上流媒體項目終於告一段落，以下在開發方面做些總結和沉澱： 　　1、手機上開發線上流媒體播放，存在不少限制，包括： 　　1)手機網速有限，GPRS一般是5K/s左右;EDGE一般是10K/S左右; 　　2)手機的CPU頻率普遍不高，導致解碼效率很低; 　　3)手機的平台眾多(Symbian/PPC/Java/MTK); 　　2、由於手機網速有限，因此，針對不同的網速，應該製作不同的版本，以便讓使用者根據自己的手機和網路環境選擇合適的版本觀看;當然，不同的碼流視頻，解析度也應該不同，比如176*144, 176*208, Q屏等; 　　3、一般基於開源ffmpeg庫進行手機平台的移植，可以有效提高開發進度; 　　4、由於手機網速低的限制，因此，需要儘可能的降低視頻的碼流。但同時，我們又希望擷取清晰和流暢的視頻播放效果，這其實是一個矛盾體。目前來看，採用H264編解碼是一個不錯的結果，因為H264的壓縮率遠高於H263，而且也是專為手機上應用的編解碼演算法; 　　5、由於手機CPU頻率不高的原因，且手機在下載視頻資料的同時，還要即時進行解碼和視頻畫面放大縮小，因此低端的手機基本上很難獲得良好的播放體驗。所以建議只在比較高端的手機平台上開發，比如Symbian/PPC(windows mobie)，Java平台估計得忽略了; 　　6、雖然是線上視頻播放，但也應該包含本地播放器應有的功能，包括全屏、非全屏、靜音、快進快退、聲音調節、暫停、重放等功能; 　　7、播放的視頻源的解析度本身是固定的，比如176*208，在不同解析度的手機上播放，則可能需要進行相應的放大或縮小，一般採用線性插值或二次線性插值演算法進行放大或縮小，需要注意這些放大或縮小演算法的運算所佔的資源，如果過高，需要調整演算法，或採用輕量級的演算法，保證畫面的清晰與流暢播放; 　　8、非常重要的一個問題：採用多線程或非同步方式，保證流媒體資料轉送的連續性。具體說明如下： 　　用戶端 <----> 網關 <----> 流媒體伺服器 　　請求 -------------------------> 　　響應 <------------------------- 　　如上所示，每次用戶端向流媒體伺服器發送擷取視頻資料，到接收到視頻資料，是有一個時間周期的，設為T1。在T1時間內，用戶端除了在播放視頻外，沒有其它處理，網路也可能是閒置。因此需要充分利用這個T1時間，在T1時間內的一個合理時間點，發送下一個請求，這樣就可以儘可能保證伺服器返回的視頻資料是連續的，從而充分利用了整個網路頻寬進行傳輸資料; 　　用戶端 <----> 網關 <----> 流媒體伺服器 　　請求1 -------------------------> 　　請求2 ----------------------> 　　響應1 <------------------------- 　　響應2 <---------------------- 　　9、如果是採用ffmpeg作為核心的容器解析和解碼引擎，可以考慮針對手機的特殊性在ffmpeg方面進行核心最佳化，比如從編碼方面進行適當調整，可以提高解碼效率，從而提高手機端解碼效率，提高播放流暢性(可以達到20%以上的效果，具體細節以後再描述); 　　10、還需要特別注意音視頻同步的問題，線上播放視頻與本地播放有很多不同的地方，需要考慮在各種異常情況下，如何保證音視頻都能同步，適當的進行部分幀資料的丟棄是必須的; 　　11、基本上所有做手機上的網路應用，都繞不開移動的cmwap網關。cmwap網關對外只開發標準的http介面，因此，所有的手機連網應用，都需要考慮如何基於http進行協議的設計，或者考慮如何基於http代理的方式進行穿透cmwap網關; 　　12、為了更好的在全國範圍內穿透cmwap網關，每次傳輸的資料包大小建議在300K左右，如果過大，某些省份的cmwap網關可能會攔截;(其實手機上的下載工具在進行分段下載時也同樣需要考慮這個問題) 　　13、一般的電視直播，都是需要使用專門的採集卡，接入類比或數字訊號，利用directShow的架構進行聲音、視頻資料擷取和同步，再進行編碼、合并到容器和傳輸(比如mp4/mtk/wmv); 　　14、基於網頁的採集，可以查看我之前的一篇文章，利用顯卡資料的鏡像驅動，可以在指定地區內對視頻資料進行抓取，同時通過音效卡捕獲聲音，再對音視頻進行同步、合并到容器(比如mp4/mtk/wmv); 　　如果都能考慮到並解決好以上提到的這些問題，這個手機流媒體產品就具備了成功的條件。