如何为 libva 加速元件处理显示的3点差异!

本文探讨了在使用LibVA硬件加速时,如何解决GStreamer管道中的视频解码器与接收器之间的数据传递问题。提出了三种解决方案,包括从LibVA拷贝解码数据、将视频过滤器更改为视频接收器以及实现杂波视频接收器。

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

gstreamer 管道是一个数据处理链 其中有一个源元件创建 读取 数据 还有一个接收器元件使用这些数据 或者将这些数据显示到屏幕或输出到扬声器 ); 另外 在源元件和接收器元件之间还有各种过滤器元件 这些过滤器元件既有 sink pad 又有 src pab

视频解码器是一种常见的过滤器,它从上游(分离器/分流器)接收数据,并将数据发送到视频接收器(通常为 x-image-sink)。但是,当存在某种硬件加速机制时,情况稍有不同(对于 libva 而言尤其如此)。在这种情况下,一般使用 libva 来处理最终渲染 (vaPutImage),但下游过滤器/接收器元件(在典型的 gstreamer 管道中)“需要”来自视频过滤器的数据。如何消除这种差异呢? 在此,我有 3 个建议:

library/libva/video-memory 拷回解码数据

这可能损害性能但却是最简单的方式。

/*
* Map data store of the buffer into the client's address space
* vaCreateBuffer() needs to be called with "data" set to NULL before
* calling vaMapBuffer()
*/
VAStatus vaMapBuffer (
VADisplay dpy,
VABufferID buf_id, /* in */
void **pbuf /* out */
);
/*
* After client making changes to a mapped data store, it needs to
* "Unmap" it to let the server know that the data is ready to be
* consumed by the server
*/
VAStatus vaUnmapBuffer (
VADisplay dpy,
VABufferID buf_id /* in */
);

·                 客户端插件可以通过 vaMapBuffer 访问解码数据如果您将数据重新复制到 userspace/video-filter-element那么对 gstreamer 的影响很小——所有其他元件都能照常工作。但是,您肯定会因为执行内存复制而损害性能(这里执行了复制操作,之后还可能针对视频接收器元件再次执行)。

·                 客户端插件可以通过 vaMapBuffer 访问解码数据在此我们不进行复制但之后的过滤器/接收器元件应该知道这是一个 vaImage 缓冲器而不是常见的数据缓冲器是否需要?)。在接收器元件使用该缓冲器之后,我们可以通过 vaUnmapBuffer 将缓冲器重新释放到 library/libva 但是我认为从 vaBuffer gfx framebuffer 可能存在捷径。当您尝试走捷径时也会损害性能。

·                 如果下游过滤器元件对 vaImage 没有太大的影响我们可以修改 x-image-sink使其使用 vaPutImage 来显示图像。
此假设有没有例外情况? 可以通过 vaPutImage2() 执行缩放。

无论如何我们将首先尝试第一种方式。

将视频过滤器更改为视频接收器

既然 libva 能够处理图片显示为什么不让它完成此项工作呢那样我们的视频过滤器元件就将更改为视频接收器元件——在视频-解码器-过滤器元件的后面将不需要其他过滤器元件和接收器元件。
这违背了 gstreamer 基础结构的常识。我们需要在视频-过滤器-解码器内部进行缩放、颜色转换和本机窗口处理。 这增加了模块的复杂性。
在粗略地浏览 ximagesink.c 之后我有了一些基本的想法
可以使用 gst_ximagesink_get_times() 处理计时。
向回调处理程序注册 gst_ximagesink_show_frame:
2156: gstbasesink_class->preroll = GST_DEBUG_FUNCPTR (gst_ximagesink_show_frame);
2157: gstbasesink_class->render = GST_DEBUG_FUNCPTR (gst_ximagesink_show_frame);

杂波视频接收器

我们必须考虑杂波在此框架中的角色它是 moblin 2.0 的目标视频接收器。
我假设杂波可以处理 VAImageID 而不是 gst 的数据缓冲器。
这样我们就可以提供杂波视频接收器 VAImageID,并且使 gst 数据缓冲器处于闲置状态。杂波视频接收器将访问 libva 以显示图像 (vaPutImage)。我们让 vaPutImage2 执行缩放。
还有差异吗?不确定。我们应该使杂波视频接收器的源 pad 成为动态 pad 以改进兼容性吗?

 



本文译自Intel Moblin.org社区
更多内容,请点击“Moblin技术”专区

 
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值