视频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小时内回复。

发布了488 篇原创文章 · 获赞 351 · 访问量 54万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 技术黑板 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览