視訊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。

————————————————

版權聲明：本文為CSDN部落客「LiveVideoStack_」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明。

原文連結：

https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/103966778

「視訊雲技術」你最值得關注的音視訊技術公衆号，每周推送來自阿裡雲一線的實踐技術文章，在這裡與音視訊領域一流工程師交流切磋。