[x265] [PATCH] Backed out changeset: fef63866bb60

Pradeep Ramachandran pradeep at multicorewareinc.com
Mon Mar 11 04:47:47 CET 2019


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.

-- 
> 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/0e2ab985/attachment-0001.html>


More information about the x265-devel mailing list