obs推流直播的好處:視頻號推流軟件

原理

基本步驟為:採集–壓縮編碼–封裝–推流–分發–流媒體協議觀看

音視頻採集封裝到直播推流原理

採集

我們知道計算機都是只認識二進制的,所以對於視頻採集,其實就是把實際看到的東西轉為二進制的格式,採集就是轉為二進制流的過程。

這部分其實實際測試中關注的是比較少的,因為客戶端針對的都是採集好的原始視頻或音頻流做處理,這裡要知道採集成的格式視頻是YUV,音頻是PCM。

YUV來說,其中“Y”表示明亮度(Luminance或Luma),也就是灰階值;而“U”和“V” 表示的則是色度(Chrominance或Chroma),作用是描述影像色彩及飽和度,用於指定像素的顏色。

處理

處理的過程主要是美顏和濾鏡了,重點說說美顏,美顏有兩步,一個是磨皮,一個是美白,要想正確美顏,所以還需要加上人臉識別技術和皮膚識別技術。

這裡要說說題外話,美顏在壓縮編碼前處理可以說是最自然的,缺點也有,不能修改。所以也有一種是通過播放器渲染”美顏”。效果嘛,呵呵。可惜的是我們項目美顏濾鏡就是這樣做的,個人還是不敢苟同的,這樣做缺點非常明顯,畫質不忍直視,還要十分拖累幀數,優點嘛,修改和實現非常簡單,成本也低

在針對原始流的處理,除了濾鏡美顏外,還可以自定義打logo,修改畫面內容。

壓縮編碼

首先,要知道的是,一個視頻是由一個個畫面組成的,多個畫面連續運動便構成了動畫,也就是視頻,一個個畫面我們稱為幀(筆者想起小時候玩的小玩具,一個小本本,裡面有很多相似的圖畫,然後像翻書那樣快速翻過,形成了動畫)。

原始視頻流是很大的,需要壓縮,那麼最簡單的辦法就是”推測”,根據前一幀推測後一幀後者幾幀,那麼就不用存儲這麼多數據了。

所以壓縮編碼就是把採集到的數據分成有關聯的一幀幀,那麼N個幀合在一起就是一個組,我們叫GOP(group of picture)。這個組裡面的幀,我們劃分成I/B/P幀,我們把I幀叫做關鍵幀,B/P幀叫做參考幀,其中B叫雙向參考幀,P叫向前參考幀,沒有I幀B/P幀也沒法播放,因為B/P幀是參考I幀的變化而成的。

壓縮編碼到底怎麼壓縮的?

壓縮編碼的作用是去掉冗餘信息,主要有以下幾個方向,當然冗餘不止這幾個哈:

空間冗餘

時間冗餘

視覺冗餘

編碼冗餘

空間冗餘:

比如下面這幅筆者正在用的壁紙,可以發現有的顏色區域非常類似甚至一樣,這樣這些重複的區域就是空間冗餘了,空間冗餘是屬於幀內壓縮的,是指在一個圖像內的壓縮。

時間冗餘:

根據時間關係產生的冗餘,根據前一幀和變化量可以推測出後一幀的冗餘,比如下面的圖(網上搜的一幅圖),動作是比較規律的,不同的只是變化(可以想成開發中動畫的定義,先定義一個圖像,然後調用api讓它旋轉、放大、移動和透明),那麼這就是時間冗餘。

視覺冗餘:

這個百度百科挺詳細的,我摘取一段下來:

在多媒體技術的應用領域中,人的眼睛是圖像信息的接收端。視覺冗餘是相對於人眼的視覺特性而言的,人類的視覺系統並不能對圖像畫面的任何變化都能感覺到,通常情況下具有以下特點:

對亮度的變化敏感,對色度的變化相對不敏感。

對靜止圖像敏感,對運動圖像相對不敏感。

對圖像的水平線條和豎直線條敏感,對斜線相對不敏感。

對整體結構敏感,對內部細節相對不敏感。

對低頻信號敏感,對高頻信號相對不敏感(如:對邊沿或者突變附近的細節不敏感)。

……

因此,包含在色度信號、運動圖像、圖像高頻信號中的一些數據,相對於人眼而言,並不能對增加圖像的清晰度作出貢獻,被人眼視為多餘的,這就是視覺冗餘。

也就是說視覺冗餘就是排除掉人類視覺不敏感的地方,達到壓縮的目的。

但是,你不排除有的人就是對這些細節很在意啊,比如每次測試不出來的東西,一發到外網,總有人反饋,一看,顏色不對啦,多了一根線啦,真是折磨人呢!

編碼冗餘:

因為不同編碼方式或者不同的圖片壓縮後產生的二進制長度是不一致的,指在編碼過程中每個像素使用的比特位大於實際的信息熵(其實就是計劃和實際不匹配產生的餘量咯),那麼就產生了冗餘,這和圖像和編碼方式有區別的,編碼冗餘也叫信息熵冗餘。

關係?

還是有關係的,GOP分組,I幀是關鍵幀,是空間冗餘,B/P幀是參考幀,是時間冗餘,然後繼續編碼,去除視覺冗餘和編碼冗餘等,最後這一過程就完成了。

常用編碼格式

這裡需要對比一下常用的編碼標準了,深入的原理不會涉及(不是算法層了,接觸太多反而沒必要),但是你要知道優缺點呢!

音視頻採集封裝到直播推流原理

那麼綜上,目前項目的編碼格式定位最主流的h.264 + aac的編碼方案,主要是為了:

移動端要考慮兼容性,硬解一般都支持h.264

要考慮性能,h.265資源消耗比較大,而且為了體驗良好需要快速編碼並保存資源

封裝

然後到封裝了,封裝其實就是打包啊,壓縮編碼後h.264和aac,要怎麼結合在一起呢,就是封裝呀,舉個例子,一個醬油瓶,裡面裝的醬油,醬油就是壓縮編碼後的成品,裝到瓶子里就是封裝,然後打上”cloudhuan牌醬油”,就是打上meatadata信息。封裝除了是包裝外,還可以打上時間戳,避免音畫不同步呢。

推流

推流協議的話其實就兩個,基於tcp的rtmp和udp的webRTC和私有協議

rtmp是adobe的私有協議,已經不再維護,推流需要封裝成flv。

優點:主流,cdn都支持,用的最多,實現簡單,創業公司用這個成本最低

缺點:基於tcp的,tcp有超時重傳的機制,意味着弱網下,穩定性可能會出問題

webRTC視頻會議用得比較多,google出品(對,又是google,一個偉大的公司)

優點:開源的,基於udp意味着直播的時候可以對弱網指定一些丟包策略。

缺點:cdn支持不良

基於udp的私有協議,大公司一般會自己實現了,缺點同樣是cdn支持不好,然後要有一定技術才能去開發。

接收流媒體

流媒體協議用的最多了就三個,一般都是支持的:

rtmp和http-flv:

都是flv的格式,延遲都是2~4s,實時性都差不多,卻別在於http是存儲flv在客戶端的,而rtmp是存儲在服務器端的,都不支持web播放

hls:

唯一一個支持h5播放的流媒體協議,延遲4~10s,格式是ts + m3u8,觀看的時候先把一組.ts視頻下載,然後通過m3u8的索引去觀看,因為要先下載一段(N個ts文件+一個m3u8文件),所以延遲和段數有關,實時性不會太好。

音視頻採集封裝到直播推流原理

總結

最後複習一下

原理流程:

採集–>處理–>壓縮編碼–>封裝–>推流–>分發–>流媒體觀看

h264和h265比較、rtmp、http-flv、hls的異同點、幀內壓縮和幀間壓縮以及GOP的概念

原創文章,作者:投稿專員,如若轉載,請註明出處:https://www.506064.com/zh-hant/n/218120.html

(0)
打賞 微信掃一掃 微信掃一掃 支付寶掃一掃 支付寶掃一掃
投稿專員的頭像投稿專員
上一篇 2024-12-09 00:30
下一篇 2024-12-09 00:30

相關推薦

發表回復

登錄後才能評論