按照JW Player技術高級副總裁John Luther的說法，CMAF將在2019年快速發(fā)展，盡管這項技術在國內還不怎么流行。蘋果、微軟以及Akamai都在支持CMAF。在下周舉行的LiveVideoStackCon 2018上，Akamai 首席架構師William Robert Law將會分享如何通過CMAF提供海量并發(fā)的低延遲流媒體服務的。

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

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

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

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

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

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

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

“我們現(xiàn)在開始看到的是客戶說‘嘿，我們想降低延遲。’” Alexander說到。

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

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

走向被更廣泛采用的道路

Akamai擁有編碼器驗證流程，并且目前擁有5個經過CMAF超低延遲解決方案認證的編碼器。相比之下，它有13個通過其當前標準的10~12秒延遲媒體服務產品認證的編碼器。因此，仍有一些問題亟待解決，但對CMAF的支持正在Akamai的編碼器計劃中進行。

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

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

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

但是，僅僅因為Akamai建立了自己的播放器并不意味著CMAF支持不在播放社區(qū)中。

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

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

“但在過去的六個月里，我聽到的幾乎全是任何關于低延遲自適應流媒體的要求，”Luther說到。

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

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

塊轉移的未來

2016年，當蘋果宣布向HLS添加fMP4支持時，CMAF塊運輸?shù)玫搅撕艽蟮耐苿印Ｎ覀兊南敕ㄊ牵珻MAF將減少為編碼為HLS和DASH的內容設置單獨的筒倉的需要。

但當時，加密是一個問題。 也就是說，CMAF支持的兩種不兼容的加密模式—密碼塊鏈接（CBC）和計數(shù)器模式（CTR）仍然需要單獨的視頻流。這是因為Apple的HLS只支持CBC，而歷史上Google的Widevine只支持CTR，Luther說。

“Widevine現(xiàn)在支持兩者，故而打破了這一僵局，”Luther說。“這不是CMAF的錯。而是兩家最大的DRM技術供應商同意不同意的錯。”

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

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