24、视频变速处理：时间戳映射、帧重复与丢帧、音频变速、同步问题
各位好，今天我们来聊聊视频变速处理。这个功能在短视频App里太常见了——慢动作回放、快进剪辑，甚至那种“卡点”效果，背后都是变速算法在支撑。
说实话，我刚接触这块时也踩过不少坑。变速听起来简单，不就是把播放速度调快调慢吗？但真正动手做才发现，视频和音频的变速完全是两码事，而且它们之间的同步问题，才是真正的“拦路虎”。
变速的核心：时间戳映射
先讲最基础的概念——时间戳映射。你想想看，原始视频每一帧都有自己的时间戳，比如第10帧在时间轴上的位置是400ms。现在我们要把视频放慢到0.5倍速，那这一帧应该出现在什么时候？
答案很简单：新的时间戳 = 原始时间戳 / 播放速度。
举个例子：
原始帧时间戳：100ms, 200ms, 300ms, 400ms...
0.5倍速播放时，新时间戳：200ms, 400ms, 600ms, 800ms...
2倍速播放时，新时间戳：50ms, 100ms, 150ms, 200ms...嗯，这里要注意：时间戳映射不是简单的线性缩放。我在项目中遇到过一个问题——当变速比例不是整数时，时间戳会出现“漂移”。比如1.3倍速，原始第3帧的300ms映射到230.7ms，但实际渲染时只能取整到230ms或231ms。这种误差累积起来，几秒钟后画面就和音频对不上了。
视频变速：帧重复与丢帧
视频变速的核心操作就两个：帧重复（慢放）和丢帧（快放）。
慢放（0.x倍速）：
说白了就是帧不够用。比如0.5倍速，原本1秒25帧，现在需要50帧才能填满1秒。怎么办？重复帧。我习惯的做法是：
- 计算目标帧率下需要的总帧数
- 根据时间戳映射，找到每一帧对应的原始帧
- 如果映射到同一帧，就重复输出
快放（1.x倍速）：
反过来，帧太多了。2倍速时，1秒只需要12.5帧，但原始有25帧。那就丢帧——每隔一帧丢一帧。但要注意，不能简单粗暴地“每隔N帧丢一帧”，那样画面会卡顿。
我曾经踩过的坑：直接按固定间隔丢帧，结果运动场景出现严重的“跳跃感”。后来改用“基于时间戳的均匀采样”——先计算目标时间轴上的每个时间点，再反向查找最近的原始帧。这样丢帧更均匀，视觉上流畅很多。
音频变速：不简单
音频变速和视频完全是两码事。你不能像视频那样直接重复或丢弃采样点——那样会变调，听起来像“唐老鸭”或“大怪兽”。
音频变速的核心是保持音调不变。常用的算法有：
- WSOLA（波形相似叠加算法）：把音频切成小段，通过重叠和交叉淡入淡出实现变速。质量不错，但计算量大。
- 相位声码器：在频域处理，通过调整相位来变速。适合音乐，但对语音会有“金属感”。
- 线性插值：简单粗暴，但会变调。除非你故意要那种效果，否则别用。
我个人在Android上推荐用MediaCodec + SoundTouch的组合。SoundTouch是一个轻量级的音频变速库，支持WSOLA算法，在移动端性能表现不错。
// 伪代码示例：使用SoundTouch进行音频变速
SoundTouch soundTouch = new SoundTouch();
soundTouch.setTempo(1.5f); // 1.5倍速，音调不变
soundTouch.setPitchSemiTones(0); // 保持原调
// 读取原始PCM数据，送入SoundTouch处理
byte[] inputBuffer = readAudioChunk();
soundTouch.putSamples(inputBuffer, inputBuffer.length / 2);
// 取出变速后的数据
byte[] outputBuffer = new byte[outputSize];
int samplesOutput = soundTouch.receiveSamples(outputBuffer, outputSize);同步问题：视频和音频的“婚姻”
视频和音频各自变速后，最头疼的问题来了——同步。
你想想看，视频变速后帧率变了，音频变速后采样率变了，但它们的播放时长必须一致。否则就会出现“嘴型对不上”的尴尬情况。
我的做法是：
- 统一时间基准：视频和音频都基于同一个“播放时间轴”来计算。不要各自维护独立的时间戳。
- 音频主导同步：音频的播放是连续的，而视频是离散的帧。我习惯以音频的时间戳为基准，视频帧去匹配音频的时间点。
- 缓冲区管理：视频解码器和音频解码器各自有缓冲区。如果视频处理慢了，音频不能等，否则会卡顿。这时候可以丢一帧视频来追上音频。
一个实用的同步策略：
- 如果视频比音频快了超过50ms，就重复当前帧（慢下来）
- 如果视频比音频慢了超过50ms，就丢一帧（追上去）
- 在50ms以内，不做调整，因为人眼基本察觉不到
知识体系总览
下面这张图总结了视频变速处理的整体流程和关键点：
实战中的几个坑
最后分享几个我实际项目中遇到的坑，希望能帮你少走弯路：
- 不要用MediaPlayer直接setPlaybackParams：Android自带的变速接口在部分机型上同步效果很差，尤其是慢放时音频会失真。建议自己实现变速逻辑。
- 注意B帧的影响：如果你用MediaCodec解码，B帧会导致帧顺序错乱。变速前一定要先按PTS重新排序。
- 音频变速的延迟：WSOLA算法需要积累一定量的音频数据才能处理，这会产生几十毫秒的延迟。在直播场景中要特别注意。
- 测试要覆盖极限情况：0.25倍速和4倍速这种极端比例，很多算法会出问题。我建议在开发阶段就加入这些测试用例。
好了，关于视频变速处理的核心内容就这些。说白了就是三件事：时间戳映射、帧操作、音视频同步。每个环节都有不少细节，但掌握了这些基础，你就能应对大部分变速场景了。