Android MediaCodec解码器BufferInfo.presentationTimeUs时间戳乱序丢帧问题

架构老林

2026-9-27

问题成因

编码帧顺序固有差异：H.264、H.265等主流视频编码格式为了提升压缩率，会采用IPB混合帧结构，编码时的解码顺序和最终播放的显示顺序本身就不一致。部分厂商的MediaCodec硬解码实现会直接按照解码顺序返回输出缓冲区，缓冲区携带的newBufferInfo.presentationTimeUs是对应帧的原始显示时间戳，因此会出现输出帧时间戳乱序的表现。
Surface输出的底层隐式排序逻辑：当配置MediaCodec输出到Surface时，解码后的帧会直接提交给系统SurfaceFlinger服务，SurfaceFlinger内部会维护帧队列，自动按照presentationTimeUs排序后再送显，因此哪怕解码输出顺序乱序，最终观感仍然流畅，用户感知不到乱序问题。而输出到OpenGL ES时，需要开发者自行获取解码纹理渲染，跳过了系统的自动排序、同步逻辑，乱序问题就会直接暴露。
Thread.sleep丢帧的根因：用Thread.sleep控制播放速度的逻辑，默认基于「帧按时间戳递增顺序输出」的假设，当遇到乱序的、时间戳小于上一帧的帧时，要么会计算出负的等待时间直接跳过当前帧，要么会错误等待后打乱后续的播放时序，最终导致大量丢帧。

解决方案

实现帧优先级队列做重排：解码拿到每一个输出缓冲区后，不要立刻渲染，先存入一个按presentationTimeUs升序排列的优先级队列，队列大小控制在3~5帧即可，避免占用过多内存。每次渲染时从队列头部取时间戳最早的帧，即可解决乱序问题。参考代码示例：

// 解码帧实体类
static class DecodeFrame implements Comparable<DecodeFrame> {
    long presentationTimeUs;
    int textureId;
    MediaCodec.BufferInfo bufferInfo;

    @Override
    public int compareTo(DecodeFrame o) {
        return Long.compare(this.presentationTimeUs, o.presentationTimeUs);
    }
}
// 初始化优先级队列
PriorityQueue<DecodeFrame> frameQueue = new PriorityQueue<>();

替换Thread.sleep为对齐渲染回路的同步逻辑：不要用Thread.sleep做延时，而是和OpenGL的渲染回路（通常为60fps即16ms/帧）对齐，记录播放起始的系统时间和视频起始时间戳，每轮渲染前计算当前应该显示的帧时间，从排序后的队列中取最近时间的帧渲染，未到显示时间的帧留到下一轮处理即可，不需要额外加休眠逻辑。
（可选，兼容性有限）开启系统层按显示顺序输出配置：Android 6.0及以上部分设备支持在MediaCodec配置时添加相关扩展参数，强制MediaCodec按显示顺序输出帧，但是该特性厂商适配度不高，仅作为补充方案，不建议作为核心逻辑使用。

内容的提问来源于stack exchange，提问作者abirusabil