Hi, 2014-09-18 10:39 GMT+02:00 Luca Barbato <lu_z...@gentoo.org>: > On 18/09/14 10:15, Gwenole Beauchesne wrote: >> Agreed. What I particularly disliked in the original approach >> (hwaccel1) [*] was to hand off the responsibility to allocate hwaccel >> resources to the client application or library. This is legacy process >> inherited from XvMC times, and also originally required by the fact >> that hwaccel libraries (libva, libvdpau, XvBA et al.) explicitly >> depended on a display backend (e.g. X11), which is bad. >> >> [*] and yes, it was my fault maybe. :) > > Everybody have to start from something =) > >> This era is gone, and much better things could be achieved so that to >> have client applications or libraries do much less work. >> The key idea is: libavcodec is the codec layer, it has to handle >> everything expect the display dependent stuff. That is, the user shall >> only be required to provide a hwaccel display/device/whatever to >> libavcodec. That's it. > > Yes. > >> At least, on the libva side, all the core hwaccel functions are in a >> display-independent library (libva), and display-dependent libraries >> (libva-x11, libva-wayland, libva-drm) are only useful to get a VA >> display. > >> At the minimum, what we need to look into is: >> >> 1. A way to select the hwaccel, or provide the device handle to >> libavcodec. In some conditions, we could even delegate the allocation >> of the hwaccel device to libavcodec, should the client application >> request it. >> >> 2. A way to precisely control the lifetime of hwaccel surfaces. In >> this case, the AVFrame.data[3], or some other more explicit field, >> could be converted to mean this is a ref-counted object where a native >> hwaccel surface lives in. data[0..2] should really be reserved for raw >> video planes, as exposed above. In normal process, the >> AVCodecContext.release_buffer() should release a reference to that >> surface, and this could be done implicitly actually, and if the client >> application really wants to keep the surface longer, then it should >> just need to hold an extra reference to it. Internally, a pool of >> hwaccel surfaces could be maintained. > > refcounted buffers make that easy to achieve now. > >> >>> The problems at hand are >>> >>> - Having an avoption api let us easily add features, but passing >>> pointers through avoption properly would require an overhaul to it (so >>> we pass the pointer >> >> What was wrong with your av_hwaccel_alloc()? I think, we only need an >> hwaccel_id, and the hwaccel_device handle. By device handle, I mean >> VADisplay, VdpDevice, whatever. > > Nothing wrong per-se (the blueprint is still in the wiki), just that > moving from one approach to the other require time and will from third > parties to adapt.
I think that, if the new APIs are disruptive enough and bring major benefits in common usage models, third parties would easily adopt. Besides, this allows for hwaccel1 legacy to live in, and possibly offer some kind of compat layer for hwaccel1 -> hwaccel2. >> I think we should discuss more during VDD, and get j-b book a slot if >> there are other interested parties. :) > > Sure, I presented hwaccel2 exactly 1 year ago and I can present what > happened and what I learnt about it. That would be great. Thanks. I couldn't attend last year, was visiting Tuscany. :) _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
