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 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. lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
