Again, sincere apologies for the late response. The latest file looks good to me. Not necessary to change, but my new Google affiliation address is: 315 Hudson St, New York, NY 10013 United States of America
On Thu, Feb 20, 2025 at 2:21 PM Megan Ferguson < mfergu...@staff.rfc-editor.org> wrote: > All, > > Thank you for your replies. We have updated according to the responses we > have received thus far to the document—specific and cluster-wide queries. > > We had the following questions/comments to (hopefully) finish the list of > queries out: > > 1) Related to the cluster-wide bit name question: we suggest making no > changes to this document as we were able to glean these names from the > existing in-document descriptions (and no pattern seems to be changing in > RFC 9626 to use “the X (name) bit” format). > > 2) Jonathan - please review the suggested text that uses “module” where > the document used “modulo”. We will await your reply prior to closing this > out. > > > Same item next paragraph, I realized the wording as written technically > contradicts the first paragraph. The last sentence should read “Every > picture containing a frame with show_frame==1, however, MUST have a unique > timestamp module the 2^32 wrap of the field.” I.e., add “picture containing > a” after “Every”. > > 3) Just a reminder that this document has a question out to the WG and > that IANA updates to match the changes in the Media Type Registration in > Section 7 will be requested once all author approvals are received (as > possible delays to moving forward in the publication process). > > Please review the files carefully as we do not make changes after > publication. > > 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) > https://www.rfc-editor.org/authors/rfc9628-lastrfcdiff.html (ditto but > side by side) > > Please contact us with any further updates/questions/comments you may > have. > > We will await approvals from each of the parties listed on the AUTH48 > status page prior to moving forward to publication. > > The AUTH48 status page for this document is available here: > > https://www.rfc-editor.org/auth48/rfc9628 > > Thank you. > > RFC Editor/mf > > > On Feb 19, 2025, at 3:13 PM, Jonathan Lennox <jonathan.len...@8x8.com> > wrote: > > > > > > > >> On Feb 19, 2025, at 3:05 PM, Megan Ferguson < > mfergu...@staff.rfc-editor.org> wrote: > >> > >> 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. > > > > After Figure 3: “Except as noted, the following field descriptions apply > to the payload descriptor formats in both Figure 2 and Figure 3.” > (Word-smith as needed.) > > > >>>>>>> 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 (?). > > > > I’ve sent the change to the mailing list, just to avoid any worry. > > > >>>>>>> 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. > > > > On re-reading the text, no, I’m sorry, I was confused; this should stay > TID. (TID is the actual protocol element, T is the temporary value > introduced for explaining the semantics of a switching up point.). (I was > confusing this change with the change to align the uses of “S” in section 3 > and of “T” in the definition of “U” in 4.2.) > > > > > > > > I have a few other changes, as well: > > > > The note in section 3 should only include the single paragraph beginning > ’Note: A "Picture Group” or “PG”, …”. The subsequent paragraph “The SS > data” should not be part of the note. > > > > in section 4.1 item “Marker Bit (M)", you’ve missed an instance of > spelling out numbers. Following the general style changes you’ve made > elsewhere, I think “otherwise, it is 0” should be “otherwise, it is zero”, > unless I’m missing some subtlety of the style guide. > > > > In section 4.1 item “Timestamp”, the change of “multiple layer” to > “multiple-layer” is wrong. Since “layer frame” is not otherwise a term, I > think changing it “if the picture is encoded with multiple frames” would be > better. > > > > Same item next paragraph, I realized the wording as written technically > contradicts the first paragraph. The last sentence should read “Every > picture containing a frame with show_frame==1, however, MUST have a unique > timestamp module the 2^32 wrap of the field.” I.e., add “picture > containing a” after “Every”. > > > > Section 4.2 “B”: another numeric bit state, “1” should be “one” > presumably. > > > > Section 4.2 “E”: again, “0” should be “zero”. > > > > Section 4.3 “Layer indices”: there should be a “the” before “Temporal > Layer 0 Picture Index (8 bits)”, i.e. “…another octet is used to represent > the Temporal Layer 0 Picture Index (8 bits) (TL0PICIDX), …”. > > > > > > > > > >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
