数字视频在处理、存储和传输上需要大量数据，典型的 30FPS 的高清视频（1920x1080），如果每个像素需要 8bit 来表示的话，那么每秒需要大约 15亿 bit。而视频编码技术的目标就是获取码率和视觉质量之间的权衡。

1

1920 x 1080 x 8 x 3 x 30 = 1,492,992,000

在视频编码技术中，码率控制（Rate Control）是一件非常重要的事情。在编码视频帧时，码率控制决定了编码器为该视频帧分配的 bit 数。

本文将基于 FFmpeg 中的 X264、X265 编码器来介绍常用的码率控制模式。

我们天天在说“用户体验”，但是，用户体验究竟是个啥呢？是功能，是价值，是认知，还是感觉？怎么来衡量“用户体验”呢？虽然，有很多专业的书籍来解释“用户体验”，但是我还是想从另外一个角度来阐述一下自己对“用户体验”这一概念的理解。

引子

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

-- Martin Fowler

作为程序员，我猜，当看完这句话后，你肯定会觉得这句话是对的，但是不见得会由衷的信服这句话。我还猜，你一定在想，Martin Fowler 究竟是谁呀？

一直以来，我都在思考如下的问题：

• 新启动的业务是否值得花费时间来开展单元测试、接口自动化测等质量保证手段？
• 新启动的业务是否值得花费时间来践行持续集成等软件开发模式？
• 新启动的业务是否值得花费时间来设计架构、编写接口文档……?
• ……

我们有一个平台来周期性的对线上的直播流数据进行某些检测，例如黑/白屏检测、静态画面检测……在检测中，我们会根据提取到的直播流的帧率来预估要计算的帧数量，例如如果要检测 5s 的直播流，而该直播流的帧率为 20 fps，需要计算的帧数量则为 100。忽然有一天，我们发现，平台开始大面积的超时，之前只需要 2s 就能完成的计算，现在却需要 30+ 分钟。查了之后，我们发现，之所以计算超时是因为 OpenCV 计算的帧率为 2000，从而导致需要计算的帧数量从之前的 100 变为了 10000，进而引起了计算超时。

从 Google Chrome version history 可以知道，2011 年 3 月 发布的 10.0.648 版本的 Chrome 浏览器就已经支持视频的硬件加速能力。从 chromium/chrome 88 开始，视频的硬件加速已经成为默认配置。

即便如此，因为视频的硬件解码需要 GPU 的特殊支持，而目前的视频编解码标准又比较丰富，我们如何判断 Chrome 在解码视频的时候是否启用了硬件加速呢？

多年以前，我阅读了一本至今都让我受益匪浅的书：《你的灯亮着吗？》。工作中，我总会按照书中的内容来训练自己解决工作中遇到的问题。作为一名测试开发工程师，在定位 BUG 时，我也会用到该书中介绍的问题解决思维模式。

在这本书的第一章「这是谁的问题」中提到：

初出茅庐的问题解决者总是在还没有定义好问题的时候就仓促的给出解决方案。迫于外界环境的压力，经验丰富的问题解决者有时也耐不住性子。在这种情况下，尽管他们能找到很多方法来解决问题，但是不一定对症。

我们一直在孜孜不倦的追求解决问题的方法、策略、妙招，却从来没有仔细想过，问题究竟是什么？

我会经常浏览并借鉴很多开源项目的代码来完成自己的工作，有很多时候这种方法让我的工作效率非常高。阅读并借鉴开源项目的成果，让我得以站在巨人的肩膀上，使得我可以更高效的工作。

不知道你也是否和我一样？如果你也和我一样，那么我们是否思考过？我们在引用别人的代码完成自己的项目时，我们的项目是否变成了一个如下图所示的四不像呢？

利用 FFmpeg 的 drawtext 滤镜，我们可以把特定的文本信息绘制于视频之上。FFmpeg 的 drawtext 滤镜可以绘制的文本信息可以参见文档 Text expansion 中的描述。例如，我们可以把视频的帧号信息描绘在视频上：

1

$ ffmpeg -i test.mp4 -vf drawtext=text=%{n}:x=50:y=50 -y output.mp4

有时候，我们想绘制一些特殊的内容，比如：当前帧是每秒中的第几帧？这是一件有趣的事情，但是 drawtext 却没办法支持这种内容的绘制。在大多数场景下，我们几乎用户到这种特殊的功能，但是，如果遇到了，我们如何解决呢？