※ 本文為 Append 轉寄自 ptt.cc 更新時間: 2014-01-05 07:45:38
看板 Live
作者 標題 [心得] FMLE低流量低畫質實況設定
時間 Sun Jan 5 07:43:11 2014
前言
Adobe Flash Media Live Encoder (FMLE)，作為一套老字號的串流直播軟體，
雖然有著高系統資源消耗的缺點，仍然在實況直播的社群中保持著相當的市佔率─特
別是停留在WindowsXP的使用者和Mac的使用者，對他們來說沒有選擇OBS和FFSplit的
機會。(XSplit那個明明就用別人家的x264還要收錢的東西，雖然市佔率高到爆炸，
但是我實在不想放在這裡比較...)
雖然有著高系統資源消耗的缺點，仍然在實況直播的社群中保持著相當的市佔率─特
別是停留在WindowsXP的使用者和Mac的使用者，對他們來說沒有選擇OBS和FFSplit的
機會。(XSplit那個明明就用別人家的x264還要收錢的東西，雖然市佔率高到爆炸，
但是我實在不想放在這裡比較...)
2013年12月中的影片系統更新之後，聽到不少朋友反應說FMLE沒辦法用啦、一直
斷線啦、畫面都馬賽克啦，之類的狀況。因為覺得這跟用哪個軟體應該沒有關係，所
以決定裝上FMLE來實際測試一次。(雖然我猜大概有不少人仍然在繼續用FMLE而且沒
感受到任何問題。...至於為什麼必須要用FMLE，當然是因為沒有Win7可以裝。...)
斷線啦、畫面都馬賽克啦，之類的狀況。因為覺得這跟用哪個軟體應該沒有關係，所
以決定裝上FMLE來實際測試一次。(雖然我猜大概有不少人仍然在繼續用FMLE而且沒
感受到任何問題。...至於為什麼必須要用FMLE，當然是因為沒有Win7可以裝。...)
這篇文章會分成兩個部分。前半部描述FMLE要怎麼樣調整設定值來進行低畫質實
況，後半部描述進行低畫質實況的理由、和一些安排畫面的考量方式。
研究動機
某實況主表示十二月底開始就沒辦法用FMLE開台給友人PK丸(pk152)看。
研究目標
能夠讓PK丸看到的影像順暢播放。(PK丸的下傳流量最大值約600kbps)
實作方法與結果
假定要讓下傳600k的PK丸能夠順暢播放，那目標應該是把傳輸量控制在80%以下
──因為他很可能還是會一邊開個其他網頁或是丟訊息，所以目標設定在480k附近。
因此採用以下三種情況，並附上實測影片片段。
──因為他很可能還是會一邊開個其他網頁或是丟訊息，所以目標設定在480k附近。
因此採用以下三種情況，並附上實測影片片段。
(以下的xxx+64kbps的xxx是影像的頻寬，64kbps是聲音的頻寬)
(1) 240p低畫質: http://twitch.tv/append/c/3494901
Append - FME設定測試 320x240@30fps 414kbps - Twitch
![[圖]]()
Adobe Flash Media Live Encoder 3.2
Video(影像): 320x240@30fps, 350kbps H264, Profile:Main, Level:2.0, KeyFrame:2sec
Audio(聲音): MP3, Mono, 44100Hz, 64kbps ...
![[圖]](http://static-cdn.jtvnw.net/jtv.thumbs/archive-492437823-630x473.jpg)
(2) 360p中低畫質: http://twitch.tv/append/c/3494922
Append - FME設定測試 480x360@20fps 464kbps - Twitch
![[圖]]()
Adobe Flash Media Live Encoder 3.2
Video(影像): 480x360@20fps, 400kbps H264, Profile:Main, Level:2.1, KeyFrame:2sec
Audio(聲音): MP3, Mono, 44100Hz, 64kbps ...
![[圖]](http://static-cdn.jtvnw.net/jtv.thumbs/archive-492651370-630x473.jpg)
(3) 360p中低畫質寬螢幕: http://twitch.tv/append/c/3494941
Append - FME設定測試 640x360@20fps 464kbps - Twitch
![[圖]]()
Adobe Flash Media Live Encoder 3.2
Video(影像): 640x360@15fps, 400kbps H264, Profile:Main, Level:2.2, KeyFrame:2sec
Audio(聲音): MP3, Mono, 44100Hz, 64kbps ...
![[圖]](http://static-cdn.jtvnw.net/jtv.thumbs/archive-492655098-630x473.jpg)
軟體除了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來說，需要更動的部分其實非常少。
鍵影格間格，聲音只要求44100Hz，AAC或MP3，設定上限─但是壓低流量的情況下顯
然會自動滿足。對於先天滿足CBR的FMLE來說，需要更動的部分其實非常少。
如果仔細看會發現我在放大解析度的同時把FPS降低了。這讓畫面不那麼流暢，
不過這是為了在盡可能的節省頻寬的情形下維持影片的可讀性。特別是寬螢幕的情況
下，為了讓影像從480拓寬到640，只好讓FPS照比例縮小到3/4，從20fps變成15fps。
然而，人眼只要FPS超過10-12左右，就會認為影像是連貫的[1]，所以我相信15fps雖
不過這是為了在盡可能的節省頻寬的情形下維持影片的可讀性。特別是寬螢幕的情況
下，為了讓影像從480拓寬到640，只好讓FPS照比例縮小到3/4，從20fps變成15fps。
然而，人眼只要FPS超過10-12左右，就會認為影像是連貫的[1]，所以我相信15fps雖
然對注重畫質的人來說雖然差強人意，但是這個妥協點應該會被大多數人接受。
上面列出了三組不同解析度的設定值，然而影像解析度在不同狀況的時候應該要
開多高呢？在這點上我多描述一些我對於實況串流的想法。我覺得一個實況主有義務
要適當的安排自己的畫面，計算清楚自己的畫面要用多大的解析度，還有觀眾在觀看
的時候會佔多大的版面。上面這三點可以分開來討論：
開多高呢？在這點上我多描述一些我對於實況串流的想法。我覺得一個實況主有義務
要適當的安排自己的畫面，計算清楚自己的畫面要用多大的解析度，還有觀眾在觀看
的時候會佔多大的版面。上面這三點可以分開來討論：
(1) 播放什麼畫面or玩什麼樣的遊戲：
舉例來說，玩紅白機馬利歐或洛克人，卻開1080p或是720p實況的，實在令人難
以忍受──紅白機的原生解析度是256x240，開到360p以上根本就是放大畫面來增加
傳輸的困難；放大畫面應該交給對方的瀏覽器來辦到，來節省傳輸所需的資料量。但
是如果玩的遊戲是LoL，原生解析度1080p，畫面中又充滿了文字，那720p很可能就是
必須的，或是壓到480p的同時利用Lanczos壓縮的特性來強調文字的邊緣，讓文字稍
微清晰一些。
以忍受──紅白機的原生解析度是256x240，開到360p以上根本就是放大畫面來增加
傳輸的困難；放大畫面應該交給對方的瀏覽器來辦到，來節省傳輸所需的資料量。但
是如果玩的遊戲是LoL，原生解析度1080p，畫面中又充滿了文字，那720p很可能就是
必須的，或是壓到480p的同時利用Lanczos壓縮的特性來強調文字的邊緣，讓文字稍
微清晰一些。
(2) 畫面上除了遊戲以外，有那些東西必須要清楚的放出來：
這邊講的其實主要是"文字"。現在有很多實況主會喜歡把聊天室放到畫面上，
例如：http://i.imgur.com/uBlIJDM.png (聊天室+點歌系統)
![[圖]](http://i.imgur.com/uBlIJDMh.png)
輸出之後文字在畫面上佔多少像素才能夠清楚的看到，用無襯線的粗體比較不怕
糊，這些都應該事先計畫好。然而，官方預設的聊天室常常無法滿足這些需求，因此
上面例子中的聊天室使用的是"IRCBalloonJ"，是個為了TTV/JTV聊天室而設計的IRC
軟體。現在網路上能夠找到的IRC軟體很多，例如繁體中文區常見的IRCBalloon、擁
糊，這些都應該事先計畫好。然而，官方預設的聊天室常常無法滿足這些需求，因此
上面例子中的聊天室使用的是"IRCBalloonJ"，是個為了TTV/JTV聊天室而設計的IRC
軟體。現在網路上能夠找到的IRC軟體很多，例如繁體中文區常見的IRCBalloon、擁
有大量腳本的mIRC、能夠搭配NicoLime形成彈幕的LimeChat、還有我現在較常使用簡
單乾淨的JTChat，都能夠配置成不錯的版面。例子中還有正上方的一行當前歌曲播放
名稱，那其實是NightBot的點歌系統，然後用OBS內建文字擷取來放在畫面上的。
單乾淨的JTChat，都能夠配置成不錯的版面。例子中還有正上方的一行當前歌曲播放
名稱，那其實是NightBot的點歌系統，然後用OBS內建文字擷取來放在畫面上的。
另外，由於最近Twitch加長了延遲時間，有一些Twitch實況主開始嘗試移動到
Hitbox上進行實況；由於Hitbox的聊天室目前並不是使用IRC協定，所以是沒有辦法
用這些IRC聊天室軟體來安排在畫面上的。雖然OBS使用者很可能可以透過CLR瀏覽器
+CSS修正來做出類似的效果，但是Hitbox官方表示聊天室正在大幅修改，所以我目
前暫時沒有仔細研究的打算。
Hitbox上進行實況；由於Hitbox的聊天室目前並不是使用IRC協定，所以是沒有辦法
用這些IRC聊天室軟體來安排在畫面上的。雖然OBS使用者很可能可以透過CLR瀏覽器
+CSS修正來做出類似的效果，但是Hitbox官方表示聊天室正在大幅修改，所以我目
前暫時沒有仔細研究的打算。
(3) 要給那些人看這個畫面：
這牽涉兩個層次。第一個是如同本文一開始舉的例子：我想讓友人PK丸看實況，
他的下傳最高只有600kbps，所以我控制在80%，也就是480kbps附近。雖然光纖寬頻
已經算是常見的，但是仍然有不少使用者沒有很好的網路─特別是那些跟邪惡P2P使
用者住在同一個屋簷下的勇者們。頻寬控制的越低，能夠無壓力的觀看的人就越多。
他的下傳最高只有600kbps，所以我控制在80%，也就是480kbps附近。雖然光纖寬頻
已經算是常見的，但是仍然有不少使用者沒有很好的網路─特別是那些跟邪惡P2P使
用者住在同一個屋簷下的勇者們。頻寬控制的越低，能夠無壓力的觀看的人就越多。
第二個是，收看者會用什麼畫面來看實況影片。舉Twitch的例子來說，官方介面
旁邊是有聊天室的；如果你相信你的觀眾平常都會開著聊天室，或你期待你的觀眾參
與聊天，他們勢必不會開著全螢幕的影片。也就是說，1080p的影片根本就不會完整
的被人看到。
與聊天，他們勢必不會開著全螢幕的影片。也就是說，1080p的影片根本就不會完整
的被人看到。
下面舉些常見的例子，來檢查一下實際上大概到底有多少空間可以用。
Twitch官方介面(功能列開啟):可視空間1280x720
http://i.imgur.com/TVDbZMc.jpg
![[圖]](http://i.imgur.com/TVDbZMch.jpg)
Twitch官方介面(功能列關閉):可視空間1470x800
http://i.imgur.com/RYVHE3D.jpg
![[圖]](http://i.imgur.com/RYVHE3Dh.jpg)
GNBOX介面:可視空間1610x870
http://i.imgur.com/g58lJeM.jpg
![[圖]](http://i.imgur.com/g58lJeMh.jpg)
皮克直播介面:可視空間1596x892
http://i.imgur.com/XpU7Hjs.jpg
![[圖]](http://i.imgur.com/XpU7Hjsh.jpg)
從以上數據看起來，假設你的觀眾有很大部分看皮克實況，那設定1600x900就有
意義──這數值非常接近了。但是如果你的觀眾會從官方介面來，超過720p的部分就
很難看到，那樣就只是純粹在浪費大家的頻寬。就算是在玩1080p的遊戲，原尺寸輸
出也沒什麼意思──除非你希望你的觀眾放棄聊天室。
意義──這數值非常接近了。但是如果你的觀眾會從官方介面來，超過720p的部分就
很難看到，那樣就只是純粹在浪費大家的頻寬。就算是在玩1080p的遊戲，原尺寸輸
出也沒什麼意思──除非你希望你的觀眾放棄聊天室。
結語
這篇文章以FMLE和友人PK丸為例，描述了低頻寬低畫質實況的設定方式；根據友
人PK丸表示，三組設定值的播放都相當順暢。同時，這篇文章也討論了一些畫面安排
上的考量方式，希望能夠避免掉一些無謂的頻寬浪費。
人PK丸表示，三組設定值的播放都相當順暢。同時，這篇文章也討論了一些畫面安排
上的考量方式，希望能夠避免掉一些無謂的頻寬浪費。
平常我們常說節約用電、節約用水、節約使用自然資源之累的事情，我覺得在現
在這個時代中，「網路流量」也已經是一種並非私人所有的共用資源；以Twitch為例
，台灣連到Twitch的總流量顯然有所侷限，即使沒有明確的消費或是頻寬限制進行約
束，使用者也應該要能夠掌握、同時控制流量，避免不必要的頻寬浪費。更進一步的
說，實況主如果能在合理的範圍之內降低上傳的頻寬，那觀看這個頻道所需要的門檻
就會降低一些，進而更有機會吸引到原本沒辦法看的觀眾。希望這樣一篇文章能夠對
大家有所幫助。
在這個時代中，「網路流量」也已經是一種並非私人所有的共用資源；以Twitch為例
，台灣連到Twitch的總流量顯然有所侷限，即使沒有明確的消費或是頻寬限制進行約
束，使用者也應該要能夠掌握、同時控制流量，避免不必要的頻寬浪費。更進一步的
說，實況主如果能在合理的範圍之內降低上傳的頻寬，那觀看這個頻道所需要的門檻
就會降低一些，進而更有機會吸引到原本沒辦法看的觀眾。希望這樣一篇文章能夠對
大家有所幫助。
Append. 2014.01.04. 23:43 p.m. UTC(+0)
註：
[1] 出自"Restoration of motion picture film"第24頁。 http://goo.gl/gwEg5X
Restoration of Motion Picture Film - Paul Read, Mark-Paul Meyer - Google Books
This is the first book to bring together the work of a modern motion picture film laboratory together with the specialist techniques for preservation and restoration of archival film.The books data has its origins in a training programme called FILM which was written by members of the Gamma Group wi ...
This is the first book to bring together the work of a modern motion picture film laboratory together with the specialist techniques for preservation and restoration of archival film.The books data has its origins in a training programme called FILM which was written by members of the Gamma Group wi ...
--
███◣ ◢██◣ ◢██◣ █ ◢█ ◣ ◢ ◢██◣ ◣ █
█ ██ █ ██ █ ██ █◢█◤ █◣◢█ █ ██ █◣ █
█ ██ █ ██ █ ██◤ ████ █ ██ ██◣█ @ ptt.cc
███◤ █ ██ █ ██◣ █◥◤█ ████ ████
█◥█◣ █ ██ █ ██ █◥█◣ █ █ █ ██ █◥██ 鴉片(Append)
█ ◥█ ◥██◤ ◥██◤ █ ◥█ █ █ █ ██ █ ◥█twitch.tv/append
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 5.65.151.228
※ 編輯: Append 來自: 5.65.151.228 (01/05 07:43)
--
※ 看板: FW 文章推薦值: 0 目前人氣: 0 累積人氣: 493
作者 Append 的最新發文:
![]()
(1) 如果說X4像是傳統看反應的動作遊戲， X6會更像一個背板遊戲。 他的關卡設計上有很多看起來很惡意的部分， 純靠反應很可能反應不及。 但...就算你什麼都不會，他給你真正的無限接關， 所以只要有 …43F 20推![]()
我真心覺得這純粹是練習量問題。 手速/反應能力這種事情可能不能練， 但是只是要破關的話絕對是可以練的。 這種話題就要來講一下故事。 忘了是小五還是小六的時候拿到了X4， X和Zero我都只打得過序關頭 …56F 23推![]()
## 前言：「公路的詛咒」 RockmanX的最初版卡帶有一個奇妙的防盜機制，(這應該是防盜機制，有許多記載) 「豆砲打到沒有辦法造成傷害而反彈的東西， 玩家就會被拔裝送回序關高速公路。」 如果對這點 …95F 72推![]()
昨天早上看到這標題，很可惜前天真的是太忙了，沒有當場看到。 但既然都被畫召喚陣了，雖然晚了些還是來回一下。 好吧其實我只是想湊個熱鬧，難得有仙劍bug可以講，不回一下對不起自己... 2018年在C洽 …85F 71推![]()
- 前言 ── 什麼是ACE？ - ACE 影片範例精選 - 所以 ACE 到底是怎麼發生的？ ------ MrWint 在這一片 TAS 中， 巧妙的利用 ACE 的手法， 挑戰 Gameboy …34F 28推
點此顯示更多發文記錄
回列表(←)
分享