From gonzalo.camarillo@ericsson.com Mon Sep 3 23:29:20 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 9955021F8527 for ; Mon, 3 Sep 2012 23:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 55Je1OgEnnBo for ; Mon, 3 Sep 2012 23:29:20 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D338421F8525 for ; Mon, 3 Sep 2012 23:29:16 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-dd-50459fbb1c2d Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 94.2C.25676.BBF95405; Tue, 4 Sep 2012 08:29:15 +0200 (CEST) Received: from [131.160.36.80] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.264.1; Tue, 4 Sep 2012 08:29:15 +0200 Message-ID: <50459FBA.9090508@ericsson.com> Date: Tue, 4 Sep 2012 09:29:14 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: video-codec@ietf.org X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLJMWRmVeSWpSXmKPExsUyM+Jvre7u+a4BBt+aFC2u9D5gdGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRvv+8ywFchUP+y4wNTCKdTFyckgImEhMPz+NFcIWk7hwbz1b FyMXh5DAKUaJI72/mCCcVYwS//f8AKviFdCW6NgznQXEZhFQkbi3egqYzSZgIbHl1n0wW1Qg UGLd1T/sEPWCEidnPgGLiwhISDxfNw3MFhaQkZja1soIsVlS4s3km2BxZgE9iSlXWxghbHmJ 7W/nMIPYQkB7lz9rYZnAyD8LydhZSFpmIWlZwMi8ilE4NzEzJ73cSC+1KDO5uDg/T684dRMj MMgObvmtuoPxzjmRQ4zSHCxK4rzWW/f4CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCsiNls 76rWEmFY9G35/QSTe5fZdtqYSUxwTjK7c83b/onv7ry/FbcKNy5TLJByPP2gpv35j+5v/A5b Xy/NzUvKWcLQpX3kf9Ld1HtMrH5JFceffNpTfnC71Tbr/3Nn/Z64qqVm02Kp+avjUlduaa9j 9N9ek7Rif9CBBQZRfBurSsxlVNenXpNXYinOSDTUYi4qTgQAm+r5hwACAAA= Subject: [video-codec] TEST, please ignore 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, 04 Sep 2012 06:29:20 -0000 Testing the list. Gonzalo From sergel@google.com Tue Sep 4 02:32:20 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 0971F21F862A for ; Tue, 4 Sep 2012 02:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 GXMZtf4LrLjV for ; Tue, 4 Sep 2012 02:32:19 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8767D21F85A3 for ; Tue, 4 Sep 2012 02:32:19 -0700 (PDT) Received: by iabz21 with SMTP id z21so9803281iab.31 for ; Tue, 04 Sep 2012 02:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-system-of-record; bh=Zgw9723GGxO9qvVA4V8CWhUB0k+ipDjfnZRKZSPm/dQ=; b=m3v8R0ck3MVEE83NQcF7M/stZMJ7SpRQ0ft1Y8IrLIwglruxAXKTy4OhoZrXo+24xV bLtlOQgwb4Ncld2FqC+nNN1cad+hz38InuW1RYklH33/sPcBWE2Fh7FzB5v7YQLHh2dS o40mukFFLIcI3/9tSeyFle+pplR4S/7B9DZ3mVEPzhIevYH4saGSmNpmvJFEJGAqlS+p +djPPMWiE8PwkNc/9z3Vu4zEwjKJmEMeEjCgfTx1v77jGD1Ow5KcqXJySCFiCVTcQuxq F9B7gCKSYCOaUzfRZWU8yY4R5YA6fWcc5Xz4M6XJXfMBaW0/8dyKNfKrkmTTdIqo5TFO I0LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=Zgw9723GGxO9qvVA4V8CWhUB0k+ipDjfnZRKZSPm/dQ=; b=HhDUJPMzHCx2uzul2hUugC8BA9THTMphUaECaB6ZTaq+oLDRae6Rz+INbL3rDDYcSy jC3wSWV74PoAla1ELkdVTC9FhJ5yXnsRWSASHAgbxWHO13Zb3yn14uA1hm7b5yYDhuys 92v2g7/QS5IQyoovo4OSdQ5n//KPB1kzg9MWqdHMQSN01HVZPJo51Hlch4Gb84S6Pkl8 c8Ze2lx2uxGvZD9NiMmGRjrMA8NzU7sifkaQMa2MIxPVnM1ZornUWjdqa5g5MhMTeX1O hqPc/lDYh8j9wJ0yusAfEyuv+QVOZhjCdYHfj8lGFqWJYZwdRNxpQxaksuoYvCDuwSFO SH2g== Received: by 10.50.40.133 with SMTP id x5mr13264968igk.69.1346751139140; Tue, 04 Sep 2012 02:32:19 -0700 (PDT) Received: by 10.50.40.133 with SMTP id x5mr13264960igk.69.1346751139003; Tue, 04 Sep 2012 02:32:19 -0700 (PDT) MIME-Version: 1.0 Sender: sergel@google.com Received: by 10.231.135.1 with HTTP; Tue, 4 Sep 2012 02:31:48 -0700 (PDT) In-Reply-To: <50459FBA.9090508@ericsson.com> References: <50459FBA.9090508@ericsson.com> From: Serge Lachapelle Date: Tue, 4 Sep 2012 11:31:48 +0200 X-Google-Sender-Auth: F-_9638gRHivQ9Xg60aTW3g-DGo Message-ID: To: Gonzalo Camarillo Content-Type: multipart/alternative; boundary=14dae93403d93dbd0b04c8dcef72 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmfGLC+B71lr2pRPHQqLwir9/zKhOKyhxxkFa9ClAYkV9kd9FOf22pgbK6yeT66Dbr4SJWBQaRM+bWgwMEWbc8XXY3/T1OXkPGQ3Bah7/jBooJafVeUs4A/T+78IhIdyM2ksdqtLtkLmPA5w5LlbpbTGWm4FaaY+RjeZ6h7zxEszmUqyTjS8CLVZ1IxSxQ9OhKIP6Ji Cc: video-codec@ietf.org Subject: Re: [video-codec] TEST, please ignore 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, 04 Sep 2012 09:32:20 -0000 --14dae93403d93dbd0b04c8dcef72 Content-Type: text/plain; charset=ISO-8859-1 Yes, it's quiet in here :) /S On Tue, Sep 4, 2012 at 8:29 AM, Gonzalo Camarillo < Gonzalo.Camarillo@ericsson.com> wrote: > Testing the list. > > Gonzalo > _______________________________________________ > video-codec mailing list > video-codec@ietf.org > https://www.ietf.org/mailman/listinfo/video-codec > --14dae93403d93dbd0b04c8dcef72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, it's quiet in here :)

/S

On Tue, Sep 4, 2012 at 8:29 AM, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> wrote:
Testing the list.

Gonzalo
_______________________________________________
video-codec mailing list
video-codec@ietf.org
https://www.ietf.org/mailman/listinfo/video-codec

--14dae93403d93dbd0b04c8dcef72-- From pre@ulrik.uio.no Sun Sep 16 00:53:08 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 E2F8221F8455 for ; Sun, 16 Sep 2012 00:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 IK0lFfH4juTV for ; Sun, 16 Sep 2012 00:53:08 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) by ietfa.amsl.com (Postfix) with ESMTP id E422E21F843E for ; Sun, 16 Sep 2012 00:53:07 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1TD9f7-0001VH-Nw for video-codec@ietf.org; Sun, 16 Sep 2012 09:53:05 +0200 Received: from diskless.uio.no ([129.240.6.26]) by mail-mx2.uio.no with esmtp (Exim 4.80) (envelope-from ) id 1TD9f7-0004bN-4j; Sun, 16 Sep 2012 09:53:05 +0200 Received: from pre by diskless.uio.no with local (Exim 4.72) (envelope-from ) id 1TD9f6-0005YY-CM; Sun, 16 Sep 2012 09:53:04 +0200 From: Petter Reinholdtsen To: video-codec@ietf.org User-Agent: Notmuch/0.11~rc1 (http://notmuchmail.org) Emacs/23.2.1 (i486-pc-linux-gnu) Date: Sun, 16 Sep 2012 09:53:04 +0200 Message-ID: <2flpq5mpfof.fsf@diskless.uio.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: Petter Reinholdtsen X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 5 sum msgs/h 2 total rcpts 26222 max rcpts/h 383 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.9, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-0.918, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 2F01A769FE619D10DEE9C9D799EBC831E83EA37D X-UiO-SPAM-Test: remote_host: 129.240.6.26 spam_score: -58 maxlevel 80 minaction 0 bait 0 mail/h: 1 total 2621 max/h 10 blacklist 0 greylist 0 ratelimit 0 X-Mailman-Approved-At: Sun, 16 Sep 2012 01:10:16 -0700 Subject: [video-codec] Please make a free and open video codec standard as defined by Digistan 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: Sun, 16 Sep 2012 07:54:55 -0000 I was very happy to discover that IETF had some activity to standardise a video codec that can be used by everyone without royalty payments. I hope this effort result in a work group and a good specification.. I also hope the work can ensure that the final specification is a free and open standard according to the definition from Digistan, : The Digital Standards Organization defines free and open standard as follows: * A free and open standard is immune to vendor capture at all stages in its life-cycle. Immunity from vendor capture makes it possible to freely use, improve upon, trust, and extend a standard over time. * The standard is adopted and will be maintained by a not-for-profit organization, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties. * The standard has been published and the standard specification document is available freely. It must be permissible to all to copy, distribute, and use it freely. * The patents possibly present on (parts of) the standard are made irrevocably available on a royalty-free basis. * There are no constraints on the re-use of the standard. The economic outcome of a free and open standard, which can be measured, is that it enables perfect competition between suppliers of products based on the standard. The initial charter draft look good in that respect, and I just wanted to mention that I believe the charter look good. -- Happy hacking Petter Reinholdtsen From tterribe@xiph.org Tue Sep 18 12:12:54 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 D32A321E8045 for ; Tue, 18 Sep 2012 12:12:53 -0700 (PDT) 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, 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 EwA7aKPZf6yN for ; Tue, 18 Sep 2012 12:12:53 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 08DFB21E8034 for ; Tue, 18 Sep 2012 12:12:53 -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 704D6F2627; Tue, 18 Sep 2012 12:12:52 -0700 (PDT) Message-ID: <5058C7B3.8050207@xiph.org> Date: Tue, 18 Sep 2012 12:12:51 -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: Petter Reinholdtsen References: <2flpq5mpfof.fsf@diskless.uio.no> In-Reply-To: <2flpq5mpfof.fsf@diskless.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: video-codec@ietf.org Subject: Re: [video-codec] Please make a free and open video codec standard as defined by Digistan 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, 18 Sep 2012 19:12:54 -0000 Petter Reinholdtsen wrote: > The initial charter draft look good in that respect, and I just wanted > to mention that I believe the charter look good. Thanks. I agree these are all desirable features. It's not possible to guarantee them all in advance, but I've tried to do as well as one can do in a charter (by liberally stealing Peter Saint-Andre's text from the codec WG charter), though I admit I'm not sure how to put "immunity from vendor capture" in a charter, but it was definitely something we considered during Opus development. Suggestions for improvements are welcome. From mohammedsraad@raadtech.com Tue Sep 18 20:47:19 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 7664E11E80E8 for ; Tue, 18 Sep 2012 20:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.757 X-Spam-Level: X-Spam-Status: No, score=-2.757 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 szoJJQbCupM8 for ; Tue, 18 Sep 2012 20:47:19 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id A859311E80E7 for ; Tue, 18 Sep 2012 20:47:18 -0700 (PDT) Received: by wibhq12 with SMTP id hq12so6296270wib.1 for ; Tue, 18 Sep 2012 20:47:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:organization :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language:x-gm-message-state; bh=uT4KSbv8yxqhZey1SecS9KxPo7JfYbslgebwhkOSoj4=; b=GJ7UxEXQz68x5gO13vJax01KKbuQR2W8HLfMECR/NbDtLzWpjK79cxDg6KQh6ES57T WKSOTNP+TrOwZ2/kV8olOb7VdHQq/WbyliUUL/1ULQ6XCZ1v+Bjx6s/ixmJByQxwIdNJ e+xwwWOCiRe2xg7k+N93gZBTr42dsy4vH/BDnhATS4iD7TRjTEsS9XenqkgKQs0vT9PR htIffUCyMX64Vb94HyNDyHugm07StSIpJuNY2SKwk0gVNT7V0nnY3z3xjsfBohrkVJuy RzsNqGnzV7Nki987oVBLkz3KCT9rOZMHX+/Tos27k+58b3GnFnKxA8PrE0q6Uy/piRIy mfMg== Received: by 10.180.82.230 with SMTP id l6mr3776013wiy.21.1348026437369; Tue, 18 Sep 2012 20:47:17 -0700 (PDT) Received: from MSRRTC02 ([94.187.93.146]) by mx.google.com with ESMTPS id r9sm2747266wia.2.2012.09.18.20.47.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Sep 2012 20:47:16 -0700 (PDT) From: "Mohammed Raad" To: "'Timothy B. Terriberry'" , "'Petter Reinholdtsen'" References: <2flpq5mpfof.fsf@diskless.uio.no> <5058C7B3.8050207@xiph.org> In-Reply-To: <5058C7B3.8050207@xiph.org> Date: Wed, 19 Sep 2012 13:47:13 +1000 Organization: RaadTech Consulting Message-ID: <003c01cd9619$76209cd0$6261d670$@raadtech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIVDaLBeUMlbB5+laNu2ok0aYSd0QJcrohFlu8vutA= Content-Language: en-au X-Gm-Message-State: ALoCoQlGabebyKGFBHBwZlIcHtx2yNsZM7IKWfl1xhFm/n8VfNtkXltEZJrq3L3y+c9FMULnc8Dy Cc: video-codec@ietf.org Subject: Re: [video-codec] Please make a free and open video codec standard as defined by Digistan 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, 19 Sep 2012 03:47:19 -0000 Dear Timothy, One of the advantages of international standards (I mean those produced by ITU, ISO, IEC) is that they provide a great deal of "immunity from vendor capture" because of the process used to develop these standards and because of the commitments that technology (IP) owners make when they accept or request that their technology is included in these standards. As I mentioned previously, ISO/IEC JTC1/SC29/WG11 (MPEG) has an activity attempting to develop an international standard in the space that this charter addresses. Will those in the IETF interested in this area of technology attempt to at least establish a liaison relationship between MPEG and the IETF working groups in need of a video coding standard that meets the requirements set in this charter? I would recommend this step to be taken to avoid market confusion and fragmentation. Best Regards, Mohammed Raad, PhD. Partner RAADTECH CONSULTING P.O. Box 113 Warrawong NSW 2502 Australia Phone: +61 414451478 Email: mohammedsraad@raadtech.com -----Original Message----- From: video-codec-bounces@ietf.org [mailto:video-codec-bounces@ietf.org] On Behalf Of Timothy B. Terriberry Sent: Wednesday, 19 September 2012 5:13 AM To: Petter Reinholdtsen Cc: video-codec@ietf.org Subject: Re: [video-codec] Please make a free and open video codec standard as defined by Digistan Petter Reinholdtsen wrote: > The initial charter draft look good in that respect, and I just wanted > to mention that I believe the charter look good. Thanks. I agree these are all desirable features. It's not possible to guarantee them all in advance, but I've tried to do as well as one can do in a charter (by liberally stealing Peter Saint-Andre's text from the codec WG charter), though I admit I'm not sure how to put "immunity from vendor capture" in a charter, but it was definitely something we considered during Opus development. Suggestions for improvements are welcome. _______________________________________________ video-codec mailing list video-codec@ietf.org https://www.ietf.org/mailman/listinfo/video-codec From tterribe@xiph.org Tue Sep 18 21:04:57 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 6933721E8095 for ; Tue, 18 Sep 2012 21:04:57 -0700 (PDT) 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, 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 MUojOtJyJsPo for ; Tue, 18 Sep 2012 21:04:56 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id D030021E8090 for ; Tue, 18 Sep 2012 21:04:56 -0700 (PDT) Received: from [172.17.0.5] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 80B93F22EB for ; Tue, 18 Sep 2012 21:04:53 -0700 (PDT) Message-ID: <50594464.50400@xiph.org> Date: Tue, 18 Sep 2012 21:04:52 -0700 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 References: <2flpq5mpfof.fsf@diskless.uio.no> <5058C7B3.8050207@xiph.org> <003c01cd9619$76209cd0$6261d670$@raadtech.com> In-Reply-To: <003c01cd9619$76209cd0$6261d670$@raadtech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [video-codec] Please make a free and open video codec standard as defined by Digistan 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, 19 Sep 2012 04:04:57 -0000 Mohammed Raad wrote: > One of the advantages of international standards (I mean those produced by > ITU, ISO, IEC) is that they provide a great deal of "immunity from vendor > capture" because of the process used to develop these standards and because In my experience vendor capture often that happens _after_ standardization (see the current mess around TTML as a great example of the kinds of things that can go wrong: ). Getting the standardization process right is the easy part. > charter addresses. Will those in the IETF interested in this area of > technology attempt to at least establish a liaison relationship between MPEG > and the IETF working groups in need of a video coding standard that meets > the requirements set in this charter? I would recommend this step to be > taken to avoid market confusion and fragmentation. I personally think a liaison relationship is perfectly reasonable. I know we had them with the ITU, ISO, and 3GPP in the codec WG, and I had assumed we'd wind up doing something similar for this WG if we formed it. I'd have to investigate the details of what we need to do to set one up. From mohammedsraad@raadtech.com Wed Sep 19 11:47:41 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 2EBDB21F849B for ; Wed, 19 Sep 2012 11:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.178 X-Spam-Level: X-Spam-Status: No, score=-3.178 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599, 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 xsKtafMPwABR for ; Wed, 19 Sep 2012 11:47:40 -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 CE0C921F8498 for ; Wed, 19 Sep 2012 11:47:39 -0700 (PDT) Received: by weyx48 with SMTP id x48so831167wey.31 for ; Wed, 19 Sep 2012 11:47:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:organization:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=EqTacC2Ny/TEwtDN0B+FjrhLwaA9IcsIpNXsQyH5JN8=; b=c7eaPohIavE88MpNa3l1FsLyiVooUwoiDK0nbGcXkf0O7yh90OMKl+s7o6mJXabytv IHUTrOgaj33g6mEw3ZS3KJZOjAjCkouCHu6NPJuMDWc6+myWw26FW7L/tZXjOejDWVV+ 0SI9TXQr7ZN3WcqER9sMB38EZdJXdEiKMMgOS3MFyH6UOLRxbxOeOcKHVMs8BxSsI+Ui VoAR0oMsLrJ9pKLrfTWoGRTrBp2MoIB54Ph++hD4OS30Du4OtxvVGsHB/iEFc2m60i11 N5NXlpdlZWoY7HiyELYLsd4H2/jIlbvwroRpk0ALFhyB92JDtUWzgO3uSwnHUbONh8vX JgPQ== Received: by 10.180.14.74 with SMTP id n10mr8406265wic.17.1348080458739; Wed, 19 Sep 2012 11:47:38 -0700 (PDT) Received: from MSRRTC02 ([94.187.42.181]) by mx.google.com with ESMTPS id cu1sm28844256wib.6.2012.09.19.11.47.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Sep 2012 11:47:37 -0700 (PDT) From: "Mohammed Raad" To: "'Timothy B. Terriberry'" , References: <2flpq5mpfof.fsf@diskless.uio.no> <5058C7B3.8050207@xiph.org> <003c01cd9619$76209cd0$6261d670$@raadtech.com> <50594464.50400@xiph.org> In-Reply-To: <50594464.50400@xiph.org> Date: Thu, 20 Sep 2012 04:47:34 +1000 Organization: RaadTech Consulting Message-ID: <000301cd9697$3d041c00$b70c5400$@raadtech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIVDaLBeUMlbB5+laNu2ok0aYSd0QJcrohFAjaoJIICBOhtjZbOSoQg Content-Language: en-au X-Gm-Message-State: ALoCoQkYe3hvAm85wvefdjkEeha6EgK1zgkwGIuIUv2pcpUeRVkjK08G2yD8HQvYY05gVHmw+XfR Subject: Re: [video-codec] Please make a free and open video codec standard as defined by Digistan 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, 19 Sep 2012 18:47:41 -0000 I think that what you are pointing to is the different standardized tool subset that a vendor may implement - such that products from different vendors are not interoperable. At ISO/IEC this problem is mostly manifested in one standard having many profiles (e.g. AVC). We are trying to avoid this problem within the IVC activity by defining one profile which would be non-royalty bearing. Of course compatibility is based on which profile is supported and the assumption is that the vast majority of vendors would support a non-royalty bearing profile. I think that it would be useful for all involved if WG11 was given an early look at what this proposed charter contains. Besides having a formal liaison arrangement, this can be done through an input contribution to the next meeting (see http://mpeg.chiariglione.org/ for details). Best Regards, Mohammed -----Original Message----- From: video-codec-bounces@ietf.org [mailto:video-codec-bounces@ietf.org] On Behalf Of Timothy B. Terriberry Sent: Wednesday, 19 September 2012 2:05 PM To: video-codec@ietf.org Subject: Re: [video-codec] Please make a free and open video codec standard as defined by Digistan Mohammed Raad wrote: > One of the advantages of international standards (I mean those > produced by ITU, ISO, IEC) is that they provide a great deal of > "immunity from vendor capture" because of the process used to develop > these standards and because In my experience vendor capture often that happens _after_ standardization (see the current mess around TTML as a great example of the kinds of things that can go wrong: ). Getting the standardization process right is the easy part. > charter addresses. Will those in the IETF interested in this area of > technology attempt to at least establish a liaison relationship > between MPEG and the IETF working groups in need of a video coding > standard that meets the requirements set in this charter? I would > recommend this step to be taken to avoid market confusion and fragmentation. I personally think a liaison relationship is perfectly reasonable. I know we had them with the ITU, ISO, and 3GPP in the codec WG, and I had assumed we'd wind up doing something similar for this WG if we formed it. I'd have to investigate the details of what we need to do to set one up. _______________________________________________ video-codec mailing list video-codec@ietf.org https://www.ietf.org/mailman/listinfo/video-codec From stewe@stewe.org Wed Sep 19 11:57:13 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 6685611E8091 for ; Wed, 19 Sep 2012 11:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.678 X-Spam-Level: X-Spam-Status: No, score=-4.678 tagged_above=-999 required=5 tests=[AWL=1.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 X4JkwQcH++XN for ; Wed, 19 Sep 2012 11:57:12 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED5D21F8602 for ; Wed, 19 Sep 2012 11:57:12 -0700 (PDT) Received: from mail260-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.23; Wed, 19 Sep 2012 18:57:11 +0000 Received: from mail260-tx2 (localhost [127.0.0.1]) by mail260-tx2-R.bigfish.com (Postfix) with ESMTP id 64004E40216; Wed, 19 Sep 2012 18:57:11 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT005.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: PS-26(zz98dI9371I542M1432I1418I1453Id6f1izz1202h1d1ah1d2ah1082kzz8275ch1033IL17326ah8275bh8275dhz2fh2a8h668h839h944he5bhf0ah107ah1220h1288h12a5h12a9h12bdh1155h) Received-SPF: pass (mail260-tx2: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT005.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail260-tx2 (localhost.localdomain [127.0.0.1]) by mail260-tx2 (MessageSwitch) id 1348081028903071_2326; Wed, 19 Sep 2012 18:57:08 +0000 (UTC) Received: from TX2EHSMHS027.bigfish.com (unknown [10.9.14.252]) by mail260-tx2.bigfish.com (Postfix) with ESMTP id D8A541580043; Wed, 19 Sep 2012 18:57:08 +0000 (UTC) Received: from BL2PRD0710HT005.namprd07.prod.outlook.com (157.56.240.133) by TX2EHSMHS027.bigfish.com (10.9.99.127) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 19 Sep 2012 18:57:06 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.6]) by BL2PRD0710HT005.namprd07.prod.outlook.com ([10.255.102.40]) with mapi id 14.16.0190.008; Wed, 19 Sep 2012 18:57:01 +0000 From: Stephan Wenger To: Mohammed Raad , "'Timothy B. Terriberry'" , "video-codec@ietf.org" Thread-Topic: [video-codec] Please make a free and open video codec standard as defined by Digistan Thread-Index: AQHNlpiM2XUZHcYqF0yn0cMqGMfb0w== Date: Wed, 19 Sep 2012 18:57:00 +0000 Message-ID: In-Reply-To: <000301cd9697$3d041c00$b70c5400$@raadtech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: text/plain; charset="us-ascii" Content-ID: <621DAAA13B1ABA47907378A77F37460C@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [video-codec] Please make a free and open video codec standard as defined by Digistan 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, 19 Sep 2012 18:57:13 -0000 There is no need to set up another formal relationship: MPEG and the IETF have such a relationship established. It has been used on or off; the last burst of activity was related to dash. Let me also note that, in the IETF, liaison activity does not have the same relevance as in bodies like MPEG. In the IETF, if you want your voice to be heard, you need to follow rule #1: be there. (Which, by the way, is not necessarily meant as physical presence, but rather as being an active contributor--another difference between the IETF and more traditional SDOs). All liaison activity of the world cannot substitute active participation here. Stephan On 9.19.2012 11:47 , "Mohammed Raad" wrote: >I think that what you are pointing to is the different standardized tool >subset that a vendor may implement - such that products from different >vendors are not interoperable. At ISO/IEC this problem is mostly >manifested >in one standard having many profiles (e.g. AVC). We are trying to avoid >this >problem within the IVC activity by defining one profile which would be >non-royalty bearing. Of course compatibility is based on which profile is >supported and the assumption is that the vast majority of vendors would >support a non-royalty bearing profile. > >I think that it would be useful for all involved if WG11 was given an >early >look at what this proposed charter contains. Besides having a formal >liaison >arrangement, this can be done through an input contribution to the next >meeting (see http://mpeg.chiariglione.org/ for details). > >Best Regards,=20 > >Mohammed=20 > >-----Original Message----- >From: video-codec-bounces@ietf.org [mailto:video-codec-bounces@ietf.org] >On >Behalf Of Timothy B. Terriberry >Sent: Wednesday, 19 September 2012 2:05 PM >To: video-codec@ietf.org >Subject: Re: [video-codec] Please make a free and open video codec >standard >as defined by Digistan > >Mohammed Raad wrote: >> One of the advantages of international standards (I mean those >> produced by ITU, ISO, IEC) is that they provide a great deal of >> "immunity from vendor capture" because of the process used to develop >> these standards and because > >In my experience vendor capture often that happens _after_ standardization >(see the current mess around TTML as a great example of the kinds of >things >that can go wrong: >). >Getting the standardization process right is the easy part. > >> charter addresses. Will those in the IETF interested in this area of >> technology attempt to at least establish a liaison relationship >> between MPEG and the IETF working groups in need of a video coding >> standard that meets the requirements set in this charter? I would >> recommend this step to be taken to avoid market confusion and >fragmentation. > >I personally think a liaison relationship is perfectly reasonable. I know >we >had them with the ITU, ISO, and 3GPP in the codec WG, and I had assumed >we'd >wind up doing something similar for this WG if we formed it. I'd have to >investigate the details of what we need to do to set one up. >_______________________________________________ >video-codec mailing list >video-codec@ietf.org >https://www.ietf.org/mailman/listinfo/video-codec > >_______________________________________________ >video-codec mailing list >video-codec@ietf.org >https://www.ietf.org/mailman/listinfo/video-codec > From mohammedsraad@raadtech.com Wed Sep 19 12:12:50 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 0D60021F847C for ; Wed, 19 Sep 2012 12:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.968 X-Spam-Level: X-Spam-Status: No, score=-2.968 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, 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 rwYHGYHMpNwU for ; Wed, 19 Sep 2012 12:12:49 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id C4B7C21F846B for ; Wed, 19 Sep 2012 12:12:48 -0700 (PDT) Received: by wibhi8 with SMTP id hi8so4688643wib.13 for ; Wed, 19 Sep 2012 12:12:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:organization:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=uFo32ULs3qhpCgxKqZSXp+3H/0fwYKq28xwjn3jVu7E=; b=ZTDc/OCklMRehix4zbUFka0sW2vW8N8mcaFlAoZDpj3SG3UwQ053G3eMT9m2z/PZJj R26CnLq3rxh9Alu3dtTUnXKOR09O46c2RT86RISekKeK3I2RIm4mO3PD4ZxYuASCDYZ4 ov943143jWdIMETIXtcScvvD9dtH8hnIIxDc4utk++X7qloPuacIfGecc6nLN1lWckrL t9afkW8JSjRW92IofirCkUklcLIF75rTMC9gSkvPWuDfN/NjnWykKe462nJWrD/M6/EE +GF1uJILlTDWmhEo+eAbRlHmIer1PwGJY/IuTKzjU+lAx+oLpLibV6YY03LvYMYGt5/w 2QYg== Received: by 10.180.106.130 with SMTP id gu2mr8492723wib.20.1348081967740; Wed, 19 Sep 2012 12:12:47 -0700 (PDT) Received: from MSRRTC02 ([94.187.42.181]) by mx.google.com with ESMTPS id fr4sm6424153wib.8.2012.09.19.12.12.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Sep 2012 12:12:46 -0700 (PDT) From: "Mohammed Raad" To: "'Stephan Wenger'" , "'Timothy B. Terriberry'" , References: <000301cd9697$3d041c00$b70c5400$@raadtech.com> In-Reply-To: Date: Thu, 20 Sep 2012 05:12:43 +1000 Organization: RaadTech Consulting Message-ID: <000701cd969a$c04b1b10$40e15130$@raadtech.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMPlYwt/ubSYMDjy8T2wxRn9DTV3ZUOCAhA Content-Language: en-au X-Gm-Message-State: ALoCoQln1BZwhYRZ9BzFlon4OV3al7i2jpXCJSjqr3AWxwr8A0oRvFAOG97wB27gTtOpY2os7MCQ Subject: Re: [video-codec] Please make a free and open video codec standard as defined by Digistan 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, 19 Sep 2012 19:12:50 -0000 OK, that's all fine. Whichever way we do things, the purpose is to ensure that we are on the same page because I strongly doubt that having two SDOs working separately on addressing this particular space will lead to anything in the next few years. BTW "be there" also applies to getting WG11 to deliver what is needed. Mohammed -----Original Message----- From: Stephan Wenger [mailto:stewe@stewe.org] Sent: Thursday, 20 September 2012 4:57 AM To: Mohammed Raad; 'Timothy B. Terriberry'; video-codec@ietf.org Subject: Re: [video-codec] Please make a free and open video codec standard as defined by Digistan There is no need to set up another formal relationship: MPEG and the IETF have such a relationship established. It has been used on or off; the last burst of activity was related to dash. Let me also note that, in the IETF, liaison activity does not have the same relevance as in bodies like MPEG. In the IETF, if you want your voice to be heard, you need to follow rule #1: be there. (Which, by the way, is not necessarily meant as physical presence, but rather as being an active contributor--another difference between the IETF and more traditional SDOs). All liaison activity of the world cannot substitute active participation here. Stephan On 9.19.2012 11:47 , "Mohammed Raad" wrote: >I think that what you are pointing to is the different standardized >tool subset that a vendor may implement - such that products from >different vendors are not interoperable. At ISO/IEC this problem is >mostly manifested in one standard having many profiles (e.g. AVC). We >are trying to avoid this problem within the IVC activity by defining >one profile which would be non-royalty bearing. Of course compatibility >is based on which profile is supported and the assumption is that the >vast majority of vendors would support a non-royalty bearing profile. > >I think that it would be useful for all involved if WG11 was given an >early look at what this proposed charter contains. Besides having a >formal liaison arrangement, this can be done through an input >contribution to the next meeting (see http://mpeg.chiariglione.org/ for >details). > >Best Regards, > >Mohammed > >-----Original Message----- >From: video-codec-bounces@ietf.org >[mailto:video-codec-bounces@ietf.org] >On >Behalf Of Timothy B. Terriberry >Sent: Wednesday, 19 September 2012 2:05 PM >To: video-codec@ietf.org >Subject: Re: [video-codec] Please make a free and open video codec >standard as defined by Digistan > >Mohammed Raad wrote: >> One of the advantages of international standards (I mean those >> produced by ITU, ISO, IEC) is that they provide a great deal of >> "immunity from vendor capture" because of the process used to develop >> these standards and because > >In my experience vendor capture often that happens _after_ >standardization (see the current mess around TTML as a great example of >the kinds of things that can go wrong: >). >Getting the standardization process right is the easy part. > >> charter addresses. Will those in the IETF interested in this area of >> technology attempt to at least establish a liaison relationship >> between MPEG and the IETF working groups in need of a video coding >> standard that meets the requirements set in this charter? I would >> recommend this step to be taken to avoid market confusion and >fragmentation. > >I personally think a liaison relationship is perfectly reasonable. I >know we had them with the ITU, ISO, and 3GPP in the codec WG, and I had >assumed we'd wind up doing something similar for this WG if we formed >it. I'd have to investigate the details of what we need to do to set >one up. >_______________________________________________ >video-codec mailing list >video-codec@ietf.org >https://www.ietf.org/mailman/listinfo/video-codec > >_______________________________________________ >video-codec mailing list >video-codec@ietf.org >https://www.ietf.org/mailman/listinfo/video-codec > From tterribe@xiph.org Mon Sep 24 13:56: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 9CAEE1F0C5C for ; Mon, 24 Sep 2012 13:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 hmcMuqJDBohV for ; Mon, 24 Sep 2012 13:56:20 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id C9C881F041D for ; Mon, 24 Sep 2012 13:56: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 582D7F2609; Mon, 24 Sep 2012 13:56:20 -0700 (PDT) Message-ID: <5060C8F4.8050200@xiph.org> Date: Mon, 24 Sep 2012 13:56:20 -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: Robert Sparks , Gonzalo Camarillo Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: video-codec@ietf.org Subject: [video-codec] BoF request: video-codec - Internet Video Codec 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, 24 Sep 2012 20:56:24 -0000 The proposers would like to request a 2-hour slot for a BoF at IETF 85 in Atlanta on the subject of standardizing a video codec. Description ----------- There are efforts underway by several groups to produce a next-generation, royalty-free (RF) video codec, including VPnext by Google [1,2] and Daala by Mozilla/Xiph.Org [3]. While far from complete, we hope that these can become the backbone of a truly universally deployable, interactive video codec standard that is competitive with royalty-bearing offerings. These projects are just the start. Recent efforts within the MPEG LA to create an RF license for the Restricted Baseline profile of H.264, while ultimately unsuccessful, showed that there are many consumer device manufacturers that would support RF licensing for a video codec. Not all will participate in development, but even providing review, as some have agreed to do, is useful. In the CODEC WG, it was the input and feature requests from a wide range of IETF participants that led to a codec that excelled at an extremely broad range of applications. This kind of review is much easier for codecs, where there are easily-understood, measurable objectives ("everyone has two eyes"). The IETF is typically used to dealing with much thornier questions, such as, "Will this interoperate with legacy, possibly-broken implementations?" or "Is this protocol sufficiently extensible?" The success of Opus from the CODEC WG has also shown that collaboration, based on the IETF's principals of open participation, can produce better results than competition between patented technologies. The IPR rules in BCP 78 and 79 are also critical for success. They impose a duty to disclose, and require exact patent or patent application numbers, in addition to basic licensing terms. This allows participants to evaluate the risk of infringement and, if appropriate, design work arounds, in any technology adopted, and assess the cost of adopting such technology. Because it does not force participants to agree to license their patents under RF terms, it helps to encourage participation even by those opposed to such terms (instead of guaranteeing they stay away). In addition to an environment which encourages third-party disclosures, this provides much better chances of success than SDOs which have a "patent-blind" process [4] or which require blanket RF grants. [1] http://downloads.webmproject.org/ngov2012/pdf/04-ngov-project-update.pdf [2] http://downloads.webmproject.org/ngov2012/wilkins/vpnext-results.html [3] http://xiph.org/daala/ [4] http://lists.xiph.org/pipermail/theora/2010-April/003769.html Details ------- The proposed working group name is videoc-codec. Conflicts to avoid: APPSAWG, AVTCORE, CLUE, CODEC, IRI, MMUSIC, PRECIS, RMCAT, RTCWEB, XMPP Expected attendance: 80 persons Does it require WebEX?: No Does it require Meetecho?: Yes BOF agenda ---------- Chair(s): Peter Saint-Andre (plus a possible TBD co-chair) Area: RAI Area directors: Gonzalo Camarillo and Robert J. Sparks Draft agenda (subject to modifications): - Note Well, logistics, agenda bash (Chairs, 5 min) - Introduction and scoping of BoF (AD, 10 min) - Goals (Chairs, 10 min) - Engineering progress to date (Google, Mozilla 20 min) - Is it reasonable to do this work at the IETF? (All, 45 min) - Charter discussion (All, 25 min) - Conclusions and next steps (Chairs/AD, 5 min) Total timeslot: 2 hours WG charter (proposed) --------------------- Internet Video Codec (video-codec) Status: Proposed Working Group Last Updated: 2012-09-24 Chair(s): TBD RAI Area Director(s): Robert J. Sparks (rjsparks@nostrum.com) Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com) RAI Area Advisor: Robert J. Sparks (rjsparks@nostrum.com) Mailing Lists: video-codec@ietf.org Description of Working Group ---------------------------- 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 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 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. 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 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 if they find 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 tterribe@xiph.org Mon Sep 24 14:05:16 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 6F0EB21F8896 for ; Mon, 24 Sep 2012 14:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.427 X-Spam-Level: X-Spam-Status: No, score=-1.427 tagged_above=-999 required=5 tests=[AWL=0.250, 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 v+km2tZ5XB78 for ; Mon, 24 Sep 2012 14:05:16 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0943921F8895 for ; Mon, 24 Sep 2012 14:05:15 -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 AFD1FF25BB for ; Mon, 24 Sep 2012 14:05:14 -0700 (PDT) Message-ID: <5060CB0A.2050101@xiph.org> Date: Mon, 24 Sep 2012 14:05:14 -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 References: <5060C8F4.8050200@xiph.org> In-Reply-To: <5060C8F4.8050200@xiph.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [video-codec] BoF request: video-codec - Internet Video Codec 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, 24 Sep 2012 21:05:16 -0000 Just as an FYI for the list, the BoF request includes an updated charter, mostly incorporating off-list feedback on grammar and wording from Peter Saint-Andre and Ted Hardie. It now references the newly-formed RMCAT WG (thanks Ted), and mentions liaisons to both ITU-T and MPEG. One item I forgot was to add a "Test results" document to the deliverables (there are milestones for it, but no entry in the deliverables list). I'll make sure that gets added to the next iteration. From gonzalo.camarillo@ericsson.com Tue Sep 25 00:45:39 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 6DAD121F8902 for ; Tue, 25 Sep 2012 00:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.73 X-Spam-Level: X-Spam-Status: No, score=-105.73 tagged_above=-999 required=5 tests=[AWL=-0.481, BAYES_00=-2.599, GB_AFFORDABLE=1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 ZxDYLGCjRrBc for ; Tue, 25 Sep 2012 00:45:34 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 02CE521F8880 for ; Tue, 25 Sep 2012 00:45:33 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-e0-5061611ca752 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0C.D1.11467.C1161605; Tue, 25 Sep 2012 09:45:32 +0200 (CEST) Received: from [131.160.36.30] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.1; Tue, 25 Sep 2012 09:45:32 +0200 Message-ID: <5061611B.6080606@ericsson.com> Date: Tue, 25 Sep 2012 10:45:31 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Timothy B. Terriberry" References: <5060C8F4.8050200@xiph.org> In-Reply-To: <5060C8F4.8050200@xiph.org> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUyM+Jvra5MYmKAwdwdlhbX5jSyWZxecpTJ 4krvA0YHZo8lS34yecza+YTF49/ZfrYA5igum5TUnMyy1CJ9uwSujH3vDrMVvMmrOL9Sp4Fx UlQXIyeHhICJxIH5T5khbDGJC/fWs3UxcnEICZxilJg3aQcrhLOaUWJ/w382kCpeAW2Jk+3v mEBsFgFVie93W1hAbDYBC4ktt+6D2aICwRLnNm6DqheUODnzCVhcREBf4vXqr2A2s0CUxK1N nWC2sICNxKRbn8HqhQTUJZZ8+QJkc3BwCmhITF+gBXGcpMSbyTehWjUlWrf/Zoew5SW2v53D DNGqLbH8WQvLBEahWUg2z0LSMgtJywJG5lWMwrmJmTnp5YZ6qUWZycXF+Xl6xambGIFBfXDL b90djKfOiRxilOZgURLn5Ura7y8kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsabq3l/9OVfM 2X9p9EjVvSyedPtmqvrHe+Udh647ztXJNz9V+iby5QTF5IWJrYtLzaeu1Ok7+pqx8+Lu+IWt m9I4TviK3t0SveWR5lrfiCunj2pzWCpMuJ4z84XO92fbzLXLtCy9zaY/DmbeLP1644aP3OEl 6/JPWU78XNh3Xqb1QGcHf/Tkv0osxRmJhlrMRcWJADbes1Q4AgAA Cc: "video-codec@ietf.org" , Robert Sparks Subject: Re: [video-codec] BoF request: video-codec - Internet Video Codec 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, 25 Sep 2012 07:45:39 -0000 Hi, thanks for the request, which was fairly close to the deadline :-) Cheers, Gonzalo On 24/09/2012 11:56 PM, Timothy B. Terriberry wrote: > The proposers would like to request a 2-hour slot for a BoF at IETF 85 > in Atlanta on the subject of standardizing a video codec. > > Description > ----------- > > There are efforts underway by several groups to produce a > next-generation, royalty-free (RF) video codec, including VPnext by > Google [1,2] and Daala by Mozilla/Xiph.Org [3]. While far from complete, > we hope that these can become the backbone of a truly universally > deployable, interactive video codec standard that is competitive with > royalty-bearing offerings. These projects are just the start. Recent > efforts within the MPEG LA to create an RF license for the Restricted > Baseline profile of H.264, while ultimately unsuccessful, showed that > there are many consumer device manufacturers that would support RF > licensing for a video codec. Not all will participate in development, > but even providing review, as some have agreed to do, is useful. In the > CODEC WG, it was the input and feature requests from a wide range of > IETF participants that led to a codec that excelled at an extremely > broad range of applications. This kind of review is much easier for > codecs, where there are easily-understood, measurable objectives > ("everyone has two eyes"). The IETF is typically used to dealing with > much thornier questions, such as, "Will this interoperate with legacy, > possibly-broken implementations?" or "Is this protocol sufficiently > extensible?" > > The success of Opus from the CODEC WG has also shown that collaboration, > based on the IETF's principals of open participation, can produce better > results than competition between patented technologies. The IPR rules in > BCP 78 and 79 are also critical for success. They impose a duty to > disclose, and require exact patent or patent application numbers, in > addition to basic licensing terms. This allows participants to evaluate > the risk of infringement and, if appropriate, design work arounds, in > any technology adopted, and assess the cost of adopting such technology. > Because it does not force participants to agree to license their patents > under RF terms, it helps to encourage participation even by those > opposed to such terms (instead of guaranteeing they stay away). In > addition to an environment which encourages third-party disclosures, > this provides much better chances of success than SDOs which have a > "patent-blind" process [4] or which require blanket RF grants. > > [1] http://downloads.webmproject.org/ngov2012/pdf/04-ngov-project-update.pdf > [2] http://downloads.webmproject.org/ngov2012/wilkins/vpnext-results.html > [3] http://xiph.org/daala/ > [4] http://lists.xiph.org/pipermail/theora/2010-April/003769.html > > Details > ------- > > The proposed working group name is videoc-codec. > > Conflicts to avoid: APPSAWG, AVTCORE, CLUE, CODEC, IRI, MMUSIC, PRECIS, > RMCAT, RTCWEB, XMPP > > Expected attendance: 80 persons > > Does it require WebEX?: No > Does it require Meetecho?: Yes > > BOF agenda > ---------- > > Chair(s): Peter Saint-Andre (plus a possible TBD co-chair) > > Area: RAI > > Area directors: Gonzalo Camarillo and Robert J. Sparks > > Draft agenda (subject to modifications): > - Note Well, logistics, agenda bash (Chairs, 5 min) > - Introduction and scoping of BoF (AD, 10 min) > - Goals (Chairs, 10 min) > - Engineering progress to date (Google, Mozilla 20 min) > - Is it reasonable to do this work at the IETF? (All, 45 min) > - Charter discussion (All, 25 min) > - Conclusions and next steps (Chairs/AD, 5 min) > > Total timeslot: 2 hours > > WG charter (proposed) > --------------------- > Internet Video Codec (video-codec) > > Status: Proposed Working Group > Last Updated: 2012-09-24 > > Chair(s): TBD > > RAI Area Director(s): > Robert J. Sparks (rjsparks@nostrum.com) > Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com) > > RAI Area Advisor: > Robert J. Sparks (rjsparks@nostrum.com) > > Mailing Lists: video-codec@ietf.org > > Description of Working Group > ---------------------------- > > 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 > 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 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. > > 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 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 if they find 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 rjsparks@nostrum.com Wed Sep 26 10:31:33 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 EC10E21F859B for ; Wed, 26 Sep 2012 10:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.863 X-Spam-Level: X-Spam-Status: No, score=-102.863 tagged_above=-999 required=5 tests=[AWL=0.737, BAYES_00=-2.599, GB_AFFORDABLE=1, GB_I_LETTER=-2, SPF_PASS=-0.001, 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 3CYMjSBTgXzy for ; Wed, 26 Sep 2012 10:31:29 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9F51D21F85A0 for ; Wed, 26 Sep 2012 10:31:28 -0700 (PDT) Received: from unnumerable.local ([4.30.77.1]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q8QHVLw8020329 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 26 Sep 2012 12:31:22 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <50633BE9.6020102@nostrum.com> Date: Wed, 26 Sep 2012 12:31:21 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Timothy B. Terriberry" References: <5060C8F4.8050200@xiph.org> In-Reply-To: <5060C8F4.8050200@xiph.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Cc: video-codec@ietf.org, Gonzalo Camarillo Subject: Re: [video-codec] BoF request: video-codec - Internet Video Codec 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, 26 Sep 2012 17:31:34 -0000 This BoF is approved. Due to tool issues, the acronym will need to be different - for now, I've asked the secretariat to use vidcodec (no hyphen, <9 letters). I will work with them to see if we can use videocodec instead. Please continue to refine the description and proposed charter on list. RjS On 9/24/12 3:56 PM, Timothy B. Terriberry wrote: > The proposers would like to request a 2-hour slot for a BoF at IETF 85 > in Atlanta on the subject of standardizing a video codec. > > Description > ----------- > > There are efforts underway by several groups to produce a > next-generation, royalty-free (RF) video codec, including VPnext by > Google [1,2] and Daala by Mozilla/Xiph.Org [3]. While far from > complete, we hope that these can become the backbone of a truly > universally deployable, interactive video codec standard that is > competitive with royalty-bearing offerings. These projects are just > the start. Recent efforts within the MPEG LA to create an RF license > for the Restricted Baseline profile of H.264, while ultimately > unsuccessful, showed that there are many consumer device manufacturers > that would support RF licensing for a video codec. Not all will > participate in development, but even providing review, as some have > agreed to do, is useful. In the CODEC WG, it was the input and feature > requests from a wide range of IETF participants that led to a codec > that excelled at an extremely broad range of applications. This kind > of review is much easier for codecs, where there are > easily-understood, measurable objectives ("everyone has two eyes"). > The IETF is typically used to dealing with much thornier questions, > such as, "Will this interoperate with legacy, possibly-broken > implementations?" or "Is this protocol sufficiently extensible?" > > The success of Opus from the CODEC WG has also shown that > collaboration, based on the IETF's principals of open participation, > can produce better results than competition between patented > technologies. The IPR rules in BCP 78 and 79 are also critical for > success. They impose a duty to disclose, and require exact patent or > patent application numbers, in addition to basic licensing terms. This > allows participants to evaluate the risk of infringement and, if > appropriate, design work arounds, in any technology adopted, and > assess the cost of adopting such technology. Because it does not force > participants to agree to license their patents under RF terms, it > helps to encourage participation even by those opposed to such terms > (instead of guaranteeing they stay away). In addition to an > environment which encourages third-party disclosures, this provides > much better chances of success than SDOs which have a "patent-blind" > process [4] or which require blanket RF grants. > > [1] > http://downloads.webmproject.org/ngov2012/pdf/04-ngov-project-update.pdf > [2] http://downloads.webmproject.org/ngov2012/wilkins/vpnext-results.html > [3] http://xiph.org/daala/ > [4] http://lists.xiph.org/pipermail/theora/2010-April/003769.html > > Details > ------- > > The proposed working group name is videoc-codec. > > Conflicts to avoid: APPSAWG, AVTCORE, CLUE, CODEC, IRI, MMUSIC, > PRECIS, RMCAT, RTCWEB, XMPP > > Expected attendance: 80 persons > > Does it require WebEX?: No > Does it require Meetecho?: Yes > > BOF agenda > ---------- > > Chair(s): Peter Saint-Andre (plus a possible TBD co-chair) > > Area: RAI > > Area directors: Gonzalo Camarillo and Robert J. Sparks > > Draft agenda (subject to modifications): > - Note Well, logistics, agenda bash (Chairs, 5 min) > - Introduction and scoping of BoF (AD, 10 min) > - Goals (Chairs, 10 min) > - Engineering progress to date (Google, Mozilla 20 min) > - Is it reasonable to do this work at the IETF? (All, 45 min) > - Charter discussion (All, 25 min) > - Conclusions and next steps (Chairs/AD, 5 min) > > Total timeslot: 2 hours > > WG charter (proposed) > --------------------- > Internet Video Codec (video-codec) > > Status: Proposed Working Group > Last Updated: 2012-09-24 > > Chair(s): TBD > > RAI Area Director(s): > Robert J. Sparks (rjsparks@nostrum.com) > Gonzalo Camarillo (Gonzalo.Camarillo@ericsson.com) > > RAI Area Advisor: > Robert J. Sparks (rjsparks@nostrum.com) > > Mailing Lists: video-codec@ietf.org > > Description of Working Group > ---------------------------- > > 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 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 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. > > 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 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 if they find 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