Internet Video Codec (netvc)
|WG||Name||Internet Video Codec|
|Area||Applications and Real-Time Area (art)|
|Dependencies||Document dependency graph (SVG)|
|Jabber chat||Room address||xmpp:firstname.lastname@example.org?join|
Charter for Working Group
This WG is chartered to produce a high-quality video codec that meets the following conditions:
1. Is competitive (in the sense of having comparable or better performance) 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 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." In keeping with this BCP, the WG will prefer algorithms or tools where there are verifiable reasons to believe they are available on an royalty-free (RF) basis. In developing the codec specification, the WG may consider information concerning old prior art or the results of research indicating royalty-free availability of particular techniques. Note that the preference stated in BCP 79 cannot guarantee that the working group will produce an IPR unencumbered codec.
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.
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.
In completing its work, the working group will seek cross-WG review with other relevant IETF working groups, including PAYLOAD, RMCAT, RTCWEB, MMUSIC, and other IETF WGs that make use of or handle negotiation of codecs. The WG will liaise with groups in other SDOs, such as the W3C HTML, Device APIs and WebRTC working groups; 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's work.
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 (documented in an informational document) 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.
|Dec 2017||Test result document to IESG, if the WG so chooses (Informational)|
|May 2017||Submit storage format specification to IESG (Standards Track)|
|May 2017||Submit reference implementation to IESG (Informational)|
|May 2017||Submit codec specification to IESG (Standards Track)|
|Jul 2016||Requirements and evaluation criteria to IESG, if the WG so chooses (Informational)|