Re: [video-codec] New Charter Draft

[Harald Alvestrand <[e-mail]>]

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

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.


>
> 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 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/video-codec