use dma_buf handle for hw video frames

[Zhao, Halley]

Thanks, I want to check whether my idea is possible.

I know that there is GstDMABufAllocator, which is used in v4l2src; but seems glsink hasn’t used it yet.
It is not so important for the gap of one fd only for dri3/dma_buf

-          It is legacy usage only (without 3D context)

-          Current GPU does YUV->RGB conversion with ease, libyami support it automatically.


thanks

From: gstreamer-devel [mailto:gstreamer-devel-bounces at lists.freedesktop.org] On Behalf Of Nicolas Dufresne
Sent: Monday, January 12, 2015 9:49 PM
To: gstreamer-devel at lists.freedesktop.org
Subject: Re: use dma_buf handle for hw video frames

What is the question ?
Le 2015-01-12 01:24, Zhao, Halley a écrit :
I have one idea to use dma_buf for hw video frames; in this way, video codec and sink can be clearly separated, video codec is simplified as well.
Since dma_buf is Linux kernel concept, different hw codecs can share the unique video sink.
See GstDMABufAllocator in gst-plugins-base.


For additional explanation,
We have a core codec library for VAAPI acceleration interface: https://github.com/01org/libyami,
it can export hw video frame as dma_buf handle, then renders it as texture: https://github.com/01org/libyami/blob/master/tests/decodeoutput.cpp#L465

another example is: we added libyami wrapper to ffmpeg for h264 decoder, then an example player can use dma_buf for video rendering: https://github.com/01org/player-ffmpeg-yami
If you want to experiment that (and if it improve the situation) feel free to propose some code.


besides opengl context, dri3 protocol supports dma_buf as well, thus legacy video rendering is fine as well.

Note that this is currently limited to 1 plane (1 FD) when combined with Mesa/DRM.

Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150114/febb90fc/attachment.html>