Apologies for the noise, resending with our current email (please reply to this address)
> On Feb 19, 2025, at 12:48 PM, Megan Ferguson <mfergu...@amsl.com> wrote: > > 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
