视频API的发展方向

本文来自Mux流媒体专家Phil Cluff 在LiveVideoStackCon 上海站的精彩分享。在此我们会研究视频API过去十年来的启发以及时间线，从Real Player、Adobe Flash、RTMP、FLV 直到DASH，并且如何将其集成到视频流平台中。另外，Phil将视频API的定义分解为编码API和视频平台API、API结构的重要性以及SAAS如何帮助开发人员更好地使用SDK。最后，我们总结了如何以14个简单步骤构建一个优秀的视频API。

作者 / Phil Cluff

整理 / LiveVideoStack

译 / Adrian Ng

非常感谢LiveVideoStack邀请我来到这个论坛，这是我第一次来中国，更何况是上海。我觉得上海是一个很棒的城市，城市节奏与这里各种各样的美食，对我来说都很重要！我是Phil，在视频行业已经有10年了。

我的职业生涯是在伦敦的BBC开始，然后转到Brightcove和Zencoder，现在在Mux当流媒体专家。在业余时间，我组织了London Video Technology Meetup（伦敦视频技术会议）。如果你们有机会来到伦敦，可以随时联系我，我欢迎你们的出席，同时间我也共同主持一个关于视频技术的播客。

今天我的主题是视频API，我们回顾流式视频历史的时间线，并讨论视频API的类型。另外，我们看看视频API以及构建优秀视频API的一些技巧，API结构的重要性。也许你会好奇这点“什么让你有资格谈论视频API这话题呢？”

在BBC，当时我们把视频中最大的API集成到了一个privateencoding API（私有的编码API）。之后，我在Brightcove 和Zencoder建立了公共和私有的视频API，现在的公司Mux，是个API的第一的视频平台。但是，我的专长还是欧洲、美国、澳大利亚和日本的某些地方。

你们比我更了解中国，所以也许我所说的可能不太适合你们的市场，但是我希望在接下来的时间，你们可以与我分享，分辨两个市场的区别。

对我来说，互联网上的流媒体视频始于1995年- 90年代的中期，所以我也会探索未来的发展方向。在线流媒体的前五年实际上是由专有的浏览器插件（动画gif之外）作出定义的，显然其中一个重要的插件是RealPlayer。

我们就什么浏览器插件达成一致，Macromedia的Flash显然变成了Adobe Flash。持续了近10年Flash视频、FLV和RTMP，之后我们开始向HDS过渡，HDS显然是Adobe的块流标准版本。Smooth和HLS发动之前，我们再次做转换并广泛地应用DASH，接下来的两年内我们会注重CMAF,LHLS,还有低延迟性DASH流。

随着Smooth的发布，我们从Flash切换到HLS的第一个版本。2012年DASH首次宣布时，许多人也开始应用它，这几乎终止了HLS的应用。

你们是否听说过Homestar Runner 或eBaum’s World的网站? 大多数人都没有忘记互联网的遗迹，所以这些网站才是真正的病毒视频概念的发源地。大多数人都没有忘记互联网的遗迹，所以以上的这些网站才是viral 视频概念的发源地。这些网站上的小猫动画，剪辑，漫画都是在Flash 世界开始，互联网上的viral 视频都是在此而被带动的。

2005年，YouTube再次推出了全球最主要的基于Flash的视频平台之一。

两年后，市场商业平台快速地增加，比如欧洲的BBC iPlayer、美国的Netflix和Hulu – 仍然基于Flash RTMP FLV流媒体。当我们踏入segmented world( 细分世界)，我们看见Amazon所建立的Amazon Prime Video。它最初被称为Instant Video。在2015年，HBO GO上线，并且年底预定将推出全新的Disney Plus (迪士尼+）

这些技术显然是在流媒的chunked streaming space(块流空间中)，这些平台只存在于块流空间。现在我们已经确定了时间表，video API到底是什么？凡是可以应用操作一段视频都归于video API。但我们将主要讨论软件即服务的视频API，对我来说，它分为两类：“编码API”和“视频平台API”，所以第一个编码API，我认为这是一个不妥当的名字，但最终还是保留了。

我认为没有一个纯粹的软件作为这个编码API存在。实际上你所说的都是API内置的转码器、Muxers、Packagers(打包器)、DRM代理、文件传输代理。但是关键是对于编码设置的fine-grainedcontrol(细粒度控制)，所以我依然称它为encodingAPI。一般来说，这将使用远程存储，通常是Amazon的S3或Google Cloud Storage云存储以及类似的设备。

这里有一些重要的例子：Zencoder，亚马逊的第一个编码产品：Elastic Transcoder，encoding.com，Hybrik，Bitmovin，以及最近的MediaConvert一种替代Elastic Transcoder的产品。

仔细看过去的10年，这些产品都释放在哪里呢？在Zencoder，我推发的第一个软件是一个serviceencoding platform(服务编码平台)，一个非常简单的JSON API。

它还支持XML API，但是我们不再使用它。不过，它有一个非常简单的工作，并使用temporaryoutput storage（临时输出存储）来帮助您快速入门。内存含有SDK，但不多，因为如果你有一个很好的API，你的SDK实际上无关紧要。

Elastic Transcoder弹性转码器-我很幸运成为弹性转码器预发行候选者之一。Amazon Web Services (AWS)比较复杂，它们所称的管道（即实际作业规范本身的输入和输出）之前引入了一个抽象。它从一开始就有很好的SDK支持，因为很明显，作为一个亚马逊产品，它只是建立在亚马逊的SDK之上。

Bitmovin是编码领域中近代有创新能力的公司，他们在2015年发布了自己的编码平台Bitcodin。这是一个相当复杂的API，他们使用MSON和JSON，JSON可是API blueprint中的一个系统。Bitmovin很积极地鼓励SDK的应用，避免直接使用他们的 Restful APIs。2017年，一个比较新式的编码API之一是Media Convert，它实际上是从Amazon的Elemental Acquisition发展起来的，适合广播公司，复杂度也高。

Encoding API怎么形成的呢？我们所见的内涵的粒度和控制已得到很大的改进，但是API交换的复杂性也提高。在此举个例子，这是Zencoder v2,如果你去注册一个帐户，你今天就可以在Zencoder上做这个。

这是运行的最基本需求，首先它只是一个input file (输入文件)。Inputfile分配你一些存储空间，并给你一个临时输入文件，它会假设你想要H.264 1兆位 – 会有defaults(默认值)。

这就是一个符合标准的API。

这是最简单的media convert job(媒体转换工作)，我们运行同一个步骤：MP4 输入，MP4输出，一个兆位，完全没有预设。

我认为这是一个糟糕的API。

为什么会有这样呢？我个人觉得因为面向开发市场会比较少，更多的是针对于高端系统集成商。另外一个关键点是人们没有首先考虑API设计，而且有很多假设认为人们会使用SDK。

提到我的第二种视频API，这是一个video platform API(视频平台API)。你们也许不知道视频平台提供更高的层次、更全面地服务，所以他们会给你ingest(摄取)，transcode(转码)，catalog(目录），distribution（发行），CDN，analytics (分析)，播放器等捆绑成一套产品。一般都会有三个 API – 可能会更多，或许更少，但至少三个服务器内置一个目录、一个摄取和一个回放API。

Brightcove的视频云在这个领域占据主导地位。Kaltura是个开源的替代方案，JW在space是个比较新的方案，而Ooyala现在也是Brightcove的一部分。

这三种API，一个是目录API – 主要是关于你的账户中内容的metadata management (元数据管理)。其中包括标题、描述、类别、元数据标记社交分发目标。

Ingest APIs:这将暴露对实际编码过程的一些控制，并且看起来像我们所讨论过的编码API。其他时候，它将使用配置文件来定义编码，因此你可以使用一个API来定义配置文件。然后，当你实际运行编码时，同时你也正在摄取引用这些配置文件。

这些是用来获取URL的，所以内容的片段可以是HLS，Smooth，DASH，或者渐进式MP4 URL。URL往往是tokenized(标记化的)，这些API很安全，但是很多情况下，它们实际上并不是很安全。

我想强调过去10年所发生的一些变化，因为JW Player 的确是一个很新、刚上线的平台。

2011年，他们建立了自己的视频平台，为Brightcove的发展提供了一个可以追溯到21世纪初的背景。这是一个基于XML的API，他们实际上使用了两个API一个用于目录和摄取，另一个用于回放生成的文档。基于Push and Pull的摄取，它可以从存储中提取一个文件，也可以将一个文件推送到它进行摄取。

2013年Ooyala宣布了“Rights Locker”，这是一个用于authenticated (身份认证)，和authorized(授权的回放)的API。这并不擅长用于线视频平台领域传统系统上，但最近我们开始看见它的演变和改进。

2015年Brightcove在年中替换了所有的 Catalog API，面向基于 JSON的对象模型。在2016年，Brightcove采用了完全基于pull-based的ingest格式。值得关注的是，Brightcove在 2018年重新添加了一个ingestion 推送技术，所以显然我们还需要基于pull以及push推送的ingestion。

正如我们所说，从基于push到基于pull-based的API转变，因为除了Push API，大多数的ingest还在但它们不再基于FTP，它们过去通常基于FTP放置位置。如今，他们通常基于S3或Google 云存储和playback security (安全播放)。

Rights Lockers概念是一个实际的authenticatedauthorized playback system(经过身份验证的授权播放系统)。所以这是相当可以改进的空间 –每一块都很弱的空间：Rights Locker是一个很好的例子，关键是看你的客户是否希望能够定义播放或做出playback。

实际上我们在编码API中看到了相当多的演变，但是在与online video platforms (在线视频平台)并不多，为什么呢？OVP公司很大，而且进展缓慢，它们有非常复杂的客户集成，也可能是外包公司管理。他们有可能从来没有接触这种集成，因此缺乏一个支持API的多个版本的欲望。最后，他们选择一些新的特性，但是这个路线不一定可以提供一个精致的API。

Move Fast (行动快)及 Break things的概念跟在线视频平台上不可以同时存在。

另外，我想提一下其他类型的视频API。我认为FFmpeg是一个视频API。FFmpeg在每一个视频平台、每一个视频软件中几乎无处不在，它总是通过command line interface（命令行接口）集成。这些年来我一直在研究，偶然发现了一些只是执行FFmpeg的东西，已经不计其数了。

FFmpeg不是software as a service(软件即服务)，但是我们可以把它作为一个社区来操纵视频。我们应该使用libav 和libav绑定。当然，我也想强调Mux的视频API与我们所讨论的API到底有什么区别。我们将mixed video infrastructure (混合视频基础设施)称为一种服务并使用与最初构建Zencoder的相同概念从新开发。因此，如果我们还记得早期的Zencoder接受请求，这是一个用于接受和流式处理的trivial API。

我们可以用Mux做同样的事情- 它是two lines而不是one line，但它仍然只有two lines。所以我们把输入放在一个URL中，不管它是公共的还是私用的，也有一个playback policy(回放策略)。

这是一个供应开箱playback security的概念。我们再次使用Playback ID然后可以把它直接放到一些URL，不管是M3U8流，还是thumbnail (缩略图) ，动画GIF。

他们所含的default behaviours也是非常简单的minimal API。

API结构重要吗？

现在，软件即服务很正常。这即是标准，客户都希望能够减少有如JSON媒体编写次数。例如：Bitmovin的数百行代码。开发者有选择的能力，能否选择使用并实验他人的SDK。在这个情况下，开发者会以developer-centric market中心的市场（目标是开发者与小公司），你更有可能购买他们的产品。

当初，我想列出10个简单的步骤编写视频API，最终我还是得到了14个步骤。

首先最重要的是：你需要知道你客户需求，谁将使用你的API？第一个问题是：它是internal内部还是external外部？它是一个公共API还是你正构建的一个产品？

如果这样的话，也许你在乎speed ofintegration (集成的速度)，还有elegant API abstraction(API抽象)。如果是internal，那抽象的API可能失去价值。我们注重的close coupling (紧密耦合) – 有一个非常具体的问题需要解决，所以必须理解这一点。

提到抽象这一点，你想要了解的是你试图在目标市场解决的问题，但我真正想看的是我的客户对视频了解有多少？他们是想要一个在任何地方操作的线视频平台，还是目的只想控制我正在使用的H.264配置文件？

每个API有一个抽象级别是重要的，不是关键的，但它很重要。为了实现这一点，您可能需要重新安排你的API。

我们从Zencoder可见，如果你给它一个input输入文件，他可以生成一个 MP4 output 输出文件。与Mux一样 – 你给它一个输入文件MP4的话，它可以给你一些HLS自适应比特率输出。所有的东西会默认为H264 – 这些都是合理的默认值。我们希望能达到最简单的集成，而不仅仅是默认而已，small minimum API请求也重要。

这是关于 trivial authentication (琐碎的身份验证)，我喜欢这样问自己“我的视频API仅仅使用curl合适吗？”如果不能的话，那么结果可能不太理想。

这是另一个例子，也是最大的在线视频平台的入门指南。设置身份验证一共有16个步骤。

对我来说，这是一个不合格的API。因为它在使用OAuth，我个人不推荐OAUTH的应用。

举个例子，Mux也是这样。这个屏幕你得到了你的API token，第二步实际上是video ingestion摄取视频。这是如何制作一个简单并实用的API。

你应该在合理的地方实用established standards(既定的标准)，通常HTTP和JSON是合理的选择，XML也是我可以接受的（虽然我个人不太喜欢）。

JSON API有些标准，用来定义API结构，它可以为request-responsepatterns 提供更好的结构。某些情况如构建private API时， HTTP可能不是最好的解决方案。你可以使用传输：message queue patterns（消息队列模式）。我构建了广泛使用message queue patterns来实现视频的系统。

如果你正在执行microservice oriented architecture (面向微服务的体系结构)比如GRPC或Protobuf，你可以使用备用传输以便在close coupling的服务之前进行通信。在此，不需要使用HTTP。

随着产品的实施，你可能会重新访问你的API。一个API很容易偏离它的初衷，你应该时时考虑你的API设计，想想每次修改API时是否忠于原始的API设计。

我很喜欢与客户谈论我的产品以及API，客户想要一个双向的关系，他们尽可能会以不同的方式看待你的API，所以有时候会对你的API设计给予非常诚实、清晰的反馈。

有一些开放的API toolchain 很强大，以下是一些以编程方式描述API的方法。你可以生成文档，你可以生成SDK，你可以生成服务器端绑定;如果你开始用编程的方式描述你的API，这些都是你可以用编程的方式做出的。举几个例子：Open API V3现在仍然是大摇大摆的。（我不知道他们为什么改名）。我们使用它成功地生成SDK，反应不错。Bitmovin 所构建的API blueprint也有同样的目的。

除此之外，无论您是否使用自动化流程，你也应该存储你的API记录。如果没有充分的文档记录，客户就可能不选择你的API。你还应该以HTTP格式存档API；有很多趋势，尤其是因为亚马逊在存储SDK方面很差。你应该使用HTTP记录，如果你用的是定义文件，那么这一切可以通过编程来完成。

首先，你应该对你的API进行版本化– 你不该等到第一次推出新版本才给一个版名，每次引入一个新版本的时候你该设定 V1 – V1 应该是最早期版本。例如，MuxAPI; 我们说的第一件事是视频API，它是Video API for Data API 的一个版本。它具有相同的类型，我们不该等到需要V2 才添加版本号。

我们必须提供一个迁移路径，以便从V1迁移V2。若强迫客户迁移服务，这对客户也许很麻烦、多余的经历。在SAAS环境下，这样做会让客户审查他们的供应商决策。实际上他们积极地问“等等，你要让我升级整个API集成吗？我倒不如直接去寻找一个更便宜、容易应用的系统，这对于客户保留是一个重点暗号。如果想解决这问题，最好是用shims (填隙片)替换旧的API，这样一个轻量级的shims会将V1转换为V2,同时以新的特性鼓励客户升级到 V2，而不是通知“在某个时候会终止V1 API 的应用”。

我们可以考虑构建transcode abstraction layers(转码抽象层)，这是一个将generic transcode request(通用转码请求)转换为multiple underlying encoding vendors(多个底层编码供应商)的一种方法。其概念就是；你把它们放在所有SAAS编码供应商面前，并根据成本或性能为每一个转码工作做出决定，最终发送的方向。

在这构建过程中，我发现它的潜力非常强大– New York Times (纽约时报)有一个很好的开源软件，即是我的朋友建构的，它涵盖了Bitmovin、Zencoder到Hibrik以及其他一些东西。

我们需要考虑playback security upfront(预先播放的安全性)，这就是我们讨论的在线视频平台API。如果你正在建造类似的东西，那你必须从零开始。

关键是我们该推卸责任给客户，当然的我们应该尊重客户的想法。如果客户允许你播放此内容，那我们尊重它的决定。

一般来说，有两种方法；第一种是在请求中添加客户的crytographic signature (加密签名)。客户会使用JWT或某种形式的加密签名签署一个URL，如果与你的签名匹配，那你尊重它。另一种方法是callbacks(回调)。这是另一种方式，客户出去定义一个URL，你可以作为供应商去点击它来决定是否可以开始播放 - 我亲眼看过两种方式的过程，而且都成功了。

作为一个总结，这14个简单的步骤并不难！

在过去的10年，经过多次的构建改革以及糟糕的API，我时时刻刻在学习新的方式做探讨。

概括起来，我认为这是两种类型的视频API编码和平台。一个合格良好的API对你的SAAS很重要，我建议您可以使用14条规则来帮助您构建一个好的视频API。

LiveVideoStackCon 2020 讲师招募

2020年LiveVideoStackCon将持续迭代，4月25日-26日在上海，9月11日-12日在北京，11月在旧金山。欢迎将你的技术实践、踩坑与填坑经历、技术与商业创业的思考分享出来，独乐不如众乐。请将个人资料和话题信息邮件到 speaker@livevideostack.com 或点击【阅读原文】了解成为LiveVideoStackCon讲师的权益与义务，我们会在48小时内回复。