[vlc-devel] DXVA no CPU access design

[Steve Lhomme]

On Wed, Apr 22, 2015 at 2:06 PM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le 2015-04-21 21:46, Julian Scheel a écrit :
>>
>> Where is this hwaccel_context coming from? And what prevents you from
>> retrieving it in the vout and putting it into a picture_sys_t?
>
>
> Desktop slice-based decoders need the hardware context at initialization
> (i.e. vlc_va_New()) to check hardware capabilities. There are no pictures to
> retrieve the hardware context from because the video output is not
> initialized yet. Some further changes to the libavcodec plugin would be
> required to solve this ordering problem.
>
> That being said, fetching the device handle from a picture - as the
> vdpau_chroma filter does - is ugly. I would rather provide the device handle
> as an opaque chroma-specific pointer from the video output to the decoder
> (*). That would be tidier IMO; but it would require core changes.
>
> (*) not in the opposite direction

Whichever way would be nice.

There's still the issue of how the vout_wrapper picture_pool_t are
created just by a chroma.

We may need some to associate some chroma with the some init
functions. In the case of DXVA2 it would need to create the D3D9
handle and the D3D9 device, before allocating the right amount of
surfaces. That's regardless of the vout chosen.

The real question is where do these init functions belong ? In core ?
In the decoder module ? If so, as a new kind of module ?

With that in place, the dxva2 module could work like this:
- create D3D9 objects to check if decoding is even possible, as today
- get the "chroma-specific pointer" defined above and redo the
D3D9/buffer init if anything changed.
- tell the dxva_context about the allocated surfaces