mpv-player
WIP: vo_vaapi_wayland: refactor into generic VO for dmabuf buffers
-
Re-design buffer pool so it is generic and does not depend on VAAPI. This vo design will be re-used for upcoming drmprime decoder, so it will be easier to re-use if vaapi dependencies are reduced to minimum. With these changes, all vaapi-specific buffer transformations are grouped into one single method.
-
rename vo_vaapi_wayland to more generic vo_dmabuf_wayland
If the drmprime decodering thing needs to be a separate VO, does it make sense to split off the buffer pool code to its own separate file/header?
It shouldn't need a new vo. The vo just needs to support two hwdecs which is presumably possible as vo=gpu does exactly that.
@Dudemanguy yes, it would make sense to move it into a separate file if there are two vos using it. @philipl that would be great - currently the vo preinit assumes vaapi and fails if it can't initialize the library. How would it know whether to initialize vaapi or not, if it supports both ?
Ah, I guess missed the details in IRC. If you want to reuse all the wayland-specific stuff, then yeah definitely it can be the same VO. I guess the VO should be renamed to something else as well (don't have any good ideas right now) if you want generalize to any hwdec.
@Dudemanguy yes, it would make sense to move it into a separate file if there are two vos using it. @philipl that would be great - currently the vo preinit assumes vaapi and fails if it can't initialize the library. How would it know whether to initialize vaapi or not, if it supports both ?
I'm not sure of all you specifically need to do, but the logic exists in vo=gpu[-next]. The basic idea is the vd code will notice the stream might be hw decodable and it will try to load the right interop for it, based on the pixfmt. You need to provide a loader helper method that will load the requested interop. You would only be willing to load vaapi or drmprime but it should work. A lot of hand waving in there.
In the future, the vaGetDisplayWl call could be made to be non-fatal if you have the drmprime thing available. I think that can wait until we actually have that usable.
In the meantime, maybe just rename this dmabuf-wayland? That's basically what this is anyway: importing from the hwdec into a dmabuf and making wl_buffer's. vaapi just happens to be the one hwdec that can work like this right now.
In the future, the
vaGetDisplayWlcall could be made to be non-fatal if you have the drmprime thing available. I think that can wait until we actually have that usable.In the meantime, maybe just rename this
dmabuf-wayland? That's basically what this is anyway: importing from the hwdec into a dmabuf and making wl_buffer's. vaapi just happens to be the one hwdec that can work like this right now.
I've added a commit to rename to the more generic dmabuf-wayland
@Dudemanguy thanks, I fixed the waf build, if you can double check it when you have time, that would be great
@Dudemanguy freebsd build fails on rsync error. Are you able to kick off another build ?
That's just the freebsd being a special snowflake. It randomly fails when trying to disconnect for whatever reason. It's always done that.
@Dudemanguy thanks a lot for the review - I'm putting this PR on hold for the moment, as I may have a better design for the vo based on the gpu VO