本文來(lái)自Mux流媒體專(zhuān)家Phil Cluff 在LiveVideoStackCon 上海站的精彩分享。在此我們會(huì)研究視頻API過(guò)去十年來(lái)的啟發(fā)以及時(shí)間線，從Real Player、Adobe Flash、RTMP、FLV 直到DASH，并且如何將其集成到視頻流平臺(tái)中。另外，Phil將視頻API的定義分解為編碼API和視頻平臺(tái)API、API結(jié)構(gòu)的重要性以及SAAS如何幫助開(kāi)發(fā)人員更好地使用SDK。最后，我們總結(jié)了如何以14個(gè)簡(jiǎn)單步驟構(gòu)建一個(gè)優(yōu)秀的視頻API。

作者 / Phil Cluff

整理 / LiveVideoStack

譯 / Adrian Ng

非常感謝LiveVideoStack邀請(qǐng)我來(lái)到這個(gè)論壇，這是我第一次來(lái)中國(guó)，更何況是上海。我覺(jué)得上海是一個(gè)很棒的城市，城市節(jié)奏與這里各種各樣的美食，對(duì)我來(lái)說(shuō)都很重要！我是Phil，在視頻行業(yè)已經(jīng)有10年了。

我的職業(yè)生涯是在倫敦的BBC開(kāi)始，然后轉(zhuǎn)到Brightcove和Zencoder，現(xiàn)在在Mux當(dāng)流媒體專(zhuān)家。在業(yè)余時(shí)間，我組織了London Video Technology Meetup（倫敦視頻技術(shù)會(huì)議）。如果你們有機(jī)會(huì)來(lái)到倫敦，可以隨時(shí)聯(lián)系我，我歡迎你們的出席，同時(shí)間我也共同主持一個(gè)關(guān)于視頻技術(shù)的播客。

今天我的主題是視頻API，我們回顧流式視頻歷史的時(shí)間線，并討論視頻API的類(lèi)型。另外，我們看看視頻API以及構(gòu)建優(yōu)秀視頻API的一些技巧，API結(jié)構(gòu)的重要性。也許你會(huì)好奇這點(diǎn)“什么讓你有資格談?wù)撘曨lAPI這話題呢？”

在BBC，當(dāng)時(shí)我們把視頻中最大的API集成到了一個(gè)privateencoding API（私有的編碼API）。之后，我在Brightcove 和Zencoder建立了公共和私有的視頻API，現(xiàn)在的公司Mux，是個(gè)API的第一的視頻平臺(tái)。但是，我的專(zhuān)長(zhǎng)還是歐洲、美國(guó)、澳大利亞和日本的某些地方。

?

你們比我更了解中國(guó)，所以也許我所說(shuō)的可能不太適合你們的市場(chǎng)，但是我希望在接下來(lái)的時(shí)間，你們可以與我分享，分辨兩個(gè)市場(chǎng)的區(qū)別。

?

對(duì)我來(lái)說(shuō)，互聯(lián)網(wǎng)上的流媒體視頻始于1995年- 90年代的中期，所以我也會(huì)探索未來(lái)的發(fā)展方向。在線流媒體的前五年實(shí)際上是由專(zhuān)有的瀏覽器插件（動(dòng)畫(huà)gif之外）作出定義的，顯然其中一個(gè)重要的插件是RealPlayer。

我們就什么瀏覽器插件達(dá)成一致，Macromedia的Flash顯然變成了Adobe Flash。持續(xù)了近10年Flash視頻、FLV和RTMP，之后我們開(kāi)始向HDS過(guò)渡，HDS顯然是Adobe的塊流標(biāo)準(zhǔn)版本。Smooth和HLS發(fā)動(dòng)之前，我們?cè)俅巫鲛D(zhuǎn)換并廣泛地應(yīng)用DASH，接下來(lái)的兩年內(nèi)我們會(huì)注重CMAF,LHLS,還有低延遲性DASH流。

隨著Smooth的發(fā)布，我們從Flash切換到HLS的第一個(gè)版本。2012年DASH首次宣布時(shí)，許多人也開(kāi)始應(yīng)用它，這幾乎終止了HLS的應(yīng)用。

?

?

你們是否聽(tīng)說(shuō)過(guò)Homestar Runner 或eBaum’s World的網(wǎng)站? 大多數(shù)人都沒(méi)有忘記互聯(lián)網(wǎng)的遺跡，所以這些網(wǎng)站才是真正的病毒視頻概念的發(fā)源地。大多數(shù)人都沒(méi)有忘記互聯(lián)網(wǎng)的遺跡，所以以上的這些網(wǎng)站才是viral 視頻概念的發(fā)源地。這些網(wǎng)站上的小貓動(dòng)畫(huà)，剪輯，漫畫(huà)都是在Flash 世界開(kāi)始，互聯(lián)網(wǎng)上的viral 視頻都是在此而被帶動(dòng)的。

2005年，YouTube再次推出了全球最主要的基于Flash的視頻平臺(tái)之一。

兩年后，市場(chǎng)商業(yè)平臺(tái)快速地增加，比如歐洲的BBC iPlayer、美國(guó)的Netflix和Hulu – 仍然基于Flash RTMP FLV流媒體。當(dāng)我們踏入segmented world( 細(xì)分世界)，我們看見(jiàn)Amazon所建立的Amazon Prime Video。它最初被稱(chēng)為Instant Video。在2015年，HBO GO上線，并且年底預(yù)定將推出全新的Disney Plus (迪士尼+）

這些技術(shù)顯然是在流媒的chunked streaming space(塊流空間中)，這些平臺(tái)只存在于塊流空間。現(xiàn)在我們已經(jīng)確定了時(shí)間表，video API到底是什么？凡是可以應(yīng)用操作一段視頻都?xì)w于video API。但我們將主要討論軟件即服務(wù)的視頻API，對(duì)我來(lái)說(shuō)，它分為兩類(lèi)：“編碼API”和“視頻平臺(tái)API”，所以第一個(gè)編碼API，我認(rèn)為這是一個(gè)不妥當(dāng)?shù)拿?#xff0c;但最終還是保留了。

我認(rèn)為沒(méi)有一個(gè)純粹的軟件作為這個(gè)編碼API存在。實(shí)際上你所說(shuō)的都是API內(nèi)置的轉(zhuǎn)碼器、Muxers、Packagers(打包器)、DRM代理、文件傳輸代理。但是關(guān)鍵是對(duì)于編碼設(shè)置的fine-grainedcontrol(細(xì)粒度控制)，所以我依然稱(chēng)它為encodingAPI。一般來(lái)說(shuō)，這將使用遠(yuǎn)程存儲(chǔ)，通常是Amazon的S3或Google Cloud Storage云存儲(chǔ)以及類(lèi)似的設(shè)備。

?

這里有一些重要的例子：Zencoder，亞馬遜的第一個(gè)編碼產(chǎn)品：Elastic Transcoder，encoding.com，Hybrik，Bitmovin，以及最近的MediaConvert一種替代Elastic Transcoder的產(chǎn)品。

仔細(xì)看過(guò)去的10年，這些產(chǎn)品都釋放在哪里呢？在Zencoder，我推發(fā)的第一個(gè)軟件是一個(gè)serviceencoding platform(服務(wù)編碼平臺(tái))，一個(gè)非常簡(jiǎn)單的JSON API。

它還支持XML API，但是我們不再使用它。不過(guò)，它有一個(gè)非常簡(jiǎn)單的工作，并使用temporaryoutput storage（臨時(shí)輸出存儲(chǔ)）來(lái)幫助您快速入門(mén)。內(nèi)存含有SDK，但不多，因?yàn)槿绻阌幸粋€(gè)很好的API，你的SDK實(shí)際上無(wú)關(guān)緊要。

Elastic Transcoder彈性轉(zhuǎn)碼器-我很幸運(yùn)成為彈性轉(zhuǎn)碼器預(yù)發(fā)行候選者之一。Amazon Web Services (AWS)比較復(fù)雜，它們所稱(chēng)的管道（即實(shí)際作業(yè)規(guī)范本身的輸入和輸出）之前引入了一個(gè)抽象。它從一開(kāi)始就有很好的SDK支持，因?yàn)楹苊黠@，作為一個(gè)亞馬遜產(chǎn)品，它只是建立在亞馬遜的SDK之上。

Bitmovin是編碼領(lǐng)域中近代有創(chuàng)新能力的公司，他們?cè)?015年發(fā)布了自己的編碼平臺(tái)Bitcodin。這是一個(gè)相當(dāng)復(fù)雜的API，他們使用MSON和JSON，JSON可是API blueprint中的一個(gè)系統(tǒng)。Bitmovin很積極地鼓勵(lì)SDK的應(yīng)用，避免直接使用他們的 Restful APIs。2017年，一個(gè)比較新式的編碼API之一是Media Convert，它實(shí)際上是從Amazon的Elemental Acquisition發(fā)展起來(lái)的，適合廣播公司，復(fù)雜度也高。

?

Encoding API怎么形成的呢？我們所見(jiàn)的內(nèi)涵的粒度和控制已得到很大的改進(jìn)，但是API交換的復(fù)雜性也提高。在此舉個(gè)例子，這是Zencoder v2,如果你去注冊(cè)一個(gè)帳戶(hù)，你今天就可以在Zencoder上做這個(gè)。

這是運(yùn)行的最基本需求，首先它只是一個(gè)input file (輸入文件)。Inputfile分配你一些存儲(chǔ)空間，并給你一個(gè)臨時(shí)輸入文件，它會(huì)假設(shè)你想要H.264 1兆位 – 會(huì)有defaults(默認(rèn)值)。

這就是一個(gè)符合標(biāo)準(zhǔn)的API。

?

這是最簡(jiǎn)單的media convert job(媒體轉(zhuǎn)換工作)，我們運(yùn)行同一個(gè)步驟：MP4 輸入，MP4輸出，一個(gè)兆位，完全沒(méi)有預(yù)設(shè)。

我認(rèn)為這是一個(gè)糟糕的API。

?

?

為什么會(huì)有這樣呢？我個(gè)人覺(jué)得因?yàn)槊嫦蜷_(kāi)發(fā)市場(chǎng)會(huì)比較少，更多的是針對(duì)于高端系統(tǒng)集成商。另外一個(gè)關(guān)鍵點(diǎn)是人們沒(méi)有首先考慮API設(shè)計(jì)，而且有很多假設(shè)認(rèn)為人們會(huì)使用SDK。

?

提到我的第二種視頻API，這是一個(gè)video platform API(視頻平臺(tái)API)。你們也許不知道視頻平臺(tái)提供更高的層次、更全面地服務(wù)，所以他們會(huì)給你ingest(攝取)，transcode(轉(zhuǎn)碼)，catalog(目錄），distribution（發(fā)行），CDN，analytics (分析)，播放器等捆綁成一套產(chǎn)品。一般都會(huì)有三個(gè) API – 可能會(huì)更多，或許更少，但至少三個(gè)服務(wù)器內(nèi)置一個(gè)目錄、一個(gè)攝取和一個(gè)回放API。

Brightcove的視頻云在這個(gè)領(lǐng)域占據(jù)主導(dǎo)地位。Kaltura是個(gè)開(kāi)源的替代方案，JW在space是個(gè)比較新的方案，而Ooyala現(xiàn)在也是Brightcove的一部分。

這三種API，一個(gè)是目錄API – 主要是關(guān)于你的賬戶(hù)中內(nèi)容的metadata management (元數(shù)據(jù)管理)。其中包括標(biāo)題、描述、類(lèi)別、元數(shù)據(jù)標(biāo)記社交分發(fā)目標(biāo)。

Ingest APIs:這將暴露對(duì)實(shí)際編碼過(guò)程的一些控制，并且看起來(lái)像我們所討論過(guò)的編碼API。其他時(shí)候，它將使用配置文件來(lái)定義編碼，因此你可以使用一個(gè)API來(lái)定義配置文件。然后，當(dāng)你實(shí)際運(yùn)行編碼時(shí)，同時(shí)你也正在攝取引用這些配置文件。

這些是用來(lái)獲取URL的，所以?xún)?nèi)容的片段可以是HLS，Smooth，DASH，或者漸進(jìn)式MP4 URL。URL往往是tokenized(標(biāo)記化的)，這些API很安全，但是很多情況下，它們實(shí)際上并不是很安全。

我想強(qiáng)調(diào)過(guò)去10年所發(fā)生的一些變化，因?yàn)镴W Player 的確是一個(gè)很新、剛上線的平臺(tái)。

2011年，他們建立了自己的視頻平臺(tái)，為Brightcove的發(fā)展提供了一個(gè)可以追溯到21世紀(jì)初的背景。這是一個(gè)基于XML的API，他們實(shí)際上使用了兩個(gè)API一個(gè)用于目錄和攝取，另一個(gè)用于回放生成的文檔。基于Push and Pull的攝取，它可以從存儲(chǔ)中提取一個(gè)文件，也可以將一個(gè)文件推送到它進(jìn)行攝取。

2013年Ooyala宣布了“Rights Locker”，這是一個(gè)用于authenticated (身份認(rèn)證)，和authorized(授權(quán)的回放)的API。這并不擅長(zhǎng)用于線視頻平臺(tái)領(lǐng)域傳統(tǒng)系統(tǒng)上，但最近我們開(kāi)始看見(jiàn)它的演變和改進(jìn)。

2015年Brightcove在年中替換了所有的 Catalog API，面向基于 JSON的對(duì)象模型。在2016年，Brightcove采用了完全基于pull-based的ingest格式。值得關(guān)注的是，Brightcove在 2018年重新添加了一個(gè)ingestion 推送技術(shù)，所以顯然我們還需要基于pull以及push推送的ingestion。

正如我們所說(shuō)，從基于push到基于pull-based的API轉(zhuǎn)變，因?yàn)槌薖ush API，大多數(shù)的ingest還在但它們不再基于FTP，它們過(guò)去通常基于FTP放置位置。如今，他們通常基于S3或Google 云存儲(chǔ)和playback security (安全播放)。

?

Rights Lockers概念是一個(gè)實(shí)際的authenticatedauthorized playback system(經(jīng)過(guò)身份驗(yàn)證的授權(quán)播放系統(tǒng))。所以這是相當(dāng)可以改進(jìn)的空間 –每一塊都很弱的空間：Rights Locker是一個(gè)很好的例子，關(guān)鍵是看你的客戶(hù)是否希望能夠定義播放或做出playback。

實(shí)際上我們?cè)诰幋aAPI中看到了相當(dāng)多的演變，但是在與online video platforms (在線視頻平臺(tái))并不多，為什么呢？OVP公司很大，而且進(jìn)展緩慢，它們有非常復(fù)雜的客戶(hù)集成，也可能是外包公司管理。他們有可能從來(lái)沒(méi)有接觸這種集成，因此缺乏一個(gè)支持API的多個(gè)版本的欲望。最后，他們選擇一些新的特性，但是這個(gè)路線不一定可以提供一個(gè)精致的API。

Move Fast (行動(dòng)快)及 Break things的概念跟在線視頻平臺(tái)上不可以同時(shí)存在。

另外，我想提一下其他類(lèi)型的視頻API。我認(rèn)為FFmpeg是一個(gè)視頻API。FFmpeg在每一個(gè)視頻平臺(tái)、每一個(gè)視頻軟件中幾乎無(wú)處不在，它總是通過(guò)command line interface（命令行接口）集成。這些年來(lái)我一直在研究，偶然發(fā)現(xiàn)了一些只是執(zhí)行FFmpeg的東西，已經(jīng)不計(jì)其數(shù)了。

FFmpeg不是software as a service(軟件即服務(wù))，但是我們可以把它作為一個(gè)社區(qū)來(lái)操縱視頻。我們應(yīng)該使用libav 和libav綁定。當(dāng)然，我也想強(qiáng)調(diào)Mux的視頻API與我們所討論的API到底有什么區(qū)別。我們將mixed video infrastructure (混合視頻基礎(chǔ)設(shè)施)稱(chēng)為一種服務(wù)并使用與最初構(gòu)建Zencoder的相同概念從新開(kāi)發(fā)。因此，如果我們還記得早期的Zencoder接受請(qǐng)求，這是一個(gè)用于接受和流式處理的trivial API。

?

我們可以用Mux做同樣的事情- 它是two lines而不是one line，但它仍然只有two lines。所以我們把輸入放在一個(gè)URL中，不管它是公共的還是私用的，也有一個(gè)playback policy(回放策略)。

?

這是一個(gè)供應(yīng)開(kāi)箱playback security的概念。我們?cè)俅问褂肞layback ID然后可以把它直接放到一些URL，不管是M3U8流，還是thumbnail (縮略圖) ，動(dòng)畫(huà)GIF。

他們所含的default behaviours也是非常簡(jiǎn)單的minimal API。

API結(jié)構(gòu)重要嗎？

現(xiàn)在，軟件即服務(wù)很正常。這即是標(biāo)準(zhǔn)，客戶(hù)都希望能夠減少有如JSON媒體編寫(xiě)次數(shù)。例如：Bitmovin的數(shù)百行代碼。開(kāi)發(fā)者有選擇的能力，能否選擇使用并實(shí)驗(yàn)他人的SDK。在這個(gè)情況下，開(kāi)發(fā)者會(huì)以developer-centric market中心的市場(chǎng)（目標(biāo)是開(kāi)發(fā)者與小公司），你更有可能購(gòu)買(mǎi)他們的產(chǎn)品。

?

當(dāng)初，我想列出10個(gè)簡(jiǎn)單的步驟編寫(xiě)視頻API，最終我還是得到了14個(gè)步驟。

?

首先最重要的是：你需要知道你客戶(hù)需求，誰(shuí)將使用你的API？第一個(gè)問(wèn)題是：它是internal內(nèi)部還是external外部？它是一個(gè)公共API還是你正構(gòu)建的一個(gè)產(chǎn)品？

如果這樣的話，也許你在乎speed ofintegration (集成的速度)，還有elegant API abstraction(API抽象)。如果是internal，那抽象的API可能失去價(jià)值。我們注重的close coupling (緊密耦合) – 有一個(gè)非常具體的問(wèn)題需要解決，所以必須理解這一點(diǎn)。

?

提到抽象這一點(diǎn)，你想要了解的是你試圖在目標(biāo)市場(chǎng)解決的問(wèn)題，但我真正想看的是我的客戶(hù)對(duì)視頻了解有多少？他們是想要一個(gè)在任何地方操作的線視頻平臺(tái)，還是目的只想控制我正在使用的H.264配置文件？

每個(gè)API有一個(gè)抽象級(jí)別是重要的，不是關(guān)鍵的，但它很重要。為了實(shí)現(xiàn)這一點(diǎn)，您可能需要重新安排你的API。

?

?

我們從Zencoder可見(jiàn)，如果你給它一個(gè)input輸入文件，他可以生成一個(gè) MP4 output 輸出文件。與Mux一樣 – 你給它一個(gè)輸入文件MP4的話，它可以給你一些HLS自適應(yīng)比特率輸出。所有的東西會(huì)默認(rèn)為H264 – 這些都是合理的默認(rèn)值。我們希望能達(dá)到最簡(jiǎn)單的集成，而不僅僅是默認(rèn)而已，small minimum API請(qǐng)求也重要。

這是關(guān)于 trivial authentication (瑣碎的身份驗(yàn)證)，我喜歡這樣問(wèn)自己“我的視頻API僅僅使用curl合適嗎？”如果不能的話，那么結(jié)果可能不太理想。

這是另一個(gè)例子，也是最大的在線視頻平臺(tái)的入門(mén)指南。設(shè)置身份驗(yàn)證一共有16個(gè)步驟。

對(duì)我來(lái)說(shuō)，這是一個(gè)不合格的API。因?yàn)樗谑褂肙Auth，我個(gè)人不推薦OAUTH的應(yīng)用。

?

舉個(gè)例子，Mux也是這樣。這個(gè)屏幕你得到了你的API token，第二步實(shí)際上是video ingestion攝取視頻。這是如何制作一個(gè)簡(jiǎn)單并實(shí)用的API。

你應(yīng)該在合理的地方實(shí)用established standards(既定的標(biāo)準(zhǔn))，通常HTTP和JSON是合理的選擇，XML也是我可以接受的（雖然我個(gè)人不太喜歡）。

JSON API有些標(biāo)準(zhǔn)，用來(lái)定義API結(jié)構(gòu)，它可以為request-responsepatterns 提供更好的結(jié)構(gòu)。某些情況如構(gòu)建private API時(shí)， HTTP可能不是最好的解決方案。你可以使用傳輸：message queue patterns（消息隊(duì)列模式）。我構(gòu)建了廣泛使用message queue patterns來(lái)實(shí)現(xiàn)視頻的系統(tǒng)。

如果你正在執(zhí)行microservice oriented architecture (面向微服務(wù)的體系結(jié)構(gòu))比如GRPC或Protobuf，你可以使用備用傳輸以便在close coupling的服務(wù)之前進(jìn)行通信。在此，不需要使用HTTP。

隨著產(chǎn)品的實(shí)施，你可能會(huì)重新訪問(wèn)你的API。一個(gè)API很容易偏離它的初衷，你應(yīng)該時(shí)時(shí)考慮你的API設(shè)計(jì)，想想每次修改API時(shí)是否忠于原始的API設(shè)計(jì)。

?

我很喜歡與客戶(hù)談?wù)撐业漠a(chǎn)品以及API，客戶(hù)想要一個(gè)雙向的關(guān)系，他們盡可能會(huì)以不同的方式看待你的API，所以有時(shí)候會(huì)對(duì)你的API設(shè)計(jì)給予非常誠(chéng)實(shí)、清晰的反饋。

?

有一些開(kāi)放的API toolchain 很強(qiáng)大，以下是一些以編程方式描述API的方法。你可以生成文檔，你可以生成SDK，你可以生成服務(wù)器端綁定;如果你開(kāi)始用編程的方式描述你的API，這些都是你可以用編程的方式做出的。舉幾個(gè)例子：Open API V3現(xiàn)在仍然是大搖大擺的。（我不知道他們?yōu)槭裁锤拿?#xff09;。我們使用它成功地生成SDK，反應(yīng)不錯(cuò)。Bitmovin 所構(gòu)建的API blueprint也有同樣的目的。

除此之外，無(wú)論您是否使用自動(dòng)化流程，你也應(yīng)該存儲(chǔ)你的API記錄。如果沒(méi)有充分的文檔記錄，客戶(hù)就可能不選擇你的API。你還應(yīng)該以HTTP格式存檔API；有很多趨勢(shì)，尤其是因?yàn)閬嗰R遜在存儲(chǔ)SDK方面很差。你應(yīng)該使用HTTP記錄，如果你用的是定義文件，那么這一切可以通過(guò)編程來(lái)完成。

首先，你應(yīng)該對(duì)你的API進(jìn)行版本化– 你不該等到第一次推出新版本才給一個(gè)版名，每次引入一個(gè)新版本的時(shí)候你該設(shè)定 V1 – V1 應(yīng)該是最早期版本。例如，MuxAPI; 我們說(shuō)的第一件事是視頻API，它是Video API for Data API 的一個(gè)版本。它具有相同的類(lèi)型，我們不該等到需要V2 才添加版本號(hào)。

我們必須提供一個(gè)遷移路徑，以便從V1遷移V2。若強(qiáng)迫客戶(hù)遷移服務(wù)，這對(duì)客戶(hù)也許很麻煩、多余的經(jīng)歷。在SAAS環(huán)境下，這樣做會(huì)讓客戶(hù)審查他們的供應(yīng)商決策。實(shí)際上他們積極地問(wèn)“等等，你要讓我升級(jí)整個(gè)API集成嗎？我倒不如直接去尋找一個(gè)更便宜、容易應(yīng)用的系統(tǒng)，這對(duì)于客戶(hù)保留是一個(gè)重點(diǎn)暗號(hào)。如果想解決這問(wèn)題，最好是用shims (填隙片)替換舊的API，這樣一個(gè)輕量級(jí)的shims會(huì)將V1轉(zhuǎn)換為V2,同時(shí)以新的特性鼓勵(lì)客戶(hù)升級(jí)到 V2，而不是通知“在某個(gè)時(shí)候會(huì)終止V1 API 的應(yīng)用”。

我們可以考慮構(gòu)建transcode abstraction layers(轉(zhuǎn)碼抽象層)，這是一個(gè)將generic transcode request(通用轉(zhuǎn)碼請(qǐng)求)轉(zhuǎn)換為multiple underlying encoding vendors(多個(gè)底層編碼供應(yīng)商)的一種方法。其概念就是；你把它們放在所有SAAS編碼供應(yīng)商面前，并根據(jù)成本或性能為每一個(gè)轉(zhuǎn)碼工作做出決定，最終發(fā)送的方向。

在這構(gòu)建過(guò)程中，我發(fā)現(xiàn)它的潛力非常強(qiáng)大– New York Times (紐約時(shí)報(bào))有一個(gè)很好的開(kāi)源軟件，即是我的朋友建構(gòu)的，它涵蓋了Bitmovin、Zencoder到Hibrik以及其他一些東西。

?

我們需要考慮playback security upfront(預(yù)先播放的安全性)，這就是我們討論的在線視頻平臺(tái)API。如果你正在建造類(lèi)似的東西，那你必須從零開(kāi)始。

關(guān)鍵是我們?cè)撏菩敦?zé)任給客戶(hù)，當(dāng)然的我們應(yīng)該尊重客戶(hù)的想法。如果客戶(hù)允許你播放此內(nèi)容，那我們尊重它的決定。

一般來(lái)說(shuō)，有兩種方法；第一種是在請(qǐng)求中添加客戶(hù)的crytographic signature (加密簽名)。客戶(hù)會(huì)使用JWT或某種形式的加密簽名簽署一個(gè)URL，如果與你的簽名匹配，那你尊重它。另一種方法是callbacks(回調(diào))。這是另一種方式，客戶(hù)出去定義一個(gè)URL，你可以作為供應(yīng)商去點(diǎn)擊它來(lái)決定是否可以開(kāi)始播放 - 我親眼看過(guò)兩種方式的過(guò)程，而且都成功了。

作為一個(gè)總結(jié)，這14個(gè)簡(jiǎn)單的步驟并不難！

?

在過(guò)去的10年，經(jīng)過(guò)多次的構(gòu)建改革以及糟糕的API，我時(shí)時(shí)刻刻在學(xué)習(xí)新的方式做探討。

概括起來(lái)，我認(rèn)為這是兩種類(lèi)型的視頻API編碼和平臺(tái)。一個(gè)合格良好的API對(duì)你的SAAS很重要，我建議您可以使用14條規(guī)則來(lái)幫助您構(gòu)建一個(gè)好的視頻API。

LiveVideoStackCon 2020?講師招募

2020年LiveVideoStackCon將持續(xù)迭代，4月25日-26日在上海，9月11日-12日在北京，11月在舊金山。歡迎將你的技術(shù)實(shí)踐、踩坑與填坑經(jīng)歷、技術(shù)與商業(yè)創(chuàng)業(yè)的思考分享出來(lái)，獨(dú)樂(lè)不如眾樂(lè)。請(qǐng)將個(gè)人資料和話題信息郵件到?speaker@livevideostack.com?或點(diǎn)擊【閱讀原文】了解成為L(zhǎng)iveVideoStackCon講師的權(quán)益與義務(wù)，我們會(huì)在48小時(shí)內(nèi)回復(fù)。

總結(jié)

以上是生活随笔為你收集整理的视频API的发展方向的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。