Authors and *Zahed (see question 10), Thank you for your replies.
We have listed the document-specific queries that still require author input below. Note that you are welcome to make updates directly to the edited XML file linked in this email if this would be more convenient than explaining a change over email. >> >> 7) <!--[rfced] Section 4.2: It seems the descriptions following Figure 3 >> apply to both Figures 2 and 3. If that is so, might a note of this >> appear somewhere earlier in that section for the ease of the reader?--> > > > Yes, that’s a good idea. Let me know if you want me to draft text, or if you > want to draft it. [rfced] Looks like this one fell off the map. We would love some draft text and guidance on placement. >> >> 10) <!--[rfced] If TID expands to "temporal layer ID", does this text say >> >> "with TID equal to TID"? Please clarify (and see our related >> >> cluster-wide question). >> >> >> >> Original: >> >> If this bit is set to 1 for the current picture with temporal layer ID >> >> equal to TID... >> >> >> >> --> >> > >> > Yes, that’s poorly worded, but I’m having some trouble expressing it >> > clearly. >> > >> > The sentence is trying to talk about a specific frame’s value of SID, so >> > that it can talk about that value later in the sentence. >> > >> > Possibly change the variable to “T”, as in: >> > >> > Switching up point. If this bit is set to 1 for the current picture with a >> > temporal-layer ID equal to T, then "switch up" to a higher frame rate is >> > possible as subsequent higher temporal-layer pictures will not depend on >> > any picture before the current picture (in coding order) with >> > temporal-layer ID greater than T.¶ >> > >> > >> > The point is that when the bit is set, then if the current frame has a >> > temporal-layer ID value X, then subsequent frames with TID>X will not >> > depend on earlier frames with TID>X. >> > >> > Can you help me come up with a clearer way to express this? >> >> Perhaps: >> Switching up point. When this bit is set to 1, if the current picture has a >> temporal-layer ID equal to value T, then subsequent pictures with >> temporal-layer ID values higher than T will not depend on any picture before >> the current picture (in coding order) with a temporal-layer ID value greater >> than T. >> >> This should be OK. However, as we are introducing a new variable, I would >> like the authors to ping the working group to see if there could be any >> issues with that or not. Authors please send an email to the mailing list >> regarding this proposal. > > This isn’t a new variable semantically, it’s just naming a nonce value to > express the existing concept more clearly. Do you really think it needs WG > approval? > > It's not a MUST, but I would be good to inform the wg about this change. [rfced] We have updated the text as described in the “Perhaps” text above. *Zahed - We will await further guidance regarding if we need to hold until WG consultation is complete (?). > >> >> 11) <!--[rfced] We note that not all fields that appear in Figure 4 are >> >> described following it. Please review and let us know if text >> >> (or a pointer to where the reader can get more information on >> >> these fields) should be added. >> >> >> >> --> >> > >> > R is only specified in the diagram - it is the number of P_DIFF fields >> > that are present. (I agree this is not great.) TID, U, and P_DIFF have the >> > same semantics as they do in the previous section, except that they apply >> > to the picture described in the picture group, rather than the current >> > picture. >> >> -Regarding question 11, please provide any updates you would like us to make >> to add description or pointers to descriptions for the items in the figure. >> >> I will wait for the authors to respond to it. I noted that here we use TID, >> this should be changed to T according to the previous change, right? > > Agreed, these two descriptions should be parallel. [rfced] As TID appears in the figure and a few descriptions, please let us know how and where this change should be made using Old/New or updating the edited XML file accessible through the link above. We have otherwise updated the file with your responses to the cluster-wide and document-specific queries we have received to date (see below). Please review these updates carefully as we do not make changes once the document is published as an RFC. Note that we will await the following prior to moving forward in the publication process: -responses to the above document-specific queries including guidance from *Zahed regarding any WG action necessary -resolution of outstanding cluster-wide queries (see separate email thread) -approvals from each author -confirmation from IANA that updates to the appropriate registries have been made to match the document (once all authors have approved) The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9628.txt https://www.rfc-editor.org/authors/rfc9628.pdf https://www.rfc-editor.org/authors/rfc9628.html https://www.rfc-editor.org/authors/rfc9628.xml The relevant diff files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9628-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9628-auth48diff.html (AUTH48 changes only) https://www.rfc-editor.org/authors/rfc9628-lastdiff.html (last to current version only) The AUTH48 status page for this document is available here: https://www.rfc-editor.org/auth48/rfc9628 The AUTH48 status page for this cluster is available here: https://www.rfc-editor.org/auth48/C324 Please contact us with any further updates/questions/comments you may have. Thank you. RFC Editor/mf -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
