[x265] [PATCH] Backed out changeset: fef63866bb60

[Pradeep Ramachandran]

On Wed, May 29, 2019 at 8:01 PM Vittorio Giovara <vittorio.giovara at gmail.com>
wrote:

>
>
> On Wed, May 29, 2019 at 12:10 AM Pradeep Ramachandran <
> pradeep at multicorewareinc.com> wrote:
>
>> On Mon, Apr 1, 2019 at 11:06 PM Vittorio Giovara <
>> vittorio.giovara at gmail.com> wrote:
>>
>>>
>>>
>>> On Wed, Mar 13, 2019 at 11:49 AM Vittorio Giovara <
>>> vittorio.giovara at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Mar 13, 2019 at 10:41 AM Pradeep Ramachandran <
>>>> pradeep at multicorewareinc.com> wrote:
>>>>
>>>>> On Tue, Mar 12, 2019 at 10:21 PM Vittorio Giovara <
>>>>> vittorio.giovara at gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Mar 12, 2019 at 12:11 PM Aruna Matheswaran <
>>>>>> aruna at multicorewareinc.com> wrote:
>>>>>>
>>>>>>> Thanks for the pointers, Vittorio. CTA-861.3-A specification states
>>>>>>> that if both MaxCLL and MaxFALL are signaled as 0, the rendering device
>>>>>>> shall interpret it as unknown.
>>>>>>>
>>>>>>
>>>>>> Thanks for your response, I am aware of this and it logically makes
>>>>>> sense.
>>>>>>
>>>>>> With this reference, x265 by default is signaling 0 for both MaxCLL
>>>>>>> and MaxFALL with the assumption that any logical implementation of the
>>>>>>> specification would ignore them.
>>>>>>>
>>>>>>
>>>>>> This part I don't understand. The possibility of avoiding sending
>>>>>> this SEI is just one if clause, what is the purpose of encoding an empty
>>>>>> message? Is it a requirement for some other specification? Does it serve a
>>>>>> private x265 use? Nothing wrong in either, but please have it documented
>>>>>> somewhere.
>>>>>>
>>>>>> The problem we see now is that your renderer interprets 0 content
>>>>>>> light levels as valid values and displays too dark or too bright pixels.
>>>>>>> Whereas a few other renderers don't accept NULL entries for content light
>>>>>>> levels and expect 0 content light level as a signal to disable/ignore their
>>>>>>> usage.
>>>>>>>
>>>>>>
>>>>>> Unfortunately though it is not *my* renderer, but it's the renderer
>>>>>> of some tvs and devices in the wild, over which I have no control.
>>>>>>
>>>>>> Will introducing *an additional param flag to enable signaling of
>>>>>>> only mastering display metadata *fix your problem? With this,
>>>>>>> renderers which don't accept NULL content light level entries shall use the
>>>>>>> default 0 signaling. On the other hand, renderers which treat 0 content
>>>>>>> light level as valid entries shall disable signaling them via the
>>>>>>> additional flag. Please share your thoughts on this suggestion.
>>>>>>>
>>>>>>
>>>>>> This would kind of work but I do not believe it's a proper solution.
>>>>>> At most, the default behavior should be the one of least expected surprise:
>>>>>> if message is empty just don't encode it. Then if a sensible usecase really
>>>>>> exists, there should be an option to force encode light level even if
>>>>>> empty. However it's still unclear why you would need to that in the first
>>>>>> place, as trusting decoders to do the right thing is not very efficient and
>>>>>> leads to a catch-a-mole experience.
>>>>>>
>>>>>
>>>>> We have other users who've come back to us with the report that that
>>>>> unless maxCLL and maxFALL  are signalled as (0,0), their decoder/renderer
>>>>> is decoding this as an invalid HDR10 stream. (My email earlier about
>>>>> non-HDR10 streams was incorrect; please ignore that.) Your use case is that
>>>>> your decoder interprets (0,0) as a valid value and renders the pixels
>>>>> incorrectly! As this SEI message is pass-through for the encoder, we just
>>>>> went back to the standard and did what we thought was the right
>>>>> interpretation of the standard, and that was to signal *all* HDR10 params
>>>>> when *any* HDR10 param was non-zero. And we had another request from a user
>>>>> asking for having the ability to always signal HDR10 SEIs even when they
>>>>> were zero and that is why we added the --hdr option. (In hind-sight, we
>>>>> should've called this --hdr10, but we will live with it for now.) Now, your
>>>>> use-case is that you want a sub-set of the HDR10 SEIs to be signaled and
>>>>> not the others. Maybe adding separate flags for force-signalling them
>>>>> separately is the best option here, but so many flags isn't a good thing!
>>>>>
>>>>
>>>> A couple of points here:
>>>> - it's not "my decoder", but decoders installed on *some* tvs and
>>>> *some* devices. I have no control over those devices and I can't even
>>>> gather data about which devices these are
>>>> - I am not using the --hdr(10) option from the command line interface,
>>>> this all comes from the API. While I can expect some kind of automatic when
>>>> using the CLI, the API itself should not "surprise-encode" messages that
>>>> weren't explicitly enabled (especially if empty
>>>> - hdr10 is mostly a commercial term, it's not a real "standard" per se
>>>> but a collection of specifications stitched together. There is no such
>>>> thing as "invalid hdr10 stream" because there is no conformance to adhere
>>>> to: decoders or renderers needs to apply whatever information is present in
>>>> the stream, to the best of their support. Some perform better some perform
>>>> worse
>>>> - I disagree with limiting the number of "so many flags": this is a
>>>> video encoder which is not a simple thing to begin with, so exposing more
>>>> knobs to allow more in-tune configuration to "expert" users is actually
>>>> appreciated (to a limit)
>>>> - I agree --hdr should have been called --hdr10 but it's never too late
>>>> to add/deprecate that, especially when major bumps are around ;)
>>>> --
>>>> Vittorio
>>>>
>>>
>>> ping I suppose
>>>
>>
>> Changeset ccc7a3edd595 has a new cli that we've added to enable cll
>> separately. Does that fix the problems that you're reporting?
>>
>
> The cli portion is not needed for my usecase as I'm an API user, but the
> internal changes should indeed fix the problem.
> Thank you
>

Thanks. We're glad this fixes your problem.

Btw, even if you're an API user, we recommend that you go through the
x265_param_parse() function, and use the cli names to set the params. This
enables leveraging the automatic checks of the library, and ensures
consistency.


> --
> 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/20190531/a36b4e7a/attachment.html>