ffplay 播放器源代码分析
共 13848字,需浏览 28分钟
·
2021-06-22 15:37
视频播放器原理其实大抵相同,都是对音视频帧序列的控制。只是一些播放器在音视频同步上可能做了更为复杂的帧预测技术,来保证音频和视频有更好的同步性。
ffplay 是 FFMpeg 自带的播放器,使用了 ffmpeg 解码库和用于视频渲染显示的 sdl 库,也是业界播放器最初参考的设计标准。
本文对 ffplay 源码进行分析,试图用更基础而系统的方法,来尝试解开播放器的音视频同步,以及播放/暂停、快进/后退的控制原理。
由于 FFMpeg 本身的跨平台特性,相比在移动端看音视频代码,在 PC 端利用 VS 查看和调试代码,分析播放器原理,要高效迅速很多。
由于 FFMpeg 官方提供的 ffmplay 在 console 中进行使用不够直观,本文直接分析 CSDN 上将 ffplay 移植到 VC 的代码(ffplay for MFC)进行分析。
一、初探mp4文件
为了让大家对视频文件有一个初步认识,首先来看对一个MP4文件的简单分析,如图1。
图1 对MP4文件解参
从图一我们知道,每个视频文件都会有特定的封装格式、比特率、时长等信息。视频解复用之后,就划分为video_stream和audio_stream,分别对应视频流和音频流。
解复用之后的音视频有自己独立的参数,视频参数包括编码方式、采样率、画面大小等,音频参数包括采样率、编码方式和声道数等。
对解复用之后的音频和视频Packet进行解码之后,就变成原始的音频(PWM)和视频(YUV/RGB)数据,才可以在进行显示和播放。
其实这已经差不多涉及到了,视频解码播放的大部分流程,整个视频播放的流程如图2所示。
图2 视频播放流程(图摘自http://blog.csdn.net/leixiaohua1020/article/details/50534150)
二、以最简单播放器开始:FFmpeg解码 + SDL显示
为将问题简单化,先不考虑播放音频,只播放视频,代码流程图如图3所示:
图3 播放器流程图(图源见水印)
流程图说明如下:
1.FFmpeg初始化的代码比较固定,主要目的就是为了设置 AVFormatContext 实例中相关成员变量的值,调用av_register_all、avformat_open_input av_find_stream_info和avcodec_find_decoder等函数。
如图4所示,初始化之后的AVFormatContext实例里面具体的值,调用av_find_stream_info就是找到文件中的音视频流数据,对其中的streams(包含音频、视频流)变量进行初始化。
图4 AVFormatContext初始化实例
2.av_read_frame不断读取stream中的下一帧,对其进行解复用得到视频的AVPacket,随后调用avcodec_decode_video2是视频帧AVPacket进行解码,得到图像帧AVFrame。
3.得到AVFrame之后,接下来就是放到SDL中进行渲染显示了,也很简单,流程见下面代码注释:
SDL_Overlay *bmp;
//将解析得到的AVFrame的数据拷贝到SDL_Overlay实例当中
SDL_LockYUVOverlay(bmp);
bmp->pixels[0]=pFrameYUV->data[0];
bmp->pixels[2]=pFrameYUV->data[1];
bmp->pixels[1]=pFrameYUV->data[2];
bmp->pitches[0]=pFrameYUV->linesize[0];
bmp->pitches[2]=pFrameYUV->linesize[1];
bmp->pitches[1]=pFrameYUV->linesize[2];
SDL_UnlockYUVOverlay(bmp);
//设置SDL_Rect,因为涉及到起始点和显示大小,用rect进行表示。
SDL_Rect rect;
rect.x = 0;
rect.y = 0;
rect.w = pCodecCtx->width;
rect.h = pCodecCtx->height;
//将SDL_Overlay数据显示到SDL_Surface当中。
SDL_DisplayYUVOverlay(bmp, &rect);
//延时40ms,留足ffmpeg取到下一帧并解码该帧的时间,随后继续读取下一帧
SDL_Delay(40);
由上面的原理可知,从帧流中获取到AVPacket,并且解码得到AVFrame,渲染到SDL窗口中。
图5 视频播放状态图
对视频播放的流程总结一下就是:读取下一帧——>解码——>播放——>不断往复,状态图如图5所示。
三、先抛五个问题
本文还是以问题抛问题的思路,以逐步对每个问题进行原理性分析,加深对音视频解码和播放的认识。以下这些问题也是每一个播放器所需要面对的基础问题和原理:
1.我们在观看电影时发现,电影可以更换不同字幕,甚至不同音频,比如中英文字幕和配音,最后在同一个画面中进行显示,视频关于画面、字幕和声音是如何组合的?
其实每一个视频文件,读取出来之后发现,都会被区分不同的流。为了让大家有更具体的理解,以FFMpeg中的代码为例,AVMediaType定义了具体的流类型:
enum AVMediaType {
AVMEDIA_TYPE_VIDEO, //视频流
AVMEDIA_TYPE_AUDIO, //音频流
AVMEDIA_TYPE_SUBTITLE, //字幕流
};
利用av_read_frame读取出音视频帧之后,随后就利用avcodec_decode_video2对视频捷星解码,或者调用avcodec_decode_audio4对音频进行解码,得到可以供渲染和显示的音视频原始数据。
图像和字幕都将会以Surface或者texture的形式,就像Android中的SurfaceFlinger,将画面不同模块的显示进行组合,生成一幅新的图像,显示在视频画面中。
2.既然视频有帧率的概念,音频有采样率的概念,是否直接利用帧率就可以控制音视频的同步了呢?每一个视频帧和音频帧在时域上都对应于一个时间点,按道理来说只要控制每一个音视频帧的播放时间,就可以实现同步。
但实际上,对每一帧显示的时间上的精确控制是很难的,更何况音频和视频的解码所需时间不同,极容易引起音视频在时间上的不同步。
所以,播放器具体是如何做音视频同步的呢?
3.视频的音频流、视频流和字幕流,他们在时间上是连续的还是离散的?不同流的帧数相同吗?
由于计算机只能数字模拟离散的世界,所以在时间上肯定是离散的。那既然是离散的,他们的帧数是否相同呢?
视频可以理解为诸多音频帧、视频帧和字幕帧在时间上的序列,他们在时间上的时长,跟视频总时长是相同的,但是由于每个帧解码时间不同,必然会导致他们在每帧的时间间隔不相同。
音频原始数据本身就是采样数据,所以是有固定时钟周期。但是视频假如想跟音频进行同步的话,可能会出现跳帧的情况,每个视频帧播放时间差,都会起伏不定,不是恒定周期。
所以结论是,三者在视频总时长上播放的帧数肯定是不一样的。
4.视频播放就是一系列的连续帧不停渲染。对视频的控制操作包括:暂停和播放、快进和后退。那有没有想过,每次快进/后退的幅度,以时间为量度好,还是以每次跳跃的帧数,就是每次快进是前进多长时间,还是前进多少帧。时间 VS 帧数?
由上面问题分析,我们知道,视频是以音频流、视频流和字幕流进行分流的,假如以帧数为基础,由于不同流的帧数量不一定相同,以帧数为单位,很容易导致三个流播放的不一致。
因此以时间为量度,相对更好,直接搜寻mp4文件流,当前播放时间的前进或后退时长的seek时间点,随后重新对文件流进行分流解析,就可以达到快进和后退之后的音视频同步效果。
我们可以看到绝大部分播放器,快进/倒退都是以时长为步进的,我们可以看看ffplay是怎么样的,以及是如何实现的。
5.上一节中,实现的简单播放器,解码和播放都是在同一个线程中,解码速度直接影响播放速度,从而将直接造成播放不流畅的问题。那如何在解码可能出现速度不均匀的情况下,进行流畅的视频播放呢?
很容易想到,引入缓冲队列,将视频图像渲染显示和视频解码作为两个线程,视频解码线程往队列中写数据,视频渲染线程从队列中读取数据进行显示,这样就可以保证视频是可以流程播放的。
因此需要采用音频帧、视频帧和字幕帧的三个缓冲队列,那如何保证音视频播放的同步呢?
PTS是视频帧或者音频帧的显示时间戳,究竟是如何利用起来的,从而控制视频帧、音频帧以及字幕帧的显示时刻呢?
那我们就可以探寻ffplay,究竟是如何去做缓冲队列控制的。
所有以上五个问题,我们都将在对ffplay源代码的探寻中,逐步找到更具体的解答。
四、ffplay代码总体结构
图6 ffplay代码总体流程
网上有人做了ffplay的总体流程图,如图6。有了这幅图,代码看起来,就会轻松了很多。流程中具体包含的细节如下:
1.启动定时器Timer,计时器40ms刷新一次,利用SDL事件机制,触发从图像帧队列中读取数据,进行渲染显示;
2.stream_componet_open函数中,av_read_frame()读取到AVPacket,随后放入到音频、视频或字幕Packet队列中;
3.video_thread,从视频packet队列中获取AVPacket并进行解码,得到AVFrame图像帧,放到VideoPicture队列中。
4..audio_thread线程,同video_thread,对音频Packet进行解码;
5.subtitle_thread线程,同video_thread,对字幕Packet进行解码。
五、视频播放器的操作控制
视频播放器的操作包括播放/暂停、快进/倒退、逐帧播放等,这些操作的实现原理是什么呢,下面对其从代码层面逐个进行分析。
5.1 ffplay所定义的关键结构体VideoState
与FFmpeg解码类似,定义了一个AVFormatContext结构体,用于存储文件名、音视频流、解码器等字段,供全局进行访问。
ffplay也定义了一个结构体VideoState,通过对VideoState的分析,就可以大体知道播放器基本实现原理。
typedef struct VideoState {
// Demux解复用线程,读视频文件stream线程,得到AVPacket,并对packet入栈
SDL_Thread *read_tid;
//视频解码线程,读取AVPacket,decode 爬出可以成AVFrame并入队
SDL_Thread *video_tid;
//视频播放刷新线程,定时播放下一帧
SDL_Thread *refresh_tid;
int paused; //控制视频暂停或播放标志位
int seek_req; //进度控制标志
int seek_flags;
AVStream *audio_st; //音频流
PacketQueue audioq; //音频packet队列
double audio_current_pts; //当前音频帧显示时间
AVStream *subtitle_st; //字幕流
PacketQueue subtitleq;//字幕packet队列
AVStream *video_st; //视频流
PacketQueue videoq;//视频packet队列
double video_current_pts; ///当前视频帧pts
double video_current_pts_drift;
VideoPicture pictq[VIDEO_PICTURE_QUEUE_SIZE]; //解码后的图像帧队列
}
从VideoState结构体中可以看出:
1.解复用、视频解码和视频刷新播放,分属三个线程中,并行控制;
2.音频流、视频流、字幕流,都有自己的缓冲队列,供不同线程读写,并且有自己的当前帧的PTS;
3.解码后的图像帧单独放在pictq队列当中,SDL利用其进行显示。
其中PTS是什么呢,这在音视频中是一个很重要的概念,直接决定视频帧或音频帧的显示时间,下面具体介绍一下。
5.2 补充基础知识——PTS和DTS
图7 音视频解码分析
图7为输出的音频帧和视频帧序列,每一帧都有PTS和DTS标签,这两个标签究竟是什么意思呢?DTS(Decode Time Stamp)和PTS(Presentation Time Stamp)都是时间戳,前者是解码时间,后者是显示时间,都是为视频帧、音频帧打上的时间标签,以更有效地支持上层应用的同步机制。
也就是说,视频帧或者音频在解码时,会记录其解码时间,视频帧的播放时间依赖于PTS。
对于声音来说 ,这两个时间标签是相同的;但对于某些视频编码格式,由于采用了双向预测技术,DTS会设置一定的超时或延时,保证音视频的同步,会造成DTS和PTS的不一致。
5.3 如何控制音视频同步
我们已经知道,视频帧的播放时间其实依赖pts字段的,音频和视频都有自己单独的pts。但pts究竟是如何生成的呢,假如音视频不同步时,pts是否需要动态调整,以保证音视频的同步?
下面先来分析,如何控制视频帧的显示时间的:
static void video_refresh(void *opaque){
//根据索引获取当前需要显示的VideoPicture
VideoPicture *vp = &is->pictq[is->pictq_rindex];
if (is->paused)
goto display; //只有在paused的情况下,才播放图像
// 将当前帧的pts减去上一帧的pts,得到中间时间差
last_duration = vp->pts - is->frame_last_pts;
//检查差值是否在合理范围内,因为两个连续帧pts的时间差,不应该太大或太小
if (last_duration > 0 && last_duration < 10.0) {
/* if duration of the last frame was sane, update last_duration in video state */
is->frame_last_duration = last_duration;
}
//既然要音视频同步,肯定要以视频或音频为参考标准,然后控制延时来保证音视频的同步,
//这个函数就做这个事情了,下面会有分析,具体是如何做到的。
delay = compute_target_delay(is->frame_last_duration, is);
//获取当前时间
time= av_gettime()/1000000.0;
//假如当前时间小于frame_timer + delay,也就是这帧改显示的时间超前,还没到,就直接返回
if (time < is->frame_timer + delay)
return;
//根据音频时钟,只要需要延时,即delay大于0,就需要更新累加到frame_timer当中。
if (delay > 0)
/更新frame_timer,frame_time是delay的累加值
is->frame_timer += delay * FFMAX(1, floor((time-is->frame_timer) / delay));
SDL_LockMutex(is->pictq_mutex);
//更新is当中当前帧的pts,比如video_current_pts、video_current_pos 等变量
update_video_pts(is, vp->pts, vp->pos);
SDL_UnlockMutex(is->pictq_mutex);
display:
/* display picture */
if (!display_disable)
video_display(is);
}
函数compute_target_delay根据音频的时钟信号,重新计算了延时,从而达到了根据音频来调整视频的显示时间,从而实现音视频同步的效果。
static double compute_target_delay(double delay, VideoState *is)
{
double sync_threshold, diff;
//因为音频是采样数据,有固定的采用周期并且依赖于主系统时钟,要调整音频的延时播放较难控制。所以实际场合中视频同步音频相比音频同步视频实现起来更容易。
if (((is->av_sync_type == AV_SYNC_AUDIO_MASTER && is->audio_st) ||
is->av_sync_type == AV_SYNC_EXTERNAL_CLOCK)) {
//获取当前视频帧播放的时间,与系统主时钟时间相减得到差值
diff = get_video_clock(is) - get_master_clock(is);
sync_threshold = FFMAX(AV_SYNC_THRESHOLD, delay);
//假如当前帧的播放时间,也就是pts,滞后于主时钟
if (fabs(diff) < AV_NOSYNC_THRESHOLD) {
if (diff <= -sync_threshold)
delay = 0;
//假如当前帧的播放时间,也就是pts,超前于主时钟,那就需要加大延时
else if (diff >= sync_threshold)
delay = 2 * delay;
}
}
return delay;
}
图8 音视频帧显示序列
所以这里的流程就很简单了,图8简单画了一个音视频帧序列,想表达的意思是,音频帧数量和视频帧数量不一定对等,另外每个音频帧的显示时间在时间上几乎对等,每个视频帧的显示时间,会根据具体情况有延时显示,这个延时就是有上面的compute_target_delay函数计算出来的。
计算延迟后,更新pts的代码如下:
static void update_video_pts(VideoState *is, double pts, int64_t pos) {
double time = av_gettime() / 1000000.0;
/* update current video pts */
is->video_current_pts = pts;
is->video_current_pts_drift = is->video_current_pts - time;
is->video_current_pos = pos;
is->frame_last_pts = pts;
}
整个流程可以概括为:
显示第一帧视频图像;
根据音频信号,计算出第二帧的delay时间,更新该帧的pts;
当pts到达后,显示第二帧视频图像;
重复以上步骤,到最后一帧。
也许在这里仍然会让人很困惑,为什么单单根据主时钟,就可以播放下一帧所需要的延时呢?
其实视频是具备一定长度的播放流,具体可以分为音频流、视频流和字幕流,三者同时在一起播放形成了视频,当然他们总的播放时间是跟视频文件的播放时长是一样的。
由于音频流本身是pwm采样数据,以固定的频率播放,这个频率是跟主时钟相同或是它的分频,从时间的角度来看,每个音频帧是自然均匀流逝。
所以音频的话,直接按照主时钟或其分频走就可以了。
视频,要根据自己的显示时间即pts,跟主时钟当前的时间进行对比,确定是超前还是滞后于系统时钟,从而确定延时,随后进行准确的播放,这样就可以保证音视频的同步了。
那接下来,还有一个问题,计算出延时之后,难道需要sleep一下做延迟显示吗?
其实并不是如此,上面分析我们知道delay会更新到当前需要更新视频帧的pts (video_current_pts),对当前AVFrame进行显示前,先检测其pts时间,假如还没到,就不进行显示了,直接return。直到下一次刷新,重新进行检测(ffplay采用的40ms定时刷新)。
代码如下,未到更新后的pts时间( is->frame_timer + dela),直接return:
if (av_gettime()/1000000.0 < is->frame_timer + delay)
return;
那接下来就是分析如何播放视频帧,就很简单了,只是这里多加了一个字幕流的处理:
static void video_image_display(VideoState *is)
{
VideoPicture *vp;
SubPicture *sp;
AVPicture pict;
SDL_Rect rect;
int i;
vp = &is->pictq[is->pictq_rindex];
if (vp->bmp) {
//字幕处理
if (is->subtitle_st) {}
}
//计算图像的显示区域
calculate_display_rect(&rect, is->xleft, is->ytop, is->width, is->height, vp);
//显示图像
SDL_DisplayYUVOverlay(vp->bmp, &rect);
//将pic队列的指针向前移动一个位置
pictq_next_picture(is);
}
VIDEO_PICTURE_QUEUE_SIZE 只设置为4,很快就会用完了。数据满了如何重新更新呢?
一旦检测到超出队列大小限制,就处于等待状态,直到pictq被取出消费,从而避免开启播放器,就把整个文件全部解码完,这样会代码会很吃内存。
static int queue_picture(VideoState *is, AVFrame *src_frame, double pts1, int64_t pos){
/* keep the last already displayed picture in the queue */
while (is->pictq_size >= VIDEO_PICTURE_QUEUE_SIZE - 2 &&
!is->videoq.abort_request) {
SDL_CondWait(is->pictq_cond, is->pictq_mutex);
}
SDL_UnlockMutex(is->pictq_mutex);
}
5.4 如何控制视频的播放和暂停?
static void stream_toggle_pause(VideoState *is)
{
if (is->paused) {
//由于frame_timer记下来视频从开始播放到当前帧播放的时间,所以暂停后,必须要将暂停的时间( is->video_current_pts_drift - is->video_current_pts)一起累加起来,并加上drift时间。
is->frame_timer += av_gettime() / 1000000.0 + is->video_current_pts_drift - is->video_current_pts;
if (is->read_pause_return != AVERROR(ENOSYS)) {
//并更新video_current_pts
is->video_current_pts = is->video_current_pts_drift + av_gettime() / 1000000.0;
}
//drift其实就是当前帧的pts和当前时间的时间差
is->video_current_pts_drift = is->video_current_pts - av_gettime() / 1000000.0;
}
//paused取反,paused标志位也会控制到图像帧的展示,按一次空格键实现暂停,再按一次就实现播放了。
is->paused = !is->paused;
}
特别说明:paused标志位控制着视频是否播放,当需要继续播放的时候,一定要重新更新当前所需要播放帧的pts时间,因为这里面要加上已经暂停的时间。
5.5 逐帧播放是如何做的?
在视频解码线程中,不断通过stream_toggle_paused,控制对视频的暂停和显示,从而实现逐帧播放:
static void step_to_next_frame(VideoState *is)
{
//逐帧播放时,一定要先继续播放,然后再设置step变量,控制逐帧播放
if (is->paused)
stream_toggle_pause(is);//会不断将paused进行取反
is->step = 1;
}
其原理就是不断的播放,然后暂停,从而实现逐帧播放:
static int video_thread(void *arg)
{
if (is->step)
stream_toggle_pause(is);
……………………
if (is->paused)
goto display;//显示视频
}
}
5.6 快进和后退
关于快进/后退,首先抛出两个问题:
1. 快进以时间为维度还是以帧数为维度来对播放进度进行控制呢?
2.一旦进度发生了变化,那么当前帧,以及AVFrame队列是否需要清零,整个对stream的流是否需要重新来进行控制呢?
ffplay中采用以时间为维度的控制方法。对于快进和后退的控制,都是通过设置VideoState的seek_req、seek_pos等变量进行控制。
do_seek: //实际上是计算is->audio_current_pts_drift + av_gettime() / 1000000.0,确定当前需要播放帧的时间值 pos = get_master_clock(cur_stream); pos += incr; //incr为每次快进的步进值,相加即可得到快进后的时间点 stream_seek(cur_stream, (int64_t)(pos AV_TIME_BASE), (int64_t)(incrAV_TIME_BASE), 0);
关于stream_seek的代码如下,其实就是设置VideoState的相关变量,以控制read_tread中的快进或后退的流程:
/* seek in the stream */
static void stream_seek(VideoState *is, int64_t pos, int64_t rel, int seek_by_bytes)
{
if (!is->seek_req) {
is->seek_pos = pos;
is->seek_rel = rel;
is->seek_flags &= ~AVSEEK_FLAG_BYTE;
if (seek_by_bytes)
is->seek_flags |= AVSEEK_FLAG_BYTE;
is->seek_req = 1;
}
}
stream_seek中设置了seek_req标志,就直接进入前进/后退控制流程了,其原理是调用avformat_seek_file函数,根据时间戳控制索引点,从而控制需要显示的下一帧:
static int read_thread(void *arg){
//当调整播放进度以后
if (is->seek_req) {
int64_t seek_target = is->seek_pos;
int64_t seek_min = is->seek_rel > 0 ? seek_target - is->seek_rel + 2: INT64_MIN;
int64_t seek_max = is->seek_rel < 0 ? seek_target - is->seek_rel - 2: INT64_MAX;
//根据时间抽查找索引点位置,定位到索引点之后,下一帧的读取直接从这里开始,就实现了快进/后退操作
ret = avformat_seek_file(is->ic, -1, seek_min, seek_target, seek_max, is->seek_flags);
if (ret < 0) {
fprintf(stderr, "s: error while seeking\n", is->ic->filename);
} else {
//查找成功之后,就需要清空当前的PAcket队列,包括音频、视频和字幕
if (is->audio_stream >= 0) {
packet_queue_flush(&is->audioq);
packet_queue_put(&is->audioq, &flush_pkt);
}
if (is->subtitle_stream >= 0) {//处理字幕stream
packet_queue_flush(&is->subtitleq);
packet_queue_put(&is->subtitleq, &flush_pkt);
}
if (is->video_stream >= 0) {
packet_queue_flush(&is->videoq);
packet_queue_put(&is->videoq, &flush_pkt);
}
}
is->seek_req = 0;
eof = 0;
}
}
另外从上面代码中发现,每次快进后退之后都会对audioq、videoq和subtitleq进行flush清零,也是相当于重新开始,保证缓冲队列中的数据的正确性。
对于音频,开始仍然有些困惑,因为在暂停的时候,没有看到对音频的控制,是如何控制的呢?
后来发现,其实暂停的时候设置了is->paused变量,解复用和音频解码和播放都依赖于is->paused变量,所以音频和视频播放都随之停止了。
六、 这次分析ffplay代码的反省总结:
1.基础概念和原理积累,最开始接触FFmpeg,因为其涉及的概念很多,看起来有种无从下手的感觉。这时候必须从基本模块入手,逐步理解更多,一定的量积累,就会产生一些质变,更好的理解视频编解码机制;
2.一定要首先看懂代码总体架构和流程,随后针对每个细节点进行深入分析,会极大提高看代码效率。会画一些框图是非常重要的,比如下面这张,所以简要的流程图要比注重细节的uml图要方便得多;
3.看FFmpeg代码,在PC端上调试,会快捷很多。假如要在Android上,调用jni来看代码,效率就会很低。
来源:https://cloud.tencent.com/developer/article/1004559
作者: 张坤
推荐:
Android FFmpeg 实现带滤镜的微信小视频录制功能