From nobody Fri Sep 1 07:28:02 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54D31341DB for ; Fri, 1 Sep 2017 07:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H2=-2.8, 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 Mx8lqnGUovwD for ; Fri, 1 Sep 2017 07:27:59 -0700 (PDT) Received: from smtp65.iad3a.emailsrvr.com (smtp65.iad3a.emailsrvr.com [173.203.187.65]) (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 559B71341DA for ; Fri, 1 Sep 2017 07:27:56 -0700 (PDT) Received: from smtp33.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp33.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 8E436554D for ; Fri, 1 Sep 2017 10:27:51 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp33.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 5D9A256A1 for ; Fri, 1 Sep 2017 10:27:51 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 01 Sep 2017 10:27:51 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 1 Sep 2017 08:27:50 -0600 References: To: avt@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [AVTCORE] Review of draft-ietf-avtext-framemarking-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 14:28:01 -0000 > On Sep 1, 2017, at 8:23 AM, Cullen Jennings wrote: >=20 > I read this draft and did not see any issues. Where are we with this = draft and what happens next ? >=20 >=20 From nobody Fri Sep 1 08:26:51 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DA2133276 for ; Fri, 1 Sep 2017 07:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 RYQGRFlm9bwV for ; Fri, 1 Sep 2017 07:23:28 -0700 (PDT) Received: from smtp99.iad3a.emailsrvr.com (smtp99.iad3a.emailsrvr.com [173.203.187.99]) (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 7E596132D9B for ; Fri, 1 Sep 2017 07:23:28 -0700 (PDT) Received: from smtp13.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 9915C5524; Fri, 1 Sep 2017 10:23:27 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp13.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 5BAB7563B; Fri, 1 Sep 2017 10:23:27 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Fri, 01 Sep 2017 10:23:27 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 1 Sep 2017 08:23:26 -0600 Message-Id: To: avtext@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: X-Mailman-Approved-At: Fri, 01 Sep 2017 08:26:49 -0700 Subject: [AVTCORE] Review of draft-ietf-avtext-framemarking-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 14:23:29 -0000 I read this draft and did not see any issues. Where are we with this = draft and what happens next ? From nobody Fri Sep 1 15:15:06 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B35B9134509 for ; Fri, 1 Sep 2017 15:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.621 X-Spam-Level: X-Spam-Status: No, score=-12.621 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 RcOMBNeoGPSp for ; Fri, 1 Sep 2017 15:15:04 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E26BE132E10 for ; Fri, 1 Sep 2017 15:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1512; q=dns/txt; s=iport; t=1504304103; x=1505513703; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UuOhXKYW+/3W22SiMH1ZqNdKLQ3kDMKhXnOe1OnJa00=; b=Rjdwhvrq324EWP9ii9r79usnoDv9bfbco5uIagjyx2stXUjptX/Ktb60 uv/6cc2yUTY7cdRzIsGyhCIuTfjCshyEKrKPWXt6wmcFSzIJt3/qL7y8n TpVcmyQQLRxW6YLUN+0v6M6wozOOQ27eySSNT8sxWbFegtaGxx43Mxj1m 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmAADf2qlZ/5BdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1qBeQeOEJAggXGWKIIShUcChBU/GAECAQEBAQEBAWsohRgBAQE?= =?us-ascii?q?BAgE6PwULAgEIDgoeEDIlAgQBDQWKKQixa4tVAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBHYMqggKBToFjgyiBPIktBaBzApRPghOJZIZ5lkYBHziBDXcVhWEMEIFndol?= =?us-ascii?q?wgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,459,1498521600"; d="scan'208";a="279978395" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Sep 2017 22:15:02 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v81MF14w006036 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Sep 2017 22:15:02 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 1 Sep 2017 17:15:01 -0500 Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1263.000; Fri, 1 Sep 2017 17:15:00 -0500 From: "Mo Zanaty (mzanaty)" To: Cullen Jennings , Jonathan Lennox , Sergio Garcia Murillo , Bernard Aboba CC: "avt@ietf.org" Thread-Topic: [AVTCORE] Review of draft-ietf-avtext-framemarking-05 Thread-Index: AQHTI2/AlRfq5gy5XUmfnaT3Kk3Sbw== Date: Fri, 1 Sep 2017 22:15:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.170.90] Content-Type: text/plain; charset="us-ascii" Content-ID: <4B13A4816E0D254883719D64F22E3A09@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [AVTCORE] Review of draft-ietf-avtext-framemarking-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 22:15:06 -0000 Thanks for bumping this, Cullen. At IETF 99, it was decided that priority marking beyond the Discardable bit should go in a separate draft. Roni submitted draft-even-avtcore-priority-markings for this. So that is closed. The only other open issue was the mapping of the VP9 U/P bits to the frame marking B/I bits. In version 05 of frame marking, we already moved VP9 LID/TID mappings to the VP9 RTP payload draft. If the frame marking B/I bits are sufficient for the needs of VP9 SVC applications, then the mapping of VP9 U/P bits to frame marking B/I bits should also be documented in the VP9 draft rather than frame marking, and we can request WGLC for frame marking without waiting for the VP9 draft updates. If the frame marking B/I bits are insufficient, or if their definition needs to be altered to support VP9 SVC applications, and the WG feels those applications are important, then we need to finalize any changes needed for frame marking B/I bits ASAP then start WGLC. Jonathan, Sergio, Bernard, You expressed interest in VP9 SVC applications. Are the frame marking B/I bits sufficient for your needs? If not, what are the specific issues we need to address? Is it only switching up to a higher spatial layer when there are multiple spatial enhancement layers? Thanks, Mo =20 > On Sep 1, 2017, at 8:23 AM, Cullen Jennings wrote: >=20 > I read this draft and did not see any issues. Where are we with this >draft and what happens next ? >=20 >=20 From nobody Thu Sep 7 13:29:30 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE23132FCE for ; Thu, 7 Sep 2017 13:29:29 -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 m8Cd5Eqv0UQp for ; Thu, 7 Sep 2017 13:29:28 -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 171BE132D0D for ; Thu, 7 Sep 2017 13:29:28 -0700 (PDT) Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v87KTBI1003748; Thu, 7 Sep 2017 16:29:23 -0400 Received: from mail.vidyo.com (mail2.vidyo.com [162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 2cqqd9m80j-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 07 Sep 2017 16:29:21 -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; Thu, 7 Sep 2017 15:29:20 -0500 From: Jonathan Lennox To: "Mo Zanaty (mzanaty)" CC: Cullen Jennings , Sergio Garcia Murillo , Bernard Aboba , IETF AVTCore WG Thread-Topic: [AVTCORE] Review of draft-ietf-avtext-framemarking-05 Thread-Index: AQHTI2/AlRfq5gy5XUmfnaT3Kk3Sb6KqPOiA Date: Thu, 7 Sep 2017 20:29:19 +0000 Message-ID: <37C2005E-B429-4E39-BC1C-9ED68E9411E4@vidyo.com> References: 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_37C2005EB4294E39BC1C9ED68E9411E4vidyocom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-09-07_12:, , 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-1707230000 definitions=main-1709070304 Archived-At: Subject: Re: [AVTCORE] Review of draft-ietf-avtext-framemarking-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 20:29:29 -0000 --_000_37C2005EB4294E39BC1C9ED68E9411E4vidyocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGUgaXNzdWUgaXNu4oCZdCBzcGVjaWZpY2FsbHkgd2l0aCBWUDkgbWFwcGluZyBh cyBzdWNoLCBidXQgcmF0aGVyIHdpdGggdGhlIHNlbWFudGljcyB0aGF0IHRoZSBWUDkgcGF5bG9h ZOKAmXMgVSBhbmQgUCBiaXRzIGV4cHJlc3MuDQoNCkVzc2VudGlhbGx5LCBWUDnigJlzIFUgaW5k aWNhdGVzIHRoYXQgdGhpcyBpcyBhIHBvaW50IGF0IHdoaWNoIGEgTUFORSBjYW4gdmFsaWRseSBz dGFydCBzZW5kaW5nIGEgaGlnaGVyIHRlbXBvcmFsIGxheWVyLCBhbmQgUCBpbmRpY2F0ZXMgYSBw b2ludCBhdCB3aGljaCBhIE1BTkUgY2FuIHN0YXJ0IHNlbmRpbmcgYSBoaWdoZXIgc3BhdGlhbCBs YXllci4NCg0KSXTigJlzIG5vdCBjbGVhciB0byBtZSB0aGF0IGZyYW1lIG1hcmtpbmcgbWFrZXMg aXQgcG9zc2libGUgdG8gZXh0cmFjdCBlaXRoZXIgb2YgdGhlc2Ugc2VtYW50aWNzIGF0IHRoZSBt b21lbnQuDQoNClBvc3NpYmx5LCB0aGUgKHZhc3RseSB1bmRlcnNwZWNpZmllZCkgc3RhdGVtZW50 IGluIHNlY3Rpb24gMy40LjIsIHJlcXVpcmluZyB0aGF0IGZyYW1lIG1hcmtpbmcgbm90IGJlIHVz ZWQgZm9yIOKAnGNvbXBsZXggb3IgaXJyZWd1bGFy4oCdIHNjYWxhYmlsaXR5IHN0cnVjdHVyZXMs IG1lYW5zIHRoYXQgKGFtb25nIG90aGVyIHRoaW5ncykgYW55IHN0cmVhbSB1c2luZyBmcmFtZSBt YXJraW5nIG5lZWRzIHRvIGJlIHRlbXBvcmFsbHkgbmVzdGVkLiAgKFNlZSB0aGUgTFJSIGRyYWZ0 IGZvciBhIGRlZmluaXRpb24gb2YgdGVtcG9yYWwgbmVzdGluZykuICBJZiB0aGlzIGlzIHRoZSBj YXNlLCB0aGVuIFZQOeKAmXMgVSBiaXQgd291bGRu4oCZdCBuZWVkIG1hcHBpbmcg4oCUIGFueSBW UDkgc3RyZWFtIHdoaWNoIGNvdWxkIHZhbGlkbHkgaGF2ZSBmcmFtZSBtYXJraW5nIGFwcGxpZWQg dG8gaXQgd291bGQgYWx3YXlzIGhhdmUgdGhlIFUgYml0IHNldCB0byB0cnVlLCBhbmQgTUFORXMg Y291bGQgc3RhcnQgc2VuZGluZyB0ZW1wb3JhbCBsYXllcnMgYXQgYW55IHRpbWUuICBJ4oCZZCBi ZSBmaW5lIHdpdGggdGhpcyByZXN0cmljdGlvbiwgYnV0IGl0IHdvdWxkIG5lZWQgdG8gYmUgd3Jp dHRlbiBkb3duIGV4cGxpY2l0bHk7IGFuZCBJIGRvbuKAmXQgdW5kZXJzdGFuZCBldmVyeW9uZSBl bHNl4oCZcyB1c2UgY2FzZXMgd2VsbCBlbm91Z2ggdG8gYmUgc3VyZSB0aGF0IG5vIG9uZSBlbHNl IHdvdWxkIGhhdmUgYSBwcm9ibGVtIHdpdGggaXQuDQoNCkZvciB0aGUgUCBiaXQsIHRoZSBpc3N1 ZSBpcyBpbmRlZWQgYWJvdXQgc3BhdGlhbCBsYXllciBzd2l0Y2hpbmctdXAgcG9pbnRzLiAgQ29u c2lkZXIgdGhlIGZvbGxvd2luZyBzdHJlYW0gZW5jb2RlZCB3aXRoIHRocmVlIHNwYXRpYWwgbGF5 ZXJzOg0KDQogICAgICAgIC4uLiA8LS0gIFMyICA8LS0gIFMyICAgICAgIFMyKiA8LS0gIFMyICA8 LS0gLi4uDQogICAgICAgICAgICAgICAgICB8ICAgICAgICB8ICAgICAgICB8ICAgICAgICB8DQog ICAgICAgICAgICAgICAgIFwvICAgICAgIFwvICAgICAgIFwvICAgICAgIFwvDQogICAgICAgIC4u LiA8LS0gIFMxICA8LS0gIFMxICA8LS0gIFMxICA8LS0gIFMxICA8LS0gLi4uDQogICAgICAgICAg ICAgICAgICB8ICAgICAgICB8ICAgICAgICB8ICAgICAgICB8DQogICAgICAgICAgICAgICAgIFwv ICAgICAgIFwvICAgICAgIFwvICAgICAgIFwvDQouLi4gPC0tICBTMCAgPC0tICBTMCAgPC0tICBT MCAgPC0tICBTMCAgPC0tIC4uLg0KDQpUaGUgZnJhbWUgbWFya2VkIHdpdGggYW4gYXN0ZXJpc2sg aXMgYSBsYXllciByZWZyZXNoIHBvaW50IGZvciBsYXllciBTMiwgYW5kIGlzIGEgcG9pbnQgYXQg d2hpY2ggYSBNQU5FIHdoaWNoIHdhcyBwcmV2aW91c2x5IGZvcndhcmRpbmcganVzdCBsYXllciBT MSBjb3VsZCBzdGFydCBzZW5kaW5nIFMyIGFzIHdlbGwuICBUaGlzIGZyYW1lIHdvdWxkIGhhdmUg dGhlIFZQOSBQIGJpdCBzZXQuICBIb3dldmVyLCBhcyBJIHVuZGVyc3RhbmQgaXQsIGl0IHdvdWxk ICpub3QqIGhhdmUgdGhlIGZyYW1lIG1hcmtpbmcgQiBvciBJIGJpdHMgc2V0LCBub3IgYW55IG90 aGVyIGZpZWxkcyBpbiB0aGUgZnJhbWUgbWFya2luZyBoZWFkZXIgZXh0ZW5zaW9uIHdoaWNoIGRp c3Rpbmd1aXNoIGl0Lg0KDQpQb3NzaWJseSB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgQiBiaXQgY291 bGQgYmUgY2hhbmdlZCBzb21laG93IHRvIHByb3ZpZGUgdGhpcyBpbmZvcm1hdGlvbiwgYnV0IEkg ZmVlbCBsaWtlIHRoZSBjdXJyZW50IEIgYml0IHNlbWFudGljcyBwcm92aWRlcyBvdGhlciBmdW5j dGlvbmFsaXR5IChhYm91dCB0aGUgZGVjb2RhYmlsaXR5IG9mIG5vbiBiYXNlLXRlbXBvcmFsLWxh eWVyIGZyYW1lcyBmb2xsb3dpbmcgbG9zcykgd2hpY2ggd2UgZG9u4oCZdCB3YW50IHRvIGJyZWFr OyBJ4oCZbSBub3Qgc3VyZSBob3cgYmVzdCB0byBzcXVhcmUgdGhpcyBjaXJjbGUuDQoNCg0KT24g U2VwIDEsIDIwMTcsIGF0IDY6MTUgUE0sIE1vIFphbmF0eSAobXphbmF0eSkgPG16YW5hdHlAY2lz Y28uY29tPG1haWx0bzptemFuYXR5QGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpUaGFua3MgZm9yIGJ1 bXBpbmcgdGhpcywgQ3VsbGVuLg0KDQpBdCBJRVRGIDk5LCBpdCB3YXMgZGVjaWRlZCB0aGF0IHBy aW9yaXR5IG1hcmtpbmcgYmV5b25kIHRoZSBEaXNjYXJkYWJsZQ0KYml0IHNob3VsZCBnbyBpbiBh IHNlcGFyYXRlIGRyYWZ0LiBSb25pIHN1Ym1pdHRlZA0KZHJhZnQtZXZlbi1hdnRjb3JlLXByaW9y aXR5LW1hcmtpbmdzIGZvciB0aGlzLiBTbyB0aGF0IGlzIGNsb3NlZC4NCg0KVGhlIG9ubHkgb3Ro ZXIgb3BlbiBpc3N1ZSB3YXMgdGhlIG1hcHBpbmcgb2YgdGhlIFZQOSBVL1AgYml0cyB0byB0aGUg ZnJhbWUNCm1hcmtpbmcgQi9JIGJpdHMuIEluIHZlcnNpb24gMDUgb2YgZnJhbWUgbWFya2luZywg d2UgYWxyZWFkeSBtb3ZlZCBWUDkNCkxJRC9USUQgbWFwcGluZ3MgdG8gdGhlIFZQOSBSVFAgcGF5 bG9hZCBkcmFmdC4gSWYgdGhlIGZyYW1lIG1hcmtpbmcgQi9JDQpiaXRzIGFyZSBzdWZmaWNpZW50 IGZvciB0aGUgbmVlZHMgb2YgVlA5IFNWQyBhcHBsaWNhdGlvbnMsIHRoZW4gdGhlDQptYXBwaW5n IG9mIFZQOSBVL1AgYml0cyB0byBmcmFtZSBtYXJraW5nIEIvSSBiaXRzIHNob3VsZCBhbHNvIGJl DQpkb2N1bWVudGVkIGluIHRoZSBWUDkgZHJhZnQgcmF0aGVyIHRoYW4gZnJhbWUgbWFya2luZywg YW5kIHdlIGNhbiByZXF1ZXN0DQpXR0xDIGZvciBmcmFtZSBtYXJraW5nIHdpdGhvdXQgd2FpdGlu ZyBmb3IgdGhlIFZQOSBkcmFmdCB1cGRhdGVzLiBJZiB0aGUNCmZyYW1lIG1hcmtpbmcgQi9JIGJp dHMgYXJlIGluc3VmZmljaWVudCwgb3IgaWYgdGhlaXIgZGVmaW5pdGlvbiBuZWVkcyB0bw0KYmUg YWx0ZXJlZCB0byBzdXBwb3J0IFZQOSBTVkMgYXBwbGljYXRpb25zLCBhbmQgdGhlIFdHIGZlZWxz IHRob3NlDQphcHBsaWNhdGlvbnMgYXJlIGltcG9ydGFudCwgdGhlbiB3ZSBuZWVkIHRvIGZpbmFs aXplIGFueSBjaGFuZ2VzIG5lZWRlZA0KZm9yIGZyYW1lIG1hcmtpbmcgQi9JIGJpdHMgQVNBUCB0 aGVuIHN0YXJ0IFdHTEMuDQoNCkpvbmF0aGFuLCBTZXJnaW8sIEJlcm5hcmQsDQpZb3UgZXhwcmVz c2VkIGludGVyZXN0IGluIFZQOSBTVkMgYXBwbGljYXRpb25zLiBBcmUgdGhlIGZyYW1lIG1hcmtp bmcgQi9JDQpiaXRzIHN1ZmZpY2llbnQgZm9yIHlvdXIgbmVlZHM/IElmIG5vdCwgd2hhdCBhcmUg dGhlIHNwZWNpZmljIGlzc3VlcyB3ZQ0KbmVlZCB0byBhZGRyZXNzPyBJcyBpdCBvbmx5IHN3aXRj aGluZyB1cCB0byBhIGhpZ2hlciBzcGF0aWFsIGxheWVyIHdoZW4NCnRoZXJlIGFyZSBtdWx0aXBs ZSBzcGF0aWFsIGVuaGFuY2VtZW50IGxheWVycz8NCg0KVGhhbmtzLA0KTW8NCg0KDQpPbiBTZXAg MSwgMjAxNywgYXQgODoyMyBBTSwgQ3VsbGVuIEplbm5pbmdzIDxmbHVmZnlAaWlpLmNhPG1haWx0 bzpmbHVmZnlAaWlpLmNhPj4gd3JvdGU6DQoNCkkgcmVhZCB0aGlzIGRyYWZ0IGFuZCBkaWQgbm90 IHNlZSBhbnkgaXNzdWVzLiBXaGVyZSBhcmUgd2Ugd2l0aCB0aGlzDQpkcmFmdCBhbmQgd2hhdCBo YXBwZW5zIG5leHQgPw0KDQoNCg0KDQo= --_000_37C2005EB4294E39BC1C9ED68E9411E4vidyocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5JIHRoaW5r IHRoZSBpc3N1ZSBpc27igJl0IHNwZWNpZmljYWxseSB3aXRoIFZQOSBtYXBwaW5nIGFzIHN1Y2gs IGJ1dCByYXRoZXIgd2l0aCB0aGUgc2VtYW50aWNzIHRoYXQgdGhlIFZQOSBwYXlsb2Fk4oCZcyBV IGFuZCBQIGJpdHMgZXhwcmVzcy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkVzc2VudGlhbGx5LCBWUDnigJlzIFUgaW5kaWNhdGVzIHRo YXQgdGhpcyBpcyBhIHBvaW50IGF0IHdoaWNoIGEgTUFORSBjYW4gdmFsaWRseSBzdGFydCBzZW5k aW5nIGEgaGlnaGVyIHRlbXBvcmFsIGxheWVyLCBhbmQgUCBpbmRpY2F0ZXMgYSBwb2ludCBhdCB3 aGljaCBhIE1BTkUgY2FuIHN0YXJ0IHNlbmRpbmcgYSBoaWdoZXIgc3BhdGlhbCBsYXllci48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkl0 4oCZcyBub3QgY2xlYXIgdG8gbWUgdGhhdCBmcmFtZSBtYXJraW5nIG1ha2VzIGl0IHBvc3NpYmxl IHRvIGV4dHJhY3QgZWl0aGVyIG9mIHRoZXNlIHNlbWFudGljcyBhdCB0aGUgbW9tZW50LjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UG9z c2libHksIHRoZSAodmFzdGx5IHVuZGVyc3BlY2lmaWVkKSBzdGF0ZW1lbnQgaW4gc2VjdGlvbiAz LjQuMiwgcmVxdWlyaW5nIHRoYXQgZnJhbWUgbWFya2luZyBub3QgYmUgdXNlZCBmb3Ig4oCcY29t cGxleCBvciBpcnJlZ3VsYXLigJ0gc2NhbGFiaWxpdHkgc3RydWN0dXJlcywgbWVhbnMgdGhhdCAo YW1vbmcgb3RoZXIgdGhpbmdzKSBhbnkgc3RyZWFtIHVzaW5nIGZyYW1lIG1hcmtpbmcgbmVlZHMg dG8gYmUgdGVtcG9yYWxseQ0KIG5lc3RlZC4gJm5ic3A7KFNlZSB0aGUgTFJSIGRyYWZ0IGZvciBh IGRlZmluaXRpb24gb2YgdGVtcG9yYWwgbmVzdGluZykuICZuYnNwO0lmIHRoaXMgaXMgdGhlIGNh c2UsIHRoZW4gVlA54oCZcyBVIGJpdCB3b3VsZG7igJl0IG5lZWQgbWFwcGluZyDigJQgYW55IFZQ OSBzdHJlYW0gd2hpY2ggY291bGQgdmFsaWRseSBoYXZlIGZyYW1lIG1hcmtpbmcgYXBwbGllZCB0 byBpdCB3b3VsZCBhbHdheXMgaGF2ZSB0aGUgVSBiaXQgc2V0IHRvIHRydWUsIGFuZCBNQU5FcyBj b3VsZCBzdGFydA0KIHNlbmRpbmcgdGVtcG9yYWwgbGF5ZXJzIGF0IGFueSB0aW1lLiAmbmJzcDtJ 4oCZZCBiZSBmaW5lIHdpdGggdGhpcyByZXN0cmljdGlvbiwgYnV0IGl0IHdvdWxkIG5lZWQgdG8g YmUgd3JpdHRlbiBkb3duIGV4cGxpY2l0bHk7IGFuZCBJIGRvbuKAmXQgdW5kZXJzdGFuZCBldmVy eW9uZSBlbHNl4oCZcyB1c2UgY2FzZXMgd2VsbCBlbm91Z2ggdG8gYmUgc3VyZSB0aGF0IG5vIG9u ZSBlbHNlIHdvdWxkIGhhdmUgYSBwcm9ibGVtIHdpdGggaXQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Gb3IgdGhlIFAgYml0LCB0aGUg aXNzdWUgaXMgaW5kZWVkIGFib3V0IHNwYXRpYWwgbGF5ZXIgc3dpdGNoaW5nLXVwIHBvaW50cy4g Jm5ic3A7Q29uc2lkZXIgdGhlIGZvbGxvd2luZyBzdHJlYW0gZW5jb2RlZCB3aXRoIHRocmVlIHNw YXRpYWwgbGF5ZXJzOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgZm9udC1zaXplOiAxMXB4 OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogTWVubG87IGJhY2tncm91bmQtY29s b3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtdmFy aWFudC1saWdhdHVyZXM6IG5vLWNvbW1vbi1saWdhdHVyZXMiIGNsYXNzPSIiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyZuYnNwOy4uLiAmbHQ7LS0mbmJzcDsgUzImbmJzcDsgJmx0Oy0tJm5i c3A7IFMyICZuYnNwOyAmbmJzcDsgJm5ic3A7IFMyKiAmbHQ7LS0mbmJzcDsgUzImbmJzcDsgJmx0 Oy0tIC4uLjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6 IDExcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsgYmFja2dyb3Vu ZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9u dC12YXJpYW50LWxpZ2F0dXJlczogbm8tY29tbW9uLWxpZ2F0dXJlcyIgY2xhc3M9IiI+Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQt ZmFtaWx5OiBNZW5sbzsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm8tY29tbW9uLWxp Z2F0dXJlcyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBcLyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBcLyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBcLyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBcLzwvc3Bhbj48L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAy NTUpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm8t Y29tbW9uLWxpZ2F0dXJlcyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC4u LiAmbHQ7LS0mbmJzcDsgUzEmbmJzcDsgJmx0Oy0tJm5ic3A7IFMxJm5ic3A7ICZsdDstLSZuYnNw OyBTMSZuYnNwOyAmbHQ7LS0mbmJzcDsgUzEmbmJzcDsgJmx0Oy0tIC4uLjwvc3Bhbj48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1 LCAyNTUpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczog bm8tY29tbW9uLWxpZ2F0dXJlcyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgfDwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBmb250LXNp emU6IDExcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5sbzsgYmFja2dy b3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm8tY29tbW9uLWxpZ2F0dXJlcyIgY2xhc3M9IiI+Jm5i c3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBcLyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBcLyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBcLyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBcLzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4 OyBmb250LXNpemU6IDExcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBNZW5s bzsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm8tY29tbW9uLWxpZ2F0dXJlcyIgY2xh c3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJl Ij48L3NwYW4+Li4uICZsdDstLSZuYnNwOyBTMCZuYnNwOyAmbHQ7LS0mbmJzcDsgUzAmbmJzcDsg Jmx0Oy0tJm5ic3A7IFMwJm5ic3A7ICZsdDstLSZuYnNwOyBTMCZuYnNwOyAmbHQ7LS0gLi4uPC9z cGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXZhcmlh bnQtbGlnYXR1cmVzOiBuby1jb21tb24tbGlnYXR1cmVzIiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSBmcmFtZSBtYXJrZWQgd2l0aCBhbiBh c3RlcmlzayBpcyBhIGxheWVyIHJlZnJlc2ggcG9pbnQgZm9yIGxheWVyIFMyLCBhbmQgaXMgYSBw b2ludCBhdCB3aGljaCBhIE1BTkUgd2hpY2ggd2FzIHByZXZpb3VzbHkgZm9yd2FyZGluZyBqdXN0 IGxheWVyIFMxIGNvdWxkIHN0YXJ0IHNlbmRpbmcgUzIgYXMgd2VsbC4gJm5ic3A7VGhpcyBmcmFt ZSB3b3VsZCBoYXZlIHRoZSBWUDkgUCBiaXQgc2V0LiAmbmJzcDtIb3dldmVyLCBhcyBJIHVuZGVy c3RhbmQNCiBpdCwgaXQgd291bGQgKm5vdCogaGF2ZSB0aGUgZnJhbWUgbWFya2luZyBCIG9yIEkg Yml0cyBzZXQsIG5vciBhbnkgb3RoZXIgZmllbGRzIGluIHRoZSBmcmFtZSBtYXJraW5nIGhlYWRl ciBleHRlbnNpb24gd2hpY2ggZGlzdGluZ3Vpc2ggaXQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Qb3NzaWJseSB0aGUgZGVmaW5pdGlv biBvZiB0aGUgQiBiaXQgY291bGQgYmUgY2hhbmdlZCBzb21laG93IHRvIHByb3ZpZGUgdGhpcyBp bmZvcm1hdGlvbiwgYnV0IEkgZmVlbCBsaWtlIHRoZSBjdXJyZW50IEIgYml0IHNlbWFudGljcyBw cm92aWRlcyBvdGhlciBmdW5jdGlvbmFsaXR5IChhYm91dCB0aGUgZGVjb2RhYmlsaXR5IG9mIG5v biBiYXNlLXRlbXBvcmFsLWxheWVyIGZyYW1lcyBmb2xsb3dpbmcgbG9zcykgd2hpY2gNCiB3ZSBk b27igJl0IHdhbnQgdG8gYnJlYWs7IEnigJltIG5vdCBzdXJlIGhvdyBiZXN0IHRvIHNxdWFyZSB0 aGlzIGNpcmNsZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBTZXAgMSwgMjAxNywgYXQgNjox NSBQTSwgTW8gWmFuYXR5IChtemFuYXR5KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm16YW5hdHlAY2lz Y28uY29tIiBjbGFzcz0iIj5temFuYXR5QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0K PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPlRoYW5rcyBmb3IgYnVtcGluZyB0aGlzLCBDdWxsZW4uPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KQXQgSUVURiA5OSwgaXQgd2FzIGRlY2lkZWQgdGhhdCBwcmlvcml0 eSBtYXJraW5nIGJleW9uZCB0aGUgRGlzY2FyZGFibGU8YnIgY2xhc3M9IiI+DQpiaXQgc2hvdWxk IGdvIGluIGEgc2VwYXJhdGUgZHJhZnQuIFJvbmkgc3VibWl0dGVkPGJyIGNsYXNzPSIiPg0KZHJh ZnQtZXZlbi1hdnRjb3JlLXByaW9yaXR5LW1hcmtpbmdzIGZvciB0aGlzLiBTbyB0aGF0IGlzIGNs b3NlZC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgb25seSBvdGhlciBvcGVuIGlz c3VlIHdhcyB0aGUgbWFwcGluZyBvZiB0aGUgVlA5IFUvUCBiaXRzIHRvIHRoZSBmcmFtZTxiciBj bGFzcz0iIj4NCm1hcmtpbmcgQi9JIGJpdHMuIEluIHZlcnNpb24gMDUgb2YgZnJhbWUgbWFya2lu Zywgd2UgYWxyZWFkeSBtb3ZlZCBWUDk8YnIgY2xhc3M9IiI+DQpMSUQvVElEIG1hcHBpbmdzIHRv IHRoZSBWUDkgUlRQIHBheWxvYWQgZHJhZnQuIElmIHRoZSBmcmFtZSBtYXJraW5nIEIvSTxiciBj bGFzcz0iIj4NCmJpdHMgYXJlIHN1ZmZpY2llbnQgZm9yIHRoZSBuZWVkcyBvZiBWUDkgU1ZDIGFw cGxpY2F0aW9ucywgdGhlbiB0aGU8YnIgY2xhc3M9IiI+DQptYXBwaW5nIG9mIFZQOSBVL1AgYml0 cyB0byBmcmFtZSBtYXJraW5nIEIvSSBiaXRzIHNob3VsZCBhbHNvIGJlPGJyIGNsYXNzPSIiPg0K ZG9jdW1lbnRlZCBpbiB0aGUgVlA5IGRyYWZ0IHJhdGhlciB0aGFuIGZyYW1lIG1hcmtpbmcsIGFu ZCB3ZSBjYW4gcmVxdWVzdDxiciBjbGFzcz0iIj4NCldHTEMgZm9yIGZyYW1lIG1hcmtpbmcgd2l0 aG91dCB3YWl0aW5nIGZvciB0aGUgVlA5IGRyYWZ0IHVwZGF0ZXMuIElmIHRoZTxiciBjbGFzcz0i Ij4NCmZyYW1lIG1hcmtpbmcgQi9JIGJpdHMgYXJlIGluc3VmZmljaWVudCwgb3IgaWYgdGhlaXIg ZGVmaW5pdGlvbiBuZWVkcyB0bzxiciBjbGFzcz0iIj4NCmJlIGFsdGVyZWQgdG8gc3VwcG9ydCBW UDkgU1ZDIGFwcGxpY2F0aW9ucywgYW5kIHRoZSBXRyBmZWVscyB0aG9zZTxiciBjbGFzcz0iIj4N CmFwcGxpY2F0aW9ucyBhcmUgaW1wb3J0YW50LCB0aGVuIHdlIG5lZWQgdG8gZmluYWxpemUgYW55 IGNoYW5nZXMgbmVlZGVkPGJyIGNsYXNzPSIiPg0KZm9yIGZyYW1lIG1hcmtpbmcgQi9JIGJpdHMg QVNBUCB0aGVuIHN0YXJ0IFdHTEMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSm9uYXRo YW4sIFNlcmdpbywgQmVybmFyZCw8YnIgY2xhc3M9IiI+DQpZb3UgZXhwcmVzc2VkIGludGVyZXN0 IGluIFZQOSBTVkMgYXBwbGljYXRpb25zLiBBcmUgdGhlIGZyYW1lIG1hcmtpbmcgQi9JPGJyIGNs YXNzPSIiPg0KYml0cyBzdWZmaWNpZW50IGZvciB5b3VyIG5lZWRzPyBJZiBub3QsIHdoYXQgYXJl IHRoZSBzcGVjaWZpYyBpc3N1ZXMgd2U8YnIgY2xhc3M9IiI+DQpuZWVkIHRvIGFkZHJlc3M/IElz IGl0IG9ubHkgc3dpdGNoaW5nIHVwIHRvIGEgaGlnaGVyIHNwYXRpYWwgbGF5ZXIgd2hlbjxiciBj bGFzcz0iIj4NCnRoZXJlIGFyZSBtdWx0aXBsZSBzcGF0aWFsIGVuaGFuY2VtZW50IGxheWVycz88 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGFua3MsPGJyIGNsYXNzPSIiPg0KTW88YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIiBjbGFzcz0iIj5PbiBTZXAgMSwgMjAxNywgYXQgODoyMyBBTSwgQ3VsbGVuIEplbm5p bmdzICZsdDs8YSBocmVmPSJtYWlsdG86Zmx1ZmZ5QGlpaS5jYSIgY2xhc3M9IiI+Zmx1ZmZ5QGlp aS5jYTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkkgcmVhZCB0 aGlzIGRyYWZ0IGFuZCBkaWQgbm90IHNlZSBhbnkgaXNzdWVzLiBXaGVyZSBhcmUgd2Ugd2l0aCB0 aGlzPGJyIGNsYXNzPSIiPg0KZHJhZnQgYW5kIHdoYXQgaGFwcGVucyBuZXh0ID88YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_37C2005EB4294E39BC1C9ED68E9411E4vidyocom_-- From nobody Thu Sep 7 15:30:19 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF955132F6C for ; Thu, 7 Sep 2017 15:30:17 -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 sl2CI7paPPho for ; Thu, 7 Sep 2017 15:30:15 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 69DD4132709 for ; Thu, 7 Sep 2017 15:30:15 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id c82so1520486vkd.4 for ; Thu, 07 Sep 2017 15:30:15 -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=xZS5S6IBnEMrUewSdT++ko3ZpmEos0v/YAqsBzM8rRY=; b=J/iGYKOVdQtjlLybNfzyzP0AKvvm5yvQLUKh1o5lKHelOXZIg2bzUgS3PCCOBKUZBw /KQuUGyxtW/tSXdh0ttfsWaTnGxClFNrrgqw+kIfNQ+VmYTrdDr61ggwYty2xAQA1BF+ 6xoYEEg6c2aJCsYutH99OXBjAuCUmRDKz6kQnqyhUlSTaDp2M6QCMvo5LQXWOVoBL9md G27jLFki5DsVW6XA7z7hj6tkVm6xFV4gmKBZ76izv4Gmj/mLQdWh8bBhumuC5h1k53qf iMJfCG5SRihKn/ypsxlc7x0sDSxhepxXBXVar8s9YIBVQb7sO4B0v1DgZwOtSkm1ekIt JmOg== 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=xZS5S6IBnEMrUewSdT++ko3ZpmEos0v/YAqsBzM8rRY=; b=Pty2K6vzi8ab+tu9BYeJU12DR41lqXHTgywzhM2rgCYPQYrXzbOjDL6sdYpcpmSmxx mWn2IOCpV541h5e1fcafQFJuUIqGGp13qvAiNc5TlB8u3c00xtxGYtycXa2ZhifUbj9x I8Z7HZU3YroG+kjRiFHlG0UHaybXI+Tk5IUmQWLCI+9tG1bnQXp+XNVNb1HSKsKxfN5D I3dfeHs4xMapGSOAwFWdsDdlIl46T77FPg/unp/7LkAGyBt0hvvpcIppLCKrKAM9XTrY K4a1wGY/yVLaCpwFdqBDSMA1FcC9ehGDzCL8IsL3lypVzF+lPkQGw25G7yuZjmn9fPNc 1y0g== X-Gm-Message-State: AHPjjUiAkTjgwlRIJ9oxnCTQntu7BfW7HPklD67oJ6MXuS8pG51A2To/ dowCTU/ihGF1GFbMweiKFNUsgdCylw== X-Google-Smtp-Source: AOwi7QBDTXfKS3QnIKZMcyTab6jCPyOh/uH37Vhn0MfR18Fh5tn/jjRnid7y0IBsjfI8c0DNLdBmRXXvWPcXfIODXgs= X-Received: by 10.31.63.12 with SMTP id m12mr530966vka.26.1504823414120; Thu, 07 Sep 2017 15:30:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.64.10 with HTTP; Thu, 7 Sep 2017 15:29:53 -0700 (PDT) In-Reply-To: <37C2005E-B429-4E39-BC1C-9ED68E9411E4@vidyo.com> References: <37C2005E-B429-4E39-BC1C-9ED68E9411E4@vidyo.com> From: Bernard Aboba Date: Thu, 7 Sep 2017 15:29:53 -0700 Message-ID: To: Jonathan Lennox Cc: "Mo Zanaty (mzanaty)" , Cullen Jennings , Sergio Garcia Murillo , IETF AVTCore WG Content-Type: multipart/alternative; boundary="001a114dcf180c649c0558a101ca" Archived-At: Subject: Re: [AVTCORE] Review of draft-ietf-avtext-framemarking-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 22:30:18 -0000 --001a114dcf180c649c0558a101ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jonathan said: " If this is the case, then VP9=E2=80=99s U bit wouldn=E2=80=99t need mappi= ng =E2=80=94 any VP9 stream which could validly have frame marking applied to it would always have the U bit set to true, and MANEs could start sending temporal layers at any time." [BA] I would be ok with a temporal nesting restriction, since that restriction is so commonly applied anyway. "However, as I understand it, it would *not* have the frame marking B or I bits set, nor any other fields in the frame marking header extension which distinguish it." [BA] That was my reading as well. So it seemed to me that another bit would be needed. On Thu, Sep 7, 2017 at 1:29 PM, Jonathan Lennox wrote: > I think the issue isn=E2=80=99t specifically with VP9 mapping as such, bu= t rather > with the semantics that the VP9 payload=E2=80=99s U and P bits express. > > Essentially, VP9=E2=80=99s U indicates that this is a point at which a MA= NE can > validly start sending a higher temporal layer, and P indicates a point at > which a MANE can start sending a higher spatial layer. > > It=E2=80=99s not clear to me that frame marking makes it possible to extr= act > either of these semantics at the moment. > > Possibly, the (vastly underspecified) statement in section 3.4.2, > requiring that frame marking not be used for =E2=80=9Ccomplex or irregula= r=E2=80=9D > scalability structures, means that (among other things) any stream using > frame marking needs to be temporally nested. (See the LRR draft for a > definition of temporal nesting). If this is the case, then VP9=E2=80=99s= U bit > wouldn=E2=80=99t need mapping =E2=80=94 any VP9 stream which could validl= y have frame > marking applied to it would always have the U bit set to true, and MANEs > could start sending temporal layers at any time. I=E2=80=99d be fine wit= h this > restriction, but it would need to be written down explicitly; and I don= =E2=80=99t > understand everyone else=E2=80=99s use cases well enough to be sure that = no one > else would have a problem with it. > > For the P bit, the issue is indeed about spatial layer switching-up > points. Consider the following stream encoded with three spatial layers: > > ... <-- S2 <-- S2 S2* <-- S2 <-- ... > | | | | > \/ \/ \/ \/ > ... <-- S1 <-- S1 <-- S1 <-- S1 <-- ... > | | | | > \/ \/ \/ \/ > ... <-- S0 <-- S0 <-- S0 <-- S0 <-- ... > > The frame marked with an asterisk is a layer refresh point for layer S2, > and is a point at which a MANE which was previously forwarding just layer > S1 could start sending S2 as well. This frame would have the VP9 P bit > set. However, as I understand it, it would *not* have the frame marking = B > or I bits set, nor any other fields in the frame marking header extension > which distinguish it. > > Possibly the definition of the B bit could be changed somehow to provide > this information, but I feel like the current B bit semantics provides > other functionality (about the decodability of non base-temporal-layer > frames following loss) which we don=E2=80=99t want to break; I=E2=80=99m = not sure how best > to square this circle. > > > On Sep 1, 2017, at 6:15 PM, Mo Zanaty (mzanaty) wrote= : > > Thanks for bumping this, Cullen. > > At IETF 99, it was decided that priority marking beyond the Discardable > bit should go in a separate draft. Roni submitted > draft-even-avtcore-priority-markings for this. So that is closed. > > The only other open issue was the mapping of the VP9 U/P bits to the fram= e > marking B/I bits. In version 05 of frame marking, we already moved VP9 > LID/TID mappings to the VP9 RTP payload draft. If the frame marking B/I > bits are sufficient for the needs of VP9 SVC applications, then the > mapping of VP9 U/P bits to frame marking B/I bits should also be > documented in the VP9 draft rather than frame marking, and we can request > WGLC for frame marking without waiting for the VP9 draft updates. If the > frame marking B/I bits are insufficient, or if their definition needs to > be altered to support VP9 SVC applications, and the WG feels those > applications are important, then we need to finalize any changes needed > for frame marking B/I bits ASAP then start WGLC. > > Jonathan, Sergio, Bernard, > You expressed interest in VP9 SVC applications. Are the frame marking B/I > bits sufficient for your needs? If not, what are the specific issues we > need to address? Is it only switching up to a higher spatial layer when > there are multiple spatial enhancement layers? > > Thanks, > Mo > > > On Sep 1, 2017, at 8:23 AM, Cullen Jennings wrote: > > I read this draft and did not see any issues. Where are we with this > draft and what happens next ? > > > > > --001a114dcf180c649c0558a101ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jonathan said:=C2=A0

"=C2=A0If this is the case, then VP9=E2=80=99s U bit w= ouldn=E2=80=99t need mapping =E2=80=94 any VP9 stream which could validly h= ave frame marking applied to it would always have the U bit set to true, an= d MANEs could start sending temporal layers at any time."
=

[BA] I would be ok with a temporal nesting restriction, s= ince that restriction is so commonly applied anyway.=C2=A0

"However, as I u= nderstand it, it would *not* have the frame marking B or I bits set, nor an= y other fields in the frame marking header extension which distinguish it.&= quot;

[BA] That was my reading as well.=C2=A0= So it seemed to me that another bit would be needed.
On Thu, Sep 7, 2017 = at 1:29 PM, Jonathan Lennox <jonathan@vidyo.com> wrote:
=
I think the issue isn=E2=80=99t specifically with VP9 mapping as such,= but rather with the semantics that the VP9 payload=E2=80=99s U and P bits = express.

Essentially, VP9=E2=80=99s U indicates that this is a point at which a= MANE can validly start sending a higher temporal layer, and P indicates a = point at which a MANE can start sending a higher spatial layer.

It=E2=80=99s not clear to me that frame marking makes it possible to e= xtract either of these semantics at the moment.

Possibly, the (vastly underspecified) statement in section 3.4.2, requ= iring that frame marking not be used for =E2=80=9Ccomplex or irregular=E2= =80=9D scalability structures, means that (among other things) any stream u= sing frame marking needs to be temporally nested. =C2=A0(See the LRR draft for a definition of temporal nesting).=C2= =A0 If this is the case, then VP9=E2=80=99s U bit wouldn=E2=80=99t need map= ping =E2=80=94 any VP9 stream which could validly have frame marking applie= d to it would always have the U bit set to true, and MANEs could start sending temporal layers at any time.=C2=A0 I=E2=80=99d be fine with this r= estriction, but it would need to be written down explicitly; and I don=E2= =80=99t understand everyone else=E2=80=99s use cases well enough to be sure= that no one else would have a problem with it.

For the P bit, the issue is indeed about spatial layer switching-up po= ints.=C2=A0 Consider the following stream encoded with three spatial layers= :

=C2=A0 =C2=A0 = =C2=A0 =C2=A0=C2=A0... <--=C2=A0 S2=C2=A0 <--=C2=A0 S2 =C2=A0 =C2=A0 = =C2=A0 S2* <--=C2=A0 S2=C2=A0 <-- ...
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \/ =C2=A0 =C2=A0 =C2=A0 \/ = =C2=A0 =C2=A0 =C2=A0 \/ =C2=A0 =C2=A0 =C2=A0 \/
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 ... <--=C2=A0 S1=C2=A0 <--=C2=A0 S1=C2=A0 <--=C2=A0 = S1=C2=A0 <--=C2=A0 S1=C2=A0 <-- ...
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \/ =C2=A0 =C2=A0 =C2=A0 \/ = =C2=A0 =C2=A0 =C2=A0 \/ =C2=A0 =C2=A0 =C2=A0 \/
= ... <--=C2=A0 S0=C2=A0 <--=C2=A0 S0=C2=A0 <--=C2=A0 S0=C2=A0 <-= -=C2=A0 S0=C2=A0 <-- ...

The frame marked with an asterisk is a layer refresh point for layer S= 2, and is a point at which a MANE which was previously forwarding just laye= r S1 could start sending S2 as well.=C2=A0 This frame would have the VP9 P = bit set.=C2=A0 However, as I understand it, it would *not* have the frame marking B or I bits set, nor any other f= ields in the frame marking header extension which distinguish it.

Possibly the definition of the B bit could be changed somehow to provi= de this information, but I feel like the current B bit semantics provides o= ther functionality (about the decodability of non base-temporal-layer frame= s following loss) which we don=E2=80=99t want to break; I=E2=80=99m not sure how best to square th= is circle.


On Sep 1, 2017, at 6:15 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:

Thanks for bumping this, Cullen.

At IETF 99, it was decided that priority marking beyond the Discardable
bit should go in a separate draft. Roni submitted
draft-even-avtcore-priority-markings for this. So that is closed.

The only other open issue was the mapping of the VP9 U/P bits to the frame<= br> marking B/I bits. In version 05 of frame marking, we already moved VP9
LID/TID mappings to the VP9 RTP payload draft. If the frame marking B/I
bits are sufficient for the needs of VP9 SVC applications, then the
mapping of VP9 U/P bits to frame marking B/I bits should also be
documented in the VP9 draft rather than frame marking, and we can request WGLC for frame marking without waiting for the VP9 draft updates. If the frame marking B/I bits are insufficient, or if their definition needs to be altered to support VP9 SVC applications, and the WG feels those
applications are important, then we need to finalize any changes needed
for frame marking B/I bits ASAP then start WGLC.

Jonathan, Sergio, Bernard,
You expressed interest in VP9 SVC applications. Are the frame marking B/I bits sufficient for your needs? If not, what are the specific issues we
need to address? Is it only switching up to a higher spatial layer when
there are multiple spatial enhancement layers?

Thanks,
Mo


On Sep 1, 2017, at 8:23 AM, Cullen Jennings <<= a href=3D"mailto:fluffy@iii.ca" target=3D"_blank">fluffy@iii.ca> wro= te:

I read this draft and did not see any issues. Where are we with this
draft and what happens next ?





--001a114dcf180c649c0558a101ca-- From nobody Thu Sep 7 16:28:57 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDEFA132FC4 for ; Thu, 7 Sep 2017 16:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 P43ber7FDamc for ; Thu, 7 Sep 2017 16:28:53 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 613DE1320CC for ; Thu, 7 Sep 2017 16:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16402; q=dns/txt; s=iport; t=1504826933; x=1506036533; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mRSxmVCssHQe3t4s8H1+2DoXplkiqAq+1ZGv0CPzIwE=; b=KysZYfUUsJjMwjDGiUN/gLFfFB4ALw1/5oAmvRdVYNaLqJ1ZQzZcCXqq zpQouT0vZ/wVtWVBgnMyia/JN6uFqb5qpkYl4pQef8aaTTZy1iWnDOjEM Xm5MHOqX74530+BmT6ep84l2vNGA9Y6HNfC8EbT9KLjYwT+B3B8goYVMU 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgCl1bFZ/49dJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rgVInnjiKKogwh1EKhT4ChANXAQIBAQEBAQJrKIUZBnkQAgE?= =?us-ascii?q?IPwchERQRAgQOBYlNTAMVrguHMQ2DewEBAQEBAQEBAgEBAQEBAQEBAQEegyqCA?= =?us-ascii?q?oFOgWMrgn2BPIEbhWGCMQWgODwCj1mEdoITiWWGeYxTiCsCERkBgTgBV4ENdxV?= =?us-ascii?q?bAYUFDBCBZ3aKHgEBAQ?= X-IronPort-AV: E=Sophos;i="5.42,360,1500940800"; d="scan'208,217";a="454865" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Sep 2017 23:28:52 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id v87NSqwu005085 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Sep 2017 23:28:52 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 7 Sep 2017 18:28:51 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1263.000; Thu, 7 Sep 2017 18:28:51 -0500 From: "Mo Zanaty (mzanaty)" To: Bernard Aboba CC: Jonathan Lennox , Cullen Jennings , Sergio Garcia Murillo , IETF AVTCore WG Thread-Topic: [AVTCORE] Review of draft-ietf-avtext-framemarking-05 Thread-Index: AQHTI2/AlRfq5gy5XUmfnaT3Kk3Sb6KqPOiAgAAhsID//7ypvg== Date: Thu, 7 Sep 2017 23:28:51 +0000 Message-ID: References: <37C2005E-B429-4E39-BC1C-9ED68E9411E4@vidyo.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_D4B55CBC8BDF449A9EFA83B72A45B44Eciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [AVTCORE] Review of draft-ietf-avtext-framemarking-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Sep 2017 23:28:56 -0000 --_000_D4B55CBC8BDF449A9EFA83B72A45B44Eciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sergio, You originally raised the issues with VP9 U/P bits. Are you ok with the res= triction that frame marking requires nested temporal layers? That would res= olve the U bit issue. For multiple spatial enhancement layers, I propose tweaking the definition = of the frame marking I (Independent) bit to mean no temporal dependencies w= hile allowing dependencies on lower spatial layers that are temporally co-l= ocated. So S2* below would set the I bit to indicate a spatial layer up swi= tching point. This change would mean frame marking could not be used to differentiate bet= ween Intra frames of simulcast spatial layers vs Intra frames of scalable s= patial layers (with inter-layer prediction dependencies). I'm fine with tha= t, since such a distinction really belongs at a higher level (media negotia= tion / signaling, overall stream or layer properties, etc.) rather than per= RTP packet. Does this work for all? Mo On Sep 7, 2017, at 6:30 PM, Bernard Aboba > wrote: Jonathan said: " If this is the case, then VP9=92s U bit wouldn=92t need mapping =97 any V= P9 stream which could validly have frame marking applied to it would always= have the U bit set to true, and MANEs could start sending temporal layers = at any time." [BA] I would be ok with a temporal nesting restriction, since that restrict= ion is so commonly applied anyway. "However, as I understand it, it would *not* have the frame marking B or I = bits set, nor any other fields in the frame marking header extension which = distinguish it." [BA] That was my reading as well. So it seemed to me that another bit woul= d be needed. On Thu, Sep 7, 2017 at 1:29 PM, Jonathan Lennox > wrote: I think the issue isn=92t specifically with VP9 mapping as such, but rather= with the semantics that the VP9 payload=92s U and P bits express. Essentially, VP9=92s U indicates that this is a point at which a MANE can v= alidly start sending a higher temporal layer, and P indicates a point at wh= ich a MANE can start sending a higher spatial layer. It=92s not clear to me that frame marking makes it possible to extract eith= er of these semantics at the moment. Possibly, the (vastly underspecified) statement in section 3.4.2, requiring= that frame marking not be used for =93complex or irregular=94 scalability = structures, means that (among other things) any stream using frame marking = needs to be temporally nested. (See the LRR draft for a definition of temp= oral nesting). If this is the case, then VP9=92s U bit wouldn=92t need map= ping =97 any VP9 stream which could validly have frame marking applied to i= t would always have the U bit set to true, and MANEs could start sending te= mporal layers at any time. I=92d be fine with this restriction, but it wou= ld need to be written down explicitly; and I don=92t understand everyone el= se=92s use cases well enough to be sure that no one else would have a probl= em with it. For the P bit, the issue is indeed about spatial layer switching-up points.= Consider the following stream encoded with three spatial layers: ... <-- S2 <-- S2 S2* <-- S2 <-- ... | | | | \/ \/ \/ \/ ... <-- S1 <-- S1 <-- S1 <-- S1 <-- ... | | | | \/ \/ \/ \/ ... <-- S0 <-- S0 <-- S0 <-- S0 <-- ... The frame marked with an asterisk is a layer refresh point for layer S2, an= d is a point at which a MANE which was previously forwarding just layer S1 = could start sending S2 as well. This frame would have the VP9 P bit set. = However, as I understand it, it would *not* have the frame marking B or I b= its set, nor any other fields in the frame marking header extension which d= istinguish it. Possibly the definition of the B bit could be changed somehow to provide th= is information, but I feel like the current B bit semantics provides other = functionality (about the decodability of non base-temporal-layer frames fol= lowing loss) which we don=92t want to break; I=92m not sure how best to squ= are this circle. On Sep 1, 2017, at 6:15 PM, Mo Zanaty (mzanaty) > wrote: Thanks for bumping this, Cullen. At IETF 99, it was decided that priority marking beyond the Discardable bit should go in a separate draft. Roni submitted draft-even-avtcore-priority-markings for this. So that is closed. The only other open issue was the mapping of the VP9 U/P bits to the frame marking B/I bits. In version 05 of frame marking, we already moved VP9 LID/TID mappings to the VP9 RTP payload draft. If the frame marking B/I bits are sufficient for the needs of VP9 SVC applications, then the mapping of VP9 U/P bits to frame marking B/I bits should also be documented in the VP9 draft rather than frame marking, and we can request WGLC for frame marking without waiting for the VP9 draft updates. If the frame marking B/I bits are insufficient, or if their definition needs to be altered to support VP9 SVC applications, and the WG feels those applications are important, then we need to finalize any changes needed for frame marking B/I bits ASAP then start WGLC. Jonathan, Sergio, Bernard, You expressed interest in VP9 SVC applications. Are the frame marking B/I bits sufficient for your needs? If not, what are the specific issues we need to address? Is it only switching up to a higher spatial layer when there are multiple spatial enhancement layers? Thanks, Mo On Sep 1, 2017, at 8:23 AM, Cullen Jennings > wrote: I read this draft and did not see any issues. Where are we with this draft and what happens next ? --_000_D4B55CBC8BDF449A9EFA83B72A45B44Eciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Sergio,
You originally raised the issues with VP9 U/P bits. Are you ok with th= e restriction that frame marking requires nested temporal layers? That woul= d resolve the U bit issue.

For multiple spatial enhancement layers, I propose tweaking the defini= tion of the frame marking I (Independent) bit to mean no temporal dependenc= ies while allowing dependencies on lower spatial layers that are temporally= co-located. So S2* below would set the I bit to indicate a spatial layer up switching point. 

This change would mean frame marking could not be used to differentiat= e between Intra frames of simulcast spatial layers vs Intra frames of scala= ble spatial layers (with inter-layer prediction dependencies). I'm fine wit= h that, since such a distinction really belongs at a higher level (media negotiation / signaling, overall s= tream or layer properties, etc.) rather than per RTP packet. 

Does this work for all?

Mo

On Sep 7, 2017, at 6:30 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:

Jonathan said: 

" If this is the case, then= VP9=92s U bit wouldn=92t need mapping =97 any VP9 stream which could valid= ly have frame marking applied to it would always have the U bit set to true= , and MANEs could start sending temporal layers at any time."

[BA] I would be ok with a temporal ne= sting restriction, since that restriction is so commonly applied anyway.&nb= sp;

"However, as I understand it, it would *not* have the frame marking= B or I bits set, nor any other fields in the frame marking header extensio= n which distinguish it."

[BA] That was my reading as well.&nbs= p; So it seemed to me that another bit would be needed.

On Thu, Sep 7, 2017 at 1:29 PM, Jonathan Lennox = <jonathan@vidyo.= com> wrote:
I think the issue isn=92t specifically with VP9 mapping as such, but r= ather with the semantics that the VP9 payload=92s U and P bits express.

Essentially, VP9=92s U indicates that this is a point at which a MANE = can validly start sending a higher temporal layer, and P indicates a point = at which a MANE can start sending a higher spatial layer.

It=92s not clear to me that frame marking makes it possible to extract= either of these semantics at the moment.

Possibly, the (vastly underspecified) statement in section 3.4.2, requ= iring that frame marking not be used for =93complex or irregular=94 scalabi= lity structures, means that (among other things) any stream using frame mar= king needs to be temporally nested.  (See the LRR draft for a definition of temporal nesting).  If t= his is the case, then VP9=92s U bit wouldn=92t need mapping =97 any VP9 str= eam which could validly have frame marking applied to it would always have = the U bit set to true, and MANEs could start sending temporal layers at any time.  I=92d be fine with this restriction, bu= t it would need to be written down explicitly; and I don=92t understand eve= ryone else=92s use cases well enough to be sure that no one else would have= a problem with it.

For the P bit, the issue is indeed about spatial layer switching-up po= ints.  Consider the following stream encoded with three spatial layers= :

    &n= bsp;   ... <--  S2  <--  S2     &n= bsp; S2* <--  S2  <-- ...
    &n= bsp;             |       = |        |        |
   &nb= sp;             \/       \/ &n= bsp;     \/       \/
    &n= bsp;   ... <--  S1  <--  S1  <--  S1=   <--  S1  <-- ...
    &n= bsp;             |       = |        |        |
   &nb= sp;             \/       \/ &n= bsp;     \/       \/
= ... <--  S0  <--  S0  <--  S0  <-= -  S0  <-- ...

The frame marked with an asterisk is a layer refresh point for layer S= 2, and is a point at which a MANE which was previously forwarding just laye= r S1 could start sending S2 as well.  This frame would have the VP9 P = bit set.  However, as I understand it, it would *not* have the frame marking B or I bits set, nor any other field= s in the frame marking header extension which distinguish it.

Possibly the definition of the B bit could be changed somehow to provi= de this information, but I feel like the current B bit semantics provides o= ther functionality (about the decodability of non base-temporal-layer frame= s following loss) which we don=92t want to break; I=92m not sure how best to square this circle.


On Sep 1, 2017, at 6:15 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:

Thanks for bumping this, Cullen.

At IETF 99, it was decided that priority marking beyond the Discardable
bit should go in a separate draft. Roni submitted
draft-even-avtcore-priority-markings for this. So that is closed.

The only other open issue was the mapping of the VP9 U/P bits to the frame<= br> marking B/I bits. In version 05 of frame marking, we already moved VP9
LID/TID mappings to the VP9 RTP payload draft. If the frame marking B/I
bits are sufficient for the needs of VP9 SVC applications, then the
mapping of VP9 U/P bits to frame marking B/I bits should also be
documented in the VP9 draft rather than frame marking, and we can request WGLC for frame marking without waiting for the VP9 draft updates. If the frame marking B/I bits are insufficient, or if their definition needs to be altered to support VP9 SVC applications, and the WG feels those
applications are important, then we need to finalize any changes needed
for frame marking B/I bits ASAP then start WGLC.

Jonathan, Sergio, Bernard,
You expressed interest in VP9 SVC applications. Are the frame marking B/I bits sufficient for your needs? If not, what are the specific issues we
need to address? Is it only switching up to a higher spatial layer when
there are multiple spatial enhancement layers?

Thanks,
Mo


On Sep 1, 2017, at 8:23 AM, Cullen Jennings <<= a href=3D"mailto:fluffy@iii.ca" target=3D"_blank">fluffy@iii.ca> wro= te:

I read this draft and did not see any issues. Where are we with this
draft and what happens next ?





--_000_D4B55CBC8BDF449A9EFA83B72A45B44Eciscocom_-- From nobody Thu Sep 7 23:06:06 2017 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B93132D89 for ; Thu, 7 Sep 2017 23:06:02 -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 Y-aVPNbkeU7m for ; Thu, 7 Sep 2017 23:06:01 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 88C321321DC for ; Thu, 7 Sep 2017 23:06:00 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id o42so2634822wrb.3 for ; Thu, 07 Sep 2017 23:06:00 -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=lcuKHYPg0QPzE3QM1f06nK0dc/rahZVGDs7Y+nXFZyM=; b=SEFUYPV5OeeCnFsJeOxwqTzLJIkknfuSF0vZLZ6auZARvB2s0k/1qMP5klI67RS8LE FiwfnuZHR3eiRO0UoC+3/2AOxxs96yoFGYaRkvIc6L+W+0SB4sRU+Ud2zpALhI/MkfZd l4b35U75jTgRCYnKWMx/lZslcOd7cH0rBvzoDYhUdQZh1QgHUURuXqA6n5Jqk4Oqu1+n 0GRbf68y3N5JmJXJt89GyQ3RixIig5g/65yYQZjYKu3Az/zju/dM+jO5nnnyn8yIqYUE bnKUQh3dK4GUF3ZpfuAx71vIArAXbz53U9YYv7VLHY7ZXqcPgVXI4dTwKXLjeuL6ylhf OHRQ== 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=lcuKHYPg0QPzE3QM1f06nK0dc/rahZVGDs7Y+nXFZyM=; b=Uw6lfut6Vyq2Ok+fh2tNviWlCYx6BkHDLGrH6u+ZKbxalW5OwEIcdGZrcgiXf3MYAS lKGVbVS1bZKZIbwZcasyUVA3NK0xpriqbuSDmtinx8HyWoTg18T2LAZyzhR/Xyjzyaao YGDAN+H0WysMfdEx0O84rM13kLtR/hTUw7tdTJn6DexiSl2M/HfcC+A6DF3h+sr0fRS9 qiGcJtIIKzQICYv+muU09lM7nMre0s11UXFKqtoJeXRWJhn7MWD40OPTZ5G5drfCJnaK qGsN8vHgdzr5Xjyo2L+uQpRb5vf0ZqZ9zKnk+aNe8h5HLKIhFz0BamP06TZD51WCqEH0 egRQ== X-Gm-Message-State: AHPjjUirE7mpVgQTnmv5bIvk7tDVYyaQYojLsYWlkeTVtavFd0VKcBTX JnB+Kp5CUuT2e+kEYFoLJvupDrykeA== X-Google-Smtp-Source: ADKCNb7DxGW8GpWjyfcJRu8DgdnhiD0YU1nkx2r897h3Pdd1Sx1SxrKQ4Arin3sXRVzjE+o03UZiIG7+rEglbOq6Bb4= X-Received: by 10.223.188.68 with SMTP id a4mr1242569wrh.300.1504850759051; Thu, 07 Sep 2017 23:05:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.43.135 with HTTP; Thu, 7 Sep 2017 23:05:58 -0700 (PDT) In-Reply-To: References: <37C2005E-B429-4E39-BC1C-9ED68E9411E4@vidyo.com> From: Sergio Garcia Murillo Date: Fri, 8 Sep 2017 08:05:58 +0200 Message-ID: To: "Mo Zanaty (mzanaty)" Cc: Bernard Aboba , Jonathan Lennox , Cullen Jennings , IETF AVTCore WG Content-Type: multipart/alternative; boundary="089e0820be30eef0110558a75e3c" Archived-At: Subject: Re: [AVTCORE] Review of draft-ietf-avtext-framemarking-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 06:06:03 -0000 --089e0820be30eef0110558a75e3c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi guys, Sorry for the late reply. It doesn't seem reasonable to me to modify the vp9 svc behavior just because we are using an rtp header extension or not, specially when we have 4 unused bits on the codec specific info. Frame marking should adapt to match codec, not the other way round (if not we are doing it wrong IMHO). Regarding the other bits, I think that the frame marking info on each draft should not only define what are they, but also how to extract it from the encoder/rtp data. In case of VP9 I think there should be an explicit mapping between the frame marking bits and the vp9 payload description bits. So in this regards, changing the meaning of the I and B bits, I could agree with it, as long as we say exactly what values of the vp9 payload description should they be equal too. Best regards Sergio 2017-09-08 1:28 GMT+02:00 Mo Zanaty (mzanaty) : > Sergio, > You originally raised the issues with VP9 U/P bits. Are you ok with the > restriction that frame marking requires nested temporal layers? That woul= d > resolve the U bit issue. > > For multiple spatial enhancement layers, I propose tweaking the definitio= n > of the frame marking I (Independent) bit to mean no temporal dependencies > while allowing dependencies on lower spatial layers that are temporally > co-located. So S2* below would set the I bit to indicate a spatial layer = up > switching point. > > This change would mean frame marking could not be used to differentiate > between Intra frames of simulcast spatial layers vs Intra frames of > scalable spatial layers (with inter-layer prediction dependencies). I'm > fine with that, since such a distinction really belongs at a higher level > (media negotiation / signaling, overall stream or layer properties, etc.) > rather than per RTP packet. > > Does this work for all? > > Mo > > On Sep 7, 2017, at 6:30 PM, Bernard Aboba wrote= : > > Jonathan said: > > " If this is the case, then VP9=E2=80=99s U bit wouldn=E2=80=99t need map= ping =E2=80=94 any VP9 > stream which could validly have frame marking applied to it would always > have the U bit set to true, and MANEs could start sending temporal layers > at any time." > > [BA] I would be ok with a temporal nesting restriction, since that > restriction is so commonly applied anyway. > > "However, as I understand it, it would *not* have the frame marking B or > I bits set, nor any other fields in the frame marking header extension > which distinguish it." > > [BA] That was my reading as well. So it seemed to me that another bit > would be needed. > > On Thu, Sep 7, 2017 at 1:29 PM, Jonathan Lennox > wrote: > >> I think the issue isn=E2=80=99t specifically with VP9 mapping as such, b= ut rather >> with the semantics that the VP9 payload=E2=80=99s U and P bits express. >> >> Essentially, VP9=E2=80=99s U indicates that this is a point at which a M= ANE can >> validly start sending a higher temporal layer, and P indicates a point a= t >> which a MANE can start sending a higher spatial layer. >> >> It=E2=80=99s not clear to me that frame marking makes it possible to ext= ract >> either of these semantics at the moment. >> >> Possibly, the (vastly underspecified) statement in section 3.4.2, >> requiring that frame marking not be used for =E2=80=9Ccomplex or irregul= ar=E2=80=9D >> scalability structures, means that (among other things) any stream using >> frame marking needs to be temporally nested. (See the LRR draft for a >> definition of temporal nesting). If this is the case, then VP9=E2=80=99= s U bit >> wouldn=E2=80=99t need mapping =E2=80=94 any VP9 stream which could valid= ly have frame >> marking applied to it would always have the U bit set to true, and MANEs >> could start sending temporal layers at any time. I=E2=80=99d be fine wi= th this >> restriction, but it would need to be written down explicitly; and I don= =E2=80=99t >> understand everyone else=E2=80=99s use cases well enough to be sure that= no one >> else would have a problem with it. >> >> For the P bit, the issue is indeed about spatial layer switching-up >> points. Consider the following stream encoded with three spatial layers= : >> >> ... <-- S2 <-- S2 S2* <-- S2 <-- ... >> | | | | >> \/ \/ \/ \/ >> ... <-- S1 <-- S1 <-- S1 <-- S1 <-- ... >> | | | | >> \/ \/ \/ \/ >> ... <-- S0 <-- S0 <-- S0 <-- S0 <-- ... >> >> The frame marked with an asterisk is a layer refresh point for layer S2, >> and is a point at which a MANE which was previously forwarding just laye= r >> S1 could start sending S2 as well. This frame would have the VP9 P bit >> set. However, as I understand it, it would *not* have the frame marking= B >> or I bits set, nor any other fields in the frame marking header extensio= n >> which distinguish it. >> >> Possibly the definition of the B bit could be changed somehow to provide >> this information, but I feel like the current B bit semantics provides >> other functionality (about the decodability of non base-temporal-layer >> frames following loss) which we don=E2=80=99t want to break; I=E2=80=99m= not sure how best >> to square this circle. >> >> >> On Sep 1, 2017, at 6:15 PM, Mo Zanaty (mzanaty) >> wrote: >> >> Thanks for bumping this, Cullen. >> >> At IETF 99, it was decided that priority marking beyond the Discardable >> bit should go in a separate draft. Roni submitted >> draft-even-avtcore-priority-markings for this. So that is closed. >> >> The only other open issue was the mapping of the VP9 U/P bits to the fra= me >> marking B/I bits. In version 05 of frame marking, we already moved VP9 >> LID/TID mappings to the VP9 RTP payload draft. If the frame marking B/I >> bits are sufficient for the needs of VP9 SVC applications, then the >> mapping of VP9 U/P bits to frame marking B/I bits should also be >> documented in the VP9 draft rather than frame marking, and we can reques= t >> WGLC for frame marking without waiting for the VP9 draft updates. If the >> frame marking B/I bits are insufficient, or if their definition needs to >> be altered to support VP9 SVC applications, and the WG feels those >> applications are important, then we need to finalize any changes needed >> for frame marking B/I bits ASAP then start WGLC. >> >> Jonathan, Sergio, Bernard, >> You expressed interest in VP9 SVC applications. Are the frame marking B/= I >> bits sufficient for your needs? If not, what are the specific issues we >> need to address? Is it only switching up to a higher spatial layer when >> there are multiple spatial enhancement layers? >> >> Thanks, >> Mo >> >> >> On Sep 1, 2017, at 8:23 AM, Cullen Jennings wrote: >> >> I read this draft and did not see any issues. Where are we with this >> draft and what happens next ? >> >> >> >> >> > --089e0820be30eef0110558a75e3c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi guys,

Sorry for the late reply.

It doesn't seem reasonable to me to modify the vp9= svc behavior just because we are using an rtp header extension or not, spe= cially when we have 4 unused bits on the codec specific info. Frame marking= should adapt to match codec, not the other way round (if not we are doing = it wrong IMHO).

Regarding the other bits, I think = that the frame marking info on each draft should not only define what are t= hey, but also how to extract it from the encoder/rtp data. In case of VP9 I= think there should be an explicit mapping between the frame marking bits a= nd the vp9 payload description bits. So in this regards, changing the meani= ng of the I and B bits, I could agree with it, as long as we say exactly wh= at values of the vp9 payload description should they be equal too.

Best regards
Sergio


2017-09-08 1:28 GMT= +02:00 Mo Zanaty (mzanaty) <mzanaty@cisco.com>:
Sergio,
You originally raised the issues with VP9 U/P bits. Are you ok with th= e restriction that frame marking requires nested temporal layers? That woul= d resolve the U bit issue.

For multiple spatial enhancement layers, I propose tweaking the defini= tion of the frame marking I (Independent) bit to mean no temporal dependenc= ies while allowing dependencies on lower spatial layers that are temporally= co-located. So S2* below would set the I bit to indicate a spatial layer up switching point.=C2=A0

This change would mean frame marking could not be used to differentiat= e between Intra frames of simulcast spatial layers vs Intra frames of scala= ble spatial layers (with inter-layer prediction dependencies). I'm fine= with that, since such a distinction really belongs at a higher level (media negotiation / signaling, overall s= tream or layer properties, etc.) rather than per RTP packet.=C2=A0

Does this work for all?

Mo

On Sep 7, 2017, at 6:30 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:

Jonathan said:=C2=A0

"=C2=A0If this is the case, then= VP9=E2=80=99s U bit wouldn=E2=80=99t need mapping =E2=80=94 any VP9 stream= which could validly have frame marking applied to it would always have the= U bit set to true, and MANEs could start sending temporal layers at any time."

[BA] I would be ok with a temporal ne= sting restriction, since that restriction is so commonly applied anyway.=C2= =A0

"However, as I understand it, it would *not* have the frame marking= B or I bits set, nor any other fields in the frame marking header extensio= n which distinguish it."

[BA] That was my reading as well.=C2= =A0 So it seemed to me that another bit would be needed.

On Thu, Sep 7, 2017 at 1:29 PM, Jonathan Lennox = <jonathan@vidyo.= com> wrote:
I think the issue isn=E2=80=99t specifically with VP9 mapping as such,= but rather with the semantics that the VP9 payload=E2=80=99s U and P bits = express.

Essentially, VP9=E2=80=99s U indicates that this is a point at which a= MANE can validly start sending a higher temporal layer, and P indicates a = point at which a MANE can start sending a higher spatial layer.

It=E2=80=99s not clear to me that frame marking makes it possible to e= xtract either of these semantics at the moment.

Possibly, the (vastly underspecified) statement in section 3.4.2, requ= iring that frame marking not be used for =E2=80=9Ccomplex or irregular=E2= =80=9D scalability structures, means that (among other things) any stream u= sing frame marking needs to be temporally nested. =C2=A0(See the LRR draft for a definition of temporal nesting).=C2=A0 If t= his is the case, then VP9=E2=80=99s U bit wouldn=E2=80=99t need mapping =E2= =80=94 any VP9 stream which could validly have frame marking applied to it = would always have the U bit set to true, and MANEs could start sending temporal layers at any time.=C2=A0 I=E2=80=99d be fine with this restricti= on, but it would need to be written down explicitly; and I don=E2=80=99t un= derstand everyone else=E2=80=99s use cases well enough to be sure that no o= ne else would have a problem with it.

For the P bit, the issue is indeed about spatial layer switching-up po= ints.=C2=A0 Consider the following stream encoded with three spatial layers= :

=C2=A0 =C2=A0 = =C2=A0 =C2=A0=C2=A0... <--=C2=A0 S2=C2=A0 <--=C2=A0 S2 =C2=A0 =C2=A0 = =C2=A0 S2* <--=C2=A0 S2=C2=A0 <-- ...
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \/ =C2=A0 =C2=A0 =C2=A0 \/ = =C2=A0 =C2=A0 =C2=A0 \/ =C2=A0 =C2=A0 =C2=A0 \/
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 ... <--=C2=A0 S1=C2=A0 <--=C2=A0 S1=C2=A0 <--=C2=A0 = S1=C2=A0 <--=C2=A0 S1=C2=A0 <-- ...
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \/ =C2=A0 =C2=A0 =C2=A0 \/ = =C2=A0 =C2=A0 =C2=A0 \/ =C2=A0 =C2=A0 =C2=A0 \/
... <--=C2=A0 S0=C2=A0 <--=C2=A0 S0=C2=A0 <--= =C2=A0 S0=C2=A0 <--=C2=A0 S0=C2=A0 <-- ...

The frame marked with an asterisk is a layer refresh point for layer S= 2, and is a point at which a MANE which was previously forwarding just laye= r S1 could start sending S2 as well.=C2=A0 This frame would have the VP9 P = bit set.=C2=A0 However, as I understand it, it would *not* have the frame marking B or I bits set, nor any other field= s in the frame marking header extension which distinguish it.

Possibly the definition of the B bit could be changed somehow to provi= de this information, but I feel like the current B bit semantics provides o= ther functionality (about the decodability of non base-temporal-layer frame= s following loss) which we don=E2=80=99t want to break; I=E2=80=99m not sure how best to square this circle.


On Sep 1, 2017, at 6:15 PM, Mo Zanaty (mzanaty) <mzanaty@cisco.com> wrote:

Thanks for bumping this, Cullen.

At IETF 99, it was decided that priority marking beyond the Discardable
bit should go in a separate draft. Roni submitted
draft-even-avtcore-priority-markings for this. So that is closed.

The only other open issue was the mapping of the VP9 U/P bits to the frame<= br> marking B/I bits. In version 05 of frame marking, we already moved VP9
LID/TID mappings to the VP9 RTP payload draft. If the frame marking B/I
bits are sufficient for the needs of VP9 SVC applications, then the
mapping of VP9 U/P bits to frame marking B/I bits should also be
documented in the VP9 draft rather than frame marking, and we can request WGLC for frame marking without waiting for the VP9 draft updates. If the frame marking B/I bits are insufficient, or if their definition needs to be altered to support VP9 SVC applications, and the WG feels those
applications are important, then we need to finalize any changes needed
for frame marking B/I bits ASAP then start WGLC.

Jonathan, Sergio, Bernard,
You expressed interest in VP9 SVC applications. Are the frame marking B/I bits sufficient for your needs? If not, what are the specific issues we
need to address? Is it only switching up to a higher spatial layer when
there are multiple spatial enhancement layers?

Thanks,
Mo


On Sep 1, 2017, at 8:23 AM, Cullen Jennings <<= a href=3D"mailto:fluffy@iii.ca" target=3D"_blank">fluffy@iii.ca> wro= te:

I read this draft and did not see any issues. Where are we with this
draft and what happens next ?






--089e0820be30eef0110558a75e3c-- From nobody Wed Sep 13 18:00:33 2017 Return-Path: X-Original-To: avt@ietf.org Delivered-To: avt@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 376FE132F69; Wed, 13 Sep 2017 18:00:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: avtcore-chairs@ietf.org, ben@nostrum.com, Rachel@huawei.com, avt@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.61.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150535083118.12663.5019326644196439490.idtracker@ietfa.amsl.com> Date: Wed, 13 Sep 2017 18:00:31 -0700 Archived-At: Subject: [AVTCORE] avtcore - New Meeting Session Request for IETF 100 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.22 List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 01:00:31 -0000 A new meeting session request has just been submitted by Rachel Huang, a Chair of the avtcore working group. --------------------------------------------------------- Working Group Name: Audio/Video Transport Core Maintenance Area Name: Applications and Real-Time Area Session Requester: Rachel Huang Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 25 Conflicts to Avoid: First Priority: artarea dispatch mmusic payload perc quic rmcat rtcweb xrblock clue netvc ice Second Priority: bier ippm tsvarea tsvwg iccrg People who must be present: Jonathan Lennox Ben Campbell Rachel Huang Resources Requested: Special Requests: ---------------------------------------------------------