2D 视频怎么显示解码成功只说明压缩数据被还原了真正让用户看到正确画面还要经过 buffer 传递、颜色转换、几何变换、时钟调度、合成和上屏。从解码帧到屏幕这条链路看似在“显示”其实同时处理四件事帧数据怎么进 GPU、颜色怎么转、几何怎么摆、时间怎么卡到屏幕刷新。1. 解码输出不一定是 RGB也不一定在 CPU移动端播放器最常见的误解是decoder 输出一块 RGB 内存OpenGL 直接画。实际链路通常不是这样。输出形式数据位置优点代价CPU YUV planesCPU memory易调试、易截图拷贝和带宽压力大CPU RGBCPU memory逻辑简单转换成本高通常不适合高分辨率播放Surface outputgraphic buffer queue低拷贝buffer 生命周期更复杂OES textureGPU external textureOpenGL 直接采样shader 和采样限制更多AHardwareBuffer跨 API 图像资源NDK / EGL / Vulkan 共享同步 fence 和格式处理复杂播放器做得好不好很多时候取决于是否减少无意义拷贝以及是否正确处理 buffer ownership。2. BufferQueue 是显示链路的隐形主角在 Android 这类系统里decoder、renderer、SurfaceFlinger 之间往往通过 buffer queue 传递图像。角色做什么producerdecoder 或 OpenGL 向队列填充 bufferconsumerrenderer、SurfaceTexture 或系统 compositor 消费 bufferacquireconsumer 拿到可读 bufferreleaseconsumer 用完后归还 bufferfence保证 GPU / display 使用完成后再复用如果队列太短容易阻塞队列太长延迟会上升。实时预览、游戏、VR/AR 会更偏低延迟普通视频播放可以接受一点队列深度换稳定性。3. YUV 到 RGB 不是固定公式YUV 的显示依赖一组约定不是看到YUV420P就能随便套一个矩阵。维度常见取值错误表现matrixBT.601 / BT.709 / BT.2020偏绿、偏红、肤色异常rangelimited / full发灰、黑位抬高、白位压缩transferSDR gamma / PQ / HLGHDR 过暗或过曝primariesBT.709 / P3 / BT.2020色域映射错误bit depth8 / 10 / 12 bitbanding、截断、格式不匹配chroma sitingleft / center色度边缘偏移从业者排查偏色时不应该只看 shader 公式还要回头看文件元数据、decoder 输出格式和系统 color pipeline 是否一致。4. OpenGL 显示到底做哪几步典型 OpenGL 视频渲染可以拆成从解码队列拿到带 PTS 的 frame 或 texture。等待或检查 acquire fence确保 GPU 可以读。绑定 YUV 多平面纹理、OES texture 或导入的 hardware buffer。设置顶点坐标和纹理坐标处理 crop、rotation、mirror、SAR/DAR。在 fragment shader 中完成采样、颜色转换和 tone mapping。绘制到 framebuffer 或中间 FBO。与字幕、UI、滤镜或转场合成。按时钟和 VSync 策略提交到 EGLSurface。release buffer 或提交 fence允许上游复用。这不是“贴图”一个动作而是一套数据、几何、颜色和同步共同参与的管线。5. 几何显示不只是宽高缩放信息用途常见错误coded sizedecoder 实际输出尺寸把 padding 当有效画面visible crop有效画面区域边缘黑边或脏数据display size期望展示尺寸拉伸或压扁SAR单个像素宽高比老片源比例异常DAR最终画面宽高比fit/fill 算错rotation横竖屏方向竖屏视频横着显示transform matrixSurfaceTexture 纹理变换上下颠倒、镜像工程上建议把“帧尺寸”“有效区域”“显示区域”分成三个概念不要用一个 width/height 贯穿到底。6. 播放时钟决定一帧什么时候上屏视频帧不能解出来就立刻画。播放器要根据主时钟判断现在是显示、等待、丢帧还是追帧。时钟策略说明适用场景audio master以音频播放位置为准普通影音播放最常见video master以视频帧节奏为准无音频或视频分析场景external clock以外部系统时钟为准投屏、直播、同步播放display vsync对齐屏幕刷新降低抖动和撕裂音画同步不是简单比较now - pts。还要考虑音频硬件延迟、decoder queue、renderer queue、SurfaceFlinger 和 panel refresh。7. 卡顿、掉帧、延迟要分开看现象可能根因排查方向周期性抖动PTS 和 VSync 节奏不匹配frame pacing、刷新率适配连续掉帧解码跟不上codec profile、分辨率、硬解负载首帧慢demux / decoder 初始化慢moov、extradata、硬解创建seek 后黑屏keyframe / flush / buffer 未清decoder flush、Surface 状态延迟高queue 太深buffer 数量、音频缓冲、同步策略偶发卡死buffer 没 releaseownership、fence、Surface 阻塞同样是“卡”可能在 demux、decode、upload、render、compositor 或 display 任一层。只盯 decoder fps 很容易误判。8. 和 3D / 360 / VR / AR 的关系2D 显示链路是后面所有沉浸式内容的底座后续主题继承 2D 的部分额外增加的复杂度3D 视频解码帧、颜色、时间戳左右眼排布和分眼显示360 视频视频纹理、PTS、颜色投影方式、球面/立方体采样VR双眼渲染、低延迟上屏头部追踪、畸变校正、reprojectionARcamera frame、GPU 合成SLAM、相机内参、真实深度遮挡所以把 2D 的 buffer、颜色、几何和时间搞清楚后面才不会把问题都误归因到“VR/AR 很玄”。一句话总结2D 显示不是解码的附属步骤而是独立的图像系统它决定帧如何进 GPU、如何按正确颜色和几何关系被画出以及何时真正出现在屏幕上。