[转] 如何处理libva加速元件的显示：(vaPutImage)（1）

通常，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 */
);

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

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

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

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

 

 

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/moblin/archive/2008/12/17/3540720.aspx