From nobody Sun Jul 2 16:45:13 2017 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7761200FC; Sun, 2 Jul 2017 16:45:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: avtext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149903911109.4958.12599646407052332539@ietfa.amsl.com> Date: Sun, 02 Jul 2017 16:45:11 -0700 Archived-At: Subject: [avtext] I-D Action: draft-ietf-avtext-lrr-07.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.22 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jul 2017 23:45:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions of the IETF. Title : The Layer Refresh Request (LRR) RTCP Feedback Message Authors : Jonathan Lennox Danny Hong Justin Uberti Stefan Holmer Magnus Flodman Filename : draft-ietf-avtext-lrr-07.txt Pages : 15 Date : 2017-07-02 Abstract: This memo describes the RTCP Payload-Specific Feedback Message "Layer Refresh Request" (LRR), which can be used to request a state refresh of one or more substreams of a layered media stream. It also defines its use with several RTP payloads for scalable media formats. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-lrr/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-avtext-lrr-07 https://datatracker.ietf.org/doc/html/draft-ietf-avtext-lrr-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-lrr-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jul 2 17:02:21 2017 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8B612741D for ; Sun, 2 Jul 2017 17:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksCfcqXiKtsV for ; Sun, 2 Jul 2017 17:02:19 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F76126E3A for ; Sun, 2 Jul 2017 17:02:18 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v62NxBxH006427 for ; Sun, 2 Jul 2017 20:02:14 -0400 Received: from mail.vidyo.com (mail2.vidyo.com [162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 2be6g40p8q-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT) for ; Sun, 02 Jul 2017 20:02:14 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Sun, 2 Jul 2017 19:02:13 -0500 From: Jonathan Lennox To: "avtext@ietf.org" Thread-Topic: [avtext] I-D Action: draft-ietf-avtext-lrr-07.txt Thread-Index: AQHS847mADIvH5+LtkGepirF+qmShqJBi/EA Date: Mon, 3 Jul 2017 00:02:13 +0000 Message-ID: <11EFCCC3-9344-4DEF-9627-B9F11136988B@vidyo.com> References: <149903911109.4958.12599646407052332539@ietfa.amsl.com> In-Reply-To: <149903911109.4958.12599646407052332539@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [100.35.229.243] Content-Type: text/plain; charset="utf-8" Content-ID: <5271B084CBAAF74B904FCE7D189FAACE@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-02_17:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707020416 Archived-At: Subject: Re: [avtext] I-D Action: draft-ietf-avtext-lrr-07.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 00:02:20 -0000 VGhpcyB2ZXJzaW9uIGFkZHJlc3NlcyBjb21tZW50cyBkdXJpbmcgSUVTRyBSZXZpZXcuDQoNClRo ZSB0ZWNobmljYWwgY2hhbmdlcyBhcmUgDQoxKSBpdOKAmXMgbm93IHJlcXVpcmVkIHRvIGRpc2Nh cmQgTFJScyB3aG9zZSBUTElEIG9yIFRUSUQgaXMgbG93ZXIgdGhhbiBDTElEIC8gQ1RJRCDigJQg YmVmb3JlIHRoaXMgd2FzIGZvcmJpZGRlbiBmb3Igc2VuZGVycyBidXQgcmVjZWl2ZXJz4oCZIGJl aGF2aW9yIHdhcyB1bnNwZWNpZmllZDsgYW5kDQoyKSBpdHMgbXV4IGNhdGVnb3J5IGlzIHNwZWNp ZmllZCBhcyBJREVOVElDQUwtUEVSLVBULCBhcyBwcmV2aW91c2x5IG1lbnRpb25lZCBvbiB0aGUg bGlzdC4NCg0KVGhlcmUgYXJlIGFsc28gYSBudW1iZXIgb2YgZWRpdG9yaWFsIGNsYXJpZmljYXRp b25zLg0KDQoNCj4gT24gSnVsIDIsIDIwMTcsIGF0IDc6NDUgUE0sIGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyB3cm90ZToNCj4gDQo+IA0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFi bGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+IFRoaXMg ZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBFeHRlbnNp b25zIG9mIHRoZSBJRVRGLg0KPiANCj4gICAgICAgIFRpdGxlICAgICAgICAgICA6IFRoZSBMYXll ciBSZWZyZXNoIFJlcXVlc3QgKExSUikgUlRDUCBGZWVkYmFjayBNZXNzYWdlDQo+ICAgICAgICBB dXRob3JzICAgICAgICAgOiBKb25hdGhhbiBMZW5ub3gNCj4gICAgICAgICAgICAgICAgICAgICAg ICAgIERhbm55IEhvbmcNCj4gICAgICAgICAgICAgICAgICAgICAgICAgIEp1c3RpbiBVYmVydGkN Cj4gICAgICAgICAgICAgICAgICAgICAgICAgIFN0ZWZhbiBIb2xtZXINCj4gICAgICAgICAgICAg ICAgICAgICAgICAgIE1hZ251cyBGbG9kbWFuDQo+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1p ZXRmLWF2dGV4dC1scnItMDcudHh0DQo+IAlQYWdlcyAgICAgICAgICAgOiAxNQ0KPiAJRGF0ZSAg ICAgICAgICAgIDogMjAxNy0wNy0wMg0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgVGhpcyBtZW1vIGRl c2NyaWJlcyB0aGUgUlRDUCBQYXlsb2FkLVNwZWNpZmljIEZlZWRiYWNrIE1lc3NhZ2UgIkxheWVy DQo+ICAgUmVmcmVzaCBSZXF1ZXN0IiAoTFJSKSwgd2hpY2ggY2FuIGJlIHVzZWQgdG8gcmVxdWVz dCBhIHN0YXRlIHJlZnJlc2gNCj4gICBvZiBvbmUgb3IgbW9yZSBzdWJzdHJlYW1zIG9mIGEgbGF5 ZXJlZCBtZWRpYSBzdHJlYW0uICBJdCBhbHNvIGRlZmluZXMNCj4gICBpdHMgdXNlIHdpdGggc2V2 ZXJhbCBSVFAgcGF5bG9hZHMgZm9yIHNjYWxhYmxlIG1lZGlhIGZvcm1hdHMuDQo+IA0KPiANCj4g VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYXZ0ZXh0LWxyci8NCj4g DQo+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCj4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXZ0ZXh0LWxyci0wNw0KPiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtYXZ0ZXh0LWxyci0w Nw0KPiANCj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0 Og0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1hdnRleHQt bHJyLTA3DQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiAN Cj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0 Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gYXZ0ZXh0IG1haWxpbmcg bGlzdA0KPiBhdnRleHRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9hdnRleHQNCj4gDQoNCg== From nobody Mon Jul 3 11:36:20 2017 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABA71316EA; Mon, 3 Jul 2017 11:36:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: avtext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149910697240.22857.10071203746819150645@ietfa.amsl.com> Date: Mon, 03 Jul 2017 11:36:12 -0700 Archived-At: Subject: [avtext] I-D Action: draft-ietf-avtext-framemarking-05.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.22 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 18:36:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Extensions of the IETF. Title : Frame Marking RTP Header Extension Authors : Espen Berger Suhas Nandakumar Mo Zanaty Filename : draft-ietf-avtext-framemarking-05.txt Pages : 11 Date : 2017-07-03 Abstract: This document describes a Frame Marking RTP header extension used to convey information about video frames that is critical for error recovery and packet forwarding in RTP middleboxes or network nodes. It is most useful when media is encrypted, and essential when the middlebox or node has no access to the media decryption keys. It is also useful for codec-agnostic processing of encrypted or unencrypted media, while it also supports extensions for codec-specific information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-framemarking/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-avtext-framemarking-05 https://datatracker.ietf.org/doc/html/draft-ietf-avtext-framemarking-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-framemarking-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 5 08:56:13 2017 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288D213193D for ; Wed, 5 Jul 2017 08:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yp0SJLzLILJg for ; Wed, 5 Jul 2017 08:56:10 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F993131631 for ; Wed, 5 Jul 2017 08:56:10 -0700 (PDT) Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v65FsMRb001512; Wed, 5 Jul 2017 11:56:06 -0400 Received: from mail.vidyo.com (mail2.vidyo.com [162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 2be4ukkdcs-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 05 Jul 2017 11:56:06 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Wed, 5 Jul 2017 10:56:05 -0500 From: Jonathan Lennox To: Sergio Garcia Murillo CC: Bernard Aboba , "Mo Zanaty (mzanaty)" , "avtext@ietf.org" , "Alexandre GOUAILLARD" Thread-Topic: [avtext] Frame marking & VP9 SVC Thread-Index: AQHSs7BKLx8XxsPKTUClO3jvyvX7QqHCXDGAgAkxMYCAABM4AIAJBioAgGZb0YCAABy+gIAAAWiAgAsaKQA= Date: Wed, 5 Jul 2017 15:56:04 +0000 Message-ID: References: <0b5c72c6-4f59-daba-f193-282ea10d1f07@gmail.com> <00166BCB-6452-4D72-B5DF-5A456B2304EF@vidyo.com> <9a4994d3-f033-e1da-7884-a55c31789c59@gmail.com> <30944D17-BEB9-4EC6-A97C-0700567563FB@vidyo.com> <918659db-1742-4dd4-6fa3-7d0797aa4582@gmail.com> <50b624f9-4ce7-099e-1730-1b3a0d986e69@cosmosoftware.io> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: multipart/alternative; boundary="_000_A3A2CACAFA2F4BA282090F5B556EA732vidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-05_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707050268 Archived-At: Subject: Re: [avtext] Frame marking & VP9 SVC X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 15:56:12 -0000 --_000_A3A2CACAFA2F4BA282090F5B556EA732vidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2VyZ2lvIOKAlCB0aGUgdXBkYXRlZCBWUDkgcGF5bG9hZCBkcmFmdCBJIHN1Ym1pdHRlZCBNb25k YXkgaW5jbHVkZXMgYSBzZWN0aW9uIGRlc2NyaWJpbmcgaXRzIHVzYWdlIHdpdGggZnJhbWUgbWFy a2luZy4NCg0KTGV0IG1lIGtub3cgd2hhdCB5b3UgdGhpbms/ICBJdCBjaGFuZ2VzIHRoZSBTIGFu ZCBUIGZpZWxkcyB0byByZWZsZWN0IHRoZSBsYXRlc3QgVlA5IGFuZCBmcmFtZSBtYXJraW5nIGRy YWZ0cywgYnV0IGl0IGRvZXMgbm90IGluY2x1ZGUgdGhlIFAgb3IgVSBiaXRzLg0KDQpJIHRoaW5r IHRoZSBpbnRlbnRpb24gaXMgdGhhdCBmcmFtZSBtYXJraW5n4oCZcyBCIGJpdCB3aWxsIHByb3Zp ZGUgYSBjb2Fyc2VyLWdyYWluIHZlcnNpb24gb2Ygd2hhdCBQIGFuZCBVIGRvIChhbmQgdGhlIOKA nGRvbuKAmXQgdXNlIGl0IHdpdGggd2VpcmQgc3RydWN0dXJlc+KAnSByZXF1aXJlbWVudCB3aWxs IG1ha2UgdGhhdCBzdWZmaWNpZW50LCB0aG91Z2ggdGhhdCBtYXkgbmVlZCB0byBiZSBtYWRlIG1v cmUgc3BlY2lmaWMpLiAgV2hhdCBkbyB5b3UgdGhpbms/DQoNCk9uIEp1biAyOCwgMjAxNywgYXQg MTA6MjMgQU0sIFNlcmdpbyBHYXJjaWEgTXVyaWxsbyA8c2VyZ2lvLmdhcmNpYS5tdXJpbGxvQGNv c21vc29mdHdhcmUuaW88bWFpbHRvOnNlcmdpby5nYXJjaWEubXVyaWxsb0Bjb3Ntb3NvZnR3YXJl LmlvPj4gd3JvdGU6DQoNCg0KWWVzLCBhdCBsZWFzdCBpbiBWUDkgU1ZDIHlvdSBjYW4gZGVmaW5l IGhvdyBtYW55IHRlbXBvcmFsIGFuZCBob3cgbWFueSBzcGF0aWFsIGxheWVycyBkbyB5b3Ugd2Fu dCBzaW11bHRhbmVvdXNseSBpbiB0aGUgZW5jb2RpbmcuIE5vdGUgYWxzbywgdGhhdCBWUDkgc3Vw cG9ydHMgcXVhbGl0eSBsYXllcnMgYXMgc3BhdGlhbCBsYXllcnMgd2l0aG91dCBhbnkgcmVzb2x1 dGlvbiBjaGFuZ2UsIHNvIHRoZSB0ZXJtICJzcGF0aWFsIGxheWVyIiBpcyB1c2VkIHRvIHJlcHJl c2VudCBib3RoIHNwYXRpYWwgYW5kIHF1YWxpdHkgbGF5ZXJzLg0KDQpCUg0KU2VyZ2lvDQpPbiAy OC8wNi8yMDE3IDE2OjE4LCBCZXJuYXJkIEFib2JhIHdyb3RlOg0KU2VyZ2lvIHNhaWQ6ICAiU28s IHNob3VsZG4ndCB0aGUgTElEIHJlZmVyZW5jZSB0byB0aGUgc3BhdGlhbCBsYXllciBJRCBvbmx5 IGFuZCBvbWl0IHRoZSBxdWFsaXR5IGxheWVyIGlkIGNvbXBsZXRlbHk/IEFsc28sIHRoZSBzcGF0 aWFsIGxheWVyIGlkIGlzIDMgYml0cyBvbiB0aGF0IGRyYWZ0LiINCg0KW0JBXSBRdWVzdGlvbjog IEluIFZQOSAob3IgQVYxLCBmb3IgdGhhdCBtYXR0ZXIpIGlzIGl0IHBvc3NpYmxlIHRvIHVzZSBi b3RoIHNwYXRpYWwgYW5kIHF1YWxpdHkgc2NhbGFiaWxpdHkgaW4gdGhlIHNhbWUgZW5jb2Rpbmc/ DQoNCk9uIFdlZCwgSnVuIDI4LCAyMDE3IGF0IDU6MzUgQU0sIFNlcmdpbyBHYXJjaWEgTXVyaWxs byA8c2VyZ2lvLmdhcmNpYS5tdXJpbGxvQGNvc21vc29mdHdhcmUuaW88bWFpbHRvOnNlcmdpby5n YXJjaWEubXVyaWxsb0Bjb3Ntb3NvZnR3YXJlLmlvPj4gd3JvdGU6DQpIaSBhbGwgYWdhaW4sDQoN CkRpZCB5b3UgaGFkIGEgY2hhbmNlIHRvIHJldmlldyB0aGUgY2hhbmdlcyB0byBhZGQgdGhlIFZQ OSBTVkMgc3BhdGlhbCBsYXllciBpbmZvcm1hdGlvbiBpbnRvIHRoZSBMSUQgb2YgdGhlIGZyYW1l IG1hcmtpbmcgZXh0ZW5zaW9uPyAoYXQgaHR0cHM6Ly9naXRodWIuY29tL211cmlsbG8xMjgvZHJh ZnQtYmVyZ2VyLWF2dGV4dC1mcmFtZW1hcmtpbmcvY29tbWl0LzM1Y2RiMjI5MTA4MjUxZjEyYmMx Y2RmNzc5MDlkZjgzYTUxZDM5OTQpDQoNCkFsc28sIEZZSSwgSSBoYXZlIHN1Ym1pdHRlZCBhIENM IHRvIGxpYndlYnJ0YyB0byBzdXBwb3J0IGZyYW1lbWFya2luZyBleHRlbnNpb24uIEN1cnJlbnRs eSBpdCBzdXBwb3J0cyBWUDgsIEgyNjQgYW5kIG5vbi1TVkMgVlA5LCBidXQgSSB3b3VsZCBsb3Zl IHRvIHRhY2tsZSBWUDkgU1ZDIGFzIHNvb24gYXMgd2UgZ2V0IGFuIGFncmVlbWVudCBvbiB0aGUg Y2hhbmdlcyB0byB0aGUgTElEOg0KDQpodHRwczovL2NvZGVyZXZpZXcud2VicnRjLm9yZy8yOTU0 NTAzMDAyLw0KDQpCZXN0IHJlZ2FyZHMNClNlcmdpbw0KDQoNCk9uIDI0LzA0LzIwMTcgMTE6Mjgs IFNlcmdpbyBHYXJjaWEgTXVyaWxsbyB3cm90ZToNCk9uIDE4LzA0LzIwMTcgMTc6NDAsIEpvbmF0 aGFuIExlbm5veCB3cm90ZToNCk9uZSBvZiB0aGUgZ29hbHMgb2YgRnJhbWUgTWFya2luZyBpcyB0 aGF0IGFuIFNGVSBjYW4gYmUgYWdub3N0aWMgdG8gdGhlIGRldGFpbHMgb2YgdGhlIGxheWVyaW5n LCBhbmQganVzdCB0cmVhdCBsYXllciBJRHMgYXMgb3BhcXVlIGxheWVyIGlkZW50aWZpZXJzLiAg UHV0dGluZyBub24tbGF5ZXIgYml0cyBpbnRvIHRoZSBMSUQgZmllbGQgd291bGQgYnJlYWsgdGhp cyBnb2FsLg0KDQpBdCB0aGUgSUVURiBtZWV0aW5nIGluIENoaWNhZ28sIGJvdGggQmVybmFyZCBB Ym9iYSBhbmQgSSB0aG91Z2h0IHRoYXQgZnJhbWUgbWFya2luZyBtaWdodCBuZWVkIGVuaGFuY2Vt ZW50cyBpbiBvcmRlciBmb3Igc3BhdGlhbCBzY2FsYWJpbGl0eSB0byBiZSBmdWxseSBzdXBwb3J0 ZWQuIEnigJltIGFkZGluZyBoaW0gdG8gdGhlIENjLCBhcyB3ZWxsIGFzIG15IGNvLWF1dGhvcnMg b24gdGhlIFZQOSBwYXlsb2FkLg0KDQpTZXJnaW8sIGlmIHlvdSB3YW50IHRvIHNlbmQgYSBwdWxs IHJlcXVlc3QgdG8gY29udHJpYnV0ZSB0ZXh0IGZvciB0aGUgVlA5IHNwZWMgKHdoaWNoIHdvdWxk IGJlIHdlbGNvbWUpLCBpdOKAmXMgaW4gR2l0aHViIGF0IGh0dHBzOi8vZ2l0aHViLmNvbS9qdWJl cnRpL2RyYXVnaHRzIC4NCkN1cnJlbnRseSB0aGUgVlA5IExJRCBtYXBwaW5nIGlzIGRlc2NyaWJl ZCBvbiB0aGUgZnJhbWUgbWFya2luZyBkcmFmdCwgYW5kIG5vdCBpbiB0aGUgVlA5IGRyYWZ0LiBX ZSBjb3VsZCBtb3ZlIHRoZSBmdWxsIGRlc2NyaXB0aW9uIGZyb20gb25lIHRleHQgdG8gYW5vdGhl ciwgYnV0IGF0IGxlYXN0IGZvciBtZSwgaXQgd2FzIGVhc2llciB0byBwcm92aWRlIGEgc21hbGwg cGF0Y2ggZm9yIGN1cnJlbnQgZHJhZnQgdG8gYWRkcmVzcyBteSBjb21tZW50czoNCg0KaHR0cHM6 Ly9naXRodWIuY29tL211cmlsbG8xMjgvZHJhZnQtYmVyZ2VyLWF2dGV4dC1mcmFtZW1hcmtpbmcv Y29tbWl0LzM1Y2RiMjI5MTA4MjUxZjEyYmMxY2RmNzc5MDlkZjgzYTUxZDM5OTQNCg0KSSBoYXZl IG5vdCBmb3VuZCB0aGUgLnhtbCBpbiBhbnkgZ2l0aHViIHJlcG8sIHNvIGp1c3QgZG93bmxvYWRl ZCB0aGUgbGF0ZXN0IGRyYWZ0IGFuZCBhcHBsaWVkIHRoZSBjaGFuZ2VzIG9uIHRvcCBvZiBpdC4N Cg0KUGxlYXNlLCBsZXQgbWUga25vdyB3aGF0IGFyZSB5b3VyIHZpZXdzIGFib3V0IGl0Lg0KDQoN Cg0KDQoNCg0KDQo= --_000_A3A2CACAFA2F4BA282090F5B556EA732vidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: <014B23ACBBB7514FB2A3D02CBF9307D1@vidyo.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5TZXJnaW8g 4oCUIHRoZSB1cGRhdGVkIFZQOSBwYXlsb2FkIGRyYWZ0IEkgc3VibWl0dGVkIE1vbmRheSBpbmNs dWRlcyBhIHNlY3Rpb24gZGVzY3JpYmluZyBpdHMgdXNhZ2Ugd2l0aCBmcmFtZSBtYXJraW5nLjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ TGV0IG1lIGtub3cgd2hhdCB5b3UgdGhpbms/ICZuYnNwO0l0IGNoYW5nZXMgdGhlIFMgYW5kIFQg ZmllbGRzIHRvIHJlZmxlY3QgdGhlIGxhdGVzdCBWUDkgYW5kIGZyYW1lIG1hcmtpbmcgZHJhZnRz LCBidXQgaXQgZG9lcyBub3QgaW5jbHVkZSB0aGUgUCBvciBVIGJpdHMuPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JIHRoaW5rIHRoZSBp bnRlbnRpb24gaXMgdGhhdCBmcmFtZSBtYXJraW5n4oCZcyBCIGJpdCB3aWxsIHByb3ZpZGUgYSBj b2Fyc2VyLWdyYWluIHZlcnNpb24gb2Ygd2hhdCBQIGFuZCBVIGRvIChhbmQgdGhlIOKAnGRvbuKA mXQgdXNlIGl0IHdpdGggd2VpcmQgc3RydWN0dXJlc+KAnSByZXF1aXJlbWVudCB3aWxsIG1ha2Ug dGhhdCBzdWZmaWNpZW50LCB0aG91Z2ggdGhhdCBtYXkgbmVlZCB0byBiZSBtYWRlIG1vcmUgc3Bl Y2lmaWMpLiAmbmJzcDtXaGF0DQogZG8geW91IHRoaW5rPzwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5P biBKdW4gMjgsIDIwMTcsIGF0IDEwOjIzIEFNLCBTZXJnaW8gR2FyY2lhIE11cmlsbG8gJmx0Ozxh IGhyZWY9Im1haWx0bzpzZXJnaW8uZ2FyY2lhLm11cmlsbG9AY29zbW9zb2Z0d2FyZS5pbyIgY2xh c3M9IiI+c2VyZ2lvLmdhcmNpYS5tdXJpbGxvQGNvc21vc29mdHdhcmUuaW88L2E+Jmd0OyB3cm90 ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIiBjbGFzcz0iIj4N CjxwIGNsYXNzPSIiPlllcywgYXQgbGVhc3QgaW4gVlA5IFNWQyB5b3UgY2FuIGRlZmluZSBob3cg bWFueSB0ZW1wb3JhbCBhbmQgaG93IG1hbnkgc3BhdGlhbCBsYXllcnMgZG8geW91IHdhbnQgc2lt dWx0YW5lb3VzbHkgaW4gdGhlIGVuY29kaW5nLiBOb3RlIGFsc28sIHRoYXQgVlA5IHN1cHBvcnRz IHF1YWxpdHkgbGF5ZXJzIGFzIHNwYXRpYWwgbGF5ZXJzIHdpdGhvdXQgYW55IHJlc29sdXRpb24g Y2hhbmdlLCBzbyB0aGUgdGVybSAmcXVvdDtzcGF0aWFsIGxheWVyJnF1b3Q7DQogaXMgdXNlZCB0 byByZXByZXNlbnQgYm90aCBzcGF0aWFsIGFuZCBxdWFsaXR5IGxheWVycy48YnIgY2xhc3M9IiI+ DQo8L3A+DQpCUjxiciBjbGFzcz0iIj4NClNlcmdpbzxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 Im1vei1jaXRlLXByZWZpeCI+T24gMjgvMDYvMjAxNyAxNjoxOCwgQmVybmFyZCBBYm9iYSB3cm90 ZTo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9Im1p ZDpDQU9XJiM0MzsyZHU3SzFDejJQekczZGRkSGFqVzN0UyYjNDM7a2tTM0JHc194UF9zdXltc3NI MnB3QUBtYWlsLmdtYWlsLmNvbSIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj5T ZXJnaW8gc2FpZDogJm5ic3A7JnF1b3Q7PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6cmdi KDIzNCwyNDUsMjU1KTtjb2xvcjpyZ2IoNjgsNzcsODYpO2ZvbnQtZmFtaWx5OlNGTW9uby1SZWd1 bGFyLENvbnNvbGFzLCZxdW90O0xpYmVyYXRpb24gTW9ubyZxdW90OyxNZW5sbyxDb3VyaWVyLG1v bm9zcGFjZTtmb250LXNpemU6MTNweDt3aGl0ZS1zcGFjZTpwcmUtd3JhcCIgY2xhc3M9IiI+U28s IHNob3VsZG4ndCB0aGUgTElEIHJlZmVyZW5jZQ0KIHRvIHRoZSBzcGF0aWFsIGxheWVyIElEIG9u bHkgYW5kIG9taXQgdGhlIHF1YWxpdHkgbGF5ZXIgaWQgY29tcGxldGVseT8gQWxzbywgdGhlIHNw YXRpYWwgbGF5ZXIgaWQgaXMgMyBiaXRzIG9uIHRoYXQgZHJhZnQuPC9zcGFuPiZxdW90OzxiciBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPltCQV0gUXVlc3Rpb246ICZuYnNwO0luIFZQOSAob3IgQVYxLCBmb3IgdGhhdCBtYXR0ZXIp IGlzIGl0IHBvc3NpYmxlIHRvIHVzZSBib3RoIHNwYXRpYWwgYW5kIHF1YWxpdHkgc2NhbGFiaWxp dHkgaW4gdGhlIHNhbWUgZW5jb2Rpbmc/PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWls X2V4dHJhIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gV2VkLCBK dW4gMjgsIDIwMTcgYXQgNTozNSBBTSwgU2VyZ2lvIEdhcmNpYSBNdXJpbGxvIDxzcGFuIGRpcj0i bHRyIiBjbGFzcz0iIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86c2VyZ2lvLmdhcmNpYS5tdXJpbGxv QGNvc21vc29mdHdhcmUuaW8iIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUi IGNsYXNzPSIiPnNlcmdpby5nYXJjaWEubXVyaWxsb0Bjb3Ntb3NvZnR3YXJlLmlvPC9hPiZndDs8 L3NwYW4+IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90 ZSIgc3R5bGU9Im1hcmdpbjowIDAgMA0KICAgICAgICAgICAgLjhleDtib3JkZXItbGVmdDoxcHgg I2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCkhpIGFsbCBhZ2Fpbiw8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpEaWQgeW91IGhhZCBhIGNoYW5jZSB0byByZXZpZXcgdGhlIGNoYW5n ZXMgdG8gYWRkIHRoZSBWUDkgU1ZDIHNwYXRpYWwgbGF5ZXIgaW5mb3JtYXRpb24gaW50byB0aGUg TElEIG9mIHRoZSBmcmFtZSBtYXJraW5nIGV4dGVuc2lvbj8gKGF0DQo8YSBocmVmPSJodHRwczov L2dpdGh1Yi5jb20vbXVyaWxsbzEyOC9kcmFmdC1iZXJnZXItYXZ0ZXh0LWZyYW1lbWFya2luZy9j b21taXQvMzVjZGIyMjkxMDgyNTFmMTJiYzFjZGY3NzkwOWRmODNhNTFkMzk5NCIgcmVsPSJub3Jl ZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0iIj4N Cmh0dHBzOi8vZ2l0aHViLmNvbS9tdXJpbGxvMTI4Lzx3YnIgY2xhc3M9IiI+ZHJhZnQtYmVyZ2Vy LWF2dGV4dC1mcmFtZW1hcmtpPHdiciBjbGFzcz0iIj5uZy9jb21taXQvMzVjZGIyMjkxMDgyNTFm MTJiYzE8d2JyIGNsYXNzPSIiPmNkZjc3OTA5ZGY4M2E1MWQzOTk0PC9hPik8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpBbHNvLCBGWUksIEkgaGF2ZSBzdWJtaXR0ZWQgYSBDTCB0byBsaWJ3 ZWJydGMgdG8gc3VwcG9ydCBmcmFtZW1hcmtpbmcgZXh0ZW5zaW9uLiBDdXJyZW50bHkgaXQgc3Vw cG9ydHMgVlA4LCBIMjY0IGFuZCBub24tU1ZDIFZQOSwgYnV0IEkgd291bGQgbG92ZSB0byB0YWNr bGUgVlA5IFNWQyBhcyBzb29uIGFzIHdlIGdldCBhbiBhZ3JlZW1lbnQgb24gdGhlIGNoYW5nZXMg dG8gdGhlIExJRDo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczov L2NvZGVyZXZpZXcud2VicnRjLm9yZy8yOTU0NTAzMDAyLyIgcmVsPSJub3JlZmVycmVyIiB0YXJn ZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0iIj5odHRwczovL2NvZGVy ZXZpZXcud2VicnRjLm9yZy88d2JyIGNsYXNzPSIiPjI5NTQ1MDMwMDIvPC9hPjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCkJlc3QgcmVnYXJkczxiciBjbGFzcz0iIj4NClNlcmdpbzxzcGFu IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9u IDI0LzA0LzIwMTcgMTE6MjgsIFNlcmdpbyBHYXJjaWEgTXVyaWxsbyB3cm90ZTo8YnIgY2xhc3M9 IiI+DQo8L3NwYW4+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46MCAwIDANCiAgICAgICAgICAgICAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtw YWRkaW5nLWxlZnQ6MWV4Ij4NCjxzcGFuIGNsYXNzPSIiPk9uIDE4LzA0LzIwMTcgMTc6NDAsIEpv bmF0aGFuIExlbm5veCB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDANCiAgICAgICAgICAgICAgICAgIC44ZXg7Ym9y ZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQpPbmUgb2YgdGhlIGdv YWxzIG9mIEZyYW1lIE1hcmtpbmcgaXMgdGhhdCBhbiBTRlUgY2FuIGJlIGFnbm9zdGljIHRvIHRo ZSBkZXRhaWxzIG9mIHRoZSBsYXllcmluZywgYW5kIGp1c3QgdHJlYXQgbGF5ZXIgSURzIGFzIG9w YXF1ZSBsYXllciBpZGVudGlmaWVycy4mbmJzcDsgUHV0dGluZyBub24tbGF5ZXIgYml0cyBpbnRv IHRoZSBMSUQgZmllbGQgd291bGQgYnJlYWsgdGhpcyBnb2FsLjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCkF0IHRoZSBJRVRGIG1lZXRpbmcgaW4gQ2hpY2FnbywgYm90aCBCZXJuYXJkIEFi b2JhIGFuZCBJIHRob3VnaHQgdGhhdCBmcmFtZSBtYXJraW5nIG1pZ2h0IG5lZWQgZW5oYW5jZW1l bnRzIGluIG9yZGVyIGZvciBzcGF0aWFsIHNjYWxhYmlsaXR5IHRvIGJlIGZ1bGx5IHN1cHBvcnRl ZC4gSeKAmW0gYWRkaW5nIGhpbSB0byB0aGUgQ2MsIGFzIHdlbGwgYXMgbXkgY28tYXV0aG9ycyBv biB0aGUgVlA5IHBheWxvYWQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU2VyZ2lvLCBp ZiB5b3Ugd2FudCB0byBzZW5kIGEgcHVsbCByZXF1ZXN0IHRvIGNvbnRyaWJ1dGUgdGV4dCBmb3Ig dGhlIFZQOSBzcGVjICh3aGljaCB3b3VsZCBiZSB3ZWxjb21lKSwgaXTigJlzIGluIEdpdGh1YiBh dA0KPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2p1YmVydGkvZHJhdWdodHMiIHJlbD0ibm9y ZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9IiI+ DQpodHRwczovL2dpdGh1Yi5jb20vanViZXJ0aS9kcmE8d2JyIGNsYXNzPSIiPnVnaHRzPC9hPiAu PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPkN1cnJlbnRseSB0aGUgVlA5IExJ RCBtYXBwaW5nIGlzIGRlc2NyaWJlZCBvbiB0aGUgZnJhbWUgbWFya2luZyBkcmFmdCwgYW5kIG5v dCBpbiB0aGUgVlA5IGRyYWZ0LiBXZSBjb3VsZCBtb3ZlIHRoZSBmdWxsIGRlc2NyaXB0aW9uIGZy b20gb25lIHRleHQgdG8gYW5vdGhlciwgYnV0IGF0IGxlYXN0IGZvciBtZSwgaXQgd2FzIGVhc2ll ciB0byBwcm92aWRlIGEgc21hbGwgcGF0Y2ggZm9yIGN1cnJlbnQgZHJhZnQgdG8gYWRkcmVzcyBt eQ0KIGNvbW1lbnRzOjxzcGFuIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9tdXJpbGxvMTI4L2RyYWZ0LWJlcmdlci1hdnRl eHQtZnJhbWVtYXJraW5nL2NvbW1pdC8zNWNkYjIyOTEwODI1MWYxMmJjMWNkZjc3OTA5ZGY4M2E1 MWQzOTk0IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9 InRydWUiIGNsYXNzPSIiPmh0dHBzOi8vZ2l0aHViLmNvbS9tdXJpbGxvMTI4Lzx3YnIgY2xhc3M9 IiI+ZHJhZnQtYmVyZ2VyLWF2dGV4dC1mcmFtZW1hcmtpPHdiciBjbGFzcz0iIj5uZy9jb21taXQv MzVjZGIyMjkxMDgyNTFmMTJiYzE8d2JyIGNsYXNzPSIiPmNkZjc3OTA5ZGY4M2E1MWQzOTk0PC9h Pg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSSBoYXZlIG5vdCBmb3VuZCB0aGUgLnht bCBpbiBhbnkgZ2l0aHViIHJlcG8sIHNvIGp1c3QgZG93bmxvYWRlZCB0aGUgbGF0ZXN0IGRyYWZ0 IGFuZCBhcHBsaWVkIHRoZSBjaGFuZ2VzIG9uIHRvcCBvZiBpdC48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpQbGVhc2UsIGxldCBtZSBrbm93IHdoYXQgYXJlIHlvdXIgdmlld3MgYWJvdXQg aXQuPGJyIGNsYXNzPSIiPg0KPC9zcGFuPjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A3A2CACAFA2F4BA282090F5B556EA732vidyocom_-- From nobody Wed Jul 5 09:52:40 2017 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FFA131D7F for ; Wed, 5 Jul 2017 09:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84DXVCsbkYxj for ; Wed, 5 Jul 2017 09:52:36 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AED03131D7B for ; Wed, 5 Jul 2017 09:52:35 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id y70so127913977vky.3 for ; Wed, 05 Jul 2017 09:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=thKnWCgJTuuSOfwD1OnKoFSKR59Q4zVCV12l+4Qzdf0=; b=GAIeCfxDaT+aQG5kYTb0JH91XRl5FUyRykL7NZNzvJ91a2No0OgELFjihzlH9h3iD6 YX8eJZrrqgSlwat7LtE31DFj6wx+Hw5OV/8YrRh+ITcSEubqvIDxTbrtIoqcscPWe1pQ cgmjAAKQGiSqAwPWrvarUc2hwRCL7abWmB83LQ2E7o2+rbn7+sjuVmgcMZmOESdwPhrt a7rRiyokAppomnsXxya8IsVayLeYw2Ea0d9pG8jgKzFmTJkD0owvsucR5Q0OMzsGJ1vK rhfZEtvBTHyZ6hO3moZQFs2sGZnM17GpBk8NHXQD889PZ2NcxyxiudG521ytIhTWuO5Y 2d5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=thKnWCgJTuuSOfwD1OnKoFSKR59Q4zVCV12l+4Qzdf0=; b=d7lG+COp6ASZqOIYHAUU/e1nJZc1e/jlD0H+/4PIn/PweeJ+RFHrwOwPYr7USH8bd8 73gNx5cfu7fgil2WggiHgqI3KwF/RQsg/qzMZfCqLHZSJirqzF58BwrIJXtje/9XhGYO ytTZ5MfALIggamKOHVFNmumJOfyYZVG7qnGNo+WC/0v90fGb/FJOjW7LadXzxbow2y3v 4LY4nF5LbeJEgqeXGS3w85XB9rlwCEHGprhCTBRkm0Bm2Xjd+F914jIu722uEBDnm6MN Bm3BnWzCuspjKV37JplgY2hlIkYqrxBj7ORYmUlW4TDcs7nVy8rHo/2nsWQo/n7bjt2H 89Nw== X-Gm-Message-State: AKS2vOw/AV7UhCvpp1iwSyBF5e+A9ONfhWAPi/5tFiwt90SzU0EqmA/8 3OIsLtfII0El/N8DTNG60Fa1ccp7Cw== X-Received: by 10.31.209.134 with SMTP id i128mr24899757vkg.125.1499273554607; Wed, 05 Jul 2017 09:52:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.74.202 with HTTP; Wed, 5 Jul 2017 09:52:14 -0700 (PDT) In-Reply-To: References: <0b5c72c6-4f59-daba-f193-282ea10d1f07@gmail.com> <00166BCB-6452-4D72-B5DF-5A456B2304EF@vidyo.com> <9a4994d3-f033-e1da-7884-a55c31789c59@gmail.com> <30944D17-BEB9-4EC6-A97C-0700567563FB@vidyo.com> <918659db-1742-4dd4-6fa3-7d0797aa4582@gmail.com> <50b624f9-4ce7-099e-1730-1b3a0d986e69@cosmosoftware.io> From: Bernard Aboba Date: Wed, 5 Jul 2017 09:52:14 -0700 Message-ID: To: Jonathan Lennox Cc: Sergio Garcia Murillo , "Mo Zanaty (mzanaty)" , "avtext@ietf.org" , Alexandre GOUAILLARD Content-Type: multipart/alternative; boundary="001a114e3a90a4c389055394d37b" Archived-At: Subject: Re: [avtext] Frame marking & VP9 SVC X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 16:52:39 -0000 --001a114e3a90a4c389055394d37b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jonathan said: "the =E2=80=9Cdon=E2=80=99t use it with weird structures=E2=80=9D requireme= nt will make that sufficient," [BA] There are structures where the B bit will not provide enough information to indicate that upscaling is possible (e.g. B bit 0 would indicate that the frame doesn't depend solely on the base layer, but P and U bits would indicate upscaling is possible). A "weird structures requirement" is somewhat unnatural. If the structures are not illegal in the bitstream specification, encoders can generate them, and decoders will be required to be able to decode them. This can generate a mismatch between what SFUs are built to handle and what endpoints do. If the payload is encrypted, the SFU won't necessarily be able to detect a "weird" structure and it can't act based on the P and U bits, only the B bit. Even if the payload is unencrypted, the SFU may wish to function based on the frame marking header alone, so as to avoid parsing the payload for the P and U bits. On Wed, Jul 5, 2017 at 8:56 AM, Jonathan Lennox wrote: > Sergio =E2=80=94 the updated VP9 payload draft I submitted Monday include= s a > section describing its usage with frame marking. > > Let me know what you think? It changes the S and T fields to reflect the > latest VP9 and frame marking drafts, but it does not include the P or U > bits. > > I think the intention is that frame marking=E2=80=99s B bit will provide = a > coarser-grain version of what P and U do (and the =E2=80=9Cdon=E2=80=99t = use it with weird > structures=E2=80=9D requirement will make that sufficient, though that ma= y need to > be made more specific). What do you think? > > On Jun 28, 2017, at 10:23 AM, Sergio Garcia Murillo < > sergio.garcia.murillo@cosmosoftware.io> wrote: > > Yes, at least in VP9 SVC you can define how many temporal and how many > spatial layers do you want simultaneously in the encoding. Note also, tha= t > VP9 supports quality layers as spatial layers without any resolution > change, so the term "spatial layer" is used to represent both spatial and > quality layers. > BR > Sergio > On 28/06/2017 16:18, Bernard Aboba wrote: > > Sergio said: "So, shouldn't the LID reference to the spatial layer ID > only and omit the quality layer id completely? Also, the spatial layer id > is 3 bits on that draft." > > [BA] Question: In VP9 (or AV1, for that matter) is it possible to use > both spatial and quality scalability in the same encoding? > > On Wed, Jun 28, 2017 at 5:35 AM, Sergio Garcia Murillo < > sergio.garcia.murillo@cosmosoftware.io> wrote: > >> Hi all again, >> >> Did you had a chance to review the changes to add the VP9 SVC spatial >> layer information into the LID of the frame marking extension? (at >> https://github.com/murillo128/draft-berger-avtext-framemarki >> ng/commit/35cdb229108251f12bc1cdf77909df83a51d3994) >> >> Also, FYI, I have submitted a CL to libwebrtc to support framemarking >> extension. Currently it supports VP8, H264 and non-SVC VP9, but I would >> love to tackle VP9 SVC as soon as we get an agreement on the changes to = the >> LID: >> >> https://codereview.webrtc.org/2954503002/ >> >> Best regards >> Sergio >> >> >> On 24/04/2017 11:28, Sergio Garcia Murillo wrote: >> >>> On 18/04/2017 17:40, Jonathan Lennox wrote: >>> >>>> One of the goals of Frame Marking is that an SFU can be agnostic to th= e >>>> details of the layering, and just treat layer IDs as opaque layer >>>> identifiers. Putting non-layer bits into the LID field would break th= is >>>> goal. >>>> >>>> At the IETF meeting in Chicago, both Bernard Aboba and I thought that >>>> frame marking might need enhancements in order for spatial scalability= to >>>> be fully supported. I=E2=80=99m adding him to the Cc, as well as my co= -authors on >>>> the VP9 payload. >>>> >>>> Sergio, if you want to send a pull request to contribute text for the >>>> VP9 spec (which would be welcome), it=E2=80=99s in Github at >>>> https://github.com/juberti/draughts . >>>> >>> Currently the VP9 LID mapping is described on the frame marking draft, >>> and not in the VP9 draft. We could move the full description from one t= ext >>> to another, but at least for me, it was easier to provide a small patch= for >>> current draft to address my comments: >>> >>> https://github.com/murillo128/draft-berger-avtext-framemarki >>> ng/commit/35cdb229108251f12bc1cdf77909df83a51d3994 >>> >>> I have not found the .xml in any github repo, so just downloaded the >>> latest draft and applied the changes on top of it. >>> >>> Please, let me know what are your views about it. >>> >> >> >> >> >> > > > --001a114e3a90a4c389055394d37b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jonathan said:=C2=A0

"the =E2=80=9Cdon=E2=80=99t use it with weird structur= es=E2=80=9D requirement will make that sufficient,"
<= br>
[BA] There are structures where the B bit will not provide en= ough information to indicate that upscaling is possible (e.g. B bit 0 would= indicate that the frame doesn't depend solely on the base layer, but P= and U bits would indicate upscaling is possible).=C2=A0

A "weird structures requirement" is somewhat unnatural. If= the structures are not illegal in the bitstream specification, encoders ca= n generate them, and decoders will be required to be able to decode them. = =C2=A0


This can generate a mismatch= between what SFUs are built to handle and what endpoints do.=C2=A0 If the = payload is encrypted, the SFU won't necessarily be able to detect a &qu= ot;weird" structure and it can't act based on the P and U bits, on= ly the B bit. Even if the payload is unencrypted, the SFU may wish to funct= ion based on the frame marking header alone, so as to avoid parsing the pay= load for the P and U bits.=C2=A0




On Wed, Jul 5, 2017 at 8:56 AM, Jonathan Lennox <jonathan@vid= yo.com> wrote:
Sergio =E2=80=94 the updated VP9 payload draft I submitted Monday incl= udes a section describing its usage with frame marking.

Let me know what you think?=C2=A0 It changes the S and T fields to ref= lect the latest VP9 and frame marking drafts, but it does not include the P= or U bits.

I think the intention is that frame marking=E2=80=99s B bit will provi= de a coarser-grain version of what P and U do (and the =E2=80=9Cdon=E2=80= =99t use it with weird structures=E2=80=9D requirement will make that suffi= cient, though that may need to be made more specific).=C2=A0 What do you think?

On Jun 28, 2017, at 10:23 AM, Sergio Garcia Murillo <sergio.garcia= .murillo@cosmosoftware.io> wrote:

Yes, at least in VP9 SVC you can define how many temporal and how many s= patial layers do you want simultaneously in the encoding. Note also, that V= P9 supports quality layers as spatial layers without any resolution change,= so the term "spatial layer" is used to represent both spatial and quality layers.

BR
Sergio
On 28/06/2017 16:18, B= ernard Aboba wrote:
Sergio said: =C2=A0"So, shouldn't the LID reference to the spatial layer ID only and omit the quality layer id completely? Als= o, the spatial layer id is 3 bits on that draft."

[BA] Question: =C2=A0In VP9 (or AV1, for that matter) is it possible t= o use both spatial and quality scalability in the same encoding?

On Wed, Jun 28, 2017 at 5:35 AM, Sergio Garcia M= urillo <sergio.garcia.murillo@cosmosoftware.io> wrote:
Hi all again,

Did you had a chance to review the changes to add the VP9 SVC spatial layer= information into the LID of the frame marking extension? (at https://github.com/murillo128/draft-berger-avtext-framemarking/co= mmit/35cdb229108251f12bc1cdf77909df83a51d3994)

Also, FYI, I have submitted a CL to libwebrtc to support framemarking exten= sion. Currently it supports VP8, H264 and non-SVC VP9, but I would love to = tackle VP9 SVC as soon as we get an agreement on the changes to the LID:
https://codereview.webrtc.org/2954503002/

Best regards
Sergio


On 24/04/2017 11:28, Sergio Garcia Murillo wrote:
On 18/04/2017 17:40, Jonathan Lennox wrote:
One of the goals of Frame Marking is that an SFU can be agnostic to the det= ails of the layering, and just treat layer IDs as opaque layer identifiers.= =C2=A0 Putting non-layer bits into the LID field would break this goal.

At the IETF meeting in Chicago, both Bernard Aboba and I thought that frame= marking might need enhancements in order for spatial scalability to be ful= ly supported. I=E2=80=99m adding him to the Cc, as well as my co-authors on= the VP9 payload.

Sergio, if you want to send a pull request to contribute text for the VP9 s= pec (which would be welcome), it=E2=80=99s in Github at https://github.com/juberti/draughts .
Currently the VP9 LID mapping is described on the frame marking draf= t, and not in the VP9 draft. We could move the full description from one te= xt to another, but at least for me, it was easier to provide a small patch = for current draft to address my comments:

https://github.com/murillo128/draft-berger-avtext-framemar= king/commit/35cdb229108251f12bc1cdf77909df83a51d3994

I have not found the .xml in any github repo, so just downloaded the latest= draft and applied the changes on top of it.

Please, let me know what are your views about it.








--001a114e3a90a4c389055394d37b-- From nobody Wed Jul 5 10:30:37 2017 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A302131DA8 for ; Wed, 5 Jul 2017 10:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLwqO6hUpRl0 for ; Wed, 5 Jul 2017 10:30:27 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 231F4131DA6 for ; Wed, 5 Jul 2017 10:30:23 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id f67so120260857wmh.1 for ; Wed, 05 Jul 2017 10:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=tjTo9SPIf4LTQP9lIncrdR3IaW7kWdxftrwvDcnV09I=; b=U+qEVUA5Q98az7VqwB/v6ZS4/dz5EYwLU0au0z/Ugl/SOTo/37ZFHWUnPaoLPhlmKH /hptQLgDPUYVr8BFQSaSdGz8mXtdnqGxc9/rImpyD4ri+EzxWpl0Cr2QueqNODxzZH5S fhwOm/bdXUibxUpQF2yW+yBICjlGyb7l5Z5EScJtH8f10y3AIlrV5WA9jltumJ6ywSNb c/hV9vgfpi3WbrLo852rq2l3vMJQRL9oMr8zTs2/BG56uGFnJv9EzUhrJLh2c6LEaxzY dL4SYZJJdmh9CCCO3DrbFie+F16kblYNnxVRoMKoIqK/dlICG34qD9PWpNEDkG40ZxgJ dzwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=tjTo9SPIf4LTQP9lIncrdR3IaW7kWdxftrwvDcnV09I=; b=Ej6LBQvO6/9E7JQAofKryoZbxtecIITu6TiAGEKlWz7vKB+1Hvmssiy3J0Ln+3hqp2 FEbvR0XNBHn5MTtOUdLWtJcek7g+9GDQGqxfn8Boor3nqH6lPIs/1Lic5YS4OjWlk4kF W93YZspXf2sxfYzODb0BHRDsc69I/wqhoHtCBQlLWJaB2TRx3hXzD1rTwWIAsaltZIzx tLA4Apldl1cBm9qZKhvD54sEFC+NfO3PXgRyD8Sldb1pibHsMstdpv88CzIiBP4lKT76 Ui8O1toP70mTYgm52DoobyN550GXFbxhyLrqXNgy1/mvEqsowVI2X/Xo2ChBXyEjYVT8 WIMQ== X-Gm-Message-State: AKS2vOwSTwG9U9PKHj3Vi22l7LLukN98NE/oLLC6/SEozcolV60i1zrB sZhZy6U0aidei3jF3ao= X-Received: by 10.28.107.135 with SMTP id a7mr30334747wmi.117.1499275821623; Wed, 05 Jul 2017 10:30:21 -0700 (PDT) Received: from [192.168.1.43] (84.red-83-36-143.dynamicip.rima-tde.net. [83.36.143.84]) by smtp.googlemail.com with ESMTPSA id g63sm24015497wrd.11.2017.07.05.10.30.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jul 2017 10:30:20 -0700 (PDT) To: Jonathan Lennox , Sergio Garcia Murillo Cc: "avtext@ietf.org" , Alexandre GOUAILLARD References: <0b5c72c6-4f59-daba-f193-282ea10d1f07@gmail.com> <00166BCB-6452-4D72-B5DF-5A456B2304EF@vidyo.com> <9a4994d3-f033-e1da-7884-a55c31789c59@gmail.com> <30944D17-BEB9-4EC6-A97C-0700567563FB@vidyo.com> <918659db-1742-4dd4-6fa3-7d0797aa4582@gmail.com> <50b624f9-4ce7-099e-1730-1b3a0d986e69@cosmosoftware.io> From: Sergio Garcia Murillo Message-ID: Date: Wed, 5 Jul 2017 19:30:20 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [avtext] Frame marking & VP9 SVC X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 17:30:29 -0000 On 05/07/2017 17:56, Jonathan Lennox wrote: > Sergio — the updated VP9 payload draft I submitted Monday includes a > section describing its usage with frame marking. > > Let me know what you think? It changes the S and T fields to reflect > the latest VP9 and frame marking drafts, but it does not include the P > or U bits. > > I think the intention is that frame marking’s B bit will provide a > coarser-grain version of what P and U do (and the “don’t use it with > weird structures” requirement will make that sufficient, though that > may need to be made more specific). What do you think? An SFU requires both VP9 P and U bits in order to be able to do up and down switching. So the question is they can be mapped 1-to-1 to the frame marking I and B bits. If so, just adding that to the draft that the I and B bits on the frame marking extension must be filled with the values of the vp9 P and U bits ( I=!P , B=U), would work. By the way, I liked more the "layer frame" and "frame" vs "frame" "picture" (but it is just a personal preference), but I am not sure if there haven't been any typos on the renaming, I will have to review it in deep because there are some things that seems wrong at first glance (but I am probably wrong). Will send a new email if I find anything. Best regards Sergio From nobody Wed Jul 5 14:20:09 2017 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE53B131DE0 for ; Wed, 5 Jul 2017 14:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQ8Bo3QPYo_r for ; Wed, 5 Jul 2017 14:20:05 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 523AB1243F6 for ; Wed, 5 Jul 2017 14:20:05 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id r125so444029vkf.1 for ; Wed, 05 Jul 2017 14:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=A2rc42/YIlgtFL3ImCY38HXhEH1hx6fc/ewtq/Uk9ZM=; b=mEXOrsc34M5v15ArZpCJ5tyGqPPd6ks3Hrj005pxhfeTxdpuCa3VFPievO5aqKJqvd SCWeI+ouwi8rbZSNBJG1Q/rXSp6mpAGxiaij9s1EN1x9OuHq0pk2ywTzb8uSwevE81Tq jYUDkyhGQ/GOE0kyOjyEfB2a3lM8YWr8vHmWyhczZc6ALhP3ciMWyP5BKXhCu/KBnSUV pv+vn5yVANAXiUgzR/8CgA6kAr5iroe/yNel0S00dMZRnRWdYKkR6UfdRJ8wvFmyXNpt gbMVCCXH+4R2XY94i0dlN++C8JV2GU2+XQDbDn0oQ/Q+9XX7tJSPKH4sRDOug5i4ShCq ba4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=A2rc42/YIlgtFL3ImCY38HXhEH1hx6fc/ewtq/Uk9ZM=; b=KfRY82U4pQW8BoGRv7Wehx7fPLfR3G0TR3ekddCe3jgPt+OYqAiPSBjagTqHAEmmEy gTeFKbvUH/7CvoHGjk0D7BCN7JnxnNNy6uqTguDq+VVhZIWoAOdvijma2QzIHM66g6ep k8AGwKJx/hnum8gchfsiFjp11Kh/myveX07gBxQZGlgaigkYACmCNjkUmXEnQYkCTuog nTiRK3kh74uOA3yahMo1JcA3JBD0XL3R3EKL0SNB3nvS3PzkMXCXVqYLDuAv4naXKQeM XaM3xTAkwYOvTc60i2unZBtN0duczSWFtmdrSaSI+FVMVvdN4qKusO8pkheHTvrOia1n VrlQ== X-Gm-Message-State: AKS2vOycPzFtLsdNsG3kw3GF0W3+LnVb0Hcw7zict7iqyb57Qa9Nysg+ 2Tl7ru1L+xggNCLRs4AsMjL0kMJhwA== X-Received: by 10.31.182.130 with SMTP id g124mr25326488vkf.128.1499289604089; Wed, 05 Jul 2017 14:20:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.74.202 with HTTP; Wed, 5 Jul 2017 14:19:43 -0700 (PDT) In-Reply-To: References: <0b5c72c6-4f59-daba-f193-282ea10d1f07@gmail.com> <00166BCB-6452-4D72-B5DF-5A456B2304EF@vidyo.com> <9a4994d3-f033-e1da-7884-a55c31789c59@gmail.com> <30944D17-BEB9-4EC6-A97C-0700567563FB@vidyo.com> <918659db-1742-4dd4-6fa3-7d0797aa4582@gmail.com> <50b624f9-4ce7-099e-1730-1b3a0d986e69@cosmosoftware.io> From: Bernard Aboba Date: Wed, 5 Jul 2017 14:19:43 -0700 Message-ID: To: Sergio Garcia Murillo Cc: Jonathan Lennox , Sergio Garcia Murillo , "avtext@ietf.org" , Alexandre GOUAILLARD Content-Type: multipart/alternative; boundary="001a1143f2104471a40553989057" Archived-At: Subject: Re: [avtext] Frame marking & VP9 SVC X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 21:20:08 -0000 --001a1143f2104471a40553989057 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sergio said: "So the question is they can be mapped 1-to-1 to the frame marking I and B bits. If so, just adding that to the draft that the I and B bits on the frame marking extension must be filled with the values of the vp9 P and U bits ( I=3D!P , B=3DU), would work." [BA] It's not obvious to me that the P or U bits can be inferred from existing framemarking bits including the I and B bits. Consider the following dependency diagrams (done in the style of the examples in https://tools.ietf.org/html/draft-ietf-avtext-lrr ): Example 1 ... <-- S2 <-- S2 S2 <-- S2 <-- ... | | | | \/ \/ \/ \/ ... <-- S1 <-- S1 S1 <-- S1 <-- ... | | | | \/ \/ \/ \/ ... <-- S0 <-- S0 <-- S0 <-- S0 <-- ... 1 2 3 4 In this example, it looks to me like all the S0 frames have the B bit set to 1, but none of the S0, S1 or S2 frames have the I bit set to 1. Frames 3 S1 and S2 have the B bit set to 1, all other S1 and S2 frames have the B bit set to zero. It also looks to me like only frames 3 S1 and S2 have the P bit set to zero, all other S0, S1 and S2 frames have it set to 1. So there is no clear relationship between the I and P bits. Example 2 ... <-- S2 <-- S2 <-- S2 <-- S2 <-- ... | | | | \/ \/ \/ \/ ... <-- S1 <-- S1 <-- S1 <-- S1 <-- ... | | | | \/ \/ \/ \/ ... <-- S0 <-- S0 S0 <-- S0 <-- ... B B BIP B 1 2 3 4 In this example, it looks to me like all the S0 frames have the B bit set to 1, but only S0 frame 3 has the I bit set to 1. None of the S1 or S2 frames have the B or I bits set to 1. It also looks to me like none of the frames have the P bit set to 0 or the U bits set to 1, except frame 3 S0. So in this example, the I and P bits are the inverse of each other, but it's not clear how the U bit can be inferred from other bits. Here are the definitions of the framemarking I, D and B bits: o I: Independent Frame (1 bit) - MUST be 1 for frames that can be decoded independent of prior frames, e.g. intra-frame, VPX keyframe, H.264 IDR [RFC6184 ], H.265 IDR/CRA/BLA/RAP [RFC7798 ]; otherwise MUST be 0. o D: Discardable Frame (1 bit) - MUST be 1 for frames that can be discarded, and still provide a decodable media stream; otherwise MUST be 0. o B: Base Layer Sync (1 bit) - MUST be 1 if this frame only depends on the base layer; otherwise MUST be 0. If no scalability is used, this MUST be 0. Here are the P and U bit definitions: P: Inter-picture predicted layer frame. When set to zero, the layer frame does not utilize inter-picture prediction. In this case, up-switching to current spatial layer's frame is possible from directly lower spatial layer frame. P SHOULD also be set to zero when encoding a layer synchronization frame in response to an LRR [I-D.ietf-avtext-lrr ] message (see Section 5.4 ). When P is set to zero, the T bit (described below) MUST also be set to 0 (if present). U: Switching up point. If this bit is set to 1 for the current frame with temporal layer ID equal to T, then "switch up" to a higher frame rate is possible as subsequent higher temporal layer frames will not depend on any frame before the current frame (in coding time) with temporal layer ID greater than T. On Wed, Jul 5, 2017 at 10:30 AM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > On 05/07/2017 17:56, Jonathan Lennox wrote: > >> Sergio =E2=80=94 the updated VP9 payload draft I submitted Monday includ= es a >> section describing its usage with frame marking. >> >> Let me know what you think? It changes the S and T fields to reflect th= e >> latest VP9 and frame marking drafts, but it does not include the P or U >> bits. >> >> I think the intention is that frame marking=E2=80=99s B bit will provide= a >> coarser-grain version of what P and U do (and the =E2=80=9Cdon=E2=80=99t= use it with weird >> structures=E2=80=9D requirement will make that sufficient, though that m= ay need to >> be made more specific). What do you think? >> > > An SFU requires both VP9 P and U bits in order to be able to do up and > down switching. So the question is they can be mapped 1-to-1 to the frame > marking I and B bits. If so, just adding that to the draft that the I and= B > bits on the frame marking extension must be filled with the values of the > vp9 P and U bits ( I=3D!P , B=3DU), would work. > > By the way, I liked more the "layer frame" and "frame" vs "frame" > "picture" (but it is just a personal preference), but I am not sure if > there haven't been any typos on the renaming, I will have to review it in > deep because there are some things that seems wrong at first glance (but = I > am probably wrong). Will send a new email if I find anything. > > Best regards > Sergio > > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext > --001a1143f2104471a40553989057 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sergio said:=C2=A0

"So the question is they can be mapped 1-to-1 to the fram= e marking I and B bits. If so, just adding that to the draft that the I and= B bits on the frame marking extension must be filled with the values of th= e vp9 P and U bits ( I=3D!P , B=3DU), would work."
[BA] It's not obvious to me that the P or U bits can be in= ferred from existing framemarking bits including the I and B bits.=C2=A0 Co= nsider the following dependency diagrams (done in the style of the examples= in https://t= ools.ietf.org/html/draft-ietf-avtext-lrr ):=C2=A0

<= div>
Example 1


        ... <--  S2  <--  S2       S2  &l=
t;--  S2  <-- ...
                  |        |        |        |

                                 \/          =
    \/               \/              \/

        ... <--  S1  <--  S1    =
   S1  <--  S1  <-- ...
                  |        |        |        |
                 \/       \/       \/       \/
        ... <--  S0  <--  S0  <--  S0  <--  S0  <-- ...

                  1        2        3        4


In this example, it loo=
ks to me like all the S0 frames have the B bit set to 1, but none of the S0=
, S1 or S2 frames have the I bit set to 1. 
Frames 3 S1 and S2 have the B bit set to 1, all other S1 and S2 fra=
mes have the B bit set to zero.  
=

It also looks to me like only f=
rames 3 S1 and S2 have the P bit set to zero, all other S0, S1 and S2 frame=
s have it set to 1.
So there is no c=
lear relationship between the I and P bits.


Example 2

= 

        ... <--  S=
2  <--  S2  <--  S2  <--  S2  <-- ...
                  |        |        |        |

                                 \/          =
    \/               \/              \/
        ... <--  S1  <--  S1  <--  S1  <--  S1  <=
-- ...
                  |        |        |        |
                 \/       \/       \/       \/
        ... <--  S0  <--  S0       S0  <--  S0  <-- ...

                  B        B       BIP      B


                  1        2        3        4



In this example, it looks to me lik=
e all the S0 frames have the B bit set to 1, but only S0 frame 3 has the I =
bit set to 1. 
None of the S1 or S2 =
frames have the B or I bits set to 1.  It also looks to me like none of the=
 frames have the P bit set to 0 or the U
bits set to 1, except frame 3 S0.  So in this example, the I and P bit=
s are the inverse of each other, but it's not clear how the
U bit can be inferred from other bits.

Here are the definitions of the framemarking I, D a= nd B bits:=C2=A0

   =20
   o  I: Independent Frame (1 bit) - MUST be 1 for frames that can be
      decoded independent of prior frames, e.g. intra-frame, VPX
      keyframe, H.264 IDR [RFC6184], H.26=
5 IDR/CRA/BLA/RAP [RF=
C7798];
      otherwise MUST be 0.
   o  D: Discardable Frame (1 bit) - MUST be 1 for frames that can be
      discarded, and still provide a decodable media stream; otherwise
      MUST be 0.
   o  B: Base Layer Sync (1 bit) - MUST be 1 if this frame only depends
      on the base layer; otherwise MUST be 0.  If no scalability is
      used, this MUST be 0.


Here are the P and U bit definitions:=C2=A0

   P: Inter-picture predicted=
 layer frame.  When set to zero, the layer
      frame does not utilize inter-picture prediction.  In this case,
      up-switching to current spatial layer's frame is possible from
      directly lower spatial layer frame.  P SHOULD also be set to zero
      when encoding a layer synchronization frame in response to an LRR
      [I-D.ietf-avtext-lrr] message (s=
ee Section 5.4).  When P is set to
      zero, the T bit (described below) MUST also be set to 0 (if
      present).


   U: Swi=
tching up point.  If this bit is set to 1 for the current
      frame with temporal layer ID equal to T, then "switch up" t=
o a
      higher frame rate is possible as subsequent higher temporal
      layer frames will not depend on any frame before the current
      frame (in coding time) with temporal layer ID greater than T.



On Wed, Jul 5, 2017 at 10:30 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
On 05/07/2017 17:56, Jonathan Lennox = wrote:
Sergio =E2=80=94 the updated VP9 payload draft I submitted Monday includes = a section describing its usage with frame marking.

Let me know what you think?=C2=A0 It changes the S and T fields to reflect = the latest VP9 and frame marking drafts, but it does not include the P or U= bits.

I think the intention is that frame marking=E2=80=99s B bit will provide a = coarser-grain version of what P and U do (and the =E2=80=9Cdon=E2=80=99t us= e it with weird structures=E2=80=9D requirement will make that sufficient, = though that may need to be made more specific).=C2=A0 What do you think?

An SFU requires both VP9=C2=A0 P and U bits in order to be able to do up an= d down switching. So the question is they can be mapped 1-to-1 to the frame= marking I and B bits. If so, just adding that to the draft that the I and = B bits on the frame marking extension must be filled with the values of the= vp9 P and U bits ( I=3D!P , B=3DU), would work.

By the way, I liked more the "layer frame" and "frame" = vs "frame" "picture" (but it is just a personal prefere= nce), but I am not sure if there haven't been any typos on the renaming= , I will have to review it in deep because there are some things that seems= wrong at first glance (but I am probably wrong). Will send a new email if = I find anything.

Best regards
Sergio

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

--001a1143f2104471a40553989057-- From nobody Wed Jul 5 14:41:33 2017 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA69F12ECB4 for ; Wed, 5 Jul 2017 14:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3dkC_bx7WfV for ; Wed, 5 Jul 2017 14:41:24 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA61212EC27 for ; Wed, 5 Jul 2017 14:41:23 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id k67so2477471wrc.2 for ; Wed, 05 Jul 2017 14:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=3xPn8rVEKVZhOYJThuwAyQk3AaBORselg1azqzU9B7Y=; b=B+w5xl3UZoEuBYzj7aEeTWWqg15fKRNBW60wWrNCfjLeHm3UDVMcs80f3OplPjxauA wcYJfuUq9u6WO48E0wMnQH8PPLM121WjnrMwdt/IyOYsdH1VmR2ryowYwTkLUSCCw74L 2e0VOX0Qf3RUMzYRYMXdWGucy15ba5J6L9d2ssXon0XZ+likIuV/JwtA0WimD+xqsRTM vxFhYYeLlka7Tvay+NsJBZ5vqP4KdrzMFRP1zUS5boC/dz/wwql6zboP6SHjgyjpTw/U IYeSGmEDtrBVTn6YmpI+dwJfaBsQKC5iYxm38+IIRvUiVaIjQog4XlKH7ZguAl61oos/ WCtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=3xPn8rVEKVZhOYJThuwAyQk3AaBORselg1azqzU9B7Y=; b=lL3076RwqirtJnZu7XNk+PP/HGmEXsTQu0Mr4hGSkr5v4RNa4A4vg3o1vQj21Q35R/ ZAUM3A/AbaAX+lKEIomkySvIuUjU9zBGLlXt8iKgE6BjczydFvzU19u7kO7t8mSpOdth 9IZNTy8+rp/S2KERBi7An58iT4lIpTqYeSngoteiIW3Nj8jKV8tPc0jPLHK3jYfFhn+U AvkaxIyXqbfgocPFGxsbpb5MtOx/dAq5I7FS0PimCGQ/GY8d7ZCdpVe8Pt/IVRlyq7Ec mMo5xk3w/bNBnMXjNhFyxvjjqNl2H0NA2FPLHYo62G0R5hHn7HRUf+jIzFnvp3TeMnwy G+QQ== X-Gm-Message-State: AKS2vOy26oSryRQNNhEm/wdDG3hry0rOS+HfOpbrOfU6fEYTVrL28iFl 2QgPWyT2ir2BNg== X-Received: by 10.28.51.212 with SMTP id z203mr35391776wmz.103.1499290882261; Wed, 05 Jul 2017 14:41:22 -0700 (PDT) Received: from [192.168.0.199] (static-96-42-229-77.ipcom.comunitel.net. [77.229.42.96]) by smtp.googlemail.com with ESMTPSA id 3sm114302wrs.18.2017.07.05.14.41.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 05 Jul 2017 14:41:16 -0700 (PDT) To: Bernard Aboba Cc: Jonathan Lennox , Sergio Garcia Murillo , "avtext@ietf.org" , Alexandre GOUAILLARD References: <0b5c72c6-4f59-daba-f193-282ea10d1f07@gmail.com> <00166BCB-6452-4D72-B5DF-5A456B2304EF@vidyo.com> <9a4994d3-f033-e1da-7884-a55c31789c59@gmail.com> <30944D17-BEB9-4EC6-A97C-0700567563FB@vidyo.com> <918659db-1742-4dd4-6fa3-7d0797aa4582@gmail.com> <50b624f9-4ce7-099e-1730-1b3a0d986e69@cosmosoftware.io> From: Sergio Garcia Murillo Message-ID: <9685e097-2255-c439-6c42-c268cac4d48f@gmail.com> Date: Wed, 5 Jul 2017 23:41:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------20C838D3AA976F9032637A64" Content-Language: en-US Archived-At: Subject: Re: [avtext] Frame marking & VP9 SVC X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 21:41:26 -0000 This is a multi-part message in MIME format. --------------20C838D3AA976F9032637A64 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 05/07/2017 23:19, Bernard Aboba wrote: > Sergio said: > > "So the question is they can be mapped 1-to-1 to the frame marking I > and B bits. If so, just adding that to the draft that the I and B bits > on the frame marking extension must be filled with the values of the > vp9 P and U bits ( I=!P , B=U), would work." > > [BA] It's not obvious to me that the P or U bits can be inferred from > existing framemarking bits including the I and B bits. I agree, it is far from obvious.. :) The point is that there is no easy way of calculating the B bit on frame marking for VP9 (you would need to process the SS to calculate it as you have done in the examples, but that info is not provided by the encoder neither present on the desc header), so the only close-enough info would be the U bit. If we "redefine" it's meaning for VP9 it could work. Regarding the P bit, in prev draft the information was per layer-frame, now with the renaming, it is per picture. Not sure if it is a typo, or it has changed it's meaning, but if so, that would be exactly the inverse of the I bit. Best regards Sergio --------------20C838D3AA976F9032637A64 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 05/07/2017 23:19, Bernard Aboba wrote:
Sergio said: 

"So the question is they can be mapped 1-to-1 to the frame marking I and B bits. If so, just adding that to the draft that the I and B bits on the frame marking extension must be filled with the values of the vp9 P and U bits ( I=!P , B=U), would work."

[BA] It's not obvious to me that the P or U bits can be inferred from existing framemarking bits including the I and B bits.

I agree, it is far from obvious.. :)

The point is that there is no easy way of calculating the B bit on frame marking for VP9 (you would need to process the SS to calculate it as you have done in the examples, but that info is not provided by the encoder neither present on the desc header), so the only close-enough info would be the U bit. If we "redefine" it's meaning for VP9 it could work.

Regarding the P bit, in prev draft the information was per layer-frame, now with the renaming, it is per picture. Not sure if it is a typo, or it has changed it's meaning, but if so, that would be exactly the inverse of the I bit.

Best regards
Sergio
--------------20C838D3AA976F9032637A64-- From nobody Wed Jul 5 15:17:46 2017 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601BB12F3D0; Wed, 5 Jul 2017 15:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0khDtS6zNoWu; Wed, 5 Jul 2017 15:17:43 -0700 (PDT) Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23646127333; Wed, 5 Jul 2017 15:17:43 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v65MGY2u028341; Wed, 5 Jul 2017 18:17:39 -0400 Received: from mail.vidyo.com (mail2.vidyo.com [162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 2be6g43y17-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 05 Jul 2017 18:17:39 -0400 Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Wed, 5 Jul 2017 17:17:38 -0500 From: Jonathan Lennox To: Sergio Garcia Murillo CC: Bernard Aboba , Sergio Garcia Murillo , "avtext@ietf.org" , "payload@ietf.org" , "Alexandre GOUAILLARD" Thread-Topic: VP9 P bit (was Re: [avtext] Frame marking & VP9 SVC) Thread-Index: AQHS9dyCSeJ3RymXI0WSORtztATA3g== Date: Wed, 5 Jul 2017 22:17:38 +0000 Message-ID: <0F54961F-C28B-4CC3-9F6C-E63C417FB3F0@vidyo.com> References: <0b5c72c6-4f59-daba-f193-282ea10d1f07@gmail.com> <00166BCB-6452-4D72-B5DF-5A456B2304EF@vidyo.com> <9a4994d3-f033-e1da-7884-a55c31789c59@gmail.com> <30944D17-BEB9-4EC6-A97C-0700567563FB@vidyo.com> <918659db-1742-4dd4-6fa3-7d0797aa4582@gmail.com> <50b624f9-4ce7-099e-1730-1b3a0d986e69@cosmosoftware.io> <9685e097-2255-c439-6c42-c268cac4d48f@gmail.com> In-Reply-To: <9685e097-2255-c439-6c42-c268cac4d48f@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [160.79.219.114] Content-Type: text/plain; charset="utf-8" Content-ID: <358B325A35ED5B41BC31580C8323DE38@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-07-05_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1707050364 Archived-At: Subject: [avtext] VP9 P bit (was Re: Frame marking & VP9 SVC) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jul 2017 22:17:44 -0000 QWRkaW5nIHBheWxvYWRAaWV0Ziwgc2luY2UgZGV0YWlscyBvZiB0aGUgVlA5IHNwZWMgaXRzZWxm IChhcyBvcHBvc2VkIHRvIGhvdyBpdOKAmXMgdXNlZCB3aXRoIGZyYW1lIG1hcmtpbmcpIHNob3Vs ZCBiZSBkaXNjdXNzZWQgdGhlcmUuICBQbGVhc2UgcmVzdHJpY3QgZm9sbG93dXBzIGFzIGFwcHJv cHJpYXRlLg0KDQo+IE9uIEp1bCA1LCAyMDE3LCBhdCA1OjQxIFBNLCBTZXJnaW8gR2FyY2lhIE11 cmlsbG8gPHNlcmdpby5nYXJjaWEubXVyaWxsb0BnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4gUmVn YXJkaW5nIHRoZSBQIGJpdCwgaW4gcHJldiBkcmFmdCB0aGUgaW5mb3JtYXRpb24gd2FzIHBlciBs YXllci1mcmFtZSwgbm93IHdpdGggdGhlIHJlbmFtaW5nLCBpdCBpcyBwZXIgcGljdHVyZS4gTm90 IHN1cmUgaWYgaXQgaXMgYSB0eXBvLCBvciBpdCBoYXMgY2hhbmdlZCBpdCdzIG1lYW5pbmcsIGJ1 dCBpZiBzbywgdGhhdCB3b3VsZCBiZSBleGFjdGx5IHRoZSBpbnZlcnNlIG9mIHRoZSBJIGJpdC4N Cg0KVGhpcyB3YXMgYSB0eXBvLCB5ZXMuIFRoYW5rcyBmb3IgY2F0Y2hpbmcgaXQhICBJ4oCZbGwg Zml4IGl0IGluIHRoZSBuZXh0IHZlcnNpb24uIChOb3RpY2UgdGhhdCB0aGVyZeKAmXMgYSBsb3Qg b2Ygb3RoZXIgdGV4dCBhcm91bmQgdGhhdCBkZWZpbml0aW9uIHRoYXQgZG9lc27igJl0IG1ha2Ug YW55IHNlbnNlIGlmIFAgaXMgcGVyLXBpY3R1cmUuKQ0KDQpPbiB0aGUgcmVhc29ucyBmb3IgdGhl IHRlcm1pbm9sb2d5IGNoYW5nZTog4oCcc3VwZXIgZnJhbWXigJ0gYWxyZWFkeSBtZWFucyBzb21l dGhpbmcgKGRpZmZlcmVudCkgaW4gVlA5LCBzbyByZXVzaW5nIHRoZSB0ZXJtIHdhcyBwcm9ibGVt YXRpYy4gIEFkZGl0aW9uYWxseSwgd2hhdCB3ZSBub3cgY2FsbCDigJxmcmFtZeKAnSBpcyBleGFj dGx5IHdoYXQgdGhlIFZQOSBjb2RlYyBzdGFuZGFyZCBtZWFucyBieSDigJxmcmFtZeKAnSwgaS5l LiBhIHNpbmdsZSBlbmNvZGVkIGltYWdlLg== From nobody Fri Jul 7 13:47:44 2017 Return-Path: X-Original-To: avtext@ietfa.amsl.com Delivered-To: avtext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB71E131530; Fri, 7 Jul 2017 13:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEvUUWixfOj4; Fri, 7 Jul 2017 13:47:41 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 996A51200FC; Fri, 7 Jul 2017 13:47:40 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v67Kld0s073709 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 7 Jul 2017 15:47:40 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <11EFCCC3-9344-4DEF-9627-B9F11136988B@vidyo.com> Date: Fri, 7 Jul 2017 15:47:38 -0500 Cc: "avtext@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8B0FD027-D1BF-4A32-8AA6-3E617EAAE0C5@nostrum.com> References: <149903911109.4958.12599646407052332539@ietfa.amsl.com> <11EFCCC3-9344-4DEF-9627-B9F11136988B@vidyo.com> To: draft-ietf-avtext-lrr.all@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [avtext] I-D Action: draft-ietf-avtext-lrr-07.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 20:47:43 -0000 I just approved this version. Thanks for all the work! Ben. > On Jul 2, 2017, at 7:02 PM, Jonathan Lennox = wrote: >=20 > This version addresses comments during IESG Review. >=20 > The technical changes are=20 > 1) it=E2=80=99s now required to discard LRRs whose TLID or TTID is = lower than CLID / CTID =E2=80=94 before this was forbidden for senders = but receivers=E2=80=99 behavior was unspecified; and > 2) its mux category is specified as IDENTICAL-PER-PT, as previously = mentioned on the list. >=20 > There are also a number of editorial clarifications. >=20 >=20 >> On Jul 2, 2017, at 7:45 PM, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Audio/Video Transport Extensions of = the IETF. >>=20 >> Title : The Layer Refresh Request (LRR) RTCP Feedback = Message >> Authors : Jonathan Lennox >> Danny Hong >> Justin Uberti >> Stefan Holmer >> Magnus Flodman >> Filename : draft-ietf-avtext-lrr-07.txt >> Pages : 15 >> Date : 2017-07-02 >>=20 >> Abstract: >> This memo describes the RTCP Payload-Specific Feedback Message = "Layer >> Refresh Request" (LRR), which can be used to request a state refresh >> of one or more substreams of a layered media stream. It also = defines >> its use with several RTP payloads for scalable media formats. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-avtext-lrr/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-avtext-lrr-07 >> https://datatracker.ietf.org/doc/html/draft-ietf-avtext-lrr-07 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtext-lrr-07 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> avtext mailing list >> avtext@ietf.org >> https://www.ietf.org/mailman/listinfo/avtext >>=20 >=20 > _______________________________________________ > avtext mailing list > avtext@ietf.org > https://www.ietf.org/mailman/listinfo/avtext From nobody Fri Jul 7 14:47:01 2017 Return-Path: X-Original-To: avtext@ietf.org Delivered-To: avtext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C8A12EB9B; Fri, 7 Jul 2017 14:46:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.55.2 Auto-Submitted: auto-generated Precedence: bulk Cc: ben@nostrum.com, draft-ietf-avtext-lrr@ietf.org, avtext@ietf.org, rachel.huang@huawei.com, The IESG , avtext-chairs@ietf.org, Rachel Huang , rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149946400704.15151.13501885322948667370.idtracker@ietfa.amsl.com> Date: Fri, 07 Jul 2017 14:46:47 -0700 Archived-At: Subject: [avtext] Protocol Action: 'The Layer Refresh Request (LRR) RTCP Feedback Message' to Proposed Standard (draft-ietf-avtext-lrr-07.txt) X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.22 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 21:46:47 -0000 The IESG has approved the following document: - 'The Layer Refresh Request (LRR) RTCP Feedback Message' (draft-ietf-avtext-lrr-07.txt) as Proposed Standard This document is the product of the Audio/Video Transport Extensions Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-avtext-lrr/ Technical Summary: This document specifies a new RTCP payload-specific feedback mssage to allow a receiver of a layered media stream to request one or more of its substreams to be refereshed without requiring the entire stream to be refreshed. This new message can be used for both temporally and spatially scaled streams. This document also defines its use with several RTP payloads for scalable media formats. Working Group Summary: The WG is happy with current version. No technical comments are received. Document Quality: The document got some reviews from AVT experts, and enough discussions during the meetings. There exist widely deployed implementations of the FIR message specified in RFC5104. This draft introduces a new request for layered codecs either spatially or temporally to avoid unnecessary information obtained by FIR. This is expected to be a very useful implementation when used with scaled streams, for example, streams with H.264 SVC. Personnel: Document Shepherd: Rachel Huang Responsible AD: Ben Campell