作為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)給出了帶有
播放器使用 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 = 0
BufferPosition(Seg 1) = MSE.timestampOffset + EPT = 0 + 0 = 0
BufferPosition(Seg 4) = MSE.timestampOffset + EPT = 0 + 6 = 6
--- Period 2 ---
MSE.timestampOffset = Period@start = 8
BufferPosition(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 = 12
BufferPosition(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 = Period12 - 8 = 4 - =
BufferPosition(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播放器能夠處理大部分以上情況,并幫助識別和解決此類問題。
審核編輯 :李倩
-
視頻傳輸
+關(guān)注
關(guān)注
3文章
99瀏覽量
20975 -
DRM
+關(guān)注
關(guān)注
0文章
46瀏覽量
15091
原文標(biāo)題:MPEG-DASH視頻傳輸中的常見問題
文章出處:【微信號:livevideostack,微信公眾號:LiveVideoStack】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。
發(fā)布評論請先 登錄
相關(guān)推薦
評論