Le 2014-09-18 11:15, Gwenole Beauchesne a écrit :
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.
What? No. Video decoding has been pulling buffers since much before
XvMC. get_buffer() is not only there for hardware acceleration.
Indeed forcing surface allocation inside libavcodec would:
1) require needlessly different architecture for HW and SW decoding,
causing a lot of unnecessary pain on applications that want to support
both,
2) prevent pooling the output surfaces ahead of decoding,
3) leak libavcodec reference counting to applications - which is
unacceptable as explained yesterday already.
This is a non-starter for me.
This era is gone, and much better things could be achieved so that to
have client applications or libraries do much less work.
That is much *more* work for most cases. If you write a client that
supports only hardware decoding, and assumes nothing else uses the GPU
simultaneously, then pushing buffers may be simpler than pulling them.
But that's not the general case.
The era of pulling output buffers is _not_ gone. Only XvMC is gone (and
XvBA and DxVA1 if you want).
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.
The type and parameters involved depend on the back-end. A generic
function will be inconvenient and break type-safety. I much prefer the
av_FOO_bind_context() approach.
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.
Cosmetics.
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.
That's already how it works. I fail to see a problem.
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.
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.
--
Rémi Denis-Courmont
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
