-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move to Candidate Recommendation #45
Comments
|
The AV1 bitstream and AV1-RTP payload specification have been approved by AoMedia and are no longer work-in-progress. |
https://aomediacodec.github.io/av1-rtp-spec/ says "This document is a draft of a proposed specification." - if it's no longer a draft, it should be probably updated accordingly |
I have sent email to the AV1 RTC SG chairs (Stephen Botzko and Michael Horowitz). |
@dontcallmedom BTW, I went over the references, and it's not clear to me why respec is deciding that so many of the references are normative. For example, there is no RTCWEB requirement that WebRTC implementations support VP9 or AV1 and the specification itself does not use normative language in relation to those codecs. |
Using a reference from a normative part of the spec makes ReSpec assumes it is a normative reference. To make it an informative reference, the reference should be written à la |
I've moved all the codec references to informative. RFC 7742 does not require browsers to support VP9, AV1 or H.264/SVC. VP8 support is required, but not support for temporal scalability. |
Now that we have resolved the discovery issue (the last CR-blocking bug), and the API has shipped in Chromium, I think we are ready to move to CR. Status of dependencies: AV1 is in final state (modulo errata); |
With our last wide review having been done 3 years ago, I think we'll need to confirm with horizontal groups that substantive changes brought to the spec since then don't raise new concerns (or that new concerns have emerged in the interval). |
@aboba this still seems to be marked as "draft" (when we refer to it as "standard" in the spec) |
I see AOMediaCodec/av1-rtp-spec#236 is trying to fix this |
I have clarified that discovery is out of the scope of the WebRTC-SVC specification, as well as making all references to Media Capabilities (and all sections in which it is referenced) non-normative. As a result, Media Capabilities is now a non-normative reference. When we discussed Issue #92 in the WEBRTC WG, the resolution was to bring it to the MEDIA WG for guidance. PING had filed Issue 176 against Media Capabilities API in March 2021. Today (December 12), the MEDIA WG considered Issues 176 and 209. I'll post a link to the minutes when they are posted. However, my understanding is that the resolution was to decline to require camera permission for Media Capabilities, as PIING requested. Given that WebRTC-SVC does not leak any more information than is already available via Media Capabilities, and also given that Media Capabilities is a non-normative reference, I have reclassified #92 as no longer being CR blocking. |
Tracking bug for the process of moving this spec to CR.
The text was updated successfully, but these errors were encountered: