前言：

延時話題屬于信號質(zhì)量優(yōu)化的重點(diǎn)和難點(diǎn)，前人有很多探索和解決方法，可以說這棵樹上結(jié)出了很多果實(shí)，促進(jìn)了技術(shù)的進(jìn)展，IP化新雨過后高處又冒出了嫩枝，筆者不自量力踩著前人搭好的梯子試圖嘗一嘗鮮。本文的內(nèi)容對于經(jīng)驗(yàn)豐富的工程師而言，可能存在頗多老調(diào)重彈之處，此次復(fù)習(xí)理論、溫故知新希望對更多讀者有所幫助。本篇將分上下兩期，為大家詳細(xì)介紹IP系統(tǒng)視音頻相對延時和絕對延時的一些心得。

無論在制作域還是傳輸域，計(jì)劃外的過大延時常是令工程師們頭疼的問題。伴隨著近幾年IP設(shè)備普及，系統(tǒng)鏈路設(shè)計(jì)多樣化，遠(yuǎn)程制作、云制作、虛擬制作等新興技術(shù)迅猛發(fā)展，老生常談的延時話題又有了新篇，延時大小也成為設(shè)備選型和系統(tǒng)設(shè)計(jì)時需要衡量的核心指標(biāo)之一。

在實(shí)際測量過程中，我們發(fā)現(xiàn)有時某一節(jié)點(diǎn)或某一段鏈路的延時很難直接量化，因此清晰的測量思路以及合理利用測試儀器至關(guān)重要。為了系統(tǒng)性進(jìn)行闡述，下面將常見的延時問題按筆者個人理解進(jìn)行簡單分類。

圖1：延時問題分類

延時(Delay)與延遲(Latency)有何不同

閱讀國外資料時，經(jīng)常會看到 “Delay”和“Latency”這兩個單詞，多數(shù)情況兩者進(jìn)行互換混用不會造成理解障礙，部分外國工程師也不會刻意去區(qū)分它們。但二者并不總是相同的，嚴(yán)格來講Delay是數(shù)據(jù)從一個端點(diǎn)傳輸?shù)搅硪粋€端點(diǎn)所花費(fèi)的時間。而Latency有雙重含義，有時被認(rèn)為是數(shù)據(jù)包從一個端點(diǎn)傳輸?shù)搅硪粋€端點(diǎn)所用的時間，這與單向Delay是一樣的，但更多的情況，Latency表示的是往返時間，包括發(fā)送數(shù)據(jù)包所需的時間加上它返回所需的時間。本文中闡述的多為單向延時，因此也不做過多區(qū)分。

一、相對延時

1.什么是相對延時？標(biāo)準(zhǔn)值從何而來？

音視頻相對延時是系統(tǒng)工程師們非常熟悉的一個概念，指的是由于系統(tǒng)內(nèi)音頻信號和視頻信號途經(jīng)不同路由，各設(shè)備信號處理時長有快有慢，導(dǎo)致音視頻信號再度匯聚時，存在相對定時誤差，也被稱作AV Delay。音視頻加嵌后的末級信號相對延時過大，將出現(xiàn)“口型對不上”的聲畫不同步現(xiàn)象，最終影響系統(tǒng)指標(biāo)和素材收錄。此外，如果監(jiān)看與監(jiān)聽信號間有過大的相對延時，超出可察覺門限甚至可接受門限，還會干擾到導(dǎo)播正常工作。

圖2：相對延時產(chǎn)生示意

那么專業(yè)制作系統(tǒng)相對延時的容限是多少？一些標(biāo)準(zhǔn)化組織對此給出了要求或建議，比如在EBU R37-2007中建議范圍是-60ms~+40ms（即音頻滯后60ms~音頻超前40ms），ATSC IS/191中是-45ms~+15ms。目前國內(nèi)更多采用的是由ITU-R BT.1359-1 (1998) 和GB/T 22150-2008 《電視廣播聲音和圖像的相對定時》中規(guī)定的-30ms~+22.5ms，那么這個范圍從何而來，背后有哪些深層的考慮？

圖3：BT.1359-1電視廣播聲音和圖像相對定時可察覺和可接受門限

經(jīng)過評估測試，在BT.1359中定義了以下概念：

平均可接受門限范圍：-185ms~+90ms（圖3中A-A’）

平均可察覺門限范圍：-125ms~+45ms（圖3中B-B’）

根據(jù)ITU制定的主觀評價等級，一個位于不可察覺平穩(wěn)段（圖3中C-C’）的信號，疊加上系統(tǒng)可能引入的誤差（B-C，-30ms；B’-C’，+22.5ms），依然能夠使系統(tǒng)輸出端音視頻相對延時保持在可察覺門限（B-B’）之上。因此，廣電總局測試以及索尼系統(tǒng)檢測服務(wù)都是以-30ms~+22.5ms作為系統(tǒng)內(nèi)音視頻相對延時的評判指標(biāo)。

2.相對延時與系統(tǒng)架構(gòu)有關(guān)嗎？有沒有參考經(jīng)驗(yàn)值？

不管采用基帶架構(gòu)、IP架構(gòu)或是混合架構(gòu)，以及系統(tǒng)鏈路如何設(shè)計(jì)，只要視音頻信號路由不同，都會存在相對延時。根據(jù)以往項(xiàng)目經(jīng)驗(yàn)，IP系統(tǒng)末級鏈路的相對延時平均典型值為+30ms左右，基帶系統(tǒng)普遍在+100ms上下，混合架構(gòu)需視混合程度具體分析。（數(shù)值僅供參考，系統(tǒng)設(shè)計(jì)或不同品牌設(shè)備可能有一定浮動）

圖4：索尼系統(tǒng)檢測服務(wù)對某IP系統(tǒng)音視頻相對延時檢測結(jié)果

圖5：總局對某IP/SDI混合系統(tǒng)音視頻相對延時檢測結(jié)果

3.相對延時超出標(biāo)準(zhǔn)范圍怎么辦？

音視頻相對延時問題的解決方法十分成熟，可以概括為先測量再校正。測量時首先打開同步信號發(fā)生器的LipSync (Leader)或AV Timing(Telestream）功能，將測試信號由外來通道輸入，解嵌后分別經(jīng)過待測系統(tǒng)的音、視頻鏈路，末級加嵌后由示波器AV phase (Leader)或 AV Delay (Telestream)功能測得音視頻相對延時量。需要注意的是，同步信號發(fā)生器和示波器需要具備相應(yīng)選件，且應(yīng)保持品牌一致，混用可能無法測量出結(jié)果。

圖6：利用同步信號發(fā)生器+示波器測量音視頻相對延時

除了用LipSync測試信號進(jìn)行測試外，還可以將聲畫同步校準(zhǔn)裝置LSC-1（圖7）擺放于鏡頭前，用攝像機(jī)拍攝這一圈LED，同時用話筒拾取其發(fā)出的蜂鳴，將經(jīng)過待測鏈路后的信號錄制下來，檢查回放內(nèi)容。當(dāng)LSC-1最上方黃色LED亮起時，會同步發(fā)出一個蜂鳴，如在回放中聽到蜂鳴時對應(yīng)亮起的LED是左半圈紅色，則表示系統(tǒng)為音頻超前；如亮起的是右側(cè)綠色，則表示系統(tǒng)為音頻滯后。相鄰兩個LED時間間隔為一幀，并且?guī)?0/60可選。類似設(shè)備在國外也有應(yīng)用，比如2022年歐歌賽，NEP用類似功能的Sync-it裝置進(jìn)行音視頻同步校準(zhǔn)。由于這種測試方法可以將現(xiàn)場→攝像機(jī)→系統(tǒng)完整鏈路全部囊括在測試范圍內(nèi)，所以是更偏重于實(shí)戰(zhàn)應(yīng)用層面的測試及校準(zhǔn)。

圖7：利用聲畫同步校準(zhǔn)裝置測量音視頻相對延時

如果不具備以上測試條件，也可通過在攝像機(jī)前朗讀爆破音、打板、扎氣球等動作，用慢動作服務(wù)器逐幀回放主觀判斷，進(jìn)行低精度替代。

4. IP系統(tǒng)中相對延時問題有高效的解決辦法嗎？

首先，IP系統(tǒng)與基帶系統(tǒng)沒有區(qū)別，也存在相對延時問題，其產(chǎn)生原因同樣是音視頻信號路由不同。對IP系統(tǒng)音視頻相對延時進(jìn)行測量時，既可以用IP示波器在IP域完成，也可以經(jīng)網(wǎng)關(guān)設(shè)備轉(zhuǎn)換為SDI信號后，再用傳統(tǒng)示波器測量。

?

圖9：Timestamp生成過程

IP系統(tǒng)中設(shè)備采用PTP協(xié)議同步，IP流利用RTP協(xié)議進(jìn)行分發(fā)，且在RTP Header中有Timestamp字段記錄時間戳。根據(jù)ST2059標(biāo)準(zhǔn)，各類信號雖采用不同頻率的采樣時鐘（視頻90kHz，音頻48kHz，輔助數(shù)據(jù)90kHz），但是仍舊可以根據(jù)PTP計(jì)算出RTP時鐘，再生成各個流的時間戳，在接收端也可以根據(jù)時間戳還原信號相位，最終保持信號同步。這是否意味著理論上可以通過Timestamp自動對齊視音頻流，以實(shí)現(xiàn)LipSync？

可惜的是，目前在系統(tǒng)層面暫時無法做到。其核心問題是：數(shù)據(jù)包每到達(dá)下一個設(shè)備并發(fā)出新流的同時，Timestamp字段會被重寫。換而言之，當(dāng)前最多可實(shí)現(xiàn)由A到B兩設(shè)備間音視頻流自動對齊。如果是更復(fù)雜但卻很現(xiàn)實(shí)的情況——音視頻流分別經(jīng)不同鏈路、多臺設(shè)備處理并路由，以目前的機(jī)制無法在系統(tǒng)層面實(shí)現(xiàn)全局自動Lipsync。

未來IP系統(tǒng)中是否可能產(chǎn)生自動Lipsync解決方案呢？業(yè)內(nèi)已經(jīng)有專業(yè)人士提出建議：帶內(nèi)攜帶原始時間戳——將音頻輔助數(shù)據(jù)也作為Payload有效載荷的一部分，或采用RTP頭部擴(kuò)展機(jī)制，或在帶外輔助數(shù)據(jù)中攜帶原始時間戳（這將需要通過新的標(biāo)準(zhǔn)或協(xié)議去定義，比如AES X242, ST2110-41/-42, 或者NMOS），利用原始時間戳將視音頻流對齊。另一種思路是：鏈路中所有信號處理設(shè)備將信息給到Broadcast Controller，并且能夠接受Broadcast Controller下發(fā)的指令，通過控制系統(tǒng)輔助實(shí)現(xiàn)時間對齊。

圖10：Broadcast Controller接收并發(fā)送時間對齊信息

不過筆者認(rèn)為想要實(shí)現(xiàn)全流程音視頻自動對齊還是存在一定技術(shù)難點(diǎn)，簡單列舉以下：

●?當(dāng)多路IP音頻流混音時，具備多個不同時間戳該以哪個為準(zhǔn)作為原始時間戳？

●?IP音視頻自動對齊時，如果希望對IP音頻流施加的延時量超出設(shè)備buffer容量時怎么處理？

●?在相對延時不穩(wěn)定的情況下，自動對齊會不停改變音頻延時量，是否會帶來打火聲？（或許可以通過算法進(jìn)一步消耗算力來解決，以實(shí)現(xiàn)變速不變調(diào)）

●?如果兩個音頻系統(tǒng)采用基帶信號互聯(lián)互通(比如二級調(diào)音或級聯(lián))，直到音頻網(wǎng)關(guān)類設(shè)備才轉(zhuǎn)換為IP流打上時間戳，這時視頻全流程都在IP域，音頻全流程則由基帶加IP兩部分組成，最終若在IP域?qū)崿F(xiàn)音視頻流自動對齊，將會有誤差，這樣做的意義和必要性看似不大。想要消除誤差，需要基帶音頻信號帶外傳輸時間信息，但如何將其轉(zhuǎn)換作為原始時間戳或許是需要突破的技術(shù)難點(diǎn)。目前看來，自動對齊最為適用的場景還是圖10中列舉的IP攝像機(jī)視頻信號和機(jī)頭Mic音頻信號之間的對齊。

以上問題為筆者個人疑問，歡迎各位讀者溝通交流。

相對延時總結(jié)：

●?基帶系統(tǒng)、IP系統(tǒng)、混合系統(tǒng)都存在相對延時問題。

●?測試系統(tǒng)相對延時用同步信號發(fā)生器+示波器組合更準(zhǔn)確，但也有其他替代手段。節(jié)目制作前的準(zhǔn)備階段可以用聲畫同步校準(zhǔn)裝置進(jìn)行輔助確認(rèn)。

●?轉(zhuǎn)播車、演播室系統(tǒng)中大多數(shù)情況都是音頻信號超前，通過在加嵌板卡（Sony IPG板卡AM50許可最大能夠延時250ms）或是調(diào)音臺主輸出母線相應(yīng)調(diào)整音頻延時量，即可消除末級信號中聲音和圖像的定時誤差。

●?如果監(jiān)聽信號與監(jiān)看信號間存在不同步，可以通過監(jiān)聽延時器或調(diào)音臺監(jiān)聽母線調(diào)整延時，結(jié)合主觀判斷，控制監(jiān)聽聲音滯后一定量，達(dá)到與監(jiān)看圖像匹配的目的。

編輯：黃飛

?