前言 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) 根據 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)