From wwwrun@rfc-editor.org Thu Apr 12 16:49:16 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A41621F8712; Thu, 12 Apr 2012 16:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.037 X-Spam-Level: X-Spam-Status: No, score=-104.037 tagged_above=-999 required=5 tests=[AWL=1.040, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFKlX90LuQHH; Thu, 12 Apr 2012 16:49:15 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id 3969E21F86FD; Thu, 12 Apr 2012 16:49:04 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8AD3DB1E003; Thu, 12 Apr 2012 16:48:23 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120412234823.8AD3DB1E003@rfc-editor.org> Date: Thu, 12 Apr 2012 16:48:23 -0700 (PDT) Cc: payload@ietf.org, rfc-editor@rfc-editor.org Subject: [payload] RFC 6597 on RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 23:49:16 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6597 Title: RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data Author: J. Downs, Ed., J. Arbeiter, Ed. Status: Standards Track Stream: IETF Date: April 2012 Mailbox: jeff_downs@partech.com, jimsgti@gmail.com Pages: 13 Characters: 27339 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-payload-rtp-klv-04.txt URL: http://www.rfc-editor.org/rfc/rfc6597.txt This document specifies the payload format for packetization of KLV (Key-Length-Value) Encoded Data, as defined by the Society of Motion Picture and Television Engineers (SMPTE) in SMPTE ST 336, into the Real-time Transport Protocol (RTP). [STANDARDS-TRACK] This document is a product of the Audio/Video Transport Payloads Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From stewe@stewe.org Mon Apr 16 14:40:21 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A571121F85D8; Mon, 16 Apr 2012 14:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.732 X-Spam-Level: X-Spam-Status: No, score=-3.732 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd6Q+UVc+Q1w; Mon, 16 Apr 2012 14:40:21 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 941BE21F85AF; Mon, 16 Apr 2012 14:40:20 -0700 (PDT) Received: from mail49-am1-R.bigfish.com (10.3.201.248) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Mon, 16 Apr 2012 21:40:19 +0000 Received: from mail49-am1 (localhost [127.0.0.1]) by mail49-am1-R.bigfish.com (Postfix) with ESMTP id 955782C0779; Mon, 16 Apr 2012 21:40:19 +0000 (UTC) X-SpamScore: -21 X-BigFish: PS-21(zzbb2dI9371Ic89bh1454I14ffI1432N41c5N98dK179cMzz1202h1082kzzz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT003.namprd07.prod.outlook.com; RD:none; EFVD:NLI Received-SPF: pass (mail49-am1: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT003.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail49-am1 (localhost.localdomain [127.0.0.1]) by mail49-am1 (MessageSwitch) id 133461241776465_6633; Mon, 16 Apr 2012 21:40:17 +0000 (UTC) Received: from AM1EHSMHS006.bigfish.com (unknown [10.3.201.236]) by mail49-am1.bigfish.com (Postfix) with ESMTP id 040C824004E; Mon, 16 Apr 2012 21:40:17 +0000 (UTC) Received: from BL2PRD0710HT003.namprd07.prod.outlook.com (157.56.240.133) by AM1EHSMHS006.bigfish.com (10.3.207.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 16 Apr 2012 21:40:16 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.1.165]) by BL2PRD0710HT003.namprd07.prod.outlook.com ([10.255.102.38]) with mapi id 14.16.0143.004; Mon, 16 Apr 2012 21:40:10 +0000 From: Stephan Wenger To: Harald Alvestrand Thread-Topic: VP8 payload, decoder processing capabilities (was Re: [rtcweb] Resolution negotiation - a contribution) Thread-Index: AQHNHBl/zPrIuhmKBk2PF+XRFqQqHg== Date: Mon, 16 Apr 2012 21:40:09 +0000 Message-ID: In-Reply-To: <4F87D9B1.4000206@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <71C3AEB0F09920489EAE38D0873E7072@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "rtcweb@ietf.org" , "payload@ietf.org" Subject: [payload] VP8 payload, decoder processing capabilities (was Re: [rtcweb] Resolution negotiation - a contribution) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2012 21:40:21 -0000 Hi all, For context: Harald and myself have been at odds for a while now about the lack of support for a code point in the VP8 payload that can be used to negotiate a maximum decoder/bitstream complexity. Specifically, Harald (and other VP8 payload folks) suggested that generic mechanisms, such as the a=3Dframerate attribute of RFC4566 in conjunction with the picture size aspect of the imageattr of RFC 6236 can be used, at least in the rtcweb context. However, as far as I understood our argument, these two mechanisms in combination are not meant as a limit for decoder complexity (in terms of samples/sec processing rate), but rather as an indication, from receiver to sender, of an upper bound of what is "useful to send". See the email below. To me, it's quite obvious that an indication of "useful to send" includes "my decoder can handle this"; however, it could be more restrictive in that factors other than decoder horsepower could also be at play, such as screen size, user interface settings, and so on. I believe that the combination of what can be signaled using the above mechanisms should be sufficient for rtcweb. However, I also believe that it is insufficient for general purpose use, mostly because it requires the support of RFC 6236, which is not exactly a widely deployed technology. Further, the a=3Dframerate attribute is not a particularly useful attribute these days anymore, because variable frame rates, at least for software encoding/decoding, are the norm. In previous posts on the payload list (in response to the VP8 payload WGLC), I have commented on the practical shortcomings of the (lack of) complexity negotiation, and suggested that this needs to be fixed. Two options: 1) codify Harald's mechanism (based on a=3Dframerate and imageattr in the VP8 payload draft, at MUST strength. "In a declarative context, a prospective media sender supporting this (VP8 payload) specification MUST support RFC 4566 a=3Dframerate and RFC6236 imageattr, and MUST include code points according to both mechanisms to identify the properties of the media stream. In an offer-answer context, both offerer and answerer receiver supporting this VP8 payload specification MUST support a=3Dframertate and imageattr, and MUST include both in their respective offer/answer messages, so to identify an operation point that will not overload the media decoder's capabilities. The issue with this approach, IMO, is that we are dealing here with three individual code points (framerate, horizontal and vertical picture size), where a single code point ought to be sufficient for determining whether a d=E9cor is capable of decoding a stream, at least from a complexity viewpoint). 2) include, in the V8 payload, a negotiable SDP code point indicating the complexity of a stream, in units of samples per second processing requirements or a derivative thereof (such as: levels as used in the MPEG world). For example, the VP8 payload could include a single, optional, negotiable parameter "SamplePerSecond". If SamplePerSecond were absent in the SDP, a value of xxxxx must be inferred. (a sensible value for xxxxx could be, for example 9216000, which is the number of samples per second for VGA resolution at 30 Hz). If SamplePerSecond is present in a declarative context, it indicates the minimum processing requirements a decoder must support in order to successfully decode the stream. In a symmetric offer-answer context, SamplePerSecond can be used to "dial down" the complexity of the stream to a value that both encoder and decoder can support. My preference is obviously the second proposal, but I'm willing to help fleshing out either or both of them, just not today :-) Regards, Stephan =20 On 4.13.2012 00:45 , "Harald Alvestrand" wrote: >On 04/12/2012 11:13 PM, Stephan Wenger wrote: >> >> On 4.12.2012 12:08 , "Harald Alvestrand" wrote: >> >>> On 04/12/2012 08:19 PM, Stephan Wenger wrote: >>>> Hi Harald, >>>> Thanks for this strawman. I believe it should work, but I fail to see >>>> how >>>> a two dimensional negotiation requirement (negotiating max values for >>>> framerate and image size--which, in turn, also has two-dimensional >>>> properties) leads to better interop than a one dimensional negotiation >>>> (pixels per second processing requirement). >>> Stephan, >>> >>> I do not see this (or the requirement from the use-cases document) >>>first >>> and foremost a decoder complexity negotiation; it is a negotiation of >>> how much data it is useful to send, given the recipient's intended use >>> of that data. >> Then such a negotiation should be executed in addition. Decoder cycle >> requirement do matter in practical implementations. >Feel free to propose language that captures this requirement. As noted, >my I-D fragment doesn't. > > From harald@alvestrand.no Mon Apr 16 17:32:21 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD3821F84DE for ; Mon, 16 Apr 2012 17:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KK+3ZRoKs8js for ; Mon, 16 Apr 2012 17:32:20 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 0C76421F84DC for ; Mon, 16 Apr 2012 17:32:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1A8E039E113; Tue, 17 Apr 2012 02:32:19 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9CcLU7-AFTS; Tue, 17 Apr 2012 02:32:18 +0200 (CEST) Received: from [192.168.11.193] (c213-89-143-9.bredband.comhem.se [213.89.143.9]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 1680D39E089; Tue, 17 Apr 2012 02:32:18 +0200 (CEST) Message-ID: <4F8CBA11.1010600@alvestrand.no> Date: Tue, 17 Apr 2012 02:32:17 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "payload@ietf.org" Subject: Re: [payload] VP8 payload, decoder processing capabilities (was Re: [rtcweb] Resolution negotiation - a contribution) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 00:32:21 -0000 Responding strictly on the payload list, and regarding the VP8 payload format only: The a=framerate attribute is a maximum framerate only. Since the maximum framerate is the one that places the most stress on the decoder, the ability to use lower framerates is irrelevant to the question of restricting the decoder load. Apart from that, I believe we agree on what we disagree about; the input of other participants would be valuable. Harald On 04/16/2012 11:40 PM, Stephan Wenger wrote: > Hi all, > > For context: Harald and myself have been at odds for a while now about the > lack of support for a code point in the VP8 payload that can be used to > negotiate a maximum decoder/bitstream complexity. Specifically, Harald > (and other VP8 payload folks) suggested that generic mechanisms, such as > the a=framerate attribute of RFC4566 in conjunction with the picture size > aspect of the imageattr of RFC 6236 can be used, at least in the rtcweb > context. However, as far as I understood our argument, these two > mechanisms in combination are not meant as a limit for decoder complexity > (in terms of samples/sec processing rate), but rather as an indication, > from receiver to sender, of an upper bound of what is "useful to send". > See the email below. To me, it's quite obvious that an indication of > "useful to send" includes "my decoder can handle this"; however, it could > be more restrictive in that factors other than decoder horsepower could > also be at play, such as screen size, user interface settings, and so on. > > I believe that the combination of what can be signaled using the above > mechanisms should be sufficient for rtcweb. However, I also believe that > it is insufficient for general purpose use, mostly because it requires the > support of RFC 6236, which is not exactly a widely deployed technology. > Further, the a=framerate attribute is not a particularly useful attribute > these days anymore, because variable frame rates, at least for software > encoding/decoding, are the norm. > > In previous posts on the payload list (in response to the VP8 payload > WGLC), I have commented on the practical shortcomings of the (lack of) > complexity negotiation, and suggested that this needs to be fixed. > > Two options: > > 1) codify Harald's mechanism (based on a=framerate and imageattr in the > VP8 payload draft, at MUST strength. "In a declarative context, a > prospective media sender supporting this (VP8 payload) specification MUST > support RFC 4566 a=framerate and RFC6236 imageattr, and MUST include code > points according to both mechanisms to identify the properties of the > media stream. In an offer-answer context, both offerer and answerer > receiver supporting this VP8 payload specification MUST support > a=framertate and imageattr, and MUST include both in their respective > offer/answer messages, so to identify an operation point that will not > overload the media decoder's capabilities. > > The issue with this approach, IMO, is that we are dealing here with three > individual code points (framerate, horizontal and vertical picture size), > where a single code point ought to be sufficient for determining whether a > décor is capable of decoding a stream, at least from a complexity > viewpoint). > > 2) include, in the V8 payload, a negotiable SDP code point indicating the > complexity of a stream, in units of samples per second processing > requirements or a derivative thereof (such as: levels as used in the MPEG > world). For example, the VP8 payload could include a single, optional, > negotiable parameter "SamplePerSecond". If SamplePerSecond were absent in > the SDP, a value of xxxxx must be inferred. (a sensible value for xxxxx > could be, for example 9216000, which is the number of samples per second > for VGA resolution at 30 Hz). If SamplePerSecond is present in a > declarative context, it indicates the minimum processing requirements a > decoder must support in order to successfully decode the stream. In a > symmetric offer-answer context, SamplePerSecond can be used to "dial down" > the complexity of the stream to a value that both encoder and decoder can > support. > > My preference is obviously the second proposal, but I'm willing to help > fleshing out either or both of them, just not today :-) > > Regards, > Stephan > > > > On 4.13.2012 00:45 , "Harald Alvestrand" wrote: > >> On 04/12/2012 11:13 PM, Stephan Wenger wrote: >>> On 4.12.2012 12:08 , "Harald Alvestrand" wrote: >>> >>>> On 04/12/2012 08:19 PM, Stephan Wenger wrote: >>>>> Hi Harald, >>>>> Thanks for this strawman. I believe it should work, but I fail to see >>>>> how >>>>> a two dimensional negotiation requirement (negotiating max values for >>>>> framerate and image size--which, in turn, also has two-dimensional >>>>> properties) leads to better interop than a one dimensional negotiation >>>>> (pixels per second processing requirement). >>>> Stephan, >>>> >>>> I do not see this (or the requirement from the use-cases document) >>>> first >>>> and foremost a decoder complexity negotiation; it is a negotiation of >>>> how much data it is useful to send, given the recipient's intended use >>>> of that data. >>> Then such a negotiation should be executed in addition. Decoder cycle >>> requirement do matter in practical implementations. >> Feel free to propose language that captures this requirement. As noted, >> my I-D fragment doesn't. >> >> > > From yuepeiyu@huawei.com Mon Apr 16 19:26:55 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82ED221F851B; Mon, 16 Apr 2012 19:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.857 X-Spam-Level: X-Spam-Status: No, score=-96.857 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_110=0.6, J_CHICKENPOX_19=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7wpZL1F81Q9; Mon, 16 Apr 2012 19:26:51 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A44D321F84FD; Mon, 16 Apr 2012 19:26:22 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFG92446; Mon, 16 Apr 2012 22:26:22 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Apr 2012 19:23:47 -0700 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 16 Apr 2012 19:22:54 -0700 Received: from SZXEML511-MBS.china.huawei.com ([169.254.4.236]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Tue, 17 Apr 2012 10:23:43 +0800 From: "Yuepeiyu (Roy)" To: "payload@ietf.org" , "rtcweb@ietf.org" Thread-Topic: [payload] VP8 payload, decoder processing capabilities (was Re: [rtcweb] Resolution negotiation - a contribution) Thread-Index: AQHNHBmOL5G/TLbF00O5BKbyP5dzR5adpMaAgACVo+A= Date: Tue, 17 Apr 2012 02:23:42 +0000 Message-ID: References: <4F8CBA11.1010600@alvestrand.no> In-Reply-To: <4F8CBA11.1010600@alvestrand.no> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.73.89] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [payload] VP8 payload, decoder processing capabilities (was Re: [rtcweb] Resolution negotiation - a contribution) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 02:26:55 -0000 SGkgSGFyYWxkIGFuZCBTdGVwaGVuLA0KDQpGaXJzdCBvZiBhbGwsIHRoZSAiU2FtcGxlUGVyU2Vj b25kIiBpbiB0aGUgb3B0aW9uIDIgc2hvdWxkIGJlIHRoZSBtYXhpbWFsIHNhbXBsZSBwZXIgc2Vj b25kIG9mIHRoZSBzdHJlYW0sIGJlY2F1c2Ugb2YgdGhlIHZhcmlhYmxlIGZyYW1lIHJhdGVzLg0K DQpTZWNvbmQsIGlmIHdlIGFyZSB0YWxraW5nIGFib3V0IHNpZ25hbGluZyBvZiBkZWNvZGVyIGNv bXBsZXhpdHkgcG9pbnQgb2YgdmlldywgDQoJMSkgSSBkb24ndCBzZWUgbXVjaCBkaWZmZXJlbmNl IGJldHdlZW4gb3B0aW9uIDEgYW5kIDIsIGlmIG9wdGlvbiAyIGlzIHRvIHNpZ25hbCB0aGUgcmVh bCBudW1iZXIgb2YgInNhbXBsZSBwZXIgc2Vjb25kIi4gDQoJMikgSSBiZWxpZXZlIGEgZGVyaXZh dGl2ZSBvZiAiU2FtcGxlUGVyU2Vjb25kIiAoc3RpbGwgb3B0aW9uIDIpIHdvdWxkIG1ha2UgbW9y ZSBzZW5zZSwgc2luY2UgdG8gc29tZSBleHRlbnQsIGxlc3MgdmFsdWVzIHdvdWxkIGJlIHNlZW4g YXMgYSBndWlkZWxpbmUgZm9yIHRoZSBlbmNvZGVyIHRvIHByb2R1Y2UgdGhlIG1lZGlhIHN0cmVh bS4gVGhpcyBpcyBtZWFuaW5nZnVsIGVzcGVjaWFsbHkgZm9yIHRoZSBkZWNsYXJhdGl2ZSBjb250 ZXh0IHdoZXJlIHRoZSBlbmNvZGVyIGhhcyBmZXdlciBpbmZvcm1hdGlvbiBvZiB0aGUgZGVjb2Rl cidzIGNhcGFiaWxpdHkuDQoNCkp1c3QgbXkgMiBjZW50cy4NClJveQ0KLS0tLS3Tyrz+1K28/i0t LS0tDQq3orz+yMs6IHBheWxvYWQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBheWxvYWQtYm91 bmNlc0BpZXRmLm9yZ10gtPqx7SBIYXJhbGQgQWx2ZXN0cmFuZA0Kt6LLzcqxvOQ6IDIwMTLE6jTU wjE3yNUgODozMg0KytW8/sjLOiBTdGVwaGFuIFdlbmdlcg0Ks63LzTogcGF5bG9hZEBpZXRmLm9y Zw0K1vfM4jogUmU6IFtwYXlsb2FkXSBWUDggcGF5bG9hZCwgZGVjb2RlciBwcm9jZXNzaW5nIGNh cGFiaWxpdGllcyAod2FzIFJlOiBbcnRjd2ViXSBSZXNvbHV0aW9uIG5lZ290aWF0aW9uIC0gYSBj b250cmlidXRpb24pDQoNClJlc3BvbmRpbmcgc3RyaWN0bHkgb24gdGhlIHBheWxvYWQgbGlzdCwg YW5kIHJlZ2FyZGluZyB0aGUgVlA4IHBheWxvYWQgDQpmb3JtYXQgb25seToNCg0KVGhlIGE9ZnJh bWVyYXRlIGF0dHJpYnV0ZSBpcyBhIG1heGltdW0gZnJhbWVyYXRlIG9ubHkuIFNpbmNlIHRoZSBt YXhpbXVtIA0KZnJhbWVyYXRlIGlzIHRoZSBvbmUgdGhhdCBwbGFjZXMgdGhlIG1vc3Qgc3RyZXNz IG9uIHRoZSBkZWNvZGVyLCB0aGUgDQphYmlsaXR5IHRvIHVzZSBsb3dlciBmcmFtZXJhdGVzIGlz IGlycmVsZXZhbnQgdG8gdGhlIHF1ZXN0aW9uIG9mIA0KcmVzdHJpY3RpbmcgdGhlIGRlY29kZXIg bG9hZC4NCg0KQXBhcnQgZnJvbSB0aGF0LCBJIGJlbGlldmUgd2UgYWdyZWUgb24gd2hhdCB3ZSBk aXNhZ3JlZSBhYm91dDsgdGhlIGlucHV0IA0Kb2Ygb3RoZXIgcGFydGljaXBhbnRzIHdvdWxkIGJl IHZhbHVhYmxlLg0KDQogICAgICAgICAgICAgICAgIEhhcmFsZA0KDQpPbiAwNC8xNi8yMDEyIDEx OjQwIFBNLCBTdGVwaGFuIFdlbmdlciB3cm90ZToNCj4gSGkgYWxsLA0KPg0KPiBGb3IgY29udGV4 dDogSGFyYWxkIGFuZCBteXNlbGYgaGF2ZSBiZWVuIGF0IG9kZHMgZm9yIGEgd2hpbGUgbm93IGFi b3V0IHRoZQ0KPiBsYWNrIG9mIHN1cHBvcnQgZm9yIGEgY29kZSBwb2ludCBpbiB0aGUgVlA4IHBh eWxvYWQgdGhhdCBjYW4gYmUgdXNlZCB0bw0KPiBuZWdvdGlhdGUgYSBtYXhpbXVtIGRlY29kZXIv Yml0c3RyZWFtIGNvbXBsZXhpdHkuICBTcGVjaWZpY2FsbHksIEhhcmFsZA0KPiAoYW5kIG90aGVy IFZQOCBwYXlsb2FkIGZvbGtzKSBzdWdnZXN0ZWQgdGhhdCBnZW5lcmljIG1lY2hhbmlzbXMsIHN1 Y2ggYXMNCj4gdGhlIGE9ZnJhbWVyYXRlIGF0dHJpYnV0ZSBvZiBSRkM0NTY2IGluIGNvbmp1bmN0 aW9uIHdpdGggdGhlIHBpY3R1cmUgc2l6ZQ0KPiBhc3BlY3Qgb2YgdGhlIGltYWdlYXR0ciBvZiBS RkMgNjIzNiBjYW4gYmUgdXNlZCwgYXQgbGVhc3QgaW4gdGhlIHJ0Y3dlYg0KPiBjb250ZXh0LiAg SG93ZXZlciwgYXMgZmFyIGFzIEkgdW5kZXJzdG9vZCBvdXIgYXJndW1lbnQsIHRoZXNlIHR3bw0K PiBtZWNoYW5pc21zIGluIGNvbWJpbmF0aW9uIGFyZSBub3QgbWVhbnQgYXMgYSBsaW1pdCBmb3Ig ZGVjb2RlciBjb21wbGV4aXR5DQo+IChpbiB0ZXJtcyBvZiBzYW1wbGVzL3NlYyBwcm9jZXNzaW5n IHJhdGUpLCBidXQgcmF0aGVyIGFzIGFuIGluZGljYXRpb24sDQo+IGZyb20gcmVjZWl2ZXIgdG8g c2VuZGVyLCBvZiBhbiB1cHBlciBib3VuZCBvZiB3aGF0IGlzICJ1c2VmdWwgdG8gc2VuZCIuDQo+ IFNlZSB0aGUgZW1haWwgYmVsb3cuICBUbyBtZSwgaXQncyBxdWl0ZSBvYnZpb3VzIHRoYXQgYW4g aW5kaWNhdGlvbiBvZg0KPiAidXNlZnVsIHRvIHNlbmQiIGluY2x1ZGVzICJteSBkZWNvZGVyIGNh biBoYW5kbGUgdGhpcyI7IGhvd2V2ZXIsIGl0IGNvdWxkDQo+IGJlIG1vcmUgcmVzdHJpY3RpdmUg aW4gdGhhdCBmYWN0b3JzIG90aGVyIHRoYW4gZGVjb2RlciBob3JzZXBvd2VyIGNvdWxkDQo+IGFs c28gYmUgYXQgcGxheSwgc3VjaCBhcyBzY3JlZW4gc2l6ZSwgdXNlciBpbnRlcmZhY2Ugc2V0dGlu Z3MsIGFuZCBzbyBvbi4NCj4NCj4gSSBiZWxpZXZlIHRoYXQgdGhlIGNvbWJpbmF0aW9uIG9mIHdo YXQgY2FuIGJlIHNpZ25hbGVkIHVzaW5nIHRoZSBhYm92ZQ0KPiBtZWNoYW5pc21zIHNob3VsZCBi ZSBzdWZmaWNpZW50IGZvciBydGN3ZWIuICBIb3dldmVyLCBJIGFsc28gYmVsaWV2ZSB0aGF0DQo+ IGl0IGlzIGluc3VmZmljaWVudCBmb3IgZ2VuZXJhbCBwdXJwb3NlIHVzZSwgbW9zdGx5IGJlY2F1 c2UgaXQgcmVxdWlyZXMgdGhlDQo+IHN1cHBvcnQgb2YgUkZDIDYyMzYsIHdoaWNoIGlzIG5vdCBl eGFjdGx5IGEgd2lkZWx5IGRlcGxveWVkIHRlY2hub2xvZ3kuDQo+IEZ1cnRoZXIsIHRoZSBhPWZy YW1lcmF0ZSBhdHRyaWJ1dGUgaXMgbm90IGEgcGFydGljdWxhcmx5IHVzZWZ1bCBhdHRyaWJ1dGUN Cj4gdGhlc2UgZGF5cyBhbnltb3JlLCBiZWNhdXNlIHZhcmlhYmxlIGZyYW1lIHJhdGVzLCBhdCBs ZWFzdCBmb3Igc29mdHdhcmUNCj4gZW5jb2RpbmcvZGVjb2RpbmcsIGFyZSB0aGUgbm9ybS4NCj4N Cj4gSW4gcHJldmlvdXMgcG9zdHMgb24gdGhlIHBheWxvYWQgbGlzdCAoaW4gcmVzcG9uc2UgdG8g dGhlIFZQOCBwYXlsb2FkDQo+IFdHTEMpLCBJIGhhdmUgY29tbWVudGVkIG9uIHRoZSBwcmFjdGlj YWwgc2hvcnRjb21pbmdzIG9mIHRoZSAobGFjayBvZikNCj4gY29tcGxleGl0eSBuZWdvdGlhdGlv biwgYW5kIHN1Z2dlc3RlZCB0aGF0IHRoaXMgbmVlZHMgdG8gYmUgZml4ZWQuDQo+DQo+IFR3byBv cHRpb25zOg0KPg0KPiAxKSBjb2RpZnkgSGFyYWxkJ3MgbWVjaGFuaXNtIChiYXNlZCBvbiBhPWZy YW1lcmF0ZSBhbmQgaW1hZ2VhdHRyIGluIHRoZQ0KPiBWUDggcGF5bG9hZCBkcmFmdCwgYXQgTVVT VCBzdHJlbmd0aC4gICJJbiBhIGRlY2xhcmF0aXZlIGNvbnRleHQsIGENCj4gcHJvc3BlY3RpdmUg bWVkaWEgc2VuZGVyIHN1cHBvcnRpbmcgdGhpcyAoVlA4IHBheWxvYWQpIHNwZWNpZmljYXRpb24g TVVTVA0KPiBzdXBwb3J0IFJGQyA0NTY2IGE9ZnJhbWVyYXRlIGFuZCBSRkM2MjM2IGltYWdlYXR0 ciwgYW5kIE1VU1QgaW5jbHVkZSBjb2RlDQo+IHBvaW50cyBhY2NvcmRpbmcgdG8gYm90aCBtZWNo YW5pc21zIHRvIGlkZW50aWZ5IHRoZSBwcm9wZXJ0aWVzIG9mIHRoZQ0KPiBtZWRpYSBzdHJlYW0u ICBJbiBhbiBvZmZlci1hbnN3ZXIgY29udGV4dCwgYm90aCBvZmZlcmVyIGFuZCBhbnN3ZXJlcg0K PiByZWNlaXZlciBzdXBwb3J0aW5nIHRoaXMgVlA4IHBheWxvYWQgc3BlY2lmaWNhdGlvbiBNVVNU IHN1cHBvcnQNCj4gYT1mcmFtZXJ0YXRlIGFuZCBpbWFnZWF0dHIsIGFuZCBNVVNUIGluY2x1ZGUg Ym90aCBpbiB0aGVpciByZXNwZWN0aXZlDQo+IG9mZmVyL2Fuc3dlciBtZXNzYWdlcywgc28gdG8g aWRlbnRpZnkgYW4gb3BlcmF0aW9uIHBvaW50IHRoYXQgd2lsbCBub3QNCj4gb3ZlcmxvYWQgdGhl IG1lZGlhIGRlY29kZXIncyBjYXBhYmlsaXRpZXMuDQo+DQo+IFRoZSBpc3N1ZSB3aXRoIHRoaXMg YXBwcm9hY2gsIElNTywgaXMgdGhhdCB3ZSBhcmUgZGVhbGluZyBoZXJlIHdpdGggdGhyZWUNCj4g aW5kaXZpZHVhbCBjb2RlIHBvaW50cyAoZnJhbWVyYXRlLCBob3Jpem9udGFsIGFuZCB2ZXJ0aWNh bCBwaWN0dXJlIHNpemUpLA0KPiB3aGVyZSBhIHNpbmdsZSBjb2RlIHBvaW50IG91Z2h0IHRvIGJl IHN1ZmZpY2llbnQgZm9yIGRldGVybWluaW5nIHdoZXRoZXIgYQ0KPiBkqKZjb3IgaXMgY2FwYWJs ZSBvZiBkZWNvZGluZyBhIHN0cmVhbSwgYXQgbGVhc3QgZnJvbSBhIGNvbXBsZXhpdHkNCj4gdmll d3BvaW50KS4NCj4NCj4gMikgaW5jbHVkZSwgaW4gdGhlIFY4IHBheWxvYWQsIGEgbmVnb3RpYWJs ZSBTRFAgY29kZSBwb2ludCBpbmRpY2F0aW5nIHRoZQ0KPiBjb21wbGV4aXR5IG9mIGEgc3RyZWFt LCBpbiB1bml0cyBvZiBzYW1wbGVzIHBlciBzZWNvbmQgcHJvY2Vzc2luZw0KPiByZXF1aXJlbWVu dHMgb3IgYSBkZXJpdmF0aXZlIHRoZXJlb2YgKHN1Y2ggYXM6IGxldmVscyBhcyB1c2VkIGluIHRo ZSBNUEVHDQo+IHdvcmxkKS4gIEZvciBleGFtcGxlLCB0aGUgVlA4IHBheWxvYWQgY291bGQgaW5j bHVkZSBhIHNpbmdsZSwgb3B0aW9uYWwsDQo+IG5lZ290aWFibGUgcGFyYW1ldGVyICJTYW1wbGVQ ZXJTZWNvbmQiLiAgSWYgU2FtcGxlUGVyU2Vjb25kIHdlcmUgYWJzZW50IGluDQo+IHRoZSBTRFAs IGEgdmFsdWUgb2YgeHh4eHggbXVzdCBiZSBpbmZlcnJlZC4gIChhIHNlbnNpYmxlIHZhbHVlIGZv ciB4eHh4eA0KPiBjb3VsZCBiZSwgZm9yIGV4YW1wbGUgOTIxNjAwMCwgd2hpY2ggaXMgdGhlIG51 bWJlciBvZiBzYW1wbGVzIHBlciBzZWNvbmQNCj4gZm9yIFZHQSByZXNvbHV0aW9uIGF0IDMwIEh6 KS4gIElmIFNhbXBsZVBlclNlY29uZCBpcyBwcmVzZW50IGluIGENCj4gZGVjbGFyYXRpdmUgY29u dGV4dCwgaXQgaW5kaWNhdGVzIHRoZSBtaW5pbXVtIHByb2Nlc3NpbmcgcmVxdWlyZW1lbnRzIGEN Cj4gZGVjb2RlciBtdXN0IHN1cHBvcnQgaW4gb3JkZXIgdG8gc3VjY2Vzc2Z1bGx5IGRlY29kZSB0 aGUgc3RyZWFtLiAgSW4gYQ0KPiBzeW1tZXRyaWMgb2ZmZXItYW5zd2VyIGNvbnRleHQsIFNhbXBs ZVBlclNlY29uZCBjYW4gYmUgdXNlZCB0byAiZGlhbCBkb3duIg0KPiB0aGUgY29tcGxleGl0eSBv ZiB0aGUgc3RyZWFtIHRvIGEgdmFsdWUgdGhhdCBib3RoIGVuY29kZXIgYW5kIGRlY29kZXIgY2Fu DQo+IHN1cHBvcnQuDQo+DQo+IE15IHByZWZlcmVuY2UgaXMgb2J2aW91c2x5IHRoZSBzZWNvbmQg cHJvcG9zYWwsIGJ1dCBJJ20gd2lsbGluZyB0byBoZWxwDQo+IGZsZXNoaW5nIG91dCBlaXRoZXIg b3IgYm90aCBvZiB0aGVtLCBqdXN0IG5vdCB0b2RheSA6LSkNCj4NCj4gUmVnYXJkcywNCj4gU3Rl cGhhbg0KPg0KPg0KPg0KPiBPbiA0LjEzLjIwMTIgMDA6NDUgLCAiSGFyYWxkIEFsdmVzdHJhbmQi PGhhcmFsZEBhbHZlc3RyYW5kLm5vPiAgd3JvdGU6DQo+DQo+PiBPbiAwNC8xMi8yMDEyIDExOjEz IFBNLCBTdGVwaGFuIFdlbmdlciB3cm90ZToNCj4+PiBPbiA0LjEyLjIwMTIgMTI6MDggLCAiSGFy YWxkIEFsdmVzdHJhbmQiPGhhcmFsZEBhbHZlc3RyYW5kLm5vPiAgIHdyb3RlOg0KPj4+DQo+Pj4+ IE9uIDA0LzEyLzIwMTIgMDg6MTkgUE0sIFN0ZXBoYW4gV2VuZ2VyIHdyb3RlOg0KPj4+Pj4gSGkg SGFyYWxkLA0KPj4+Pj4gVGhhbmtzIGZvciB0aGlzIHN0cmF3bWFuLiAgSSBiZWxpZXZlIGl0IHNo b3VsZCB3b3JrLCBidXQgSSBmYWlsIHRvIHNlZQ0KPj4+Pj4gaG93DQo+Pj4+PiBhIHR3byBkaW1l bnNpb25hbCBuZWdvdGlhdGlvbiByZXF1aXJlbWVudCAobmVnb3RpYXRpbmcgbWF4IHZhbHVlcyBm b3INCj4+Pj4+IGZyYW1lcmF0ZSBhbmQgaW1hZ2Ugc2l6ZS0td2hpY2gsIGluIHR1cm4sIGFsc28g aGFzIHR3by1kaW1lbnNpb25hbA0KPj4+Pj4gcHJvcGVydGllcykgbGVhZHMgdG8gYmV0dGVyIGlu dGVyb3AgdGhhbiBhIG9uZSBkaW1lbnNpb25hbCBuZWdvdGlhdGlvbg0KPj4+Pj4gKHBpeGVscyBw ZXIgc2Vjb25kIHByb2Nlc3NpbmcgcmVxdWlyZW1lbnQpLg0KPj4+PiBTdGVwaGFuLA0KPj4+Pg0K Pj4+PiBJIGRvIG5vdCBzZWUgdGhpcyAob3IgdGhlIHJlcXVpcmVtZW50IGZyb20gdGhlIHVzZS1j YXNlcyBkb2N1bWVudCkNCj4+Pj4gZmlyc3QNCj4+Pj4gYW5kIGZvcmVtb3N0IGEgZGVjb2RlciBj b21wbGV4aXR5IG5lZ290aWF0aW9uOyBpdCBpcyBhIG5lZ290aWF0aW9uIG9mDQo+Pj4+IGhvdyBt dWNoIGRhdGEgaXQgaXMgdXNlZnVsIHRvIHNlbmQsIGdpdmVuIHRoZSByZWNpcGllbnQncyBpbnRl bmRlZCB1c2UNCj4+Pj4gb2YgdGhhdCBkYXRhLg0KPj4+IFRoZW4gc3VjaCBhIG5lZ290aWF0aW9u IHNob3VsZCBiZSBleGVjdXRlZCBpbiBhZGRpdGlvbi4gIERlY29kZXIgY3ljbGUNCj4+PiByZXF1 aXJlbWVudCBkbyBtYXR0ZXIgaW4gcHJhY3RpY2FsIGltcGxlbWVudGF0aW9ucy4NCj4+IEZlZWwg ZnJlZSB0byBwcm9wb3NlIGxhbmd1YWdlIHRoYXQgY2FwdHVyZXMgdGhpcyByZXF1aXJlbWVudC4g QXMgbm90ZWQsDQo+PiBteSBJLUQgZnJhZ21lbnQgZG9lc24ndC4NCj4+DQo+Pg0KPg0KPg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcGF5bG9hZCBt YWlsaW5nIGxpc3QNCnBheWxvYWRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcGF5bG9hZA0K From ron.even.tlv@gmail.com Mon Apr 16 23:50:05 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313A021F85C5 for ; Mon, 16 Apr 2012 23:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.879 X-Spam-Level: X-Spam-Status: No, score=-2.879 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elsCSieDExRA for ; Mon, 16 Apr 2012 23:50:01 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB8F721F8554 for ; Mon, 16 Apr 2012 23:50:00 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4093491wgb.13 for ; Mon, 16 Apr 2012 23:50:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=RpStbCZ+lTL+TaB8oyZoyFctn05UEoNfmnZlMMwBjeQ=; b=QldyjvozR5bODDP+qSlXlmLsbgs4KLKIMWAgO1qQ0CivAvTIYl1chb3g1jkGTX9gzh mdSgBrVALJnywBXKFMklJm76LsGAypbheePIJSATjdmDvpnxI49Xz0DFUFzdKDR7tl66 HfLpAg24hOup3rSdilwW9upiQsUp+uY5dSBLjrYC9K60soni+SwkvYohcGbx7/PYkDO8 3ZkVCp4YC2A+EzS7TtJb08w9r3zWRUsYDnBNc5ycViUJl4+aSNxDFCeb8K0+s9kWW3at Qe8/fBe/Adtq7Eyu1HORCR1aagc1djDwVpjjiHOpzNzqMRZ1jjKN4/twSRSCERScsa+c o53Q== Received: by 10.180.80.70 with SMTP id p6mr4072780wix.21.1334645399498; Mon, 16 Apr 2012 23:49:59 -0700 (PDT) Received: from windows8d787f9 ([109.65.204.117]) by mx.google.com with ESMTPS id u9sm24855001wix.0.2012.04.16.23.49.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 Apr 2012 23:49:58 -0700 (PDT) From: "Roni Even" To: "'Stephan Wenger'" , "'Harald Alvestrand'" References: <4F87D9B1.4000206@alvestrand.no> In-Reply-To: Date: Tue, 17 Apr 2012 09:48:23 +0300 Message-ID: <4f8d1296.e950b40a.7abe.4224@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHNHBl/zPrIuhmKBk2PF+XRFqQqHpaekqZg Content-Language: en-us Cc: payload@ietf.org Subject: Re: [payload] VP8 payload, decoder processing capabilities (was Re: [rtcweb] Resolution negotiation - a contribution) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 06:50:05 -0000 Hi, I think that one point that is missing here is if the issue is only for = the receiver capability or request or if there is a need to specify also the encoder capabilities. In H.264 (RFC6184) the level parameter signal the encoding and decoding capability and the answers can signal a lower level (If asymmetry is supported). The level provides some maximum on what the receiver can request. I think that the image attribute does not provide this functionality and = I am not sure if this is the meaning of the SamplesPerSecond parameter. I am keeping the discussion in payload WG=20 Roni Even As individual > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf Of Stephan Wenger > Sent: Tuesday, April 17, 2012 12:40 AM > To: Harald Alvestrand > Cc: rtcweb@ietf.org; payload@ietf.org > Subject: [payload] VP8 payload, decoder processing capabilities (was > Re: [rtcweb] Resolution negotiation - a contribution) >=20 > Hi all, >=20 > For context: Harald and myself have been at odds for a while now about > the lack of support for a code point in the VP8 payload that can be > used to negotiate a maximum decoder/bitstream complexity. > Specifically, Harald (and other VP8 payload folks) suggested that > generic mechanisms, such as the a=3Dframerate attribute of RFC4566 in > conjunction with the picture size aspect of the imageattr of RFC 6236 > can be used, at least in the rtcweb context. However, as far as I > understood our argument, these two mechanisms in combination are not > meant as a limit for decoder complexity (in terms of samples/sec > processing rate), but rather as an indication, from receiver to = sender, > of an upper bound of what is "useful to send". > See the email below. To me, it's quite obvious that an indication of > "useful to send" includes "my decoder can handle this"; however, it > could be more restrictive in that factors other than decoder = horsepower > could also be at play, such as screen size, user interface settings, > and so on. >=20 > I believe that the combination of what can be signaled using the above > mechanisms should be sufficient for rtcweb. However, I also believe > that it is insufficient for general purpose use, mostly because it > requires the support of RFC 6236, which is not exactly a widely > deployed technology. > Further, the a=3Dframerate attribute is not a particularly useful > attribute these days anymore, because variable frame rates, at least > for software encoding/decoding, are the norm. >=20 > In previous posts on the payload list (in response to the VP8 payload > WGLC), I have commented on the practical shortcomings of the (lack of) > complexity negotiation, and suggested that this needs to be fixed. >=20 > Two options: >=20 > 1) codify Harald's mechanism (based on a=3Dframerate and imageattr in = the > VP8 payload draft, at MUST strength. "In a declarative context, a > prospective media sender supporting this (VP8 payload) specification > MUST support RFC 4566 a=3Dframerate and RFC6236 imageattr, and MUST > include code points according to both mechanisms to identify the > properties of the media stream. In an offer-answer context, both > offerer and answerer receiver supporting this VP8 payload = specification > MUST support a=3Dframertate and imageattr, and MUST include both in = their > respective offer/answer messages, so to identify an operation point > that will not overload the media decoder's capabilities. >=20 > The issue with this approach, IMO, is that we are dealing here with > three individual code points (framerate, horizontal and vertical > picture size), where a single code point ought to be sufficient for > determining whether a d=E9cor is capable of decoding a stream, at = least > from a complexity viewpoint). >=20 > 2) include, in the V8 payload, a negotiable SDP code point indicating > the complexity of a stream, in units of samples per second processing > requirements or a derivative thereof (such as: levels as used in the > MPEG world). For example, the VP8 payload could include a single, > optional, negotiable parameter "SamplePerSecond". If SamplePerSecond > were absent in the SDP, a value of xxxxx must be inferred. (a = sensible > value for xxxxx could be, for example 9216000, which is the number of > samples per second for VGA resolution at 30 Hz). If SamplePerSecond = is > present in a declarative context, it indicates the minimum processing > requirements a decoder must support in order to successfully decode = the > stream. In a symmetric offer-answer context, SamplePerSecond can be > used to "dial down" > the complexity of the stream to a value that both encoder and decoder > can support. >=20 > My preference is obviously the second proposal, but I'm willing to = help > fleshing out either or both of them, just not today :-) >=20 > Regards, > Stephan >=20 >=20 >=20 > On 4.13.2012 00:45 , "Harald Alvestrand" wrote: >=20 > >On 04/12/2012 11:13 PM, Stephan Wenger wrote: > >> > >> On 4.12.2012 12:08 , "Harald Alvestrand" > wrote: > >> > >>> On 04/12/2012 08:19 PM, Stephan Wenger wrote: > >>>> Hi Harald, > >>>> Thanks for this strawman. I believe it should work, but I fail = to > >>>> see how a two dimensional negotiation requirement (negotiating = max > >>>> values for framerate and image size--which, in turn, also has > >>>> two-dimensional > >>>> properties) leads to better interop than a one dimensional > >>>> negotiation (pixels per second processing requirement). > >>> Stephan, > >>> > >>> I do not see this (or the requirement from the use-cases document) > >>>first and foremost a decoder complexity negotiation; it is a > >>>negotiation of how much data it is useful to send, given the > >>>recipient's intended use of that data. > >> Then such a negotiation should be executed in addition. Decoder > >> cycle requirement do matter in practical implementations. > >Feel free to propose language that captures this requirement. As > noted, > >my I-D fragment doesn't. > > > > >=20 >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From harald@alvestrand.no Tue Apr 17 00:32:02 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5998121F8475 for ; Tue, 17 Apr 2012 00:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.924 X-Spam-Level: X-Spam-Status: No, score=-109.924 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHBNbnlRPdWl for ; Tue, 17 Apr 2012 00:32:00 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B5BBD21F8550 for ; Tue, 17 Apr 2012 00:31:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9171739E11A; Tue, 17 Apr 2012 09:31:58 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzXFtte-gefk; Tue, 17 Apr 2012 09:31:53 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5338F39E072; Tue, 17 Apr 2012 09:31:53 +0200 (CEST) Message-ID: <4F8D1C69.3080905@alvestrand.no> Date: Tue, 17 Apr 2012 09:31:53 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: Roni Even References: <4F87D9B1.4000206@alvestrand.no> <4f8d1296.e950b40a.7abe.4224@mx.google.com> In-Reply-To: <4f8d1296.e950b40a.7abe.4224@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: payload@ietf.org Subject: Re: [payload] VP8 payload, decoder processing capabilities (was Re: [rtcweb] Resolution negotiation - a contribution) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 07:32:02 -0000 On 04/17/2012 08:48 AM, Roni Even wrote: > Hi, > I think that one point that is missing here is if the issue is only for the > receiver capability or request or if there is a need to specify also the > encoder capabilities. > In H.264 (RFC6184) the level parameter signal the encoding and decoding > capability and the answers can signal a lower level (If asymmetry is > supported). The level provides some maximum on what the receiver can > request. > I think that the image attribute does not provide this functionality and I > am not sure if this is the meaning of the SamplesPerSecond parameter. This discussion is strictly about the VP8 codec, so the question is really whether this functionality is needed for the VP8 codec. In VP8, there are no options at the encoder, and no intention to add any. > I am keeping the discussion in payload WG Respected. > Roni Even > As individual > >> -----Original Message----- >> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On >> Behalf Of Stephan Wenger >> Sent: Tuesday, April 17, 2012 12:40 AM >> To: Harald Alvestrand >> Cc: rtcweb@ietf.org; payload@ietf.org >> Subject: [payload] VP8 payload, decoder processing capabilities (was >> Re: [rtcweb] Resolution negotiation - a contribution) >> >> Hi all, >> >> For context: Harald and myself have been at odds for a while now about >> the lack of support for a code point in the VP8 payload that can be >> used to negotiate a maximum decoder/bitstream complexity. >> Specifically, Harald (and other VP8 payload folks) suggested that >> generic mechanisms, such as the a=framerate attribute of RFC4566 in >> conjunction with the picture size aspect of the imageattr of RFC 6236 >> can be used, at least in the rtcweb context. However, as far as I >> understood our argument, these two mechanisms in combination are not >> meant as a limit for decoder complexity (in terms of samples/sec >> processing rate), but rather as an indication, from receiver to sender, >> of an upper bound of what is "useful to send". >> See the email below. To me, it's quite obvious that an indication of >> "useful to send" includes "my decoder can handle this"; however, it >> could be more restrictive in that factors other than decoder horsepower >> could also be at play, such as screen size, user interface settings, >> and so on. >> >> I believe that the combination of what can be signaled using the above >> mechanisms should be sufficient for rtcweb. However, I also believe >> that it is insufficient for general purpose use, mostly because it >> requires the support of RFC 6236, which is not exactly a widely >> deployed technology. >> Further, the a=framerate attribute is not a particularly useful >> attribute these days anymore, because variable frame rates, at least >> for software encoding/decoding, are the norm. >> >> In previous posts on the payload list (in response to the VP8 payload >> WGLC), I have commented on the practical shortcomings of the (lack of) >> complexity negotiation, and suggested that this needs to be fixed. >> >> Two options: >> >> 1) codify Harald's mechanism (based on a=framerate and imageattr in the >> VP8 payload draft, at MUST strength. "In a declarative context, a >> prospective media sender supporting this (VP8 payload) specification >> MUST support RFC 4566 a=framerate and RFC6236 imageattr, and MUST >> include code points according to both mechanisms to identify the >> properties of the media stream. In an offer-answer context, both >> offerer and answerer receiver supporting this VP8 payload specification >> MUST support a=framertate and imageattr, and MUST include both in their >> respective offer/answer messages, so to identify an operation point >> that will not overload the media decoder's capabilities. >> >> The issue with this approach, IMO, is that we are dealing here with >> three individual code points (framerate, horizontal and vertical >> picture size), where a single code point ought to be sufficient for >> determining whether a décor is capable of decoding a stream, at least >> from a complexity viewpoint). >> >> 2) include, in the V8 payload, a negotiable SDP code point indicating >> the complexity of a stream, in units of samples per second processing >> requirements or a derivative thereof (such as: levels as used in the >> MPEG world). For example, the VP8 payload could include a single, >> optional, negotiable parameter "SamplePerSecond". If SamplePerSecond >> were absent in the SDP, a value of xxxxx must be inferred. (a sensible >> value for xxxxx could be, for example 9216000, which is the number of >> samples per second for VGA resolution at 30 Hz). If SamplePerSecond is >> present in a declarative context, it indicates the minimum processing >> requirements a decoder must support in order to successfully decode the >> stream. In a symmetric offer-answer context, SamplePerSecond can be >> used to "dial down" >> the complexity of the stream to a value that both encoder and decoder >> can support. >> >> My preference is obviously the second proposal, but I'm willing to help >> fleshing out either or both of them, just not today :-) >> >> Regards, >> Stephan >> >> >> >> On 4.13.2012 00:45 , "Harald Alvestrand" wrote: >> >>> On 04/12/2012 11:13 PM, Stephan Wenger wrote: >>>> On 4.12.2012 12:08 , "Harald Alvestrand" >> wrote: >>>>> On 04/12/2012 08:19 PM, Stephan Wenger wrote: >>>>>> Hi Harald, >>>>>> Thanks for this strawman. I believe it should work, but I fail to >>>>>> see how a two dimensional negotiation requirement (negotiating max >>>>>> values for framerate and image size--which, in turn, also has >>>>>> two-dimensional >>>>>> properties) leads to better interop than a one dimensional >>>>>> negotiation (pixels per second processing requirement). >>>>> Stephan, >>>>> >>>>> I do not see this (or the requirement from the use-cases document) >>>>> first and foremost a decoder complexity negotiation; it is a >>>>> negotiation of how much data it is useful to send, given the >>>>> recipient's intended use of that data. >>>> Then such a negotiation should be executed in addition. Decoder >>>> cycle requirement do matter in practical implementations. >>> Feel free to propose language that captures this requirement. As >> noted, >>> my I-D fragment doesn't. >>> >>> >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload > From tharper@logitech.com Tue Apr 17 00:47:12 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB00421F8498 for ; Tue, 17 Apr 2012 00:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QT+MhBvOC9ZW for ; Tue, 17 Apr 2012 00:47:05 -0700 (PDT) Received: from na3sys009aog133.obsmtp.com (na3sys009aog133.obsmtp.com [74.125.149.82]) by ietfa.amsl.com (Postfix) with ESMTP id 7064121F8495 for ; Tue, 17 Apr 2012 00:47:05 -0700 (PDT) Received: from mail-pb0-f51.google.com ([209.85.160.51]) (using TLSv1) by na3sys009aob133.postini.com ([74.125.148.12]) with SMTP ID DSNKT40f+DGFFTXKRgmh/DoLeyh30iWCo5Gq@postini.com; Tue, 17 Apr 2012 00:47:05 PDT Received: by pbcwy12 with SMTP id wy12so10567757pbc.38 for ; Tue, 17 Apr 2012 00:47:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=fvJbRaNGOj2MXhe9CT94Q/CJa6sFl5uDgKaL/3o2F7g=; b=Lg9hxLAU2dppmlnij4cQxJVC1pT33OzBniRNBgjDqUm4eIl76GVtqEliTCsVeukX2a IDpGxGFmpyAKKyRsPl1/j00igTRbjEZ5OjZA9TVcXHOgK6qice4ISbknr7kgNoOmdRZh +7g6ImNK/eeVi5wH4Je4+3CP4VsgDBg8p6bVXwEC8S7BHqjrYjMPiCSc/sgpzLQ8W6jz m14NojvG0EplueOyZCRuaoxHBETMaPIoERfBixJrZ03YxBJMsFBCEehG6O3LcbPkaXCT lz57iOIpC8Yte92Pg3VxqxE3NUYgzr6EbfGSQCWOViij+DlA3WlzXD+fRWhllpBgAIiA w6qg== Received: by 10.68.211.104 with SMTP id nb8mr35290646pbc.40.1334648824112; Tue, 17 Apr 2012 00:47:04 -0700 (PDT) Received: from [192.168.1.111] (c-76-126-8-251.hsd1.ca.comcast.net. [76.126.8.251]) by mx.google.com with ESMTPS id ms6sm15622717pbb.53.2012.04.17.00.47.01 (version=SSLv3 cipher=OTHER); Tue, 17 Apr 2012 00:47:02 -0700 (PDT) Message-ID: <4F8D1FF0.5050002@logitech.com> Date: Tue, 17 Apr 2012 00:46:56 -0700 From: tom harper User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Roni Even References: <4F87D9B1.4000206@alvestrand.no> <4f8d1296.e950b40a.7abe.4224@mx.google.com> In-Reply-To: <4f8d1296.e950b40a.7abe.4224@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQl52SYCFAZrzqqhXjde05uu79iDqoAqjfaFOBQZSD6YsROaNCccRxId3R3ou5BJh45fBg62 Cc: payload@ietf.org Subject: Re: [payload] VP8 payload, decoder processing capabilities (was Re: [rtcweb] Resolution negotiation - a contribution) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tharper@logitech.com List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 07:47:13 -0000 I understand where Harald is coming from, VP8 doesn't have the same computational jump that h264 has between cavlc and cabac at the decoder. With h264 this is important, as there are a bunch of devices that only do the former. I don't think this applies to vp8 that I know of. So you don't need a level equivalent. However, I don't know that the standards proposed by Harald do everything either. Unless I misread, I think rfc 4566 a=framerate is intended to be defined at the media level for all video media- For devices with a general frame rate cap this is fine, but often you instead want a codec specific max frame rate, due to the varying complexities of differing codecs. Also, it isn't clear to me from looking at the imageattr spec that you can easily specify a range of resolutions other than listing them out in verbose detail. I don't think that is ideal either. And I might ultimately have a frame rate constraint at a higher resolution that I don't have at a lower one. So that wouldn't be clear using imageattr. For the cases a=framerate doesn't handle, there still needs to be the ability to negotiate a codec specific preferred max display size, as well as the codec specific computational limit of decoding,. So I would vote for a solution like maxmbps- the max complexity is then understood. Then I guess you would need a maxfs equivalent also. Then you could just allow the application to let the frame rate vary as needed. as me, Tom On 4/16/2012 11:48 PM, Roni Even wrote: > Hi, > I think that one point that is missing here is if the issue is only for the > receiver capability or request or if there is a need to specify also the > encoder capabilities. > In H.264 (RFC6184) the level parameter signal the encoding and decoding > capability and the answers can signal a lower level (If asymmetry is > supported). The level provides some maximum on what the receiver can > request. > I think that the image attribute does not provide this functionality and I > am not sure if this is the meaning of the SamplesPerSecond parameter. > > I am keeping the discussion in payload WG > > Roni Even > As individual > >> -----Original Message----- >> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On >> Behalf Of Stephan Wenger >> Sent: Tuesday, April 17, 2012 12:40 AM >> To: Harald Alvestrand >> Cc: rtcweb@ietf.org; payload@ietf.org >> Subject: [payload] VP8 payload, decoder processing capabilities (was >> Re: [rtcweb] Resolution negotiation - a contribution) >> >> Hi all, >> >> For context: Harald and myself have been at odds for a while now about >> the lack of support for a code point in the VP8 payload that can be >> used to negotiate a maximum decoder/bitstream complexity. >> Specifically, Harald (and other VP8 payload folks) suggested that >> generic mechanisms, such as the a=framerate attribute of RFC4566 in >> conjunction with the picture size aspect of the imageattr of RFC 6236 >> can be used, at least in the rtcweb context. However, as far as I >> understood our argument, these two mechanisms in combination are not >> meant as a limit for decoder complexity (in terms of samples/sec >> processing rate), but rather as an indication, from receiver to sender, >> of an upper bound of what is "useful to send". >> See the email below. To me, it's quite obvious that an indication of >> "useful to send" includes "my decoder can handle this"; however, it >> could be more restrictive in that factors other than decoder horsepower >> could also be at play, such as screen size, user interface settings, >> and so on. >> >> I believe that the combination of what can be signaled using the above >> mechanisms should be sufficient for rtcweb. However, I also believe >> that it is insufficient for general purpose use, mostly because it >> requires the support of RFC 6236, which is not exactly a widely >> deployed technology. >> Further, the a=framerate attribute is not a particularly useful >> attribute these days anymore, because variable frame rates, at least >> for software encoding/decoding, are the norm. >> >> In previous posts on the payload list (in response to the VP8 payload >> WGLC), I have commented on the practical shortcomings of the (lack of) >> complexity negotiation, and suggested that this needs to be fixed. >> >> Two options: >> >> 1) codify Harald's mechanism (based on a=framerate and imageattr in the >> VP8 payload draft, at MUST strength. "In a declarative context, a >> prospective media sender supporting this (VP8 payload) specification >> MUST support RFC 4566 a=framerate and RFC6236 imageattr, and MUST >> include code points according to both mechanisms to identify the >> properties of the media stream. In an offer-answer context, both >> offerer and answerer receiver supporting this VP8 payload specification >> MUST support a=framertate and imageattr, and MUST include both in their >> respective offer/answer messages, so to identify an operation point >> that will not overload the media decoder's capabilities. >> >> The issue with this approach, IMO, is that we are dealing here with >> three individual code points (framerate, horizontal and vertical >> picture size), where a single code point ought to be sufficient for >> determining whether a décor is capable of decoding a stream, at least >> from a complexity viewpoint). >> >> 2) include, in the V8 payload, a negotiable SDP code point indicating >> the complexity of a stream, in units of samples per second processing >> requirements or a derivative thereof (such as: levels as used in the >> MPEG world). For example, the VP8 payload could include a single, >> optional, negotiable parameter "SamplePerSecond". If SamplePerSecond >> were absent in the SDP, a value of xxxxx must be inferred. (a sensible >> value for xxxxx could be, for example 9216000, which is the number of >> samples per second for VGA resolution at 30 Hz). If SamplePerSecond is >> present in a declarative context, it indicates the minimum processing >> requirements a decoder must support in order to successfully decode the >> stream. In a symmetric offer-answer context, SamplePerSecond can be >> used to "dial down" >> the complexity of the stream to a value that both encoder and decoder >> can support. >> >> My preference is obviously the second proposal, but I'm willing to help >> fleshing out either or both of them, just not today :-) >> >> Regards, >> Stephan >> >> >> >> On 4.13.2012 00:45 , "Harald Alvestrand" wrote: >> >>> On 04/12/2012 11:13 PM, Stephan Wenger wrote: >>>> On 4.12.2012 12:08 , "Harald Alvestrand" >> wrote: >>>>> On 04/12/2012 08:19 PM, Stephan Wenger wrote: >>>>>> Hi Harald, >>>>>> Thanks for this strawman. I believe it should work, but I fail to >>>>>> see how a two dimensional negotiation requirement (negotiating max >>>>>> values for framerate and image size--which, in turn, also has >>>>>> two-dimensional >>>>>> properties) leads to better interop than a one dimensional >>>>>> negotiation (pixels per second processing requirement). >>>>> Stephan, >>>>> >>>>> I do not see this (or the requirement from the use-cases document) >>>>> first and foremost a decoder complexity negotiation; it is a >>>>> negotiation of how much data it is useful to send, given the >>>>> recipient's intended use of that data. >>>> Then such a negotiation should be executed in addition. Decoder >>>> cycle requirement do matter in practical implementations. >>> Feel free to propose language that captures this requirement. As >> noted, >>> my I-D fragment doesn't. >>> >>> >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > From internet-drafts@ietf.org Tue Apr 17 04:56:49 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D2221F85FD; Tue, 17 Apr 2012 04:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9REAQpIO1gs; Tue, 17 Apr 2012 04:56:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D9421F85C9; Tue, 17 Apr 2012 04:56:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120417115644.14164.38458.idtracker@ietfa.amsl.com> Date: Tue, 17 Apr 2012 04:56:44 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-avt-rtp-isac-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 11:56:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Workin= g Group of the IETF. Title : RTP Payload Format for the iSAC Codec Author(s) : Tina le Grand Paul E. Jones Pascal Huart Harald Alvestrand Filename : draft-ietf-avt-rtp-isac-01.txt Pages : 10 Date : 2012-04-17 iSAC is a proprietary wideband speech and audio codec developed by Global IP Solutions, suitable for use in Voice over IP applications. This document describes the payload format for iSAC generated bit streams within a Real-Time Protocol (RTP) packet. Also included here are the necessary details for the use of iSAC with the Session Description Protocol (SDP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-isac-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-avt-rtp-isac-01.txt From harald@alvestrand.no Tue Apr 17 04:58:25 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A96E21F863F for ; Tue, 17 Apr 2012 04:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.466 X-Spam-Level: X-Spam-Status: No, score=-110.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXWnQtlDVWKt for ; Tue, 17 Apr 2012 04:58:24 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 25BAE21F8629 for ; Tue, 17 Apr 2012 04:58:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 37D9F39E11A for ; Tue, 17 Apr 2012 13:58:23 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWqSygT9Eh57 for ; Tue, 17 Apr 2012 13:58:22 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id C2BAD39E072 for ; Tue, 17 Apr 2012 13:58:22 +0200 (CEST) Message-ID: <4F8D5ADE.10400@alvestrand.no> Date: Tue, 17 Apr 2012 13:58:22 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: "payload@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [payload] Refresh of ISAC I-D X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 11:58:25 -0000 I have just submitted draft-ietf-avt-rtp-isac-01 to the I-D repositories. This is strictly a refresh, to make sure it is available in the I-D repositories; we will do another round to include the information on the superwideband mode before we ask the WG to consider the document again. Yours for the completion of pending issues, Harald Alvestrand From eckelcu@cisco.com Tue Apr 17 11:22:17 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07A521F84C5 for ; Tue, 17 Apr 2012 11:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3ZJ8zwUanwG for ; Tue, 17 Apr 2012 11:22:09 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 922E621F84B9 for ; Tue, 17 Apr 2012 11:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=eckelcu@cisco.com; l=10130; q=dns/txt; s=iport; t=1334686929; x=1335896529; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=onqog7i+RWbbreZ8Arr7QY8bDjipz0iwyrymGSOheXU=; b=jrONzRAtOcqJdSW5mQkIJ3xjGit9g+YQ+Z/97C+hsEybwfeS5trcLsb2 NCV84BHa3x+R3YOdnd2GqmwCwFgl0AvlXAGtIzxOTEAMO807Q+77Y97ap 2sVjCM2IcQb+/CeILGfUMH8dDA2EoN4W8MiHtsyFQpGS1jh1crXgdL8mm c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALmzjU+rRDoH/2dsb2JhbAA6CrE9gQeCCQEBAQQBAQEPAR0+CwwEAgEIEQQBAQEKBhMEAQYBJh8JCAEBBAESCBMHh2sBC5oNoAiKXAWFM2MEiCkzjiSNPIFpgweBNAEEAw X-IronPort-AV: E=Sophos;i="4.75,436,1330905600"; d="scan'208";a="40865360" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 17 Apr 2012 18:22:09 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3HIM9Zh003574; Tue, 17 Apr 2012 18:22:09 GMT Received: from xmb-sjc-234.amer.cisco.com ([128.107.191.111]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Apr 2012 11:22:08 -0700 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Apr 2012 11:22:07 -0700 Message-ID: In-Reply-To: <4F8D1FF0.5050002@logitech.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] VP8 payload, decoder processing capabilities (was Re: [rtcweb] Resolution negotiation - a contribution) Thread-Index: Ac0cbk+tpS/ZdU/nSSuR6gduVhlXsgAVxQbw References: <4F87D9B1.4000206@alvestrand.no> <4f8d1296.e950b40a.7abe.4224@mx.google.com> <4F8D1FF0.5050002@logitech.com> From: "Charles Eckel (eckelcu)" To: , "Roni Even" X-OriginalArrivalTime: 17 Apr 2012 18:22:08.0940 (UTC) FILETIME=[001A36C0:01CD1CC7] Cc: payload@ietf.org Subject: Re: [payload] VP8 payload, decoder processing capabilities (was Re: [rtcweb] Resolution negotiation - a contribution) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 18:22:17 -0000 If I understand correctly, one concern is that implementations of VP8 = will encounter similar problems to those of H.264 in terms of = negotiation of decoder capabilities. H.264 allows you to negotiate = max-mbps and max-fs for the maximum macroblocks per second and maximum = frame size, respectively. In theory, this should be sufficient. = Unfortunately, many real world implementations have limitations in terms = of max frame rate as well. While they can receive 1080p at 30 fps, they = cannot receive 360p at 60 fps, or 180p at 172 fps. These combinations = fall well within the max-mbps and max-fs limits, but they still are not = supported due to limitations of implementations. The proposal of the max-fps parameter for H.264 = (http://tools.ietf.org/html/draft-kristensen-avt-rtp-h241param-01) is a = response to this. It is a work in progress. It seems something similar may be necessary in practice for VP8. I agree with Tom that the existing max-framerate at the media line level = is not sufficient. Cheers, Charles > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf Of tom harper > Sent: Tuesday, April 17, 2012 12:47 AM > To: Roni Even > Cc: payload@ietf.org > Subject: Re: [payload] VP8 payload, decoder processing capabilities > (was Re: [rtcweb] Resolution negotiation - a contribution) >=20 > I understand where Harald is coming from, VP8 doesn't have the same > computational jump that h264 has between cavlc and cabac at the > decoder. With h264 this is important, as there are a bunch of = devices > that only do the former. I don't think this applies to vp8 that I = know > of. >=20 > So you don't need a level equivalent. However, I don't know that the > standards proposed by Harald do everything either. >=20 > Unless I misread, I think rfc 4566 a=3Dframerate is intended to be > defined > at the media level for all video media- For devices with a general > frame rate cap this is fine, but often you instead want a codec > specific > max frame rate, due to the varying complexities of differing codecs. > Also, it isn't clear to me from looking at the imageattr spec that you > can easily specify a range of resolutions other than listing them out > in > verbose detail. I don't think that is ideal either. And I might > ultimately have a frame rate constraint at a higher resolution that I > don't have at a lower one. So that wouldn't be clear using imageattr. >=20 > For the cases a=3Dframerate doesn't handle, there still needs to be = the > ability to negotiate a codec specific preferred max display size, as > well as the codec specific computational limit of decoding,. >=20 > So I would vote for a solution like maxmbps- the max complexity is = then > understood. Then I guess you would need a maxfs equivalent also. = Then > you could just allow the application to let the frame rate vary as > needed. >=20 > as me, >=20 > Tom >=20 > On 4/16/2012 11:48 PM, Roni Even wrote: > > Hi, > > I think that one point that is missing here is if the issue is only > for the > > receiver capability or request or if there is a need to specify also > the > > encoder capabilities. > > In H.264 (RFC6184) the level parameter signal the encoding and > decoding > > capability and the answers can signal a lower level (If asymmetry is > > supported). The level provides some maximum on what the receiver can > > request. > > I think that the image attribute does not provide this functionality > and I > > am not sure if this is the meaning of the SamplesPerSecond = parameter. > > > > I am keeping the discussion in payload WG > > > > Roni Even > > As individual > > > >> -----Original Message----- > >> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > >> Behalf Of Stephan Wenger > >> Sent: Tuesday, April 17, 2012 12:40 AM > >> To: Harald Alvestrand > >> Cc: rtcweb@ietf.org; payload@ietf.org > >> Subject: [payload] VP8 payload, decoder processing capabilities = (was > >> Re: [rtcweb] Resolution negotiation - a contribution) > >> > >> Hi all, > >> > >> For context: Harald and myself have been at odds for a while now > about > >> the lack of support for a code point in the VP8 payload that can be > >> used to negotiate a maximum decoder/bitstream complexity. > >> Specifically, Harald (and other VP8 payload folks) suggested that > >> generic mechanisms, such as the a=3Dframerate attribute of RFC4566 = in > >> conjunction with the picture size aspect of the imageattr of RFC > 6236 > >> can be used, at least in the rtcweb context. However, as far as I > >> understood our argument, these two mechanisms in combination are = not > >> meant as a limit for decoder complexity (in terms of samples/sec > >> processing rate), but rather as an indication, from receiver to > sender, > >> of an upper bound of what is "useful to send". > >> See the email below. To me, it's quite obvious that an indication > of > >> "useful to send" includes "my decoder can handle this"; however, it > >> could be more restrictive in that factors other than decoder > horsepower > >> could also be at play, such as screen size, user interface = settings, > >> and so on. > >> > >> I believe that the combination of what can be signaled using the > above > >> mechanisms should be sufficient for rtcweb. However, I also = believe > >> that it is insufficient for general purpose use, mostly because it > >> requires the support of RFC 6236, which is not exactly a widely > >> deployed technology. > >> Further, the a=3Dframerate attribute is not a particularly useful > >> attribute these days anymore, because variable frame rates, at = least > >> for software encoding/decoding, are the norm. > >> > >> In previous posts on the payload list (in response to the VP8 > payload > >> WGLC), I have commented on the practical shortcomings of the (lack > of) > >> complexity negotiation, and suggested that this needs to be fixed. > >> > >> Two options: > >> > >> 1) codify Harald's mechanism (based on a=3Dframerate and imageattr = in > the > >> VP8 payload draft, at MUST strength. "In a declarative context, a > >> prospective media sender supporting this (VP8 payload) = specification > >> MUST support RFC 4566 a=3Dframerate and RFC6236 imageattr, and MUST > >> include code points according to both mechanisms to identify the > >> properties of the media stream. In an offer-answer context, both > >> offerer and answerer receiver supporting this VP8 payload > specification > >> MUST support a=3Dframertate and imageattr, and MUST include both in > their > >> respective offer/answer messages, so to identify an operation point > >> that will not overload the media decoder's capabilities. > >> > >> The issue with this approach, IMO, is that we are dealing here with > >> three individual code points (framerate, horizontal and vertical > >> picture size), where a single code point ought to be sufficient for > >> determining whether a d=E9cor is capable of decoding a stream, at > least > >> from a complexity viewpoint). > >> > >> 2) include, in the V8 payload, a negotiable SDP code point > indicating > >> the complexity of a stream, in units of samples per second > processing > >> requirements or a derivative thereof (such as: levels as used in = the > >> MPEG world). For example, the VP8 payload could include a single, > >> optional, negotiable parameter "SamplePerSecond". If > SamplePerSecond > >> were absent in the SDP, a value of xxxxx must be inferred. (a > sensible > >> value for xxxxx could be, for example 9216000, which is the number > of > >> samples per second for VGA resolution at 30 Hz). If = SamplePerSecond > is > >> present in a declarative context, it indicates the minimum > processing > >> requirements a decoder must support in order to successfully decode > the > >> stream. In a symmetric offer-answer context, SamplePerSecond can = be > >> used to "dial down" > >> the complexity of the stream to a value that both encoder and > decoder > >> can support. > >> > >> My preference is obviously the second proposal, but I'm willing to > help > >> fleshing out either or both of them, just not today :-) > >> > >> Regards, > >> Stephan > >> > >> > >> > >> On 4.13.2012 00:45 , "Harald Alvestrand" > wrote: > >> > >>> On 04/12/2012 11:13 PM, Stephan Wenger wrote: > >>>> On 4.12.2012 12:08 , "Harald Alvestrand" > >> wrote: > >>>>> On 04/12/2012 08:19 PM, Stephan Wenger wrote: > >>>>>> Hi Harald, > >>>>>> Thanks for this strawman. I believe it should work, but I fail > to > >>>>>> see how a two dimensional negotiation requirement (negotiating > max > >>>>>> values for framerate and image size--which, in turn, also has > >>>>>> two-dimensional > >>>>>> properties) leads to better interop than a one dimensional > >>>>>> negotiation (pixels per second processing requirement). > >>>>> Stephan, > >>>>> > >>>>> I do not see this (or the requirement from the use-cases > document) > >>>>> first and foremost a decoder complexity negotiation; it is a > >>>>> negotiation of how much data it is useful to send, given the > >>>>> recipient's intended use of that data. > >>>> Then such a negotiation should be executed in addition. Decoder > >>>> cycle requirement do matter in practical implementations. > >>> Feel free to propose language that captures this requirement. As > >> noted, > >>> my I-D fragment doesn't. > >>> > >>> > >> > >> _______________________________________________ > >> payload mailing list > >> payload@ietf.org > >> https://www.ietf.org/mailman/listinfo/payload > > _______________________________________________ > > payload mailing list > > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From tharper@logitech.com Tue Apr 24 05:27:43 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBB021F8726 for ; Tue, 24 Apr 2012 05:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XK9mBisv61xl for ; Tue, 24 Apr 2012 05:27:42 -0700 (PDT) Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) by ietfa.amsl.com (Postfix) with ESMTP id 11F2621F8686 for ; Tue, 24 Apr 2012 05:27:41 -0700 (PDT) Received: from mail-pb0-f49.google.com ([209.85.160.49]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKT5acPSCGHB0bimfZCNQmOL9Y6pS1Wwf+@postini.com; Tue, 24 Apr 2012 05:27:42 PDT Received: by pbcun4 with SMTP id un4so37737pbc.8 for ; Tue, 24 Apr 2012 05:27:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=UbEDsBkem8/Kyqoo2EwTrCIjubFoXbar4UaUIJybnho=; b=BjvgD9yj+bA9UV9Cf2k9JgAWcxoiW7PAiyKqoyh38CtG+7Akril8cCioc1Eoy4qlf3 gSVIWm7klpnbIot6VUQW1Cvd3+xkaeRJdAh46iotFx3zTJH+yBTeh5M60crXZa7+s3VU t0/R2RSK67ryB35rSfU3qJ9qsnaHqIOABLn5RQJfnJwhQW2RnmFEvbuUbf/h7Zh4kTLd hmoTeToJaE03/5sJ86eax4LALZrsEm0yJFRJFg5aBuh414Z+NDZki6dvdcE+xQCuJF1D chQGjhL5XGLzEFR2EgFn74BAESnkvGoaeDiZ/qI1y7DIiZBcCTFH4Lsj2t69D5EXX5FM gAUw== Received: by 10.68.131.106 with SMTP id ol10mr3616450pbb.40.1335270460550; Tue, 24 Apr 2012 05:27:40 -0700 (PDT) Received: from [172.19.173.134] (c-76-126-8-251.hsd1.ca.comcast.net. [76.126.8.251]) by mx.google.com with ESMTPS id pg1sm17315988pbc.21.2012.04.24.05.27.38 (version=SSLv3 cipher=OTHER); Tue, 24 Apr 2012 05:27:39 -0700 (PDT) Message-ID: <4F969A29.3040908@logitech.com> Date: Tue, 24 Apr 2012 05:18:49 -0700 From: tom harper User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: payload@ietf.org References: <4F87D9B1.4000206@alvestrand.no> <4f8d1296.e950b40a.7abe.4224@mx.google.com> <4F8D1FF0.5050002@logitech.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQkcHbWRnFeIKcQu9T8ExIC/Y04ObJIhGrS/+ORsR2UPhLjXzvA2k/NLocw7bjCeTjgXFIKg Subject: Re: [payload] VP8 payload, decoder processing capabilities (was Re: [rtcweb] Resolution negotiation - a contribution) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: tharper@logitech.com List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 12:27:43 -0000 I think the max-fps might be what is needed. A general frame rate display limitation with a device ( i.e. it can only do 15, 30 fps) such as a phone could just use frame rate the way Harald described on the media line- the case of I can do VGA-30 (but not 120 fps) and I can do 720p-30. What this would not handle would be if there is some other overall processing cap that is codec specific, and your cpu/hardware could do 720p 30 and 1080p 15, but 60 is your max due to some programmatic limitation or choice. You could in theory do it with the max-fps parameter in the following manner- Using maxmbps/maxfs, infer the maximum codec frame rate at the maximum resolution to be max-mbps/max-fs. Then you need a max-fps parameter to cap your max framerate at lower resolutions. You could infer the max framerate in between by calculating the max-mbps/max-fs ratio, assuming it is linear. You could make max-fps optional by having a default max-fps = max-mbps/max-fs. The above should in theory cover multiple video streams also, where each stream's capability could be shaped. If there is a more complicated use case you would have to probably specify exact resolution/frame rate combos, it would be optional, so probably doesn't need to be specified here. Tom On 4/17/2012 11:22 AM, Charles Eckel (eckelcu) wrote: > If I understand correctly, one concern is that implementations of VP8 will encounter similar problems to those of H.264 in terms of negotiation of decoder capabilities. H.264 allows you to negotiate max-mbps and max-fs for the maximum macroblocks per second and maximum frame size, respectively. In theory, this should be sufficient. Unfortunately, many real world implementations have limitations in terms of max frame rate as well. While they can receive 1080p at 30 fps, they cannot receive 360p at 60 fps, or 180p at 172 fps. These combinations fall well within the max-mbps and max-fs limits, but they still are not supported due to limitations of implementations. > The proposal of the max-fps parameter for H.264 (http://tools.ietf.org/html/draft-kristensen-avt-rtp-h241param-01) is a response to this. It is a work in progress. > It seems something similar may be necessary in practice for VP8. > I agree with Tom that the existing max-framerate at the media line level is not sufficient. > > Cheers, > Charles > >> -----Original Message----- >> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On >> Behalf Of tom harper >> Sent: Tuesday, April 17, 2012 12:47 AM >> To: Roni Even >> Cc: payload@ietf.org >> Subject: Re: [payload] VP8 payload, decoder processing capabilities >> (was Re: [rtcweb] Resolution negotiation - a contribution) >> >> I understand where Harald is coming from, VP8 doesn't have the same >> computational jump that h264 has between cavlc and cabac at the >> decoder. With h264 this is important, as there are a bunch of devices >> that only do the former. I don't think this applies to vp8 that I know >> of. >> >> So you don't need a level equivalent. However, I don't know that the >> standards proposed by Harald do everything either. >> >> Unless I misread, I think rfc 4566 a=framerate is intended to be >> defined >> at the media level for all video media- For devices with a general >> frame rate cap this is fine, but often you instead want a codec >> specific >> max frame rate, due to the varying complexities of differing codecs. >> Also, it isn't clear to me from looking at the imageattr spec that you >> can easily specify a range of resolutions other than listing them out >> in >> verbose detail. I don't think that is ideal either. And I might >> ultimately have a frame rate constraint at a higher resolution that I >> don't have at a lower one. So that wouldn't be clear using imageattr. >> >> For the cases a=framerate doesn't handle, there still needs to be the >> ability to negotiate a codec specific preferred max display size, as >> well as the codec specific computational limit of decoding,. >> >> So I would vote for a solution like maxmbps- the max complexity is then >> understood. Then I guess you would need a maxfs equivalent also. Then >> you could just allow the application to let the frame rate vary as >> needed. >> >> as me, >> >> Tom >> >> On 4/16/2012 11:48 PM, Roni Even wrote: >>> Hi, >>> I think that one point that is missing here is if the issue is only >> for the >>> receiver capability or request or if there is a need to specify also >> the >>> encoder capabilities. >>> In H.264 (RFC6184) the level parameter signal the encoding and >> decoding >>> capability and the answers can signal a lower level (If asymmetry is >>> supported). The level provides some maximum on what the receiver can >>> request. >>> I think that the image attribute does not provide this functionality >> and I >>> am not sure if this is the meaning of the SamplesPerSecond parameter. >>> >>> I am keeping the discussion in payload WG >>> >>> Roni Even >>> As individual >>> >>>> -----Original Message----- >>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On >>>> Behalf Of Stephan Wenger >>>> Sent: Tuesday, April 17, 2012 12:40 AM >>>> To: Harald Alvestrand >>>> Cc: rtcweb@ietf.org; payload@ietf.org >>>> Subject: [payload] VP8 payload, decoder processing capabilities (was >>>> Re: [rtcweb] Resolution negotiation - a contribution) >>>> >>>> Hi all, >>>> >>>> For context: Harald and myself have been at odds for a while now >> about >>>> the lack of support for a code point in the VP8 payload that can be >>>> used to negotiate a maximum decoder/bitstream complexity. >>>> Specifically, Harald (and other VP8 payload folks) suggested that >>>> generic mechanisms, such as the a=framerate attribute of RFC4566 in >>>> conjunction with the picture size aspect of the imageattr of RFC >> 6236 >>>> can be used, at least in the rtcweb context. However, as far as I >>>> understood our argument, these two mechanisms in combination are not >>>> meant as a limit for decoder complexity (in terms of samples/sec >>>> processing rate), but rather as an indication, from receiver to >> sender, >>>> of an upper bound of what is "useful to send". >>>> See the email below. To me, it's quite obvious that an indication >> of >>>> "useful to send" includes "my decoder can handle this"; however, it >>>> could be more restrictive in that factors other than decoder >> horsepower >>>> could also be at play, such as screen size, user interface settings, >>>> and so on. >>>> >>>> I believe that the combination of what can be signaled using the >> above >>>> mechanisms should be sufficient for rtcweb. However, I also believe >>>> that it is insufficient for general purpose use, mostly because it >>>> requires the support of RFC 6236, which is not exactly a widely >>>> deployed technology. >>>> Further, the a=framerate attribute is not a particularly useful >>>> attribute these days anymore, because variable frame rates, at least >>>> for software encoding/decoding, are the norm. >>>> >>>> In previous posts on the payload list (in response to the VP8 >> payload >>>> WGLC), I have commented on the practical shortcomings of the (lack >> of) >>>> complexity negotiation, and suggested that this needs to be fixed. >>>> >>>> Two options: >>>> >>>> 1) codify Harald's mechanism (based on a=framerate and imageattr in >> the >>>> VP8 payload draft, at MUST strength. "In a declarative context, a >>>> prospective media sender supporting this (VP8 payload) specification >>>> MUST support RFC 4566 a=framerate and RFC6236 imageattr, and MUST >>>> include code points according to both mechanisms to identify the >>>> properties of the media stream. In an offer-answer context, both >>>> offerer and answerer receiver supporting this VP8 payload >> specification >>>> MUST support a=framertate and imageattr, and MUST include both in >> their >>>> respective offer/answer messages, so to identify an operation point >>>> that will not overload the media decoder's capabilities. >>>> >>>> The issue with this approach, IMO, is that we are dealing here with >>>> three individual code points (framerate, horizontal and vertical >>>> picture size), where a single code point ought to be sufficient for >>>> determining whether a décor is capable of decoding a stream, at >> least >>>> from a complexity viewpoint). >>>> >>>> 2) include, in the V8 payload, a negotiable SDP code point >> indicating >>>> the complexity of a stream, in units of samples per second >> processing >>>> requirements or a derivative thereof (such as: levels as used in the >>>> MPEG world). For example, the VP8 payload could include a single, >>>> optional, negotiable parameter "SamplePerSecond". If >> SamplePerSecond >>>> were absent in the SDP, a value of xxxxx must be inferred. (a >> sensible >>>> value for xxxxx could be, for example 9216000, which is the number >> of >>>> samples per second for VGA resolution at 30 Hz). If SamplePerSecond >> is >>>> present in a declarative context, it indicates the minimum >> processing >>>> requirements a decoder must support in order to successfully decode >> the >>>> stream. In a symmetric offer-answer context, SamplePerSecond can be >>>> used to "dial down" >>>> the complexity of the stream to a value that both encoder and >> decoder >>>> can support. >>>> >>>> My preference is obviously the second proposal, but I'm willing to >> help >>>> fleshing out either or both of them, just not today :-) >>>> >>>> Regards, >>>> Stephan >>>> >>>> >>>> >>>> On 4.13.2012 00:45 , "Harald Alvestrand" >> wrote: >>>>> On 04/12/2012 11:13 PM, Stephan Wenger wrote: >>>>>> On 4.12.2012 12:08 , "Harald Alvestrand" >>>> wrote: >>>>>>> On 04/12/2012 08:19 PM, Stephan Wenger wrote: >>>>>>>> Hi Harald, >>>>>>>> Thanks for this strawman. I believe it should work, but I fail >> to >>>>>>>> see how a two dimensional negotiation requirement (negotiating >> max >>>>>>>> values for framerate and image size--which, in turn, also has >>>>>>>> two-dimensional >>>>>>>> properties) leads to better interop than a one dimensional >>>>>>>> negotiation (pixels per second processing requirement). >>>>>>> Stephan, >>>>>>> >>>>>>> I do not see this (or the requirement from the use-cases >> document) >>>>>>> first and foremost a decoder complexity negotiation; it is a >>>>>>> negotiation of how much data it is useful to send, given the >>>>>>> recipient's intended use of that data. >>>>>> Then such a negotiation should be executed in addition. Decoder >>>>>> cycle requirement do matter in practical implementations. >>>>> Feel free to propose language that captures this requirement. As >>>> noted, >>>>> my I-D fragment doesn't. >>>>> >>>>> >>>> _______________________________________________ >>>> payload mailing list >>>> payload@ietf.org >>>> https://www.ietf.org/mailman/listinfo/payload >>> _______________________________________________ >>> payload mailing list >>> payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload >>> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload From ron.even.tlv@gmail.com Tue Apr 24 13:39:55 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C18C21E802C for ; Tue, 24 Apr 2012 13:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.907 X-Spam-Level: X-Spam-Status: No, score=-2.907 tagged_above=-999 required=5 tests=[AWL=-0.508, BAYES_00=-2.599, J_CHICKENPOX_110=0.6, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piUcfxQfEAYQ for ; Tue, 24 Apr 2012 13:39:54 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id A09A221E801F for ; Tue, 24 Apr 2012 13:39:53 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so885737wib.13 for ; Tue, 24 Apr 2012 13:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=gPVlIWIbNQ04aT05B4T3vIV1RGYCh/QbHJhp/MAvikE=; b=x1N2LvTeRZIjGfIkXX1zTIS3XzJo3JQZD/iJzTgF5SttF1Ll6y8XSPYeDinf94Fz1U WleHLmiaNj8PwTTcOIRRECgMC9CJrfhCSG3rFEMZhqO9GEpM+QLz2d27QxfTq59AjEIA 1A+5wdNpLxClTFZ94JlBJtcqJn1db00pIXcgrCY7C+Loj8qcTYdGUCf8mPuycSqbgO2F GfaVcNE0Q0seiFUC8khXY2syZEL76r2mNA22koMIdLp5J5zribDpdAywFSfdz4k7gQul vYrq9nQory/PRTTKIHKpKfvmqYDPGb90R/dpeBxJJTrCXeo/ZatBRfatpQATkvjwwL2O iLmw== Received: by 10.216.139.156 with SMTP id c28mr13105716wej.57.1335299992739; Tue, 24 Apr 2012 13:39:52 -0700 (PDT) Received: from windows8d787f9 ([109.65.204.117]) by mx.google.com with ESMTPS id j3sm50397685wiw.1.2012.04.24.13.39.49 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Apr 2012 13:39:50 -0700 (PDT) From: "Roni Even" To: , References: <4F87D9B1.4000206@alvestrand.no> <4f8d1296.e950b40a.7abe.4224@mx.google.com> <4F8D1FF0.5050002@logitech.com> <4F969A29.3040908@logitech.com> In-Reply-To: <4F969A29.3040908@logitech.com> Date: Tue, 24 Apr 2012 23:38:08 +0300 Message-ID: <4f970f96.634cb40a.7e67.ffff8a0e@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0iFadLNN0m/oe4T6arlG46xkwrFgAQug0Q Content-Language: en-us Subject: Re: [payload] VP8 payload, decoder processing capabilities (was Re: [rtcweb] Resolution negotiation - a contribution) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 20:39:55 -0000 Hi, I would like to explain why we have the maxmbps, maxfs, and all these parameters for H.264 at least my view. ITU-T H.264 tables A.1 and A.6 define the level values and as such they = also define the maximum resolution allowed for each level and the maximum = decoded picture buffer size and the maximum video bit rate. Now when an endpoint claims to support a level it must support all parameters. Now according = to table A.6 if you want to support 1080HD video you must support level 4 = which mean you also support video bit rate of 20Mbit/s and 30 frames per = second. Using only the level parameter you cannot say that you support a lower = level but have larger decoded picture buffer size that will allow you to = support 1080HD video at 15fps for example.=20 As for the VP8 case note also the need to know the maximum frame size = which is important for the required decoded picture buffer size. This may look = not important for low resolution but when you go to high resolution (even = higher than HD) it may also become a limitation.=20 Roni Even As individual > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf Of tom harper > Sent: Tuesday, April 24, 2012 3:19 PM > To: payload@ietf.org > Subject: Re: [payload] VP8 payload, decoder processing capabilities > (was Re: [rtcweb] Resolution negotiation - a contribution) >=20 > I think the max-fps might be what is needed. >=20 > A general frame rate display limitation with a device ( i.e. it can > only do 15, 30 fps) such as a phone could just use frame rate the way > Harald described on the media line- the case of I can do VGA-30 (but > not 120 > fps) and I can do 720p-30. >=20 > What this would not handle would be if there is some other overall > processing cap that is codec specific, and your cpu/hardware could do > 720p 30 and 1080p 15, but 60 is your max due to some programmatic > limitation or choice. >=20 > You could in theory do it with the max-fps parameter in the following > manner- Using maxmbps/maxfs, infer the maximum codec frame rate at the > maximum resolution to be max-mbps/max-fs. Then you need a max-fps > parameter to cap your max framerate at lower resolutions. You could > infer the max framerate in between by calculating the max-mbps/max-fs > ratio, assuming it is linear. >=20 > You could make max-fps optional by having a default max-fps =3D max- > mbps/max-fs. >=20 > The above should in theory cover multiple video streams also, where > each stream's capability could be shaped. >=20 > If there is a more complicated use case you would have to probably > specify exact resolution/frame rate combos, it would be optional, so > probably doesn't need to be specified here. >=20 > Tom >=20 >=20 > On 4/17/2012 11:22 AM, Charles Eckel (eckelcu) wrote: > > If I understand correctly, one concern is that implementations of = VP8 > will encounter similar problems to those of H.264 in terms of > negotiation of decoder capabilities. H.264 allows you to negotiate = max- > mbps and max-fs for the maximum macroblocks per second and maximum > frame size, respectively. In theory, this should be sufficient. > Unfortunately, many real world implementations have limitations in > terms of max frame rate as well. While they can receive 1080p at 30 > fps, they cannot receive 360p at 60 fps, or 180p at 172 fps. These > combinations fall well within the max-mbps and max-fs limits, but they > still are not supported due to limitations of implementations. > > The proposal of the max-fps parameter for H.264 > (http://tools.ietf.org/html/draft-kristensen-avt-rtp-h241param-01) is = a > response to this. It is a work in progress. > > It seems something similar may be necessary in practice for VP8. > > I agree with Tom that the existing max-framerate at the media line > level is not sufficient. > > > > Cheers, > > Charles > > > >> -----Original Message----- > >> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > >> Behalf Of tom harper > >> Sent: Tuesday, April 17, 2012 12:47 AM > >> To: Roni Even > >> Cc: payload@ietf.org > >> Subject: Re: [payload] VP8 payload, decoder processing capabilities > >> (was Re: [rtcweb] Resolution negotiation - a contribution) > >> > >> I understand where Harald is coming from, VP8 doesn't have the same > >> computational jump that h264 has between cavlc and cabac at the > >> decoder. With h264 this is important, as there are a bunch of > devices > >> that only do the former. I don't think this applies to vp8 that I > >> know of. > >> > >> So you don't need a level equivalent. However, I don't know that > the > >> standards proposed by Harald do everything either. > >> > >> Unless I misread, I think rfc 4566 a=3Dframerate is intended to be > >> defined at the media level for all video media- For devices with a > >> general frame rate cap this is fine, but often you instead want a > >> codec specific max frame rate, due to the varying complexities of > >> differing codecs. > >> Also, it isn't clear to me from looking at the imageattr spec that > >> you can easily specify a range of resolutions other than listing > them > >> out in verbose detail. I don't think that is ideal either. And I > >> might ultimately have a frame rate constraint at a higher = resolution > >> that I don't have at a lower one. So that wouldn't be clear using > >> imageattr. > >> > >> For the cases a=3Dframerate doesn't handle, there still needs to be > the > >> ability to negotiate a codec specific preferred max display size, = as > >> well as the codec specific computational limit of decoding,. > >> > >> So I would vote for a solution like maxmbps- the max complexity is > >> then understood. Then I guess you would need a maxfs equivalent > >> also. Then you could just allow the application to let the frame > >> rate vary as needed. > >> > >> as me, > >> > >> Tom > >> > >> On 4/16/2012 11:48 PM, Roni Even wrote: > >>> Hi, > >>> I think that one point that is missing here is if the issue is = only > >> for the > >>> receiver capability or request or if there is a need to specify > also > >> the > >>> encoder capabilities. > >>> In H.264 (RFC6184) the level parameter signal the encoding and > >> decoding > >>> capability and the answers can signal a lower level (If asymmetry > is > >>> supported). The level provides some maximum on what the receiver > can > >>> request. > >>> I think that the image attribute does not provide this > functionality > >> and I > >>> am not sure if this is the meaning of the SamplesPerSecond > parameter. > >>> > >>> I am keeping the discussion in payload WG > >>> > >>> Roni Even > >>> As individual > >>> > >>>> -----Original Message----- > >>>> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] > On > >>>> Behalf Of Stephan Wenger > >>>> Sent: Tuesday, April 17, 2012 12:40 AM > >>>> To: Harald Alvestrand > >>>> Cc: rtcweb@ietf.org; payload@ietf.org > >>>> Subject: [payload] VP8 payload, decoder processing capabilities > >>>> (was > >>>> Re: [rtcweb] Resolution negotiation - a contribution) > >>>> > >>>> Hi all, > >>>> > >>>> For context: Harald and myself have been at odds for a while now > >> about > >>>> the lack of support for a code point in the VP8 payload that can > be > >>>> used to negotiate a maximum decoder/bitstream complexity. > >>>> Specifically, Harald (and other VP8 payload folks) suggested that > >>>> generic mechanisms, such as the a=3Dframerate attribute of = RFC4566 > in > >>>> conjunction with the picture size aspect of the imageattr of RFC > >> 6236 > >>>> can be used, at least in the rtcweb context. However, as far as = I > >>>> understood our argument, these two mechanisms in combination are > >>>> not meant as a limit for decoder complexity (in terms of > >>>> samples/sec processing rate), but rather as an indication, from > >>>> receiver to > >> sender, > >>>> of an upper bound of what is "useful to send". > >>>> See the email below. To me, it's quite obvious that an = indication > >> of > >>>> "useful to send" includes "my decoder can handle this"; however, > it > >>>> could be more restrictive in that factors other than decoder > >> horsepower > >>>> could also be at play, such as screen size, user interface > >>>> settings, and so on. > >>>> > >>>> I believe that the combination of what can be signaled using the > >> above > >>>> mechanisms should be sufficient for rtcweb. However, I also > >>>> believe that it is insufficient for general purpose use, mostly > >>>> because it requires the support of RFC 6236, which is not exactly > a > >>>> widely deployed technology. > >>>> Further, the a=3Dframerate attribute is not a particularly useful > >>>> attribute these days anymore, because variable frame rates, at > >>>> least for software encoding/decoding, are the norm. > >>>> > >>>> In previous posts on the payload list (in response to the VP8 > >> payload > >>>> WGLC), I have commented on the practical shortcomings of the = (lack > >> of) > >>>> complexity negotiation, and suggested that this needs to be = fixed. > >>>> > >>>> Two options: > >>>> > >>>> 1) codify Harald's mechanism (based on a=3Dframerate and = imageattr > in > >> the > >>>> VP8 payload draft, at MUST strength. "In a declarative context, = a > >>>> prospective media sender supporting this (VP8 payload) > >>>> specification MUST support RFC 4566 a=3Dframerate and RFC6236 > >>>> imageattr, and MUST include code points according to both > >>>> mechanisms to identify the properties of the media stream. In an > >>>> offer-answer context, both offerer and answerer receiver > supporting > >>>> this VP8 payload > >> specification > >>>> MUST support a=3Dframertate and imageattr, and MUST include both = in > >> their > >>>> respective offer/answer messages, so to identify an operation > point > >>>> that will not overload the media decoder's capabilities. > >>>> > >>>> The issue with this approach, IMO, is that we are dealing here > with > >>>> three individual code points (framerate, horizontal and vertical > >>>> picture size), where a single code point ought to be sufficient > for > >>>> determining whether a d=E9cor is capable of decoding a stream, at > >> least > >>>> from a complexity viewpoint). > >>>> > >>>> 2) include, in the V8 payload, a negotiable SDP code point > >> indicating > >>>> the complexity of a stream, in units of samples per second > >> processing > >>>> requirements or a derivative thereof (such as: levels as used in > >>>> the MPEG world). For example, the VP8 payload could include a > >>>> single, optional, negotiable parameter "SamplePerSecond". If > >> SamplePerSecond > >>>> were absent in the SDP, a value of xxxxx must be inferred. (a > >> sensible > >>>> value for xxxxx could be, for example 9216000, which is the = number > >> of > >>>> samples per second for VGA resolution at 30 Hz). If > >>>> SamplePerSecond > >> is > >>>> present in a declarative context, it indicates the minimum > >> processing > >>>> requirements a decoder must support in order to successfully > decode > >> the > >>>> stream. In a symmetric offer-answer context, SamplePerSecond can > >>>> be used to "dial down" > >>>> the complexity of the stream to a value that both encoder and > >> decoder > >>>> can support. > >>>> > >>>> My preference is obviously the second proposal, but I'm willing = to > >> help > >>>> fleshing out either or both of them, just not today :-) > >>>> > >>>> Regards, > >>>> Stephan > >>>> > >>>> > >>>> > >>>> On 4.13.2012 00:45 , "Harald Alvestrand" > >> wrote: > >>>>> On 04/12/2012 11:13 PM, Stephan Wenger wrote: > >>>>>> On 4.12.2012 12:08 , "Harald Alvestrand" > >>>> wrote: > >>>>>>> On 04/12/2012 08:19 PM, Stephan Wenger wrote: > >>>>>>>> Hi Harald, > >>>>>>>> Thanks for this strawman. I believe it should work, but I > fail > >> to > >>>>>>>> see how a two dimensional negotiation requirement = (negotiating > >> max > >>>>>>>> values for framerate and image size--which, in turn, also has > >>>>>>>> two-dimensional > >>>>>>>> properties) leads to better interop than a one dimensional > >>>>>>>> negotiation (pixels per second processing requirement). > >>>>>>> Stephan, > >>>>>>> > >>>>>>> I do not see this (or the requirement from the use-cases > >> document) > >>>>>>> first and foremost a decoder complexity negotiation; it is a > >>>>>>> negotiation of how much data it is useful to send, given the > >>>>>>> recipient's intended use of that data. > >>>>>> Then such a negotiation should be executed in addition. = Decoder > >>>>>> cycle requirement do matter in practical implementations. > >>>>> Feel free to propose language that captures this requirement. As > >>>> noted, > >>>>> my I-D fragment doesn't. > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> payload mailing list > >>>> payload@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/payload > >>> _______________________________________________ > >>> payload mailing list > >>> payload@ietf.org > >>> https://www.ietf.org/mailman/listinfo/payload > >>> > >> _______________________________________________ > >> payload mailing list > >> payload@ietf.org > >> https://www.ietf.org/mailman/listinfo/payload > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From macinnis@broadcom.com Tue Apr 24 14:31:46 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBECE21E8015 for ; Tue, 24 Apr 2012 14:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51XvCQ6hysBQ for ; Tue, 24 Apr 2012 14:31:46 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4026F21E8012 for ; Tue, 24 Apr 2012 14:31:46 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 24 Apr 2012 14:31:40 -0700 X-Server-Uuid: B730DE51-FC43-4C83-941F-F1F78A914BDD Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.15) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Tue, 24 Apr 2012 14:31:39 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS06.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Tue, 24 Apr 2012 14:31:38 -0700 From: "Sandy (Alexander) MacInnis" To: "payload@ietf.org" Thread-Topic: [payload] VP8 payload, decoder processing capabilities Thread-Index: AQHNImGhsZ9OQporJkCSSBvwnJv8jA== Date: Tue, 24 Apr 2012 21:31:38 +0000 Message-ID: <5B1A263B43E389479AB3DAC1EAF0C8F5024458@SJEXCHMB12.corp.ad.broadcom.com> References: <4F87D9B1.4000206@alvestrand.no> <4f8d1296.e950b40a.7abe.4224@mx.google.com> <4F8D1FF0.5050002@logitech.com> <4F969A29.3040908@logitech.com> <4f970f96.634cb40a.7e67.ffff8a0e@mx.google.com> In-Reply-To: <4f970f96.634cb40a.7e67.ffff8a0e@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.240.253.73] MIME-Version: 1.0 X-WSS-ID: 6389C4363E022582980-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [payload] VP8 payload, decoder processing capabilities X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 21:31:46 -0000 I have another question about this. Background: In the VP8 bitstream spec, and in the payload draft, the use of multiple co= efficient partitions is optional and not required.=20 A VP8 decoder might use multi-threaded processing, such that it can achieve= significantly greater throughput by decoding multiple coefficient partitio= ns in parallel. Such a decoder might rely on the presence of a certain numb= er of coefficient partitions in order to achieve a certain level of through= put. For example, some receiver might comprise a multi-threaded decoder that can= decode 1920x1080p60 if the stream has at least four coefficient partitions= , but if the stream has only one coefficient partition it might be limited = to a significantly smaller product of frame size and frame rate. Question: With the current draft, how does a multi-threaded decoder know in= advance how many coefficient partitions the stream uses, so it can decide = whether it can decode a stream of a given frame size and frame rate? Or doe= s this aspect not matter? --Sandy (Alexander) MacInnis Broadcom [...older parts of thread deleted...] From olivier.crete@collabora.com Tue Apr 24 14:41:02 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7351B21F854F for ; Tue, 24 Apr 2012 14:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v15jrhUuWxxN for ; Tue, 24 Apr 2012 14:41:01 -0700 (PDT) Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [93.93.135.160]) by ietfa.amsl.com (Postfix) with ESMTP id 82A8621F854B for ; Tue, 24 Apr 2012 14:41:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: tester) with ESMTPSA id 2CC2E600169 Message-ID: <1335303658.1928.3.camel@TesterTop4> From: Olivier =?ISO-8859-1?Q?Cr=EAte?= To: payload@ietf.org Date: Tue, 24 Apr 2012 17:40:58 -0400 In-Reply-To: <5B1A263B43E389479AB3DAC1EAF0C8F5024458@SJEXCHMB12.corp.ad.broadcom.com> References: <4F87D9B1.4000206@alvestrand.no> <4f8d1296.e950b40a.7abe.4224@mx.google.com> <4F8D1FF0.5050002@logitech.com> <4F969A29.3040908@logitech.com> <4f970f96.634cb40a.7e67.ffff8a0e@mx.google.com> <5B1A263B43E389479AB3DAC1EAF0C8F5024458@SJEXCHMB12.corp.ad.broadcom.com> Organization: Collabora Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-8o5uZaETdtNYaNV1vXE7" X-Mailer: Evolution 3.2.3 (3.2.3-2.fc16) Mime-Version: 1.0 Subject: Re: [payload] VP8 payload, decoder processing capabilities X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 21:41:02 -0000 --=-8o5uZaETdtNYaNV1vXE7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2012-04-24 at 21:31 +0000, Sandy (Alexander) MacInnis wrote: > I have another question about this. >=20 > Background: > In the VP8 bitstream spec, and in the payload draft, the use of multiple = coefficient partitions is optional and not required.=20 >=20 > A VP8 decoder might use multi-threaded processing, such that it can achie= ve significantly greater throughput by decoding multiple coefficient partit= ions in parallel. Such a decoder might rely on the presence of a certain nu= mber of coefficient partitions in order to achieve a certain level of throu= ghput. >=20 > For example, some receiver might comprise a multi-threaded decoder that c= an decode 1920x1080p60 if the stream has at least four coefficient partitio= ns, but if the stream has only one coefficient partition it might be limite= d to a significantly smaller product of frame size and frame rate. >=20 > Question: With the current draft, how does a multi-threaded decoder know = in advance how many coefficient partitions the stream uses, so it can decid= e whether it can decode a stream of a given frame size and frame rate? Or d= oes this aspect not matter? I think the receiver should include all of that in its SDP, maybe something like: SamplesPerCoefficientPartition=3DX MaxParallelCoeffficientPartitions=3DY That said, I'm concerned that all of this is a really static view of things, which is useful on a fixed device. But is completely pointless when writing software that runs on a general purpose computer (such as a desktop or a smartphone), in which case we want something more dynamic. So maybe all of this discussion is mostly pointless and we should push for a more dynamic solution (maybe some kind of RTCP feedback?) --=20 Olivier Cr=C3=AAte olivier.crete@collabora.com --=-8o5uZaETdtNYaNV1vXE7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEABECAAYFAk+XHeoACgkQHTiOWk7ZorvPRQCeMv6XlOVG3c77+2m7oVS6mFfU LB4An25QO74CJCda/fXPinpEpTPkidhA =YdHg -----END PGP SIGNATURE----- --=-8o5uZaETdtNYaNV1vXE7-- From macinnis@broadcom.com Wed Apr 25 09:26:15 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6547021F866D for ; Wed, 25 Apr 2012 09:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mFUWurDB++i for ; Wed, 25 Apr 2012 09:26:14 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by ietfa.amsl.com (Postfix) with ESMTP id ED8E621F8668 for ; Wed, 25 Apr 2012 09:26:13 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Wed, 25 Apr 2012 09:26:06 -0700 X-Server-Uuid: B730DE51-FC43-4C83-941F-F1F78A914BDD Received: from SJEXCHCAS02.corp.ad.broadcom.com (10.16.192.37) by SJEXCHHUB01.corp.ad.broadcom.com (10.16.192.224) with Microsoft SMTP Server (TLS) id 8.2.247.2; Wed, 25 Apr 2012 09:26:04 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by sjexchcas02.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0355.002; Wed, 25 Apr 2012 09:26:03 -0700 From: "Sandy (Alexander) MacInnis" To: "payload@ietf.org" , =?utf-8?B?T2xpdmllciBDcsOqdGU=?= Thread-Topic: [payload] VP8 payload, decoder processing capabilities Thread-Index: AQHNImGsXgcarpaDUUCO3CZpwEnVYZaq9nMAgADA/nA= Date: Wed, 25 Apr 2012 16:26:02 +0000 Message-ID: <5B1A263B43E389479AB3DAC1EAF0C8F5025DC5@SJEXCHMB12.corp.ad.broadcom.com> References: <4F87D9B1.4000206@alvestrand.no> <4f8d1296.e950b40a.7abe.4224@mx.google.com> <4F8D1FF0.5050002@logitech.com> <4F969A29.3040908@logitech.com> <4f970f96.634cb40a.7e67.ffff8a0e@mx.google.com> <5B1A263B43E389479AB3DAC1EAF0C8F5024458@SJEXCHMB12.corp.ad.broadcom.com> <1335303658.1928.3.camel@TesterTop4> In-Reply-To: <1335303658.1928.3.camel@TesterTop4> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.240.253.102] MIME-Version: 1.0 X-WSS-ID: 6386FA143E023004907-01-01 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Subject: Re: [payload] VP8 payload, decoder processing capabilities X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 16:26:15 -0000 VGhhbmtzIE9saXZpZXIuDQoNCkkgd2FzIGhvcGluZyB0byBoZWFyIGZyb20gc29tZW9uZSBhdCBH b29nbGUgYWJvdXQgdGhpcy4NCg0KQlRXLCB0aGVyZSBtaWdodCBiZSBhIG1pc3VuZGVyc3RhbmRp bmcgaGVyZS4gV2hhdCBJIGhhdmUgaW4gbWluZCBpcyB0aGF0IGEgc2VuZGVyIHdvdWxkIG9mZmVy IGEgc3RyZWFtIGluZGljYXRpbmcgaG93IG1hbnkgY29lZmZpY2llbnQgcGFydGl0aW9ucyB0aGF0 IHN0cmVhbSB1c2VzLCBhbG9uZyB3aXRoIHRoZSBmcmFtZSBzaXplIGFuZCByYXRlIChvciB3aGF0 ZXZlciBhbHRlcm5hdGl2ZSBzdWNoIGFzIHBpeGVsIHJhdGUgb3IgbWFjcm9ibG9jayByYXRlIHRo ZSBncm91cCBkZWNpZGVzIG9uKS4gQSByZWNlaXZlciB3b3VsZCBiZSBhYmxlIHRvIGRlY2lkZSBi YXNlZCBvbiB0aGlzIGluZm9ybWF0aW9uIHdoZXRoZXIgb3Igbm90IGl0IGNhbiBkZWNvZGUgdGhl IHN0cmVhbS4gVGhlIHJlY2VpdmVyIG1pZ2h0IG5lZWQgYXQgbGVhc3QgYSBjZXJ0YWluIG51bWJl ciBvZiBjb2VmZmljaWVudCBwYXJ0aXRpb25zIHRvIGJlIGFibGUgdG8gZGVjb2RlIGEgc3RyZWFt IHdpdGggYSBjZXJ0YWluIGZyYW1lIHNpemUgJiByYXRlLiANCg0KTm90ZSAxOiBUaGlzIGRvZXMg bm90IGFwcGx5IHRvIGFsbCByZWNlaXZlcnMsIGJ1dCBpdCBtaWdodCBhcHBseSB0byBzb21lLiAN Cg0KTm90ZSAyOiBJZiB0aGUgc3RyZWFtIGhhcyBtb3JlIGNvZWZmaWNpZW50IHBhcnRpdGlvbnMg dGhhbiB0aGUgcmVjZWl2ZXIgbmVlZHMsIHRoYXQncyBub3QgYSBwcm9ibGVtLCBidXQgaWYgaXQg aGFzIHRvbyBmZXcsIHRoYXQgY291bGQgcG90ZW50aWFsbHkgYmUgYSBwcm9ibGVtLiANCg0KSW4g dGhpcyBzY2VuYXJpbyBpdCBkb2Vzbid0IG1hdHRlciB3aGV0aGVyIHRoZSByZWNlaXZlcidzIGNh cGFiaWxpdHkgYXJlIHN0YXRpYyBvciBkeW5hbWljOyBhbGwgdGhhdCBtYXR0ZXJzIGlzIHRoYXQg dGhlIHJlY2VpdmVyIGtub3dzIHdoYXQgaXRzIGNhcGFiaWxpdGllcyBhcmUgYXQgdGhlIHRpbWUg aXQgZGVjaWRlcyB3aGV0aGVyIG9yIG5vdCBpdCBjYW4gZGVjb2RlIHRoZSBzdHJlYW0uIA0KDQpJ ZiB0aGUgY29uY2VybiBpcyB0aGF0IHRoZSByZWNlaXZlcidzIGNhcGFiaWxpdHkgbWlnaHQgYmUg cmVkdWNlZCBhZnRlciBpdCBzdGFydHMgdG8gZGVjb2RlIHRoZSBzdHJlYW0sIHRoYXQgb3BlbnMg YSBiaWdnZXIgaXNzdWUgdGhhdCBJIHdhcyBub3QgdHJ5aW5nIHRvIGFkZHJlc3MuIEhvd2V2ZXIs IEkgZG9uJ3QgdGhpbmsgdGhhdCBjb25jZXJuIGFwcGxpZXMgdG8gdGhlIHNwZWNpZmljIHF1ZXN0 aW9uIG9mIGhvdyBtYW55IGNvZWZmaWNpZW50IHBhcnRpdGlvbnMgdGhlIHN0cmVhbSBoYXMuIElm IHRoZSByZWNlaXZlciBlaXRoZXIgcmVxdWlyZXMgYSBjZXJ0YWluIG51bWJlciBvZiBjb2VmZmlj aWVudCBwYXJ0aXRpb25zIGluaXRpYWxseSwgb3IgYW50aWNpcGF0ZXMgdGhhdCBkdWUgdG8gZHlu YW1pYyBiZWhhdmlvciBpdCBtaWdodCByZXF1aXJlIHRoZW0gaW4gdGhlIGZ1dHVyZSwgaXQgY2Fu IHVzZSB0aGF0IGluZm9ybWF0aW9uIHRvIGRlY2lkZSB3aGV0aGVyIG9yIG5vdCB0byBhY2NlcHQg dGhlIHN0cmVhbS4gT24gdGhlIG90aGVyIGhhbmQsIGlmIHRoZSByZWNlaXZlciBtaWdodCBpbiB0 aGUgZnV0dXJlIHJlcXVpcmUgYSBzbWFsbGVyIGZyYW1lIHNpemUgJiByYXRlIHN0cmVhbSBhZnRl ciB0aGUgc3RyZWFtIGhhcyBzdGFydGVkLCB0aGF0J3MgYW5vdGhlciBtYXR0ZXIgYWx0b2dldGhl ci4NCg0KLS1TYW5keSAoQWxleGFuZGVyKSBNYWNJbm5pcw0KQnJvYWRjb20NCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcGF5bG9hZC1ib3VuY2VzQGlldGYub3JnIFttYWls dG86cGF5bG9hZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgT2xpdmllciBDcsOqdGUN ClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDI0LCAyMDEyIDI6NDEgUE0NClRvOiBwYXlsb2FkQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW3BheWxvYWRdIFZQOCBwYXlsb2FkLCBkZWNvZGVyIHByb2Nlc3Np bmcgY2FwYWJpbGl0aWVzDQoNCk9uIFR1ZSwgMjAxMi0wNC0yNCBhdCAyMTozMSArMDAwMCwgU2Fu ZHkgKEFsZXhhbmRlcikgTWFjSW5uaXMgd3JvdGU6DQo+IEkgaGF2ZSBhbm90aGVyIHF1ZXN0aW9u IGFib3V0IHRoaXMuDQo+IA0KPiBCYWNrZ3JvdW5kOg0KPiBJbiB0aGUgVlA4IGJpdHN0cmVhbSBz cGVjLCBhbmQgaW4gdGhlIHBheWxvYWQgZHJhZnQsIHRoZSB1c2Ugb2YgbXVsdGlwbGUgY29lZmZp Y2llbnQgcGFydGl0aW9ucyBpcyBvcHRpb25hbCBhbmQgbm90IHJlcXVpcmVkLiANCj4gDQo+IEEg VlA4IGRlY29kZXIgbWlnaHQgdXNlIG11bHRpLXRocmVhZGVkIHByb2Nlc3NpbmcsIHN1Y2ggdGhh dCBpdCBjYW4gYWNoaWV2ZSBzaWduaWZpY2FudGx5IGdyZWF0ZXIgdGhyb3VnaHB1dCBieSBkZWNv ZGluZyBtdWx0aXBsZSBjb2VmZmljaWVudCBwYXJ0aXRpb25zIGluIHBhcmFsbGVsLiBTdWNoIGEg ZGVjb2RlciBtaWdodCByZWx5IG9uIHRoZSBwcmVzZW5jZSBvZiBhIGNlcnRhaW4gbnVtYmVyIG9m IGNvZWZmaWNpZW50IHBhcnRpdGlvbnMgaW4gb3JkZXIgdG8gYWNoaWV2ZSBhIGNlcnRhaW4gbGV2 ZWwgb2YgdGhyb3VnaHB1dC4NCj4gDQo+IEZvciBleGFtcGxlLCBzb21lIHJlY2VpdmVyIG1pZ2h0 IGNvbXByaXNlIGEgbXVsdGktdGhyZWFkZWQgZGVjb2RlciB0aGF0IGNhbiBkZWNvZGUgMTkyMHgx MDgwcDYwIGlmIHRoZSBzdHJlYW0gaGFzIGF0IGxlYXN0IGZvdXIgY29lZmZpY2llbnQgcGFydGl0 aW9ucywgYnV0IGlmIHRoZSBzdHJlYW0gaGFzIG9ubHkgb25lIGNvZWZmaWNpZW50IHBhcnRpdGlv biBpdCBtaWdodCBiZSBsaW1pdGVkIHRvIGEgc2lnbmlmaWNhbnRseSBzbWFsbGVyIHByb2R1Y3Qg b2YgZnJhbWUgc2l6ZSBhbmQgZnJhbWUgcmF0ZS4NCj4gDQo+IFF1ZXN0aW9uOiBXaXRoIHRoZSBj dXJyZW50IGRyYWZ0LCBob3cgZG9lcyBhIG11bHRpLXRocmVhZGVkIGRlY29kZXIga25vdyBpbiBh ZHZhbmNlIGhvdyBtYW55IGNvZWZmaWNpZW50IHBhcnRpdGlvbnMgdGhlIHN0cmVhbSB1c2VzLCBz byBpdCBjYW4gZGVjaWRlIHdoZXRoZXIgaXQgY2FuIGRlY29kZSBhIHN0cmVhbSBvZiBhIGdpdmVu IGZyYW1lIHNpemUgYW5kIGZyYW1lIHJhdGU/IE9yIGRvZXMgdGhpcyBhc3BlY3Qgbm90IG1hdHRl cj8NCg0KSSB0aGluayB0aGUgcmVjZWl2ZXIgc2hvdWxkIGluY2x1ZGUgYWxsIG9mIHRoYXQgaW4g aXRzIFNEUCwgbWF5YmUNCnNvbWV0aGluZyBsaWtlOiBTYW1wbGVzUGVyQ29lZmZpY2llbnRQYXJ0 aXRpb249WA0KTWF4UGFyYWxsZWxDb2VmZmZpY2llbnRQYXJ0aXRpb25zPVkNCg0KVGhhdCBzYWlk LCBJJ20gY29uY2VybmVkIHRoYXQgYWxsIG9mIHRoaXMgaXMgYSByZWFsbHkgc3RhdGljIHZpZXcg b2YNCnRoaW5ncywgd2hpY2ggaXMgdXNlZnVsIG9uIGEgZml4ZWQgZGV2aWNlLiBCdXQgaXMgY29t cGxldGVseSBwb2ludGxlc3MNCndoZW4gd3JpdGluZyBzb2Z0d2FyZSB0aGF0IHJ1bnMgb24gYSBn ZW5lcmFsIHB1cnBvc2UgY29tcHV0ZXIgKHN1Y2ggYXMgYQ0KZGVza3RvcCBvciBhIHNtYXJ0cGhv bmUpLCBpbiB3aGljaCBjYXNlIHdlIHdhbnQgc29tZXRoaW5nIG1vcmUgZHluYW1pYy4NClNvIG1h eWJlIGFsbCBvZiB0aGlzIGRpc2N1c3Npb24gaXMgbW9zdGx5IHBvaW50bGVzcyBhbmQgd2Ugc2hv dWxkIHB1c2gNCmZvciBhIG1vcmUgZHluYW1pYyBzb2x1dGlvbiAobWF5YmUgc29tZSBraW5kIG9m IFJUQ1AgZmVlZGJhY2s/KQ0KDQotLSANCk9saXZpZXIgQ3LDqnRlDQpvbGl2aWVyLmNyZXRlQGNv bGxhYm9yYS5jb20NCg== From ietf-ipr@ietf.org Wed Apr 25 10:32:01 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE60621F87F8; Wed, 25 Apr 2012 10:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjG+C-MoLeca; Wed, 25 Apr 2012 10:32:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65AB021F87D3; Wed, 25 Apr 2012 10:32:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: zfang@qualcomm.com X-Test-IDTracker: no X-IETF-IDTracker: 4.01p1 Message-ID: <20120425173200.1079.20033.idtracker@ietfa.amsl.com> Date: Wed, 25 Apr 2012 10:32:00 -0700 Cc: payload@ietf.org, ipr-announce@ietf.org Subject: [payload] IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-avt-rtp-evrc-nw-06 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 17:32:01 -0000 Dear Zheng Fang: An IPR disclosure that pertains to your Internet-Draft entitled "RTP paylo= ad format for Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW)" (dra= ft- ietf-avt-rtp-evrc-nw) was submitted to the IETF Secretariat on 2012-04-25 a= nd has been posted on the "IETF Page of Intellectual Property Rights Disclosur= es" (https://datatracker.ietf.org/ipr/1766/). The title of the IPR disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to dr= aft- ietf-avt-rtp-evrc-nw-06.""); The IETF Secretariat