[vlc-devel] [PATCH 1/3] decoder: forward the source colorimetry if the decoder doesn't set it

Steve Lhomme robux4 at ycbcr.xyz
Tue Feb 19 08:29:17 CET 2019


On 18/02/2019 17:45, Rémi Denis-Courmont wrote:
> Le maanantaina 18. helmikuuta 2019, 17.56.40 EET Steve Lhomme a écrit :
>> ---
>>   src/input/decoder_helpers.c | 16 ++++++++++++++++
>>   1 file changed, 16 insertions(+)
>>
>> diff --git a/src/input/decoder_helpers.c b/src/input/decoder_helpers.c
>> index 3cc02de8d6..a019a540df 100644
>> --- a/src/input/decoder_helpers.c
>> +++ b/src/input/decoder_helpers.c
>> @@ -79,6 +79,22 @@ int decoder_UpdateVideoFormat( decoder_t *dec )
>>                     dec->cbs->video.format_update == NULL) )
>>           return -1;
>>
>> +    if ( dec->fmt_in.video.color_range != COLOR_RANGE_UNDEF &&
>> +         dec->fmt_out.video.color_range == COLOR_RANGE_UNDEF )
>> +        dec->fmt_out.video.color_range = dec->fmt_in.video.color_range;
> This is equivalent and simpler:
>
> +    if (dec->fmt_out.video.color_range == COLOR_RANGE_UNDEF)
> +        dec->fmt_out.video.color_range = dec->fmt_in.video.color_range

Indeed

> The only Q is whether fmt_out should be mangled in the back of the decoder.
> That seems sketchy.

Yes, that's why I'd rather have other opinions.

For decoders that never write those values it will only make things better.

For decoders that do change those values *after* the first 
decoder_UpdateVideoFormat() call, it could be a problem. When the pool 
is handled in there as the new values may not be coming out of that pool.

Looking at the current code it seems we do not handle this case either. 
For example the pool from the vout doesn't reset the metadata on the 
pictures and I don't see a place where it would copy them back in the 
decoder before being pushed to the vout.


More information about the vlc-devel mailing list