前言：

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

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

　　在實際測量過程中，我們發(fā)現(xiàn)有時某一節(jié)點或某一段鏈路的延時很難直接量化，因此清晰的測量思路以及合理利用測試儀器至關重要。前言：

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

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

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

圖1：延時問題分類

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

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

　　一、相對延時

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

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

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

　　那么專業(yè)制作系統(tǒng)相對延時的容限是多少?一些標準化組織對此給出了要求或建議，比如在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)檢測服務都是以-30ms~+22.5ms作為系統(tǒng)內(nèi)音視頻相對延時的評判指標。

　　2.相對延時與系統(tǒng)架構有關嗎?有沒有參考經(jīng)驗值?

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

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

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

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

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

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

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

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

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

圖8：冬奧會出鏡記者進行聲畫同步測試

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

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

圖9：Timestamp生成過程

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

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

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

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

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

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

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

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

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

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

　　相對延時總結(jié)：

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

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

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

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