记得入行的时候，主流的视频都是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倾斜
儿子吵着要睡觉了,咱们下回再续哈,谢谢理解.