1. 首頁 > 生活 > >

視頻號推流軟件B 視頻號推流工具

小知識



文章插圖
視頻號推流軟件B 視頻號推流工具

文章插圖
原理
基本步驟為：采集–壓縮編碼–封裝–推流–分發–流媒體協議觀看
采集
我們知道計算機都是只認識二進制的 ， 所以對于視頻采集 ， 其實就是把實際看到的東西轉為二進制的格式 ， 采集就是轉為二進制流的過程 。
這部分其實實際測試中關注的是比較少的 ， 因為客戶端針對的都是采集好的原始視頻或音頻流做處理 ， 這里要知道采集成的格式視頻是YUV ， 音頻是PCM 。
YUV來說 ， 其中“Y”表示明亮度（Luminance或Luma） ， 也就是灰階值；而“U”和“V” 表示的則是色度（Chrominance或Chroma） ， 作用是描述影像色彩及飽和度 ， 用于指定像素的顏色 。
處理
處理的過程主要是美顏和濾鏡了 ， 重點說說美顏 ， 美顏有兩步 ， 一個是磨皮 ， 一個是美白 ， 要想正確美顏 ， 所以還需要加上人臉識別技術和皮膚識別技術 。
這里要說說題外話 ， 美顏在壓縮編碼前處理可以說是最自然的 ， 缺點也有 ， 不能修改 。所以也有一種是通過播放器渲染”美顏” 。效果嘛 ， 呵呵 ?？上У氖俏覀冺椖棵李仦V鏡就是這樣做的 ， 個人還是不敢茍同的 ， 這樣做缺點非常明顯 ， 畫質不忍直視 ， 還要十分拖累幀數 ， 優點嘛 ， 修改和實現非常簡單 ， 成本也低
在針對原始流的處理 ， 除了濾鏡美顏外 ， 還可以自定義打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文件) ， 所以延遲和段數有關 ， 實時性不會太好 。
總結
最后復習一下
原理流程：
采集–>處理–>壓縮編碼–>封裝–>推流–>分發–>流媒體觀看
【視頻號推流軟件B 視頻號推流工具】h264和h265比較、rtmp、http-flv、hls的異同點、幀內壓縮和幀間壓縮以及GOP的概念