[vlc-devel] [PATCH] picture: fix missing video_format_t attributes from the picture
robux4 at ycbcr.xyz
Tue Oct 2 09:50:08 CEST 2018
On 01/10/2018 18:58, Rémi Denis-Courmont wrote:
> Le perjantaina 28. syyskuuta 2018, 15.33.34 EEST Filip Roséen a écrit :
>> Hi Remi,
>> On 2018-09-28 15:23, Rémi Denis-Courmont wrote:
>>> Le vendredi 28 septembre 2018, 15:04:33 EEST Filip Roséen a écrit :
>>>> LGTM, as long as we are sure that we will not (once again) step into
>>>> life-time issues related to the ownership of
>>>> `video_format_t.p_palette` (but as it worked before, well.. it at
>>>> least wouldn't get worse than what we had previously).
>>> I have said it before and I will say it again: we should just kill
>>> p_palette so that video format is actually POD like so much code assumes.
>>> The troubles are not worth the benefits. It is just daft to treat
>>> paletized formats as decoded formats nowadays.
>> Mhm, I definitely agree!
>> I have never been a fan of `p_palette`, and given the amount of
>> trouble we have had with lifetime problems due to changes not taking
>> the ownership into account. I would happily see it being
>> *plain-old-data*, and it would save us so much time when we have some
>> obscure patch because of some developer mismatching *copy-by-value* vs
> No, I don't mean to make the palette an array to be copied by value.
> I mean to remove the palette from the video format, where it does not belong.
> Nobody uses palettized video outputs since two decades or so - and none of the
> VLC video display plugins support any.
Actually there's demand for Lookup Table (LUT) based rendering for
professional use. To match each color exactly with the source. I think
that would use the same mechanism and needs to be handled in the video
output if possible. libplacebo already supports it AFAIK.
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel