FFmpeg时间基详解：从原理到实战，彻底解决音视频同步问题

1. 时间基到底在解决什么问题

但凡用FFmpeg做过音视频开发的人，几乎都绕不开一个让人头大的概念——时间基（Time Base）。我第一次接触这玩意儿的时候，看着代码里到处出现的AVRational、time_base、pts、dts，脑子里全是问号：为什么不能统一用一个秒或者毫秒来表示时间？搞这么复杂到底图什么？

后来踩的坑多了，才慢慢理解这套设计的精妙之处。简单来说，时间基就是FFmpeg用来表示时间的一套“刻度系统”。你可以把它想象成不同手表上的刻度——有的表最小刻度是秒，有的是毫秒，有的是微秒。当你拿两块不同刻度的表来对时间，不换算就会出大问题。

FFmpeg内部要处理各种各样的时间来源：摄像头采集的原始帧率可能是29.97fps这种非整数，音频采样率可能是44100Hz，容器格式里封装的时间戳单位又各不相同。如果全部统一成秒，用浮点数表示，精度损失和累积误差会非常严重。所以FFmpeg选择用有理数（分数）来表示时间基，每个时间戳都是一个整数，乘以时间基就得到真实的时间值。

这个设计带来的核心好处有三个：精度可控、运算高效、适配灵活。精度可控是因为有理数运算可以精确表示1/3这种无限循环小数；运算高效是因为整数运算比浮点运算快且没有累积误差；适配灵活是因为不同的流、不同的容器可以各自定义自己的时间基，互不干扰。

理解时间基，是掌握FFmpeg音视频同步、转码、封装、裁剪等所有核心操作的基础。不管你是做播放器、做转码服务、还是做音视频编辑工具，时间基搞不清楚，音画不同步、时间戳错乱、seek不准这些问题就会一直缠着你。这篇文章我会从实际开发的角度，把时间基的来龙去脉、换算方法、常见坑点全部拆开讲清楚，适合有一定FFmpeg基础但被时间基困扰的开发者。

2. 核心概念拆解与底层逻辑

2.1 AVRational结构体：有理数的表达方式

FFmpeg里时间基的定义非常朴素，就是一个结构体：

typedef struct AVRational { int num; // 分子 int den; // 分母 } AVRational;

这个结构体表示的就是分数num/den。比如{1, 1000}表示千分之一秒，也就是毫秒；{1, 90000}表示九万分之一秒，这是MPEG-TS流常用的时间基。

为什么用int而不是int64_t？因为时间基的分母通常不会超过几十万，分子一般是1或者1001这种小数值，int的范围完全够用。但时间戳本身用的是int64_t，因为长时间的视频时间戳数值会很大，比如90kHz时间基下，一小时的视频时间戳就是90000 * 3600 = 324000000，虽然int32勉强能装下，但为了安全统一用64位。

这里有个容易混淆的点：时间基本身是一个分数，但它表示的是“一个时间单位是多少秒”。比如{1, 1000}的时间基，时间戳值为500，表示的时间就是500 * (1/1000) = 0.5秒。这个换算关系必须刻在脑子里。

2.2 不同层级的时间基：从流到帧

FFmpeg里时间基不是只有一个，而是分层级的，每一层有自己的含义和用途。搞混层级是新手最常犯的错误。

AVStream.time_base：这是流级别的时间基，表示该流中时间戳的单位。对于视频流，它通常等于1/framerate，比如25fps的视频，时间基就是{1, 25}。对于音频流，它通常等于1/sample_rate，比如44100Hz的音频，时间基就是{1, 44100}。这个时间基在封装格式的头部定义，用于描述该流中所有时间戳的含义。

AVCodecContext.time_base：这是编解码器上下文的时间基，表示编码器或解码器内部使用的时间单位。对于解码器，这个值通常由解码器自己设置；对于编码器，需要我们在打开编码器之前设置好。它和AVStream.time_base可能不一致，转码时需要做转换。

AVFrame.time_base（新版本已废弃，改用AVFrame的pts配合AVCodecContext的time_base）：表示帧时间戳的时间基。在旧版本FFmpeg中，AVFrame有自己的time_base字段，新版本中这个字段被移除了，帧的时间戳统一用AVCodecContext.time_base来解释。

AVPacket.time_base（同样在新版本中行为有变化）：表示包时间戳的时间基。历史上AVPacket也有自己的time_base，后来被废弃，统一用AVStream.time_base来解释。

注意：FFmpeg 4.0之后的版本对时间基的处理做了不少调整，很多旧教程里的写法在新版本上会报错或者行为不一致。如果你看的资料比较老，一定要对照官方文档确认当前版本的行为。

2.3 PTS和DTS：时间戳的两个维度

PTS（Presentation Time Stamp）是显示时间戳，告诉播放器这一帧应该在什么时间被显示出来。DTS（Decoding Time Stamp）是解码时间戳，告诉解码器这一帧应该在什么时间被解码。

对于没有B帧的视频，PTS和DTS是相等的，解码顺序和显示顺序一致。但一旦有B帧，情况就复杂了：B帧需要参考后面的帧才能解码，所以它的解码顺序在参考帧之前，但显示顺序在参考帧之后。这就导致DTS和PTS出现差异。

用一个具体例子说明：假设视频帧的显示顺序是I帧、B帧、B帧、P帧。由于B帧依赖后面的P帧，实际解码顺序变成I帧、P帧、B帧、B帧。那么：

可以看到PTS和DTS的顺序完全不同。播放器根据PTS来显示帧，解码器根据DTS来解码帧。如果搞混了这两个概念，音视频同步就会出大问题。

2.4 时间基的换算：av_rescale_q的核心作用

不同时间基之间换算，FFmpeg提供了专门的函数：

int64_t av_rescale_q(int64_t a, AVRational bq, AVRational cq);

这个函数的作用是把时间戳a从时间基bq转换到时间基cq。内部实现是a * bq / cq，但为了避免溢出和精度损失，FFmpeg用了更复杂的算法。

举个实际例子：假设你有一个视频流，AVStream.time_base是{1, 25}，某个帧的PTS是50。现在你要把这个帧送给编码器，编码器的AVCodecContext.time_base是{1, 1000}。那么转换后的PTS就是：

av_rescale_q(50, {1, 25}, {1, 1000}) = 50 * (1/25) / (1/1000) = 50 * 1000 / 25 = 2000

验证一下：50个1/25秒就是2秒，2000个1/1000秒也是2秒，换算正确。

还有一个常用的函数是av_q2d，把AVRational转成double：

double av_q2d(AVRational a);

这个函数返回a.num / (double)a.den。比如av_q2d({1, 25})返回0.04，表示每个时间单位是0.04秒。这个函数在需要做浮点运算时很方便，但要注意浮点精度问题，不要用它来做精确的时间戳计算。

3. 实操中的时间基处理与避坑指南

3.1 转码场景下的时间基转换全流程

转码是时间基问题最集中的场景。一个典型的转码流程是：解封装 → 解码 → 编码 → 封装。每个阶段的时间基都可能不同，需要仔细处理。

解封装阶段：从AVFormatContext中读取AVPacket，此时AVPacket的pts和dts是基于AVStream.time_base的。比如一个MP4文件，视频流的time_base可能是{1, 12800}，音频流的time_base可能是{1, 44100}。

解码阶段：把AVPacket送给解码器，得到AVFrame。此时AVFrame的pts是基于AVCodecContext.time_base的。对于大多数解码器，这个时间基和AVStream.time_base一致，但不绝对。

编码阶段：把AVFrame送给编码器之前，需要确保帧的pts是基于编码器的time_base的。如果编码器的time_base和帧的pts时间基不一致，必须用av_rescale_q转换。

封装阶段：编码器输出的AVPacket，其pts是基于编码器time_base的。写入输出文件之前，需要把pts转换到输出流的time_base。

整个流程中，最容易出错的是编码阶段。很多人在打开编码器时随便设一个time_base，结果导致输出文件的时间戳完全错乱。正确的做法是：编码器的time_base应该设置为1/framerate，并且要保证帧的pts按照这个时间基递增。

// 设置编码器时间基 codec_ctx->time_base = (AVRational){1, fps}; codec_ctx->framerate = (AVRational){fps, 1}; // 转换帧的pts到编码器时间基 frame->pts = av_rescale_q(frame->pts, decoder_ctx->time_base, codec_ctx->time_base);

这里有个细节：framerate和time_base是倒数关系。framerate是{25, 1}表示25fps，对应的time_base是{1, 25}。设置的时候不要搞反了。

3.2 音视频同步中的时间基统一

音视频同步是时间基问题的另一个重灾区。音频和视频有各自的时间基，要同步播放必须统一到同一个时间基准上。

常见的做法是选择一个参考时钟（通常是音频时钟，因为音频对抖动更敏感），然后把视频帧的PTS转换到音频的时间基上进行比较。

// 假设音频时间基是audio_tb，视频时间基是video_tb // 视频帧的pts是video_pts int64_t video_pts_in_audio_tb = av_rescale_q(video_pts, video_tb, audio_tb); // 获取当前音频时钟 int64_t audio_clock = get_audio_clock(); // 计算差值 int64_t diff = video_pts_in_audio_tb - audio_clock; // 根据差值决定是等待还是丢帧 if (diff > THRESHOLD) { // 视频超前，等待 av_usleep(diff); } else if (diff < -THRESHOLD) { // 视频落后，丢帧 drop_frame(); }

这里的THRESHOLD通常取几十毫秒，太小会导致频繁调整，太大会导致同步不准。具体取值要根据实际场景调优。

实操心得：音视频同步的阈值不要设得太死，建议做成动态的。刚开始同步时用大阈值快速收敛，接近同步后用小阈值精细调整。我在一个直播项目里用固定阈值，结果网络抖动时画面频繁卡顿，后来改成动态阈值才解决。

3.3 seek操作中的时间基陷阱

seek是时间基问题最隐蔽的地方。av_seek_frame函数的签名是：

int av_seek_frame(AVFormatContext *s, int stream_index, int64_t timestamp, int flags);

这里的timestamp是基于哪个时间基的？答案是：基于AVStream.time_base。但很多人会误以为是基于AV_TIME_BASE（即{1, 1000000}，微秒）。

AV_TIME_BASE是FFmpeg定义的一个全局时间基，值为1000000，表示微秒。当stream_index传-1时，timestamp才是基于AV_TIME_BASE的。如果指定了具体的流，timestamp就是基于该流的time_base。

// 方式一：指定流，timestamp基于流的time_base int64_t target = 10 * stream->time_base.den / stream->time_base.num; // 10秒 av_seek_frame(fmt_ctx, stream_index, target, AVSEEK_FLAG_BACKWARD); // 方式二：不指定流，timestamp基于AV_TIME_BASE int64_t target_us = 10 * AV_TIME_BASE; // 10秒 av_seek_frame(fmt_ctx, -1, target_us, AVSEEK_FLAG_BACKWARD);

这两种方式的结果可能不同，因为方式一会seek到该流时间戳对应的位置，方式二会seek到全局时间对应的位置。实际开发中建议用方式一，因为更精确。

还有一个坑：seek之后，解码器里可能还有缓存的帧，这些帧的PTS可能小于seek目标。如果不处理，会出现seek后画面跳回旧位置的问题。正确的做法是seek之后调用avcodec_flush_buffers清空解码器缓存。

3.4 常见问题速查表

4. 进阶技巧与实战经验

4.1 自定义时间基的选择策略

虽然FFmpeg允许任意有理数作为时间基，但实际选择时有几个推荐值：

视频常用：{1, 90000}是MPEG-TS的标准时间基，兼容性最好；{1, 1000}是毫秒级，适合大多数场景；{1, framerate}是帧级，最直观但framerate为29.97这种非整数时会有精度问题。

音频常用：{1, sample_rate}是采样级，最精确；{1, 1000}是毫秒级，适合和视频统一。

选择时间基的核心原则是：精度够用即可，不要盲目追求高精度。时间基分母越大，时间戳数值越大，溢出风险越高。比如用{1, 1000000}做时间基，一小时的视频时间戳就是36亿，接近int32上限，必须用int64。而用{1, 90000}，一小时才3.24亿，安全得多。

踩过的坑：我曾经在一个项目里为了“精确”把所有时间基都设成{1, 1000000}，结果处理长视频时时间戳溢出，画面直接花屏。后来改成{1, 90000}就正常了。精度不是越高越好，够用就行。

4.2 处理可变帧率视频的时间基

可变帧率（VFR）视频是时间基处理的高级话题。固定帧率视频每帧间隔相同，时间基可以简单设为1/framerate。但VFR视频每帧间隔不同，不能用固定时间基。

处理VFR视频的正确做法是：保持原始时间基不变，不要强行转换成固定帧率。编码时把AVCodecContext.time_base设为一个足够精细的值（比如{1, 90000}），然后每帧的PTS按照实际显示时间设置。

// VFR视频处理 codec_ctx->time_base = (AVRational){1, 90000}; // 每帧的pts根据实际时间计算 frame->pts = av_rescale_q(actual_pts, src_time_base, codec_ctx->time_base);

如果强行把VFR转成CFR，会出现重复帧或丢帧，画面会卡顿或跳跃。除非业务明确要求CFR，否则保持VFR是更好的选择。

4.3 时间基相关的调试技巧

时间基问题往往很隐蔽，调试时需要一些技巧。我常用的方法有这几个：

打印时间基和PTS：在关键节点打印时间基和PTS，对比是否符合预期。

printf("stream tb: %d/%d, codec tb: %d/%d, pts: %ld\n", stream->time_base.num, stream->time_base.den, codec_ctx->time_base.num, codec_ctx->time_base.den, frame->pts);

用av_q2d转成秒来验证：把时间戳转成秒，直观判断是否正确。

double pts_seconds = frame->pts * av_q2d(codec_ctx->time_base); printf("pts in seconds: %f\n", pts_seconds);

检查时间戳单调性：正常情况下PTS应该单调递增（B帧的DTS可能不单调，但PTS一定单调）。如果发现PTS回退，说明时间基处理有问题。

用ffprobe验证输出：转码完成后用ffprobe检查输出文件的时间戳信息，确认是否符合预期。

ffprobe -v quiet -show_streams -show_frames output.mp4

这些方法看起来简单，但实际调试时非常有效。我遇到过一个问题，音视频同步始终差几百毫秒，打印时间基才发现音频流的时间基被错误地设成了{1, 48000}而不是{1, 44100}，导致所有时间戳都偏了。

4.4 新旧版本FFmpeg的时间基差异

FFmpeg 4.0是一个分水岭，之前和之后的时间基处理有不少差异。如果你维护的项目跨版本，这些差异必须注意。

AVFrame.time_base：4.0之前AVFrame有time_base字段，4.0之后被移除。旧代码里frame->time_base的写法在新版本会编译报错。替代方案是用AVCodecContext.time_base来解释帧的PTS。

AVPacket.time_base：类似地，AVPacket的time_base字段也被废弃。新版本中AVPacket的PTS统一用AVStream.time_base解释。

av_stream_get_side_data：这个函数在4.0之后行为有变化，影响某些时间基相关的元数据获取。

编码器时间基设置：新版本对编码器时间基的校验更严格，如果设置不合理会直接报错。旧版本可能只是警告。

经验之谈：升级FFmpeg版本时，时间基相关的代码一定要重点测试。我见过太多项目升级后音视频不同步，最后发现是时间基API变了。建议在升级前先写一个最小复现用例，验证时间基处理逻辑在新版本上的行为。

5. 从源码角度看时间基的实现

5.1 av_rescale_q的内部实现

av_rescale_q看起来简单，内部实现却有不少讲究。核心逻辑在av_rescale_rnd函数里，它要解决的核心问题是：如何在避免溢出的前提下，尽可能精确地计算a * b / c。

直接算a * b可能溢出，所以FFmpeg用了分步计算和位运算的技巧。具体实现比较复杂，但作为使用者，我们只需要知道：这个函数会尽量保证精度，但极端情况下仍可能溢出。如果时间戳特别大，建议先用av_rescale_q_rnd指定舍入方式，或者手动做除法。

// 安全的时间基转换 int64_t safe_rescale(int64_t ts, AVRational from, AVRational to) { // 先约分，减少溢出风险 int64_t a = ts * from.num * to.den; int64_t b = from.den * to.num; return a / b; }

这个简化版在大多数情况下够用，但不如av_rescale_q精确。生产环境还是建议用官方函数。

5.2 时间基在封装格式中的体现

不同的封装格式对时间基的处理不同，理解这些差异有助于排查问题。

MP4：MP4的mvhd和tkhd原子里有timescale字段，相当于时间基的分母。视频轨的timescale通常是帧率的整数倍，音频轨通常是采样率。MP4的时间戳是整数，单位是1/timescale秒。

MPEG-TS：MPEG-TS用90kHz的时间基，PTS和DTS都是33位整数。这个时间基是固定的，所有流都用同一个。

MKV：MKV用纳秒级时间基，精度很高。时间戳是int64，单位是纳秒。

FLV：FLV用毫秒级时间基，精度较低。时间戳是int32，单位是毫秒。

转码时如果输入输出格式不同，时间基转换是必须的。比如MP4转FLV，时间基从1/timescale转到毫秒，精度会损失，可能导致音视频轻微不同步。这时候需要在转换时做舍入处理，尽量减少误差。

5.3 时间基与帧率的关系再梳理

帧率和时间基的关系是初学者最容易搞混的地方，这里再梳理一遍。

帧率（framerate）是每秒显示的帧数，单位是fps。时间基（time_base）是每个时间单位对应的秒数。两者互为倒数关系：

time_base = 1 / framerate framerate = 1 / time_base

对于25fps的视频，framerate = {25, 1}，time_base = {1, 25}。每帧的PTS间隔是1（以时间基为单位），对应真实时间0.04秒。

对于29.97fps的视频，framerate = {30000, 1001}，time_base = {1001, 30000}。每帧的PTS间隔是1，对应真实时间1001/30000 ≈ 0.03337秒。注意这里不能用{1, 30}近似，否则长时间播放会累积误差。

关键点：非整数帧率必须用有理数精确表示。29.97不是30，23.976不是24，这些差异在短视频里看不出来，但长视频里会累积成秒级的偏差。

6. 实战案例：一个完整的时间基处理流程

6.1 场景描述

假设我们要做一个视频转码工具，输入是一个MP4文件，输出是FLV文件。输入视频是25fps，音频是44100Hz。输出要求视频保持25fps，音频保持44100Hz。

这个场景涉及的时间基转换有：MP4视频流时间基 → 解码器时间基 → 编码器时间基 → FLV视频流时间基；音频类似。每一层都要正确处理。

6.2 关键代码实现

// 打开输入 AVFormatContext *in_fmt = NULL; avformat_open_input(&in_fmt, input_path, NULL, NULL); avformat_find_stream_info(in_fmt, NULL); // 打开输出 AVFormatContext *out_fmt = NULL; avformat_alloc_output_context2(&out_fmt, NULL, NULL, output_path); // 视频流处理 int video_index = av_find_best_stream(in_fmt, AVMEDIA_TYPE_VIDEO, -1, -1, NULL, 0); AVStream *in_video_stream = in_fmt->streams[video_index]; // 创建输出视频流 AVStream *out_video_stream = avformat_new_stream(out_fmt, NULL); out_video_stream->time_base = (AVRational){1, 25}; // FLV视频时间基 // 编码器设置 AVCodecContext *video_enc_ctx = avcodec_alloc_context3(video_encoder); video_enc_ctx->time_base = (AVRational){1, 25}; video_enc_ctx->framerate = (AVRational){25, 1}; // 转码循环 AVPacket *pkt = av_packet_alloc(); AVFrame *frame = av_frame_alloc(); while (av_read_frame(in_fmt, pkt) >= 0) { if (pkt->stream_index == video_index) { // 解码 avcodec_send_packet(video_dec_ctx, pkt); while (avcodec_receive_frame(video_dec_ctx, frame) == 0) { // 时间基转换：解码器时间基 → 编码器时间基 frame->pts = av_rescale_q(frame->pts, video_dec_ctx->time_base, video_enc_ctx->time_base); // 编码 avcodec_send_frame(video_enc_ctx, frame); while (avcodec_receive_packet(video_enc_ctx, pkt) == 0) { // 时间基转换：编码器时间基 → 输出流时间基 pkt->pts = av_rescale_q(pkt->pts, video_enc_ctx->time_base, out_video_stream->time_base); pkt->dts = av_rescale_q(pkt->dts, video_enc_ctx->time_base, out_video_stream->time_base); pkt->duration = av_rescale_q(pkt->duration, video_enc_ctx->time_base, out_video_stream->time_base); // 写入输出 av_interleaved_write_frame(out_fmt, pkt); } } } av_packet_unref(pkt); }

这段代码里有三次时间基转换，每一次都不能少。第一次是解码器到编码器，第二次是编码器到输出流，第三次是duration的转换（容易被忽略）。

6.3 常见错误与修正

错误一：忘记转换duration。AVPacket的duration字段也需要转换时间基，否则播放器计算帧时长会出错。

错误二：编码器时间基和输出流时间基不一致。有些开发者编码器用{1, 25}，输出流用{1, 1000}，但忘记转换，导致时间戳差了40倍。

错误三：音频时间基处理不当。音频的时间基通常是采样率，转换时要注意采样数和时间戳的区别。一个音频帧可能包含1024个采样，时间戳间隔是1024，不是1。

错误四：首帧PTS不为0。有些输入文件首帧PTS不是0，直接转码会导致输出文件开头有一段空白。需要在转码前记录首帧PTS，后续所有帧减去这个值做归零。

// 首帧PTS归零 static int64_t first_pts = AV_NOPTS_VALUE; if (first_pts == AV_NOPTS_VALUE) { first_pts = frame->pts; } frame->pts -= first_pts;

这个处理看似简单，但实际项目中非常必要。我做过一个批量转码工具，输入文件来源五花八门，不做归零处理的话，输出文件的时间戳乱七八糟，播放器seek都会出问题。

6.4 验证与测试

转码完成后，验证时间基处理是否正确，我通常做这几步：

1. 用ffprobe查看输出文件的流信息，确认时间基和帧率符合预期。
2. 播放输出文件，检查音视频是否同步，seek是否准确。
3. 对比输入输出文件的时长，误差应该在毫秒级以内。
4. 如果是长视频，检查中间位置和结尾位置的时间戳是否正常。

# 查看流信息 ffprobe -v error -show_entries stream=index,codec_type,time_base,r_frame_rate -of default=noprint_wrappers=1 output.flv # 查看时长 ffprobe -v error -show_entries format=duration -of default=noprint_wrappers=1 output.flv

如果发现时长偏差超过1秒，基本可以确定是时间基处理有问题。常见原因是帧率转换时的舍入误差累积，或者音频采样数计算错误。

7. 时间基处理的通用原则与个人体会

7.1 五条通用原则

经过这么多项目的打磨，我总结了时间基处理的五条通用原则，基本能覆盖90%的场景：

原则一：明确每个时间戳的时间基。拿到一个时间戳，第一件事是确认它基于哪个时间基。不确定就打印出来看，不要猜。

原则二：跨层必转换。数据在不同层级之间传递时，时间基必须转换。解码到编码要转，编码到封装要转，音频到视频要转。

原则三：保持单调递增。PTS必须单调递增，DTS在无B帧时也必须单调递增。发现回退立即排查。

原则四：首帧归零。输出文件的首帧PTS应该归零，避免播放器处理异常。

原则五：精度够用即可。不要盲目追求高精度时间基，够用就行，避免溢出和性能问题。

7.2 个人踩坑体会

时间基这个问题，看文档觉得简单，实际动手全是坑。我印象最深的一次是一个直播转码项目，音视频同步始终差200毫秒左右，排查了两天才发现是音频编码器的时间基设成了{1, 48000}，而实际采样率是44100。这个错误很隐蔽，因为48000和44100很接近，短时间看不出来，长时间才累积成明显偏差。

还有一次是做视频剪辑工具，seek总是不准，有时候偏几秒。后来发现是av_seek_frame的timestamp用错了时间基，传的是微秒但函数期望的是流时间基。改成正确的时间基后，seek精度立刻提升到帧级。

这些经历让我明白一个道理：时间基问题不会自己消失，只会以各种奇怪的现象表现出来。音画不同步、seek不准、时长错误、播放卡顿，背后都可能是时间基处理不当。与其出了问题再排查，不如在写代码时就把每个时间基转换都写清楚、测明白。

7.3 后续扩展方向

时间基处理掌握之后，可以进一步深入几个方向：一是研究FFmpeg源码里av_rescale_q的具体实现，理解它如何处理溢出和精度；二是研究不同封装格式的时间基规范，比如MP4的timescale、MKV的纳秒时间基；三是研究可变帧率视频的时间基处理，这是进阶话题；四是研究硬件编解码器的时间基处理，硬件编码器对时间基的要求可能和软件编码器不同。

这些方向每一个都值得深入，但前提是基础的时间基转换要扎实。我见过太多人跳过基础直接搞高级特性，结果问题一堆。时间基就是FFmpeg开发的基本功，练好了，后面的事情会顺很多。