Hi, here is a new iteration of the hwaccel-ng set. It's still an RFC, but the API could now be close to a final version, unless there are major objections.
The main change from the first version is that now there are two main objects in the API -- AVHWDeviceContext and AVHWFramesContext. AVHWDeviceContext is supposed to store the "device/session/display/whatever else the API decides to call it" stuff that's not tied to a specific stream configuration. OTOH AVHWFramesContext represents a pool of frames with specific defined properties (depending on the API it can be either dynamic or static). AVHWFramesContext is always tied to a parent device context. Given an AVHWFramesContext, the caller can currently allocate hw frames and copy the data to and from them in a completely hw-independent way, which I think is rather nice. The basic idea is that if you have something like a hardware scaling filter, it will have different frame contexts on input and output, but they will share the device context. One point for discussion is the use of AVBufferPool API to allow custom user allocators, I see at least two possible issues with it: - it can only return a single AVBufferRef at a time, which make it very awkward to allocate hw frames composed of multiple non-contiguous planes. I am, however, not aware of any API that supports such frames. And it could potentially still be supported through the use of very very evil tricks (e.g. the returned AVBuffer's data points to an array of AVBufferRefs that contain the actual planes). - it cannot (in a sane way) return auxiliary information, such as the stride, which is a free user-selectable parameter in some APIs (e.g. CUDA). It can still be signalled through the hardware-specific context. Another conceivable (but probably unpopular) option is extending AVBuffers with side data. I'm still unsure how important those issues are and whether they justify inventing a new API. Opinions welcome. -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
