Something wrong with gstreamer-vaapi DMABuf support

Volker Vogelhuber v.vogelhuber at digitalendoscopy.de
Fri Dec 8 09:45:48 UTC 2017


I'm currently trying to update my gstreamer version from a patched 1.8.3 
to 1.12.2. Unfortunately some of the changes regarding DMABuf support 
are still only in master. So I updated the gstreamer-vaapi to the git 
master (rev. af0bf7212bcf7d1064e15b7cbcb1bd901f093622).
For my project I have a DMABuf source that is feeded with FDs from 
another process and passed to vaapih264enc. For playback I need the 
other way round and have vaapih264dec to decode buffers into a DMABuf 
again transfered to another process that will import them as a GL 
texture. So far this did work with the patched 1.8.3 (thanks to patches 
from Nicolas Dufresne for older versions).
But with the current gstreamer-vaapi it seems like the vaapipostproc is 
not working properly. With the following pipeline I get a scrambled 
output image:

gst-launch-1.0 videotestsrc num-buffers=1 ! 
video/x-raw(rgb),framerate=25/1,width=640,height=360 ! vaapipostproc ! 
video/x-raw,width=320,height=240 ! jpegenc ! filesink location="test.jpg"

After a lot of debugging I finally found out, that it seems to have 
something to do with the allocator used for the buffers. I guess the 
force of the DMABuf allocator in gstvaapipluginbase.c 
ensure_srcpad_allocator is the root cause. After I changed the code to:

plugin->srcpad_allocator = NULL;
if (caps && gst_vaapi_caps_feature_contains(caps,
                  GST_VAAPI_CAPS_FEATURE_DMABUF)) {
     if (gst_caps_is_video_raw (caps))
       plugin->srcpad_allocator = create_dmabuf_srcpad_allocator (plugin,
                                     vinfo, !plugin->srcpad_can_dmabuf);
     else {
       plugin->srcpad_allocator =
         create_dmabuf_srcpad_allocator (plugin, vinfo, FALSE);
         if (!plugin->srcpad_allocator)
           goto error_create_allocator;
     }
}

the vaapipostproc seems to work Ok while the vaapih264dec is still able 
to provide the DMABuf I need. I guess there is something wrong as soon 
as the VAAPI is trying to map DMABuf to anything else 
(VASurface/SystemMemory). Because as long as there is no write to system 
memory but only encoding from a DMABuf and decoding into a DMABuf that 
is then directly used by the GPU as a texture there seem to be no 
problem. Only if I try to use the decoded image and e.g. write a JPG out 
of it, things go wrong.

I'm not sure if the problem only exists because I only upgraded 
gstreamer-vaapi to git master and not the rest of the gstreamer 
libraries (plugins, base, etc.) but maybe someone else can try to test 
the pipeline call on the command line and check if the resulting 
test.jpg contains proper image data.


More information about the gstreamer-devel mailing list