From lars@ibp.de Tue Jun 12 14:42:31 2012 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56DFC21F868A for ; Tue, 12 Jun 2012 14:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.16 X-Spam-Level: X-Spam-Status: No, score=-0.16 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35, J_CHICKENPOX_15=0.6] 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 Y3Zj4V46+NNH for ; Tue, 12 Jun 2012 14:42:30 -0700 (PDT) Received: from mail.ibp.de (mail.ibp.de [87.234.192.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF6D21F8642 for ; Tue, 12 Jun 2012 14:42:30 -0700 (PDT) Received: from ohm.ibp.de (unknown [10.222.227.132]) by mail.ibp.de (Postfix) with ESMTPSA id 195ADC5C1D1; Tue, 12 Jun 2012 23:42:28 +0200 (CEST) From: Lars Immisch Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jun 2012 23:42:28 +0200 Message-Id: <619CA092-0565-41EE-AD7B-D2F836B22337@ibp.de> To: codec@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: Tim Pritlove Subject: [codec] draft-spittka-payload-rtp-opus-00: a=fmtp:101 application=audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 21:42:31 -0000 Hi, I have integrated the Opus codec into a SIP UA (based on pjsip). The = intended application is for a broadcast (podcast) studio: a guest calls = into the studio, talks (and maybe even sings) with the host, and the = conversation is broadcast. For this application, the highest available quality is desirable.=20 I have experimented with Opus in the appliation=3Daudio setting and am = pretty happy with it. But reading draft-spittka-payload-rtp-opus-00, I = find no provision to encourage the other party to send an Opus stream = encoded with the "audio" application setting. I'd like to propose an additional "application" parameter that can take = the value "audio", "lowdelay" (and maybe "voip"): In my example, the studio would offer (or answer with): m=3Daudio 54312 RTP/AVP 101 a=3Drtpmap:101 opus/48000 a=3Dfmtp:101 application=3Daudio This would prompt the encoder on the other side to use the audio = application mode of Opus. I hope this makes sense. If it does, I'd be very pleased if it could be = included in the next draft.=20 - Lars Immisch= From jmvalin@jmvalin.ca Tue Jun 12 15:03:48 2012 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8774F21F8582 for ; Tue, 12 Jun 2012 15:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] 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 VsENKkIqQCDR for ; Tue, 12 Jun 2012 15:03:48 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by ietfa.amsl.com (Postfix) with ESMTP id 0A84321F855F for ; Tue, 12 Jun 2012 15:03:48 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.1.14] ([96.21.20.94]) by VL-VM-MR003.ip.videotron.ca (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTP id <0M5I00EI8YMAM900@VL-VM-MR003.ip.videotron.ca> for codec@ietf.org; Tue, 12 Jun 2012 18:03:47 -0400 (EDT) Message-id: <4FD7BCCA.5000708@jmvalin.ca> Date: Tue, 12 Jun 2012 18:03:54 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 To: Lars Immisch References: <619CA092-0565-41EE-AD7B-D2F836B22337@ibp.de> In-reply-to: <619CA092-0565-41EE-AD7B-D2F836B22337@ibp.de> X-Enigmail-Version: 1.4.2 Cc: codec@ietf.org, Tim Pritlove Subject: Re: [codec] draft-spittka-payload-rtp-opus-00: a=fmtp:101 application=audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 22:03:48 -0000 Hi, The idea here is that the sender should know better than the receiver the optimal way to encode the audio. This is why there's no application= parameter. Cheers, Jean-Marc On 12-06-12 05:42 PM, Lars Immisch wrote: > Hi, > > I have integrated the Opus codec into a SIP UA (based on pjsip). The > intended application is for a broadcast (podcast) studio: a guest > calls into the studio, talks (and maybe even sings) with the host, > and the conversation is broadcast. > > For this application, the highest available quality is desirable. > > I have experimented with Opus in the appliation=audio setting and am > pretty happy with it. But reading draft-spittka-payload-rtp-opus-00, > I find no provision to encourage the other party to send an Opus > stream encoded with the "audio" application setting. > > I'd like to propose an additional "application" parameter that can > take the value "audio", "lowdelay" (and maybe "voip"): > > In my example, the studio would offer (or answer with): > > m=audio 54312 RTP/AVP 101 a=rtpmap:101 opus/48000 a=fmtp:101 > application=audio > > This would prompt the encoder on the other side to use the audio > application mode of Opus. > > I hope this makes sense. If it does, I'd be very pleased if it could > be included in the next draft. > > - Lars Immisch _______________________________________________ codec > mailing list codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > From lars@ibp.de Tue Jun 12 15:34:00 2012 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF3821F861D for ; Tue, 12 Jun 2012 15:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.205 X-Spam-Level: X-Spam-Status: No, score=-1.205 tagged_above=-999 required=5 tests=[AWL=1.044, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 oDZND7BZR+qW for ; Tue, 12 Jun 2012 15:34:00 -0700 (PDT) Received: from mail.ibp.de (mail.ibp.de [87.234.192.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2AF3421F86F0 for ; Tue, 12 Jun 2012 15:33:59 -0700 (PDT) Received: from ohm.ibp.de (unknown [10.222.227.132]) by mail.ibp.de (Postfix) with ESMTPSA id 0951EC5C1D4; Wed, 13 Jun 2012 00:33:57 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Lars Immisch In-Reply-To: <4FD7BCCA.5000708@jmvalin.ca> Date: Wed, 13 Jun 2012 00:33:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <619CA092-0565-41EE-AD7B-D2F836B22337@ibp.de> <4FD7BCCA.5000708@jmvalin.ca> To: Jean-Marc Valin X-Mailer: Apple Mail (2.1084) Cc: codec@ietf.org, Tim Pritlove Subject: Re: [codec] draft-spittka-payload-rtp-opus-00: a=fmtp:101 application=audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 22:34:00 -0000 Hi, > The idea here is that the sender should know better than the receiver > the optimal way to encode the audio. This is why there's no = application=3D > parameter. I understand that reasoning. A hi-fi music on hold implementation would = just use application=3Daudio and send it unless the receiver asks for = bandwidth restrictions. But in our usecase (guest calls into broadcast studio), the receiver = does know better. The recording will be broadcast and the receiver wants = a way of saying: "Hey, send your best quality (because this will be = broadcast)". This addition would solve a real problem and create no interoperability = concerns. If you can think of other ways to solve this problem, I'd be pleased to = hear them (I toyed with the idea of having an opus-audio codec, but = dismissed it because application=3Daudio seemed a better fit, in = particular because the hypothetical opus-audio and the opus codec can = interoperate). - Lars Immisch= From jmvalin@mozilla.com Tue Jun 12 17:38:13 2012 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E5721F8747 for ; Tue, 12 Jun 2012 17:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lu5Z9AyXUaFY for ; Tue, 12 Jun 2012 17:38:12 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id DFBD721F873D for ; Tue, 12 Jun 2012 17:38:12 -0700 (PDT) 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 96163F26D5; Tue, 12 Jun 2012 17:38:10 -0700 (PDT) Message-ID: <4FD7E0F1.4080801@mozilla.com> Date: Tue, 12 Jun 2012 20:38:09 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Lars Immisch References: <619CA092-0565-41EE-AD7B-D2F836B22337@ibp.de> <4FD7BCCA.5000708@jmvalin.ca> In-Reply-To: X-Enigmail-Version: 1.4.2 X-Enigmail-Draft-Status: 513 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org, Tim Pritlove Subject: Re: [codec] draft-spittka-payload-rtp-opus-00: a=fmtp:101 application=audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 00:38:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/12/2012 06:33 PM, Lars Immisch wrote: > But in our usecase (guest calls into broadcast studio), the > receiver does know better. The recording will be broadcast and the > receiver wants a way of saying: "Hey, send your best quality > (because this will be broadcast)". Just saying "encode at high bit-rate" is enough to get the best quality. Also, note that the "application" setting has nothing to do with the Opus format. It's just an option in the current libopus API. Other Opus implementation may not have that option at all, or may expose the equivalent through a totally different API. This is why it cannot be included in the SDP. Cheers, Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP1+DrAAoJEJ6/8sItn9q90kMH/jypHEuF18BMBhMw1B8rJMrX 23mrTXX5KtnDZuSk8rKaY95hbBJQcqKGNlj+FlU3tOkFB/dku6ZOY6F82Z8nJzoH Gbh7g/GD8GrBFhGvmHOGe93e+6qvGhaM/QtARvwDMHjzNAUPILHQ4QmmnaVAcXpH QAje+n90Or51LcfYixgD+apSG/QqgQkiJxfHTFKZtbmcrnFPY5AGkE9kcFKfXD3W o13m7evU0lRsI+wx9dWWgPIb7GHOLVfQqTCZGSSjlJ8GsMgje/gtg439FqP8lOm/ CDrF8M+svvhNUgbt7+tKIffQCpYrNd9CLDU/GOv9x+FtTqfsF3muEqKdNdMRqLA= =ZUvc -----END PGP SIGNATURE----- From lars@ibp.de Wed Jun 13 15:53:58 2012 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A717021F8512 for ; Wed, 13 Jun 2012 15:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.727 X-Spam-Level: X-Spam-Status: No, score=-1.727 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 rR1AdC+xroW2 for ; Wed, 13 Jun 2012 15:53:57 -0700 (PDT) Received: from mail.ibp.de (mail.ibp.de [87.234.192.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7F34221F850C for ; Wed, 13 Jun 2012 15:53:54 -0700 (PDT) Received: from ohm.ibp.de (unknown [10.222.227.132]) by mail.ibp.de (Postfix) with ESMTPSA id 51774C5C1D1; Thu, 14 Jun 2012 00:53:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Lars Immisch In-Reply-To: <4FD7E0F1.4080801@mozilla.com> Date: Thu, 14 Jun 2012 00:52:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <47991A48-3BEF-44CE-B416-693373693F96@ibp.de> References: <619CA092-0565-41EE-AD7B-D2F836B22337@ibp.de> <4FD7BCCA.5000708@jmvalin.ca> <4FD7E0F1.4080801@mozilla.com> To: Jean-Marc Valin X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: codec@ietf.org, Tim Pritlove Subject: Re: [codec] draft-spittka-payload-rtp-opus-00: a=fmtp:101 application=audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2012 22:53:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, >> But in our usecase (guest calls into broadcast studio), the >> receiver does know better. The recording will be broadcast and the >> receiver wants a way of saying: "Hey, send your best quality >> (because this will be broadcast)". >=20 > Just saying "encode at high bit-rate" is enough to get the best > quality. Also, note that the "application" setting has nothing to do > with the Opus format. It's just an option in the current libopus API. > Other Opus implementation may not have that option at all, or may > expose the equivalent through a totally different API. This is why it > cannot be included in the SDP. Well, the draft talks about "audio mode" and "voice mode" [1]. I should = have suggested the parameter name "mode" and not "application" to stay = within the draft's language. But how can the receiver say: "encode at high bit-rate"? I don't see how = that can be done. a=3Dfmtp: 101 maxaveragebitrate=3D128000 (or any x > 32000) is a bit = weak, because that's always true per Table 1.=20 What about maxaveragbitrate=3Dunlimited? And a bit of explanatory text like this (modified from Section 7.2.1): o The parameter "maxaveragebitrate" is a unidirectional receive-only parameter. The value "unlimited" indicates that the local receiver=20= wishes to receive payload data that was encoded with the audio = mode=20 of the codec. Other numerical values reflects limitations of the = local=20 receiver and the sender of the other side MUST NOT send with an = average=20 bit rate higher than "maxaveragebitrate" as it might overload the = network and/or receiver. The parameter "maxaveragebitrate" typically will not compromise interoperability; however, dependent on the set value of the parameter the performance of the application may suffer and should be set with care. That would be good enough for the use case at hand, but it isn't easy on = the reader of the draft. "mode=3Daudio" seems clearer and needs less = text. But I don't care how it is done as long as the receiver can = indicate to the sender that it wants the highest quality that the sender = can produce. - - Lars [1] There is a typo in the draft: the section title in 3.1.1 should = probably be "Voice mode" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJP2Rn/AAoJEFqVdVRAw6wHzKEIAJmIn7bArSF2HZugXy/N+bu0 RVExiCOYfQ271XZyfHcB/qYeaGhQE9mbMvOrJUQt+HQ08d6QKp5TaaomTs7EBz2G NE+3aZRdRq/ba8R7evurWxp7bvF0doXT4cn1kLwAIvWRPtObQR58Ot05a2Y+ys3F p3EOYmHuLLMACsUki4jPGKEfH6dMtSDfQZb5nyHSRwy6Teyyc+SntVms37j6agKJ 1XHE//Bstmg9S54LaxkB6xGJH1wqRtO8tsdrJdTKf9ea0bYMLCtiryxOEOakVEiy eD+0mvqhPHxGvRvxyouITJVe8GqrjGfzwsDHKYjFxEuQM9JbhuiFd0Fpk8Nn/kI=3D =3D8djS -----END PGP SIGNATURE----- From jmvalin@mozilla.com Thu Jun 14 08:07:28 2012 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E38F21F86A8 for ; Thu, 14 Jun 2012 08:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFWfI5h2-dFF for ; Thu, 14 Jun 2012 08:07:28 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCF721F863F for ; Thu, 14 Jun 2012 08:07:28 -0700 (PDT) Received: from [192.168.1.15] (modemcable094.20-21-96.mc.videotron.ca [96.21.20.94]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id EDC7DF22F1; Thu, 14 Jun 2012 08:07:26 -0700 (PDT) Message-ID: <4FD9FE2D.8070408@mozilla.com> Date: Thu, 14 Jun 2012 11:07:25 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Lars Immisch References: <619CA092-0565-41EE-AD7B-D2F836B22337@ibp.de> <4FD7BCCA.5000708@jmvalin.ca> <4FD7E0F1.4080801@mozilla.com> <47991A48-3BEF-44CE-B416-693373693F96@ibp.de> In-Reply-To: <47991A48-3BEF-44CE-B416-693373693F96@ibp.de> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org, Tim Pritlove Subject: Re: [codec] draft-spittka-payload-rtp-opus-00: a=fmtp:101 application=audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 15:07:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/13/2012 06:52 PM, Lars Immisch wrote: > Well, the draft talks about "audio mode" and "voice mode" [1]. I > should have suggested the parameter name "mode" and not > "application" to stay within the draft's language. Actually, the audio mode/voice mode will go away in the next revision - -- it's just not needed considering that the sender knows better. > But how can the receiver say: "encode at high bit-rate"? I don't > see how that can be done. You can do that with the b=AS: parameter > a=fmtp: 101 maxaveragebitrate=128000 (or any x > 32000) is a bit > weak, because that's always true per Table 1. First, table is just a rule of thumb for the recommended bandwidth bandwidth in each more. It's not about defining maxaveragebitrate. Also, we've realised that maxaveragebitrate needs to be a hard cap and that it's not a good idea to use it for controlling the rate. > What about maxaveragbitrate=unlimited? Indeed, we'll make maxaveragbitrate *default* to unlimited in the next draft. Controlling the bitrate should be done with the b= attribute. Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJP2f4tAAoJEJ6/8sItn9q9efIH/Ryhv6dY1MY787Ow4YAVK3Fj cOaKQVcFOwEeFfto+4a0fVnBdTP0Zb5WBqAAySwFjKmk+72omAGPETsDamqMQhN+ 8XGE5/Nx8eq9kGzsEtWp/XkPPUjBxF1iTr9s89MLmmKU0h/O9RdEzGbht9aNL3Go oDbjWK8/lDi5giOUglFTPOjX3vdZJNGMfX+6qMY93CqROp0shIs+S1J7BJOFl9gs K9XqRl/uyOV/7QtfN8HGDjsuX4qx/iKkt9+ABD0ZEmSXwNBZnrtDXP9Mx9mMpNlg iq3s+VzxhT5YHMTLsv0f9M2j2HAHmr1EGQRSBlKqAEnnDfiaLnjmHQDlULXac9U= =ROUc -----END PGP SIGNATURE----- From lars@ibp.de Thu Jun 14 14:58:57 2012 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9063221F85D0 for ; Thu, 14 Jun 2012 14:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 jEl-TQcFZk5g for ; Thu, 14 Jun 2012 14:58:57 -0700 (PDT) Received: from mail.ibp.de (mail.ibp.de [87.234.192.161]) by ietfa.amsl.com (Postfix) with ESMTP id BCFEB21F84B6 for ; Thu, 14 Jun 2012 14:58:56 -0700 (PDT) Received: from ohm.ibp.de (unknown [10.222.227.132]) by mail.ibp.de (Postfix) with ESMTPSA id B008AC5C1D1; Thu, 14 Jun 2012 23:58:54 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Lars Immisch In-Reply-To: <4FD9FE2D.8070408@mozilla.com> Date: Thu, 14 Jun 2012 23:58:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5AB46D94-218A-4668-88C7-A169FB1256C1@ibp.de> References: <619CA092-0565-41EE-AD7B-D2F836B22337@ibp.de> <4FD7BCCA.5000708@jmvalin.ca> <4FD7E0F1.4080801@mozilla.com> <47991A48-3BEF-44CE-B416-693373693F96@ibp.de> <4FD9FE2D.8070408@mozilla.com> To: Jean-Marc Valin X-Pgp-Agent: GPGMail 1.3.3 X-Mailer: Apple Mail (2.1084) Cc: codec@ietf.org, Tim Pritlove Subject: Re: [codec] draft-spittka-payload-rtp-opus-00: a=fmtp:101 application=audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 21:58:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > On 06/13/2012 06:52 PM, Lars Immisch wrote: >> Well, the draft talks about "audio mode" and "voice mode" [1]. I=20 >> should have suggested the parameter name "mode" and not >> "application" to stay within the draft's language. >=20 > Actually, the audio mode/voice mode will go away in the next revision > - -- it's just not needed considering that the sender knows better. >=20 >> But how can the receiver say: "encode at high bit-rate"? I don't >> see how that can be done. >=20 > You can do that with the b=3DAS: parameter Ah, ok. RFC 3556 >> a=3Dfmtp: 101 maxaveragebitrate=3D128000 (or any x > 32000) is a bit=20= >> weak, because that's always true per Table 1. >=20 > First, table is just a rule of thumb for the recommended bandwidth > bandwidth in each more. It's not about defining maxaveragebitrate. > Also, we've realised that maxaveragebitrate needs to be a hard cap and > that it's not a good idea to use it for controlling the rate. >=20 >> What about maxaveragbitrate=3Dunlimited? >=20 > Indeed, we'll make maxaveragbitrate *default* to unlimited in the next > draft. Controlling the bitrate should be done with the b=3D attribute. That sounds like it would address my concerns. Thank you, - - Lars Immisch -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJP2l6eAAoJEFqVdVRAw6wHuUUH/Rf8RWdNNBfwwIVLpSk3iIDx 8f1cLq/WbgD2Lg23JsO3SQ6ICnR+YTBdOqa7OWt/s7aEbIa8ivho8HWYyWEDZYLp Wash60VLcgt9rIjwgK6br/7PYMy0ZcehKFE55huJ6kU8hV3XSRu7Vam2VWBQce8Y kSWPRzYR3cj8Kt9kl6U3RzM9j7hKxBqXBPj/9iFrMtcn6D1R9VVTCAjoNDl/11T+ SVIJfkKscnyAeZGKP1r/eOfBjGltBoSXchu1surEkkxRrTV9lDX7Iat7EXjlu/1X 5By7STFIAcZ6UIfoYM3sp+s+rCRD8uxRgIND4RjXMCwCnlG5QeEzTteSlYc50u0=3D =3DMYfj -----END PGP SIGNATURE----- From internet-drafts@ietf.org Mon Jun 18 18:45:14 2012 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B48E11E80D7; Mon, 18 Jun 2012 18:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFJpw2PpZE-D; Mon, 18 Jun 2012 18:45:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A5D21F851A; Mon, 18 Jun 2012 18:45:13 -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.20 Message-ID: <20120619014513.13113.22962.idtracker@ietfa.amsl.com> Date: Mon, 18 Jun 2012 18:45:13 -0700 Cc: codec@ietf.org Subject: [codec] I-D Action: draft-ietf-codec-opus-15.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2012 01:45:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Wideband Audio Codec Working Gro= up of the IETF. Title : Definition of the Opus Audio Codec Author(s) : Jean-Marc Valin Koen Vos Timothy B. Terriberry Filename : draft-ietf-codec-opus-15.txt Pages : 330 Date : 2012-06-18 Abstract: This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kb/s to very high quality stereo music at 510 kb/s. Opus uses both linear prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-codec-opus There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-codec-opus-15 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-codec-opus-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Jun 28 19:45:16 2012 Return-Path: X-Original-To: codec@ietfa.amsl.com Delivered-To: codec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84D111E811A; Thu, 28 Jun 2012 19:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.229 X-Spam-Level: X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wRjusF5fkMk; Thu, 28 Jun 2012 19:45:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322CE11E8085; Thu, 28 Jun 2012 19:45:16 -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.21p1 Message-ID: <20120629024516.18984.58342.idtracker@ietfa.amsl.com> Date: Thu, 28 Jun 2012 19:45:16 -0700 Cc: codec@ietf.org Subject: [codec] I-D Action: draft-ietf-codec-opus-16.txt X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 02:45:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Internet Wideband Audio Codec Working Gro= up of the IETF. Title : Definition of the Opus Audio Codec Author(s) : Jean-Marc Valin Koen Vos Timothy B. Terriberry Filename : draft-ietf-codec-opus-16.txt Pages : 330 Date : 2012-06-28 Abstract: This document defines the Opus interactive speech and audio codec. Opus is designed to handle a wide range of interactive audio applications, including Voice over IP, videoconferencing, in-game chat, and even live, distributed music performances. It scales from low bitrate narrowband speech at 6 kb/s to very high quality stereo music at 510 kb/s. Opus uses both linear prediction (LP) and the Modified Discrete Cosine Transform (MDCT) to achieve good compression of both speech and music. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-codec-opus There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-codec-opus-16 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-codec-opus-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/