On Thu, Sep 18, 2014 at 10:51 AM, Rémi Denis-Courmont <[email protected]> wrote:
> 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. > I agree. If I cannot handle the surface allocation myself for my DXVA2 decoder, then it becomes useless to me. The way a pure DXVA2 chain works in DirectShow and MediaFoundation (ie. without copying the image to system RAM), you need pre-allocate the surfaces and other resources in negotiation with the video renderer, if my user app is not in control of this anymore, it becomes impossible. Optionally letting avcodec do this for the use-case where you're copying stuff back to sysmem anyway might work out ok for simple use-cases, but if the option goes away to let the user-app manage it at all, you lose a lot of functionality. - Hendrik _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
