前言：

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

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

在實際測量過程中，我們發現有時某一節點或某一段鏈路的延時很難直接量化，因此清晰的測量思路以及合理利用測試儀器至關重要。為了系統性進行闡述，下面將常見的延時問題按筆者個人理解進行簡單分類。

圖1：延時問題分類

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

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

一、相對延時

1.什么是相對延時？標準值從何而來？

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

圖2：相對延時產生示意

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

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

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

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

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

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

2.相對延時與系統架構有關嗎？有沒有參考經驗值？

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

圖4：索尼系統檢測服務對某IP系統音視頻相對延時檢測結果

圖5：總局對某IP/SDI混合系統音視頻相對延時檢測結果

3.相對延時超出標準范圍怎么辦？

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

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

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

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

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

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

首先，IP系統與基帶系統沒有區別，也存在相對延時問題，其產生原因同樣是音視頻信號路由不同。對IP系統音視頻相對延時進行測量時，既可以用IP示波器在IP域完成，也可以經網關設備轉換為SDI信號后，再用傳統示波器測量。

?

圖9：Timestamp生成過程

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

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

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

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

不過筆者認為想要實現全流程音視頻自動對齊還是存在一定技術難點，簡單列舉以下：

●?當多路IP音頻流混音時，具備多個不同時間戳該以哪個為準作為原始時間戳？

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

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

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

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

相對延時總結：

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

●?測試系統相對延時用同步信號發生器+示波器組合更準確，但也有其他替代手段。節目制作前的準備階段可以用聲畫同步校準裝置進行輔助確認。

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

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

編輯：黃飛

?