[vlc-devel] [PATCH] [RFC] always output an opaque D3D9 surface from DXVA

Rémi Denis-Courmont remi at remlab.net
Mon Apr 27 12:30:31 CEST 2015

Le 2015-04-27 12:31, Steve Lhomme a écrit :
>> I think it is preferable for the hardware context to be made 
>> available already
>> at Open(). (Also I would pass the picture_sys_t cast to void, rather 
>> than the
>> whole picture_t. It would be slightly less ugly.)
>> Besides Setup needs to go away separately. It should be folded into 
>> Open()
>> (for all plugins). libavcodec has to call get_format() again if the 
>> resolution
>> changes.
> I'll give it a try. Thanks for helping moving this forward.

There are still some issues left:

- We need to ensure that fmt_out does not vary between get_format() 
calls - so that the underlying video output does not get destroyed and 
recreated. This is a bit intricate because we also need to support 
unaccelerated decoders that do not call get_format() at all.

- Passing opaque handles from the vout to the decoder only works if 
there is no format conversion (i.e. vout format and decoder output are 
identical). Otherwise, the lack of custom pool for filters hits.

- And obviously I have not adjusted vlc_va_New() to get the 
picture_sys_t or whatever yet.

> Also the big remaining question is how to handle the D3D9 picture_t
> pool in the core. I did it the quick & dirty way with some if on the
> opaque pixel format and surrounded by _WIN32 tests.

I'm not sure what you mean by that. If you don't do conversion and the 
video output supports subpictures, there should be no major issues. 
Except maybe for the corner case of snapshots.

If you do conversion, then you either have to use work-arounds like 
VDPAU, or implement filter pools or an usable subset of them.

Rémi Denis-Courmont

More information about the vlc-devel mailing list