[video-codec] Proposed charter

"Timothy B. Terriberry" <tterribe@xiph.org> Mon, 20 August 2012 22:15 UTC

Return-Path: <tterribe@xiph.org>
X-Original-To: video-codec@ietfa.amsl.com
Delivered-To: video-codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFD321F854E for <video-codec@ietfa.amsl.com>; Mon, 20 Aug 2012 15:15:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.091
X-Spam-Level:
X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, GB_AFFORDABLE=1, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpUoX+uixkUr for <video-codec@ietfa.amsl.com>; Mon, 20 Aug 2012 15:15:24 -0700 (PDT)
Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id DF78121F854D for <video-codec@ietf.org>; Mon, 20 Aug 2012 15:15:20 -0700 (PDT)
Received: from [10.250.6.54] (corp-240.mv.mozilla.com [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id D5D13F2631 for <video-codec@ietf.org>; Mon, 20 Aug 2012 15:15:17 -0700 (PDT)
Message-ID: <5032B6F5.7030402@xiph.org>
Date: Mon, 20 Aug 2012 15:15:17 -0700
From: "Timothy B. Terriberry" <tterribe@xiph.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120626 SeaMonkey/2.10.1
MIME-Version: 1.0
To: video-codec@ietf.org
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [video-codec] Proposed charter
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Video codec BoF discussion list <video-codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/video-codec>, <mailto:video-codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/video-codec>
List-Post: <mailto:video-codec@ietf.org>
List-Help: <mailto:video-codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/video-codec>, <mailto:video-codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Aug 2012 22:15:24 -0000

As promised, here is a first draft of a proposed charter for the 
eventual working group, should we be successful in forming one. Comments 
and feedback would be most appreciated.



Problem Statement

According to reports from developers of Internet video applications and
operators of Internet video services, there are no standardized,
high-quality video codecs that meet all of the following three
conditions:

1. Are optimized for use in interactive Internet applications.

2. Are published by a recognized standards development organization
(SDO) and therefore subject to 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
Internet; according to reports, this mismatch between design and
deployment has hindered interoperability of such codecs in interactive
Internet applications.

There exist codecs that can be widely implemented, but that are not
standardized under the IPR rules 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
adoptions of such codecs in Internet applications.

According to application developers and service operators, a video
codec that meets both 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 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).

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

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.

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

In addition to the technical objectives, there is one process goal,
which is

5. Ensuring the work is done under the IPR rules of the IETF.

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 or select 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 more than one codec, or a
codec with multiple modes; however, it is not the goal of working group
to produce more than one codec, and to reduce confusion in the
marketplace the working group shall endeavor to produce as few codecs as
possible.

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
Real-time Transport Protocol (RTP).

- Collaborate with working groups in the Transport Area to identify
important aspects of packet transmission over the Internet.

- Collaborate with working groups in the Transport Area 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 use cases.

The working group will coordinate with the ITU-T (Study group 16), with
the intent of submitting the completed codec RFC for co-publication by
the ITU-T if the ITU-T finds that appropriate. The working group will
communicate a detailed description of the requirements and goals to
other SDOs including the ITU-T and MPEG to help determine if existing
codecs meet the requirements and goals. Information about codecs being
standardized will be available to other SDOs in the form of internet
drafts and the working group welcomes technical feedback from other SDOs
and experts from other organizations.

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


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 along
with source code for a reference implementation. 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.

4. Specification of a storage format for non-interactive (HTTP)
streaming or file transfer of the codec. It is envisioned that this
document shall be a Proposed Standard document.

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  Submit codec specification to IESG (Standards Track)
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