前言
不管是手機(jī)攝像頭還是一些芯片,他所采集到的實(shí)際上都是一幀一幀的圖像,當(dāng)幀數(shù)大于24-30的時候,對這些圖像進(jìn)行連續(xù)的播放,對人的感覺就像是視頻在播放 . 常見的圖片壓縮格式有:png,jpg等等.
我們?yōu)槭裁匆M(jìn)行壓縮呢?做一個假設(shè),一張圖片是2M,如果一段視頻是30幀,那么他如果不經(jīng)過處理,這段視頻一秒鐘的數(shù)據(jù)量就是60M,這在本地或者局域網(wǎng)倒是問題比較小,對一些發(fā)達(dá)國家來說或許也勉強(qiáng)可以,但對中國目前的互聯(lián)網(wǎng)環(huán)境來說,一分鐘傳輸60M文件,還是壓力很大的,所以我們便不得不去研究壓縮,在這里順便提一句,一位前輩曾告訴過我,音視頻開發(fā)到了后面,網(wǎng)絡(luò)就成了瓶頸,這句話剛開始其實(shí)還不是很明白,但現(xiàn)在已經(jīng)開始理解起來了.
H.264的壓縮算法可以很有效的對單幅圖片進(jìn)行壓縮,它的原理就是我第一篇文章中講到的IBP幀算法,兩幅圖片對前后不同的地方進(jìn)行傳輸,這樣就可以對圖像進(jìn)行大幅度的壓縮.如下圖所示,畫的不太好,意思一下.藍(lán)色地方就是兩幅圖不同的地方.
后來推出了H.265標(biāo)準(zhǔn)在720p畫質(zhì)以下時區(qū)別是不大的,在傳播4k這樣的畫質(zhì)時就可以看出明顯區(qū)別了,H.265的壓縮率會更高.
像iPhone和安卓手機(jī)內(nèi)部都是有硬編碼的芯片的,他的效率非常高,如果沒有硬編碼芯片,我們就需要使用FFmpeg,X264對其進(jìn)行編碼了.而硬解碼的芯片一般第三方是沒有權(quán)限去使用的徘郭，所以這時候我們就要用到FFmpeg了帜篇，像這種解碼的方式我們就稱其為軟解肺蔚，這種方式的解碼效率相比硬解碼來講是偏低的胞四，而我們的目的就是通過一些手段和方法來提高軟解碼的效率。
H.264解碼工具
在項(xiàng)目這里的三個文件是封裝好的解碼工具,注釋這里我沒有詳細(xì)的注釋,若果有不明白的地方,請翻閱第三篇文章,基本是類似的.
在這個工具類中取消了使用sws_scale()函數(shù)來進(jìn)行yuv->rgb的過程,他太消耗性能,我們可以使用libyuv或者交給Opengl的shader讓他利用硬件來進(jìn)行轉(zhuǎn)換,這個效率非常高.下面推薦一篇關(guān)于yuv->rgb優(yōu)化算法的一篇文章:鏈接.
這是雷博關(guān)于sws_scale()函數(shù)的介紹:鏈接
這是雷博關(guān)于sws_scale()函數(shù)性能的測試:鏈接
Opengl ES渲染工具
這個大體的邏輯就是將YUV420P數(shù)據(jù)通過rander轉(zhuǎn)化為RGB數(shù)據(jù),再利用紋理貼圖顯示出來,這是我找到的一個比較好的渲染工具類.工具類本身是繼承自UIView的,上面的scrollerview可以實(shí)現(xiàn)縮放等功能.
