基于FFmpeg+nginx技術的RTSP轉RTMP架構實現

邰非 謝周鵬 宋培龍

1.河海大學理學院;2.常州市中級人民法院信息處;3.南京航星信息技術有限公司研發中心

當前網絡高清攝像機都內置提供RTSP流服務[1-2],借助VLC等客戶端工具可以直接連接RTSP流來觀摩,也可以通過VLC所提供的組件服務或是其他第三方服務將接收流功能封裝成插件,結合行業業務流程實現應用。基于Web端的開發可以使用這些插件。在PC上通過Web頁面下載插件獲取RTSP流進行播放,在移動端則通過小程序或插件載體來獲取流。無論是插件還是小程序都會帶來便捷性、安全性等方面的影響。HTML5雖然提供了視頻標簽Video,但只支持MP4、WebM、OGG三種格式。本文所給出的實現架構是通過Video.js庫來實現無插件RTMP播放流[1-2],并提出未來不支持flash瀏覽器上的無插件播放方案。

0 引言

隨著網絡帶寬的不斷提高,流媒體的應用也越來越廣泛,一方面客戶端從早先的PC機到現在的移動設備,如智能手機、iPad,另一方面服務端媒體網站提供了大量內容豐富的音視頻資源,支持在線直播、點播等各種訪問方式。由此而產生了一系列的行業應用,如基于流媒體交互式教學應用的遠程教育,還有各種網絡直播、點播及視頻會議系統,雖然有些概念早期都有,但應用內涵是以靜態、單向、非富媒體的形式展現,個人體驗、互動性、實時性等都不理想。如何將這些富媒體以方便的方式提供給各種類型的客戶端去使用,成為當下應用研究的一個焦點。本文主要針對的是富媒體為流媒體時,如何通過技術手段,讓客戶端在無插件的狀態下播放,眾所周知插件安裝會占用資源相對較少的移動設備,且會帶來安全性問題,而在移動設備已成支付首選工具的時代,安全性的問題更加突出。

1 技術路線背景

1.1 協議簡介及應用

RTSP全稱:Real Time Streaming Protocol,即實時流傳輸協議,屬于TCP/IP[2]應用層協議,它定義了一對多應用程序如何有效地通過I P網絡傳送多媒體數據。RTSP在體系結構上位于RTP和RTCP之上,它使用TCP或UDP[2]完成數據傳輸。RTSP提供完整的交互過程,包括發起會話Session、創建傳輸機制SETUP、播放PLAY、錄制RECORD、停止TEARDOWN。這些特性易于控制流媒體播放[1],當前很多高清網絡攝像機都內置支持RTSP流服務。

RTMP全稱:Real Time Messaging Protocol,即實時消息傳輸協議,該協議屬于TCP/IP的應用層協議,是用來進行實時數據通信的網絡協議,主要用來在Flash/AIR平臺進行音視頻和數據通信。包括支持RTMP協議的流媒體/交互服務器[3]。

對于RTSP流可以通過插件的形式在PC端播放,也可能通過小程序或插件的形式在移動端播放,但插件本身是受許多安全性限制,在使用上并不方便,而對于RTMP流來說,則不存在這樣的問題,只要瀏覽器支持Flash,就可以直接播放RTMP流。

1.2 基于Nginx的服務器架構與流程

如圖1所示,網絡高清攝像機提供了RTSP流,服務器端可通過拉流的方式,從這些攝像機上獲取音視頻流,再推送到RTMP服務器,RTMP服務器完成Http.flash或Http.flv格式封裝,提供給訪問的客戶端實現直播功能。RTMP服務器可選用Nginx服務器,該服務器提供RTSP拉流、RTSP轉RTMP、RTMP轉Http.flash或Http.flv的功能[4]。

圖1 RTSP轉RTMP架構部署Fig.1 RTSP to RTMP architecture deployment

RTSP轉RTMP使用了FFmpeg技術。FFmpeg為開源項目,采用LGPL或GPL許可證,它可以用來錄制、轉換數字音視頻,并可以流的方式為客戶提供服務,其底層使用了非常先進的音視頻編解碼庫Libavcodec。本文的架構中采用了該項技術,實現RTSP轉RTMP,并按需求封裝成Http.flash或Http.flv格式的功能。另外通過FFmpeg命令還可以對多路RTSP流進行合并處理,提供軟拼裝流的服務。

圖2 從協議、技術層面給出整個架構實現的。源可能有兩種,一種是RTSP流源,市面上的高清攝像機基本都內置這種協議,另一種是RTMP流源,需要專門定制,這類攝像機無需有固定IP即可推流,可直接接入云服務器做直播,相比于RTSP,如采用H.264和AAC編碼,則720P/30FPS僅需要512Kbps～1Mbps碼流,RTSP大約為3Mbps,可見會大大降低帶寬成本。就本文所提供的框架而言,如果前端攝像機提供RTMP流,可繞過RTSP流服務器,直接接到RTMP流服務器上,對RTMP流提供Http.flash或Http.flv封裝[4]就可以了。

圖2 協議轉換、封裝、播放技術關聯圖Fig.2 Association diagram of protocol conversion, encapsulation,and playback technology

2 實現算法描述

如圖3給出了算法的關鍵流程。音視頻源有兩種,一種是RTSP源,另一種為RTMP源,如果是RTSP源則將其轉為RTMP源,這里提一下為什么要轉為RTMP流,因為這是實現Web頁面無插件播放的基礎,插件本身會引發安全性問題,很多殺毒軟件和防火墻在默認情況下是會攔截這類插件的下載與運行。

圖3 算法流程圖Fig.3 Algorithm flow chart

通過FFmpeg SDK,可以很方便地將RTSP流轉為RTMP流,RTMP流到達Nginx服務器,配置該服務器,可將RTMP再次封裝成Http.flash格式、Http.flv格式或HLS格式,這三種格式都是基于Http實現的,可以不受防火墻的限制。考慮到移動設備的瀏覽器內核的差異性,將Android與ios兩大平臺分別處理,蘋果ios自帶瀏覽器只能播放HLS格式,Android自帶瀏覽器則可以播放另外兩種。考慮到2020年谷歌的Chrome、微軟的Edge不再支持Flash,需要對瀏覽器是否支持Flash作一個判斷,如果支持則使用Http.flash格式的流,不支持就采用Http.flv格式,Video.js庫和Flv.js庫[4]提供Http.Flv格式流的播放。另外Nginx服務器可以提供負載均衡,是目前較為流行的流媒體發布服務器。

對于另一些應用場景,會有多畫面合成的要求,在源端可以進行軟處理或硬處理,所謂軟處理是用FFmpeg SDK對多路流進行合流編碼[5-6]。硬處理則利用采集板卡將多路采集信號合并成一路。前者效率低,延遲較大。后者效率高,延遲較小,但成本相對高。對于拼裝畫面在客戶端通過區域劃分與識別,可最大化焦點畫面,達到最佳的觀看效果。

3 結語

流媒體技術是音視頻數據在互聯網上應用最為廣泛的技術之一,無論是個人、學校、機關事業單位還是企業,無不有其應用場景,其易用性、安全性、健壯性會直接影響到用戶的體驗。通過各項技術的組合,可以為不同的客戶提供所需的解決方案。本文中所涉及的FFmpeg+Nginx技術架構是結合客戶端的需求而提出的,在實際運用收到了良好的效果,當然其中還有不足之處,如延遲問題,最好的方案是從采集源端直接定制,這是硬件廠商后面要做的工作。

引用

[1] 鐘玉琢.流媒體與視頻服務器[M].北京:清華大學出版社,2000.

[2] W.Richard Stevens.TCP/IP Illustrated Volume 1(The Protocols)[M].北京:機械工業出版社,2005.

[3] 孫曉剛.面向軟件工程的Visula C++網絡程序開發[M].北京:清華大學出版社,2004.

[4] 孫衛琴.Tomcat與Java Web開發技術詳解(第2版)[M].北京:電子工業出版社,2009.

[5] 楊天路.P2P網絡技術原理與C++開發案例[M].北京:人民郵電出版社,2008.

[6] Martin Fowler.重構:改善既有代碼的設計(中文版)[M].北京:中國電力出版社,2006.