[心得] FMLE低流量低畫質實況設定
前言
Adobe Flash Media Live Encoder (FMLE)，作為一套老字號的串流直播軟體，
雖然有著高系統資源消耗的缺點，仍然在實況直播的社群中保持著相當的市佔率─特
別是停留在WindowsXP的使用者和Mac的使用者，對他們來說沒有選擇OBS和FFSplit的
機會。(XSplit那個明明就用別人家的x264還要收錢的東西，雖然市佔率高到爆炸，
但是我實在不想放在這裡比較...)
2013年12月中的影片系統更新之後，聽到不少朋友反應說FMLE沒辦法用啦、一直
斷線啦、畫面都馬賽克啦，之類的狀況。因為覺得這跟用哪個軟體應該沒有關係，所
以決定裝上FMLE來實際測試一次。(雖然我猜大概有不少人仍然在繼續用FMLE而且沒
感受到任何問題。...至於為什麼必須要用FMLE，當然是因為沒有Win7可以裝。...)
這篇文章會分成兩個部分。前半部描述FMLE要怎麼樣調整設定值來進行低畫質實
況，後半部描述進行低畫質實況的理由、和一些安排畫面的考量方式。
研究動機
某實況主表示十二月底開始就沒辦法用FMLE開台給友人PK丸(pk152)看。
研究目標
能夠讓PK丸看到的影像順暢播放。(PK丸的下傳流量最大值約600kbps)
實作方法與結果
假定要讓下傳600k的PK丸能夠順暢播放，那目標應該是把傳輸量控制在80%以下
──因為他很可能還是會一邊開個其他網頁或是丟訊息，所以目標設定在480k附近。
因此採用以下三種情況，並附上實測影片片段。
(以下的xxx+64kbps的xxx是影像的頻寬，64kbps是聲音的頻寬)
(1) 240p低畫質: http://twitch.tv/append/c/3494901
320x240@30fps 350+64kbps H264 Profile:Main Level:2.0 KeyFrame:2sec
(2) 360p中低畫質: http://twitch.tv/append/c/3494922
480x360@20fps 400+64kbps H264 Profile:Main Level:2.1 KeyFrame:2sec
(3) 360p中低畫質寬螢幕: http://twitch.tv/append/c/3494941
640x360@15fps 400+64kbps H264 Profile:Main Level:2.2 KeyFrame:2sec
軟體除了FMLE 3.2進行編碼以外，畫面擷取是用SCFH DSF 0.4.1。
H264的Profile固定為Main，Level盡可能選擇最小值(反正太低FMLE會告訴你)，
Keyframe Frequency固定為2 seconds，
聲音的設定固定為MP3/Mono/44100Hz/64kbps。
討論
Twitch對於實況的要求其實很少：影像只要求H264、固定位元率(CBR)和2秒的關
鍵影格間格，聲音只要求44100Hz，AAC或MP3，設定上限─但是壓低流量的情況下顯
然會自動滿足。對於先天滿足CBR的FMLE來說，需要更動的部分其實非常少。
如果仔細看會發現我在放大解析度的同時把FPS降低了。這讓畫面不那麼流暢，
不過這是為了在盡可能的節省頻寬的情形下維持影片的可讀性。特別是寬螢幕的情況
下，為了讓影像從480拓寬到640，只好讓FPS照比例縮小到3/4，從20fps變成15fps。
然而，人眼只要FPS超過10-12左右，就會認為影像是連貫的[1]，所以我相信15fps雖
然對注重畫質的人來說雖然差強人意，但是這個妥協點應該會被大多數人接受。
上面列出了三組不同解析度的設定值，然而影像解析度在不同狀況的時候應該要
開多高呢？在這點上我多描述一些我對於實況串流的想法。我覺得一個實況主有義務
要適當的安排自己的畫面，計算清楚自己的畫面要用多大的解析度，還有觀眾在觀看
的時候會佔多大的版面。上面這三點可以分開來討論：
(1) 播放什麼畫面or玩什麼樣的遊戲：
舉例來說，玩紅白機馬利歐或洛克人，卻開1080p或是720p實況的，實在令人難
以忍受──紅白機的原生解析度是256x240，開到360p以上根本就是放大畫面來增加
傳輸的困難；放大畫面應該交給對方的瀏覽器來辦到，來節省傳輸所需的資料量。但
是如果玩的遊戲是LoL，原生解析度1080p，畫面中又充滿了文字，那720p很可能就是
必須的，或是壓到480p的同時利用Lanczos壓縮的特性來強調文字的邊緣，讓文字稍
微清晰一些。
(2) 畫面上除了遊戲以外，有那些東西必須要清楚的放出來：
這邊講的其實主要是"文字"。現在有很多實況主會喜歡把聊天室放到畫面上，
例如：http://i.imgur.com/uBlIJDM.png
(聊天室+點歌系統)
輸出之後文字在畫面上佔多少像素才能夠清楚的看到，用無襯線的粗體比較不怕
糊，這些都應該事先計畫好。然而，官方預設的聊天室常常無法滿足這些需求，因此
上面例子中的聊天室使用的是"IRCBalloonJ"，是個為了TTV/JTV聊天室而設計的IRC
軟體。現在網路上能夠找到的IRC軟體很多，例如繁體中文區常見的IRCBalloon、擁
有大量腳本的mIRC、能夠搭配NicoLime形成彈幕的LimeChat、還有我現在較常使用簡
單乾淨的JTChat，都能夠配置成不錯的版面。例子中還有正上方的一行當前歌曲播放
名稱，那其實是NightBot的點歌系統，然後用OBS內建文字擷取來放在畫面上的。
另外，由於最近Twitch加長了延遲時間，有一些Twitch實況主開始嘗試移動到
Hitbox上進行實況；由於Hitbox的聊天室目前並不是使用IRC協定，所以是沒有辦法
用這些IRC聊天室軟體來安排在畫面上的。雖然OBS使用者很可能可以透過CLR瀏覽器
+CSS修正來做出類似的效果，但是Hitbox官方表示聊天室正在大幅修改，所以我目
前暫時沒有仔細研究的打算。
(3) 要給那些人看這個畫面：
這牽涉兩個層次。第一個是如同本文一開始舉的例子：我想讓友人PK丸看實況，
他的下傳最高只有600kbps，所以我控制在80%，也就是480kbps附近。雖然光纖寬頻
已經算是常見的，但是仍然有不少使用者沒有很好的網路─特別是那些跟邪惡P2P使
用者住在同一個屋簷下的勇者們。頻寬控制的越低，能夠無壓力的觀看的人就越多。
第二個是，收看者會用什麼畫面來看實況影片。舉Twitch的例子來說，官方介面
旁邊是有聊天室的；如果你相信你的觀眾平常都會開著聊天室，或你期待你的觀眾參
與聊天，他們勢必不會開著全螢幕的影片。也就是說，1080p的影片根本就不會完整
的被人看到。
下面舉些常見的例子，來檢查一下實際上大概到底有多少空間可以用。
Twitch官方介面(功能列開啟):可視空間1280x720
http://i.imgur.com/TVDbZMc.jpg
Twitch官方介面(功能列關閉):可視空間1470x800
http://i.imgur.com/RYVHE3D.jpg
GNBOX介面:可視空間1610x870
http://i.imgur.com/g58lJeM.jpg
皮克直播介面:可視空間1596x892
http://i.imgur.com/XpU7Hjs.jpg
從以上數據看起來，假設你的觀眾有很大部分看皮克實況，那設定1600x900就有
意義──這數值非常接近了。但是如果你的觀眾會從官方介面來，超過720p的部分就
很難看到，那樣就只是純粹在浪費大家的頻寬。就算是在玩1080p的遊戲，原尺寸輸
出也沒什麼意思──除非你希望你的觀眾放棄聊天室。
結語
這篇文章以FMLE和友人PK丸為例，描述了低頻寬低畫質實況的設定方式；根據友
人PK丸表示，三組設定值的播放都相當順暢。同時，這篇文章也討論了一些畫面安排
上的考量方式，希望能夠避免掉一些無謂的頻寬浪費。
平常我們常說節約用電、節約用水、節約使用自然資源之累的事情，我覺得在現
在這個時代中，「網路流量」也已經是一種並非私人所有的共用資源；以Twitch為例
，台灣連到Twitch的總流量顯然有所侷限，即使沒有明確的消費或是頻寬限制進行約
束，使用者也應該要能夠掌握、同時控制流量，避免不必要的頻寬浪費。更進一步的
說，實況主如果能在合理的範圍之內降低上傳的頻寬，那觀看這個頻道所需要的門檻
就會降低一些，進而更有機會吸引到原本沒辦法看的觀眾。希望這樣一篇文章能夠對
大家有所幫助。
Append. 2014.01.04. 23:43 p.m. UTC(+0)
註：
[1] 出自"Restoration of motion picture film"第24頁。 http://goo.gl/gwEg5X
--
███◣ ◢██◣ ◢██◣ █ ◢█ ◣ ◢ ◢██◣ ◣ █
█ ██ █ ██ █ ██ █◢█◤ █◣◢█ █ ██ █◣ █
█ ██ █ ██ █ ██◤ ████ █ ██ ██◣█ @ ptt.cc
███◤ █ ██ █ ██◣ █◥◤█ ████ ████
█◥█◣ █ ██ █ ██ █◥█◣ █ █ █ ██ █◥██ 鴉片(Append)
█ ◥█ ◥██◤ ◥██◤ █ ◥█ █ █ █ ██ █ ◥█twitch.tv/append
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 5.65.151.228
※ 編輯: Append 來自: 5.65.151.228 (01/05 07:43)
推
01/05 19:13, , 1F
01/05 19:13, 1F
→
01/05 20:51, , 2F
01/05 20:51, 2F
推
01/06 04:07, , 3F
01/06 04:07, 3F
推
01/06 04:25, , 4F
01/06 04:25, 4F
推
01/06 10:33, , 5F
01/06 10:33, 5F
推
01/06 11:02, , 6F
01/06 11:02, 6F
推
01/06 13:14, , 7F
01/06 13:14, 7F
根據 http://goo.gl/Jtp5YZ Twitch官方Blog在20131213放出來的消息說
we've increased the latency by multiple seconds
to make sure that we're delivering smooth video.
總之他們為了確保大家可以更順暢的看到那些影片(意思是不會斷一下斷一下)
增加的延遲的時間
然後在 http://goo.gl/y0GYo7 同樣 官方blog 在20131220放出來的消息
他們統計了Dreamhack Winter 2013的轉播數據 認為新系統非常成功
使用者中斷串流進入緩衝區間的次數 跟舊系統相比 少了非常多
這邊的Dreamhack Winter 2013應該是一系列的電競轉播，
因此我覺得Twitch的目標如果是這個社群，他們優先放棄即時性是非常正確的；
但是對於重視互動的小型社群來說，這陣子就會過得非常痛苦。
1220那個時候他們認為那時的延遲大概分布在12-40秒不等，
然後這個延遲是"有可能"下降的─他們聲稱會讓工程師致力於解決這問題；
但是我其實不太相信他們會讓他回到10秒內。
我目前對Twitch/Justin上的社群觀察，大致上可以用四種模型描述：
http://i.imgur.com/8MkevlM.png
(註解一下。一個社群有可能介在某兩個Type之間，而且這個比例會隨時間變化)
然而在這些社群之中，最能夠為Twitch帶來收入，也同時使用最大宗的流量的，
應該是Type1的那些串流。他們需要節目內容的品質，但是不需要即時性。
所以我覺得Twitch把延遲時間加長是很符合他們的需求的，
同時我不太相信Twitch會有興趣把這個平衡拉回來照顧其他Type的社群。
※ 編輯: Append 來自: 5.67.248.183 (01/06 20:20)
推
01/06 20:11, , 8F
01/06 20:11, 8F
推
01/06 20:35, , 9F
01/06 20:35, 9F
推
01/08 01:23, , 10F
01/08 01:23, 10F
→
01/08 11:44, , 11F
01/08 11:44, 11F
推
01/08 23:05, , 12F
01/08 23:05, 12F
Live 近期熱門文章
PTT數位生活區 即時熱門文章
