在 偏差——人类决策中的陷阱 一书的 谨小慎微的选择，大胆无畏的预测 这一章节中说道：

如果一个项目的倡导者处于接近组织层级最顶端的位置，那么他的建议、预测和假设就不会受到太多的审查。

相反，由更基层的员工提出的小规模项目缺必须克服重重障碍，在得到批准之前要经受多层审查。

如果你所在的项目由处于接近组织层级最顶端位置的人发起，那么恭喜你进入了一个明星项目，你所获得的收益也会因为明星项目的快速发展而与众不同。

谁不想做明星项目呢？

但是，明星项目的数量总归是有限的，其所能承载的团队成员的数量也是有限的。当我们处在一个普通项目的时候，我们又如何才能突破资源的限制，创造出更大的价值？

在视频处理中，我们经常会用到不同的色彩空间：非线性RGB，线性 RGB，YUV，XYZ……为什么需要这么多的色彩空间呢？为什么在 FFmpeg 中会有 color_space，color_transfer，color_primaries 等一系列的颜色属性呢？这些术语之间究竟隐藏着什么秘密？

引言

我们的平台有一个算子用于计算给定视频的音视频流的码率，该算子底层通过调用 ffprobe 来计算音视频的码率。

1
2

ffprobe -select_streams v:0 -show_entries stream=bit_rate \
-of default=nokey=0:noprint_wrappers=1 'video_file'

此时，得到的 bit_rate 的单位是 b/s，为了方便，我们把该码率转换为了 Mb/s：

1

bit_rate = bit_rate / 1024 / 1024;

忽然有一天，我们的用户反馈，平台返回的码率结果和 ffprobe 的结果不一致。具体表现如下所示：

1
2
3

Stream #0:0(und): Video: hevc (Main) (hvc1), 3492 kb/s, ...
    ...
bit_rate=3492451 ==> 3.33 Mb/s

平台返回 3.33 Mb/s x 1024 = 3410 kb/s，而 ffprobe 返回的则为 3492 kb/s。

因为工作原因，最近经常要分析一些数据，这些数据的格式不规范，并且数据量级不大——大概在 1W 左右。

一开始，我是不屑于使用 Excel 来处理的，总想着写个程序来完成处理。后来，我发现，我的想法是多么的愚蠢，因为我发现，Excel 简直是太强大了，完全满足了我的各种需要。还好我及时纠正了自己愚蠢的想法，否则我现在还在忙个不停的调试自己的那些代码。

本文把自己使用 Excel 进行数据分析过程中学习到的小技巧进行了梳理总结。

作为视频业务，经常需要：

• 对比不同的视频，从而确定哪个视频的画质更好，以便可以为用户带来更好的体验。
• 对比不同编码参数生成的视频，以便确定在哪些配置下产生的视频能带来最好的体验。
• 对比不同产品的视频画质，以便做到知彼知己，并在对比之中带来较好的用户体验。

数字视频在处理、存储和传输上需要大量数据，典型的 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，进而引起了计算超时。