[vlc-devel] [PATCH 2/8] libvlc: add rendering callbacks for D3D11 and D3D9

[Steve Lhomme]

On 2019-05-06 16:33, Rémi Denis-Courmont wrote:
> Le maanantaina 6. toukokuuta 2019, 16.01.31 EEST Steve Lhomme a écrit :
>> ---
>>   include/vlc/libvlc_media_player.h | 144 ++++++++++++++++++++++++++++++
>>   include/vlc_vout_display.h        |   8 +-
>>   lib/libvlc.sym                    |   1 +
>>   lib/media_player.c                |  54 +++++++++++
>>   4 files changed, 203 insertions(+), 4 deletions(-)
> This is heavily coupled to DX. Identifiers should not be generic.

It's on purpose, because in the end there should be one API covering 
OpenGL, D3D, Vulkan, Metal, etc. I mimicked the OpenGL callbacks on 
purpose because they are pretty much doing the same thing at the same 
time. Only the OpenGL "GetProcAddress" is specific to OpenGL.

In the end they should be merged. The HDR10 Metadata should be passed to 
the host app duringOpenGL MakeCurrent(true) for example, so the host can 
pass it down/use it for tone mapping.

I can rename the callbacks for now (the colorimetry structure should be 
shared already). But I think in the end it should be merged. And it 
should be done before the 4.0 libvlc is finalized because we want it to 
be stable in the future.

Aside from that, I also think this architecture of rendering could also 
become a module type in VLC. Right now the D3D display modules are 
actually made of a part that renders to a texture (I'd call rendering 
engine) either a plain texture or a swapchain target, and a part that 
actually display the rendered texture on the screen (which is really 
what a display module should do). I think that's the same for OpenGL. 
This splitting could be reused for rendering using the GPU to do 
blending, colorimetry conversion, 360 projection, chroma conversion, 
resizing, etc. This can be used by the transcoder (especially when 
encoding in the GPU). That may be done in 5.0 it's not urgent.