?

轉(zhuǎn)

一，ffmpeg架構(gòu)

1. 簡介

FFmpeg 是一個集錄制、轉(zhuǎn)換、音 / 視頻編碼解碼功能為一體的完整的開源解決方案。 FFmpeg 的

開發(fā)是基于 Linux 操作系統(tǒng)，但是可以在大多數(shù)操作系統(tǒng)中編譯和使用。 FFmpeg 支持 MPEG 、

DivX 、 MPEG4 、 AC3 、 DV 、 FLV 等 40 多種編碼， AVI 、 MPEG 、 OGG 、 Matroska 、 ASF 等 90 多種解碼 .

TCPMP, VLC, MPlayer 等開源播放器都用到了 FFmpeg 。

FFmpeg 主目錄下主要有 libavcodec 、 libavformat 和 libavutil 等子目錄。其中 libavcodec 用

于存放各個 encode/decode 模塊， libavformat 用于存放 muxer/demuxer 模塊， libavutil 用于

存放內(nèi)存操作等輔助性模塊。

以 flash movie 的 flv 文件格式為例， muxer/demuxer 的 flvenc.c 和 flvdec.c 文件在

libavformat 目錄下， encode/decode 的 mpegvideo.c 和 h263de.c 在 libavcodec 目錄下。

?

2. muxer/demuxer 與 encoder/decoder 定義與初始化

muxer/demuxer 和 encoder/decoder 在 FFmpeg 中的實現(xiàn)代碼里，有許多相同的地方，而二者最

大的差別是 muxer 和 demuxer 分別是不同的結(jié)構(gòu) AVOutputFormat 與 AVInputFormat ，而 encoder

和 decoder 都是用的 AVCodec 結(jié)構(gòu)。

?

muxer/demuxer 和 encoder/decoder 在 FFmpeg 中相同的地方有：

??? 二者都是在 main() 開始的 av_register_all() 函數(shù)內(nèi)初始化的

??? 二者都是以鏈表的形式保存在全局變量中的

??????? muxer/demuxer 是分別保存在全局變量 AVOutputFormat *first_oformat 與

??????? AVInputFormat *first_iformat 中的。

??????? encoder/decoder 都是保存在全局變量 AVCodec *first_avcodec 中的。

??? 二者都用函數(shù)指針的方式作為開放的公共接口

???

demuxer 開放的接口有：

??? int (*read_probe)(AVProbeData *);

??? int (*read_header)(struct AVFormatContext *, AVFormatParameters *ap);

??? int (*read_packet)(struct AVFormatContext *, AVPacket *pkt);

??? int (*read_close)(struct AVFormatContext *);

??? int (*read_seek)(struct AVFormatContext *, int stream_index, int64_t timestamp, int flags);

???

muxer 開放的接口有：

??? int (*write_header)(struct AVFormatContext *);

??? int (*write_packet)(struct AVFormatContext *, AVPacket *pkt);

??? int (*write_trailer)(struct AVFormatContext *);

?

encoder/decoder 的接口是一樣的，只不過二者分別只實現(xiàn) encoder 和 decoder 函數(shù)：

??? int (*init)(AVCodecContext *);

??? int (*encode)(AVCodecContext *, uint8_t *buf, int buf_size, void *data);

??? int (*close)(AVCodecContext *);

??? int (*decode)(AVCodecContext *, void *outdata, int *outdata_size, uint8_t *buf, int buf_size);

?

仍以 flv 文件為例來說明 muxer/demuxer 的初始化。

在 libavformat\allformats.c 文件的 av_register_all(void) 函數(shù)中，通過執(zhí)行

REGISTER_MUXDEMUX(FLV, flv);

將支持 flv 格式的 flv_muxer 與 flv_demuxer 變量分別注冊到全局變量 first_oformat 與 first_iformat 鏈表的最后位置。

其中 flv_muxer 在 libavformat\flvenc.c 中定義如下：

AVOutputFormat flv_muxer = {

??? "flv",

??? "flv format",

??? "video/x-flv",

??? "flv",

??? sizeof(FLVContext),

#ifdef CONFIG_LIBMP3LAME

??? CODEC_ID_MP3,

#else // CONFIG_LIBMP3LAME

??? CODEC_ID_NONE,

??? CODEC_ID_FLV1,

??? flv_write_header,

??? flv_write_packet,

??? flv_write_trailer,

??? .codec_tag= (const AVCodecTag*[]){flv_video_codec_ids, flv_audio_codec_ids, 0},

}

AVOutputFormat 結(jié)構(gòu)的定義如下：

typedef struct AVOutputFormat {

??? const char *name;

??? const char *long_name;

??? const char *mime_type;

??? const char *extensions;

???

??? int priv_data_size;

???

??? enum CodecID audio_codec;

??? enum CodecID video_codec;

??? int (*write_header)(struct AVFormatContext *);

??? int (*write_packet)(struct AVFormatContext *, AVPacket *pkt);

??? int (*write_trailer)(struct AVFormatContext *);

???

??? int flags;

???

??? int (*set_parameters)(struct AVFormatContext *, AVFormatParameters *);

??? int (*interleave_packet)(struct AVFormatContext *, AVPacket *out, AVPacket *in, int flush);

?

???

??? const struct AVCodecTag **codec_tag;

???

??? struct AVOutputFormat *next;

} AVOutputFormat;

由 AVOutputFormat 結(jié)構(gòu)的定義可知， flv_muxer 變量初始化的第一、二個成員分別為該 muxer

的名稱與長名稱，第三、第四個成員為所對應(yīng) MIMIE Type 和后綴名，第五個成員是所對應(yīng)的

私有結(jié)構(gòu)的大小，第六、第七個成員為所對應(yīng)的音頻編碼和視頻編碼類型 ID ，接下來就是三

個重要的接口函數(shù)，該 muxer 的功能也就是通過調(diào)用這三個接口實現(xiàn)的。

?

flv_demuxer 在 libavformat\flvdec.c 中定義如下 , 與 flv_muxer 類似，在這兒主要也是設(shè)置

了 5 個接口函數(shù)，其中 flv_probe 接口用途是測試傳入的數(shù)據(jù)段是否是符合當(dāng)前文件格式，這

個接口在匹配當(dāng)前 demuxer 時會用到。

AVInputFormat flv_demuxer = {

??? "flv",

??? "flv format",

??? 0,

??? flv_probe,

??? flv_read_header,

??? flv_read_packet,

??? flv_read_close,

??? flv_read_seek,

??? .extensions = "flv",

??? .value = CODEC_ID_FLV1,

};

?

在上述 av_register_all(void) 函數(shù)中通過執(zhí)行 libavcodec\allcodecs.c 文件里的

avcodec_register_all(void) 函數(shù)來初始化全部的 encoder/decoder 。

?

因為不是每種編碼方式都支持 encode 和 decode ，所以有以下三種注冊方式：

#define REGISTER_ENCODER(X,x) \

??? if(ENABLE_##X##_ENCODER) register_avcodec(&x##_encoder)

#define REGISTER_DECODER(X,x) \

??? if(ENABLE_##X##_DECODER) register_avcodec(&x##_decoder)

#define REGISTER_ENCDEC(X,x) REGISTER_ENCODER(X,x); REGISTER_DECODER(X,x)

?

如支持 flv 的 flv_encoder 和 flv_decoder 變量就分別是在 libavcodec\mpegvideo.c 和 libavcodec\h263de.c 中創(chuàng)建的。

3. 當(dāng)前 muxer/demuxer 的匹配

在 FFmpeg 的文件轉(zhuǎn)換過程中，首先要做的就是根據(jù)傳入文件和傳出文件的后綴名 [FIXME] 匹配

合適的 demuxer 和 muxer 。匹配上的 demuxer 和 muxer 都保存在如下所示，定義在 ffmpeg.c 里的

全局變量 file_iformat 和 file_oformat 中：

? ? static AVInputFormat *file_iformat;

? ? static AVOutputFormat *file_oformat;

3.1 demuxer 匹配

在 libavformat\utils.c 中的 static AVInputFormat *av_probe_input_format2(

AVProbeData *pd, int is_opened, int *score_max) 函數(shù)用途是根據(jù)傳入的 probe data 數(shù)據(jù)

，依次調(diào)用每個 demuxer 的 read_probe 接口，來進(jìn)行該 demuxer 是否和傳入的文件內(nèi)容匹配的

判斷。其調(diào)用順序如下：

void parse_options(int argc, char **argv, const OptionDef *options,

void (* parse_arg_function)(const char *));

static void opt_input_file(const char *filename)

int av_open_input_file(…… )

AVInputFormat *av_probe_input_format(AVProbeData *pd,

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? int is_opened)

static AVInputFormat *av_probe_input_format2(……)

opt_input_file 函數(shù)是在保存在 const OptionDef options[] 數(shù)組中，用于

void parse_options(int argc, char **argv, const OptionDef *options) 中解析 argv 里的

“-i” 參數(shù)，也就是輸入文件名時調(diào)用的。

3.2 muxer 匹配

與 demuxer 的匹配不同， muxer 的匹配是調(diào)用 guess_format 函數(shù)，根據(jù) main() 函數(shù)的 argv 里的

輸出文件后綴名來進(jìn)行的。

void parse_options(int argc, char **argv, const OptionDef *options,

? ? ? ? ? void (* parse_arg_function)(const char *));

void parse_arg_file(const char *filename)

static void opt_output_file(const char *filename)

AVOutputFormat *guess_format(const char *short_name,

? ? ? ? ? ? ? ? ? ? ? ? ? ? const char *filename,

? ? ? ? ? ? ? ? ? ? ? ? ? ? const char *mime_type)

3.3 當(dāng)前 encoder/decoder 的匹配

在 main() 函數(shù)中除了解析傳入?yún)?shù)并初始化 demuxer 與 muxer 的 parse_options( ) 函數(shù)以外，

其他的功能都是在 av_encode( ) 函數(shù)里完成的。

在 libavcodec\utils.c 中有如下二個函數(shù) :

? ? AVCodec *avcodec_find_encoder(enum CodecID id)

? ? AVCodec *avcodec_find_decoder(enum CodecID id)

他們的功能就是根據(jù)傳入的 CodecID ，找到匹配的 encoder 和 decoder 。

在 av_encode( ) 函數(shù)的開頭，首先初始化各個 AVInputStream 和 AVOutputStream ，然后分別調(diào)

用上述二個函數(shù)，并將匹配上的 encoder 與 decoder 分別保存在 :

AVInputStream->AVStream *st->AVCodecContext *codec->struct AVCodec *codec 與

AVOutputStream->AVStream *st->AVCodecContext *codec->struct AVCodec *codec 變量。

4. 其他主要數(shù)據(jù)結(jié)構(gòu)

4.1 AVFormatContext

AVFormatContext 是 FFMpeg 格式轉(zhuǎn)換過程中實現(xiàn)輸入和輸出功能、保存相關(guān)數(shù)據(jù)的主要結(jié)構(gòu)。

每一個輸入和輸出文件，都在如下定義的指針數(shù)組全局變量中有對應(yīng)的實體。

? ? static AVFormatContext *output_files[MAX_FILES];

? ? static AVFormatContext *input_files[MAX_FILES];

對于輸入和輸出，因為共用的是同一個結(jié)構(gòu)體，所以需要分別對該結(jié)構(gòu)中如下定義的 iformat

或 oformat 成員賦值。

? ? struct AVInputFormat *iformat;

? ? struct AVOutputFormat *oformat;

對一個 AVFormatContext 來說，這二個成員不能同時有值，即一個 AVFormatContext 不能同時

含有 demuxer 和 muxer 。在 main( ) 函數(shù)開頭的 parse_options( ) 函數(shù)中找到了匹配的 muxer 和

demuxer 之后，根據(jù)傳入的 argv 參數(shù)，初始化每個輸入和輸出的 AVFormatContext 結(jié)構(gòu)，并保

存在相應(yīng)的 output_files 和 input_files 指針數(shù)組中。在 av_encode( ) 函數(shù)中， output_files

和 input_files 是作為函數(shù)參數(shù)傳入后，在其他地方就沒有用到了。

4.2 AVCodecContext

保存 AVCodec 指針和與 codec 相關(guān)數(shù)據(jù)，如 video 的 width 、 height ， audio 的 sample rate 等。

AVCodecContext 中的 codec_type ， codec_id 二個變量對于 encoder/decoder 的匹配來說，最為

重要。

? ? enum CodecType codec_type;? ?

? ? enum CodecID codec_id;? ? ? ?

如上所示， codec_type 保存的是 CODEC_TYPE_VIDEO ， CODEC_TYPE_AUDIO 等媒體類型，

codec_id 保存的是 CODEC_ID_FLV1 ， CODEC_ID_VP6F 等編碼方式。

以支持 flv 格式為例，在前述的 av_open_input_file(…… ) 函數(shù)中，匹配到正確的

AVInputFormat demuxer 后，通過 av_open_input_stream( ) 函數(shù)中調(diào)用 AVInputFormat 的

read_header 接口來執(zhí)行 flvdec.c 中的 flv_read_header( ) 函數(shù)。在 flv_read_header( ) 函數(shù)

內(nèi)，根據(jù)文件頭中的數(shù)據(jù)，創(chuàng)建相應(yīng)的視頻或音頻 AVStream ，并設(shè)置 AVStream 中

AVCodecContext 的正確的 codec_type 值。 codec_id 值是在解碼過程中 flv_read_packet( ) 函

數(shù)執(zhí)行時根據(jù)每一個 packet 頭中的數(shù)據(jù)來設(shè)置的。

4.3 AVStream

AVStream 結(jié)構(gòu)保存與數(shù)據(jù)流相關(guān)的編解碼器，數(shù)據(jù)段等信息。比較重要的有如下二個成員：

? ? AVCodecContext *codec;

? ? void *priv_data;

其中 codec 指針保存的就是上節(jié)所述的 encoder 或 decoder 結(jié)構(gòu)。 priv_data 指針保存的是和具

體編解碼流相關(guān)的數(shù)據(jù)，如下代碼所示，在 ASF 的解碼過程中， priv_data 保存的就是

ASFStream 結(jié)構(gòu)的數(shù)據(jù)。

? ? AVStream *st;

? ? ASFStream *asf_st;?

? ? … …

? ? st->priv_data = asf_st;

4.4 AVInputStream/ AVOutputStream

根據(jù)輸入和輸出流的不同，前述的 AVStream 結(jié)構(gòu)都是封裝在 AVInputStream 和 AVOutputStream

結(jié)構(gòu)中，在 av_encode( ) 函數(shù)中使用。 AVInputStream 中還保存的有與時間有關(guān)的信息。

AVOutputStream 中還保存有與音視頻同步等相關(guān)的信息。

4.5 AVPacket

AVPacket 結(jié)構(gòu)定義如下，其是用于保存讀取的 packet 數(shù)據(jù)。

typedef struct AVPacket {

? ? int64_t pts;? ? ? ? ? ? ///< presentation time stamp in time_base units

? ? int64_t dts;? ? ? ? ? ? ///< decompression time stamp in time_base units

? ? uint8_t *data;

? ? int? size;

? ? int? stream_index;

? ? int? flags;

? ? int? duration;? ? ? ? ///< presentation duration in time_base units (0 if not available)

? ? void (*destruct)(struct AVPacket *);

? ? void *priv;

? ? int64_t pos;? ? ? ? ? ///< byte position in stream, -1 if unknown

} AVPacket;

在 av_encode() 函數(shù)中，調(diào)用 AVInputFormat 的

(*read_packet)(struct AVFormatContext *, AVPacket *pkt) 接口，讀取輸入文件的一幀數(shù)

據(jù)保存在當(dāng)前輸入 AVFormatContext 的 AVPacket 成員中。

---------------------------------------------------------------------

FFMPEG 是目前被應(yīng)用最廣泛的編解碼軟件庫，支持多種流行的編解碼器，它是 C 語言實現(xiàn)的，不僅被集成到各種 PC 軟件，也經(jīng)常被移植到多種嵌入式設(shè)備中。使用面向?qū)ο蟮霓k法來設(shè)想這樣一個編解碼庫，首先讓人想到的是構(gòu)造各種編解碼器的類，然后對于它們的抽象基類確定運(yùn)行數(shù)據(jù)流的規(guī)則，根據(jù)算法轉(zhuǎn)換輸入輸出對象。

在實際的代碼，將這些編解碼器分成 encoder/decoder ， muxer/demuxer 和 device 三種對象，分別對應(yīng)于編解碼，輸入輸 出格式和設(shè)備。在 main 函數(shù)的開始，就是初始化這三類對象。在 avcodec_register_all 中，很多編解碼器被注冊，包括視頻的 H.264 解碼器和 X264 編碼器等，

REGISTER_DECODER (H264, h264);

REGISTER_ENCODER (LIBX264, libx264);

找到相關(guān)的宏代碼如下

#define REGISTER_ENCODER(X,x) { \

????????? extern AVCodec x##_encoder; \

????????? if(CONFIG_##X##_ENCODER)? avcodec_register(&x##_encoder); }

#define REGISTER_DECODER(X,x) { \

????????? extern AVCodec x##_decoder; \

????????? if(CONFIG_##X##_DECODER)? avcodec_register(&x##_decoder); }

這樣就實際在代碼中根據(jù) CONFIG_##X##_ENCODER 這樣的編譯選項來注冊 libx264_encoder 和 h264_decoder ，注冊的過程發(fā)生在 avcodec_register(AVCodec *codec) 函數(shù)中，實際上就是向全局鏈表 first_avcodec 中加入 libx264_encoder 、 h264_decoder 特定的編解碼 器，輸入?yún)?shù) AVCodec 是一個結(jié)構(gòu)體，可以理解為編解碼器的基類，其中不僅包含了名稱， id 等屬性，而且包含了如下函數(shù)指針，讓每個具體的編解碼器擴(kuò)展類實現(xiàn)。

??? int (*init)(AVCodecContext *);

??? int (*encode)(AVCodecContext *, uint8_t *buf, int buf_size, void *data);

??? int (*close)(AVCodecContext *);

??? int (*decode)(AVCodecContext *, void *outdata, int *outdata_size,

????????????????? const uint8_t *buf, int buf_size);

?? ?void (*flush)(AVCodecContext *);

繼續(xù)追蹤 libx264 ，也就是 X264 的靜態(tài)編碼庫，它在 FFMPEG 編譯的時候被引入作為 H.264 編碼器。在 libx264.c 中有如下代碼

AVCodec libx264_encoder = {

??? .name = "libx264",

??? .type = CODEC_TYPE_VIDEO,

??? .id = CODEC_ID_H264,

??? .priv_data_size = sizeof(X264Context),

??? .init = X264_init,

??? .encode = X264_frame,

??? .close = X264_close,

??? .capabilities = CODEC_CAP_DELAY,

??? .pix_fmts = (enum PixelFormat[]) { PIX_FMT_YUV420P, PIX_FMT_NONE },

??? .long_name = NULL_IF_CONFIG_SMALL("libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10"),

};

這里具體對來自 AVCodec 得屬性和方法賦值。其中

??? .init = X264_init,

??? .encode = X264_frame,

??? .close = X264_close,

將函數(shù)指針指向了具體函數(shù)，這三個函數(shù)將使用 libx264 靜態(tài)庫中提供的 API ，也就是 X264 的主要接口函數(shù)進(jìn)行具體實現(xiàn)。 pix_fmts 定義了所支持的輸入格式，這里 4 ： 2 ： 0

PIX_FMT_YUV420P,?? ///< planar YUV 4:2:0, 12bpp, (1 Cr & Cb sample per 2x2 Y samples)

上面看到的 X264Context 封裝了 X264 所需要的上下文管理數(shù)據(jù)，

typedef struct X264Context {

??? x264_param_t params;

??? x264_t *enc;

??? x264_picture_t pic;

??? AVFrame out_pic;

} X264Context;

它 屬于結(jié)構(gòu)體 AVCodecContext 的 void *priv_data 變量，定義了每種編解碼器私有的上下文屬性， AVCodecContext 也類似上下文基類一樣，還提供其他表示屏幕解析率、量化范圍等的上下文屬性和 rtp_callback 等函數(shù)指針供編解碼使用。

回到 main 函數(shù)，可以看到完成了各類編解碼器，輸入輸出格式和設(shè)備注冊以后，將進(jìn)行上下文初始化和編解碼參數(shù)讀入，然后調(diào)用 av_encode （）函數(shù)進(jìn)行具體的編解碼工作。根據(jù)該函數(shù)的注釋一路查看其過程：

1. 輸入輸出流初始化。

2. 根據(jù)輸入輸出流確定需要的編解碼器，并初始化。

3. 寫輸出文件的各部分

重點關(guān)注一下 step2 和 3 ，看看怎么利用前面分析的編解碼器基類來實現(xiàn)多態(tài)。大概查看一下這段代碼的關(guān)系，發(fā)現(xiàn)在 FFMPEG 里，可以用類圖來表示大概的編解碼器組合。

可以參考【 3 】來了解這些結(jié)構(gòu)的含義（見附錄）。在這里會調(diào)用一系列來自 utils.c 的函數(shù)，這里的 avcodec_open （）函數(shù)，在打開編解碼器都會調(diào)用到，它將運(yùn)行如下代碼：

??? avctx->codec = codec;

??? avctx->codec_id = codec->id;

??? avctx->frame_number = 0;

??? if(avctx->codec->init){

??????? ret = avctx->codec->init(avctx);

進(jìn)行具體適配的編解碼器初始化，而這里的 avctx->codec->init(avctx) 就是調(diào)用 AVCodec 中函數(shù)指針定義的具體初始化函數(shù)，例如 X264_init 。

在 avcodec_encode_video （）和 avcodec_encode_audio （）被 output_packet （）調(diào)用進(jìn)行音視頻編碼，將 同樣利用函數(shù)指針 avctx->codec->encode （）調(diào)用適配編碼器的編碼函數(shù)，如 X264_frame 進(jìn)行具體工作。

從上面的分析，我們可以看到 FFMPEG 怎么利用面向?qū)ο髞沓橄缶幗獯a器行為，通過組合和繼承關(guān)系具體化每個編解碼器實體。設(shè)想要在 FFMPEG 中加入新的解碼器 H265 ，要做的事情如下：

1. 在 config 編譯配置中加入 CONFIG_H265_DECODER

2. 利用宏注冊 H265 解碼器

3. 定義 AVCodec 265_decoder 變量，初始化屬性和函數(shù)指針

4. 利用解碼器 API 具體化 265_decoder 的 init 等函數(shù)指針

完成以上步驟，就可以把新的解碼器放入 FFMPEG ，外部的匹配和運(yùn)行規(guī)則由基類的多態(tài)實現(xiàn)了。

4. X264 架構(gòu)分析

X264 是一款從 2004 年有法國大學(xué)生發(fā)起的開源 H.264 編碼器，對 PC 進(jìn)行匯編級代碼優(yōu)化，舍棄了片組和多參考幀等性能效率比不高的功能來提高編碼效率，它被 FFMPEG 作為引入的 .264 編碼庫，也被移植到很多 DSP 嵌入平臺。前面第三節(jié)已經(jīng)對 FFMPEG 中的 X264 進(jìn)行舉例分析，這里將繼續(xù)結(jié)合 X264 框架加深相關(guān)內(nèi)容的了解。

查看代碼前，還是思考一下對于一款具體的編碼器，怎么面向?qū)ο蠓治瞿兀繉鼐幋a部分對不同算法的抽象，還有幀內(nèi)或幀間編碼各種估計算法的抽象，都可以作為類來構(gòu)建。

在 X264 中，我們看到的對外 API 和上下文變量都聲明在 X264.h 中， API 函數(shù)中，關(guān)于輔助功能的函數(shù)在 common.c 中定義

void x264_picture_alloc( x264_picture_t *pic, int i_csp, int i_width, int i_height );

void x264_picture_clean( x264_picture_t *pic );

int x264_nal_encode( void *, int *, int b_annexeb, x264_nal_t *nal );

而編碼功能函數(shù)定義在 encoder.c

x264_t *x264_encoder_open?? ( x264_param_t * );

int???? x264_encoder_reconfig( x264_t *, x264_param_t * );

int???? x264_encoder_headers( x264_t *, x264_nal_t **, int * );

int???? x264_encoder_encode ( x264_t *, x264_nal_t **, int *, x264_picture_t *, x264_picture_t * );

void??? x264_encoder_close? ( x264_t * );

在 x264.c 文件中，有程序的 main 函數(shù)，可以看作做 API 使用的例子，它也是通過調(diào)用 X264.h 中的 API 和上下文變量來實現(xiàn)實際功能。

X264 最重要的記錄上下文數(shù)據(jù)的結(jié)構(gòu)體 x264_t 定義在 common.h 中，它包含了從線程控制變量到具體的 SPS 、 PPS 、量化矩陣、 cabac 上下文等所有的 H.264 編碼相關(guān)變量。其中包含如下的結(jié)構(gòu)體

??? x264_predict_t????? predict_16x16[4+3];

??? x264_predict_t????? predict_8x8c[4+3];

??? x264_predict8x8_t?? predict_8x8[9+3];

??? x264_predict_t????? predict_4x4[9+3];

??? x264_predict_8x8_filter_t predict_8x8_filter;

??? x264_pixel_function_t pixf;

??? x264_mc_functions_t?? mc;

??? x264_dct_function_t?? dctf;

??? x264_zigzag_function_t zigzagf;

??? x264_quant_function_t quantf;

??? x264_deblock_function_t loopf;

跟蹤查看可以看到它們或是一個函數(shù)指針，或是由函數(shù)指針組成的結(jié)構(gòu)，這樣的用法很想面向?qū)ο笾械? interface 接口聲明。這些函數(shù)指針將在 x264_encoder_open （）函數(shù)中被初始化，這里的初始化首先根據(jù) CPU 的不同提供不同的函數(shù)實現(xiàn)代碼段，很多與可能是匯編實現(xiàn)，以提高代碼運(yùn)行效率。其次把功能相似的函數(shù)集中管理，例如類似 intra16 的 4 種和 intra4 的九種預(yù)測函數(shù)都被用函數(shù)指針數(shù)組管理起來。

x264_encoder_encode （）是負(fù)責(zé)編碼的主要函數(shù)，而其內(nèi)包含的 x264_slice_write （）負(fù)責(zé)片層一下的具體編碼，包括了幀內(nèi)和幀間宏塊編碼。在這里， cabac 和 cavlc 的行為是根據(jù) h->param.b_cabac 來區(qū)別的，分別運(yùn)行 x264_macroblock_write_cabac （）和 x264_macroblock_write_cavlc （）來寫碼流，在這一部分，功能函數(shù)按文件定義歸類，基本按照編碼流程圖運(yùn)行，看起來更像面向過程的寫法，在已經(jīng)初始化了具體的函數(shù)指針，程序就一直按編碼過程的邏輯實現(xiàn)。如果從整體架構(gòu)來看， x264 利用這種類似接口的形式實現(xiàn)了弱耦合和可重用， 利用 x264_t 這個貫穿始終的上下文，實現(xiàn)信息封裝和多態(tài)。

本文大概分析了 FFMPEG/X264 的代碼架構(gòu)，重點探討用 C 語言來實現(xiàn)面向?qū)ο缶幋a，雖不至于強(qiáng)行向 C++ 靠攏，但是也各有實現(xiàn)特色，保證實用性。值得規(guī)劃 C 語言軟件項目所借鑒。 ?

?

【參考文獻(xiàn)】

1.“ 用例子說明面向?qū)ο蠛兔嫦蜻^程的區(qū)別 ”

2.?liyuming1978 ， “ liyuming1978 的專欄 ”

3. “FFMpeg 框架代碼閱讀 ”

?

Using libavformat and libavcodec

Martin B?hme (boehme@inb.uni-luebeckREMOVETHIS.de)

February 18, 2004

Update (January 23 2009): By now, these articles are quite out of date... unfortunately, I haven't found the time to update them, but thankfully, others have jumped in. Stephen Dranger has a more recent tutorial , ryanfb of cryptosystem.org has an updated version of the code, and David Hoerl has a more recent update .

Update (July 22 2004): I discovered that the code I originally presented contained a memory leak (av_free_packet() wasn't being called). My apologies - I've updated the demo program and the code in the article to eliminate the leak.

Update (July 21 2004): There's a new prerelease of ffmpeg (0.4.9-pre1). I describe the changes to the libavformat / libavcodec API in this article .

The libavformat and libavcodec libraries that come with ffmpeg are a great way of accessing a large variety of video file formats. Unfortunately, there is no real documentation on using these libraries in your own programs (at least I couldn't find any), and the example programs aren't really very helpful either.

This situation meant that, when I used libavformat/libavcodec on a recent project, it took quite a lot of experimentation to find out how to use them. Here's what I learned - hopefully I'll be able to save others from having to go through the same trial-and-error process. There's also a small demo program that you can download. The code I'll present works with libavformat/libavcodec as included in version 0.4.8 of ffmpeg (the most recent version as I'm writing this). If you find that later versions break the code, please let me know.

In this document, I'll only cover how to read video streams from a file; audio streams work pretty much the same way, but I haven't actually used them, so I can't present any example code.

In case you're wondering why there are two libraries, libavformat and libavcodec: Many video file formats (AVI being a prime example) don't actually specify which codec(s) should be used to encode audio and video data; they merely define how an audio and a video stream (or, potentially, several audio/video streams) should be combined into a single file. This is why sometimes, when you open an AVI file, you get only sound, but no picture - because the right video codec isn't installed on your system. Thus, libavformat deals with parsing video files and separating the streams contained in them, and libavcodec deals with decoding raw audio and video streams.

Opening a Video File

First things first - let's look at how to open a video file and get at the streams contained in it. The first thing we need to do is to initialize libavformat/libavcodec:

av_register_all();

This registers all available file formats and codecs with the library so they will be used automatically when a file with the corresponding format/codec is opened. Note that you only need to call av_register_all() once, so it's probably best to do this somewhere in your startup code. If you like, it's possible to register only certain individual file formats and codecs, but there's usually no reason why you would have to do that.

Next off, opening the file:

AVFormatContext *pFormatCtx;

const char ????? *filename="myvideo.mpg";

// Open video file

if(av_open_input_file(&pFormatCtx, filename, NULL, 0, NULL)!=0)

??? handle_error(); // Couldn't open file

The last three parameters specify the file format, buffer size and format parameters; by simply specifying NULL or 0 we ask libavformat to auto-detect the format and use a default buffer size. Replace handle_error() with appropriate error handling code for your application.

Next, we need to retrieve information about the streams contained in the file:

// Retrieve stream information

if(av_find_stream_info(pFormatCtx)<0)

??? handle_error(); // Couldn't find stream information

This fills the streams field of the AVFormatContext with valid information. As a debugging aid, we'll dump this information onto standard error, but of course you don't have to do this in a production application:

dump_format(pFormatCtx, 0, filename, false);

As mentioned in the introduction, we'll handle only video streams, not audio streams. To make things nice and easy, we simply use the first video stream we find:

int ??????????? i, videoStream;

AVCodecContext *pCodecCtx;

// Find the first video stream

videoStream=-1;

for(i=0; i<pFormatCtx->nb_streams; i++)

??? if(pFormatCtx->streams[i]->codec.codec_type==CODEC_TYPE_VIDEO)

??? {

??????? videoStream=i;

??????? break;

??? }

if(videoStream==-1)

??? handle_error(); // Didn't find a video stream

// Get a pointer to the codec context for the video stream

pCodecCtx=&pFormatCtx->streams[videoStream]->codec;

OK, so now we've got a pointer to the so-called codec context for our video stream, but we still have to find the actual codec and open it:

AVCodec *pCodec;

// Find the decoder for the video stream

pCodec=avcodec_find_decoder(pCodecCtx->codec_id);

if(pCodec==NULL)

??? handle_error(); // Codec not found

// Inform the codec that we can handle truncated bitstreams -- i.e.,

// bitstreams where frame boundaries can fall in the middle of packets

if(pCodec->capabilities & CODEC_CAP_TRUNCATED)

??? pCodecCtx->flags|=CODEC_FLAG_TRUNCATED;

// Open codec

if(avcodec_open(pCodecCtx, pCodec)<0)

??? handle_error(); // Could not open codec

(So what's up with those "truncated bitstreams"? Well, as we'll see in a moment, the data in a video stream is split up into packets. Since the amount of data per video frame can vary, the boundary between two video frames need not coincide with a packet boundary. Here, we're telling the codec that we can handle this situation.)

One important piece of information that is stored in the AVCodecContext structure is the frame rate of the video. To allow for non-integer frame rates (like NTSC's 29.97 fps), the rate is stored as a fraction, with the numerator in pCodecCtx->frame_rate and the denominator in pCodecCtx->frame_rate_base. While testing the library with different video files, I noticed that some codecs (notably ASF) seem to fill these fields incorrectly (frame_rate_base contains 1 instead of 1000). The following hack fixes this:

// Hack to correct wrong frame rates that seem to be generated by some

// codecs

if(pCodecCtx->frame_rate>1000 && pCodecCtx->frame_rate_base==1)

??? pCodecCtx->frame_rate_base=1000;

Note that it shouldn't be a problem to leave this fix in place even if the bug is corrected some day - it's unlikely that a video would have a frame rate of more than 1000 fps.

One more thing left to do: Allocate a video frame to store the decoded images in:

AVFrame *pFrame;

pFrame=avcodec_alloc_frame();

That's it! Now let's start decoding some video.

Decoding Video Frames

As I've already mentioned, a video file can contain several audio and video streams, and each of those streams is split up into packets of a particular size. Our job is to read these packets one by one using libavformat, filter out all those that aren't part of the video stream we're interested in, and hand them on to libavcodec for decoding. In doing this, we'll have to take care of the fact that the boundary between two frames can occur in the middle of a packet.

Sound complicated? Lucikly, we can encapsulate this whole process in a routine that simply returns the next video frame:

bool GetNextFrame(AVFormatContext *pFormatCtx, AVCodecContext *pCodecCtx,

??? int videoStream, AVFrame *pFrame)

{

??? static AVPacket packet;

??? static int ????? bytesRemaining=0;

??? static uint8_t ? *rawData;

??? static bool ???? fFirstTime=true;

??? int ???????????? bytesDecoded;

??? int ???????????? frameFinished;

??? // First time we're called, set packet.data to NULL to indicate it

??? // doesn't have to be freed

??? if(fFirstTime)

??? {

??????? fFirstTime=false;

??????? packet.data=NULL;

??? }

??? // Decode packets until we have decoded a complete frame

??? while(true)

??? {

??????? // Work on the current packet until we have decoded all of it

??????? while(bytesRemaining > 0)

??????? {

??????????? // Decode the next chunk of data

??????????? bytesDecoded=avcodec_decode_video(pCodecCtx, pFrame,

??????????????? &frameFinished, rawData, bytesRemaining);

??????????? // Was there an error?

??????????? if(bytesDecoded < 0)

??????????? {

??????????????? fprintf(stderr, "Error while decoding frame\n");

??????????????? return false;

??????????? }

??????????? bytesRemaining-=bytesDecoded;

??????????? rawData+=bytesDecoded;

??????????? // Did we finish the current frame? Then we can return

??????????? if(frameFinished)

??????????????? return true;

??????? }

??????? // Read the next packet, skipping all packets that aren't for this

??????? // stream

??????? do

??????? {

??????????? // Free old packet

??????????? if(packet.data!=NULL)

??????????????? av_free_packet(&packet);

??????????? // Read new packet

??????????? if(av_read_packet(pFormatCtx, &packet)<0)

??????????????? goto loop_exit;

??????? } while(packet.stream_index!=videoStream);

??????? bytesRemaining=packet.size;

??????? rawData=packet.data;

??? }

loop_exit:

??? // Decode the rest of the last frame

??? bytesDecoded=avcodec_decode_video(pCodecCtx, pFrame, &frameFinished,

??????? rawData, bytesRemaining);

??? // Free last packet

??? if(packet.data!=NULL)

??????? av_free_packet(&packet);

??? return frameFinished!=0;

}

Now, all we have to do is sit in a loop, calling GetNextFrame() until it returns false. Just one more thing to take care of: Most codecs return images in YUV 420 format (one luminance and two chrominance channels, with the chrominance channels samples at half the spatial resolution of the luminance channel). Depending on what you want to do with the video data, you may want to convert this to RGB. (Note, though, that this is not necessary if all you want to do is display the video data; take a look at the X11 Xvideo extension, which does YUV-to-RGB and scaling in hardware.) Fortunately, libavcodec provides a conversion routine called img_convert, which does conversion between YUV and RGB as well as a variety of other image formats. The loop that decodes the video thus becomes:

while(GetNextFrame(pFormatCtx, pCodecCtx, videoStream, pFrame))

{

??? img_convert((AVPicture *)pFrameRGB, PIX_FMT_RGB24, (AVPicture*)pFrame,

??????? pCodecCtx->pix_fmt, pCodecCtx->width, pCodecCtx->height);

??? // Process the video frame (save to disk etc.)

??? DoSomethingWithTheImage(pFrameRGB);

}

The RGB image pFrameRGB (of type AVFrame *) is allocated like this:

AVFrame *pFrameRGB;

int ???? numBytes;

uint8_t *buffer;

// Allocate an AVFrame structure

pFrameRGB=avcodec_alloc_frame();

if(pFrameRGB==NULL)

??? handle_error();

// Determine required buffer size and allocate buffer

numBytes=avpicture_get_size(PIX_FMT_RGB24, pCodecCtx->width,

??? pCodecCtx->height);

buffer=new uint8_t[numBytes];

// Assign appropriate parts of buffer to image planes in pFrameRGB

avpicture_fill((AVPicture *)pFrameRGB, buffer, PIX_FMT_RGB24,

??? pCodecCtx->width, pCodecCtx->height);

Cleaning up

OK, we've read and processed our video, now all that's left for us to do is clean up after ourselves:

// Free the RGB image

delete [] buffer;

av_free(pFrameRGB);

// Free the YUV frame

av_free(pFrame);

// Close the codec

avcodec_close(pCodecCtx);

// Close the video file

av_close_input_file(pFormatCtx);

Done!

Sample Code

A sample app that wraps all of this code up in compilable form is here . If you have any additional comments, please contact me at boehme@inb.uni-luebeckREMOVETHIS.de. Standard disclaimer: I assume no liability for the correct functioning of the code and techniques presented in this article.

?

?

?

?

?

二，解碼流程

FFMpeg的解碼流程

1. 從基礎(chǔ)談起
先給出幾個概念，以在后面的分析中方便理解
Container:在音視頻中的容器，一般指的是一種特定的文件格式，里面指明了所包含的
??? 音視頻，字幕等相關(guān)信息
Stream:這個詞有些微妙，很多地方都用到，比如TCP，SVR4系統(tǒng)等，其實在音視頻，你
??? 可以理解為單純的音頻數(shù)據(jù)或者視頻數(shù)據(jù)等
Frames:這個概念不是很好明確的表示，指的是Stream中的一個數(shù)據(jù)單元，要真正對這
??? 個概念有所理解，可能需要看一些音視頻編碼解碼的理論知識
Packet:是Stream的raw數(shù)據(jù)
Codec:Coded + Decoded
其實這些概念在在FFmpeg中都有很好的體現(xiàn)，我們在后續(xù)分析中會慢慢看到

2.解碼的基本流程
我很懶，于是還是選擇了從<An ffmpeg and SDL Tutorial>中的流程概述:

10 OPEN video_stream FROM video.avi
20 READ packet FROM video_stream INTO frame
30 IF frame NOT COMPLETE GOTO 20
40 DO SOMETHING WITH frame
50 GOTO 20

這就是解碼的全過程，一眼看去，是不是感覺不過如此:),不過，事情有深有淺，從淺
到深，然后從深回到淺可能才是一個有意思的過程，我們的故事，就從這里開始，展開
來講。

3.例子代碼
在<An ffmpeg and SDL Tutorial 1>中，給出了一個陽春版的解碼器，我們來仔細(xì)看看
陽春后面的故事，為了方便講述，我先貼出代碼：

#include <ffmpeg/avcodec.h>
#include <ffmpeg/avformat.h>

#include <stdio.h>

void SaveFrame(AVFrame *pFrame, int width, int height, int iFrame) {
FILE *pFile;
char szFilename[32];
int y;

// Open file
sprintf(szFilename, "frame%d.ppm", iFrame);
pFile=fopen(szFilename, "wb");
if(pFile==NULL)
??? return;

// Write header
fprintf(pFile, "P6\n%d %d\n255\n", width, height);

// Write pixel data
for(y=0; y<height; y++)
??? fwrite(pFrame->data[0]+y*pFrame->linesize[0], 1, width*3, pFile);

// Close file
fclose(pFile);
}

int main(int argc, char *argv[]) {
AVFormatContext *pFormatCtx;
int???????????? i, videoStream;
AVCodecContext *pCodecCtx;
AVCodec???????? *pCodec;
AVFrame???????? *pFrame;?
AVFrame???????? *pFrameRGB;
AVPacket??????? packet;
int???????????? frameFinished;
int???????????? numBytes;
uint8_t???????? *buffer;

if(argc < 2) {
??? printf("Please provide a movie file\n");
??? return -1;
}
// Register all formats and codecs
########################################
[1]
########################################
av_register_all();

// Open video file
########################################
[2]
########################################
if(av_open_input_file(&pFormatCtx, argv[1], NULL, 0, NULL)!=0)
??? return -1; // Couldn't open file

// Retrieve stream information
########################################
[3]
########################################
if(av_find_stream_info(pFormatCtx)<0)
??? return -1; // Couldn't find stream information

// Dump information about file onto standard error
dump_format(pFormatCtx, 0, argv[1], 0);

// Find the first video stream
videoStream=-1;
for(i=0; i<pFormatCtx->nb_streams; i++)
??? if(pFormatCtx->streams[i]->codec->codec_type==CODEC_TYPE_VIDEO) {
????? videoStream=i;
????? break;
??? }
if(videoStream==-1)
??? return -1; // Didn't find a video stream

// Get a pointer to the codec context for the video stream
pCodecCtx=pFormatCtx->streams[videoStream]->codec;

// Find the decoder for the video stream
pCodec=avcodec_find_decoder(pCodecCtx->codec_id);
if(pCodec==NULL) {
??? fprintf(stderr, "Unsupported codec!\n");
??? return -1; // Codec not found
}
// Open codec
if(avcodec_open(pCodecCtx, pCodec)<0)
??? return -1; // Could not open codec

// Allocate video frame
pFrame=avcodec_alloc_frame();

// Allocate an AVFrame structure
pFrameRGB=avcodec_alloc_frame();
if(pFrameRGB==NULL)
??? return -1;
????
// Determine required buffer size and allocate buffer
numBytes=avpicture_get_size(PIX_FMT_RGB24, pCodecCtx->width,
????????????????? pCodecCtx->height);
buffer=(uint8_t *)av_malloc(numBytes*sizeof(uint8_t));

// Assign appropriate parts of buffer to image planes in pFrameRGB
// Note that pFrameRGB is an AVFrame, but AVFrame is a superset
// of AVPicture
avpicture_fill((AVPicture *)pFrameRGB, buffer, PIX_FMT_RGB24,
???????? pCodecCtx->width, pCodecCtx->height);

// Read frames and save first five frames to disk
########################################
[4]
########################################
i=0;
while(av_read_frame(pFormatCtx, &packet)>=0) {
??? // Is this a packet from the video stream?
??? if(packet.stream_index==videoStream) {
????? // Decode video frame
????? avcodec_decode_video(pCodecCtx, pFrame, &frameFinished,?
?????????????? packet.data, packet.size);
??????
????? // Did we get a video frame?
????? if(frameFinished) {
??? // Convert the image from its native format to RGB
??? img_convert((AVPicture *)pFrameRGB, PIX_FMT_RGB24,?
??????????????????? (AVPicture*)pFrame, pCodecCtx->pix_fmt,?
??????????????????? pCodecCtx->width,?
??????????????????? pCodecCtx->height);
????
??? // Save the frame to disk
??? if(++i<=5)
????? SaveFrame(pFrameRGB, pCodecCtx->width, pCodecCtx->height,?
??????????? i);
????? }
??? }
????
??? // Free the packet that was allocated by av_read_frame
??? av_free_packet(&packet);
}

// Free the RGB image
av_free(buffer);
av_free(pFrameRGB);

// Free the YUV frame
av_free(pFrame);

// Close the codec
avcodec_close(pCodecCtx);

// Close the video file
av_close_input_file(pFormatCtx);

return 0;
}

代碼注釋得很清楚，沒什么過多需要講解的，關(guān)于其中的什么YUV420，RGB，PPM等格式
，如果不理解，麻煩還是google一下，也可以參考:http://barrypopy.cublog.cn/里面
的相關(guān)文章

其實這部分代碼，很好了Demo了怎么樣去抓屏功能的實現(xiàn)，但我們得去看看魔術(shù)師在后
臺的一些手法，而不只是簡單的享受其表演。

4.背后的故事
真正的難度，其實就是上面的[1],[2],[3],[4],其他部分，都是數(shù)據(jù)結(jié)構(gòu)之間的轉(zhuǎn)換，
如果你認(rèn)真看代碼的話，不難理解其他部分。

[1]:沒什么太多好說的，如果不明白，看我轉(zhuǎn)載的關(guān)于FFmepg框架的文章

[2]:先說說里面的AVFormatContext *pFormatCtx結(jié)構(gòu)，字面意思理解AVFormatContext
就是關(guān)于AVFormat(其實就是我們上面說的Container格式)的所處的Context(場景)，自
然是保存Container信息的總控結(jié)構(gòu)了，后面你也可以看到，基本上所有的信息，都可
以從它出發(fā)而獲取到
????
我們來看看av_open_input_file()都做了些什么：
[libavformat/utils.c]
int av_open_input_file(AVFormatContext **ic_ptr, const char *filename,
?????????????????????? AVInputFormat *fmt,
?????????????????????? int buf_size,
?????????????????????? AVFormatParameters *ap)
{
??? ......
??? if (!fmt) {
???????
??????? fmt = av_probe_input_format(pd, 0);
??? }

?? ......
??? err = av_open_input_stream(ic_ptr, pb, filename, fmt, ap);
?? ......
}

這樣看來，只是做了兩件事情：
1). 偵測容器文件格式
2). 從容器文件獲取Stream的信息

這兩件事情，實際上就是調(diào)用特定文件的demuxer以分離Stream的過程:

具體流程如下:

av_open_input_file
??? |
??? +---->av_probe_input_format從first_iformat中遍歷注冊的所有demuxer以?
??? |???? 調(diào)用相應(yīng)的probe函數(shù)
??? |
??? +---->av_open_input_stream調(diào)用指定demuxer的read_header函數(shù)以獲取相關(guān)
????????? 流的信息ic->iformat->read_header

如果反過來再參考我轉(zhuǎn)貼的關(guān)于ffmpeg框架的文章，是否清楚一些了呢:)

[3]:簡單從AVFormatContext獲取Stream的信息，沒什么好多說的

[4]:先簡單說一些ffmpeg方面的東西，從理論角度說過來，Packet可以包含frame的部
分?jǐn)?shù)據(jù)，但ffmpeg為了實現(xiàn)上的方便，使得對于視頻來說，每個Packet至少包含一
frame,對于音頻也是相應(yīng)處理，這是實現(xiàn)方面的考慮，而非協(xié)議要求.
因此，在上面的代碼實際上是這樣的：
??? 從文件中讀取packet，從Packet中解碼相應(yīng)的frame;
??? 從幀中解碼;
??? if(解碼幀完成)
??????? do something();

我們來看看如何獲取Packet,又如何從Packet中解碼frame的。

av_read_frame
??? |
??? +---->av_read_frame_internal
??????? |
??????? +---->av_parser_parse調(diào)用的是指定解碼器的s->parser->parser_parse函數(shù)以從raw packet中重構(gòu)frame

avcodec_decode_video
??? |
??? +---->avctx->codec->decode調(diào)用指定Codec的解碼函數(shù)
????
因此，從上面的過程可以看到，實際上分為了兩部分：

一部分是解復(fù)用(demuxer),然后是解碼(decode)

使用的分別是：
av_open_input_file()??????????? ---->解復(fù)用

av_read_frame()??????????? |
?????????????????????????? |??? ---->解碼????
avcodec_decode_video()???? |

5.后面該做些什么
結(jié)合這部分和轉(zhuǎn)貼的ffmepg框架的文章，應(yīng)該可以基本打通解碼的流程了，后面的問題則是針對具體容器格式和具體編碼解碼器的分析

?

?

ffmpeg架構(gòu)和解碼流程分析