短视频市场如火如荼，TikTok、抖音等短视频产品一骑绝尘

是否设想有朝一日你会参与到流媒体、OTT 产品研发当中

在风口上跳舞

如果客户希望帮助实现一个视频播放服务，该怎么做？

大概率开始会这样想： 把视频通过 CDN 加速网络暴露出去

这个方案虽然简单，但会带来如下的挑战

• 一个高质量的源文件通常尺寸非常大，需要很长的时间来下载。

• 播放器的 UI 尺寸通常不是固定的，而是响应式的，需要能够随着设备类型和屏幕尺寸的变化而变化，单一视频源会带来不好的用户体验

• 当用户停止观看或跳过部分片段时，大量昂贵的网络带宽会被浪费。

解决如上问题的思路是，生成具有不同比特率的原始媒体的多个渲染。通常称为编码或转码的过程。根据所选的编解码器和配置，源文件可以转换为一系列不同质量和大小的单独输出。每个渲染可能被分解成相同长度的片段，称为段或片段。使用 HTTP 范围请求允许请求和下载一个文件的特定范围，每个单独的范围允许独立的渲染。

如下图所示

上面的思路正是流（Streaming）定义的主要内容

把思路拆解一下，得到下图

• PlayList：流媒体协议（DASH、HLS)、规范清单或播放列表的使用、同步，以及如何将媒体片段传递给播放器。

• Container:  媒体容器 (TS, MP4, CMAF, 等)，将底层媒体（视频、音频、字幕等）包装成可由播放器渲染的单个片段或碎片。

• Encryption:  加密层（AES-128)，为编码器提供了一种加密底层媒体的方法，并让播放器在渲染前检索有效的密钥并解密内容。

• Codec:  编解码器  (AVC, HEVC)，决定实际视频数据如何被压缩并在设备表现出来。

列举两个比较有代表性的 Streaming 流协议

HLS， 由苹果公司在 2009 年发布，目前是市场的领导者。它的栈构成为

•  .m3u8 清单文件

•  TS 媒体容器

•  CBC-based 加密算法 

•  H.264/AVC 加解码协议

3 年后，由 Google, Microsoft, Adobe 等一梯队企业联合发布 MPEG-DASH，与传统的 HLS 相比有一系列改进，旨在被采纳为流媒体的新全球标准。它使用

• .mpd 清单文件，

• 零散的 MP4 容器

• AES-128 CBC 或者 AES-128 CTR 加密算法 

从此，Streaming 天下一分为二。

如果客户还希望你能够保护视频的数字内容版权，该怎么做？

DRM 能帮忙！

数字版权管理（DRM）是指保护一个组织的数字媒体免受未经授权的使用，确保公司对数字内容的传播保持控制。并通过控制访问并将其限制在授权用户范围内来保护敏感和机密信息。

它使用各种方法和技术来实现这一目标，包括：

• 限制或阻止用户编辑、保存、分享、转发或打印内容

• 对某一特定作品的复制数量设定限制

• 防止用户对数字内容进行截屏

• 设置失效日期，在此日期之后用户不能访问数字内容

• 按地区控制对数字媒体的访问

• 为内容打上水印以验证真实性和所有权

下图展示了在 Streaming 流媒体当中实现 DRM 行业最佳实践方案

加密视频，保存到 CDN

• 向 DRM 公司的 License Server 索取密码

• 使用该密码本加密视频，电影被编码成不同的比特率分辨率组合，然后分成 块或片段。每个块代表几秒钟的视频，并且可以独立解码，并且生成 Manifest 文件和 Video Segments 文件

• 将加密和 Video Segments 和 Manifest 文件保存到 CDN.

客户端获取解密 License、解密视频

• 播放器从 CDN 获取电影及其清单

• 从清单中提取 KeyID

• 创建许可请求

• 将许可请求发送到许可服务器

• 等待、收听并接收来自许可证服务器的响应。

• 使用来自服务器的解密密钥来解密内容

• 解码解密的内容

• 显示解码的电影

注意： 在基于 DRM 的流媒体中，内容密钥绝不会直接暴露给任何用户。相反，视频文件附带的头文件包含有关所用 AES 加密机制的元数据。视频元数据由浏览器/设备中的一个软件使用，称为内容解密模块 (CDM)。

市场上存在三种主要的 DRM 技术，Apple FairPlay、Google Widevine 和 Microsoft PlayReady。

如果一个客户决定与三个不同的 DRM 公司合作，而这三个公司都使用不同的加密技术，那么这意味着内容提供商需要对他们的视频进行重复加密，从而导致存储空间和其他资源的浪费。该怎么解决呢？

重复加密的原因是因为 FairPlay 支持 HLS，所采用的媒体容器和加密协议与 Dash 一簇产品 Widevine、PlayReady 是不一样的。

为了解决重复加密的问题，HLS 和 DASH 相互妥协、提出了 CMAF。CMAF 创建的目的是成为通用的流媒体容器，可以在所有现代设备上进行渲染，而不是为 HLS 生成 TS 段，为 DASH 生成 fMP4 片段，一个单一的 fMP4（容器）渲染集可以在 HLS 和 DASH 播放列表中被引用。

是否有一个更高效的服务来集成各个 DRM，而不需要去单独和每个 DRM 系统集成。

Iredto 提供了解决方案、多 DRM 解决方案 Iredto Control 结合了基于云服务的软件产品，使媒体品牌（例如，付费电视运营商、工作室、体育权利持有人、视频流应用程序等）能够在一系列设备中通过执行各种 DRM 技术的安全有效的 DRM 许可证配置分发和保护其内容器

总结

到此、我们解决了客户关于流媒体服务、数字版权实施的两个问题。是不是感觉可以可以大展拳脚啊，别高兴太早，这里面会有好多坑等着你呢。

举个例，考虑产品和客户端迭代升级不一致的情况，实际情况当中不仅仅要支持 HLS 和 DASH, 同时还需要支持 CMAF Drm,  ​​​​​如果遇到了，那就自求多福吧，CMAF 并没有帮助统一，恰恰相反，它带来的是需要更多的源来支持。

好方案并不一定在当下会呈现一个好的结果。

关注我

Marvin Ma - 程序员、技术顾问、编程教练

[原文出处] http://mentorfinder.cn/marvin/