摘要：
想要優化延遲，可Latency到底是多少？延遲始終是媒體內容傳輸的一個重要關注點，人們也在不斷嘗試用新的方法來優化延遲，本文參考AWS的一些新技術，介紹了延遲的定義，以及如何具體測量延遲，給出了延遲的量化概念。
延遲的基本概念定義
爲什麼延遲會成爲直播的一個很大的問題？每當傳輸的內容對延遲敏感時，比如體育，遊戲，新聞等電視內容，還是電子競技，賭博等純OTT內容，都不希望有延遲。延遲的等待時間導致沒有觀看比賽的懸念；等待讓觀衆成爲娛樂和實時信息領域的二等公民。比如觀看足球比賽時：你的鄰居在電視上觀看這場比賽，而你的OTT服務只能提供給你相對鄰居有25-30s延遲的直播比賽，這就導致你在聽到鄰居的慶祝喊叫後，纔看到接下來的進球，這是令人沮喪的，這也類似於你最喜歡的歌唱比賽結果被同時在觀看比賽的Twitter或Facebook 所傳播，而後者一般延遲較低，進而導致你又提前知道結果。
除廣播傳輸延遲和社交網絡競爭之外，內容提供商最大限度地減少實時傳輸延遲還有其他的原因。以前使用RTMP流的Flash應用程序在延遲方面表現良好，但隨着Flash在Web瀏覽器中漸漸被棄用，CDN在交付方面也將棄用RTMP，因此內容提供商需要切換到HTML5友好的流式傳輸技術，如HLS和DASH，或最近的CMAF。其他一些內容提供商希望開發具有交互功能的個人廣播服務，並且在這種情形下一般視頻信號30秒延遲無法接受。此外，那些想要開發同步第二屏幕，社交會議等應用程序的人需要在更精細級別上控制流式傳輸延遲。
在延遲方面，通常會有三個級別，有兩個邊界劃分，高邊界和低邊界，表一列出了不同級別延遲的劃分。廣播傳輸延遲一般爲3到12秒，具體取決於傳輸方式(有線/IPTV/DTT/衛星)和每個傳送網絡拓撲的結構等細節。經常出現6秒的廣播延遲的平均值，這意味着OTT的平均延遲點位於“reduced latency”的低範圍或“low latency”的高範圍內。
表1. 不同級別的延遲劃分
使用基於HTTP的流媒體，延遲主要取決於媒體切片(segment)的長度：如果媒體切片長度爲6秒，則意味着播放器已經比其請求第一個切片的實際時間晚至少6秒。許多播放器在實際開始播放之前將其他媒體切片下載到其緩衝區，這將自動增加到第一個解碼視頻幀的時間。當然，還有其他因素會產生延遲，例如視頻編碼過程的持續時間，攝取和打包操作的持續時間，網絡傳播延遲以及CDN緩衝區的延遲時間（如果有的話）。但在大多數情況下，播放器佔總體延遲的最大份額。實際上，大多數播放器通常會使用保守的啓發式算法並緩衝三個切片或更多切片的時間長度。
使用Microsoft Smooth Streaming，通常的切片長度爲2秒，通常在Silverlight播放器中以大約10秒的延遲。使用DASH，情況幾乎是一樣的。大多數播放器可以支持2秒切片，但在延遲方面會有不同。但是HLS的情況完全不同：直到2016年中期，Apple的建議是使用10秒的切片，最終大多數HLS播放器（包括Apple自己的播放器）的延遲時間約爲30秒。 2016年8月，Apple的技術說明TN2224表示，“我們過去建議使用10秒的目標持續時間。我們是不希望 突然重新細分 的內容。但我們確實相信，未來，6秒會是更好的方案。”每切片減少4秒，那麼12秒的延遲就會消失。大多數時候，內容製作者都會遵循Apple的建議，即使iOS播放器可以使用較小的切片長度，因爲他們不想冒險在AppStore中驗證他們的iOS應用程序。但最近的三次改進改變了iOS11上Safari Mobile的情況：啓用了實時HLS流的自動啓動功能; 對短的segment持續時間的支持得到顯著改善; 現在還支持FairPlay DRM。這意味着，內容製作者並非一定需要在iOS上使用已發佈的應用程序才能用短的segment來減少實時傳輸延遲，而可以通過DRM提供受保護的流。
有些人可能會考慮到短的媒體切片在CDN和播放器上引入很高的負載，但多年來，Microsoft Smooth Streaming利用2秒切片一直就是這種情況。爲了解決廣播傳輸中的延遲，下一步計劃是減少到1秒的切片，這實際上不會產生難以解決的問題。因爲它將請求數量乘以2，所有HTTP開銷都根據headers和TCP連接而定，而且它可以通過CDN進行管理（特別是如果它支持edge端的HTTP 2.0和origin端的HTTP 1.1，如Amazon CloudFront ），並且現在的播放器通過光纖，4G，LTE，DOCSIS 3.1 FD以及其他最先進的連接技術，可以從更高帶寬以及最後一英里連接中受益。實驗也表明，許多播放器現在支持1秒和2秒的短切片，因此提供了許多新的選項以降低延遲。而且對於HLS和DASH中的編碼器，打包器和origin服務，短的segment也通常不是問題。除了仍然要求6秒持續時間的AppStore之外，內容製作者可以靈活地在所有平臺上的各種播放器中試驗1或2秒的媒體切片，這樣做一般會減少延遲。
在較高的層面上，以下方式可以減少延遲：
- 優化視頻編碼的傳輸管道
- 根據要求選擇合適的segment持續時間
- 構建適當的架構
- 優化（或替換）視頻播放器
怎樣測量延遲
延遲優化過程的第一步是知道傳輸鏈中的每個部分在總延遲中的佔比，這可以讓我們知道優化的優先級。 首先從測量端到端延遲(measuring the end-to-end latency)開始。下面以AWS的部分產品作爲示例演示如何測量延遲。
測量端到端延遲的最簡單方法是使用運行clapperboard應用程序的平板電腦，使用連接到編碼器的攝像頭拍攝，將流發佈到 的origin處，然後通過CDN傳送到播放器。 將播放器放在clapperboard平板電腦旁邊，拍下兩個屏幕的圖片，在每個屏幕上減去時間碼，這樣就可以獲得延遲的值。然後這樣多做幾次，以確保它準確地表示傳輸過程的延遲。
圖1. 測量端到端延遲
或者，可以將AWS Elemental Live編碼器與一個循環文件源一起使用，將編碼器時間（使用NTP參考編碼器）刻錄爲視頻上的覆蓋圖，並將刻錄的時間碼與在瀏覽器窗口中的時間服務（如time.is）進行比較。 同時還需要添加捕獲延遲，這個值通常爲400毫秒左右。
捕獲延遲(capture latency)
可以在視頻編碼參數的預處理部分激活AWS Elemental Live上的時間碼刻錄; 需要爲編碼階梯中的每個比特率激活它。
圖2. AWS Elemental Live添加時間碼
需要驗證是否在低延遲模式下設置編碼器。在AWS Elemental Live中，在Input參數的“Additional Global Configuration”部分中選擇“Low Latency Mode”複選框。
圖3. 設置緩衝區大小和目標IP
接下來，在TS輸出部分設置一個帶有500 ms緩衝區的UDP / TS編碼事件，並將筆記本電腦IP作爲目標。在筆記本電腦上，使用：network-caching = 200選項打開VLC上的網絡流（在此示例中爲rtp：//192.168.10.62：5011），以使用200 ms的網絡緩衝區。通過比較燒錄的時間碼和clapperboard時間碼， 將能夠從VLC窗口的快照計算捕獲延遲。
圖4. 計算捕獲延遲
如果平板電腦不允許將其與NTP同步，那麼IOS上的某些應用程序（例如“Emerald Time”）可以得到平板電腦的時間漂移與NTP相比的程度。在我們的例子中，時間漂移是+ 0.023s，意味着clapperboard時間實際上是25：00.86而不是25：00.88。燒錄的時間碼是25:01:06（最後兩位是幀號），也就是25：01.25（因爲我們以24fps編碼）。因此，我們的捕獲延遲（25：01.25 - 25：00.86）= 0.39秒。 公式爲：捕獲延遲=以秒爲單位的Burnt Timecode - （Clapperboard時間碼+ NTP漂移）。
編碼延遲(encoding latency)
通過此UDP / TS編碼事件，我們還可以計算視頻編碼管道生成的延遲。我們的示例使用以下編碼參數，以便滿足一些高要求的場景。
圖5. 示例事件的視頻編碼參數
在我們的例子中，我們的平板電腦時間爲13：27：19.32，VLC時間爲13：27：16.75。
圖6. 編碼管道傳輸的結果
編碼管道延遲使用以下公式計算:(平板電腦時間 - VLC時間） - （捕獲延遲+ VLC緩衝區+ RTP緩衝區），轉換爲（19.32-16.75） - （0.39 + 0.20 + 0.50）= 1.48秒
獲取延遲(ingest latency)
現在我們知道了捕獲延遲和編碼管道的延遲，接下來是獲取延遲。“獲取延遲”包括打包攝取格式並將其攝取到origin端所需的時間。在這裏，我們使用HLS將1秒的切片推送到AWS Elemental MediaStore。使用shell，我們可以監視origin上HLS子播放列表的更改：
Powershell：
$ while sleep 0.01; do curl https://container.mediastore.eu-west-1.amazonaws.com/livehls/index_730.m3u8 && date +"%Y-%m-%d %H:%M:%S,%3N";
done
當在shell輸出中首次引用切片時，返回該切片。然後我們下載切片以驗證它攜帶的時間碼：16：49：53：37（UTC + 1）。當前日期和切片時間碼之間的差異是55.51 - 53.37 = 2.14秒。如果我們去除編碼延遲和捕獲延遲，我們會隔離打包HLS切片並將其推送到origin端所需的時間。公式爲攝取延遲=（當前日期 – 切片時間碼） - （捕獲延遲+編碼延遲）。對於AWS Elemental MediaStore，我們得到0.27秒。對於AWS Elemental Delta，相同的計算得出0.55秒。
再打包延遲(repackaging latency)
通過對AWS Elemental Delta和AWS Elemental MediaPackage應用相同的方法，並添加先前計算的獲取延遲，我們可以計算再打包攝取流所需的時間。 公式是再打包延遲=（當前日期 – 切片時間碼） - （捕獲延遲+編碼延遲+攝取延遲）
對於ElementalMediaPackage（假設攝取延遲與AWS Elemental Delta相同，因爲沒有簡單的方法可以測量它）HLS從攝取到輸出HLS 1秒切片，再打包延遲爲（57.34 - 54.58）- （0.39 + 1.48 + 0.55）= 0.34秒。 對於AWS Elemental Delta，其值爲（26.41 -23.86） - （0.39 + 1.48 + 0.55）= 0.41秒。
傳輸延遲(delivery latency)
相同的方法可以應用於交付 - 即從origin到CDN edge的傳輸。在origin端進行再包裝的情況下，傳輸延遲=（當前日期 – 切片時間碼）-（捕獲延遲+編碼延遲+獲取延遲+再包裝延遲）。當origin端通過流式傳輸時，傳輸延遲=（當前日期 – 切片時間碼）-（捕獲延遲+編碼延遲+攝取延遲）。 可以通過在origin端添加Amazon CloudFront分配並使用與攝取延遲計算相同的命令行來測量傳輸延遲。對於AWS Elemental MediaStore，我們有（52.71 - 50.40）-（0.39 + 1.48 + 0.27），這是0.17秒。對於同一區域中的所有origin端類型，此延遲是相同的。
客戶端延遲(client latency)
在此類別中，我們可以找到兩個受客戶端影響的延遲因素：最後一英里延遲（與網絡帶寬相關）和播放器延遲（與內容緩衝區相關）。最後一英里的延遲範圍從光纖連接上的幾毫秒到最慢的移動連接上的幾秒。內容下載持續時間直接影響延遲，因爲它延遲到T + x秒，此時時間碼T可用於在客戶端緩衝和播放。如果此延遲與切片長度相比太大，則播放器將無法構建足夠的緩衝區，並且它將導致播放器切換到較低的比特率，直到在比特率，網絡之間找到合適的折衷點。如果即使是最低的比特率也不允許構建足夠的緩衝區，那麼它將不斷播放，停止和再緩存，因爲內容無法足夠快地下載。一旦內容下載持續時間開始上升到切片大小的50％，它就會從緩衝區角度將播放器帶到危險區域。理想情況下，它應該保持在25％以下。
可以測量客戶端延遲的方式是客戶端延遲=端到端延遲 -（捕獲延遲+編碼延遲+攝取延遲+重新打包延遲+傳輸延遲）。可以通過從總體客戶端延遲中減去媒體切片的平均傳輸時間（也稱爲最後一英里延遲）來計算播放器延遲。
以下是使用AWS Elemental Live和AWS Elemental MediaStore生成的HLS 1秒切片的示例細分，隨Amazon CloudFront一起提供給標準的hls.js 0.8.9播放器：
表2. 傳輸中的各階段所佔延遲比例
正如表中所看到的，編碼和播放階段產生了大部分延遲，這是大部分改善延遲的所要關注的地方。 但這並不意味着沒有辦法優化其他步驟，但優化的影響相對較小。當輸出切片的大小增加時，播放器和最後一英里延遲通常會增加而其他階段的延遲幾乎保持穩定。
參考資料
https://aws.amazon.com/cn/blogs/media/how-to-compete-with-broadcast-latency-using-current-adaptive-bitrate-technologies-part-1/