[vlc-devel] Windows 0-copy DXVA

[Steve Lhomme]

So I made it work in a not-so-dirty way. Alongside the output
video_format_t, the decoder has the possibility to pass some callbacks
that are used by the pool allocator to setup the picture_t properly.
In the normal case, the old code does exactly the same.

Maybe one day we can do something cleaner, ie the decoder pool belongs
to the decoder, the display pool to the display and the filter/SPU
pool to the vout. But that's a much bigger change.

On Thu, Apr 16, 2015 at 1:51 PM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le 2015-04-16 09:43, Steve Lhomme a écrit :
>>
>> 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
>
>
> Again, so far only a display module can provide a custom picture pool so
> far. I started some work in that area late last year, but a lot of
> implementation is still missing to support custom pools in splitter and/or
> filter modules. The vout wrapper is only the tip of the iceberg here.

The structure/callback I added to create the proper surfaces is not
tied to picture pools, it could be used anytime a picture_t is
created.

>> 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
>
>
> I would concentrate on the direct GPU path for now. You can always fall back
> to CPU decoding or retain the existing in-decoder memory copy in other
> cases. decode_UpdateVideoFormat() should fail if the decoder requests an
> unsupported "chroma".

Not sure how this is supposed to work. If the vout rejects a chroma,
it does so during a picture_t request, that then returns NULL. But at
that point a new decoder is not negotiated, it just fails and doesn't
decode that track.

Also that means every possible vout that can be used on Windows should
be modified to refuse the D3D9 opaque surfaces.

>> IMO picture_pool_NewFromFormat() should be able to create the
>> necessary amount D3D9 surfaces when passed my pixel format.
>
>
> IMNSHO, the conversion filter module should be able to create and supply its
> own picture pool, like the display module.


Yes, someday.

For now I should fix the D3D11 texture handling, which is not
supported. So using DXVA surfaces doesn't need to do the blending,
even though the surface is converted to I420 via a regular "video
filter2" before being passed to the vout.