[vlc-devel] [RFC v2 4/8] libvlc: handle the input colorimetry on the surface callbacks

[Steve Lhomme]

On 5/2/2019 4:33 PM, Rémi Denis-Courmont wrote:
> Le torstaina 2. toukokuuta 2019, 16.28.47 EEST Steve Lhomme a écrit :
>> ---
>>   include/vlc/libvlc_media_player.h | 53 ++++++++++++++++++++++++++++++-
>>   include/vlc_vout_display.h        |  8 +++++
>>   lib/media_player.c                | 37 ++++++++++++++++++++-
>>   3 files changed, 96 insertions(+), 2 deletions(-)
> Colorimetry is, or should be, part of the track meta data, where it can be
> accessed regardless of rendering mechanism, regardless of track selection, and
> can be extended without breaking apps.

It depends on your definition of metadata. Is the video width/height a 
metadata or needed for proper rendering ?

And track selection has everything to do with what will be provided to 
the host app for rendering. The rendering cannot be done "regardless of 
track selection".

> The video output already is supposed to have the shaders for colours inside
> OGL / DX outputs. I don't see why the rendering callbacks should care.

The shaders are precisely there to transform the source colorimetry into 
the one of the display, like doing tone mapping when displaying a HDR 
source on a SDR display. The pixel shaders are created knowing the 
source and destination format. And the only way to do it properly is to 
know the colorimetry used by the host app. So we at least need the 
output part of the LIBVLC_VIDEO_UPDATE_OUTPUT call.

But we should also provide the host app the source information so it can 
decide what rendering format it's going to use. For example if the 
source is 10 bits, it should not select an 8 bits format, especially if 
the screen is 10 bits.

Currently there's no way for the host app to know the format of the 
video that's being rendered, hence these new enums.

> Besides, that will break as soon as a new enum member needs to be added, and
> the app does not know it.

I don't see how it's going to break. The host app doesn't need to care 
what the source formats are if it doesn't understand them. It does have 
to tell exactly what it's going to support. And to do so it uses the 
enum values it understands. If new unknown enum values are added, it 
won't make any difference to that.

On the source side, if new enum values are added the host can ignore 
them and pick a basic output format. Maybe it could have picked a better 
output format if it understood this value. But it's not a real issue. In 
all cases it has to provide the colorimetry it's going to use.