FFmpeg源码详解：从入门到实践

5星 · 超过95%的资源需积分: 43 174 浏览量更新于2024-07-29 收藏 1.34MB PDF 举报

FFmpeg是一个广泛使用的开源多媒体处理框架，特别在视频和音频编码、解码以及流处理方面具有强大的功能。本文档深入剖析了FFmpeg的核心组件FFPLAY的源码，旨在帮助初学者理解和掌握这一复杂但关键的部分。作者杨书良以其丰富的经验和详尽的讲解，将复杂的源码逻辑分解为易于理解的章节。第1章概述了FFPLAY的基本结构，包括文件概览、播放器原理、架构特点、主要改动以及与SDL（Simple DirectMedia Layer）的集成，以及对AVI文件格式和常见的视频音频压缩算法如MSRLE和TrueSpeech的简要介绍。这为读者提供了整体的框架认识，以便后续深入研究。第二章着重于FFmpeg的基础库libavutil的剖析，涵盖了多个关键头文件如common.h、bswap.h、rational.h、mathematics.h和avutil.h。这些文件的功能描述和文件注释揭示了FFmpeg内部处理音频和视频数据时所使用的数学运算、数据类型转换和文件操作等核心技术。第三章转向libavformat部分，这是FFmpeg处理媒体文件输入输出的核心模块。章节详细列出了avformat.h、allformat.c、cutils.c、file.c、avio.h、avio.c、aviobuf.c以及utils_format.c等关键文件及其功能和注释。这些代码涉及到文件解析、数据流管理、IO操作以及不同格式支持的实现。通过逐章深入分析，读者可以了解到FFPLAY源码中涉及的文件系统操作、数据结构设计、解码器和编码器的选择、多媒体流处理策略，以及与其他库（如SDL）的交互。这对于学习者来说，无论是开发自己的多媒体应用还是深入理解FFmpeg的工作原理，都是一份宝贵的资源。通过实践理解和消化这些内容，可以帮助新手逐渐提升对FFmpeg源码的理解和操作能力。

FFMPEG/FFPLA Y 源码剖析第 16 页共 234 页

感恩的心，感谢生命中的每一个人！ mcodec.cnblogs.com tslking@tom.com

对应一个 URLProtocol 结构，比如 file ， pipe ， tcp 等等，但瘦身后的 ffplay 只支持 file 一种输入文件。 next 变量

用于把所有支持的广义的输入文件连接成链表，便于遍历查找。

typedef struct URLContext

{

struct URLProtocol *prot;

int

flags;

int

max_packet_siz e; // if non z ero, the stream is packetized with this max packet size

void *priv_data; // 文件句柄 fd ，网络通信 Scoket 等

char filename[1]; // specified filename

} URLContext;

URLContext 结构表示程序运行的当前广义输入文件使用的上下文，着重于所有广义输入文件共有的属性 ( 并

且是在程序运行时才能确定其值 ) 和关联其他结构的字段。 prot 字段关联相应的广义输入文件； priv_data 字段关

联各个具体广义输入文件的句柄。

typedef struct ByteIOContext

{

unsigned char *buffer;

int

buffer_siz e;

unsigned char *buf_ptr, *buf_end;

void *opaque; // 关联 URLContext

int

(*read_buf)(void *opaque, uint8_t *buf,

int

buf_siz e);

int

(*write_buf)(void *opaque, uint8_t *buf,

int

buf_siz e);

offset_t(*seek)(void *opaque, offset_t offset,

int

whence);

offset_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

max_packet_siz e;

int

error; // contains the error code or 0 if no error happened

} ByteIOContext;

ByteIOContext 结构扩展 URLProtocol 结构成内部有缓冲机制的广泛意义上的文件，改善广义输入文件的 IO

性能。由其数据结构定义的字段可知，主要是缓冲区相关字段，标记字段，和一个关联字段 opaque 来完成广义

文件读写操作。 opaque 关联字段用于关联 URLContext 结构，间接关联并扩展 URLProtocol 结构。

接着我们来重点分析 AVStream/AVIStream 这几个数据结构，这几个数据结构定义了解析媒体流的核心属性

，

主要用于读取媒体流数据，相当于 Directshow 中的解复用 Demux 内部的流解析逻辑。特别注意此结构关联

AVCodecContext 结构，并经此结构能跳转到其他结构。

FFMPEG/FFPLA Y 源码剖析第 19 页共 234 页

感恩的心，感谢生命中的每一个人！ mcodec.cnblogs.com tslking@tom.com

AVStream *audio_st; // 关联的主要数据结构是 AVCodecContext 和 AVIStream

AVStream *video_st;

int

audio_stream; // 音频流索引，实际表示 AVFormatContext 结构中 AVStream *streams[] 数组中的索引

int

video_stream; // 视频流索引，实际表示 AVFormatContext 结构中 AVStream *streams[] 数组中的索引

PacketQueue audioq; // 音频数据包队列，注意一包音频数据可能包含几个音频帧

PacketQueue videoq; // 视频数据包队列，注意瘦身后的 ffplay 一包视频数据是完整的一帧

VideoPicture pictq[VIDEO_PICTURE_QUEUE_SIZE]; // 输出视频队列，瘦身后的 ffplay 只有一项

double frame_last_delay;

uint8_t audio_buf[(AVCODEC_MAX_AUDIO_FRAME_SIZE *3) / 2]; // 输出的音频缓存

unsigned

int

audio_buf_siz e;

int

audio_buf_index;

AVPacket audio_pkt; // 音频包属性，只一个指针指向原始音频包数据，非直接包含音频数据包数据

uint8_t *audio_pkt_data;

int

audio_pkt_siz e;

SDL_mutex *video_decoder_mutex; // 视频线程同步互斥变量

SDL_mutex *audio_decoder_mutex; // 音频线程同步互斥变量

char filename[240]; // 媒体文件名

} VideoState;

音视频数据流简单流程，由 ByteIOContext(URLContext/URLProtocol ) 表示的广义输入文件，在

AVStream(AVIStreamt) 提供的特定文件容器流信息的指引下，用 AVInputFormat(AVFormatContext /AVInputForma

) 接口的 read_packet() 函数读取完整的一帧数据，分别放到音频或视频 PacketQueue(AVPacketList/AVPacket) 队列

中，这部分功能由 decode_thread 线程完成。对于视频数据， vide o_thread 线程不停的从视频 PacketQueue 队列中

取出视频帧，调用 AVCodec(AVCodecContext /MsrleContext) 接口的 decode() 函数解码视频帧，在适当延时后做颜

色空间转化并调用 SDL 库显示出来。对于音频数据， SDL 播放库播放完缓冲区的 PCM 数据后，调用

sdl_audio_callback() 函数解码音频数据，并把解码后的 PCM 数据填充到 SDL 音频缓存播放。当下次播放完后，

再调用 sdl_audio_callback() 函数解码填充，如此循环不已。对于 SDL 库的实现，这里不做讨论。

特别注意 decode_thread

decode_thread

decode_thread 线程的共分为三大逻辑功能。

(1)

：首先调用

av_open_input_file() 直接识别文件格式和间接识别媒体格式 ( 媒体格式是通过 av_open_input_fi le

调用 av_open_input_stream 再调用 ic->iformat->read_header(ic, ap) 来识别的，所以是间接识别媒体格式 ) 。

FFMPEG/FFPLA Y 源码剖析第 20 页共 234 页

感恩的心，感谢生命中的每一个人！ mcodec.cnblogs.com tslking@tom.com

(2) ：接着调用 stream_component_open() 查找打开编解码器 codec 并启动音频和视频解码线程。

(3) ：再接着解析文件，分离音视频数据包，排序进入队列。

1.5

1.5 ffplay

ffplay

ffplay 主要改动

主要改动

在 ffmpeg 的瘦身过程中，精跳细选留下 MS RLE 视频压缩算法和 True Speech 语音压缩算法，主要是因为这

两个算法足够的简单，并且测试文件 CLOCKTXT.avi 就在手边， AVI 容器的解复用也很简单，不好的就是视频

分辨率是 321x321 太怪怪，简单转换为 YUV 显示不太正确，所以把它转压为 320x320 格式，无损压缩的转压就

是麻烦多多，常规的转压缩工具都不好用，浪费了比较长的时间。

超大量的删除不用支撑的文件格式和媒体编解码算法相关代码，删掉不支持的平台相关代码，删掉了一些不

用支撑的功能，同时写死某些参数又精简了很多函数的实现，有些地方牺牲了一些运算进度来简化，有些函数做

了合并，为实现最小化把没有实际使用的几乎所有变量和函数也删掉了。

ffplay 有几个函数名字值得商榷，不太符合上下文，为便于理解，做了修改。

url_fread() 函数由 get_buffer() 改名而来，如果把 ByteIOContext *s 看作是广义上的文件句柄，已有的

url_fopen()/url_fclose()/url_feof()/url_fsiz e()/url_ftell()/url_fskip()/url_fseek() 函数名字非常准确，但是从文件操作的

完备性来讲，没有读文件的函数 ( 解码器不写文件所以不需要考虑 url_fwrite() 函数 ) 。 ffplay 原始的 get_buffer() 函

数实际就是广义上的读文件函数，把它改成 url_fread() 后文件操作类函数就完备了。

在读文件模块，操作内部缓冲区的几个静态内部函数 url_read_buf()/url_seek_buf()/url_write_buf () 是由相应的

url_read_packet()/url_seek_packet()/url_write_packet() 修改而来，首先在功能上它们维护模块内部使用的 buffer

，

其

次 read_packet() 类函数在其他地方有使用，在那个地方一次读一个完整数据包 (packet) ，为区分 buffer 和 packet

的不同就修改了名字。

数据结构的修改，把 AVStream 结构中的 AVCodecContext *codec 改成了 actx 更准确的描述了变量的意义。

同步机制的修改，此瘦身后的 ffplay 采用比较简单的同步策略，视频音频都从零开始起步计时，按照各自的

时钟往前走，音频由自身特性决定不用时钟，播放速率由采样率，声道数，量化 bit 数决定；视频按照帧率计算

每帧间隔，从第二帧开始忽略掉读文件解码显示等等操作消耗的时间，先 sleep 间隔时间再显示视频图像，为此

在 AVStream 结构中添加 double frame_last_delay 变量表示帧间隔时间。

1.6

1.6 SDL

SDL

SDL 显示视频

显示视频

SDL 是 Simple Direct Layer 的缩写。它是一个出色的多媒体库，适用于 PC 平台，并且已经应用在许多工

程中，它是如此的优秀，甚至已移植到某些手机平台上。它的官方网站是 http://www.libsdl.org/ ，在这个网

剩余233页未读，继续阅读

defineYou

粉丝: 2

FFmpeg源码详解：从入门到实践

FFMPEG FFPLAY 源码剖析_杨书良著_带目录高清.pdf

FFMPEG源码深入解析.pdf

FFMpeg_FFPlay 源码剖析.pdf（杨书良）全套附源代码

ffmpeg源码剖析.pdf

FFmpeg 源码剖析.rar

FFmpeg源码剖析与核心组件详解

FFmpeg源码剖析与简化版实现

掌握G711/G723编解码：FFmpeg源码剖析

ffmpeg的ffplay源码剖析

ffdoc （FFMPEG的最完整教程）（FFMPEG的源码剖析）

最新资源