From James.Barrett@bbc.co.uk Fri Aug 14 04:01:09 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52F11A1B60 for ; Fri, 14 Aug 2015 04:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6auA40X2HNMY for ; Fri, 14 Aug 2015 04:01:08 -0700 (PDT) Received: from mailout0.thls.bbc.co.uk (mailout0.thls.bbc.co.uk [132.185.240.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229351A1B4A for ; Fri, 14 Aug 2015 04:01:07 -0700 (PDT) Received: from BGB01XI1007.national.core.bbc.co.uk (bgb01xi1007.national.core.bbc.co.uk [10.161.14.21]) by mailout0.thls.bbc.co.uk (8.14.4/8.14.3) with ESMTP id t7EB13Wm000472 for ; Fri, 14 Aug 2015 12:01:03 +0100 (BST) Received: from BGB01XUD1007.national.core.bbc.co.uk ([10.161.14.5]) by BGB01XI1007.national.core.bbc.co.uk ([10.161.14.21]) with mapi id 14.03.0195.001; Fri, 14 Aug 2015 12:01:02 +0100 From: James Barrett To: "payload@ietf.org" Thread-Topic: New Version Notification for draft-weaver-payload-rtp-vc2hq-00.txt Thread-Index: AQHQ1n6nfdCHR7pSHkuJMfVDXMRzdA== Date: Fri, 14 Aug 2015 11:01:01 +0000 Message-ID: <1EA43377-310D-4D59-940B-2024D22899B0@bbc.co.uk> References: <20150814104615.17210.86604.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.10.48.249] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 Content-Type: text/plain; charset="utf-8" Content-ID: <3537AF734366E647A2DC1FB06B1D7BC6@bbc.co.uk> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 14 Aug 2015 04:32:22 -0700 Subject: [payload] Fwd: New Version Notification for draft-weaver-payload-rtp-vc2hq-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 11:07:06 -0000 SSB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgdGhhdCB0aGlzIGRyYWZ0ICJSVFAgUGF5bG9hZCBGb3Jt YXQgZm9yIFZDLTIgSFEgUHJvZmlsZSBWaWRlb+KAnSBiZSByZXZpZXdlZCBieSB0aGUgd29ya2lu ZyBncm91cC4NCg0KSW4gZm9ybWF0dGluZyBpdCBJIGhhdmUgbWFkZSB1c2Ugb2YgdGhlIHRlbXBs YXRlIGluIGRyYWZ0LWlldGYtcGF5bG9hZC1ydHAtaG93dG8tMTQgYW5kIGhhdmUgYXR0ZW1wdGVk IHRvIGZvbGxvdyB0aGUgZ3VpZGVsaW5lcyBpbiB0aGF0IGRvY3VtZW50Lg0KLS0NCkphbWVzIFAu IFdlYXZlciAobsOpIEJhcnJldHQpDQpSZXNlYXJjaCBFbmdpbmVlcg0KQkJDIFImRCBOb3J0aCBM YWIsDQpGbG9vciA1IERvY2sgSG91c2UsIE1lZGlhQ2l0eSwNCk01MCAyTEgNClRlbDogKzQ0KDAp MzAgMzA0MC05NTIxDQplLW1haWw6IGphbWVzLmJhcnJldHRAYmJjLmNvLnVrDQoNCkJlZ2luIGZv cndhcmRlZCBtZXNzYWdlOg0KDQpGcm9tOiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KU3Vi amVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13ZWF2ZXItcGF5bG9hZC1y dHAtdmMyaHEtMDAudHh0DQpEYXRlOiAxNCBBdWd1c3QgMjAxNSAxMTo0NjoxNSBCU1QNClRvOiAi SmFtZXMgUC4gV2VhdmVyIiA8amFtZXMuYmFycmV0dEBiYmMuY28udWs+LCAiSmFtZXMgUC4gV2Vh dmVyIiA8amFtZXMuYmFycmV0dEBiYmMuY28udWs+DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQs IGRyYWZ0LXdlYXZlci1wYXlsb2FkLXJ0cC12YzJocS0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgSmFtZXMgUC4gV2VhdmVyIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRG IHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC13ZWF2ZXItcGF5bG9hZC1ydHAtdmMyaHENClJl dmlzaW9uOgkwMA0KVGl0bGU6CQlSVFAgUGF5bG9hZCBGb3JtYXQgZm9yIFZDLTIgSFEgUHJvZmls ZSBWaWRlbw0KRG9jdW1lbnQgZGF0ZToJMjAxNS0wOC0xNA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NClBhZ2VzOgkJMTYNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd2VhdmVyLXBheWxvYWQtcnRwLXZjMmhxLTAwLnR4dA0K U3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdl YXZlci1wYXlsb2FkLXJ0cC12YzJocS8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtd2VhdmVyLXBheWxvYWQtcnRwLXZjMmhxLTAwDQoNCg0KQWJzdHJh Y3Q6DQogIFRoaXMgbWVtbyBkZXNjcmliZXMgYW4gUlRQIFBheWxvYWQgZm9ybWF0IGZvciB0aGUg SGlnaCBRdWFsaXR5IChIUSkNCiAgcHJvZmlsZSBvZiBTTVBURSBTdGFuZGFyZCBTVCAyMDQyLTEg a25vd24gYXMgVkMtMi4gIFRoaXMgZG9jdW1lbnQNCiAgZGVzY3JpYmVzIHRoZSB0cmFuc3BvcnQg b2YgSFEgUHJvZmlsZSBWQy0yIGluIFJUUCBwYWNrZXRzIGFuZCBoYXMNCiAgYXBwbGljYXRpb25z IGZvciBsb3ctY29tcGxleGl0eSwgaGlnaC1iYW5kd2lkdGggc3RyZWFtaW5nIG9mIGJvdGgNCiAg bG9zc2xlc3MgYW5kIGxvc3N5IGNvbXByZXNzZWQgdmlkZW8uDQoNCiAgVGhlIEhRIHByb2ZpbGUg b2YgVkMtMiBpcyBpbnRlbmRlZCBmb3IgbG93IGxhdGVuY3kgdmlkZW8gY29tcHJlc3Npb24NCiAg KHdpdGggbGF0ZW5jeSBwb3RlbnRpYWxseSBvbiB0aGUgb3JkZXIgb2YgbGluZXMgb2YgdmlkZW8p IGF0IGhpZ2gNCiAgZGF0YSByYXRlcyAod2l0aCBjb21wcmVzc2lvbiByYXRpb3Mgb24gdGhlIG9y ZGVyIG9mIDI6MSBvciA0OjEpLg0KDQoNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg== From nobody Fri Aug 14 07:46:45 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCFA1A3B9B for ; Fri, 14 Aug 2015 07:46:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHUDbAXnA-RT for ; Fri, 14 Aug 2015 07:46:42 -0700 (PDT) Received: from mx0b-00195501.pphosted.com (mx0b-00195501.pphosted.com [67.231.157.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E657E1A21BF for ; Fri, 14 Aug 2015 07:46:41 -0700 (PDT) Received: from pps.filterd (m0072276.ppops.net [127.0.0.1]) by mx0b-00195501.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t7EEfZ2R014788 for ; Fri, 14 Aug 2015 07:46:41 -0700 Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0145.outbound.protection.outlook.com [207.46.163.145]) by mx0b-00195501.pphosted.com with ESMTP id 1w9hm3079p-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 14 Aug 2015 07:46:40 -0700 Received: from BLUPR05MB657.namprd05.prod.outlook.com (10.141.205.142) by BLUPR05MB450.namprd05.prod.outlook.com (10.141.28.19) with Microsoft SMTP Server (TLS) id 15.1.231.21; Fri, 14 Aug 2015 14:46:40 +0000 Received: from BLUPR05MB659.namprd05.prod.outlook.com (10.141.205.144) by BLUPR05MB657.namprd05.prod.outlook.com (10.141.205.142) with Microsoft SMTP Server (TLS) id 15.1.231.21; Fri, 14 Aug 2015 14:46:38 +0000 Received: from BLUPR05MB659.namprd05.prod.outlook.com ([10.141.205.144]) by BLUPR05MB659.namprd05.prod.outlook.com ([10.141.205.144]) with mapi id 15.01.0225.018; Fri, 14 Aug 2015 14:46:38 +0000 From: Thomas Edwards To: "payload@ietf.org" Thread-Topic: [payload] Fwd: New Version Notification for draft-weaver-payload-rtp-vc2hq-00.txt Thread-Index: AQHQ1qAG6kyyG0Ge0U6BTwn9MOEznw== Date: Fri, 14 Aug 2015 14:46:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Edwards@fox.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [104.173.233.221] x-microsoft-exchange-diagnostics: 1; BLUPR05MB657; 5:54GQXziinDJ8TNog6JkJlNV89/YqLy7S2j7Tbo6/8u3FhUolz/kTL19v0KDB3NTcccL7OniC7lPEj4M3kEspuLKkAYFVy95kcB5DxXZIM4l0DOZ13kqBOfCIMCVcJ4g4eaqLm2eg6ISsDoctM5h6ng==; 24:ANqpSL+/Rvcc5nnhb0xrIfdCsSNzuak1M3lWxCcf7yqgN7DMhrw82W0gZtzehv06D9fEuE0DP/bibRU7u9cyPxxOEgN6rfcKkQGSJztAonQ=; 20:FewsY6FKh2z9bf5HEBTHrrbaH33h+RiMd1JqYEQi7gYVI4vNV/LEQBx8baQQPtCYhhgEsaET0mziT3P5HlywZA== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB657; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB450; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB657; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB657; x-forefront-prvs: 066898046A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(189002)(377424004)(479174004)(252514010)(377454003)(199003)(2473001)(450100001)(86362001)(122556002)(575784001)(10400500002)(66066001)(64706001)(68736005)(15975445007)(62966003)(77096005)(77156002)(106116001)(106356001)(105586002)(19580405001)(99286002)(40100003)(102836002)(2501003)(2900100001)(2656002)(83506001)(92566002)(87936001)(110136002)(50986999)(5001920100001)(54356999)(4001540100001)(5001860100001)(4001350100001)(97736004)(189998001)(5001960100002)(107886002)(19580395003)(5001830100001)(36756003)(81156007)(5002640100001)(46102003)(2351001)(230783001)(101416001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB657; H:BLUPR05MB659.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fox.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7E6C3005682B2249852BA30213360E08@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2015 14:46:38.6089 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: de99ade3-81db-4070-ae0d-3c1562041b30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB657 X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB450; 2:wPA+QlC3G5Y0wLH/wesqJWNc9IaKhslRzV/J7+pdCfODs0HdNNXbfj66vm/CfLAKvC7FhBXgYh+DF10n37/34aPKu565B+E/Dv9CzMSQqjlAaeYGs6N3WMyh1reVv6YqM4o8otadgwb3DS7QUksu5wUa7PDLyYMmCNgCcnQH8PQ=; 3:QRRskFl/K5fpeJmjvpjUW3iPRQCDAfIiYUAxSEekPI1e5RUloR77wUnSwwLlQMh8yHByzefa2c2T9NpKqXcmSfnNia2sQvHtx1PYZDzqFy/C+7uCxkRtFyw6dm+UCkg+y6IeXbiof1BqycFK+Xm5AQ==; 25:E7ScGHDS5ssOUHICjw4QXeSjzsK8lIylvjoybDg+KF2JeOu8FL8CIdJmfpZ8o9dN6b5M+7zKhBwk4/gnIh4Vo8XJxCFYDivj/QC35hynQUa45pJZ3oltsJJZAh+7NklLf7x1UIWNmrWJEnq5drfKRBrvVPzoLcKCUjMMinwY/fHoZsQPZeOy19pVx3bvH1mgH/K5lxBGaM5nYzQl83GtiXe/pwDLwk44wOj28HG6GJ94qIUhlwdPfOMRzTj5u8uV3DAjxAfO3/yO0xGYX5RjEw==; 23:82bPgceoBqCg1BEMLpOZM+FJW+i3fTuJMD0tgS0V6hs5tiZW7gm/ehMhEvWQBFHXfLMAKvD1x9+uI7U4QGT4LqMInyRpN4RrA9OPMz/p7p3NCEJI1PRA2QQY4mIKWYfAd46lwsWvJMFlAHj3Wd+qd7uUwRESLQnivqyFnBKC4Ln8wX4W87s8/aD2A3ztUCxK X-OriginatorOrg: fox.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-08-14_06:2015-08-13,2015-08-14,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1508140210 Archived-At: Subject: Re: [payload] Fwd: New Version Notification for draft-weaver-payload-rtp-vc2hq-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 14:46:43 -0000 I support the adoption of the VC-2 RTP Payload Format work by the payload group. My first comment is that the title should be changed to "RTP Payload Format for SMPTE VC-2 HQ Profile Video." -Thomas --=20 Thomas Edwards=09 VP Engineering & Development FOX Networks Engineering and Operations thomas.edwards@fox.com Phone: +1.310.369.6696 10201 West Pico Blvd. Los Angeles, CA 90035 On 8/14/15, 4:01 AM, "James Barrett" wrote: >I would like to request that this draft "RTP Payload Format for VC-2 HQ >Profile Video=B2 be reviewed by the working group. > > > >In formatting it I have made use of the template in >draft-ietf-payload-rtp-howto-14 and have attempted to follow the >guidelines in that document. > >-- > >James P. Weaver (n=E9 Barrett) > >Research Engineer > >BBC R&D North Lab, > >Floor 5 Dock House, MediaCity, > >M50 2LH > >Tel: +44(0)30 3040-9521 > >e-mail: james.barrett@bbc.co.uk > > > >Begin forwarded message: > > > >From: > >Subject: New Version Notification for >draft-weaver-payload-rtp-vc2hq-00.txt > >Date: 14 August 2015 11:46:15 BST > >To: "James P. Weaver" , "James P. Weaver" > > > > > > >A new version of I-D, draft-weaver-payload-rtp-vc2hq-00.txt > >has been successfully submitted by James P. Weaver and posted to the > >IETF repository. > > > >Name: draft-weaver-payload-rtp-vc2hq > >Revision: 00 > >Title: RTP Payload Format for VC-2 HQ Profile Video > >Document date: 2015-08-14 > >Group: Individual Submission > >Pages: 16 > >URL: =20 >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_intern= et >-2Ddrafts_draft-2Dweaver-2Dpayload-2Drtp-2Dvc2hq-2D00.txt&d=3DAwIGaQ&c=3Du= w6TL >u4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoL= EH >gd0quQxly8&m=3Dgy34t4t-CjGI8OnkES2XOexlx1HXk2y1sbDXkuAYM_U&s=3D_xh9-gXNARM= KNCl >LN1CZk0ZCyKQeV5iI1-1omXmSRIY&e=3D > >Status: =20 >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.or= g_ >doc_draft-2Dweaver-2Dpayload-2Drtp-2Dvc2hq_&d=3DAwIGaQ&c=3Duw6TLu4hwhHdiGJ= Ogwc >WD4AjKQx6zvFcGEsbfiY9-EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m= =3Dg >y34t4t-CjGI8OnkES2XOexlx1HXk2y1sbDXkuAYM_U&s=3DpnvEHvdn_GaX3iCL1evQTt2DLGk= Jf >H9QlUMbNiH9kco&e=3D=20 > >Htmlized: =20 >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html= _d >raft-2Dweaver-2Dpayload-2Drtp-2Dvc2hq-2D00&d=3DAwIGaQ&c=3Duw6TLu4hwhHdiGJO= gwcW >D4AjKQx6zvFcGEsbfiY9-EI&r=3DlekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m= =3Dgy >34t4t-CjGI8OnkES2XOexlx1HXk2y1sbDXkuAYM_U&s=3DJGIpf83ZX0sZ0By5XWXphhydNrKR= Vu >DzjRrGxqte900&e=3D=20 > > > > > >Abstract: > > This memo describes an RTP Payload format for the High Quality (HQ) > > profile of SMPTE Standard ST 2042-1 known as VC-2. This document > > describes the transport of HQ Profile VC-2 in RTP packets and has > > applications for low-complexity, high-bandwidth streaming of both > > lossless and lossy compressed video. > > > > The HQ profile of VC-2 is intended for low latency video compression > > (with latency potentially on the order of lines of video) at high > > data rates (with compression ratios on the order of 2:1 or 4:1). > > > > > > > > > >Please note that it may take a couple of minutes from the time of >submission > >until the htmlized version and diff are available at >https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__tools.ietf.org&d=3DA= wIGa >Q&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=3DlekNOOM5noV61zrPH3rw= Pyht >NnLLWoLEHgd0quQxly8&m=3Dgy34t4t-CjGI8OnkES2XOexlx1HXk2y1sbDXkuAYM_U&s=3DPZ= Rii6 >BNVZui0AWzAZ-KWwJWU-m025BKejGDIlUpUnI&e=3D . > > > >The IETF Secretariat > > > > > >_______________________________________________ >payload mailing list >payload@ietf.org >https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_ >listinfo_payload&d=3DAwIGaQ&c=3Duw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-E= I&r=3D >lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=3Dgy34t4t-CjGI8OnkES2XOexlx1= HX >k2y1sbDXkuAYM_U&s=3DYCaHDigHAxAdC3eplqjTtVFhSV6jZ71edg_vdDbq04w&e=3D=20 From nobody Mon Aug 24 14:22:24 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E079B1B137B; Mon, 24 Aug 2015 14:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.589 X-Spam-Level: X-Spam-Status: No, score=0.589 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_26=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnzRkv01kVqr; Mon, 24 Aug 2015 14:22:20 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A6B1ACD82; Mon, 24 Aug 2015 14:22:17 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7OLLrq1082754 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 24 Aug 2015 16:22:04 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Harald Alvestrand" Date: Mon, 24 Aug 2015 16:21:53 -0500 Message-ID: <73A192FD-294B-4D94-8B27-75E7CF835E58@nostrum.com> In-Reply-To: <55B9DCCE.1050902@alvestrand.no> References: <55A3A7F1.8010109@dial.pipex.com> <55B9DCCE.1050902@alvestrand.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: draft-ietf-payload-vp8.all@ietf.org, Elwyn Davies , payload-chairs@ietf.org, payload@ietf.org Subject: Re: [payload] Gen-art 2nd LC review of draft-ietf-payload-vp8-16 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 21:22:23 -0000 (- GenART and IETF lists) Hi Harald, Any updates? Thanks! Ben. On 30 Jul 2015, at 3:14, Harald Alvestrand wrote: > Unfortunately this is vacation time in Scandinavia - won't do anything > with this until mid-August, I'm afraid. (Henrik might.) > > So it'll have to wait another 2 telechats or so..... > > > On 07/29/2015 11:58 PM, Ben Campbell wrote: >> Hi VP8 Authors: >> >> Has there been a response to Elwyn's Gen-ART review from the authors? >> If so, I haven't seen it. (I did see Colin's response). >> >> Based Elwyn's review, and on Harald's response to my earlier >> questions, I assume that the authors will wish to update the draft >> before it goes back to an IESG telechat. If that's not the case, >> please let me know. Please be advised that tomorrow (July 30) is the >> nominal deadline for getting things on the August 6 telechat. >> >> Thanks! >> >> Ben. >> >> >> On 13 Jul 2015, at 15:57, Ben Campbell wrote: >> >>> (+payload and Harald) >>> >>> Elwyn: Thanks for the detailed review! >>> >>> Authors: Please address Elwyn's comments at your earliest >>> convenience. There's quite a bit here, and I assume we will need a >>> new revision before taking this to the IESG telechat, but it would be >>> helpful to discuss any proposed changes via email before submitting. >>> >>> Thanks! >>> >>> Ben. >>> >>> >>> On 13 Jul 2015, at 6:58, Elwyn Davies wrote: >>> >>>> I am the assigned Gen-ART reviewer for this draft. For background on >>>> Gen-ART, please see the FAQ at >>>> >>>> . >>>> >>>> Please resolve these comments along with any other Last Call comments >>>> you may receive. >>>> >>>> Document: draft-ietf-payload-vp8-16.txt >>>> Reviewer: Elwyn Davies >>>> Review Date: 2015/07/10 >>>> IETF LC End Date: 2015/07/13 >>>> IESG Telechat date: (if known) - >>>> >>>> Summary: Gosh, it has been a long time since the last review! >>>> >>>> Major issues: >>>> >>>> Minor issues: >>>> s4.2: Various of the frame indices either SHOULD or, in the case of >>>> KEYIDX, MAY start at random values. The rationale(s) for these >>>> requirements are not explained - nor is the reason why it it is only a >>>> MAY for KEYIDX whereas it is SHOULD for PictureID and what might happen >>>> were the MAY/SHOULD to be ignored. >>>> >>>> Is the rationale something that should be mentioned in the security >>>> considerations? >>>> >>>> s10.1: The downref to RFC 6386 identified by idnits was duly noted >>>> in the last call >>>> announcement. I don't have a problem with the downref. >>>> >>>> Nits/editorial comments: >>>> >>>> General: Consistent usage of "prediction and mode" vs >>>> "prediction/mode" would be desirable. >>>> >>>> s1, para 2: Needs to introduce the 'macroblock' jargon defined in >>>> RFC 6386. Suggest: >>>> OLD: >>>> VP8 is based on decomposition of frames into square sub-blocks of >>>> pixels, prediction of such sub-blocks using previously constructed >>>> blocks, and... >>>> NEW: >>>> VP8 is based on decomposition of frames into square sub-blocks of >>>> pixels known as "macroblocks" (see Section 2 of [RFC6386]). Prediction >>>> of such sub-blocks using previously constructed blocks, and... >>>> END >>>> >>>> s2: There are a number of technical terms brought over from RFC 6386. >>>> These should be listed in s2. At least the following would be in >>>> the list: >>>> key frame, interframe, golden frame, altref frame, macroblock. >>>> Also the terms picture selection index (RPSI) and slice loss >>>> indication (SLI) from RFC 4585. >>>> >>>> s3, para 2: Providing a reference to explain what temporal scalability >>>> and the hierarchy selection is all about would be useful. One >>>> possibility >>>> would be: >>>> >>>> Lim, J. Yang, and B. Jeon,”Fast Coding Mode Decision for Scalable >>>> Video Coding”, >>>> 10th Int’l Conf. on Advanced Communication Technology, vol. 3, pp. >>>> 1897-1900, 2008. >>>> >>>> It would also help to add a pointer to the TL0PICIDX description in >>>> s4.2, thus: >>>> ADD: >>>> Support for temporal scalability is provided by the optional >>>> TL0PICIDX and TID/Y/KEYIDX >>>> fields described in Section 4.2. >>>> END >>>> >>>> ss3 and 4: The discussion of how the frame payload might or might >>>> not be distributed across >>>> multiple packets is not very clear. The draft has in mind a >>>> 'preferred use case' (para 1 >>>> of s4.4 says: >>>> >>>>> In the preferred use case, the S bit and PID fields >>>>> described in Section 4.2 should be used to indicate what the packet >>>>> contains. >>>> >>>> I think it would be helpful to be a bit more positive about this in >>>> s3, para 3: >>>> OLD: >>>> This memo >>>> allows the partitions to be sent separately or in the same RTP >>>> packet. It may be beneficial for decoder error-concealment to send >>>> the partitions in different packets, even though it is not mandatory >>>> according to this specification. >>>> NEW: >>>> Accordingly, this document RECOMMENDS that the frame is packetized >>>> by the sender >>>> with each data partition in a separate packet or packets. This may >>>> be beneficial >>>> for decoder error concealment and the payload format described in >>>> Section 4 provides >>>> fields that allow the partitions to be identified even if the first >>>> partition is >>>> not available. The sender can, alternatively, aggregate the data >>>> partitions into >>>> a single data stream and, optionally, split it into several packets >>>> without >>>> consideration of the partition boundaries. The receiver can use the >>>> length >>>> information in the first partition to identify the partitions during >>>> decoding. >>>> END >>>> >>>> s4/Figure 1: s/bytes/octets/ (2 places) >>>> >>>> Figure 1, caption: s/sequel/Sections 4.2 and 4.3/ >>>> >>>> Figure 1: The format shown is correct only for the first packet in a >>>> frame. Subsequent >>>> packets will not contain the payload header and will have later >>>> octets of the frame payload. >>>> This should be mentioned in drawing and/or in the caption. >>>> >>>> s4.1, last two paras: >>>>> Sequence number: The sequence numbers are monotonically increasing >>>>> and set as packets are sent. >>>>> >>>>> The remaining RTP header fields are used as specified in >>>>> [RFC3550]. >>>> Redefining the Sequence Number field seems gratuitous and >>>> potentially dangerous, >>>> given that it is *very carefully* defined in RFC 3550 and the >>>> overall intent does >>>> not seem any different from that in RFC 3550. OTOH a note about the >>>> (non?-)use of the X bit >>>> and the Payload Type field (PT) would be useful. I suggest >>>> replacing the paras above with: >>>> NEW: >>>> X bit: MUST be 0. The VP8 RTP profile does not use the RTP Header >>>> Extension capability. >>>> >>>> PT (Payload Type): In line with the policy in Section 3 of >>>> [RFC3551], applications >>>> using the VP8 RTP payload profile MUST assign a dynamic payload type >>>> number to >>>> be used in each RTP session and provide a mechanism to indicate the >>>> mapping. >>>> See Section 6.2 for the mechanism to be used with the Session >>>> Description Protocol (SDP) >>>> [RFC4566]. >>>> >>>> The remaining RTP Fixed Header Fields (V, P, CC, sequence number, >>>> SSRC and CSRC >>>> identfiers) are used as specified in Section 5.1 of [RFC5330]. >>>> END >>>> Note that this may be considered to make the reference to RFC 3551 >>>> normative. >>>> >>>> s4.2, X bit: There is potential for confusion between the X bit in >>>> the fixed header >>>> and the X bit in the VP8 Payload Descriptor. Perhaps changing this >>>> to C for control bits >>>> would avoid the problem. >>>> >>>> s4.2, M bit: Similarly, it might be better to use B (for BIG) in >>>> place of M to avoid confusion. >>>> >>>> s4.2, para 7 after Fig 2: For consistency: >>>> OLD: >>>> When the X bit is set to 1 in the first octet, the extension bit >>>> field octet MUST be provided as the second octet. If the X bit is 0, >>>> the extension bit field octet MUST NOT be present, and no extensions >>>> (I, L, T, or K) are permitted. >>>> NEW: >>>> When the X [or C] bit is set to 1 in the first octet, the Extended >>>> Control Bits >>>> field octet MUST be provided as the second octet. If the X [or C] >>>> bit is 0, >>>> the extension bit field octet MUST NOT be present, and no extensions >>>> (I, L, T, or K) are permitted. >>>> END >>>> >>>> s4.2: The issue of using either 'wrap' or 'restart' but not both for >>>> restarting number sequences has been raised in various comments by >>>> IESG members. >>>> >>>> s4.2, TL0PICIDX: I think, given the statements in s3 about not >>>> defining the hierarchy, that more explanation is needed of what the >>>> 'lowest or base layer' actually means. >>>> >>>> s4.2, TL0PICIDX: >>>>> If TID is larger than 0, TL0PICIDX >>>>> indicates which base layer frame the current image depends on. >>>>> TL0PICIDX MUST be incremented when TID is 0. >>>> What happens if L=1 but both T=0 and K=0 so that there is no TID >>>> value present? Or indeed if T=0 but K=1 so that the TID field is >>>> there but 'MUST be ignored by the receiver' (definition of TID field)? >>>> >>>> s4.3: It would be useful to include the section number (9.1) where >>>> the uncompressed data chunk specification is found. I was somewhat >>>> surprised that the ordering is reversed in the protocol spec. >>>> >>>> s4.3, VER: The receiver should validate this field - currently only >>>> values 0-3 are valid. >>>> >>>> s4.3, SizeN: Make it clear these are integer fields: s/in Size0,/in >>>> integer fields Size0,/ >>>> >>>> s4.3 and s4.4: It would be helpful to implementers to explain what >>>> the offsets in the first partition payload are for the additional >>>> partition count and additional partition sizes. Having rummaged >>>> around in RFC 6386, I have to say that I am unclear whether the >>>> values are placed after the full chunk of data indicated by >>>> 1stPartitionSize or are part of this data. And if the latter is the >>>> case, how to work out where the partition sizes are. I guess that >>>> they ought to be at offset (1stPartitionSize+10 - key frame - or >>>> 1stPartitionSize+3 - interframe) in the VP8 Payload field as it is >>>> difficult to work out where they are without decoding the partition >>>> otherwise. Also exactly how many partition sizes to expect - I >>>> think I read in RFC 6386 that the last partition size is implicit. >>>> Help! >>>> >>>> In the course of clearing this up, it might be appropriate to move >>>> the last sentence of the first para of s4.4 and the second para of >>>> s4.4 into s4.3 as part of the explanation. This is the relevant text: >>>>> Note that the length of the first partition can >>>>> always be obtained from the first partition size parameter in the VP8 >>>>> payload header. >>>>> >>>>> The VP8 bitstream format [RFC6386] specifies that if multiple DCT/WHT >>>>> partitions are produced, the location of each partition start is >>>>> found at the end of the first (prediction/mode) partition. In this >>>>> RTP payload specification, the location offsets are considered to be >>>>> part of the first partition. >>>> >>>> >>>> s4.4: I found this section very difficult to parse. It is a bit >>>> 'stream of consciousness' and would benefit from a reordering and >>>> rewrite. Suggestion (assuming the second para gets moved to s4.3): >>>> NEW SECTION 4.4: >>>> An encoded VP8 frame can be divided into two or more partitions, as >>>> described in Section 1. It is OPTIONAL for a packetizer implementing >>>> this RTP specification >>>> to pay attention to the partition boundaries within an encoded frame. >>>> If packetization of a frame is done without considering the partition >>>> boundaries, the PID field MAY be set to zero for all packets, and the >>>> S bit MUST NOT be set to one for any other packet than the first. >>>> >>>> If the preferred usage suggested in Section 3 is followed, with each >>>> packet >>>> carrying data from exactly one partition, the S bit and PID fields >>>> described in Section 4.2 SHOULD be used to indicate what the packet >>>> contains. The PID field should indicate which partition the first >>>> octet of the payload belongs to, and the S bit indicates that the >>>> packet starts on a new partition. >>>> >>>> If the packetizer does not pay attention to the partition >>>> boundaries, one >>>> packet can contain a fragment of a partition, a complete partition, >>>> or an >>>> aggregate of fragments and partitions. There is no explicit >>>> signaling of >>>> partition boundaries in the payload and the partition lengths at the >>>> end of >>>> the first partition have to be used to identify the boundaries. >>>> Partitions >>>> MUST be aggregated in decoding order. Two fragments from different >>>> partitions MAY be aggregated into the same packet along with one or >>>> more >>>> complete partitions. >>>> >>>> In all cases, the payload of a packet MUST contain data from only >>>> one video >>>> frame. Consequently the set of packets carrying the data from a >>>> particular >>>> frame will contain exactly one VP8 Payload Header (see Section 4.3) >>>> carried >>>> in the first packet of the frame. The last, or only, packet >>>> carrying data for the >>>> frame MUST have the M bit set in the RTP header. >>>> >>>> s4.5.1: Th algorithm only applies for the RECOMMENDED use case with >>>> partitions in separate packets. >>>> This should be noted. >>>> >>>> s5.2, last para: s/only parts of the frame is corrupted./only part >>>> of the frame is corrupted./ >>>> >>>> s6: s/This payload format has two required parameters./This payload >>>> format has two optional parameters./ >>>> [I think this is probably a hangover from the previous version.] >>>> >>>> s7: s/Cryptographic system may also allow/The cryptographic system >>>> may also allow/ >>>> >>>> s7: >>>>> the usage of SRTP [RFC3711] is recommended. >>>> RECOMMENDED? >>>> >>>> s10.2: I suspect that RFC 3551 is normative. > > > -- > Surveillance is pervasive. Go Dark. From nobody Mon Aug 24 18:44:47 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2661ACEA5; Mon, 24 Aug 2015 18:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIQyRyar6WL0; Mon, 24 Aug 2015 18:44:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0702B1ACEAB; Mon, 24 Aug 2015 18:44:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150825014443.11024.77662.idtracker@ietfa.amsl.com> Date: Mon, 24 Aug 2015 18:44:43 -0700 Archived-At: Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-14.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 01:44:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for H.265/HEVC Video Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-14.txt Pages : 99 Date : 2015-08-24 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. When multiple RTP streams are used, a single or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-h265-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 24 18:52:38 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9351ACE1E for ; Mon, 24 Aug 2015 18:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cb0O_nypPofb for ; Mon, 24 Aug 2015 18:52:35 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAA461A1DBE for ; Mon, 24 Aug 2015 18:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1440467555; x=1472003555; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hUK7vXQrlg9Cc5fUgl+gyjmSGJagLGi6nBurK/9fbu4=; b=dfVhc4GCUEouXceeXapg+IIkfBy7qsP2cvI2BzdaUDHEvYvjDF1JUELx io6ztl1eHDKEzeXmNS00uwAIJrfwpp8duRroX+cKxRawjL4XcwW9uDssM SYoz8eAZaM92lYRZIuB/NkOb+eqDmubdCC1u8hAXhbDQQPzwlZ1EK3EGh A=; X-IronPort-AV: E=McAfee;i="5700,7163,7903"; a="227668431" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by wolverine02.qualcomm.com with ESMTP; 24 Aug 2015 18:52:35 -0700 X-IronPort-AV: E=Sophos;i="5.15,743,1432623600"; d="scan'208";a="33491984" Received: from nalasexr01e.na.qualcomm.com ([10.49.56.51]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 24 Aug 2015 18:52:34 -0700 Received: from NALASEXR01H.na.qualcomm.com (10.49.56.54) by nalasexr01e.na.qualcomm.com (10.49.56.51) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 24 Aug 2015 18:52:34 -0700 Received: from NALASEXR01H.na.qualcomm.com ([10.49.56.54]) by NALASEXR01H.na.qualcomm.com ([10.49.56.54]) with mapi id 15.00.1076.010; Mon, 24 Aug 2015 18:52:34 -0700 From: "Wang, Ye-Kui" To: "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-h265-14.txt Thread-Index: AQHQ3texjFaUSu2fzUCsBiiZPfIdwJ4b8nXw Date: Tue, 25 Aug 2015 01:52:33 +0000 Message-ID: References: <20150825014443.11024.77662.idtracker@ietfa.amsl.com> In-Reply-To: <20150825014443.11024.77662.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [199.106.115.192] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Brian E Carpenter Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-14.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 01:52:37 -0000 This version addresses the comments from the following reviews: - The SDP Directorate Review - The Gen-ART Last Call review - OPS-DIR Review All the changes are purely editorial nits. BR, YK -----Original Message----- From: payload [mailto:payload-bounces@ietf.org] On Behalf Of internet-draft= s@ietf.org Sent: Monday, August 24, 2015 6:45 PM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-14.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : RTP Payload Format for H.265/HEVC Video Authors : Ye-Kui Wang Yago Sanchez Thomas Schierl Stephan Wenger Miska M. Hannuksela Filename : draft-ietf-payload-rtp-h265-14.txt Pages : 99 Date : 2015-08-24 Abstract: This memo describes an RTP payload format for the video coding standard ITU-T Recommendation H.265 and ISO/IEC International Standard 23008-2, both also known as High Efficiency Video Coding (HEVC) and developed by the Joint Collaborative Team on Video Coding (JCT-VC). The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit into multiple RTP packets. Furthermore, it supports transmission of an HEVC bitstream over a single as well as multiple RTP streams. When multiple RTP streams are used, a single or multiple transports may be utilized. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-h265-14 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From nobody Mon Aug 24 23:48:30 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7420A1A1B28 for ; Mon, 24 Aug 2015 23:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.193 X-Spam-Level: X-Spam-Status: No, score=0.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Vt2nD8KCn-S for ; Mon, 24 Aug 2015 23:48:23 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75DE1ACDE7 for ; Mon, 24 Aug 2015 23:48:23 -0700 (PDT) Received: by iodb91 with SMTP id b91so175169706iod.1 for ; Mon, 24 Aug 2015 23:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qcTDb1OuBVodX8SMqp6X/TU0GwUjBGabQR2g9nK2z4U=; b=VsC6cj6uRWKcUCGzaH2Gi6UQ5QC8PobeAiQmkTuIxaVclsE9AaA4dCPDuWAe0v1o/M OxSZaxQgUSFASeaGxfNw3fKR6H8hPgW7VWbUyrzh+8sMRG/Pfda5y12sC9F0+FvMi05Q JluxeZSSt6SPBpb62thYHZWDCwTRQmE7AekDGlDsB3vRWOM8X3Np+pCTjYES2WfHaSCC X/QoVCmQODV3OJ0NMfhL9rO1N2zLEnsGhZW3SuZq6UziBRMwEkwSsuPrTUNHWo/7h3N7 yXHJ/omFYECKzqxuf1+6XaazJcIjj/zUmGqteOXx5wsW9ocLuRIgwJtzHZt8GFT1zaAl v0Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qcTDb1OuBVodX8SMqp6X/TU0GwUjBGabQR2g9nK2z4U=; b=JqdvwuZpERSpY6DKVXJoboHCkzAWW+HC9WXaxlGWfa5uS1SKWGjO+T4843wte2OHbb Rs31nAyUM6JM07MP1I1P27ziQCVcJlbNIrdCGIjFAZrzkw3b5J2KalU2ZoEyRqDlw99u 5/Q8da+IuRrClMgeDUV/hdBwXFXdFH0c5vOLrgbpAXXUXgGXRNZzUS0slA7G9vvhY2TO YZ0XPa5MINLdn7oB5xcWvLoOWN8ZIizAg+NT1nxiRovqvD+2JCH3bsXms32tJtHcrh5p mg6yD4kGw/H7WFlXT7miIuqp2smoFWUA9LO7bMUwYGkSAoaqK2ubbP0NyADJwjPs4P8B wSiw== X-Gm-Message-State: ALoCoQkSeDgmq8fi3WfDL8b/nb+lwXrtwZ2BO+2IROkz2ciMqrpTbpsgVwWdMdqdVNh+nbcEDX1l MIME-Version: 1.0 X-Received: by 10.107.8.36 with SMTP id 36mr25418923ioi.172.1440485302778; Mon, 24 Aug 2015 23:48:22 -0700 (PDT) Received: by 10.64.162.165 with HTTP; Mon, 24 Aug 2015 23:48:22 -0700 (PDT) In-Reply-To: <73A192FD-294B-4D94-8B27-75E7CF835E58@nostrum.com> References: <55A3A7F1.8010109@dial.pipex.com> <55B9DCCE.1050902@alvestrand.no> <73A192FD-294B-4D94-8B27-75E7CF835E58@nostrum.com> Date: Tue, 25 Aug 2015 08:48:22 +0200 Message-ID: From: Henrik Lundin To: Ben Campbell Content-Type: multipart/alternative; boundary=001a113fb884c6f877051e1d1efd Archived-At: Cc: draft-ietf-payload-vp8.all@ietf.org, Elwyn Davies , payload-chairs@ietf.org, "payload@ietf.org" Subject: Re: [payload] Gen-art 2nd LC review of draft-ietf-payload-vp8-16 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 06:48:28 -0000 --001a113fb884c6f877051e1d1efd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ben, We have an update. We're reviewing it internally right now. You can expect a new submission shortly. Thanks! /Henrik On Mon, Aug 24, 2015 at 11:21 PM, Ben Campbell wrote: > (- GenART and IETF lists) > > Hi Harald, > > Any updates? > > Thanks! > > Ben. > > On 30 Jul 2015, at 3:14, Harald Alvestrand wrote: > > > Unfortunately this is vacation time in Scandinavia - won't do anything > > with this until mid-August, I'm afraid. (Henrik might.) > > > > So it'll have to wait another 2 telechats or so..... > > > > > > On 07/29/2015 11:58 PM, Ben Campbell wrote: > >> Hi VP8 Authors: > >> > >> Has there been a response to Elwyn's Gen-ART review from the authors? > >> If so, I haven't seen it. (I did see Colin's response). > >> > >> Based Elwyn's review, and on Harald's response to my earlier > >> questions, I assume that the authors will wish to update the draft > >> before it goes back to an IESG telechat. If that's not the case, > >> please let me know. Please be advised that tomorrow (July 30) is the > >> nominal deadline for getting things on the August 6 telechat. > >> > >> Thanks! > >> > >> Ben. > >> > >> > >> On 13 Jul 2015, at 15:57, Ben Campbell wrote: > >> > >>> (+payload and Harald) > >>> > >>> Elwyn: Thanks for the detailed review! > >>> > >>> Authors: Please address Elwyn's comments at your earliest > >>> convenience. There's quite a bit here, and I assume we will need a > >>> new revision before taking this to the IESG telechat, but it would be > >>> helpful to discuss any proposed changes via email before submitting. > >>> > >>> Thanks! > >>> > >>> Ben. > >>> > >>> > >>> On 13 Jul 2015, at 6:58, Elwyn Davies wrote: > >>> > >>>> I am the assigned Gen-ART reviewer for this draft. For background on > >>>> Gen-ART, please see the FAQ at > >>>> > >>>> . > >>>> > >>>> Please resolve these comments along with any other Last Call comment= s > >>>> you may receive. > >>>> > >>>> Document: draft-ietf-payload-vp8-16.txt > >>>> Reviewer: Elwyn Davies > >>>> Review Date: 2015/07/10 > >>>> IETF LC End Date: 2015/07/13 > >>>> IESG Telechat date: (if known) - > >>>> > >>>> Summary: Gosh, it has been a long time since the last review! > >>>> > >>>> Major issues: > >>>> > >>>> Minor issues: > >>>> s4.2: Various of the frame indices either SHOULD or, in the case of > >>>> KEYIDX, MAY start at random values. The rationale(s) for these > >>>> requirements are not explained - nor is the reason why it it is only= a > >>>> MAY for KEYIDX whereas it is SHOULD for PictureID and what might > happen > >>>> were the MAY/SHOULD to be ignored. > >>>> > >>>> Is the rationale something that should be mentioned in the security > >>>> considerations? > >>>> > >>>> s10.1: The downref to RFC 6386 identified by idnits was duly noted > >>>> in the last call > >>>> announcement. I don't have a problem with the downref. > >>>> > >>>> Nits/editorial comments: > >>>> > >>>> General: Consistent usage of "prediction and mode" vs > >>>> "prediction/mode" would be desirable. > >>>> > >>>> s1, para 2: Needs to introduce the 'macroblock' jargon defined in > >>>> RFC 6386. Suggest: > >>>> OLD: > >>>> VP8 is based on decomposition of frames into square sub-blocks of > >>>> pixels, prediction of such sub-blocks using previously constructed > >>>> blocks, and... > >>>> NEW: > >>>> VP8 is based on decomposition of frames into square sub-blocks of > >>>> pixels known as "macroblocks" (see Section 2 of [RFC6386]). > Prediction > >>>> of such sub-blocks using previously constructed blocks, and... > >>>> END > >>>> > >>>> s2: There are a number of technical terms brought over from RFC 6386= . > >>>> These should be listed in s2. At least the following would be in > >>>> the list: > >>>> key frame, interframe, golden frame, altref frame, macroblock. > >>>> Also the terms picture selection index (RPSI) and slice loss > >>>> indication (SLI) from RFC 4585. > >>>> > >>>> s3, para 2: Providing a reference to explain what temporal scalabili= ty > >>>> and the hierarchy selection is all about would be useful. One > >>>> possibility > >>>> would be: > >>>> > >>>> Lim, J. Yang, and B. Jeon,=E2=80=9DFast Coding Mode Decision for Sca= lable > >>>> Video Coding=E2=80=9D, > >>>> 10th Int=E2=80=99l Conf. on Advanced Communication Technology, vol. = 3, pp. > >>>> 1897-1900, 2008. > >>>> > >>>> It would also help to add a pointer to the TL0PICIDX description in > >>>> s4.2, thus: > >>>> ADD: > >>>> Support for temporal scalability is provided by the optional > >>>> TL0PICIDX and TID/Y/KEYIDX > >>>> fields described in Section 4.2. > >>>> END > >>>> > >>>> ss3 and 4: The discussion of how the frame payload might or might > >>>> not be distributed across > >>>> multiple packets is not very clear. The draft has in mind a > >>>> 'preferred use case' (para 1 > >>>> of s4.4 says: > >>>> > >>>>> In the preferred use case, the S bit and PID fields > >>>>> described in Section 4.2 should be used to indicate what the packet > >>>>> contains. > >>>> > >>>> I think it would be helpful to be a bit more positive about this in > >>>> s3, para 3: > >>>> OLD: > >>>> This memo > >>>> allows the partitions to be sent separately or in the same RTP > >>>> packet. It may be beneficial for decoder error-concealment to send > >>>> the partitions in different packets, even though it is not mandatory > >>>> according to this specification. > >>>> NEW: > >>>> Accordingly, this document RECOMMENDS that the frame is packetized > >>>> by the sender > >>>> with each data partition in a separate packet or packets. This may > >>>> be beneficial > >>>> for decoder error concealment and the payload format described in > >>>> Section 4 provides > >>>> fields that allow the partitions to be identified even if the first > >>>> partition is > >>>> not available. The sender can, alternatively, aggregate the data > >>>> partitions into > >>>> a single data stream and, optionally, split it into several packets > >>>> without > >>>> consideration of the partition boundaries. The receiver can use the > >>>> length > >>>> information in the first partition to identify the partitions during > >>>> decoding. > >>>> END > >>>> > >>>> s4/Figure 1: s/bytes/octets/ (2 places) > >>>> > >>>> Figure 1, caption: s/sequel/Sections 4.2 and 4.3/ > >>>> > >>>> Figure 1: The format shown is correct only for the first packet in a > >>>> frame. Subsequent > >>>> packets will not contain the payload header and will have later > >>>> octets of the frame payload. > >>>> This should be mentioned in drawing and/or in the caption. > >>>> > >>>> s4.1, last two paras: > >>>>> Sequence number: The sequence numbers are monotonically increasing > >>>>> and set as packets are sent. > >>>>> > >>>>> The remaining RTP header fields are used as specified in > >>>>> [RFC3550]. > >>>> Redefining the Sequence Number field seems gratuitous and > >>>> potentially dangerous, > >>>> given that it is *very carefully* defined in RFC 3550 and the > >>>> overall intent does > >>>> not seem any different from that in RFC 3550. OTOH a note about the > >>>> (non?-)use of the X bit > >>>> and the Payload Type field (PT) would be useful. I suggest > >>>> replacing the paras above with: > >>>> NEW: > >>>> X bit: MUST be 0. The VP8 RTP profile does not use the RTP Header > >>>> Extension capability. > >>>> > >>>> PT (Payload Type): In line with the policy in Section 3 of > >>>> [RFC3551], applications > >>>> using the VP8 RTP payload profile MUST assign a dynamic payload type > >>>> number to > >>>> be used in each RTP session and provide a mechanism to indicate the > >>>> mapping. > >>>> See Section 6.2 for the mechanism to be used with the Session > >>>> Description Protocol (SDP) > >>>> [RFC4566]. > >>>> > >>>> The remaining RTP Fixed Header Fields (V, P, CC, sequence number, > >>>> SSRC and CSRC > >>>> identfiers) are used as specified in Section 5.1 of [RFC5330]. > >>>> END > >>>> Note that this may be considered to make the reference to RFC 3551 > >>>> normative. > >>>> > >>>> s4.2, X bit: There is potential for confusion between the X bit in > >>>> the fixed header > >>>> and the X bit in the VP8 Payload Descriptor. Perhaps changing this > >>>> to C for control bits > >>>> would avoid the problem. > >>>> > >>>> s4.2, M bit: Similarly, it might be better to use B (for BIG) in > >>>> place of M to avoid confusion. > >>>> > >>>> s4.2, para 7 after Fig 2: For consistency: > >>>> OLD: > >>>> When the X bit is set to 1 in the first octet, the extension bit > >>>> field octet MUST be provided as the second octet. If the X bit is 0= , > >>>> the extension bit field octet MUST NOT be present, and no extensions > >>>> (I, L, T, or K) are permitted. > >>>> NEW: > >>>> When the X [or C] bit is set to 1 in the first octet, the Extended > >>>> Control Bits > >>>> field octet MUST be provided as the second octet. If the X [or C] > >>>> bit is 0, > >>>> the extension bit field octet MUST NOT be present, and no extensions > >>>> (I, L, T, or K) are permitted. > >>>> END > >>>> > >>>> s4.2: The issue of using either 'wrap' or 'restart' but not both for > >>>> restarting number sequences has been raised in various comments by > >>>> IESG members. > >>>> > >>>> s4.2, TL0PICIDX: I think, given the statements in s3 about not > >>>> defining the hierarchy, that more explanation is needed of what the > >>>> 'lowest or base layer' actually means. > >>>> > >>>> s4.2, TL0PICIDX: > >>>>> If TID is larger than 0, TL0PICIDX > >>>>> indicates which base layer frame the current image depends on. > >>>>> TL0PICIDX MUST be incremented when TID is 0. > >>>> What happens if L=3D1 but both T=3D0 and K=3D0 so that there is no T= ID > >>>> value present? Or indeed if T=3D0 but K=3D1 so that the TID field is > >>>> there but 'MUST be ignored by the receiver' (definition of TID > field)? > >>>> > >>>> s4.3: It would be useful to include the section number (9.1) where > >>>> the uncompressed data chunk specification is found. I was somewhat > >>>> surprised that the ordering is reversed in the protocol spec. > >>>> > >>>> s4.3, VER: The receiver should validate this field - currently only > >>>> values 0-3 are valid. > >>>> > >>>> s4.3, SizeN: Make it clear these are integer fields: s/in Size0,/in > >>>> integer fields Size0,/ > >>>> > >>>> s4.3 and s4.4: It would be helpful to implementers to explain what > >>>> the offsets in the first partition payload are for the additional > >>>> partition count and additional partition sizes. Having rummaged > >>>> around in RFC 6386, I have to say that I am unclear whether the > >>>> values are placed after the full chunk of data indicated by > >>>> 1stPartitionSize or are part of this data. And if the latter is the > >>>> case, how to work out where the partition sizes are. I guess that > >>>> they ought to be at offset (1stPartitionSize+10 - key frame - or > >>>> 1stPartitionSize+3 - interframe) in the VP8 Payload field as it is > >>>> difficult to work out where they are without decoding the partition > >>>> otherwise. Also exactly how many partition sizes to expect - I > >>>> think I read in RFC 6386 that the last partition size is implicit. > >>>> Help! > >>>> > >>>> In the course of clearing this up, it might be appropriate to move > >>>> the last sentence of the first para of s4.4 and the second para of > >>>> s4.4 into s4.3 as part of the explanation. This is the relevant tex= t: > >>>>> Note that the length of the first partition can > >>>>> always be obtained from the first partition size parameter in the V= P8 > >>>>> payload header. > >>>>> > >>>>> The VP8 bitstream format [RFC6386] specifies that if multiple DCT/W= HT > >>>>> partitions are produced, the location of each partition start is > >>>>> found at the end of the first (prediction/mode) partition. In this > >>>>> RTP payload specification, the location offsets are considered to b= e > >>>>> part of the first partition. > >>>> > >>>> > >>>> s4.4: I found this section very difficult to parse. It is a bit > >>>> 'stream of consciousness' and would benefit from a reordering and > >>>> rewrite. Suggestion (assuming the second para gets moved to s4.3): > >>>> NEW SECTION 4.4: > >>>> An encoded VP8 frame can be divided into two or more partitions, as > >>>> described in Section 1. It is OPTIONAL for a packetizer implementin= g > >>>> this RTP specification > >>>> to pay attention to the partition boundaries within an encoded frame= . > >>>> If packetization of a frame is done without considering the partitio= n > >>>> boundaries, the PID field MAY be set to zero for all packets, and th= e > >>>> S bit MUST NOT be set to one for any other packet than the first. > >>>> > >>>> If the preferred usage suggested in Section 3 is followed, with each > >>>> packet > >>>> carrying data from exactly one partition, the S bit and PID fields > >>>> described in Section 4.2 SHOULD be used to indicate what the packet > >>>> contains. The PID field should indicate which partition the first > >>>> octet of the payload belongs to, and the S bit indicates that the > >>>> packet starts on a new partition. > >>>> > >>>> If the packetizer does not pay attention to the partition > >>>> boundaries, one > >>>> packet can contain a fragment of a partition, a complete partition, > >>>> or an > >>>> aggregate of fragments and partitions. There is no explicit > >>>> signaling of > >>>> partition boundaries in the payload and the partition lengths at the > >>>> end of > >>>> the first partition have to be used to identify the boundaries. > >>>> Partitions > >>>> MUST be aggregated in decoding order. Two fragments from different > >>>> partitions MAY be aggregated into the same packet along with one or > >>>> more > >>>> complete partitions. > >>>> > >>>> In all cases, the payload of a packet MUST contain data from only > >>>> one video > >>>> frame. Consequently the set of packets carrying the data from a > >>>> particular > >>>> frame will contain exactly one VP8 Payload Header (see Section 4.3) > >>>> carried > >>>> in the first packet of the frame. The last, or only, packet > >>>> carrying data for the > >>>> frame MUST have the M bit set in the RTP header. > >>>> > >>>> s4.5.1: Th algorithm only applies for the RECOMMENDED use case with > >>>> partitions in separate packets. > >>>> This should be noted. > >>>> > >>>> s5.2, last para: s/only parts of the frame is corrupted./only part > >>>> of the frame is corrupted./ > >>>> > >>>> s6: s/This payload format has two required parameters./This payload > >>>> format has two optional parameters./ > >>>> [I think this is probably a hangover from the previous version.] > >>>> > >>>> s7: s/Cryptographic system may also allow/The cryptographic system > >>>> may also allow/ > >>>> > >>>> s7: > >>>>> the usage of SRTP [RFC3711] is recommended. > >>>> RECOMMENDED? > >>>> > >>>> s10.2: I suspect that RFC 3551 is normative. > > > > > > -- > > Surveillance is pervasive. Go Dark. > --=20 Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 41 --001a113fb884c6f877051e1d1efd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ben,

We have an update. We're re= viewing it internally right now. You can expect a new submission shortly.

Thanks!
/Henrik


On Mon, Aug 24, = 2015 at 11:21 PM, Ben Campbell <ben@nostrum.com> wrote:
(- GenART and IETF lists)

Hi Harald,

Any updates?

Thanks!

Ben.

On 30 Jul 2015, at 3:14, Harald Alvestrand wrote:

> Unfortunately this is v= acation time in Scandinavia - won't do anything
> with this until mid-August, I'm afraid. (Henrik might.)
>
> So it'll have to wait another 2 telechats or so.....
>
>
> On 07/29/2015 11:58 PM, Ben Campbell wrote:
>> Hi VP8 Authors:
>>
>> Has there been a response to Elwyn's Gen-ART review from the a= uthors?
>> If so, I haven't seen it. (I did see Colin's response). >>
>> Based Elwyn's review, and on Harald's response to my earli= er
>> questions, I assume that the authors will wish to update the draft=
>> before it goes back to an IESG telechat. If that's not the cas= e,
>> please let me know. Please be advised that tomorrow (July 30) is t= he
>> nominal deadline for getting things on the August 6 telechat.
>>
>> Thanks!
>>
>> Ben.
>>
>>
>> On 13 Jul 2015, at 15:57, Ben Campbell wrote:
>>
>>> (+payload and Harald)
>>>
>>> Elwyn: Thanks for the detailed review!
>>>
>>> Authors: Please address Elwyn's comments at your earliest<= br> >>> convenience. There's quite a bit here, and I assume we wil= l need a
>>> new revision before taking this to the IESG telechat, but it w= ould be
>>> helpful to discuss any proposed changes via email before submi= tting.
>>>
>>> Thanks!
>>>
>>> Ben.
>>>
>>>
>>> On 13 Jul 2015, at 6:58, Elwyn Davies wrote:
>>>
>>>> I am the assigned Gen-ART reviewer for this draft. For bac= kground on
>>>> Gen-ART, please see the FAQ at
>>>>
>>>> <http://wiki.tools.ietf.o= rg/area/gen/trac/wiki/GenArtfaq>.
>>>>
>>>> Please resolve these comments along with any other Last Ca= ll comments
>>>> you may receive.
>>>>
>>>> Document: draft-ietf-payload-vp8-16.txt
>>>> Reviewer: Elwyn Davies
>>>> Review Date: 2015/07/10
>>>> IETF LC End Date: 2015/07/13
>>>> IESG Telechat date: (if known) -
>>>>
>>>> Summary: Gosh, it has been a long time since the last revi= ew!
>>>>
>>>> Major issues:
>>>>
>>>> Minor issues:
>>>> s4.2: Various of the frame indices either SHOULD or, in th= e case of
>>>> KEYIDX, MAY start at random values.=C2=A0 The rationale(s)= for these
>>>> requirements are not explained - nor is the reason why it = it is only a
>>>> MAY for KEYIDX whereas it is SHOULD for PictureID and what= might happen
>>>> were the MAY/SHOULD to be ignored.
>>>>
>>>> Is the rationale something that should be mentioned in the= security
>>>> considerations?
>>>>
>>>> s10.1:=C2=A0 The downref to RFC 6386 identified by idnits = was duly noted
>>>> in the last call
>>>> announcement.=C2=A0 I don't have a problem with the do= wnref.
>>>>
>>>> Nits/editorial comments:
>>>>
>>>> General: Consistent usage of "prediction and mode&quo= t; vs
>>>> "prediction/mode" would be desirable.
>>>>
>>>> s1, para 2: Needs to introduce the 'macroblock' ja= rgon defined in
>>>> RFC 6386. Suggest:
>>>> OLD:
>>>> VP8 is based on decomposition of frames into square sub-bl= ocks of
>>>> pixels, prediction of such sub-blocks using previously con= structed
>>>> blocks, and...
>>>> NEW:
>>>> VP8 is based on decomposition of frames into square sub-bl= ocks of
>>>> pixels known as "macroblocks" (see Section 2 of = [RFC6386]).=C2=A0 Prediction
>>>> of such sub-blocks using previously constructed blocks, an= d...
>>>> END
>>>>
>>>> s2: There are a number of technical terms brought over fro= m RFC 6386.
>>>> These should be listed in s2.=C2=A0 At least the following= would be in
>>>> the list:
>>>> key frame, interframe, golden frame, altref frame, macrobl= ock.
>>>> Also the terms picture selection index (RPSI) and slice lo= ss
>>>> indication (SLI) from RFC 4585.
>>>>
>>>> s3, para 2: Providing a reference to explain what temporal= scalability
>>>> and the hierarchy selection is all about would be useful.= =C2=A0 One
>>>> possibility
>>>> would be:
>>>>
>>>> Lim, J. Yang, and B. Jeon,=E2=80=9DFast Coding Mode Decisi= on for Scalable
>>>> Video Coding=E2=80=9D,
>>>> 10th Int=E2=80=99l Conf. on Advanced Communication Technol= ogy, vol. 3, pp.
>>>> 1897-1900, 2008.
>>>>
>>>> It would also help to add a pointer to the TL0PICIDX descr= iption in
>>>> s4.2, thus:
>>>> ADD:
>>>> Support for temporal scalability is provided by the option= al
>>>> TL0PICIDX and TID/Y/KEYIDX
>>>> fields described in Section 4.2.
>>>> END
>>>>
>>>> ss3 and 4: The discussion of how the frame payload might o= r might
>>>> not be distributed across
>>>> multiple packets is not very clear.=C2=A0 =C2=A0The draft = has in mind a
>>>> 'preferred use case' (para 1
>>>> of s4.4 says:
>>>>
>>>>> In the preferred use case, the S bit and PID fields >>>>> described in Section 4.2 should be used to indicate wh= at the packet
>>>>> contains.
>>>>
>>>> I think it would be helpful to be a bit more positive abou= t this in
>>>> s3, para 3:
>>>> OLD:
>>>> This memo
>>>> allows the partitions to be sent separately or in the same= RTP
>>>> packet.=C2=A0 It may be beneficial for decoder error-conce= alment to send
>>>> the partitions in different packets, even though it is not= mandatory
>>>> according to this specification.
>>>> NEW:
>>>> Accordingly, this document RECOMMENDS that the frame is pa= cketized
>>>> by the sender
>>>> with each data partition in a separate packet or packets.= =C2=A0 This may
>>>> be beneficial
>>>> for decoder error concealment and the payload format descr= ibed in
>>>> Section 4 provides
>>>> fields that allow the partitions to be identified even if = the first
>>>> partition is
>>>> not available.=C2=A0 The sender can, alternatively, aggreg= ate the data
>>>> partitions into
>>>> a single data stream and, optionally, split it into severa= l packets
>>>> without
>>>> consideration of the partition boundaries.=C2=A0 The recei= ver can use the
>>>> length
>>>> information in the first partition to identify the partiti= ons during
>>>> decoding.
>>>> END
>>>>
>>>> s4/Figure 1: s/bytes/octets/ (2 places)
>>>>
>>>> Figure 1, caption: s/sequel/Sections 4.2 and 4.3/
>>>>
>>>> Figure 1: The format shown is correct only for the first p= acket in a
>>>> frame.=C2=A0 Subsequent
>>>> packets will not contain the payload header and will have = later
>>>> octets of the frame payload.
>>>> This should be mentioned in drawing and/or in the caption.=
>>>>
>>>> s4.1, last two paras:
>>>>> Sequence number:=C2=A0 The sequence numbers are monoto= nically increasing
>>>>> and set as packets are sent.
>>>>>
>>>>> The remaining RTP header fields are used as specified = in
>>>>> [RFC3550].
>>>> Redefining the Sequence Number field seems gratuitous and<= br> >>>> potentially dangerous,
>>>> given that it is *very carefully* defined in RFC 3550 and = the
>>>> overall intent does
>>>> not seem any different from that in RFC 3550.=C2=A0 OTOH a= note about the
>>>> (non?-)use of the X bit
>>>> and the Payload Type field (PT) would be useful.=C2=A0 I s= uggest
>>>> replacing the paras above with:
>>>> NEW:
>>>> X bit: MUST be 0.=C2=A0 The VP8 RTP profile does not use t= he RTP Header
>>>> Extension capability.
>>>>
>>>> PT (Payload Type):=C2=A0 In line with the policy in Sectio= n 3 of
>>>> [RFC3551], applications
>>>> using the VP8 RTP payload profile MUST assign a dynamic pa= yload type
>>>> number to
>>>> be used in each RTP session and provide a mechanism to ind= icate the
>>>> mapping.
>>>> See Section 6.2 for the mechanism to be used with the Sess= ion
>>>> Description Protocol (SDP)
>>>> [RFC4566].
>>>>
>>>> The remaining RTP Fixed Header Fields (V, P, CC, sequence = number,
>>>> SSRC and CSRC
>>>> identfiers) are used as specified in Section 5.1 of [RFC53= 30].
>>>> END
>>>> Note that this may be considered to make the reference to = RFC 3551
>>>> normative.
>>>>
>>>> s4.2, X bit:=C2=A0 There is potential for confusion betwee= n the X bit in
>>>> the fixed header
>>>> and the X bit in the VP8 Payload Descriptor.=C2=A0 Perhaps= changing this
>>>> to C for control bits
>>>> would avoid the problem.
>>>>
>>>> s4.2, M bit: Similarly, it might be better to use B (for B= IG) in
>>>> place of M to avoid confusion.
>>>>
>>>> s4.2, para 7 after Fig 2: For consistency:
>>>> OLD:
>>>> When the X bit is set to 1 in the first octet, the extensi= on bit
>>>> field octet MUST be provided as the second octet.=C2=A0 If= the X bit is 0,
>>>> the extension bit field octet MUST NOT be present, and no = extensions
>>>> (I, L, T, or K) are permitted.
>>>> NEW:
>>>> When the X [or C] bit is set to 1 in the first octet, the = Extended
>>>> Control Bits
>>>> field octet MUST be provided as the second octet.=C2=A0 If= the X [or C]
>>>> bit is 0,
>>>> the extension bit field octet MUST NOT be present, and no = extensions
>>>> (I, L, T, or K) are permitted.
>>>> END
>>>>
>>>> s4.2: The issue of using either 'wrap' or 'res= tart' but not both for
>>>> restarting number sequences has been raised in various com= ments by
>>>> IESG members.
>>>>
>>>> s4.2, TL0PICIDX: I think, given the statements in s3 about= not
>>>> defining the hierarchy, that more explanation is needed of= what the
>>>> 'lowest or base layer' actually means.
>>>>
>>>> s4.2, TL0PICIDX:
>>>>> If TID is larger than 0, TL0PICIDX
>>>>> indicates which base layer frame the current image dep= ends on.
>>>>> TL0PICIDX MUST be incremented when TID is 0.
>>>> What happens if L=3D1 but both T=3D0 and K=3D0 so that the= re is no TID
>>>> value present? Or indeed if T=3D0 but K=3D1 so that the TI= D field is
>>>> there but 'MUST be ignored by the receiver'=C2=A0 = (definition of TID field)?
>>>>
>>>> s4.3: It would be useful to include the section number (9.= 1) where
>>>> the uncompressed data chunk specification is found.=C2=A0 = I was somewhat
>>>> surprised that the ordering is reversed in the protocol sp= ec.
>>>>
>>>> s4.3, VER: The receiver should validate this field - curre= ntly only
>>>> values 0-3 are valid.
>>>>
>>>> s4.3, SizeN:=C2=A0 Make it clear these are integer fields:= s/in Size0,/in
>>>> integer fields Size0,/
>>>>
>>>> s4.3 and s4.4:=C2=A0 It would be helpful to implementers t= o explain what
>>>> the offsets in the=C2=A0 first partition payload are for t= he additional
>>>> partition count and additional partition sizes.=C2=A0 Havi= ng rummaged
>>>> around in RFC=C2=A0 6386, I have to say that I am unclear = whether the
>>>> values are placed after the full chunk of data indicated b= y
>>>> 1stPartitionSize or are part of this data. And if the latt= er is the
>>>> case, how to work out where the partition sizes are.=C2=A0= I guess that
>>>> they ought to be at offset (1stPartitionSize+10 - key fram= e - or
>>>> 1stPartitionSize+3 - interframe) in the VP8 Payload field = as it is
>>>> difficult to work out where they are without decoding the = partition
>>>> otherwise.=C2=A0 Also exactly how many partition sizes to = expect - I
>>>> think I read in RFC 6386 that the last partition size is i= mplicit.
>>>> Help!
>>>>
>>>> In the course of clearing this up, it might be appropriate= to move
>>>> the last sentence of the first para of s4.4 and the second= para of
>>>> s4.4 into s4.3 as part of the explanation.=C2=A0 This is t= he relevant text:
>>>>> Note that the length of the first partition can
>>>>> always be obtained from the first partition size param= eter in the VP8
>>>>> payload header.
>>>>>
>>>>> The VP8 bitstream format [RFC6386] specifies that if m= ultiple DCT/WHT
>>>>> partitions are produced, the location of each partitio= n start is
>>>>> found at the end of the first (prediction/mode) partit= ion.=C2=A0 In this
>>>>> RTP payload specification, the location offsets are co= nsidered to be
>>>>> part of the first partition.
>>>>
>>>>
>>>> s4.4:=C2=A0 I found this section very difficult to parse.= =C2=A0 It is a bit
>>>> 'stream of consciousness' and would benefit from a= reordering and
>>>> rewrite.=C2=A0 Suggestion (assuming the second para gets m= oved to s4.3):
>>>> NEW SECTION 4.4:
>>>> An encoded VP8 frame can be divided into two or more parti= tions, as
>>>> described in Section 1.=C2=A0 It is OPTIONAL for a packeti= zer implementing
>>>> this RTP specification
>>>> to pay attention to the partition boundaries within an enc= oded frame.
>>>> If packetization of a frame is done without considering th= e partition
>>>> boundaries, the PID field MAY be set to zero for all packe= ts, and the
>>>> S bit MUST NOT be set to one for any other packet than the= first.
>>>>
>>>> If the preferred usage suggested in Section 3 is followed,= with each
>>>> packet
>>>> carrying data from exactly one partition, the S bit and PI= D fields
>>>> described in Section 4.2 SHOULD be used to indicate what t= he packet
>>>> contains.=C2=A0 The PID field should indicate which partit= ion the first
>>>> octet of the payload belongs to, and the S bit indicates t= hat the
>>>> packet starts on a new partition.
>>>>
>>>> If the packetizer does not pay attention to the partition<= br> >>>> boundaries, one
>>>> packet can contain a fragment of a=C2=A0 partition, a comp= lete partition,
>>>> or an
>>>> aggregate of fragments and partitions.=C2=A0 There is no e= xplicit
>>>> signaling of
>>>> partition boundaries in the payload and the partition leng= ths at the
>>>> end of
>>>> the first partition have to be used to identify the bounda= ries.
>>>> Partitions
>>>> MUST be aggregated in decoding order.=C2=A0 Two fragments = from different
>>>> partitions MAY be aggregated into the same packet along wi= th one or
>>>> more
>>>> complete partitions.
>>>>
>>>> In all cases, the payload of a packet MUST contain data fr= om only
>>>> one video
>>>> frame.=C2=A0 Consequently the set of packets carrying the = data from a
>>>> particular
>>>> frame will contain exactly one VP8 Payload Header (see Sec= tion 4.3)
>>>> carried
>>>> in the first packet of the frame.=C2=A0 The last, or only,= packet
>>>> carrying data for the
>>>> frame MUST have the M bit set in the RTP header.
>>>>
>>>> s4.5.1:=C2=A0 Th algorithm only applies for the RECOMMENDE= D use case with
>>>> partitions in separate packets.
>>>> This should be noted.
>>>>
>>>> s5.2, last para: s/only parts of the frame is corrupted./o= nly part
>>>> of the frame is corrupted./
>>>>
>>>> s6: s/This payload format has two required parameters./Thi= s payload
>>>> format has two optional parameters./
>>>> [I think this is probably a hangover from the previous ver= sion.]
>>>>
>>>> s7: s/Cryptographic system may also allow/The cryptographi= c system
>>>> may also allow/
>>>>
>>>> s7:
>>>>> the usage of SRTP [RFC3711] is recommended.
>>>> RECOMMENDED?
>>>>
>>>> s10.2: I suspect that RFC 3551 is normative.
>
>
> --
> Surveillance is pervasive. Go Dark.



--
=
= Henrik Lundin=C2=A0|=C2=A0WebRTC Software Eng=C2=A0|=C2=A0hlundin@google.com=C2=A0|= =C2=A0+46 70 646 13 41

--001a113fb884c6f877051e1d1efd-- From nobody Tue Aug 25 00:00:15 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6991B2AAA; Tue, 25 Aug 2015 00:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srmYIp4NVNxf; Tue, 25 Aug 2015 00:00:03 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD731B2AB3; Tue, 25 Aug 2015 00:00:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 0F3E27C0772; Tue, 25 Aug 2015 09:00:01 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4e6gnYWeTHH; Tue, 25 Aug 2015 08:59:56 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:e81d:df2a:c4ba:93a4] (unknown [IPv6:2001:470:de0a:27:e81d:df2a:c4ba:93a4]) by mork.alvestrand.no (Postfix) with ESMTPSA id 7D4F07C075E; Tue, 25 Aug 2015 08:59:56 +0200 (CEST) Message-ID: <55DC126B.6020002@alvestrand.no> Date: Tue, 25 Aug 2015 08:59:55 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Henrik Lundin , Ben Campbell References: <55A3A7F1.8010109@dial.pipex.com> <55B9DCCE.1050902@alvestrand.no> <73A192FD-294B-4D94-8B27-75E7CF835E58@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-payload-vp8.all@ietf.org, Elwyn Davies , payload-chairs@ietf.org, "payload@ietf.org" Subject: Re: [payload] Gen-art 2nd LC review of draft-ietf-payload-vp8-16 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 07:00:11 -0000 Den 25. aug. 2015 08:48, skrev Henrik Lundin: > Hi Ben, > > We have an update. We're reviewing it internally right now. You can > expect a new submission shortly. I'm doing a round of grammar review.... do you want to see it now, or should we just submit an updated I-D and notify you when it's up? Harald > > Thanks! > /Henrik > > > On Mon, Aug 24, 2015 at 11:21 PM, Ben Campbell > wrote: > > (- GenART and IETF lists) > > Hi Harald, > > Any updates? > > Thanks! > > Ben. > > On 30 Jul 2015, at 3:14, Harald Alvestrand wrote: > > > Unfortunately this is vacation time in Scandinavia - won't do anything > > with this until mid-August, I'm afraid. (Henrik might.) > > > > So it'll have to wait another 2 telechats or so..... > > > > > > On 07/29/2015 11:58 PM, Ben Campbell wrote: > >> Hi VP8 Authors: > >> > >> Has there been a response to Elwyn's Gen-ART review from the authors? > >> If so, I haven't seen it. (I did see Colin's response). > >> > >> Based Elwyn's review, and on Harald's response to my earlier > >> questions, I assume that the authors will wish to update the draft > >> before it goes back to an IESG telechat. If that's not the case, > >> please let me know. Please be advised that tomorrow (July 30) is the > >> nominal deadline for getting things on the August 6 telechat. > >> > >> Thanks! > >> > >> Ben. > >> > >> > >> On 13 Jul 2015, at 15:57, Ben Campbell wrote: > >> > >>> (+payload and Harald) > >>> > >>> Elwyn: Thanks for the detailed review! > >>> > >>> Authors: Please address Elwyn's comments at your earliest > >>> convenience. There's quite a bit here, and I assume we will need a > >>> new revision before taking this to the IESG telechat, but it would be > >>> helpful to discuss any proposed changes via email before submitting. > >>> > >>> Thanks! > >>> > >>> Ben. > >>> > >>> > >>> On 13 Jul 2015, at 6:58, Elwyn Davies wrote: > >>> > >>>> I am the assigned Gen-ART reviewer for this draft. For background on > >>>> Gen-ART, please see the FAQ at > >>>> > >>>> . > >>>> > >>>> Please resolve these comments along with any other Last Call comments > >>>> you may receive. > >>>> > >>>> Document: draft-ietf-payload-vp8-16.txt > >>>> Reviewer: Elwyn Davies > >>>> Review Date: 2015/07/10 > >>>> IETF LC End Date: 2015/07/13 > >>>> IESG Telechat date: (if known) - > >>>> > >>>> Summary: Gosh, it has been a long time since the last review! > >>>> > >>>> Major issues: > >>>> > >>>> Minor issues: > >>>> s4.2: Various of the frame indices either SHOULD or, in the case of > >>>> KEYIDX, MAY start at random values. The rationale(s) for these > >>>> requirements are not explained - nor is the reason why it it is only a > >>>> MAY for KEYIDX whereas it is SHOULD for PictureID and what might happen > >>>> were the MAY/SHOULD to be ignored. > >>>> > >>>> Is the rationale something that should be mentioned in the security > >>>> considerations? > >>>> > >>>> s10.1: The downref to RFC 6386 identified by idnits was duly noted > >>>> in the last call > >>>> announcement. I don't have a problem with the downref. > >>>> > >>>> Nits/editorial comments: > >>>> > >>>> General: Consistent usage of "prediction and mode" vs > >>>> "prediction/mode" would be desirable. > >>>> > >>>> s1, para 2: Needs to introduce the 'macroblock' jargon defined in > >>>> RFC 6386. Suggest: > >>>> OLD: > >>>> VP8 is based on decomposition of frames into square sub-blocks of > >>>> pixels, prediction of such sub-blocks using previously constructed > >>>> blocks, and... > >>>> NEW: > >>>> VP8 is based on decomposition of frames into square sub-blocks of > >>>> pixels known as "macroblocks" (see Section 2 of [RFC6386]). Prediction > >>>> of such sub-blocks using previously constructed blocks, and... > >>>> END > >>>> > >>>> s2: There are a number of technical terms brought over from RFC 6386. > >>>> These should be listed in s2. At least the following would be in > >>>> the list: > >>>> key frame, interframe, golden frame, altref frame, macroblock. > >>>> Also the terms picture selection index (RPSI) and slice loss > >>>> indication (SLI) from RFC 4585. > >>>> > >>>> s3, para 2: Providing a reference to explain what temporal scalability > >>>> and the hierarchy selection is all about would be useful. One > >>>> possibility > >>>> would be: > >>>> > >>>> Lim, J. Yang, and B. Jeon,”Fast Coding Mode Decision for Scalable > >>>> Video Coding”, > >>>> 10th Int’l Conf. on Advanced Communication Technology, vol. 3, pp. > >>>> 1897-1900, 2008. > >>>> > >>>> It would also help to add a pointer to the TL0PICIDX description in > >>>> s4.2, thus: > >>>> ADD: > >>>> Support for temporal scalability is provided by the optional > >>>> TL0PICIDX and TID/Y/KEYIDX > >>>> fields described in Section 4.2. > >>>> END > >>>> > >>>> ss3 and 4: The discussion of how the frame payload might or might > >>>> not be distributed across > >>>> multiple packets is not very clear. The draft has in mind a > >>>> 'preferred use case' (para 1 > >>>> of s4.4 says: > >>>> > >>>>> In the preferred use case, the S bit and PID fields > >>>>> described in Section 4.2 should be used to indicate what the packet > >>>>> contains. > >>>> > >>>> I think it would be helpful to be a bit more positive about this in > >>>> s3, para 3: > >>>> OLD: > >>>> This memo > >>>> allows the partitions to be sent separately or in the same RTP > >>>> packet. It may be beneficial for decoder error-concealment to send > >>>> the partitions in different packets, even though it is not mandatory > >>>> according to this specification. > >>>> NEW: > >>>> Accordingly, this document RECOMMENDS that the frame is packetized > >>>> by the sender > >>>> with each data partition in a separate packet or packets. This may > >>>> be beneficial > >>>> for decoder error concealment and the payload format described in > >>>> Section 4 provides > >>>> fields that allow the partitions to be identified even if the first > >>>> partition is > >>>> not available. The sender can, alternatively, aggregate the data > >>>> partitions into > >>>> a single data stream and, optionally, split it into several packets > >>>> without > >>>> consideration of the partition boundaries. The receiver can use the > >>>> length > >>>> information in the first partition to identify the partitions during > >>>> decoding. > >>>> END > >>>> > >>>> s4/Figure 1: s/bytes/octets/ (2 places) > >>>> > >>>> Figure 1, caption: s/sequel/Sections 4.2 and 4.3/ > >>>> > >>>> Figure 1: The format shown is correct only for the first packet in a > >>>> frame. Subsequent > >>>> packets will not contain the payload header and will have later > >>>> octets of the frame payload. > >>>> This should be mentioned in drawing and/or in the caption. > >>>> > >>>> s4.1, last two paras: > >>>>> Sequence number: The sequence numbers are monotonically increasing > >>>>> and set as packets are sent. > >>>>> > >>>>> The remaining RTP header fields are used as specified in > >>>>> [RFC3550]. > >>>> Redefining the Sequence Number field seems gratuitous and > >>>> potentially dangerous, > >>>> given that it is *very carefully* defined in RFC 3550 and the > >>>> overall intent does > >>>> not seem any different from that in RFC 3550. OTOH a note about the > >>>> (non?-)use of the X bit > >>>> and the Payload Type field (PT) would be useful. I suggest > >>>> replacing the paras above with: > >>>> NEW: > >>>> X bit: MUST be 0. The VP8 RTP profile does not use the RTP Header > >>>> Extension capability. > >>>> > >>>> PT (Payload Type): In line with the policy in Section 3 of > >>>> [RFC3551], applications > >>>> using the VP8 RTP payload profile MUST assign a dynamic payload type > >>>> number to > >>>> be used in each RTP session and provide a mechanism to indicate the > >>>> mapping. > >>>> See Section 6.2 for the mechanism to be used with the Session > >>>> Description Protocol (SDP) > >>>> [RFC4566]. > >>>> > >>>> The remaining RTP Fixed Header Fields (V, P, CC, sequence number, > >>>> SSRC and CSRC > >>>> identfiers) are used as specified in Section 5.1 of [RFC5330]. > >>>> END > >>>> Note that this may be considered to make the reference to RFC 3551 > >>>> normative. > >>>> > >>>> s4.2, X bit: There is potential for confusion between the X bit in > >>>> the fixed header > >>>> and the X bit in the VP8 Payload Descriptor. Perhaps changing this > >>>> to C for control bits > >>>> would avoid the problem. > >>>> > >>>> s4.2, M bit: Similarly, it might be better to use B (for BIG) in > >>>> place of M to avoid confusion. > >>>> > >>>> s4.2, para 7 after Fig 2: For consistency: > >>>> OLD: > >>>> When the X bit is set to 1 in the first octet, the extension bit > >>>> field octet MUST be provided as the second octet. If the X bit is 0, > >>>> the extension bit field octet MUST NOT be present, and no extensions > >>>> (I, L, T, or K) are permitted. > >>>> NEW: > >>>> When the X [or C] bit is set to 1 in the first octet, the Extended > >>>> Control Bits > >>>> field octet MUST be provided as the second octet. If the X [or C] > >>>> bit is 0, > >>>> the extension bit field octet MUST NOT be present, and no extensions > >>>> (I, L, T, or K) are permitted. > >>>> END > >>>> > >>>> s4.2: The issue of using either 'wrap' or 'restart' but not both for > >>>> restarting number sequences has been raised in various comments by > >>>> IESG members. > >>>> > >>>> s4.2, TL0PICIDX: I think, given the statements in s3 about not > >>>> defining the hierarchy, that more explanation is needed of what the > >>>> 'lowest or base layer' actually means. > >>>> > >>>> s4.2, TL0PICIDX: > >>>>> If TID is larger than 0, TL0PICIDX > >>>>> indicates which base layer frame the current image depends on. > >>>>> TL0PICIDX MUST be incremented when TID is 0. > >>>> What happens if L=1 but both T=0 and K=0 so that there is no TID > >>>> value present? Or indeed if T=0 but K=1 so that the TID field is > >>>> there but 'MUST be ignored by the receiver' (definition of TID field)? > >>>> > >>>> s4.3: It would be useful to include the section number (9.1) where > >>>> the uncompressed data chunk specification is found. I was somewhat > >>>> surprised that the ordering is reversed in the protocol spec. > >>>> > >>>> s4.3, VER: The receiver should validate this field - currently only > >>>> values 0-3 are valid. > >>>> > >>>> s4.3, SizeN: Make it clear these are integer fields: s/in Size0,/in > >>>> integer fields Size0,/ > >>>> > >>>> s4.3 and s4.4: It would be helpful to implementers to explain what > >>>> the offsets in the first partition payload are for the additional > >>>> partition count and additional partition sizes. Having rummaged > >>>> around in RFC 6386, I have to say that I am unclear whether the > >>>> values are placed after the full chunk of data indicated by > >>>> 1stPartitionSize or are part of this data. And if the latter is the > >>>> case, how to work out where the partition sizes are. I guess that > >>>> they ought to be at offset (1stPartitionSize+10 - key frame - or > >>>> 1stPartitionSize+3 - interframe) in the VP8 Payload field as it is > >>>> difficult to work out where they are without decoding the partition > >>>> otherwise. Also exactly how many partition sizes to expect - I > >>>> think I read in RFC 6386 that the last partition size is implicit. > >>>> Help! > >>>> > >>>> In the course of clearing this up, it might be appropriate to move > >>>> the last sentence of the first para of s4.4 and the second para of > >>>> s4.4 into s4.3 as part of the explanation. This is the relevant text: > >>>>> Note that the length of the first partition can > >>>>> always be obtained from the first partition size parameter in the VP8 > >>>>> payload header. > >>>>> > >>>>> The VP8 bitstream format [RFC6386] specifies that if multiple DCT/WHT > >>>>> partitions are produced, the location of each partition start is > >>>>> found at the end of the first (prediction/mode) partition. In this > >>>>> RTP payload specification, the location offsets are considered to be > >>>>> part of the first partition. > >>>> > >>>> > >>>> s4.4: I found this section very difficult to parse. It is a bit > >>>> 'stream of consciousness' and would benefit from a reordering and > >>>> rewrite. Suggestion (assuming the second para gets moved to s4.3): > >>>> NEW SECTION 4.4: > >>>> An encoded VP8 frame can be divided into two or more partitions, as > >>>> described in Section 1. It is OPTIONAL for a packetizer implementing > >>>> this RTP specification > >>>> to pay attention to the partition boundaries within an encoded frame. > >>>> If packetization of a frame is done without considering the partition > >>>> boundaries, the PID field MAY be set to zero for all packets, and the > >>>> S bit MUST NOT be set to one for any other packet than the first. > >>>> > >>>> If the preferred usage suggested in Section 3 is followed, with each > >>>> packet > >>>> carrying data from exactly one partition, the S bit and PID fields > >>>> described in Section 4.2 SHOULD be used to indicate what the packet > >>>> contains. The PID field should indicate which partition the first > >>>> octet of the payload belongs to, and the S bit indicates that the > >>>> packet starts on a new partition. > >>>> > >>>> If the packetizer does not pay attention to the partition > >>>> boundaries, one > >>>> packet can contain a fragment of a partition, a complete partition, > >>>> or an > >>>> aggregate of fragments and partitions. There is no explicit > >>>> signaling of > >>>> partition boundaries in the payload and the partition lengths at the > >>>> end of > >>>> the first partition have to be used to identify the boundaries. > >>>> Partitions > >>>> MUST be aggregated in decoding order. Two fragments from different > >>>> partitions MAY be aggregated into the same packet along with one or > >>>> more > >>>> complete partitions. > >>>> > >>>> In all cases, the payload of a packet MUST contain data from only > >>>> one video > >>>> frame. Consequently the set of packets carrying the data from a > >>>> particular > >>>> frame will contain exactly one VP8 Payload Header (see Section 4.3) > >>>> carried > >>>> in the first packet of the frame. The last, or only, packet > >>>> carrying data for the > >>>> frame MUST have the M bit set in the RTP header. > >>>> > >>>> s4.5.1: Th algorithm only applies for the RECOMMENDED use case with > >>>> partitions in separate packets. > >>>> This should be noted. > >>>> > >>>> s5.2, last para: s/only parts of the frame is corrupted./only part > >>>> of the frame is corrupted./ > >>>> > >>>> s6: s/This payload format has two required parameters./This payload > >>>> format has two optional parameters./ > >>>> [I think this is probably a hangover from the previous version.] > >>>> > >>>> s7: s/Cryptographic system may also allow/The cryptographic system > >>>> may also allow/ > >>>> > >>>> s7: > >>>>> the usage of SRTP [RFC3711] is recommended. > >>>> RECOMMENDED? > >>>> > >>>> s10.2: I suspect that RFC 3551 is normative. > > > > > > -- > > Surveillance is pervasive. Go Dark. > > > > > -- > Henrik Lundin | WebRTC Software Eng | hlundin@google.com > | +46 70 646 13 41 > From nobody Tue Aug 25 06:56:37 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5C71B31FD; Tue, 25 Aug 2015 06:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8_1AW9R_9vw; Tue, 25 Aug 2015 06:56:31 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6482A1B31C8; Tue, 25 Aug 2015 06:56:25 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7PDu5ud084391 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 25 Aug 2015 08:56:15 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Henrik Lundin" Date: Tue, 25 Aug 2015 08:56:04 -0500 Message-ID: <272CCA38-0FE6-4E95-BCAD-C8CB090C5250@nostrum.com> In-Reply-To: References: <55A3A7F1.8010109@dial.pipex.com> <55B9DCCE.1050902@alvestrand.no> <73A192FD-294B-4D94-8B27-75E7CF835E58@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: draft-ietf-payload-vp8.all@ietf.org, Elwyn Davies , payload-chairs@ietf.org, payload@ietf.org Subject: Re: [payload] Gen-art 2nd LC review of draft-ietf-payload-vp8-16 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 13:56:35 -0000 Excellent, thanks! On 25 Aug 2015, at 1:48, Henrik Lundin wrote: > Hi Ben, > > We have an update. We're reviewing it internally right now. You can expect > a new submission shortly. > > Thanks! > /Henrik > > > On Mon, Aug 24, 2015 at 11:21 PM, Ben Campbell wrote: > >> (- GenART and IETF lists) >> >> Hi Harald, >> >> Any updates? >> >> Thanks! >> >> Ben. >> >> On 30 Jul 2015, at 3:14, Harald Alvestrand wrote: >> >>> Unfortunately this is vacation time in Scandinavia - won't do anything >>> with this until mid-August, I'm afraid. (Henrik might.) >>> >>> So it'll have to wait another 2 telechats or so..... >>> >>> >>> On 07/29/2015 11:58 PM, Ben Campbell wrote: >>>> Hi VP8 Authors: >>>> >>>> Has there been a response to Elwyn's Gen-ART review from the authors? >>>> If so, I haven't seen it. (I did see Colin's response). >>>> >>>> Based Elwyn's review, and on Harald's response to my earlier >>>> questions, I assume that the authors will wish to update the draft >>>> before it goes back to an IESG telechat. If that's not the case, >>>> please let me know. Please be advised that tomorrow (July 30) is the >>>> nominal deadline for getting things on the August 6 telechat. >>>> >>>> Thanks! >>>> >>>> Ben. >>>> >>>> >>>> On 13 Jul 2015, at 15:57, Ben Campbell wrote: >>>> >>>>> (+payload and Harald) >>>>> >>>>> Elwyn: Thanks for the detailed review! >>>>> >>>>> Authors: Please address Elwyn's comments at your earliest >>>>> convenience. There's quite a bit here, and I assume we will need a >>>>> new revision before taking this to the IESG telechat, but it would be >>>>> helpful to discuss any proposed changes via email before submitting. >>>>> >>>>> Thanks! >>>>> >>>>> Ben. >>>>> >>>>> >>>>> On 13 Jul 2015, at 6:58, Elwyn Davies wrote: >>>>> >>>>>> I am the assigned Gen-ART reviewer for this draft. For background on >>>>>> Gen-ART, please see the FAQ at >>>>>> >>>>>> . >>>>>> >>>>>> Please resolve these comments along with any other Last Call comments >>>>>> you may receive. >>>>>> >>>>>> Document: draft-ietf-payload-vp8-16.txt >>>>>> Reviewer: Elwyn Davies >>>>>> Review Date: 2015/07/10 >>>>>> IETF LC End Date: 2015/07/13 >>>>>> IESG Telechat date: (if known) - >>>>>> >>>>>> Summary: Gosh, it has been a long time since the last review! >>>>>> >>>>>> Major issues: >>>>>> >>>>>> Minor issues: >>>>>> s4.2: Various of the frame indices either SHOULD or, in the case of >>>>>> KEYIDX, MAY start at random values. The rationale(s) for these >>>>>> requirements are not explained - nor is the reason why it it is only a >>>>>> MAY for KEYIDX whereas it is SHOULD for PictureID and what might >> happen >>>>>> were the MAY/SHOULD to be ignored. >>>>>> >>>>>> Is the rationale something that should be mentioned in the security >>>>>> considerations? >>>>>> >>>>>> s10.1: The downref to RFC 6386 identified by idnits was duly noted >>>>>> in the last call >>>>>> announcement. I don't have a problem with the downref. >>>>>> >>>>>> Nits/editorial comments: >>>>>> >>>>>> General: Consistent usage of "prediction and mode" vs >>>>>> "prediction/mode" would be desirable. >>>>>> >>>>>> s1, para 2: Needs to introduce the 'macroblock' jargon defined in >>>>>> RFC 6386. Suggest: >>>>>> OLD: >>>>>> VP8 is based on decomposition of frames into square sub-blocks of >>>>>> pixels, prediction of such sub-blocks using previously constructed >>>>>> blocks, and... >>>>>> NEW: >>>>>> VP8 is based on decomposition of frames into square sub-blocks of >>>>>> pixels known as "macroblocks" (see Section 2 of [RFC6386]). >> Prediction >>>>>> of such sub-blocks using previously constructed blocks, and... >>>>>> END >>>>>> >>>>>> s2: There are a number of technical terms brought over from RFC 6386. >>>>>> These should be listed in s2. At least the following would be in >>>>>> the list: >>>>>> key frame, interframe, golden frame, altref frame, macroblock. >>>>>> Also the terms picture selection index (RPSI) and slice loss >>>>>> indication (SLI) from RFC 4585. >>>>>> >>>>>> s3, para 2: Providing a reference to explain what temporal scalability >>>>>> and the hierarchy selection is all about would be useful. One >>>>>> possibility >>>>>> would be: >>>>>> >>>>>> Lim, J. Yang, and B. Jeon,”Fast Coding Mode Decision for Scalable >>>>>> Video Coding”, >>>>>> 10th Int’l Conf. on Advanced Communication Technology, vol. 3, pp. >>>>>> 1897-1900, 2008. >>>>>> >>>>>> It would also help to add a pointer to the TL0PICIDX description in >>>>>> s4.2, thus: >>>>>> ADD: >>>>>> Support for temporal scalability is provided by the optional >>>>>> TL0PICIDX and TID/Y/KEYIDX >>>>>> fields described in Section 4.2. >>>>>> END >>>>>> >>>>>> ss3 and 4: The discussion of how the frame payload might or might >>>>>> not be distributed across >>>>>> multiple packets is not very clear. The draft has in mind a >>>>>> 'preferred use case' (para 1 >>>>>> of s4.4 says: >>>>>> >>>>>>> In the preferred use case, the S bit and PID fields >>>>>>> described in Section 4.2 should be used to indicate what the packet >>>>>>> contains. >>>>>> >>>>>> I think it would be helpful to be a bit more positive about this in >>>>>> s3, para 3: >>>>>> OLD: >>>>>> This memo >>>>>> allows the partitions to be sent separately or in the same RTP >>>>>> packet. It may be beneficial for decoder error-concealment to send >>>>>> the partitions in different packets, even though it is not mandatory >>>>>> according to this specification. >>>>>> NEW: >>>>>> Accordingly, this document RECOMMENDS that the frame is packetized >>>>>> by the sender >>>>>> with each data partition in a separate packet or packets. This may >>>>>> be beneficial >>>>>> for decoder error concealment and the payload format described in >>>>>> Section 4 provides >>>>>> fields that allow the partitions to be identified even if the first >>>>>> partition is >>>>>> not available. The sender can, alternatively, aggregate the data >>>>>> partitions into >>>>>> a single data stream and, optionally, split it into several packets >>>>>> without >>>>>> consideration of the partition boundaries. The receiver can use the >>>>>> length >>>>>> information in the first partition to identify the partitions during >>>>>> decoding. >>>>>> END >>>>>> >>>>>> s4/Figure 1: s/bytes/octets/ (2 places) >>>>>> >>>>>> Figure 1, caption: s/sequel/Sections 4.2 and 4.3/ >>>>>> >>>>>> Figure 1: The format shown is correct only for the first packet in a >>>>>> frame. Subsequent >>>>>> packets will not contain the payload header and will have later >>>>>> octets of the frame payload. >>>>>> This should be mentioned in drawing and/or in the caption. >>>>>> >>>>>> s4.1, last two paras: >>>>>>> Sequence number: The sequence numbers are monotonically increasing >>>>>>> and set as packets are sent. >>>>>>> >>>>>>> The remaining RTP header fields are used as specified in >>>>>>> [RFC3550]. >>>>>> Redefining the Sequence Number field seems gratuitous and >>>>>> potentially dangerous, >>>>>> given that it is *very carefully* defined in RFC 3550 and the >>>>>> overall intent does >>>>>> not seem any different from that in RFC 3550. OTOH a note about the >>>>>> (non?-)use of the X bit >>>>>> and the Payload Type field (PT) would be useful. I suggest >>>>>> replacing the paras above with: >>>>>> NEW: >>>>>> X bit: MUST be 0. The VP8 RTP profile does not use the RTP Header >>>>>> Extension capability. >>>>>> >>>>>> PT (Payload Type): In line with the policy in Section 3 of >>>>>> [RFC3551], applications >>>>>> using the VP8 RTP payload profile MUST assign a dynamic payload type >>>>>> number to >>>>>> be used in each RTP session and provide a mechanism to indicate the >>>>>> mapping. >>>>>> See Section 6.2 for the mechanism to be used with the Session >>>>>> Description Protocol (SDP) >>>>>> [RFC4566]. >>>>>> >>>>>> The remaining RTP Fixed Header Fields (V, P, CC, sequence number, >>>>>> SSRC and CSRC >>>>>> identfiers) are used as specified in Section 5.1 of [RFC5330]. >>>>>> END >>>>>> Note that this may be considered to make the reference to RFC 3551 >>>>>> normative. >>>>>> >>>>>> s4.2, X bit: There is potential for confusion between the X bit in >>>>>> the fixed header >>>>>> and the X bit in the VP8 Payload Descriptor. Perhaps changing this >>>>>> to C for control bits >>>>>> would avoid the problem. >>>>>> >>>>>> s4.2, M bit: Similarly, it might be better to use B (for BIG) in >>>>>> place of M to avoid confusion. >>>>>> >>>>>> s4.2, para 7 after Fig 2: For consistency: >>>>>> OLD: >>>>>> When the X bit is set to 1 in the first octet, the extension bit >>>>>> field octet MUST be provided as the second octet. If the X bit is 0, >>>>>> the extension bit field octet MUST NOT be present, and no extensions >>>>>> (I, L, T, or K) are permitted. >>>>>> NEW: >>>>>> When the X [or C] bit is set to 1 in the first octet, the Extended >>>>>> Control Bits >>>>>> field octet MUST be provided as the second octet. If the X [or C] >>>>>> bit is 0, >>>>>> the extension bit field octet MUST NOT be present, and no extensions >>>>>> (I, L, T, or K) are permitted. >>>>>> END >>>>>> >>>>>> s4.2: The issue of using either 'wrap' or 'restart' but not both for >>>>>> restarting number sequences has been raised in various comments by >>>>>> IESG members. >>>>>> >>>>>> s4.2, TL0PICIDX: I think, given the statements in s3 about not >>>>>> defining the hierarchy, that more explanation is needed of what the >>>>>> 'lowest or base layer' actually means. >>>>>> >>>>>> s4.2, TL0PICIDX: >>>>>>> If TID is larger than 0, TL0PICIDX >>>>>>> indicates which base layer frame the current image depends on. >>>>>>> TL0PICIDX MUST be incremented when TID is 0. >>>>>> What happens if L=1 but both T=0 and K=0 so that there is no TID >>>>>> value present? Or indeed if T=0 but K=1 so that the TID field is >>>>>> there but 'MUST be ignored by the receiver' (definition of TID >> field)? >>>>>> >>>>>> s4.3: It would be useful to include the section number (9.1) where >>>>>> the uncompressed data chunk specification is found. I was somewhat >>>>>> surprised that the ordering is reversed in the protocol spec. >>>>>> >>>>>> s4.3, VER: The receiver should validate this field - currently only >>>>>> values 0-3 are valid. >>>>>> >>>>>> s4.3, SizeN: Make it clear these are integer fields: s/in Size0,/in >>>>>> integer fields Size0,/ >>>>>> >>>>>> s4.3 and s4.4: It would be helpful to implementers to explain what >>>>>> the offsets in the first partition payload are for the additional >>>>>> partition count and additional partition sizes. Having rummaged >>>>>> around in RFC 6386, I have to say that I am unclear whether the >>>>>> values are placed after the full chunk of data indicated by >>>>>> 1stPartitionSize or are part of this data. And if the latter is the >>>>>> case, how to work out where the partition sizes are. I guess that >>>>>> they ought to be at offset (1stPartitionSize+10 - key frame - or >>>>>> 1stPartitionSize+3 - interframe) in the VP8 Payload field as it is >>>>>> difficult to work out where they are without decoding the partition >>>>>> otherwise. Also exactly how many partition sizes to expect - I >>>>>> think I read in RFC 6386 that the last partition size is implicit. >>>>>> Help! >>>>>> >>>>>> In the course of clearing this up, it might be appropriate to move >>>>>> the last sentence of the first para of s4.4 and the second para of >>>>>> s4.4 into s4.3 as part of the explanation. This is the relevant text: >>>>>>> Note that the length of the first partition can >>>>>>> always be obtained from the first partition size parameter in the VP8 >>>>>>> payload header. >>>>>>> >>>>>>> The VP8 bitstream format [RFC6386] specifies that if multiple DCT/WHT >>>>>>> partitions are produced, the location of each partition start is >>>>>>> found at the end of the first (prediction/mode) partition. In this >>>>>>> RTP payload specification, the location offsets are considered to be >>>>>>> part of the first partition. >>>>>> >>>>>> >>>>>> s4.4: I found this section very difficult to parse. It is a bit >>>>>> 'stream of consciousness' and would benefit from a reordering and >>>>>> rewrite. Suggestion (assuming the second para gets moved to s4.3): >>>>>> NEW SECTION 4.4: >>>>>> An encoded VP8 frame can be divided into two or more partitions, as >>>>>> described in Section 1. It is OPTIONAL for a packetizer implementing >>>>>> this RTP specification >>>>>> to pay attention to the partition boundaries within an encoded frame. >>>>>> If packetization of a frame is done without considering the partition >>>>>> boundaries, the PID field MAY be set to zero for all packets, and the >>>>>> S bit MUST NOT be set to one for any other packet than the first. >>>>>> >>>>>> If the preferred usage suggested in Section 3 is followed, with each >>>>>> packet >>>>>> carrying data from exactly one partition, the S bit and PID fields >>>>>> described in Section 4.2 SHOULD be used to indicate what the packet >>>>>> contains. The PID field should indicate which partition the first >>>>>> octet of the payload belongs to, and the S bit indicates that the >>>>>> packet starts on a new partition. >>>>>> >>>>>> If the packetizer does not pay attention to the partition >>>>>> boundaries, one >>>>>> packet can contain a fragment of a partition, a complete partition, >>>>>> or an >>>>>> aggregate of fragments and partitions. There is no explicit >>>>>> signaling of >>>>>> partition boundaries in the payload and the partition lengths at the >>>>>> end of >>>>>> the first partition have to be used to identify the boundaries. >>>>>> Partitions >>>>>> MUST be aggregated in decoding order. Two fragments from different >>>>>> partitions MAY be aggregated into the same packet along with one or >>>>>> more >>>>>> complete partitions. >>>>>> >>>>>> In all cases, the payload of a packet MUST contain data from only >>>>>> one video >>>>>> frame. Consequently the set of packets carrying the data from a >>>>>> particular >>>>>> frame will contain exactly one VP8 Payload Header (see Section 4.3) >>>>>> carried >>>>>> in the first packet of the frame. The last, or only, packet >>>>>> carrying data for the >>>>>> frame MUST have the M bit set in the RTP header. >>>>>> >>>>>> s4.5.1: Th algorithm only applies for the RECOMMENDED use case with >>>>>> partitions in separate packets. >>>>>> This should be noted. >>>>>> >>>>>> s5.2, last para: s/only parts of the frame is corrupted./only part >>>>>> of the frame is corrupted./ >>>>>> >>>>>> s6: s/This payload format has two required parameters./This payload >>>>>> format has two optional parameters./ >>>>>> [I think this is probably a hangover from the previous version.] >>>>>> >>>>>> s7: s/Cryptographic system may also allow/The cryptographic system >>>>>> may also allow/ >>>>>> >>>>>> s7: >>>>>>> the usage of SRTP [RFC3711] is recommended. >>>>>> RECOMMENDED? >>>>>> >>>>>> s10.2: I suspect that RFC 3551 is normative. >>> >>> >>> -- >>> Surveillance is pervasive. Go Dark. >> > > > > -- > Henrik Lundin | WebRTC Software Eng | hlundin@google.com | +46 70 646 13 41 From nobody Tue Aug 25 06:58:52 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7581D1B2FE3; Tue, 25 Aug 2015 06:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akSvXV8eAC9q; Tue, 25 Aug 2015 06:58:50 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8683D1B2FE2; Tue, 25 Aug 2015 06:58:50 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7PDwVZd084558 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 25 Aug 2015 08:58:41 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Harald Alvestrand" Date: Tue, 25 Aug 2015 08:58:31 -0500 Message-ID: <7E888827-50DF-47FA-A85A-B2B955F302A2@nostrum.com> In-Reply-To: <55DC126B.6020002@alvestrand.no> References: <55A3A7F1.8010109@dial.pipex.com> <55B9DCCE.1050902@alvestrand.no> <73A192FD-294B-4D94-8B27-75E7CF835E58@nostrum.com> <55DC126B.6020002@alvestrand.no> MIME-Version: 1.0 X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: draft-ietf-payload-vp8.all@ietf.org, payload-chairs@ietf.org, Elwyn Davies , payload@ietf.org Subject: Re: [payload] Gen-art 2nd LC review of draft-ietf-payload-vp8-16 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 13:58:51 -0000 On 25 Aug 2015, at 1:59, Harald Alvestrand wrote: > Den 25. aug. 2015 08:48, skrev Henrik Lundin: > >> Hi Ben, >> >> We have an update. We're reviewing it internally right now. You can >> expect a new submission shortly. > > > I'm doing a round of grammar review.... do you want to see it now, or > should we just submit an updated I-D and notify you when it's up? > > Harald Please submit it when you are ready. Thanks! Ben. From nobody Tue Aug 25 15:22:09 2015 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979221AC3EC for ; Tue, 25 Aug 2015 15:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-Wp7kLJGXG9 for ; Tue, 25 Aug 2015 15:22:05 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF0C31B2F1D for ; Tue, 25 Aug 2015 15:22:05 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t7PMLkFK030843 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 25 Aug 2015 17:21:57 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Wang, Ye-Kui" Date: Tue, 25 Aug 2015 17:21:45 -0500 Message-ID: <4DDD1F48-F61F-4FDE-A598-85E80E534983@nostrum.com> In-Reply-To: References: <20150825014443.11024.77662.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: Brian E Carpenter , payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-h265-14.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 22:22:07 -0000 Thanks! I've requested that this go in the September 3 telechat agenda. Ben. On 24 Aug 2015, at 20:52, Wang, Ye-Kui wrote: > This version addresses the comments from the following reviews: > - The SDP Directorate Review > - The Gen-ART Last Call review > - OPS-DIR Review > > All the changes are purely editorial nits. > > BR, YK > > -----Original Message----- > From: payload [mailto:payload-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Monday, August 24, 2015 6:45 PM > To: i-d-announce@ietf.org > Cc: payload@ietf.org > Subject: [payload] I-D Action: draft-ietf-payload-rtp-h265-14.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Audio/Video Transport Payloads > Working Group of the IETF. > > Title : RTP Payload Format for H.265/HEVC Video > Authors : Ye-Kui Wang > Yago Sanchez > Thomas Schierl > Stephan Wenger > Miska M. Hannuksela > Filename : draft-ietf-payload-rtp-h265-14.txt > Pages : 99 > Date : 2015-08-24 > > Abstract: > This memo describes an RTP payload format for the video coding > standard ITU-T Recommendation H.265 and ISO/IEC International > Standard 23008-2, both also known as High Efficiency Video Coding > (HEVC) and developed by the Joint Collaborative Team on Video > Coding (JCT-VC). The RTP payload format allows for packetization > of one or more Network Abstraction Layer (NAL) units in each RTP > packet payload, as well as fragmentation of a NAL unit into > multiple RTP packets. Furthermore, it supports transmission of > an HEVC bitstream over a single as well as multiple RTP streams. > When multiple RTP streams are used, a single or multiple > transports may be utilized. The payload format has wide > applicability in videoconferencing, Internet video streaming, and > high bit-rate entertainment-quality video, among others. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-h265/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-payload-rtp-h265-14 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-h265-14 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload