解读针对您自身流媒体堆栈的编解码器专利索赔

想象一下，你收到一封律师函，上面写着”请您看一下这个？”打开之后，你会发现里面附有一张侵权比对表，声称你的服务侵犯了某项视频编码专利。这张比对表引用的是标准文档和厂商架构图，但没有引用你的源代码。而且除了你之外，从来没有别人看过你的源代码。

索赔要求到底在要求什么

编解码器专利权利要求的写法，多数时候类似于一份食谱：

把帧划分成块；
基于相邻块预测每一个块；
对残余的差值做变换；
在码流中放入一个标志，告知解码器发生了什么。

这些步骤中的每一个都是索赔的组成部分，也是其他一切赖以成立的基础。侵权，基本上意味着被指控的系统把这些步骤全都做到了。只要漏掉其中一个，整个索赔要求就崩塌了。在你继续读比对表的下一行之前，必须先记住这一点。

我们目前看到的大多数图表通常都走捷径，直接指向标准。其逻辑是：如果你实现了 H.265 或 AV1，你必然在做权利要求所描述的事情。当标准强制要求某一步骤时，法院接受这种论证；但当标准把该步骤留作可选时，法院对此类论证的态度就远没那么友好了。而真实的技术栈通常会跳过标准所允许的相当一部分内容，具体取决于 profile。预设（preset）和硬件限制也会造成同样的情况。我第一次读到这一点时的惊讶之处在于：一个被广泛使用的标准，并不自动意味着其中每个可选特性都被开启了。

编码器

这些论述大多以编码器为对象，所以我建议从这一项开始。此外，我们应该从真实的配置入手，而不是理论配置。拿到命令行参数或 API 调用记录，以及 ladder 定义。然后设法确定每个 preset 分别开启了哪些编码工具——因为这正是比对表在缺乏内部信息的情况下无法确定的部分。你肯定需要一些样本编码和日志。这是我得知某个更新改变了我们的输出、却直到查日志才明白原因的方式。

编码器的软件实现与硬件实现并不完全相同。跑在 CPU 上的软件 preset，与集成在云端处理器里的硬件编码器，在工具选择上会彼此不同。所以，一份没有把这一点考虑进去的比对表是有问题的。Preset 名称本身也不一定靠得住。某个版本里的”Fast”可能启用了某些工具，而下一版里的”fast”却没有启用它们。

首先，要弄清楚代码归谁所有。很多服务是授权使用编码器的，你可能根本打不开这些代码。所以你应当在早期就把这一点讲明。在回复任何人之前，先把合同读一遍。

封装器（Packager）

Packager 主要关心的是”打包”。它只负责把码流切分成块并生成 manifest。Packager 并不处理真正被编码后的视频数据。某些权利要求可以落在这一层，因为它们与信令（signalling）有关。参数集（parameter set）或 SEI 消息可能原封不动地穿过你的整条流水线。它是你生成的，还是你只是携带了它？区分这两者至关重要。因此，在做任何假设之前，最好先咨询法律顾问。显然，每个版本都应该保留一个样本分片。用码流分析工具打开它，看看里面到底有什么。只有真实文件才能平息那些仅凭架构图就会引发的争论。

播放器

我们都知道，解码器相关的权利要求指向播放器，所以要仔细考虑你实际交付的是什么。你手机里由另一家公司制造的芯片负责解码。你的应用请求播放视频，拿回来的是像素。但那些你在权利要求中列出的步骤，究竟是谁在执行？如果有多个实体分别执行这些步骤，法律上的常规做法是弄清楚谁指挥或控制了其他步骤的执行。而如果权利要求针对的是整个系统，常规做法则是弄清楚是谁把这个系统投入运行。在对这些步骤作出任何主张之前，先把权利要求中的步骤画成流程图。逐一识别权利要求中的每个技术特征。