直擊|Taipei Video Tech #6 如何滿血回歸

Shuen-Huei (Drake) Guan
BlendVision
Published in
21 min readOct 6, 2020
24 小時 video tech meetup 馬拉松,跟著太陽的推進路線,始於奧克蘭,經過台灣,終於西雅圖~ by JP Saibene, Organizer @ MonteVIDEO Tech | CEO @ Qualabs
24 小時 video tech meetup 馬拉松,跟著太陽的推進路線,始於奧克蘭,經過台灣,終於西雅圖~ by JP Saibene, Organizer @ MonteVIDEO Tech | CEO @ Qualabs

序章:源起

故事是這麼開始的…

有天,Sydney Video Tech 的主辦人之一 Jeremy Brown 在一個酒吧與朋友小聚,啤酒一口接一口,漸漸聊開了。話題一個接一個,從產業的發展,公司裏的八卦,到最近流行些什麼,都聊上了。最後,大家很自然的又聊到了 COVID-19 這個本年度最大的話題。然後,突然有個點子被提了出來:

既然整個世界在 2020 稍為停頓了下來,變安靜了,不如,我們來辦個稍為吵鬧一點的活動,讓世界各地一小搓人活絡一下吧。要不,來試試串聯全球各地的 video tech 社群,來個馬拉松接力活動,辦一場全球 24 小時的 video tech meetup 好了!

打屁完了,接著就是下一步了。正值 8 月中上旬,做事俐落的 Jeremy,當下敲定就辦在九月中下旬。接著 Jeremy 立馬上去全球影視串流聖地 video-dev.slack.com ,在上頭開始詢問各地社群主辦人的意願與想法。

從幾位社群主辦人的回饋看來,似乎,可行!

(以上的故事,有點兒模糊。一方面是因為帶著酒精的關係,一方面是因為我並非第一人稱待在酒吧見證了整個過程。所以,多少帶有一點未經考證,有那麼點神祕的色彩。內容雖然不完全正確,但也應該差不多的吧~)

只相隔了數十分鐘,非常熱血的 Tokyo Video Tech 主辦人之一 Takesato-san ,也在第一時間注意到了這個點子。他在與其它 Tokyo Video Tech 的主辦人就此邀約討論過一輪後,很快下了個決定(這一點實在很不像日本人,我以為日本人下決定都要開個二十個會才有辦法往下一步的)。

並且,Takesato-san 還立即丟了個訊息給我:

Takesato: Drake, are you thinking to join Jeremy’s plan? We’re just starting to talk about it just couples of hours, but we want to ride this big wave, don’t we?

Drake: Ha. That’s cool. Quite an interesting proposal. Let me discuss with Neal (and other co-hosts) first.

(two weeks later…)

Drake: Taipei Video Tech is in for this 24hr meetup!

Jeremy 在 video-dev.slack.com 上登高一呼,發出邀請後,一個城市拉著一個城市的主辦人(真的是如此!像 Taipei 就是被 Tokyo 拉著加入這場盛會的),很快的,就湊到了 18~20 個世界各地 video tech 主辦人示意加入了!

The initial schedule of all meetups to compile a 24hr video tech meetup marathon. © Jeremy Brown
The initial schedule of all meetups to compile a 24hr video tech meetup marathon. © Jeremy Brown

最後,串聯了 19 個都市的 24hr video tech meetup。從時區最早 GMT+13 的奧克蘭開始,結著是 GMT+10 的雪梨,然後就是一個大跳躍來到 GMT+9 的東京,然後又回到 GMT+10 的墨爾本,接著是我們 GMT+8 的台北,然後一路下去,穿過中東,來到歐洲,進入美洲,最後由 GMT-7 的西雅圖收尾。只差非洲,就湊齊了人類歷史上(?)第一次五大洲在同一天完成 24hr video tech meetup 馬拉松了!

究竟是哪幾個城市先不顧一切加入的?又是哪些個城市後來加入的?以及又有哪些城市是在最後一刻不好意思拒絕而加入的…?已經無從(我也懶了)考究了。特別是由於 video-dev.slack.com 使用的是免費 slack 帳號,有歷史訊息的上限,之前的討論訊息,還真的無法找到了 😜

The initial talks of all meetups to compile a 24hr video tech meetup marathon. © Jeremy Brown
The initial talks of all meetups to compile a 24hr video tech meetup marathon. © Jeremy Brown

有了大夥串聯主辦的意願,還得確認另一個主角也準備好了才行:分享的主題。

Taipei 這邊,我們還沒有能建置一個「投稿機制」(不過這就是 meetup 的一種常態,我想不少各地的 video tech 也沒有這種機制的吧),於是還是先從我們三個主辦單位的社內問起,再邀稿於其它比較熟的單位的方式進行。

時間也真的也太短了,就差不多只剩下一個月,要邀到稿的機會不容易。但我們的運氣也真的是很好,這個 COVID-19 讓大家沉寂了一陣子,累積了不少東西(也可能是悶太久了),所以很快的,三個主辦單位都有各自貢獻了題目出來了。

另一方面,各地 video tech meetup 的分享主題也陸陸續續出爐。有來自 Brightcove 談 SSAI;Bitmovin 談 Per-Title-Encoding;V-Nova 在推廣剛剛被提名的 LCEVC (MPEG5 Part2);Wowza 談 LL-HLS;…等。能一口氣看到各地 video tech meetup 的主題,非常的過癮。

24hr Video Technology meetups!

既然整個世界在 2020 稍為停頓了下來,變安靜了,不如,我們來辦個稍為吵鬧一點的活動,讓世界各地一小搓人活絡一下吧。

第一章:啟動 TVT#6

去年底的 TVT#5 ,在 AWS Taiwan 辦公室與來自美國的 Netflix 朋友 和 來自日本的 AbemaTV 朋友度過了愉快、收獲滿滿、豪華點心的一晚之後,原本還想應該很快會有下一場。沒料到,才一剛過完年,整個世界就此遭遇了新冠疫情。世界,停下了腳步。

TVT#6 主辦公司代表合照,由左至右:Racing (17LIVE), Neal (KKStream), Drake (KKStream), and Rex (CATCHPLAY+).
TVT#6 主辦公司代表合照,由左至右:Racing (17LIVE), Neal (KKStream), Drake (KKStream), and Rex (CATCHPLAY+).

在回應了 Takesato-san 以及 Jeremy 的邀約後,仔細確認了一下,距離這個大串聯活動,只剩不到一個月的時間做準備與張羅,得加緊腳步了。運氣很好的,再度邀請到了 17LiveRacing Wang 以及 CATCHPLAY+ 的 Rex 合作,再加上老夥伴 NealBrian Lee (小布)Taipei Video Tech #6 的籌劃就此開工~

平日不起眼,只有在感冒時才會使用的口罩,突然間成了全球的搶手貨。幸好,我們在台灣,有國家隊罩著。雖然在台灣的我們也跟著世界的腳步慢了下來,但還可以以一種優雅而安全的步調,慢步平實的走著。距離上一場的 TVT#5 ,將近快九個月了,因為一個熱血的 24hr video tech meetup 的號召,TVT#6 啟動了。

Taipei Video Tech #6 主題圖示, by Brian Lee (小布)
Taipei Video Tech #6 主題圖示, by Brian Lee (小布)

從 TVT#5 開始,Brian 就建議我們可以給每一場 meetup 一個主題,搭配一個專有的圖示/icon。這一期 TVT#6 的主題圖示一樣很因應時事 COVID-19。KKStream 再次攜手 CATCHPLAY+ 與 17LIVE,戴著守護我們健康的口罩,在 9 月 24 日(四),與世界各地的 video tech 合力,成為 24hr video tech meetup 的一份子,舉辦第六屆「Taipei Video Technology 串流產業沙龍」,與大家聚聚!

從 Streaming Meetup 到 Taipei Video Tech #6 一路下來的參與狀況。

從 2018 年的 Streaming Meetup 到 TVT#6,有一些有趣的統計:

  • 六場下來,都是由我擔任活動主持人。
  • 這一次的地主隊 CATCHPLAY+ 除了提供場地,人力,環境安排…等,還熱情邀約了非常多的同事加入。沒記錯的話,大約有快 20 位來自 CATCHPLAY+ 的人吧!
  • 最早的兩場叫 Streaming Meetup,後來在 Neal 與我參加了 Demuxed,然後在網路上遇見了三位 Tokyo Video Tech 主辦人之後,才正式更名為 Taipei Video Tech,簡稱 TVT。
  • 後來才發現,TVT 的第一個 T 既可以指 Taipei,也可以指 Tokyo,所以每次打 TVT 時,都有點懷疑自己是在講哪一個。Tokyo 與 Taipei 之間,似乎有股神祕的緣份吶!
  • 截至目前為止,每一場的場地都不一樣。從最早的 KKStream 辦公室,到 101 上的 Google Taiwan 辦公室,微風南山上的 AWS Taiwan 辦公室,再到 CATCHPLAY+ 的辦公室。
  • 辦在 Google Taiwan 辦公室的 TVT#4 給人的印象很深刻。活動開始前,眾人還可以看著夕陽落入地平線。那時拍了不少照片與縮時攝影~
  • 擔任過主辦/協辦單位的,目前為止計有 KKStream, 17Media / 17LIVE, UmboCV, CATCHPLAY / CATCHPLAY+ 共四家。感謝大家的付出,特別是這是個無給職,與 KPI 無關,還得在工作忙錄中抽空出來開會討論的事。
  • 參與人數上,一直控制在 60~90 之間。不曉得有參加過任何一場的你,會不會因為這樣的人數控制,而覺得空間有稍為舒服一點呢?
  • 報名參加的單位,從最早的 17 個公司行號,到後來最多有 40 家(這一定是 Netflix 講題的關係)。一路累積下來,扣除掉每次都會簽到的主辦單位後,遠傳、LINE TV、iKala 以及 Giloo 是前幾名熱情報名的單位。
  • 特別是遠傳,只差一次,就湊到六場,場場都報名了!你們可能不曉得,每一場要放出各單位的 logo 並且排列出來,是一個非常不容易的任務。
  • 講題分享方面,KKStream 給過六個講題;17LIVE 與 CATCHPLAY+ 各給過兩個;UmboCV 給過一個;還有來自海外的有 日本的 Forecast Communications Inc., Netflix, AbemaTV;然後身為贊助商之一的 Google 也曾熱情給過一場。
  • 非常希望,之後有更多來自不同單位的主題分享。另外,截至目前為止,你最有印象的會是哪些分享主題呢?
前三次 TVT 結束後的問卷調查。在 TVT#5 時,首次填問卷人數超過報名人數的半數了!
TVT#5 問卷回饋。

距離上一場的 TVT#5 ,將近快九個月了,因為一個熱血的 24hr video tech meetup 的號召,TVT#6 啟動了。

接下來,就讓我們一起來回顧一下,TVT#6 當晚,三位講者的主題。

第二章之一:直播訊號的合流

主題一:【PK 系統 — 視訊連線與直播的整合應用】

YC Chang and TH Huang.

17LIVE 一直致力於提供豐富多元的直播內容以滿足不同族群以及年齡層的使用者。這次他們將一對一視訊與多人直播進行結合,讓各路主播在直播競賽中一較高下!就讓我們一窺 17 是如何將緊張刺激的 PK 對戰呈現給所有用戶。

張育銓 YC Chang, 17LIVE 串流科技部門經理
黃子軒 TH Huang, 17LIVE 應用科技部門後端工程師

Lovely 3 PK demos with varieties of scenarios. © 17LIVE

第一場由 17LIVE 開頭。17 帶來的議題很有意思:在有限的時間內,設計出一個可以讓兩位直播主的畫面合起來互動(PK)的功能,然後讓所有用戶與兩位直播主的 PK 直播互動。一開場的三場 PK 示範影片非常的有意思:有 PK 配對;配對動畫;兩位直播主的低延遲互動;直播的特效;用戶的留言;彈幕式訊息;…

Simplified flowchart of one streamer to join another one, get merged, and then deliver to a viewer. © 17LIVE

整個串流的架構與概念約是這樣:首先,每一位直播主會透過伺服器端做一個 PK 請求的申請與配對等待,有點像是進入 lobby server 等候一樣。接著兩位直播主的各自訊號在經過必要的影像處理後(美肌、雜訊排除、…),再將各自訊號打進另一個 server,在 server 上進行兩個直播主訊號的視訊拼貼以及音訊疊合,最後以 RTMP server 的形式,讓用戶去拉訊號來看。

這部分的分享很有意思,特別是在一開始就提到了三種作法,以及三種作法的一些簡要分析與猜想,最後挑選了上述的 “Merge Streams in Server” 以及更細節的一些解說。

如果這個 PK 機制,改做成一個 B2B 高品質服務,提供給日本客戶的話,哪幾個環節會非常的重要呢?以下是我不負責任的猜想:

  1. 怎麼有效的動態配置 ingestion (or injection) server 與 RTMP server (as streaming origin) 會是一個重要的課題,這決定了至關重要的營運成本。
  2. 另一個課題,會是怎麼做好可靠的 HA,讓整個服務的 SLA 來個至少 3 個 9 (99.9%)之類的。特別是日本客戶,對於一個服務的穩定度有非常高的要求與期待。
  3. 為了有更高的穿透性,不論是什麼平台與環境都能無礙串流,那麼捨棄擁有低延遲優勢的 RTMP,改以 HTTP-based 的串流協定,也許是個需要考慮的方向。MPEG CMAF 或是 LL-HLS 或甚至是 LHLS,會是一個方向,但還需要在這些串流協定中,做進一步的鑽研,而不是把它們當作 it would just work as expected 來看待。
Final page for Q&A or hiring?! © 17LIVE

由 17 的 YC 與 TH 兩人帶來了非常有意思的技術分享。最後的收尾我很喜愛。

接下來,大家有任何的問題想提問,想 Q&A 的,請刷這個 QR code~

第二章之二:高規格的 Frame-accurate Catch-up TV

主題二:【日本電視直播技術革命 串流平台不容忽視的 Linear Streaming 技術創新】

Neal Tsai.

KKBOX 集團旗下影音串流技術公司 KKStream 為日本最大有線電視公司,打造 OTT 串流平台,並建構出獨創 Linear Streaming 解決方案,能細分千分之一秒的畫面,從電視直播及時剪輯出 VOD 後立即上架節目,讓用戶輕鬆在各種智慧型裝置上享受絕佳的觀影體驗。

蔡豐旭 Neal, KKStream 串流技術部門經理

Three challenges to deal with for a high-profile Japanese client. © KKStream

Neal 帶來的是 KKStream 在去年中,一個重量級日本客戶在線性頻道串流(linear streaming)所提出的其中三個挑戰。與電視台或是系統台合作時,有非常多獨特,Internet 原生服務的開發商不曾想到過,也未曾遇到過,的一些需求與設計考量。而這也是 B2B 公司所累積的 domain know-how(業內專業知識與技能)。

第一個乍聽之下覺得很不可思議的是,接受來自電視頻道訊號的 IP 位址是不太能更動的,不管是開發期,測試期,或是 pre-production 與 production 環境。在電視台/系統台的環境中,有大量的特規硬體設備,一個扣著一個,有非常固定的橋接方式。你可能很難想像,換一個測試用的訊號接受 IP 位址,可能要兩三個月的工程!

另一個日本客戶最常見的要求(特別是客戶是做 B2C 服務的),就是穩定度與服務品質了。你有聽過 5 個 9 (99.999%) 的 SLA 要求嘛?有被要求過不管你架在雲端上的服務發生了什麼狀況,都要在兩個小時內盡可能救回來,然後搶救過程中,還得每 15 分鐘就通報一次進展的狀況的?還有要想辦法把一些狀況,做到在事先就可以通知客戶的?…很像是在做一個國防專案似的要求~ 😛

最後一點,也是這一次分享的重點:Frame-accurate Catch-up TV (Live2VOD)。要在以幀(frame)為單位的精準度下,做到根據 EPG 或是 metadata 或是 API 的指定,全自動的把帶狀節目分出一個一個 Catch-up TV (類似 VOD 的一種變形)出來,而且還規定要在帶狀節目一結束後的 15 分鐘內完成。

What’s the frame-accurate Live2VOD? And what’s the idea of Trim/Harvest to solve this task. © KKStream

什麼是以幀(frame)為精準度的 Frame-accurate Catch-up TV 呢?又是以什麼樣的設計來解決它的呢?Neal 先以一張上圖做了個概念上的說明。

舉例來說,在某個日劇台裏頭,它每週四的晚間 9 點到 10 點,排播的節目是 MIU404 這一齣。由於這個日劇台有授權提供 Catch-up TV 的功能,於是這個節目一播放完畢後,是可以立即被轉成像 VOD 那樣,提供一個短時間內(像是兩週內)可以隨選隨放的。這個就是 Catch-up TV (or Live2VOD with strict period constraint)的功能。

困難的點就在於,雖然我們說的是「晚間 9 點到 10 點」,但每一段帶狀節目並不會,事實上幾乎完全不會,對齊這個整點時段的。拿上圖例來說,它是 9 點 00 分 01.020 秒開始播放,在 10 點 00 分 03.113 秒時結束。不止沒有對齊整點,而且還是有帶小數點的秒為單位了。Frame-accurate Catch-up TV 這邊指的就是,這個自動剪出 Catch-up TV 的系統,必須要盡可能的一秒不差地,或說是一幀畫面也不差地執行。多一點不行,少一點也不行。

上述的要求,還要再加上 1) 要在節目結束後的 15 分鐘內完成 Catch-up TV 的輸出」;2) 高穩定度(高 SLA);3) 有防呆機制;4) 整個跑在 AWS 上頭;4) 與 AWS Elemental Media Services 整合;N) 以及……(省略),就是整個 Frame-accurate Catch-up TV 的功能需求了。

AWS Elemental MediaConnect, MediaLive, MediaPackage 完整標配後,更重要的是接在後頭的 Harvester 與 Trimmer 的設計好完成 frame-accurate Live2VOD. © KKStream

上圖中,Harvest 與 Trim 是兩隻分工完成整個任務的程式。其中 Harvest 負責把帶狀節目 live streaming 中的 media segment (fragmented mp4 or m2ts) 給”提出來”,然後放進 S3 裏頭。以上一張圖為例,就是把 1~N 這幾個 media segments 給存進 S3,供後續使用。

接著待第 1 至第 N 個都存下來了,且也確認了這個節目有授權可以轉為 catch-up TV 了,從 EPG 或是 metadata 那邊得到精準要切的時間點之後,計算出第 1 個 media segment 以及第 N 個 media segment 要切開來的位置,這部分就屬於 Trim 的工作了。

接著,我們把上述的資訊 1) 第 1 個與第 N 個 media segment 在 S3 上的位置;2) 第 1 個與第 N 個 media segment 要切開來的時間點,交由 AWS Elemental MediaConvert 來執行。於是就會切出如上圖的 1–1, 1–2, N-1, N-2 這幾個比較小的 media segments 來,然後連同中間的那些 media segments 整個拋給 AWS Elemental MediaPackage 來進行打包,加密…打完收工。

Three Patents to optimize streaming bandwidth consumption during COVID-19. Taiwan can help, and KKStream can help. © KKStream

非常喜歡 Neal 最後的收尾。

他先是提到,在 COVID-19 的期間,整個世界的物理活動與人際互動被迫隔離或是緩下來了,有更多的 work-from-home employees,有更大量的視訊會議。再加上無法隨處跑跳的人,也開始看更多的串流影片了。於是,網路頻寬的使用量大增。5G 的時代還沒來,4G 的頻寬使用量倒是愈用愈多了。

在 KKStream,我們先後投入研發了自家的 Per-Title Encoding (PTE) 以及 Perceptual Streaming Engine (PSE),除了研發,也導入產品中,更同時申請了專利。最近,剛剛獲得最新的資訊,PTE 與 PSE 總計在三個國家都拿到了專利,是個非常開心的事。

更重要的是,PTE 或是 PSE 的導入產品,讓我們的客戶的頻寬使用量確時的降低了。頻寬的使用減少了,自然就可以把這些頻寬給有更需要的人去運用。這就好比適宜的使用水資源,節省下來的,自然可以供給更需要的人或是團體去使用。

KKStream can help. Taiwan can help.

第二章之三:工程師成長史

主題三:【串流工程師養成計劃】

Kevin Chen.

CATCHPLAY 於 2007 年成立,是全球性的娛樂媒體公司,致力於提供最新穎、最時尚的整合性娛樂影音服務給消費者和各企業。在這個資訊網路爆炸的世代,網路娛樂已是成為主流宅娛樂,如何在這產業規劃出屬於自己的職涯生活,需要具備何種資訊素質及素養,一起來探索究竟。

陳昶宇 Kevin, CATCHPLAY+ 串流技術開發部門 資深工程師

The simple formula, what I thought, to utilize as a streaming engineer. © CATCHPLAY+

Kevin 帶來的最後一個主題,是在分享他怎麼從對影音串流的想像不同的人,在參加了 TVT#5 後加入了 CATCHPLAY+,在短短加入的十個月內,從完全不知道狀況,到變成一位可靠的 video engineer 的旅程。

他的開場是這樣的:我以為,影音串流嘛,不就是 ffmpeg 之類的嘛?所以大抵就是一行如下的指令,或是之類的,就做到了吧~

ffmpeg -i video.mp4 -c:v libx264 -c:a aac -f dash out.mpd

After the journey of becoming a streaming engineer, those buzzword technologies are what to learn. © CATCHPLAY+.

接著他才發現,好像不是這樣,然後就是一趟十個月的旅程。最後,它整理出了一個心智圖出來,用來記錄下來他經歷過哪些生澀的技術,這些技術彼此之間的關係,以及後續可能還有什麼…

Streaming is such fun, isn’t it? © CATCHPLAY+

因為整個分享實在太熱血了,我一度忘記我是在 TVT 裏頭,反而更像是在聽一位回學校分享工作經歷的學長給學弟妹的課座分享。Kevin 他最後一頁,一樣使用了帶有濃濃電影色彩的梗圖:

Streaming 是不是很好玩?

最終章:串流產業沙龍 — 你我他

先來張帥氣的合照再說吧~
就用這一張幾乎只剩下剪影的照片做為結尾。Let’s PLAY. Let’s Stream!

不用出賣個資,請花 3 分鐘填寫問卷,讓我們把 Taipei Video Tech 辦得更好!期待在 TVT#7 時,再與你相見~

附錄:24hr video tech 影片上線

--

--

Shuen-Huei (Drake) Guan
BlendVision

thinking, planning, coding and inspiring something about human beings, and then tech... https://about.me/drakeguan