Hi,
2014-09-18 10:51 GMT+02:00 Rémi Denis-Courmont <[email protected]>:
> 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,
I don't buy this, the suggested approach actually does allow for the
same architecture to be used regardless of HW or SW decoding. Only
hwaccel init would matter, if needed.
> 2) prevent pooling the output surfaces ahead of decoding,
Should this be really needed, that could be solved with a mix of the
approaches exposed below.
> 3) leak libavcodec reference counting to applications - which is
> unacceptable as explained yesterday already.
Keeping an AVFrame longer as a decode ref, or video processing ref can
work equally well IMHO.
> 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.
Luca's usage model on blueprint was plain simple to work with too. But
I'd guess an additional indirection for initialization could be
tolerable to make most parties happy.
>> 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.
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.
bonus point: you can still have the freedom to delegate hwaccel_device
allocation to libavcodec too.
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.
Otherwise, client application developers would get confused on the
normal operational model.
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 mean, if this is for the AVFrame system memory
buffers, that's readily a known process.
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
