ffmpeg d3d11va 加速访问帧出现帧混乱 flush

最新推荐文章于 2025-06-20 14:32:55 发布

原创最新推荐文章于 2025-06-20 14:32:55 发布 · 3.6k 阅读

4 ·

CC 4.0 BY-SA版权

文章标签：

#d3d11va #ffmpeg #帧混乱 #flush

dirextx 同时被 2 个专栏收录

8 篇文章

订阅专栏

ffmpeg

1 篇文章

订阅专栏

使用ffmpeg d3d11va时出现帧时序混乱问题。ffmpeg用d3d11va时frame数据存放有特点，按常规取图方式耗时。分析发现D3d有命令缓冲机制，猜测多线程操作导致pipeline stall。在copysubresourceregion后加入flush命令解决问题，且copysubresouce有两帧延时。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

使用ffmpeg d3d11va的时候出现帧的时序上混乱。
通过ffmpeg 源码可知，ffmpeg 用d3d11va 时出来的frame 中的data[0]存放的是decode texture数组（默认大小为20），data[1] 存放下标（可以发现，貌似下标总是一个随机的值，没调试进去，所以没有发现在哪里修改下标，不过通过下表访问的数据是没错的）。decode texture是在显存上的一个纹理，但是如果按demo中的方式去取图像，他需要先创建一个staging 类型的 texture ，再将decode texture拷贝到staging类型的 texture，再将staging 类型的texture中的内容map出来，这是极为消耗时间的。我的操作是直接decode texture放到我的default类型的render texture中。开始的时候出现问题帧时序上的问题。但是如果调用ffmpeg demo中的原始的代码，却没有出现这个问题。

查了一通，发现这里。

大概意思就是： D3d中有一个内部的命令缓冲（command list）机制，这个机制能减少用户态和内核态的切换。很多函数执行完后，会暂时将操作放到command list中，后续command list会高效的去执行。有以下几个操作能让command list立马执行完。

猜测因为ffmpeg d3d11va 中解码时在内部有开启子线程。多线程操作导致了在 copysubresource 时，产生了pipeline stall。
于是在copysubresourceregion后加入flush 命令，果然就没有这个问题了。下面的lock是必须加上的。

D3D11_BOX box; box.back = 1, box.front = 0, box.left = 0, box.right = descT.Width, box.top = 0, box.bottom = descT.Height;
ctx1->lock(ctx1->lock_ctx);
dctx->CopySubresourceRegion(frame->m_d3DTextureFfmpeg, 0, 0, 0, 0, (ID3D11Texture2D*)m_frame->data[0], currentFrameIndex,&box); //may be we can use the buffer in the frame directly
dctx->Flush(); //清空缓冲命令 //https://docs.microsoft.com/zh-cn/windows/desktop/api/d3d11/nf-d3d11-id3d11devicecontext-flush
ctx1->unlock(ctx1->lock_ctx);

值得注意的是copysubresouce 大概是有两帧的延时：