<div dir="ltr">Víctor,<br><div><br></div><div>Thanks for the hints. I'll check gstreamer-vaapi code and try to hack it in the way as you suggested.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 25, 2016 at 3:27 AM, Víctor M. Jáquez L. <span dir="ltr"><<a href="mailto:vjaquez@igalia.com" target="_blank">vjaquez@igalia.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05/25/16 at 09:45am, Víctor M. Jáquez L. wrote:<br>
> On 05/25/16 at 01:22am, Anon wrote:<br>
> > Hi All,<br>
> ><br>
> > I want to implement the following use case on Intel Haswell CPU with HD<br>
> > graphics:<br>
> ><br>
> > offscreen OpenGL rendering to OpenGL 2D texture -> use<br>
> > EGL_MESA_image_dma_buf_export<br>
> > to export the texture as prime fd -> vaCreateSurfaces from the prime fd -><br>
> > use vaapi to hw acclerate h264 encoding<br>
> ><br>
> > Is this supported by the latest va-api and libva-intel-driver release<br>
> > (i.e., 1.7.0)? If so, is there any example I can start with?<br>
> ><br>
> > I did read the sample application h264encode.c and thought it might be a<br>
> > good starting point. However, the first major issue I encountered is when<br>
> > creating context through vaCreateContext, a number of pre-allocated va<br>
> > surfaces are required and thus statically associated with the new va<br>
> > context. However, with prime fd, the fd will change so a new va surface is<br>
> > created with every new prime fd. I don't see any API can be used to<br>
> > dynamically add/remove va surfaces after the context is created. Can you<br>
> > please give me some suggestions?<br>
><br>
> You can look at the gstreamer-vaapi[1] code, which supports it, though right<br>
> now is under discussion and rewriting.<br>
><br>
> 1. <a href="https://cgit.freedesktop.org/gstreamer/gstreamer-vaapi" rel="noreferrer" target="_blank">https://cgit.freedesktop.org/gstreamer/gstreamer-vaapi</a><br>
<br>
</span>Ugh... morning coffee is not kicking yet.<br>
<br>
This specific pipeline is not supported out-of-the-box, perhaps hacking<br>
gldownload element to export dmabuf elements from a specific texture grabber<br>
by glsrcbin. I don't know the details.<br>
<br>
Anyway, from the VA side, afaik, encoders/decoders need pre-allocate the<br>
output surfaces, not the input ones.<br>
<br>
You can associate the prime fd to a surface and encode it. Don't release the<br>
fd until the surface is already processed.<br>
<span class="HOEnZb"><font color="#888888"><br>
vmjl<br>
</font></span></blockquote></div><br></div>