> On Feb 20, 2025, at 2:21 PM, Megan Ferguson <mfergu...@staff.rfc-editor.org> > wrote: > > > 3) Regarding the response to our cluster-wide question about bit names > (moving to this thread as now document-specific), Jonathan said: >> In 9627: >> C could be described as “Current layer information present” or “CTID and >> CLID present” if you want a name for it. >> Y is used in this document to reference the “Y” bit defined in RFC 7741, >> where it is named “1 layer sync bit”. > … >> I’m not sure what’s the best way to use this information, however. > > Perhaps no change to C as we already have: > > C (1 bit): > A flag bit indicating whether the Current Temporal-layer ID (CTID) > and Current Layer ID (CLID) fields are present in the FCI. If > this bit is 0, the sender of the LRR message is requesting refresh > of all layers up to and including the target layer.
That seems good. > Perhaps just a citation for Y?: > A VP8 layer refresh point can be identified by the presence of the Y > bit (see [RFC7741]) in the VP8 payload header. Agreed. > 4) Please review points 3 and 4 from Madison’s mail (originally sent 13 > February) and let us know how you would like to proceed. Note also that we > will assume the other actions she described us taking in that same mail are > acceptable unless we hear objection. > >> >> >>>>> 10) <!--[rfced] We had the following questions related to the >>>>> abbreviations and initialisms used throughout the document: >>>>> >>>>> a) In the following equation, will it be clear to the reader what TO >>>>> and TN refer to? >>>>> >>>>> TID = TO and target TID = TN >>>>> >>>>> If these are abbreviations, they should be expanded on first use (per >>>>> RFC 7322). >>> >>> These are nonce variables so we can talk about the specific values of CTID >>> and TTID sent in a hypothetical LRR message. Is there a clearer way to >>> express this? >> >> 3) Thank you for the clarification! Perhaps adding a note at the end of the >> sentence would clarify this for readers? >> >> Current: >> In this case, given current TID = TO and target TID = TN, layer refresh to >> TN is satisfied when a >> NAL unit type of 2 or 3 is seen for TID = T1, then TID = T2, all the way up >> to TID = TN. >> >> Perhaps: >> In this case, given current TID = TO and target TID = TN, layer refresh to >> TN is satisfied when a >> NAL unit type of 2 or 3 is seen for TID = T1, then TID = T2, all the way up >> to TID = TN (note that >> TN and TO refer to nonce variables in this instance). If you think that’s clearer, it works for me. >> 4) We have removed quotes surrounding field names upon first use for >> consistency. Also, please note that the following terms still need review: >> > [snip] >> Current Layer ID (CLID) vs. Current Layer Index Note the last paragraph of section 2: A "layer index" is a numeric label for a specific spatial and temporal layer of a scalable stream. It consists of both a "temporal-layer ID" identifying the temporal layer and a "layer ID" identifying the spatial or quality layer. The details of how layers of a scalable stream are labeled are codec specific. Details for several codecs are defined in Section 4 <https://www.rfc-editor.org/authors/rfc9627.html#codec-details>.¶ <https://www.rfc-editor.org/authors/rfc9627.html#section-2.1-17> So these are two separate things. > > 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/rfc9627.txt > https://www.rfc-editor.org/authors/rfc9627.pdf > https://www.rfc-editor.org/authors/rfc9627.html > https://www.rfc-editor.org/authors/rfc9627.xml > > The relevant diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9627-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9627-auth48diff.html (AUTH48 changes > only) > https://www.rfc-editor.org/authors/rfc9627-lastdiff.html (last to current > version only) > https://www.rfc-editor.org/authors/rfc9627-lastrfc diff.html (las to > current 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/rfc9627 > > Thank you. > > RFC Editor/mf > >> On Feb 20, 2025, at 12:06 AM, Justin Uberti <jus...@uberti.name> wrote: >> >> A few very minor nits that I encountered when reviewing this document: >> - the RFC9626 reference for frame marking mistakenly refers to RFC 9621 >> - the headings for Section 4 should probably include punctuation, e.g,. >> H.264/SVC, VP8, H.265 >> - my affiliation is now OpenAI rather than Google >> >> Thanks, >> Justin >> >> On Wed, Feb 19, 2025 at 2:28 PM Jonathan Lennox <jonathan.len...@8x8.com> >> wrote: >> A few changes: >> >> Section 2.1: since “FIR” is usually pronounced “eff-eye-arr” not “fir” like >> the tree, it begins with a vowel sound. Thus, presumably the second >> sentence of the third paragraph should be “This is the difference between a >> layer refresh and an FIR [RFC5104]”. I.e. “an” rather than “a”. >> >> Section 2.1 again, paragraphs after the figures: the text should remain >> “spatial layer S1” and “spatial layer S0”, not hyphenated. In this usage >> “spatial layer” is a noun, describing specific spatial layers named “S0” or >> “S1”, not an adjective. >> >> Section 3, third paragraph, should start “The design of LRR” (not “An LRR”), >> since this is discussing the overall mechanism, not a specific message. >> >>> 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: >>>> >>>> Greetings, >>>> >>>> This document has been updated with the responses to our cluster-wide >>>> queries we have received to date. 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 follow-up questions sent by Madison (see previous email) >>>> -resolution of outstanding cluster-wide issues (see separate email thread) >>>> -approvals from each author >>>> >>>> The files have been posted here (please refresh): >>>> https://www.rfc-editor.org/authors/rfc9627.txt >>>> https://www.rfc-editor.org/authors/rfc9627.pdf >>>> https://www.rfc-editor.org/authors/rfc9627.html >>>> https://www.rfc-editor.org/authors/rfc9627.xml >>>> >>>> The relevant diff files have been posted here (please refresh): >>>> https://www.rfc-editor.org/authors/rfc9627-diff.html (comprehensive diff) >>>> https://www.rfc-editor.org/authors/rfc9627-auth48diff.html (AUTH48 changes >>>> only) >>>> https://www.rfc-editor.org/authors/rfc9627-lastdiff.html (last to current >>>> version only) >>>> >>>> The AUTH48 status page for this document is available here: >>>> https://www.rfc-editor.org/auth48/rfc9627 >>>> >>>> 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 >>>> >>>>> On Feb 13, 2025, at 10:36 AM, Madison Church >>>>> <mchu...@staff.rfc-editor.org> wrote: >>>>> >>>>> Hi Jonathan, >>>>> >>>>> Thank you for your reply! We have updated the document per your response. >>>>> Please see the thread below for followup comments and updated files. >>>>> >>>>>>>> 3) <!--[rfced] We had the following questions regarding Section 2. >>>>>>>> Section 2 was titled "Conventions, Definitions, and Acronyms". >>>>>>>> It contains the BCP 14 boilerplate and a single subsection that >>>>>>>> is titled "Terminology". >>>>>>>> >>>>>>>> a) There is no list of acronyms in this section. Please review our >>>>>>>> updates to the title of this section and let us know any objections >>>>>>>> (of if a list of abbreviations was missing). >>>>>>>> >>>>>>>> Original: >>>>>>>> Conventions, Definitions and Acronyms >>>>>>>> >>>>>>>> Current: >>>>>>>> Conventions and Terminology >>>>>> >>>>>> That’s fine. >>>>>> >>>>>>>> b) We see several terms throughout the document that it may be useful >>>>>>>> to include in this section (as they are seemingly introduced in >>>>>>>> sections that follow). For example: >>>>>>>> >>>>>>>> temporally nested >>>>>>>> Layer Index >>>>>>>> temporal ID >>>>>>>> layer ID >>>>>>>> >>>>>>>> Please let us know if you'd like to add any terms to the Terminology >>>>>>>> section. >>>>>>>> --> >>>>>> >>>>>> Aren’t these all already defined in Section 2, or am I missing something? >>>>> >>>>> 1) Thank you for pointing this out. When re-reviewing Section 2.1, it >>>>> looks like the highlighted terms in question 3b are defined. >>>>> >>>>> For example (paragraph above Section 3): >>>>> "A 'layer index' is a numeric label for a specific spatial and >>>>> temporal layer of a scalable stream." >>>>> >>>>> We have left the definitions as is in this section. >>>>> >>>>>>>> 6) <!--[rfced] In the text below, are you referring to the title of the >>>>>>>> document? >>>>>>>> >>>>>>>> Original: >>>>>>>> If the payload also specifies how it is used with the Frame Marking >>>>>>>> RTP Header Extension [I-D.ietf-avtext-framemarking], the syntax MUST >>>>>>>> be defined in the same manner as the TID and LID fields in that >>>>>>>> header. >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> If the payload also specifies how it is used with "Video Frame Marking >>>>>>>> RTP Header Extension" [RFC9626], the syntax MUST be defined in the >>>>>>>> same manner as the TID and LID fields in that header. >>>>>>>> >>>>>>>> Or perhaps: >>>>>>>> If the payload also specifies how it is used with the [Video?] Frame >>>>>>>> Marking RTP Header Extension described in [RFC9626], the syntax MUST >>>>>>>> be defined in the same manner as the TID and LID fields in that >>>>>>>> header. >>>>>>>> --> >>>>>> >>>>>> The latter seems good, including the word “Video”. >>>>> >>>>> 2) We have updated the sentence above to use the second option. If there >>>>> are any additional changes needed to the text above (in reference to the >>>>> current status of RFC 9626), please let us know and we will make those >>>>> updates as well. >>>>> >>>>>>>> 10) <!--[rfced] We had the following questions related to the >>>>>>>> abbreviations and initialisms used throughout the document: >>>>>>>> >>>>>>>> a) In the following equation, will it be clear to the reader what TO >>>>>>>> and TN refer to? >>>>>>>> >>>>>>>> TID = TO and target TID = TN >>>>>>>> >>>>>>>> If these are abbreviations, they should be expanded on first use (per >>>>>>>> RFC 7322). >>>>>> >>>>>> These are nonce variables so we can talk about the specific values of >>>>>> CTID and TTID sent in a hypothetical LRR message. Is there a clearer >>>>>> way to express this? >>>>> >>>>> 3) Thank you for the clarification! Perhaps adding a note at the end of >>>>> the sentence would clarify this for readers? >>>>> >>>>> Current: >>>>> In this case, given current TID = TO and target TID = TN, layer refresh >>>>> to TN is satisfied when a >>>>> NAL unit type of 2 or 3 is seen for TID = T1, then TID = T2, all the way >>>>> up to TID = TN. >>>>> >>>>> Perhaps: >>>>> In this case, given current TID = TO and target TID = TN, layer refresh >>>>> to TN is satisfied when a >>>>> NAL unit type of 2 or 3 is seen for TID = T1, then TID = T2, all the way >>>>> up to TID = TN (note that >>>>> TN and TO refer to nonce variables in this instance). >>>>> >>>>>>>> b) We see: >>>>>>>> >>>>>>>> CLID - Current Layer ID >>>>>>>> >>>>>>>> and also Current Layer Index (or current layer indices or layer >>>>>>>> indices) >>>>>>>> >>>>>>>> Please review these occurrences and let us know if they should be made >>>>>>>> uniform. >>>>>>>> 11) <!--[rfced] We had the following questions related to the >>>>>>>> terminology >>>>>>>> used throughout the document. >>>>>>>> >>>>>>>> a) Please review the way field names are treated with regard to >>>>>>>> capitalization and quotation and let us know if/how they should be >>>>>>>> made uniform. >>>>>>>> >>>>>>>> For example, we see: >>>>>>>> >>>>>>>> "R" field >>>>>>>> "RES" field >>>>>>>> layer index field >>>>>>>> LayerId field vs. layer ID field vs. LID field (see related cluster >>>>>>>> query) >>>>>>>> "media source" field >>>>>>>> "Current Temporal Layer ID (CTID)" and "Current Layer ID (CLID)" fields >>>>>>>> payload type field >>>>>>>> "SSRC of packet sender" field >>>>>>>> DID, QID, and TID fields >>>>>>>> --> >>>>>> >>>>>> I think I’ve tended to use quotes on first reference to a field, and not >>>>>> use them subsequently, but if you think that’s confusing feel free to >>>>>> remove them. >>>>>> >>>>>> I think I’ve also tended to use capitalization when referring to a >>>>>> protocol element and use plain English when referring to the abstract >>>>>> concept carried in that protocol element, but if you want to normalize >>>>>> them that's fine. >>>>> >>>>> 4) We have removed quotes surrounding field names upon first use for >>>>> consistency. Also, please note that the following terms still need review: >>>>> >>>>> LayerId field vs. layer ID field vs. LID field (see related cluster query) >>>>> Current Layer ID (CLID) vs. Current Layer Index >>>>> >>>>> >>>>> The updated files have been posted here (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9627.txt >>>>> https://www.rfc-editor.org/authors/rfc9627.pdf >>>>> https://www.rfc-editor.org/authors/rfc9627.html >>>>> https://www.rfc-editor.org/authors/rfc9627.xml >>>>> >>>>> The updated diff files have been posted here (please refresh): >>>>> https://www.rfc-editor.org/authors/rfc9627-diff.html (comprehensive diff) >>>>> https://www.rfc-editor.org/authors/rfc9627-rfcdiff.html (side by side) >>>>> https://www.rfc-editor.org/authors/rfc9627-auth48diff.html (AUTH48 >>>>> changes) >>>>> https://www.rfc-editor.org/authors/rfc9627-auth48rfcdiff.html (side by >>>>> side) >>>>> >>>>> For the AUTH48 status of this document, please see: >>>>> https://www.rfc-editor.org/auth48/rfc9627 >>>>> >>>>> Thank you, >>>>> RFC Editor/mc >>>>> >>>> >>>> >>>> >>>> >>>> >>> >> >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
