視頻直播技術大全、直播架構、技術原理和實現思路方案整理

來源：互聯網轉載時間：2024-01-29 07:46:02

直播難:個人認為要想把直播從零開始做出來,絕對是牛逼中的牛逼,大牛中的大牛,因為直播中運用到的技術難點非常之多,視頻/音頻處理,圖形處理,視頻/音頻壓縮,CDN分發,即時通訊等技術,每一個技術都夠你學幾年的。

直播易:已經有各個領域的大牛,封裝好了許多牛逼的框架,我們只需要用別人寫好的框架,就能快速的搭建一個直播app,也就是傳說中的站在大牛肩膀上編程。

通用直播模型

首先是主播方,它是產生視頻流的源頭,由一系列流程組成:第一,通過一定的設備來采集數據;第二,將采集的這些視頻進行一系列的處理,比如水印、美顏和特效濾鏡等處理;第三,將處理后的結果視頻編碼壓縮成可觀看可傳輸的視頻流;第四,分發推流,即將壓縮后的視頻流通過網絡通道傳輸出去。

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

我們知道,內容產生方和消費方一般都不是一一對應的。對于一個直播產品來講,最直觀的體現就是一個主播可能會有很多粉絲。因此,我們不能直接讓主播端和所有播放端進行點對點通信,這在技術上是做不到或者很有難度。主播方播出的視頻到達播放端之前,需要經過一系列的中間環節,也就是我們這里講的直播服務器端。

直播服務器端提供的最核心功能是收集主播端的視頻推流,并將其放大后推送給所有觀眾端。除了這個核心功能,還有很多運營級別的訴求,比如鑒權認證,視頻連線和實時轉碼,自動鑒黃,多屏合一,以及云端錄制存儲等功能。另外,對于一個主播端推出的視頻流,中間需要經過一些環節才能到達播放端,因此對中間環節的質量進行監控,以及根據這些監控來進行智能調度,也是非常重要的訴求。

實際上無論是主播端還是播放端,他們的訴求都不會僅僅是拍攝視頻和播放視頻這么簡單。在這個核心訴求被滿足之后,還有很多關鍵訴求需要被滿足。比如,對于一個消費級的直播產品來說,除了這三大模塊之外,還需要實現一個業務服務端來進行推流和播放控制,以及所有用戶狀態的維持。如此,就構成了一個消費級可用的直播產品。

但是正如剛才所說的直播通用模型一樣,實際上這里很多功能都可以抽象成一個通用功能,也就是說各家直播產品的需求和實現方式都類似。

直播架構

直播App 架構和技術點

直播APP的業務邏輯不復雜,使用基本的MVC框架即可。

部分Controller的業務邏輯較多,獨立的業務可以拆分出去作為一個單獨的Catagory;
Model的數據變化采用event(notification)的形式通知,便于做多處數據綁定;
Model之間的相互獨立,如果由業務需要,需要交換Model的數據,由Controller代為處理;
HTTPService為AFNetworking封裝,回調Model以Block塊為主,特殊的業務邏輯以event(notification)的形式通知;

一個完整直播APP功能

聊天: 私聊、聊天室、點亮、推送、黑名單等;
禮物: 普通禮物、豪華禮物、紅包、排行榜、第三方充值、內購、禮物動態更新、提現等;
直播列表: 關注、熱門、最新、分類直播用戶列表等;
自己直播: 錄制、推流、解碼、播放、美顏、心跳、后臺切換、主播對管理員操作、管理員對用戶等;
房間邏輯: 創建房間、進入房間、退出房間、關閉房間、切換房間、房間管理員設置、房間用戶列表等;
用戶邏輯: 普通登陸、第三方登陸、注冊、搜索、修改個人信息、關注列表、粉絲列表、忘記密碼、查看個人信息、收入榜、關注和取關、檢索等;
觀看直播: 聊天信息、滾屏彈幕、禮物顯示、加載界面等;
統計: APP業務統計、第三方統計等;
超管: 禁播、隱藏、審核等;

一個完整直播app實現流程

1.采集、2.濾鏡處理、3.編碼、4.推流、5.CDN分發、6.拉流、7.解碼、8.播放、9.聊天互動

了解流媒體(直播需要用到流媒體)

流媒體開發:網絡層(socket或st)負責傳輸,協議層(rtmp或hls)負責網絡打包,封裝層(flv、ts)負責編解碼數據的封裝,編碼層(h.264和aac)負責圖像,音頻壓縮。
幀:每幀代表一幅靜止的圖像
GOP:(Group of Pictures)畫面組,一個GOP就是一組連續的畫面,每個畫面都是一幀,一個GOP就是很多幀的集合。
? 直播的數據,其實是一組圖片,包括I幀、P幀、B幀,當用戶第一次觀看的時候,會尋找I幀,而播放器會到服務器尋找到最近的I幀反饋給用戶。因此,GOP Cache增加了端到端延遲,因為它必須要拿到最近的I幀
? GOP Cache的長度越長,畫面質量越好
碼率:圖片進行壓縮后每秒顯示的數據量。
幀率:每秒顯示的圖片數。影響畫面流暢度,與畫面流暢度成正比:幀率越大,畫面越流暢;幀率越小,畫面越有跳動感。
? 由于人類眼睛的特殊生理結構,如果所看畫面之幀率高于16的時候,就會認為是連貫的,此現象稱之為視覺暫留。并且當幀速達到一定數值后,再增長的話,人眼也不容易察覺到有明顯的流暢度提升了。
分辨率:(矩形)圖片的長度和寬度,即圖片的尺寸
壓縮前的每秒數據量:幀率X分辨率(單位應該是若干個字節)
壓縮比:壓縮前的每秒數據量/碼率 (對于同一個視頻源并采用同一種視頻編碼算法,則:壓縮比越高,畫面質量越差。)
視頻文件格式:文件的后綴,比如.wmv,.mov,.mp4,.mp3,.avi,
? 主要用處,根據文件格式,系統會自動判斷用什么軟件打開,
注意: 隨意修改文件格式,對文件的本身不會造成太大的影響,比如把avi改成mp4,文件還是avi.
視頻封裝格式:一種儲存視頻信息的容器,流式封裝可以有TS、FLV等,索引式的封裝有MP4,MOV,AVI等,
? 主要作用:一個視頻文件往往會包含圖像和音頻,還有一些配置信息(如圖像和音頻的關聯,如何解碼它們等):這些內容需要按照一定的規則組織、封裝起來.
? 注意:會發現封裝格式跟文件格式一樣,因為一般視頻文件格式的后綴名即采用相應的視頻封裝格式的名稱,所以視頻文件格式就是視頻封裝格式。
視頻封裝格式和視頻壓縮編碼標準:就好像項目工程和編程語言,封裝格式就是一個項目的工程,視頻編碼方式就是編程語言,一個項目工程可以用不同語言開發。

直播基礎知識介紹

采集視頻、音頻

采集視頻、音頻編碼框架:AVFoundation:AVFoundation是用來播放和創建實時的視聽媒體數據的框架,同時提供Objective-C接口來操作這些視聽數據,比如編輯,旋轉,重編碼

視頻、音頻硬件設備

CCD:圖像傳感器: 用于圖像采集和處理的過程,把圖像轉換成電信號。
拾音器:聲音傳感器: 用于聲音采集和處理的過程,把聲音轉換成電信號。
音頻采樣數據:一般都是PCM格式
視頻采樣數據: 一般都是YUV,或RGB格式,采集到的原始音視頻的體積是非常大的,需要經過壓縮技術處理來提高傳輸效率

視頻處理(美顏,水印)

視頻處理原理:因為視頻最終也是通過GPU,一幀一幀渲染到屏幕上的,所以我們可以利用OpenGL ES,對視頻幀進行各種加工,從而視頻各種不同的效果,就好像一個水龍頭流出的水,經過若干節管道,然后流向不同的目標
現在的各種美顏和視頻添加特效的app都是利用GPUImage這個框架實現的.

視頻處理框架

GPUImage : GPUImage是一個基于OpenGL ES的一個強大的圖像/視頻處理框架,封裝好了各種濾鏡同時也可以編寫自定義的濾鏡,其本身內置了多達120多種常見的濾鏡效果。
OpenGL:OpenGL(全寫Open Graphics Library)是個定義了一個跨編程語言、跨平臺的編程接口的規格,它用于三維圖象(二維的亦可)。OpenGL是個專業的圖形程序接口,是一個功能強大,調用方便的底層圖形庫。
OpenGL ES:OpenGL ES (OpenGL for Embedded Systems) 是 OpenGL三維圖形 API 的子集,針對手機、PDA和游戲主機等嵌入式設備而設計。

視頻編碼解碼框架

FFmpeg:是一個跨平臺的開源視頻框架,能實現如視頻編碼,解碼,轉碼,串流,播放等豐富的功能。其支持的視頻格式以及播放協議非常豐富,幾乎包含了所有音視頻編解碼、封裝格式以及播放協議。
? -Libswresample:可以對音頻進行重采樣,rematrixing 以及轉換采樣格式等操作。
? -Libavcodec:提供了一個通用的編解碼框架,包含了許多視頻,音頻,字幕流等編碼/解碼器。
? -Libavformat:用于對視頻進行封裝/解封裝。
? -Libavutil:包含一些共用的函數,如隨機數生成,數據結構,數學運算等。
? -Libpostproc:用于進行視頻的一些后期處理。
? -Libswscale:用于視頻圖像縮放,顏色空間轉換等。
? -Libavfilter:提供濾鏡功能。
X264:把視頻原數據YUV編碼壓縮成H.264格式
VideoToolbox:蘋果自帶的視頻硬解碼和硬編碼API,但是在iOS8之后才開放。
AudioToolbox:蘋果自帶的音頻硬解碼和硬編碼API

視頻編碼技術

視頻壓縮編碼標準:對視頻進行壓縮(視頻編碼)或者解壓縮(視頻解碼)的編碼技術,比如MPEG,H.264,這些視頻編碼技術是壓縮編碼視頻的
? 主要作用:是將視頻像素數據壓縮成為視頻碼流,從而降低視頻的數據量。如果視頻不經過壓縮編碼的話,體積通常是非常大的,一部電影可能就要上百G的空間。
? 注意:最影響視頻質量的是其視頻編碼數據和音頻編碼數據,跟封裝格式沒有多大關系
MPEG:一種視頻壓縮方式,它采用了幀間壓縮,僅存儲連續幀之間有差別的地方 ,從而達到較大的壓縮比
H.264/AVC:一種視頻壓縮方式,采用事先預測和與MPEG中的P-B幀一樣的幀預測方法壓縮,它可以根據需要產生適合網絡情況傳輸的視頻流,還有更高的壓縮比,有更好的圖象質量
? 注意1:如果是從單個畫面清晰度比較,MPEG4有優勢;從動作連貫性上的清晰度,H.264有優勢
? 注意2:由于264的算法更加復雜,程序實現煩瑣,運行它需要更多的處理器和內存資源。因此,運行264對系統要求是比較高的。
? 注意3:由于264的實現更加靈活,它把一些實現留給了廠商自己去實現,雖然這樣給實現帶來了很多好處,但是不同產品之間互通成了很大的問題,造成了通過A公司的編碼器編出的數據,必須通過A公司的解碼器去解這樣尷尬的事情
H.265/HEVC:一種視頻壓縮方式,基于H.264,保留原來的某些技術,同時對一些相關的技術加以改進,以改善碼流、編碼質量、延時和算法復雜度之間的關系,達到最優化設置。
? H.265 是一種更為高效的編碼標準,能夠在同等畫質效果下將內容的體積壓縮得更小,傳輸時更快更省帶寬
? I幀:(關鍵幀)保留一副完整的畫面,解碼時只需要本幀數據就可以完成(因為包含完整畫面)
P幀:(差別幀)保留這一幀跟之前幀的差別,解碼時需要用之前緩存的畫面疊加上本幀定義的差別,生成最終畫面。(P幀沒有完整畫面數據,只有與前一幀的畫面差別的數據)
B幀:(雙向差別幀)保留的是本幀與前后幀的差別,解碼B幀,不僅要取得之前的緩存畫面,還要解碼之后的畫面,通過前后畫面的與本幀數據的疊加取得最終的畫面。B幀壓縮率高,但是解碼時CPU會比較累
幀內(Intraframe)壓縮:當壓縮一幀圖像時,僅考慮本幀的數據而不考慮相鄰幀之間的冗余信息,幀內一般采用有損壓縮算法
幀間(Interframe)壓縮:時間壓縮(Temporal compression),它通過比較時間軸上不同幀之間的數據進行壓縮。幀間壓縮一般是無損的
muxing(合成):將視頻流、音頻流甚至是字幕流封裝到一個文件中(容器格式(FLV,TS)),作為一個信號進行傳輸。

音頻編碼技術

AAC,mp3:這些屬于音頻編碼技術,壓縮音頻用

碼率控制

多碼率:觀眾所處的網絡情況是非常復雜的,有可能是WiFi,有可能4G、3G、甚至2G,那么怎么滿足多方需求呢?多搞幾條線路,根據當前網絡環境自定義碼率。
? 例如:常?？匆娨曨l播放軟件中的1024,720,高清,標清,流暢等,指的就是各種碼率。

視頻封裝格式

TS : 一種流媒體封裝格式,流媒體封裝有一個好處,就是不需要加載索引再播放,大大減少了首次載入的延遲,如果片子比較長,mp4文件的索引相當大,影響用戶體驗
? 為什么要用TS:這是因為兩個TS片段可以無縫拼接,播放器能連續播放
FLV: 一種流媒體封裝格式,由于它形成的文件極小、加載速度極快,使得網絡觀看視頻文件成為可能,因此FLV格式成為了當今主流視頻格式

推流

數據傳輸框架

librtmp:用來傳輸RTMP協議格式的數據

流媒體數據傳輸協議

RTMP(Real Time Messaging Protocol,實時消息傳輸協議)屬于五層TCP/IP體系中的應用層,它是基于TCP傳輸的流媒體協議,默認端口為1935,是一個協議族,包括RTMP基本協議及RTMPT、RTMPS、REMPE等多種變種。RTMP協議是Adobe System公司為Flash播放器和FMS服務器之間音視頻和數據傳輸開發的私有協議,用來解決多媒體數據傳輸流的多路復用(Multiplexing)和分包(packetizing)的問題,基于此協議,abobe提供完善的音視頻解決方案,比如點播、直播、互動。
? RTMP協議用于對象、視頻、音頻的傳輸。
? 這個協議建立在TCP協議或者輪詢HTTP協議之上。
? RTMP協議就像一個用來裝數據包的容器,這些數據可以是FLV中的視音頻數據。一個單一的連接可以通過不同的通道傳輸多路網絡流,這些通道中的包都是按照固定大小的包傳輸的
? chunk:消息包

流媒體服務器

常用服務器

SRS:一款國人開發的優秀開源流媒體服務器系統
BMS:也是一款流媒體服務器系統,但不開源,是SRS的商業版,比SRS功能更多
nginx:免費開源web服務器,常用來配置流媒體服務器。

流媒體SRS 4.0開發入門

數據分發

CDN:(Content Delivery Network),即內容分發網絡,將網站的內容發布到最接近用戶的網絡”邊緣”,使用戶可以就近取得所需的內容,解決 Internet網絡擁擠的狀況,提高用戶訪問網站的響應速度.
? CDN:代理服務器,相當于一個中介。
? CDN工作原理:比如請求流媒體數據
?? 1.上傳流媒體數據到服務器(源站)
?? 2.源站存儲流媒體數據
?? 3.客戶端播放流媒體,向CDN請求編碼后的流媒體數據
?? 4.CDN的服務器響應請求,若節點上沒有該流媒體數據存在,則向源站繼續請求流媒體數據;若節點上已經緩存了該視頻文件,則跳到第6步。
?? 5.源站響應CDN的請求,將流媒體分發到相應的CDN節點上
?? 6.CDN將流媒體數據發送到客戶端
回源:當有用戶訪問某一個URL的時候,如果被解析到的那個CDN節點沒有緩存響應的內容,或者是緩存已經到期,就會回源站去獲取搜索。如果沒有人訪問,那么CDN節點不會主動去源站拿.
帶寬:在固定的時間可傳輸的數據總量,
? 比如64位、800MHz的前端總線,它的數據傳輸率就等于64bit×800MHz÷8(Byte)=6.4GB/s
負載均衡: 由多臺服務器以對稱的方式組成一個服務器集合,每臺服務器都具有等價的地位,都可以單獨對外提供服務而無須其他服務器的輔助.
? 通過某種負載分擔技術,將外部發送來的請求均勻分配到對稱結構中的某一臺服務器上,而接收到請求的服務器獨立地回應客戶的請求。
? 均衡負載能夠平均分配客戶請求到服務器列陣,籍此提供快速獲取重要數據,解決大量并發訪問服務問題。
? 這種群集技術可以用最少的投資獲得接近于大型主機的性能。
QoS(帶寬管理):限制每一個組群的帶寬,讓有限的帶寬發揮最大的效用

拉流

直播協議選擇:
? 即時性要求較高或有互動需求的可以采用RTMP,RTSP
? 對于有回放或跨平臺需求的,推薦使用HLS

HLS:由Apple公司定義的用于實時流傳輸的協議,HLS基于HTTP協議實現,傳輸內容包括兩部分,一是M3U8描述文件,二是TS媒體文件?？蓪崿F流媒體的直播和點播,主要應用在iOS系統
? HLS是以點播的技術方式來實現直播
? HLS是自適應碼率流播,客戶端會根據網絡狀況自動選擇不同碼率的視頻流,條件允許的情況下使用高碼率,網絡繁忙的時候使用低碼率,并且自動在二者間隨意切換。這對移動設備網絡狀況不穩定的情況下保障流暢播放非常有幫助。
? 實現方法是服務器端提供多碼率視頻流,并且在列表文件中注明,播放器根據播放進度和下載速度自動調整。
HLS與RTMP對比:HLS主要是延時比較大,RTMP主要優勢在于延時低
? HLS協議的小切片方式會生成大量的文件,存儲或處理這些文件會造成大量資源浪費
? 相比使用RTSP協議的好處在于,一旦切分完成,之后的分發過程完全不需要額外使用任何專門軟件,普通的網絡服務器即可,大大降低了CDN邊緣服務器的配置要求,可以使用任何現成的CDN,而一般服務器很少支持RTSP。
HTTP-FLV:基于HTTP協議流式的傳輸媒體內容。
? 相對于RTMP,HTTP更簡單和廣為人知,內容延遲同樣可以做到1~3秒,打開速度更快,因為HTTP本身沒有復雜的狀態交互。所以從延遲角度來看,HTTP-FLV要優于RTMP
RTSP:實時流傳輸協議,定義了一對多應用程序如何有效地通過IP網絡傳送多媒體數據.
RTP:實時傳輸協議,RTP是建立在UDP協議上的,常與RTCP一起使用,其本身并沒有提供按時發送機制或其它服務質量(QoS)保證,它依賴于低層服務去實現這一過程。
RTCP:RTP的配套協議,主要功能是為RTP所提供的服務質量(QoS)提供反饋,收集相關媒體連接的統計信息,例如傳輸字節數,傳輸分組數,丟失分組數,單向和雙向網絡延遲等等。