記得入行的時候，主流的視頻都是VGA(640x480)的，HD覺得都很高，到今天從芯片的能力的角度，8K甚至更好的視頻分辨率都已經不是問題，但在很多的領域（比如視頻監控）1080P仍然是主流，不是大家不願意到更高的分辨率，而是因爲更高分辨率帶來的高帶寬跟存儲成本是大家所承受不起的（相比較所獲得的收益而言）
以視頻監控領域爲例，目前大家的主流分辨率還是1080P，主流的帶寬基本控制在1 ~ 2Mbps, 各家提供的套餐基本也是以存留時間來劃分，基本都是一週左右的時間，所以如何以更低的bitrate來得到同等質量（或者說是不損害用戶體驗的）視頻成爲大家都關心的課題。
Codec的發展(MPEG2 -> MPEG4 -> H264 -> H265, VP8 -> VP9 -> VP10 …) 也是爲了解決這個問題，從做產品的角度，這些Codec都比較成熟，沒有太多優化的空間(否則JVT的那些專家都幹嘛去了)，這裏我想談的是基於一個成熟的Codec的前提下，如何從應用的角度來優化bitrate方案。
基本上各家SoC廠商也會提供一些solution，比如海思有SmartH26x+，Amba SmartRC …, 我這裏只是提供一些參考建議，算是拋磚引玉。
１. 最早優化方向：
- CBR: 直接將bitrate，簡單粗暴 降低幀率：可能影響流暢度，但對監控而言，更在乎的某一幀是否清晰，流暢度反而不是第一考慮因素
- 增大GOV Length：GOV越大，關鍵幀越少，同樣的bitrate, 質量會越好，但GOV如果太大，在live傳輸的時候，如果掉幀了，那所有後續幀都要丟掉，直到下一個IDR出現，當網絡條件不好的時候這會造成很糟的用戶體驗，當然有人可能會說force IDR，但一旦這樣做了，搞不好IDR會很多，quality會嚴重下降
- 引入B幀：引入B幀會降低bitrate，但會帶來幾十個毫秒的時延，對CVR無所謂，但live則不一定了
- Profile： High Profile > Main Profile > Baseline Profile
２. 進階版
考慮到監控需求，很多的監控場景特別是對於家庭的監控場景，很多的時候畫面幾乎就是靜態的，偶爾纔會有人出現，所以如果針對不同的場景做優化就很自然的出現了，其實這個想法一直都有，但10年前用的人很少，爲何？因爲CPU都不是太給力，我記得第一個做的DM365主頻才297MHz，算一個motion已經有點死去活來的，那會跑一個openCV裏面的高斯模型能把CPU吃完，後來CPU越來越給力，這個優化自然也就上臺面了，其實優化的思路都是一樣的，就是把豐收的年份的糧食省下來度荒年。
- 優化2-1：針對不同的場景設定不一樣的bitrate，靜態場景對bitrate的需求比較少，可以設定比較低，當detect motion的時候再把bitrate拉上去，至於設定幾個level，如何調整motion threshold，就是各家的祕密了
- 優化2-2：針對不同的場景設定不一樣的FPS，靜態的時候可以低一些，動態畫面可以高一些。極致的時候對static可能就是靜態的1幀數據，直到畫面有變化才傳輸或者存儲起來。
- 優化2-3: 針對不同的場景設定不同GOV Length，靜態的GOV可以適當拉大，動態的可以降低。
3. 強化版
基於進階版的基礎上做進一步的深度優化。
- 優化3-1：參考noise level調整zmv
- 優化3-2：基於不同場景設定不同的QP(Quality Parameter), QP range 1 ~ 51, 1 means best quality, 51 means worst. 基本上在靜態場景下：關鍵幀的QP的下限（對應的最好的quality）可以低一些（quality更好），P幀或者B幀的QP的下限可以高一些，講白了就是bitrate向關鍵幀傾斜，動態場景的時候可能就要平衡一下了
- 優化3-3：優化motion level的計算算法,必要的時候需要引入VA來判斷是否真是一個物體在動還是隻是干擾?
- 優化3-4: 基於一個準確的motion或者VA計算的基礎上, 動態調整ROI,把有限的bitrate資源向ROI傾斜
兒子吵着要睡覺了,咱們下回再續哈,謝謝理解.