[x265] [PATCH] Backed out changeset: fef63866bb60

[Pradeep Ramachandran]

On Mon, Mar 11, 2019 at 9:17 AM Pradeep Ramachandran <
pradeep at multicorewareinc.com> wrote:

> On Sat, Mar 9, 2019 at 2:14 AM Vittorio Giovara <
> vittorio.giovara at gmail.com> wrote:
>
>>
>>
>> On Fri, Mar 8, 2019 at 12:27 AM Pradeep Ramachandran <
>> pradeep at multicorewareinc.com> wrote:
>>
>>> # HG changeset patch
>>> # User Pradeep Ramachandran <pradeep at multicorewareinc.com>
>>> # Date 1552022473 -19800
>>> #      Fri Mar 08 10:51:13 2019 +0530
>>> # Node ID 636258ebc7a90e0a35466e9b605ab335b9ce2194
>>> # Parent  0eccd62725b6a24ae27d52189c4a624dffdd7a07
>>> Backed out changeset: fef63866bb60
>>>
>>> diff -r 0eccd62725b6 -r 636258ebc7a9 source/encoder/encoder.cpp
>>> --- a/source/encoder/encoder.cpp        Mon Mar 04 15:36:38 2019 +0530
>>> +++ b/source/encoder/encoder.cpp        Fri Mar 08 10:51:13 2019 +0530
>>> @@ -2459,13 +2459,10 @@
>>>
>>>      if (m_param->bEmitHDRSEI)
>>>      {
>>> -        if (m_emitCLLSEI)
>>> -        {
>>> -            SEIContentLightLevel cllsei;
>>> -            cllsei.max_content_light_level = m_param->maxCLL;
>>> -            cllsei.max_pic_average_light_level = m_param->maxFALL;
>>> -            cllsei.writeSEImessages(bs, m_sps, NAL_UNIT_PREFIX_SEI,
>>> list, m_param->bSingleSeiNal);
>>> -        }
>>> +        SEIContentLightLevel cllsei;
>>> +        cllsei.max_content_light_level = m_param->maxCLL;
>>> +        cllsei.max_pic_average_light_level = m_param->maxFALL;
>>> +        cllsei.writeSEImessages(bs, m_sps, NAL_UNIT_PREFIX_SEI, list,
>>> m_param->bSingleSeiNal);
>>>
>>>          if (m_param->masteringDisplayColorVolume)
>>>          {
>>>
>>
>> Why?
>>
>> It would be *really* nice if this kind of information was provided in the
>> commit message without having to ask it every time.
>> Like in the commit that is being removed: "Some devices render
>> out-of-luminance pixels incorrectly otherwise."
>>
>> So, NAK until further explanation is provided.
>>
>
> Apologies for not clarifying why in the commit message.
>
> The reason for backing this commit out was because we got some error
> reports that some packagers were treating the streams that didn't have this
> set correctly as non-HDR10 streams and that wasn't ok. Verifiers like the
> DoViES verifiers were complaining, and that was a problem for some users
> breaking their streams.
>

And I forgot to mention that the --hdr option was added to force signalling
of HDR params even with 0 max-cll values (please see docs at
https://x265.readthedocs.io/en/latest/cli.html#cmdoption-hdr).
Does excluding the --hdr option from your cli not suffice for your
use-case? The only situation I can think of is having master-display but
with 0 max-cll / max-fall values. Is that your use-case?


>
> --
>> Vittorio
>> _______________________________________________
>> x265-devel mailing list
>> x265-devel at videolan.org
>> https://mailman.videolan.org/listinfo/x265-devel
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20190311/0ee5e275/attachment.html>