On Fri, Feb 7, 2025 at 9:21 PM Jonathan Lennox <jonathan.len...@8x8.com> wrote:
> > > On Oct 10, 2024, at 6:28 AM, Zaheduzzaman Sarker < > zahed.sarker.i...@gmail.com> wrote: > > > > On Mon, Oct 7, 2024 at 8:35 PM Megan Ferguson <mfergu...@amsl.com> wrote: > >> Zahed, >> >> Thank you for your reply and guidance. >> >> It looks like we note that questions 10, 19, and 21F could also benefit >> from AD approval/guidance on the AUTH48 status page - and we’ve thrown in >> question 11 in case you had thoughts (questions and previous replies copied >> below for your convenience): >> >> >> >> 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. > > > >> 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. > > >> >> >> 19) <!--[rfced] Please review the entry for "Change Controller" in >> Section >> >> 7. While we see similar text for the vp8 and vc2 entries, we want >> to >> >> confirm that this entry has been reviewed with the following in >> >> mind from >> >> https://www.iana.org/help/protocol-registration: >> >> >> >> "The IESG shouldn't be listed as a change controller unless the >> >> RFC that created the registry (e.g. port numbers, XML namespaces >> >> and schemas) requires it. The IETF should be named instead." >> >> >> >> --> >> > >> > I’d be happy for the change controller to be something like "IETF >> AVTCore Working Group delegated from the IETF”, but I think this should be >> an AD question. ADs? >> > > This is fine. > > >> >> >> >> >> >> f) Is N_S an abbreviation for "Number of Spatial layers"? Might the >> >> explanation in Section 4.2.1 be made clearer? >> >> >> >> Original: >> >> N_S: N_S + 1 indicates the number of spatial layers present in the VP9 >> >> stream. >> >> >> >> Perhaps: >> >> N_S: Number of Spatial layers. N_S + 1 indicates the number of >> >> spatial layers present in the VP9 stream. >> > >> > Let’s call it “Number of Spatial Layers Minus 1” to be clear? >> > > why the "plus 1" is becoming "minus 1", is not clear to me. Jonathan, > could you explain? > > //Zahed > > > The semantic value is the number of spatial layers, the protocol element > on the wire is one less than that (since it’s impossible to have zero > spatial layers). > > So if N_S is the protocol element, > > N_S + 1 = number of spatial layers > > Or rearranging > N_S = number of spatial layers minus 1. > I see. It's fine with me. @rfc-editor. Are there any remaining issues with this document other than the author's approval? //Zahed > > > >> We have updated the files to reflect Zahed's guidance for question 6. >> >> 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) >> >> 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 Oct 7, 2024, at 9:36 AM, Zaheduzzaman Sarker < >> zahed.sarker.i...@gmail.com> wrote: >> > >> > Hi, >> > >> > For question 6, I would prefer to pick alternative B, for both cases. >> This option does make it clear without adding the extra "MUST" in the >> sentence, I am expecting the defaults value is Zero here. >> > >> > //Zahed >> > >> > On Tue, Aug 13, 2024 at 6:28 AM <rfc-edi...@rfc-editor.org> wrote: >> > Authors and *AD, >> > >> > [AD - please see question 6 below] >> > >> > While reviewing this document during AUTH48, please resolve (as >> necessary) the following questions, which are also in the XML file. >> > >> > 1) <!--[rfced] Please note that we have updated the title of Section 2 >> to >> > more accurately describe its contents. Please let us know any >> > objections.--> >> > >> > >> > 2) <!--[rfced] Might replacing the slash in the following with "and", >> > "or", or "and/or" be helpful to the reader? >> > >> > Original: >> > ...for a particular resolution/quality,... >> > --> >> > >> > >> > 3) <!-- [rfced] FYI: We've updated the following sentence by adding "a" >> > before "previously coded frame in time". Please let us know if >> > this changes the intended meaning. >> > >> > Original: >> > This "inter-layer" dependency can result in additional coding gain >> > compared to the case where only traditional "inter-picture" >> dependency is >> > used, where a frame depends on previously coded frame in time. >> > >> > Updated: >> > This "inter-layer" dependency can result in additional coding gain >> > compared to the case where only traditional "inter-picture" >> dependency is >> > used, where a frame depends on a previously coded frame in time. >> > --> >> > >> > >> > 4) <!-- [rfced] Please review whether any of the notes in this document >> > should be in the <aside> element. It is defined as "a container for >> > content that is semantically less important or tangential to the >> > content that surrounds it" ( >> https://authors.ietf.org/en/rfcxml-vocabulary#aside). >> > --> >> > >> > >> > 5) <!--[rfced] Should "the specifications" in this text be clarified for >> > the reader? >> > >> > Original: >> > All integer fields in the specifications are encoded as unsigned >> > integers in network octet order. >> > --> >> > >> > >> > 6) <!--[rfced] [*AD] In the following, we believe restructuring the text >> > may clarify the applicability of the BCP 14 keywords (are both >> > parts of the sentence MUSTs?). Please review. >> > >> > Instance 1: >> > >> > Original: >> > Marker bit (M): MUST be set to 1 for the final packet of the highest >> > spatial layer frame (the final packet of the picture), and 0 >> > otherwise. >> > >> > Perhap A: >> > Marker bit (M): This bit MUST be set to 1 for the final packet of >> > the highest spatial-layer frame (the final packet of the picture); >> > otherwise, it MUST be 0. >> > >> > Perhaps B: >> > Marker bit (M): This bit MUST be set to 1 for the final packet of >> > the highest spatial-layer frame (the final packet of the picture); >> > otherwise, it is 0. >> > >> > Instance 2: >> > >> > Original: >> > MUST be set to 1 for the final RTP packet of a >> > VP9 frame, and 0 otherwise >> > >> > Perhaps A: >> > This bit MUST be set to 1 for the final RTP packet of a VP9 frame; >> > otherwise, it MUST be 0. >> > >> > Perhaps B: >> > This bit MUST be set to 1 for the final RTP packet of a VP9 frame; >> > otherwise, it is 0. >> > --> >> > >> > >> > 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?--> >> > >> > >> > 8) <!-- [rfced] FYI: We've removed quotes from around certain bit names, >> > e.g., ""D" bit" for consistency with similar uses in this >> > document. Please let us know if this is not preferred. Please >> > also see our cluster-wide question regarding bit names prior to >> > reply. >> > --> >> > >> > >> > 9) <!--[rfced] Might a clarification of "This information" be helpful >> to the reader? >> > >> > Original: >> > >> > Layer indices: This information is optional but RECOMMENDED whenever >> > encoding with layers. >> > >> > Perhaps: >> > >> > Layer indices: This field is optional but RECOMMENDED whenever >> > encoding with layers. >> > --> >> > >> > >> > 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... >> > >> > --> >> > >> > >> > 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. >> > >> > --> >> > >> > >> > 12) <!--[rfced] Section 5.1 is titled "Reference Picture Selection >> > Indication (RPSI)". The first sentence of this section uses >> > "reference picture selection index". Please review if "index" is >> > correct or if it should be made "indication" (or vice versa).--> >> > >> > >> > 13) <!--[rfced] Please review whether any of the notes in this document >> > should be in the <aside> element. It is defined as "a container >> > for content that is semantically less important or tangential to >> > the content that surrounds it" >> > (https://xml2rfc.tools.ietf.org/xml2rfc-doc.html#name-aside-2). >> > --> >> > >> > >> > 14) <!-- [rfced] In the following sentences: >> > >> > a) does the receiver want to upgrade to {2,1}? How might we clarify >> > "which"? >> > >> > b) please review the use of commas between the braced values. Is our >> > suggestion correct? >> > >> > Original: >> > LRR {1,0}, {2,1} is sent by an MCU when it is currently relaying >> > {1,0} to a receiver and which wants to upgrade to {2,1}. In >> > response the encoder should encode the next frames in layers {1,1} >> > and {2,1} by only referring to frames in {1,0}, or {0,0}. >> > >> > >> > Perhaps: >> > LRR {1,0} {2,1} is sent by an MCU when it is currently relaying >> > {1,0} to a receiver that wants to upgrade to {2,1}. In response, >> > the encoder should encode the next frames in layers {1,1} and {2,1} >> > by only referring to frames in {1,0} or {0,0}. >> > >> > --> >> > >> > >> > 15) <!--[rfced] In the following, please review the use of "value" >> > (singular) and "receivers" (not possessive?). >> > >> > Original: >> > ...where a media sender does not have media available that fits within >> > a receivers max-fs and max-fr value;... >> > >> > Perhaps: >> > ...where a media sender does not have media available that fits within >> > a receiver's max-fs and max-fr values;... >> > >> > --> >> > >> > >> > 16) <!--[rfced] Might adding "each" to the following text be helpful for >> > the reader? Or is the intention that the width and height be >> > taken together? (Same question for the last sentence of this >> > paragraph.) >> > >> > Original: >> > The decoder is capable of decoding this frame size as long as the >> > width and height of the frame in macroblocks are less than >> > int(sqrt(max-fs * 8)) - 8))... >> > >> > Perhaps: >> > The decoder is capable of decoding this frame size as long as the >> > width and height of the frame in macroblocks are each less than >> > int(sqrt(max-fs * 8)) - 8))... >> > >> > --> >> > >> > >> > 17) <!--[rfced] Please note that we have shortened the title of Table 2 >> > and rephrased to avoid awkward hyphenation. Please review and >> > let us know any objections. >> > >> > Original: >> > Table of profile-id integer values representing the VP( profile >> > corresponding to the set of coding tools supported Current: profile-id >> > to VP9 Profile Integer Comparison >> > >> > Current: >> > Comparison of profile-id to VP9 Profile Integer >> > --> >> > >> > >> > 18) <!--[rfced] Please note that after AUTH48 concludes, we will >> > communicate any changes to the media type template in Section 7 >> > to IANA for corresponding updates to >> > https://www.iana.org/assignments/media-types/video/VP9 to be >> > made.--> >> > >> > >> > 19) <!--[rfced] Please review the entry for "Change Controller" in >> Section >> > 7. While we see similar text for the vp8 and vc2 entries, we want >> to >> > confirm that this entry has been reviewed with the following in >> > mind from >> > https://www.iana.org/help/protocol-registration: >> > >> > "The IESG shouldn't be listed as a change controller unless the >> > RFC that created the registry (e.g. port numbers, XML namespaces >> > and schemas) requires it. The IETF should be named instead." >> > >> > --> >> > >> > >> > 20) <!--[rfced] Should any further information on the IANA >> Considerations >> > for the "RTP Payload Format Media Types" registry be given? >> > >> > Perhaps: >> > The media type has also been added to the "RTP Payload Format Media >> > Types" subregistry of th e"Real-Time Transport Protocol (RTP) >> > Parameters" registry as follows: >> > >> > Media Type: video >> > Subtype: VP9 >> > Clock Rate (Hz): 90000 >> > Reference: RFC 9628 >> > --> >> > >> > >> > 21) <!-- [rfced] Terminology and abbreviations: We had the following >> > questions related to terminology or abbreviation use throughout >> > the document. >> > >> > a) The following terms had different forms throughout this >> > document. Please let us know if/how these may be made uniform. >> > >> > reference indices vs. Reference Indices >> > >> > b) We have updated these terms to be the form on the right to match >> > use in the companion documents and/or be consistent within this >> > document. >> > >> > key frame vs. keyframe >> > "max-fs" vs. max-fs >> > "max-fr" vs. max-fr >> > "profile-id" vs. profile-id >> > >> > c) How may we expand "SRGB"? Segment Routing Global Block? If so, >> > would you like to add as a note to the table? Or is this something >> > that could be housed in the Terminology section? >> > >> > d) Is SID expanded to spatial-layer ID? It seems so here: >> > >> > Original: >> > ...temporal-layer ID (TID) and spatial layer ID (SID)... >> > >> > If SID is spatial-layer ID (please also see our cluster-wide question >> > regarding this abbreviation as well as our related question about TID >> > before responding), please review the following text as it seems to >> > state the SID is equal to SID: >> > >> > Original: >> > Within a picture, a frame with spatial layer ID equal to SID... >> > >> > >> > >> > e) We note that TL0PICIDX is expanded in RFC-to-be 9626 as "Temporal >> > Layer 0 Picture Index". Please let us know if/how we may update the >> > following to make this document consistent within the cluster. >> > >> > Original: >> > TL0PICIDX: 8 bits temporal-layer zero index. >> > >> > and >> > >> > ...is used to represent temporal layer 0 index (TL0PICIDX)... >> > >> > Further, may we update to either "8-bit" or rephrase to put this >> > information in parentheses (as was done in RFC 9626)? >> > >> > f) Is N_S an abbreviation for "Number of Spatial layers"? Might the >> > explanation in Section 4.2.1 be made clearer? >> > >> > Original: >> > N_S: N_S + 1 indicates the number of spatial layers present in the VP9 >> > stream. >> > >> > Perhaps: >> > N_S: Number of Spatial layers. N_S + 1 indicates the number of >> > spatial layers present in the VP9 stream. >> > >> > g) Please note that we have expanded these abbreviations as follows. >> > Please let us know any objections. >> > >> > MCU - Multipoint Control Unit (per RFC 5104) >> > >> > --> >> > >> > >> > 22) <!-- [rfced] Please review the "Inclusive Language" portion of the >> > online Style Guide >> > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >> > and let us know if any changes are needed. >> > >> > We see the use of "native" but note that it is a quote from RFC 4585. >> > >> > In addition, please consider whether "tradition" and "traditionally" >> > should be updated for clarity. While the NIST website >> > < >> https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1 >> > >> > indicates that this term is potentially biased, it is also ambiguous. >> > "Tradition" is a subjective term, as it is not the same for everyone. >> > --> >> > >> > >> > Thank you. >> > >> > RFC Editor/mf >> > >> > *****IMPORTANT***** >> > >> > Updated 2024/08/12 >> > >> > RFC Author(s): >> > -------------- >> > >> > Instructions for Completing AUTH48 >> > >> > Your document has now entered AUTH48. Once it has been reviewed and >> > approved by you and all coauthors, it will be published as an RFC. >> > If an author is no longer available, there are several remedies >> > available as listed in the FAQ (https://www.rfc-editor.org/faq/). >> > >> > You and you coauthors are responsible for engaging other parties >> > (e.g., Contributors or Working Group) as necessary before providing >> > your approval. >> > >> > Planning your review >> > --------------------- >> > >> > Please review the following aspects of your document: >> > >> > * RFC Editor questions >> > >> > Please review and resolve any questions raised by the RFC Editor >> > that have been included in the XML file as comments marked as >> > follows: >> > >> > <!-- [rfced] ... --> >> > >> > These questions will also be sent in a subsequent email. >> > >> > * Changes submitted by coauthors >> > >> > Please ensure that you review any changes submitted by your >> > coauthors. We assume that if you do not speak up that you >> > agree to changes submitted by your coauthors. >> > >> > * Content >> > >> > Please review the full content of the document, as this cannot >> > change once the RFC is published. Please pay particular attention >> to: >> > - IANA considerations updates (if applicable) >> > - contact information >> > - references >> > >> > * Copyright notices and legends >> > >> > Please review the copyright notice and legends as defined in >> > RFC 5378 and the Trust Legal Provisions >> > (TLP – https://trustee.ietf.org/license-info/). >> > >> > * Semantic markup >> > >> > Please review the markup in the XML file to ensure that elements of >> > content are correctly tagged. For example, ensure that <sourcecode> >> > and <artwork> are set correctly. See details at >> > <https://authors.ietf.org/rfcxml-vocabulary>. >> > >> > * Formatted output >> > >> > Please review the PDF, HTML, and TXT files to ensure that the >> > formatted output, as generated from the markup in the XML file, is >> > reasonable. Please note that the TXT will have formatting >> > limitations compared to the PDF and HTML. >> > >> > >> > Submitting changes >> > ------------------ >> > >> > To submit changes, please reply to this email using ‘REPLY ALL’ as all >> > the parties CCed on this message need to see your changes. The parties >> > include: >> > >> > * your coauthors >> > >> > * rfc-edi...@rfc-editor.org (the RPC team) >> > >> > * other document participants, depending on the stream (e.g., >> > IETF Stream participants are your working group chairs, the >> > responsible ADs, and the document shepherd). >> > >> > * auth48archive@rfc-editor.org, which is a new archival mailing >> list >> > to preserve AUTH48 conversations; it is not an active discussion >> > list: >> > >> > * More info: >> > >> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >> > >> > * The archive itself: >> > https://mailarchive.ietf.org/arch/browse/auth48archive/ >> > >> > * Note: If only absolutely necessary, you may temporarily opt out >> > of the archiving of messages (e.g., to discuss a sensitive >> matter). >> > If needed, please add a note at the top of the message that you >> > have dropped the address. When the discussion is concluded, >> > auth48archive@rfc-editor.org will be re-added to the CC list >> and >> > its addition will be noted at the top of the message. >> > >> > You may submit your changes in one of two ways: >> > >> > An update to the provided XML file >> > — OR — >> > An explicit list of changes in this format >> > >> > Section # (or indicate Global) >> > >> > OLD: >> > old text >> > >> > NEW: >> > new text >> > >> > You do not need to reply with both an updated XML file and an explicit >> > list of changes, as either form is sufficient. >> > >> > We will ask a stream manager to review and approve any changes that seem >> > beyond editorial in nature, e.g., addition of new text, deletion of >> text, >> > and technical changes. Information about stream managers can be found >> in >> > the FAQ. Editorial changes do not require approval from a stream >> manager. >> > >> > >> > Approving for publication >> > -------------------------- >> > >> > To approve your RFC for publication, please reply to this email stating >> > that you approve this RFC for publication. Please use ‘REPLY ALL’, >> > as all the parties CCed on this message need to see your approval. >> > >> > >> > Files >> > ----- >> > >> > The files are available here: >> > https://www.rfc-editor.org/authors/rfc9628.xml >> > https://www.rfc-editor.org/authors/rfc9628.html >> > https://www.rfc-editor.org/authors/rfc9628.pdf >> > https://www.rfc-editor.org/authors/rfc9628.txt >> > >> > Diff file of the text: >> > https://www.rfc-editor.org/authors/rfc9628-diff.html >> > https://www.rfc-editor.org/authors/rfc9628-rfcdiff.html (side by >> side) >> > >> > Diff of the XML: >> > https://www.rfc-editor.org/authors/rfc9628-xmldiff1.html >> > >> > The following files are provided to facilitate creation of your own >> > diff files of the XML. >> > >> > Initial XMLv3 created using XMLv2 as input: >> > https://www.rfc-editor.org/authors/rfc9628.original.v2v3.xml >> > >> > XMLv3 file that is a best effort to capture v3-related format updates >> > only: >> > https://www.rfc-editor.org/authors/rfc9628.form.xml >> > >> > >> > Tracking progress >> > ----------------- >> > >> > The details of the AUTH48 status of your document are here: >> > https://www.rfc-editor.org/auth48/rfc9628 >> > >> > Please let us know if you have any questions. >> > >> > Thank you for your cooperation, >> > >> > RFC Editor >> > >> > -------------------------------------- >> > RFC9628 (draft-ietf-payload-vp9-16) >> > >> > Title : RTP Payload Format for VP9 Video >> > Author(s) : J. Uberti, S. Holmer, M. Flodman, D. Hong, J. Lennox >> > WG Chair(s) : Dr. Bernard D. Aboba, Jonathan Lennox >> > Area Director(s) : Zaheduzzaman Sarker, Francesca Palombini >> > >> > >> >> >> >> >> >> >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
