From nobody Tue Jul 1 17:12:15 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6021ABB90 for ; Tue, 1 Jul 2014 17:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDka7No-uG5X for ; Tue, 1 Jul 2014 17:11:54 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102D41A0B17 for ; Tue, 1 Jul 2014 17:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1404259915; x=1435795915; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hU9viFh8yUHEi0Jo/azn0VAEtkAMeJadF4E8NIfZU4Y=; b=jTnmVlOZsuEGis5gLj7xQ67lhMLoSBXq60YJYOCPudVkIoCzPTsWq6ZD VzQ/ap64TKRgsUhbhvlPm9jW1pmmbFIjxpdPolooihaF8qqHBw06eyZD0 bhRY3+in7G6yFncnWY14NZMxztUSLghbqOc3c5olxCoW7sWEuW+SmSA1R s=; X-IronPort-AV: E=McAfee;i="5600,1067,7486"; a="68274962" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth01.qualcomm.com with ESMTP; 01 Jul 2014 17:11:54 -0700 X-IronPort-AV: E=Sophos;i="5.01,585,1400050800"; d="scan'208,217";a="759686688" Received: from nasanexhc11.na.qualcomm.com ([172.30.39.6]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 01 Jul 2014 17:11:53 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.42]) by nasanexhc11.na.qualcomm.com ([172.30.39.6]) with mapi id 14.03.0181.006; Tue, 1 Jul 2014 17:11:52 -0700 From: "Wang, Ye-Kui" To: Roni Even , "payload@ietf.org" Thread-Topic: [payload] WGLC for H.265 - RTP Payload Format for High Efficiency Video Coding - comments Thread-Index: Ac+UYuTnX4dTe7nxRYqeaYeN0J0K9wBJrrXA Date: Wed, 2 Jul 2014 00:11:52 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A8350826F07@nasanexd02f.na.qualcomm.com> References: <002401cf9464$92a7e1b0$b7f7a510$@gmail.com> In-Reply-To: <002401cf9464$92a7e1b0$b7f7a510$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.192] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A8350826F07nasanexd02fnaqu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/ToaHw5MMozRWBuj_Fw45FhNY7TY Cc: "draft-ietf-payload-rtp-h265@tools.ietf.org" Subject: Re: [payload] WGLC for H.265 - RTP Payload Format for High Efficiency Video Coding - comments X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jul 2014 00:12:03 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A8350826F07nasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, Thanks a lot for your review and comments. Please find my replies inline be= low. Some of the replies were from both Stephan (Wenger) any myself, as we = discussed how to reply together in Sapporo Japan. BR, YK From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Roni Even Sent: Monday, June 30, 2014 6:10 AM To: payload@ietf.org Cc: draft-ietf-payload-rtp-h265@tools.ietf.org Subject: Re: [payload] WGLC for H.265 - RTP Payload Format for High Efficie= ncy Video Coding - comments Hi, I reviewed the documents and have some comments as individual!!!! In section 1.1.4 "forbidden_zero_bit. MUST be zero.". What does the MUST m= ean if in section 4.8 the f bit can be set to 1. What is the behavior in th= is case when the bit is set to 1? [YK]: Good spotting. Stephan and I discussed this, and we think that we can= just change "MUST be zero" in section 1.1.4 to say that the value is requi= red to be equal to 0 in the HEVC spec. Section 1.1.4 is anyway a part of an= introduction and overview of the HEVC specification. We will do the same = for the nuh_layer_id semantics as well in Section 1.1.4. In section 7.1 missing person & email address to contact [YK]: OK, will add that in the next version. In section 7.2.2 "The profile-compatibility-indicator, when offered as send= only, describe bitstream properties. The answerer MAY accept an RTP paylo= ad type even if the decoder is not capable of handling the profile indicat= ed by the profile-space, profile-id, and interop- constraints parameters, b= ut capable of any of the profiles indicated by the profile-space, profile-= compatibility-indicator, and interop-constraints. However, when the profil= e-compatibility-indicator is used in a recvonly or sendrecv media descripti= on, the bitstream using this RTP payload type is required to conform to all= profiles indicated by profile-space, profile-compatibility-indicator, and = interop-constraints." I do not understand this case can you explain why th= is behavior? [YK]: This is because of the semantics of the profile related parameters pr= ofile-space, profile-id, interop-constraints, and profile-compatibility-ind= icator as specified in the HEVC spec. Let me use an example to explain. Firstly on the part before "However". Let's say the profile-compatibility-i= ndicator have two flags set, corresponding to profiles A and B, respectivel= y. Meanwhile, the profile indicated by the profile-space, profile-id, and i= nterop-constraints parameters may be just profile A. When such profile-comp= atibility-indicator indicates a bitstream property, that means the bitstrea= m is encoded using only tools that are common for profiles A and B, and thu= s a decoder conforming to either profile A or profile B can decode the bits= tream, i.e. the decoder does not have to be conforming to profile A. Now, on the part starting with "However". When such profile-compatibility-i= ndicator indicates decoder capability, it really indicates that the decoder= implements only the common tools of profiles A and B. This part just says = that this is the case. Please let us know if you think some clarification such as this should be a= dded to the draft. In section 7.2.2 "see the semantics of sprop-vps on one video parameter set= being consistent with another video parameter set". Please provide referen= ce. [YK]: OK, will provide a cross reference to the section for the semantics o= f sprop-vps. In section 7.2.2 "rules apply to transport of parameter set in the answerer= -to-offerer direction" . What happens when the RTP is received before the S= DP answer? [YK]: I guess you meant in the early media cases for reduced start up delay= . Stephan and I agreed that we can just say something like, in case some R= TP stream(s) are sent before SDP offer/answer settles down, in-band paramet= er sets MUST be used for those RTP stream parts sent before the SDP offer/a= nswer. In section 7.2.4 Parameter Sets Considerations what about the different mul= tipoint topologies? [YK]: Roni, Stephan and I tried to understand what you might mean, but we c= ould not figure it out. Could you please clarify? Thanks! Thanks Roni From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 11 June, 2014 12:59 PM To: 'payload@ietf.org' Cc: draft-ietf-payload-rtp-h265@tools.ietf.org Subject: WGLC for H.265 - RTP Payload Format for High Efficiency Video Codi= ng WG, This is to start the WGLC for the RTP Payload Format for High Efficiency Vi= deo Coding (H.265) draft http://tools.ietf.org/html/draft-ietf-payload-rtp-= h265-04 The WGLC is for three weeks till July 3rd Please send your comments and approvals to the payload list. Authors, please let the WG chairs know if you are aware of any undeclared = IPR related to this draft. It is needed for the publication request. Thanks Roni Even Payload co-chair --_000_8BA7D4CEACFFE04BA2D902BF11719A8350826F07nasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,

 

Thanks a lot for your = review and comments. Please find my replies inline below. Some of the repli= es were from both Stephan (Wenger) any myself, as we discussed how to reply= together in Sapporo Japan.

 

BR, YK

 

From: payload = [mailto:payload-bounces@ietf.or= g] On Behalf Of Roni Even
Sent: Monday, June 30, 2014 6:10 AM
To: payload@ietf.org
Cc: dr= aft-ietf-payload-rtp-h265@tools.ietf.org
Subject: Re: [payload] WGLC for H.265 - RTP Payload Format for High = Efficiency Video Coding - comments

 

Hi,

I reviewed the documents and have some comments as i= ndividual!!!!

 

In section 1.1.4 “forbidden_zero_bit.  MUST be zero.”. = What does the MUST mean if in section 4.8 the f bit can be set to 1. What i= s the behavior in this case when the bit is set to 1?

[YK]: Good spotting. Stephan and I discussed this, and we = think that we can just change “MUST be zero” in section 1.1.4 t= o say that the value is required to be equal to 0 in the HEVC spec. Section 1.1.4 is anyway a part of an introduction and = overview of the HEVC specification.  We will do the same for the nuh_l= ayer_id semantics as well in Section 1.1.4.

In section 7.1 missing person & email address to contact<= /span>

[YK]: OK, will add that in the next version.

In section 7.2.2 “The profile-compatibility= -indicator, when offered as sendonly,  describe bitstream properties.&= nbsp; The answerer MAY accept an RTP payload type even if the decoder is no= t capable of handling the  profile indicated by the profile-space, profile-id, and interop- constraints parameters, but capabl= e of any of the profiles  indicated by the profile-space, profile-comp= atibility-indicator, and interop-constraints.  However, when the profi= le-compatibility-indicator is used in a recvonly or sendrecv media description, the bitstream using this RTP payload type i= s required to conform to all profiles indicated by profile-space, profile-c= ompatibility-indicator, and interop-constraints.”  I do not unde= rstand this case can you explain why this behavior?

 

[YK]: This is becau= se of the semantics of the profile related parameters profile-space, profil= e-id, interop-constraints, and profile-compatibility-indicator as specified= in the HEVC spec.

 

Let me use an examp= le to explain.

 

Firstly on the part= before “However”. Let’s say the profile-compatibility-in= dicator have two flags set, corresponding to profiles A and B, respectively= . Meanwhile, the profile indicated by the profile-space, profile-id, and interop-constraints parameters may be just profile A. When= such profile-compatibility-indicator indicates a bitstream property, that = means the bitstream is encoded using only tools that are common for profile= s A and B, and thus a decoder conforming to either profile A or profile B can decode the bitstream, i.e. the decode= r does not have to be conforming to profile A.

 

Now, on the part st= arting with “However”. When such profile-compatibility-indicato= r indicates decoder capability, it really indicates that the decoder implem= ents only the common tools of profiles A and B. This part just says that this is the case.

 

Please let us know = if you think some clarification such as this should be added to the draft.<= o:p>

 

 

In section 7.2.2 “see the semantics of spro= p-vps on one video parameter set being consistent with another video parame= ter set”. Please provide reference.

 

[YK]: OK, will prov= ide a cross reference to the section for the semantics of sprop-vps.

 

 

In section 7.2.2 “rules apply to transport = of parameter set in the answerer-to-offerer direction” . What happens= when the RTP is received before the SDP answer?

 

[YK]: I guess you m= eant in the early media cases for reduced start up delay.  Stephan and= I agreed that we can just say something like, in case some RTP stream(s) a= re sent before SDP offer/answer settles down, in-band parameter sets MUST be used for those RTP stream parts sent before= the SDP offer/answer.

 

In section 7.2.4 Parameter Sets Considerations wh= at about the different multipoint topologies?

 

[YK]: Roni, Stephan= and I tried to understand what you might mean, but we could not figure it = out. Could you please clarify? Thanks!

 

 

Thanks

Roni

 

 

 

From: Roni Eve= n [mailto:ron.even.tlv@gmail.com<= /a>]
Sent: 11 June, 2014 12:59 PM
To: 'payload@ietf.org'
Cc: dr= aft-ietf-payload-rtp-h265@tools.ietf.org
Subject: WGLC for H.265 - RTP Payload Format for High Efficiency Vid= eo Coding

 

WG,

 

This is to start the WGLC for the RTP Payload Format for = High Efficiency Video Coding (H.265) draft http:= //tools.ietf.org/html/draft-ietf-payload-rtp-h265-04

The WGLC is for three weeks till July 3rd

Please send your comments and approvals to the pa= yload list.

 

 

Authors, please let the WG chairs know if you are= aware of any undeclared  IPR related to this draft. It is needed for = the publication request.

Thanks

Roni Even

Payload co-chair

 

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A8350826F07nasanexd02fnaqu_-- From nobody Mon Jul 7 22:55:22 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BA01B2979 for ; Mon, 7 Jul 2014 22:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-3ZSd4bkv6P for ; Mon, 7 Jul 2014 22:55:19 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 321191B28F0 for ; Mon, 7 Jul 2014 22:55:19 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id k14so2695091wgh.0 for ; Mon, 07 Jul 2014 22:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=3wGQLRYLf9/6x+S2Melk8I7SJLxvt6eG8fNSAFQnnVc=; b=ejA1I7ilSPXDu9BQCSUxGrJvOaWTjLSsrBcieUNfylviCSk3N7hmJhHOGx52e2Gy60 nZVkqX6AS+uORpcAu04rFQ6DnlNnRJON6cXz+yQa8CgadQZVKrRxdJ3WyXV7cnTJYbRv mweN1/UPrmOh0/jxqiNFkMXY7zY5eQrI4pTJpVfmUgVenwfS08ySPcsBybDUZmC+QT+O Pjs8PNRnv38/YElzFBxmgd5D2hu2A/FI54jnqtO2LoHFokx6TI+0ac+ODxw6E+8ml6by Ywl1CIkjkT5yE0BdIxGl66yNJJ/szkT1pZ56a4iMsO+ygEXh0Mbo4IDB71Mq+fZTp9a7 s/WQ== X-Received: by 10.180.21.200 with SMTP id x8mr1129076wie.67.1404798917675; Mon, 07 Jul 2014 22:55:17 -0700 (PDT) Received: from RoniE (bzq-79-176-120-218.red.bezeqint.net. [79.176.120.218]) by mx.google.com with ESMTPSA id p3sm94062458wjw.13.2014.07.07.22.55.15 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 07 Jul 2014 22:55:16 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: In-Reply-To: Date: Tue, 8 Jul 2014 08:55:10 +0300 Message-ID: <013301cf9a71$2f863420$8e929c60$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEF01AJCGwzyzlsWQjSYUEPAIEdlZ0pN03A Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/payload/Ck2C49ZGmU8mdNRb-aLOoQNKtr0 Subject: Re: [payload] WGLC for VP8 (draft-ietf-payload-vp8-11) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jul 2014 05:55:21 -0000 Hi, I reviewed the document and have some comments as individual 1. in section 4.2 figure 2 the PictureID as far as I understand from the text can be 8 or 16 bit but the figure shows only 8 bit 2. In section 4.2 " When the X bit is set to 1 in the first octet, the OPTIONAL extension bit field MUST be present in the second octet." This sentence is not clear to do you mean the whole octet. 3. I agree with YK comment about explaining golden frame and altref frame since section 5 is unclear without some understanding of these frames. 4. In section 6.2 the sentence " The receiver MUST ignore any parameter unspecified in this memo" is misleading, do you mean any SDP parameter for example b= MUST be ignored. 5. In 6.2.1 we do not use MIME but call it media subtype 6. In section 6.2.2 what is the meaning of max-fr and max-fs if the stream is sendonly? Also I assume that there is no need for symmetry for these parameters Thanks Roni > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Ali C. Begen > (abegen) > Sent: 12 June, 2014 9:21 AM > To: > Subject: [payload] WGLC for VP8 (draft-ietf-payload-vp8-11) > > I am starting a new WGLC for this draft. There has been much discussion after > the earlier WGLC ended, so it will be good to run this. > > The direct link is: > http://tools.ietf.org/html/draft-ietf-payload-vp8-11 > > The WGLC will run thru July 3rd (the same deadline for the h265 payload draft). > As usual, send your comments and approvals to the payload list. > > If there are undeclared IPRs, this is a good time to bring them up. > > Thanks, > -acbegen (as a co-chair) > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Tue Jul 8 09:00:59 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEED1B2B4D; Tue, 8 Jul 2014 08:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYd92Y_ZUoFU; Tue, 8 Jul 2014 08:55:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D20A11B2B4B; Tue, 8 Jul 2014 08:54:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: ts@thomas-schierl.de,alex@vidyo.com,stewe@stewe.org,yekui.wang@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140708155444.22198.75236.idtracker@ietfa.amsl.com> Date: Tue, 08 Jul 2014 08:54:44 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/xrMX2LNcRoxrfD9nndf0WgP4siU X-Mailman-Approved-At: Tue, 08 Jul 2014 09:00:49 -0700 Cc: alissa@cooperw.in, payload@ietf.org, ipr-announce@ietf.org Subject: [payload] IPR Disclosure: Vidyo, Inc.'s Statement about IPR related to RFC 6190 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jul 2014 15:55:16 -0000 Dear Thomas Schierl, Alex Eleftheriadis, Stephan Wenger, Ye-Kui Wang: An IPR disclosure that pertains to your RFC entitled "RTP Payload Format for Scalable Video Coding" (RFC6190) was submitted to the IETF Secretariat on 2014-07-07 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2384/). The title of the IPR disclosure is "Vidyo, Inc.'s Statement about IPR related to RFC 6190.""); The IETF Secretariat From nobody Wed Jul 23 07:45:24 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031171A0A86 for ; Wed, 23 Jul 2014 07:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTv3i_8t_6iY for ; Wed, 23 Jul 2014 07:45:20 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 553E21B2816 for ; Wed, 23 Jul 2014 07:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=588; q=dns/txt; s=iport; t=1406126721; x=1407336321; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=iVGqx5woKqvC15Ldevf4Os+hcKD/Q5XIVc7/ErZhksM=; b=mcw0faxgUXraUPyV15B6Ev8H7RXhogJrNJDbvfAL+IcB6MmwGbgbXkKa xMmxb2RJTpwyqxF7cdfglhk9pCnTnx+LCO/aUJKjeFO6xIac1HIJJDoQ9 HpxC+zPiEN9tR6UhG+ybosqYLhYZ7CPB3f99vmyX2t9ukdMGkaKz/jGw6 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFABfKz1OtJV2Q/2dsb2JhbABZgmokUlcEx2WGclOBDBZ2hAo6PxIBPkInBA4OiDkBDMAhF456AQFPAoMzgRgFmy2BUpJug0hsAYELOQ X-IronPort-AV: E=Sophos;i="5.01,717,1400025600"; d="scan'208";a="63344085" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-3.cisco.com with ESMTP; 23 Jul 2014 14:45:20 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s6NEjJsh027718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Jul 2014 14:45:19 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Wed, 23 Jul 2014 09:45:19 -0500 From: "Ali C. Begen (abegen)" To: "draft-ietf-payload-vp8@tools.ietf.org" Thread-Topic: Result of WGLC on the VP8 draft Thread-Index: AQHPpoS46TyZOsJvDkmD0D9TT2e1LA== Date: Wed, 23 Jul 2014 14:45:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <73C310B2DF15044DB5DA140CC7468C37@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/ojk_FtybW3-LWWmoPVD3SFF7aBY Cc: "" Subject: [payload] Result of WGLC on the VP8 draft X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2014 14:45:22 -0000 The WGLC has ended for the following draft: http://tools.ietf.org/id/draft-ietf-payload-vp8-11.txt I have seen comments from Roni and YK, which require a revision. Stephan al= so provided comments but he did not ask for any changes. Authors, please address Roni's and YK's comments.=20 WG, There was no comment raised in the WGLC regarding the image size issue (in = response to http://www.ietf.org/mail-archive/web/payload/current/msg00969.h= tml) So, I will consider that the WG is happy with the current draft and we can = proceed. -acbegen (as the co-chair)= From nobody Wed Jul 23 08:18:25 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C831B2928 for ; Wed, 23 Jul 2014 08:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deFdRHjy9qcW for ; Wed, 23 Jul 2014 08:18:14 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF3A1B292E for ; Wed, 23 Jul 2014 08:18:13 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so8041582wiv.1 for ; Wed, 23 Jul 2014 08:18:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=bPGMGOgVepPEnGjfFhlm4M9U3Xgr86BxAKqYr26Szno=; b=fZzCK12nDC7P63E4DdZ2O2sr8Z+bN9ohM7nvKM99hRdhjzaCLBKxK0JqHHA1Iqh9rv R0h0FiP84BB9zGD8jl2R0wcRM/Bfg0J1HlId4WvxDhKHitLP5F4woKqqxY986mDy09Pz Iz5Tgo9MDqypJg/Dwl1Ew++Y89t670r83ie8jerkEfX89S9yqeOxmro+C4/rG/If6sCp atuF6ExQ8s220RZGaP1+ban1FnFUrs6xquq85bFSyH346nVBJy15mh0ULRu92AKDf1EQ PcnSRFUceCdNjenadRtP4tmEGJAKI6vFWE1mjXy3KhhM1UWGU864mY4uueX4UJLHsVdu AMDg== X-Received: by 10.180.10.166 with SMTP id j6mr25929802wib.73.1406128691414; Wed, 23 Jul 2014 08:18:11 -0700 (PDT) Received: from RoniE ([2001:67c:370:160:2853:9966:2ea2:a817]) by mx.google.com with ESMTPSA id ft17sm7043953wjc.14.2014.07.23.08.18.09 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 23 Jul 2014 08:18:10 -0700 (PDT) From: "Roni Even" To: , "Wang, Ye-Kui" Date: Wed, 23 Jul 2014 18:18:07 +0300 Message-ID: <008301cfa689$504d7e60$f0e87b20$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0084_01CFA6A2.759B2B90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+miRjl+xMTMQboQjiBNmu7h4Qtqg== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/payload/zGegIozvN2PLeBvBXedQir5kogk Subject: [payload] result of WGLC on H.265 (HEVC) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2014 15:18:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0084_01CFA6A2.759B2B90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The WGLC has ended for the following draft: http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-04 There were comments from Danny and me as far as I can tell, which require a revision. Authors, please address the comments. After the new revision I will send the document to publication Regards Roni Even Payload co-chair ------=_NextPart_000_0084_01CFA6A2.759B2B90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The = WGLC has ended for the following draft:

http:/= /tools.ietf.org/html/draft-ietf-payload-rtp-h265-04 =

 

There were comments from Danny and me as far as I = can tell, which require a revision.

Authors, please address the comments. =

 

After the new revision I will send the document to = publication

 

Regards

Roni = Even

Payload = co-chair

------=_NextPart_000_0084_01CFA6A2.759B2B90-- From nobody Wed Jul 23 09:11:13 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409A61B2AFC for ; Wed, 23 Jul 2014 09:11:12 -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=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0yxYcUFXj2T for ; Wed, 23 Jul 2014 09:11:05 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 270771A0067 for ; Wed, 23 Jul 2014 09:11:05 -0700 (PDT) Received: from CO1PR07MB363.namprd07.prod.outlook.com (10.141.75.22) by CO1PR07MB364.namprd07.prod.outlook.com (10.141.75.13) with Microsoft SMTP Server (TLS) id 15.0.990.7; Wed, 23 Jul 2014 16:11:01 +0000 Received: from CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.67]) by CO1PR07MB363.namprd07.prod.outlook.com ([169.254.3.67]) with mapi id 15.00.0990.007; Wed, 23 Jul 2014 16:11:01 +0000 From: Stephan Wenger To: Roni Even , "payload@ietf.org" , "Wang, Ye-Kui" Thread-Topic: [payload] result of WGLC on H.265 (HEVC) Thread-Index: Ac+miRjl+xMTMQboQjiBNmu7h4Qtqv//zBiA Date: Wed, 23 Jul 2014 16:11:01 +0000 Message-ID: References: <008301cfa689$504d7e60$f0e87b20$@gmail.com> In-Reply-To: <008301cfa689$504d7e60$f0e87b20$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.162.237] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(979002)(199002)(189002)(377454003)(4396001)(74662001)(19617315012)(105586002)(77096002)(85306003)(16236675004)(99286002)(54356999)(15975445006)(106356001)(76176999)(74502001)(76482001)(107046002)(92726001)(36756003)(107886001)(86362001)(101416001)(21056001)(46102001)(15202345003)(81542001)(81342001)(85852003)(87936001)(19580405001)(20776003)(83322001)(50986999)(64706001)(19580395003)(95666004)(31966008)(99396002)(79102001)(19625215002)(80022001)(92566001)(19300405004)(77982001)(66066001)(83072002)(2656002)(42262001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:CO1PR07MB364; H:CO1PR07MB363.namprd07.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_CFF5569F43FBAstewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/payload/P3JQMNKBZGnVoAsO4B3ZVC3AYGk Subject: Re: [payload] result of WGLC on H.265 (HEVC) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2014 16:11:12 -0000 --_000_CFF5569F43FBAstewesteweorg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Expect the new version latest during first or second week of August. Stephan From: Roni Even > Date: Wednesday, July 23, 2014 at 8:18 AM To: "payload@ietf.org" >, Ye-Kui Wang > Subject: [payload] result of WGLC on H.265 (HEVC) The WGLC has ended for the following draft: http://tools.ietf.org/html/draft-ietf-payload-rtp-h265-04 There were comments from Danny and me as far as I can tell, which require a= revision. Authors, please address the comments. After the new revision I will send the document to publication Regards Roni Even Payload co-chair --_000_CFF5569F43FBAstewesteweorg_ Content-Type: text/html; charset="us-ascii" Content-ID: <5411D49C66A52F4BABF4CC2D45551A77@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Expect the new version latest during first or second week of August. &= nbsp;
Stephan

From: Roni Even <ron.even.tlv@gmail.com>
Date: Wednesday, July 23, 2014 at 8= :18 AM
To: "payload@ietf.org" <payload@ietf.org>, Ye-Kui Wang <yekuiw@qti.qualcomm.com>
Subject: [payload] result of WGLC o= n H.265 (HEVC)

The WGLC has ended for the following draft:<= /o:p>

http://tools.ietf.org/html/draft-ietf-payload-rtp-h265= -04

 

There were comments from Danny and me as far as I= can tell, which require a revision.

Authors, please address the comments. =

 

After the new revision I will send the document t= o publication

 

Regards

Roni Even

Payload co-chair

 --_000_CFF5569F43FBAstewesteweorg_-- From nobody Mon Jul 28 09:02:42 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A2C1A035F for ; Mon, 28 Jul 2014 09:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.223 X-Spam-Level: ** X-Spam-Status: No, score=2.223 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_SUMOF=1, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_15=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_56=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_FAIL=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2-kCSBj3Hlj for ; Mon, 28 Jul 2014 09:02:20 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4DC1A034F for ; Mon, 28 Jul 2014 09:02:14 -0700 (PDT) Received: from [10.252.28.253] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id B65DEF24BE for ; Mon, 28 Jul 2014 09:02:13 -0700 (PDT) Message-ID: <53D67405.800@xiph.org> Date: Mon, 28 Jul 2014 09:02:13 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: "payload@ietf.org" Content-Type: multipart/mixed; boundary="------------030807090404090602050201" Archived-At: http://mailarchive.ietf.org/arch/msg/payload/fAADODpJ-62BpV7gFtwkzCsS5QY Subject: [payload] Review of draft-ietf-payload-rtp-opus-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jul 2014 16:02:29 -0000 This is a multi-part message in MIME format. --------------030807090404090602050201 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I have reviewed draft-itef-payload-rtp-opus-02. After the issues below are addressed, I think this draft is ready for WGLC. The following suggestions/corrections are not meant to change the meaning of any text, merely clarify or improve the wording. Abstract: "that is essential to" -> "necessary to" (fewer words is better) "Further, media type registrations are described" -> "Further, it describes media type registrations" (remove passive voice) 1. Introduction " (codec)" -> "" (this WG is never referred to again, so defining the short name is unnecessary) "thus, making" -> "thus making" The same suggestions made for the abstract also apply to the text from it that is repeated here. 2. Conventions, Definitions and Acronyms used in this document "usually " -> "" (the term is used a total of 3 times in the document, all in the same paragraph, which also makes it clear that it means "per channel"... no reason to suggest to the reader that it might be ambiguous here) 2.1 Audio Bandwidth "Bandwidth" -> "Audio Bandwidth (Hz)" "Sampling" -> "Sampling Rate (Hz)" Although the section is called "Audio Bandwidth", there's no reason not to give units in these column headers to make it clear we're not talking about network bandwidth (bits per second). The abbreviations should also probably be capitalized (the document uses capitalization for these abbreviations inconsistently, but I think the capitalized version should be preferred). 3. Opus Codec The first couple of sentences use "speech and audio" quite a few times, but never distinguish how "speech" is not also "audio". Suggest replacing them with the following text: The Opus [RFC6716] codec encodes speech signals as well as general audio signals. Two different modes can be chosen, a voice mode or an audio mode, to allow the most efficient coding depending on the type of the input signal, the sampling frequency of the input signal, and the intended application. The next sentence should also say "general audio signals" instead of just "audio signals". 3.1 Network Bandwidth "a higher bitrate results in higher quality" -> "higher bitrates result in higher quality" 3.1.2 Variable versus Constant Bit Rate "Bit Rate" -> "Bitrate" (for consistency with the rest of the document) "application" -> "applications" "One potential reason ... is the potential..." -> "One reason ... is the potential..." "_may_" -> "_might_" The document uses "may", "should", and "required" in a number of non-2119 contexts. These should all be changed to "might"/"can", "ought to", and "needed"/"necessary" as appropriate. 3.1.3 Discontinuous Transmission (DTX) "may" -> "can" "an adaptive bitrate" -> "a variable bitrate" (the referenced section describes "variable bitrate", but never defines "adaptive bitrate") "In that case, the bitrate will automatically be reduced for certain input signals like periods of silence. During continuous transmission the bitrate will be reduced, when the input signal allows to do so, but the transmission to the receiver itself will never be interrupted." -> "In that case, the encoder will automatically reduce the bitrate for certain input signals, like periods of silence. When using continuous transmission, it will reduce the bitrate when the characteristics of the input signal permit, but will never interrupt the transmission to the receiver." (remove passive voice and the ungrammatical "allows to do so"; also change "During" to "When using" to clarify that this is a choice) "may be set to" -> "can" The last paragraph in the section should also remove references to a DTX "mode", to avoid ambiguity with the speech mode or audio mode. RFC 6716 is very careful to define a "mode" of operation as only the choice of SILK or CELT, and refer to other parameter choices as a "configuration", to avoid making the word "mode" ambiguous. This document should take the same care. It should also move the last sentence of this paragraph to the front, so that the conclusion is last (and replace "adaptive" with "variable" again, for consistency). Proposed alternative text: DTX can be used with both variable and constant bitrate. It will have a slightly lower speech or audio quality than continuous transmission. Therefore, using continuous transmission is RECOMMENDED unless restraints on network capacity are severe. 3.3 Forward Error Correction (FEC) "allows for "in-band" forward error correction data to be embedded" -> "allows for embedding "in-band" forward error correction data" (remove passive voice) "the bit stream of Opus" -> "the Opus bit stream" "(n-1)" -> "(N-1)" "n" -> "N" "when, in case of a packet loss, the next packet is available" -> "when it loses a packet and the next packet is available" (remove ungrammatical use of "in case of") "will consider ... and invokes the frame loss concealment." -> "will consider ... and invoke frame loss concealment." (avoid tense change and remove an inappropriate article) 3.4 Stereo Operation "required" -> "needed" "usage of the network" -> "usage of network resources" (for consistency with the wording in Section 3.3) 4.1 RTP Header Usage "The Opus payload format uses the fields of the RTP header consistent with this specification." -> "The use of the fields of the RTP header by the Opus payload format is consistent with that specification." (avoid awkward use of the adverb "consistently", which would be required to make the original sentence correct; also "this specification" would be the current draft, use "that specification" to refer to RFC3550) "is a multiple number of octets" -> "is an integer number of octets" "required" -> "necessary" "duplicates of RTP packets" -> "duplicate RTP packets" "Only one of those payloads MUST be provided to the Opus decoder for decoding and others MUST be discarded." -> "The receiver MUST provide only one of those payloads to the Opus decoder for decoding, and MUST discard the others." (remove passive voice, particularly in a sentence that places normative requirements on an actor without naming that actor) "bandwidths which may" -> "bandwidths, which can" (the clause is non-restrictive, and non-normative) The language in this paragraph should also be made consistent with the language in Section 6.1 (when describing the rate: parameter). Proposed text: Opus supports 5 different audio bandwidths, which can be adjusted during a call. The RTP timestamp is incremented with a 48000 Hz clock rate for all modes of Opus and all sampling rates. The unit for the timestamp is samples per single (mono) channel. The RTP timestamp corresponds to the sample time of the first encoded sample in the encoded frame. For data encoded with sampling rates other than 48000 Hz, the sampling rate has to be adjusted to 48000 Hz using the corresponding multiplier in Table 2. "fs" -> "Sampling Rate" (fs is not yet a defined term; recommend "Sampling Rate" for consistency with the text and with Table 1) 4.2 Payload Structure "can be set to" -> "can" "...combined into a packet. The maximum packet length is limited to the amount of encoded data representing 120 ms of speech or audi odata." -> "...combined into a packet, up to a maximum packet duration representing 120 ms of speech or audio data." (keeping these in the same sentence prevents a reader from stopping at the end of the first sentence and not realizing the next imposes an additional restriction; also, replace "length" with the less ambiguous "duration", to be clear we're not talking about a restriction on the number of bytes) "... encoder and therefore only one packet output from the Opus encoder MUST be used as a payload" -> "...encoder, and therefore an RTP payload MUST contain exactly one packet output from the Opus encoder." (remove passive voice from normative requirements; a change in subject requires a comma before "and") Figure 1 should be centered instead of left-justified. "and how" -> "and shows how" (repeat the verb to provide a better indication what clause the "and" here applies to) "the timestamps have to be added up according to the combined frames" -> "the timestamp increment is the sum of the increments for the individual frames" (we aren't adding timestamps, and "according to" is ambiguous) nb, mb, etc. in Table 3 should be capitalized. 5. Congestion Control "The adaptive nature of the Opus codec allows for an efficient congestion control." -> "" (this is redundant with the sentence right after it) "time and thus" -> "time, thus" "allowing for an efficient" -> "allowing efficient" "control since" -> "control, since" (unrestrictive clause) "these frame sizes" -> "the packet duration" (the previous part of the sentence talks about a packet, not frames) "overhead but" -> "overhead, but" "error sensitivity" -> "loss sensitivity" (let's be clear about the kind of errors we're worried about) "sensitivity and should be done" -> "sensitivity, so it ought to be used" (non-normative should; also, it is not clear how to "do" a lower packet transmission rate) "It is RECOMMENDED that congestion control is applied during the transmission of Opus encoded data." -> "It is RECOMMENDED that senders of Opus encoded data apply congestion control." (remove passive voice from normative requirements) 6.1 Opus Media Type Registration "RTP timestamp clock rate" -> "the RTP timestamp" (clock rate appears redundantly elsewhere in the same sentence; missing article) "with 48000 Hz clock rate" -> "with a 48000 Hz clock rate" (missing article) "sampling frequencies" -> "sampling rates" (for consistency with the rest of the document) "For audio sampling rates other than 48000 Hz the rate has to be adjusted to 48000 Hz according to Table 2." -> "For data encoded with sampling rates other than 48000 Hz, the sampling rate has to be adjusted to 48000 Hz using the corresponding multiplier in Table 2." (for consistency with proposed text in Section 4.1) "the decoder's maximum length of time in milliseconds rounded up to the next full integer value represented by the media in a packet that can be encapsulated in a received packet according to Section 6 of RFC4566." This is quite the mouthful, and it is quite ambiguous which clauses refer to which (especially the reference to RFC4566). It is also phrased as an absolute requirement, when several sentences later the document clearly states it is not one. How about "the maximum duration of media represented by a packet (according to Section 6 of RFC4566) that a decoder wants to receive, in milliseconds rounded up to the next full integer value." I am inferring here that RFC4566 is being invoked solely to define the duration of a packet, since the same phrase appears in the definition of minptime, which is not defined by RFC4566. "...40, and 60 or an arbitrary multiple of Opus frame sizes rounded up to the next full integer value up to a maximum value of 120 as defined..." -> "...40, 50, or an arbitrary multiple of an Opus frame size rounded up to the next full integer value, up to a maximum of 120, as defined..." (both using and omitting a serial comma in the same sentence; it is unclear what "a" multiple of several "frame sizes" might be... in practice it must be a multiple of _one_ frame size, though since all frame sizes are themselves a multiple of a 2.5 ms frame size, this does not impose any additional restrictions; also added some missing commas) "120 is assumed as default" -> "the default is 120" (no reason not to be direct) The corresponding text for ptime and minptime should be changed in the same ways. "may vary as it" -> "can vary, as it" (non-nomrative may, non-restrictive clause) "allowed but" -> "allowed, but" "range between 6000 and 510000" -> "range 6000 to 510000" (I assume this was meant to be inclusive) "maxplaybackrate:" -> "maxplaybackrate" "will be the default" -> 'is the default" "utilisation" -> "utilization" (for consistency with the American spelling in the rest of the document) "mono is assumed (stereo=0)" -> "the default is 0 (mono)" "1 and 0 where" -> "1 and 0, where" "preferred and 0 specifies" -> "preferred, and 0 specifies" (comma for new subject) "mono is assumed (sprop-stereo=0)" -> "the default is 0 (mono)" "1 and 0 where" -> "1 and 0, where" "bitrate and 0 specifies" -> "bitrate, and 0 specifies" (comma for new subject) "cbr is assumed to be 0" -> "the default is 0 (vbr)" "Note that the maximum average bitrate may still be changed..." -> "When cbr is 1, the maximum average bitrate can still change..." (the phrase "Note that" is always superfluous; this is only surprising when cbr is enabled, so let's call out that case; also, remove the non-normative may). "It is RECOMMENDED to provide 0 in case FEC cannot be utilized..." -> "Providing 0 when FEC cannot be used... is RECOMMENDED." (less awkward phrasing; "used" is always preferable to "utilized") "usedtx is assumed to be 0" -> "the default is 0" "Opus media type is..." -> "The Opus media type is..." "may use this media type" -> "can use this media type" 6.2.1 Offer-Answer Model Considerations for Opus "is not subject to this payload format description" -> "is not restricted by this payload format description" (it is unclear what "subject to" actually means) "capable to decode" -> "capable of decoding" "dependent on the set values of the parameters the performance of the application may suffer" -> "some values might cause application performance to suffer" (non-normative may, indirect phrasing) "and should be set with care" -> "and ought to be used with care" (non-normative should; subject-verb disagreement) "as a function of the bitrates" -> "as a function of the bitrate" 6.2.2 Declarative SDP Considerations for Opus "should be selected" -> "ought to be selected" (non-normative should) "capable to accept" -> "capable of accepting" "may be provided" -> "can be provided" (non-normative may) "should be kept small" -> "ought to be kept small" (non-normative should) 7. Security Considerations "from e.g., RFC3711" -> "from, e.g., RFC3711" "audio data, hence, ..." -> "audio data. Hence, ..." I have a few more proposals that do change the meaning of the text: 3.1.2 Variable versus Constant Bitrate "the average bitrate SHOULD be adjusted to the available network capacity" -> "the average bitrate SHOULD NOT exceed the available network capacity" We shouldn't encourage people to fill up the pipe just because it's available. 3.3 Forward Error Correction (FEC) This section talks about "the decoder API", which presupposes a specific implementation of Opus. There's no reason not to be implementation-independent here. Proposed text: "The decoder API function has a flag to indicate that a FEC frame rather than a regular frame should be decoded." -> "The receiver can then configure its decoder to decode the FEC data from the packet rather than the regular audio data." 4.2 Payload Structure The current encoder API has limited support for creating packets containing multiple frames, and a separate repacketizer API is provided to construct such multi-frame packets. The current text suggests the latter is forbidden, but I don't believe that's the intent. Proposed text: "The packetization of encoded data is purely done by the Opus encoder, and therefore an RTP payload MUST contain exactly one packet output from the Opus encoder." -> "The grouping of one or more Opus frames into a single Opus packet is defined in Section 3 of RFC6716. An RTP payload MUST contain exactly one Opus packet as defined by that document." 6.2.1 Offer-Answer Model Considerations for Opus Based on off-list feedback I got recently, I propose the following text for maxplaybackrate: o The "maxplaybackrate" parameter is a unidirectional receive-only parameter that reflects limitations of the local receiver. When sending to a single destination, a sender MUST NOT use an audio bandwidth higher than necessary to represent audio sampled at a sampling rate of "maxplaybackrate". Gateways or senders that are sending the same encoded audio to multiple destinations SHOULD NOT use an audio bandwidth higher than necessary to represent audio sampled at "maxplaybackrate", as this would lead to inefficient use of network resources. The "maxplaybackrate" parameter does not affect interoperability. Also, this parameter SHOULD NOT be used to adjust the audio bandwidth as a function of the bitrate, as this is the responsibility of the Opus encoder implementation. The change from "an audio bandwidth higher than 'maxplaybackrate'" to "an audio bandwidth higher than necessary to represent audio sampled at a sampling rate of 'maxplaybackrate'" was done to handle the fact that maxplaybackrate is a sampling rate, which is typically at least twice the value of the corresponding audio bandwidth, and to handle the case where maxplaybackrate does not correspond exactly to one of the sampling rates supported by Opus (e.g., fully representing audio sampled at 32 kHz would require using Opus in a fullband configuration... given typical rate allocations of the encoder, the waste from using 48 kHz instead of 32 kHz would only be a handful of bits per frame). Similarly, for stereo: o The "stereo" parameter is a unidirectional receive-only parameter. When sending to a single destination, a sender MUST NOT use stereo when "stereo" is 0. Gateways or senders that are sending the same encoded audio to multiple destinations SHOULD NOT use stereo when "stereo" is 0, as this would lead to inefficient use of network resources. The "stereo" parameter does not affect interoperability. I think this strikes the right balance between giving receivers the leverage they need to keep senders from wasting their network resources while allowing gateways to avoid transcoding. If others have advice to implementers on how to handle multiparty situations (e.g., a 3-way mesh call where someone joins from the PSTN), feel free to propose text on the list. I've attached git patches for both sets of changes. --------------030807090404090602050201 Content-Type: text/x-patch; name="0001-RTP-draft-edits-no-normative-changes.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-RTP-draft-edits-no-normative-changes.patch" >From 2ce26299b264a5a190bae21fd59e5f51f37d8b3d Mon Sep 17 00:00:00 2001 From: "Timothy B. Terriberry" Date: Fri, 25 Jul 2014 21:45:46 -0700 Subject: [PATCH 1/2] RTP draft edits (no normative changes). This is the result of an editing pass for clarity and consistency. --- doc/draft-ietf-payload-rtp-opus.xml | 396 ++++++++++++++++++------------------ 1 file changed, 198 insertions(+), 198 deletions(-) diff --git a/doc/draft-ietf-payload-rtp-opus.xml b/doc/draft-ietf-payload-rtp-opus.xml index 89a980c..afa7284 100644 --- a/doc/draft-ietf-payload-rtp-opus.xml +++ b/doc/draft-ietf-payload-rtp-opus.xml @@ -71,203 +71,203 @@ This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus encoded - speech and audio data that is essential to integrate the codec in the - most compatible way. Further, media type registrations - are described for the RTP payload format. + speech and audio data necessary to integrate the codec in the + most compatible way. Further, it describes media type registrations + for the RTP payload format.
The Opus codec is a speech and audio codec developed within the - IETF Internet Wideband Audio Codec working group (codec). The codec + IETF Internet Wideband Audio Codec working group. The codec has a very low algorithmic delay and it is highly scalable in terms of audio bandwidth, bitrate, and complexity. Further, it provides different modes to efficiently encode speech signals - as well as music signals, thus, making it the codec of choice for + as well as music signals, thus making it the codec of choice for various applications using the Internet or similar networks. This document defines the Real-time Transport Protocol (RTP) payload format for packetization - of Opus encoded speech and audio data that is essential to + of Opus encoded speech and audio data necessary to integrate the Opus codec in the - most compatible way. Further, media type registrations are described for + most compatible way. Further, it describes media type registrations for the RTP payload format. More information on the Opus codec can be obtained from .
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . Constant bitrate Central Processing Unit Discontinuous transmission Forward error correction - Internet Protocol - Speech or audio samples (usually per channel) - Session Description Protocol + Internet Protocol + Speech or audio samples (per channel) + Session Description Protocol Variable bitrate
- - Throughout this document, we refer to the following definitions: - + + Throughout this document, we refer to the following definitions: + - Abbreviation + Abbreviation Name - Bandwidth - Sampling - nb + Audio Bandwidth (Hz) + Sampling Rate (Hz) + NB Narrowband 0 - 4000 8000 - mb + MB Mediumband 0 - 6000 12000 - wb + WB Wideband 0 - 8000 16000 - swb + SWB Super-wideband 0 - 12000 24000 - fb + FB Fullband 0 - 20000 48000 Audio bandwidth naming
- The Opus speech and audio codec has been developed to encode speech - signals as well as audio signals. Two different modes, a voice mode - or an audio mode, may be chosen to allow the most efficient coding - dependent on the type of input signal, the sampling frequency of the - input signal, and the specific application. + The Opus codec encodes speech + signals as well as general audio signals. Two different modes can be + chosen, a voice mode or an audio mode, to allow the most efficient coding + depending on the type of the input signal, the sampling frequency of the + input signal, and the intended application. The voice mode allows efficient encoding of voice signals at lower bit - rates while the audio mode is optimized for audio signals at medium and + rates while the audio mode is optimized for general audio signals at medium and higher bitrates. The Opus speech and audio codec is highly scalable in terms of audio bandwidth, bitrate, and complexity. Further, Opus allows transmitting stereo signals.
- Opus supports all bitrates from 6 kb/s to 510 kb/s. - The bitrate can be changed dynamically within that range. - All - other parameters being - equal, higher bitrate results in higher quality. - -
- - For a frame size of - 20 ms, these - are the bitrate "sweet spots" for Opus in various configurations: + Opus supports all bitrates from 6 kb/s to 510 kb/s. + The bitrate can be changed dynamically within that range. + All + other parameters being + equal, higher bitrates result in higher quality. + +
+ + For a frame size of + 20 ms, these + are the bitrate "sweet spots" for Opus in various configurations: - 8-12 kb/s for NB speech, - 16-20 kb/s for WB speech, - 28-40 kb/s for FB speech, - 48-64 kb/s for FB mono music, and - 64-128 kb/s for FB stereo music. - - + 8-12 kb/s for NB speech, + 16-20 kb/s for WB speech, + 28-40 kb/s for FB speech, + 48-64 kb/s for FB mono music, and + 64-128 kb/s for FB stereo music. + +
-
+
+ + For the same average bitrate, variable bitrate (VBR) can achieve higher quality + than constant bitrate (CBR). For the majority of voice transmission applications, VBR + is the best choice. One reason for choosing CBR is the potential + information leak that might occur when encrypting the + compressed stream. See for guidelines on when VBR is + appropriate for encrypted audio communications. In the case where an existing + VBR stream needs to be converted to CBR for security reasons, then the Opus padding + mechanism described in is the RECOMMENDED way to achieve padding + because the RTP padding bit is unencrypted. + - For the same average bitrate, variable bitrate (VBR) can achieve higher quality - than constant bitrate (CBR). For the majority of voice transmission application, VBR - is the best choice. One potential reason for choosing CBR is the potential - information leak that may occur when encrypting the - compressed stream. See for guidelines on when VBR is - appropriate for encrypted audio communications. In the case where an existing - VBR stream needs to be converted to CBR for security reasons, then the Opus padding - mechanism described in is the RECOMMENDED way to achieve padding - because the RTP padding bit is unencrypted. - - The bitrate can be adjusted at any point in time. To avoid congestion, the average bitrate SHOULD be adjusted to the available network capacity. If no target bitrate is specified, the bitrates specified in are RECOMMENDED.
- The Opus codec may, as described in , - be operated with an adaptive bitrate. In that case, the bitrate - will automatically be reduced for certain input signals like periods - of silence. During continuous transmission the bitrate will be - reduced, when the input signal allows to do so, but the transmission - to the receiver itself will never be interrupted. Therefore, the + The Opus codec can, as described in , + be operated with a variable bitrate. In that case, the encoder will + automatically reduce the bitrate for certain input signals, like periods + of silence. When using continuous transmission, it will reduce the + bitrate when the characteristics of the input signal permit, but + will never interrupt the transmission to the receiver. Therefore, the received signal will maintain the same high level of quality over the full duration of a transmission while minimizing the average bit rate over time. In cases where the bitrate of Opus needs to be reduced even further or in cases where only constant bitrate is available, - the Opus encoder may be set to use discontinuous + the Opus encoder can use discontinuous transmission (DTX), where parts of the encoded signal that correspond to periods of silence in the input speech or audio signal are not transmitted to the receiver. On the receiving side, the non-transmitted parts will be handled by a frame loss concealment unit in the Opus decoder which generates a comfort noise signal to replace the non transmitted parts of the speech or audio signal. - The DTX mode of Opus will have a slightly lower speech or audio - quality than the continuous mode. Therefore, it is RECOMMENDED to - use Opus in the continuous mode unless restraints on network - capacity are severe. The DTX mode can be engaged for operation - in both adaptive or constant bitrate. + DTX can be used with both variable and constant bitrate. + It will have a slightly lower speech or audio + quality than continuous transmission. Therefore, using continuous + transmission is RECOMMENDED unless restraints on network capacity + are severe.
@@ -276,147 +276,148 @@ a trade-off between audio quality and bitrate. Also, different modes of Opus have different complexity.
- The voice mode of Opus allows for "in-band" forward error correction (FEC) - data to be embedded into the bit stream of Opus. This FEC scheme adds - redundant information about the previous packet (n-1) to the current - output packet n. For + The voice mode of Opus allows for embedding "in-band" forward error correction (FEC) + data into the Opus bit stream. This FEC scheme adds + redundant information about the previous packet (N-1) to the current + output packet N. For each frame, the encoder decides whether to use FEC based on (1) an externally-provided estimate of the channel's packet loss rate; (2) an externally-provided estimate of the channel's capacity; (3) the sensitivity of the audio or speech signal to packet loss; (4) whether the receiving decoder has indicated it can take advantage of "in-band" FEC information. The decision to send "in-band" FEC information is entirely controlled by the encoder and therefore no special precautions for the payload have to be taken. On the receiving side, the decoder can take advantage of this - additional information when, in case of a packet loss, the next packet + additional information when it loses a packet and the next packet is available. In order to use the FEC data, the jitter buffer needs to provide access to payloads with the FEC data. The decoder API function has a flag to indicate that a FEC frame rather than a regular frame should be decoded. If no FEC data is available for the current frame, the decoder - will consider the frame lost and invokes the frame loss concealment. + will consider the frame lost and invoke frame loss concealment. If the FEC scheme is not implemented on the receiving side, FEC SHOULD NOT be used, as it leads to an inefficient usage of network resources. Decoder support for FEC SHOULD be indicated at the time a session is set up.
Opus allows for transmission of stereo audio signals. This operation is signaled in-band in the Opus payload and no special arrangement - is required in the payload format. Any implementation of the Opus + is needed in the payload format. Any implementation of the Opus decoder MUST be capable of receiving stereo signals, although it MAY - decode those signals as mono. + decode those signals as mono. If a decoder can not take advantage of the benefits of a stereo signal this SHOULD be indicated at the time a session is set up. In that case the sending side SHOULD NOT send stereo signals as it leads to an - inefficient usage of the network. + inefficient usage of network resources.
The payload format for Opus consists of the RTP header and Opus payload data.
- The format of the RTP header is specified in . The Opus - payload format uses the fields of the RTP header consistent with this - specification. + The format of the RTP header is specified in . + The use of the fields of the RTP header by the Opus payload format is + consistent with that specification. - The payload length of Opus is a multiple number of octets and - therefore no padding is required. The payload MAY be padded by an + The payload length of Opus is an integer number of octets and + therefore no padding is necessary. The payload MAY be padded by an integer number of octets according to . The marker bit (M) of the RTP header is used in accordance with - Section 4.1 of . + Section 4.1 of . The RTP payload type for Opus has not been assigned statically and is expected to be assigned dynamically. - The receiving side MUST be prepared to receive duplicates of RTP - packets. Only one of those payloads MUST be provided to the Opus decoder - for decoding and others MUST be discarded. + The receiving side MUST be prepared to receive duplicate RTP + packets. The receiver MUST provide only one of those payloads to the + Opus decoder for decoding, and MUST discard the others. - Opus supports 5 different audio bandwidths which may be adjusted during - the duration of a call. The RTP timestamp clock frequency is defined as - the highest supported sampling frequency of Opus, i.e. 48000 Hz, for all - modes and sampling rates of Opus. The unit + Opus supports 5 different audio bandwidths, which can be adjusted during + a call. + The RTP timestamp is incremented with a 48000 Hz clock rate + for all modes of Opus and all sampling rates. + The unit for the timestamp is samples per single (mono) channel. The RTP timestamp corresponds to the - sample time of the first encoded sample in the encoded frame. For sampling - rates lower than 48000 Hz the number of samples has to be multiplied with - a multiplier according to to determine - the RTP timestamp. + sample time of the first encoded sample in the encoded frame. + For data encoded with sampling rates other than 48000 Hz, + the sampling rate has to be adjusted to 48000 Hz using the + corresponding multiplier in . - fs (Hz) + Sampling Rate (Hz) Multiplier 8000 6 12000 4 16000 3 24000 2 48000 1
- The Opus encoder can be set to output encoded frames representing 2.5, 5, 10, 20, - 40, or 60 ms of speech or audio data. Further, an arbitrary number of frames can be - combined into a packet. The maximum packet length is limited to the amount of encoded - data representing 120 ms of speech or audio data. The packetization of encoded data - is purely done by the Opus encoder and therefore only one packet output from the Opus - encoder MUST be used as a payload. + The Opus encoder can output encoded frames representing 2.5, 5, 10, 20, + 40, or 60 ms of speech or audio data. Further, an arbitrary number of frames can be + combined into a packet, up to a maximum packet duration representing + 120 ms of speech or audio data. The packetization of encoded data + is purely done by the Opus encoder, and therefore an RTP payload MUST + contain exactly one packet output from the Opus encoder. shows the structure combined with the RTP header.
- +
shows supported frame sizes in - milliseconds of encoded speech or audio data for speech and audio mode - (Mode) and sampling rates (fs) of Opus and how the timestamp needs to - be incremented for packetization (ts incr). If the Opus encoder - outputs multiple encoded frames into a single packet the timestamps - have to be added up according to the combined frames. + milliseconds of encoded speech or audio data for the speech and audio modes + (Mode) and sampling rates (fs) of Opus and shows how the timestamp is + incremented for packetization (ts incr). If the Opus encoder + outputs multiple encoded frames into a single packet, the timestamp + increment is the sum of the increments for the individual frames. Mode fs 2.5 5 @@ -428,72 +429,71 @@ all 120 240 480 960 1920 2880 voice - nb/mb/wb/swb/fb + NB/MB/WB/SWB/FB x x x x audio - nb/wb/swb/fb + NB/WB/SWB/FB x x x x
- The adaptive nature of the Opus codec allows for an efficient - congestion control. - - The target bitrate of Opus can be adjusted at any point in time and - thus allowing for an efficient congestion control. Furthermore, the amount + The target bitrate of Opus can be adjusted at any point in time, thus + allowing efficient congestion control. Furthermore, the amount of encoded speech or audio data encoded in a - single packet can be used for congestion control since the transmission - rate is inversely proportional to these frame sizes. A lower packet - transmission rate reduces the amount of header overhead but at the same - time increases latency and error sensitivity and should be done with care. - - It is RECOMMENDED that congestion control is applied during the - transmission of Opus encoded data. + single packet can be used for congestion control, since the transmission + rate is inversely proportional to the packet duration. A lower packet + transmission rate reduces the amount of header overhead, but at the same + time increases latency and loss sensitivity, so it ought to be used with + care. + + It is RECOMMENDED that senders of Opus encoded data apply congestion + control.
One media subtype (audio/opus) has been defined and registered as described in the following section.
Media type registration is done according to and . Type name: audio Subtype name: opus Required parameters: - RTP timestamp clock rate is incremented with + the RTP timestamp is incremented with a 48000 Hz clock rate for all modes of Opus and all sampling - frequencies. For audio sampling rates other than 48000 Hz the rate - has to be adjusted to 48000 Hz according to . + rates. For data encoded with sampling rates other than 48000 Hz, + the sampling rate has to be adjusted to 48000 Hz using the + corresponding multiplier in . Optional parameters: a hint about the maximum output sampling rate that the receiver is @@ -520,137 +520,138 @@ processing pipeline (e.g. echo cancellation) at a higher rate than necessary. This parameter can take any value between 8000 and 48000, although commonly the value will match one of the Opus bandwidths (). By default, the sender is assumed to have no limitations, i.e. 48000. - the decoder's maximum length of time in - milliseconds rounded up to the next full integer value represented - by the media in a packet that can be - encapsulated in a received packet according to Section 6 of - . Possible values are 3, 5, 10, 20, 40, - and 60 or an arbitrary multiple of Opus frame sizes rounded up to - the next full integer value up to a maximum value of 120 as + the maximum duration of media represented + by a packet (according to Section 6 of + ) that a decoder wants to receive, in + milliseconds rounded up to the next full integer value. + Possible values are 3, 5, 10, 20, 40, 60, or an arbitrary + multiple of an Opus frame size rounded up to the next full integer + value, up to a maximum value of 120, as defined in . If no value is - specified, 120 is assumed as default. This value is a recommendation + specified, the default is 120. This value is a recommendation by the decoding side to ensure the best performance for the decoder. The decoder MUST be capable of accepting any allowed packet sizes to ensure maximum compatibility. - the decoder's recommended length of time in - milliseconds rounded up to the next full integer value represented - by the media in a packet according to - Section 6 of . Possible values are - 3, 5, 10, 20, 40, or 60 or an arbitrary multiple of Opus frame sizes - rounded up to the next full integer value up to a maximum - value of 120 as defined in the preferred duration of media represented + by a packet (according to Section 6 of + ) that a decoder wants to receive, in + milliseconds rounded up to the next full integer value. + Possible values are 3, 5, 10, 20, 40, 60, or an arbitrary + multiple of an Opus frame size rounded up to the next full integer + value, up to a maximum value of 120, as defined in . If no value is - specified, 20 is assumed as default. If ptime is greater than + specified, the default is 20. If ptime is greater than maxptime, ptime MUST be ignored. This parameter MAY be changed during a session. This value is a recommendation by the decoding side to ensure the best performance for the decoder. The decoder MUST be capable of accepting any allowed packet sizes to ensure maximum compatibility. - the decoder's minimum length of time in - milliseconds rounded up to the next full integer value represented - by the media in a packet that SHOULD - be encapsulated in a received packet according to Section 6 of . Possible values are 3, 5, 10, 20, 40, and 60 + the minimum duration of media represented + by a packet (according to Section 6 of + ) that SHOULD be encapsulated in a received + packet, in milliseconds rounded up to the next full integer value. + Possible values are 3, 5, 10, 20, 40, and 60 or an arbitrary multiple of Opus frame sizes rounded up to the next full integer value up to a maximum value of 120 as defined in . If no value is - specified, 3 is assumed as default. This value is a recommendation + specified, the default is 3. This value is a recommendation by the decoding side to ensure the best performance for the decoder. The decoder MUST be capable to accept any allowed packet sizes to ensure maximum compatibility. specifies the maximum average - receive bitrate of a session in bits per second (b/s). The actual - value of the bitrate may vary as it is dependent on the + receive bitrate of a session in bits per second (b/s). The actual + value of the bitrate can vary, as it is dependent on the characteristics of the media in a packet. Note that the maximum average bitrate MAY be modified dynamically during a session. Any - positive integer is allowed but values outside the range between - 6000 and 510000 SHOULD be ignored. If no value is specified, the + positive integer is allowed, but values outside the range + 6000 to 510000 SHOULD be ignored. If no value is specified, the maximum value specified in - for the corresponding mode of Opus and corresponding maxplaybackrate: - will be the default. + for the corresponding mode of Opus and corresponding maxplaybackrate + is the default. specifies whether the decoder prefers receiving stereo or mono signals. - Possible values are 1 and 0 where 1 specifies that stereo signals are preferred + Possible values are 1 and 0 where 1 specifies that stereo signals are preferred, and 0 specifies that only mono signals are preferred. Independent of the stereo parameter every receiver MUST be able to receive and decode stereo signals but sending stereo signals to a receiver that signaled a preference for mono signals may result in higher than necessary network - utilisation and encoding complexity. If no value is specified, mono - is assumed (stereo=0). + utilization and encoding complexity. If no value is specified, + the default is 0 (mono). specifies whether the sender is likely to produce stereo audio. - Possible values are 1 and 0 where 1 specifies that stereo signals are likely to - be sent, and 0 speficies that the sender will likely only send mono. - This is not a guarantee that the sender will never send stereo audio - (e.g. it could send a pre-recorded prompt that uses stereo), but it - indicates to the receiver that the received signal can be safely downmixed to mono. - This parameter is useful to avoid wasting receiver resources by operating the audio - processing pipeline (e.g. echo cancellation) in stereo when not necessary. - If no value is specified, mono - is assumed (sprop-stereo=0). + Possible values are 1 and 0, where 1 specifies that stereo signals are likely to + be sent, and 0 specifies that the sender will likely only send mono. + This is not a guarantee that the sender will never send stereo audio + (e.g. it could send a pre-recorded prompt that uses stereo), but it + indicates to the receiver that the received signal can be safely downmixed to mono. + This parameter is useful to avoid wasting receiver resources by operating the audio + processing pipeline (e.g. echo cancellation) in stereo when not necessary. + If no value is specified, the default is 0 + (mono). specifies if the decoder prefers the use of a constant bitrate versus - variable bitrate. Possible values are 1 and 0 where 1 specifies constant - bitrate and 0 specifies variable bitrate. If no value is specified, cbr - is assumed to be 0. Note that the maximum average bitrate may still be - changed, e.g. to adapt to changing network conditions. + variable bitrate. Possible values are 1 and 0, where 1 specifies constant + bitrate and 0 specifies variable bitrate. If no value is specified, + the default is 0 (vbr). When cbr is 1, the maximum average bitrate can still + change, e.g. to adapt to changing network conditions. specifies that the decoder has the capability to - take advantage of the Opus in-band FEC. Possible values are 1 and 0. It is RECOMMENDED to provide - 0 in case FEC cannot be utilized on the receiving side. If no + take advantage of the Opus in-band FEC. Possible values are 1 and 0. + Providing 0 when FEC cannot be used on the receiving side is + RECOMMENDED. If no value is specified, useinbandfec is assumed to be 0. This parameter is only a preference and the receiver MUST be able to process packets that include FEC information, even if it means the FEC part is discarded. specifies if the decoder prefers the use of - DTX. Possible values are 1 and 0. If no value is specified, usedtx - is assumed to be 0. + DTX. Possible values are 1 and 0. If no value is specified, the + default is 0. Encoding considerations: - Opus media type is framed and consists of binary data according - to Section 4.8 in . + The Opus media type is framed and consists of binary data according + to Section 4.8 in . Security considerations: See of this document. Interoperability considerations: none Published specification: none Applications that use this media type: Any application that requires the transport of - speech or audio data may use this media type. Some examples are, + speech or audio data can use this media type. Some examples are, but not limited to, audio and video conferencing, Voice over IP, media streaming. Person & email address to contact for further information: SILK Support silksupport@skype.net Jean-Marc Valin jmvalin@jmvalin.ca @@ -684,17 +685,17 @@ the mapping is as follows: The media type ("audio") goes in SDP "m=" as the media name. The media subtype ("opus") goes in SDP "a=rtpmap" as the encoding name. The RTP clock rate in "a=rtpmap" MUST be 48000 and the number of - channels MUST be 2. + channels MUST be 2. The OPTIONAL media type parameters "ptime" and "maxptime" are mapped to "a=ptime" and "a=maxptime" attributes, respectively, in the SDP. The OPTIONAL media type parameters "maxaveragebitrate", "maxplaybackrate", "minptime", "stereo", "cbr", "useinbandfec", and "usedtx", when present, MUST be included in the "a=fmtp" attribute @@ -770,65 +771,64 @@ target="RFC3264"/> to negotiate the use of Opus, the following considerations apply: Opus supports several clock rates. For signaling purposes only the highest, i.e. 48000, is used. The actual clock rate of the corresponding media is signaled inside the payload and is not - subject to this payload format description. The decoder MUST be - capable to decode every received clock rate. An example + restricted by this payload format description. The decoder MUST be + capable of decoding every received clock rate. An example is shown below:
The "ptime" and "maxptime" parameters are unidirectional receive-only parameters and typically will not compromise - interoperability; however, dependent on the set values of the - parameters the performance of the application may suffer. defines the SDP offer-answer handling of the "ptime" parameter. The "maxptime" parameter MUST be handled in the same way. The "minptime" parameter is a unidirectional receive-only parameters and typically will not compromise - interoperability; however, dependent on the set values of the - parameter the performance of the application may suffer and should be - set with care. + interoperability; however, some values might cause application + performance to suffer and ought to be used with care. The "maxplaybackrate" parameter is a unidirectional receive-only parameter that reflects limitations of the local receiver. The sender of the other side SHOULD NOT send with an audio bandwidth higher than "maxplaybackrate" as this would lead to inefficient use of network resources. The "maxplaybackrate" parameter does not - affect interoperability. Also, this parameter SHOULD NOT be used - to adjust the audio bandwidth as a function of the bitrates, as this - is the responsibility of the Opus encoder implementation. + affect interoperability. Also, this parameter SHOULD NOT be used + to adjust the audio bandwidth as a function of the bitrate, as this + is the responsibility of the Opus encoder implementation. The "maxaveragebitrate" parameter is a unidirectional receive-only parameter that reflects limitations of the local receiver. The sender of the other side MUST NOT send with an average bitrate higher than "maxaveragebitrate" as it might overload the network and/or receiver. The "maxaveragebitrate" parameter 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. + compromise interoperability; however, some values might cause + application performance to suffer, and ought to be set with + care. The "sprop-maxcapturerate" and "sprop-stereo" parameters are unidirectional sender-only parameters that reflect limitations of the sender side. They allow the receiver to set up a reduced-complexity audio processing pipeline if the sender is not planning to use the full range of Opus's capabilities. Neither "sprop-maxcapturerate" nor "sprop-stereo" affect @@ -861,46 +861,46 @@ For declarative use of SDP such as in Session Announcement Protocol (SAP), , and RTSP, , for Opus, the following needs to be considered: The values for "maxptime", "ptime", "minptime", "maxplaybackrate", and - "maxaveragebitrate" should be selected carefully to ensure that a + "maxaveragebitrate" ought to be selected carefully to ensure that a reasonable performance can be achieved for the participants of a session. The values for "maxptime", "ptime", and "minptime" of the payload format configuration are recommendations by the decoding side to ensure the best performance for the decoder. The decoder MUST be - capable to accept any allowed packet sizes to + capable of accepting any allowed packet sizes to ensure maximum compatibility. All other parameters of the payload format configuration are declarative and a participant MUST use the configurations that are provided for - the session. More than one configuration may be provided if necessary + the session. More than one configuration can be provided if necessary by declaring multiple RTP payload types; however, the number of types - should be kept small. + ought to be kept small.
All RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in the RTP - specification and any profile from - e.g. or . + specification and any profile from, + e.g., or . - This payload format transports Opus encoded speech or audio data, - hence, security issues include confidentiality, integrity protection, and + This payload format transports Opus encoded speech or audio data. + Hence, security issues include confidentiality, integrity protection, and authentication of the speech or audio itself. The Opus payload format does not have any built-in security mechanisms. Any suitable external mechanisms, such as SRTP , MAY be used. This payload format and the Opus encoding do not exhibit any significant non-uniformity in the receiver-end computational load and thus are unlikely to pose a denial-of-service threat due to the receipt of pathological datagrams. -- 1.8.3.2 --------------030807090404090602050201 Content-Type: text/x-patch; name="0002-RTP-draft-edits-normative-changes.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0002-RTP-draft-edits-normative-changes.patch" >From d9e116bcbfd182ac63e2e2fa2daf407d326b6345 Mon Sep 17 00:00:00 2001 From: "Timothy B. Terriberry" Date: Fri, 25 Jul 2014 22:33:55 -0700 Subject: [PATCH 2/2] RTP draft edits (normative changes). Here are my proposals to resolve a few issues with the current draft. See the corresponding message to the list for details. --- doc/draft-ietf-payload-rtp-opus.xml | 34 +++++++++++++++++++++++----------- 1 file changed, 23 insertions(+), 11 deletions(-) diff --git a/doc/draft-ietf-payload-rtp-opus.xml b/doc/draft-ietf-payload-rtp-opus.xml index afa7284..412ce0f 100644 --- a/doc/draft-ietf-payload-rtp-opus.xml +++ b/doc/draft-ietf-payload-rtp-opus.xml @@ -215,17 +215,17 @@ compressed stream. See for guidelines on when VBR is appropriate for encrypted audio communications. In the case where an existing VBR stream needs to be converted to CBR for security reasons, then the Opus padding mechanism described in is the RECOMMENDED way to achieve padding because the RTP padding bit is unencrypted. The bitrate can be adjusted at any point in time. To avoid congestion, - the average bitrate SHOULD be adjusted to the available + the average bitrate SHOULD NOT exceed the available network capacity. If no target bitrate is specified, the bitrates specified in are RECOMMENDED.
@@ -294,19 +294,20 @@ entirely controlled by the encoder and therefore no special precautions for the payload have to be taken. On the receiving side, the decoder can take advantage of this additional information when it loses a packet and the next packet is available. In order to use the FEC data, the jitter buffer needs - to provide access to payloads with the FEC data. The decoder API function - has a flag to indicate that a FEC frame rather than a regular frame should - be decoded. If no FEC data is available for the current frame, the decoder + to provide access to payloads with the FEC data. The receiver can + then configure its decoder to decode the FEC data from the packet + rather than the regular audio data. + If no FEC data is available for the current frame, the decoder will consider the frame lost and invoke frame loss concealment. If the FEC scheme is not implemented on the receiving side, FEC SHOULD NOT be used, as it leads to an inefficient usage of network resources. Decoder support for FEC SHOULD be indicated at the time a session is set up. @@ -383,19 +384,20 @@
The Opus encoder can output encoded frames representing 2.5, 5, 10, 20, 40, or 60 ms of speech or audio data. Further, an arbitrary number of frames can be combined into a packet, up to a maximum packet duration representing - 120 ms of speech or audio data. The packetization of encoded data - is purely done by the Opus encoder, and therefore an RTP payload MUST - contain exactly one packet output from the Opus encoder. + 120 ms of speech or audio data. The grouping of one or more Opus + frames into a single Opus packet is defined in Section 3 of + . An RTP payload MUST contain exactly one + Opus packet as defined by that document. shows the structure combined with the RTP header.
The "maxplaybackrate" parameter is a unidirectional receive-only - parameter that reflects limitations of the local receiver. The sender - of the other side SHOULD NOT send with an audio bandwidth higher than - "maxplaybackrate" as this would lead to inefficient use of network resources. + parameter that reflects limitations of the local receiver. When + sending to a single destination, a sender MUST NOT use an audio + bandwidth higher than necessary to represent audio sampled at + a sampling rate of "maxplaybackrate". Gateways or senders that + are sending the same encoded audio to multiple destinations + SHOULD NOT use an audio bandwidth higher than necessary to + represent audio sampled at "maxplaybackrate", as this would lead + to inefficient use of network resources. The "maxplaybackrate" parameter does not affect interoperability. Also, this parameter SHOULD NOT be used to adjust the audio bandwidth as a function of the bitrate, as this is the responsibility of the Opus encoder implementation. The "maxaveragebitrate" parameter is a unidirectional receive-only parameter that reflects limitations of the local receiver. The sender @@ -832,17 +839,22 @@ processing pipeline if the sender is not planning to use the full range of Opus's capabilities. Neither "sprop-maxcapturerate" nor "sprop-stereo" affect interoperability and the receiver MUST be capable of receiving any signal. The "stereo" parameter is a unidirectional receive-only - parameter. + parameter. When sending to a single destination, a sender MUST + NOT use stereo when "stereo" is 0. Gateways or senders that are + sending the same encoded audio to multiple destinations SHOULD + NOT use stereo when "stereo" is 0, as this would lead to + inefficient use of network resources. The "stereo" parameter does + not affect interoperability. The "cbr" parameter is a unidirectional receive-only parameter. The "useinbandfec" parameter is a unidirectional receive-only -- 1.8.3.2 --------------030807090404090602050201-- From nobody Wed Jul 30 12:38:34 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968441A040D; Wed, 30 Jul 2014 12:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fKZ473b3AHo; Wed, 30 Jul 2014 12:38:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8321A03F5; Wed, 30 Jul 2014 12:38:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140730193829.450.64578.idtracker@ietfa.amsl.com> Date: Wed, 30 Jul 2014 12:38:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/payload/G-oRccZBjzzEyTRouDEVLOBvN3g Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-opus-03.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2014 19:38:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for Opus Speech and Audio Codec Authors : Julian Spittka Koen Vos Jean-Marc Valin Filename : draft-ietf-payload-rtp-opus-03.txt Pages : 18 Date : 2014-07-30 Abstract: This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus encoded speech and audio data necessary to integrate the codec in the most compatible way. Further, it describes media type registrations for the RTP payload format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-opus-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-opus-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 30 17:06:35 2014 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBED1A01E5 for ; Wed, 30 Jul 2014 17:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=1, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWEzYkB0qs8t for ; Wed, 30 Jul 2014 17:06:27 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFFD91A016D for ; Wed, 30 Jul 2014 17:06:26 -0700 (PDT) Received: from panoramix.jmvalin.ca (modemcable167.97-201-24.mc.videotron.ca [24.201.97.167]) (Authenticated sender: jvalin@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id C4021F223D; Wed, 30 Jul 2014 17:06:25 -0700 (PDT) Message-ID: <53D98880.9050408@mozilla.com> Date: Wed, 30 Jul 2014 20:06:24 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Timothy B. Terriberry" , "payload@ietf.org" References: <53D67405.800@xiph.org> In-Reply-To: <53D67405.800@xiph.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/payload/NqnqVzIUk_P5m9x8Kb0e_cGTx80 Subject: Re: [payload] Review of draft-ietf-payload-rtp-opus-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2014 00:06:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks Tim, these changes are all included in the latest version of the draft I just posted. Jean-Marc On 28/07/14 12:02 PM, Timothy B. Terriberry wrote: > I have reviewed draft-itef-payload-rtp-opus-02. After the issues > below are addressed, I think this draft is ready for WGLC. > > The following suggestions/corrections are not meant to change the > meaning of any text, merely clarify or improve the wording. > > Abstract: > > "that is essential to" -> "necessary to" (fewer words is better) > > "Further, media type registrations are described" -> "Further, it > describes media type registrations" (remove passive voice) > > 1. Introduction > > " (codec)" -> "" (this WG is never referred to again, so defining > the short name is unnecessary) > > "thus, making" -> "thus making" > > The same suggestions made for the abstract also apply to the text > from it that is repeated here. > > 2. Conventions, Definitions and Acronyms used in this document > > "usually " -> "" (the term is used a total of 3 times in the > document, all in the same paragraph, which also makes it clear that > it means "per channel"... no reason to suggest to the reader that > it might be ambiguous here) > > 2.1 Audio Bandwidth > > "Bandwidth" -> "Audio Bandwidth (Hz)" > > "Sampling" -> "Sampling Rate (Hz)" > > Although the section is called "Audio Bandwidth", there's no reason > not to give units in these column headers to make it clear we're > not talking about network bandwidth (bits per second). > > The abbreviations should also probably be capitalized (the document > uses capitalization for these abbreviations inconsistently, but I > think the capitalized version should be preferred). > > 3. Opus Codec > > The first couple of sentences use "speech and audio" quite a few > times, but never distinguish how "speech" is not also "audio". > Suggest replacing them with the following text: > > The Opus [RFC6716] codec encodes speech signals as well as general > audio signals. Two different modes can be chosen, a voice mode or > an audio mode, to allow the most efficient coding depending on the > type of the input signal, the sampling frequency of the input > signal, and the intended application. > > The next sentence should also say "general audio signals" instead > of just "audio signals". > > 3.1 Network Bandwidth > > "a higher bitrate results in higher quality" -> "higher bitrates > result in higher quality" > > 3.1.2 Variable versus Constant Bit Rate > > "Bit Rate" -> "Bitrate" (for consistency with the rest of the > document) > > "application" -> "applications" > > "One potential reason ... is the potential..." -> "One reason ... > is the potential..." > > "_may_" -> "_might_" > > The document uses "may", "should", and "required" in a number of > non-2119 contexts. These should all be changed to "might"/"can", > "ought to", and "needed"/"necessary" as appropriate. > > 3.1.3 Discontinuous Transmission (DTX) > > "may" -> "can" > > "an adaptive bitrate" -> "a variable bitrate" (the referenced > section describes "variable bitrate", but never defines "adaptive > bitrate") > > "In that case, the bitrate will automatically be reduced for > certain input signals like periods of silence. During continuous > transmission the bitrate will be reduced, when the input signal > allows to do so, but the transmission to the receiver itself will > never be interrupted." -> "In that case, the encoder will > automatically reduce the bitrate for certain input signals, like > periods of silence. When using continuous transmission, it will > reduce the bitrate when the characteristics of the input signal > permit, but will never interrupt the transmission to the receiver." > (remove passive voice and the ungrammatical "allows to do so"; also > change "During" to "When using" to clarify that this is a choice) > > "may be set to" -> "can" > > The last paragraph in the section should also remove references to > a DTX "mode", to avoid ambiguity with the speech mode or audio > mode. RFC 6716 is very careful to define a "mode" of operation as > only the choice of SILK or CELT, and refer to other parameter > choices as a "configuration", to avoid making the word "mode" > ambiguous. This document should take the same care. It should also > move the last sentence of this paragraph to the front, so that the > conclusion is last (and replace "adaptive" with "variable" again, > for consistency). Proposed alternative text: > > DTX can be used with both variable and constant bitrate. It will > have a slightly lower speech or audio quality than continuous > transmission. Therefore, using continuous transmission is > RECOMMENDED unless restraints on network capacity are severe. > > 3.3 Forward Error Correction (FEC) > > "allows for "in-band" forward error correction data to be embedded" > -> "allows for embedding "in-band" forward error correction data" > (remove passive voice) > > "the bit stream of Opus" -> "the Opus bit stream" > > "(n-1)" -> "(N-1)" > > "n" -> "N" > > "when, in case of a packet loss, the next packet is available" -> > "when it loses a packet and the next packet is available" (remove > ungrammatical use of "in case of") > > "will consider ... and invokes the frame loss concealment." -> > "will consider ... and invoke frame loss concealment." (avoid tense > change and remove an inappropriate article) > > 3.4 Stereo Operation > > "required" -> "needed" > > "usage of the network" -> "usage of network resources" (for > consistency with the wording in Section 3.3) > > 4.1 RTP Header Usage > > "The Opus payload format uses the fields of the RTP header > consistent with this specification." -> "The use of the fields of > the RTP header by the Opus payload format is consistent with that > specification." (avoid awkward use of the adverb "consistently", > which would be required to make the original sentence correct; also > "this specification" would be the current draft, use "that > specification" to refer to RFC3550) > > "is a multiple number of octets" -> "is an integer number of > octets" > > "required" -> "necessary" > > "duplicates of RTP packets" -> "duplicate RTP packets" > > "Only one of those payloads MUST be provided to the Opus decoder > for decoding and others MUST be discarded." -> "The receiver MUST > provide only one of those payloads to the Opus decoder for > decoding, and MUST discard the others." (remove passive voice, > particularly in a sentence that places normative requirements on an > actor without naming that actor) > > "bandwidths which may" -> "bandwidths, which can" (the clause is > non-restrictive, and non-normative) > > The language in this paragraph should also be made consistent with > the language in Section 6.1 (when describing the rate: parameter). > Proposed text: > > Opus supports 5 different audio bandwidths, which can be adjusted > during a call. The RTP timestamp is incremented with a 48000 Hz > clock rate for all modes of Opus and all sampling rates. The unit > for the timestamp is samples per single (mono) channel. The RTP > timestamp corresponds to the sample time of the first encoded > sample in the encoded frame. For data encoded with sampling rates > other than 48000 Hz, the sampling rate has to be adjusted to 48000 > Hz using the corresponding multiplier in Table 2. > > "fs" -> "Sampling Rate" (fs is not yet a defined term; recommend > "Sampling Rate" for consistency with the text and with Table 1) > > 4.2 Payload Structure > > "can be set to" -> "can" > > "...combined into a packet. The maximum packet length is limited to > the amount of encoded data representing 120 ms of speech or audi > odata." -> "...combined into a packet, up to a maximum packet > duration representing 120 ms of speech or audio data." (keeping > these in the same sentence prevents a reader from stopping at the > end of the first sentence and not realizing the next imposes an > additional restriction; also, replace "length" with the less > ambiguous "duration", to be clear we're not talking about a > restriction on the number of bytes) > > "... encoder and therefore only one packet output from the Opus > encoder MUST be used as a payload" -> "...encoder, and therefore an > RTP payload MUST contain exactly one packet output from the Opus > encoder." (remove passive voice from normative requirements; a > change in subject requires a comma before "and") > > Figure 1 should be centered instead of left-justified. > > "and how" -> "and shows how" (repeat the verb to provide a better > indication what clause the "and" here applies to) > > "the timestamps have to be added up according to the combined > frames" -> "the timestamp increment is the sum of the increments > for the individual frames" (we aren't adding timestamps, and > "according to" is ambiguous) > > nb, mb, etc. in Table 3 should be capitalized. > > 5. Congestion Control > > "The adaptive nature of the Opus codec allows for an efficient > congestion control." -> "" (this is redundant with the sentence > right after it) > > "time and thus" -> "time, thus" > > "allowing for an efficient" -> "allowing efficient" > > "control since" -> "control, since" (unrestrictive clause) > > "these frame sizes" -> "the packet duration" (the previous part of > the sentence talks about a packet, not frames) > > "overhead but" -> "overhead, but" > > "error sensitivity" -> "loss sensitivity" (let's be clear about the > kind of errors we're worried about) > > "sensitivity and should be done" -> "sensitivity, so it ought to > be used" (non-normative should; also, it is not clear how to "do" a > lower packet transmission rate) > > "It is RECOMMENDED that congestion control is applied during the > transmission of Opus encoded data." -> "It is RECOMMENDED that > senders of Opus encoded data apply congestion control." (remove > passive voice from normative requirements) > > 6.1 Opus Media Type Registration > > "RTP timestamp clock rate" -> "the RTP timestamp" (clock rate > appears redundantly elsewhere in the same sentence; missing > article) > > "with 48000 Hz clock rate" -> "with a 48000 Hz clock rate" > (missing article) > > "sampling frequencies" -> "sampling rates" (for consistency with > the rest of the document) > > "For audio sampling rates other than 48000 Hz the rate has to be > adjusted to 48000 Hz according to Table 2." -> "For data encoded > with sampling rates other than 48000 Hz, the sampling rate has to > be adjusted to 48000 Hz using the corresponding multiplier in Table > 2." (for consistency with proposed text in Section 4.1) > > "the decoder's maximum length of time in milliseconds rounded up to > the next full integer value represented by the media in a packet > that can be encapsulated in a received packet according to Section > 6 of RFC4566." > > This is quite the mouthful, and it is quite ambiguous which > clauses refer to which (especially the reference to RFC4566). It is > also phrased as an absolute requirement, when several sentences > later the document clearly states it is not one. How about > > "the maximum duration of media represented by a packet (according > to Section 6 of RFC4566) that a decoder wants to receive, in > milliseconds rounded up to the next full integer value." > > I am inferring here that RFC4566 is being invoked solely to define > the duration of a packet, since the same phrase appears in the > definition of minptime, which is not defined by RFC4566. > > "...40, and 60 or an arbitrary multiple of Opus frame sizes rounded > up to the next full integer value up to a maximum value of 120 as > defined..." -> "...40, 50, or an arbitrary multiple of an Opus > frame size rounded up to the next full integer value, up to a > maximum of 120, as defined..." (both using and omitting a serial > comma in the same sentence; it is unclear what "a" multiple of > several "frame sizes" might be... in practice it must be a multiple > of _one_ frame size, though since all frame sizes are themselves a > multiple of a 2.5 ms frame size, this does not impose any > additional restrictions; also added some missing commas) > > "120 is assumed as default" -> "the default is 120" (no reason not > to be direct) > > The corresponding text for ptime and minptime should be changed in > the same ways. > > "may vary as it" -> "can vary, as it" (non-nomrative may, > non-restrictive clause) > > "allowed but" -> "allowed, but" > > "range between 6000 and 510000" -> "range 6000 to 510000" (I assume > this was meant to be inclusive) > > "maxplaybackrate:" -> "maxplaybackrate" > > "will be the default" -> 'is the default" > > "utilisation" -> "utilization" (for consistency with the American > spelling in the rest of the document) > > "mono is assumed (stereo=0)" -> "the default is 0 (mono)" > > "1 and 0 where" -> "1 and 0, where" > > "preferred and 0 specifies" -> "preferred, and 0 specifies" (comma > for new subject) > > "mono is assumed (sprop-stereo=0)" -> "the default is 0 (mono)" > > "1 and 0 where" -> "1 and 0, where" > > "bitrate and 0 specifies" -> "bitrate, and 0 specifies" (comma for > new subject) > > "cbr is assumed to be 0" -> "the default is 0 (vbr)" > > "Note that the maximum average bitrate may still be changed..." -> > "When cbr is 1, the maximum average bitrate can still change..." > (the phrase "Note that" is always superfluous; this is only > surprising when cbr is enabled, so let's call out that case; also, > remove the non-normative may). > > "It is RECOMMENDED to provide 0 in case FEC cannot be utilized..." > -> "Providing 0 when FEC cannot be used... is RECOMMENDED." (less > awkward phrasing; "used" is always preferable to "utilized") > > "usedtx is assumed to be 0" -> "the default is 0" > > "Opus media type is..." -> "The Opus media type is..." > > "may use this media type" -> "can use this media type" > > 6.2.1 Offer-Answer Model Considerations for Opus > > "is not subject to this payload format description" -> "is not > restricted by this payload format description" (it is unclear what > "subject to" actually means) > > "capable to decode" -> "capable of decoding" > > "dependent on the set values of the parameters the performance of > the application may suffer" -> "some values might cause > application performance to suffer" (non-normative may, indirect > phrasing) > > "and should be set with care" -> "and ought to be used with care" > (non-normative should; subject-verb disagreement) > > "as a function of the bitrates" -> "as a function of the bitrate" > > 6.2.2 Declarative SDP Considerations for Opus > > "should be selected" -> "ought to be selected" (non-normative > should) > > "capable to accept" -> "capable of accepting" > > "may be provided" -> "can be provided" (non-normative may) > > "should be kept small" -> "ought to be kept small" (non-normative > should) > > 7. Security Considerations > > "from e.g., RFC3711" -> "from, e.g., RFC3711" > > "audio data, hence, ..." -> "audio data. Hence, ..." > > I have a few more proposals that do change the meaning of the > text: > > 3.1.2 Variable versus Constant Bitrate > > "the average bitrate SHOULD be adjusted to the available network > capacity" -> "the average bitrate SHOULD NOT exceed the available > network capacity" > > We shouldn't encourage people to fill up the pipe just because > it's available. > > 3.3 Forward Error Correction (FEC) > > This section talks about "the decoder API", which presupposes a > specific implementation of Opus. There's no reason not to be > implementation-independent here. Proposed text: > > "The decoder API function has a flag to indicate that a FEC frame > rather than a regular frame should be decoded." -> "The receiver > can then configure its decoder to decode the FEC data from the > packet rather than the regular audio data." > > 4.2 Payload Structure > > The current encoder API has limited support for creating packets > containing multiple frames, and a separate repacketizer API is > provided to construct such multi-frame packets. The current text > suggests the latter is forbidden, but I don't believe that's the > intent. Proposed text: > > "The packetization of encoded data is purely done by the Opus > encoder, and therefore an RTP payload MUST contain exactly one > packet output from the Opus encoder." -> "The grouping of one or > more Opus frames into a single Opus packet is defined in Section 3 > of RFC6716. An RTP payload MUST contain exactly one Opus packet as > defined by that document." > > 6.2.1 Offer-Answer Model Considerations for Opus > > Based on off-list feedback I got recently, I propose the following > text for maxplaybackrate: > > o The "maxplaybackrate" parameter is a unidirectional > receive-only parameter that reflects limitations of the local > receiver. When sending to a single destination, a sender MUST NOT > use an audio bandwidth higher than necessary to represent audio > sampled at a sampling rate of "maxplaybackrate". Gateways or > senders that are sending the same encoded audio to multiple > destinations SHOULD NOT use an audio bandwidth higher than > necessary to represent audio sampled at "maxplaybackrate", as this > would lead to inefficient use of network resources. The > "maxplaybackrate" parameter does not affect interoperability. > Also, this parameter SHOULD NOT be used to adjust the audio > bandwidth as a function of the bitrate, as this is the > responsibility of the Opus encoder implementation. > > The change from "an audio bandwidth higher than 'maxplaybackrate'" > to "an audio bandwidth higher than necessary to represent audio > sampled at a sampling rate of 'maxplaybackrate'" was done to handle > the fact that maxplaybackrate is a sampling rate, which is > typically at least twice the value of the corresponding audio > bandwidth, and to handle the case where maxplaybackrate does not > correspond exactly to one of the sampling rates supported by Opus > (e.g., fully representing audio sampled at 32 kHz would require > using Opus in a fullband configuration... given typical rate > allocations of the encoder, the waste from using 48 kHz instead of > 32 kHz would only be a handful of bits per frame). > > Similarly, for stereo: > > o The "stereo" parameter is a unidirectional receive-only > parameter. When sending to a single destination, a sender MUST NOT > use stereo when "stereo" is 0. Gateways or senders that are > sending the same encoded audio to multiple destinations SHOULD NOT > use stereo when "stereo" is 0, as this would lead to inefficient > use of network resources. The "stereo" parameter does not affect > interoperability. > > I think this strikes the right balance between giving receivers > the leverage they need to keep senders from wasting their network > resources while allowing gateways to avoid transcoding. If others > have advice to implementers on how to handle multiparty situations > (e.g., a 3-way mesh call where someone joins from the PSTN), feel > free to propose text on the list. > > I've attached git patches for both sets of changes. > > > _______________________________________________ payload mailing > list payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJT2Yh6AAoJEJ6/8sItn9q9NJUIAK6Bi/CyGb07yYcq9rw8jqOW QI5Ve3xHok8y7HqxMvdK9nzamGPHZlqsfoCUqP0xPfUIS/98rUivUyGhpOdKh8+N KVrKWeSn176SVKum6G9RQUZENe+H0t1Ts21vgEw01N/VOAchRHJZNhv+EvCAjhc0 d61zOJJR7cV3s+Zk+DrLTSJvsqA2YW/ArqPcntLe14AEOtcfXlNJgRW0dQncLhs2 Dw+PVpPt4aKk2UW+ydeGqzWpUZ0zoUbL/Bc57SAp3B9Njv22FGJgNTsmhakMjzRn hGoGOmVjuO2YDkWdGUMFUO78H6QuO4ndlHo3B7fObUvNalNKQQWBGpxT0x5mPJQ= =34Ih -----END PGP SIGNATURE-----