目次
1. OTT簡介
2. 影像編碼
3. 影像組成
4. 影像壓縮
5. 影像取樣
6. 影像封裝
7. 影音串流方式
8. HLS 協議簡介
在公視工作了一陣子但好像一直沒有很了解串流影音的細節
不得不說影音串流真的是門大學問
各式各樣的名詞散落各處、又很難一時聯想在一塊
剛好借著機會簡單的調查一下
不知道大家的經驗是如何？在我的生活中蠻常會聽到什麼 OTT 產業興起啊？無損音檔啊？
還有各式產品，例如：Netflix、Spotify、Youtube、MOD、歡樂看、Apple TV 等等的
不過知道歸知道，但我一直沒有懂
到底 OTT 有什麼了不起的？
不就是把影片放在網路上，然後可以觀看而已？
有沒有快被說服了？難道沒有人覺得 MOD 不就是台數比較少、可以看劇的第四台嗎(#
OTT 到底在紅什麼？為什麼大家搶著做？
如果你也是抱持跟過去的我相同的想法，恭喜你來對地方了！
讓我用淺薄的技術知識帶你重新了解 OTT，以及實現他的技術 ～
串流影音簡介
要講串流媒體之前必須帶大家先了解 OTT 這個概念
Over The Top，簡稱OTT
意思就是公司越過運營商，利用 網路 將影音傳送到用戶所持的裝置
不論是個人電腦(PC)、智慧型手機(Smartphone)、平板電腦(Tablet PC)甚至是家用電視
OTT 在我們的生活隨處可見，像是我們常見到的：
- Netflix
- 愛奇藝
- Yahoo TV
- YouTube
- KKTV
- CHOCO TV
都是 OTT 平台喔！
以下補充機上盒的種類與介紹，比較偏題～
機上盒也是 OTT 的一環，使用開放網路串流影音，集成互動電視功能的全功能網際網路電視，他們被稱為 OTT TV (網際網路電視) ，像是：歡樂看、Apple TV
但與他們相似的 MOD 就不是 OTT TV 了！
MOD 是 IPTV，隸屬電信業者底下，透過電信商搭建的專有網路串流影音，保證網速與影像品質
但相較 IPTV，OTT TV 不需搭建自有網路，進入市場的技術門檻以及受到的政府管制低很多
所以無論是新創公司或是既有媒體平台跨足的網路電視服務，都屬於利用網際網路的 OTT TV
詳細了解可以看這篇，有講 OTT TV v.s. IPTV v.s. 第四臺（Cable）
從上文我們就可以做一個總結
喔～原來 OTT 跟第四台最不一樣的，就是影片轉為網路傳輸啊！
但改成網路傳輸又怎麼樣呢？跟以往的影像處理難道不一樣嗎？
讓我們繼續看下去～
轉檔 Transcoding
試著想像一下，若你打開 YouTube 或是 Netflix 播放十分鐘的影片，可能需要下載 1GB 的影片檔案
除了網速不夠會延長下載時間以外，若沒有手機上網吃到飽或是網速低的地區，根本負擔不起看影片的成本
這樣不方便的服務還會普及嗎？
更別提平台商自身的成本更是高得嚇死人
因此轉檔就出現了！
將「原生檔」轉為適合透過網路播放的「播放檔」的規格
這個轉換過程就是所謂的「轉檔」或是「轉碼」(transcode)
當然除了 格式的轉換 之外，還有一個很重要的工作就是 壓縮
降低播放時的所需的頻寬需求及成本以外，也讓使用者不需負擔高成本（流量）觀看影片 ♥(´∀` )人
但影片壓縮並非我們想像的這麼簡單
影片壓縮屬於破壞性的壓縮
什麼叫做「破壞性」呢？
破壞性壓縮並不是我們一般把檔案壓成 zip 檔這麼單純
他會把影像資料中的多餘資訊去除，因此壓縮後的影片檔案無法像文件壓縮一樣透過解壓縮來回復成原始檔
簡單舉個例子，當我把影片壓成 240p，傳送到用戶端解壓縮開始播放時，畫質不會回復到原檔那麼清晰的畫質
話是這麼說，但我怎麼知道要去除哪些資訊咧？
編碼
要 刪除、壓縮 影像資訊其實需要透過 編碼 的協助，而要順利播放影片，播放器 則需要支援相對應的 解碼器
也就是說要播放一段影音需要透過以下流程
基本上影音會拆成 影像 和 音訊 分別處理
但這篇文章主要是淺談影像處理的部分～只會簡單提及音訊
那目前市面上常見的 影像主流編碼 分為兩大類：
- H.26X
H.264、H.265，是蘋果旗下的編碼，被各平台、裝置廣泛使用，蘋果公司是他的最大支持者 - VPX
VP8、VP9，是 Google 旗下的編碼，因此 YouTube 大量的影片都改用 VP8
但好像還是哪裡怪怪的？！
剛剛說編碼器進行的是破壞性的壓縮，但我感覺還是很像一般的文件壓縮呀
編碼器究竟做了什麼？
看來要了解影像壓縮，看來必須從瞭解影像資訊開始 (´・ω・`)
影像的組成
像素與顏色編碼
這幅名畫是 秀拉 的 大碗島的星期天下午
我覺得很適合解釋圖片 XD
我們第一眼看到這幅畫時，他在我們眼前就是一幅完整的圖
但細看才發現，這幅畫是由不同明暗、深淺的 點 組成
而這就是像素的概念
所以通常我們在講圖片大小時，例如：1440 * 970
就是在講這張圖片有多少 點（像素）描述這張圖片
所以放大才會失真，因為根本沒有那麼多像素可以構成這張圖片，只好把像素拉大，就變成我們所熟知的鋸齒狀
所以對電腦來說一張圖片就是以二進位的方式描述圖片的組成，它包含的資訊有：方塊位置、顏色、亮度….等等
至於每一格像素的色彩顏色編碼可以分為兩種：
- RGB
由三原色紅綠藍，一個顏色可以用 8 bit 來表示，深到淺分為 255 – 0
- 黑白：只有黑與白，所以只要 1 bit 代表黑色
- 灰階：灰色由黑與白的深淺表示，最黑到最白有 255 種的選擇，所以要 8 bit
- 全彩：也就是紅綠藍各有 255 種選擇，所以是 3 x 8 bit 等於 24 bit - YUV
和 RGB 不同，為另一種顏色編碼
- Y：明亮度
- U：色度
- V：濃度
較符合我們眼睛的敏感度，且有些格式所需空間比 RGB 還小，因此現在的影片較常使用 YUV
像是最常用的YUV 4:2:0
每 4 個 Y 採樣，對應 2 個 U 採樣或者 2 個 V 採樣，無論如何色度採樣都只有亮度的一半
因此只需佔用8+4+0=12位，相較 RGB 24bit 整整少了一半
影片幀數
了解圖片後，我們就要進階到影像了
大家多少應該還記得，影片是由一張一張連續的圖片所構成
而一張靜止的圖片就被稱為一幀，影片就是由幀所構成
如果我們說這個影片是 30 幀，就代表一秒會跑過 30 張圖片，也就是 30 FPS
FPS 越高動作就流暢，但相對需要的空間就越多
不僅如此，一幀還可以在拆分喔！
一幀的圖像包括兩場：頂場、底場
從上面的圖可以發現，所謂的頂場和底場，其實就是將一個畫面以水平的方向分割
奇數條稱為底場、偶數條稱為頂場，兩個畫面合在一起為一幀
但好好的影像沒事幹嘛拆成兩部分咧？
別急別急～這在後面影像取樣的部分就會講到他的用途了！( ^ω^)
影片解析度
解析度大家應該就比較聽過了，就是我們常在切換的 480p、720p、1080p
套用上面所學到的知識！就是指畫面垂直的像素數量喔！
越多像素可以描述的顏色越多，因此理論上值越高代表畫質越好
影片壓縮
位元速率 Bit Rate
了解影片的組成後，我們就可以推估一下影片原檔的大小了
基本上影片大小就是取決於：影片的解析度、幀率、位元速率（Bit Rate）
舉個例子：
解析度=1920 x 1080
顏色取樣深度=24bit（R、G、B各色8bit）
每秒幀數=30幀
(不含音檔)1920 x 1080 x 24bit x 30 = 1,492,992,000 bit/秒 = 186.624 mb/秒
如果直接觀看原檔，不包含聲音，一秒鐘的畫面就需要下載 186.624 mb？！
難怪影像需要壓縮 Σ(ﾟДﾟ；≡；ﾟдﾟ) 這到底誰看得起？！
這時候就要介紹位元速率了
位元速率顧名思義就是，一秒內可以傳輸多少 Bit，和 FPS 一樣是一種單位
那他影響的其實就是資料的傳輸量
剛剛有講到像素、幀數，他們都有固定占的容量
在幀數不變的情況下，傳輸 Bit 的管子變窄了，便會影響傳輸的像素數量
畫素就會因此下降
因此用越高的 Bit Rate 去壓縮，能放的影像和聲音的資料就越多
所以今天若要達到 480p、720p、1080p，甚至 4K 的畫質
他就需要相對應的 Bit Rate 以免達不到那個畫質對應的品質
根據Bit Rate，我們也就可以概略估算出播出所需的頻寬，其計算公式如下：
例如：
一片 800Kbps 的 3 分鐘影片，加上聲音 100Kbps，總共900Kbps播放一次所需的流量 = 影片大小所需頻寬 = 最大同時觀看人數 * Bit Rate
從上述可以推算出其大小為：
900Kbps x 180秒 / 8 * 1,000 = 20MB
若要支持最多同時有 100 人收看 900Kbps 的影片所需的頻寬為：
100 x 900Kbps = 90Mbps
若以台灣平均每一 Mb 的頻寬 NT$3,000 計算
則每月的頻寬成本為
90Mbps * 3,000 = 27萬
若網站每月有 30,000 個訪客觀看影片，則每次的成本為：
270,000 / 30,000 = NT$9元
既然如此，那有沒有一種可能是我用低的 Bit Rate 節省成本，但還是可以壓出一樣高的畫質呢？
答案是可以的！｡:.ﾟヽ(*´∀`)ﾉﾟ.:｡
這就是 Google Apple 等公司研究新編碼的動力！
以 H.264、H.265 來說
在 Bit Rate 減少 51–74% 的情況下，H.265 編碼視訊的質量是能與 H.264 編碼視訊近似甚至更好的！
影片取樣
還記得破壞性壓縮嗎？
H.265 編碼之所可以做到這麼驚人的效果，無非就是他刪除了人眼無法辨識出差別的資訊
保留高解析度的像素量，但減少需要傳輸的像素
誒….聽起來有點矛盾…..
在講解之前先簡單瞭解一下人類視覺的特性吧！
一般影片取樣會根據 人類視覺系統 HVS 的特點刪除多餘資訊
- 對高頻信息不敏感
- 對高對比度更敏感
- 對亮度信息比色度信息更敏感
- 對運動的信息更敏感
按照上述四個特點會刪除以下資訊：
- 時間上的冗餘資訊（temporal redundancy）
在視訊資料中，相鄰且關連性強的影格 - 空間上的冗餘資訊（spatial redundancy）
在同一張影格之中，相鄰且關連性強的像素 - 統計上的冗餘資訊（statistical redundancy）
統計上的冗餘資訊指的是欲編碼的符號（symbol）的機率分布是不均勻（non-uniform）的 - 感知上的冗餘資訊（perceptual redundancy）
感知上的冗餘資訊是指在人在觀看視訊時，人眼無法察覺的資訊
恩…..聽起來有道理但感覺還是很模糊QQ
沒關係～還記得上面關於影像的基本知識嗎？
我們來舉一些例子！
以像素來舉例的話，我們可以用以下方法刪減資訊量
- 部分編碼
只針對有變化的部分編碼，例如：演講時講者的嘴型 - 合併顏色相近的像素，減少像素量，並使用
YUV 4:2:0的格式描述顏色
由於人眼對亮度信息比色度信息更敏感
因此亮度採樣保持 4 ，讓色度、濃度採樣降至 1/2，以減少空間
形成一個個大小不一的編碼樹區塊
接著以幀數壓縮做舉例
- 將相鄰且關連性強的影格合併
若有一幕畫面是長這樣的：A 關鍵幀B 幀C 幀D 關鍵幀
若只需留下關鍵的影格，就可以減少很多空間了！ - 幀內或幀間預測
相較H.264的 8 種預測模式，H.265共有 33 種，可以想像他是紀錄不同的運鏡的方向，去預測像素的位移
但這個部分我就沒有深入研究了 ( º﹃º )，目前有找到一篇講述H.264的幀間 / 幀內預測 - 以交錯掃描（interlaced scan）進行傳輸
也就是透過頂場、底場交替播出，減少傳輸的像素量，在快速輪換的結果下，人眼就會因視覺暫留而看到完整畫面。
如此一來就減少了空間和感知上的冗餘資訊了～
這樣看來影像轉碼真的沒有我們想得如此簡單，他的流程是這樣的：
基本上怎麼壓縮的就會怎麼被解壓縮
唯一不可逆的是 反量化 ，影像破壞是無法還原的
影像封裝
上述講的編碼我好像懂了
但日常生活中好像都沒有看過這些名詞，難道編碼不是格式嗎？
在先前我們有講到影片其實會分為影像和聲音分開處理
其實封裝就是將聲音與影像編碼丟到一個容器中的過程
封裝格式種類很多，例如MP4，MKV，RMVB，TS，FLV，AVI等等，也就是那些我們熟知的影片副檔名！
為什麼轉好檔要把影片封裝，無非是因為以下幾點：
- 讓聲音與影像內容同步，將已經壓縮編碼的影片資料和音頻資料按照一定的格式放到一起
- 提供索引內容，讓用戶可以決定想要看或聽什麼地方
- 紀錄編碼資訊，讓播放器用相對應的解碼器解碼
要特別注意的是，容器最大的目的就是將影片資料和音頻資料按照一定的格式放到一起
因此編碼是可以混搭的，只要在表頭戴上編碼格式即可
把我們之前提到的影像編碼搭配上音訊編碼，組合起來就是我們常聽到的格式，像是：
- MPEG 4 MPEG-4 Part 14（.mp4 / .m4a）
除了聲音與影像外，還可以儲放字幕，由於它也有支持串流的播放，所以也可以在網路上支援流傳輸
它可以支援的編碼如下：
- 影像編碼：H.26X、MPEG4 Part 2、VP9 (VP8 不確定有沒有)
- 聲音編碼：AAC、MPEG-4 Part3 (包含 MP3) - WebM（.webm）
WebM 它是由 Google 支援的影像檔容器，它裡面使用的封裝格式為 Matroska，開發出來主要是給 HTML5 使用的， Youtube 也都支持這種格式
它可以支援的編碼如下：
- 影像編碼：VP8、VP9
- 聲音編碼：Vorbis、Opus - Ogg（.ogg）
屬於流媒體，可支持串流播放，為開源項目沒有軟體專利的限制 (MPEG4 則有此限制)。
它可以支援的編碼如下：
- 影像編碼：Theora、Daala
- 聲音編碼：Vorbis、Opus、Flac、PCM - Ts MPEG-2 Transport Stream（.ts）
HLS 協議中專門的使用它，這也在之後會詳細的說明
它可以支援的編碼如下：
- 影像編碼：H264、MPEG4 part 2
- 聲音編碼：MP3、AAC
所以真正的流程應該是長這樣！
（編碼的預測、變換、量化、熵編碼就先以編碼代稱）
我們又搜集了一塊碎片，有種離真相越來越近的感覺(*´∀`)~♥
但這時突然又聽到了新的名詞
HLS（HTTP Media Live Streaming）
哪泥？！這篇文居然還沒結束？
HLS 其實是一種通訊協議
那什麼究竟什麼是協議呢？(;ﾟдﾟ)
Video Streaming 通訊協議
在了解 HLS 之前先來了解什麼是協議吧 (`・ω・´)
協議顧名思義，就是協議就是：要完成特定事情時，所約定好的處理流程
所以通訊協議就是為了「通訊」而訂定的處理流程
影音串流演化史
影音是慢慢進化而來，一開始我們所熟悉的自適性串流（Adaptive HTTP）是不存在的
每一種串流都有它自身的特色和實作、處理的方式
讓我來一一介紹他們吧～
Streaming Progressive Download
最原始的影像播放方式，他播放影音的方式是：
在 Server 上放一段影片，然後將網頁播放器指向影片URL，當用戶點擊播放，播放器立即開始下載文件
一旦有足夠的數據，播放器就會開始播放影片，但是它會繼續下載，直到它收到整個文件（因此是漸進式）
因此他帶來的問題是：
- 無法跳轉片段（需等前面載完）
- 吃網路速度，只適合短片
- 容易造成浪費
一個考慮觀看十分鐘影片的用戶，他們可能只看了一分鐘就離開了頁面，但此時已經下載了其他9分鐘。
此時平台商付費轉移的數據是用戶實際觀看的數據的九倍之多 - 無法實現直播
RTSP/RTMP Streaming
因應 Progressive Download 的問題，此時出現了 RTSP/RTMP 影音串流協定，他強調即時性、低延遲
其中 RTSP 是透過 Flash 播放影片，加入分段切割影片的概念，只需載入目前切割的片段，不須等影片載完可跳點觀看，且多了畫質的選擇
但他帶來的問題在於：
- Server 和 CDN 並未廣泛支持 RTSP
大多數平台商不希望維護昂貴的專用服務器來傳輸 - 他走的埠號通常會被企業防火牆阻止
- Flash 漸漸被淘汰
Adaptive HTTP Streaming
延續 RTSP/RTMP Streaming 的畫面，透過程式將即時影音資料切割、壓縮後，再由網路分段傳送資料到用戶端 (Client)
並利用緩衝記憶體 (Buffer) 的概念，資料不須儲存可直接從 Buffer 讀取播放後丟棄
如此一來，用戶就可以一邊下載、一邊觀看，而不必先將所有資料，都下載到硬碟上，再開啟應用軟體觀看
但缺點就是有延遲，不適合做直撥、視訊…等等
HLS
了解上述串流方式的演進，就可以進一步了解自適性串流中的 HLS 協議了！
HLS 是一基於 HTTP(S) 的 串流媒體協議，為 Apple 所開發，是目前最受歡迎的技術
他分為兩種 session：隨選視訊、直播（這邊主要談的是隨選視訊的部分），共有以下幾種特點：
- 支援影像編碼為 H.264，支援的聲音編碼為 AAC、MP3，並且使用 .ts 流容器
- 接收方可以根據網路狀況自動調整不同解析度
- 支援加密
- 同個影音內容不同的播放條件
例如：依國家切換字幕、依流量切換解析度 - 基於HTTP，可以有良好的Cache機制，可節省花費
- 會延遲 QQ
當然不止 Apple ，Microsoft、MPEG 聯盟和 Adobe 都提供了相對應的自適性串流工具
為什麼要基於 HTTP 上開發呢？
我們所熟知的 HTTP 本身是不提供串流媒體功能的，所以需採用不同的協議傳輸，像是早期的 RTSP 串流
但也就會產生許多問題，像是：埠號被擋、依賴已經凋亡的 Flash 播放器
若能透過 HTTP 來進行串流媒體傳輸就能解決以下問題：
- 不需要專門的協議，可穿越大部分的 router／NAT／Firewal
如此一來就沒有 RTMP 所遇到的問題了～ - Server／Client 實作容易
支援 HTTP request/response 的 server 即可
因此蘋果就基於 HTTP 協議來開發出另一個應用層的協議 HLS，彌補 HTTP 的不足
讓開發者透過 HLS 規定好的方式，就可以使用 HTTP 來進行串流媒體傳輸
由於 HLS 技術的核心是使用 HTTP(S) 傳輸，但 HTTP(S) 有容量限制，因此還需進行檔案分割
使用 MPEG-2 編碼壓縮後，他會將影像分割成多個小檔案
再將聲音訊息、編碼訊息包裝成副檔名為 .ts 的檔案
並按照影片順序，產生一個 索引檔 (M3U8) 記錄這些小檔案的順序與位址，作為播放列表
為了因應畫質轉換的服務，在影片轉檔時會將影片轉成不同的畫質，分別切成不同的 .ts 檔
因此 M3U8 會產生兩層，第一層是指向畫質，第二層會指向影片播放的順序
當客戶端 (Client) 透過播放器（URL）取得 M3U8 檔後，便能依目前的影片觀看進度對其中的 ts 檔發送 request 開始觀看影片
來舉個例子吧～
首先進入影音頁，按下播放鍵立即暫停，來看看我們拿到的哪些資訊
上面可以看到我們拿到了兩個 m3u8 檔
點開第一個 m3u8
裡面的內容是解析度，因此可以得知這是第一層 m3u8
其中 Bandwidth 是指平均在多少流量時播放某解析度
他可以放很多不同的條件，像是我們上面所講到的：不同的國家有不同的字幕等
接著我們點選第二個 m3u8 檔
點開發現內容包含很多一行行的網址
因此可以得知這是第二層的 m3u8
其中，一直不斷出現的#EXTINF:10 為此片段的時間長度，也就是 10 秒！
下面則是影片檔的位置
從 URL 可以發現我們抓的解析度是 480
所以他應該是 第一層 m3u8 指向的 480p 的 m3u8
現在我們切換畫質看看~
點開最新的 m3u8 發現畫質成功切換成 1080p
從抓取的檔案也可以發現
0.ts 是 480p
切換畫質後，1080p 是接著 1.ts 開始
不須像早期的 Streaming Progressive Download 需要再請求一次 0.ts，將完整片段都重新下載
透過實例的講解是不是更了解 HLS 了呢 ( • ̀ω•́ )
以上就是整個影音串流從無到有的過程
這篇文前期搜集資料到整理真的花了許多時間
影音串流不只是協議的步驟，他還牽涉到整個影片的處理，壓縮、取樣、封裝等等，更需要基本的影像知識
希望可以透過這篇的整理讓大家更了解影音串流
影音雖然繁雜，但卻是很有魅力的存在呢！
拍個手讓我知道，這個文章對你們有幫助 ♥(´∀` )人
可以拍五次喔！快來瘋狂擊掌！
