8、输入Buffer优化：输入队列管理、预填充策略、PTS对齐、避免饥饿与溢出

各位同学，今天我们来聊聊硬解码中一个特别容易被忽视，但一旦出问题就让人抓狂的话题——输入Buffer优化。

说实话，我早期做视频播放器的时候，踩过不少坑。有一次在低端机上跑4K视频，解码器动不动就罢工，日志里全是"input buffer timeout"。后来才发现，根本不是解码器不行，而是我喂数据的方式有问题。嗯，今天就把这些经验掰开揉碎了讲给你听。

8.1 输入队列管理：别让解码器饿着，也别撑坏它

MediaCodec的输入队列，说白了就是一个生产者-消费者模型。你往里面塞数据，解码器从里面取数据。但这里有个关键点：解码器能同时处理的输入Buffer数量是有限的，通常只有4到8个。

我个人习惯的做法是：维护一个应用层的待解码队列，而不是直接把所有数据一股脑塞给MediaCodec。为什么？因为MediaCodec的dequeueInputBuffer()是非阻塞的，如果你塞得太快，它会返回-1，这时候你就得自己排队。

// 伪代码示例：输入队列管理
class InputBufferManager {
    private val pendingQueue = ArrayDeque<MediaPacket>()
    private val MAX_PENDING = 16  // 应用层队列上限
    
    fun feedDecoder(codec: MediaCodec) {
        while (pendingQueue.isNotEmpty()) {
            val inputIndex = codec.dequeueInputBuffer(0)  // 非阻塞
            if (inputIndex < 0) break  // 解码器队列满了
            
            val buffer = codec.getInputBuffer(inputIndex)
            val packet = pendingQueue.removeFirst()
            // 拷贝数据、设置PTS、flags
            buffer?.put(packet.data)
            codec.queueInputBuffer(inputIndex, 0, packet.size, packet.pts, packet.flags)
        }
    }
}

这里有个避坑指南：千万不要在解码线程里做I/O操作。我曾经犯过这个错——在feedDecoder()里直接读文件，结果解码线程卡住，整个播放器都跟着抖。正确的做法是：用一个单独的线程读取数据，塞到pendingQueue里，解码线程只管从队列取。

8.2 预填充策略：让解码器"热车"

你想想看，解码器刚启动的时候，内部状态是空的。如果你一上来就让它干活，它得一边初始化一边处理数据，效率肯定上不去。所以我们需要一个预填充策略。

我建议的做法是：在开始播放前，先往解码器里塞3到5帧数据，但不立即输出。等解码器内部缓冲区填得差不多了，再开始取输出。这样能显著减少启动阶段的卡顿。

// 预填充示例
fun prefillDecoder(codec: MediaCodec, packets: List<MediaPacket>) {
    val prefillCount = if (is4KVideo) 5 else 3
    for (i in 0 until prefillCount.coerceAtMost(packets.size)) {
        val inputIndex = codec.dequeueInputBuffer(10000)  // 等待最多10ms
        if (inputIndex < 0) break
        val buffer = codec.getInputBuffer(inputIndex)
        buffer?.put(packets[i].data)
        codec.queueInputBuffer(inputIndex, 0, packets[i].size, packets[i].pts, 
                               if (i == prefillCount - 1) MediaCodec.BUFFER_FLAG_CODEC_CONFIG else 0)
    }
}

8.3 PTS对齐：时间戳是解码器的"心跳"

PTS（Presentation Timestamp）这个东西，说白了就是告诉解码器"这帧数据该在什么时候显示"。如果PTS不对齐，轻则音画不同步，重则解码器直接罢工。

我记得有一次做直播项目，推流端的时间戳是从0开始的，但播放器端期望的是绝对时间戳。结果解码器输出的帧全部乱序，画面像幻灯片一样跳。后来排查了半天，才发现是PTS没有做归一化处理。

正确的做法是：所有输入到MediaCodec的PTS，必须是一个单调递增的时间序列。单位是微秒（μs），而且不能有回退。如果你从文件或网络流里拿到的PTS是乱序的，需要先做排序和重映射。

场景	PTS处理方式	注意事项
本地文件播放	直接使用文件中的PTS	确保PTS是单调递增的
直播流	从0开始，按帧率递增	需要做时间基转换
网络流（如RTSP）	使用RTP时间戳，做归一化	注意时间戳回绕问题
变速播放	PTS乘以播放速度系数	需要同步音频PTS

8.4 避免饥饿与溢出：平衡的艺术

饥饿（Starvation）和溢出（Overflow）是输入Buffer管理的两个极端。饥饿是指解码器没数据可吃，溢出是指你塞得太快把解码器撑爆了。

怎么避免？我的经验是：用水位线来控制。在应用层维护一个待解码队列，设置高水位和低水位。

• 低水位（比如队列里只剩2帧）：赶紧从网络或文件里读数据，补充进来。
• 高水位（比如队列里超过16帧）：暂停读取，等解码器消化一些再说。

你可能会问：为什么不直接用MediaCodec的队列水位？因为MediaCodec的队列太浅了（通常只有4-8个），而且你没法直接查询它还剩多少空位。所以自己维护一个应用层队列，反而更可控。

// 水位控制示例
class WatermarkController {
    private val LOW_WATER = 2
    private val HIGH_WATER = 16
    private val pendingQueue = ArrayDeque<MediaPacket>()
    
    fun shouldReadMore(): Boolean = pendingQueue.size <= LOW_WATER
    fun shouldPauseRead(): Boolean = pendingQueue.size >= HIGH_WATER
    
    fun onPacketArrived(packet: MediaPacket) {
        if (pendingQueue.size < HIGH_WATER) {
            pendingQueue.addLast(packet)
        } else {
            // 溢出处理：丢弃非关键帧，或者延迟读取
            if (!packet.isKeyFrame) return  // 丢弃非关键帧
            pendingQueue.addLast(packet)
            pendingQueue.removeFirst()  // 移除最旧的帧
        }
    }
}

8.5 知识体系总览

下面这张图总结了输入Buffer优化的核心逻辑，你可以对照着梳理自己的实现。

这张图里，数据从源头发到应用层队列，经过水位控制、PTS对齐和预填充策略的优化，再喂给MediaCodec。这三个策略是并行工作的，缺一不可。

好了，关于输入Buffer优化，今天就聊到这里。记住一句话：解码器的输入Buffer就像人的胃，你不能让它饿着，也不能让它撑着。找到那个平衡点，你的播放器就成功了一半。