Help with gstreamer-vaapi + rockchip vpu vaapi driver

[Benedict Holland]

I am not sure if LibDRM got ported for the rockchip MESA drivers. I tip my
hat to you. I tried getting GStreamer to work with my board and the only
thing I could get working was the very low-level ffmpeg commands. Even that
was touchy. If you need help testing it out, let me know.

Thanks,
~Ben

On Mon, Oct 15, 2018 at 5:49 PM 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.
>
> >
> > 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!
> > _______________________________________________
> > gstreamer-devel mailing list
> > gstreamer-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20181015/9051eedb/attachment.html>