From tterribe@xiph.org Tue Dec 4 15:29:00 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 A612521F8AF8 for ; Tue, 4 Dec 2012 15:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q373L3bXVneY for ; Tue, 4 Dec 2012 15:29:00 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id AD10921F8AD2 for ; Tue, 4 Dec 2012 15:28:55 -0800 (PST) Received: from [10.250.6.54] (unknown [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id D9777F210B for ; Tue, 4 Dec 2012 15:28:54 -0800 (PST) Message-ID: <50BE8736.8090801@xiph.org> Date: Tue, 04 Dec 2012 15:28:54 -0800 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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [video-codec] Comments on draft-maxwell-videocodec-requirements-00 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 Dec 2012 23:29:01 -0000 John Koleszar wrote: > can pipeline the encode with the camera. Even if you only get a whole > frame at the encoder, it could be valuable to be able to ship the data > as soon as you can fill an RTP packet, rather than waiting until the > whole frame is encoded. There are also pipelining considerations where Also a format capable of subframe latency encoding generally has good cache coherency. I'm not sure how much software engineering effort I would want to expend into proving this out, though, as long as we ensure the format doesn't compromise this unnecessarily. >> Section 4, fifth paragraph, bullet 2: >> >> This is great for storage but, I'm not convinced this is helpful for >> networks. For network operations, lower average bitrates with higher >> unpredictability may be worse than higher average bitrates with greater >> predictability. > > This is more of an issue for VOD applications rather than > teleconferencing. The rate variance you can accept is governed by how > much you can prebuffer. Taking advantage of this where possible can > get you substantial quality gains vs constant bitrate, for the same > average bitrate. An important point about quality: people will often judge quality of a segment by that of the _worst_ frame. So, while I understand that keeping a consistent flow bandwidth helps when competing in a link bottleneck somewhere, the value of the extra bits (the ones used to boost the quality of the other frames above that of the worst one) is actually fairly low, in terms of its effect on perception. This is something I hope rmcat will explore in more detail, though I recognize it's hard to evaluate. One idea that occurs to me is actually using VBR video and padding it with FEC data to get something closer to CBR. That might actually be a better use of the bits. From abegen@cisco.com Tue Dec 4 15:34:07 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 4955621F8BB4 for ; Tue, 4 Dec 2012 15:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] 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 S8PI-Dvuc603 for ; Tue, 4 Dec 2012 15:34:06 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA3521F8BB2 for ; Tue, 4 Dec 2012 15:34:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=766; q=dns/txt; s=iport; t=1354664046; x=1355873646; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=g4Q/E4TC0mUkerie2FjpYJRPIYh7hA3L5dAgJyFnwiY=; b=mly8uKivcKaOLudLu7NR9AocMzXYWPOv2cJUZPQlpN9Kgamf6Z3eDH4a xVpnbWYr12dFg6fi0qpMff9BJZYnLxG+/iLEIkK0bNoJ0XaOyRCe8a1Xz lTziprsPmVoz21qrWgi9C/Jq9hBwpC6I8pAVtSSZiWaKeotNt9d21Q8RJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFAMiHvlCtJXG8/2dsb2JhbABEgmyDAbhHFnOCHgEBAQQ6SwYBCBEDAQILFEIdCAIEARIIiAgBsC2QVYw3g2BhA6ZKgnKCIQ X-IronPort-AV: E=McAfee;i="5400,1158,6916"; a="149414437" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 04 Dec 2012 23:34:06 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qB4NY6MM008283 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Dec 2012 23:34:06 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Tue, 4 Dec 2012 17:34:06 -0600 From: "Ali C. Begen (abegen)" To: "Timothy B. Terriberry" , "video-codec@ietf.org" Thread-Topic: [video-codec] Comments on draft-maxwell-videocodec-requirements-00 Thread-Index: AQHN0nfZqszjoQZ1ZEamDb7v8XUYmw== Date: Tue, 4 Dec 2012 23:34:06 +0000 Message-ID: In-Reply-To: <50BE8736.8090801@xiph.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.247.1] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [video-codec] Comments on draft-maxwell-videocodec-requirements-00 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 Dec 2012 23:34:07 -0000 -----Original Message----- From: "Timothy B. Terriberry" Date: Tuesday, December 4, 2012 6:28 PM To: "video-codec@ietf.org" Subject: Re: [video-codec] Comments on draft-maxwell-videocodec-requirements-00 >This is something I hope rmcat will explore in more detail, though I >recognize it's hard to evaluate. One idea that occurs to me is actually >using VBR video and padding it with FEC data to get something closer to >CBR. That might actually be a better use of the bits. I doubt it. If a frame (or slide) has less bits due to VBR encoding, that means it is easier to encode it, which implies it is less important than the one that has more bits. FEC'ing these frames will not make the stream CBR. From tterribe@xiph.org Tue Dec 4 15:40:51 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 9FF5621F8BC4 for ; Tue, 4 Dec 2012 15:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXN9YYZMajvS for ; Tue, 4 Dec 2012 15:40:47 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id D4DEF21F8AD3 for ; Tue, 4 Dec 2012 15:40:47 -0800 (PST) Received: from [10.250.6.54] (unknown [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id D02B4F210B for ; Tue, 4 Dec 2012 15:40:46 -0800 (PST) Message-ID: <50BE89FE.1080207@xiph.org> Date: Tue, 04 Dec 2012 15:40:46 -0800 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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [video-codec] Comments on draft-maxwell-videocodec-requirements-00 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 Dec 2012 23:40:51 -0000 Kevin Gross wrote: > There are 8 applications listed in section 3. VOD is the only one that > clearly benefits here. How much emphasis do we want to put on that > application? I've seen estimates that at peak hours this constitutes 50% of the Internet bandwidth usage of the United States [1]. That might be worth emphasizing. > Why? The motivation for bandwidth efficiency is never convincingly > substantiated in the draft. I'm aware that bandwidth efficiency is a > very respected metric among codec developers. I'm questioning how > important it actually is for applications and users given that available > network bandwidth is increasing much faster than required media > bandwidth and the efficiency increases we expect to be able > to achieve with a new codec are comparatively modest. The users seem to think it is pretty darn important. See, for example, Chris DiBona's claims that switching to Theora would break the internet [2] (rebutted [3], for the record, but the quality bar has moved beyond where it was in 2009, and will have moved farther before we're done). I'll cite our experience with Opus as another example: it always had excellent latency and scalability, but people did not start to get really excited about it until the quality started to exceed that of the best high-latency codecs (this is not quite true: I gave a presentation on CELT, one of the predecessors of Opus, at LCA 2009, and after explaining that bitrate efficiency was explicitly a non-goal, had a number of excited people come up to me and ask, "How long until this compresses better than Vorbis?"). If you want people to use your codec, this matters. We've tried twice now to get people to use codecs that were substantially less complex than their competitors but which did not resoundingly beat them in bitrate efficiency (to put it generously). It hasn't worked. I'll also point out that HEVC's target was 50% less bitrate than H.264 High Profile at > HD resolutions. I don't have numbers on how close they got off-hand, but I think most users would agree that that is not a modest number. If we don't at least match this performance, I'm not going to say we've failed, but we should _certainly_ be doing better than the RF options we already have. [1] http://www.sandvine.com/news/pr_detail.asp?ID=312 [2] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020380.html [3] http://people.xiph.org/~greg/video/ytcompare/comparison.html From tterribe@xiph.org Tue Dec 4 15:42:03 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 0B38321F8BCD for ; Tue, 4 Dec 2012 15:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_33=0.6, 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 4q73hIgvuA7q for ; Tue, 4 Dec 2012 15:42:02 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id A7BC821F8BCA for ; Tue, 4 Dec 2012 15:42:02 -0800 (PST) Received: from [10.250.6.54] (unknown [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 88D8DF210B for ; Tue, 4 Dec 2012 15:42:02 -0800 (PST) Message-ID: <50BE8A4A.4050907@xiph.org> Date: Tue, 04 Dec 2012 15:42:02 -0800 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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [video-codec] Comments on draft-maxwell-videocodec-requirements-00 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 Dec 2012 23:42:03 -0000 Ali C. Begen (abegen) wrote: >> This is something I hope rmcat will explore in more detail, though I >> recognize it's hard to evaluate. One idea that occurs to me is actually >> using VBR video and padding it with FEC data to get something closer to >> CBR. That might actually be a better use of the bits. > > I doubt it. If a frame (or slide) has less bits due to VBR encoding, that > means it is easier to encode it, which implies it is less important than > the one that has more bits. FEC'ing these frames will not make the stream > CBR. Well, the idea would be to put the redundant information from the larger (more important) frames in space you didn't use in the smaller frames, to protect against lost packets in those frames. From abegen@cisco.com Tue Dec 4 15:46:17 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 B29C921F858C for ; Tue, 4 Dec 2012 15:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] 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 zuHkD4mzLags for ; Tue, 4 Dec 2012 15:46:16 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BD5AE21F8521 for ; Tue, 4 Dec 2012 15:46:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1304; q=dns/txt; s=iport; t=1354664776; x=1355874376; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Nd7/C7wnsoYnNFu+4sqaihIB9S0GGOxNbOKTspJvbGc=; b=nJpmSZfC/0z8qXmURcHtbbsx+uJFuRmlcM06cC9ODo7fyOW/Hq9EFXYf g3DzBtbypcUZZkkoqRBUECSkCDhuYYiSkXoxir9ZvPQQMRkxeI1YRmm6i nc8GRJhqw+SQZEP3iFUIZJTb5FRGhvkSBfnFZI6/Qoo/ba6rTnUiSrnTJ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAN2KvlCtJV2b/2dsb2JhbABEgmy7SBZzgh4BAQEEAQEBNzQXBgEIEQMBAgEKFDcLHQgCBAESCIgIAQuwJZBNBIw3g2BhA6ZKgnKCIQ X-IronPort-AV: E=McAfee;i="5400,1158,6916"; a="146420317" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 04 Dec 2012 23:46:15 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qB4NkF9b016987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Dec 2012 23:46:15 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Tue, 4 Dec 2012 17:46:15 -0600 From: "Ali C. Begen (abegen)" To: "Timothy B. Terriberry" , "video-codec@ietf.org" Thread-Topic: [video-codec] Comments on draft-maxwell-videocodec-requirements-00 Thread-Index: AQHN0nmLwAXAtrgS4E6eh0qB3NACUQ== Date: Tue, 4 Dec 2012 23:46:14 +0000 Message-ID: In-Reply-To: <50BE8A4A.4050907@xiph.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.247.1] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [video-codec] Comments on draft-maxwell-videocodec-requirements-00 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 Dec 2012 23:46:17 -0000 -----Original Message----- From: "Timothy B. Terriberry" Date: Tuesday, December 4, 2012 6:42 PM To: "video-codec@ietf.org" Subject: Re: [video-codec] Comments on draft-maxwell-videocodec-requirements-00 >Ali C. Begen (abegen) wrote: >>> This is something I hope rmcat will explore in more detail, though I >>> recognize it's hard to evaluate. One idea that occurs to me is actually >>> using VBR video and padding it with FEC data to get something closer to >>> CBR. That might actually be a better use of the bits. >> >> I doubt it. If a frame (or slide) has less bits due to VBR encoding, >>that >> means it is easier to encode it, which implies it is less important than >> the one that has more bits. FEC'ing these frames will not make the >>stream >> CBR. > >Well, the idea would be to put the redundant information from the larger >(more important) frames in space you didn't use in the smaller frames, >to protect against lost packets in those frames. That is possible but that will introduce potentially long delays (which we don't want in video-codec). -acbegen >_______________________________________________ >video-codec mailing list >video-codec@ietf.org >https://www.ietf.org/mailman/listinfo/video-codec From tterribe@xiph.org Tue Dec 4 15:51:09 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 8D27021F8BCF for ; Tue, 4 Dec 2012 15:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T49fQ3AFz0P7 for ; Tue, 4 Dec 2012 15:51:09 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 06C8021F8BCD for ; Tue, 4 Dec 2012 15:51:09 -0800 (PST) Received: from [10.250.6.54] (unknown [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id BCA46F20E1 for ; Tue, 4 Dec 2012 15:51:08 -0800 (PST) Message-ID: <50BE8C6C.8010200@xiph.org> Date: Tue, 04 Dec 2012 15:51:08 -0800 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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [video-codec] Comments on draft-maxwell-videocodec-requirements-00 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 Dec 2012 23:51:09 -0000 Ali C. Begen (abegen) wrote: >> Well, the idea would be to put the redundant information from the larger >> (more important) frames in space you didn't use in the smaller frames, >> to protect against lost packets in those frames. > > That is possible but that will introduce potentially long delays (which we > don't want in video-codec). I wasn't thinking of going beyond the most recent frame. That restriction would limit your ability to make things truly CBR (or conversely to keep truly consistent quality), but I think it would be a step in the right direction. It might work very well with a hierarchical-P or P/B reference frame structure. From sergio.garcia.murillo@gmail.com Tue Dec 4 16:01: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 206BE21F8A34 for ; Tue, 4 Dec 2012 16:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 HOGC-459DJct for ; Tue, 4 Dec 2012 16:01:53 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5C17921F8A24 for ; Tue, 4 Dec 2012 16:01:53 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so2018913wey.31 for ; Tue, 04 Dec 2012 16:01:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ypO2pp/ckbbYg8uH+OiSC6VELUlSw1JZ72iq7S9o+J8=; b=LPxxdCk7cup/O0crg3FRWd/h51WVdn+NzHqu2kyQWl8QlhWZT8XfSN3ck+q3UHGqTa tojrYtZcysZJrVPVHKNDIDqGpGorAIKopOUYU937AOJL6CtKugB1aa3CvyGNlGfatksq UFvTl7FwPOvbn7XqIqVpRP3NAAXkmJGp7vgWH6LOCcyvLfiwamCfyaHGrx5n11BB2Y6E GkvvFXxfA0bae9FJTtI2MwBWc/JWxdS3yNymSmMnFeeb/CxpYNxVAgKJKzVeXNmx7M8x ESicYOMXMjdhPueFyvI4+YtnG4thmSFnTBPw4kPdDWvijVHlVVrQJ/3qQmXkOOyI80ar hQPg== Received: by 10.216.216.27 with SMTP id f27mr220182wep.22.1354665705876; Tue, 04 Dec 2012 16:01:45 -0800 (PST) Received: from [192.168.1.10] (145.pool85-48-32.dynamic.orange.es. [85.48.32.145]) by mx.google.com with ESMTPS id fv2sm17046659wib.4.2012.12.04.16.01.44 (version=SSLv3 cipher=OTHER); Tue, 04 Dec 2012 16:01:45 -0800 (PST) Message-ID: <50BE8EE7.5050404@gmail.com> Date: Wed, 05 Dec 2012 01:01:43 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: video-codec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [video-codec] Comments on draft-maxwell-videocodec-requirements-00 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, 05 Dec 2012 00:01:54 -0000 El 05/12/2012 0:46, Ali C. Begen (abegen) escribió: > > -----Original Message----- > From: "Timothy B. Terriberry" > Date: Tuesday, December 4, 2012 6:42 PM > To: "video-codec@ietf.org" > Subject: Re: [video-codec] Comments > on draft-maxwell-videocodec-requirements-00 > >> Ali C. Begen (abegen) wrote: >>>> This is something I hope rmcat will explore in more detail, though I >>>> recognize it's hard to evaluate. One idea that occurs to me is actually >>>> using VBR video and padding it with FEC data to get something closer to >>>> CBR. That might actually be a better use of the bits. >>> I doubt it. If a frame (or slide) has less bits due to VBR encoding, >>> that >>> means it is easier to encode it, which implies it is less important than >>> the one that has more bits. FEC'ing these frames will not make the >>> stream >>> CBR. >> Well, the idea would be to put the redundant information from the larger >> (more important) frames in space you didn't use in the smaller frames, >> to protect against lost packets in those frames. > That is possible but that will introduce potentially long delays (which we > don't want in video-codec). > Redundant information is important for congestion control algorithms. For example the google draft: http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-03 Expects a packet lost rate >10% before reducing the video rate. Providing this redundancy in the codec instead of using FEC could have some benefits. Also, I think that for videoconferencing, what is most important is not CBR vs VBR but to be able to limit the maximum size of an encoded frame (i.e. something like constrained VBR). Best regards Sergio From gmaxwell@juniper.net Tue Dec 4 16:20: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 0792521F8BCC for ; Tue, 4 Dec 2012 16:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] 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 uAvzlDaiAFfp for ; Tue, 4 Dec 2012 16:20:53 -0800 (PST) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 089B921F8B99 for ; Tue, 4 Dec 2012 16:20:52 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUL6TZFKl5JnZo8jUX7DofCcmL0WZugXB@postini.com; Tue, 04 Dec 2012 16:20:53 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 4 Dec 2012 16:11:33 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Tue, 4 Dec 2012 16:11:33 -0800 Received: from db3outboundpool.messaging.microsoft.com (213.199.154.141) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 4 Dec 2012 16:14:03 -0800 Received: from mail120-db3-R.bigfish.com (10.3.81.237) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 5 Dec 2012 00:11:31 +0000 Received: from mail120-db3 (localhost [127.0.0.1]) by mail120-db3-R.bigfish.com (Postfix) with ESMTP id 2746F2403B7 for ; Wed, 5 Dec 2012 00:11:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.197; KIP:(null); UIP:(null); (null); H:CH1PRD0511HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -4 X-BigFish: PS-4(zz98dIzz1de0h1202h1d1ah1d2ahzz17326ah5eeeKz2dh2a8h668h839h946hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1155h) Received: from mail120-db3 (localhost.localdomain [127.0.0.1]) by mail120-db3 (MessageSwitch) id 1354666289950811_20536; Wed, 5 Dec 2012 00:11:29 +0000 (UTC) Received: from DB3EHSMHS007.bigfish.com (unknown [10.3.81.241]) by mail120-db3.bigfish.com (Postfix) with ESMTP id E5172120065; Wed, 5 Dec 2012 00:11:29 +0000 (UTC) Received: from CH1PRD0511HT004.namprd05.prod.outlook.com (157.56.245.197) by DB3EHSMHS007.bigfish.com (10.3.87.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 5 Dec 2012 00:11:29 +0000 Received: from CH1PRD0511MB432.namprd05.prod.outlook.com ([169.254.4.119]) by CH1PRD0511HT004.namprd05.prod.outlook.com ([10.255.159.39]) with mapi id 14.16.0245.002; Wed, 5 Dec 2012 00:11:04 +0000 From: Gregory Maxwell To: Kevin Gross , John Koleszar Thread-Topic: Resource scaling Was: Comments on draft-maxwell-videocodec-requirements-00 Thread-Index: AQHN0np+1SI2FgGK5UiofxkRREJdHA== Date: Wed, 5 Dec 2012 00:11:03 +0000 Message-ID: <9B8EA46C78239244B5F7A07E163D3DFE05F96B8C@CH1PRD0511MB432.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [96.241.176.56] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%AVANW.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "video-codec@ietf.org" Subject: [video-codec] Resource scaling Was: Comments on draft-maxwell-videocodec-requirements-00 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, 05 Dec 2012 00:20:54 -0000 Kevin Gross [kevin.gross@avanw.com] wrote:=0A= > Why? The motivation for bandwidth efficiency is never convincingly=0A= > substantiated in the draft. I'm aware that bandwidth efficiency is a very= =0A= > respected metric among codec developers. I'm questioning how important=0A= > it actually is for applications and users given that available network ba= ndwidth=0A= > is increasing much faster than required media bandwidth and the efficienc= y=0A= > increases we expect to be able to achieve with a new codec are comparativ= ely modest.=0A= =0A= For high quality material resolutions and frame rates are growing=97 we're = still a ways from being able to saturate human perception. But I can buy th= at networks are growing faster. But I don't know that demands of video its= elf are the best comparison point there: We also want to do other things wi= th that network bandwidth like service more concurrent users, or run other = protocols, or extend it out to more remote regions. Some people want to bro= adcast every one of their meals (though I don't know why) and attach remote= cameras to their dogs. So it's quite conceivable that demand for compressi= on performance is going up even absent _any_ increase in video resolution.= =0A= =0A= So when talking about compression efficiency I think it's more useful to ta= lk about how computation and coding science scales and compare that to how = networks and storage scales. We have a set of resources that can be applie= d and traded off to optimize how we handle video. Which of these things are= more costly on average across all usage? =0A= =0A= During the BOF I made a remark along the lines that the available bandwidth= at the edge of the network appears to be subject to a slower scaling law t= han what we see for low cost transistor density (Moore's law), or magnetic = storage density (Kryder's Law). =0A= =0A= I didn't think it a very controversial supposition, as it's hard for the co= nverse to be true on a sustained basis (switches ultimately become constrai= ned by memory bandwidth)=97 but it's not one that I made without seeing som= e data on it in the past, e.g.=0A= =0A= http://download.broadband.gov/plan/fcc-omnibus-broadband-initiative-%28obi%= 29-technical-paper-broadband-performance.pdf Page 4.=0A= =0A= "Since 1997, consumer-purchased broadband connection speeds have doubled ro= ughly every four years, with advertised fixed broadband download speeds gro= wing at a 20% annual rate"=0A= =0A= What I thought I'd seen before, but can't seem to find now is information o= n the _distribution_ of available speeds=97 as I think the highest access s= peeds tend to grow faster than the lower ones, which is an interesting fact= or for services which need to accommodate many potential users.=0A= =0A= There are a number of other=97 mostly market related=97 arguments that can = be made about the importance of compression efficiency, but I thought it wo= uld be productive to break this one out and see if I'm completely confused = on this point.=0A= From tterribe@xiph.org Tue Dec 4 16:23:30 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 BAD5D21F8BB0 for ; Tue, 4 Dec 2012 16:23:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMrQcoDMr89f for ; Tue, 4 Dec 2012 16:23:30 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9932E21F841F for ; Tue, 4 Dec 2012 16:23:30 -0800 (PST) Received: from [10.250.6.54] (unknown [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 70335F20E1 for ; Tue, 4 Dec 2012 16:23:30 -0800 (PST) Message-ID: <50BE9402.4030103@xiph.org> Date: Tue, 04 Dec 2012 16:23:30 -0800 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: <9B8EA46C78239244B5F7A07E163D3DFE049149@CH1PRD0511MB432.namprd05.prod.outlook.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [video-codec] draft-maxwell-videocodec-requirements 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, 05 Dec 2012 00:23:30 -0000 Jozsef Vass wrote: > 4. What about some kind of scalable scheme? It maybe advantageous in a > conference scenario. Your other comments are good, but I think scalability is mostly a waste of time. The full resolution case winds up being somewhat less bitrate-efficient, and this is the part that contains most of the bits. This is enough that simulcast actually competes fairly well, is much, much simpler, and avoids a host of IPR issues. From tterribe@xiph.org Tue Dec 4 17:10: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 CFF1D21F8BED for ; Tue, 4 Dec 2012 17:10:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+0dlw1sw9Xd for ; Tue, 4 Dec 2012 17:10:39 -0800 (PST) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id C9C6621F8BEA for ; Tue, 4 Dec 2012 17:10:39 -0800 (PST) Received: from [10.250.6.54] (unknown [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id B83CCF211F for ; Tue, 4 Dec 2012 17:10:38 -0800 (PST) Message-ID: <50BE9F0E.7070304@xiph.org> Date: Tue, 04 Dec 2012 17:10:38 -0800 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: <20121106112625.2btpoxrylcgg8w4c@kizuka.merseine.nu> <509AC2B4.3010406@wonderhamster.org> <20121107153423.d93rypvha8w480wc@kizuka.merseine.nu> <50AAC17E.5000208@wonderhamster.org> In-Reply-To: <50AAC17E.5000208@wonderhamster.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [video-codec] Charter issues from BoF 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, 05 Dec 2012 01:10:41 -0000 Spencer Dawkins wrote: > I'm not seeing a problem yet for this proposed working group, but I am > remembering that "the Internet" covers a LOT of different points in the > "speed/delay/reliability" space, from interconnected data centers to > environments that are slightly better-connected than DTNRG networks :-) > ... it would be great to be clear on what environments are being targeted. This is good advice. My primary interest is public, consumer-level, best-effort networks (i.e., where people run browsers). I can try to add some language to the charter to that effect if no one objects to that being the focus. > program. I'd love for a chartered videocodec working group to have a > good plan for liaison relationships, and I say that without reference to > any other IETF working group having, or not having, a good plan for > liaison relationships :-) I've been approached by a couple of people from the MPEG IVC effort who think that we can do better than liaison-style collaboration, but I'm not sure what the best approach is here, yet. I will try to encourage them to post their thoughts on the list. > I'd suggest the proposed working group community discuss whether it's > worth producing a video codec that is known to not be RF, early in the > process. There is some difficulty in deciding what "known to not be RF" means. Some people would take the existence of an IPR disclosure---any IPR disclosure---that does not make that IPR available under RF terms to be an indication that the work is not RF... and in the case that the disclosure is by the author of the technique in question, this is very compelling. Other people are willing to investigate the real risk associated with those disclosures, evaluate the effectiveness of design-arounds (which do not incur an obligation to update that disclosure), etc. Experience with Opus suggests to me that this should be handled by WG consensus on a case-by-case basis, instead of with an iron-clad rule in the charter. This was discussed a fair bit at the bar BoF in Vancouver, and the "developed under the IPR rules of the IETF" language that's currently in the charter was strongly suggested to me as the best way to phrase this. Speaking personally, I would not support publishing as an RFC any codec that I did not believe was RF. > I'm not saying that I have an opinion about "one codec or many", I'm > saying it would be helpful to understand whether one codec could meet > the need for a codec that's "optimized for the Internet", before > deciding whether to produce more than one codec. I think it can. The biggest challenge comes in deciding whether or not to support coding tools that are not robust in the face of packet loss. This includes, for example, anything which makes decisions about what values to read from the bitstream based on the decoded, reconstructed pixels. In the presence of loss, making one of those decisions incorrectly would corrupt the rest of the frame. To illustrate this, one of the items mentioned in the VP9 presentation included scoring candidate motion vectors by matching the (already-decoded) edge pixels from neighboring blocks to the reference frame at the same offset. I believe this is okay in its current form, because the codebook used to decode the motion vector residual has no dependency on the value of the MV being used as a predictor. But if we wanted to use a scheme that _did_ depend on that value, we'd have to give up the ability to look at those pixels in neighboring blocks. I've had in mind for a while now a coding scheme which allows you to code a MV relative to two different predictors, but unlike the normal approach of "code which predictor is closer, and then code an offset relative to that predictor," doesn't introduce any redundancy in the coding. This depends on exactly what those two predictors are (consider the case where they're the same, for example), so it wouldn't be compatible with this VP9 technique for deriving the list of predictors. But even in this case, we could pick which of the two approaches works better on average, or even allow both techniques to be used, and switch between them. Video frames have enough bits to make this kind of switching at the frame or even smaller levels quite practical, and you could pick up quite a lot of alternate algorithms like this before it made sense to give up all the things that _are_ common in the two use cases and have two completely separate codecs. > If I'm understanding what other people are saying, I'm not hearing "need > old technology where patents have expired" as a strategy for video > codecs, but It might be helpful for the proposed working group community > to be clear on how much new technology people are planning to define, > early on. I think we should be doing both things. If you look carefully at some of the drafts that have already been submitted, you'll see some of the references are _very_ old. There's a lot of research out there that's been around for a long time, but never made it into a widely deployed codec. Sometimes that's for very good reasons. Sometimes it's because design decisions which were important at the time have become less so as Moore's law has changed the best operating point on the chip area/clock speed/power usage frontier. Sometimes it's because the technique introduced practical problems which are solvable, but no one ever attempted to solve them. We (Mozilla) are also exploring ways we can actually publish solid information about why we think the the codec will be royalty-free (once it is finished). As you may know, it is normally not in our interest to do so (it is basically mapping out your defense, or at least part of it, to any potential litigants), but it may wind up being worth the trade-off. > I hope this is helpful. And again, I think the important thing is that > the proposed working group community take Cullen's suggestions > seriously, more than what the community decides about them. I think this (and Cullen's feedback generally) has been very helpful. I hope to submit an updated version of the charter incorporating a bunch of the feedback received thus far before next week. From yasser_syed@cable.comcast.com Tue Dec 4 17:18:31 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 A201321F8AF9 for ; Tue, 4 Dec 2012 17:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.231 X-Spam-Level: X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, 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 qCE6Y7NT7801 for ; Tue, 4 Dec 2012 17:18:30 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 7AED021F8AF4 for ; Tue, 4 Dec 2012 17:18:28 -0800 (PST) Received: from ([147.191.109.18]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.44730735; Tue, 04 Dec 2012 17:52:22 -0700 Received: from COPDCEXMB10.cable.comcast.com ([169.254.2.129]) by copdcexhub02.cable.comcast.com ([fe80::606c:7186:baeb:9c46%12]) with mapi id 14.02.0318.001; Tue, 4 Dec 2012 18:18:23 -0700 From: "Syed, Yasser" To: "video-codec@ietf.org" Thread-Topic: [video-codec] Charter issues from BoF Thread-Index: AQHNxq4lUCmcc6zM7km/KJown6uwzZgJ8qgA//+M0AA= Date: Wed, 5 Dec 2012 01:18:22 +0000 Message-ID: <45504FA1E904A6489B34A4F5D1291D756A0BECA9@COPDCEXMB10.cable.comcast.com> In-Reply-To: <50BE9F0E.7070304@xiph.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [24.40.55.70] Content-Type: text/plain; charset="us-ascii" Content-ID: <6AD4DD5F79E4F64F9DA348F1910A6DE3@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [video-codec] Charter issues from BoF 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, 05 Dec 2012 01:18:31 -0000 Was anyone involved in some of the AVS discussions in the past? It wasn't RF, but I believe there was some tradeoff discussions in terms of what IPR made it in or out and how it affected end video quality. It seems like a similar effort in the past that did result in an output document. Yasser On 12/4/12 6:10 PM, "Timothy B. Terriberry" wrote: >Spencer Dawkins wrote: >> I'm not seeing a problem yet for this proposed working group, but I am >> remembering that "the Internet" covers a LOT of different points in the >> "speed/delay/reliability" space, from interconnected data centers to >> environments that are slightly better-connected than DTNRG networks :-) >> ... it would be great to be clear on what environments are being >>targeted. > >This is good advice. My primary interest is public, consumer-level, >best-effort networks (i.e., where people run browsers). I can try to add >some language to the charter to that effect if no one objects to that >being the focus. > >> program. I'd love for a chartered videocodec working group to have a >> good plan for liaison relationships, and I say that without reference to >> any other IETF working group having, or not having, a good plan for >> liaison relationships :-) > >I've been approached by a couple of people from the MPEG IVC effort who >think that we can do better than liaison-style collaboration, but I'm >not sure what the best approach is here, yet. I will try to encourage >them to post their thoughts on the list. > >> I'd suggest the proposed working group community discuss whether it's >> worth producing a video codec that is known to not be RF, early in the >> process. > >There is some difficulty in deciding what "known to not be RF" means. >Some people would take the existence of an IPR disclosure---any IPR >disclosure---that does not make that IPR available under RF terms to be >an indication that the work is not RF... and in the case that the >disclosure is by the author of the technique in question, this is very >compelling. Other people are willing to investigate the real risk >associated with those disclosures, evaluate the effectiveness of >design-arounds (which do not incur an obligation to update that >disclosure), etc. > >Experience with Opus suggests to me that this should be handled by WG >consensus on a case-by-case basis, instead of with an iron-clad rule in >the charter. This was discussed a fair bit at the bar BoF in Vancouver, >and the "developed under the IPR rules of the IETF" language that's >currently in the charter was strongly suggested to me as the best way to >phrase this. > >Speaking personally, I would not support publishing as an RFC any codec >that I did not believe was RF. > >> I'm not saying that I have an opinion about "one codec or many", I'm >> saying it would be helpful to understand whether one codec could meet >> the need for a codec that's "optimized for the Internet", before >> deciding whether to produce more than one codec. > >I think it can. The biggest challenge comes in deciding whether or not >to support coding tools that are not robust in the face of packet loss. >This includes, for example, anything which makes decisions about what >values to read from the bitstream based on the decoded, reconstructed >pixels. In the presence of loss, making one of those decisions >incorrectly would corrupt the rest of the frame. > >To illustrate this, one of the items mentioned in the VP9 presentation >included scoring candidate motion vectors by matching the >(already-decoded) edge pixels from neighboring blocks to the reference >frame at the same offset. I believe this is okay in its current form, >because the codebook used to decode the motion vector residual has no >dependency on the value of the MV being used as a predictor. But if we >wanted to use a scheme that _did_ depend on that value, we'd have to >give up the ability to look at those pixels in neighboring blocks. I've >had in mind for a while now a coding scheme which allows you to code a >MV relative to two different predictors, but unlike the normal approach >of "code which predictor is closer, and then code an offset relative to >that predictor," doesn't introduce any redundancy in the coding. This >depends on exactly what those two predictors are (consider the case >where they're the same, for example), so it wouldn't be compatible with >this VP9 technique for deriving the list of predictors. > >But even in this case, we could pick which of the two approaches works >better on average, or even allow both techniques to be used, and switch >between them. Video frames have enough bits to make this kind of >switching at the frame or even smaller levels quite practical, and you >could pick up quite a lot of alternate algorithms like this before it >made sense to give up all the things that _are_ common in the two use >cases and have two completely separate codecs. > >> If I'm understanding what other people are saying, I'm not hearing "need >> old technology where patents have expired" as a strategy for video >> codecs, but It might be helpful for the proposed working group community >> to be clear on how much new technology people are planning to define, >> early on. > >I think we should be doing both things. If you look carefully at some of >the drafts that have already been submitted, you'll see some of the >references are _very_ old. There's a lot of research out there that's >been around for a long time, but never made it into a widely deployed >codec. Sometimes that's for very good reasons. Sometimes it's because >design decisions which were important at the time have become less so as >Moore's law has changed the best operating point on the chip area/clock >speed/power usage frontier. Sometimes it's because the technique >introduced practical problems which are solvable, but no one ever >attempted to solve them. > >We (Mozilla) are also exploring ways we can actually publish solid >information about why we think the the codec will be royalty-free (once >it is finished). As you may know, it is normally not in our interest to >do so (it is basically mapping out your defense, or at least part of it, >to any potential litigants), but it may wind up being worth the trade-off. > >> I hope this is helpful. And again, I think the important thing is that >> the proposed working group community take Cullen's suggestions >> seriously, more than what the community decides about them. > >I think this (and Cullen's feedback generally) has been very helpful. I >hope to submit an updated version of the charter incorporating a bunch >of the feedback received thus far before next week. >_______________________________________________ >video-codec mailing list >video-codec@ietf.org >https://www.ietf.org/mailman/listinfo/video-codec From kevin.gross@avanw.com Wed Dec 5 03:40:47 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 9276721F8908 for ; Wed, 5 Dec 2012 03:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.976 X-Spam-Level: X-Spam-Status: No, score=-0.976 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_HTML_USL_OBFU=1.666] 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 IIFyJ-GgflBy for ; Wed, 5 Dec 2012 03:40:44 -0800 (PST) Received: from oproxy11-pub.bluehost.com (oproxy11-pub.bluehost.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 9B2B321F8716 for ; Wed, 5 Dec 2012 03:40:43 -0800 (PST) Received: (qmail 20153 invoked by uid 0); 5 Dec 2012 03:51:00 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy11.bluehost.com with SMTP; 5 Dec 2012 03:51:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=2le3JLR2lXIksEw+tT+dXlsqb8ZVIi3RIsT8ID4Vr0c=; b=VnFlAk3M2MWqzLf+090AiW/U+7MqJ09H+Q+a1f5G9YDA6O+aAqrBQ4FTEIlt0tLeGoLB9vR+8ZDQ611wqmHZXyTp/Xo8wA81fJdYtuWzHLSSub2dGPIeM+/DEc2c5YQ7; Received: from [209.85.210.172] (port=45054 helo=mail-ia0-f172.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1Tg60h-00030Q-TD for video-codec@ietf.org; Tue, 04 Dec 2012 20:51:00 -0700 Received: by mail-ia0-f172.google.com with SMTP id z13so3860520iaz.31 for ; Tue, 04 Dec 2012 19:50:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.140.67 with SMTP id re3mr581767igb.16.1354679457917; Tue, 04 Dec 2012 19:50:57 -0800 (PST) Received: by 10.50.151.135 with HTTP; Tue, 4 Dec 2012 19:50:57 -0800 (PST) In-Reply-To: <50BE89FE.1080207@xiph.org> References: <50BE89FE.1080207@xiph.org> Date: Tue, 4 Dec 2012 20:50:57 -0700 Message-ID: From: Kevin Gross To: "Timothy B. Terriberry" Content-Type: multipart/alternative; boundary=e89a8f838b95dfac4004d012e366 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.210.172 authed with kevin.gross@avanw.com} Cc: video-codec@ietf.org Subject: Re: [video-codec] Comments on draft-maxwell-videocodec-requirements-00 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, 05 Dec 2012 11:40:47 -0000 --e89a8f838b95dfac4004d012e366 Content-Type: text/plain; charset=ISO-8859-1 Good stuff. Thanks for including the DiBona rebuttal - good points made there, but, like you say, you have significant experience that indicates the less optimized approach is not successful in the "market". We should not ignore that. We do need to decide how important VOD is. I'm not sure that wasn't ironic understatement in your response. My understanding is that a significant driver for this codec effort is RTCweb and there's not much VOD there. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Tue, Dec 4, 2012 at 4:40 PM, Timothy B. Terriberry wrote: > Kevin Gross wrote: > >> There are 8 applications listed in section 3. VOD is the only one that >> clearly benefits here. How much emphasis do we want to put on that >> application? >> > > I've seen estimates that at peak hours this constitutes 50% of the > Internet bandwidth usage of the United States [1]. That might be worth > emphasizing. > > > Why? The motivation for bandwidth efficiency is never convincingly >> substantiated in the draft. I'm aware that bandwidth efficiency is a >> very respected metric among codec developers. I'm questioning how >> important it actually is for applications and users given that available >> network bandwidth is increasing much faster than required media >> bandwidth and the efficiency increases we expect to be able >> to achieve with a new codec are comparatively modest. >> > > The users seem to think it is pretty darn important. See, for example, > Chris DiBona's claims that switching to Theora would break the internet [2] > (rebutted [3], for the record, but the quality bar has moved beyond where > it was in 2009, and will have moved farther before we're done). > > I'll cite our experience with Opus as another example: it always had > excellent latency and scalability, but people did not start to get really > excited about it until the quality started to exceed that of the best > high-latency codecs (this is not quite true: I gave a presentation on CELT, > one of the predecessors of Opus, at LCA 2009, and after explaining that > bitrate efficiency was explicitly a non-goal, had a number of excited > people come up to me and ask, "How long until this compresses better than > Vorbis?"). If you want people to use your codec, this matters. > > We've tried twice now to get people to use codecs that were substantially > less complex than their competitors but which did not resoundingly beat > them in bitrate efficiency (to put it generously). It hasn't worked. > > I'll also point out that HEVC's target was 50% less bitrate than H.264 > High Profile at > HD resolutions. I don't have numbers on how close they > got off-hand, but I think most users would agree that that is not a modest > number. If we don't at least match this performance, I'm not going to say > we've failed, but we should _certainly_ be doing better than the RF options > we already have. > > [1] http://www.sandvine.com/news/**pr_detail.asp?ID=312 > [2] http://lists.whatwg.org/htdig.**cgi/whatwg-whatwg.org/2009-** > June/020380.html > [3] http://people.xiph.org/~greg/**video/ytcompare/comparison.**html > > ______________________________**_________________ > video-codec mailing list > video-codec@ietf.org > https://www.ietf.org/mailman/**listinfo/video-codec > --e89a8f838b95dfac4004d012e366 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Good stuff. Thanks for including the DiBona rebuttal - good points made the= re, but, like you say, you have significant experience that indicates the l= ess optimized approach is not=A0successful=A0in the "market". We = should not ignore that.

We do need to decide how important VOD is. I'm not sure = that wasn't ironic understatement in your response. My understanding is= that a significant driver for this codec effort is RTCweb and there's = not much VOD there.

Kevin Gross
+1-303-447-0517
Medi= a Network Consultant
AVA Networks -=A0www.AVAnw.com,=A0www.X192.org


On Tue, Dec 4, 2012 at 4:40 PM, Ti= mothy B. Terriberry <tterribe@xiph.org> wrote:
Kevin Gross wrote:
There are 8 applications listed in section 3. VOD is the only one that
clearly benefits here. How much emphasis do we want to put on that
application?

I've seen estimates that at peak hours this constitutes 50% of the Inte= rnet bandwidth usage of the United States [1]. That might be worth emphasiz= ing.


Why? The motivation for bandwidth efficiency is never convincingly
substantiated in the draft. I'm aware that bandwidth efficiency is a very respected metric among codec developers. I'm questioning how
important it actually is for applications and users given that available network bandwidth is increasing much faster than required media
bandwidth and the efficiency increases we expect to be able
to achieve with a new codec are comparatively modest.

The users seem to think it is pretty darn important. See, for example, Chri= s DiBona's claims that switching to Theora would break the internet [2]= (rebutted [3], for the record, but the quality bar has moved beyond where = it was in 2009, and will have moved farther before we're done).

I'll cite our experience with Opus as another example: it always had ex= cellent latency and scalability, but people did not start to get really exc= ited about it until the quality started to exceed that of the best high-lat= ency codecs (this is not quite true: I gave a presentation on CELT, one of = the predecessors of Opus, at LCA 2009, and after explaining that bitrate ef= ficiency was explicitly a non-goal, had a number of excited people come up = to me and ask, "How long until this compresses better than Vorbis?&quo= t;). If you want people to use your codec, this matters.

We've tried twice now to get people to use codecs that were substantial= ly less complex than their competitors but which did not resoundingly beat = them in bitrate efficiency (to put it generously). It hasn't worked.
I'll also point out that HEVC's target was 50% less bitrate than H.= 264 High Profile at > HD resolutions. I don't have numbers on how cl= ose they got off-hand, but I think most users would agree that that is not = a modest number. If we don't at least match this performance, I'm n= ot going to say we've failed, but we should _certainly_ be doing better= than the RF options we already have.

[1] http://www.sandvine.com/news/pr_detail.asp?ID=3D312<= br> [2] http://lists.whatwg.org/htdig.cgi/w= hatwg-whatwg.org/2009-June/020380.html
[3] http://people.xiph.org/~greg/video/ytcompare/com= parison.html

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

--e89a8f838b95dfac4004d012e366-- From basilgohar@librevideo.org Wed Dec 5 04:15:15 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 2513E21F896C for ; Wed, 5 Dec 2012 04:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 wEAmIMvyJqF6 for ; Wed, 5 Dec 2012 04:15:11 -0800 (PST) Received: from mail.zaytoon.hidayahonline.net (zaytoon.hidayahonline.net [173.193.202.83]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE6021F8932 for ; Wed, 5 Dec 2012 04:15:11 -0800 (PST) Received: from [192.168.2.100] (cpe-75-180-52-231.columbus.res.rr.com [75.180.52.231]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: basilgohar@librevideo.org) by mail.zaytoon.hidayahonline.net (Postfix) with ESMTPSA id 4758F659E9B for ; Wed, 5 Dec 2012 07:15:10 -0500 (EST) Message-ID: <50BF3AC6.90904@librevideo.org> Date: Wed, 05 Dec 2012 07:15:02 -0500 From: Basil Mohamed Gohar User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: video-codec@ietf.org References: <50BE89FE.1080207@xiph.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [video-codec] Comments on draft-maxwell-videocodec-requirements-00 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, 05 Dec 2012 12:15:15 -0000 I think the value of including the use-case of VOD in conjunction with RTCWeb is that, in most cases, the application which will be playing VOD will be the same one used for VOD (e.g., the web browser). Targeting both will reach a wider audience, and there are cases in the life cycle of RTCWeb content were it will begin as an RTCWeb session but then end-up as VOD. An education might do a live session for students using RTCWeb for video conferencing to a wide audio, and then archive that same video to serve as VOD later. Many "live" examples can fit this method of usage as well. Being able to use the exact same bits, and not need to reencode, would add a lot of value to spec and open-up a lot more opportunities. I think this doesn't subtract at all from the "significant driver" aspect, but to ignore it is to cut out an enormous segment of the potential usage and benefit of having a RF, standardized video codec. On 12/04/2012 10:50 PM, Kevin Gross wrote: > Good stuff. Thanks for including the DiBona rebuttal - good points > made there, but, like you say, you have significant experience that > indicates the less optimized approach is not successful in the > "market". We should not ignore that. > > We do need to decide how important VOD is. I'm not sure that wasn't > ironic understatement in your response. My understanding is that a > significant driver for this codec effort is RTCweb and there's not > much VOD there. > > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com , www.X192.org > > > > On Tue, Dec 4, 2012 at 4:40 PM, Timothy B. Terriberry > > wrote: > > Kevin Gross wrote: > > There are 8 applications listed in section 3. VOD is the only > one that > clearly benefits here. How much emphasis do we want to put on that > application? > > > I've seen estimates that at peak hours this constitutes 50% of the > Internet bandwidth usage of the United States [1]. That might be > worth emphasizing. > > > Why? The motivation for bandwidth efficiency is never convincingly > substantiated in the draft. I'm aware that bandwidth > efficiency is a > very respected metric among codec developers. I'm questioning how > important it actually is for applications and users given that > available > network bandwidth is increasing much faster than required media > bandwidth and the efficiency increases we expect to be able > to achieve with a new codec are comparatively modest. > > > The users seem to think it is pretty darn important. See, for > example, Chris DiBona's claims that switching to Theora would > break the internet [2] (rebutted [3], for the record, but the > quality bar has moved beyond where it was in 2009, and will have > moved farther before we're done). > > I'll cite our experience with Opus as another example: it always > had excellent latency and scalability, but people did not start to > get really excited about it until the quality started to exceed > that of the best high-latency codecs (this is not quite true: I > gave a presentation on CELT, one of the predecessors of Opus, at > LCA 2009, and after explaining that bitrate efficiency was > explicitly a non-goal, had a number of excited people come up to > me and ask, "How long until this compresses better than Vorbis?"). > If you want people to use your codec, this matters. > > We've tried twice now to get people to use codecs that were > substantially less complex than their competitors but which did > not resoundingly beat them in bitrate efficiency (to put it > generously). It hasn't worked. > > I'll also point out that HEVC's target was 50% less bitrate than > H.264 High Profile at > HD resolutions. I don't have numbers on > how close they got off-hand, but I think most users would agree > that that is not a modest number. If we don't at least match this > performance, I'm not going to say we've failed, but we should > _certainly_ be doing better than the RF options we already have. > > [1] http://www.sandvine.com/news/pr_detail.asp?ID=312 > [2] > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020380.html > [3] http://people.xiph.org/~greg/video/ytcompare/comparison.html > > > _______________________________________________ > 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 -- Libre Video http://librevideo.org From giles@mozilla.com Wed Dec 5 13:25: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 B4E7221F8BEB for ; Wed, 5 Dec 2012 13:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeOnQva6swuN for ; Wed, 5 Dec 2012 13:25:38 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6FB21F8B9E for ; Wed, 5 Dec 2012 13:25:38 -0800 (PST) Received: from Glaucomys.local (unknown [64.213.70.194]) (Authenticated sender: rgiles@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 97121F2181; Wed, 5 Dec 2012 13:25:37 -0800 (PST) Message-ID: <50BFBBD7.9010703@mozilla.com> Date: Wed, 05 Dec 2012 13:25:43 -0800 From: Ralph Giles User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Kevin Gross References: <50BE89FE.1080207@xiph.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: video-codec@ietf.org, "Timothy B. Terriberry" Subject: Re: [video-codec] Comments on draft-maxwell-videocodec-requirements-00 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, 05 Dec 2012 21:25:38 -0000 On 12-12-04 7:50 PM, Kevin Gross wrote: > We do need to decide how important VOD is. I'm not sure that wasn't > ironic understatement in your response. My understanding is that a > significant driver for this codec effort is RTCweb and there's not much > VOD there. Personally I'm very interested in the VOD case. RTCweb's latency requirements tend to be a tighter constraint, but I hope this group will take advantages to improve performance in applications where latency doesn't matter as well. I do suspect that the desire to treat 'streaming' and 'downloading' as distinct cases will lead to a lot of VOD services offering video over RTCweb. -r From spencer@wonderhamster.org Thu Dec 6 10:07:49 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 3AFF521F87C8 for ; Thu, 6 Dec 2012 10:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 nmiW4i-HA0q5 for ; Thu, 6 Dec 2012 10:07:48 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id CD79721F87C0 for ; Thu, 6 Dec 2012 10:07:35 -0800 (PST) Received: from [132.177.126.194] (gtp126194.iol.unh.edu [132.177.126.194]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MgdCx-1TVJB41XFv-00O0cl; Thu, 06 Dec 2012 13:07:35 -0500 Message-ID: <50C0DEEC.5040901@wonderhamster.org> Date: Thu, 06 Dec 2012 12:07:40 -0600 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: video-codec@ietf.org References: <20121106112625.2btpoxrylcgg8w4c@kizuka.merseine.nu> <509AC2B4.3010406@wonderhamster.org> <20121107153423.d93rypvha8w480wc@kizuka.merseine.nu> <50AAC17E.5000208@wonderhamster.org> <50BE9F0E.7070304@xiph.org> In-Reply-To: <50BE9F0E.7070304@xiph.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:IHEziQdkZX/hv5R6D8B+i3kd8gt48RTdSezp+zZ/7Kd rtZdGhUnkVYDf7Rdw44kICHT5bRXWGweB0im+1c6IqZcoiE3HK F7dcBVKBfyjSUQpMbqMPn45td8sZU+tTtUP0sEz8rhnSv/BIQe iqzwVmFJ2N8+MnWgiJiLNIValqyPu8mrrZxtc4BtmcpllxFKGX TOjbZdpVUuqJkdoW47g+7fyzhB5QGe45CvXLd+HWfV7TCqKegx Fbbr06xRXRaYUA020SsbL1LAE07AKcDddHkOYEz82BpqNquTWg 22vAikTTaTBwwsEKx4w4fDwzJT4WLvr36jrwENn4QnNPjskEfp UYGFiS72h004IU2gz8ATHlW7wMZSpqYSFG3cOb9gz Subject: Re: [video-codec] Charter issues from BoF 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, 06 Dec 2012 18:07:49 -0000 Hi, Tim, Thanks for your reply. Where you are seems, to me, to be well within the boundaries of the kind of decisions we rely on working groups to make, and rely on working group chairs to call consensus for. On one specific point, and this is as much for your amusement as for your information ... On 12/4/2012 7:10 PM, Timothy B. Terriberry wrote: > Spencer Dawkins wrote: >> I'd suggest the proposed working group community discuss whether it's >> worth producing a video codec that is known to not be RF, early in the >> process. > > There is some difficulty in deciding what "known to not be RF" means. > Some people would take the existence of an IPR disclosure---any IPR > disclosure---that does not make that IPR available under RF terms to be > an indication that the work is not RF... and in the case that the > disclosure is by the author of the technique in question, this is very > compelling. Other people are willing to investigate the real risk > associated with those disclosures, evaluate the effectiveness of > design-arounds (which do not incur an obligation to update that > disclosure), etc. So, right. We rely on IETF working groups to make decisions about what's acceptable from an IPR standpoint, in specific cases. One of my favorite quotes of all time is from the 1968 NATO Software Engineering (conveniently located at http://www.scrummanager.net/files/nato1968e.pdf): "Bauer: The concept seems to be clear by now. It has been defined several times by examples of what it is not." Your response is very clear at a detailed level. My comment was at the 50,000-foot level - I'm betting there are IPR situations that you and other working group participants would agree are not even remotely "RF", and I'm wondering if it's helpful for working group participants to know whether they expect to proceed if that's the way things play out. > Experience with Opus suggests to me that this should be handled by WG > consensus on a case-by-case basis, instead of with an iron-clad rule in > the charter. This was discussed a fair bit at the bar BoF in Vancouver, > and the "developed under the IPR rules of the IETF" language that's > currently in the charter was strongly suggested to me as the best way to > phrase this. Yes, exactly - not that this is nailed down in the charter, but that the working group has given the question some thought. Perhaps that's a reasonable group activity; perhaps it's better left to individual contemplation. > Speaking personally, I would not support publishing as an RFC any codec > that I did not believe was RF. This is the kind of thought I'm suggesting :-) I'm glad my comments were mostly useful. IMO, one of the most important things IAB members do is to help IETF participants charter new work. Spencer From rob.glidden@sbcglobal.net Mon Dec 10 13:06:09 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 B4DCE21F868F for ; Mon, 10 Dec 2012 13:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 0z2JGauOzIfJ for ; Mon, 10 Dec 2012 13:06:05 -0800 (PST) Received: from nm26.access.bullet.mail.mud.yahoo.com (nm26.access.bullet.mail.mud.yahoo.com [66.94.237.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0F421F868E for ; Mon, 10 Dec 2012 13:06:05 -0800 (PST) Received: from [66.94.237.192] by nm26.access.bullet.mail.mud.yahoo.com with NNFMP; 10 Dec 2012 21:06:04 -0000 Received: from [68.142.198.107] by tm3.access.bullet.mail.mud.yahoo.com with NNFMP; 10 Dec 2012 21:06:04 -0000 Received: from [127.0.0.1] by smtp112.sbc.mail.mud.yahoo.com with NNFMP; 10 Dec 2012 21:06:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sbcglobal.net; s=s1024; t=1355173564; bh=l6udQ4+N/QOoJybD5G4PL7AWMMagldqsscynvf0ifVY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type; b=buZoC8iK/2PAVGWn3+0KhNubtSHmi74rrdzC31CJN8PGdDHj0SwulreDd5Ze1hvhK9BRjOkhogVfF7zVVz42L2/e9/bsJ4Y2I+9y8AwbMP6T5R+fuzWxfqZMqy9ttg9K8bpy6N85Ab2kbXNGhu8kT3WAhbJLW5QwRzyCF0rcUmo= X-Yahoo-Newman-Id: 543488.7731.bm@smtp112.sbc.mail.mud.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: WTEAF_MVM1ll4txfgqOFDb7kgo1HKnb25RMBV183jmRgylZ W6YAucDV_qEQAP_NSYCQ0rWZZRnBevo9pLwHL3rbI0c7NY1QV0bithm51.9H ZK3InCvvd9UioXIUhPE0kZnkDuHB_Kamgg8oYuKxWgmvgconsm.cvkpoOAcs 7mdYGjRkgsfQl98qU.POibRnyarsjsv3e5a9T7wqCrrpCSzS0gLYaakgwrnJ hyQbXOJDMXzLFJ_7s3nO3_jtmLj_R4rOS.D3M9PzjNw16KV2Y5HbgRAKstcB zCsDYsZeJ3fQCfYCGgsrqCzA7cdPZ67KpnAg0IkyjnQdOziaLIycnM2y7ZJa AQf1Q23zoLwRqkZ9CQugZm7RIRLHbh9JFRrm6WDmp6TzMO6.3_zrMtK9kjjJ mWjWJpv2Ou4QjuJYOmLG4FnawCwTrxH_UBBEmviRWFA7yVW_PQYDXeyJ7Pd2 dpeMBjhxKnywEppC11u5KecswN5J2CLW67ZiyqCuylCCjyXCsft7p6m..PSW G84BTbzV4F4mlbrL43WyH988O1o_hRwO4Vw8lt4egmhZchey0seXd5WQyIFg MQrBaCcK4flIEXfCpkuv5Z7T2x9qsDpNJExS5HI3zXE1y3TPE3YSuUO4B4f_ Rd1YPhUftJPXQi02zP8YOyWASo905mWnaB8yX9tNNBLam94VECXK50uGV9nv 2MV8hk1r6LOXyOrB2T7Z4.QMrWM4Jw.LhjP4.YRI7iK4M X-Yahoo-SMTP: xflwSnaswBCuS46GvTyhPI4RUJpgPG5UXouB5Vxqo4t9fsHeH0I- Received: from [10.0.0.10] (rob.glidden@99.25.33.39 with plain) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 10 Dec 2012 13:06:04 -0800 PST Message-ID: <50C64EBB.3090804@sbcglobal.net> Date: Mon, 10 Dec 2012 13:06:03 -0800 From: Rob Glidden User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Timothy B. Terriberry" References: <20121106112625.2btpoxrylcgg8w4c@kizuka.merseine.nu> <509AC2B4.3010406@wonderhamster.org> <20121107153423.d93rypvha8w480wc@kizuka.merseine.nu> <50AAC17E.5000208@wonderhamster.org> <50BE9F0E.7070304@xiph.org> In-Reply-To: <50BE9F0E.7070304@xiph.org> Content-Type: multipart/alternative; boundary="------------010809090501070901040908" Cc: video-codec@ietf.org Subject: [video-codec] MPEG IVC, Re: Charter issues from BoF 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, 10 Dec 2012 21:06:09 -0000 This is a multi-part message in MIME format. --------------010809090501070901040908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit > I've been approached by a couple of people from the MPEG IVC effort who > think that we can do better than liaison-style collaboration [...] Indeed, at the last MPEG meeting, decisions were taken to approach IETF about potential collaboration in RF codec standardization and to make publicly available the IVC Test Model (ITM) v 3.0. Internet Video Coding (aka "IVC") is a proposal for an RF codec standard under active exploration by MPEG. IVC is roughly based on a patent-scrubbed version of AVS and partly inspired by an RF codec activity at Sun called OMC. IVC is a work-in-progress, and improvements in the test code base and additional/alternative/better technologies (if RF vetted) are welcome. There is a lot to discuss about how collaboration could proceed so I won't try to put it all in one email. But in the spirit of "rough consensus and working code" and links below, here's a start. Rob MPEG 102 Meeting Resolutions, section 15.2 Internet Video Codec: http://www.itscj.ipsj.or.jp/sc29/open/29view/29n13049c.htm MPEG Liaison Statement to IETF RTCWeb WG and IETF video-codec BoF on the progress of IVC and WebVC: https://datatracker.ietf.org/liaison/1212/ IVC public repository: - URL: http://wg11.sc29.org/ivcpublic/repos/ - Read-Only User: ivcpublic - Read-Only Password: ivcpublic - (posted on IVC AHG alias) IVC Ad Hoc group alias: - http://mpeg.chiariglione.org/meetings/shanghai12/shanghai_ahg.htm ISO, SC29, MPEG procedures: - http://www.itscj.ipsj.or.jp/sc29/29w7proc.htm, in particular: - ISO/IEC Directives Part 1: Procedures for the technical work (9th edition, 2012) - ISO/IEC Directives Supplement - Procedures specific to JTC 1 (3rd edition, 2012) - Common Patent Policy for ITU-T/ITU-R/ISO/IEC - Guidelines for Implementation of the Common Patent Policy for ITU-T/ITU-R/ISO/IEC Ad Hoc Group rules: - SC29: Section 1.14, ISO/IEC Directives, Part 1 Supplement --- Procedures specific to JTC 1 - MPEG: http://mpeg.chiariglione.org/ad-hoc_groups.php ------------------------------------------------------------------------ On 12/4/2012 5:10 PM, Timothy B. Terriberry wrote: > Spencer Dawkins wrote: >> I'm not seeing a problem yet for this proposed working group, but I am >> remembering that "the Internet" covers a LOT of different points in the >> "speed/delay/reliability" space, from interconnected data centers to >> environments that are slightly better-connected than DTNRG networks :-) >> ... it would be great to be clear on what environments are being >> targeted. > > This is good advice. My primary interest is public, consumer-level, > best-effort networks (i.e., where people run browsers). I can try to > add some language to the charter to that effect if no one objects to > that being the focus. > >> program. I'd love for a chartered videocodec working group to have a >> good plan for liaison relationships, and I say that without reference to >> any other IETF working group having, or not having, a good plan for >> liaison relationships :-) > > I've been approached by a couple of people from the MPEG IVC effort > who think that we can do better than liaison-style collaboration, but > I'm not sure what the best approach is here, yet. I will try to > encourage them to post their thoughts on the list. > >> I'd suggest the proposed working group community discuss whether it's >> worth producing a video codec that is known to not be RF, early in the >> process. > > There is some difficulty in deciding what "known to not be RF" means. > Some people would take the existence of an IPR disclosure---any IPR > disclosure---that does not make that IPR available under RF terms to > be an indication that the work is not RF... and in the case that the > disclosure is by the author of the technique in question, this is very > compelling. Other people are willing to investigate the real risk > associated with those disclosures, evaluate the effectiveness of > design-arounds (which do not incur an obligation to update that > disclosure), etc. > > Experience with Opus suggests to me that this should be handled by WG > consensus on a case-by-case basis, instead of with an iron-clad rule > in the charter. This was discussed a fair bit at the bar BoF in > Vancouver, and the "developed under the IPR rules of the IETF" > language that's currently in the charter was strongly suggested to me > as the best way to phrase this. > > Speaking personally, I would not support publishing as an RFC any > codec that I did not believe was RF. > >> I'm not saying that I have an opinion about "one codec or many", I'm >> saying it would be helpful to understand whether one codec could meet >> the need for a codec that's "optimized for the Internet", before >> deciding whether to produce more than one codec. > > I think it can. The biggest challenge comes in deciding whether or not > to support coding tools that are not robust in the face of packet > loss. This includes, for example, anything which makes decisions about > what values to read from the bitstream based on the decoded, > reconstructed pixels. In the presence of loss, making one of those > decisions incorrectly would corrupt the rest of the frame. > > To illustrate this, one of the items mentioned in the VP9 presentation > included scoring candidate motion vectors by matching the > (already-decoded) edge pixels from neighboring blocks to the reference > frame at the same offset. I believe this is okay in its current form, > because the codebook used to decode the motion vector residual has no > dependency on the value of the MV being used as a predictor. But if we > wanted to use a scheme that _did_ depend on that value, we'd have to > give up the ability to look at those pixels in neighboring blocks. > I've had in mind for a while now a coding scheme which allows you to > code a MV relative to two different predictors, but unlike the normal > approach of "code which predictor is closer, and then code an offset > relative to that predictor," doesn't introduce any redundancy in the > coding. This depends on exactly what those two predictors are > (consider the case where they're the same, for example), so it > wouldn't be compatible with this VP9 technique for deriving the list > of predictors. > > But even in this case, we could pick which of the two approaches works > better on average, or even allow both techniques to be used, and > switch between them. Video frames have enough bits to make this kind > of switching at the frame or even smaller levels quite practical, and > you could pick up quite a lot of alternate algorithms like this before > it made sense to give up all the things that _are_ common in the two > use cases and have two completely separate codecs. > >> If I'm understanding what other people are saying, I'm not hearing "need >> old technology where patents have expired" as a strategy for video >> codecs, but It might be helpful for the proposed working group community >> to be clear on how much new technology people are planning to define, >> early on. > > I think we should be doing both things. If you look carefully at some > of the drafts that have already been submitted, you'll see some of the > references are _very_ old. There's a lot of research out there that's > been around for a long time, but never made it into a widely deployed > codec. Sometimes that's for very good reasons. Sometimes it's because > design decisions which were important at the time have become less so > as Moore's law has changed the best operating point on the chip > area/clock speed/power usage frontier. Sometimes it's because the > technique introduced practical problems which are solvable, but no one > ever attempted to solve them. > > We (Mozilla) are also exploring ways we can actually publish solid > information about why we think the the codec will be royalty-free > (once it is finished). As you may know, it is normally not in our > interest to do so (it is basically mapping out your defense, or at > least part of it, to any potential litigants), but it may wind up > being worth the trade-off. > >> I hope this is helpful. And again, I think the important thing is that >> the proposed working group community take Cullen's suggestions >> seriously, more than what the community decides about them. > > I think this (and Cullen's feedback generally) has been very helpful. > I hope to submit an updated version of the charter incorporating a > bunch of the feedback received thus far before next week. > _______________________________________________ > video-codec mailing list > video-codec@ietf.org > https://www.ietf.org/mailman/listinfo/video-codec > --------------010809090501070901040908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
> I've been approached by a couple of people from the MPEG IVC effort who 
> think that we can do better than liaison-style collaboration [...]
Indeed, at the last MPEG meeting, decisions were taken to approach IETF about potential collaboration in RF codec standardization and to make publicly available the IVC Test Model (ITM) v 3.0.

Internet Video Coding (aka "IVC") is a proposal for an RF codec standard under active exploration by MPEG.

IVC is roughly based on a patent-scrubbed version of AVS and partly inspired by an RF codec activity at Sun called OMC.

IVC is a work-in-progress, and improvements in the test code base and additional/alternative/better technologies (if RF vetted) are welcome. 

There is a lot to discuss about how collaboration could proceed so I won't try to put it all in one email.   But in the spirit of "rough consensus and working code" and links below, here's a start.

Rob

MPEG 102 Meeting Resolutions, section 15.2 Internet Video Codec:
http://www.itscj.ipsj.or.jp/sc29/open/29view/29n13049c.htm

MPEG Liaison Statement to IETF RTCWeb WG and IETF video-codec BoF on the progress of IVC and WebVC:
https://datatracker.ietf.org/liaison/1212/

IVC public repository:
- URL: http://wg11.sc29.org/ivcpublic/repos/
- Read-Only User: ivcpublic
- Read-Only Password: ivcpublic
- (posted on IVC AHG alias)

IVC Ad Hoc group alias:
- http://mpeg.chiariglione.org/meetings/shanghai12/shanghai_ahg.htm

ISO, SC29, MPEG procedures:
- http://www.itscj.ipsj.or.jp/sc29/29w7proc.htm, in particular:
- ISO/IEC Directives Part 1: Procedures for the technical work (9th edition, 2012)
- ISO/IEC Directives Supplement - Procedures specific to JTC 1 (3rd edition, 2012)
- Common Patent Policy for ITU-T/ITU-R/ISO/IEC
- Guidelines for Implementation of the Common Patent Policy for ITU-T/ITU-R/ISO/IEC

Ad Hoc Group rules:
- SC29: Section 1.14, ISO/IEC Directives, Part 1 Supplement —  Procedures specific to JTC 1
- MPEG: http://mpeg.chiariglione.org/ad-hoc_groups.php




On 12/4/2012 5:10 PM, Timothy B. Terriberry wrote:
Spencer Dawkins wrote:
I'm not seeing a problem yet for this proposed working group, but I am
remembering that "the Internet" covers a LOT of different points in the
"speed/delay/reliability" space, from interconnected data centers to
environments that are slightly better-connected than DTNRG networks :-)
... it would be great to be clear on what environments are being targeted.

This is good advice. My primary interest is public, consumer-level, best-effort networks (i.e., where people run browsers). I can try to add some language to the charter to that effect if no one objects to that being the focus.

program. I'd love for a chartered videocodec working group to have a
good plan for liaison relationships, and I say that without reference to
any other IETF working group having, or not having, a good plan for
liaison relationships :-)

I've been approached by a couple of people from the MPEG IVC effort who think that we can do better than liaison-style collaboration, but I'm not sure what the best approach is here, yet. I will try to encourage them to post their thoughts on the list.

I'd suggest the proposed working group community discuss whether it's
worth producing a video codec that is known to not be RF, early in the
process.

There is some difficulty in deciding what "known to not be RF" means. Some people would take the existence of an IPR disclosure---any IPR disclosure---that does not make that IPR available under RF terms to be an indication that the work is not RF... and in the case that the disclosure is by the author of the technique in question, this is very compelling. Other people are willing to investigate the real risk associated with those disclosures, evaluate the effectiveness of design-arounds (which do not incur an obligation to update that disclosure), etc.

Experience with Opus suggests to me that this should be handled by WG consensus on a case-by-case basis, instead of with an iron-clad rule in the charter. This was discussed a fair bit at the bar BoF in Vancouver, and the "developed under the IPR rules of the IETF" language that's currently in the charter was strongly suggested to me as the best way to phrase this.

Speaking personally, I would not support publishing as an RFC any codec that I did not believe was RF.

I'm not saying that I have an opinion about "one codec or many", I'm
saying it would be helpful to understand whether one codec could meet
the need for a codec that's "optimized for the Internet", before
deciding whether to produce more than one codec.

I think it can. The biggest challenge comes in deciding whether or not to support coding tools that are not robust in the face of packet loss. This includes, for example, anything which makes decisions about what values to read from the bitstream based on the decoded, reconstructed pixels. In the presence of loss, making one of those decisions incorrectly would corrupt the rest of the frame.

To illustrate this, one of the items mentioned in the VP9 presentation included scoring candidate motion vectors by matching the (already-decoded) edge pixels from neighboring blocks to the reference frame at the same offset. I believe this is okay in its current form, because the codebook used to decode the motion vector residual has no dependency on the value of the MV being used as a predictor. But if we wanted to use a scheme that _did_ depend on that value, we'd have to give up the ability to look at those pixels in neighboring blocks. I've had in mind for a while now a coding scheme which allows you to code a MV relative to two different predictors, but unlike the normal approach of "code which predictor is closer, and then code an offset relative to that predictor," doesn't introduce any redundancy in the coding. This depends on exactly what those two predictors are (consider the case where they're the same, for example), so it wouldn't be compatible with this VP9 technique for deriving the list of predictors.

But even in this case, we could pick which of the two approaches works better on average, or even allow both techniques to be used, and switch between them. Video frames have enough bits to make this kind of switching at the frame or even smaller levels quite practical, and you could pick up quite a lot of alternate algorithms like this before it made sense to give up all the things that _are_ common in the two use cases and have two completely separate codecs.

If I'm understanding what other people are saying, I'm not hearing "need
old technology where patents have expired" as a strategy for video
codecs, but It might be helpful for the proposed working group community
to be clear on how much new technology people are planning to define,
early on.

I think we should be doing both things. If you look carefully at some of the drafts that have already been submitted, you'll see some of the references are _very_ old. There's a lot of research out there that's been around for a long time, but never made it into a widely deployed codec. Sometimes that's for very good reasons. Sometimes it's because design decisions which were important at the time have become less so as Moore's law has changed the best operating point on the chip area/clock speed/power usage frontier. Sometimes it's because the technique introduced practical problems which are solvable, but no one ever attempted to solve them.

We (Mozilla) are also exploring ways we can actually publish solid information about why we think the the codec will be royalty-free (once it is finished). As you may know, it is normally not in our interest to do so (it is basically mapping out your defense, or at least part of it, to any potential litigants), but it may wind up being worth the trade-off.

I hope this is helpful. And again, I think the important thing is that
the proposed working group community take Cullen's suggestions
seriously, more than what the community decides about them.

I think this (and Cullen's feedback generally) has been very helpful. I hope to submit an updated version of the charter incorporating a bunch of the feedback received thus far before next week.
_______________________________________________
video-codec mailing list
video-codec@ietf.org
https://www.ietf.org/mailman/listinfo/video-codec


--------------010809090501070901040908-- From tom_a_sparks@yahoo.com.au Mon Dec 17 21:19:31 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 D409D1F0CE7 for ; Mon, 17 Dec 2012 21:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_60=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 ItSzG5uk8Mem for ; Mon, 17 Dec 2012 21:19:31 -0800 (PST) Received: from nm15.bullet.mail.bf1.yahoo.com (nm15.bullet.mail.bf1.yahoo.com [98.139.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id 069FE1F0CE6 for ; Mon, 17 Dec 2012 21:19:30 -0800 (PST) Received: from [98.139.215.140] by nm15.bullet.mail.bf1.yahoo.com with NNFMP; 18 Dec 2012 05:19:30 -0000 Received: from [98.139.212.200] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 18 Dec 2012 05:19:30 -0000 Received: from [127.0.0.1] by omp1009.mail.bf1.yahoo.com with NNFMP; 18 Dec 2012 05:19:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 125682.21928.bm@omp1009.mail.bf1.yahoo.com Received: (qmail 47227 invoked by uid 60001); 18 Dec 2012 05:19:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1355807970; bh=T/nlxlFrSD7r2eZdxvf5zfeAn2TRCgZLanxPCVNST3A=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=adAw6EGZXp8Qk0WefmFTahhY54UvkFtfZP3qm8WfU9TmBwfACAlqX8vY1ZxPX4ZJSO3+tYU1WM2b/9APwAP+iyQNNoRD3i+R+HmPhjfUQ7vbxcFgENVAPT7kcdiDbOXCSTGhunhcxZlfpM5pD2N6Adht97iyqTeDimUD/OMjF+E= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=oIT5pZi70DoFmKtb/aVgupKdg0DB78kDmYfrVK8FW1MgKgmqfOM3XmFSZjUy6D+3i1JlvQBbiCyvh0yScfjdAQmaFXZkWXx9zFAqbETCU9jrhgbKCj5ORAEGOJpgME/bBxso9pf7FN5HFWflbWCuBcvilE6AyIe94fJtAMw1c8Q=; X-YMail-OSG: 8m0kll4VM1m92wavikyN8Le6Fj.X.TCGK5RQ8CDgo9y22N6 _JxVXq2P04Jn2c4HA2FLNDLw6xKqV_3dnRturKBpJuYn2.ncja7azhxiIt7W b7YqC1XZsqH.A3Pzt65.guHRB81DzbL8fjBktZQwfVGPZgf8G0cViu.Pmi9a w65f1XfXXKDwqAg94VWo6eoeoDo4fKWMoSij3cKVvVR2ClxRKZkgPN7de2HK 61MD..LswHdCEMSmvb3NZY6gTDvJM6tyxLDJNN2ioPgFWG1emL1buc9LZkwD FJq5BhDiKulVfMQ51irrPiciglH0qPe_FYa4qdnaB9UOy2w6gU_Dvbh7YBRT .SgvEMiu2KCt307YX.3VU35CIIQ6jEmXLyESMm8dvUAUsXAMTBNh_Iz_x1m4 pt9f0wYY7GBJCZdVVbvY3_dSxwQ5lJrnM9bOX45OFnsn6kerl5mRJJK6uGdV OdpFTXxAEQVfTvY1hbIvcxjriBXYX001X2H3SB7fWN9a53xAwKzYHG88.Nuw AN09RXQ-- Received: from [121.217.127.224] by web142503.mail.bf1.yahoo.com via HTTP; Mon, 17 Dec 2012 21:19:29 PST X-Rocket-MIMEInfo: 001.001, c2VjdGlvbiAzLjIKbmVlZHMgc29tZSBleGFtcGxlcwplZzogc2t5cGUKCnNlY3Rpb24gMy4zCm5lZWRzIHNvbWUgZXhhbXBsZXMKRWc6IHdlYmNhbXMsIElQIGNhbWVyYXMKCnNlY3Rpb24gMy40CnNob3VsZCBiZSBicm9rZW4gdXAgaW50byB0d28gcGFydHMgYXMgdGhlcmUgYXJlIGRpZmZlcmVudCByZXF1aXJlbWVudHMgCgpzZWN0aW9uIDMuNGEgbGl2ZSB2aWRlbyBmZWVkcwpSZW1vdGUgY29udHJvbCB2ZWhpY2xlIHdpdGggb24tYm9hcmQgY2FtZXJhcwplZzogVUFWcywgUk9WcywgZXRjCgpzZWN0aW9uIDMBMAEBAQE- X-Mailer: YahooMailWebService/0.8.129.483 References: Message-ID: <1355807969.33097.YahooMailNeo@web142503.mail.bf1.yahoo.com> Date: Mon, 17 Dec 2012 21:19:29 -0800 (PST) From: Tom Sparks To: "video-codec@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [video-codec] Comments on draft-maxwell-videocodec-requirements-00 X-BeenThere: video-codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Tom Sparks List-Id: Video codec BoF discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 05:19:32 -0000 section 3.2=0Aneeds some examples=0Aeg: skype=0A=0Asection 3.3=0Aneeds some= examples=0AEg: webcams, IP cameras=0A=0Asection 3.4=0Ashould be broken up = into two parts as there are different requirements =0A=0Asection 3.4a live = video feeds=0ARemote control vehicle with on-board cameras=0Aeg: UAVs, ROVs= , etc=0A=0Asection 3.4b=0Alower frame rate 10fps, lossless compression=0Aex= cept for 3D video games=0Aeg: VNC, screencasting=0A=0Asection 3.5=0Awhat ab= out 2D Animation?=0Ahave the same basic requirements of screencasting=0A=0A= ---=0Atom_a_sparks "It's a nerdy thing I like to do"=A0=0A