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

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

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

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

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

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

?

解碼，指的是將分離器丟來的各種原生壓縮格式，比如H264/H265的視頻，F(xiàn)LAC/AAC的音頻，解碼為非壓縮的格式，比如視頻是YUV/RGB（相當(dāng)于bmp），音頻是PCM（相當(dāng)于wav），然后丟給下游模塊。負責(zé)解碼的模塊濾鏡稱為解碼器(decoder)。常見的有LAV/ffmpeg, ffdshow(同樣停止更新了)……

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

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

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

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

?

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

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

因為顯示器是RGB顯示，而解碼后的視頻多為YUV格式，渲染器一般也需要負責(zé)將YUV轉(zhuǎn)換為RGB，并保證輸出的圖像大小跟播放窗口吻合。

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

字幕的加載可能在渲染器前（將字幕信息整合進YUV/RGB數(shù)據(jù)給渲染器），也可能在渲染器后（播放器來將字幕整合入生成完畢的RGB圖像）。多數(shù)解碼包的配置界面，主要就是讓你選擇分離器、解碼器和渲染器的：

?

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

2. 硬解的定義與分類

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

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

硬解現(xiàn)在比較常見的是以下種類：

DXVA(DirectX Video Acceleration)，比較古老的方案了。Windows XP以及之前系統(tǒng)上流行的。上古ffdshow的硬解就是利用DXVA。DXVA規(guī)范下容易出現(xiàn)不完全解碼，導(dǎo)致畫質(zhì)降低。Vista以后，漸漸地被拋棄。

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

使用DXVA解碼，都需要先將視頻數(shù)據(jù)（壓縮的格式）傳輸?shù)斤@存中，然后再讓GPU進行解碼。

DXVA2有兩種實現(xiàn)方式：native和copy-back。區(qū)別是解碼后的數(shù)據(jù)是否還要傳回內(nèi)存。

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

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

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

Intel Quick Sync是集成在CPU中的邏輯電路承擔(dān)的。注意的是這玩意并非隸屬于Intel的集顯，而是CPU的直屬。它直接讀寫內(nèi)存，運行表現(xiàn)和軟解非常類似。Intel Quick Sync堪稱速度快，能耗低。

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

硬解的模式可以在LAV Decoder的設(shè)置中選擇：

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

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

Active：當(dāng)前正在使用這種模式解碼

Available：應(yīng)該可以使用這種模式

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

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

碰到?jīng)]辦法開啟硬解，比如設(shè)備不能正常工作，或者碰到10bit AVC這種不支持的，那么自動轉(zhuǎn)為軟解。

?

3、YUV->RGB轉(zhuǎn)換過程中的細節(jié)

將解碼器輸出的YUV格式，轉(zhuǎn)為RGB，并且縮放到播放窗口輸出，是視頻渲染器的職能?？梢哉f，如果解碼過程是完全解碼，也不主動添加播放器調(diào)校和驅(qū)動增強，渲染的環(huán)節(jié)決定了最終成品的畫質(zhì)。造成畫質(zhì)區(qū)別的可以說就三點：縮放算法，運算精度，和抖動算法。任何試圖優(yōu)化渲染器效果的嘗試，都應(yīng)該從這三個方面著手。

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

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

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

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

另外，RGB處理相對YUV處理，精度要求相對較低；或者說，RGB處理相比較，精度稍低帶來的影響不明顯。（不幸的是多數(shù)時候處理的數(shù)據(jù)都是YUV，然后根據(jù)水桶原理……）播放過程中，應(yīng)該盡量減少RGB-YUV互轉(zhuǎn)的次數(shù)，每一次轉(zhuǎn)換都要做一次計算與取整，都會導(dǎo)致實際精度降低。

抖動算法(Dithering Algorithm)，通常出現(xiàn)在高精度轉(zhuǎn)低精度中。在數(shù)字圖像高轉(zhuǎn)低處理中，全部四舍五入不見得是好習(xí)慣。抖動算法通過科學(xué)的添加噪點，來掩蓋精度的不足。比如說原圖（RGB24，即RGB 8bit）：

?

分別用四舍五入（上） 和 Floyd–Steinberg 抖動算法（下），將此圖轉(zhuǎn)為RGB16(RGB分別為5bit，6bit和5bit，早期windows桌面的“16色”，區(qū)別于RGB24的“真彩色”)

?

?

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

?

現(xiàn)在，我們來模擬一下渲染器的工作流程，并用藍色標注出可能造成畫質(zhì)差別的地方：

1、渲染器從解碼器那里獲取YUV數(shù)據(jù)。注意拿到的數(shù)據(jù)可能是全精度，也可能是降精度，取決于渲染器接口類型；

2、播放器和顯卡驅(qū)動可能會試圖“優(yōu)化”畫面；

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

4、將YUV444的數(shù)據(jù)，轉(zhuǎn)為RGB。轉(zhuǎn)換的過程勢必需要浮點運算（YUV->RGB一些參與運算的常數(shù)是浮點數(shù)）；

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

6、因為4的步驟中，必須以浮點數(shù)運算，而輸出結(jié)果一定是RGB 8bit整數(shù)，因此輸出之前必須有一個高轉(zhuǎn)低的過程。

2~6每一步都涉及數(shù)字運算，因此有運算精度的區(qū)別。

?

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

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

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

問：我們能怎么拯救EVR？
答：1、因為RGB對精度要求不敏感，而且輸入RGB后，驅(qū)動和播放器基本沒辦法插手，所以設(shè)法永遠輸入RGB 8bit，不讓YUV數(shù)據(jù)經(jīng)過低精度處理；2、讓LAV解碼器來做YUV->RGB。LAV可以以32bit浮點的高精度、雙立方的UV放大算法、隨機抖動算法，較高質(zhì)量的完成轉(zhuǎn)換；3、圖像縮放算法手動設(shè)置為更高級的雙立方。

問：聽上去不錯，我們應(yīng)該怎么操作？
答：參見http://vcb-s.com/archives/4384或者http://vcb-s.com/archives/4407

?

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

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

之前基于EVR CP教程中，之所以pot推薦RGB24輸出，而mpc推薦RGB32輸出，是測試的結(jié)果。這樣設(shè)置播放器不會再多一次轉(zhuǎn)換（雖然就算轉(zhuǎn)換了也沒啥）。

?

4、硬解的優(yōu)劣與選擇

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

首先考慮一個問題：什么樣的視頻能被硬解？

8bit AVC可以被各種顯卡硬解；然而8bit AVC格式的軟解壓力小的可憐，以vcb-s常發(fā)的24fps 1080p的視頻算，現(xiàn)在CPU軟解，占用率普遍不到5%。

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

8bit HEVC現(xiàn)在最新顯卡普遍能硬解；然而因為8bit x265的缺陷（或者說8bit x264的優(yōu)越性），我們發(fā)現(xiàn)這玩意表現(xiàn)多數(shù)還不及8bit AVC，所以vcb-s從來不用；相對而言，它的解碼壓力也不大，大致相當(dāng)于10bit AVC。

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

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

分析完畢了，你覺得自己需要硬解么？

如果你沒有GTX960/GTX950，你也基本碰不到1080p 60fps乃至4K的8bit HEVC，那么你只能去硬解8bit AVC，省那么5%不到的CPU占用率——真有這個必要么？軟解吃力的硬解解不了，硬解解得了的軟解解的飛起，那我們?yōu)槭裁匆爸鞣N潛在風(fēng)險去開硬解呢？

好吧，就算你說我真有理由要開硬解：我有GTX960/950，我的CPU真的太爛……我們來分析下不同情況下，硬解應(yīng)該怎么開。硬解設(shè)置跟你使用的渲染器有關(guān)：

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

如果你使用GTX960/950硬解10bit HEVC，請務(wù)必設(shè)置為DXVA2(copy-back)，這是現(xiàn)在唯一可以開啟10bit HEVC硬解的模式；

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

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

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

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

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

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

?

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

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

其中藍色部分標示的這些是最常見到的，主要是YUV 420的不同精度，以及RGB格式（注意16bit RGB，即RGB48，在現(xiàn)有播放器體系下還沒有實裝，所以現(xiàn)在播放器中的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，沒有轉(zhuǎn)回YUV。需要注意的是你必須關(guān)閉pot自帶的內(nèi)置濾鏡（按F5，進入”參數(shù)選項”設(shè)置。 2、點擊“濾鏡”，將右邊的”內(nèi)置圖像處理濾鏡設(shè)置”激活條件設(shè)置為：”不使用”），否則potplayer一定會自作主張轉(zhuǎn)回YUV的。

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

?

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

紅框中勾選的，F(xiàn)ormats表示渲染過程中格式變化，從始至終都是RGB；

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

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

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

?

6、動漫畫面區(qū)別于常規(guī)錄制視頻的特殊性

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

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

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

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

?

現(xiàn)在，我們把所有函數(shù)值，四舍五入到小數(shù)點后三位數(shù)：

?

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

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

?

然后我們也把它的精度限制為小數(shù)點后3位：

?

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

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

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

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

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

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

?

問：既然加噪點可以有效避免精度降低，為什么在動漫壓制中不用這個方法呢？

答：噪點作為一種高頻信息，需要浪費成倍的碼率。在今天10bit編碼可以不增加（甚至減少）碼率完美解決問題的前提下，我們?yōu)槭裁匆?0年前的理解呢？

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

?

7、播放器軟件的現(xiàn)狀與分析

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

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

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

更恐怖的是，高質(zhì)量播放依賴的組件數(shù)量龐大，而彼此之間缺乏系統(tǒng)性的聯(lián)系測試。開發(fā)者往往是各自測試各自的，沒有組織、沒有公司說作為一個整體來調(diào)試一套方案。當(dāng)播放軟件趨于復(fù)雜，組件數(shù)量增多，功能強化，出錯的概率指數(shù)級上升。一個基于potplayer+madVR的播放方案，不考慮音頻，涉及到以下可能出問題的地方：

potplayer本體, ?LAV分離器，LAV視頻解碼器，madVR渲染器，操作系統(tǒng)，顯卡和顯卡驅(qū)動。

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

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

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

所以以后請別問我為什么不寫madVR+SVP+Reclock+XySubFilter這些高端貨的教程，更別出了錯問我錯在哪里、怎么解決——臣妾做不到??！

?

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

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

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

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

?

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

?

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

?

9、播放器配置學(xué)習(xí)的建議

對于想自學(xué)高級播放器設(shè)置的同學(xué)們，教程總是不缺的，網(wǎng)上一搜一大堆，各大論壇什么的置頂帖，萬年冷凍庫，等等。寫的比vcb-s現(xiàn)有幾篇教程更新、更詳細、更高端的比比皆是，也都可以作為很不錯的教程。然而我一直認為，這些教程只是授人以鯉，或者授人以鳊、鰱、鳙……，導(dǎo)致的結(jié)果就是來一只鯽，或者給你個漁網(wǎng)讓你按照自己喜好撈一只，很多人一下子就傻眼了。

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

學(xué)習(xí)播放器配置，有這么幾條原則，是我希望分享給大家的：

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

2、循序漸進。先把一套簡單基礎(chǔ)的方案弄好弄懂，再去學(xué)習(xí)和嘗試更好的方法。對于新的插件，你要嘗試測試它們在你機器上的表現(xiàn)；對于別人的設(shè)置，設(shè)法了解他這么推薦的原因，以及這個原因是否適用于你。最典型的，很多人用著madVR問我，你在新教程里教我們LAV只勾選RGB，我要改么？看了這篇教程你應(yīng)該知道要不要改與背后的原因了吧。

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

?

?