[vlc-devel] Windows 0-copy DXVA

Steve Lhomme robux4 at videolabs.io
Thu Apr 16 08:43:10 CEST 2015


So I got the thing working for now with D3D9 using only GPU surfaces
and D3D11 using a filter to extract pixels from a surface to planes in
a picture_t. But I had to use a temporary hack that settle a surface
on each picture_t that comes along in vlc_va_Extract(). This is
equivalent to having it set when the decoder pool is created, except
it doesn't release/destroy the resources properly.

I could hack even more in there the picture_t gc to release this a
little cleaner. But that' just dirty.

IMO there's something missing when creating the decoder pool here:
http://git.videolan.org/?p=vlc.git;a=blob;f=src/video_output/vout_wrapper.c;h=d172bcca0bfdacc9ebc5c7979a1f10850e7092c9;hb=HEAD#l133

My decoder only deals with surfaces to avoid copying to CPU by
default. It has no way to know if the vout is going to be compatible
with it or not. So that part is fixed. But then the vout creates the
pool of picture_t that will be used to extract decoded frames from the
decoder and push them in the FIFO of the display. It uses
picture_pool_NewFromFormat() to do that.

The problem is that my picture_t should have empty planes and D3D9
surfaces that the decoder can deal with. It's similar to other opaque
formats:
http://git.videolan.org/?p=vlc.git;a=blob;f=src/misc/fourcc.c;h=0a08be45ecc81f8ad44ec2d607dffd621011fc76;hb=HEAD#l2191

Except those opaque formats assume the vout will be compatible and
share their display pool. This is what I was doing with a D3D9 only
solution. But it should be working with other vout as well and not
rely on who is going to create the display pool (if Android or
Raspberry Pi get a new vout, the same problem will occur).

IMO picture_pool_NewFromFormat() should be able to create the
necessary amount D3D9 surfaces when passed my pixel format. We know
this pool will be used to get picture_t from the decoder. So it's only
fair that it allocates data that the decoder will be able to handle.
The term "opaque" may be a bit contradictory though.

How about a vlc_chroma_description_sys_t with some extra callbacks
that could create such surfaces ?

As Rémi mentioned the decoder pool is also used for other things.
There's a private pool that is also used for SPU blending. It reserves
4 pictures from the decoder pool. I'm going to look into this to see
what needs to be changed for this to work.

On Wed, Apr 15, 2015 at 4:16 PM, Steve Lhomme <robux4 at videolabs.io> wrote:
> 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.
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel



More information about the vlc-devel mailing list