一、背景介紹

隨著移動互聯網的深入發展，視頻消費場景逐漸變成主流，早期由于手機硬件的限制問題，導致生產出來的視頻畫質、清晰度存在較大的問題，用戶體驗不太好，當時的網絡也處于4G的發展階段，網絡的限制也無法持續支持高清視頻的消費，但是現在5G發展地如火如荼，網絡的高速發展，手機硬件性能的提升，用戶越來越不滿足于低畫質和低清晰度的視頻。提升視頻的畫質和清晰度勢在必行，需要一套行之有效提升視頻清晰度的優化方案。

二、評價標準

做一件事情之前，首先需要確定一下評價這件事情的標準。所以在提出視頻清晰度優化方案之前，必須先確定一下衡量視頻清晰度的評價準則。評價視頻清晰度有兩種準則：

2.1 客觀標準

客觀標準就是利用算法計算視頻畫面質量分，同等條件下，如果A視頻的質量分得到高于B視頻，說明A視頻的保真質量做得比B視頻更好。評估視頻質量的算法有兩大類：

• 完全參考：兩個視頻逐幀對比分析，計算對比的質量，這種使用的比較多，常見的VMAF、PSNR、SSIM都是完全參考。
• 部分參考：截圖視頻中的部分幀來對比分析。有些場景例如直播沒法完全對比，截取部分幀來對比是比較科學的。

目前Netflix推出的VMAF算法是評價視頻質量的主流算法，下面我們簡單介紹一下：

• VMAF 全稱 Video Multi-method Assessment Fusion ，它借助人類視覺模型以及機器學習來評估一個視頻的質量。
• VMAF的評價指標主要包含：其中VIF和DLM是空間域的，表示一幀畫面之內的特征；TI是時間域的，表示多幀畫面之間的相關性特征。

視頻信息保真度（VIF：Visual Quality Fidelity）

細節損失指標（DLM：Detail Loss Measure）

時域運動指標/平均相關位置像素差(TI：Temporal Information)

• VMAF基于SVM的nuSvr算法，在運行的過程中，根據事先訓練好的model，賦予每種視頻特征以不同的權重，對每一種畫面都生成一個評分，最終以均值算法進行歸總，算出該視頻的最終評分。
• VMAF計算出的分數范圍是0 ~ 100，其中0表示最低質量，100表示最高質量，后續對比的時候只給出分數。

2.2 主觀標準

客觀標準固然重要，但是視頻是給人看的，最終視頻的質量好不好，還需要用戶主觀感受。換言之，兩個視頻的VMAF可能相近，但是用戶觀感可能會不一樣，有些用戶喜歡柔色，有些用戶喜歡暖色。

主觀標準操作起來比較簡單，找幾個視頻，讓用戶觀看之后主觀給出評價，視頻A和視頻B的質量對比如何，這種輸出的結果比較準確，但是工作量比較大，不好大范圍推廣。所以根據項目要求，在特定的時候采用客觀評價標準，在某些場景采用主觀評價標準。

例如下面兩張圖片，它們的VMAF值是相近的，但是第二張看上去明顯比第一張畫質好多了，而且更加明亮，這并沒有改變圖片的編碼結構，只是對畫面本身進行一些調色處理（這個我們下面會單獨拎出來講），就能明顯提升主觀感受。所以評價視頻質量需要綜合主觀標準和客觀標準綜合來判斷。而且我們建議在有條件的情況下，主觀標準更加重要，因為客觀標準只是模擬人眼的視覺系統，和真實的場景還是有所差距。

三、基礎優化

通過上面的描述我們基本了解了視頻質量的評價標準，但如果要提升視頻質量，這些還不夠，我們還需要介紹一下視頻的基本屬性，以及這些屬性可以在多大程度上影響視頻的質量。

我們首先使用MediaInfo來查看一下視頻的屬性，由于重點關注畫質，所以就自動忽略封裝格式和音頻流信息，只關注視頻軌道信息：

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L3.1
Format settings                          : CABAC / 4 Ref Frames
Format settings, CABAC                   : Yes
Format settings, Reference frames        : 4 frames
Codec ID                                 : avc1
Codec ID/Info                            : Advanced Video Coding
Duration                                 : 2 min 41 s
Bit rate                                 : 634 kb/s
Bit rate mode                            : CBR
Width                                    : 960 pixels
Height                                   : 540 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 25.000 FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.049
Stream size                              : 12.2 MiB (94%)
Writing library                          : x264 core 148
Encoding settings                        : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=17 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=75 / keyint_min=7 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=26.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=800 / vbv_bufsize=1600 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00
Codec configuration box                  :

其中有幾個非常重要的屬性需要特別關注一下：下面我們列出的各個屬性都是基于其他條件不變的情況下，只改變當前屬性。例如談Profile，就要保證其他的屬性是相同的，只有Profile不同，這樣比較視頻的畫質才有意義。

3.1 Profile

Profile對應上面的是Encoder Profile Level，正常情況下，Profile Level有三種類型：

• Baseline Profile
• Main Profile
• High Profile

其中Baseline Profile對應清晰度最低，Android 3.0之后的版本都支持的，Main Profile清晰度比Baseline Profile清晰度要好，但是從Android 7.0之后才支持，High Profile清晰度最高，也是從Android 7.0之后才支持。我們在設置Encoder Profile Level之前，需要判斷一下當前是否支持。

3.2 Bitrate碼率

視頻碼率是視頻數據傳輸時單位時間內傳送的數據位數。單位是kbps，望文生義，碼率越大，單位時間填充的數據就越多，視頻質量就越高。

碼率并不是越大越好，碼率設置超過一定的大小，對視頻畫質的提升已不太明顯，肉眼已經看不出區別，但是視頻大小會增加很多。所以設置合適的碼率就行。通常建議的碼率計算方式是：

Bitrate = width * height * frameRate * factor
factor = 0.15

按照上面的公式設置的碼率是比較合適的，當然如果想要更加高清的，可以適當增加factor大小。

3.3 Bitrate Mode

碼率雖然設置了，但是碼率是描述一段時間的平均傳輸的數據位數，無法保證每一個時間段內傳送的數據大小是固定的或者在一個固定的范圍內。還有一個Bitrate Mode參數來表示碼率模式。它也有三種類型：

• VBR：可變碼率（Variable Bitrate）, 此編碼方式會根據幀間數據的變化量大小來動態調整碼率，如果幀間的運動變化比較大，調高碼率，如果幀間的運動變化比較小，調小碼率。從編碼方式就可以看出來，這樣的編碼方式有兩個缺點：（1）運動預測計算算法有一定的耗時，編碼時間較長；（2）碼率多變，最終生成的文件大小不可預測。可能很大也可能很小。
• CBR：固定碼率或者常數碼率（Constant Bitrate）, 這是默認的編碼方式，使用此編碼方式，文件從始至終的編碼碼率會固定不變或者基本不變。這種方式的好處是文件大小是確定的，不會出現文件大小不可預測的情況。但是缺點也很明顯，有時候幀間變化比較大，有時候幀間變化比較小，如果都使用同樣的碼率，幀間變化比較大的時間畫質會比較一般，幀間變化比較小的時間顯得浪費。無法做到較好的平衡。
• ABR：平均碼率（Average Bitrate）, 平均碼率較好地兼顧了VBR和CBR的，在幀間變化比較大的時間使用較大的碼率，在幀間變化比較小的時間采用較小的碼率，最終保證整體采用的碼率固定就可以了。較好的處理了畫質和文件大小之間的矛盾。

但是很可惜的是MediaCodec并不支持ABR，我們如果想采用ABR模式的話還需要使用軟編碼。MediaCodec也提供了三種模式：

BITRATE_MODE_CQ：這種模式是全面考慮視頻質量，盡可能保證視頻質量，所以編碼出來的視頻都很大，并不可取。

• BITRATE_MODE_VBR：同上面的VBR
• BITRATE_MODE_CBR：同上面的CBR

眾所周知，硬編碼速度要遠遠快于軟編碼，所以編碼都是優先采用硬編碼，硬編碼失敗再采用軟編碼兼容。所以硬編碼MediaCodec建議采用BITRATE_MODE_CBR模式，切換到軟編碼采用VBR模式。

3.4 B幀設置

視頻由I幀、P幀、B幀 三種類型的視頻幀組成的。

I幀是幀內圖像幀，就是關鍵幀，意思是此幀不需要依賴其他的幀就可以進行編碼或者解碼。

P幀是前向預測圖像幀，此幀需要參考在它之前的I幀或者P幀，采用運動預測的方式進行幀間編碼或者解碼。P幀大小相當于I幀大小的1/10 ~ 1/20。

B幀是雙向預測圖像幀，此幀需要參考在它之前的I幀或者P幀，也需要參考在它之后的I幀或者P幀，采用運動預測的方式進行幀間預測編碼或者解碼。

GOP表示兩個I幀之間的圖像幀序列，GOP=2s，表示兩個I幀之間的間隔是2s。

Android平臺只有高通部分芯片支持B幀編碼，并且Android系統也沒有開發設置B幀的接口，所以對使用Android MediaCodec編碼的開發者而言，無法開啟B幀編碼（iOS是可以的，暗自垂淚）。當然軟編碼是可以設置B幀的。

設置B幀有什么好處？

B幀大小約是I幀大小的1/50，如果設置了B幀了，并不會降低清晰度，但是可以大大降低視頻的大小，這樣我們就可以相應地調大碼率，最終實現了提升清晰度的目標。

當然設置了B幀之后，增加了編碼和解碼的復雜度，這點開發者在設置的時候必須要有充分的認識。

四、HEVC編碼

目前H.264編碼還是使用最廣泛的編碼方式，主要還是H.264編碼的兼容性比較好，而且免費開源。HEVC自從2013年第一版發布開源出來，還沒有完全替代H.264（主要原因是收費，而且部分機型可能不支持），不過HEVC憑借其獨特的優勢也得到了較多地應用。

HEVC相對H.264的優勢：

• HEVC標準視頻的幀內預測模式支持33種方向，并且提供了更好的運動補償處理和矢量預測方法。而H.264只支持8種。
• HEVC采用了塊的四叉樹劃分結構，采用了8x8 ~ 64 x 64 像素的自適應塊劃分，而H.264每個宏塊的大小都是固定的16 x 16像素，HEVC的這樣設計可以保證在不同的幀間和幀內復雜程度中可以動態調整宏塊的大小，經過測試發現，在相同的圖像質量下，HEVC編碼的視頻比H.264編碼的視頻約減少40%，換言之，如果HEVC和H.264碼率相同，那么HEVC編碼的視頻比H.264編碼的視頻要清晰地多。

上圖可以看出同樣的視頻幀，HEVC使用的宏塊比H.264要少很多，體現了HEVC的優勢。

我們在使用MediaCodec HEVC硬編碼時，需要判斷一下當前是否支持HEVC編碼，Android 5.0已經支持了HEVC，不過一些低端芯片可能還是沒有支持HEVC，我們在編碼之前需要判斷一下是否支持。

使用HEVC編碼，可以保證在不增加文件大小的情況下，大大提升視頻的清晰度。

上圖是H.264編碼，下圖是HEVC編碼。

五、色彩調優

上面的幾種優化方式都是在編碼層面調整參數或者直接改變編碼方式來提升視頻的畫質，但有一種方式通過調整視頻畫面的色值——綜合調整亮度、對比度、色溫、飽和度、銳度等顏色參數，進而優化整體的視頻畫面，讓視頻畫面看上去“更清晰”。

我們經常用到的顏色空間有RGB顏色空間、HSV顏色空間、YUV顏色空間還有CIELab顏色空間，其中RGB顏色空間使用的比較廣泛。如上圖，圖像分為三個通道量：R分量、G分量、B分量，每個分量的值是0 ~ 255，三個分量共同組成一個顏色的RGB值。RGB分量的值分布構成了顏色色值的直方圖，我們通過調節RGB值來調節圖像的顏色。

有幾種對顏色色值的調節方式，對我們理解顏色調節有很大的幫助：

• 亮度：亮度表示人眼對發光體或被照射物體表面的發光或反射光強度實際感受的物理量，簡而言之，RGB分量越大，圖像就越亮；反之，圖像越暗。
• 對比度：圖像對比度是指圖像中從黑色到白色漸變的層次反差或比值。反差越大，比值越大，從視覺上感知，圖像就越清晰醒目，對比度越大；反差越小，比值越小，從視覺上感知，圖像越不清晰醒目，蒙塵感越強，對比度越小。
• 色溫：色溫和溫度還真有一定的關系，表示絕對黑體從絕對零度開始加熱之后呈現的顏色。從我們生活中來看，暖色調看上去比較溫馨，冷色調感受上有點清涼。
• 飽和度：飽和度是指色彩的鮮艷程度或者純度。飽和度越高，圖像色彩越鮮艷，色彩純度越高；反之則越低，直至灰度圖。
• 銳度：銳度主要用來表示圖像邊緣的對比度，由于人類感官，高銳度的圖像看起來更加清晰，圖像上的細節對比非常明顯。

我們可以將上面五種調節方式綜合起來調節圖片色彩。

• 亮度增加10個點（-100 ~ 100）
• 色溫增加5個點（-100 ~ 100）
• 飽和度增加20個點（0 ~ 100）
• 銳度增加15個點（0 ~ 100）

第一張是原圖，第二張是經過顏色調節之后輸出的圖片。

六、超分算法

上面提到的優化方式無論從編碼層面，還是從顏色調節層面，都算是基本的優化方式，近年來，隨著機器學習的火熱，超分算法越來越廣泛地應用到圖像和視頻處理上來。超分辨率就是指通過機器學習地方式重建圖像，達成提升圖像分辨率的效果。

目前比較成熟的超分技術是Real-ESRGAN，基于BasicSR，采用ESRGAN算法，利用機器學習的優勢對圖片和視頻進行去模糊、Resize、降噪、銳化等處理，重建圖片，實現對圖片的超分辨率處理。

E-SR-GAN算法的三個步驟：

• 特征提取：計算噪點
• 非線性映射：放大，模糊化噪點
• 圖像重建：差分，平滑過度，去噪

相對之前的SRCNN等超分算法，改進了如下幾點：

• 改進感知損失，提高輸出圖像的邊緣清晰度和紋理真實性。
• 利用對抗網絡的優勢不斷反饋改進GAN判別器，預測高分辨率圖像和原始圖像之前的相對真實性而不是絕對真實性?？梢曰謴驮紙D像的真實的紋理細節。
• 優化了模型的穩定性，每次生成的圖片都和原圖片殘差對比，進行矯正訓練，最終得到的結果非常穩定。

下面是超分前后的對比結果：大家可以點擊大圖對比一下細節，可以看出超分之后的圖片精細化很多，去掉模糊的地方、降低圖片的噪點。

七、總結

本文結合當下視頻的痛點（清晰度問題），提出衡量視頻清晰度的標準——主觀標準和客觀標準，指明了視頻清晰度的優化目標和方向，根據視頻的基本特征（碼率、GOP、編碼模式等）提出基礎優化的方法，在基礎優化的基礎上提出高級編碼方式（相對H.264編碼方式），再結合目前主流的視頻色彩濾鏡提出視頻色彩調優方案，讓視頻看上去更清晰。最終的大殺器——超分算法采用E-SR-GAN方式進行放大、降噪、重建幀來提升視頻清晰度。希望上面這些方法可以給大家帶來一些幫助，對提升視頻清晰度有更進一步的思考。

參考文章：

VMAF開源項目 https://github.com/Netflix/vmaf

揭秘 VMAF 視頻質量評測標準https://xie.infoq.cn/article/26aaf2ab83f56192a65ba22ea

Netflix VMAF 視頻質量評估工具概述https://zhuanlan.zhihu.com/p/94223056

B幀對視頻清晰度/碼率的影響https://blog.csdn.net/matrix_laboratory/article/details/82726897

H264 vs H265https://www.cnblogs.com/wujianming-110117/p/12640533.html

超分開源項目https://github.com/xinntao/Real-ESRGAN