On Mon, Apr 1, 2019 at 11:06 PM Vittorio Giovara <[email protected]> wrote:
> > > On Wed, Mar 13, 2019 at 11:49 AM Vittorio Giovara < > [email protected]> wrote: > >> >> >> On Wed, Mar 13, 2019 at 10:41 AM Pradeep Ramachandran < >> [email protected]> wrote: >> >>> On Tue, Mar 12, 2019 at 10:21 PM Vittorio Giovara < >>> [email protected]> wrote: >>> >>>> >>>> >>>> On Tue, Mar 12, 2019 at 12:11 PM Aruna Matheswaran < >>>> [email protected]> 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? > -- > Vittorio > _______________________________________________ > x265-devel mailing list > [email protected] > https://mailman.videolan.org/listinfo/x265-devel >
_______________________________________________ x265-devel mailing list [email protected] https://mailman.videolan.org/listinfo/x265-devel
