2016年被稱爲“中國網絡直播元年”，網絡直播已成爲網絡文化領域重要的經營模式和文化市場的重要組成部分。而以“直播造人”事件爲節點，直播行業進入了嚴格規範化的時期，鑑黃、版權保護越來越受到直播行業的關注。在這樣的背景下，2016年4月，北京網絡文化協會發布了《北京網絡直播行業自律公約》，規定網絡直播房間必須添加水印。對於直播行業的工程師而言，直播流添加水印成爲了必備技能。筆者曾在寶利通，邁能半導體從事avc、hevc編解碼開發工作多年，現在任網心科技高級工程師，負責星域CDN轉碼相關工作，在此分享一些粗淺的經驗，希望對大家有所幫助。
傳統水印添加技術的4大坑
在直播視頻流中添加水印，最簡單的方法是推流端直接添加水印並編碼推流。然而這需要直播企業規範自己旗下所有的主播在直播時都必須添加帶有自家標識的水印logo，而且需要公司投入一定的研發力量去修改推流工具實現加水印技術。從具體操作和研發上存在一定的難度，因此很多直播企業會對接入自家的CDN廠商提出直播流加水印的需求。
在已經編碼的視頻流中加水印，就需要把壓縮視頻流解碼爲原始視頻格式，疊加水印圖片到視頻中的某個固定區域，然後重新編碼推送出來，因此要實現直播流加水印就需要用到視頻轉碼技術。而提到視頻轉碼技術就不得不提到兩個開源工程：ffmpeg和x264。ffmpeg強大完善的流媒體處理和x264高效高性能的視頻壓縮能力以及H.264格式在市場中的廣泛應用使得它們的組合成爲大多數流媒體工程師在轉碼時的不二選擇。添加水印也不過是ffmpeg在命令行的一組命令而已，幾個視頻濾鏡加x264的幾個編碼參數就可以很方便的在直播流中加入水印並轉推出去。
然而對於CDN廠商來說這真的是很好的做法嗎?其實不然，用ffmpeg做轉碼是一種全解全編的方式，即把直播視頻流完全解碼爲原始視頻，然後對疊加水印的視頻用x264重新編碼，這麼做存在以下幾個缺點：
1、 源流視頻的gop結構被改變。如下圖所示，直播客戶對於直播延遲和視頻流質量要求不盡相同，各家採用的視頻編碼器不同或者編碼器採用的參數不同，導致源流的gop結構不盡相同，從CDN廠商的角度，源流的gop結構是難以從程序的角度判斷的，對各家客戶做差異化處理也存在較大的困難，而統一用相同的編碼參數做轉碼則破壞了源流的gop結構，使得轉碼之後的水印流在延時數據上發生改變，有可能達不到客戶的要求。
轉碼前的幀序列
轉碼後的幀序列
2、 碼率無法與源流完全保持一致。目前直播推流大多采用rtmp協議或者http協議傳輸flv的方式，源流碼率往往會寫到flv的metadata中。然而在實際的應用場景中，由於客戶使用的編碼器各不相同，flv或者rtmp流的metadata中可能並沒有視頻碼率的數據，或者根本是一個錯誤數據，由於目前直播流大多數都採用abr的方式，碼率是在實時變化的，這種情況下監控源流碼率並通知編碼器實時作出改變也是非常困難的。即便metadata中的碼率是正確的，但是abr碼率控制模式還需要峯值碼率參數，同時前邊提到由於gop結構完全被改變，輸入輸出視頻的同一幀可能使用不同的幀類型，使得轉碼流與源流碼率時刻保持一致也是不可能的。
3、 源流視頻質量存在損失。源流質量的損失主要來自於兩個方面：
(1)gop結構發生改變。編碼器在編碼時考慮到不同幀類型的重要性不同，爲了提高視頻流的整體質量，通常會給I幀分配較小的QP參數以保留較高的圖像質量，P幀次之，B幀分配較大的QP參數，圖像質量相對來說最差。而經過轉碼後輸入輸出視頻的同一幀可能使用不同的幀類型，源流的I幀可能變爲P幀甚至B幀，原來的P/B幀可能被轉碼流用作I幀，從而損害視頻流的整體質量。
(2)二次編碼損失。轉碼後圖像重新進行編碼，每個宏塊重新進行模式選擇、運動估計和量化，使得編碼後圖像質量下降。
4、 視頻轉碼的計算量太大，對轉碼集羣的投入會非常高。全解全編的視頻轉碼方式所需要的計算量是非常大的，一路1080P30，3mbps的碼流可能需要3到4個核進行處理，如果客戶所有的流都需要加水印處理，相當於所有的源流都要做轉碼，需要對轉碼集羣投入大量的服務器做運算，成本大幅增加不說，高負載下直播流的卡頓率也有可能大幅上升。當然有些廠商可能會採用GPU或者FPGA專用硬件的方式來做轉碼，雖然可以緩解轉碼服務器負載，然而成本也是非常高的，而且也避免不了之前的三個問題。
僅僅爲了疊加一塊小小的水印圖片，需要用到這麼高的計算成本，而且可能只是取得一個差強人意的結果，恐怕再也沒有比這更費力不討好的業務了。難道爲了一塊小小的水印就必須要把整個視頻全部重新編碼?就不能只對水印區域重新編碼嗎?
優化方案：在保證圖像質量的前提下大幅提高編碼速度
由於目前市場上絕大多數的視頻流都是用H.264標準編碼的，熟悉H.264的人應該知道，與之前的編碼標準如MPEG-2、H.263相比，H.264在很多編碼技術上都是高度依賴上下文的，如幀內預測，mv預測，甚至殘差的熵編碼，前邊宏塊的編碼模式或者殘差發生改變，都會影響到後邊宏塊的編碼，這麼看來似乎還真的要把整個圖像重新編碼一次。
當然，H.264也的確有些辦法把某些區域隔離開來，比如按照宏塊raster scan的順序，把包含水印的區域部分作爲一個slice，不包含水印的區域作爲一個slice，不同的slice之間編碼是完全獨立的，不可以互相參考，這樣可以在轉碼時只把包含水印的slice重新編碼。另外H.264可以採用slice group技術，其中一種模式是把圖像分爲fore ground和back ground兩個slice group，不同的slice group之間編碼也是完全獨立的，水印部分可以放在fore ground這個slice group裏。但無論哪種方式，都是要在推流端事先配置好編碼參數的，slice group技術很多H.264編碼器並不支持，所以需要直播企業開發專門的編碼器來支持這種場景，同時也需要跟主播約定好推流時的參數，如果這樣，那不如直接在主播推流時直接加上水印再推流更來得方便，因此這種方法並不可行。
在視頻轉碼領域，利用源流解碼信息加速編碼器決策，在保證圖像質量的前提下大幅提高編碼速度是一種比較常用的方法，而加水印的業務場景則非常適合使用這一方法。我們可以只對水印相關的宏塊重新編碼，即只對水印區域覆蓋的宏塊和參考了水印區域的inter宏塊重新做模式選擇和運動估計，而其他與水印區域不相關的宏塊則可以使用原有的編碼模式、運動矢量和量化參數QP等等。由於水印圖片通常只佔視頻中很小的一部分，這樣大部分宏塊都不必重新做模式選擇和運動估計，既可以節省大量無謂的計算，又可以保證加水印流的幀類型與源流完全一致，碼率非常接近源流，對圖像質量也幾乎沒有任何損傷，連編碼器的碼率控制模塊(RC)都可以去掉。
當然要實現這樣的策略，開發量還是不小的，難點也很多。
首先我們需要重新開發編解碼器，使得編解碼器之間使用完全一樣的數據結構來保存同類的宏塊信息，如宏塊模式、運動矢量、QP等等，這樣纔可以方便的在解碼器和編碼器之間傳遞和共享編碼信息。
需要傳遞的信息可分爲序列級、幀級(或者slice級)和宏塊級，如下圖所示：
解碼器到編碼器的信息傳遞
其中最複雜的一步，是宏塊級解碼信息的傳遞，包含前邊所說的宏塊模式、運動矢量等信息，因爲源流的這些信息是經過了推流端編碼器決策之後選擇的，可以認爲對當前圖像就是最優的選擇，除了水印區域相關的宏塊，其他的宏塊都可以拿來直接進行編碼。
下面三幅圖是新舊加水印法對某一幀測試視頻加水印前後的模式和mv信息圖，第一幅圖是原始測試視頻，第二幅圖是完全轉碼加水印的視頻，第三幅圖則是改進後的加水印方法得到的視頻。
原始測試視頻
完全轉碼加水印的視頻
改進方法加水印的視頻
通過對比可以看出改進的方法完全基本使用原有的編碼信息來生成水印視頻，而原有的完全轉碼方式得到的視頻跟原有視頻相比則變化非常大。
然後要進行水印區域相關的宏塊的二次編碼，這部分宏塊由於視頻數據發生了改變，需要編碼器重新決策以選出最優的模式和mv信息。這部分的工作包括水印圖片覆蓋區域的宏塊和參考了水印區域的inter宏塊位置的確定以及編碼器宏塊模式選擇所需要的初始化過程。
此外，實現這種加水印方式的最大難點在於源流的不確定性。由於H.264編碼規範支持的編碼特性非常多，如果源流中包含自己編碼器所不支持的特性，編碼時則會在輸出流中出現花屏甚至導致程序崩潰，因此一方面需要編碼器儘可能支持更多的編碼特性，另一方面在遇到不支持的編碼參數時能夠識別出來並回退到普通的完全轉碼加水印的方式來更完善和穩定的支持線上的業務。
實際應用：
通過對三種類型遊戲的流：英雄聯盟，穿越火線，守望先鋒分別進行測試，測試機器環境爲24核cpu：E5-2630 v2 @ 2.60GHz。在解碼器編碼器都只開一個線程的情況下性能數據如下表所示：
優化後轉碼的性能基本提升了一倍左右，其中英雄聯盟性能提升最小，守望先鋒提升最多。究其原因是因爲英雄聯盟畫面變化和運動劇烈程度相對是最小的，而優化完的水印程序對運動劇烈碼率較高的流改善最爲明顯，所以穿越火線和守望先鋒這種fps遊戲改善最爲明顯。
此外對不同幀率的流進行測試，發現隨着視頻幀率增加，視頻獲得的性能增益逐漸下降，因爲幀率越高的情況下一方面本身需要更多的計算，另一方面相鄰幀之間的相關性增加，使得幀間的變化越來越小，所能取得的增益自然會下降。
在測試機器環境下，線上絕大多數流用兩個編碼線程即可滿足要求，少數高碼率高幀率的流，三個線程可以確保滿足要求。
再來看輸出水印流的圖像質量對比，測試用例還是上述的三個遊戲視頻，結果如下表所示：
可以看到優化後圖像質量有了非常明顯地提升，結果符合算法的初衷。
利益相關：同事（Sean 王）的一些觀點
原文在此：http://geek.csdn.net/news/detail/131071?from=groupmessage&isappinstalled=0