視頻傳輸延遲，尤其是在某些互動(dòng)社交環(huán)境中，會(huì)嚴(yán)重影響用戶的體驗(yàn)。Instagram多年來(lái)以降低視頻上傳延遲為重要指標(biāo)，實(shí)現(xiàn)了多種優(yōu)化策略。本文來(lái)自Instagram媒體基礎(chǔ)設(shè)施團(tuán)隊(duì)軟件工程師Ryan Peterman。

文 / Ryan Peterman

譯 / 蔣默邱澤

原文

https://instagram-engineering.com/video-upload-latency-improvements-at-instagram-bcf4b4c5520a

2013年6月，Instagram推出視頻上傳功能。當(dāng)時(shí)系統(tǒng)功能很簡(jiǎn)單，為了攝取視頻并用于播放。我們讓Instagram app在客戶端完成錄制后將整段視頻文件傳至服務(wù)器，然后我們將視頻轉(zhuǎn)碼為一組質(zhì)量可控的視頻版本，以確保視頻文件可以在盡可能多的設(shè)備上播出。一旦所有視頻都可用我們就“發(fā)布”供用戶觀看。

一個(gè)簡(jiǎn)單視頻上傳流程

Instagram在社交環(huán)境中對(duì)上傳時(shí)間反應(yīng)尤為敏感，用戶希望其他人可以盡快看到他們的視頻故事和實(shí)時(shí)消息留言。出于這個(gè)原因上傳延遲是Instagram一個(gè)非常重要的指標(biāo)。多年來(lái)，我們開(kāi)發(fā)出了多種減少延遲的策略。

讓我們首先定義本文中的上傳延遲，即服務(wù)器從客戶端接收到所有視頻碼率信息，直至視頻"可發(fā)布"或可供查看為止。

發(fā)布內(nèi)容

減少視頻上傳延遲最簡(jiǎn)單的優(yōu)化是在視頻被發(fā)布前盡可能減少步驟。我們的想法是在所有視頻版本都可用之前，先將可用的最高質(zhì)量視頻版本發(fā)布出去。其余視頻可用于回放并非強(qiáng)制性，可以為帶寬弱的用戶提供較少卡頓的回放體驗(yàn)。這樣可以有效降低處理低質(zhì)量視頻比高質(zhì)量版本花費(fèi)更多時(shí)間而造成的延遲，極大程度上提高了視頻上傳的成功率。因?yàn)槲覀冎灰蕾囈粋€(gè)版本而不是所有質(zhì)量版本。

發(fā)布內(nèi)容僅取決于高質(zhì)量的版本

我們使用基于圖形的存儲(chǔ)系統(tǒng)來(lái)表示視頻數(shù)據(jù)模型，所有視頻版本"視頻資源附加到父節(jié)點(diǎn)，這允許上傳的視頻被判斷為媒體級(jí)別而不是視頻版本級(jí)別。這種抽象實(shí)現(xiàn)了簡(jiǎn)單統(tǒng)一的發(fā)布邏輯。為了實(shí)現(xiàn)上述改進(jìn)，我們將視頻資源標(biāo)記為“可發(fā)布的”，當(dāng)我們通過(guò)視頻處理服務(wù)收到回調(diào)信息時(shí)在視頻資源中進(jìn)行翻轉(zhuǎn)布爾值。

通過(guò)讓發(fā)布信號(hào)只依賴于一個(gè)版本，使得我們的視頻處理模型更具彈性和靈活機(jī)制。如果通道在一段時(shí)間內(nèi)無(wú)法生成可選編碼，我們?nèi)匀豢梢詼?zhǔn)許發(fā)布視頻，因?yàn)槲覀儞碛凶罡哔|(zhì)量版本。之后我們可以按需補(bǔ)充其余版本。

為了使發(fā)布信號(hào)只依賴于最高質(zhì)量的版本，帶寬受限的用戶可能會(huì)體驗(yàn)次優(yōu)的回放體驗(yàn)，直到其余版本完成為止。例如，只要最高質(zhì)量的版本準(zhǔn)備好了，視頻就會(huì)發(fā)布，但是可能還有一些低質(zhì)量的版本正在處理中，這些版本要到稍后才能發(fā)布。當(dāng)帶寬受限的用戶最初觀看視頻時(shí)，如果只有最高質(zhì)量的視頻可用，他們可能會(huì)體驗(yàn)到相對(duì)較高的卡頓率與失幀率。而實(shí)際上在絕大多數(shù)情況下，編碼的其余部分在強(qiáng)制的版本完成后也會(huì)迅速可用。

視頻切片上傳處理

另一種加快視頻上傳速度的方法是讓客戶端在視頻錄制完成后對(duì)其進(jìn)行切片。一旦視頻被切片，客戶端就會(huì)把它們上傳到服務(wù)器上，并給每個(gè)切片加上索引，以便后續(xù)可以按順序重新組合。當(dāng)服務(wù)器接收到視頻切片時(shí)，并行地進(jìn)行代碼轉(zhuǎn)換，從而節(jié)省時(shí)間。一旦所有切片都被轉(zhuǎn)碼，將其組合在一起，就可以進(jìn)行播放。

通道處理部分被切片且并行

在服務(wù)端，我們將每個(gè)視頻處理流水線構(gòu)建為有向非循環(huán)圖。每個(gè)節(jié)點(diǎn)都是執(zhí)行單元，每個(gè)邊則代表兩個(gè)節(jié)點(diǎn)間的依賴關(guān)系。每個(gè)節(jié)點(diǎn)在所有依賴項(xiàng)完成后執(zhí)行運(yùn)行。這里的示例是基本非分段通道簡(jiǎn)化處理視頻過(guò)程：

在示例中大部分工作都發(fā)生在轉(zhuǎn)碼節(jié)點(diǎn)中。如果能并行化這部分，我們就可以顯著減少上傳延時(shí)。切片通道旨在通過(guò)為每個(gè)片段添加轉(zhuǎn)碼任務(wù)來(lái)并行化該部分。然后，添加一個(gè)拼接任務(wù)，將每個(gè)片段的視頻幀連接起來(lái)，放在一個(gè)新的容器中。此拼接任務(wù)取決于通道每個(gè)片段任務(wù)，如下圖：

在多數(shù)情況下切片上傳只會(huì)減少上傳延時(shí)，但質(zhì)量權(quán)衡還有其他復(fù)雜性。例如：切片上傳會(huì)增加通道復(fù)雜性。有一些質(zhì)量指標(biāo)會(huì)在轉(zhuǎn)碼時(shí)用于每個(gè)案例如SSIM。這些指標(biāo)對(duì)我們每個(gè)細(xì)分受眾群沒(méi)有幫助。但是我們需要對(duì)所有片段的SSIM進(jìn)行持續(xù)時(shí)間平均加權(quán)，以得出整個(gè)視頻的SSIM。同樣處理異常更加復(fù)雜，因?yàn)橐幚矸浅６鄶?shù)量的計(jì)算單元。

此外通過(guò)切片視頻，我們?cè)谕ǖ酪肓硪粋€(gè)步驟將所有轉(zhuǎn)碼片段拼接在一起。這需要更多CPU處理，若是非切片則不必。重要問(wèn)題是拼接步驟在最終系統(tǒng)中明顯增加了I/O要求，每個(gè)片段在單個(gè)機(jī)器進(jìn)行轉(zhuǎn)碼拼接時(shí)我們希望執(zhí)行拼接處理。因此其他節(jié)點(diǎn)必須從網(wǎng)絡(luò)下載所有片段這會(huì)大大增加I/O利用率。

在切片長(zhǎng)度上我們會(huì)處理的非常小，這樣可以并行完成更多任務(wù)。然而，由于設(shè)置節(jié)點(diǎn)對(duì)切片進(jìn)行轉(zhuǎn)碼時(shí)存在一些必須開(kāi)銷，因此我們將切片長(zhǎng)度保持在某個(gè)閾值以上。如果切片長(zhǎng)度細(xì)分的太小，那么必然浪費(fèi)資源。實(shí)際上將長(zhǎng)度設(shè)置為大約幾秒的時(shí)間對(duì)我們來(lái)說(shuō)足以。

此外就上傳延時(shí)而言，這并不總是全勝法子。隨著初始視頻縮短切片上傳的好處也相應(yīng)減少了。例如：下面描述了短視頻和長(zhǎng)視頻的非分段視頻處理和分段視頻處理相對(duì)于時(shí)間的比較。對(duì)于這兩者，我假設(shè)視頻處理時(shí)間與視頻長(zhǎng)度成正比圖。Δt 是切片和非切片通道執(zhí)行之間的上傳延時(shí)。與長(zhǎng)視頻相比，短視頻的獲勝幾率要小得多:

總的來(lái)說(shuō)，我們決定在上傳過(guò)程的開(kāi)始階段根據(jù)產(chǎn)品和視頻的長(zhǎng)度對(duì)視頻進(jìn)行切片。某些視頻產(chǎn)品（例如故事情節(jié)）已經(jīng)強(qiáng)制規(guī)定了長(zhǎng)度的最大值，這些最大值足夠短，切片不需要特別復(fù)雜。對(duì)于像IGTV這樣的視頻產(chǎn)品，規(guī)定了最小長(zhǎng)度，這樣有足夠的長(zhǎng)度使得分片上傳是有價(jià)值的。

透?jìng)?/span>

我們用來(lái)改進(jìn)上傳延遲和節(jié)省CPU利用率的另一種性能優(yōu)化稱為“透?jìng)鳌鄙蟼鳌Ｔ谀承┣闆r下，上傳的媒體已經(jīng)可以在大多數(shù)設(shè)備上播放了。如果是這樣，我們可以完全跳過(guò)視頻處理并將視頻直接存儲(chǔ)到數(shù)據(jù)模型中。這樣不僅減少了延遲而且在這種情況下我們不需要對(duì)視頻進(jìn)行轉(zhuǎn)碼。

?透?jìng)鳈z測(cè)是發(fā)布前的關(guān)鍵

這是一個(gè)非常重要的檢查步驟，以便進(jìn)入Instagram的視頻符合我們的播放標(biāo)準(zhǔn)。除了視頻轉(zhuǎn)碼通道外，我們還添加了另一種通道用于檢測(cè)傳入視頻的特定屬性。例如：編解碼器和碼率，以確認(rèn)是否視頻符合透?jìng)鞯臈l件。如果視頻的解碼器支持較少，那么能夠播放視頻的Instagram用戶就會(huì)更少。類似地，如果比特率過(guò)高，則通過(guò)網(wǎng)絡(luò)加載用于回放的視頻將花費(fèi)太長(zhǎng)時(shí)間。

一旦解碼器和碼率通過(guò)我們的篩選標(biāo)準(zhǔn)，我們就會(huì)使用內(nèi)部工具檢查視頻文件；該工具報(bào)告拓?fù)洹⒁恢滦院痛鎯?chǔ)流一致性。如果視頻文件不一致，嘗試修復(fù)原視頻文件會(huì)被啟用。這個(gè)內(nèi)部工具可以可靠的識(shí)別緩沖區(qū)溢出場(chǎng)景，使得我們不會(huì)向用戶提供任何惡略質(zhì)量文件。最后我們將修復(fù)后的視頻與原始視音頻一起轉(zhuǎn)碼并存儲(chǔ)在我們的數(shù)據(jù)模型中：

由此產(chǎn)生的透?jìng)魍ǖ辣绒D(zhuǎn)碼通道完成得更迅速。我們檢查確保視頻版本的可播放性，因此系統(tǒng)允許將資源池視頻回調(diào)并標(biāo)記發(fā)布狀態(tài)。這極大地改善了視頻處理延時(shí)并提高了視頻質(zhì)量，因?yàn)檗D(zhuǎn)碼是一個(gè)有損的過(guò)程。

這里的權(quán)衡也取決于我們?cè)O(shè)定的碼率上限，其原因有幾種：如果原始視頻的碼率太高并且執(zhí)行透?jìng)魃蟼?#xff0c;那么我們將存儲(chǔ)比轉(zhuǎn)碼視頻時(shí)更大的文件。此外，隨著碼率的增加視覺(jué)質(zhì)量反而在減少，當(dāng)這些內(nèi)容在屏幕尺寸有限的移動(dòng)設(shè)備上播放時(shí)則更加明顯。而高碼率的原始視頻在透?jìng)靼姹九c高質(zhì)量轉(zhuǎn)碼版本比較時(shí)，獲得的視覺(jué)質(zhì)量?jī)?yōu)勢(shì)較小。實(shí)際上，我們的比特率上限允許我們控制這些權(quán)衡。

總而言之，透?jìng)鲗?duì)于依賴延遲的視頻產(chǎn)品尤其有用。

下一步呢?

多年來(lái)，Instagram的視頻處理能力有了顯著提高。這種基礎(chǔ)設(shè)施以高效、可靠和高質(zhì)量方式為全球用戶提供了豐富的價(jià)值。我們也在致力于使上述程序更加高效簡(jiǎn)單。

隨著視頻的老化和與外界的互動(dòng)，一個(gè)最有希望的領(lǐng)域是根據(jù)需要生成和清除編碼。

例如，我們可能希望根據(jù)流行程度或視頻的年齡等數(shù)據(jù)更改某個(gè)視頻的表示形式。由于舊的內(nèi)容沒(méi)有那么多的觀看，我們不可能存儲(chǔ)所有的視頻版本。取而代之的是，我們可以只為那些看起來(lái)很久以前的小流量設(shè)置一個(gè)視頻版本的子集。如果一個(gè)舊視頻突然流行起來(lái)，那么我們可能會(huì)根據(jù)需要重新生成這些版本。

設(shè)計(jì)一個(gè)系統(tǒng)來(lái)管理我們?cè)诿總€(gè)視頻生命周期中所擁有的視頻表示形式涉及到許多有趣的挑戰(zhàn)。我們應(yīng)該選擇使用什么信號(hào)？如何快速有效地管理和迭代現(xiàn)有的視頻？

LiveVideoStack? 招募

LiveVideoStack正在招募編輯/記者/運(yùn)營(yíng)，與全球頂尖多媒及技術(shù)專家和LiveVideoStack年輕的伙伴一起，推動(dòng)多媒體技術(shù)生態(tài)發(fā)展。了解崗位信息請(qǐng)?jiān)贐OSS直聘上搜索“LiveVideoStack”，或通過(guò)微信“Tony_Bao_”與主編包研交流。

點(diǎn)擊【閱讀原文】或掃描圖中二維碼，了解更多大會(huì)講師及分享內(nèi)容信息！

總結(jié)

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

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