技術解碼 - CMAF 技術解碼及實踐
在當今如火如荼的直播產業中，運行着各種各樣的流媒體封裝及傳輸協議，比如廣電行業應用最多的 HLS、風靡互聯網直播平臺的 RTMP、HTTP-FLV 以及海外 OTT 行業應用廣泛的 MPEG-DASH。這些流媒體封裝協議都有各自的利弊，比如 RTMP、FLV 這種流式傳輸媒體協議，能夠滿足實時直播場景低延時的要求，但是由於容器格式老舊，在一些新的編碼協議擴展、加密方案支持上，無法跟新迭代滿足需求。再比如 HLS、MEPG-DASH 這種文件切片式流媒體協議由於應用了 MPEG-TS 或 MP4 容器格式，在編碼器擴展、多音軌支持、版權保護方面有着得天獨厚的優勢，但是由於切片式生成和傳輸的缺陷，導致端到端延遲高一直是被用戶所詬病。面對這樣的割裂的格局，一種全新的、兼容性更高，針對上述幾個問題的通用容器格式和傳輸方案應運而生。
CMAF，全稱 Common Media Application Format，是由 Microsoft、Apple、MLBAM、Akamai 等行業巨頭向 MPEG 提出並在 2017 年被批准的一項國際標準。顧名思義，CMAF 旨在解決媒體擴展性、傳輸低延遲、內容可緩存性等通用問題的綜合性解決方案，整體上降低流媒體傳輸的成本以及提升用戶體驗。
首先先從媒體對象模型上了解下 CMAF 的組成：
圖 1.CMAF 數據模型圖
從圖中數據模型組成結構可以看出，在實際 Package 生產過程中，CMAF 包含了 manifest 文件中 Presentation、Selection Set、Switching Set、Track 以及真實的切片。
在邏輯上也可以用 Header、Segment、Chunk 以及 Track 來描述 CMAF 資源對象。
接下來重點介紹下這幾個結構。
圖 2.CMAF Header 結構圖
**CMAF Header：**CMAF Header 用於描述每個 CMAF Track 解析、解碼和現實等相關的配置，通常是起始於一個'ftyp'類型的 box，包含一個'moov'box，包含了整個 set 的 box 的序列號，基本以 init.m4s 形式呈現具體的內容。
圖 3. 包含一個 IOSBMFF 數據段的 CMAF Fragment
**CMAF Fragment：**如圖 3 中，每個 Fragment 通常由一個 ISOBMFF 段組成，可以獨立解碼和解密，當進行 chunked 傳輸時可以包裝多個 ISOBMFF 段。
圖 4.CMAF track 數據框架
**CMAF Track：**如圖 4 中，每個 track 中包含存儲在 CMAF 指定的容器中的編碼的媒體樣本，包括音頻，視頻和字幕， 由一個 CMAF 頭片段和其後的包含媒體樣本的 CMAF 切片組成。CMAF 序列包含存儲在 CMAF 指定的容器中的編碼的媒體樣本，包括音頻，視頻和字幕，源自 ISO 基本媒體文件格式（ISOBMFF）。
圖 5.CMAF Segment 結構
**CMAF Segement：**如圖 5 中，在一個 CMAF 序列中的一個或多個 CMAF Fragment 可以被打包成一個 CMAF Segment，每個 Segment 可以使用獨立的資源描述符進行引用和傳輸。爲了更高效編碼，通常每個音視頻 Fragment 長度在 2-6s，爲了保證 CMAF 低延時的效果，CMAF 的 Segment 的長度通常不會超過 10-12s。
圖 6.CMAF Chunk 數據結構圖
**CMAF Chunk：**如圖 6 所示，CMAF Chunk 是在直播編碼器中，在一個 CMAF Segmetn 沒有完整產生的情況下可以被分成不同的塊進行傳輸分發，用這種方法能夠使每一個 CMAF Fragment 能夠漸進式編碼、傳輸以及播放器的解碼。也能夠滿足廣播和多播的傳輸和識別。
除了瞭解上述基礎的數據結構外，CMAF 的媒體模型中還定義了多 track 集合以及自適應碼率的結構、爲了支持多語種 & 多視頻角度或編碼器的選擇集合和延遲綁定的數據結構、多 CMAF 序列進行同步編碼、解碼的基準時間數據模型等。
作爲通用的媒體封裝格式，CMAF 的特性優勢非常明顯，對比常用的幾個流媒體封裝協議看：
表 1. 多協議特性對比
通過上面幾種流媒體封裝和傳輸協議對比來看，幾乎所有維度 CMAF 都是完美 PK 對手。下面分別從擴展性、安全性、低延遲和多碼率自適應維度簡單分析下 CMAF 的特性。
圖 7. 多通道選擇集合
**擴展性：**如圖 7 所示，首先 CMAF 可以使用 track 的維度來分離音頻、視頻、字幕等，也可以使用多 track 去描述不通的編碼器或不同的碼率，這種方式可以很好支持多音軌、多碼率以及字幕的場景需求。
**安全性：**對於 OTT 視頻行業來說，版權保護一直是標準化需求，CMAF 繼承了 HLS 和 MPEG-DASH 對通用 DRM 方案（CENC）的支持能力。比如 CBC 加密模式中能夠支持 Apple 的 FairPlay DRM,CTR 加密模式下，支持谷歌的 widevine 以及微軟的 fairplay，基本滿足了 99.9% 的硬件設備級別加密要求。
**低延遲：**CMAF 把 segment 切成了更小的塊單元進行傳輸，首先不需要等待 segment 完全生成的編碼延遲，其次更快的請求響應能力能夠提升播放器的響應速度，整體上保證了播放器能夠在一個塊產生的延遲裏獲取到最新的一個塊，進行解碼和播放，從而降低延遲。
圖 8. 多 track 切換集合
**多碼率自適應：**CMAF 定義了可互操作的 CMAF 媒體配置文件。這些媒體配置文件制定瞭解碼和所需的編碼和編碼規則，以及確保動態自適應流所需的無縫跟蹤切換的需求，交換集可以在 CMAF 切片的邊界處切換和憑藉備選的 CMAF TRACK, 以不同的比特率和分辨率自適應地傳輸相同的流。
**資源利用率：**在傳統 HLS 和 DASH 共存的場景下，同一份流存在 mpeg-ts 以及 m4s 兩種不同格式的緩存，不利於提升資源命中率，當統一爲 CMAF 格式後，可以有效減少緩存，提升資源命中率，提升整體資源利用率。
仔細分析上述的特性，其實很多特性在 MPEG-DASH 的標準中已經實現，CMAF 對比 DASH 的優勢主要集中在低延遲，接下來我們重點分析下低延時的實現原理：
圖 9. 切片耗時、響應分析原理圖
在傳統的文件切片編碼器中，延遲往往由幾部分產生，比如爲了保證快速響應，分發歷史生成的片或者爲了保證傳輸最新切片，hold 住連接，等待最新的切片生成後再分發。
分析圖中的 case1，爲了保證對播放器的快速響應，直接分發了歷史分片 3，由於切片的長度爲 8s，生成第一個分片就會累計 8s 延遲，再加上當前編碼器中最新未生成的 3s 的緩存數據，那麼本次請求的延遲就是 11s 左右。
分析圖中的 case2，爲了降低延遲，hold 住請求 5s，然後分發最新的切片，那麼延遲就是 8s，雖然延遲對比 case1 略有下降，但是用戶的 Qoe 並不好，在最新分片生成的期間內，雖然保證了延遲都是 8s，但是所有的連接都會被 hold 住 0-8s，用戶首屏的體驗會比較差。
那麼在 CMAF 中，這種被 hold 和延遲大的問題都會被解決，首先能夠保證在任何時候都可以立刻響應，其次，即使當前的分片還沒有產生，也可以用 chunk 編碼的方式把當前片已經編碼後可解碼的部分立刻發出去，那麼對於圖中的 case 來說，保證立刻響應，延遲也控制在 3s。
對於這種大切片的情況，實時響應的要求下，能保證延遲控制在 0-8s。在實際的應用場景中，我們可以把分片長度控制小點，比如 4s 一個片，那麼整體的用戶延時能控制在 0-4s，首屏也能得到保證。
關於 CMAF 的應用，騰訊雲直播產品已經完成了編碼器部分的開發部署，配合直播 cdn 平臺，我們整體的設計思路如圖所示：
圖 10.CMAF 媒體處理框架
複用雲端原有的接流、轉碼處理的優勢能力，增加 CMAF Packager 模塊，用於處理 CMAF 的容器封裝等媒體處理工作，包裝成可以傳輸的 http chunk 推送給 http server 分發給終端播放器進行播放。以下是騰訊雲中國香港的媒體處理中心切片生成的 CMAF 流配合騰訊雲直播 cdn 分發的效果對比普通 DASH 流效果圖：
圖 11.CMAF 和普通 MPEG-DASH 效果對比圖
測試環境說明：
**編碼器位置：**雲直播中國香港集羣。
**推流：**中國香港騰訊雲 cvm，ffmpeg 文件推流。
**切片服務配置：**封裝模塊配置的切片爲 4s 一個，3 個分片爲窗口大小。
**測試地點：**中國深圳。
**測試播放器：**DASH.js
**效果：**整體效果看，CMAF 比普通的 MPEG-DASH 流降低了 15s 左右的延遲。當然，測試效果和播放器的策略有一定相關性。
分析 CMAF 和普通 MPEG-DASH 差異點：
1、傳輸方式：
普通 DASH 採用了文件式的傳輸方式，而 CMAF 採用了 chunk 流式傳輸方式。DASH 的每個文件包含了很多數據幀，而 CMAF 的每個 chunk 可以包含 1 幀或多幀就可以進行分發。
圖 12.CMAF Chunk 傳輸
圖 13. 普通 MPEG-DASH 文件傳輸
2、Segment 的組成方式
普通 DASH 的 Segment 由 1 個 mdat 組成，其中包含了 1 個 moof 和 1 個 mdat，mdat 包含了若干數據幀。CMAF 的 Segment 可以由 1 個或多個 Fragment 組成，每個 Fragment 可以包含 1 幀或若干幀。
圖 14.CMAF 中 m4s 分片結構圖
圖 15. 普通 MPEG-DASH 中 m4s 分片結構圖
關於播放器兼容性：
目前我們測試驗證主要基於幾款開源的 web 播放器，比如 DASH.js、THEOplayer。ios 和安卓端目前還沒驗證播放器相關特性以及兼容性問題。播放器兼容問題也一直是 DASH 和 CMAF 協議所面臨的挑戰。
長連接複用優化：
在傳統的 DASH 或 HLS 分發中，往往使用短連接來請求 m3u8 文件或 ts、mp4 分片，爲了更好提高傳輸效率，我們建議使用 HTTP2.0 多路複用或 HTTP1.1 長連接特性，複用 TCP 連接，文件索引列表和切片請求分別運行在 2 個的 TCP 連接上，整體上可以提升傳輸效率也能夠降低雲端服務器的連接數負載，提升整體的服務性能。
後記
很多技術，從原理角度理解是比較簡單明瞭的，但是真實地工程化應用到線上，保證海量、穩定可靠、低成本以及魯棒性高的服務，又是另一門高深的學問。我們會持續優化迭代 CMAF 的性能，爭取爲用戶帶來更好的音視頻流媒體服務體驗。
體驗指引
如果需要體驗雲直播的 CMAF 能力可以提工單聯繫我們技術人員獲取支持。歡迎大家體驗並提出寶貴意見。
參考文檔
1.Common Media Application Format for Segmented Media-ISO/IEC JTC1/SC29/WG11 N16186.
2.https://github.com/DASH-Industry-Forum/DASH.js/wiki/Low-Latency-streaming.
3.https://github.com/cannonbeach/ott-packager.
4.http://www.streamingmediaglobal.com/Articles/ReadArticle.aspx?ArticleID=135885&PageNum=1.
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/oEbiW_pSB97ih9B8Gwi6LA