> 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 > <mailto: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? >> >> 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. > >> >> 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 <mailto: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 >> > <mailto: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 <mailto: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 <mailto: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 <mailto: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
