Le 2014-09-18 12:20, Gwenole Beauchesne a écrit :
Except not. Maybe VA only needs a pointer and if we forego type
safety, it
can easily be made into a void pointer:
int av_hwaccel_alloc(AVCodecContext *, enum AVPixelFormat, void *);
Yes but... VDPAU needs a 32-bits integer *and* a pointer, so that
does not
quite work. And I would not assume that other interfaces can
conveniently be
made into a single void pointer either.
Also, not that I care myself, but I don't see a credible story for
preemption handling if there is a generic function.
In this case,
- av_hwaccel_device, where you could have an
av_hwaccel_{bind,import}_HWACCEL_device()
- av_hwaccel_context (internal or public struct), and the void *
above
is your av_hwaccel_device.
Compare with file descriptors: They are all destroyed with close(), but
the functions and function prototypes to create them varies by type.
bonus point: you can still have the freedom to delegate
hwaccel_device
allocation to libavcodec too.
You could define a function for the special case that the application
wants to use hardware decoding in a completely transparent fashion. But
that is a special case of its own. I still don't see the benefit in not
having specific functions for what are non-transparent cases anyway.
Your hwaccel_device is where you could import a pool of hwaccel
surfaces if needed.
However, we need to have at least one common baseline usage model.
This may be possible for decoding-only acceleration (into CPU memory),
but I don't think it even makes sense for full acceleration. Surface
allocation is per-backend, post-processing is per-backend and rendering
is per-backend.
Otherwise, client application developers would get confused on the
normal operational model.
The only case where you can really abstract the backend away from the
application developer is where you copy decoded content back to the CPU.
And that is the most useless case, as it is often slower than software
decoding.
BTW, we should really stop abusing pixel-formats for identifying
hwaccels. We could have an hwaccel_id enum just fine, or a string
literal. Or did the AVPixelFormat arg above serve other purpose in
your proposal?
I agree that for certain use cases, we would need a separate
get_hw_context() callback before get_format(). Indeed, we cannot use
pixel formats to distinguish hardware-accelerated decoding to CPU
memory, from normal software decoding.
*But* when the surfaces are not mapped to the CPU, then I think a
separate pixel format is actually sound. It describes what to expect of
the AVFrame structure afterall.
I mean, if this is for the AVFrame system memory
buffers, that's readily a known process.
Sure.
--
Rémi Denis-Courmont
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
