Okay, there seems to be support here for a new deliverable (most
importantly, from the people who will likely be doing the work to
satisfy the deliverable). The attached charter incorporates this new
deliverable, as well as the clarification based on Mo's earlier comment.
/a
On 4/3/15 17:01, Suhas Nandakumar wrote:
On Fri, Apr 3, 2015 at 11:17 AM, Timothy B. Terriberry
<[email protected] <mailto:[email protected]>> wrote:
Mo Zanaty (mzanaty) wrote:
Adam Roach <[email protected] <mailto:[email protected]>> wrote:
I propose clarifying by changing the first milestone to be
"Requirements and evaluation criteria to IESG..."
Works for me.
Also fine to keep the final milestone for the testing doc for
now. We can revisit once there, which also gives time to see
how opus handles this (currently no supply or demand interest).
Both sound fine to me.
Any objection to adding the deliverable for a reference
implementation? Here's some proposed text:
"3. Source code for a reference implementation that includes both
an encoder and a decoder."
+1 for adding source code ref-impl.
_______________________________________________
video-codec mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/video-codec
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, including mobile devices, and efficient
implementation in new hardware designs.
3. Use in interactive real-time 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 will consider the impacts its decisions have on the
efficiency of transcoding to and from other existing video codecs.
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
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); ISO/IEC
(JTC1/SC29 WG11); 3GPP (SA4); and JCT-VC.
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 set of technical requirements and evaluation criteria. The WG may choose
to pursue publication of these in an RFC if it deems that to be beneficial.
2. Proposed Standard specification of an encoded bit stream and decoder
operation where the normative formats and algorithms are described in English
text and not as code.
3. Source code for a reference implementation that includes both an encoder
and a decoder.
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 Requirements and evaluation criteria to IESG, if the WG so chooses
(Informational)
TBD Submit codec specification to IESG (Standards Track)
TBD Submit reference implementation to IESG (Informational)
TBD Submit storage format specification to IESG (Standards Track)
TBD Testing document to IESG (Informational)
Title: wdiff netvc-charter-01.txt netvc-charter-02.txt
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, including mobile devices, and efficient
implementation in new hardware designs.
3. Use in interactive real-time 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 will consider the impacts its decisions have on the
efficiency of transcoding to and from other existing video codecs.
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
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); ISO/IEC
(JTC1/SC29 WG11); 3GPP (SA4); and JCT-VC.
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 set of technical requirements and evaluation criteria. The WG may choose
to pursue publication of these in an RFC if it deems that to be beneficial.
2. Proposed Standard specification of an encoded bit stream and decoder
operation where the normative formats and algorithms are described in English
text and not as code.
3. Source code for a reference implementation that includes both an encoder
and a decoder.
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.
4.
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 Requirements and evaluation criteria to IESG, if the WG so chooses
(Informational)
TBD Submit codec specification to IESG (Standards Track)
TBD Submit reference implementation to IESG (Informational)
TBD Submit storage format specification to IESG (Standards Track)
TBD Testing document to IESG (Informational)
_______________________________________________
video-codec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/video-codec
