1 encoder

?

2 slice write

?

3?analyse

?

FFMPEG中MPEG-2編解碼函數(shù)調(diào)用關(guān)系圖

1 Encoder

?

（函數(shù)調(diào)用從左到右，下同；圖片顯示不全時(shí)，請(qǐng)下載顯示）

?

2 P幀運(yùn)動(dòng)估計(jì)流程圖

3 B幀運(yùn)動(dòng)估計(jì)流程圖

?

?

4 decoder

?

?

ffmpeg的mpeg2編碼I幀代碼解讀

首先說(shuō)一下編碼的函數(shù)層次：
MPV_encode_picture
—encode_thread
———encode_mb_hq
————encode_mb（編碼一個(gè)宏塊）
——————encode_mb_internal（編碼I幀宏塊，在這個(gè)函數(shù)里面選擇不同的宏塊編碼器）
————————mpeg1_encode_mb（由于YUV的比例不一樣，4：4：4或者4：2：0，進(jìn)行宏塊編碼）
——————————mpeg1_encode_mb_internal（對(duì)宏塊進(jìn)行編碼）
————————————mpeg1_encode_block（對(duì)一個(gè)block進(jìn)行編碼，注意這里面的宏塊都是經(jīng)過(guò)DCT和量化之后的數(shù)據(jù)）：這個(gè)函數(shù)就是最需要看的咯：包括DC編碼和AC編碼，會(huì)選擇不同的碼表進(jìn)行編碼（詳細(xì)過(guò)程看代碼）

其次，所有的編碼后的數(shù)據(jù)都是通過(guò)函數(shù)put_bits寫(xiě)到比特流中

第三，以上的代碼解讀都不包括諸如圖片頭之類(lèi)的編碼，相應(yīng)的格式編碼可以在相應(yīng)層次中的函數(shù)里面找到。

第 四，libavcodec/mpegvideo_enc.c里面MPV_encode_init對(duì)編碼進(jìn)行初始化，主要是初始化，根據(jù) avctx->codec_id選擇不同的編碼標(biāo)準(zhǔn)，進(jìn)行不同的初始化，在656行，根據(jù)s->dct_quantize選擇了DCT系數(shù)和 量化器（因?yàn)椴煌木幋a標(biāo)準(zhǔn)，量化器是不一樣的），然而在程序里面，統(tǒng)一由函數(shù)指針指向的函數(shù)dct_quantize完成

第五，在encode_mb_internal里面首先，進(jìn)行了DCT和量化，然后進(jìn)行霍夫曼編碼——根據(jù)(s->codec_id)選擇不同的編碼器。DCT & quantize在1629行。

第五，在mpeg1_encode_block函數(shù)里面的block并沒(méi)有進(jìn)行zig-zag掃描，而 zig-zag掃描的過(guò)程，是在不斷的產(chǎn)生新的索引index，這個(gè)步驟是在885行的j = s->intra_scantable.permutated[i];完成的，j就是zig-zag掃描之后的索引，根據(jù)j索引出block中的數(shù)據(jù)。

簡(jiǎn)單的說(shuō)一下編碼的過(guò)程：
1.初始化，包括選擇DCT和量化器等等
2.編碼一個(gè)圖像（picture），將picture分成若干的mb（MacroBlock），這個(gè)時(shí)候要寫(xiě)入相應(yīng)的圖片頭信息
3. 編碼I幀MacroBlock，將MacroBlock分成若個(gè)小的block，由于YUV的比例不一樣，因此每次需要編碼的block的數(shù)量也是不一樣 的，在函數(shù)mpeg1_encode_mb里面，就區(qū)分了CHROMA_420和其他格式擁有不同的block數(shù)量。
4.編碼block，一個(gè)block包含三個(gè)編碼對(duì)象：DC系數(shù)，AC系數(shù)（level）和游程長(zhǎng)度。DC系數(shù)單獨(dú)用差分編碼，AC和run
聯(lián)合在一起編碼。這個(gè)過(guò)程都是在函數(shù)mpeg1_encode_block里面完成的。 1.MpegEncContext這個(gè)struct類(lèi)型，一定要吃透，雖然代碼是用C寫(xiě)得，但是寫(xiě)得很C++，這個(gè)MpegEncContext其實(shí)可以看做一個(gè)C++的類(lèi)，里面定義了很多指針，這些指針指又指向了一些strcut，而這個(gè)struct其實(shí)相當(dāng)于C++的成員函數(shù)，成員函數(shù)的初始化，一般是在XX_init函數(shù)里面初始化的。這一點(diǎn)，可以在后面的敘述中體現(xiàn)出來(lái)。

2.再說(shuō)一下編碼的過(guò)程，encode_mb_internal函數(shù)，做了MarcoBlock的編碼，在1629行，開(kāi)始做DCT&quant，1686行，開(kāi)始做霍夫曼編碼，而霍夫曼編碼，對(duì)不同的標(biāo)準(zhǔn)來(lái)說(shuō)，碼表是不一樣的，因此在1687行做了一個(gè)switch的選擇，mpeg1和mpeg2，都是用的相同的mpeg1_encode_mb函數(shù)進(jìn)行block的編碼，而block內(nèi)的編碼，在以前的筆記中已經(jīng)提到，過(guò)程這里不重復(fù)。

3.現(xiàn)在說(shuō)DCT&quant，其中，1635行s->block_last_index[i] = s->dct_quantize(s, s->block[i], i, s->qscale, &overflow);，就是做DCT&quant。正如第1點(diǎn)中說(shuō)的，dct_quantize本來(lái)只是MpegEncContext中的一個(gè)元素，類(lèi)型為指針，指向一個(gè)struct，而這個(gè)struct就相當(dāng)于C++里面的成員函數(shù)?，F(xiàn)在，我們知道了在這個(gè)地方，相當(dāng)于調(diào)用了一個(gè)成員函數(shù)，做了DCT&quant這件事情，接下來(lái)，討論這個(gè)成員函數(shù)在哪里初始化的。

4.在Mpegvideo.c的MPV_encode_init函數(shù)里面，對(duì)編碼所需要的一些“成員函數(shù)”進(jìn)行了初始化。前面一堆東西，是做編碼器的選擇。在第656行，dct_quant這成員函數(shù)被初始化為dct_quant_c這個(gè)函數(shù)。于是，接下去找dct_quant_c這個(gè)函數(shù)的定義。發(fā)現(xiàn)，3649行，又調(diào)用了dsp.fdct這個(gè)成員函數(shù)，做離散余弦變換。接下來(lái)找dsp.fdct這個(gè)成員函數(shù)的初始化地方。
這個(gè)非常費(fèi)勁，我找了半天才找到——在函數(shù)dsputil_init里面做了fdct的初始化，一步一步的跟蹤調(diào)用關(guān)系，可以發(fā)現(xiàn)過(guò)程是這樣的：
MPV_encode_init調(diào)用MPV_common_init，再調(diào)用dsputil_init，在dsputil_init里面初始化了fdct，而MPV_encode_init緊接著，執(zhí)行前面提到的dct_quantize的初始化。
至此，整個(gè)初始化完成。 1.完整的初始化過(guò)程，函數(shù)調(diào)用關(guān)系如下： encode_init MPV_encode_init：里面要根據(jù)不同的Codec_ID來(lái)配置一些數(shù)據(jù) MPV_common_init：基本的結(jié)構(gòu)體的初始化，在此之前，高度寬度等變量已經(jīng)設(shè)置好了 dsputil_init：初始化了fdct，而MPV_encode_init緊接著，執(zhí)行前面提到的dct_quantize的初始化。 然而，這個(gè)時(shí)候量化表并沒(méi)有初始化，量化表的初始化是用函數(shù)ff_set_qscale進(jìn)行的。而這個(gè)函數(shù)的調(diào)用關(guān)系，在第二點(diǎn)中講到 2.編碼器運(yùn)行的函數(shù)調(diào)用關(guān)系如下： MPV_encode_picture：頂層函數(shù) encode_picture：編碼一副圖像，這個(gè)時(shí)候首先要編碼圖像頭，調(diào)用mpeg1_encode_picture_header函數(shù)，然后在2912行，通過(guò)s指針調(diào)用了encode_thread函數(shù)，開(kāi)始編碼 encode_thread里面，調(diào)用了ff_set_qscale，進(jìn)行qscale的初始化，然后調(diào)用encode_mb_hq進(jìn)行編碼 encode_mb_hq調(diào)用encode_mb進(jìn)行宏塊編碼 encode_mb調(diào)用encode_mb_internal進(jìn)行幀內(nèi)編碼 encode_mb_internal調(diào)用mpeg1_encode_mb進(jìn)行編碼 mpeg1_encode_mb調(diào)用mpeg1_encode_mb_internal進(jìn)行編碼 mpeg1_encode_mb_internal調(diào)用mpeg1_encode_block進(jìn)行16x16的塊編碼 3.關(guān)于header mpeg1_encode_picture_header調(diào)用了mpeg1_encode_sequence_header寫(xiě)入了序列的頭 mpeg1_encode_sequence_header調(diào)用了ff_write_quant_matrix這里面，包括了要填的量化表的寫(xiě)入，這個(gè)量化表是用戶自定義的。在后面又調(diào)用了ff_mpeg1_encode_slice_header。 ff_mpeg1_encode_slice_header又調(diào)用了寫(xiě)header，寫(xiě)qscale的函數(shù)，寫(xiě)文件頭。 下面解釋一個(gè)block的編碼以及編碼碼表 1.首先編碼的是DC系數(shù)，在函數(shù)encode_dc里面進(jìn)行。由于DC系數(shù)的碼表有兩個(gè)，分別針對(duì)Y幀和（Cr，Cb）幀。編碼的時(shí)候，編碼的是非負(fù)的系數(shù)，但是原始的DC系數(shù)有正有負(fù)，因此需要做一個(gè)映射。這一個(gè)映射，在encode_dc里面，首先就用 if(((unsigned) (diff+255)) >= 511) 分成了兩部分，表示正負(fù)數(shù)的映射。而碼表的選擇，是根據(jù)component變量來(lái)選擇的。整個(gè)編碼過(guò)程和標(biāo)準(zhǔn)完全一樣。但是代碼中diff為正和為負(fù)的情況，表面上采用了不同的編碼方法，但是實(shí)質(zhì)上是完全一樣的。 mpeg1_lum_dc_uni的初始化在ff_mpeg1_encode_init里面完成，查看這個(gè)初始化過(guò)程，其實(shí)就是一個(gè)編碼過(guò)程。 2.對(duì)于其他系數(shù)的編碼，根據(jù)標(biāo)準(zhǔn)，存在兩種不同的情況： a.（level，run）較小的情況，直接進(jìn)行查表 b.（level，run）較大的情況，進(jìn)行所謂的換碼編碼，首先是寫(xiě)入一個(gè)Escape code，然后在加上level和run 因此，首先需要判斷（level，run）是否足夠大，代碼中用 if (alevel <= mpeg1_max_level[0][run]) 來(lái)解決這個(gè)問(wèn)題。mpeg1_max_level這個(gè)矩陣的構(gòu)成在ff_mpeg1_encode_init函數(shù)中，通過(guò)調(diào)用init_rl函數(shù)來(lái)實(shí)現(xiàn)，至于這個(gè)具體怎么初始化的，很容易看懂的（如果這個(gè)都看不懂，那ffmpeg代碼也就不要想看懂了） 3.在一個(gè)block的最后，需要編碼end of block，也是通過(guò)查表 4.現(xiàn)在解釋碼表，所有要用到的vlc的碼表存放在文件mpeg12data.c里面， mpeg1_vlc就是標(biāo)準(zhǔn)中的碼表B-14 mpeg2_vlc就是標(biāo)準(zhǔn)中的碼表B-15 兩個(gè)碼表，第一列表示碼字，第二列表示碼字長(zhǎng)度，對(duì)照標(biāo)準(zhǔn)上面的碼表，很容易發(fā)現(xiàn)這兩個(gè)數(shù)組的構(gòu)成方法（具體是什么，看一下就知道了，很容易的） 看懂了這里，也就很容易看懂在mpeg12enc.c里面對(duì)于其他系數(shù)的編碼了 最后要說(shuō)的是，ffmpeg的代碼寫(xiě)的非常的晦澀，寫(xiě)得非常的不對(duì)稱，比如encode_dc就是這樣的，碼表的初始化也比較混亂，因而看起來(lái)很費(fèi)勁

MPEG-4 AVC/H.264 信息

作者：haibara????來(lái)源：pcicp.com????DVDrip制作????2006-6-15 14:13:02?

?

本FAQ系列由（haibara）翻譯，期間受到kaito_mkid（pcicp）幫助，在此感謝，由于Newbie的關(guān)系，如有翻譯錯(cuò)誤，還請(qǐng)各位指出，由Doom9的bond編撰的原文。

譯者注：基本專業(yè)名稱我都以小括號(hào)形式加以解釋，詳細(xì)信息請(qǐng)自行查閱資料。

什么是MPEG-4？

MPEG-4（ISO 14496）是由制定了我們熟知的MPEG-1（MP3, VCD）和MPEG-2（DVD, SVCD）標(biāo)準(zhǔn)，并力于使各種音頻/視頻壓縮格式和更多內(nèi)容標(biāo)準(zhǔn)化的國(guó)際標(biāo)準(zhǔn)化組織(International Organization for Standardization/ISO)的工作組，即運(yùn)動(dòng)圖像專家組(Moving Picture Experts Group/MPEG)發(fā)展的廣泛的開(kāi)放標(biāo)準(zhǔn)。
本質(zhì)上MPEG-4標(biāo)準(zhǔn)不僅把目標(biāo)定為標(biāo)準(zhǔn)化某些有發(fā)展前途的產(chǎn)品（例如達(dá)到DVD性能），而且含蓋了一個(gè)能讓產(chǎn)品供應(yīng)商根據(jù)需要選擇適當(dāng)標(biāo)準(zhǔn)去執(zhí)行的廣泛的次級(jí)標(biāo)準(zhǔn)。

MPEG-4標(biāo)準(zhǔn)，如上所說(shuō)，被分成許多不同的次級(jí)標(biāo)準(zhǔn)，在Doom9里我們使用者可能最感興趣的部分如下：
- ISO 14496-1（Systems/系統(tǒng)），動(dòng)畫(huà)/交互性（類(lèi)DVD菜單）
- ISO 14496-2（Video/視頻），如Advanced Simple Profile(ASP/高級(jí)簡(jiǎn)單類(lèi))，由XviD, DivX5, 3ivx...執(zhí)行
- ISO 14496-3（Audio/音頻），Advanced Audio Coding(AAC/先進(jìn)音頻編碼)
- ISO 14496-10（Video/視頻），Advanced Video Coding(AVC/進(jìn)階視頻編碼)，著名有H.264
- ISO 14496-14（Container/容器），MP4容器格式（使用.mp4作擴(kuò)展名）
- ISO 14496-17（Subtitles/字幕），MPEG-4時(shí)標(biāo)文本字幕格式

這些信息頁(yè)面正力于提供這些標(biāo)準(zhǔn)的大部分有用的信息，尤其是作為焦點(diǎn)的MPEG-4 ASP和AVC/H.264。


與封閉格式如Micro$oft的Windows Media相比，象MPEG-4一樣的開(kāi)放標(biāo)準(zhǔn)有什么可能的優(yōu)勢(shì)？

開(kāi)放標(biāo)準(zhǔn)的一個(gè)好處是當(dāng)創(chuàng)建產(chǎn)品時(shí)允許向所有人開(kāi)放并遵循它。因此我們已經(jīng)有許多不同的符合MPEG-4標(biāo)準(zhǔn)并可互相兼容的產(chǎn)品。
其次是互通性和大范圍的產(chǎn)品選擇性，一個(gè)開(kāi)放標(biāo)準(zhǔn)導(dǎo)致競(jìng)爭(zhēng)，對(duì)顧客而言這意味著產(chǎn)品在競(jìng)爭(zhēng)市場(chǎng)中能更好地提高品質(zhì)，更少的價(jià)格和更關(guān)注顧客需求。

但不要忘記這也許對(duì)我們來(lái)說(shuō)最重要的一點(diǎn)：
一個(gè)開(kāi)放標(biāo)準(zhǔn)允許開(kāi)源發(fā)展，例如我們熟知的XviD。

ISO 14496-10 (Video) - 進(jìn)階視頻編碼(Advanced Video Coding/AVC)

有著AVC/H.264的MPEG-4標(biāo)準(zhǔn)定義了一個(gè)擁有最新，最高技術(shù)的實(shí)用的，充滿尖端科技的視頻編碼格式。

2003年，ISO的MPEG(Moving Pictures Experts Group/運(yùn)動(dòng)圖像專家組)與聯(lián)合國(guó)(United Nations/UNO)下設(shè)的ITU(International Telecommunication Union/國(guó)際電信聯(lián)盟)的VCEG(Video Coding Experts Group/視頻編碼專家組)這2大組織最終完成并共同規(guī)定了AVC/H.264視頻編碼標(biāo)準(zhǔn)，其中后者曾標(biāo)準(zhǔn)化H.263格式（現(xiàn)主用于視頻會(huì)議）。
AVC/H.264標(biāo)準(zhǔn)它自身是由MPEG和VCEG的專家構(gòu)成的Joint Video Team(JVT/聯(lián)合視頻組)發(fā)展的。

由MPEG來(lái)看，該標(biāo)準(zhǔn)被叫做MPEG-4 Part 10（ISO 14496-10）；由ITU來(lái)看，它叫做H.264（ITU的公文號(hào)） 其中作為后者已廣泛流傳開(kāi)來(lái)。
新標(biāo)準(zhǔn)選擇Advanced Video Coding(AVC/進(jìn)階視頻編碼)作為“官方”名 - 因?yàn)閷?duì)應(yīng)視頻的音頻格式是Advanced Audio Coding(AAC/先進(jìn)音頻編碼)。


AVC/H.264 Profile

AVC/H.264定義了4種不同的Profile(類(lèi))：Baseline(基線類(lèi)), Main(主要類(lèi)), Extended(擴(kuò)展類(lèi))和High Profile(高端類(lèi))（它們各自下分成許多個(gè) 層）：

- Baseline Profile 提供I/P幀，僅支持progressive(逐行掃描)和CAVLC
- Extended Profile 提供I/P/B/SP/SI幀，僅支持progressive(逐行掃描)和CAVLC
- Main Profile 提供I/P/B幀，支持progressive(逐行掃描)和interlaced(隔行掃描)，提供CAVLC或CABAC
- High Profile （也就是FRExt）在Main Profile基礎(chǔ)上新增：8x8 intra prediction(8x8 幀內(nèi)預(yù)測(cè)), custom quant(自定義量化), lossless video coding(無(wú)損視頻編碼), 更多的yuv格式（4:4:4...）

只有未來(lái)會(huì)告訴我們哪一種框架和工具最可能被用于DVD備份，但是我猜想會(huì)是有著以下的工具大力幫助的Main和/或High Profile（同樣請(qǐng)核實(shí) MPEG-4 ASP的工具描述，除了GMC，所有的工具在AVC下都是可用的）：

CAVLC/CABAC：
AVC/H.264定義了2種先進(jìn)的重構(gòu)數(shù)據(jù)流（包括macroblock-type(宏塊), motionvectors(運(yùn)動(dòng)矢量) + reference-index(參考索引)...）的熵編碼工具，一舉超越MPEG-4 ASP：
Context-Adaptive Variable Length Coding(CAVLC/上下文自適應(yīng)變長(zhǎng)編碼)和 Context-Adaptive Binary Arithmetic Coding(CABAC/上下文自適應(yīng)二進(jìn)制算術(shù)編碼)
CABAC，與AVC/H.264中只是默認(rèn)算法的CAVLC（也叫UVLC）相比，是個(gè)壓縮率更強(qiáng)大的算法，據(jù)說(shuō)能額外降低10-15%的比特率（特別在高碼率）。CABAC（同CAVLC一樣）是一種無(wú)損算法，因此不會(huì)降低質(zhì)量，但會(huì)減緩編碼和解碼速度。

Loop/Deblocking Filter(循環(huán)/去塊濾波器)：
與預(yù)處理濾波器（例如通過(guò)avisynth作用于輸入端），或后處理濾波器（通過(guò)解碼器作用于最終輸出端）相反，循環(huán)濾波器在編碼過(guò)程中對(duì)每楨進(jìn)行濾波，編碼完成后被用于下一楨的參考。它能消除塊效應(yīng)，尤其在低碼率時(shí)，但同樣會(huì)減緩編碼和解碼速度。

Variable Block Sizes/Macroblock Partitions(塊大小可變/宏塊劃分)：
與MPEG-4 ASP（僅Inter4V/4MV能作16x16和8x8塊變換）相比，AVC/H.264把動(dòng)態(tài)搜尋精度(Motion Search Precision)提高到4x4（包含的步驟有8x4...）。子塊大小是自適應(yīng)/可變的，一個(gè)優(yōu)秀的編碼器應(yīng)能對(duì)每個(gè)宏塊明智地作出最恰當(dāng)?shù)膭澐执笮Q定。

Multiple Reference Frames(多重參考楨)：
與MPEG-4 ASP（僅允許當(dāng)前楨的前一楨作為參考楨）相比，AVC/H.264使用幀間搜索方式并提供成倍的參考楨選擇，它意味著AVC/H.264編碼能決定是否只是簡(jiǎn)單地參考前一楨或甚至參考比前楨更過(guò)去的楨。因此（例如某個(gè)P楨能參考最近I楨前的某楨）不得不提出一種新型楨型：IDR楨，是種其后的楨不允許參考其前的楨的I楨。使用多重參考楨會(huì)減慢編碼和解碼速度并且可能導(dǎo)致只能在IDR楨剪切。

Weighted Prediction(加權(quán)預(yù)測(cè))：
有了加權(quán)預(yù)測(cè)就能對(duì)參考楨進(jìn)行加權(quán)（例如你能測(cè)量前一幅圖象的亮度程度）。它特別有助于在那些隨時(shí)可能淡入或淡出的場(chǎng)景中前后圖象極為相似，只是畫(huà)面變暗的圖象的處理。WP對(duì)于同時(shí)出現(xiàn)淡入及淡出的圖象沒(méi)有效果（例如當(dāng)圖象從一個(gè)場(chǎng)景轉(zhuǎn)到另一個(gè)場(chǎng)景就會(huì)同時(shí)出現(xiàn)淡入及淡出）。

Rate Distortion Optimisation(RDO/碼率-失真/損耗最佳化)：
只要編碼器不得不在眾多選擇中作出絕擇時(shí)，RDO允許選擇最有效的編碼方式（例如面臨采用楨間/楨內(nèi)的動(dòng)態(tài)搜尋的決定...）
RDO不是AVC/H.264本身定義的工具，它是第一個(gè)由H.264參考軟件引入的工具，可謂一種新的途徑。其他的編碼也能利用RDO，如XviD'的VHQ模式能使用RDO


AVC/H.264與其他流行的視頻編碼格式的比較測(cè)評(píng)：
?

現(xiàn)有的AVC/H.264編碼

可用于終端用戶的AVC/H.264執(zhí)行者有 x264, Nero, Apple, Sorenson, Elecard, Moonlight, VSS, mpegable, Envivio, Hdot264 ( binary), DSPR, JM (參考軟件) ( binary), ffmpeg, Philips, FastVDO, Skal, Sony和 更多

編碼器

- x264：第一個(gè)公開(kāi)的可使用High Profile的編碼器，開(kāi)源（GPL）（ 源碼），使用VFW的有： x264vfw, ffdshow（輸出.avi），命令行的： x264cli（輸出raw的.mp4）, mencoder（輸出raw的.avi）（Doom9的 MeGUI）或 ffmpeg
x264支持2pass, CABAC, 循環(huán)濾波, 多重B幀, 雙向參考(B-Reference), 多重參考楨, 4x4 P幀塊變換, 8x8 B幀塊劃分, 失真信號(hào)化(anamorphic signalling)和High Profile：8x8 dtc(離散余弦變換)與幀內(nèi)預(yù)測(cè), 無(wú)損視頻編碼和自定義無(wú)損量化矩陣(custom quant matrix)
- NeroDigital AVC： Nero Recode2內(nèi)含，輸出為.mp4
ND AVC支持2pass, CABAC, 自適應(yīng)循環(huán)濾波, 多重B幀, 多重參考楨, 加權(quán)預(yù)測(cè), 8x8 B幀塊劃分, 16x16 B幀塊劃分, 自適應(yīng)量化（高度Psy）
- Sorenson： Sorenson Squeeze 4內(nèi)含，輸出.mp4,
Sorenson支持2pass, 最大2連續(xù)B幀, 雙向參考, 循環(huán)濾波和多重Slice
- Apple： Quicktime 7內(nèi)含，輸出.mp4, .3gp和.mov，編碼速度很慢
支持2pass, 最大1連續(xù)B幀, 循環(huán)濾波(0,0), 8x8 P幀塊變換, 8x8 B幀塊變換, 4x4 I幀塊變換, 自適應(yīng)量化, 5級(jí)Slice, 沒(méi)有CABAC, 沒(méi)有加權(quán)預(yù)測(cè), 沒(méi)有多重參考楨
- JM：此AVC參考軟件v9.3版提供Main和High Profile：B/SP幀, CABAC, 循環(huán)濾波器, 4x4 塊劃分, 多重參考楨, 自適應(yīng)量化, 差錯(cuò)修復(fù)(Error Resilience), RDO, 無(wú)損視頻編碼, 自定義量化), 比率控制(Rate Control)等...
- Hdot264：由doom9會(huì)員charact3r發(fā)展的開(kāi)源（GPL）的VFW版參考軟件，仍然以很老的參考軟件（JM 4.0c）為基礎(chǔ)
- VSS：免費(fèi)的VFW編碼器（可預(yù)覽5天），以參考編碼器為基礎(chǔ)
- Elecard： Elecard Mobile Converter內(nèi)含，輸出.mp4， MainConcept's v2 encoder也內(nèi)含，輸出.264和.mpg PS/TS
不再公開(kāi)的：
- Moonlight：Moonlight的 OneClick Compressor v1.1和CyberLink的 PowerEncoder內(nèi)含，輸出.mpg
Moonlight支持1pass（VBR/CBR/預(yù)設(shè) 量化）, CABAC, 循環(huán)濾波, 最大2連續(xù)B幀, 8x8 B幀塊劃分, 自適應(yīng)量化, 自動(dòng)調(diào)整PAR(Pixel Aspect Ratio/象素縱橫比), 隔行掃描
- MainConcept：免費(fèi)的編碼器（有水印），輸出.264和.mpg PS/TS
1pass（CBR/VBR/預(yù)設(shè) 量化）, P幀重排(P-Frame Reorder), CABAC, 循環(huán)濾波, 多重B-Vops(Bidirectional Video Object Planes/雙向視頻對(duì)象平面), 多重參考楨, 4x4 P幀塊劃分), PAR, RDO
- mpegable：提供試用有限的免費(fèi)VFW編碼器（不以參考軟件為基礎(chǔ)），不支持YV12
mpegable支持僅限P幀的1pass（預(yù)設(shè)量化）, 8x8 P幀塊劃分, 只支持CAVLC, 循環(huán)濾波
- Envivio： 4Coder內(nèi)含，輸出.mp4

解碼器 ( 比較測(cè)評(píng))

- ffmpeg：開(kāi)源（LGPL），包含在 ffdshow（VFW和DShow編碼器), mplayer和 VideoLAN等
支持B幀, 雙向參考, CABAC, 循環(huán)濾波, 加權(quán)預(yù)測(cè)和High Profile (8x8 dct與幀內(nèi)預(yù)測(cè), 無(wú)損視頻編碼)
- Apple：Quicktime 7支持AVC解碼，支持.mp4/.mov，解碼速度很慢
僅支持最大1連續(xù)B幀, CABAC, 不作后幀參考的循環(huán)濾波, 多重B幀和隔行掃描
- NeroDigital AVC：Recode2附帶DShow解碼器和.mp4 Parser
支持Main和High Profile
- VSS：VFW解碼器 (預(yù)覽5天) 和 DShow解碼器 (限制30天)
VSS DShow支持.avi (支持VSSH和H264 fourcc), CABAC, 循環(huán)濾波, B幀
- Elecard： Elecard's MPEG Player v4.0和 MainConcept's v2 encoder內(nèi)含
- Envivio：有個(gè)名叫EnvivioTV的非免費(fèi)AVC DShow解碼器，（從2.0版開(kāi)始，當(dāng)前版本為2-1-181）支持混合AVC的.mp4
- Philips： AVC Alliance播放器內(nèi)含免費(fèi)的DShow AVC解碼器（只支持raw AVC）
- FastVDO：有時(shí)間限制（每個(gè)視頻文件5分鐘）的High Profile DShow解碼器
- Pegasus： 這里有發(fā)展不成熟的DShow AVC解碼器
- Basic AVC Decoder用C編寫(xiě)，是一所大學(xué)的工程，見(jiàn) 這里
不再公開(kāi)的：
- Moonlight：DShow解碼器/Parser支持混合AVC的.mpg, .mp4和.264 Moonlight's MPEG Player v3.0內(nèi)含
支持Main和High Profile
- MainConcept：v1預(yù)覽版提供免費(fèi)DShow AVC解碼器（有水印) 并且Parser支持AVC和.mpg PS/TS
- mpegable：提供試用有限的VFW解碼器 (可用于DShow)，支持.avi (支持 DAVC fourcc)


預(yù)覽樣本

NeroDigital： mp4, mp4
Sorenson： mp4
AVC Alliance： raw
Moonlight： raw/中碼率, raw/低碼率, raw, mpg
FastVDO： raw/high profile
Apple： mov
Videosoft: avi, avi/新, avi/老
Lead： ogm


當(dāng)前AVC/H.264的爭(zhēng)論

- 互通性：大多數(shù)執(zhí)行者支持多種容器格式：
.mp4：由MPEG-4標(biāo)準(zhǔn)（ISO 14496-15）定義的AVC容器，Apple, Nero, Sorenson, Envivio, Elecard/Moonlight和x264都支持
.mpg PS/TS：由MPEG-2標(biāo)準(zhǔn)（ISO 13818-1, AMD3）定義的AVC容器，Mainconcept和Elecard/Moonlight支持
.avi：采取AVC-in-AVI的方式非標(biāo)準(zhǔn)，因此會(huì)造成不兼容問(wèn)題。 AVI和VFW的局限（如關(guān)于B幀或任意幀的編碼順序），混合這兩種格式混合會(huì)完全阻礙AVC提供的所有可能特性的執(zhí)行，因此可能降低質(zhì)量，或至少降低處理速度和互通性，其競(jìng)爭(zhēng)性也因此下降。當(dāng)前VSS和x264（mencoder 和vfw）支持使用AVI
.264/.h264：未混合入容器的原始數(shù)據(jù)流。JM參考軟件, x264cli, mencoder和mainconcept都可輸出

- 速度：當(dāng)前一些執(zhí)行者編碼器速度不敢恭維，依然只有x264和NeroDigital's AVC的編碼器看上去能提供不俗的速度與品質(zhì)。但這不會(huì)改變AVC是種先進(jìn)的視頻編碼方式的事實(shí)。所以老的CPU編解碼AVC會(huì)非常耗時(shí)


MPEG-4 AVC/H.264的硬件應(yīng)用化 - HD-DVD/藍(lán)光(Blu-ray)

DVD論壇(DVD Forum)和藍(lán)光光盤(pán)協(xié)會(huì)(Blu-ray Disc Association)正在討論能支持高清晰(High Definition)內(nèi)容（存儲(chǔ)容量完全超過(guò)當(dāng)前的DVD）下一代DVD格式的繼承人選：HD-DVD和BD-ROM

據(jù) 這里報(bào)道HD-DVD會(huì)強(qiáng)制采用MPEG-4 AVC/H.264，而藍(lán)光支持老早被MPEG-4 AVC/H.264 High Profile納入- 這里

因此AVC/H.264極有可能成為下一代視頻格式，會(huì)被廣泛地使用和支持，就象今天MPEG-2（用于DVD)的情形一樣

FFMPEG 學(xué)習(xí)筆記

一 Encoder函數(shù)調(diào)用圖

1 avcodec_encode_video
? |___ avcodec_check_dimensions
? |___ avctx->codec->encode(for mpeg-2 call MPV_encode_picture)
????? |___ init_put_bits(for multiple thread)
????? |___ load_input_picture(copy data from input pic_arg)
????? |___ select_input_picture(I,B,P)
????? |___ MPV_frame_start
????? |___ encode_picture
????? |???????????????? |___ s->avctx->execute
????? |???????????????? |___ encode_thread
????? |????????????????????? |___ encode_mb
????? |????????????????????? |___ MPV_decode_mb
????? |
????? |
????? |___ MPV_frame_end

x264中的Decoder

在早期的x264版本中，包括decoder和encoder兩部分，后來(lái)不知道出于什么原因，decoder部分的代碼沒(méi)有再繼續(xù)維護(hù)，這部分代碼一直保留到了20061009的版本（?X264_BUILD 53）；但因?yàn)槠陂gencoder部分的代碼有較大的改動(dòng)，包括數(shù)據(jù)結(jié)構(gòu)的變化，導(dǎo)致兩部分代碼只有在較低版本時(shí)才可以同時(shí)正常編譯。

?

我使用#define X264_BUILD 0x0002版本的代碼進(jìn)行了測(cè)試。發(fā)現(xiàn)Decoder代碼存在以下問(wèn)題：

1 僅支持BaseLine的解碼，因?yàn)槠渲袥](méi)有B幀和CABAC的解碼部分。

2 代碼中有兩個(gè)BUG需要自己解決一下。

?? a. x264_realloc函數(shù)中，把

??????????? *( (int*) ( (uint8_t*) p ) - sizeof( void ** ) -
???????????????????????? sizeof( int ) );

?????? 改為

??????????? *( (int*) (( (uint8_t*) p ) - sizeof( void ** ) -
???????????????????????? sizeof( int ) ));

??? b. x264_slice_header_ref_pic_reordering函數(shù)中，把

??? if( h->i_ref0 > h->pps->i_num_ref_idx_l0_active )
??? {
??????? h->i_ref0 = h->pps->i_num_ref_idx_l0_active;
??? }
??? if( h->i_ref1 > h->pps->i_num_ref_idx_l1_active )
??? {
??????? h->i_ref1 = h->pps->i_num_ref_idx_l1_active;
??? }
改為：

?if( h->i_ref0 > h->sh.i_num_ref_idx_l0_active )
?{
??h->i_ref0 = h->sh.i_num_ref_idx_l0_active;
?}
?if( h->i_ref1 > h->sh.i_num_ref_idx_l1_active )
?{
??h->i_ref1 = h->sh.i_num_ref_idx_l1_active;
?}

?

?

3 其它一些頭文件的改動(dòng)，因?yàn)閮刹糠执a中有一些同名的文件，需要在include時(shí)加上相應(yīng)的目錄名。

x264 代碼下載信息

2011-08-11

1 不同版本的x264下載地址：http://download.videolan.org/pub/videolan/x264/snapshots/

2 x264從20061010起（即這個(gè)版本x264-snapshot-20061010-2245.tar.bz2）不再支持decoder代碼。

H.264/AVC中CAVLC編碼方法簡(jiǎn)介

H.264/AVC中CAVLC編碼方法簡(jiǎn)介

?

一 名詞

?????? TotalCoeffs：全部非零系數(shù)個(gè)數(shù)。（0～16）

?????? TotalZeros：最后一個(gè)非零系數(shù)前的零的個(gè)數(shù)。

?????? TrailingOnes：拖尾系數(shù)（即＋1）的個(gè)數(shù)。（0~3）

?????? NC：當(dāng)前塊值。除色度的直流系數(shù)外（常數(shù)－1），其它系數(shù)類(lèi)型NC值是根據(jù)當(dāng)前左邊4x4塊的非零系數(shù)數(shù)目（NA）和當(dāng)前塊上面4x4的非零系數(shù)的數(shù)目（NB求得的。

?????? 計(jì)算NC的值

上面的塊（NB）	左達(dá)的塊（NA）	NC
X	X	（NA+NB）/2
X	?	NA
?	X	NB
?	?	0

?????? 選擇非零系數(shù)個(gè)數(shù)和拖尾系數(shù)個(gè)數(shù)的編碼表格（表格見(jiàn)畢書(shū)附錄）：

NC	表格
0<=NC<2	變長(zhǎng)表格1
2<=NC<4	變長(zhǎng)表格2
5<=NC<8	變長(zhǎng)表格3
NC=-1	變長(zhǎng)表格4
NC>=8	定長(zhǎng)表格

?

?

二 編碼過(guò)程

?????? 1. 對(duì)TotalCoeffs和TrailingOnes進(jìn)行組合編碼，稱為Coeff_token。

?????? 2. 對(duì)拖尾系數(shù)的符號(hào)進(jìn)行編碼，＋為1，－為0，從右向左。

?????? 3. 對(duì)非零系數(shù)（不包括拖尾系數(shù)，拖尾系數(shù)已經(jīng)編碼）進(jìn)行編碼，從右向左。

?????? 4. 對(duì)TotalZeros進(jìn)行編碼。

?????? 5. 對(duì)非零系數(shù)前的零的個(gè)數(shù)進(jìn)行編碼，從右向左，最后一個(gè)（從左邊數(shù)第一個(gè)）非零系數(shù)前的零的個(gè)數(shù)不需要編碼（剩下的零都是這個(gè)位置的）。

以下4x4塊為例（畢書(shū)P123，原例有誤）：

0? 0 ?-1 ?0

5? 2? 0? 0

3? 0? 0? 0

1? 0? 0? 0

Z掃描完成后： 0,0,5,3,2,-1,0,0,0,1…

No	元素	數(shù)值	編碼	說(shuō)明
1	Coeff_token	TotalCoeffs=5,TrailingOnes=2	0000101	TotalCoeffs ,和TrailingOnes的組合進(jìn)行編碼
2-1	TrailingOnes_sign_flag	+	1	拖尾系數(shù)的符號(hào)，從右向左
2-2	TrailingOnes_sign_flag	－	0	?
3-1	Level(2)	1（suffixLength=0）	1	?
3-2	Level(1)	3（suffixLength=1）	0010	?
3-3	Level(0)	5（suffixLength=1）	000010	?
4	Total_zeros	5	101	?
5-1	Run_before(4)	ZeroLeft=5, run_before=3	010	?
5-2	Run_before(3)	ZeroLeft=2, run_before=0	1	?
5-3	Run_before(2)	ZeroLeft=2, run_before=0	1	?
5-4	Run_before(1)	ZeroLeft=2, run_before=0	1	?
5-5	Run_before(0)	ZeroLeft=2, run_before=2	?	最后一個(gè)不需要編碼

?

編碼輸出：00001011010010000010101010111

總結(jié)

以上是生活随笔為你收集整理的x264函数调用关系图的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。