Android如何實(shí)現(xiàn)h264硬編碼

使用Android中的StageFright框架調(diào)用OpenMAX進(jìn)行硬件編碼，OMX部分由硬件廠(chǎng)商實(shí)現(xiàn)，無(wú)需關(guān)注，看好StageFright的調(diào)用方法即可

成都創(chuàng)新互聯(lián)是一家網(wǎng)站設(shè)計(jì)公司，集創(chuàng)意、互聯(lián)網(wǎng)應(yīng)用、軟件技術(shù)為一體的創(chuàng)意網(wǎng)站建設(shè)服務(wù)商，主營(yíng)產(chǎn)品：響應(yīng)式網(wǎng)站開(kāi)發(fā)、成都品牌網(wǎng)站建設(shè)、成都營(yíng)銷(xiāo)網(wǎng)站建設(shè)。我們專(zhuān)注企業(yè)品牌在網(wǎng)站中的整體樹(shù)立，網(wǎng)絡(luò)互動(dòng)的體驗(yàn)，以及在手機(jī)等移動(dòng)端的優(yōu)質(zhì)呈現(xiàn)。成都網(wǎng)站設(shè)計(jì)、網(wǎng)站制作、外貿(mào)營(yíng)銷(xiāo)網(wǎng)站建設(shè)、移動(dòng)互聯(lián)產(chǎn)品、網(wǎng)絡(luò)運(yùn)營(yíng)、VI設(shè)計(jì)、云產(chǎn)品.運(yùn)維為核心業(yè)務(wù)。為用戶(hù)提供一站式解決方案，我們深知市場(chǎng)的競(jìng)爭(zhēng)激烈，認(rèn)真對(duì)待每位客戶(hù)，為客戶(hù)提供賞析悅目的作品，網(wǎng)站的價(jià)值服務(wù)。

Android 音視頻01 --- H264的基本原理01

H264壓縮技術(shù)主要采用了以下幾種方法對(duì)視頻數(shù)據(jù)進(jìn)行壓縮。包括：

解決的是空域數(shù)據(jù)冗余問(wèn)題。

解決的是時(shí)域數(shù)據(jù)冗徐問(wèn)題

將空間上的相關(guān)性變?yōu)轭l域上無(wú)關(guān)的數(shù)據(jù)然后進(jìn)行量化。

經(jīng)過(guò)壓縮后的幀分為：I幀，P幀和B幀:

關(guān)鍵幀，采用幀內(nèi)壓縮技術(shù)。

向前參考幀，在壓縮時(shí)，只參考前面已經(jīng)處理的幀。采用幀音壓縮技術(shù)。

雙向參考幀，在壓縮時(shí)，它即參考前而的幀，又參考它后面的幀。采用幀間壓縮技術(shù)。

除了I/P/B幀外，還有圖像序列GOP。

H264的基本原理其實(shí)非常簡(jiǎn)單，下我們就簡(jiǎn)單的描述一下H264壓縮數(shù)據(jù)的過(guò)程。通過(guò)攝像頭采集到的視頻幀（按每秒 30 幀算），被送到 H264 編碼器的緩沖區(qū)中。編碼器先要為每一幅圖片劃分宏塊。

劃分好宏塊后，計(jì)算宏塊的象素值。以此類(lèi)推，計(jì)算一幅圖像中每個(gè)宏塊的像素值。

對(duì)于視頻數(shù)據(jù)主要有兩類(lèi)數(shù)據(jù)冗余，一類(lèi)是時(shí)間上的數(shù)據(jù)冗余，另一類(lèi)是空間上的數(shù)據(jù)冗余。其中時(shí)間上的數(shù)據(jù)冗余是最大的。為什么說(shuō)時(shí)間上的冗余是最大的呢？假設(shè)攝像頭每秒抓取30幀，這30幀的數(shù)據(jù)大部分情況下都是相關(guān)聯(lián)的。也有可能不止30幀的的數(shù)據(jù)，可能幾十幀，上百幀的數(shù)據(jù)都是關(guān)聯(lián)特別密切的。

H264編碼器會(huì)按順序，每次取出兩幅相鄰的幀進(jìn)行宏塊比較，計(jì)算兩幀的相似度。如下圖：

在H264編碼器中將幀分組后，就要計(jì)算幀組內(nèi)物體的運(yùn)動(dòng)矢量了。

H264編碼器首先按順序從緩沖區(qū)頭部取出兩幀視頻數(shù)據(jù)，然后進(jìn)行宏塊掃描。當(dāng)發(fā)現(xiàn)其中一幅圖片中有物體時(shí)，就在另一幅圖的鄰近位置（搜索窗口中）進(jìn)行搜索。如果此時(shí)在另一幅圖中找到該物體，那么就可以計(jì)算出物體的運(yùn)動(dòng)矢量了。

運(yùn)動(dòng)矢量計(jì)算出來(lái)后，將相同部分（也就是綠色部分）減去，就得到了補(bǔ)償數(shù)據(jù)。我們最終只需要將補(bǔ)償數(shù)據(jù)進(jìn)行壓縮保存，以后在解碼時(shí)就可以恢復(fù)原圖了。壓縮補(bǔ)償后的數(shù)據(jù)只需要記錄很少的一點(diǎn)數(shù)據(jù)。

我們把運(yùn)動(dòng)矢量與補(bǔ)償稱(chēng)為 幀間壓縮技術(shù) ，它解決的是視頻幀在時(shí)間上的數(shù)據(jù)冗余。除了幀間壓縮，幀內(nèi)也要進(jìn)行數(shù)據(jù)壓縮，幀內(nèi)數(shù)據(jù)壓縮解決的是空間上的數(shù)據(jù)冗余。

人眼對(duì)圖象都有一個(gè)識(shí)別度，對(duì)低頻的亮度很敏感，對(duì)高頻的亮度不太敏感。所以基于一些研究，可以將一幅圖像中人眼不敏感的數(shù)據(jù)去除掉。這樣就提出了幀內(nèi)預(yù)測(cè)技術(shù)。

一幅圖像被劃分好宏塊后，對(duì)每個(gè)宏塊可以進(jìn)行 9 種模式的預(yù)測(cè)。找出與原圖最接近的一種預(yù)測(cè)模式。然后，將原始圖像與幀內(nèi)預(yù)測(cè)后的圖像相減得殘差值。再將我們之前得到的預(yù)測(cè)模式信息一起保存起來(lái)，這樣我們就可以在解碼時(shí)恢復(fù)原圖了，經(jīng)過(guò)幀內(nèi)與幀間的壓縮后，雖然數(shù)據(jù)有大幅減少，但還有優(yōu)化的空間。

可以將殘差數(shù)據(jù)做整數(shù)離散余弦變換，去掉數(shù)據(jù)的相關(guān)性，進(jìn)一步壓縮數(shù)據(jù)。

上面的幀內(nèi)壓縮是屬于有損壓縮技術(shù)。也就是說(shuō)圖像被壓縮后，無(wú)法完全復(fù)原。而CABAC屬于無(wú)損壓縮技術(shù)。

無(wú)損壓縮技術(shù)大家最熟悉的可能就是哈夫曼編碼了，給高頻的詞一個(gè)短碼，給低頻詞一個(gè)長(zhǎng)碼從而達(dá)到數(shù)據(jù)壓縮的目的。MPEG-2中使用的VLC就是這種算法，我們以 A-Z 作為例子，A屬于高頻數(shù)據(jù)，Z屬于低頻數(shù)據(jù)?？纯此侨绾巫龅?。

CABAC也是給高頻數(shù)據(jù)短碼，給低頻數(shù)據(jù)長(zhǎng)碼。同時(shí)還會(huì)根據(jù)上下文相關(guān)性進(jìn)行壓縮，這種方式又比VLC高效很多。

制定了相互傳輸?shù)母袷?，將宏?有組織，有結(jié)構(gòu)，有順序的形成一系列的碼流。這種碼流既可 通過(guò) InputStream 網(wǎng)絡(luò)流的數(shù)據(jù)進(jìn)行傳輸，也可以封裝成一個(gè)文件進(jìn)行保存，主要作用是為了傳輸。

組成H264碼流的結(jié)構(gòu)中 包含以下幾部分 ，從大到小排序依次是：

H264視頻序列，圖像，片組，片，NALU，宏塊 ，像素。

NAL層:（Network Abstraction Layer,視頻數(shù)據(jù)網(wǎng)絡(luò)抽象層） ： 它的作用是H264只要在網(wǎng)絡(luò)上傳輸，在傳輸?shù)倪^(guò)程每個(gè)包以太網(wǎng)是1500字節(jié)，而H264的幀往往會(huì)大于1500字節(jié)，所以要進(jìn)行拆包，將一個(gè)幀拆成多個(gè)包進(jìn)行傳輸，所有的拆包或者組包都是通過(guò)NAL層去處理的。

VCL層:（Video Coding Layer,視頻數(shù)據(jù)編碼層） ： 對(duì)視頻原始數(shù)據(jù)進(jìn)行壓縮

起始碼0x 00 00 00 01 或者 0x 00 00 01 作為 分隔符 。

兩個(gè) 0x 00 00 00 01之間的字節(jié)數(shù)據(jù) 是表示一個(gè)NAL Unit。

I 幀的特點(diǎn)：

1.分組:把幾幀圖像分為一組(GOP，也就是一個(gè)序列),為防止運(yùn)動(dòng)變化,幀數(shù)不宜取多。

2.定義幀:將每組內(nèi)各幀圖像定義為三種類(lèi)型,即I幀、B幀和P幀;

3.預(yù)測(cè)幀:以I幀做為基礎(chǔ)幀,以I幀預(yù)測(cè)P幀,再由I幀和P幀預(yù)測(cè)B幀;

4.數(shù)據(jù)傳輸:最后將I幀數(shù)據(jù)與預(yù)測(cè)的差值信息進(jìn)行存儲(chǔ)和傳輸。

1．更高的編碼效率：同H.263等標(biāo)準(zhǔn)的特率效率相比，能夠平均節(jié)省大于50％的碼率。

2．高質(zhì)量的視頻畫(huà)面：H.264能夠在低碼率情況下提供高質(zhì)量的視頻圖像，在較低帶寬上提供高質(zhì)量的圖像傳輸是H.264的應(yīng)用亮點(diǎn)。

3．提高網(wǎng)絡(luò)適應(yīng)能力：H.264可以工作在實(shí)時(shí)通信應(yīng)用（如視頻會(huì)議）低延時(shí)模式下，也可以工作在沒(méi)有延時(shí)的視頻存儲(chǔ)或視頻流服務(wù)器中。

4．采用混合編碼結(jié)構(gòu)：同H.263相同，H.264也使用采用DCT變換編碼加DPCM的差分編碼的混合編碼結(jié)構(gòu)，還增加了如多模式運(yùn)動(dòng)估計(jì)、幀內(nèi)預(yù)測(cè)、多幀預(yù)測(cè)、基于內(nèi)容的變長(zhǎng)編碼、4x4二維整數(shù)變換等新的編碼方式，提高了編碼效率。

5．H.264的編碼選項(xiàng)較少：在H.263中編碼時(shí)往往需要設(shè)置相當(dāng)多選項(xiàng)，增加了編碼的難度，而H.264做到了力求簡(jiǎn)潔的“回歸基本”，降低了編碼時(shí)復(fù)雜度。

6．H.264可以應(yīng)用在不同場(chǎng)合：H.264可以根據(jù)不同的環(huán)境使用不同的傳輸和播放速率，并且提供了豐富的錯(cuò)誤處理工具，可以很好的控制或消除丟包和誤碼。

7．錯(cuò)誤恢復(fù)功能：H.264提供了解決網(wǎng)絡(luò)傳輸包丟失的問(wèn)題的工具，適用于在高誤碼率傳輸?shù)臒o(wú)線(xiàn)網(wǎng)絡(luò)中傳輸視頻數(shù)據(jù)。

8．較高的復(fù)雜度：264性能的改進(jìn)是以增加復(fù)雜性為代價(jià)而獲得的。據(jù)估計(jì)，H.264編碼的計(jì)算復(fù)雜度大約相當(dāng)于H.263的3倍，解碼復(fù)雜度大約相當(dāng)于H.263的2倍。

H.264的目標(biāo)應(yīng)用涵蓋了目前大部分的視頻服務(wù)，如有線(xiàn)電視遠(yuǎn)程監(jiān)控、交互媒體、數(shù)字電視、視頻會(huì)議、視頻點(diǎn)播、流媒體服務(wù)等。H.264為解決不同應(yīng)用中的網(wǎng)絡(luò)傳輸?shù)牟町悺６x了兩層：視頻編碼層（VCL：Video Coding Layer）負(fù)責(zé)高效的視頻內(nèi)容表示，網(wǎng)絡(luò)提取層（NAL：Network Abstraction Layer）負(fù)責(zé)以網(wǎng)絡(luò)所要求的恰當(dāng)?shù)姆绞綄?duì)數(shù)據(jù)進(jìn)行打包和傳送。

Android音視頻開(kāi)發(fā)——H264的基本概念

ffmpeg常用命令

封裝格式 。

編碼的本質(zhì)就是壓縮數(shù)據(jù)

音頻編碼的作用： 將音頻采樣數(shù)據(jù)（ PCM 等）壓縮成音頻碼流，從而降低音頻的數(shù)據(jù)量。 常用的音頻編碼方式有以下幾種：

H264壓縮技術(shù)主要采用了以下幾種方法對(duì)視頻數(shù)據(jù)進(jìn)行壓縮。包括：

經(jīng)過(guò)壓縮后的幀分為：I幀，P幀和B幀:

除了I/P/B幀外，還有圖像序列GOP。

組成碼流的結(jié)構(gòu)中，包含了以下幾個(gè)部分，從大到小依次是：

H264視頻序列，圖像，片組，片，NALU，宏塊，像素

H264功能分為兩層：

1.H264視頻序列包括一系列的NAL單元，每個(gè)NAL單元包含一個(gè)RBSP。

2.一個(gè)原始的H.264由 N個(gè)NALU單元組成

3.NALU單元由[StartCode][NALU Header][NALU Payload]三部分組成

5.NAL Header

由三部分組成forbidden_bit(1bit)(禁止位)，nal_reference_bit(2bits)（優(yōu)先級(jí),，值越大，該NAL越重要），nal_unit_type(5bits)（類(lèi)型）

nal_unit_type

6.NAL的解碼單元的流程如下

Android音頻開(kāi)發(fā)（三）——音頻編解碼

上一節(jié)中我們講了怎么采集音頻并播放，由于A(yíng)udioRecord采集的是PCM數(shù)據(jù)，沒(méi)有經(jīng)過(guò)處理，所有播放的時(shí)候會(huì)有雜音，嘯叫等現(xiàn)象出現(xiàn)。因此處理掉這些不需要的數(shù)據(jù)就是本節(jié)的內(nèi)容，編碼與解碼。

Android官方提供給我們的用于編解碼的類(lèi)是 MediaCodec ,它是android 4.1（API 16）才引入的，所以只能工作于andorid4.1以上的手機(jī)，如果想兼容4.1以下版本的手機(jī)，只能使用第三方庫(kù)，如大名鼎鼎的 ffmpeg ,B站的 ijkplayer 等。

（1）提供了一套訪(fǎng)問(wèn) Android 底層多媒體模塊的接口，主要是音視頻的編解碼接口

（2）在A(yíng)ndroid上，預(yù)設(shè)的多媒體框架是基于第三方PacketVideo公司的OpenCORE來(lái)實(shí)現(xiàn)，OpenCORE的優(yōu)點(diǎn)是兼顧了跨平臺(tái)的移植性，而且已經(jīng)過(guò)多方驗(yàn)證，所以相對(duì)來(lái)說(shuō)較為穩(wěn)定；缺點(diǎn)是國(guó)語(yǔ)龐大復(fù)雜，需要耗費(fèi)相當(dāng)多的時(shí)間去維護(hù)。因此從Android 2.0開(kāi)始，Google引進(jìn)了較為簡(jiǎn)潔的StageFright。Android 底層多媒體模塊采用的是 StageFright 框架，它是基于OpenMax標(biāo)準(zhǔn)實(shí)現(xiàn)的，任何 Android 底層編解碼模塊的實(shí)現(xiàn)，都必須遵循 OpenMax 標(biāo)準(zhǔn)。值得一提的是，OpenMAX是Khronos制定的API，Khronos也是OpenGL的制定者。Google 官方默認(rèn)提供了一系列的軟件編解碼器：包括：OMX.google.h264.encoder，OMX.google.h264.encoder， OMX.google.aac.encoder， OMX.google.aac.decoder 等等，而硬件編解碼功能，則需要由芯片廠(chǎng)商依照 OpenMax 框架標(biāo)準(zhǔn)來(lái)完成，所以，一般采用不同芯片型號(hào)的手機(jī)，硬件編解碼的實(shí)現(xiàn)和性能是不同的

（3）Android 應(yīng)用層統(tǒng)一由 MediaCodec API 來(lái)提供各種音視頻編解碼功能，由參數(shù)配置來(lái)決定采用何種編解碼算法、是否采用硬件編解碼加速等等

根據(jù)android官方文檔的描述，MediaCodec的核心就是使用緩沖區(qū)隊(duì)列來(lái)操作數(shù)據(jù)，使用流程如下：

//name既是媒體文件的類(lèi)型，如audio/3gpp，詳情參考MediaFormat的MIMETYPE常量

MediaCodec codec = MediaCodec.createByCodecName(name);

codec.configure(format, …);

MediaFormat outputFormat = codec.getOutputFormat(); // option B

codec.start();

for (;;) {

////獲取可用的inputBuffer -1代表一直等待，0表示不等待 建議-1,避免丟幀

int inputBufferId = codec.dequeueInputBuffer(-1);

if (inputBufferId = 0) {

ByteBuffer inputBuffer = codec.getInputBuffer(…);

// fill inputBuffer with valid data

…

codec.queueInputBuffer(inputBufferId, …);

}

//執(zhí)行上面的操作后就把待編解碼的數(shù)據(jù)存入了輸入緩沖區(qū)，然后下一步就是操作然后把編解碼的數(shù)據(jù)存入輸出緩沖區(qū)

int outputBufferId = codec.dequeueOutputBuffer(…);

if (outputBufferId = 0) {

ByteBuffer outputBuffer = codec.getOutputBuffer(outputBufferId);

MediaFormat bufferFormat = codec.getOutputFormat(outputBufferId); // option A

// bufferFormat is identical to outputFormat

// outputBuffer is ready to be processed or rendered.

…

codec.releaseOutputBuffer(outputBufferId, …);

} else if (outputBufferId == MediaCodec.INFO_OUTPUT_FORMAT_CHANGED) {

// Subsequent data will conform to new format.

// Can ignore if using getOutputFormat(outputBufferId)

outputFormat = codec.getOutputFormat(); // option B

}

}

codec.stop();

codec.release();

MediaCodec codec = MediaCodec.createByCodecName(name);

MediaFormat mOutputFormat; // member variable

codec.setCallback(new MediaCodec.Callback() {

@Override

void onInputBufferAvailable(MediaCodec mc, int inputBufferId) {

ByteBuffer inputBuffer = codec.getInputBuffer(inputBufferId);

// fill inputBuffer with valid data

…

codec.queueInputBuffer(inputBufferId, …);

}

@Override

void onOutputBufferAvailable(MediaCodec mc, int outputBufferId, …) {

ByteBuffer outputBuffer = codec.getOutputBuffer(outputBufferId);

MediaFormat bufferFormat = codec.getOutputFormat(outputBufferId); // option A

// bufferFormat is equivalent to mOutputFormat

// outputBuffer is ready to be processed or rendered.

…

codec.releaseOutputBuffer(outputBufferId, …);

}

@Override

void onOutputFormatChanged(MediaCodec mc, MediaFormat format) {

// Subsequent data will conform to new format.

// Can ignore if using getOutputFormat(outputBufferId)

mOutputFormat = format; // option B

}

@Override

void onError(…) {

…

}

});

codec.configure(format, …);

mOutputFormat = codec.getOutputFormat(); // option B

codec.start();

// wait for processing to complete

codec.stop();

codec.release();

MediaCodec codec = MediaCodec.createByCodecName(name);

codec.configure(format, …);

codec.start();

//API的區(qū)別在這里

ByteBuffer[] inputBuffers = codec.getInputBuffers();

ByteBuffer[] outputBuffers = codec.getOutputBuffers();

for (;;) {

int inputBufferId = codec.dequeueInputBuffer(…);

if (inputBufferId = 0) {

// fill inputBuffers[inputBufferId] with valid data

…

codec.queueInputBuffer(inputBufferId, …);

}

int outputBufferId = codec.dequeueOutputBuffer(…);

if (outputBufferId = 0) {

// outputBuffers[outputBufferId] is ready to be processed or rendered.

…

codec.releaseOutputBuffer(outputBufferId, …);

} else if (outputBufferId == MediaCodec.INFO_OUTPUT_BUFFERS_CHANGED) {

outputBuffers = codec.getOutputBuffers();

} else if (outputBufferId == MediaCodec.INFO_OUTPUT_FORMAT_CHANGED) {

// Subsequent data will conform to new format.

MediaFormat format = codec.getOutputFormat();

}

}

codec.stop();

codec.release();

文章標(biāo)題：h264android的簡(jiǎn)單介紹
網(wǎng)站網(wǎng)址：http://sd-ha.com/article22/hoosjc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供軟件開(kāi)發(fā)、商城網(wǎng)站、網(wǎng)站維護(hù)、虛擬主機(jī)、網(wǎng)站內(nèi)鏈、外貿(mào)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀(guān)點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)