功能需求

?直播事件與流之間的最大延遲不超過1分鐘?系統(tǒng)應能夠適應大量用戶（異構(gòu)交付）?系統(tǒng)應能將視頻轉(zhuǎn)換為不同的分辨率和編解碼器?系統(tǒng)應具備容錯性

視頻轉(zhuǎn)換和接收

由于我們正在實時直播整個事件，因此我們不能等待整個視頻結(jié)束后再開始將其轉(zhuǎn)換為不同的格式和編解碼器。為了實現(xiàn)這一點，我們可以使用一種名為RTMP（Real-Time Messaging Protocol）的協(xié)議。

?RTMP代表實時消息傳輸協(xié)議（Real-Time Messaging Protocol）?我們使用RTMP是因為它是基于TCP的，因此不會丟失數(shù)據(jù)，更加可靠。我們需要使用TCP，因為我們不希望在傳輸過程中丟失數(shù)據(jù)包。如果我們使用UDP之類的協(xié)議，雖然傳輸速度會更快，但在每個階段丟失數(shù)據(jù)將導致視頻質(zhì)量下降。

所需組件

?轉(zhuǎn)換服務：RTMP提供視頻流，轉(zhuǎn)換服務將該視頻流轉(zhuǎn)換為不同的編解碼器和分辨率。它還具有作業(yè)調(diào)度器，以原始視頻流為輸入，將其轉(zhuǎn)換為所有的分辨率和編解碼器。多個工作節(jié)點執(zhí)行這些任務。當有新的原始視頻流時，轉(zhuǎn)換服務將其推送到消息隊列。工作節(jié)點訂閱此消息隊列。它們接受輸入，并在視頻轉(zhuǎn)換完成后將其推送到另一個消息隊列。?數(shù)據(jù)庫：為了在發(fā)生災難時不丟失視頻數(shù)據(jù)（我們需要容錯性），我們將使用數(shù)據(jù)庫存儲原始視頻數(shù)據(jù)。?分布式文件服務：在工作節(jié)點處理視頻后，還需要將結(jié)果存儲在文件服務中以實現(xiàn)容錯性。?消息隊列

架構(gòu)圖

向終端用戶傳輸視頻

我們將使用內(nèi)容交付網(wǎng)絡(luò)（CDN）將視頻傳輸給終端用戶。CDN或邊緣服務器在地理上更接近終端用戶。

由于用戶將通過HTTP連接，因此我們可以使用諸如HLS（HTTP Live Streaming）（用于iPhone）或DASH（Dynamic Adaptive Streaming over HTTP）（用于其他操作系統(tǒng)）的協(xié)議。

但是，為什么我們要使用HLS/DASH？

HLS/DASH具有自適應比特率。這意味著我們將根據(jù)以下因素調(diào)整比特率：

?可提供的視頻質(zhì)量?網(wǎng)絡(luò)速度?客戶設(shè)備支持的分辨率和格式

由于它是一種流媒體協(xié)

議，它可以根據(jù)帶寬的使用情況和實時需求來合理地進行調(diào)整。

注意：與RTMP相比，HLS/DASH是較低質(zhì)量的連接，因此我們在實時性和質(zhì)量之間進行了權(quán)衡。

為了將視頻發(fā)送到CDN，我們可以在全球范圍內(nèi)部署服務器。我們將處理后的視頻發(fā)送到這些服務器，然后服務器將其發(fā)送到CDN。

我們將使用RTMP將視頻發(fā)送到服務器。

但是，為什么我們不直接將處理后的視頻發(fā)送到CDN？

跨內(nèi)容交付網(wǎng)絡(luò)的傳播速度可能不太高。因此，如果我們將處理后的視頻發(fā)送到CDN，而它們在不同位置擁有服務器，則SLA保證可能無法與實時直播保證相匹配。

每當客戶端請求視頻時，其中一個服務器將客戶端引導到CDN上的一個端點。客戶端可以使用此端點來獲取視頻。

緩存

我們將讓CDN負責緩存視頻。盡管您可以將熱門視頻片段緩存在內(nèi)存中，但為了減輕服務器負載，我們可以緩存客戶端 <-> 終點的映射。這樣，我們可以直接獲取終點，而無需每次重新路由。

容錯性

為了使我們的系統(tǒng)更具容錯性，我們可以使用負載均衡器。如果其中一個服務器離線，我們可以將請求重定向到其他服務器。

折衷方案

?使用WebRTC與使用HLS/DASH進行視頻傳輸。HLS/DASH是基于HTTP并通過TCP工作的。它們保持有序傳輸。另一方面，WebRTC基于點對點，并通過UDP工作。它可能還會發(fā)送無序的數(shù)據(jù)塊。由于我們希望保持視頻質(zhì)量，因此我們將使用HLS/DASH。

所需組件

?內(nèi)容交付網(wǎng)絡(luò)（CDN）?在不同位置的服務器

架構(gòu)圖

容量估算

每個直播流需要處理多少個視頻？

假設(shè)：

?捕捉的視頻為8k。?我們要提供的分辨率：1080p、720p、480p和360p。?編解碼器數(shù)量：4?板球比賽持續(xù)時間：10小時?視頻大?。?0GB

720p視頻大?。?0/2 = 5GB

480p視頻大小：10/4 = 2.5GB

360p視頻大?。?0/8 = 1.25GB

所有分辨率所需的總存儲空間：18.75GB

所有分辨率和編解碼器所

需的總存儲空間：18.75 * 4 = 75GB

在單個直播流中需要向CDN傳輸多少數(shù)據(jù)？

假設(shè)：

?用戶數(shù)量：10,000,000?使用高清分辨率的用戶比例：50%?觀看直播流的用戶比例：50%

標準分辨率下的視頻大?。?0/4 = 2.5GB

因此，總數(shù)據(jù)傳輸量 = SUM(視頻類型的大小 * 類型的用戶數(shù)量) * 平均觀看百分比

= (10 GB * 50/100 * 10? + 2.5 GB * 50/100 * 10?) * 50/100 = 3.125 * 1000000GB = 3.125 PB

從事件到用戶設(shè)備傳輸數(shù)據(jù)需要多長時間？

假設(shè)：

?用戶每秒消耗的數(shù)據(jù)量 = 10GB / 10小時 =?300?kB/sec?將300kB數(shù)據(jù)傳輸?shù)阶罱腃DN所需時間 =?1秒?從CDN向用戶傳輸300kB數(shù)據(jù)所需時間 =?150毫秒

總傳輸時間 = 1秒 + 0.15秒 + 0.15秒 =?1.3秒

假設(shè)ffmpeg運行速度為視頻速度的2倍，處理時間為1 / 2 =?0.5秒

總延遲時間 = 1.3秒 + 0.5秒 =?1.8秒

通過以上內(nèi)容，我們設(shè)計了一個類似ESPN的實時視頻流系統(tǒng)，該系統(tǒng)具備容錯性、支持不同分辨率和編解碼器的視頻轉(zhuǎn)換，以及使用CDN進行視頻傳輸。我們還進行了容量估算，估計了處理視頻、傳輸數(shù)據(jù)和傳輸延遲所需的時間。文章來源地址http://www.zghlxwxcb.cn/news/detail-469756.html