Help with gstreamer-vaapi + rockchip vpu vaapi driver

[Ezequiel Garcia]

On Mon, 15 Oct 2018 at 10:07, Víctor Jáquez <vjaquez at igalia.com> wrote:
>
> 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.
>

OK, cool. So I have dig it further and managed to get some
results. Still not working fully.

> 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??
>

Yes, it does.

However, I found a few things that seemed off:

1. On this particular platform, the library requires
PRIME_2 buffer type for AcquireBufferHandle.
It's done only if the pixel format is tiled,
but I have relaxed the requirement, since it
doesn't seem needed to acquire the buffer.

See: https://github.com/bootlin/libva-v4l2-request/blob/master/src/buffer.c#L212

2. Also, since there is no GetImage implementation
I have enabled GST_VAAPI_ENABLE_DIRECT_RENDERING=1,
so DeriveImage is used.

Although there are some artifacts, see image attached,
and also there's a SIGSEGV somewhere in v4l library.

However, I think this will prevent proper zero-copy to work,
since DeriveImage is effectively memcpying
the surface into an image.

Does gst-vaapi support zero-copy VAAPI to DRM ?

Do you know what hooks should I implement in the vaapi backend?
GetImage is not implemented, but I suspect it would
be another memcpy, or am I wrong?

Thanks a lot!
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unnamed (1).jpg
Type: image/jpeg
Size: 648282 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20181015/be17a860/attachment-0001.jpg>