面向未來(lái)的移動(dòng)寬帶音視頻傳輸協(xié)議現(xiàn)狀與挑戰(zhàn)白皮書(shū)

面向未來(lái)的移動(dòng)寬帶音視頻傳輸協(xié)議—現(xiàn)狀與挑戰(zhàn) 21.視頻制作域和傳輸域的場(chǎng)景、用例和關(guān)鍵指標(biāo) 4 4 5 5 9 11 13 13 14 15 17 18 19 19 20 21 22 23 24 25 26 29 29 36 36 38 41 41 42 44 46 46 47 48 50 53 552摘要:率，用戶平均體驗(yàn)速率也達(dá)到了百兆級(jí)別。.首先是被廣泛應(yīng)用在后4G時(shí)代的傳輸協(xié)議，例如視頻背包使用的RTP/R等低時(shí)延協(xié)議逐步成熟，也有可能成為背包傳輸?shù)闹?41.視頻制作域和傳輸域的場(chǎng)景、用例和關(guān)鍵指標(biāo)通常，視頻制作域可以分為電視級(jí)內(nèi)容生產(chǎn)、互聯(lián)51.2視頻制作域的數(shù)據(jù)傳輸絡(luò)聚合網(wǎng)絡(luò)，快速現(xiàn)場(chǎng)搭建高速、穩(wěn)定、低延時(shí)的制6），7的AV信號(hào)（視頻和音頻）轉(zhuǎn)換成IP，并同時(shí)89表2超高清（4K）信號(hào)的示例性KPI通過(guò)名人主播、商鋪店家主播、職業(yè)主播等，匯集1.3移動(dòng)傳輸域的數(shù)據(jù)傳輸表34K、8K超高清視頻編碼、碼率需求2.視頻制作域傳輸協(xié)議2.1電視級(jí)制作使用的協(xié)議工作流中、在后期制作中、以及在向多頻道視頻節(jié)目分銷商動(dòng)通信系統(tǒng)提供帶寬的增加，通過(guò)移動(dòng)網(wǎng)絡(luò)ST2022-1一個(gè)流。而在大部分的應(yīng)用場(chǎng)景中，需要將三者彼此分開(kāi)(例如，將音頻和相關(guān)2015年，VSF的StudioVideooverIP（SVIP）活動(dòng)小組定義了技術(shù)建議TR-03，該建議將每種媒介作為單獨(dú)的流或源，使用RTP作為基礎(chǔ)傳輸協(xié)議ST2022之間的關(guān)鍵區(qū)別是物理連接，而ST2022和2110之間的區(qū)別是后者的），這里提到的控制和管理是由網(wǎng)絡(luò)媒體開(kāi)放規(guī)范（NMOS）定義的。NMOS允許設(shè)備協(xié)議技術(shù)是美國(guó)NewTek基于局域網(wǎng)研發(fā)的視頻編碼傳輸協(xié)議，NDI是一種網(wǎng)絡(luò)輸和接收，同時(shí)具有低延遲、精確幀視頻、數(shù)據(jù)流相則受本地網(wǎng)絡(luò)帶寬的限制，如千兆以太網(wǎng)僅能同時(shí)傳輸數(shù)個(gè)NDI源。FULLNDI個(gè)1080p60的NDI流僅需10Mbps左右。低帶寬的優(yōu)勢(shì)允許NDI|HX采用WiFi無(wú)線連接，或速度低于千兆位的網(wǎng)絡(luò)鏈路，部署十分方便。需要注意的是，與另外，NDI系列標(biāo)準(zhǔn)還推出了NDI|HX2[10]。作為下一代高效的NDI協(xié)議，NDI4發(fā)現(xiàn)服務(wù)器）和對(duì)低級(jí)網(wǎng)絡(luò)傳輸?shù)?.1.4無(wú)壓縮與淺壓縮的視頻編碼技術(shù)的簡(jiǎn)介的需求。下面表4總結(jié)了上述提及的各種常見(jiàn)的無(wú)壓縮或淺壓縮技術(shù)的統(tǒng)計(jì)表格供大家參考，用戶可以根據(jù)自己的應(yīng)用場(chǎng)表4無(wú)壓縮、淺壓縮算法比較UncompressedTICO/JPEG-XSH.264/AVC(AI)H.265/HEVC(AI)H.266/VVC(AI)2.2移動(dòng)鏈路回傳協(xié)議視頻工作流。根據(jù)Haivision的調(diào)研報(bào)體視頻傳輸逐漸成為新的選擇，近年來(lái)SRT的安全可靠傳輸、WebRTC的實(shí)時(shí)互RTMP（RealTimeMessagingProtMacromedia為通過(guò)互聯(lián)網(wǎng)在Flash播放器與一個(gè)服務(wù)器之間傳輸流媒體音頻、因此從2005年開(kāi)始，人們開(kāi)始逆向此協(xié)議并發(fā)布了若干開(kāi)源版本。最終AdobeRTMP協(xié)議至今仍然被廣泛應(yīng)用，但是近年來(lái)在應(yīng)用中觀察到如下問(wèn)題急需1.協(xié)議比較古老，最后更新日期是2012年，最高只支持到H.264,對(duì)除此之外，其本身又存在c0/s0到c2/s2的三次握手，再加上Connection、4.不能實(shí)現(xiàn)自適應(yīng)帶寬編碼，依賴于TCP協(xié)議無(wú)法提供實(shí)時(shí)帶寬數(shù)）；●豐富的擁塞控制統(tǒng)計(jì)信息，RTT，Lostrate，inflight，Sendbitrate，利用這些信息做擁塞控制，或），），（單播而不是組播）。SRT的亮點(diǎn)在于能夠克服有損網(wǎng)絡(luò)中的抖動(dòng)和丟包。SRT頁(yè)瀏覽器內(nèi)部進(jìn)行實(shí)時(shí)視頻和音頻通話的技術(shù)，于2011年6月由谷歌開(kāi)源。WebRTC允許開(kāi)發(fā)人員使用HTML和JavaScriptAPI來(lái)創(chuàng)建實(shí)時(shí)應(yīng)用，而無(wú)需下作為典型的瀏覽器之間的協(xié)議，WebRTC最大的特點(diǎn)是低延時(shí)和無(wú)卡頓。WebRTC可以提供點(diǎn)對(duì)多點(diǎn)的安全連接，使得多個(gè)音頻合視頻流可以在其連接上流動(dòng)。WebRTC提供了視頻會(huì)議的核心技術(shù)，包括音視頻的采集、編解碼、網(wǎng)絡(luò)傳輸、顯示等功能，并支持跨平臺(tái)（Windows，Linux，Mac，Android）。2020年的疫情驅(qū)使視頻通信需求劇增，也驅(qū)動(dòng)WebRTC面向更大規(guī)模的在線并發(fā)會(huì)議WebRTC因傳輸速度快、延遲低，適合應(yīng)用于對(duì)實(shí)時(shí)性、互動(dòng)性要求高，但ZIXI的傳輸流協(xié)議是一種內(nèi)容和網(wǎng)絡(luò)感知協(xié)議，可動(dòng)態(tài)調(diào)整以適應(yīng)不斷變恢復(fù)和數(shù)據(jù)包重新排序，平滑視頻傳輸，并將ZIXI提供可預(yù)測(cè)的低延遲、無(wú)數(shù)據(jù)包丟失的卓越可靠性和廣播級(jí)視頻質(zhì)量(標(biāo)清、高清和UHD)，沒(méi)有延遲、分辨率或斷斷續(xù)續(xù)的折中。從一個(gè)支持ZIXIZIXI的傳輸流技術(shù)通過(guò)網(wǎng)絡(luò)感知、動(dòng)態(tài)去抖動(dòng)、MPEG特定的優(yōu)化、Z-ARQ應(yīng)比特率控制以實(shí)現(xiàn)最高質(zhì)量和可靠性。并通過(guò)基于DTLS標(biāo)準(zhǔn)的保護(hù)提供點(diǎn)對(duì)點(diǎn)或多點(diǎn)傳輸。ZIXI可以部署在本地或云中，能夠監(jiān)控路徑上任何地方的流。對(duì)于管理、處理和更大規(guī)模的分發(fā)功能，ZIXI可以支持復(fù)雜的實(shí)時(shí)內(nèi)容生產(chǎn)制作，并能夠支持可靠的和可擴(kuò)展的集群壓縮技術(shù)等保持更新?lián)Q代，更加貼合時(shí)代的需求?，F(xiàn)在RIST有兩種配置）；主要配置文件mainprofile在傳輸時(shí)可以件還提供可調(diào)試的AES加密。這些之外，RIST還有著一些其他特性：通過(guò)刪除目前正在開(kāi)發(fā)的高級(jí)配置文件Advancedprofile，它可以自動(dòng)調(diào)試網(wǎng)絡(luò)參開(kāi)源的RIST接口在Upipe,libRIST,FFMPEG中都有支持。以僅實(shí)時(shí)傳輸協(xié)議模式運(yùn)行與非RIST接收器的互操作性，有效地使其與GB/T-28181協(xié)議[11]是在國(guó)際上通用的SIP協(xié)議進(jìn)行私有化定制，流媒體服務(wù)端與客戶端的數(shù)據(jù)交互采用SOAP協(xié)議。ONVIF規(guī)范的目標(biāo)是實(shí)現(xiàn)一個(gè)網(wǎng)絡(luò)議，RTMP兼容性極佳，對(duì)用戶來(lái)說(shuō)，在現(xiàn)有單向直播架構(gòu)上，接入成本較低。固定的情況下，當(dāng)RTMP客戶端播放端距離服務(wù)器越遠(yuǎn)（RTT越大），它從服務(wù)培訓(xùn)、會(huì)議等場(chǎng)景。許多實(shí)時(shí)音視頻服務(wù)專業(yè)廠商通過(guò)采用WebRTC技術(shù)，可實(shí)并通過(guò)RTCP（實(shí)時(shí)傳輸控制協(xié)議）進(jìn)行數(shù)據(jù)傳輸質(zhì)量控制。在網(wǎng)絡(luò)傳輸層，其表5ZIXI,SRT和RIST協(xié)議的對(duì)比越ARQ發(fā)送劃兩2022-1ZIXI,RIST和SRT均基于UDP協(xié)議，支持高碼率的分發(fā)能力，具備FEC前轉(zhuǎn)播、新聞報(bào)道和云轉(zhuǎn)播等等。后期我們將會(huì)進(jìn)行基于5G網(wǎng)絡(luò)的SRT和RIST3.移動(dòng)傳輸域傳協(xié)議3.1自適應(yīng)碼率傳輸進(jìn)，但仍有兩個(gè)頭疼的問(wèn)題:），2.它假定帶寬在整個(gè)流的持續(xù)時(shí)間內(nèi)保持固定--鑒于互聯(lián)網(wǎng)的公共性質(zhì)和段（使用HTTPGET請(qǐng)求）。當(dāng)片段被下載時(shí)，播放器將不斷估計(jì)自己和服務(wù)器HTTP是無(wú)會(huì)話的，并且不包括RTCP消息的交換(盡管底層TCP協(xié)議確實(shí)要求服MoveNetworks的想法很快被當(dāng)時(shí)的主要流媒體技術(shù)提供商采用。微軟在不同的文件格式來(lái)封裝音頻/視頻內(nèi)容（SmoothStreaming使用MP4，HLS使用），容器格式和標(biāo)準(zhǔn)化的清單文件語(yǔ)法，可以實(shí)現(xiàn)動(dòng)態(tài)廣告插入（DAI）、3D視頻、然被蘋(píng)果設(shè)備廣泛使用，這些設(shè)備構(gòu)成了相當(dāng)大的市場(chǎng)份額。因此MPEG推出了多個(gè)方案和規(guī)范來(lái)更好的解決這個(gè)問(wèn)題，其中最成功的就是CMAF，全稱Common），通用媒體應(yīng)用格式(CMAF)的規(guī)范旨在與傳統(tǒng)的RTP相比，DASH和HLS（或CMAF）協(xié)議更適合互聯(lián)網(wǎng)或不可靠網(wǎng)望將端到端的延遲減少到幾秒。其基本思想是編2到4秒)劃分為小至500毫秒的較小段。然后，每個(gè)塊都可以單獨(dú)轉(zhuǎn)發(fā)到打包發(fā)生在數(shù)據(jù)段邊界上，但通過(guò)這個(gè)技術(shù)，端到其中，具有代表性的標(biāo)準(zhǔn)是LL-HLS（Low-LatencyHLS）和LL-DASH標(biāo)準(zhǔn)規(guī)范。該擴(kuò)展與常規(guī)HLS向后兼容，同時(shí)提供了Apple認(rèn)可的方法來(lái)降低HLS的延遲，主要手段包括：1)采用HLSPartialSegments機(jī)制，允許片段立生成、打包和發(fā)送，且每個(gè)PartialSegment可以很短，不必像Segment一樣必須是IDR幀開(kāi)頭，從而達(dá)到降低延時(shí)的目的。對(duì)于第二個(gè)特性，此次更新刪除了HTTP/2的要求，而是引入了一個(gè)新標(biāo)簽2017年4月，LL-DASH首次被提出，2020年3月，MPEG發(fā)布LL-DASHEncoding)機(jī)制，通過(guò)使用HTTP/1.1Chun了準(zhǔn)備一個(gè)完整媒體片段的耗時(shí)。在兼容性方面，除了使用HTTP/1.1Chunked件（MPD），并請(qǐng)求相應(yīng)的片段進(jìn)行下載和播放，僅僅是不再具有低延遲特?fù)?jù)實(shí)時(shí)網(wǎng)絡(luò)狀態(tài)動(dòng)態(tài)在多檔之間實(shí)現(xiàn)無(wú)縫切換，平衡清晰度和流暢度；2)生態(tài)行業(yè)內(nèi)頭部APP企業(yè)近兩年，服務(wù)穩(wěn)定，部署簡(jiǎn)單；3）易擴(kuò)展：在底層，LAS支持HTTP、QUIC等多種協(xié)議，未來(lái)將支持WebRTC，進(jìn)一步降低延遲，在上層，LAS1.0版本基于HTTP-FLV實(shí)現(xiàn)直播拉流，與目前國(guó)內(nèi)使用最廣泛的基于3.2面向廣播組播分發(fā)FLUTE協(xié)議的主體部分是ALC[15]協(xié)信協(xié)議的主體部分，負(fù)責(zé)提供前述的進(jìn)程管理的功能。選的組成組件，負(fù)責(zé)ALC在Internet上的擁塞控制。自接收端的回饋信息，通過(guò)預(yù)先提供冗余信息來(lái)彌補(bǔ)ALC時(shí)媒體或者非實(shí)時(shí)文件）的時(shí)延特性優(yōu)化傳輸BIER在組播首節(jié)點(diǎn)（BIERIngress）確定組播的接收者（BIEREgre到任何組播流，也無(wú)需保存任何組播流相關(guān)信息，與用戶及業(yè)務(wù)量的增減無(wú)關(guān)，對(duì)于組播成員的加入、退出都需要進(jìn)行管理，需要表5Bier與傳統(tǒng)PIM組播的比對(duì)斂收斂過(guò)程，單播路由收斂完成，性性控3.3單點(diǎn)分發(fā)HTTP1/HTTP2/HTTP3歷史上第一個(gè)有記載的HTTP版本是0.9（TheHT），設(shè)計(jì)用于從服務(wù)器獲取HTML（HyperTextMark于HTTP/1.0，HTTP/1.1），可以傳送多個(gè)HTTP請(qǐng)求和響應(yīng)，減少了每次建立和關(guān)閉連接的消耗和延遲。更多的請(qǐng)求頭和響應(yīng)頭來(lái)改進(jìn)和擴(kuò)充HTTP/1.0））），），個(gè)HTTPResponse，不同的HTTPResponse對(duì)應(yīng)于不同的HT3.頭部壓縮（HeaderCompression在介紹HTTP/1.x時(shí)，我們知道在Push功能。所謂ServerPush指的是HTTP/2.0服務(wù)器在此外，Nginx與Apache也已經(jīng)支持HTTP請(qǐng)求文件的示意圖，在HTTP/1.x中，客戶端需要請(qǐng)求網(wǎng)站首頁(yè)達(dá)客戶端之后，才能繼續(xù)發(fā)送下一個(gè)HTTPRequest。HTTP/1.1Request與多個(gè)HTTPResponse在同一個(gè)TCP連接上存高了鏈路帶寬的利用率。但是即使如此，客戶端與服務(wù)端由于可以看出基于HTTP/2ServerPush來(lái)請(qǐng)求網(wǎng)站首頁(yè)instyle.css與圖片home.jpg三圖15HTTP/1.x,HTTP/2.0無(wú)ServerPush和HTTP/2.0結(jié)合ServerPush流程比較QUIC雖然基于UDP，但是在原本的基礎(chǔ)中，這兩類終端被統(tǒng)稱為XR（eXtendedReal視角，終端能夠根據(jù)用戶的觀看視角動(dòng)態(tài)渲染圖像、視表6VR視頻基本配置規(guī)范式式表7VR音頻基本配置規(guī)范式y(tǒng)3含4VR媒體傳輸協(xié)議要求和智能手機(jī)類似，也是以DASH和H4.小結(jié)和音視頻傳輸趨勢(shì)預(yù)測(cè)景景放例發(fā)控3GPPeMBMS、DVB等移動(dòng)廣播系統(tǒng)參考文獻(xiàn)[2]中央廣播電視總臺(tái)，《4K超高清電視技術(shù)應(yīng)用實(shí)施指南（2018版）》，[5]Haivision,“BROADCIPandCloudAdoptionintheBroadcastImultipleInternetEngin/2021/01/pressre/pro/attributes/SEG/manual/BR-800_User_Guide_V19.pdf[10]RickAckermans，RIS[11]GB/T28181-2016公共安全視頻監(jiān)控聯(lián)網(wǎng)系統(tǒng)信息傳輸、交換、控制技術(shù)要[13]IETF,RFC3926-Fil[14]3GPP,TS26.346,Multimedia