[vlc-devel] [PATCH 2/8] libvlc: add rendering callbacks for D3D11 and D3D9
robux4 at ycbcr.xyz
Tue May 7 08:43:47 CEST 2019
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.
More information about the vlc-devel