MPEG-DASH視頻流中6種最常見的隱患

作為dash.js項目的首席開發(fā)人員，我們經(jīng)常面對這樣的情況：我們必須評估DASH傳輸失敗是由dash.js播放器實現(xiàn)中的實際bug引起，還是由錯誤的內(nèi)容生成引起。在本文中，我們將分享一些在DASH傳輸中出現(xiàn)的常見錯誤，以及我們通常在面對這些錯誤時所總結(jié)的一些見解。

/ DRM的特定問題 /

“想要安全，請使用https”

在播放受到DRM保護(hù)的視頻的時候，經(jīng)常會出現(xiàn)一個與底層應(yīng)用托管有關(guān)的錯誤。為了能夠使用EME（加密媒體擴(kuò)展，DRM播放以及與CDM通信時必須用到的W3C API），Web瀏覽器通常必須使用https。如果使用http調(diào)用應(yīng)用，dash.js將輸出警告：無法進(jìn)行DRM播放。

No supported version of EME detected on this user agent! - Attempts to play encrypted content will fail!

保護(hù)自己免受保護(hù)

DRM本身是一個比較復(fù)雜的話題。有一個顯而易見的事實是：有三種主要的DRM系統(tǒng)，分別是：Google Widevine、Microsoft PlayReady和Apple FairPlay。在Google Chrome和Mozilla Firefox中，需要Widevine才能啟動DRM播放，但是老款Edge卻只支持PlayReady。一些設(shè)備（如智能電視或者FireTV）同時支持Widevine和PlayReady。因此，在特定平臺試圖播放DRM保護(hù)內(nèi)容之前，我們需要評估具體平臺底層對DRM的功能支持。當(dāng)使用dash.js時，一旦找到并選擇了合適的DRM系統(tǒng)，就會顯示如下輸出：

DRM: KeySystem Access Granted (com.widevine.alpha)!

如果某個平臺支持多種DRM系統(tǒng)，那么定義選擇優(yōu)先級會很有用。

{    "com.widevine.alpha": {        "serverURL": "someurl",        "priority": 1    },    "com.microsoft.playready": {        "serverURL": "someurl",        "priority": 2    }}

比如按照上例中的配置，dash.js會優(yōu)先考慮使用Widewine DRM, 而不是PlayReady。

你可以在之前的博文中了解到更多DRM知識：https://websites.fraunhofer.de/video-dev/enabling-hardware-drm-on-android-chrome-using-the-encrypted-media-extensions/

https://websites.fraunhofer.de/video-dev/dash-js-license-acquisition-for-multiple-eme-versions/

模式化一切

在《dash.js：多個EME版本的許可獲取》（dash.js: License acquisition for multiple EME versions）[1]一文中，我們描述了dash.js 內(nèi)容保護(hù)模型的概念，從中得到的關(guān)鍵點(diǎn)是：dash.js實現(xiàn)了三種不同版本的EME（被封裝在不同的內(nèi)容保護(hù)模型中）。遺憾的是，很多設(shè)備（向那些“樂于”為智能電視和機(jī)頂盒開發(fā)的人問候）需要定制其中一種保護(hù)模型。在此類設(shè)備上調(diào)試DRM問題時，這件事很值得做：總是檢查EME調(diào)用是否需要被前置或者另做修改。

/播放時序的特定問題 /

“請保證您的播放器的當(dāng)前播放時間不要掉出滑動窗口”

當(dāng)開發(fā)DASH播放器或者創(chuàng)建DASH MPD時，一個關(guān)鍵概念是要理解DASH時序模型。你可以通過閱讀

DASH-IF IOP guidelines[2]和DASH-IF implementation guidelines: restricted timing model[3]了解DASH時序模型。

我們經(jīng)常遇到的一個問題由視頻流引起，其中可用媒體切片的呈現(xiàn)時間在時移緩沖區(qū)之外。當(dāng)給出了帶有 的明確時間信息時，播放器能夠調(diào)整自身操作。下圖就說明了這種調(diào)整：

播放器使用 MPD@timeShiftBufferDepth屬性確定DVR窗口。除此之外，從“UTC now”時間中減去當(dāng)前的即時直播延遲時間，就能得到“實際的DVR窗口時長”（比“名義的DVR窗口時長”要短）。在直播期間，上層應(yīng)用只能在有效的DVR窗口內(nèi)進(jìn)行播放移動。

在上面的示例中，最后一個可用切片（第5個切片）的呈現(xiàn)結(jié)束時間在DVR窗口之外。在這種情況下，播放器將找不到可供下載和播放的切片。在這種情況下，dash.js可以將anchor time（基準(zhǔn)時間）調(diào)整到最近已播放切片的presentation end time（該切片的呈現(xiàn)截止時間），從而得出用于計算有效DVR窗口的調(diào)整值，以避免播放停頓。該功能通過調(diào)整設(shè)置參數(shù)實現(xiàn)，如下所示：

player.updateSettings({   streaming:     {     calcSegmentAvailabilityRangeFromTimeline: true    }})

使用Offset避免Upset

為了能夠在DASH視頻流中插入廣告，MPD經(jīng)常使用多種分段時間。讓我們來看一個非常簡單的示例：我們想向主要內(nèi)容（main content）添加一個中貼片廣告。

這種情況下，我們在切換為廣告內(nèi)容前，先播放8秒主要內(nèi)容。廣告結(jié)束后，我們重新播放主要內(nèi)容。所有分段持續(xù)時間總和構(gòu)成了18秒媒體呈現(xiàn)持續(xù)時間。

為了將視頻切片對應(yīng)到媒體緩沖區(qū)中的目標(biāo)位置，MSE對切片的內(nèi)部呈現(xiàn)時間戳（既最早的呈現(xiàn)時間EPT，Earliest Presentation Time）添加了可配置的timestampOffset。因此，應(yīng)用可以通過調(diào)整timestampOffset控制切片在緩沖區(qū)中的位置。

現(xiàn)在，以上所述對我們的示例而言又有什么意義呢？讓我們假設(shè)主要內(nèi)容中的第一個切片和廣告內(nèi)容中的第一個切片的EPT為0。在DASH視頻流中，一個切片的呈現(xiàn)時間與其分段時間的開始有關(guān)。如果我們僅僅將每個切片的MSE.timestampOffset設(shè)置為每個分段時間的起始時間會發(fā)生什么？如下所示：分段時間1和分段時間2沒有問題。

--- Period 1 ---MSE.timestampOffset = Period@start = 0BufferPosition(Seg 1) = MSE.timestampOffset + EPT = 0 + 0 = 0 BufferPosition(Seg 4) = MSE.timestampOffset + EPT = 0 + 6 = 6 --- Period 2 --- MSE.timestampOffset = Period@start = 8BufferPosition(Seg 1) = MSE.timestampOffset + EPT = 8 + 0 = 8 BufferPosition(Seg 2) = MSE.timestampOffset + EPT = 8 + 2 = 10

但問題出現(xiàn)在分段時間3。因為我們從第5個切片開始，EPT沒有設(shè)置為0。

--- Period 3 ---MSE.timestampOffset = Period@start = 12BufferPosition(Seg 5) = MSE.timestampOffset + EPT = 12 + 8 = 20 

沒有將分段時間3的第一個切片定位在媒體呈現(xiàn)時間線中的第12秒，而是在第20秒時結(jié)束了。幸運(yùn)的是，有一個方法很容易解決剛剛的問題：在MPD中，我們可以為每個時間段分配一個單獨(dú)的@presentationTimeOffset （注意：在此示例中，我們做了一些簡化處理）。

在MPD中，對于每個 Representation而言，@presentationTimeOffset都不同。dash.js 使用@presentationTimeOffset來計算 MSE.timestampOffset。我們將@presentationTimeOffset的值設(shè)置為該時段中第一個切片的EPT：

--- Period 3 ---MSE.timestampOffset = Period@start - @presentationTimeOffset = 12 - 8 = 4BufferPosition(Seg 5) = MSE.timestampOffset + EPT = 4 + 8 = 12 BufferPosition(Seg 6) = MSE.timestampOffset + EPT = 4 + 10 = 14 

現(xiàn)在所有切片都處在媒體緩沖區(qū)的正確位置，我們終于得到了一個連續(xù)的媒體呈現(xiàn)時間線。

關(guān)注緩沖——前方空隙

基于MSE的播放器有一個大問題，那就是時間線中的時間空隙。大部分MSE實現(xiàn)無法處理這種情況，因為其中的媒體緩沖并不連續(xù)，而且一旦播放位置到達(dá)空隙，緩沖就會停止。那么當(dāng)我們在討論空隙以及產(chǎn)生空隙的原因時，到底意味著什么？從我們的經(jīng)驗來看，空隙主要由以下兩個原因引起：

• 后續(xù)時間段沒有對齊，結(jié)果時間段邊界處的切片也無法對齊。

• 切片中的總媒體樣本持續(xù)時間短于其呈現(xiàn)持續(xù)時間所指示的時間。

最終就導(dǎo)致了如下情況的發(fā)生：

在這種情況下，切片1和切片2完美對齊，然而切片2和切片3之間有一個空隙。為了避免出現(xiàn)播放停止，dash.js會適時啟用一個復(fù)雜的空隙跳轉(zhuǎn)機(jī)制?？梢酝ㄟ^如下設(shè)置啟用和配置該機(jī)制：

player.updateSettings({   streaming:     {            jumpGaps: true,            jumpLargeGaps: true,            smallGapLimit: 1.5,    }})

/ 結(jié)語 /

本篇文章中，我們分享了MPEG-DASH視頻流中6種最常見的隱患。

當(dāng)播放受到DRM保護(hù)的視頻時，我們強(qiáng)調(diào)需要https，并概括了使用特定DRM系統(tǒng)平臺的重要性。除此之外，我們推動了實現(xiàn)EME舊版本的需求。

MPEG-DASH的時序模型并不容易理解。錯誤的DVR窗口會導(dǎo)致播放停止和失敗。在多時段廣告插入的背景下，使用MPD的具體屬性將時間段對齊以避免媒體緩沖的不連續(xù)很重要。此外，當(dāng)MSE實現(xiàn)無法處理媒體緩沖中的空隙時，應(yīng)避免媒體時間線中的空隙。

dash.js播放器能夠處理大部分以上情況，并幫助識別和解決此類問題。

審核編輯 ：李倩