很久沒(méi)有寫(xiě)博客了，最近一直在忙FLASH直播相關(guān)的事情，終于完成了階段性工作。先描述下我們的FLASH方案。我們主要用FLASH在瀏覽器展示實(shí)時(shí)游戲直播視頻，視頻可以除了可以再WEB上觀看，也可以在語(yǔ)音客戶(hù)端觀看和手機(jī)觀看。開(kāi)始我們采用基本的FLASH FMS/RTMP方式。測(cè)試下來(lái)有以下幾個(gè)問(wèn)題：

1、上傳和觀看必須用FLASH，RTMP和FLASH本身很多細(xì)節(jié)無(wú)法掌控。

2、帶寬問(wèn)題，F(xiàn)LASH編碼的視頻帶寬過(guò)大，視頻品質(zhì)相同的情況下640P的分辨率（70 ~ 90KB/S）與用X264應(yīng)用程序編碼(35 ~ 55KB/S)的同分辨率相比帶寬大30KB/S,這是不能接受的。

3、傳輸RTMP承載過(guò)于呆板和復(fù)雜，無(wú)法根據(jù)實(shí)時(shí)直播進(jìn)行優(yōu)化。

4、其他一些FLASH FMS上的問(wèn)題。例如：嚴(yán)格時(shí)間戳問(wèn)題、語(yǔ)音丟包問(wèn)題、延遲問(wèn)題等。

測(cè)試下來(lái)，無(wú)法跟我們現(xiàn)有的語(yǔ)音視頻應(yīng)用軟件做很好的兼容。經(jīng)過(guò)討論后，我們采用私有協(xié)議傳輸，前端用FLASH做展示。利用FLASH的TCP和FLV做一個(gè)仿應(yīng)用程序的WEB客戶(hù)端?？傮w方案描述如下：

1.實(shí)時(shí)上傳視頻通過(guò)語(yǔ)音客戶(hù)端進(jìn)行，客戶(hù)端用X264和HEAAC進(jìn)行進(jìn)行媒體編碼，通過(guò)私有的網(wǎng)絡(luò)協(xié)議上傳到媒體服務(wù)器上。

2.媒體服務(wù)器實(shí)現(xiàn)語(yǔ)音和視頻分離傳輸，為什么要分離傳輸呢？語(yǔ)音為了防止延遲，采用的是UDP方式傳輸，允許丟包，也可以采用語(yǔ)音特有的QOS算法進(jìn)行控制；視頻采用RUDP方式傳輸，不允許丟包，盡量減少延遲。分離傳輸還有一個(gè)好處就是可以根據(jù)語(yǔ)音和視頻帶寬特性調(diào)配具體的機(jī)房帶寬。

3、設(shè)計(jì)一個(gè)falsh gate服務(wù)來(lái)耦合WEB FLASH的接入。在這個(gè)網(wǎng)關(guān)上實(shí)現(xiàn)語(yǔ)音和視頻的合并、協(xié)議轉(zhuǎn)譯、FLASH的接入?yún)f(xié)議實(shí)現(xiàn)、FLASH的私有協(xié)議QOS保證、減少播放緩沖等待等。

4、實(shí)現(xiàn)一個(gè)WEB FLASH播放器。主要實(shí)現(xiàn)私有協(xié)議的接入、FLV緩沖播放、多路媒體管理、視頻JITTER BUFFER/語(yǔ)音JITTER BUFFER、核心C的模塊嵌入（SWC方式）、語(yǔ)音視頻同步、QOS評(píng)估和路線選擇、斷線重連等。

下圖是整個(gè)流數(shù)據(jù)的走向圖：

整個(gè)方案大概用了1個(gè)月實(shí)現(xiàn)，期間遇到了很多坑。如下：

1、在初期的實(shí)現(xiàn)的版本中，視頻在FLASH端感覺(jué)很卡，沒(méi)有丟包，在模擬客戶(hù)端中是完全正常的。我們查看FLV播放的幀，發(fā)現(xiàn)只有5幀被播放。后來(lái)我查看編碼器中的參數(shù)，發(fā)現(xiàn)在640P分辨率下用了H264的B幀編碼，從測(cè)試模擬程序來(lái)看，F(xiàn)LASH好像不支持B幀。把B幀去掉，進(jìn)行測(cè)試，正常了。

2、視頻分包問(wèn)題，在我們的客戶(hù)端傳輸網(wǎng)絡(luò)中，為了兼容P2P，我們將一幀視頻數(shù)據(jù)以4K大小進(jìn)行分包。因?yàn)閿?shù)據(jù)包是直接透?jìng)鞯紽LASH PLAYER上，必須在FLASH SWC中做組包。開(kāi)始一直因?yàn)榻M包方式不對(duì)，F(xiàn)LV播放無(wú)圖像或者出現(xiàn)馬賽克。后來(lái)嚴(yán)格調(diào)整時(shí)間戳和組包算法，正常了。時(shí)間戳一定要嚴(yán)格對(duì)齊，至少在FLV播放前是這樣的。

3、語(yǔ)音疊幀問(wèn)題，我們采用HEAAC進(jìn)行編碼，1秒鐘會(huì)產(chǎn)生22 ~ 23幀數(shù)據(jù)，在客戶(hù)端為了減少UDP報(bào)文的數(shù)量，采用了3幀疊成一個(gè)語(yǔ)音報(bào)文，這樣時(shí)間戳在報(bào)文中是最后一幀數(shù)據(jù)的時(shí)間戳，在FLASH播放端處理的時(shí)候，開(kāi)始以最后時(shí)間戳進(jìn)行播放，聲音很鈍。后來(lái)進(jìn)行測(cè)試和問(wèn)題查找，發(fā)現(xiàn)在時(shí)間戳上，進(jìn)行時(shí)間戳完全校驗(yàn)，收到一個(gè)語(yǔ)音包后進(jìn)行拆幀，第一幀的時(shí)間戳是TS - 2*44,第二幀的時(shí)間戳是TS - 44,第三幀是TS。進(jìn)行測(cè)試，完全正常了。

4、語(yǔ)音采樣率的坑，我們?cè)诳蛻?hù)端都是采用48KHZ的雙聲道采樣編碼，在FLASH PLAYER FLV完全無(wú)法聽(tīng)到聲音。后來(lái)查找FLASH支持的采用，才發(fā)現(xiàn)只支持11KHZ,22KHZ,44.1KHZ采樣。但是我們的HEAAC中好像沒(méi)有支持44.1KHZ的采樣編碼?；剡^(guò)頭進(jìn)行HEAAC的改造，把44.1KHZ的采用率編碼加上。進(jìn)行測(cè)試，正常通過(guò)。

5、FLASH PLAYER播放器內(nèi)存泄露問(wèn)題。在長(zhǎng)時(shí)間運(yùn)行過(guò)程中，瀏覽器的內(nèi)存越來(lái)越大，開(kāi)始毫無(wú)頭緒。后來(lái)經(jīng)過(guò)仔細(xì)查找，發(fā)現(xiàn)是SWC(flash 嵌入C模塊)有內(nèi)存泄露。用工具經(jīng)常排查，修改對(duì)應(yīng)FLASH 嵌入C中的內(nèi)存泄露問(wèn)題，進(jìn)行測(cè)試，內(nèi)存正常。

6、FLASH POLICY FILE問(wèn)題，在FLASH 使用TCP連接外網(wǎng)服務(wù)器時(shí)，做過(guò)網(wǎng)游的同學(xué)應(yīng)該知道有個(gè)策略驗(yàn)證。我按照網(wǎng)絡(luò)上搜索的格式填寫(xiě)回應(yīng)后，F(xiàn)LASH還是拒絕工作。進(jìn)行抓包查看，發(fā)現(xiàn)POLICY報(bào)文完全正確。查找ADOBE網(wǎng)站上的資料，發(fā)現(xiàn)在服務(wù)端的SOCKET必須用同步SOCKET進(jìn)行POLICY回應(yīng)，客戶(hù)端才會(huì)生效。因?yàn)槲覀兎?wù)器采用的都是EPOLL ET模式，所以沒(méi)辦法。只好另外起一個(gè)監(jiān)聽(tīng)843端口的同步SOCKET線程進(jìn)行POLICY響應(yīng)。進(jìn)行測(cè)試，正常了。

總結(jié)，F(xiàn)LASH私有協(xié)議視頻直播中，由于很多細(xì)節(jié)FLASH并沒(méi)有公開(kāi)，在開(kāi)發(fā)進(jìn)度上會(huì)比FMS RTMP方案慢很多，成本也大很多。但一旦做成了，視頻直播的效果和服務(wù)器部署不會(huì)受FMS和RTMP的限制，可以做更多結(jié)合自身業(yè)務(wù)的優(yōu)化。帶寬成本也小近30%。私有協(xié)議還有個(gè)一個(gè)好處就是可以做到多屏融合，移動(dòng)端、WEB端、PC客戶(hù)端任意兼容。這是值得的。