视频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小時內回復。
總結
以上是生活随笔為你收集整理的视频API的发展方向的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 音视频技术开发周刊（第128期）
- 下一篇： 9家专利拥有者退出MPEG LA HEV