From tterribe@xiph.org Tue Jan 1 22:36:54 2013 Return-Path: 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 C902E21F8FBB for ; Tue, 1 Jan 2013 22:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_AFFORDABLE=1, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] 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 TMHUaxwMkLbW for ; Tue, 1 Jan 2013 22:36:53 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 278A121F8FAE for ; Tue, 1 Jan 2013 22:36:53 -0800 (PST) Received: from [192.168.11.8] (pool-71-114-8-24.washdc.dsl-w.verizon.net [71.114.8.24]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 972E9F20F2; Tue, 1 Jan 2013 22:36:50 -0800 (PST) Message-ID: <50E3D581.8070405@xiph.org> Date: Tue, 01 Jan 2013 22:36:49 -0800 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120625 SeaMonkey/2.10.1 MIME-Version: 1.0 To: video-codec@ietf.org Content-Type: multipart/mixed; boundary="------------000502080802080707030707" Cc: Rob Glidden Subject: [video-codec] Charter update X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 06:36:54 -0000 This is a multi-part message in MIME format. --------------000502080802080707030707 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Slightly later than I'd hoped, here is an updated version of the proposed charter, based on feedback from the list and during the BoF. The major changes are - Clarify that HTTP streaming should support both progressive and chunked downloads. - Added some examples of what "optimized for the Internet" means. - Clarified that the we only intend to produce one codec. - Added a goal to be suitable for use with various Internet applications and Web APIs. - Unified language about the ITU and ISO. - Removed the suggestion that we would ask other SDOs if one of their existing codecs satisfies all of our requirements and goals. - Added a statement that we should not produce an RFC if there is consensus that the codec cannot "be widely implemented and easily distributed among application developers, service operators, and end users." - Moved the reference implementation into a separate deliverable - Added a deliverable for a test results document - Minor editorial changes. I think there is still work to do on the language about interacting with other SDOs. However, I have not gotten any response to my Nov. 6th request [1] for specific language that people want to see here. Rob, any suggestions would be welcome. [1] http://www.ietf.org/mail-archive/web/video-codec/current/msg00064.html The full text of the proposed charter follows. A full diff from the previous version is attached. Problem Statement According to reports from developers of Internet video applications and operators of Internet video services, there is no standardized, high-quality video codec that meets all of the following three conditions: 1. Is optimized for use in interactive Internet applications. 2. Is 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 public, consumer-level, best-effort Internet. Such optimizations might include fast and flexible congestion control, such as the ability to change resolution without sending a keyframe; a simple means of handling packet loss in the face of reference frame re-ordering; 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. According to reports, this mismatch between design and deployment has hindered performance and interoperability of such codecs in Internet applications. There exist codecs that can be widely implemented, but were not developed under the IPR rules of 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 adoption of such codecs in Internet applications. According to application developers and service operators, a video codec that meets all three 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 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. 5. Ensuring suitability for use in Internet applications and Web APIs, such as the HTML5