如何利用免版税视频流技术构建优质视频体验？

随着全行业及消费者对版权技术的越发重视，如何利用免版税技术在不受专利限制的影响下提供高质量的在线视频服务，成为当前所面临的最大难题。Mux流媒体专家Phil Cluff总结了其在探索免版税视频流技术过程中所做的一些工作，在LiveVideoStackCon 2019 上海音视频技术大会上，Phil Cluff将详细介绍《视频API的发展》。

文 / Phil Cluff

译 / 咪宝

审校 / John

原文：https://mux.com/blog/streaming-video-on-the-internet-without-mpeg/

作者注：本文基于我所参与的一系列为探索利用免版税视频流技术构建优质视频体验的可行性而进行的实验。 在Mux我们使用多种技术帮助客户尽可能多地接触用户，然而随着全行业与消费者愈发重视技术版权，为便于互联网用户制作个人视频流，积极探索免版税视频技术成为摆在我们面前的关键问题。

互联网基础应当建立在不受专利限制的开放技术之上，但当我们在互联网上观看视频时所面对的情形却截然不同。绝大多数情况下，在线视频的产业链仍有相当一部分依赖于受专利保护的技术，其中大部分是MPEG组织开发和许可的。

而最近随着免费视频编解码器AV1的异军突起，我们最终是否会迎来一个转折点，可以在不受专利软件限制的情况下在线观看视频?

也许是的，但当我们谈起在线视频流媒体生态系统时需要知道，其背后不仅仅只是一个视频编解码器。

目的

我认为无版权视频技术的挑战是基于“开源”的视频技术为尽可能多的消费者建立一个优质的视频流访问体验。这里的“开源”主要是指：

1、我们所用的技术不应受软件专利的限制。

为什么我们所用的专利技术十分重要？因为专利代表着金钱与风险。使用MPEG的H.264（AVC）和AAC等技术需要向MPEG许可机构支付专利授权费；而近年来随着HEVC（H.265）授权情况的不确定性，专利授权费用有逐渐增加的潜在可能。结合MPEG DASH专利池的那些受版权保护技术正推动人们寻找在版权问题上更加友好的替代选择。

专利技术授权过程所面临的最大挑战之一是如何准确了解交付链中有哪些人应当在什么时间支付许可费。这是一件难以全面解释的复杂命题（IANAL）。

2、我们使用的软件技术应该被公开透明地开发。

虽然这一点对我来说并不是最重要的因素，但我还是希望自己能够为一项工程的推进贡献一些力量，与他人合作并了解他们的需求从而共同推动行业所用的标准与软件的升级。

组件

当我们思考如何构建理论上的交付技术堆栈时，我们必须关注一些可以利用开源技术的关键领域：

1. 编码器

2. 编解码器

3. 数据容器

4. 传输技术

5. 播放器

我不会花太多时间谈论编码器，因为现有的视频编码器已经非常灵活，足以满足现有需求。

编解码器

我们必须基于现有流媒体视频技术栈，找出最适合的视频和音频编解码器。新的编解码器重新定义了我们系统的有效覆盖范围，正如我们常说的那样，对开放视频和音频代码的支持是灵活多变的，但面对不同编码器之间客观存在的差距我们需要根据应用场景及时变通选择策略。

首先，让我们把现在互联网上较为常见的视频与音频编解码器分为以下两组：开源且专利友好的编解码器与受严格专利保护的编解码器，我们将测试这些编码器并寻求对于现在互联网服务而言最具性价比的组合。

开源的视频编解码器

VP8

VP8是由On2（现在被Google收购）公司开发的免版税编解码器，具有与H.264大致相同的计算复杂度。由于现代浏览器中H.264十分流行，VP8不再被广泛用于视频点播，但最近多被用于WebRTC中，以主流视频编解码器的身份重新活跃。

VP9

VP9是由谷歌开发的免版税编解码器，它是VP8的继承者，展示了更高的压缩比和视觉质量。尽管其编码计算复杂，但VP9可使用硬件加速解决方案。硬件加速的VP9解码器内置于许多现代浏览器和设备中，也被广泛用于Youtube、Netflix、Facebook和Twitch等网站。这些网站倾向于使用VP9与传统的MPEG，使得无论用户端设备是否支持VP9，消费者都可以使用平台服务。

AV1

AV1是由Alliance for Open Media（AOM）开发的免版税编解码器。初期AV1其实是被设计为VP9的替代品也就是VP10编解码器，但谷歌决定将这项工作捐赠给AOM基金会，在Cisco的Thor和Mozilla的Daala编解码器功能基础上开发成为了AV1。AV1在编码和解码方面的计算成本非常高，并且由于浏览器支持受限，编码内容与编码成本难以均衡，在互联网上广泛部署AV1的难度较大。

受专利保护的视频编解码器

AVC (H.264)

Advanced Video Coding（AVC）是由MPEG开发的视频编解码器，同样也是世界上最常见的视频编解码器，可在几乎所有主流浏览器与设备中使用。AVC编码与解码的计算成本相对低廉；并且由于AVC主要由MPEG开发，MPEG会通过MPEG-LA组向开发者收取使用授权费用。

HEVC (H.265)

High Efficiency Video Coding（HEVC）是由MPEG开发的视频编解码器，是之前较为流行的AVC（H.264）编解码器的后继产品，特别在1080p以上的分辨率HEVC可提供更高的压缩比。HEVC的解码器主要被用于智能电视，机顶盒和iOS设备，这也导致HEVC通常被用于提供高价值的UHD内容。HEVC的编码和解码计算成本很高，并且HEVC在目前任何桌面浏览器中都不可用。

自由音频编解码器

Vorbis

Vorbis是由Xiph.Org开发的免版税音频编解码器。它通常与VP8视频编解码器一起使用从而提供完整的免版税流媒体解决方案，目前Vorbis已被Opus取代。

Opus

Opus是由Xiph.Org开发的免版税音频编解码器。它通常与VP9视频编解码器一起使用，以提供完整的免版税流媒体解决方案。

受专利保护的音频编解码器

Advanced Audio Coding（AAC）

高级音频编码（AAC）是由MPEG开发的一款最为常见的音频压缩编解码器，可在各个主流浏览器与设备中使用。

Dolby Digital（AC3）

Dolby Digital是杜比实验室开发的音频编解码器，也称为AC-3，通常被用于家庭影音设备而不被用于网络浏览器或移动设备中。

Dolby Digital Plus（eAC3）

Dolby Digital Plus是杜比实验室开发的音频编解码器，也称为增强型AC-3或eAC-3用意取代Dolby Digital从而借助更低的比特率实现更高的声音质量与更丰富的环绕声道。

编解码器选择和测试

从上述编解码器中我选择了一个代表集作为测试用例，在电脑浏览器与移动设备浏览器上运行多个标签页并测试其性能，所选择的编解码器与容器如下：

• AVC（H.264）与MP4容器中的AAC 被选为基线测试的测试对象——我们希望这种组合可以满足任何情形下的播放需求。
• WebM容器中的VP8和Vorbis 被选为开源视频和音频编解码器的最简易组合。
• WebM容器中的VP9和Opus 被选为开源视频和音频编解码器的高压缩性能组合。

测试的工作原理是为每个源加载一个简单的<video>元素并输入被设置为静态托管状态的短视频片段，同时正确配置所有必需的CORS设置；启动静音与自动播放以及playinline从而简化测试，以便我们可以在页面加载时轻松验证播放效果。

此测试过程可在浏览器中自行运作，方法是在不同的浏览器中使用此链接，相关源代码可以在Github上被找到。 我们将当下最受欢迎的几个浏览器——Chrome，Firefox，Edge和Safari用于此项测试。

这里需要注意的是，尽管Internet Explorer与UC浏览器在市场中同样占有一定份额，但我目前并没有专注于这些平台，希望以后能有机会深入研究这些浏览器。

编解码器测试 - 桌面端浏览器

在最受欢迎的桌面端浏览器上进行的编解码器测试

（https://stream.mux.com/TDaL8h49KGc01dnp1KplILcnF024iO44gS/high.mp4）

此项测试可在浏览器上直接进行，测试结果也颇为理想。正如我们所期待的那样，MP4在全部浏览器上都可成功播放而对于VP8与VP9而言有大约3/4测试用例成功播放。这样的结果对我来说还算预期之内，而浏览器中出现播放异常状况最多的是Safari。为了确定这样的结果是否会对产品服务带来重大影响，让我们看看这四大桌面端浏览器的市场覆盖率统计数据。

根据2018年12月Statcounter公布的结果，桌面端浏览器的市场占有率如下：

• Chrome: 71%
• Firefox: 10%
• Safari: 5%
• Edge: 4%

这意味着如果你考虑采用在WebM容器中仅使用VP8或VP8与Opus / Vorbis的组合，那么市场上大约有85％的浏览器可以完美支持正常的播放活动，而市面上浏览器对MP4组合的支持率为95％，不得不说这样的结果令人印象深刻，并且还具有非常大的提升空间，那么如果是移动设备又是一番怎样的结果呢？

编解码器测试 – 移动端浏览器

虽然编码器支持85%以上的桌面端浏览器，但由于绝大多数互联网流量都源自移动端浏览器，因此在市场占有率较高的几大移动端浏览器上进行测试是十分有必要的。（这里我们使用适用于iOS和Android的Chrome与适用于iOS的Safari）。

在最受欢迎的移动端浏览器上进行的编解码器测试

（https://stream.mux.com/XTIy8VvEBD0026VwkwndvePOKCorE9vHW/high.mp4）

移动端的测试结果相对于桌面端更出人意料，MP4仍可以在任何设备上播放但开源视频编解码器却无法在iOS平台上成功播放，这意味着全世界最受欢迎的移动终端设备不支持开源视频编解码器。如果我们查看Statcounter提供的移动端浏览器市场份额，这一问题似乎更为凸显：

• Android Chrome: 41%
• iOS Chrome: 14%
• iOS Safari: 23%

这就意味着仅41％的移动端浏览器能够完美支持开源编解码器，不得不说这样的结果令人失望。尽管MP4支持90％以上的移动设备，但我们仍需做出一些努力以实现iOS平台浏览器（Chrome、Safari等）对开源编码器的支持。

Polyfills

Polyfills是视频播放领域的一项重大创新。Polyfills通过<canvas>元素和Web Audio API的组合，借助Javascript（在某些情况下借助Web Assembly，WASM）在浏览器中提供类似于VP8、VP9和AV1的编解码功能。该技术的最佳示例之一是为了让上传至维基百科的视频在更多浏览器上播放（维基百科仅使用“免费”视频编解码器和视频内容容器来提取和传送视频）而开发的OGV.js。

我们希望OGV.js可以帮助我们解决iOS对开源编码器的兼容性问题。，为此我们特别整理了一个测试工具（https://geneticgenesis.github.io/codec-tests/ogv-js-test.html）。在实验中我们添加基于polyfill的OGV.js并在之前无法兼容开源编解码器的设备与浏览器上进行测试。

在有兼容性问题的浏览器上测试OGV.js

（https://stream.mux.com/XTIy8VvEBD0026VwkwndvePOKCorE9vHW/high.mp4）

结果令人满意！OGV.js解决了许多我们面临的兼容性问题，借助OGV.js我们实现了开源编码器在Mac端Safari浏览器与iOS端Chrome和Safari浏览器上的使用；更重要的是，OGV.js也支持高版本的Internet Explorer，可以说OGV.js为开源编码器在桌面端与移动端的全面覆盖做出了不可磨灭的贡献。

当然，使用polyfills播放也存在一定缺陷。其中最为明显的是基于Javascript在客户端（或WASM）中解码和渲染视频的过程为CPU带来了非常大的运算压力，直接造成的现象是CPU使用率居高不下，温度与能耗始终保持高位；除此之外，polyfills不提供本地播放体验的特性使得开发者需要花费大量时间精力设计优化用户界面与交互。

容器

关于容器我不再赘述，原因是容器和编解码器一般为固定搭配，支持的组合相当有限，一个开源容器若想实现理想性能往往只能搭配一款开源编解码器，这里我们使用的是WebM。 WebM是.mkv的衍生物，以上所有实验都基于WebM容器进行。

传输技术

仅关注视频在浏览器中的播放性能与效果显然是不够的，前文我提出要构建一套可提供与那些使用基于专利保护技术的用户所获的一样优质视频体验的开源技术栈。

现在绝大多数在线视频播放都支持自适应编码技术（ABR），自适应编码技术是指传输音视频数据时系统可根据网络条件好坏在不同比特率的编码副本之间进行选择，以确保用户体验不会因为不断变化的网络环境而牺牲。

通常情况下，该技术通过以2～10秒为单位将视频文件分块存储并基于多个比特率进行编码实现视频文件的多码率，同时允许用户端请求内容的各个片段并在下载片段文件时监测网络环境以作出适合当下网络环境并为用户提供最佳观看体验的码率策略。

HLS and DASH

现在常用的两种ABR技术为HLS和DASH。

DASH（基于HTTP的动态自适应流传输）是由MPEG设计的自适应比特率流技术的实践成果。其通过单个基于XML的清单文件实现动态自适应传输，常用文件扩展名为.mpd。

DASH一直是开源视频格式实现自适应编码技术的首选解决方案，现已被Youtube、Netflix等平台使用，甚至Bitmovin的AV1编码测试流也基于MPEG DASH实现。然而随着MPEG许可机构（MPEG-LA）宣布启动DASH的专利池申报，一些组织开始尝试摆脱DASH。

HLS（HTTP直播流）是由在Apple的Roger Pantos设计与维护的一套自适应比特率流媒体传输技术。虽然据我所知HLS暂未受到专利池保护，但HLS与我对开源软件定义的第二项标准存在冲突：HLS在一个封闭的环境中开发且几乎没有来自其他较大社区的投入，有些社区尝试HLS之上进行扩展（例如LHLS）但这些都不太可能成为HLS官方认可的标准化技术。

为了更好地支持开源编解码器和容器，我们可以考虑在HLS仍处于开源状态时开发另一个HLS扩展从而扩展对WebM容器所包含的开源编解码器的支持并提供可用于开源解决方案的ABR技术。

虽然我们可以看到互联网开源编解码器的部署不断增加，但其中一些部署仍使用存在专利风险的DASH或者依赖于第三方公司享有专利的ABR技术。我们迫切地需要一种完全开源化，不存在任何专利风险的ABR技术以应对开源视频编解码器AV1的不断兴起。

SASH

大约在4年前，我和Jon Dahl（我们的联合创始人兼首席执行官）在San Francisco Video聚会上对MPEG DASH做出的一系列决策感到遗憾。为改善此现状，我们制定了一项ABR应用的新标准。

SASH（基于HTTP的简单自适应流）是一种参考了HLS和DASH大规模部署的经验并改进其设计决策，在提高简单性和可读性的同时消除播放器开发不确定因素的全新协议，SASH被设计成可替换HLS或DASH以实现媒体数据的传输。

2019年，在为FOSDEM准备此演讲时我再次拒绝了SASH，原因是在我的研究里缺乏完全开源的ABR技术。从那以后，我花时间回顾了我4年前做出的决定并尝试改进设计以满足更多实际案例的需求。

SASH使用简单的JSON清单描述ABR集。看看下面的例子：

 1{
 2    "sash_version" : 2,
 3    "presentation_duration": 300,
 4    "video" : [
 5        {
 6            "mine_type" : "video/mp4",
 7            "segment_template" : {
 8                "duration": 1.960,
 9                "init": "http://example.com/video-1/$rendition$/init.m4f",
10                "media": "http://example.com/video-1/$rendition$/segment$number$.m4f",
11                "start_number": 0,
12                "end_number" : 154
13            },
14            "renditions" : {
15                "video-540p-800k" : {
16                    "bandwidth": 800000,
17                    "codecs": "avc1.4d401e",
18                    "height": 480,
19                    "width": 852
20                }
21            }
22        }
23    ],
24    "audio": [
25        {
26            "mime_type" : "video/mp4",
27            "segment_template": {
28                "duration": 1.996,
29                "init": "http://example.com/video-1/$rendition$/init.m4f",
30                "media": "http://example.com/video-1/$rendition$/segment$number$.m4f",
31                "start_number": 0,
32                "end_number": 154
33            },
34            "renditions": {
35                "audio-64k" : {
36                    "bandwidth": 64000,
37                    "codecs": "mp4a.40.2"
38                }
39            }
40        }
41    ]
42}

我今年一直在关注的一个重大变化是支持不连续性，以支持各种用例，包括货币化。作为Github上Demuxed社区的一部分，我将继续开发SASH提案。特别是，我很想听到您对v0.2提案的任何反馈！

播放器

与开源播放器相关的文章有很多，这里我就不再赘述。需要注意在播放器选型时我们应当考虑以下几点：

进行播放器选型，关键是您所在企业的业务目标与产品开发策略——是需要样式、插件等统一且完整的播放器完整框架还是需要高定制化的简易播放器框架？以下选项可供您参考：

Video.js

Video.js是一个全面的HTML5视频播放器框架，内置插件、样式和对HLS和DASH的全面支持。VideoJS是在GitHub上开放的，并且是在Apache V2许可下获得许可的。

构建开源的视频交付链，Video.js是一个很好的选择。Video.js已经实现了对开源编解码器与容器的良好支持；如果结合DASH，Video.js甚至可以与具有ABR功能的编解码器一起使用。

实现SASH等对Video.js的支持并不是一件困难的事情，Video.js通过获得了Apache V2许可的开源组件Video.js HTTP Streaming（VHS）实现了基于HTTP的ABR功能并提供对未来格式的支持。

开源视频链的另一优势在于其已经为Video.js提供了一个OGV.js插件。这意味着我们可以借助一套统一的视频播放器，使那些原本不支持开源编解码器的浏览器支持OGV.js下的polyfill。

HLS.js

当然还有HLS.js，HLS.js并非一个完整的播放器解决方案而是一个为HTML5 <video>元素提供ABR（以HLS形式）功能的库。如果您想从底层开始构建属于自己的播放器并定制播放器样式、按钮、插件等，则可以使用HLS.js。

虽然让HLS增加对SASH的支持似乎不太可能，但在HLS中增加对WebM VP9等内容的支持则相对容易，这也是实现全开源解决方案的基石。HLS.js同样获得了Apache V2的许可。

播放器的问题

虽然我们为用户提供了一系列不错的选择，但这些似乎并没有完全得到落实。尽管我们的OGV.js polyfill解决方案可以很好地填补基本回放中的技术空白，但到目前为止我们仍无法实现polyfill对ABR技术的支持。

现在的浏览器中，ABR通过使用SourceBuffer API实现将媒体元素以视频和音频块的形式传输至HTML5。遗憾的是，这些功能并不能被用于OGV.js polyfill。这也意味着为了向所有用户提供我们所描述的服务，我们必须将和API相似的SourceBuffer构建至OGV.js或使用其他具有与SourceBuffer相似功能的技术代替。

开源视频产业链概览

拼凑碎片化的观点，总结如何构建开源视频产业链，我们需要在今天与未来不懈努力。

目前

通过利用以下开源技术，我们可以实现开源视频产业链覆盖超过90％的桌面浏览器与超过80％的移动浏览器：

• 带有Vorbis的VP8或带有Opus的VP9
• WebM容器
• Video.js与OGV.js polyfill

遗憾的是，现在我们暂时无法在开源视频产业链中使用ABR技术，但相信现在的临时解决方案会为我们为在未来实现HLS对WebM的支持而做出的不懈探索点明方向。

未来不久

每个互联网从业者都希望拥有一个通用的开放视频传输产业链以降低交付成本与技术复杂性，而开源技术使得节省数据使用，增加互联网数据传输效率提供了可能。

希望在不久的将来能看待这些技术帮助构建一个完善的开源视频产业链。

• 支持Opus的AV1
• WebM 容器
• 基于ABR的SASH
• 支持具有ABR功能的OGV.js polyfill 技术的Video.js

总结

这是一个在线视频蓬勃发展的时代，越来越多的设备与浏览器提供了对开源播放器的支持，同时由强大的Javascript引擎驱动的polyfill技术正在帮助我们进一步优化功能架构完善产品服务。我们即将推出一个基于完全开源技术构建的编解码器。

基于开源技术，我们能为用户提供可媲美那些基于占市场主导地位的专利敏感技术的视频服务体验。Mux将继续投资开源技术并积极将其用于视频传输，为使用产品与服务的用户带来愉悦使用感受。