Skip to content
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

Open
alvestrand opened this issue Jul 8, 2021 · 14 comments
Open

Move to Candidate Recommendation #45

alvestrand opened this issue Jul 8, 2021 · 14 comments

Comments

@alvestrand
Copy link
Contributor

Tracking bug for the process of moving this spec to CR.

@dontcallmedom
Copy link
Member

dontcallmedom commented Jul 9, 2021

  • Wide Review conducted
  • 6 issues (incl one open during horizontal review) to assess whether they're CR blocking
  • Implementation statuses: Chromium in Origin Trial, Mozilla position
  • Dependencies (they don't need to be settled to go to CR, just reviewed):
    • AV1 is qualified a WIP in the spec, but it looks like it is in final state (modulo errata);
    • AV1-RTP: unclear what timeline to completion looks like
    • VP9: unclear status and timeline to completion; but also unclear that it actually is a normative dependency
    • VP9-PAYLOAD: in RFC editor queue
  • Test suite: WPT - a single test file at the moment

@aboba
Copy link
Contributor

aboba commented Jul 9, 2021

The AV1 bitstream and AV1-RTP payload specification have been approved by AoMedia and are no longer work-in-progress.

@dontcallmedom
Copy link
Member

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

@aboba
Copy link
Contributor

aboba commented Jul 9, 2021

I have sent email to the AV1 RTC SG chairs (Stephen Botzko and Michael Horowitz).

@aboba
Copy link
Contributor

aboba commented Jul 10, 2021

@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.

@dontcallmedom
Copy link
Member

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 [[?VP9]] (i.e. preceded with a question mark).

@aboba
Copy link
Contributor

aboba commented Jul 12, 2021

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.

@aboba
Copy link
Contributor

aboba commented Mar 29, 2023

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);
AV1-RTP: in final state.
VP9: not a normative dependency.
VP9-PAYLOAD: in RFC editor queue, [MISS-REF] now unblocked.

@dontcallmedom
Copy link
Member

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).

@dontcallmedom
Copy link
Member

dontcallmedom commented Apr 25, 2023

Updated wide review requests:

I've asked for feedback by May 16

@dontcallmedom
Copy link
Member

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

@aboba this still seems to be marked as "draft" (when we refer to it as "standard" in the spec)

@dontcallmedom
Copy link
Member

I see AOMediaCodec/av1-rtp-spec#236 is trying to fix this

@dontcallmedom
Copy link
Member

@aboba can you suggest a way forward for #92 ? this is the last thing preventing us to request transition to CR AFAICT

@aboba
Copy link
Contributor

aboba commented Dec 11, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants