柳 歡

（安徽省廣播電視科研所，安徽 合肥 230000）

0 引 言

隨著信息技術的發(fā)展，在線點播、直播、視頻聊天、遠程會議等已成為常態(tài)，短視頻平臺強勢增長，虛擬現實（Virtual Reality，VR）、增強現實（Augmented Reality，AR）、遠程醫(yī)療等越來越多音視頻應用場景被挖掘。音視頻技術需要不斷升級以支持新應用、新模式和新場景下的需求。

音視頻技術是將聲音或一系列靜態(tài)影像等模擬信號轉換成數字信號，再通過壓縮編碼、封裝等一系列處理，發(fā)送給接收端，接收端再解封裝、解碼還原成音視頻的技術。最初，人們獲取音視頻，需要將整個音視頻文件下載到本地，再利用播放器播放，通常需要花較長時間等待音視頻文件下載完成。隨著技術的發(fā)展，出現了兩種邊下載邊播放的技術，即超文本傳輸協議（HyperText Transfer Protocol，HTTP）漸進式下載和流媒體傳輸。其中，流媒體傳輸包括HTTP流式傳輸和實時流傳輸兩種方式。

1 HTTP漸進式下載

HTTP漸進式下載的原理基于音視頻文件的特點，即使用音視頻文件的元信息和部分幀數據就可以實現解碼播放。但通常音視頻的元信息不一定放在文件的開頭，如果按順序接收文件，一開始可能無法獲得元信息，就無法實現邊下載邊播放。因此，HTTP 1.1版本之后的協議增加了range-request請求，即在請求報文中有一個字段range來指定請求資源的字節(jié)范圍。這樣就可以跨字節(jié)獲得音視頻的元信息，從而實現邊下載邊解碼播放。

MP4和FLV格式的文件對HTTP漸進式下載支持比較好[1]。通常，元文件在文件的末尾，所以一般會發(fā)送3個請求，具體實現步驟如下：第一個請求先從媒體文件0 Byte開始找元文件；如果沒找到，則通過range-request發(fā)送第二個請求到媒體文件的末尾去找；找到元文件后，再發(fā)送一個請求從文件開頭開始，這時媒體文件開始解碼播放。如果媒體文件是經過優(yōu)化的，元文件放在開頭，則只需發(fā)送一個請求。

2 流媒體傳輸

流媒體傳輸原理是將音視頻文件通過一定的算法編碼壓縮成一個個壓縮包，再由流媒體服務器通過特定的網絡協議進行連續(xù)、實時的傳送，用戶端接收到壓縮包后再實時地解壓縮播放。

其中，傳輸層的網絡協議有用戶數據報協議（User Datagram Protocol，UDP）和傳輸控制協議（Transmission Control Protocol，TCP）。使用UDP協議，可以實現低時延，網絡出現分組丟失時，不會觸發(fā)重傳導致播放不流暢，適合對實時性要求較高的場景，比如實況轉播等。另外，UDP協議是無序的，需要額外的協議如實時傳輸協議（Real-time Transport Protocol，RTP）、實時流傳輸協議（Real Time Streaming Protocol，RTSP）輔助傳輸，增加成本；還有可能會被防火墻阻攔。使用TCP協議，可以實現有序可靠傳輸，通常應用在對實時性要求較低的場景中。

在TCP/UDP之上的協議主要有HTTP、RTSP、實時信息傳輸協議（Real Time Message Protocol，RTMP）、RTP等。根據協議或者是服務器的不同，流媒體傳輸主要分為HTTP流式傳輸和實時流傳輸。HTTP流式傳輸，通過HTTP協議順序下載文件，用戶只能觀看已下載的音視頻內容，無法快進到未下載部分。實時流傳輸，需要保持音視頻信號帶寬與網絡連接匹配，使音視頻能夠被實時看到，需要有專門的流媒體服務器與傳輸協議。下面分別介紹這兩種傳輸方式。

2.1 HTTP流式傳輸

HTTP流式傳輸是通過HTTP協議傳輸音視頻的。首先，在Web服務器端將音視頻文件分割成一個個很小的獨立切片，同時生成一個索引文件。索引文件記錄著一個個切片的地址。客戶端通過HTTP協議向服務器請求索引文件，再根據索引文件請求一個個切片文件，從而實現音視頻文件的播放，傳輸流程如圖1所示。

圖1 HTTP流式傳輸流程圖

HTTP流式傳輸具體實現主要有基于HTTP的自適應碼率流媒體（HTTP Live Streaming，HLS）流式傳輸、基于HTTP的動態(tài)自適應（Dynamic Adaptive Streaming over HTTP，DASH）流式傳輸[2]、基于Adobe的HTTP動態(tài)（HTTP Dynamic Streaming，HDS）流式傳輸等。這里介紹下HLS流式傳輸和DASH流式傳輸。

2.1.1 HLS流式傳輸

HLS協議是由蘋果公司針對移動端音視頻接收而開發(fā)的，現在很多桌面應用也支持該協議，比如H5就支持HLS協議。

2.1.1.1 HLS流式傳輸原理

HLS流式傳輸要求視頻編碼格式為H264，音頻編碼格式為AAC、MP3、AC-3，封裝格式為MPEG-2 TS。編碼器將輸入的音視頻數據轉換成支持的音視頻格式，再封裝為MPEG-2 TS格式文件，按一定的時間段（通常是10 s）切割成一個個ts文件，同一碼率的ts切片地址形成一個二級索引文件。根據這些不同碼率的二級索引文件地址再形成一個一級索引文件。索引文件的格式為m3u8。如果音視頻文件只有一個碼率，則只有一個索引文件。具體如圖2所示。

圖2 HLS音視頻切片分割圖

客戶端通過HTTP協議請求一級索引文件，根據自身網絡條件自適應地請求合適碼率的二級索引文件，從該索引文件中獲取適應碼率的ts切片地址，再請求ts文件，進而實現音視頻的播放。

2.1.1.2 HLS流式傳輸的應用

HLS流式傳輸通常應用在點播和直播中。其中，點播應用不需要更新索引文件，直播應用需要不斷更新索引文件。當采集端將視音頻流推送到服務器時，服務器將收到的信息流緩存一段時間封裝成ts文件，同時服務器會更新m3u8索引文件。播放端不斷從索引文件中獲取最新的ts文件，從而實現直播。

2.1.2 DASH流式傳輸

DASH協議是國際標準化組織（International Organization for Standardization，ISO）制定的開放協議。

2.1.2.1 DASH流式傳輸原理

DASH流式傳輸與HLS流類似，也是服務器端將媒體內容分割成一個個切片，每個切片可以存有不同的碼率，客戶端可以根據自身和網絡情況選擇不同的碼率播放。它的索引文件是MPD格式，格式如圖3所示，由外至內分別是Period（時間段）→AdaptationSet（自適應子集）→Representation（媒體展示）→Segment（分段）。Period將媒體內容按時間段劃分，一個DASH碼流可能有一個或多個時間段，一個時間段里面的內容不再變更；AdaptationSet是一個時間段里的不同媒體內容，如音頻、視頻、字幕等；Representation是同一媒體類型的不同碼率版本；Segment是同一碼率的媒體內容的多個分片地址，也就是真正的媒體內容地址。自適應播放就是在不同碼率的Representation之間切換。DASH流支持的視頻編碼格式有H264等，音頻編碼格式有AAC、MP3、AC-3等，封裝格式有MPEG-2 TS或MP4格式等多種格式，分片可以是MP4（fmp4）文件，也可以是ts文件。

圖3 MPD文件格式

2.1.2.2 DASH流式傳輸的應用

DASH流式傳輸通常應用在點播和直播中。點播不需要更新MPD文件，直播需要不斷更新MPD文件，添加新的Period，在新的Period里添加新的媒體內容。直播和點播就是通過不斷輪詢MPD、不斷發(fā)送HTTP請求媒體內容分片來實現的。

2.2 實時流傳輸

實時流傳輸需要保持音視頻信號帶寬與網絡連接匹配，需要有專門的流媒體服務器和傳輸協議，更有效地為用戶提供音視頻服務。實時流傳輸主要有基于RTMP協議的實時流傳輸[3-4]、基于RTP/RTCP協議的實時流傳輸[5]等。

2.2.1 基于RTMP協議的實時流傳輸

基于RTMP協議的實時流傳輸，是通過RTMP協議實現音視頻的實時傳送。RTMP協議是Adobe公司為Flash播放器與服務器進行音視頻數據傳輸而開發(fā)的。

RTMP的原理是在RTMP客戶端和RTMP服務器之間建立通信鏈路來實現數據快速、可靠傳輸。首先，在RTMP客戶端和RTMP服務器之間建立TCP連接，來保證信息傳輸的可靠性。然后，客戶端和服務器之間要進行RTMP握手，主要是為了驗證客戶端和服務器端使用的RTMP版本一致，相互之間可以通信，以及雙方的時間戳。具體流程如圖4所示。完成RTMP握手后，客戶端和服務器之間交互連接URL、音視頻編解碼器等信息實現網絡連接。它是服務器應用程序與客戶端之間的基礎連接，只能建立一個。完成網絡連接建立后，就可以建立網絡流。網絡流是服務器與客戶端發(fā)送多媒體數據通道，完成網絡流建立后就可以通過play等命令來實現音視頻的傳輸了。

圖4 RTMP握手

RTMP音視頻數據傳輸是發(fā)送端先將音視頻數據封裝成RTMP消息（每個RTMP消息都有一個Message ID），為了實現低時延，再把消息拆分成一個個更小的Chunk單元。其中，對于Chunk單元的大小，服務器和客戶端可以協商，通常音頻默認為64 Bytes，視頻默認為128 Bytes。完成拆分后，發(fā)送端再將這些Chunk單元發(fā)送給接收端。接收端接收到Chunk單元，根據Message ID恢復成RTMP消息，再解壓縮恢復成音視頻數據。RTMP協議就是這樣實現低時延音視頻傳輸的。

2.2.2 基于RTP/RTCP協議的實時流傳輸

基于RTP/RTCP協議的實時流傳輸，是通過RTP/RTCP協議來傳遞音視頻數據。RTP/RTCP協議是國際互聯網工程任務組（The Internet Engineering Task Force，IETF）為在網絡上實現一對一或一對多傳遞實時多媒體信息設計的，工作在應用層協議之下，TCP/UDP協議之上。RTP只負責傳遞音視頻數據，RTCP負責音視頻數據傳輸的質量控制、媒體間同步等。而發(fā)送端向誰發(fā)送音視頻、如何控制音視頻的播放，則由其他應用層協議如會話描述協議（Session Description Protocal，SDP）、會話初始協議（Session Initiation Protocol，SIP）、RTSP等來實現。RTP、RTCP通常工作在UDP協議之上，RTP端口在1 025到65 535之間選擇一個偶數端口，RTCP端口為相鄰的下一個奇數端口。協議層架構如圖5所示。

圖5 協議層架構

2.2.2.1 基于RTP/RTCP協議的實時流傳輸原理

應用程序建立一個RTP會話時，會確定一對傳輸地址。傳輸地址由一個網絡地址加兩個端口號組成，一個端口傳輸RTP數據包，用于傳輸音視頻信息；一個端口傳輸RTCP數據包，用于傳輸控制信息。上層將音視頻數據壓縮編碼后發(fā)送給RTP協議層，RTP協議層將音視頻數據封裝成RTP包發(fā)送給UDP層再發(fā)送到網絡；上層將控制信息發(fā)送給RTCP層，RTCP協議將控制信息封裝成RTCP包再發(fā)送到網絡。接收端處理就是上述過程的逆過程。RTP/RTCP傳輸流程如圖6所示。下面介紹下RTP、RTCP的包格式。

圖6 RTP/RTCP傳輸流程圖

2.2.2.2 RTP包格式

RTP包由RTP包頭+RTP載荷構成。RTP載荷就是實際要傳輸的音視頻數據。RTP包頭格式如圖7所示。前12 Bytes為固定頭，后面的部分為可選部分。

圖7 RTP包頭格式

有效載荷類型表示RTP載荷部分的數據類型，接收方可以根據載荷類型來進行解碼，恢復成音視頻。同步源標識發(fā)送RTP包的端。發(fā)送方每發(fā)送一個RTP包，序列號值加1。接收方可根據序列號值來排序、檢測丟包等。時間戳是RTP包第一個八位字節(jié)的采樣時刻，接收端可以用來計算延時、抖動和同步。參與源是指當幾個不同來源的RTP流通過混合器混合成一個新的RTP流，這個新流有一個同步源標識，而這些原同步源標識將作為新RTP流的參與源標識，目的站通過參與源標識來把不同RTP流分開。一個RTP流最多可以有15個參與源。CC表示參與源的數量。

2.2.2.3 RTCP包格式

RTCP協議主要是反饋當前RTP包傳輸質量及實現媒體間同步等。RTP會話期間，各參與者周期性地發(fā)送RTCP包，統(tǒng)計發(fā)送端發(fā)送RTP包信息以及接收端接收情況等。系統(tǒng)根據RTCP包信息來做出相應的調整，以便提供更好的傳輸服務。RTCP包有五種常用類型：發(fā)送端報告SR、接收端報告RR、源點描述SDES、BYE結束以及特定應用報告App。發(fā)送端報告SR是發(fā)送RTP流的端向所有接收端發(fā)送其傳輸和接收統(tǒng)計報告，以便讓接收端進行同步、計算丟包數、丟包率等。接收端報告RR，是接收端向所有端發(fā)送其RTP流接收情況統(tǒng)計報告，以便讓發(fā)送端知道其發(fā)送的RTP流被接收的情況，從而調整數據發(fā)送速率等。當一個端既是發(fā)送端也是接收端則發(fā)送SR報告，只作為接收端不作為發(fā)送端則發(fā)送RR報告。源點描述SDES描述會話參與者，包括參與者的規(guī)范名CNAME。CNAME可以用來實現同一參與者不同媒體源的同步，比如同一參與者的音頻流和視頻流是分開傳輸的，同步源標識不同但CNAME相同，就可以實現音頻和視頻的同步。BYE結束表示關閉一個源，即通知其他參會員者自己將退出會話。這里詳細介紹一下發(fā)送端報告SR，其報文格式如圖8所示。

圖8中，SSRC of sender表示該發(fā)送端的標識，NTS（分高位和低位）表示發(fā)送此報告時的絕對時間戳；RTS為相對時間戳，與RTP包的時間戳具有相同的初始值和單位；SPC代表該發(fā)送端從發(fā)送RTP包開始到此刻總共發(fā)送的RTP包數，SOC代表該發(fā)送端從發(fā)送RTP包開始到此刻總共發(fā)送的RTP包凈荷的總字節(jié)數。

下面是該發(fā)送端從別的發(fā)送端接收到的RTP包情況。

SSRC_1標識向該接收端發(fā)送RTP流的一個發(fā)送端，F表示從上一次RR報文發(fā)送之后，從SSRC_1發(fā)送端來的包的丟包率；C表示從開始接收SSRC_1數據包到當前時刻丟失的總包數，EHSN表示從SSRC_1接收到的RTP包的最大序列號，LSR表示最近接收到的SSRC_1 SR報文的時間戳，DLSR表示從最近接收到SSRC_1 SR報文到發(fā)送本報文的時延。

基于RTP/RTCP協議的實時流傳輸通過發(fā)送端發(fā)送RTP流傳輸音視頻信息，各參與者周期性發(fā)送RTCP包傳輸控制信息，接收端根據RTP包頭中的載荷類型、時間戳、序號以及RTCP SR包中的時間戳等信息將音視頻信息解析出來并實現同步；各參與者根據RTCP報告來評估網絡狀況，從而采取相應措施來調整傳輸質量。

目前，還有谷歌公司主導的網頁即時通信WebRTC（其實是RTP的一種實現，其中包含許多協議）、騰訊云等私有協議來實現音視頻傳輸。

3 幾種音視頻傳輸方法的優(yōu)缺點及應用

以上所述這些音視頻傳輸方式都具有不同的特點。例如，HTTP漸進式下載使用Web服務器，實現、維護簡單，不易被防火墻攔截，對MP4和FLV格式文件支持較好，但傳輸延遲長、文件會保存到本地占用存儲空間，保密性差；HLS協議的實現、維護簡單，可以自適應調節(jié)碼率，不易被防火墻攔截，但延遲較大，本地播放占用存儲空間且保密性差，支持的音視頻格式較少；DASH協議實現、維護簡單，可以自適應調節(jié)碼率，不易被防火墻攔截，延遲較HLS協議小，切片靈活，本地播放占用存儲空間且保密性差；RTMP協議實時播放、傳輸延遲較低，需要有專門的流媒體服務器，開銷大，使用非公共端口，可能會被防火墻攔截，且隨著flash不再維護，被各大瀏覽器棄用，在網頁端的應用大大減少；RTP/RTCP協議傳輸延遲低，支持的音視頻格式多，但需要有專門的流媒體服務器，開銷大，且使用非公共端口，可能會被防火墻攔截。表1具體分析了這幾種音視頻傳輸方式各自的優(yōu)點、缺點和應用場景。具體應用時，相關從業(yè)人員應結合實際情況來選擇合適的傳輸方式。

表1 音視頻傳輸方式的優(yōu)缺點和應用場景

4 音視頻技術面臨的問題

隨著信息技術的發(fā)展，音視頻業(yè)務類型越來越多，包括現在的點播、直播、即時通信，正在發(fā)展的VR、AR、遠程醫(yī)療、云游戲、元宇宙等等，對音視頻技術的要求越來越高。當前，音視頻技術面臨的主要問題如下。

（1）對音視頻質量的要求越來越高。當前，用戶對視聽體驗的要求越來越高，朝著超高清、低時延、流暢、互動方向發(fā)展。這對系統(tǒng)的帶寬、存儲能力要求越來越高，導致成本越來越高。VR、AR、遠程醫(yī)療、云游戲等新興技術對低時延、互動性、沉浸感的要求也越來越高。

（2）飛速增長的音視頻數據量對系統(tǒng)的算力要求越來越高。傳統(tǒng)的單機算法無法滿足大規(guī)模數據處理要求。

（3）訪問量大。音視頻服務器負載較大，且影響訪問的因素較多，訪問量存在不確定性。對此，需要保障業(yè)務高峰時的服務質量和穩(wěn)定運行，避免業(yè)務訪問量較小時的資源浪費，實現最優(yōu)配置。

（4）要適應不同終端。未來，音視頻在各行各業(yè)中的應用會越來越多，應用場景也會越來越多，意味著會有各種各樣類型的終端需要適應。

針對這些問題，本文提出以下幾點建議：

（1）可以通過優(yōu)化音視頻編碼算法，來降低存儲、帶寬成本，減少算力消耗；

（2）可以通過優(yōu)化應用程序、文件系統(tǒng)、緩存、磁盤等來提升系統(tǒng)輸入/輸出性能，提高數據的讀寫速度，從而實現低時延；

（3）通過分布式算法，將數據分散到多個節(jié)點上來處理，以提高數據處理效率，從而滿足音視頻傳輸對系統(tǒng)算力的要求；

（4）選擇合適的負載均衡方式、合理的調度策略來合理分配任務，充分發(fā)揮各服務器的性能，提高系統(tǒng)的可用性和穩(wěn)定性，從而解決系統(tǒng)高并發(fā)訪問量問題；

（5）選擇能夠匹配海量終端的音視頻標準和傳輸協議，來適應不同終端。

5 結 語

本文探討了音視頻傳輸技術和各種傳輸方式的優(yōu)缺點、應用場景，分析了音視頻傳輸面臨的問題，并針對這些問題提出了一些建議。未來，音視頻將會有更多的應用場景，如云游戲、元宇宙等，業(yè)務類型會越來越多，要求也會越來越高，希望本文能給相關從業(yè)人員提供參考和借鑒。