Hi Jonathan, Justin, and *AD,
Thanks for your reply.
We have updated to use Mo’s proposed text as related to question 10 (the text
sent to the WG). We will await *AD review/confirmation that we are okay to go
forward with this text:
Current:
U: Switching up point. When this bit is set to one, 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
decode order) with a temporal-layer ID value greater than T.
We are hoping to hear from Justin as to how to edit the postal address
(affiliation has been updated as requested).
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 21, 2025, at 1:53 PM, Jonathan Lennox <jonathan.len...@8x8.com> wrote:
>
> I also notice that Justin’s affiliation was updated for 9627, but not for
> 9628.
>
>> On Feb 21, 2025, at 3:51 PM, Jonathan Lennox <jonathan.len...@8x8.com> wrote:
>>
>>
>>
>>> 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
