所有的影音串流服務的營運單位都曉得， 日常的營運費用（OPEX）支出裏頭， 前三大的是支出分別是：
- 內容版權費
- 流量費
- 人事成本
內容版權費是大老闆與首席內容官（Chief Content Officer）的事； 人事成本是營運長（Chief Operation Officer）與研發主管的事； 至於流量費嘛（以及與它高度相關的儲存空間費用）， 我們都曉得這是影音服務有別於其它網路業的最大支出。 流量費也是這一篇 blog 或這個 CMAF 標準在關心的議題。
從多媒體技術的觀點來看的話，現在的影音串流服務是怎麼做到的呢？ 以我微薄的知識與見聞來看，目前成熟的技術市場，大概是有以下的幾塊：
- (Adaptive) streaming protocols: MPEG-DASH, HLS, HDS, MSS, RTMP, …
- Container format: MP4, fMP4, TS, MOV, …
- Video codec: H.264, HEVC, VP9, …
- DRM: PlayReady, Widevine, FairPlay, …
- Caption: SRT, WebVtt, …
- Ad: VAST, VPAID, …
以一家有點規模， 平台有至少包含 Android, iOS, Web, STB, … 的 VOD (Video-on-Demand）服務來看， 一部影片，會因為上述的 1, 2, 4 這三點，少則要準備個 2 份，多則要個 3, 4 份。 然後 1 份裏頭，又會因為有 adaptive streaming 而有很多的 profiles， 然後一個 profile 又可能因為 media segmentation 而有很多的檔案。
以一部 60 分鐘的影片，10 個 profiles，5 秒為一個 media segment 來看：
video duration: 1 hour
segment duration: 5 seconds
adaptive profiles: 10 (audio and video)
media segments: 60 * 60 * 10 / 5 = 7,200
一份會有 7,200 個檔。
如果來個 3, 4 份的話，就是會有 21,600 ~ 28,800 個檔案。
這對於儲存空間來說，是一筆支出，但更嚴重的，是對於流量的支出。 原本，一部影片，CDN 只要 cache 個一份， 現在因為上述的原因，變成要 cache 個兩三四份，糟透了。 理論上，網路流量的支出是要高於儲存的支出的，而且高很多。 除非，你在經營一家沒有人看的影音服務…
2015 ~ 2016 年之間，兩大巨頭，Microsoft & Apple，坐下來談一件事。 他們針對上述的問題，做了初步的努力，這個產物就是 CMAF (Common Media Application Format)。 CMAF 繼續了 MAF 的特性（或說是美德也行）， 它並沒有定義任何新的技術或規格， 相反的，它是基於現在的技術規格下， *挑選（或限制）*出了一些規範（ex, profiles）來符合當下的軟硬體需求。
CMAF defines the encoding and packaging of segmented media objects for delivery and decoding on end user devices in adaptive multimedia presentations. In particular, this is (i) storage, (ii) identification, and (iii) delivery of encoded media objects with various constraints on encoding and packaging. That means, CMAF defines not only the segment format but also codecs and most importantly media profiles (i.e., for AVC, HEVC, AAC). – CMAF Scope
簡單來看，CMAF 決定了基於 ISOBMFF (or fMP4) 的 media segment 格式、 audeio 與 video 的 codecs、 以及字幕（subtitle）檔的格式。 但是它並沒有包含 adaptive streaming protocol， 所以使用 HLS 或是 DASH 並不在這個 CMAF 的定義範籌裏頭。
CMAF 想像中的美好願景是： 未來，一部影片只需要儲存一份，串流時也只要一種格式，CDN 也只要暫存一種就行。 同樣都是 fMP4（bye bye, TS)、 同樣都是採用 AVC, AAC, HEVC, VP9(?)、 字幕檔的格式都一樣… 是個美好的大同世界~
如果沒有 DRM，影音串流執行起來，困難度應該會少掉不少…
借用 STREAMING FORMAT EVOLUTION — DOES CMAF GIVE US THE SINGLE FORMAT? 的圖來看會更清楚一點。 以下是一張從 streaming protocol 往內看，層層扒開，一路往內看的圖示。
DASH 與 HLS 在最外頭，它最薄，也最無關痛癢。 DASH 簡單來說，就是個 XML 檔搭配一些規範以及 validation rules。 而 HLS 則更是簡單到爆炸的類 txt 檔 。 它們倆都短小精幹，相對於 media segment 檔來說，是可以忽略的地步。 它們可以被事先產生好，也可以動態產生。 實務上，要讓它再更精簡一點的話，就是透過 HTTP Compression 即可。 對於儲存空間與網路流量來說，這兩個玩意兒不是問題。
fMP4 與 TS (or MPEG-2 TS, more formal name) 則是決定了 streaming file format 的重點。 TS 有其優秀而重要的貢獻，但在 adaptive streaming 的時代來看，就顯得過時了。 它的 188-byte packet 限制以及 4~12 bytes 的 header 設計， 使得每一個 media segment 的 overhead (浪費掉的空間) 明顯比 fMP4 來得多。 雖然說有各家的 TS optimizer 可以套用，不過就是整個很費工。 另一個影響 media segment 大小的，就是 codec 了。 但這個不在這一篇的討論範籌裏頭。
Web standards 一直是推進這個 Internet Era 的重要推手， 在 video streaming 這一塊也是一樣。 因為 Common Encryption (CENC) 的提出，各大家 DRM solution providers 也就更容易整合了。 雖然各家 DRM solution protocols 不同，但是加密的方式確是可以統一下來。 很遺憾的是，HLS (或更精準的說，是 Apple FairPlay）讓世界變得稍為麻煩了點。 它支援的 AES-128 或是 Sample-AES，都與其它 DRM solutions 都不一樣，無法納入 CENC。 雖然每一家都是採用 AES，但 HLS/FairPlay 只支援 CBC mode，而其它則是支援 CTR mode！ 因為 CBC 與 CTR 是兩個完全不相信的 mode，加密出來的檔案（或數位流）也不一樣。 換句話說，因為這個不同，CMAF 的一個檔通吃的美夢還無法完成！
影音串流的格式一統革命尚未成功，產業還需努力…
CMAF: (by CMAF: What It Is and Why It May Change Your OTT Future
- It is an ISOBMFF, fMP4 container, specifically ISO/IEC 14496-12:201. Transport Streams have served the purpose of the broadcast and cable industries well in delivering continuous streams of data, but they are ill-suited to segmented media delivery and switching, incurring higher overhead/payload ratios than fmp4. fmp4 is extensible for future additions, lightweight, already used by DASH, Smooth and HDS and is an ISO standard with a robust toolset around it for encoding, manipulation, debugging and analysis.
- Common Encryption (CENC) - ISO/IEC 23001-7: 2016 - a standard means of encrypting media content payload using AES-128bit encryption and then supplying header information so that multiple concurrent DRM systems can be used to decrypt the content. This prevents separate silos of content being needed to support the myriad of DRM solutions available today which, unfortunately, are not converging at the same rate as the file containers.
- Will support the MPEG codec suite of AVC (ISO/IEC 14496-10), AAC (ISO/IEC 14496-3) and HEVC (ISO/IEC 23008-2) codecs in a baseline interoperability but allow other codecs (such as VP9 or multichannel audio) to be signaled.
- Currently allows two types of captioning/subtitling formats - WebVTT and IMSC-1.
- Segments must begin with keyframes and there must be precise segment alignment across bitrates. This simplifies switching between bitrates for players.
- Requires independent (non-muxed) audio and video segments.
- A low latency mode is offered, which should further help reduce OTT live stream latencies below the thresholds for terrestrial and satellite broadcast distribution.
- Is designed to be referenced by both a HLS playlist (.m3u8) and a DASH manifest (.mpd).
References:
