整合營銷服務商

          電腦端+手機端+微信端=數據同步管理

          免費咨詢熱線:

          “新技術”主題論壇:HTML5和OTT游戲的未來之旅

          “新技術”主題論壇:HTML5和OTT游戲的未來之旅

          術是游戲的土壤,每一次革新都給整個產業翻天覆地的變化。12月18日,在與第十一屆“中國游戲產業年會”同期舉行的首屆“中國游戲產品經理大會”上,將設置“新技術帶來的產品變革”主題論壇,邀請領域內重量級嘉賓,圍繞HTML5和OTT這兩項即將深刻改變游戲和整個互聯網產業的關鍵技術進行深入探討,火星撞地球,精彩不容錯過。

          HTML5

          2014年10月29日, 萬維網聯盟(W3C)宣告,經過8年的反復探討和修訂,HTML5的標準終于正式完成;微信小游戲《圍住神經貓》一夜爆紅,創造了3天擁有500萬用戶和1億次訪問量的奇跡。人們猛然察覺:HTML5游戲真的來了。事實上,進過多年的積累與沉淀,HTML5游戲技術已經達到了一個微妙的臨界點,目前以PC客戶端和游戲APP在內的現有主流游戲形式將有翻天覆地的變化。

          本次主題論壇特意邀請了締造《圍住神經貓》的白鷺引擎創始人兼CEO陳書藝先生,以及戰斗在HTML5游戲研發和推廣第一線的眾多大咖,一起暢談HTML5游戲的未來。

          OTT

          OTT的意義在于使流量更加不受限制的變成人們所需要的各種服務和內容,消弭了硬件和軟件、傳統產業和互聯網產業之間的巨大鴻溝,由此產生一個更為開放和龐大的產業鏈。游戲作為互聯網一重大內容分野,其格局和形態也將隨之發生改變。

          一方面優秀的游戲使得OTT的內容更加充實,給了習慣駐留客廳的用戶以更多體驗選擇,讓他們樂意留在屏幕前;另一方面OTT使得游戲能滲入家庭客廳——這一前景廣闊而又夢寐以求的全新市場。

          本次主題論壇特意邀請了浙江華數游戲基地總經理章璋等重要嘉賓,為在場的觀眾一展OTT游戲的廣闊前景。

          主持人:

          7k7k市場部副總裁譚運鵬

          部分嘉賓名單:

          白鷺引擎創始人兼ceo陳書藝

          浙江華數游戲基地總經理章璋

          37游戲產品高級副總裁胡宇航

          游久時代研發副總裁賈卓倫

          中娛在線ceo蔣宇彤

          點擊下面相關鏈接,進入年會報名頁面

          2月18日,作為2014年“中國游戲產業年會”的系列活動,首屆“中國游戲產品經理大會”成功舉行,受到了業界的廣泛期待和歡迎肯定,其舉辦的形式和內容都得到巨大的啟發。

          CP和游戲制作人需更多展示機會

          本次“中國游戲產品經理大會”共有近20名國內領軍游戲平臺負責人、一線游戲制作人出席并參與了演講和點評,但仍就難以滿足現場觀眾的需求,另一方面,由于時間限制,幾乎所有CP演講嘉賓都沒能完成所有演講與分享,足見機會對其珍貴程度。

          像“中國游戲產業年會”這樣大型的產業會議的機會更是彌足珍貴,未來的經理大會將更為廣泛的吸收游戲CP的報名,并且應參會者的要求會議時間也適當延長,以為國內游戲制作者和產品提供更多的展現機會。

          優秀產品需多環節通力協作完成

          移動互聯網下的游戲產業已經形成一個分工格外細致的龐大產業,本次經理大會將處于游戲產業鏈不同環節的人物匯聚到了一起,各自對自身所扮演的角色進行闡述,事實證明形成了良好的聚合效益。

          作為游戲平臺方代表,騰訊和百度的平臺主要技術負責人都出席了會議并發表演講,包含了眾多廣大CP們普遍關心的關鍵性問題,以及一些啟發性強烈的新鮮論點;如百度移動游戲技術產品總監李顏江提出了百度平臺的學習模型,通過這個模型平臺可以打造精準的歷史模型和綜合評價體系,以實現平臺資源的最大優化與分配;而騰訊應用寶開發平臺總監陳鵬則為現場觀眾介紹了騰訊平臺的首發政策和數據。

          而針對同一游戲技術的溝通和交流,更令不同環節的游戲人大受裨益。如本次經理大會將HTML5技術列為重大議題,CP、平臺和引擎技術商的代表悉數登場。如一手締造了HTML5游戲神話的《圍住神經貓》白鷺引擎創始人陳書藝表示,小型休閑游戲已經不是發展的重點,國內月收入超過百萬級的 HTML5游戲廠商已超十家,這將對游戲CP和游戲平臺帶來巨大影響;從2011年就開始進行HTML5游戲開發探索的中娛在線CEO蔣宇彤表示,之前全球范圍內都沒有一個真正成熟的HTML5游戲開發環境,但白鷺的出現令這個環境發生了巨大改變;華數游戲基地總經理章璋則從電視OTT平臺的角度佐證,華數近期推出的HTML5平臺極大地改變了整個業務面貌。

          技術交叉融合成熱點

          此外,不同游戲技術之間的交叉融合也是本次經理大會重點關注領域。華數游戲基地總經理章璋表示華數11月18號在OTT機頂盒和電視機上面推出了HTML5平臺,包括了視頻媒體、游戲電視頻道的點播推廣以及一些HTML5的游戲賞玩等一系列的全新業務。由于技術的交叉融合往往給產業帶來翻天覆地的變化,勢必成為未來經理大會的一大重點關注領域。

          首屆“中國游戲產品經理大會”之所以成功為行業帶來巨大啟發,與其新穎的形式、貼近廠商需求的主題和內容有關。在未來,大會還將以此為目標,不斷在形式和內容上進行擴容和革新,力爭為游戲行業帶來更具價值的游戲盛會,推升與改善中國游戲生態,最終實現產業長期繁榮的目標。

          .引言

          本篇文章是基于上篇文章去編寫的,繼續講解協議轉換的原理,可以看看前面的文章,能夠更好理解本篇文章,參考列表如下。

          聊聊視頻會議系統中web端與客戶端通信的關鍵技術設計(1)

          1.系統框架

          本文主要講解視頻會議中協議轉換的設計,包括Web Socket-TCP 協議和 Web Socket-RTMP 協議的兩個雙向轉換,進而實現 PC Client、Flash Client 和 HTML5 Client 間視音頻實時通信的視頻會議應用。設計多種協議間轉換方案,就是為了既能夠通過PC Client參與視頻會議,也能夠通過Flash Client加入視頻會議,甚至能通過HTML5 Client接入視頻會議,三者之間相互通信。雖然市面上有這種解決方案,還是想通過一些實際的底層,去分析怎樣去解決這些問題,而不是拿來直接使用,而不知道底層發生了什么。

          本文舉例的服務器系統包括了服務器(Web 服務器和流媒體服務器)、數據庫、多點控制單元 MCU、傳輸網絡、相關視音頻設備以及客戶端。整個軟硬件系統的框架如下圖所示:

          軟硬件系統的框架


          可以看出該系統現有兩種客戶端:PC Client 和 Flash Client。有兩種流媒體服務器,包括私有流媒體服務器V5和Red5服務器。下面可以剖析下整個系統。

          (1)PC Client 和 Flash Client 都是通過 XMPP 協議與 Web 服務器進行信令交互,如連接建立、建立流、身份驗證、信令正文以及連接斷開。

          (2)PC Client 通過 HTTP 協議實現“發送用戶信息”、“傳輸用戶文本”以及“獲取用戶列表”等簡單功能。Flash Client 是一種 Web 客戶端,需要與 Web 服務器進行視頻會議應用程序交互,使用 HTTP 協議傳輸大量的數據,如地址、端口、會議房間等流媒體服務器信息。

          (3)PC Client 底層也是通過 TCP 協議與 V5 服務器進行音視頻通信,其中 TCP 所承載視音頻數據是一種“借用”RTP/RTCP 協議頭部的自定義報文格式Flash Client 將視頻和音頻分開處理:視頻通過 RTMP 協議與 Red5 服務器交互;音頻通過 TCP 協議與 V5 服務器交互,并且采用與 PC Client 相同的自定義報文格式。


          Flash Client 將視頻和音頻分開處理!由于音頻數據相對較小,Flash Client 便采用基于 TCP 的自定義報文格式接發音頻數據,而沒有直接使用 RTMP 傳輸音頻數據。那么PC Client 與 Flash Client 間音頻交互和兩個 PC Client 間音頻交互相同。當初,Flash Client也打算基于 TCP 的自定義報文格式接發視頻數據,但是視頻流相對較大且壓縮成 H.264時十分消耗內存及 CPU,只好采用 RTMP 傳輸視頻數據。最終,系統采用 Red5服務器(也可以使用其它方案)作為 RTMP 中轉并添加協議轉換功能,實現 PC Client 與 Flash Client 視頻交互。


          2.傳輸協議的關系

          實際中還是推薦使用Nginx服務器做,基于第三方模塊 nginx-rtmp-module 的 Nginx 服務器可作為 RTMP 服務器,可以替換 Red5 服務器。但是該第三方模塊尚未提供一對多實時通信功能,無法滿足視頻會議多用戶應用需求。最近SRS服務器集成了webrtc,這個應該能夠滿足服務端的要求,我沒有測試過了,如果有人測試了,可以私信或者評論區回復。這里就使用第三方模塊進行擴展設計。

          將 HTML5 Client 融入整個系統時候,我們必須實現 HTML5 Client 與現存的兩類客戶端間實時音視頻通信。下面從音頻和視頻兩個角度分析該系統傳輸協議間關系。

          (1)音頻交互

          鑒于 PC Client 和 Flash Client 使用相同的音頻處理方式,HTML5 Client 可采用基于Web Socket 協議傳輸音頻數據,并且音頻數據也采用自定義報文格式。那么各種客戶端之間音頻流上傳和接收流程圖,如下圖所示:


          客戶端間音頻流上傳和接收流程圖客戶端間音頻流上傳和接收流程圖

          針對 HTML5 Client,主要分析如下:PC Client 或 Flash Client 的音頻上傳通過 TCP協議,HTML5 Client 通過 Web Socket 協議接收;HTML5 Client 通過 Web Socket 協議上傳音頻,PC Client 或 Flash Client 通過 TCP 協議接收音頻。那么音頻方面可得如下結論:當 HTML5 Client 融入視頻會議系統時,整個 系統需要實現 Web Socket-TCP 協議之間的轉換

          (2)視頻交互

          前文可知,PC Client底層采用TCP 協議收發視頻數據;Flash Client 采用 RTMP 協議收發視頻數據。根據 HTML5 Client 處理音頻的方式,那么傳輸視頻數據時它仍可采用Web Socket 協議,并且視頻數據也采用自定義報文格式。因此,各客戶端之間視頻流上傳和接收流程圖,如下圖所示:


          客戶端間視頻流上傳和接收流程圖客戶端間視頻流上傳和接收流程圖

          針對 HTML5 Client,那么視頻方面可得如下結論:當 HTML5 Client 與 Flash Client視頻通信時,系統需要實現 Web Socket-RTMP 協議間的轉換;當 HTML5 Client 與 PCClient 視頻通信時,需要實現 Web Socket-TCP 協議間的轉換。

          通 過 實 現 Web Socket-TCP 協 議 和Web Socket-RTMP 協議的兩個轉換,將 HTML5 Client 融入系統。


          3.可行方案分析

          通過分析可行性方案,選取最優的方案。

          (1)PC Client 視音頻數據和 Flash Client 音頻數據都是通過 TCP 協議上傳到服務器中私有流媒體服務器 V5,接著 V5 服務器的 TCP 模塊會進行分發處理。因而,HTML5 Client可使用Web Socket協議從V5服務器的TCP模塊獲得這些數據。這個過程需要TCP轉Web Socket 協議。反之,需要 Web Socket 轉 TCP 協議。可見,兩個轉換都位于 V5 服務器。V5 服務器添加 Web Socket協議處理也非常簡單。為了 系統的穩定性,可直接修改 V5 服務器的 TCP 模塊,實現 Web Socket-TCP 雙向轉換。Web Socket-TCP 轉換方案設計如下圖所示:


          Web Socket-TCP 轉換方案

          (2)Web Socket-RTMP 協議轉換

          Flash Client 與 HTML5 Client 之間視頻交互,引起 Web Socket-RTMP 協議轉換。FlashClient 通過 RTMP 協議將視頻數據上傳到 Nginx 服務器,而 HTML5 Client 需要使用Web Socket 協議獲取這些視頻數據。 前面已經提到,Nginx 通過第三方 RTMP 模塊為 Flash Client 提供視頻服務。最初,打算使用 V5 服務器中轉視頻的方式:Nginx 的 RTMP模塊將 Flash Client 上傳的視頻轉發給 V5 服務器,然后 HTML5 Client 從 V5 服務器獲取視頻數據。但是測試發現,延遲至少 5s,不滿足視頻會議實時要求。隨著 Web Socket協議的廣泛應用,Nginx 論壇也出現了一些第三方模塊(HTTP 模塊)支持 Web Socket處理。因此,我選擇直接基于 Nginx服務器,先添加Web Socket處理(支持 HTML5 Client),然后添加 Web Socket-RTMP 協議轉換功能。在 Nginx 中,兩種協議的轉換既可以在 RTMP模塊中實現,也可以在 HTTP 模塊中實現。本文選擇“新增 HTTP 模塊”的方式來實現協議間相互轉換。

          基于 RTMP 模塊,實現協議間相互轉換。基于第三方 RTMP 框架,在現有 live模塊或本文 RTMP 擴展模塊實現 Web Socket 處理。該方案,Nginx 不需要特殊對待 HTML5 Client(等同于 Flash Client)。但是,它存在一個非常大的難題:RTMP 協議是 Adobe 公司的私有協議,因而 RTMP 服務器不易進行其他協議的開發。研究后可知,該方案工作量巨大,可行性很低。如下圖所示:


          RTMP 模塊實現轉換的設計


          基于 HTTP 第三方模塊,實現協議間相互轉換。RTMP 框架提供“ffmpeg 命令”支持流轉碼功能。本方案,首先利用 ffmpeg 命令的轉碼功能將 RTMP 流轉換為 HTTP流,然后使用支持 Web Socket 的 HTTP 第三方模塊 nchan 處理。這種方案,代碼工作量比較小,但是存在兩個缺點:一是只能從 RTMP 到 Web Socket 的單向轉換;二是整體可控性比較差。可控性差是因為 ffmpeg 命令無法根據實際網絡情況調整轉碼速率。該方案設計如下圖所示:


          RTMP 模塊命令和 HTTP 第三方模塊實現轉換

          新增 HTTP 模塊,實現協議間相互轉換。新增 HTTP 模塊既充當 HTML5 Client的 Web Socket 服務器,同時又充當 RTMP 模塊的”Flash 客戶端”,主要采用 Upstream機制實現。通過 Upstream 機制,基于 Web Socket 協議的 HTML5 Client 便能與新增 HTTP模塊視頻交互以及新增 HTTP 模塊可與上游 RTMP 服務器(RTMP 模塊)交互視頻數據。該方案可充分利用 Nginx 并發特性。新增 HTTP 模塊的方案設計如下圖所示。本次就選取這種方案。


          新增 HTTP 模塊實現轉換


          4.RTMP 擴展模塊設計

          添加第三方RTMP 模塊的Nginx 服務器可以支持 Flash Client,實現一對一實時流和一對多點播通信但是該第三方模塊尚未提供一對多實時流通信功能,因而無法滿足視頻會議多用戶應用需求。大家可以去試一試srs流媒體服務器的webrtc。

          每個模塊對于每個用戶會話存有一個獨立的上下文結構體(ctx,會話上下文)。會話上下文,一般在建立會話時建立并存于內存池中模塊指針數組。每個 RTMP 模塊自定義會話上下文的內容,這樣 RTMP 模塊就可以從會話上下文中獲取上下文信息,會話上下文在會話結束時自動銷毀。RTMP 會話上下文,一般都包括指向用戶會話的指針,進而通過上下文識別會話主體。為了滿足視頻會議中多 Flash Client 的應用需求,我們需要將各用戶會話上下文串起來。本文采用簡單且高效的單鏈表方式。視頻會議多用戶應用中,某個用戶發布且有多個用戶播放(類似于廣播)是最常見應用場景,因而會話上下文中需要添加標記位標識用戶類型。基于前面的分析,本文設計 RTMP 擴展模塊的會話上下文結構體,關鍵部分如下圖所示:


          本文設計的 RTMP 擴展模塊位于 RTMP 框架第四層,包括發布、播放、啟動、暫停、流開始、流結束以及音頻|視頻流處理等功能。這些指令一般就對應RTMP第三層模塊的方法。擴展模塊設計如圖所示:


          擴展模塊設計

          視頻會議多用戶應用的關鍵說明如下:

          (1)當用戶需要發布視頻時,會將會話上下文 publishing 置為 1,并將媒體流發給Nginx 服務器。用戶都通過配置文件 nginx.conf 與擴展模塊會話連接時建立會話上下文。

          (2)其他用戶作為接收者,會話上下文 publishing 取默認值 0,并等待接收媒體流。

          (3)擴展模塊通過調用RTMP框架第三層方法收到的視頻流,并發送給會話上下文 publishing 為 0 的用戶,即接收用戶,這些用戶收到視頻流后便可播放視頻。


          5.HTML5 Client設計

          5.1 自定義報文設計

          HTML5 Client 視音頻數據采用自定義報文(CELLPACKET)格式封裝,CELLPACKET 包括長度標識字段、RTP 頭部、RTPMM 頭部和視音頻數據流。CELLPACKET結構如下圖所示:

          CELLPACKET結構

          CELLPACKET 使用短整型變量 Length 標識該數據報的長度。之所以添加該字段,是因為視頻數據一般都比較大導致傳輸過程被分片,在接收端就需要按照該字段進行分片的整合。接著,CELLPACKE 直接包含 12bytes 的 RTP 頭部,為了滿足視頻會議的業務需求,CELLPACKE 頭部又增加了 20bytes 的 RTPMM 頭部。RTPMM 頭部是一種自定義的私有格式,如 MMID 表示媒體流 id、V/A Frame 標識視音頻數據幀類型等,RTPMM 頭部結構如下圖所示:


          下面對 RTPMM頭部各字段屬性進行詳細解釋:

          (1)V2RTP Version(8bits):協議版本號,默認為 1。

          (2)Flag(8bits):RR Flag,標識該報文中是否有 RR(特殊報告)。

          (3)Band Info(16bits):帶寬信息,標識 Audio/Video 通道的帶寬值。服務器會根據該值,及時調整發送速率。

          (4)Sub Number(8bits):分片序號,若音視頻數據分片,使用該字段值標識該分片位于第幾個,默認為 0,即不分片。

          (5)Total Num(8bits):分片總數,常和分片序號(Sub Number)組合使用,進而完成數據包重組。若分片序號字段不為 0,Total Num 則表示該分片的總數。

          (6)Seqence Number(16bits):序列號,標識媒體報文,該值會隨著報文自動遞增。

          (7)Timestamp(32bits):時間戳,采用絕對時間,標識報文封裝的時間。

          (8)MMID(32bits):數據流 id,該值與音視頻流一一對應,最重要的標識字段。

          (9)V/A Frame(8bits):音頻、視頻的幀類型。如果數據包是 Video 數據,該字段值 0表示 I 幀,1 表示 P 幀;如果報文是 Aduio 數據,0 表示普通幀,1 表示重要幀。該字段默認為 0。

          (10)Audio Burst(8bits):突發 Audio 標記字段,默認為 0。當客戶端靜音抑制一段時間后,突然非抑制 Audio 幀,那么該字段會取 TRUE。

          (11)Video Size(8bits):標識視頻數據大小,默認為 0。

          (12)Reserved(8bits):保留位,供將來擴展使用。


          5.2 HTML5 Client 相關設計

          HTML5 Client 與流媒體服務器建立 Web Socket 連接,通過 Web Socket API 發送和接收 Web Socket 音視頻數據。本文對 HTML5 Client 音視頻處理設計,如下圖所示:

          HTML5 Client 音視頻處理設計


          直接使用 HTML5 技術提供地 get User Media API 獲取本地視音頻。該 API訪問攝像頭和麥克風,啟動和獲取 Video 元素的視頻與音頻數據。Web 應用領域里,HTML5 已經可以通過 Java Script 腳本實現大量的音視頻編解碼器,其中比較流行的編解碼器包括:X264 視頻編解碼器、Open H264 視頻編解碼器以及 G.723 音頻編解碼器。如果你的video插件不支持視頻直播流顯示,可以采用固定周期地將視頻幀渲染到Canvas 的替代方法。目前一般集成了webrtc,使用起來更加方便。音視頻數據流向和結構如下圖所示:

          本文的HTML5 Client 視音頻數據采用自定義報文格式,那么現有的 HTML5 客戶端是無法直接識別、解析和封裝。因此,本文對 HTML5 Client 新增這些功能,設計如上圖所示。關于 HTML5 Client 增加的功能,說明如下:

          (1)將本地經編碼器處理過的視音頻數據流,先按照自定義報文格式封裝,接著將得到報文存入發送緩沖池,最后通過 Web Socket 發送出去。

          (2)當 HTML5 客戶端接收視音頻數據流時,觸發 Web Socket 連接獲取數據并存入接收緩沖池,按照自定義報文格式拆包,最后將所得的視音頻流送入對應解碼器。

          注意:采用Java Script 腳本來實現封裝和拆包功能。數據的傳送使用 Web Worker實現。


          6.Web Socket轉TCP 方案設計

          Web Socket-TCP 轉換可封裝于私有流媒體服務器 V5 的 TCP 模塊。本節詳細說明轉換方案的設計:對原 TCP 處理模塊增加 Web Socket 協議處理功能。該轉換先處理 Web Socket 協議握手過程,如解析握手請求與生成握手應答。握手成功后,該轉換再根據 Web Socket 數據幀對幀中有效負載解析或封裝。握手機制處理非常簡單,本節不描述。下面以 HTML5 Client 和 PC Client 間視音頻通信為例,說明 TCP 模塊新增處理 Web Socket 數據幀的設計思路,如下圖所示:


          HTML5 Client 和 PC Client 之間通信

          HTML5 Client1 發送音視頻數據流到 PC Client1,PC Client2 發送音視頻數據流到HTML5Client2。

          (1)當私有流媒體服務器 V5 收到 TCP 數據流時,根據數據流所連接類型分類處理。當連接不是 Web Socket 連接時,則對應著 PC Client,數據流直接走原 TCP 接收處理過程;當連接是 Web Socket 連接,即對應著 HTML5 Client,服務器根據 Web Socket數據幀格式,先去掉 Web Socket 頭部,接著走原TCP 接收處理過程。

          (2)當私有流媒體服務器 V5 發送 TCP 數據流時,也根據所連接類型分類處理。當連接不是 Web Socket 連接時,則對應著 PC Client,數據流直接走原 TCP 發送處理過程;當連接為 Web Socket 連接,即對應著 HTML5 Client,服務器根據 Web Socket 數據幀格式,先添加 Web Socket 頭部,接著走原TCP發送處理過程。

          可見 Web Socket-TCP轉換功能,V5 服務器端僅僅需要改變原 TCP 模塊中接收TCP數據流和發送 TCP 數據流兩部分功能函數。


          7.Web Socket轉RTMP 方案設計

          本文選擇 Nginx 服務器“新增 HTTP 模塊”方案,而該方案需要具有兩大功能:Web Socket 處理,Web Socket-RTMP 轉換。前者通過借鑒 Nginx 現有的第三方模塊 nchan,很容易實現,這里不再敘述。后者是本文研究的核心,主要涉及 Upstream 機制和視頻數據報文轉換。下面描述新增 HTTP 模塊的相關設計。

          Upstream 機制是 Nginx 提供一種全異步方式,能夠與第三方服務器交互,如建立TCP 連接、發送請求、接收響應以及關閉 TCP 連接。Upstream 機制十分高效,同時兼具簡單的特性:僅包括 8 個回調方法,用戶只需要根據自己的業務需求實現其中幾個回調方法即可。本文新增 HTTP 模塊需用到 Upstream 機制的 4 個回調方法:create_request、reinit_request、process_header 以及 finalize_request。

          下面就舉例說明create_request 和 process_header 兩個關鍵回調方法:

          (1)create_request 回調方法,Upstream 機制必須實現的方法。方案中該回調方法需將下游 TCP 連接讀寫事件置 empty_handler(不做任何事情,起阻塞作用)。該方法由 HTML5 Client 的第一個請求(Web Socket 握手請求)觸發,提取 Web Socket 握手信息供 process_header 回調方法處理進而建立 Web Socket 連接。

          (2)process_header 回調方法,是最重要的 Upstream 回調方法,由上游服務器返回第一個響應觸發。process_header 方法,包括兩個主要任務:建立 HTML5 Client 與新增模塊間 Web Socket 連接,建立新增模塊與 RTMP 服務器間 RTMP連接

          通過Upstream的4個回調方法,新增HTTP模塊成為HTML5 Client 和 RTMP 服務器的橋梁。HTML5 Client 成功建立與新增 HTTP 的 Web Socket 連接,普通 Flash Client與 RTMP 服務器(Nginx 的 RTMP 模塊)相連接,通過新增 HTTP 模塊這個橋梁,兩類客戶端已經“連通”,如下圖所示:


          Upstream 實現兩類客戶端連通


          描述 HTML5 Client 獲取 Flash Client 的視頻過程,即 RTMP 轉 Web Socket 過程,如下所示:

          (1)基于前面所述 Upstream 機制,兩類客戶端已經連通。

          (2)HTML5 Client 發送 PLAY 命令,該命令經新增 HTTP 模塊透傳給 RTMP 模塊。

          (3)RTMP 模塊會將指定 Flash Client 上傳視頻流以 RTMP 數據包返回。

          (4)新增 HTTP 模塊收到 RTMP 數據包,解析 RTMP 數據包中視頻數據,并將視頻數據重新封裝自定義數據報文格式,然后發送給 HTML5 Client。RTMP 轉 Web Socket 過程如下圖所示:


          RTMP 轉 Web Socket 過程

          上面第(4)步驟包括一個重要功能:HTML5 Client 視頻數據采用自定義報文,Flash Client視頻數據封裝于 RTMP 報文,因而我們必須在新增 HTTP 模塊添加視頻數據報文轉換功能。為了保障系統的穩定和轉換簡單化,HTML5 Client 采用與 Flash Client 相同的 H.264視頻數據格式。那么,視頻數據報文轉換可簡化為報文頭部轉換。兩類客戶端視頻報文轉換,如下圖所示:


          視頻報文轉換視頻報文轉換

          8.總結

          本文主要講解了HTML5 Client、RTMP 擴展模塊和多協議間轉換方案設計的原理。其中協議轉換設計包括了Web Socket到TCP相互轉換,Web Socket到RTMP相互轉換。針對上面的講的原理,如果目前有更好的商用穩定的框架,也歡迎大家能夠分享出來。后面再講講如何實現。歡迎關注,收藏,轉發,分享。

          后期關于項目知識,也會更新在微信公眾號“記錄世界 from antonio”,歡迎關注


          主站蜘蛛池模板: 免费无码一区二区三区蜜桃大| 精品一区二区久久久久久久网精| 日本视频一区在线观看免费| 国产精品伦子一区二区三区| 色窝窝无码一区二区三区| 亚洲色精品VR一区区三区| 久久精品午夜一区二区福利| 国产一区二区在线观看app| 日韩精品久久一区二区三区| 久久精品国产AV一区二区三区| 日本道免费精品一区二区| 一本色道久久综合一区| 丰满人妻一区二区三区视频| 麻豆视传媒一区二区三区| 精品人妻一区二区三区四区在线 | 麻豆va一区二区三区久久浪| 国产吧一区在线视频| 无码人妻精品一区二区三区99性| 色欲精品国产一区二区三区AV| 国精品无码一区二区三区左线| 国产一区二区免费| 国产在线精品一区二区不卡| 国产AV午夜精品一区二区三| 国产一区二区内射最近更新| 亚洲午夜福利AV一区二区无码| 亚洲国产综合无码一区| 亚洲综合一区二区国产精品| 亚洲av无码片区一区二区三区| 精品无码一区在线观看| 中文字幕一区二区三区人妻少妇| 中文字幕一区二区三区人妻少妇| 99国产精品欧美一区二区三区| 国产无人区一区二区三区| 亚洲AⅤ视频一区二区三区| 成人国产一区二区三区| 亚洲视频一区二区在线观看| 亚洲Av无码国产一区二区 | 亚洲AV无码第一区二区三区| 色一乱一伦一图一区二区精品| 久久精品国产AV一区二区三区| 美日韩一区二区三区|