基于5G網絡的視頻低延遲視頻關鍵技術及應用場景

本次分享將分為三個部分：第一部分介紹低延遲視頻所涉及到的關鍵技術，包括低延遲視頻編解碼、視頻傳輸、視頻處理低延時框架、視頻采集和顯示；第二部分重點介紹5G環境下低延遲視頻對抗弱網提出的要求，包括：弱網狀態的探測、擁塞控制等；最后一部分會結合實際測試結果，介紹在港口遠控、遠程駕駛等場景下的應用范例。

網絡技術發展帶來了延時低這一問題的討論。以前網絡的延遲比較高，芯片的處理都需要時間，所以延時一直都做得不夠完美。隨著技術的發展，芯片的處理能力提高和網絡的發展，低延遲視頻開始能夠運用在一些比較特殊的場景，所以今天我想講的主要內容包括：首先把“低延時”這一問題拋出來，然后介紹一下如何解決這些問題和相關技術，最后介紹低延遲視頻的應用場景。

-01-

低延遲視頻面對的問題

延時是做視頻都會遇到的一個關鍵技術指標。平時面對面實時交流，一般200ms的延時就能達到滿意的狀態，因為人與人之間交流的反應速度沒有這么快。但是人和機器交流或機器和機器間對接，對延遲的要求就會比較高，因為機器的反應速度遠快于人。例如受操控的中等速度的工程車，通常100ms的延遲速度能夠滿足控制要求，較典型的例子是遠程控制車上的機械臂。另外，游戲也有比較高的延遲需求，最好是在100ms以下，最好能夠做到50ms、60ms左右。因為游戲雖然是人在操控，但控制的是較為激烈的游戲場景，例如開車、開槍，可能延遲差一點點游戲就輸了，因此延遲對于用戶體驗而言是很關鍵的。遠程開車速度通常有60公里/小時，延遲如果在60ms左右，控制時就會有1米左右的誤差。再如在高速公路上操控無人機，“智慧道路”要求在控制的同時告知操控人前方是否有事故或障礙物，因此延遲需要達到30ms左右才能滿足用戶的要求。

那么如何定義延遲呢？ 從視頻的產生、采集到顯示（在云游戲場景下，即從視頻產生的時候算起）產生的延時，即視頻經過發送、網絡傳輸、接收，一直到顯示器，這整個環節就屬于端到端的延時。中間段的延時也可以單獨計算，例如從發送端到接收端，不計算頭和尾的延時。這中間的很多環節都會產生延時，所以每個環節的延時都需要計算、都需要考慮指標能做到多少，這樣才能把完整的延時定義出來。同時，還需要考慮內容的產生來源，例如內容是從某個云端產生，這其中的延時也需要計算。因此，技術指標是需要考慮到各個方面的。以上就是它的定義。

? 可以通過列表來估算每個環節會產生多大的延遲，哪些環節是容易產生延遲的。第一個環節是采樣，如果是30幀/秒，其中會有33ms左右的間隔。這個（過程）本身也是有延遲的，因為采集有固定間隔，其固定間隔就是采樣的延時。接下來是媒體的前處理，主要是ISP芯片帶來的延遲，例如降噪、畸變校正等，其中的運算、數據傳輸都會產生延時，這部分就和它的處理能力有關，我們也可以對其進行估算。

然后是發送緩沖、網絡傳輸、接收緩沖，這些也都需要時間，因為網絡的帶寬是有限的，如果帶寬非常寬，則傳輸時間可以忽略不計。后面會詳細介紹這其中會帶來什么問題。這部分是延時產生的主要來源。

再之后是后處理，后處理和前處理相同，都屬于媒體的處理，這部分的延遲比較固定，其數值不會波動太大。而中間的網絡部分（的延遲）波動是比較大的，是隨著網絡條件、環境變化而變化的，也和丟不丟包有關。最終的顯示，解碼之后進入顯示緩存和顯示器，顯示也是存在等待延遲的。綜合上面的計算，根據目前系統的能力來看，如果不計算采樣延時，（延時）大概在20到幾百之間。

? 下面再逐個分析延時產生的原因到底是什么。一個是計算的開銷，比如說在處理的時候計算很復雜，涉及到一些數值計算，比如做白平衡、降噪、去掉噪聲、編碼、解碼，這些都是大計算量的，都需要時間，時間大概在幾毫秒到幾十毫秒不等。這部分屬于計算的開銷。

第二個（延遲產生的）來源是傳輸延遲。網絡本身是有延遲的，不管是什么網絡，光的傳輸都是需要時間的，路由器處理也需要時間，不管用什么方式（傳輸）都是需要時間的。視頻的數據量比較大，大的視頻幀有幾百kbps到幾M不等。傳輸是在有限的帶寬上進行，假設是50M、100M左右的網絡，傳一個2M的視頻，這是需要幾毫秒時間的。通過后面的視頻傳輸數據的波形圖，可以看出視頻的碼流是不穩定的，即每幀的大小差異比較大，每幀在傳輸中需要的時間是不確定的，每幀到達目的地的時間不同，是不是固定的，這樣不可預計到達時間。壓縮前的視頻數據達到1G左右的級別，即數據在編碼前和解碼后都有這么大的數據量，這在終端設備上顯示和處理都是需要時間的。所以傳輸的延遲算是需要考慮的一個方面。還有就是抗丟包。當網絡質量比較差的時候，要應對網絡抖動或網絡丟包，就要用一個“代價”。通常情況下，要保證用戶體驗，要用的“代價”就是用延時來換。所以要增加延遲來抵抗（丟包），比如重傳。這部分的延遲是可變動的，隨著網絡狀態的變化而不斷變化。再有就是任務調度之間的延遲。要把以上的步驟串起來，不同的模塊之間、不同的任務之間需要安排好，像流水線一樣。如果流水安排得不好，就會出現“等待”：數據還沒來，我無法處理，需要等數據過來才能開始。這其中就有等待延遲。

? 再看到延遲、帶寬和算力之間的關系。它們之間是三角形的、互相矛盾關系。如果要限制算力、節省算力，延遲可能就會上升。算力如果給得多，延遲或帶寬就會占得比較少，它們之間是互相矛盾的關系。假如帶寬給得非常高，給得十分充足，延遲肯定就會下降，因為花在傳輸路上的時間少了，而且如果帶寬給得高，抗丟包也好做，需要的抗弱網的延遲比較少。所以它們之間是三角形的關系。延遲最終可以表達為與帶寬、算力、視頻質量相關的函數，視頻質量高，要求的延遲、算力的消耗都會更多，會影響視頻質量。算力高意味著成本高，帶寬占得高也意味著成本高，所以需要尋找平衡。在什么樣的質量下、在什么樣的延遲要求下，用多少成本約束是合理的。也不是一定要選擇最好的芯片，處理能力、配置強一些、帶寬配置高一些，就一定是好的，它是一個均衡的關系，相互之間要達到平衡和優化。當然，視頻質量和延遲也是互為矛盾的關系，如果視頻質量要求高，碼率就會高。

? 再看下視頻碼流的圖。不同的線表示不同的條件，有的是游戲，有的是演講、聊天。在不同的條件下的曲線是變化的，碼流是不太有規則的，雖然長時間看，有一根平均線，但短時間看是忽上忽下的，這是因為視頻的復雜度不一樣，內容的復雜度和碼流是有關系的。內容越復雜，或者攝像頭劇烈晃動、距離變動，碼流自然就會沖高，因為帶寬（例如4M的帶寬）是壓不住的，是會上升的。因為編碼要保證質量在一定范圍內、保證它不太差，那么（碼流）必然會沖高，因為信息量非常大。如果把碼率壓低，編碼器最終輸出的質量會很差，就會看到很多不清楚的、模糊的畫面。內容的復雜度還包括幀內的內容。如果幀內的內容非常豐富，也會影響碼流的輸出。所以視頻的碼流波動是比較劇烈的。

還有一個影響碼率的因素是視頻的I幀、P幀的問題。關鍵幀的大小一般是P幀的5倍、10倍都有可能，這取決于內容的復雜度、幀內的復雜度。如果幀內復雜度很高，100k、200k都是很正常的，而P幀可能只有它的十分之一。因為它的波動比較劇烈，所以每幀在路上傳輸消耗的時間是不一樣的，即使是網絡很好的時候，到達、接收的時間也是不一樣的，到達延遲是變化的。有的幀可能特別大，要把它拆成幾百個報文，要等所有的報文都收到才算傳輸完畢，這路上花費的時間變化就會比較大。同時，碼流變化會對網絡產生一定的沖擊，假設幾個攝像頭在同一個信道里傳輸，幾個波峰都在一起，相互之間會擠，等待時間就會大幅度增加，就會出現更多不可預料的延時。這些問題都是需要考慮的。

? 顯示也是有延遲的。視頻解碼后，到GPU渲染，再到操作系統顯示。如圖，是安卓上的顯示過程，在其他系統上也是一樣的，有顯示服務，服務每隔一段時間會刷新一次的，如果要求數據”1”低延遲顯示，就要在第一個間隔點前把它處理、渲染好，比如你需要疊加一個文字，就需要在這之前處理好，再到下一個時間段會把它刷新。除了圖中的延遲外，還有顯示器刷新的時間，顯示器刷新的時間比較短，有的顯示器僅有1毫秒。操作系統是軟件控制的，這里的延遲和刷新率有關，例如刷新頻率是100赫茲，就會有10毫秒的間隔。這是一個固定的延遲，它是操作系統和刷新間隔造成的。再看圖中的“3”的圖像，“3”跨越兩個時間段，它的顯示就會等待更長時間，它不會在前面還沒有處理完就刷新顯示器。所以顯示的環節也是延遲比較大。

以上就是低延遲視頻的問題，下面再看下如何解決這些問題。

? 我把它歸納為傳輸和信源（兩部分）。傳輸主要是指低延遲傳輸，即如何實現（傳輸的）快速、穩定，能抵抗丟包。信源層包括攝像頭前面的處理部分，到最終的顯示，如果把這一系列問題都能解決好，解決延遲問題的目標就達成了。

? 并行視頻的處理和編碼。視頻本身是采樣過來的，是可以劃分成條塊的，前面這個示意圖可以橫過來劃分，也可以四分劃分。發送條塊可以通過并行來計算，圖像的并行化是解決延遲的主要手段。當然，并行化也會帶來一些問題，并行是通過劃分（進行的），計算的時候就可以把每塊分別計算，進行處理，包括后面的編碼也可以用同樣的方法，這樣就可以通過并行化把延遲降到原來的幾分之一。當然，（為了實現并行化），每幀都單獨處理而不做關聯會造成一些問題，比如白平衡，有的處理算法要整幀先計算，或者后面做補償計算。因為每幀的內部及每幀之間是有關聯度的，包括編碼，在計算時一旦分割進行全屏處理，從而實現并行化。

并行化有什么問題呢？一個是做了分塊之后，Slice的壓縮比也是受影響的，不僅有幀頭開銷，Slice之間的相互參考也會減少，就會帶來壓縮率的下降。還有就是視頻解碼時，要跨越條塊邊界就需要做濾波，所以解碼的并行化不如編碼的并行化好。所以一般是編碼時做并行化，解碼的并行化比較弱。然后是做圖像處理時，不同條塊之間有一致性的問題，比如光照強度，有區域的較暗，需要做統一的計算，才能知道別的塊要怎么處理。

因此，如果把并行化做好，編碼的時間、前處理的時間都可以減少很多。充分發揮計算的能力，通過并行化的手段使延遲下降。

還有就是動態調整關鍵幀的間隔，來減少碼流波動。看上面這張圖，關鍵幀如果同時出現，這兩幀的延遲都受到影響。這時候瞬間出現一個比較大的波動，到達接收端時，就會出現這一幀在路上的時間特別長的情況，其他幀比較小。但是顯示時為了保證流暢性，減少快慢播問題，就必須緩沖和等待。為了能夠平滑地顯示播放，不至于不斷出現快放、慢放的情況，就會導致所有的幀都帶來額外的延遲，慢慢才能通過動態緩沖把它補償回來。這種情況是需避免的，以避免關鍵幀同時出現。

在延遲要求比較敏感的地方，關鍵幀盡量越少越好。因為關鍵幀越少，碼流的平滑度越容易做，每幀在路上的時間不容易出現波動。當然，有的場景會要求固定間隔，比如幾秒就要有一個關鍵幀。假如沒有終端臨時加入觀看，是可以讓間隔長一些的，這是有收益的，而且壓縮比也更高。但是如果有的場景間隔要求短，就盡量避免它們同時出現。在同一個信道中間傳輸多路視頻的時候，盡量把關鍵幀交錯開，避免關鍵幀同時出現，減少I幀的碰撞。

在傳輸過程中間，已經編碼完的數據立刻進行傳輸，盡量減少等待。有多少數據立刻傳輸，不用等這一幀全部編完，因為按照并行化編碼，數據是可以先后出來的，這樣就可以減少等待。這是傳輸的問題。

有的場景延遲是固定為主的，有的則是變化的，因為是和網絡有關的，網絡路上很多是不確定的，哪兒堵車了、哪兒出問題了，會帶來很大的不確定性。一般抗丟包用的都是前向糾錯或者重傳，或者兩者互相結合。如果是延遲很敏感的場景，可以先用FEC使丟包率下降，但它不能把丟包率完全消除，這取決于你的丟包模型。如果模型是很均勻的，用FEC是可以把它消除到幾乎沒有的；但通常前向糾錯本身是無法把它完全消除的，但它能夠使得你的丟包率下降，下降之后發生重傳的概率就會相對低一些。重傳的次數越多，在路上RTT的時間就會更長，就會出現卡頓，就會影響后面視頻的接收和顯示，緩沖區就會有很多數據在等。

而且前向糾錯本身冗余率是非常高的，它會帶來額外的帶寬的浪費和消耗。但它是一種平衡，假如你舍得用帶寬，延遲是可以下降的；如果你覺得帶寬很值錢，不希望消耗太多，延遲可能就會增加一些，前向糾錯可能就加得少或者不加，因為有時不一定會有收益。在丟包比較多、或丟包模型不符合一定條件時，不用FEC會劃算，這是一種平衡。如果能夠通過網絡狀態探測到，并且能夠根據當前的丟包率、RTT的時間，能夠動態調整，達到一個平衡就能知道什么場景下用什么方式是最劃算的。

通訊引擎本身是能夠滿足各種條件的。例如延遲敏感條件，或者帶寬和延遲要求平衡的條件，告訴引擎有這些偏好要求，就可以通過做一些策略調整來達到最終延遲和帶寬消耗的平衡。

還有就是智能調速技術。接收方把每個報文的接收時間反饋回去，發送端就可以根據接收的時間和發送時間的差來估算網絡狀態，最終可以獲得網絡帶寬、當前的丟包率、延遲等信息。網絡如果感知到這些信息，碼率就可以做動態調整。在移動網絡中，碼率和帶寬是波動的，當被干擾、被遮擋或有天氣變化等情況時，它的無線信號在一段時間內也會出現比較大比例的丟包或帶寬的下降。無線信號的噪聲上升了，整個網絡的帶寬就會下降，丟包率上升等情況都會出現。這時就需要對它進行動態監測，要估算網絡現在到底怎么樣、處于什么狀態，要獲得丟包率等參數，同時感知視頻內容。

所謂的內容，是指內容的復雜度，復雜度可以表征為時間復雜度和空間復雜度。時間復雜度就是每幀之間的變化，比如運動是否劇烈。空間復雜度是幀內的畫面復雜度。根據這些來動態估計碼率的決策，可以使得碼率更加合理，達到最優值，減少卡頓和延遲。

智能調速能夠根據各種條件實時動態調整碼率。調整碼率不能太頻繁，不能一秒鐘內立刻就變了，那也是有問題的，它也得有一定的調整時間的限制。這個圖可以看出，如果調整的時間合理，隨著網絡帶寬的恢復，碼率也能恢復。當然恢復是慢速恢復，下降則是快速下降。為了盡量消除卡頓，帶寬必須快速下降，而上升則是慢慢上升。

還有一個問題是最短傳輸路徑。如果端到端，在兩個端上解決這個問題，其實還不是徹底地解決，因為在路上傳輸所消耗的時間和網絡節點是從哪兒走有關。如果網絡節點之間，能夠把路況都探測到、獲取到不同路徑的延遲和帶寬情況，就可以尋找到最小延遲路徑來解決延遲這個問題，使得網絡傳輸之間自主選路。再加上上面端到端之間的媒體抗弱網，在端到端之間、2個媒體節點之間做抗丟包，綜合起來之后可以達到完整的方案。每個節點都做了優化，就可以解決好這個問題。 ?

-03-

低延遲視頻應用案例

最后說一下應用場景。

? 5G應用給產業帶來了一些變革。之前許多控制都是靠有線的，例如網線、光纖。但是有了移動網絡之后，一些需要運動的、不太容易布線的（東西、場景），移動網絡就可以適用于這些新的應用場景，例如生產線、工業應用、自動駕駛、遠程操控，或是一些較為危險的場景，例如地下礦車等。工業園區、港口、煤礦、醫院、智慧社區這些都是未來潛在的應用可能。這也是移動網絡帶來的一個好處，即通信設備可以通過移動網絡來解決問題。

這是我們中興做的一個網關，上面帶5G天線，里面可以接幾個攝像頭，也可以接工業、車載控制的口，接口豐富。可以接SDI的攝像頭，這種攝像頭延遲是比較低的。還有就是接入IP攝像頭，它已經把視頻編碼和打包好了。最后工業設備的控制，通過遠程控制臺可以控制前面的設備。IP攝像頭的延遲取決于攝像頭編碼和采集的延遲。因為上面有5G天線，所以可以實現遠程控制。

還有一種是可以有一個網關，前面攝像頭已采集的視頻經過它做一次轉碼，轉碼之后再通過天線從基站過來，再把視頻進行回傳。這是我們的另外一個設備，它可以進行網關的轉碼或合成，畫面也可以在里面合成，合成網關設備可以和前面的設備形成互補。

案例1是煤礦。左邊是煤礦的機械，在井道里面，如果將網關放在車上，可以在機械上放幾個攝像頭，遠程控制中心可以看到礦井內視頻，就不用人在下面開車了，可以在地面的集控中心控制它。因為這個機械的延遲要求估計在100毫秒就夠，它運動速度不快，就可以解決井下工人工作環境危險的問題。這是通過遠程控制減少人工成本的比較有價值的應用。

無人集卡。這和前面的車差不多，但它可以帶幾個SDI或IP攝像頭，然后通過車載完成控制。中間要建5G的基站，及核心網設備。里面有2個5G模組實現備份，提供抗弱網體驗，支持onvif攝像頭，及支持IP攝像頭接入。到了本地之后它是可以走有線的。

這個場景是在港口上。港口上有龍門吊（之類的設備），每個吊車上可以放20、30個攝像頭，人都是在操控室里控制的。這種場景要求人可以切換攝像頭，傳過來之后還需要做一些放大，這樣才能使操作時司機控制得比較好。這種以前都是用有線來做的，用光纖或網線來做，因為環境比較惡劣，有一定的維護成本。如果換成無線的這種，相對而言維護成本會降低。可以提供50-80毫秒的延遲，無線網絡上的這一段大概在10毫秒，可以解決在岸橋這一場景的遠程控制。它的優勢在于司機控制龍門吊時可以自由切換攝像頭，智能化之后生產效率還是會有一定提高的。