From roman@telurix.com Fri Mar 1 13:15:55 2013 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 030E01F0D0B for ; Fri, 1 Mar 2013 13:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBSViTgiHuQL for ; Fri, 1 Mar 2013 13:15:54 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE4C1F0C74 for ; Fri, 1 Mar 2013 13:15:54 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id d7so2863654wer.8 for ; Fri, 01 Mar 2013 13:15:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=b0ONAnyQRjur4mubzOaBqGFoHKYfGKSnwX2XAafV/Mg=; b=TUZHblx0GT2Hn+tMBkR9+Rvig4BXyD4Zgg0zj84fLofek29o/QxXFjjUdJJNfHV8g6 XuygePI+8gpp4/B7oQA+8usfYz5namb1M3DLa7jcHEl0UCkElFYGu8KmmbhHRMDb3zPn MIkafIYEy1v5JwbqyQd6ZrJBn75jzdfmSN++O8iH2mEQiHXcuLIA+6v8Ixj79XBO94DW sb75U04ALk99y94K4VG1cPgyBiTFFo8FHVGpEHXcKGtmd3bmarI/40/nQc8sCdBYKGaX bWkrO/MTavw2ZcdL3IGAnlyGl48cOBissTsge4n0JMupS4vu1KvOBv82FK++pAg/KwmB Ovdw== X-Received: by 10.180.98.74 with SMTP id eg10mr235105wib.22.1362172553544; Fri, 01 Mar 2013 13:15:53 -0800 (PST) Received: from mail-wi0-x22a.google.com ([2a00:1450:400c:c05::22a]) by mx.google.com with ESMTPS id n10sm92783wia.0.2013.03.01.13.15.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Mar 2013 13:15:52 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hm11so119345wib.3 for ; Fri, 01 Mar 2013 13:15:51 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.181.11.198 with SMTP id ek6mr5073045wid.1.1362172551409; Fri, 01 Mar 2013 13:15:51 -0800 (PST) Received: by 10.216.206.90 with HTTP; Fri, 1 Mar 2013 13:15:51 -0800 (PST) Date: Fri, 1 Mar 2013 16:15:51 -0500 Message-ID: From: Roman Shpount To: payload@ietf.org Content-Type: multipart/alternative; boundary=f46d043c084a0cbbd904d6e38396 X-Gm-Message-State: ALoCoQkSd6NBOY6xCzGbMMF7g2AGdcWHZZ2UQunWcp8H8YQYxoNOQATfVo3I4K7FbWJqgv1Y2rVK Subject: [payload] draft-ietf-payload-rtp-opus-00 and specifying preference to receive stereo 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: Fri, 01 Mar 2013 21:15:55 -0000 --f46d043c084a0cbbd904d6e38396 Content-Type: text/plain; charset=ISO-8859-1 I am sure someone have already asked this, but why do we need "stereo" optional parameter and always specify number of channels 2 in RTP map? Can this be replaced by simply saying that receiver specifies its preference to receive stereo by specifying 2 channels in RTP map and its preference to receive mono audio by specifying 1 channel in RTP map? We should still specify that every receiver MUST be able to receive and decode stereo signals. _____________ Roman Shpount --f46d043c084a0cbbd904d6e38396 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am sure someone have already asked this, but why do we need "stereo" optional parameter and always specify= =A0number of channels=A02 in RTP map? Can this be replaced by simply saying = that receiver specifies its preference to receive stereo by=A0specif= ying=A02 channels in RTP map and its preference to receive mono audio by sp= ecifying=A01 channel in RTP map? We should st= ill specify that every receiver=A0MUST= be able to receive and decode stereo signals.
_____________
Roman Shpount
--f46d043c084a0cbbd904d6e38396-- From jmvalin@mozilla.com Fri Mar 1 13:56:17 2013 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 6827621E80BC for ; Fri, 1 Mar 2013 13:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91K16j2TU+Pr for ; Fri, 1 Mar 2013 13:56:15 -0800 (PST) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3973221E803F for ; Fri, 1 Mar 2013 13:56:15 -0800 (PST) Received: from [192.168.1.15] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 75B37F2131; Fri, 1 Mar 2013 13:56:14 -0800 (PST) Message-ID: <513123FD.5020407@mozilla.com> Date: Fri, 01 Mar 2013 16:56:13 -0500 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Roman Shpount References: In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: payload@ietf.org Subject: Re: [payload] draft-ietf-payload-rtp-opus-00 and specifying preference to receive stereo 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: Fri, 01 Mar 2013 21:56:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/01/2013 04:15 PM, Roman Shpount wrote: > I am sure someone have already asked this, but why do we need > "stereo" optional parameter and always specify number of channels 2 > in RTP map? Can this be replaced by simply saying that receiver > specifies its preference to receive stereo by specifying 2 channels > in RTP map and its preference to receive mono audio by specifying 1 > channel in RTP map? We should still specify that every receiver > MUST be able to receive and decode stereo signals. One of the reasons is preventing interop an failure case where one client would have opus/48000/1 while the other has opus/48000/2. It also makes it easier to negotiate the case where stereo is used in one direction, while mono is used in the other direction. The idea is that stereo=0 really means "stereo isn't useful for me" rather than "this stream cannot have stereo in it". There are applications where one might want to send stereo to a client that specified mono, for example, in conferencing applications where we want to send the same audio to all participants, or even for "high-quality music on hold" when we only want a single version of our music. In general, any opus stream may contain 48 kHz stereo in it, and that's why it's advertised as such. Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRMSP9AAoJEJ6/8sItn9q9YFoIAKRxZN2MUp5M0F+R9e8SRPZF ZpSkjDec3/FmjLvRpe/pphb3CeWossvf6R2PzvOAPM9NWLgRS+70MEi0L/s6hEqS 0uZ6CpJuXc2+IT0VgL/+jdOPH/cWXlA4cSjQx3IgWM0lPBsba311g5Tan7io0E0c sPdIf9eY9oeVeCJXhnA0MiJ/yXwAcGRlHJ606NQ/T+QoyPBZb03+C98EVXfdHKai bfgIjGopqnzVPDfrmsYC75Lcpn0ZofcKBiEshXc4uHhUTTJsoipfDn4iPHz0UHBW W+SSs9xNBw+zOkxvmqsBFO8zsMoqoJMljTHbzIb5GDui9V9M946rgccUKBrvWJc= =x4fH -----END PGP SIGNATURE----- From harald@alvestrand.no Mon Mar 4 02:57:15 2013 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 92EA521F8952 for ; Mon, 4 Mar 2013 02:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.299 X-Spam-Level: X-Spam-Status: No, score=-111.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_00=-2.599, 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 e6sb9AfX7ONZ for ; Mon, 4 Mar 2013 02:57:14 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEC521F8951 for ; Mon, 4 Mar 2013 02:57:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8701B39E0FD for ; Mon, 4 Mar 2013 11:57:13 +0100 (CET) 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 IU3Ab2Nkg0XB for ; Mon, 4 Mar 2013 11:57:12 +0100 (CET) Received: from [IPv6:2001:6c8:1004:101:2553:85a4:ea3d:efab] (unknown [IPv6:2001:6c8:1004:101:2553:85a4:ea3d:efab]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 18B2A39E0C8 for ; Mon, 4 Mar 2013 11:57:12 +0100 (CET) Message-ID: <51347E07.30803@alvestrand.no> Date: Mon, 04 Mar 2013 11:57:11 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: payload@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [payload] Review of draft-ietf-payload-vp8-08 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, 04 Mar 2013 10:57:15 -0000 Thanks for the review, Cullen. It is only 3 months since the second WG Last Call on this document, and almost exactly one year since the first WG Last Call - most of what you mention has been unchanged even long before that, so this is definitely asking for late changes. I haven't consulted with the experts on this yet - it seems they are on vacation or otherwise unavailable at the moment, so this is my attempt at responses. On 02/26/2013 06:45 AM, Cullen Jennings (fluffy) wrote: > My major issues is I think it is not appropriate to define a temperable scalable codec in the same draft as the payload. I'm fine with the payloads for it but I think the temporal scalability stuff should be moved to a separate draft outside of payload - it's very confusing having the two mixed together. I disagree. This is a payload that has some properties that make some scalability options possible, and the payload format needs some properties in order to take advantage of that. There is no "non-scalable variant" of VP8. This is it. > Need to be able to negotiate upper bound on resolution and frame rates - every time I have brought this up in the past the authors have strongly objected but I don't understand how hardware codecs work without this. The hardware codecs need to have the 4 image buffers and they will have a limit to the size of theses. My preferred way of dealing with resolution would be just to mandate use of rfc6236 when using VP8. There are plenty of ways to negotiate upper limits on resolution. a=imageattr is just one of them. When discussing what we need to limit with our hardware design people, max-fr and max-fs was the result of the discussion; max-fs limits the size of a frame, and max-fr limits the frame rate. This was a topic raised at the first Last Call, the addition of max-fs and max-fr was the major technical change done at that time, and the original poster said that his issue had been addressed. > I don't see a need for 7 bit pictureID, it just adds to complexity that will not be tested 7-bit picture IDs were added in order to reduce the overhead, I believe. Taking them out now would lead to an interesting interoperability issue with existing deployed code; I wouldn't want to remove it until all existing code has been checked to verify that they never generate it. I can check with the people who maintain it if you really want to pursue the issue. > The temporal stuff does not seem to be specified very well. To be more specific, I think creating a layered codec from a non layered codec would better be done in a spec other than the payload description. Among other things that space is littered with IPR issues that should not be confused with the base payload Feel free to file IPR disclosures on it. As I said before, the codec has certain layering properties, and the payload needs to expose those. > The SDP does not allow one to specify the color space's supported but is seems that VP8 does so seems like something is needed in SDP. VP8 does not permit any decoder to duck out of supporting what the encoder is able to send. It was a design decision to limit the negotiation to the absolute minimum; we'd like to keep that property unless compellling scenarios arguing for something else comes up. > I'd like to see negotiation of the loop filter type used for a variety of reasons Again, the choice of going for one profile without negotiation was a deliberate one. What cannot be negotiated cannot be messed up by negotiation failure. So far, all VP8 decoders can decode all valid VP8 encoded streams; we'd like to keep that property. If compelling use cases come up, we could revisit this - but they'd have to be very compelling. > I'd like to see negotiation of the reconstrcuction filter type(s) used - amount other things new ones can be added to VP8 and we need a way to support that. VP8 is a fixed bitstream, and Google does not have plans to develop it further. Do you see a reason for making such changes to VP8 instead of contributing them into ongoing video work (video-codec, VP9)? > I'd like to see what the limits are of google hardware implementation (or anyone else's if they exist) and make sure that all theses limits can be expressed in SDP. Feel free to contact Aki for access to the hardware tapeouts. > I'd like to see a way of describing upper bound on macro block rate instead of the combined max-fs / max-fr solution. I don't see how to make hardware decoders work without this. Apparently the current hardware decoders were able to make it work. > It would be good to see more advice on how many partitions to use and why. Advice is good, but I think this will change due to more circumstances than can easily fit into an RTP spec; I don't think this is the right place for that advice. > I'm confused on the Y bit. Please explain the nature of your confusion - I believe I understood it, but I may have missed something. > Unclear if receiver is supposed to send positive ACK RPSI It is allowed - the section describes why it is useful. It is not mandated; applications can do that if they want to, but the payload format is the same whether or not the application uses RPSI. My summary comment: I don't see a reason to make technical changes to the spec based on these comments. I also don't see a reason to delay the IETF-wide last call based on these comments. Clarifications, if needed, can be addressed together with Last Call comments after IETF Last Call. Harald From abegen@cisco.com Tue Mar 5 15:03:11 2013 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 8C7B711E80FA for ; Tue, 5 Mar 2013 15:03:11 -0800 (PST) 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=[BAYES_00=-2.599, 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 3bzVySSKKiHf for ; Tue, 5 Mar 2013 15:03:10 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 78B9C11E80BF for ; Tue, 5 Mar 2013 15:03:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6259; q=dns/txt; s=iport; t=1362524590; x=1363734190; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rHAN678ddRet4jBUJRnYGKgBXJpTJ+N1r3ecgB/OLbE=; b=aWI4R5WFeadld79m8/6Bf2Wrf7L8Bj7nicYPCu+tgp8hmeYy2ORWxjAU 1AxK65oCOspdB6V87Aa5IpgjDIuYopqlehYsZnF23IwV/JjHB6YPyIltu DHf7/1bAlF86GE4dVv/v2wG54yIiVkl6l9p7Sk0sCXhERaZj4PzO23gic A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAEN4NlGtJV2c/2dsb2JhbABEhH2/bYFxFnOCKwEBAQMBAQEBNzEDCwULAgEIGAoUECcLJQIEDgUIE4dyBgELrCeQEgSNV4EDAjEHgl9hA5MGlDKDCIFqPQ X-IronPort-AV: E=Sophos;i="4.84,791,1355097600"; d="scan'208";a="184143987" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 05 Mar 2013 23:03:09 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r25N398C018786 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Mar 2013 23:03:09 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Tue, 5 Mar 2013 17:03:09 -0600 From: "Ali C. Begen (abegen)" To: Harald Alvestrand Thread-Topic: [payload] Review of draft-ietf-payload-vp8-08 Thread-Index: AQHOE+SBCBGG65gUD0CDCg9/8nULH5iVyteAgAJdJ4A= Date: Tue, 5 Mar 2013 23:03:08 +0000 Message-ID: References: <51347E07.30803@alvestrand.no> In-Reply-To: <51347E07.30803@alvestrand.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.247.49] Content-Type: text/plain; charset="us-ascii" Content-ID: <7496959C59DCFF418056F91A77E97F3D@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Cullen Jennings \(fluffy\)" , "payload@ietf.org" Subject: Re: [payload] Review of draft-ietf-payload-vp8-08 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, 05 Mar 2013 23:03:11 -0000 I think I will prepare the document write-up and ship it to the AD. If ther= e are remaining comments that one feels the authors should address, we stil= l have the IETF LC process. -acbegen On Mar 4, 2013, at 9:57 PM, Harald Alvestrand wrote: > Thanks for the review, Cullen. It is only 3 months since the second WG La= st Call on this document, and almost exactly one year since the first WG La= st Call - most of what you mention has been unchanged even long before that= , so this is definitely asking for late changes. >=20 > I haven't consulted with the experts on this yet - it seems they are on v= acation or otherwise unavailable at the moment, so this is my attempt at re= sponses. >=20 > On 02/26/2013 06:45 AM, Cullen Jennings (fluffy) wrote: >> My major issues is I think it is not appropriate to define a temperable = scalable codec in the same draft as the payload. I'm fine with the payloads= for it but I think the temporal scalability stuff should be moved to a sep= arate draft outside of payload - it's very confusing having the two mixed t= ogether. > I disagree. This is a payload that has some properties that make some sca= lability options possible, and the payload format needs some properties in = order to take advantage of that. >=20 > There is no "non-scalable variant" of VP8. This is it. >> Need to be able to negotiate upper bound on resolution and frame rates -= every time I have brought this up in the past the authors have strongly ob= jected but I don't understand how hardware codecs work without this. The ha= rdware codecs need to have the 4 image buffers and they will have a limit t= o the size of theses. My preferred way of dealing with resolution would be = just to mandate use of rfc6236 when using VP8. >=20 > There are plenty of ways to negotiate upper limits on resolution. a=3Dima= geattr is just one of them. >=20 > When discussing what we need to limit with our hardware design people, ma= x-fr and max-fs was the result of the discussion; max-fs limits the size of= a frame, and max-fr limits the frame rate. >=20 > This was a topic raised at the first Last Call, the addition of max-fs an= d max-fr was the major technical change done at that time, and the original= poster said that his issue had been addressed. >> I don't see a need for 7 bit pictureID, it just adds to complexity that = will not be tested > 7-bit picture IDs were added in order to reduce the overhead, I believe. = Taking them out now would lead to an interesting interoperability issue wit= h existing deployed code; I wouldn't want to remove it until all existing c= ode has been checked to verify that they never generate it. >=20 > I can check with the people who maintain it if you really want to pursue = the issue. >> The temporal stuff does not seem to be specified very well. To be more s= pecific, I think creating a layered codec from a non layered codec would be= tter be done in a spec other than the payload description. Among other thin= gs that space is littered with IPR issues that should not be confused with = the base payload >=20 > Feel free to file IPR disclosures on it. > As I said before, the codec has certain layering properties, and the payl= oad needs to expose those. >=20 >> The SDP does not allow one to specify the color space's supported but is= seems that VP8 does so seems like something is needed in SDP. > VP8 does not permit any decoder to duck out of supporting what the encode= r is able to send. > It was a design decision to limit the negotiation to the absolute minimum= ; we'd like to keep that property unless compellling scenarios arguing for = something else comes up. >> I'd like to see negotiation of the loop filter type used for a variety o= f reasons > Again, the choice of going for one profile without negotiation was a deli= berate one. What cannot be negotiated cannot be messed up by negotiation fa= ilure. > So far, all VP8 decoders can decode all valid VP8 encoded streams; we'd l= ike to keep that property. >=20 > If compelling use cases come up, we could revisit this - but they'd have = to be very compelling. >> I'd like to see negotiation of the reconstrcuction filter type(s) used -= amount other things new ones can be added to VP8 and we need a way to supp= ort that. > VP8 is a fixed bitstream, and Google does not have plans to develop it fu= rther. > Do you see a reason for making such changes to VP8 instead of contributin= g them into ongoing video work (video-codec, VP9)? >> I'd like to see what the limits are of google hardware implementation (o= r anyone else's if they exist) and make sure that all theses limits can be = expressed in SDP. > Feel free to contact Aki for access to the hardware tapeouts. >> I'd like to see a way of describing upper bound on macro block rate inst= ead of the combined max-fs / max-fr solution. I don't see how to make hardw= are decoders work without this. > Apparently the current hardware decoders were able to make it work. >> It would be good to see more advice on how many partitions to use and wh= y. > Advice is good, but I think this will change due to more circumstances th= an can easily fit into an RTP spec; I don't think this is the right place f= or that advice. >> I'm confused on the Y bit. > Please explain the nature of your confusion - I believe I understood it, = but I may have missed something. >> Unclear if receiver is supposed to send positive ACK RPSI > It is allowed - the section describes why it is useful. It is not mandate= d; applications can do that if they want to, but the payload format is the = same whether or not the application uses RPSI. >=20 > My summary comment: I don't see a reason to make technical changes to the= spec based on these comments. > I also don't see a reason to delay the IETF-wide last call based on these= comments. >=20 > Clarifications, if needed, can be addressed together with Last Call comme= nts after IETF Last Call. >=20 > Harald >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From abegen@cisco.com Fri Mar 8 14:17:04 2013 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 64C5421F85B8 for ; Fri, 8 Mar 2013 14:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, 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 zDku6k6YR+Yt for ; Fri, 8 Mar 2013 14:17:03 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id C0BE721F8598 for ; Fri, 8 Mar 2013 14:17:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3107; q=dns/txt; s=iport; t=1362781023; x=1363990623; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WkTnMPbO8gRU9/1J4lH4mlbVymNR7pJmrDnzjfMd+20=; b=B/PgloStAfZyKn15um8JmXzPFoS1TORTWLeMeXf3WNO7efTf8P5RP4sB bScIFw9/3Zy2MtgXGncmDitdy+2Ym8tpFJZ1co3YqfDixGwZk5kKOtZ7d 0BzLI36deTBx57Y8pW6y4w5UIPv5rida5u3O02vMzG3QaqqV3ir4MHgU5 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAE1iOlGtJV2d/2dsb2JhbABDhDjAF4FdFnSCLAEBAQMBAQEBNzQLBQsCAQgRAwECCxQQJwsUCQgBAQQOBQgBiAQGAQu7eI5ZAiYLAgUGgllhA5dxij+FFYMKgic X-IronPort-AV: E=Sophos;i="4.84,810,1355097600"; d="scan'208";a="185507398" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 08 Mar 2013 22:17:03 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r28MH3GE005334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Mar 2013 22:17:03 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Fri, 8 Mar 2013 16:17:03 -0600 From: "Ali C. Begen (abegen)" To: Jonathan Lennox Thread-Topic: [payload] I-D Action: draft-lennox-payload-ulp-ssrc-mux-00.txt Thread-Index: Ac4OLLg3u78rusOXT1udSw5FPXiOQgN9cqiA Date: Fri, 8 Mar 2013 22:17:02 +0000 Message-ID: References: <20130218225054.23444.52245.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.152.107] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "payload@ietf.org" Subject: Re: [payload] I-D Action: draft-lennox-payload-ulp-ssrc-mux-00.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: Fri, 08 Mar 2013 22:17:04 -0000 I read the draft, it clearly does what it intends to do. But note that the documents resulting from FECFRAME explicitly allowed for = SSRC muxing. I am not sure how widely 5109 is implemented given that FECFRA= ME specified bunch of alternatives. -acbegen=20 On Feb 18, 2013, at 3:07 PM, Jonathan Lennox wrote: > Hi, all -- >=20 > Discussions at previous IETFs pointed out to me that RFC 5109 (the RTP Ge= neric FEC payload) forbids using it in SSRC-multiplexing, even though RFC 5= 576 (SSRC attributes/groups) defines a semantic to permit exactly that. >=20 > This document updates RFC 5109 to permit source-multiplexing of FEC strea= ms with the payloads they protect, so long as the associations between the = FEC and original SSRCs are properly signaled. This not only fixes the inco= nsistency between RFC 5109 and RFC 5576, but also permits FEC's use with ot= her mechanisms for associating SSRCs in an RTP session, such as BUNDLE or S= RCNAME. >=20 > Comments are welcome. >=20 > Begin forwarded message: >=20 >> From: "internet-drafts@ietf.org" >> Subject: I-D Action: draft-lennox-payload-ulp-ssrc-mux-00.txt >> Date: February 18, 2013 5:50:54 PM EST >> To: "i-d-announce@ietf.org" >> Reply-To: "internet-drafts@ietf.org" >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >>=20 >>=20 >> Title : Supporting Source-Multiplexing of the Real-Time Trans= port Protocol (RTP) Payload for Generic Forward Error Correction >> Author(s) : Jonathan Lennox >> Filename : draft-lennox-payload-ulp-ssrc-mux-00.txt >> Pages : 6 >> Date : 2013-02-18 >>=20 >> Abstract: >> The Real-Time Transport Protocol (RTP) Payload format for Generic >> Forward Error Correction (FEC), specified in RFC 5109, forbids >> transmitting FEC repair flows as separate sources in the same RTP >> session as the flows being repaired. This document updates RFC 5109 >> to lift that restriction, as long as the association between original >> and repair flows is properly signaled and negotiated. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-lennox-payload-ulp-ssrc-mux >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-lennox-payload-ulp-ssrc-mux-00 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >=20 > -- > Jonathan Lennox > jonathan@vidyo.com >=20 >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From internet-drafts@ietf.org Wed Mar 13 10:05:33 2013 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 7531921F8E10; Wed, 13 Mar 2013 10:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 4SoMl690Ap7s; Wed, 13 Mar 2013 10:05:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A4321F89E9; Wed, 13 Mar 2013 10:05:32 -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.42 Message-ID: <20130313170532.8176.75319.idtracker@ietfa.amsl.com> Date: Wed, 13 Mar 2013 10:05:32 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-aptx-00.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: Wed, 13 Mar 2013 17:05:33 -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 Working Gr= oup of the IETF. Title : RTP Payload Format for Standard apt-X and Enhanced apt-X= Codecs Author(s) : John Lindsay Hartmut Foerster Filename : draft-ietf-payload-rtp-aptx-00.txt Pages : 22 Date : 2013-03-13 Abstract: This document specifies a scheme for packetizing Standard apt-X, or Enhanced apt-X, encoded audio data into Real-time Transport Protocol (RTP) packets. The document describes a payload format that permits transmission of multiple related audio channels in a single RTP payload, and a means of establishing Standard apt-X and Enhanced apt-X connections through the Session Description Protocol (SDP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-aptx There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-aptx-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From abegen@cisco.com Wed Mar 13 10:07:37 2013 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 19C2221F89E9 for ; Wed, 13 Mar 2013 10:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.074 X-Spam-Level: X-Spam-Status: No, score=-10.074 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, 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 drVy2kjK8aFW for ; Wed, 13 Mar 2013 10:07:35 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8A83921F8E02 for ; Wed, 13 Mar 2013 10:07:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9882; q=dns/txt; s=iport; t=1363194455; x=1364404055; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=N0hqujGgB/rfzTOv3CJuSqzxuPmg14YlsyqussEIYas=; b=YniKeu/LJxRUTnerzM22nFAYAf8AZVIkSfyAM4hHv55GaPyE6ZqPRswV T1swL8/xsp5GsIsqo93GXjg/O3Awtj9B+sk5YGmpMWhpTYc7Ud70oGcST JFdgiLROIw/8RZAaZ/KcedR3wJ8c1TQ1aoUK19CpbAVwE+Lewzu8WORfN w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAIexQFGtJXG+/2dsb2JhbAA5CoQ2g228WGdyFnSCLAEEIxE3BwcSARYMAgYgAgQwFRIEDg0BiAsBC7APkkQXgSOMHgsGCoEAMYI0MmEDp0yDCoFsBxcGGA X-IronPort-AV: E=Sophos;i="4.84,838,1355097600"; d="scan'208";a="187119869" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 13 Mar 2013 17:07:35 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2DH7Zg2014920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Mar 2013 17:07:35 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 12:07:34 -0500 From: "Ali C. Begen (abegen)" To: Robert Sparks Thread-Topic: Publication request for draft-ietf-payload-vp8 Thread-Index: AQHOIA1Btf9KenO1/kK0/uTbMJgbHg== Date: Wed, 13 Mar 2013 17:07:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [10.86.247.19] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "payload@ietf.org" Subject: [payload] Publication request for draft-ietf-payload-vp8 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, 13 Mar 2013 17:07:37 -0000 SGkgUm9iZXJ0LA0KDQpUaGlzIGlzIHRoZSBwdWJsaWNhdGlvbiByZXF1ZXN0IGZvciBkcmFmdC1p ZXRmLXBheWxvYWQtdnA4Lg0KDQpUaGUgZHJhZnQgaGFzIGJlZW4gcmV2aWV3ZWQgYnkgbWFueSBp bmRpdmlkdWFscy4gSXQgZm9sbG93cyB0aGUgdHlwaWNhbA0KcGF5bG9hZCBmb3JtYXQgZG9jdW1l bnQgc3R5bGUuIEl0IHNhdGlzZmllcyBvbmUgb2Ygb3VyIG1pbGVzdG9uZXMuDQoNClRoYW5rcywN Ci1hY2JlZ2VuDQoNCg0KKDEpIFdoYXQgdHlwZSBvZiBSRkMgaXMgYmVpbmcgcmVxdWVzdGVkIChC Q1AsIFByb3Bvc2VkIFN0YW5kYXJkLA0KSW50ZXJuZXQgU3RhbmRhcmQsIEluZm9ybWF0aW9uYWws IEV4cGVyaW1lbnRhbCwgb3IgSGlzdG9yaWMpPyAgV2h5DQppcyB0aGlzIHRoZSBwcm9wZXIgdHlw ZSBvZiBSRkM/ICBJcyB0aGlzIHR5cGUgb2YgUkZDIGluZGljYXRlZCBpbiB0aGUNCnRpdGxlIHBh Z2UgaGVhZGVyPw0KDQpTdGFuZGFyZHMgdHJhY2sgYXMgaW5kaWNhdGVkIGluIHRoZSB0aXRsZSBw YWdlIGhlYWRlci4NCg0KKDIpIFRoZSBJRVNHIGFwcHJvdmFsIGFubm91bmNlbWVudCBpbmNsdWRl cyBhIERvY3VtZW50IEFubm91bmNlbWVudA0KV3JpdGUtVXAuIFBsZWFzZSBwcm92aWRlIHN1Y2gg YSBEb2N1bWVudCBBbm5vdW5jZW1lbnQgV3JpdGUtVXAuIFJlY2VudA0KZXhhbXBsZXMgY2FuIGJl IGZvdW5kIGluIHRoZSAiQWN0aW9uIiBhbm5vdW5jZW1lbnRzIGZvciBhcHByb3ZlZA0KZG9jdW1l bnRzLiBUaGUgYXBwcm92YWwgYW5ub3VuY2VtZW50IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgc2Vj dGlvbnM6DQoNClRlY2huaWNhbCBTdW1tYXJ5DQoNClRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRo ZSBSVFAgcGF5bG9hZCBmb3JtYXQgZm9yIHRoZSBWUDggdmlkZW8gY29kZWMuDQpUaGUgVlA4IGNv ZGVjIHN1cHBvcnRzIHZhcmlvdXMgYXBwbGljYXRpb25zIHJhbmdpbmcgZnJvbSBsb3ctYml0cmF0 ZQ0KcGVlci10by1wZWVyIHRvIGhpZ2gtYml0cmF0ZSB2aWRlb2NvbmZlcmVuY2luZyBhcHBsaWNh dGlvbnMuDQoNCldvcmtpbmcgR3JvdXAgU3VtbWFyeQ0KDQoJVGhlIFdHTEMgcHJvY2VzcyB3YXMg cnVuIHR3aWNlIGFuZCBidW5jaCBvZiBjb21tZW50cyB3ZXJlIGFkZHJlc3NlZCBpbg0KdGhlIGxh dGVzdCB2ZXJzaW9uLiBBZnRlciB0aGUgc2Vjb25kIFdHTEMsIHRoZXJlIHdlcmUgc29tZSBjb21t ZW50cw0Kc3VibWl0dGVkIGJ5IEN1bGxlbiBKZW5uaW5ncyBhbmQgb25lIG9mIHRoZSBhdXRob3Jz IHJlc3BvbmRlZCBpbiB0aGUgbGlzdC4NCkF0IHRoaXMgdGltZSwgd2UgYXJlIHByb2NlZWRpbmcg d2l0aCBwdWJsaWNhdGlvbiByZXF1ZXN0LiBJZiB0aGVyZSBhcmUNCmZ1cnRoZXIgY29tbWVudHMs IHRoZXkgY2FuIGJlIHN1Ym1pdHRlZCBkdXJpbmcgdGhlIElFVEYgTEMuDQoNCkRvY3VtZW50IFF1 YWxpdHkNCg0KCVRoZSBWUDggY29kZWMgaGFzIGJlZW4gdXNlZCBpbiB2YXJpb3VzIGFwcGxpY2F0 aW9ucyAobW9zdCBub3RhYmx5IGJ5DQpHb29nbGUpLiBFYXJsaWVyIHZlcnNpb25zIG9mIGNvZGVj IHdlcmUgdXNlZCBieSBTa3lwZS4gVGhlIG1lZGlhIHN1YnR5cGUNCnJlZ2lzdHJhdGlvbiByZXZp ZXcgd2FzIHJlcXVlc3Qgb24gMTEvMjgvMjAxMi4NCg0KUGVyc29ubmVsDQoNCglBbGkgQmVnZW4g aXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkLiBSb2JlcnQgU3BhcmtzIGlzIHRoZSByZXNwb25zaWJs ZSBBRC4NCg0KKDMpIEJyaWVmbHkgZGVzY3JpYmUgdGhlIHJldmlldyBvZiB0aGlzIGRvY3VtZW50 IHRoYXQgd2FzIHBlcmZvcm1lZCBieQ0KdGhlIERvY3VtZW50IFNoZXBoZXJkLiAgSWYgdGhpcyB2 ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCBpcyBub3QgcmVhZHkNCmZvciBwdWJsaWNhdGlvbiwgcGxl YXNlIGV4cGxhaW4gd2h5IHRoZSBkb2N1bWVudCBpcyBiZWluZyBmb3J3YXJkZWQgdG8NCnRoZSBJ RVNHLg0KDQoJVGhlIHNoZXBoZXJkIHJldmlld2VkIHRoZSBsYXRlc3QgdmVyc2lvbiAoLTA4KSBh bmQgdGhlcmUgYXJlIG5vIGlzc3Vlcy4NCg0KKDQpIERvZXMgdGhlIGRvY3VtZW50IFNoZXBoZXJk IGhhdmUgYW55IGNvbmNlcm5zIGFib3V0IHRoZSBkZXB0aCBvcg0KYnJlYWR0aCBvZiB0aGUgcmV2 aWV3cyB0aGF0IGhhdmUgYmVlbiBwZXJmb3JtZWQ/DQoNCglOb3QgYXQgdGhpcyBwb2ludC4NCg0K KDUpIERvIHBvcnRpb25zIG9mIHRoZSBkb2N1bWVudCBuZWVkIHJldmlldyBmcm9tIGEgcGFydGlj dWxhciBvciBmcm9tDQpicm9hZGVyIHBlcnNwZWN0aXZlLCBlLmcuLCBzZWN1cml0eSwgb3BlcmF0 aW9uYWwgY29tcGxleGl0eSwgQUFBLCBETlMsDQpESENQLCBYTUwsIG9yIGludGVybmF0aW9uYWxp emF0aW9uPyBJZiBzbywgZGVzY3JpYmUgdGhlIHJldmlldyB0aGF0DQp0b29rIHBsYWNlLg0KDQoJ Tm9wZS4NCg0KKDYpIERlc2NyaWJlIGFueSBzcGVjaWZpYyBjb25jZXJucyBvciBpc3N1ZXMgdGhh dCB0aGUgRG9jdW1lbnQgU2hlcGhlcmQNCmhhcyB3aXRoIHRoaXMgZG9jdW1lbnQgdGhhdCB0aGUg UmVzcG9uc2libGUgQXJlYSBEaXJlY3RvciBhbmQvb3IgdGhlDQpJRVNHIHNob3VsZCBiZSBhd2Fy ZSBvZj8gRm9yIGV4YW1wbGUsIHBlcmhhcHMgaGUgb3Igc2hlIGlzIHVuY29tZm9ydGFibGUNCndp dGggY2VydGFpbiBwYXJ0cyBvZiB0aGUgZG9jdW1lbnQsIG9yIGhhcyBjb25jZXJucyB3aGV0aGVy IHRoZXJlIHJlYWxseQ0KaXMgYSBuZWVkIGZvciBpdC4gSW4gYW55IGV2ZW50LCBpZiB0aGUgV0cg aGFzIGRpc2N1c3NlZCB0aG9zZSBpc3N1ZXMgYW5kDQpoYXMgaW5kaWNhdGVkIHRoYXQgaXQgc3Rp bGwgd2lzaGVzIHRvIGFkdmFuY2UgdGhlIGRvY3VtZW50LCBkZXRhaWwgdGhvc2UNCmNvbmNlcm5z IGhlcmUuDQoNCglOb25lLg0KDQooNykgSGFzIGVhY2ggYXV0aG9yIGNvbmZpcm1lZCB0aGF0IGFu eSBhbmQgYWxsIGFwcHJvcHJpYXRlIElQUg0KZGlzY2xvc3VyZXMgcmVxdWlyZWQgZm9yIGZ1bGwg Y29uZm9ybWFuY2Ugd2l0aCB0aGUgcHJvdmlzaW9ucyBvZiBCQ1AgNzgNCmFuZCBCQ1AgNzkgaGF2 ZSBhbHJlYWR5IGJlZW4gZmlsZWQuIElmIG5vdCwgZXhwbGFpbiB3aHkuDQoNCglZZXMuDQoNCig4 KSBIYXMgYW4gSVBSIGRpc2Nsb3N1cmUgYmVlbiBmaWxlZCB0aGF0IHJlZmVyZW5jZXMgdGhpcyBk b2N1bWVudD8NCklmIHNvLCBzdW1tYXJpemUgYW55IFdHIGRpc2N1c3Npb24gYW5kIGNvbmNsdXNp b24gcmVnYXJkaW5nIHRoZSBJUFINCmRpc2Nsb3N1cmVzLg0KDQoJVGhlcmUgaXMgb25lIElQUiBz dWJtaXNzaW9uIGZyb20gVmlkeW8gKElQUiAxNjIyKS4gVGhlIFdHIGRpZCBub3QgaGF2ZQ0KY29u Y2VybnMgYWJvdXQgdGhpcyBJUFIgc3VibWlzc2lvbi4NCg0KKDkpIEhvdyBzb2xpZCBpcyB0aGUg V0cgY29uc2Vuc3VzIGJlaGluZCB0aGlzIGRvY3VtZW50PyBEb2VzIGl0DQpyZXByZXNlbnQgdGhl IHN0cm9uZyBjb25jdXJyZW5jZSBvZiBhIGZldyBpbmRpdmlkdWFscywgd2l0aCBvdGhlcnMNCmJl aW5nIHNpbGVudCwgb3IgZG9lcyB0aGUgV0cgYXMgYSB3aG9sZSB1bmRlcnN0YW5kIGFuZCBhZ3Jl ZSB3aXRoIGl0Pw0KDQoJU2V2ZXJhbCBwZW9wbGUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCwgbW9z dGx5IHdobyBhcmUgaW50ZXJlc3RlZCBpbg0KaW1wbGVtZW50aW5nIHRoaXMgcGF5bG9hZC4gVGhl cmUgd2VyZSBubyBvYmplY3Rpb25zIGZyb20gdGhlIHJlc3Qgb2YgdGhlDQpXRy4NCg0KKDEwKSBI YXMgYW55b25lIHRocmVhdGVuZWQgYW4gYXBwZWFsIG9yIG90aGVyd2lzZSBpbmRpY2F0ZWQgZXh0 cmVtZQ0KZGlzY29udGVudD8gSWYgc28sIHBsZWFzZSBzdW1tYXJpc2UgdGhlIGFyZWFzIG9mIGNv bmZsaWN0IGluIHNlcGFyYXRlDQplbWFpbCBtZXNzYWdlcyB0byB0aGUgUmVzcG9uc2libGUgQXJl YSBEaXJlY3Rvci4gKEl0IHNob3VsZCBiZSBpbiBhDQpzZXBhcmF0ZSBlbWFpbCBiZWNhdXNlIHRo aXMgcXVlc3Rpb25uYWlyZSBpcyBwdWJsaWNseSBhdmFpbGFibGUuKQ0KDQoJTm9wZS4NCg0KKDEx KSBJZGVudGlmeSBhbnkgSUQgbml0cyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgaGFzIGZvdW5kIGlu IHRoaXMNCmRvY3VtZW50LiAoU2VlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvdG9vbHMvaWRuaXRzLyBh bmQgdGhlIEludGVybmV0LURyYWZ0cw0KQ2hlY2tsaXN0KS4gQm9pbGVycGxhdGUgY2hlY2tzIGFy ZSBub3QgZW5vdWdoOyB0aGlzIGNoZWNrIG5lZWRzIHRvIGJlDQp0aG9yb3VnaC4NCg0KCVRoZXJl IGFyZSBhIGZldyBJRCBuaXRzLg0KDQoJMSkgVW51c2VkIHJlZmVyZW5jZTogUkZDIDM5ODQNCgky KSBPYnNvbGV0ZSBub3JtYXRpdmUgcmVmZXJlbmNlOiBSRkMgNDI4OCAoT2Jzb2xldGVkIGJ5IFJG QyA2ODM4KQ0KCTMpIERvd25yZWY6IE5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gYW4gSW5mb3JtYXRp b25hbCBSRkM6IFJGQyA2Mzg2DQoNClRoZXJlIGFyZSBhbHNvIGEgZmV3IG1pbm9yIGVycm9ycy4g Rm9yIGV4YW1wbGUsIHRoZSBzdWJ0eXBlIGhhcyAzIChub3QgMikNCm9wdGlvbmFsIHBhcmFtZXRl cnMuDQoNCigxMikgRGVzY3JpYmUgaG93IHRoZSBkb2N1bWVudCBtZWV0cyBhbnkgcmVxdWlyZWQg Zm9ybWFsIHJldmlldw0KY3JpdGVyaWEsIHN1Y2ggYXMgdGhlIE1JQiBEb2N0b3IsIG1lZGlhIHR5 cGUsIGFuZCBVUkkgdHlwZSByZXZpZXdzLg0KDQoJTWVkaWEgc3VidHlwZSByZWdpc3RyYXRpb24g cmV2aWV3IHdhcyByZXF1ZXN0ZWQ6DQoJaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL21lZGlhLXR5cGVzL2N1cnJlbnQvbXNnMDA0NTUuaHRtbA0KDQooMTMpIEhhdmUgYWxsIHJl ZmVyZW5jZXMgd2l0aGluIHRoaXMgZG9jdW1lbnQgYmVlbiBpZGVudGlmaWVkIGFzDQplaXRoZXIg bm9ybWF0aXZlIG9yIGluZm9ybWF0aXZlPw0KDQoJTm8sIHdoaWNoIG1lYW5zIGFsbCByZWZlcmVu Y2VzIHdpbGwgYmUgY29uc2lkZXJlZCBhcyAibm9ybWF0aXZlIi4NCg0KKDE0KSBBcmUgdGhlcmUg bm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gZG9jdW1lbnRzIHRoYXQgYXJlIG5vdCByZWFkeSBmb3IN CmFkdmFuY2VtZW50IG9yIGFyZSBvdGhlcndpc2UgaW4gYW4gdW5jbGVhciBzdGF0ZT8gSWYgc3Vj aCBub3JtYXRpdmUNCnJlZmVyZW5jZXMgZXhpc3QsIHdoYXQgaXMgdGhlIHBsYW4gZm9yIHRoZWly IGNvbXBsZXRpb24/DQoNCglOb3BlLg0KDQooMTUpIEFyZSB0aGVyZSBkb3dud2FyZCBub3JtYXRp dmUgcmVmZXJlbmNlcyByZWZlcmVuY2VzIChzZWUgUkZDIDM5NjcpPw0KSWYgc28sIGxpc3QgdGhl c2UgZG93bndhcmQgcmVmZXJlbmNlcyB0byBzdXBwb3J0IHRoZSBBcmVhIERpcmVjdG9yIGluDQp0 aGUgTGFzdCBDYWxsIHByb2NlZHVyZS4NCg0KCVRoZXJlIGlzIGEgZG93bnJlZiB0byBSRkMgNjM4 Niwgd2hpY2ggaXMgdGhlIG1haW4gUkZDIHRoYXQgZGVzY3JpYmVzIHRoZQ0KVlA4IGRhdGEgZm9y bWF0LiBUaGF0IFJGQyBpcyBhbiBpbmZvcm1hdGlvbmFsIG9uZSBzaW5jZSBpdCB3YXMgYW4NCmlu ZGVwZW5kZW50IHN1Ym1pc3Npb24gKG5vdCB0aHJ1IGEgV0cpLg0KDQooMTYpIFdpbGwgcHVibGlj YXRpb24gb2YgdGhpcyBkb2N1bWVudCBjaGFuZ2UgdGhlIHN0YXR1cyBvZiBhbnkNCmV4aXN0aW5n IFJGQ3M/IEFyZSB0aG9zZSBSRkNzIGxpc3RlZCBvbiB0aGUgdGl0bGUgcGFnZSBoZWFkZXIsIGxp c3RlZA0KaW4gdGhlIGFic3RyYWN0LCBhbmQgZGlzY3Vzc2VkIGluIHRoZSBpbnRyb2R1Y3Rpb24/ IElmIHRoZSBSRkNzIGFyZSBub3QNCmxpc3RlZCBpbiB0aGUgQWJzdHJhY3QgYW5kIEludHJvZHVj dGlvbiwgZXhwbGFpbiB3aHksIGFuZCBwb2ludCB0byB0aGUNCnBhcnQgb2YgdGhlIGRvY3VtZW50 IHdoZXJlIHRoZSByZWxhdGlvbnNoaXAgb2YgdGhpcyBkb2N1bWVudCB0byB0aGUNCm90aGVyIFJG Q3MgaXMgZGlzY3Vzc2VkLiBJZiB0aGlzIGluZm9ybWF0aW9uIGlzIG5vdCBpbiB0aGUgZG9jdW1l bnQsDQpleHBsYWluIHdoeSB0aGUgV0cgY29uc2lkZXJzIGl0IHVubmVjZXNzYXJ5Lg0KDQoJTm8g Y2hhbmdlcyB0byBleGlzdGluZyBkb2N1bWVudHMuDQoNCigxNykgRGVzY3JpYmUgdGhlIERvY3Vt ZW50IFNoZXBoZXJkJ3MgcmV2aWV3IG9mIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zDQpzZWN0aW9u LCBlc3BlY2lhbGx5IHdpdGggcmVnYXJkIHRvIGl0cyBjb25zaXN0ZW5jeSB3aXRoIHRoZSBib2R5 IG9mIHRoZQ0KZG9jdW1lbnQuIENvbmZpcm0gdGhhdCBhbGwgcHJvdG9jb2wgZXh0ZW5zaW9ucyB0 aGF0IHRoZSBkb2N1bWVudCBtYWtlcw0KYXJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgYXBwcm9wcmlh dGUgcmVzZXJ2YXRpb25zIGluIElBTkEgcmVnaXN0cmllcy4NCkNvbmZpcm0gdGhhdCBhbnkgcmVm ZXJlbmNlZCBJQU5BIHJlZ2lzdHJpZXMgaGF2ZSBiZWVuIGNsZWFybHkNCmlkZW50aWZpZWQuIENv bmZpcm0gdGhhdCBuZXdseSBjcmVhdGVkIElBTkEgcmVnaXN0cmllcyBpbmNsdWRlIGENCmRldGFp bGVkIHNwZWNpZmljYXRpb24gb2YgdGhlIGluaXRpYWwgY29udGVudHMgZm9yIHRoZSByZWdpc3Ry eSwgdGhhdA0KYWxsb2NhdGlvbnMgcHJvY2VkdXJlcyBmb3IgZnV0dXJlIHJlZ2lzdHJhdGlvbnMg YXJlIGRlZmluZWQsIGFuZCBhDQpyZWFzb25hYmxlIG5hbWUgZm9yIHRoZSBuZXcgcmVnaXN0cnkg aGFzIGJlZW4gc3VnZ2VzdGVkIChzZWUgUkZDIDUyMjYpLg0KDQoJVGhlIG1lZGlhIHN1YnR5cGUg cmVnaXN0cmF0aW9uIGlzIGNvbXBsaWFudCB3aXRoIHRoZSByZWdpc3RyYXRpb24NCnRlbXBsYXRl IChSRkMgNjgzOCkuDQoNCigxOCkgTGlzdCBhbnkgbmV3IElBTkEgcmVnaXN0cmllcyB0aGF0IHJl cXVpcmUgRXhwZXJ0IFJldmlldyBmb3IgZnV0dXJlDQphbGxvY2F0aW9ucy4gUHJvdmlkZSBhbnkg cHVibGljIGd1aWRhbmNlIHRoYXQgdGhlIElFU0cgd291bGQgZmluZA0KdXNlZnVsIGluIHNlbGVj dGluZyB0aGUgSUFOQSBFeHBlcnRzIGZvciB0aGVzZSBuZXcgcmVnaXN0cmllcy4NCg0KCU5vIG5l dyBJQU5BIHJlZ2lzdHJpZXMuDQoNCigxOSkgRGVzY3JpYmUgcmV2aWV3cyBhbmQgYXV0b21hdGVk IGNoZWNrcyBwZXJmb3JtZWQgYnkgdGhlIERvY3VtZW50DQpTaGVwaGVyZCB0byB2YWxpZGF0ZSBz ZWN0aW9ucyBvZiB0aGUgZG9jdW1lbnQgd3JpdHRlbiBpbiBhIGZvcm1hbA0KbGFuZ3VhZ2UsIHN1 Y2ggYXMgWE1MIGNvZGUsIEJORiBydWxlcywgTUlCIGRlZmluaXRpb25zLCBldGMuDQoNCglObyBm b3JtYWwgbGFuZ3VhZ2UgY29uc2lkZXJhdGlvbnMuDQoNCg0KDQo= From wwwrun@rfc-editor.org Wed Mar 20 22:29:23 2013 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 DE02421F8FA7; Wed, 20 Mar 2013 22:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, 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 rHGazsR-bizG; Wed, 20 Mar 2013 22:29:23 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 72B1F21F8FA5; Wed, 20 Mar 2013 22:29:23 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 05481B1E008; Wed, 20 Mar 2013 22:29:18 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130321052918.05481B1E008@rfc-editor.org> Date: Wed, 20 Mar 2013 22:29:18 -0700 (PDT) Cc: payload@ietf.org, rfc-editor@rfc-editor.org Subject: [payload] RFC 6884 on RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) 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, 21 Mar 2013 05:29:24 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6884 Title: RTP Payload Format for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW) Author: Z. Fang Status: Standards Track Stream: IETF Date: March 2013 Mailbox: zfang@qualcomm.com Pages: 21 Characters: 43207 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-rtp-evrc-nw-10.txt URL: http://www.rfc-editor.org/rfc/rfc6884.txt This document specifies Real-time Transport Protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as email. This document is a product of the Audio/Video Transport Payloads Working Group of the IETF. This is now a Proposed Standard. 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 fluffy@cisco.com Mon Mar 25 07:53:33 2013 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 336F511E80DF; Mon, 25 Mar 2013 07:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.399 X-Spam-Level: X-Spam-Status: No, score=-109.399 tagged_above=-999 required=5 tests=[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 RQxQx8qI3Tt5; Mon, 25 Mar 2013 07:53:32 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C05C511E80C5; Mon, 25 Mar 2013 07:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5760; q=dns/txt; s=iport; t=1364223212; x=1365432812; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vjYnUk1lutMBXRYCTgPbkatxsentgrAmCwLoN4T1OGM=; b=XCcFScQRqFCwHdP/cTX0B6xA0BUwChs4olE2UnTI9iD/uaQOZWmREDME KGplZAaECv2toehB30BZfXqNVveIfauRCvnvuk1mII0te14K+i6lduvUV OHCzzSLdBq+yoXs+ZrogcNJnp0wf80mg4kpm6H+8ZxdnxwP5vcXcky32Z c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKxjUFGtJXG//2dsb2JhbAA6CsVhggEWdIIkAQEBAwEBAQFrCwULAgEIDgoKGQsnCyUCBA4FCIgGBgzCcASNTQsGBYECAjEHgl9hA4hBimCUSoFUgTaBawgXHg X-IronPort-AV: E=Sophos;i="4.84,905,1355097600"; d="scan'208";a="191105024" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 25 Mar 2013 14:53:31 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2PErVoJ001069 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Mar 2013 14:53:31 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.155]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Mon, 25 Mar 2013 09:53:30 -0500 From: "Cullen Jennings (fluffy)" To: Stephan Wenger Thread-Topic: [payload] VP8 payload, decoder processing capabilities (was Re: [rtcweb] Resolution negotiation - a contribution) Thread-Index: AQHOKWiD6cOREVy9J0iAWauRubjUxw== Date: Mon, 25 Mar 2013 14:53:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <47C551C39BAFC143A10F91EF2DBBE92F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 25 Mar 2013 07:55:17 -0700 Cc: "rtcweb@ietf.org" , "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: Mon, 25 Mar 2013 14:53:33 -0000 I'd would find it very helpful to see the parameterization of Google hardwa= re implementations. It been said that anyone can get the CHDL/Verilog for t= his but I can't get it. Looking at that would help understand what are limi= tations of at least one hardware implementation. I think that would shed a = bunch of light on what might be needed.=20 On Apr 16, 2012, at 14:40 , Stephan Wenger wrote: > Hi all, >=20 > For context: Harald and myself have been at odds for a while now about th= e > 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 si= ze > 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 th= e > support of RFC 6236, which is not exactly a widely deployed technology. > Further, the a=3Dframerate attribute is not a particularly useful attribu= te > 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 co= de > 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 i= n > 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: >>>=20 >>> On 4.12.2012 12:08 , "Harald Alvestrand" wrote: >>>=20 >>>> 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 se= e >>>>> 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 negotiatio= n >>>>> (pixels per second processing requirement). >>>> Stephan, >>>>=20 >>>> 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 >=20 >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From harald@alvestrand.no Tue Mar 26 15:29:50 2013 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 4E0B321F85B0 for ; Tue, 26 Mar 2013 15:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.699 X-Spam-Level: X-Spam-Status: No, score=-109.699 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 jgLJXmzjgCxL for ; Tue, 26 Mar 2013 15:29:48 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 65D7221F85A1 for ; Tue, 26 Mar 2013 15:29:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id A20AE39E1BB for ; Tue, 26 Mar 2013 23:29:46 +0100 (CET) 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 jviv1WjHex9q for ; Tue, 26 Mar 2013 23:29:44 +0100 (CET) Received: from [IPv6:2001:470:de0a:27:d4a:939a:5855:2ae2] (unknown [IPv6:2001:470:de0a:27:d4a:939a:5855:2ae2]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 3CF8639E091 for ; Tue, 26 Mar 2013 23:29:44 +0100 (CET) Message-ID: <51522157.1060609@alvestrand.no> Date: Tue, 26 Mar 2013 23:29:43 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "payload@ietf.org" References: <5150A1AC.6020602@alvestrand.no> In-Reply-To: <5150A1AC.6020602@alvestrand.no> X-Forwarded-Message-Id: <5150A1AC.6020602@alvestrand.no> Content-Type: multipart/alternative; boundary="------------080605010708040405080405" Subject: [payload] Fwd: Re: [rtcweb] VP8 payload, decoder processing capabilities (was Re: 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, 26 Mar 2013 22:29:50 -0000 This is a multi-part message in MIME format. --------------080605010708040405080405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I noticed after replying on RTCWEB that Cullen had sent this to both rtcweb and payload, and realized that my response probably should be on payload as well. -------- Original Message -------- Subject: Re: [rtcweb] [payload] VP8 payload, decoder processing capabilities (was Re: Resolution negotiation - a contribution) Date: Mon, 25 Mar 2013 20:12:44 +0100 From: Harald Alvestrand To: rtcweb@ietf.org On 03/25/2013 03:53 PM, Cullen Jennings (fluffy) wrote: > I'd would find it very helpful to see the parameterization of Google hardware implementations. It been said that anyone can get the CHDL/Verilog forthis but I can't get it. Looking at that would help understand what are limitations of at least one hardware implementation. I think that would shed a bunch of light on what might be needed. Cullen, I still haven't seen the note from you with a copy of the note from Aki that said what the issue is with you getting access to the hardware design stuff. The message you quote below is almost one year old, and we added two new parameters to the VP8 SDP declaration after that specifically to address Stefan's point, and included the following text: 6.2.2. Offer/Answer Considerations The VP8 codec offers a decode complexity that is roughly linear with the number of pixels encoded. In some practical applications, there will be a need for negotiating frame rate and resolution, provided by the OPTIONAL parameters "max-fs" and "max-fr", in addition to these parameters, many practical applications will need a mean to communicate the max bitrate. The SDP endpoints MAY negotiate a method to communicate the maximum media bitrate, such as TMMBR in [RFC5104], therefore VP8 does not add any new mechanisms for this negotiation. The parameter "max-fr" and "max-fs" are defined in Section 6.1, where the macroblock size is 16x16 pixels as defined in [RFC6386]. In many practical applications, the max frame size and max frame rate are known from other information; if they are not constrained by other means, the max-fs and max-fr parameters MUST be used to establish these limits. > > On Apr 16, 2012, at 14:40 , 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 whethera >> 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 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --------------080605010708040405080405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I noticed after replying on RTCWEB that Cullen had sent this to both rtcweb and payload, and realized that my response probably should be on payload as well.


-------- Original Message --------
Subject: Re: [rtcweb] [payload] VP8 payload, decoder processing capabilities (was Re: Resolution negotiation - a contribution)
Date: Mon, 25 Mar 2013 20:12:44 +0100
From: Harald Alvestrand <harald@alvestrand.no>
To: rtcweb@ietf.org 


On 03/25/2013 03:53 PM, Cullen Jennings (fluffy) wrote:
> I'd would find it very helpful to see the parameterization of Google hardware implementations. It been said that anyone can get the CHDL/Verilog forthis but I can't get it. Looking at that would help understand what are limitations of at least one hardware implementation. I think that would shed a bunch of light on what might be needed.

Cullen, I still haven't seen the note from you with a copy of the note 
from Aki that said what the issue is with you getting access to the 
hardware design stuff.

The message you quote below is almost one year old, and we added two new 
parameters to the VP8 SDP declaration after that specifically to address 
Stefan's point, and included the following text:

6.2.2.  Offer/Answer Considerations

   The VP8 codec offers a decode complexity that is roughly linear with
   the number of pixels encoded.  In some practical applications, there
   will be a need for negotiating frame rate and resolution, provided by
   the OPTIONAL parameters "max-fs" and "max-fr", in addition to these
   parameters, many practical applications will need a mean to
   communicate the max bitrate.  The SDP endpoints MAY negotiate a
   method to communicate the maximum media bitrate, such as TMMBR in
   [RFC5104], therefore VP8 does not add any new mechanisms for this
   negotiation.  The parameter "max-fr" and "max-fs" are defined in
   Section 6.1, where the macroblock size is 16x16 pixels as defined in
   [RFC6386].  In many practical applications, the max frame size and
   max frame rate are known from other information; if they are not
   constrained by other means, the max-fs and max-fr parameters MUST be
   used to establish these limits.



>
> On Apr 16, 2012, at 14:40 , 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 whethera
>> 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" <harald@alvestrand.no> wrote:
>>
>>> On 04/12/2012 11:13 PM, Stephan Wenger wrote:
>>>> On 4.12.2012 12:08 , "Harald Alvestrand"<harald@alvestrand.no>  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
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


--------------080605010708040405080405-- From mramalho@cisco.com Thu Mar 28 11:04:05 2013 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 B336821F90B5 for ; Thu, 28 Mar 2013 11:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 R+BW93k+0jJW for ; Thu, 28 Mar 2013 11:04:03 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 61EE721F90B4 for ; Thu, 28 Mar 2013 11:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9337; q=dns/txt; s=iport; t=1364493843; x=1365703443; h=from:to:subject:date:message-id:mime-version; bh=PPiCScwpR3SX5/PufBfF+/jyP+JxfRyw8JsufCRywv4=; b=V+Cu1eLqVcJOPV0UZNWMHLTWQEz+qQqpIVz7hnKlJIvQS56y4kLH3lW6 GOlFzP31X/UR1rSnIJ52/i6GdpKAO2TSQnnMuERcOru8MEDCjTrnqIGE4 ZvNvORentH28uP/sdCysNaTB8UjSh75ja4QsjjHd7DbRpTqGWeXHs4Wuy 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAiFVFGtJXG//2dsb2JhbABDgkN3vnmBBBZ0gh8BAQECAQEtOQgdASpWJgEEGwESh3MGDJ4OoROJBYRGCxZ7gxdhA5gHj2mDC4FrCBce X-IronPort-AV: E=Sophos;i="4.87,927,1363132800"; d="scan'208,217";a="189618038" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 28 Mar 2013 18:04:02 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2SI424s007800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 28 Mar 2013 18:04:02 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.134]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 28 Mar 2013 13:04:02 -0500 From: "Michael Ramalho (mramalho)" To: "payload@ietf.org" Thread-Topic: Request for G.711 RTP Payload Format to be adopted as a PAYLOAD work item Thread-Index: Ac4r3n/+B1SdXLETRwWJfC71TBmvqw== Date: Thu, 28 Mar 2013 18:04:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.125.229] Content-Type: multipart/alternative; boundary="_000_D21571530BF9644D9A443D6BD95B9103154F9ACCxmbrcdx12ciscoc_" MIME-Version: 1.0 Subject: [payload] Request for G.711 RTP Payload Format to be adopted as a PAYLOAD work item 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, 28 Mar 2013 18:04:05 -0000 --_000_D21571530BF9644D9A443D6BD95B9103154F9ACCxmbrcdx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ali Begen, Roni Even (PAYLOAD WG Chairs) and Payload WG, This email requests that the RTP payload format for ITU-T Rec. G.711.0 be a= formal work item for the PAYLOAD WG. The G.711.0 RTP payload draft (draft-ramalho-payload-g7110) has been discus= sed at past IETFs and is listed as a "related document" for the PAYLOAD wor= king group (see: http://datatracker.ietf.org/wg/payload/). The history/chronology of G.711.0 work in the IETF Payload Working Group fo= llows after my signature for those interested. If adopted, a milestone submit date of December 2013 is suggested. Regards, Michael Ramalho >>Chronology of G.711.0 Work in the IETF PAYLOAD WG<< >> IETF 81 Quebec, Canada, July 24-29, 2011 I presented the G.711.0 "Compression Segments" draft at the PAYLOAD meeting= held within the AVTEXT timeslot. This draft was a combination of a "G.711-= like" RTP payload specification and text describing how G.711.0 could be us= ed as a lossless compression mechanism for "G.711.0 segments" of an end-to-= end G.711 session. In discussion that ensued at that meeting it was decided that this draft sh= ould be split into two drafts: Draft 1: "G.711.0 RTP Payload Format" draft (targeted as standards track RF= C), and Draft 2: "G.711.0 Use Cases" draft (targeted as informational RFC). Soon after IETF 81 this was accomplished by the following drafts: draft-ram= alho-payload-g7110-01.txt (G.711.0 RTP payload format) and draft-ramalho-g7= 110-segments-00.txt (G.711.0 "use cases"). As the G.711.0 payload draft is nearly identical to the G.711 RTP payload s= pecification, there was little debate on the mailing lists about it outside= of the storage mode definition (the G.711 RTP payload specification did no= t have a storage mode defined). >>IETF 83 Paris, France, March 27, 2012 I presented: draft-ramalho-g7110-segments-00 during the PAYLOAD segment ins= ide of the AVTEXT meeting slot (http://www.ietf.org/proceedings/83/slides/s= lides-83-avtext-6.pdf ). I did not present on the G.711.0 payload format draft, as the only issue be= ing debated on the list for this draft was the storage mode - and the stora= ge mode agreements were converging to a solution on the mailing list. I renewed the G.711.0 RTP payload specification with a new version (draft-r= amalho-payload-g7110-02.txt) which captured the email discussions on the st= orage mode issues. I let the use case draft (draft-ramalho-g7110-segments-00) expire due to la= ck of interest on the mailing list. I believe interest will revive when the= payload specification is complete. >>Summary: This email requests the G.711.0 RTP Payload Format be a formal w= orking group item with an associated milestone (December 2013 suggested). --_000_D21571530BF9644D9A443D6BD95B9103154F9ACCxmbrcdx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ali Begen, Roni Even (PAYLOAD WG Chairs) and Payload= WG,

 

This email requests that the RTP payload format for = ITU-T Rec. G.711.0 be a formal work item for the PAYLOAD WG.

 

The G.711.0 RTP payload draft (draft-ramalho-payload= -g7110) has been discussed at past IETFs and is listed as a “related = document” for the PAYLOAD working group (see: http://datatracker.ietf= .org/wg/payload/).

 

The history/chronology of G.711.0 work in the IETF P= ayload Working Group follows after my signature for those interested.<= /o:p>

 

If adopted, a milestone submit date of December 2013= is suggested.

 

Regards,

 

Michael Ramalho

 

>>Chronology of G.711.0 Work in the IETF PAYLO= AD WG<<

 

>> IETF 81 Quebec, Canada, July 24-29, 2011

 

I presented the G.711.0 “Compression Segments&= #8221; draft at the PAYLOAD meeting held within the AVTEXT timeslot. This d= raft was a combination of a “G.711-like” RTP payload specificat= ion and text describing how G.711.0 could be used as a lossless compression mechanism for “G.711.0 segments” of an end-to-end = G.711 session.

 

In discussion that ensued at that meeting it was dec= ided that this draft should be split into two drafts:

 

Draft 1: “G.711.0 RTP Payload Format” dr= aft (targeted as standards track RFC), and

Draft 2: “G.711.0 Use Cases” draft (targ= eted as informational RFC).

 

Soon after IETF 81 this was accomplished by the foll= owing drafts: draft-ramalho-payload-g7110-01.txt (G.711.0 RTP payload forma= t) and draft-ramalho-g7110-segments-00.txt (G.711.0 “use cases”= ).

 

As the G.711.0 payload draft is nearly identical to = the G.711 RTP payload specification, there was little debate on the mailing= lists about it outside of the storage mode definition (the G.711 RTP paylo= ad specification did not have a storage mode defined).

 

>>IETF 83 Paris, France, March 27, 2012

 

I presented: draft-ramalho-g7110-segments-00 during = the PAYLOAD segment inside of the AVTEXT meeting slot (http://www.ietf.org/= proceedings/83/slides/slides-83-avtext-6.pdf ).

 

I did not present on the G.711.0 payload format draf= t, as the only issue being debated on the list for this draft was the stora= ge mode – and the storage mode agreements were converging to a soluti= on on the mailing list.

 

I renewed the G.711.0 RTP payload specification with= a new version (draft-ramalho-payload-g7110-02.txt) which captured the emai= l discussions on the storage mode issues.

 

I let the use case draft (draft-ramalho-g7110-segmen= ts-00) expire due to lack of interest on the mailing list. I believe intere= st will revive when the payload specification is complete.

 

>>Summary: This email requests the G.711.0 RTP= Payload Format be a formal working group item with an associated milestone= (December 2013 suggested).

--_000_D21571530BF9644D9A443D6BD95B9103154F9ACCxmbrcdx12ciscoc_-- From paulej@packetizer.com Thu Mar 28 11:21:52 2013 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 28FC321F9012 for ; Thu, 28 Mar 2013 11:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=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 hDZuvRRg-no6 for ; Thu, 28 Mar 2013 11:21:49 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id BAD3621F8ECC for ; Thu, 28 Mar 2013 11:21:49 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r2SILlLd008614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Mar 2013 14:21:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1364494908; bh=UgQ41rxtZU5QnLtNs+DJAdNOrAPqI7f8MMmGmhMuqi0=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=VCRbBuTqnBL+an6iSVNmWvP+59dE64rSFox0gDws5f+rNrOv8Myye0vptgi2ABCAZ a8L9Q3ozs5VZ70UntHms6uRCXv03NLuM3J+ouCDYUAwcc+FwqCVfQD6vhA1/UemJ/i Ne5kBbeqUEh+E2c489WOKW2QTkBUVWE/ZNmosVRE= From: "Paul E. Jones" To: "'Michael Ramalho \(mramalho\)'" , References: In-Reply-To: Date: Thu, 28 Mar 2013 14:22:12 -0400 Message-ID: <04b601ce2be1$2aeca1b0$80c5e510$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04B7_01CE2BBF.A3DBC500" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHHxFOZWbbWHBMs87aWSLc8uyGgPZjIOVDA Content-Language: en-us Subject: Re: [payload] Request for G.711 RTP Payload Format to be adopted as a PAYLOAD work item 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, 28 Mar 2013 18:21:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_04B7_01CE2BBF.A3DBC500 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Though it should go without saying, I certainly support this request. Paul From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Michael Ramalho (mramalho) Sent: Thursday, March 28, 2013 2:04 PM To: payload@ietf.org Subject: [payload] Request for G.711 RTP Payload Format to be adopted as a PAYLOAD work item Ali Begen, Roni Even (PAYLOAD WG Chairs) and Payload WG, This email requests that the RTP payload format for ITU-T Rec. G.711.0 be a formal work item for the PAYLOAD WG. The G.711.0 RTP payload draft (draft-ramalho-payload-g7110) has been discussed at past IETFs and is listed as a "related document" for the PAYLOAD working group (see: http://datatracker.ietf.org/wg/payload/). The history/chronology of G.711.0 work in the IETF Payload Working Group follows after my signature for those interested. If adopted, a milestone submit date of December 2013 is suggested. Regards, Michael Ramalho >>Chronology of G.711.0 Work in the IETF PAYLOAD WG<< >> IETF 81 Quebec, Canada, July 24-29, 2011 I presented the G.711.0 "Compression Segments" draft at the PAYLOAD meeting held within the AVTEXT timeslot. This draft was a combination of a "G.711-like" RTP payload specification and text describing how G.711.0 could be used as a lossless compression mechanism for "G.711.0 segments" of an end-to-end G.711 session. In discussion that ensued at that meeting it was decided that this draft should be split into two drafts: Draft 1: "G.711.0 RTP Payload Format" draft (targeted as standards track RFC), and Draft 2: "G.711.0 Use Cases" draft (targeted as informational RFC). Soon after IETF 81 this was accomplished by the following drafts: draft-ramalho-payload-g7110-01.txt (G.711.0 RTP payload format) and draft-ramalho-g7110-segments-00.txt (G.711.0 "use cases"). As the G.711.0 payload draft is nearly identical to the G.711 RTP payload specification, there was little debate on the mailing lists about it outside of the storage mode definition (the G.711 RTP payload specification did not have a storage mode defined). >>IETF 83 Paris, France, March 27, 2012 I presented: draft-ramalho-g7110-segments-00 during the PAYLOAD segment inside of the AVTEXT meeting slot (http://www.ietf.org/proceedings/83/slides/slides-83-avtext-6.pdf ). I did not present on the G.711.0 payload format draft, as the only issue being debated on the list for this draft was the storage mode - and the storage mode agreements were converging to a solution on the mailing list. I renewed the G.711.0 RTP payload specification with a new version (draft-ramalho-payload-g7110-02.txt) which captured the email discussions on the storage mode issues. I let the use case draft (draft-ramalho-g7110-segments-00) expire due to lack of interest on the mailing list. I believe interest will revive when the payload specification is complete. >>Summary: This email requests the G.711.0 RTP Payload Format be a formal working group item with an associated milestone (December 2013 suggested). ------=_NextPart_000_04B7_01CE2BBF.A3DBC500 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Though it should go without saying, I certainly = support this request.

 

Paul

 

From:= = payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Michael Ramalho (mramalho)
Sent: Thursday, March 28, = 2013 2:04 PM
To: payload@ietf.org
Subject: [payload] = Request for G.711 RTP Payload Format to be adopted as a PAYLOAD work = item

 

Ali Begen, = Roni Even (PAYLOAD WG Chairs) and Payload WG,

 

This email = requests that the RTP payload format for ITU-T Rec. G.711.0 be a formal = work item for the PAYLOAD WG.

 

The G.711.0 = RTP payload draft (draft-ramalho-payload-g7110) has been discussed at = past IETFs and is listed as a “related document” for the = PAYLOAD working group (see: http://datatracker.ietf.= org/wg/payload/).

 

The = history/chronology of G.711.0 work in the IETF Payload Working Group = follows after my signature for those interested.

 

If adopted, = a milestone submit date of December 2013 is suggested.

 

Regards,

 

Michael = Ramalho

 

>>Chronology of G.711.0 Work in the IETF PAYLOAD = WG<<

 

>> IETF 81 Quebec, Canada, July 24-29, = 2011

 

I presented the G.711.0 “Compression = Segments” draft at the PAYLOAD meeting held within the AVTEXT = timeslot. This draft was a combination of a “G.711-like” RTP = payload specification and text describing how G.711.0 could be used as a = lossless compression mechanism for “G.711.0 segments” of an = end-to-end G.711 session.

 

In = discussion that ensued at that meeting it was decided that this draft = should be split into two drafts:

 

Draft 1: = “G.711.0 RTP Payload Format” draft (targeted as standards = track RFC), and

Draft 2: = “G.711.0 Use Cases” draft (targeted as informational = RFC).

 

Soon after IETF 81 this was accomplished by the = following drafts: draft-ramalho-payload-g7110-01.txt (G.711.0 RTP = payload format) and draft-ramalho-g7110-segments-00.txt (G.711.0 = “use cases”).

 

As the = G.711.0 payload draft is nearly identical to the G.711 RTP payload = specification, there was little debate on the mailing lists about it = outside of the storage mode definition (the G.711 RTP payload = specification did not have a storage mode defined).

 

>>IETF = 83 Paris, France, March 27, 2012

 

I presented: = draft-ramalho-g7110-segments-00 during the PAYLOAD segment inside of the = AVTEXT meeting slot (http://www.ietf.org/proceedings/83/slides/slides-83-avtext-6.pdf = ).

 

I did not present on the G.711.0 payload format draft, = as the only issue being debated on the list for this draft was the = storage mode – and the storage mode agreements were converging to = a solution on the mailing list.

 

I renewed = the G.711.0 RTP payload specification with a new version = (draft-ramalho-payload-g7110-02.txt) which captured the email = discussions on the storage mode issues.

 

I let the = use case draft (draft-ramalho-g7110-segments-00) expire due to lack of = interest on the mailing list. I believe interest will revive when the = payload specification is complete.

 

>>Summary: This email requests the G.711.0 RTP = Payload Format be a formal working group item with an associated = milestone (December 2013 = suggested).

------=_NextPart_000_04B7_01CE2BBF.A3DBC500-- From simao.campos@itu.int Thu Mar 28 12:37:14 2013 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 CD33521F8E9E for ; Thu, 28 Mar 2013 12:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 93z8aFG6QiGL for ; Thu, 28 Mar 2013 12:37:12 -0700 (PDT) Received: from kapur.svc.unicc.org (kapur.svc.unicc.org [193.194.138.75]) by ietfa.amsl.com (Postfix) with ESMTP id ED85021F8E8F for ; Thu, 28 Mar 2013 12:37:11 -0700 (PDT) Received: from chicha.svc.unicc.org (chicha.svc.unicc.org [192.168.202.41]) by kapur.svc.unicc.org (Switch-3.1.7/Switch-3.1.7) with ESMTP id r2SJb6vR007454; Thu, 28 Mar 2013 20:37:06 +0100 Received: from lati.svc.unicc.org (localhost.localdomain [127.0.0.1]) by chicha.svc.unicc.org (Switch-3.1.7/Switch-3.1.7) with ESMTP id r2SJb8D8021615; Thu, 28 Mar 2013 20:37:08 +0100 Received: from mailweb.itu.int ([10.81.38.61]) by lati.svc.unicc.org (Switch-3.1.7/Switch-3.1.7) with ESMTP id r2SJb8B7031926; Thu, 28 Mar 2013 20:37:08 +0100 Received: from TUCHM02.TUECSP.UNICC.ORG ([169.254.2.229]) by TUCHM04.TUECSP.UNICC.ORG ([169.254.1.216]) with mapi id 14.02.0318.004; Thu, 28 Mar 2013 19:37:07 +0000 From: "Campos, Simao" To: "payload@ietf.org" Thread-Topic: [payload] Request for G.711 RTP Payload Format to be adopted as a PAYLOAD work item Thread-Index: Ac4r3n/+B1SdXLETRwWJfC71TBmvqwADFeAQ Date: Thu, 28 Mar 2013 19:37:07 +0000 Message-ID: <47625A4A3006CE47BB72AF5BC1EBBEFD90F8A98A@TUCHM02.TUECSP.UNICC.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.81.64.160] Content-Type: multipart/alternative; boundary="_000_47625A4A3006CE47BB72AF5BC1EBBEFD90F8A98ATUCHM02TUECSPUN_" MIME-Version: 1.0 Subject: Re: [payload] Request for G.711 RTP Payload Format to be adopted as a PAYLOAD work item 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, 28 Mar 2013 19:37:14 -0000 --_000_47625A4A3006CE47BB72AF5BC1EBBEFD90F8A98ATUCHM02TUECSPUN_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable G.711.0 has been adopted in 2009, however for deployment over IP a standard= RTP packetization format is needed, hence I'd support Michael's proposal t= o have the G.711.0 RTP Payload Format as a formal working group item with a= n associated milestone. Sim=E3o Campos ITU-T SG16 Secretariat From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Michael Ramalho (mramalho) Sent: Thursday, March 28, 2013 7:04 PM To: payload@ietf.org Subject: [payload] Request for G.711 RTP Payload Format to be adopted as a = PAYLOAD work item Ali Begen, Roni Even (PAYLOAD WG Chairs) and Payload WG, This email requests that the RTP payload format for ITU-T Rec. G.711.0 be a= formal work item for the PAYLOAD WG. The G.711.0 RTP payload draft (draft-ramalho-payload-g7110) has been discus= sed at past IETFs and is listed as a "related document" for the PAYLOAD wor= king group (see: http://datatracker.ietf.org/wg/payload/). The history/chronology of G.711.0 work in the IETF Payload Working Group fo= llows after my signature for those interested. If adopted, a milestone submit date of December 2013 is suggested. Regards, Michael Ramalho >>Chronology of G.711.0 Work in the IETF PAYLOAD WG<< >> IETF 81 Quebec, Canada, July 24-29, 2011 I presented the G.711.0 "Compression Segments" draft at the PAYLOAD meeting= held within the AVTEXT timeslot. This draft was a combination of a "G.711-= like" RTP payload specification and text describing how G.711.0 could be us= ed as a lossless compression mechanism for "G.711.0 segments" of an end-to-= end G.711 session. In discussion that ensued at that meeting it was decided that this draft sh= ould be split into two drafts: Draft 1: "G.711.0 RTP Payload Format" draft (targeted as standards track RF= C), and Draft 2: "G.711.0 Use Cases" draft (targeted as informational RFC). Soon after IETF 81 this was accomplished by the following drafts: draft-ram= alho-payload-g7110-01.txt (G.711.0 RTP payload format) and draft-ramalho-g7= 110-segments-00.txt (G.711.0 "use cases"). As the G.711.0 payload draft is nearly identical to the G.711 RTP payload s= pecification, there was little debate on the mailing lists about it outside= of the storage mode definition (the G.711 RTP payload specification did no= t have a storage mode defined). >>IETF 83 Paris, France, March 27, 2012 I presented: draft-ramalho-g7110-segments-00 during the PAYLOAD segment ins= ide of the AVTEXT meeting slot (http://www.ietf.org/proceedings/83/slides/s= lides-83-avtext-6.pdf ). I did not present on the G.711.0 payload format draft, as the only issue be= ing debated on the list for this draft was the storage mode - and the stora= ge mode agreements were converging to a solution on the mailing list. I renewed the G.711.0 RTP payload specification with a new version (draft-r= amalho-payload-g7110-02.txt) which captured the email discussions on the st= orage mode issues. I let the use case draft (draft-ramalho-g7110-segments-00) expire due to la= ck of interest on the mailing list. I believe interest will revive when the= payload specification is complete. >>Summary: This email requests the G.711.0 RTP Payload Format be a formal w= orking group item with an associated milestone (December 2013 suggested). --_000_47625A4A3006CE47BB72AF5BC1EBBEFD90F8A98ATUCHM02TUECSPUN_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

G.711.0 has been adopt= ed in 2009, however for deployment over IP a standard RTP packetization for= mat is needed, hence I'd support Michael's proposal to have the G.711.0 RTP= Payload Format as a formal working group item with an associated milestone.

 

Sim=E3o= Campos

ITU-T S= G16 Secretariat

&n= bsp;

From: payload-= bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Michael Ramalho (mramalho)
Sent: Thursday, March 28, 2013 7:04 PM
To: payload@ietf.org
Subject: [payload] Request for G.711 RTP Payload Format to be adopte= d as a PAYLOAD work item

 

Ali Begen, Roni Even (PAYLOAD WG Chairs) and Payload= WG,

 

This email requests that the RTP payload format for = ITU-T Rec. G.711.0 be a formal work item for the PAYLOAD WG.

 

The G.711.0 RTP payload draft (draft-ramalho-payload= -g7110) has been discussed at past IETFs and is listed as a “related = document” for the PAYLOAD working group (see: http://datatracker.ietf= .org/wg/payload/).

 

The history/chronology of G.711.0 work in the IETF P= ayload Working Group follows after my signature for those interested.<= /o:p>

 

If adopted, a milestone submit date of December 2013= is suggested.

 

Regards,

 

Michael Ramalho

 

>>Chronology of G.711.0 Work in the IETF PAYLO= AD WG<<

 

>> IETF 81 Quebec, Canada, July 24-29, 2011

 

I presented the G.711.0 “Compression Segments&= #8221; draft at the PAYLOAD meeting held within the AVTEXT timeslot. This d= raft was a combination of a “G.711-like” RTP payload specificat= ion and text describing how G.711.0 could be used as a lossless compression mechanism for “G.711.0 segments” of an end-to-end = G.711 session.

 

In discussion that ensued at that meeting it was dec= ided that this draft should be split into two drafts:

 

Draft 1: “G.711.0 RTP Payload Format” dr= aft (targeted as standards track RFC), and

Draft 2: “G.711.0 Use Cases” draft (targ= eted as informational RFC).

 

Soon after IETF 81 this was accomplished by the foll= owing drafts: draft-ramalho-payload-g7110-01.txt (G.711.0 RTP payload forma= t) and draft-ramalho-g7110-segments-00.txt (G.711.0 “use cases”= ).

 

As the G.711.0 payload draft is nearly identical to = the G.711 RTP payload specification, there was little debate on the mailing= lists about it outside of the storage mode definition (the G.711 RTP paylo= ad specification did not have a storage mode defined).

 

>>IETF 83 Paris, France, March 27, 2012

 

I presented: draft-ramalho-g7110-segments-00 during = the PAYLOAD segment inside of the AVTEXT meeting slot (http://www.ietf.or= g/proceedings/83/slides/slides-83-avtext-6.pdf ).

 

I did not present on the G.711.0 payload format draf= t, as the only issue being debated on the list for this draft was the stora= ge mode – and the storage mode agreements were converging to a soluti= on on the mailing list.

 

I renewed the G.711.0 RTP payload specification with= a new version (draft-ramalho-payload-g7110-02.txt) which captured the emai= l discussions on the storage mode issues.

 

I let the use case draft (draft-ramalho-g7110-segmen= ts-00) expire due to lack of interest on the mailing list. I believe intere= st will revive when the payload specification is complete.

 

>>Summary: This email requests the G.711.0 RTP= Payload Format be a formal working group item with an associated milestone= (December 2013 suggested).

--_000_47625A4A3006CE47BB72AF5BC1EBBEFD90F8A98ATUCHM02TUECSPUN_-- From dwing@cisco.com Thu Mar 28 11:56:14 2013 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 8563D21F8EE8 for ; Thu, 28 Mar 2013 11:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.475 X-Spam-Level: X-Spam-Status: No, score=-110.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 JfCZXiqpBb2P for ; Thu, 28 Mar 2013 11:56:13 -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 928FC21F8ED6 for ; Thu, 28 Mar 2013 11:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12996; q=dns/txt; s=iport; t=1364496973; x=1365706573; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=q68+pnGxueg3FnwGPMREfvrxqxecZsdPfaRfewMVthU=; b=PikU4zhilS5SVaFQaaWXfGoph+wDt4IRgvYJplvdMs4/JbwycZwXCu4k z4S+R/TFZrDBAgPpP/sZwZS45MMRhOL5WtsR+ZwcD+VYDBu8eB2XjO7xR 1fLeCbdDvaX05w6VYi0DhgQCMqtJiK7E8Jd23w7bhXWT4rceSGoCb+75Q Q=; X-IronPort-AV: E=Sophos;i="4.87,367,1363132800"; d="scan'208,217";a="76924145" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 28 Mar 2013 18:56:13 +0000 Received: from [10.32.240.194] ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2SIuC7r028536; Thu, 28 Mar 2013 18:56:12 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_66951549-A1BA-41D1-882B-2C647F7FA5BB" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dan Wing In-Reply-To: Date: Thu, 28 Mar 2013 11:56:11 -0700 Message-Id: References: To: Michael Ramalho (mramalho) X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Thu, 28 Mar 2013 15:19:32 -0700 Cc: "payload@ietf.org" Subject: Re: [payload] Request for G.711 RTP Payload Format to be adopted as a PAYLOAD work item 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, 28 Mar 2013 18:56:14 -0000 --Apple-Mail=_66951549-A1BA-41D1-882B-2C647F7FA5BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 (I left the subject line intact, but was tempted to adjust the subject = line to say G.711.0). I support adopting G.711.0 by PAYLOAD as a new RTP payload format. For = better or worse, G.711 is widely deployed and G.711.0 provides losses = compression of that widely-deployed codec. -d On Mar 28, 2013, at 11:04 AM, Michael Ramalho (mramalho) = wrote: > Ali Begen, Roni Even (PAYLOAD WG Chairs) and Payload WG, > =20 > This email requests that the RTP payload format for ITU-T Rec. G.711.0 = be a formal work item for the PAYLOAD WG. > =20 > The G.711.0 RTP payload draft (draft-ramalho-payload-g7110) has been = discussed at past IETFs and is listed as a =93related document=94 for = the PAYLOAD working group (see: = http://datatracker.ietf.org/wg/payload/). > =20 > The history/chronology of G.711.0 work in the IETF Payload Working = Group follows after my signature for those interested. > =20 > If adopted, a milestone submit date of December 2013 is suggested. > =20 > Regards, > =20 > Michael Ramalho > =20 > >>Chronology of G.711.0 Work in the IETF PAYLOAD WG<< > =20 > >> IETF 81 Quebec, Canada, July 24-29, 2011 > =20 > I presented the G.711.0 =93Compression Segments=94 draft at the = PAYLOAD meeting held within the AVTEXT timeslot. This draft was a = combination of a =93G.711-like=94 RTP payload specification and text = describing how G.711.0 could be used as a lossless compression mechanism = for =93G.711.0 segments=94 of an end-to-end G.711 session. > =20 > In discussion that ensued at that meeting it was decided that this = draft should be split into two drafts: > =20 > Draft 1: =93G.711.0 RTP Payload Format=94 draft (targeted as standards = track RFC), and > Draft 2: =93G.711.0 Use Cases=94 draft (targeted as informational = RFC). > =20 > Soon after IETF 81 this was accomplished by the following drafts: = draft-ramalho-payload-g7110-01.txt (G.711.0 RTP payload format) and = draft-ramalho-g7110-segments-00.txt (G.711.0 =93use cases=94). > =20 > As the G.711.0 payload draft is nearly identical to the G.711 RTP = payload specification, there was little debate on the mailing lists = about it outside of the storage mode definition (the G.711 RTP payload = specification did not have a storage mode defined). > =20 > >>IETF 83 Paris, France, March 27, 2012 > =20 > I presented: draft-ramalho-g7110-segments-00 during the PAYLOAD = segment inside of the AVTEXT meeting slot = (http://www.ietf.org/proceedings/83/slides/slides-83-avtext-6.pdf ). > =20 > I did not present on the G.711.0 payload format draft, as the only = issue being debated on the list for this draft was the storage mode =96 = and the storage mode agreements were converging to a solution on the = mailing list. > =20 > I renewed the G.711.0 RTP payload specification with a new version = (draft-ramalho-payload-g7110-02.txt) which captured the email = discussions on the storage mode issues. > =20 > I let the use case draft (draft-ramalho-g7110-segments-00) expire due = to lack of interest on the mailing list. I believe interest will revive = when the payload specification is complete. > =20 > >>Summary: This email requests the G.711.0 RTP Payload Format be a = formal working group item with an associated milestone (December 2013 = suggested). --Apple-Mail=_66951549-A1BA-41D1-882B-2C647F7FA5BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
(I left the subject line = intact, but was tempted to adjust the subject line to say = G.711.0).

I support adopting G.711.0 by = PAYLOAD as a new RTP payload format.  For better or worse, G.711 is = widely deployed and G.711.0 provides losses compression of that = widely-deployed = codec.

-d

On Mar 28, = 2013, at 11:04 AM, Michael Ramalho (mramalho) <mramalho@cisco.com> = wrote:

Ali Begen, Roni Even (PAYLOAD WG Chairs) and = Payload WG,
This email requests = that the RTP payload format for ITU-T Rec. G.711.0 be a formal work item = for the PAYLOAD WG.
The G.711.0 RTP = payload draft (draft-ramalho-payload-g7110) has been discussed at past = IETFs and is listed as a =93related document=94 for the PAYLOAD working = group (see:  

= --Apple-Mail=_66951549-A1BA-41D1-882B-2C647F7FA5BB-- From mperumal@cisco.com Sat Mar 30 08:00:19 2013 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 5BE2B21F848B for ; Sat, 30 Mar 2013 08:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 wBWKYeOuYWfe for ; Sat, 30 Mar 2013 08:00:16 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 4477A21F84AF for ; Sat, 30 Mar 2013 08:00:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17842; q=dns/txt; s=iport; t=1364655616; x=1365865216; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=h2jl+DeXGjOqlhCTqfSujOOQf93KJmAzeX4HZ5ueGWc=; b=hgNQ+vvTDLOYaJ/odO0o5Q1oWDtLX/gC+JMoeD3o4Uqma0pTGV5ouElz iQCQulwx3kVRW2RnplFVwGT0tFSevPT3WNPb9he2QRGWuI3sT7YVXwtvN vdLQEORqTQnsJTNwXDDXgDdoJNIMuNsZ1rCwU/CjGuyNp24klEGtWBfVW A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnIFAGb9VlGtJV2Y/2dsb2JhbABDgkN3rgeJMYgygQwWdIIfAQEBAgEBLTkICxACAQgRBAEBCx0HMhQJCAIEAQ0FCAESh3MGDL9LiReETQsWeyYLBgGCX2EDmAqPbIFVgTaBawgXHg X-IronPort-AV: E=Sophos;i="4.87,378,1363132800"; d="scan'208,217";a="193191428" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 30 Mar 2013 15:00:15 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2UF0FbX008364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 30 Mar 2013 15:00:15 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.47]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Sat, 30 Mar 2013 10:00:15 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "Dan Wing (dwing)" , "Michael Ramalho (mramalho)" Thread-Topic: [payload] Request for G.711 RTP Payload Format to be adopted as a PAYLOAD work item Thread-Index: AQHOLAJUSgkhBahdvUiJfZPjV3TXjZi73dBw Date: Sat, 30 Mar 2013 15:00:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.56.187] Content-Type: multipart/alternative; boundary="_000_E721D8C6A2E1544DB2DEBC313AF54DE224058DCDxmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "payload@ietf.org" Subject: Re: [payload] Request for G.711 RTP Payload Format to be adopted as a PAYLOAD work item 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: Sat, 30 Mar 2013 15:00:19 -0000 --_000_E721D8C6A2E1544DB2DEBC313AF54DE224058DCDxmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I too support adoption of this work in PAYLOAD. (To add to Dan, the G.711.0 compression is stateless as well) Muthu From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Dan Wing (dwing) Sent: Friday, March 29, 2013 12:26 AM To: Michael Ramalho (mramalho) Cc: payload@ietf.org Subject: Re: [payload] Request for G.711 RTP Payload Format to be adopted a= s a PAYLOAD work item (I left the subject line intact, but was tempted to adjust the subject line= to say G.711.0). I support adopting G.711.0 by PAYLOAD as a new RTP payload format. For bet= ter or worse, G.711 is widely deployed and G.711.0 provides losses compress= ion of that widely-deployed codec. -d On Mar 28, 2013, at 11:04 AM, Michael Ramalho (mramalho) > wrote: Ali Begen, Roni Even (PAYLOAD WG Chairs) and Payload WG, This email requests that the RTP payload format for ITU-T Rec. G.711.0 be a= formal work item for the PAYLOAD WG. The G.711.0 RTP payload draft (draft-ramalho-payload-g7110) has been discus= sed at past IETFs and is listed as a "related document" for the PAYLOAD wor= king group (see: http://datatracker.ietf.org/wg/payload/). The history/chronology of G.711.0 work in the IETF Payload Working Group fo= llows after my signature for those interested. If adopted, a milestone submit date of December 2013 is suggested. Regards, Michael Ramalho >>Chronology of G.711.0 Work in the IETF PAYLOAD WG<< >> IETF 81 Quebec, Canada, July 24-29, 2011 I presented the G.711.0 "Compression Segments" draft at the PAYLOAD meeting= held within the AVTEXT timeslot. This draft was a combination of a "G.711-= like" RTP payload specification and text describing how G.711.0 could be us= ed as a lossless compression mechanism for "G.711.0 segments" of an end-to-= end G.711 session. In discussion that ensued at that meeting it was decided that this draft sh= ould be split into two drafts: Draft 1: "G.711.0 RTP Payload Format" draft (targeted as standards track RF= C), and Draft 2: "G.711.0 Use Cases" draft (targeted as informational RFC). Soon after IETF 81 this was accomplished by the following drafts: draft-ram= alho-payload-g7110-01.txt (G.711.0 RTP payload format) and draft-ramalho-g7= 110-segments-00.txt (G.711.0 "use cases"). As the G.711.0 payload draft is nearly identical to the G.711 RTP payload s= pecification, there was little debate on the mailing lists about it outside= of the storage mode definition (the G.711 RTP payload specification did no= t have a storage mode defined). >>IETF 83 Paris, France, March 27, 2012 I presented: draft-ramalho-g7110-segments-00 during the PAYLOAD segment ins= ide of the AVTEXT meeting slot (http://www.ietf.org/proceedings/83/slides/s= lides-83-avtext-6.pdf ). I did not present on the G.711.0 payload format draft, as the only issue be= ing debated on the list for this draft was the storage mode - and the stora= ge mode agreements were converging to a solution on the mailing list. I renewed the G.711.0 RTP payload specification with a new version (draft-r= amalho-payload-g7110-02.txt) which captured the email discussions on the st= orage mode issues. I let the use case draft (draft-ramalho-g7110-segments-00) expire due to la= ck of interest on the mailing list. I believe interest will revive when the= payload specification is complete. >>Summary: This email requests the G.711.0 RTP Payload Format be a formal w= orking group item with an associated milestone (December 2013 suggested). --_000_E721D8C6A2E1544DB2DEBC313AF54DE224058DCDxmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I too support adoption of this work in PAYLOAD.

 

(To add to Dan, the G.711.0 compression is stateless as we= ll)

 

Muthu

 

From: payload-= bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Dan Wing (dwing)
Sent: Friday, March 29, 2013 12:26 AM
To: Michael Ramalho (mramalho)
Cc: payload@ietf.org
Subject: Re: [payload] Request for G.711 RTP Payload Format to be ad= opted as a PAYLOAD work item

 

(I left the subject line intact, but was tempted to = adjust the subject line to say G.711.0).

 

I support adopting G.711.0 by PAYLOAD as a new = RTP payload format.  For better or worse, G.711 is widely deployed and= G.711.0 provides losses compression of that widely-deployed codec.

 

-d

 



Ali Begen, Roni Even (PAYLOAD WG Chairs= ) and Payload WG,

 

This email requests that the RTP payloa= d format for ITU-T Rec. G.711.0 be a formal work item for the PAYLOAD WG.

 

The G.711.0 RTP payload draft (draft-ra= malho-payload-g7110) has been discussed at past IETFs and is listed as a &#= 8220;related document” for the PAYLOAD working group (see: http://datatracker.ietf.org/w= g/payload/).

 

The history/chronology of G.711.0 work = in the IETF Payload Working Group follows after my signature for those inte= rested.

 

If adopted, a milestone submit date of = December 2013 is suggested.

 

Regards,

 

Michael Ramalho

 

>>Chronology of G.711.0 Work in t= he IETF PAYLOAD WG<<

 

>> IETF 81 Quebec, Canada, July 2= 4-29, 2011

 

I presented the G.711.0 “Compress= ion Segments” draft at the PAYLOAD meeting held within the AVTEXT tim= eslot. This draft was a combination of a “G.711-like” RTP paylo= ad specification and text describing how G.711.0 could be used as a lossless compression me= chanism for “G.711.0 segments” of an end-to-end G.711 session.<= o:p>

 

In discussion that ensued at that meeti= ng it was decided that this draft should be split into two drafts:

 

Draft 1: “G.711.0 RTP Payload For= mat” draft (targeted as standards track RFC), and

Draft 2: “G.711.0 Use Cases”= ; draft (targeted as informational RFC).

 

Soon after IETF 81 this was accomplishe= d by the following drafts: draft-ramalho-payload-g7110-01.txt (G.711.0 RTP = payload format) and draft-ramalho-g7110-segments-00.txt (G.711.0 “use cases”).

 

As the G.711.0 payload draft is nearly = identical to the G.711 RTP payload specification, there was little debate o= n the mailing lists about it outside of the storage mode definition (the G.711 RTP payload specification did not have a storage mod= e defined).

 

>>IETF 83 Paris, France, March 27= , 2012

 

I presented: draft-ramalho-g7110-segmen= ts-00 during the PAYLOAD segment inside of the AVTEXT meeting slot (http://www.ietf.org/proceedings/83/slides/slides-83= -avtext-6.pdf = ).

 

I did not present on the G.711.0 payloa= d format draft, as the only issue being debated on the list for this draft = was the storage mode – and the storage mode agreements were converging to a solution on the mailing list.

 

I renewed the G.711.0 RTP payload speci= fication with a new version (draft-ramalho-payload-g7110-02.txt) which capt= ured the email discussions on the storage mode issues.

 

I let the use case draft (draft-ramalho= -g7110-segments-00) expire due to lack of interest on the mailing list. I b= elieve interest will revive when the payload specification is complete.

 

>>Summary: This email requests th= e G.711.0 RTP Payload Format be a formal working group item with an associa= ted milestone (December 2013 suggested).

 

--_000_E721D8C6A2E1544DB2DEBC313AF54DE224058DCDxmbrcdx02ciscoc_--