Drake's Weblog

kkstream

4 minute read

2017.09,在那個平均氣溫 27~32 的盛夏台北,KKStream 辦公室有幾位來自 CNEX 的貴賓。
短短不到的兩個小時,立即的達成了共識:
雙方團隊在一週內,以最有效益的方式,在最小的範圍上,協力合作讓 CNEX × Giloo 紀實影音線上影展 上線。
因著這麼的一個合作會議,在這之後,我們有了個機會認識 Giloo 這個新興服務,
同時以接近第一人稱的角度看著它上線,一路到今天~




Giloo的命名,來自於閩南語「紀錄」的發音。


Giloo 的創立初衷是打造專屬於紀實影像的社群平台。
我們相信紀實影像與說故事的力量,如何從生產、觀看、流通與傳播等各個面向加大力道,
是 Giloo 所有企劃與產品的核心提問。



整個合作的需求與契機,緣由非常簡單:內容保護。

5 minute read

就如同 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,會是怎麼樣的一回事?

3 minute read

趨使一件計劃之外的事,產生點意外的火花,最快的方法之一,就是辦一個活動了。


當全世界(好吧,其實只有一小群人)都開始瘋狂談論 AI, Machine Learning 時,
而你發現你們家的基礎建設還很不足,
有很多 data pipeline, data engineering 的事沒做好,
根本無暇去想那個什麼 AI (stuff or buzzwords)之類的…
又或者,雖然你們做了一些 data analytics,
也開發了些所謂的 recommendation system,
但認真想想,其實都還離完全的商業目標有那麼一段距離…


KKStream / KKTV / KKV 很不巧的,剛好也在經歷上述的狀況。
雖然我們有老大哥 KKBOX 可以咨詢,但基本功還是得自己一步一步來。
最最基本也重要的任務:1)組織資料團隊;2)建立資料認知;3)執行資料工程。
都無法假它人之手。



我們在(永遠都會)人仰馬翻的日常業務裏頭,啟動了一個小活動。


KKV Data Game 17.05




  • 人:所有 KKV 集團(KKStream + KKTV 2.0)的同事。




  • 事:根據拿到的,過去一段時間 KKTV 用戶的看劇行為與資料,預測(猜)用戶接下來會看的劇。




  • 時:05/04 - 05/11,僅僅一週。




  • 地:透過 Kaggle in Class 來舉辦整個比賽。




  • 物:使用 KKTV 的真實資料。



1 minute read

今年三月,急就章的去了一趟 Google Cloud Next ‘17,
重新體驗了一下 Cloud Vision API
順道玩玩別人拿它來做的小實驗。



這個在現場的 Vison API demo booth,
最多可以同時看到連續的三組被拍攝並上傳的照片與分析。
中間那組是我與我的同事 R 大
右邊那組是我的兩位同事 G 大 以及 iR 大 (i 大不能亂用…)。
右邊那組同事笑得可開心著的了~


5 minute read

所有的影音串流服務的營運單位都曉得,
日常的營運費用(OPEX)支出裏頭,
前三大的是支出分別是:



  • 內容版權費

  • 流量費

  • 人事成本


內容版權費是大老闆與首席內容官(Chief Content Officer)的事;
人事成本是營運長(Chief Operation Officer)與研發主管的事;
至於流量費嘛(以及與它高度相關的儲存空間費用),
我們都曉得這是影音服務有別於其它網路業的最大支出。
流量費也是這一篇 blog 或這個 CMAF 標準在關心的議題。



從多媒體技術的觀點來看的話,現在的影音串流服務是怎麼做到的呢?
以我微薄的知識與見聞來看,目前成熟的技術市場,大概是有以下的幾塊:



  1. (Adaptive) streaming protocols: MPEG-DASH, HLS, HDS, MSS, RTMP, …

  2. Container format: MP4, fMP4, TS, MOV, …

  3. Video codec: H.264, HEVC, VP9, …

  4. DRM: PlayReady, Widevine, FairPlay, …

  5. Caption: SRT, WebVtt, …

  6. 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)來符合當下的軟硬體需求。

Recent posts

Categories

About

You're looking at Drake's words or statements. All opinions are my own.