一 背景回顾上篇结尾说解码的 13.85ms 另有隐情这篇填坑。13.85ms 里真解码只有 0.5ms解块Detileblock-linear-pitch-linear占了约 13.3ms。Block-LinearBL块线性和Pitch-LinearPL行线性/扫描线是图像数据两种内存布局之所以同时存在根本原因在于图像处理GPU/渲染/采样与图像传输显示输出/DMA/连续内存读写在硬件缓存Cache命中率与总线吞吐效率上的矛盾。通常GPU 中图像处理用 BL 布局而 CPU/显示用 PL 布局。二 方案选择端侧多个硬件模块支持解块之前考虑用 GPU 解块但是 GPU 的引入会使代码复杂而且有“杀鸡用牛刀”的感觉解块是固定套路的搬运活不值得占用 GPU。最终选择片上专用硬件模块做 NV12 BL→ARGB 转换。原则就是能下放给专用硬件的就别让通用算力干。新的 pipeline 如下图1手关键点检测处理流程三 调试过程遇到的坑3.1 多平面格式跨硬件拷贝的 plane offset 陷阱前期做视频解码后的 NV12 BL 上屏验证过程中遇到问题屏幕虽然能显示动画但画面错位。这是典型的 Y 数据对UV 数据不对的症状。查看代码我直接用 memcpy 把 decoder 后的 buffer 送到显示 buffer但事实上 decoder buffer 的大小和显示 buffer 不一样解码[Y data][UV data]显示[Y data][16KB pad][UV data]根因不同硬件模块对 NV12/NV21/I420 的 plane offset 假设不一致这个坑在 Qualcomm UBWC、ARM AFBC 等都会遇到。3.2 Cache 的两面性memcpy 慢了 40x在做解码到显示 buffer 拷贝时因为没有设置解码 buffer 的 cache enable导致 profile 时候发现 memcpy 拷贝一帧3.4MB需要 5.6ms这远慢于 CPU 内存拷贝的正常水平调试发现是解码 buffer 属性没有 cache enable。显示黑屏视频解码成功显示也没有错误但是屏幕黑屏无任何显示。调试发现 cache line 有数据但内存中没有。根因同一个参数cpuCache在不同方向表现出不同的行为读设置错“慢”写设置错“黑”。3.3 方法论渐进式验证调试过程中还有其他问题不具体描述。实现的时候遵循纯色填充→单引擎工作→多引擎级联。纯色填充验证显示支持 ARGB/NV12 PL 等格式。单引擎工作分别验证解码/硬件颜色空间转换/显示等各硬件引擎能工作。整个处理流程级联起来嵌入式 GPU/VPU 等调试挂死就要重启直接端到端联调成本极高四 实验结果优化前后对比阶段优化前耗时(ms)优化后耗时(ms)视频解码13.850.97颜色空间转换(NV12-RGB)4.230.81去Alpha planeN/A1.6手掌模型预处理1.481.44手掌检测推理0.710.70手掌检测后处理0.040.04关键点模型预处理3.453.42关键点检测1.171.15关键点后处理1.91.88显示提交4.154.15(沿用之前测试数据)总耗时30.9816.16NOTE受显示硬件 30Hz 限制实际可观测帧率上限为 30fps换 60Hz 显示硬件后预计可达 60fps。硬件模块颜色空间转换输出的是 ARGB比模型要的 RGB 多一个 Alpha 通道得剥掉1.6ms——即便如此总账还是赚的。优化后视频解码颜色空间转换去 Alpha plane3.5msdump 第 100 帧如下图2第100帧手关键点检测结果图左上角 OSD 消息显示帧率 81FPS 是没有上屏的结果。五 心得总结到此MediaPipe 端侧移植和优化做阶段性总结第一篇移植不在翻译代码在胶水代码第二篇瓶颈不在模型在等屏幕本篇瓶颈不在解码在解块回头看端侧模型优化就是不断把活儿交还给合适的硬件往前看摄像头接入整个 pipeline真正做到“实时看世界”