Help with gstreamer-vaapi + rockchip vpu vaapi driver

[Víctor Jáquez]

Hi,

On Fri, 12 Oct 2018 at 16:58, Ezequiel Garcia wrote:
> Victor,
> 
> Found some time to pick up my investigation on vaapi on v4l, using
> bootlin's vaapi backend.
> I am using gst-build to get latest sources, and set the env variables
> as you suggested.
> The vaapi backend is properly detected:
> 
> # gst-inspect-1.0 vaapi
> Plugin Details:
>   Name                     vaapi
>   Description              VA-API based elements
>   Filename
> /root/gst-build/build/subprojects/gstreamer-vaapi/gst/vaapi/libgstvaapi.so
>   Version                  1.15.0.1
>   License                  LGPL
>   Source module            gstreamer-vaapi
>   Binary package           gstreamer-vaapi
>   Origin URL
> http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer
> 
>   vaapimpeg2dec: VA-API MPEG2 decoder
>   vaapipostproc: VA-API video postprocessing
>   vaapidecodebin: VA-API Decode Bin
>   vaapisink: VA-API sink
> 
>   4 features:
>   +-- 4 elements
> 
> The pipeline I  am trying now is (see full log below):
> 
> GST_DEBUG=vaapi*:4 gst-launch-1.0 filesrc
> location=~/big_buck_bunny_480p_MPEG2_MP2_25fps_1800K.MPG ! mpegpsdemux
> ! vaapimpeg2dec ! video/x-raw,width=854,height=480 ! kmssink
> 
> Now, my question is: is it possible to connect a vaapi decoder to a
> non-vaapi sink? Judging from this traces:
> 
> 0:00:01.230428590 32630   0x555350 INFO             vaapidecode
> gstvaapipluginbase.c:959:gst_vaapi_plugin_base_decide_allocation:<vaapidecode_mpeg2-0>
> ignoring non-VAAPI pool: <kmsbufferpool1>
> 0:00:01.270321791 32630   0x555350 ERROR                  vaapi
> gstvaapibufferproxy.c:228:gst_vaapi_buffer_proxy_new_from_object:
> failed to acquire the underlying VA buffer handle
> 0:00:01.270796060 32630   0x555350 ERROR                default
> gstvaapisurface_drm.c:54:gst_vaapi_surface_get_drm_buf_handle: failed
> to allocate export buffer proxy
> 
> I think not. So, I need to add proper support for a vaapisink DRM
> display, right?

Nope, you should be capable to use (almost) any sink.

For example, I have a blog post, using an atom board, playing a video with vaapi
and kmssink

https://blogs.igalia.com/vjaquez/2016/07/01/va-api-and-drmkms-in-minnowboard/

If I understand correctly the logs, vaapi decides to use the dmabuf allocator
for the src allocator but when the decode wants to use those surfaces, the
cannot be allocated.

I would recommend, as a test, to change the code to use the surface allocator
and use the vaapi mapping when copying the frames to kmssink.

https://cgit.freedesktop.org/gstreamer/gstreamer-vaapi/tree/gst/vaapi/gstvaapipluginbase.c#n532

Is dmabuf supported bye the v4l2 vaapi driver??

vmjl