Help with gstreamer-vaapi + rockchip vpu vaapi driver

[Ezequiel Garcia]

On Mon, 15 Oct 2018 at 18:57, Nicolas Dufresne <nicolas at ndufresne.ca> wrote:
>
> Le lundi 15 octobre 2018 à 17:04 -0300, Ezequiel Garcia a écrit :
> > 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 ?
>
> Not at the moment. There is no VAAPI DRM backend, and the dmabuf
> exportation need to be ported to PRIME_2 in order to expose the
> modifiers. Whenever there is no modifiers, normal DMABuf will be used
> and then kmssink could work.
>

Maybe this is something we can kickoff during next hackfest.
It doesn't sound like we are too far away, and with cedrus
driver about to be merged, it'd be interesting to have this
pieces in place.
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar