本次分享將分為三個(gè)部分：第一部分介紹低延遲視頻所涉及到的關(guān)鍵技術(shù)，包括低延遲視頻編解碼、視頻傳輸、視頻處理低延時(shí)框架、視頻采集和顯示；第二部分重點(diǎn)介紹5G環(huán)境下低延遲視頻對(duì)抗弱網(wǎng)提出的要求，包括：弱網(wǎng)狀態(tài)的探測(cè)、擁塞控制等；最后一部分會(huì)結(jié)合實(shí)際測(cè)試結(jié)果，介紹在港口遠(yuǎn)控、遠(yuǎn)程駕駛等場(chǎng)景下的應(yīng)用范例。

文/沈燦

整理/LiveVideoStack

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

-01-

低延遲視頻面對(duì)的問題

延時(shí)是做視頻都會(huì)遇到的一個(gè)關(guān)鍵技術(shù)指標(biāo)。平時(shí)面對(duì)面實(shí)時(shí)交流，一般200ms的延時(shí)就能達(dá)到滿意的狀態(tài)，因?yàn)槿伺c人之間交流的反應(yīng)速度沒有這么快。但是人和機(jī)器交流或機(jī)器和機(jī)器間對(duì)接，對(duì)延遲的要求就會(huì)比較高，因?yàn)闄C(jī)器的反應(yīng)速度遠(yuǎn)快于人。例如受操控的中等速度的工程車，通常100ms的延遲速度能夠滿足控制要求，較典型的例子是遠(yuǎn)程控制車上的機(jī)械臂。

另外，游戲也有比較高的延遲需求，最好是在100ms以下，最好能夠做到50ms、60ms左右。因?yàn)橛螒螂m然是人在操控，但控制的是較為激烈的游戲場(chǎng)景，例如開車、開槍，可能延遲差一點(diǎn)點(diǎn)游戲就輸了，因此延遲對(duì)于用戶體驗(yàn)而言是很關(guān)鍵的。遠(yuǎn)程開車速度通常有60公里/小時(shí)，延遲如果在60ms左右，控制時(shí)就會(huì)有1米左右的誤差。再如在高速公路上操控?zé)o人機(jī)，“智慧道路”要求在控制的同時(shí)告知操控人前方是否有事故或障礙物，因此延遲需要達(dá)到30ms左右才能滿足用戶的要求。

那么如何定義延遲呢？

從視頻的產(chǎn)生、采集到顯示（在云游戲場(chǎng)景下，即從視頻產(chǎn)生的時(shí)候算起）產(chǎn)生的延時(shí)，即視頻經(jīng)過發(fā)送、網(wǎng)絡(luò)傳輸、接收，一直到顯示器，這整個(gè)環(huán)節(jié)就屬于端到端的延時(shí)。中間段的延時(shí)也可以單獨(dú)計(jì)算，例如從發(fā)送端到接收端，不計(jì)算頭和尾的延時(shí)。這中間的很多環(huán)節(jié)都會(huì)產(chǎn)生延時(shí)，所以每個(gè)環(huán)節(jié)的延時(shí)都需要計(jì)算、都需要考慮指標(biāo)能做到多少，這樣才能把完整的延時(shí)定義出來。同時(shí)，還需要考慮內(nèi)容的產(chǎn)生來源，例如內(nèi)容是從某個(gè)云端產(chǎn)生，這其中的延時(shí)也需要計(jì)算。因此，技術(shù)指標(biāo)是需要考慮到各個(gè)方面的。以上就是它的定義。

可以通過列表來估算每個(gè)環(huán)節(jié)會(huì)產(chǎn)生多大的延遲，哪些環(huán)節(jié)是容易產(chǎn)生延遲的。第一個(gè)環(huán)節(jié)是采樣，如果是30幀/秒，其中會(huì)有33ms左右的間隔。這個(gè)（過程）本身也是有延遲的，因?yàn)椴杉泄潭ㄩg隔，其固定間隔就是采樣的延時(shí)。接下來是媒體的前處理，主要是ISP芯片帶來的延遲，例如降噪、畸變校正等，其中的運(yùn)算、數(shù)據(jù)傳輸都會(huì)產(chǎn)生延時(shí)，這部分就和它的處理能力有關(guān)，我們也可以對(duì)其進(jìn)行估算。

然后是發(fā)送緩沖、網(wǎng)絡(luò)傳輸、接收緩沖，這些也都需要時(shí)間，因?yàn)榫W(wǎng)絡(luò)的帶寬是有限的，如果帶寬非常寬，則傳輸時(shí)間可以忽略不計(jì)。后面會(huì)詳細(xì)介紹這其中會(huì)帶來什么問題。這部分是延時(shí)產(chǎn)生的主要來源。

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

?

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

第二個(gè)（延遲產(chǎn)生的）來源是傳輸延遲。網(wǎng)絡(luò)本身是有延遲的，不管是什么網(wǎng)絡(luò)，光的傳輸都是需要時(shí)間的，路由器處理也需要時(shí)間，不管用什么方式（傳輸）都是需要時(shí)間的。視頻的數(shù)據(jù)量比較大，大的視頻幀有幾百kbps到幾M不等。傳輸是在有限的帶寬上進(jìn)行，假設(shè)是50M、100M左右的網(wǎng)絡(luò)，傳一個(gè)2M的視頻，這是需要幾毫秒時(shí)間的。通過后面的視頻傳輸數(shù)據(jù)的波形圖，可以看出視頻的碼流是不穩(wěn)定的，即每幀的大小差異比較大，每幀在傳輸中需要的時(shí)間是不確定的，每幀到達(dá)目的地的時(shí)間不同，是不是固定的，這樣不可預(yù)計(jì)到達(dá)時(shí)間。壓縮前的視頻數(shù)據(jù)達(dá)到1G左右的級(jí)別，即數(shù)據(jù)在編碼前和解碼后都有這么大的數(shù)據(jù)量，這在終端設(shè)備上顯示和處理都是需要時(shí)間的。所以傳輸?shù)难舆t算是需要考慮的一個(gè)方面。

還有就是抗丟包。當(dāng)網(wǎng)絡(luò)質(zhì)量比較差的時(shí)候，要應(yīng)對(duì)網(wǎng)絡(luò)抖動(dòng)或網(wǎng)絡(luò)丟包，就要用一個(gè)“代價(jià)”。通常情況下，要保證用戶體驗(yàn)，要用的“代價(jià)”就是用延時(shí)來換。所以要增加延遲來抵抗（丟包），比如重傳。這部分的延遲是可變動(dòng)的，隨著網(wǎng)絡(luò)狀態(tài)的變化而不斷變化。再有就是任務(wù)調(diào)度之間的延遲。要把以上的步驟串起來，不同的模塊之間、不同的任務(wù)之間需要安排好，像流水線一樣。如果流水安排得不好，就會(huì)出現(xiàn)“等待”：數(shù)據(jù)還沒來，我無法處理，需要等數(shù)據(jù)過來才能開始。這其中就有等待延遲。

再看到延遲、帶寬和算力之間的關(guān)系。它們之間是三角形的、互相矛盾關(guān)系。如果要限制算力、節(jié)省算力，延遲可能就會(huì)上升。算力如果給得多，延遲或帶寬就會(huì)占得比較少，它們之間是互相矛盾的關(guān)系。假如帶寬給得非常高，給得十分充足，延遲肯定就會(huì)下降，因?yàn)榛ㄔ趥鬏斅飞系臅r(shí)間少了，而且如果帶寬給得高，抗丟包也好做，需要的抗弱網(wǎng)的延遲比較少。所以它們之間是三角形的關(guān)系。延遲最終可以表達(dá)為與帶寬、算力、視頻質(zhì)量相關(guān)的函數(shù)，視頻質(zhì)量高，要求的延遲、算力的消耗都會(huì)更多，會(huì)影響視頻質(zhì)量。算力高意味著成本高，帶寬占得高也意味著成本高，所以需要尋找平衡。在什么樣的質(zhì)量下、在什么樣的延遲要求下，用多少成本約束是合理的。也不是一定要選擇最好的芯片，處理能力、配置強(qiáng)一些、帶寬配置高一些，就一定是好的，它是一個(gè)均衡的關(guān)系，相互之間要達(dá)到平衡和優(yōu)化。當(dāng)然，視頻質(zhì)量和延遲也是互為矛盾的關(guān)系，如果視頻質(zhì)量要求高，碼率就會(huì)高。

?

再看下視頻碼流的圖。不同的線表示不同的條件，有的是游戲，有的是演講、聊天。在不同的條件下的曲線是變化的，碼流是不太有規(guī)則的，雖然長(zhǎng)時(shí)間看，有一根平均線，但短時(shí)間看是忽上忽下的，這是因?yàn)橐曨l的復(fù)雜度不一樣，內(nèi)容的復(fù)雜度和碼流是有關(guān)系的。內(nèi)容越復(fù)雜，或者攝像頭劇烈晃動(dòng)、距離變動(dòng)，碼流自然就會(huì)沖高，因?yàn)閹挘ɡ?M的帶寬）是壓不住的，是會(huì)上升的。因?yàn)榫幋a要保證質(zhì)量在一定范圍內(nèi)、保證它不太差，那么（碼流）必然會(huì)沖高，因?yàn)樾畔⒘糠浅４蟆Ｈ绻汛a率壓低，編碼器最終輸出的質(zhì)量會(huì)很差，就會(huì)看到很多不清楚的、模糊的畫面。內(nèi)容的復(fù)雜度還包括幀內(nèi)的內(nèi)容。如果幀內(nèi)的內(nèi)容非常豐富，也會(huì)影響碼流的輸出。所以視頻的碼流波動(dòng)是比較劇烈的。

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

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

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

我把它歸納為傳輸和信源（兩部分）。傳輸主要是指低延遲傳輸，即如何實(shí)現(xiàn)（傳輸?shù)模┛焖佟⒎€(wěn)定，能抵抗丟包。信源層包括攝像頭前面的處理部分，到最終的顯示，如果把這一系列問題都能解決好，解決延遲問題的目標(biāo)就達(dá)成了。

?

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

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

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

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

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

?

在傳輸過程中間，已經(jīng)編碼完的數(shù)據(jù)立刻進(jìn)行傳輸，盡量減少等待。有多少數(shù)據(jù)立刻傳輸，不用等這一幀全部編完，因?yàn)榘凑詹⑿谢幋a，數(shù)據(jù)是可以先后出來的，這樣就可以減少等待。這是傳輸?shù)膯栴}。

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

而且前向糾錯(cuò)本身冗余率是非常高的，它會(huì)帶來額外的帶寬的浪費(fèi)和消耗。但它是一種平衡，假如你舍得用帶寬，延遲是可以下降的；如果你覺得帶寬很值錢，不希望消耗太多，延遲可能就會(huì)增加一些，前向糾錯(cuò)可能就加得少或者不加，因?yàn)橛袝r(shí)不一定會(huì)有收益。在丟包比較多、或丟包模型不符合一定條件時(shí)，不用FEC會(huì)劃算，這是一種平衡。如果能夠通過網(wǎng)絡(luò)狀態(tài)探測(cè)到，并且能夠根據(jù)當(dāng)前的丟包率、RTT的時(shí)間，能夠動(dòng)態(tài)調(diào)整，達(dá)到一個(gè)平衡就能知道什么場(chǎng)景下用什么方式是最劃算的。

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

?

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

所謂的內(nèi)容，是指內(nèi)容的復(fù)雜度，復(fù)雜度可以表征為時(shí)間復(fù)雜度和空間復(fù)雜度。時(shí)間復(fù)雜度就是每幀之間的變化，比如運(yùn)動(dòng)是否劇烈。空間復(fù)雜度是幀內(nèi)的畫面復(fù)雜度。根據(jù)這些來動(dòng)態(tài)估計(jì)碼率的決策，可以使得碼率更加合理，達(dá)到最優(yōu)值，減少卡頓和延遲。

智能調(diào)速能夠根據(jù)各種條件實(shí)時(shí)動(dòng)態(tài)調(diào)整碼率。調(diào)整碼率不能太頻繁，不能一秒鐘內(nèi)立刻就變了，那也是有問題的，它也得有一定的調(diào)整時(shí)間的限制。這個(gè)圖可以看出，如果調(diào)整的時(shí)間合理，隨著網(wǎng)絡(luò)帶寬的恢復(fù)，碼率也能恢復(fù)。當(dāng)然恢復(fù)是慢速恢復(fù)，下降則是快速下降。為了盡量消除卡頓，帶寬必須快速下降，而上升則是慢慢上升。

?

還有一個(gè)問題是最短傳輸路徑。如果端到端，在兩個(gè)端上解決這個(gè)問題，其實(shí)還不是徹底地解決，因?yàn)樵诼飞蟼鬏斔牡臅r(shí)間和網(wǎng)絡(luò)節(jié)點(diǎn)是從哪兒走有關(guān)。如果網(wǎng)絡(luò)節(jié)點(diǎn)之間，能夠把路況都探測(cè)到、獲取到不同路徑的延遲和帶寬情況，就可以尋找到最小延遲路徑來解決延遲這個(gè)問題，使得網(wǎng)絡(luò)傳輸之間自主選路。再加上上面端到端之間的媒體抗弱網(wǎng)，在端到端之間、2個(gè)媒體節(jié)點(diǎn)之間做抗丟包，綜合起來之后可以達(dá)到完整的方案。每個(gè)節(jié)點(diǎn)都做了優(yōu)化，就可以解決好這個(gè)問題。

-03-

低延遲視頻應(yīng)用案例

最后說一下應(yīng)用場(chǎng)景。

?

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

這是我們中興做的一個(gè)網(wǎng)關(guān)，上面帶5G天線，里面可以接幾個(gè)攝像頭，也可以接工業(yè)、車載控制的口，接口豐富。可以接SDI的攝像頭，這種攝像頭延遲是比較低的。還有就是接入IP攝像頭，它已經(jīng)把視頻編碼和打包好了。最后工業(yè)設(shè)備的控制，通過遠(yuǎn)程控制臺(tái)可以控制前面的設(shè)備。IP攝像頭的延遲取決于攝像頭編碼和采集的延遲。因?yàn)樯厦嬗?G天線，所以可以實(shí)現(xiàn)遠(yuǎn)程控制。

?

還有一種是可以有一個(gè)網(wǎng)關(guān)，前面攝像頭已采集的視頻經(jīng)過它做一次轉(zhuǎn)碼，轉(zhuǎn)碼之后再通過天線從基站過來，再把視頻進(jìn)行回傳。這是我們的另外一個(gè)設(shè)備，它可以進(jìn)行網(wǎng)關(guān)的轉(zhuǎn)碼或合成，畫面也可以在里面合成，合成網(wǎng)關(guān)設(shè)備可以和前面的設(shè)備形成互補(bǔ)。

案例1是煤礦。左邊是煤礦的機(jī)械，在井道里面，如果將網(wǎng)關(guān)放在車上，可以在機(jī)械上放幾個(gè)攝像頭，遠(yuǎn)程控制中心可以看到礦井內(nèi)視頻，就不用人在下面開車了，可以在地面的集控中心控制它。因?yàn)檫@個(gè)機(jī)械的延遲要求估計(jì)在100毫秒就夠，它運(yùn)動(dòng)速度不快，就可以解決井下工人工作環(huán)境危險(xiǎn)的問題。這是通過遠(yuǎn)程控制減少人工成本的比較有價(jià)值的應(yīng)用。

?

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

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

還有就是車聯(lián)網(wǎng)。車聯(lián)網(wǎng)一個(gè)場(chǎng)景是用在車上，一個(gè)是用在路測(cè)單元。路測(cè)單元需要把路上采集的視頻回傳回去，運(yùn)算時(shí)在邊緣的機(jī)房進(jìn)行計(jì)算，計(jì)算完后報(bào)告給路上的一些相關(guān)車輛，這樣可以形成路和車之間的協(xié)同。

我的分享就到這里，謝謝。