嵌入式音视频同步实战：三级FIFO解决音画不同步

1. 从一次音画不同步的翻车现场说起去年冬天我在一个车载录像项目上栽了个跟头。硬件平台是典型的ARM Linux嵌入式方案主控跑着双核Cortex-A7摄像头走MIPI接口音频从I2S麦克风阵列进来编码用硬编H.264加AAC封装成MP4存到TF卡。功能跑起来一切正常但回放的时候声音总是比画面快那么一截——大概两百毫秒左右。两百毫秒是什么概念看人说话像在看译制片嘴型对不上敲桌子的声音先到画面里的手才落下去。这个问题在嵌入式录像里太常见了常见到很多团队直接选择“忍了”。但车载场景不行事故定责的时候音频和视频的时间关系本身就是证据链的一部分。你没法跟客户解释“差两百毫秒不影响使用”。于是我开始系统性地排查整条音视频链路从驱动层的时间戳采集到编码器的帧管理再到封装时的PTS/DTS对齐一层一层往下挖。最后让我彻底解决这个问题的是一个看起来非常“老派”的方案把音频链路拆成三级FIFO。这个思路不是我的原创是跟一个做了十几年音视频固件的老工程师聊出来的。他说你们年轻人总想着用一个环形缓冲区解决所有问题但音频和视频的节奏根本不一样硬塞到一个队列里不出问题才怪。这篇文章就是那次排查和重构的完整记录。我会把音视频同步的核心原理、三级FIFO的设计思路、每一级FIFO的参数计算、时间戳对齐的具体操作以及我踩过的那些坑全部摊开来讲。如果你正在做嵌入式录像、车载DVR、安防IPC或者任何需要音视频同步的项目这篇内容应该能帮你省下至少两周的调试时间。2. 音视频同步的本质不是“同时采集”而是“同时呈现”2.1 为什么采集同步了播放还是不同步很多人第一次做音视频同步的时候会有一个直觉性的误解只要我在驱动层让音频和视频在同一时刻开始采集它们就应该同步。这个想法在理论上没错但在工程上几乎不可能实现。原因在于音频和视频的采集机制完全不同。视频是“帧驱动”的摄像头按照固定的帧率比如30fps往外吐数据每一帧对应一个精确的采集时刻。音频是“流驱动”的I2S麦克风按照采样率比如48kHz连续不断地产生样本它没有“帧”的概念只有样本计数。更麻烦的是这两条链路在SoC内部走的是不同的总线、不同的DMA通道、不同的中断优先级。视频帧到达DDR的时刻和音频样本块到达DDR的时刻天然就存在抖动。这个抖动可能只有几毫秒也可能因为系统负载波动达到几十毫秒。所以音视频同步的本质不是“同时采集”而是“同时呈现”。也就是说你需要在播放端建立一个统一的时间基准让音频和视频都按照这个基准来调度自己的输出。这个基准就是时间戳。2.2 时间戳从哪来V4L2和ALSA的采集时间在Linux嵌入式系统里视频采集通常走V4L2框架音频采集走ALSA框架。这两个框架都提供了获取采集时间戳的接口但用法和精度差异很大。V4L2的时间戳通过struct v4l2_buffer的timestamp字段返回。你需要在VIDIOC_QUERYBUF之后、VIDIOC_QBUF之前确保驱动填充了这个字段。常用的时间戳类型有两种V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC和V4L2_BUF_FLAG_TIMESTAMP_COPY。前者是驱动在采集完成时打的单调时钟时间戳后者是驱动直接拷贝用户空间传入的时间戳。做同步必须用MONOTONIC类型因为它是系统启动以来的纳秒数不受系统时间调整的影响。ALSA的时间戳获取稍微麻烦一点。你可以通过snd_pcm_status_get_tstamp()获取最后一次硬件中断的时间戳也可以通过snd_pcm_htimestamp()获取高精度时间戳。但要注意ALSA的时间戳精度依赖于声卡的时钟源有些廉价Codec的时钟抖动很大需要做滤波处理。我实测下来V4L2的MONOTONIC时间戳精度通常在微秒级ALSA的htimestamp精度在几十微秒级。对于音视频同步来说这个精度足够了因为人眼对音画不同步的感知阈值大约在±80毫秒左右我们只需要把误差控制在±20毫秒以内就能做到“无感”。2.3 同步策略选型音频主时钟还是视频主时钟确定了时间戳来源之后下一步是选择同步策略。常见的策略有三种策略基准优点缺点适用场景音频主时钟音频播放速率音频对抖动敏感人耳对音频断续极敏感视频需要丢帧或补帧画面可能卡顿录音笔、语音通话视频主时钟视频帧率画面流畅音频需要重采样可能产生变调监控预览、视频会议外部时钟系统单调时钟音视频独立调整互不影响实现复杂需要精确的时钟模型专业录像、车载DVR车载录像场景我最终选了外部时钟策略也就是以系统单调时钟为基准音频和视频各自根据自己的时间戳去对齐这个基准。这样做的好处是音频和视频的调整是解耦的不会因为视频丢帧导致音频变调也不会因为音频重采样导致画面卡顿。但外部时钟策略对缓冲区管理的要求极高。如果音频和视频的数据各自放在一个简单的环形缓冲区里你很难精确控制“当前应该播放哪一帧”。这就是三级FIFO要解决的问题。3. 三级FIFO的设计把音频链路拆开看3.1 为什么一个FIFO不够用在最初的版本里我的音频链路是这样的I2S驱动通过DMA把音频样本搬到一块环形缓冲区编码线程从环形缓冲区里读数据攒够一帧AAC的量比如1024个样本就送去编码编码完成后把AAC帧和对应的时间戳一起送给封装线程。这个结构看起来没问题但它有一个致命的缺陷环形缓冲区里混放了“未编码的PCM样本”和“已编码的AAC帧”两种完全不同节奏的数据。PCM样本是连续不断的AAC帧是离散的。当编码线程因为系统调度延迟没有及时读取时环形缓冲区会溢出导致PCM样本丢失。而PCM样本丢失的直接后果就是音频时间戳和实际内容错位。更隐蔽的问题是编码线程从环形缓冲区读取数据时它拿到的时间戳是“缓冲区里最早那个样本的时间戳”。但如果缓冲区里积压了多帧数据这个时间戳和当前正在编码的数据之间就存在偏差。这个偏差会随着系统负载波动而变化导致音频时间戳忽快忽慢。三级FIFO的思路就是把这条链路拆成三个独立的阶段每个阶段用独立的FIFO管理每个FIFO只负责一种数据节奏。3.2 第一级FIFO驱动层到用户空间的PCM缓冲第一级FIFO位于内核驱动和用户空间之间我把它叫做“采集FIFO”。它的作用是平滑I2S DMA中断到用户空间读取之间的抖动。这一级FIFO的实现方式取决于你的驱动架构。如果驱动支持mmap你可以直接在用户空间映射DMA缓冲区然后用一个无锁环形队列来管理读写指针。如果驱动只支持read()你需要在用户空间开一个足够大的缓冲区用一个独立线程专门负责从驱动读取数据。这一级FIFO的关键参数是缓冲深度。缓冲太浅系统调度延迟会导致溢出缓冲太深会增加音频的端到端延迟。我的经验值是缓冲深度 采样率 × 最大调度延迟 × 安全系数。假设采样率48kHz最大调度延迟20ms安全系数2那么缓冲深度 48000 × 0.02 × 2 1920个样本。实际配置时取2的整数次幂也就是2048个样本。注意这一级FIFO里存放的是纯PCM样本不包含任何时间戳信息。时间戳在这一级是“隐含”的通过样本计数来推算。每读取N个样本就对应一个精确的时间增量。3.3 第二级FIFOPCM到编码器的帧对齐缓冲第二级FIFO位于PCM读取线程和编码线程之间我把它叫做“帧对齐FIFO”。它的作用是把连续的PCM样本流切分成编码器需要的固定帧长。AAC编码器通常要求每帧1024个样本对于48kHz采样率约21.3ms。但I2S驱动吐出的PCM样本块大小可能不是1024的整数倍比如DMA每次搬运512个样本。如果直接把512个样本送给编码器编码器会报错或者内部缓存导致时间戳计算混乱。帧对齐FIFO的做法是PCM读取线程把样本写入FIFO编码线程从FIFO里读取恰好1024个样本。如果FIFO里的样本不足1024个编码线程就等待如果超过1024个就精确读取1024个剩余的留在FIFO里。这一级FIFO的关键参数是帧长对齐和时间戳绑定。每从FIFO里读出一帧1024个样本就要根据这一帧第一个样本的采集时间戳计算出这一帧的呈现时间戳。计算公式如下frame_pts first_sample_pts (frame_index × frame_duration)其中frame_duration是帧长除以采样率单位是纳秒。对于1024个样本、48kHz采样率frame_duration 1024 / 48000 × 1e9 ≈ 21,333,333纳秒。实操心得时间戳计算一定要用64位整数单位统一用纳秒。我见过有人用毫秒做单位结果累积误差在几分钟后就超过了100毫秒。另外first_sample_pts要从第一级FIFO的样本计数精确推算不能直接用系统当前时间否则会引入读取线程的调度延迟。3.4 第三级FIFO编码后到封装前的帧队列第三级FIFO位于编码线程和封装线程之间我把它叫做“编码帧FIFO”。它的作用是缓冲已编码的AAC帧等待封装线程按照时间戳顺序取走。这一级FIFO里存放的是完整的AAC帧每一帧都带有精确的PTS。封装线程从FIFO里取帧时不是简单地按先进先出顺序取而是要根据视频帧的时间戳来决定什么时候取哪一帧。具体来说封装线程维护一个“当前封装时间”mux_time它从0开始按照音视频帧的时间戳递增。当mux_time到达某个音频帧的PTS时就把这个音频帧写入MP4当mux_time到达某个视频帧的PTS时就把这个视频帧写入MP4。如果音频帧的PTS落后于mux_time太多比如超过50毫秒说明音频编码跟不上需要丢帧如果音频帧的PTS超前于mux_time太多说明音频编码太快需要等待。这一级FIFO的关键参数是队列深度和丢帧阈值。队列深度决定了能容忍多大的编码抖动我通常设置为8到16帧。丢帧阈值决定了什么时候放弃一帧我设置为50毫秒超过这个值就丢弃避免累积延迟。3.5 三级FIFO的联动时间戳如何贯穿始终三级FIFO不是孤立的它们通过时间戳这条线串联起来。第一级FIFO的样本计数决定了第二级FIFO的帧PTS第二级FIFO的帧PTS决定了第三级FIFO的队列排序第三级FIFO的队列排序决定了封装时的音视频交错顺序。整个链路的时间戳传递可以用一个简单的公式概括audio_frame_pts base_pts (total_samples_consumed / sample_rate) × 1e9其中base_pts是音频采集启动时的系统单调时钟时间total_samples_consumed是从启动到现在总共消耗的样本数。这个公式保证了音频时间戳的单调性和线性性不受任何调度抖动的影响。视频链路也采用类似的公式但视频的时间戳直接来自V4L2的buffer timestamp不需要额外计算。封装线程拿到音频和视频的PTS后按照PTS从小到大排序依次写入MP4的sample table。4. 实操过程从驱动配置到封装对齐4.1 驱动层V4L2和ALSA的时间戳配置视频采集的V4L2配置需要注意几个关键点。首先在VIDIOC_REQBUFS时选择V4L2_MEMORY_MMAP模式这样驱动会在采集完成时自动填充timestamp字段。其次在VIDIOC_QBUF之前检查v4l2_buffer.flags是否包含V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC如果没有需要在驱动层强制设置。struct v4l2_buffer buf; memset(buf, 0, sizeof(buf)); buf.type V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory V4L2_MEMORY_MMAP; buf.index i; if (ioctl(fd, VIDIOC_QUERYBUF, buf) 0) { perror(VIDIOC_QUERYBUF); return -1; } if (!(buf.flags V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC)) { fprintf(stderr, Warning: driver does not support MONOTONIC timestamp\n); }音频采集的ALSA配置稍微复杂一些。你需要先通过snd_pcm_hw_params()设置采样率、通道数和格式然后通过snd_pcm_sw_params()设置启动阈值和停止阈值。时间戳的获取在snd_pcm_readi()之后调用snd_pcm_htimestamp()。snd_pcm_sframes_t frames snd_pcm_readi(capture_handle, buffer, frame_size); if (frames 0) { frames snd_pcm_recover(capture_handle, frames, 0); } snd_htimestamp_t tstamp; snd_pcm_htimestamp(capture_handle, avail, tstamp); uint64_t audio_pts tstamp.tv_sec * 1000000000ULL tstamp.tv_nsec;注意snd_pcm_htimestamp()返回的是最后一次硬件中断的时间戳它对应的是缓冲区中“最新”样本的采集时间而不是你刚刚读取的那批样本的时间。你需要根据缓冲区里的样本数反推读取样本的时间戳。具体做法是read_pts htimestamp - (buffered_samples / sample_rate) × 1e9。4.2 第一级FIFO的实现无锁环形队列第一级FIFO我用了一个经典的无锁环形队列生产者是ALSA读取线程消费者是PCM帧对齐线程。队列的每个元素是一个样本块块大小固定为256个样本。#define FIFO1_DEPTH 2048 #define BLOCK_SIZE 256 typedef struct { int16_t data[BLOCK_SIZE * 2]; // 立体声 uint64_t pts; } audio_block_t; typedef struct { audio_block_t blocks[FIFO1_DEPTH / BLOCK_SIZE]; volatile uint32_t write_idx; volatile uint32_t read_idx; } fifo1_t;写入时ALSA线程把读取到的样本按256个一组切分每组附带一个根据htimestamp推算的PTS然后写入队列。读取时帧对齐线程从队列里取出样本块累积到1024个样本后送给编码器。这个队列的关键是内存屏障。在ARM架构上写入write_idx之前必须执行__sync_synchronize()否则消费者可能看到新的索引但读到旧的数据。4.3 第二级FIFO的实现帧对齐与PTS绑定第二级FIFO是一个简单的样本缓冲区但它需要精确管理PTS。我的做法是维护一个sample_counter每写入一个样本就递增。当累积到1024个样本时计算这一帧的PTSuint64_t frame_pts base_pts (sample_counter * 1000000000ULL) / sample_rate; sample_counter 1024;这里base_pts是音频采集启动时的单调时钟时间sample_rate是48000。这个公式保证了PTS的精确性和单调性。实操心得sample_counter必须用64位无符号整数因为48kHz采样率下运行24小时会产生约41亿个样本32位整数会溢出。溢出后的PTS会突然跳变导致封装线程疯狂丢帧。4.4 第三级FIFO的实现编码帧队列与封装调度第三级FIFO是一个带优先级的队列元素是AAC帧和对应的PTS。封装线程从队列里取帧时不是简单地取队首而是扫描整个队列找到PTS最接近mux_time的那一帧。typedef struct { uint8_t *data; size_t size; uint64_t pts; } aac_frame_t; aac_frame_t *find_best_frame(fifo3_t *fifo, uint64_t mux_time) { aac_frame_t *best NULL; uint64_t min_diff UINT64_MAX; for (int i 0; i fifo-count; i) { uint64_t diff (fifo-frames[i].pts mux_time) ? (fifo-frames[i].pts - mux_time) : (mux_time - fifo-frames[i].pts); if (diff min_diff) { min_diff diff; best fifo-frames[i]; } } return best; }如果min_diff超过50毫秒说明队列里没有合适的帧封装线程就等待或者插入静音帧。如果队列满了超过16帧就丢弃PTS最旧的那一帧。4.5 封装层MP4的sample table与交错写入MP4封装的关键是sample table的构建。每个音频帧和视频帧都要在sample table里记录它的offset、size、duration和PTS。封装线程按照PTS顺序交替写入音频和视频帧确保播放器能正确解码。void mux_frame(mp4_muxer_t *muxer, uint8_t *data, size_t size, uint64_t pts, int is_video) { uint32_t offset muxer-current_offset; fwrite(data, 1, size, muxer-fp); muxer-current_offset size; if (is_video) { add_video_sample(muxer, offset, size, pts); } else { add_audio_sample(muxer, offset, size, pts); } }注意MP4的PTS单位是“timescale”通常是90000视频和48000音频。你需要把纳秒时间戳转换成对应的timescale单位。转换公式是pts_in_timescale pts_ns * timescale / 1e9。这个转换必须用64位整数否则会丢失精度。5. 常见问题与排查技巧实录5.1 音频时间戳跳变从溢出到时钟源音频时间戳跳变是最常见的问题表现是封装后的MP4里音频时长和视频时长不一致或者播放器报告“音频时间戳不连续”。排查思路分三步走。第一步检查sample_counter是否溢出。48kHz采样率下32位无符号整数在约24.8小时后溢出。如果你用的是32位计数器改成64位。第二步检查ALSA的htimestamp是否稳定。有些Codec的时钟源抖动很大htimestamp会在几毫秒范围内波动。你可以用滑动平均滤波来平滑它。第三步检查系统单调时钟是否被调整。如果系统启动了NTP同步单调时钟可能会被微调导致PTS基准漂移。解决办法是使用CLOCK_MONOTONIC_RAW它不受NTP调整影响。5.2 视频帧时间戳与音频帧时间戳的基准不一致这个问题很隐蔽表现是音视频各自单独播放都正常但合在一起就不同步。原因是视频的V4L2时间戳和音频的ALSA时间戳可能来自不同的时钟源。V4L2的MONOTONIC时间戳通常来自ktime_get_ts()而ALSA的htimestamp可能来自声卡的独立时钟。这两个时钟的频率可能有微小差异比如视频时钟是1GHz音频时钟是1.0001GHz。运行一小时后累积误差可能达到几百毫秒。解决办法是在启动时记录两个时钟的初始偏移然后在运行过程中定期校准。我的做法是每10秒计算一次音频PTS和视频PTS的差值如果差值超过10毫秒就调整音频的base_pts来补偿。5.3 编码器延迟导致的PTS偏移AAC编码器通常有内部缓存比如FAAC编码器会缓存一帧的样本。这意味着你送给编码器的第一帧1024个样本编码器可能要到第二帧才输出。如果你直接用输入样本的PTS作为输出帧的PTS就会引入一帧的延迟约21毫秒。解决办法是在编码器初始化后先送一帧静音样本“预热”然后从第二帧开始正式计算PTS。或者在编码器输出帧时根据编码器的内部延迟补偿PTS。5.4 系统负载波动导致的FIFO溢出嵌入式系统的CPU负载波动很大尤其是当视频编码和音频编码同时运行时。如果音频读取线程被视频编码线程抢占超过20毫秒第一级FIFO就可能溢出。解决办法有两个。一是提高音频读取线程的优先级用pthread_setschedparam()设置为SCHED_FIFO优先级设为80比视频编码线程高。二是增大第一级FIFO的深度从2048个样本增加到4096个样本代价是增加约42毫秒的端到端延迟。实操心得在ARM Linux上SCHED_FIFO线程如果长时间占用CPU会触发内核的RT throttling导致整个系统卡死。我的做法是给音频线程设置一个合理的CPU亲和性绑定到CPU0视频编码线程绑定到CPU1避免相互抢占。5.5 常见问题速查表现象可能原因排查方法解决方案音频比视频快200ms音频PTS基准错误检查base_pts是否用了系统当前时间改用采集启动时的单调时钟音频时间戳跳变sample_counter溢出检查计数器位宽改用64位计数器音视频各自正常但合起来不同步时钟源不一致比较V4L2和ALSA的时间戳差值定期校准base_pts音频断续第一级FIFO溢出检查读取线程优先级提高优先级或增大FIFO深度封装后音频时长偏短编码器延迟未补偿检查编码器输出帧数预热编码器或补偿PTS播放器报告时间戳不连续MP4 timescale转换错误检查转换公式用64位整数转换6. 一些关于时间戳和FIFO的零碎经验三级FIFO的方案跑通之后我又在几个不同的硬件平台上做了移植包括全志R16、瑞芯微RV1109和星宸SSC338Q。每个平台的驱动行为都有差异但三级FIFO的框架没有变过。这说明这个设计是足够通用的。有一个细节值得单独提一下时间戳的单位统一用纳秒但在MP4封装时视频的timescale通常是90000音频是48000。从纳秒转到timescale时除法会引入舍入误差。我的做法是先乘后除并且用64位中间变量。比如pts_90000 (pts_ns * 90000) / 1000000000这样精度损失最小。另外如果你用的是硬件编码器比如瑞芯微的MPP或者星宸的VENC编码器输出的帧可能不带PTS需要你自己根据输入帧的PTS来推算。这时候要注意编码器的帧重排序B帧输出顺序和输入顺序可能不一致。解决办法是禁用B帧或者维护一个PTS映射表。最后说一个调试技巧在开发阶段我会在每一级FIFO的入口和出口打印时间戳和队列深度用fprintf(stderr, ...)输出到串口。虽然会影响性能但能直观地看到时间戳的流动和队列的积压情况。等调通之后再关掉这些打印。这个方案后续还可以扩展的地方是支持多路音频输入比如麦克风阵列的波束成形以及支持可变帧率的视频编码。多路音频的情况下每一路都需要独立的三级FIFO然后在封装层做混音和时间戳对齐。可变帧率的情况下视频的PTS不再是等间隔的封装线程需要更复杂的调度逻辑。这些我还在摸索中等有成熟方案了再写出来分享。