[vlc-devel] [PATCH 1/5] va: try to output an opaque chroma first, then a plane-based one

[Steve Lhomme]

On Mon, Jun 1, 2015 at 7:22 PM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le lundi 01 juin 2015, 19:15:03 Steve Lhomme a écrit :
>> It's not specific to DXVA. IMO Video Acceleration has no guarantee
>> that the decoded frames will be in the CPU memory. In a DRM system
>> there's even a good chance it's not possible at all. So it's a good
>> thing that we make sure the vout is possible for the output type.
>
> We already do that. There are no needs to extend the setup callback for that
> purpose. Besides, the setup callbacks should die.
>
> It´s the transcode plugin that needs fixing here, not libavcodec.

I don't understand which part of the chain you are referring to. The
GPU to CPU copying is not an issue right now. The problem is the
buffering of the picture_t coming out of the decoder before being
rendered, the ones that are "extracted" from the decoder. Creating
that pool, that belongs in the core, is based on the pixel format.
Right now it's not possible to allocate GPU-based picture_t the way
it's done. And I'm not sure it's a good idea to do it there anyway. We
need one hack per new GPU format.

I think it's better to try to use the va with another format that's
more suitable for the core, when necessary. In the end it could even
try 100 different pixel formats if needed. The boolean I added is too
limitating. And since we already loop on the output format list that
avcodec says it can handle, adding another loop on possible output
format in the same place doesn't seem too far fetching.

I know there are some talks about reworking some parts of the pools or
buffers but I don't know much about it. So maybe there are some
solutions in the pipeline that I don't know of.