Hi,
Here is a example for using drm rendering with libva decoding.
https://github.com/01org/libyami-utils/blob/master/examples/grid.cpp
-----Original Message-----
From: Libva [mailto:[email protected]] On Behalf Of Yann
Dirson
Sent: Wednesday, July 6, 2016 6:52 AM
To: [email protected]
Cc: tech <[email protected]>
Subject: [Libva] Decoding and rendering to DRM
Hello,
I started to investigate how to render the decoded video to screen without
going through X11, and DRM/KMS looks likes the best candidate, with hints in
the libva API doc that it is supported.
Is there already some code somewhere doing that ? gstreamer-vaapi, which at
first glance looked the most promising candidate apparently in fact does not do
that :) Even a pretty complicated app could do the trick, I'm using a dedicated
LD_PRELOAD API tracer to understand how various apps are using libva.
The approach I am trying is:
* start with vaGetDisplayDRM()
* use vaQuerySurfaceAttributes to identify available pixel_format and mem_type
(here NV12 format only, and MEM_TYPE_KERNEL_DRM is advertized) - pitches and
offsets will have to match the underlying DRM framebuffer (it's not obvious to
me yet if the latter is/can be created automatically or if the caller has to
provide it)
* create my vaSurface's using those parameters
* decode picture as usual, targetting those DRM-backed surfaces
* use vaAcquireBufferHandle to get a handle to the underlying DRM frame buffer
and from there get DRM to display it and eg. drmModePageFlip() it
The problem I have, is that vaAcquireBufferHandle is apparently supposed to
lock the *VABuffer* used as backing store for the surface, but I don't see an
API to get that object from the surface.
I'm suspecting VASurfaceAttribExternalBuffers::buffers could be a way for the
app to provide them on surface creation (did not find much hints in the API doc
about this field, not even if it's an in or out parameter), and that those
should be created at the DRM level, but then I cannot create a VABufferID for
this before I get a VAContextID, and that one in turns requires the surfaces to
be created already, so even if I create the DRM frame buffers at first I'm
still left with a missing link.
I'm also quite new to DRM as well, which does not help, and I'm wondering:
* are dumb buffers sufficient for this use, or should I rather turn to libgbm,
or should I simply get them created automatically ?
* declaring a frame buffer as NV12 seems to require use of drmModeAddFB2(), but
the latter seems to expect one *handle* per plane and return a *buf_id*, I
guess it is the latter which should be bassed as "buffer handles" through
VASurfaceAttribExternalBuffers::buffers, despite the different terminlology
Am I (at least to some extent) on the right track ?
Also the following is still obscure to me: what's the semantics of
VASurfaceAttrib.flags for vaCreateSurfaces ? It took me some time to figure
out that my original guess of setting them to VA_SURFACE_ATTRIB_SETTABLE was
what was causing an "invalid parameter" error
Best regards,
--
Yann Dirson <[email protected]>
Blade -- 90 avenue des Ternes, 75017 Paris
_______________________________________________
Libva mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libva
_______________________________________________
Libva mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libva
