> On 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).
Good. > > 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”. Thanks for catching that, yes, that was an autocorrect error. It should indeed be “modulo”. > 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). Mo had a response to the WG mail about that language — I agree with him, the parenthetical phrase would be better as “(in decoding order)” to match other usages. I also have two more changes for this document: In the definition of Picture ID, in section 4.2, in the phrase "if the field transitions from 15 bits to 7 bits, it is truncated (i.e., the value after 0x1bbe is 0xbf)” the value “0xbf” should be replaced by “0x3f”. (0xbf is not a 7-bit value.) The title of section 4.5 should be “Example of a VP9 RTP Stream”, because there is only one example. Thank you! -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org