如何通過(guò)CMAF提供海量并發(fā)的低延遲流媒體服務(wù)的

按照J(rèn)W Player技術(shù)高級(jí)副總裁John Luther的說(shuō)法，CMAF將在2019年快速發(fā)展，盡管這項(xiàng)技術(shù)在國(guó)內(nèi)還不怎么流行。蘋(píng)果、微軟以及Akamai都在支持CMAF。在下周舉行的LiveVideoStackCon 2018上，Akamai 首席架構(gòu)師William Robert Law將會(huì)分享如何通過(guò)CMAF提供海量并發(fā)的低延遲流媒體服務(wù)的。

在CMAF的幫助下，流媒體延遲可大大降低。（Pixabay）

在過(guò)去的幾年中，直播中的延遲水平有所提升，但隨著現(xiàn)場(chǎng)直播內(nèi)容的受眾增長(zhǎng)，對(duì)低延遲的要求也越來(lái)越高。而這就是CMAF的用武之地。

通用媒體應(yīng)用格式（CMAF）不一定是新格式。它與已經(jīng)使用了多年的分散的MP4密切相關(guān)。由Apple和Microsoft合作，CMAF的想法是為HLS或DASH（兩種主流流媒體協(xié)議）創(chuàng)建標(biāo)準(zhǔn)化的傳輸容器，以避免視頻流工作流程中增加的成本與復(fù)雜性。

Akamai Technologies產(chǎn)品管理高級(jí)主管Jon Alexander表示，CMAF允許進(jìn)行塊轉(zhuǎn)移。這意味著視頻片段仍由編碼器在播放器播放時(shí)創(chuàng)建。因此，必須將播放器在視頻收到整個(gè)文件之前就開(kāi)始渲染視頻。

塊傳輸可以幫助降低現(xiàn)有的延遲級(jí)別。

Alexander表示，大約三到四年前，無(wú)論是使用HLS還是DASH，端到端延遲的默認(rèn)值大約為30~45秒。 Akamai表示，它的低延遲產(chǎn)品大約兩年前推出，提供10~12秒的延遲，而現(xiàn)在則是該公司的標(biāo)準(zhǔn)。

這是用于如2018年世界杯等大型直播活動(dòng)的標(biāo)準(zhǔn)。但隨著這些事件繼續(xù)吸引了更多的直播觀眾，廣播公司希望延遲性能能夠有進(jìn)一步地提升。

“我們現(xiàn)在開(kāi)始看到的是客戶說(shuō)‘嘿，我們想降低延遲?！?Alexander說(shuō)到。

考慮到這一要求，IBC的Akamai在9月份通過(guò)大塊轉(zhuǎn)移展示了CMAF流媒體，將延遲降低到了不到一秒的水平。

它現(xiàn)在在Akamai的平臺(tái)上得到了本地支持，但挑戰(zhàn)則在于視頻工作流程需要編碼器和能夠支持塊傳輸?shù)牟シ牌鳌?/p>

走向被更廣泛采用的道路

Akamai擁有編碼器驗(yàn)證流程，并且目前擁有5個(gè)經(jīng)過(guò)CMAF超低延遲解決方案認(rèn)證的編碼器。相比之下，它有13個(gè)通過(guò)其當(dāng)前標(biāo)準(zhǔn)的10~12秒延遲媒體服務(wù)產(chǎn)品認(rèn)證的編碼器。因此，仍有一些問(wèn)題亟待解決，但對(duì)CMAF的支持正在Akamai的編碼器計(jì)劃中進(jìn)行。

但是為了在9月的IBC展示它的超低延遲演示，Akamai建立了自己的播放器。

使用自定義dash.js播放器，Akamai演示了一個(gè)使用目標(biāo)延遲的播放器。這意味著播放器嘗試與直播同步，并在現(xiàn)場(chǎng)后停留3~5秒。

該公司還在解決滑點(diǎn)問(wèn)題，這是指低延遲流中的變化或延遲。Akamai的dash.js播放器可以使用設(shè)置的延遲目標(biāo)動(dòng)態(tài)地重新分配直播和實(shí)時(shí)廣播，以防止在延長(zhǎng)的觀看時(shí)間內(nèi)累積滑點(diǎn)。在60分鐘的時(shí)間內(nèi)，就可以在一到兩分鐘內(nèi)將直播放到現(xiàn)場(chǎng)。

但是，僅僅因?yàn)锳kamai建立了自己的播放器并不意味著CMAF支持不在播放社區(qū)中。

JW Player技術(shù)高級(jí)副總裁John Luther表示，他的公司正在努力在2019年為其播放器增加CMAF支持。

Luther說(shuō)，與許多人希望的相比， CMAF需要更長(zhǎng)的時(shí)間來(lái)獲得行業(yè)認(rèn)可采用，他說(shuō)DASH也是如此。另外，他談到HLS是當(dāng)今流媒體的主流格式，而具有MPEG-2傳輸段的HLS可以很好地滿足當(dāng)今大多數(shù)流媒體的需求。

“但在過(guò)去的六個(gè)月里，我聽(tīng)到的幾乎全是任何關(guān)于低延遲自適應(yīng)流媒體的要求，”Luther說(shuō)到。

他表示，部分需求來(lái)自Flash的實(shí)時(shí)消息傳遞協(xié)議（RTMP）部分，實(shí)際上已經(jīng)消失—并且業(yè)界意識(shí)到HTML5沒(méi)有真正的實(shí)時(shí)傳輸協(xié)議。而他認(rèn)為，CMAF塊轉(zhuǎn)移可以滿足這種需求。

“為了做到這一切并確保每個(gè)人都符合CMAF，測(cè)試它并將其放入編碼管道，包裝，CDN和整個(gè)生態(tài)系統(tǒng)中，這需要做很多工作。而這項(xiàng)工作現(xiàn)在已經(jīng)開(kāi)始了，”Luther說(shuō)?！皶r(shí)機(jī)到了，我認(rèn)為2019年將是它的突破年。”

塊轉(zhuǎn)移的未來(lái)

2016年，當(dāng)蘋(píng)果宣布向HLS添加fMP4支持時(shí)，CMAF塊運(yùn)輸?shù)玫搅撕艽蟮耐苿?dòng)。我們的想法是，CMAF將減少為編碼為HLS和DASH的內(nèi)容設(shè)置單獨(dú)的筒倉(cāng)的需要。

但當(dāng)時(shí)，加密是一個(gè)問(wèn)題。 也就是說(shuō)，CMAF支持的兩種不兼容的加密模式—密碼塊鏈接（CBC）和計(jì)數(shù)器模式（CTR）仍然需要單獨(dú)的視頻流。這是因?yàn)锳pple的HLS只支持CBC，而歷史上Google的Widevine只支持CTR，Luther說(shuō)。

“Widevine現(xiàn)在支持兩者，故而打破了這一僵局，”Luther說(shuō)?！斑@不是CMAF的錯(cuò)。而是兩家最大的DRM技術(shù)供應(yīng)商同意不同意的錯(cuò)?！?/p>

Luther表示，加密媒體擴(kuò)展規(guī)范中還有一個(gè)新的API，用于檢測(cè)瀏覽器支持的加密模式，并且它應(yīng)該進(jìn)一步幫助加速CMAF的采用。

在可以開(kāi)始影響消費(fèi)者體驗(yàn)上，CMAF還有很長(zhǎng)的路要走。但Luther表示，如果CMAF由所有內(nèi)容交付網(wǎng)絡(luò)，包裝供應(yīng)商和其他所有人實(shí)施，那么它將具有實(shí)現(xiàn)自適應(yīng)流分秒傳送的潛力。