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
