切換
舊版
前往
大廳
主題

OBS 實況報告 (新增縮放濾鏡應用)

TermSelf | 2014-06-28 02:02:35 | 巴幣 1150 | 人氣 41576


最後更新日期:2017/03/02


先感謝FFFAN大的部分補充


我的電腦相關


配備

CPU - Intel Core i5 3570K
GPU - GV-R797OC-3GD
iGPU - Intel® HD Graphics 4000
RAM - 4GB x 4 (雙通道)

軟體
Open Broadcaster Software Studio
Open Broadcaster Software Classic
(皆以 x64 版本為主要測試項目)

編碼方式

1. [CPU]
2. [QSV] Intel Quick Sync Video
3. [NVENC] Nvidia NVENC
4. [VCE] Video Codec Engine
5. [擷取裝置] C985, CV710, HD○A ...etc
6. [CPU + 擷取裝置](雙主機)
7. [CPU + 區網串流](雙主機)

Intel HD4000的 [QSV] 畫質勝過 Maxwell (first generation) [NVENC] & Tahiti XT2 [VCE]

[CPU] i5 在 1080P 不夠力,請上 i7,並且極限超頻

[CPU + 區網串流] = A QSV(unlimited rate) (LAN)→ B Encoding


實況準備


目的

  • 玩動態稍多的遊戲


需求

  • 不影響系統效能
  • 畫質中
  • 移動時殘塊中至低

條件

  • FHD (1080p)
  • Higher rate (1500~10000 kb/s)
  • Frame rate (20~60 fps)


網站說明


測試時間
2017/02/04


Steam
  • FPS Limited:30 fps
  • Bandwidth Limit:3500 Kbit/s
  • Upload:穩定
  • Download (Buffer):偶爾不穩定
  • Delay:3500 kbit/s 8~11 Seconds
  • Recording:No

Youtube
  • FPS Limited:? fps
  • Bandwidth Limit:10 Mbps
  • Upload:穩定,有時極不穩定
  • Download (Buffer):穩定
  • Delay: ? kbit/s ~20 Seconds
  • Recording:Lifetime

hitbox
  • FPS Limited:60+ fps
  • Bandwidth Limit:無上限
  • Upload:偶爾不穩定
  • Download (Buffer):偶爾不穩定 (存檔的影片下載速度偏低,依賴網路環境)
  • Delay:6000 kbit/s 15~26 Seconds (Website=Livestremer)
  • Recording:Lifetime (官方說有時限,實際上沒有)

Twitch
  • FPS Limited:60+ fps
  • Bandwidth Limit:約 25000 kbit/s
  • Upload:不穩定/偶爾不穩定,依賴網路環境
  • Download (Buffer):穩定/偶爾不穩定,依賴網路環境
  • Delay:6000 kbit/s 15+~28+ Seconds (Website) / ~12+ Seconds (Livestremer)
  • Recording:14 Days (Regular) / 60 Days (Turbo) / Highlight→Lifetime

LIVEhouse.in
  • FPS Limited:60+ fps
  • Bandwidth Limit:5000+ kbit/s
  • Upload:穩定
  • Download (Buffer):穩定
  • Delay:6000 kbit/s ~21 Seconds
  • Recording:10 Days / Highlight→Lifetime

Beam
  • FPS Limited:? fps
  • Bandwidth Limit:3500 kbit/s
  • Upload:穩定
  • Download (Buffer):穩定
  • Delay:3500 kbit/s ? Seconds
  • Recording:?

上傳穩定度
(5000 kbit/s)
Youtube > LIVEhouse.in > hitbox > Twitch

下載穩定度
(5000 kbit/s)
Youtube >> LIVEhouse.in > hitbox =? Twitch

延遲時間(越左越短)
(5000 kbit/s)
LIVEhouse.in < Youtube = Twitch = hitbox

建議線路選擇

  • Twitch
    • 台灣
    • 香港
    • 日本
  • hitbox
    • 香港

  • Youtube
    • 主要
    • 備用


實況方式


主要有分三種,分別是 2 低流量和 1 高流量。


Intel 高階 CPU - 高CPU使用率,低流量


一體成形,獨走風騷,但很容易沒走兩三步就翻車,除非很有技術,否則請勿輕易嘗試。
因為硬體負荷過重,不推薦。
如果一定要使用,建議 720P 或更低。
除非有祖傳祕方的 x264 編碼參數,否則請愛用低耗能遊戲。
小遊戲,手遊,靜態的 LOL 比較可行。
單機大作,請在夢中享用。


Intel 中階以上 CPU 且支援 QSV / NVENC / VCE - 低CPU使用率高流量


最基本要求

在一切程序開始之前,關於 GPU 方面,無論内顯還是獨顯,雖然不是很吃重,但也不是隨便一張卡都可以,還是要有點料,那就是你必須能輕鬆的觀看 1080P 的影片,而且還有餘力應付遊戲 (之後還會提到這點),另外不管有沒有內顯,獨顯都是必須的。

為什麼使用QSV ?

如果採用 CPU 編碼,CPU 必須是 i7 以上並且極限超頻,i5 基本上是不可行的,開下去會嚴重影響到遊戲效能,畢竟比較主流的電腦都是用 i5 組成,因此除了 CPU 編碼之外,硬體編碼就成為了(相對)低產階級們的替代方案。

FFFANx264 cpu編碼主要看遊戲對cpu線程數的負載程度,如果是LOL這種低壓遊戲 2C4T的I3實況1080P FPS設定60,顯卡不是太鳥的狀況下沒問題

自硬體編碼戰開始,同為硬體編碼之中,Intel QSV 最先推出,而 Nvidia NVENC 緊跟在後推出,接著不久後 AMD 也殺出了 VCE。

但至今 2016 年底,無論 NVIDIA 和 AMD 怎麼自吹自家硬編,依照測試結果 QSV 依然穩坐第一名之席位,而且差距還真不小。

除非你真的沒有 QSV,那麼用 NVENC / VCE 代替是推薦的。

FFFANqsv吃內顯運算跟部分分享出來的記憶體資源,所以對性能的損失會比nvenc/vce再小一點,但INTEL不同世代內顯的QSV的編碼品質/效率有差,NVENC/VCE則是硬體編碼/遊戲皆共享GPU運算,性能損失比QSV大一些

使用內顯(QSV)的優缺點

一般來說 CPU 使用率低於10%,或是無感。

缺點:畫質較 CPU 編碼差,需要很高的流量才能與 CPU 編碼畫質抗衡
   1080P 可行的流量至少需達 2000 kbit/s 起跳
   (AVBR 模式 在 6000 kbit/s 以上有優異表現)
   對於記憶體頻寬影響很大,對筆電來說可能有障礙,基本為雙通道 (待確認)

優點:QSV 最強大的地方,就在於它的編碼速度很快
   不會像 CPU 有編碼時間過長的問題,流量幾乎可以說要多高就多高
   約 20000 kbit/s 以上,高動態上可以非常的順暢,殘塊很少
   (特製)CPU編碼 5000 kbit/s 的高動態相同
   因此有不少玩家拿來本地錄影後上傳。

FFFAN一般動態多視角切換快的遊戲 X264編碼@1080p大概至少要開到4000才會比較可以接受
FFFAN硬體編碼如qsv/nvenc或是amd的vce要達到差不多動態畫質碼率得拉高不少,不過不管用哪種方式本來就是有一好沒倆好,而QSV/NVENC/VCE對於很多流量不敷使用的人也不太適用,網路很給力或是單純本機錄影倒是很不錯的選擇


Intel 高階 CPU + 擷取裝置/區往串流 - 不影響CPU使用率,低流量


一機遊戲,一機實況

土豪群實況主們,為了解決同時遊戲和實況造成 CPU 使用率滿載而不足的困境。

採用一台當遊戲機,一台專門來實況。這樣就能完全避免當你玩遊戲又同時實況時,避免 CPU 或 GPU 被實況軟體佔用效能而影響到遊戲體驗。

硬體要多強?

定位

  • 實況機:高階CPU + 較弱的GPU(內顯可) + 擷取裝置(必須支援OBS)
  • 遊戲機:中階以上CPU + 較強的GPU

實況機

沒有改變的是 CPU,只要關係到 CPU 編碼,一樣需要 i7&E3 或更高,x264 編碼的設定,因為相關詳細解析的文章很稀少,所以沒辦法提供,自行去爬吧。

實況機的顯卡不用很強,主要是靠擷取裝置在代替你的顯卡進行捕捉的動作,C985 很有名,但是卻只支援輸出 1080P@30fps,2014 年較有名的是 CV710,真正的支援輸出 1080P@60fps,兩款都可以在 OBS 運行,不過 CV710 有個小問題,原本設計並不是PC用的,是給家機這種使用,若要改成 PC 用需要再準備 1 轉 2 的 HDMI 配置器,另一個比較常被推薦的是 HD75A。 (如果有興趣找CV710可以看這邊的文)
(由於2015之後的我就沒有研究這部分的東西,因此,請自己去爬之後出的新產品)

FFFAN另外如果是對CPU線程數比較依賴的遊戲,如看門狗/CRYSIS 3就算是4C8T的E3/I7排除掉擷取方式及其他變數,其實實況遊戲中的性能也是直直掉,如果是在FPS設定60或者是顯卡GPU瓶頸較大的時候如果堅持X264編碼的話大概也只能望向6C12T,只是成本問題要取捨

遊戲機

這應該不用解釋了,排除了因實況而影響效能這個因子,砸錢吧,弄到多強就多強。


硬體編碼/軟體編碼 傻傻分不清?

  • 硬體編碼,指的是 QSV / NVENC / VCE 這類技術或客製化硬體編碼產品(擷取裝置)。
  • 軟體編碼,指的就是使用 錄影/編輯 軟體時,透過 CPU 編碼來錄製。


什麼編碼方式和 OBS 有什麼關係?

QSV / NVENC / VCE 在 OBS 裡面是內建支援,所以很方便,但是 OBS 並沒有專門支援這些市面上販售的擷取裝置的硬體編碼,如果要讓上面提到的 C985 和 CV710 進行「硬體編碼」,必須使用其官方軟體 RECENTRAL 來錄製才可以。


那買擷取裝置到底做什麼用的?

只用來擷取遊戲機的畫面,所以和硬體編碼沒有任何的關係。

使用OBS的視訊擷取裝置,把「遊戲機的畫面,透過擷取裝置傳送到「實況機」的 OBS,聰明的你應該注意到了,擷取裝置就是拿來擷取用的,基本上對實況並沒有任何的幫助,需要用到的就是它有傳輸畫面和音源的功能。

擷取裝置能亂買,因為市面上很多產品並不支援 OBS,而 C985 有些有支援,所以才熱門
除此之外,擷取裝置可能會碰上高畫質數位內容保護 (HDCP) 的問題,我就不多說了,自行去找方法吧。

實況機和遊戲機,分別是做什麼的?

  • 實況機:
    • CPU - (OBS)軟體編碼進行錄製
    • GPU - 顯示擷取過來的畫面&做濾鏡的運算
    • 擷取裝置 - 擷取遊戲機的畫面和聲音

  • 遊戲機
    • CPU - 遊戲用
    • GPU - 遊戲用


錄影(實況)時發生的問題&改善&建議


這邊我把它混在一起,也方便解釋。

CPU滿載

造成編碼過長而丟失影格。
影片中畫面跳格

GPU滿載

造成編碼不正確。
影片中畫面加速或異常緩慢,甚至跳格的狀況

避免CPU滿載

降低編碼等級
升級 CPU
或者改用 QSV / NVENC / VCE


避免(獨顯)GPU滿載

保留足夠的 GPU 核心使用率,常用的方法有以下幾種:
降低幀數、降低錄影解析度,或是升級顯卡...等等。


顯卡效能需求


不同擷取方式的GPU核心使用率

Window Capture ≦  Monitor Capture < Game Capture < Window Capture (相容模式)

使用全螢幕進行遊戲時只能使用 Game Capture。
雖然全螢幕運行遊戲可以稍微降低GPU負載,但是有些遊戲優化很好,視窗和全螢幕運行遊戲吃的效能是一樣的。
另外開啟相容模式會大幅增加硬體負擔,如可不開啟請不要開。

主要使用的三個方案
1. Monitor Capture + 視窗遊戲
2. Window Capture + 視窗遊戲
3. Game Capture + 全螢幕遊戲 / 視窗遊戲(Studio 限定)

【補充】 

使用 SweetFX 畫面增強插件在 Game Capture 模式中將無法運作。
使用 Game Capture + 全螢幕遊戲,通常會比 Window Capture + 視窗遊戲 還要吃效能。


GPU記憶體使用率


Game Capture = Window Capture (相容模式) < Window Capture << Monitor Capture

記憶體部分,雖然有差但是沒有差很多,頂多多個幾十MB而已,所以可以視為沒有差異


不同擷取方式的流暢度(畫面延遲)


僅供參考

Window Capture ≧ Game Capture > Monitor Capture


點過濾 (Classic 限定)


使用「視窗擷取」、「螢幕擷取」時可以開啟,開啟之後會降低一點點效能但不明顯,可以換來畫面銳化和色階補正,看起來會有顆粒感,如果你的視窗大小沒拉好,文字會出現偏位現象。

我不喜歡開,感覺和原生畫面差很多,不推薦使用。


實況莫名掉幀


某一些遊戲,即使 GPU / CPU 使用率看起來都沒有滿,但是一開實況卻發現 fps 很明顯的下降(視覺感官上),這是遊戲優化不佳的問題

CPU 多核心運算的優化不佳,大致可分兩類
1. 僅有單一核心 CPU 滿載,其餘 CPU 卻未滿載
2. 雖然核心有正常被使用,但各自的使用率都偏低。

要解決這問題,你必須升級CPU,或是超頻,或是雙手一攤,罵兩三句F什麼的,然後當作沒這回事。

已知有問題的遊戲:
  • 刺客教條系列
  • 部分透過 OpenGL API 運行的遊戲


畫面糊糊的,我應該先試著做什麼


  • 增加上傳流量 (推薦)
  • 降低畫格數(FPS) (推薦)
  • 濾鏡 (僅有 Studio 可以隨意調整,Classic 有附加條件)
  • 降低解析度
  • CPU 編碼調整
  • 更換串流平台

1. 提升上傳流量

遇過一些使用者,流量在 1000 kbit/s 或更低,可以提高至最少 2000 kbit/s

2. 降低畫格數(FPS)

非常有效,畫面在高動態模糊會大幅下降,但同時流暢感也會下降許多,事實上,觀看的人會比玩的人感覺來得不敏感,請不要太在意,20 ~ 40 fps 是感受較敏感的區間,需謹慎調整,建議最低請不要低於 20 fps,建議高於 25 fps。

3. 放大來達到劣化畫質 (濾鏡 Classic 限定)

見下面,其他。

4. 降低錄影解析度

1080P → 720P
720P → 480P

5. CPU 編碼調整

提高 CPU 編碼等級,讓你的 CPU 更操
或是,你可以用自訂義的x264編碼做調整。

6. 更換平台

平台很多,不一定要死守一個平台。
我推薦使用 hitbox 或 livehouse。

氣和平台優勢,一般人會選人氣,但,這樣下去實況界永遠不會好。
所以 Twitch 才是那鳥樣子,有錢卻不給玩家好品質。

雖然我知道幾個方法可以改變這個局面,但這並不能達成我真正想要的目的。
我只能說,一切的一切,都是靠玩家們的堆疊所完成。
待時機對了,就會再次「站起來」(?。

【補充】

用固定的 2000 kbit/s 去測試的結果,在低流量時,1080P (原生 1:1) 和 720P (縮減)其實畫面沒有很大的差異。
主要還是畫格數影響比較多,對 1080P 螢幕來說,720P 算是有損畫質,看起來就會沒有 1080P 細節來的高,很多地方會被強制糊掉,降了雖然去塊效果比 1080P 好,但是細節隨著喪失掉。
要畫質最好,最好是能做到 1:1。 (桌面解析度=錄影解析度)


CBR 或 VBR


這兩種格式我們常會在錄影或是轉檔看到。

CBR (Constant bitrate 固定位元速率)

在編碼的時候,要求輸出固定碼率
假設你設定成 1000 kbit/s結果的平均也會在 1000 kbit/s 左右
整個影片中最大碼率也不會離 1000 kbit/s 太遠。

VBR (Variable bitrate 可變位元速率)

在編碼的時候,由電腦控制碼率
假設你設定目標 1000 kbit/s,最大 1000 kbit/s結果的平均會在0~1000 kbit/s 之間,視你的影片,顏色鮮豔的地方通常會需要比較高的碼率,正常不會達到 1000 kbit/s因為過場畫面通常會是很低的碼率。

關於畫質

VBR 不見得會比較差,視軟體的要求,有些 VBR 的模式可以要求兩次PASS,碼率會比較精準,畫質也會比一次 PASS 好,結果和 CBR 相比,我測出來的結果是沒有很大的差異。

如果你害怕 VBR 畫質會很差,請使用 CBR,如果你不迷信,請選擇 VBR,就是信仰問題啦!

VBR 其實還有隱性的穩流效果,使用 CBR 掉包率有可能會比較高,因為一直在相對高的流量,而 VBR 卻是浮動的,可能好死不死,那段時間剛好網路不穩,VBR 可能就可以躲過一劫,另外在低動態畫面時可以獲得遠比 CBR 高的檔案容量上的效益。


其他


GPU 超頻相關(非必要)

TDP (目標瓦數非實際功耗)滿載(約95%)會造成時脈不穩定,代表一種處理器單元達到極限,提升預設 TDP 或最大功耗後有機會穩定。

FFFAN至於TDP,不論是CPU/GPU的TDP SPEC一般遊戲實況不太可能有Burn-in的那種壓力,至多了不起就是boost p-state稍微低一點
FFFAN不會降到像是burn-in時那種倍頻,不同狀況壓力不同,所以只是實況遊戲不太需要去考慮到cpu/gpu的TDP限制

幻燈片現象

最近在測試上傳伺服器和下載伺服器差異,我發現到如果下載位址非上傳位址可能會造成下載時出現幻燈片,一格一格的,推論由於亞洲區可能不存在可供下載的暫存伺服器或是負載過高得不到該端的下載權限,因此導致上傳後至亞洲伺服器仍需要再次傳回美國伺服器,最後用戶端再從美國伺服器進行下載,而在這回傳的路途上,伺服器對伺服器一樣要走海底電纜,因此產生了亞洲伺服器傳回美國伺服器的速度可能會比直接上傳至美國慢一些,而從美國伺服器下載時,由於還沒從亞洲伺服器上傳過去,就出現了斷斷續續的下載量,結果就是出現幻燈片。

唯一不同的地方是,上傳至亞洲伺服器不容易掉包,而美國伺服器則比較容易掉包;伺服器傳伺服器因為不是即時的所以沒有掉包的問題。

理論上,指定上傳至下載伺服器端,可以改善幻燈片現象,但是必須承擔掉包,即丟失影格的風險


CFR 固定畫格速率 的差異 (測試於 Classic)

開啟

 刷新畫格速率固定
 導致「錄影 FPS 遠低於遊戲 FPS」時
 會產生動作較不連貫的感覺
 但遊戲 FPS 極為穩定,或低於錄影 FPS時,該值較沒有意義

關閉

 刷新畫格速率小幅度浮動
 主要使用在錄影 FPS 較低」時,可以增加動作連貫感
 可能不符合實況網站要求
 有機會碰到編碼異常,但目前為止我完全沒遇過。

B-frame 說明和應用時機 (測試於 Classic)

對於 B-frame=0 與 B-frame>0 ,隨著時間增加,比起以往有了更多的體驗之後,現在回來檢視,我發現在當初在寫這個地方是有錯誤的,向各位致歉。

B-frame 在任何的編碼下都可以使用,需設定在 [進階]→[影像]→[自訂OOXX編碼設定]

簡單來說,B-frame 開啟與否關係到參考前後幀。

畫面容易出現殘塊時 (也就是在碼率不足時)

B-frame=0
不會參考前後幀。

優點:低/靜態時,畫質會比 B-frame>0 優異。
缺點:當畫面在靜態轉動態時會急遽劣化。

B-frame>0
能夠參考前後幀

優點:理論上,畫面在靜態轉動態劣化會較為緩和
缺點:當單一像素塊畫質高時,B-frame>0 會造成殘像變得非常明顯,而且會造成畫面不自然閃爍,這個狀況必須經過實際測試才可以知道。

因此,事實上 B-frame 並不適合在會產生殘塊較多的狀況下使用,也就是低流量實況時,當然,如果開啟 B-frame 後沒有發生畫面延遲,仍然是可以使用的。

單一像素塊畫質高殘塊較明顯時,不建議使用 B-frame。

單一像素塊畫質較低,殘塊較不明顯時,B-frame 值可以大於 0,但請務必不要超過 4,提高的效果沒有比較好,而且還有可能會出現音影不同步,通常 1 或 2 會達到最適化

在高流量殘塊量極少時,建議 B-frame 值小於 2,可以設 0 但要先測試過畫質再看看,通常設 1 會達到最適化,0 的畫質是最好的。

總結來說,在實況時 B-frame 值設為 1,是最為通用的。
殘塊較不明顯、殘塊量中至少,開啟可以達到最佳的較果。

此外,B-frame 和 IDR 幀有一些類似,但是他是一直發生的現象,而不是長時間的週期現象,故在常時下,影響是不容小覷的。

若要使畫面看起來均衡,降低單一像素塊畫質為優先考量
若要使畫面看起來模糊,提高 B-frame 優先考量

關於 IDR (關鍵影格) 造成的閃爍

碼率不足以應付當前畫面換景時IDR 又在當下沒有參考前後幀時,就會發生閃爍
畫面的改變很巨大,人眼會很明顯的感到前後1秒的畫面是不同的,感覺起來就是閃爍。

實況網站大部分都會要求玩家將關鍵影格設為 2 秒,當我們設定了這個固定秒數,在沒有參考前後幀的狀況下,每到設定的秒數,畫面就會強制進行換景此就有高機率每隔固定秒數就閃爍一次。

最佳的選擇是設為自動,而非 2 秒,2 秒只是為了配合伺服器端的二次編碼方便進行,若將關鍵影格設成自動,IDR 會在比較適合的時間點上加入,閃爍的感覺亦會下降許多。

此外 B-frame 的效果在設為自動時會比較有用。

如果認為格式不符合網站是沒關係的,可以把關鍵影格設定成自動,但是壞處就是設成自動會有播放幀數不穩定或伺服器端編碼錯誤而出現斷線的可能性。

另外,要解決這問題還有一個方式:增加上傳流量
這也是不錯的選擇。

放大來達到劣化畫質 (僅限 Classic)

如果要做高畫質錄影,建議使用原生錄影解析度。

原本螢幕最高解析度只支援到 1920 x 1080

用下圖的設置,就可以做 Downsample

這邊改完之後,請記得去編輯場景的大小,因為改完之後場景空間會變成4倍大,所以需要重新拉滿畫面。

濾鏡的層級,依照 GeDoSaTo 的說明:(可以嘗試解說他們的差異)
  • bilinear: 顯示卡一般會做事情,較便宜的性能代價
  • bicubic: 較高的畫質,更貴的性能代價
  • lanczos: 較高的畫質和銳化,最貴的性能代價

關於這個東西,如果你碰到流量不方便提高、動態殘塊太明顯時,尤其是遊戲畫面是較為鮮豔的,可以選擇使用這招。

假設你有一個螢幕的原生解析度 1920x1080,如果把錄影解析度調到 3840x2160 之後,會發生三件事。

1. 錄影區塊變為4倍 (像素增加為4倍)
2. 遊戲只佔錄影區塊的1/4
3. 殘塊大小變成1080P的1/4

之後,把遊戲畫面重新拉滿整個錄影區塊,你會發現,看起來比畫面變差而且柔化,這是因為,你剛剛把一個 1/4 大的東西,放大了 4 倍,就跟小畫家有個圖形,原本只有 1x1 你卻把它拉成 4x4 的道理是一樣的,畫質會劣化,不過這劣化程度會比起 720P 縮減來的少。

缺點:在某些狀況下,比起原生解析度,GPU使用率將近多了1倍。


在全彩中進行編碼 (Classic) / YUV 顏色範圍 (Studio)

這是在後續測試時發現到先前的錯誤,現在看到的是重定義後的內容
打勾這個選項,可以改變錄製顏色的深度,RGB範圍從16-235變成0-255
但事實上,這個設定可有可無,因為主要問題來自於播放器的處理

用4張圖來解釋

全彩編碼 Enable / 播放器 (未定義) / 驅動強制 (0-255)

全彩編碼 Enable / 播放器 (未定義) / 驅動強制 (16-235)

全彩編碼 Disable / 播放器 (未定義) / 驅動強制 (0-255)

全彩編碼 Disable / 播放器 (未定義) / 驅動強制 (16-235)

第1張看出來有嚴重曝光的現象
第2、3張完全一樣,正常還原色階
第4張就是真正16-235的灰階表現,明顯有色階下降的問題

由於網路上普遍屬於3圖的類型最多
所以建議關閉全彩中進行編碼然後,驅動設定成0-255
藉此忽視錄影源要求格式的轉換來維持相容性

另外
如果播放器有限定的話會強制設定成播放器的設定
這樣的狀況下無論OBS或驅動怎麼改都不會有任何效果


YUV 色彩空間 (僅限 Studio)

請愛用「709」,但請不要去動 YUV 顏色範圍,使用預設「部分」就好。


縮放濾鏡 (僅限 Studio)

不是影像設定中的壓縮方式,而是從「預覽」畫面中進行設定。
右鍵「來源」,可以選擇縮放濾鏡有以下五種可選:
  • 停用 (預設)
  • 雙性線插值
  • 雙三次插值
  • Lanczos

停用
即不會重新縮放
在預覽畫面中,適用於視窗未進行過任何縮放之視窗。
例如:遊戲的解析度為1920x1080,預覽畫面同為塞滿版面的1920x1080。

任何時候都不推薦,目前沒有比較適合的應用地方,也請不要去測試。

雙性線插值
較停用之畫面略為銳化。
在預覽畫面中,適用於進行過任何縮小或放大之視窗。
除了原生以外有改過大小的都推薦。

雙三次插值
毛刺感高,除非有必要,不推薦。
在預覽畫面中,可用於進行過任何大幅度縮小之視窗。

Lanczos
毛刺更高,除非有必要,不推薦。
在預覽畫面中,可用於進行過任何大幅度縮小之視窗。


NEVNC 研究區

The 'Default' preset just chooses between High Quality and High Quality Low Latency depending on your resolution and frame rate. Currently, OBS picks High Quality for 1080p60 or greater. 'Auto' would probably have been a better name for it.
'NVDefault' is the real default preset exposed by the NVENC API. It has most of the features enabled except B-frames. There is no encoder latency, since NVENC has no frame lookahead, but frame sizes vary significantly, requiring a buffer for smooth playback.

'High Quality' is essentially NVDefault with B-frames enabled. B-frames usually improve compression efficiency, but, with NVENC, they do not. I don't know if this was fixed in Maxwell, but the High Quality preset actually produces worse results than NVDefault on my GTX 670.

The 'Low Latency' presets add extra processing to try to keep frames at a constant size. Frames can be decoded and displayed in real-time without the need for a buffer. This is good for applications like remote gaming and videoconferencing where every millisecond counts, but it significantly reduces picture quality.

All of the presets are fast enough to be used for real-time encoding; however, if you were encoding multiple streams at a time, you might need to use the faster presets.

In terms of quality, I would rank the presets as such:

NVDefault > High Quality > High Quality Low Latency > Low Latency

The High Quality Low Latency preset preserves more detail than the High Quality preset, but it also generates a lot of blocky artifacts, making it end up looking worse in most cases.

For general use, I would use the NVDefault preset. ShadowPlay uses something like it, and it has very good video quality. The High Quality preset would be useful if I dropped frames a lot or wanted very fast seeking. The Low Latency presets just weren't designed for our use case and subjectively doesn't look very good. Of course, you should test it yourself and see if it looks better to you.


我做了幾個測試,NVDefault 畫質確實是最佳的,但是也最吃流量。

NVENC - NVIDIA Hardware Video Encoder Application Note

這個 PDF 提到 Kepler 和 Maxwell 1、2 代在 Quality / Low Latency 的編碼效率。

只有 Maxwell 2 代 可以玩 H.265,在 H264 上 1、2 代的效率差異沒有很大,但是和Kepler比起來就贏很多。


QSV AVBR 研究區 (測試於 Classic)


特性

比 CBR 和 VBR 掃描的速度慢。
較能保住靜態、低動態的畫質。
高動態的畫質回復較慢。
在高動態的時候細節會比 CBR 和 VBR 平滑、均衡。
(不像 CBR 和 VBR 一碰到高動態畫質就完全劣化,整塊糊掉。)

此模式在中等流量跑低動態遊戲時會有很優異的表現

最近,我開始研究起準確性(%)和收斂這兩個在OBS裡面可調整的參數。
因為原本的解釋非常繞口而且難懂,故不細說,只講出結果。

準確性

當「無法達到目標碼率」,優先做出的畫質顯示條件。
當「可達到目標碼率」時,此項目效果不顯著。

準確性 0 %,單一像素格畫質低 (色塊均衡)
準確性 100 %單一像素格畫質高 (色塊獨立)

準確性 100 % + B-frame=0 畫質高,殘塊最明顯
準確性 0 % + B-frame=0 畫質中,殘塊明顯
準確性 100 % + B-frame=2 畫質中低,殘塊略為明顯
準確性 0 % + B-frame=2 畫質低殘塊較不明顯

若「不可能達到目標碼率」準確性建議低於 100%
數值需要依照個人喜好設定

收斂

無論能不能達到目標碼率意旨進行準確性判定前所需的週期時間
「可達到目標碼率」時,此項目效果不顯著。
運作模式如下:
畫面→(等待收斂時間)→(準確性判定)→畫質做出變化
當此值越高,在動態後進入靜態,回復至最佳畫面所需時間會增加
理論上,能將動轉靜的碼率稀釋至動態畫面,以擠出更多的碼率給動態使用
但此條件實用性並不是很高,在不能達到目標碼率時,效果並不顯著

數值建議高於 0
「不可能達到目標碼率」,數值可盡量提高

以下是 Studio 的設定

其中有個小BUG,若非同步(Async)設定為 1,且錄製格式為 mp4 的時候,QSV 解碼會出現影音不同步的問題,建議您採用 mkv 當作錄影格式,這個問題就可以解決。



多平台實況 (Windows)


兩種方式,流量要求不同,穩定度也有所不同。

第一種:透過二次串流網站

支援蠻多平台的
但是從亞洲區的上傳量不到 2000 kbit/s 就在狂掉包
不管是傳到 北美/大洋洲/歐洲 的伺服器端都一樣
所以,這是極不可靠的一個選擇。
而且延遲時間會比原本單一串流還要高出不少。
唯一的優點就是不需要增加額外的流量,這點稍後會解釋。


第二種:透過特定程式來達到分流

透過nginx的rtmp模組
對本地端IP進行上傳
再讓程式監控該IP的串流數據並轉發到指定的實況台網址

透過這種方法的缺點是沒有流量分配和顯示的功能
這會導致上傳流量達到物理極限時,你不知道上傳量到底足夠不
你只能透過實況網站上看到的為準,甚至連有沒有掉包都不知道。
當然,如果你很清楚自己到底有多少的上傳量就不需要煩惱這個問題
伺服器選對了沒意外應該就是穩穩地

進入正題

首先你要下載的 nginx 必須是有包含 RTMP 模組
不然是不能用的

你可以從這裡下載
nginx 1.7.12.1 Lizard (後續的版本都沒有支援)
就是有包含 RTMP 模組的 nginx

接著到路徑
nginx 1.7.12.1 Lizardconf

新增一個新文字文件.txt
複製這串指令

#user  nobody;
worker_processes  1;

error_log  logs/rtmp_error.log debug;
pid        logs/nginx.pid;

events {
    worker_connections  1024;
}

rtmp {
    server {
        listen 1935;
        chunk_size 8192;

        application stream {
            live on;
            meta copy;
            push rtmp://live-ams.twitch.tv/app/live_XYZ_ZXY;
            push rtmp://live.hitbox.tv/push/username?key=XYZ;
        }
    }
}

更改串流金鑰
到網站上自己找
別忘了最後會有個「;」,請別刪掉
live_XYZ_ZXY
username?key=XYZ

更改伺服器
可以用 OBS 的 Server Ping 插件看到
舉例來說:
Twitch 台灣線路是 live-tpe.twitch.tv/app
要變更就是把歐洲線路 live-ams.twitch.tv/app 改成台灣線 live-tpe.twitch.tv/app

更多平台
自己多加一條
push  rtmp://OOXX

最後存檔,再把這個文件改名成
nginx.conf

如果看不到附檔名,你可以將存檔類型改成「所有檔案」後再存檔

最後開啟命令提示字元
置換到指定資料夾執行 nginx.exe

假設我把「nginx 1.7.12.1 Lizard」這個資料夾放在C槽
像這樣:C:nginx 1.7.12.1 Lizard

那我必須在cmd上輸入的就是:
cd C:nginx 1.7.12.1 Lizard
start nginx.exe

輸入完之後就會看到跳出一個視窗然後過一下就消失,這就是有執行成功
在工作管理員中會看到兩個 nginx.exe 這就代表有正常運作

到這裡為止,大概就是 nginx 的部分。

至於OBS的部分

        application stream {

這個是 nginx.conf 中的一項重要參數
(先記著下面會用到)

看看FMS URL,這是我的設定(見圖)
rtmp://192.168.1.101/stream

192.168.1.101 就是我的虛擬IP
要發送的位置,你可以從網路和共用中心找到
或是可以試試看用
rtmp://localhost/stream
反正就是試圖把資料傳給自己

stream 就是上面 nginx.conf 中所設定的名稱
必須一致,不然就會失敗
當然也可以改成任何你喜歡的文字等等 (例如:live)


一切就緒之後,就大功告成啦
每次重開電腦要記得再執行一次運行 nginx.exe

如果你有其他使用上的困難你可以參考下面這兩個影片

如果你在win7以下碰到上傳量的問題
可以用試著用這條 reg 來做改善

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesAFDParameters]
"DefaultSendWindow"=dword:00010000

這條的功能原文是這樣的:
I've also encountered this issue on Windows Server 2008 R2 (which shares the same code with Windows 7), and I discovered that the send window was too small, bottlenecking FFmpeg. Neither FFmpeg nor nginx-rtmp allow you to adjust their send windows, so I changed Windows's default send window (no pun intended).

I've attached the registration entry for your convenience. It sets the default send window to 64K. Apply the entry and restart your computer. FFmpeg should then be able to stream to Twitch at full speed.



如果你想讓 nginx 在 Windows有更進一步的使用需求,可以參考 #1 #2

我目前已有自行編譯成功的案例
nginx-1.11.10
nginx-rtmp-module-1.1.11
openssl-1.0.1u (1.1.0和1.0.2目前都失敗,需要再研究研究)
pcre-8.40
zlib-1.2.11

(為了弄這個,當時折騰了我一整天,搞得我快壞掉啦QQ)


網路節點重要性


我在使用的多平台串流時候
發現到一個很嚴重的問題

很容易掉包
而且平台不固定
有時候是A,有時候B有問題

之後我回到只串流一個進行探討
我發現到ISP有時候會引導你到優化不佳的節點
造成你一連上去就狂掉包
一旦連上優化好的節點,卻一切正常

當你連到爛節點,請不要猶豫
重新連線就是了

測出ping值越低,理論上穩定和上傳能力就是越高
當你發現ping明明夠低,但是卻狂掉包
問題很可能就是出在連線的節點路徑不佳

另外,在多平台串流上
nginx 沒有辦法查詢掉包資訊
所以必須透過其他程式監控IP (你必須知道哪一個是IP是指哪個平台)
看上傳流量就可以約略知道現在到底有沒有掉包
如果想謹慎一點,就要透過看自己的台幾十秒來確認

般來說
在看自己的台的時候
有問題一看就知道了
通常就是跳格、畫面撕裂或只剩聲音而畫面停止

至於要在連上後幹掉IP重連
會需要透過一些網路監控軟體來達成


另外要幹的話,要注意一點
短時間內不要幹太快,不然有時候會BUG
顯示有傳送但是實際上網站卻是離線狀態
連到爛線最好還是等個幾秒再幹



CPU編碼特區 (研究向,非福利)


(本區並非完全正確,請看看參考不要太相信)

淺談量化向的CPU編碼心得

重要參數

qp
qpmin
qpmax
畫質表現的上限(qpmin)和下限(qpmax),這會影響到實際能輸出的畫面等級
在CPU運算未超支的前提下,最低值能達到越低愈好,基本上即時運算又要保有低值是困難的
最高值可以設定較高來稀釋碼率需求,但效果並不顯著,適中即可,亦可以強迫較高畫質

bframes
上面已經提到不少關於這個設定的解釋,但是在CPU編制中,可以透過相關設定更改B幀和其他幀的權重,在CPU編制中是很難調教的一個功能之一,如果可以,真的不太想去動它

me
模式會極大的影響到畫面在動態時的畫質,也是CPU爆炸的主因

merange
me 模式裡的搜索範圍,影響較小,但是過度增加一樣會導致CPU爆炸

aq-mode
這功能可以說有點神奇,當值為2時,動態場景的畫面表現有顯著的提升,相對的在動態時CPU更容易爆炸

rate
流量在CPU編碼中其實不是很重要,原因是CPU編碼不管怎麼編最終都是透過量化的結果
好比說,有個杯子,容量就是CPU編碼參數,而裝進去的水就是碼率,當水溢出時,也就是實際碼率大於CPU編碼參數所需的碼率時,多出來的流量毫無意義,換句話說,這衍生了一個很嚴重的問題
在CPU編碼中,透過增加流量來提高畫質的是不太可行的

結語
到目前為止,就我所知
要達到高畫質又要省CPU的編碼是不存在的
想要高畫質就是要讓CPU吃滿吃爆

我沒有親自測試過,但目前的已知的是
目前市面上 i5 等級以上的 CPU 可以達到 3500 kbit/s 720P 高畫質實況
但很可惜 Windows 似乎辦不到,要在 Linux 下用 FFmpeg 編制
實際上跑是能跑得動,但也是很勉強的
而1080P會直接爆給你看

距離六、八核心普及還有不短的一段時間
待普及之後,還有很長的路可以走

我的原則就是
在有限的資源下,做到最好。

至於問我資源的在哪,就是看到的這些了。
這個時候只要恨我不是土豪就好了 (笑


畫質測試


使用 QSV 的條件下

Xsplit:
使用 VBR 模式
去塊能力極佳

OBS Studio:
使用 AVBR 模式
相較於 Class 版,同概念的畫質設定下更為優異

實況建議度
Xsplit ≧ OBS Studio = OBS Classic

這邊會推薦 Xsplit 原因在於去塊能力非常優異,既使在碼率不足的高動態下,仍然有不錯的平滑感,降低一眼就看出畫質很差的感覺,但這也意味著,它的最高畫質精度不如 OBS Studio,而且在色差處理上也是有比較差的趨勢,不過對於觀眾來說,我想應該優先取決於動態畫質的表現,當真不愧是付費軟體,抓住了重點。

錄影建議度
OBS Studio > OBS Classic > Xsplit

OBS Studio 因為部分設定和 Classic 不同,這使得 OBS Studio 可以提供比 Classic 更好的靜態畫質,同時在顏色設定上 Studio 有了更多選擇,但基本上和 Classic 一樣,沒有意外的話,畫質表現上 Studio 已經完勝 Classic (在AVBR模式及畫質需求下)。


上傳/下載觀察報告


上傳
路由的影響較高,需要靠自己洗IP跑trace,方法暫不談,因步驟極為複雜且環境差異過大。
其餘依照 ping 值越高,上傳速率逐漸減少。

下載
受先天上通訊設備能力限制。
次之以 CDN 位置及流量為主要影響依據
若站方設有流量限制,即與 ping 值無關時,回天乏術。

普遍來說 DNS 不具有改變 CDN 之效力,被動操控方式為變更上傳伺服器,主要操控方式為變更路由線路或強制變更下載位置



低幀(FPS)救星 (僅限 Studio)


非常實用,但木眼還是看不出來。

在 Studio 版中,有自訂的 FPS可以任意填入任何數字,以高 FPS 來說,例如 60 FPS,這影響並不會有什麼,但是在非常低的 15 FPS,這時就不那麼好玩了,簡直是糟糕透頂。

在低 FPS 的時候,對於眼睛好的人總是會覺得不太舒服,其中的原因不外乎就是連貫感不佳,如果曾經有過更高FPS的體驗之後,會讓人覺得原本該有的細節(動作)消失了,畫面產生了跳躍感。

現在,讓我們有個機會可以稍微改善這點。

在設定中,除了「常用 FPS」與「自訂 FPS」之外,我們還有「自訂 FPS 比率」,這功能似乎沒啥屁用,不過就是個分子分母而已,一般也不會刻意去除到什麼 29.999 的奇怪數字,理應是用不上的才是,但我錯了,這就是神奇的地方。

一般的高 FPS 是這樣,分母就是設 1 沒錯啊,看起來沒有變動的需要。
影格數(分子):60
秒數(分母):1

而低 FPS 是這樣,也沒錯,沒什麼不同,就 FPS 低了很多。
影格數(分子):15
秒數(分母):1

那接下來,影格提高到 90,分母改成 6,也沒什麼對吧,實際上還是 15 FPS 在輸出。
影格數(分子):90
秒數(分母):6

那現在,這樣到底有什麼意義,一樣是 15 FPS 沒變啊。
影格數(分子):900
秒數(分母):60

但,實際上,同為 15 FPS 的這三組,最下面這組 900/60 的表現最好,能看到的細節遠比 15/1 來的多上許多。

為什麼?
就因為你有血輪眼?
啊不是

這要讓我提一下,第一人稱射擊遊戲。
對一部分的人來說,關掉垂直同步並使用無邊框視窗遊玩的人,體驗會比較深刻。

在過去 CRT 螢幕有著破 60 Hz 是很常見的,而如今除非特別挑選比較高階的 IPS / VA 液晶螢幕,很平民的螢幕就只有 60 Hz。

想當然,玩射擊遊戲就是要比別人看到畫面更早且更多細節才能先發制人,這並不是空談,而是實際存在的事實。

那對於我們這些 60 Hz 平民階級呢?

我們不會因為螢幕是 60 Hz 就把 FPS 鎖在 60,如果可以我們會把 FPS 拉到 100 以上,或是大部分遊戲的極限 200 FPS,這麼做看似沒有用,但實際上體驗過的都懂,差別可大了。

你能看到的細節確實更多,但不會比 120 Hz的玩家更早。

那到底是?

因為人腦有一種功能,自動分析。

不知道您有沒有看過一部漫畫,直至死亡將我們分開(台譯:終極感應),裡面的女主角能預測未來,它的原理是因為這主角的大腦很會玩統計學(分析能力),總之就很意外的能推算出遠比一般人更遠更準確的未來

當人在獲得的畫面足夠連貫之時,其實都可以推測出接下來的極短暫的後續動作,因此細節會變多,這之中的就只差在有沒有自覺而已。

那麼在這裡反過來說,因為細節變多了,所以畫面的連貫感提升了也就成立。

說了一堆廢話,那到底要設多大才夠?
畫格數(分母)越高越好,但效果會呈遞減的曲線,隨著 FPS 不同會有不同的極限點。

不建議將影格數設定高於 5000,這可能會對編碼效能造成一定程度的負擔。


送禮物贊助創作者 !
0
留言

創作回應

影旭
請問有OBSS的設定教學嗎? 我怎麼改好像都畫質沒甚麼變化 不像OBS版一樣好處理
2017-02-12 13:16:20
惡魔羊Baphomet
請問您在「QSV AVBR 研究區」下的附圖,「準確度」的部分,你填了「10000」,
我滿困惑的,我原以為這是填0~100的百分比(%)的欄位。
所以想請問這個欄位大概是要填什麼範圍的數字。
2017-02-25 20:46:41
TermSelf
看心情, 當然是能設最高就設最高阿
2017-02-25 21:06:35
㊣看似平凡♂
請問7. [CPU + 區網串流](雙主機)
有可以不修改IPV4 前提完成嗎?
2018-02-08 09:06:27
TermSelf
我不太確定你講的東西是指什麼, 但問我能不能, 應該是可以, 我有看過類似的東西, 不過我跟nginx不熟, 所以...客製化的部分需要你自己去研究, 我估計是幫不上忙, 我想應該是需要額外建一個本地server讓他可以辨識出127.0.0.1之類的
2018-02-10 02:15:20
kelvin
想問OBS直播如何設定好呢? 常遇到[畫面模糊]問題 // 網速 上傳690Mbps 下載940mbps 處理器R5-1600 顯卡1070 螢幕1080P 直播平台Youtube
2018-04-19 08:26:53
ルビー
YT目前的編碼上傳後會削減我的碼率除非他幫我轉VP9但要觀看人數六千以上才會轉VP9 但有些高手上傳AVC1時 光是720P畫質就比我的1080P好 這種要該如何調整?
2020-06-29 14:18:50
TermSelf
請問你的編碼方式跟設定是? 如果可以的話請提供一些自己的影片以及其他人的影片以作為參考
2020-06-29 17:26:53

更多創作