編碼和封裝：引入延遲和參數(shù)配置、質(zhì)量要求密切相關(guān)。某些流媒體協(xié)議可能會(huì)引入額外的延遲，因?yàn)樗鼈冎挥性谕耆邮盏胶蟛泡敵鲆淮髩K（chunk）媒體內(nèi)容。
第一英里上傳（first mile upload）：將打包內(nèi)容上傳到 CDN 通常會(huì)受到商業(yè)條款的限制。例如，與來(lái)自新聞工作室的租用線(xiàn)路設(shè)置相比，如果通過(guò)無(wú)線(xiàn)連接完成上傳將會(huì)產(chǎn)生更大的延遲。
CDN 傳播：為了大規(guī)模傳送內(nèi)容，大多數(shù)媒體管道都利用內(nèi)容傳送網(wǎng)絡(luò) (content delivery network)。因此，內(nèi)容需要在不同緩存之間傳播，從而引入額外延遲。
最后一英里交付 (last mile delivery)：用戶(hù)網(wǎng)絡(luò)連接可能會(huì)對(duì)延遲產(chǎn)生重大影響。用戶(hù)可以在家庭網(wǎng)絡(luò)連接到 wifi 熱點(diǎn)，或者使用移動(dòng)連接來(lái)訪(fǎng)問(wèn)網(wǎng)絡(luò)內(nèi)容。此外，由于可能會(huì)選取不同遠(yuǎn)近的 CDN 端點(diǎn)，用戶(hù)地理位置也會(huì)造成額外延遲。
播放器緩沖區(qū)：視頻播放器必須緩沖媒體以確保流暢播放。緩沖區(qū)大小通常在媒體規(guī)范中定義，但具有一定靈活性。播放緩沖是延遲的主要因素，優(yōu)化緩沖區(qū)配置是常態(tài)。
fig.1 (延遲來(lái)源)
典型延遲（typical latency）18-45s：如下圖所示，在這個(gè)區(qū)域，我們看到一般都是 HLS 和 MPEG-DASH 設(shè)置，這兩種適用于非時(shí)間敏感的線(xiàn)性廣播，并且不會(huì)與廣播公司或社交媒體上的其他觀(guān)眾進(jìn)行任何交互。
較少延遲（reduced latency）5-18s：通過(guò)調(diào)整 HLS 和 MPEG-DASH 流來(lái)減少延遲，減少了 segment 大小并增加了 infrastructure 的大小。該方法通常用于直播新聞和體育賽事。
低延遲（low latency）1-5s：低延遲通常被視為每個(gè)發(fā)布者的目標(biāo)，因?yàn)樗试S更多交互式用例。
超低延遲（ultra low latency）200ms-1s：可以實(shí)現(xiàn)更好的交互性，感覺(jué)接近實(shí)時(shí)。雖然不適合語(yǔ)音通信或會(huì)議，但這種延遲通常對(duì)于常見(jiàn)用例而言足夠低。
實(shí)時(shí)通信（real time communication）0-200ms：實(shí)時(shí)通信對(duì)于雙向會(huì)議和通信等用例至關(guān)重要。
fig.2 (延遲長(zhǎng)短定義)
DASH 是一個(gè)類(lèi)似于 HLS 的分片傳輸協(xié)議（其中一些多軌道，無(wú)縫切換之類(lèi)的特性我們這里暫不討論），DASH 中的列表文件是 mpd (Media Presentation Description) 。根據(jù) mpd 中的幾個(gè)時(shí)間字段（fig.3），我們可以算出 服務(wù)器和播放器直接的端到端延遲，這點(diǎn)很重要（詳細(xì)算法可以看 dash.js 中 getCurrentLiveLatency 方法源碼）。
fig.3 (DASH 時(shí)間模型)
能準(zhǔn)確的獲取端到端延遲在直播中最重要的意義就是：我們有了控制延遲的基礎(chǔ)條件。在上面描述延遲圖中（fig.1），第二步到第四步的網(wǎng)絡(luò)傳輸抖動(dòng)是我們無(wú)法控制的，但是只要我們知道了延遲的具體時(shí)間，就可以通過(guò)控制播放器播放進(jìn)度，來(lái)實(shí)現(xiàn)快進(jìn)或者慢放來(lái)保持穩(wěn)定延時(shí)（sample）。 在下圖（fig.4）中，我們通過(guò)播放器設(shè)置將延遲控制在了 5s 整。
fig.4 (示例)
實(shí)現(xiàn)低延遲的第一個(gè)必需行為是分塊編碼（chunked encoding）。根據(jù) MPEG CMAF 標(biāo)準(zhǔn)，CMAF 中各個(gè)對(duì)象的命名如圖 1 所示。chunk 是最小的可引用單元，至少包含 moof 和 mdat 這兩部分。一個(gè)或多個(gè) chunk 以形成 fragment，一個(gè)或多個(gè) fragment 形成一個(gè) segment。標(biāo)準(zhǔn) CMAF 的 media segment 使用單個(gè) moof 和 mdat 編碼，如圖 2 所示，mdat 包含單個(gè) IDR（Instantaneous Decoder Refresh，瞬時(shí)解碼器刷新）幀，這是每個(gè) segment 開(kāi)始傳輸所必需的。
再次強(qiáng)調(diào)一下，只有滿(mǎn)足以下所有條件，才能穩(wěn)定實(shí)現(xiàn) ULL-CMAF 的減少延遲功能：
CMAF 段中的內(nèi)容是塊編碼的。
編碼器調(diào)整其 DASH manifest/ HLS playlist 以適應(yīng)分塊編碼的使用和數(shù)據(jù)的早期可用性。
編碼器使用 HTTP 1.1 塊編碼傳輸將內(nèi)容推送到 origin 處。
CDN 在分發(fā)鏈的每個(gè)步驟使用 HTTP 塊編碼傳輸。
客戶(hù)端：
準(zhǔn)確地對(duì) segment 的請(qǐng)求進(jìn)行計(jì)時(shí)，并在 live edge 的一個(gè) segment 持續(xù)時(shí)間內(nèi)請(qǐng)求該切片;
在接收到比特流時(shí)對(duì)其進(jìn)行解碼，并且不用等到 segment 傳輸結(jié)束。在瀏覽器中運(yùn)行的 HTML5 播放器必須使用 Fetch 而不是 XHR API，因?yàn)?Fetch 允許在數(shù)據(jù)仍在下載時(shí)讀取響應(yīng)主體;
有一個(gè)估計(jì)吞吐量的方案，因?yàn)闃?biāo)準(zhǔn)的 segment 定時(shí)技術(shù)將會(huì)失效;
具有緩沖和自適應(yīng)邏輯以應(yīng)對(duì)非常低的緩沖;
由于吞吐量波動(dòng)，如果它落后于直播流，要具有趕上直播流的功能。
優(yōu)化延遲的最佳解決方案（一）
優(yōu)化延遲的最佳解決方案（二）
優(yōu)化延遲的最佳解決方案（三）The importance of low latency in video streaming
視頻傳輸延遲分析及解決方案：CMAF、LHLSBEST PRACTICES FOR ULTRA-LOW LATENCY STREAMING USING CHUNKED-ENCODED AND CHUNK-TRANSFERRED CMAF
超低延遲 CMAF 流媒體方案解析
聯(lián)系客服
