<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 29, 2019 at 12:10 AM Pradeep Ramachandran <<a href="mailto:pradeep@multicorewareinc.com">pradeep@multicorewareinc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Mon, Apr 1, 2019 at 11:06 PM Vittorio Giovara <<a href="mailto:vittorio.giovara@gmail.com" target="_blank">vittorio.giovara@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 13, 2019 at 11:49 AM Vittorio Giovara <<a href="mailto:vittorio.giovara@gmail.com" target="_blank">vittorio.giovara@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 13, 2019 at 10:41 AM Pradeep Ramachandran <<a href="mailto:pradeep@multicorewareinc.com" target="_blank">pradeep@multicorewareinc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Tue, Mar 12, 2019 at 10:21 PM Vittorio Giovara <<a href="mailto:vittorio.giovara@gmail.com" target="_blank">vittorio.giovara@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 12, 2019 at 12:11 PM Aruna Matheswaran <<a href="mailto:aruna@multicorewareinc.com" target="_blank">aruna@multicorewareinc.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"><div>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. </div></div></div></blockquote><div><br></div><div>Thanks for your response, I am aware of this and it logically makes sense.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"><div>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.<br></div></div></div></blockquote><div><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"><div>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. </div></div></div></blockquote><div><br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"><div></div><div>Will introducing <b>an additional param flag to enable signaling of only mastering display metadata </b>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.</div></div></div></blockquote><div><br></div><div>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.<br></div></div></div></div></blockquote><div><br></div><div>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!</div></div></div></blockquote><div><br></div><div>A couple of points here:</div><div>- 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</div><div>- 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</div><div>- 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<br></div><div>- 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)<br></div><div>- I agree --hdr should have been called --hdr10 but it's never too late to add/deprecate that, especially when major bumps are around ;)<br></div></div>-- <br><div dir="ltr" class="gmail-m_7645114861532446292gmail-m_6951756653735201434gmail-m_620989680499630593gmail_signature">Vittorio</div></div>
</blockquote></div><br clear="all"></div>ping I suppose<br></div></blockquote><div><br></div><div>Changeset ccc7a3edd595 has a new cli that we've added to enable cll separately. Does that fix the problems that you're reporting?</div></div></div></blockquote></div><div><br></div><div>The cli portion is not needed for my usecase as I'm an API user, but the internal changes should indeed fix the problem.</div><div>Thank you<br></div>-- <br><div dir="ltr" class="gmail_signature">Vittorio</div></div>