[vlc-devel] [PATCH] DxVA2: allow NV12 pixel format all the way to the D3D texture

[Steve Lhomme]

It turns out D3D9 currently doesn't handle direct buffer rendering (0
copy) because of is_slow and has_pictures_invalid set here:
http://git.videolan.org/?p=vlc.git;a=blob;f=modules/video_output/msw/direct3d9.c;h=56d053bbb4044ccccbabe7b3b2d2038aa0e062b5;hb=HEAD#l204

After hacking my way in I managed to get DXVA2 to output an "opaque"
format. But I had to mimic a NV12 for this to work. The vout is the
one responsible for allocating the frame buffers. And thus it needs to
know the dimensions of the buffer it needs. This is okay in the vout
but it also impacts other areas.

I'll keep digging to get something opaque to everything but the vouts.

On Wed, Apr 1, 2015 at 3:44 PM, Steve Lhomme <robux4 at videolabs.io> wrote:
> On Wed, Apr 1, 2015 at 3:40 PM, Jean-Baptiste Kempf <jb at videolan.org> wrote:
>> On 01 Apr, Steve Lhomme wrote :
>>> On Wed, Apr 1, 2015 at 3:16 PM, Jean-Baptiste Kempf <jb at videolan.org> wrote:
>>> > On 01 Apr, Steve Lhomme wrote :
>>> >> j-b mentioned that a custom VLC_CODEC_DXVA pixel format could be used
>>> >> for hardware acceleration, like it's done in Android. But if we want
>>> >> to use filters that means the DXVA format cannot be opaque.
>>> >
>>> > Well, one idea is that the DxVA decoder always outputs
>>> > VLC_CODEC_D3D9_OPAQUE or VLC_CODEC_D3D11_OPAQUE and we create a fiter
>>> > that can do VLC_CODEC_D3D9_OPAQUE -> NV12 and one VLC_CODEC_D3D9_OPAQUE
>>> > -> YV12.
>>>
>>> As NV12 is a requirement of DxVA there's a good chance that any GPU
>>> that comes with support for it and outputs NV12 will support NV12
>>> input format.
>>
>> So what?
>>
>>> > Therefore we can do all the format negotiation in the vfilter chain.
>>> >
>>> > And of course, we can have the D3D or D3D11 video output to render
>>> > directly the VLC_CODEC_D3D9_OPAQUE or VLC_CODEC_D3D11_OPAQUE
>>> > (respectively)
>>>
>>> In the end what's the difference in having VLC_CODEC_DXVA_OPAQUE just
>>> being VLC_CODEC_NV12 ? It gives the same problem with filters that
>>> only handle I420.
>>
>> No. VLC_CODEC_DXVA_OPAQUE would be just the handle to Direct3D9 surface
>> ref.
>>
>>> It's not that opaque if we want to able to convert it. So let's not
>>
>> Of course, but we already have the conversion between Direct3D9 and NV12
>> or YV12 in the decoder
>>
>>> using an opaque format at all.
>>
>> It is. Because it's a way to have GPU 0-copy like on VDPAU and
>> MediaCodec.
>>
>>> A real opaque format would make sense in the case the user doesn't
>>> want to bother with filters. It could be handled by the matching vout.
>>> It might be useful to support formats that cannot be accessed at all
>>> by the CPU (DRM).
>>
>> I'm sorry, but I think you are mistaken.
>>
>> The solution I propose would allow to have:
>>  - 0 copy (full opaque)
>>  - NV12 output for Direct3D output
>>  - I420 for filters and the rest.
>>
>> And all that could be autonegotiated.
>
>
> OK, that's easy enough to try to see if it works (the negotiation and
> using filters).
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel