Subject: [video-codec] New Charter Draft

From: "Timothy B. Terriberry" <[email-masked]>
Date: Thu, 24 Jan 2013 12:34:50 -0800

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
--- video-codec-charter-20130108.txt	2013-01-08 22:53:25.258764448 -0800
+++ video-codec-charter-20130124.txt	2013-01-24 12:28:41.953314686 -0800
@@ -1,96 +1,85 @@
-Problem Statement
+Objectives
 
-According to reports from developers of Internet video applications and
-operators of Internet video services, there is no standardized,
-high-quality video codec that meets all of the following three
-conditions:
+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) and therefore subject to clear change control and IPR disclosure
-rules.
+(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.
 
-There exist codecs that provide high quality encoding of video
-information, but that are not optimized for the actual conditions of
-the public, consumer-level, best-effort Internet. Such optimizations
-might include fast and flexible congestion control, such as the ability
-to change resolution without sending a keyframe; a simple means of
-handling packet loss in the face of reference frame re-ordering; 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. According to reports, this mismatch
-between design and deployment has hindered performance and
-interoperability of such codecs in Internet applications.
-
-There exist codecs that can be widely implemented, but were not
-developed under the IPR rules of any SDO; according to reports, the
-lack of clarity in their IPR status has hindered adoption of such
-codecs in Internet applications.
-
-There exist codecs that are standardized, but that cannot be widely
-implemented and easily distributed; according to reports, the presence
-of various usage restrictions (e.g., in the form of requirements to pay
-royalty fees, obtain a license, enter into a business agreement, or
-meet other special conditions imposed by a patent holder) has hindered
-adoption of such codecs in Internet applications.
-
-According to application developers and service operators, a video
-codec that meets all three of these conditions would: (1) enable
-protocol designers to more easily specify a mandatory-to-implement
-codec in their protocols and thus improve interoperability; (2) enable
-developers to more easily build innovative applications for the
-Internet; (3) enable service operators to more easily deploy
-affordable, high-quality video services on the Internet; and (4) enable
-end users of Internet applications and services to enjoy an improved
-user experience.
-
-Objectives
-
-The goal of this working group is to ensure the existence of a single
-high-quality video codec that can be widely implemented and easily
-distributed among application developers, service operators, and end
-users. At present it appears that 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. Designing for 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).
+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.
 
-2. Addressing the real transport conditions of the Internet, such as
+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.
 
-3. Ensuring interoperability and clean integration with the Real-time
-Transport Protocol (RTP), including secure transport via SRTP.
+5. Not require large amounts of out of bound data before a stream can
+be decoded.
 
-4. Ensuring interoperability with Internet signaling technologies such
-as Session Initiation Protocol (SIP), Session Description Protocol
-(SDP), and Extensible Messaging and Presence Protocol (XMPP). However,
-the result should not depend on the details of any particular signaling
-technology.
-
-5. Ensuring suitability for 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.
+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.
 
-Optimizing for very low bit rates (typically below 64 kbps) is out of
-scope because such work might necessitate specialized optimizations.
+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"]
+|]
 
-In addition to the technical objectives, there is one process goal,
-which is
+Non-Goals
 
-6. Ensuring the work is done under the IPR rules of the IETF.
+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
@@ -104,11 +93,13 @@
 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 AVT WG, define the codec's payload format for use with the
+- 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
@@ -130,54 +121,7 @@
 
 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 they find that
-appropriate. To facilitate the potential for co-publication, and
-recognizing other SDOs like ISO/IEC (JTC1/SC29 WG11) are assessing
-video codec technologies for potential royalty-free standardization,
-the working group will seek on an ongoing basis where feasible to
-communicate through existing liaison channels and meetings, evaluate
-and share in-process proposals, test results, code bases, and IPR
-information, and facilitate parallel consideration of the working
-group's work-in-progress for royalty-free standardization under
-processes like the Common Patent Policy for ITU-T/ITU-R/ISO/IEC.
-
-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.
-
-A codec that can be widely implemented and easily distributed among
-application developers, service operators, and end users is preferred.
-Many existing codecs that might fulfill some or most of the technical
-attributes listed above are encumbered in various ways. For example,
-patent holders might require that those wishing to implement the codec
-in software, deploy the codec in a service, or distribute the codec in
-software or hardware need to request a license, enter into a business
-agreement, pay licensing fees or royalties, or attempt to adhere to
-other special conditions or restrictions.
-
-Because such encumbrances have made it difficult to widely implement
-and easily distribute high-quality video codecs across the entire
-Internet community, the working group prefers unencumbered technologies
-in a way that is consistent with BCP 78 and BCP 79. In particular, 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 shall
-follow BCP 79, and adhere to the spirit of BCP 79. The working group
-cannot explicitly rule out the possibility of adopting encumbered
-technologies; however, the working group will try to avoid encumbered
-technologies that require royalties or other encumbrances that would
-prevent such technologies from being easy to redistribute and use. 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."
+codec RFC for co-publication by the ITU-T and ISO if the co-publishing organizations find that appropriate.
 
 Deliverables
 
@@ -190,8 +134,8 @@
 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. It is
-envisioned that this document shall be a Proposed Standard document.
+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
@@ -199,8 +143,8 @@
 
 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. It is envisioned that this
-document shall be a Proposed Standard document.
+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

---

From: Jean-Marc Valin <[email-masked]>
Date: Mon, 28 Jan 2013 18:21:22 -0500

Hi Tim,

The new version looks good to me. Just had a few minor comments (inline)

> 6569) will form the starting point for guidelines and requirements for

I think "and requirements" should be removed since we have a separate
requirements draft.

> processes of the working group. This document shall be Informational.

Actually, I don't think this guidelines draft is needed at all. AFAIK
this is now something WGs generally need and I don't think it was ever
useful in the codec WG.

Cheers,

	Jean-Marc

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 30 Jan 2013 09:54:59 +0100

On 01/24/2013 09:34 PM, Timothy B. Terriberry wrote:
> 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 like this one.

On the IPR issues, I think you should send a mail to the IETF senior 
counsel (still Jorge Contreras, I believe) for advice; he might help you 
change this language from "totally informal" to something that actually 
means something in legalese - or tell you why it is a bad idea to have 
it there.

> _______________________________________________
> video-codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/video-codec