[x265] [PATCH] Backed out changeset: fef63866bb60

[Vittorio Giovara]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20190313/8a3d67cd/attachment-0001.html>