From prvs=1834f706c7=magnus.westerlund@ericsson.com Thu May 2 07:29:32 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0769D21F8525 for ; Thu, 2 May 2013 07:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.816 X-Spam-Level: X-Spam-Status: No, score=-104.816 tagged_above=-999 required=5 tests=[AWL=1.433, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkQcLuBoFZCA for ; Thu, 2 May 2013 07:29:27 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 79AE721F86F4 for ; Thu, 2 May 2013 07:29:23 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-d8-51827842532c Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 5A.DF.01956.24872815; Thu, 2 May 2013 16:29:22 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Thu, 2 May 2013 16:29:21 +0200 Message-ID: <51827840.9090201@ericsson.com> Date: Thu, 2 May 2013 16:29:20 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: payload@ietf.org References: <20130412133336.27848.48350.idtracker@ietfa.amsl.com> <51680E0E.3070002@ericsson.com> In-Reply-To: <51680E0E.3070002@ericsson.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHJMWRmVeSWpSXmKPExsUyM+Jvra5TRVOgwaKLYhaXLp5lcmD0WLLk J1MAYxS3TVJiSVlwZnqevl0Cd8bX48IFd0QrDq/8yNLAuFKwi5GTQ0LAROLTnGPMELaYxIV7 69lAbCGBU4wS088HdjFyAdnLGCV6Lp5kAknwCmhLrDq5ihXEZhFQkbh/qgXMZhOwkLj5oxGo mYNDVCBYYmtrDES5oMTJmU9YQGwRARGJRXcng9nCAm4SR3+sY4TYlSjRsOI42F5OAR2J7f0f 2SDukZTY8qKdHcRmFtCTmHK1hRHClpdo3jqbGaJXW6KhqYN1AqPgLCTrZiFpmYWkZQEj8ypG 9tzEzJz0cvNNjMDgO7jlt8EOxk33xQ4xSnOwKInzJnM1BgoJpCeWpGanphakFsUXleakFh9i ZOLgBBFcUg2MSzfH8nz4p5gkfuVa5eKZitOnPcrvrbLh3nTshPaMRqbU9+fqhH9zJZ9/ymq4 MLvR+KGi/Y5PNvG/3mZUOXAmtS5dJf/Y+mJqyrLsFeYBf2++9Kuobe5xd2mOn3jTbu2mqxUP nsvGr0p84v9kx/L0fWE+oU7ic4okv5f/8JvcvDAg2fTu9JvZSizFGYmGWsxFxYkA6RRR1hEC AAA= Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-howto-03.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 14:29:32 -0000 WG, I would appreciate a review. /Magnus On 2013-04-12 15:37, Magnus Westerlund wrote: > WG, > > Sorry for being tardy in updating this document. I have finally done a > rewrite of the text on security consideration, especially the template > text. I now intended to request review of this from the sec-dir and SEC > ADs if they think this works. > > I have also done a complete review and taken care of any detected > published documents, concluded WG and other things that has changed > since last years submission. > > If the security considerations are okay I do think this document is > ready for publications. I would really appreciate if some could take the > time to review it and see if they agree that it is ready for WG last call. > > Cheers > > Magnus Westerlund > > On 2013-04-12 15:33, internet-drafts@ietf.org wrote: >> >> 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 : How to Write an RTP Payload Format >> Author(s) : Magnus Westerlund >> Filename : draft-ietf-payload-rtp-howto-03.txt >> Pages : 51 >> Date : 2013-04-12 >> >> Abstract: >> This document contains information on how to best write an RTP >> payload format. It provides reading tips, design practices, and >> practical tips on how to produce an RTP payload format specification >> quickly and with good results. A template is also included with >> instructions that can be used when writing an RTP payload format. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-payload-rtp-howto-03 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-howto-03 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >> >> > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From fluffy@cisco.com Fri May 10 14:19:25 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDAFC21F90BB; Fri, 10 May 2013 14:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSXRDTi15JvM; Fri, 10 May 2013 14:19:20 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 22C7D21F9012; Fri, 10 May 2013 14:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=583; q=dns/txt; s=iport; t=1368220760; x=1369430360; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kb+Rn7mtlFkEyhGGIoDTacP4zwoKlRLU4Si8UyXe1RE=; b=arlXtkXTXDBOFkendgWeq/v1lWxkQbRcardSPean1Q7MFxhDwjXSFRlU PSUVe4QoMWfc0C0kLDJUBqcbP/1lBWSayDyua79m+8hyPwexojLASybLM FseXNgFsitODc9ESb+UsZjDOSAwQE65PFUvOh5KLNe9fRlfFtY3OGgg9W Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFADhjjVGtJV2Y/2dsb2JhbABSgwfAVnwWdIIfAQEBAwE6PwULAgEIIhQQMiUCBA4Nh34GvUOOdQIxB4J0YQOoYYMPgic X-IronPort-AV: E=Sophos;i="4.87,651,1363132800"; d="scan'208";a="208990655" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 10 May 2013 21:19:15 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4ALJFpA027334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 May 2013 21:19:15 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Fri, 10 May 2013 16:19:15 -0500 From: "Cullen Jennings (fluffy)" To: "Dale R. Worley" Thread-Topic: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? Thread-Index: AQHOTcQG0FWtFMhXHUOIqYR0Ncup8g== Date: Fri, 10 May 2013 21:19:15 +0000 Message-ID: References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> <517A23B4.3060801@ericsson.com> <201304261820.r3QIKq913501941@shell01.TheWorld.com> In-Reply-To: <201304261820.r3QIKq913501941@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="us-ascii" Content-ID: <3D957E974AB28D4097794FEE7879B157@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmusic@ietf.org" , "payload@ietf.org" Subject: Re: [payload] [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 21:19:25 -0000 >=20 64-65 have been obsolete and given the lack of H.261 being used in deployme= nts I think it is safe if they are in the secondary pool.=20 I think they would be better to ref=20 65 [RFC2032] 66 [RFC5484] For the rest, I think it should be more like=20 65 [RFC2032] 66 [RFC5484] 67 [RFC5450] 72 [RFC3550] 73 [RFC3550] 74 [RFC3550] 75 [RFC3550] 76 [RFC3550] 77 [RFC4585] 78 [RFC4585] 79 [RFC3611] 80 IEEE Std 1733TM-2011 Given how the next two are used, bit hard to decide what the impact is whe= n doing O/A=20 81 [RFC5760]=20 82 [RFC6284] From magnus.westerlund@ericsson.com Mon May 13 01:03:14 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E6721F9195; Mon, 13 May 2013 01:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.784 X-Spam-Level: X-Spam-Status: No, score=-100.784 tagged_above=-999 required=5 tests=[AWL=5.466, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmp+bwnJXxYT; Mon, 13 May 2013 01:03:08 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 47EA521F8D84; Mon, 13 May 2013 01:03:05 -0700 (PDT) X-AuditID: c1b4fb25-b7f396d000007d06-0d-51909e380163 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 52.76.32006.83E90915; Mon, 13 May 2013 10:03:04 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Mon, 13 May 2013 10:03:04 +0200 Message-ID: <51909E36.9050407@ericsson.com> Date: Mon, 13 May 2013 10:03:02 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Dale R. Worley" References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> <517A23B4.3060801@ericsson.com> <201304261820.r3QIKq913501941@shell01.TheWorld.com> In-Reply-To: <201304261820.r3QIKq913501941@shell01.TheWorld.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+Jvra7FvAmBBv2bxS2mLn/MYnHp4lkm i5cnyhyYPSbv/8rssWTJT6YApigum5TUnMyy1CJ9uwSujIuznrAVXJGp2L3hMUsD4zSxLkZO DgkBE4ntt16wQNhiEhfurWfrYuTiEBI4xShxdNdyZghnOaPE9507WbsYOTh4BbQlutcIgDSw CKhKXF81DayZTcBC4uaPRjaQElGBYImtrTEgYV4BQYmTM5+wgIRFBDQlOhbkgISZgTq/vn/I DhIWFvCV2PxVDiQsJPCZUeLNBwOQMKeAg8Tz7wEQh0lKbHnRzg7RqScx5WoLI4QtL9G8dTYz RKu2RENTB+sERqFZSPbOQtIyC0nLAkbmVYzsuYmZOenlRpsYgaF6cMtv1R2Md86JHGKU5mBR EudN5moMFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cAYefgQw/uN3U7bnnnEi3W7XngsJTb5 zxKfJdYWW3fM//ku+Ynlrk0RgXz5ulOvVwTkCos6GgpMbnPpW9q051DkugDmE/wnb7C81Lqw 9vvN2qtxu3j2/jY2+b6SPztn37K8zwHfNjzL/jwh8P5H22039smU+D/8eLw1ucB51YJgIUOD J7vKi7/8UmIpzkg01GIuKk4EAD41rMMjAgAA Cc: mmusic@ietf.org, payload@ietf.org Subject: Re: [payload] [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 08:03:14 -0000 Dale, Ok, I think you have convinced me that there is a point in updating or at least clarifying the registry. However, I think it is important that one makes clear the difference between using RTP/RTCP MUX and not. The considerations for doing static allocations which was this registries original purpose and the the usage of dynamic PT assignments with and without RTP/RTCP MUX is quite different. >From my perspective I don't see major issues to use all 128 values of PT field if needed when doing dynamic allocation and not using RTP/RTCP MUX. Yes, I would use the one that collide with SR/RR RTCP packets last, but I still would use them. The thing that is getting screwed up are classifier filters, not the actual end-points. Clearly if using RTP/RTCP MUX you need to avoid the PT values corresponding to RTCP packets types in use. Especially if reduced size RTCP is used. I also think you should check with IANA if one can touch a closed registry at all, or if we are restricted to clarifying notes for the registry. Cheers Magnus On 2013-04-26 20:20, Dale R. Worley wrote: >> From: Magnus Westerlund >> >> Regarding the IANA, Mo you have correctly identified the registry as >> closed and Adam pointed to the relevant text. Is this level of >> indirection so problematic that this registry needs a Note to the effect? > > (cleaning up my proposal) > > I use the IANA registries as the reference for how the various number > spaces are managed. The current final rows of the Payload Types table > read: > > 35-71 Unassigned > 72-76 Reserved for RTCP conflict avoidance [RFC3551] > 77-95 Unassigned > 96-127 dynamic [RFC3551] > > I find these to be problematic in several ways: > > 1) RFC 5761 is not mentioned at all, despite that it provides > important modifications of the governing text in RFC 3551. This is a > practical problem: Note that Adam quoted the text in RFC 3551, not > the text in RFC 5761, and the 3551 text is now incorrect. > > 2) The range that is reserved for RTCP avoidance is not specified > correctly. It's true that the rest of the RTCP avoidance range is > marked "Unassigned", but in the context of RFC 3551, that suggests > that they can be used as a secondary dynamic assignment area. > > 3) The range 35-71 should be marked more clearly as the secondary > dynamic assignment area. > > Because of this, I suggest the following changes to this registry: > > 1) The "Reference" section should be changed from "[RFC3551]" to > "[RFC5761][RFC3551]". > > 2) The final rows should be changed to > > 35-63 Unassigned/secondary dynamic area [RFC5761] > 64-71 Reserved for RTCP conflict avoidance [RFC5761] > 72-76 Reserved for RTCP conflict avoidance [RFC3551] > 77-95 Reserved for RTCP conflict avoidance [RFC5761] > 96-127 Dynamic [RFC3551] > > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ron.even.tlv@gmail.com Mon May 13 01:46:48 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92CB621F92F4; Mon, 13 May 2013 01:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.567 X-Spam-Level: * X-Spam-Status: No, score=1.567 tagged_above=-999 required=5 tests=[AWL=4.166, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oilvrP2zspXG; Mon, 13 May 2013 01:46:48 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6979321F9347; Mon, 13 May 2013 01:46:47 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id ey16so655943wid.5 for ; Mon, 13 May 2013 01:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=iXKwtxnTPiI2xxXBpSymcVg5qcSq7NWo+elt09Koacs=; b=QczqhHcknho4ql9YvyzBr6JMUn8ohLVtVg3JRnUEd4FWeEheILfcG9UEzCXGafSbWr 9Jt1i1+hh9WVznXmQBRhBv5V5BC65x9f25QffOw/wy808wNZMA9EgRrXDq2t6FmdStAC e8n+UM4GZdnQnFfUxxAUEZcV2fI34Thtog8K3hLy/O8W7gkG9exs6W3dPk5ibiKAMLvN uDXariX/Xr7bnnK4kZk6SjNTPMClEJ71m9nf8WJobCngyrkdxWoN5H1Ws6tUiuHb9izd on2Tlq4ZOpqSaUQGkTew6RGaPmlqOrwAAQKSehIgL73dNbvjfTY28IFafTrA7fci9VbV iDhQ== X-Received: by 10.180.90.70 with SMTP id bu6mr17072329wib.34.1368434806557; Mon, 13 May 2013 01:46:46 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPSA id ay7sm6551238wib.9.2013.05.13.01.46.44 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 May 2013 01:46:45 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" , "'Dale R. Worley'" References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> <517A23B4.3060801@ericsson.com> <201304261820.r3QIKq913501941@shell01.TheWorld.com> <51909E36.9050407@ericsson.com> In-Reply-To: <51909E36.9050407@ericsson.com> Date: Mon, 13 May 2013 11:45:51 +0300 Message-ID: <008d01ce4fb6$47860250$d69206f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHhSi4rMF59GtWVZLm6eUv/wmHmTAG3YjvyAXHa8loCRvWqfgHvq+67AYZd+3eYlaWWgA== Content-Language: en-us Cc: mmusic@ietf.org, payload@ietf.org Subject: Re: [payload] [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 08:46:48 -0000 Hi, I am also concerned about putting in the registries the different case = where RTCP mux is used or not. I think the best we can do is add a general = note in the registry point at RFC5761 saying that it provides clarification on = using the pt type numbers in different cases. Roni -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf = Of Magnus Westerlund Sent: 13 May, 2013 11:03 AM To: Dale R. Worley Cc: mmusic@ietf.org; payload@ietf.org Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? Dale, Ok, I think you have convinced me that there is a point in updating or = at least clarifying the registry. However, I think it is important that one makes clear the difference between using RTP/RTCP MUX and not. The considerations for doing static allocations which was this registries original purpose and the the usage of dynamic PT assignments with and without RTP/RTCP MUX is quite different. >From my perspective I don't see major issues to use all 128 values of PT field if needed when doing dynamic allocation and not using RTP/RTCP = MUX. Yes, I would use the one that collide with SR/RR RTCP packets last, but = I still would use them. The thing that is getting screwed up are = classifier filters, not the actual end-points. Clearly if using RTP/RTCP MUX you need to avoid the PT values = corresponding to RTCP packets types in use. Especially if reduced size RTCP is used. I also think you should check with IANA if one can touch a closed = registry at all, or if we are restricted to clarifying notes for the registry. Cheers Magnus On 2013-04-26 20:20, Dale R. Worley wrote: >> From: Magnus Westerlund >> >> Regarding the IANA, Mo you have correctly identified the registry as=20 >> closed and Adam pointed to the relevant text. Is this level of=20 >> indirection so problematic that this registry needs a Note to the = effect? >=20 > (cleaning up my proposal) >=20 > I use the IANA registries as the reference for how the various number=20 > spaces are managed. The current final rows of the Payload Types table > read: >=20 > 35-71 Unassigned > 72-76 Reserved for RTCP conflict avoidance [RFC3551] > 77-95 Unassigned > 96-127 dynamic [RFC3551] >=20 > I find these to be problematic in several ways: >=20 > 1) RFC 5761 is not mentioned at all, despite that it provides=20 > important modifications of the governing text in RFC 3551. This is a=20 > practical problem: Note that Adam quoted the text in RFC 3551, not=20 > the text in RFC 5761, and the 3551 text is now incorrect. >=20 > 2) The range that is reserved for RTCP avoidance is not specified=20 > correctly. It's true that the rest of the RTCP avoidance range is=20 > marked "Unassigned", but in the context of RFC 3551, that suggests=20 > that they can be used as a secondary dynamic assignment area. >=20 > 3) The range 35-71 should be marked more clearly as the secondary=20 > dynamic assignment area. >=20 > Because of this, I suggest the following changes to this registry: >=20 > 1) The "Reference" section should be changed from "[RFC3551]" to=20 > "[RFC5761][RFC3551]". >=20 > 2) The final rows should be changed to >=20 > 35-63 Unassigned/secondary dynamic area [RFC5761] > 64-71 Reserved for RTCP conflict avoidance [RFC5761] > 72-76 Reserved for RTCP conflict avoidance [RFC3551] > 77-95 Reserved for RTCP conflict avoidance [RFC5761] > 96-127 Dynamic [RFC3551] >=20 > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >=20 >=20 --=20 Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ mmusic mailing list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic From keith.drage@alcatel-lucent.com Thu May 16 10:54:32 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D6011E8142; Thu, 16 May 2013 10:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWy2ovAUanVv; Thu, 16 May 2013 10:54:22 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2D311E8126; Thu, 16 May 2013 10:54:21 -0700 (PDT) Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r4GHs7pR024308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 16 May 2013 12:54:08 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id r4GHs6gN032140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 May 2013 13:54:06 -0400 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 16 May 2013 13:54:06 -0400 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 16 May 2013 19:54:03 +0200 From: "DRAGE, Keith (Keith)" To: "Dale R. Worley" , Roni Even Thread-Topic: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? Thread-Index: AQHOUkzLLsu164tLIUibgvMxBULeBZkIFknQ Date: Thu, 16 May 2013 17:54:03 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B03B590@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> <517A23B4.3060801@ericsson.com> <201304261820.r3QIKq913501941@shell01.TheWorld.com> <51909E36.9050407@ericsson.com> <008d01ce4fb6$47860250$d69206f0$@gmail.com> <201305161547.r4GFlckY4863857@shell01.TheWorld.com> In-Reply-To: <201305161547.r4GFlckY4863857@shell01.TheWorld.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "mmusic@ietf.org" , "payload@ietf.org" Subject: Re: [payload] [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 17:54:32 -0000 The registry is not there to show how values are used. It should concentrate on two issues: - Making sure the value is reserved so that it can not be reused for someth= ing else - Identifying where the user should go to find further information about th= at value. Anything else should be in the RFCs. If there is lack of clarity as a resul= t, that means spinning a new version of the RFC or filing a fix. We cannot fix lack of clarity in the RFCs by playing with the IANA tables. Regards Keith > -----Original Message----- > From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf > Of Dale R. Worley > Sent: 16 May 2013 16:48 > To: Roni Even > Cc: magnus.westerlund@ericsson.com; mmusic@ietf.org; payload@ietf.org > Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC > 5761? >=20 > > From: "Roni Even" > > > > I am also concerned about putting in the registries the different case > where > > RTCP mux is used or not. I think the best we can do is add a general > note in > > the registry point at RFC5761 saying that it provides clarification on > using > > the pt type numbers in different cases. >=20 > I do not believe that the registry table format allows us to express > well the difference between the RTCP-mux case and the non-RTCP-mux > case. I believe that we should add RFC 5761 as the *primary* > reference for this registry. As a conservative choice, the PTs 64-95 > can be marked as "reserved"; the careful reader of RFC 5761 can tell > that in the non-RTCP-mux case, there is no danger that the endpoints > will confuse those PTs with RTCP packets. >=20 > Dale > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From worley@shell01.TheWorld.com Thu May 16 08:48:09 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B414E21F8F6E for ; Thu, 16 May 2013 08:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTvS3veBVIQE for ; Thu, 16 May 2013 08:48:04 -0700 (PDT) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id BBE2021F91F1 for ; Thu, 16 May 2013 08:48:01 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r4GFlcJO013205; Thu, 16 May 2013 11:47:41 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r4GFlcGn4864532; Thu, 16 May 2013 11:47:38 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r4GFlckY4863857; Thu, 16 May 2013 11:47:38 -0400 (EDT) Date: Thu, 16 May 2013 11:47:38 -0400 (EDT) Message-Id: <201305161547.r4GFlckY4863857@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "Roni Even" In-reply-to: <008d01ce4fb6$47860250$d69206f0$@gmail.com> (ron.even.tlv@gmail.com) References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> <517A23B4.3060801@ericsson.com> <201304261820.r3QIKq913501941@shell01.TheWorld.com> <51909E36.9050407@ericsson.com> <008d01ce4fb6$47860250$d69206f0$@gmail.com> X-Mailman-Approved-At: Thu, 16 May 2013 13:59:08 -0700 Cc: mmusic@ietf.org, payload@ietf.org Subject: Re: [payload] [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 15:48:09 -0000 > From: "Roni Even" > > I am also concerned about putting in the registries the different case where > RTCP mux is used or not. I think the best we can do is add a general note in > the registry point at RFC5761 saying that it provides clarification on using > the pt type numbers in different cases. I do not believe that the registry table format allows us to express well the difference between the RTCP-mux case and the non-RTCP-mux case. I believe that we should add RFC 5761 as the *primary* reference for this registry. As a conservative choice, the PTs 64-95 can be marked as "reserved"; the careful reader of RFC 5761 can tell that in the non-RTCP-mux case, there is no danger that the endpoints will confuse those PTs with RTCP packets. Dale From worley@shell01.TheWorld.com Thu May 16 08:48:15 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA8911E80FC for ; Thu, 16 May 2013 08:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icUuewWJgecz for ; Thu, 16 May 2013 08:48:09 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 5038C21F9381 for ; Thu, 16 May 2013 08:48:02 -0700 (PDT) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r4GFltNm024996; Thu, 16 May 2013 11:47:57 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r4GFltmn4876171; Thu, 16 May 2013 11:47:55 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r4GFlt3X4878967; Thu, 16 May 2013 11:47:55 -0400 (EDT) Date: Thu, 16 May 2013 11:47:55 -0400 (EDT) Message-Id: <201305161547.r4GFlt3X4878967@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Magnus Westerlund In-reply-to: <51909E36.9050407@ericsson.com> (magnus.westerlund@ericsson.com) References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> <517A23B4.3060801@ericsson.com> <201304261820.r3QIKq913501941@shell01.TheWorld.com> <51909E36.9050407@ericsson.com> X-Mailman-Approved-At: Thu, 16 May 2013 13:59:08 -0700 Cc: mmusic@ietf.org, payload@ietf.org Subject: Re: [payload] [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 15:48:15 -0000 > From: Magnus Westerlund > > Ok, I think you have convinced me that there is a point in updating or > at least clarifying the registry. Very good. > From my perspective I don't see major issues to use all 128 values of PT > field if needed when doing dynamic allocation and not using RTP/RTCP > MUX. Yes, I would use the one that collide with SR/RR RTCP packets last, > but I still would use them. The thing that is getting screwed up are > classifier filters, not the actual end-points. This is true. But it is difficult to express this fact in the table format of a registry. My preference is to provide RFC 5761 as the primary reference for the registry and to mark conservatively PTs 64 to 95 as "reserved". The careful reader of RFC 5761 can determine that in the non-RTCP-mux case that the endpoint will not confuse the endpoints, but that it may confuse network diagnostic elements. > I also think you should check with IANA if one can touch a closed > registry at all, or if we are restricted to clarifying notes for the > registry. I have sent an inquiry to Gonzalo about this point. Dale From worley@shell01.TheWorld.com Thu May 16 08:48:21 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBFB21F872E for ; Thu, 16 May 2013 08:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Er9tgUZ17wI for ; Thu, 16 May 2013 08:48:15 -0700 (PDT) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id EA18421F92EB for ; Thu, 16 May 2013 08:48:06 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r4GFlLbl001790; Thu, 16 May 2013 11:47:23 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r4GFlKZL4878276; Thu, 16 May 2013 11:47:21 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r4GFlKwa4878884; Thu, 16 May 2013 11:47:20 -0400 (EDT) Date: Thu, 16 May 2013 11:47:20 -0400 (EDT) Message-Id: <201305161547.r4GFlKwa4878884@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "Cullen Jennings (fluffy)" In-reply-to: (fluffy@cisco.com) References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> <517A23B4.3060801@ericsson.com> <201304261820.r3QIKq913501941@shell01.TheWorld.com> X-Mailman-Approved-At: Thu, 16 May 2013 13:59:08 -0700 Cc: mmusic@ietf.org, payload@ietf.org Subject: Re: [payload] [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 15:48:21 -0000 I want to confirm that I understand you here: I believe that you are giving the references for the various RTCP packet types that could potentially collide with the numbers given as RTP payload type. E.g., RTP PT 65 could be mistaken for RTCP packet type 65 + 128 = 193. And RTCP 193 is marked in the "RTCP Control Packet types (PT)" registry with reference RFC 2032. So I believe that the information in the table you've written below is captured in "RTCP Control Packet types (PT)" (http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xml#rtp-parameters-3). Dale > From: "Cullen Jennings (fluffy)" > CC: Magnus Westerlund , > "mmusic@ietf.org" > , > "payload@ietf.org" > Date: Fri, 10 May 2013 21:19:15 +0000 > Accept-Language: en-US > > > > 64-65 have been obsolete and given the lack of H.261 being used in deployments I think it is safe if they are in the secondary pool. > > I think they would be better to ref > > 65 [RFC2032] > 66 [RFC5484] > > For the rest, I think it should be more like > > 65 [RFC2032] > 66 [RFC5484] > 67 [RFC5450] > > 72 [RFC3550] > 73 [RFC3550] > 74 [RFC3550] > 75 [RFC3550] > 76 [RFC3550] > > 77 [RFC4585] > 78 [RFC4585] > > 79 [RFC3611] > 80 IEEE Std 1733TM-2011 > > Given how the next two are used, bit hard to decide what the impact is when doing O/A > 81 [RFC5760] > 82 [RFC6284] From adam@nostrum.com Thu May 16 10:23:31 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247EE21F882A; Thu, 16 May 2013 10:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wX3OtTA-l6D; Thu, 16 May 2013 10:23:30 -0700 (PDT) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7200D21F8605; Thu, 16 May 2013 10:23:30 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r4GHNIwd070721 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 16 May 2013 12:23:18 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <51951605.6030602@nostrum.com> Date: Thu, 16 May 2013 12:23:17 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Dale R. Worley" References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> <517A23B4.3060801@ericsson.com> <201304261820.r3QIKq913501941@shell01.TheWorld.com> <51909E36.9050407@ericsson.com> <201305161547.r4GFlt3X4878967@shell01.TheWorld.com> In-Reply-To: <201305161547.r4GFlt3X4878967@shell01.TheWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Thu, 16 May 2013 13:59:08 -0700 Cc: mmusic@ietf.org, payload@ietf.org Subject: Re: [payload] [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 17:23:31 -0000 On 5/16/13 10:47, Dale R. Worley wrote: > My preference is to provide RFC 5761 as the primary reference for the > registry and to mark conservatively PTs 64 to 95 as "reserved". The > careful reader of RFC 5761 can determine that in the non-RTCP-mux case > that the endpoint will not confuse the endpoints, but that it may > confuse network diagnostic elements. It can also frustrate attempts to gateway between a system that does multiplexing and one that does not. I think we should treat them as off-limits for all uses, regardless of whether we're multiplexing RTCP over the same channel. /a From gonzalo.camarillo@ericsson.com Mon May 20 23:23:41 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81F621F972D for ; Mon, 20 May 2013 23:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.211 X-Spam-Level: X-Spam-Status: No, score=-106.211 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTSj-+GGvnHA for ; Mon, 20 May 2013 23:23:33 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 671F221F90D2 for ; Mon, 20 May 2013 23:23:23 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-90-519b12d9a24f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 10.0F.28930.9D21B915; Tue, 21 May 2013 08:23:21 +0200 (CEST) Received: from [131.160.126.9] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Tue, 21 May 2013 08:23:21 +0200 Message-ID: <519B12D8.1080404@ericsson.com> Date: Tue, 21 May 2013 09:23:20 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> <517A23B4.3060801@ericsson.com> <201304261820.r3QIKq913501941@shell01.TheWorld.com> <51909E36.9050407@ericsson.com> <008d01ce4fb6$47860250$d69206f0$@gmail.com> <201305161547.r4GFlckY4863857@shell01.TheWorld.com> <949EF20990823C4C85C18D59AA11AD8B03B590@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B03B590@FR712WXCHMBA11.zeu.alcatel-lucent.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUyM+Jvre5NodmBBhdv2Vg8bTzLaHHp4lkm i7/tzBYvT5Q5sHi0PtvL6jF5/1dmj52z7rJ7LFnykymAJYrLJiU1J7MstUjfLoErY/rJZ4wF X0Qqeh/uZWlgfCXQxcjJISFgIvF42Xw2CFtM4sK99UA2F4eQwClGiasnXrFAOKsZJTZf+gdW xSugLfF5zy0mEJtFQFVi5aZ3rCA2m4CFxJZb91lAbFGBKIk56x5A1QtKnJz5BCwuImAt8erx FqA4BwezQKXE5gOpIGFhgUiJSU3nmSF2HWKWuN/5jhEkwSkQLbG/7TUjxHWSEltetLOD2MwC ehJTrrYwQtjyEtvfzmEGsYWAblv+rIVlAqPQLCSrZyFpmYWkZQEj8ypG9tzEzJz0csNNjMCA Prjlt+4OxlPnRA4xSnOwKInz9mpPDRQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAWG9l8nR2 /Zf94X9M3rn+ep5rn3+p9OqVa5NO2BtFGy717VI+aOPu6JT9OX5D3IJXf2U+TBX6UprA8i07 YQ/vO5EExzxdNVOjyO2mKqp6EUafZa30l/Z8XS5ps2/KxqYJC29sNKnu6Fnf/HvVaueWjcf2 N+b67dk1TWGewUb7h2tkn78N8k/zVWIpzkg01GIuKk4EACBNgeQ2AgAA Cc: "Dale R. Worley" , "payload@ietf.org" Subject: Re: [payload] [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 06:23:42 -0000 Hi, [removing the MMUSIC list from the cc: to avoid cross-posting] this seems to be the last email on this thread. Keith makes a good point here. IANA registries are not supposed to replace RFCs. RFCs are the actual specifications; IANA registries serve a different purpose. So, adding a note to a registry or clarifying any potentially confusing aspects of that registry is something we should do. However, we should not try and overload this particular registry with too much info. Keeping this in mind, please discuss the best way to address this issue. Thanks, Gonzalo On 16/05/2013 8:54 PM, DRAGE, Keith (Keith) wrote: > The registry is not there to show how values are used. > > It should concentrate on two issues: > > - Making sure the value is reserved so that it can not be reused for something else > - Identifying where the user should go to find further information about that value. > > Anything else should be in the RFCs. If there is lack of clarity as a result, that means spinning a new version of the RFC or filing a fix. > > We cannot fix lack of clarity in the RFCs by playing with the IANA tables. > > Regards > > Keith > >> -----Original Message----- >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >> Of Dale R. Worley >> Sent: 16 May 2013 16:48 >> To: Roni Even >> Cc: magnus.westerlund@ericsson.com; mmusic@ietf.org; payload@ietf.org >> Subject: Re: [MMUSIC] Should we update the IANA registry to reflect RFC >> 5761? >> >>> From: "Roni Even" >>> >>> I am also concerned about putting in the registries the different case >> where >>> RTCP mux is used or not. I think the best we can do is add a general >> note in >>> the registry point at RFC5761 saying that it provides clarification on >> using >>> the pt type numbers in different cases. >> >> I do not believe that the registry table format allows us to express >> well the difference between the RTCP-mux case and the non-RTCP-mux >> case. I believe that we should add RFC 5761 as the *primary* >> reference for this registry. As a conservative choice, the PTs 64-95 >> can be marked as "reserved"; the careful reader of RFC 5761 can tell >> that in the non-RTCP-mux case, there is no danger that the endpoints >> will confuse those PTs with RTCP packets. >> >> Dale >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > From fluffy@cisco.com Tue May 21 07:51:15 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7B821F96D6; Tue, 21 May 2013 07:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.569 X-Spam-Level: X-Spam-Status: No, score=-110.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOBrrzj4e08s; Tue, 21 May 2013 07:50:57 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BD3A821F9500; Tue, 21 May 2013 07:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=790; q=dns/txt; s=iport; t=1369147857; x=1370357457; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2n9lovN1A306ExwrBoORhkj4Yj1upVAZ5i0Fji6oqR4=; b=hNyJb66F6w9joIMYzIH9UvW54r6GY4mYxGvLOzKXMgw531V/JScSgXAz SW0Yri7l49F9bOCqTHHWX2t09tfI8f7QLbekcCiuFrP6+ER3Z0pHBfzlW gILRJ2pAVlFdeEvN6YmnO1DGbavtrgcokhKOCUcBytfUox/aFt9Rz7q4q M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHOJm1GtJXG//2dsb2JhbABZgwjBf4EJFnSCIwEBAQMBeQULAgEIIiQyJQIEDgUIEYduBrtbjmcCMQeCc2EDiGegEYMPgiY X-IronPort-AV: E=Sophos;i="4.87,714,1363132800"; d="scan'208";a="213134923" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 21 May 2013 14:50:44 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4LEoiCN003811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 May 2013 14:50:44 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 21 May 2013 09:50:44 -0500 From: "Cullen Jennings (fluffy)" To: "mmusic@ietf.org WG" Thread-Topic: [MMUSIC] Should we update the IANA registry to reflect RFC 5761? Thread-Index: AQHOVjKRuwJMNkuCLEGo8RXp25VaDA== Date: Tue, 21 May 2013 14:50:30 +0000 Message-ID: References: <201304251725.r3PHPqeV3429515@shell01.TheWorld.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DC561@xmb-rcd-x14.cisco.com> <51798419.7070103@nostrum.com> <517A23B4.3060801@ericsson.com> <201304261820.r3QIKq913501941@shell01.TheWorld.com> <51909E36.9050407@ericsson.com> In-Reply-To: <51909E36.9050407@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Dale R. Worley" , "payload@ietf.org" Subject: Re: [payload] [MMUSIC] Should we update the IANA registry to reflect RFC 5761? X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 14:51:15 -0000 On May 13, 2013, at 2:03 AM, Magnus Westerlund wrote: > I also think you should check with IANA if one can touch a closed > registry at all, or if we are restricted to clarifying notes for the > registry. If we have consensus for the change and IESG approval, I think we can do wh= atever we want to the IANA registries. If we want a totally different forma= t for the registry, we can do that - we just need a draft that updates the = previous RFC that defined the registries.=20 However, I agree with Keith the registry is for code point allocation, not = explaining life to implementors. If we need an information RFC to summarize= and explain all the info to implementors, that would be easy to publish if= someone wrote it.=20 From patrik.westin@gmail.com Tue May 21 08:22:59 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BC121F97B9 for ; Tue, 21 May 2013 08:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEDwGZIF-zXh for ; Tue, 21 May 2013 08:22:59 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D1BE221F9793 for ; Tue, 21 May 2013 08:22:58 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k5so1984885iea.18 for ; Tue, 21 May 2013 08:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=FKRshp0m37Xw7ZW++toMmVRl7Iqf2/7MoGHg9D516mc=; b=r3pEYVmTUS4ku39lF+mjlMfE55lB3keCcFaXfR9byUWYteve4MRRbTR+ayqh+llfCd pTY9/2rGUZVYVi6JqbS20d9/rvxVRNWuxq2iSpCxcvoTpIynJ7aUAbXiROmQMB8aEKfJ BwDEbvVeZdKXypo+C0mMRFXJvjdo9N+4hkAgvvSCgm8ouB49esD+pViNgUBeZaFkYRis 4pyuylMhLxY3/aKkgcM2i8cr6GoY9WXffgRtCit3I4A2F4fxvcxnBIVjSOZHcGuMStBx l9xLLi1Y9tKPdpR31Klx06BrxgZvUHNm3gU822OWD/Ne/PmwGsrn4K4rE2NOy28b5gMo sKww== X-Received: by 10.50.23.41 with SMTP id j9mr1729813igf.59.1369149778427; Tue, 21 May 2013 08:22:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.46.78 with HTTP; Tue, 21 May 2013 08:22:38 -0700 (PDT) From: Patrik Westin Date: Tue, 21 May 2013 08:22:38 -0700 Message-ID: To: "payload@ietf.org" Content-Type: multipart/alternative; boundary=089e0153666a30082004dd3c06b5 Subject: Re: [payload] AD review of draft-ietf-payload-vp8-08 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 15:22:59 -0000 --089e0153666a30082004dd3c06b5 Content-Type: text/plain; charset=ISO-8859-1 This is how I think about it 1. Collect all packets with a given RTP timestamp 2. Go through packets in order, sorted by sequence numbers, if packets are missing, send NACK or decode with missing partitions, see 4.x below. 3. Complete frame is detected by no missing sequence numbers and first packet in the frame containing S=1 with partId=0 and the last packet in the frame having the marker bit set. 4.1 scan for the start of a new partition; S=1 4.2 continue scan to detect end of partition; hence a new S=1 (previous packet was the end of the partition) is found or the marker bit is set, if a loss it detected before the end of the partition abandon all packets in this partition and continue the scan repeating 4.1 4.3 store the packets in the complete partition continue the scan repeating 4.1 until end of frame is reached. 4.4 send all complete partitions to the decoder, if no complete partition is found discard the whole frame. Regarding the minor issues: VP8 only support 8 partitions hence 3-bits in the PartID field should therefor be enough. We have nothing that force the PictureID length to be fixed size during the session, the receiver must handle both cases so in practice it make no difference to the receiver. If the sender out of convenience want to keep the same length it's free to do so. --089e0153666a30082004dd3c06b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is how I think about it

1. Collect all packets with a given RTP timestamp
2. Go through packet= s in order, sorted by sequence numbers, if packets are missing, send NACK o= r decode with missing partitions, see 4.x below.
3. Complete frame is detected by no missing sequence numbers and first pack= et in the frame containing S=3D1 with partId=3D0 and the last packet in the= frame having the marker bit set. =A0
4.1 scan for the start of a new pa= rtition; S=3D1
4.2 continue scan to detect end of partition; hence a new S=3D1 (previous p= acket was the end of the partition) is found or the marker bit is set, if a= loss it detected before the end of the partition abandon all packets in th= is partition and continue the scan repeating 4.1
4.3 store the packets in the complete partition continue the scan repeating= 4.1 until end of frame is reached.=A0
4.4 send all complete partitions = =A0to the decoder, if no complete partition is found discard the whole fram= e.


Regarding the minor issues:
VP8 only s= upport 8 partitions =A0hence 3-bits in the PartID field should therefor be = enough.

=
We have nothing that force the PictureID length to be fixed size during th= e session, the receiver must handle both cases so in practice it make no di= fference to the receiver. If the sender out of convenience want to keep the= same length it's free to do so.
--089e0153666a30082004dd3c06b5-- From gonzalo.camarillo@ericsson.com Tue May 21 22:57:02 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88CBB21F92BB for ; Tue, 21 May 2013 22:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.136 X-Spam-Level: X-Spam-Status: No, score=-105.136 tagged_above=-999 required=5 tests=[AWL=-1.041, BAYES_00=-2.599, FRT_BELOW2=2.154, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLmYoRtqd+JZ for ; Tue, 21 May 2013 22:56:57 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD3D21F91AB for ; Tue, 21 May 2013 22:56:54 -0700 (PDT) X-AuditID: c1b4fb2d-b7fe36d000007102-27-519c5e259a0d Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 87.18.28930.52E5C915; Wed, 22 May 2013 07:56:54 +0200 (CEST) Received: from [131.160.126.9] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Wed, 22 May 2013 07:56:53 +0200 Message-ID: <519C5E24.7030209@ericsson.com> Date: Wed, 22 May 2013 08:56:52 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Mo Zanaty (mzanaty)" References: <006901ce3cd1$46596c20$d30c4460$@gmail.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DA449@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D90F6DA449@xmb-rcd-x14.cisco.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUyM+Jvra5a3JxAg0k/mSxePJjDZHHp4lkm i7/tzBZ7z+xls7hy5BebxZM1x5gd2Dym/N7I6rFz1l12jyVLfjJ5vHig5LFo6jPGANYoLpuU 1JzMstQifbsErowfZ/vYCi5IVfxuPc7ewHhPuIuRk0NCwETi6sbpzBC2mMSFe+vZuhi5OIQE TjFKPNm1gxXCWc0o8Wv5SvYuRg4OXgFtiWfrwJpZBFQlpvcfZAKx2QQsJLbcus8CYosKREnM WfeADcTmFRCUODnzCVhcREBX4t3vZ4wgNrPAU0aJy30cILawgL3ExyuLweYICVRI7F27Bqye U8BXYuOatUwQx0lKbHnRzg7RayBxZNEcVghbXqJ562xmiF5tieXPWlgmMArNQrJ6FpKWWUha FjAyr2Jkz03MzEkvN9zECAz2g1t+6+5gPHVO5BCjNAeLkjhvr/bUQCGB9MSS1OzU1ILUovii 0pzU4kOMTBycUg2MhXVJX//pBuwQebBDd4LNonb3lDmrtDVnr7+k5y7/yFrB1j+KofSBdfru 9gkBdl/K8pms5Saz//rOJPTox+QZ1g5fzt9kF/tQJGjKfFn5x05Pn2cL4m14/x+Nbat3FJ92 zui0kkxlU+zZjt1saXb3797nOPnk6IP8lZs8tnGL73L2+rb4z8lVSizFGYmGWsxFxYkAMmHv /UQCAAA= Cc: "Wang, Ye-Kui" , "'Botzko, Stephen'" , "payload@ietf.org" , "Tom Kristensen \(tomkrist\)" Subject: Re: [payload] Errata report on RFC6184 - H.264 payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 05:57:02 -0000 Hi, is this erratum likely to cause interoperability problems? We need to know that in order to properly handle the erratum. What is your view? Note that the policy is to "verify" errata that are likely to cause interoperability problems and to "hold for document update" errata that are correct but are not likely to cause those types of problems. Thanks, Gonzalo On 19/04/2013 7:35 PM, Mo Zanaty (mzanaty) wrote: > The errata looks correct. For further clarity, it may also help to add > parenthesis > > around (max-dpb*8/3). > > > > NEW: > > When max-dpb is signaled, the receiver MUST be able to decode > > NAL unit streams that conform to the signaled highest level, > > with the exception that the MaxDpbMbs value in Table A-1 of [1] > > for the signaled highest level is replaced with the value of > > max-dpb * 8/3. Consequently, a receiver that signals max-dpb > > MUST be capable of storing the following number of decoded > > frames, complementary field pairs, and non-paired fields in its > > decoded picture buffer: > > Min((max-dpb * 8/3) / (PicWidthInMbs * FrameHeightInMbs),16) > > > > Mo > > > > > > *From:*Roni Even [mailto:ron.even.tlv@gmail.com] > *Sent:* Friday, April 19, 2013 3:41 AM > *To:* payload@ietf.org > *Cc:* 'Botzko, Stephen'; Mo Zanaty (mzanaty); Wang, Ye-Kui; Tom > Kristensen (tomkrist) > *Subject:* Errata report on RFC6184 - H.264 payload > > > > Hi, > > An errata report was filed on RFC6184 > http://www.rfc-editor.org/errata_search.php?eid=3318 it is given bellow. > > I would like to get some feedback about this errata, is it correct? > > “Section 8.1 says: > > On page 46 start from line 7: > > "When max-dpb is signaled, the receiver MUST be able to decode > > NAL unit streams that conform to the signaled highest level, > > with the exception that the MaxDpbMbs value in Table A-1 of [1] > > for the signaled highest level is replaced with the value of > > max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb > > ^^^^^ > > MUST be capable of storing the following number of decoded > > frames, complementary field pairs, and non-paired fields in its > > decoded picture buffer: > > Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), > > ^^^^^ > > 16)" > > It should say: > > When max-dpb is signaled, the receiver MUST be able to decode > > NAL unit streams that conform to the signaled highest level, > > with the exception that the MaxDpbMbs value in Table A-1 of [1] > > for the signaled highest level is replaced with the value of > > max-dpb * 8 / 3. Consequently, a receiver that signals max-dpb > > ^^^^^ > > MUST be capable of storing the following number of decoded > > frames, complementary field pairs, and non-paired fields in its > > decoded picture buffer: > > Min(max-dpb * 8 / 3 / ( PicWidthInMbs * FrameHeightInMbs), > > ^^^^^ > > 16) > > “ > > > > > > > > My personal view is that since MaxDpbMbs= max-dpb * 8 / 3 the errata is > correct. > > > > > > Roni Even > > > > > > > > > > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > From ron.even.tlv@gmail.com Tue May 21 23:55:40 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB62F21F92BB for ; Tue, 21 May 2013 23:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=-0.577, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASxTVjv2bEb7 for ; Tue, 21 May 2013 23:55:36 -0700 (PDT) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id C350121F9232 for ; Tue, 21 May 2013 23:55:35 -0700 (PDT) Received: by mail-ee0-f45.google.com with SMTP id l10so889066eei.18 for ; Tue, 21 May 2013 23:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=OpuVAbM0FJv0vfrAeez34f3EuNkgPvSuZGezHugD1xU=; b=FZnhoEmql3YPJB2zh3BgEH6rilYDPZ8n1BBuyP0vYH5A4iqoFj2jh9/TQDziMhGi5I Yv2ZGW8a9sVT5JVFEKamVWgWTwGnc+xxO3wdArwpfuv5wKwxsyiqxbh9McUFyUWWXwYo +lSmQ7oS1al3JQkvqMtqexyQV3HjitwHF/BlmFlL2CX51gdXMpzn7z5wOFX4B+jJdAWp WQCG3M/2uW6UW99XLY3gToHaDRacZ6SB5QJfPFNxihJbwiLFrJ/pKfSQV3qhEp5TdESH znphfi8U6Jb2Sqgkqjsc4NHlKH41LhUrvIMkim1PamcclCSbTBdQ6BU+8Ue47MIC89pN YGxA== X-Received: by 10.15.111.75 with SMTP id ci51mr15986831eeb.7.1369205734873; Tue, 21 May 2013 23:55:34 -0700 (PDT) Received: from RoniE (bzq-79-182-167-109.red.bezeqint.net. [79.182.167.109]) by mx.google.com with ESMTPSA id l6sm8036160eem.9.2013.05.21.23.55.31 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 21 May 2013 23:55:34 -0700 (PDT) From: "Roni Even" To: "'Gonzalo Camarillo'" , "'Mo Zanaty \(mzanaty\)'" References: <006901ce3cd1$46596c20$d30c4460$@gmail.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DA449@xmb-rcd-x14.cisco.com> <519C5E24.7030209@ericsson.com> In-Reply-To: <519C5E24.7030209@ericsson.com> Date: Wed, 22 May 2013 09:54:32 +0300 Message-ID: <01ab01ce56b9$38ceab90$aa6c02b0$@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: AQIDvKjYiZ6SrFiMJouiiCTn/jRubALoqMUmAbd4IISYgPdAQA== Content-Language: en-us Cc: "'Wang, Ye-Kui'" , "'Botzko, Stephen'" , payload@ietf.org, "'Tom Kristensen \(tomkrist\)'" Subject: Re: [payload] Errata report on RFC6184 - H.264 payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 06:55:41 -0000 Hi, In my view it will not cause any interoperability if the implementers are looking at the ITU-H.264 reference. I assume they are looking at table A-1 in order to know the actual DPB size for the needed resolution and calculating it Roni > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: 22 May, 2013 8:57 AM > To: Mo Zanaty (mzanaty) > Cc: Roni Even; payload@ietf.org; Wang, Ye-Kui; 'Botzko, Stephen'; Tom > Kristensen (tomkrist) > Subject: Re: [payload] Errata report on RFC6184 - H.264 payload > > Hi, > > is this erratum likely to cause interoperability problems? We need to know > that in order to properly handle the erratum. What is your view? > > Note that the policy is to "verify" errata that are likely to cause > interoperability problems and to "hold for document update" errata that are > correct but are not likely to cause those types of problems. > > Thanks, > > Gonzalo > > On 19/04/2013 7:35 PM, Mo Zanaty (mzanaty) wrote: > > The errata looks correct. For further clarity, it may also help to add > > parenthesis > > > > around (max-dpb*8/3). > > > > > > > > NEW: > > > > When max-dpb is signaled, the receiver MUST be able to decode > > > > NAL unit streams that conform to the signaled highest level, > > > > with the exception that the MaxDpbMbs value in Table A-1 of [1] > > > > for the signaled highest level is replaced with the value of > > > > max-dpb * 8/3. Consequently, a receiver that signals max-dpb > > > > MUST be capable of storing the following number of decoded > > > > frames, complementary field pairs, and non-paired fields in its > > > > decoded picture buffer: > > > > Min((max-dpb * 8/3) / (PicWidthInMbs * FrameHeightInMbs),16) > > > > > > > > Mo > > > > > > > > > > > > *From:*Roni Even [mailto:ron.even.tlv@gmail.com] > > *Sent:* Friday, April 19, 2013 3:41 AM > > *To:* payload@ietf.org > > *Cc:* 'Botzko, Stephen'; Mo Zanaty (mzanaty); Wang, Ye-Kui; Tom > > Kristensen (tomkrist) > > *Subject:* Errata report on RFC6184 - H.264 payload > > > > > > > > Hi, > > > > An errata report was filed on RFC6184 > > http://www.rfc-editor.org/errata_search.php?eid=3318 it is given bellow. > > > > I would like to get some feedback about this errata, is it correct? > > > > "Section 8.1 says: > > > > On page 46 start from line 7: > > > > "When max-dpb is signaled, the receiver MUST be able to decode > > > > NAL unit streams that conform to the signaled highest level, > > > > with the exception that the MaxDpbMbs value in Table A-1 of [1] > > > > for the signaled highest level is replaced with the value of > > > > max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb > > > > ^^^^^ > > > > MUST be capable of storing the following number of decoded > > > > frames, complementary field pairs, and non-paired fields in its > > > > decoded picture buffer: > > > > Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), > > > > ^^^^^ > > > > 16)" > > > > It should say: > > > > When max-dpb is signaled, the receiver MUST be able to decode > > > > NAL unit streams that conform to the signaled highest level, > > > > with the exception that the MaxDpbMbs value in Table A-1 of [1] > > > > for the signaled highest level is replaced with the value of > > > > max-dpb * 8 / 3. Consequently, a receiver that signals max-dpb > > > > ^^^^^ > > > > MUST be capable of storing the following number of decoded > > > > frames, complementary field pairs, and non-paired fields in its > > > > decoded picture buffer: > > > > Min(max-dpb * 8 / 3 / ( PicWidthInMbs * FrameHeightInMbs), > > > > ^^^^^ > > > > 16) > > > > " > > > > > > > > > > > > > > > > My personal view is that since MaxDpbMbs= max-dpb * 8 / 3 the errata > > is correct. > > > > > > > > > > > > Roni Even > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > payload mailing list > > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload > > From gonzalo.camarillo@ericsson.com Wed May 22 02:59:47 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3516521F86F5 for ; Wed, 22 May 2013 02:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.089 X-Spam-Level: X-Spam-Status: No, score=-105.089 tagged_above=-999 required=5 tests=[AWL=-0.994, BAYES_00=-2.599, FRT_BELOW2=2.154, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OS+qesdmpVa3 for ; Wed, 22 May 2013 02:59:41 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id DC14D21F8756 for ; Wed, 22 May 2013 02:59:40 -0700 (PDT) X-AuditID: c1b4fb30-b7f8a6d000001a2d-3c-519c970bfd40 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 99.2C.06701.B079C915; Wed, 22 May 2013 11:59:39 +0200 (CEST) Received: from [131.160.126.9] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Wed, 22 May 2013 11:59:38 +0200 Message-ID: <519C9709.3050607@ericsson.com> Date: Wed, 22 May 2013 12:59:37 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Roni Even References: <006901ce3cd1$46596c20$d30c4460$@gmail.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DA449@xmb-rcd-x14.cisco.com> <519C5E24.7030209@ericsson.com> <01ab01ce56b9$38ceab90$aa6c02b0$@gmail.com> In-Reply-To: <01ab01ce56b9$38ceab90$aa6c02b0$@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyM+JvrS739DmBBgc3ilm8eDCHyeLSxbNM Fn/bmS32ntnLZnHlyC82iydrjjE7sHlM+b2R1WPnrLvsHkuW/GTyePFAyWPR1GeMAaxRXDYp qTmZZalF+nYJXBn7WrewFVxXqlj+bBlLA+NU6S5GTg4JAROJPS+eM0PYYhIX7q1n62Lk4hAS OMUocWz+AWYIZzWjxJMbb5hAqngFtCVePjnFDmKzCKhKLJx/kQXEZhOwkNhy6z6YLSoQJTFn 3QM2iHpBiZMzn4DFRQTUJF6v/Qy2gVngNqPEi3/nwBLCAvYSH68sBlsgJHCEUeLAPDMQmxNo 6LWlKxkhzpOU2PKiHWwxs4CexJSrLYwQtrzE9rdzmCF6tSWWP2thmcAoNAvJ7llIWmYhaVnA yLyKkT03MTMnvdx8EyMw4A9u+W2wg3HTfbFDjNIcLErivH3aUwOFBNITS1KzU1MLUovii0pz UosPMTJxcEo1MB5/ZGbmsXhj2Kk7lyeek0p+xjQnaqGM3vn6tP12adPCGQSFK+azHlBzOuVz cML3NT4JRc3aGjWPZxV//DPrvvksdp+axlPfFPjWM/4zP6Ai9HzuDJb/r9I/SehF5xy+si9Q VFq2q7GL03j1V6n/S/QDjll9+bk/NED3fv+65ecM1dMWuAlYBiqxFGckGmoxFxUnAgAzRn98 RgIAAA== Cc: "'Wang, Ye-Kui'" , "'Botzko, Stephen'" , payload@ietf.org, "'Tom Kristensen \(tomkrist\)'" Subject: Re: [payload] Errata report on RFC6184 - H.264 payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 09:59:47 -0000 Hi Roni, thanks for your response. I am actually leaning towards verifying the erratum, given that the wrong figures could confuse someone. Cheers, Gonzalo On 22/05/2013 9:54 AM, Roni Even wrote: > Hi, > In my view it will not cause any interoperability if the implementers are > looking at the ITU-H.264 reference. I assume they are looking at table A-1 > in order to know the actual DPB size for the needed resolution and > calculating it > Roni > >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >> Sent: 22 May, 2013 8:57 AM >> To: Mo Zanaty (mzanaty) >> Cc: Roni Even; payload@ietf.org; Wang, Ye-Kui; 'Botzko, Stephen'; Tom >> Kristensen (tomkrist) >> Subject: Re: [payload] Errata report on RFC6184 - H.264 payload >> >> Hi, >> >> is this erratum likely to cause interoperability problems? We need to know >> that in order to properly handle the erratum. What is your view? >> >> Note that the policy is to "verify" errata that are likely to cause >> interoperability problems and to "hold for document update" errata that > are >> correct but are not likely to cause those types of problems. >> >> Thanks, >> >> Gonzalo >> >> On 19/04/2013 7:35 PM, Mo Zanaty (mzanaty) wrote: >>> The errata looks correct. For further clarity, it may also help to add >>> parenthesis >>> >>> around (max-dpb*8/3). >>> >>> >>> >>> NEW: >>> >>> When max-dpb is signaled, the receiver MUST be able to decode >>> >>> NAL unit streams that conform to the signaled highest level, >>> >>> with the exception that the MaxDpbMbs value in Table A-1 of [1] >>> >>> for the signaled highest level is replaced with the value of >>> >>> max-dpb * 8/3. Consequently, a receiver that signals max-dpb >>> >>> MUST be capable of storing the following number of decoded >>> >>> frames, complementary field pairs, and non-paired fields in its >>> >>> decoded picture buffer: >>> >>> Min((max-dpb * 8/3) / (PicWidthInMbs * FrameHeightInMbs),16) >>> >>> >>> >>> Mo >>> >>> >>> >>> >>> >>> *From:*Roni Even [mailto:ron.even.tlv@gmail.com] >>> *Sent:* Friday, April 19, 2013 3:41 AM >>> *To:* payload@ietf.org >>> *Cc:* 'Botzko, Stephen'; Mo Zanaty (mzanaty); Wang, Ye-Kui; Tom >>> Kristensen (tomkrist) >>> *Subject:* Errata report on RFC6184 - H.264 payload >>> >>> >>> >>> Hi, >>> >>> An errata report was filed on RFC6184 >>> http://www.rfc-editor.org/errata_search.php?eid=3318 it is given > bellow. >>> >>> I would like to get some feedback about this errata, is it correct? >>> >>> "Section 8.1 says: >>> >>> On page 46 start from line 7: >>> >>> "When max-dpb is signaled, the receiver MUST be able to decode >>> >>> NAL unit streams that conform to the signaled highest level, >>> >>> with the exception that the MaxDpbMbs value in Table A-1 of [1] >>> >>> for the signaled highest level is replaced with the value of >>> >>> max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb >>> >>> ^^^^^ >>> >>> MUST be capable of storing the following number of decoded >>> >>> frames, complementary field pairs, and non-paired fields in its >>> >>> decoded picture buffer: >>> >>> Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), >>> >>> ^^^^^ >>> >>> 16)" >>> >>> It should say: >>> >>> When max-dpb is signaled, the receiver MUST be able to decode >>> >>> NAL unit streams that conform to the signaled highest level, >>> >>> with the exception that the MaxDpbMbs value in Table A-1 of [1] >>> >>> for the signaled highest level is replaced with the value of >>> >>> max-dpb * 8 / 3. Consequently, a receiver that signals max-dpb >>> >>> ^^^^^ >>> >>> MUST be capable of storing the following number of decoded >>> >>> frames, complementary field pairs, and non-paired fields in its >>> >>> decoded picture buffer: >>> >>> Min(max-dpb * 8 / 3 / ( PicWidthInMbs * FrameHeightInMbs), >>> >>> ^^^^^ >>> >>> 16) >>> >>> " >>> >>> >>> >>> >>> >>> >>> >>> My personal view is that since MaxDpbMbs= max-dpb * 8 / 3 the errata >>> is correct. >>> >>> >>> >>> >>> >>> Roni Even >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> payload mailing list >>> payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload >>> > From stephen.botzko@gmail.com Wed May 22 03:48:54 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B2321F962B for ; Wed, 22 May 2013 03:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.444 X-Spam-Level: X-Spam-Status: No, score=-1.444 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwKVbKyPZ4jn for ; Wed, 22 May 2013 03:48:50 -0700 (PDT) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id A54AF21F962A for ; Wed, 22 May 2013 03:48:50 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id hv10so1213200vcb.34 for ; Wed, 22 May 2013 03:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fpeJs6ohBEOo+JtTLprilRJMV6yq3X5+gnsovGqQ7wQ=; b=VutCH/k0ydqYS4NYYkSU2bP30wpwOSxIVPRw/gftvraNLVdhvVEiJ0zqOooBymBYPG PFDZcHPyF7ewgT+VJqygiQOPnPt26Wt7WJCJDxG5902lTEbcjjGhG/IZqO5ZGXxmvDpR 4Tgjp2i79h1nE6DjwwYfcRvVbJicJ7MSXxlawiukPByfEJSlTj0CE/jOGjUJXViUBl3J zGCGpPoSLxarqUT1ByCLSVTZsbzJCrG09aHxFwsOzmAr55NpAwArtBVgZiTu3f+DGCeW 1zl2sXeikpP5uZMm8SVgXahATnfl4BTmZA4eSIpuV1csMr/UHHrtIO2sU49PE/XCTYVx 4QlQ== MIME-Version: 1.0 X-Received: by 10.220.158.209 with SMTP id g17mr2187012vcx.22.1369219730069; Wed, 22 May 2013 03:48:50 -0700 (PDT) Received: by 10.220.202.138 with HTTP; Wed, 22 May 2013 03:48:49 -0700 (PDT) In-Reply-To: <519C9709.3050607@ericsson.com> References: <006901ce3cd1$46596c20$d30c4460$@gmail.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DA449@xmb-rcd-x14.cisco.com> <519C5E24.7030209@ericsson.com> <01ab01ce56b9$38ceab90$aa6c02b0$@gmail.com> <519C9709.3050607@ericsson.com> Date: Wed, 22 May 2013 06:48:49 -0400 Message-ID: From: Stephen Botzko To: Gonzalo Camarillo Content-Type: multipart/alternative; boundary=001a11c2a204a15d5304dd4c4f64 Cc: "Wang, Ye-Kui" , "Botzko, Stephen" , payload@ietf.org, "Tom Kristensen \(tomkrist\)" Subject: Re: [payload] Errata report on RFC6184 - H.264 payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 10:48:54 -0000 --001a11c2a204a15d5304dd4c4f64 Content-Type: text/plain; charset=ISO-8859-1 Hi all First of all, I believe the erratum is correct. units of 8/3 means that max-dpb=3 is the same as MaxDpbMbs=8. -if max-dbp is signalled, then that indicates that a receiver can handle more reference frames than profile/level requires. -if the same mistake is made in both sender and receiver, then no harm is done. -however, if the mistake is not consistent, then the sender and receiver will have different understandings of the number of reference frames. -since the unit 8/3 was specifically chosen to match RFC 3984's original values, then mismatched implementations are in fact likely. If the encoder uses a larger number of reference frames than is in fact available, the rendered video will be corrupted. If the encoder uses a smaller number of reference frames, then the rendered video will be ok, though perhaps lower in quality than it could be. If the computed number of reference frames turns out to be less than what is required in the level, then some implementations might get quite confused (since this violates the MUST be greater than A-1). Given the need to match RFC 3984 values (hence the odd units), I would disagree with Roni's assessment that there is no interop issue that results. Given the overall confusion on the unusual units, I would rather see this fixed sooner than later. BR Stephen Botzko On Wed, May 22, 2013 at 5:59 AM, Gonzalo Camarillo < Gonzalo.Camarillo@ericsson.com> wrote: > Hi Roni, > > thanks for your response. I am actually leaning towards verifying the > erratum, given that the wrong figures could confuse someone. > > Cheers, > > Gonzalo > > On 22/05/2013 9:54 AM, Roni Even wrote: > > Hi, > > In my view it will not cause any interoperability if the implementers are > > looking at the ITU-H.264 reference. I assume they are looking at table > A-1 > > in order to know the actual DPB size for the needed resolution and > > calculating it > > Roni > > > >> -----Original Message----- > >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > >> Sent: 22 May, 2013 8:57 AM > >> To: Mo Zanaty (mzanaty) > >> Cc: Roni Even; payload@ietf.org; Wang, Ye-Kui; 'Botzko, Stephen'; Tom > >> Kristensen (tomkrist) > >> Subject: Re: [payload] Errata report on RFC6184 - H.264 payload > >> > >> Hi, > >> > >> is this erratum likely to cause interoperability problems? We need to > know > >> that in order to properly handle the erratum. What is your view? > >> > >> Note that the policy is to "verify" errata that are likely to cause > >> interoperability problems and to "hold for document update" errata that > > are > >> correct but are not likely to cause those types of problems. > >> > >> Thanks, > >> > >> Gonzalo > >> > >> On 19/04/2013 7:35 PM, Mo Zanaty (mzanaty) wrote: > >>> The errata looks correct. For further clarity, it may also help to add > >>> parenthesis > >>> > >>> around (max-dpb*8/3). > >>> > >>> > >>> > >>> NEW: > >>> > >>> When max-dpb is signaled, the receiver MUST be able to decode > >>> > >>> NAL unit streams that conform to the signaled highest level, > >>> > >>> with the exception that the MaxDpbMbs value in Table A-1 of [1] > >>> > >>> for the signaled highest level is replaced with the value of > >>> > >>> max-dpb * 8/3. Consequently, a receiver that signals max-dpb > >>> > >>> MUST be capable of storing the following number of decoded > >>> > >>> frames, complementary field pairs, and non-paired fields in its > >>> > >>> decoded picture buffer: > >>> > >>> Min((max-dpb * 8/3) / (PicWidthInMbs * FrameHeightInMbs),16) > >>> > >>> > >>> > >>> Mo > >>> > >>> > >>> > >>> > >>> > >>> *From:*Roni Even [mailto:ron.even.tlv@gmail.com] > >>> *Sent:* Friday, April 19, 2013 3:41 AM > >>> *To:* payload@ietf.org > >>> *Cc:* 'Botzko, Stephen'; Mo Zanaty (mzanaty); Wang, Ye-Kui; Tom > >>> Kristensen (tomkrist) > >>> *Subject:* Errata report on RFC6184 - H.264 payload > >>> > >>> > >>> > >>> Hi, > >>> > >>> An errata report was filed on RFC6184 > >>> http://www.rfc-editor.org/errata_search.php?eid=3318 it is given > > bellow. > >>> > >>> I would like to get some feedback about this errata, is it correct? > >>> > >>> "Section 8.1 says: > >>> > >>> On page 46 start from line 7: > >>> > >>> "When max-dpb is signaled, the receiver MUST be able to decode > >>> > >>> NAL unit streams that conform to the signaled highest level, > >>> > >>> with the exception that the MaxDpbMbs value in Table A-1 of [1] > >>> > >>> for the signaled highest level is replaced with the value of > >>> > >>> max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb > >>> > >>> ^^^^^ > >>> > >>> MUST be capable of storing the following number of decoded > >>> > >>> frames, complementary field pairs, and non-paired fields in its > >>> > >>> decoded picture buffer: > >>> > >>> Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), > >>> > >>> ^^^^^ > >>> > >>> 16)" > >>> > >>> It should say: > >>> > >>> When max-dpb is signaled, the receiver MUST be able to decode > >>> > >>> NAL unit streams that conform to the signaled highest level, > >>> > >>> with the exception that the MaxDpbMbs value in Table A-1 of [1] > >>> > >>> for the signaled highest level is replaced with the value of > >>> > >>> max-dpb * 8 / 3. Consequently, a receiver that signals max-dpb > >>> > >>> ^^^^^ > >>> > >>> MUST be capable of storing the following number of decoded > >>> > >>> frames, complementary field pairs, and non-paired fields in its > >>> > >>> decoded picture buffer: > >>> > >>> Min(max-dpb * 8 / 3 / ( PicWidthInMbs * FrameHeightInMbs), > >>> > >>> ^^^^^ > >>> > >>> 16) > >>> > >>> " > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> My personal view is that since MaxDpbMbs= max-dpb * 8 / 3 the errata > >>> is correct. > >>> > >>> > >>> > >>> > >>> > >>> Roni Even > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> payload mailing list > >>> payload@ietf.org > >>> https://www.ietf.org/mailman/listinfo/payload > >>> > > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > --001a11c2a204a15d5304dd4c4f64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all

First of all, I believe the erratum is correct.=A0 units of 8= /3 means that max-dpb=3D3=A0 is the same as MaxDpbMbs=3D8.

-if max-d= bp is signalled, then that indicates that a receiver can handle more refere= nce frames than profile/level requires.
-if the same mistake is made in both sender and receiver, then no harm is d= one.
-however, if the mistake is not consistent, then the sender and rec= eiver will have different understandings of the number of reference frames.=

-since the unit 8/3 was specifically chosen to match RFC 3984's ori= ginal values, then mismatched implementations are in fact likely.

If= the encoder uses a larger number of reference frames than is in fact avail= able, the rendered video will be corrupted.
If the encoder uses a smaller number of reference frames, then the rendered= video will be ok, though perhaps lower in quality than it could be.
If the computed number of reference frames turns out to be less than what = is required in the level, then some implementations might get quite confuse= d (since this violates the MUST be greater than A-1).=A0

Given the need to match RFC 3984 values (hence the odd units), I would = disagree with Roni's assessment that there is no interop issue that res= ults. Given the overall confusion on the unusual units, I would rather see = this fixed sooner than later.

BR
Stephen Botzko


On Wed, May = 22, 2013 at 5:59 AM, Gonzalo Camarillo <Gonzalo.Camarillo@eri= csson.com> wrote:
Hi Roni,

thanks for your response. I am actually leaning towards verifying the
erratum, given that the wrong figures could confuse someone.

Cheers,

Gonzalo

On 22/05/2013 9:54 AM, Roni Even wrote:
> Hi,
> In my view it will not cause any interoperability if the implementers = are
> looking at the ITU-H.264 reference. I assume they are looking at table= A-1
> in order to know the actual DPB size for the needed resolution and
> calculating it
> Roni
>
>> -----Original Message-----
>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]
>> Sent: 22 May, 2013 8:57 AM
>> To: Mo Zanaty (mzanaty)
>> Cc: Roni Even; payload@ietf.or= g; Wang, Ye-Kui; 'Botzko, Stephen'; Tom
>> Kristensen (tomkrist)
>> Subject: Re: [payload] Errata report on RFC6184 - H.264 payload >>
>> Hi,
>>
>> is this erratum likely to cause interoperability problems? We need= to know
>> that in order to properly handle the erratum. What is your view? >>
>> Note that the policy is to "verify" errata that are like= ly to cause
>> interoperability problems and to "hold for document update&qu= ot; errata that
> are
>> correct but are not likely to cause those types of problems.
>>
>> Thanks,
>>
>> Gonzalo
>>
>> On 19/04/2013 7:35 PM, Mo Zanaty (mzanaty) wrote:
>>> The errata looks correct. For further clarity, it may also hel= p to add
>>> parenthesis
>>>
>>> around (max-dpb*8/3).
>>>
>>>
>>>
>>> NEW:
>>>
>>> When max-dpb is signaled, the receiver MUST be able to decode<= br> >>>
>>> NAL unit streams that conform to the signaled highest level, >>>
>>> with the exception that the MaxDpbMbs value in Table A-1 of [1= ]
>>>
>>> for the signaled highest level is replaced with the value of >>>
>>> max-dpb * 8/3. Consequently, a receiver that signals max-dpb >>>
>>> MUST be capable of storing the following number of decoded
>>>
>>> frames, complementary field pairs, and non-paired fields in it= s
>>>
>>> decoded picture buffer:
>>>
>>> Min((max-dpb * 8/3) / (PicWidthInMbs * FrameHeightInMbs),16) >>>
>>>
>>>
>>> Mo
>>>
>>>
>>>
>>>
>>>
>>> *From:*Roni Even [mailto:ron.even.tlv@gmail.com]
>>> *Sent:* Friday, April 19, 2013 3:41 AM
>>> *To:* payload@ietf.org=
>>> *Cc:* 'Botzko, Stephen'; Mo Zanaty (mzanaty); Wang, Ye= -Kui; Tom
>>> Kristensen (tomkrist)
>>> *Subject:* Errata report on RFC6184 - H.264 payload
>>>
>>>
>>>
>>> Hi,
>>>
>>> An errata report was filed on RFC6184
>>> http://www.rfc-editor.org/errata_search.php?eid=3D33= 18 =A0it is given
> bellow.
>>>
>>> I would like to get some feedback about this errata, is it cor= rect?
>>>
>>> "Section 8.1 says:
>>>
>>> On page 46 start from line 7:
>>>
>>> "When max-dpb is signaled, the receiver MUST be able to d= ecode
>>>
>>> NAL unit streams that conform to the signaled highest level, >>>
>>> with the exception that the MaxDpbMbs value in Table A-1 of [1= ]
>>>
>>> for the signaled highest level is replaced with the value of >>>
>>> max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb=
>>>
>>> =A0 =A0 =A0 =A0 =A0 ^^^^^
>>>
>>> MUST be capable of storing the following number of decoded
>>>
>>> frames, complementary field pairs, and non-paired fields in it= s
>>>
>>> decoded picture buffer:
>>>
>>> Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs),
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^
>>>
>>> 16)"
>>>
>>> It should say:
>>>
>>> When max-dpb is signaled, the receiver MUST be able to decode<= br> >>>
>>> NAL unit streams that conform to the signaled highest level, >>>
>>> with the exception that the MaxDpbMbs value in Table A-1 of [1= ]
>>>
>>> for the signaled highest level is replaced with the value of >>>
>>> max-dpb * 8 / 3. Consequently, a receiver that signals max-dpb=
>>>
>>> =A0 =A0 =A0 =A0 =A0 ^^^^^
>>>
>>> MUST be capable of storing the following number of decoded
>>>
>>> frames, complementary field pairs, and non-paired fields in it= s
>>>
>>> decoded picture buffer:
>>>
>>> Min(max-dpb * 8 / 3 / ( PicWidthInMbs * FrameHeightInMbs),
>>>
>>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 ^^^^^
>>>
>>> 16)
>>>
>>> "
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> My personal view is that =A0since MaxDpbMbs=3D max-dpb * 8 / 3= the errata
>>> is correct.
>>>
>>>
>>>
>>>
>>>
>>> Roni Even
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> payload mailing list
>>> payload@ietf.org
>>> https://www.ietf.org/mailman/listinfo/payload
>>>
>

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

--001a11c2a204a15d5304dd4c4f64-- From ron.even.tlv@gmail.com Wed May 22 04:08:56 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CB121F963F for ; Wed, 22 May 2013 04:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.733 X-Spam-Level: X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tl99MZfBBi5 for ; Wed, 22 May 2013 04:08:51 -0700 (PDT) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by ietfa.amsl.com (Postfix) with ESMTP id 277C021F9635 for ; Wed, 22 May 2013 04:08:50 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id e49so1028709eek.5 for ; Wed, 22 May 2013 04:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=q47noo65APKJyCb6YvrfRT+GBQtW8ZzyYx9psIt0JXI=; b=eXPKgsaYZ7ZkgKNXAQxvCS19QUoc7KQfpitoY7TsS1DOFL0RbPnOXkBQUtYZ56kj3Q E6M/ghGya0bmgwTruOiiIFIb/5pC5FI+DPg1MeX/Jfqe3OFn2URcUUP1TgoZd0NPCSZT 0RwayxjVaTflOBjXLiHrgnRzNdexacGG0vIpLxRYx5RLPcwGgeqIs8iz00oJ6GoCbY48 erlN1flkVjV3LQCI0ezKC2Z4TkjxU6ri3r/ZRGeXDqyQQG+sbUqlFRGXJaVuZy09JD3J 4dDtHrx0ru68r+VVKK6XEhNSqVnxFnyLhtdr36RgdKidX0nAiJifiFyyaWCKeste6kek bhdw== X-Received: by 10.14.99.8 with SMTP id w8mr17940699eef.30.1369220930133; Wed, 22 May 2013 04:08:50 -0700 (PDT) Received: from RoniE (bzq-79-182-167-109.red.bezeqint.net. [79.182.167.109]) by mx.google.com with ESMTPSA id z52sm9455555eea.1.2013.05.22.04.08.46 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 22 May 2013 04:08:49 -0700 (PDT) From: "Roni Even" To: "'Stephen Botzko'" , "'Gonzalo Camarillo'" References: <006901ce3cd1$46596c20$d30c4460$@gmail.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DA449@xmb-rcd-x14.cisco.com> <519C5E24.7030209@ericsson.com> <01ab01ce56b9$38ceab90$aa6c02b0$@gmail.com> <519C9709.3050607@ericsson.com> In-Reply-To: Date: Wed, 22 May 2013 14:07:46 +0300 Message-ID: <01cb01ce56dc$997b1fa0$cc715ee0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01CC_01CE56F5.BECA2C60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIDvKjYiZ6SrFiMJouiiCTn/jRubALoqMUmAbd4IIQBgB2MNQIvJ+jLAq8cqU+YTklqkA== Content-Language: en-us Cc: "'Wang, Ye-Kui'" , "'Botzko, Stephen'" , payload@ietf.org, "'Tom Kristensen \(tomkrist\)'" Subject: Re: [payload] Errata report on RFC6184 - H.264 payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 11:08:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01CC_01CE56F5.BECA2C60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Steve, The fix is already there, if you go to RFC6184 you will see that it says that the errata exists to fix it. The question is what are the implications, do you think or know (Polycom systems) if existing implementations used the wrong value (3/8) in which case there will be interoperability problem. Roni From: Stephen Botzko [mailto:stephen.botzko@gmail.com] Sent: 22 May, 2013 1:49 PM To: Gonzalo Camarillo Cc: Roni Even; Wang, Ye-Kui; Botzko, Stephen; payload@ietf.org; Tom Kristensen (tomkrist) Subject: Re: [payload] Errata report on RFC6184 - H.264 payload Hi all First of all, I believe the erratum is correct. units of 8/3 means that max-dpb=3 is the same as MaxDpbMbs=8. -if max-dbp is signalled, then that indicates that a receiver can handle more reference frames than profile/level requires. -if the same mistake is made in both sender and receiver, then no harm is done. -however, if the mistake is not consistent, then the sender and receiver will have different understandings of the number of reference frames. -since the unit 8/3 was specifically chosen to match RFC 3984's original values, then mismatched implementations are in fact likely. If the encoder uses a larger number of reference frames than is in fact available, the rendered video will be corrupted. If the encoder uses a smaller number of reference frames, then the rendered video will be ok, though perhaps lower in quality than it could be. If the computed number of reference frames turns out to be less than what is required in the level, then some implementations might get quite confused (since this violates the MUST be greater than A-1). Given the need to match RFC 3984 values (hence the odd units), I would disagree with Roni's assessment that there is no interop issue that results. Given the overall confusion on the unusual units, I would rather see this fixed sooner than later. BR Stephen Botzko On Wed, May 22, 2013 at 5:59 AM, Gonzalo Camarillo wrote: Hi Roni, thanks for your response. I am actually leaning towards verifying the erratum, given that the wrong figures could confuse someone. Cheers, Gonzalo On 22/05/2013 9:54 AM, Roni Even wrote: > Hi, > In my view it will not cause any interoperability if the implementers are > looking at the ITU-H.264 reference. I assume they are looking at table A-1 > in order to know the actual DPB size for the needed resolution and > calculating it > Roni > >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >> Sent: 22 May, 2013 8:57 AM >> To: Mo Zanaty (mzanaty) >> Cc: Roni Even; payload@ietf.org; Wang, Ye-Kui; 'Botzko, Stephen'; Tom >> Kristensen (tomkrist) >> Subject: Re: [payload] Errata report on RFC6184 - H.264 payload >> >> Hi, >> >> is this erratum likely to cause interoperability problems? We need to know >> that in order to properly handle the erratum. What is your view? >> >> Note that the policy is to "verify" errata that are likely to cause >> interoperability problems and to "hold for document update" errata that > are >> correct but are not likely to cause those types of problems. >> >> Thanks, >> >> Gonzalo >> >> On 19/04/2013 7:35 PM, Mo Zanaty (mzanaty) wrote: >>> The errata looks correct. For further clarity, it may also help to add >>> parenthesis >>> >>> around (max-dpb*8/3). >>> >>> >>> >>> NEW: >>> >>> When max-dpb is signaled, the receiver MUST be able to decode >>> >>> NAL unit streams that conform to the signaled highest level, >>> >>> with the exception that the MaxDpbMbs value in Table A-1 of [1] >>> >>> for the signaled highest level is replaced with the value of >>> >>> max-dpb * 8/3. Consequently, a receiver that signals max-dpb >>> >>> MUST be capable of storing the following number of decoded >>> >>> frames, complementary field pairs, and non-paired fields in its >>> >>> decoded picture buffer: >>> >>> Min((max-dpb * 8/3) / (PicWidthInMbs * FrameHeightInMbs),16) >>> >>> >>> >>> Mo >>> >>> >>> >>> >>> >>> *From:*Roni Even [mailto:ron.even.tlv@gmail.com] >>> *Sent:* Friday, April 19, 2013 3:41 AM >>> *To:* payload@ietf.org >>> *Cc:* 'Botzko, Stephen'; Mo Zanaty (mzanaty); Wang, Ye-Kui; Tom >>> Kristensen (tomkrist) >>> *Subject:* Errata report on RFC6184 - H.264 payload >>> >>> >>> >>> Hi, >>> >>> An errata report was filed on RFC6184 >>> http://www.rfc-editor.org/errata_search.php?eid=3318 it is given > bellow. >>> >>> I would like to get some feedback about this errata, is it correct? >>> >>> "Section 8.1 says: >>> >>> On page 46 start from line 7: >>> >>> "When max-dpb is signaled, the receiver MUST be able to decode >>> >>> NAL unit streams that conform to the signaled highest level, >>> >>> with the exception that the MaxDpbMbs value in Table A-1 of [1] >>> >>> for the signaled highest level is replaced with the value of >>> >>> max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb >>> >>> ^^^^^ >>> >>> MUST be capable of storing the following number of decoded >>> >>> frames, complementary field pairs, and non-paired fields in its >>> >>> decoded picture buffer: >>> >>> Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), >>> >>> ^^^^^ >>> >>> 16)" >>> >>> It should say: >>> >>> When max-dpb is signaled, the receiver MUST be able to decode >>> >>> NAL unit streams that conform to the signaled highest level, >>> >>> with the exception that the MaxDpbMbs value in Table A-1 of [1] >>> >>> for the signaled highest level is replaced with the value of >>> >>> max-dpb * 8 / 3. Consequently, a receiver that signals max-dpb >>> >>> ^^^^^ >>> >>> MUST be capable of storing the following number of decoded >>> >>> frames, complementary field pairs, and non-paired fields in its >>> >>> decoded picture buffer: >>> >>> Min(max-dpb * 8 / 3 / ( PicWidthInMbs * FrameHeightInMbs), >>> >>> ^^^^^ >>> >>> 16) >>> >>> " >>> >>> >>> >>> >>> >>> >>> >>> My personal view is that since MaxDpbMbs= max-dpb * 8 / 3 the errata >>> is correct. >>> >>> >>> >>> >>> >>> Roni Even >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> payload mailing list >>> payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload >>> > _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload ------=_NextPart_000_01CC_01CE56F5.BECA2C60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Steve,

The fix is already there, if you go to RFC6184 you will see that it = says that the errata exists to fix it.

The question is what are the implications, do you think or know = (Polycom systems) if existing implementations used the wrong value (3/8) = in which case there will be interoperability problem.  =

Roni

 

From:= = Stephen Botzko [mailto:stephen.botzko@gmail.com]
Sent: 22 = May, 2013 1:49 PM
To: Gonzalo Camarillo
Cc: Roni = Even; Wang, Ye-Kui; Botzko, Stephen; payload@ietf.org; Tom Kristensen = (tomkrist)
Subject: Re: [payload] Errata report on RFC6184 - = H.264 payload

 

Hi all

First of all, I believe the = erratum is correct.  units of 8/3 means that max-dpb=3D3  is = the same as MaxDpbMbs=3D8.

-if max-dbp is signalled, then that = indicates that a receiver can handle more reference frames than = profile/level requires.
-if the same mistake is made in both sender = and receiver, then no harm is done.
-however, if the mistake is not = consistent, then the sender and receiver will have different = understandings of the number of reference frames.

-since the unit = 8/3 was specifically chosen to match RFC 3984's original values, then = mismatched implementations are in fact likely.

If the encoder = uses a larger number of reference frames than is in fact available, the = rendered video will be corrupted.
If the encoder uses a smaller = number of reference frames, then the rendered video will be ok, though = perhaps lower in quality than it could be.

If the computed number = of reference frames turns out to be less than what is required in the = level, then some implementations might get quite confused (since this = violates the MUST be greater than A-1). 

Given the need to = match RFC 3984 values (hence the odd units), I would disagree with = Roni's assessment that there is no interop issue that results. Given the = overall confusion on the unusual units, I would rather see this fixed = sooner than later.

BR
Stephen = Botzko

On Wed, May 22, = 2013 at 5:59 AM, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> = wrote:

Hi Roni,

thanks for = your response. I am actually leaning towards verifying the
erratum, = given that the wrong figures could confuse = someone.

Cheers,

Gonzalo


On 22/05/2013 9:54 AM, Roni Even wrote:
> = Hi,
> In my view it will not cause any interoperability if the = implementers are
> looking at the ITU-H.264 reference. I assume = they are looking at table A-1
> in order to know the actual DPB = size for the needed resolution and
> calculating it
> = Roni
>
>> -----Original Message-----
>> From: = Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson= .com]
>> Sent: 22 May, 2013 8:57 AM
>> To: Mo = Zanaty (mzanaty)
>> Cc: Roni Even; payload@ietf.org; Wang, Ye-Kui; = 'Botzko, Stephen'; Tom
>> Kristensen (tomkrist)
>> = Subject: Re: [payload] Errata report on RFC6184 - H.264 = payload
>>
>> Hi,
>>
>> is this = erratum likely to cause interoperability problems? We need to = know
>> that in order to properly handle the erratum. What is = your view?
>>
>> Note that the policy is to = "verify" errata that are likely to cause
>> = interoperability problems and to "hold for document update" = errata that
> are
>> correct but are not likely to cause = those types of problems.
>>
>> = Thanks,
>>
>> Gonzalo
>>
>> On = 19/04/2013 7:35 PM, Mo Zanaty (mzanaty) wrote:
>>> The = errata looks correct. For further clarity, it may also help to = add
>>> parenthesis
>>>
>>> around = (max-dpb*8/3).
>>>
>>>
>>>
>>= ;> NEW:
>>>
>>> When max-dpb is signaled, the = receiver MUST be able to decode
>>>
>>> NAL unit = streams that conform to the signaled highest = level,
>>>
>>> with the exception that the = MaxDpbMbs value in Table A-1 of [1]
>>>
>>> for = the signaled highest level is replaced with the value = of
>>>
>>> max-dpb * 8/3. Consequently, a = receiver that signals max-dpb
>>>
>>> MUST be = capable of storing the following number of = decoded
>>>
>>> frames, complementary field = pairs, and non-paired fields in its
>>>
>>> = decoded picture buffer:
>>>
>>> Min((max-dpb * = 8/3) / (PicWidthInMbs * = FrameHeightInMbs),16)
>>>
>>>
>>>
= >>> = Mo
>>>
>>>
>>>
>>>
>= ;>>
>>> *From:*Roni Even [mailto:ron.even.tlv@gmail.com]
>= ;>> *Sent:* Friday, April 19, 2013 3:41 AM
>>> *To:* = payload@ietf.org
>>> = *Cc:* 'Botzko, Stephen'; Mo Zanaty (mzanaty); Wang, Ye-Kui; = Tom
>>> Kristensen (tomkrist)
>>> *Subject:* = Errata report on RFC6184 - H.264 = payload
>>>
>>>
>>>
>>> = Hi,
>>>
>>> An errata report was filed on = RFC6184
>>> http://www.rfc-editor.org/errata_search.php?eid=3D3318<= /a>  it is given
> bellow.
>>>
>>> I = would like to get some feedback about this errata, is it = correct?
>>>
>>> "Section 8.1 = says:
>>>
>>> On page 46 start from line = 7:
>>>
>>> "When max-dpb is signaled, the = receiver MUST be able to decode
>>>
>>> NAL unit = streams that conform to the signaled highest = level,
>>>
>>> with the exception that the = MaxDpbMbs value in Table A-1 of [1]
>>>
>>> for = the signaled highest level is replaced with the value = of
>>>
>>> max-dpb * 3 / 8. Consequently, a = receiver that signals max-dpb
>>>
>>>   =         ^^^^^
>>>
>>> MUST = be capable of storing the following number of = decoded
>>>
>>> frames, complementary field = pairs, and non-paired fields in its
>>>
>>> = decoded picture buffer:
>>>
>>> Min(max-dpb * 3 = / 8 / ( PicWidthInMbs * = FrameHeightInMbs),
>>>
>>>       =         ^^^^^
>>>
>>> = 16)"
>>>
>>> It should = say:
>>>
>>> When max-dpb is signaled, the = receiver MUST be able to decode
>>>
>>> NAL unit = streams that conform to the signaled highest = level,
>>>
>>> with the exception that the = MaxDpbMbs value in Table A-1 of [1]
>>>
>>> for = the signaled highest level is replaced with the value = of
>>>
>>> max-dpb * 8 / 3. Consequently, a = receiver that signals max-dpb
>>>
>>>   =         ^^^^^
>>>
>>> MUST = be capable of storing the following number of = decoded
>>>
>>> frames, complementary field = pairs, and non-paired fields in its
>>>
>>> = decoded picture buffer:
>>>
>>> Min(max-dpb * 8 = / 3 / ( PicWidthInMbs * = FrameHeightInMbs),
>>>
>>>       =         ^^^^^
>>>
>>> = 16)
>>>
>>> = "
>>>
>>>
>>>
>>>>>>
>>>
>>>
>>> My = personal view is that  since MaxDpbMbs=3D max-dpb * 8 / 3 the = errata
>>> is = correct.
>>>
>>>
>>>
>>><= br>>>>
>>> Roni = Even
>>>
>>>
>>>
>>>
&= gt;>>
>>>
>>>
>>>
>>&g= t;
>>>
>>>
>>> = _______________________________________________
>>> payload = mailing list
>>> payload@ietf.org
>>> https://www.ietf.org/mailman/listinfo/payload
&g= t;>>
>

_______________________________________________=
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload<= /o:p>

 

------=_NextPart_000_01CC_01CE56F5.BECA2C60-- From gonzalo.camarillo@ericsson.com Wed May 22 04:25:33 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316F621F9635 for ; Wed, 22 May 2013 04:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.045 X-Spam-Level: X-Spam-Status: No, score=-105.045 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_00=-2.599, FRT_BELOW2=2.154, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExNXCCDlEDQn for ; Wed, 22 May 2013 04:25:28 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB6021F955C for ; Wed, 22 May 2013 04:25:27 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-28-519cab253a52 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id EC.89.31782.52BAC915; Wed, 22 May 2013 13:25:26 +0200 (CEST) Received: from [131.160.126.9] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Wed, 22 May 2013 13:25:25 +0200 Message-ID: <519CAB25.7050902@ericsson.com> Date: Wed, 22 May 2013 14:25:25 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Roni Even References: <006901ce3cd1$46596c20$d30c4460$@gmail.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DA449@xmb-rcd-x14.cisco.com> <519C5E24.7030209@ericsson.com> <01ab01ce56b9$38ceab90$aa6c02b0$@gmail.com> <519C9709.3050607@ericsson.com> <01cb01ce56dc$997b1fa0$cc715ee0$@gmail.com> In-Reply-To: <01cb01ce56dc$997b1fa0$cc715ee0$@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvra7a6jmBBr0HuCwuXTzLZPG3ndli 5odNrBZ7z+xls7hy5BebxZM1x5gd2Dym/N7I6rFz1l12jyVLfjJ5vHig5LFo6jPGANYoLpuU 1JzMstQifbsErox/DVvZCq7YV+z9/J6xgfG4URcjJ4eEgInE2XP9zBC2mMSFe+vZuhi5OIQE TjFKPLl2hBnCWc0o8XVXGztIFa+AtsTWB5vZQGwWAVWJqb8XgMXZBCwktty6zwJiiwpEScxZ 94ANol5Q4uTMJ2BxEQE1iddrP4NtYBa4zSgxu/8O2GphAXuJj1cWM0Fsu8oksXnSBSaQBCfQ 1H0vD7JC3CcpseVFO9g2ZgE9iSlXWxghbHmJ7W/ngA0SArpu+bMWlgmMQrOQLJ+FpGUWkpYF jMyrGNlzEzNz0suNNjECQ/7glt+qOxjvnBM5xCjNwaIkzturPTVQSCA9sSQ1OzW1ILUovqg0 J7X4ECMTB6dUA6NRs+N3VonJZ6LNfHgtPaaku6UuniGvVnrZYXPht2Uba5ddYVtq9aJug+KF XPs5jDt4ZDge1PzK/O1emufcX3tEsarj8IbIEF3JSXa7VqZIzezNfzD15Z33Yr0pAjKMGn8u sTsWu/nPYI376Lz5/PrVPYzFTd0mbiGvrdOsT+SxxrGxff7lr8RSnJFoqMVcVJwIAKI4JrdH AgAA Cc: "'Wang, Ye-Kui'" , "'Botzko, Stephen'" , payload@ietf.org, "'Tom Kristensen \(tomkrist\)'" Subject: Re: [payload] Errata report on RFC6184 - H.264 payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 11:25:33 -0000 Hi, let me clarify what we are doing here. This is the page where you can see all the errata related to RFC 6184: http://www.rfc-editor.org/errata_search.php?rfc=6184 As you can see, there is only one erratum and its state is "reported". Given that the erratum is correct, as we have already discussed, we have to move it to one of the following two states: verified or held for document update. The first state means that the erratum is correct and that implementers should look at it carefully. The second state means that the erratum is correct but that implementers do not need to pay too much attention to it because it is not likely to confuse them (e.g., a typo in a document or an error in an example). So, this is important for all implementers, old and new. Based on the discussions so far, I am going to "verify" this erratum. Cheers, Gonzalo On 22/05/2013 2:07 PM, Roni Even wrote: > Hi Steve, > > The fix is already there, if you go to RFC6184 you will see that it says > that the errata exists to fix it. > > The question is what are the implications, do you think or know (Polycom > systems) if existing implementations used the wrong value (3/8) in which > case there will be interoperability problem. > > Roni > > > > *From:*Stephen Botzko [mailto:stephen.botzko@gmail.com] > *Sent:* 22 May, 2013 1:49 PM > *To:* Gonzalo Camarillo > *Cc:* Roni Even; Wang, Ye-Kui; Botzko, Stephen; payload@ietf.org; Tom > Kristensen (tomkrist) > *Subject:* Re: [payload] Errata report on RFC6184 - H.264 payload > > > > Hi all > > First of all, I believe the erratum is correct. units of 8/3 means that > max-dpb=3 is the same as MaxDpbMbs=8. > > -if max-dbp is signalled, then that indicates that a receiver can handle > more reference frames than profile/level requires. > -if the same mistake is made in both sender and receiver, then no harm > is done. > -however, if the mistake is not consistent, then the sender and receiver > will have different understandings of the number of reference frames. > > -since the unit 8/3 was specifically chosen to match RFC 3984's original > values, then mismatched implementations are in fact likely. > > If the encoder uses a larger number of reference frames than is in fact > available, the rendered video will be corrupted. > If the encoder uses a smaller number of reference frames, then the > rendered video will be ok, though perhaps lower in quality than it could be. > > If the computed number of reference frames turns out to be less than > what is required in the level, then some implementations might get quite > confused (since this violates the MUST be greater than A-1). > > Given the need to match RFC 3984 values (hence the odd units), I would > disagree with Roni's assessment that there is no interop issue that > results. Given the overall confusion on the unusual units, I would > rather see this fixed sooner than later. > > BR > Stephen Botzko > > On Wed, May 22, 2013 at 5:59 AM, Gonzalo Camarillo > > > wrote: > > Hi Roni, > > thanks for your response. I am actually leaning towards verifying the > erratum, given that the wrong figures could confuse someone. > > Cheers, > > Gonzalo > > > On 22/05/2013 9:54 AM, Roni Even wrote: >> Hi, >> In my view it will not cause any interoperability if the implementers are >> looking at the ITU-H.264 reference. I assume they are looking at table A-1 >> in order to know the actual DPB size for the needed resolution and >> calculating it >> Roni >> >>> -----Original Message----- >>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com > ] >>> Sent: 22 May, 2013 8:57 AM >>> To: Mo Zanaty (mzanaty) >>> Cc: Roni Even; payload@ietf.org ; Wang, > Ye-Kui; 'Botzko, Stephen'; Tom >>> Kristensen (tomkrist) >>> Subject: Re: [payload] Errata report on RFC6184 - H.264 payload >>> >>> Hi, >>> >>> is this erratum likely to cause interoperability problems? We need to > know >>> that in order to properly handle the erratum. What is your view? >>> >>> Note that the policy is to "verify" errata that are likely to cause >>> interoperability problems and to "hold for document update" errata that >> are >>> correct but are not likely to cause those types of problems. >>> >>> Thanks, >>> >>> Gonzalo >>> >>> On 19/04/2013 7:35 PM, Mo Zanaty (mzanaty) wrote: >>>> The errata looks correct. For further clarity, it may also help to add >>>> parenthesis >>>> >>>> around (max-dpb*8/3). >>>> >>>> >>>> >>>> NEW: >>>> >>>> When max-dpb is signaled, the receiver MUST be able to decode >>>> >>>> NAL unit streams that conform to the signaled highest level, >>>> >>>> with the exception that the MaxDpbMbs value in Table A-1 of [1] >>>> >>>> for the signaled highest level is replaced with the value of >>>> >>>> max-dpb * 8/3. Consequently, a receiver that signals max-dpb >>>> >>>> MUST be capable of storing the following number of decoded >>>> >>>> frames, complementary field pairs, and non-paired fields in its >>>> >>>> decoded picture buffer: >>>> >>>> Min((max-dpb * 8/3) / (PicWidthInMbs * FrameHeightInMbs),16) >>>> >>>> >>>> >>>> Mo >>>> >>>> >>>> >>>> >>>> >>>> *From:*Roni Even [mailto:ron.even.tlv@gmail.com > ] >>>> *Sent:* Friday, April 19, 2013 3:41 AM >>>> *To:* payload@ietf.org >>>> *Cc:* 'Botzko, Stephen'; Mo Zanaty (mzanaty); Wang, Ye-Kui; Tom >>>> Kristensen (tomkrist) >>>> *Subject:* Errata report on RFC6184 - H.264 payload >>>> >>>> >>>> >>>> Hi, >>>> >>>> An errata report was filed on RFC6184 >>>> http://www.rfc-editor.org/errata_search.php?eid=3318 it is given >> bellow. >>>> >>>> I would like to get some feedback about this errata, is it correct? >>>> >>>> "Section 8.1 says: >>>> >>>> On page 46 start from line 7: >>>> >>>> "When max-dpb is signaled, the receiver MUST be able to decode >>>> >>>> NAL unit streams that conform to the signaled highest level, >>>> >>>> with the exception that the MaxDpbMbs value in Table A-1 of [1] >>>> >>>> for the signaled highest level is replaced with the value of >>>> >>>> max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb >>>> >>>> ^^^^^ >>>> >>>> MUST be capable of storing the following number of decoded >>>> >>>> frames, complementary field pairs, and non-paired fields in its >>>> >>>> decoded picture buffer: >>>> >>>> Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), >>>> >>>> ^^^^^ >>>> >>>> 16)" >>>> >>>> It should say: >>>> >>>> When max-dpb is signaled, the receiver MUST be able to decode >>>> >>>> NAL unit streams that conform to the signaled highest level, >>>> >>>> with the exception that the MaxDpbMbs value in Table A-1 of [1] >>>> >>>> for the signaled highest level is replaced with the value of >>>> >>>> max-dpb * 8 / 3. Consequently, a receiver that signals max-dpb >>>> >>>> ^^^^^ >>>> >>>> MUST be capable of storing the following number of decoded >>>> >>>> frames, complementary field pairs, and non-paired fields in its >>>> >>>> decoded picture buffer: >>>> >>>> Min(max-dpb * 8 / 3 / ( PicWidthInMbs * FrameHeightInMbs), >>>> >>>> ^^^^^ >>>> >>>> 16) >>>> >>>> " >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> My personal view is that since MaxDpbMbs= max-dpb * 8 / 3 the errata >>>> is correct. >>>> >>>> >>>> >>>> >>>> >>>> Roni Even >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> payload mailing list >>>> payload@ietf.org >>>> https://www.ietf.org/mailman/listinfo/payload >>>> >> > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > > > From mzanaty@cisco.com Wed May 22 08:12:48 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5255221F8E87 for ; Wed, 22 May 2013 08:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.522 X-Spam-Level: X-Spam-Status: No, score=-9.522 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+ek5hjj2b+W for ; Wed, 22 May 2013 08:12:43 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8879021F8607 for ; Wed, 22 May 2013 08:12:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9268; q=dns/txt; s=iport; t=1369235563; x=1370445163; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/bUPc1NXUm2aHwmqoWkjoqNE0J1i8hkcAs2x/6xsnc8=; b=jNvYJzXYrJbO9uGfZWF2eQuScjnZAJ8SmebpSoHVOTjNfeeTSr5P1UlM 4cnufyXmojPUMhiTjq1NTQLDzsrkYYe1F9RX5mydy0fy0ONPPDiutUdQ0 0lsvmHAPaYb/wjABXbzhVRRtwQfpcnJ5zNEY6+0hdpCcwOIFZm0Wcmgf7 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowFAMPfnFGtJV2Y/2dsb2JhbABAFAaDCDDBboEFFnSCIwEBAQQBAQE3NAsMBAIBCBEEAQEBChQJByEGCxQJCAIEAQ0FCIdzAw8MM7IpDYhNjEaBMXUGKwcGgm1hA5NngWuOA4Ujgw96gSw X-IronPort-AV: E=Sophos;i="4.87,721,1363132800"; d="scan'208";a="213626998" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 22 May 2013 15:12:43 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4MFCgLC009608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 May 2013 15:12:42 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Wed, 22 May 2013 10:12:42 -0500 From: "Mo Zanaty (mzanaty)" To: Gonzalo Camarillo , Roni Even Thread-Topic: [payload] Errata report on RFC6184 - H.264 payload Thread-Index: Ac48zT0MjAv8KR0ASOKqxoogCAoRIAAR8V4gBnGDkgAAAgOUAAAGdsaAAAG34oAAAKltAAAAnc6AAAT7T6A= Date: Wed, 22 May 2013 15:12:41 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D47AF81@xmb-rcd-x14.cisco.com> References: <006901ce3cd1$46596c20$d30c4460$@gmail.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DA449@xmb-rcd-x14.cisco.com> <519C5E24.7030209@ericsson.com> <01ab01ce56b9$38ceab90$aa6c02b0$@gmail.com> <519C9709.3050607@ericsson.com> <01cb01ce56dc$997b1fa0$cc715ee0$@gmail.com> <519CAB25.7050902@ericsson.com> In-Reply-To: <519CAB25.7050902@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.217.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'Wang, Ye-Kui'" , "'Botzko, Stephen'" , "payload@ietf.org" , "Tom Kristensen \(tomkrist\)" Subject: Re: [payload] Errata report on RFC6184 - H.264 payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 15:12:48 -0000 Agree to "verify" this. It can possibly (although unlikely) cause interoper= ability problems due to confusion about the conversion between max-dpb and = MaxDpbMbs. I say "although unlikely" because max-dpb is rarely used, since = the default number of reference frames (4+) in any H.264 level typically ex= ceeds the number used in conferencing. At recent interoperability events (S= IPit30, IMTC SuperOp 2013), only a single vendor was using max-dpb (and cor= rectly). And those using it would likely be knowledgeable about its intende= d semantics. Mo -----Original Message----- From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Gonzalo Camarillo Sent: Wednesday, May 22, 2013 7:25 AM To: Roni Even Cc: 'Wang, Ye-Kui'; 'Botzko, Stephen'; payload@ietf.org; Tom Kristensen (to= mkrist) Subject: Re: [payload] Errata report on RFC6184 - H.264 payload Hi, let me clarify what we are doing here. This is the page where you can see all the errata related to RFC 6184: http://www.rfc-editor.org/errata_search.php?rfc=3D6184 As you can see, there is only one erratum and its state is "reported". Given that the erratum is correct, as we have already discussed, we have to move it to one of the following two states: verified or held for document update. The first state means that the erratum is correct and that implementers should look at it carefully. The second state means that the erratum is correct but that implementers do not need to pay too much attention to it because it is not likely to confuse them (e.g., a typo in a document or an error in an example). So, this is important for all implementers, old and new. Based on the discussions so far, I am going to "verify" this erratum. Cheers, Gonzalo On 22/05/2013 2:07 PM, Roni Even wrote: > Hi Steve, >=20 > The fix is already there, if you go to RFC6184 you will see that it says > that the errata exists to fix it. >=20 > The question is what are the implications, do you think or know (Polycom > systems) if existing implementations used the wrong value (3/8) in which > case there will be interoperability problem.=20 >=20 > Roni >=20 > =20 >=20 > *From:*Stephen Botzko [mailto:stephen.botzko@gmail.com] > *Sent:* 22 May, 2013 1:49 PM > *To:* Gonzalo Camarillo > *Cc:* Roni Even; Wang, Ye-Kui; Botzko, Stephen; payload@ietf.org; Tom > Kristensen (tomkrist) > *Subject:* Re: [payload] Errata report on RFC6184 - H.264 payload >=20 > =20 >=20 > Hi all >=20 > First of all, I believe the erratum is correct. units of 8/3 means that > max-dpb=3D3 is the same as MaxDpbMbs=3D8. >=20 > -if max-dbp is signalled, then that indicates that a receiver can handle > more reference frames than profile/level requires. > -if the same mistake is made in both sender and receiver, then no harm > is done. > -however, if the mistake is not consistent, then the sender and receiver > will have different understandings of the number of reference frames. >=20 > -since the unit 8/3 was specifically chosen to match RFC 3984's original > values, then mismatched implementations are in fact likely. >=20 > If the encoder uses a larger number of reference frames than is in fact > available, the rendered video will be corrupted. > If the encoder uses a smaller number of reference frames, then the > rendered video will be ok, though perhaps lower in quality than it could = be. >=20 > If the computed number of reference frames turns out to be less than > what is required in the level, then some implementations might get quite > confused (since this violates the MUST be greater than A-1).=20 >=20 > Given the need to match RFC 3984 values (hence the odd units), I would > disagree with Roni's assessment that there is no interop issue that > results. Given the overall confusion on the unusual units, I would > rather see this fixed sooner than later. >=20 > BR > Stephen Botzko >=20 > On Wed, May 22, 2013 at 5:59 AM, Gonzalo Camarillo > > > wrote: >=20 > Hi Roni, >=20 > thanks for your response. I am actually leaning towards verifying the > erratum, given that the wrong figures could confuse someone. >=20 > Cheers, >=20 > Gonzalo >=20 >=20 > On 22/05/2013 9:54 AM, Roni Even wrote: >> Hi, >> In my view it will not cause any interoperability if the implementers ar= e >> looking at the ITU-H.264 reference. I assume they are looking at table A= -1 >> in order to know the actual DPB size for the needed resolution and >> calculating it >> Roni >> >>> -----Original Message----- >>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com > ] >>> Sent: 22 May, 2013 8:57 AM >>> To: Mo Zanaty (mzanaty) >>> Cc: Roni Even; payload@ietf.org ; Wang, > Ye-Kui; 'Botzko, Stephen'; Tom >>> Kristensen (tomkrist) >>> Subject: Re: [payload] Errata report on RFC6184 - H.264 payload >>> >>> Hi, >>> >>> is this erratum likely to cause interoperability problems? We need to > know >>> that in order to properly handle the erratum. What is your view? >>> >>> Note that the policy is to "verify" errata that are likely to cause >>> interoperability problems and to "hold for document update" errata that >> are >>> correct but are not likely to cause those types of problems. >>> >>> Thanks, >>> >>> Gonzalo >>> >>> On 19/04/2013 7:35 PM, Mo Zanaty (mzanaty) wrote: >>>> The errata looks correct. For further clarity, it may also help to add >>>> parenthesis >>>> >>>> around (max-dpb*8/3). >>>> >>>> >>>> >>>> NEW: >>>> >>>> When max-dpb is signaled, the receiver MUST be able to decode >>>> >>>> NAL unit streams that conform to the signaled highest level, >>>> >>>> with the exception that the MaxDpbMbs value in Table A-1 of [1] >>>> >>>> for the signaled highest level is replaced with the value of >>>> >>>> max-dpb * 8/3. Consequently, a receiver that signals max-dpb >>>> >>>> MUST be capable of storing the following number of decoded >>>> >>>> frames, complementary field pairs, and non-paired fields in its >>>> >>>> decoded picture buffer: >>>> >>>> Min((max-dpb * 8/3) / (PicWidthInMbs * FrameHeightInMbs),16) >>>> >>>> >>>> >>>> Mo >>>> >>>> >>>> >>>> >>>> >>>> *From:*Roni Even [mailto:ron.even.tlv@gmail.com > ] >>>> *Sent:* Friday, April 19, 2013 3:41 AM >>>> *To:* payload@ietf.org >>>> *Cc:* 'Botzko, Stephen'; Mo Zanaty (mzanaty); Wang, Ye-Kui; Tom >>>> Kristensen (tomkrist) >>>> *Subject:* Errata report on RFC6184 - H.264 payload >>>> >>>> >>>> >>>> Hi, >>>> >>>> An errata report was filed on RFC6184 >>>> http://www.rfc-editor.org/errata_search.php?eid=3D3318 it is given >> bellow. >>>> >>>> I would like to get some feedback about this errata, is it correct? >>>> >>>> "Section 8.1 says: >>>> >>>> On page 46 start from line 7: >>>> >>>> "When max-dpb is signaled, the receiver MUST be able to decode >>>> >>>> NAL unit streams that conform to the signaled highest level, >>>> >>>> with the exception that the MaxDpbMbs value in Table A-1 of [1] >>>> >>>> for the signaled highest level is replaced with the value of >>>> >>>> max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb >>>> >>>> ^^^^^ >>>> >>>> MUST be capable of storing the following number of decoded >>>> >>>> frames, complementary field pairs, and non-paired fields in its >>>> >>>> decoded picture buffer: >>>> >>>> Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), >>>> >>>> ^^^^^ >>>> >>>> 16)" >>>> >>>> It should say: >>>> >>>> When max-dpb is signaled, the receiver MUST be able to decode >>>> >>>> NAL unit streams that conform to the signaled highest level, >>>> >>>> with the exception that the MaxDpbMbs value in Table A-1 of [1] >>>> >>>> for the signaled highest level is replaced with the value of >>>> >>>> max-dpb * 8 / 3. Consequently, a receiver that signals max-dpb >>>> >>>> ^^^^^ >>>> >>>> MUST be capable of storing the following number of decoded >>>> >>>> frames, complementary field pairs, and non-paired fields in its >>>> >>>> decoded picture buffer: >>>> >>>> Min(max-dpb * 8 / 3 / ( PicWidthInMbs * FrameHeightInMbs), >>>> >>>> ^^^^^ >>>> >>>> 16) >>>> >>>> " >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> My personal view is that since MaxDpbMbs=3D max-dpb * 8 / 3 the errat= a >>>> is correct. >>>> >>>> >>>> >>>> >>>> >>>> Roni Even >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> payload mailing list >>>> payload@ietf.org >>>> https://www.ietf.org/mailman/listinfo/payload >>>> >> >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload >=20 > =20 >=20 _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From Stephen.Botzko@polycom.com Wed May 22 09:09:19 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4D021F9671 for ; Wed, 22 May 2013 09:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.445 X-Spam-Level: X-Spam-Status: No, score=-4.445 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TM66UMSXQkbq for ; Wed, 22 May 2013 09:09:13 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1AB21F96AC for ; Wed, 22 May 2013 09:09:09 -0700 (PDT) Received: from CRPMBOXPRD07.polycom.com ([fe80::91fc:8a0f:5258:aff0]) by crpehubprd02.polycom.com ([::1]) with mapi; Wed, 22 May 2013 09:09:08 -0700 From: "Botzko, Stephen" To: "Mo Zanaty (mzanaty)" Date: Wed, 22 May 2013 09:09:07 -0700 Thread-Topic: [payload] Errata report on RFC6184 - H.264 payload Thread-Index: Ac5XBrCiT9teo6ZkRwyDmjLwHlcqKA== Message-ID: <6910FFCE-CADE-490E-A866-B16334050559@polycom.com> References: <006901ce3cd1$46596c20$d30c4460$@gmail.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DA449@xmb-rcd-x14.cisco.com> <519C5E24.7030209@ericsson.com> <01ab01ce56b9$38ceab90$aa6c02b0$@gmail.com> <519C9709.3050607@ericsson.com> <01cb01ce56dc$997b1fa0$cc715ee0$@gmail.com> <519CAB25.7050902@ericsson.com> <3879D71E758A7E4AA99A35DD8D41D3D91D47AF81@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D47AF81@xmb-rcd-x14.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 22 May 2013 09:14:36 -0700 Cc: "Wang, Ye-Kui" , "payload@ietf.org" , "Tom Kristensen \(tomkrist\)" Subject: Re: [payload] Errata report on RFC6184 - H.264 payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 16:09:19 -0000 I agree that "verify" is the appropriate state. Stephen Botzko Sent from my iPad On May 22, 2013, at 11:12 AM, "Mo Zanaty (mzanaty)" wro= te: > Agree to "verify" this. It can possibly (although unlikely) cause interop= erability problems due to confusion about the conversion between max-dpb an= d MaxDpbMbs. I say "although unlikely" because max-dpb is rarely used, sinc= e the default number of reference frames (4+) in any H.264 level typically = exceeds the number used in conferencing. At recent interoperability events = (SIPit30, IMTC SuperOp 2013), only a single vendor was using max-dpb (and c= orrectly). And those using it would likely be knowledgeable about its inten= ded semantics. >=20 > Mo >=20 > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behal= f Of Gonzalo Camarillo > Sent: Wednesday, May 22, 2013 7:25 AM > To: Roni Even > Cc: 'Wang, Ye-Kui'; 'Botzko, Stephen'; payload@ietf.org; Tom Kristensen (= tomkrist) > Subject: Re: [payload] Errata report on RFC6184 - H.264 payload >=20 > Hi, >=20 > let me clarify what we are doing here. This is the page where you can > see all the errata related to RFC 6184: >=20 > http://www.rfc-editor.org/errata_search.php?rfc=3D6184 >=20 > As you can see, there is only one erratum and its state is "reported". > Given that the erratum is correct, as we have already discussed, we have > to move it to one of the following two states: verified or held for > document update. >=20 > The first state means that the erratum is correct and that implementers > should look at it carefully. The second state means that the erratum is > correct but that implementers do not need to pay too much attention to > it because it is not likely to confuse them (e.g., a typo in a document > or an error in an example). >=20 > So, this is important for all implementers, old and new. >=20 > Based on the discussions so far, I am going to "verify" this erratum. >=20 > Cheers, >=20 > Gonzalo >=20 > On 22/05/2013 2:07 PM, Roni Even wrote: >> Hi Steve, >>=20 >> The fix is already there, if you go to RFC6184 you will see that it says >> that the errata exists to fix it. >>=20 >> The question is what are the implications, do you think or know (Polycom >> systems) if existing implementations used the wrong value (3/8) in which >> case there will be interoperability problem. >>=20 >> Roni >>=20 >>=20 >>=20 >> *From:*Stephen Botzko [mailto:stephen.botzko@gmail.com] >> *Sent:* 22 May, 2013 1:49 PM >> *To:* Gonzalo Camarillo >> *Cc:* Roni Even; Wang, Ye-Kui; Botzko, Stephen; payload@ietf.org; Tom >> Kristensen (tomkrist) >> *Subject:* Re: [payload] Errata report on RFC6184 - H.264 payload >>=20 >>=20 >>=20 >> Hi all >>=20 >> First of all, I believe the erratum is correct. units of 8/3 means that >> max-dpb=3D3 is the same as MaxDpbMbs=3D8. >>=20 >> -if max-dbp is signalled, then that indicates that a receiver can handle >> more reference frames than profile/level requires. >> -if the same mistake is made in both sender and receiver, then no harm >> is done. >> -however, if the mistake is not consistent, then the sender and receiver >> will have different understandings of the number of reference frames. >>=20 >> -since the unit 8/3 was specifically chosen to match RFC 3984's original >> values, then mismatched implementations are in fact likely. >>=20 >> If the encoder uses a larger number of reference frames than is in fact >> available, the rendered video will be corrupted. >> If the encoder uses a smaller number of reference frames, then the >> rendered video will be ok, though perhaps lower in quality than it could= be. >>=20 >> If the computed number of reference frames turns out to be less than >> what is required in the level, then some implementations might get quite >> confused (since this violates the MUST be greater than A-1). >>=20 >> Given the need to match RFC 3984 values (hence the odd units), I would >> disagree with Roni's assessment that there is no interop issue that >> results. Given the overall confusion on the unusual units, I would >> rather see this fixed sooner than later. >>=20 >> BR >> Stephen Botzko >>=20 >> On Wed, May 22, 2013 at 5:59 AM, Gonzalo Camarillo >> > >> wrote: >>=20 >> Hi Roni, >>=20 >> thanks for your response. I am actually leaning towards verifying the >> erratum, given that the wrong figures could confuse someone. >>=20 >> Cheers, >>=20 >> Gonzalo >>=20 >>=20 >> On 22/05/2013 9:54 AM, Roni Even wrote: >>> Hi, >>> In my view it will not cause any interoperability if the implementers a= re >>> looking at the ITU-H.264 reference. I assume they are looking at table = A-1 >>> in order to know the actual DPB size for the needed resolution and >>> calculating it >>> Roni >>>=20 >>>> -----Original Message----- >>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com >> ] >>>> Sent: 22 May, 2013 8:57 AM >>>> To: Mo Zanaty (mzanaty) >>>> Cc: Roni Even; payload@ietf.org ; Wang, >> Ye-Kui; 'Botzko, Stephen'; Tom >>>> Kristensen (tomkrist) >>>> Subject: Re: [payload] Errata report on RFC6184 - H.264 payload >>>>=20 >>>> Hi, >>>>=20 >>>> is this erratum likely to cause interoperability problems? We need to >> know >>>> that in order to properly handle the erratum. What is your view? >>>>=20 >>>> Note that the policy is to "verify" errata that are likely to cause >>>> interoperability problems and to "hold for document update" errata tha= t >>> are >>>> correct but are not likely to cause those types of problems. >>>>=20 >>>> Thanks, >>>>=20 >>>> Gonzalo >>>>=20 >>>> On 19/04/2013 7:35 PM, Mo Zanaty (mzanaty) wrote: >>>>> The errata looks correct. For further clarity, it may also help to ad= d >>>>> parenthesis >>>>>=20 >>>>> around (max-dpb*8/3). >>>>>=20 >>>>>=20 >>>>>=20 >>>>> NEW: >>>>>=20 >>>>> When max-dpb is signaled, the receiver MUST be able to decode >>>>>=20 >>>>> NAL unit streams that conform to the signaled highest level, >>>>>=20 >>>>> with the exception that the MaxDpbMbs value in Table A-1 of [1] >>>>>=20 >>>>> for the signaled highest level is replaced with the value of >>>>>=20 >>>>> max-dpb * 8/3. Consequently, a receiver that signals max-dpb >>>>>=20 >>>>> MUST be capable of storing the following number of decoded >>>>>=20 >>>>> frames, complementary field pairs, and non-paired fields in its >>>>>=20 >>>>> decoded picture buffer: >>>>>=20 >>>>> Min((max-dpb * 8/3) / (PicWidthInMbs * FrameHeightInMbs),16) >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Mo >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> *From:*Roni Even [mailto:ron.even.tlv@gmail.com >> ] >>>>> *Sent:* Friday, April 19, 2013 3:41 AM >>>>> *To:* payload@ietf.org >>>>> *Cc:* 'Botzko, Stephen'; Mo Zanaty (mzanaty); Wang, Ye-Kui; Tom >>>>> Kristensen (tomkrist) >>>>> *Subject:* Errata report on RFC6184 - H.264 payload >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> An errata report was filed on RFC6184 >>>>> http://www.rfc-editor.org/errata_search.php?eid=3D3318 it is given >>> bellow. >>>>>=20 >>>>> I would like to get some feedback about this errata, is it correct? >>>>>=20 >>>>> "Section 8.1 says: >>>>>=20 >>>>> On page 46 start from line 7: >>>>>=20 >>>>> "When max-dpb is signaled, the receiver MUST be able to decode >>>>>=20 >>>>> NAL unit streams that conform to the signaled highest level, >>>>>=20 >>>>> with the exception that the MaxDpbMbs value in Table A-1 of [1] >>>>>=20 >>>>> for the signaled highest level is replaced with the value of >>>>>=20 >>>>> max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb >>>>>=20 >>>>> ^^^^^ >>>>>=20 >>>>> MUST be capable of storing the following number of decoded >>>>>=20 >>>>> frames, complementary field pairs, and non-paired fields in its >>>>>=20 >>>>> decoded picture buffer: >>>>>=20 >>>>> Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), >>>>>=20 >>>>> ^^^^^ >>>>>=20 >>>>> 16)" >>>>>=20 >>>>> It should say: >>>>>=20 >>>>> When max-dpb is signaled, the receiver MUST be able to decode >>>>>=20 >>>>> NAL unit streams that conform to the signaled highest level, >>>>>=20 >>>>> with the exception that the MaxDpbMbs value in Table A-1 of [1] >>>>>=20 >>>>> for the signaled highest level is replaced with the value of >>>>>=20 >>>>> max-dpb * 8 / 3. Consequently, a receiver that signals max-dpb >>>>>=20 >>>>> ^^^^^ >>>>>=20 >>>>> MUST be capable of storing the following number of decoded >>>>>=20 >>>>> frames, complementary field pairs, and non-paired fields in its >>>>>=20 >>>>> decoded picture buffer: >>>>>=20 >>>>> Min(max-dpb * 8 / 3 / ( PicWidthInMbs * FrameHeightInMbs), >>>>>=20 >>>>> ^^^^^ >>>>>=20 >>>>> 16) >>>>>=20 >>>>> " >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> My personal view is that since MaxDpbMbs=3D max-dpb * 8 / 3 the erra= ta >>>>> is correct. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Roni Even >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> payload mailing list >>>>> payload@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/payload >>=20 >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From gonzalo.camarillo@ericsson.com Wed May 22 22:36:03 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4242111E8181 for ; Wed, 22 May 2013 22:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.002 X-Spam-Level: X-Spam-Status: No, score=-105.002 tagged_above=-999 required=5 tests=[AWL=-0.907, BAYES_00=-2.599, FRT_BELOW2=2.154, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDbBEK1wPNlM for ; Wed, 22 May 2013 22:35:58 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A37EA21F9662 for ; Wed, 22 May 2013 22:35:57 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-24-519daabca7b5 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 6E.3D.31782.CBAAD915; Thu, 23 May 2013 07:35:56 +0200 (CEST) Received: from [131.160.36.24] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Thu, 23 May 2013 07:35:56 +0200 Message-ID: <519DAABB.7000500@ericsson.com> Date: Thu, 23 May 2013 08:35:55 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Botzko, Stephen" References: <006901ce3cd1$46596c20$d30c4460$@gmail.com> <3879D71E758A7E4AA99A35DD8D41D3D90F6DA449@xmb-rcd-x14.cisco.com> <519C5E24.7030209@ericsson.com> <01ab01ce56b9$38ceab90$aa6c02b0$@gmail.com> <519C9709.3050607@ericsson.com> <01cb01ce56dc$997b1fa0$cc715ee0$@gmail.com> <519CAB25.7050902@ericsson.com> <3879D71E758A7E4AA99A35DD8D41D3D91D47AF81@xmb-rcd-x14.cisco.com> <6910FFCE-CADE-490E-A866-B16334050559@polycom.com> In-Reply-To: <6910FFCE-CADE-490E-A866-B16334050559@polycom.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM+Jvre6eVXMDDWauNbZ48WAOk8Wli2eZ LP62M1vsPbOXzeLKkV9sFk/WHGN2YPOY8nsjq8fOWXfZPZYs+cnk8eKBkseiqc8YA1ijuGxS UnMyy1KL9O0SuDJmdx9nLPjoW9F45xdTA+NS+y5GTg4JAROJzitnmSBsMYkL99azdTFycQgJ nGKUOPfvFSuEs5pR4seBAywgVbwC2hI/tn8As1kEVCV2v5/OCmKzCVhIbLl1HywuKhAlMWfd AzaIekGJkzOfgMVFBIwkPv5exgQylFngHqPEvsXfwVYLC9hLfLyymAli20tmiS+N65lBEpxA iUWrt7FC3CcpseVFOzuIzSygJzHlagsjhC0vsf3tHLB6IaDrlj9rYZnAKDQLyfJZSFpmIWlZ wMi8ipE9NzEzJ73caBMjMOQPbvmtuoPxzjmRQ4zSHCxK4ry92lMDhQTSE0tSs1NTC1KL4otK c1KLDzEycXBKNTCWSzbm7eNNizqqcFDn+eb+5xG2rUXePqKP9934dOr/9uu7TmW0d1ppOmou 0P6t9s14rmtW1JMQxoj1nZraYV+nxjSnP/p/YdqcooTm9Pq7MYc2T5TVLWquUpkclfm+e76z +9cD1zp1Orb+7c5qaZ4/b84FW38Vj8zpjCK3LnnPUd934dfm/XuVWIozEg21mIuKEwHnZaVq RwIAAA== Cc: "Wang, Ye-Kui" , "payload@ietf.org" , "Tom Kristensen \(tomkrist\)" Subject: Re: [payload] Errata report on RFC6184 - H.264 payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 05:36:03 -0000 Done! Gonzalo On 22/05/2013 7:09 PM, Botzko, Stephen wrote: > I agree that "verify" is the appropriate state. > > Stephen Botzko > > Sent from my iPad > > On May 22, 2013, at 11:12 AM, "Mo Zanaty (mzanaty)" wrote: > >> Agree to "verify" this. It can possibly (although unlikely) cause interoperability problems due to confusion about the conversion between max-dpb and MaxDpbMbs. I say "although unlikely" because max-dpb is rarely used, since the default number of reference frames (4+) in any H.264 level typically exceeds the number used in conferencing. At recent interoperability events (SIPit30, IMTC SuperOp 2013), only a single vendor was using max-dpb (and correctly). And those using it would likely be knowledgeable about its intended semantics. >> >> Mo >> >> -----Original Message----- >> From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >> Sent: Wednesday, May 22, 2013 7:25 AM >> To: Roni Even >> Cc: 'Wang, Ye-Kui'; 'Botzko, Stephen'; payload@ietf.org; Tom Kristensen (tomkrist) >> Subject: Re: [payload] Errata report on RFC6184 - H.264 payload >> >> Hi, >> >> let me clarify what we are doing here. This is the page where you can >> see all the errata related to RFC 6184: >> >> http://www.rfc-editor.org/errata_search.php?rfc=6184 >> >> As you can see, there is only one erratum and its state is "reported". >> Given that the erratum is correct, as we have already discussed, we have >> to move it to one of the following two states: verified or held for >> document update. >> >> The first state means that the erratum is correct and that implementers >> should look at it carefully. The second state means that the erratum is >> correct but that implementers do not need to pay too much attention to >> it because it is not likely to confuse them (e.g., a typo in a document >> or an error in an example). >> >> So, this is important for all implementers, old and new. >> >> Based on the discussions so far, I am going to "verify" this erratum. >> >> Cheers, >> >> Gonzalo >> >> On 22/05/2013 2:07 PM, Roni Even wrote: >>> Hi Steve, >>> >>> The fix is already there, if you go to RFC6184 you will see that it says >>> that the errata exists to fix it. >>> >>> The question is what are the implications, do you think or know (Polycom >>> systems) if existing implementations used the wrong value (3/8) in which >>> case there will be interoperability problem. >>> >>> Roni >>> >>> >>> >>> *From:*Stephen Botzko [mailto:stephen.botzko@gmail.com] >>> *Sent:* 22 May, 2013 1:49 PM >>> *To:* Gonzalo Camarillo >>> *Cc:* Roni Even; Wang, Ye-Kui; Botzko, Stephen; payload@ietf.org; Tom >>> Kristensen (tomkrist) >>> *Subject:* Re: [payload] Errata report on RFC6184 - H.264 payload >>> >>> >>> >>> Hi all >>> >>> First of all, I believe the erratum is correct. units of 8/3 means that >>> max-dpb=3 is the same as MaxDpbMbs=8. >>> >>> -if max-dbp is signalled, then that indicates that a receiver can handle >>> more reference frames than profile/level requires. >>> -if the same mistake is made in both sender and receiver, then no harm >>> is done. >>> -however, if the mistake is not consistent, then the sender and receiver >>> will have different understandings of the number of reference frames. >>> >>> -since the unit 8/3 was specifically chosen to match RFC 3984's original >>> values, then mismatched implementations are in fact likely. >>> >>> If the encoder uses a larger number of reference frames than is in fact >>> available, the rendered video will be corrupted. >>> If the encoder uses a smaller number of reference frames, then the >>> rendered video will be ok, though perhaps lower in quality than it could be. >>> >>> If the computed number of reference frames turns out to be less than >>> what is required in the level, then some implementations might get quite >>> confused (since this violates the MUST be greater than A-1). >>> >>> Given the need to match RFC 3984 values (hence the odd units), I would >>> disagree with Roni's assessment that there is no interop issue that >>> results. Given the overall confusion on the unusual units, I would >>> rather see this fixed sooner than later. >>> >>> BR >>> Stephen Botzko >>> >>> On Wed, May 22, 2013 at 5:59 AM, Gonzalo Camarillo >>> > >>> wrote: >>> >>> Hi Roni, >>> >>> thanks for your response. I am actually leaning towards verifying the >>> erratum, given that the wrong figures could confuse someone. >>> >>> Cheers, >>> >>> Gonzalo >>> >>> >>> On 22/05/2013 9:54 AM, Roni Even wrote: >>>> Hi, >>>> In my view it will not cause any interoperability if the implementers are >>>> looking at the ITU-H.264 reference. I assume they are looking at table A-1 >>>> in order to know the actual DPB size for the needed resolution and >>>> calculating it >>>> Roni >>>> >>>>> -----Original Message----- >>>>> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com >>> ] >>>>> Sent: 22 May, 2013 8:57 AM >>>>> To: Mo Zanaty (mzanaty) >>>>> Cc: Roni Even; payload@ietf.org ; Wang, >>> Ye-Kui; 'Botzko, Stephen'; Tom >>>>> Kristensen (tomkrist) >>>>> Subject: Re: [payload] Errata report on RFC6184 - H.264 payload >>>>> >>>>> Hi, >>>>> >>>>> is this erratum likely to cause interoperability problems? We need to >>> know >>>>> that in order to properly handle the erratum. What is your view? >>>>> >>>>> Note that the policy is to "verify" errata that are likely to cause >>>>> interoperability problems and to "hold for document update" errata that >>>> are >>>>> correct but are not likely to cause those types of problems. >>>>> >>>>> Thanks, >>>>> >>>>> Gonzalo >>>>> >>>>> On 19/04/2013 7:35 PM, Mo Zanaty (mzanaty) wrote: >>>>>> The errata looks correct. For further clarity, it may also help to add >>>>>> parenthesis >>>>>> >>>>>> around (max-dpb*8/3). >>>>>> >>>>>> >>>>>> >>>>>> NEW: >>>>>> >>>>>> When max-dpb is signaled, the receiver MUST be able to decode >>>>>> >>>>>> NAL unit streams that conform to the signaled highest level, >>>>>> >>>>>> with the exception that the MaxDpbMbs value in Table A-1 of [1] >>>>>> >>>>>> for the signaled highest level is replaced with the value of >>>>>> >>>>>> max-dpb * 8/3. Consequently, a receiver that signals max-dpb >>>>>> >>>>>> MUST be capable of storing the following number of decoded >>>>>> >>>>>> frames, complementary field pairs, and non-paired fields in its >>>>>> >>>>>> decoded picture buffer: >>>>>> >>>>>> Min((max-dpb * 8/3) / (PicWidthInMbs * FrameHeightInMbs),16) >>>>>> >>>>>> >>>>>> >>>>>> Mo >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:*Roni Even [mailto:ron.even.tlv@gmail.com >>> ] >>>>>> *Sent:* Friday, April 19, 2013 3:41 AM >>>>>> *To:* payload@ietf.org >>>>>> *Cc:* 'Botzko, Stephen'; Mo Zanaty (mzanaty); Wang, Ye-Kui; Tom >>>>>> Kristensen (tomkrist) >>>>>> *Subject:* Errata report on RFC6184 - H.264 payload >>>>>> >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> An errata report was filed on RFC6184 >>>>>> http://www.rfc-editor.org/errata_search.php?eid=3318 it is given >>>> bellow. >>>>>> >>>>>> I would like to get some feedback about this errata, is it correct? >>>>>> >>>>>> "Section 8.1 says: >>>>>> >>>>>> On page 46 start from line 7: >>>>>> >>>>>> "When max-dpb is signaled, the receiver MUST be able to decode >>>>>> >>>>>> NAL unit streams that conform to the signaled highest level, >>>>>> >>>>>> with the exception that the MaxDpbMbs value in Table A-1 of [1] >>>>>> >>>>>> for the signaled highest level is replaced with the value of >>>>>> >>>>>> max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb >>>>>> >>>>>> ^^^^^ >>>>>> >>>>>> MUST be capable of storing the following number of decoded >>>>>> >>>>>> frames, complementary field pairs, and non-paired fields in its >>>>>> >>>>>> decoded picture buffer: >>>>>> >>>>>> Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), >>>>>> >>>>>> ^^^^^ >>>>>> >>>>>> 16)" >>>>>> >>>>>> It should say: >>>>>> >>>>>> When max-dpb is signaled, the receiver MUST be able to decode >>>>>> >>>>>> NAL unit streams that conform to the signaled highest level, >>>>>> >>>>>> with the exception that the MaxDpbMbs value in Table A-1 of [1] >>>>>> >>>>>> for the signaled highest level is replaced with the value of >>>>>> >>>>>> max-dpb * 8 / 3. Consequently, a receiver that signals max-dpb >>>>>> >>>>>> ^^^^^ >>>>>> >>>>>> MUST be capable of storing the following number of decoded >>>>>> >>>>>> frames, complementary field pairs, and non-paired fields in its >>>>>> >>>>>> decoded picture buffer: >>>>>> >>>>>> Min(max-dpb * 8 / 3 / ( PicWidthInMbs * FrameHeightInMbs), >>>>>> >>>>>> ^^^^^ >>>>>> >>>>>> 16) >>>>>> >>>>>> " >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> My personal view is that since MaxDpbMbs= max-dpb * 8 / 3 the errata >>>>>> is correct. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Roni Even >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> payload mailing list >>>>>> payload@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/payload >>> >>> _______________________________________________ >>> payload mailing list >>> payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload From rlb@ipv.sx Tue May 28 11:34:56 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7BC921E8084 for ; Tue, 28 May 2013 11:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.423 X-Spam-Level: X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[AWL=1.553, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5P0oZGtHuW6 for ; Tue, 28 May 2013 11:34:50 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id EAB0021E8087 for ; Tue, 28 May 2013 11:34:35 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n12so10479455oag.17 for ; Tue, 28 May 2013 11:34:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=cj1aqKTFGyAsPKvjt2ffNfC4UicecMIiC3MzgfxIReU=; b=WrL3hBRXN69XMz+lR03zSVI3OSikVthWv1o35ae6v8HhLK099xbcZ1IEe1Za+6oFao JkLnnEhZjbC4yiYY0BAR6H1I53BDCeVGxIHIsaFngl96gQy5XAihRgdJ/D3I+ZrSy9Dt f+9fO1u4tOYDiKDLB+JUlnI5QxFXIiRuh6d75W9ZeJrLwI5wOp7VsX+8nUjdyRDBCJGJ 5cg8+3yCmEpLB7hp7+6nCsdqNhv2GUJc2sIbPpNrHigMQRZ7MsU7yJb839JSnYjIlQ7T t3DNBMWUOqwXmrImY3Yp2WHl1FSlsfuzOdp1HJohfaXY0OAqXvLNMLQABK74yEGAAZfg wJtA== MIME-Version: 1.0 X-Received: by 10.60.46.70 with SMTP id t6mr21819598oem.121.1369766074932; Tue, 28 May 2013 11:34:34 -0700 (PDT) Received: by 10.60.17.9 with HTTP; Tue, 28 May 2013 11:34:34 -0700 (PDT) X-Originating-IP: [192.1.51.101] In-Reply-To: <065f01ce2f22$26c76b80$74564280$@gmail.com> References: <062e01ce2f03$33956840$9ac038c0$@gmail.com> <065f01ce2f22$26c76b80$74564280$@gmail.com> Date: Tue, 28 May 2013 14:34:34 -0400 Message-ID: From: Richard Barnes To: Roni Even Content-Type: multipart/alternative; boundary=089e0149497252727704ddcb8428 X-Gm-Message-State: ALoCoQn7iWzcO+lY31hC0fsvTGlMN9D05LjbUPiT2oxSaS/x0jAjCHMAyu5tQLLfbJOVrqzVCedr Cc: draft-ietf-avt-rtp-isac@tools.ietf.org, payload@ietf.org Subject: Re: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 18:34:57 -0000 --089e0149497252727704ddcb8428 Content-Type: text/plain; charset=ISO-8859-1 Dear Authors, Any update on these issues? Thanks, --Richard On Mon, Apr 1, 2013 at 5:44 PM, Roni Even wrote: > Hi Richard,**** > > These fields are not part of the RTP header but part of the iSAC payload > header and I agree that it will be better to clarify them.**** > > Roni**** > > ** ** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* 01 April, 2013 9:47 PM > *To:* Roni Even > *Cc:* payload@ietf.org; draft-ietf-avt-rtp-isac@tools.ietf.org > *Subject:* Re: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04**** > > ** ** > > Sure. I didn't mean to imply that we need a reference to the codec, in > fact the opposite. I was looking for this document to tell me how to parse > out the fields I would feed into the black box of the codec. They describe > the fields, but it seems to me that they need more detail in order for > people to know how to parse them out of the payload.**** > > ** ** > > --Richard**** > > ** ** > > On Mon, Apr 1, 2013 at 2:03 PM, Roni Even wrote:* > *** > > Hi Richard,**** > > As a general comment, for RTP payload specifications we do not require a > normative reference to the codec. We only require enough information that > will allow an RTP receiver to parse the information and move it to the > decoder that can be a black box. This allows us to publish RTP payload > specification also for codecs whose specifications are not publically > available.**** > > Still in this case more information can be supplied.**** > > **** > > As for the comments the authors should address them**** > > **** > > Roni Even**** > > **** > > *From:* payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] *On > Behalf Of *Richard Barnes > *Sent:* 01 April, 2013 8:06 PM > *To:* payload@ietf.org > *Cc:* draft-ietf-avt-rtp-isac@tools.ietf.org > *Subject:* [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04**** > > **** > > Overall, this document looks in pretty good shape. A couple of comments I > would like to get resolved before IETF LC:**** > > **** > > Section 3.1., "Consult source code for details"**** > > If the details are only specified in the source code, then the source > needs to be a normative reference. And I would prefer to avoid that :) > Better to specify here how the BEI and FL fields are encoded. > Alternatively, if the codec really does expect a combined BEI/FL field, you > could specify such a field here, opaque to the RTP layer. However, you > would at least need to say how the recipient knows where this field starts > and stops.**** > > **** > > Section 3.2., "The length of the encoded data is variable and depends > on the signal characteristics and the target bit rate."**** > > However, there's nothing in this section that tells a recipient how to > determine what this length is. **** > > **** > > Section 3.3., "... verifying the CRC checksum ..."**** > > Please specify which CRC function is to be applied, and how the CRC value > field is formatted.**** > > **** > > Section 3.3., "If this value would exceed 255 at encoding..."**** > > It sounds like the LEN field is a single octet unsigned integer. Please > state that explicitly. **** > > **** > > Section 9.2. Informative References.**** > > Better path to source code would be "webrtc/ > modules/audio_coding/codecs/isac"**** > > **** > > Thanks,**** > > --Richard**** > > ** ** > --089e0149497252727704ddcb8428 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Authors,

Any update on these issue= s?

Thanks,
--Richard


On Mon, Apr 1, 2013 a= t 5:44 PM, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi Richard,

These fields are not part= of the RTP header but part of the iSAC payload header and I agree that it = will be better to clarify them.

Roni=

=A0

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: 01 April, 2013 9:47 PM
To: Roni Even
Cc: <= a href=3D"mailto:payload@ietf.org" target=3D"_blank">payload@ietf.org; = draft-ietf-avt-rtp-isac@tools.ietf.org
Subject: Re: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04<= /u>

= =A0

Sure. I didn't mean to imply that = we need a reference to the codec, in fact the opposite. =A0I was looking fo= r this document to tell me how to parse out the fields I would feed into th= e black box of the codec. =A0They describe the fields, but it seems to me t= hat they need more detail in order for people to know how to parse them out= of the payload.

=A0

--Richard

=A0

= On Mon, Apr 1, 2013 at 2:03 PM, Roni Even <ron.even.tlv@gmail.com> wrote:=

Hi Richard,

As a= general comment, for RTP payload specifications we do not require a normat= ive reference to the codec. We only require enough information that will al= low an RTP receiver to parse the information and move it to the decoder tha= t can be a black box. This allows us to publish RTP payload specification a= lso for codecs whose specifications are not publically available.=

Still in this case more i= nformation can be supplied.

= =A0

As for the comments the a= uthors should address them

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">=A0

Roni Even

=A0

From: payload-bounces@ietf= .org [mailto:payload-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: 01 April, 2013 8:06 PM
To: payload@ietf.org
Cc: draft-ietf= -avt-rtp-isac@tools.ietf.org
Subject: [payload] AD Evaluation: draft-ietf-avt-rtp-isac-04<= u>

=A0

Overall, this document looks in pretty good shape. =A0A = couple of comments I would like to get resolved before IETF LC:

=A0

Section 3.1., "Consult source code for details"=

If the details are only specified= in the source code, then the source needs to be a normative reference. =A0= And I would prefer to avoid that =A0:) =A0Better to specify here how the BE= I and FL fields are encoded. =A0 Alternatively, if the codec really does ex= pect a combined BEI/FL field, you could specify such a field here, opaque t= o the RTP layer. =A0However, you would at least need to say how the recipie= nt knows where this field starts and stops.

=A0

Section 3.2., "The len= gth of the encoded data is variable and depends on=A0the signal characteris= tics and the target bit rate."

However, there's nothing in this sect= ion that tells a recipient how to determine what this length is. =A0=

=A0

Section 3.3., "...=A0verifying the CR= C checksum ..."

Please specify which CRC function is to be applied, and how the CRC val= ue field is formatted.

=A0

Section 3.3., "If this= value would exceed 255 at encoding..."

=

It sounds like the LEN field is a single octet unsig= ned integer. =A0Please state that explicitly.=A0

=A0

Section 9.2. Informative References.

Better path to source code would be "= ;webrtc/modules/audio_coding/codecs/isac&q= uot;

=A0

Thanks,<= /span>

--Richard

<= /div>

=A0

<= /div>

--089e0149497252727704ddcb8428--