Skip to main content

WebRTC Video Processing and Codec Requirements
draft-ietf-rtcweb-video-06

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    rtcweb mailing list <rtcweb@ietf.org>,
    rtcweb chair <rtcweb-chairs@tools.ietf.org>
Subject: Protocol Action: 'WebRTC Video Processing and Codec Requirements' to Proposed Standard (draft-ietf-rtcweb-video-06.txt)

The IESG has approved the following document:
- 'WebRTC Video Processing and Codec Requirements'
  (draft-ietf-rtcweb-video-06.txt) as Proposed Standard

This document is the product of the Real-Time Communication in
WEB-browsers Working Group.

The IESG contact persons are Ben Campbell, Barry Leiba and Alissa Cooper.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-video/


Ballot Text

Technical Summary

   This specification provides the requirements and considerations for
  WebRTC applications to send and receive video across a network.  It
  specifies the video processing that is required, as well as video
  codecs and their parameters.

Working Group Summary

   From Sean Turner:
   
   I’d characterize discussions about this draft as a lengthy, lively, and spirited and that’s putting it mildly, but I also think if Chuck were representative of this then this meme would sum it up:http://cdn.meme.am/instances/500x/58865172.jpg.  There has easily been in excess of 1,000 email messages about this draft and this draft has been discussed at many f2f meetings ​(IETF 81, 82, 85, 86, and 88) before the WG consciously decided to take an entire year off from discussing it before re-engaging around the IETF 91 timeframe.

From the start, VP8 and H.264 were the front runners though H.261, H.263, Theora, and Motion JPEG were also considered.  From the 10,000 foot level, the draw to H.264 was its widespread support and the draw to VP8 was its BSD-like license and irrevocable free patent license on its bitstream format.  Of course, VP8 was shown to be widely supported and the IPR “freeness” of VP8 was questioned (discussed in response to question #3 below). And, H.264’s widespread support was attacked based on the number of profiles and H.264’s licensing cost was described as “low”.

Of course, the topic that dominated the discussion was IPR.  But, from the start everybody that this was going to be the case so there’s text to address it in the charter, i.e., there’s the possibly that an IPR-encumbered solution might be selected.  See Section 3 for more on IPR issues.

Lest you think that the entire debate was about IPR, early on technical topics included video quality and performance as well as status of VP8 standardization, which BTW is moving its way through ISO.  None of these topics however were interesting enough to maintain the WG's attention while the IPR debated raged.

As far as the consensus process goes, there were actually three attempts at reaching consensus.  The first attempt did not result in WG consensus.  After the 1st attempt failed, the WG explored an alternative decision making process (the 2nd attempt), which also was fodder for the IETF discussion list, based on this msghttp://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html.  This too didn’t result in WG consensus but a couple of important topics did fall out: 1) it helped enumerate more options (i.e., it wasn’t just H.264 vs VP8) and 2) confirmed that the WG did in fact want to decide on an MTI codec.

Leading up to IETF 91, the chairs proposed a series of physical and vocal calisthenics, which can be found here:http://www.ietf.org/mail-archive/web/rtcweb/current/msg13358.html, that we thought would help the WG reach consensus (i.e., third time being the charm and all).  But, Adam took the wind out of our sails with his so called “novel proposal", which can be found here: http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432.html. Based on list support for the proposal we modified our questions to refer to Adam’s text prior to the meeting.  So at the 2nd RTCWeb session @ IETF 91 we had presentations from the draft author on the compromise text and from the VP8 and H.264 “camps” in support of the compromise.  Then, we had an open mic session followed by some hums.  The rough consensus in the room was to adopt the comprise text but there were some objections raised and I pointed these out in the message sent to the mailing list confirming the room’s consensus:http://www.ietf.org/mail-archive/web/rtcweb/current/msg13696.html.  After the allotted time elapsed (and a few hundred more emails), I determined that the consensus in the room was confirmed.

I’ll note that during the second WG consensus attempt, I purposely requested that the other two chairs step down from the podium and I, along with some help from my ADs, made the consensus call and it was later confirmed on the list.

Document Quality

   There are many implementations that will or do make use of this specification.

Personnel

   Sean Turner is the document shepherd. Alissa Cooper is the responsible Area Director.

RFC Editor note

This document requires three editorial edits.

1. The 1st paragraph in section 5 should be amended as follows:

OLD:

For the definitions of "WebRTC Browser," "WebRTC Non-Browser", and
"WebRTC-Compatible Endpoint" as they are used in this section, please
refer to [I-D.ietf-rtcweb-overview].

NEW:

For the definitions of "WebRTC Browser," "WebRTC Non-Browser", and
"WebRTC-Compatible Endpoint" as they are used in this section, please
refer to Section 2.

2. The following text should be added to section 2 (Terminology):

The following definitions are used in this document:

o  A WebRTC browser (also called a WebRTC User Agent or WebRTC UA) is
    something that conforms to both the protocol specification and the
    Javascript API (see [I-D.ietf-rtcweb-overview]).

o  A WebRTC non-browser is something that conforms to the protocol
    specification, but does not claim to implement the Javascript API.
    This can also be called a "WebRTC device" or "WebRTC native
    application”.

o  A WebRTC endpoint is either a WebRTC browser or a WebRTC non-
    browser.  It conforms to the protocol specification.

o  A WebRTC-compatible endpoint is an endpoint that is able to
    successfully communicate with a WebRTC endpoint, but may fail to
    meet some requirements of a WebRTC endpoint.  This may limit where
    in the network such an endpoint can be attached, or may limit the
    security guarantees that it offers to others.  It is not
    constrained by this specification; when it is mentioned at all, it
    is to note the implications on WebRTC-compatible endpoints of the
    requirements placed on WebRTC endpoints.

These definitions are also found in [I-D.ietf-rtcweb-overview]
and that document should be consulted for additional information.

3. Move [I-D.ietf-rtcweb-overview] from the Normative Reference section to the Informative Reference section.


RFC Editor Note