Hi, 2014-09-10 12:30 GMT+02:00 Luca Barbato <[email protected]>: > On 10/09/14 11:10, Gwenole Beauchesne wrote: >> Well, the initial use-case I had in mind, in view to supporting some >> hwaccel2 interfaces, was a capability bit to indicate it is possible >> to implicitly output to raw YUV buffers, possibly user-allocated, >> instead of dealing with VASurfaceID, VdpSurface id, or other excessive >> download/upload/sync mechanisms, etc. > > I like the idea indeed. > >> Another use-case is that for some hwaccels, it could be interesting to >> enable frame-level decoding, while also still allowing slice-level >> decoding in specific use cases. e.g. in dxva2/vaapi, that could be a >> way to enable "short" mode decoding in H.264 AVC, but keep "long" mode >> decoding for H.264 MVC. > > That would need the next step that is the > av_hwaccel_alloc/config/open/close() (think about avresample for a > similar api).
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. :) 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. 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. > 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. > - we need to keep the structure exposed to let the users that need to > pass otherwise-managed pointers keep doing it. > > - per-hwaccel allocator might be less confusing than having a function > returning a pointer that you have to cast, but having 3+ functions for > each hwaccel might be a burden in the long time. > >> Having said that, I believe a simple comment update is fine as it is. >> An explicit deprecation attribute would not. > > I do agree. I think we should discuss more during VDD, and get j-b book a slot if there are other interested parties. :) Regards, -- Gwenole Beauchesne Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France Registration Number (RCS): Nanterre B 302 456 199 _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
