[vlc-devel] Windows 0-copy DXVA

[Rémi Denis-Courmont]

Le 2015-04-15 16:34, Steve Lhomme a écrit :
>> The only operation that the decoder can possibly do with the pool is
>> allocate a picture from it. If you need to pass some context, you 
>> can use
>> the picture(_sys). Exposing the pool directly to the decoder would 
>> not solve
>> any problem, and yet would require rewriting all decoder modules 
>> call sites
>> (last time, I counted four of those).
>
> But once the picture_t are allocated in the pool, they should not
> change.

Well yes? The picture are allocated once when the pool is created.

> Playing with the picture_sys_t in the vlc_va_Extract() is what
> gave me some out of order frames in some cases.

Then you're doing it wrong.

> Another (hackish) solution to my problem is that when 
> vlc_va_Extract()
> is called with a fresh picture_t (without a p_sys)

p_sys is set when the picture is allocated. You are not making sense.

> it would take a surface from its pool and assign it to that picture_t
> for the remaining of the lifetime of the picture_t.

> There's still the issue of
> who is responsible to safely release the surface when it's not used.

The picture is returned to the pool for reuse when it is dereferenced. 
If the pool is destroyed, the picture release callback 
(picture_resource_t.pf_destroy) eventually releases the buffer.

> It's kinda working, except my surface->I420 doesn't work with a D3D11
> picture_t output. The current filter framework doesn't lock the
> picture_t before writing into it.

HW to SW pictures cannot work properly due to lack of SPU blending and 
per-filter pool.

-- 
Rémi Denis-Courmont