2017.09，在那個平均氣溫 27~32 的盛夏台北，KKStream 辦公室有幾位來自 CNEX 的貴賓。
短短不到的兩個小時，立即的達成了共識：
雙方團隊在一週內，以最有效益的方式，在最小的範圍上，協力合作讓 CNEX × Giloo 紀實影音線上影展 上線。
因著這麼的一個合作會議，在這之後，我們有了個機會認識 Giloo 這個新興服務，
同時以接近第一人稱的角度看著它上線，一路到今天~
Giloo的命名，來自於閩南語「紀錄」的發音。
Giloo 的創立初衷是打造專屬於紀實影像的社群平台。
我們相信紀實影像與說故事的力量，如何從生產、觀看、流通與傳播等各個面向加大力道，
是 Giloo 所有企劃與產品的核心提問。
整個合作的需求與契機，緣由非常簡單：內容保護。
就如同 Paul Graham 的 Hackers & Painters: Big Ideas from the Computer Age 裏頭說的，
「這是個對科技阿宅最棒的年代，只要夠 nerdy，夠有想法，夠有生意頭腦，那就去創業吧。」
今年五月，KKV (KKStream & KKTV) 內部執行了一個 KKV Data Game 17.05。
隨後的六月，毅然決定對外開放，搭上 PyCon Taiwan 2017 的順風車，辦了個 KKBOX Data Game 17.06。
主辦人之一的 @ironhead 寫了篇 blog：Stories of KKBOX Data Game 17.06。
而這一篇，打算以另一個觀點來聊聊這個 game 到底是怎麼樣的一個 game~
如果，我們把整個 KKBOX Data Game 17.06 當作一家 startup，會是怎麼樣的一回事？
趨使一件計劃之外的事，產生點意外的火花，最快的方法之一，就是辦一個活動了。
當全世界（好吧，其實只有一小群人）都開始瘋狂談論 AI, Machine Learning 時，
而你發現你們家的基礎建設還很不足，
有很多 data pipeline, data engineering 的事沒做好，
根本無暇去想那個什麼 AI (stuff or buzzwords）之類的…
又或者，雖然你們做了一些 data analytics，
也開發了些所謂的 recommendation system，
但認真想想，其實都還離完全的商業目標有那麼一段距離…
KKStream / KKTV / KKV 很不巧的，剛好也在經歷上述的狀況。
雖然我們有老大哥 KKBOX 可以咨詢，但基本功還是得自己一步一步來。
最最基本也重要的任務：1）組織資料團隊；2）建立資料認知；3）執行資料工程。
都無法假它人之手。
我們在（永遠都會）人仰馬翻的日常業務裏頭，啟動了一個小活動。
人：所有 KKV 集團（KKStream + KKTV 2.0）的同事。
事：根據拿到的，過去一段時間 KKTV 用戶的看劇行為與資料，預測（猜）用戶接下來會看的劇。
時：05/04 - 05/11，僅僅一週。
地：透過 Kaggle in Class 來舉辦整個比賽。
物：使用 KKTV 的真實資料。
今年三月，急就章的去了一趟 Google Cloud Next ‘17，
重新體驗了一下 Cloud Vision API，
順道玩玩別人拿它來做的小實驗。
這個在現場的 Vison API demo booth，
最多可以同時看到連續的三組被拍攝並上傳的照片與分析。
中間那組是我與我的同事 R 大 。
右邊那組是我的兩位同事 G 大 以及 iR 大 （i 大不能亂用…）。
右邊那組同事笑得可開心著的了~
所有的影音串流服務的營運單位都曉得，
日常的營運費用（OPEX）支出裏頭，
前三大的是支出分別是：
內容版權費是大老闆與首席內容官（Chief Content Officer）的事；
人事成本是營運長（Chief Operation Officer）與研發主管的事；
至於流量費嘛（以及與它高度相關的儲存空間費用），
我們都曉得這是影音服務有別於其它網路業的最大支出。
流量費也是這一篇 blog 或這個 CMAF 標準在關心的議題。
從多媒體技術的觀點來看的話，現在的影音串流服務是怎麼做到的呢？
以我微薄的知識與見聞來看，目前成熟的技術市場，大概是有以下的幾塊：
以一家有點規模，
平台有至少包含 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）來符合當下的軟硬體需求。
You're looking at Drake's words or statements. All opinions are my own.