From nobody Wed Mar 1 12:11:00 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 6679C1296C1 for ; Wed, 1 Mar 2017 12:10:59 -0800 (PST) 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 PmBqqE3pXv-5 for ; Wed, 1 Mar 2017 12:10:56 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 AA1271296E3 for ; Wed, 1 Mar 2017 12:10:53 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id q7so20904301uaf.2 for ; Wed, 01 Mar 2017 12:10:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=uZis2famrRSnGbI0bdDOUlpZyGw/TXpM2/T+860ITI4=; b=qg2nmQX51EfBIRzRJH4MAKkFrvAuFPSxeojuICGCIb8D+XcifaQjZvAeVbElluSqJ1 CJAQoTz+Qw7YMnqkTXWfRA8insmgJr7xesQoFtPfaHSKaRNL5tBa4OfhB8zmwNGk80If B4l3LPN0Wbm0ccr0AwCvVBDhkZSOB98S+TJr750YJX4T8+4iTS5vzAqdzDTrjT40aOcf h+khIPxG7ZWbydEiSPYG0T+XAfHQI3aV8dLUA9BzSqhwATYgu/kcPZYZIPYjvwAb4nkl pjo1kWvUW2I2NisIpxQmMf8H9R10DjGyfoXS8J1QMc13gDrNr34+z9cPA3MCosl+lGHA j1nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=uZis2famrRSnGbI0bdDOUlpZyGw/TXpM2/T+860ITI4=; b=LUo2nluZ69XhB/NTjsOflU+IHAm9XAeEYlM478Tcwhv+DuejlBiDaU1m8WavZ8jCxE /jmTY9jZ0UWgb0Zbf92yJzjBiHgXIQ9+nAP5EkQrkIy+nDa5TSrnLuG7iYtkFa10joWC LyKa4V1eHv9ZeAMtjUbY5V+5cROI/cQKWGMNoWeqQ2n0FmHiXr5edjcE+E9oYyoDjhHr +Raxn2r0cpalrEbJegX6U01PKiPv5RwG22y6BaDnhTSGt3g3UBW+rzRTojIJvfFIw5tF 3dwVgnWPFzGpS4HYrWsarbfAZedacjd5PNMs4i9FhsXu2njLQAsqABAWdwNv4dnzLpK7 X7JQ== X-Gm-Message-State: AMke39notWz4sBgWpP3ZF/Cd559aryBGq3KdD0PTF2Gdupg0BBPG0RWnWOBIrbSXgInPwfoyZG4asNsCtOg/XA== X-Received: by 10.159.36.10 with SMTP id 10mr5290236uaq.124.1488399051986; Wed, 01 Mar 2017 12:10:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.88.90 with HTTP; Wed, 1 Mar 2017 12:10:31 -0800 (PST) From: Bernard Aboba Date: Wed, 1 Mar 2017 12:10:31 -0800 Message-ID: To: avtext@ietf.org Content-Type: multipart/alternative; boundary=001a113df684c721660549b0e893 Archived-At: Subject: [avtext] draft-ietf-avtext-framemarking and FEC X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 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, 01 Mar 2017 20:10:59 -0000 --001a113df684c721660549b0e893 Content-Type: text/plain; charset=UTF-8 So far, discussion on framemarking has focused on conveying information about video frames useful to an SFU. In video forwarding scenarios, forward error correction can be used to protect one or more layers. Today, typically robustness (FEC or RTX) is dealt with hop-by-hop, not end-to-end. For example, FEC is consumed and re-generated by the SFU which receives video frames and repairs via the received FEC if it can.The SFU decides which video frames to forward (such as by using info in the frame marking header), and will regenerate an FEC stream corresponding to the forwarded stream. My question is whether hop-by-hop robustness is expected to continue with PERC so that the payloads of FEC packets would be available to the SFU, or whether FEC payload would also be encrypted so that FEC would be end-to-end. If FEC becomes end-to-end, do those packets also need to be marked? --001a113df684c721660549b0e893 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So far, discussion on framemarking has focused on conveyin= g information about video frames useful to an SFU.=C2=A0

In video forwarding scenarios, forward error correction can be used to pro= tect one or more layers.=C2=A0

Today, typically ro= bustness (FEC or RTX) is dealt with hop-by-hop, not end-to-end.=C2=A0 For e= xample, FEC is consumed and re-generated by the SFU which receives video fr= ames and repairs via the received FEC if it can.The SFU decides which video= frames to forward (such as by using info in the frame marking header), and= will regenerate an FEC stream corresponding to the forwarded stream.=C2=A0=

My question is whether hop-by-hop robustness is e= xpected to continue with PERC so that the payloads of FEC packets would be = available to the SFU, or whether FEC payload would also be encrypted so tha= t FEC would be end-to-end.=C2=A0

If FEC becomes en= d-to-end, do those packets also need to be marked?=C2=A0
--001a113df684c721660549b0e893-- From nobody Fri Mar 3 15:59:46 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 851A5129A00; Fri, 3 Mar 2017 15:55:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148858533053.15846.16177063560210445798.idtracker@ietfa.amsl.com> Date: Fri, 03 Mar 2017 15:55:30 -0800 Archived-At: Cc: avtext@ietf.org Subject: [avtext] avtext - Requested session has been scheduled for IETF 98 X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 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, 03 Mar 2017 23:55:30 -0000 Dear Rachel Huang, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. avtext Session 1 (1:00:00) Tuesday, Morning Session I 0900-1130 Room Name: Zurich A size: 115 --------------------------------------------- Special Note: 10:30-11:30 Request Information: --------------------------------------------------------- Working Group Name: Audio/Video Transport Extensions 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: rtcweb payload rmcat xrblock mmusic quic dispatch netvc perc Second Priority: tram sipcore stir tsvwg taps aqm People who must be present: Jonathan Lennox Ben Campbell Rachel Huang Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Mar 8 09:33:35 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 E278E1296FF; Wed, 8 Mar 2017 09:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.76 X-Spam-Level: * X-Spam-Status: No, score=1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.08, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.281, 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 JdoQjt3O4V7e; Wed, 8 Mar 2017 09:33:33 -0800 (PST) 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 5B68A1297ED; Wed, 8 Mar 2017 09:33:33 -0800 (PST) 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 v28HTK1a017691; Wed, 8 Mar 2017 12:33:25 -0500 Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 28yvxctp2q-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 08 Mar 2017 12:33:25 -0500 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, 8 Mar 2017 11:33:24 -0600 From: Jonathan Lennox To: IETF AVTCore WG Thread-Topic: Please send agenda requests for AVTCORE Thread-Index: AQHSmDIWohlsfb1Q0Eq6wgKxj/7dqw== Date: Wed, 8 Mar 2017 17:33:23 +0000 Message-ID: <1818BA63-AF40-4A09-8698-D0D35A1844C3@vidyo.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: <738EA8CFCE27C64686B77910A69FEEE8@vidyo.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-03-08_13:, , 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-1702020001 definitions=main-1703080139 Archived-At: Cc: "avtext@ietf.org" Subject: [avtext] Please send agenda requests for AVTCORE X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 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, 08 Mar 2017 17:33:34 -0000 SGVsbG8sIGFsbCDigJQNCg0KQXMgQmVuIHNhaWQsIFJhY2hlbCBhbmQgSSBhcmUgbm93IHRoZSBj aGFpcnMgb2YgdGhlIHJlLW1lcmdlZCBBVlRDT1JFIHdvcmtpbmcgZ3JvdXAuICAoVGhhbmtzIHRv IE1hZ251cyBhbmQgUm9uaSBmb3IgdGhlaXIgeWVhcnMgb2Ygd29yayEpDQoNCkFsbCBBVlRFWFQg bWlsZXN0b25lcyBhbmQgd29ya2luZyBncm91cCBpdGVtcyBhcmUgbm93IEFWVENPUkUgaW5zdGVh ZC4NCg0KQXMgc3VjaCwgcGxlYXNlIHNlbmQgdXMgYW55IGFnZW5kYSByZXF1ZXN0cyBmb3IgdGhl IEFWVENPUkUgc2Vzc2lvbiBpbiBDaGljYWdvLiAgVGhhbmtzIQ0KDQpKb25hdGhhbg0KDQo= From nobody Thu Mar 9 11:06:15 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 C10BE12945A; Thu, 9 Mar 2017 11:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 9FPB0YAF0hZC; Thu, 9 Mar 2017 11:06:09 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 997CD129452; Thu, 9 Mar 2017 11:06:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5347; q=dns/txt; s=iport; t=1489086369; x=1490295969; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Pr8hvkNYc3zHiUszYJEV8zS5npFQV6B0R9q3kIWwZ2A=; b=lyZpejkLY1F/GxdtFXIp7yiVlcgGe4vTitQjXKMkHhXMFs7+hesmAOxG vDBMiGfqynZs80BHLI1htlgPUvNR+8bS2e0SzwANlly0AhgfzJ+VDKQyr X1d9i473d9NhS+kEKJ7/hrP/daVoQNGZBaTL9EOjCQrz8XCvrbMJ9jBvl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CGAQC9psFY/4MNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm5jgWsHg1mKDJFPhiOBaod+hS2CDoYiAoIxPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUVAQEBAQMEHARVEAIBCAQNAwECKAQDIQkIFAkIAgQBDQWJaAMVsRIMgiWHN?= =?us-ascii?q?g2DIwEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GToRvglGCI4Jngl4Fm386AY4MhCu?= =?us-ascii?q?Be48liESCEIhqAR84gQNWFYcTdYkegQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,137,1486425600"; d="scan'208,217";a="395679676" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Mar 2017 19:06:08 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v29J68BQ018189 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Mar 2017 19:06:08 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 9 Mar 2017 13:06:08 -0600 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.1210.000; Thu, 9 Mar 2017 13:06:08 -0600 From: "Mo Zanaty (mzanaty)" To: Bernard Aboba , Emil Ivov , Boris Grozev Thread-Topic: [avtext] draft-ietf-avtext-framemarking and FEC Thread-Index: AQHSmQg1frQLKhEX+0Sxuj+szvmizA== Date: Thu, 9 Mar 2017 19:06:07 +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.1.161129 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.238.74] Content-Type: multipart/alternative; boundary="_000_D4E70BF46AB64mzanatyciscocom_" MIME-Version: 1.0 Archived-At: Cc: "avtext@ietf.org" , "perc@ietf.org" Subject: Re: [avtext] draft-ietf-avtext-framemarking and FEC X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 09 Mar 2017 19:06:10 -0000 --_000_D4E70BF46AB64mzanatyciscocom_ Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Hi Bernard, Adding PERC for your question on HBH vs E2E FEC/RTX. I expected HBH but don= 't think this has been discussed. Adding Emil and Boris as they plan to sub= mit/present a PERC draft related to this (RTX). Frame marking was intended for Source RTP Streams not Redundancy RTP Stream= s [RFC 7656]. I will update the draft to reflect this. If E2E encrypted red= undancy streams need some type of marking, I would recommend a separate mar= king mechanism rather than overloading or extending the current video frame= marking draft. Thanks, Mo From: avtext > on b= ehalf of Bernard Aboba > Date: Wednesday, March 1, 2017 at 3:10 PM To: "avtext@ietf.org" > Subject: [avtext] draft-ietf-avtext-framemarking and FEC So far, discussion on framemarking has focused on conveying information abo= ut video frames useful to an SFU. In video forwarding scenarios, forward error correction can be used to prot= ect one or more layers. Today, typically robustness (FEC or RTX) is dealt with hop-by-hop, not end-= to-end. For example, FEC is consumed and re-generated by the SFU which rec= eives video frames and repairs via the received FEC if it can.The SFU decid= es which video frames to forward (such as by using info in the frame markin= g header), and will regenerate an FEC stream corresponding to the forwarded= stream. My question is whether hop-by-hop robustness is expected to continue with P= ERC so that the payloads of FEC packets would be available to the SFU, or w= hether FEC payload would also be encrypted so that FEC would be end-to-end. If FEC becomes end-to-end, do those packets also need to be marked? --_000_D4E70BF46AB64mzanatyciscocom_ Content-Type: text/html; charset="windows-1251" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Bernard,

Adding PERC for your question on HBH vs E2E FEC/RTX. I expected HBH bu= t don't think this has been discussed. Adding Emil and Boris as they plan t= o submit/present a PERC draft related to this (RTX).

Frame marking was intended for Source RTP Streams not Redundancy RTP S= treams [RFC 7656]. I will update the draft to reflect this. If E2E encrypte= d redundancy streams need some type of marking, I would recommend a separat= e marking mechanism rather than overloading or extending the current video frame marking draft.

Thanks,
Mo

From: avtext <avtext-bounces@ietf.org> on behalf of Berna= rd Aboba <bernard.aboba@gmail= .com>
Date: Wednesday, March 1, 2017 at 3= :10 PM
To: "avtext@ietf.org" <= avtext@ietf.org>
Subject: [avtext] draft-ietf-avtext= -framemarking and FEC

So far, discussion on framemarking has focused on conveyin= g information about video frames useful to an SFU. 

In video forwarding scenarios, forward error correction can be used to= protect one or more layers. 

Today, typically robustness (FEC or RTX) is dealt with hop-by-hop, not= end-to-end.  For example, FEC is consumed and re-generated by the SFU= which receives video frames and repairs via the received FEC if it can.The= SFU decides which video frames to forward (such as by using info in the frame marking header), and will regenerate a= n FEC stream corresponding to the forwarded stream. 

My question is whether hop-by-hop robustness is expected to continue w= ith PERC so that the payloads of FEC packets would be available to the SFU,= or whether FEC payload would also be encrypted so that FEC would be end-to= -end. 

If FEC becomes end-to-end, do those packets also need to be marked?&nb= sp;
 --_000_D4E70BF46AB64mzanatyciscocom_-- From nobody Thu Mar 9 18:41:39 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 DFE4F1294B2; Thu, 9 Mar 2017 18:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 EH9ZlMx3Lf6C; Thu, 9 Mar 2017 18:41:32 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8831294E1; Thu, 9 Mar 2017 18:41:32 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 35E11B80184; Thu, 9 Mar 2017 18:06:13 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20170310020613.35E11B80184@rfc-editor.org> Date: Thu, 9 Mar 2017 18:06:13 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, avtext@ietf.org, rfc-editor@rfc-editor.org Subject: [avtext] RFC 8082 on Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 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, 10 Mar 2017 02:41:34 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8082 Title: Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs Author: S. Wenger, J. Lennox, B. Burman, M. Westerlund Status: Standards Track Stream: IETF Date: March 2017 Mailbox: stewe@stewe.org, jonathan@vidyo.com, bo.burman@ericsson.com, magnus.westerlund@ericsson.com Pages: 11 Characters: 25093 Updates: RFC 5104 I-D Tag: draft-ietf-avtext-avpf-ccm-layered-04.txt URL: https://www.rfc-editor.org/info/rfc8082 DOI: 10.17487/RFC8082 This document updates RFC 5104 by fixing a shortcoming in the specification language of the Codec Control Message Full Intra Request (FIR) description when using it with layered codecs. In particular, a decoder refresh point needs to be sent by a media sender when a FIR is received on any layer of the layered bitstream, regardless of whether those layers are being sent in a single or in multiple RTP flows. The other payload-specific feedback messages defined in RFC 5104 and RFC 4585 (which was updated by RFC 5506) have also been analyzed, and no corresponding shortcomings have been found. This document is a product of the Audio/Video Transport Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Mar 13 17:03:05 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 84441129B04; Mon, 13 Mar 2017 17:03:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148944978452.20333.12646852221818497460@ietfa.amsl.com> Date: Mon, 13 Mar 2017 17:03:04 -0700 Archived-At: Cc: avtext@ietf.org Subject: [avtext] I-D Action: draft-ietf-avtext-framemarking-04.txt X-BeenThere: avtext@ietf.org X-Mailman-Version: 2.1.17 List-Id: Audio/Video Transport Extensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 00:03:04 -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-04.txt Pages : 11 Date : 2017-03-13 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-avtext-framemarking-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-framemarking-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 27 00:43:18 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 612C212949B; Mon, 27 Mar 2017 00:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 hrF-n98k-5Il; Mon, 27 Mar 2017 00:43:08 -0700 (PDT) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 4B86C129463; Mon, 27 Mar 2017 00:43:08 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id d191so25405478ywe.2; Mon, 27 Mar 2017 00:43:08 -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=mPS8lcSH7pHRAn+YUDZ+BvYETb2lGky+LgtesjZqq6Y=; b=W7zoochEFOQ5gg2kS98hxxbFm9YjOXSX8HwElq/Jt9AanZUhxdibPws9yL+aqUpqWB ydH3K0weuQGuXBzN9tTwodDn4qUu+X0Kj7e8gkQ9QRqimkYaREnZaNDA1l4RMy9svkrU jLyDzFWUgP4qUioO8HonagZpHUVXKqUp8Gow0C3Ceg2gcj2POIqvIFKQ6r1r+KHdahhb HiiVXrcBz/EgTDlrXNUDvgrm6DmPbybWBuWOF4FgIH+UTLmugCWg+IvX75Z+ITfIcQb5 vBGIRVeC64dyyTIjgmi2adUZVSvqjFFFbIDNKnRI0qSqQrKoUBkwLuAu9p9Wb+HI4eZH 66sg== 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=mPS8lcSH7pHRAn+YUDZ+BvYETb2lGky+LgtesjZqq6Y=; b=aoadpdLHBres+1QaomgmdSUHKBPso+d+VtaZpZv7XU9tgkecfQjWY07vnZSgyuJSdM Xr0cUfzaif4+6HSBgx6pjOenmesz/2qh730/guKtlPpqry910bZEw4hhAS2RtxyBgrHL ajS5k39aNZ+bigO5guDHaM4Y2NmW54L/qtkzFnd4vjlfNa7K+0yi1n8jVkWqws57FEEE MwC4kl5C/UluhPoCeYazaYGicCyrtZZfvxmDy0gchssj8XDteUcgMYB6f5WfAJzGNpAC pHPiuH3Qg+TLiRCVHBSBSSlwZCA9/sq9RMjNWkVuc5yvn5jmTaOHctFmJeVwLP0F4je6 lp+Q== X-Gm-Message-State: AFeK/H3+k7WdZxzmI1+9VPibNWG4pmQRDrnZ2c/lYH74S+HNFVULJzPks5GfBhhjhqr3vgoYSIshJ3KrvpHPhw== X-Received: by 10.129.125.5 with SMTP id y5mr15437149ywc.120.1490600587208; Mon, 27 Mar 2017 00:43:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.230.73 with HTTP; Mon, 27 Mar 2017 00:43:06 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Miguel_Par=C3=ADs_D=C3=ADaz?= Date: Mon, 27 Mar 2017 09:43:06 +0200 Message-ID: To: Jonathan Lennox Cc: "Paul E. Jones" , "avtext@ietf.org" , mmusic Content-Type: multipart/alternative; boundary=001a1149364480cfa5054bb17ee0 Archived-At: Subject: Re: [avtext] framemarking: add frame size info 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, 27 Mar 2017 07:43:11 -0000 --001a1149364480cfa5054bb17ee0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello again, is there anybody considering this proposal, or nobody see the benefits? Kind regards!! 2016-11-10 15:18 GMT+01:00 Miguel Par=C3=ADs D=C3=ADaz : > Hello, > in the new draft of sdp-simulcast an "RTP Aspect" section [1] has been > added, which explains how the media is handled on RTP level. > > Specifically, In the Media-Switching Mixer section [2] the same thoughts = I > exposed are said: > > This section discusses the behavior in cases where the RTP middlebox > behaves like the Media-Switching Mixer (Section 3.6.2 ) in RTP > Topologies [RFC7667 ]. The funda= mental aspect here is that the media > sources delivered from the middlebox will be the mixer's conceptual > or functional ones. For example, one media source may be the main > speaker in high resolution video, while a number of other media > sources are thumbnails of each participant. > > The above results in that the RTP stream produced by the mixer is one > that switches between a number of received incoming RTP streams for > different media sources and in different simulcast versions. The > mixer selects the media source to be sent as one of the RTP streams, > and then selects among the available simulcast streams for the most > appropriate one. The selection criteria include available bandwidth > on the mixer to receiver path and restrictions based on the > functional usage of the RTP stream delivered to the receiver. An > example of the latter, is that it is unnecessary to forward a full HD > video to a receiver if the display area is just a thumbnail. Thus, > restrictions may exist to not allow some simulcast streams to be > forwarded for some of the mixer's media sources. > > > In our case to provide this feature, currently we have to depay the RTP > packets, and apply different types of parses (depending on the codec) to > read the frame size, which reduces the scalability of the system and hind= er > the implementation a lot. > Because of that, I think that having frame size (width and height) info i= n > the Frame Marking RTP header extension is quite interesting to implement > this kind of use cases in a easy and efficient way (the same that an > audio-level extension header is provided to avoid analysing it in the > middlebox side). > > I am adding MMUSIC group in the thread, because I think that this also > should be discussed in the context of the simulcast case. > > Best!! > > Refs > [1] https://tools.ietf.org/html/draft-ietf-mmusic-sdp- > simulcast-06#section-7.2 > [2] https://tools.ietf.org/html/draft-ietf-mmusic-sdp- > simulcast-06#section-7.2.1 > > > 2016-08-30 12:37 GMT+02:00 Miguel Par=C3=ADs D=C3=ADaz : > >> I assume that the media distributor has the information from the SDP (it >> performs the SDP negotiation which each "client"), but the point is that >> encoders may change the video size depending on the available bandwidth, >> the complexivity of the video source, etc., unless the sender forces the >> encoders' configuration with a fix frame size... >> >> >> 2016-08-26 19:07 GMT+02:00 Jonathan Lennox : >> >>> (As an individual.) >>> >>> In the latest version of simulcast the media distributor would need the >>> RID values, not the PT values, but the idea is the same =E2=80=94 it ne= eds the SDP. >>> >>> Note that if the media distributor doesn=E2=80=99t have information fro= m the SDP >>> it can=E2=80=99t reliably identify the frame marking header extension a= t all, since >>> header extension IDs are negotiated. So I=E2=80=99m not sure how much b= enefit there >>> is to putting the size in the header extension. >>> >>> That said, if we envision a scenario where encoders might be frequently >>> changing their video size (in response to available network bandwidth, = or >>> the like), it might be useful for encoders to be able to indicate the >>> current size they=E2=80=99re encoding without needing to send updated S= DP all the >>> time. >>> >>> On Aug 26, 2016, at 12:52 PM, Paul E. Jones >>> wrote: >>> >>> Miguel, >>> >>> You make the assumption that the media distributor will not see the SDP= , >>> I suppose. While certainly a valid model, I'll admit that I had person= ally >>> assumed any media forwarding function would see the SDP (or at least be >>> told the PT values and any relevant flow information similar to what RF= C >>> 6236 provides) and would thus know which PT values correspond to what v= ideo >>> resolutions if simulcast is employed. >>> >>> Paul >>> >>> ------ Original Message ------ >>> From: "Miguel Par=C3=ADs D=C3=ADaz" >>> To: avtext@ietf.org >>> Sent: 8/25/2016 10:12:48 AM >>> Subject: [avtext] framemarking: add frame size info >>> >>> Hello, >>> it would be great having frame size (width and height) info in the Fram= e >>> Marking RTP header extension [1]. >>> >>> Why? >>> For example, in the case of using simulcast in an SFU, selecting the >>> stream by the size would ease the application development and improve t= he >>> experience of the users. >>> Application developers don't usually have deep knowledge about media >>> like bitrate, etc., but they know which video size has to be rendered i= n >>> the GUI, which may depend on the client where the app is running: a mob= ile, >>> a PC with a 13"=C2=B7 screen, a PC with 27" screen, etc. >>> >>> In this way and taking a videoconference app as example, if a >>> participant select another participant to be rendered as main video, th= e >>> app could ask the SFU to select the video quality that better matches t= o >>> 800x600 size. >>> >>> What do you think about this idea? >>> >>> Thanks and best regards!! >>> >>> Refs >>> [1] https://tools.ietf.org/html/draft-ietf-avtext-framemarking-02 >>> >>> -- >>> Miguel Par=C3=ADs D=C3=ADaz >>> -----------------------------------------------------------------------= - >>> Computer/Software engineer. >>> Researcher and architect in http://www.kurento.org >>> http://twitter.com/mparisdiaz >>> -----------------------------------------------------------------------= - >>> >>> _______________________________________________ >>> avtext mailing list >>> avtext@ietf.org >>> https://www.ietf.org/mailman/listinfo/avtext >>> >>> >>> >> >> >> -- >> Miguel Par=C3=ADs D=C3=ADaz >> ------------------------------------------------------------------------ >> Computer/Software engineer. >> Researcher and architect in http://www.kurento.org >> http://twitter.com/mparisdiaz >> ------------------------------------------------------------------------ >> > > > > -- > Miguel Par=C3=ADs D=C3=ADaz > ------------------------------------------------------------------------ > Computer/Software engineer. > Researcher and architect in http://www.kurento.org > http://twitter.com/mparisdiaz > ------------------------------------------------------------------------ > --=20 Miguel Par=C3=ADs D=C3=ADaz ------------------------------------------------------------------------ Computer/Software engineer. Researcher and architect in http://www.kurento.org http://twitter.com/mparisdiaz ------------------------------------------------------------------------ --001a1149364480cfa5054bb17ee0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello again,
is there anybody consideri= ng this proposal, or nobody see the benefits?

Kind regards!!

2016-11-1= 0 15:18 GMT+01:00 Miguel Par=C3=ADs D=C3=ADaz <mparisdiaz@gmail.com= >:
Hello,
in the new draft = of sdp-simulcast an "RTP Aspect" section [1] has been added, whic= h explains how the media is handled on RTP level.

Specifically= , In the Media-Switching Mixer section [2] the same thoughts I exposed are = said:
   This section=
 discusses the behavior in cases where the RTP middlebox
   behaves like the Media-Switching Mixer (=
Section 3.6.2) in RTP
   Topologies [RFC7667].  The fundamental a=
spect here is that the media
   sources delivered from the middlebox will be the mixer's conceptual
   or functional ones.  For example, one media source may be the main
   speaker in high resolution video, while a number of other media
   sources are thumbnails of each participant.

   The above results in that the RTP stream produced by the mixer is one
   that switches between a number of received incoming RTP streams for
   different media sources and in different simulcast versions.  The
   mixer selects the media source to be sent as one of the RTP streams,
   and then selects among the available simulcast streams for the most
   appropriate one.  The selection criteria include available bandwidth
   on the mixer to receiver path and restrictions based on the
   functional usage of the RTP stream delivered to the receiver.  An
   example of the latter, is that it is unnecessary to forward a full HD
   video to a receiver if the display area is just a thumbnail.  Thus,
   restrictions may exist to not allow some simulcast streams to be
   forwarded for some of the mixer's media sources.
=
In our case to provide this feature, currently we have to de= pay the RTP packets, and apply different types of parses (depending on the = codec) to read the frame size, which reduces the scalability of the system = and hinder the implementation a lot.
Because of that, I think= that having frame size (width and height) info in the=20 Frame Marking RTP header extension is quite interesting to implement=20 this kind of use cases in a easy and efficient way (the same that an audio-= level extension header is provided to avoid analysing it in the middlebox s= ide).

I am adding MMUSIC group in the thread, = because I think that this also should be discussed in the context of the si= mulcast case.

Best!!


2016-08-30 12:37 GMT+02:00 Miguel Par=C3=ADs D=C3=ADaz = <mparisdiaz@gm= ail.com>:
= I assume that the media distributor has the information from the SDP (it pe= rforms the SDP negotiation which each "client"), but the point is= that encoders may change the video size depending on the available bandwid= th, the complexivity of the video source, etc., unless the sender forces th= e encoders' configuration with a fix frame size...


2016-08-26 19:0= 7 GMT+02:00 Jonathan Lennox <jonathan@vidyo.com>:
(As an individual.)

In the latest version of simulcast the media distributor would need th= e RID values, not the PT values, but the idea is the same =E2=80=94 it need= s the SDP.

Note that if the media distributor doesn=E2=80=99t have information fr= om the SDP it can=E2=80=99t reliably identify the frame marking header exte= nsion at all, since header extension IDs are negotiated. So I=E2=80=99m not= sure how much benefit there is to putting the size in the header extension.

That said, if we envision a scenario where encoders might be frequentl= y changing their video size (in response to available network bandwidth, or= the like), it might be useful for encoders to be able to indicate the curr= ent size they=E2=80=99re encoding without needing to send updated SDP all the time.

On Aug 26, 2016, at 12:52 PM, Paul E. Jones <paulej@packetizer.com> wrote:
Miguel,

You make the assumption that the media distributor will not see the SDP, I = suppose.=C2=A0 While certainly a valid model, I'll admit that I had per= sonally assumed any media forwarding function would see the SDP (or at leas= t be told the PT values and any relevant flow information similar to what RFC 6236 provides) and would thus know wh= ich PT values correspond to what video resolutions if simulcast is employed= .

Paul

------ Original Message ------
From: "Miguel Par=C3=ADs D=C3=ADaz" <mparisdiaz@gmail.com>
Sent: 8/25/2016 10:12:48 AM
Subject: [avtext] framemarking: add frame size info

Hello,
it would be great having frame size (width and height) info in the Fra= me Marking RTP header extension [1].

Why?
For example, in the case of using simulcast in an SFU, selecting the s= tream by the size would ease the application development and improve the ex= perience of the users.
Application developers don't usually have deep knowledge about med= ia like bitrate, etc., but they know which video size has to be rendered in= the GUI, which may depend on the client where the app is running: a mobile= , a PC with a 13"=C2=B7 screen, a PC with 27" screen, etc.

In this way and taking a videoconference app as example, if a particip= ant select another participant to be rendered as main video, the app could = ask the SFU to select the video quality that better matches to 800x600 size= .

What do you think about this idea?

Thanks and best regards!!

Refs
[1]=C2=A0https://tools.ietf.org/html/dra= ft-ietf-avtext-framemarking-02

--=C2=A0
Miguel Par=C3=ADs D=C3=ADaz
-----------------------------------------------------------------= -------
Computer/Software engineer.
Researcher and architect in=C2=A0http://www.kurento.org
http://twitter.= com/mparisdiaz
-----------------------------------------------------------------= -------
_______________________________________________<= /span>
avtext mailing list
avtext@ietf.org
https://www.ietf.org/mailman/listinfo/avtext




--
Miguel Par=C3=ADs D=C3=ADaz
---------------= ---------------------------------------------------------
Comp= uter/Software engineer.
Researcher and architect in http://www.kurento.org
http://twitter.com/mparisdi= az
------------------------------------------------------------= ------------



--
Miguel Par=C3=ADs D=C3=ADaz
------------------------= ------------------------------------------------
Computer/Soft= ware engineer.
Researcher and architect in http://www.kurento.org
http://twitter.com/mparisdiaz----------------------------------------------------------------= --------



--
Mi= guel Par=C3=ADs D=C3=ADaz
----------------------------------------------= --------------------------
Computer/Software engineer.
Researcher and= architect in http://w= ww.kurento.org
http://twitter.com/mparisdiaz
-------------------------------= -----------------------------------------
--001a1149364480cfa5054bb17ee0-- From nobody Mon Mar 27 08:10:58 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 DF870129739; Mon, 27 Mar 2017 08:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 UKSKk0FVCwQM; Mon, 27 Mar 2017 08:10:45 -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 52E4B129452; Mon, 27 Mar 2017 08:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35008; q=dns/txt; s=iport; t=1490627445; x=1491837045; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yokPB9x+mOsNyzalEbA86NnY5E47reCOnpbrmu7jk2A=; b=GSfZWNJ1tzUVAMiyEBrlXELO2zkYWggDqKhLwYLLpP8XiRNCSYib//LH fR3R0n9HLwMhQ2dk1d3Jj2bLzX82vrq7R7zZljd3ofz14zlIV2t15lIKe rYukzOErucTn5vRxvAGTiS5jTJ4fbIsS4CQ1BZPgYiwr94ZgR3Utj9Pzf Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DJAQAvKtlY/51dJa1SCgEYAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCbjsrYYELB4NbY4kskU2IF400gg4fAQyCQIJsSgIagns/GAE?= =?us-ascii?q?CAQEBAQEBAWsohRUBAQEBAwEBITIZCwwEAgEIEQMBAQEhBwMCAgIfBgsUCQgCB?= =?us-ascii?q?AENBQkSiVQDFQ6rX4Imhy8NgwMBAQEBAQEBAQEBAQEBAQEBAQEBAQEdhk6DZoE?= =?us-ascii?q?JglGBWyQUBwkegkiCXwWJHgeMZ4YVOgGGeocbhDaBfFSBC4cihjSKbQIkhCyEJ?= =?us-ascii?q?QEfOIEEWRVBhB85HYFjdQEBiCaBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,232,1486425600"; d="scan'208,217";a="214964986" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Mar 2017 15:10:43 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v2RFAhlD016944 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Mar 2017 15:10:44 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Mar 2017 10:10:43 -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.1210.000; Mon, 27 Mar 2017 10:10:42 -0500 From: "Mo Zanaty (mzanaty)" To: =?utf-8?B?TWlndWVsIFBhcsOtcyBEw61heg==?= , "Jonathan Lennox" CC: "avtext@ietf.org" , mmusic Thread-Topic: [MMUSIC] [avtext] framemarking: add frame size info Thread-Index: AQHSpwxN7LteRg2zYk6+J0YoGnCPzQ== Date: Mon, 27 Mar 2017 15:10:42 +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.2.170228 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.211.33] Content-Type: multipart/alternative; boundary="_000_D4FEA22D6B914mzanatyciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [avtext] [MMUSIC] framemarking: add frame size info 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, 27 Mar 2017 15:10:49 -0000 --_000_D4FEA22D6B914mzanatyciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWlndWVsLA0KDQpUaGlzIHdhcyBkaXNjdXNzZWQgaW4gSUVURiA5NyBkdXJpbmcgdGhlIEFW VEVYVCBzZXNzaW9uIG9uIEZyYW1lIE1hcmtpbmcuDQpTZWUgdGhlIHNsaWRlcyBhbmQgbWludXRl cy4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy85Ny9zZXNzaW9uL2F2dGV4 dA0KDQpUaGUgcmVjb21tZW5kZWQgYW5kIGFncmVlZCBzb2x1dGlvbiB3YXMgdG8gdXNlIFJJRCBy YXRoZXIgdGhhbiBhZGQgZnJhbWUgc2l6ZQ0KaW4gdGhlIEZyYW1lIE1hcmtpbmcgaGVhZGVyIGV4 dGVuc2lvbi4NCg0KVGhhbmtzLA0KTW8NCg0KDQpGcm9tOiBtbXVzaWMgPG1tdXNpYy1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBN aWd1ZWwgUGFyw61zIETDrWF6IDxtcGFyaXNkaWF6QGdtYWlsLmNvbTxtYWlsdG86bXBhcmlzZGlh ekBnbWFpbC5jb20+Pg0KRGF0ZTogTW9uZGF5LCBNYXJjaCAyNywgMjAxNyBhdCAzOjQzIEFNDQpU bzogSm9uYXRoYW4gTGVubm94IDxqb25hdGhhbkB2aWR5by5jb208bWFpbHRvOmpvbmF0aGFuQHZp ZHlvLmNvbT4+DQpDYzogImF2dGV4dEBpZXRmLm9yZzxtYWlsdG86YXZ0ZXh0QGlldGYub3JnPiIg PGF2dGV4dEBpZXRmLm9yZzxtYWlsdG86YXZ0ZXh0QGlldGYub3JnPj4sICJtbXVzaWNAaWV0Zi5v cmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4iIDxtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNp Y0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW01NVVNJQ10gW2F2dGV4dF0gZnJhbWVtYXJraW5n OiBhZGQgZnJhbWUgc2l6ZSBpbmZvDQoNCkhlbGxvIGFnYWluLA0KaXMgdGhlcmUgYW55Ym9keSBj b25zaWRlcmluZyB0aGlzIHByb3Bvc2FsLCBvciBub2JvZHkgc2VlIHRoZSBiZW5lZml0cz8NCg0K S2luZCByZWdhcmRzISENCg0KMjAxNi0xMS0xMCAxNToxOCBHTVQrMDE6MDAgTWlndWVsIFBhcsOt cyBEw61heiA8bXBhcmlzZGlhekBnbWFpbC5jb208bWFpbHRvOm1wYXJpc2RpYXpAZ21haWwuY29t Pj46DQpIZWxsbywNCmluIHRoZSBuZXcgZHJhZnQgb2Ygc2RwLXNpbXVsY2FzdCBhbiAiUlRQIEFz cGVjdCIgc2VjdGlvbiBbMV0gaGFzIGJlZW4gYWRkZWQsIHdoaWNoIGV4cGxhaW5zIGhvdyB0aGUg bWVkaWEgaXMgaGFuZGxlZCBvbiBSVFAgbGV2ZWwuDQoNClNwZWNpZmljYWxseSwgSW4gdGhlIE1l ZGlhLVN3aXRjaGluZyBNaXhlciBzZWN0aW9uIFsyXSB0aGUgc2FtZSB0aG91Z2h0cyBJIGV4cG9z ZWQgYXJlIHNhaWQ6DQoNCiAgIFRoaXMgc2VjdGlvbiBkaXNjdXNzZXMgdGhlIGJlaGF2aW9yIGlu IGNhc2VzIHdoZXJlIHRoZSBSVFAgbWlkZGxlYm94DQogICBiZWhhdmVzIGxpa2UgdGhlIE1lZGlh LVN3aXRjaGluZyBNaXhlciAoU2VjdGlvbiAzLjYuMjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0wNiNzZWN0aW9uLTMuNi4yPikgaW4g UlRQDQogICBUb3BvbG9naWVzIFtSRkM3NjY3PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM3NjY3Pl0uICBUaGUgZnVuZGFtZW50YWwgYXNwZWN0IGhlcmUgaXMgdGhhdCB0aGUgbWVkaWEN CiAgIHNvdXJjZXMgZGVsaXZlcmVkIGZyb20gdGhlIG1pZGRsZWJveCB3aWxsIGJlIHRoZSBtaXhl cidzIGNvbmNlcHR1YWwNCiAgIG9yIGZ1bmN0aW9uYWwgb25lcy4gIEZvciBleGFtcGxlLCBvbmUg bWVkaWEgc291cmNlIG1heSBiZSB0aGUgbWFpbg0KICAgc3BlYWtlciBpbiBoaWdoIHJlc29sdXRp b24gdmlkZW8sIHdoaWxlIGEgbnVtYmVyIG9mIG90aGVyIG1lZGlhDQogICBzb3VyY2VzIGFyZSB0 aHVtYm5haWxzIG9mIGVhY2ggcGFydGljaXBhbnQuDQoNCiAgIFRoZSBhYm92ZSByZXN1bHRzIGlu IHRoYXQgdGhlIFJUUCBzdHJlYW0gcHJvZHVjZWQgYnkgdGhlIG1peGVyIGlzIG9uZQ0KICAgdGhh dCBzd2l0Y2hlcyBiZXR3ZWVuIGEgbnVtYmVyIG9mIHJlY2VpdmVkIGluY29taW5nIFJUUCBzdHJl YW1zIGZvcg0KICAgZGlmZmVyZW50IG1lZGlhIHNvdXJjZXMgYW5kIGluIGRpZmZlcmVudCBzaW11 bGNhc3QgdmVyc2lvbnMuICBUaGUNCiAgIG1peGVyIHNlbGVjdHMgdGhlIG1lZGlhIHNvdXJjZSB0 byBiZSBzZW50IGFzIG9uZSBvZiB0aGUgUlRQIHN0cmVhbXMsDQogICBhbmQgdGhlbiBzZWxlY3Rz IGFtb25nIHRoZSBhdmFpbGFibGUgc2ltdWxjYXN0IHN0cmVhbXMgZm9yIHRoZSBtb3N0DQogICBh cHByb3ByaWF0ZSBvbmUuICBUaGUgc2VsZWN0aW9uIGNyaXRlcmlhIGluY2x1ZGUgYXZhaWxhYmxl IGJhbmR3aWR0aA0KICAgb24gdGhlIG1peGVyIHRvIHJlY2VpdmVyIHBhdGggYW5kIHJlc3RyaWN0 aW9ucyBiYXNlZCBvbiB0aGUNCiAgIGZ1bmN0aW9uYWwgdXNhZ2Ugb2YgdGhlIFJUUCBzdHJlYW0g ZGVsaXZlcmVkIHRvIHRoZSByZWNlaXZlci4gIEFuDQogICBleGFtcGxlIG9mIHRoZSBsYXR0ZXIs IGlzIHRoYXQgaXQgaXMgdW5uZWNlc3NhcnkgdG8gZm9yd2FyZCBhIGZ1bGwgSEQNCiAgIHZpZGVv IHRvIGEgcmVjZWl2ZXIgaWYgdGhlIGRpc3BsYXkgYXJlYSBpcyBqdXN0IGEgdGh1bWJuYWlsLiAg VGh1cywNCiAgIHJlc3RyaWN0aW9ucyBtYXkgZXhpc3QgdG8gbm90IGFsbG93IHNvbWUgc2ltdWxj YXN0IHN0cmVhbXMgdG8gYmUNCiAgIGZvcndhcmRlZCBmb3Igc29tZSBvZiB0aGUgbWl4ZXIncyBt ZWRpYSBzb3VyY2VzLg0KDQpJbiBvdXIgY2FzZSB0byBwcm92aWRlIHRoaXMgZmVhdHVyZSwgY3Vy cmVudGx5IHdlIGhhdmUgdG8gZGVwYXkgdGhlIFJUUCBwYWNrZXRzLCBhbmQgYXBwbHkgZGlmZmVy ZW50IHR5cGVzIG9mIHBhcnNlcyAoZGVwZW5kaW5nIG9uIHRoZSBjb2RlYykgdG8gcmVhZCB0aGUg ZnJhbWUgc2l6ZSwgd2hpY2ggcmVkdWNlcyB0aGUgc2NhbGFiaWxpdHkgb2YgdGhlIHN5c3RlbSBh bmQgaGluZGVyIHRoZSBpbXBsZW1lbnRhdGlvbiBhIGxvdC4NCkJlY2F1c2Ugb2YgdGhhdCwgSSB0 aGluayB0aGF0IGhhdmluZyBmcmFtZSBzaXplICh3aWR0aCBhbmQgaGVpZ2h0KSBpbmZvIGluIHRo ZSBGcmFtZSBNYXJraW5nIFJUUCBoZWFkZXIgZXh0ZW5zaW9uIGlzIHF1aXRlIGludGVyZXN0aW5n IHRvIGltcGxlbWVudCB0aGlzIGtpbmQgb2YgdXNlIGNhc2VzIGluIGEgZWFzeSBhbmQgZWZmaWNp ZW50IHdheSAodGhlIHNhbWUgdGhhdCBhbiBhdWRpby1sZXZlbCBleHRlbnNpb24gaGVhZGVyIGlz IHByb3ZpZGVkIHRvIGF2b2lkIGFuYWx5c2luZyBpdCBpbiB0aGUgbWlkZGxlYm94IHNpZGUpLg0K DQpJIGFtIGFkZGluZyBNTVVTSUMgZ3JvdXAgaW4gdGhlIHRocmVhZCwgYmVjYXVzZSBJIHRoaW5r IHRoYXQgdGhpcyBhbHNvIHNob3VsZCBiZSBkaXNjdXNzZWQgaW4gdGhlIGNvbnRleHQgb2YgdGhl IHNpbXVsY2FzdCBjYXNlLg0KDQpCZXN0ISENCg0KUmVmcw0KWzFdIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0LTA2I3NlY3Rpb24tNy4y DQpbMl0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLXNkcC1z aW11bGNhc3QtMDYjc2VjdGlvbi03LjIuMQ0KDQoNCjIwMTYtMDgtMzAgMTI6MzcgR01UKzAyOjAw IE1pZ3VlbCBQYXLDrXMgRMOtYXogPG1wYXJpc2RpYXpAZ21haWwuY29tPG1haWx0bzptcGFyaXNk aWF6QGdtYWlsLmNvbT4+Og0KSSBhc3N1bWUgdGhhdCB0aGUgbWVkaWEgZGlzdHJpYnV0b3IgaGFz IHRoZSBpbmZvcm1hdGlvbiBmcm9tIHRoZSBTRFAgKGl0IHBlcmZvcm1zIHRoZSBTRFAgbmVnb3Rp YXRpb24gd2hpY2ggZWFjaCAiY2xpZW50IiksIGJ1dCB0aGUgcG9pbnQgaXMgdGhhdCBlbmNvZGVy cyBtYXkgY2hhbmdlIHRoZSB2aWRlbyBzaXplIGRlcGVuZGluZyBvbiB0aGUgYXZhaWxhYmxlIGJh bmR3aWR0aCwgdGhlIGNvbXBsZXhpdml0eSBvZiB0aGUgdmlkZW8gc291cmNlLCBldGMuLCB1bmxl c3MgdGhlIHNlbmRlciBmb3JjZXMgdGhlIGVuY29kZXJzJyBjb25maWd1cmF0aW9uIHdpdGggYSBm aXggZnJhbWUgc2l6ZS4uLg0KDQoNCjIwMTYtMDgtMjYgMTk6MDcgR01UKzAyOjAwIEpvbmF0aGFu IExlbm5veCA8am9uYXRoYW5AdmlkeW8uY29tPG1haWx0bzpqb25hdGhhbkB2aWR5by5jb20+PjoN CihBcyBhbiBpbmRpdmlkdWFsLikNCg0KSW4gdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHNpbXVsY2Fz dCB0aGUgbWVkaWEgZGlzdHJpYnV0b3Igd291bGQgbmVlZCB0aGUgUklEIHZhbHVlcywgbm90IHRo ZSBQVCB2YWx1ZXMsIGJ1dCB0aGUgaWRlYSBpcyB0aGUgc2FtZSDigJQgaXQgbmVlZHMgdGhlIFNE UC4NCg0KTm90ZSB0aGF0IGlmIHRoZSBtZWRpYSBkaXN0cmlidXRvciBkb2VzbuKAmXQgaGF2ZSBp bmZvcm1hdGlvbiBmcm9tIHRoZSBTRFAgaXQgY2Fu4oCZdCByZWxpYWJseSBpZGVudGlmeSB0aGUg ZnJhbWUgbWFya2luZyBoZWFkZXIgZXh0ZW5zaW9uIGF0IGFsbCwgc2luY2UgaGVhZGVyIGV4dGVu c2lvbiBJRHMgYXJlIG5lZ290aWF0ZWQuIFNvIEnigJltIG5vdCBzdXJlIGhvdyBtdWNoIGJlbmVm aXQgdGhlcmUgaXMgdG8gcHV0dGluZyB0aGUgc2l6ZSBpbiB0aGUgaGVhZGVyIGV4dGVuc2lvbi4N Cg0KVGhhdCBzYWlkLCBpZiB3ZSBlbnZpc2lvbiBhIHNjZW5hcmlvIHdoZXJlIGVuY29kZXJzIG1p Z2h0IGJlIGZyZXF1ZW50bHkgY2hhbmdpbmcgdGhlaXIgdmlkZW8gc2l6ZSAoaW4gcmVzcG9uc2Ug dG8gYXZhaWxhYmxlIG5ldHdvcmsgYmFuZHdpZHRoLCBvciB0aGUgbGlrZSksIGl0IG1pZ2h0IGJl IHVzZWZ1bCBmb3IgZW5jb2RlcnMgdG8gYmUgYWJsZSB0byBpbmRpY2F0ZSB0aGUgY3VycmVudCBz aXplIHRoZXnigJlyZSBlbmNvZGluZyB3aXRob3V0IG5lZWRpbmcgdG8gc2VuZCB1cGRhdGVkIFNE UCBhbGwgdGhlIHRpbWUuDQoNCk9uIEF1ZyAyNiwgMjAxNiwgYXQgMTI6NTIgUE0sIFBhdWwgRS4g Sm9uZXMgPHBhdWxlakBwYWNrZXRpemVyLmNvbTxtYWlsdG86cGF1bGVqQHBhY2tldGl6ZXIuY29t Pj4gd3JvdGU6DQoNCk1pZ3VlbCwNCg0KWW91IG1ha2UgdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUg bWVkaWEgZGlzdHJpYnV0b3Igd2lsbCBub3Qgc2VlIHRoZSBTRFAsIEkgc3VwcG9zZS4gIFdoaWxl IGNlcnRhaW5seSBhIHZhbGlkIG1vZGVsLCBJJ2xsIGFkbWl0IHRoYXQgSSBoYWQgcGVyc29uYWxs eSBhc3N1bWVkIGFueSBtZWRpYSBmb3J3YXJkaW5nIGZ1bmN0aW9uIHdvdWxkIHNlZSB0aGUgU0RQ IChvciBhdCBsZWFzdCBiZSB0b2xkIHRoZSBQVCB2YWx1ZXMgYW5kIGFueSByZWxldmFudCBmbG93 IGluZm9ybWF0aW9uIHNpbWlsYXIgdG8gd2hhdCBSRkMgNjIzNiBwcm92aWRlcykgYW5kIHdvdWxk IHRodXMga25vdyB3aGljaCBQVCB2YWx1ZXMgY29ycmVzcG9uZCB0byB3aGF0IHZpZGVvIHJlc29s dXRpb25zIGlmIHNpbXVsY2FzdCBpcyBlbXBsb3llZC4NCg0KUGF1bA0KDQotLS0tLS0gT3JpZ2lu YWwgTWVzc2FnZSAtLS0tLS0NCkZyb206ICJNaWd1ZWwgUGFyw61zIETDrWF6IiA8bXBhcmlzZGlh ekBnbWFpbC5jb208bWFpbHRvOm1wYXJpc2RpYXpAZ21haWwuY29tPj4NClRvOiBhdnRleHRAaWV0 Zi5vcmc8bWFpbHRvOmF2dGV4dEBpZXRmLm9yZz4NClNlbnQ6IDgvMjUvMjAxNiAxMDoxMjo0OCBB TQ0KU3ViamVjdDogW2F2dGV4dF0gZnJhbWVtYXJraW5nOiBhZGQgZnJhbWUgc2l6ZSBpbmZvDQoN CkhlbGxvLA0KaXQgd291bGQgYmUgZ3JlYXQgaGF2aW5nIGZyYW1lIHNpemUgKHdpZHRoIGFuZCBo ZWlnaHQpIGluZm8gaW4gdGhlIEZyYW1lIE1hcmtpbmcgUlRQIGhlYWRlciBleHRlbnNpb24gWzFd Lg0KDQpXaHk/DQpGb3IgZXhhbXBsZSwgaW4gdGhlIGNhc2Ugb2YgdXNpbmcgc2ltdWxjYXN0IGlu IGFuIFNGVSwgc2VsZWN0aW5nIHRoZSBzdHJlYW0gYnkgdGhlIHNpemUgd291bGQgZWFzZSB0aGUg YXBwbGljYXRpb24gZGV2ZWxvcG1lbnQgYW5kIGltcHJvdmUgdGhlIGV4cGVyaWVuY2Ugb2YgdGhl IHVzZXJzLg0KQXBwbGljYXRpb24gZGV2ZWxvcGVycyBkb24ndCB1c3VhbGx5IGhhdmUgZGVlcCBr bm93bGVkZ2UgYWJvdXQgbWVkaWEgbGlrZSBiaXRyYXRlLCBldGMuLCBidXQgdGhleSBrbm93IHdo aWNoIHZpZGVvIHNpemUgaGFzIHRvIGJlIHJlbmRlcmVkIGluIHRoZSBHVUksIHdoaWNoIG1heSBk ZXBlbmQgb24gdGhlIGNsaWVudCB3aGVyZSB0aGUgYXBwIGlzIHJ1bm5pbmc6IGEgbW9iaWxlLCBh IFBDIHdpdGggYSAxMyLCtyBzY3JlZW4sIGEgUEMgd2l0aCAyNyIgc2NyZWVuLCBldGMuDQoNCklu IHRoaXMgd2F5IGFuZCB0YWtpbmcgYSB2aWRlb2NvbmZlcmVuY2UgYXBwIGFzIGV4YW1wbGUsIGlm IGEgcGFydGljaXBhbnQgc2VsZWN0IGFub3RoZXIgcGFydGljaXBhbnQgdG8gYmUgcmVuZGVyZWQg YXMgbWFpbiB2aWRlbywgdGhlIGFwcCBjb3VsZCBhc2sgdGhlIFNGVSB0byBzZWxlY3QgdGhlIHZp ZGVvIHF1YWxpdHkgdGhhdCBiZXR0ZXIgbWF0Y2hlcyB0byA4MDB4NjAwIHNpemUuDQoNCldoYXQg ZG8geW91IHRoaW5rIGFib3V0IHRoaXMgaWRlYT8NCg0KVGhhbmtzIGFuZCBiZXN0IHJlZ2FyZHMh IQ0KDQpSZWZzDQpbMV0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXZ0 ZXh0LWZyYW1lbWFya2luZy0wMg0KDQotLQ0KTWlndWVsIFBhcsOtcyBEw61heg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpDb21wdXRlci9Tb2Z0d2FyZSBlbmdpbmVlci4NClJlc2VhcmNoZXIgYW5kIGFyY2hp dGVjdCBpbiBodHRwOi8vd3d3Lmt1cmVudG8ub3JnPGh0dHA6Ly93d3cua3VyZW50by5vcmcvPg0K aHR0cDovL3R3aXR0ZXIuY29tL21wYXJpc2RpYXoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmF2dGV4dCBtYWlsaW5nIGxp c3QNCmF2dGV4dEBpZXRmLm9yZzxtYWlsdG86YXZ0ZXh0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnRleHQNCg0KDQoNCg0KLS0NCk1pZ3VlbCBQYXLD rXMgRMOtYXoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ29tcHV0ZXIvU29mdHdhcmUgZW5naW5lZXIuDQpS ZXNlYXJjaGVyIGFuZCBhcmNoaXRlY3QgaW4gaHR0cDovL3d3dy5rdXJlbnRvLm9yZw0KaHR0cDov L3R3aXR0ZXIuY29tL21wYXJpc2RpYXoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KLS0NCk1pZ3Vl bCBQYXLDrXMgRMOtYXoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ29tcHV0ZXIvU29mdHdhcmUgZW5naW5l ZXIuDQpSZXNlYXJjaGVyIGFuZCBhcmNoaXRlY3QgaW4gaHR0cDovL3d3dy5rdXJlbnRvLm9yZw0K aHR0cDovL3R3aXR0ZXIuY29tL21wYXJpc2RpYXoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCg0KLS0N Ck1pZ3VlbCBQYXLDrXMgRMOtYXoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ29tcHV0ZXIvU29mdHdhcmUg ZW5naW5lZXIuDQpSZXNlYXJjaGVyIGFuZCBhcmNoaXRlY3QgaW4gaHR0cDovL3d3dy5rdXJlbnRv Lm9yZw0KaHR0cDovL3R3aXR0ZXIuY29tL21wYXJpc2RpYXoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K --_000_D4FEA22D6B914mzanatyciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7C7004262ECE84439DB2EF0FD48358D7@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx MnB4OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7Ij4NCjxkaXY+SGkgTWlndWVsLDwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhpcyB3YXMgZGlzY3Vzc2VkIGluIElFVEYg OTcgZHVyaW5nIHRoZSBBVlRFWFQgc2Vzc2lvbiBvbiBGcmFtZSBNYXJraW5nLjwvZGl2Pg0KPGRp dj5TZWUgdGhlIHNsaWRlcyBhbmQgbWludXRlcy48L2Rpdj4NCjxkaXY+PGEgaHJlZj0iaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzk3L3Nlc3Npb24vYXZ0ZXh0Ij5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTcvc2Vzc2lvbi9hdnRleHQ8L2E+PC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgcmVjb21tZW5kZWQgYW5kIGFncmVlZCBzb2x1 dGlvbiB3YXMgdG8gdXNlIFJJRCByYXRoZXIgdGhhbiBhZGQgZnJhbWUgc2l6ZTwvZGl2Pg0KPGRp dj5pbiB0aGUgRnJhbWUgTWFya2luZyBoZWFkZXIgZXh0ZW5zaW9uLjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj5NbzwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04i Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQt YWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JE RVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDog MGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBC T1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+bW11c2ljICZsdDs8YSBocmVmPSJtYWls dG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmciPm1tdXNpYy1ib3VuY2VzQGlldGYub3JnPC9hPiZn dDsgb24gYmVoYWxmIG9mIE1pZ3VlbCBQYXLDrXMgRMOtYXogJmx0OzxhIGhyZWY9Im1haWx0bzpt cGFyaXNkaWF6QGdtYWlsLmNvbSI+bXBhcmlzZGlhekBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+TW9uZGF5LCBNYXJjaCAy NywgMjAxNyBhdCAzOjQzIEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRv OiA8L3NwYW4+Sm9uYXRoYW4gTGVubm94ICZsdDs8YSBocmVmPSJtYWlsdG86am9uYXRoYW5Admlk eW8uY29tIj5qb25hdGhhbkB2aWR5by5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzphdnRleHRAaWV0 Zi5vcmciPmF2dGV4dEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphdnRl eHRAaWV0Zi5vcmciPmF2dGV4dEBpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWls dG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtNTVVTSUNd IFthdnRleHRdIGZyYW1lbWFya2luZzogYWRkIGZyYW1lIHNpemUgaW5mbzxicj4NCjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pg0K PGRpdj5IZWxsbyBhZ2Fpbiw8YnI+DQo8L2Rpdj4NCmlzIHRoZXJlIGFueWJvZHkgY29uc2lkZXJp bmcgdGhpcyBwcm9wb3NhbCwgb3Igbm9ib2R5IHNlZSB0aGUgYmVuZWZpdHM/PGJyPg0KPGJyPg0K PC9kaXY+DQpLaW5kIHJlZ2FyZHMhITxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0 cmEiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4yMDE2LTExLTEwIDE1OjE4IEdNVCYj NDM7MDE6MDAgTWlndWVsIFBhcsOtcyBEw61heiA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJl Zj0ibWFpbHRvOm1wYXJpc2RpYXpAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bXBhcmlzZGlh ekBnbWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj46PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWls X3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29s aWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+PHNwYW4gY2xhc3M9 Im1fLTU4Nzk0OTg5MzcyODg1ODAxNzZnbWFpbC1nSSI+PC9zcGFuPkhlbGxvLDxicj4NCmluIHRo ZSBuZXcgZHJhZnQgb2Ygc2RwLXNpbXVsY2FzdCBhbiAmcXVvdDtSVFAgQXNwZWN0JnF1b3Q7IHNl Y3Rpb24gWzFdIGhhcyBiZWVuIGFkZGVkLCB3aGljaCBleHBsYWlucyBob3cgdGhlIG1lZGlhIGlz IGhhbmRsZWQgb24gUlRQIGxldmVsLjxicj4NCjxicj4NCjwvZGl2Pg0KU3BlY2lmaWNhbGx5LCBJ biB0aGUgTWVkaWEtU3dpdGNoaW5nIE1peGVyIHNlY3Rpb24gWzJdIHRoZSBzYW1lIHRob3VnaHRz IEkgZXhwb3NlZCBhcmUgc2FpZDo8YnI+DQo8cHJlIGNsYXNzPSJtXy01ODc5NDk4OTM3Mjg4NTgw MTc2Z21haWwtbmV3cGFnZSI+ICAgVGhpcyBzZWN0aW9uIGRpc2N1c3NlcyB0aGUgYmVoYXZpb3Ig aW4gY2FzZXMgd2hlcmUgdGhlIFJUUCBtaWRkbGVib3gNCiAgIGJlaGF2ZXMgbGlrZSB0aGUgTWVk aWEtU3dpdGNoaW5nIE1peGVyICg8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1tbXVzaWMtc2RwLXNpbXVsY2FzdC0wNiNzZWN0aW9uLTMuNi4yIiB0YXJnZXQ9 Il9ibGFuayI+U2VjdGlvbiAzLjYuMjwvYT4pIGluIFJUUA0KICAgVG9wb2xvZ2llcyBbPGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc2NjciIHRpdGxlPSImcXVvdDtSVFAg VG9wb2xvZ2llcyZxdW90OyIgdGFyZ2V0PSJfYmxhbmsiPlJGQzc2Njc8L2E+XS4gIFRoZSBmdW5k YW1lbnRhbCBhc3BlY3QgaGVyZSBpcyB0aGF0IHRoZSBtZWRpYQ0KICAgc291cmNlcyBkZWxpdmVy ZWQgZnJvbSB0aGUgbWlkZGxlYm94IHdpbGwgYmUgdGhlIG1peGVyJ3MgY29uY2VwdHVhbA0KICAg b3IgZnVuY3Rpb25hbCBvbmVzLiAgRm9yIGV4YW1wbGUsIG9uZSBtZWRpYSBzb3VyY2UgbWF5IGJl IHRoZSBtYWluDQogICBzcGVha2VyIGluIGhpZ2ggcmVzb2x1dGlvbiB2aWRlbywgd2hpbGUgYSBu dW1iZXIgb2Ygb3RoZXIgbWVkaWENCiAgIHNvdXJjZXMgYXJlIHRodW1ibmFpbHMgb2YgZWFjaCBw YXJ0aWNpcGFudC4NCg0KICAgVGhlIGFib3ZlIHJlc3VsdHMgaW4gdGhhdCB0aGUgUlRQIHN0cmVh bSBwcm9kdWNlZCBieSB0aGUgbWl4ZXIgaXMgb25lDQogICB0aGF0IHN3aXRjaGVzIGJldHdlZW4g YSBudW1iZXIgb2YgcmVjZWl2ZWQgaW5jb21pbmcgUlRQIHN0cmVhbXMgZm9yDQogICBkaWZmZXJl bnQgbWVkaWEgc291cmNlcyBhbmQgaW4gZGlmZmVyZW50IHNpbXVsY2FzdCB2ZXJzaW9ucy4gIFRo ZQ0KICAgbWl4ZXIgc2VsZWN0cyB0aGUgbWVkaWEgc291cmNlIHRvIGJlIHNlbnQgYXMgb25lIG9m IHRoZSBSVFAgc3RyZWFtcywNCiAgIGFuZCB0aGVuIHNlbGVjdHMgYW1vbmcgdGhlIGF2YWlsYWJs ZSBzaW11bGNhc3Qgc3RyZWFtcyBmb3IgdGhlIG1vc3QNCiAgIGFwcHJvcHJpYXRlIG9uZS4gIFRo ZSBzZWxlY3Rpb24gY3JpdGVyaWEgaW5jbHVkZSBhdmFpbGFibGUgYmFuZHdpZHRoDQogICBvbiB0 aGUgbWl4ZXIgdG8gcmVjZWl2ZXIgcGF0aCBhbmQgcmVzdHJpY3Rpb25zIGJhc2VkIG9uIHRoZQ0K ICAgZnVuY3Rpb25hbCB1c2FnZSBvZiB0aGUgUlRQIHN0cmVhbSBkZWxpdmVyZWQgdG8gdGhlIHJl Y2VpdmVyLiAgQW4NCiAgIGV4YW1wbGUgb2YgdGhlIGxhdHRlciwgaXMgdGhhdCBpdCBpcyB1bm5l Y2Vzc2FyeSB0byBmb3J3YXJkIGEgZnVsbCBIRA0KICAgdmlkZW8gdG8gYSByZWNlaXZlciBpZiB0 aGUgZGlzcGxheSBhcmVhIGlzIGp1c3QgYSB0aHVtYm5haWwuICBUaHVzLA0KICAgcmVzdHJpY3Rp b25zIG1heSBleGlzdCB0byBub3QgYWxsb3cgc29tZSBzaW11bGNhc3Qgc3RyZWFtcyB0byBiZQ0K ICAgZm9yd2FyZGVkIGZvciBzb21lIG9mIHRoZSBtaXhlcidzIG1lZGlhIHNvdXJjZXMuPGJyPjwv cHJlPg0KPGRpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkluIG91ciBjYXNlIHRvIHByb3Zp ZGUgdGhpcyBmZWF0dXJlLCBjdXJyZW50bHkgd2UgaGF2ZSB0byBkZXBheSB0aGUgUlRQIHBhY2tl dHMsIGFuZCBhcHBseSBkaWZmZXJlbnQgdHlwZXMgb2YgcGFyc2VzIChkZXBlbmRpbmcgb24gdGhl IGNvZGVjKSB0byByZWFkIHRoZSBmcmFtZSBzaXplLCB3aGljaCByZWR1Y2VzIHRoZSBzY2FsYWJp bGl0eSBvZiB0aGUgc3lzdGVtIGFuZCBoaW5kZXIgdGhlIGltcGxlbWVudGF0aW9uIGEgbG90Ljxi cj4NCjwvZGl2Pg0KPGRpdj5CZWNhdXNlIG9mIHRoYXQsIEkgdGhpbmsgdGhhdCBoYXZpbmcgZnJh bWUgc2l6ZSAod2lkdGggYW5kIGhlaWdodCkgaW5mbyBpbiB0aGUgRnJhbWUgTWFya2luZyBSVFAg aGVhZGVyIGV4dGVuc2lvbiBpcyBxdWl0ZSBpbnRlcmVzdGluZyB0byBpbXBsZW1lbnQgdGhpcyBr aW5kIG9mIHVzZSBjYXNlcyBpbiBhIGVhc3kgYW5kIGVmZmljaWVudCB3YXkgKHRoZSBzYW1lIHRo YXQgYW4gYXVkaW8tbGV2ZWwgZXh0ZW5zaW9uIGhlYWRlciBpcyBwcm92aWRlZA0KIHRvIGF2b2lk IGFuYWx5c2luZyBpdCBpbiB0aGUgbWlkZGxlYm94IHNpZGUpLjxicj4NCjwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+SSBhbSBhZGRpbmcgTU1VU0lDIGdyb3VwIGluIHRoZSB0aHJlYWQs IGJlY2F1c2UgSSB0aGluayB0aGF0IHRoaXMgYWxzbyBzaG91bGQgYmUgZGlzY3Vzc2VkIGluIHRo ZSBjb250ZXh0IG9mIHRoZSBzaW11bGNhc3QgY2FzZS48YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXY+ QmVzdCEhPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWZzPGJyPg0KWzFd IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1z ZHAtc2ltdWxjYXN0LTA2I3NlY3Rpb24tNy4yIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvPHdicj5kcmFmdC1pZXRmLW1tdXNpYy1zZHAtPHdicj5zaW11bGNh c3QtMDYjc2VjdGlvbi03LjI8L2E+PGJyPg0KWzJdIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1zZHAtc2ltdWxjYXN0LTA2I3NlY3Rpb24tNy4y LjEiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC88d2JyPmRy YWZ0LWlldGYtbW11c2ljLXNkcC08d2JyPnNpbXVsY2FzdC0wNiNzZWN0aW9uLTcuMi4xPC9hPjxi cj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IkhPRW5aYiI+DQo8 ZGl2IGNsYXNzPSJoNSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFz cz0iZ21haWxfcXVvdGUiPjIwMTYtMDgtMzAgMTI6MzcgR01UJiM0MzswMjowMCBNaWd1ZWwgUGFy w61zIETDrWF6IDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBocmVmPSJtYWlsdG86bXBhcmlzZGlh ekBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tcGFyaXNkaWF6QGdtYWlsLmNvbTwvYT4mZ3Q7 PC9zcGFuPjo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4 Ij4NCjxkaXYgZGlyPSJsdHIiPkkgYXNzdW1lIHRoYXQgdGhlIG1lZGlhIGRpc3RyaWJ1dG9yIGhh cyB0aGUgaW5mb3JtYXRpb24gZnJvbSB0aGUgU0RQIChpdCBwZXJmb3JtcyB0aGUgU0RQIG5lZ290 aWF0aW9uIHdoaWNoIGVhY2ggJnF1b3Q7Y2xpZW50JnF1b3Q7KSwgYnV0IHRoZSBwb2ludCBpcyB0 aGF0IGVuY29kZXJzIG1heSBjaGFuZ2UgdGhlIHZpZGVvIHNpemUgZGVwZW5kaW5nIG9uIHRoZSBh dmFpbGFibGUgYmFuZHdpZHRoLCB0aGUgY29tcGxleGl2aXR5IG9mIHRoZQ0KIHZpZGVvIHNvdXJj ZSwgZXRjLiwgdW5sZXNzIHRoZSBzZW5kZXIgZm9yY2VzIHRoZSBlbmNvZGVycycgY29uZmlndXJh dGlvbiB3aXRoIGEgZml4IGZyYW1lIHNpemUuLi48YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9Im1fLTU4Nzk0OTg5MzcyODg1ODAxNzZIT0VuWmIiPg0KPGRpdiBjbGFzcz0ibV8tNTg3OTQ5 ODkzNzI4ODU4MDE3Nmg1Ij4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+DQo8ZGl2IGNs YXNzPSJnbWFpbF9xdW90ZSI+MjAxNi0wOC0yNiAxOTowNyBHTVQmIzQzOzAyOjAwIEpvbmF0aGFu IExlbm5veCA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmpvbmF0aGFuQHZp ZHlvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpvbmF0aGFuQHZpZHlvLmNvbTwvYT4mZ3Q7PC9zcGFu Pjo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAw IDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxk aXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXY+KEFzIGFuIGluZGl2aWR1YWwu KTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SW4gdGhlIGxhdGVzdCB2ZXJzaW9uIG9m IHNpbXVsY2FzdCB0aGUgbWVkaWEgZGlzdHJpYnV0b3Igd291bGQgbmVlZCB0aGUgUklEIHZhbHVl cywgbm90IHRoZSBQVCB2YWx1ZXMsIGJ1dCB0aGUgaWRlYSBpcyB0aGUgc2FtZSDigJQgaXQgbmVl ZHMgdGhlIFNEUC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk5vdGUgdGhhdCBpZiB0 aGUgbWVkaWEgZGlzdHJpYnV0b3IgZG9lc27igJl0IGhhdmUgaW5mb3JtYXRpb24gZnJvbSB0aGUg U0RQIGl0IGNhbuKAmXQgcmVsaWFibHkgaWRlbnRpZnkgdGhlIGZyYW1lIG1hcmtpbmcgaGVhZGVy IGV4dGVuc2lvbiBhdCBhbGwsIHNpbmNlIGhlYWRlciBleHRlbnNpb24gSURzIGFyZSBuZWdvdGlh dGVkLiBTbyBJ4oCZbSBub3Qgc3VyZSBob3cgbXVjaCBiZW5lZml0IHRoZXJlIGlzIHRvIHB1dHRp bmcgdGhlIHNpemUgaW4gdGhlDQogaGVhZGVyIGV4dGVuc2lvbi48L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PlRoYXQgc2FpZCwgaWYgd2UgZW52aXNpb24gYSBzY2VuYXJpbyB3aGVyZSBl bmNvZGVycyBtaWdodCBiZSBmcmVxdWVudGx5IGNoYW5naW5nIHRoZWlyIHZpZGVvIHNpemUgKGlu IHJlc3BvbnNlIHRvIGF2YWlsYWJsZSBuZXR3b3JrIGJhbmR3aWR0aCwgb3IgdGhlIGxpa2UpLCBp dCBtaWdodCBiZSB1c2VmdWwgZm9yIGVuY29kZXJzIHRvIGJlIGFibGUgdG8gaW5kaWNhdGUgdGhl IGN1cnJlbnQgc2l6ZSB0aGV54oCZcmUgZW5jb2Rpbmcgd2l0aG91dA0KIG5lZWRpbmcgdG8gc2Vu ZCB1cGRhdGVkIFNEUCBhbGwgdGhlIHRpbWUuPC9kaXY+DQo8YnI+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0ibV8tNTg3OTQ5ODkzNzI4ODU4MDE3 Nm1fLTcwODU5MTQ5OTMzMjY5NzEzNjhoNSI+DQo8ZGl2Pk9uIEF1ZyAyNiwgMjAxNiwgYXQgMTI6 NTIgUE0sIFBhdWwgRS4gSm9uZXMgJmx0OzxhIGhyZWY9Im1haWx0bzpwYXVsZWpAcGFja2V0aXpl ci5jb20iIHRhcmdldD0iX2JsYW5rIj5wYXVsZWpAcGFja2V0aXplci5jb208L2E+Jmd0OyB3cm90 ZTo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9 Im1fLTU4Nzk0OTg5MzcyODg1ODAxNzZtXy03MDg1OTE0OTkzMzI2OTcxMzY4aDUiPg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtmb250LXNpemU6MTVweDtmb250LXN0eWxlOm5vcm1h bDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3Rh cnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFs O3dvcmQtc3BhY2luZzowcHgiPg0KTWlndWVsLDwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6Q2FsaWJyaTtmb250LXNpemU6MTVweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpu b3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6 MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzow cHgiPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2ZvbnQt c2l6ZToxNXB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3Bh Y2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zv cm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweCI+DQpZb3UgbWFrZSB0 aGUgYXNzdW1wdGlvbiB0aGF0IHRoZSBtZWRpYSBkaXN0cmlidXRvciB3aWxsIG5vdCBzZWUgdGhl IFNEUCwgSSBzdXBwb3NlLiZuYnNwOyBXaGlsZSBjZXJ0YWlubHkgYSB2YWxpZCBtb2RlbCwgSSds bCBhZG1pdCB0aGF0IEkgaGFkIHBlcnNvbmFsbHkgYXNzdW1lZCBhbnkgbWVkaWEgZm9yd2FyZGlu ZyBmdW5jdGlvbiB3b3VsZCBzZWUgdGhlIFNEUCAob3IgYXQgbGVhc3QgYmUgdG9sZCB0aGUgUFQg dmFsdWVzIGFuZCBhbnkgcmVsZXZhbnQNCiBmbG93IGluZm9ybWF0aW9uIHNpbWlsYXIgdG8gd2hh dCBSRkMgNjIzNiBwcm92aWRlcykgYW5kIHdvdWxkIHRodXMga25vdyB3aGljaCBQVCB2YWx1ZXMg Y29ycmVzcG9uZCB0byB3aGF0IHZpZGVvIHJlc29sdXRpb25zIGlmIHNpbXVsY2FzdCBpcyBlbXBs b3llZC48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Zm9udC1zaXplOjE1 cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5v cm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25l O3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTtmb250LXNpemU6MTVweDtmb250LXN0eWxlOm5v cm1hbDtmb250LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246 c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9y bWFsO3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4+UGF1bDwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Zm9udC1zaXplOjE1cHg7Zm9udC1zdHlsZTpub3JtYWw7 Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0 O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3 b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 Q2FsaWJyaTtmb250LXNpemU6MTVweDtmb250LXN0eWxlOm5vcm1hbDtmb250LXdlaWdodDpub3Jt YWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4 O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQtc3BhY2luZzowcHgi Pg0KLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250 LWZhbWlseTpDYWxpYnJpO2ZvbnQtc2l6ZToxNXB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2Vp Z2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWlu ZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFj aW5nOjBweCI+DQpGcm9tOiAmcXVvdDtNaWd1ZWwgUGFyw61zIETDrWF6JnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86bXBhcmlzZGlhekBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tcGFyaXNk aWF6QGdtYWlsLmNvbTwvYT4mZ3Q7PC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpO2ZvbnQtc2l6ZToxNXB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDts ZXR0ZXItc3BhY2luZzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4 dC10cmFuc2Zvcm06bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweCI+DQpU bzo8c3Bhbj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmF2dGV4dEBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmF2dGV4dEBpZXRmLm9yZzwvYT48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmk7Zm9udC1zaXplOjE1cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWln aHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5k ZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNp bmc6MHB4Ij4NClNlbnQ6IDgvMjUvMjAxNiAxMDoxMjo0OCBBTTwvZGl2Pg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaTtmb250LXNpemU6MTVweDtmb250LXN0eWxlOm5vcm1hbDtmb250 LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4 dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQt c3BhY2luZzowcHgiPg0KU3ViamVjdDogW2F2dGV4dF0gZnJhbWVtYXJraW5nOiBhZGQgZnJhbWUg c2l6ZSBpbmZvPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2ZvbnQtc2l6 ZToxNXB4O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2lu Zzpub3JtYWw7dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06 bm9uZTt3aGl0ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Zm9udC1zaXplOjE1cHg7Zm9udC1zdHls ZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFs aWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNl Om5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxl PSJtYXJnaW4tbGVmdDo1cHg7bWFyZ2luLXJpZ2h0OjBweDtwYWRkaW5nLWxlZnQ6MTBweDtwYWRk aW5nLXJpZ2h0OjBweDtib3JkZXItbGVmdC13aWR0aDoxcHg7Ym9yZGVyLWxlZnQtc3R5bGU6c29s aWQ7Ym9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTttYXJnaW4tdG9wOjNweDtwYWRk aW5nLXRvcDowcHgiPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pg0KPGRpdj5IZWxsbyw8YnI+DQo8 L2Rpdj4NCjxkaXY+aXQgd291bGQgYmUgZ3JlYXQgaGF2aW5nIGZyYW1lIHNpemUgKHdpZHRoIGFu ZCBoZWlnaHQpIGluZm8gaW4gdGhlIEZyYW1lIE1hcmtpbmcgUlRQIGhlYWRlciBleHRlbnNpb24g WzFdLjxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdj5XaHk/PGJyPg0KPC9kaXY+DQo8ZGl2PkZvciBl eGFtcGxlLCBpbiB0aGUgY2FzZSBvZiB1c2luZyBzaW11bGNhc3QgaW4gYW4gU0ZVLCBzZWxlY3Rp bmcgdGhlIHN0cmVhbSBieSB0aGUgc2l6ZSB3b3VsZCBlYXNlIHRoZSBhcHBsaWNhdGlvbiBkZXZl bG9wbWVudCBhbmQgaW1wcm92ZSB0aGUgZXhwZXJpZW5jZSBvZiB0aGUgdXNlcnMuPGJyPg0KPC9k aXY+DQo8ZGl2PkFwcGxpY2F0aW9uIGRldmVsb3BlcnMgZG9uJ3QgdXN1YWxseSBoYXZlIGRlZXAg a25vd2xlZGdlIGFib3V0IG1lZGlhIGxpa2UgYml0cmF0ZSwgZXRjLiwgYnV0IHRoZXkga25vdyB3 aGljaCB2aWRlbyBzaXplIGhhcyB0byBiZSByZW5kZXJlZCBpbiB0aGUgR1VJLCB3aGljaCBtYXkg ZGVwZW5kIG9uIHRoZSBjbGllbnQgd2hlcmUgdGhlIGFwcCBpcyBydW5uaW5nOiBhIG1vYmlsZSwg YSBQQyB3aXRoIGEgMTMmcXVvdDvCtyBzY3JlZW4sIGEgUEMgd2l0aA0KIDI3JnF1b3Q7IHNjcmVl biwgZXRjLjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SW4gdGhpcyB3YXkg YW5kIHRha2luZyBhIHZpZGVvY29uZmVyZW5jZSBhcHAgYXMgZXhhbXBsZSwgaWYgYSBwYXJ0aWNp cGFudCBzZWxlY3QgYW5vdGhlciBwYXJ0aWNpcGFudCB0byBiZSByZW5kZXJlZCBhcyBtYWluIHZp ZGVvLCB0aGUgYXBwIGNvdWxkIGFzayB0aGUgU0ZVIHRvIHNlbGVjdCB0aGUgdmlkZW8gcXVhbGl0 eSB0aGF0IGJldHRlciBtYXRjaGVzIHRvIDgwMHg2MDAgc2l6ZS48YnI+DQo8L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PldoYXQgZG8geW91IHRoaW5rIGFib3V0IHRoaXMgaWRlYT88YnI+ DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KVGhhbmtzIGFuZCBiZXN0IHJlZ2FyZHMhITxicj4NCjxi cj4NClJlZnM8YnI+DQpbMV08c3Bhbj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXZ0ZXh0LWZyYW1lbWFya2luZy0wMiIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtPHdicj5sL2RyYWZ0LWlldGYtYXZ0 ZXh0LWZyYW1lbWFya2k8d2JyPm5nLTAyPC9hPg0KPGRpdj4NCjxkaXY+PGJyPg0KLS08c3Bhbj4m bmJzcDs8L3NwYW4+PGJyPg0KPGRpdiBkYXRhLXNtYXJ0bWFpbD0iZ21haWxfc2lnbmF0dXJlIj4N CjxkaXYgZGlyPSJsdHIiPk1pZ3VlbCBQYXLDrXMgRMOtYXo8YnI+DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08d2JyPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTx3YnI+LS0t LS0tLS0tLS0tPGJyPg0KQ29tcHV0ZXIvU29mdHdhcmUgZW5naW5lZXIuPGJyPg0KUmVzZWFyY2hl ciBhbmQgYXJjaGl0ZWN0IGluPHNwYW4+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cu a3VyZW50by5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5rdXJlbnRvLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwOi8vdHdpdHRlci5jb20vbXBhcmlzZGlheiIgdGFyZ2V0PSJfYmxh bmsiPmh0dHA6Ly90d2l0dGVyLmNvbS9tcGFyaXNkaWF6PC9hPjxicj4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTx3YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPHdicj4t LS0tLS0tLS0tLS08YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkNhbGlicmk7Zm9udC1zaXplOjE1cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWln aHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5k ZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNp bmc6MHB4O2Zsb2F0Om5vbmU7ZGlzcGxheTppbmxpbmUhaW1wb3J0YW50Ij5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188d2JyPl9fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaTtmb250LXNpemU6MTVweDtmb250LXN0eWxlOm5vcm1hbDtmb250 LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4 dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQt c3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Zm9udC1zaXpl OjE1cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5n Om5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpu b25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4O2Zsb2F0Om5vbmU7ZGlzcGxh eTppbmxpbmUhaW1wb3J0YW50Ij5hdnRleHQgbWFpbGluZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaTtmb250LXNpemU6MTVweDtmb250LXN0eWxlOm5vcm1hbDtmb250 LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4 dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQt c3BhY2luZzowcHgiPg0KPGEgaHJlZj0ibWFpbHRvOmF2dGV4dEBpZXRmLm9yZyIgc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmk7Zm9udC1zaXplOjE1cHg7Zm9udC1zdHlsZTpub3JtYWw7Zm9udC13 ZWlnaHQ6bm9ybWFsO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3RleHQt aW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRlLXNwYWNlOm5vcm1hbDt3b3JkLXNw YWNpbmc6MHB4IiB0YXJnZXQ9Il9ibGFuayI+YXZ0ZXh0QGlldGYub3JnPC9hPjxiciBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaTtmb250LXNpemU6MTVweDtmb250LXN0eWxlOm5vcm1hbDtmb250 LXdlaWdodDpub3JtYWw7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7dGV4 dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6bm9ybWFsO3dvcmQt c3BhY2luZzowcHgiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hdnRleHQiIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2ZvbnQtc2l6ZToxNXB4O2Zv bnQtc3R5bGU6bm9ybWFsO2ZvbnQtd2VpZ2h0Om5vcm1hbDtsZXR0ZXItc3BhY2luZzpub3JtYWw7 dGV4dC1hbGlnbjpzdGFydDt0ZXh0LWluZGVudDowcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aGl0 ZS1zcGFjZTpub3JtYWw7d29yZC1zcGFjaW5nOjBweCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbDx3YnI+aXN0aW5mby9hdnRleHQ8L2E+PC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8YnI+DQotLSA8YnI+DQo8ZGl2IGNsYXNzPSJtXy01ODc5 NDk4OTM3Mjg4NTgwMTc2bV8tNzA4NTkxNDk5MzMyNjk3MTM2OGdtYWlsX3NpZ25hdHVyZSIgZGF0 YS1zbWFydG1haWw9ImdtYWlsX3NpZ25hdHVyZSI+DQo8ZGl2IGRpcj0ibHRyIj5NaWd1ZWwgUGFy w61zIETDrWF6PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPHdicj4tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08d2JyPi0tLS0tLS0tLS0tLTxicj4NCkNvbXB1dGVyL1Nv ZnR3YXJlIGVuZ2luZWVyLjxicj4NClJlc2VhcmNoZXIgYW5kIGFyY2hpdGVjdCBpbiA8YSBocmVm PSJodHRwOi8vd3d3Lmt1cmVudG8ub3JnIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5rdXJl bnRvLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwOi8vdHdpdHRlci5jb20vbXBhcmlzZGlheiIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90d2l0dGVyLmNvbS9tcGFyaXNkaWF6PC9hPjxicj4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTx3YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPHdicj4tLS0tLS0tLS0tLS08YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8YnIgY2xlYXI9ImFsbCI+ DQo8YnI+DQotLSA8YnI+DQo8ZGl2IGNsYXNzPSJtXy01ODc5NDk4OTM3Mjg4NTgwMTc2Z21haWxf c2lnbmF0dXJlIiBkYXRhLXNtYXJ0bWFpbD0iZ21haWxfc2lnbmF0dXJlIj4NCjxkaXYgZGlyPSJs dHIiPk1pZ3VlbCBQYXLDrXMgRMOtYXo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08d2JyPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTx3YnI+LS0tLS0tLS0tLS0tPGJy Pg0KQ29tcHV0ZXIvU29mdHdhcmUgZW5naW5lZXIuPGJyPg0KUmVzZWFyY2hlciBhbmQgYXJjaGl0 ZWN0IGluIDxhIGhyZWY9Imh0dHA6Ly93d3cua3VyZW50by5vcmciIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vd3d3Lmt1cmVudG8ub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHA6Ly90d2l0dGVyLmNv bS9tcGFyaXNkaWF6IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3R3aXR0ZXIuY29tL21wYXJpc2Rp YXo8L2E+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPHdicj4tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08d2JyPi0tLS0tLS0tLS0tLTxicj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjxi ciBjbGVhcj0iYWxsIj4NCjxicj4NCi0tIDxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3NpZ25hdHVy ZSIgZGF0YS1zbWFydG1haWw9ImdtYWlsX3NpZ25hdHVyZSI+DQo8ZGl2IGRpcj0ibHRyIj5NaWd1 ZWwgUGFyw61zIETDrWF6PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KQ29tcHV0ZXIvU29mdHdh cmUgZW5naW5lZXIuPGJyPg0KUmVzZWFyY2hlciBhbmQgYXJjaGl0ZWN0IGluIDxhIGhyZWY9Imh0 dHA6Ly93d3cua3VyZW50by5vcmciIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3Lmt1cmVudG8u b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHA6Ly90d2l0dGVyLmNvbS9tcGFyaXNkaWF6IiB0YXJn ZXQ9Il9ibGFuayI+aHR0cDovL3R3aXR0ZXIuY29tL21wYXJpc2RpYXo8L2E+PGJyPg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv c3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D4FEA22D6B914mzanatyciscocom_-- From nobody Tue Mar 28 06:54: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 A00CB128DF3 for ; Tue, 28 Mar 2017 06:54:31 -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 iaja97g_EWNe for ; Tue, 28 Mar 2017 06:54:28 -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 47A4F128ACA for ; Tue, 28 Mar 2017 06:54:27 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id u1so106584765wra.2 for ; Tue, 28 Mar 2017 06:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=Xm/zh9cscRkGpY66g6ROKM+RbJe2tIPeRu6s+kP6DZo=; b=MSQrc73VUIE7NbLSW6nwbM49YZx4caqJ53eSRQtimHB8WOd6Lie3scz6/Uy+8OXHYM 1rDyqN25dGGRhdhuczcZ/v9L1Ru/Gp4ON8RSthDV48IbPmoSyeikd/FY5aEFMCn74NGG bp3dde2NJJ0br6oULn2W4oQU3ptzXHTBGImh5IwGOiWeRmZp9nNenkzYc23tOoKpAGik pPdNRosrUFEPs4zsKWgmCuLzl3i5JWZ0lAJSlfGYSJ944TE/jGQWORSAc8FprzBT3jsI ova6bANOB1VYYUkujMysBnhNnplDpRReukRn1LLONrZZZCjsFp4RpEdwJS4VQ/YKTeWS c83Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=Xm/zh9cscRkGpY66g6ROKM+RbJe2tIPeRu6s+kP6DZo=; b=Lj7aRry+JbsTiSGcrmaqFp8oLEZ2vtfvLaCPXLi8OYIbpeOJcyy6KUTEYWUZAdssIB gWuq9kwnBW2qcVvkeMvw4piizg100AAcAJDIes5SA5kfFGrcPu2DT8gvaE7WVJ2KZ9xo 1E3BitTQEW2MYf0LtcehDZfw4OHC/d79pRUyl0PtQSRVaDPM2tNzZrKWs4e/0+VSWDcs GYedYzb/WO9a5u9vVtRWXrIYlMsjN3kMgD7sTOA5mtLC+RD2WPu7Qcs2Ed+Uc74SSKft 50+I+X4tcHbikFwkI2FNWr2tSFvT94eTG+f8EEo2FkoQ4No75zioYUw0MSosRlS9GcXw xoyw== X-Gm-Message-State: AFeK/H3NwgAo+I45fE3YT4Z9V3WKreU+LDjNZdyNw8+dENGcSzEcImImYiLYl4VMO6fppw== X-Received: by 10.28.63.71 with SMTP id m68mr4206104wma.46.1490709265479; Tue, 28 Mar 2017 06:54:25 -0700 (PDT) Received: from [192.168.1.37] (148.red-79-153-126.dynamicip.rima-tde.net. [79.153.126.148]) by smtp.googlemail.com with ESMTPSA id g23sm3748735wme.8.2017.03.28.06.54.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 06:54:24 -0700 (PDT) To: avtext@ietf.org From: Sergio Garcia Murillo Message-ID: Date: Tue, 28 Mar 2017 15:54:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------271F95B27B4A1BAFFA14FA03" Archived-At: Subject: [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: Tue, 28 Mar 2017 13:54:32 -0000 This is a multi-part message in MIME format. --------------271F95B27B4A1BAFFA14FA03 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I have been implementing the framemarking for PERC and I have some doubts regarding the VP9 LID mapping. First, is that according to https://tools.ietf.org/html/draft-ietf-payload-vp9-03 there are no quality layers on VP9 SVC they are considered as case of spatial layers: VP9 supports quality layers as spatial layers without any resolution changes; hereinafter, the term "spatial layer" is used to represent both spatial and quality layers. 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. Also, in order to be able to implement VP9 SVC layer selection, the SFU needs the information of the P and U bits of the VP9 header description: 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 (seeSection 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. Without that info, the SFU won't be able to upscale, so it would be required to add that information on the VP9 LID. Including that changes, it would be something like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID=2 | L=2 |S|E|I|D|B| TID |0|0|0|P|U|SID | TL0PICIDX | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Best regards Sergio --------------271F95B27B4A1BAFFA14FA03 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

I have been implementing the framemarking for PERC and I have some doubts regarding the VP9 LID mapping.

First, is that according to https://tools.ietf.org/html/draft-ietf-payload-vp9-03 there are no quality layers on VP9 SVC they are considered as case of spatial layers:

   VP9 supports quality layers as spatial layers without any resolution
   changes; hereinafter, the term "spatial layer" is used to represent
   both spatial and quality layers.

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.

Also, in order to be able to implement VP9 SVC layer selection, the SFU needs the information of the P and U bits of the VP9 header description:

   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.

Without that info, the SFU won't be able to upscale, so it would be required to add that information on the VP9 LID.
Including that changes, it would be something like this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  ID=2 |  L=2  |S|E|I|D|B| TID |0|0|0|P|U| SID |    TL0PICIDX  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Best regards
Sergio
--------------271F95B27B4A1BAFFA14FA03-- From nobody Tue Mar 28 09:53: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 480571294D0 for ; Tue, 28 Mar 2017 09:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 34OSX_QKVZSU for ; Tue, 28 Mar 2017 09:53:41 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C84A129468 for ; Tue, 28 Mar 2017 09:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10908; q=dns/txt; s=iport; t=1490720021; x=1491929621; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=AFWJlGF2PoOVIQFve8S1AK8nR5sJbMiIRt/t+COnSgY=; b=QY/JMtcMWFsOjcSUwywtXcvq8hPgujdJ245Hflgc1AAylLXQj8admteA Wo9pd2xN+aHXL7CikJiWfUj6wZL4J/4SSYa/iDKMQHIP/tABmjNEPLE08 QiMspzTHKsJF8gGuJwgUT3UEntsZDHUFfXXMI27ALNQtfdlhyxpYakRpK 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DtBAARlNpY/5tdJa1TChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJuOythgQsHg1uKD5FRhiSBc4gEhTGCDiyCGwGDWgKDIT8YAQI?= =?us-ascii?q?BAQEBAQEBayiFFQEBAQEDBBwEZQIBCBEDAQIoBAMhCQgUCQgCBAEQAolvAxUOr?= =?us-ascii?q?H8MgiUrhwUNgxEBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZOhG+CUYFbSIJngl4?= =?us-ascii?q?FnCY6AYZ7gyqDcYQ4kTOKb4h6AR84PkZZFYUZHYFjQzIBiESBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,237,1486425600"; d="scan'208,217";a="400349036" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2017 16:53:40 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2SGre8O023882 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Mar 2017 16:53:40 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.1210.3; Tue, 28 Mar 2017 11:53:39 -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.1210.000; Tue, 28 Mar 2017 11:53:39 -0500 From: "Mo Zanaty (mzanaty)" To: Sergio Garcia Murillo , "avtext@ietf.org" Thread-Topic: [avtext] Frame marking & VP9 SVC Thread-Index: AQHSp+PZCuZf8O8boky9hNFKfq9hdg== Date: Tue, 28 Mar 2017 16:53:39 +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.2.170228 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.224.245] Content-Type: multipart/alternative; boundary="_000_D4FFF3296BA66mzanatyciscocom_" MIME-Version: 1.0 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: Tue, 28 Mar 2017 16:53:43 -0000 --_000_D4FFF3296BA66mzanatyciscocom_ Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Hi Sergio, Good catch. The VP9 payload format has changed since the Frame Marking LID = extensions were defined. The VP9 authors expect it may change further. Base= d on discussion during today's AVT session, we will remove VP9 from the Fra= me Marking draft (which will help avoid MIS-REF later), and move that infor= mation to the VP9 payload format so it can evolve without diverging. The discussion on U and P bits was more nuanced. The main point is Frame Ma= rking should help identify when layer refresh has occurred and when layer u= p switching is possible. We will add some text on this for simple, fixed sc= alability structures, and note that complex, non-fixed structures require p= ayload-specific inspection and logic that no extra bits will completely eli= minate. Cheers, Mo From: avtext > on b= ehalf of Sergio Murillo > Date: Tuesday, March 28, 2017 at 9:54 AM To: "avtext@ietf.org" > Subject: [avtext] Frame marking & VP9 SVC Hi, I have been implementing the framemarking for PERC and I have some doubts r= egarding the VP9 LID mapping. First, is that according to https://tools.ietf.org/html/draft-ietf-payload-= vp9-03 there are no quality layers on VP9 SVC they are considered as case o= f spatial layers: VP9 supports quality layers as spatial layers without any resolution changes; hereinafter, the term "spatial layer" is used to represent both spatial and quality layers. 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 d= raft. Also, in order to be able to implement VP9 SVC layer selection, the SFU nee= ds the information of the P and U bits of the VP9 header description: 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. Without that info, the SFU won't be able to upscale, so it would be require= d to add that information on the VP9 LID. Including that changes, it would be something like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID=3D2 | L=3D2 |S|E|I|D|B| TID |0|0|0|P|U| SID | TL0PICIDX | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Best regards Sergio --_000_D4FFF3296BA66mzanatyciscocom_ Content-Type: text/html; charset="windows-1251" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Sergio,

Good catch. The VP9 payload format has changed since the Frame Marking= LID extensions were defined. The VP9 authors expect it may change further.= Based on discussion during today's AVT session, we will remove VP9 from th= e Frame Marking draft (which will help avoid MIS-REF later), and move that information to the VP9 payload fo= rmat so it can evolve without diverging.

The discussion on U and P bits was more nuanced. The main point is Fra= me Marking should help identify when layer refresh has occurred and when la= yer up switching is possible. We will add some text on this for simple, fix= ed scalability structures, and note that complex, non-fixed structures require payload-specific inspection and= logic that no extra bits will completely eliminate.

Cheers,
Mo

From: avtext <avtext-bounces@ietf.org> on behalf of Sergi= o Murillo <sergio.gar= cia.murillo@gmail.com>
Date: Tuesday, March 28, 2017 at 9:= 54 AM
To: "avtext@ietf.org" <= avtext@ietf.org>
Subject: [avtext] Frame marking &am= p; VP9 SVC

Hi,

I have been implementing the framemarking for PERC and I have some doubt= s regarding the VP9 LID mapping.

First, is that according to https://tools.ietf.org/html/draft-ietf-payload-vp9-03 there are no qual= ity layers on VP9 SVC they are considered as case of spatial layers:

   VP9 supports quality layers as spatial layers without any=
 resolution
   changes; hereinafter, the term "spatial layer" is used to repr=
esent
   both spatial and quality layers.

So, shouldn't the LID reference to the spatial layer ID only  and o= mit the quality layer id completely? Also, the spatial layer id is 3 bits o= n that draft.

Also, in order to be able to implement VP9 SVC layer selection, the SFU = needs the information of the P and U bits of the VP9 header description: 

   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<=
/a>).  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 c=
urrent
      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.

Without that info, the SFU won't be able to upscale, so it would be require= d to add that information on the VP9 LID.
Including that changes, it would be something like this:

    0                   1                   2               =
    3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+
   |  ID=3D2 |  L=3D2  |S|E|I|D|B| TID |0|0|0|P|U| SID | =
   TL0PICIDX  |
   +-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+

Best regards
Sergio
 --_000_D4FFF3296BA66mzanatyciscocom_-- From nobody Tue Mar 28 10:02:58 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 5D650129454 for ; Tue, 28 Mar 2017 10:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_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 UQ2AKGWSssBk for ; Tue, 28 Mar 2017 10:02:52 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 57E991292F4 for ; Tue, 28 Mar 2017 10:02:52 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id o81so3757690wmb.1 for ; Tue, 28 Mar 2017 10:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=pjqvjakCocZo/vFBOfnW49sl0pS7ahW+puYvKNED0y8=; b=XLWvHeBWkXJv2P1epOABqvBBVmQbvLIIbUwHP55AHBGxDfLntzrgrOVeL4jWYsBVQI 4mk567vDcWd7y9kSG29elBw1zDgFaHZjG6PNfEynhsDRXopdOdpZSxoJD0eUkH29ROQs JB+QXzGs5AfdimBoyKK9QI6IT3eYmlCWUe9wvfgisyWWljR6XLb7CX/l0JPfnov9KvK3 0+L/7A7juhoXBamNhOmT69iRt++PL191tu6XpuXExuZxmAjX2YFXijPxaL6kooZ5T5TC SYXgjn4d7MokHrSmDmfoxAmR5RSE55i1jWFQ7hdRH+runQXCUBx3g52WZFI4z/23xgC/ QVdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=pjqvjakCocZo/vFBOfnW49sl0pS7ahW+puYvKNED0y8=; b=oVmrpOz+EDKagafK2rxNC/Wt709hRkuEN/J3sR5YEBkWi4wzd6WHu1kKxaPjl9pTFT 1QVygccdJSWvXTvyl/wUpstnzdE5r9Na+8/9stwUqr8UeTpacFXRUYkrLBA8IZKO4AHY m+ruxw8pBQbCys2KlVC3xvapkF2EjK88y1tXrJjD73qKmT/YJaFcJHLNdOhlAEmRFwCK +QtTDojiYKK7aPMKwIyFaRX8ZmrJQNvB+ehg7qbZEPI7o+8TUE+K1uDIXjFagPCM7QZ5 hACYfdxjrL2ouS+BSurLlHfSq/EY4fg4Th5htw054ZD7s7YLpNK3LtGLXk4qYYvIPg3e AiCA== X-Gm-Message-State: AFeK/H30/FJq36Z76navjCMjDoBNeZPC11SYq+/CbBFUsumnRYwOl6MYAWoLdLoNiEU60g== X-Received: by 10.28.55.3 with SMTP id e3mr15511340wma.141.1490720570418; Tue, 28 Mar 2017 10:02:50 -0700 (PDT) Received: from [192.168.1.37] (148.red-79-153-126.dynamicip.rima-tde.net. [79.153.126.148]) by smtp.googlemail.com with ESMTPSA id u7sm5611160wru.56.2017.03.28.10.02.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 10:02:49 -0700 (PDT) To: "Mo Zanaty (mzanaty)" , "avtext@ietf.org" References: From: Sergio Garcia Murillo Message-ID: <081e824d-f986-0818-267d-7cb13e836bb4@gmail.com> Date: Tue, 28 Mar 2017 19:02:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FF986E42EA20673B2A6C2B76" 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: Tue, 28 Mar 2017 17:02:55 -0000 This is a multi-part message in MIME format. --------------FF986E42EA20673B2A6C2B76 Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Hi Mo, Thanks for checking it out. Just one comment, please take into account that in PERC context the payload is encrypted, so the SFU will not have access to the media payload and will only be able to rely on the frame marking extensions to perform the selective forwarding. Best regards Sergio On 28/03/2017 18:53, Mo Zanaty (mzanaty) wrote: > Hi Sergio, > > Good catch. The VP9 payload format has changed since the Frame Marking > LID extensions were defined. The VP9 authors expect it may change > further. Based on discussion during today's AVT session, we will > remove VP9 from the Frame Marking draft (which will help avoid MIS-REF > later), and move that information to the VP9 payload format so it can > evolve without diverging. > > The discussion on U and P bits was more nuanced. The main point is > Frame Marking should help identify when layer refresh has occurred and > when layer up switching is possible. We will add some text on this for > simple, fixed scalability structures, and note that complex, non-fixed > structures require payload-specific inspection and logic that no extra > bits will completely eliminate. > > Cheers, > Mo > > From: avtext > on behalf of Sergio Murillo > > > Date: Tuesday, March 28, 2017 at 9:54 AM > To: "avtext@ietf.org " > > Subject: [avtext] Frame marking & VP9 SVC > > Hi, > > I have been implementing the framemarking for PERC and I have some > doubts regarding the VP9 LID mapping. > > First, is that according to > https://tools.ietf.org/html/draft-ietf-payload-vp9-03 there are no > quality layers on VP9 SVC they are considered as case of spatial layers: > > VP9 supports quality layers as spatial layers without any resolution > changes; hereinafter, the term "spatial layer" is used to represent > both spatial and quality layers. > > 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. > > Also, in order to be able to implement VP9 SVC layer selection, the > SFU needs the information of the P and U bits of the VP9 header > description: > > 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 (seeSection 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. > > Without that info, the SFU won't be able to upscale, so it would be > required to add that information on the VP9 LID. > Including that changes, it would be something like this: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ID=2 | L=2 |S|E|I|D|B| TID |0|0|0|P|U|SID | TL0PICIDX | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Best regards > Sergio --------------FF986E42EA20673B2A6C2B76 Content-Type: text/html; charset=windows-1251 Content-Transfer-Encoding: 8bit
Hi Mo,

Thanks for checking it out.

Just one comment, please take into account that in PERC context the payload is encrypted, so the SFU will not have access to the media payload and will only be able to rely on the frame marking extensions to perform the selective forwarding.

Best regards
Sergio

On 28/03/2017 18:53, Mo Zanaty (mzanaty) wrote:


--------------FF986E42EA20673B2A6C2B76--
Hi Sergio,

Good catch. The VP9 payload format has changed since the Frame Marking LID extensions were defined. The VP9 authors expect it may change further. Based on discussion during today's AVT session, we will remove VP9 from the Frame Marking draft (which will help avoid MIS-REF later), and move that information to the VP9 payload format so it can evolve without diverging.

The discussion on U and P bits was more nuanced. The main point is Frame Marking should help identify when layer refresh has occurred and when layer up switching is possible. We will add some text on this for simple, fixed scalability structures, and note that complex, non-fixed structures require payload-specific inspection and logic that no extra bits will completely eliminate.

Cheers,
Mo

From: avtext <avtext-bounces@ietf.org> on behalf of Sergio Murillo <sergio.garcia.murillo@gmail.com>
Date: Tuesday, March 28, 2017 at 9:54 AM
To: "avtext@ietf.org" <avtext@ietf.org>
Subject: [avtext] Frame marking & VP9 SVC

Hi,

I have been implementing the framemarking for PERC and I have some doubts regarding the VP9 LID mapping.

First, is that according to https://tools.ietf.org/html/draft-ietf-payload-vp9-03 there are no quality layers on VP9 SVC they are considered as case of spatial layers:

   VP9 supports quality layers as spatial layers without any resolution
   changes; hereinafter, the term "spatial layer" is used to represent
   both spatial and quality layers.

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.

Also, in order to be able to implement VP9 SVC layer selection, the SFU needs the information of the P and U bits of the VP9 header description:

   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.

Without that info, the SFU won't be able to upscale, so it would be required to add that information on the VP9 LID.
Including that changes, it would be something like this:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  ID=2 |  L=2  |S|E|I|D|B| TID |0|0|0|P|U| SID |    TL0PICIDX  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Best regards
Sergio