From adamsobieski@hotmail.com Sat Dec 1 21:15:35 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD2C21E80A3 for ; Sat, 1 Dec 2012 21:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.755 X-Spam-Level: * X-Spam-Status: No, score=1.755 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8M5HtnIFIAU for ; Sat, 1 Dec 2012 21:15:34 -0800 (PST) Received: from snt0-omc2-s27.snt0.hotmail.com (snt0-omc2-s27.snt0.hotmail.com [65.55.90.102]) by ietfa.amsl.com (Postfix) with ESMTP id 116EC21E8091 for ; Sat, 1 Dec 2012 21:15:34 -0800 (PST) Received: from SNT002-W46 ([65.55.90.73]) by snt0-omc2-s27.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 1 Dec 2012 21:15:32 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_8da7161c-6e3b-4a63-ab02-09efb42bc10e_" X-Originating-IP: [174.100.43.136] From: Adam Sobieski To: "payload@ietf.org" Date: Sun, 2 Dec 2012 05:15:32 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 02 Dec 2012 05:15:32.0867 (UTC) FILETIME=[0DA5BD30:01CDD04C] Subject: [payload] Velocity Vector Fields, Computer Vision and Digital Video X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 05:15:35 -0000 --_8da7161c-6e3b-4a63-ab02-09efb42bc10e_ Content-Type: text/plain; charset="iso-8859-3" Content-Transfer-Encoding: base64 SW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSwNClBheWxvYWQgV29ya2luZyBHcm91cCwN CiANCkdyZWV0aW5ncy4gIEEgZGlnaXRhbCB2aWRlbyB0ZWNobm9sb2d5IHRvcGljIGlzIHRoYXQg Y2hhbGxlbmdlcyBpbiBtb3Rpb24gZXN0aW1hdGlvbiBoYXZlIGluY2x1ZGVkIHRoYXQgbW90aW9u IHdhcyB0aHJlZS1kaW1lbnNpb25hbCB3aGlsZSB2aWRlbyBpbWFnZXMgd2VyZSBwcm9qZWN0aW9u cyBvZiAzRCBtb3Rpb24gb250byB0d28tZGltZW5zaW9uYWwgYml0bWFwcy4gIFZlbG9jaXR5IGFu ZCBkaWdpdGFsIHZpZGVvIGFyZSBpbnRlcnJlbGF0ZWQgdG9waWNzIGFuZCBleGNpdGluZyByZXNl YXJjaCwgYXBwbGljYWJsZSB0byBib3RoIGNvbXB1dGVyIHZpc2lvbiBhbmQgZGlnaXRhbCB2aWRl byB0b3BpY3MsIGlzIHVuZGVyd2F5IHdpdGggcmVnYXJkIHRvIHJlYWwtdGltZSAzRCB2ZWxvY2l0 eSB2ZWN0b3IgZmllbGRzIHdpdGggS2luZWN0IHNlbnNvcnMuDQogDQpBbiBJQ0NWIDIwMTEgcGFw ZXIsIEtpbmVjdGluZyB0aGUgRG90czogUGFydGljbGUgQmFzZWQgU2NlbmUgRmxvdyBmcm9tIERl cHRoIFNlbnNvcnMsIGJ5IFNpbW9uIEhhZGZpZWxkIChodHRwOi8vcGVyc29uYWwuZWUuc3VycmV5 LmFjLnVrL1BlcnNvbmFsL1IuQm93ZGVuL3B1YmxpY2F0aW9ucy8yMDExL0lDQ1YvSGFkZmllbGRf SUNDVjExLnBkZiwgaHR0cDovL3d3dy55b3V0dWJlLmNvbS93YXRjaD92PTEwQ1dPWmNHTXYwKSBp bGx1c3RyYXRlcyB2ZWxvY2l0eSB2ZWN0b3IgZmllbGRzIGZyb20gS2luZWN0IGRhdGEgYW5kIGRl c2NyaWJlcyBhIENQVSBpbXBsZW1lbnRhdGlvbiB3aGlsZSBhIHBhcmFsbGVsIEdQVSBpbXBsZW1l bnRhdGlvbiB3aXRoIHJlYWwtdGltZSBwZXJmb3JtYW5jZSBpcyBhbnRpY2lwYXRlZC4NCiANCldp dGggcmVnYXJkIHRvIDNEIHZpZGVvLCBjdXJyZW50IHRlY2hub2xvZ2llcyBpbmNsdWRlIE1QRUcg bXVsdGl2aWV3IGNvZGluZyAoaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXBheWxv YWQtcnRwLW12Yy0wMi50eHQpLCBmcmVlIHZpZXdwb2ludCB2aWRlbywgYW5kIDJELXBsdXMtZGVw dGggdmlkZW8sIHJlc2VtYmxpbmcgdGhlIGRhdGEgZnJvbSBSR0JEIHNlbnNvcnMsIGFuZCwgaW4g YWRkaXRpb24gdG8gcHJldmlvdXMgdGVjaG5pcXVlcyBmb3Igc3VwZXItcmVzb2x1dGlvbiwgYm90 aCB0aGUgZGVwdGggc3RyZWFtIGRhdGEgYW5kIGNvbXB1dGVkIGRhdGEsIHN1Y2ggYXMgc3VyZmFj ZSBnZW9tZXRyeSBhbmQgdmVsb2NpdHkgdmVjdG9yIGZpZWxkcywgY2FuIGJlIG9mIHVzZSB0byBo ZXVyaXN0aWNzIGZvciBzdXBlci1yZXNvbHZpbmcgdmlkZW8gc3RyZWFtcy4gMkQtUGx1cy1EZXB0 aCBCYXNlZCBSZXNvbHV0aW9uIGFuZCBGcmFtZS1yYXRlIFVwLWNvbnZlcnNpb24gVGVjaG5pcXVl IGZvciBEZXB0aCBWaWRlbyBieSBKaW53b29rIENob2ksIERvbmdibyBNaW4sIGFuZCBLd2FuZ2hv b24gU29obiBkaXNjdXNzZXMgc29tZSByZWxhdGVkIHN1cGVyLXJlc29sdXRpb24gdG9waWNzLg0K IA0KSW50ZXJlc3Rpbmcgc2NlbmFyaW9zIGluY2x1ZGU6IHZpZGVvIGNhbGxzLCB2aWRlbyBjb25m ZXJlbmNlcywgdmlkZW8gYmxvZ3MgYW5kIHZpZGVvIGZvcnVtcy4gV2l0aCB0aGUgc3VwZXItcmVz b2x1dGlvbiBvZiBzdHJlYW1zIGZyb20gUkdCRCBzZW5zb3JzLCBzdHJlYW1pbmcgYW5kIHN0b3Jh Z2UgZWZmaWNpZW5jaWVzIGNhbiBiZSBlbmhhbmNlZC4gIEluIGFkZGl0aW9uIHRvIDJELXBsdXMt ZGVwdGgsIHN0ZXJlb3Njb3BpYyAzRCB2aWRlbywgYW5kIE1QRUcgTVZDLCBhbHNvIHBvc3NpYmxl IGFyZTogM0QgdmlkZW8gc3RyZWFtaW5nLCB2aWRlbyBjYWxsaW5nIGFuZCBjb25mZXJlbmNpbmcs IGludGVyb3BlcmFibGUgd2l0aCBoZWFkIHRyYWNraW5nLCAyRCtWZWxvY2l0eSBvciBSR0JWIHZp ZGVvLCBhbmQgM0QgdmlkZW8gZm9ybWF0cyBiYXNlZCB1cG9uLCBpbnN0ZWFkIG9mIHNlcXVlbmNl cyBvZiBiaXRtYXBzLCBzZXF1ZW5jZXMgb2YgcG9pbnQgY2xvdWRzIG9yIDNEIHN1cmZhY2VzLg0K IA0KV2l0aCByZWdhcmQgdG8gdGhlIG51bWVyaWNhbCBwcmVjaXNpb24gb2YgZGVwdGggbWVhc3Vy ZW1lbnRzIGFuZCB0aGF0IG9mIHZlbG9jaXR5IGFuZCBhY2NlbGVyYXRpb24gdmVjdG9yIGZpZWxk cywgZnVuY3Rpb25zIHRvIG9idGFpbiAzRCBwcm9iYWJpbGl0eSBkaXN0cmlidXRpb25zIGFyb3Vu ZCBlYWNoIDNEIHBvaW50IGFyZSBvZiBpbnRlcmVzdC4gQWNjdXJhY3kgQW5hbHlzaXMgb2YgS2lu ZWN0IERlcHRoIERhdGEgYnkgSy4gS2hvc2hlbGhhbSBkaXNjdXNzZXMgdGhlIG51bWVyaWNhbCBw cmVjaXNpb24gb2YgS2luZWN0IHNlbnNvciBkZXB0aCBtZWFzdXJlbWVudHMuIDNEIHdpdGggS2lu ZWN0IGJ5IEphbiBTbWlzZWssIE1pY2hhbCBKYW5jb3NlayBhbmQgVG9tYXMgUGFqZGxhIGFsc28g ZGlzY3Vzc2VzIHRoZSBjYWxpYnJhdGlvbiBvZiBhbmQgYWNjdXJhY3kgYW5hbHlzaXMgb2YgS2lu ZWN0IHNlbnNvcnMgYXMgd2VsbCBhcyBzdHJ1Y3R1cmUgZnJvbSBtb3Rpb24uICBBY2N1cmFjeSBh bmFseXNpcyBvZiBkZXB0aCBtZWFzdXJlbWVudHMgYW5kIG9mIHRoZSB0aW1lc3RhbXBzIG9mIHRo ZSBkZXB0aCBhbmQgUkdCIGRhdGEgc3RyZWFtcyBjYW4gYmUgb2YgdXNlIHRvIG51bWVyaWNhbCBh bGdvcml0aG1zIGZvciBwcmVjaXNlbHkgb2J0YWluaW5nIGFuZCB1dGlsaXppbmcgZGVwdGggbWVh c3VyZW1lbnRzIGFuZCB2ZWxvY2l0eSBhbmQgYWNjZWxlcmF0aW9uIHZlY3RvciBmaWVsZHMuDQog DQpBZGRpdGlvbmFsbHksIHRvd2FyZHMgY29tYmluZWQgdXNlcyBvZiBkZXB0aCBhbmQgUkdCIGRh dGEsIHdoZXJlIGRlcHRoIGRhdGEgY2FuIHN1cGVyLXJlc29sdmUgUkdCIGRhdGEgYW5kIFJHQiBk YXRhIGNhbiBzdXBlci1yZXNvbHZlIGRlcHRoIGRhdGEsIHNvbWUgYXBwcm9hY2hlcyBpbmNsdWRl IGVkZ2UgZGV0ZWN0aW9uLCBzaWxob3VldHRlcywgdmlzdWFsIGh1bGwgY29uc3RydWN0aW9uLCBh bmQgdG9waWNzIGRpc2N1c3NlZCBpbiBTaWxob3VldHRlLWJhc2VkIDNEIE1vZGVsIFJlY29uc3Ry dWN0aW9uIGZyb20gTXVsdGlwbGUgSW1hZ2VzIGJ5IEFkZW0gWWFzYXIgTXVsYXlpbSwgVWxhcyBZ uWxtYXosIGFuZCBWb2xrYW4gQXRhbGF5LCBhbmQgU2hhcGUtRnJvbS1TaWxob3VldHRlIG9mIEFy dGljdWxhdGVkIE9iamVjdHMgYW5kIGl0cyBVc2UgZm9yIEh1bWFuIEJvZHkgS2luZW1hdGljcyBF c3RpbWF0aW9uIGFuZCBNb3Rpb24gQ2FwdHVyZSBieSBHZXJtYW4gSy4gTS4gQ2hldW5nLCBTaW1v biBCYWtlciwgYW5kIFRha2VvIEthbmFkZS4gIFNoYXBlIGZyb20gc2hhZGluZyBpcyBkaXNjdXNz ZWQgaW4gU2hhcGUgZnJvbSBTaGFkaW5nOiBBIFN1cnZleSBieSBSdW8gWmhhbmcsIFBpbmctU2lu ZyBUc2FpLCBKYW1lcyBFZHdpbiBDcnllciwgYW5kIE11YmFyYWsgU2hhaCBhbmQgUmVjb3Zlcmlu ZyBTdXJmYWNlIFJlZmxlY3RhbmNlIGFuZCBNdWx0aXBsZSBMaWdodCBMb2NhdGlvbnMgYW5kIElu dGVuc2l0aWVzIGZyb20gSW1hZ2UgRGF0YSBieSBTLiBYdSBhbmQgQS4gTS4gV2FsbGFjZS4NCg0K DQoNCktpbmQgcmVnYXJkcywNCiANCkFkYW0gU29iaWVza2kgCQkgCSAgIAkJICA= --_8da7161c-6e3b-4a63-ab02-09efb42bc10e_ Content-Type: text/html; charset="iso-8859-3" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxzdHlsZT48IS0tDQouaG1tZXNzYWdlIFANCnsNCm1hcmdpbjowcHg7 DQpwYWRkaW5nOjBweA0KfQ0KYm9keS5obW1lc3NhZ2UNCnsNCmZvbnQtc2l6ZTogMTJwdDsNCmZv bnQtZmFtaWx5OkNhbGlicmkNCn0NCi0tPjwvc3R5bGU+PC9oZWFkPg0KPGJvZHkgY2xhc3M9J2ht bWVzc2FnZSc+PGRpdiBkaXI9J2x0cic+SW50ZXJuZXQgRW5naW5lZXJpbmcgVGFzayBGb3JjZSw8 YnIvPg0KUGF5bG9hZCBXb3JraW5nIEdyb3VwLDxici8+DQo8YnIvPiANCkdyZWV0aW5ncy4gIEEg ZGlnaXRhbCB2aWRlbyB0ZWNobm9sb2d5IHRvcGljIGlzIHRoYXQgY2hhbGxlbmdlcyBpbiBtb3Rp b24gZXN0aW1hdGlvbiBoYXZlIGluY2x1ZGVkIHRoYXQgbW90aW9uIHdhcyB0aHJlZS1kaW1lbnNp b25hbCB3aGlsZSB2aWRlbyBpbWFnZXMgd2VyZSBwcm9qZWN0aW9ucyBvZiAzRCBtb3Rpb24gb250 byB0d28tZGltZW5zaW9uYWwgYml0bWFwcy4gIFZlbG9jaXR5IGFuZCBkaWdpdGFsIHZpZGVvIGFy ZSBpbnRlcnJlbGF0ZWQgdG9waWNzIGFuZCBleGNpdGluZyByZXNlYXJjaCwgYXBwbGljYWJsZSB0 byBib3RoIGNvbXB1dGVyIHZpc2lvbiBhbmQgZGlnaXRhbCB2aWRlbyB0b3BpY3MsIGlzIHVuZGVy d2F5IHdpdGggcmVnYXJkIHRvIHJlYWwtdGltZSAzRCB2ZWxvY2l0eSB2ZWN0b3IgZmllbGRzIHdp dGggS2luZWN0IHNlbnNvcnMuPEJSPg0KPGJyLz4gDQpBbiBJQ0NWIDIwMTEgcGFwZXIsIDxpPktp bmVjdGluZyB0aGUgRG90czogUGFydGljbGUgQmFzZWQgU2NlbmUgRmxvdyBmcm9tIERlcHRoIFNl bnNvcnM8L2k+LCBieSBTaW1vbiBIYWRmaWVsZCAoPGEgaHJlZj0iaHR0cDovL3BlcnNvbmFsLmVl LnN1cnJleS5hYy51ay9QZXJzb25hbC9SLkJvd2Rlbi9wdWJsaWNhdGlvbnMvMjAxMS9JQ0NWL0hh ZGZpZWxkX0lDQ1YxMS5wZGYiPmh0dHA6Ly9wZXJzb25hbC5lZS5zdXJyZXkuYWMudWsvUGVyc29u YWwvUi5Cb3dkZW4vcHVibGljYXRpb25zLzIwMTEvSUNDVi9IYWRmaWVsZF9JQ0NWMTEucGRmPC9h PiwgPGEgaHJlZj0iaHR0cDovL3d3dy55b3V0dWJlLmNvbS93YXRjaD92PTEwQ1dPWmNHTXYwIj5o dHRwOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9MTBDV09aY0dNdjA8L2E+KSBpbGx1c3RyYXRl cyB2ZWxvY2l0eSB2ZWN0b3IgZmllbGRzIGZyb20gS2luZWN0IGRhdGEgYW5kIGRlc2NyaWJlcyBh IENQVSBpbXBsZW1lbnRhdGlvbiB3aGlsZSBhIHBhcmFsbGVsIEdQVSBpbXBsZW1lbnRhdGlvbiB3 aXRoIHJlYWwtdGltZSBwZXJmb3JtYW5jZSBpcyBhbnRpY2lwYXRlZC48QlI+DQo8YnIvPiANCldp dGggcmVnYXJkIHRvIDNEIHZpZGVvLCBjdXJyZW50IHRlY2hub2xvZ2llcyBpbmNsdWRlIE1QRUcg bXVsdGl2aWV3IGNvZGluZyAoPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1p ZXRmLXBheWxvYWQtcnRwLW12Yy0wMi50eHQiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQt aWV0Zi1wYXlsb2FkLXJ0cC1tdmMtMDIudHh0PC9hPiksIGZyZWUgdmlld3BvaW50IHZpZGVvLCBh bmQgMkQtcGx1cy1kZXB0aCB2aWRlbywgcmVzZW1ibGluZyB0aGUgZGF0YSBmcm9tIFJHQkQgc2Vu c29ycywgYW5kLCBpbiBhZGRpdGlvbiB0byBwcmV2aW91cyB0ZWNobmlxdWVzIGZvciBzdXBlci1y ZXNvbHV0aW9uLCBib3RoIHRoZSBkZXB0aCBzdHJlYW0gZGF0YSBhbmQgY29tcHV0ZWQgZGF0YSwg c3VjaCBhcyBzdXJmYWNlIGdlb21ldHJ5IGFuZCB2ZWxvY2l0eSB2ZWN0b3IgZmllbGRzLCBjYW4g YmUgb2YgdXNlIHRvIGhldXJpc3RpY3MgZm9yIHN1cGVyLXJlc29sdmluZyB2aWRlbyBzdHJlYW1z LiA8aT4yRC1QbHVzLURlcHRoIEJhc2VkIFJlc29sdXRpb24gYW5kIEZyYW1lLXJhdGUgVXAtY29u dmVyc2lvbiBUZWNobmlxdWUgZm9yIERlcHRoIFZpZGVvPC9pPiBieSBKaW53b29rIENob2ksIERv bmdibyBNaW4sIGFuZCBLd2FuZ2hvb24gU29obiBkaXNjdXNzZXMgc29tZSByZWxhdGVkIHN1cGVy LXJlc29sdXRpb24gdG9waWNzLjxCUj4NCjxici8+IA0KSW50ZXJlc3Rpbmcgc2NlbmFyaW9zIGlu Y2x1ZGU6IHZpZGVvIGNhbGxzLCB2aWRlbyBjb25mZXJlbmNlcywgdmlkZW8gYmxvZ3MgYW5kIHZp ZGVvIGZvcnVtcy4gV2l0aCB0aGUgc3VwZXItcmVzb2x1dGlvbiBvZiBzdHJlYW1zIGZyb20gUkdC RCBzZW5zb3JzLCBzdHJlYW1pbmcgYW5kIHN0b3JhZ2UgZWZmaWNpZW5jaWVzIGNhbiBiZSBlbmhh bmNlZC4gIEluIGFkZGl0aW9uIHRvIDJELXBsdXMtZGVwdGgsIHN0ZXJlb3Njb3BpYyAzRCB2aWRl bywgYW5kIE1QRUcgTVZDLCBhbHNvIHBvc3NpYmxlIGFyZTogM0QgdmlkZW8gc3RyZWFtaW5nLCB2 aWRlbyBjYWxsaW5nIGFuZCBjb25mZXJlbmNpbmcsIGludGVyb3BlcmFibGUgd2l0aCBoZWFkIHRy YWNraW5nLCAyRCtWZWxvY2l0eSBvciBSR0JWIHZpZGVvLCBhbmQgM0QgdmlkZW8gZm9ybWF0cyBi YXNlZCB1cG9uLCBpbnN0ZWFkIG9mIHNlcXVlbmNlcyBvZiBiaXRtYXBzLCBzZXF1ZW5jZXMgb2Yg cG9pbnQgY2xvdWRzIG9yIDNEIHN1cmZhY2VzLjxCUj4NCjxici8+IA0KV2l0aCByZWdhcmQgdG8g dGhlIG51bWVyaWNhbCBwcmVjaXNpb24gb2YgZGVwdGggbWVhc3VyZW1lbnRzIGFuZCB0aGF0IG9m IHZlbG9jaXR5IGFuZCBhY2NlbGVyYXRpb24gdmVjdG9yIGZpZWxkcywgZnVuY3Rpb25zIHRvIG9i dGFpbiAzRCBwcm9iYWJpbGl0eSBkaXN0cmlidXRpb25zIGFyb3VuZCBlYWNoIDNEIHBvaW50IGFy ZSBvZiBpbnRlcmVzdC4gPGk+QWNjdXJhY3kgQW5hbHlzaXMgb2YgS2luZWN0IERlcHRoIERhdGE8 L2k+IGJ5IEsuIEtob3NoZWxoYW0gZGlzY3Vzc2VzIHRoZSBudW1lcmljYWwgcHJlY2lzaW9uIG9m IEtpbmVjdCBzZW5zb3IgZGVwdGggbWVhc3VyZW1lbnRzLiA8aT4zRCB3aXRoIEtpbmVjdDwvaT4g YnkgSmFuIFNtaXNlaywgTWljaGFsIEphbmNvc2VrIGFuZCBUb21hcyBQYWpkbGEgYWxzbyBkaXNj dXNzZXMgdGhlIGNhbGlicmF0aW9uIG9mIGFuZCBhY2N1cmFjeSBhbmFseXNpcyBvZiBLaW5lY3Qg c2Vuc29ycyBhcyB3ZWxsIGFzIHN0cnVjdHVyZSBmcm9tIG1vdGlvbi4gIEFjY3VyYWN5IGFuYWx5 c2lzIG9mIGRlcHRoIG1lYXN1cmVtZW50cyBhbmQgb2YgdGhlIHRpbWVzdGFtcHMgb2YgdGhlIGRl cHRoIGFuZCBSR0IgZGF0YSBzdHJlYW1zIGNhbiBiZSBvZiB1c2UgdG8gbnVtZXJpY2FsIGFsZ29y aXRobXMgZm9yIHByZWNpc2VseSBvYnRhaW5pbmcgYW5kIHV0aWxpemluZyBkZXB0aCBtZWFzdXJl bWVudHMgYW5kIHZlbG9jaXR5IGFuZCBhY2NlbGVyYXRpb24gdmVjdG9yIGZpZWxkcy48QlI+DQo8 YnIvPiANCkFkZGl0aW9uYWxseSwgdG93YXJkcyBjb21iaW5lZCB1c2VzIG9mIGRlcHRoIGFuZCBS R0IgZGF0YSwgd2hlcmUgZGVwdGggZGF0YSBjYW4gc3VwZXItcmVzb2x2ZSBSR0IgZGF0YSBhbmQg UkdCIGRhdGEgY2FuIHN1cGVyLXJlc29sdmUgZGVwdGggZGF0YSwgc29tZSBhcHByb2FjaGVzIGlu Y2x1ZGUgZWRnZSBkZXRlY3Rpb24sIHNpbGhvdWV0dGVzLCB2aXN1YWwgaHVsbCBjb25zdHJ1Y3Rp b24sIGFuZCB0b3BpY3MgZGlzY3Vzc2VkIGluIDxpPlNpbGhvdWV0dGUtYmFzZWQgM0QgTW9kZWwg UmVjb25zdHJ1Y3Rpb24gZnJvbSBNdWx0aXBsZSBJbWFnZXM8L2k+IGJ5IEFkZW0gWWFzYXIgTXVs YXlpbSwgVWxhcyBZuWxtYXosIGFuZCBWb2xrYW4gQXRhbGF5LCBhbmQgPGk+U2hhcGUtRnJvbS1T aWxob3VldHRlIG9mIEFydGljdWxhdGVkIE9iamVjdHMgYW5kIGl0cyBVc2UgZm9yIEh1bWFuIEJv ZHkgS2luZW1hdGljcyBFc3RpbWF0aW9uIGFuZCBNb3Rpb24gQ2FwdHVyZTwvaT4gYnkgR2VybWFu IEsuIE0uIENoZXVuZywgU2ltb24gQmFrZXIsIGFuZCBUYWtlbyBLYW5hZGUuICBTaGFwZSBmcm9t IHNoYWRpbmcgaXMgZGlzY3Vzc2VkIGluIDxpPlNoYXBlIGZyb20gU2hhZGluZzogQSBTdXJ2ZXk8 L2k+IGJ5IFJ1byBaaGFuZywgUGluZy1TaW5nIFRzYWksIEphbWVzIEVkd2luIENyeWVyLCBhbmQg TXViYXJhayBTaGFoIGFuZCA8aT5SZWNvdmVyaW5nIFN1cmZhY2UgUmVmbGVjdGFuY2UgYW5kIE11 bHRpcGxlIExpZ2h0IExvY2F0aW9ucyBhbmQgSW50ZW5zaXRpZXMgZnJvbSBJbWFnZSBEYXRhPC9p PiBieSBTLiBYdSBhbmQgQS4gTS4gV2FsbGFjZS48QlI+DQo8YnIvPg0KPGJyLz4NCjxici8+DQpL aW5kIHJlZ2FyZHMsPGJyLz4NCjxici8+IA0KQWRhbSBTb2JpZXNraSAJCSAJICAgCQkgIDwvZGl2 PjwvYm9keT4NCjwvaHRtbD4= --_8da7161c-6e3b-4a63-ab02-09efb42bc10e_-- From abegen@cisco.com Wed Dec 5 18:21:07 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2F021F8D08 for ; Wed, 5 Dec 2012 18:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LDqV7zmx+sa5 for ; Wed, 5 Dec 2012 18:21:07 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id E720C21F8CED for ; Wed, 5 Dec 2012 18:20:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=766; q=dns/txt; s=iport; t=1354760458; x=1355970058; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=MINZmxTJknIyV0nHChFFEp4mMUqNwwJcPt9JdFZSoxA=; b=mFRWG1ar6tFlRxNjhbB7pGteqQW+6Atpzq5CcNcPBlRLTjoudO+IcTHR QzYF6bFNc/TLS026rFC735oIAmH+J4kjBI2g4TqbS4JMXeDaFBQi4R+JA F7aFUHFV/TG/Q/H6rDPTqCYlRx+R1N1/9MHH3leBAfplB6yGZNoNnFRVN U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0FAIr/v1CtJV2d/2dsb2JhbABEhW24QBZzgh4BAQEEAQEBNzQXBgEIEQMBAgsUNwsdCAIEEwiICAyhAqFQBIw3g2BhA6ZKgnKCIQ X-IronPort-AV: E=McAfee;i="5400,1158,6917"; a="149895187" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 06 Dec 2012 02:20:57 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qB62KvDI018118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 6 Dec 2012 02:20:57 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.171]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Wed, 5 Dec 2012 20:20:57 -0600 From: "Ali C. Begen (abegen)" To: "payload@ietf.org" Thread-Topic: [payload] WGLC for VP8 Payload Thread-Index: AQHNxpKRijb9Uyx1rkaO+XOA7twBQpgLNEKA Date: Thu, 6 Dec 2012 02:20:57 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.255.174] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 02:21:07 -0000 I have not seen any comments on the list. Please review the draft and post your comments on the list. Thanks. -acbegen -----Original Message----- From: "Ali C. Begen" Date: Monday, November 19, 2012 3:15 PM To: "payload@ietf.org" Subject: [payload] WGLC for VP8 Payload >Hi everyone, > >We had a WGLC for this draft earlier this year and there have been a few >updates to the document. I am starting a 2nd WGLC. Please review and >comment on the list by December 10th. > >https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_text=3D1 > > >-acbegen > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload From abegen@cisco.com Mon Dec 10 09:36:28 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277E021F8570 for ; Mon, 10 Dec 2012 09:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skxi5233eMpR for ; Mon, 10 Dec 2012 09:36:27 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9A521F856D for ; Mon, 10 Dec 2012 09:36:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=853; q=dns/txt; s=iport; t=1355160987; x=1356370587; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=l/z/wZx6UL2s9nB7GOJVje4bWOTNwBgeyWreQJy8E5s=; b=VPu0Q4K+TmDBj9BhnXRGhrSUfSpj05pyqiNRt0GHGs/7/lRjSJaeoRtq K1cnIwyTHKm4YQ+t/m69z+NvFp/G6KjBPpKvdGYuG698bnlSKwvKwfAmf DXU2hn5K7z/96Fb0d3vKiTfRuqkSmSKVQS0/EjV+h9+JUv2jiYywY9R/V I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFANIcxlCtJV2Z/2dsb2JhbABEgmyDBLkRFnOCHgEBAQQBAQE3NBcGAQgRAwECCxQ3Cx0IAgQTCIgJAQuWOKEIBIw/g2JhA6ZOgnOCIg X-IronPort-AV: E=McAfee;i="5400,1158,6921"; a="148314241" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 10 Dec 2012 17:36:26 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBAHaPMD014620 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 10 Dec 2012 17:36:25 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Mon, 10 Dec 2012 11:36:25 -0600 From: "Ali C. Begen (abegen)" To: "payload@ietf.org" Thread-Topic: [payload] WGLC for VP8 Payload Thread-Index: AQHNxpKRijb9Uyx1rkaO+XOA7twBQpgSfVyA Date: Mon, 10 Dec 2012 17:36:25 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.255.183] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 17:36:28 -0000 I have not seen any comments on the list. There were some issues raised in the previous call. I am assuming all parties are happy with the current version. I will prepare the document write-up. -acbegen -----Original Message----- From: "Ali C. Begen" Date: Monday, November 19, 2012 3:15 PM To: "payload@ietf.org" Subject: [payload] WGLC for VP8 Payload >Hi everyone, > >We had a WGLC for this draft earlier this year and there have been a few >updates to the document. I am starting a 2nd WGLC. Please review and >comment on the list by December 10th. > >https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_text=3D1 > > >-acbegen > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload From tharper@logitech.com Mon Dec 10 12:39:47 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4F721F8654 for ; Mon, 10 Dec 2012 12:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ISIMrU4CjpD for ; Mon, 10 Dec 2012 12:39:47 -0800 (PST) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4FA21F863A for ; Mon, 10 Dec 2012 12:39:46 -0800 (PST) Received: from mail-ie0-f198.google.com ([209.85.223.198]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKUMZIkrrc9+Ti01rgZRLxLGTyN8UEWd4F@postini.com; Mon, 10 Dec 2012 12:39:47 PST Received: by mail-ie0-f198.google.com with SMTP id c10so14526678ieb.1 for ; Mon, 10 Dec 2012 12:39:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=CXKwDiUY3G/yv2exW1kcVA3CkOtHk0VhsV+jyGJ9T4Y=; b=NUQzBI4i6pWxLuBTSIdYj4OwSKhbBH/13zv2PI/c7j8JU7cnRpblCszLNIyzjuxAZM He3dfJjsNWRp1dknclrq4HyUXVSwcNeId7i8JXu54KvLihV/GoSYBvFGGXJh8AZf/SVK NDm9ZDolvofNar5vwVpApGAfWNcfMUihSAEn6Z/+IirAcNfmoUMCBxnQiDU0quqbU+/w pIaXo83+9hfqGUV4G8mfCHYOsxBcJodVZ7J5VCcVZ5e2UchcEYWgyjEMEDezC44TsR78 Ycsx3D+Vu0nUZ215FTiDo12XzFB4+UncdFgaQErZtOh9T5FMi7nGUmarkUacoZgt8bJD 1ZIA== Received: by 10.60.172.113 with SMTP id bb17mr8469724oec.110.1355171985222; Mon, 10 Dec 2012 12:39:45 -0800 (PST) Received: by 10.60.172.113 with SMTP id bb17mr8469719oec.110.1355171985134; Mon, 10 Dec 2012 12:39:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.76.95.197 with HTTP; Mon, 10 Dec 2012 12:39:25 -0800 (PST) In-Reply-To: References: From: Tom Harper Date: Mon, 10 Dec 2012 12:39:25 -0800 Message-ID: To: "Ali C. Begen (abegen)" Content-Type: multipart/alternative; boundary=bcaec54d4028c892c104d0859039 X-Gm-Message-State: ALoCoQn4zvSSOXZWjAphSErFFif43UJ0PDdQsfC3YY3swbeW07QGJDpphclUKIskcV8TgPAmxqS6blz5umDC2AchYhlCRCzO3p0UsTsF8kOYTQS0rdZ6pJz2YgA45xQ7Sq2EfeBOgSj5i4Z4GzS5QwVNhNUPWD7Nvg== Cc: "payload@ietf.org" Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 20:39:47 -0000 --bcaec54d4028c892c104d0859039 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 10, 2012 at 9:36 AM, Ali C. Begen (abegen) wrote: > I have not seen any comments on the list. There were some issues raised in > the previous call. I am assuming all parties are happy with the current > version. > > I will prepare the document write-up. > Hi, I have no further feedback at this time- it seems that all of the concerns from before have been addressed, and we are working with the current draft version. Thanks! Tom --bcaec54d4028c892c104d0859039 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 10, 2012 at 9:36 AM, Al= i C. Begen (abegen) <abegen@cisco.com> wrote:
I have not seen any comments on the list. There were some = issues raised in
the previous call. I am assuming all parties are happy with the current
version.

I will prepare the document write-up.

Hi,

I have no further feedback at this time- it seems = that all of the concerns from before have been addressed, and we are workin= g with the current draft version.

Thanks!

Tom
--bcaec54d4028c892c104d0859039-- From harald@alvestrand.no Tue Dec 11 05:33:08 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9055721F87A2 for ; Tue, 11 Dec 2012 05:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.466 X-Spam-Level: X-Spam-Status: No, score=-110.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmPXvYPn0hQ2 for ; Tue, 11 Dec 2012 05:33:08 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id F1E2821F86B7 for ; Tue, 11 Dec 2012 05:33:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E397339E1AC for ; Tue, 11 Dec 2012 14:33:04 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2llG3PYFEAaf for ; Tue, 11 Dec 2012 14:33:04 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id CF01739E179 for ; Tue, 11 Dec 2012 14:33:03 +0100 (CET) Message-ID: <50C7360E.2060604@alvestrand.no> Date: Tue, 11 Dec 2012 14:33:02 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: payload@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 13:33:08 -0000 On 12/10/2012 06:36 PM, Ali C. Begen (abegen) wrote: > I have not seen any comments on the list. There were some issues raised in > the previous call. I am assuming all parties are happy with the current > version. > > I will prepare the document write-up. Thank you. I'm looking forward to closing off this item. > > -acbegen > > -----Original Message----- > From: "Ali C. Begen" > Date: Monday, November 19, 2012 3:15 PM > To: "payload@ietf.org" > Subject: [payload] WGLC for VP8 Payload > >> Hi everyone, >> >> We had a WGLC for this draft earlier this year and there have been a few >> updates to the document. I am starting a 2nd WGLC. Please review and >> comment on the list by December 10th. >> >> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_text=1 >> >> >> -acbegen >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From jonathan@vidyo.com Tue Dec 11 08:49:09 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71FE21F84DB for ; Tue, 11 Dec 2012 08:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_26=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62Xeasu361MJ for ; Tue, 11 Dec 2012 08:49:09 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id C179721F8896 for ; Tue, 11 Dec 2012 08:49:08 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 31B118C086C for ; Tue, 11 Dec 2012 11:49:08 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB024.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id D27558C08F6 for ; Tue, 11 Dec 2012 11:49:07 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Tue, 11 Dec 2012 11:48:46 -0500 From: Jonathan Lennox To: "payload@ietf.org" Date: Tue, 11 Dec 2012 11:49:05 -0500 Thread-Topic: [payload] WGLC for VP8 Payload Thread-Index: Ac3Xv2+HBA+98tshSFm0IcC5LoseQw== Message-ID: <1F6FCD47-5EA4-40EC-9682-E290C6F1A25B@vidyo.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 16:49:09 -0000 Hi -- I have two comments on this draft. Sorry for being late. First of all, an editorial matter: Section 6 says the format has no paramet= ers, but section 6.1 lists two optional parameters (max-fr and max-fs). Secondly, more substantively, I note that the payload format's rules on KEY= IDX and TL0PICIDX impose a fair bit of overhead on boxes that wish to splic= e together VP8 streams, since both values are required to always increment = consecutively in a bitstream (if they're being used). By contrast, the equivalent fields of the H.264 SVC payload format (in the = PACSI) just say that IDRPICID must be different in consecutive IDR frames, = without requiring that the value increment by 1; and TL0PICIDX resets to 0 = on every IDR frame, rather than carrying on continuously. (H.264's IDR fra= mes are analogous for these purposes to VP8's essential keyframes). This means that an H.264 SVC splicer -- as long as it doesn't get unlucky, = such that the two streams it's splicing happen to have identical IDRPICID v= alues at the splice point -- can just transition from one bitstream to anot= her at any IDR frame. By contrast, following a splice, a VP8 splicer must re-write both these fie= lds for the rest of the lifetime of the stream, since they each have only o= ne valid possible value following the splice. The VP8 payload format's decision is a reasonable design choice -- as compa= red to the H.264 SVC rules, it removes some ambiguity between splice points= and packet loss, giving decoders somewhat greater visibility as to what's = going on in the bitstream, and also allows TL0PICIDX and KEYIDX to be ortho= gonal options because they increment independently. However, I wanted to m= ake sure this had been considered explicitly by the working group, and we h= ad consensus that it was the right decision. (Note well disclaimer: Vidyo has an IPR declaration against the VP8 payload= -- see .) On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote: > I have not seen any comments on the list. Please review the draft and pos= t > your comments on the list. >=20 > Thanks. > -acbegen >=20 > -----Original Message----- > From: "Ali C. Begen" > Date: Monday, November 19, 2012 3:15 PM > To: "payload@ietf.org" > Subject: [payload] WGLC for VP8 Payload >=20 >> Hi everyone, >>=20 >> We had a WGLC for this draft earlier this year and there have been a few >> updates to the document. I am starting a 2nd WGLC. Please review and >> comment on the list by December 10th. >>=20 >> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_text=3D= 1 >>=20 > https://www.ietf.org/mailman/listinfo/payload >=20 -- Jonathan Lennox jonathan@vidyo.com From abegen@cisco.com Tue Dec 11 16:13:22 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CA621F8889 for ; Tue, 11 Dec 2012 16:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuDWz9V31EwH for ; Tue, 11 Dec 2012 16:13:21 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 57C3E21F8888 for ; Tue, 11 Dec 2012 16:13:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3588; q=dns/txt; s=iport; t=1355271201; x=1356480801; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=XnZ/g8movsGJaiJ+g50b72qlX/lM45mKZZNCViOvJoY=; b=Fno04FKP1XAkn0PSoAeGfxqoxj+IIwE2hj8lFf6s9gQKknVQcFZYLhmn c7LImvAsGTbSd8DY2Sn/Ojl7MWgaqxlJ4gLZBG44e6+kA3+NxZS7Htb7Z Aa4XUEe2KvUzHS2Lo5b5FfB0adqgHWKV3ypPPuiWFxAkzIN0s+vDXKQYk k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAJLLx1CtJXG+/2dsb2JhbABFvlsWc4IeAQEBBAEBATc0CwwGAQgRAwECAQoUNwsdCAIEAQ0FCIgJDK04jiuMSoNiYQOXI48sgmYNgiI X-IronPort-AV: E=Sophos;i="4.84,262,1355097600"; d="scan'208";a="148906399" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 12 Dec 2012 00:13:20 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBC0DKEI006266 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Dec 2012 00:13:20 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.177]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Tue, 11 Dec 2012 18:13:20 -0600 From: "Ali C. Begen (abegen)" To: Jonathan Lennox , "payload@ietf.org" Thread-Topic: [payload] WGLC for VP8 Payload Thread-Index: AQHNxpKRijb9Uyx1rkaO+XOA7twBQpgLNEKAgAkiCoCAAChLAA== Date: Wed, 12 Dec 2012 00:13:19 +0000 Message-ID: In-Reply-To: <1F6FCD47-5EA4-40EC-9682-E290C6F1A25B@vidyo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.244.189] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-payload-vp8@tools.ietf.org" Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 00:13:22 -0000 The first one should be fixed by the authors thru a quick revision. As for the second one, I will ask the authors reply. Also if there are others who strongly think one way or another, lets discuss it. Jonathan, are you ok if the authors simply acknowledge this in the draft (assuming they agree with you) or do you actually not like this at all? -acbegen -----Original Message----- From: Jonathan Lennox Date: Tuesday, December 11, 2012 11:49 AM To: "payload@ietf.org" Subject: Re: [payload] WGLC for VP8 Payload >Hi -- I have two comments on this draft. Sorry for being late. > >First of all, an editorial matter: Section 6 says the format has no >parameters, but section 6.1 lists two optional parameters (max-fr and >max-fs). > > >Secondly, more substantively, I note that the payload format's rules on >KEYIDX and TL0PICIDX impose a fair bit of overhead on boxes that wish to >splice together VP8 streams, since both values are required to always >increment consecutively in a bitstream (if they're being used). > >By contrast, the equivalent fields of the H.264 SVC payload format (in >the PACSI) just say that IDRPICID must be different in consecutive IDR >frames, without requiring that the value increment by 1; and TL0PICIDX >resets to 0 on every IDR frame, rather than carrying on continuously. >(H.264's IDR frames are analogous for these purposes to VP8's essential >keyframes). > >This means that an H.264 SVC splicer -- as long as it doesn't get >unlucky, such that the two streams it's splicing happen to have identical >IDRPICID values at the splice point -- can just transition from one >bitstream to another at any IDR frame. > >By contrast, following a splice, a VP8 splicer must re-write both these >fields for the rest of the lifetime of the stream, since they each have >only one valid possible value following the splice. > >The VP8 payload format's decision is a reasonable design choice -- as >compared to the H.264 SVC rules, it removes some ambiguity between splice >points and packet loss, giving decoders somewhat greater visibility as to >what's going on in the bitstream, and also allows TL0PICIDX and KEYIDX to >be orthogonal options because they increment independently. However, I >wanted to make sure this had been considered explicitly by the working >group, and we had consensus that it was the right decision. > >(Note well disclaimer: Vidyo has an IPR declaration against the VP8 >payload -- see .) > > >On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote: > >> I have not seen any comments on the list. Please review the draft and >>post >> your comments on the list. >>=20 >> Thanks. >> -acbegen >>=20 >> -----Original Message----- >> From: "Ali C. Begen" >> Date: Monday, November 19, 2012 3:15 PM >> To: "payload@ietf.org" >> Subject: [payload] WGLC for VP8 Payload >>=20 >>> Hi everyone, >>>=20 >>> We had a WGLC for this draft earlier this year and there have been a >>>few >>> updates to the document. I am starting a 2nd WGLC. Please review and >>> comment on the list by December 10th. >>>=20 >>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_text= =3D1 >>>=20 >> https://www.ietf.org/mailman/listinfo/payload >>=20 > >-- >Jonathan Lennox >jonathan@vidyo.com > > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload From ron.even.tlv@gmail.com Wed Dec 12 22:37:49 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5E021F85E6 for ; Wed, 12 Dec 2012 22:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fs5GeeFHZP3e for ; Wed, 12 Dec 2012 22:37:48 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3485921F8AE0 for ; Wed, 12 Dec 2012 22:37:48 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1022279eek.31 for ; Wed, 12 Dec 2012 22:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=ElK+TjA3eD11xTRRzyAiVXGLeq71E2NSoCcGJ3NIYmM=; b=s/tdqgKqVGxS8yQ/qJ9UYk4e1yt8R27WEnw4IF+LqoV2pkqWGd29AHkdMiKBtw+juS wBzRdPZ2vLTIfLkM6uTi0HkkVlK2vqxUW77aQ8YF8AYiZ8y1yZKVjbb9ZWmwztwtZNL/ L24zUZ+GQeD9WDwLxIcg+bsKyv5My8UJJgDffUggogR9xwMelb0sRA8rw24OaK08K4Zh /EiS6DKiG5WNHXorO+7c6Bt/IaQj812aYwCL6CSorlPWzNkLDXNFxk701DogLjSxs9GP 8u1/xSbfeZK0wnQE4SWXC35rxmIw5g7xzTbuOD+NS7yxVJo/ZSA+nXyd9qc2GquSD25M 53Ug== Received: by 10.14.194.199 with SMTP id m47mr2460547een.11.1355380667052; Wed, 12 Dec 2012 22:37:47 -0800 (PST) Received: from RoniE (bzq-79-176-185-176.red.bezeqint.net. [79.176.185.176]) by mx.google.com with ESMTPS id l3sm1080903eem.14.2012.12.12.22.37.44 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Dec 2012 22:37:46 -0800 (PST) From: "Roni Even" To: Date: Thu, 13 Dec 2012 08:34:58 +0200 Message-ID: <005201cdd8fb$fb139d50$f13ad7f0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0053_01CDD90C.BE9D0990" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3Y++h0UQghJ/PcRKOitadPT1ArYw== Content-Language: en-us Cc: draft-ietf-avt-rtp-isac@tools.ietf.org Subject: [payload] WGLC on draft-ietf-avt-rtp-isac-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 06:37:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0053_01CDD90C.BE9D0990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avt-rtp-isac-02 , RTP Payload Format for the iSAC Codec The WGLC will end on January 2nd, 2013 Please review the draft and send comments to the list. For the draft authors; Are you aware of any IPR that applies to draft-ietf-avt-rtp-isac-02? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? The above question is needed for the document write-up when sent to publication. Thanks Roni Even Payload co-chair ------=_NextPart_000_0053_01CDD90C.BE9D0990 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I would =
like to start a WGLC on  http://too=
ls.ietf.org/html/draft-ietf-avt-rtp-isac-02 , RTP =
Payload Format for the iSAC Codec
 =

 =

The WGLC will = end on January 2nd, 2013

 

Please = review the draft and send comments to the list.

 

For the = draft authors;  Are you aware of any IPR that applies to = draft-ietf-= avt-rtp-isac-02? If = so,= 

has this =
IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, =
4879, 3669 and 5378 for more details)?
The above =
question is needed for the document write-up when sent to =
publication.
 =

Thanks

 

Roni = Even

Payload =  co-chair

 

 

 

------=_NextPart_000_0053_01CDD90C.BE9D0990-- From ron.even.tlv@gmail.com Wed Dec 12 22:48:47 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C3B21F8A9A for ; Wed, 12 Dec 2012 22:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPBA8mvc4u1B for ; Wed, 12 Dec 2012 22:48:47 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9685021F8A77 for ; Wed, 12 Dec 2012 22:48:46 -0800 (PST) Received: by mail-ee0-f44.google.com with SMTP id b47so1026587eek.31 for ; Wed, 12 Dec 2012 22:48:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=ExPNAHEX2p7TriHovksjgCejADadICksLAsLhsV6mZs=; b=wDUSyyGG+luYrjjBIhitlHlLRCkLI/UD9VrZoB7IHV/I9wCc4Z2BoOrOFcXTGNSL4Z YqE+y+T9k6webjIjjESLxeFnsbci+awaam/yy69T0QF5ZpeTcedKzTW1uoYXwYCYQkzR vjI8IQ5fS885PFansqlWdPQIA9PU9u+1AicCWmXsg0hKHokICT/hyN07yMpKDK4yqBWp eAlGpNS6AGtZp0Vv/egRdZp+cg2JkZEtivX873ozTZS4IMc9JiZYeWmaU50AASC7qCdh RxMXJOnHIO6QQmKpKrmnCNPOqa0YIDenci67FGe3o04girwsygxSn1cl42rZZoAHP75n 8OKQ== Received: by 10.14.178.196 with SMTP id f44mr2469140eem.14.1355381325806; Wed, 12 Dec 2012 22:48:45 -0800 (PST) Received: from RoniE (bzq-79-176-185-176.red.bezeqint.net. [79.176.185.176]) by mx.google.com with ESMTPS id 6sm1161378eea.3.2012.12.12.22.48.43 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 12 Dec 2012 22:48:44 -0800 (PST) From: "Roni Even" To: Date: Thu, 13 Dec 2012 08:45:57 +0200 Message-ID: <005701cdd8fd$83ade6b0$8b09b410$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0058_01CDD90E.4737C820" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3Y/VDIdS/QicjiQxCmDifr23qBVw== Content-Language: en-us Cc: draft-ietf-avt-rtp-isac@tools.ietf.org, payload@ietf.org Subject: [payload] registration of iSac media subtype X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 06:48:47 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0058_01CDD90E.4737C820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The iSac draft is currently in WGLC in the Payload WG http://tools.ietf.org/html/draft-ietf-avt-rtp-isac-02 the media type registration is in section 4 and also included below. Please review the registration. Thanks Roni Even Payload WG co-chair Media type name: audio Media subtype: isac Required parameters: None Optional parameters: * ibitrate: The parameter indicates the upper bound of the initial target bit rate the device would like to receive. For channel-adaptive mode, the target bit rate may vary with time; for channel-independent mode, the target bit rate will remain at that level unless instructed otherwise. An acceptable value for ibitrate is in the range of 20000 to 32000 (bits per second). * maxbitrate: The parameter indicates the maximum bit rate the endpoint expects to receive. The recipient of this parameter SHOULD NOT transmit at a higher bit rate. Encoding considerations: This media format is framed and binary. Security considerations: See Section 6 Interoperability considerations: None Published specification: RFC XXXX Applications which use this media type: This media type is suitable for use in numerous applications needing to transport encoded voice or other audio. Some examples include Voice over IP, Streaming Media, Voice Messaging, and Conferencing. Additional information: None Intended usage: COMMON Other Information/General Comment: iSAC is a proprietary speech and audio codec owned by Google. The codec operates on 30 or 60 ms speech frames at a sampling rate clock of 16 kHz or 32 kHz. Person to contact for further information: Tina le Grand [tlegrand@google.com] Restrictions on usage: This media type depends on RTP framing, and hence is only defined for transfer via RTP [2]. Transport within other framing protocols is not defined at this time. Change controller: IETF Audio/Video Transport working group delegated from the IESG. Note to the RFC Editor / IANA: Please replace "RFC XXXX" above with the number of this RFC when published, and remove this note. ------=_NextPart_000_0058_01CDD90E.4737C820 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

The iSac draft = is currently in WGLC in the Payload WG http://too= ls.ietf.org/html/draft-ietf-avt-rtp-isac-02

the media type registration is in section 4 and also = included below.

Please review the = registration.

 

Thanks

Roni Even =

Payload WG co-chair

 

   =

Media type name:   = audio

 

   Media subtype:   = isac

 

   Required parameters:  = None

 

   Optional parameters:

 

      *  ibitrate: The = parameter indicates the upper bound of the

         = initial target bit rate the device would like to receive.  = For

         = channel-adaptive mode, the target bit rate may vary with = time;

         for = channel-independent mode, the target bit rate will = remain

         at = that level unless instructed otherwise.  An acceptable = value

         for = ibitrate is in the range of 20000 to 32000 (bits per

         = second).

 

      *  maxbitrate: The = parameter indicates the maximum bit rate the

         = endpoint expects to receive.  The recipient of this = parameter

         = SHOULD NOT transmit at a higher bit rate.

 

   = Encoding considerations:

      This media format is = framed and binary.

 

   = Security considerations:  See Section 6

 

  =  Interoperability considerations:  None

 

   = Published specification:  RFC XXXX

 

   = Applications which use this media type:

      This media type is = suitable for use in numerous applications

      needing to transport = encoded voice or other audio.  Some examples

      include Voice over IP, = Streaming Media, Voice Messaging, and

      = Conferencing.

 

   Additional information:  = None

 

   Intended usage:  = COMMON

 

   Other Information/General = Comment:

      iSAC is a proprietary = speech and audio codec owned by Google.  The

      codec operates on 30 or = 60 ms speech frames at a sampling rate

      clock of 16 kHz or 32 = kHz.

 

   Person to contact for further = information:

      Tina le Grand = [tlegrand@google.com]

 

   = Restrictions on usage:

      This media type depends = on RTP framing, and hence is only defined

      for transfer via RTP = [2].  Transport within other framing

      protocols is not = defined at this time.

 

   = Change controller:

      IETF Audio/Video = Transport working group delegated from the IESG.

 

   = Note to the RFC Editor / IANA: Please replace "RFC XXXX" above = with

   the number of this = RFC when published, and remove this = note.

------=_NextPart_000_0058_01CDD90E.4737C820-- From ietf-ipr@ietf.org Wed Dec 12 09:36:27 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D893F21E804D; Wed, 12 Dec 2012 09:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.418 X-Spam-Level: X-Spam-Status: No, score=-102.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHhbfMRA0FfE; Wed, 12 Dec 2012 09:36:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC2221F89C2; Wed, 12 Dec 2012 09:36:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: ts@thomas-schierl.de, alex@vidyo.com, stewe@stewe.org, yekui.wang@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121212173625.26154.51164.idtracker@ietfa.amsl.com> Date: Wed, 12 Dec 2012 09:36:25 -0800 X-Mailman-Approved-At: Thu, 13 Dec 2012 02:34:34 -0800 Cc: payload@ietf.org, ipr-announce@ietf.org Subject: [payload] IPR Disclosure: Microsoft Corporation's Statement about IPR related to RFC 6190 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 17:36:28 -0000 Dear Thomas Schierl, Alex Eleftheriadis, Stephan Wenger, Ye-Kui Wang: An IPR disclosure that pertains to your RFC entitled "RTP Payload Format f= or Scalable Video Coding" (RFC6190) was submitted to the IETF Secretariat on 2012-12-10 and has been posted on the "IETF Page of Intellectual Property R= ights Disclosures" (https://datatracker.ietf.org/ipr/1937/). The title of the IPR disclosure is "Microsoft Corporation's Statement about IPR related to RFC 6190.""); The IETF Secretariat From jonathan@vidyo.com Thu Dec 13 08:29:22 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBCF21F89A3 for ; Thu, 13 Dec 2012 08:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, J_CHICKENPOX_26=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNHihPPHjkLX for ; Thu, 13 Dec 2012 08:29:21 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5976321F85D2 for ; Thu, 13 Dec 2012 08:29:21 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id DC96D416A35; Thu, 13 Dec 2012 05:27:25 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 1E90341691C; Thu, 13 Dec 2012 05:27:15 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Thu, 13 Dec 2012 11:29:00 -0500 From: Jonathan Lennox To: "Ali C. Begen (abegen)" , "payload@ietf.org" Date: Thu, 13 Dec 2012 11:29:07 -0500 Thread-Topic: [payload] WGLC for VP8 Payload Thread-Index: AQHNxpKRijb9Uyx1rkaO+XOA7twBQpgLNEKAgAkiCoCAAChLAIACfvJg Message-ID: References: <1F6FCD47-5EA4-40EC-9682-E290C6F1A25B@vidyo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-payload-vp8@tools.ietf.org" Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:29:22 -0000 Hi, Ali -- I just wanted to make sure the issue had been considered; if the WG agrees = that the current design is okay given the limitations I've mentioned, I'm n= ot going to object. Discussion of the issue might be helpful in the document. -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 Sent: Tuesday, December 11, 2012 7:13 PM To: Jonathan Lennox; payload@ietf.org Cc: draft-ietf-payload-vp8@tools.ietf.org Subject: Re: [payload] WGLC for VP8 Payload The first one should be fixed by the authors thru a quick revision. As for = the second one, I will ask the authors reply. Also if there are others who = strongly think one way or another, lets discuss it. Jonathan, are you ok if the authors simply acknowledge this in the draft (a= ssuming they agree with you) or do you actually not like this at all? -acbegen -----Original Message----- From: Jonathan Lennox Date: Tuesday, December 11, 2012 11:49 AM To: "payload@ietf.org" Subject: Re: [payload] WGLC for VP8 Payload >Hi -- I have two comments on this draft. Sorry for being late. > >First of all, an editorial matter: Section 6 says the format has no=20 >parameters, but section 6.1 lists two optional parameters (max-fr and=20 >max-fs). > > >Secondly, more substantively, I note that the payload format's rules on=20 >KEYIDX and TL0PICIDX impose a fair bit of overhead on boxes that wish=20 >to splice together VP8 streams, since both values are required to=20 >always increment consecutively in a bitstream (if they're being used). > >By contrast, the equivalent fields of the H.264 SVC payload format (in=20 >the PACSI) just say that IDRPICID must be different in consecutive IDR=20 >frames, without requiring that the value increment by 1; and TL0PICIDX=20 >resets to 0 on every IDR frame, rather than carrying on continuously. >(H.264's IDR frames are analogous for these purposes to VP8's essential=20 >keyframes). > >This means that an H.264 SVC splicer -- as long as it doesn't get=20 >unlucky, such that the two streams it's splicing happen to have=20 >identical IDRPICID values at the splice point -- can just transition=20 >from one bitstream to another at any IDR frame. > >By contrast, following a splice, a VP8 splicer must re-write both these=20 >fields for the rest of the lifetime of the stream, since they each have=20 >only one valid possible value following the splice. > >The VP8 payload format's decision is a reasonable design choice -- as=20 >compared to the H.264 SVC rules, it removes some ambiguity between=20 >splice points and packet loss, giving decoders somewhat greater=20 >visibility as to what's going on in the bitstream, and also allows=20 >TL0PICIDX and KEYIDX to be orthogonal options because they increment=20 >independently. However, I wanted to make sure this had been considered=20 >explicitly by the working group, and we had consensus that it was the righ= t decision. > >(Note well disclaimer: Vidyo has an IPR declaration against the VP8=20 >payload -- see .) > > >On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote: > >> I have not seen any comments on the list. Please review the draft and=20 >>post your comments on the list. >>=20 >> Thanks. >> -acbegen >>=20 >> -----Original Message----- >> From: "Ali C. Begen" >> Date: Monday, November 19, 2012 3:15 PM >> To: "payload@ietf.org" >> Subject: [payload] WGLC for VP8 Payload >>=20 >>> Hi everyone, >>>=20 >>> We had a WGLC for this draft earlier this year and there have been a=20 >>>few updates to the document. I am starting a 2nd WGLC. Please review=20 >>>and comment on the list by December 10th. >>>=20 >>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_tex >>> t=3D1 >>>=20 >> https://www.ietf.org/mailman/listinfo/payload >>=20 > >-- >Jonathan Lennox >jonathan@vidyo.com > > >_______________________________________________ >payload mailing list >payload@ietf.org >https://www.ietf.org/mailman/listinfo/payload From internet-drafts@ietf.org Thu Dec 13 08:52:52 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3CF21F889E; Thu, 13 Dec 2012 08:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4K8omzPBmSdl; Thu, 13 Dec 2012 08:52:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA72521F8568; Thu, 13 Dec 2012 08:52:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121213165251.5705.64683.idtracker@ietfa.amsl.com> Date: Thu, 13 Dec 2012 08:52:51 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-vp8-07.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:52:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : RTP Payload Format for VP8 Video Author(s) : Patrik Westin Henrik F Lundin Michael Glover Justin Uberti Frank Galligan Filename : draft-ietf-payload-vp8-07.txt Pages : 29 Date : 2012-12-13 Abstract: This memo describes an RTP payload format for the VP8 video codec. The payload format has wide applicability, as it supports applications from low bit-rate peer-to-peer usage, to high bit-rate video conferences. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-vp8 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-vp8-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-vp8-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From abegen@cisco.com Thu Dec 13 08:55:44 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFBE21F897E for ; Thu, 13 Dec 2012 08:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.149 X-Spam-Level: X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8v2+Xd51cvES for ; Thu, 13 Dec 2012 08:55:43 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 045F321F8854 for ; Thu, 13 Dec 2012 08:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4770; q=dns/txt; s=iport; t=1355417743; x=1356627343; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=U9+9f4XY/+QdfAbPsbGx79cv3EvkGf/dthMDmZDlK2Q=; b=lLQQ6zXk1QgQS3ABFN9NSO+6ph8ulzn8vvCVtj4nj3GqalmEEb7xPDoP P6gaiCh968YQ9igQ83nckf59uhnds/fdLnAJV1LG5zEu4OuLUGG0S/6Q+ AdjU3hHtpDs1h8aA/kxM6T4mTC7d6deu6HVbvEMERyAnnrR+tZicPMP58 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMcHylCtJV2b/2dsb2JhbABFvm8Wc4IeAQEBBAEBATc0CwwGAQgRAwEBAQEKFAkuCxQJCAIEAQ0FCIgLDL0JjFeDYmEDlyWPLIJzgiI X-IronPort-AV: E=Sophos;i="4.84,275,1355097600"; d="scan'208";a="152672339" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 13 Dec 2012 16:55:42 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBDGtgUq016340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Dec 2012 16:55:42 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.177]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Thu, 13 Dec 2012 10:55:42 -0600 From: "Ali C. Begen (abegen)" To: Jonathan Lennox , "payload@ietf.org" Thread-Topic: [payload] WGLC for VP8 Payload Thread-Index: AQHNxpKRijb9Uyx1rkaO+XOA7twBQpgLNEKAgAkiCoCAAChLAIACfvJggAArcIA= Date: Thu, 13 Dec 2012 16:55:41 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.255.25] Content-Type: text/plain; charset="us-ascii" Content-ID: <6AF7543091BEBD46A8260E83BFFCB2A1@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-payload-vp8@tools.ietf.org" Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:55:44 -0000 Thanks, the authors just rev'ed the draft to fix the first issue. I hope they will address the second issue first in the list and then reflect the agreement in the next revision. I will hold on to the doc write-up till then. -acbegen -----Original Message----- From: Jonathan Lennox Date: Thursday, December 13, 2012 11:29 AM To: "Ali C. Begen" , "payload@ietf.org" Cc: "draft-ietf-payload-vp8@tools.ietf.org" Subject: RE: [payload] WGLC for VP8 Payload >Hi, Ali -- > >I just wanted to make sure the issue had been considered; if the WG >agrees that the current design is okay given the limitations I've >mentioned, I'm not going to object. > >Discussion of the issue might be helpful in the document. > >-----Original Message----- >From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >Sent: Tuesday, December 11, 2012 7:13 PM >To: Jonathan Lennox; payload@ietf.org >Cc: draft-ietf-payload-vp8@tools.ietf.org >Subject: Re: [payload] WGLC for VP8 Payload > >The first one should be fixed by the authors thru a quick revision. As >for the second one, I will ask the authors reply. Also if there are >others who strongly think one way or another, lets discuss it. > >Jonathan, are you ok if the authors simply acknowledge this in the draft >(assuming they agree with you) or do you actually not like this at all? > >-acbegen > >-----Original Message----- >From: Jonathan Lennox >Date: Tuesday, December 11, 2012 11:49 AM >To: "payload@ietf.org" >Subject: Re: [payload] WGLC for VP8 Payload > >>Hi -- I have two comments on this draft. Sorry for being late. >> >>First of all, an editorial matter: Section 6 says the format has no >>parameters, but section 6.1 lists two optional parameters (max-fr and >>max-fs). >> >> >>Secondly, more substantively, I note that the payload format's rules on >>KEYIDX and TL0PICIDX impose a fair bit of overhead on boxes that wish >>to splice together VP8 streams, since both values are required to >>always increment consecutively in a bitstream (if they're being used). >> >>By contrast, the equivalent fields of the H.264 SVC payload format (in >>the PACSI) just say that IDRPICID must be different in consecutive IDR >>frames, without requiring that the value increment by 1; and TL0PICIDX >>resets to 0 on every IDR frame, rather than carrying on continuously. >>(H.264's IDR frames are analogous for these purposes to VP8's essential >>keyframes). >> >>This means that an H.264 SVC splicer -- as long as it doesn't get >>unlucky, such that the two streams it's splicing happen to have >>identical IDRPICID values at the splice point -- can just transition >>from one bitstream to another at any IDR frame. >> >>By contrast, following a splice, a VP8 splicer must re-write both these >>fields for the rest of the lifetime of the stream, since they each have >>only one valid possible value following the splice. >> >>The VP8 payload format's decision is a reasonable design choice -- as >>compared to the H.264 SVC rules, it removes some ambiguity between >>splice points and packet loss, giving decoders somewhat greater >>visibility as to what's going on in the bitstream, and also allows >>TL0PICIDX and KEYIDX to be orthogonal options because they increment >>independently. However, I wanted to make sure this had been considered >>explicitly by the working group, and we had consensus that it was the >>right decision. >> >>(Note well disclaimer: Vidyo has an IPR declaration against the VP8 >>payload -- see .) >> >> >>On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote: >> >>> I have not seen any comments on the list. Please review the draft and >>>post your comments on the list. >>>=20 >>> Thanks. >>> -acbegen >>>=20 >>> -----Original Message----- >>> From: "Ali C. Begen" >>> Date: Monday, November 19, 2012 3:15 PM >>> To: "payload@ietf.org" >>> Subject: [payload] WGLC for VP8 Payload >>>=20 >>>> Hi everyone, >>>>=20 >>>> We had a WGLC for this draft earlier this year and there have been a >>>>few updates to the document. I am starting a 2nd WGLC. Please review >>>>and comment on the list by December 10th. >>>>=20 >>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_tex >>>> t=3D1 >>>>=20 >>> https://www.ietf.org/mailman/listinfo/payload >>>=20 >> >>-- >>Jonathan Lennox >>jonathan@vidyo.com >> >> >>_______________________________________________ >>payload mailing list >>payload@ietf.org >>https://www.ietf.org/mailman/listinfo/payload > From internet-drafts@ietf.org Thu Dec 13 11:43:53 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF1A21F8A32; Thu, 13 Dec 2012 11:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqNbXz24b+mn; Thu, 13 Dec 2012 11:43:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32C0021F8A0F; Thu, 13 Dec 2012 11:43:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121213194353.29464.60888.idtracker@ietfa.amsl.com> Date: Thu, 13 Dec 2012 11:43:53 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-avt-rtp-evrc-nw-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 19:43:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : RTP payload format for Enhanced Variable Rate Narrowband= -Wideband Codec (EVRC-NW) Author(s) : Zheng Fang Filename : draft-ietf-avt-rtp-evrc-nw-09.txt Pages : 32 Date : 2012-12-13 Abstract: This document specifies real-time transport protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as e-mail. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-evrc-nw There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avt-rtp-evrc-nw-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avt-rtp-evrc-nw-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zfang@qualcomm.com Thu Dec 13 11:53:23 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62F521F8428 for ; Thu, 13 Dec 2012 11:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVyXk-9lzl5l for ; Thu, 13 Dec 2012 11:53:23 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 360F221F841E for ; Thu, 13 Dec 2012 11:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1355426774; x=1386962774; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-transfer-encoding: mime-version:x-ironport-av; bh=EboeB0UDFs6bwX+CuwcYCjCgktGge3GA08aZdJTc5Wo=; b=OalQEiarrjOhU9hxJnQ2Q+AHNxN2JXiApTY/01LW/sawJw2Iv2WkvSAL lKDDhgN1DkSKidLCLmyfQVfDUhy1FqYWTv9QE9CvPDC5P2i9AueZDg3a2 oxqsXQrKFfIlTYhALppG0okT/r1rwv5soUD4rh/6u0XMGhPpGqR9+OWz0 g=; X-IronPort-AV: E=Sophos;i="4.84,275,1355126400"; d="scan'208";a="11854431" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 13 Dec 2012 11:26:13 -0800 Received: from nasanexhc03.na.qualcomm.com ([172.30.48.26]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Dec 2012 11:53:21 -0800 Received: from NASANEXD01A.na.qualcomm.com ([169.254.1.194]) by NASANEXHC03.na.qualcomm.com ([172.30.48.26]) with mapi id 14.02.0318.004; Thu, 13 Dec 2012 11:53:21 -0800 From: "Fang, Zheng" To: "payload@ietf.org" Thread-Topic: [payload] I-D Action: draft-ietf-avt-rtp-evrc-nw-09.txt Thread-Index: AQHN2Wo0aLiX2EaGSEGHtW3iGkkbKJgXIcdw Date: Thu, 13 Dec 2012 19:53:20 +0000 Message-ID: References: <20121213194353.29464.60888.idtracker@ietfa.amsl.com> In-Reply-To: <20121213194353.29464.60888.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Peter Yee \(peter@akayla.com\)" , "Sinder, Dan" Subject: [payload] FW: I-D Action: draft-ietf-avt-rtp-evrc-nw-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 19:53:24 -0000 FYI. I uploaded version-09 of draft-ietf-avt-rtp-evrc-nw. Modifications are= based on Gen-ART review feedback. Diff can be found at http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-avt-rtp-evrc-nw-09.txt Thanks to Peter for the comments.=20 -Zheng -----Original Message----- From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of internet-drafts@ietf.org Sent: Thursday, December 13, 2012 11:44 AM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-avt-rtp-evrc-nw-09.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 Enhanced Variable Rate Narrowband= -Wideband Codec (EVRC-NW) Author(s) : Zheng Fang Filename : draft-ietf-avt-rtp-evrc-nw-09.txt Pages : 32 Date : 2012-12-13 Abstract: This document specifies real-time transport protocol (RTP) payload formats to be used for the Enhanced Variable Rate Narrowband-Wideband Codec (EVRC-NW). Three media type registrations are included for EVRC-NW RTP payload formats. In addition, a file format is specified for transport of EVRC-NW speech data in storage mode applications such as e-mail. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avt-rtp-evrc-nw There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avt-rtp-evrc-nw-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avt-rtp-evrc-nw-09 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 harald@alvestrand.no Fri Dec 14 03:29:04 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51C921F857B for ; Fri, 14 Dec 2012 03:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.485 X-Spam-Level: X-Spam-Status: No, score=-110.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eogRcjvwwc9v for ; Fri, 14 Dec 2012 03:29:04 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 068BB21F8568 for ; Fri, 14 Dec 2012 03:29:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D945C39E1AC for ; Fri, 14 Dec 2012 12:29:02 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNiHSsdonKKR for ; Fri, 14 Dec 2012 12:29:01 +0100 (CET) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id F101939E13B for ; Fri, 14 Dec 2012 12:29:00 +0100 (CET) Message-ID: <50CB0D7B.4030000@alvestrand.no> Date: Fri, 14 Dec 2012 12:28:59 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: payload@ietf.org References: <20121212173625.26154.51164.idtracker@ietfa.amsl.com> In-Reply-To: <20121212173625.26154.51164.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [payload] IPR Disclosure: Microsoft Corporation's Statement about IPR related to RFC 6190 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 11:29:04 -0000 On 12/12/2012 06:36 PM, IETF Secretariat wrote: > Dear Thomas Schierl, Alex Eleftheriadis, Stephan Wenger, Ye-Kui Wang: > > An IPR disclosure that pertains to your RFC entitled "RTP Payload Format for > Scalable Video Coding" (RFC6190) was submitted to the IETF Secretariat on > 2012-12-10 and has been posted on the "IETF Page of Intellectual Property Rights > Disclosures" (https://datatracker.ietf.org/ipr/1937/). The title of the IPR > disclosure is "Microsoft Corporation's Statement about IPR related to RFC > 6190.""); > > The IETF Secretariat This is an interesting IPR disclosure. The disclosure relates to "NA" patents and "None" unpublished pending patent applications. As far as I can tell, it's an IPR disclosure that does not disclose any IPR - not even if any IPR exists. Is there a way to mark such disclosures as either "useless" or "not in conformance with IETF IPR rules"? From patrik.westin@gmail.com Thu Dec 13 08:57:44 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57ABA21F8A0C for ; Thu, 13 Dec 2012 08:57:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.997 X-Spam-Level: X-Spam-Status: No, score=-2.997 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD4O1zjJL3fc for ; Thu, 13 Dec 2012 08:57:43 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7827521F89E9 for ; Thu, 13 Dec 2012 08:57:41 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so1960743lbk.31 for ; Thu, 13 Dec 2012 08:57:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2zfFOxo2HYyXfWWrmjjqLy0Q9RIys1pYhNwVJfBHPiw=; b=VMyKs5y7JcOiu7csOh9TAHB1BmcIM3hGrpOTUcJrBU59kKEyHz9nyiH53LaHKr4IV5 PDVzKjhGgLWCLxx+JatI419p+uQoCsWvLFeViUAgyuteuckgO5GfjbXYMA75naY0qeEH OWEi2X3XL7sYQIdYgDXuxCuwIOhsRCekHI3NW6nWRIxSqSPl3RCRpGXgBwAi1gAFgudG ad1UnWMGMDsGFjlPDAIMVAVbBejxq2d8hthMkqQAzmfZfAvDECCiYcN6BbAnwUArVrlg HIs9Sn4C3BjKe1aCVi7nOnIZ9DEV/9psEnYuIoeRfcx3uzrDyrNf+q93X/fsAfyG5eku N+7A== Received: by 10.152.125.237 with SMTP id mt13mr23275lab.45.1355417857527; Thu, 13 Dec 2012 08:57:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.81.197 with HTTP; Thu, 13 Dec 2012 08:57:17 -0800 (PST) In-Reply-To: References: <1F6FCD47-5EA4-40EC-9682-E290C6F1A25B@vidyo.com> From: Patrik Westin Date: Thu, 13 Dec 2012 08:57:17 -0800 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=f46d04426ccceb8fc004d0becf12 X-Mailman-Approved-At: Fri, 14 Dec 2012 08:53:58 -0800 Cc: "draft-ietf-payload-vp8@tools.ietf.org" , "payload@ietf.org" Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 16:57:44 -0000 --f46d04426ccceb8fc004d0becf12 Content-Type: text/plain; charset=ISO-8859-1 Thanks for pointing out the inconsistency. We've submitted a new draft that fixes that problem. The second issue was intentional. We'll keep it this way. On Thu, Dec 13, 2012 at 8:29 AM, Jonathan Lennox wrote: > Hi, Ali -- > > I just wanted to make sure the issue had been considered; if the WG agrees > that the current design is okay given the limitations I've mentioned, I'm > not going to object. > > Discussion of the issue might be helpful in the document. > > -----Original Message----- > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > Sent: Tuesday, December 11, 2012 7:13 PM > To: Jonathan Lennox; payload@ietf.org > Cc: draft-ietf-payload-vp8@tools.ietf.org > Subject: Re: [payload] WGLC for VP8 Payload > > The first one should be fixed by the authors thru a quick revision. As for > the second one, I will ask the authors reply. Also if there are others who > strongly think one way or another, lets discuss it. > > Jonathan, are you ok if the authors simply acknowledge this in the draft > (assuming they agree with you) or do you actually not like this at all? > > -acbegen > > -----Original Message----- > From: Jonathan Lennox > Date: Tuesday, December 11, 2012 11:49 AM > To: "payload@ietf.org" > Subject: Re: [payload] WGLC for VP8 Payload > > >Hi -- I have two comments on this draft. Sorry for being late. > > > >First of all, an editorial matter: Section 6 says the format has no > >parameters, but section 6.1 lists two optional parameters (max-fr and > >max-fs). > > > > > >Secondly, more substantively, I note that the payload format's rules on > >KEYIDX and TL0PICIDX impose a fair bit of overhead on boxes that wish > >to splice together VP8 streams, since both values are required to > >always increment consecutively in a bitstream (if they're being used). > > > >By contrast, the equivalent fields of the H.264 SVC payload format (in > >the PACSI) just say that IDRPICID must be different in consecutive IDR > >frames, without requiring that the value increment by 1; and TL0PICIDX > >resets to 0 on every IDR frame, rather than carrying on continuously. > >(H.264's IDR frames are analogous for these purposes to VP8's essential > >keyframes). > > > >This means that an H.264 SVC splicer -- as long as it doesn't get > >unlucky, such that the two streams it's splicing happen to have > >identical IDRPICID values at the splice point -- can just transition > >from one bitstream to another at any IDR frame. > > > >By contrast, following a splice, a VP8 splicer must re-write both these > >fields for the rest of the lifetime of the stream, since they each have > >only one valid possible value following the splice. > > > >The VP8 payload format's decision is a reasonable design choice -- as > >compared to the H.264 SVC rules, it removes some ambiguity between > >splice points and packet loss, giving decoders somewhat greater > >visibility as to what's going on in the bitstream, and also allows > >TL0PICIDX and KEYIDX to be orthogonal options because they increment > >independently. However, I wanted to make sure this had been considered > >explicitly by the working group, and we had consensus that it was the > right decision. > > > >(Note well disclaimer: Vidyo has an IPR declaration against the VP8 > >payload -- see .) > > > > > >On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote: > > > >> I have not seen any comments on the list. Please review the draft and > >>post your comments on the list. > >> > >> Thanks. > >> -acbegen > >> > >> -----Original Message----- > >> From: "Ali C. Begen" > >> Date: Monday, November 19, 2012 3:15 PM > >> To: "payload@ietf.org" > >> Subject: [payload] WGLC for VP8 Payload > >> > >>> Hi everyone, > >>> > >>> We had a WGLC for this draft earlier this year and there have been a > >>>few updates to the document. I am starting a 2nd WGLC. Please review > >>>and comment on the list by December 10th. > >>> > >>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_tex > >>> t=1 > >>> > >> https://www.ietf.org/mailman/listinfo/payload > >> > > > >-- > >Jonathan Lennox > >jonathan@vidyo.com > > > > > >_______________________________________________ > >payload mailing list > >payload@ietf.org > >https://www.ietf.org/mailman/listinfo/payload > > --f46d04426ccceb8fc004d0becf12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for poin= ting out the inconsistency. We've submitted a new
draft that fixes that problem.=A0

The second issue was intentional= . We'll keep it this way.

On Thu, Dec 13, 2012 at 8:29 AM, Jonathan Le= nnox <jonathan@vidyo.com> wrote:
Hi, Ali --

I just wanted to make sure the issue had been considered; if the WG agrees = that the current design is okay given the limitations I've mentioned, I= 'm not going to object.

Discussion of the issue might be helpful in the document.

-----Original Message-----
From: Ali C. Begen (abegen) [mailto:abe= gen@cisco.com]
Sent: Tuesday, December 11, 2012 7:13 PM
To: Jonathan Lennox; payload@ietf.org
Cc: draft-ietf-pay= load-vp8@tools.ietf.org
Subject: Re: [payload] WGLC for VP8 Payload

The first one should be fixed by the authors thru a quick revision. As for = the second one, I will ask the authors reply. Also if there are others who = strongly think one way or another, lets discuss it.

Jonathan, are you ok if the authors simply acknowledge this in the draft (a= ssuming they agree with you) or do you actually not like this at all?

-acbegen

-----Original Message-----
From: Jonathan Lennox <jonathan@vi= dyo.com>
Date: Tuesday, December 11, 2012 11:49 AM
To: "payload@ietf.org" &l= t;payload@ietf.org>
Subject: Re: [payload] WGLC for VP8 Payload

>Hi -- I have two comments on this draft. =A0Sorry for being late.
>
>First of all, an editorial matter: Section 6 says the format has no
>parameters, but section 6.1 lists two optional parameters (max-fr and >max-fs).
>
>
>Secondly, more substantively, I note that the payload format's rule= s on
>KEYIDX and TL0PICIDX impose a fair bit of overhead on boxes that wish >to splice together VP8 streams, since both values are required to
>always increment consecutively in a bitstream (if they're being use= d).
>
>By contrast, the equivalent fields of the H.264 SVC payload format (in<= br> >the PACSI) just say that IDRPICID must be different in consecutive IDR<= br> >frames, without requiring that the value increment by 1; and TL0PICIDX<= br> >resets to 0 on every IDR frame, rather than carrying on continuously. >(H.264's IDR frames are analogous for these purposes to VP8's e= ssential
>keyframes).
>
>This means that an H.264 SVC splicer -- as long as it doesn't get >unlucky, such that the two streams it's splicing happen to have
>identical IDRPICID values at the splice point -- can just transition >from one bitstream to another at any IDR frame.
>
>By contrast, following a splice, a VP8 splicer must re-write both these=
>fields for the rest of the lifetime of the stream, since they each have=
>only one valid possible value following the splice.
>
>The VP8 payload format's decision is a reasonable design choice -- = as
>compared to the H.264 SVC rules, it removes some ambiguity between
>splice points and packet loss, giving decoders somewhat greater
>visibility as to what's going on in the bitstream, and also allows<= br> >TL0PICIDX and KEYIDX to be orthogonal options because they increment >independently. =A0However, I wanted to make sure this had been consider= ed
>explicitly by the working group, and we had consensus that it was the r= ight decision.
>
>(Note well disclaimer: Vidyo has an IPR declaration against the VP8
>payload -- see <http://tracker.tools.ietf.org/ipr/1622/>.)
>
>
>On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote:
>
>> I have not seen any comments on the list. Please review the draft = and
>>post =A0your comments on the list.
>>
>> Thanks.
>> -acbegen
>>
>> -----Original Message-----
>> From: "Ali C. Begen" <abegen@cisco.com>
>> Date: Monday, November 19, 2012 3:15 PM
>> To: "payload@ietf.org= " <payload@ietf.org>
>> Subject: [payload] WGLC for VP8 Payload
>>
>>> Hi everyone,
>>>
>>> We had a WGLC for this draft earlier this year and there have = been a
>>>few =A0updates to the document. I am starting a 2nd WGLC. Pleas= e review
>>>and =A0comment on the list by December 10th.
>>>
>>> https://datatracker.ietf.org/doc/draft= -ietf-payload-vp8/?include_tex
>>> t=3D1
>>>
>> https://www.ietf.org/mailman/listinfo/payload
>>
>
>--
>Jonathan Lennox
>jonathan@vidyo.com
>
>
>_______________________________________________
>payload mailing list
>payload@ietf.org
>https://www.ietf.org/mailman/listinfo/payload


--f46d04426ccceb8fc004d0becf12-- From pwestin@google.com Fri Dec 14 13:53:36 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80CE21F873F for ; Fri, 14 Dec 2012 13:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.375 X-Spam-Level: X-Spam-Status: No, score=-102.375 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHSnyp5xXGgF for ; Fri, 14 Dec 2012 13:53:31 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id F0BF121F850B for ; Fri, 14 Dec 2012 13:53:30 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so2522334pad.31 for ; Fri, 14 Dec 2012 13:53:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=QHqnAJ9kgCbWy5N67S9ZMXh5gkcVvWvoMD4sETDZ6IY=; b=ek7aJ5XPpVAGSNpKWJV+SiIOXc+5DASOc28v+ff3uOMDIdkp/38+l2wo5BqbcCp3rM sg9BKQESsnhJRYesRQh06wBHQJBBHJgVH+Aa4oo6Hxbfv81Jb91dAUl1HsW3MK7PVHvh jvxCZWbU6QoiEO1QNwzMJC/3YWBAEWyBtiTmSa3GQkERjDQ7y97CYU2AEW9dWYWr8nbY D8Mzxk4M1lamunCGwe0HwJSRmI4MiG31mRW0t36fdMaJ+A3WHTx5nW0J+5PZCdP13HeO TdYZM42thrZR6HfQBulm1j8pXj0bJVmXzYSA9XsBQ3xFpGWlbsUBlb/KwP3KGCVH6GDi HzgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=QHqnAJ9kgCbWy5N67S9ZMXh5gkcVvWvoMD4sETDZ6IY=; b=YHliLEvv6B07WWegKI3VfQ5PPIwS1PXMafR7LdNb86j6iJFDmMa2j8XN9ckS466Yx0 ObTtrivlYaQ4Oox/uk6xg4jtvNsxt0ZqWDJ1pajVaxEKJOw8YqUZzhOKCZ2IxDu1rPxF Us687yue+d9yYMBeycuo3qqv5uuMh7UR/8XSlq677oJMzXHwdgiENgw7O+Fb3y2ubV61 ER+A+6xNFEmre8kGEtuS2+Y26FCqW60xXxdicE95n9Ypnm2w7tkKIrO8GV1GGI38xCy3 nRYcMJ09OCUbRgCALYco9pYryDfL+uLGp/V1hcdzHIrTG3V7a43FLBoQs86UImj8oS1a gtpQ== Received: by 10.68.247.39 with SMTP id yb7mr19827352pbc.15.1355522010686; Fri, 14 Dec 2012 13:53:30 -0800 (PST) MIME-Version: 1.0 Sender: pwestin@google.com Received: by 10.68.230.166 with HTTP; Fri, 14 Dec 2012 13:53:10 -0800 (PST) In-Reply-To: References: From: Patrik Westin Date: Fri, 14 Dec 2012 13:53:10 -0800 X-Google-Sender-Auth: hhXB0zbxXL4LjE6ovUXEo68pGRY Message-ID: To: "Ali C. Begen (abegen)" Content-Type: multipart/alternative; boundary=047d7b2e0fc9eea50c04d0d70fe6 X-Gm-Message-State: ALoCoQmjPEWNf9TfyXOB6G+gzk7o/AIiAzxHoKORHQW72aQtiX3H97i4dZM5hK8u0gX1tnsL0fm1+eTcqAuS/OOaJgPp8pA4Ib4kk+65oQvgI3XCKjclUgEjF9gkeQ6T4NLqlUOXmG/bSgNkSDWwewimYDku9MSlWbEQsC3eyGRw5SiJy1q4fXs0+tMGUE4XYVRAygxFOLER Cc: Jonathan Lennox , "draft-ietf-payload-vp8@tools.ietf.org" , "payload@ietf.org" Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: pwestin@webrtc.org 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 Dec 2012 21:53:37 -0000 --047d7b2e0fc9eea50c04d0d70fe6 Content-Type: text/plain; charset=ISO-8859-1 Trying to send this again since my previous message did not reach the list. Thanks for pointing out the inconsistency. We've submitted a new draft that fixes that problem. The second issue was intentional. We'll keep it this way. On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abegen) wrote: > Thanks, the authors just rev'ed the draft to fix the first issue. I hope > they will address the second issue first in the list and then reflect the > agreement in the next revision. I will hold on to the doc write-up till > then. > > -acbegen > > -----Original Message----- > From: Jonathan Lennox > Date: Thursday, December 13, 2012 11:29 AM > To: "Ali C. Begen" , "payload@ietf.org" > > Cc: "draft-ietf-payload-vp8@tools.ietf.org" > > Subject: RE: [payload] WGLC for VP8 Payload > > >Hi, Ali -- > > > >I just wanted to make sure the issue had been considered; if the WG > >agrees that the current design is okay given the limitations I've > >mentioned, I'm not going to object. > > > >Discussion of the issue might be helpful in the document. > > > >-----Original Message----- > >From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > >Sent: Tuesday, December 11, 2012 7:13 PM > >To: Jonathan Lennox; payload@ietf.org > >Cc: draft-ietf-payload-vp8@tools.ietf.org > >Subject: Re: [payload] WGLC for VP8 Payload > > > >The first one should be fixed by the authors thru a quick revision. As > >for the second one, I will ask the authors reply. Also if there are > >others who strongly think one way or another, lets discuss it. > > > >Jonathan, are you ok if the authors simply acknowledge this in the draft > >(assuming they agree with you) or do you actually not like this at all? > > > >-acbegen > > > >-----Original Message----- > >From: Jonathan Lennox > >Date: Tuesday, December 11, 2012 11:49 AM > >To: "payload@ietf.org" > >Subject: Re: [payload] WGLC for VP8 Payload > > > >>Hi -- I have two comments on this draft. Sorry for being late. > >> > >>First of all, an editorial matter: Section 6 says the format has no > >>parameters, but section 6.1 lists two optional parameters (max-fr and > >>max-fs). > >> > >> > >>Secondly, more substantively, I note that the payload format's rules on > >>KEYIDX and TL0PICIDX impose a fair bit of overhead on boxes that wish > >>to splice together VP8 streams, since both values are required to > >>always increment consecutively in a bitstream (if they're being used). > >> > >>By contrast, the equivalent fields of the H.264 SVC payload format (in > >>the PACSI) just say that IDRPICID must be different in consecutive IDR > >>frames, without requiring that the value increment by 1; and TL0PICIDX > >>resets to 0 on every IDR frame, rather than carrying on continuously. > >>(H.264's IDR frames are analogous for these purposes to VP8's essential > >>keyframes). > >> > >>This means that an H.264 SVC splicer -- as long as it doesn't get > >>unlucky, such that the two streams it's splicing happen to have > >>identical IDRPICID values at the splice point -- can just transition > >>from one bitstream to another at any IDR frame. > >> > >>By contrast, following a splice, a VP8 splicer must re-write both these > >>fields for the rest of the lifetime of the stream, since they each have > >>only one valid possible value following the splice. > >> > >>The VP8 payload format's decision is a reasonable design choice -- as > >>compared to the H.264 SVC rules, it removes some ambiguity between > >>splice points and packet loss, giving decoders somewhat greater > >>visibility as to what's going on in the bitstream, and also allows > >>TL0PICIDX and KEYIDX to be orthogonal options because they increment > >>independently. However, I wanted to make sure this had been considered > >>explicitly by the working group, and we had consensus that it was the > >>right decision. > >> > >>(Note well disclaimer: Vidyo has an IPR declaration against the VP8 > >>payload -- see .) > >> > >> > >>On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote: > >> > >>> I have not seen any comments on the list. Please review the draft and > >>>post your comments on the list. > >>> > >>> Thanks. > >>> -acbegen > >>> > >>> -----Original Message----- > >>> From: "Ali C. Begen" > >>> Date: Monday, November 19, 2012 3:15 PM > >>> To: "payload@ietf.org" > >>> Subject: [payload] WGLC for VP8 Payload > >>> > >>>> Hi everyone, > >>>> > >>>> We had a WGLC for this draft earlier this year and there have been a > >>>>few updates to the document. I am starting a 2nd WGLC. Please review > >>>>and comment on the list by December 10th. > >>>> > >>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_tex > >>>> t=1 > >>>> > >>> https://www.ietf.org/mailman/listinfo/payload > >>> > >> > >>-- > >>Jonathan Lennox > >>jonathan@vidyo.com > >> > >> > >>_______________________________________________ > >>payload mailing list > >>payload@ietf.org > >>https://www.ietf.org/mailman/listinfo/payload > > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > --047d7b2e0fc9eea50c04d0d70fe6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Trying to send this again since my=A0previous=A0message did not = reach the list.

Thanks for pointing out the inconsistency. We've= submitted a new
draft that fixes that problem.

The second issue was intentional. We= 'll keep it this way.


On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abeg= en) <abegen@cisco.com> wrote:
Thanks, the authors just rev'ed the draf= t to fix the first issue. I hope
they will address the second issue first in the list and then reflect the agreement in the next revision. I will hold on to the doc write-up till
then.

-acbegen

-----Original Message-----
From: Jonathan Lennox <jonathan@vi= dyo.com>
Date: Thursday, December 13, 2012 11:29 AM To: "Ali C. Begen" <abegen= @cisco.com>, "payload@ietf.= org"
<payload@ietf.org>
Cc: "draft-ie= tf-payload-vp8@tools.ietf.org"
<draft-ietf-pay= load-vp8@tools.ietf.org>
Subject: RE: [payload] WGLC f= or VP8 Payload

>Hi, Ali --
>
>I just wanted to make sure the issue had been considered; if the WG
>agrees that the current design is okay given the limitations I've >mentioned, I'm not going to object.
>
>Discussion of the issue might be helpful in the document.
>
>-----Original Message-----
>From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]
>Sent: Tuesday, December 11, 2012 7:13 PM
>To: Jonathan Lennox; payload@ietf.o= rg
>Cc: draft-ietf= -payload-vp8@tools.ietf.org
>Subject: Re: [payload] WGLC for VP8 Payload
>
>The first one should be fixed by the authors thru a quick revision. As<= br> >for the second one, I will ask the authors reply. Also if there are
>others who strongly think one way or another, lets discuss it.
>
>Jonathan, are you ok if the authors simply acknowledge this in the draf= t
>(assuming they agree with you) or do you actually not like this at all?=
>
>-acbegen
>
>-----Original Message-----
>From: Jonathan Lennox <jonatha= n@vidyo.com>
>Date: Tuesday, December 11, 2012 11:49 AM
>To: "payload@ietf.org"= ; <payload@ietf.org>
>Subject: Re: [payload] WGLC for VP8 Payload
>
>>Hi -- I have two comments on this draft. =A0Sorry for being late. >>
>>First of all, an editorial matter: Section 6 says the format has no=
>>parameters, but section 6.1 lists two optional parameters (max-fr a= nd
>>max-fs).
>>
>>
>>Secondly, more substantively, I note that the payload format's = rules on
>>KEYIDX and TL0PICIDX impose a fair bit of overhead on boxes that wi= sh
>>to splice together VP8 streams, since both values are required to >>always increment consecutively in a bitstream (if they're being= used).
>>
>>By contrast, the equivalent fields of the H.264 SVC payload format = (in
>>the PACSI) just say that IDRPICID must be different in consecutive = IDR
>>frames, without requiring that the value increment by 1; and TL0PIC= IDX
>>resets to 0 on every IDR frame, rather than carrying on continuousl= y.
>>(H.264's IDR frames are analogous for these purposes to VP8'= ;s essential
>>keyframes).
>>
>>This means that an H.264 SVC splicer -- as long as it doesn't g= et
>>unlucky, such that the two streams it's splicing happen to have=
>>identical IDRPICID values at the splice point -- can just transitio= n
>>from one bitstream to another at any IDR frame.
>>
>>By contrast, following a splice, a VP8 splicer must re-write both t= hese
>>fields for the rest of the lifetime of the stream, since they each = have
>>only one valid possible value following the splice.
>>
>>The VP8 payload format's decision is a reasonable design choice= -- as
>>compared to the H.264 SVC rules, it removes some ambiguity between<= br> >>splice points and packet loss, giving decoders somewhat greater
>>visibility as to what's going on in the bitstream, and also all= ows
>>TL0PICIDX and KEYIDX to be orthogonal options because they incremen= t
>>independently. =A0However, I wanted to make sure this had been cons= idered
>>explicitly by the working group, and we had consensus that it was t= he
>>right decision.
>>
>>(Note well disclaimer: Vidyo has an IPR declaration against the VP8=
>>payload -- see <http://tracker.tools.ietf.org/ipr/1622/>.)
>>
>>
>>On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote:
>>
>>> I have not seen any comments on the list. Please review the dr= aft and
>>>post =A0your comments on the list.
>>>
>>> Thanks.
>>> -acbegen
>>>
>>> -----Original Message-----
>>> From: "Ali C. Begen" <abegen@cisco.com>
>>> Date: Monday, November 19, 2012 3:15 PM
>>> To: "payload@ietf.org= " <payload@ietf.org>=
>>> Subject: [payload] WGLC for VP8 Payload
>>>
>>>> Hi everyone,
>>>>
>>>> We had a WGLC for this draft earlier this year and there h= ave been a
>>>>few =A0updates to the document. I am starting a 2nd WGLC. P= lease review
>>>>and =A0comment on the list by December 10th.
>>>>
>>>> https://datatracker.ietf.org/doc/d= raft-ietf-payload-vp8/?include_tex
>>>> t=3D1
>>>>
>>> https://www.ietf.org/mailman/listinfo/payload
>>>
>>
>>--
>>Jonathan Lennox
>>jonathan@vidyo.com
>>
>>
>>_______________________________________________
>>payload mailing list
>>payload@ietf.org
>>https://www.ietf.org/mailman/listinfo/payload
>

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

--047d7b2e0fc9eea50c04d0d70fe6-- From abegen@cisco.com Fri Dec 14 14:30:26 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77B121F8AD0 for ; Fri, 14 Dec 2012 14:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.118 X-Spam-Level: X-Spam-Status: No, score=-10.118 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKYZ-+0RXqUq for ; Fri, 14 Dec 2012 14:30:21 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7B621F8AB9 for ; Fri, 14 Dec 2012 14:30:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17594; q=dns/txt; s=iport; t=1355524221; x=1356733821; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=J/TI4pJoji02EJBFisoqy8JhW3+96ddj6NiWL6O5FMY=; b=NLOrsnVonX3lEaImCme0RWOvs5noQoNE2UerMhEgAMFy5hPVdgGeam+N ss1p+vudqSZDzT9Fm2jlrgCgo99gLraamcNpn2+5nsilQcQUozN8PAkf9 LZ1Twc6X7RnbrbzfeQ8SIeEmCE6q9RWDXUQdp6baQcTHgdpN3KxSisJ/r w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFANCny1CtJXG8/2dsb2JhbABFgkkjsn6JIBZzgh4BAQEEAQEBawsMBgEIEQMBAQEBCh0uCxQJCAIEDgUIiAsBC70IjFeDYmEDlyWPLIJzgiI X-IronPort-AV: E=Sophos;i="4.84,284,1355097600"; d="scan'208,217";a="153162174" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 14 Dec 2012 22:30:20 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBEMUKRs023308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Dec 2012 22:30:20 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Fri, 14 Dec 2012 16:30:19 -0600 From: "Ali C. Begen (abegen)" To: "pwestin@webrtc.org" Thread-Topic: [payload] WGLC for VP8 Payload Thread-Index: AQHNxpKRijb9Uyx1rkaO+XOA7twBQpgLNEKAgAkiCoCAAChLAIACfvJggAArcICAAjlHAP//to2A Date: Fri, 14 Dec 2012 22:30:19 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.255.187] Content-Type: multipart/alternative; boundary="_000_C15918F2FCDA0243A7C919DA7C4BE9940CD924F1xmbalnx01ciscoc_" MIME-Version: 1.0 Cc: Jonathan Lennox , "draft-ietf-payload-vp8@tools.ietf.org" , "payload@ietf.org" Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 22:30:26 -0000 --_000_C15918F2FCDA0243A7C919DA7C4BE9940CD924F1xmbalnx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are you at least planning to put some text around the point Jonathan brough= t up? From: Patrik Westin > Reply-To: "pwestin@webrtc.org" > Date: Friday, December 14, 2012 4:53 PM To: "Ali C. Begen" > Cc: Jonathan Lennox >, "paylo= ad@ietf.org" >, "draft-ietf-payload-vp8@tools.ietf.org" > Subject: Re: [payload] WGLC for VP8 Payload Trying to send this again since my previous message did not reach the list. Thanks for pointing out the inconsistency. We've submitted a new draft that fixes that problem. The second issue was intentional. We'll keep it this way. On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abegen) > wrote: Thanks, the authors just rev'ed the draft to fix the first issue. I hope they will address the second issue first in the list and then reflect the agreement in the next revision. I will hold on to the doc write-up till then. -acbegen -----Original Message----- From: Jonathan Lennox > Date: Thursday, December 13, 2012 11:29 AM To: "Ali C. Begen" >, "payload@ie= tf.org" > Cc: "draft-ietf-payload-vp8@tools.ietf.org" > Subject: RE: [payload] WGLC for VP8 Payload >Hi, Ali -- > >I just wanted to make sure the issue had been considered; if the WG >agrees that the current design is okay given the limitations I've >mentioned, I'm not going to object. > >Discussion of the issue might be helpful in the document. > >-----Original Message----- >From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >Sent: Tuesday, December 11, 2012 7:13 PM >To: Jonathan Lennox; payload@ietf.org >Cc: draft-ietf-payload-vp8@tools.ietf.org >Subject: Re: [payload] WGLC for VP8 Payload > >The first one should be fixed by the authors thru a quick revision. As >for the second one, I will ask the authors reply. Also if there are >others who strongly think one way or another, lets discuss it. > >Jonathan, are you ok if the authors simply acknowledge this in the draft >(assuming they agree with you) or do you actually not like this at all? > >-acbegen > >-----Original Message----- >From: Jonathan Lennox > >Date: Tuesday, December 11, 2012 11:49 AM >To: "payload@ietf.org" > >Subject: Re: [payload] WGLC for VP8 Payload > >>Hi -- I have two comments on this draft. Sorry for being late. >> >>First of all, an editorial matter: Section 6 says the format has no >>parameters, but section 6.1 lists two optional parameters (max-fr and >>max-fs). >> >> >>Secondly, more substantively, I note that the payload format's rules on >>KEYIDX and TL0PICIDX impose a fair bit of overhead on boxes that wish >>to splice together VP8 streams, since both values are required to >>always increment consecutively in a bitstream (if they're being used). >> >>By contrast, the equivalent fields of the H.264 SVC payload format (in >>the PACSI) just say that IDRPICID must be different in consecutive IDR >>frames, without requiring that the value increment by 1; and TL0PICIDX >>resets to 0 on every IDR frame, rather than carrying on continuously. >>(H.264's IDR frames are analogous for these purposes to VP8's essential >>keyframes). >> >>This means that an H.264 SVC splicer -- as long as it doesn't get >>unlucky, such that the two streams it's splicing happen to have >>identical IDRPICID values at the splice point -- can just transition >>from one bitstream to another at any IDR frame. >> >>By contrast, following a splice, a VP8 splicer must re-write both these >>fields for the rest of the lifetime of the stream, since they each have >>only one valid possible value following the splice. >> >>The VP8 payload format's decision is a reasonable design choice -- as >>compared to the H.264 SVC rules, it removes some ambiguity between >>splice points and packet loss, giving decoders somewhat greater >>visibility as to what's going on in the bitstream, and also allows >>TL0PICIDX and KEYIDX to be orthogonal options because they increment >>independently. However, I wanted to make sure this had been considered >>explicitly by the working group, and we had consensus that it was the >>right decision. >> >>(Note well disclaimer: Vidyo has an IPR declaration against the VP8 >>payload -- see .) >> >> >>On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote: >> >>> I have not seen any comments on the list. Please review the draft and >>>post your comments on the list. >>> >>> Thanks. >>> -acbegen >>> >>> -----Original Message----- >>> From: "Ali C. Begen" > >>> Date: Monday, November 19, 2012 3:15 PM >>> To: "payload@ietf.org" > >>> Subject: [payload] WGLC for VP8 Payload >>> >>>> Hi everyone, >>>> >>>> We had a WGLC for this draft earlier this year and there have been a >>>>few updates to the document. I am starting a 2nd WGLC. Please review >>>>and comment on the list by December 10th. >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_tex >>>> t=3D1 >>>> >>> https://www.ietf.org/mailman/listinfo/payload >>> >> >>-- >>Jonathan Lennox >>jonathan@vidyo.com >> >> >>_______________________________________________ >>payload mailing list >>payload@ietf.org >>https://www.ietf.org/mailman/listinfo/payload > _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload --_000_C15918F2FCDA0243A7C919DA7C4BE9940CD924F1xmbalnx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <8EE54BB810324F439D423B98AA409000@cisco.com> Content-Transfer-Encoding: quoted-printable
Are you at least planning to put some text around the point Jonathan b= rought up?

From: Patrik Westin <pwestin@webrtc.org>
Reply-To: "pwestin@webrtc.org" <pwestin@webrtc.org>
Date: Friday, December 14, 2012 4:5= 3 PM
To: "Ali C. Begen" <abegen@cisco.com>
Cc: Jonathan Lennox <jonathan@vidyo.com>, "payload@ietf.org" <payload@ietf.org>, "draft-ietf-payload-vp8@tools.ietf.org" <draft-ietf-pa= yload-vp8@tools.ietf.org>
Subject: Re: [payload] WGLC for VP8= Payload

Trying to send this again since my previous mess= age did not reach the list.

Thanks for pointing out the inconsistency. We've submitted a new
draft that fixes that problem.

The second issue was intentional. We'll keep it this way.


On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (a= begen) <abegen@cisco.com<= /a>> wrote:
Thanks, the authors just rev'ed the draft to fix the first issue. I hope they will address the second issue first in the list and then reflect the agreement in the next revision. I will hold on to the doc write-up till
then.

-acbegen

-----Original Message-----
From: Jonathan Lennox <jonathan@vi= dyo.com>
Date: Thursday, December 13, 2012 11:29 AM
To: "Ali C. Begen" <abegen= @cisco.com>, "payload@ietf.= org"
<payload@ietf.org>
Cc: "draft-ie= tf-payload-vp8@tools.ietf.org"
<draft-ietf-pay= load-vp8@tools.ietf.org>
Subject: RE: [payload] WGLC for VP8 Payload

>Hi, Ali --
>
>I just wanted to make sure the issue had been considered; if the WG
>agrees that the current design is okay given the limitations I've
>mentioned, I'm not going to object.
>
>Discussion of the issue might be helpful in the document.
>
>-----Original Message-----
>From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]
>Sent: Tuesday, December 11, 2012 7:13 PM
>To: Jonathan Lennox; payload@ietf.o= rg
>Cc: draft-ietf= -payload-vp8@tools.ietf.org
>Subject: Re: [payload] WGLC for VP8 Payload
>
>The first one should be fixed by the authors thru a quick revision. As<= br> >for the second one, I will ask the authors reply. Also if there are
>others who strongly think one way or another, lets discuss it.
>
>Jonathan, are you ok if the authors simply acknowledge this in the draf= t
>(assuming they agree with you) or do you actually not like this at all?=
>
>-acbegen
>
>-----Original Message-----
>From: Jonathan Lennox <jonatha= n@vidyo.com>
>Date: Tuesday, December 11, 2012 11:49 AM
>To: "payload@ietf.org"= ; <payload@ietf.org>
>Subject: Re: [payload] WGLC for VP8 Payload
>
>>Hi -- I have two comments on this draft.  Sorry for being late= .
>>
>>First of all, an editorial matter: Section 6 says the format has no=
>>parameters, but section 6.1 lists two optional parameters (max-fr a= nd
>>max-fs).
>>
>>
>>Secondly, more substantively, I note that the payload format's rule= s on
>>KEYIDX and TL0PICIDX impose a fair bit of overhead on boxes that wi= sh
>>to splice together VP8 streams, since both values are required to >>always increment consecutively in a bitstream (if they're being use= d).
>>
>>By contrast, the equivalent fields of the H.264 SVC payload format = (in
>>the PACSI) just say that IDRPICID must be different in consecutive = IDR
>>frames, without requiring that the value increment by 1; and TL0PIC= IDX
>>resets to 0 on every IDR frame, rather than carrying on continuousl= y.
>>(H.264's IDR frames are analogous for these purposes to VP8's essen= tial
>>keyframes).
>>
>>This means that an H.264 SVC splicer -- as long as it doesn't get >>unlucky, such that the two streams it's splicing happen to have
>>identical IDRPICID values at the splice point -- can just transitio= n
>>from one bitstream to another at any IDR frame.
>>
>>By contrast, following a splice, a VP8 splicer must re-write both t= hese
>>fields for the rest of the lifetime of the stream, since they each = have
>>only one valid possible value following the splice.
>>
>>The VP8 payload format's decision is a reasonable design choice -- = as
>>compared to the H.264 SVC rules, it removes some ambiguity between<= br> >>splice points and packet loss, giving decoders somewhat greater
>>visibility as to what's going on in the bitstream, and also allows<= br> >>TL0PICIDX and KEYIDX to be orthogonal options because they incremen= t
>>independently.  However, I wanted to make sure this had been c= onsidered
>>explicitly by the working group, and we had consensus that it was t= he
>>right decision.
>>
>>(Note well disclaimer: Vidyo has an IPR declaration against the VP8=
>>payload -- see <http://tracker.tools.ietf.org/ipr/1622/>.)
>>
>>
>>On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote:
>>
>>> I have not seen any comments on the list. Please review the dr= aft and
>>>post  your comments on the list.
>>>
>>> Thanks.
>>> -acbegen
>>>
>>> -----Original Message-----
>>> From: "Ali C. Begen" <abegen@cisco.com>
>>> Date: Monday, November 19, 2012 3:15 PM
>>> To: "payload@ietf.org= " <payload@ietf.org>=
>>> Subject: [payload] WGLC for VP8 Payload
>>>
>>>> Hi everyone,
>>>>
>>>> We had a WGLC for this draft earlier this year and there h= ave been a
>>>>few  updates to the document. I am starting a 2nd WGLC= . Please review
>>>>and  comment on the list by December 10th.
>>>>
>>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_tex >>>> t=3D1
>>>>
>>> https://www.ietf.org/mailman/listinfo/payload
>>>
>>
>>--
>>Jonathan Lennox
>>jonathan@vidyo.com
>>
>>
>>_______________________________________________
>>payload mailing list
>>payload@ietf.org
>>https://www.ietf.org/mailman/listinfo/payload
>

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


--_000_C15918F2FCDA0243A7C919DA7C4BE9940CD924F1xmbalnx01ciscoc_-- From pwestin@google.com Fri Dec 14 14:47:13 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D466C21F8AF4 for ; Fri, 14 Dec 2012 14:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.375 X-Spam-Level: X-Spam-Status: No, score=-102.375 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZbHSeaTjZHb for ; Fri, 14 Dec 2012 14:47:09 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id B0DB221F8AF9 for ; Fri, 14 Dec 2012 14:47:09 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id hz11so2542899pad.31 for ; Fri, 14 Dec 2012 14:47:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=d6jODAcelag7NglE1WLfrLlPI6VBNFYfasCD7lB4JQU=; b=UJe2rwMbvRxxIAX5J0BljjQAs7d7SD2YNrdkSaSb6SJgVqwtUaAcReH0P7RCnvPPo2 IBjtkvveVH8YPFAU3hf9/8u2Fag87MREdorXXMO3HBm69Urs97v4YIvc2XfOMwA2+g6O IsWXsTVSIIBG+tcs9GQjR3jM8gRqTr4yqz2OvtORcbFIJ2ozCYzMXfpmjpXkqHHMRBZ+ IDMxi+OCEUq6aCKhTqrR3KdpgekKfbyBmjchMmeGixFV2wx9sUK+lpEdiErVUNH/UKmp Lpg88+q0VAvonlBmcS1H+BNVPI886CTfC+7Wf0t7BoOzAUdFMsZOCptuga3Q8X0jLw3j E/ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=d6jODAcelag7NglE1WLfrLlPI6VBNFYfasCD7lB4JQU=; b=IGleZCC6ZsBi/nn8aCHRjg5N9DOLaEyVYWbWTJDOI0rmeGiEzG6fq3AD3q6PEUT9VY ffvhY1FKjZVo/UXgLohN3hKHYweG2yquaf855Lfes8dR50eCuitAmgi4R2Z7IGNv9JSK R5GxNj3+WCiuYBZIu3xTaeVCSlDki40HvRz/TloK63pBd6b5+M0YI50J5HeiH3OZUIDX osFZ/PWUv1nBd7y73qURMr+iDxZbYVBs8gAmjNt7akH7koEu/9+oQSuCKpReEWwc7Ez+ jvKdKoewI3Fc8uwAUydosYDfXmUZ5Inhy/qJSaxU94Z0orDq800Jwxu60inmNgeXZTQC 1VRA== Received: by 10.68.247.39 with SMTP id yb7mr20165383pbc.15.1355525229351; Fri, 14 Dec 2012 14:47:09 -0800 (PST) MIME-Version: 1.0 Sender: pwestin@google.com Received: by 10.68.230.166 with HTTP; Fri, 14 Dec 2012 14:46:49 -0800 (PST) In-Reply-To: References: From: Patrik Westin Date: Fri, 14 Dec 2012 14:46:49 -0800 X-Google-Sender-Auth: 2nJEG--xZl9HbxDIgpcsN2EBI1k Message-ID: To: "Ali C. Begen (abegen)" Content-Type: multipart/alternative; boundary=047d7b2e0fc9c7954804d0d7cf4d X-Gm-Message-State: ALoCoQl+tVlB0i/tNf3ueTMJIQ+8aYMKUfqkyqm9KMbnyYGXhtbQ4kYOzIWi+/te+qG0/3fE70HPpT8PwNnTt+YzezSBUOKe6jv1GtbzJe0GDilObkin0HQlltzg/m7trnpO43S/tuNnUVt8I15HuNgtrgUQZ+EnzRdkafSUjAtyKzVHJfJopf+QSJfv4ijv/ySflsZb3Lpt Cc: Jonathan Lennox , "draft-ietf-payload-vp8@tools.ietf.org" , "payload@ietf.org" Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: pwestin@webrtc.org 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 Dec 2012 22:47:14 -0000 --047d7b2e0fc9c7954804d0d7cf4d Content-Type: text/plain; charset=ISO-8859-1 Well he did not have a point in my mind. This is what he wrote. "The VP8 payload format's decision is a reasonable design choice -- as compared to the H.264 SVC rules, it removes some ambiguity between splice points and packet loss, giving decoders somewhat greater visibility as to what's going on in the bitstream, and also allows TL0PICIDX and KEYIDX to be orthogonal options because they increment independently." The worst thing that can happen in a draft is to leave ambiguity, which we don't have in the current draft. However if we do it the way H.264 SVC do we could introduce such ambiguity On Fri, Dec 14, 2012 at 2:30 PM, Ali C. Begen (abegen) wrote: > Are you at least planning to put some text around the point Jonathan > brought up? > > From: Patrik Westin > Reply-To: "pwestin@webrtc.org" > Date: Friday, December 14, 2012 4:53 PM > > To: "Ali C. Begen" > Cc: Jonathan Lennox , "payload@ietf.org" < > payload@ietf.org>, "draft-ietf-payload-vp8@tools.ietf.org" < > draft-ietf-payload-vp8@tools.ietf.org> > > Subject: Re: [payload] WGLC for VP8 Payload > > Trying to send this again since my previous message did not reach the > list. > > Thanks for pointing out the inconsistency. We've submitted a new > draft that fixes that problem. > > The second issue was intentional. We'll keep it this way. > > > On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abegen) wrote: > >> Thanks, the authors just rev'ed the draft to fix the first issue. I hope >> they will address the second issue first in the list and then reflect the >> agreement in the next revision. I will hold on to the doc write-up till >> then. >> >> -acbegen >> >> -----Original Message----- >> From: Jonathan Lennox >> Date: Thursday, December 13, 2012 11:29 AM >> To: "Ali C. Begen" , "payload@ietf.org" >> >> Cc: "draft-ietf-payload-vp8@tools.ietf.org" >> >> Subject: RE: [payload] WGLC for VP8 Payload >> >> >Hi, Ali -- >> > >> >I just wanted to make sure the issue had been considered; if the WG >> >agrees that the current design is okay given the limitations I've >> >mentioned, I'm not going to object. >> > >> >Discussion of the issue might be helpful in the document. >> > >> >-----Original Message----- >> >From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >> >Sent: Tuesday, December 11, 2012 7:13 PM >> >To: Jonathan Lennox; payload@ietf.org >> >Cc: draft-ietf-payload-vp8@tools.ietf.org >> >Subject: Re: [payload] WGLC for VP8 Payload >> > >> >The first one should be fixed by the authors thru a quick revision. As >> >for the second one, I will ask the authors reply. Also if there are >> >others who strongly think one way or another, lets discuss it. >> > >> >Jonathan, are you ok if the authors simply acknowledge this in the draft >> >(assuming they agree with you) or do you actually not like this at all? >> > >> >-acbegen >> > >> >-----Original Message----- >> >From: Jonathan Lennox >> >Date: Tuesday, December 11, 2012 11:49 AM >> >To: "payload@ietf.org" >> >Subject: Re: [payload] WGLC for VP8 Payload >> > >> >>Hi -- I have two comments on this draft. Sorry for being late. >> >> >> >>First of all, an editorial matter: Section 6 says the format has no >> >>parameters, but section 6.1 lists two optional parameters (max-fr and >> >>max-fs). >> >> >> >> >> >>Secondly, more substantively, I note that the payload format's rules on >> >>KEYIDX and TL0PICIDX impose a fair bit of overhead on boxes that wish >> >>to splice together VP8 streams, since both values are required to >> >>always increment consecutively in a bitstream (if they're being used). >> >> >> >>By contrast, the equivalent fields of the H.264 SVC payload format (in >> >>the PACSI) just say that IDRPICID must be different in consecutive IDR >> >>frames, without requiring that the value increment by 1; and TL0PICIDX >> >>resets to 0 on every IDR frame, rather than carrying on continuously. >> >>(H.264's IDR frames are analogous for these purposes to VP8's essential >> >>keyframes). >> >> >> >>This means that an H.264 SVC splicer -- as long as it doesn't get >> >>unlucky, such that the two streams it's splicing happen to have >> >>identical IDRPICID values at the splice point -- can just transition >> >>from one bitstream to another at any IDR frame. >> >> >> >>By contrast, following a splice, a VP8 splicer must re-write both these >> >>fields for the rest of the lifetime of the stream, since they each have >> >>only one valid possible value following the splice. >> >> >> >>The VP8 payload format's decision is a reasonable design choice -- as >> >>compared to the H.264 SVC rules, it removes some ambiguity between >> >>splice points and packet loss, giving decoders somewhat greater >> >>visibility as to what's going on in the bitstream, and also allows >> >>TL0PICIDX and KEYIDX to be orthogonal options because they increment >> >>independently. However, I wanted to make sure this had been considered >> >>explicitly by the working group, and we had consensus that it was the >> >>right decision. >> >> >> >>(Note well disclaimer: Vidyo has an IPR declaration against the VP8 >> >>payload -- see .) >> >> >> >> >> >>On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote: >> >> >> >>> I have not seen any comments on the list. Please review the draft and >> >>>post your comments on the list. >> >>> >> >>> Thanks. >> >>> -acbegen >> >>> >> >>> -----Original Message----- >> >>> From: "Ali C. Begen" >> >>> Date: Monday, November 19, 2012 3:15 PM >> >>> To: "payload@ietf.org" >> >>> Subject: [payload] WGLC for VP8 Payload >> >>> >> >>>> Hi everyone, >> >>>> >> >>>> We had a WGLC for this draft earlier this year and there have been a >> >>>>few updates to the document. I am starting a 2nd WGLC. Please review >> >>>>and comment on the list by December 10th. >> >>>> >> >>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_tex >> >>>> t=1 >> >>>> >> >>> https://www.ietf.org/mailman/listinfo/payload >> >>> >> >> >> >>-- >> >>Jonathan Lennox >> >>jonathan@vidyo.com >> >> >> >> >> >>_______________________________________________ >> >>payload mailing list >> >>payload@ietf.org >> >>https://www.ietf.org/mailman/listinfo/payload >> > >> >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload >> > > > > --047d7b2e0fc9c7954804d0d7cf4d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Well he did not have a point in my mind. This is what he wr= ote.

"The VP8 payload format's decision is a reasona= ble design choice -- as compared to the H.264 SVC rules, it removes some am= biguity between splice points and packet loss, giving decoders somewhat gre= ater visibility as to what's going on in the bitstream, and also allows= TL0PICIDX and KEYIDX to be orthogonal options because they increment indep= endently."

The w= orst thing that can happen in a draft is to leave=A0ambiguity, which we don't have in = the current draft. However if we do it the way=A0H.264 SVC=A0do we could introduce such=A0<= /span>ambiguity=


On Fri, Dec 1= 4, 2012 at 2:30 PM, Ali C. Begen (abegen) <abegen@cisco.com> = wrote:
Are you at least planning to put some text around the point Jonathan b= rought up?

From: Patrik Westin <pwestin@webrtc.org>
Reply-To: "pwestin@webrtc.org" <pwestin@webrtc.org&g= t;
Date: Friday, December 14, 2012 4:5= 3 PM

To: "Ali C. Begen" <abegen@cisco.com>= ;
Cc: Jonathan Lennox <jonathan@vidyo.com&g= t;, "payload@iet= f.org" <p= ayload@ietf.org>, "draft-ietf-payload-vp8@tools.ietf.org&qu= ot; <draft-ietf-payload-vp8@tools.ietf.org>
Subject: Re: [payload] WGLC for VP8= Payload

Trying to send this again since my=A0previous=A0message di= d not reach the list.

Thanks for pointing out the inconsistency. We've submitted a new
draft that fixes that problem.

The second issue was intentional. We'll keep it this way.


On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (a= begen) <abegen@cisco.com<= /a>> wrote:
Thanks, the authors just rev'ed the draft to fix the first issue. I hop= e
they will address the second issue first in the list and then reflect the agreement in the next revision. I will hold on to the doc write-up till
then.
Subject: RE: [payload] WGLC for VP8 Payload

>Hi, Ali --
>
>I just wanted to make sure the issue had been considered; if the WG
>agrees that the current design is okay given the limitations I've >mentioned, I'm not going to object.
>
>Discussion of the issue might be helpful in the document.
>
>-----Original Message-----
>From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]
>Sent: Tuesday, December 11, 2012 7:13 PM
>To: Jonathan Lennox; payload@ietf.org
>Cc: draft-ietf-payload-vp8@tools.ietf.org
>Subject: Re: [payload] WGLC for VP8 Payload
>
>The first one should be fixed by the authors thru a quick revision. As<= br> >for the second one, I will ask the authors reply. Also if there are
>others who strongly think one way or another, lets discuss it.
>
>Jonathan, are you ok if the authors simply acknowledge this in the draf= t
>(assuming they agree with you) or do you actually not like this at all?=
>
>-acbegen
>
>-----Original Message-----
>From: Jonathan Lennox <jonathan@vidyo.com>
>Date: Tuesday, December 11, 2012 11:49 AM
>To: "payload= @ietf.org" <payload@ietf.org>
>Subject: Re: [payload] WGLC for VP8 Payload
>
>>Hi -- I have two comments on this draft. =A0Sorry for being late. >>
>>First of all, an editorial matter: Section 6 says the format has no=
>>parameters, but section 6.1 lists two optional parameters (max-fr a= nd
>>max-fs).
>>
>>
>>Secondly, more substantively, I note that the payload format's = rules on
>>KEYIDX and TL0PICIDX impose a fair bit of overhead on boxes that wi= sh
>>to splice together VP8 streams, since both values are required to >>always increment consecutively in a bitstream (if they're being= used).
>>
>>By contrast, the equivalent fields of the H.264 SVC payload format = (in
>>the PACSI) just say that IDRPICID must be different in consecutive = IDR
>>frames, without requiring that the value increment by 1; and TL0PIC= IDX
>>resets to 0 on every IDR frame, rather than carrying on continuousl= y.
>>(H.264's IDR frames are analogous for these purposes to VP8'= ;s essential
>>keyframes).
>>
>>This means that an H.264 SVC splicer -- as long as it doesn't g= et
>>unlucky, such that the two streams it's splicing happen to have=
>>identical IDRPICID values at the splice point -- can just transitio= n
>>from one bitstream to another at any IDR frame.
>>
>>By contrast, following a splice, a VP8 splicer must re-write both t= hese
>>fields for the rest of the lifetime of the stream, since they each = have
>>only one valid possible value following the splice.
>>
>>The VP8 payload format's decision is a reasonable design choice= -- as
>>compared to the H.264 SVC rules, it removes some ambiguity between<= br> >>splice points and packet loss, giving decoders somewhat greater
>>visibility as to what's going on in the bitstream, and also all= ows
>>TL0PICIDX and KEYIDX to be orthogonal options because they incremen= t
>>independently. =A0However, I wanted to make sure this had been cons= idered
>>explicitly by the working group, and we had consensus that it was t= he
>>right decision.
>>
>>(Note well disclaimer: Vidyo has an IPR declaration against the VP8=
>>payload -- see <http://tracker.tools.ietf.org/ipr/1622/>.)
>>
>>
>>On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote:
>>
>>> I have not seen any comments on the list. Please review the dr= aft and
>>>post =A0your comments on the list.
>>>
>>> Thanks.
>>> -acbegen
>>>
>>> -----Original Message-----
>>> From: "Ali C. Begen" <abegen@cisco.com>
>>> Date: Monday, November 19, 2012 3:15 PM
>>> To: "payload@ietf.org" <payload@ietf.org>
>>> Subject: [payload] WGLC for VP8 Payload
>>>
>>>> Hi everyone,
>>>>
>>>> We had a WGLC for this draft earlier this year and there h= ave been a
>>>>few =A0updates to the document. I am starting a 2nd WGLC. P= lease review
>>>>and =A0comment on the list by December 10th.
>>>>
>>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_tex >>>> t=3D1
>>>>
>>> https://www.ietf.org/mailman/listinfo/payload
>>>
>>
>>--
>>Jonathan Lennox
>>jonathan@vi= dyo.com
>>
>>
>>_______________________________________________
>>payload mailing list
>>payload@ietf.= org
>>https://www.ietf.org/mailman/listinfo/payload
>

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



--047d7b2e0fc9c7954804d0d7cf4d-- From jonathan@vidyo.com Fri Dec 14 14:55:36 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E91621F8A7D for ; Fri, 14 Dec 2012 14:55:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vsmRuUaX83h for ; Fri, 14 Dec 2012 14:55:32 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id BDA5221F8B1D for ; Fri, 14 Dec 2012 14:55:31 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 07B844168E4; Fri, 14 Dec 2012 11:53:44 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id C348241683A; Fri, 14 Dec 2012 11:53:41 -0500 (EST) Received: from BE235.mail.lan ([10.110.32.235]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Fri, 14 Dec 2012 17:55:03 -0500 From: Jonathan Lennox To: "pwestin@webrtc.org" , "Ali C. Begen (abegen)" Date: Fri, 14 Dec 2012 17:55:27 -0500 Thread-Topic: [payload] WGLC for VP8 Payload Thread-Index: Ac3aTPRtnjCdsSIbQ7K1Ar7H3pwg+QAANlmQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C3759687E4991243A1A0BD44EAC823034DFAE1DA60BE235maillan_" MIME-Version: 1.0 Cc: "draft-ietf-payload-vp8@tools.ietf.org" , "payload@ietf.org" Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 22:55:36 -0000 --_000_C3759687E4991243A1A0BD44EAC823034DFAE1DA60BE235maillan_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What I think Ali meant was to add some text describing the implications of = this design choice for splicers - i.e., if these features are in use, they = must re-write packets indefinitely following a splice. From: pwestin@google.com [mailto:pwestin@google.com] On Behalf Of Patrik We= stin Sent: Friday, December 14, 2012 5:47 PM To: Ali C. Begen (abegen) Cc: Jonathan Lennox; payload@ietf.org; draft-ietf-payload-vp8@tools.ietf.or= g Subject: Re: [payload] WGLC for VP8 Payload Well he did not have a point in my mind. This is what he wrote. "The VP8 payload format's decision is a reasonable design choice -- as comp= ared to the H.264 SVC rules, it removes some ambiguity between splice point= s and packet loss, giving decoders somewhat greater visibility as to what's= going on in the bitstream, and also allows TL0PICIDX and KEYIDX to be orth= ogonal options because they increment independently." The worst thing that can happen in a draft is to leave ambiguity, which we = don't have in the current draft. However if we do it the way H.264 SVC do w= e could introduce such ambiguity On Fri, Dec 14, 2012 at 2:30 PM, Ali C. Begen (abegen) > wrote: Are you at least planning to put some text around the point Jonathan brough= t up? From: Patrik Westin > Reply-To: "pwestin@webrtc.org" > Date: Friday, December 14, 2012 4:53 PM To: "Ali C. Begen" > Cc: Jonathan Lennox >, "paylo= ad@ietf.org" >, "draft-ietf-payload-vp8@tools.ietf.org" > Subject: Re: [payload] WGLC for VP8 Payload Trying to send this again since my previous message did not reach the list. Thanks for pointing out the inconsistency. We've submitted a new draft that fixes that problem. The second issue was intentional. We'll keep it this way. On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abegen) > wrote: Thanks, the authors just rev'ed the draft to fix the first issue. I hope they will address the second issue first in the list and then reflect the agreement in the next revision. I will hold on to the doc write-up till then. -acbegen -----Original Message----- From: Jonathan Lennox > Date: Thursday, December 13, 2012 11:29 AM To: "Ali C. Begen" >, "payload@ie= tf.org" > Cc: "draft-ietf-payload-vp8@tools.ietf.org" > Subject: RE: [payload] WGLC for VP8 Payload >Hi, Ali -- > >I just wanted to make sure the issue had been considered; if the WG >agrees that the current design is okay given the limitations I've >mentioned, I'm not going to object. > >Discussion of the issue might be helpful in the document. > >-----Original Message----- >From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >Sent: Tuesday, December 11, 2012 7:13 PM >To: Jonathan Lennox; payload@ietf.org >Cc: draft-ietf-payload-vp8@tools.ietf.org >Subject: Re: [payload] WGLC for VP8 Payload > >The first one should be fixed by the authors thru a quick revision. As >for the second one, I will ask the authors reply. Also if there are >others who strongly think one way or another, lets discuss it. > >Jonathan, are you ok if the authors simply acknowledge this in the draft >(assuming they agree with you) or do you actually not like this at all? > >-acbegen > >-----Original Message----- >From: Jonathan Lennox > >Date: Tuesday, December 11, 2012 11:49 AM >To: "payload@ietf.org" > >Subject: Re: [payload] WGLC for VP8 Payload > >>Hi -- I have two comments on this draft. Sorry for being late. >> >>First of all, an editorial matter: Section 6 says the format has no >>parameters, but section 6.1 lists two optional parameters (max-fr and >>max-fs). >> >> >>Secondly, more substantively, I note that the payload format's rules on >>KEYIDX and TL0PICIDX impose a fair bit of overhead on boxes that wish >>to splice together VP8 streams, since both values are required to >>always increment consecutively in a bitstream (if they're being used). >> >>By contrast, the equivalent fields of the H.264 SVC payload format (in >>the PACSI) just say that IDRPICID must be different in consecutive IDR >>frames, without requiring that the value increment by 1; and TL0PICIDX >>resets to 0 on every IDR frame, rather than carrying on continuously. >>(H.264's IDR frames are analogous for these purposes to VP8's essential >>keyframes). >> >>This means that an H.264 SVC splicer -- as long as it doesn't get >>unlucky, such that the two streams it's splicing happen to have >>identical IDRPICID values at the splice point -- can just transition >>from one bitstream to another at any IDR frame. >> >>By contrast, following a splice, a VP8 splicer must re-write both these >>fields for the rest of the lifetime of the stream, since they each have >>only one valid possible value following the splice. >> >>The VP8 payload format's decision is a reasonable design choice -- as >>compared to the H.264 SVC rules, it removes some ambiguity between >>splice points and packet loss, giving decoders somewhat greater >>visibility as to what's going on in the bitstream, and also allows >>TL0PICIDX and KEYIDX to be orthogonal options because they increment >>independently. However, I wanted to make sure this had been considered >>explicitly by the working group, and we had consensus that it was the >>right decision. >> >>(Note well disclaimer: Vidyo has an IPR declaration against the VP8 >>payload -- see .) >> >> >>On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote: >> >>> I have not seen any comments on the list. Please review the draft and >>>post your comments on the list. >>> >>> Thanks. >>> -acbegen >>> >>> -----Original Message----- >>> From: "Ali C. Begen" > >>> Date: Monday, November 19, 2012 3:15 PM >>> To: "payload@ietf.org" > >>> Subject: [payload] WGLC for VP8 Payload >>> >>>> Hi everyone, >>>> >>>> We had a WGLC for this draft earlier this year and there have been a >>>>few updates to the document. I am starting a 2nd WGLC. Please review >>>>and comment on the list by December 10th. >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_tex >>>> t=3D1 >>>> >>> https://www.ietf.org/mailman/listinfo/payload >>> >> >>-- >>Jonathan Lennox >>jonathan@vidyo.com >> >> >>_______________________________________________ >>payload mailing list >>payload@ietf.org >>https://www.ietf.org/mailman/listinfo/payload > _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload --_000_C3759687E4991243A1A0BD44EAC823034DFAE1DA60BE235maillan_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

What I th= ink Ali meant was to add some text describing the implications of this desi= gn choice for splicers – i.e., if these features are in use, they mus= t re-write packets indefinitely following a splice.

 

= From:= pwestin@google.com [mailto:pwestin@google.com] On Behalf Of Patr= ik Westin
Sent: Friday, December 14, 2012 5:47 PM
To: A= li C. Begen (abegen)
Cc: Jonathan Lennox; payload@ietf.org; draft= -ietf-payload-vp8@tools.ietf.org
Subject: Re: [payload] WGLC for = VP8 Payload

 

=

Well he did not have a point in my mind. This is= what he wrote.

 

"The VP8 payload format's decision= is a reasonable design choice -- as compared to the H.264 SVC rules, it re= moves some ambiguity between splice points and packet loss, giving decoders= somewhat greater visibility as to what's going on in the bitstream, and al= so allows TL0PICIDX and KEYIDX to be orthogonal options because they increm= ent independently."

&= nbsp;

The worst thing that can happe= n in a draft is to leave ambiguity, which we don't have in the current= draft. However if we do it the way H.264 SVC do we could introdu= ce such ambiguity

 

On Fri,= Dec 14, 2012 at 2:30 PM, Ali C. Begen (abegen) <abegen@cisco.com> wrote:

Are you at least planning to put some text= around the point Jonathan brought up?

 

<= b>From:= Patrik Westin <pwestin@webrtc.org>
Reply-To: "pwestin@webrtc.org" <pwestin@webrtc.org&= gt;
Date: Friday, December 14, 2012 4:53 PM

=


To: "Ali C. Begen" <abegen@cisco.com>

Cc: Jonathan Lennox <jonathan@vidyo.com>, &q= uot;payload@ietf.org<= /a>" <payload= @ietf.org>, "draft-ietf-payload-vp8@tools.ietf.org" &l= t;draft-ietf-payload-vp8@tools.ietf.org>

<= div>


Subject: Re: [payload] WGLC for VP8 Payload

&nbs= p;

Trying to send this again since my = previous message did not reach the list.

Thanks for pointing ou= t the inconsistency. We've submitted a new
draft that fixes that problem= .


The second issue was intention= al. We'll keep it this way.

 

On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abegen) <abegen@cisco.com> wrote:<= o:p>

Thanks, the authors just rev'ed the draft = to fix the first issue. I hope
they will address the second issue first = in the list and then reflect the
agreement in the next revision. I will = hold on to the doc write-up till
then.


-acbegen

-----Original Message-----
From: Jonathan Lenno= x <jonathan@vidy= o.com>

Date: Thursday, D= ecember 13, 2012 11:29 AM
To: "Ali C. Begen" <abegen@cisco.com>, "payload@ietf.org&qu= ot;
<payload@ie= tf.org>
Cc: "draft-ietf-payload-vp8@tools.ietf.org"=
<draft-ietf-payload-vp8@tools.ietf.org>

=

Subject: RE: [payload] WGLC for VP8 Payload
=
>Hi, Ali --
>
>I just wanted to make sure the issue had = been considered; if the WG
>agrees that the current design is okay gi= ven the limitations I've
>mentioned, I'm not going to object.
>=
>Discussion of the issue might be helpful in the document.
>>-----Original Message-----
>From: Ali C. Begen (abegen) [mailto= :abegen@cisco.com= ]
>Sent: Tuesday, December 11, 2012 7:13 PM
>To: Jonathan Lenno= x; payload@ietf.org
>Cc: draft-ietf-payload-vp8@tools.ietf.org
>Subject: Re:= [payload] WGLC for VP8 Payload
>
>The first one should be fixe= d by the authors thru a quick revision. As
>for the second one, I wil= l ask the authors reply. Also if there are
>others who strongly think= one way or another, lets discuss it.
>
>Jonathan, are you ok i= f the authors simply acknowledge this in the draft
>(assuming they ag= ree with you) or do you actually not like this at all?
>
>-acbe= gen
>
>-----Original Message-----
>From: Jonathan Lennox = <jonathan@vidyo.= com>
>Date: Tuesday, December 11, 2012 11:49 AM
>To: &qu= ot;payload@ietf.org" <payload@= ietf.org>
>Subject: Re: [payload] WGLC for VP8 Payload
>=
>>Hi -- I have two comments on this draft.  Sorry for being = late.
>>
>>First of all, an editorial matter: Section 6 s= ays the format has no
>>parameters, but section 6.1 lists two opti= onal parameters (max-fr and
>>max-fs).
>>
>>
= >>Secondly, more substantively, I note that the payload format's rule= s on
>>KEYIDX and TL0PICIDX impose a fair bit of overhead on boxes= that wish
>>to splice together VP8 streams, since both values are= required to
>>always increment consecutively in a bitstream (if t= hey're being used).
>>
>>By contrast, the equivalent fiel= ds of the H.264 SVC payload format (in
>>the PACSI) just say that = IDRPICID must be different in consecutive IDR
>>frames, without re= quiring that the value increment by 1; and TL0PICIDX
>>resets to 0= on every IDR frame, rather than carrying on continuously.
>>(H.26= 4's IDR frames are analogous for these purposes to VP8's essential
>&= gt;keyframes).
>>
>>This means that an H.264 SVC splicer = -- as long as it doesn't get
>>unlucky, such that the two streams = it's splicing happen to have
>>identical IDRPICID values at the sp= lice point -- can just transition
>>from one bitstream to another = at any IDR frame.
>>
>>By contrast, following a splice, a= VP8 splicer must re-write both these
>>fields for the rest of the= lifetime of the stream, since they each have
>>only one valid pos= sible value following the splice.
>>
>>The VP8 payload fo= rmat's decision is a reasonable design choice -- as
>>compared to = the H.264 SVC rules, it removes some ambiguity between
>>splice po= ints and packet loss, giving decoders somewhat greater
>>visibilit= y as to what's going on in the bitstream, and also allows
>>TL0PIC= IDX and KEYIDX to be orthogonal options because they increment
>>i= ndependently.  However, I wanted to make sure this had been considered=
>>explicitly by the working group, and we had consensus that it w= as the
>>right decision.
>>
>>(Note well disclai= mer: Vidyo has an IPR declaration against the VP8
>>payload -- see= <= http://tracker.tools.ietf.org/ipr/1622/>.)
>>
>>>>On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote:
>&= gt;
>>> I have not seen any comments on the list. Please review= the draft and
>>>post  your comments on the list.
>= >>
>>> Thanks.
>>> -acbegen
>>>>>> -----Original Message-----
>>> From: "Ali C= . Begen" <abe= gen@cisco.com>
>>> Date: Monday, November 19, 2012 3:15 = PM
>>> To: "payload@ietf.org" <payload@ietf.org>
>>> Subject: [payloa= d] WGLC for VP8 Payload
>>>
>>>> Hi everyone,>>>>
>>>> We had a WGLC for this draft earlier = this year and there have been a
>>>>few  updates to the= document. I am starting a 2nd WGLC. Please review
>>>>and &= nbsp;comment on the list by December 10th.
>>>>
>>&= gt;> https://datatracker.ietf.org/doc/draft-ietf= -payload-vp8/?include_tex
>>>> t=3D1
>>>>=
>>> https://www.ietf.org/mailman/listinfo/payload
>= >>
>>
>>--
>>Jonathan Lennox
>>jonathan@vidyo.com
>>
>>
>>______________________________________= _________
>>payload mailing list
>>payload@ietf.org
>>https://ww= w.ietf.org/mailman/listinfo/payload
>

____________________= ___________________________
payload mailing list
payload@ietf.org
https://www.ietf= .org/mailman/listinfo/payload

 

=

 

 

&nb= sp;

= --_000_C3759687E4991243A1A0BD44EAC823034DFAE1DA60BE235maillan_-- From pwestin@google.com Fri Dec 14 15:06:57 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE95821F8AD0 for ; Fri, 14 Dec 2012 15:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.375 X-Spam-Level: X-Spam-Status: No, score=-102.375 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4ghVq4slCLX for ; Fri, 14 Dec 2012 15:06:53 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 76BA421F8AAC for ; Fri, 14 Dec 2012 15:06:48 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so2508919pbc.31 for ; Fri, 14 Dec 2012 15:06:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=aQmHzgqmUsTcuvgPEPji7bpeTd/MNMmApKH8L2dSVkc=; b=h4HKkB59crWjFL36PtjHc4C7T1DDWtwk+bkQaLdcaxn6yO6gOWHrbAAM445NPk5iso pKLaLCOkyLL3b8V3JXUmTSbn+8ZhzJwP66HezgX+cH4+19/HlxwhTQJkHz+XnevDRP18 sYsjR4t1f02+40OWVwFoM9jbxOCp5llMAvF8yUrfwToLemIcNQoby1kuD+b2lA3IHXKn pYRNIu2/d9DwxmbKERgool2gsUdbVExBKrjaBEwCoahhLQIdmouFdsDhW2hvRrJ5KOXT wwbZ1F+GYUEzOo0rcp7rp/BfSn87BykOuDYZ6xoiDhYp5TvXCrWaldZuC1Uxoxy2mLbQ tbWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=aQmHzgqmUsTcuvgPEPji7bpeTd/MNMmApKH8L2dSVkc=; b=CmhxtUCcRw0clWEP96cduhBUeFL3tReP5Gj9Wik5HwjlOMV+enyUXym+yPPX2KQrp9 Ar/O+d9fSq/LTzM/ZQHN1bzjKUHLQCIB0Zj/8LDPPhDbsvPcOGZnFkjDh8WdGHsb0KJY zldowBpepV2JbYLjiJcdT1dvbfaqalVbX/Rigzre3qGAmACcHl7tpDLkzZsebzndpal9 omGc6qCrSN6yWonRIVamqvqNaLqNp8J91MWLJN+WlfTldK6OkMqFDmIl4SXAOUDb3Krm vMhUsOR+tPZ6qOEDIfkIVRK12b6ErbI4alnIsjJ2ct/fxFs4Et7MxKig5lquEGlhCeVh f7Gg== Received: by 10.66.89.9 with SMTP id bk9mr19634030pab.67.1355526408084; Fri, 14 Dec 2012 15:06:48 -0800 (PST) MIME-Version: 1.0 Sender: pwestin@google.com Received: by 10.68.230.166 with HTTP; Fri, 14 Dec 2012 15:06:27 -0800 (PST) In-Reply-To: References: From: Patrik Westin Date: Fri, 14 Dec 2012 15:06:27 -0800 X-Google-Sender-Auth: IZdPOupGUS4WgGQx4fYCgdMm4E4 Message-ID: To: Jonathan Lennox Content-Type: multipart/alternative; boundary=f46d042fda54099d2104d0d816d8 X-Gm-Message-State: ALoCoQmMyvVtX29u0NhwpbEc6MPhJmYTAgda8cuWjcv13NUAWh4XHa0gfm6a39t+IALI3XVcYURfBvOTZGdCQpBhaCI8ADH7H4rKjIswIGtZ6oZU5v5IpOpIdzSqEGBHS7ErYu/DMTv4k46tDDFmNe/rz4Wmrlztnd7fZbhEFoMf4Zh0Ra3UUrBvHD2wt21LptYGLbwKGg/9 Cc: "draft-ietf-payload-vp8@tools.ietf.org" , "payload@ietf.org" Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: pwestin@webrtc.org 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 Dec 2012 23:06:58 -0000 --f46d042fda54099d2104d0d816d8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Ali do you really want me to add that to the draft? On Fri, Dec 14, 2012 at 2:55 PM, Jonathan Lennox wrote= : > What I think Ali meant was to add some text describing the implications o= f > this design choice for splicers =96 i.e., if these features are in use, t= hey > must re-write packets indefinitely following a splice.**** > > ** ** > > *From:* pwestin@google.com [mailto:pwestin@google.com] *On Behalf Of *Pat= rik > Westin > *Sent:* Friday, December 14, 2012 5:47 PM > *To:* Ali C. Begen (abegen) > *Cc:* Jonathan Lennox; payload@ietf.org; > draft-ietf-payload-vp8@tools.ietf.org > > *Subject:* Re: [payload] WGLC for VP8 Payload**** > > ** ** > > Well he did not have a point in my mind. This is what he wrote.**** > > ** ** > > "The VP8 payload format's decision is a reasonable design choice -- as > compared to the H.264 SVC rules, it removes some ambiguity between splice > points and packet loss, giving decoders somewhat greater visibility as to > what's going on in the bitstream, and also allows TL0PICIDX and KEYIDX to > be orthogonal options because they increment independently."**** > > ** ** > > The worst thing that can happen in a draft is to leave ambiguity, which w= e > don't have in the current draft. However if we do it the way H.264 SVC do > we could introduce such ambiguity**** > > ** ** > > On Fri, Dec 14, 2012 at 2:30 PM, Ali C. Begen (abegen) > wrote:**** > > Are you at least planning to put some text around the point Jonathan > brought up?**** > > ** ** > > *From: *Patrik Westin > *Reply-To: *"pwestin@webrtc.org" > *Date: *Friday, December 14, 2012 4:53 PM**** > > > *To: *"Ali C. Begen" **** > > *Cc: *Jonathan Lennox , "payload@ietf.org" < > payload@ietf.org>, "draft-ietf-payload-vp8@tools.ietf.org" < > draft-ietf-payload-vp8@tools.ietf.org>**** > > > *Subject: *Re: [payload] WGLC for VP8 Payload**** > > ** ** > > Trying to send this again since my previous message did not reach the lis= t. > > Thanks for pointing out the inconsistency. We've submitted a new > draft that fixes that problem. **** > > > The second issue was intentional. We'll keep it this way.**** > > ** ** > > On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abegen) > wrote:**** > > Thanks, the authors just rev'ed the draft to fix the first issue. I hope > they will address the second issue first in the list and then reflect the > agreement in the next revision. I will hold on to the doc write-up till > then.**** > > > -acbegen > > -----Original Message----- > From: Jonathan Lennox **** > > Date: Thursday, December 13, 2012 11:29 AM > To: "Ali C. Begen" , "payload@ietf.org" > > Cc: "draft-ietf-payload-vp8@tools.ietf.org" > **** > > Subject: RE: [payload] WGLC for VP8 Payload > > >Hi, Ali -- > > > >I just wanted to make sure the issue had been considered; if the WG > >agrees that the current design is okay given the limitations I've > >mentioned, I'm not going to object. > > > >Discussion of the issue might be helpful in the document. > > > >-----Original Message----- > >From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > >Sent: Tuesday, December 11, 2012 7:13 PM > >To: Jonathan Lennox; payload@ietf.org > >Cc: draft-ietf-payload-vp8@tools.ietf.org > >Subject: Re: [payload] WGLC for VP8 Payload > > > >The first one should be fixed by the authors thru a quick revision. As > >for the second one, I will ask the authors reply. Also if there are > >others who strongly think one way or another, lets discuss it. > > > >Jonathan, are you ok if the authors simply acknowledge this in the draft > >(assuming they agree with you) or do you actually not like this at all? > > > >-acbegen > > > >-----Original Message----- > >From: Jonathan Lennox > >Date: Tuesday, December 11, 2012 11:49 AM > >To: "payload@ietf.org" > >Subject: Re: [payload] WGLC for VP8 Payload > > > >>Hi -- I have two comments on this draft. Sorry for being late. > >> > >>First of all, an editorial matter: Section 6 says the format has no > >>parameters, but section 6.1 lists two optional parameters (max-fr and > >>max-fs). > >> > >> > >>Secondly, more substantively, I note that the payload format's rules on > >>KEYIDX and TL0PICIDX impose a fair bit of overhead on boxes that wish > >>to splice together VP8 streams, since both values are required to > >>always increment consecutively in a bitstream (if they're being used). > >> > >>By contrast, the equivalent fields of the H.264 SVC payload format (in > >>the PACSI) just say that IDRPICID must be different in consecutive IDR > >>frames, without requiring that the value increment by 1; and TL0PICIDX > >>resets to 0 on every IDR frame, rather than carrying on continuously. > >>(H.264's IDR frames are analogous for these purposes to VP8's essential > >>keyframes). > >> > >>This means that an H.264 SVC splicer -- as long as it doesn't get > >>unlucky, such that the two streams it's splicing happen to have > >>identical IDRPICID values at the splice point -- can just transition > >>from one bitstream to another at any IDR frame. > >> > >>By contrast, following a splice, a VP8 splicer must re-write both these > >>fields for the rest of the lifetime of the stream, since they each have > >>only one valid possible value following the splice. > >> > >>The VP8 payload format's decision is a reasonable design choice -- as > >>compared to the H.264 SVC rules, it removes some ambiguity between > >>splice points and packet loss, giving decoders somewhat greater > >>visibility as to what's going on in the bitstream, and also allows > >>TL0PICIDX and KEYIDX to be orthogonal options because they increment > >>independently. However, I wanted to make sure this had been considered > >>explicitly by the working group, and we had consensus that it was the > >>right decision. > >> > >>(Note well disclaimer: Vidyo has an IPR declaration against the VP8 > >>payload -- see .) > >> > >> > >>On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote: > >> > >>> I have not seen any comments on the list. Please review the draft and > >>>post your comments on the list. > >>> > >>> Thanks. > >>> -acbegen > >>> > >>> -----Original Message----- > >>> From: "Ali C. Begen" > >>> Date: Monday, November 19, 2012 3:15 PM > >>> To: "payload@ietf.org" > >>> Subject: [payload] WGLC for VP8 Payload > >>> > >>>> Hi everyone, > >>>> > >>>> We had a WGLC for this draft earlier this year and there have been a > >>>>few updates to the document. I am starting a 2nd WGLC. Please review > >>>>and comment on the list by December 10th. > >>>> > >>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_tex > >>>> t=3D1 > >>>> > >>> https://www.ietf.org/mailman/listinfo/payload > >>> > >> > >>-- > >>Jonathan Lennox > >>jonathan@vidyo.com > >> > >> > >>_______________________________________________ > >>payload mailing list > >>payload@ietf.org > >>https://www.ietf.org/mailman/listinfo/payload > > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload**** > > ** ** > > ** ** > > ** ** > > ** ** > --f46d042fda54099d2104d0d816d8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Ali do you really want me to add that to the draft?


On Fri, Dec 14, 2012= at 2:55 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:

What I think = Ali meant was to add some text describing the implications of this design c= hoice for splicers =96 i.e., if these features are in use, they must re-wri= te packets indefinitely following a splice.

=A0<= /p>

From: pwestin@google.com [= mailto:pwestin@goog= le.com] On Behalf Of Patrik Westin
Sent: Friday, December 14, 2012 5:47 PM
To: Ali C. Begen (= abegen)
Cc: Jonathan Lennox; payload@ietf.org; draft-ietf-payload-vp8@tools.ietf.o= rg


Subject: Re: [payload] WGLC for VP8 Paylo= ad

=A0

Well he did not have a point in my mind. This is what he wrote.<= /u>

=A0

"The VP8 payload format'= ;s decision is a reasonable design choice -- as compared to the H.264 SVC r= ules, it removes some ambiguity between splice points and packet loss, givi= ng decoders somewhat greater visibility as to what's going on in the bi= tstream, and also allows TL0PICIDX and KEYIDX to be orthogonal options beca= use they increment independently."

=A0

The worst thing that can happen = in a draft is to leave=A0ambiguity, which we don't have in the current = draft. However if we do it the way=A0H.264 SVC=A0do we could introduce such= =A0ambiguity

=A0

On Fri,= Dec 14, 2012 at 2:30 PM, Ali C. Begen (abegen) <abegen@cisco.com> wrote:

Are you at least planning to = put some text around the point Jonathan brought up?

=A0

=

From: Patrik= Westin <pwestin= @webrtc.org>
Reply-To: "pwestin@webrtc.org" <pwestin@webrtc.org>
Date: Friday, Decemb= er 14, 2012 4:53 PM


To: "Ali C. Begen&= quot; <abegen@cisc= o.com>

Cc: Jo= nathan Lennox <j= onathan@vidyo.com>, "payload@ietf.org" <payload@ietf.org>, "draft-ietf-payload-vp= 8@tools.ietf.org" <draft-ietf-payload-vp8@tools.ietf.org>= ;


Subject: Re: [payl= oad] WGLC for VP8 Payload

=A0

=

Trying to send this a= gain since my=A0previous=A0message did not reach the list.

Thanks fo= r pointing out the inconsistency. We've submitted a new
draft that fixes that problem.


The second issue was intentional. We'll keep it= this way.

=A0

= On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abegen) <abegen@cisco.com> wrote:

Thanks, the authors just rev'ed the d= raft to fix the first issue. I hope
they will address the second issue f= irst in the list and then reflect the
agreement in the next revision. I will hold on to the doc write-up till
= then.


-a= cbegen

-----Original Message-----
From: Jonathan Lennox <jonathan@vidyo.com><= u>

Subject: RE: [payload] WG= LC for VP8 Payload

>Hi, Ali --
>
>I just wanted to ma= ke sure the issue had been considered; if the WG
>agrees that the current design is okay given the limitations I've>mentioned, I'm not going to object.
>
>Discussion of = the issue might be helpful in the document.
>
>-----Original Me= ssage-----
>From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]
>Sent: Tuesday, December 11,= 2012 7:13 PM
>To: Jonathan Lennox; payload@ietf.org
>Cc: draft-ietf-payload-vp8@tools.ietf.org
>Subject: Re: [payl= oad] WGLC for VP8 Payload
>
>The first one should be fixed by t= he authors thru a quick revision. As
>for the second one, I will ask the authors reply. Also if there are
= >others who strongly think one way or another, lets discuss it.
><= br>>Jonathan, are you ok if the authors simply acknowledge this in the d= raft
>(assuming they agree with you) or do you actually not like this at all?=
>
>-acbegen
>
>-----Original Message-----
>F= rom: Jonathan Lennox <jonathan@vidyo.com>
>Date: Tuesday, December 11, 2012 11:49 AM
>To: "payload@ietf.org" <payload@ietf.org>= ;
>Subject: Re: [payload] WGLC for VP8 Payload
>
>>Hi -- I = have two comments on this draft. =A0Sorry for being late.
>>
&g= t;>First of all, an editorial matter: Section 6 says the format has no >>parameters, but section 6.1 lists two optional parameters (max-fr a= nd
>>max-fs).
>>
>>
>>Secondly, more su= bstantively, I note that the payload format's rules on
>>KEYID= X and TL0PICIDX impose a fair bit of overhead on boxes that wish
>>to splice together VP8 streams, since both values are required to>>always increment consecutively in a bitstream (if they're bei= ng used).
>>
>>By contrast, the equivalent fields of the = H.264 SVC payload format (in
>>the PACSI) just say that IDRPICID must be different in consecutive = IDR
>>frames, without requiring that the value increment by 1; and= TL0PICIDX
>>resets to 0 on every IDR frame, rather than carrying = on continuously.
>>(H.264's IDR frames are analogous for these purposes to VP8'= ;s essential
>>keyframes).
>>
>>This means that = an H.264 SVC splicer -- as long as it doesn't get
>>unlucky, s= uch that the two streams it's splicing happen to have
>>identical IDRPICID values at the splice point -- can just transitio= n
>>from one bitstream to another at any IDR frame.
>>>>By contrast, following a splice, a VP8 splicer must re-write both = these
>>fields for the rest of the lifetime of the stream, since they each = have
>>only one valid possible value following the splice.
>= >
>>The VP8 payload format's decision is a reasonable desig= n choice -- as
>>compared to the H.264 SVC rules, it removes some ambiguity between<= br>>>splice points and packet loss, giving decoders somewhat greater<= br>>>visibility as to what's going on in the bitstream, and also = allows
>>TL0PICIDX and KEYIDX to be orthogonal options because they incremen= t
>>independently. =A0However, I wanted to make sure this had been= considered
>>explicitly by the working group, and we had consensu= s that it was the
>>right decision.
>>
>>(Note well disclaimer: Vidyo= has an IPR declaration against the VP8
>>payload -- see <http://tra= cker.tools.ietf.org/ipr/1622/>.)
>>
>>
>>On Dec 5, 2012, at 9:20 PM, Ali C. Begen (a= begen) wrote:
>>
>>> I have not seen any comments on t= he list. Please review the draft and
>>>post =A0your comments o= n the list.
>>>
>>> Thanks.
>>> -acbegen
>>&g= t;
>>> -----Original Message-----
>>> From: "A= li C. Begen" <abegen@cisco.com>
>>> Date: Monday, November 19, 2012 3:15 PM
>>> To: &q= uot;payload@ietf.org<= /a>" <payload= @ietf.org>
>>> Subject: [payload] WGLC for VP8 Payload
>>>
>= ;>>> Hi everyone,
>>>>
>>>> We had a= WGLC for this draft earlier this year and there have been a
>>>= ;>few =A0updates to the document. I am starting a 2nd WGLC. Please revie= w
>>>>and =A0comment on the list by December 10th.
>>>= ;>
>>>> https://datatracker.ietf.= org/doc/draft-ietf-payload-vp8/?include_tex
>>>> t=3D1
>>>>
>>> https://www.iet= f.org/mailman/listinfo/payload
>>>
>>
>>-= -
>>Jonathan Lennox
>>jonathan@vidyo.com
>>
>>
>>_= ______________________________________________
>>payload mailing l= ist
>>payload@ietf.= org
>>https://www.ietf.org/mailman/listinfo/payload
&g= t;

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

=A0

=A0

= =A0

=A0


--f46d042fda54099d2104d0d816d8-- From abegen@cisco.com Fri Dec 14 15:09:27 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CB121F8AB9 for ; Fri, 14 Dec 2012 15:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JExSu3bJV8bZ for ; Fri, 14 Dec 2012 15:09:22 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6655F21F8AAC for ; Fri, 14 Dec 2012 15:09:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28072; q=dns/txt; s=iport; t=1355526562; x=1356736162; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=KzDiM0kAUOz/n7zeUBz+iOjvlLMklIbWZZfmi1sOXSg=; b=FKzqTWnYAGXjaXqVfvQcYZvLaoeonvBdkw8thLXhmD2Z+fvSJIAImrYn euw9eIQ2lWCMYkl9e55nYQMNAWR8ZEVRlgrl2g4S7hLzMAMxC/OzxUDR6 oOT1Ho8lSLQ8WMzjujt8ZhN/o8SZwetmrng8IrEwRyJLaZh4V8qe/GcRh w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFADaxy1CtJV2a/2dsb2JhbABFgkkjsn6JIBZzgh4BAQEEAQEBawsMBgEIEQMBAQEBChYHLgsUCQgCBAENBQiICwELvQiMV4NiYQOXJY8sgnOCIg X-IronPort-AV: E=Sophos;i="4.84,284,1355097600"; d="scan'208,217";a="153173383" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 14 Dec 2012 23:09:21 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBEN9LxF017278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Dec 2012 23:09:21 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Fri, 14 Dec 2012 17:09:21 -0600 From: "Ali C. Begen (abegen)" To: "pwestin@webrtc.org" , Jonathan Lennox Thread-Topic: [payload] WGLC for VP8 Payload Thread-Index: AQHNxpKRijb9Uyx1rkaO+XOA7twBQpgLNEKAgAkiCoCAAChLAIACfvJggAArcICAAjlHAP//to2AgABYcICAAAJqgIAAAxOA//+s+gA= Date: Fri, 14 Dec 2012 23:09:20 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.255.187] Content-Type: multipart/alternative; boundary="_000_C15918F2FCDA0243A7C919DA7C4BE9940CD925ABxmbalnx01ciscoc_" MIME-Version: 1.0 Cc: "draft-ietf-payload-vp8@tools.ietf.org" , "payload@ietf.org" Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 23:09:27 -0000 --_000_C15918F2FCDA0243A7C919DA7C4BE9940CD925ABxmbalnx01ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Personally (chair-hat off), I think we should. It does not harm anything bu= t provides clarification to someone who is not deep down in every detail. From: Patrik Westin > Reply-To: "pwestin@webrtc.org" > Date: Friday, December 14, 2012 6:06 PM To: Jonathan Lennox > Cc: "Ali C. Begen" >, "payload@ie= tf.org" = >, "draft-ietf-payload-vp8@tools.ietf.org" > Subject: Re: [payload] WGLC for VP8 Payload Ali do you really want me to add that to the draft? On Fri, Dec 14, 2012 at 2:55 PM, Jonathan Lennox > wrote: What I think Ali meant was to add some text describing the implications of = this design choice for splicers =96 i.e., if these features are in use, the= y must re-write packets indefinitely following a splice. From:pwestin@google.com [mailto:pwestin@google.c= om] On Behalf Of Patrik Westin Sent: Friday, December 14, 2012 5:47 PM To: Ali C. Begen (abegen) Cc: Jonathan Lennox; payload@ietf.org; draft-ietf-= payload-vp8@tools.ietf.org Subject: Re: [payload] WGLC for VP8 Payload Well he did not have a point in my mind. This is what he wrote. "The VP8 payload format's decision is a reasonable design choice -- as comp= ared to the H.264 SVC rules, it removes some ambiguity between splice point= s and packet loss, giving decoders somewhat greater visibility as to what's= going on in the bitstream, and also allows TL0PICIDX and KEYIDX to be orth= ogonal options because they increment independently." The worst thing that can happen in a draft is to leave ambiguity, which we = don't have in the current draft. However if we do it the way H.264 SVC do w= e could introduce such ambiguity On Fri, Dec 14, 2012 at 2:30 PM, Ali C. Begen (abegen) > wrote: Are you at least planning to put some text around the point Jonathan brough= t up? From: Patrik Westin > Reply-To: "pwestin@webrtc.org" > Date: Friday, December 14, 2012 4:53 PM To: "Ali C. Begen" > Cc: Jonathan Lennox >, "paylo= ad@ietf.org" >, "draft-ietf-payload-vp8@tools.ietf.org" > Subject: Re: [payload] WGLC for VP8 Payload Trying to send this again since my previous message did not reach the list. Thanks for pointing out the inconsistency. We've submitted a new draft that fixes that problem. The second issue was intentional. We'll keep it this way. On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abegen) > wrote: Thanks, the authors just rev'ed the draft to fix the first issue. I hope they will address the second issue first in the list and then reflect the agreement in the next revision. I will hold on to the doc write-up till then. -acbegen -----Original Message----- From: Jonathan Lennox > Date: Thursday, December 13, 2012 11:29 AM To: "Ali C. Begen" >, "payload@ie= tf.org" > Cc: "draft-ietf-payload-vp8@tools.ietf.org" > Subject: RE: [payload] WGLC for VP8 Payload >Hi, Ali -- > >I just wanted to make sure the issue had been considered; if the WG >agrees that the current design is okay given the limitations I've >mentioned, I'm not going to object. > >Discussion of the issue might be helpful in the document. > >-----Original Message----- >From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >Sent: Tuesday, December 11, 2012 7:13 PM >To: Jonathan Lennox; payload@ietf.org >Cc: draft-ietf-payload-vp8@tools.ietf.org >Subject: Re: [payload] WGLC for VP8 Payload > >The first one should be fixed by the authors thru a quick revision. As >for the second one, I will ask the authors reply. Also if there are >others who strongly think one way or another, lets discuss it. > >Jonathan, are you ok if the authors simply acknowledge this in the draft >(assuming they agree with you) or do you actually not like this at all? > >-acbegen > >-----Original Message----- >From: Jonathan Lennox > >Date: Tuesday, December 11, 2012 11:49 AM >To: "payload@ietf.org" > >Subject: Re: [payload] WGLC for VP8 Payload > >>Hi -- I have two comments on this draft. Sorry for being late. >> >>First of all, an editorial matter: Section 6 says the format has no >>parameters, but section 6.1 lists two optional parameters (max-fr and >>max-fs). >> >> >>Secondly, more substantively, I note that the payload format's rules on >>KEYIDX and TL0PICIDX impose a fair bit of overhead on boxes that wish >>to splice together VP8 streams, since both values are required to >>always increment consecutively in a bitstream (if they're being used). >> >>By contrast, the equivalent fields of the H.264 SVC payload format (in >>the PACSI) just say that IDRPICID must be different in consecutive IDR >>frames, without requiring that the value increment by 1; and TL0PICIDX >>resets to 0 on every IDR frame, rather than carrying on continuously. >>(H.264's IDR frames are analogous for these purposes to VP8's essential >>keyframes). >> >>This means that an H.264 SVC splicer -- as long as it doesn't get >>unlucky, such that the two streams it's splicing happen to have >>identical IDRPICID values at the splice point -- can just transition >>from one bitstream to another at any IDR frame. >> >>By contrast, following a splice, a VP8 splicer must re-write both these >>fields for the rest of the lifetime of the stream, since they each have >>only one valid possible value following the splice. >> >>The VP8 payload format's decision is a reasonable design choice -- as >>compared to the H.264 SVC rules, it removes some ambiguity between >>splice points and packet loss, giving decoders somewhat greater >>visibility as to what's going on in the bitstream, and also allows >>TL0PICIDX and KEYIDX to be orthogonal options because they increment >>independently. However, I wanted to make sure this had been considered >>explicitly by the working group, and we had consensus that it was the >>right decision. >> >>(Note well disclaimer: Vidyo has an IPR declaration against the VP8 >>payload -- see .) >> >> >>On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote: >> >>> I have not seen any comments on the list. Please review the draft and >>>post your comments on the list. >>> >>> Thanks. >>> -acbegen >>> >>> -----Original Message----- >>> From: "Ali C. Begen" > >>> Date: Monday, November 19, 2012 3:15 PM >>> To: "payload@ietf.org" > >>> Subject: [payload] WGLC for VP8 Payload >>> >>>> Hi everyone, >>>> >>>> We had a WGLC for this draft earlier this year and there have been a >>>>few updates to the document. I am starting a 2nd WGLC. Please review >>>>and comment on the list by December 10th. >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_tex >>>> t=3D1 >>>> >>> https://www.ietf.org/mailman/listinfo/payload >>> >> >>-- >>Jonathan Lennox >>jonathan@vidyo.com >> >> >>_______________________________________________ >>payload mailing list >>payload@ietf.org >>https://www.ietf.org/mailman/listinfo/payload > _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload --_000_C15918F2FCDA0243A7C919DA7C4BE9940CD925ABxmbalnx01ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Personally (chair-hat off), I think we should. It does not harm anythi= ng but provides clarification to someone who is not deep down in every deta= il.

From: Patrik Westin <pwestin@webrtc.org>
Reply-To: "pwestin@webrtc.org" <pwestin@webrtc.org>
Date: Friday, December 14, 2012 6:0= 6 PM
To: Jonathan Lennox <jonathan@vidyo.com>
Cc: "Ali C. Begen" <abegen@cisco.com>, "payload@ietf.org" <payload@ietf.org>, "draft-ietf-payload-vp8@tools.ietf.org" <draft-ietf-pa= yload-vp8@tools.ietf.org>
Subject: Re: [payload] WGLC for VP8= Payload

Ali do you really want me to add that to the draft?


On Fri, Dec 14, 2012 at 2:55 PM, Jonathan Lennox= <jonathan@vidyo.= com> wrote:

What I think Ali meant was to add = some text describing the implications of this design choice for splicers = =96 i.e., if these features are in use, they must re-write packets indefinitely following a splice.<= /span>

 

From:pwestin@google.com [mailto:pwestin@google.com] On Behalf Of Patrik Westin
Sent: Friday, December 14, 2012 5:47 PM
To: Ali C. Begen (abegen)
Cc: Jonathan Lennox; payload@ietf.org; = draft-ietf-payload-vp8@tools.ietf.org


Subject: Re: [payload] WGLC for VP8 Payload

 

Well he did not have a point in my mind. This is what he wrot= e.

 

"The VP8 payload format's decision is a reasonable desig= n choice -- as compared to the H.264 SVC rules, it removes some ambiguity b= etween splice points and packet loss, giving decoders somewhat greater visibility as to what's going on in the bitstrea= m, and also allows TL0PICIDX and KEYIDX to be orthogonal options because th= ey increment independently."

 

The worst thing that can happen in a draft is to leave a= mbiguity, which we don't have in the current draft. However if we do it the= way H.264 SVC do we could introduce such ambiguity

 

On Fri, Dec 14, 2012 at 2:30 PM, Ali C. Begen (abegen) <abegen@cisco.com>= ; wrote:

Are you at least planning to put some text around the poi= nt Jonathan brought up?

 

From: Patrik Westin <pwestin@webrtc.org>
Reply-To: "pwestin@webrtc.org" <pwestin@webrtc.org>
Date: Friday, December 14, 2012 4:53 PM


To: "Ali C. Begen" <abegen@cisco.com>

Cc: Jonathan Lennox <jonathan@vidyo.com>, "payload@ietf.org" <payload@ietf.org>, "draft-ietf-payload-vp8@tools.ietf.org" <draft-ietf-paylo= ad-vp8@tools.ietf.org>


Subject: Re: [payload] WGLC for VP8 Payload

 

Trying to send this again since my previous message= did not reach the list.

Thanks for pointing out the inconsistency. We've submitted a new
draft that fixes that problem.


The second issue was intentional. We'll keep it this way.

 

On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abegen) <abegen@cisco.com>= ; wrote:

Thanks, the authors just rev'ed the draft to fix the first is= sue. I hope
they will address the second issue first in the list and then reflect the agreement in the next revision. I will hold on to the doc write-up till
then.


-acbegen

-----Original Message-----
From: Jonathan Lennox <jonathan@vidyo.com>

Subject: RE: [payload] WGLC for VP8 Payload

>Hi, Ali --
>
>I just wanted to make sure the issue had been considered; if the WG
>agrees that the current design is okay given the limitations I've
>mentioned, I'm not going to object.
>
>Discussion of the issue might be helpful in the document.
>
>-----Original Message-----
>From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]
>Sent: Tuesday, December 11, 2012 7:13 PM
>To: Jonathan Lennox; payload@ietf.org
>Cc: draft-ietf-payload-vp8@tools.ietf.org
>Subject: Re: [payload] WGLC for VP8 Payload
>
>The first one should be fixed by the authors thru a quick revision. As<= br> >for the second one, I will ask the authors reply. Also if there are
>others who strongly think one way or another, lets discuss it.
>
>Jonathan, are you ok if the authors simply acknowledge this in the draf= t
>(assuming they agree with you) or do you actually not like this at all?=
>
>-acbegen
>
>-----Original Message-----
>From: Jonathan Lennox <jonathan@vidyo.com>
>Date: Tuesday, December 11, 2012 11:49 AM
>To: "payload= @ietf.org" <payload@ietf.org>
>Subject: Re: [payload] WGLC for VP8 Payload
>
>>Hi -- I have two comments on this draft.  Sorry for being late= .
>>
>>First of all, an editorial matter: Section 6 says the format has no=
>>parameters, but section 6.1 lists two optional parameters (max-fr a= nd
>>max-fs).
>>
>>
>>Secondly, more substantively, I note that the payload format's rule= s on
>>KEYIDX and TL0PICIDX impose a fair bit of overhead on boxes that wi= sh
>>to splice together VP8 streams, since both values are required to >>always increment consecutively in a bitstream (if they're being use= d).
>>
>>By contrast, the equivalent fields of the H.264 SVC payload format = (in
>>the PACSI) just say that IDRPICID must be different in consecutive = IDR
>>frames, without requiring that the value increment by 1; and TL0PIC= IDX
>>resets to 0 on every IDR frame, rather than carrying on continuousl= y.
>>(H.264's IDR frames are analogous for these purposes to VP8's essen= tial
>>keyframes).
>>
>>This means that an H.264 SVC splicer -- as long as it doesn't get >>unlucky, such that the two streams it's splicing happen to have
>>identical IDRPICID values at the splice point -- can just transitio= n
>>from one bitstream to another at any IDR frame.
>>
>>By contrast, following a splice, a VP8 splicer must re-write both t= hese
>>fields for the rest of the lifetime of the stream, since they each = have
>>only one valid possible value following the splice.
>>
>>The VP8 payload format's decision is a reasonable design choice -- = as
>>compared to the H.264 SVC rules, it removes some ambiguity between<= br> >>splice points and packet loss, giving decoders somewhat greater
>>visibility as to what's going on in the bitstream, and also allows<= br> >>TL0PICIDX and KEYIDX to be orthogonal options because they incremen= t
>>independently.  However, I wanted to make sure this had been c= onsidered
>>explicitly by the working group, and we had consensus that it was t= he
>>right decision.
>>
>>(Note well disclaimer: Vidyo has an IPR declaration against the VP8=
>>payload -- see <http://tracker.tools.ietf.org/ipr/1622/>.)
>>
>>
>>On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote:
>>
>>> I have not seen any comments on the list. Please review the dr= aft and
>>>post  your comments on the list.
>>>
>>> Thanks.
>>> -acbegen
>>>
>>> -----Original Message-----
>>> From: "Ali C. Begen" <abegen@cisco.com>
>>> Date: Monday, November 19, 2012 3:15 PM
>>> To: "payload@ietf.org" <payload@ietf.org>
>>> Subject: [payload] WGLC for VP8 Payload
>>>
>>>> Hi everyone,
>>>>
>>>> We had a WGLC for this draft earlier this year and there h= ave been a
>>>>few  updates to the document. I am starting a 2nd WGLC= . Please review
>>>>and  comment on the list by December 10th.
>>>>
>>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_tex >>>> t=3D1
>>>>
>>> https://www.ietf.org/mailman/listinfo/payload
>>>
>>
>>--
>>Jonathan Lennox
>>jonathan@vi= dyo.com
>>
>>
>>_______________________________________________
>>payload mailing list
>>payload@ietf.= org
>>https://www.ietf.org/mailman/listinfo/payload
>

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

 

 

 

 




--_000_C15918F2FCDA0243A7C919DA7C4BE9940CD925ABxmbalnx01ciscoc_-- From stewe@stewe.org Fri Dec 14 15:27:26 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFCB21F8AC6 for ; Fri, 14 Dec 2012 15:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.748 X-Spam-Level: X-Spam-Status: No, score=-5.748 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcwjByCT8WXJ for ; Fri, 14 Dec 2012 15:27:20 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id E375C21F8992 for ; Fri, 14 Dec 2012 15:27:17 -0800 (PST) Received: from mail123-co9-R.bigfish.com (10.236.132.253) by CO9EHSOBE025.bigfish.com (10.236.130.88) with Microsoft SMTP Server id 14.1.225.23; Fri, 14 Dec 2012 23:27:17 +0000 Received: from mail123-co9 (localhost [127.0.0.1]) by mail123-co9-R.bigfish.com (Postfix) with ESMTP id EBC033C00B4; Fri, 14 Dec 2012 23:27:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.133; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0710HT005.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: PS-28(zz98dI9371I1431Jc85eh148cI542I1432Ic1dM4015I14ffI9a6kzz1de0h1202h1e76h1d1ah1d2ah1082kzz18c673h17326ah8275bh8275dh1033ILz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received-SPF: pass (mail123-co9: domain of stewe.org designates 157.56.240.133 as permitted sender) client-ip=157.56.240.133; envelope-from=stewe@stewe.org; helo=BL2PRD0710HT005.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail123-co9 (localhost.localdomain [127.0.0.1]) by mail123-co9 (MessageSwitch) id 1355527632650948_12604; Fri, 14 Dec 2012 23:27:12 +0000 (UTC) Received: from CO9EHSMHS024.bigfish.com (unknown [10.236.132.246]) by mail123-co9.bigfish.com (Postfix) with ESMTP id 9A4FC1C0056; Fri, 14 Dec 2012 23:27:12 +0000 (UTC) Received: from BL2PRD0710HT005.namprd07.prod.outlook.com (157.56.240.133) by CO9EHSMHS024.bigfish.com (10.236.130.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 14 Dec 2012 23:27:12 +0000 Received: from BL2PRD0710MB349.namprd07.prod.outlook.com ([169.254.2.159]) by BL2PRD0710HT005.namprd07.prod.outlook.com ([10.255.102.40]) with mapi id 14.16.0245.002; Fri, 14 Dec 2012 23:27:08 +0000 From: Stephan Wenger To: "Ali C. Begen (abegen)" , "pwestin@webrtc.org" , Jonathan Lennox Thread-Topic: [payload] WGLC for VP8 Payload Thread-Index: AQHNxpKRijb9Uyx1rkaO+XOA7twBQpgLNEKAgAi9dYCAAHwegIACoveAgAAHbICAAeVzAIAACmGAgAAEnICAAAJqgIAAAxKAgAAAzwD//37XgA== Date: Fri, 14 Dec 2012 23:27:08 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.86.4] Content-Type: multipart/alternative; boundary="_000_FDBFA77C7400C74F87BC297393B53E352FFCE00CBL2PRD0710MB349_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Cc: "payload@ietf.org" , "draft-ietf-payload-vp8@tools.ietf.org" Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 23:27:26 -0000 --_000_FDBFA77C7400C74F87BC297393B53E352FFCE00CBL2PRD0710MB349_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I'm with Ali here. The design choice that has been made in the VP8 payload= is different from the one in the SVC payload, despite similarity in codepo= int names and functionality. The reasoning for that ought to be documented= . In the SVC payload format, we didn't need to, because we were first in d= escribing something like this :-) A sentence or two should suffice, along the lines Jonathan proposed. Stephan From: "Ali C. Begen (abegen)" > Date: Friday, 14 December, 2012 15:09 To: "pwestin@webrtc.org" >, Jonathan Lennox > Cc: "draft-ietf-payload-vp8@tools.ietf.org" >, "payload@ietf.org" > Subject: Re: [payload] WGLC for VP8 Payload Personally (chair-hat off), I think we should. It does not harm anything bu= t provides clarification to someone who is not deep down in every detail. From: Patrik Westin > Reply-To: "pwestin@webrtc.org" > Date: Friday, December 14, 2012 6:06 PM To: Jonathan Lennox > Cc: "Ali C. Begen" >, "payload@ie= tf.org" = >, "draft-ietf-payload-vp8@tools.ietf.org" > Subject: Re: [payload] WGLC for VP8 Payload Ali do you really want me to add that to the draft? On Fri, Dec 14, 2012 at 2:55 PM, Jonathan Lennox > wrote: What I think Ali meant was to add some text describing the implications of = this design choice for splicers =96 i.e., if these features are in use, the= y must re-write packets indefinitely following a splice. From:pwestin@google.com [mailto:pwestin@google.c= om] On Behalf Of Patrik Westin Sent: Friday, December 14, 2012 5:47 PM To: Ali C. Begen (abegen) Cc: Jonathan Lennox; payload@ietf.org; draft-ietf-= payload-vp8@tools.ietf.org Subject: Re: [payload] WGLC for VP8 Payload Well he did not have a point in my mind. This is what he wrote. "The VP8 payload format's decision is a reasonable design choice -- as comp= ared to the H.264 SVC rules, it removes some ambiguity between splice point= s and packet loss, giving decoders somewhat greater visibility as to what's= going on in the bitstream, and also allows TL0PICIDX and KEYIDX to be orth= ogonal options because they increment independently." The worst thing that can happen in a draft is to leave ambiguity, which we = don't have in the current draft. However if we do it the way H.264 SVC do w= e could introduce such ambiguity On Fri, Dec 14, 2012 at 2:30 PM, Ali C. Begen (abegen) > wrote: Are you at least planning to put some text around the point Jonathan brough= t up? From: Patrik Westin > Reply-To: "pwestin@webrtc.org" > Date: Friday, December 14, 2012 4:53 PM To: "Ali C. Begen" > Cc: Jonathan Lennox >, "paylo= ad@ietf.org" >, "draft-ietf-payload-vp8@tools.ietf.org" > Subject: Re: [payload] WGLC for VP8 Payload Trying to send this again since my previous message did not reach the list. Thanks for pointing out the inconsistency. We've submitted a new draft that fixes that problem. The second issue was intentional. We'll keep it this way. On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abegen) > wrote: Thanks, the authors just rev'ed the draft to fix the first issue. I hope they will address the second issue first in the list and then reflect the agreement in the next revision. I will hold on to the doc write-up till then. -acbegen -----Original Message----- From: Jonathan Lennox > Date: Thursday, December 13, 2012 11:29 AM To: "Ali C. Begen" >, "payload@ie= tf.org" > Cc: "draft-ietf-payload-vp8@tools.ietf.org" > Subject: RE: [payload] WGLC for VP8 Payload >Hi, Ali -- > >I just wanted to make sure the issue had been considered; if the WG >agrees that the current design is okay given the limitations I've >mentioned, I'm not going to object. > >Discussion of the issue might be helpful in the document. > >-----Original Message----- >From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] >Sent: Tuesday, December 11, 2012 7:13 PM >To: Jonathan Lennox; payload@ietf.org >Cc: draft-ietf-payload-vp8@tools.ietf.org >Subject: Re: [payload] WGLC for VP8 Payload > >The first one should be fixed by the authors thru a quick revision. As >for the second one, I will ask the authors reply. Also if there are >others who strongly think one way or another, lets discuss it. > >Jonathan, are you ok if the authors simply acknowledge this in the draft >(assuming they agree with you) or do you actually not like this at all? > >-acbegen > >-----Original Message----- >From: Jonathan Lennox > >Date: Tuesday, December 11, 2012 11:49 AM >To: "payload@ietf.org" > >Subject: Re: [payload] WGLC for VP8 Payload > >>Hi -- I have two comments on this draft. Sorry for being late. >> >>First of all, an editorial matter: Section 6 says the format has no >>parameters, but section 6.1 lists two optional parameters (max-fr and >>max-fs). >> >> >>Secondly, more substantively, I note that the payload format's rules on >>KEYIDX and TL0PICIDX impose a fair bit of overhead on boxes that wish >>to splice together VP8 streams, since both values are required to >>always increment consecutively in a bitstream (if they're being used). >> >>By contrast, the equivalent fields of the H.264 SVC payload format (in >>the PACSI) just say that IDRPICID must be different in consecutive IDR >>frames, without requiring that the value increment by 1; and TL0PICIDX >>resets to 0 on every IDR frame, rather than carrying on continuously. >>(H.264's IDR frames are analogous for these purposes to VP8's essential >>keyframes). >> >>This means that an H.264 SVC splicer -- as long as it doesn't get >>unlucky, such that the two streams it's splicing happen to have >>identical IDRPICID values at the splice point -- can just transition >>from one bitstream to another at any IDR frame. >> >>By contrast, following a splice, a VP8 splicer must re-write both these >>fields for the rest of the lifetime of the stream, since they each have >>only one valid possible value following the splice. >> >>The VP8 payload format's decision is a reasonable design choice -- as >>compared to the H.264 SVC rules, it removes some ambiguity between >>splice points and packet loss, giving decoders somewhat greater >>visibility as to what's going on in the bitstream, and also allows >>TL0PICIDX and KEYIDX to be orthogonal options because they increment >>independently. However, I wanted to make sure this had been considered >>explicitly by the working group, and we had consensus that it was the >>right decision. >> >>(Note well disclaimer: Vidyo has an IPR declaration against the VP8 >>payload -- see .) >> >> >>On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote: >> >>> I have not seen any comments on the list. Please review the draft and >>>post your comments on the list. >>> >>> Thanks. >>> -acbegen >>> >>> -----Original Message----- >>> From: "Ali C. Begen" > >>> Date: Monday, November 19, 2012 3:15 PM >>> To: "payload@ietf.org" > >>> Subject: [payload] WGLC for VP8 Payload >>> >>>> Hi everyone, >>>> >>>> We had a WGLC for this draft earlier this year and there have been a >>>>few updates to the document. I am starting a 2nd WGLC. Please review >>>>and comment on the list by December 10th. >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_tex >>>> t=3D1 >>>> >>> https://www.ietf.org/mailman/listinfo/payload >>> >> >>-- >>Jonathan Lennox >>jonathan@vidyo.com >> >> >>_______________________________________________ >>payload mailing list >>payload@ietf.org >>https://www.ietf.org/mailman/listinfo/payload > _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload --_000_FDBFA77C7400C74F87BC297393B53E352FFCE00CBL2PRD0710MB349_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5A7AB7E4DE0CE7419CBCF5F633895AA4@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi,
I'm with Ali here.  The design choice that has been made in the V= P8 payload is different from the one in the SVC payload, despite similarity= in codepoint names and functionality.  The reasoning for that ought t= o be documented.  In the SVC payload format, we didn't need to, because we were first in describing something like this= :-)
A sentence or two should suffice, along the lines Jonathan proposed.
Stephan

From: "Ali C. Begen (abegen)&q= uot; <abegen@cisco.com>
Date: Friday, 14 December, 2012 15:= 09
To: "pwestin@webrtc.org" <pwestin@webrtc.org>, Jonathan Lennox <jonathan@vidyo.com>
Cc: "draft-ietf-payload-vp8@tools.ietf.org&q= uot; <draft-iet= f-payload-vp8@tools.ietf.org>, "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] WGLC for VP8= Payload

Personally (chair-hat off), I think we should. It does not harm anythi= ng but provides clarification to someone who is not deep down in every deta= il.

From: Patrik Westin <pwestin@webrtc.org>
Reply-To: "pwestin@webrtc.org" <pwestin@webrtc.org>
Date: Friday, December 14, 2012 6:0= 6 PM
To: Jonathan Lennox <jonathan@vidyo.com>
Cc: "Ali C. Begen" <abegen@cisco.com>, "payload@ietf.org" <payload@ietf.org>, "draft-ietf-payload-vp8@tools.ietf.org" <draft-ietf-pa= yload-vp8@tools.ietf.org>
Subject: Re: [payload] WGLC for VP8= Payload

Ali do you really want me to add that to the draft?


On Fri, Dec 14, 2012 at 2:55 PM, Jonathan Lennox= <jonathan@vidyo.= com> wrote:

What I think Ali meant was to add = some text describing the implications of this design choice for splicers = =96 i.e., if these features are in use, they must re-write packets indefinitely following a splice.<= /span>

 

From:pwestin@google.com [mailto:pwestin@google.com] On Behalf Of Patrik Westin
Sent: Friday, December 14, 2012 5:47 PM
To: Ali C. Begen (abegen)
Cc: Jonathan Lennox; payload@ietf.org; = draft-ietf-payload-vp8@tools.ietf.org


Subject: Re: [payload] WGLC for VP8 Payload

 

Well he did not have a point in my mind. This is what he wrot= e.

 

"The VP8 payload format's decision is a reasonable desig= n choice -- as compared to the H.264 SVC rules, it removes some ambiguity b= etween splice points and packet loss, giving decoders somewhat greater visibility as to what's going on in the bitstrea= m, and also allows TL0PICIDX and KEYIDX to be orthogonal options because th= ey increment independently."

 

The worst thing that can happen in a draft is to leave a= mbiguity, which we don't have in the current draft. However if we do it the= way H.264 SVC do we could introduce such ambiguity

 

On Fri, Dec 14, 2012 at 2:30 PM, Ali C. Begen (abegen) <abegen@cisco.com>= ; wrote:

Are you at least planning to put some text around the poi= nt Jonathan brought up?

 

From: Patrik Westin <pwestin@webrtc.org>
Reply-To: "pwestin@webrtc.org" <pwestin@webrtc.org>
Date: Friday, December 14, 2012 4:53 PM


To: "Ali C. Begen" <abegen@cisco.com>

Cc: Jonathan Lennox <jonathan@vidyo.com>, "payload@ietf.org" <payload@ietf.org>, "draft-ietf-payload-vp8@tools.ietf.org" <draft-ietf-paylo= ad-vp8@tools.ietf.org>


Subject: Re: [payload] WGLC for VP8 Payload

 

Trying to send this again since my previous message= did not reach the list.

Thanks for pointing out the inconsistency. We've submitted a new
draft that fixes that problem.


The second issue was intentional. We'll keep it this way.

 

On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abegen) <abegen@cisco.com>= ; wrote:

Thanks, the authors just rev'ed the draft to fix the first is= sue. I hope
they will address the second issue first in the list and then reflect the agreement in the next revision. I will hold on to the doc write-up till
then.


-acbegen

-----Original Message-----
From: Jonathan Lennox <jonathan@vidyo.com>

Subject: RE: [payload] WGLC for VP8 Payload

>Hi, Ali --
>
>I just wanted to make sure the issue had been considered; if the WG
>agrees that the current design is okay given the limitations I've
>mentioned, I'm not going to object.
>
>Discussion of the issue might be helpful in the document.
>
>-----Original Message-----
>From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]
>Sent: Tuesday, December 11, 2012 7:13 PM
>To: Jonathan Lennox; payload@ietf.org
>Cc: draft-ietf-payload-vp8@tools.ietf.org
>Subject: Re: [payload] WGLC for VP8 Payload
>
>The first one should be fixed by the authors thru a quick revision. As<= br> >for the second one, I will ask the authors reply. Also if there are
>others who strongly think one way or another, lets discuss it.
>
>Jonathan, are you ok if the authors simply acknowledge this in the draf= t
>(assuming they agree with you) or do you actually not like this at all?=
>
>-acbegen
>
>-----Original Message-----
>From: Jonathan Lennox <jonathan@vidyo.com>
>Date: Tuesday, December 11, 2012 11:49 AM
>To: "payload= @ietf.org" <payload@ietf.org>
>Subject: Re: [payload] WGLC for VP8 Payload
>
>>Hi -- I have two comments on this draft.  Sorry for being late= .
>>
>>First of all, an editorial matter: Section 6 says the format has no=
>>parameters, but section 6.1 lists two optional parameters (max-fr a= nd
>>max-fs).
>>
>>
>>Secondly, more substantively, I note that the payload format's rule= s on
>>KEYIDX and TL0PICIDX impose a fair bit of overhead on boxes that wi= sh
>>to splice together VP8 streams, since both values are required to >>always increment consecutively in a bitstream (if they're being use= d).
>>
>>By contrast, the equivalent fields of the H.264 SVC payload format = (in
>>the PACSI) just say that IDRPICID must be different in consecutive = IDR
>>frames, without requiring that the value increment by 1; and TL0PIC= IDX
>>resets to 0 on every IDR frame, rather than carrying on continuousl= y.
>>(H.264's IDR frames are analogous for these purposes to VP8's essen= tial
>>keyframes).
>>
>>This means that an H.264 SVC splicer -- as long as it doesn't get >>unlucky, such that the two streams it's splicing happen to have
>>identical IDRPICID values at the splice point -- can just transitio= n
>>from one bitstream to another at any IDR frame.
>>
>>By contrast, following a splice, a VP8 splicer must re-write both t= hese
>>fields for the rest of the lifetime of the stream, since they each = have
>>only one valid possible value following the splice.
>>
>>The VP8 payload format's decision is a reasonable design choice -- = as
>>compared to the H.264 SVC rules, it removes some ambiguity between<= br> >>splice points and packet loss, giving decoders somewhat greater
>>visibility as to what's going on in the bitstream, and also allows<= br> >>TL0PICIDX and KEYIDX to be orthogonal options because they incremen= t
>>independently.  However, I wanted to make sure this had been c= onsidered
>>explicitly by the working group, and we had consensus that it was t= he
>>right decision.
>>
>>(Note well disclaimer: Vidyo has an IPR declaration against the VP8=
>>payload -- see <http://tracker.tools.ietf.org/ipr/1622/>.)
>>
>>
>>On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote:
>>
>>> I have not seen any comments on the list. Please review the dr= aft and
>>>post  your comments on the list.
>>>
>>> Thanks.
>>> -acbegen
>>>
>>> -----Original Message-----
>>> From: "Ali C. Begen" <abegen@cisco.com>
>>> Date: Monday, November 19, 2012 3:15 PM
>>> To: "payload@ietf.org" <payload@ietf.org>
>>> Subject: [payload] WGLC for VP8 Payload
>>>
>>>> Hi everyone,
>>>>
>>>> We had a WGLC for this draft earlier this year and there h= ave been a
>>>>few  updates to the document. I am starting a 2nd WGLC= . Please review
>>>>and  comment on the list by December 10th.
>>>>
>>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_tex >>>> t=3D1
>>>>
>>> https://www.ietf.org/mailman/listinfo/payload
>>>
>>
>>--
>>Jonathan Lennox
>>jonathan@vi= dyo.com
>>
>>
>>_______________________________________________
>>payload mailing list
>>payload@ietf.= org
>>https://www.ietf.org/mailman/listinfo/payload
>

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

 

 

 

 




--_000_FDBFA77C7400C74F87BC297393B53E352FFCE00CBL2PRD0710MB349_-- From glenzorn@gmail.com Sat Dec 15 05:11:25 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B9F21F8830 for ; Sat, 15 Dec 2012 05:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhjQgQ9+bX-N for ; Sat, 15 Dec 2012 05:11:23 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9780521F87E7 for ; Sat, 15 Dec 2012 05:11:23 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so2764947pbc.31 for ; Sat, 15 Dec 2012 05:11:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1oKHxFDdZGH+iMrJaJGHNkiT2cQW1dpUsEE3HA3PMhw=; b=J+vXWQFMzyxFkK7e2iTO5xB3rAXOBItn8eA78K5rz7/CD1AW6mVtFzClfKEG36+Z8z niIVm3jtyNLyHWMh7YDQ6qtXTA4ACuBEEFpmuMwQbbxijW6TnTG14BSyRdYyOQ/kHjTs KONgmpNOLcVdWClhXh5p6Alz56xBXTzY3jCz3cyRqkWtVg1sUPe6INbQLzrMuFHt8eZ+ 7EfWidL8wswlWeU3xGdXocZZB84kQxn8bnVVWVOltHVFrRfngznqwNThbZ4R+mE9iwM6 2p24LVIKuElWAxPnky1+QObVFK06G0PlvCng32s7SJ+468kFbsunULevHeDTEZgxYXLR yEaw== Received: by 10.68.240.36 with SMTP id vx4mr24792281pbc.90.1355577083412; Sat, 15 Dec 2012 05:11:23 -0800 (PST) Received: from [192.168.0.102] (ppp-124-120-128-42.revip2.asianet.co.th. [124.120.128.42]) by mx.google.com with ESMTPS id o5sm5034337pay.5.2012.12.15.05.11.17 (version=SSLv3 cipher=OTHER); Sat, 15 Dec 2012 05:11:21 -0800 (PST) Message-ID: <50CC76F3.7060702@gmail.com> Date: Sat, 15 Dec 2012 20:11:15 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Jonathan Lennox , "pwestin@webrtc.org" , "draft-ietf-payload-vp8@tools.ietf.org" , "payload@ietf.org" Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Dec 2012 13:11:25 -0000 On 12/15/2012 06:27 AM, Stephan Wenger wrote: > Hi, I'm with Ali here. Me, too. > The design choice that has been made in the VP8 payload is different > from the one in the SVC payload, despite similarity in codepoint > names and functionality. The reasoning for that ought to be > documented. In the SVC payload format, we didn't need to, because we > were first in describing something like this :-) A sentence or two > should suffice, along the lines Jonathan proposed. Stephan > > From: "Ali C. Begen (abegen)" > Date: Friday, 14 December, 2012 15:09 To: > "pwestin@webrtc.org " >, Jonathan Lennox > Cc: > "draft-ietf-payload-vp8@tools.ietf.org > " > >, "payload@ietf.org > " > Subject: Re: [payload] WGLC for VP8 > Payload > > Personally (chair-hat off), I think we should. It does not harm > anything but provides clarification to someone who is not deep down > in every detail. > > From: Patrik Westin > > Reply-To: "pwestin@webrtc.org " > > Date: Friday, > December 14, 2012 6:06 PM To: Jonathan Lennox > Cc: "Ali C. Begen" >, "payload@ietf.org > " >, "draft-ietf-payload-vp8@tools.ietf.org > " > > Subject: Re: > [payload] WGLC for VP8 Payload > > Ali do you really want me to add that to the draft? > > > On Fri, Dec 14, 2012 at 2:55 PM, Jonathan Lennox > wrote: > > What I think Ali meant was to add some text describing the > implications of this design choice for splicers – i.e., if these > features are in use, they must re-write packets indefinitely > following a splice. > > > > *From:*pwestin@google.com > [mailto:pwestin@google.com ] *On Behalf Of > *Patrik Westin *Sent:* Friday, December 14, 2012 5:47 PM *To:* Ali C. > Begen (abegen) *Cc:* Jonathan Lennox; payload@ietf.org > ; draft-ietf-payload-vp8@tools.ietf.org > > > > *Subject:* Re: [payload] WGLC for VP8 Payload > > > > Well he did not have a point in my mind. This is what he wrote. > > > > "The VP8 payload format's decision is a reasonable design choice -- > as compared to the H.264 SVC rules, it removes some ambiguity between > splice points and packet loss, giving decoders somewhat greater > visibility as to what's going on in the bitstream, and also allows > TL0PICIDX and KEYIDX to be orthogonal options because they increment > independently." > > > > The worst thing that can happen in a draft is to leave ambiguity, > which we don't have in the current draft. However if we do it the way > H.264 SVC do we could introduce such ambiguity > > > > On Fri, Dec 14, 2012 at 2:30 PM, Ali C. Begen (abegen) > > wrote: > > Are you at least planning to put some text around the point Jonathan > brought up? > > > > *From: *Patrik Westin > *Reply-To: *"pwestin@webrtc.org > " > *Date: *Friday, December 14, 2012 4:53 > PM > > > *To: *"Ali C. Begen" > > > *Cc: *Jonathan Lennox >, "payload@ietf.org > " >, "draft-ietf-payload-vp8@tools.ietf.org > " > > > > > *Subject: *Re: [payload] WGLC for VP8 Payload > > > > Trying to send this again since my previous message did not reach the > list. > > Thanks for pointing out the inconsistency. We've submitted a new > draft that fixes that problem. > > > The second issue was intentional. We'll keep it this way. > > > > On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abegen) > > wrote: > > Thanks, the authors just rev'ed the draft to fix the first issue. I > hope they will address the second issue first in the list and then > reflect the agreement in the next revision. I will hold on to the doc > write-up till then. > > > -acbegen > > -----Original Message----- From: Jonathan Lennox > > > Date: Thursday, December 13, 2012 11:29 AM To: "Ali C. Begen" > >, "payload@ietf.org > " > Cc: "draft-ietf-payload-vp8@tools.ietf.org > " > > > > Subject: RE: [payload] WGLC for VP8 Payload > >> Hi, Ali -- >> >> I just wanted to make sure the issue had been considered; if the >> WG agrees that the current design is okay given the limitations >> I've mentioned, I'm not going to object. >> >> Discussion of the issue might be helpful in the document. >> >> -----Original Message----- From: Ali C. Begen (abegen) >> [mailto:abegen@cisco.com ] Sent: Tuesday, >> December 11, 2012 7:13 PM To: Jonathan Lennox; payload@ietf.org >> Cc: draft-ietf-payload-vp8@tools.ietf.org >> Subject: Re: >> [payload] WGLC for VP8 Payload >> >> The first one should be fixed by the authors thru a quick revision. >> As for the second one, I will ask the authors reply. Also if there >> are others who strongly think one way or another, lets discuss it. >> >> Jonathan, are you ok if the authors simply acknowledge this in the >> draft (assuming they agree with you) or do you actually not like >> this at all? >> >> -acbegen >> >> -----Original Message----- From: Jonathan Lennox >> > Date: Tuesday, >> December 11, 2012 11:49 AM To: "payload@ietf.org >> " > > Subject: Re: [payload] WGLC for VP8 >> Payload >> >>> Hi -- I have two comments on this draft. Sorry for being late. >>> >>> First of all, an editorial matter: Section 6 says the format has >>> no parameters, but section 6.1 lists two optional parameters >>> (max-fr and max-fs). >>> >>> >>> Secondly, more substantively, I note that the payload format's >>> rules on KEYIDX and TL0PICIDX impose a fair bit of overhead on >>> boxes that wish to splice together VP8 streams, since both values >>> are required to always increment consecutively in a bitstream (if >>> they're being used). >>> >>> By contrast, the equivalent fields of the H.264 SVC payload >>> format (in the PACSI) just say that IDRPICID must be different in >>> consecutive IDR frames, without requiring that the value >>> increment by 1; and TL0PICIDX resets to 0 on every IDR frame, >>> rather than carrying on continuously. (H.264's IDR frames are >>> analogous for these purposes to VP8's essential keyframes). >>> >>> This means that an H.264 SVC splicer -- as long as it doesn't >>> get unlucky, such that the two streams it's splicing happen to >>> have identical IDRPICID values at the splice point -- can just >>> transition from one bitstream to another at any IDR frame. >>> >>> By contrast, following a splice, a VP8 splicer must re-write both >>> these fields for the rest of the lifetime of the stream, since >>> they each have only one valid possible value following the >>> splice. >>> >>> The VP8 payload format's decision is a reasonable design choice >>> -- as compared to the H.264 SVC rules, it removes some ambiguity >>> between splice points and packet loss, giving decoders somewhat >>> greater visibility as to what's going on in the bitstream, and >>> also allows TL0PICIDX and KEYIDX to be orthogonal options because >>> they increment independently. However, I wanted to make sure >>> this had been considered explicitly by the working group, and we >>> had consensus that it was the right decision. >>> >>> (Note well disclaimer: Vidyo has an IPR declaration against the >>> VP8 payload -- see .) >>> >>> >>> On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote: >>> >>>> I have not seen any comments on the list. Please review the >>>> draft and post your comments on the list. >>>> >>>> Thanks. -acbegen >>>> >>>> -----Original Message----- From: "Ali C. Begen" >>>> > Date: Monday, >>>> November 19, 2012 3:15 PM To: "payload@ietf.org >>>> " >>> > Subject: [payload] WGLC for VP8 >>>> Payload >>>> >>>>> Hi everyone, >>>>> >>>>> We had a WGLC for this draft earlier this year and there have >>>>> been a few updates to the document. I am starting a 2nd >>>>> WGLC. Please review and comment on the list by December >>>>> 10th. >>>>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_tex > >>>>> >>>> t=1 >>>>> >>>> https://www.ietf.org/mailman/listinfo/payload >>>> >>> >>> -- Jonathan Lennox jonathan@vidyo.com >>> >>> >>> >>> _______________________________________________ payload mailing >>> list payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload >> > > _______________________________________________ payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > > > > > > > > > > > > > > > _______________________________________________ payload mailing list > payload@ietf.org https://www.ietf.org/mailman/listinfo/payload From abegen@cisco.com Mon Dec 17 11:36:56 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFAE21F88A9 for ; Mon, 17 Dec 2012 11:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.384 X-Spam-Level: X-Spam-Status: No, score=-10.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9k9GO8e85KSB for ; Mon, 17 Dec 2012 11:36:55 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A5F0121F8897 for ; Mon, 17 Dec 2012 11:36:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=434; q=dns/txt; s=iport; t=1355773014; x=1356982614; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=zoTXwum+8PibBUUJOICKiQ+7SObPem3CEr33YIYqsz8=; b=dnTX7oQMmRY/7SdItBMP6GXZoQEEUV3pbfXTSTBrtPGWhoXIoM6SBs8g PqGlWjInv9jdjaakHEudGNcB9b+Bap0ExYHv/XSu7726aofI5IjfIcQyO nY5SKyQH2EMAMYDH5RhwzaxWnj2JyZaLSR523N/We+ZUM7FFyJGReHyux k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAIFzz1CtJV2d/2dsb2JhbABFgmyDCLgyFnOCIAEEOlEBKhRCJwQbiAsBC5hzoSKMXYNiYQOXJo8sgnOCIg X-IronPort-AV: E=Sophos;i="4.84,304,1355097600"; d="scan'208";a="153671031" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 17 Dec 2012 19:36:51 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBHJapIH032528 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 17 Dec 2012 19:36:51 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 13:36:51 -0600 From: "Ali C. Begen (abegen)" To: "payload@ietf.org" Thread-Topic: Adopting draft-spittka-payload-rtp-opus Thread-Index: AQHN3I3cBUPTnvZxb0md0zQnypK00g== Date: Mon, 17 Dec 2012 19:36:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.254.233] Content-Type: text/plain; charset="us-ascii" Content-ID: <08A0D6949B208144B2262B81D77E4B2D@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [payload] Adopting draft-spittka-payload-rtp-opus X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 19:36:56 -0000 Hi everyone, The Opus draft has been pretty completed and the authors would like to see it adopted and published. http://datatracker.ietf.org/doc/draft-spittka-payload-rtp-opus/ We already have a milestone for this as: Dec 2012 Submit RTP Payload Format for Opus Speech and Audio Codec as proposed standard Please speak up if you do not support adopting this draft by Dec. 24th. Thanks, -acbegen (as a co-chair) From pwestin@google.com Wed Dec 19 15:07:09 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F5F21F8932 for ; Wed, 19 Dec 2012 15:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.542 X-Spam-Level: X-Spam-Status: No, score=-101.542 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygBj0RkBLktR for ; Wed, 19 Dec 2012 15:07:08 -0800 (PST) Received: from mail-da0-f41.google.com (mail-da0-f41.google.com [209.85.210.41]) by ietfa.amsl.com (Postfix) with ESMTP id EB04121F88DB for ; Wed, 19 Dec 2012 15:07:07 -0800 (PST) Received: by mail-da0-f41.google.com with SMTP id e20so1165037dak.14 for ; Wed, 19 Dec 2012 15:07:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=2d655MoLDhKz6y1yjoLYuA68A6IGvSPDpTOew56khmQ=; b=M5Ga24BIo1rJfsYEHPxGzNipZ1uZBQ8VS9TkbGI77QtWswVcP3sJsqDPjslKskr5LV PKqWBJPa56F5JkJvjSOK303kM/bXNfFqiP7afYYfPsF+R8xLA6PzlThQo1wpoC1WGR70 9a/IIrksAunY7pNB/XFBYLXl85fKA/Wba5lPdCTLfl9bWxbw/Ty5tOoh3xWys1Uim/CK sBTT/ER2Gbg+aUGUSMIjRmSySbvKW6VurzIIJ76a0zJBXpeeYk3ldGixrVyvLuL/p8hp J92Vlqj6oaBybSlchYL+dMOwxQ35DIMtuM0vzT7V3/gzfaapCRzJtn6ZiUAyF7VxnWIH ecNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=2d655MoLDhKz6y1yjoLYuA68A6IGvSPDpTOew56khmQ=; b=Rg6Uz/MSOJm8GewHIeYoPXkqMRI5zg5FaVvY6JoNdw1mnAIQYMs7p1ChwikYRyuFgS kbZDGXS0yVpu7C/i6nQFi04T9BB8u1pqjGpIsBRrhGMoEgFBmrkCzDIzJRnVPQHrOed3 gJfqx2/JYiywg/HDrK7SZ1ueiXXigNDPMBkisVnDgiQOBKoQkpcxZTlgka89Jjn2u7/u UV9Mk0U95GglZZp+9EBR47q8JBBS/9u1YUmTJ7BAN91IjGYzZivwBbfA9wyr3xPIBuJX NMPfXg/pTOKLeULxcCSTZgw9rbSTRN1klNwtp9qpkCKg7wU4s79HbkIrUhhS7kADKhGg H6Nw== Received: by 10.66.73.230 with SMTP id o6mr21589879pav.57.1355958427499; Wed, 19 Dec 2012 15:07:07 -0800 (PST) MIME-Version: 1.0 Sender: pwestin@google.com Received: by 10.68.135.7 with HTTP; Wed, 19 Dec 2012 15:06:47 -0800 (PST) In-Reply-To: <50CC76F3.7060702@gmail.com> References: <50CC76F3.7060702@gmail.com> From: Patrik Westin Date: Wed, 19 Dec 2012 15:06:47 -0800 X-Google-Sender-Auth: J1VZQdtDw1s923jaiE3ChhpbitM Message-ID: To: Glen Zorn Content-Type: multipart/alternative; boundary=f46d042ef52566bd7b04d13cac5b X-Gm-Message-State: ALoCoQkclxXx/4x6srvClgOkPJmxqpBzSbL+P+cKhQ4vTOfpvtrdP0yY7OF/GQdGeSh0hFTUFY7/HDu96YPxqgemcmdnmOTBDfbCNEY1Q+XDwWXowuFx0cXyOnJ3c6XVSeuSN7PXZ/QRqw71XiYgTZM5M4eKciODCoAIQ2GHRPSpDEfjI1PQXGJWlaSwOMpa4kCx6y1oBzdm Cc: Jonathan Lennox , "draft-ietf-payload-vp8@tools.ietf.org" , "payload@ietf.org" Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: pwestin@webrtc.org List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 23:07:09 -0000 --f46d042ef52566bd7b04d13cac5b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Would you be happy with adding paragraph saying something like this? "People doing splicing of VP8 streams will have to make sure the rules for incrementing TL0PICIDX and KEYIDX are obeyed across the splice. This may require rewriting values of TL0PICIDX and KEYIDX after the splice." On Sat, Dec 15, 2012 at 5:11 AM, Glen Zorn wrote: > On 12/15/2012 06:27 AM, Stephan Wenger wrote: > > Hi, I'm with Ali here. >> > > Me, too. > > > The design choice that has been made in the VP8 payload is different >> > > from the one in the SVC payload, despite similarity in codepoint > > names and functionality. The reasoning for that ought to be > > documented. In the SVC payload format, we didn't need to, because we > > were first in describing something like this :-) A sentence or two > > should suffice, along the lines Jonathan proposed. Stephan > > > > From: "Ali C. Begen (abegen)" > > Date: Friday, 14 December, 2012 15:09 To: > > "pwestin@webrtc.org " > >, Jonathan Lennox > > Cc: > > "draft-ietf-payload-vp8@tools.**ietf.org > > > >" > > > > >>, > "payload@ietf.org > > " > > Subject: Re: [payload] WGLC for VP8 > > > Payload > > > > Personally (chair-hat off), I think we should. It does not harm > > anything but provides clarification to someone who is not deep down > > in every detail. > > > > From: Patrik Westin > > > Reply-To: "pwestin@webrtc.org " > > > Date: Friday, > > > December 14, 2012 6:06 PM To: Jonathan Lennox > > Cc: "Ali C. Begen" > >, "payload@ietf.org > > " > >, "draft-ietf-payload-vp8@tools.**ietf.org > > > >" > > > > >> > Subject: Re: > > > [payload] WGLC for VP8 Payload > > > > Ali do you really want me to add that to the draft? > > > > > > On Fri, Dec 14, 2012 at 2:55 PM, Jonathan Lennox > > wrote: > > > > What I think Ali meant was to add some text describing the > > implications of this design choice for splicers =96 i.e., if these > > features are in use, they must re-write packets indefinitely > > following a splice. > > > > > > > > *From:*pwestin@google.com > > [mailto:pwestin@google.com ] *On Behalf Of > > *Patrik Westin *Sent:* Friday, December 14, 2012 5:47 PM *To:* Ali C. > > Begen (abegen) *Cc:* Jonathan Lennox; payload@ietf.org > > ; draft-ietf-payload-vp8@tools.**ietf.org > > > > > > > > > > *Subject:* Re: [payload] WGLC for VP8 Payload > > > > > > > > > Well he did not have a point in my mind. This is what he wrote. > > > > > > > > "The VP8 payload format's decision is a reasonable design choice -- > > as compared to the H.264 SVC rules, it removes some ambiguity between > > splice points and packet loss, giving decoders somewhat greater > > visibility as to what's going on in the bitstream, and also allows > > TL0PICIDX and KEYIDX to be orthogonal options because they increment > > independently." > > > > > > > > The worst thing that can happen in a draft is to leave ambiguity, > > which we don't have in the current draft. However if we do it the way > > H.264 SVC do we could introduce such ambiguity > > > > > > > > On Fri, Dec 14, 2012 at 2:30 PM, Ali C. Begen (abegen) > > > wrote: > > > > Are you at least planning to put some text around the point Jonathan > > brought up? > > > > > > > > *From: *Patrik Westin > > *Reply-To: *"pwestin@webrtc.org > > " > > *Date: *Friday, December 14, 2012 4:53 > > PM > > > > > > *To: *"Ali C. Begen" > > > > > *Cc: *Jonathan Lennox > >, "payload@ietf.org > > " > >, "draft-ietf-payload-vp8@tools.**ietf.org > > > >" > > > > > >> > > > > > > *Subject: *Re: [payload] WGLC for VP8 Payload > > > > > > > > > Trying to send this again since my previous message did not reach the > > list. > > > > Thanks for pointing out the inconsistency. We've submitted a new > > draft that fixes that problem. > > > > > > The second issue was intentional. We'll keep it this way. > > > > > > > > On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abegen) > > > wrote: > > > > Thanks, the authors just rev'ed the draft to fix the first issue. I > > hope they will address the second issue first in the list and then > > reflect the agreement in the next revision. I will hold on to the doc > > write-up till then. > > > > > > -acbegen > > > > -----Original Message----- From: Jonathan Lennox > > > > > > > Date: Thursday, December 13, 2012 11:29 AM To: "Ali C. Begen" > > >, "payload@ietf.org > > " > > Cc: "draft-ietf-payload-vp8@tools.**ietf.org= > > > >" > > > > > >> > > > > > Subject: RE: [payload] WGLC for VP8 Payload > > > >> Hi, Ali -- > >> > >> I just wanted to make sure the issue had been considered; if the > >> WG agrees that the current design is okay given the limitations > >> I've mentioned, I'm not going to object. > >> > >> Discussion of the issue might be helpful in the document. > >> > >> -----Original Message----- From: Ali C. Begen (abegen) > >> [mailto:abegen@cisco.com ] Sent: Tuesday, > > >> December 11, 2012 7:13 PM To: Jonathan Lennox; payload@ietf.org > >> Cc: draft-ietf-payload-vp8@tools.**ietf.org<= draft-ietf-payload-vp8@tools.ietf.org> > >> > > Subject: Re: > > >> [payload] WGLC for VP8 Payload > >> > >> The first one should be fixed by the authors thru a quick revision. > >> As for the second one, I will ask the authors reply. Also if there > >> are others who strongly think one way or another, lets discuss it. > >> > >> Jonathan, are you ok if the authors simply acknowledge this in the > >> draft (assuming they agree with you) or do you actually not like > >> this at all? > >> > >> -acbegen > >> > >> -----Original Message----- From: Jonathan Lennox > >> > Date: Tuesday, > > >> December 11, 2012 11:49 AM To: "payload@ietf.org > >> " >> > Subject: Re: [payload] WGLC for VP8 > > >> Payload > >> > >>> Hi -- I have two comments on this draft. Sorry for being late. > >>> > >>> First of all, an editorial matter: Section 6 says the format has > >>> no parameters, but section 6.1 lists two optional parameters > >>> (max-fr and max-fs). > >>> > >>> > >>> Secondly, more substantively, I note that the payload format's > >>> rules on KEYIDX and TL0PICIDX impose a fair bit of overhead on > >>> boxes that wish to splice together VP8 streams, since both values > >>> are required to always increment consecutively in a bitstream (if > >>> they're being used). > >>> > >>> By contrast, the equivalent fields of the H.264 SVC payload > >>> format (in the PACSI) just say that IDRPICID must be different in > >>> consecutive IDR frames, without requiring that the value > >>> increment by 1; and TL0PICIDX resets to 0 on every IDR frame, > >>> rather than carrying on continuously. (H.264's IDR frames are > >>> analogous for these purposes to VP8's essential keyframes). > >>> > >>> This means that an H.264 SVC splicer -- as long as it doesn't > >>> get unlucky, such that the two streams it's splicing happen to > >>> have identical IDRPICID values at the splice point -- can just > >>> transition from one bitstream to another at any IDR frame. > >>> > >>> By contrast, following a splice, a VP8 splicer must re-write both > >>> these fields for the rest of the lifetime of the stream, since > >>> they each have only one valid possible value following the > >>> splice. > >>> > >>> The VP8 payload format's decision is a reasonable design choice > >>> -- as compared to the H.264 SVC rules, it removes some ambiguity > >>> between splice points and packet loss, giving decoders somewhat > >>> greater visibility as to what's going on in the bitstream, and > >>> also allows TL0PICIDX and KEYIDX to be orthogonal options because > >>> they increment independently. However, I wanted to make sure > >>> this had been considered explicitly by the working group, and we > >>> had consensus that it was the right decision. > >>> > >>> (Note well disclaimer: Vidyo has an IPR declaration against the > >>> VP8 payload -- see > >.) > >>> > >>> > >>> On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote: > >>> > >>>> I have not seen any comments on the list. Please review the > >>>> draft and post your comments on the list. > >>>> > >>>> Thanks. -acbegen > >>>> > >>>> -----Original Message----- From: "Ali C. Begen" > >>>> > Date: Monday, > > >>>> November 19, 2012 3:15 PM To: "payload@ietf.org > >>>> " >>>> > Subject: [payload] WGLC for VP8 > > >>>> Payload > >>>> > >>>>> Hi everyone, > >>>>> > >>>>> We had a WGLC for this draft earlier this year and there have > >>>>> been a few updates to the document. I am starting a 2nd > >>>>> WGLC. Please review and comment on the list by December > >>>>> 10th. > >>>>> > >>>>> https://datatracker.ietf.org/**doc/draft-ietf-payload-vp8/?** > include_tex > > > >>>>> > >>>> t=3D1 > >>>>> > >>>> https://www.ietf.org/mailman/**listinfo/payload > >>>> > >>> > >>> -- Jonathan Lennox jonathan@vidyo.com > >>> > >>> > >>> > >>> ______________________________**_________________ payload mailing > >>> list payload@ietf.org > > >>> https://www.ietf.org/mailman/**listinfo/payload > >> > > > > ______________________________**_________________ payload mailing list > > payload@ietf.org > > > https://www.ietf.org/mailman/**listinfo/payload > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ______________________________**_________________ payload mailing list > > payload@ietf.org https://www.ietf.org/mailman/**listinfo/payload > > --f46d042ef52566bd7b04d13cac5b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Would you be happy with addin= g=A0paragraph s= aying something like this?

"People doing= splicing=A0of VP8 streams will have to make sure the rules for incrementing=A0TL0PICIDX an= d KEYIDX are obeyed across the splice. This may require=A0rewriting values of TL0PI= CIDX and KEYIDX after the splice."


<= br>
On Sat, Dec 15, 2012 at 5:11 AM, Glen Zorn <glenzorn@gmail.com> wrote:
On 12/15/2012 06:27 AM, St= ephan Wenger wrote:

Hi, I'm with Ali here.

Me, too.


The design choice that has been =A0made in the VP8 payload is different
> from the one in the SVC payload, despite similarity in codepoint
> names and functionality. The reasoning for that ought to be
> documented. In the SVC payload format, we didn't need to, because = we
> were first in describing something like this :-) A sentence or two
> should suffice, along the lines Jonathan proposed. Stephan
>
> From: "Ali C. Begen (abegen)" <abegen@cisco.com
> <mailto:abege= n@cisco.com>> Date: Friday, 14 December, 2012 15:09 To:
> "pwestin@= webrtc.org <mailto:pwestin@webrtc.org>" <pwestin@webrtc.org
> <mailto:pwe= stin@webrtc.org>>, Jonathan Lennox <jonathan@vidyo.com
> <mailto:jon= athan@vidyo.com>> Cc:
> "draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>"<= br> > <draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>>, &= quot;payload@ietf.org=
> <mailto:paylo= ad@ietf.org>" <payload@ietf.org
> <mailto:paylo= ad@ietf.org>> Subject: Re: [payload] WGLC for VP8

> Payload
>
> Personally (chair-hat off), I think we should. It does not harm
> anything but provides clarification to someone who is not deep down > in every detail.
>
> From: Patrik Westin <pwestin@webrtc.org <mailto:pwestin@webrtc.org>>
> Reply-To: "pwestin@webrtc.org <mailto:pwestin@webrtc.org>"
> <pwestin@we= brtc.org <mailto:pwestin@webrtc.org>> Date: Friday,

> December 14, 2012 6:06 PM To: Jonathan Lennox <jonathan@vidyo.com
> <mailto:jon= athan@vidyo.com>> Cc: "Ali C. Begen" <abegen@cisco.com
> <mailto:abege= n@cisco.com>>, "payload@ietf.org
> <mailto:paylo= ad@ietf.org>" <payload@ietf.org
> <mailto:paylo= ad@ietf.org>>, "draft-ietf-payload-vp8@tools.ietf.org=
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>"<= br> > <draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>> Su= bject: Re:

> [payload] WGLC for VP8 Payload
>
> Ali do you really want me to add that to the draft?
>
>
> On Fri, Dec 14, 2012 at 2:55 PM, Jonathan Lennox <jonathan@vidyo.com
> <mailto:jon= athan@vidyo.com>> wrote:
>
> What I think Ali meant was to add some text describing the
> implications of this design choice for splicers =96 i.e., if these
> features are in use, they must re-write packets indefinitely
> following a splice.
>
>
>
> *From:*pwestin= @google.com <mailto:pwestin@google.com>
> [mailto:pwesti= n@google.com <mailto:pwestin@google.com>] *On Behalf Of
> *Patrik Westin *Sent:* Friday, December 14, 2012 5:47 PM *To:* Ali C.<= br> > Begen (abegen) *Cc:* Jonathan Lennox; payload@ietf.org
> <mailto:paylo= ad@ietf.org>; draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>
>
>
> *Subject:* Re: [payload] WGLC for VP8 Payload

>
>
>
> Well he did not have a point in my mind. This is what he wrote.
>
>
>
> "The VP8 payload format's decision is a reasonable design cho= ice --
> as compared to the H.264 SVC rules, it removes some ambiguity between<= br> > splice points and packet loss, giving decoders somewhat greater
> visibility as to what's going on in the bitstream, and also allows=
> TL0PICIDX and KEYIDX to be orthogonal options because they increment > independently."
>
>
>
> The worst thing that can happen in a draft is to leave ambiguity,
> which we don't have in the current draft. However if we do it the = way
> H.264 SVC do we could introduce such ambiguity
>
>
>
> On Fri, Dec 14, 2012 at 2:30 PM, Ali C. Begen (abegen)
> <abegen@cisco= .com <mailto:a= begen@cisco.com>> wrote:
>
> Are you at least planning to put some text around the point Jonathan > brought up?
>
>
>
> *From: *Patrik Westin <pwestin@webrtc.org
> <mailto:pwe= stin@webrtc.org>> *Reply-To: *"pwestin@webrtc.org
> <mailto:pwe= stin@webrtc.org>" <pwestin@webrtc.org
> <mailto:pwe= stin@webrtc.org>> *Date: *Friday, December 14, 2012 4:53
> PM
>
>
> *To: *"Ali C. Begen" <abegen@cisco.com <mailto:abegen@cisco.com>>
>
> *Cc: *Jonathan Lennox <jonathan@vidyo.com
> <mailto:jon= athan@vidyo.com>>, "payload@ietf.org
> <mailto:paylo= ad@ietf.org>" <payload@ietf.org
> <mailto:paylo= ad@ietf.org>>, "draft-ietf-payload-vp8@tools.ietf.org=
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>"<= br> > <draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>> >
>
> *Subject: *Re: [payload] WGLC for VP8 Payload

>
>
>
> Trying to send this again since my previous message did not reach the<= br> > list.
>
> Thanks for pointing out the inconsistency. We've submitted a new > draft that fixes that problem.
>
>
> The second issue was intentional. We'll keep it this way.
>
>
>
> On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abegen)
> <abegen@cisco= .com <mailto:a= begen@cisco.com>> wrote:
>
> Thanks, the authors just rev'ed the draft to fix the first issue. = I
> hope they will address the second issue first in the list and then
> reflect the agreement in the next revision. I will hold on to the doc<= br> > write-up till then.
>
>
> -acbegen
>
> -----Original Message----- From: Jonathan Lennox <jonathan@vidyo.com
> <mailto:jon= athan@vidyo.com>>

>
> Date: Thursday, December 13, 2012 11:29 AM To: "Ali C. Begen"= ;
> <abegen@cisco= .com <mailto:a= begen@cisco.com>>, "payload@ietf.org
> <mailto:paylo= ad@ietf.org>" <payload@ietf.org
> <mailto:paylo= ad@ietf.org>> Cc: "draft-ietf-payload-vp8@tools.ietf.= org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>"<= br> > <draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>>
>
> Subject: RE: [payload] WGLC for VP8 Payload
>
>> Hi, Ali --
>>
>> I just wanted to make sure the issue had been considered; if the >> WG agrees that the current design is okay given the limitations >> I've mentioned, I'm not going to object.
>>
>> Discussion of the issue might be helpful in the document.
>>
>> -----Original Message----- From: Ali C. Begen (abegen)
>> [mailto:abeg= en@cisco.com <mailto:abegen@cisco.com>] Sent: Tuesday,

>> December 11, 2012 7:13 PM To: Jonathan Lennox; payload@ietf.org
>> <mailto:p= ayload@ietf.org> Cc: draft-ietf-payload-vp8@tools.ietf.org
>> <mailto:draft-ietf-payload-vp8@tools.ietf.org> Su= bject: Re:

>> [payload] WGLC for VP8 Payload
>>
>> The first one should be fixed by the authors thru a quick revision= .
>> As for the second one, I will ask the authors reply. Also if there=
>> are others who strongly think one way or another, lets discuss it.=
>>
>> Jonathan, are you ok if the authors simply acknowledge this in the=
>> draft (assuming they agree with you) or do you actually not like >> this at all?
>>
>> -acbegen
>>
>> -----Original Message----- From: Jonathan Lennox
>> <jonath= an@vidyo.com <mailto:jonathan@vidyo.com>> Date: Tuesday,
>> December 11, 2012 11:49 AM To: "payload@ietf.org
>> <mailto:p= ayload@ietf.org>" <payload@ietf.org
>> <mailto:p= ayload@ietf.org>> Subject: Re: [payload] WGLC for VP8

>> Payload
>>
>>> Hi -- I have two comments on this draft. Sorry for being late.=
>>>
>>> First of all, an editorial matter: Section 6 says the format h= as
>>> no parameters, but section 6.1 lists two optional parameters >>> (max-fr and max-fs).
>>>
>>>
>>> Secondly, more substantively, I note that the payload format&#= 39;s
>>> rules on KEYIDX and TL0PICIDX impose a fair bit of overhead on=
>>> boxes that wish to splice together VP8 streams, since both val= ues
>>> are required to always increment consecutively in a bitstream = (if
>>> they're being used).
>>>
>>> By contrast, the equivalent fields of the H.264 SVC payload >>> format (in the PACSI) just say that IDRPICID must be different= in
>>> consecutive IDR frames, without requiring that the value
>>> increment by 1; and TL0PICIDX resets to 0 on every IDR frame,<= br> >>> rather than carrying on continuously. (H.264's IDR frames = are
>>> analogous for these purposes to VP8's essential keyframes)= .
>>>
>>> This means that an H.264 SVC splicer -- as long as it doesn= 9;t
>>> get unlucky, such that the two streams it's splicing happe= n to
>>> have identical IDRPICID values at the splice point -- can just=
>>> transition from one bitstream to another at any IDR frame.
>>>
>>> By contrast, following a splice, a VP8 splicer must re-write b= oth
>>> these fields for the rest of the lifetime of the stream, since=
>>> they each have only one valid possible value following the
>>> splice.
>>>
>>> The VP8 payload format's decision is a reasonable design c= hoice
>>> -- as compared to the H.264 SVC rules, it removes some ambigui= ty
>>> between splice points and packet loss, giving decoders somewha= t
>>> greater visibility as to what's going on in the bitstream,= and
>>> also allows TL0PICIDX and KEYIDX to be orthogonal options beca= use
>>> they increment independently. However, I wanted to make sure >>> this had been considered explicitly by the working group, and = we
>>> had consensus that it was the right decision.
>>>
>>> (Note well disclaimer: Vidyo has an IPR declaration against th= e
>>> VP8 payload -- see <http://tracker.tools.ietf.org/ipr/162= 2/>.)
>>>
>>>
>>> On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote:
>>>
>>>> I have not seen any comments on the list. Please review th= e
>>>> draft and post your comments on the list.
>>>>
>>>> Thanks. -acbegen
>>>>
>>>> -----Original Message----- From: "Ali C. Begen"<= br>
>>>> <= abegen@cisco.com <mailto:abegen@cisco.com>> Date: Monday,
>>>> November 19, 2012 3:15 PM To: "payload@ietf.org
>>>> <mailto:payload@ietf.org>" <payload@ietf.org
>>>> <mailto:payload@ietf.org>> Subject: [payload] WGLC for VP8

>>>> Payload
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> We had a WGLC for this draft earlier this year and the= re have
>>>>> been a few updates to the document. I am starting a 2n= d
>>>>> WGLC. Please review and comment on the list by Decembe= r
>>>>> 10th.
>>>>>
>>>>> https://datatracker.ietf.org/<= u>doc/draft-ietf-payload-vp8/?include_tex
>
>>>>>
>>>> t=3D1
>>>>>
>>>> https://www.ietf.org/mailman/listinfo/payload<= br> >>>>
>>>
>>> -- Jonathan Lennox jonathan@vidyo.com
>>> <mailto:jonathan@vidyo.com>
>>>
>>>
>>> _______________________________________________ payload= mailing
>>> list pay= load@ietf.org <mailto:payload@ietf.org>

>>> https://www.ietf.org/mailman/listinfo/payload
>>
>
> _______________________________________________ payload mailing= list
> payload@ietf.org= <mailto:paylo= ad@ietf.org>

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


--f46d042ef52566bd7b04d13cac5b-- From ron.even.tlv@gmail.com Wed Dec 26 04:45:03 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1690721F843E for ; Wed, 26 Dec 2012 04:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m11NOVSNl3jz for ; Wed, 26 Dec 2012 04:45:00 -0800 (PST) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id 15C0921F84FC for ; Wed, 26 Dec 2012 04:44:59 -0800 (PST) Received: by mail-ee0-f43.google.com with SMTP id e49so4314668eek.2 for ; Wed, 26 Dec 2012 04:44:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=JVLQkg3D8SZHMzYlx5/zVAskaN4JgGGbmgTSNcrdJJY=; b=ppJ1DJeFieejhl7o7CJ3f04xtTG9pzV6mUAA6/Hdz7J8JYG2b6vQtjnq4cd2lp0xmi t433AtjukCPdGeh3si1BGFH30cq10a6V6LdiqBgfbofdEAAHjhwkuWH/+ePq0P5ioMOI wzTYYyAcwJu5KT4RxSrV33k9EYl78v8F3qD+F2a8NAr/T5i31lKJfYc5fPYUqL9vJr+y 7FswbHVKRGm0BmjhyUNlXI3SvFmbDcbNeRdKnieXOWL0o6dCLNWY3DcNHVV//TY4JxTo Ge1tAJn7Edl30NfKI9LhQb6tvsRmzWSr7qq3txfVYDL2F/+L9C4wK/j2bYfTGeL3w7Y9 h3BQ== X-Received: by 10.14.207.195 with SMTP id n43mr68907473eeo.38.1356525899105; Wed, 26 Dec 2012 04:44:59 -0800 (PST) Received: from RoniE (bzq-79-176-219-120.red.bezeqint.net. [79.176.219.120]) by mx.google.com with ESMTPS id 43sm53020908eed.10.2012.12.26.04.44.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Dec 2012 04:44:57 -0800 (PST) From: "Roni Even" To: References: In-Reply-To: Date: Wed, 26 Dec 2012 14:42:05 +0200 Message-ID: <01dd01cde366$6be0b3f0$43a21bd0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01DE_01CDE377.2F6B7FC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3Y++h0UQghJ/PcRKOitadPT1ArYwKZcbWg Content-Language: en-us Cc: draft-ietf-avt-rtp-isac@tools.ietf.org Subject: Re: [payload] WGLC on draft-ietf-avt-rtp-isac-02 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2012 12:45:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01DE_01CDE377.2F6B7FC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I reviewed the draft and have some questions and comments 1. In section 2 there is a mention of target bit rate. It is not clear how is it calculated and what does average during peaks mean? How is this parameter related to the ibitrate parameter defined in the IANA section. 2. In section 2 "The available bandwidth is continuously estimated at the receiving iSAC and signaled in-band in the iSAC bit stream". How does it work? 3. In section 3 second paragraph please discuss using dynamic payload type number maybe add "The assignment of an RTP payload type for the format defined in this memo is outside the scope of this document. The RTP profiles in use currently mandate binding the payload type dynamically for this payload format." 4. In section 3.2 what are the BEI and FL values and how many bits each one uses. 5. In section 3.3 what is bandwidth probe, how does it work. Is it specified elsewhere, in which case provide a reference. 6. In section 3.3 "The user can choose to lower the maximum allowed payload length ". Who is the user(sender / receiver) and how is it done. 7. In section 3.4 how does a receiver know if he receives a wideband or super-wideband payload in order to decode correctly. 8. In section 3.5 "signaled inband". What is inband, any reference? 9. Looking at figure 6 I am not clear from the text how does the receiver know that there is padding and not payload? 10. In section 4 change the beginning to "This RTP payload format is identified using the media type audio/isac, which is registered in accordance with [RFC4855 ] and uses the template of [RFC4288 ]." 11. Please verify that the registration follows the template. Currently the order is not correct and there are missing subscetions. 12. Since ibitrate and maxbitrate are optional parameters what are the default values if not specified. I saw 20000 for ibitrate for channel adaptive mode in section 2. 13. What are the units for ibitrate and maxbitrate 14. In section 4 the change controller should be the payload working group. 15. In section 5 what is the clock rate in rtpmap. 16. Can you switch from wideband to super wideband without any signaling using the same payload type number. Can you use a 32000 clock rate also for the wideband. 17. The document should have a congestion control section see http://tools.ietf.org/html/draft-ietf-payload-rtp-howto-02 18. The security section need to be expanded see for example section 10 of RFC 5404. Thanks Roni Even From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 13 December, 2012 8:35 AM To: 'payload@ietf.org' Cc: 'draft-ietf-avt-rtp-isac@tools.ietf.org' Subject: WGLC on draft-ietf-avt-rtp-isac-02 Hi, I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avt-rtp-isac-02 , RTP Payload Format for the iSAC Codec The WGLC will end on January 2nd, 2013 Please review the draft and send comments to the list. For the draft authors; Are you aware of any IPR that applies to draft-ietf-avt-rtp-isac-02? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? The above question is needed for the document write-up when sent to publication. Thanks Roni Even Payload co-chair _____ ------=_NextPart_000_01DE_01CDE377.2F6B7FC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I reviewed the draft and = have some questions and comments

 

1.       = In section 2 there is a mention of target bit = rate. It is not clear how is it calculated and what does average during = peaks mean? How is this parameter related to the ibitrate parameter = defined in the IANA section.

2.       = In section 2 “The  available = bandwidth is continuously estimated at the receiving iSAC and signaled = in-band in the iSAC bit stream”. How does it = work?

3.       = In section 3 second paragraph please discuss = using dynamic payload type number maybe add “The assignment of an RTP payload type for the format defined = in this  memo is outside the scope of this document.  The RTP = profiles in use  currently mandate binding the payload type = dynamically for this  payload = format.”

4.       = In section 3.2  what are the BEI and FL = values  and how many bits each one uses.

5.       = In section 3.3 what is bandwidth probe, how does = it work. Is it specified elsewhere, in which case provide a = reference.

6.       = In section 3.3 “The = user can choose to lower the maximum allowed payload length “. Who = is the user(sender / receiver) and how is it done.

7.       = In section 3.4 how does a = receiver know if he receives a wideband or super-wideband payload in = order to decode correctly.

8.       = In section 3.5 = “signaled inband”. What is inband, any = reference?

9.       = Looking at figure 6 I am = not clear from the text how does the receiver know that there is padding = and not payload?

10.  = In section 4 = change the beginning to “This RTP payload format is identified using = the media type audio/isac, which is registered in accordance with [RFC4855] and uses = the  template of [RFC4288].”

11.  = Please verify that the registration follows = the template. Currently the order is not correct and there are missing = subscetions.

12.  = Since ibitrate and maxbitrate are optional = parameters what are the default values if not specified. I saw 20000 for = ibitrate for channel adaptive mode in section 2. =

13.  = What are the units for ibitrate and = maxbitrate

14.  =  In section 4 the change controller = should be the payload working group.

15.  = In section 5 what is the clock rate in = rtpmap.

16.  = Can you switch from wideband to super = wideband without any signaling using the same payload type number. Can = you use a 32000 clock rate also for the = wideband.

17.   = The document should have a congestion control = section see http:= //tools.ietf.org/html/draft-ietf-payload-rtp-howto-02

<= p class=3DMsoListParagraph = style=3D'text-indent:-.25in;page-break-before:always;mso-list:l0 level1 = lfo1'>18.   = The security section need = to be expanded see for example section 10 of RFC 5404.

Thanks

Roni = Even

 

 

From:= = Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: 13 December, = 2012 8:35 AM
To: 'payload@ietf.org'
Cc: = 'draft-ietf-avt-rtp-isac@tools.ietf.org'
Subject: WGLC on = draft-ietf-avt-rtp-isac-02

 

Hi,

I would =
like to start a WGLC on  http://too=
ls.ietf.org/html/draft-ietf-avt-rtp-isac-02 , RTP =
Payload Format for the iSAC Codec
 =

 =

The WGLC will = end on January 2nd, 2013

 

Please = review the draft and send comments to the list.

 

For the = draft authors;  Are you aware of any IPR that applies to = draft-ietf-avt-rtp-isac-02? If so,

has this =
IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, =
4879, 3669 and 5378 for more details)?
The above =
question is needed for the document write-up when sent to =
publication.
 =

Thanks

 

Roni = Even

Payload =  co-chair

 

 

 

------=_NextPart_000_01DE_01CDE377.2F6B7FC0-- From abegen@cisco.com Sat Dec 29 12:02:20 2012 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B450D21F8790 for ; Sat, 29 Dec 2012 12:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.277 X-Spam-Level: X-Spam-Status: No, score=-9.277 tagged_above=-999 required=5 tests=[AWL=-0.946, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_HI=-8, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcOOi5BefSGm for ; Sat, 29 Dec 2012 12:02:07 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7120821F8778 for ; Sat, 29 Dec 2012 12:02:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44594; q=dns/txt; s=iport; t=1356811326; x=1358020926; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=xjMq0zDM+uE4t90D41WY5yhA1QLDt8t3rz/m1tibfDw=; b=iDVLTg1jC6OtM9B4u+HwG+o4ssMmlnNeDXBCCMCXOvkCW8jwgogO4ZDY 48k1VKa1ELDXC2KGvKvygfifaJsMtVVa7Ok+ttC5MnRRhlXCbSPwW3Syl 68sZCbiZOjG+4LB2J2dzpzGAKLJ17lrtJKcmG4qRbFlujnDs4efol4R7u U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYFAFBL31CtJV2a/2dsb2JhbABFgkkjsWKGVYJBFnOCHgEBAQMBAQEBF1QLBQcGAQgRAwEBAQEKFgEGKAYLFAkIAgQBDQUIh3kDCQYBC644DYhAi21qg2JhA5Q2gnKKG4URgS+BRYIm X-IronPort-AV: E=Sophos;i="4.84,378,1355097600"; d="scan'208,217";a="157372959" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 29 Dec 2012 20:02:05 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBTK25kA030947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 29 Dec 2012 20:02:05 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Sat, 29 Dec 2012 14:02:05 -0600 From: "Ali C. Begen (abegen)" To: "pwestin@webrtc.org" , Glen Zorn Thread-Topic: [payload] WGLC for VP8 Payload Thread-Index: AQHNxpKRijb9Uyx1rkaO+XOA7twBQpgLNEKAgAkiCoCAAChLAIACfvJggAArcICAAjlHAP//to2AgABYcICAAAJqgIAAAxOA//+s+gCAAFjNAIAA5kGAgAbvuICADy/ogA== Date: Sat, 29 Dec 2012 20:02:04 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.86.245.254] Content-Type: multipart/alternative; boundary="_000_C15918F2FCDA0243A7C919DA7C4BE9940CDE15B3xmbalnx01ciscoc_" MIME-Version: 1.0 Cc: Jonathan Lennox , "draft-ietf-payload-vp8@tools.ietf.org" , "payload@ietf.org" Subject: Re: [payload] WGLC for VP8 Payload X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 20:02:20 -0000 --_000_C15918F2FCDA0243A7C919DA7C4BE9940CDE15B3xmbalnx01ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Patrik Westin > Reply-To: "pwestin@webrtc.org" > Date: Wednesday, December 19, 2012 6:06 PM To: Glen Zorn > Cc: Stephan Wenger >, "Ali C. Begen= " >, Jonathan Lennox >, "payload@ietf.org" >, "draft-ietf-payload-vp8@= tools.ietf.org" > Subject: Re: [payload] WGLC for VP8 Payload Would you be happy with adding paragraph saying something like this? "People doing splicing of VP8 streams will have to make sure the rules for = incrementing TL0PICIDX and KEYIDX are obeyed across the splice. This may re= quire rewriting values of TL0PICIDX and KEYIDX after the splice." Slight rewording: Implementations doing splicing of VP8 streams will have to make sure the ru= les for incrementing TL0PICIDX and KEYIDX are obeyed across the splice. Thi= s will likely require rewriting values of TL0PICIDX and KEYIDX after the sp= lice. BTW, just out of curiosity, as vp9 is surfacing soon, is there any implicat= ion on this draft? -acbegen On Sat, Dec 15, 2012 at 5:11 AM, Glen Zorn > wrote: On 12/15/2012 06:27 AM, Stephan Wenger wrote: Hi, I'm with Ali here. Me, too. The design choice that has been made in the VP8 payload is different > from the one in the SVC payload, despite similarity in codepoint > names and functionality. The reasoning for that ought to be > documented. In the SVC payload format, we didn't need to, because we > were first in describing something like this :-) A sentence or two > should suffice, along the lines Jonathan proposed. Stephan > > From: "Ali C. Begen (abegen)" > >> Date: Friday, 14 Dece= mber, 2012 15:09 To: > "pwestin@webrtc.org >" > >>, Jonathan Lennox = > >> Cc: > "draft-ietf-payload-vp8@tools.ietf.org > >" > > >>, "payload@ietf.org > >" > >> Subject: Re: [payload= ] WGLC for VP8 > Payload > > Personally (chair-hat off), I think we should. It does not harm > anything but provides clarification to someone who is not deep down > in every detail. > > From: Patrik Westin >> > Reply-To: "pwestin@webrtc.org >" > >> Date: Friday, > December 14, 2012 6:06 PM To: Jonathan Lennox > >> Cc: "Ali C. Begen= " > >>, "payload@ietf.org > >" > >>, "draft-ietf-payload-= vp8@tools.ietf.org > >" > > >> Subject: Re: > [payload] WGLC for VP8 Payload > > Ali do you really want me to add that to the draft? > > > On Fri, Dec 14, 2012 at 2:55 PM, Jonathan Lennox > >> wrote: > > What I think Ali meant was to add some text describing the > implications of this design choice for splicers =96 i.e., if these > features are in use, they must re-write packets indefinitely > following a splice. > > > > *From:*pwestin@google.com > > [mailto:pwestin@google.com >] *On Behalf Of > *Patrik Westin *Sent:* Friday, December 14, 2012 5:47 PM *To:* Ali C. > Begen (abegen) *Cc:* Jonathan Lennox; payload@ietf.org > >; draft-ietf-payload-vp= 8@tools.ietf.org > > > > > *Subject:* Re: [payload] WGLC for VP8 Payload > > > > Well he did not have a point in my mind. This is what he wrote. > > > > "The VP8 payload format's decision is a reasonable design choice -- > as compared to the H.264 SVC rules, it removes some ambiguity between > splice points and packet loss, giving decoders somewhat greater > visibility as to what's going on in the bitstream, and also allows > TL0PICIDX and KEYIDX to be orthogonal options because they increment > independently." > > > > The worst thing that can happen in a draft is to leave ambiguity, > which we don't have in the current draft. However if we do it the way > H.264 SVC do we could introduce such ambiguity > > > > On Fri, Dec 14, 2012 at 2:30 PM, Ali C. Begen (abegen) > >> wrote: > > Are you at least planning to put some text around the point Jonathan > brought up? > > > > *From: *Patrik Westin > >> *Reply-To: *"pwes= tin@webrtc.org > >" > >> *Date: *Friday, D= ecember 14, 2012 4:53 > PM > > > *To: *"Ali C. Begen" >> > > *Cc: *Jonathan Lennox > >>, "payload@ietf.or= g > >" > >>, "draft-ietf-payload-= vp8@tools.ietf.org > >" > > >> > > > *Subject: *Re: [payload] WGLC for VP8 Payload > > > > Trying to send this again since my previous message did not reach the > list. > > Thanks for pointing out the inconsistency. We've submitted a new > draft that fixes that problem. > > > The second issue was intentional. We'll keep it this way. > > > > On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abegen) > >> wrote: > > Thanks, the authors just rev'ed the draft to fix the first issue. I > hope they will address the second issue first in the list and then > reflect the agreement in the next revision. I will hold on to the doc > write-up till then. > > > -acbegen > > -----Original Message----- From: Jonathan Lennox > >> > > Date: Thursday, December 13, 2012 11:29 AM To: "Ali C. Begen" > >>, "payload@ietf.org > >" > >> Cc: "draft-ietf-paylo= ad-vp8@tools.ietf.org > >" > > >> > > Subject: RE: [payload] WGLC for VP8 Payload > >> Hi, Ali -- >> >> I just wanted to make sure the issue had been considered; if the >> WG agrees that the current design is okay given the limitations >> I've mentioned, I'm not going to object. >> >> Discussion of the issue might be helpful in the document. >> >> -----Original Message----- From: Ali C. Begen (abegen) >> [mailto:abegen@cisco.com >] Sent: Tuesday, >> December 11, 2012 7:13 PM To: Jonathan Lennox; payload@ietf.org >> > Cc: draft-ietf-payloa= d-vp8@tools.ietf.org >> > Subject: Re: >> [payload] WGLC for VP8 Payload >> >> The first one should be fixed by the authors thru a quick revision. >> As for the second one, I will ask the authors reply. Also if there >> are others who strongly think one way or another, lets discuss it. >> >> Jonathan, are you ok if the authors simply acknowledge this in the >> draft (assuming they agree with you) or do you actually not like >> this at all? >> >> -acbegen >> >> -----Original Message----- From: Jonathan Lennox >> >> Date: Tuesday, >> December 11, 2012 11:49 AM To: "payload@ietf.org >> >" >> >> Subject: Re: [payloa= d] WGLC for VP8 >> Payload >> >>> Hi -- I have two comments on this draft. Sorry for being late. >>> >>> First of all, an editorial matter: Section 6 says the format has >>> no parameters, but section 6.1 lists two optional parameters >>> (max-fr and max-fs). >>> >>> >>> Secondly, more substantively, I note that the payload format's >>> rules on KEYIDX and TL0PICIDX impose a fair bit of overhead on >>> boxes that wish to splice together VP8 streams, since both values >>> are required to always increment consecutively in a bitstream (if >>> they're being used). >>> >>> By contrast, the equivalent fields of the H.264 SVC payload >>> format (in the PACSI) just say that IDRPICID must be different in >>> consecutive IDR frames, without requiring that the value >>> increment by 1; and TL0PICIDX resets to 0 on every IDR frame, >>> rather than carrying on continuously. (H.264's IDR frames are >>> analogous for these purposes to VP8's essential keyframes). >>> >>> This means that an H.264 SVC splicer -- as long as it doesn't >>> get unlucky, such that the two streams it's splicing happen to >>> have identical IDRPICID values at the splice point -- can just >>> transition from one bitstream to another at any IDR frame. >>> >>> By contrast, following a splice, a VP8 splicer must re-write both >>> these fields for the rest of the lifetime of the stream, since >>> they each have only one valid possible value following the >>> splice. >>> >>> The VP8 payload format's decision is a reasonable design choice >>> -- as compared to the H.264 SVC rules, it removes some ambiguity >>> between splice points and packet loss, giving decoders somewhat >>> greater visibility as to what's going on in the bitstream, and >>> also allows TL0PICIDX and KEYIDX to be orthogonal options because >>> they increment independently. However, I wanted to make sure >>> this had been considered explicitly by the working group, and we >>> had consensus that it was the right decision. >>> >>> (Note well disclaimer: Vidyo has an IPR declaration against the >>> VP8 payload -- see .) >>> >>> >>> On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote: >>> >>>> I have not seen any comments on the list. Please review the >>>> draft and post your comments on the list. >>>> >>>> Thanks. -acbegen >>>> >>>> -----Original Message----- From: "Ali C. Begen" >>>> >> Date: Monday, >>>> November 19, 2012 3:15 PM To: "payload@ietf.org >>>> >" >>>> >> Subject: [payload]= WGLC for VP8 >>>> Payload >>>> >>>>> Hi everyone, >>>>> >>>>> We had a WGLC for this draft earlier this year and there have >>>>> been a few updates to the document. I am starting a 2nd >>>>> WGLC. Please review and comment on the list by December >>>>> 10th. >>>>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?include_tex > >>>>> >>>> t=3D1 >>>>> >>>> https://www.ietf.org/mailman/listinfo/payload >>>> >>> >>> -- Jonathan Lennox jonathan@vidyo.com >>> > >>> >>> >>> _______________________________________________ payload mailing >>> list payload@ietf.org > >>> https://www.ietf.org/mailman/listinfo/payload >> > > _______________________________________________ payload mailing list > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload > > > > > > > > > > > > > > > _______________________________________________ payload mailing list > payload@ietf.org https://www.ietf.org/mailman/li= stinfo/payload --_000_C15918F2FCDA0243A7C919DA7C4BE9940CDE15B3xmbalnx01ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <920F6374427DAD4F8BD0EC015DB06EC4@cisco.com> Content-Transfer-Encoding: quoted-printable
From: Patrik Westin <pwestin@webrtc.org>
Reply-To: "pwestin@webrtc.org" <pwestin@webrtc.org>
Date: Wednesday, December 19, 2012 = 6:06 PM
To: Glen Zorn <glenzorn@gmail.com>
Cc: Stephan Wenger <stewe@stewe.org>, "Ali C. Begen" &l= t;abegen@cisco.com>, Jonathan Le= nnox <jonathan@vidyo.com>, "payload@ietf.org" <<= a href=3D"mailto:payload@ietf.org">payload@ietf.org>, "draft-ietf-payload-vp8@to= ols.ietf.org" <draft-ietf-payload-vp8@tools.ietf.org>
Subject: Re: [payload] WGLC for VP8= Payload

Would you be happy with adding = ;paragrap= h saying something like this?

"People doing splicing of VP8 stream= s will have to make sure the rules for incrementing TL0PICIDX and KEYIDX are obeyed across the splice. This may require rewriting val= ues of TL0PICIDX and KEYIDX after the splice."

Slight rewording:

Implement= ations doing splicing of VP8 streams will have to make sure the rules fo= r incrementing TL0PICIDX and KEYIDX are obeyed across the splice. This will likely require rewri= ting values of TL0PICIDX and KEYIDX after the splice.

BTW, = just out of curiosity, as vp9 is surfacing soon, is there any implicat= ion on this draft? 

-acbegen




On Sat, Dec 15, 2012 at 5:11 AM, Glen Zorn <glenzorn@gmail.= com> wrote:
On 12/15/2012 06:27 AM, Stephan Wenger wrote:

Hi, I'm with Ali here.

Me, too.


The design choice that has been  made in the VP8 payload is different<= br>
> from the one in the SVC payload, despite similarity in codepoint
> names and functionality. The reasoning for that ought to be
> documented. In the SVC payload format, we didn't need to, because we > were first in describing something like this :-) A sentence or two
> should suffice, along the lines Jonathan proposed. Stephan
>
> From: "Ali C. Begen (abegen)" <abegen@cisco.com
> <mailto:abege= n@cisco.com>> Date: Friday, 14 December, 2012 15:09 To:
> "pwestin@= webrtc.org <mailto:pwestin@webrtc.org>" <pwestin@webrtc.org
> <mailto:pwe= stin@webrtc.org>>, Jonathan Lennox <jonathan@vidyo.com
> <mailto:jon= athan@vidyo.com>> Cc:
> "draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>"<= br> > <draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>>, &= quot;payload@ietf.org=
> <mailto:paylo= ad@ietf.org>" <payload@ietf.org
> <mailto:paylo= ad@ietf.org>> Subject: Re: [payload] WGLC for VP8

> Payload
>
> Personally (chair-hat off), I think we should. It does not harm
> anything but provides clarification to someone who is not deep down > in every detail.
>
> From: Patrik Westin <pwestin@webrtc.org <mailto:pwestin@webrtc.org>>
> Reply-To: "pwestin@webrtc.org <mailto:pwestin@webrtc.org>"
> <pwestin@we= brtc.org <mailto:pwestin@webrtc.org>> Date: Friday,

> December 14, 2012 6:06 PM To: Jonathan Lennox <jonathan@vidyo.com
> <mailto:jon= athan@vidyo.com>> Cc: "Ali C. Begen" <abegen@cisco.com
> <mailto:abege= n@cisco.com>>, "payload@ietf.org
> <mailto:paylo= ad@ietf.org>" <payload@ietf.org
> <mailto:paylo= ad@ietf.org>>, "draft-ietf-payload-vp8@tools.ietf.org=
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>"<= br> > <draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>> Su= bject: Re:

> [payload] WGLC for VP8 Payload
>
> Ali do you really want me to add that to the draft?
>
>
> On Fri, Dec 14, 2012 at 2:55 PM, Jonathan Lennox <jonathan@vidyo.com
> <mailto:jonathan@vidyo.com>> wrote:
>
> What I think Ali meant was to add some text describing the
> implications of this design choice for splicers =96 i.e., if these
> features are in use, they must re-write packets indefinitely
> following a splice.
>
>
>
> *From:*pwestin= @google.com <mailto:pwestin@google.com>
> [mailto:pwesti= n@google.com <mailto:pwestin@google.com>] *On Behalf Of
> *Patrik Westin *Sent:* Friday, December 14, 2012 5:47 PM *To:* Ali C.<= br> > Begen (abegen) *Cc:* Jonathan Lennox; payload@ietf.org
> <mailto:paylo= ad@ietf.org>; = draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>
>
>
> *Subject:* Re: [payload] WGLC for VP8 Payload

>
>
>
> Well he did not have a point in my mind. This is what he wrote.
>
>
>
> "The VP8 payload format's decision is a reasonable design choice = --
> as compared to the H.264 SVC rules, it removes some ambiguity between<= br> > splice points and packet loss, giving decoders somewhat greater
> visibility as to what's going on in the bitstream, and also allows
> TL0PICIDX and KEYIDX to be orthogonal options because they increment > independently."
>
>
>
> The worst thing that can happen in a draft is to leave ambiguity,
> which we don't have in the current draft. However if we do it the way<= br> > H.264 SVC do we could introduce such ambiguity
>
>
>
> On Fri, Dec 14, 2012 at 2:30 PM, Ali C. Begen (abegen)
> <abegen@cisco.com <mailto:abegen@cisco.com>> wrote:
>
> Are you at least planning to put some text around the point Jonathan > brought up?
>
>
>
> *From: *Patrik Westin <pwestin@webrtc.org
> <mailto:pwe= stin@webrtc.org>> *Reply-To: *"pwestin@webrtc.org
> <mailto:pwe= stin@webrtc.org>" <pwestin@webrtc.org
> <mailto:pwe= stin@webrtc.org>> *Date: *Friday, December 14, 2012 4:53
> PM
>
>
> *To: *"Ali C. Begen" <abegen@cisco.com <mailto:abegen@cisco.com>>
>
> *Cc: *Jonathan Lennox <jonathan@vidyo.com
> <mailto:jon= athan@vidyo.com>>, "payload@ietf.org
> <mailto:paylo= ad@ietf.org>" <payload@ietf.org
> <mailto:paylo= ad@ietf.org>>, "draft-ietf-payload-vp8@tools.ietf.org=
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>"<= br> > <draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>> >
>
> *Subject: *Re: [payload] WGLC for VP8 Payload

>
>
>
> Trying to send this again since my previous message did not reach the<= br> > list.
>
> Thanks for pointing out the inconsistency. We've submitted a new
> draft that fixes that problem.
>
>
> The second issue was intentional. We'll keep it this way.
>
>
>
> On Thu, Dec 13, 2012 at 8:55 AM, Ali C. Begen (abegen)
> <abegen@cisco.com <mailto:abegen@cisco.com>> wrote:
>
> Thanks, the authors just rev'ed the draft to fix the first issue. I > hope they will address the second issue first in the list and then
> reflect the agreement in the next revision. I will hold on to the doc<= br> > write-up till then.
>
>
> -acbegen
>
> -----Original Message----- From: Jonathan Lennox <jonathan@vidyo.com
> <mailto:jon= athan@vidyo.com>>

>
> Date: Thursday, December 13, 2012 11:29 AM To: "Ali C. Begen"= ;
> <abegen@cisco= .com <mailto:a= begen@cisco.com>>, "payload@ietf.org
> <mailto:paylo= ad@ietf.org>" <payload@ietf.org
> <mailto:paylo= ad@ietf.org>> Cc: "draft-ietf-payload-vp8@tools.ietf.= org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>"<= br> > <draft-ietf-payload-vp8@tools.ietf.org
> <mailto:draft-ietf-payload-vp8@tools.ietf.org>>

>
> Subject: RE: [payload] WGLC for VP8 Payload
>
>> Hi, Ali --
>>
>> I just wanted to make sure the issue had been considered; if the >> WG agrees that the current design is okay given the limitations >> I've mentioned, I'm not going to object.
>>
>> Discussion of the issue might be helpful in the document.
>>
>> -----Original Message----- From: Ali C. Begen (abegen)
>> [mailto:abeg= en@cisco.com <mailto:abegen@cisco.com>] Sent: Tuesday,

>> December 11, 2012 7:13 PM To: Jonathan Lennox; payload@ietf.org
>> <mailto:p= ayload@ietf.org> Cc: = draft-ietf-payload-vp8@tools.ietf.org
>> <mailto:draft-ietf-payload-vp8@tools.ietf.org> Su= bject: Re:

>> [payload] WGLC for VP8 Payload
>>
>> The first one should be fixed by the authors thru a quick revision= .
>> As for the second one, I will ask the authors reply. Also if there=
>> are others who strongly think one way or another, lets discuss it.=
>>
>> Jonathan, are you ok if the authors simply acknowledge this in the=
>> draft (assuming they agree with you) or do you actually not like >> this at all?
>>
>> -acbegen
>>
>> -----Original Message----- From: Jonathan Lennox
>> <jonath= an@vidyo.com <mailto:jonathan@vidyo.com>> Date: Tuesday,

>> December 11, 2012 11:49 AM To: "payload@ietf.org
>> <mailto:p= ayload@ietf.org>" <payload@ietf.org
>> <mailto:p= ayload@ietf.org>> Subject: Re: [payload] WGLC for VP8

>> Payload
>>
>>> Hi -- I have two comments on this draft. Sorry for being late.=
>>>
>>> First of all, an editorial matter: Section 6 says the format h= as
>>> no parameters, but section 6.1 lists two optional parameters >>> (max-fr and max-fs).
>>>
>>>
>>> Secondly, more substantively, I note that the payload format's=
>>> rules on KEYIDX and TL0PICIDX impose a fair bit of overhead on=
>>> boxes that wish to splice together VP8 streams, since both val= ues
>>> are required to always increment consecutively in a bitstream = (if
>>> they're being used).
>>>
>>> By contrast, the equivalent fields of the H.264 SVC payload >>> format (in the PACSI) just say that IDRPICID must be different= in
>>> consecutive IDR frames, without requiring that the value
>>> increment by 1; and TL0PICIDX resets to 0 on every IDR frame,<= br> >>> rather than carrying on continuously. (H.264's IDR frames are<= br> >>> analogous for these purposes to VP8's essential keyframes). >>>
>>> This means that an H.264 SVC splicer -- as long as it doesn't<= br> >>> get unlucky, such that the two streams it's splicing happen to=
>>> have identical IDRPICID values at the splice point -- can just=
>>> transition from one bitstream to another at any IDR frame.
>>>
>>> By contrast, following a splice, a VP8 splicer must re-write b= oth
>>> these fields for the rest of the lifetime of the stream, since=
>>> they each have only one valid possible value following the
>>> splice.
>>>
>>> The VP8 payload format's decision is a reasonable design choic= e
>>> -- as compared to the H.264 SVC rules, it removes some ambigui= ty
>>> between splice points and packet loss, giving decoders somewha= t
>>> greater visibility as to what's going on in the bitstream, and=
>>> also allows TL0PICIDX and KEYIDX to be orthogonal options beca= use
>>> they increment independently. However, I wanted to make sure >>> this had been considered explicitly by the working group, and = we
>>> had consensus that it was the right decision.
>>>
>>> (Note well disclaimer: Vidyo has an IPR declaration against th= e
>>> VP8 payload -- see <http://tracker.tools.ietf.org/ipr/162= 2/>.)
>>>
>>>
>>> On Dec 5, 2012, at 9:20 PM, Ali C. Begen (abegen) wrote:
>>>
>>>> I have not seen any comments on the list. Please review th= e
>>>> draft and post your comments on the list.
>>>>
>>>> Thanks. -acbegen
>>>>
>>>> -----Original Message----- From: "Ali C. Begen"<= br>
>>>> <= abegen@cisco.com <mailto:abegen@cisco.com>> Date: Monday,

>>>> November 19, 2012 3:15 PM To: "payload@ietf.org
>>>> <mailto:payload@ietf.org>" <payload@ietf.org
>>>> <mailto:payload@ietf.org>> Subject: [payload] WGLC for VP8

>>>> Payload
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> We had a WGLC for this draft earlier this year and the= re have
>>>>> been a few updates to the document. I am starting a 2n= d
>>>>> WGLC. Please review and comment on the list by Decembe= r
>>>>> 10th.
>>>>>
>>>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8/?incl= ude_tex
>
>>>>>
>>>> t=3D1
>>>>>
>>>> https://www.ietf.org/mailman/listinfo/payload<= br> >>>>
>>>
>>> -- Jonathan Lennox jonathan@vidyo.com
>>> <mailto:jonathan@vidyo.com>
>>>
>>>
>>> _______________________________________________ payload= mailing
>>> list pay= load@ietf.org <mailto:payload@ietf.org>

>>> https://www.ietf.org/mailman/listinfo/payload
>>
>
> _______________________________________________ payload mailing= list
> payload@ietf.org= <mailto:paylo= ad@ietf.org>

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


--_000_C15918F2FCDA0243A7C919DA7C4BE9940CDE15B3xmbalnx01ciscoc_--