[vlc-devel] Windows 0-copy DXVA

Steve Lhomme robux4 at videolabs.io
Wed Apr 15 16:16:17 CEST 2015

On Wed, Apr 15, 2015 at 3:34 PM, Steve Lhomme <robux4 at videolabs.io> wrote:
> 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.

I spoke too fast. It does lock the surface before writing on it. There
was a hack I added during development that fucked some things up. It's
now almost working. I'm going to clean things up now.

More information about the vlc-devel mailing list