Subject: [video-codec] Revised Charter video-codec - comments, feedback?!

From: David Benham <[email-masked]>
Date: Tue, 3 Feb 2015 14:14:34 -0800

Latest revision proposed below.

For those familiar with the prior version, this revision is shorter as it
attempted to only include items consistent with typical, concise WG
Charter.   Thus you will find of the more technically specific requirements
are deferred to (informational) requirements doc as shown on the milestone
list.  Remaining requirements focus on preforming well even in the chaotic,
real-world Internet, being competitive with the state-of-art of popular
codec(s) when the spec is completed and explicitly stating that verifiable
IPR status (eg, may include research from another entity outside IETF).

Additional polishing is desired ... comments/feedback please!

The following is also online at
https://daala.etherpad.mozilla.org/video-codec-charter
-------------------------------------------------------------------------------------------------------------------------

video-codec-charter

Objectives

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

1. Is competitive with current video codecs in widespread use.

2. Is optimized for use in interactive web applications.

3. Is viewed as having IPR licensing terms that allow it to be widely
implemented and deployed.

To elaborate, this video codec will need to be commercially interesting to
implement by being competitive with the video codecs in widespread use at
the time it is finalized.

This video codec will need to be optimized for the real-world conditions of
the public, best-effort Internet. It should include, but may not be limited
to, the ability to support fast and flexible congestion control and rate
adaptation, the ability to quickly join broadcast streams and the ability
to be optimized for captures of content typically shared in interactive
communications.

The objective is to produce a video codec that can be implemented,
distributed, and deployed by open source and closed source software as well
as implemented in specialized hardware.

The WG will prefer algorithms or tools where there are verifiable reasons
to believe they are RF over algorithms or tools where there is RF
uncertainty or known active IPR claims with royalty liability potential.
The codec specification will document why it believes that each part is
likely to be RF, which will help adoption of the codec. This can include
references to old prior art and/or patent research information.

Process

The core technical considerations for such a codec include, but are not
necessarily limited to, the following:

1. High compression efficiency that is competitive with existing popular
video codecs.

2. Reasonable computational complexity that permits real-time operation on
existing, popular hardware, and efficient implementation in new hardware
designs.

3. Use in interactive applications, such as point-to-point video calls,
multi-party video conferencing, telepresence, teleoperation, and in-game
video chat.

4. Resilient in the real-world transport conditions of the Internet, such as
the flexibility to rapidly respond to changing bandwidth availability
and loss rates, etc.

5. Integratable with common Internet applications and Web APIs (e.g., the
HTML5 <video> tag and WebRTC API, live streaming, adaptive streaming, and
common media-related APIs without depending on any particular API.).

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."  This preference cannot guarantee
that the working group will produce an IPR unencumbered codec.

Non-Goals

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

It is explicitly not a goal of the working group to produce a codec that
will be mandated for implementation across the entire IETF or Internet
community.

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. The WG may produce a codec that is highly configurable,
operating in many different modes with the ability to smoothly be extended
with new modes in the future.

Collaboration

In completing its work, the working group will liaise with other relevant
IETF working groups and SDOs, including PAYLOAD, RMCAT, RTCWEB, MMUSIC, and
other IETF WGs that make use of or handle negotiation of codecs; W3C
working groups including HTML, Device APIs and WebRTC; and ITU-T (Study
group 16) and ISO/IEC (JTC1/SC29 WG11).

It is expected that an open source reference version of the codec will be
developed in parallel with the working group.

The WG will accept and consider in its decision process input received from
external parties concerning IPR risk associated with proposed algorithms.

Deliverables

1. A document that outlines the IPR terms the working group wishes
contributors to the specifications would use to license their IPR.

2. A set of technical requirements and evaluation metrics. The WG may
choose to pursue publication of these in an RFC if it deems that to be
beneficial.

3. Proposed Standard specification of an encoder and decoder where the
normative algorithms are described in English text and not as code.

4. Specification of a storage format for file transfer of the encoded video
as an elementary stream compatible with existing, popular container formats
to support non-interactive (HTTP) streaming, including live encoding and
both progressive and large-chunk downloads. The WG will not develop a new
container format.

5. 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  IPR licensing terms goals (Informational)

TBD  Requirements to IESG, if the WG so chooses (Informational)

TBD  Submit codec specification to IESG (Standards Track)

TBD  Submit storage format specification to IESG (Standards Track)

TBD  Testing document to IESG (Informational)

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 03 Feb 2015 20:37:35 -0800

David Benham wrote:
> For those familiar with the prior version, this revision is shorter as
> it attempted to only include items consistent with typical, concise WG
> Charter.   Thus you will find of the more technically specific

I think this reads much better now.

> In completing its work, the working group will liaise with other
> relevant IETF working groups and SDOs, including PAYLOAD, RMCAT, RTCWEB,
> MMUSIC, and other IETF WGs that make use of or handle negotiation of
> codecs; W3C working groups including HTML, Device APIs and WebRTC; and
> ITU-T (Study group 16) and ISO/IEC (JTC1/SC29 WG11).

I know that in the pre-BoF meeting in Toronto several people made 
comments that attempting to coordinate with ITU/ISO for possible joint 
publication was probably not worth the effort given the timescales 
required to set up joint work like JVT and JCTVC in the past and the 
lack of interest in similar attempts during CODEC. Given that, do people 
feel there's much value in liaising with these bodies at all, or should 
we drop those groups from this list entirely?