[VCB-Studio 科普教程 5] 那些播放器教程背後的知識

幾乎一年前，我們寫了一篇科普向的文章：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的設置中選擇：

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

每選擇一個模式（除了None），藍框會顯示一個單詞：

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

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

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

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

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

 

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

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

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

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

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

精度，是指運算的過程中，參與運算的數，有效位數的高低。在計算機中表現為使用怎樣的格式來進行，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硬解的模式；(2020年更新：現在native/D3D11也行了，那就選這倆加加速吧）

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

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

一般情況下，建議順序： Intel QS, NV CUVID, DXVA2(copy-back)

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

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

 

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

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

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

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

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

Potplayer中觀察方法，可以用tab鍵顯示：

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次取消)

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

小結一下，當有噪點存在的時候，主打高精度、優秀縮放算法的播放器，優勢將不再明顯。從另一個方面講，面對較少噪點、較為突出線條的動漫，對播放器的精度和縮放算法提出的要求就很高。編碼器也是一樣的道理，動漫非常需要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、量力而行。播放器越高級，組件越多，往往性能消耗越大，出錯概率也越高，同時收益越少。學會放棄與妥協，畢竟，你看的是片子，不是播放器組件和參數。