[video-codec] New Charter Draft

["Timothy B. Terriberry" <[e-mail]>]

Thanks to Cullen, Harald, EKR, Robert, and Jean-Marc for participating 
in the con-call on Friday (and sorry if I forgot anyone else). Apologies 
for not getting this out sooner. It took a little longer than I was 
expecting to convert the text we hacked up back into coherent English.

This doesn't address all of Cullen's issues (specifically, there's just 
a placeholder for the licensing terms), but should serve as a starting 
point to clean up any remaining concerns.

I suspect a changelog would be too long to be useful, and the draft is 
32% smaller now, so re-reading it is probably easier. I'm not sure a 
diff is useful either, but it was easy to produce, so I've included it.

Full text of the new charter follows:



Objectives

This WG is chartered to produce a single, standardized, high-quality
video codec that meets the following three conditions:

1. Is optimized for use in interactive Internet applications.

2. Is published by a recognized standards development organization
(SDO) with clear change control and IPR disclosure rules.

3. Can be widely implemented and easily distributed among application
developers, service operators, and end users.

This codec will be optimized for the actual conditions of the public,
consumer-level, best-effort Internet. It might have properties like
fast and flexible congestion control, the ability to change bitrate
smoothly over a range of at least two orders of magnitude without
unnecessary quality degradation, the ability to join broadcast streams
without waiting for a keyframe, special coding tools for screen
captures to support remote services and desktop sharing, and many more.

The objective is to produce a codec that can be implemented,
distributed, and deloyed by open source and closed source software and
hardware vendors, without the need to request a license, enter into a
business agreement, pay licensing fees or royalties, or attempt to
adhere to other onerous conditions or restrictions.

Process

Ensuring the existence of such a codec will require a development
effort within the working group. The core technical considerations for
such a codec include, but are not necessarily limited to, the
following:

1. Use in interactive applications. Examples include, but are not
limited to, point-to-point video calls, multi-party video conferencing,
telepresence, teleoperation, and in-game video chat.

2. Tolerating packet loss.

3. Use in Internet applications and Web APIs, such as the HTML5 <video>
tag, live streaming (e.g., via icecast), adaptive streaming (e.g.,
Dynamic Adaptive Streaming over HTTP (DASH), HTTP Live Streaming (HLS),
etc.), the MediaSource API, the WebRTC APIs, proposed web recording
APIs, and so on. However, the result should not depend on the details
of any particular API.

4. Addressing the real transport conditions of the Internet, such as
the flexibility to rapidly respond to changing bandwidth availability
and loss rates, or as otherwise identified and prioritized by the
working group.

5. Not require large amounts of out of bound data before a stream can
be decoded.

The Guidelines for Development of an Audio Codec within the IETF (RFC
6569) will form the starting point for guidelines and requirements for
achieving the forgoing objectives for video. The working group will
modify them as necessary with lessons learned during that process (for
example, specifying the use of English text as the normative definition
of the codec instead of source code), refining them into a new document
in accordance with the usual IETF procedures once consensus has been
achieved.

The working group shall heed the preference stated in BCP 79: "In
general, IETF working groups prefer technologies with no known IPR
claims or, for technologies with claims against them, an offer of
royalty-free licensing." Although this preference cannot guarantee
that the working group will produce an unencumbered codec, the working
group should not proceed with publication of a codec RFC if there is
consensus that it cannot "be widely implemented and easily distributed
among application developers, service operators, and end users."

[An example of acceptable license terms would be:
["If you don't sue us over this spec, we won't sue you over this IPR"|
  "If you don't sue anyone over this spec, we won't sue you over this IPR"]
|]

Non-Goals

Optimizing for very low bit rates (typically below 256 kbps) is out of
scope because such work might necessitate specialized optimizations.

Although a codec produced by this working group or another standards
organization might be used as a mandatory-to-implement technology by
designers of particular Internet protocols, it is explicitly not a goal
of the working group to produce a codec that will be mandated for use
across the entire IETF or Internet community nor would their be any
expectation that this would be the only mandatory-to-implement codec.

Based on the working group's analysis of the design space, the working
group might determine that it needs to produce a codec with multiple
modes of operation. However, it is not the goal of working group to
produce more than one codec.

Collaboration

In completing its work, the working group should collaborate with other
IETF working groups to complete particular tasks. These might include,
but would not be limited to, the following:

- Within the PAYLOAD WG, define the codec's payload format for use with the
Real-time Transport Protocol (RTP).

- Collaborate with RMCAT and any other appropriate working groups in
the Transport Area to identify important aspects of packet transmission
over the Internet.

- Collaborate with RMCAT to understand the degree of rate adaptation
desirable, and to reflect that understanding in the design of a codec
that can adjust its transmission in a way that minimizes disruption to
the video.

- Collaborate with working groups in the RAI Area to ensure that
information about and negotiation of the codec can be easily
represented at the signaling layer.

- Collaborate with working groups in the RAI Area such as CLUE and
RTCWEB to ensure the codec can satisfy all of their video-related use
cases.

The working group will coordinate with the ITU-T (Study group 16) and
ISO/IEC (JTC1/SC29 WG11), with the intent of submitting the completed
codec RFC for co-publication by the ITU-T and ISO if the co-publishing 
organizations find that appropriate.

Deliverables

1. A set of Codec Standardization Guidelines that define the work
processes of the working group. This document shall be Informational.

2. A set of technical Requirements. This document shall be
Informational.

3. Specification of a codec that meets the agreed-upon requirements, in
the form of an Internet-Draft that defines the codec algorithm. The
text description of the codec shall describe the mandatory,
recommended, and optional portions of the encoder and decoder. This
document shall be a Proposed Standard.

4. A reference implementation of a software encoder and decoder. This
will be in a separate document from the text description to allow it to
be updated independently. It does not need to be standards-track.

5. Specification of a storage format for file transfer of the codec, to
support non-interactive (HTTP) streaming, including live encoding and
both progressive and chunked downloads. This docuemnt shall be a
Proposed Standard.

6. A collection of test results, either from tests conducted by the
working group or made publicly available elsewhere, characterizing the
performance of the codec. This document shall be informational.

Goals and Milestones
TBD  WGLC on codec standardization guidelines
TBD  WGLC on requirements, liaise to other SDOs
TBD  Requirements to IESG (Informational)
TBD  Liaise requirements RFC to other SDOs
TBD  Codec standardization guidelines to IESG (Informational)
TBD  WGLC on codec specification, liaise to other SDOs
TBD  WGLC on reference implementation, liaise to other SDOs
TBD  Submit codec specification to IESG (Standards Track)
TBD  Submit reference implementation to IESG (Informational)
TBD  WGLC on storage format specification
TBD  Submit storage format specification to IESG (Standards Track)
TBD  WGLC on Testing document
TBD  Testing document to IESG