? ? ? URLProtocol,URLContext和ByteIOContext是FFMpeg操作文件(即I/O,包括網絡數據流)的結構,這幾個結構現實的功能類似于C++的多態繼承吧,C++的多態是通過子類繼承實現,而FFMpeg的“多態”是通過靜態對像現實。這部分的代碼非常值得C程序借鑒,我是說,如果你要在C里實現類似C++多態性的功能;比如當你要區分你老婆和情人之間的不同功能時。
? ? ?好了,先來看一下這三個struct的定義吧
typedef struct URLProtocol {
?
? ? const char *name; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? //Rotocol名稱
? ? int (*url_open)(URLContext *h, const char *url, int flags); ? ? ?//open函數指針對象,以下類似
? ? int (*url_read)(URLContext *h, unsigned char *buf, int size);?
? ? int (*url_write)(URLContext *h, unsigned char *buf, int size);
? ? int64_t (*url_seek)(URLContext *h, int64_t pos, int whence);
? ? int (*url_close)(URLContext *h);
? ? struct URLProtocol *next; ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?//指向下一個URLProtocol,具體說明見備注1
? ? int (*url_read_pause)(URLContext *h, int pause);
? ? int64_t (*url_read_seek)(URLContext *h, int stream_index,int64_t timestamp, int flags);
? ? int (*url_get_file_handle)(URLContext *h);
} URLProtocol;
?
備注1:FFMpeg所有的Protol類型都用這個變量串成一個鏈表,表頭為avio.c里的URLProtocol *first_protocol = NULL;
每個文件類似都有自己的一個URLProtocol靜態對象,如libavformat/file.c里
?
URLProtocol file_protocol = {
? ? "file",
? ? file_open,
? ? file_read,
? ? file_write,
? ? file_seek,
? ? file_close,
? ? .url_get_file_handle = file_get_handle,
};
再通過av_register_protocol()將他們鏈接成鏈表。在FFMpeg中所有的URLProtocol對像值都在編譯時確定。
?
?
typedef struct URLContext {
#if LIBAVFORMAT_VERSION_MAJOR >= 53
? ? const AVClass *av_class; ///< information for av_log(). Set by url_open().
#endif
? ? struct URLProtocol *prot; ? ? ? ? ?//指向具體的I/0類型,在運行時通過文件URL確定,如是file類型時就是file_protocol?? ? ? ? ?
? ? int flags;
? ? int is_streamed; ?/**< true if streamed (no seek possible), default = false */
? ? int max_packet_size; ?/**< if non zero, the stream is packetized with this max packet size */
? ? void *priv_data; ? ? ? ? ? ? ? ? ? ? ? //指向具體的I/O句柄
? ? char *filename; /**< specified URL */
} URLContext;
不同于URLProtocol對象值在編譯時確定,URLContext對象值是在運行過程中根據輸入的I/O類型動態確定的。這一動一靜組合起到了C++的多態繼承一樣的作用。URLContext像是基類,為大家共同所有,而URLProtocol像是子類部分。
?
typedef struct {
? ? unsigned char *buffer;
? ? int buffer_size;
? ? unsigned char *buf_ptr, *buf_end;
? ? void *opaque;
? ? int (*read_packet)(void *opaque, uint8_t *buf, int buf_size);
? ? int (*write_packet)(void *opaque, uint8_t *buf, int buf_size);
? ? int64_t (*seek)(void *opaque, int64_t offset, int whence);
? ? int64_t pos; /**< position in the file of the current buffer */
? ? int must_flush; /**< true if the next seek should flush */
? ? int eof_reached; /**< true if eof reached */
? ? int write_flag; ?/**< true if open for writing */
? ? int is_streamed;
? ? int max_packet_size;
? ? unsigned long checksum;
? ? unsigned char *checksum_ptr;
? ? unsigned long (*update_checksum)(unsigned long checksum, const uint8_t *buf, unsigned int size);
? ? int error; ? ? ? ? ///< contains the error code or 0 if no error happened
? ? int (*read_pause)(void *opaque, int pause);
? ? int64_t (*read_seek)(void *opaque, int stream_index,
? ? ? ? ? ? ? ? ? ? ? ? ?int64_t timestamp, int flags);
} ByteIOContext;
ByteIOContext是URLContext和URLProtocol?一個擴展,也是FFMpeg提供給用戶的接口,URLContext和URLProtocol對用戶是透明,我們所有的操作是通過ByteIOContext現實。這幾個struct的相關的關鍵函數有:
int av_open_input_file(AVFormatContext **ic_ptr, const char *filename,
? ? ? ? ? ? ? ? ? ? ? ?AVInputFormat *fmt,
? ? ? ? ? ? ? ? ? ? ? ?int buf_size,
? ? ? ? ? ? ? ? ? ? ? ?AVFormatParameters *ap)
{
? ??int url_fopen(ByteIOContext **s, const char *filename, int flags)
? ??{
? ?? ????url_open(URLContext **puc, const char *filename, int flags)
? ?? ????{
? ??? ??? ? ???URLProtocol *up;
? ? ?? ???? ? ?//根據filename確定up
? ? ?? ???? ? ?url_open_protocol (URLContext **puc, struct URLProtocol *up,?const char *filename, int flags)
? ? ??? ??? ? ?{
? ? ??? ??? ? ? ? ? //初始化URLContext對像,并通過 up->url_open()將I/O打開將I/O fd賦值給URLContext的priv_data對像
? ? ??? ??? ? ?}
? ??? ???}
? ??? ???url_fdopen(ByteIOContext **s, URLContext *h)
? ??? ???{
? ??? ??? ? ? ?//初始化ByteIOContext 對像
? ? ?? ??}
? ??}
}
我們先看一下音視頻播放器的大概結構(個人想法,不保證正確):1、數據源輸入(Input)->2、文件格式解析器(Demux)->3、音視頻解碼(Decoder)->4、顏色空間轉換(僅視頻)->5、渲染輸出(Render Output)。前一篇介紹的幾個struct是數據源輸入模塊里的內容,哪么這一帖所講的就是第二個模塊即文件格式解析器里用到的內容。? ? ??AVInputFormat、AVOutputFormat與URLProtocol類似,每一種文件類型都有一個AVInputFormat和AVOutputFormat靜態對像并通過av_register_input_format和av_register_output_format函數鏈成一個表,其表頭在utils.c:
?
/** head of registered input format linked list */
AVInputFormat *first_iformat = NULL;
/** head of registered output format linked list */
AVOutputFormat *first_oformat = NULL;
?
AVInputFormat和AVOutputFormat的定義分別在avformat.h,代碼很長,不貼出來浪費空間了。
當程序運行時,AVInputFormat對像的
?
int av_open_input_file(AVFormatContext **ic_ptr, const char *filename,
? ? ? ? ? ? ? ? ? ? ? ?AVInputFormat *fmt,
? ??? ? ? ? ? ? ? ? ? ?int buf_size,
? ? ? ? ? ? ? ? ? ? ???AVFormatParameters *ap)
{
?
? ???fmt = av_probe_input_format(pd, 0);//返回該文件的AVInputFormat類型
}
至于AVOutputFormat嘛,下次再說吧,晚安!
?? AVFormatContext在FFMpeg里是一個非常重要的的結構,是其它輸入、輸出相關信息的一個容器,需要注意的是其中兩個成員:void *priv_data;//
成員變量指向具體的Stream類型對像,如AVIStream。其
AVCodecContext *actx;//記錄具體的編解容器,這個下面會講
也在這讀頭文件信息里初始化。
主要相關的函數有
int av_open_input_file(AVFormatContext **ic_ptr, const char *filename,
? ? ? ? ? ? ? ? ? ? ? ?AVInputFormat *fmt,
? ? ? ? ? ? ? ? ? ? ? ?int buf_size,
? ? ? ? ? ? ? ? ? ? ? ?AVFormatParameters *ap)
{
?
? ??av_open_input_stream(AVFormatContext **ic_ptr,ByteIOContext *pb, const char *filename,AVInputFormat ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?*fmt, AVFormatParameters *ap)
? ??{
? ? ? ? ?fmt.read_header()//調用具體的AVInputFormat的read_header,如avi_read_header
? ?? ????{
? ? ? ? ? ? ? ?//根據文件頭信息初始化AVStream *streams及AVStream里的
? ? ? ? ? ? ? ?//void *priv_data和AVCodecContext *actx;成員對像
? ??? ???}? ? ? ??
? ??}
}
static AVCodec *first_avcodec = NULL;
AVCodecContext的enum CodecID codec_id成員記錄者當前數據流的Codec,void *priv_data記錄具體Codec所對應的上下文信息對像的指針,如MsrleContext。這三個結合起來現實數據解碼的作用。我們可以傻逼的認為AVCodecContext是這個解碼模塊的容器類,Codec是操作函數集合,類似MsrleContext的就是操作數據對像。
他們之間關系的確立:
每一個解碼類型都會有自己的Codec靜態對像,Codec的int priv_data_size記錄該解碼器上下文的結構大小,如MsrleContext。這些都是編譯時確定的,程序運行時通過avcodec_register_all()將所有的解碼器注冊成一個鏈表。在av_open_input_stream()函數中調用AVInputFormat的read_header()中讀文件頭信息時,會讀出數據流的CodecID,即確定了他的解碼器Codec。
typedef struct AVPicture {
? ? uint8_t *data[4];
? ? int linesize[4]; ? ? ? ///< number of bytes per line
} AVPicture;
typedef struct AVFrame
{
? ?uint8_t *data[4]; // 有多重意義,其一用NULL 來判斷是否被占用
? ?int linesize[4];
? ?uint8_t *base[4]; // 有多重意義,其一用NULL 來判斷是否分配內存
? ?//......其他的數據
} AVFrame;
從定義上可知,AVPicture是AVFrame的一個子集,他們都是數據流在編解過程中用來保存數據緩存的對像,從int av_read_frame(AVFormatContext *s, AVPacket *pkt)函數看,從數據流讀出的數據首先是保存在AVPacket里,也可以理解為一個AVPacket最多只包含一個AVFrame,而一個AVFrame可能包含好幾個AVPacket,AVPacket是種數據流分包的概念。記錄一些音視頻相關的屬性值,如pts,dts等,定義如下:
typedef struct AVPacket {? ?
? ? int64_t pts;? ?
? ? int64_t dts;
? ? uint8_t *data;
? ? int ? size;
? ? int ? stream_index;
? ? int ? flags;? ?
? ? int ? duration;
? ? void ?(*destruct)(struct AVPacket *);
? ? void ?*priv;
? ? int64_t pos; ? ? ? ? ? ? ? ? ? ? ? ? ? ?///< byte position in stream, -1 if unknown? ?
? ? int64_t convergence_duration;
} AVPacket;