28、MCU 调试：分析 MCU 的混流日志，验证音视频同步和布局切换
MCU 的混流，说白了就是把多路音视频揉成一轨输出。听起来简单，但实际调试起来，坑不少。我见过太多人盯着日志看半天，愣是没发现音视频不同步，或者布局切换后画面错位。今天我就带你手把手分析混流日志，把那些隐藏的问题揪出来。
28.1 混流日志里到底藏着什么？
MCU 的日志，其实就三块核心信息：
- 输入流状态：每路参与者的视频分辨率、帧率、音频采样率
- 混流决策：布局切换的触发条件、时间点
- 输出流参数：合成后的视频宽高、音频编码参数、时间戳对齐情况
我个人习惯，拿到日志先搜三个关键词：Mixer::AddInput、LayoutChange、SyncOffset。这三个基本能覆盖 80% 的问题。
核心原则：混流日志的每一行时间戳，都必须能对应到实际音视频帧的 RTP 时间戳。对不上，就是不同步。
28.2 音视频同步验证：别被时间戳骗了
音视频同步，不是看两个时间戳数值相等，而是看它们的 播放时间差。MCU 混流时，各路输入的音频和视频可能来自不同时钟域，日志里会记录一个 SyncOffset 字段。
举个例子，我在项目中遇到过这样的情况：
[Mixer] SyncOffset: video_ts=4523000, audio_ts=4523100, diff=100ms
乍一看 diff 只有 100ms，好像还行？但注意，这个 diff 是 累积偏移。如果它持续增长，说明时钟漂移了。我建议你画个趋势图，看 diff 是否在 ±50ms 内波动。超过 200ms，用户就能感觉到嘴型对不上。
我的小技巧：在日志里加一个 SyncCheck 标记，每 5 秒输出一次当前所有输入流的同步状态。这样一眼就能看出哪路流在飘。
验证步骤很简单：
- 找到日志中
Mixer::OutputFrame行，记录 video_ts 和 audio_ts - 计算差值，单位毫秒
- 连续看 10 个输出帧，如果差值波动超过 100ms，说明同步有问题
28.3 布局切换：日志里的“断点”
布局切换，是 MCU 调试里最容易出视觉 bug 的地方。日志里会记录类似这样的信息：
[LayoutManager] SwitchTo: grid_2x2, triggered_by: speaker_change
[LayoutManager] Previous: grid_1x1, transition_duration: 300ms
这里要注意两个点：
- 触发时机：是说话人变化触发的，还是手动触发的？如果是说话人变化，日志里应该紧跟着
ActiveSpeaker事件 - 过渡时间：
transition_duration是 MCU 内部做画面过渡的时间。如果这个值太大，用户会看到黑屏或画面闪烁
我曾经踩过一个坑：布局切换后，某一路视频的分辨率没跟着变。日志里显示：
[Mixer] Input[3]: res=640x480, target_res=320x240
[Warning] Resize failed: input[3] not ready
嗯，这里要注意，MCU 在切换布局时，如果某路输入还没准备好新的分辨率，它会直接复用旧分辨率。结果就是画面里一个大一个小，非常难看。
避坑指南：我曾经因为布局切换后忘记检查所有输入流的分辨率，导致线上会议出现“画中画里有个小窗是模糊的”。后来我加了一个 LayoutValidation 步骤，每次切换后强制所有输入重新协商分辨率。
28.4 实战：从日志里揪出不同步
我给你看一段真实的混流日志片段：
10:00:01.234 [Mixer] Input[0] video: ts=1000, pts=1000
10:00:01.234 [Mixer] Input[0] audio: ts=1050, pts=1050
10:00:01.234 [Mixer] SyncOffset: video_pts=1000, audio_pts=1050, diff=50ms
10:00:01.534 [Mixer] Input[0] video: ts=1500, pts=1500
10:00:01.534 [Mixer] Input[0] audio: ts=1600, pts=1600
10:00:01.534 [Mixer] SyncOffset: video_pts=1500, audio_pts=1600, diff=100ms
10:00:01.834 [Mixer] Input[0] video: ts=2000, pts=2000
10:00:01.834 [Mixer] Input[0] audio: ts=2200, pts=2200
10:00:01.834 [Mixer] SyncOffset: video_pts=2000, audio_pts=2200, diff=200ms
看到了吗？diff 从 50ms 涨到了 200ms，而且还在涨。这说明音频时钟比视频时钟快。原因可能是音频采样率漂移，或者视频帧率不稳定。
我的处理方法是：
- 检查输入源的音频采样率是否稳定（日志里搜
AudioClockDrift） - 如果漂移超过 5%，建议在 MCU 侧做音频重采样
- 如果视频帧率波动大，考虑在混流前加一个视频帧率平滑器
28.5 布局切换的日志分析流程图
下面这张图，是我自己调试时用的逻辑。每次布局切换，我都按这个流程走一遍：
28.6 常见问题速查表
| 日志关键词 | 可能的问题 | 我的建议 |
|---|---|---|
SyncOffset 持续增长 |
时钟漂移，音视频不同步 | 检查输入源的时钟，考虑做音频重采样 |
Resize failed |
输入流分辨率不匹配 | 强制输入流重新协商分辨率 |
transition_duration > 500ms |
布局切换卡顿 | 优化过渡算法，或者降低过渡帧率 |
Input not ready |
输入流未就绪就切换布局 | 加一个等待机制，等所有输入流就绪再切换 |
我的经验：调试 MCU 混流，最怕的就是“偶现”。我一般会在日志里加一个 MixerHealth 标记，每 10 秒输出一次所有输入流的同步状态和布局信息。这样即使问题复现不了，也能从历史日志里找到线索。
好了，关于 MCU 混流日志的分析，今天就聊到这儿。你下次调试时，记得先看 SyncOffset，再看布局切换的过渡时间。这两块搞定了，大部分问题都能迎刃而解。