實時音視頻面視必備：快速掌握11個視頻技術相關的基礎概念

本文作者Ahab，原題「視頻相關的理論知識與基礎概念」，收錄時有修訂和改動。

1、引言

隨著移動網際網路的普及，實時音視頻技術已經在越來越多的場景下發揮重要作用，已經不再局限於IM中的實時視頻聊天、實時視頻會議這種功能，在遠程醫療、遠程教育、智能家居等等場景也司空見慣。

雖然實時音視頻技術的應用越來越普及，但對於程式設計師來說，這方面的技術門檻仍然存在（準備地說是仍然很高），想要在短時間內全面掌握實時音視頻相關的技術難度非常大。

以IM中的實時音視頻聊天為例，一個簡化了的視頻聊天技術，本質就是：音視頻技術+網絡技術的組合體，如下圖所示：網絡模塊之上的部分，就是音視頻技術所涉及的範疇。

▲ 圖片引用自《微信小程序音視頻技術背後的故事》

所以，想學習實時音視頻開發，一般都是先學習音視頻相關的技術知識，至於網絡技術，完全可以分開學習。

不過，作為想從事這方面工作的小白面視者，是無法在短時間內全面掌握音視頻技術，但可以通過快速了解相關的知識概念，在自已在腦中快速組織起相應的知識圖譜，有助於日後針對相關知識點逐個深入學習和研究，也算是一種高效的技術學習方法。

本文將通過通俗的文字，言簡意賅地為你講解實時音視頻技術中跟視頻技術在關的11個非常重要的基礎知識概念，希望能為你日後從事這方面的工作起到拋磚引玉的作用。

學習交流：

開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK

（本文同步發布於：http://www.52im.net/thread-3194-1-1.html）

2、關於作者

王英豪：現居廣州。

Github : https://github.com/yhaolpz

CSDN: http://blog.csdn.net/yhaolpz

個人博客 : http://yhaowa.gitee.io

3、參考資料

[1] 零基礎，史上最通俗視頻編碼技術入門

[2] 零基礎入門：實時音視頻技術基礎知識全面盤點

[3] 理解實時音視頻聊天中的延時問題一篇就夠

4、什麼是視頻？

根據人眼視覺暫留原理，每秒超過 24 幀的圖像變化看上去是平滑連續的，這樣的連續畫面的播放叫視頻。

通俗來說說，視頻相當於連續展示多張圖片，原理就像下面這樣：

▲ 圖片引用自《零基礎，史上最通俗視頻編碼技術入門》

5、什麼是解析度？

5.1 基礎

解析度是以橫向和縱向的像素數量來衡量的，表示平面圖像的精細程度。視頻精細程度並不只取決於視頻解析度，還取決於屏幕解析度。

1080P 的 P 指 Progressive scan（逐行掃描），即垂直方向像素點，也就是 "高"，所以 1920 * 1080 叫 1080P， 不叫 1920P。

5.2 上採樣

當 720P 的視頻在 1080P 屏幕上播放時，需要將圖像放大，放大操作也叫上採樣。

「上採樣」幾乎都是採用內插值方法，即在原有圖像的像素點之間採用合適的插值算法插入新的元素，所以圖像放大也稱為圖像插值。

簡單的記錄一下插值算法：

常見插值算法技術原理：

1）鄰插值算法：將四個像素（放大一倍）用原圖一個像素的顏色填充，較簡單易實現，早期的時候應用比較普遍，但會產生明顯的鋸齒邊緣和馬賽克現象；

2）雙線性插值法：是對鄰插值法的一種改進，先對兩水平方向進行一階線性插值，再在垂直方向上進行一階線性插值。能有效地彌補鄰插值算法的不足，但還存在鋸齒現象並會導致一些不期望的細節柔化；

3）雙三次插值法：是對雙線性插值法的改進，它不僅考慮到周圍四個直接相鄰像素點灰度值的影響，還考慮到它們灰度值變化率的影響，使插值生成的像素灰度值延續原圖像灰度變化的連續性，從而使放大圖像濃淡變化自然平滑。

除此之外還有很多更複雜效果更優的算法，比如小波插值、分形等等。

5.3 下採樣

當 1080P 的視頻在 720P 屏幕上播放時，需要將圖像縮小，縮小操作也叫下採樣。

「下採樣」的定義為：對於一個樣值序列，間隔幾個樣值取樣一次，得到新序列。

對於一幅解析度為 MxN 的圖像，對其進行 s 倍下採樣，即得到 (M/s)x(N/s) 解析度的圖像（s 應為 M、N 的公約數），就是把原始圖像 sxs 窗口內的圖像變成一個像素，這個像素點的值就是窗口內所有像素的均值。

最佳體驗為屏幕與視頻解析度相同且全屏播放，視頻解析度過高的話屏幕沒有能力去呈現，視頻解析度過低的話無法發揮屏幕的能力。

6、什麼是比特率？

6.1 基礎

比特率即碼率，在不同領域有不同的含義，在多媒體領域，指單位時間播放音頻或視頻的比特數，可以理解成吞吐量或帶寬。

單位為 bps , 即 bits per second，每秒傳輸的數據量，常用單位有：kbps、mbps 等。

計算公式：碼率（kbps）= 文件大小（kb）/ 時長（s）

通俗一點理解就是取樣率，取樣率越大，精度就越高，圖像質量越好，但數據量也越大，所以要找到一個平衡點：用最低的比特率達到最少的失真。

在一個視頻中，不同時段畫面的複雜程度是不同的，比如高速變化的場景和幾乎靜止的場景，所需的數據量也是不同的，若都使用同一種比特率是不太合理的，所以引入了動態比特率。

6.2 動態比特率

簡稱為 VBR，即 Variable Bit Rate，比特率可以隨著圖像複雜程度的不同而隨之變化。

圖像內容簡單的片段採用較小的碼率，圖像內容複雜的片段採用較大的碼率，這樣既保證了播放質量，又兼顧了數據量的限制。

比如 RMVB 視頻文件，其中的 VB 就是指 VBR，表示採用動態比特率編碼方式，達到播放質量與體積兼得的效果。

6.3 靜態比特率

簡稱為 CBR，即 Constant Bit Rate，比特率恆定。

圖像內容複雜的片段質量不穩定，圖像內容簡單的片段質量較好。上面列出的計算公式顯然是針對 CBR ，除 VBR 和 CBR 外，還有 CVBR（Constrained VariableBit Rate） 、ABR (Average Bit Rate) 等等。

7、什麼是採樣率？

定義：每秒從連續信號中提取並組成離散信號的採樣個數，單位為赫茲（Hz）。對於取樣率、採樣率和抽樣率，沒必要糾結它們的區別，都是同義詞。

視頻一般不標識採樣率屬性，比如：

採樣率本身就是一個可泛化的概念，對於視頻來說，若非要用採樣率來描述的話，那就要分為兩個層面：幀頻和場頻。

1）從幀頻層面來說：採樣率就是指幀率，指 1 秒鐘顯示多少幀圖像；

2）從場頻層面來說：採樣率就是指像素頻率，指 1 秒鐘顯示多少個像素。

像素頻率是顯示器的一個指標，可以理解成顯示器的最大帶寬，可以起到限制解析度和刷新率的作用。

根據含義可得出一個公式：

像素頻率 = 幀率 X 幀像素數量

對於：

幀率 = 138.5 x 1024 x 1024 / 1920 / 1080 ≈ 70.04 ， 得出的 70Hz 為正常的幀率範圍，也可以反向確定對像素頻率的理解是正確的。

8、什麼是幀率？

定義：用於測量顯示幀數的量度。單位為 FPS（Frames per Second，每秒顯示幀數）或赫茲（Hz）。

幀率越高，畫面越流暢、逼真，對顯卡的處理能力要求越高，數據量越大。

文章開頭，我們提到每秒超過 24 幀的圖像變化看上去是平滑連續的，這是針對電影等視頻而言，對遊戲來說 24 幀不一定就是流暢的。

為什麼 24fps 的電影感覺流暢，而 24fps 的遊戲就感覺很卡呢？

第一個原因：兩者圖像生成原理不同

電影的一幀在一段時間曝光，每一幀都包含一段時間的信息，而遊戲的畫面則是由顯卡計算生成的，一幀只包含那一瞬間的信息。

比如一個圓從左上角移動到右下角：

前者為電影的一幀，後者為遊戲的一幀，可以看到在電影中動作會出現拖影，給人以動感的效果，連貫而不卡。

第二個原因：電影的FPS是穩定的，而遊戲則是不穩定的

電影若為 24fps，那就表示每隔 1/24 秒刷新一次畫面，幀間隔是固定的。

遊戲若為 60fps，表示大約每隔 1/60 秒刷新一次畫面，幀間隔是不穩定的，即使 1 秒能顯示 60 幀，那也可能是前半秒顯示了 59 幀，後半秒顯示了 1 幀。

9、什麼是視頻編碼？

9.1 基礎

定義：通過特定的壓縮技術，將某個視頻格式的文件轉換成另一種視頻格式。視頻數據在時域和空域層面都有極強的相關性，這也表示有大量的「時域冗餘信息」和「空域冗餘信息」，壓縮技術就是去掉數據中的冗餘信息。

9.2 無損壓縮

無損壓縮也稱為可逆編碼，重構後的數據與原數據完全相同，適用於磁碟文件的壓縮等。無損壓縮主要採用熵編碼方式，包括香農編碼、哈夫曼編碼和算術編碼等。

9.2.1）香農編碼：

香農編碼採用信源符號的累計概率分布函數來分配碼字，效率不高，實用性不大，但對其他編碼方法有很好的理論指導意義。

9.2.2）哈夫曼編碼：

哈夫曼編碼完全依據出現概率來構造異字頭的平均長度最短的碼字。

基本方法為：先對圖像數據掃描一遍，計算出各種像素出現的概率，按概率的大小指定不同長度的唯一碼字，由此得到一張該圖像的霍夫曼碼錶。

編碼後的圖像數據記錄的是每個像素的碼字，而碼字與實際像素值的對應關係記錄在碼錶中。

9.2.3）算術編碼：

算術編碼是用符號的概率和編碼間隔兩個基本參數來描述的，在給定符號集和符號概率的情況下，算術編碼可以給出接近最優的編碼結果。

使用算術編碼的壓縮算法通常先要對輸入符號的概率進行估計，然後再編碼，估計越準，編碼結果就越接近最優的結果。

9.3 有損壓縮

有損壓縮也稱為不可逆編碼，重構後的數據與原數據有差異，適用於任何允許有失真的場景，例如視頻會議、可視電話、視頻廣播、視頻監控等。

編碼方式包括預測編碼、變換編碼、量化編碼、混合編碼等。

10、什麼是編碼標準？

10.1 基礎

定義：為保證編碼的正確性，編碼要規範化、標準化，所以就有了編碼標準。

研製視頻編碼標準的有兩大正式組織：

1）ISO/IEC（國際標準化組織）；

2）ITU-T（國際電信聯盟通信標準部）。

ISO/IEC 制定的編碼標準有：MPEG-1、MPEG-2、MPEG-4、MPEG-7、MPEG-21 和 MPEG-H 等。

ITU-T 制定的編碼標準有：H.261、H.262、H.263、H.264 和 H.265 等。

MPEG-x 和 H.26x 標準的視頻編碼都是採用有損壓縮的混合編碼方式，主要區別在於處理圖像的解析度、預測精度、搜索範圍、量化步長等參數的不同，所以其應用場合也不同。

10.2 MPEG-x 系列

10.2.1）MPEG-1：

MPEG-1 共 5 部分。

第 2 部分視頻編碼方案，規定了逐行掃描視頻的編碼方案。

第 3 部分音頻編碼方案，將音頻流的壓縮分為 3 層並依次增大壓縮比，廣為流傳的 MP3（MPEG-1 Layer 3）就是按照此部分編碼方案壓縮之後的文件格式。

10.2.2）MPEG-2：

MPEG-2 共 11 個部分，在 MPEG-1 的基礎上提高了碼率和質量。

第 2 部分視頻編碼方案，規定了隔行掃描視頻的編碼方案，是和 ITU-T 共同開發的，ITU-T 稱其為 H.262。

第 3 部分音頻編碼方案，延續了 MPEG-1 的 3 層壓縮方案，壓縮後文件格式仍為 MP3，但在壓縮算法上有所改進。

第 7 部分首次提出 AAC（MPEG Advanced Audio Coding）編碼，目的以更小的容量和更好的音質取代 MP3 格式。

10.2.3）MPEG-4：

MPEG-4 共 27 個部分，更加注重多媒體系統的交互性和靈活性。

第 3 部分音頻編碼方案，優化了 AAC 編碼算法，並在推出後逐漸取代 MP3，比如和視頻封裝在一起的音頻優先考慮 AAC 格式，但就民用而言大部分還是使用 MP3 格式。

第 10 部分提出 AVC（Advanced Video Coding）編碼，是和 ITU-T 共同開發的，ITU-T 稱其為 H.264。

第 14 部分提出了 MP4 格式封裝，官方文件後綴名是 ".mp4"，還有其他的以 mp4 為基礎進行的擴展或縮水版本的格式，包括：M4V, 3GP, F4V 等。

10.2.4）MPEG-7：

MPEG-7 不同於 MPEG-1、MPEG-2、MPEG-4，它不是音視頻壓縮標準。

MPEG-7 被稱為 "多媒體內容描述接口"，目的就是產生一種描述多媒體信息的標準，並將該描述與所描述的內容相聯繫，以實現快速有效的檢索。

10.2.5）MPEG-12：

MPEG-12 其實就是一些關鍵技術的集成，通過這種集成環境對全球數字媒體資源進行管理，實現內容描述、創建、發布、使用、識別、收費管理、版權保護等功能。

10.2.6）MPEG-H：

MPEG-H 包含了 1 個數字容器標準、1 個視頻壓縮標準、1 個音頻壓縮標準和 2 個一致性測試標準。

其中視頻壓縮標準為高效率視頻編碼（HEVC），和 ITU-T 聯合開發，相比 H.264/MPEG-4 AVC 數據壓縮率增加了 1 倍。

10.3 H.26x 系列

10.3.1）H.261：

H.261 是第一個實用的數字視頻編碼標準，使用了混合編碼框架，包括了基於運動補償的幀間預測，基於離散餘弦變換的空域變換編碼，量化，zig-zag 掃描和熵編碼。

H.261 的設計相當成功，之後的視頻編碼國際標準基本上都是基於 H.261 的設計框架，包括 MPEG-1，MPEG-2／H.262，H.263，甚至 H.264。

10.3.2）H.262：

H.262 由 MPEG-1 擴充而來，支持隔行掃描，在技術內容上和 MPEG-2 視頻標準一致，DVD 就是採用了該技術。

10.3.3）H.263：

H.263 是一種用於視頻會議的低碼率視頻編碼標準，在 H.261 基礎上發展而來。

與 H.261 相比採用了半象素的運動補償，並增加了 4 種有效的壓縮編碼模式，在低碼率下能夠提供比 H.261 更好的圖像效果。

H.263 於 1995 年推出第一版，後續在 1998 年和 2000 年還推出了第二版 H.263+、第三版 H.263++ 。

10.3.4）H.264：

H.264 又稱為 MPEG-4 第 10 部分，即 MPEG-4 AVC，它是一種面向塊，基於運動補償的視頻編碼標準。

於 2003 年正式發布，現在已經成為高精度視頻錄製、壓縮和發布的最常用格式之一。

H.264 可以在低碼率情況下提供高質量的視頻圖像，相比 H.263 可節省 50% 的碼率。

相比 H.263，H.264 不需設置較多的編碼選項，降低了編碼的複雜度。

H.264 可以根據不同的環境使用不同的傳輸和播放速率，並且提供了豐富的錯誤處理工具，可以很好的控制或消除丟包和誤碼。

H.264 性能的改進是以增加複雜性為代價而獲得的，H.264 編碼的計算複雜度大約相當於 H.263 的 3 倍，解碼複雜度大約相當於 H.263 的 2 倍。

H.264 協議中定義了三種幀，分別為 I 幀、P 幀以及 B 幀：

1）I 幀：I幀即幀內編碼幀、關鍵幀，可以理解為一幀畫面的完整保留，解碼時只需要本幀數據就可以完成，不需要參考其他畫面，數據量比較大；

2）P 幀：P幀即前向預測編碼幀，記錄當前幀跟上一關鍵幀（或P幀）的差別，解碼時依賴之前緩存的畫面，疊加上本幀定義的差別，才能生成最終畫面，數據量較 I 幀小很多；

3）B 幀：B幀即雙向預測編碼幀，記錄當前幀跟前後幀的差別，解碼時依賴前面的I幀（或P幀）和後面的P幀，數據量比I幀和P幀小很多。

數據壓縮比大約為：I幀：P幀：B幀 = 7：20：50，可見 P 幀和 B 幀極大的節省了數據量，節省出來的空間可以用來多保存一些 I 幀，以實現在相同碼率下，提供更好的畫質。

10.3.5）H.265：

H.265 即高效視頻編碼（High Efficiency Video Coding ，簡稱 HEVC），於 2013 年正式推出。

H.265 編碼架構和 H.264 相似，主要也包含，幀內預測、幀間預測、轉換、量化、去區塊濾波器、熵編碼等模塊。

H.265 編碼架構整體被分為編碼單位、預測單位和轉換單位。

H.265 在 H.264 的基礎之上，使用先進的技術用以改善碼流、編碼質量、延時和算法複雜度之間的關係，達到最優化設置。

在碼率減少 51-74% 的情況下，H.265 編碼視頻的質量還能與 H.264 編碼視頻近似甚至更好。

H.265 可以在有限帶寬下傳輸更高質量的網絡視頻，智慧型手機、平板機等行動裝置將能直接在線播放 1080p 的全高清視頻，讓網絡視頻跟上了顯示屏 「高解析度化」 的腳步。

來張圖感受一下吧：

除 MPEG-x 和 H.26x 系列標準外，還有其他的編碼標準，如谷歌的 VP 系列，對視頻編碼標準歸納一下，如圖：

11、什麼是視頻封裝格式？

視頻封裝格式如 mp4、mkv，用來存儲或傳輸編碼數據，可以理解成一個容器。

封裝就是按照一定規則把音視頻、字幕等數據組織起來，包含編碼類型等公共信息，播放器可以按照這些信息來匹配解碼器、同步音視頻。

不同的封裝格式支持的視音頻編碼格式是不一樣的，比如 MKV 格式支持比較多，RMVB 則主要支持 Real 公司的視音頻編碼格式。

WiKi百科上列出了常見的視頻封裝格式，可以查看各封裝格式支持的音視頻編碼格式等信息。

12、什麼是視頻解碼？

定義：將視頻壓縮編碼過的數據，解壓縮成為視頻原始數據，即視頻編碼的反過程。

對於一個播放器來說，很重要的一個指標就是能支持多少種視頻解碼。

13、視頻播放原理是什麼？

播放一個本地視頻文件，需要經過解封裝、解碼音視頻、音視頻同步等步驟。

解封裝：就是將輸入的封裝格式的數據，分離成為音頻壓縮編碼數據和視頻壓縮編碼數據。例如，FLV 格式的數據，經過解封裝操作後，輸出 H.264 編碼的視頻碼流和 AAC 編碼的音頻碼流。

解碼：將視頻/音頻壓縮編碼數據，解碼成為非壓縮的視頻/音頻原始數據。

音頻的壓縮編碼標準包含 AAC，MP3，AC-3 等等，視頻的壓縮編碼標準則包含 H.264，MPEG2，VC-1 等等。

解碼是整個系統中最重要也是最複雜的一個環節。

通過解碼，壓縮編碼的視頻數據輸出成為非壓縮的顏色數據，例如 YUV420P，RGB 等等；壓縮編碼的音頻數據輸出成為非壓縮的音頻抽樣數據，例如 PCM 數據。

音視頻同步：根據解封裝模塊處理過程中獲取到的參數信息，同步解碼出來的視頻和音頻數據，並將視頻音頻數據送至系統的顯卡和音效卡播放出來。

14、實時音視頻中音視頻與網絡的關係是什麼？

以下是一個典型的實時音視頻數據的詳細流轉原理圖：

▲ 圖片引用自《微信小程序音視頻技術背後的故事》

如上圖所示，相較於普通的音視頻本地播放，實時音視頻技術多了一個網絡傳輸的步驟，換句話說：實時音視頻技術 = 音視頻技術 + 網絡技術。

因為篇幅受限，本篇就不對具體的技術細節展開討論，感興趣的讀者，可以繼續深入閱讀即時通訊網收錄的《實時音視頻開發技術專輯》。

15、深入學習

如果你是初學者，還想以通俗易懂的方式了解實時音視頻技術，可以繼續閱讀以下文章：

《即時通訊音視頻開發（十九）：零基礎，史上最通俗視頻編碼技術入門》（* 強烈推薦）

《零基礎入門：實時音視頻技術基礎知識全面盤點》

如果你想系統專業的學習實時音視頻技術，那麼務必閱讀以下文章：

《即時通訊音視頻開發（一）：視頻編解碼之理論概述》

《即時通訊音視頻開發（二）：視頻編解碼之數字視頻介紹》

《即時通訊音視頻開發（三）：視頻編解碼之編碼基礎》

《即時通訊音視頻開發（四）：視頻編解碼之預測技術介紹》

《即時通訊音視頻開發（五）：認識主流視頻編碼技術H.264》

《即時通訊音視頻開發（六）：如何開始音頻編解碼技術的學習》

《即時通訊音視頻開發（七）：音頻基礎及編碼原理入門》

《即時通訊音視頻開發（八）：常見的實時語音通訊編碼標準》

《即時通訊音視頻開發（九）：實時語音通訊的回音及回音消除概述》

《即時通訊音視頻開發（十）：實時語音通訊的回音消除技術詳解》

《即時通訊音視頻開發（十一）：實時語音通訊丟包補償技術詳解》

《即時通訊音視頻開發（十二）：多人實時音視頻聊天架構探討》

《即時通訊音視頻開發（十三）：實時視頻編碼H.264的特點與優勢》

《即時通訊音視頻開發（十四）：實時音視頻數據傳輸協議介紹》

《即時通訊音視頻開發（十五）：聊聊P2P與實時音視頻的應用情況》

《即時通訊音視頻開發（十六）：移動端實時音視頻開發的幾個建議》

《即時通訊音視頻開發（十七）：視頻編碼H.264、VP8的前世今生》

《即時通訊音視頻開發（十八）：詳解音頻編解碼的原理、演進和應用選型》

《實時語音聊天中的音頻處理與編碼壓縮技術簡述》

《網易視頻雲技術分享：音頻處理與壓縮技術快速入門》

《學習RFC3550：RTP/RTCP實時傳輸協議基礎知識》

《基於RTMP數據傳輸協議的實時流媒體技術研究（論文全文）》

《聲網架構師談實時音視頻雲的實現難點(視頻採訪)》

《淺談開發實時視頻直播平臺的技術要點》

《還在靠「喂喂喂」測試實時語音通話質量？本文教你科學的評測方法！》

《實現延遲低於500毫秒的1080P實時音視頻直播的實踐分享》

《移動端實時視頻直播技術實踐：如何做到實時秒開、流暢不卡》

《如何用最簡單的方法測試你的實時音視頻方案》

《技術揭秘：支持百萬級粉絲互動的Facebook實時視頻直播》

《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》

《移動端實時音視頻直播技術詳解（一）：開篇》

《移動端實時音視頻直播技術詳解（二）：採集》

《移動端實時音視頻直播技術詳解（三）：處理》

《移動端實時音視頻直播技術詳解（四）：編碼和封裝》

《移動端實時音視頻直播技術詳解（五）：推流和傳輸》

《移動端實時音視頻直播技術詳解（六）：延遲優化》

《理論聯繫實際：實現一個簡單地基於HTML5的實時視頻直播》

《IM實時音視頻聊天時的回聲消除技術詳解》

《淺談實時音視頻直播中直接影響用戶體驗的幾項關鍵技術指標》

《如何優化傳輸機制來實現實時音視頻的超低延遲？》

《首次披露：快手是如何做到百萬觀眾同場看直播仍能秒開且不卡頓的？》

《Android直播入門實踐：動手搭建一套簡單的直播系統》

《網易雲信實時視頻直播在TCP數據傳輸層的一些優化思路》

《實時音視頻聊天技術分享：面向不可靠網絡的抗丟包編解碼器》

《P2P技術如何將實時視頻直播帶寬降低75%？》

《專訪微信視頻技術負責人：微信實時視頻聊天技術的演進》

《騰訊音視頻實驗室：使用AI黑科技實現超低碼率的高清實時視頻聊天》

《微信團隊分享：微信每日億次實時音視頻聊天背後的技術解密》

《近期大熱的實時直播答題系統的實現思路與技術難點分享》

《福利貼：最全實時音視頻開發要用到的開源工程匯總》

《七牛雲技術分享：使用QUIC協議實現實時視頻直播0卡頓！》

《實時音視頻聊天中超低延遲架構的思考與技術實踐》

《理解實時音視頻聊天中的延時問題一篇就夠》

《實時視頻直播客戶端技術盤點：Native、HTML5、WebRTC、微信小程序》

《寫給小白的實時音視頻技術入門提綱》

《微信多媒體團隊訪談：音視頻開發的學習、微信的音視頻技術和挑戰等》

《騰訊技術分享：微信小程序音視頻技術背後的故事》

《微信多媒體團隊梁俊斌訪談：聊一聊我所了解的音視頻技術》

《新浪微博技術分享：微博短視頻服務的優化實踐之路》

《實時音頻的混音在視頻直播應用中的技術原理和實踐總結》

《以網遊服務端的網絡接入層設計為例，理解實時通信的技術挑戰》

《騰訊技術分享：微信小程序音視頻與WebRTC互通的技術思路和實踐》

《新浪微博技術分享：微博實時直播答題的百萬高並發架構實踐》

《技術乾貨：實時視頻直播首屏耗時400ms內的優化實踐》

《愛奇藝技術分享：輕鬆詼諧，講解視頻編解碼技術的過去、現在和將來》

本文已同步發布於「即時通訊技術圈」公眾號。

同步發布連結：http://www.52im.net/thread-3194-1-1.html