[vlc-devel] Windows 0-copy DXVA

[Steve Lhomme]

On Wed, Apr 15, 2015 at 3:16 PM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le 2015-04-15 15:42, Steve Lhomme a écrit :
>>
>> Shouldn't there be a way to tie the decoder pool to the actual decoder?
>
>
> I think I already explained a few days ago why that would not work: the
> decoder does not know where to output to - the video output (or the encoder)
> determines that.
>
>> At least tell the decoder this pool is being used
>
>
> 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. Playing with the picture_sys_t in the vlc_va_Extract() is what
gave me some out of order frames in some cases.

Another (hackish) solution to my problem is that when vlc_va_Extract()
is called with a fresh picture_t (without a p_sys) 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.

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.

>> and also when it's not used anymore.
>
>
> I already told you: the pool is used at least as long as the decoder does
> not change its output format.
>
> --
> Rémi Denis-Courmont
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel