1、引言
本文來自新浪微博視頻轉(zhuǎn)碼平臺技術(shù)負(fù)責(zé)人李成亞在LiveVideoStackCon 2017上的分享，由LiveVideoStack整理成文。李成亞分享了微博短視頻如何提升用戶體驗、降低成本的思路與實踐，包括提升短視頻發(fā)布速度，降低長視頻轉(zhuǎn)碼時間，通過新的Codec減少帶寬成本等。
本文的短視頻技術(shù)跟IM的單聊、群聊、朋友圈里的小視頻是類似的東西，文中針對短視頻的相關(guān)優(yōu)化實踐可以為您的IM小視頻開發(fā)提供一定的參考和借鑒意義，希望對您有用，也感謝分享者李成亞。
學(xué)習(xí)交流：
- 即時通訊開發(fā)交流3群：185926912[推薦]
- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》
（本文同步發(fā)布于：http://www.52im.net/thread-1843-1-1.html）
2、分享者
李成亞：新浪微博視頻轉(zhuǎn)碼平臺技術(shù)負(fù)責(zé)人。15年加入新浪微博，曾參與微博混合云體系建設(shè)。在互聯(lián)網(wǎng)后端服務(wù)研發(fā)及架構(gòu)方面有多年的實踐經(jīng)驗，關(guān)注高可用，高并發(fā)，云生態(tài)等領(lǐng)域。
3、相關(guān)文章
《微信團(tuán)隊分享：微信Android版小視頻編碼填過的那些坑》
4、內(nèi)容概述
我所在的團(tuán)隊主要負(fù)責(zé)微博短視頻從客戶端的轉(zhuǎn)碼上傳到服務(wù)端的轉(zhuǎn)碼存儲的整條服務(wù)鏈路。今天主要向大家分享我們團(tuán)隊在短視頻方面有關(guān)視頻編解碼的實踐與探索。
這是一個簡單的交互圖，表示典型的生產(chǎn)者、消費(fèi)者和服務(wù)方之間的關(guān)系，其在平臺中關(guān)心的重點也會有所不同，在這里需要強(qiáng)調(diào)的是，我們今天主要討論通過技術(shù)手段改進(jìn)優(yōu)化服務(wù)并為消費(fèi)者帶來更加完善的產(chǎn)品體驗，關(guān)于用戶內(nèi)容的部分并不在此次討論的范疇。
簡單總結(jié)了一下平臺中每方關(guān)切的重點：
生產(chǎn)者關(guān)心視頻的發(fā)布速度，也就是用戶通過微博客戶端發(fā)布一段視頻，從點擊發(fā)布按鈕開始到其他人能在微博上看到此視頻所需要時間的長短；
消費(fèi)者關(guān)心視頻的觀看體驗，例如是否卡頓，流量消耗等；
服務(wù)方關(guān)心平臺的服務(wù)質(zhì)量。
5、發(fā)布速度
5.1 發(fā)送流程與關(guān)鍵性問題
先來看發(fā)布速度。首先向大家簡單介紹一下用戶通過微博客戶端發(fā)送視頻的流程。
客戶端是一個iOS或Android平臺應(yīng)用：
首先，在客戶端我們會對視頻做一次壓縮，其目的是縮小視頻體積；
接下來視頻經(jīng)過轉(zhuǎn)碼后會被作為一個整體文件單獨上傳至Web Server；
Web Server接收后會將視頻上傳到存儲服務(wù)，同時在服務(wù)端觸發(fā)轉(zhuǎn)碼操作。
此服務(wù)端轉(zhuǎn)碼的目的是：
1）視頻規(guī)范化，統(tǒng)一輸出格式，排查視頻錯誤；
2）視頻標(biāo)記處理，為視頻添加水印或標(biāo)識；
3）自動截圖。接下來服務(wù)端轉(zhuǎn)碼后也會把此視頻文件上傳至存儲服務(wù)，最后提示用戶視頻發(fā)送成功。
我想大家可以很明顯地看出來這里有三個關(guān)鍵性問題：
1）整個視頻發(fā)布是一個串行的過程。意味著一旦其中任何一個環(huán)節(jié)出現(xiàn)問題都會導(dǎo)致整個操作的失敗；
2）服務(wù)端轉(zhuǎn)碼慢。因為曾經(jīng)的服務(wù)端轉(zhuǎn)碼是一次性轉(zhuǎn)碼，我們?yōu)榱藴p小視頻壓縮的體積使用了一個比較復(fù)雜的算法。
3）長視頻發(fā)布的速度非常慢。曾經(jīng)在微博上發(fā)布一段最長一小時的視頻，其延時可達(dá)到好幾個小時。
后來我們重寫或者重構(gòu)了每條鏈路上一些關(guān)鍵節(jié)點的服務(wù)代碼。
5.2 關(guān)鍵技術(shù)優(yōu)化
下面我來介紹一下幾個關(guān)鍵的技術(shù)優(yōu)化點。
1）在客戶端我們會將編碼與上傳合并到同一個流程里，我們在客戶端中集成了一個監(jiān)控編碼器的線程以監(jiān)測編碼器完成Gop數(shù)據(jù)編碼的數(shù)量；一旦此數(shù)量累計到一定閥值后會觸發(fā)客戶端的上傳操作，客戶端將這部分?jǐn)?shù)據(jù)進(jìn)行單獨分片并上傳至Web Server，在Web Server收到所有分片之后會進(jìn)行Merge操作，最后上傳至存儲服務(wù)。
2）我們在轉(zhuǎn)碼端集成了一個調(diào)度模塊，此模塊會在發(fā)布階段為視頻做一次低復(fù)雜度的編碼以縮短視頻的發(fā)布延遲；當(dāng)完成這次低復(fù)雜度轉(zhuǎn)碼后調(diào)度器會進(jìn)行一次更高復(fù)雜度的轉(zhuǎn)碼，此轉(zhuǎn)碼完成之后會原播放鏈接會被替換，整個操作流程對用戶而言是無感知的。
3）對長視頻采取分片并進(jìn)行轉(zhuǎn)碼。其大概過程是：首先一個輸入的視頻會被分離成音頻軌和視頻軌。
其次依據(jù)其GOP，視頻軌會被切割成不同的分片，一個分片中可能包含多個GOP。但一個GOP不會被分在不同的分片中，以避免最終視頻合并時出現(xiàn)丟幀而導(dǎo)致視頻觀看卡頓的問題。
最終分片完成后，每一片會被調(diào)度器分發(fā)到不同的轉(zhuǎn)碼器同時進(jìn)行轉(zhuǎn)碼。
此時調(diào)度器會開啟一個監(jiān)聽線程去監(jiān)聽此視頻所有分片的轉(zhuǎn)碼任務(wù)，一旦調(diào)度器監(jiān)測到最后一個分片已經(jīng)處理完成便觸發(fā)一次Merge操作，把視頻流的所有分片合并成一個視頻，最后再和音頻軌合并為一個完整的輸出視頻。
5.3 總結(jié)與成果
上述流程中我們主要做了以下三點優(yōu)化：
1）客戶端：將編碼與上傳合并為一個操作；
2）服務(wù)端：分等級轉(zhuǎn)碼。在發(fā)布階段只進(jìn)行簡單復(fù)雜度的快速編碼；
3）對長視頻進(jìn)行分片并行轉(zhuǎn)碼。這里的兩個關(guān)鍵點：A：分離音視頻。B：按GOP分割視頻流。
通過上述這些優(yōu)化，我們可以提升視頻平均發(fā)布速度至原來的3倍，提升長視頻發(fā)布速度至原來的10倍以上，以上就是我們在視頻發(fā)布階段主要進(jìn)行的一些優(yōu)化。
6、觀看體驗
下面我想與大家分享一些關(guān)于觀看體驗的優(yōu)化，分享之前先為大家介紹一下產(chǎn)品形態(tài)與觀看場景：
1）產(chǎn)品形態(tài)
這是目前微博上主流的兩個視頻類產(chǎn)品，左邊是一個信息流中的視頻，其默認(rèn)播放尺寸比較小而且基本上都以橫屏呈現(xiàn)；右邊是微博于2017年初上線的一個新服務(wù)“微博故事”，這是一個全屏播放并可添加AR特效的視頻產(chǎn)品，以上是微博視頻業(yè)務(wù)的兩種產(chǎn)品形態(tài)。
2）觀看場景
觀看場景是指用戶會在什么樣的場景下觀看微博視頻。首先，在網(wǎng)絡(luò)環(huán)境上可能是Wi-Fi或移動網(wǎng)絡(luò)；在終端設(shè)備上可能是手機(jī)、Pad或PC；手機(jī)又可依據(jù)不同的操作系統(tǒng)、屏幕大小、硬件配置等等進(jìn)行細(xì)分。如果我們只做一些發(fā)布階段的工作，用戶在不同場景下選擇不同產(chǎn)品形態(tài)看到的都是同一份文件。這種方案可能在某些特定的場景下能夠帶來比較好的體驗，但是我相信對于大多數(shù)場景這種方案的體驗應(yīng)該都不是最好的，甚至很糟糕。
6.1 服務(wù)端轉(zhuǎn)碼細(xì)化
第一項優(yōu)化是在服務(wù)端進(jìn)行轉(zhuǎn)碼的細(xì)化，簡單地說就是從原來的一個輸出變?yōu)槎鄠€輸出，這些輸出之間主要的差別大概是以下三個維度：
1）分辨率從低到高。微博視頻服務(wù)的分辨率最低是240P，最高目前是720P，在未來還可以更高一些；
2）編碼復(fù)雜度從簡單編碼到復(fù)雜編碼；
3）視頻格式，例如MP4、HLS等等。
6.2 下發(fā)策略優(yōu)化
我們會在客戶端構(gòu)建一個定制化的下發(fā)策略，根據(jù)產(chǎn)品形態(tài)與用戶的網(wǎng)絡(luò)環(huán)境、設(shè)備類型、屏幕的尺寸等硬件配置來選擇一個符合此場景需求的編碼復(fù)雜度、分辨率、格式等輸出參數(shù)。通常情況下我們選擇的輸出都是此用戶在此場景下能夠以足夠清晰度播放的較低碼率視頻。
6.3 A/B Test
接下來要講的是一種常見方法叫做A/B Test，大概分為四個步驟：定義指標(biāo)、選擇對照組、變更設(shè)置、對比結(jié)果。
1）定義指標(biāo)
詳細(xì)說一下定義指標(biāo)。第一個是首幀播放延遲，簡單說就是從用戶點擊播放按紐到視頻的第一幀畫面播放出來所需要的時間，包括下載時間、解碼時間、渲染時間等等；第二個是播放失敗率；第三個是有效播放率，這里我們有兩個和播放數(shù)相關(guān)的統(tǒng)計指標(biāo)：總播放量就是只要此視頻有一幀被成功播放就算一次，有效播放量是指此視頻連續(xù)成功播放多長時間，例如三秒鐘、五秒鐘連續(xù)的播放。有效播放率就是這兩者的比值。
2）選擇對照組
關(guān)于選擇對照組我們大概有兩種方式：第一種是隨機(jī)選擇，就是從所有的微博用戶中隨機(jī)抽取20%分成兩個對照組。第二種是按特征選擇，可以確定用戶具體的某一個特征，例如是不是大V用戶或粉絲數(shù)量處于何種量級，甚至可以按照用戶登陸終端設(shè)備不同來進(jìn)行選擇。
3）變更設(shè)置
這里我們主要在兩方面進(jìn)行一些區(qū)分與調(diào)整：第一是編解碼參數(shù)，以 X264具體來說就是X264的那些編解碼參數(shù)；第二是下發(fā)策略，有時候盡管兩個用戶可能處于同一個場景，但我們依然會下發(fā)一個不同的視頻并最終看哪個視頻的數(shù)據(jù)表現(xiàn)更好。這里其實還有一些其他的調(diào)整，例如是否啟用客戶端的軟編、硬編、或軟解、硬解等等。
4）對比結(jié)果
最后就是對比結(jié)果，這里主要有兩點，第一是前文定義的核心指標(biāo)變化情況是趨于優(yōu)還是差，第二是客觀的視頻質(zhì)量對比；我們也會借助一些開源的工具來客觀對比視頻本身的指標(biāo)，例如PSNR或者SSIM，這也是A/B Test的主要內(nèi)容。需要說明的是，選擇對照組、變更設(shè)置、對比結(jié)果是不斷迭代的過程，通過不斷的去調(diào)整各種設(shè)置最終達(dá)到優(yōu)化指標(biāo)的目的。
上圖是指在 Wi-Fi 環(huán)境下微博自動播放的一種策略。既然是自動播放就涉及到一個問題：播放之前需要先下載視頻，那么需要下載多少比較合適呢？
6.4 Wi-Fi 環(huán)境下自動播放
方案一：固定長度下載
一開始我們采取的是一種叫做“固定長度下載”的方案。簡而言之就是每個視頻都提前下載一部分固定長度的數(shù)據(jù)例如265K，當(dāng)時此功能上線之后我們就發(fā)現(xiàn)了兩個比較明顯的問題：第一是視頻下載服務(wù)器占用帶寬有很大的上升。因為自動播放的功能，當(dāng)天的播放量已經(jīng)上升到之前的兩倍多，其中一部分播放量最終回到視頻的下載原站；第二是有部分的視頻依然會出現(xiàn)輕微的卡頓感。
簡單解釋一下這兩個問題的原因，其實這兩個原因都和下載方式不正確有關(guān)系。帶寬占用飆升是因為自動下載導(dǎo)致用戶下載得太多，卡頓感是因為自動下載下的內(nèi)容還不足以支撐流暢的播放體驗。關(guān)于第二點需要進(jìn)行解釋的是：我們知道對于一個視頻文件，比如說MP4，它的一些Meta信息或Moov信息是在頭部的，并且此信息的長度與視頻本身的長度相關(guān)，也就是說視頻越長這部分的信息提取量越大，所以對于一些短視頻自動下載256K可能太多，但對于長視頻下載256K又太少。
方案二：固定時間下載
我們想到了一種固定時間下載的方案，簡而言之就是對每個視頻都先計算好一部分例如前三秒鐘的數(shù)據(jù)大小，我們在服務(wù)端轉(zhuǎn)碼的同時會計算出此視頻包含的Meta信息、Moov信息、前三幀的MBAT等加起來有多大；在用戶瀏覽信息流的同時和這些信息將與播放鏈接一起下發(fā)至客戶端。需要進(jìn)行解釋的是這個3秒是基于我們反復(fù)調(diào)整測試最終得出的一個最佳值，可以在明顯消除自動播放卡頓感的同時控制帶寬的占用。
6.5 提高視頻源的質(zhì)量
之前微博對發(fā)布視頻的壓縮門檻有了一個質(zhì)的提升，從480P提高到了720P，并且對全部的微博用戶都開放了此權(quán)限。我們未來還可能實現(xiàn)1080P的上傳，可以看到隨著分辨率的提升對比左右兩個視頻畫面差距十分明顯。
6.6 小結(jié)
簡單總結(jié)一下對于觀看體驗方面的幾項重要優(yōu)化：
第一是我們依據(jù)定制化的下發(fā)策略根據(jù)用戶場景自動下發(fā)最符合此場景的視頻；
第二是我們使用A/B Test來幫助不斷完善幾項核心指標(biāo)，從而優(yōu)化觀看體驗；
第三是我們實現(xiàn)了Wi-Fi下的自動播放；
第四是提升上傳視頻的質(zhì)量。
7、服務(wù)質(zhì)量
作為服務(wù)提供方的我們比較關(guān)心的問題可以概括成一句話：怎么既穩(wěn)定又省錢地提供高質(zhì)量的短視頻服務(wù)？這句話有兩個關(guān)鍵點：穩(wěn)定、省錢。為了保證穩(wěn)定我們做得更多的其實是一些類似于多機(jī)房部署等架構(gòu)方面的工作，在此不用贅述。
7.1 降低成本
省錢，是指成本優(yōu)化方面。在這里主要有兩個降低成本的思路：
【思路一：保持畫質(zhì)，提高編碼復(fù)雜度，降低碼率】
思路一可以簡單理解為一個用時間換空間的方案。我們知道隨著編解碼器的發(fā)展，在其編碼的復(fù)雜度越來越高的同時帶寬與碼率是越來越低，同等碼率下視頻質(zhì)量越來越高。以H.265為例，官方給出的比較有代表性的數(shù)據(jù)是H.265相對于H.264而言其編碼復(fù)雜度大概提升至后者的10倍，而碼率能夠達(dá)到H.264的50%。如此高的一個編碼成本提升，如果是在客戶端或是服務(wù)端進(jìn)行都是不現(xiàn)實的。于是我們構(gòu)想了一種新的思路：熱門視頻的極限轉(zhuǎn)碼。
思路一優(yōu)化：熱門視頻極限轉(zhuǎn)碼
（1）業(yè)務(wù)特點
簡單介紹一下，微博具有一個很明顯的熱點+長尾的業(yè)務(wù)特點，可能每天TOP2000或TOP1000部分的視頻會占到當(dāng)天視頻播放量的50%以上，而絕大部分視頻的播放量很低，只能占10%～20%。根據(jù)此種業(yè)務(wù)特點，我們提出了這種只對一部分熱門視頻進(jìn)行極限轉(zhuǎn)碼的方案，從而最大程度地節(jié)省計算成本，降低帶寬消耗。
（2）熱點判斷
如何判斷某個視頻是否為熱門視頻？我們主要從以下兩個方面：第一是預(yù)判。在其發(fā)布階段，我們根據(jù)發(fā)布方的影響力預(yù)判其是否為熱門視頻，在這里我們并沒有什么非常復(fù)雜的機(jī)器學(xué)習(xí)算法，而是可以簡單理解為根據(jù)用戶的粉絲數(shù)作出判斷。第二是跟蹤。可能有些視頻在發(fā)布階段并沒有被判定為一個熱門視頻，但是可能因為某位微博大V轉(zhuǎn)發(fā)了他的視頻或者因為這個視頻本身很有意思從而帶來播放量的爆發(fā)性增長。在這里我們會有一個程序去統(tǒng)計某個時間段t內(nèi)全站播放量Top x的一部分視頻；隨后這部分中還未進(jìn)行極限轉(zhuǎn)碼的視頻，會被調(diào)度器投放至一個工作隊列中進(jìn)行極限轉(zhuǎn)碼。這里的一個小細(xì)節(jié)是我們的統(tǒng)計時間段t與統(tǒng)計視頻數(shù)量x都可根據(jù)機(jī)群的工作負(fù)載進(jìn)行動態(tài)調(diào)整。如果機(jī)群整體負(fù)載較高，我們會把這兩個數(shù)值調(diào)低以避免熱門視頻的轉(zhuǎn)碼對正常發(fā)布視頻的轉(zhuǎn)碼任務(wù)造成過多影響；如果機(jī)群整體負(fù)載較低，我們就可把這兩個數(shù)適當(dāng)調(diào)大以轉(zhuǎn)碼處理更多低碼率視頻從而降低帶寬成本。
（3）方案選擇
關(guān)于方案選擇，在這里我只是提供一些可供選擇的思路，大概是有三種：第一是更換編解碼器例如H.265或AV1；第二是使用一些機(jī)器學(xué)習(xí)的技術(shù)進(jìn)行場景識別，判斷此視頻的類型，從而優(yōu)化編碼過程。第三是使用云服務(wù)，業(yè)內(nèi)的一些云服務(wù)提供商都能提供這種高復(fù)雜度轉(zhuǎn)碼能力的服務(wù)。
（4）意義與影響
通過采用對熱門視頻進(jìn)行極限轉(zhuǎn)碼的方案，我們可以實現(xiàn)20%～40%的碼率下降；而在目前所有微博視頻播放量中通過這種高復(fù)雜度轉(zhuǎn)碼處理的視頻的占比可達(dá)到一半以上，與此同時日帶寬節(jié)省在一百TB以上。
【思路二：保持畫質(zhì)，保持編碼復(fù)雜程度，降低成本】
思路二是保持畫質(zhì)、保持編碼復(fù)雜度的同時降低成本。上圖是一個比較簡單的視頻轉(zhuǎn)碼流程，從視頻輸入到解封裝，再到視頻的解碼與處理，經(jīng)過視頻的編碼最后封裝與合并到輸出。此流程可以說本身已經(jīng)沒有什么優(yōu)化的余地。
思路二優(yōu)化：多輸出轉(zhuǎn)碼
但這里有一個前提就是其輸出并不是只有一個而是多個。這些輸出之間的差別可能就是分辨率或格式，其他的大部分的參數(shù)是一樣的。所以我們可以復(fù)用解碼的一個環(huán)節(jié)：可以看到上圖的后半段，在視頻流解碼完成之后視頻會被復(fù)制出多份，每份會進(jìn)行單獨的視頻轉(zhuǎn)碼，緊接著復(fù)制出的每一個流會與音頻流合并成一個單獨的輸出，最終通過此方式我們可以同時轉(zhuǎn)出多個輸出。
意義與影響：通過這種方式我們可實現(xiàn)整體轉(zhuǎn)碼耗時節(jié)省15%左右。
7.2 降低集群冗余度
我們都知道現(xiàn)在很多的互聯(lián)網(wǎng)業(yè)務(wù)都會面臨一個流量明顯變化的過程，例如一天中某個時間段會出現(xiàn)流量的高峰或低谷，如果希望集群能夠經(jīng)受住流量高峰的考驗就需要保持一個比較高的冗余度，可能需要保持1.5甚至2倍的冗余，才能在流量高峰時段保證互聯(lián)網(wǎng)服務(wù)的穩(wěn)定進(jìn)行。
以下是關(guān)于此方面我們進(jìn)行的一些工作。
消除差異：
首先，在整個短視頻服務(wù)的環(huán)節(jié)中，整條鏈路由以下四個服務(wù)構(gòu)成：上傳服務(wù)、轉(zhuǎn)碼服務(wù)、存儲服務(wù)、業(yè)務(wù)服務(wù)。這些服務(wù)所需要的配置、運(yùn)行環(huán)境，甚至實現(xiàn)語言都是不一樣的，而每個服務(wù)都有自己的流量高峰與低谷。這便導(dǎo)致了這樣一個問題：如果按傳統(tǒng)方式，需要每個服務(wù)始終保持一個比較高的冗余度，那么所有服務(wù)加起來整個集群的冗余度就會顯得非常高，從而造成一些浪費(fèi)。所以我們需要做的是抹除這些服務(wù)之間的差異。具體來說是通過最近幾年在后端領(lǐng)域很火的Docker技術(shù)將包括配置代碼在內(nèi)的整個運(yùn)行環(huán)境打包成一個鏡像，可以簡單理解為一個壓縮包；我們所有的服務(wù)依賴的都是這種Docker服務(wù)，只要在機(jī)器上安裝Docker軟件就可以隨時啟用所需服務(wù)。通過這種方式可以將之前處于高冗余度下的四個集群轉(zhuǎn)變?yōu)橐粋€集群，此機(jī)群只要保持一定的冗余度就可完成服務(wù)的承載。
定時擴(kuò)容：
上圖是微博大致的每天流量變化趨勢，最右邊那部分是晚8點到次日凌晨0點的晚高峰，可以說幾乎每天流量都是以這種趨勢變化，晚高峰時段流量會比白天大部分時間段高出20%～30%的樣子，面對這種情況我們會在高峰時段通過一些公有云服務(wù)擴(kuò)充出的一些計算資源承擔(dān)這部分高峰流量；當(dāng)高峰期結(jié)束便撤下這些公有云服務(wù)以盡可能降低服務(wù)的整體成本。
彈性擴(kuò)容：
上圖是之前鹿晗發(fā)微博公開戀情的半個小時內(nèi)，微博一些核心服務(wù)的流量變化。可以看到從12點的值到最高峰，不到半個小時流量基本翻了4倍。這種量級的上漲是無法通過諸如降級或流量調(diào)配等人工干預(yù)手段有效應(yīng)對，這便要求我們的服務(wù)器必須具備快速且大批量的彈性擴(kuò)容能力。當(dāng)天我們也是從阿里云上緊急擴(kuò)容了超過一千臺的服務(wù)器，最終將此熱點事件造成的流量爆炸性增長化險為夷。
7.3 成本優(yōu)化總結(jié)
簡單總結(jié)一下我們在成本優(yōu)化方面做的一些工作：
首先是對熱門視頻進(jìn)行極限轉(zhuǎn)碼，通過以最小的計算資源去獲取最大帶寬節(jié)省來降低成本；
其次是我們多輸出轉(zhuǎn)碼，整體上降低一些編碼的成本，隨著發(fā)布的視頻的質(zhì)量越來越高，多輸出轉(zhuǎn)碼降低成本所帶來的收益應(yīng)該會繼續(xù)提高；
第三是根據(jù)業(yè)務(wù)的流量變化通過一些彈性擴(kuò)容的手段來動態(tài)調(diào)整集群的規(guī)模。
附錄：更多音視頻開發(fā)文章
《即時通訊音視頻開發(fā)（一）：視頻編解碼之理論概述》
《即時通訊音視頻開發(fā)（二）：視頻編解碼之?dāng)?shù)字視頻介紹》
《即時通訊音視頻開發(fā)（三）：視頻編解碼之編碼基礎(chǔ)》
《即時通訊音視頻開發(fā)（四）：視頻編解碼之預(yù)測技術(shù)介紹》
《即時通訊音視頻開發(fā)（五）：認(rèn)識主流視頻編碼技術(shù)H.264》
《即時通訊音視頻開發(fā)（六）：如何開始音頻編解碼技術(shù)的學(xué)習(xí)》
《即時通訊音視頻開發(fā)（七）：音頻基礎(chǔ)及編碼原理入門》
《即時通訊音視頻開發(fā)（八）：常見的實時語音通訊編碼標(biāo)準(zhǔn)》
《即時通訊音視頻開發(fā)（九）：實時語音通訊的回音及回音消除概述》
《即時通訊音視頻開發(fā)（十）：實時語音通訊的回音消除技術(shù)詳解》
《即時通訊音視頻開發(fā)（十一）：實時語音通訊丟包補(bǔ)償技術(shù)詳解》
《即時通訊音視頻開發(fā)（十二）：多人實時音視頻聊天架構(gòu)探討》
《即時通訊音視頻開發(fā)（十三）：實時視頻編碼H.264的特點與優(yōu)勢》
《即時通訊音視頻開發(fā)（十四）：實時音視頻數(shù)據(jù)傳輸協(xié)議介紹》
《即時通訊音視頻開發(fā)（十五）：聊聊P2P與實時音視頻的應(yīng)用情況》
《即時通訊音視頻開發(fā)（十六）：移動端實時音視頻開發(fā)的幾個建議》
《即時通訊音視頻開發(fā)（十七）：視頻編碼H.264、VP8的前世今生》
《實時語音聊天中的音頻處理與編碼壓縮技術(shù)簡述》
《網(wǎng)易視頻云技術(shù)分享：音頻處理與壓縮技術(shù)快速入門》
《學(xué)習(xí)RFC3550：RTP/RTCP實時傳輸協(xié)議基礎(chǔ)知識》
《基于RTMP數(shù)據(jù)傳輸協(xié)議的實時流媒體技術(shù)研究（論文全文）》
《聲網(wǎng)架構(gòu)師談實時音視頻云的實現(xiàn)難點(視頻采訪)》
《淺談開發(fā)實時視頻直播平臺的技術(shù)要點》
《還在靠“喂喂喂”測試實時語音通話質(zhì)量？本文教你科學(xué)的評測方法！》
《實現(xiàn)延遲低于500毫秒的1080P實時音視頻直播的實踐分享》
《移動端實時視頻直播技術(shù)實踐：如何做到實時秒開、流暢不卡》
《如何用最簡單的方法測試你的實時音視頻方案》
《技術(shù)揭秘：支持百萬級粉絲互動的Facebook實時視頻直播》
《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》
《移動端實時音視頻直播技術(shù)詳解（一）：開篇》
《移動端實時音視頻直播技術(shù)詳解（二）：采集》
《移動端實時音視頻直播技術(shù)詳解（三）：處理》
《移動端實時音視頻直播技術(shù)詳解（四）：編碼和封裝》
《移動端實時音視頻直播技術(shù)詳解（五）：推流和傳輸》
《移動端實時音視頻直播技術(shù)詳解（六）：延遲優(yōu)化》
《理論聯(lián)系實際：實現(xiàn)一個簡單地基于HTML5的實時視頻直播》
《IM實時音視頻聊天時的回聲消除技術(shù)詳解》
《淺談實時音視頻直播中直接影響用戶體驗的幾項關(guān)鍵技術(shù)指標(biāo)》
《如何優(yōu)化傳輸機(jī)制來實現(xiàn)實時音視頻的超低延遲？》
《首次披露：快手是如何做到百萬觀眾同場看直播仍能秒開且不卡頓的？》
《Android直播入門實踐：動手搭建一套簡單的直播系統(tǒng)》
《網(wǎng)易云信實時視頻直播在TCP數(shù)據(jù)傳輸層的一些優(yōu)化思路》
《實時音視頻聊天技術(shù)分享：面向不可靠網(wǎng)絡(luò)的抗丟包編解碼器》
《P2P技術(shù)如何將實時視頻直播帶寬降低75%？》
《專訪微信視頻技術(shù)負(fù)責(zé)人：微信實時視頻聊天技術(shù)的演進(jìn)》
《騰訊音視頻實驗室：使用AI黑科技實現(xiàn)超低碼率的高清實時視頻聊天》
《微信團(tuán)隊分享：微信每日億次實時音視頻聊天背后的技術(shù)解密》
《近期大熱的實時直播答題系統(tǒng)的實現(xiàn)思路與技術(shù)難點分享》
《福利貼：最全實時音視頻開發(fā)要用到的開源工程匯總》
《七牛云技術(shù)分享：使用QUIC協(xié)議實現(xiàn)實時視頻直播0卡頓！》
《實時音視頻聊天中超低延遲架構(gòu)的思考與技術(shù)實踐》
《理解實時音視頻聊天中的延時問題一篇就夠》
《實時視頻直播客戶端技術(shù)盤點：Native、HTML5、WebRTC、微信小程序》
《寫給小白的實時音視頻技術(shù)入門提綱》
《微信多媒體團(tuán)隊訪談：音視頻開發(fā)的學(xué)習(xí)、微信的音視頻技術(shù)和挑戰(zhàn)等》
《騰訊技術(shù)分享：微信小程序音視頻技術(shù)背后的故事》
《微信多媒體團(tuán)隊梁俊斌訪談：聊一聊我所了解的音視頻技術(shù)》
《新浪微博技術(shù)分享：微博短視頻服務(wù)的優(yōu)化實踐之路》
>> 更多同類文章 ……
（本文同步發(fā)布于：http://www.52im.net/thread-1843-1-1.html）