幾乎一年前,我們寫了一篇科普向的文章:http://vcb-s.com/archives/2726,意外地廣受大家好評。很多讀者在評論中表達了希望有後續科普的意願,今天我們為大家帶來這個系列的後續篇。

閱讀本篇之前,請務必確保你基本理解了科普三(上文鏈接)的內容。如標題所示,本篇致力於講述播放器相關的知識,而不是任何播放器安裝教程。

這篇教程的目的是,為那些希望折騰一個更好播放器的觀眾,講述一些平時你閱讀的教程,不會跟你說的重要知識,來解答以下問題:

. 播放器播放視頻,是怎樣的一個流程?

. 硬解和軟解的區別優劣在哪裡?

. 什麼樣的播放效果是最標準、最原汁原味的?

. 為什麼高級播放器教程全寫的那麼繁瑣複雜,還特容易各種出錯?

. 為什麼動漫壓制特別喜歡用10bit,而且播放器動不動推薦madVR?

. 不同精度在播放器中的標識是怎樣?怎麼判斷播放過程是否對畫質有折扣?

. SVP/Reclock/XySubFilter是怎樣插件?

. 我應該怎樣選擇合適我的播放環境?

……

 

本教程將分以下模塊詳細敘述:

1、播放器的工作流程:分離,解碼,渲染

2、硬解的定義、分類

3、YUV->RGB轉換過程中的細節

4、硬解的優劣與選擇

5、圖像格式的標識與查看方法

6、動漫畫面區別於常規錄製視頻的特殊性

7、播放器軟件的現狀與分析

8、其他常見播放器配件簡介

9、播放器配置學習的建議

 

1、播放器的工作流程:分離,解碼,渲染

簡單說就三個大步驟:分離、解碼、渲染。

分離,指的是拿到媒體文件(MKV/MP4/MKA)等,先收集相關的文件(包括外掛音軌、字幕),然後將所有軌道拆開,拆分成單獨的內容。視頻流、音頻流、字幕、章節信息,等等。負責執行分離的模塊濾鏡,叫做分離器(splitter/demuxer)。

當同樣類型的軌道不止一條的時候(比如多音軌),分離器還負責挑選其中的一條。通常同類型多軌道,會有一條軌道被設定為“默認軌”(比如多音軌MKV一般以主音軌為默認),你想選擇副音軌,你就需要在分離器中手動切換。很多播放器會在自己的界面中提供音軌/字幕切換的功能,其實也是間接利用分離器實現的。

分離器現在能用的基本上只有LAV/ffmpeg了(這倆幾乎可以算一家),以前還有個Haali,然而停止更新已久,不能適應HEVC時代了。

分離器一般不耗費運算性能。因為它只是簡單地收集、拆分和選擇。

 

解碼,指的是將分離器丟來的各種原生壓縮格式,比如H264/H265的視頻,FLAC/AAC的音頻,解碼為非壓縮的格式,比如視頻是YUV/RGB(相當於bmp),音頻是PCM(相當於wav),然後丟給下游模塊。負責解碼的模塊濾鏡稱為解碼器(decoder)。常見的有LAV/ffmpeg, ffdshow(同樣停止更新了)……

當解碼器能完全解碼一個軌道中所有有效信息的時候,我們成為完全解碼(現在絕大多數情況是如此),否則稱為不完全解碼。比如說,早期一些顯卡的硬解,不能完全處理H264視頻流的所有,解碼出的畫質有折扣;又或者DTS-HD MA解碼器開源之前,基於ffmpeg/lav等解碼器只能解碼出部分信息,導致音頻是有損的。

解碼出來的格式,都需要加上精度的度量。比如說10bit 視頻完全解碼後是YUV 10bit,8bit視頻是YUV 8bit,16bit flac格式是PCM 16bit整數,aac是PCM 32bit浮點。麻煩在於,解碼器下游的模塊不見得能照單全收。比如說以前播放器就不支持10bit YUV丟給下游,解碼器只好轉為YUV 8bit(後來madVR之所以是一個極大的提升,就是因為madVR基本上全部通吃)。同理;很多聲卡能支持24bit整數PCM已經是極限,所以32bit浮點的PCM需要轉為24bit整數。

如果解碼器可以將最原始的數據,或者更高精度(比如有時候為了方便,將10bit轉為16bit)輸出給下游,我們稱為全精度輸出;否則,解碼器會試圖降低精度輸出,我們稱為低精度輸出。少數時候,我們會讓解碼器做一些轉換(比如vcb-s新播放器教程中,讓lav解碼器做YUV->RGB的轉換),我們稱為轉換輸出。

解碼器,特別是視頻解碼器,往往成為大量消耗運算資源的地方。這個問題在H264早期非常嚴重,那時候的主流CPU很難負擔720p/1080p的高清解碼,能耗巨大,移動平台尤其如此。所以才催生了各種硬件加速和硬件解碼,並逐漸成為一個規範標準。

 

渲染,指的是將解碼後的數據,在pc硬件上(顯示器、揚聲器)進行播放。負責渲染的模塊我們稱之為渲染器(Render),視頻渲染器主流有EVR(Enhanced Video Render, 微軟送的)以及madVR(madshi Video Render)。

音頻渲染器一般都是系統自帶的(同樣是微軟送的),也有可以自定義的。比如MPC播放器有MPC Audio Render,可以支持類似wasapi輸出等其他功能。

因為顯示器是RGB顯示,而解碼後的視頻多為YUV格式,渲染器一般也需要負責將YUV轉換為RGB,並保證輸出的圖像大小跟播放窗口吻合。

多數播放器自帶的濾鏡(mpc/pot都有很多調色之類的功能),顯卡的加成,以及SVP,都作用於解碼器和渲染器中間。它們接過解碼器解碼的數據,對其進行處理,然後將處理後的數據送給渲染器。因為渲染器是需要藉助顯卡進行圖形運算,YUV數據基本上需要先進入顯存,所以顯卡可以檢測到丟來的YUV數據,對其進行“優化”。同樣需要當心的是,這些濾鏡和處理,往往入口精度低,處理精度也低。導致的後果就是解碼器被迫低精度輸出,給這些濾鏡低精度處理,從而大幅降低視頻精度,導致色帶色塊問題。

字幕的加載可能在渲染器前(將字幕信息整合進YUV/RGB數據給渲染器),也可能在渲染器後(播放器來將字幕整合入生成完畢的RGB圖像)。

多數解碼包的配置界面,主要就是讓你選擇分離器、解碼器和渲染器的:

如上圖,上方就有讓你選擇視頻渲染器,然後下方左右分別是針對不同文件格式的分離器,以及針對不同媒體格式的解碼器。

2. 硬解的定義與分類

如上文所說,硬解是為了緩解高分辨率新編碼面世初期,CPU不堪重負的解碼壓力,而誕生的技術。如果說軟解的定義是:利用CPU通用運算能力,進行解碼,那麼硬解的定義可以這麼說:不利用CPU通用運算能力,而是依賴其他集成電路,無論是否特製,來進行解碼。

更古老的時候,有些顯卡沒辦法進行完全解碼,只是幫助計算部分解碼過程中的運算,那麼可以歸為“硬件加速”。估計Intel下一代CPU“混合加速HEVC解碼”也是一樣的道理。

硬解現在比較常見的是以下種類:

DXVA(DirectX Video Acceleration),比較古老的方案了。Windows XP以及之前系統上流行的。上古ffdshow的硬解就是利用DXVA。DXVA規範下容易出現不完全解碼,導致畫質降低。Vista以後,漸漸地被拋棄。

DXVA2,目前主流的硬解方式。主要由GPU來實現,但是並非利用GPU的流處理器,INA三家都是使用了單獨附在GPU芯片上的一塊專職電路來完成。GPU硬解能力往往不與顯卡遊戲性能相關,而與搭載的專職電路先進與否相關。典型的就是GT610,它是NVIDIA第一款能硬解4K視頻的GPU,同時代其他GTX650/GTX580什麼面對4K視頻只有傻眼的份兒,就因為它的GPU塞入的專職電路,是剛開發出最先進的一款(代號為VP5,其他同時代的都是VP4)。

使用DXVA解碼,都需要先將視頻數據(壓縮的格式)傳輸到顯存中,然後再讓GPU進行解碼。

DXVA2有兩種實現方式:native和copy-back。區別是解碼後的數據是否還要傳回內存。

native選擇不傳,直接丟給同樣依賴GPU工作的渲染器,數據從頭到尾都在顯存中。而copy-back選擇傳,數據會傳回內存,一番處理後再傳回顯存,讓渲染器工作。native的輸出必須為YUV 8bit,而copy-back則可以為10bit。

之所以需要有copy-back這麼個傳來傳去的過程,就是因為有些濾鏡,比如SVP,比如LAV的轉格式,必須依賴CPU+內存進行工作。不傳回來沒辦法繼續處理。copy-back保證了硬解的流程類似軟解,可以不漏下任何後處理。而代價是傳來傳去必定降低性能,增加能耗。需要注意的是,即便用native,也可能導致解碼後的數據被“優化”,因為有些處理,包括播放器、顯卡驅動帶的那些,是可以完全作用在GPU環境中的。

除了DXVA2,還有兩種特殊的硬解:Intel Quick Sync, 和NVIDIA CUVID。如同名稱所示,它們是Intel和NV的專屬。

Intel Quick Sync是集成在CPU中的邏輯電路承擔的。注意的是這玩意並非隸屬於Intel的集顯,而是CPU的直屬。它直接讀寫內存,運行表現和軟解非常類似。Intel Quick Sync堪稱速度快,能耗低。

NVIDIA CUVID,是基於NV自己的接口,寫的一個類似DXVA2(copy-back)的升級版。

硬解的模式可以在LAV Decoder的設置中選擇:

banner26

紅框的下拉框可選None(軟解),CUVID,QuickSync,DXVA2(native 和 copy back)。

每選擇一個模式(除了None),藍框會顯示一個單詞:

Active:當前正在使用這種模式解碼

Available:應該可以使用這種模式

Not Available:不支持使用這種模式

綠框當中則是顯示當前在使用哪個解碼器。如果是軟解,顯示avcodec,否則顯示類似dxva2cb, dxva2n等標示。

碰到沒辦法開啟硬解,比如設備不能正常工作,或者碰到10bit AVC這種不支持的,那麼自動轉為軟解。

 

3、YUV->RGB轉換過程中的細節

將解碼器輸出的YUV格式,轉為RGB,並且縮放到播放窗口輸出,是視頻渲染器的職能。可以說,如果解碼過程是完全解碼,也不主動添加播放器調校和驅動增強,渲染的環節決定了最終成品的畫質。造成畫質區別的可以說就三點:縮放算法,運算精度,和抖動算法。任何試圖優化渲染器效果的嘗試,都應該從這三個方面着手。

縮放算法造成的區別,比較好理解。例如原圖(150*150):

kanade

用雙線性算法(上,多數播放器默認算法)和nnedi3(下)放大到272 * 272像素:

19867d

2015

不同算法造成的效果肉眼可見。注意上圖中隨處可見的鋸齒,以及細線的模糊。

精度,是指運算的過程中,參與運算的數,有效位數的高低。在計算機中表現為使用怎樣的格式來進行,8bit/16bit/32bit整數,16bit/32bit浮點。精度不足的表現在上篇教程中已經有展示,不做贅述,然而還是提醒一句:千萬不要以為顯示器是8bit,就認為8bit 整數 的片源精度/處理精度是足夠的。

另外,RGB處理相對YUV處理,精度要求相對較低;或者說,RGB處理相比較,精度稍低帶來的影響不明顯。(不幸的是多數時候處理的數據都是YUV,然後根據水桶原理……)播放過程中,應該盡量減少RGB-YUV互轉的次數,每一次轉換都要做一次計算與取整,都會導致實際精度降低。

抖動算法(Dithering Algorithm),通常出現在高精度轉低精度中。在數字圖像高轉低處理中,全部四捨五入不見得是好習慣。抖動算法通過科學的添加噪點,來掩蓋精度的不足。比如說原圖(RGB24,即RGB 8bit):

分別用四捨五入(上) 和 Floyd–Steinberg 抖動算法(下),將此圖轉為RGB16(RGB分別為5bit,6bit和5bit,早期windows桌面的“16色”,區別於RGB24的“真彩色”)

可以看出,使用抖動算法的圖片較好的掩蓋了精度不足引起的色帶和偏色問題。在YUV 和 RGB的運算過程中,如果出現高精度轉低精度,是否使用抖動,使用的抖動算法如何,也會決定輸出效果。

 

現在,我們來模擬一下渲染器的工作流程,並用藍色標註出可能造成畫質差別的地方:

1、渲染器從解碼器那裡獲取YUV數據。注意拿到的數據可能是全精度,也可能是降精度,取決於渲染器接口類型;

2、播放器和顯卡驅動可能會試圖“優化”畫面;

3、如果不是YUV444格式的,渲染器會先將UV平面放大到Y平面的大小。這個步驟稱為Chroma upscaling;

4、將YUV444的數據,轉為RGB。轉換的過程勢必需要浮點運算(YUV->RGB一些參與運算的常數是浮點數);

5、播放器或者渲染器將RGB用特定的算法縮放到播放窗口大小。這個步驟稱為Image Upscaling(圖像放大)/Downscaling(圖像縮小);

6、因為4的步驟中,必須以浮點數運算,而輸出結果一定是RGB 8bit整數,因此輸出之前必須有一個高轉低的過程

2~6每一步都涉及數字運算,因此有運算精度的區別

 

問:什麼樣的渲染器,什麼樣的輸出畫面是標準的、完美的?
答:沒有。因為運算精度總可以無限的高,縮放算法也永遠有提升的空間,所以視頻播放不存在“標準、完美”一說;只有相比較而言的好與差,以及在人眼識別程度內的“接近完美”

問:有哪些渲染器能“接近完美”的處理以上所有情況?
答:只有madVR。

問:Windows充話費送的那個EVR,默認情況下有啥不好?
答:1、接口精度低,強迫YUV 8bit/RGB 8bit的輸入;2、縮放算法默認是平庸的雙線性;3、運算精度較低,默認只有8bit整數和16bit浮點數;4、抖動算法有,較為單一和固定;5、如果輸入的是YUV數據,EVR會任由播放器和驅動亂來。

問:我們能怎麼拯救EVR?
答:1、因為RGB對精度要求不敏感,而且輸入RGB後,驅動和播放器基本沒辦法插手,所以設法永遠輸入RGB 8bit,不讓YUV數據經過低精度處理;2、讓LAV解碼器來做YUV->RGB。LAV可以以32bit浮點的高精度、雙立方的UV放大算法、隨機抖動算法,較高質量的完成轉換;3、圖像縮放算法手動設置為更高級的雙立方。

問:聽上去不錯,我們應該怎麼操作?
答:參見http://vcb-s.com/archives/4384或者http://vcb-s.com/archives/4407

 

所以,如果你使用的是madVR渲染器,你應該允許LAV輸出它默認設置的那些格式,YUV/RGB。LAV會以全精度輸出YUV給madVR進行處理;如果你使用EVR渲染器,你應該永遠只允許LAV輸出RGB 8bit

RGB 8bit 包括RGB24和RGB32。RGB32多一個透明層通道,看似帶了個沒用的東西,但是因為計算機更喜歡2的次方,所以部分運算下RGB32比RGB24快。在視頻播放中,這兩個格式幾乎完全等同;互轉也人畜無害(加一個空的透明度通道 vs 去掉透明度通道)。

之前基於EVR CP教程中,之所以pot推薦RGB24輸出,而mpc推薦RGB32輸出,是測試的結果。這樣設置播放器不會再多一次轉換(雖然就算轉換了也沒啥)。

 

4、硬解的優劣與選擇

絕大多數vcb-s的教程,都讓大家不要開啟硬解,就算開啟,優先使用DXVA2(copy-back),這裡我們做一個詳細的解釋。

首先考慮一個問題:什麼樣的視頻能被硬解?

8bit AVC可以被各種顯卡硬解;然而8bit AVC格式的軟解壓力小的可憐,以vcb-s常發的24fps 1080p的視頻算,現在CPU軟解,佔用率普遍不到5%。

10bit AVC沒有能硬解的。(所以10bit版炮姐時代,試圖硬解的洗洗睡吧。)軟解,解碼壓力尚可,不是很可怕,24fps 1080p的視頻,現在的cpu大約10%

8bit HEVC現在最新顯卡普遍能硬解;然而因為8bit x265的缺陷(或者說8bit x264的優越性),我們發現這玩意表現多數還不及8bit AVC,所以vcb-s從來不用;相對而言,它的解碼壓力也不大,大致相當於10bit AVC。

10bit HEVC,目前只有NV的GTX950和GTX960支持硬解。它的軟解壓力算是比較大,現在主流的CPU佔用在20%左右;對於上古CPU或者一些低端筆記本CPU,流暢解碼會比較吃力,特別是60fps的特典。對於將來的4K 60fps,現在桌面4核心CPU基本上完全無力軟解。

能硬解的視頻必須是YUV420格式。

分析完畢了,你覺得自己需要硬解么?

如果你沒有GTX960/GTX950,你也基本碰不到1080p 60fps乃至4K的8bit HEVC,那麼你只能去硬解8bit AVC,省那麼5%不到的CPU佔用率——真有這個必要麼?軟解吃力的硬解解不了,硬解解得了的軟解解的飛起,那我們為什麼要冒着各種潛在風險去開硬解呢?

好吧,就算你說我真有理由要開硬解:我有GTX960/950,我的CPU真的太爛……我們來分析下不同情況下,硬解應該怎麼開。硬解設置跟你使用的渲染器有關:

如果你使用madVR,通常是不建議你開硬解的。眾所周知madVR會消耗大量顯卡運算,因此沒必要再去把大量數據塞進GPU和顯存,跟madVR搶奪資源。讓CPU分擔解碼,讓GPU專心跑madVR,是比較推薦的做法;

如果你使用GTX960/950硬解10bit HEVC,請務必設置為DXVA2(copy-back),這是現在唯一可以開啟10bit HEVC硬解的模式;

其他情況下,如果你真的非要開硬解搭配madVR,建議順序(保證你硬件可用): Intel QS, DXVA2(native), NV CUVID, DXVA2(copy-back),其實用哪個都沒有太多關係,主要的功耗消耗點在madVR。

如果你使用EVR CP(調節過縮放算法),希望追求較高質量的播放,你首先要排除的是DXVA2(Native)。因為這種模式下,LAV會直接輸出YUV 8bit給顯卡,哪怕強制規定了輸出只能是RGB。用DXVA2(copy-back)是可以的;這種模式下,解碼後的數據將回傳給CPU,繼續做高質量轉RGB的後續操作。

如果你使用GTX960/950硬解10bit HEVC,請務必設置為DXVA2(copy-back),理由同上,並且也需要強制RGB輸出。

其他情況下,建議順序: Intel QS, NV CUVID, DXVA2(copy-back)

所以不難理解為什麼之前教程我說了,要開硬解請用DXVA2(copy-back)。這種軟解流程、硬解運算的泛用性模式,是最人畜無害的,哪怕這種模式折騰程度,導致在性能和功耗上大多是得不償失。

追求最大性能的,特別是用來對付那些能夠被硬解的高清病毒的,請使用EVR默認,搭配DXVA2(Native)播放。這樣效率應該是最高的,各種專治8bit AVC 4K的高清病毒。只不過這種做法會損失畫質,因此不建議日常使用。

 

5、圖像格式的標識與查看方法

在播放器中,不同格式、不同精度的圖像,有着規範的定義和標號。這一點可以在LAV的設置界面很清楚的看到:

2015

其中藍色部分標示的這些是最常見到的,主要是YUV 420的不同精度,以及RGB格式(注意16bit RGB,即RGB48,在現有播放器體系下還沒有實裝,所以現在播放器中的RGB基本就是RGB 8bit)

使用DXVA2(Native)硬解的時候,輸出是DXVA,也是YUV420 8bit。

RGB格式除了上文所說的RGB32和RGB24,播放器中還有XRGB和ARGB的標示,也都是一回事兒。

Potplayer中觀察方法,可以用tab鍵顯示:

banner26

potplayer會給出視頻解碼器(圖中是LAV)

解碼器輸入的格式是HVC1(HEVC),輸出是RGB給渲染器。YUV->RGB的過程完全是LAV處理。

渲染器是EVR CP,渲染整個過程,格式都是RGB,沒有轉回YUV。需要注意的是你必須關閉pot自帶的內置濾鏡(按F5,進入”參數選項”設置。 2、點擊“濾鏡”,將右邊的”內置圖像處理濾鏡設置”激活條件設置為:”不使用”),否則potplayer一定會自作主張轉回YUV的。

縮放算法是Lanczos 3。(注意如果你播放畫面跟視頻畫面相同,比如你在1080p的顯示器上全屏播放,縮放算法會顯示臨近採樣,這是正常的)

 

MPC-HC/MPC-BE中,按Ctrl+J可以調出類似的信息:(再按1~2次取消)

2015

紅框中勾選的,Formats表示渲染過程中格式變化,從始至終都是RGB;

Video Size給出了原始尺寸和播放尺寸,以及使用的縮放算法(雙立方 A=-0.6)

Decoder則是解碼器;輸出是RGB。

通過這樣的查看方法,你可以知道你的播放器工作流程,以及設置是否按照預期。

 

6、動漫畫面區別於常規錄製視頻的特殊性

一直以來都有這樣的說法:“10bit, madVR這些東西都是那些壓動漫的人弄出來的歪門邪道,我是看不出這些東西在電影上有個P用。”

其實吧,這還真不是這群人眼力不好或者裝睡不醒。區別於錄製視頻,比如電影之類的,動漫、CG等有着自己的特殊性。總結起來就兩點:1、噪點少,2、線條非常突兀。

視頻拍攝,限制於器材水準,噪點是不可避免的,在後續製作等過程中也難以完全去除。而動漫天生可以0噪點,動漫中的噪點更多是數字圖像處理中主動加上去的。噪點的一大作用就是極大地降低視頻處理和壓制,對於精度的需要。說的簡單點:高噪點的視頻不怕低精度,反之亦然。

怎麼理解這個概念呢?我們藉助一個簡化的圖片來演示。假設我們有一條平滑、高精度的曲線(這是y=1/x在[10,30]上的圖):

現在,我們把所有函數值,四捨五入到小數點後三位數:

降低精度的效果很明顯,我們現在的圖看上去跟樓梯一樣,出現了明顯的”斷層”。表現在視頻中,這種斷層就是色帶。同時值得注意的是,越是平坦、變化小的地方(就是之前科普中的”平面”),色帶表現越嚴重。

現在,我們模仿給圖像加噪點,來給這個函數加一個小幅度(約為1%)隨機抖動:

然後我們也把它的精度限制為小數點後3位:

可見,這一次精度降低,圖像似乎沒有受到太多影響,精度降低造成的階梯狀效果也很不明顯。表現在數字圖像處理中,意味着噪點重的圖片,在降低精度的時候收到的影響很小。

這就是為什麼那些致力於改善精度的提升,對於電影等視頻幾乎沒有用——播放過程的精度低怎麼了;能有什麼視覺影響?

類似的現象,噪點會使得人眼對圖像銳利度等差異不敏感,或者說,縮放算法造成的區別,變得不太可見。以之前的圖為例,假如為兩幅圖都加上強度相同的噪點:

2015

2015

區別已然幾乎不可見。注意噪點是如何幫忙掩蓋拉升過程中的鋸齒等瑕疵,並加入虛假的高頻信息,讓圖像看上去細節很豐富。這還是應用在線條/平面非常分明的動漫;換作電影,這樣的差異只會更不起眼。

小結一下,當有噪點存在的時候,主打高精度、優秀縮放算法的播放器,優勢將不再明顯。從另一個方面講,面對較少噪點、較為突出線條的動漫,對播放器的精度和縮放算法提出的要求就很高。編碼器也是一樣的道理,動漫非常需要10bit x264/x265這樣原生高精度的編碼器來提升畫質。

因此,再面對本節開頭的說法,不需要反駁,那是很自然的(攤手)。

 

問:既然加噪點可以有效避免精度降低,為什麼在動漫壓制中不用這個方法呢?

答:噪點作為一種高頻信息,需要浪費成倍的碼率。在今天10bit編碼可以不增加(甚至減少)碼率完美解決問題的前提下,我們為什麼要用10年前的理解呢?

PS: 10年前只有8bit編碼器的時候,主動加噪確實是很常見的防色帶、去色帶手段。在今天商業性藍光編碼器只有8bit精度的限制下,很多動漫藍光後期也是通過加噪點解決的(Sony那高大上的“SBMV技術”的核心)。然而,藍光可以不惜碼率,Rip不行,除非你是Yousei。(所以Yousei的Devil-Jin至今用着這種手段)

 

7、播放器軟件的現狀與分析

接上文分析。面對占絕對多數的電影觀眾,現有的播放器,pot/mpc默認,已然足夠好了。再好的設置能帶來的觀感提升幾乎沒有,還不如在什麼一鍵增強,左眼效果,以及在線字幕、彈幕上下功夫。

面對多數動漫黨,稍微修改一下基於EVR CP+LAV的播放設置,也能達到很滿意的效果,很平衡的兼顧畫質、性能與穩定性。所以如果你不求折騰(還把這麼長的教程看到這裡,真是辛苦你了),建議使用vcb-s最新寫的兩篇64bit播放器教程。

如果你真的欲求不滿,那麼你就可以試着接觸madVR,SVP這些東西。但是有一點需要提醒的是:這些純粹由fans開發的東西,甚至包括mpc/pot這些軟件,是高度不可靠的。哪怕所謂的“穩定版”,出bug的幾率都很高。(更別提現在madVR一直都是“測試版”,版本號還在0.x)MadVR至今有個問題,就是它所在的目錄路徑不能有中文。這個問題存在幾年了,作者壓根不屑於,或者說,抽不出精力去修復它——你見過幾個正兒八經的軟件不支持安裝目錄有中文?!

更恐怖的是,高質量播放依賴的組件數量龐大,而彼此之間缺乏系統性的聯繫測試。開發者往往是各自測試各自的,沒有組織、沒有公司說作為一個整體來調試一套方案。當播放軟件趨於複雜,組件數量增多,功能強化,出錯的概率指數級上升。一個基於potplayer+madVR的播放方案,不考慮音頻,涉及到以下可能出問題的地方:

potplayer本體,  LAV分離器,LAV視頻解碼器,madVR渲染器,操作系統,顯卡和顯卡驅動。

假設每一個組件出錯的平均概率是3%,求問這一套方案正常運行不出錯的概率是多少?1-0.97^6=83%。

也就是說,平均5個人裡面,就有一個人用這套方案出錯。出錯的理由往往很難查到,每個人都有每個人的原因。

(舉個我自己的例子,雖然我寫的教程基於mpc-hc,但我自己在用mpc-be。因為對於mpc-hc,我設置讓EVR渲染器使用雙立方縮放,mpc-hc始終都使用的是最樸素的雙線性,導致縮放效果很差(對我來說)。各種途徑查錯無功而返,最終換mpc-be問題解決。)

所以以後請別問我為什麼不寫madVR+SVP+Reclock+XySubFilter這些高端貨的教程,更別出了錯問我錯在哪裡、怎麼解決——臣妾做不到啊!

 

8、其他常見播放器配件簡介

除了madVR,其他播放器折騰一般還有這些配件:

SVP(Smooth Video Project)比較眾所周知了,它是一個插值平滑軟件。本身依賴avisynth開發,通過ffdshow/ffdraw來加載,作用在解碼器之後,渲染器之前。SVP只能支持YUV420 8bit輸入輸出。

SVP的性能消耗非常可觀,特別是開啟OpenCL之後,如果再開啟madVR(接EVR CP容易導致精度問題,這時候可以手動在ffdshow/ffdraw中加噪點來緩解),對顯卡的性能和驅動穩定性都是考驗。儘管如此,SVP的插值平滑帶來的觀看提升也是非常可觀的,強烈建議madVR的倍幀滿足不了、同時又有很強配置的觀眾們爬文安裝。

 

XySubFilter,是目前最先進的字幕插件,對高級字幕特效的支持,渲染的質量,性能的優化,對高精度播放以及madVR的配合都做得很到位。如果你患有字幕強迫症末期,建議去折騰一下這個插件。

 

Reclock,一個致力於改善播放視頻幀率不穩定的插件,不過多數人用它的目的可能還是為了它的wasapi輸出。實際表現完全聊勝於無,特別是wasapi現在mpc自帶的audio render就內置了,而且Reclock沒有64bit版,因此不建議折騰。

 

9、播放器配置學習的建議

對於想自學高級播放器設置的同學們,教程總是不缺的,網上一搜一大堆,各大論壇什麼的置頂帖,萬年冷凍庫,等等。寫的比vcb-s現有幾篇教程更新、更詳細、更高端的比比皆是,也都可以作為很不錯的教程。然而我一直認為,這些教程只是授人以鯉,或者授人以鯿、鰱、鱅……,導致的結果就是來一隻鯽,或者給你個漁網讓你按照自己喜好撈一隻,很多人一下子就傻眼了。

這也是我寫這篇教程的初衷,講述一下現在網上林林總總的教程,不會跟你說的很多細節與知識。有的人madVR設置玩出了花,結果不知道檢查pot內置的ffmpeg解碼器,會把YUV420 10bit 降低精度+瞎轉換 為YUV422 8bit丟給madVR,然後又說自己看不出區別……這折騰的意義何在呢。

學習播放器配置,有這麼幾條原則,是我希望分享給大家的:

1、實事求是。不要盲目的去折騰,也不要為了心理安慰去折騰。一套更好的方案,只有你確實感覺到了提升,並且這個提升在你心理滿意度上,足夠抵消麻煩,才值得你去升級。比較的過程中,相信自己的眼睛,而不是相信別人的說教。比如說我真不推薦筆記本用戶折騰任何頂級縮放算法——那麼小個屏幕你能看出點啥?教程里說出花的放大算法跟你有幾毛錢關係?

2、循序漸進。先把一套簡單基礎的方案弄好弄懂,再去學習和嘗試更好的方法。對於新的插件,你要嘗試測試它們在你機器上的表現;對於別人的設置,設法了解他這麼推薦的原因,以及這個原因是否適用於你。最典型的,很多人用着madVR問我,你在新教程里教我們LAV只勾選RGB,我要改么?看了這篇教程你應該知道要不要改與背後的原因了吧。

3、量力而行。播放器越高級,組件越多,往往性能消耗越大,出錯概率也越高,同時收益越少。學會放棄與妥協,畢竟,你看的是片子,不是播放器組件和參數。

 

 

LittlePox

LittlePox

VCB-Studio 前隊長/壓制組組長
LittlePox

[VCB-Studio 科普教程 1.4] 在 macOS 上使用 IINA 播放器

本文主要為 macOS 用戶介紹 IINA 這款播放器。和之前的 MPC-HC 和 PotPlayer 的教程一樣,本文的目標讀者是對播放器不希望太折騰,同時希望能獲得較好畫質的...

阅读全文

[VCB-Studio 科普教程 2.5] 基於 PotPlayer 和 madVR 的播放器教程

Potplayer 是高清影視常用的播放器,界面簡潔,功能齊全,比 MPC-HC 和 MPC-BE 更人性化;但其默認方案十分糟糕,預設過多錯誤,無法正確播放 10-bit 視頻,...

阅读全文

[VCB-Studio 科普教程 2] madVR 渲染器配置教程(2016.08.13 更新)

現在的高清視頻觀看體驗,瓶頸不在片源,也不在製作,而是在播放器 ——題記 看到logo那張對比圖了么?曾經就有人拿着右邊效果一般的截圖來質問我,而正確的播...

阅读全文

114 条评论

  1. 您是說現在大多數的藍光原盤內的視頻不是 以每秒24張(或30之類的?)無損bmp圖像的形式存儲,而是編碼成了yuv420之類的有損圖像存儲的?

  2. 寫得好詳細,國內應該找不到第二篇這麼詳細的教程了
    另外關於reclock:
    其實reclock的出現其實是因為PC的顯卡輸出的刷新頻率並不能準確的設置。對於23.976fps的視頻顯卡沒法以準確的23.976Hz的刷新率輸出給電視,N卡的刷新率大概會在23.967左右,於是視頻比音頻略慢一點,最後導致每隔幾十秒鐘丟一幀,非常惱人。所以有一群人想出了對音頻重採樣加速的辦法,reclock就是這個目的。
    當然很多人覺得自己並沒有體驗過每隔幾十秒頓一下的感覺,那是因為你的顯卡輸出60Hz,24p的視頻已經通過2:3下拉本身就加入了很多重複幀,沒有原始的24p那麼流暢。
    所以總結一下,對於不是用24p的電視或投影,並且也不用SVP的同學,reclock完全沒用意義。
    P.S. 最近我發現有個叫做Custom Resolution Utility (CRU)的軟件可以較精確的設定顯卡輸出的刷新率,某些情況下的效果可以取代reclock

  3. 按網上的教程http://www.hd.club.tw/thread-124742-1-1.html折騰了SVP 3.1.7後,發現開啟SVP必須使用ffdshow raw video filter濾鏡,雖然視頻信息上看還是用的LAV+MADVR,請問這裡使用ffdshow會不會降低精度+瞎轉換?

    1. 現在的svp用的ffdshow的raw濾鏡,解碼還是交給LAV的,默認情況下,ffdshow只是走個流程,不會亂搞格式,雖然ffdshow支持的格式沒lav那麼多,但是4:2:0的基本上都沒問題

      1. 今天折騰了半天后發現,開啟svp所必需的ffdshow確實會強制降低LAV的輸出精度,我在播放VCB的心理測量者2時發現輸出從原先的P010,10bit變成nv12,8bit,關閉ffdshow後恢復原樣。若強制在LAV中設置10bit輸出,則輸出會變成P416,16bit。莫非是我設置有誤?

欢迎留言