視頻直播方案

首先是主播方,它是產生視頻流的源頭,通過一定的設備來采集數據。比如我們的是通過車載終端來獲取視頻流數據的。

其次是播放端,播放端功能有兩個層面,第一個層面是關鍵性的需求;另一層面是業務層面的。先看第一個層面,它涉及到一些非常關鍵的指標,比如秒開,在很多場景當中都有這樣的要求,然后是對于一些重要內容的版權保護。為了達到更好的效果,我們還需要配合服務端做智能解析,這在某些場景下也是關鍵性需求。再來看第二個層面也即業務層面的功能,對于一個社交直播產品來說,在播放端,觀眾希望能夠實時的看到主播端推過來的視頻流,并且和主播以及其他觀眾產生一定的互動,因此它可能包含一些像點贊、聊天和彈幕這樣的功能,以及禮物這樣更高級的道具。

直播服務器端提供的最核心功能是收集主播端的視頻推流,并將其放大后推送給所有觀眾端。除了這個核心功能,還有很多運營級別的訴求,比如鑒權認證,視頻連線和實時轉碼,自動鑒黃,多屏合一,以及云端錄制存儲等功能。另外,對于一個主播端推出的視頻流,中間需要經過一些環節才能到達播放端,因此對中間環節的質量進行監控,以及根據這些監控來進行智能調度,也是非常重要的訴求。實際上無論是主播端還是播放端,他們的訴求都不會僅僅是拍攝視頻和播放視頻這么簡單。在這個核心訴求被滿足之后,還有很多關鍵訴求需要被滿足。比如,對于一個消費級的直播產品來說,除了這三大模塊之外,還需要實現一個業務服務端來進行推流和播放控制,以及所有用戶狀態的維持。如此,就構成了一個消費級可用的直播產品。

視頻直播方案(包括APP在內)

錄制->編碼->網絡傳輸->解碼->播放

以上為直播的整體流程,根據該流程分為以下技術點:

怎樣錄制直播視頻(流媒體源/編碼/封裝)怎樣實時上傳直播視頻(視頻推流:

如何推/往哪里推/推流服務器)怎樣播放直播視頻(如何看: HLS/rtmp/flv)直播間的用戶是如何交互

如何搭建一個完整的視頻直播系統?一個完整的直播系統大致包含這幾個環節:采集、前處理、編碼、傳輸、解碼和渲染。在兩端傳輸的過程中再加上一個服務端處理。大致的模型如下:

推流,指的是把采集階段封包好的內容傳輸到服務器的過程。

流程如下:

經過輸出設備(AVCaptureVideoDataOutput)得到原始的采樣數據--視頻數據(YUV)和音頻數據(AAC);

使用硬編碼(對應系統的API)或軟編碼(FFMpeg)來編碼壓縮音視頻數據;分別得到已編碼的H.264視頻數據和AAC音頻數據;

根據不同的封裝格式(如FLV、TS、MPEG-TS);

使用HLS協議的時候加上這一步(HLS分段生成策略及m3u8索引文件)通過流上傳到服務器;

服務器進行相關協議的分發目前主流的推送協議,以及各自的優缺點如下:

RTMP

RTMP是Real Time Messaging Protocol(實時消息傳輸協議)的縮寫,是Adobe公司為Flash/AIR平臺和服務器之間音、視頻及數據傳輸開發的實時消息傳送協議。

RTMP協議基于TCP,包括RTMP基本協議及RTMPT/RTMPS/RTMPE等多種變種。RTMP協議中,視頻必須是H264編碼,音頻必須是AAC或MP3編碼,且多以flv格式封包。RTMP是目前最主流的流媒體傳輸協議,對CDN支持良好,實現難度較低,是大多數的直播平臺的選擇。

不過RTMP有著一個最大的不足——不支持瀏覽器,且Adobe已不再更新。因此直播服務要支持瀏覽器的話,需要另外的推送協議支持。

HLS

Http Live Streaming是由Apple公司定義的基于HTTP的流媒體實時傳輸協議。它的原理是將整個流分為多個小的文件來下載,每次只下載若干個。服務器端會將最新的直播數據生成新的小文件,客戶端只要不停的按順序播放從服務器獲取到的文件,就實現了直播?；旧?HLS是以點播的技術實現了直播的體驗。因為每個小文件的時長很短,客戶端可以很快地切換碼率,以適應不同帶寬條件下的播放。

分段推送的技術特點,決定了HLS的延遲一般會高于普通的流媒體直播協議。

傳輸內容包括兩部分:一是M3U8描述文件,二是TS媒體文件。TS媒體文件中的視頻必須是H264編碼,音頻必須是AAC或MP3編碼。

由于數據通過HTTP協議傳輸,所以完全不用考慮防火墻或者代理的問題,而且分段文件的時長很短,不過HLS的

WebRTC

WebRTC(Web Real-Time Communication),即“源自網頁即時通信”。

WebRTC是一個支持瀏覽器進行實時語音、視頻對話的開源協議。

WebRTC的支持者甚多,Google、Mozilla、Opera推動其成為W3C推薦標準。

WebRTC支持目前的主流瀏覽器,并且基于SRTP和UDP,即便在網絡信號一般的情況下也具備較好的穩定性。

此外,WebRTC可以實現點對點通信,通信雙方延時低,是實現“連麥”功能比較好的選擇。

拉流,指服務器已有直播內容,用指定地址進行拉取的過程。根據協議類型(如RTMP、RTP、RTSP、HTTP等),與服務器建立連接并接收數據;流程如下:

解析二進制數據,從中找到相關流信息;根據不同的封裝格式(如FLV、TS)解復用(demux);

分別得到已編碼的H.264視頻數據和AAC音頻數據;

使用硬解碼(對應系統的API)或軟解碼(FFMpeg)來解壓音視頻數據;經過解碼后得到原始的視頻數據(YUV)和音頻數據(AAC);

因為音頻和視頻解碼是分開的,所以我們得把它們同步起來,否則會出現音視頻不同步的現象,比如別人說話會跟口型對不上;

最后把同步的音頻數據送到耳機或外放,視頻數據送到屏幕上顯示。

直播架構(包括APP)

1. 采集端流程

(1)音視頻采集

(2)視頻處理

(3)音視頻編碼壓縮

(4)把音視頻封裝成FLV.TS

采集端;(常用框架)

AVFoundation框架 數據

FFmpeg 框架 音頻壓縮

X264 框架 視頻壓縮

Libremp 框架 推流

1. 服務器流程

(1)數據分發 (SDN)

(2)展示畫面

(3)錄制視頻

(4)實時轉碼

常用服務器;

SNS、BMS、nginx

1. 播放端流程

(1)從FLV.TS中獲取音視頻數據

(2)音視頻編碼

(3)播放

RTSP;實時流傳輸協議,是TCP/IP協議體系中的一個應用層協議.RTSP在體系結構上位于RTP和RTCP之上,它使用TCP或UDP完成數據傳輸。

RTMP;實時消息傳輸協議)的首字母縮寫。該協議基于TCP,是一個協議族,包括RTMP基本協議及RTMPT/RTMPS/RTMPE等多種變種。

FLV中的TS;首先引入dts(decode time-stamp)的概念,解碼時間戳,標識數據送入解碼器的時間,就是開始解碼的時間,應該按時隨著解碼順序而遞增的。 flv格式在碼流里有time-stamp位。由Timestamp和TimestampExtended組合得出TS(time-stamp),單位是毫秒。

可見TS是遞增的,又知道此碼流有B幀,所以播放順序一定是和解碼順序不同的。所以flv中的TS應該是DTS。

HLS;Http Live Streaming是由Apple公司定義的基于HTTP的流媒體實時傳輸協議。它的原理是將整個流分為多個小的文件來下載,每次只下載若干個。服務器端會將最新的直播數據生成新的小文件,客戶端只要不停的按順序播放從服務器獲取到的文件,就實現了直播?；旧?HLS是以點播的技術實現了直播的體驗。因為每個小文件的時長很短,客戶端可以很快地切換碼率,以適應不同帶寬條件下的播放。

簡單講就是把整個流分成一個個小的,基于HTTP的文件來下載,每次只下載一些,前面提到了用于H5播放直播視頻時引入的一個.m3u8(extended M3U playlist)的文件,這個文件就是基于HLS協議,存放視頻流元數據的文件。

分段推送的技術特點,決定了HLS的延遲一般會高于普通的流媒體直播協議。

傳輸內容包括兩部分:一是M3U8描述文件,二是TS媒體文件。TS媒體文件中的視頻必須是H264編碼,音頻必須是AAC或MP3編碼。

由于數據通過HTTP協議傳輸,所以完全不用考慮防火墻或者代理的問題,而且分段文件的時長很短,不過HLS的WebRTCWebRTC(Web Real-Time Communication),即“源自網頁即時通信”。

WebRTC是一個支持瀏覽器進行實時語音、視頻對話的開源協議。WebRTC的支持者甚多,Google、Mozilla、Opera推動其成為W3C推薦標準。WebRTC支持目前的主流瀏覽器,并且基于SRTP和UDP,即便在網絡信號一般的情況下也具備較好的穩定性。