# AWS的訪談-關於公視如何運用AWSMediaConvert

1. 介紹公視目前的營運。強調財團法人。(10秒鐘)

公共電視台是用台灣人民納稅錢所成立的電視台，而是NPO組織，也是台灣唯一的公共電視台，2017建立了VOD影音平台，也是從那個時候起，開始運用AWS相關服務，

2. 在 VOD 服務上為什麼會使用 AWS MediaConvert 呢？

公視VOD影音平台，與台灣國內其他影音平台最大不同之處就在於提供4K影音，所以在轉檔上面臨很多挑戰。過去公視 VOD 是採自行轉檔，4K若包含剪接、轉檔要花費比原影音長度多2到3倍的時間。但遇到需求大的時候，我們的轉檔機器及人力都有限，所以轉檔的時間就會拉長。

另外在處理 4K 影片的時候，自行轉檔的檔案都會太大，造成網頁播放上的問題。

為了改善這些問題，我們工程師就改採用 AWS 的 MediaConvert 服務， MediaConvert 可以同時處理多項影音轉檔，即使是4K的檔案也沒問題，公視就不會因為轉檔的量大就要花更多的時間處理。

另外透過 MediaConvert 轉出的 4K 影片檔案會小很多，經過我們的測試後，畫質上也不會差異太大。

3. 介紹下公視 MediaConvert 的 workflow。

簡單介紹一下我們的工作流程：我們是透過 SFTP 將內容上傳到 AWS 的 S3，因為 SFTP 是比較通用的協定，可以支援的免費軟體又多，而且還有加密，有一定的安全性，所以公視就不需再使用特定的軟體處理 S3 上傳影片的事情。

上傳到S3之後，我們有 2 個路徑，一個是自動轉檔，一個是備份的。當指定的檔案來到自動轉檔的路徑時，就會啟動 AWS 的 Step Functions，在開始的時候，它會觸發 AWS Lambda 去發一個訊息到 Slack Webhook 告訴我們現在有一個檔案現在進入到轉檔流程。
轉檔完成後，也會觸發 Lambda 到 Slack Webhook 通知說檔案已經轉完了。
除此之外，我們還會多做一些動作，會做符合我們平台上的命名規則。所以我們會針對轉完後的檔案去做一些搬移或重新命名，這一部分我們也會透過 Lambda 來完成

我們剛剛有講到自動轉檔的路徑，另一個備分路徑是可以運用到自動剪接。
公視過去為了電視播出的影音檔案多有破口，這些破口就是約10秒鐘左右的黑畫面，若直接轉檔，使用者就會看到這些黑畫面，所以我們都要人工剪輯處理，但當時間比較急迫時，我們也會使用 MediaConvert 處理這樣的事情。
就在我們剛剛提到S3上有2個不同的路徑，這時備份的路徑就是留給類似需要重新剪接的檔案
Lambda 就會根據要剪破口 timecode 資訊來啟動 MediaConvert 去做剪輯動作，最終會得到一個完整無破口的原檔，同時也會指定輸出的位置就是自動轉檔s3的路徑，就可以繼續完成自動轉檔的流程。

以上就是我們運用MediaConvert的一些流程分享。

`自動轉檔`
- 使用者從 SFTP 上傳檔案到 S3 指定自動轉檔的路徑。
- 上傳完成後會觸發 Step Function 進行轉檔。
- 在 **ingest** 階段會透過 Lambda 去通知 Slack 有收到檔案並開始轉檔。
- 在 **process** 階段會觸發 MediaConvert 進行轉檔。
- 在 **pulish** 階段會再一次透過 Lambda 通知檔案轉檔完成。

`剪輯破口`
- 從 Slack 輸入破口的時間傳送給 AWS API Gateway。
- Lambda 收到來自 API Gateway 的資訊後會啟動 MediaConvert。
- 在剪完破口後會把檔案輸出到自動轉檔的 S3 路徑。
- 接下來就會繼續 `自動轉檔` 的流程。

4. 是如何想到上面的架構呢？

是透過 AWS 官網 Video on demand Solution 的推薦架構再去建置的。

5. 直播上公視也有使用 AWS Elemental 的服務，請問有哪些呢？

去年透過本地端的 Encoder 傳送 RTMP 的訊號到自建 Media Server並搭配 CloudFront 。
但在這樣的架構下，同時觀看人數會過多時，會有 Media Server 無法水平擴充處理來自 Cloudfront 的 Miss 請的問題。

後來改成從 Encoder 直接傳送 HLS 的檔案到 MediaStore，在 MediaStore 前面一樣搭配 CloudFront。因為 MediaStore 是 AWS 管理的服務，公視就不用擔心水平擴充的問題，在 1080P 的畫質下可以讓更多使用者觀賞到直播影音。

6. 與惡的片子外流，藉由AWS講到S3的部分。流程自動化。

前一陣子公視自製的一部影片 "我們與惡的距離" 非常火紅，但大家從媒體上也知道有平台尚未上架的影片外流消息，當下公視 VOD 平台在第一時間就查閱了 AWS 提供的 Access Log ，確認並沒有外部存取的紀錄！因此也快速排除了從平台外流的可能。其實這是透過

7. 結尾：

公共電視近來透過影音平台運用部分雲端技術後，更加發現若懂得善用新的科技技術，不但能使現有服務更加穩定，也可以節省更多人力到創新應用的層面，還有避免一些人為因素所造成的失誤。所以我們也正逐步規劃，希望能讓公視VOD影音平台能與電視台的影音資料庫的介接上架流程，能逐步轉向全面自動化。

# 透過 CDN 來增加我與倒站的距離
Apr 29 ,2019
標題很沒梗我知道 哈哈～
但目的是說明公視+在 我們與惡的距離 上映時遇到的狀況，
就忽略這沒梗的標題吧。Let’s Go!

> 我(工程師 Richard)：劇透！就在 API 前面加上 CDN 來減少資源的直接存取。
> 觀眾：咦？！好像就講完了，那就來洗洗睡囉～
> 我(工程師 Richard)：誒先不要，先不要，看一半再關分頁也不遲啊～

**事件回顧**
先把世界線的事件整理一下：
1. 與惡EP5, EP6 更新(2019/04/07)：公視+出現狀況
2. 與惡EP7, EP8 更新(2019/04/14)：公視+再次出現狀況(´Д`)
3. 與惡EP9, EP10 更新(2019/04/21)：終於沒問題惹（撒花

在 EP5,EP6 事件的隔天，公視與開發夥伴立刻開始尋找原因
經過測試與收集資料後訂出了改善方向：
1. 調整服務的參數
2. 可暫時關閉推薦功能以減省資源
3. 全面升級服務基礎建設

> 問：咦？看起來有模有樣啊，那是遇到啥問題？
> 答：就是。。。第三點啊！

項目 1 和 2 很快都被完成，但是項目 3 在短時間內要執行的風險比較大。
最終我們選擇最簡單直接的 CDN Cache！

解決方法