前言

今天和大家講一下音視頻直播技術(shù)架構(gòu)。之前的關(guān)注點主要放在客戶端如何采集音頻數(shù)據(jù)上，經(jīng)過這兩天的思考，我覺得應(yīng)該先給大家講一下音視頻直播技術(shù)架構(gòu)，這樣更容易從整體上理解視頻直播技術(shù)是如何運轉(zhuǎn)的，之后再逐步的介紹每一個主題。

簡單的音視頻直播架構(gòu)

直播架構(gòu)

這種架構(gòu)非常的簡單，利用已經(jīng)有的CDN網(wǎng)絡(luò)如阿里，帝聯(lián)，藍訊等，自己再搭建一個信令服務(wù)器，這樣就將服務(wù)層搭建好了。

共享者首先向信令服務(wù)器發(fā)送共享音視頻指令，之后通過 Camera 或 攝像頭采集數(shù)據(jù)，數(shù)據(jù)經(jīng)編碼后通過RTMP協(xié)議將流推送給CDN網(wǎng)絡(luò)。

接收端向信令服務(wù)器發(fā)指令，獲取共享者共享的流名稱，然后通過流名稱從CDN網(wǎng)絡(luò)拉取音視頻流，再經(jīng)過解碼后渲染在屏幕上。

實時交互的音視頻直播架構(gòu)

直播架構(gòu)

這種架構(gòu)與上一種比要復(fù)雜不少，其中最主要的差別是增加了自有網(wǎng)絡(luò)。客戶端通過 UDP 進行數(shù)據(jù)傳輸，這樣可以大大減少由于網(wǎng)絡(luò)及CDN結(jié)構(gòu)導(dǎo)致的音視頻延遲問題。

共享者共享音視頻時，都是通過UDP協(xié)議上傳到自有網(wǎng)絡(luò)服務(wù)器上。如果有其它參與人要與共享者進行實時互動，那么參與者也是通過UDP連接到自有網(wǎng)絡(luò)，這樣才能達到實時互動的效果。

共享者的音視頻數(shù)據(jù)上傳到自有網(wǎng)絡(luò)后，還要通過專門的服務(wù)將數(shù)據(jù)流轉(zhuǎn)成RTMP流推到CDN網(wǎng)絡(luò)，這樣對于大多數(shù)不參與時實互動的用戶就可以從CDN獲取數(shù)音視頻數(shù)據(jù)了。

這種架構(gòu)既可以滿足實時互動的需求，也可以滿足大批用戶只觀看不互動的需求。

解決高負載大并發(fā)問題

直播架構(gòu)

為了解決實時互動大負載，高并發(fā)的問題，需要增加資源管理服務(wù)器，實時監(jiān)測各服務(wù)的資源。第次當用戶共享音視頻時，資源管理器都可以分配最佳的服務(wù)器給共享用戶使用，并且服務(wù)器資源可以根據(jù)需要橫向擴容。

注意 為了增加執(zhí)行效率，服務(wù)端基本都是用 C/C++ 程序編寫。

小結(jié)

實時互動直播是未來的直播趨勢，大看可以看一下我另一篇文章音視頻直播漫談中的介紹。有了這個架構(gòu)我們后面就可以逐步的給大家講解每個主題。如 Android、IOS、windows、mac下如何進行音視頻數(shù)據(jù)采集，如何進行編碼，是采用硬編還是使用軟編?它們各自有什么優(yōu)勢，如何使用 opengl 進行渲染，如何進行網(wǎng)絡(luò)優(yōu)化等等。

作者：音視頻直播技術(shù)專家
鏈接：https://www.jianshu.com/p/db3482971758
來源：簡書
簡書著作權(quán)歸作者所有，任何形式的轉(zhuǎn)載都請聯(lián)系作者獲得授權(quán)并注明出處。

總結(jié)

以上是生活随笔為你收集整理的音视频直播--技术架构的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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