From tterribe@xiph.org Thu Aug 16 14:42:48 2012 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 4D9B521F84C4 for ; Thu, 16 Aug 2012 14:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] 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 LyM4743Q+LEr for ; Thu, 16 Aug 2012 14:42:47 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id CDC1A21F849D for ; Thu, 16 Aug 2012 14:42:44 -0700 (PDT) Received: from [10.250.6.54] (corp-240.mv.mozilla.com [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 69D5EF2698 for ; Thu, 16 Aug 2012 14:42:44 -0700 (PDT) Message-ID: <502D6954.5000606@xiph.org> Date: Thu, 16 Aug 2012 14:42:44 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120626 SeaMonkey/2.10.1 MIME-Version: 1.0 To: video-codec@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [video-codec] New video-codec list 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: Thu, 16 Aug 2012 21:42:48 -0000 As discussed briefly at the bar BoF in Vancouver, we've set up a list to discuss hosting a real BoF in Atlanta about forming a WG to work on a video codec. I've included everyone who attended the bar BoF in the initial subscription list (apologies to anyone I missed or anyone who wanted to run screaming instead of getting more involved). Please forward to any others you think should be here. After people have had a little bit of time to join, I'll send out a WG charter proposal to get the discussions started. From ietf-secretariat@ietf.org Mon Aug 20 09:54:38 2012 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 DFE0121F867E; Mon, 20 Aug 2012 09:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.937 X-Spam-Level: X-Spam-Status: No, score=-102.937 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 5IlNSLxmdxMa; Mon, 20 Aug 2012 09:54:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8939E21F8541; Mon, 20 Aug 2012 09:54:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120820165438.3185.98607.idtracker@ietfa.amsl.com> Date: Mon, 20 Aug 2012 09:54:38 -0700 Cc: rjsparks@nostrum.com, video-codec@ietf.org, gonzalo.camarillo@ericsson.com, tterribe@xiph.org Subject: [video-codec] New Non-WG Mailing List: video-codec -- Video codec BoF discussion list 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: Mon, 20 Aug 2012 16:54:39 -0000 A new IETF non-working group email list has been created. List address: video-codec@ietf.org Archive: http://www.ietf.org/mail-archive/web/video-codec/current/maillist.= html To subscribe: https://www.ietf.org/mailman/listinfo/video-codec Purpose: This list is for dicussions relating to the potential setup of a n= ew IETF working group devoted to standardizing a video codec. For additional information, please contact the list administrators. From tterribe@xiph.org Mon Aug 20 15:15:24 2012 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 BDFD321F854E for ; Mon, 20 Aug 2012 15:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.091 X-Spam-Level: X-Spam-Status: No, score=-1.091 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, GB_AFFORDABLE=1, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] 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 HpUoX+uixkUr for ; Mon, 20 Aug 2012 15:15:24 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id DF78121F854D for ; Mon, 20 Aug 2012 15:15:20 -0700 (PDT) Received: from [10.250.6.54] (corp-240.mv.mozilla.com [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id D5D13F2631 for ; Mon, 20 Aug 2012 15:15:17 -0700 (PDT) Message-ID: <5032B6F5.7030402@xiph.org> Date: Mon, 20 Aug 2012 15:15:17 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120626 SeaMonkey/2.10.1 MIME-Version: 1.0 To: video-codec@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [video-codec] Proposed charter 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: Mon, 20 Aug 2012 22:15:24 -0000 As promised, here is a first draft of a proposed charter for the eventual working group, should we be successful in forming one. Comments and feedback would be most appreciated. Problem Statement According to reports from developers of Internet video applications and operators of Internet video services, there are no standardized, high-quality video codecs that meet all of the following three conditions: 1. Are optimized for use in interactive Internet applications. 2. Are 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 Internet; according to reports, this mismatch between design and deployment has hindered interoperability of such codecs in interactive Internet applications. There exist codecs that can be widely implemented, but that are not standardized under the IPR rules 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 adoptions of such codecs in Internet applications. According to application developers and service operators, a video codec that meets both 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 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. Optimizing for very low bit rates (typically below 64 kbps) is out of scope because such work might necessitate specialized optimizations. In addition to the technical objectives, there is one process goal, which is 5. Ensuring the work is done under the IPR rules of the IETF. 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 or select 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 more than one codec, or a codec with multiple modes; however, it is not the goal of working group to produce more than one codec, and to reduce confusion in the marketplace the working group shall endeavor to produce as few codecs as possible. 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 AVT WG, define the codec's payload format for use with the Real-time Transport Protocol (RTP). - Collaborate with working groups in the Transport Area to identify important aspects of packet transmission over the Internet. - Collaborate with working groups in the Transport Area 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 use cases. The working group will coordinate with the ITU-T (Study group 16), with the intent of submitting the completed codec RFC for co-publication by the ITU-T if the ITU-T finds that appropriate. The working group will communicate a detailed description of the requirements and goals to other SDOs including the ITU-T and MPEG to help determine if existing codecs meet the requirements and goals. Information about codecs being standardized will be available to other SDOs in the form of internet drafts and the working group welcomes technical feedback from other SDOs and experts from other organizations. 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, refining them into a new document in accordance with the usual IETF procedures once consensus has been achieved. A codec that can be widely implemented and easily distributed among application developers, service operators, and end users is preferred. Many existing codecs that might fulfill some or most of the technical attributes listed above are encumbered in various ways. For example, patent holders might require that those wishing to implement the codec in software, deploy the codec in a service, or distribute the codec in software or hardware need to request a license, enter into a business agreement, pay licensing fees or royalties, or attempt to adhere to other special conditions or restrictions. Because such encumbrances have made it difficult to widely implement and easily distribute high-quality video codecs across the entire Internet community, the working group prefers unencumbered technologies in a way that is consistent with BCP 78 and BCP 79. In particular, 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 shall follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to redistribute and use. 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 along with source code for a reference implementation. The text description of the codec shall describe the mandatory, recommended, and optional portions of the encoder and decoder. It is envisioned that this document shall be a Proposed Standard document. 4. Specification of a storage format for non-interactive (HTTP) streaming or file transfer of the codec. It is envisioned that this document shall be a Proposed Standard document. 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 Submit codec specification to IESG (Standards Track) 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 From mohammedsraad@raadtech.com Tue Aug 21 06:54:59 2012 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 E224E21F851E for ; Tue, 21 Aug 2012 06:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.267 X-Spam-Level: X-Spam-Status: No, score=-1.267 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_URI_MEDS=0.842] 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 vSGQLEAaXNje for ; Tue, 21 Aug 2012 06:54:58 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id EDF4A21F84F8 for ; Tue, 21 Aug 2012 06:54:57 -0700 (PDT) Received: by weyu54 with SMTP id u54so5305662wey.31 for ; Tue, 21 Aug 2012 06:54:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:subject:date:organization:message-id:mime-version :content-type:x-mailer:thread-index:content-language :x-gm-message-state; bh=/B6vO/q3LsWgKcodURDucTINb6IhxKJRs9JGjHS1PKI=; b=MqQ2ZTKjZ7cSqywM1/Szb0m031xTcX+QwwBYyNVb0qWR3M9NwpJFwSPNWP4Pz8szoJ MRli2pp0Mg8d0qPTEQTEC000q1590N6aISK/ZfoCFlGOJtP3RACKn7Ja6y++70FOwdpI +WjnyopNTeKiFt7X+McGymuQqHAPQjlibB1m+hridBbSJ6LV2+XhBoel0P/MCNPsDVym eZUjhMbd8FUS+aBadCjiZu3GRjpIMJJa+Doqs6i6nzR1ZNncDFpXLS4iMX0p0WEao1ff yMjsPq9W4YsoV0/4u2TsyipPS8tqe3PS3olYDbf+6mP28JGHJKbknpAPFjgN400Ot/lD rm/g== Received: by 10.180.97.106 with SMTP id dz10mr39009340wib.21.1345557296956; Tue, 21 Aug 2012 06:54:56 -0700 (PDT) Received: from MSRRTC02 ([178.135.186.159]) by mx.google.com with ESMTPS id bc2sm4380318wib.0.2012.08.21.06.54.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Aug 2012 06:54:56 -0700 (PDT) From: "Mohammed Raad" To: Date: Tue, 21 Aug 2012 23:54:43 +1000 Organization: RaadTech Consulting Message-ID: <00ff01cd7fa4$861687c0$92439740$@raadtech.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0100_01CD7FF8.57C49390" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1/pB/m8SrwR45qTNOEOSux+7gKug== Content-Language: en-au X-Gm-Message-State: ALoCoQknl8LjjkM6j4BYe7o1iSkVlk5kHMAR/XzDla3ccjFA5Rt8d4uYbS5mSe4NW4hNr0WiwmSn Cc: video-codec@ietf.org Subject: [video-codec] regarding the proposed charter 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: Tue, 21 Aug 2012 14:01:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0100_01CD7FF8.57C49390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Timothy, I recently started to follow this reflector regarding the intention to define an internet friendly video codec within the IETF. You may be aware that MPEG has an ongoing Internet Video Coding (IVC) exploration activity which aims to meet many of the listed technical objectives you have listed in your proposed charter. You may also be aware that participation levels in that activity have been disappointing. So, I wanted to encourage potential participants within this activity to participate in the MPEG IVC exploration as well. The relevant reflector can be subscribed to by visiting http://mailman.rwth-aachen.de/mailman/listinfo/mpeg-ivc . My first impression is that the proposed charter you have posted provides a number of challenging and important standardization objectives. As you may be aware, a number of internet video coding and royalty free video coding advocates have so far chosen to not contribute to the IVC exploration activity. This is disappointing. Nonetheless, a number of MPEG's membership are continuing to work on developing a suitable video compression standard that can be used effectively on the internet. As such, I would like to encourage interested experts from the IETF to contribute to the IVC exploration so that we can meet the goals you have articulated (and, potentially, more). Best Regards, Mohammed Raad, PhD. Partner RAADTECH CONSULTING P.O. Box 113 Warrawong NSW 2502 Australia Phone: +61 414451478 Email: mohammedsraad@raadtech.com ------=_NextPart_000_0100_01CD7FF8.57C49390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear = Timothy,

 

I recently started to follow this reflector regarding = the intention to define an internet friendly video codec within the = IETF. You may be aware that MPEG has an ongoing Internet Video Coding = (IVC) exploration activity which aims to meet many of the listed = technical objectives you have listed in your proposed charter. You may = also be aware that participation levels in that activity have been = disappointing. So, I wanted to encourage potential participants within = this activity to participate in the MPEG IVC exploration as well. The = relevant reflector can be subscribed to by visiting http://m= ailman.rwth-aachen.de/mailman/listinfo/mpeg-ivc = .

 

My first impression is that the proposed charter you have = posted provides a number of challenging and important standardization = objectives. As you may be aware, a number of internet video coding and = royalty free video coding advocates have so far chosen to not contribute = to the IVC exploration activity. This is disappointing. Nonetheless, a = number of MPEG’s membership are continuing to work on developing a = suitable video compression standard that can be used effectively on the = internet. As such, I would like to encourage interested experts from the = IETF to contribute to the IVC exploration so that we can meet the goals = you have articulated (and, potentially, more).

 

Best = Regards,

 

Mohammed = Raad, PhD.
Partner
RAADTECH CONSULTING
P.O. Box = 113
Warrawong
NSW 2502 Australia
Phone: +61 414451478
Email: = mohammedsraad@raadtech.com

 

------=_NextPart_000_0100_01CD7FF8.57C49390--