From internet-drafts@ietf.org Fri Aug 2 09:09:10 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2923F21E80E4; Fri, 2 Aug 2013 09:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JATf8GylC3su; Fri, 2 Aug 2013 09:09:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E46321E80C2; Fri, 2 Aug 2013 09:09:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130802160903.7453.98263.idtracker@ietfa.amsl.com> Date: Fri, 02 Aug 2013 09:09:03 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-opus-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 16:09:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : RTP Payload Format for Opus Speech and Audio Codec Author(s) : Julian Spittka Koen Vos Jean-Marc Valin Filename : draft-ietf-payload-rtp-opus-01.txt Pages : 18 Date : 2013-08-02 Abstract: This document defines the Real-time Transport Protocol (RTP) payload format for packetization of Opus encoded speech and audio data that is essential to integrate the codec in the most compatible way. Further, media type registrations are described for the RTP payload format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-opus There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-opus-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-opus-01 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 hhhansen@MAYAH.com Thu Aug 8 03:01:17 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8045F21F9C4E; Thu, 8 Aug 2013 03:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93VkmsCIGSxO; Thu, 8 Aug 2013 03:01:11 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.18.16]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE6621F9C12; Thu, 8 Aug 2013 03:01:09 -0700 (PDT) Received: from [217.91.215.225] (helo=mayah-sbs.MAYAH.COM) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1V7N1n-0005Fo-L2; Thu, 08 Aug 2013 12:01:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Aug 2013 12:01:02 +0200 Message-ID: <031C6AD0F5FEAB449C77DF4E9D047A5C40495B@mayah-sbs.mayah.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-aptx-00.txt Thread-Index: Ac4gDnCa3Fo7/g6xRW2P9VT6PrKdAQgXDU0g From: "Hans-Heinrich Hansen" To: , X-Df-Sender: MzI2MjQx Cc: payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-aptx-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 10:01:17 -0000 We support this draft and hope that this will be formally adopted as = soon as possible so that all devices of different manufacturers can be = compatible. Hans-Heinrich Hansen MAYAH Communications GmbH From yekuiw@qti.qualcomm.com Thu Aug 8 09:40:51 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF2A21E80AC; Thu, 8 Aug 2013 09:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PY80VgetGYmg; Thu, 8 Aug 2013 09:40:47 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9E53111E81D0; Thu, 8 Aug 2013 09:40:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1375980042; x=1407516042; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=bbxBnlLRIwouq1oJoNdAuIWKJkP2gndje5tGVBiTScw=; b=wc2NvinrUWbuCkR7VHWvfuUSQ0vLGM+L42GVMDk3hk0nOQzp9SiNMI0z 2TybT76LzXn/2y+SdrpOAZa5IeV2ZupZChOMmHVuIRqLkw+KI0b6qFK2y H7xJ5Mrt5X4jyP73hs0KAT4JY8fA+D9tcocHIuSQc94cAhFLIyoNAGRp0 c=; X-IronPort-AV: E=Sophos;i="4.89,840,1367996400"; d="scan'208,217";a="49099242" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP; 08 Aug 2013 09:40:42 -0700 X-IronPort-AV: E=Sophos;i="4.89,840,1367996400"; d="scan'208,217";a="517814667" Received: from nasanexhc13.na.qualcomm.com ([172.30.48.20]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 08 Aug 2013 09:40:25 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.21]) by nasanexhc13.na.qualcomm.com ([172.30.48.20]) with mapi id 14.03.0146.002; Thu, 8 Aug 2013 09:40:16 -0700 From: "Wang, Ye-Kui" To: Ross Finlayson , "avt@ietf.org" , "payload@ietf.org" Thread-Topic: [AVTCORE] Clarifying the H.264 RTP payload format specification's text on when to set the RTP "M" bit Thread-Index: AQHOkVzkeMqFQ9EXC0GCRYYICjI/eZmLhfPA Date: Thu, 8 Aug 2013 16:40:15 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.192] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83384D4C47nasanexd02fnaqu_" MIME-Version: 1.0 Subject: Re: [payload] [AVTCORE] Clarifying the H.264 RTP payload format specification's text on when to set the RTP "M" bit X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 16:40:51 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D4C47nasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I share Mo's opinion here that there is no need to add additional text to t= he H.264 or the H.265 draft in this aspect, rather the semantics of the M b= it is sufficient. First of all, implementers are expected to have basic knowledge of the vide= o coding specification itself. If we try to explain all the coding-level de= tails, there can be a lot. Secondly, as I mentioned in the avtcore session in Berlin, the M bit for H.= 264 payload format is not reliable because RFC 6184 supports multi-time agg= regation packets (MTAPs). This is not an issue any more in the H.265 payloa= d as MTAPs are not supported anymore, thus the M bit can be a reliable indi= cation. Of course, bad packetization/sender implementations can make that u= nreliable - but bad packetization/sender implementations can make anything = unreliable - thus they don't count. Lastly, the suggested text is too vague and even incorrect. For example, in= the following copied part: what is "the current NAL unit"? Also, it is pos= sible for non-VCL NAL unit to be between two VCL NAL units in an AU, the fo= llowing language would suggest that the first of the two VCL NAL unit ends = the AU - this is definitely incorrect. The current NAL unit ends an access unit if it is a VCL NAL unit, and i= f either: - the next NAL unit is not a VCL NAL unit, or - the next NAL unit is a VCL NAL unit, and the high-order bit o= f the first byte after its NALU header is 1. BR, YK From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross = Finlayson Sent: Sunday, August 04, 2013 2:52 PM To: avt@ietf.org Subject: Re: [AVTCORE] Clarifying the H.264 RTP payload format specificatio= n's text on when to set the RTP "M" bit If you are willing to detect the last NALU of a frame by waiting for the fi= rst VCL NALU of the next frame, that is very simple in both H.264 and H.265= . The first bit after the VCL NALU header is set if it's the first VCL NALU= of a frame. This works in H.265 because the slice header explicitly has su= ch a flag. Thanks. This is exactly the kind of information that would be useful for i= mplementers. Note that RTP receivers are technically forbidden to rely on the marker bit= . But many implementations detect whether it is reliable, then use it as an= optimization to minimize latency if reliable. Yes, it's unfortunate that there may be implementations out there that do n= ot set the RTP 'M' bit correctly. But to reduce the likelihood of this hap= pening, we should try to make our RTP payload format specifications as clea= r as is reasonable about when to set the 'M' bit. (It is common - in non-i= nteractive environments - for RTP transmitting applications to obtain their= encoded data as a byte stream.) I don't think the draft needs any more text beyond what it currently says. On the contrary - I think you've explained that some additional text would = be both useful and reasonable. (Once again, because we're not MPEG, we sho= uld not feel the need to fully-specify only the behavior that's required by= RTP *receivers*.) So I suggest adding the following paragraph to the H.265 RTP payload format= specification, just after the existing 'M bit' text: ---------- Unfortunately the contents of a NAL unit, alone, does not tell a RTP sender= implementation whether or not the NAL unit ends an access unit. Instead, = the implementation can obtain this information separately, from the encoder= . If, however, this information is not directly available from the encoder= (e.g., because the implementation is sending data that consists solely of = a sequence of pre-encoded NAL units), then it must instead inspect the next= NAL unit, to determine whether or not the current NAL unit ends an access = unit. The following rule can be used: The current NAL unit ends an access unit if it is a VCL NAL unit, and i= f either: - the next NAL unit is not a VCL NAL unit, or - the next NAL unit is a VCL NAL unit, and the high-order bit of = the first byte after its NALU header is 1. ---------- Ross Finlayson Live Networks, Inc. http://www.live555.com/ --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D4C47nasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I share Mo’s opinio= n here that there is no need to add additional text to the H.264 or the H.2= 65 draft in this aspect, rather the semantics of the M bit is sufficient.

 <= /p>

First of all, implementer= s are expected to have basic knowledge of the video coding specification it= self. If we try to explain all the coding-level details, there can be a lot.

 <= /p>

Secondly, as I mentioned = in the avtcore session in Berlin, the M bit for H.264 payload format is not= reliable because RFC 6184 supports multi-time aggregation packets (MTAPs). This is not an issue any more in the H.265 payload as MTA= Ps are not supported anymore, thus the M bit can be a reliable indication. = Of course, bad packetization/sender implementations can make that unreliabl= e – but bad packetization/sender implementations can make anything unreliable – thus they don’t= count.

 <= /p>

Lastly, the suggested tex= t is too vague and even incorrect. For example, in the following copied par= t: what is “the current NAL unit”? Also, it is possible for non-VCL NAL unit to be between two VCL NAL units in an AU, the followi= ng language would suggest that the first of the two VCL NAL unit ends the A= U – this is definitely incorrect.

    The current NAL unit ends an access un= it if it is a VCL NAL unit, and if either:

   &nb= sp;        - the next NAL unit is= not a VCL NAL unit, or

   &nb= sp;        - the next NAL unit is= a VCL NAL unit, and the high-order bit of the first byte after its NALU he= ader is 1.

 <= /p>

BR, YK<= /p>

 <= /p>

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross Finlayson
Sent: Sunday, August 04, 2013 2:52 PM
To: avt@ietf.org
Subject: Re: [AVTCORE] Clarifying the H.264 RTP payload format speci= fication's text on when to set the RTP "M" bit<= /p>

 

If you are willing to de= tect the last NALU of a frame by waiting for the first VCL NALU of the next= frame, that is very simple in both H.264 and H.265. The first bit after the VCL NALU header is set if it’s the first VCL NALU of a= frame. This works in H.265 because the slice header explicitly has such a = flag.

 

Thanks.  This is exactly the kind of informatio= n that would be useful for implementers.

 



Note that RTP receivers = are technically forbidden to rely on the marker bit. But many implementatio= ns detect whether it is reliable, then use it as an optimization to minimize latency if reliable.

 

Yes, it's unfortunate that there may be implementati= ons out there that do not set the RTP 'M' bit correctly.  But to reduc= e the likelihood of this happening, we should try to make our RTP payload f= ormat specifications as clear as is reasonable about when to set the 'M' bit.  (It is common - in non-interactive en= vironments - for RTP transmitting applications to obtain their encoded data= as a byte stream.)

 



 I don’t thin= k the draft needs any more text beyond what it currently says.

 

On the contrary - I think you've explained that some= additional text would be both useful and reasonable.  (Once again, be= cause we're not MPEG, we should not feel the need to fully-specify only the= behavior that's required by RTP *receivers*.)

 

So I suggest adding the following paragraph to the H= .265 RTP payload format specification, just after the existing 'M bit' text= :

 

----------

Unfortunately the contents of a NAL unit, alone, doe= s not tell a RTP sender implementation whether or not the NAL unit ends an = access unit.  Instead, the implementation can obtain this information = separately, from the encoder.  If, however, this information is not directly available from the encoder (e.g., because= the implementation is sending data that consists solely of a sequence of p= re-encoded NAL units), then it must instead inspect the next NAL unit, to d= etermine whether or not the current NAL unit ends an access unit.  The following rule can be used:

    The current NAL unit ends an access un= it if it is a VCL NAL unit, and if either:

   &nb= sp;      - the next NAL unit is not a VCL N= AL unit, or

   &nb= sp;      - the next NAL unit is a VCL NAL u= nit, and the high-order bit of the first byte after its NALU header is 1.

----------

 

Ross Finlayson
Live Networks, Inc.
http:/= /www.live555.com/

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A83384D4C47nasanexd02fnaqu_-- From finlayson@live555.com Thu Aug 8 20:15:28 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C7A11E8146; Thu, 8 Aug 2013 20:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxpvQYMp0RLH; Thu, 8 Aug 2013 20:15:23 -0700 (PDT) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4C47311E80F7; Thu, 8 Aug 2013 20:15:23 -0700 (PDT) Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.4/8.14.4) with ESMTP id r793FKMf011677; Thu, 8 Aug 2013 20:15:21 -0700 (PDT) (envelope-from finlayson@live555.com) From: Ross Finlayson Content-Type: multipart/alternative; boundary="Apple-Mail=_A55FC23C-7ED4-4429-B2D2-BBC7CDB9DF7B" Message-Id: <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Thu, 8 Aug 2013 20:15:19 -0700 References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> To: "avt@ietf.org" , payload@ietf.org In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> X-Mailer: Apple Mail (2.1508) Subject: Re: [payload] [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 03:15:28 -0000 --Apple-Mail=_A55FC23C-7ED4-4429-B2D2-BBC7CDB9DF7B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 (I changed the "Subject:" line to make it clear that we're talking about = the (future) H.265 RTP payload format specification here; not the = (existing) H.264 RTP payload format specification.) > First of all, implementers are expected to have basic knowledge of the = video coding specification itself. Yes. However, in this case we seem to disagree on what constitutes = 'basic knowledge'. Determining whether or not a NAL unit ends an = 'access unit' (in the situation - common for many implementations - = where this is not available directly from the encoder) is far from = 'basic knowledge' of H.265. Unless you can point to a specific section = in the H.265 specification that describes this (in which case we could = add a reference to that section), it seems prudent to add a little text = to our RTP payload format specification that clarifies this. > Of course, bad packetization/sender implementations [of the RTP 'M' = bit] can make that unreliable =96 but bad packetization/sender = implementations can make anything unreliable =96 thus they don=92t = count. I'm not sure what you're saying here. I hope you're not saying that we = shouldn't really care about whether or not implementations set the 'M' = bit correctly, because in that case I definitely disagree; that's the = whole point of this email thread. =20 > Lastly, the suggested text is too vague and even incorrect. Like Mohamed, you're inadvertently making my point for me :-) > For example, in the following copied part: what is =93the current NAL = unit=94? By this I mean the NAL unit that's being packed in the RTP packet for = which we are considering whether or not to set the "M' bit (or the final = such NAL unit, if there's more than one). =20 > Also, it is possible for non-VCL NAL unit to be between two VCL NAL = units in an AU, the [suggested] language would suggest that the first of = the two VCL NAL unit ends the AU =96 this is definitely incorrect. Yes, good point - thanks. Here, then, is new wording for the suggested paragraph (to be added to = the H.265 RTP payload format specification, just after the existing 'M = bit' text): ---------- Unfortunately the contents of a NAL unit, alone, does not tell a RTP = sender implementation whether or not the NAL unit ends an access unit. = Instead, the implementation can obtain this information separately, from = the encoder. If, however, this information is not available directly = from the encoder (e.g., because the implementation is sending data that = consists solely of a sequence of pre-encoded NAL units), then it must = instead inspect subsequent NAL units, to determine whether or not the = NAL unit ends an access unit. The following rule can be used: A NAL unit ends an access unit if it is a VCL NAL unit, and the = next-occurring VCL NAL unit has the high-order bit of the first byte = after its NALU header equal to 1. ---------- Ross Finlayson Live Networks, Inc. http://www.live555.com/ --Apple-Mail=_A55FC23C-7ED4-4429-B2D2-BBC7CDB9DF7B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
(I changed the "Subject:" = line to make it clear that we're talking about the (future) H.265 RTP = payload format specification here; not the (existing) H.264 RTP payload = format specification.)


First of all, = implementers are expected to have basic knowledge of the video coding = specification = itself.

Yes. =  However, in this case we seem to disagree on what constitutes = 'basic knowledge'.  Determining whether or not a NAL unit ends an = 'access unit' (in the situation - common for many implementations - = where this is not available directly from the encoder) is far from = 'basic knowledge' of H.265.  Unless you can point to a specific = section in the H.265 specification that describes this (in which case we = could add a reference to that section), it seems prudent to add a little = text to our RTP payload format specification that clarifies = this.


Of course, bad = packetization/sender implementations [of the RTP 'M' bit] can make that = unreliable =96 but bad packetization/sender implementations can make = anything unreliable =96 thus they don=92t = count.

I'm not sure = what you're saying here.  I hope you're not saying that we = shouldn't really care about whether or not implementations set the 'M' = bit correctly, because in that case I definitely disagree; that's the = whole point of this email = thread.

 
 Lastly, the = suggested text is too vague and even = incorrect.

Like = Mohamed, you're inadvertently making my point for me = :-)


For example, in = the following copied part: what is =93the current NAL = unit=94?

By this I = mean the NAL unit that's being packed in the RTP packet for which we are = considering whether or not to set the "M' bit (or the final such NAL = unit, if there's more than one). =  


Also, it is = possible for non-VCL NAL unit to be between two VCL NAL units in an AU, = the [suggested] language would suggest that the first of the two VCL NAL = unit ends the AU =96 this is definitely = incorrect.

<= div>
Yes, good point - thanks.

Here, then, = is new wording for the suggested paragraph (to be added to the H.265 RTP = payload format specification, just after the existing 'M bit' = text):

----------
Unfortunately = the contents of a NAL unit, alone, does not tell a RTP sender = implementation whether or not the NAL unit ends an access unit. =  Instead, the implementation can obtain this information = separately, from the encoder.  If, however, this information is = not available directly from the encoder (e.g., because the = implementation is sending data that consists solely of a sequence of = pre-encoded NAL units), then it must instead inspect subsequent NAL = units, to determine whether or not the NAL unit ends an access unit. =  The following rule can be used:
    A NAL = unit ends an access unit if it is a VCL NAL unit, and the = next-occurring VCL NAL unit has the high-order bit of the first byte = after its NALU header equal to = 1.
----------

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/=


= --Apple-Mail=_A55FC23C-7ED4-4429-B2D2-BBC7CDB9DF7B-- From tomkrist@cisco.com Fri Aug 9 04:52:46 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7CC21F99A2 for ; Fri, 9 Aug 2013 04:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZPZ0aBabmeq for ; Fri, 9 Aug 2013 04:52:35 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id AC7BC21F9EA3 for ; Fri, 9 Aug 2013 04:52:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42360; q=dns/txt; s=iport; t=1376049153; x=1377258753; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=0qAPpQh8Qkr2WG8FE/U8vpI49pS8ySDWoCpMqdNneaY=; b=EeVFC9kpCOEDKqOpQreW0q1ezx8do0HwSr0uPcKPiofbHo/xEMdTVWUi rH6pqQJMlnK3kGY/X5YtPalxec+CP5HguAjQ/kvVNarLL4e4R/auKpCc4 OwI/ts6ToF2Xb2CDmbn+ySoUnSS2iAHDccJx592sXOddB5lB8ffk3OFHb s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAMPWBFKQ/khM/2dsb2JhbABbgkJENUqIdrVigRkWdIIkAQEBAwEBAQELDBMoEAkKAQULCxEEAQEBCRYBAQYHCQMCAQIBFR8JCAYNAQUCAQEFEodvBgcFuSyOVQkBAYE7BgEJhAUDl2GBKoR8hgWFJIMaOoEsAQQEFw X-IronPort-AV: E=Sophos;i="4.89,845,1367971200"; d="scan'208,217";a="85619805" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 09 Aug 2013 11:52:29 +0000 Received: from [10.47.38.191] ([10.47.38.191]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r79BqRbQ028176; Fri, 9 Aug 2013 11:52:27 GMT Message-ID: <5204D7FB.1020507@cisco.com> Date: Fri, 09 Aug 2013 13:52:27 +0200 From: Tom Kristensen Organization: Cisco User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10 MIME-Version: 1.0 To: "Wang, Ye-Kui" References: <8BA7D4CEACFFE04BA2D902BF11719A83383F92DF@nasanexd02f.na.qualcomm.com> <8BA7D4CEACFFE04BA2D902BF11719A833844E9AB@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A833844E9AB@nasanexd02f.na.qualcomm.com> Content-Type: multipart/alternative; boundary="------------020303050405060802090801" Cc: "payload@ietf.org" Subject: Re: [payload] Submission of new versions of H.265/HEVC payload format X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 11:52:46 -0000 This is a multi-part message in MIME format. --------------020303050405060802090801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit A late response after summer holiday and inbox flooding season; comments/answers inline below. On 06/27/2013 07:28 PM, Wang, Ye-Kui wrote: > > Hi Tom, > > Thanks for the review and the suggestions. I have some comments on the > suggestions. > > On max-fps: The following paragraph in > draft-kristensen-payload-rtp-h241param-00 seems to be the main reason > for the introduction of max-fps. Just for a better understanding, > could you please clarify why the receiver side would have a preferred > frame rate? Does that relate to rendering/display capability? If that > is the case, then discarding of the additional frames should be done > by the rendering module instead of the decoder, as conforming decoders > should just output frames that are indicated, by the bitstream, to be > output. > > If the encoder chooses to send at a higher frame rate than preferred > > by the receiver side, the decoder will normally discard the > > additional frames after decoding them. The transmission of the extra > > frames and the processing of frames to just discard them are wasteful > > and the bandwidth and processing could be used more effectively. > Stephan provided convincing argumentation for this in the IETF-87 AVTCORE session. And as we know both H.264 and H.265 allow very high/extreme framerates for a given level, when the resolution is small enough. The max-fps parameter is meant to set a limit for useful and preferred maximal framerate. And yes, the decoder is one thing. Render/display capability another. The value for max-fps might stem from display/render capability or as Stephan mentioned at IETF-87 - the use of video for content sharing with a typically high resolution/low framerate stream. > Not relevant for H.265/HEVC payload, but for H.264/AVC payload in RFC > 6184, would introduction of such a parameter cause any IOP issue > between a legacy sender and a new receiver? I think that should be > analyzed in draft-kristensen-payload-rtp-h241param-00. Certainly, it > would also be good to clarify the above question related to > rendering/display capability in > draft-kristensen-payload-rtp-h241param-00 too. > Thanks, note taken! I will update the upcoming version of draft-kristensen-payload-rtp-h241param with the interop/backwards compatibility issues valid for H.264 and the rendering/display vs. decoder distinction. > On max-lts: It makes sense to me, but we would need to specify a lower > bound of the value, such that it would at least not contradict with > the min tile size implied by other parameters. > This parameter is no longer proposed, since the signalling need is taken care of in the merged proposal for parallellization tools agreep upon at IETF-87. The minimum tile size should be limited to the lower bound on the tile size in H.265, text might be needed for the dec-parallel-cap. > On max-tr and max-tc: It seems that they are saying that there are > scenarios where you would need more tiles than allowed by the > indicated level. Could you please give an (practical) example that > this is needed? I am asking this because in JCT-VC there had been a > lot of discussions after which the level limits of MaxTileRows and > MaxTileCols were concluded. > The values of maxTileRows and maxTileColumns defined in HEVC were a compromise, mainly between people who wanted to limited the maximum number of tiles for their single-core decoder design and people who wanted a large number of tiles for their multi-core encoder design. Moreover, when making maxTileRows/Cols in HEVC level-dependent (rather than resolution-dependent) it was already anticipated that additional flexibility could be achieved during call negotiation. (See document JCTVC-J0235.) There are at least three reasons for adding max-tr and max-tc as additional optional parameters: 1) Typically video conferencing uses bit rates that are significantly lower than the values specified in HEVC for a given level/resolution. For example, it is expected that 1080p30 can use bit rates at 1 mbps or below, while HEVC specifies a maximum bitrate of 12 mbps for 1080p30 (level 4). To avoid designing CABAC decoding for unnecessarily high bit rates, the practical solution that has been used in the industry since H.264 days has been to signal support for a low level, and then send optional parameters to indicate support for a higher resolution. For example, a 1080p30 capable decoder could signal: - max-recv-level-id = 2.1 (maxBR = 3000) - max-ls = 1920x1080 - max-lps = 1920x0180x30 However, without being able to signal max-tc and max-tr, the encoder would have to comply with the values of maxTileRows and maxTileColumns of level 2.1 (maxTileRows = maxTileColums = 1). 2) Even if a decoder could signal the "true" value of max-recv-level-id, there are encoders who would benefit from using an even higher number of tiles. For example, for level 4 (1080p30), HEVC specifies maxTileRows = maxTileColums = 5, limiting the total number of tiles to 25. On the other hand, there exist processing devices having as many as 64 cores. Also, for sw encoder designs, it might be beneficial to have significantly more tiles than cores for load balancing purposes. A decoder that signals values of max-tr and max-tc larger than those indicated by the signaled level/resolution would give the encoder more freedom to choose the appropriate balance between number of tiles and level of parallelization. 3) Finally, for the sake of consistency, it seems reasonable support the same negotiation mechanisms for all parameters of HEVC tables A-1 and A-2, i.e. not only those corresponding to max-ls, max-lps, max-cbp, max-dpb, and max-br. Cheers, -- Tom > BR, YK > > *From:* payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] *On > Behalf Of *Tom Kristensen > *Sent:* Thursday, June 27, 2013 6:34 AM > *To:* Wang, Ye-Kui > *Cc:* Geir Arne Sandbakken; payload@ietf.org; Tom Kristensen > *Subject:* Re: [payload] Submission of new versions of H.265/HEVC > payload format > > We have done a first review of the new version of this draft. Seems > promising. However, we are missing a couple of things. > > First, we would like to include a max-fps parameter in line with the > proposed draft draft-kristensen-payload-rtp-h241param-00. A similar > parameter has been part of H.241 for while and will eventually be > valid for H.265 in H.323 land too. Note that this is a limiting > parameter, different from the other max-* parameters (max-ls, max-lps, > max-cpb, max-dpb and max-br). > > We propose max-fps as something along the lines of: > > ------ > > max-fps: The value of max-fps is an integer indicating the maximum > > frame rate in units of hundredths of frames per second that can be > > efficiently received. The signaled highest level is conveyed in > > the value of the profile-level-id parameter or the max-recv-level > > parameter. The max-fps parameter MAY be used to signal that the > > receiver has a constraint in that it is not capable of decoding > > video efficiently at the full frame rate that is implied by the > > signaled highest level and, if present, one or more of the > > parameters max-ls, max-lps or max-br. > > Notice that the value of max-fps is not necessarily the frame rate > > at which the maximum frame size can be sent, it constitutes a > > constraint on maximum frame rate for all resolutions. > > Informational note: The max-fps parameter is semantically > > different from max-ls, max-lps, max-cpb, max-dpb, > > and max-br in that max-fps is used to signal a constraint, > > lowering the maximum frame rate from what is implied by the > > signaled MaxLumaSR and MaxLumaPS. > > The encoder MUST use a frame rate equal to or less than this > > value. In cases where the max-fps parameter is absent the > > encoder is free to choose any frame rate according > > to the highest signaled level and any signaled optional > > parameters. > > ------ > > Second, we are missing an ability to signal support for tiles (number > of tiles used/to expect) and maximum tile size. The ability to signal > support for a number of tiles higher than what is implied for the > signalled level (as listed in Table A-1 in the HEVC specification. > These two parameters have the same semantics as the existing max-* > parameters (max-ls, max-lps, max-cpb, max-dpb and max-br). > > We propose max-tr (or max-tile-rows) and the equivalent description > for max-tc (or max-tile-cols) along the lines of: > > ------ > > (Will be introduced toghether with max-ls, max-lps, max-cpb, > max-dpb, max-br, as parameters that "MAY be used to signal the > capabilities of a receiver implementation.") > > capabilities...: > > max-tr: > > The value of max-tr is an integer indication the maximum number > > of tile rows. The max-tr parameter signals that the receiver is > > capable of decoding video with a larger number of tile rows than > > is required by the signaled highest level. > > When max-tr is signaled, the receiver must be able to decode NAL > > unit streams that conform to the signaled highest level, with the > > exception that the MaxTileRows value in Table A-1 of [HEVC] for > > the signaled highest level is replaced with the value of max-tr. > > The value of max-tr MUST be greater than or equal to the value of > > MaxTileRows given in Table A-1 of [HEVC] for the highest > > level. Senders MAY use this knowledge to send pictures utilizing > > a larger number of tile rows than is indicated in the signaled > > highest level. > > max-tc: > > (As for max-tr with s/max-tr/max-tc/ > > s/MaxTileRows/MaxTileCols/ > > s/rows/colums) > > ------ > > The last tile related parameter is a new parameter named max-lts to > specify maximum luma tile size to make sure the decoder doesn't > receive a stream with too large resolution and/or bitrate in one > single tile. The max-lts parameter is a limiting parameter - as > described for max-fps above. > > We propose max-lts to signal the maximum size allowed in one tile > along the lines of: > > ------ > > max-lts: > > The value of max-lts, Maximum Luma Tile Size, is an integer > > indicating the maximum tile size in units of luma samples. The > > max-lts parameter signals the maximum size of one tile that the > > decoder is able to decode. > > Informational note: The max-fps parameter is semantically > > different from max-ls, max-lps, max-cpb, max-dpb, > > and max-br in that max-lts is used to signal a constraint > > on the maximum tile size. > > The encoder MUST use a tile size equal to or less than this > > value. In cases where the max-lts parameter is absent the > > encoder is free to choose any tile size according > > to the highest signaled level and any signaled optional > > parameters. > > ------ > > Please consider these additions. More text needed to merge the new > parameters into the media subtype specification, offer/answer rules > and so on - of course. To be dealt with later. > > -- Tom > > On 11 June 2013 19:00, Wang, Ye-Kui > wrote: > > Dear All, > > We have just submitted versions 02 and 03 of > draft-schierl-payload-rtp-h265, for which the links are as follows: > > Version 02: > URL: > http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-h265-02.txt > Htmlized: http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02 > Diff: http://www.ietf.org/rfcdiff?url2=draft-schierl-payload-rtp-h265-02 > > Version 03: > URL: > http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-h265-03.txt > Htmlized: http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03 > Diff: http://www.ietf.org/rfcdiff?url2=draft-schierl-payload-rtp-h265-03 > > Version 02 includes huge changes compared to the earlier submitted > version 01. In a short summary, the authors have worked hard to try to > make the design complete, from both the payload structure and the > signaling points of view. Compared to version 02, version 03 only > contains a correction of the email address of an author. > > Due to that the industry is eager to deploy H.265/HEVC and other > standards bodies such as 3GPP rely on the payload format for support > of H.265/HEVC in RTP based video services, we need to progress this > draft relatively quickly. Therefore, we would like to request quick > reviews from interested parties and also request for the WG status of > this draft. > > BR, YK (on behalf of the authors) > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > > > > -- > # Cisco | http://www.cisco.com/telepresence/ > ## tomkrist@cisco.com | > http://www.tandberg.com > ### | http://folk.uio.no/tomkri/ > --------------020303050405060802090801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit A late response after summer holiday and inbox flooding season; comments/answers inline below.

On 06/27/2013 07:28 PM, Wang, Ye-Kui wrote:

Hi Tom,

 

Thanks for the review and the suggestions. I have some comments on the suggestions.

 

On max-fps: The following paragraph in draft-kristensen-payload-rtp-h241param-00 seems to be the main reason for the introduction of max-fps. Just for a better understanding, could you please clarify why the receiver side would have a preferred frame rate? Does that relate to rendering/display capability? If that is the case, then discarding of the additional frames should be done by the rendering module instead of the decoder, as conforming decoders should just output frames that are indicated, by the bitstream, to be output.

 

   If the encoder chooses to send at a higher frame rate than preferred

   by the receiver side, the decoder will normally discard the

   additional frames after decoding them.  The transmission of the extra

   frames and the processing of frames to just discard them are wasteful

   and the bandwidth and processing could be used more effectively.


Stephan provided convincing argumentation for this in the IETF-87 AVTCORE session. And as we know both H.264 and H.265 allow very high/extreme framerates for a given level, when the resolution is small enough. The max-fps parameter is meant to set a limit for useful and preferred maximal framerate.

And yes, the decoder is one thing. Render/display capability another. The value for max-fps might stem from display/render capability or as Stephan mentioned at IETF-87 - the use of video for content sharing with a typically high resolution/low framerate stream.
 

Not relevant for H.265/HEVC payload, but for H.264/AVC payload in RFC 6184, would introduction of such a parameter cause any IOP issue between a legacy sender and a new receiver? I think that should be analyzed in draft-kristensen-payload-rtp-h241param-00. Certainly, it would also be good to clarify the above question related to rendering/display capability in draft-kristensen-payload-rtp-h241param-00 too.


Thanks, note taken! I will update the upcoming version of draft-kristensen-payload-rtp-h241param with the interop/backwards compatibility issues valid for H.264 and the rendering/display vs. decoder distinction.

On max-lts: It makes sense to me, but we would need to specify a lower bound of the value, such that it would at least not contradict with the min tile size implied by other parameters.


This parameter is no longer proposed, since the signalling need is taken care of in the merged proposal for parallellization tools agreep upon at IETF-87. The minimum tile size should be limited to the lower bound on the tile size in H.265, text might be needed for the dec-parallel-cap.

On max-tr and max-tc: It seems that they are saying that there are scenarios where you would need more tiles than allowed by the indicated level. Could you please give an (practical) example that this is needed? I am asking this because in JCT-VC there had been a lot of discussions after which the level limits of MaxTileRows and MaxTileCols were concluded.


The values of maxTileRows and maxTileColumns defined in HEVC were a compromise, mainly between people who wanted to limited the maximum number of tiles for their single-core decoder design and people who wanted a large number of tiles for their multi-core encoder design. Moreover, when making maxTileRows/Cols in HEVC level-dependent (rather than resolution-dependent) it was already anticipated that additional flexibility could be achieved during call negotiation. (See document JCTVC-J0235.)
 
There are at least three reasons for adding max-tr and max-tc as additional optional parameters:
 
   1)  Typically video conferencing uses bit rates that are significantly lower than the values specified in HEVC for a given level/resolution. For example, it is expected that 1080p30 can use bit rates at 1 mbps or below, while HEVC specifies a maximum bitrate of 12 mbps for 1080p30 (level 4). To avoid designing CABAC decoding for unnecessarily high bit rates, the practical solution that has been used in the industry since H.264 days has been to signal support for a low level, and then send optional parameters to indicate support for a higher resolution. For example, a 1080p30 capable decoder could signal:
    -  max-recv-level-id = 2.1 (maxBR = 3000)
    -  max-ls = 1920x1080
    -  max-lps = 1920x0180x30
However, without being able to signal max-tc and max-tr, the encoder would have to comply with the values of maxTileRows and maxTileColumns of level 2.1 (maxTileRows = maxTileColums = 1).

   2)  Even if a decoder could signal the “true” value of max-recv-level-id, there are encoders who would benefit from using an even higher number of tiles. For example, for level 4 (1080p30), HEVC specifies maxTileRows = maxTileColums = 5, limiting the total number of tiles to 25. On the other hand, there exist processing devices having as many as 64 cores. Also, for sw encoder designs, it might be beneficial to have significantly more tiles than cores for load balancing purposes. A decoder that signals values of max-tr and max-tc larger than those indicated by the signaled level/resolution would give the encoder more freedom to choose the appropriate balance between number of tiles and level of parallelization.

   3)  Finally, for the sake of consistency, it seems reasonable support the same negotiation mechanisms for all parameters of HEVC tables A-1 and A-2, i.e. not only those corresponding to max-ls, max-lps, max-cbp, max-dpb, and max-br.


Cheers,
-- Tom

 

BR, YK

 

From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Tom Kristensen
Sent: Thursday, June 27, 2013 6:34 AM
To: Wang, Ye-Kui
Cc: Geir Arne Sandbakken; payload@ietf.org; Tom Kristensen
Subject: Re: [payload] Submission of new versions of H.265/HEVC payload format

 

We have done a first review of the new version of this draft. Seems promising. However, we are missing a couple of things.

 

First, we would like to include a max-fps parameter in line with the proposed draft draft-kristensen-payload-rtp-h241param-00. A similar parameter has been part of H.241 for while and will eventually be valid for H.265 in H.323 land too. Note that this is a limiting parameter, different from the other max-* parameters (max-ls, max-lps, max-cpb, max-dpb and max-br).

 

We propose max-fps as something along the lines of:

   ------

   max-fps:  The value of max-fps is an integer indicating the maximum

      frame rate in units of hundredths of frames per second that can be

      efficiently received.  The signaled highest level is conveyed in

      the value of the profile-level-id parameter or the max-recv-level

      parameter.  The max-fps parameter MAY be used to signal that the

      receiver has a constraint in that it is not capable of decoding

      video efficiently at the full frame rate that is implied by the

      signaled highest level and, if present, one or more of the

      parameters max-ls, max-lps or max-br.

 

      Notice that the value of max-fps is not necessarily the frame rate

      at which the maximum frame size can be sent, it constitutes a

      constraint on maximum frame rate for all resolutions.

 

         Informational note: The max-fps parameter is semantically

         different from max-ls, max-lps, max-cpb, max-dpb,

         and max-br in that max-fps is used to signal a constraint,

         lowering the maximum frame rate from what is implied by the

         signaled MaxLumaSR and MaxLumaPS.

 

      The encoder MUST use a frame rate equal to or less than this

      value.  In cases where the max-fps parameter is absent the

      encoder is free to choose any frame rate according

      to the highest signaled level and any signaled optional

      parameters.

   ------

 

Second, we are missing an ability to signal support for tiles (number of tiles used/to expect) and maximum tile size. The ability to signal support for a number of tiles higher than what is implied for the signalled level (as listed in Table A-1 in the HEVC specification. These two parameters have the same semantics as the existing max-* parameters (max-ls, max-lps, max-cpb, max-dpb and max-br).

 

We propose max-tr (or max-tile-rows) and the equivalent description for max-tc (or max-tile-cols) along the lines of:

   ------

   (Will be introduced toghether with max-ls, max-lps, max-cpb, max-dpb, max-br, as parameters that "MAY be used to signal the capabilities of a receiver implementation.")

capabilities...:

 

   max-tr: 

      The value of max-tr is an integer indication the maximum number

      of tile rows. The max-tr parameter signals that the receiver is

      capable of decoding video with a larger number of tile rows than

      is required by the signaled highest level.

 

      When max-tr is signaled, the receiver must be able to decode NAL

      unit streams that conform to the signaled highest level, with the

      exception that the MaxTileRows value in Table A-1 of [HEVC] for

      the signaled highest level is replaced with the value of max-tr.

      The value of max-tr MUST be greater than or equal to the value of

      MaxTileRows given in Table A-1 of [HEVC] for the highest

      level. Senders MAY use this knowledge to send pictures utilizing

      a larger number of tile rows than is indicated in the signaled

      highest level.

 

   max-tc:

      (As for max-tr with s/max-tr/max-tc/

                          s/MaxTileRows/MaxTileCols/

                          s/rows/colums)

   ------

 

The last tile related parameter is a new parameter named max-lts to specify maximum luma tile size to make sure the decoder doesn't receive a stream with too large resolution and/or bitrate in one single tile. The max-lts parameter is a limiting parameter - as described for max-fps above. 

 

We propose max-lts to signal the maximum size allowed in one tile along the lines of:

   ------

   max-lts:

      The value of max-lts, Maximum Luma Tile Size, is an integer

      indicating the maximum tile size in units of luma samples. The

      max-lts parameter signals the maximum size of one tile that the

      decoder is able to decode.

 

         Informational note: The max-fps parameter is semantically

         different from max-ls, max-lps, max-cpb, max-dpb,

         and max-br in that max-lts is used to signal a constraint

         on the maximum tile size.

 

      The encoder MUST use a tile size equal to or less than this

      value.  In cases where the max-lts parameter is absent the

      encoder is free to choose any tile size according

      to the highest signaled level and any signaled optional

      parameters.

   ------

 

Please consider these additions. More text needed to merge the new parameters into the media subtype specification, offer/answer rules and so on - of course. To be dealt with later.

 

-- Tom

 

On 11 June 2013 19:00, Wang, Ye-Kui <yekuiw@qti.qualcomm.com> wrote:

Dear All,

We have just submitted versions 02 and 03 of draft-schierl-payload-rtp-h265, for which the links are as follows:

Version 02:
URL:             http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-h265-02.txt
Htmlized:        http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-schierl-payload-rtp-h265-02

Version 03:
URL:             http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-h265-03.txt
Htmlized:        http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-03
Diff:            http://www.ietf.org/rfcdiff?url2=draft-schierl-payload-rtp-h265-03

Version 02 includes huge changes compared to the earlier submitted version 01. In a short summary, the authors have worked hard to try to make the design complete, from both the payload structure and the signaling points of view. Compared to version 02, version 03 only contains a correction of the email address of an author.

Due to that the industry is eager to deploy H.265/HEVC and other standards bodies such as 3GPP rely on the payload format for support of H.265/HEVC in RTP based video services, we need to progress this draft relatively quickly. Therefore, we would like to request quick reviews from interested parties and also request for the WG status of this draft.

BR, YK (on behalf of the authors)
_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload



 

--
# Cisco                         |  http://www.cisco.com/telepresence/
## tomkrist@cisco.com  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/


--------------020303050405060802090801-- From yekuiw@qti.qualcomm.com Fri Aug 9 06:01:12 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBFA11E80AD; Fri, 9 Aug 2013 06:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s39h+S-YPU1T; Fri, 9 Aug 2013 06:01:07 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 275E621E804B; Fri, 9 Aug 2013 06:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1376053265; x=1407589265; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=NOiR/EXSJrXdjSLmtxt39oCus/g92dlcWPZAssxkv4E=; b=j1jdvJHonJjK6JYxE7QlYrfWvA5foQPslkbafWa3ujBelbxgb37zvf1m vbfGwUWs77ei6CDqajk3e5Le/ssEsV7rJmCoaMbK9+8J4FOI9mZS4mbpq +YDCJJMXDSJJl0ODXqNcz4Ndll5sCPgP19VFLUU44bOw6Iv3LP6TVuSly I=; X-IronPort-AV: E=Sophos;i="4.89,846,1367996400"; d="scan'208,217";a="49272985" Received: from unknown (HELO ironmsg01-lv.qualcomm.com) ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 09 Aug 2013 06:01:03 -0700 Received: from nasanexhc13.na.qualcomm.com ([172.30.48.20]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 09 Aug 2013 06:01:03 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.21]) by nasanexhc13.na.qualcomm.com ([172.30.48.20]) with mapi id 14.03.0146.002; Fri, 9 Aug 2013 06:01:03 -0700 From: "Wang, Ye-Kui" To: Ross Finlayson , "avt@ietf.org" , "payload@ietf.org" Thread-Topic: [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit Thread-Index: AQHOlK64MyApD0+0bEyc75pQI3FkapmM0zAQ Date: Fri, 9 Aug 2013 13:01:02 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> In-Reply-To: <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.192] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3nasanexd02fnaqu_" MIME-Version: 1.0 Subject: Re: [payload] [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 13:01:12 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3nasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Though I don't think it is not really necessary, I think we can either simp= ly add a note after the semantics of the M bit saying that the first slice = header bit indicates that the slice is the first slice of a picture, or men= tion this as part of the introduction to HEVC. The addition is not really necessary because the first slice header bit is = more expected to be used by video decoders for detection of the start of a = new picture without relying on timing (because they might not be available = to the decoder etc), while for the receivers at RTP level, they can always = use the M bit and/or the RTP timestamp. The semantics of the M bit is clearly specified, thus sender implementation= s should follow the semantics. Those implementations that do not follow wha= t is specified, e.g. the M bit semantics, when encapsulating NAL units into= packets, are bad implementations. It seems to me that the reasoning for yo= ur suggestion is that you expect in the future a lot of H.265 RTP payload f= ormat implementations would not follow the M bit. Nobody knows the future, = but I hope this would not happen, as it is so easy to follow the semantics,= and I don't see a reason why implementers would not follow what is being s= pecified. As I explained twice already, not as in RFC 6184, in the context = of the H.265 payload draft, there is no reliability issue with the M bit to= be used for detection the end of an AU (after de-jittering of course - sam= e for all approaches. BR, YK From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross = Finlayson Sent: Thursday, August 08, 2013 8:15 PM To: avt@ietf.org; payload@ietf.org Subject: Re: [AVTCORE] Clarifying the H.265 RTP payload format specificatio= n's text on when to set the RTP "M" bit (I changed the "Subject:" line to make it clear that we're talking about th= e (future) H.265 RTP payload format specification here; not the (existing) = H.264 RTP payload format specification.) First of all, implementers are expected to have basic knowledge of the vide= o coding specification itself. Yes. However, in this case we seem to disagree on what constitutes 'basic = knowledge'. Determining whether or not a NAL unit ends an 'access unit' (i= n the situation - common for many implementations - where this is not avail= able directly from the encoder) is far from 'basic knowledge' of H.265. Un= less you can point to a specific section in the H.265 specification that de= scribes this (in which case we could add a reference to that section), it s= eems prudent to add a little text to our RTP payload format specification t= hat clarifies this. Of course, bad packetization/sender implementations [of the RTP 'M' bit] ca= n make that unreliable - but bad packetization/sender implementations can m= ake anything unreliable - thus they don't count. I'm not sure what you're saying here. I hope you're not saying that we sho= uldn't really care about whether or not implementations set the 'M' bit cor= rectly, because in that case I definitely disagree; that's the whole point = of this email thread. Lastly, the suggested text is too vague and even incorrect. Like Mohamed, you're inadvertently making my point for me :-) For example, in the following copied part: what is "the current NAL unit"? By this I mean the NAL unit that's being packed in the RTP packet for which= we are considering whether or not to set the "M' bit (or the final such NA= L unit, if there's more than one). Also, it is possible for non-VCL NAL unit to be between two VCL NAL units i= n an AU, the [suggested] language would suggest that the first of the two V= CL NAL unit ends the AU - this is definitely incorrect. Yes, good point - thanks. Here, then, is new wording for the suggested paragraph (to be added to the = H.265 RTP payload format specification, just after the existing 'M bit' tex= t): ---------- Unfortunately the contents of a NAL unit, alone, does not tell a RTP sender= implementation whether or not the NAL unit ends an access unit. Instead, = the implementation can obtain this information separately, from the encoder= . If, however, this information is not available directly from the encoder= (e.g., because the implementation is sending data that consists solely of = a sequence of pre-encoded NAL units), then it must instead inspect subseque= nt NAL units, to determine whether or not the NAL unit ends an access unit.= The following rule can be used: A NAL unit ends an access unit if it is a VCL NAL unit, and the next-oc= curring VCL NAL unit has the high-order bit of the first byte after its NAL= U header equal to 1. ---------- Ross Finlayson Live Networks, Inc. http://www.live555.com/ --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3nasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Though I don’t thin= k it is not really necessary, I think we can either simply add a note after= the semantics of the M bit saying that the first slice header bit indicates that the slice is the first slice of a picture, or mention t= his as part of the introduction to HEVC.

 <= /p>

The addition is not reall= y necessary because the first slice header bit is more expected to be used = by video decoders for detection of the start of a new picture without relying on timing (because they might not be available to the deco= der etc), while for the receivers at RTP level, they can always use the M b= it and/or the RTP timestamp.

 <= /p>

The semantics of the M bi= t is clearly specified, thus sender implementations should follow the seman= tics. Those implementations that do not follow what is specified, e.g. the M bit semantics, when encapsulating NAL units into packets, are b= ad implementations. It seems to me that the reasoning for your suggestion i= s that you expect in the future a lot of H.265 RTP payload format implement= ations would not follow the M bit. Nobody knows the future, but I hope this would not happen, as it is so eas= y to follow the semantics, and I don’t see a reason why implementers = would not follow what is being specified. As I explained twice already, not= as in RFC 6184, in the context of the H.265 payload draft, there is no reliability issue with the M bit to be us= ed for detection the end of an AU (after de-jittering of course – sam= e for all approaches.

 <= /p>

BR, YK<= /p>

 <= /p>

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross Finlayson
Sent: Thursday, August 08, 2013 8:15 PM
To: avt@ietf.org; payload@ietf.org
Subject: Re: [AVTCORE] Clarifying the H.265 RTP payload format speci= fication's text on when to set the RTP "M" bit<= /p>

 

(I changed the "Subject:" line to make it = clear that we're talking about the (future) H.265 RTP payload format specif= ication here; not the (existing) H.264 RTP payload format specification.)

 



First of all, implementer= s are expected to have basic knowledge of the video coding specification it= self.

 

Yes.  However, in this case we seem to disagree= on what constitutes 'basic knowledge'.  Determining whether or not a = NAL unit ends an 'access unit' (in the situation - common for many implemen= tations - where this is not available directly from the encoder) is far from 'basic knowledge' of H.265.  Unless you= can point to a specific section in the H.265 specification that describes = this (in which case we could add a reference to that section), it seems pru= dent to add a little text to our RTP payload format specification that clarifies this.

 

 

Of course, bad packetizat= ion/sender implementations [of the RTP 'M' bit] can make that unreliable &#= 8211; but bad packetization/sender implementations can make anything unreliable – thus they don’t count.

 

I'm not sure what you're saying here.  I hope y= ou're not saying that we shouldn't really care about whether or not impleme= ntations set the 'M' bit correctly, because in that case I definitely disag= ree; that's the whole point of this email thread.

 

 

 Lastly, the suggest= ed text is too vague and even incorrect.

 

Like Mohamed, you're inadvertently making my point f= or me :-)

 

 

For example, in the follo= wing copied part: what is “the current NAL unit”?

 

By this I mean the NAL unit that's being packed in t= he RTP packet for which we are considering whether or not to set the "= M' bit (or the final such NAL unit, if there's more than one).  <= /o:p>

 



Also, it is possible for = non-VCL NAL unit to be between two VCL NAL units in an AU, the [suggested] = language would suggest that the first of the two VCL NAL unit ends the AU – this is definitely incorrect.

 

Yes, good point - thanks.

 

Here, then, is new wording for the suggested paragra= ph (to be added to the H.265 RTP payload format specification, just after t= he existing 'M bit' text):

 

----------

Unfortunately the contents of a NAL unit, alone, doe= s not tell a RTP sender implementation whether or not the NAL unit ends an = access unit.  Instead, the implementation can obtain this information = separately, from the encoder.  If, however, this information is not available directly from the encoder (e.g= ., because the implementation is sending data that consists solely of a seq= uence of pre-encoded NAL units), then it must instead inspect subsequent NA= L units, to determine whether or not the NAL unit ends an access unit.  The following rule can be used:=

    A NAL unit ends an access unit if it i= s a VCL NAL unit, and the next-occurring VCL NAL unit has the high-ord= er bit of the first byte after its NALU header equal to 1.

----------

 

Ross Finlayson
Live Networks, Inc.
http:/= /www.live555.com/

 

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3nasanexd02fnaqu_-- From yekuiw@qti.qualcomm.com Fri Aug 9 08:55:09 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CED621F9F97; Fri, 9 Aug 2013 08:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrC9bsnBqS2j; Fri, 9 Aug 2013 08:55:04 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 4E47811E80E6; Fri, 9 Aug 2013 08:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1376063269; x=1407599269; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=FNO/iVA6naupcatYyBsy5IGI/cKqRH8G5+YlgEUXQSU=; b=Y0v46xTfg9o7YW2sh5o3loLAoE9NGhYjwP0iZOquWYoKpVoRlUNfARzJ 5bEzoupJcWTOFgnBiD5vXkhZ9WpWhOl2xmCLjVWu2k0Y1mv9g+ndighm0 849JaqU7XgBy+3WoCgYn2Fh/v4wOUdkXBhCOiEybGeWMjlVl7pmdGTnev I=; X-IronPort-AV: E=Sophos;i="4.89,846,1367996400"; d="scan'208,217";a="49280889" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 09 Aug 2013 08:47:45 -0700 X-IronPort-AV: E=Sophos;i="4.89,846,1367996400"; d="scan'208,217";a="581848004" Received: from nasanexhc16.na.qualcomm.com ([10.45.158.213]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 09 Aug 2013 08:47:45 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.21]) by nasanexhc16.na.qualcomm.com ([10.45.158.213]) with mapi id 14.03.0146.002; Fri, 9 Aug 2013 08:47:45 -0700 From: "Wang, Ye-Kui" To: Ross Finlayson , "avt@ietf.org" , "payload@ietf.org" Thread-Topic: [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit Thread-Index: AQHOlQCLVlfaHsfVP0SU09HfIMXjqJmNBWbA Date: Fri, 9 Aug 2013 15:47:44 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83384D6184@nasanexd02f.na.qualcomm.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.39.5] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83384D6184nasanexd02fnaqu_" MIME-Version: 1.0 Subject: Re: [payload] [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:55:09 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D6184nasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Typo: "Though I don't think it is not really necessary" -> "Though I don't = think it is really necessary" or "Though I think it is not really necessary= ". From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Wang,= Ye-Kui Sent: Friday, August 09, 2013 6:01 AM To: Ross Finlayson; avt@ietf.org; payload@ietf.org Subject: Re: [AVTCORE] Clarifying the H.265 RTP payload format specificatio= n's text on when to set the RTP "M" bit Though I don't think it is not really necessary, I think we can either simp= ly add a note after the semantics of the M bit saying that the first slice = header bit indicates that the slice is the first slice of a picture, or men= tion this as part of the introduction to HEVC. The addition is not really necessary because the first slice header bit is = more expected to be used by video decoders for detection of the start of a = new picture without relying on timing (because they might not be available = to the decoder etc), while for the receivers at RTP level, they can always = use the M bit and/or the RTP timestamp. The semantics of the M bit is clearly specified, thus sender implementation= s should follow the semantics. Those implementations that do not follow wha= t is specified, e.g. the M bit semantics, when encapsulating NAL units into= packets, are bad implementations. It seems to me that the reasoning for yo= ur suggestion is that you expect in the future a lot of H.265 RTP payload f= ormat implementations would not follow the M bit. Nobody knows the future, = but I hope this would not happen, as it is so easy to follow the semantics,= and I don't see a reason why implementers would not follow what is being s= pecified. As I explained twice already, not as in RFC 6184, in the context = of the H.265 payload draft, there is no reliability issue with the M bit to= be used for detection the end of an AU (after de-jittering of course - sam= e for all approaches. BR, YK From: avt-bounces@ietf.org [mailto:avt-bounces= @ietf.org] On Behalf Of Ross Finlayson Sent: Thursday, August 08, 2013 8:15 PM To: avt@ietf.org; payload@ietf.org Subject: Re: [AVTCORE] Clarifying the H.265 RTP payload format specificatio= n's text on when to set the RTP "M" bit (I changed the "Subject:" line to make it clear that we're talking about th= e (future) H.265 RTP payload format specification here; not the (existing) = H.264 RTP payload format specification.) First of all, implementers are expected to have basic knowledge of the vide= o coding specification itself. Yes. However, in this case we seem to disagree on what constitutes 'basic = knowledge'. Determining whether or not a NAL unit ends an 'access unit' (i= n the situation - common for many implementations - where this is not avail= able directly from the encoder) is far from 'basic knowledge' of H.265. Un= less you can point to a specific section in the H.265 specification that de= scribes this (in which case we could add a reference to that section), it s= eems prudent to add a little text to our RTP payload format specification t= hat clarifies this. Of course, bad packetization/sender implementations [of the RTP 'M' bit] ca= n make that unreliable - but bad packetization/sender implementations can m= ake anything unreliable - thus they don't count. I'm not sure what you're saying here. I hope you're not saying that we sho= uldn't really care about whether or not implementations set the 'M' bit cor= rectly, because in that case I definitely disagree; that's the whole point = of this email thread. Lastly, the suggested text is too vague and even incorrect. Like Mohamed, you're inadvertently making my point for me :-) For example, in the following copied part: what is "the current NAL unit"? By this I mean the NAL unit that's being packed in the RTP packet for which= we are considering whether or not to set the "M' bit (or the final such NA= L unit, if there's more than one). Also, it is possible for non-VCL NAL unit to be between two VCL NAL units i= n an AU, the [suggested] language would suggest that the first of the two V= CL NAL unit ends the AU - this is definitely incorrect. Yes, good point - thanks. Here, then, is new wording for the suggested paragraph (to be added to the = H.265 RTP payload format specification, just after the existing 'M bit' tex= t): ---------- Unfortunately the contents of a NAL unit, alone, does not tell a RTP sender= implementation whether or not the NAL unit ends an access unit. Instead, = the implementation can obtain this information separately, from the encoder= . If, however, this information is not available directly from the encoder= (e.g., because the implementation is sending data that consists solely of = a sequence of pre-encoded NAL units), then it must instead inspect subseque= nt NAL units, to determine whether or not the NAL unit ends an access unit.= The following rule can be used: A NAL unit ends an access unit if it is a VCL NAL unit, and the next-oc= curring VCL NAL unit has the high-order bit of the first byte after its NAL= U header equal to 1. ---------- Ross Finlayson Live Networks, Inc. http://www.live555.com/ --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D6184nasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Typo: “Though I don’t think it is not really necessary= ” -> “Though I don’t think = it is really necessary” or “<= /span>Though I think it is not really necessary”= ;.

 <= /p>

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Wang, Ye-Kui
Sent: Friday, August 09, 2013 6:01 AM
To: Ross Finlayson; avt@ietf.org; payload@ietf.org
Subject: Re: [AVTCORE] Clarifying the H.265 RTP payload format speci= fication's text on when to set the RTP "M" bit<= /p>

 

Though I don’t thin= k it is not really necessary, I think we can either simply add a note after= the semantics of the M bit saying that the first slice header bit indicates that the slice is the first slice of a picture, or mention t= his as part of the introduction to HEVC.

 <= /p>

The addition is not reall= y necessary because the first slice header bit is more expected to be used = by video decoders for detection of the start of a new picture without relying on timing (because they might not be available to the deco= der etc), while for the receivers at RTP level, they can always use the M b= it and/or the RTP timestamp.

 <= /p>

The semantics of the M bi= t is clearly specified, thus sender implementations should follow the seman= tics. Those implementations that do not follow what is specified, e.g. the M bit semantics, when encapsulating NAL units into packets, are b= ad implementations. It seems to me that the reasoning for your suggestion i= s that you expect in the future a lot of H.265 RTP payload format implement= ations would not follow the M bit. Nobody knows the future, but I hope this would not happen, as it is so eas= y to follow the semantics, and I don’t see a reason why implementers = would not follow what is being specified. As I explained twice already, not= as in RFC 6184, in the context of the H.265 payload draft, there is no reliability issue with the M bit to be us= ed for detection the end of an AU (after de-jittering of course – sam= e for all approaches.

 <= /p>

BR, YK<= /p>

 <= /p>

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross Finlayson
Sent: Thursday, August 08, 2013 8:15 PM
To: avt@ietf.org; payload@ietf.org
Subject: Re: [AVTCORE] Clarifying the H.265 RTP payload format speci= fication's text on when to set the RTP "M" bit<= /p>

 

(I changed the "Subject:" line to make it = clear that we're talking about the (future) H.265 RTP payload format specif= ication here; not the (existing) H.264 RTP payload format specification.)

 

 

First of all, implementer= s are expected to have basic knowledge of the video coding specification it= self.

 

Yes.  However, in this case we seem to disagree= on what constitutes 'basic knowledge'.  Determining whether or not a = NAL unit ends an 'access unit' (in the situation - common for many implemen= tations - where this is not available directly from the encoder) is far from 'basic knowledge' of H.265.  Unless you= can point to a specific section in the H.265 specification that describes = this (in which case we could add a reference to that section), it seems pru= dent to add a little text to our RTP payload format specification that clarifies this.

 

 

Of course, bad packetizat= ion/sender implementations [of the RTP 'M' bit] can make that unreliable &#= 8211; but bad packetization/sender implementations can make anything unreliable – thus they don’t count.

 

I'm not sure what you're saying here.  I hope y= ou're not saying that we shouldn't really care about whether or not impleme= ntations set the 'M' bit correctly, because in that case I definitely disag= ree; that's the whole point of this email thread.

 

 

 Lastly, the suggest= ed text is too vague and even incorrect.

 

Like Mohamed, you're inadvertently making my point f= or me :-)

 

 

For example, in the follo= wing copied part: what is “the current NAL unit”?

 

By this I mean the NAL unit that's being packed in t= he RTP packet for which we are considering whether or not to set the "= M' bit (or the final such NAL unit, if there's more than one).  <= /o:p>

 

 

Also, it is possible for = non-VCL NAL unit to be between two VCL NAL units in an AU, the [suggested] = language would suggest that the first of the two VCL NAL unit ends the AU – this is definitely incorrect.

 

Yes, good point - thanks.

 

Here, then, is new wording for the suggested paragra= ph (to be added to the H.265 RTP payload format specification, just after t= he existing 'M bit' text):

 

----------

Unfortunately the contents of a NAL unit, alone, doe= s not tell a RTP sender implementation whether or not the NAL unit ends an = access unit.  Instead, the implementation can obtain this information = separately, from the encoder.  If, however, this information is not available directly from the encoder (e.g= ., because the implementation is sending data that consists solely of a seq= uence of pre-encoded NAL units), then it must instead inspect subsequent NA= L units, to determine whether or not the NAL unit ends an access unit.  The following rule can be used:=

    A NAL unit ends an access unit if it i= s a VCL NAL unit, and the next-occurring VCL NAL unit has the high-ord= er bit of the first byte after its NALU header equal to 1.

----------

 

Ross Finlayson
Live Networks, Inc.
http:/= /www.live555.com/

 

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A83384D6184nasanexd02fnaqu_-- From yekuiw@qti.qualcomm.com Fri Aug 9 11:01:09 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AD511E8123 for ; Fri, 9 Aug 2013 11:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AD48SL-iX7hv for ; Fri, 9 Aug 2013 11:00:59 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id A5B7421F9C6F for ; Fri, 9 Aug 2013 10:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1376070948; x=1407606948; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QHVd4eUE+rIE9aR67p5PjY+XUNTU9+Q3WX0gRCQyG70=; b=EbZQo7AjMRI6branB5a88TGGccAu6NAFoxKLQSOlysREr7xhpI3g1BPZ kCcnxHoLKTF/WATCHlNyy+fARmKbFW1iYnVApX6pCDKOw/IvvlbrKLF0w C6hcJYFgU2d20t9imAiRXgFFc/agSKRKkrjv4WhX5UMcgm9gdz7avBIK+ c=; X-IronPort-AV: E=Sophos;i="4.89,847,1367996400"; d="scan'208,217";a="49288881" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 09 Aug 2013 10:55:47 -0700 Received: from nasanexhc17.na.qualcomm.com ([10.45.158.129]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 09 Aug 2013 10:55:47 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.21]) by NASANEXHC17.na.qualcomm.com ([10.45.158.129]) with mapi id 14.03.0146.002; Fri, 9 Aug 2013 10:55:47 -0700 From: "Wang, Ye-Kui" To: Tom Kristensen Thread-Topic: [payload] Submission of new versions of H.265/HEVC payload format Thread-Index: AQHOczrzTxJvXBhLWkGnuMyZJW3g0ZlJxGPggEO4VoD//+8kkA== Date: Fri, 9 Aug 2013 17:55:46 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83384D6529@nasanexd02f.na.qualcomm.com> References: <8BA7D4CEACFFE04BA2D902BF11719A83383F92DF@nasanexd02f.na.qualcomm.com> <8BA7D4CEACFFE04BA2D902BF11719A833844E9AB@nasanexd02f.na.qualcomm.com> <5204D7FB.1020507@cisco.com> In-Reply-To: <5204D7FB.1020507@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83384D6529nasanexd02fnaqu_" MIME-Version: 1.0 Cc: "payload@ietf.org" Subject: Re: [payload] Submission of new versions of H.265/HEVC payload format X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 18:01:09 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D6529nasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Tom for the answers and clarifications. It seems convincing to me th= at we should add max-tr and max-tc on top of what have been agreed at the a= vtcore session in Berlin. I will include them in the next version unless people have issues with it -= so please speak up if you do have issues. BR, YK From: Tom Kristensen [mailto:tomkrist@cisco.com] Sent: Friday, August 09, 2013 4:52 AM To: Wang, Ye-Kui Cc: Tom Kristensen; payload@ietf.org Subject: Re: [payload] Submission of new versions of H.265/HEVC payload for= mat A late response after summer holiday and inbox flooding season; comments/an= swers inline below. On 06/27/2013 07:28 PM, Wang, Ye-Kui wrote: Hi Tom, Thanks for the review and the suggestions. I have some comments on the sugg= estions. On max-fps: The following paragraph in draft-kristensen-payload-rtp-h241par= am-00 seems to be the main reason for the introduction of max-fps. Just for= a better understanding, could you please clarify why the receiver side wou= ld have a preferred frame rate? Does that relate to rendering/display capab= ility? If that is the case, then discarding of the additional frames should= be done by the rendering module instead of the decoder, as conforming deco= ders should just output frames that are indicated, by the bitstream, to be = output. If the encoder chooses to send at a higher frame rate than preferred by the receiver side, the decoder will normally discard the additional frames after decoding them. The transmission of the extra frames and the processing of frames to just discard them are wasteful and the bandwidth and processing could be used more effectively. Stephan provided convincing argumentation for this in the IETF-87 AVTCORE s= ession. And as we know both H.264 and H.265 allow very high/extreme framera= tes for a given level, when the resolution is small enough. The max-fps par= ameter is meant to set a limit for useful and preferred maximal framerate. And yes, the decoder is one thing. Render/display capability another. The v= alue for max-fps might stem from display/render capability or as Stephan me= ntioned at IETF-87 - the use of video for content sharing with a typically = high resolution/low framerate stream. Not relevant for H.265/HEVC payload, but for H.264/AVC payload in RFC 6184,= would introduction of such a parameter cause any IOP issue between a legac= y sender and a new receiver? I think that should be analyzed in draft-krist= ensen-payload-rtp-h241param-00. Certainly, it would also be good to clarify= the above question related to rendering/display capability in draft-kriste= nsen-payload-rtp-h241param-00 too. Thanks, note taken! I will update the upcoming version of draft-kristensen-= payload-rtp-h241param with the interop/backwards compatibility issues valid= for H.264 and the rendering/display vs. decoder distinction. On max-lts: It makes sense to me, but we would need to specify a lower boun= d of the value, such that it would at least not contradict with the min til= e size implied by other parameters. This parameter is no longer proposed, since the signalling need is taken ca= re of in the merged proposal for parallellization tools agreep upon at IETF= -87. The minimum tile size should be limited to the lower bound on the tile= size in H.265, text might be needed for the dec-parallel-cap. On max-tr and max-tc: It seems that they are saying that there are scenario= s where you would need more tiles than allowed by the indicated level. Coul= d you please give an (practical) example that this is needed? I am asking t= his because in JCT-VC there had been a lot of discussions after which the l= evel limits of MaxTileRows and MaxTileCols were concluded. The values of maxTileRows and maxTileColumns defined in HEVC were a comprom= ise, mainly between people who wanted to limited the maximum number of tile= s for their single-core decoder design and people who wanted a large number= of tiles for their multi-core encoder design. Moreover, when making maxTil= eRows/Cols in HEVC level-dependent (rather than resolution-dependent) it wa= s already anticipated that additional flexibility could be achieved during = call negotiation. (See document JCTVC-J0235.) There are at least three reasons for adding max-tr and max-tc as additional= optional parameters: 1) Typically video conferencing uses bit rates that are significantly l= ower than the values specified in HEVC for a given level/resolution. For ex= ample, it is expected that 1080p30 can use bit rates at 1 mbps or below, wh= ile HEVC specifies a maximum bitrate of 12 mbps for 1080p30 (level 4). To a= void designing CABAC decoding for unnecessarily high bit rates, the practic= al solution that has been used in the industry since H.264 days has been to= signal support for a low level, and then send optional parameters to indic= ate support for a higher resolution. For example, a 1080p30 capable decoder= could signal: - max-recv-level-id =3D 2.1 (maxBR =3D 3000) - max-ls =3D 1920x1080 - max-lps =3D 1920x0180x30 However, without being able to signal max-tc and max-tr, the encoder would = have to comply with the values of maxTileRows and maxTileColumns of level 2= .1 (maxTileRows =3D maxTileColums =3D 1). 2) Even if a decoder could signal the "true" value of max-recv-level-id= , there are encoders who would benefit from using an even higher number of = tiles. For example, for level 4 (1080p30), HEVC specifies maxTileRows =3D m= axTileColums =3D 5, limiting the total number of tiles to 25. On the other = hand, there exist processing devices having as many as 64 cores. Also, for = sw encoder designs, it might be beneficial to have significantly more tiles= than cores for load balancing purposes. A decoder that signals values of m= ax-tr and max-tc larger than those indicated by the signaled level/resoluti= on would give the encoder more freedom to choose the appropriate balance be= tween number of tiles and level of parallelization. 3) Finally, for the sake of consistency, it seems reasonable support th= e same negotiation mechanisms for all parameters of HEVC tables A-1 and A-2= , i.e. not only those corresponding to max-ls, max-lps, max-cbp, max-dpb, a= nd max-br. Cheers, -- Tom BR, YK From: payload-bounces@ietf.org [mailto:pay= load-bounces@ietf.org] On Behalf Of Tom Kristensen Sent: Thursday, June 27, 2013 6:34 AM To: Wang, Ye-Kui Cc: Geir Arne Sandbakken; payload@ietf.org; Tom Kr= istensen Subject: Re: [payload] Submission of new versions of H.265/HEVC payload for= mat We have done a first review of the new version of this draft. Seems promisi= ng. However, we are missing a couple of things. First, we would like to include a max-fps parameter in line with the propos= ed draft draft-kristensen-payload-rtp-h241param-00. A similar parameter has= been part of H.241 for while and will eventually be valid for H.265 in H.3= 23 land too. Note that this is a limiting parameter, different from the oth= er max-* parameters (max-ls, max-lps, max-cpb, max-dpb and max-br). We propose max-fps as something along the lines of: ------ max-fps: The value of max-fps is an integer indicating the maximum frame rate in units of hundredths of frames per second that can be efficiently received. The signaled highest level is conveyed in the value of the profile-level-id parameter or the max-recv-level parameter. The max-fps parameter MAY be used to signal that the receiver has a constraint in that it is not capable of decoding video efficiently at the full frame rate that is implied by the signaled highest level and, if present, one or more of the parameters max-ls, max-lps or max-br. Notice that the value of max-fps is not necessarily the frame rate at which the maximum frame size can be sent, it constitutes a constraint on maximum frame rate for all resolutions. Informational note: The max-fps parameter is semantically different from max-ls, max-lps, max-cpb, max-dpb, and max-br in that max-fps is used to signal a constraint, lowering the maximum frame rate from what is implied by the signaled MaxLumaSR and MaxLumaPS. The encoder MUST use a frame rate equal to or less than this value. In cases where the max-fps parameter is absent the encoder is free to choose any frame rate according to the highest signaled level and any signaled optional parameters. ------ Second, we are missing an ability to signal support for tiles (number of ti= les used/to expect) and maximum tile size. The ability to signal support fo= r a number of tiles higher than what is implied for the signalled level (as= listed in Table A-1 in the HEVC specification. These two parameters have t= he same semantics as the existing max-* parameters (max-ls, max-lps, max-cp= b, max-dpb and max-br). We propose max-tr (or max-tile-rows) and the equivalent description for max= -tc (or max-tile-cols) along the lines of: ------ (Will be introduced toghether with max-ls, max-lps, max-cpb, max-dpb, ma= x-br, as parameters that "MAY be used to signal the capabilities of a recei= ver implementation.") capabilities...: max-tr: The value of max-tr is an integer indication the maximum number of tile rows. The max-tr parameter signals that the receiver is capable of decoding video with a larger number of tile rows than is required by the signaled highest level. When max-tr is signaled, the receiver must be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxTileRows value in Table A-1 of [HEVC] for the signaled highest level is replaced with the value of max-tr. The value of max-tr MUST be greater than or equal to the value of MaxTileRows given in Table A-1 of [HEVC] for the highest level. Senders MAY use this knowledge to send pictures utilizing a larger number of tile rows than is indicated in the signaled highest level. max-tc: (As for max-tr with s/max-tr/max-tc/ s/MaxTileRows/MaxTileCols/ s/rows/colums) ------ The last tile related parameter is a new parameter named max-lts to specify= maximum luma tile size to make sure the decoder doesn't receive a stream w= ith too large resolution and/or bitrate in one single tile. The max-lts par= ameter is a limiting parameter - as described for max-fps above. We propose max-lts to signal the maximum size allowed in one tile along the= lines of: ------ max-lts: The value of max-lts, Maximum Luma Tile Size, is an integer indicating the maximum tile size in units of luma samples. The max-lts parameter signals the maximum size of one tile that the decoder is able to decode. Informational note: The max-fps parameter is semantically different from max-ls, max-lps, max-cpb, max-dpb, and max-br in that max-lts is used to signal a constraint on the maximum tile size. The encoder MUST use a tile size equal to or less than this value. In cases where the max-lts parameter is absent the encoder is free to choose any tile size according to the highest signaled level and any signaled optional parameters. ------ Please consider these additions. More text needed to merge the new paramete= rs into the media subtype specification, offer/answer rules and so on - of = course. To be dealt with later. -- Tom On 11 June 2013 19:00, Wang, Ye-Kui > wrote: Dear All, We have just submitted versions 02 and 03 of draft-schierl-payload-rtp-h265= , for which the links are as follows: Version 02: URL: http://www.ietf.org/internet-drafts/draft-schierl-payload-= rtp-h265-02.txt Htmlized: http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-= 02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-r= tp-h265-02 Version 03: URL: http://www.ietf.org/internet-drafts/draft-schierl-payload-= rtp-h265-03.txt Htmlized: http://tools.ietf.org/html/draft-schierl-payload-rtp-h265-= 03 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-r= tp-h265-03 Version 02 includes huge changes compared to the earlier submitted version = 01. In a short summary, the authors have worked hard to try to make the des= ign complete, from both the payload structure and the signaling points of v= iew. Compared to version 02, version 03 only contains a correction of the e= mail address of an author. Due to that the industry is eager to deploy H.265/HEVC and other standards = bodies such as 3GPP rely on the payload format for support of H.265/HEVC in= RTP based video services, we need to progress this draft relatively quickl= y. Therefore, we would like to request quick reviews from interested partie= s and also request for the WG status of this draft. BR, YK (on behalf of the authors) _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com | http://www.tandberg.co= m ### | http://folk.uio.no/tomkri/ --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D6529nasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Tom for the answer= s and clarifications. It seems convincing to me that we should add max-tr and max-tc on top of what have bee= n agreed at the avtcore session in Berlin.

 <= /p>

I will include them in th= e next version unless people have issues with it – so please speak up= if you do have issues.=

 <= /p>

BR, YK<= /p>

 <= /p>

From:= Tom Kristensen [mai= lto:tomkrist@cisco.com]
Sent: Friday, August 09, 2013 4:52 AM
To: Wang, Ye-Kui
Cc: Tom Kristensen; payload@ietf.org
Subject: Re: [payload] Submission of new versions of H.265/HEVC payl= oad format

 

A late response after summer holiday and inbox flood= ing season; comments/answers inline below.

On 06/27/2013 07:28 PM, Wang, Ye-Kui wrote:

Hi Tom,=

 <= /p>

Thanks for the review and= the suggestions. I have some comments on the suggestions.

 <= /p>

On max-fps: The following= paragraph in draft-kristensen-payload-rtp-h241param-00 seems to be the mai= n reason for the introduction of max-fps. Just for a better understanding, could you please clarify why the receiver side would have a= preferred frame rate? Does that relate to rendering/display capability? If= that is the case, then discarding of the additional frames should be done = by the rendering module instead of the decoder, as conforming decoders should just output frames that are = indicated, by the bitstream, to be output.

 <= /p>

   If the encoder chooses to send at a higher fr= ame rate than preferred

   by the receiver side, the decoder will normal= ly discard the

   additional frames after decoding them.  = The transmission of the extra

   frames and the processing of frames to just d= iscard them are wasteful

   and the bandwidth and processing could be use= d more effectively.


Stephan provided convincing argumentation for this in the IETF-87 AVTCORE s= ession. And as we know both H.264 and H.265 allow very high/extreme framera= tes for a given level, when the resolution is small enough. The max-fps par= ameter is meant to set a limit for useful and preferred maximal framerate.

And yes, the decoder is one thing. Render/display capability another. The v= alue for max-fps might stem from display/render capability or as Stephan me= ntioned at IETF-87 - the use of video for content sharing with a typically = high resolution/low framerate stream.
 

Not relevant for H.265/HE= VC payload, but for H.264/AVC payload in RFC 6184, would introduction of su= ch a parameter cause any IOP issue between a legacy sender and a new receiver? I think that should be analyzed in draft-kristensen-pa= yload-rtp-h241param-00. Certainly, it would also be good to clarify the abo= ve question related to rendering/display capability in draft-kristensen-pay= load-rtp-h241param-00 too.


Thanks, note taken! I will update the upcoming version of draft-kristensen-= payload-rtp-h241param with the interop/backwards compatibility issues valid= for H.264 and the rendering/display vs. decoder distinction.


On max-lts: It makes sens= e to me, but we would need to specify a lower bound of the value, such that= it would at least not contradict with the min tile size implied by other parameters.


This parameter is no longer proposed, since the signalling need is taken ca= re of in the merged proposal for parallellization tools agreep upon at IETF= -87. The minimum tile size should be limited to the lower bound on the tile= size in H.265, text might be needed for the dec-parallel-cap.


On max-tr and max-tc: It = seems that they are saying that there are scenarios where you would need mo= re tiles than allowed by the indicated level. Could you please give an (practical) example that this is needed? I am asking this b= ecause in JCT-VC there had been a lot of discussions after which the level = limits of MaxTileRows and MaxTileCols were concluded.


The values of maxTileRows and maxTileColumns defined in HEVC were a comprom= ise, mainly between people who wanted to limited the maximum number of tile= s for their single-core decoder design and people who wanted a large number= of tiles for their multi-core encoder design. Moreover, when making maxTileRows/Cols in HEVC level-dependent (ra= ther than resolution-dependent) it was already anticipated that additional = flexibility could be achieved during call negotiation. (See document JCTVC-= J0235.)
 
There are at least three reasons for adding max-tr and max-tc as additional= optional parameters:
 
   1)  Typically video conferencing uses bit rates that are = significantly lower than the values specified in HEVC for a given level/res= olution. For example, it is expected that 1080p30 can use bit rates at 1 mb= ps or below, while HEVC specifies a maximum bitrate of 12 mbps for 1080p30 (level 4). To avoid designing CABAC decoding for un= necessarily high bit rates, the practical solution that has been used in th= e industry since H.264 days has been to signal support for a low level, and= then send optional parameters to indicate support for a higher resolution. For example, a 1080p30 capable d= ecoder could signal:
    -  max-recv-level-id =3D 2.1 (maxBR =3D 3000)
    -  max-ls =3D 1920x1080
    -  max-lps =3D 1920x0180x30
However, without being able to signal max-tc and max-tr, the encoder would = have to comply with the values of maxTileRows and maxTileColumns of level 2= .1 (maxTileRows =3D maxTileColums =3D 1).

   2)  Even if a decoder could signal the “true”= value of max-recv-level-id, there are encoders who would benefit from usin= g an even higher number of tiles. For example, for level 4 (1080p30), HEVC = specifies maxTileRows =3D maxTileColums =3D 5, limiting the total number of tiles to 25. On the other hand, there exist processing devices h= aving as many as 64 cores. Also, for sw encoder designs, it might be benefi= cial to have significantly more tiles than cores for load balancing purpose= s. A decoder that signals values of max-tr and max-tc larger than those indicated by the signaled level/res= olution would give the encoder more freedom to choose the appropriate balan= ce between number of tiles and level of parallelization.

   3)  Finally, for the sake of consistency, it seems reason= able support the same negotiation mechanisms for all parameters of HEVC tab= les A-1 and A-2, i.e. not only those corresponding to max-ls, max-lps, max-= cbp, max-dpb, and max-br.


Cheers,
-- Tom


 <= /p>

BR, YK<= /p>

 <= /p>

From: payload-bounces@ietf.org [<= a href=3D"mailto:payload-bounces@ietf.org">mailto:payload-bounces@ietf.org<= /a>] On Behalf Of Tom Kristensen
Sent: Thursday, June 27, 2013 6:34 AM
To: Wang, Ye-Kui
Cc: Geir Arne Sandbakken; payloa= d@ietf.org; Tom Kristensen
Subject: Re: [payload] Submission of new versions of H.265/HEVC payl= oad format

 

We have done a first review of the new version of th= is draft. Seems promising. However, we are missing a couple of things.=

 

First, we would like to include a max-fps parameter = in line with the proposed draft draft-kristensen-payload-rtp-h241param-00. = A similar parameter has been part of H.241 for while and will eventually be= valid for H.265 in H.323 land too. Note that this is a limiting parameter, different from the other max-* par= ameters (max-ls, max-lps, max-cpb, max-dpb and max-br).

 

We propose max-fps as something along the lines of:<= o:p>

   ------

   max-fps:  The value of max-fps is = an integer indicating the maximum

      frame rate in units of hundredt= hs of frames per second that can be

      efficiently received.  The= signaled highest level is conveyed in

      the value of the profile-level-= id parameter or the max-recv-level

      parameter.  The max-fps pa= rameter MAY be used to signal that the

      receiver has a constraint in th= at it is not capable of decoding

      video efficiently at the full f= rame rate that is implied by the

      signaled highest level and, if = present, one or more of the

      parameters max-ls, max-lps or m= ax-br.

 

      Notice that the value of max-fp= s is not necessarily the frame rate

      at which the maximum frame size= can be sent, it constitutes a

      constraint on maximum frame rat= e for all resolutions.

 

         Informational note= : The max-fps parameter is semantically

         different from max= -ls, max-lps, max-cpb, max-dpb,

         and max-br in that= max-fps is used to signal a constraint,

         lowering the maxim= um frame rate from what is implied by the

         signaled MaxLumaSR= and MaxLumaPS.

 

      The encoder MUST use a frame ra= te equal to or less than this

      value.  In cases where the= max-fps parameter is absent the

      encoder is free to choose any f= rame rate according

      to the highest signaled level a= nd any signaled optional

      parameters.

   ------

 

Second, we are missing an ability to signal support = for tiles (number of tiles used/to expect) and maximum tile size. The abili= ty to signal support for a number of tiles higher than what is implied for = the signalled level (as listed in Table A-1 in the HEVC specification. These two parameters have the same se= mantics as the existing max-* parameters (max-ls, max-lps, max-cpb, max-dpb= and max-br).

 

We propose max-tr (or max-tile-rows) and the equival= ent description for max-tc (or max-tile-cols) along the lines of:

   ------

   (Will be introduced toghether with max-= ls, max-lps, max-cpb, max-dpb, max-br, as parameters that "MAY be used= to signal the capabilities of a receiver implementation.")=

capabilities...:

 

   max-tr: 

      The value of max-tr is an integ= er indication the maximum number

      of tile rows. The max-tr parame= ter signals that the receiver is

      capable of decoding video with = a larger number of tile rows than

      is required by the signaled hig= hest level.

 

      When max-tr is signaled, the re= ceiver must be able to decode NAL

      unit streams that conform to th= e signaled highest level, with the

      exception that the MaxTileRows = value in Table A-1 of [HEVC] for

      the signaled highest level is r= eplaced with the value of max-tr.

      The value of max-tr MUST be gre= ater than or equal to the value of

      MaxTileRows given in Table A-1 = of [HEVC] for the highest

      level. Senders MAY use this kno= wledge to send pictures utilizing

      a larger number of tile rows th= an is indicated in the signaled

      highest level.

 

   max-tc:

      (As for max-tr with s/max-tr/ma= x-tc/

              &nb= sp;           s/MaxTileRows/MaxTileCols/

              &nb= sp;           s/rows/colums)

   ------

 

The last tile related parameter is a new parameter n= amed max-lts to specify maximum luma tile size to make sure the decoder doe= sn't receive a stream with too large resolution and/or bitrate in one singl= e tile. The max-lts parameter is a limiting parameter - as described for max-fps above. 

 

We propose max-lts to signal the maximum size allowe= d in one tile along the lines of:

   ------

   max-lts:

      The value of max-lts, Maximum L= uma Tile Size, is an integer

      indicating the maximum tile siz= e in units of luma samples. The

      max-lts parameter signals the m= aximum size of one tile that the

      decoder is able to decode.=

 

         Informational note= : The max-fps parameter is semantically

         different from max= -ls, max-lps, max-cpb, max-dpb,

         and max-br in that= max-lts is used to signal a constraint

         on the maximum til= e size.

 

      The encoder MUST use a tile siz= e equal to or less than this

      value.  In cases where the= max-lts parameter is absent the

      encoder is free to choose any t= ile size according

      to the highest signaled level a= nd any signaled optional

      parameters.

   ------

 

Please consider these additions. More text needed to= merge the new parameters into the media subtype specification, offer/answe= r rules and so on - of course. To be dealt with later.

 

-- Tom

 

On 11 June 2013 19:00, Wang, Ye-Kui <yekuiw@qti.qualcomm.com> wrote:

Dear All,

We have just submitted versions 02 and 03 of draft-schierl-payload-rtp-h265= , for which the links are as follows:

Version 02:
URL:             http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-h265-02.txt
Htmlized:        http://tools.ietf.org/= html/draft-schierl-payload-rtp-h265-02
Diff:            http= ://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-02

Version 03:
URL:             http://www.ietf.org/internet-drafts/draft-schierl-payload-rtp-h265-03.txt
Htmlized:        http://tools.ietf.org/= html/draft-schierl-payload-rtp-h265-03
Diff:            http= ://www.ietf.org/rfcdiff?url2=3Ddraft-schierl-payload-rtp-h265-03

Version 02 includes huge changes compared to the earlier submitted version = 01. In a short summary, the authors have worked hard to try to make the des= ign complete, from both the payload structure and the signaling points of v= iew. Compared to version 02, version 03 only contains a correction of the email address of an author.

Due to that the industry is eager to deploy H.265/HEVC and other standards = bodies such as 3GPP rely on the payload format for support of H.265/HEVC in= RTP based video services, we need to progress this draft relatively quickl= y. Therefore, we would like to request quick reviews from interested parties and also request for the WG status o= f this draft.

BR, YK (on behalf of the authors)
_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload



 

--
# Cisco                   &nbs= p;     |  http://www.cisco.com/telepresence/
## tomkrist@cisco.c= om  |  = http://www.tandberg.com
###                     &= nbsp;         |  http://folk.uio.no/tomkri/

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A83384D6529nasanexd02fnaqu_-- From prvs=926d81219=HeinzPeter.Reykers@wdr.de Fri Aug 9 11:18:54 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2B121F9C38; Fri, 9 Aug 2013 11:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4aRVtfbu5gF; Fri, 9 Aug 2013 11:18:40 -0700 (PDT) Received: from smtp39.wdr.de (smtp39.wdr.de [149.219.195.39]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBBE21F9406; Fri, 9 Aug 2013 11:12:24 -0700 (PDT) Message-Id: <52054D240200005600077E10@wdr.de> Date: Fri, 09 Aug 2013 20:12:20 +0200 From: "Heinz Peter Reykers" To: , References: <031C6AD0F5FEAB449C77DF4E9D047A5C40495B@mayah-sbs.mayah.com> In-Reply-To: <031C6AD0F5FEAB449C77DF4E9D047A5C40495B@mayah-sbs.mayah.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part1A294014.2__=" Cc: payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-aptx-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 18:18:54 -0000 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part1A294014.2__= Content-Type: multipart/alternative; boundary="=__Part1A294014.3__=" --=__Part1A294014.3__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello all,=20 the implementation of the algorithm enhanced apt-X for low delay transmissi= ons in radio is a very important task for codec manufacturers. In german = public radio and television landscape a couple of different units already = exists, delivered from different codec manufacturers. When they are used = for contribution of audio content it is a high priority aim to guaranty = the interoperability of these codecs from different manufacturers to each = other. This can only be made properly by using the same rfc within the = prerequisites and instructions how to implement this algorithm and the = belonging signaling. The european broadcasting union EBU created a = technical document, putting together all the different rfc's for the = mandatory, recommend and optional functions each codec for audio-over-IP = use must/should have. =20 Therefore we urgently need this new rfc as an accepted and distributed = document, because interoperability of different codecs is very important = for the german broadcasters.=20 Kind regards=20 Heinz Peter Reykers --=__Part1A294014.3__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML =0A =0A=0A =0A =0A

=0A Hello = all,

=0A
=0A

=0A the = implementation of the algorithm enhanced apt-X for low delay transmissions = in radio is a very important task for codec manufacturers. In german = public radio and television landscape a couple of different units already = exists, delivered from different codec manufacturers. When they are = used for contribution of audio content it is a high priority aim to = guaranty the interoperability of these codecs from different manufacturers = to each other. This can only be made properly by using the same rfc within = the prerequisites and instructions how to implement this algorithm and the = belonging signaling. The european broadcasting union EBU created a = technical document, putting together all the different rfc's for = the mandatory, recommend and optional functions each codec for = audio-over-IP use must/should have.

=0A
=0A

=0A Therefore we urgently need this new rfc as an accepted = and distributed document, because interoperability of different codecs = is very important for the german broadcasters.

=0A
=
=0A

=0A Kind regards

=0A
= =0A

=0A Heinz Peter Reykers

=0A = =0A=0A --=__Part1A294014.3__=-- --=__Part1A294014.2__= Content-Type: application/octet-stream; name="Reykers, Heinz Peter.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Reykers, Heinz Peter.vcf" QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpQUk9ESUQ6LS8vTm92ZWxsIEluYy8vR3JvdXB3aXNl IDguMC4yIA0KWC1HV1RZUEU6VVNFUg0KRk46UmV5a2VycywgSGVpbnogUGV0ZXINCk46UmV5a2Vy cztIZWlueiBQZXRlcg0KRU1BSUw7SU5URVJORVQ7UFJFRjpIZWluelBldGVyLlJleWtlcnNAV0RS LkRFDQpVSUQ6QTBGRUFDMjAtMTI2RC0wMDAwLTg3NUItN0UwMDk1REI0Qzg0DQpURUw7Vk9JQ0U7 UFJFRjorNDkgKDIyMSkgMjIwLTQxODMNClRFTDtWT0lDRTtXT1JLOis0OSAoMjIxKSAyMjAtNDE4 Mw0KVEVMO0ZBWDtQUkVGOis0OSAoMjIxKSAyMjAtNzc0MTgzDQpUSVRMRTpEaXBsLi1JbmcuDQpS RVY6MjAxMzA4MDZUMjMwNjQzWg0KRU5EOlZDQVJEDQoNCg== --=__Part1A294014.2__=-- From prvs=926d81219=HeinzPeter.Reykers@wdr.de Fri Aug 9 11:33:44 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BF321F9CE2 for ; Fri, 9 Aug 2013 11:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16uzkO6dyjKI for ; Fri, 9 Aug 2013 11:33:39 -0700 (PDT) Received: from smtp39.wdr.de (smtp39.wdr.de [149.219.195.39]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4B411E80F5 for ; Fri, 9 Aug 2013 11:27:42 -0700 (PDT) Message-Id: <520550BB0200005600077E18@wdr.de> Date: Fri, 09 Aug 2013 20:27:39 +0200 From: "Heinz Peter Reykers" To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part80B3DA8B.0__=" Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-aptx-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 18:33:44 -0000 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part80B3DA8B.0__= Content-Type: multipart/alternative; boundary="=__Part80B3DA8B.1__=" --=__Part80B3DA8B.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello all,=20 the implementation of the algorithm enhanced apt-X for low delay transmissi= ons in radio is a very important task for codec manufacturers. In german = public radio and television landscape a couple of different units already = exists, delivered from different codec manufacturers. When they are used = for contribution of audio content it is a high priority aim to guaranty = the interoperability of these codecs from different manufacturers to each = other. This can only be made properly by using the same rfc within the = prerequisites and instructions how to implement this algorithm and the = belonging signaling. The european broadcasting union EBU created a = technical document, putting together all the different rfc's for the = mandatory, recommend and optional functions each codec for audio-over-IP = use must/should have. =20 Therefore we urgently need this new rfc as an accepted and distributed = document, because interoperability of different codecs is very important = for the german broadcasters.=20 Kind regards=20 Heinz Peter Reykers --=__Part80B3DA8B.1__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML =0A =0A=0A =0A =0A

=0A Hello all,=

=0A

=0A =
=0A

=0A

=0A the implementation of = the algorithm enhanced apt-X for low delay transmissions in radio is a = very important task for codec manufacturers. In german public radio and = television landscape a couple of different units already exists, = delivered from different codec manufacturers. When they are used for = contribution of audio content it is a high priority aim to guaranty the = interoperability of these codecs from different manufacturers to each = other. This can only be made properly by using the same rfc within the = prerequisites and instructions how to implement this algorithm and the = belonging signaling. The european broadcasting union EBU created a = technical document, putting together all the different rfc's for = the mandatory, recommend and optional functions each codec for = audio-over-IP use must/should have.

=0A

=0A
=0A

=0A

=0A Therefore we urgently need this new rfc as an accepted = and distributed document, because interoperability of different codecs = is very important for the german broadcasters.

=0A

=0A
=0A
=0A =

=0A

=0A = Kind regards

=0A =

=0A
=0A =

=0A

=0A Heinz Peter Reykers=0A

=0A = =0A=0A --=__Part80B3DA8B.1__=-- --=__Part80B3DA8B.0__= Content-Type: application/octet-stream; name="Reykers, Heinz Peter.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Reykers, Heinz Peter.vcf" QkVHSU46VkNBUkQNClZFUlNJT046Mi4xDQpQUk9ESUQ6LS8vTm92ZWxsIEluYy8vR3JvdXB3aXNl IDguMC4yIA0KWC1HV1RZUEU6VVNFUg0KRk46UmV5a2VycywgSGVpbnogUGV0ZXINCk46UmV5a2Vy cztIZWlueiBQZXRlcg0KRU1BSUw7SU5URVJORVQ7UFJFRjpIZWluelBldGVyLlJleWtlcnNAV0RS LkRFDQpVSUQ6QTBGRUFDMjAtMTI2RC0wMDAwLTg3NUItN0UwMDk1REI0Qzg0DQpURUw7Vk9JQ0U7 UFJFRjorNDkgKDIyMSkgMjIwLTQxODMNClRFTDtWT0lDRTtXT1JLOis0OSAoMjIxKSAyMjAtNDE4 Mw0KVEVMO0ZBWDtQUkVGOis0OSAoMjIxKSAyMjAtNzc0MTgzDQpUSVRMRTpEaXBsLi1JbmcuDQpS RVY6MjAxMzA4MDZUMjMwNjQzWg0KRU5EOlZDQVJEDQoNCg== --=__Part80B3DA8B.0__=-- From finlayson@live555.com Fri Aug 9 13:17:52 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1691921E8094; Fri, 9 Aug 2013 13:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXFpHIaosvNC; Fri, 9 Aug 2013 13:17:47 -0700 (PDT) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id E2EAF21F9C7A; Fri, 9 Aug 2013 13:11:04 -0700 (PDT) Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.4/8.14.4) with ESMTP id r79KB11Q003736; Fri, 9 Aug 2013 13:11:02 -0700 (PDT) (envelope-from finlayson@live555.com) From: Ross Finlayson Content-Type: multipart/alternative; boundary="Apple-Mail=_0F3358AC-C016-4465-9173-887790A380C5" Message-Id: <69F25DB2-6926-4ACA-935D-90376A2A7BFA@live555.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Fri, 9 Aug 2013 13:11:01 -0700 References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> To: "avt@ietf.org" , "payload@ietf.org" In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> X-Mailer: Apple Mail (2.1508) Subject: Re: [payload] [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 20:17:52 -0000 --Apple-Mail=_0F3358AC-C016-4465-9173-887790A380C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > Though I don=92t think it is [] really necessary, I think we can = either simply add a note after the semantics of the M bit saying that = the first slice header bit indicates that the slice is the first slice = of a picture, or mention this as part of the introduction to HEVC. Because the new text is intended to help implementers figure out when to = set the 'M' bit, it should be added just after the existing 'M' bit = text. (But why not just use the paragraph that I suggested?) > The addition is not really necessary because the first slice header = bit is more expected to be used by video decoders for detection of the = start of a new picture without relying on timing (because they might not = be available to the decoder etc), while for the receivers at RTP level, = they can always use the M bit and/or the RTP timestamp. Yes, but that's irrelevant here, because we're talking about how to = clarify the text for implementers of RTP *senders*, not RTP receivers. = (If the current proposed RTP payload format specification were to be = used only by the implementers of H.265/RTP receivers, then I would have = no problem with it. But that's not the case.)=20 > it is so easy to follow the semantics, and I don=92t see a reason why = implementers would not follow what is being specified. The reason is (as I've explained before) that for many RTP sender = implementers who aren't very familiar with the H.265 codec = specification, it will not be immediately obvious whether a NAL unit = ends an access unit. That's why I'm proposing adding a (very small) bit = of extra text to clarify this. I think the core of the disagreement here is that there are two = different views on what a RTP payload format specification should be: One view is that a RTP payload format specification should be the = shortest, most concise possible document that describes how to = send/receive RTP packets for a particular codec, for someone how is = already very familiar with the codec specification. =46rom the = perspective of a codec designer, this point of view makes perfect sense: = The codec specification is the 'core document'; the RTP payload format = specification is logically just an 'appendix'. Therefore, from this = point of view, there seems little sense in adding extra, redundant text = to the RTP payload format document, because it's information that is = already available in the codec specification. However, there are two problems with this point of view. The first = problem is that it makes the specification 'fragile'. Someone who = happens to misread the codec specification is more likely to implement = the RTP payload format incorrectly. The second problem with this point of view is a practical one. Many (if = not most) people who implement RTP payload formats are not codec = experts. They just want to know how to transmit data that they've = received from an encoder, or (on the receiving end) want to know how to = feed data that they've received from a RTP stream into a decoder. It's = not reasonable to expect them to have intimate knowledge of the codec = specification (especially since they may want to implement the RTP = payload formats for several codecs - not just one). Nor will they = always have time to read through the codec specification in detail to = find information that could just as easily have been made available in = the RTP payload format specification. An alternative view of what a RTP payload format should be (and this is = the view that is, I think, is shared by most members of the AVT(CORE) = working group) is that a RTP payload format specification should have = sufficient detail to allow someone to implement the payload format = (sending and/or receiving), even if they have only a limited knowledge = of the codec specification. Even if this means adding text to the RTP = payload format specification that might - from the point of view of the = codec designer - seem somewhat redundant. I hope this helps you understand why adding just a small bit of = redundant text (such as the paragraph I suggested) to the RTP payload = format specification (after the existing 'M' bit text) will help = implementers, and makes it more likely that they will implement the RTP = payload format correctly. Ross Finlayson Live Networks, Inc. http://www.live555.com/ --Apple-Mail=_0F3358AC-C016-4465-9173-887790A380C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Though I don=92t think = it is [] really necessary, I think we can either simply add a note after = the semantics of the M bit saying that the first slice header bit = indicates that the slice is the first slice of a picture, or mention = this as part of the introduction to = HEVC.

Because the = new text is intended to help implementers figure out when to set the 'M' = bit, it should be added just after the existing 'M' bit text.  (But = why not just use the paragraph that I = suggested?)


The addition is not = really necessary because the first slice header bit is more expected to = be used by video decoders for detection of the start of a new picture = without relying on timing (because they might not be available to the = decoder etc), while for the receivers at RTP level, they can always use = the M bit and/or the RTP = timestamp.

Yes, but = that's irrelevant here, because we're talking about how to clarify the = text for implementers of RTP *senders*, not RTP receivers.  (If the = current proposed RTP payload format specification were to be used only = by the implementers of H.265/RTP receivers, then I would have no problem = with it.  But that's not the = case.) 


it is so easy to = follow the semantics, and I don=92t see a reason why implementers would = not follow what is being = specified.

The = reason is (as I've explained before) that for many RTP sender = implementers who aren't very familiar with the H.265 codec = specification, it will not be immediately obvious whether a NAL unit = ends an access unit.  That's why I'm proposing adding a (very = small) bit of extra text to clarify this.

I = think the core of the disagreement here is that there are two different = views on what a RTP payload format specification should = be:

One view is that a RTP payload format = specification should be the shortest, most concise possible document = that describes how to send/receive RTP packets for a particular codec, = for someone how is already very familiar with the codec specification. =  =46rom the perspective of a codec designer, this point of view = makes perfect sense: The codec specification is the 'core document'; the = RTP payload format specification is logically just an 'appendix'. =  Therefore, from this point of view, there seems little sense in = adding extra, redundant text to the RTP payload format document, because = it's information that is already available in the codec = specification.

However, there are two problems = with this point of view.  The first problem is that it makes the = specification 'fragile'.  Someone who happens to misread the codec = specification is more likely to implement the RTP payload format = incorrectly.

The second problem with this point = of view is a practical one.  Many (if not most) people who = implement RTP payload formats are not codec experts.  They = just want to know how to transmit data that they've received from = an encoder, or (on the receiving end) want to know how to feed data that = they've received from a RTP stream into a decoder.  It's not = reasonable to expect them to have intimate knowledge of the codec = specification (especially since they may want to implement the RTP = payload formats for several codecs - not just one).  Nor will they = always have time to read through the codec specification in detail to = find information that could just as easily have been made available in = the RTP payload format specification.

An = alternative view of what a RTP payload format should be (and this is the = view that is, I think, is shared by most members of the AVT(CORE) = working group) is that a RTP payload format specification should have = sufficient detail to allow someone to implement the payload format = (sending and/or receiving), even if they have only a limited knowledge = of the codec specification.  Even if this means adding text to the = RTP payload format specification that might - from the point of view of = the codec designer - seem somewhat redundant.

I = hope this helps you understand why adding just a small bit of redundant = text (such as the paragraph I suggested) to the RTP payload format = specification (after the existing 'M' bit text) will help implementers, = and makes it more likely that they will implement the RTP payload format = correctly.


Ross = Finlayson
Live Networks, Inc.
http://www.live555.com/=

= --Apple-Mail=_0F3358AC-C016-4465-9173-887790A380C5-- From yekuiw@qti.qualcomm.com Fri Aug 9 15:57:29 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366F921F9D95; Fri, 9 Aug 2013 15:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3dcci-uWxSS; Fri, 9 Aug 2013 15:57:15 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 379E821F9E62; Fri, 9 Aug 2013 15:49:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1376088577; x=1407624577; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=frnj6wymdAI+6Byk9Pgll+5O5lk6+2+IKWIM8NQNT8c=; b=KtklqgjW5XzTgsP1hUR1DzkAS2NGoWejPZMMr4qahLD2LEvtHIIoH2ji +Atk2sxaS5T5xVVBkb+9rD1v2mlReVwXhKGo0MobqNDXnccGj31KOKjQ5 zL5cv/Z4sZv1N6URPFg7F2cvtDey6BI2qGVMsND7MXQHf5sSq/qezOyXP U=; X-IronPort-AV: E=Sophos;i="4.89,849,1367996400"; d="scan'208,217";a="49306333" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 09 Aug 2013 15:49:36 -0700 X-IronPort-AV: E=Sophos;i="4.89,848,1367996400"; d="scan'208,217";a="582022121" Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 09 Aug 2013 15:49:35 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.21]) by nasanexhc10.na.qualcomm.com ([172.30.48.3]) with mapi id 14.03.0146.002; Fri, 9 Aug 2013 15:49:35 -0700 From: "Wang, Ye-Kui" To: Ross Finlayson , "avt@ietf.org" , "payload@ietf.org" Thread-Topic: [payload] [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit Thread-Index: AQHOlK64MyApD0+0bEyc75pQI3FkapmM0zAQgADx7oD//7IbsA== Date: Fri, 9 Aug 2013 22:49:34 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83384D690F@nasanexd02f.na.qualcomm.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> <69F25DB2-6926-4ACA-935D-90376A2A7BFA@live555.com> In-Reply-To: <69F25DB2-6926-4ACA-935D-90376A2A7BFA@live555.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83384D690Fnasanexd02fnaqu_" MIME-Version: 1.0 Subject: Re: [payload] [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 22:57:29 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D690Fnasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Now I understand your intention better - did not see that the note was inte= nded for sender implementers. For this purpose, indeed (as Mo pointed out earlier?) that first of all, th= e sender needs make sure the RTP timestamp for each RTP packet is correct. = As long as RTP timestamp is correct, it is also easy to know when the M bit= should be set. Or are you saying that there is no problem with RTP timesta= mp setting but there is a problem for the M bit setting? If yes, please cla= rify why. I have no problem to putting some information in the line as you suggested,= if the suggested text is good. However, the suggested wording below still = has a few problems (or shortcomings). ---------- Unfortunately the contents of a NAL unit, alone, does not tell a RTP sender= implementation whether or not the NAL unit ends an access unit. Instead, = the implementation can obtain this information separately, from the encoder= . If, however, this information is not available directly from the encoder= (e.g., because the implementation is sending data that consists solely of = a sequence of pre-encoded NAL units), then it must instead inspect subseque= nt NAL units, to determine whether or not the NAL unit ends an access unit.= The following rule can be used: A NAL unit ends an access unit if it is a VCL NAL unit, and the next-oc= curring VCL NAL unit has the high-order bit of the first byte after its NAL= U header equal to 1. ---------- The problems (or shortcomings) are: - I don't think it is good to say that the fact that a NAL unit it= self does not indicate whether it is the last one of an AU is unfortunate. - Saying that the information can be obtained from the encoder is = vague to me. I guess you meant the bitstream instead, as the encoder may be= absent e.g. when dealing pre-encoded video. - Saying that inspecting subsequent NAL units is a must is not rea= lly correct, as I believe timing information can be used too - as mentioned= above, you got to make sure the RTP timestamp value is correctly set anywa= y. - Last but not least, an AU may also end with a non-VCL NAL unit, = e.g. a filler data NAL unit, an end of sequence NAL unit, an end of bitstre= am NAL unit, a suffix SEI NAL unit, etc. BR, YK From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf = Of Ross Finlayson Sent: Friday, August 09, 2013 1:11 PM To: avt@ietf.org; payload@ietf.org Subject: Re: [payload] [AVTCORE] Clarifying the H.265 RTP payload format sp= ecification's text on when to set the RTP "M" bit Though I don't think it is [] really necessary, I think we can either simpl= y add a note after the semantics of the M bit saying that the first slice h= eader bit indicates that the slice is the first slice of a picture, or ment= ion this as part of the introduction to HEVC. Because the new text is intended to help implementers figure out when to se= t the 'M' bit, it should be added just after the existing 'M' bit text. (B= ut why not just use the paragraph that I suggested?) The addition is not really necessary because the first slice header bit is = more expected to be used by video decoders for detection of the start of a = new picture without relying on timing (because they might not be available = to the decoder etc), while for the receivers at RTP level, they can always = use the M bit and/or the RTP timestamp. Yes, but that's irrelevant here, because we're talking about how to clarify= the text for implementers of RTP *senders*, not RTP receivers. (If the cu= rrent proposed RTP payload format specification were to be used only by the= implementers of H.265/RTP receivers, then I would have no problem with it.= But that's not the case.) it is so easy to follow the semantics, and I don't see a reason why impleme= nters would not follow what is being specified. The reason is (as I've explained before) that for many RTP sender implement= ers who aren't very familiar with the H.265 codec specification, it will no= t be immediately obvious whether a NAL unit ends an access unit. That's wh= y I'm proposing adding a (very small) bit of extra text to clarify this. I think the core of the disagreement here is that there are two different v= iews on what a RTP payload format specification should be: One view is that a RTP payload format specification should be the shortest,= most concise possible document that describes how to send/receive RTP pack= ets for a particular codec, for someone how is already very familiar with t= he codec specification. From the perspective of a codec designer, this poi= nt of view makes perfect sense: The codec specification is the 'core docume= nt'; the RTP payload format specification is logically just an 'appendix'. = Therefore, from this point of view, there seems little sense in adding ext= ra, redundant text to the RTP payload format document, because it's informa= tion that is already available in the codec specification. However, there are two problems with this point of view. The first problem= is that it makes the specification 'fragile'. Someone who happens to misr= ead the codec specification is more likely to implement the RTP payload for= mat incorrectly. The second problem with this point of view is a practical one. Many (if no= t most) people who implement RTP payload formats are not codec experts. Th= ey just want to know how to transmit data that they've received from an enc= oder, or (on the receiving end) want to know how to feed data that they've = received from a RTP stream into a decoder. It's not reasonable to expect t= hem to have intimate knowledge of the codec specification (especially since= they may want to implement the RTP payload formats for several codecs - no= t just one). Nor will they always have time to read through the codec spec= ification in detail to find information that could just as easily have been= made available in the RTP payload format specification. An alternative view of what a RTP payload format should be (and this is the= view that is, I think, is shared by most members of the AVT(CORE) working = group) is that a RTP payload format specification should have sufficient de= tail to allow someone to implement the payload format (sending and/or recei= ving), even if they have only a limited knowledge of the codec specificatio= n. Even if this means adding text to the RTP payload format specification = that might - from the point of view of the codec designer - seem somewhat r= edundant. I hope this helps you understand why adding just a small bit of redundant t= ext (such as the paragraph I suggested) to the RTP payload format specifica= tion (after the existing 'M' bit text) will help implementers, and makes it= more likely that they will implement the RTP payload format correctly. Ross Finlayson Live Networks, Inc. http://www.live555.com/ --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D690Fnasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Now I understand your int= ention better – did not see that the note was intended for sender imp= lementers. 

 <= /p>

For this purpose, indeed = (as Mo pointed out earlier?) that first of all, the sender needs make sure = the RTP timestamp for each RTP packet is correct. As long as RTP timestamp is correct, it is also easy to know when the M bit should= be set. Or are you saying that there is no problem with RTP timestamp sett= ing but there is a problem for the M bit setting? If yes, please clarify wh= y.

 <= /p>

I have no problem to putt= ing some information in the line as you suggested, if the suggested text is= good. However, the suggested wording below still has a few problems (or shortcomings).

 <= /p>

----------

Unfortunately the contents of a NAL unit, alone, doe= s not tell a RTP sender implementation whether or not the NAL unit ends an = access unit.  Instead, the implementation can obtain this information = separately, from the encoder.  If, however, this information is not available directly from the encoder (e.g= ., because the implementation is sending data that consists solely of a seq= uence of pre-encoded NAL units), then it must instead inspect subsequent NA= L units, to determine whether or not the NAL unit ends an access unit.  The following rule can be used:=

    A NAL unit ends an access unit if it i= s a VCL NAL unit, and the next-occurring VCL NAL unit has the high-ord= er bit of the first byte after its NALU header equal to 1.

----------

 <= /p>

The problems (or shortcom= ings) are:

- =          I don’t thi= nk it is good to say that the fact that a NAL unit itself does not indicate= whether it is the last one of an AU is unfortunate.

- =          Saying that the i= nformation can be obtained from the encoder is vague to me. I guess you mea= nt the bitstream instead, as the encoder may be absent e.g. when dealing pre-encoded video.

- =          Saying that inspe= cting subsequent NAL units is a must is not really correct, as I believe ti= ming information can be used too – as mentioned above, you got to make sure the RTP timestamp value is correctly set anyway.=

- =          Last but not leas= t, an AU may also end with a non-VCL NAL unit, e.g. a filler data NAL unit,= an end of sequence NAL unit, an end of bitstream NAL unit, a suffix SEI NAL unit, etc.

 <= /p>

BR, YK<= /p>

 <= /p>

From: payload-bounces@ietf.org [mailto:payload-bounces@ietf= .org] On Behalf Of Ross Finlayson
Sent: Friday, August 09, 2013 1:11 PM
To: avt@ietf.org; payload@ietf.org
Subject: Re: [payload] [AVTCORE] Clarifying the H.265 RTP payload fo= rmat specification's text on when to set the RTP "M" bit

 

Though I don’t thin= k it is [] really necessary, I think we can either simply add a note after = the semantics of the M bit saying that the first slice header bit indicates that the slice is the first slice of a picture, or mention t= his as part of the introduction to HEVC.

 

Because the new text is intended to help implementer= s figure out when to set the 'M' bit, it should be added just after the exi= sting 'M' bit text.  (But why not just use the paragraph that I sugges= ted?)

 



The addition is not reall= y necessary because the first slice header bit is more expected to be used = by video decoders for detection of the start of a new picture without relying on timing (because they might not be available to the deco= der etc), while for the receivers at RTP level, they can always use the M b= it and/or the RTP timestamp.

 

Yes, but that's irrelevant here, because we're talki= ng about how to clarify the text for implementers of RTP *senders*, not RTP= receivers.  (If the current proposed RTP payload format specification= were to be used only by the implementers of H.265/RTP receivers, then I would have no problem with it.  But th= at's not the case.) 

 

 

it is so easy to follow t= he semantics, and I don’t see a reason why implementers would not fol= low what is being specified.

 

The reason is (as I've explained before) that for ma= ny RTP sender implementers who aren't very familiar with the H.265 codec sp= ecification, it will not be immediately obvious whether a NAL unit ends an = access unit.  That's why I'm proposing adding a (very small) bit of extra text to clarify this.

 

I think the core of the disagreement here is that th= ere are two different views on what a RTP payload format specification shou= ld be:

 

One view is that a RTP payload format specification = should be the shortest, most concise possible document that describes how t= o send/receive RTP packets for a particular codec, for someone how is alrea= dy very familiar with the codec specification.  From the perspective of a codec designer, this point of view makes p= erfect sense: The codec specification is the 'core document'; the RTP paylo= ad format specification is logically just an 'appendix'.  Therefore, f= rom this point of view, there seems little sense in adding extra, redundant text to the RTP payload format document, = because it's information that is already available in the codec specificati= on.

 

However, there are two problems with this point of v= iew.  The first problem is that it makes the specification 'fragile'. =  Someone who happens to misread the codec specification is more likely= to implement the RTP payload format incorrectly.

 

The second problem with this point of view is a prac= tical one.  Many (if not most) people who implement RTP payload format= s are not codec experts.  They just want to know how to transmit = data that they've received from an encoder, or (on the receiving end) want to know how to feed data that they've received fro= m a RTP stream into a decoder.  It's not reasonable to expect them to = have intimate knowledge of the codec specification (especially since they m= ay want to implement the RTP payload formats for several codecs - not just one).  Nor will they always hav= e time to read through the codec specification in detail to find informatio= n that could just as easily have been made available in the RTP payload for= mat specification.

 

An alternative view of what a RTP payload format sho= uld be (and this is the view that is, I think, is shared by most members of= the AVT(CORE) working group) is that a RTP payload format specification sh= ould have sufficient detail to allow someone to implement the payload format (sending and/or receiving), even i= f they have only a limited knowledge of the codec specification.  Even= if this means adding text to the RTP payload format specification that mig= ht - from the point of view of the codec designer - seem somewhat redundant.

 

I hope this helps you understand why adding just a s= mall bit of redundant text (such as the paragraph I suggested) to the RTP p= ayload format specification (after the existing 'M' bit text) will help imp= lementers, and makes it more likely that they will implement the RTP payload format correctly.

 

 

Ross Finlayson
Live Networks, Inc.
http:/= /www.live555.com/

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A83384D690Fnasanexd02fnaqu_-- From finlayson@live555.com Fri Aug 9 17:54:18 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E184111E81A8; Fri, 9 Aug 2013 17:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cy+Lq+D9p5x; Fri, 9 Aug 2013 17:54:09 -0700 (PDT) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id 8839E21F9BFF; Fri, 9 Aug 2013 17:47:54 -0700 (PDT) Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.4/8.14.4) with ESMTP id r7A0lpd0092379; Fri, 9 Aug 2013 17:47:52 -0700 (PDT) (envelope-from finlayson@live555.com) From: Ross Finlayson Content-Type: multipart/alternative; boundary="Apple-Mail=_D679A071-4D6C-4368-9856-7FA361D3ABA3" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Fri, 9 Aug 2013 17:47:50 -0700 References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> <69F25DB2-6926-4ACA-935D-90376A2A7BFA@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D690F@nasanexd02f.na.qualcomm.com> To: "avt@ietf.org" , "payload@ietf.org" In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83384D690F@nasanexd02f.na.qualcomm.com> X-Mailer: Apple Mail (2.1508) Subject: Re: [payload] [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 00:54:18 -0000 --Apple-Mail=_D679A071-4D6C-4368-9856-7FA361D3ABA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > Now I understand your intention better =96 did not see that the note = was intended for sender implementers.=20 OK, thanks. > For this purpose, indeed (as Mo pointed out earlier?) that first of = all, the sender needs make sure the RTP timestamp for each RTP packet is = correct. As long as RTP timestamp is correct, it is also easy to know = when the M bit should be set. Or are you saying that there is no problem = with RTP timestamp setting but there is a problem for the M bit setting? = If yes, please clarify why. Figuring out the RTP timestamp isn't (nearly as much of) a problem, = because this can be done by knowing the stream's frame rate. But in = this email thread, I'm focusing only on the RTP 'M' bit, because for it = (unlike the timestamp) there's less of an incentive for a sender = implementation to 'get it right'. I'm worried that if the RTP payload = format specification doesn't make it crystal clear when a NAL unit ends = an 'access unit', then an implementer might be tempted to just not = bother setting the bit at all. I don't want to see that happen. Hence = this email thread. > I have no problem to putting some information in the line as you = suggested, if the suggested text is good. However, the suggested wording = below still has a few problems (or shortcomings). > =20 > ---------- > Unfortunately the contents of a NAL unit, alone, does not tell a RTP = sender implementation whether or not the NAL unit ends an access unit. = Instead, the implementation can obtain this information separately, from = the encoder. If, however, this information is not available directly = from the encoder (e.g., because the implementation is sending data that = consists solely of a sequence of pre-encoded NAL units), then it must = instead inspect subsequent NAL units, to determine whether or not the = NAL unit ends an access unit. The following rule can be used: > A NAL unit ends an access unit if it is a VCL NAL unit, and the = next-occurring VCL NAL unit has the high-order bit of the first byte = after its NALU header equal to 1. > ---------- > =20 > The problems (or shortcomings) are: > - I don=92t think it is good to say that the fact that a NAL = unit itself does not indicate whether it is the last one of an AU is = unfortunate. Why not? It *is* "unfortunate". I'm not intending to 'insult' H.265 = here :-) > - Saying that the information can be obtained from the = encoder is vague to me. I guess you meant the bitstream instead, as the = encoder may be absent e.g. when dealing pre-encoded video. I think you may have been confused by my use of the word "can" in the = 2nd sentence of my proposed paragraph. Here is a rewording of the 2nd = (& 3rd) sentences; I hope this will make things clearer: "Instead, the implementation may be able to obtain this = information separately, from the encoder. If, however, the = implementation cannot obtain this information directly from the encoder = (e.g., because the implementation is sending data that consists solely = of a sequence of pre-encoded NAL units), then it must instead inspect = subsequent NAL units, to determine whether or not the NAL unit ends an = access unit." > - Last but not least, an AU may also end with a non-VCL NAL = unit, e.g. a filler data NAL unit, an end of sequence NAL unit, an end = of bitstream NAL unit, a suffix SEI NAL unit, etc. Arggh! Now, I hope, you see the problem :-) Can you then help me = figure out a more accurate wording for the rule? In particular: 1/ Suppose we have a VCL NAL unit, followed immediately by = another VCL NAL unit with the first slice header bit set. In this case, = there's no doubt: The first VCL NAL unit definitely ends an 'access = unit' - correct? 2/ Suppose we have a VCL NAL unit, followed by a sequence of one = or more non-VCL NAL units, followed immediately by a VCL NAL unit with = the first slice header bit set. In this case, which (if any) of the = non-VCL NAL units ends an 'access unit'? Can we figure out a rule = (ideally, an easy rule, based solely on the "nal_unit_type"s) for this? Ross Finlayson Live Networks, Inc. http://www.live555.com/ --Apple-Mail=_D679A071-4D6C-4368-9856-7FA361D3ABA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Now I understand your = intention better =96 did not see that the note was intended for sender = implementers. 

OK= , thanks.


 For this purpose, = indeed (as Mo pointed out earlier?) that first of all, the sender needs = make sure the RTP timestamp for each RTP packet is correct. As long as = RTP timestamp is correct, it is also easy to know when the M bit should = be set. Or are you saying that there is no problem with RTP timestamp = setting but there is a problem for the M bit setting? If yes, please = clarify = why.

Figuring out = the RTP timestamp isn't (nearly as much of) a problem, because this can = be done by knowing the stream's frame rate.  But in this email = thread, I'm focusing only on the RTP 'M' bit, because for it (unlike the = timestamp) there's less of an incentive for a sender implementation to = 'get it right'.  I'm worried that if the RTP payload format = specification doesn't make it crystal clear when a NAL unit ends an = 'access unit', then an implementer might be tempted to just not bother = setting the bit at all.  I don't want to see that happen. =  Hence this email thread.


I have no problem = to putting some information in the line as you suggested, if the = suggested text is good. However, the suggested wording below still has a = few problems (or shortcomings).
 
Unfortunately = the contents of a NAL unit, alone, does not tell a RTP sender = implementation whether or not the NAL unit ends an access unit. =  Instead, the implementation can obtain this information = separately, from the encoder.  If, however, this information is = not available directly from the encoder (e.g., because the = implementation is sending data that consists solely of a sequence of = pre-encoded NAL units), then it must instead inspect subsequent NAL = units, to determine whether or not the NAL unit ends an access unit. =  The following rule can be used:
    A NAL unit ends an access unit if it = is a VCL NAL unit, and the next-occurring VCL NAL unit has the = high-order bit of the first byte after its NALU header equal to = 1.
 
The problems (or shortcomings) = are:
- I don=92t think it is good to say that the fact that = a NAL unit itself does not indicate whether it is the last one of an AU = is unfortunate.

Why = not?  It *is* "unfortunate".  I'm not intending to 'insult' = H.265 here :-)


 Saying that the information can be obtained from the = encoder is vague to me. I guess you meant the bitstream instead, as the = encoder may be absent e.g. when dealing pre-encoded = video.

I think you = may have been confused by my use of the word "can" in the 2nd sentence = of my proposed paragraph.  Here is a rewording of the 2nd (& = 3rd) sentences; I hope this will make things = clearer:

"Instead, the implementation may = be able to obtain this information separately, from the encoder. =  If, however, the implementation cannot obtain this information = directly from the encoder (e.g., because the implementation is sending = data that consists solely of a sequence of pre-encoded NAL units), then = it must instead inspect subsequent NAL units, to determine whether or = not the NAL unit ends an access unit."


-Last but not least, an = AU may also end with a non-VCL NAL unit, e.g. a filler data NAL unit, an = end of sequence NAL unit, an end of bitstream NAL unit, a suffix SEI NAL = unit, = etc.

Arggh! =  Now, I hope, you see the problem :-)  Can you then help me = figure out a more accurate wording for the rule?  In = particular:
= 1/ Suppose we have a VCL NAL unit, followed immediately by = another VCL NAL unit with the first slice header bit set.  In this = case, there's no doubt: The first VCL NAL unit definitely ends an = 'access unit' - correct?
2/ Suppose we have a VCL NAL = unit, followed by a sequence of one or more non-VCL NAL units, followed = immediately by a VCL NAL unit with the first slice header bit set. =  In this case, which (if any) of the non-VCL NAL units ends an = 'access unit'?  Can we figure out a rule (ideally, an easy rule, = based solely on the "nal_unit_type"s) for this?


Ross = Finlayson
Live Networks, Inc.
http://www.live555.com/=

= --Apple-Mail=_D679A071-4D6C-4368-9856-7FA361D3ABA3-- From mzanaty@cisco.com Fri Aug 9 20:21:47 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1631F0D5B; Fri, 9 Aug 2013 20:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPwTbovYkQqr; Fri, 9 Aug 2013 20:21:41 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 07C5D11E80E1; Fri, 9 Aug 2013 20:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24516; q=dns/txt; s=iport; t=1376104509; x=1377314109; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=9nMqi7xSAthD1UZc7OOTUeCL9yC5XS7sbLhDJVSJ9qU=; b=WoadOQubo3H5A7PLk7AOqbThmU1IDxJOi7YM7uYiIyEzy2ptuZLEoSpu H16mYSKYZFKFXQatdh2BJ6mK9cIrSOEX7NpdA8f+Zwm88IVb+ES0zefeV /mZeo3+3QMHO1CeDbYWtz9aJCKciEdnHtpRZQhRRYgAMW+OxIH2KsMHN5 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFANSvBVKtJXG//2dsb2JhbABbgkJENVC9SwGBDoEcFnSCJAEBAQQtXAIBCBEEAQELFgMEBzIUCQgCBAESCIgIuEuObIEVNwGDGnUDlAuVJoFhgTqBcTk X-IronPort-AV: E=Sophos;i="4.89,849,1367971200"; d="scan'208,217";a="245494983" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 10 Aug 2013 03:15:04 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7A3F3H2030968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 10 Aug 2013 03:15:03 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 22:15:02 -0500 From: "Mo Zanaty (mzanaty)" To: Ross Finlayson , "avt@ietf.org" , "payload@ietf.org" Thread-Topic: [AVTCORE] [payload] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit Thread-Index: AQHOlWQpaJZ07kYRdUCcKb/5v960lpmNqdXA Date: Sat, 10 Aug 2013 03:15:02 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D4CC65C@xmb-rcd-x14.cisco.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> <69F25DB2-6926-4ACA-935D-90376A2A7BFA@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D690F@nasanexd02f.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.235.195] Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D91D4CC65Cxmbrcdx14ciscoc_" MIME-Version: 1.0 Subject: Re: [payload] [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 03:21:47 -0000 --_000_3879D71E758A7E4AA99A35DD8D41D3D91D4CC65Cxmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ross, If we focus on the RTP timestamp rather than the marker bit, I think we wil= l solve your problem. The timestamp MUST be set reliably since it is critic= al for many RTP functions. The marker bit SHOULD be set reliably to allow r= eceivers to detect end of frame without waiting for the next frame/timestam= p, but this is not a MUST because it is just a latency optimization rather = than a critical function. If you are unable to set the RTP timestamp reliably, that is a much bigger = issue than the marker bit. That would be an entirely different discussion, = so I assume that is not the case. If you are able to set the RTP timestamp reliably, then you must already ha= ve some sort of frame boundary identification. In that case, you can set th= e marker bit based on the timestamp changing, assuming you are willing to w= ait for the next frame/timestamp before sending the last packet of a frame. But you should realize that, in doing this, you have defeated the marker bi= t optimization. You have just shifted the latency from the receiver to the = sender, but the latency remains the same. In both cases you incur the extra= latency between the last packet of a frame and the first packet of the nex= t frame. If the sender incurs this latency to make the marker bit reliable, the rece= iver will hopefully detect that it is reliable and not incur further latenc= y. However, a simple receiver may incur further latency if it only looks fo= r timestamp changes and has no logic to detect marker reliability to optimi= ze out this latency. Also, if the receiver jitter buffer is currently longe= r than the extra latency added by the sender, then the sender added the ext= ra latency unnecessarily. If the sender never sets the marker bit to avoid adding latency, the receiv= er will incur the latency once it sees the marker bit is unreliable (or unc= onditionally for simple receivers that only look for timestamp changes). So there is not much benefit in making the marker bit reliable in this case= , and there is even the risk that it will add unnecessary latency. Regards, Mo From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross = Finlayson Sent: Friday, August 09, 2013 8:48 PM To: avt@ietf.org; payload@ietf.org Subject: Re: [AVTCORE] [payload] Clarifying the H.265 RTP payload format sp= ecification's text on when to set the RTP "M" bit Now I understand your intention better - did not see that the note was inte= nded for sender implementers. OK, thanks. For this purpose, indeed (as Mo pointed out earlier?) that first of all, t= he sender needs make sure the RTP timestamp for each RTP packet is correct.= As long as RTP timestamp is correct, it is also easy to know when the M bi= t should be set. Or are you saying that there is no problem with RTP timest= amp setting but there is a problem for the M bit setting? If yes, please cl= arify why. Figuring out the RTP timestamp isn't (nearly as much of) a problem, because= this can be done by knowing the stream's frame rate. But in this email th= read, I'm focusing only on the RTP 'M' bit, because for it (unlike the time= stamp) there's less of an incentive for a sender implementation to 'get it = right'. I'm worried that if the RTP payload format specification doesn't m= ake it crystal clear when a NAL unit ends an 'access unit', then an impleme= nter might be tempted to just not bother setting the bit at all. I don't w= ant to see that happen. Hence this email thread. I have no problem to putting some information in the line as you suggested,= if the suggested text is good. However, the suggested wording below still = has a few problems (or shortcomings). ---------- Unfortunately the contents of a NAL unit, alone, does not tell a RTP sender= implementation whether or not the NAL unit ends an access unit. Instead, = the implementation can obtain this information separately, from the encoder= . If, however, this information is not available directly from the encoder= (e.g., because the implementation is sending data that consists solely of = a sequence of pre-encoded NAL units), then it must instead inspect subseque= nt NAL units, to determine whether or not the NAL unit ends an access unit.= The following rule can be used: A NAL unit ends an access unit if it is a VCL NAL unit, and the next-oc= curring VCL NAL unit has the high-order bit of the first byte after its NAL= U header equal to 1. ---------- The problems (or shortcomings) are: - I don't think it is good to say that the fact that a NAL unit it= self does not indicate whether it is the last one of an AU is unfortunate. Why not? It *is* "unfortunate". I'm not intending to 'insult' H.265 here = :-) - Saying that the information can be obtained from the encoder is = vague to me. I guess you meant the bitstream instead, as the encoder may be= absent e.g. when dealing pre-encoded video. I think you may have been confused by my use of the word "can" in the 2nd s= entence of my proposed paragraph. Here is a rewording of the 2nd (& 3rd) s= entences; I hope this will make things clearer: "Instead, the implementation may be able to obtain this informa= tion separately, from the encoder. If, however, the implementation cannot = obtain this information directly from the encoder (e.g., because the implem= entation is sending data that consists solely of a sequence of pre-encoded = NAL units), then it must instead inspect subsequent NAL units, to determine= whether or not the NAL unit ends an access unit." - Last but not least, an AU may also end with a non-VCL NAL unit, = e.g. a filler data NAL unit, an end of sequence NAL unit, an end of bitstre= am NAL unit, a suffix SEI NAL unit, etc. Arggh! Now, I hope, you see the problem :-) Can you then help me figure o= ut a more accurate wording for the rule? In particular: 1/ Suppose we have a VCL NAL unit, followed immediately by anot= her VCL NAL unit with the first slice header bit set. In this case, there'= s no doubt: The first VCL NAL unit definitely ends an 'access unit' - corre= ct? 2/ Suppose we have a VCL NAL unit, followed by a sequence of on= e or more non-VCL NAL units, followed immediately by a VCL NAL unit with th= e first slice header bit set. In this case, which (if any) of the non-VCL = NAL units ends an 'access unit'? Can we figure out a rule (ideally, an eas= y rule, based solely on the "nal_unit_type"s) for this? Ross Finlayson Live Networks, Inc. http://www.live555.com/ --_000_3879D71E758A7E4AA99A35DD8D41D3D91D4CC65Cxmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ross,

 

If we focus on the RTP timestamp rather= than the marker bit, I think we will solve your problem. The timestamp MUS= T be set reliably since it is critical for many RTP functions. The marker bit SHOULD be set reliably to allow receivers to detect end of = frame without waiting for the next frame/timestamp, but this is not a MUST = because it is just a latency optimization rather than a critical function.<= o:p>

 

If you are unable to set the RTP timest= amp reliably, that is a much bigger issue than the marker bit. That would b= e an entirely different discussion, so I assume that is not the case.

 

If you are able to set the RTP timestam= p reliably, then you must already have some sort of frame boundary identifi= cation. In that case, you can set the marker bit based on the timestamp changing, assuming you are willing to wait for the next fram= e/timestamp before sending the last packet of a frame.

 

But you should realize that, in doing t= his, you have defeated the marker bit optimization. You have just shifted t= he latency from the receiver to the sender, but the latency remains the same. In both cases you incur the extra latency between the la= st packet of a frame and the first packet of the next frame.

 

If the sender incurs this latency to ma= ke the marker bit reliable, the receiver will hopefully detect that it is r= eliable and not incur further latency. However, a simple receiver may incur further latency if it only looks for timestamp changes = and has no logic to detect marker reliability to optimize out this latency.= Also, if the receiver jitter buffer is currently longer than the extra lat= ency added by the sender, then the sender added the extra latency unnecessarily.

 

If the sender never sets the marker bit= to avoid adding latency, the receiver will incur the latency once it sees = the marker bit is unreliable (or unconditionally for simple receivers that only look for timestamp changes).

 

So there is not much benefit in making = the marker bit reliable in this case, and there is even the risk that it wi= ll add unnecessary latency.

 

Regards,

Mo

 

From: avt-boun= ces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross Finlayson
Sent: Friday, August 09, 2013 8:48 PM
To: avt@ietf.org; payload@ietf.org
Subject: Re: [AVTCORE] [payload] Clarifying the H.265 RTP payload fo= rmat specification's text on when to set the RTP "M" bit

 

Now I unde= rstand your intention better – did not see that the note was intended= for sender implementers. 

 

OK, thanks.

 



 For = this purpose, indeed (as Mo pointed out earlier?) that first of all, the se= nder needs make sure the RTP timestamp for each RTP packet is correct. As long as RTP timestamp is correct, it is also easy to know when the M bi= t should be set. Or are you saying that there is no problem with RTP timest= amp setting but there is a problem for the M bit setting? If yes, please cl= arify why.

 

Figuring out the RTP timestamp isn't (nearly as much= of) a problem, because this can be done by knowing the stream's frame rate= .  But in this email thread, I'm focusing only on the RTP 'M' bit, bec= ause for it (unlike the timestamp) there's less of an incentive for a sender implementation to 'get it right'.  = I'm worried that if the RTP payload format specification doesn't make it cr= ystal clear when a NAL unit ends an 'access unit', then an implementer migh= t be tempted to just not bother setting the bit at all.  I don't want to see that happen.  Hence this em= ail thread.




I have no = problem to putting some information in the line as you suggested, if the su= ggested text is good. However, the suggested wording below still has a few problems (or shortcomings).

 

----------

Unfortunately the contents of a= NAL unit, alone, does not tell a RTP sender implementation whether or not = the NAL unit ends an access unit.  Instead, the implementation can obt= ain this information separately, from the encoder.  If, however, this information is not available di= rectly from the encoder (e.g., because the implementation is sending data t= hat consists solely of a sequence of pre-encoded NAL units), then it must i= nstead inspect subsequent NAL units, to determine whether or not the NAL unit ends an access unit.  The following rule = can be used:

    A NAL unit ends a= n access unit if it is a VCL NAL unit, and the next-occurring VCL NAL = unit has the high-order bit of the first byte after its NALU header equal t= o 1.

----------

 

The proble= ms (or shortcomings) are:

-          I don’t think it is good to say that the fact that a NAL unit itself d= oes not indicate whether it is the last one of an AU is unfortunate.=

 

Why not?  It *is* "unfortunate". &nbs= p;I'm not intending to 'insult' H.265 here :-)

 



-          Saying that the information can be obtained from the encoder is vague to me. I gu= ess you meant the bitstream instead, as the encoder may be absent e.g. when= dealing pre-encoded video.

 

I think you may have been confused by my use of the = word "can" in the 2nd sentence of my proposed paragraph.  He= re is a rewording of the 2nd (& 3rd) sentences; I hope this will make t= hings clearer:

 

   &nb= sp;        "Instead, the imp= lementation may be able to obtain this information separately, from the enc= oder.  If, however, the implementation cannot obtain this information = directly from the encoder (e.g., because the implementation is sending data that consists solely of = a sequence of pre-encoded NAL units), then it must instead inspect subseque= nt NAL units, to determine whether or not the NAL unit ends an access unit.= "




-          Last but not least, an AU may also end with a non-VCL NAL unit, e.g. a filler d= ata NAL unit, an end of sequence NAL unit, an end of bitstream NAL unit, a = suffix SEI NAL unit, etc.

 

Arggh!  Now, I hope, you see the problem :-) &n= bsp;Can you then help me figure out a more accurate wording for the rule? &= nbsp;In particular:

   &nb= sp;        1/ Suppose we have a V= CL NAL unit, followed immediately by another VCL NAL unit with the first sl= ice header bit set.  In this case, there's no doubt: The first VCL NAL= unit definitely ends an 'access unit' - correct?

   &nb= sp;        2/ Suppose we have a V= CL NAL unit, followed by a sequence of one or more non-VCL NAL units, follo= wed immediately by a VCL NAL unit with the first slice header bit set.=  In this case, which (if any) of the non-VCL NAL units ends an 'access unit'?  Can we figu= re out a rule (ideally, an easy rule, based solely on the "nal_unit_ty= pe"s) for this?

 

Ross Finlayson
Live Networks, Inc.
http:/= /www.live555.com/

 

--_000_3879D71E758A7E4AA99A35DD8D41D3D91D4CC65Cxmbrcdx14ciscoc_-- From finlayson@live555.com Fri Aug 9 21:55:27 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2978D11E8131; Fri, 9 Aug 2013 21:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qg3n6t+LvOuc; Fri, 9 Aug 2013 21:55:21 -0700 (PDT) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6677611E80F6; Fri, 9 Aug 2013 21:49:53 -0700 (PDT) Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.4/8.14.4) with ESMTP id r7A4nkJF057217; Fri, 9 Aug 2013 21:49:50 -0700 (PDT) (envelope-from finlayson@live555.com) From: Ross Finlayson Content-Type: multipart/alternative; boundary="Apple-Mail=_41DC87E7-EDDD-43ED-AB0D-08FD287188A7" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Fri, 9 Aug 2013 21:49:45 -0700 References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> <69F25DB2-6926-4ACA-935D-90376A2A7BFA@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D690F@nasanexd02f.na.qualcomm.com> <3879D71E758A7E4AA99A35DD8D41D3D91D4CC65C@xmb-rcd-x14.cisco.com> To: "avt@ietf.org" , "payload@ietf.org" In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D4CC65C@xmb-rcd-x14.cisco.com> X-Mailer: Apple Mail (2.1508) Subject: Re: [payload] [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 04:55:27 -0000 --Apple-Mail=_41DC87E7-EDDD-43ED-AB0D-08FD287188A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > If you are able to set the RTP timestamp reliably, then you must = already have some sort of frame boundary identification. Yes, we have a reliable way of determining when *VCL* NAL units cross a = frame boundary: Look at the first slice header bit. The one remaining = problem (that I identified at the end of my last message) is: How to = classify any *non-VCL* NAL units that appear between one VCL NAL unit = and another VCL unit that has the first slice header bit. Which of = these belong to the last frame, and which belong to the next frame. But perhaps this doesn't really matter? Perhaps it's OK (from the point = of view of receivers that check and try to optimize for the 'M' bit) if = we always set the 'M' bit for the last VCL NAL unit of a frame, even if = some subsequent non-VCL NAL units (appearing before the first VCL NAL = unit of the next frame) also belong logically to the current frame?? > But you should realize that, in doing this, you have defeated the = marker bit optimization. You have just shifted the latency from the = receiver to the sender No, not necessarily. If the encoded video comes from a file (i.e., = pre-recorded), then the latency involved in requiring the sender to = examine the 'next' frame will usually be negligible. But in any case, = the situation we're talking about here (senders working from a sequence = of pre-encoded NAL units) is one that usually occurs only in = non-interactive environments, for which latency isn't crucial. > So there is not much benefit in making the marker bit reliable in this = case, and there is even the risk that it will add unnecessary latency. That's certainly another possibility, I suppose: Recommend that if a = sending implementation cannot determine whether or not a NAL unit ends = an 'access unit' (frame) without having to scan subsequent NAL units, = then it should not set the 'M' bit at all. I don't like this, though = (especially because it adds receiver latency without necessarily = reducing sender latency (note above)). But it's a possibility to = consider... Ross Finlayson Live Networks, Inc. http://www.live555.com/ --Apple-Mail=_41DC87E7-EDDD-43ED-AB0D-08FD287188A7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
If you are able to set the RTP timestamp = reliably, then you must already have some sort of frame boundary = identification.

Yes, = we have a reliable way of determining when *VCL* NAL units cross a frame = boundary: Look at the first slice header bit.  The one = remaining problem (that I identified at the end of my last message) is: = How to classify any *non-VCL* NAL units that appear between one VCL NAL = unit and another VCL unit that has the first slice header bit. =  Which of these belong to the last frame, and which belong to the = next frame.

But perhaps this doesn't really = matter?  Perhaps it's OK (from the point of view of receivers that = check and try to optimize for the 'M' bit) if we always set the 'M' bit = for the last VCL NAL unit of a frame, even if some subsequent non-VCL = NAL units (appearing before the first VCL NAL unit of the next frame) = also belong logically to the current = frame??


But you should realize that, in doing this, you = have defeated the marker bit optimization. You have just shifted the = latency from the receiver to the = sender

No, not = necessarily.  If the encoded video comes from a file (i.e., = pre-recorded), then the latency involved in requiring the sender to = examine the 'next' frame will usually be negligible.  But in any = case, the situation we're talking about here (senders working from a = sequence of pre-encoded NAL units) is one that usually occurs only in = non-interactive environments, for which latency isn't = crucial.


So there is not much benefit in making the marker bit = reliable in this case, and there is even the risk that it will add = unnecessary = latency.

That's = certainly another possibility, I suppose: Recommend that if a sending = implementation cannot determine whether or not a NAL unit ends an = 'access unit' (frame) without having to scan subsequent NAL units, then = it should not set the 'M' bit at all.  I don't like this, though = (especially because it adds receiver latency without necessarily = reducing sender latency (note above)).  But it's a possibility to = consider...

Ross = Finlayson
Live Networks, Inc.
http://www.live555.com/=

= --Apple-Mail=_41DC87E7-EDDD-43ED-AB0D-08FD287188A7-- From yekuiw@qti.qualcomm.com Sat Aug 10 07:00:04 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE2111E810E; Sat, 10 Aug 2013 07:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAP4SXT4ijdy; Sat, 10 Aug 2013 06:59:59 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 1773921F843F; Sat, 10 Aug 2013 06:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1376142887; x=1407678887; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=rNWQu+sNVuqJRA+KMoUGa8pfHyY2LwJyEm2J9P3jB6I=; b=zN//X2+ayOB57aSvDNdu2dTybSFVNmDBDXHhYZRgsPeqtMZAE2j+qnVG Y5csjQFpU7xbGhlSbgkCPrr9y37QmgZZ38gHAbHi3YI78pJSW25gpVJwy HklvFq+AbjNuNhhf78ejv9KVRhFOBKyMWZprCdCMW23gSx7fNkGpXoDr1 s=; X-IronPort-AV: E=Sophos;i="4.89,851,1367996400"; d="scan'208,217";a="49335680" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 10 Aug 2013 06:54:45 -0700 Received: from nasanexhc16.na.qualcomm.com ([10.45.158.213]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Aug 2013 06:54:45 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.21]) by nasanexhc16.na.qualcomm.com ([10.45.158.213]) with mapi id 14.03.0146.002; Sat, 10 Aug 2013 06:54:45 -0700 From: "Wang, Ye-Kui" To: Ross Finlayson , "avt@ietf.org" , "payload@ietf.org" Thread-Topic: [AVTCORE] [payload] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit Thread-Index: AQHOlYXebWo12KX/i0m4/b5pwipzfZmOdc6A Date: Sat, 10 Aug 2013 13:54:45 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4@nasanexd02f.na.qualcomm.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> <69F25DB2-6926-4ACA-935D-90376A2A7BFA@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D690F@nasanexd02f.na.qualcomm.com> <3879D71E758A7E4AA99A35DD8D41D3D91D4CC65C@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.192] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4nasanexd02fnaqu_" MIME-Version: 1.0 Subject: Re: [payload] [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 14:00:04 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4nasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ross, You just need one more little step to get everything right here, instead of= thinking of compromising the implementation :) That is, read subclause 7.4.2.4.4 of the HEVC spec. The most relevant parag= raphs are copied below for convenience (the first paragraph itself contains= the answer to your question, but the second paragraph may also provide hel= pful information): The first of any of the following NAL units after the last VCL NAL unit of = a coded picture specifies the start of a new access unit: - access unit delimiter NAL unit (when present), - VPS NAL unit (when present), - SPS NAL unit (when present), - PPS NAL unit (when present), - Prefix SEI NAL unit (when present), - NAL units with nal_unit_type in the range of RSV_NVCL41..RSV_NVCL44 (= when present), - NAL units with nal_unit_type in the range of UNSPEC48..UNSPEC55 (when= present), - first VCL NAL unit of a coded picture (always present). The order of the coded pictures and non-VCL NAL units within an access unit= shall obey the following constraints: - When an access unit delimiter NAL unit is present, it shall be the fi= rst NAL unit. There shall be at most one access unit delimiter NAL unit in = any access unit. - When any prefix SEI NAL units are present, they shall not follow the = last VCL NAL unit of the access unit. - NAL units having nal_unit_type equal to FD_NUT or SUFFIX_SEI_NUT, or = in the range of RSV_NVCL45..RSV_NVCL47 or UNSPEC56..UNSPEC63 shall not prec= ede the first VCL NAL unit of the coded picture. - When an end of sequence NAL unit is present, it shall be the last NAL= unit in the access unit other than an end of bitstream NAL unit (when pres= ent). - When an end of bitstream NAL unit is present, it shall be the last NA= L unit in the access unit. NOTE - VPS NAL units, SPS NAL units, PPS NAL units, prefix SEI NAL units, o= r NAL units with nal_unit_type in the range of RSV_NVCL41..RSV_NVCL44 or UN= SPEC48..UNSPEC55, may be present in an access unit, but cannot follow the l= ast VCL NAL unit of the coded picture within the access unit, as this condi= tion would specify the start of a new access unit. BR, YK From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross = Finlayson Sent: Friday, August 09, 2013 9:50 PM To: avt@ietf.org; payload@ietf.org Subject: Re: [AVTCORE] [payload] Clarifying the H.265 RTP payload format sp= ecification's text on when to set the RTP "M" bit If you are able to set the RTP timestamp reliably, then you must already ha= ve some sort of frame boundary identification. Yes, we have a reliable way of determining when *VCL* NAL units cross a fra= me boundary: Look at the first slice header bit. The one remaining problem= (that I identified at the end of my last message) is: How to classify any = *non-VCL* NAL units that appear between one VCL NAL unit and another VCL un= it that has the first slice header bit. Which of these belong to the last = frame, and which belong to the next frame. But perhaps this doesn't really matter? Perhaps it's OK (from the point of= view of receivers that check and try to optimize for the 'M' bit) if we al= ways set the 'M' bit for the last VCL NAL unit of a frame, even if some sub= sequent non-VCL NAL units (appearing before the first VCL NAL unit of the n= ext frame) also belong logically to the current frame?? But you should realize that, in doing this, you have defeated the marker bi= t optimization. You have just shifted the latency from the receiver to the = sender No, not necessarily. If the encoded video comes from a file (i.e., pre-rec= orded), then the latency involved in requiring the sender to examine the 'n= ext' frame will usually be negligible. But in any case, the situation we'r= e talking about here (senders working from a sequence of pre-encoded NAL un= its) is one that usually occurs only in non-interactive environments, for w= hich latency isn't crucial. So there is not much benefit in making the marker bit reliable in this case= , and there is even the risk that it will add unnecessary latency. That's certainly another possibility, I suppose: Recommend that if a sendin= g implementation cannot determine whether or not a NAL unit ends an 'access= unit' (frame) without having to scan subsequent NAL units, then it should = not set the 'M' bit at all. I don't like this, though (especially because = it adds receiver latency without necessarily reducing sender latency (note = above)). But it's a possibility to consider... Ross Finlayson Live Networks, Inc. http://www.live555.com/ --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4nasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ross,

 <= /p>

You just need one more li= ttle step to get everything right here, instead of thinking of compromising= the implementation J

 <= /p>

That is, read subclause 7= .4.2.4.4 of the HEVC spec. The most relevant paragraphs are copied below fo= r convenience (the first paragraph itself contains the answer to your question, but the second paragraph may also provide helpful inform= ation):

 <= /p>

The first of any of the following NAL units after th= e last VCL NAL unit of a coded picture specifies the start of a new access = unit:

–     access unit delimite= r NAL unit (when present),

–     VPS NAL unit (when p= resent),

–     SPS NAL unit (when p= resent),

–     PPS NAL unit (when p= resent),

–     Prefix SEI NAL unit = (when present),

–     NAL units with nal_u= nit_type in the range of RSV_NVCL41..RSV_NVCL44 (when present),<= /p>

–     NAL units with nal_u= nit_type in the range of UNSPEC48..UNSPEC55 (when present),

–     first VCL NAL unit o= f a coded picture (always present).

 

The order of the coded pictures and non-VCL NAL unit= s within an access unit shall obey the following constraints:

= 211;     When an access unit delimiter NAL unit is pres= ent, it shall be the first NAL unit. There shall be at most one access unit= delimiter NAL unit in any access unit.

= 211;     When any prefix SEI NAL units are present, the= y shall not follow the last VCL NAL unit of the access unit.

= 211;     NAL units having nal_unit_type equal to FD_NUT= or SUFFIX_SEI_NUT, or in the range of RSV_NVCL45..RSV_NVCL47 or UNSPEC56..= UNSPEC63 shall not precede the first VCL NAL unit of the coded picture.

= 211;     When an end of sequence NAL unit is present, i= t shall be the last NAL unit in the access unit other than an end of bitstr= eam NAL unit (when present).

= 211;     When an end of bitstream NAL unit is present, = it shall be the last NAL unit in the access unit.

NOTE – VPS NAL unit= s, SPS NAL units, PPS NAL units, prefix SEI NAL units, or NAL units with na= l_unit_type in the range of RSV_NVCL41..RSV_NVCL44 or UNSPEC48..UNSPEC55, m= ay be present in an access unit, but cannot follow the last VCL NAL unit of the coded picture within the access unit, as this con= dition would specify the start of a new access unit.

 <= /p>

BR, YK<= /p>

 <= /p>

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross Finlayson
Sent: Friday, August 09, 2013 9:50 PM
To: avt@ietf.org; payload@ietf.org
Subject: Re: [AVTCORE] [payload] Clarifying the H.265 RTP payload fo= rmat specification's text on when to set the RTP "M" bit

 

If you are able to set t= he RTP timestamp reliably, then you must already have some sort of frame bo= undary identification.

 

Yes, we have a reliable way of determining when *VCL= * NAL units cross a frame boundary: Look at the first slice header bit= .  The one remaining problem (that I identified at the end of my last = message) is: How to classify any *non-VCL* NAL units that appear between one VCL NAL unit and another VCL unit that has t= he first slice header bit.  Which of these belong to the last frame, a= nd which belong to the next frame.

 

But perhaps this doesn't really matter?  Perhap= s it's OK (from the point of view of receivers that check and try to optimi= ze for the 'M' bit) if we always set the 'M' bit for the last VCL NAL unit = of a frame, even if some subsequent non-VCL NAL units (appearing before the first VCL NAL unit of the next frame) also= belong logically to the current frame??

 



But you should realize t= hat, in doing this, you have defeated the marker bit optimization. You have= just shifted the latency from the receiver to the sender

 

No, not necessarily.  If the encoded video come= s from a file (i.e., pre-recorded), then the latency involved in requiring = the sender to examine the 'next' frame will usually be negligible.  Bu= t in any case, the situation we're talking about here (senders working from a sequence of pre-encoded NAL units) is one tha= t usually occurs only in non-interactive environments, for which latency is= n't crucial.

 

 

So there is not much ben= efit in making the marker bit reliable in this case, and there is even the = risk that it will add unnecessary latency.=

 

That's certainly anot= her possibility, I suppose: Recommend that if a sending implementation cann= ot determine whether or not a NAL unit ends an 'access unit' (frame) withou= t having to scan subsequent NAL units, then it should not set the 'M' bit at all.  I don't like this, though= (especially because it adds receiver latency without necessarily reducing = sender latency (note above)).  But it's a possibility to consider...

Ross Finlayson
Live Networks, Inc.
http:/= /www.live555.com/

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4nasanexd02fnaqu_-- From yekuiw@qti.qualcomm.com Sat Aug 10 07:25:43 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C43E11E8102; Sat, 10 Aug 2013 07:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rVb2xeyizpO; Sat, 10 Aug 2013 07:25:38 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC3721F9DAA; Sat, 10 Aug 2013 07:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1376144207; x=1407680207; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=iCUKa4gDTQFRPQYaGSZMr0Czbf73tZVUzI6EPBnyRBE=; b=N4HFosWf0tisriscPhyLEl3scuHEq78OfzxbZlHqWffzphJg6iHCZxyB 4ft7xCXrl7iJqdCPOtPVreSVDIWwLlF01wqJb2pOudZCr7BD4PjELR2UD nCpYcpqNlRBvn+779ENcc68eyiDM3UdXcwf+fHV7T214P8dpTZ+ei1yzI I=; X-IronPort-AV: E=Sophos;i="4.89,851,1367996400"; d="scan'208,217";a="49336497" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth02.qualcomm.com with ESMTP; 10 Aug 2013 07:16:47 -0700 Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 10 Aug 2013 07:16:46 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.21]) by nasanexhc08.na.qualcomm.com ([172.30.39.7]) with mapi id 14.03.0146.002; Sat, 10 Aug 2013 07:16:46 -0700 From: "Wang, Ye-Kui" To: Ross Finlayson , "avt@ietf.org" , "payload@ietf.org" Thread-Topic: [AVTCORE] [payload] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit Thread-Index: AQHOldHxrENwOy7dhUOuP7HJFLBE0pmOeOQQ Date: Sat, 10 Aug 2013 14:16:46 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83384D701C@nasanexd02f.na.qualcomm.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> <69F25DB2-6926-4ACA-935D-90376A2A7BFA@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D690F@nasanexd02f.na.qualcomm.com> <3879D71E758A7E4AA99A35DD8D41D3D91D4CC65C@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4@nasanexd02f.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.192] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83384D701Cnasanexd02fnaqu_" MIME-Version: 1.0 Subject: Re: [payload] [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 14:25:43 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D701Cnasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regardless of the following, I still think that the timestamp approach shou= ld be the way to go. A good system should have a clear mapping of each vide= o data unit (NAL unit in the context of H.265 and H.264) to an output times= tamp, be it real-time encoding or pre-encoded content. For real-time encodi= ng, the encoder knows what data units are generated for each input raw pict= ure and thus it clearly knows the timestamp for each data unit. A pre-encod= ed content should have been stored in some kind of video storage format tha= t has timestamp associated with each data unit, e.g. in a file container ac= cording to ISO base media file format, MPEG-2 systems, or whatever other fi= le storage format. Trying to generate timestamps from a raw coded video bit= stream without timing information for each coded picture based on a guess o= f frame rate is really just a hack to me, as frame rate can be adaptive, pa= rticularly at the beginning of a session in low-delay conversational applic= ations or at locations of scene change or of need of full intra refresh or = random accessibility, wherein your rate control algorithm can easily requir= e skipping the encoding of some frames. BR, YK From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Wang,= Ye-Kui Sent: Saturday, August 10, 2013 6:55 AM To: Ross Finlayson; avt@ietf.org; payload@ietf.org Subject: Re: [AVTCORE] [payload] Clarifying the H.265 RTP payload format sp= ecification's text on when to set the RTP "M" bit Hi Ross, You just need one more little step to get everything right here, instead of= thinking of compromising the implementation :) That is, read subclause 7.4.2.4.4 of the HEVC spec. The most relevant parag= raphs are copied below for convenience (the first paragraph itself contains= the answer to your question, but the second paragraph may also provide hel= pful information): The first of any of the following NAL units after the last VCL NAL unit of = a coded picture specifies the start of a new access unit: - access unit delimiter NAL unit (when present), - VPS NAL unit (when present), - SPS NAL unit (when present), - PPS NAL unit (when present), - Prefix SEI NAL unit (when present), - NAL units with nal_unit_type in the range of RSV_NVCL41..RSV_NVCL44 (= when present), - NAL units with nal_unit_type in the range of UNSPEC48..UNSPEC55 (when= present), - first VCL NAL unit of a coded picture (always present). The order of the coded pictures and non-VCL NAL units within an access unit= shall obey the following constraints: - When an access unit delimiter NAL unit is present, it shall be the fi= rst NAL unit. There shall be at most one access unit delimiter NAL unit in = any access unit. - When any prefix SEI NAL units are present, they shall not follow the = last VCL NAL unit of the access unit. - NAL units having nal_unit_type equal to FD_NUT or SUFFIX_SEI_NUT, or = in the range of RSV_NVCL45..RSV_NVCL47 or UNSPEC56..UNSPEC63 shall not prec= ede the first VCL NAL unit of the coded picture. - When an end of sequence NAL unit is present, it shall be the last NAL= unit in the access unit other than an end of bitstream NAL unit (when pres= ent). - When an end of bitstream NAL unit is present, it shall be the last NA= L unit in the access unit. NOTE - VPS NAL units, SPS NAL units, PPS NAL units, prefix SEI NAL units, o= r NAL units with nal_unit_type in the range of RSV_NVCL41..RSV_NVCL44 or UN= SPEC48..UNSPEC55, may be present in an access unit, but cannot follow the l= ast VCL NAL unit of the coded picture within the access unit, as this condi= tion would specify the start of a new access unit. BR, YK From: avt-bounces@ietf.org [mailto:avt-bounces= @ietf.org] On Behalf Of Ross Finlayson Sent: Friday, August 09, 2013 9:50 PM To: avt@ietf.org; payload@ietf.org Subject: Re: [AVTCORE] [payload] Clarifying the H.265 RTP payload format sp= ecification's text on when to set the RTP "M" bit If you are able to set the RTP timestamp reliably, then you must already ha= ve some sort of frame boundary identification. Yes, we have a reliable way of determining when *VCL* NAL units cross a fra= me boundary: Look at the first slice header bit. The one remaining problem= (that I identified at the end of my last message) is: How to classify any = *non-VCL* NAL units that appear between one VCL NAL unit and another VCL un= it that has the first slice header bit. Which of these belong to the last = frame, and which belong to the next frame. But perhaps this doesn't really matter? Perhaps it's OK (from the point of= view of receivers that check and try to optimize for the 'M' bit) if we al= ways set the 'M' bit for the last VCL NAL unit of a frame, even if some sub= sequent non-VCL NAL units (appearing before the first VCL NAL unit of the n= ext frame) also belong logically to the current frame?? But you should realize that, in doing this, you have defeated the marker bi= t optimization. You have just shifted the latency from the receiver to the = sender No, not necessarily. If the encoded video comes from a file (i.e., pre-rec= orded), then the latency involved in requiring the sender to examine the 'n= ext' frame will usually be negligible. But in any case, the situation we'r= e talking about here (senders working from a sequence of pre-encoded NAL un= its) is one that usually occurs only in non-interactive environments, for w= hich latency isn't crucial. So there is not much benefit in making the marker bit reliable in this case= , and there is even the risk that it will add unnecessary latency. That's certainly another possibility, I suppose: Recommend that if a sendin= g implementation cannot determine whether or not a NAL unit ends an 'access= unit' (frame) without having to scan subsequent NAL units, then it should = not set the 'M' bit at all. I don't like this, though (especially because = it adds receiver latency without necessarily reducing sender latency (note = above)). But it's a possibility to consider... Ross Finlayson Live Networks, Inc. http://www.live555.com/ --_000_8BA7D4CEACFFE04BA2D902BF11719A83384D701Cnasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Regardless of the followi= ng, I still think that the timestamp approach should be the way to go. A go= od system should have a clear mapping of each video data unit (NAL unit in the context of H.265 and H.264) to an output timestamp, = be it real-time encoding or pre-encoded content. For real-time encoding, th= e encoder knows what data units are generated for each input raw picture an= d thus it clearly knows the timestamp for each data unit. A pre-encoded content should have been stored in some = kind of video storage format that has timestamp associated with each data u= nit, e.g. in a file container according to ISO base media file format, MPEG= -2 systems, or whatever other file storage format. Trying to generate timestamps from a raw coded video bitst= ream without timing information for each coded picture based on a guess of = frame rate is really just a hack to me, as frame rate can be adaptive, part= icularly at the beginning of a session in low-delay conversational applications or at locations of scene change o= r of need of full intra refresh or random accessibility, wherein your rate = control algorithm can easily require skipping the encoding of some frames.

 <= /p>

BR, YK<= /p>

 <= /p>

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Wang, Ye-Kui
Sent: Saturday, August 10, 2013 6:55 AM
To: Ross Finlayson; avt@ietf.org; payload@ietf.org
Subject: Re: [AVTCORE] [payload] Clarifying the H.265 RTP payload fo= rmat specification's text on when to set the RTP "M" bit

 

Hi Ross,

 <= /p>

You just need one more li= ttle step to get everything right here, instead of thinking of compromising= the implementation J

 <= /p>

That is, read subclause 7= .4.2.4.4 of the HEVC spec. The most relevant paragraphs are copied below fo= r convenience (the first paragraph itself contains the answer to your question, but the second paragraph may also provide helpful inform= ation):

 <= /p>

The first of any of the following NAL units after th= e last VCL NAL unit of a coded picture specifies the start of a new access = unit:

–     access unit delimite= r NAL unit (when present),

–     VPS NAL unit (when p= resent),

–     SPS NAL unit (when p= resent),

–     PPS NAL unit (when p= resent),

–     Prefix SEI NAL unit = (when present),

–     NAL units with nal_u= nit_type in the range of RSV_NVCL41..RSV_NVCL44 (when present),<= /p>

–     NAL units with nal_u= nit_type in the range of UNSPEC48..UNSPEC55 (when present),

–     first VCL NAL unit o= f a coded picture (always present).

 

The order of the coded pictures and non-VCL NAL unit= s within an access unit shall obey the following constraints:

= 211;     When an access unit delimiter NAL unit is pres= ent, it shall be the first NAL unit. There shall be at most one access unit= delimiter NAL unit in any access unit.

= 211;     When any prefix SEI NAL units are present, the= y shall not follow the last VCL NAL unit of the access unit.

= 211;     NAL units having nal_unit_type equal to FD_NUT= or SUFFIX_SEI_NUT, or in the range of RSV_NVCL45..RSV_NVCL47 or UNSPEC56..= UNSPEC63 shall not precede the first VCL NAL unit of the coded picture.

= 211;     When an end of sequence NAL unit is present, i= t shall be the last NAL unit in the access unit other than an end of bitstr= eam NAL unit (when present).

= 211;     When an end of bitstream NAL unit is present, = it shall be the last NAL unit in the access unit.

NOTE – VPS NAL unit= s, SPS NAL units, PPS NAL units, prefix SEI NAL units, or NAL units with na= l_unit_type in the range of RSV_NVCL41..RSV_NVCL44 or UNSPEC48..UNSPEC55, m= ay be present in an access unit, but cannot follow the last VCL NAL unit of the coded picture within the access unit, as this con= dition would specify the start of a new access unit.

 <= /p>

BR, YK<= /p>

 <= /p>

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross Finlayson
Sent: Friday, August 09, 2013 9:50 PM
To: avt@ietf.org; payload@ietf.org
Subject: Re: [AVTCORE] [payload] Clarifying the H.265 RTP payload fo= rmat specification's text on when to set the RTP "M" bit

 

If you are able to set t= he RTP timestamp reliably, then you must already have some sort of frame bo= undary identification.

 

Yes, we have a reliable way of determining when *VCL= * NAL units cross a frame boundary: Look at the first slice header bit= .  The one remaining problem (that I identified at the end of my last = message) is: How to classify any *non-VCL* NAL units that appear between one VCL NAL unit and another VCL unit that has t= he first slice header bit.  Which of these belong to the last frame, a= nd which belong to the next frame.

 

But perhaps this doesn't really matter?  Perhap= s it's OK (from the point of view of receivers that check and try to optimi= ze for the 'M' bit) if we always set the 'M' bit for the last VCL NAL unit = of a frame, even if some subsequent non-VCL NAL units (appearing before the first VCL NAL unit of the next frame) also= belong logically to the current frame??

 

 

But you should realize t= hat, in doing this, you have defeated the marker bit optimization. You have= just shifted the latency from the receiver to the sender

 

No, not necessarily.  If the encoded video come= s from a file (i.e., pre-recorded), then the latency involved in requiring = the sender to examine the 'next' frame will usually be negligible.  Bu= t in any case, the situation we're talking about here (senders working from a sequence of pre-encoded NAL units) is one tha= t usually occurs only in non-interactive environments, for which latency is= n't crucial.

 

 

So there is not much ben= efit in making the marker bit reliable in this case, and there is even the = risk that it will add unnecessary latency.=

 

That's certainly anot= her possibility, I suppose: Recommend that if a sending implementation cann= ot determine whether or not a NAL unit ends an 'access unit' (frame) withou= t having to scan subsequent NAL units, then it should not set the 'M' bit at all.  I don't like this, though= (especially because it adds receiver latency without necessarily reducing = sender latency (note above)).  But it's a possibility to consider...

Ross Finlayson
Live Networks, Inc.
http:/= /www.live555.com/

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A83384D701Cnasanexd02fnaqu_-- From ron.even.tlv@gmail.com Mon Aug 12 04:40:39 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E4821F9F21 for ; Mon, 12 Aug 2013 04:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxX9sann2GsO for ; Mon, 12 Aug 2013 04:40:32 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 39D2921F9D98 for ; Mon, 12 Aug 2013 04:01:49 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id e12so5430039wgh.9 for ; Mon, 12 Aug 2013 04:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=qOUCLENBtodDjh0vjEh2pb3b8A6e7Pf8bPHd8/vaT20=; b=ZesYBlW0NMyv3VwclGUEwBvNGvSdlEu+Yk5h5jz4tbu2/zC5566l2CRS1NiAfhie7b uEZcgJblfCwq0wM98ny/5QHVkQKqEOEPH4k5UAdWl1/tqG7lgt123BLDbcri9S9E2Fui SqxAgKqYVYCNTJLwh5pozl2ckcFtNHqDvNYLPsFeYPyVwQJ/dG/b/WEATeS7KabxUqAe wNbOi/KY51ISR1kHy35upp5MaKCm/e2qFacSFksYBfM7RzgOfwF3NA5wPd+pkQOe06YA bRroSOO6KdRAMkR8CaW649eBSE9fscMaPab/Uoj7KpnsQyPmbgTkZFS3CLpDMFoN6G5y BbUw== X-Received: by 10.194.172.9 with SMTP id ay9mr12752308wjc.54.1376305308335; Mon, 12 Aug 2013 04:01:48 -0700 (PDT) Received: from RoniE (bzq-109-67-221-133.red.bezeqint.net. [109.67.221.133]) by mx.google.com with ESMTPSA id a4sm15605066wik.11.2013.08.12.04.01.46 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 12 Aug 2013 04:01:47 -0700 (PDT) From: "Roni Even" To: Date: Mon, 12 Aug 2013 13:59:35 +0300 Message-ID: <057e01ce974b$09abd2c0$1d037840$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_057F_01CE9764.2EF958E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6XSqgF/DFLfyQ6SKatEYNnG5zQAA== Content-Language: en-us Subject: [payload] IETF87 meeting notes X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 11:40:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_057F_01CE9764.2EF958E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I posted the AVTcore meeting notes. There was a presentation on H.265 payload which is part of Payload so please review and comment. http://www.ietf.org/proceedings/87/minutes/minutes-87-avtcore Please review. Roni Even Payload co-chair ------=_NextPart_000_057F_01CE9764.2EF958E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, =

I posted the AVTcore meeting notes. = There was a presentation on H.265 payload which is part of Payload so = please review and comment.

ht= tp://www.ietf.org/proceedings/87/minutes/minutes-87-avtcore

Please review.

Roni Even

Payload = co-chair

------=_NextPart_000_057F_01CE9764.2EF958E0-- From quaix@digigram.com Mon Aug 12 03:46:10 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3C621F9D9C for ; Mon, 12 Aug 2013 03:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mac4cBh18b2y for ; Mon, 12 Aug 2013 03:46:01 -0700 (PDT) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by ietfa.amsl.com (Postfix) with ESMTP id 76E4321F9B4D for ; Mon, 12 Aug 2013 02:13:22 -0700 (PDT) Received: by mail-ee0-f46.google.com with SMTP id c13so3304448eek.19 for ; Mon, 12 Aug 2013 02:13:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=P2MA3Zggb/ct8raoTNANEOqv52A1dOoW0vjwMEqj6yk=; b=kXYgF2gSpOudwUmxtURG46oc9Yq4m3Ot5zuTKX8iDQf766qtVUacHR6g8ZhYXlTvs6 hksB+IKEAhRa3hw0ZdRikfDiEwnQOn9ZnmBQGtTg8JTG1OPsYr0+7ZQNF/MgLEnhCL0G /WqV8l1Tt3UIUyN/rDP2kQcsdPPRNXXzSSoG9y0pC+musXZpGQl6MK3QF3uzsF8ySL+/ 6STCQKKnjiqtGSLmY7HkEnMOTaXIc7C0lO5C0M6l1X1V6ZXjbidckavW2wlqQ5mh19Z/ fbNHZ2bHSXFaLfUrPPQvkJupHp855OVSeUiXv2P3ttrrQI7Sd2/Z+krIsLicrbJ0qwNr BVNQ== X-Gm-Message-State: ALoCoQmXMAuwACYA/KImtVX03YEdXA+dzjkNAF90nnXxuQDtcM7Y31LodBDxm+QVQgZhflx1A+7jMS9XMCHPtVYoUn4I9nC+NA== X-Received: by 10.14.207.4 with SMTP id m4mr12199157eeo.61.1376298800823; Mon, 12 Aug 2013 02:13:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.127.137 with HTTP; Mon, 12 Aug 2013 02:12:40 -0700 (PDT) In-Reply-To: <20130313170532.8176.75319.idtracker@ietfa.amsl.com> References: <20130313170532.8176.75319.idtracker@ietfa.amsl.com> From: Michel Quaix Date: Mon, 12 Aug 2013 11:12:40 +0200 Message-ID: To: internet-drafts@ietf.org Content-Type: multipart/alternative; boundary=047d7b343ff420ef8b04e3bc89cd X-Mailman-Approved-At: Mon, 12 Aug 2013 08:08:52 -0700 Cc: payload@ietf.org, i-d-announce@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-aptx-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 10:46:11 -0000 --047d7b343ff420ef8b04e3bc89cd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We, at Digigram, have implemented this draft in our audio codecs. It works and we need it to guaranty the interoperability with codecs from other manufacturers, so I support adopting this draft. Regards, *Michel QUAIX* Software Group Manager and Solution Specialist, Phone: +33 (0)4 76 52 47 47 DIGIGRAM Innovall=E9e, 82-84 All=E9e Galil=E9e, 38330 MONTBONNOT SAINT-MARTIN, FRANCE 2013/3/13 > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Audio/Video Transport Payloads Working > Group of the IETF. > > Title : RTP Payload Format for Standard apt-X and > Enhanced apt-X Codecs > Author(s) : John Lindsay > Hartmut Foerster > Filename : draft-ietf-payload-rtp-aptx-00.txt > Pages : 22 > Date : 2013-03-13 > > Abstract: > This document specifies a scheme for packetizing Standard apt-X, or > Enhanced apt-X, encoded audio data into Real-time Transport Protocol > (RTP) packets. The document describes a payload format that permits > transmission of multiple related audio channels in a single RTP > payload, and a means of establishing Standard apt-X and Enhanced > apt-X connections through the Session Description Protocol (SDP). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-aptx > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-payload-rtp-aptx-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > --=20 *Meet the Digigram Team in Amsterdam, IBC 2013 - HALL 8, Stand C51 -=20 September 13-17* Need a free invite? - use coupon code 4462 and register here:=20 www.ibc.org/register [image: Images int=E9gr=E9es 1] --047d7b343ff420ef8b04e3bc89cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We, at= Digigram, have implemented this draft in our audio codecs. It works and we= need it to guaranty the interoperability with codecs from other manufactur= ers, so=A0I support adopting this draft.

Regards,
Michel QUAIX
=
Software Group Manager and Solution Specialist= ,
DIGIGRAM
Innovall=E9e, 82-84 All=E9e Galil=E9e,
38330 MONTBONNOT SAINT-MARTIN,
FRANCE


2013/3/13 <internet-drafts@ietf= .org>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Audio/Video Transport Payloads Working = Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : RTP Payload Format for Standard= apt-X and Enhanced apt-X Codecs
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : John Lindsay
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hartmut Foerster
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-payload-rtp-aptx-00.tx= t
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 22
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-03-13

Abstract:
=A0 =A0This document specifies a scheme for packetizing Standard apt-X, or<= br> =A0 =A0Enhanced apt-X, encoded audio data into Real-time Transport Protocol=
=A0 =A0(RTP) packets. =A0The document describes a payload format that permi= ts
=A0 =A0transmission of multiple related audio channels in a single RTP
=A0 =A0payload, and a means of establishing Standard apt-X and Enhanced
=A0 =A0apt-X connections through the Session Description Protocol (SDP).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-apt= x

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-payload-rtp-aptx-00<= br>

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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


Meet the Digigram Te= am in Amsterdam,=A0IBC=A02013=A0- HALL 8, Stand C51 - September 13-17

Need a fre= e invite? - use coupon code 4462 and register here:=A0= www.ibc.org/register

3D"Images<= /p>

--047d7b343ff420ef8b04e3bc89cd-- From finlayson@live555.com Mon Aug 12 12:25:32 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B1521F9E63; Mon, 12 Aug 2013 12:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgLcMt2yMicZ; Mon, 12 Aug 2013 12:25:27 -0700 (PDT) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id A67BC21F9E52; Mon, 12 Aug 2013 12:25:27 -0700 (PDT) Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.4/8.14.4) with ESMTP id r7CJPN4B018049; Mon, 12 Aug 2013 12:25:25 -0700 (PDT) (envelope-from finlayson@live555.com) From: Ross Finlayson Content-Type: multipart/alternative; boundary="Apple-Mail=_CE71244D-CC1C-464B-9F6F-FB73421345B7" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Mon, 12 Aug 2013 12:25:23 -0700 References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> <69F25DB2-6926-4ACA-935D-90376A2A7BFA@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D690F@nasanexd02f.na.qualcomm.com> <3879D71E758A7E4AA99A35DD8D41D3D91D4CC65C@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4@nasanexd02f.na.qualcomm.com> To: "avt@ietf.org" , "payload@ietf.org" In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4@nasanexd02f.na.qualcomm.com> X-Mailer: Apple Mail (2.1508) Subject: Re: [payload] [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 19:25:32 -0000 --Apple-Mail=_CE71244D-CC1C-464B-9F6F-FB73421345B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > You just need one more little step to get everything right here, = instead of thinking of compromising the implementation J > =20 > That is, read subclause 7.4.2.4.4 of the HEVC spec. The most relevant = paragraphs are copied below for convenience (the first paragraph itself = contains the answer to your question, but the second paragraph may also = provide helpful information) Thanks for the info; that was useful. Here, then is the updated text of a paragraph - to be added after the = existing 'M bit' text - that clarifies when/how to set it: ---------- Unfortunately the contents of a NAL unit, alone, do not tell a RTP = sender implementation whether or not the NAL unit ends an access unit. = Instead, the implementation may be able to obtain this information = separately, from the encoder. If, however, the implementation cannot = obtain this information directly from the encoder (e.g., because the = implementation is sending data that consists solely of a sequence of = pre-encoded NAL units), then it must instead inspect subsequent NAL = units, to determine whether or not the NAL unit ends an access unit. If = the NAL units have already been timestamped, then these timestamps can = be used to determine the access unit boundaries. Otherwise, the access = unit boundaries (and times) must be determined by inspecting the NAL = units' contents - specifically, the "nal_unit_type" and (for VCL NAL = units) the "first_slice_segment_in_pic_flag". The following rule can be = used: A NAL unit (X) ends an access unit if the next-occurring VCL = NAL unit (Y) has the high-order bit of the first byte after its NAL unit = header equal to 1, and all NAL units, if any, between (X) and (Y) have a = "nal_unit_type" in one of the following ranges: [32,35], 39, [41,44], or = [48,55]. ---------- Ross Finlayson Live Networks, Inc. http://www.live555.com/ --Apple-Mail=_CE71244D-CC1C-464B-9F6F-FB73421345B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
You just need one more = little step to get everything right here, instead of thinking of = compromising the implementation J
 
That is, read subclause = 7.4.2.4.4 of the HEVC spec. The most relevant paragraphs are copied = below for convenience (the first paragraph itself contains the answer to = your question, but the second paragraph may also provide helpful = information)

Thanks = for the info; that was useful.

Here, then is = the updated text of a paragraph - to be added after the existing 'M bit' = text - that clarifies when/how to set = it:
----------
Unfortunately the contents of a = NAL unit, alone, do not tell a RTP sender implementation whether or not = the NAL unit ends an access unit.  Instead, the implementation may = be able to obtain this information separately, from the encoder. =  If, however, the implementation cannot obtain this information = directly from the encoder (e.g., because the implementation is sending = data that consists solely of a sequence of pre-encoded NAL units), then = it must instead inspect subsequent NAL units, to determine whether or = not the NAL unit ends an access unit.  If the NAL units have = already been timestamped, then these timestamps can be used to determine = the access unit boundaries.  Otherwise, the access unit boundaries = (and times) must be determined by inspecting the NAL units' contents - = specifically, the "nal_unit_type" and (for VCL NAL units) the = "first_slice_segment_in_pic_flag".  The following rule can be = used:
 A NAL unit (X) ends an access unit if the = next-occurring VCL NAL unit (Y) has the high-order bit of the first byte = after its NAL unit header equal to 1, and all NAL units, if any, between = (X) and (Y) have a "nal_unit_type" in one of the following ranges: = [32,35], 39, [41,44], or = [48,55].
----------

Ross = Finlayson
Live Networks, Inc.
http://www.live555.com/

= --Apple-Mail=_CE71244D-CC1C-464B-9F6F-FB73421345B7-- From prvs=9291d5a95=HeinzPeter.Reykers@wdr.de Mon Aug 12 13:49:08 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF7521F9D83; Mon, 12 Aug 2013 13:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRU4hMPKSZWg; Mon, 12 Aug 2013 13:49:05 -0700 (PDT) Received: from smtp39.wdr.de (smtp39.wdr.de [149.219.195.39]) by ietfa.amsl.com (Postfix) with ESMTP id D4EBB21F9D7E; Mon, 12 Aug 2013 13:49:03 -0700 (PDT) Message-Id: <520966590200005600077F5A@wdr.de> Date: Mon, 12 Aug 2013 22:48:56 +0200 From: "Heinz Peter Reykers" To: , Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part51620728.2__=" Cc: payload@ietf.org, i-d-announce@ietf.org Subject: [payload] Antw: Re: I-D Action: draft-ietf-payload-rtp-aptx-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 20:49:09 -0000 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part51620728.2__= Content-Type: multipart/alternative; boundary="=__Part51620728.3__=" --=__Part51620728.3__= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hello all, the implementation of the algorithm enhanced apt-X for low delay transmissions in radio is a very important task for codec manufacturers. In german public radio and television landscape a couple of different units already exists, delivered from different codec manufacturers. When they are used for contribution of audio content it is a high priority aim to guaranty the interoperability of these codecs from different manufacturers to each other. This can only be made properly by using the same rfc within the prerequisites and instructions how to implement this algorithm and the belonging signaling. The european broadcasting union EBU created a technical document, putting together all the different rfc's for the mandatory, recommend and optional functions each codec for audio-over-IP use must/should have. Therefore we urgently need this new rfc as an accepted and distributed document, because interoperability between different codecs is very important for the german broadcasters in radio as well as in tv. Kind regards Heinz Peter Reykers ____________________________________ Dipl.-Ing. Heinz Peter Reykers Westdeutscher Rundfunk Köln Programmverbreitung / WAN Audio-Encoding, Kontribution Appellhofplatz 1, 50600 Köln Tel.: +49 (0)221 220 - 4183 Fax: +49 (0)221 220 - 774183 mobil: +49 (0)172 251 3066 e-mail: heinzpeter.reykers@wdr.de Archivhaus 1331 >>> Michel Quaix 12.08.13 17.09 Uhr >>> We, at Digigram, have implemented this draft in our audio codecs. It works and we need it to guaranty the interoperability with codecs from other manufacturers, so I support adopting this draft. Regards, Michel QUAIX Software Group Manager and Solution Specialist, Phone: +33 (0)4 76 52 47 47 DIGIGRAM Innovallée, 82-84 Allée Galilée, 38330 MONTBONNOT SAINT-MARTIN, FRANCE 2013/3/13 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs Author(s) : John Lindsay Hartmut Foerster Filename : draft-ietf-payload-rtp-aptx-00.txt Pages : 22 Date : 2013-03-13 Abstract: This document specifies a scheme for packetizing Standard apt-X, or Enhanced apt-X, encoded audio data into Real-time Transport Protocol (RTP) packets. The document describes a payload format that permits transmission of multiple related audio channels in a single RTP payload, and a means of establishing Standard apt-X and Enhanced apt-X connections through the Session Description Protocol (SDP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-aptx There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-aptx-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ payload mailing list payload@ietf.org https://www.ietf.org/mailman/listinfo/payload Meet the Digigram Team in Amsterdam, IBC 2013 - HALL 8, Stand C51 - September 13-17 Need a free invite? - use coupon code 4462 and register here: www.ibc.org/register --=__Part51620728.3__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Description: HTML

Hello all,


the implementation of the=20 algorithm enhanced apt-X for low delay transmissions in radio is a very=20 important task for codec manufacturers. In german public radio and=20 television landscape a couple of different units already exists,=20 delivered from different codec manufacturers. When they are used for=20 contribution of audio content it is a high priority aim to guaranty the=20 interoperability of these codecs from different manufacturers to each=20 other. This can only be made properly by using the same rfc within the=20 prerequisites and instructions how to implement this algorithm and the=20 belonging signaling. The european broadcasting union EBU created a=20 technical document, putting together all the different rfc's for the=20 mandatory, recommend and optional functions each codec for audio-over-IP use must/should have.


Therefore we urgently = need=20 this new rfc as an accepted and distributed document, because=20 interoperability between different codecs is very important for the = german=20 broadcasters in radio as well as in tv.



Kind regards


Heinz Peter Reykers




__________________________= __________


Dipl.-Ing. Heinz Peter Reykers

Westdeutscher = Rundfunk Köln
Programmverbreitung / WAN
Audio-Encoding, = Kontribution
Appellhofplatz 1, 50600 Köln

Tel.: +49 (0)221 = 220 - 4183
Fax: +49 (0)221 220 - 774183
mobil: +49 (0)172 251 = 3066

e-mail: heinzpeter.reykers@wdr.de

Archivhaus 1331
<= br/>>>> Michel Quaix 12.08.13 17.09 Uhr = >>>
We, = at Digigram, have implemented this draft in our audio codecs. It works and = we need it to guaranty the interoperability with codecs from other = manufacturers, so I support adopting this draft.
Regards,
Michel QUAIX
=
Software Group Manager and Solution Specialist= ,
DIGIGRAM
<= font color=3D"#3333ff">Innovall=E9e, 82-84 All=E9e Galil=E9e,
38330 MONTBONNOT SAINT-MARTIN,
FRANCE


2013/3/13 <internet-drafts@= ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts = directories.
 This draft is a work item of the Audio/Video Transport Payloads = Working Group of the IETF.

        Title           : RTP = Payload Format for Standard apt-X and Enhanced apt-X Codecs
        Author(s)       : John = Lindsay
                    =       Hartmut Foerster
        Filename        : = draft-ietf-payload-rtp-aptx-00.txt
        Pages           : = 22
        Date           =  : 2013-03-13

Abstract:
   This document specifies a scheme for packetizing Standard = apt-X, or
   Enhanced apt-X, encoded audio data into Real-time Transport = Protocol
   (RTP) packets.  The document describes a payload format = that permits
   transmission of multiple related audio channels in a single = RTP
   payload, and a means of establishing Standard apt-X and = Enhanced
   apt-X connections through the Session Description Protocol = (SDP).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-a= ptx

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-payload-rtp-aptx-00=


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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


Meet the Digigram Team in = Amsterdam, IBC 2013 - HALL 8, Stand C51 - September = 13-17

Need a = free invite? - use coupon code 4462 and register here: www.ibc.org/register

3D"Images

 --=__Part51620728.3__=-- --=__Part51620728.2__=-- From harald@alvestrand.no Wed Aug 14 05:28:46 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2915711E815E; Wed, 14 Aug 2013 05:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.311 X-Spam-Level: X-Spam-Status: No, score=-110.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utqmLdKxkT0E; Wed, 14 Aug 2013 05:28:42 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A58EA11E80EC; Wed, 14 Aug 2013 05:28:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id C929E39E4EA; Wed, 14 Aug 2013 14:28:39 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xo6-LjC6i82m; Wed, 14 Aug 2013 14:28:38 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 9912939E1C2; Wed, 14 Aug 2013 14:28:38 +0200 (CEST) Message-ID: <520B77F5.4000800@alvestrand.no> Date: Wed, 14 Aug 2013 14:28:37 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Cullen Jennings References: <51E6A4D9.30003@alvestrand.no> <957DBFE5-900D-44CB-BDE2-FB96BB83B3AE@iii.ca> In-Reply-To: <957DBFE5-900D-44CB-BDE2-FB96BB83B3AE@iii.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: The IESG , payload@ietf.org Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 12:28:46 -0000 On 07/19/2013 10:17 PM, Cullen Jennings wrote: > These can't be optional otherwise a device that is hardware limited can't know that the other side will use them. Thus there is no way to build solutions that interoperate by design instead of luck. A device that has announced a=imageattr:97 recv [x:640,y:480] and a=framerate:60 has stated that max-fr is >= 60 and that max-fs is >= 1200. These parameters were added because people on this list asked for them. So far, I do not think they have been added to any existing implementation, and we don't seem to be seeing many interoperability problems because of that. I don't think this is because of "luck". I think it's because these are not the constraints that are the most constraining in most practical situations - other constraints make sure we never reach the limits that might have been encoded using max-fr and max-fs. > > > > On Jul 17, 2013, at 7:06 AM, Harald Alvestrand wrote: > >> On 07/10/2013 10:28 PM, Stephan Wenger wrote: >>> Hi, >>> I read through the diff file. The main change seems to be to reduce the >>> PartitionID field by one bit, which is now reserved. This is fine. >>> While reading through the diff file (without checking against the main >>> text--too lazy or too busy, take your choice :-), I noticed that max_fr >>> and max_fs are optional, and could not see a default being defined. >> The theory is that there would be external constraints (such as an application-wide configuration, or an out-of-SDP signalling mechanism) that gave the constraints in question. >> >> Quote from 6.2.2: >> >> In many practical applications, the max frame size and >> max frame rate are known from other information; if they are not >> constrained by other means, the max-fs and max-fr parameters MUST be >> used to establish these limits. >> >> We did not see a compelling reason to make non-compliant the present applications that do not use these parameters. >> >> >> >>> Is >>> this prudent? How does a decoding system decide whether it is able to >>> decode a stream without any indication of the complexity of the stream? >>> Start decoding and reject once the header tells you that this stream is >>> beyond your capacity? >>> Stephan >>> >>> On 7.10.2013 08:50 , "internet-drafts@ietf.org" >>> wrote: >>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Audio/Video Transport Payloads Working >>>> Group of the IETF. >>>> >>>> Title : RTP Payload Format for VP8 Video >>>> Author(s) : Patrik Westin >>>> Henrik F Lundin >>>> Michael Glover >>>> Justin Uberti >>>> Frank Galligan >>>> Filename : draft-ietf-payload-vp8-09.txt >>>> Pages : 30 >>>> Date : 2013-07-10 >>>> >>>> Abstract: >>>> This memo describes an RTP payload format for the VP8 video codec. >>>> The payload format has wide applicability, as it supports >>>> applications from low bit-rate peer-to-peer usage, to high bit-rate >>>> video conferences. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-payload-vp8 >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-payload-vp8-09 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-vp8-09 >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> payload mailing list >>>> payload@ietf.org >>>> https://www.ietf.org/mailman/listinfo/payload >>> _______________________________________________ >>> payload mailing list >>> payload@ietf.org >>> https://www.ietf.org/mailman/listinfo/payload >> _______________________________________________ >> payload mailing list >> payload@ietf.org >> https://www.ietf.org/mailman/listinfo/payload From tterribe@xiph.org Wed Aug 14 05:41:27 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB0E11E8170; Wed, 14 Aug 2013 05:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajvVkyqoW8ZK; Wed, 14 Aug 2013 05:41:21 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0D711E8168; Wed, 14 Aug 2013 05:41:17 -0700 (PDT) Received: from [172.17.0.5] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 22C6FF20F0; Wed, 14 Aug 2013 05:41:16 -0700 (PDT) Message-ID: <520B7AEB.9080100@xiph.org> Date: Wed, 14 Aug 2013 05:41:15 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 SeaMonkey/2.16 MIME-Version: 1.0 To: payload@ietf.org References: <51E6A4D9.30003@alvestrand.no> <957DBFE5-900D-44CB-BDE2-FB96BB83B3AE@iii.ca> <520B77F5.4000800@alvestrand.no> In-Reply-To: <520B77F5.4000800@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: The IESG Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 12:41:28 -0000 Harald Alvestrand wrote: > These parameters were added because people on this list asked for them. > So far, I do not think they have been added to any existing > implementation, and we don't seem to be seeing many interoperability > problems because of that. > > I don't think this is because of "luck". I think it's because these are > not the constraints that are the most constraining in most practical > situations - other constraints make sure we never reach the limits that > might have been encoded using max-fr and max-fs. I respectfully disagree. I think it's because implementations on resource-constrained mobile devices are still somewhat immature (ours certainly is). Earlier in this thread I pointed you to where we are adding support for these parameters for precisely this use-case. I thought we had agreement from the Chrome team that they would support them as well (c.f. our WebRTC office hours call on June 10th, where I recall you saying something to the effect of, "If we put them in the spec, then we should support them."). If that is not the plan, then we have a problem. From tterribe@xiph.org Wed Aug 14 05:43:11 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C65D11E8164; Wed, 14 Aug 2013 05:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNxnFfF6U-9b; Wed, 14 Aug 2013 05:42:59 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB9C11E8152; Wed, 14 Aug 2013 05:42:59 -0700 (PDT) Received: from [172.17.0.5] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id B3CA8F20DD; Wed, 14 Aug 2013 05:42:58 -0700 (PDT) Message-ID: <520B7B52.4080909@xiph.org> Date: Wed, 14 Aug 2013 05:42:58 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 SeaMonkey/2.16 MIME-Version: 1.0 To: payload@ietf.org References: <51E6A4D9.30003@alvestrand.no> <957DBFE5-900D-44CB-BDE2-FB96BB83B3AE@iii.ca> <520B77F5.4000800@alvestrand.no> <520B7AEB.9080100@xiph.org> In-Reply-To: <520B7AEB.9080100@xiph.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: The IESG Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2013 12:43:11 -0000 Timothy B. Terriberry wrote: > them as well (c.f. our WebRTC office hours call on June 10th, where I Correction, June 12th. From harald@alvestrand.no Thu Aug 15 07:21:19 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EC421E815B for ; Thu, 15 Aug 2013 07:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YegdbuTwNZ9n for ; Thu, 15 Aug 2013 07:21:13 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6289C21E8158 for ; Thu, 15 Aug 2013 07:21:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B733C39EA6C for ; Thu, 15 Aug 2013 16:21:07 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZD-X-iPO8vO for ; Thu, 15 Aug 2013 16:21:06 +0200 (CEST) Received: from [172.28.249.38] (unknown [74.125.57.89]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id CEF0139E0E1 for ; Thu, 15 Aug 2013 16:21:06 +0200 (CEST) Message-ID: <520CE3D2.1070306@alvestrand.no> Date: Thu, 15 Aug 2013 16:21:06 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: payload@ietf.org References: <51E6A4D9.30003@alvestrand.no> <957DBFE5-900D-44CB-BDE2-FB96BB83B3AE@iii.ca> <520B77F5.4000800@alvestrand.no> <520B7AEB.9080100@xiph.org> In-Reply-To: <520B7AEB.9080100@xiph.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2013 14:21:19 -0000 On 08/14/2013 02:41 PM, Timothy B. Terriberry wrote: > Harald Alvestrand wrote: >> These parameters were added because people on this list asked for them. >> So far, I do not think they have been added to any existing >> implementation, and we don't seem to be seeing many interoperability >> problems because of that. >> >> I don't think this is because of "luck". I think it's because these are >> not the constraints that are the most constraining in most practical >> situations - other constraints make sure we never reach the limits that >> might have been encoded using max-fr and max-fs. > > I respectfully disagree. I think it's because implementations on > resource-constrained mobile devices are still somewhat immature (ours > certainly is). Earlier in this thread I pointed you to where we are > adding support for these parameters for precisely this use-case. I > thought we had agreement from the Chrome team that they would support > them as well (c.f. our WebRTC office hours call on June 10th, where I > recall you saying something to the effect of, "If we put them in the > spec, then we should support them."). If that is not the plan, then we > have a problem. I fully think we should support them in our implementations (as in - parse them and obey the constraints they imply). I just don't think we should, in the spec, mandate sending them. To be specific: The change I think Cullen is suggesting is: == OLD == Required parameters: none Optional parameters: max-fr, max-fs These parameters MAY be used to signal the capabilities of a receiver implementation. These parameters MUST NOT be used for any other purpose. == NEW == Required parameters: max-fr, max-fs These parameters MUST be used to signal the capabilities of a receiver implementation. These parameters MUST NOT be used for any other purpose. Optional parameters: none == END == If that's not the change you're suggesting, Cullen, please clarify. (note: the MUST NOT language means that the parameters are not allowed in a sendonly a=fmtp line, so they should probably be formally optional anyway - either that, or my change proposal is incomplete.) From Lindsay@worldcastsystems.com Wed Aug 21 04:13:25 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39DF611E8187 for ; Wed, 21 Aug 2013 04:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.002 X-Spam-Level: * X-Spam-Status: No, score=1.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8StYP9aiI+EY for ; Wed, 21 Aug 2013 04:13:20 -0700 (PDT) Received: from mailgate.aptcodecs.com (mailgate.aptcodecs.com [217.33.179.85]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2DE11E81C1 for ; Wed, 21 Aug 2013 04:13:19 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01CE9E5F.6FF02282"; type="multipart/alternative" Date: Wed, 21 Aug 2013 12:13:17 +0100 Message-ID: <8C4E0C2409735E4FBC22D754A238F94D02F743D3@APTSBS.apt.local> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: RE: [payload] I-D Action: draft-ietf-payload-rtp-aptx-00.txt thread-index: Ac6eX2+mhoEpwHBVQcSyKXSWrXduCQ== From: "John Lindsay" To: Cc: Foerster@worldcastsystems.com Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-aptx-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 11:13:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CE9E5F.6FF02282 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CE9E5F.6FF02282" ------_=_NextPart_002_01CE9E5F.6FF02282 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi =20 Over the last few months there have been a number of posts to the = payload group in support of the draft RFC. =20 The only issues that have been raised during the last 6 months are from = Hans-Heinrich Hansen on 24th April 2013, however Hans-Heinrich has now = accepted and implemented the draft as is. On 8th August support for the = current format of the draft was expressed by Hans-Heinrich. =20 Hence as there are currently no other outstanding issues we would ask = for anyone with an issue to review and post comments to the group = otherwise can the doc to be moved forward to the publication stage.=20 =20 Once again thanks to all that have taken the time to review and post = thus far. =20 Regards =20 John Lindsay =20 =20 =20 =20 =20 John Lindsay R&D Manager=20 Tel : +44 (0) 28 90 677200 lindsay@worldcastsystems.com =20 APT office: Whiterock Business Park 729 Springfield Road - Belfast - BT12 7FP Tel : 44 (0) 2890 677200 - Fax : 44 (0) 2890 677201=20 Si=E8ge Social: 20, av Neil Armstrong, Parc d'Activit=E9s J.F. Kennedy = = = = = = =20 33700 Bordeaux-M=E9rignac - FRANCE=20 Tel: +33 557 928 928 - Fax: +33 557 928 929=20 =20 =20 ------_=_NextPart_002_01CE9E5F.6FF02282 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

Over the = last few months there have been a number of posts to the payload group = in support of the draft RFC.

 

The only = issues that have been raised during the last 6 months are from = Hans-Heinrich Hansen on 24th April 2013, however = Hans-Heinrich has now accepted and implemented the draft as is. On = 8th August support for the current format of the draft was = expressed by Hans-Heinrich.

 

Hence as = there are currently no other outstanding issues we would ask for anyone = with an issue to review and post comments to the group otherwise can the = doc to be moved forward to the publication stage.

 

Once again = thanks to all that have taken the time to review and post thus = far.

 

Regards

 

John = Lindsay

 

3DAPT

3D"Worldcast

3DEcreso

3DAudemat

Tel : +44 (0) 28 90 677200

lindsay@worldcastsystems.com =

John Lindsay

R&D Manager

APT office:
Whiterock Business Park
729 Springfield Road - = Belfast - BT12 7FP
Tel : 44 (0) 2890 677200 - Fax : 44 (0) 2890 = 677201

Si=E8ge Social:
20, av Neil Armstrong, Parc d'Activit=E9s J.F. = Kennedy= = =  
33700 Bordeaux-M=E9rignac - FRANCE
Tel: +33 557 928 = 928 - Fax: +33 557 928 929

 =



=

 

------_=_NextPart_002_01CE9E5F.6FF02282-- ------_=_NextPart_001_01CE9E5F.6FF02282 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoKDBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxsc Hx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8f/8AAEQgAPgD5AwERAAIRAQMRAf/EAKwAAAEEAwEAAAAAAAAAAAAA AAQCAwUGAAEHCAEAAgMBAQEAAAAAAAAAAAAAAQIAAwQFBgcQAAIBAgQCBQgIBQIFBQAAAAECAwQF ABESBiExQZEiEwdRYXGB0TJSFKGxQpIjUxUIwWJyMxbhgvCi4kOTJDQmFxgRAAEDAgQDBgUEAgEF AAAAAAEAEQIDBCExURJhExRBcZEiMgXwgaHB0bFSciThQmKCkiMzNP/aAAwDAQACEQMRAD8Ao11r Yg+RnhbIfYbP+Jx7wlfOrakWykoqS6oi6UIcj4eH1jA3LZG2JzU/tHYW+t5kyWW2a6QNpe4VDiOB SOY1sO0R0hATjJXvYUvUcV0Lf22U8sl063/tVukkStctxRQykdqOmp2kUHzO7xZ/dxzpe9Dsj9V0 Y+0gZlZXftcvVNEzWu+QVcg5RVETwA/7lab6sGHvUf8AaJVVX2cnKX0XOd0bN3htZtN6tclPCTpS rU95Ax6MpUBX1HI+bHUoXdOr6SuTce3zpHzZKuJW9vM5cPT7MXus5pYIgXBT9pQfQfbguquQliv4 f3Bl5l/6sR0po8PjwTclcx/7jepR7TiOmFEaIeSdyOch+6P4YCtjAcEM8jn7Mh9LAYiuERwTBd8+ MRPpc4CtYa/RYJCOcKD+ok4CBjxKcWpGXKIerEdKafekipaQ5KyKnSQp44DpzTERi7opJJGyGs5D +TIAdWC6zmIHZ9U7rYkKHZh08NIwJFNTiM2CNg4eXrGFdPKKOicAcGPpBwCoIoqJgB9o+vhhCroh FxOOgkehc8ISrQEQpz6foxVJXRwRcBIPHPFTq1SVNIVOfRiOoYupKGTMAg4BKAipCCQHLjhCUdqP hYcO0OrCFOAj4SPLhCmCMiPDhxxWU4RkLN5cIVaIojUcKiwXj6pliZv7in/YQceoK81TiR2fVNUc 9thrYpa6JaqljbVJTKSneZcQhcZlQx5kccuWK6jthmtlEYuQWVuqPFfxMvrxWqz1T0dMF7uks9lj eBEQckRYgZSB52OMUbSjDEseMlulcVZYBx3BS1BYf3HUOVbTQ3xBlqINRKzEeeJ3Yn0FcVmpanA7 EwhcDEGXx81aNt/uN3tYbglt3tbTUxpkJmZPla1B8WhgiP6Ml9OKqvtlOYemW+oRp384Fqg+mK79 Zb5tjeVh+aoZIbla6pdE0TgOAcuMcsbZ5MOkEY4tSnOlJjgQupCcZxcYgrgnjB4IiwJNuHbau1nB 1VlCO21MCffQ8zF5c+K+jl3fb/cd/kn6uw6rh+4e37RvgMO0LkKyH8x/Uhx2FwzHgPFTFBtvcFws tdeqSCWa227hW1GarozAPutk7c/sg4qlXhGQiT5irIWs5RMhEbRxH5TSbav8+3p9xR00z2amkEM1 XmgCyEqNOk5PzdejENeAnsfzJ4209m9ht1+ChqjbV9i27HuOSjkFlllNPHWF0CmUEjTpz1/ZPRic 6G/Y/mVot57N7eVQDzRdIX1scWEoxgexDtNHnw7oekk/wxUZjUK8UpaSShUxge9F6lJxN41CHIlo VLx7Y3JPtuXcqU3/AMfilFPJWgIB3pIGnTq182HHTirnxM9j49ys6eUY7m+qjo5DyBIy8gyxe6yy Cmtt7dv+47g1usdK9dWLGZmiDIp0KQC2blRzYdOKqtaNMPIsEaVvKoWiMVIbc2Tu3cT1C2W1zVvy jaah1KKiN8JZ2Vc/MDiutc04NuLOrqVtUk+0ZKwr4OeJyqWbb8xAGeXeQE8PMJMZ+uo6q/o6un6K vETU8rwTx9zNExSSOTNWVlORVgeRBxpE3yWYwbNFQyA5dpSfTiGRUiyLRyMu1liqUirQAiopM/tA 4qMirQApypsl2t1PR1NbAYYK9O9pHJU60yBzGkkjgw54oFQSJAOStNMgAkZrcXDlgkqBGU7NmPJh NysIClqXIj/XDAqsqRgAz/1xCi6koVXIfVhCoCjIVPDFZVgKPiQcM+vCFEST/djy4VNvK8dtESeA kI8zq+PTBedEu7wQdSFBIVHZvIdIxJHgtFPvCum2/ETdNqgis2x6EW6okUCaeCmWruFU/NmeRlfs 5+6iKAo8vPGCpawkd1Q/gLpRuZemmPyrfTeMHj3tVVrNwWyqrbcDnIK+hanGXmmRI9J9OfoxknaW 8/QceBWiNetH1jBdYsN88N/GrbkkNbRL87TqPmKObIVdKzcBJDKOJXPkw4H7Q6Mc+UattJwtYMKs WzXGpG3X4GeISoNVXYqvtAghY6ylByOa8lmiz6/5Tjq7o3dPJpD6H8LnbZW083iV6pttwtt6tMFd SOtTb6+ESRtwKvHIvIj0HIjHn5RMJMcCF1wQQ/YvIfjDsr/Dd5TUdPFILTWL81bpC4ACMe3H5fw2 4ejLHqLG6NWGOYzXmr+15c8GY8FZ/D2bLwO38yqTpZOBfnmidPRjPdn+zTWuyj/Xn8/0WrLKv/5k 3A4XPK6J2c8+PeU3Tg1P/sj/AB/KkI/1COP3CVDDDXft527TTrpiqdwpC6gZnS80qnLLzHCGTXUj /wAFfTg9vEcfunPF3d1Lsjdv+OWLblkWgpqWF1M9ujnkLOCSS5IzxXZ0OdDdKUndPc3EqUmiAzLN z7f25uO3+Ft5ktFPQ1O4a2OluyW+JaaOSMyKpzReXI8efH0YSFSVM1IgkiOTq4wExElnSd+eI9p2 l4h1+3/8OstXt+gCQ/LfKQxzurwK2ffENl2n+Dl14ahbmpSEt0tx4qmtc7J7WG1Jasoan9t98qaK lNBQy3wtTUZl7zuo2miKx95kMwo4csGDi5i+e1LUY25I1+6A8LorPbPCnd28mtdJcbvbpo4KU16C oiVW7ocEPDnKT1YN5UlKrGDkR4FJZwEacpM8lavATxGrdx72loJrTaKFFopZRNb6NaeXNXjGkuGP Z7XEYzXtERg4JOPaVdaXEpyYgZKKsk0sXgBu6SJzC5vOkuhKnIyU4yzBGL5l7iH8fyqnahP+R/Vc 823d9yU15pZrNU1DXRG/9KkRaZyxBBAjOsNwz4ZY21IxMSJZLn060t3lJJ8Vftk2fd9xvl73NWyU FNJQ6heJ77CDCJJACQ0IC6WAUHPhl68Y69SEYiAfHLatdCMzKUywbPcui7O/Sr5dGtlxqtrXammh k1UtspjHUZjLtBj0Dp6cYqxlEON4PErXRImWJhIcB/kqH2fFtqi2zcIqc22mvkVfLEau9xF4WgSU qgRyMvdGXA8888PW3SkMzFuxJR2xgcgXOfel3yzXm92CsaiqNvVkdCBUVK2iPROFUE+9lyyBOXTl iQlGMg4kH1UmJTiWMS2iL3xJaF2VtdauGWStegX5GVHCxoRHFqMin3s+jC0BLfJsnTV5R2RfNsFQ YVLZeTGsrKCyPhHrwqYFSNMMsujDBAqTgYcM+eCoyPgJJHlwpTKShYAefy4QqAIuI4rKsCezwqZl 5ANPIznSI2A+JcvqOPT7V5reAMXUXWwyI2oaUB48QcvrxXOJ7GC20pAqzbCuG/paxLBs6V4a+ubN 2o27mWQKM/xJ+DLGg45agvrxmrQgBuqMQFsozmSIwwXVE3j41eF9RTvvmE3nbFY4inkklWpK6h2g sx7QbTnksnZbjl5ccw06Nf8A9bRkF0RKpT9XmCVv6w0WwrzY/FbYWRsNdIhrqSJvwdFQNXYX7Mcy 5jT9hssugBbeZqxNKfqRqRECJjLtXRPHaw0G6fCuoulPlJJQRpdLfMACTHkC49DRMT1Yz2EzCsBr gnuoCVMqF/a9uOet2tX2OdixtUyyU2fRDUgtpHmWRGPrxo94pNMSH+32Wb22rugY/tW/3S2WGo2d b7xp/HttYE1gZnuqhSGH30TC+0zaoRqE3uMHpvoVw3YW/N3WCStorJTi409wQfOWyWlNTE4UZBjG vHkcj0Hpx2LmhTmQZliMuxcy1q1IAiAceKts3i54lUtrmpG2fQw2knvZ4GtMqU5IyOt0zCcNI4nG Y2lB33l/5LWK9dm2DwKpO7fFzcu5rdRWyVaSgttBL8xT0lti+WjEozyfIFuK6jlli6jbU4EkEyJ1 KrncVJBjgylKjx+3XXGJrnaLHcqmNBH85W0CzTMq8tTFvqGKI2UHYGUfmrjdyZyAVEX/AMYN2Xe7 WKvqRR06bcmWe1UNND3NKkiMrcUBzI7AGWfLllgdJCLg/wC3FE3UizBQe6b7fN23m4bmr4F7yd4/ m5qeNhAjaAiDMltOoR8Mzxw9OAiBELPUlKZMmUrtHxV3NtezVVloko7haKqQTTUNwgWphEnAFgpI 56R1Yqq28Zl+0aKylXlAMjrN4zbmt1bdXpKW1x0V57s1tm+UQ0JaJAgdYNXZJA7XHI9OKumjJnJw 4pzczDsBipmm8c90UkcwttustonqIzEauhoUgmCn4WDfWMWCxgcyW4lUzvqgyA8ELs3xIv8Atm3V dupPlau217iSoo6+ITxM4yGrIleJyGfoxpq2kKhBOY0WOneVKYIAcHUKx0PjJfqaVaijs9jpp0z7 ueCgVHUkZEqyvwxSbCBwMpeKtj7hVzER/wBpQth8SdzWqquc6TQVv6y5kuUFZGs0crnPtaQVy4HL LllhqtpAgdm3JlKN3UBJz3ZuFN0ni5uGn1tQW+02+eRCnzNLRrHIoPkIb68Z+jicyT81oF3UGQA+ Sa2/4gX6z2yS1qtNXUEshmMFbEJwJGObMMyOZ48enD1baJL5HglpV5xDM44hSr+JN8mt9TRU9PQW 6KsTu6h6OnELshBBGYJ6CejCi0i7kktqU0rqbMwD6BE2vf8Ae4rbTW6ano66lpF0U3zcAlZV5ZA5 jo4YBtYkuHD6Ii6lGIGBZRiKXZm0hcyTpHADM55DzYv2LPvRUcZ4YQwVgkjYRkPL5jgMnBRkOeY8 v0YUqwKUp2AGXAnpIwpQZStDR1NScoInk8pUZgek8hiqcgM08Yk5KVjt0MP/ALqqSNumKP8AEf8A 5eH04pMycgrdjZlOabV8c/3U9uB5uCnl4rx1Gcy2sH+U49YvKy4LJIi0Y1jNc82GQPDERjLHBW3w Z3da9p7/AKeuuI7u3zRSUs9QF4RCXIq5AGeQZRnl0Yw+4UDUpERzzXU9vrCE3kc8F3Dx13rsybw1 r6KO4UlfVXIRLb4IJI52LCRX7zJS2lVCnterHF9vt6nOBYgDNdi7qw5ZxzVP75of2q6Ln70z93b1 ccSPndUekf0qxHmxrb+75fn4LOT/AFcfjHBdFvkrWjwFkWt7M0dhjpmVhke9lp1iVcj06mAxgpDd dYfv+61VfLQL/t+y55+1SGc3DcU2R7lYqaMno1FpCPoGOh70cIjvWD2geo9yuf7krhDS+HYgcBpK ysgjjTp7GqQnqTGP2mL1n0C0+5n/AMJGq434e11c1gu1tgSnnWeeCZ6Ja79Mrm0KwDxzNlHJGufa Q58cjljsXcRvEjhhm24Ll2UzsMRjjlu2lWK20V0iuVLI1LX2mNZUL3IbkpH7hdXGRo5BocKOJU8+ WM85RMTiJcNhWuEZOHEo8d7qj2B7ZV7jvO1qqSKqob/PJBQ3QQqmitWVjSVKhV7KSMdLqOGlvNjV ViYwjMBjHMcO0KijMSnKBLiRz49hS7/Db7PX2TaMcdLKLTUxzX+pkA7qavkZe+ieQKW7inT8Lh/M csCkDMSqY+YYd35OalaYgY0x2HHvXRCvf3kx1kC0lrEzZyTz2KqtkcQJI1RCKCVqfLoVg+nlxxzp RG3U903++K6cZHdi7f8AS35VI8Pb1c02hua0WKopYrtJV0lTSQyilRJIkMiTmM1Q0NpBTgTnly6c bLinHfGUh5WOv2WK3nIRlGJ8z4fBTFpppv8A7Et0u9XtlTJLSTtFAJKMRLOsMgpEqDErUyMZdJGs EctWK6uNIimCIvx+fFXUsKgNQvNvBWCSOR7XdE3Ba4o6L5Co7uatr7ROEqO7JgMKUVNHP3veZBdD ZeXhiiMPMNub9gl91fOo0Tvybtb7KuNdJtv7O2ytiemgrq+OqnvEyxwTVBlWoMcSSNIjsiLEoKrw 5541ihvnLcMmbTJYZ3QpwiQc3dTFz3ddodvbfq6CSkguddHUteJ6empRNK8M5jhM2UZy/DHkGfPC 07QGUgRgGbEpanuAEYl/U74aImGalrrlsq51cNBLXVBlF0E3dwQymKoZYTVBFKqWTLtFOPDPCmkQ JgOwy8OxOLuBNMk+p/gq2rHVyw1a3GOWlpRTznVXzWippcxE2lWSnSGbMtloKHMHI4zbRg2J4bn+ q083VwOO1vpiuWwUz6VOno6eeOiaa5wuo8UdDTPwyXA5aPUxRsFM+fEcMAQUlXBGClKfMZAjhhis 7KQiQkZgYQohFRrl0erCFWxRdHR1VVMI6eF5pDyVFLH6MVTkBmtMATkpyKxpTZfqFXFSHpiT8eb7 icF/3HFBqP6Q6uFP9xZGQ1dqp+FHRGocf9+rOfHzRJkvWTisxkcz4KwSiMh4oh7rcKgBZZmEfRCu SRj0KuQwBTiFDMlGUdFVzLnHC7L8WWS9Z4YWUwO1AUzoi/0us+Ff/IntwnMCblleaBteYDID6Meo 5oXkeRLVK/xeU81+jE5oS8iWqZm2lIcyVz9WBzQrYUpaqQ23syztWD9Qt9dcSpzWiotCCQeR3Opw PLpHrxRWrSbymMeJW6hSi/mEpcAutLty4X6st1dvRKbb207Jpa2bf1qNRQZJ3gPRkPTlwA4k45PN jTBjSedSWcl1dk5kSqtCnHKP5UH4t7qrt4yQWSzxyfpEUgbPSe8qZuSZJzCrn2RzJ4+TGiwthR88 vV+iy390a3kh6f1XSfCXYa7N2qKacD9RrHNTXt5GIyWPPyIo688cu/uedUcekZLq2NuaVMA+rtXL PGe8vuu+RUdG2q1WvUsUg4iWZsu8cfyjLSvrx1/baPKg59UlxvdKxqy2x9MfqVUrV4dPX08szOsZ XWkSlGOqRUDDUwBVF7Q5+rG2pdCJZlgo2cpgnc2neiarwoqEbuBLHUVDHKAJ7r5jgvEe8WBAwgvQ cWYKw+3zjgJPLsRll2Vedv53SguFNTNKjxtUrF3ssMfa/EizRmRm7vIMna488V1K8KnlMT+VbTo1 aI3CQ72dhwQE3hjI1ma701QkyRTmCuDKyEMzdl4nfITKy8Tl2h0jFouwJ7SGww/zos0rOZhvEnxY /kaoau8LylQ0K1UZYzfLwM8MsZlYEBtOa8ANXPp6MQXYIduzgrhZSBbd2sMCPj7pM/hTPFKKZqqB 3cqYQFkKup05tmFIXTrHA88J1YIdirxaSiWcY/HyWSeFncSSJPWQxqimRX7uVtaIgkcgKp5Bh6cT q3yCPSGOcv1Sx4ZxQIk80w7tZhHKIoXdgmYzkU5Acm4K2ROALlywCadqwclStZ4WzUFxakmnhWLu 0mjqdL9pJGCR6ogO8RiWGasOGBG9EouAqZWJjJifn/hLj8OWAaSKaOReIjZUkGp11alOa9nLuzxb gcTqxop0Wh/VGJ4fKFkbv0YKrHUkcjaijaGXTp1Z6unlgdXwU6EY4/T5Jf8AgKwgSSSxRrlkWKOM n4dn3eI4+8OGB1boixEccB8vjxQ8dgb4cMaiApIyKxHL3cKaiPLRKWNvhwpqJxTRlLt2eVtMUTSN 5FBP1YrlVAzVkaZOSk4ts91xqZ44PKg/Ek+6mf0nFRr6B1dG3fMoqKitsP8AbpWqZPzKhsl/8cf8 WxWZyOZbuV/LjHIP3owJd6qPuItQh6Yade7jHpVAB14TyxxRG6XclQ7e0f35YofKuet/upqwDW0T cvVGxUFsi5pLUt0asok+jU2EMpHgmAiOKLiklj4U8EVOOhkUM33n1HCEPmXT7tME+KauqDm5ll85 JI9mA4CjEpf6XP8AlHA5gR2FUcbTPwfRjodQuf0wW/8AFD8H0YnUIdMFh2mfg+jB6hDpgmztA58F ywOoTCgi6PZtC7A1UzxH+WLvDl6dQ+rCyuZDJMLaJzVmtFFteyHvqOklqa0DITyKAw/pzyC+oYyV ZVKmBLBaqUaVPEAkoe/XK93WJqYD5Wjfg8aZlnHkZ/J5gMNRpwgXzKFWrKYbIKtDaC9CZegY19Qs nThOJtOQAquYB95RwBy8oxOoS9MlHasrHU+ZPlPE8PPidQEpt1o7XbSF46ByXoGfmxOoQ6ZKl25P LDFBIzNDDn3UZPZXUc20jkMzzwBXALpunJAHYEy+1S2ROZI5E8csHqE3TlJ/xMltTZlviJJPXic8 JuQUo7T1Els2J5k5k4HPU5JT1Pth4XWSMsrqwZSDyZTmp9RwDXBR5RTr7ZeSRpJM3kkOp3YksxPH Mk88DngIcgnFKTbLKCACAeBAJ4+nA56PIKcTbhBzAI9GfTgGuiKBTq7cZshpLZcBzPDA54R5BTyb XI95Qv8AUQMKbhNyCn027Tr7zFvMi/xb2YBrlHkBER2eJf7VMpPxPm56uC/RhTV1KYU9AnWtVS66 ZJNKfl55L91fZheYBkm5cjmsSx0689TnyKAo6zn9WAapVggAiI7YF/s06hviI1n/AJuH0YUz4qCL 9ica1VUgylchRyVmyH3R7MLzAMk5iTmlpaIF958/Mi/xOWIahQ2BPpQ0y8oS39bfwXLC7jqjtGid WJ19xEj/AKVGfWczgOjilGGV/fZm8xJwHCjErPlB5MTcptSNFs/MXqPswXko0dVmi2fmL1H2YjyU aOqzRbPzF6j7MR5INHVYUtf5i9R9mI8kWjqs0Wz8xeo+zEeSDR1WaLZ+YvUfZiPJRo6rNFs/MXqP sxHko0dVmi2fmL1H2YjyUaOq3ot35g6j7MR5KNHVKCUH5g6j7MR5ItHVYUt3TIvrH+mA8lGjqklL X8a9R9mC8lGitaLV+YvUfZiPJFo6rNFq/MHUfZiPJRo6rNFr/MXqPsxHko0dUoJbfzB1H2YDyUaO q3otvxjqPsxHko0VsLbviXqOJ5kWilqlD0OnVgPJFgtlKXLi/D0HL6sByowWgtB0MPp9mD5kGilq tJ0MvVgYosFsrT9L8PQcByiwWAUnxD6cTFDypain6GX/AI9OBimDLZVOljl68sRTBaC03xDqwcUM FsCn+LAxRwSh3HlH04GKOCUBF0EYmKOC2AvQerARW+Hn+nEUX//Z ------_=_NextPart_001_01CE9E5F.6FF02282 Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.jpg Content-Location: image002.jpg /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoKDBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxsc Hx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8f/8AAEQgAGQBlAwERAAIRAQMRAf/EAHkAAAMAAwEBAAAAAAAAAAAA AAADBAIFBgEHAQEBAQEBAQAAAAAAAAAAAAACAAEDBQQQAAICAQIFAgUFAQAAAAAAAAECAwQAERIh MRMFBkFxUSJCFAdhMmIjMyURAQEAAgEEAwAAAAAAAAAAAAABEQIDITESE0FRBP/aAAwDAQACEQMR AD8A+6QMfjnoV8PjFsTHBWyRXGcFbhSmGlDkwU4euGnDVw04yzGjJDJDJDJDJOLiTTPQrz5ssiAw UpaqiwU1KYa2HpgpxprfnfjNC59pdnmrSCZa3UlrWUh6rttUdYx9L5mPA7tMU4trMxezWXFeXPyP 4dRlux2Lr/8ANcxX5Y61mWKF1ALLJLHG0aldePzcMycG1+O7fdrM9eymp5t2a15VL42jgXFqQ3YJ CybJ45tx/qGu5iqpqeHLMvFZr5FOWXbx+cN400KxtK0irGmu9yQFG06HU/pnLDo9aSNWVWYKz8FB OhPtkmWSGSGScVEc9CvPi2FS3IE+3HBTi2KFxz4e+c7SxVCqB9Qw2lIcmg9cNOPnsf4O7BvjWS/Y mrR2Rb2PFWM7MsvVCNa6fWK7v5cuGd7+rb6cZ+bX7VR/i/uk8XklO136Wv2ryG/ZtS0qsUJ1hsBQ VaSaN3D6Lodp0w3nkxZOusKcFvlLem1b6LwWCp5DD3rtvcJ6brWr0bNYLFLHNBVJ6akyIzodGIJV hnO82dcWOvqxtmVd3XxuLuECQPLpGJJXkDIH1Ezbjt1I2sPpb0wa74dLCqnikcFmad7TydWYzbSD yLFiGJZtdd2hI04embd1hgviIWSjJ99KzU3Z2ZgSz6spXkwAKqiprodRl7GeLcdu7dWoVlggUAAD eRw3MFCliPidvHBbkpFOYnEwcxnoV8F7t/D/AI5897u5Y/dic6cnphpQ9MFOHrhpw1cNOMsxoyQy QyQyQyT/2Q== ------_=_NextPart_001_01CE9E5F.6FF02282 Content-Type: image/jpeg; name="image003.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image003.jpg Content-Location: image003.jpg /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoKDBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxsc Hx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8f/8AAEQgADgBlAwERAAIRAQMRAf/EAIwAAAMAAgMAAAAAAAAAAAAA AAECBAMFAAYHAQADAQEBAAAAAAAAAAAAAAABAgQDAAUQAAEDAgQDBQgDAAAAAAAAAAIBEQMSEwAh BBQxQSJhMgUVFlGRocFCUiMGgdFiEQABAwIEBQMDBQEAAAAAAAABABECIRIxQaETUSIDBBTB0QVh cTLwkbFCotL/2gAMAwEAAhEDEQA/APfY9Y2UMQQp2JUXvXFxhxUN/ALMBmauRKXbgMucrFr/ABPZ WBGO4eoNQFHVERhUlVaRMuXJMef33e7NoZzIto+QJ0VnZ9pvXVYRH6zH8oafxzVSyxQBolGeUpEC 4SgCjEgqpCqhUr1t3cRw+SnMiIhzEyxLBotUUfPgq5dhGIMjPlDYBzV6YtlxVReK60Z49KGljk1R hJKoDN0IMaiLVKHeVS4Nh5951BIQEQZkE/lSjZtjVCPawtMjIiLgfjx+j4LFL+0TBNqY4tCUpaUh A40UlMjUUJRGgDDKpsyTE0/lJCUgIE20zd2ejAjVbw+PBAJk137akHRUxfsq7pY5tPt4BmsLLKpo rvSi5RrH1Lw68MPkedpRtjczl/8Alv8ASB7HlcG4s9G930RD9knWKDVFo0HRajUppQO68iKsixoS hS3FPuwB8hJhIx5JStxri2DeqY9kHMbuYRuwpg+L+i20mshjUK6vyGoCwqWYuqqrOyZccXy6oDPm VGOmTgkXxTRCYgRqhn3QUSRVfgyNzwvkQdnqm2Js64niejUlBDVTT6UEn9zY7yIOzrtiWKIeI6Y5 QiGtSkRx6C4ZK65ZJnzwR14kgB6/QoHoyAf1VONlkupRR6MUT8yyL7AFk95f1i4k8FAw4qmMo36Q /klzwpRBGSGu8vtBv7SR1fjrbvMvd7WxF3eww3WZ6PxVXbbznbd82SH6f20F6zYctvUzP9VL/HEv U8SyN1ttbfVlVDyby112fo6q8N8kri2ViumS1bpempLjN/pqu3Ddv47jbtdizcH5tcUvW32N92Tv 9qaYJpfTvmC3bG+qGrhXXlS7c+GM+p425W3ccfd8lrDf26XWaIr6U3q17bdXep6XvPz5VVfHGcvE vrZe/wDr3WkfJs/ta2nsjF6S3w29ru7q0NS911duVT4EfEvpZe+vujLybK3WtotlqNjQN+mitaX+ 7N/m+LepY3NxU0L3olk8u3Edyi+w2n4tnS3ywstu4OzoxvtLYJQ8r3PTbvure1+bfPAG1dRrkTuW 5smLy67G9Fxxttx4dPDBO24wdAXseCqxusV//9k= ------_=_NextPart_001_01CE9E5F.6FF02282 Content-Type: image/jpeg; name="image004.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image004.jpg Content-Location: image004.jpg /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoKDBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxsc Hx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8f/8AAEQgAGABlAwERAAIRAQMRAf/EAHQAAAMBAQEBAAAAAAAAAAAA AAABAwQCBQgBAQEBAQAAAAAAAAAAAAAAAAABAgQQAAIBBAAEBAQGAwAAAAAAAAECAwAREgQhMRMF QVEiBnGBYhRhkbEyUhaCIzMRAQEBAQEBAQAAAAAAAAAAAAABERITAjH/2gAMAwEAAhEDEQA/APoB I55Td2dz5m5rt2Rw2WuNvbh0ColRiWBNgU5D8GZam6n4tod00tvPoliEiScki3okBI+fpNZrUTHu PUaCSXWgn2OlCs74qAFDpmoYk8OHlepjU+lP7V26JCZEkyjijmnC4kIJEEgHqZS3A+ArPNa7i590 aAlWOOHYmykECOiDFpSnUwGTLxxNZ4rXcWPujtq6sGyqu8c6sygYKwwOJDK7qeY8KzxWvSZqnbfc Or3De+3gU9NtePZhlIPqWQsCCLekrj4ml+MjXz9y16LbOuqhnkVFJIBYheI4HnWMb0fda3D/AHJx BYeochzPwq4ml95q5KnWTJgWUZDiBzI86Yaa7GuxVVlRi4uoDAkgeVTF1Sg8oROeZJro2ObKybXt /U2tj7hy6TFOmzRsVuoJIB/OnaeYX2zoLYQmaACJYT0pGXJEviG8+ZrPbXnHX9W7diyxmaCOSNYZ UikZVdEXFQ3+PCp2vnFG9sdsM/XQSRPiikI3pIiGK3BvyAtU7q+caB2PQ6wlxbMbJ3B6j/1KYX+F vCp1WuIzj2l2lQnT6sRVDHkkhBKF2exv9TmnpTyjTrdg7fqzQy63UhMEawhUdsWRL4hwf3WyNS/d qz4k/GqXR15UKOCVKuvPwkN2/SprWJP2rVZ2Y5Wds2S/Atcm/L6jTo5M9s1iWILLnnmAeYkNyD86 aY719GGBmcXeRyC7vYkkX48h/I8qWkjRUVPpDyFXWcPCmmHgaauHjQwWqKdqAoCgKAoCgKAoP//Z ------_=_NextPart_001_01CE9E5F.6FF02282 Content-Type: image/png; name="image005.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image005.png Content-Location: image005.png iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ bWFnZVJlYWR5ccllPAAABGBJREFUeNqkVUtvW0UU/u6943v9iFM7aRJStVZLZXDLq3SBykttJZQF CxAqYtlKFUuksmEBf4B1pC6R2LCpxIYNYtNHhAQVCBJB6UNJhWgCeTROXCe+9n3MDOfMvTZNiJtK Hcn2Hd+Z7/vOOd+ZsV555zNohVPjo3snx58aripFsycYtm3Zi0v12cWV+gXL0teEVOrk8eeOXD39 6jHAcvCE+CB8QMsXr/wwc3X6j1unxN5y+eKhAxVM/foXluvNZMHjDGvnv5VSGBsexNOVCuYXly4K 183V5hYaqDdbcISNx4RHO5DodCLodK7pIZ/NIJcTWFptIgolGFsEsQ42/EAImyQp3dvQb5BA+EGE 6sEynj00BDuNJJt1cHO2jltz68jRM2GCsQVviJWkQu+eezIA2qRs4rUKPni7hv1jRGB3Y3Zx6dtp /DjzNzyvYITwRyiKrTt51ODIOoHC0cMlnD/zEoZKwyYvTJq4hzEcxFJDKguWSYgmAlIvtdzVPVpb RBLj3beqBpyLSZbcYgpOTawZLyYP2GBssikxyv+U9E+PMsY5XtvfU9xpR5j86jrm7tWRz7tYXWuh NJBFHGt6z5Hoboq0CedRgxfnswL5XC5NmI1/VjZw6bvfkHEc2I4FzxXwMk6ClWIKTerNvE8ErLzp R5CxwmoDcGwnJbDQ6oRYXvUxPlIkoySqhZPgJP1Gc5jca4RS/a8HVFrdTz982UwkKeGNnAIG2jda wOcfn6CoXBQpRZd/WsCV6wsoFFwSwgyKCAiBap5EsK07FZFqQjwzcaLnpSiKKWISRAUsDeZx9r03 e629vKbxzeW71GwZg8nrBQdgM4GM6cHZSmDqo6CiEJKXE6F8qFZSSjhObKJ0vSxCIjfriZwxGTuJ gBZEMmXb1lj80jQi2VTSr5UWnC1qkdnjSJnfhJAEmXQnmCYCrjCni5XZettRYSVgb5z7ElGckE19 cc78nyNH/XJjEe9/8jVGyoVkORGVSwXaowwmTKMhAaVzA8rRO/Ywg3etrC1lSJVmO0oElLbYnGHa nEvcYByBNiYhgqjtI2w/gL+5Bs+xdzzsLFMPyq3mlEhTZBlLKniEkPYF2dDUQadrmTTMkzDCFvtq NVSqL8C+34Dr9D+sVdorWsUmgrij4eULOHJyAiN7Mni4T0PqmcOjJXizv0O06R5o0UWzvgsB159T FBuXUASkNQwCNO6vQwTulsgjIvCFA8YW5EyvSJeETQ+aiuT0uam0lRRNkTWT8wtJMUkUf7oRUPph CwtFMgFjC7/VvO3Z8fOVoQHMr2+a8PpdNFy6gFTzWRyFlGeqg083mx/K3jpB9jlQHoBrR2Bs0Wqs fXRj9s61Y7WjODg0hrZU2KGp0T2qioNFozZH1+tY2cHrz4yjVBC9OyNP6h06rmdu3wRjU4rsqaV7 d09/36xPFgt7qsZdlrXDfZB8/TzdNvbzKMfzKz7+vDOHYsFNzW6sZG+0HsxuNhoXBGH/K8AAwZyc 9z1avW8AAAAASUVORK5CYII= ------_=_NextPart_001_01CE9E5F.6FF02282 Content-Type: image/png; name="image006.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image006.png Content-Location: image006.png iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ bWFnZVJlYWR5ccllPAAABGBJREFUeNqsVltvG0UU/nZnvOtk7TipXQROoRBIKFIVgcqlAom2CMTl B/AOqA9ISH1GiB+AeECVKiSeeaJISEg8oLaiLa8VkVoFNSWkF5KAolwc79qxvbszwzmzjmOnQQqF tcbrnZ35zjnf+c4ZO59cnIEj3JOHS8Wzh8ZGJo2Bxn+4HAfuYi2cX643ziSpuiJTbU6cmhi//MZE BS7+n8s8UZm+cHvt8k/zf5yU46XiuZcOVbDW0mglanAhfaxX9Pk317Dn4EXCvLW6fk6Wg/yRVpKi maodGMINhgRG/RxSetxoJEhSjf3aqbdoPxmpBMNHpOs4nbZWUhvT8zqfk5i9t4nvfr6LwpDEe29N wfMElDL7TATQ1ikYW2rKKWMnKsstTSJOU5z+8hruLobgl3+GMT7/4BjWo86+yZKuAGPLONFItEHa jUA49Jt4WYZA+WgV4VaCG7WYBEDztG4vC3sZZUzGlolSFDp64WsKRLgOSsU8JG31hItKOcCYJxGX 7gdjv5rthEY6IAblMCsKMlWUQKPtyCjKjHiUB5c2jwYefr9Xx8sfX8DuFPBjkhq8//aTePO5Kppx 2nsnCI+xqQ7oR3dYA/YlkCPP+e5KBx2Tw0J0Pz2ULsRExaffL+D5p8vwaW03lT1MGauUJjV5p3sh a0PlSAZAdwb18x4839uTfE5L1FZWGEJIbKuRMRnbRqBsArUNmWlxyDUjhOVLdckQjtvb3E8RlQ9O Hz+Igi/QSpWd40CVyDBl5r2xWd/OgcPVkBN2YSNWeKEa4Ot3J7ASJQPtxHS/GjrBeisZMO4RJmPL xEZAXNKE282B3ccUkQVJACtUmjN/1ZBQZFaqpp+ljMb+9DDZeStVDVeRlDi/irKzPTTJJedLJEST RypaCBP8eGMV5WGJIOei0DeCnANJtdO/32JYTJapUZZbpokdYyn6wsErh4v4YSHEmHSRHy3gq1/W sdRQmB4vQIpMDNZbuj9W9jFCDm0Xq7bzXLyKc8DA2rYKt8uPpJcnHvVxaSlHEtUIKArnkTLO327g m1+bO3zobExWPXz2TtUaMN1iZUzGlipV1ouEJCVMZiEkY48XBT589gC+uL6JDj2PFHxMlYZo86CS +PHOahP1jgL1RVsHnFyeZ2zJ1HC8qY3E9FK3GLbwWrVIHB/Et3camNvsYIv0LtzdPQd4dapC4FwL mdTZ823aqQ5SqkadhWd2TBgyMrsW4li5gOMPlTBbJzmm3AwHDWjtYHpMYSncoHaTdSPVlWjKhRYr 5TuWSscWhtvfHul+fTUktTQwQc0vTwnXu05slxYthFt0YJHMHWOp4TnGYWy5EUVz9UZ09MDwMFYa baoHZSPpv2qxxtpqBP0P501OZIDsv0tKebiQR60R0UkYzcmoHX908eatK68/M4WnRopIeJHzYIe9 JsVx/deaES7d/A2MLan3X11er506f23mbCkIJgld2zb5QH8nbKd0683mfKuTnMlJcfVvAQYAm8qL 65gOAucAAAAASUVORK5CYII= ------_=_NextPart_001_01CE9E5F.6FF02282-- From hhhansen@MAYAH.com Wed Aug 21 12:36:59 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A6111E810A for ; Wed, 21 Aug 2013 12:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.352 X-Spam-Level: * X-Spam-Status: No, score=1.352 tagged_above=-999 required=5 tests=[BAYES_50=0.001, EXTRA_MPART_TYPE=1, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GYv3WltSFPZ for ; Wed, 21 Aug 2013 12:36:56 -0700 (PDT) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id 1678E21F9EE2 for ; Wed, 21 Aug 2013 12:36:54 -0700 (PDT) Received: from [217.91.215.225] (helo=mayah-sbs.MAYAH.COM) by smtprelay04.ispgateway.de with esmtpa (Exim 4.68) (envelope-from ) id 1VCED6-00072s-72; Wed, 21 Aug 2013 21:36:52 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CE9EA5.C7CBC376" Date: Wed, 21 Aug 2013 21:36:49 +0200 Message-ID: <031C6AD0F5FEAB449C77DF4E9D047A5C40499D@mayah-sbs.mayah.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [payload] I-D Action: draft-ietf-payload-rtp-aptx-00.txt Thread-Index: Ac6eX2+mhoEpwHBVQcSyKXSWrXduCQARgtpQ From: "Hans-Heinrich Hansen" To: "John Lindsay" , X-Df-Sender: MzI2MjQx Cc: Foerster@worldcastsystems.com Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-aptx-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 19:37:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CE9EA5.C7CBC376 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CE9EA5.C7CBC376" ------_=_NextPart_002_01CE9EA5.C7CBC376 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, we'll support this draft! Hopefully this draft will be an official = RFC asap!!!!! =20 Freundliche Gr=FC=DFe, Best regards, Hans-Heinrich Hansen Dipl.-Ing., Senior Development Engineer MAYAH Communications GmbH Lise-Meitner-Strasse 2 24941 Flensburg, Germany http://www.mayah.com =20 info@mayah.com Skype: hhhansen.mayah.com Live messenger: hhhansen@mayah.com Gesch=E4ftsf=FChrer, CEO, Dipl.-Ing. Detlef Wiese HRB 118601, Ust-IdNr DE193170106, Steuer-Nr Finanzamt Freising = 115/132/10789 Es gelten unsere Allgemeinen Gesch=E4ftsbedingungen = http://www.mayah.com/agb_de.pdf. We apply our General terms of delivery and business = http://www.mayah.com/agb_engl.pdf. Please note that this message and any included attachments are intended = only for the use of the addressee. It may contain information that is = confidential. If you are not the intended recipient, you are hereby = notified that any distribution or copying of this communication is = prohibited. If you have received this information by accident or due to = a misinterpretation of your e-mail address please be sure to erase the = original message and any copies or printouts hereof. Thank you. -----Original Message----- From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]On = Behalf Of John Lindsay Sent: Wednesday, August 21, 2013 1:13 PM To: payload@ietf.org Cc: Foerster@worldcastsystems.com Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-aptx-00.txt Hi =20 Over the last few months there have been a number of posts to the = payload group in support of the draft RFC. =20 The only issues that have been raised during the last 6 months are from = Hans-Heinrich Hansen on 24th April 2013, however Hans-Heinrich has now = accepted and implemented the draft as is. On 8th August support for the = current format of the draft was expressed by Hans-Heinrich. =20 Hence as there are currently no other outstanding issues we would ask = for anyone with an issue to review and post comments to the group = otherwise can the doc to be moved forward to the publication stage.=20 =20 Once again thanks to all that have taken the time to review and post = thus far. =20 Regards =20 John Lindsay =20 Worldcast Systems APT Ecreso Audemat John Lindsay R&D Manager=20 Tel : +44 (0) 28 90 677200 lindsay@worldcastsystems.com=20 APT office: Whiterock Business Park 729 Springfield Road - Belfast - BT12 7FP Tel : 44 (0) 2890 677200 - Fax : 44 (0) 2890 677201=20 Si=E8ge Social: 20, av Neil Armstrong, Parc d'Activit=E9s J.F. Kennedy = = = = = = =20 33700 Bordeaux-M=E9rignac - FRANCE=20 Tel: +33 557 928 928 - Fax: +33 557 928 929=20 =20 =20 ------_=_NextPart_002_01CE9EA5.C7CBC376 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yes,=20 we'll support this draft! Hopefully this draft will be an official RFC=20 asap!!!!!
 
Freundliche Gr=FC=DFe,
Best regards,

Hans-Heinrich Hansen
Dipl.-Ing., Senior Development Engineer

MAYAH Communications GmbH
Lise-Meitner-Strasse 2
24941 = Flensburg,=20 Germany
http://www.mayah.com
info@mayah.com=

Skype: hhhansen.mayah.com
Live messenger: hhhansen@mayah.com

Gesch=E4ftsf=FChrer, CEO, Dipl.-Ing. Detlef Wiese
HRB 118601, = Ust-IdNr=20 DE193170106, Steuer-Nr Finanzamt Freising 115/132/10789

Es gelten unsere Allgemeinen Gesch=E4ftsbedingungen http://www.mayah.com/agb_de.pdf<= /A>.
We=20 apply our General terms of delivery and business http://www.mayah.com/agb_engl.= pdf.

Please note that this message and any included attachments are = intended only=20 for the use of the addressee. It may contain information that is = confidential.=20 If you are not the intended recipient, you are hereby notified that any=20 distribution or copying of this communication is prohibited. If you have = received this information by accident or due to a misinterpretation of = your=20 e-mail address please be sure to erase the original message and any = copies or=20 printouts hereof. Thank you.

-----Original Message-----
From:=20 payload-bounces@ietf.org [mailto:payload-bounces@ietf.org]On Behalf = Of=20 John Lindsay
Sent: Wednesday, August 21, 2013 1:13=20 PM
To: payload@ietf.org
Cc:=20 Foerster@worldcastsystems.com
Subject: Re: [payload] I-D = Action:=20 draft-ietf-payload-rtp-aptx-00.txt

Hi

 

Over the last few months there have been a number = of posts=20 to the payload group in support of the draft RFC.

 

The only issues that have been raised during the = last 6=20 months are from Hans-Heinrich Hansen on 24th April 2013, = however=20 Hans-Heinrich has now accepted and implemented the draft as is. On=20 8th August support for the current format of the draft was=20 expressed by Hans-Heinrich.

 

Hence as there are currently no other outstanding = issues we=20 would ask for anyone with an issue to review and post comments to the = group=20 otherwise can the doc to be moved forward to the publication stage.=20

 

Once again thanks to all that have taken the time = to review=20 and post thus far.

 

Regards

 

John Lindsay

 

John=20 Lindsay

R&D=20 Manager=20

Tel=20 : +44 (0) 28 90 677200

lindsay@worldcastsystems.com=20

APT=20 office:
Whiterock=20 Business Park
729 Springfield Road - Belfast - BT12 = 7FP
Tel=20 : 44 (0) 2890 677200 - Fax : 44 (0) 2890 677201 =

Si=E8ge=20 Social:
20,=20 av Neil Armstrong, Parc d'Activit=E9s J.F. Kennedy= = =  =20
33700=20 Bordeaux-M=E9rignac - FRANCE
Tel: +33 557 928 928 - = Fax: +33 557=20 928 929

=

 



 

------_=_NextPart_002_01CE9EA5.C7CBC376-- ------_=_NextPart_001_01CE9EA5.C7CBC376 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: <281413419@21082013-2e98> Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoKDBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxsc Hx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8f/8AAEQgAPgD5AwERAAIRAQMRAf/EAKwAAAEEAwEAAAAAAAAAAAAA AAQCAwUGAAEHCAEAAgMBAQEAAAAAAAAAAAAAAQIAAwQFBgcQAAIBAgQCBQgIBQIFBQAAAAECAwQF ABESBiExQZEiEwdRYXGB0TJSFKGxQpIjUxUIwWJyMxbhgvCi4kOTJDQmFxgRAAEDAgQDBgUEAgEF AAAAAAEAEQIDBCExURJhExRBcZEiMgXwgaHB0bFSciThQmKCkiMzNP/aAAwDAQACEQMRAD8Ao11r Yg+RnhbIfYbP+Jx7wlfOrakWykoqS6oi6UIcj4eH1jA3LZG2JzU/tHYW+t5kyWW2a6QNpe4VDiOB SOY1sO0R0hATjJXvYUvUcV0Lf22U8sl063/tVukkStctxRQykdqOmp2kUHzO7xZ/dxzpe9Dsj9V0 Y+0gZlZXftcvVNEzWu+QVcg5RVETwA/7lab6sGHvUf8AaJVVX2cnKX0XOd0bN3htZtN6tclPCTpS rU95Ax6MpUBX1HI+bHUoXdOr6SuTce3zpHzZKuJW9vM5cPT7MXus5pYIgXBT9pQfQfbguquQliv4 f3Bl5l/6sR0po8PjwTclcx/7jepR7TiOmFEaIeSdyOch+6P4YCtjAcEM8jn7Mh9LAYiuERwTBd8+ MRPpc4CtYa/RYJCOcKD+ok4CBjxKcWpGXKIerEdKafekipaQ5KyKnSQp44DpzTERi7opJJGyGs5D +TIAdWC6zmIHZ9U7rYkKHZh08NIwJFNTiM2CNg4eXrGFdPKKOicAcGPpBwCoIoqJgB9o+vhhCroh FxOOgkehc8ISrQEQpz6foxVJXRwRcBIPHPFTq1SVNIVOfRiOoYupKGTMAg4BKAipCCQHLjhCUdqP hYcO0OrCFOAj4SPLhCmCMiPDhxxWU4RkLN5cIVaIojUcKiwXj6pliZv7in/YQceoK81TiR2fVNUc 9thrYpa6JaqljbVJTKSneZcQhcZlQx5kccuWK6jthmtlEYuQWVuqPFfxMvrxWqz1T0dMF7uks9lj eBEQckRYgZSB52OMUbSjDEseMlulcVZYBx3BS1BYf3HUOVbTQ3xBlqINRKzEeeJ3Yn0FcVmpanA7 EwhcDEGXx81aNt/uN3tYbglt3tbTUxpkJmZPla1B8WhgiP6Ml9OKqvtlOYemW+oRp384Fqg+mK79 Zb5tjeVh+aoZIbla6pdE0TgOAcuMcsbZ5MOkEY4tSnOlJjgQupCcZxcYgrgnjB4IiwJNuHbau1nB 1VlCO21MCffQ8zF5c+K+jl3fb/cd/kn6uw6rh+4e37RvgMO0LkKyH8x/Uhx2FwzHgPFTFBtvcFws tdeqSCWa227hW1GarozAPutk7c/sg4qlXhGQiT5irIWs5RMhEbRxH5TSbav8+3p9xR00z2amkEM1 XmgCyEqNOk5PzdejENeAnsfzJ4209m9ht1+ChqjbV9i27HuOSjkFlllNPHWF0CmUEjTpz1/ZPRic 6G/Y/mVot57N7eVQDzRdIX1scWEoxgexDtNHnw7oekk/wxUZjUK8UpaSShUxge9F6lJxN41CHIlo VLx7Y3JPtuXcqU3/AMfilFPJWgIB3pIGnTq182HHTirnxM9j49ys6eUY7m+qjo5DyBIy8gyxe6yy Cmtt7dv+47g1usdK9dWLGZmiDIp0KQC2blRzYdOKqtaNMPIsEaVvKoWiMVIbc2Tu3cT1C2W1zVvy jaah1KKiN8JZ2Vc/MDiutc04NuLOrqVtUk+0ZKwr4OeJyqWbb8xAGeXeQE8PMJMZ+uo6q/o6un6K vETU8rwTx9zNExSSOTNWVlORVgeRBxpE3yWYwbNFQyA5dpSfTiGRUiyLRyMu1liqUirQAiopM/tA 4qMirQApypsl2t1PR1NbAYYK9O9pHJU60yBzGkkjgw54oFQSJAOStNMgAkZrcXDlgkqBGU7NmPJh NysIClqXIj/XDAqsqRgAz/1xCi6koVXIfVhCoCjIVPDFZVgKPiQcM+vCFEST/djy4VNvK8dtESeA kI8zq+PTBedEu7wQdSFBIVHZvIdIxJHgtFPvCum2/ETdNqgis2x6EW6okUCaeCmWruFU/NmeRlfs 5+6iKAo8vPGCpawkd1Q/gLpRuZemmPyrfTeMHj3tVVrNwWyqrbcDnIK+hanGXmmRI9J9OfoxknaW 8/QceBWiNetH1jBdYsN88N/GrbkkNbRL87TqPmKObIVdKzcBJDKOJXPkw4H7Q6Mc+UattJwtYMKs WzXGpG3X4GeISoNVXYqvtAghY6ylByOa8lmiz6/5Tjq7o3dPJpD6H8LnbZW083iV6pttwtt6tMFd SOtTb6+ESRtwKvHIvIj0HIjHn5RMJMcCF1wQQ/YvIfjDsr/Dd5TUdPFILTWL81bpC4ACMe3H5fw2 4ejLHqLG6NWGOYzXmr+15c8GY8FZ/D2bLwO38yqTpZOBfnmidPRjPdn+zTWuyj/Xn8/0WrLKv/5k 3A4XPK6J2c8+PeU3Tg1P/sj/AB/KkI/1COP3CVDDDXft527TTrpiqdwpC6gZnS80qnLLzHCGTXUj /wAFfTg9vEcfunPF3d1Lsjdv+OWLblkWgpqWF1M9ujnkLOCSS5IzxXZ0OdDdKUndPc3EqUmiAzLN z7f25uO3+Ft5ktFPQ1O4a2OluyW+JaaOSMyKpzReXI8efH0YSFSVM1IgkiOTq4wExElnSd+eI9p2 l4h1+3/8OstXt+gCQ/LfKQxzurwK2ffENl2n+Dl14ahbmpSEt0tx4qmtc7J7WG1Jasoan9t98qaK lNBQy3wtTUZl7zuo2miKx95kMwo4csGDi5i+e1LUY25I1+6A8LorPbPCnd28mtdJcbvbpo4KU16C oiVW7ocEPDnKT1YN5UlKrGDkR4FJZwEacpM8lavATxGrdx72loJrTaKFFopZRNb6NaeXNXjGkuGP Z7XEYzXtERg4JOPaVdaXEpyYgZKKsk0sXgBu6SJzC5vOkuhKnIyU4yzBGL5l7iH8fyqnahP+R/Vc 823d9yU15pZrNU1DXRG/9KkRaZyxBBAjOsNwz4ZY21IxMSJZLn060t3lJJ8Vftk2fd9xvl73NWyU FNJQ6heJ77CDCJJACQ0IC6WAUHPhl68Y69SEYiAfHLatdCMzKUywbPcui7O/Sr5dGtlxqtrXammh k1UtspjHUZjLtBj0Dp6cYqxlEON4PErXRImWJhIcB/kqH2fFtqi2zcIqc22mvkVfLEau9xF4WgSU qgRyMvdGXA8888PW3SkMzFuxJR2xgcgXOfel3yzXm92CsaiqNvVkdCBUVK2iPROFUE+9lyyBOXTl iQlGMg4kH1UmJTiWMS2iL3xJaF2VtdauGWStegX5GVHCxoRHFqMin3s+jC0BLfJsnTV5R2RfNsFQ YVLZeTGsrKCyPhHrwqYFSNMMsujDBAqTgYcM+eCoyPgJJHlwpTKShYAefy4QqAIuI4rKsCezwqZl 5ANPIznSI2A+JcvqOPT7V5reAMXUXWwyI2oaUB48QcvrxXOJ7GC20pAqzbCuG/paxLBs6V4a+ubN 2o27mWQKM/xJ+DLGg45agvrxmrQgBuqMQFsozmSIwwXVE3j41eF9RTvvmE3nbFY4inkklWpK6h2g sx7QbTnksnZbjl5ccw06Nf8A9bRkF0RKpT9XmCVv6w0WwrzY/FbYWRsNdIhrqSJvwdFQNXYX7Mcy 5jT9hssugBbeZqxNKfqRqRECJjLtXRPHaw0G6fCuoulPlJJQRpdLfMACTHkC49DRMT1Yz2EzCsBr gnuoCVMqF/a9uOet2tX2OdixtUyyU2fRDUgtpHmWRGPrxo94pNMSH+32Wb22rugY/tW/3S2WGo2d b7xp/HttYE1gZnuqhSGH30TC+0zaoRqE3uMHpvoVw3YW/N3WCStorJTi409wQfOWyWlNTE4UZBjG vHkcj0Hpx2LmhTmQZliMuxcy1q1IAiAceKts3i54lUtrmpG2fQw2knvZ4GtMqU5IyOt0zCcNI4nG Y2lB33l/5LWK9dm2DwKpO7fFzcu5rdRWyVaSgttBL8xT0lti+WjEozyfIFuK6jlli6jbU4EkEyJ1 KrncVJBjgylKjx+3XXGJrnaLHcqmNBH85W0CzTMq8tTFvqGKI2UHYGUfmrjdyZyAVEX/AMYN2Xe7 WKvqRR06bcmWe1UNND3NKkiMrcUBzI7AGWfLllgdJCLg/wC3FE3UizBQe6b7fN23m4bmr4F7yd4/ m5qeNhAjaAiDMltOoR8Mzxw9OAiBELPUlKZMmUrtHxV3NtezVVloko7haKqQTTUNwgWphEnAFgpI 56R1Yqq28Zl+0aKylXlAMjrN4zbmt1bdXpKW1x0V57s1tm+UQ0JaJAgdYNXZJA7XHI9OKumjJnJw 4pzczDsBipmm8c90UkcwttustonqIzEauhoUgmCn4WDfWMWCxgcyW4lUzvqgyA8ELs3xIv8Atm3V dupPlau217iSoo6+ITxM4yGrIleJyGfoxpq2kKhBOY0WOneVKYIAcHUKx0PjJfqaVaijs9jpp0z7 ueCgVHUkZEqyvwxSbCBwMpeKtj7hVzER/wBpQth8SdzWqquc6TQVv6y5kuUFZGs0crnPtaQVy4HL LllhqtpAgdm3JlKN3UBJz3ZuFN0ni5uGn1tQW+02+eRCnzNLRrHIoPkIb68Z+jicyT81oF3UGQA+ Sa2/4gX6z2yS1qtNXUEshmMFbEJwJGObMMyOZ48enD1baJL5HglpV5xDM44hSr+JN8mt9TRU9PQW 6KsTu6h6OnELshBBGYJ6CejCi0i7kktqU0rqbMwD6BE2vf8Ae4rbTW6ano66lpF0U3zcAlZV5ZA5 jo4YBtYkuHD6Ii6lGIGBZRiKXZm0hcyTpHADM55DzYv2LPvRUcZ4YQwVgkjYRkPL5jgMnBRkOeY8 v0YUqwKUp2AGXAnpIwpQZStDR1NScoInk8pUZgek8hiqcgM08Yk5KVjt0MP/ALqqSNumKP8AEf8A 5eH04pMycgrdjZlOabV8c/3U9uB5uCnl4rx1Gcy2sH+U49YvKy4LJIi0Y1jNc82GQPDERjLHBW3w Z3da9p7/AKeuuI7u3zRSUs9QF4RCXIq5AGeQZRnl0Yw+4UDUpERzzXU9vrCE3kc8F3Dx13rsybw1 r6KO4UlfVXIRLb4IJI52LCRX7zJS2lVCnterHF9vt6nOBYgDNdi7qw5ZxzVP75of2q6Ln70z93b1 ccSPndUekf0qxHmxrb+75fn4LOT/AFcfjHBdFvkrWjwFkWt7M0dhjpmVhke9lp1iVcj06mAxgpDd dYfv+61VfLQL/t+y55+1SGc3DcU2R7lYqaMno1FpCPoGOh70cIjvWD2geo9yuf7krhDS+HYgcBpK ysgjjTp7GqQnqTGP2mL1n0C0+5n/AMJGq434e11c1gu1tgSnnWeeCZ6Ja79Mrm0KwDxzNlHJGufa Q58cjljsXcRvEjhhm24Ll2UzsMRjjlu2lWK20V0iuVLI1LX2mNZUL3IbkpH7hdXGRo5BocKOJU8+ WM85RMTiJcNhWuEZOHEo8d7qj2B7ZV7jvO1qqSKqob/PJBQ3QQqmitWVjSVKhV7KSMdLqOGlvNjV ViYwjMBjHMcO0KijMSnKBLiRz49hS7/Db7PX2TaMcdLKLTUxzX+pkA7qavkZe+ieQKW7inT8Lh/M csCkDMSqY+YYd35OalaYgY0x2HHvXRCvf3kx1kC0lrEzZyTz2KqtkcQJI1RCKCVqfLoVg+nlxxzp RG3U903++K6cZHdi7f8AS35VI8Pb1c02hua0WKopYrtJV0lTSQyilRJIkMiTmM1Q0NpBTgTnly6c bLinHfGUh5WOv2WK3nIRlGJ8z4fBTFpppv8A7Et0u9XtlTJLSTtFAJKMRLOsMgpEqDErUyMZdJGs EctWK6uNIimCIvx+fFXUsKgNQvNvBWCSOR7XdE3Ba4o6L5Co7uatr7ROEqO7JgMKUVNHP3veZBdD ZeXhiiMPMNub9gl91fOo0Tvybtb7KuNdJtv7O2ytiemgrq+OqnvEyxwTVBlWoMcSSNIjsiLEoKrw 5541ihvnLcMmbTJYZ3QpwiQc3dTFz3ddodvbfq6CSkguddHUteJ6empRNK8M5jhM2UZy/DHkGfPC 07QGUgRgGbEpanuAEYl/U74aImGalrrlsq51cNBLXVBlF0E3dwQymKoZYTVBFKqWTLtFOPDPCmkQ JgOwy8OxOLuBNMk+p/gq2rHVyw1a3GOWlpRTznVXzWippcxE2lWSnSGbMtloKHMHI4zbRg2J4bn+ q083VwOO1vpiuWwUz6VOno6eeOiaa5wuo8UdDTPwyXA5aPUxRsFM+fEcMAQUlXBGClKfMZAjhhis 7KQiQkZgYQohFRrl0erCFWxRdHR1VVMI6eF5pDyVFLH6MVTkBmtMATkpyKxpTZfqFXFSHpiT8eb7 icF/3HFBqP6Q6uFP9xZGQ1dqp+FHRGocf9+rOfHzRJkvWTisxkcz4KwSiMh4oh7rcKgBZZmEfRCu SRj0KuQwBTiFDMlGUdFVzLnHC7L8WWS9Z4YWUwO1AUzoi/0us+Ff/IntwnMCblleaBteYDID6Meo 5oXkeRLVK/xeU81+jE5oS8iWqZm2lIcyVz9WBzQrYUpaqQ23syztWD9Qt9dcSpzWiotCCQeR3Opw PLpHrxRWrSbymMeJW6hSi/mEpcAutLty4X6st1dvRKbb207Jpa2bf1qNRQZJ3gPRkPTlwA4k45PN jTBjSedSWcl1dk5kSqtCnHKP5UH4t7qrt4yQWSzxyfpEUgbPSe8qZuSZJzCrn2RzJ4+TGiwthR88 vV+iy390a3kh6f1XSfCXYa7N2qKacD9RrHNTXt5GIyWPPyIo688cu/uedUcekZLq2NuaVMA+rtXL PGe8vuu+RUdG2q1WvUsUg4iWZsu8cfyjLSvrx1/baPKg59UlxvdKxqy2x9MfqVUrV4dPX08szOsZ XWkSlGOqRUDDUwBVF7Q5+rG2pdCJZlgo2cpgnc2neiarwoqEbuBLHUVDHKAJ7r5jgvEe8WBAwgvQ cWYKw+3zjgJPLsRll2Vedv53SguFNTNKjxtUrF3ssMfa/EizRmRm7vIMna488V1K8KnlMT+VbTo1 aI3CQ72dhwQE3hjI1ma701QkyRTmCuDKyEMzdl4nfITKy8Tl2h0jFouwJ7SGww/zos0rOZhvEnxY /kaoau8LylQ0K1UZYzfLwM8MsZlYEBtOa8ANXPp6MQXYIduzgrhZSBbd2sMCPj7pM/hTPFKKZqqB 3cqYQFkKup05tmFIXTrHA88J1YIdirxaSiWcY/HyWSeFncSSJPWQxqimRX7uVtaIgkcgKp5Bh6cT q3yCPSGOcv1Sx4ZxQIk80w7tZhHKIoXdgmYzkU5Acm4K2ROALlywCadqwclStZ4WzUFxakmnhWLu 0mjqdL9pJGCR6ogO8RiWGasOGBG9EouAqZWJjJifn/hLj8OWAaSKaOReIjZUkGp11alOa9nLuzxb gcTqxop0Wh/VGJ4fKFkbv0YKrHUkcjaijaGXTp1Z6unlgdXwU6EY4/T5Jf8AgKwgSSSxRrlkWKOM n4dn3eI4+8OGB1boixEccB8vjxQ8dgb4cMaiApIyKxHL3cKaiPLRKWNvhwpqJxTRlLt2eVtMUTSN 5FBP1YrlVAzVkaZOSk4ts91xqZ44PKg/Ek+6mf0nFRr6B1dG3fMoqKitsP8AbpWqZPzKhsl/8cf8 WxWZyOZbuV/LjHIP3owJd6qPuItQh6Yade7jHpVAB14TyxxRG6XclQ7e0f35YofKuet/upqwDW0T cvVGxUFsi5pLUt0asok+jU2EMpHgmAiOKLiklj4U8EVOOhkUM33n1HCEPmXT7tME+KauqDm5ll85 JI9mA4CjEpf6XP8AlHA5gR2FUcbTPwfRjodQuf0wW/8AFD8H0YnUIdMFh2mfg+jB6hDpgmztA58F ywOoTCgi6PZtC7A1UzxH+WLvDl6dQ+rCyuZDJMLaJzVmtFFteyHvqOklqa0DITyKAw/pzyC+oYyV ZVKmBLBaqUaVPEAkoe/XK93WJqYD5Wjfg8aZlnHkZ/J5gMNRpwgXzKFWrKYbIKtDaC9CZegY19Qs nThOJtOQAquYB95RwBy8oxOoS9MlHasrHU+ZPlPE8PPidQEpt1o7XbSF46ByXoGfmxOoQ6ZKl25P LDFBIzNDDn3UZPZXUc20jkMzzwBXALpunJAHYEy+1S2ROZI5E8csHqE3TlJ/xMltTZlviJJPXic8 JuQUo7T1Els2J5k5k4HPU5JT1Pth4XWSMsrqwZSDyZTmp9RwDXBR5RTr7ZeSRpJM3kkOp3YksxPH Mk88DngIcgnFKTbLKCACAeBAJ4+nA56PIKcTbhBzAI9GfTgGuiKBTq7cZshpLZcBzPDA54R5BTyb XI95Qv8AUQMKbhNyCn027Tr7zFvMi/xb2YBrlHkBER2eJf7VMpPxPm56uC/RhTV1KYU9AnWtVS66 ZJNKfl55L91fZheYBkm5cjmsSx0689TnyKAo6zn9WAapVggAiI7YF/s06hviI1n/AJuH0YUz4qCL 9ica1VUgylchRyVmyH3R7MLzAMk5iTmlpaIF958/Mi/xOWIahQ2BPpQ0y8oS39bfwXLC7jqjtGid WJ19xEj/AKVGfWczgOjilGGV/fZm8xJwHCjErPlB5MTcptSNFs/MXqPswXko0dVmi2fmL1H2YjyU aOqzRbPzF6j7MR5INHVYUtf5i9R9mI8kWjqs0Wz8xeo+zEeSDR1WaLZ+YvUfZiPJRo6rNFs/MXqP sxHko0dVmi2fmL1H2YjyUaOq3ot35g6j7MR5KNHVKCUH5g6j7MR5ItHVYUt3TIvrH+mA8lGjqklL X8a9R9mC8lGitaLV+YvUfZiPJFo6rNFq/MHUfZiPJRo6rNFr/MXqPsxHko0dUoJbfzB1H2YDyUaO q3otvxjqPsxHko0VsLbviXqOJ5kWilqlD0OnVgPJFgtlKXLi/D0HL6sByowWgtB0MPp9mD5kGilq tJ0MvVgYosFsrT9L8PQcByiwWAUnxD6cTFDypain6GX/AI9OBimDLZVOljl68sRTBaC03xDqwcUM FsCn+LAxRwSh3HlH04GKOCUBF0EYmKOC2AvQerARW+Hn+nEUX//Z ------_=_NextPart_001_01CE9EA5.C7CBC376 Content-Type: image/jpeg; name="image002.jpg" Content-Transfer-Encoding: base64 Content-ID: <281413419@21082013-2e9f> Content-Description: image002.jpg Content-Location: image002.jpg /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoKDBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxsc Hx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8f/8AAEQgAGQBlAwERAAIRAQMRAf/EAHkAAAMAAwEBAAAAAAAAAAAA AAADBAIFBgEHAQEBAQEBAQAAAAAAAAAAAAACAAEDBQQQAAICAQIFAgUFAQAAAAAAAAECAwQAERIh MRMFBkFxUSJCFAdhMmIjMyURAQEAAgEEAwAAAAAAAAAAAAABEQIDITESE0FRBP/aAAwDAQACEQMR AD8A+6QMfjnoV8PjFsTHBWyRXGcFbhSmGlDkwU4euGnDVw04yzGjJDJDJDJDJOLiTTPQrz5ssiAw UpaqiwU1KYa2HpgpxprfnfjNC59pdnmrSCZa3UlrWUh6rttUdYx9L5mPA7tMU4trMxezWXFeXPyP 4dRlux2Lr/8ANcxX5Y61mWKF1ALLJLHG0aldePzcMycG1+O7fdrM9eymp5t2a15VL42jgXFqQ3YJ CybJ45tx/qGu5iqpqeHLMvFZr5FOWXbx+cN400KxtK0irGmu9yQFG06HU/pnLDo9aSNWVWYKz8FB OhPtkmWSGSGScVEc9CvPi2FS3IE+3HBTi2KFxz4e+c7SxVCqB9Qw2lIcmg9cNOPnsf4O7BvjWS/Y mrR2Rb2PFWM7MsvVCNa6fWK7v5cuGd7+rb6cZ+bX7VR/i/uk8XklO136Wv2ryG/ZtS0qsUJ1hsBQ VaSaN3D6Lodp0w3nkxZOusKcFvlLem1b6LwWCp5DD3rtvcJ6brWr0bNYLFLHNBVJ6akyIzodGIJV hnO82dcWOvqxtmVd3XxuLuECQPLpGJJXkDIH1Ezbjt1I2sPpb0wa74dLCqnikcFmad7TydWYzbSD yLFiGJZtdd2hI04embd1hgviIWSjJ99KzU3Z2ZgSz6spXkwAKqiprodRl7GeLcdu7dWoVlggUAAD eRw3MFCliPidvHBbkpFOYnEwcxnoV8F7t/D/AI5897u5Y/dic6cnphpQ9MFOHrhpw1cNOMsxoyQy QyQyQyT/2Q== ------_=_NextPart_001_01CE9EA5.C7CBC376 Content-Type: image/jpeg; name="image003.jpg" Content-Transfer-Encoding: base64 Content-ID: <281413419@21082013-2ea6> Content-Description: image003.jpg Content-Location: image003.jpg /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoKDBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxsc Hx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8f/8AAEQgADgBlAwERAAIRAQMRAf/EAIwAAAMAAgMAAAAAAAAAAAAA AAECBAMFAAYHAQADAQEBAAAAAAAAAAAAAAABAgQDAAUQAAEDAgQDBQgDAAAAAAAAAAIBEQMSEwAh BBQxQSJhMgUVFlGRocFCUiMGgdFiEQABAwIEBQMDBQEAAAAAAAABABECIRIxQaETUSIDBBTB0QVh cTLwkbFCotL/2gAMAwEAAhEDEQA/APfY9Y2UMQQp2JUXvXFxhxUN/ALMBmauRKXbgMucrFr/ABPZ WBGO4eoNQFHVERhUlVaRMuXJMef33e7NoZzIto+QJ0VnZ9pvXVYRH6zH8oafxzVSyxQBolGeUpEC 4SgCjEgqpCqhUr1t3cRw+SnMiIhzEyxLBotUUfPgq5dhGIMjPlDYBzV6YtlxVReK60Z49KGljk1R hJKoDN0IMaiLVKHeVS4Nh5951BIQEQZkE/lSjZtjVCPawtMjIiLgfjx+j4LFL+0TBNqY4tCUpaUh A40UlMjUUJRGgDDKpsyTE0/lJCUgIE20zd2ejAjVbw+PBAJk137akHRUxfsq7pY5tPt4BmsLLKpo rvSi5RrH1Lw68MPkedpRtjczl/8Alv8ASB7HlcG4s9G930RD9knWKDVFo0HRajUppQO68iKsixoS hS3FPuwB8hJhIx5JStxri2DeqY9kHMbuYRuwpg+L+i20mshjUK6vyGoCwqWYuqqrOyZccXy6oDPm VGOmTgkXxTRCYgRqhn3QUSRVfgyNzwvkQdnqm2Js64niejUlBDVTT6UEn9zY7yIOzrtiWKIeI6Y5 QiGtSkRx6C4ZK65ZJnzwR14kgB6/QoHoyAf1VONlkupRR6MUT8yyL7AFk95f1i4k8FAw4qmMo36Q /klzwpRBGSGu8vtBv7SR1fjrbvMvd7WxF3eww3WZ6PxVXbbznbd82SH6f20F6zYctvUzP9VL/HEv U8SyN1ttbfVlVDyby112fo6q8N8kri2ViumS1bpempLjN/pqu3Ddv47jbtdizcH5tcUvW32N92Tv 9qaYJpfTvmC3bG+qGrhXXlS7c+GM+p425W3ccfd8lrDf26XWaIr6U3q17bdXep6XvPz5VVfHGcvE vrZe/wDr3WkfJs/ta2nsjF6S3w29ru7q0NS911duVT4EfEvpZe+vujLybK3WtotlqNjQN+mitaX+ 7N/m+LepY3NxU0L3olk8u3Edyi+w2n4tnS3ywstu4OzoxvtLYJQ8r3PTbvure1+bfPAG1dRrkTuW 5smLy67G9Fxxttx4dPDBO24wdAXseCqxusV//9k= ------_=_NextPart_001_01CE9EA5.C7CBC376 Content-Type: image/jpeg; name="image004.jpg" Content-Transfer-Encoding: base64 Content-ID: <281413419@21082013-2ead> Content-Description: image004.jpg Content-Location: image004.jpg /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAPAAA/+4ADkFkb2JlAGTAAAAAAf/b AIQABgQEBAUEBgUFBgkGBQYJCwgGBggLDAoKCwoKDBAMDAwMDAwQDA4PEA8ODBMTFBQTExwbGxsc Hx8fHx8fHx8fHwEHBwcNDA0YEBAYGhURFRofHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8fHx8f Hx8fHx8fHx8fHx8fHx8fHx8f/8AAEQgAGABlAwERAAIRAQMRAf/EAHQAAAMBAQEBAAAAAAAAAAAA AAABAwQCBQgBAQEBAQAAAAAAAAAAAAAAAAABAgQQAAIBBAAEBAQGAwAAAAAAAAECAwAREgQhMRMF QVEiBnGBYhRhkbEyUhaCIzMRAQEBAQEBAQAAAAAAAAAAAAABERITAjH/2gAMAwEAAhEDEQA/APoB I55Td2dz5m5rt2Rw2WuNvbh0ColRiWBNgU5D8GZam6n4tod00tvPoliEiScki3okBI+fpNZrUTHu PUaCSXWgn2OlCs74qAFDpmoYk8OHlepjU+lP7V26JCZEkyjijmnC4kIJEEgHqZS3A+ArPNa7i590 aAlWOOHYmykECOiDFpSnUwGTLxxNZ4rXcWPujtq6sGyqu8c6sygYKwwOJDK7qeY8KzxWvSZqnbfc Or3De+3gU9NtePZhlIPqWQsCCLekrj4ml+MjXz9y16LbOuqhnkVFJIBYheI4HnWMb0fda3D/AHJx BYeochzPwq4ml95q5KnWTJgWUZDiBzI86Yaa7GuxVVlRi4uoDAkgeVTF1Sg8oROeZJro2ObKybXt /U2tj7hy6TFOmzRsVuoJIB/OnaeYX2zoLYQmaACJYT0pGXJEviG8+ZrPbXnHX9W7diyxmaCOSNYZ UikZVdEXFQ3+PCp2vnFG9sdsM/XQSRPiikI3pIiGK3BvyAtU7q+caB2PQ6wlxbMbJ3B6j/1KYX+F vCp1WuIzj2l2lQnT6sRVDHkkhBKF2exv9TmnpTyjTrdg7fqzQy63UhMEawhUdsWRL4hwf3WyNS/d qz4k/GqXR15UKOCVKuvPwkN2/SprWJP2rVZ2Y5Wds2S/Atcm/L6jTo5M9s1iWILLnnmAeYkNyD86 aY719GGBmcXeRyC7vYkkX48h/I8qWkjRUVPpDyFXWcPCmmHgaauHjQwWqKdqAoCgKAoCgKAoP//Z ------_=_NextPart_001_01CE9EA5.C7CBC376 Content-Type: image/png; name="image005.png" Content-Transfer-Encoding: base64 Content-ID: <281413419@21082013-2eb4> Content-Description: image005.png Content-Location: image005.png iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ bWFnZVJlYWR5ccllPAAABGBJREFUeNqkVUtvW0UU/u6943v9iFM7aRJStVZLZXDLq3SBykttJZQF CxAqYtlKFUuksmEBf4B1pC6R2LCpxIYNYtNHhAQVCBJB6UNJhWgCeTROXCe+9n3MDOfMvTZNiJtK Hcn2Hd+Z7/vOOd+ZsV555zNohVPjo3snx58aripFsycYtm3Zi0v12cWV+gXL0teEVOrk8eeOXD39 6jHAcvCE+CB8QMsXr/wwc3X6j1unxN5y+eKhAxVM/foXluvNZMHjDGvnv5VSGBsexNOVCuYXly4K 183V5hYaqDdbcISNx4RHO5DodCLodK7pIZ/NIJcTWFptIgolGFsEsQ42/EAImyQp3dvQb5BA+EGE 6sEynj00BDuNJJt1cHO2jltz68jRM2GCsQVviJWkQu+eezIA2qRs4rUKPni7hv1jRGB3Y3Zx6dtp /DjzNzyvYITwRyiKrTt51ODIOoHC0cMlnD/zEoZKwyYvTJq4hzEcxFJDKguWSYgmAlIvtdzVPVpb RBLj3beqBpyLSZbcYgpOTawZLyYP2GBssikxyv+U9E+PMsY5XtvfU9xpR5j86jrm7tWRz7tYXWuh NJBFHGt6z5Hoboq0CedRgxfnswL5XC5NmI1/VjZw6bvfkHEc2I4FzxXwMk6ClWIKTerNvE8ErLzp R5CxwmoDcGwnJbDQ6oRYXvUxPlIkoySqhZPgJP1Gc5jca4RS/a8HVFrdTz982UwkKeGNnAIG2jda wOcfn6CoXBQpRZd/WsCV6wsoFFwSwgyKCAiBap5EsK07FZFqQjwzcaLnpSiKKWISRAUsDeZx9r03 e629vKbxzeW71GwZg8nrBQdgM4GM6cHZSmDqo6CiEJKXE6F8qFZSSjhObKJ0vSxCIjfriZwxGTuJ gBZEMmXb1lj80jQi2VTSr5UWnC1qkdnjSJnfhJAEmXQnmCYCrjCni5XZettRYSVgb5z7ElGckE19 cc78nyNH/XJjEe9/8jVGyoVkORGVSwXaowwmTKMhAaVzA8rRO/Ywg3etrC1lSJVmO0oElLbYnGHa nEvcYByBNiYhgqjtI2w/gL+5Bs+xdzzsLFMPyq3mlEhTZBlLKniEkPYF2dDUQadrmTTMkzDCFvtq NVSqL8C+34Dr9D+sVdorWsUmgrij4eULOHJyAiN7Mni4T0PqmcOjJXizv0O06R5o0UWzvgsB159T FBuXUASkNQwCNO6vQwTulsgjIvCFA8YW5EyvSJeETQ+aiuT0uam0lRRNkTWT8wtJMUkUf7oRUPph CwtFMgFjC7/VvO3Z8fOVoQHMr2+a8PpdNFy6gFTzWRyFlGeqg083mx/K3jpB9jlQHoBrR2Bs0Wqs fXRj9s61Y7WjODg0hrZU2KGp0T2qioNFozZH1+tY2cHrz4yjVBC9OyNP6h06rmdu3wRjU4rsqaV7 d09/36xPFgt7qsZdlrXDfZB8/TzdNvbzKMfzKz7+vDOHYsFNzW6sZG+0HsxuNhoXBGH/K8AAwZyc 9z1avW8AAAAASUVORK5CYII= ------_=_NextPart_001_01CE9EA5.C7CBC376 Content-Type: image/png; name="image006.png" Content-Transfer-Encoding: base64 Content-ID: <281413419@21082013-2ebb> Content-Description: image006.png Content-Location: image006.png iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ bWFnZVJlYWR5ccllPAAABGBJREFUeNqsVltvG0UU/nZnvOtk7TipXQROoRBIKFIVgcqlAom2CMTl B/AOqA9ISH1GiB+AeECVKiSeeaJISEg8oLaiLa8VkVoFNSWkF5KAolwc79qxvbszwzmzjmOnQQqF tcbrnZ35zjnf+c4ZO59cnIEj3JOHS8Wzh8ZGJo2Bxn+4HAfuYi2cX643ziSpuiJTbU6cmhi//MZE BS7+n8s8UZm+cHvt8k/zf5yU46XiuZcOVbDW0mglanAhfaxX9Pk317Dn4EXCvLW6fk6Wg/yRVpKi maodGMINhgRG/RxSetxoJEhSjf3aqbdoPxmpBMNHpOs4nbZWUhvT8zqfk5i9t4nvfr6LwpDEe29N wfMElDL7TATQ1ikYW2rKKWMnKsstTSJOU5z+8hruLobgl3+GMT7/4BjWo86+yZKuAGPLONFItEHa jUA49Jt4WYZA+WgV4VaCG7WYBEDztG4vC3sZZUzGlolSFDp64WsKRLgOSsU8JG31hItKOcCYJxGX 7gdjv5rthEY6IAblMCsKMlWUQKPtyCjKjHiUB5c2jwYefr9Xx8sfX8DuFPBjkhq8//aTePO5Kppx 2nsnCI+xqQ7oR3dYA/YlkCPP+e5KBx2Tw0J0Pz2ULsRExaffL+D5p8vwaW03lT1MGauUJjV5p3sh a0PlSAZAdwb18x4839uTfE5L1FZWGEJIbKuRMRnbRqBsArUNmWlxyDUjhOVLdckQjtvb3E8RlQ9O Hz+Igi/QSpWd40CVyDBl5r2xWd/OgcPVkBN2YSNWeKEa4Ot3J7ASJQPtxHS/GjrBeisZMO4RJmPL xEZAXNKE282B3ccUkQVJACtUmjN/1ZBQZFaqpp+ljMb+9DDZeStVDVeRlDi/irKzPTTJJedLJEST RypaCBP8eGMV5WGJIOei0DeCnANJtdO/32JYTJapUZZbpokdYyn6wsErh4v4YSHEmHSRHy3gq1/W sdRQmB4vQIpMDNZbuj9W9jFCDm0Xq7bzXLyKc8DA2rYKt8uPpJcnHvVxaSlHEtUIKArnkTLO327g m1+bO3zobExWPXz2TtUaMN1iZUzGlipV1ouEJCVMZiEkY48XBT589gC+uL6JDj2PFHxMlYZo86CS +PHOahP1jgL1RVsHnFyeZ2zJ1HC8qY3E9FK3GLbwWrVIHB/Et3camNvsYIv0LtzdPQd4dapC4FwL mdTZ823aqQ5SqkadhWd2TBgyMrsW4li5gOMPlTBbJzmm3AwHDWjtYHpMYSncoHaTdSPVlWjKhRYr 5TuWSscWhtvfHul+fTUktTQwQc0vTwnXu05slxYthFt0YJHMHWOp4TnGYWy5EUVz9UZ09MDwMFYa baoHZSPpv2qxxtpqBP0P501OZIDsv0tKebiQR60R0UkYzcmoHX908eatK68/M4WnRopIeJHzYIe9 JsVx/deaES7d/A2MLan3X11er506f23mbCkIJgld2zb5QH8nbKd0683mfKuTnMlJcfVvAQYAm8qL 65gOAucAAAAASUVORK5CYII= ------_=_NextPart_001_01CE9EA5.C7CBC376-- From tterribe@xiph.org Wed Aug 21 18:21:28 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C96211E81AB for ; Wed, 21 Aug 2013 18:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1c+jsrVdUvO for ; Wed, 21 Aug 2013 18:21:23 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 338E611E81A5 for ; Wed, 21 Aug 2013 18:21:23 -0700 (PDT) Received: from [10.250.6.54] (corp-240.mv.mozilla.com [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 5600CF22A3 for ; Wed, 21 Aug 2013 18:21:22 -0700 (PDT) Message-ID: <52156792.3000501@xiph.org> Date: Wed, 21 Aug 2013 18:21:22 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 SeaMonkey/2.16.2 MIME-Version: 1.0 To: payload@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [payload] draft-ietf-payload-rtp-opus X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 01:21:28 -0000 In answering a question about draft-ietf-codec-oggopus [1], I realized that we don't describe how DTX is expected to work very well in the current payload draft. In the reference implementation, it is implemented by continually submitting audio to the encoder, which uses its voice activity detection to identify whole frames that can be dropped. If voice activity resumes in the middle of a frame, the whole frame is transmitted. I think we should make such behavior required, so that receivers can use simple packet loss concealment to fill in the missing data, instead of being required to synthesize an arbitrary number of samples. Therefore I propose we add the following sentence to the second to last paragraph of section 3.1.3: "The transmitter MUST drop whole frames only, to ensure successive RTP timestamps differ by a multiple of 120 and to allow the receiver to use whole frames for concealment." [1] http://www.ietf.org/mail-archive/web/codec/current/msg03030.html From internet-drafts@ietf.org Wed Aug 21 23:50:49 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4B821F9C88; Wed, 21 Aug 2013 23:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSxfbmeMETDw; Wed, 21 Aug 2013 23:50:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6DD21F960E; Wed, 21 Aug 2013 23:50:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130822065048.29182.27861.idtracker@ietfa.amsl.com> Date: Wed, 21 Aug 2013 23:50:48 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-howto-05.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 06:50:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : How to Write an RTP Payload Format Author(s) : Magnus Westerlund Filename : draft-ietf-payload-rtp-howto-05.txt Pages : 51 Date : 2013-08-21 Abstract: This document contains information on how to best write an RTP payload format. It provides reading tips, design practices, and practical tips on how to produce an RTP payload format specification quickly and with good results. A template is also included with instructions that can be used when writing an RTP payload format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-howto-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-howto-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From magnus.westerlund@ericsson.com Wed Aug 21 23:53:49 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABF921F9E46 for ; Wed, 21 Aug 2013 23:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.239 X-Spam-Level: X-Spam-Status: No, score=-105.239 tagged_above=-999 required=5 tests=[AWL=1.010, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gw-TvYMLkPWk for ; Wed, 21 Aug 2013 23:53:44 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB5421F9E01 for ; Wed, 21 Aug 2013 23:53:43 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-6b-5215b567aab5 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 2C.A8.22048.765B5125; Thu, 22 Aug 2013 08:53:28 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.20) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.2.328.9; Thu, 22 Aug 2013 08:53:26 +0200 Message-ID: <5215B596.5030007@ericsson.com> Date: Thu, 22 Aug 2013 08:54:14 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <20130822065048.29182.27861.idtracker@ietfa.amsl.com> In-Reply-To: <20130822065048.29182.27861.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNJMWRmVeSWpSXmKPExsUyM+JvjW7mVtEgg/O3rC0uXTzL5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDUHz7IWHBWuaJjWwdrAeIq/i5GTQ0LAROLvq/fMELaYxIV7 69m6GLk4hAQOM0r0f3nKCuEsY5TYdHAJG0gVr4C2xJEd28A6WARUJQ4t/swEYrMJWEjc/NEI ViMqECzRvv0rVL2gxMmZT1hAbBGgDQ/fnwXrFRZwk/j/fglYr5CAo8TMRY2MIDangJNE54n3 TBAXSUpsW3SMHcRmFtCTmHK1hRHClpdo3jqbGaJXW6KhqYN1AqPgLCTrZiFpmYWkZQEj8ypG 9tzEzJz0cvNNjMAAPLjlt8EOxk33xQ4xSnOwKInzbtY7EygkkJ5YkpqdmlqQWhRfVJqTWnyI kYmDU6qB0XfO5nerpU5vNuzy2vt3vbrPo+w9Qo3is/O2/nygqWFiYPBAguO4crN09qM7+0/6 +x7ZnKV0yZlJWndF0IG3XnMNptvnHLFZ4p/4rSLt69mcvkmsL8UfvbpkUSMu326n/+3cU9k2 Ds4TR572Rk8qYzq/W8PLKYGFw2OPYIjy1nbH5G8f17wTVmIpzkg01GIuKk4EAIvWDdUOAgAA Subject: Re: [payload] I-D Action: draft-ietf-payload-rtp-howto-05.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 06:53:49 -0000 WG, This is a really minor update. Changing some RTP profiles to RTP/PROFILE consistently in the document. I also switched to using the new XML2RFC processor. I intended to wait for the assigned but not done SecDir review. However, as this has been lingering for close to three months now I would like to proceed. I therefore request WG last call of this document. Cheers Magnus Westerlund On 2013-08-22 08:50, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. > > Title : How to Write an RTP Payload Format > Author(s) : Magnus Westerlund > Filename : draft-ietf-payload-rtp-howto-05.txt > Pages : 51 > Date : 2013-08-21 > > Abstract: > This document contains information on how to best write an RTP > payload format. It provides reading tips, design practices, and > practical tips on how to produce an RTP payload format specification > quickly and with good results. A template is also included with > instructions that can be used when writing an RTP payload format. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-payload-rtp-howto-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-payload-rtp-howto-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From abegen@cisco.com Thu Aug 22 01:58:08 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906AD21F9DFC for ; Thu, 22 Aug 2013 01:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lj-LNIkyti5d for ; Thu, 22 Aug 2013 01:58:03 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B4C6C21F9A44 for ; Thu, 22 Aug 2013 01:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=516; q=dns/txt; s=iport; t=1377161883; x=1378371483; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=AVeM1caBh34E0sqp0r4TZJ0Dr+BCglVKeBZ8JYHh5gA=; b=d72Rb1YQaRB3zMPYV3q0RANLJaS0yag011fRpzaxYHOaHyLt/eBS7MKr q37nNtqvErOUIgzOboHZEK+igRVIRjO3e7FWnLj0YGQWwt9eaF9yPBNQx LFO93CGGGtMJikEFPiLgpC7KexUvxupbrYZu88gN7euAXMXX14wnQZp/9 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEGAInRFVKtJXHA/2dsb2JhbABagmQhNVGCVL0xgR0WbQeCJgEEOlEBKhRCJwQbiAgBC5U3mVEEkDWDU3sDqUCDH4Ir X-IronPort-AV: E=Sophos;i="4.89,932,1367971200"; d="scan'208";a="250375056" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 22 Aug 2013 08:58:03 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7M8w3wL014278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 22 Aug 2013 08:58:03 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Thu, 22 Aug 2013 03:58:02 -0500 From: "Ali C. Begen (abegen)" To: "payload@ietf.org" Thread-Topic: WGLC for draft-ietf-payload-rtp-howto-05 Thread-Index: AQHOnxW0JqQDumtvLE+Tk9S9gB3Jkg== Date: Thu, 22 Aug 2013 08:58:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.99.78] Content-Type: text/plain; charset="us-ascii" Content-ID: <35B62767C3476447A78AA33C8D821CCE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [payload] WGLC for draft-ietf-payload-rtp-howto-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 08:58:08 -0000 (As a WG co-chair) I am starting WGLC for the following draft (version 05).=20 https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto/ This is an important document as it outlines how someone is supposed to wri= te the payload specs. If there are sections you don't understand or that are not clear enough, et= c. please post them to the list. We need to get this right to minimize furt= her headaches for future documents in our WG. The deadline for the WGLC is September 20th. -acbegen= From pparrilla@prodys.net Thu Aug 22 07:10:26 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E4B11E80E6 for ; Thu, 22 Aug 2013 07:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.492 X-Spam-Level: *** X-Spam-Status: No, score=3.492 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DYN_RDNS_AND_INLINE_IMAGE=0.001, EXTRA_MPART_TYPE=1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hej7BvTTTud1 for ; Thu, 22 Aug 2013 07:10:21 -0700 (PDT) Received: from host.prodys.net (89-248-106-64.redes.interdominios.com [89.248.106.64]) by ietfa.amsl.com (Postfix) with ESMTP id DCFE811E8174 for ; Thu, 22 Aug 2013 07:10:14 -0700 (PDT) Received: (qmail 36957 invoked from network); 22 Aug 2013 18:10:21 +0200 Received: from 130.230.14.62.static.jazztel.es (HELO ProdysMail.prodysdom.com) (62.14.230.130) by 89-248-106-64.redes.interdominios.com with ESMTPA; 22 Aug 2013 18:10:21 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01CE9F41.095AD6DB"; type="multipart/alternative" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 22 Aug 2013 16:08:11 +0200 Message-ID: <9FB32EAFA4821C45BAC276C7E712701D01776EAB@ProdysMail.prodysdom.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [payload] I-D Action: draft-ietf-payload-rtp-aptx-00.txt Thread-Index: Ac6fQQkHfSSnlX1iQAa+/Hm69jXtuA== From: "Pedro Parrilla" To: Subject: [payload] I-D Action: draft-ietf-payload-rtp-aptx-00.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 14:13:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CE9F41.095AD6DB Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CE9F41.095AD6DB" ------_=_NextPart_002_01CE9F41.095AD6DB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi =20 Prodys, as audio codec manufacturer, supports different versions of this draft, and we would very much like for this draft to become an RFC as soon as possible, so that all manufacturers have a standard document to follow. That would help a lot to all audio codec manufacturers to achieve interoperability. =20 Best regards, =20 Pedro Parrilla Application Engineer email:pparrilla@prodys.net =20 web:www.prodys.com Tlf.:+34916896880 =20 ------_=_NextPart_002_01CE9F41.095AD6DB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

Prodys, as audio codec manufacturer, supports different versions of this draft, and we would very much like for this = draft to become an RFC as soon as possible, so that all manufacturers have a = standard document to follow. That would help a lot to all audio codec manufacturers to = achieve interoperability.

 

Best regards,

 

Pedro Parrilla

Application Engineer

email:pparrilla@prodys.net

web:www.prodys.com=

Tlf.:+34916896880

 

------_=_NextPart_002_01CE9F41.095AD6DB-- ------_=_NextPart_001_01CE9F41.095AD6DB Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEASABIAAD/4QCURXhpZgAASUkqAAgAAAADADEBAgAcAAAAMgAAADIBAgAU AAAATgAAAGmHBAABAAAAYgAAAAAAAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzox MDoxNyAxMzowOTowMwADAAGgAwABAAAA//8BJgKgBAABAAAAuwIAAAOgBAABAAAAQwEAAAAAAAD/ 4n0QSUNDX1BST0ZJTEUAAQEACIBwQURCRQIQAABwcnRyQ01ZS0xhYiAH0AAHABoABQApADVhY3Nw QVBQTAAAAABBREJFAAAAAAAAAAAAAAAAAAAAAQAA9tYAAQAAAADTLUFEQkUAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApkZXNjAAAA/AAAAHRjcHJ0AAABcAAA ACt3dHB0AAABnAAAABRBMkIwAAABsAAAogZBMkIyAAABsAAAogZBMkIxAACjuAAAogZCMkEwAAFF wAACOLRCMkExAAN+dAACOLRCMkEyAAW3KAACOLRnYW10AAfv3AAAkJFkZXNjAAAAAAAAABpVLlMu IFdlYiBDb2F0ZWQgKFNXT1ApIHYyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHRleHQAAAAAQ29weXJp Z2h0IDIwMDAgQWRvYmUgU3lzdGVtcywgSW5jLgAAWFlaIAAAAAAAALVaAAC8ZwAAkjBtZnQyAAAA AAQDCQAAAQAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAABAAABAAACAAACJAQdBdoHaQjZ CjYLhQzHDf8PMRBeEYsStxPiFQsWMhdXGHkZmBq1G9Ic7x4lH1kghyGyItoj/yUjJkQnZiiGKacq xyvoLQguKC9IMGkxiTKmM8I03jX7Nxg4NTlROm07iTylPcI+3j/4QRFCKUNCRFxFdUaPR6lIw0nd SvdMEk0sTkNPWVBvUYZSnFOyVMlV31b2WA1ZI1o6W1FcZl14Xopfm2CtYb5iz2PgZPFmAmcSaCNp M2pCa1JsXm1nbnFvenCDcYxylHOcdKN1qnaxd7d4vXnDesh7zXzOfc1+zH/LgMmBx4LFg8KEv4W7 hreHs4iuiamKpIuejJiNkY6Gj3uQcJFkkliTTJRAlTOWJpcZmAyY/5nymuSb1pzInbuerZ+foI6h fKJqo1ekRaUzpiCnDqf8qOqp16rFq7Osoa2Prn2va7BZsUeyNrMktBK1ALXtttq3yLi1uaO6kLt+ vGu9Wb5HvzXAIsEQwf7C7MPaxMfFtcajx5HIfslsylnLRMwuzRjOAc7rz9XQvtGn0pDTedRh1UnW MdcY2ADY5tnN2rLbmNx93WLeR98s4BDg9OHY4rvjnuR75VfmM+cO5+jowema6nHrSOwd7PDtw+6W 73bwVfEz8g/y6vPD9Jz1c/ZJ9x738/jG+ZX6Yfsp++v8p/1c/gv+tP9a//8AAAHoA6cFLAaEB78I 5woECxYMHA0eDhwPGRAXERQSEBMLFAQU/BXzFuYX2BjMGdYa3hvhHOEd3x7bH9Yg0SHLIsQjviS4 JbMmrieqKKYpoiqgK54snS2aLpUvkTCNMYkyhjODNIE1fzZ/N384gDmCOn87fjx8PXw+fD99QH9B gkKFQ4lEjUWSRphHmkibSZ1Kn0ujTKZNqk6vT7RQulHAUsdTzlTVVddW2VfbWN5Z4FrjW+dc6l3t XvFf9WD4YfxjAGQDZQFl/2b8Z/po+Gn1avNr8Gzubetu6G/lcOFx3nLac9Z0zXXDdrl3r3ileZt6 kHuFfHp9b35kf1iATYFBgjWDKYQchRCF/obth9uIyom4iqaLlYyDjXGOYI9OkD2RLJIbkwqT+pTp ldmWyZe6mKeZk5qAm22cWp1InjafJaAUoQSh9aLmo9ikyqW9prGnpqibqZGqh6t/rHetb65nr2Cw WrFUsk+zTLRJtUa2RbdEuEW5RrpIu0q8Tr1Svle/XcBjwWrCcsN7xITFisaQx5bIncmlyq3Ltsy/ zcjO0s/c0ObR8dL71AbVEtYe1yrYN9lE2lHbXtxr3Xneht+U4JzhouKo463ksuW25rrnvejA6cPq 1Ovl7PXuBO8S8CDxLPI480P0TvVZ9mP3avhu+W/6bPtk/Fb9RP4v/xf//wAAAgUD2AVoBsYIBgky ClILZQxyDXgOeg96EHoReRJ1E3AUaBVeFlIXRRg3GSkaNBs9HEAdPx46HzQgLCEjIhkjDyQEJPkl 7ibjJ9gozCnBKrYrqyyfLZMuhy98MHAxZDJZM000QTU2Nis3ITgWOQs6ADr2O+084z3bPtM/y0DE Qb1Ct0OyRKxFpkahR5xIl0mUSpBLjkyLTYpOiU+IUIhRiVKIU4hUiFWIVolXiliLWY1aj1uRXJNd ll6YX5tgnWGfYqBjoWSjZaRmpmenaKhpqWqqa6psq22rbqtvq3CpcahypXOjdKB1nXaZd5V4kXmM eod7gnx8fXZ+b39pgGGBWoJRg0iEPoU1hiuHIYgXiQyKAor3i+2M4o3Yjs2Pw5C5ka+SpZOclJKV iZaAl3iYcJlqmmObXpxZnVWeUp9QoE+hT6JQo1KkVaVZpl+nZqhuqXiqgquOrJytq667r8yw37Hz swm0ILU4tlG3bLiHuaS6wrvhvQG+Ib9DwGXBh8Kqw87E8cYVxznIXsmCyqbLysztzhDPMtBU0XTS lNOy1M/V69cG2B7ZNtpM22HcdN2H3pjfp+Cz4b7ix+PN5NHl0ubQ58zoxOm66qzrm+yH7W/uWO9c 8FvxVvJM8z30KvUS9fb21vez+I35Yvov+vT7sfxm/RH9s/5N/uH/cf//AAAB2QONBQkGVAd/CJYJ oQqkC58Mkw2CDnAPXxBMETcSIRMJE/AU1hW7Fp8XgxiBGX0adBtmHFUdQR4sHxcgACDqIdMivSOm JJAleiZkJ04oOSklKhAq/SvqLNctxC6xL54wjDF5MmczVTRENTI2IjcROAE48TniOtM7xDy1PaY+ mD+KQH1Bb0JiQ1VESUU8RjBHI0gXSQtJ/0rzS+hM3E3QTsVPuVCtUaFSlVOIVHpVbVZfV1FYQ1k1 WiZbGFwJXPpd617cX8xgvWGsYptjiWR4ZWZmVGdCaDBpHmoLavhr5WzSbb5uqm+WcIJxbHJWc0B0 KXUSdft25HfNeLZ5nnqGe258Vn0+fiV/DX/0gNuBwoKog42EcoVXhjuHIIgFiOqJz4qzi5iMfY1i jkePLZASkPiR3pLEk6qUkZV4lmCXR5gvmRiaAZrqm9Scv52qnpafg6BxoV+iT6M/pDClIqYVpwin /ajzqeqq4qvbrNWt0K7Lr8ewxLHCssGzwbTCtcW2yLfNuNO527rju+28+L4EvxHAIMEwwkDDUsRm xXrGj8emyL7J1srxzAzNKs5Hz2PQgNGf0r/T4NUD1ifXTNhz2ZvaxNvv3RreRt9z4KHhz+MC5E3l mebn6DbphurY7CvtgO7X8DHxkPLv9E31qvcE+Fr5q/r2/Dr9e/67////AIAAgADltH/Nf1TMP3+l fsOyjH+UfmmYf3+efkx943/BfmNiQX/+fpJEYYB/fwUfZIH+gBz8uH50i3nkD35XibLK235PiBSx Pn5chrSXL36ChZt8k36+hLpg6X8Pg/RDAH+Wg3gdooDkg9/6o30llwjiSH0clDHJWH0lkXqvzn1L jx6V1n2GjQ17Tn3XizxftH43iYlBy37AiC0cBH/PiBH4v3wXorDggnwXnsnHsnwrmxSuRXxbl6OU c3yrlKZ6Dn0MkeZelX13j09Atn3/jS0ajH7Ei8n3CXtHrnXe2ntEqXrGG3tdpMSs0nuWoGaTEHvq nFp42nxbmLtdiHzPlU0/uX1SkosZPH3GjvD1hXqqul3dWXqftEjEp3qzrourfHrwqT2R4ntMpE53 snvAn7pci3w9m48+03y8mHYYF3zbkEn0OHovxnLcDXobvzvDYnonuHOqTXpksjaQ33rJrHF20ntE pxBbrnvAojA+DHw7nw8XHHwHj6DzHXnR0sja8Xm0ymHCSXm4wo2pP3nwu2GP53pZtM52BnrdrsZb BnteqYc9Y3vQpNMWSXtSjxHyKnmM34TZ/Xlm1dPBVXlgzO6oVnmUxOKPE3n+vZJ1S3qGtwdaaXsM sdw82nt6qSUVnnrIjp3t7YkTfivWfogAfbG+zYcFfVemtYYwfTOOGoWEfUh00IT8fYxaa4Sbfeg9 joSffosYi4Z6gAHryYeuiQjVAIajh329jYW5hiGlfoT4hQOM0IRkhCpzfYP0g4hZD4Oogwc8OYO4 guAW+YV3hAPp+4Zwk/jTU4V3kXW8EIScjxmkFIP1jROLiYN1i1ZyVYMXidVX/4LYiHw7LILrh5QV iIR7h6joUoVznvjRsoSDm4G6f4OymDuioYMOlTqKOIKgkqFxKYJQkENW94Ibjhw6NIIujJYUOIOJ isnmyISqqhjQMoO7pa25BoLxoYKhP4JVnaSI7oHjmhJwC4GjludWAoF1k/85U4GGkgwTFYKajOfl Y4QMtWLO1oMdsAO3tYJSquqgBYG5pi6H1YFOocZu/YEJnbxVH4DjmjM4iYDzmDgSH4G8jEHkL4OL wNrNrIKcuoK2koHOtHqe9IE2rt+G6IDTqbBuMYCTpO1UXIBloNg33YB0nlgRVIEDi7fjKYMkzJXM r4I2xTu1mIFlvkOeA4DKt8uGCYBpsd1td4AzrI1TxoAIqFY3TYAKo1wQroBsi0fiToLQ2LvL2oHm 0E60xIETyGGdNYB0wRSFToASunps1X/ftM1TPH+6sEg20X+8pRAQKn/0iu7dPJJhfJjHa5B6fEOx Vo6yfBCax40afBGDl4u3fElrnoqCfLFSdYmIfTI2joknfgERMovWf97bRpEthsvGBY9ChYSwKo2D hG+Zsov8g5CCg4qtgvJqjImNgohRXoijgkA1eohJgmAQBIqYg4bZs5AAkSTEnY4iju2u/YxjjN+Y gIrxiyaBVYmzibJpaoimiHxQSofLh3Y0dod5hwUO+olWhrvYR48Im5LDLo0ymHutgYuGlZeXHooT kv2AF4jokL5oU4fmjrxPW4cTjP8znYbCjB0OFIgoiYTW6Y5KphXB0Yx4oiasJIrUnnOV0olomwp+ 5ogyl+pnS4c+lS1OfYZvkswy2YYckcENTocliP/Vp42xsMfAm4virACq9oo+p3eUtIjWo0F94oek n1xmWIanm9pNtYXdmPkyLIWKl/IMqIZLiI/UkI0zu6W/kotntgWp8onCsKaTvohbq6R9Cocwpwhl noY2oudNDIVfn68xnYULnT8MHoWXiDHTo4zLxse+s4sDwEmpFoleuhSS54f0tEl8QobMrwRk9oXc qndMh4UFp2UxJISioToLroUEh+bS4Ixy0le9+4qwyvGoXYkNw+GSMYejvVN7nYZ6t3xkaYWLssdM DYS9rmcwt4RcoPALVYSOh6nM+5vye1u4k5lHeyGj9pa4ewmO3pRgeyZ5FZJFe3hiaZBle/lKco7a fJMvY441fX4KfpAff8DLOprihP23Zpgjg+ejAZWZgvyN+pNNgkt4K5FDgdhhfI91gZpJfo33gYEu eY1XgeMJz46bgwjJ05nfjq22HJcljMKh5ZSYiviM4ZJbiYl3IZBeiFRgg46eh15ImI0qhqAtp4yM hp0JNY1HhejIqJjnmI6045Y9lc6gp5O9kzSLu5FykO12A4+Gjv9ff43SjVJHsYxmi/ss3ovMi80I r4wfhd/HfJgsooazxpWEnvqfe5MLm6yKhJDSmKp07I7ZlfRej40xk6BG7ovFkcQsO4snkb4IPIsh hZHGX5ebrKWyspT1qFmebJJ+pEqJhJBKoI10AY5TnSNduIydmidGQYs0l/crroqUlzsH24pMhVDF ZpcmtuyxyZSAsd6diZIIrQ6Iqo/VqJpzQI3lpI9dE4wwoRNFsYq0ntMrOooSm8gHi4mbhRrEkpbD wXixB5Qeu6WcyZGnthaH7o9ysO5yj42FrFVcfYvaqJlFPopcpkEq2YmonPkHSokLhO7D4pZuzHmw Z5PKxdicKJFWv4WHTo8jubNx/o02tKpcA4uNsRNE1YoarEIqfIlpnLoHFoiZhMu9P6XQenqqHKJo ek2W0Z8cekWDFJwIenJunZk4etRZLJaye2RCU5SifAon85PzfP0EqpN/f6a7s6Tig5SpKqFagpyW FZ4KgdCCYJr9gT5t25g6gOtYY5XCgM5BgpO8gNsnNJMLgXUEaJIDgpq6iKPrjMKoF6BoiwGVJJ0V iW6Ba5oXiCls8ZddhydXipTvhmZAvJLuhegmjpI4hlsEL5C0gtS5fKMblfWm/Z+jk3qT/5xZkTmA X5lOjzNr9ZadjZFWrZQ0jDFAApI0izkl+ZF3i9kD/Y+SgrK4lqJVn2imCp7pnDOS/puqmT9/Vpim lotrBJXYlC5V2ZN8kj8/UpF+kOwlbpC/kVYD046Zgpa3o6HIqQKlNZ5VpRWSLpsRoWt+gpgRnhlq OZVWmyJVIpLrmKw+w5Dslz8lAZAnlgsDr43Ign22y6FXsr2kbZ3hrh6RbJqdqcZ9ypegpdFplpTr olJUlpKAn4M+T5BsnlQkrI+gmMwDkY0agmm2D6D+vLajxp2Ct2GQypo9slx9LJc/rcxpAZSOqeBU F5Itpw0975ASpMMkZY8wmJsDeYyNglm1caCvxyyjPJ0twReQQZnqu198pZbwtj9oiJRAshJTs5Hg r0c9m4/SqagkH470mGwDZYwdgkyuHq/+eeScKaveebaKEKfeebJ3iqQXeeZkR6CYelBP+Z1zeuY6 H5r2e40gKZqYfHEAAJXTf8qszq8ogoObaKrkgZmJfqbagOB2+6MTgGNjqJ+bgCZPU5x/gCM5dJoF gEwfoZmWgRcAAJSOgACr3649iy6aiqn+iY2IvaXtiBp2MaIwhvti5J68hiBOn5umhY441ZkshUsf LpirhkYAAJNwgACrEq1qk+eZqqk3kZqHzKUwj4R1UKFojb1iEp38jFFN6Jroizg4QZhqiqIeypfX i7MAAJJ4gACqQazKnLSY2qiYmcKG86SUlxd0daDPlMBhTZ1LkrBNQpo9kSg3v5e4kGsedZcUkGEA C5GSgAepkKwspcyYL6f8ojGGSKP5nuJzyqA1m+9gqpyymVxMr5mPl2s3TZcKluUeKJZflFgAG5DE gBKo4qu5rwOXoqd9qriFwqNypsNzQJ+so0NgKZw2oE9MQZkcnjs29paAnX0d85XIlEAAKJAZgBuo QqthuHSXGacbs3uFQ6MNrudyyJ9IquRfu5vWp6lL4ZjFpeM2sJYjousdzJVPlCYAM4+PgCKnuasV wl6WpqbEvKuE1qK2t3FyYp72svpfY5uGr7pLnJh1rR82e5XdpNYdp5UJlA0API8ggCifsLqEeXSO 1bWreTp90bD8eTJsZKyLeWdaOKhkedRG76Suemox66HmewcX8KJye74AAJEogACeprm2gaSOQrTC gL19YrAFgA1r86uMf55ZuKdkf3JGbKOuf4MxbKDef8EXsKE7gLoAAJBugACd97jLidWNmrPeiEl8 z68ahu5rVaqjhe1ZHqZ6hTRF4aLGhMww+p/shMQXgaAchgQAAI/LgACdaLfzkhCM+LMPj+d8Gq5S jftqqqnOjGNYfaWriy1FWaH2ilcwlZ8TiiwXXJ8cirAAAI8+gACc1bdGmmmMYrJhl6Z7e62mlTRq BqkkkxhX7aTwkV1E4aE/kDUwPp5SkCoXPp42jrgAAI7EgACcO7a/ou6L2bHRn5J6+q0PnI9pi6iP mfhXeaRal9ZEfaCSlnAv+J2elqQXJ51nj6gAAI5egACbyLY2q6CLcLFEp6V6mKyCpBNpL6gEoQVX JaPUnpdEOaAInUkvxJzwnCcXFZyoj5sAAI4KgACbSrXXtIyLIrDUr9t6V6wDq6to6ad5qDFW36NL pbBD/J+VpJ4vnJyGoDEXFZwXj5sAAI3FgACa2bWGveuKy7B0uIN6Dquhs7ZorKcbr+NWsqLvraBD 3584qqcvkZwvoCkXH5u2j6IAAI2OgACR88VjeRiCH7/SeMtyFrp8eLlho7VpeOpQcbCneVM+C6xz eeQppqmWemoPZqtZewsAAI1DgACRN8SLgOaBtr7zf/hxwrmQf0phSrRtfuJQDa+efsQ9ratffuUp XahmfzIPhanDgEQAAIz+gACQzcOSiKiBR74IhydxXriehdxg27N1hPNPoa6fhFk9UqpahBkpI6dK hE4Pr6hPhO4AAIzBgACQgcKpkGuA6L0jjl9w6be8jJVga7KGiyZPOq2yiiU9AKlqiZMo9qZIieMP 2qcEiQIAAIyMgACQLMHomE+AlLxblbVwkrbwk3RgC7G7kZVO6KzWkCY8w6iSj2ko16VjkBsQBKXh itQAAIxegACPx8FQoGKAQru1nTdwTbZAmnNfz7EJmCxOrqwmlnE8lafQlbIowqSWlbwQK6Tjiu4A AIw4gACPZsDVqJR//LsqpNBwFrWqoYdforBvnt9OiauTnQc8fac6nKwouKPgmm4QTqQGiwYAAIwZ gACPJsBRsPV/zLqhrJNv9rUfqMtfja/jpdhOd6sJpBo8b6a8ov8os6NTm4UQbKNEixsAAIv/gACO 1L/wucl/rrottJtv7bSbsC1fh69RrPpOe6pwq1w8gKYgp/Uo3KLIm6AQsKK4i0gAAIvrgACEtNCf ePN118pZeINmrsRveFtXEb7WeH1Gs7mTeNo1B7UIeVgg9rJ3ea4H67LZe0UAAIn5gACEYs+fgG51 m8l+f2dmcMOMfq1Wzr3WfkRGcbh0fik02bPMflAg9rD+fp8IZ7Dqf+cAAIoWgACESs6Fh8V1b8h8 hkFmQ8KFhPpWmby9hCFGP7dLg540vrKRg4EhC6+Vg/gI5q8og/4AAIovgACERs18jxZ1X8dsjRlm IMFyi2dWdrubihpGJLYoiUg0tbFmiP4hLK5JieQJXa2bhlUAAIpFgACEOcyYloV1WMZ4lAdmHcBw kfBWarqXkElGIbUVjyQ0xLBVjt8hWq0gj3sJzKxChqAAAIpYgACEHcvUniF1UMWkmxpmKL+OmJBW g7mvlplGOLQvlUs0469dlUohkqwYlEAKNKsbhuYAAIpogACD/ssspc91SsTvojlmN77MnztWobjp nP1GXLNum7k1Dq6am60hzasyltsKkaofhyUAAIp1gACD3MqaraZ1RcRUqXZmSr4opgFWwrg9o45G hLLCoqE1Pa34oOkiCqqClwQK56lPh18AAIqAgACDvsoStcV1RcPFsOpmZL2TrPJW8rejqmZGwrIl qN81iK1WpDIiZanbl0ELR6iwh6AAAIqIgADyhntGeYra93uceaXC/Xv2edGqfXxYehyRcHzDeop3 u307exZc9n3De6o/1n54fFwbFn/RfQ/wXHmQhO/ZOnoHg+jBcXqAgwSpFXr+gk6QHXuFgch2eXwX gWRbunyygQo+l31ngNQZdX5fgNvuangmkHTXaHisjlG/13k3jFGnknnMip+OvHppiSV1N3sRh9Va kXu6hpU9dnxrhYkX9nzvhRjsmHb4nAbVn3eFmNO+IHgaldGmAXi8kw2NUnlvkKZz9XonjmtZdXrb jE08bHuFioIWmnuIiN/q8HYFp6PUAHaTo2y8inctn2+khXfXm7mL73iRmEZyvnlalSxYZ3oXkjk7 dXq3j9UVZHpXjBTpgnVLs1LSmXXVriK7KXZsqSijNXcZpH6KvXfaoCJxmHinnBNXbHlrmGY6lnoC la4UVnlnjcDoUHS5vx3RbXU9uPS5/nXOsv+iE3Z6rWSJuXdDqCxws3gWo05WkXjYnus51nlmnCoT cnimjSbnV3RMywvQeXTKw+q5BnVSvQChGXX5tnaIzHbEsGhv6HeequFV53hkphw5M3jjodESuXgI jKjmkXQD1ynPuHR5zwy4OnT2xzGgRXWUv8iH/3ZcuPdvL3c4suhVRngAri04pnh3pk0SJXeLjETh 44Qud+XMM4OjeDu18oMueJie/oLReQyHWoKLeZ1u8IJdektVYIJPewI5JoKZe9MT34SdfI7gH4Kg gr3K94Ipgfe03YHFgU2d34F5gMyGI4FDgHRts4EpgEBUHoEwgB437oGDgCwSeIMggKbehIFKjavJ ToDhi96zUYCHii+cZ4BRiMOE1IAyh4xshoAuhoFTDIBAhY4254CNhOIRPIGyhHPc54AqmJfHpH/F ldWxqn92kzqa6n9GkNSDfH88jsJrWH9IjN5SCH9kiyQ1+n+sieEQK4B1h8HbYH89o5LGJH7Yn+qw Mn6QnGuZgX5pmSSCL35hlhdqOn5+k2hRFX6jkPM1IX7ij0oPQH9lilDaDX6Frq3E2n4gqiSu7X3V pb2YS32xoY+BFX2wnalpMn3LmhtQOH35lws0Xn4ylV8Oe36AicrY833zuerDyH2OtIGt2n0+rzGX PH0YqiCAI30epW9oYX0/oSdPfH1nnYwzuH2Zm2YN2H3DiVzYEH2FxVnC630fvw6s8nzIuNeWUHyZ suN/RHygrW1nnXzLqJVO2nz3pNkzLH0boFgNU30oiQLXZH010RfCPHzQyeesMHxuwsaVgnw0u/d+ hHw4tc1m93xlsJdOVHyXrJYyuny3okwM6HytiLrRwY1RdpK9tYvrdwapA4qpd36TfomOeAl9MYiX eLJmBYfFeXpNnocoekkyOIclezEM1okkfHnQPIvxgMe8fIqZgD6n2oljf86SaIhVf358H4duf1dk +4auf1FMlIYef1wxNYYaf5gL7IeLgFrO4oqpixu7IYlfiZymrIgriDeRL4cwhw168oZYhhNj4oWp hUZLj4UmhJYwRIUhhEQLHoYkg8LNfomPlXW5sYhJkxelJoclkNqPzYYujs95sYVsjQtix4TMi3ZK nIRRihUvboRGiVkKa4TshrfMJoiwn9q4V4dsnKujzoZOmZ6OgYVdlsJ4hISYlB5hwoQIkdFJwIOT j9Aur4N+jvEJ0oPhhqTK9ogAqmi3L4a9pmqiqoWeooiNaISwntp3goPvm29g04NYmF5I+4LqleMu B4LQlQ0JUYMAhkzJ+YdytRm2N4YxsE6hsYUPq5eMdYQgpxp2p4NmovdgF4LSn0dIVYJYnHUte4I4 mkkI5oJGhgTJLIcDv/+1bYXFumeg34SftN6LoYOpr5J13oLvqsJfZ4JmpqRHx4Hto/ktBIG6nnAI j4GuhcnIkYauyz20zYV0xNigL4RJvnqK6oNLuGh1NYKOswBe1YIGrrVHSoGTqtYsl4FeniYISoE1 hZvCB5a9dYSvWZSKdgucDZKDdpeH8JCudzZy+I8Hd/NdBo2UeMtFuYxyeaYrA4xOeowGqYz/fJzA vJV9fyyuU5NQfsubFJFTfn6HAY+IflNyCY3tfk9cHIyIfm1EzotvfpkqJ4tDfvoGLItsgBe/jpRX iNitGJI0h52Z+5A2hnWF5I54hYlw/4zqhMZbKIuShC9D8YqBg7opY4pNg7kFvooKgya+b5NBkqer 5JEokJmYuY83jqGEyI1wjONv64v0i2ZaMIqoihxDGYmeiREoqolliOcFX4jXg6G9R5JnnIWqz5BO mbKXmY5hlwODlYyqlIVu2YsokkFZQInrkFJCU4jkjscoCIigjsoFDYfQg2q8PJG/poapxY+poviW kI28n4eCl4wHnEpt8IqHmVFYbYlAlrtBp4g8lN8nfIfwlDsEyIbzgzy7W5E5sKeo6Y8lrF+VtI01 qCyBwIt+pDRtLIoEoJhXxoi9nYNBGYepm5UnC4dVmL4Ej4Y8gxW6pJDPuwGoNo69tgCU+YzKsQ+B BIsOrF5seYmUqDBXKIhXpNdAnYdAotwmqobWmiQEYIWmgva6GpB8xbqnp45twAOUW4x4ulKAYIq2 tPJr4ok3sE5Wp4f7rRJALYbsqMQmSIaBmeIEO4Uvgt2yw6B6dMOhSJ2IdU6PPJrHdeJ8aJg9doxo sZXpd1NT6JPaeDI9oZJFeQwjZ5JJedQBSpBZfLqxsJ9gfeagfZxrfZiOfJmsfWN7qpckfVFn7JTY fWZTJJLSfZ0825FAfeEiuZEzflQBLI7Mf92wu55Ghw6feZtchfSNj5ibhPl6tpYghDNnBZPdg5xS UJHhgzE8HZBTgu4iHpA1gzsBEY1vgLmvvJ1TkDGeaJptjmCMbpe0jLZ5t5UwizNmE5L6ifpRfpEF iPM7bo94iDkhlY9KiLMA+oxAgKmu1ZxwmYqddpmTlwSLcpbilKd4s5RlknNlMZIbkIJQtpAzju46 yo6njdwhF45tji8A5os9gJyt85vMowicrJjun9GKqZY4nL534JO8meVkY5F9l1dP/4+KlT06OI3+ lBIgqY23kuAA1opjgJGtMptNrKCb7JhvqMGJ6JW3pP53JZM6oX5jupD/nmZPbo8Km/E5wo1qmwIg VY0WldwAyImugIeskJrrtmqbUJgNseOJSJVRrXV2hZLOqVZjIJCTpctO5o6no0o5WY0AoVsgDIyQ lasAvYkbgICsFJqcwJ2a05e+u2+IvpUAtlZ195J4saJin5A5rc1Oeo5Mq104/IyupmUfvow+lXYA tIilgHqkCaqRdDmTn6bsdLyCsaN8dU9xBaBFdfxec51KdsVKvJqod6I1V5i+eGsbQJlreOwAAI2e fxGjMKmWfOOTC6XnfJuCJKJwfHNwdp80fHBd2pw5fJdKIpmbfN40v5etfS0a0Jg1fZgAAIxsgACi c6iKhYiSP6TkhIWBbKFmg6Rvsp4xgv5dH5s8gohJeZijgkQ0LJaygisabZcZgsYAAItggAChsKeV ji+RY6P2jIOAfaCAiv5u251EibJcVZpZiKtIy5fFh+EzoZXRh3gaE5YaiDgAAIp3gACg46bUluaQ l6M1lJp/qZ/Ckn9uApyIkJ9bnJmJjvZILJb9jb8zJpUCjS8ZyJUtjO0AAImvgACgOqYin96P7aKJ nPN+/J8WmjVtVpval7Za+JjalYZHoJY5k+Uyu5Q7k4kZhJRWkOoAAIkHgACfnaWhqPKPZ6IFpWd+ d56KogZsyJtGnvNabphOnFtHKpWympMyYpOdmhAZUJOikR0AAIh8gACfFqVDsjSO5qGkrhB99J4j qhVsSJrapnpZ9Zfgo5RGvpVMog4yEZMun3QZJpMQkQEAAIgLgACeqqT5u96OfaFUtyF9hJ3Qsotr 15qDrnpZkJeGq4NGbJTvqUIxzpLYoawY95K1kOEAAIewgACV8bUIc8SGfbC4dDd2kKyidMJl76jF dWxUZ6UrdjFBoqIIdwMs8J/4d6wSbqIcd6wAAIl+gACVVbQifAGGH6/Fe7R2NKuee5Bljqeye5ZT +6QRe8hBOKDpfBosj57JfGkSVKCdfK8AAIjEgACU1bMZhCyFjK7DgzR1sKqTgmVk/KapgdhTb6MH gX9AvZ/ggVssL520gWcSP58/ggkAAIghgACUTrIfjFOE7K3PisJ0+6mkiWBkWaWxiD9S1qIYh2hA PZ7yhtgr0py6hsESK54GhsoAAIeTgACTu7FTlJKEVK0EknB0WajckIhjsqTpjt9SSqFAjYQ/yJ4f jKErgZvbjKgSG5zuiuIAAIcZgACTKrC3nPmDy6xmmktz1Kg4l9VjL6RBla1RzqCUk+U/Zp1ZksMr QJsLkxMSEJvyjDYAAIazgACSvrAlpYWDYKvVoktzaKeln0pixqOtnKdRbqABmo4/G5y/mXorEJpG mJQSCZsMjDIAAIZegACSU6/FrkWDG6tsqnhzJqcspuNieKMfo8lRHZ9toY0+zpw9oLoq2pnKnPkS B5pdjDEAAIYZgACR+696t2yCyqsXsxFy1abQrvFiKqK/q3xQ3J8JqXM+npvUps0qvJlknOUSBpnm jDAAAIXigACIdr/lc1F54br1c61q2bZDdCtbJ7HKdMxKiq2edYc4k6oUdkYkUqgrdrcKWKoHdxcA AIYMgACIHr8Fey55uboIetRqrrU8eqxa9LCrerZKT6xueu44X6jVe0MkNKbHe4EKn6gufGIAAIW2 gACH3r3ygul5Yrj9gfRqXrQmgS5alq+PgLVJ9qtMgHQ4GqesgGwkE6WBgJQK36aDgSYAAIVrgACH l7zniph5Abf1iRtp57Mih9RaLK6BhtdJlKpBhi03z6adhdUj8qRbhhgLF6UHhVEAAIUpgACHPrwK kmB4pbcWkGJphLJBjqZZwK2ejTNJP6lOjBw3j6Wsi5Yj16NWjD4LSqO5h6IAAITxgACG37timlN4 ULZnl9ZpNbGIlZxZdazfk71I+aiMklU3XaTTkcYjw6JrkegLdKKUh78AAITCgACGh7reol94CbXa n2Ro9bDvnK5ZOaw+mmtIwqfsmNs3OaQsmKojuqGYlqMLnKGUh9kAAISagACGTbpiqpV31bVapx5o xrBro/ZZD6uzoWVImqden+U3FKOmnwojqqD8mB0LwKC0h/IAAIR7gACGDboRsz53wLT4rzlot6/z q4NY9asjqKhIiKa9pzk3E6L9pA8jwqBgmC0L8aAdiBMAAIRhgAB7bssxcv1tmcW2czdfWMB/c5pQ c7uCdCdAnrbfdMsvRbMhdWQbBrH4dWsDb7BNd4kAAIMkgAB7aMpAeohtq8TCehFfXr9redlQcLpJ edpAmbWHeg0vUrGoelYbR7Axel8EC64vfEYAAIMigAB7cskSgdltl8OegNhfR749gA9QTrkLf6BA fbQ6f20vULBHf3cbfa6Sf6sEl6xJgHUAAIMhgAB7cMfoiRRtfcJzh55fF70RhmdQJbfUhYVAXrMB hQIvSq8ChN8bra0dhYQFEqqbg24AAIMfgAB7W8bskGVtZcFwjoBe/rwEjOhQArbCi6VAT7Hfis8v UK3ciqwb36vQizAFgakkg7kAAIMegAB7OcYll+RtVMCalZBe97sfk45QA7XVkfZAT7DukOwvYazS kQEcFaqmkAsF5Kfhg/sAAIMdgAB7F8WEn3VtR7/qnLNe97pgmkdQCrUMmGZAW7All10veawAl3kc S6mjkyEGO6bOhDcAAIMdgAB69sUGpzBtP79bo/1e/LnBoSxQFrRhnxRAZ691nlkvjatWnNMceKjg k0AGh6XrhGoAAIMcgAB63MSdrz5tPr7hq5NfCbk4qFtQKrPMpjNAha7XpM4vuaqwoEUcs6gxk2cG yKVGhJYAAIMcgADmH3ZwcxjQG3dLc/G5gHgfdMyiKnjqda+KJHmydqFxY3p/d6NXhntPeJ87L3wx eZYWnX0heejkD3SHfmjOa3WJfhu3+nZ8feWgy3dlfcqI3XhLfc1wLnkzfeRWW3oVffk6B3rvfhIV IHtUfcHiMXLwidLMmnQCiGS2X3UKhxKfRnYKhf2HfncIhRFu83gGhEJVPnj2g3k4+XnEgsQTxHnV ggvgaXGTlTjKzXKukr+0nHPAkGydsXTRjkyGEXXmjHZtsnb2isJUKnfyiSE3/niyh7cSlHiLheze yXB1oJ3JMnGSnS+zAnKrmeecK3PFltWErnTlk/hsfHYHkWlTI3cLjvo3FXe7jP4Rj3dxiT/dbG+Y rA3H2XC0p7qxqnHLo3+a23Lon3qDd3QPm7RrWHU1mDNSLnZBlQ82QnbhksUQtHaEi0vcTm7rt4zG wXAEsluwi3EVrTGZvnIwqDyCcnNdo5pqcnSKn0xRWnWUm3U1j3YlmSUP/nW/itDbb25twx7F5W+B vRWvo3CItwSYy3GbsSOBhXLJq6xppHP9prZQr3UJons09HWFnrUPanUfimzay24bzsbFRG8px+Su 63AhwPOX/3EnujaAu3JPs/xo63ODrn1QCnSOqkk0Y3T9oygO9HSfihzWFX8OcbbB5X8Qcsqs9H8d c8+XH381dNGAdX9Wdd1o7n+IdvZQMX/PeAg0moBZeQcPWIHyeTzUjH1RfH/Asn1zfHqrzn2XfHyV /n3AfI9/U33zfLln0343fPdPHn6NfTQzkH8SfXIOQYBIfYPTAHvSh1C/B3wChkKqQXwzhUSUgXxx hG99/ny7g71mon0VgyZOC312gpgyk33tgiUNTH7SgYPRbnqGkhi9ZXq8kBmooXr3jjCTDXtAjGl8 qnuhit1leHwMiXJNCXx2iCExrXzehx4MeH2NhPzP83lynOm773mqmgunLXntl0GRpHo/lJh7Znql khxkW3sij+dMGXuTjeEw3HvqjH8Lwnx3h/POs3ibp9K6s3jUpB+l8nkVoHGQcnlqnOZ6SnnWmZFj VnpTloRLPnrMk+YwIXsVkoILKXuNh4vNrnfxstO5sHgqrk6k6nhlqb+PbHi5pVR5WnksoTRihXmu nXFKhHohmksvg3pcmHIKqnrLhzbM5HdzvfG443equKCkEHfcszWOi3gnret4gXibqQlhxHknpLdJ 5XmcoWsu/HnBnU4KQnothvDMVXceyT64SndRwyOjX3d3vOCNy3e1tsJ3yHgksS9hIHiwrHtJVHkn qPIufXlBn28J8HmvhrjGfogYcIqz/Iczcb6gkoZyctqMG4XRc+52t4VHdQtgXITcdjVItISed1Ut xYT0eFII3IZPeWDFRoaAeriy6oW7euqfc4UMexuLB4R1e1d1qoP5e6dfW4OcfAlHuoNofGks2IOy fMAIL4SqfXXEEoUOhPmxqIRchDGeX4Ozg3KJ2YMsgtJ0h4K6glReUYJrgfNGx4JEgZ8r+4KFgW4H mIM5gQvCrYPHjyqwMYMWjY2cyYJ8i/eIcYIAinxzQoGoiTZdNYFriBJF1YFKhxMrLIF4hn4HFIH4 hCjBVIK9mWGu2IINlv2bdYF6lJ2HKYEFklFyG4CwkC1cNYCEjlRFAIBojLwqeICEjAkGo4DmhH3A MIHto76tuIFAoJaaV4CrnWSGFIA4mkVxHH/nl1pbUX+2lMJERH+hkrQp13+wkhMGRH/+hD2/RIFJ rjesy4Cfqk6ZZIAFpkuFIH+OoltwPX9Enrhakn8Ym4JDpn72mSIpUX74l0IF9n8/hAi+kIDOuNqs EIAmtDKYmX+Er2CETn8Cqp9vc363pk5Z2H6VoqlDDH53oHAo335em4IFtn6jg9y+FIB4w8Grgn/T vmOX7H8kuMGDk36TszVuxn5ArklZRX4gqnNCk34HpzAoeX3mm14Fg34mg7q3XJFXb7GmNY+ecO2U IY4cchKA9IzJcy5sy4uYdFRXk4qVdYZA74ngdqQmgYo7d4EDKookeb22WI/heVOlQ45HeZ6THozU eel/+YuHej9r1opfeqlWqolmeyRACoi1e5glsoj6e/QC24iEfWm1SY6LguqkDI0Cgl2SA4uSgdN+ 14pTgWlqzIk3gRlVu4hKgOM/NoeegLok+ofOgLgClYcWgKK0LI1NjJWi1IvLiz6Qtopqieh9uYkq iLRpvYgfh6xUzoc+hsc+a4aYhg0kUIa2heYCWYXZgZazBYxLlkmhworLlDiPnIlvki18i4g6kDdo sIcxjmtT34ZhjOU9pYW9i68js4XEi7kCJYTKgXOyBouFoB+gvooJnVmOmIismo97kod5l9pnyoZx lVtTEoWYkzE8/oT3ka4jLITskSEB+YPlgVaxNYrpqg6f64lxppaNwIgPow16vIbZn51nBYXVnHtS aoT9mdQ8dYRKmD4iwIQwlZ0B1YMngT2wkopytCefQIj+sAKNCYeWq756AoZWp5dmUYVQo+FRxoSD oPQ78IPOn18iYYOUlz8BuIKNgSmwIIoavouevIiqucKMboc7tMZ5XYXvr+5luYTiq8BRRIQTqOY7 f4NkpTEh/4MilvwBoIISgRmom5rpbwiYjphzcEGHpZY8cWl1sJQ8coxitZJoc7dOkpDVdOc41I/C dfQeo5CGdoQAAIpye0WnypmdeCeX0pc9eICG15UOeN105JMNeUdh65E7ecVN0I+selA4GY6Veswe Bo81ewsAAIjZfpOm75hXgTuW0ZYJgMqF6ZPbgGVz7ZHlgBxhBZAdf/FNAY6Yf983Y42Bf9Ydd43+ f/MAAIdygACl9Zc2ikCVwpTqiR+ExpLHiA1y9pDNhw9gG48ThkFMOY2WhZU2wIx+hRsc/IzdhWYA AIY7gAClC5Yuk3GUzpPskaODy5HQj+Jx9o/cjjNfRo4WjLNLfoyli302KouMiq4cj4vQiuMAAIUw gACkNJVvnMaUDZMvmlGDCpEOl95xJI8alYZed41ak2hKyovfka41mIrFkMccI4ryj5EAAIRPgACj gZTapi6TUpKeoxmCSpB6n/pwaI6BnPxdyYzDmlNKNotGmD81JYoWl5Qb0Yosks8AAIOVgACi8ZRp r7uSvZIxrAuBq5AHqEZvx44EpKddLYxEoYpJporPn2Q0tImYndkbi4mHkp8AAIL9gACiipQWuZqS SJHgtVuBI4+usPNvOI2hrL9cqovYqVJJN4pgp0g0UokwotcbN4kYkmcAAIKEgACaUqTbboSLPKG6 b697WZ7dcNJqe5w4cfRYlZnGcxtFbpevdD8wcpZldSgV/5hNdSgAAIYgfmmZsqO7dy6KtKCkd4V6 w53Bd+lp5JsReF5X/JibeOdE3ZaCeXov6pUqee0VppbUedwAAIUAgACZC6KGf8GJ6p99f156CpyW fw1pH5ntfuBXRpd6ftBEO5VmftkvYpQHfugVVJV4fwgAAIQEgACYSqFliEqJDZ5jh0R5GJuGhlNo TpjZhYRWgJZzhONDk5RkhGou3pL/hCsVB5Q+hIAAAIMogACXfqB8kN2IQ518j0J4R5qhjb1ndJf3 jFhV0ZWBixpC/JN7ijUubJIMidEUypMbiUAAAIJsgACW15+wmauHl5y5l3p3l5nflVdmyZcvk1NV L5S3kY1Ce5KbkEAuDJEnkA4UkpIUjUYAAIHOgACWRp8coo+HGJwon893FZlEnQ1mOZaKmnRUnZQV mEFB/5H8lskttJBtloUUYZE4jcgAAIFLgACVzp6xq5eGnZu9qE52kpjSpPlltpYOoddUHpOVn1FB h5GCnhAtWI/pm+AUOZCEjawAAIDggACVdZ5itPCGO5trsSl2Iph4rUZlQZWqqa5TtJMqpw5BL5ES pTotDo99nnYUApAMjYcAAICLgACMnK80bgB+V6t7bxdvXagDcC9feaTAcUtOjKG7cmg8QZ83c3cn zZ33dCQNL6C4c8UAAIJ/gACMLK45dkF+Bqp6do5vAKbtdvJfGqOVd2xOK6CDd/s76J30eIwnhJyZ eOQNOp7ieNEAAIHFgACLuq0Nfl19c6lYff9ufKXCfbtei6JpfaJNp59Wfag7eZzHfcYnM5tXfd4N P502fjsAAIEhgACLMKvqhmd8z6g6hXdtw6SrhKJd66FNg/lNEZ5Dg4E7AJu0gzYm4Jo1gy0NP5u1 gxEAAICTgACKm6r5joN8NKdNjQ1tHqPBi7RdQaBiioFMiZ1MiYk6jZrBiOwmlJkxiP8NP5pchz0A AIAagACKEKpBlsR7rqaWlM1smKMFkuxcup+hkTlMCZyFj9E6MpndjvQmW5g/j1sNQpkniPcAAIAA gACJqKmenyB7QKX4nKtsJqJkmkZcSJ79mBhLoZvellw545kulYYmNpdelNwNSpgRiPwAAIAAgACJ S6k0p6d7BaWKpL1r56Hkoc5b+J5inyNLSps5nTk5ipiZnKwl85bLmXINSpc5iPwAAIAAgACJA6jo sIJ6vKUzrSprlaGCqcBbo532pr1K/5rFpPo5TpgfosQlyJZRmYwNQ5agiPcAAIAAgAB/crn/bWxx 4bXAbmljsbG9b3FUq63pcIBEmapgcY0zAaeTcngeu6bRcsEFvac/c20AAIAAgAB/M7kfdVBxx7TJ dYxjkbCedelUiqypdmJEdqkJdvAy66Ymd3UexKUwd5IGIKUheMUAAIAAgAB++bfxfP5xb7OffJ1j Ra9nfF5UM6tofFREKqfCfGsytqTVfJYeuaO1fKEGcqM2faMAAIAAgAB+qra/hJJxBbJxg7Bixq49 gvFTyqo4gmZDyaaWghQycqOkgfAepKJighYGtqF/geQAAIAAgAB+TLW/jDhwpLFyiuFiW60+ibBT Vak3iK1DdKWGh/AyMaKTh54ekKE0iCsG8Z/6hLEAAIAAgAB98LT+lAZwT7CtkkBiCKxxkJdTAqhi jyZDJaSqjhIx/qGdjbUegaAjjeAHIZ6jhNIAAIAAgAB9n7Rpm+ZwC7ASmbZhxqvJl5lSvqevlcRC 4qP2lIIx0qDelHoefp8ukqcHTp14hPEAAIAAgAB9arPpo+Vv2K+OoVBhkKs9ns1ShqcbnKlCrKNc m3AxnKBKmuIeZp58lI0HeZx2hQ4AAIAAgAB9NrObrEdv0K8rqVZhhKrBpl1SZKaCo+tCkKKtosMx lJ+Pn/Medp3JlJkHoJvFhSgAAIAAgAByr8VIbN5lpcCsbbRYHbw5bp9J07fsb5U6dbQBcIEpU7E0 cS0UlrHpcLgAAKspdHsAAIAAgAByosR3dHBlw7+xdItYOrsEdNVJ8baGdUA6lrJ2db8pja9/diEV Fa/EdbsAD6npeOcAAIAAgAByo8M6e7hlqr5ye0VYJrm1ev1J1rUkevc6iLEDexIpnq3yezgVbq3e ewQAo6fTfS4AAIAAgABylcHtgtplgL0mgfhX57hqgUJJqLPSgMw6Zq+tgJYpnKyKgJAVr6wwgMwB IaX4gMQAAIAAgABydsDSigtlX7wHiMhXwLdFh7ZJdbKohto6Ua5zhlEpnqtHhkkV7aqvhpABkaRV gQ8AAIAAgAByUb/5kWhlSrsfj8tXsrZOjlRJZ7GojSI6Qa1sjF4pqKohjIUWJ6lYi4MB8aLqgVAA AIAAgAByML9QmNNlP7piluBXrrV/lQpJY7DPk406P6yQksIptqk4kwcWYKgtjyECR6G0gYoAAIAA gAByE77ToGBlPbnMnhpXsbTVm+5JZLAWmjo6OqvSmbYpt6h9mHkWhadNjzoCjaCzgboAAIAAgABx /r52qDZlQ7lQpaJXu7RDoyhJa693oWs6RaspoFEp0KfKnEUWqKaPj1ICup/zgdgAAIAAgADZtXGB bKrFDnLXbjevv3Qbb7eZm3VJcS2CrHZrcqNq63eKdBtSBXigdYI2enmgdsASAnp5dq3Xt29Xd97D cHDceEeuSXJBeLeYS3OPeTSBdHTSeb5px3YOelFQ63c0etY1aHghez4QznjCeq3V4m2Egx3BpG8b gmestXCZgcKWzHIAgUmAHHNegOpok3SygJxP2XXlgEo0bHa8f+8PwHdBfyLUGWvqjkq/1W2OjJCq 7m8ZivCVOnCXiXV+sHIOiDFnV3N2hwROzHS0heIzgHVyhNsO1nXzgzDSemqUmW++O2xAlsypVG3W lD+Trm9ekdV9UnDij5RmJXJejZFNznOki6gypXRHihgODnTUhqjRJmmKpJ2862s4oSOoAmzPnaqS YW5cmlF8HG/olyplCnFolD9M43K2kaYx4HM/j84NZXPjiQ7QFWi5r9S73Wpnq4qm62v5pyuRSW2F oud7GG8YnuZkJnCfmzNMGXHol+8xOnJalhQM2XMbiLDPR2gfuxW7EGnLtgGmDGtTsMOQXmzWq5h6 L25qpsZjV2/4om1LcHFDnsgwqnGXm5AMZ3J5iGLOuWe8xmC6gGlhwH2lYWraumOPnGxNtGB5bW3a rs9ip29oqe9KznCuplAwGnDrn+4MDHH3iCXKWnnka4u3fXpkbUujwXrmbuuPAntocHR5VXvucfpi tXx8c39K0n0VdO4v4X3Qdh4LOX9kdjfI6Xfodjy2V3iRduSipHktd4ON7HnEeCJ4QnpdeMphr3r/ eXpJ2Xuiehou9XxJepAKa32xeqjHZXYqgOS0rnbmgIehHHeVgCyMc3hDf+h28nj1f7lghXmtf5hI z3paf3MuB3rlf0AJtnwzftbF03Sli3qzC3VrijOfeHYniPKLA3bkh8R1oneuhr9fX3h4hdBH1Xkt hO8tMHmchDQJGXrognfEW3NdlhOxl3Qqk/aeBHTwkdmJl3W3j810ZXaJjeFeSHdmjC1G7Xggip0s bHhyiYoIk3nMhZPDJHJboMKwYnMsndecznPymt6IaHS+l/RzSnWXlTNdS3Z0kq5GG3c0kIsrvXdr j3oIInjdhYDCK3GPq36vZnJhp8ybzXMjo/mHaHPuoDNyXXTPnKxcfXWxmXZFanZpltErLHaHlVcH xHgXhUDBbnD4tk2upHHHsdma+nKBrTGGjnNEqJNxh3QmpE1bvXURoIxEznXJncAqrnXHmiMHeHd2 hQ3A8HCUwTauF3FevAOaUnIJtomF1nK+sR5w1XOZrCtbHnSEqAhEO3U7pRAqKnUjnIIHO3b2hOS7 boKUapyqMYI4bHiX64H5biqEeYHRb79v/IG5cU1acIG4ctlDgIHddEcpBIKBdVMFPIO7do26TIC9 dLOpEICNdY2Ws4BldlaDT4BLdxdu5YBCd91ZcIBQeKZCk4B4eVooLoD8ecgEyIIMetK5HH8Ofs2n wn75freVmH7ffpyCJH7YfoZtz37cfoNYeX74fo1Bun8nfpInbn+OfnwEYoCRfpK3vH2UiNWmXH2G h+6UDn18hv6AyX2BhhVskH2fhUxXYX3MhJhAzH3/g/YmqH5Eg4QECX9IgdS2bXxZkuGlC3xQkTiS v3xQj39/hHxdjchrd3yAjC1WaHy+isc//nz0iZAl/30YiQYDvn4vgoi1VXtinQyj83temqORqHte mB5+dXtulZtqeXuVkzxVinvPkR4/RnwJj3UlaHwPjwADfn1Bgly0dXqep0mjDXqdpCaQvHqZoNV9 inqnnYhpoHrUmnVUznsSl78+rHs+lcYk7HsqlCADSXx9gjmzzHoLsaCiWHoMrcaP+Hn/qa98wnoE pZlo3Hoxod1UGnp5nro+GXqjnOQkf3pqmFIDHnvdghyzXHmnvCCh0nmnt5iPVnmNsr58FHmDrelo OXmoqZdTjHnupkE9l3oao3wkC3nNmF8C/HteggSs2Iu9adqc+YqAa7uL/Yl+bXB5wIipbwhmaYfx cJhR7IdiciQ76Icgc4UhsYf1dE4AAIeBdySr84oCc2WcB4j4dFWK7ogMdTJ4uYc/dghlcYaNduJR B4YGd7w7EYXAeHgg9oZqeMcAAIWVexWq8IhqfNua1Yd7fPmJ2YaYfQt3nYXafSFkcYU0fUZQKYS4 fXU6UYRyfZkgVYT0fZAAAIPmfoqp0Yb2hlqZpIYPhbeIkIU+hQB2i4SGhFNjeYPtg8NPXIN5g0k5 poM4guMfxoOYgrgAAIJvgACopYXDj9uYmITgjoqHg4QXjSJ1YoNni7Zib4LWimROa4J1iUo44YIy iG4fMoJmiHsAAIEugACnq4TXmX6XloP6l36GgYMwlVx0b4KAkzNhjIHxkTBNqoGGj3g4RYFFjlIe tYFYjd0AAIAggACm4oQcozKWyINFoIiFrYJ2naxzmYHCmspgxIE3mCZNAIDNlfI3x4B2lLoeUYBs klcAAIAAgACmSoOPrQiWI4K+qbqE+IHnpiZy4YEmooxgEoCXn1ZMU4A5nNk3N3/fm7Ud+H+nlEQA AIAAgACl44MttxqVpIJgszOEXoF8rutyPICpqqBffIAQpu9L13+vpHo2zX9YoXkdnn8NlAcAAIAA gACeppUeaU6P1JMmayN/7pF5bNRuzJADbmpcjY6wb/ZJD42dcXQz1o0QcrIZh46icvYAAIMWeryd 7JOUclqPFpHIc01/FJAndDNt+o6sdRRbxI1YdflIVYxFdtkzKIutd4oY/Y0Ad4MAAIGhfh+dGJIT e06OEJBie31+IY7Ge6dtAI1Ye9ha4IwNfBhHjosBfF8yfopjfJEYfot8fGwAAIBagACcGZC3hCuM /Y8Lg7N89o1+gzVsCYwQgrhZ+orWglhGzonTggkx5Ykwgc0YEYoSgdkAAIAAgACbJo+EjSyMAI3i jBB7+IxeiulrCIr2ib9ZLYm1iLJGHIi+h9wxWYgXh1AXsIjGh1gAAIAAgACaUo6gllGLP40GlJh7 N4t+ksRqNYoUkPBYXojVj0ZFbYfUjfEwy4cpjU0XSYesjAUAAIAAgACZpI3vn4KKh4xanTB6eYrN mrVpeolemD1XrYghlgpE1YcclFswXoZXk/QW/4ayj40AAIAAgACZHI1oqMyJ9YvYpel53IpEos1o 3IjJn7dXEoeInQ9EQIaLm0kv5oW9mikWvoXhj2EAAIAAgACYvY0IslaJhIt7rvF5VoncqzloTohS p5BWkYcGpJRD1YYEovYvhoU4nx0Wa4VIjygAAIAAgACQ2J7haMyC15xMao1z35oCbDRjxJfvbcVS h5YLb0k/7JSGcLErSpPocbMQbJbecS8AAIAAfdCQQJ2NcWOCSJsQclFzPJjDczpjJpajdCJR8JS2 dQw/ZZMqdekq05J1dnoQOJT1dfIAAIAAgACPmJwhedmBdZm6ehJyfZdtek1iYJVTepVRPZNqeuk+ y5Hhe0AqWZEce3EQBpMveyUAAIAAgACOz5rMgj2AkphugdtxhJYtgXlhkJQTgSZQe5I3gOo+KpCz gMIp3o/igKkP0pGSgKoAAIAAgACOAJm0iqh/xpdZiblwtJUdiMdgtJMHh95P1pEchww9m4+ghnop d47Bhj4PrZAWhXsAAIAAgACNVZjGk0d/F5Z4kctwAZQ8kEBgCpIfjrpPM5AzjWA9JY6fjGopIo22 jF0Pi47AiZEAAIAAgACMxpgYm/d+mpXPmfhvgpOJl9RfepFglblOno91k/E8pY3iks0oz4zYksUP aY2dimsAAIAAgACMVZeZpL9+IpVSokNvAJMDn5Ne9pDNnPFOHY7cmtQ8Jo1Pmdwoa4w4mBoPS4ys ilcAAIAAgACMAZc9rcR9w5T0qtxukZKap6hegpBWpJFNtI5bolE7z4zGoPUoH4uvmyEPHIv5ijcA AIAAgACDiakTaDd2PKX2aeBoFaMea3hY4qB4bP5Ii54ObnI2spw1b7ciXpvjcFoIWJ2vcCAAAIAA gACDEqfycGd13qTWcUdnraHncixYgZ8ncxZIMJyrc/42Z5rDdMsiK5pHdR4IgJt0dTEAAIAAgACC lqaWeGh1P6OIeKJnIqCTeOVX753SeT1HsJtUeaA2AJlnef4h65jMehUInZlneqcAAIAAgACCAKVC gFB0kKI6gABmX59Of7ZXTpyMf4JHHJoYf2k1i5gpf18hoZd1f1gIrpeLf5MAAIAAgACBZKQliEdz 8KEkh3hltZ48hq1Wn5t5hfFGlpj6hVw1G5cPhQIhWpZChRQIvJXfg9EAAIAAgACA2KNLkF9zaKBO jxllLp1hjctWFZqYjI9GE5gSi4g0yJYHivEhK5Uki2IIzJRghfMAAIAAgACAbaKQmIdy95+Zls5k uJyolQJVnZnak01FppdRkfI0d5U8kVshFZQekOgI4pMOhgIAAIAAgACAFKIUoNNyw58bnrlkfpwX nG1VUZksmjhFUJaVmKY0F5SOmGEgxpNvlX8I6JIAhgYAAIAAgAB/0aG8qVxyfZ63puxkLpumpDJU +pitoaVFApYNoC0z2ZP8nnwgmZLYlgoI45E7hgIAAIAAgAB2tLPBZ39p9bA4aQhcgKzlaoxOGKm8 bAI+h6bibVwtPaTrbmsYuaWXbmwBiaKqcAIAAIAAgAB2WrLQb1Jpyq8ocB1cV6umcPlN+ahUcd0+ cKVecrwtOqNJc2oY46Onc0YB/qA3dWEAAIAAgAB2DLF8duhpYK3YdxtcAqpHd2BNoKbrd8M+KKPs eC0tEKHHeIQY7qHpeFQCXp35elgAAIAAgAB1rLAdfl1o6ax9fhZbd6jzfd1NNKWUfcM9x6KZfcYs 0KBqfdEY56BafbwCrJv6fq8AAIAAgAB1RK70heFof6tYhS5bBafPhIdMt6Rtg/M9cqFkg48skJ8y g2sY2Z73g78C7Zo7gfsAAIAAgAB05K4TjYpoKKp1jHJar6bji1hMX6N5ilg9HqBoiZosX54YiWgY 0p22iYMDI5i2gh8AAIAAgAB0lK1llT1n5qnBk8pabqYjkkNMGKKtkN481J+aj+4sMJ07kAcY2pyV jlkDVpdqgkIAAIAAgAB0XazXnQJnsaktmztaMqWGmVZL2KIGl6M8lJ7slrUr65yTlnYYu5vGkLkD iZZTgmQAAIAAgAB0Lqx+pRdntKi+oxlaLqT8oNBLuKFdnsk8e54pnfMr65u+m5MY0ZrykMgDrJWM gnwAAIAAgABqMr8DZrRdzrtAaA5Q47eWaXBDI7QFasY0KrDoa/QjH68+bKIOIbFIa+MAAJ8Ec7AA AIAAgABp7b49bjJdz7o5bthQ9bZCb5xDRbJ3cG40W68ucTEjc61KcZwOta7ocOYAAJ3AeCkAAIAA gABpzbzndWRdnbjadYBQ1bTPdbhDJrDtdhk0Ua2QdnwjkauIdq4PHKzIdiYAAJyJfCIAAIAAgABp qLtyfGtdYbdmfB5Qh7Nde+lC8q93e940LawUe/Ajk6nye/gPZ6rie9gAAJtof6EAAIAAgABperox g39dNbYjgtpQVrIVgktCtK4rgdc0FKq3gZojlKiFgZ4Pqakwga4AAJpsgAAAAIAAgABpTrk8irtd HrUciclQRLEAiNxCnq0NiBAz/KmRh5Ijnac6h8AP5qerhrgAAJmQgAAAAIAAgABpKbh/kf5dFLRH kMhQP7AYj4JClKwbjmwz8aibjeEjp6YyjkUQIqZZiukAAJjfgAAAAIAAgABpDbfzmVldF7Oel+ZQ RK9ZllVCkqtNlQgz5KfHlLYjnKVek8wQP6VZivwAAJhIgAAAAIAAgABo+rePoOtdI7MTn0lQUa61 nXxClqqbnCUz6acLm24jsaSUmCIQVqSDiwwAAJeygAAAAIAAgADNUGxtZkS5524waHWl02/YapCQ 4HFjbJR7DnLfbo1kVXRPcH1MbHWkclAxrXapc9YNx3gxc7bLXGnucVS4WGvncmekbW22c3ePn29n dIZ543EGdZdjPnKWdqVLYXP6d5swsXTceFUM5nZ0d+XJiGfJfGC2kWncfFyi4WvLfF+OJm2ZfH14 kW9WfKpiEnD/fN5KWXJvfQQvxnMrfQQMIXTufIPHu2Xih1C0wmgKhlChG2oLhWCMmmvyhId3Km3N g9Ng22+Mgy9JVHEFgo0u6XGZgesLdnObgLjGGGRGkjSzKWZ8kFSfg2iNjn6LD2qDjLt112xuixdf sm5DiaJIYG/CiEEuHnArhx8K5HJ4hFLExWMAnSGx3WU/mnCeOGdVl7WJymlTlQp0pmtHkoVepW0h kDNHgm6mjiktaW7mjMUKaHGEhwnDtmH9qBOw1GRApJedKmZVoPqIu2hUnWtzqWpSmhNdyGwzlv9G x22xlFQs0m3LkvMKAnC5hsTC7WE8swmwDWN/rsScU2WNqkyH22eFpdtyymmEobhc/2ttngVGJGzq mv0sT2zZmFwJr3AUhozCamC7vf6vhWL6uOebsmT4s5OHJWbirk5yF2jaqXNcXWrCpT5Fi2w3oj4r xmwAnKgJbXAShl++r3SOZWCtBHWCZ76abHZxae+Gvndaa/1yD3hCbftcWnksb+5FU3oPcbsrA3rf cxkHgH0Wc329RnI9b/Cr6XNmcTuZWnR1cnCFtnV2c5hxDnZzdL1bandxdd9EdnhdduQqOHkFd5AG 9XtbeBS7wHAuemuqPnFyeraX03KaevmEP3O2e0JvwXTPe5VaRHXke+xDc3bWfDIpWHdOfD8GennW fGy6KW5dhMqomm+yhDOWMXDsg5aC13Ibgv5ueHNPgoBZJ3R4gg5ChXVugZ8okXW3gS4GD3iFgDG4 rmzRjymnJ24yjcOUv298jFCBbHC4it9tRnH3iYRYGnM0iFJBqHQthzsn3nREhnkFtHdkg2y3eGuW mZql9Gz/l22Tj25NlSOAQ2+RktpsMHDZkK9XKXIWjrdA4nMTjRInPnL7jFYFZ3beg6e2gmqbpBSk /GwIoSSSkm1UngV/SW6amuZrR2/rl/lWYHEulVZAPnIfkzgmvHHekiMFJ3dKg3y1y2nfrpekPmtM queRxWyRpvh+dm3PowZqd28in2FVo3BunDc/pnFdmfMmSXDqluIE9Hehg1m1VmliuSSjuGrJtLeR I2v+r/h9xm0vqz5pz256pvJVD2/Fo2c/GHCuoQ0lx3AVmYsEynfngz2wcHz/ZKygTX0dZx2PEX1U aVd8ln2ca2do/n3xbWVURH5Wb1M+EX7VcQ8kAH+rciYB94FndAGvU3rRbqCfM3sncBON33t6cWh7 dXvVcqln83w6c+NTU3yvdRQ9OH0sdh0jQ33Jdp8Btn+ueHGuHXjVeJGd4HlNeRmMvnm2eZF6S3om egBm5HqcenZSZnsfeu08cHude0winHwCe1QBfX4rfFesuHcQgmecc3eYgiWLN3gWgc94+niWgXJl rnkngSZRWnm8gOU7j3o6gKMh5npkgFYBS33Rf7qrZnWXjECbIHYqi0CJ5Xa0iiV3sXc/iQBknHfX h+tQZnh9hvs6x3j6hishSXjohcwBIH4YgMOqT3RpljKaCXUDlHiI0XWRkpZ2pHYjkKljoXbBjtZP kndjjTc6GXffi/kgv3eYi7YA/X5VgKupcHN4oC+ZJXQXnb6H6nSjmxZ1wXU1mGVizHXaleJO23aA k7E5inbrkiggUXZzkMwA336HgJeoynLBqjmYc3NipxaHK3Poo6x0/3RyoDliDnUYnRNOK3XHmng4 /XYsmRAf73V6lPQAx36wgIaoXHJEtFiX8HLisIqGj3NbrGJ0WnPXqDhhc3R2pIFNpXUiobA4fHWD n4Yfd3SolUYAtH7RgHmif4XFZBmToIUWZomDl4ScaMJyP4RHatFfuIQLbMpL8YPybqw2gYQgcEgc ZYVhcOYAAIBMdrqhmIO4bYOSp4NFbwmCgILocG1xNYKfcb5ew4JrcwRLF4JadDs1wIJ9dTgbyINv dWYAAIAAermgi4HZdtWRZoGId4uBXYE7eCtwEoEDeMBdwIDeeVVKOIDXeeQ1BYDzek8bN4GaeiwA AIAAfjqfZoAZgCWQM3/dgCKAF3+ngANvE395f95c239kf8JJgH9mf600eH9+f5Qayn/hf1cAAIAA gACeO36wiX2PJH59iM9/B35Qh/9t5H4rhx1b1n4ehkpIkX4yhZkzsn5ChQ0aOX5ZhQwAAIAAgACd RH2Qku6OJH1lkZV+Cn06kA9s8n0Zjnda9X0OjPhH130Zi7EzHH0kit0Zx3z7imYAAIAAgACcfXyq nGeNWXyGmml9PXxXmC5sJnw0leRaNHwuk8lHNHw4kgoypXwrkSYZcXvHjtkAAIAAgACb5Xv7pfOM tnvco1V8jnunoGtrd3t5nXJZiXtxmslGj3uDmMMyH3ttl/kZIHrEkP0AAIAAgACbfXt/r5+MOXti rG57/HshqNlq3nrkpTxY/nrSoh1GGXrgoBoxr3rGnZ8YuHnykLcAAIAAgACU0Y8MY5KG8o2dZfF3 8Ix5aCBnn4uJaidWG4q7bBVDPYoqbeEudoopb0cTyIybbxQAAIAAekCUEI0tbHqGK4v3bf53Dorl b2hmy4n0cMBVWYklcgtCkYiTcz8t34h9dB4TYop9c6wAAIAAfbaTMYtfdUeFHIpNdg52GIlIdsRl 1Ihkd3BUfYefeBpB14cTeLktSYbueR8TA4h/eJoAAIAAgACSLIm4ffuEC4iyfiR08ofBfjVk6obi fjtTqYYufkdBLoWpflUsy4V2flQSuYagfgYAAIAAgACRMIhMhsyDD4dThldz/IZrhcNj9YWShR1S 9YTZhIFAnIRchAwsW4Qgg78Sd4Tog4YAAIAAgACQV4c7j76CVIZKjrJzQ4VgjXdjIoSFjCdSJIPM ivA/8oNEigAr0oL9iZ4SH4NniDoAAIAAgACPqIZimLWBmoV4lxdyhYSJlTliZ4Opk0ZRbYLykYo/ VYJlkEIrb4H7kB0R5YIejBkAAIAAgACPIIW8ob6BCYTZn5Zx6YPhnRthzIL0motQ1YI3mFo+uYGy lvQq8IE6lkYRsoERi/cAAIAAgACOvoVFqveAl4RlqFdxY4NipUVhP4JioiFQWIGXn5g+VoEKnmUq m4COmzURcYBFi8sAAIAAgACHfJidYxV6aZaYZVlsRJTjZ3hc4ZNkaXJMSZIPa006NpEgbPUl2ZE4 bgELPJOVbXQAAIAAfUaG1Zb9a4p5z5UfbQJrmZNpbmdcRZHbb79LvJB7cQY5vo+BcicleI92csgL LpEYckUAAIAAgACGIJVIc9t47pOIdKVq0pHZdWRbe5BRdh5LDI71dtQ5Lo36d3QlDo3Ud7sLHI7I d30AAIAAgACFSJOwfBZ3/pH8fExpzJBdfHNapo7afJdKS42MfMA4kYyUfOUknIxYfOYLAYy8fQwA AIAAgACEb5JdhFl3KpCxhAdo+I8Yg6FZxo2agzFJqIxBgsk4BYtRgockOIr+gmcK7Yrxge4AAIAA gACDupFHjMh2co+oi+9oP44PivRZGIyJietJBosuiP03nIoliFsj64nAiGsK2YlnhhQAAIAAgACD JpB0lUR18Y7dk/BnvI07kmJYhouokMVIa4pNj2g3FIlCjpgjnoiyjsYKxogdh0kAAIAAgACCsY/W nc51do5CnAVnOoyXme9YBIr2l8xH6omTlho2j4iMlWsjNIfplBUKtocQhz4AAIAAgACCWo9kpoR1 Fo3OpFtmy4wXocdXkYpnny9HhIj3nVI2PIflnHAi7oc5l54KlYZGhygAAIAAgAB6kKKlYnBuE6Am ZJVgq53uZqBSIJvnaIpCWJoeak4w4pj+a8McgZnBbD8D35ihbL4AAIAAf9B5/KFBanttoJ7Ma+Jg NJx/bUFRuZpdbpVCAZiAb9Iwo5dKcNQcZpfPcQcEIJYQcdIAAIAAgAB5a5+iclhs7p1CcyFfnZr0 c+ZRIZjRdKxBgpbydWgwRJWxdf4cNpYFdfsEUpPFd00AAIAAgAB4xJ4Qeh1sMpu7emFezZl4epxQ fJdYetxA7JWBex0v05Q8e08b95RnezEEdJHAfEwAAIAAgAB4G5y/ge9riJpygbleHpg1gXZPyJYT gS1AaJQ0gPgvZJLvgNwbtZL1gNgEjo/9gJ0AAIAAgAB3hpu6id9q+plziThdk5cwiHVPOpUJh60/ 4pMihwcvGZG5hrEbj5GdhxYEqI52gyYAAIAAgAB3EZrdkddqgJiekMRdFZZYj4ZOupQrjkg/bZJA jU4uxJDKjPQbhpBljKQEx40pgzsAAIAAgAB2s5pFmetqS5gGmINc3ZWulstOc5NhlQw/HpFlk9Yu Y4/7k9IbMI+MkT0E1Ywcg0UAAIAAgAB2a5nWoitqApeNoHtci5UnnlxOHJLMnEQ+0pDEmxkuJ49L mfAbB47NkkYE2ItSg0YAAIAAgABuBq05YZNiA6pdY5JVOqe3ZYNHaaU7Z1c4TaMdaPcnNqIXahsS KqR/aacAAJjTbmIAAIAAgABtg6wQaT9huqkbao9U/aZGa+FHQKOgbSo4N6FgblMnP6AxbxsScaIt booAAJctc2kAAIAAgABtF6qBcLNhOaeTcXNUmKS0cjdG3qIDcwE37Z+5c7onG55ydC4SkqATc5gA AJWgeDAAAIAAgABsoajqeAhgr6YDeFNT/aMseJxGaqB6eO83iZ4zeUEm3ZzceWwSl54yePUAAJQw fGMAAIAAgABsKKeQf2xgOKSvf1BTgaHZfytF458mfwQ3MZzQfvQmnZtwfvISkpyGfuMAAJLogAAA AIAAgABrvaaHhvJf2aOlhndTJaDHheRFhZ4LhVA22JurhOUmb5oohNUSkpsDhLgAAJHGgAAAAIAA gABrZKW3jn1fkaLSja9S35/njLJFOp0ei7s2hpq8ixsmO5kli0oSpZmoiaEAAJDbgAAAAIAAgABr JKUPlhBfVKImlPVSnJ8zk59E85xfklk2QJn0kbMl6ZhhkbwSgpitjIMAAJAngAAAAIAAgABq8KSh neNfVqGknKhSmZ6YmvdE2JuimVY2M5kXmM8l/JdqlucSqpepjJ4AC4+KgAgAAIAAgABhs7h8YIlV 9LV8YlJJobKQZBg8Ya/DZcMtu62MZyUckq1EZ7gIXK6kZ2sAAJNYctgAAIAAgABhMLeRZ9tVx7RP aQJJkrEVajg8b64La2Yt5aufbGQc8KsKbLoI8awJbGkAAJIXd24AAIAAgABg6rYLbuxVd7K/b5JJ Xa9ycEU8Q6xRcQct1qnOcacdFKkFcckJXKmlcZ0AAJDhe4AAAIAAgABgqrRkddhVJbEadhlI/a3Q dmE8BKqrdrotqqggdwsdF6cydwYJqKd6dzgAAI+/fxYAAIAAgABgaLL1fNJU6a+sfL9IvqxdfK07 uak0fJwtjqaVfKIdGaWOfJkJ6qWIfRkAAI7BgAAAAIAAgABgLrHag/FUx66Bg5dIo6skgyo7m6fx gsEtb6VIgoMdJaQQgqAKJ6PMgjkAAI3jgAAAAIAAgABf/bD8ixRUta2Nin1ImKofibw7i6bhiQgt XaQxiLYdK6LeiSAKZaJKhogAAI0zgAAAAIAAgABf2bBXkkZUsqzLkX5ImKlIkHY7haX5j4ktS6NB j2UdGKHsjrwKfKEfhxcAAIycgAAAAIAAgABfwa/dmaBUu6wsmL1Io6iRl4E7h6U0loQtUqJtli0d M6EBk04KkqAihyYAAIwAgAAAAIAAgADBE2cVX+2u02k5YrSb7Ws+ZWCIIm0kZ+5zaW74amldt3C5 bNFGx3JFbxAsz3MmcN0KBHYqcRS/IGQlatGtS2aKbIWajmi/biyG6GrSb8tyRmzPcWBcqG6xcutF yXBJdFMr6HDxdV0JbXRodWu9SWGVdaerhmQgdk6ZB2Z9dvOFc2izd6Vw+GrSeFxbgWzQeRFEym5w ea8rD27ZegoI6XLcei27d19LgF2puGH1gA+XQ2Rsf8iD7mbBf41vl2kBf2laUmsYf01Dz2y+fykq Qmzkfu0IdnGzfoa5zF1ViwSoIGAXidyVsmKmiLWCaWUMh5duUmdiho5ZNWmQhadC52s5hM0piWsZ hBoIFHJZgj+4cVvAlbOm1F6Sk7uUcGEtkbWBMWOij7ZtLWYDjdRYPGg3jB1CGmnjiqAo5Wl+ibEH wXLlhT63XFp5oGOlzF1WnZ6Tal/1mrqAMWJwl95sPWTelTFXamcaksBBcWi7kK8oYGgXj8oHfHNZ hRC2jll/qw6lBVxip3ySnF7+o75/X2F2oAhrbmPnnJlWrWYsmY9A1mfJlycn7GbilSIHRHO4hOq2 CljUtaykflu1sT+SA15ErKV+umCxqCFqz2MdpANWH2VgoH5ATWbwnh8nbmXImV8HGHQDhMyzN27s X0eimXBPYjGRDnGnZOl+aHL2Z3dqtHQ/ae1V6XWBbE0/vHakbncmAndab/wEMnsJcRKxwmwsaauh e23Pa4yQAG9QbVB9a3C9bv9pw3IgcJ9VDnN4cjI++HSgc5olV3UPdHgD4XlydcmwMWm1c/SfzWt+ dN+Oe20gdbh79m6tdoxoenAwd2BT7XGheC49/nLJeNwkh3LmeSYDmXnrekaukmeCfh+eJmlmfi2M 2mshfi56lWzHfilnOG5pfjBS2W/ufjs9HHEXfjwj0nDhfhADW3pTfiutEGWfiEecs2eYh4uLbGlp hrp5LmsgheFmE2zRhRVR125shGc8S2+Sg8cjMG8Gg1MDJnqtgYKr1mQYkn2bgGYfkPyKQWf6j1l4 Dmm/ja9lBWt6jBpQ9m0Wiq87lG46iYgioG1diR8C+nr5ggOq3GLcnLWaiWTsmnKJS2bLl/53H2iV lYVkJWpckzVQNmv+kSY6/20Sj48iL2vqjtwC1Xs3geqqI2Hspu2ZzGP+o+mIhGXZoKh2VmefnWJj YGlqmmFPgGsUl9E6bmwhlhYhyWqqk5ACt3tqgdaprWFFsR+ZRmNUrVuH6GUiqU11sWbcpUVixWii oaRO+mpKnrY562tKnPohT2mKloUCn3uTgcWlpHcVXsOWenevYbqGNHhcZHR0p3kUZvth8HnTaWdO Bnqba7c4i3tmbb8ey3w7btMAAIAAcmCkeHR5aI2VWnVUao6FAXYlbGlzi3b2bidg7nfLb9VNInij cWw3w3lmcsceKHnYc1EAAIAAdwWjNnIXclCUAnMfc26D5HQOdHRyaHT4dWZf7HXgdlNMRnbHdzY3 EXeFd+0dnXeSeAcAAIAAexihxG/1e/eSjXEXfE+CWHIffIxxGXMefLleuHQlfOlLPHUefRg2NXXV fTYc83V3fQMAAIAAfqKgbG4mhZyROG9ahTuBCHB1hLdv1HGDhB9dtHKUg5BKVXOfgxc1fHRNgq0c anOFgm8AAIAAgACfUGyvj1aQIG3vjj5/+G8TjPduzXAsi51cvXFFilVJjXJMiTY023LyiGMb73HL iEsAAIAAgACebWuAmROPPGzIl0d/FG3ulT9t8G8Lkydb7nAukTRI3HE3j4g0WXHFjnEbkHBdjVgA AIAAgACdxGqWotOOimvjoFd+WG0FnZFtNW4dmrxbNm9CmCtIMHBSlhkz0XDUlR8bOm81kXoAAIAA gACdVGnxrJeOCGs9qXJ9wWxUpfJsl21fomtapW59n01HtW+KnQMzVm//m3gaxG5HkhkAAIAAgACY UH+XXlqKSX9wYUZ7GH94Y/hqln+eZnZY2H/XaNVFxoAuaw0w5YC+bN4WtYI9bTQAAIAAdlyXU30b Z5iJRn05aaR6AX1ka4dpkX2cbU1X7X3jbv5E+35BcI8wOX69cckWNn+zcbsAAIAAemeWOXrXcL6I AXsgcgF45XticydoeHuwdDdW+nwIdTpEL3xwdikvl3zbdtgVxX1IdoUAAIAAffOVBXjEeeeGvHkq enJ3l3mFettneXnhezlWEHpOe45DcXrAe9wvCXsbfAoVZnsde6YAAIAAgACT03cHgw6Frnd/gvN2 hHfqgrBmTXhSglJVH3jHgftClnlIgbQuV3mSgXYU6XlNgVMAAIAAgACS1HWkjEuEqXYmi4d1hHaX ipFlWHcGiYNUOnd+iINB4Hf2h64txngwhy0UgXfGhqYAAIAAgACSB3SClYmD23UMlCN0t3V9knxk kXXukMFTfXZsjylBQXbijeEtWnb8jVMUOXZ+ixYAAIAAgACRanOgnsyDN3QwnMp0C3Semnhj53UI mBNS13WGlfNAoXYAlGYs2nYHk/4T9XV3jX4AAIAAgACQ/XL9qByCunOPpYpzfXP0opNjVXRRn49S U3TGnP1AM3U5m2osbHUzmYwTi3S0jTcAAIAAgACLLIh+XfB+EYetYMdv04cdY2pgR4a4ZdtPdIZx aCc9K4ZmajsovIbta7kOBoj+a0cAAIAAedOKUYY0Zq19OoWkaLVu7IUtappfc4TObGJOuoSKbg88 j4R8b48oQITfcI8N14ZJb/UAAIAAfViJXoQHb1N8HYOkcKNt7YNCcdted4LzcvpN34K7dAs72IKx dPons4L3dYcNnoPndO8AAIAAgACIT4IUd+h6+oHFeJdsuIF4eSpdhIEyeahNAIENeh47I4EHeoEn LIEyeqsNZoHRel0AAIAAgACHSoBWgIt5/YAbgKNrwn/fgJZci3+mgG5MZ397gEk6qH99gC0m3H+O gBANUn/+f+gAAIAAgACGaH8HiU95Nn7YiNNrAn6biCNbwn5eh1ZLjX43hpc5/X4shgkmUX4khdkN DX56hKMAAIAAgACFsX3zkhF4eX3MkQZqR32Nj7dbDX1OjlBK3H0pjQ85Zn0WjCwl9XzjjDoM6n0y iJYAAIAAgACFIn0dmtV353z7mURpsHy3l19aeXxvlWJKSXxGk7I403w0krElgnvmkkoMy3wniKYA AIAAgACEuHx/o7F3dHxgoaxpL3wTnzhZ9nu8nLFJ1nuHmqw4dntrmeAlJnsMlyMMintfiHoAAIAA gAB+Q5H5XWZx2pCRYBpkaY9xYqZVuo6DZQdFvo3DZzk0H41yaRsf0o5WahcGTo6ZahQAAIAAfMt9 e4/oZahxKo6wZ6Bjso2ZaX9VGYyka0NFNovcbOUztYt9bkUfjownbuAGaov2bvAAAIAAf958ro3X bdFwOozFbyNi5Iu8cGJUTorQcY5Ei4oNcqMzLompc4YfNoojc8wGd4mfdCsAAIAAgAB7yYvtdelv RIrudqph3on5d1RThYkTd/FD14hdeHsyo4f2eOce3YhGeO0GfIeSeb8AAIAAgAB66YpKfgVueIlY fkRhGYhrfmRSsIeOfmpDUYbLfm0yNoZnfncenYaMfmMGjIXGfq8AAIAAgAB6Ioj6hkRtuYgWhftg XocqhYdSC4ZChPhCuoV8hHEx8oT3hCAeboT5hDsGkYQ8gtsAAIAAgAB5g4f0joxtOocajc5f44Yn jMpRd4Uwi6dCGYRpirIxYIPeijIeKYOjiokGi4LzhGwAAIAAgAB5BIcqlt1suYZUlbFfXYVZlCdQ 9YRVknxBmoODkTEw1IL4kMgduIKbj9YGiYHlhGsAAIAAgAB4ooaSn01sUoW+ncte6oS4m8ZQgoOl maJBNoLCmCUwhoIml7YdgYGvk/MGfYEUhGMAAIAAgABxr5vYXLJl8Zn3X0JZO5hgYbRLTpb8Y/s8 CpXaZgcq4pV9Z54WLpeFZ8cAAJMNab8AAIAAf0pw95oOZIxlZ5hHZm9YtJaiaEBK4ZUjafg7tpPq a4Mqr5NubKsWMJUXbJQAL5C+brYAAIAAgABwT5gTbEJkopZqbY5YDpTLbsxKP5NNb/s7NJIRcQkq VpGCccoWFZLccYUAc45wdDMAAIAAgABvk5Yxc+Nj0ZSWdK1XK5MHdWVJjZGPdhI6mZBbdqgp5Y/B dwkV3pDZdq0AooxreUQAAIAAgABu15Sbe5BjF5MMe+JWcZGCfB1I0JAJfEM6Eo7PfGcpdY4xfHwV nI8OfDoAw4qqfaYAAIAAgABuMpNbg1pifJHWgz5V3JBIgvtIO47KgqE5hI2GglYpMIy+gjcVdo1k gmgA4IkngJcAAIAAgABtrJJPiydh9ZDViqFVVI9FieRHs42/iRU5Box2iHYoz4udiFEVdYvjiAQB A4ffgK8AAIAAgABtQpGLkwphsZAXkjVVEo55kQFHaYzTj7E4vIt0jtMocIqejwQVGYrHjKABGobR gL4AAIAAgABs75D4mw5hX499mfhUuY3UmF9HEIwglrE4coqxldEoOYnFlScU/InJjjABJ4YDgMgA AIAAgABlYqZXW7BaEqQfXhVN8KIjYGVAq6BbYo0x8p8FZGgg558TZYoL+6G7ZRoAAI2UbdIAAIAA gABks6TMYydZpqKOZPFNk6BtZrBAbJ57aFYx0pz/ab8g85zVaooMT576af0AAIv7cswAAIAAgABk K6LoanVZDKC4a7hNGZ6UbPE/+Jyabh4xf5sRbxog0JrBb5UMfZxsbwYAAIp7d6IAAIAAgABjnaEH catYa57icnpMaJzJczw/dZrRc/UxEZlIdI0gkJjedMMMjpoZdFUAAIkUe+UAAIAAgABjDp9uePBX 4Z1TeVhL3ps7ea0+45k/eewwtJepeicgTZctejEMjpgBeioAAIfRf5wAAIAAgABikJ4sgFZXcZwW gGFLdZn4gEg+fJfzgBowVZZOf/ogJZWif/gMlZYegBEAAIa0gAAAAIAAgABiJp0th79XGZsYh3lL JJjwhvg+KJbchmYv+pUyhg4f5pRthkQMrJR0hQ0AAIXOgAAAAIAAgABh1ZxejytWzJpKjptK05gc jb492JX9jNsvrpREjHYfi5N+jK8MiZMliHoAAIUhgAAAAIAAgABhlZvLls1Wv5muliRKxZdslO89 vZUok6wvq5NKk2cfsZJbke8Mv5HsiJ8AAIScgAAAAIAAgABZI7GtWmROGq9SXI1CZK0ZXqo1nKsY YJ4nLKnjYiMVk6thYmgDRam2Y1oAAIjncf0AAIAAgABYcLBnYX1Nuq3iYxtCI6tqZLk1f6kuZjon Oqe9Z2AV6qjPZ3AD0qa/aFEAAIegdrIAAIAAgABYCK6SaGhNSqwLaZBB0KmJarQ1OKc4a84nGKWs bJoWCqZzbHwEOaPzbXgAAIZnet0AAIAAgABXrqynbzpM36omb/1BV6eocLk056VVcW0m36O8cewW CqROcasEhKFccvwAAIVBfooAAIAAgABXUqr9dhxMiqiCdopBBKX/duo0iqOmdzMmuqH1d20WCaJd dykEwp8GeOEAAIQ+gAAAAIAAgABW/6mtfSNMUKcqfUpA1aSdfU40XqI3fT8mkqB0fTMWG6CXfRYE /5zvfhYAAINegAAAAIAAgABWuqighC1MKaYShBZAuaN1g8c0QaECg2wmdJ80g0cWHZ8tg4cFPpsh gnoAAIKtgAAAAIAAgABWhafSi0NME6Uyiv1AqqKDimc0Mp/+ic8mXZ4hicoV/54RiTYFTZmrg5YA AIIWgAAAAIAAgABWYqc0kn5MDKR6kiJAp6G6kVU0Lp8jkKQmZ50vkJkWJpz2jeQFaphwg6kAAIGA gAAAAIAAgAC1JmFTWbKj/mPRXQOSNmYvYDd/hmhxY0xr3mqfZkZXKGyuaSVBKm5ia88n627abd0G uXSjbsWzKl3OZGGicWCaZqyQ1GM2aOZ+S2WuaxBqumgNbShWHmpAby5ANWv8cQYnGGwScl4GY3U1 c0GxTlqxbwGgql2zcEqPTWCDcYx81mMmcs5pbmWsdA1U+2f+dUM/Pmm7dlYmUWlldwoGF3W1eCKv dFfleYGe3VsWedyNjF4Jejl7WWDSepdoFGN/ewFT1GXqe2s+Tmeoe8Qll2bde+sF1XYkfJqtvlV4 g/KdRljOg3WMBFvjgvZ53l7Fgnlm4mGMgghSyGQRga89dmXKgVgk8mSEgREFnXaDgG2sUlN2jmab 91bpjRiKzFoUi8B4uF0Nimplzl/kiShR52JwiAo8vmQlhxkkYmJ1hp0FbnbTg6arLVHPmNWa6lVY lraJ0FiRlIN3yluYkllk716AkFRRJGEUjoU8KWK4jQwj8GDIjKIFRncWg5GqUFCEozaaHlQboEOJ CldanTd3DFpkmjtkN11Ul4BQeF/xlR47nGGKk1Yjjl9skewFJndMg3upwU+YrXWZklM0qaCIeFZs pbl2eVlwofhjsFxenplQBF76m8U7KGB/mgUjIl5Flh4FDXd3g2qoF2jbWUmYY2qpXK+Hz2xrX+Z2 JW4fYvBjZW/KZdxPf3FfaKc6InKvayog6HLxbMwBTH3PbvOmgWWIY3eXNGelZeSGvWmaaDF1LWt2 amNigG1CbH1Os27xbn85dHA+cEUgW3ACcUwBLn4Bc8ek3mKIbY6Vf2TZbw6FN2b7cHhzuGj/cdRh OGrvcyZNlmy4dGk4gW39dXwfnW0udfkBFH4teGWjNF/Xd4iT1WJQeDCDlmSUeMdyX2a4eVFf/mjN edxMjGqqemM3q2vmes8e+mqdeuEA/X5UfGahqF1/gX2SYGAZgV2CLWJ8gSZw/mS4gOJe6GbhgKRL l2jUgHc26GoDgEsea2h0gB0A6n51f9SgY1uQi3uRK15CipaBCWC4iZJv6WMJiINd5mVAh4JKyWc1 hqM2Q2hYhfgd7marhdoA2X6RgJOfX1n5lXSQMly8k8yAGl8+kftvBmGbkCRdEWPijm9KE2XcjPM1 v2bli+Edj2Uzi4wAzH6ogIqenVi7n2GPc1uInPd/WV4NmltuSmBsl79cWmK4lWFJaGS5k2k1N2Wy kjcdOmQEkDYAwX66gIKeHVfYqTaO6lqlpgx+w10joqdtsl97n05b0GHEnFhI9WPCmgc0w2SimOUc y2MNk3gAuH7JgHybNnCyWPeM1XHMXGB9Z3LxX5BsvHQbYoxa4XVEZWRHwXZnaBMy8ndoamAZXnfN a1oAAIAAch2Z4W2HYo2Lo27uZQ98MXBBZ2lro3GMaaFZ5XLRa75G5nQHbboyOHT1b2AY0nTJb9wA AIAAdsiYhWqhbCCKP2xAbcd7EW29b1VqhW8mcMZY7nCDcihGGHHJc3QxmXKldHwYY3ImdJMAAIAA euKXBGgFdZmIwWnLdn55g2tnd0ZpOmzsd/lXvm5seKNFFm/CeUEwx3CJebcXym/seYwAAIAAfnGV oGXGfw6HZ2emfzx4M2lef0Zn+Gr5fzlWxmyIfyxEOW3tfygwGm6efx4XUm4GfvAAAIAAgACUe2Pq iJKGTGXfiAp3Jmemh1Zm92lThoxV1mrthcxDf2xOhSsviGznhL8W6WxyhMAAAIAAgACTj2JikhKF ZWRmkNh2RmY2j2ZmIWftjeJVDWmSjH1C1mr0i1YvFWtqiqwWnWsjiccAAIAAgACS3mEum4mEsmM7 maF1jmUOl3VlbmbDlTpUXmhtkz1CL2nSkbIuk2oukSUWVmoVjeUAAIAAgACSZmBNpPOELmJdomd0 +2Qpn4Rk2WXWnJxT2Gd6mhdBwWjZmFMuImkYl2AV5WlMjs4AAIAAgACOfHjnWLGBJ3lSXAlyt3nh Xyhi/nqEYhNSAXsxZNQ/nXvvZ14rPHzFaVsQ3n5QaWAAAIAAdgmNUnXhYbqAEHaZZEBxnHdSZpth /XgPaNNRH3jPaus+3XmVbNMqn3pHbkAQiHuFbfYAAIAAeh+MHXMbarV+vXQJbHlwe3Tjbh1g5XW7 b6JQMnaPcRI+Gnddcl0qC3ftc0UQPXkQcssAAIAAfbWK1XCTc7J9a3GodMBvKXKhda1f6HONdodP T3R6d0s9Z3VPd/spjnW9eGkQA3bsd/AAAIAAgACJk25rfK58UG+ZfRZuC3CpfVdeuHGlfXpOXXKe fZo8inN9fboo3XPGfcMPoXUlfZ4AAIAAgACIiWykhbZ7R23jhXptDm7/hQxdx3AJhIJNf3EHg/87 43Hbg5koW3H/g2UPWnOhgvoAAIAAgACHsmssjrp6dWx5jd5sQW2cjMNdAm6ri5FMxm+wins7SHB+ iaYn+nBwiWkPLnJZh3AAAIAAgACHDGoCl7l5zWtYlkRrlWx8lIFcXW2JkqlMI26OkQ86qm9bj/Yn gG8nj+wPAHFQiiUAAIAAgACGl2kkoLN5T2p/nrRrCmuenFFb0Gyhmd5Lp22dl9I6RW5flq4nFW4J lWUOp3CRiegAAIAAgACB14GLWF11WIFYW5dnxoFaXqFY7IF9YXdIwYG4ZBs3A4InZnEi0YMdZ/gI 54SkZ98AAIAAeXOAy362YOJ0aH7KY19m1H7tZbVYF38eZ+dIC39gafI2cH/Ka7kiZ4CEbMkI34Hp bJoAAIAAfQZ/unwNaV1zOXxWayllzXyXbNhXGXzcbmZHMn0tb9g1vn2WcRMh5n4YcbYIxX+GcZsA AIAAgAB+mHmmccpyDnoNcvdklnpodAVWLnq7dPdGW3sgddM1F3uHdoghdHvUdtAIsn1wdwsAAIAA gAB9gHeJektw+XgLetxjjHh5e0lVLHjae5lFtHk/e+E0i3mpfBshGXnAfCAIqnuhfJYAAIAAgAB8 j3XXgt5wLHZrgt9izXbhgq1UX3dGglxE5XesghAz8ngCgd8gn3fjgdUIg3ofgVwAAIAAgAB7y3Rx i2pvZnUQit5iDHWJihBTpXXxiShENHZYiF0zXHagh9kgSnY7iA8IcnjYhVUAAIAAgAB7MXNSk/Bu znP7kuBhc3RzkX9TE3TVkARDo3U5jswyy3V6jisf3HTgjg0IY3fOhasAAIAAgAB6vnJ4nHxuV3Mn mv1g83ObmRBSk3Pylw5DNXRJlYEydHR6lRIfgXO2ktYILHcKhYYAAIAAgAB1Toq3V9ppgIn7WvBc sol8Xd5OpIknYJs/NIj+Yxst84lKZSkZf4r5ZfMB9YoUZxgAAIAAfF90WIgbX+dos4eZYlNb6Icu ZJ5N+IbZZsU+qYaraLktjobiaksZT4gwarsCLIdsa/oAAIAAf4NzaoWRZ+dnrIU+abNbC4Tpa2ZN I4ShbPk9+IR4bmQtB4Shb30ZAIWZb6ACToUTcTYAAIAAgABycIM/b99moYMIcRlZ9oLHcjhMSoKM cz49NIJwdCMsbYKOdMoYnIM2dLICXYMKds0AAIAAgABxfYFCd+BluYEdeJFZDoDqeSJLXYC3eZg8 mYCTefwr6ICpekIYSID/ehMCboFEe8AAAIAAgABwpn+Qf/Jk739/gCNYUn9VgCdKtX8hgAw8B374 f/Ars37pf+UYM37zf+gCjX+9f/gAAIAAgABv9n45iAtkYX46h8ZXz34Nhz1KK33KhpQ7cn2bhgsr KX19hdQX930qhh0Cln52gcAAAIAAgABvaX0mkCRj130vj3JXRX0AjmdJqny1jTw69Xx8jGAqpHxR jDwXkHu0i1sCn31qgcYAAIAAgABu/XxTmEtjanxgl0JW03wslb9JO3vWlCI6l3uNkxIqW3tJkv8X UXp1j48CkHyggbwAAIAAgABpA5R/Vwpd0JNIWfdRrpJVXMVEUZGVX2I1eZElYbAkcpGiY1UPT5SM YycAAIgJaZoAAIAAftRoHZIjXqhdH5EUYP1RCZAhYzhDzI9RZU41F47MZx8kPo8caFsPaZFtZ/oA AIYibmQAAIAAgABnUY+2ZjdcQI7MZ/1QUI3naa1DHI0baz00jYyRbJUj4ozCbW4PXo6CbOkAAIRe c6cAAIAAgABmfo1xbbxbXoyebv9PYovJcCpCZYsFcTwz7IqAciAjb4qYcp0PN4vPcg4AAIK8eJoA AIAAgABlr4t9dUxaloq8dhVOm4nxdsJBnokud1AzZoifd8gjA4iid/0PDIlTd5QAAIFOfOUAAIAA gABk94nifPBZ7okwfUtOAIhnfXtBCYeffY0y3ocEfZki2YbMfaMPC//bAEMAAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAgIBAQIBAQECAgICAgICAgIBAgICAgICAgICAv/bAEMB AQEBAQEBAQEBAQIBAQECAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC AgICAgICAv/AABEIAGEA0gMBIgACEQEDEQH/xAAfAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJ Cgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQz YnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOE hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm 5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIE BAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZ GiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SV lpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4 +fr/2gAMAwEAAhEDEQA/AP76KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiivNvip8UvDvwi8LnxT4jW5uIH1Cz02z06w8k6hf3N1JmRLVJ5FVvKtEuJnJIG2DbkMy1yY/HY PLMHicwzDERwuCwcHUq1Ju0YQirtvr6JJtuySbaRnVq06FOdWrNU6dNXk3skj52/bH+I3j3wXoPh ux8Gx69o1peaguo6v400yOWOCzksZB/Z2hi+iyIJZp8yyrIFSSOFIhvDyLWF8Bv2v7TxPNZeEfik 9npOvTNHa6b4rjVLXSNXmbCRwarFkJpN+z4AkXFtIWwRCxAb6x8J+M/Afxd8LzX2gX2neJdBv4jZ 6pp13CjyQNKn7zT9a0m5Utby4P3ZF2tjdGzDDV+d/wC0j+yu/guK+8d/Dq2nuvCSl7jW/Do33F14 bRjl7yxJy13oQJ+dTmS1HJLw5aP8P4zfG2S5m/Efg/Ov9YuHa9Kk6+BTVSisNTjrOkoOUalP4qkq 1Plr0pSbftKXOo/M5j/aeGr/ANsZfifrmElGPNS3ioJbxtdNbtyVpRbe8b2/U7/PY9Rnt7UV+c37 J37R88s2n/Crx7qDT+bstfBfiC8lLyhxxF4c1K4kOZARxZysc5AtmJzFj9Ga/UuEOLsq40yajnGV zcU3yVqMmvaUKyScqc7b7pwktJwakrXaXuZfmFDMsNHEUHbpKL3hLrF/mn1WoUUUV9SdwUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUV88WH7Rng7xJ+0dqv7NfgyWHxJ4u8CeBx4 ++L9/Z3Cyad8OLLV7qDT/BHhjU5IdwbxjrE8t5dx2ZIa203Rprm4Cm5tA/0PXTisHisE6EcVRlQl iKcK0FJWk6dRXpz5d0qkbThdLmhKM43hKLfLhMdhMcq8sJXjiIYarOjOUXeKq02lUgpbSdOV4T5W +SpGdOVpwlFMkkSJHlldI4o1Z5JJGCRxogLO7uxARAoJJJAAGTxXhXxz+Bej/G7RbCGfWL7R9Z0V Lubw/fwStcaUJbxYvMGo6Zu23UMghhHmoVmRclGKkozP2lNP+IGsfCjXtG+HemPqmpap5drq8Vvc JFqI8O4eXU49Mgcj7bdzLFHC0SsHMM0gQMxVT+fvwI/aZ8T/AAr1K28L+MpdR1nwOlwbK4sr0Sy6 x4UdZDHLNpv2j94beJw3nWT8YU+SI3G1vxvjzjXhvAZtQ4M4vyerPh/PKEefGTU1h1U9p7sLpRk1 S5YVJ1qVRyoycG47yj5WaZlg6WIhl2YYeTwmKir1HdQUubRX02sm5Rd4u2nVecq/xT/Zl+IuP3uj a1abWaMM8/h/xVoxlI6gKuo6ZJtIBws0EnaKVcV+t3wl+Kfhz4x+DofEGlKkU2P7P8Q6FcMk0+k6 gYf9IsrlWGJ7OSMs0MhG2aJuQGDquR8V/hp4V+PPw/S3hubOe4nshrHgvxPb7JRaXM8Aktpo5lG6 TTLhCiXEfdG3YEkaFfy++DPj/XPgH8WHg12O4srBdRk8L+OtJkJ2pbR3TQPehOjz2dx+/hcffjLq p2ynP57g6mO8GOKMFgamMlmPhzxPP91Um1NYac7e+5L3VKClGVRxSjiKDdRRdSm4x8mnKrw5jqdK VR1soxr91t35G7a9tLq9tJx13WnU/tR/BL/hVPiyDxH4agltvBnie6kuNMWAso8Pa3GftNxpMcqc wwcGezOchFeMHMGT98/sz/F4/Ff4fwtqk6yeLfDBh0jxHkgSXp8snT9b2dluoI38w9PtFvMBgYFe hfFPwJp3xU+HmveFZWgl/tWwF1ot8NrpbatAn2rR9Qhf/nn5/lhiPvQzuvRq/K/9mLxrefDX4z6b pmqs1lY+ILqTwX4htpTtW3u5rnybCSUHGJINajhXPZJpR/Ea6sTQj4VeKGAxOC/ccIcdP2dSmtKV Gs5pXil7sY0atSFSD2jQrVacVaNy5wWRZ3SnT93L8091r7MZXW3RKMmmu0ZSS2P2ZooIwSD1HBor +k7rufZHkfi39oH4CeANdufC3jz44/B/wP4ns4LW5u/DnjD4leDvDWvWttfRCeyubjSNZ1mG4hgm gIeJ2jCyKdyEjmqvh/8AaP8A2dvFur2egeFPj98E/FGvajKsFhonh74qeBtZ1e+mc4SGz03T9dkm upSeAsaMSe1fzy/8F8vAng3xV+0x/wAE2tN8QeGtI1G28b/EXVvCHi1ntI4L3X/DN348+E9hNouo 6nahLmWxFpqmpJGvmgw/bpWhMbOxPvn7cP8AwQ1/Y6vvgV8RvG/7NngC7+CXxh+HfhPXfG/hC68M +KPFF9oeu3/hPT7jXP7A1bSde1W88hruGxlht7u0e3uLW5lhm3yRo8T/AK9g+CuC45NwVj884hx+ V4njONdU3TwlDEYbDToYl4VyrSeIo1nTlUSn7lOUowbTd1d/jGN4645eecd5fkXDeX5thuBpYd1I 1MXXw+KxUMRhI4xRoR+r1qKqxpt0/wB5UjGU0mlZ8q/oE6daK/K3/gjj+0t4q/aT/YH+HnjX4la1 Pq/jD4f6l4m+GPivxTq9yGutYh8EvbTaPrmtX07fvb4+FNR0YXlzK26Wa1lnlYs7Mf0gtviN8Pb2 Dwxc2njzwZc2/jYuvgueDxRokkXi8pnd/wAIs632PEI4PNp5wIGQSOa/PM8yHH5FnWbZJiYOticn xFXD1JQUnCUqTl70Xa/LOEXUjez5NWlZ2/SeH+Isv4hyLJs/wtT2OFzrDUcTThUlFTjGrGD5JK9u aE5qnK11z2Sbur9lRXD+P/ib8N/hRoMnin4oePvBvw68NxyiBte8b+JNI8L6U1wyl1to77WbuGOa 5KAkRoWcgZC07wD8Svh18VdAi8VfDDx54P8AiJ4Zmla3j1/wT4j0nxPpBuEVXktmv9Hu5o4rlVZS 0bMrgMMqK8z6pivq31z6tU+qc3J7Xkl7Pn35ee3LzW+ze/ker9cwn1r6l9ap/XeXn9jzx9rybc/s 78/Lf7VreZ21cR8Sdf8AF/hXwJ4p8ReAvA3/AAsrxho+kXN/oHgT/hJNP8If8JPfwAOuljxLqtvL b6QzxiQiWWNkygUgFgR2/TkkAAEkk4AABJJJ6AAHJPFeLeH/ANoT4C+PvEfiD4e+BfjV8KfGXjzR 7DUW1Twb4X8f+F9d8TWS29tMbozaNpupyT4h2t52EPkkYk21eEoVqk3iIYKWNoYRxnVjy1HTUFJX VWVJxlCEvhclODs3yyjKzUYzEUKcFh6mOjgcRjVKnRlzUlUdRxdnRjVUo1KkLqSi4VI3S5oSjdP4 o/4JY/twfEj9vT4WfGD4qfETwd4W8A/8Iv8AGe/8AeF/Cfhia/vv7J0TTPCfhjU5Y9a1jUZN2s6w dT1W98ydIbaHaqrHboFyf1Ar+fP/AIN9da0Xw7+x58fda8QatpWg6PY/tT+NmvtX1m/s9K0y0SXw z4EtoWu9Qvpo4rdWuJ4o1LuNzzKgyzAH95dJ8beDNf1BtJ0Lxf4W1vVUs21F9M0fxDpGp6gunpNF bvftZWV48q2QnmhQylfLDzKpbcwB+z8SsowuVcb8TYDKcB9UyvL66p04QU3TpxjRpO3NJybfvc0n KTk3K8m27nw3hbnWLzjgLhXMM5zH67m+Y4d1atSo4KpUlKtVXNyxUUlpyxUIqKUeWKSVl09Fcl/w n/gL+1W0L/hOPB/9uJqaaI+i/wDCT6J/a6a1KFaPR3037d5y6qyupW3KecdwwnIrhfjN8YPhP8Kt Fgb4m/HXwR8DP7WbZpet+K/E/gvQb25KNtk/sq18ab4b4hiAzC3mVO+K+LoYLF4ivRw1PD1JVsRb kiqc5Skt7xjCMpyVtfdjJ22R91Xx+Dw+HrYqriqcKGH+OTqU4xi9rSnOUYRbenvSjqez0V8XaR8L tI+Nemt4o8C/t0fHjxXoF24MWqfCj4i/BOXQY2YeYIorzwx8L51jbawOxpd2F5GM15t4p/Ye+Okh kn+G/wDwUl/bC8HXZy0SeK4Pgx8TNJjcgDMlhqnw3spZY8gfKLpepwRnNexSybLHUdDGcRUstrwd pKrhcdaL6qXJh51E11Xs7+R4lXO819nGvguGa2Z4eavGVHFYC810cPaYmFNp9H7RI/RsAnoCfoM/ yoKsOoI+oI/nX8ff/BTOw/4KGfA/4g/An4T/ALRv/BRvXLP9nv4rXniQQfHLwt8PdU+Glp4ZvvDt vFLdaf8AEPQ/hFEuoeIrw29zpzW0EN3NE4vJZvJRYJXH49/AD/gpR+2l+zH4ytvEHw//AGgfHXir R7O/JvvB3xG8Qa7468BeKrCKR0aG/wBA8TX0smnpPBkrNZyWd7D5gKTIwIr9kyH6PeZ8S5FHOMl4 twGYTr03VoxhRxkcPVj7SrSUfrVahScavPRnGdJ0Oek+V1FGM4Sl+H8RfSVyjhXiGWSZ9wdmGWQo VFSrSqVsDLE0peypVXJ4ShiKylR5K9OVOsq/s6y51TcpU5xX+kP16V/P7/wWJ/4K3RfssaPd/s7f s4eItMvP2jtftmj8YeKrM2mqw/BLQLmP5cROskD/ABHvI3H2S3lD/wBm25N7cRebJZq/xV+0B/wc QQfET9j/AFHQfhB4O8SfCT9q3xdPF4S1y6WRNU8MeCPD1zZSPr3j3wF4nO2S61WYAWmnW91bxXWn TXzXbNN9lhkm/lpubnUNWv7i9vbm+1XVdTvJbq7vLue41DUtS1C8mMk9xc3EzPLe301xIzM7FpJH cklmNfY+Ev0f8b/adTO/EDA/VsNlVZwo5fU5ZrE1Kdn7atKMpQlhYyfuQTksQ03NqkuWr8N40fSQ wEcpp5B4b5h9axec0IzrZjT5oPC0ql17GjGUY1I4uUfjnJReHjJcidZ81H+uT/g2r1LxB4osv22f GnifUL3xBrfiHxl8JbrWfE+tXFxqWva1rV3ZfEPUNRudR1e7kaW+mkluBLKZGZjJKGJyRX9RNfgF /wAEs/Bvw+/4Jd/sHT/E/wDbC8a6H8E/EPxw8VS/EfU9D8Z3H2PxFp2kQaVa6T4N8K2vhuCJ9Q1b xM2kQS389jbW81zbvrpgmjjeGQD5v/aO/wCDk/wdpF/daD+yr8D9Q8bxqlxbRePvi1fT+F9MmvXj MVncaR4H0QT3uoWguWRwLu8sJZVHl+RGW3D4bjXg/iTxM8SuKsfwZk88xyiNenQjilyUsGvquHo4 afLiKjhRklOlKypyk3GzjFxaZ+hcCcacM+FPhZwfl/HedwyzOpYeeIlhJc1XGv63ia2Khz4amp1o txrR5pVYxSldSkpJpf0R/G/9on4Mfs4+HdP8T/GXx7pPg2y1vU4dD8MadMt3qfijxj4huZI4bTw9 4L8JaNb3GpeLNcmnmhRLaxtZ5N0ybgoYGvmL9rD4N2PibwnD8bfC+i3ui6zFYWOo+L9GvLI2GpXW k3cMLJqGqacGJs/EFl5saXiElvLVxId8GT+en/BLP9kX9oH4w/Em4/4KPf8ABQafWfE/xe161I/Z 48E+NLc2q/Dbw7qIlkn8Z2Xgl40tvBLzW0yQaHZJDHNbWzz6jOv2q6t5k/oE1PTbTWdN1DSb+JZr LVLK7067icBlktr2CS2nRgeoMcrV+EeLvh9w1i8txnBSx8c8zKjTl7fG03F4Whjkr044J8vtJrDS vCtXlOPt250lSp01J1P0/hzMM042yWvm2aZQ8jyzMvey7DV4v67Gkr8mKxb5uSlOvpOnhoRvSpW9 pWqOry0/gD9h74oXF1DrHwr1a5aUafBLr/hUyuWaO0aZE1nSoyzf6pJ5obiNR086fAAArhv24/AM OkeLdA8f2MCxQeK7WXS9Y2KArazo6R/Z7l8ceZNpckanPX+zyeTmvFfgXc3Hgr9obwjZq7IbTxjd +Frr1kgu5LzQpkf1BaRT7lRX31+2ppUV98FZr5lBl0XxPoN7C5AyouZJ9MlUE9AyXwz/ALor+R8o nU4s8D+IctzH95jeDKk3RlLWUIYaMK8Fd/y0Z18Mu1NJLYqg5Y/hnF0a3vVcuk+V7tKFpL/yVyh6 JHV/sq+M5fGfwY8NvdzGbUPDb3PhW9kZtzuNIMf9nO5PO46VPYjJ6lDX52ftUeG28F/HLxHc6ePs 6ay2neMNPMYKeXdX6eZdSRkHgjWLS7bjoWFfTf7A+oyPofxH0gljFbavoWpRqfuq97ZXtrMR7kWE H/fNcJ+3pYJF4y8BakFAe88M6jZyNjlhp+qCVMnvgagw/Cuvi+pLiLwI4bzuu3LGZTLDfvPt3pVZ 5fJt73n7s5d5JN6mmYSeL4WweJlrUocmvX3W6T+/RvzP0H8JePtD13wp4Z1u4u4kn1nw9ouqzL/d l1DTba7kXr2eZh+FFfll4Y+Imp2Phrw9ZR3EipZ6HpNqi56Jb2FvCo6eiCivrcH4z4b6phfbYVTr ezp875t5cseZ79Xd/f2O+nxEvZ0+aneVlffeyv8AmfF3/BdMgftS/wDBLIsQqj4z3pZmIVVA+I/w ZJZmY4VQASSeABzX60f8FBv2vvhF+y1+zB8W/GPi3xn4cTxJrHgjxT4a+HfhKLV9PuNf8X+Mtf0e 90nRbHTNJiuDNPZRXl3HPfT7PJtbW2lkldflDfkj/wAF3La2vf2nf+CXVleQQ3VnefGDU7S7tbiN Zbe6tbn4h/BuC4tp4m4khkhkdHU8MrkHg1+mfhT/AIJA/wDBOvwX8Sl+Kekfs36Bd+JLTU11bS7D xF4h8X+KPB+jahFci6in0zwVr+vXGmQRpcDfHC1s8ETYMcS7Vx/eeLnwvQ4K8IMZxNVxjo4KjmdS nh8JRoz+suGa1JSpVa9XEUnhoyainOFHEPlcrRjJRv8AkWDhxbiOPPGnBcKUsDGtjq+U0qmJxlev D6rz5NSjGtSw9HDVVipRvJ+znXwyUlC8pRckvxk0f9mHV/hV/wAG7vj+4+Idr4m8OeMNcu3/AGgd K0y11nXfDN5p1v4u8Z+EvDnh238Qafp93AurWF74GjguJdPv45oANaRmhWeKN09Y/wCCb/8AwTBX 42/Cn9kP9tn46fGHx/H8TvASfDDxD8DfB+lNpX/CvvA3we+FepwQeFfCl7o19ZPLNc6zp2k3F/eX VtdW3lS68JvLllWXzP08/wCCxIC/8E0P2r1UBVXwV4bVVUBVVV+IXg8KqqBhVAAAA4AGBXb/APBP G2ub3/gm7+yzZ2hYXl5+zN4StbUr94XNx4VaG3K/7XmumPet8Vx7xBX8P84z7C4lZfjOI+KcYqko qM3Sw+Iy+jUqYanKpF8tKV1GdknOMbSdpTUubBeHfD2G8Rsk4exeGlmWC4Y4SwXsoylKmq2Jw2YV adLE1Y05RUqsbSlT5m405SvFXjBx/Jn9nP4F+Ff+Cxv7UH7Rf7U37UB1zxn+zX8FPiLqHwT/AGb/ AIMR67q2jeErmHRNtzqvibWRpF5DPJLNp8ulXlwIZYnu7vXzHPKbXT7e3rnvix8KNG/4I2ft+fs3 /E/4AT6x4a/ZH/ax8Qj4V/Fz4WXWtalq/h/w3rrahp9iuqWEmq3Ukuy1i13TtV0+SeWW5gGj6pZi f7HciJffv+DdPXbU/shfF/wDcOqeKPAn7SfjEeI7R8LdxNrnhjwitpNcxYyoa40bVIwT1e0kUfdN R/8ABwzbwaj8AP2XtGtVWXxTqv7WHhG18NW6ANeyzS+GfEltcfZUHzN+/utPVsDG6aMdSte4syx6 8WMT4b1a8/8AUmdOeUrL+Z/VY4VYJypYmNL4FiFVUca8Tb2zqNy57Ox4DyzL5eDmF8UKNCH+vcKt POXmNl9bli3j1GrhZVfjeGdJywP1S/sVTSiqfMrnZ/8ABYX40/FPxT4x/Zn/AOCc/wACfFFz4L8c /tgeJ/s3xD8YadJPDqPh/wCEttqC6ZfW0E1rKksVleGLX7m98tkkmsvCstnvEV5LXFfGL/gh7+z9 8HPglN8Rv2Qb/wCIXw6/ap+BeiXHxD+HnxQbxpq+pX3jPxV4PspNXl0nxJo0z/YbeDVY7S5tlWxt 7SOFr1UkSe186CXjP2pbs+GP+C/n7B9/4sl26VqnwYt/D+g3Fy/7hte1C0+MujRJCzcCaTXLy0jG OWkuUXqwr+iPxBd2dhoGvX2oPHHp9nomrXV9JKQIks7fT7ia6eQtwIxAkhOeMDmvj8w4hzngbJPD jBcN4qWEwmZ4L+08YqfwZhiMRi8RSnSxcbWxFKnQo08OqNRSgouXu80mz7XK+G8l4/z7xPx/E+Ej jMZlWYf2VgpVP4mXYbD4LDVoVsHJ64atUxFepiHXp8s3NR97likfz4f8G9mh6J8Q/wBhb47aD410 bS/EGheMP2hfGlp4k0TVtPtrzStStNX8B+BDf2l1pt1E8UkBMz4RlYKVGBlRXF/8EJvD2jfAD9oT /goT+yHq2jaXa+OPhn8RrXUtG1trC1TXtW8E6TrWseFJLc6l5XnTaMsS+Eb2OLeYRJr7SqC0havW P+DdCaC4/ZC+NFxa4+yz/tP+M5rbaAF+zy+DfAskG0DoPKZcVxfxsMP7I/8AwXn+B/xYkkj0nwB+ 2V8LLjwT4qvGYWti/im20xvC0huJDhA66z4Z+Gtw7HJzqLMSN2a+uz2tVzLjDxx4PUpRWcYd43D0 03risqVHFqnGOicqmHWIg9NeWKtorfGcPUaeV8FeAPGjUZ/2LiYYDEVGlZYTOPbYN1Jyab5aeJeH mm2uXmk7q7T+pPhJ8MvAvxa/4LJftT/GiLwh4dkX9mr4H/B/4SQ61HpFiJrr4sfEGG88Y6x4he5E GZvEtn4PWLTTdH/SI7e4WISCPCn4k/4J0fAX4B/8FMPij+2J+1P+15oVh8cPiPYfHPWvh34N+G3i /WNSn0P4VfDHSbaOTwxFp3hW01KIRwSxSzWcMsqNCH0O4liH2uW6lP6Xf8EpbC48S/BP4sftK6pC yax+1v8AtKfGX42wTTDE/wDwha+KLjwT8PLXcetpH4Y8KW8kI6bL4kDDc/mz+1p/wRB+N+m/G/xr +0n/AME9vj3J8JvEfjHVtS8Wal8PLrxP4k8A3en69q142qava+D/AB14X8xJNCutTmuJ4tO1K3SG 2acxC6aAIsfl5dm2W0834o4VxvFU+D8zw2AyzKcFmb9rKNGWWqCx+GlVpSVShTxmJU5OpGUYKMOW TcWoS9fMsnzWpk3CXF+A4RhxrleKzDNc4x2Vp0ozrxzRzll2KhSqxlSxFXBYWVOCpyjKbc+aCUk5 w/Wj9i/9hTwL+xF48/aVg+EVomjfCD4yeIPh74z8H+FH1C71K58H6rpOh67pXizQIri+LzSaGt5P YXFg00ssqx6g9szstsrv9+1+F/8AwSB/az/ax8f+Mv2iP2Qf21obu9+Nn7N48O6hH4j1WDTF8R3u h61PcWNxpniK/wBEAtPERicaRd6fqkWWvbPWt0kk2xJD+6FflXH2CzzAcUY7D8RZhTzbM1TwreLp VHWp4qi8LRWHxEKrSdX2tBU5SqS96U3Jyu22fr/h3j8gzLhPL8Tw1l1XJ8qdTFxWDrU/Y1cJWWLr /WcNOim1S9jiHVhGnF8sIqMY2ikl4P8AtH/s1fBz9rH4Wa18Hfjj4Tg8V+DdXeO7gCzPY614e1u2 SVNP8SeGNZgHm6Lr1t50vlzR5Vklkgnjmt5ZYn/gT/4KS/8ABPnxx+wB8a28JXcmo+JvhB40+2av 8HviNcwxg65o9vIn23w5r720SxW3jTS2mhjvIlVFuIpYb6BEiuPLi/0ZK8H/AGkP2afg5+1j8K9c +Dvxv8J2/inwjrI8+3lUra674a1qKOSOw8TeFNYWNpNE8QWxlcxTx5V1d4J45reWWF/rfCfxXzLw 6zWFLEzqY7hfGSf1nCp35HKy+s4eMmoxrRsuaN4xrQThJqShOHxXjJ4OZV4nZPOrh4UsBxbgo/7L jHG3Oo3f1bEyinKVCd3yytKVGdpwvF1IVP8AL/pVdo2WRHaN42WRJEYo6OhDK6MpyrBgCCOQRkV+ y/7bv/BEz9qv9lfUvEXin4caDqX7QXwNsBd6lZ+MvBlitx408P6NCXlaLxx4EtXa7iuLe2Uma901 LuydIzOxtQWhj/Gbgg+nII/Qgjsc5zX+hnD/ABNkPFeAhmXD+aUc0wk0runJOUHJX5KtN2nSnbeF SMZLsf5m8S8J8R8HZlPK+JcorZTjIN2VSLUKii7OdGor060O06cpR8z9rf2dP+CLn7fv7X+ieHPi H481G3+FngfVNOt7rw34h+O/iXxHq3iq90G7jiuLa70HwTCLzULPT5rd4pIftraak6MkiboyHr+k j9hr/gi5+y5+x1c6V458QW7fHr42WHlXNt498d6VZpoHhe/VOZvAngcvPbaNcpISY766kvdQUqGh nt8lKy/+CHv7Yk37UP7IGl+DPFmqtqPxT/Z1m0/4a+KJ7qcy6hrXhEWjyfDjxNcNIxeaSTQ7SfTp pGJZ7nwxLK5zMK/Ziv4P8VPE7xGnnGe8H5ji45FgMDWqUZYbBQ9jGpS3puVXWvOnWpSjUceeFOcZ +9TV+Vf6KeEHhR4Y08k4e43yzBz4hzHMcPSrxxeYT+sTp1rWqRjSsqFOpRrRlTUuSdSnKFo1W1zM 57kk9yeScDHJ78Cobi5hs7ee7uXEVvawy3M8jEBY4YI2mlkYk4CrGjE+wqavjr9rv4y2fgvwbdeA tHvEfxd4xtHtbqOCQGXRfDk4KXt3cbTmGe6j3wQKcMVkllAwik/zPxNxBgeF8jzDO8fUUKOCpylG LdnUqNWp0od51J2iktruTtFNr9/xuLpYHDVsTVdo0k2l/M/sxXm3p+Ox8H/B9ZPGH7RXhS8t0LDU fiDN4iO0Y2WsF9d67K5A6KIIT+OK/Qf9s+/is/gfqFu7KH1TxH4dsoFJGWeK7k1F9oPXEVi5NfPn 7Dfw3nuta1v4n39uUsNLt5/D3h53XAudSuwh1e6hJHzJBZeXDkcb7916oRU/7dvjiG61Lwj8PbSY O2lxT+JtZRHBEdzfIbLSIZAD8sgtFvpMHnbdoe4r+auH1U4c8EeLM5zH3MRxdUqxoxejnHEKGFi0 nrr+/rLvSSktNT43CqWD4ax+IraTzBy5V3U7QX/t0vTVHQfsDWUq6Z8StRIIhm1Dw5Yo2PlMlvba ncSgHHJC3MP/AH3XI/t7XaP4q+HtiCDJb+HdXu3HcJeanBFGTz3NlL+VfSv7H/hCTwv8GNLvbmEw 3ni7Ub7xNIrKVk+xz+VY6XuyBw1hYxSD2uM96+E/2wPEo8S/GzWbO0fz4/DOnaX4ahVDuzeQxPfX kagHlxe6hJGQO8OOtdfFEHkPgBw/leI93EZrLDNRfxfvq9TMLW30glFro2k9S8cvqnCmEoT0niHD Tr70nV/IzvD3g7UbvQNDuo4pSlzo+mXCEIcFJrKCRSPl6YYUV+pHgn4U6HpXgzwjpl7APtmneGNA sLvKpn7TZ6VaW8+c/wDTWN6K9vBeC9WWDwkquIjCrKlTck73UuWN09N09Drp8Ot06blNJuKuvOyv 0PxA/wCCvnwW/aI+PH7SX7G2vfBT9nf4qfEzw7+zR4vTx58QvEehWvhqw0a/s9Q8V/D3xFHo/hC4 8QeI7R/EetR6f4V1ATpDH5UU00UJlZzII/6AtC1ca/ouk66um6vo66xp1pqY0nX7B9L13TBewpP9 g1jTZGZrDU4t+yaEkmORGXJxmvmrxfrf7aVv4o16HwL8PPgFqXg2LUZk8Nah4i8Y+MLHXbzSQE+z z6tZ2Vi0Ntekl9yRsVGBg1zv/CQft+/9Ev8A2af/AAu/HP8A8rq/c8/8aqWPyrIeGavBOeRpcIfW qFKvQybMairqtXdWrNz5ZUqkZVbzpTpKEXTa+JWZxZRkuFyTiLivP6dTG4nEcVVcPOvTlh/3VOWE orDUfYOFNS5fYpKfPKpzyXOnG9n5f/wVY8LfEf4nfsU/Fv4KfCT4XeN/ip8Q/i9Y6P4Z8PaX4Qtd JFlpMmn+J9A8QXureKdY1zVrO20XSV0/S7lY2aR5J52SKKM5dk77/gnLpnjbwl+xt8CPhp8R/hz4 0+F/jz4TeAvD/wAOfFPh3xpZafbzy6t4a0+C2m1XQ73SdSu7bWfD9wpR7e5imPVopUSWN1GkfEP7 fo6/DD9mgfXx345/+V3uKP8AhIf2/f8Aol/7NP8A4Xfjnt1/5h1cr8a8PLhSnwn/AKi5+sNDHSx/ t/7DzP2zrToxw7i1y+z9n7KMUkocymnLns3EuOV4aPF9TjDnxzxVTARy72H1b9yqEazxCkn7P2vt fayk3J1HHkfLyXSk/wAefiJ8Gf2w/wDgl1+2f8W/2lf2T/gbrf7TH7LH7St6+v8AxL+EHgx7t/Ev g/xRPqN3rF09tp+mWdzc2RttZ1LWp9Lv4bK8tDZa9Ppt7HC8UE9d98OfhZ+1t/wUw/a7+Cv7Sv7V HwG1f9l79l79l+8m8U/Cj4M+NLyW68b+PviJJc2V/aa5rtjd2drNHZR6hp2jTzTTWVrCINDhsbSO 4N1eXK/qSPEP7fwOR8MP2aQfbx346B/TTqQ+If2/STn4Yfs0k8Zz478dE+2f+JdX1dT6SyqYaOIl 4a5wuK44P6h/bP8AYebfW3hnR+r83s7/AFf619XfsPrbpur7K6VpWkfIUvDzLqWJlho5pmv+qEsd /aP9ifV4fU1ivbLE8qq+w+sfU/rP+0fU/aexdVXd4txfxv8A8Fe/2D/id+1H4S+Fvxy/Ztulsf2n v2aNefxP4Et47y20y98W6N9usNbl0XS9SvGWC38S2Ou6RYahpguXS3mY3drI6tcoy/OmjftVf8FN v22fh1J+yvd/sSeMP2Z/E/jPTJfAvx6/ac8aHWdD8HeF/Bl5CdP8c6r8PfCutaJby3HjPUNIa+t7 G2hvdQS3m1HfGxiUXMP6p/8ACQft+/8ARL/2af8Awu/HX/yupT4i/b+PB+GP7NJxjg+PPHXGeB10 71riyz6ROHweR5dk+YeGeb55PIKlSrlmJxORZqquClVkqk48tPkp4miqv76FHERnTVS/Mp0/3Z25 pwZhsZn+Z53lubZtkFPiOnTpZrhcNQi6WPjSh7OE+arRnUwtd0f3E6+GlCpKmlyuFRe0fwX/AMEO fgf8Z/2ZPgb8Vfg38bPg98QPhnrd78W9Z+IXhq/8TWmjy6HrfhPUdD8M+HbBINV0XV7lYNfS40S4 eeyuEglWF0mQMjME4P8A4OFfglqPj39mH4S/Fjwm0tv48+EHxs8OaTolxZTG21R7L4ryQeFVttMn idZPtv8Awl1t4OkjEZLL5buoGGNfsL8JNS/aU1DWdTi+Nvg/4UeHtCTTo30e5+HviLxFrWoz6qbu NZINQh1i1jSGx+xmZg6Et5igdM1+H/gb4k/tXf8ABQ39rv4dfAP4lfBbXvBn7PX7E/7QvjL4kfFj 4m6tY6zY6f8AGTxR8MvEfiKy+CGnLBqWi2dskjO2l3UllaveCZEn1Fnhhjt0b9Z8PuMsx404vxni /wDUXw9QyepLG4+hjadTBVfZqjVoyp08Ni5e2l9bdNYenFObc8RTkl7Ntx+f4myTJso8Nst8K6UM bj58QQ/s/LnOg/aRqQxFKpGrXlTpxhShhVP606k4wg6OGmub2nKpfuz+z78LdP8Agf8AA34PfB/T Y447P4ZfDjwZ4L/dKFWa58P6FY2GoXZA4Mk2oQ3Uznu05Pevxa+H37aH7ev7HKeIP2f/AI0f8E+/ jz+0FYeFfF3iuw+DPxY+Dk48Raf4q+Htz4g1O+8GaZ4ivbXTb2GK9tNGurG2Fw0sVytvbxx3VkJ4 nmm/Vvxlrn7aEHinXYfAnw9+AmpeDo7+UeHb/wAS+MPF9hr93poVDHNqtnY2LQ212XL7ljYqABjr XNjxF+38DgfDH9moHrgePPHQOOmcDTq/FcH4zZXluMz7DZ74c5zxVSzCvz1ZSynNY/7RRqVbV8Ni sLyNwqOrU5muenWpyTVmoyX3mcZTWrxyiORZrmHDVfIqc8PSlQwlPEUamHnGlCVKrRxFKpTmo+wp ypTi4yg4tpuMmn8uf8E5PgD8fI/i1+1B+3H+1J4LsvhX8Wf2ptR8Kad4d+D1rqMOq3vw3+GXgmxW 00Sz8R31v8j+IbqOLTfOj4kQaUJZkgluGtoP1urwH4U6r+01fa9fQ/Grwf8ACLw94bXSXl027+H/ AIl8Razq02s/ardY4Lq21i1SOPTzZm7ZnU7xIiKBgmvfq9qrxlV47qy4hqZXXyWNVU6FLCV8LWwc sPQwtOGHoUoUMQ3WVKFKnCMJzlKVSznKUpNs93hbJ8JkWT0cvwk69ZKpXrVauJSWIr4jEVp18RXq pRhHnrVqk5tQhGEU1GEYxSSKKKKzPoRQSCCOCOhr83vir/wSP/4J5/Gbxrq/xD8b/s5aB/wlniC9 udT1+/8ADHiHxh4MtdZ1K7Ktc6jfaR4X1+1szfSSKzySRwRtJJI8km92Zj+kFFeplWd5zkVaeIyX NsTlFerHllPDV6tCUo3vyylSlFyjfWzur67nk5vkGR8QUKeGz3JsLnWHpS54QxWHpYiEZbc0Y1YT UZW0uknbTY/nt8IfsXX/APwST/awu/2kvgbo/izxv+xL8VvDw8CfHDwVpn9reLPHnwBjlvrPUNG+ IsdhCs1746+HunaxbSNczxrPqemafq98Zo7mONJ2/oB0fWNJ8Q6TpuvaDqdhrWiazY2up6Rq+l3U N9pup6dewpcWl9Y3ls7R3VrLA6OjoxVlYEGtIEg5BwR3FZul6RpWiWosdG02x0mxEs862WnWsNlZ pNdStcXUsdrboqRPJcPJI+1RueRmPLEn1OI+KMXxV9Sxmcp4jPcLTjQqYvmvLFUaatReIi1riKUf 3brp3rU1BVI+0hKpU8rhjhPBcIfXsDkjWGyDF1Z4ilg1G0cJWqu9aOHkn7uGqy/eKg4/uarqezn7 OcaVLx39ofx140+HHw21HxV4I0+wvL20uba31C6vkknGi6feM0H9sQ2S4W7eK6e2UrIfLQTeY6uq la/Mj4V/CLx/+0N4uutX1K81E6TPfm58WeONTDzB3yDNa6fJKQt9qrIAkcUf7qBQpk2RqFP7Oanp mn61p19pGrWcGoaZqVrNZX9jdRiW2u7S4QxT288bcPG0bMCPfjB5ryn4hfFP4b/Ajw5ZQan9m05V tJE8OeEdDtYY7y+S3wvl2NlEFjtLQSFRJPIUjQtklnwp/nfj7gbAZ7nOF4g4q4llg+DsnpRnUwc5 +zpOspNOXPeKhGrFxhKynXk706Uo88eXqzXLKWKxFPF47Gunl+Him6bdo81976WUlZPeT2i1fS14 g1vwN+z78MFmEMeneHvDNglhoulxyKLzVtQZXNrZRM3NzqNzc73mlIJG6Wd8Kpx+TnhDQfE/7R3x kI1F5JLnxHqsuteJr6IN5GkaBbvH9pERbiKOKzWC1tV7u8S+tP8AH3xD+Iv7SPjrTrOGwnuZJrh7 Pwn4O0svLZ6XDKR5s0jtgSXJjAa6vJdqqiYHlxKq1+oPwB+CGm/Bnwr9ldob/wAW60ILnxNq8Skq 8yKfI0qwZhuXTLfe4XoZZGaVgMqq/nzlW8ZuJsvy/LcJLA+G3Ck48z5fZxxEoJJQjBJKLnBKnSp/ FQw8p1Jcs6kaZ5XvcR42jSo03SybANdLKbSskl0utEvswbbs2keheLvEeh/C7wFqmvzxxWmjeEtD C2dmhCK32SBLTSdMtx3eScWsKD1kz2r8ivgX4Y1D4v8Axy0m41cPeRNrdz438UzkFkMFpef2lMjk 9Em1KS2gUHqJ8djXrH7Yfxuh8Ya0nw38N3iz+HPDF40+u3sD7oNW8RQh4hbRuhxNZWKtIu4ZV7l3 IyIkY/UH7I3wjk+HvgV/EutWpg8UeOEtr6aKZNtxpugxqz6Tp7hhmKWQSvczLwQZ40YBo8V351Vh 4m+JuU8PZelV4W4IftcVOP8ACqVYSjzwVvdcZThTw0EuixFSF4K5piZRzrOsPhKNpYHLPem18Lkm rrs02lBek2tD60JyST1PJxwPyooor+kj7I/LPxr/AME7/H+u+Ob/AMeeFv2o/iH4W1HXfEvx18Ra 3po1DxFJo0L/ABXv7iLwzaeHbTTdetX0e20Xw9LDDOPNeTUZocCa0gWBIKeqfsBfFe/8N65pcPxi 8OWk2vaLq+n6JpEI+Kg8OfBR7zW31WXT/g/5/j+acaPq1s5t9Z/tgXkoH/IO+y2uLIfqxRX2EOO+ JYRw8PrsJLDW5L4ehdJSlNJtU02k5NK7bUL0r+ylOEvi5eH/AAvKeIn9SqReJvz2xGIs24Rg2k6r UW4wTfKknUtVt7WMJx/MFP2Kf2itP10az4W/aasvCljpHxD8RfErQPC8fh/xX4gsNR1nxP4ZsfB2 oaT4s1jU/F0d1f8AhaLQJvEgsLBVeHTrnU4JbNYks7aODmLf/gnl8bdP0zT9Lm/a18VeOrbTdX8J ahH/AMJxH4gE93p3hLUfh7ZWWgXk2k62Emsn8FfDjSba4keGSS71LUtR1K4DPfzof1loojx1xFDk ca1BOCir/U8LztRbklKp7H2kvelKTbk23Jtt6WcuAuG583NRxElJydnjcXyJzUYycaftvZx92MYp KCSjFJJa3/Kt/wDgnX8RZ4YIb79qPxrqzaZodvY+F7zVJPFMmpeEL2Twn8WdO1e007UbHxbby6p4 en8W/EDRNQhS6Y31la+G00+3vQtvp81p1l5+xH8T77QPhppNt8abTwnJ4P8AEXxG1yaLwyPiL/Z3 g618aa34G1jTNE+GIvvHbXH2OytfCOtWBGuy6jb/AGb4hat9ns4Ivs9tH+lFFRPjjiSpKnOeMhKV FuUf9nw6Sbpzpt8qpKLbjUne8XzSlKTu5T5qp8B8MUoVIU8FUjGqlGX+04ltpVKdVLmdVySjKlDl 5ZLljGMY2UIKP5XN/wAE/fipeWniDSNV/aGa70vWNBn0y6vl0/xgviXxLqM/h7xRpul6n4m1k+MC 8EehXOuadb6Rb2BggksdDt5LlFvlaZ/Q/hN+yJ8avhz8RLHxFr3x6sfH/gK/1XxZf+I/h9qejeLN NtNL0/xX4VsfBj+H/Bt3H4vnCaXZeHvDPg6O0F5GSk9rqF4FW5vpJa/Q6iprca8QYilWoVsRSnSr wlCS+rYdaSjytxapKUJWtaUHGSSjGLUYxirocD8O4etQxFHDVY1cPONSL+tYlrmjLnipRdVxnFO9 4zUotylJpylKT/OPxL+xB49ufBvwj8L+FPjrrel6n4Ci+KaeJ/GHiLUPG3ifXPFjfEGIw2kjC68U KFvbK1tdGtre8lZruytdLaCzkSK6uUfiB/wT8+JcV9p+uJ8b7e41fSfGWm67p8F4/j64tG8P6f8A ETW/Gkmg6veXfiqeTX7ia31SGKS7u4pZ2FnFbSyTRQRyn9U6KdLjbiKlDkji4OLlOTvQott1Kk6s 024Xac6krK9oxfLG0dCanAnDVWp7WeDnzKMIK1eulFU6dOlBqKqWTUKULu15SXNK8rNflXo/7Bn7 SGhQWttZ/tseLL1bXX/hz4yjuNd8Panqk8OsfCq+8Ta34Y8JxInimASeBbzxB4rvJtYWYy3V/b6T YWkxlhgxXo0f7Jvxnk+Bfi/4LTfFbQbaS7+JVj8RfBHjOKTx1e6rozyeMZ/E9/oviI3mu/aPF+m2 8kFhJFHqNzcx3/2ueyvlMEEFw36HUUq3GmfYiUJ1atBzp1adaLjhMLBqrSa5Jv2dKKk0lyWkpJwc o296V6ocD8P4aM4UaWIjCpSqUJKWMxVROlVT54L2labim3zpwcWpqMr3jG3ivwm8EfEXwhrfxW1H x14p8PeJLTx740sPGWhW+iWfiCzbw2//AAhfhfwrq+iLHrWr3SLpLXXhaK+tktxEEm1i78xXYh29 qoor5zE4mpi6zr1VFTcYRtGKhG0IRpxtGKSXuxV9NXdvVs+mwuGpYOiqFFycFKcvek5yvUnKpK8p Nt+9J2V7JWSskkFFFFc50BRRRQAUUUUAFeDfH34IWfxr8O6ZpyX1vo2u6NqcV1putTWz3Qhsrhki 1eykijdWljkt1R0XcAJrWMkhSxr3mivNzfKcvz3LcXlOa4dYrAY6PJUg21dXTTUotSjKMkpRlFqU ZJNNNGOIw9LFUamHrw9pSqq0lqr9d1qmnqmtUzx/4S/BHwR8HdMe38O2rXer3USrq3ibU1ifV9Q2 Dc0YkUBbCwDAsIIgqDALl2G+vlv9pX9qi2soNR+Hvww1FbnUpVmsfEXi2xlDW+nxMDFcaboNzHxc agQWWW5Q7IBlYmaXLR6f7a2tfFHSNP8AD9p4e1K5tvAfiISaRq1vo8EseqT66WeSCwvr2DMslhc2 mfKhj2B5LaRJPMyi15r8Bf2P9R1iWx8V/Fi0l0rRE8q5sPBrkw6pqoGHibXChzpmnEYzACLiUcP5 Sn5vwvinNeIauOqeFfhvw9LJaWEhCOJxnL7KlRoVoqXNTnHmUITjJ89eTliKkvaRpw9qnJ/MY7EY uVV5Hk2EeGVNJTqW5YxjJJ3TV7Jp6y1m3dJc2pgfsqfs8z+NtTs/iL4xsmTwZpVyJ9GsLuM58Vap byApM0cn+s0OCddzseLiWMRDciy1+rVQWtrbWVtb2dnbwWlpaQx29ra20SQW9vBCgjihghjAWKJU UBVAAAGBU9fqXAvBOW8DZLTyzBP2+Kq2nicQ1aVera17a8tOGsaVO7UI3bcpynOXuZZltHLMMqNL 3py1nPrKX6JbJdPNttlFFFfaHohRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAc94h+7of/Yy6P8A+jJa6Jup+p/nRRXLS/3nF/8AcP8A9JZnH+JU/wC3fyEooorqNAoo ooA//9k= ------_=_NextPart_001_01CE9F41.095AD6DB-- From bernard_aboba@hotmail.com Thu Aug 22 14:37:47 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B35C21F8436 for ; Thu, 22 Aug 2013 14:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdFiFVcvfXsr for ; Thu, 22 Aug 2013 14:37:41 -0700 (PDT) Received: from blu0-omc2-s20.blu0.hotmail.com (blu0-omc2-s20.blu0.hotmail.com [65.55.111.95]) by ietfa.amsl.com (Postfix) with ESMTP id CE7C821F84B8 for ; Thu, 22 Aug 2013 14:37:40 -0700 (PDT) Received: from BLU169-W120 ([65.55.111.73]) by blu0-omc2-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Aug 2013 14:37:34 -0700 X-TMN: [39l5XROacQUA7gyqzVcYA8Jqkw6ARnf84FxH8PJT5CM=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_a6e05ae6-f436-470d-8902-14ceb06b1712_" From: Bernard Aboba To: "Mo Zanaty (mzanaty)" , Roni Even Date: Thu, 22 Aug 2013 14:37:33 -0700 Importance: Normal In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D508265@xmb-rcd-x14.cisco.com> References: , , <3879D71E758A7E4AA99A35DD8D41D3D91D487E63@xmb-rcd-x14.cisco.com>, , , , <3AD93742-DBA4-4EDD-80AD-A667994ECE8D@vidyo.com>, <034a01ce9f16$bc2d8600$34889200$@gmail.com>, <3879D71E758A7E4AA99A35DD8D41D3D91D508265@xmb-rcd-x14.cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 22 Aug 2013 21:37:34.0540 (UTC) FILETIME=[D057C8C0:01CE9F7F] Cc: "payload@ietf.org" Subject: Re: [payload] RFC 6190 Single Session Transport (multiple-SSRCs vs. single SSRC) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2013 21:37:47 -0000 --_a6e05ae6-f436-470d-8902-14ceb06b1712_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Roni said:=20 =20 Maybe if you want to use FEC only on the base layer and not on all layers. =20 [BA] Yes=2C that is one advantage (though by no means the biggest one).=20 =20 Mo said:=20 =20 =0A= =0A= =0A= =0A= "Selective forwarding of layers at a switch is simpler with MST versus SST= =2C since SST requires rewriting timestamps and sequence numbers to drop la= yers. RTCP reporting per=0A= layer is another benefit of MST. These advantages stem from using multiple= SSRCs independent of whether they use the same or separate transport flows= ." [BA] Yes=2C this is perhaps the biggest advantage=2C particularly when = encryption is used=2C although completely avoiding decryption typically eit= her requires SDP extensions (to expose SSRC dependency groups) and/or RTP e= xtensions (to expose information that would normally only be obtained by de= crypting the PACSI NAL unit). =0A= =0A= "I think the entire nomenclature of SST/MST should evolve to Single/Multipl= e SSRC (not Session) Transport=2C since that is really what matters." [BA] = For much of RFC 6190 it is the distinction between multiple and single SSR= C transmission that matters=2C and the term "MST" can be interpreted as "m= ulti-SSRC transmission"=2C whether or not it occurs within a single RTP ses= sion. However=2C this isn't true everywhere in the document. For example= =2C Section 1.2.2 says: "MST should be used in a multicast session when di= fferent receivers=0A= may request different layers of the scalable bitstream." In this case MS= T really does mean "multi-session transport". So the single/multi-sessio= n distinction will probably need to remain in a few places. "So updating = the nomenclature would align with both current deployments and future stand= ards like BUNDLE/UP." [BA] While it probably wouldn't help clarify things t= o do a global replace of "multi-session" with "multi-SSRC" I do agree that = it's important for to be more thoughtful about this going forward. In part= icular=2C while it might be too late to fix the interop issues causes by RF= C 6190=2C we probably do have the ability to make sure that the same proble= ms don't crop up in future PAYLOAD documents. "Note that MST is already w= idely deployed this way=2C which is non-standard." [BA] I agree that multi= -SSRC single-session transmission is widely deployed. However=2C I couldn'= t find anywhere in RFC 6190 where it is stated that MST implementations MUS= T use multiple sessions (or even anything about what uses of SSRCs are enco= uraged/discouraged)=2C and in fact=2C the design accommodates multi-SSRC si= ngle-session transmission quite well. So I don't agree that multi-SSRC sin= gle-session transmission is "non-standard". =0A= =0A= =0A= =0A= =0A= From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org]=0A= On Behalf Of Jonathan Lennox =0A= Sent: 19 July=2C 2013 5:54 PM =0A= To: Bernard Aboba =0A= Cc: mmusic@ietf.org =0A= Subject: Re: [MMUSIC] RFC 6190 Single Session Transport=0A= =0A= =0A= =0A= =0A= =0A= =0A= On Jul 18=2C 2013=2C at 10:02 PM=2C Bernard Aboba wrote:=0A= =0A= =0A= =0A= =0A= Jonathan said: =0A= =0A= "I don't understand how single-session multi-source transmission will work = without either a) signaling "a=3Dssrc-group DDP" decoding dependencies=2C o= r b) making various implementation-specific=0A= assumptions about the structure of the SVC streams." =0A= =20 =0A= [BA] In terms of SDP choices for expressing layering within a single m line= =2C you can either go the a=3Dssrc-group:DDP route=2C or use distinct paylo= ad types for each layer and RFC 5583 a=3Dgroup:DDP (this is what "Unified P= lan" Section 4.7 appears to advocate). =20 =0A= =0A= I'm not sure how "MST within a single session" could be expressed in SDP wi= thout BUNDLE. Was the idea to use multiple m lines and group them together= but use the same port? =0A= =0A= =0A= =0A= =0A= =0A= =0A= I think the authors of RFC 6190 didn't see a use case for MST within a sing= le RTP session -- all of the interesting MST use cases they saw involved se= parate transport flows for the separate layers=2C and if you're sending all= the layers on=0A= a single transport flow=2C SST is significantly simpler.=0A= =0A= =0A= =0A= =0A= =0A= What requirement are you trying to achieve that's met by MST in a single se= ssion=2C but not by SST?=0A= =0A= =0A= =0A= =0A= --=0A= =0A= =0A= Jonathan Lennox =0A= jonathan@vidyo.com=0A= =0A= =0A= =0A= =0A= = --_a6e05ae6-f436-470d-8902-14ceb06b1712_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Roni said:
 =3B
Maybe= if you want to use FEC only on the base layer and not on all layers.
 =3B
[BA] Yes=2C that is one advantage (though by no means the bi= ggest one).
 =3B
Mo said:
 =3B
=0A= =0A= =0A=
=0A=

"Selective forwarding of layers at a switch is s= impler with MST versus SST=2C since SST requires rewriting timestamps and s= equence numbers to drop layers. RTCP reporting per=0A= layer is another benefit of MST. These advantages stem from using multiple= SSRCs independent of whether they use the same or separate transport flows= ."

 =3B

[BA] =3B Yes=2C this is perhaps the biggest advantage=2C par= ticularly when encryption is used=2C although completely avoiding decryptio= n typically either requires SDP extensions =3B(to expose SSRC dependenc= y groups) and/or RTP extensions (to expose information that would normally = only be obtained by decrypting the PACSI NAL unit). =3B

=0A=

 =3B

=0A=

"I think the entire nomenclature of SST/MST shou= ld evolve to Single/Multiple SSRC (not Session) Transport=2C since that is = really what matters."

 =3B<= /p>

[BA] =3B For much of RFC 6190 it is the d= istinction between multiple and single SSRC transmission that matters=2C&nb= sp=3B and the term "MST" can be interpreted as "multi-SSRC transmission"=2C= whether or not it occurs within a single RTP session. =3B =3B Howe= ver=2C this isn't true =3Beverywhere in the document. =3B For examp= le=2C Section 1.2.2 says:

&nb= sp=3B

"MST should be used in= a multicast session when different receivers=0A= may request different layers of the scalable bitstream."

 =3B

In this case MST really does mean = "multi-session transport". =3B =3B =3B So the single/multi-sess= ion distinction will probably need to remain in a few places.

 =3B

=

"So =3B updating the nomenclature would al= ign with both current deployments and future standards like BUNDLE/UP."

 =3B

[BA] While it probably wouldn't help cla= rify things to do a global replace of "multi-session" with "multi-SSRC" I d= o agree that it's important for to be more thoughtful about this going forw= ard.

 =3B

In particular=2C while it might be too late to fix the interop issue= s causes by RFC 6190=2C we probably do have the ability to make sure that t= he same =3Bproblems don't crop up in future PAYLOAD documents. <= /p>

 =3B

 =3B

"Note that MST is alrea= dy widely deployed this way=2C which is non-standard."

 =3B

[BA] = =3B I agree that =3Bmulti-SSRC single-session transmission =3Bis wi= dely deployed. =3B However=2C I couldn't find anywhere in RFC 6190 wher= e it is stated that MST implementations MUST use multiple sessions (or even= anything about what uses of SSRCs are encouraged/discouraged)=2C and in fa= ct=2C the design accommodates multi-SSRC single-session transmission quite = well. =3B So I don't agree that multi-SSRC single-session transmission = is "non-standard". =3B

 =3B

=0A=

 =3B=0A=

=0A=
=0A=
=0A=

From: mmusic-bounces@ietf.org [mail= to:mmusic-bounces@ietf.org]=0A= On Behalf Of Jonathan Lennox
=0A= Sent: 19 July=2C 2013 5:54 PM
=0A= To: Bernard Aboba
=0A= Cc: mmusic@ietf.org
=0A= Subject: Re: [MMUSIC] RFC 6190 Single Session Transport

= =0A=
=0A=
=0A=

 =3B

=0A=

 =3B

=0A=
=0A=
=0A=

On Jul 18=2C 2013=2C at 10:02 PM=2C Bernard Aboba= <=3Bbernard_aboba@hotmail.c= om>=3B wrote:

=0A=
=0A=

 =3B

=0A=
=0A=
=0A=

Jonathan said: =3B

=0A=
=0A=

"I don't understand how single-session multi-source transmission wi= ll work without either a) signaling "a=3Dssrc-group DDP" decoding dependenc= ies=2C or b) making various implementation-specific=0A= assumptions about the structure of the SVC streams."
=0A=  =3B
=0A= [BA] In terms of SDP choices for expressing layering within a single m line= =2C you can either go the a=3Dssrc-group:DDP route=2C or use distinct paylo= ad types for each layer and RFC 5583 a=3Dgroup:DDP (this is what "Unified P= lan" Section 4.7 appears to advocate). =3B =3B
=0A=
=0A= I'm not sure how "MST within a single session" could be expressed in SDP wi= thout BUNDLE. =3B Was the idea to use multiple m lines and group them t= ogether but use the same port?&nbs= p=3B

=0A=
=0A=
=0A=
=0A=

 =3B

=0A=
=0A=
=0A=

I think the authors of RFC 6190 didn't see a use = case for MST within a single RTP session -- all of the interesting MST use = cases they saw involved separate transport flows for the separate layers=2C= and if you're sending all the layers on=0A= a single transport flow=2C SST is significantly simpler.

=0A=
=0A=
=0A=

 =3B

=0A=
=0A=
=0A=

What requirement are you trying to achieve that's= met by MST in a single session=2C but not by SST?

=0A=
=0A=

 =3B

=0A=
=0A=
=0A=

--

=0A=
=0A=
=0A=

Jonathan Lennox
=0A= jonathan@vidyo.com

=0A=
=0A=
=0A=

 =3B

=0A=
=0A=
= --_a6e05ae6-f436-470d-8902-14ceb06b1712_-- From jmvalin@mozilla.com Thu Aug 22 20:16:35 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149C311E8196 for ; Thu, 22 Aug 2013 20:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kx39YXP2uWHA for ; Thu, 22 Aug 2013 20:16:29 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 505AC11E8193 for ; Thu, 22 Aug 2013 20:16:29 -0700 (PDT) Received: from [192.168.1.15] (modemcable130.97-201-24.mc.videotron.ca [24.201.97.130]) (Authenticated sender: jvalin@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 18E75F210C; Thu, 22 Aug 2013 20:16:26 -0700 (PDT) Message-ID: <5216D40A.50800@mozilla.com> Date: Thu, 22 Aug 2013 23:16:26 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Timothy B. Terriberry" References: <52156792.3000501@xiph.org> In-Reply-To: <52156792.3000501@xiph.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: payload@ietf.org Subject: Re: [payload] draft-ietf-payload-rtp-opus X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2013 03:16:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/21/2013 09:21 PM, Timothy B. Terriberry wrote: > Therefore I propose we add the following sentence to the second to > last paragraph of section 3.1.3: "The transmitter MUST drop whole > frames only, to ensure successive RTP timestamps differ by a > multiple of 120 and to allow the receiver to use whole frames for > concealment." Yes, makes sense. I'll add that. Jean-Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSFtQKAAoJEJ6/8sItn9q9VhMH/1g8+kL1GPg33zT3v+kuxkLT PJ1LroYCevwtIi/4eBcxWX9+0KNYqFfHk1EjCGztCv6Hh/n/A85vh3Fu5igCa1O0 3sEOc9ztwu1FpmoguH/d/rScS9JZDwFjmAuXeMYfAOcji8OSyQgBWtleU67U6OyR 176Fq2cZo4b5pCzpcYiZn2xBsSKNpsuc+jmC3NpN4Gavnsbe32KlZuWypQ/VGaNM Rutz6BNyVdMdPi5jBEY64Annf39b8deech9UddKf8yk3NPWEEkVSSXb/w3RI8LbZ WPf/9vwqmFUvaf4wbbNIC818QPFoE6yn0YeIUAwfgVuM+IMg5nX1hR5XAPJ3GmM= =Q8Yk -----END PGP SIGNATURE----- From internet-drafts@ietf.org Mon Aug 26 06:48:20 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A1E11E81D0; Mon, 26 Aug 2013 06:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xpJqr30o4JA; Mon, 26 Aug 2013 06:48:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A8911E81CF; Mon, 26 Aug 2013 06:48:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130826134811.5471.14234.idtracker@ietfa.amsl.com> Date: Mon, 26 Aug 2013 06:48:11 -0700 Cc: payload@ietf.org Subject: [payload] I-D Action: draft-ietf-payload-rtp-sbc-06.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 13:48:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Payloads Working Gr= oup of the IETF. Title : RTP Payload Format for Bluetooth's SBC Audio Codec Author(s) : Christian Hoene Frans de Bont Filename : draft-ietf-payload-rtp-sbc-06.txt Pages : 23 Date : 2013-08-26 Abstract: This document specifies a Real-time Transport Protocol (RTP) payload format to be used for the low complexity subband codec (SBC), which is the mandatory audio codec of the Advanced Audio Distribution Profile (A2DP) Specification written by the Bluetooth(r) Special Interest Group (SIG). The payload format is designed to be able to interoperate with existing Bluetooth A2DP devices, to provide high streaming audio quality, interactive audio transmission over the internet, and ultra-low delay coding for jam sessions on the internet. This document contains also a media type registration which specifies the use of the RTP payload format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-payload-rtp-sbc There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-payload-rtp-sbc-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-payload-rtp-sbc-06 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 frans.de.bont@philips.com Mon Aug 26 06:54:07 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3563A21F9E9D for ; Mon, 26 Aug 2013 06:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ct7Wz4k8uGMo for ; Mon, 26 Aug 2013 06:54:01 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 154CB21F9301 for ; Mon, 26 Aug 2013 06:53:53 -0700 (PDT) Received: from mail67-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE012.bigfish.com (10.9.40.32) with Microsoft SMTP Server id 14.1.225.22; Mon, 26 Aug 2013 13:53:52 +0000 Received: from mail67-tx2 (localhost [127.0.0.1]) by mail67-tx2-R.bigfish.com (Postfix) with ESMTP id 2B9B0A012C; Mon, 26 Aug 2013 13:53:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(z5621hz15d6Oc85fh9feI9251I217bIdd85kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah18c673h186068h8275dh1de097hz2dh2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h1155h) Received: from mail67-tx2 (localhost.localdomain [127.0.0.1]) by mail67-tx2 (MessageSwitch) id 1377525229809387_31562; Mon, 26 Aug 2013 13:53:49 +0000 (UTC) Received: from TX2EHSMHS041.bigfish.com (unknown [10.9.14.227]) by mail67-tx2.bigfish.com (Postfix) with ESMTP id B6D134C00BF; Mon, 26 Aug 2013 13:53:49 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS041.bigfish.com (10.9.99.141) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 26 Aug 2013 13:53:49 +0000 Received: from 011-DB3MMR1-023.MGDPHG.emi.philips.com (10.128.28.107) by 011-DB3MMR1-009.MGDPHG.emi.philips.com (10.128.28.48) with Microsoft SMTP Server (TLS) id 14.3.146.2; Mon, 26 Aug 2013 13:53:38 +0000 Received: from 011-DB3MPN1-019.MGDPHG.emi.philips.com ([169.254.9.152]) by 011-DB3MMR1-023.MGDPHG.emi.philips.com ([fe80::e485:97aa:9b41:86e3%11]) with mapi id 14.03.0146.002; Mon, 26 Aug 2013 13:53:32 +0000 From: "Bont, Frans de" To: Roni Even , "payload@ietf.org" Thread-Topic: review of http://tools.ietf.org/html/draft-ietf-payload-rtp-sbc-05 Thread-Index: Ac6B8vJzCBaBnd+wRcqvB/Q9vbGEfAgb5ZdA Date: Mon, 26 Aug 2013 13:53:32 +0000 Message-ID: References: <000a01ce81f3$f3e61020$dbb23060$@gmail.com> In-Reply-To: <000a01ce81f3$f3e61020$dbb23060$@gmail.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.100] Content-Type: multipart/alternative; boundary="_000_EB88DF006E9D2E449909FBD49813C0E323EBCBF2011DB3MPN1019MG_" MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "Christian Hoene \(Symonics\)" Subject: Re: [payload] review of http://tools.ietf.org/html/draft-ietf-payload-rtp-sbc-05 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 13:54:08 -0000 --_000_EB88DF006E9D2E449909FBD49813C0E323EBCBF2011DB3MPN1019MG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, Thanks for your review. An updated draft has been submitted a minute ago. T= he changes are described below. 1. The reference to A2DPV12 can be found at: https://www.bluetooth.or= g/docman/handlers/DownloadDoc.ashx?doc_id=3D66605 and has been added to the= document. 2. An explanation of the Join and RFA header fields is added to secti= on 3.2. 3. A default value for the "Capabilities" parameter has been added. T= his value represents the mandatory capabilities of A2DP devices. 4. "Symmetric" is indeed a better naming than "bi-direction" for a pa= rameter. As described, the negotiation is finished if the offerer and the a= nswerer have agreed upon explicit capabilities for each payload type number= , so when the sent and received "Capabilities" parameter are the same. 5. The reference to RFC4288 has been updated to RFC6838. We think the draft is now ready for WGLC. Best regards, Frans From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Tuesday 16 July 2013 9:13 To: payload@ietf.org Cc: Bont, Frans de; Christian Hoene (Symonics) Subject: review of http://tools.ietf.org/html/draft-ietf-payload-rtp-sbc-05 Hi, I read the document and have some questions and comments 1. The reference to A2DPV12 is normative but does not point to a spec= ific document. Can you provide a link to the specification. 2. The join and RFC frame header field are mentioned but not explaine= d in section 3.2 3. The "Capabilities" is an optional parameter. What is the default v= alues if not specified. Maybe it should be a required parameter. 4. In section 7.2.1 do you mean that the "capabilities" parameters is= symmetric, the send and receive MUST be the same? Please calrify Thanks Roni Even as individual ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_EB88DF006E9D2E449909FBD49813C0E323EBCBF2011DB3MPN1019MG_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,

 

Thanks for your review. An updated draft has been su= bmitted a minute ago. The changes are described below.

 

1.       The reference= to A2DPV12 can be found at: https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=3D66605 and has been added to the document.

2.       An explanatio= n of the Join and RFA header fields is added to section 3.2.

3.       A default val= ue for the “Capabilities” parameter has been added. This value = represents the mandatory capabilities of A2DP devices.

4.       “Symmet= ric” is indeed a better naming than “bi-direction” for a = parameter. As described, the negotiation is finished if the offerer and the= answerer have agreed upon explicit capabilities for each payload type numb= er, so when the sent and received “Capabilities” parameter are the same.

5.       The reference= to RFC4288 has been updated to RFC6838.

 

We think the draft is now ready for WGLC.

 

Best regards,

Frans

 

From: Roni E= ven [mailto:ron.even.tlv@gmail.com]
Sent: Tuesday 16 July 2013 9:13
To: payload@ietf.org
Cc: Bont, Frans de; Christian Hoene (Symonics)
Subject: review of http://tools.ietf.org/html/draft-ietf-payload-rtp= -sbc-05

 

Hi,

I read the document and have some questions and comm= ents

 

1.       The reference to A2DPV12 is normativ= e but does not point to a specific document. Can you provide a link to the = specification.

2.       The join and RFC frame header field are mentioned but = not explained in section 3.2

3.       The “Capabilities” is an optional paramete= r. What is the default values if not specified. Maybe it should be a requir= ed parameter.

4.       In section 7.2.1 do you mean that the “capabilit= ies” parameters is symmetric, the send and receive MUST be the same? = Please calrify

Thanks

Roni Even as individual

 

 


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_EB88DF006E9D2E449909FBD49813C0E323EBCBF2011DB3MPN1019MG_-- From harald@alvestrand.no Mon Aug 26 07:56:30 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDF421E8087 for ; Mon, 26 Aug 2013 07:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.244 X-Spam-Level: X-Spam-Status: No, score=-110.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHSVqnup3nwa for ; Mon, 26 Aug 2013 07:56:23 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 7615C21E804C for ; Mon, 26 Aug 2013 07:56:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 7F51639E170 for ; Mon, 26 Aug 2013 16:56:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccpze297NAj9 for ; Mon, 26 Aug 2013 16:56:21 +0200 (CEST) Received: from [IPv6:2001:470:de0a:27:35ea:8afd:74a3:27be] (unknown [IPv6:2001:470:de0a:27:35ea:8afd:74a3:27be]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8485339E106 for ; Mon, 26 Aug 2013 16:56:21 +0200 (CEST) Message-ID: <521B6CCF.9000808@alvestrand.no> Date: Mon, 26 Aug 2013 16:57:19 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: payload@ietf.org References: <51E6A4D9.30003@alvestrand.no> <957DBFE5-900D-44CB-BDE2-FB96BB83B3AE@iii.ca> <520B77F5.4000800@alvestrand.no> <520B7AEB.9080100@xiph.org> <520CE3D2.1070306@alvestrand.no> In-Reply-To: <520CE3D2.1070306@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 14:56:31 -0000 Note that this is still awaiting: 1) Verification by Cullen that this change would satisfy his request 2) Consensus call by the chairs about whether or not this change should be made On 08/15/2013 04:21 PM, Harald Alvestrand wrote: > On 08/14/2013 02:41 PM, Timothy B. Terriberry wrote: >> Harald Alvestrand wrote: >>> These parameters were added because people on this list asked for them. >>> So far, I do not think they have been added to any existing >>> implementation, and we don't seem to be seeing many interoperability >>> problems because of that. >>> >>> I don't think this is because of "luck". I think it's because these are >>> not the constraints that are the most constraining in most practical >>> situations - other constraints make sure we never reach the limits that >>> might have been encoded using max-fr and max-fs. >> I respectfully disagree. I think it's because implementations on >> resource-constrained mobile devices are still somewhat immature (ours >> certainly is). Earlier in this thread I pointed you to where we are >> adding support for these parameters for precisely this use-case. I >> thought we had agreement from the Chrome team that they would support >> them as well (c.f. our WebRTC office hours call on June 10th, where I >> recall you saying something to the effect of, "If we put them in the >> spec, then we should support them."). If that is not the plan, then we >> have a problem. > I fully think we should support them in our implementations (as in - > parse them and obey the constraints they imply). > > I just don't think we should, in the spec, mandate sending them. > > To be specific: The change I think Cullen is suggesting is: > > == OLD == > > Required parameters: none > > Optional parameters: > > max-fr, max-fs These parameters MAY be used to signal the > capabilities of a receiver implementation. These parameters > MUST NOT be used for any other purpose. > > > == NEW == > > Required parameters: > > max-fr, max-fs These parameters MUST be used to signal the > capabilities of a receiver implementation. These parameters > MUST NOT be used for any other purpose. > > Optional parameters: none > > == END == > > If that's not the change you're suggesting, Cullen, please clarify. > > (note: the MUST NOT language means that the parameters are not allowed in a > sendonly a=fmtp line, so they should probably be formally optional > anyway - either that, or my change proposal is incomplete.) > > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From wwwrun@rfc-editor.org Mon Aug 26 09:31:46 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D432311E81BD for ; Mon, 26 Aug 2013 09:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.36 X-Spam-Level: X-Spam-Status: No, score=-102.36 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beeiIdItSlx6 for ; Mon, 26 Aug 2013 09:31:46 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 6D36211E81BB for ; Mon, 26 Aug 2013 09:31:46 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 54E0B8E018; Mon, 26 Aug 2013 09:26:42 -0700 (PDT) To: stewe@stewe.org, yekui.wang@huawei.com, ts@thomas-schierl.de, alex@vidyo.com, rlb@ipv.sx, gonzalo.camarillo@ericsson.com, abegen@cisco.com, roni.even@mail01.huawei.com From: RFC Errata System Message-Id: <20130826162642.54E0B8E018@rfc-editor.org> Date: Mon, 26 Aug 2013 09:26:42 -0700 (PDT) X-Mailman-Approved-At: Mon, 26 Aug 2013 09:33:00 -0700 Cc: payload@ietf.org, rfc-editor@rfc-editor.org Subject: [payload] [Technical Errata Reported] RFC6190 (3711) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 16:31:46 -0000 The following errata report has been submitted for RFC6190, "RTP Payload Format for Scalable Video Coding". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6190&eid=3711 -------------------------------------- Type: Technical Reported by: Xiaohui Wei (Joanne) Section: 1.1.3 Original Text ------------- N: 1 bit no_inter_layer_pred_flag. This flag specifies, when present in a coded slice NAL unit, whether inter-layer prediction may be used for decoding the coded slice (when equal to 1) or not (when equal to 0). Corrected Text -------------- N: 1 bit no_inter_layer_pred_flag. This flag specifies, when present in a coded slice NAL unit, whether inter-layer prediction may be used for decoding the coded slice (when equal to 0) or not ^ (when equal to 1). ^ Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6190 (draft-ietf-avt-rtp-svc-27) -------------------------------------- Title : RTP Payload Format for Scalable Video Coding Publication Date : May 2011 Author(s) : S. Wenger, Y.-K. Wang, T. Schierl, A. Eleftheriadis Category : PROPOSED STANDARD Source : Audio/Video Transport Payloads Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From yekuiw@qti.qualcomm.com Mon Aug 26 21:51:04 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D30611E814F; Mon, 26 Aug 2013 21:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qk+3zq93g2Lp; Mon, 26 Aug 2013 21:50:51 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id BC06311E814E; Mon, 26 Aug 2013 21:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1377579051; x=1409115051; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=sTE8l5f5e7b+bGxI/EM45K46fjVBRoil8spbMvxuXh0=; b=sXmXiJx446nTqYcDjUu98BSCnHVH49NuJNUuTNKL8Tm97rzHrVRxfk4/ PC0lgEJKE9aFyWz4MtLr1DNz664+3BspNkpvJI38KO9QEVxXSQAEkYekp hSjNheV+H1Uceb56S6PqQb/GzqFj/Fy69erUmjrICRbya2TIo92iw0+3w M=; X-IronPort-AV: E=McAfee;i="5400,1158,7179"; a="70834475" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 26 Aug 2013 21:50:50 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7179"; a="502177744" Received: from nasanexhc10.na.qualcomm.com ([172.30.48.3]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 26 Aug 2013 21:50:50 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.196]) by nasanexhc10.na.qualcomm.com ([172.30.48.3]) with mapi id 14.03.0146.002; Mon, 26 Aug 2013 21:50:50 -0700 From: "Wang, Ye-Kui" To: Ross Finlayson , "avt@ietf.org" , "payload@ietf.org" Thread-Topic: [AVTCORE] [payload] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit Thread-Index: AQHOl5G5Kw+UmANe70imwgNSo5t7VZmojqFg Date: Tue, 27 Aug 2013 04:50:49 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A83385120E1@nasanexd02f.na.qualcomm.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> <69F25DB2-6926-4ACA-935D-90376A2A7BFA@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D690F@nasanexd02f.na.qualcomm.com> <3879D71E758A7E4AA99A35DD8D41D3D91D4CC65C@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4@nasanexd02f.na.qualcomm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.106.115.192] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A83385120E1nasanexd02fnaqu_" MIME-Version: 1.0 Subject: Re: [payload] [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 04:51:05 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A83385120E1nasanexd02fnaqu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ross, Sorry for a slow response. I started to edit this draft today, and have inc= luded the following note after the semantics of the M bit: Informative note: The content of a NAL unit does not tell whether or not th= e NAL unit is the last NAL unit, in decoding order, of an access unit. An = RTP sender implementation may obtain this information from the video encode= r. If, however, the implementation cannot obtain this information directly= from the encoder, e.g., when the stream was pre-encoded, and also there is= no timestamp allocated for each NAL unit, then the sender implementation c= an inspect subsequent NAL units in decoding order to determine whether or n= ot the NAL unit is the last NAL unit of an access unit as follows. A NAL u= nit naluX is the last NAL unit of an access unit if the next VCL NAL unit n= aluY in decoding order has the high-order bit of the first byte after its N= AL unit header equal to 1, and all NAL units between naluX and naluY, when = present, have nal_unit_type in the range of 32 to 35, inclusive, equal to 3= 9, in the range of 41 to 44, inclusive, or in the range of 48 to 55, inclus= ive. Would you be fine with this wording? BR, YK From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross = Finlayson Sent: Monday, August 12, 2013 12:25 PM To: avt@ietf.org; payload@ietf.org Subject: Re: [AVTCORE] [payload] Clarifying the H.265 RTP payload format sp= ecification's text on when to set the RTP "M" bit You just need one more little step to get everything right here, instead of= thinking of compromising the implementation :) That is, read subclause 7.4.2.4.4 of the HEVC spec. The most relevant parag= raphs are copied below for convenience (the first paragraph itself contains= the answer to your question, but the second paragraph may also provide hel= pful information) Thanks for the info; that was useful. Here, then is the updated text of a paragraph - to be added after the exist= ing 'M bit' text - that clarifies when/how to set it: ---------- Unfortunately the contents of a NAL unit, alone, do not tell a RTP sender i= mplementation whether or not the NAL unit ends an access unit. Instead, th= e implementation may be able to obtain this information separately, from th= e encoder. If, however, the implementation cannot obtain this information = directly from the encoder (e.g., because the implementation is sending data= that consists solely of a sequence of pre-encoded NAL units), then it must= instead inspect subsequent NAL units, to determine whether or not the NAL = unit ends an access unit. If the NAL units have already been timestamped, = then these timestamps can be used to determine the access unit boundaries. = Otherwise, the access unit boundaries (and times) must be determined by in= specting the NAL units' contents - specifically, the "nal_unit_type" and (f= or VCL NAL units) the "first_slice_segment_in_pic_flag". The following rul= e can be used: A NAL unit (X) ends an access unit if the next-occurring VCL NAL= unit (Y) has the high-order bit of the first byte after its NAL unit heade= r equal to 1, and all NAL units, if any, between (X) and (Y) have a "nal_un= it_type" in one of the following ranges: [32,35], 39, [41,44], or [48,55]. ---------- Ross Finlayson Live Networks, Inc. http://www.live555.com/ --_000_8BA7D4CEACFFE04BA2D902BF11719A83385120E1nasanexd02fnaqu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ross,

 <= /p>

Sorry for a slow response= . I started to edit this draft today, and have included the following note = after the semantics of the M bit:

 <= /p>

Informative note: The con= tent of a NAL unit does not tell whether or not the NAL unit is the last NA= L unit, in decoding order, of an access unit.  An RTP sender implement= ation may obtain this information from the video encoder.  If, however, the implementation cannot obtain this in= formation directly from the encoder, e.g., when the stream was pre-encoded,= and also there is no timestamp allocated for each NAL unit, then the sende= r implementation can inspect subsequent NAL units in decoding order to determine whether or not the NAL unit is th= e last NAL unit of an access unit as follows.  A NAL unit naluX is the= last NAL unit of an access unit if the next VCL NAL unit naluY in decoding= order has the high-order bit of the first byte after its NAL unit header equal to 1, and all NAL units between= naluX and naluY, when present, have nal_unit_type in the range of 32 to 35= , inclusive, equal to 39, in the range of 41 to 44, inclusive, or in the ra= nge of 48 to 55, inclusive.

 <= /p>

Would you be fine with th= is wording?

 <= /p>

BR, YK<= /p>

 <= /p>

 <= /p>

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ross Finlayson
Sent: Monday, August 12, 2013 12:25 PM
To: avt@ietf.org; payload@ietf.org
Subject: Re: [AVTCORE] [payload] Clarifying the H.265 RTP payload fo= rmat specification's text on when to set the RTP "M" bit

 

You just need one more li= ttle step to get everything right here, instead of thinking of compromising= the implementation J

 <= /p>

That is, read subclause 7= .4.2.4.4 of the HEVC spec. The most relevant paragraphs are copied below fo= r convenience (the first paragraph itself contains the answer to your question, but the second paragraph may also provide helpful inform= ation)

 

Thanks for the info; that was useful.

 

Here, then is the updated text of a paragraph - to b= e added after the existing 'M bit' text - that clarifies when/how to set it= :

----------

Unfortunately the contents of a NAL unit, alone, do = not tell a RTP sender implementation whether or not the NAL unit ends an ac= cess unit.  Instead, the implementation may be able to obtain this inf= ormation separately, from the encoder.  If, however, the implementation cannot obtain this information direc= tly from the encoder (e.g., because the implementation is sending data that= consists solely of a sequence of pre-encoded NAL units), then it must inst= ead inspect subsequent NAL units, to determine whether or not the NAL unit ends an access unit.  If the NA= L units have already been timestamped, then these timestamps can be used to= determine the access unit boundaries.  Otherwise, the access unit bou= ndaries (and times) must be determined by inspecting the NAL units' contents - specifically, the "nal_unit_type= " and (for VCL NAL units) the "first_slice_segment_in_pic_flag&qu= ot;.  The following rule can be used:

   &nb= sp;       A NAL unit (X) ends an acces= s unit if the next-occurring VCL NAL unit (Y) has the high-order bit of the= first byte after its NAL unit header equal to 1, and all NAL units, if any= , between (X) and (Y) have a "nal_unit_type" in one of the following ranges: [= 32,35], 39, [41,44], or [48,55].

----------

 

Ross Finlayson
Live Networks, Inc.
http:/= /www.live555.com/

 

--_000_8BA7D4CEACFFE04BA2D902BF11719A83385120E1nasanexd02fnaqu_-- From finlayson@live555.com Mon Aug 26 22:39:03 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6815E21F9B18; Mon, 26 Aug 2013 22:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wL8z-lSQS4pF; Mon, 26 Aug 2013 22:38:58 -0700 (PDT) Received: from ns.live555.com (ns.live555.com [4.79.217.242]) by ietfa.amsl.com (Postfix) with ESMTP id E680F21F99C0; Mon, 26 Aug 2013 22:38:58 -0700 (PDT) Received: from [127.0.0.1] (localhost.live555.com [127.0.0.1]) by ns.live555.com (8.14.4/8.14.4) with ESMTP id r7R5crrk011687; Mon, 26 Aug 2013 22:38:54 -0700 (PDT) (envelope-from finlayson@live555.com) Content-Type: multipart/alternative; boundary="Apple-Mail=_A2B275B2-78D8-432C-9001-6B09994EF54F" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ross Finlayson In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83385120E1@nasanexd02f.na.qualcomm.com> Date: Mon, 26 Aug 2013 22:38:53 -0700 Message-Id: <969F6DF9-BABB-4438-BAC0-E0F36049ED63@live555.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> <69F25DB2-6926-4ACA-935D-90376A2A7BFA@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D690F@nasanexd02f.na.qualcomm.com> <3879D71E758A7E4AA99A35DD8D41D3D91D4CC65C@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4@nasanexd02f.na.qualcomm.com> <8BA7D4CEACFFE04BA2D902BF11719A83385120E1@nasanexd02f.na.qualcomm.com> To: "Wang, Ye-Kui" X-Mailer: Apple Mail (2.1508) Cc: "avt@ietf.org" , "payload@ietf.org" Subject: Re: [payload] [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 05:39:03 -0000 --Apple-Mail=_A2B275B2-78D8-432C-9001-6B09994EF54F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 26, 2013, at 9:50 PM, "Wang, Ye-Kui" = wrote: > Hi Ross, > =20 > Sorry for a slow response. I started to edit this draft today, and = have included the following note after the semantics of the M bit: > =20 > Informative note: The content of a NAL unit does not tell whether or = not the NAL unit is the last NAL unit, in decoding order, of an access = unit. An RTP sender implementation may obtain this information from the = video encoder. If, however, the implementation cannot obtain this = information directly from the encoder, e.g., when the stream was = pre-encoded, and also there is no timestamp allocated for each NAL unit, = then the sender implementation can inspect subsequent NAL units in = decoding order to determine whether or not the NAL unit is the last NAL = unit of an access unit as follows. A NAL unit naluX is the last NAL = unit of an access unit if the next VCL NAL unit naluY in decoding order = has the high-order bit of the first byte after its NAL unit header equal = to 1, and all NAL units between naluX and naluY, when present, have = nal_unit_type in the range of 32 to 35, inclusive, equal to 39, in the = range of 41 to 44, inclusive, or in the range of 48 to 55, inclusive. > =20 > Would you be fine with this wording? Yes, this looks good to me. Ross Finlayson Live Networks, Inc. http://www.live555.com/ --Apple-Mail=_A2B275B2-78D8-432C-9001-6B09994EF54F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Aug 26, 2013, = at 9:50 PM, "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com> = wrote:

Hi = Ross,
 
Sorry for a slow response. I started to edit = this draft today, and have included the following note after the = semantics of the M bit:
 
Informative note: The content of a NAL unit does not tell = whether or not the NAL unit is the last NAL unit, in decoding order, of = an access unit.  An RTP sender implementation may obtain this = information from the video encoder.  If, however, the = implementation cannot obtain this information directly from the encoder, = e.g., when the stream was pre-encoded, and also there is no timestamp = allocated for each NAL unit, then the sender implementation can inspect = subsequent NAL units in decoding order to determine whether or not the = NAL unit is the last NAL unit of an access unit as follows.  A NAL = unit naluX is the last NAL unit of an access unit if the next VCL NAL = unit naluY in decoding order has the high-order bit of the first byte = after its NAL unit header equal to 1, and all NAL units between naluX = and naluY, when present, have nal_unit_type in the range of 32 to 35, = inclusive, equal to 39, in the range of 41 to 44, inclusive, or in the = range of 48 to 55, inclusive.
 
Would you be fine with this = wording?

Yes, this = looks good to me.

Ross = Finlayson
Live Networks, Inc.
http://www.live555.com/=

= --Apple-Mail=_A2B275B2-78D8-432C-9001-6B09994EF54F-- From mzanaty@cisco.com Tue Aug 27 15:58:13 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6A221F9FDE; Tue, 27 Aug 2013 15:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmhxfMUV1z2M; Tue, 27 Aug 2013 15:58:07 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5195A21F9FD5; Tue, 27 Aug 2013 15:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19322; q=dns/txt; s=iport; t=1377644287; x=1378853887; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=m1IodV4vhwp3VKwwMjjzN3Dfqy1McOhoshExXCoohvU=; b=J1E+5lxIBEC+wy8yL38ck5SDgJNnS+QCGJDBSG+vHrJVSiN/cKR/kese nNMJ5bJDY6P5e1L3bzLZW6yAUHtNKMTqYs7vZJ2zi2VkXhTfPFiaVTGgL FwA0nljOX+bKadHJEpgsHmgcCiXT1hZrCrnAJt9gjfPT3iP2IZ/+0QgfC 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocFAI4uHVKtJV2c/2dsb2JhbABZgkNENYN4u3UBgQwXgQsWdIIkAQEBBAEBASAKTBACAQgRBAEBJAQDAgICJQsUCQgCBA4FiAEMpjaSKo9JFwQGAQmCXzR9A5QVg1qRYIFjgT0 X-IronPort-AV: E=Sophos;i="4.89,971,1367971200"; d="scan'208,217";a="252472492" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 27 Aug 2013 22:58:06 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7RMw6el019282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Aug 2013 22:58:06 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.38]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 27 Aug 2013 17:58:05 -0500 From: "Mo Zanaty (mzanaty)" To: "Wang, Ye-Kui" Thread-Topic: [AVTCORE] [payload] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit Thread-Index: AQHOo3jjnEEyNQElLUmyU/ypjzM8DQ== Date: Tue, 27 Aug 2013 22:58:04 +0000 Message-ID: <75CC2B0E-28F2-452C-9CE5-060DB8DFEE6B@cisco.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> <69F25DB2-6926-4ACA-935D-90376A2A7BFA@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D690F@nasanexd02f.na.qualcomm.com> <3879D71E758A7E4AA99A35DD8D41D3D91D4CC65C@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4@nasanexd02f.na.qualcomm.com> <8BA7D4CEACFFE04BA2D902BF11719A83385120E1@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A83385120E1@nasanexd02f.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_75CC2B0E28F2452C9CE5060DB8DFEE6Bciscocom_" MIME-Version: 1.0 Cc: "avt@ietf.org" , "payload@ietf.org" Subject: Re: [payload] [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 22:58:13 -0000 --_000_75CC2B0E28F2452C9CE5060DB8DFEE6Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdWdnZXN0IHJlcGxhY2luZyAiVGhlIGNvbnRlbnQgb2YgYSBOQUwgdW5pdCIgd2l0aCAiVGhl IE5BTCB1bml0IGhlYWRlciIuIFRoZSBjb250ZW50IGRvZXMgcmV2ZWFsIGVuZCBvZiBhY2Nlc3Mg dW5pdCBib3VuZGFyaWVzIGlmIHlvdSdyZSB3aWxsaW5nIHRvIHBhcnNlL2RlY29kZSBpdCBhbGwu DQoNCk1vDQoNCg0KT24gQXVnIDI3LCAyMDEzLCBhdCAxMjo1MSBBTSwgIldhbmcsIFllLUt1aSIg PHlla3Vpd0BxdGkucXVhbGNvbW0uY29tPG1haWx0bzp5ZWt1aXdAcXRpLnF1YWxjb21tLmNvbT4+ IHdyb3RlOg0KDQpIaSBSb3NzLA0KDQpTb3JyeSBmb3IgYSBzbG93IHJlc3BvbnNlLiBJIHN0YXJ0 ZWQgdG8gZWRpdCB0aGlzIGRyYWZ0IHRvZGF5LCBhbmQgaGF2ZSBpbmNsdWRlZCB0aGUgZm9sbG93 aW5nIG5vdGUgYWZ0ZXIgdGhlIHNlbWFudGljcyBvZiB0aGUgTSBiaXQ6DQoNCkluZm9ybWF0aXZl IG5vdGU6IFRoZSBjb250ZW50IG9mIGEgTkFMIHVuaXQgZG9lcyBub3QgdGVsbCB3aGV0aGVyIG9y IG5vdCB0aGUgTkFMIHVuaXQgaXMgdGhlIGxhc3QgTkFMIHVuaXQsIGluIGRlY29kaW5nIG9yZGVy LCBvZiBhbiBhY2Nlc3MgdW5pdC4gIEFuIFJUUCBzZW5kZXIgaW1wbGVtZW50YXRpb24gbWF5IG9i dGFpbiB0aGlzIGluZm9ybWF0aW9uIGZyb20gdGhlIHZpZGVvIGVuY29kZXIuICBJZiwgaG93ZXZl ciwgdGhlIGltcGxlbWVudGF0aW9uIGNhbm5vdCBvYnRhaW4gdGhpcyBpbmZvcm1hdGlvbiBkaXJl Y3RseSBmcm9tIHRoZSBlbmNvZGVyLCBlLmcuLCB3aGVuIHRoZSBzdHJlYW0gd2FzIHByZS1lbmNv ZGVkLCBhbmQgYWxzbyB0aGVyZSBpcyBubyB0aW1lc3RhbXAgYWxsb2NhdGVkIGZvciBlYWNoIE5B TCB1bml0LCB0aGVuIHRoZSBzZW5kZXIgaW1wbGVtZW50YXRpb24gY2FuIGluc3BlY3Qgc3Vic2Vx dWVudCBOQUwgdW5pdHMgaW4gZGVjb2Rpbmcgb3JkZXIgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgb3Ig bm90IHRoZSBOQUwgdW5pdCBpcyB0aGUgbGFzdCBOQUwgdW5pdCBvZiBhbiBhY2Nlc3MgdW5pdCBh cyBmb2xsb3dzLiAgQSBOQUwgdW5pdCBuYWx1WCBpcyB0aGUgbGFzdCBOQUwgdW5pdCBvZiBhbiBh Y2Nlc3MgdW5pdCBpZiB0aGUgbmV4dCBWQ0wgTkFMIHVuaXQgbmFsdVkgaW4gZGVjb2Rpbmcgb3Jk ZXIgaGFzIHRoZSBoaWdoLW9yZGVyIGJpdCBvZiB0aGUgZmlyc3QgYnl0ZSBhZnRlciBpdHMgTkFM IHVuaXQgaGVhZGVyIGVxdWFsIHRvIDEsIGFuZCBhbGwgTkFMIHVuaXRzIGJldHdlZW4gbmFsdVgg YW5kIG5hbHVZLCB3aGVuIHByZXNlbnQsIGhhdmUgbmFsX3VuaXRfdHlwZSBpbiB0aGUgcmFuZ2Ug b2YgMzIgdG8gMzUsIGluY2x1c2l2ZSwgZXF1YWwgdG8gMzksIGluIHRoZSByYW5nZSBvZiA0MSB0 byA0NCwgaW5jbHVzaXZlLCBvciBpbiB0aGUgcmFuZ2Ugb2YgNDggdG8gNTUsIGluY2x1c2l2ZS4N Cg0KV291bGQgeW91IGJlIGZpbmUgd2l0aCB0aGlzIHdvcmRpbmc/DQoNCkJSLCBZSw0KDQoNCkZy b206IGF2dC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphdnQtYm91bmNlc0BpZXRmLm9yZz4gW21h aWx0bzphdnQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvc3MgRmlubGF5c29uDQpT ZW50OiBNb25kYXksIEF1Z3VzdCAxMiwgMjAxMyAxMjoyNSBQTQ0KVG86IGF2dEBpZXRmLm9yZzxt YWlsdG86YXZ0QGlldGYub3JnPjsgcGF5bG9hZEBpZXRmLm9yZzxtYWlsdG86cGF5bG9hZEBpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gW3BheWxvYWRdIENsYXJpZnlpbmcgdGhlIEgu MjY1IFJUUCBwYXlsb2FkIGZvcm1hdCBzcGVjaWZpY2F0aW9uJ3MgdGV4dCBvbiB3aGVuIHRvIHNl dCB0aGUgUlRQICJNIiBiaXQNCg0KWW91IGp1c3QgbmVlZCBvbmUgbW9yZSBsaXR0bGUgc3RlcCB0 byBnZXQgZXZlcnl0aGluZyByaWdodCBoZXJlLCBpbnN0ZWFkIG9mIHRoaW5raW5nIG9mIGNvbXBy b21pc2luZyB0aGUgaW1wbGVtZW50YXRpb24g4pi6DQoNClRoYXQgaXMsIHJlYWQgc3ViY2xhdXNl IDcuNC4yLjQuNCBvZiB0aGUgSEVWQyBzcGVjLiBUaGUgbW9zdCByZWxldmFudCBwYXJhZ3JhcGhz IGFyZSBjb3BpZWQgYmVsb3cgZm9yIGNvbnZlbmllbmNlICh0aGUgZmlyc3QgcGFyYWdyYXBoIGl0 c2VsZiBjb250YWlucyB0aGUgYW5zd2VyIHRvIHlvdXIgcXVlc3Rpb24sIGJ1dCB0aGUgc2Vjb25k IHBhcmFncmFwaCBtYXkgYWxzbyBwcm92aWRlIGhlbHBmdWwgaW5mb3JtYXRpb24pDQoNClRoYW5r cyBmb3IgdGhlIGluZm87IHRoYXQgd2FzIHVzZWZ1bC4NCg0KSGVyZSwgdGhlbiBpcyB0aGUgdXBk YXRlZCB0ZXh0IG9mIGEgcGFyYWdyYXBoIC0gdG8gYmUgYWRkZWQgYWZ0ZXIgdGhlIGV4aXN0aW5n ICdNIGJpdCcgdGV4dCAtIHRoYXQgY2xhcmlmaWVzIHdoZW4vaG93IHRvIHNldCBpdDoNCi0tLS0t LS0tLS0NClVuZm9ydHVuYXRlbHkgdGhlIGNvbnRlbnRzIG9mIGEgTkFMIHVuaXQsIGFsb25lLCBk byBub3QgdGVsbCBhIFJUUCBzZW5kZXIgaW1wbGVtZW50YXRpb24gd2hldGhlciBvciBub3QgdGhl IE5BTCB1bml0IGVuZHMgYW4gYWNjZXNzIHVuaXQuICBJbnN0ZWFkLCB0aGUgaW1wbGVtZW50YXRp b24gbWF5IGJlIGFibGUgdG8gb2J0YWluIHRoaXMgaW5mb3JtYXRpb24gc2VwYXJhdGVseSwgZnJv bSB0aGUgZW5jb2Rlci4gIElmLCBob3dldmVyLCB0aGUgaW1wbGVtZW50YXRpb24gY2Fubm90IG9i dGFpbiB0aGlzIGluZm9ybWF0aW9uIGRpcmVjdGx5IGZyb20gdGhlIGVuY29kZXIgKGUuZy4sIGJl Y2F1c2UgdGhlIGltcGxlbWVudGF0aW9uIGlzIHNlbmRpbmcgZGF0YSB0aGF0IGNvbnNpc3RzIHNv bGVseSBvZiBhIHNlcXVlbmNlIG9mIHByZS1lbmNvZGVkIE5BTCB1bml0cyksIHRoZW4gaXQgbXVz dCBpbnN0ZWFkIGluc3BlY3Qgc3Vic2VxdWVudCBOQUwgdW5pdHMsIHRvIGRldGVybWluZSB3aGV0 aGVyIG9yIG5vdCB0aGUgTkFMIHVuaXQgZW5kcyBhbiBhY2Nlc3MgdW5pdC4gIElmIHRoZSBOQUwg dW5pdHMgaGF2ZSBhbHJlYWR5IGJlZW4gdGltZXN0YW1wZWQsIHRoZW4gdGhlc2UgdGltZXN0YW1w cyBjYW4gYmUgdXNlZCB0byBkZXRlcm1pbmUgdGhlIGFjY2VzcyB1bml0IGJvdW5kYXJpZXMuICBP dGhlcndpc2UsIHRoZSBhY2Nlc3MgdW5pdCBib3VuZGFyaWVzIChhbmQgdGltZXMpIG11c3QgYmUg ZGV0ZXJtaW5lZCBieSBpbnNwZWN0aW5nIHRoZSBOQUwgdW5pdHMnIGNvbnRlbnRzIC0gc3BlY2lm aWNhbGx5LCB0aGUgIm5hbF91bml0X3R5cGUiIGFuZCAoZm9yIFZDTCBOQUwgdW5pdHMpIHRoZSAi Zmlyc3Rfc2xpY2Vfc2VnbWVudF9pbl9waWNfZmxhZyIuICBUaGUgZm9sbG93aW5nIHJ1bGUgY2Fu IGJlIHVzZWQ6DQogICAgICAgICAgIEEgTkFMIHVuaXQgKFgpIGVuZHMgYW4gYWNjZXNzIHVuaXQg aWYgdGhlIG5leHQtb2NjdXJyaW5nIFZDTCBOQUwgdW5pdCAoWSkgaGFzIHRoZSBoaWdoLW9yZGVy IGJpdCBvZiB0aGUgZmlyc3QgYnl0ZSBhZnRlciBpdHMgTkFMIHVuaXQgaGVhZGVyIGVxdWFsIHRv IDEsIGFuZCBhbGwgTkFMIHVuaXRzLCBpZiBhbnksIGJldHdlZW4gKFgpIGFuZCAoWSkgaGF2ZSBh ICJuYWxfdW5pdF90eXBlIiBpbiBvbmUgb2YgdGhlIGZvbGxvd2luZyByYW5nZXM6IFszMiwzNV0s IDM5LCBbNDEsNDRdLCBvciBbNDgsNTVdLg0KLS0tLS0tLS0tLQ0KDQpSb3NzIEZpbmxheXNvbg0K TGl2ZSBOZXR3b3JrcywgSW5jLg0KaHR0cDovL3d3dy5saXZlNTU1LmNvbS8NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkF1ZGlvL1ZpZGVvIFRyYW5z cG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRAaWV0Zi5vcmc8bWFpbHRvOmF2dEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo= --_000_75CC2B0E28F2452C9CE5060DB8DFEE6Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <35CF5F472498474DAA6FE9BE36C36192@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IiNGRkZG RkYiPg0KPGRpdj5JIHN1Z2dlc3QgcmVwbGFjaW5nICZxdW90O1RoZSBjb250ZW50IG9mIGEgTkFM IHVuaXQmcXVvdDsgd2l0aCAmcXVvdDtUaGUgTkFMIHVuaXQgaGVhZGVyJnF1b3Q7LiBUaGUgY29u dGVudCBkb2VzIHJldmVhbCBlbmQgb2YgYWNjZXNzIHVuaXQgYm91bmRhcmllcyBpZiB5b3UncmUg d2lsbGluZyB0byBwYXJzZS9kZWNvZGUgaXQgYWxsLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+TW88L2Rpdj4NCjxkaXY+PGJyPg0KPGJyPg0KT24gQXVnIDI3LCAyMDEzLCBhdCAxMjo1 MSBBTSwgJnF1b3Q7V2FuZywgWWUtS3VpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86eWVrdWl3 QHF0aS5xdWFsY29tbS5jb20iPnlla3Vpd0BxdGkucXVhbGNvbW0uY29tPC9hPiZndDsgd3JvdGU6 PGJyPg0KPGJyPg0KPC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdj4NCjxtZXRhIG5hbWU9IkdlbmVy YXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPGJh c2UgaHJlZj0ieC1tc2c6Ly85NzEvIj48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAq Lw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJ cGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIg MTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3Vu IjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFt ZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5hcHBsZS10YWItc3Bhbg0KCXttc28tc3R5 bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0 eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5IaSBSb3NzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U29ycnkgZm9yIGEgc2xvdyBy ZXNwb25zZS4gSSBzdGFydGVkIHRvIGVkaXQgdGhpcyBkcmFmdCB0b2RheSwgYW5kIGhhdmUgaW5j bHVkZWQgdGhlIGZvbGxvd2luZyBub3RlIGFmdGVyIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIE0gYml0 OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjlpbiI+SW5mb3Jt YXRpdmUgbm90ZTogVGhlIGNvbnRlbnQgb2YgYSBOQUwgdW5pdCBkb2VzIG5vdCB0ZWxsIHdoZXRo ZXIgb3Igbm90IHRoZSBOQUwgdW5pdCBpcyB0aGUgbGFzdCBOQUwgdW5pdCwgaW4gZGVjb2Rpbmcg b3JkZXIsIG9mIGFuIGFjY2VzcyB1bml0LiZuYnNwOyBBbiBSVFAgc2VuZGVyIGltcGxlbWVudGF0 aW9uIG1heSBvYnRhaW4gdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHRoZQ0KIHZpZGVvIGVuY29kZXIu Jm5ic3A7IElmLCBob3dldmVyLCB0aGUgaW1wbGVtZW50YXRpb24gY2Fubm90IG9idGFpbiB0aGlz IGluZm9ybWF0aW9uIGRpcmVjdGx5IGZyb20gdGhlIGVuY29kZXIsIGUuZy4sIHdoZW4gdGhlIHN0 cmVhbSB3YXMgcHJlLWVuY29kZWQsIGFuZCBhbHNvIHRoZXJlIGlzIG5vIHRpbWVzdGFtcCBhbGxv Y2F0ZWQgZm9yIGVhY2ggTkFMIHVuaXQsIHRoZW4gdGhlIHNlbmRlciBpbXBsZW1lbnRhdGlvbiBj YW4gaW5zcGVjdCBzdWJzZXF1ZW50DQogTkFMIHVuaXRzIGluIGRlY29kaW5nIG9yZGVyIHRvIGRl dGVybWluZSB3aGV0aGVyIG9yIG5vdCB0aGUgTkFMIHVuaXQgaXMgdGhlIGxhc3QgTkFMIHVuaXQg b2YgYW4gYWNjZXNzIHVuaXQgYXMgZm9sbG93cy4mbmJzcDsgQSBOQUwgdW5pdCBuYWx1WCBpcyB0 aGUgbGFzdCBOQUwgdW5pdCBvZiBhbiBhY2Nlc3MgdW5pdCBpZiB0aGUgbmV4dCBWQ0wgTkFMIHVu aXQgbmFsdVkgaW4gZGVjb2Rpbmcgb3JkZXIgaGFzIHRoZSBoaWdoLW9yZGVyIGJpdCBvZiB0aGUN CiBmaXJzdCBieXRlIGFmdGVyIGl0cyBOQUwgdW5pdCBoZWFkZXIgZXF1YWwgdG8gMSwgYW5kIGFs bCBOQUwgdW5pdHMgYmV0d2VlbiBuYWx1WCBhbmQgbmFsdVksIHdoZW4gcHJlc2VudCwgaGF2ZSBu YWxfdW5pdF90eXBlIGluIHRoZSByYW5nZSBvZiAzMiB0byAzNSwgaW5jbHVzaXZlLCBlcXVhbCB0 byAzOSwgaW4gdGhlIHJhbmdlIG9mIDQxIHRvIDQ0LCBpbmNsdXNpdmUsIG9yIGluIHRoZSByYW5n ZSBvZiA0OCB0byA1NSwgaW5jbHVzaXZlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Xb3VsZCB5b3UgYmUgZmluZSB3aXRoIHRoaXMg d29yZGluZz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSLCBZSzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOmF2dC1ib3VuY2VzQGlldGYub3Jn Ij5hdnQtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzphdnQtYm91bmNlc0BpZXRmLm9yZ10N CjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9zcyBGaW5sYXlzb248YnI+DQo8Yj5TZW50OjwvYj4gTW9u ZGF5LCBBdWd1c3QgMTIsIDIwMTMgMTI6MjUgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1h aWx0bzphdnRAaWV0Zi5vcmciPmF2dEBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpwYXls b2FkQGlldGYub3JnIj4NCnBheWxvYWRAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbQVZUQ09SRV0gW3BheWxvYWRdIENsYXJpZnlpbmcgdGhlIEguMjY1IFJUUCBwYXlsb2Fk IGZvcm1hdCBzcGVjaWZpY2F0aW9uJ3MgdGV4dCBvbiB3aGVuIHRvIHNldCB0aGUgUlRQICZxdW90 O00mcXVvdDsgYml0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+WW91IGp1c3QgbmVlZCBvbmUgbW9yZSBsaXR0bGUgc3RlcCB0byBnZXQgZXZl cnl0aGluZyByaWdodCBoZXJlLCBpbnN0ZWFkIG9mIHRoaW5raW5nIG9mIGNvbXByb21pc2luZyB0 aGUgaW1wbGVtZW50YXRpb248c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UaGF0IGlzLCByZWFkIHN1YmNsYXVzZSA3LjQuMi40LjQgb2YgdGhlIEhFVkMg c3BlYy4gVGhlIG1vc3QgcmVsZXZhbnQgcGFyYWdyYXBocyBhcmUgY29waWVkIGJlbG93IGZvciBj b252ZW5pZW5jZSAodGhlIGZpcnN0IHBhcmFncmFwaCBpdHNlbGYgY29udGFpbnMgdGhlIGFuc3dl cg0KIHRvIHlvdXIgcXVlc3Rpb24sIGJ1dCB0aGUgc2Vjb25kIHBhcmFncmFwaCBtYXkgYWxzbyBw cm92aWRlIGhlbHBmdWwgaW5mb3JtYXRpb24pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZv ciB0aGUgaW5mbzsgdGhhdCB3YXMgdXNlZnVsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJlLCB0aGVuIGlzIHRoZSB1cGRhdGVkIHRleHQg b2YgYSBwYXJhZ3JhcGggLSB0byBiZSBhZGRlZCBhZnRlciB0aGUgZXhpc3RpbmcgJ00gYml0JyB0 ZXh0IC0gdGhhdCBjbGFyaWZpZXMgd2hlbi9ob3cgdG8gc2V0IGl0OjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0tLS0tLS08bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVuZm9ydHVu YXRlbHkgdGhlIGNvbnRlbnRzIG9mIGEgTkFMIHVuaXQsIGFsb25lLCBkbyBub3QgdGVsbCBhIFJU UCBzZW5kZXIgaW1wbGVtZW50YXRpb24gd2hldGhlciBvciBub3QgdGhlIE5BTCB1bml0IGVuZHMg YW4gYWNjZXNzIHVuaXQuICZuYnNwO0luc3RlYWQsIHRoZSBpbXBsZW1lbnRhdGlvbiBtYXkgYmUg YWJsZSB0byBvYnRhaW4gdGhpcyBpbmZvcm1hdGlvbiBzZXBhcmF0ZWx5LCBmcm9tIHRoZSBlbmNv ZGVyLg0KICZuYnNwO0lmLCBob3dldmVyLCB0aGUgaW1wbGVtZW50YXRpb24gY2Fubm90IG9idGFp biB0aGlzIGluZm9ybWF0aW9uIGRpcmVjdGx5IGZyb20gdGhlIGVuY29kZXIgKGUuZy4sIGJlY2F1 c2UgdGhlIGltcGxlbWVudGF0aW9uIGlzIHNlbmRpbmcgZGF0YSB0aGF0IGNvbnNpc3RzIHNvbGVs eSBvZiBhIHNlcXVlbmNlIG9mIHByZS1lbmNvZGVkIE5BTCB1bml0cyksIHRoZW4gaXQgbXVzdCBp bnN0ZWFkIGluc3BlY3Qgc3Vic2VxdWVudCBOQUwgdW5pdHMsIHRvDQogZGV0ZXJtaW5lIHdoZXRo ZXIgb3Igbm90IHRoZSBOQUwgdW5pdCBlbmRzIGFuIGFjY2VzcyB1bml0LiAmbmJzcDtJZiB0aGUg TkFMIHVuaXRzIGhhdmUgYWxyZWFkeSBiZWVuIHRpbWVzdGFtcGVkLCB0aGVuIHRoZXNlIHRpbWVz dGFtcHMgY2FuIGJlIHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSBhY2Nlc3MgdW5pdCBib3VuZGFyaWVz LiAmbmJzcDtPdGhlcndpc2UsIHRoZSBhY2Nlc3MgdW5pdCBib3VuZGFyaWVzIChhbmQgdGltZXMp IG11c3QgYmUgZGV0ZXJtaW5lZCBieQ0KIGluc3BlY3RpbmcgdGhlIE5BTCB1bml0cycgY29udGVu dHMgLSBzcGVjaWZpY2FsbHksIHRoZSAmcXVvdDtuYWxfdW5pdF90eXBlJnF1b3Q7IGFuZCAoZm9y IFZDTCBOQUwgdW5pdHMpIHRoZSAmcXVvdDtmaXJzdF9zbGljZV9zZWdtZW50X2luX3BpY19mbGFn JnF1b3Q7LiAmbmJzcDtUaGUgZm9sbG93aW5nIHJ1bGUgY2FuIGJlIHVzZWQ6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBw bGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA8L3NwYW4+Jm5ic3A7QSBOQUwgdW5pdCAoWCkgZW5kcyBhbiBhY2Nlc3MgdW5p dCBpZiB0aGUgbmV4dC1vY2N1cnJpbmcgVkNMIE5BTCB1bml0IChZKSBoYXMgdGhlIGhpZ2gtb3Jk ZXIgYml0IG9mIHRoZSBmaXJzdCBieXRlIGFmdGVyIGl0cyBOQUwgdW5pdCBoZWFkZXIgZXF1YWwg dG8gMSwgYW5kIGFsbCBOQUwgdW5pdHMsIGlmIGFueSwgYmV0d2VlbiAoWCkNCiBhbmQgKFkpIGhh dmUgYSAmcXVvdDtuYWxfdW5pdF90eXBlJnF1b3Q7IGluIG9uZSBvZiB0aGUgZm9sbG93aW5nIHJh bmdlczogWzMyLDM1XSwgMzksIFs0MSw0NF0sIG9yIFs0OCw1NV0uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLS0tLS0tPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g Y2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5Sb3NzIEZpbmxheXNvbjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1z cGFuIj5MaXZlIE5ldHdvcmtzLCBJbmMuPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS1z dHlsZS1zcGFuIj48YSBocmVmPSJodHRwOi8vd3d3LmxpdmU1NTUuY29tLyI+aHR0cDovL3d3dy5s aXZlNTU1LmNvbS88L2E+PC9zcGFuPjwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188L3NwYW4+PGJyPg0KPHNwYW4+QXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUg TWFpbnRlbmFuY2U8L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0ibWFpbHRvOmF2dEBpZXRmLm9y ZyI+YXZ0QGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj48YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9hdnQ8L2E+PC9zcGFuPjxicj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_75CC2B0E28F2452C9CE5060DB8DFEE6Bciscocom_-- From yekuiw@qti.qualcomm.com Tue Aug 27 18:36:44 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3563711E810F; Tue, 27 Aug 2013 18:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dzONskcQer1; Tue, 27 Aug 2013 18:36:21 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 733F011E80F6; Tue, 27 Aug 2013 18:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1377653781; x=1409189781; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UPKwrPw2jtO0RxxUtEZpC1yOb4GNbcEqmbXFYfWerJM=; b=vlyKitEclIAwfcUWbQ1jfGoxiv4HI+2AT0t/6zbGO7lwtqh9GqJ/4Pyx +cdzhRqX5ZqDdC+/ine6NGYvGs50iBMZJF9ODhXLyf7MPCYtYbb5o7mxs OSyxU57UfnwoncWdZIUPj8cKv9hrIon8FUua8/dmL+8I3mnCQt444ZmX3 o=; X-IronPort-AV: E=McAfee;i="5400,1158,7180"; a="50444729" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 27 Aug 2013 18:36:20 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7180"; a="18566149" Received: from nasanexhc11.na.qualcomm.com ([172.30.39.6]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 27 Aug 2013 18:36:20 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.196]) by nasanexhc11.na.qualcomm.com ([172.30.39.6]) with mapi id 14.03.0146.002; Tue, 27 Aug 2013 18:36:20 -0700 From: "Wang, Ye-Kui" To: "Mo Zanaty (mzanaty)" Thread-Topic: [AVTCORE] [payload] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit Thread-Index: AQHOo3jm1moEaDpZa0yx3vgEUVhvCZmp1oPg Date: Wed, 28 Aug 2013 01:36:20 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A8338512D57@nasanexd02f.na.qualcomm.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> <69F25DB2-6926-4ACA-935D-90376A2A7BFA@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D690F@nasanexd02f.na.qualcomm.com> <3879D71E758A7E4AA99A35DD8D41D3D91D4CC65C@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4@nasanexd02f.na.qualcomm.com> <8BA7D4CEACFFE04BA2D902BF11719A83385120E1@nasanexd02f.na.qualcomm.com> <75CC2B0E-28F2-452C-9CE5-060DB8DFEE6B@cisco.com> In-Reply-To: <75CC2B0E-28F2-452C-9CE5-060DB8DFEE6B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A8338512D57nasanexd02fnaqu_" MIME-Version: 1.0 Cc: "avt@ietf.org" , "payload@ietf.org" Subject: Re: [payload] [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 01:36:45 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A8338512D57nasanexd02fnaqu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTW8sDQoNCiJUaGUgY29udGVudCBvZiBhIE5BTCB1bml0IiBjYW4gdGVsbCB3aGV0aGVyIHRo ZSBOQUwgdW5pdCBpcyB0aGUgbGFzdCBzbGljZSBvZiBhIHBpY3R1cmUsIGJ1dCB0aGUgbGFzdCBO QUwgdW5pdCBvZiBhbiBBVSBjYW4gYWxzbyBiZSBhIG5vbi1WQ0wgTkFMIHVuaXQuIENvbnNpZGVy aW5nIHRoaXMsICJ0aGUgY29udGVudCBvZiBhIE5BTCB1bml0IiBkb2VzIG5vdCB0ZWxsIHdoZXRo ZXIgYSBOQUwgdW5pdCBpcyB0aGUgbGFzdCBOQUwgdW5pdCBvZiBhbiBBVS4NCg0KQlIsIFlLDQoN CkZyb206IE1vIFphbmF0eSAobXphbmF0eSkgW21haWx0bzptemFuYXR5QGNpc2NvLmNvbV0NClNl bnQ6IFR1ZXNkYXksIEF1Z3VzdCAyNywgMjAxMyAzOjU4IFBNDQpUbzogV2FuZywgWWUtS3VpDQpD YzogUm9zcyBGaW5sYXlzb247IGF2dEBpZXRmLm9yZzsgcGF5bG9hZEBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtBVlRDT1JFXSBbcGF5bG9hZF0gQ2xhcmlmeWluZyB0aGUgSC4yNjUgUlRQIHBheWxv YWQgZm9ybWF0IHNwZWNpZmljYXRpb24ncyB0ZXh0IG9uIHdoZW4gdG8gc2V0IHRoZSBSVFAgIk0i IGJpdA0KDQpJIHN1Z2dlc3QgcmVwbGFjaW5nICJUaGUgY29udGVudCBvZiBhIE5BTCB1bml0IiB3 aXRoICJUaGUgTkFMIHVuaXQgaGVhZGVyIi4gVGhlIGNvbnRlbnQgZG9lcyByZXZlYWwgZW5kIG9m IGFjY2VzcyB1bml0IGJvdW5kYXJpZXMgaWYgeW91J3JlIHdpbGxpbmcgdG8gcGFyc2UvZGVjb2Rl IGl0IGFsbC4NCg0KTW8NCg0KDQpPbiBBdWcgMjcsIDIwMTMsIGF0IDEyOjUxIEFNLCAiV2FuZywg WWUtS3VpIiA8eWVrdWl3QHF0aS5xdWFsY29tbS5jb208bWFpbHRvOnlla3Vpd0BxdGkucXVhbGNv bW0uY29tPj4gd3JvdGU6DQpIaSBSb3NzLA0KDQpTb3JyeSBmb3IgYSBzbG93IHJlc3BvbnNlLiBJ IHN0YXJ0ZWQgdG8gZWRpdCB0aGlzIGRyYWZ0IHRvZGF5LCBhbmQgaGF2ZSBpbmNsdWRlZCB0aGUg Zm9sbG93aW5nIG5vdGUgYWZ0ZXIgdGhlIHNlbWFudGljcyBvZiB0aGUgTSBiaXQ6DQoNCkluZm9y bWF0aXZlIG5vdGU6IFRoZSBjb250ZW50IG9mIGEgTkFMIHVuaXQgZG9lcyBub3QgdGVsbCB3aGV0 aGVyIG9yIG5vdCB0aGUgTkFMIHVuaXQgaXMgdGhlIGxhc3QgTkFMIHVuaXQsIGluIGRlY29kaW5n IG9yZGVyLCBvZiBhbiBhY2Nlc3MgdW5pdC4gIEFuIFJUUCBzZW5kZXIgaW1wbGVtZW50YXRpb24g bWF5IG9idGFpbiB0aGlzIGluZm9ybWF0aW9uIGZyb20gdGhlIHZpZGVvIGVuY29kZXIuICBJZiwg aG93ZXZlciwgdGhlIGltcGxlbWVudGF0aW9uIGNhbm5vdCBvYnRhaW4gdGhpcyBpbmZvcm1hdGlv biBkaXJlY3RseSBmcm9tIHRoZSBlbmNvZGVyLCBlLmcuLCB3aGVuIHRoZSBzdHJlYW0gd2FzIHBy ZS1lbmNvZGVkLCBhbmQgYWxzbyB0aGVyZSBpcyBubyB0aW1lc3RhbXAgYWxsb2NhdGVkIGZvciBl YWNoIE5BTCB1bml0LCB0aGVuIHRoZSBzZW5kZXIgaW1wbGVtZW50YXRpb24gY2FuIGluc3BlY3Qg c3Vic2VxdWVudCBOQUwgdW5pdHMgaW4gZGVjb2Rpbmcgb3JkZXIgdG8gZGV0ZXJtaW5lIHdoZXRo ZXIgb3Igbm90IHRoZSBOQUwgdW5pdCBpcyB0aGUgbGFzdCBOQUwgdW5pdCBvZiBhbiBhY2Nlc3Mg dW5pdCBhcyBmb2xsb3dzLiAgQSBOQUwgdW5pdCBuYWx1WCBpcyB0aGUgbGFzdCBOQUwgdW5pdCBv ZiBhbiBhY2Nlc3MgdW5pdCBpZiB0aGUgbmV4dCBWQ0wgTkFMIHVuaXQgbmFsdVkgaW4gZGVjb2Rp bmcgb3JkZXIgaGFzIHRoZSBoaWdoLW9yZGVyIGJpdCBvZiB0aGUgZmlyc3QgYnl0ZSBhZnRlciBp dHMgTkFMIHVuaXQgaGVhZGVyIGVxdWFsIHRvIDEsIGFuZCBhbGwgTkFMIHVuaXRzIGJldHdlZW4g bmFsdVggYW5kIG5hbHVZLCB3aGVuIHByZXNlbnQsIGhhdmUgbmFsX3VuaXRfdHlwZSBpbiB0aGUg cmFuZ2Ugb2YgMzIgdG8gMzUsIGluY2x1c2l2ZSwgZXF1YWwgdG8gMzksIGluIHRoZSByYW5nZSBv ZiA0MSB0byA0NCwgaW5jbHVzaXZlLCBvciBpbiB0aGUgcmFuZ2Ugb2YgNDggdG8gNTUsIGluY2x1 c2l2ZS4NCg0KV291bGQgeW91IGJlIGZpbmUgd2l0aCB0aGlzIHdvcmRpbmc/DQoNCkJSLCBZSw0K DQoNCkZyb206IGF2dC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzphdnQtYm91bmNlc0BpZXRmLm9y Zz4gW21haWx0bzphdnQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvc3MgRmlubGF5 c29uDQpTZW50OiBNb25kYXksIEF1Z3VzdCAxMiwgMjAxMyAxMjoyNSBQTQ0KVG86IGF2dEBpZXRm Lm9yZzxtYWlsdG86YXZ0QGlldGYub3JnPjsgcGF5bG9hZEBpZXRmLm9yZzxtYWlsdG86cGF5bG9h ZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gW3BheWxvYWRdIENsYXJpZnlpbmcg dGhlIEguMjY1IFJUUCBwYXlsb2FkIGZvcm1hdCBzcGVjaWZpY2F0aW9uJ3MgdGV4dCBvbiB3aGVu IHRvIHNldCB0aGUgUlRQICJNIiBiaXQNCg0KWW91IGp1c3QgbmVlZCBvbmUgbW9yZSBsaXR0bGUg c3RlcCB0byBnZXQgZXZlcnl0aGluZyByaWdodCBoZXJlLCBpbnN0ZWFkIG9mIHRoaW5raW5nIG9m IGNvbXByb21pc2luZyB0aGUgaW1wbGVtZW50YXRpb24g4pi6DQoNClRoYXQgaXMsIHJlYWQgc3Vi Y2xhdXNlIDcuNC4yLjQuNCBvZiB0aGUgSEVWQyBzcGVjLiBUaGUgbW9zdCByZWxldmFudCBwYXJh Z3JhcGhzIGFyZSBjb3BpZWQgYmVsb3cgZm9yIGNvbnZlbmllbmNlICh0aGUgZmlyc3QgcGFyYWdy YXBoIGl0c2VsZiBjb250YWlucyB0aGUgYW5zd2VyIHRvIHlvdXIgcXVlc3Rpb24sIGJ1dCB0aGUg c2Vjb25kIHBhcmFncmFwaCBtYXkgYWxzbyBwcm92aWRlIGhlbHBmdWwgaW5mb3JtYXRpb24pDQoN ClRoYW5rcyBmb3IgdGhlIGluZm87IHRoYXQgd2FzIHVzZWZ1bC4NCg0KSGVyZSwgdGhlbiBpcyB0 aGUgdXBkYXRlZCB0ZXh0IG9mIGEgcGFyYWdyYXBoIC0gdG8gYmUgYWRkZWQgYWZ0ZXIgdGhlIGV4 aXN0aW5nICdNIGJpdCcgdGV4dCAtIHRoYXQgY2xhcmlmaWVzIHdoZW4vaG93IHRvIHNldCBpdDoN Ci0tLS0tLS0tLS0NClVuZm9ydHVuYXRlbHkgdGhlIGNvbnRlbnRzIG9mIGEgTkFMIHVuaXQsIGFs b25lLCBkbyBub3QgdGVsbCBhIFJUUCBzZW5kZXIgaW1wbGVtZW50YXRpb24gd2hldGhlciBvciBu b3QgdGhlIE5BTCB1bml0IGVuZHMgYW4gYWNjZXNzIHVuaXQuICBJbnN0ZWFkLCB0aGUgaW1wbGVt ZW50YXRpb24gbWF5IGJlIGFibGUgdG8gb2J0YWluIHRoaXMgaW5mb3JtYXRpb24gc2VwYXJhdGVs eSwgZnJvbSB0aGUgZW5jb2Rlci4gIElmLCBob3dldmVyLCB0aGUgaW1wbGVtZW50YXRpb24gY2Fu bm90IG9idGFpbiB0aGlzIGluZm9ybWF0aW9uIGRpcmVjdGx5IGZyb20gdGhlIGVuY29kZXIgKGUu Zy4sIGJlY2F1c2UgdGhlIGltcGxlbWVudGF0aW9uIGlzIHNlbmRpbmcgZGF0YSB0aGF0IGNvbnNp c3RzIHNvbGVseSBvZiBhIHNlcXVlbmNlIG9mIHByZS1lbmNvZGVkIE5BTCB1bml0cyksIHRoZW4g aXQgbXVzdCBpbnN0ZWFkIGluc3BlY3Qgc3Vic2VxdWVudCBOQUwgdW5pdHMsIHRvIGRldGVybWlu ZSB3aGV0aGVyIG9yIG5vdCB0aGUgTkFMIHVuaXQgZW5kcyBhbiBhY2Nlc3MgdW5pdC4gIElmIHRo ZSBOQUwgdW5pdHMgaGF2ZSBhbHJlYWR5IGJlZW4gdGltZXN0YW1wZWQsIHRoZW4gdGhlc2UgdGlt ZXN0YW1wcyBjYW4gYmUgdXNlZCB0byBkZXRlcm1pbmUgdGhlIGFjY2VzcyB1bml0IGJvdW5kYXJp ZXMuICBPdGhlcndpc2UsIHRoZSBhY2Nlc3MgdW5pdCBib3VuZGFyaWVzIChhbmQgdGltZXMpIG11 c3QgYmUgZGV0ZXJtaW5lZCBieSBpbnNwZWN0aW5nIHRoZSBOQUwgdW5pdHMnIGNvbnRlbnRzIC0g c3BlY2lmaWNhbGx5LCB0aGUgIm5hbF91bml0X3R5cGUiIGFuZCAoZm9yIFZDTCBOQUwgdW5pdHMp IHRoZSAiZmlyc3Rfc2xpY2Vfc2VnbWVudF9pbl9waWNfZmxhZyIuICBUaGUgZm9sbG93aW5nIHJ1 bGUgY2FuIGJlIHVzZWQ6DQogICAgICAgICAgIEEgTkFMIHVuaXQgKFgpIGVuZHMgYW4gYWNjZXNz IHVuaXQgaWYgdGhlIG5leHQtb2NjdXJyaW5nIFZDTCBOQUwgdW5pdCAoWSkgaGFzIHRoZSBoaWdo LW9yZGVyIGJpdCBvZiB0aGUgZmlyc3QgYnl0ZSBhZnRlciBpdHMgTkFMIHVuaXQgaGVhZGVyIGVx dWFsIHRvIDEsIGFuZCBhbGwgTkFMIHVuaXRzLCBpZiBhbnksIGJldHdlZW4gKFgpIGFuZCAoWSkg aGF2ZSBhICJuYWxfdW5pdF90eXBlIiBpbiBvbmUgb2YgdGhlIGZvbGxvd2luZyByYW5nZXM6IFsz MiwzNV0sIDM5LCBbNDEsNDRdLCBvciBbNDgsNTVdLg0KLS0tLS0tLS0tLQ0KDQpSb3NzIEZpbmxh eXNvbg0KTGl2ZSBOZXR3b3JrcywgSW5jLg0KaHR0cDovL3d3dy5saXZlNTU1LmNvbS8NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkF1ZGlvL1ZpZGVv IFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQphdnRAaWV0Zi5vcmc8bWFpbHRvOmF2dEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo= --_000_8BA7D4CEACFFE04BA2D902BF11719A8338512D57nasanexd02fnaqu_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPGJhc2Ug aHJlZj0ieC1tc2c6Ly85NzEvIj48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQg MiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFu b3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNp bVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1j b252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30N CnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0K c3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLUNBIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTW8sPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZxdW90O1RoZSBjb250ZW50IG9mIGEgTkFMIHVuaXQmcXVvdDsgY2Fu IHRlbGwgd2hldGhlciB0aGUgTkFMIHVuaXQgaXMgdGhlIGxhc3Qgc2xpY2Ugb2YgYSBwaWN0dXJl LCBidXQgdGhlIGxhc3QgTkFMIHVuaXQgb2YgYW4gQVUgY2FuIGFsc28gYmUgYSBub24tVkNMIE5B TCB1bml0LiBDb25zaWRlcmluZyB0aGlzLCAmcXVvdDt0aGUgY29udGVudCBvZiBhIE5BTCB1bml0 JnF1b3Q7IGRvZXMgbm90IHRlbGwgd2hldGhlciBhIE5BTCB1bml0IGlzIHRoZQ0KIGxhc3QgTkFM IHVuaXQgb2YgYW4gQVUuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+QlIsIFlLPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTW8gWmFuYXR5IChtemFuYXR5KSBbbWFp bHRvOm16YW5hdHlAY2lzY28uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEF1Z3Vz dCAyNywgMjAxMyAzOjU4IFBNPGJyPg0KPGI+VG86PC9iPiBXYW5nLCBZZS1LdWk8YnI+DQo8Yj5D Yzo8L2I+IFJvc3MgRmlubGF5c29uOyBhdnRAaWV0Zi5vcmc7IHBheWxvYWRAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtBVlRDT1JFXSBbcGF5bG9hZF0gQ2xhcmlmeWluZyB0aGUg SC4yNjUgUlRQIHBheWxvYWQgZm9ybWF0IHNwZWNpZmljYXRpb24ncyB0ZXh0IG9uIHdoZW4gdG8g c2V0IHRoZSBSVFAgJnF1b3Q7TSZxdW90OyBiaXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzdWdnZXN0IHJlcGxhY2luZyAmcXVvdDtUaGUg Y29udGVudCBvZiBhIE5BTCB1bml0JnF1b3Q7IHdpdGggJnF1b3Q7VGhlIE5BTCB1bml0IGhlYWRl ciZxdW90Oy4gVGhlIGNvbnRlbnQgZG9lcyByZXZlYWwgZW5kIG9mIGFjY2VzcyB1bml0IGJvdW5k YXJpZXMgaWYgeW91J3JlIHdpbGxpbmcgdG8gcGFyc2UvZGVjb2RlIGl0IGFsbC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TW88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KT24gQXVnIDI3LCAyMDEzLCBhdCAxMjo1MSBBTSwg JnF1b3Q7V2FuZywgWWUtS3VpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86eWVrdWl3QHF0aS5x dWFsY29tbS5jb20iPnlla3Vpd0BxdGkucXVhbGNvbW0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgUm9zcyw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvcnJ5 IGZvciBhIHNsb3cgcmVzcG9uc2UuIEkgc3RhcnRlZCB0byBlZGl0IHRoaXMgZHJhZnQgdG9kYXks IGFuZCBoYXZlIGluY2x1ZGVkIHRoZSBmb2xsb3dpbmcgbm90ZSBhZnRlciB0aGUgc2VtYW50aWNz IG9mIHRoZSBNIGJpdDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi45aW4iPkluZm9ybWF0aXZlIG5vdGU6IFRoZSBjb250ZW50IG9mIGEgTkFMIHVuaXQgZG9lcyBu b3QgdGVsbCB3aGV0aGVyIG9yIG5vdCB0aGUgTkFMIHVuaXQgaXMgdGhlIGxhc3QgTkFMIHVuaXQs IGluIGRlY29kaW5nIG9yZGVyLCBvZiBhbiBhY2Nlc3MgdW5pdC4mbmJzcDsgQW4gUlRQIHNlbmRl ciBpbXBsZW1lbnRhdGlvbiBtYXkgb2J0YWluIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB0aGUNCiB2 aWRlbyBlbmNvZGVyLiZuYnNwOyBJZiwgaG93ZXZlciwgdGhlIGltcGxlbWVudGF0aW9uIGNhbm5v dCBvYnRhaW4gdGhpcyBpbmZvcm1hdGlvbiBkaXJlY3RseSBmcm9tIHRoZSBlbmNvZGVyLCBlLmcu LCB3aGVuIHRoZSBzdHJlYW0gd2FzIHByZS1lbmNvZGVkLCBhbmQgYWxzbyB0aGVyZSBpcyBubyB0 aW1lc3RhbXAgYWxsb2NhdGVkIGZvciBlYWNoIE5BTCB1bml0LCB0aGVuIHRoZSBzZW5kZXIgaW1w bGVtZW50YXRpb24gY2FuIGluc3BlY3Qgc3Vic2VxdWVudA0KIE5BTCB1bml0cyBpbiBkZWNvZGlu ZyBvcmRlciB0byBkZXRlcm1pbmUgd2hldGhlciBvciBub3QgdGhlIE5BTCB1bml0IGlzIHRoZSBs YXN0IE5BTCB1bml0IG9mIGFuIGFjY2VzcyB1bml0IGFzIGZvbGxvd3MuJm5ic3A7IEEgTkFMIHVu aXQgbmFsdVggaXMgdGhlIGxhc3QgTkFMIHVuaXQgb2YgYW4gYWNjZXNzIHVuaXQgaWYgdGhlIG5l eHQgVkNMIE5BTCB1bml0IG5hbHVZIGluIGRlY29kaW5nIG9yZGVyIGhhcyB0aGUgaGlnaC1vcmRl ciBiaXQgb2YgdGhlDQogZmlyc3QgYnl0ZSBhZnRlciBpdHMgTkFMIHVuaXQgaGVhZGVyIGVxdWFs IHRvIDEsIGFuZCBhbGwgTkFMIHVuaXRzIGJldHdlZW4gbmFsdVggYW5kIG5hbHVZLCB3aGVuIHBy ZXNlbnQsIGhhdmUgbmFsX3VuaXRfdHlwZSBpbiB0aGUgcmFuZ2Ugb2YgMzIgdG8gMzUsIGluY2x1 c2l2ZSwgZXF1YWwgdG8gMzksIGluIHRoZSByYW5nZSBvZiA0MSB0byA0NCwgaW5jbHVzaXZlLCBv ciBpbiB0aGUgcmFuZ2Ugb2YgNDggdG8gNTUsIGluY2x1c2l2ZS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V291bGQgeW91IGJlIGZp bmUgd2l0aCB0aGlzIHdvcmRpbmc/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CUiwgWUs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzphdnQtYm91 bmNlc0BpZXRmLm9yZyI+YXZ0LWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFs8YSBocmVmPSJtYWlsdG86 YXZ0LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzphdnQtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPlJvc3MgRmlubGF5c29uPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRh eSwgQXVndXN0IDEyLCAyMDEzIDEyOjI1IFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWls dG86YXZ0QGlldGYub3JnIj5hdnRAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86cGF5bG9h ZEBpZXRmLm9yZyI+DQpwYXlsb2FkQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW0FWVENPUkVdIFtwYXlsb2FkXSBDbGFyaWZ5aW5nIHRoZSBILjI2NSBSVFAgcGF5bG9hZCBm b3JtYXQgc3BlY2lmaWNhdGlvbidzIHRleHQgb24gd2hlbiB0byBzZXQgdGhlIFJUUCAmcXVvdDtN JnF1b3Q7IGJpdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPllvdSBqdXN0IG5lZWQgb25lIG1vcmUgbGl0dGxlIHN0ZXAgdG8gZ2V0IGV2ZXJ5 dGhpbmcgcmlnaHQgaGVyZSwgaW5zdGVhZCBvZiB0aGlua2luZyBvZiBjb21wcm9taXNpbmcgdGhl IGltcGxlbWVudGF0aW9uPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpX aW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+Sjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+VGhhdCBpcywgcmVhZCBzdWJjbGF1c2UgNy40LjIuNC40IG9mIHRoZSBIRVZDIHNw ZWMuIFRoZSBtb3N0IHJlbGV2YW50IHBhcmFncmFwaHMgYXJlIGNvcGllZCBiZWxvdyBmb3IgY29u dmVuaWVuY2UgKHRoZSBmaXJzdCBwYXJhZ3JhcGggaXRzZWxmIGNvbnRhaW5zIHRoZSBhbnN3ZXIN CiB0byB5b3VyIHF1ZXN0aW9uLCBidXQgdGhlIHNlY29uZCBwYXJhZ3JhcGggbWF5IGFsc28gcHJv dmlkZSBoZWxwZnVsIGluZm9ybWF0aW9uKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3Ig dGhlIGluZm87IHRoYXQgd2FzIHVzZWZ1bC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVyZSwgdGhlbiBpcyB0aGUgdXBkYXRlZCB0ZXh0IG9m IGEgcGFyYWdyYXBoIC0gdG8gYmUgYWRkZWQgYWZ0ZXIgdGhlIGV4aXN0aW5nICdNIGJpdCcgdGV4 dCAtIHRoYXQgY2xhcmlmaWVzIHdoZW4vaG93IHRvIHNldCBpdDo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLS0tLS0tPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5VbmZvcnR1bmF0 ZWx5IHRoZSBjb250ZW50cyBvZiBhIE5BTCB1bml0LCBhbG9uZSwgZG8gbm90IHRlbGwgYSBSVFAg c2VuZGVyIGltcGxlbWVudGF0aW9uIHdoZXRoZXIgb3Igbm90IHRoZSBOQUwgdW5pdCBlbmRzIGFu IGFjY2VzcyB1bml0LiAmbmJzcDtJbnN0ZWFkLCB0aGUgaW1wbGVtZW50YXRpb24gbWF5IGJlIGFi bGUgdG8gb2J0YWluIHRoaXMgaW5mb3JtYXRpb24gc2VwYXJhdGVseSwgZnJvbSB0aGUgZW5jb2Rl ci4NCiAmbmJzcDtJZiwgaG93ZXZlciwgdGhlIGltcGxlbWVudGF0aW9uIGNhbm5vdCBvYnRhaW4g dGhpcyBpbmZvcm1hdGlvbiBkaXJlY3RseSBmcm9tIHRoZSBlbmNvZGVyIChlLmcuLCBiZWNhdXNl IHRoZSBpbXBsZW1lbnRhdGlvbiBpcyBzZW5kaW5nIGRhdGEgdGhhdCBjb25zaXN0cyBzb2xlbHkg b2YgYSBzZXF1ZW5jZSBvZiBwcmUtZW5jb2RlZCBOQUwgdW5pdHMpLCB0aGVuIGl0IG11c3QgaW5z dGVhZCBpbnNwZWN0IHN1YnNlcXVlbnQgTkFMIHVuaXRzLCB0bw0KIGRldGVybWluZSB3aGV0aGVy IG9yIG5vdCB0aGUgTkFMIHVuaXQgZW5kcyBhbiBhY2Nlc3MgdW5pdC4gJm5ic3A7SWYgdGhlIE5B TCB1bml0cyBoYXZlIGFscmVhZHkgYmVlbiB0aW1lc3RhbXBlZCwgdGhlbiB0aGVzZSB0aW1lc3Rh bXBzIGNhbiBiZSB1c2VkIHRvIGRldGVybWluZSB0aGUgYWNjZXNzIHVuaXQgYm91bmRhcmllcy4g Jm5ic3A7T3RoZXJ3aXNlLCB0aGUgYWNjZXNzIHVuaXQgYm91bmRhcmllcyAoYW5kIHRpbWVzKSBt dXN0IGJlIGRldGVybWluZWQgYnkNCiBpbnNwZWN0aW5nIHRoZSBOQUwgdW5pdHMnIGNvbnRlbnRz IC0gc3BlY2lmaWNhbGx5LCB0aGUgJnF1b3Q7bmFsX3VuaXRfdHlwZSZxdW90OyBhbmQgKGZvciBW Q0wgTkFMIHVuaXRzKSB0aGUgJnF1b3Q7Zmlyc3Rfc2xpY2Vfc2VnbWVudF9pbl9waWNfZmxhZyZx dW90Oy4gJm5ic3A7VGhlIGZvbGxvd2luZyBydWxlIGNhbiBiZSB1c2VkOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxl LXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPC9zcGFuPiZuYnNwO0EgTkFMIHVuaXQgKFgpIGVuZHMgYW4gYWNjZXNzIHVuaXQg aWYgdGhlIG5leHQtb2NjdXJyaW5nIFZDTCBOQUwgdW5pdCAoWSkgaGFzIHRoZSBoaWdoLW9yZGVy IGJpdCBvZiB0aGUgZmlyc3QgYnl0ZSBhZnRlciBpdHMgTkFMIHVuaXQgaGVhZGVyIGVxdWFsIHRv IDEsIGFuZCBhbGwgTkFMIHVuaXRzLCBpZiBhbnksIGJldHdlZW4gKFgpDQogYW5kIChZKSBoYXZl IGEgJnF1b3Q7bmFsX3VuaXRfdHlwZSZxdW90OyBpbiBvbmUgb2YgdGhlIGZvbGxvd2luZyByYW5n ZXM6IFszMiwzNV0sIDM5LCBbNDEsNDRdLCBvciBbNDgsNTVdLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNs YXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+Um9zcyBGaW5sYXlzb248L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3Bh biI+TGl2ZSBOZXR3b3JrcywgSW5jLjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtc3R5 bGUtc3BhbiI+PGEgaHJlZj0iaHR0cDovL3d3dy5saXZlNTU1LmNvbS8iPmh0dHA6Ly93d3cubGl2 ZTU1NS5jb20vPC9hPjwvc3Bhbj48L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRl bmFuY2U8YnI+DQo8YSBocmVmPSJtYWlsdG86YXZ0QGlldGYub3JnIj5hdnRAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0PC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8BA7D4CEACFFE04BA2D902BF11719A8338512D57nasanexd02fnaqu_-- From mzanaty@cisco.com Tue Aug 27 21:21:43 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243F211E813B; Tue, 27 Aug 2013 21:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4oLpoizbwPd; Tue, 27 Aug 2013 21:21:38 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 17EFB11E812C; Tue, 27 Aug 2013 21:21:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32896; q=dns/txt; s=iport; t=1377663698; x=1378873298; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0DTLTwwtyMh8+N900nzjQRS0MxVOk8jF5vZnfoY9sFE=; b=CbhKaasXQ2X0Svjwz5tlDYvZrxYIPLpCY/3xmLMabdcPuMLhvN/Oddko QMJJME4bOxUHnsyvXPiByekd0rfmJFSCYQ1yFkkz+zVpEmTf1TeLad9Uc xWltUA1tPxSUT2MDHVy1W60fs72rmi7lptcFEaoZQNz5K86+T5BdLk+OL 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogFAAF6HVKtJXHB/2dsb2JhbABagkNENVGDJ7t1AYEMF4EOFnSCJAEBAQQBAQEgCkwQAgEIEQQBAQsWAwQDAgICJQsUCQgCBA4FCId5DKYvkkSPMxYXBAYBCYJfNH0DlBWVOoFjgT2CKg X-IronPort-AV: E=Sophos;i="4.89,973,1367971200"; d="scan'208,217";a="249463183" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 28 Aug 2013 04:21:37 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7S4LbY8013384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Aug 2013 04:21:37 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.38]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Tue, 27 Aug 2013 23:21:36 -0500 From: "Mo Zanaty (mzanaty)" To: "Wang, Ye-Kui" Thread-Topic: [AVTCORE] [payload] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit Thread-Index: AQHOo3jjnEEyNQElLUmyU/ypjzM8DZmqKt0A///IteA= Date: Wed, 28 Aug 2013 04:21:36 +0000 Message-ID: <3879D71E758A7E4AA99A35DD8D41D3D91D50A36A@xmb-rcd-x14.cisco.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> <69F25DB2-6926-4ACA-935D-90376A2A7BFA@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D690F@nasanexd02f.na.qualcomm.com> <3879D71E758A7E4AA99A35DD8D41D3D91D4CC65C@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4@nasanexd02f.na.qualcomm.com> <8BA7D4CEACFFE04BA2D902BF11719A83385120E1@nasanexd02f.na.qualcomm.com> <75CC2B0E-28F2-452C-9CE5-060DB8DFEE6B@cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338512D57@nasanexd02f.na.qualcomm.com> In-Reply-To: <8BA7D4CEACFFE04BA2D902BF11719A8338512D57@nasanexd02f.na.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.235.29] Content-Type: multipart/alternative; boundary="_000_3879D71E758A7E4AA99A35DD8D41D3D91D50A36Axmbrcdx14ciscoc_" MIME-Version: 1.0 Cc: "avt@ietf.org" , "payload@ietf.org" Subject: Re: [payload] [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 04:21:43 -0000 --_000_3879D71E758A7E4AA99A35DD8D41D3D91D50A36Axmbrcdx14ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWUssDQoNCkdvb2QgcG9pbnQgb24gdHJhaWxpbmcgbm9uLVZDTCBOQUwgdW5pdHMuDQoNClRo YXQgYnJpbmdzIHVwIGFub3RoZXIgcG9pbnQgb24gbm9uLVZDTCBOQUwgdW5pdHMuIEkgYXNzdW1l IHRoZSBub24tVkNMIE5BTCB1bml0cyBkZWZpbmVkIGluIHRoaXMgZHJhZnQgKEFQL0ZVKSBjYW7i gJl0IGFwcGVhciBpbiB0aGUgYml0c3RyZWFtIHByb2Nlc3NlZCBieSB0aGUgUlRQIHNlbmRlciB1 c2luZyB0aGlzIGluZm9ybWF0aXZlIG5vdGUuIFRoYXQgaXMsIHRoZSBSVFAgc2VuZGVyIG11c3Qg YmUgcHJvY2Vzc2luZyBhbiBlbGVtZW50YXJ5IHN0cmVhbSB0aGF0IG9ubHkgY29udGFpbnMgTkFM IHVuaXRzIHNwZWNpZmllZCBpbiB0aGUgSC4yNjUgc3RhbmRhcmQgaXRzZWxmIFswLTQ3XSwgYW5k IGNhbuKAmXQgYmUgcHJvY2Vzc2luZyBhIGJpdHN0cmVhbSB0aGF0IGNhbWUgZnJvbSBhbm90aGVy IFJUUCBzZW5kZXIgd2hpY2ggbWF5IGhhdmUgaW5zZXJ0ZWQgdW5zcGVjaWZpZWQgTkFMIHVuaXRz IFs0OC02M10gbGlrZSBBUC9GVSwgc2luY2UgdGhhdCBjb3VsZCB5aWVsZCBpbXByb3BlciByZXN1 bHRzIGZvciB0aGlzIG5vdGUuDQoNCk9yIGRvIHdlIGFjdHVhbGx5IG5lZWQgdG8gc3BsaXQgQVAg YW5kIEZVIGVhY2ggaW50byB0d28gbm9uLVZDTCB1bml0cywgb25lIGluIHRoZSBsZWFkaW5nIG5v bi1WQ0wgcmFuZ2UgWzQ4LTU1XSBhbmQgYW5vdGhlciBpbiB0aGUgdHJhaWxpbmcgbm9uLVZDTCBy YW5nZSBbNTYtNjNdPyBJIHdvdWxkIGxpa2UgdG8gYXZvaWQgdGhhdCBjb21wbGV4aXR5LCBidXQg dGhhdCBzZWVtcyB0byBiZSB3aGF0IHRoZSBydWxlcyBpbiBILjI2NSA3LjQuMi40LjQgcmVxdWly ZSB3aGVuIHVzaW5nIHRoZSB1bnNwZWNpZmllZCByYW5nZSBbNDgtNjNdLiBEbyB5b3UgcmVjYWxs IHRoZSBtb3RpdmF0aW9uIGZvciBydWxlcyBvbiBzdWJyYW5nZXMgb2YgdGhlIHVuc3BlY2lmaWVk IHJhbmdlPw0KDQpBbHNvLCBpdCBtYXkgYmUgdXNlZnVsIHRvIGluZGljYXRlIGluIHRoZSBpbmZv cm1hdGl2ZSBub3RlIGhvdyB0byBkaWZmZXJlbnRpYXRlIFZDTCBOQUwgdW5pdHMgWzAtMzFdIGZy b20gbm9uLVZDTCBOQUwgdW5pdHMgWzMyLTYzXSwgaS5lLiB0aGUgTVNCIG9mIHRoZSA2LWJpdCBO QUwgdW5pdCB0eXBlIGlzIDEgaW4gbm9uLVZDTCBOQUwgdW5pdHMuDQoNClJlZ2FyZHMsDQpNbw0K DQoNCkZyb206IFdhbmcsIFllLUt1aSBbbWFpbHRvOnlla3Vpd0BxdGkucXVhbGNvbW0uY29tXQ0K U2VudDogVHVlc2RheSwgQXVndXN0IDI3LCAyMDEzIDk6MzYgUE0NClRvOiBNbyBaYW5hdHkgKG16 YW5hdHkpDQpDYzogUm9zcyBGaW5sYXlzb247IGF2dEBpZXRmLm9yZzsgcGF5bG9hZEBpZXRmLm9y Zw0KU3ViamVjdDogUkU6IFtBVlRDT1JFXSBbcGF5bG9hZF0gQ2xhcmlmeWluZyB0aGUgSC4yNjUg UlRQIHBheWxvYWQgZm9ybWF0IHNwZWNpZmljYXRpb24ncyB0ZXh0IG9uIHdoZW4gdG8gc2V0IHRo ZSBSVFAgIk0iIGJpdA0KDQpIaSBNbywNCg0KIlRoZSBjb250ZW50IG9mIGEgTkFMIHVuaXQiIGNh biB0ZWxsIHdoZXRoZXIgdGhlIE5BTCB1bml0IGlzIHRoZSBsYXN0IHNsaWNlIG9mIGEgcGljdHVy ZSwgYnV0IHRoZSBsYXN0IE5BTCB1bml0IG9mIGFuIEFVIGNhbiBhbHNvIGJlIGEgbm9uLVZDTCBO QUwgdW5pdC4gQ29uc2lkZXJpbmcgdGhpcywgInRoZSBjb250ZW50IG9mIGEgTkFMIHVuaXQiIGRv ZXMgbm90IHRlbGwgd2hldGhlciBhIE5BTCB1bml0IGlzIHRoZSBsYXN0IE5BTCB1bml0IG9mIGFu IEFVLg0KDQpCUiwgWUsNCg0KRnJvbTogTW8gWmFuYXR5IChtemFuYXR5KSBbbWFpbHRvOm16YW5h dHlAY2lzY28uY29tXQ0KU2VudDogVHVlc2RheSwgQXVndXN0IDI3LCAyMDEzIDM6NTggUE0NClRv OiBXYW5nLCBZZS1LdWkNCkNjOiBSb3NzIEZpbmxheXNvbjsgYXZ0QGlldGYub3JnOyBwYXlsb2Fk QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0FWVENPUkVdIFtwYXlsb2FkXSBDbGFyaWZ5aW5nIHRo ZSBILjI2NSBSVFAgcGF5bG9hZCBmb3JtYXQgc3BlY2lmaWNhdGlvbidzIHRleHQgb24gd2hlbiB0 byBzZXQgdGhlIFJUUCAiTSIgYml0DQoNCkkgc3VnZ2VzdCByZXBsYWNpbmcgIlRoZSBjb250ZW50 IG9mIGEgTkFMIHVuaXQiIHdpdGggIlRoZSBOQUwgdW5pdCBoZWFkZXIiLiBUaGUgY29udGVudCBk b2VzIHJldmVhbCBlbmQgb2YgYWNjZXNzIHVuaXQgYm91bmRhcmllcyBpZiB5b3UncmUgd2lsbGlu ZyB0byBwYXJzZS9kZWNvZGUgaXQgYWxsLg0KDQpNbw0KDQoNCk9uIEF1ZyAyNywgMjAxMywgYXQg MTI6NTEgQU0sICJXYW5nLCBZZS1LdWkiIDx5ZWt1aXdAcXRpLnF1YWxjb21tLmNvbTxtYWlsdG86 eWVrdWl3QHF0aS5xdWFsY29tbS5jb20+PiB3cm90ZToNCkhpIFJvc3MsDQoNClNvcnJ5IGZvciBh IHNsb3cgcmVzcG9uc2UuIEkgc3RhcnRlZCB0byBlZGl0IHRoaXMgZHJhZnQgdG9kYXksIGFuZCBo YXZlIGluY2x1ZGVkIHRoZSBmb2xsb3dpbmcgbm90ZSBhZnRlciB0aGUgc2VtYW50aWNzIG9mIHRo ZSBNIGJpdDoNCg0KSW5mb3JtYXRpdmUgbm90ZTogVGhlIGNvbnRlbnQgb2YgYSBOQUwgdW5pdCBk b2VzIG5vdCB0ZWxsIHdoZXRoZXIgb3Igbm90IHRoZSBOQUwgdW5pdCBpcyB0aGUgbGFzdCBOQUwg dW5pdCwgaW4gZGVjb2Rpbmcgb3JkZXIsIG9mIGFuIGFjY2VzcyB1bml0LiAgQW4gUlRQIHNlbmRl ciBpbXBsZW1lbnRhdGlvbiBtYXkgb2J0YWluIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB0aGUgdmlk ZW8gZW5jb2Rlci4gIElmLCBob3dldmVyLCB0aGUgaW1wbGVtZW50YXRpb24gY2Fubm90IG9idGFp biB0aGlzIGluZm9ybWF0aW9uIGRpcmVjdGx5IGZyb20gdGhlIGVuY29kZXIsIGUuZy4sIHdoZW4g dGhlIHN0cmVhbSB3YXMgcHJlLWVuY29kZWQsIGFuZCBhbHNvIHRoZXJlIGlzIG5vIHRpbWVzdGFt cCBhbGxvY2F0ZWQgZm9yIGVhY2ggTkFMIHVuaXQsIHRoZW4gdGhlIHNlbmRlciBpbXBsZW1lbnRh dGlvbiBjYW4gaW5zcGVjdCBzdWJzZXF1ZW50IE5BTCB1bml0cyBpbiBkZWNvZGluZyBvcmRlciB0 byBkZXRlcm1pbmUgd2hldGhlciBvciBub3QgdGhlIE5BTCB1bml0IGlzIHRoZSBsYXN0IE5BTCB1 bml0IG9mIGFuIGFjY2VzcyB1bml0IGFzIGZvbGxvd3MuICBBIE5BTCB1bml0IG5hbHVYIGlzIHRo ZSBsYXN0IE5BTCB1bml0IG9mIGFuIGFjY2VzcyB1bml0IGlmIHRoZSBuZXh0IFZDTCBOQUwgdW5p dCBuYWx1WSBpbiBkZWNvZGluZyBvcmRlciBoYXMgdGhlIGhpZ2gtb3JkZXIgYml0IG9mIHRoZSBm aXJzdCBieXRlIGFmdGVyIGl0cyBOQUwgdW5pdCBoZWFkZXIgZXF1YWwgdG8gMSwgYW5kIGFsbCBO QUwgdW5pdHMgYmV0d2VlbiBuYWx1WCBhbmQgbmFsdVksIHdoZW4gcHJlc2VudCwgaGF2ZSBuYWxf dW5pdF90eXBlIGluIHRoZSByYW5nZSBvZiAzMiB0byAzNSwgaW5jbHVzaXZlLCBlcXVhbCB0byAz OSwgaW4gdGhlIHJhbmdlIG9mIDQxIHRvIDQ0LCBpbmNsdXNpdmUsIG9yIGluIHRoZSByYW5nZSBv ZiA0OCB0byA1NSwgaW5jbHVzaXZlLg0KDQpXb3VsZCB5b3UgYmUgZmluZSB3aXRoIHRoaXMgd29y ZGluZz8NCg0KQlIsIFlLDQoNCg0KRnJvbTogYXZ0LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmF2 dC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmF2dC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgUm9zcyBGaW5sYXlzb24NClNlbnQ6IE1vbmRheSwgQXVndXN0IDEyLCAyMDEzIDEyOjI1 IFBNDQpUbzogYXZ0QGlldGYub3JnPG1haWx0bzphdnRAaWV0Zi5vcmc+OyBwYXlsb2FkQGlldGYu b3JnPG1haWx0bzpwYXlsb2FkQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtBVlRDT1JFXSBbcGF5 bG9hZF0gQ2xhcmlmeWluZyB0aGUgSC4yNjUgUlRQIHBheWxvYWQgZm9ybWF0IHNwZWNpZmljYXRp b24ncyB0ZXh0IG9uIHdoZW4gdG8gc2V0IHRoZSBSVFAgIk0iIGJpdA0KDQpZb3UganVzdCBuZWVk IG9uZSBtb3JlIGxpdHRsZSBzdGVwIHRvIGdldCBldmVyeXRoaW5nIHJpZ2h0IGhlcmUsIGluc3Rl YWQgb2YgdGhpbmtpbmcgb2YgY29tcHJvbWlzaW5nIHRoZSBpbXBsZW1lbnRhdGlvbiDimLoNCg0K VGhhdCBpcywgcmVhZCBzdWJjbGF1c2UgNy40LjIuNC40IG9mIHRoZSBIRVZDIHNwZWMuIFRoZSBt b3N0IHJlbGV2YW50IHBhcmFncmFwaHMgYXJlIGNvcGllZCBiZWxvdyBmb3IgY29udmVuaWVuY2Ug KHRoZSBmaXJzdCBwYXJhZ3JhcGggaXRzZWxmIGNvbnRhaW5zIHRoZSBhbnN3ZXIgdG8geW91ciBx dWVzdGlvbiwgYnV0IHRoZSBzZWNvbmQgcGFyYWdyYXBoIG1heSBhbHNvIHByb3ZpZGUgaGVscGZ1 bCBpbmZvcm1hdGlvbikNCg0KVGhhbmtzIGZvciB0aGUgaW5mbzsgdGhhdCB3YXMgdXNlZnVsLg0K DQpIZXJlLCB0aGVuIGlzIHRoZSB1cGRhdGVkIHRleHQgb2YgYSBwYXJhZ3JhcGggLSB0byBiZSBh ZGRlZCBhZnRlciB0aGUgZXhpc3RpbmcgJ00gYml0JyB0ZXh0IC0gdGhhdCBjbGFyaWZpZXMgd2hl bi9ob3cgdG8gc2V0IGl0Og0KLS0tLS0tLS0tLQ0KVW5mb3J0dW5hdGVseSB0aGUgY29udGVudHMg b2YgYSBOQUwgdW5pdCwgYWxvbmUsIGRvIG5vdCB0ZWxsIGEgUlRQIHNlbmRlciBpbXBsZW1lbnRh dGlvbiB3aGV0aGVyIG9yIG5vdCB0aGUgTkFMIHVuaXQgZW5kcyBhbiBhY2Nlc3MgdW5pdC4gIElu c3RlYWQsIHRoZSBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgYWJsZSB0byBvYnRhaW4gdGhpcyBpbmZv cm1hdGlvbiBzZXBhcmF0ZWx5LCBmcm9tIHRoZSBlbmNvZGVyLiAgSWYsIGhvd2V2ZXIsIHRoZSBp bXBsZW1lbnRhdGlvbiBjYW5ub3Qgb2J0YWluIHRoaXMgaW5mb3JtYXRpb24gZGlyZWN0bHkgZnJv bSB0aGUgZW5jb2RlciAoZS5nLiwgYmVjYXVzZSB0aGUgaW1wbGVtZW50YXRpb24gaXMgc2VuZGlu ZyBkYXRhIHRoYXQgY29uc2lzdHMgc29sZWx5IG9mIGEgc2VxdWVuY2Ugb2YgcHJlLWVuY29kZWQg TkFMIHVuaXRzKSwgdGhlbiBpdCBtdXN0IGluc3RlYWQgaW5zcGVjdCBzdWJzZXF1ZW50IE5BTCB1 bml0cywgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IHRoZSBOQUwgdW5pdCBlbmRzIGFuIGFj Y2VzcyB1bml0LiAgSWYgdGhlIE5BTCB1bml0cyBoYXZlIGFscmVhZHkgYmVlbiB0aW1lc3RhbXBl ZCwgdGhlbiB0aGVzZSB0aW1lc3RhbXBzIGNhbiBiZSB1c2VkIHRvIGRldGVybWluZSB0aGUgYWNj ZXNzIHVuaXQgYm91bmRhcmllcy4gIE90aGVyd2lzZSwgdGhlIGFjY2VzcyB1bml0IGJvdW5kYXJp ZXMgKGFuZCB0aW1lcykgbXVzdCBiZSBkZXRlcm1pbmVkIGJ5IGluc3BlY3RpbmcgdGhlIE5BTCB1 bml0cycgY29udGVudHMgLSBzcGVjaWZpY2FsbHksIHRoZSAibmFsX3VuaXRfdHlwZSIgYW5kIChm b3IgVkNMIE5BTCB1bml0cykgdGhlICJmaXJzdF9zbGljZV9zZWdtZW50X2luX3BpY19mbGFnIi4g IFRoZSBmb2xsb3dpbmcgcnVsZSBjYW4gYmUgdXNlZDoNCiAgICAgICAgICAgQSBOQUwgdW5pdCAo WCkgZW5kcyBhbiBhY2Nlc3MgdW5pdCBpZiB0aGUgbmV4dC1vY2N1cnJpbmcgVkNMIE5BTCB1bml0 IChZKSBoYXMgdGhlIGhpZ2gtb3JkZXIgYml0IG9mIHRoZSBmaXJzdCBieXRlIGFmdGVyIGl0cyBO QUwgdW5pdCBoZWFkZXIgZXF1YWwgdG8gMSwgYW5kIGFsbCBOQUwgdW5pdHMsIGlmIGFueSwgYmV0 d2VlbiAoWCkgYW5kIChZKSBoYXZlIGEgIm5hbF91bml0X3R5cGUiIGluIG9uZSBvZiB0aGUgZm9s bG93aW5nIHJhbmdlczogWzMyLDM1XSwgMzksIFs0MSw0NF0sIG9yIFs0OCw1NV0uDQotLS0tLS0t LS0tDQoNClJvc3MgRmlubGF5c29uDQpMaXZlIE5ldHdvcmtzLCBJbmMuDQpodHRwOi8vd3d3Lmxp dmU1NTUuY29tLw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCmF2dEBpZXRmLm9y ZzxtYWlsdG86YXZ0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hdnQNCg== --_000_3879D71E758A7E4AA99A35DD8D41D3D91D50A36Axmbrcdx14ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPGJhc2Ug aHJlZj0ieC1tc2c6Ly85NzEvIj48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQg MiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFu b3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Oldp bmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUg NCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRl LCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBs ZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5hcHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFt ZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5h bWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGkg WUssPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkdvb2QgcG9pbnQgb24g dHJhaWxpbmcgbm9uLVZDTCBOQUwgdW5pdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPlRoYXQgYnJpbmdzIHVwIGFub3RoZXIgcG9pbnQgb24gbm9uLVZDTCBOQUwgdW5p dHMuIEkgYXNzdW1lIHRoZSBub24tVkNMIE5BTCB1bml0cyBkZWZpbmVkIGluIHRoaXMgZHJhZnQg KEFQL0ZVKSBjYW7igJl0IGFwcGVhciBpbiB0aGUgYml0c3RyZWFtIHByb2Nlc3NlZCBieSB0aGUg UlRQIHNlbmRlcg0KIHVzaW5nIHRoaXMgaW5mb3JtYXRpdmUgbm90ZS4gVGhhdCBpcywgdGhlIFJU UCBzZW5kZXIgbXVzdCBiZSBwcm9jZXNzaW5nIGFuIGVsZW1lbnRhcnkgc3RyZWFtIHRoYXQgb25s eSBjb250YWlucyBOQUwgdW5pdHMgc3BlY2lmaWVkIGluIHRoZSBILjI2NSBzdGFuZGFyZCBpdHNl bGYgWzAtNDddLCBhbmQgY2Fu4oCZdCBiZSBwcm9jZXNzaW5nIGEgYml0c3RyZWFtIHRoYXQgY2Ft ZSBmcm9tIGFub3RoZXIgUlRQIHNlbmRlciB3aGljaCBtYXkgaGF2ZSBpbnNlcnRlZA0KIHVuc3Bl Y2lmaWVkIE5BTCB1bml0cyBbNDgtNjNdIGxpa2UgQVAvRlUsIHNpbmNlIHRoYXQgY291bGQgeWll bGQgaW1wcm9wZXIgcmVzdWx0cyBmb3IgdGhpcyBub3RlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5PciBkbyB3ZSBhY3R1YWxseSBuZWVkIHRvIHNwbGl0IEFQIGFuZCBG VSBlYWNoIGludG8gdHdvIG5vbi1WQ0wgdW5pdHMsIG9uZSBpbiB0aGUgbGVhZGluZyBub24tVkNM IHJhbmdlIFs0OC01NV0gYW5kIGFub3RoZXIgaW4gdGhlIHRyYWlsaW5nIG5vbi1WQ0wgcmFuZ2Ug WzU2LTYzXT8gSSB3b3VsZA0KIGxpa2UgdG8gYXZvaWQgdGhhdCBjb21wbGV4aXR5LCBidXQgdGhh dCBzZWVtcyB0byBiZSB3aGF0IHRoZSBydWxlcyBpbiBILjI2NSA3LjQuMi40LjQgcmVxdWlyZSB3 aGVuIHVzaW5nIHRoZSB1bnNwZWNpZmllZCByYW5nZSBbNDgtNjNdLiBEbyB5b3UgcmVjYWxsIHRo ZSBtb3RpdmF0aW9uIGZvciBydWxlcyBvbiBzdWJyYW5nZXMgb2YgdGhlIHVuc3BlY2lmaWVkIHJh bmdlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BbHNvLCBpdCBtYXkg YmUgdXNlZnVsIHRvIGluZGljYXRlIGluIHRoZSBpbmZvcm1hdGl2ZSBub3RlIGhvdyB0byBkaWZm ZXJlbnRpYXRlIFZDTCBOQUwgdW5pdHMgWzAtMzFdIGZyb20gbm9uLVZDTCBOQUwgdW5pdHMgWzMy LTYzXSwgaS5lLiB0aGUgTVNCIG9mIHRoZSA2LWJpdCBOQUwgdW5pdCB0eXBlDQogaXMgMSBpbiBu b24tVkNMIE5BTCB1bml0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk1vPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g V2FuZywgWWUtS3VpIFttYWlsdG86eWVrdWl3QHF0aS5xdWFsY29tbS5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gVHVlc2RheSwgQXVndXN0IDI3LCAyMDEzIDk6MzYgUE08YnI+DQo8Yj5Ubzo8L2I+ IE1vIFphbmF0eSAobXphbmF0eSk8YnI+DQo8Yj5DYzo8L2I+IFJvc3MgRmlubGF5c29uOyBhdnRA aWV0Zi5vcmc7IHBheWxvYWRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtBVlRD T1JFXSBbcGF5bG9hZF0gQ2xhcmlmeWluZyB0aGUgSC4yNjUgUlRQIHBheWxvYWQgZm9ybWF0IHNw ZWNpZmljYXRpb24ncyB0ZXh0IG9uIHdoZW4gdG8gc2V0IHRoZSBSVFAgJnF1b3Q7TSZxdW90OyBi aXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIE1vLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPiZx dW90O1RoZSBjb250ZW50IG9mIGEgTkFMIHVuaXQmcXVvdDsgY2FuIHRlbGwgd2hldGhlciB0aGUg TkFMIHVuaXQgaXMgdGhlIGxhc3Qgc2xpY2Ugb2YgYSBwaWN0dXJlLCBidXQgdGhlIGxhc3QgTkFM IHVuaXQgb2YgYW4gQVUgY2FuIGFsc28gYmUgYSBub24tVkNMIE5BTCB1bml0LiBDb25zaWRlcmlu ZyB0aGlzLCAmcXVvdDt0aGUgY29udGVudCBvZiBhIE5BTCB1bml0JnF1b3Q7IGRvZXMgbm90IHRl bGwgd2hldGhlcg0KIGEgTkFMIHVuaXQgaXMgdGhlIGxhc3QgTkFMIHVuaXQgb2YgYW4gQVUuPC9z cGFuPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSLCBZSzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTW8gWmFuYXR5 IChtemFuYXR5KSBbbWFpbHRvOm16YW5hdHlAY2lzY28uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IFR1ZXNkYXksIEF1Z3VzdCAyNywgMjAxMyAzOjU4IFBNPGJyPg0KPGI+VG86PC9iPiBXYW5nLCBZ ZS1LdWk8YnI+DQo8Yj5DYzo8L2I+IFJvc3MgRmlubGF5c29uOyBhdnRAaWV0Zi5vcmc7IHBheWxv YWRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtBVlRDT1JFXSBbcGF5bG9hZF0g Q2xhcmlmeWluZyB0aGUgSC4yNjUgUlRQIHBheWxvYWQgZm9ybWF0IHNwZWNpZmljYXRpb24ncyB0 ZXh0IG9uIHdoZW4gdG8gc2V0IHRoZSBSVFAgJnF1b3Q7TSZxdW90OyBiaXQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tQ0EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+SSBzdWdnZXN0IHJlcGxhY2luZyAmcXVvdDtU aGUgY29udGVudCBvZiBhIE5BTCB1bml0JnF1b3Q7IHdpdGggJnF1b3Q7VGhlIE5BTCB1bml0IGhl YWRlciZxdW90Oy4gVGhlIGNvbnRlbnQgZG9lcyByZXZlYWwgZW5kIG9mIGFjY2VzcyB1bml0IGJv dW5kYXJpZXMgaWYgeW91J3JlIHdpbGxpbmcgdG8gcGFyc2UvZGVjb2RlIGl0IGFsbC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1DQSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPk1vPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1DQSI+PGJyPg0KPGJyPg0KT24gQXVn IDI3LCAyMDEzLCBhdCAxMjo1MSBBTSwgJnF1b3Q7V2FuZywgWWUtS3VpJnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86eWVrdWl3QHF0aS5xdWFsY29tbS5jb20iPnlla3Vpd0BxdGkucXVhbGNvbW0u Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5IaSBSb3NzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+U29ycnkgZm9yIGEgc2xvdyByZXNwb25zZS4gSSBzdGFydGVkIHRvIGVkaXQgdGhpcyBkcmFm dCB0b2RheSwgYW5kIGhhdmUgaW5jbHVkZWQgdGhlIGZvbGxvd2luZyBub3RlIGFmdGVyIHRoZSBz ZW1hbnRpY3Mgb2YgdGhlIE0gYml0Ojwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouOWluIj48c3BhbiBsYW5nPSJFTi1DQSI+SW5mb3JtYXRpdmUgbm90 ZTogVGhlIGNvbnRlbnQgb2YgYSBOQUwgdW5pdCBkb2VzIG5vdCB0ZWxsIHdoZXRoZXIgb3Igbm90 IHRoZSBOQUwgdW5pdCBpcyB0aGUgbGFzdCBOQUwgdW5pdCwgaW4gZGVjb2Rpbmcgb3JkZXIsIG9m IGFuIGFjY2VzcyB1bml0LiZuYnNwOyBBbiBSVFAgc2VuZGVyIGltcGxlbWVudGF0aW9uIG1heSBv YnRhaW4gdGhpcw0KIGluZm9ybWF0aW9uIGZyb20gdGhlIHZpZGVvIGVuY29kZXIuJm5ic3A7IElm LCBob3dldmVyLCB0aGUgaW1wbGVtZW50YXRpb24gY2Fubm90IG9idGFpbiB0aGlzIGluZm9ybWF0 aW9uIGRpcmVjdGx5IGZyb20gdGhlIGVuY29kZXIsIGUuZy4sIHdoZW4gdGhlIHN0cmVhbSB3YXMg cHJlLWVuY29kZWQsIGFuZCBhbHNvIHRoZXJlIGlzIG5vIHRpbWVzdGFtcCBhbGxvY2F0ZWQgZm9y IGVhY2ggTkFMIHVuaXQsIHRoZW4gdGhlIHNlbmRlciBpbXBsZW1lbnRhdGlvbg0KIGNhbiBpbnNw ZWN0IHN1YnNlcXVlbnQgTkFMIHVuaXRzIGluIGRlY29kaW5nIG9yZGVyIHRvIGRldGVybWluZSB3 aGV0aGVyIG9yIG5vdCB0aGUgTkFMIHVuaXQgaXMgdGhlIGxhc3QgTkFMIHVuaXQgb2YgYW4gYWNj ZXNzIHVuaXQgYXMgZm9sbG93cy4mbmJzcDsgQSBOQUwgdW5pdCBuYWx1WCBpcyB0aGUgbGFzdCBO QUwgdW5pdCBvZiBhbiBhY2Nlc3MgdW5pdCBpZiB0aGUgbmV4dCBWQ0wgTkFMIHVuaXQgbmFsdVkg aW4gZGVjb2Rpbmcgb3JkZXIgaGFzIHRoZQ0KIGhpZ2gtb3JkZXIgYml0IG9mIHRoZSBmaXJzdCBi eXRlIGFmdGVyIGl0cyBOQUwgdW5pdCBoZWFkZXIgZXF1YWwgdG8gMSwgYW5kIGFsbCBOQUwgdW5p dHMgYmV0d2VlbiBuYWx1WCBhbmQgbmFsdVksIHdoZW4gcHJlc2VudCwgaGF2ZSBuYWxfdW5pdF90 eXBlIGluIHRoZSByYW5nZSBvZiAzMiB0byAzNSwgaW5jbHVzaXZlLCBlcXVhbCB0byAzOSwgaW4g dGhlIHJhbmdlIG9mIDQxIHRvIDQ0LCBpbmNsdXNpdmUsIG9yIGluIHRoZSByYW5nZSBvZiA0OA0K IHRvIDU1LCBpbmNsdXNpdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V291bGQgeW91IGJlIGZpbmUgd2l0aCB0aGlzIHdvcmRp bmc/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CUiwgWUs8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4N CjxhIGhyZWY9Im1haWx0bzphdnQtYm91bmNlc0BpZXRmLm9yZyI+YXZ0LWJvdW5jZXNAaWV0Zi5v cmc8L2E+IFs8YSBocmVmPSJtYWlsdG86YXZ0LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzphdnQt Ym91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvc3MgRmlubGF5c29u PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXVndXN0IDEyLCAyMDEzIDEyOjI1IFBNPGJyPg0K PGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86YXZ0QGlldGYub3JnIj5hdnRAaWV0Zi5vcmc8L2E+ OyA8YSBocmVmPSJtYWlsdG86cGF5bG9hZEBpZXRmLm9yZyI+DQpwYXlsb2FkQGlldGYub3JnPC9h Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0FWVENPUkVdIFtwYXlsb2FkXSBDbGFyaWZ5aW5n IHRoZSBILjI2NSBSVFAgcGF5bG9hZCBmb3JtYXQgc3BlY2lmaWNhdGlvbidzIHRleHQgb24gd2hl biB0byBzZXQgdGhlIFJUUCAmcXVvdDtNJnF1b3Q7IGJpdDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1D QSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WW91IGp1c3QgbmVlZCBv bmUgbW9yZSBsaXR0bGUgc3RlcCB0byBnZXQgZXZlcnl0aGluZyByaWdodCBoZXJlLCBpbnN0ZWFk IG9mIHRoaW5raW5nIG9mIGNvbXByb21pc2luZyB0aGUgaW1wbGVtZW50YXRpb248c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29s b3I6IzFGNDk3RCI+Sjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VGhhdCBpcywgcmVhZCBzdWJjbGF1c2UgNy40LjIuNC40IG9mIHRo ZSBIRVZDIHNwZWMuIFRoZSBtb3N0IHJlbGV2YW50IHBhcmFncmFwaHMgYXJlIGNvcGllZCBiZWxv dyBmb3IgY29udmVuaWVuY2UgKHRoZSBmaXJzdCBwYXJhZ3JhcGggaXRzZWxmIGNvbnRhaW5zDQog dGhlIGFuc3dlciB0byB5b3VyIHF1ZXN0aW9uLCBidXQgdGhlIHNlY29uZCBwYXJhZ3JhcGggbWF5 IGFsc28gcHJvdmlkZSBoZWxwZnVsIGluZm9ybWF0aW9uKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1D QSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1DQSI+VGhhbmtzIGZvciB0aGUgaW5mbzsgdGhhdCB3YXMgdXNlZnVsLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1DQSI+SGVyZSwgdGhlbiBpcyB0 aGUgdXBkYXRlZCB0ZXh0IG9mIGEgcGFyYWdyYXBoIC0gdG8gYmUgYWRkZWQgYWZ0ZXIgdGhlIGV4 aXN0aW5nICdNIGJpdCcgdGV4dCAtIHRoYXQgY2xhcmlmaWVzIHdoZW4vaG93IHRvIHNldCBpdDo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiPi0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D QSI+VW5mb3J0dW5hdGVseSB0aGUgY29udGVudHMgb2YgYSBOQUwgdW5pdCwgYWxvbmUsIGRvIG5v dCB0ZWxsIGEgUlRQIHNlbmRlciBpbXBsZW1lbnRhdGlvbiB3aGV0aGVyIG9yIG5vdCB0aGUgTkFM IHVuaXQgZW5kcyBhbiBhY2Nlc3MgdW5pdC4gJm5ic3A7SW5zdGVhZCwgdGhlIGltcGxlbWVudGF0 aW9uIG1heSBiZSBhYmxlIHRvIG9idGFpbiB0aGlzIGluZm9ybWF0aW9uIHNlcGFyYXRlbHksDQog ZnJvbSB0aGUgZW5jb2Rlci4gJm5ic3A7SWYsIGhvd2V2ZXIsIHRoZSBpbXBsZW1lbnRhdGlvbiBj YW5ub3Qgb2J0YWluIHRoaXMgaW5mb3JtYXRpb24gZGlyZWN0bHkgZnJvbSB0aGUgZW5jb2RlciAo ZS5nLiwgYmVjYXVzZSB0aGUgaW1wbGVtZW50YXRpb24gaXMgc2VuZGluZyBkYXRhIHRoYXQgY29u c2lzdHMgc29sZWx5IG9mIGEgc2VxdWVuY2Ugb2YgcHJlLWVuY29kZWQgTkFMIHVuaXRzKSwgdGhl biBpdCBtdXN0IGluc3RlYWQgaW5zcGVjdCBzdWJzZXF1ZW50DQogTkFMIHVuaXRzLCB0byBkZXRl cm1pbmUgd2hldGhlciBvciBub3QgdGhlIE5BTCB1bml0IGVuZHMgYW4gYWNjZXNzIHVuaXQuICZu YnNwO0lmIHRoZSBOQUwgdW5pdHMgaGF2ZSBhbHJlYWR5IGJlZW4gdGltZXN0YW1wZWQsIHRoZW4g dGhlc2UgdGltZXN0YW1wcyBjYW4gYmUgdXNlZCB0byBkZXRlcm1pbmUgdGhlIGFjY2VzcyB1bml0 IGJvdW5kYXJpZXMuICZuYnNwO090aGVyd2lzZSwgdGhlIGFjY2VzcyB1bml0IGJvdW5kYXJpZXMg KGFuZCB0aW1lcykgbXVzdCBiZQ0KIGRldGVybWluZWQgYnkgaW5zcGVjdGluZyB0aGUgTkFMIHVu aXRzJyBjb250ZW50cyAtIHNwZWNpZmljYWxseSwgdGhlICZxdW90O25hbF91bml0X3R5cGUmcXVv dDsgYW5kIChmb3IgVkNMIE5BTCB1bml0cykgdGhlICZxdW90O2ZpcnN0X3NsaWNlX3NlZ21lbnRf aW5fcGljX2ZsYWcmcXVvdDsuICZuYnNwO1RoZSBmb2xsb3dpbmcgcnVsZSBjYW4gYmUgdXNlZDo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPg0K PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDtBIE5BTCB1bml0IChYKSBlbmRzIGFuIGFj Y2VzcyB1bml0IGlmIHRoZSBuZXh0LW9jY3VycmluZyBWQ0wgTkFMIHVuaXQgKFkpIGhhcyB0aGUg aGlnaC1vcmRlciBiaXQgb2YgdGhlIGZpcnN0IGJ5dGUgYWZ0ZXIgaXRzIE5BTCB1bml0IGhlYWRl ciBlcXVhbCB0byAxLCBhbmQgYWxsIE5BTCB1bml0cywgaWYgYW55LCBiZXR3ZWVuIChYKSBhbmQg KFkpIGhhdmUgYSAmcXVvdDtuYWxfdW5pdF90eXBlJnF1b3Q7IGluIG9uZQ0KIG9mIHRoZSBmb2xs b3dpbmcgcmFuZ2VzOiBbMzIsMzVdLCAzOSwgWzQxLDQ0XSwgb3IgWzQ4LDU1XS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1DQSI+LS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5 bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlJvc3MgRmlubGF5c29uPC9zcGFuPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj5MaXZlIE5ldHdvcmtzLCBJ bmMuPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48YSBocmVmPSJo dHRwOi8vd3d3LmxpdmU1NTUuY29tLyI+aHR0cDovL3d3dy5saXZlNTU1LmNvbS88L2E+PC9zcGFu Pjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUNBIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNl PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmF2dEBpZXRmLm9yZyI+YXZ0QGlldGYub3JnPC9hPjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0Ij5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dDwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3879D71E758A7E4AA99A35DD8D41D3D91D50A36Axmbrcdx14ciscoc_-- From yekuiw@qti.qualcomm.com Wed Aug 28 10:55:58 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F0121E8050; Wed, 28 Aug 2013 10:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihPqGrTdgL58; Wed, 28 Aug 2013 10:55:30 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4E811E81A8; Wed, 28 Aug 2013 10:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1377712518; x=1409248518; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XI7SGSotHnMPuKUoam298iO0hSlBvvBIyfkWAbhgdKQ=; b=d9VNhZYFr7a8Uvlk09jo+qFXHl4vxxLqPNeycCSfvsLN5SJ+ihzAUwl3 2Dm9YtCDiN3ss4td222MU8jCJGxnAK3XFZnztYBwh6tHV79gFVPI33TfL /SM5NxUP5KT7Avbid2sDsaas3u+RjilVstAs4jz2ozQrdTIqQBc9/Wq39 s=; X-IronPort-AV: E=McAfee;i="5400,1158,7181"; a="50373431" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth01.qualcomm.com with ESMTP; 28 Aug 2013 10:55:13 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7181"; a="18592879" Received: from nasanexhc13.na.qualcomm.com ([172.30.48.20]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 28 Aug 2013 10:55:12 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc13.na.qualcomm.com (172.30.48.20) with Microsoft SMTP Server (TLS) id 14.3.146.2; Wed, 28 Aug 2013 10:55:12 -0700 Received: from NASANEXD02F.na.qualcomm.com ([169.254.8.196]) by nasanexhc05.na.qualcomm.com ([172.30.48.2]) with mapi id 14.03.0146.002; Wed, 28 Aug 2013 10:55:12 -0700 From: "Wang, Ye-Kui" To: "Mo Zanaty (mzanaty)" Thread-Topic: [AVTCORE] [payload] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit Thread-Index: AQHOo3jm1moEaDpZa0yx3vgEUVhvCZmp1oPggACkDgCAAGUh8A== Date: Wed, 28 Aug 2013 17:55:11 +0000 Message-ID: <8BA7D4CEACFFE04BA2D902BF11719A833851364F@nasanexd02f.na.qualcomm.com> References: <3879D71E758A7E4AA99A35DD8D41D3D91D4C7AA7@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D4C47@nasanexd02f.na.qualcomm.com> <5D781561-69CD-4E0D-9377-B4B26036E691@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D5FB3@nasanexd02f.na.qualcomm.com> <69F25DB2-6926-4ACA-935D-90376A2A7BFA@live555.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D690F@nasanexd02f.na.qualcomm.com> <3879D71E758A7E4AA99A35DD8D41D3D91D4CC65C@xmb-rcd-x14.cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A83384D6FD4@nasanexd02f.na.qualcomm.com> <8BA7D4CEACFFE04BA2D902BF11719A83385120E1@nasanexd02f.na.qualcomm.com> <75CC2B0E-28F2-452C-9CE5-060DB8DFEE6B@cisco.com> <8BA7D4CEACFFE04BA2D902BF11719A8338512D57@nasanexd02f.na.qualcomm.com> <3879D71E758A7E4AA99A35DD8D41D3D91D50A36A@xmb-rcd-x14.cisco.com> In-Reply-To: <3879D71E758A7E4AA99A35DD8D41D3D91D50A36A@xmb-rcd-x14.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.48.1] Content-Type: multipart/alternative; boundary="_000_8BA7D4CEACFFE04BA2D902BF11719A833851364Fnasanexd02fnaqu_" MIME-Version: 1.0 Cc: "avt@ietf.org" , "payload@ietf.org" Subject: Re: [payload] [AVTCORE] Clarifying the H.265 RTP payload format specification's text on when to set the RTP "M" bit X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 17:55:58 -0000 --_000_8BA7D4CEACFFE04BA2D902BF11719A833851364Fnasanexd02fnaqu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTW8sDQoNCkdvb2QgcG9pbnQuIFRoZSBub3RlIGlzIHJlYWxseSBhYm91dCBhbiBSVFAgc2Vu ZGVyIGltcGxlbWVudGF0aW9uIHRha2VzIGFuIEhFVkMgYml0c3RyZWFtIGFzIGlucHV0IGFuZCBn ZW5lcmF0ZXMgUlRQIHBhY2tldHMgYXMgdGhlIG91dHB1dCwgd2hpbGUgdXN1YWxseSBOQUwgdW5p dHMgd2l0aCB0eXBlIGluIHRoZSByYW5nZSBvZiBbNDgtNjNdIHdvdWxkIG5vdCBiZSBwcmVzZW50 IGluIGFuIEhFVkMgYml0c3RyZWFtLiBIeXBvdGhldGljYWxseSwgZXZlbiBzb21lIHNvcnRzIG9m IE5BTCB1bml0cyB3aXRoIHR5cGUgaW4gdGhlIHJhbmdlIG9mIFs0OC02M10gYXJlIHByZXNlbnQs IHRoZSBub3RlIGlzIHN0aWxsIGNvcnJlY3QgaW4gdGVybXMgb2YgdGVsbGluZyB3aGljaCBOQUwg dW5pdCBpcyB0aGUgbGFzdCBOQUwgdW5pdCBvZiBhbiBBVS4gTm90ZSB0aGF0IGZyb20gdGhlIHZp ZGVvIGNvZGluZyBzcGVjIHBvaW50IG9mIHZpZXcsIHRoZSByYW5nZSBvZiBbNDgtNjNdIGlzIG5v dCBqdXN0IGxlZnQgdW5zcGVjaWZpZWQgZm9yIHRoZSBSVFAgcGF5bG9hZCBmb3JtYXRzLCBidXQg YWxzbyBmb3IgZmlsZSBmb3JtYXRzIGFuZCBvdGhlciBzeXN0ZW1zIGNvbXBvbmVudHMgYXMgd2Vs bC4NCg0KSW4gSkNULVZDLCB0aGUgc3BsaXR0aW5nIG9mIHRoZSByYW5nZSBbNDgtNjNdIGludG8g dHdvIHN1YmNhdGVnb3JpZXMsIHByZWZpeCBhbmQgc3VmZml4LCB3YXMgYSByZXN1bHQgZnJvbSBh IGRpc2N1c3Npb24gb24gdGhlIFBBQ1NJIE5BTCB1bml0IGluIFJGQyA2MTkwLCB3aGljaCBpcyBl ZmZlY3RpdmVseSBhIHByZWZpeCwgYnV0IGluIEguMjY0L0FWQyBhbGwgdGhlIOKAnHVuc3BlY2lm aWVk4oCdIE5BTCB1bml0IHR5cGVzIGFyZSBzcGVjaWZpZWQgYXMgc3VmZml4LiBUaGUgaXNzdWUg d2FzIHByZXR0eSBoeXBvdGhldGljYWwgSU1PLCBhcyBhbnl3YXkgYW4gUlRQIGRlcGFja2V0aXpl ciAob3IgYSBmaWxlIHBhcnNlcikgd291bGQgbm90IGZlZWQgc3R1ZmYgbGlrZSBBUHMgb3IgRlVz IGRpcmVjdGx5IGludG8gYSBkZWNvZGVyLiBPbmUgcmVsYXRlZCBhY3Rpb24gd2Ugc2hvdWxkIHBy b2JhYmx5IGRvIGlzIHRvIGV4cGxpY2l0bHkgZGlzYWxsb3cgYW4gUlRQIGRlcGFja2V0aXplciB0 byBkaXJlY3RseSBvdXRwdXQgQVBzIG9yIEZVcyB3aXRob3V0IGRlcGFja2V0aXppbmcgdGhlbSBl dmVuIHRob3VnaCB0aGF0IGxvb2tzIG9idmlvdXMuDQoNCkN1cnJlbnRseSBpbiB0aGlzIGRyYWZ0 LCBBUHMgYW5kIEZVcyB1c2UgdHlwZXMgNDggYW5kIDQ5LCB0d28gb2YgdGhlIHByZWZpeCDigJx1 bnNwZWNpZmllZOKAnSBOQUwgdW5pdCB0eXBlcy4gVGhpcyBpcyBmaW5lLCBhcyBpbiBhbiBSVFAg c3RyZWFtIGFuIEFQIG9yIEZVIG1heSBzdGFydCBhbiDigJxBVeKAnS4NCg0KUmVnYXJkaW5nIHlv dXIgbGFzdCBwb2ludCwgSSBhZ3JlZSB0aGF0IGluZGVlZCBpdCB3b3VsZCBiZSB1c2VmdWwgdG8g ZXhwbGljaXRseSBzcGVsbCBvdXQgd2hpY2ggTkFMIHVuaXRzIGFyZSBWQ0wgTkFMIHVuaXRzIChh bmQgd2hpY2ggb25lcyBhcmUgbm9uLVZDTCBOQUwgdW5pdCkgaW4gdGhpcyBkcmFmdC4gSW5zdGVh ZCBvZiBwdXR0aW5nIHRoaXMgaW5mb3JtYXRpb24gaW50byB0aGUgbm90ZSwgSSB0aGluayBpdCBp cyBwcm9iYWJseSBldmVuIGJldHRlciB0byBtZW50aW9uIGl0IGluIFNlY3Rpb24gMS4xLjQgKE5B TCBVbml0IEhlYWRlcikgYXMgcGFydCBvZiB0aGUgaW50cm9kdWN0aW9uIHRvIHRoZSBuYWxfdW5p dF90eXBlIGZpZWxkLg0KDQpCUiwgWUsNCg0KRnJvbTogTW8gWmFuYXR5IChtemFuYXR5KSBbbWFp bHRvOm16YW5hdHlAY2lzY28uY29tXQ0KU2VudDogVHVlc2RheSwgQXVndXN0IDI3LCAyMDEzIDk6 MjIgUE0NClRvOiBXYW5nLCBZZS1LdWkNCkNjOiBSb3NzIEZpbmxheXNvbjsgYXZ0QGlldGYub3Jn OyBwYXlsb2FkQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW0FWVENPUkVdIFtwYXlsb2FkXSBDbGFy aWZ5aW5nIHRoZSBILjI2NSBSVFAgcGF5bG9hZCBmb3JtYXQgc3BlY2lmaWNhdGlvbidzIHRleHQg b24gd2hlbiB0byBzZXQgdGhlIFJUUCAiTSIgYml0DQoNCkhpIFlLLA0KDQpHb29kIHBvaW50IG9u IHRyYWlsaW5nIG5vbi1WQ0wgTkFMIHVuaXRzLg0KDQpUaGF0IGJyaW5ncyB1cCBhbm90aGVyIHBv aW50IG9uIG5vbi1WQ0wgTkFMIHVuaXRzLiBJIGFzc3VtZSB0aGUgbm9uLVZDTCBOQUwgdW5pdHMg ZGVmaW5lZCBpbiB0aGlzIGRyYWZ0IChBUC9GVSkgY2Fu4oCZdCBhcHBlYXIgaW4gdGhlIGJpdHN0 cmVhbSBwcm9jZXNzZWQgYnkgdGhlIFJUUCBzZW5kZXIgdXNpbmcgdGhpcyBpbmZvcm1hdGl2ZSBu b3RlLiBUaGF0IGlzLCB0aGUgUlRQIHNlbmRlciBtdXN0IGJlIHByb2Nlc3NpbmcgYW4gZWxlbWVu dGFyeSBzdHJlYW0gdGhhdCBvbmx5IGNvbnRhaW5zIE5BTCB1bml0cyBzcGVjaWZpZWQgaW4gdGhl IEguMjY1IHN0YW5kYXJkIGl0c2VsZiBbMC00N10sIGFuZCBjYW7igJl0IGJlIHByb2Nlc3Npbmcg YSBiaXRzdHJlYW0gdGhhdCBjYW1lIGZyb20gYW5vdGhlciBSVFAgc2VuZGVyIHdoaWNoIG1heSBo YXZlIGluc2VydGVkIHVuc3BlY2lmaWVkIE5BTCB1bml0cyBbNDgtNjNdIGxpa2UgQVAvRlUsIHNp bmNlIHRoYXQgY291bGQgeWllbGQgaW1wcm9wZXIgcmVzdWx0cyBmb3IgdGhpcyBub3RlLg0KDQpP ciBkbyB3ZSBhY3R1YWxseSBuZWVkIHRvIHNwbGl0IEFQIGFuZCBGVSBlYWNoIGludG8gdHdvIG5v bi1WQ0wgdW5pdHMsIG9uZSBpbiB0aGUgbGVhZGluZyBub24tVkNMIHJhbmdlIFs0OC01NV0gYW5k IGFub3RoZXIgaW4gdGhlIHRyYWlsaW5nIG5vbi1WQ0wgcmFuZ2UgWzU2LTYzXT8gSSB3b3VsZCBs aWtlIHRvIGF2b2lkIHRoYXQgY29tcGxleGl0eSwgYnV0IHRoYXQgc2VlbXMgdG8gYmUgd2hhdCB0 aGUgcnVsZXMgaW4gSC4yNjUgNy40LjIuNC40IHJlcXVpcmUgd2hlbiB1c2luZyB0aGUgdW5zcGVj aWZpZWQgcmFuZ2UgWzQ4LTYzXS4gRG8geW91IHJlY2FsbCB0aGUgbW90aXZhdGlvbiBmb3IgcnVs ZXMgb24gc3VicmFuZ2VzIG9mIHRoZSB1bnNwZWNpZmllZCByYW5nZT8NCg0KQWxzbywgaXQgbWF5 IGJlIHVzZWZ1bCB0byBpbmRpY2F0ZSBpbiB0aGUgaW5mb3JtYXRpdmUgbm90ZSBob3cgdG8gZGlm ZmVyZW50aWF0ZSBWQ0wgTkFMIHVuaXRzIFswLTMxXSBmcm9tIG5vbi1WQ0wgTkFMIHVuaXRzIFsz Mi02M10sIGkuZS4gdGhlIE1TQiBvZiB0aGUgNi1iaXQgTkFMIHVuaXQgdHlwZSBpcyAxIGluIG5v bi1WQ0wgTkFMIHVuaXRzLg0KDQpSZWdhcmRzLA0KTW8NCg0KDQpGcm9tOiBXYW5nLCBZZS1LdWkg W21haWx0bzp5ZWt1aXdAcXRpLnF1YWxjb21tLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAy NywgMjAxMyA5OjM2IFBNDQpUbzogTW8gWmFuYXR5IChtemFuYXR5KQ0KQ2M6IFJvc3MgRmlubGF5 c29uOyBhdnRAaWV0Zi5vcmc8bWFpbHRvOmF2dEBpZXRmLm9yZz47IHBheWxvYWRAaWV0Zi5vcmc8 bWFpbHRvOnBheWxvYWRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0FWVENPUkVdIFtwYXlsb2Fk XSBDbGFyaWZ5aW5nIHRoZSBILjI2NSBSVFAgcGF5bG9hZCBmb3JtYXQgc3BlY2lmaWNhdGlvbidz IHRleHQgb24gd2hlbiB0byBzZXQgdGhlIFJUUCAiTSIgYml0DQoNCkhpIE1vLA0KDQoiVGhlIGNv bnRlbnQgb2YgYSBOQUwgdW5pdCIgY2FuIHRlbGwgd2hldGhlciB0aGUgTkFMIHVuaXQgaXMgdGhl IGxhc3Qgc2xpY2Ugb2YgYSBwaWN0dXJlLCBidXQgdGhlIGxhc3QgTkFMIHVuaXQgb2YgYW4gQVUg Y2FuIGFsc28gYmUgYSBub24tVkNMIE5BTCB1bml0LiBDb25zaWRlcmluZyB0aGlzLCAidGhlIGNv bnRlbnQgb2YgYSBOQUwgdW5pdCIgZG9lcyBub3QgdGVsbCB3aGV0aGVyIGEgTkFMIHVuaXQgaXMg dGhlIGxhc3QgTkFMIHVuaXQgb2YgYW4gQVUuDQoNCkJSLCBZSw0KDQpGcm9tOiBNbyBaYW5hdHkg KG16YW5hdHkpIFttYWlsdG86bXphbmF0eUBjaXNjby5jb21dDQpTZW50OiBUdWVzZGF5LCBBdWd1 c3QgMjcsIDIwMTMgMzo1OCBQTQ0KVG86IFdhbmcsIFllLUt1aQ0KQ2M6IFJvc3MgRmlubGF5c29u OyBhdnRAaWV0Zi5vcmc8bWFpbHRvOmF2dEBpZXRmLm9yZz47IHBheWxvYWRAaWV0Zi5vcmc8bWFp bHRvOnBheWxvYWRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0FWVENPUkVdIFtwYXlsb2FkXSBD bGFyaWZ5aW5nIHRoZSBILjI2NSBSVFAgcGF5bG9hZCBmb3JtYXQgc3BlY2lmaWNhdGlvbidzIHRl eHQgb24gd2hlbiB0byBzZXQgdGhlIFJUUCAiTSIgYml0DQoNCkkgc3VnZ2VzdCByZXBsYWNpbmcg IlRoZSBjb250ZW50IG9mIGEgTkFMIHVuaXQiIHdpdGggIlRoZSBOQUwgdW5pdCBoZWFkZXIiLiBU aGUgY29udGVudCBkb2VzIHJldmVhbCBlbmQgb2YgYWNjZXNzIHVuaXQgYm91bmRhcmllcyBpZiB5 b3UncmUgd2lsbGluZyB0byBwYXJzZS9kZWNvZGUgaXQgYWxsLg0KDQpNbw0KDQoNCk9uIEF1ZyAy NywgMjAxMywgYXQgMTI6NTEgQU0sICJXYW5nLCBZZS1LdWkiIDx5ZWt1aXdAcXRpLnF1YWxjb21t LmNvbTxtYWlsdG86eWVrdWl3QHF0aS5xdWFsY29tbS5jb20+PiB3cm90ZToNCkhpIFJvc3MsDQoN ClNvcnJ5IGZvciBhIHNsb3cgcmVzcG9uc2UuIEkgc3RhcnRlZCB0byBlZGl0IHRoaXMgZHJhZnQg dG9kYXksIGFuZCBoYXZlIGluY2x1ZGVkIHRoZSBmb2xsb3dpbmcgbm90ZSBhZnRlciB0aGUgc2Vt YW50aWNzIG9mIHRoZSBNIGJpdDoNCg0KSW5mb3JtYXRpdmUgbm90ZTogVGhlIGNvbnRlbnQgb2Yg YSBOQUwgdW5pdCBkb2VzIG5vdCB0ZWxsIHdoZXRoZXIgb3Igbm90IHRoZSBOQUwgdW5pdCBpcyB0 aGUgbGFzdCBOQUwgdW5pdCwgaW4gZGVjb2Rpbmcgb3JkZXIsIG9mIGFuIGFjY2VzcyB1bml0LiAg QW4gUlRQIHNlbmRlciBpbXBsZW1lbnRhdGlvbiBtYXkgb2J0YWluIHRoaXMgaW5mb3JtYXRpb24g ZnJvbSB0aGUgdmlkZW8gZW5jb2Rlci4gIElmLCBob3dldmVyLCB0aGUgaW1wbGVtZW50YXRpb24g Y2Fubm90IG9idGFpbiB0aGlzIGluZm9ybWF0aW9uIGRpcmVjdGx5IGZyb20gdGhlIGVuY29kZXIs IGUuZy4sIHdoZW4gdGhlIHN0cmVhbSB3YXMgcHJlLWVuY29kZWQsIGFuZCBhbHNvIHRoZXJlIGlz IG5vIHRpbWVzdGFtcCBhbGxvY2F0ZWQgZm9yIGVhY2ggTkFMIHVuaXQsIHRoZW4gdGhlIHNlbmRl ciBpbXBsZW1lbnRhdGlvbiBjYW4gaW5zcGVjdCBzdWJzZXF1ZW50IE5BTCB1bml0cyBpbiBkZWNv ZGluZyBvcmRlciB0byBkZXRlcm1pbmUgd2hldGhlciBvciBub3QgdGhlIE5BTCB1bml0IGlzIHRo ZSBsYXN0IE5BTCB1bml0IG9mIGFuIGFjY2VzcyB1bml0IGFzIGZvbGxvd3MuICBBIE5BTCB1bml0 IG5hbHVYIGlzIHRoZSBsYXN0IE5BTCB1bml0IG9mIGFuIGFjY2VzcyB1bml0IGlmIHRoZSBuZXh0 IFZDTCBOQUwgdW5pdCBuYWx1WSBpbiBkZWNvZGluZyBvcmRlciBoYXMgdGhlIGhpZ2gtb3JkZXIg Yml0IG9mIHRoZSBmaXJzdCBieXRlIGFmdGVyIGl0cyBOQUwgdW5pdCBoZWFkZXIgZXF1YWwgdG8g MSwgYW5kIGFsbCBOQUwgdW5pdHMgYmV0d2VlbiBuYWx1WCBhbmQgbmFsdVksIHdoZW4gcHJlc2Vu dCwgaGF2ZSBuYWxfdW5pdF90eXBlIGluIHRoZSByYW5nZSBvZiAzMiB0byAzNSwgaW5jbHVzaXZl LCBlcXVhbCB0byAzOSwgaW4gdGhlIHJhbmdlIG9mIDQxIHRvIDQ0LCBpbmNsdXNpdmUsIG9yIGlu IHRoZSByYW5nZSBvZiA0OCB0byA1NSwgaW5jbHVzaXZlLg0KDQpXb3VsZCB5b3UgYmUgZmluZSB3 aXRoIHRoaXMgd29yZGluZz8NCg0KQlIsIFlLDQoNCg0KRnJvbTogYXZ0LWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOmF2dC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmF2dC1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgUm9zcyBGaW5sYXlzb24NClNlbnQ6IE1vbmRheSwgQXVndXN0IDEy LCAyMDEzIDEyOjI1IFBNDQpUbzogYXZ0QGlldGYub3JnPG1haWx0bzphdnRAaWV0Zi5vcmc+OyBw YXlsb2FkQGlldGYub3JnPG1haWx0bzpwYXlsb2FkQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtB VlRDT1JFXSBbcGF5bG9hZF0gQ2xhcmlmeWluZyB0aGUgSC4yNjUgUlRQIHBheWxvYWQgZm9ybWF0 IHNwZWNpZmljYXRpb24ncyB0ZXh0IG9uIHdoZW4gdG8gc2V0IHRoZSBSVFAgIk0iIGJpdA0KDQpZ b3UganVzdCBuZWVkIG9uZSBtb3JlIGxpdHRsZSBzdGVwIHRvIGdldCBldmVyeXRoaW5nIHJpZ2h0 IGhlcmUsIGluc3RlYWQgb2YgdGhpbmtpbmcgb2YgY29tcHJvbWlzaW5nIHRoZSBpbXBsZW1lbnRh dGlvbiDimLoNCg0KVGhhdCBpcywgcmVhZCBzdWJjbGF1c2UgNy40LjIuNC40IG9mIHRoZSBIRVZD IHNwZWMuIFRoZSBtb3N0IHJlbGV2YW50IHBhcmFncmFwaHMgYXJlIGNvcGllZCBiZWxvdyBmb3Ig Y29udmVuaWVuY2UgKHRoZSBmaXJzdCBwYXJhZ3JhcGggaXRzZWxmIGNvbnRhaW5zIHRoZSBhbnN3 ZXIgdG8geW91ciBxdWVzdGlvbiwgYnV0IHRoZSBzZWNvbmQgcGFyYWdyYXBoIG1heSBhbHNvIHBy b3ZpZGUgaGVscGZ1bCBpbmZvcm1hdGlvbikNCg0KVGhhbmtzIGZvciB0aGUgaW5mbzsgdGhhdCB3 YXMgdXNlZnVsLg0KDQpIZXJlLCB0aGVuIGlzIHRoZSB1cGRhdGVkIHRleHQgb2YgYSBwYXJhZ3Jh cGggLSB0byBiZSBhZGRlZCBhZnRlciB0aGUgZXhpc3RpbmcgJ00gYml0JyB0ZXh0IC0gdGhhdCBj bGFyaWZpZXMgd2hlbi9ob3cgdG8gc2V0IGl0Og0KLS0tLS0tLS0tLQ0KVW5mb3J0dW5hdGVseSB0 aGUgY29udGVudHMgb2YgYSBOQUwgdW5pdCwgYWxvbmUsIGRvIG5vdCB0ZWxsIGEgUlRQIHNlbmRl ciBpbXBsZW1lbnRhdGlvbiB3aGV0aGVyIG9yIG5vdCB0aGUgTkFMIHVuaXQgZW5kcyBhbiBhY2Nl c3MgdW5pdC4gIEluc3RlYWQsIHRoZSBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgYWJsZSB0byBvYnRh aW4gdGhpcyBpbmZvcm1hdGlvbiBzZXBhcmF0ZWx5LCBmcm9tIHRoZSBlbmNvZGVyLiAgSWYsIGhv d2V2ZXIsIHRoZSBpbXBsZW1lbnRhdGlvbiBjYW5ub3Qgb2J0YWluIHRoaXMgaW5mb3JtYXRpb24g ZGlyZWN0bHkgZnJvbSB0aGUgZW5jb2RlciAoZS5nLiwgYmVjYXVzZSB0aGUgaW1wbGVtZW50YXRp b24gaXMgc2VuZGluZyBkYXRhIHRoYXQgY29uc2lzdHMgc29sZWx5IG9mIGEgc2VxdWVuY2Ugb2Yg cHJlLWVuY29kZWQgTkFMIHVuaXRzKSwgdGhlbiBpdCBtdXN0IGluc3RlYWQgaW5zcGVjdCBzdWJz ZXF1ZW50IE5BTCB1bml0cywgdG8gZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IHRoZSBOQUwgdW5p dCBlbmRzIGFuIGFjY2VzcyB1bml0LiAgSWYgdGhlIE5BTCB1bml0cyBoYXZlIGFscmVhZHkgYmVl biB0aW1lc3RhbXBlZCwgdGhlbiB0aGVzZSB0aW1lc3RhbXBzIGNhbiBiZSB1c2VkIHRvIGRldGVy bWluZSB0aGUgYWNjZXNzIHVuaXQgYm91bmRhcmllcy4gIE90aGVyd2lzZSwgdGhlIGFjY2VzcyB1 bml0IGJvdW5kYXJpZXMgKGFuZCB0aW1lcykgbXVzdCBiZSBkZXRlcm1pbmVkIGJ5IGluc3BlY3Rp bmcgdGhlIE5BTCB1bml0cycgY29udGVudHMgLSBzcGVjaWZpY2FsbHksIHRoZSAibmFsX3VuaXRf dHlwZSIgYW5kIChmb3IgVkNMIE5BTCB1bml0cykgdGhlICJmaXJzdF9zbGljZV9zZWdtZW50X2lu X3BpY19mbGFnIi4gIFRoZSBmb2xsb3dpbmcgcnVsZSBjYW4gYmUgdXNlZDoNCiAgICAgICAgICAg QSBOQUwgdW5pdCAoWCkgZW5kcyBhbiBhY2Nlc3MgdW5pdCBpZiB0aGUgbmV4dC1vY2N1cnJpbmcg VkNMIE5BTCB1bml0IChZKSBoYXMgdGhlIGhpZ2gtb3JkZXIgYml0IG9mIHRoZSBmaXJzdCBieXRl IGFmdGVyIGl0cyBOQUwgdW5pdCBoZWFkZXIgZXF1YWwgdG8gMSwgYW5kIGFsbCBOQUwgdW5pdHMs IGlmIGFueSwgYmV0d2VlbiAoWCkgYW5kIChZKSBoYXZlIGEgIm5hbF91bml0X3R5cGUiIGluIG9u ZSBvZiB0aGUgZm9sbG93aW5nIHJhbmdlczogWzMyLDM1XSwgMzksIFs0MSw0NF0sIG9yIFs0OCw1 NV0uDQotLS0tLS0tLS0tDQoNClJvc3MgRmlubGF5c29uDQpMaXZlIE5ldHdvcmtzLCBJbmMuDQpo dHRwOi8vd3d3LmxpdmU1NTUuY29tLw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UN CmF2dEBpZXRmLm9yZzxtYWlsdG86YXZ0QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hdnQNCg== --_000_8BA7D4CEACFFE04BA2D902BF11719A833851364Fnasanexd02fnaqu_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPGJhc2Ug aHJlZj0ieC1tc2c6Ly85NzEvIj48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQg MiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFu b3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNp bVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4 LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29u VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNl DQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLmFwcGxlLXRh Yi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uYXBwbGUtc3R5 bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uRW1haWxT dHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0 ZSIgbGFuZz0iRU4tQ0EiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBNbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkdvb2QgcG9pbnQuIFRoZSBu b3RlIGlzIHJlYWxseSBhYm91dCBhbiBSVFAgc2VuZGVyIGltcGxlbWVudGF0aW9uIHRha2VzIGFu IEhFVkMgYml0c3RyZWFtIGFzIGlucHV0IGFuZCBnZW5lcmF0ZXMgUlRQIHBhY2tldHMgYXMgdGhl IG91dHB1dCwgd2hpbGUgdXN1YWxseSBOQUwNCiB1bml0cyB3aXRoIHR5cGUgaW4gdGhlIHJhbmdl IG9mIFs0OC02M10gd291bGQgbm90IGJlIHByZXNlbnQgaW4gYW4gSEVWQyBiaXRzdHJlYW0uIEh5 cG90aGV0aWNhbGx5LCBldmVuIHNvbWUgc29ydHMgb2YgTkFMIHVuaXRzIHdpdGggdHlwZSBpbiB0 aGUgcmFuZ2Ugb2YgWzQ4LTYzXSBhcmUgcHJlc2VudCwgdGhlIG5vdGUgaXMgc3RpbGwgY29ycmVj dCBpbiB0ZXJtcyBvZiB0ZWxsaW5nIHdoaWNoIE5BTCB1bml0IGlzIHRoZSBsYXN0IE5BTCB1bml0 DQogb2YgYW4gQVUuIE5vdGUgdGhhdCBmcm9tIHRoZSB2aWRlbyBjb2Rpbmcgc3BlYyBwb2ludCBv ZiB2aWV3LCB0aGUgcmFuZ2Ugb2YgWzQ4LTYzXSBpcyBub3QganVzdCBsZWZ0IHVuc3BlY2lmaWVk IGZvciB0aGUgUlRQIHBheWxvYWQgZm9ybWF0cywgYnV0IGFsc28gZm9yIGZpbGUgZm9ybWF0cyBh bmQgb3RoZXIgc3lzdGVtcyBjb21wb25lbnRzIGFzIHdlbGwuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiBKQ1QtVkMs IHRoZSBzcGxpdHRpbmcgb2YgdGhlIHJhbmdlIFs0OC02M10gaW50byB0d28gc3ViY2F0ZWdvcmll cywgcHJlZml4IGFuZCBzdWZmaXgsIHdhcyBhIHJlc3VsdCBmcm9tIGEgZGlzY3Vzc2lvbiBvbiB0 aGUgUEFDU0kgTkFMIHVuaXQgaW4gUkZDIDYxOTAsIHdoaWNoDQogaXMgZWZmZWN0aXZlbHkgYSBw cmVmaXgsIGJ1dCBpbiBILjI2NC9BVkMgYWxsIHRoZSDigJx1bnNwZWNpZmllZOKAnSBOQUwgdW5p dCB0eXBlcyBhcmUgc3BlY2lmaWVkIGFzIHN1ZmZpeC4gVGhlIGlzc3VlIHdhcyBwcmV0dHkgaHlw b3RoZXRpY2FsIElNTywgYXMgYW55d2F5IGFuIFJUUCBkZXBhY2tldGl6ZXIgKG9yIGEgZmlsZSBw YXJzZXIpIHdvdWxkIG5vdCBmZWVkIHN0dWZmIGxpa2UgQVBzIG9yIEZVcyBkaXJlY3RseSBpbnRv IGEgZGVjb2Rlci4gT25lDQogcmVsYXRlZCBhY3Rpb24gd2Ugc2hvdWxkIHByb2JhYmx5IGRvIGlz IHRvIGV4cGxpY2l0bHkgZGlzYWxsb3cgYW4gUlRQIGRlcGFja2V0aXplciB0byBkaXJlY3RseSBv dXRwdXQgQVBzIG9yIEZVcyB3aXRob3V0IGRlcGFja2V0aXppbmcgdGhlbSBldmVuIHRob3VnaCB0 aGF0IGxvb2tzIG9idmlvdXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DdXJyZW50bHkgaW4gdGhpcyBkcmFmdCwgQVBz IGFuZCBGVXMgdXNlIHR5cGVzIDQ4IGFuZCA0OSwgdHdvIG9mIHRoZSBwcmVmaXgg4oCcdW5zcGVj aWZpZWTigJ0gTkFMIHVuaXQgdHlwZXMuIFRoaXMgaXMgZmluZSwgYXMgaW4gYW4gUlRQIHN0cmVh bSBhbiBBUCBvciBGVSBtYXkNCiBzdGFydCBhbiDigJxBVeKAnS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZGlu ZyB5b3VyIGxhc3QgcG9pbnQsIEkgYWdyZWUgdGhhdCBpbmRlZWQgaXQgd291bGQgYmUgdXNlZnVs IHRvIGV4cGxpY2l0bHkgc3BlbGwgb3V0IHdoaWNoIE5BTCB1bml0cyBhcmUgVkNMIE5BTCB1bml0 cyAoYW5kIHdoaWNoIG9uZXMgYXJlIG5vbi1WQ0wgTkFMDQogdW5pdCkgaW4gdGhpcyBkcmFmdC4g SW5zdGVhZCBvZiBwdXR0aW5nIHRoaXMgaW5mb3JtYXRpb24gaW50byB0aGUgbm90ZSwgSSB0aGlu ayBpdCBpcyBwcm9iYWJseSBldmVuIGJldHRlciB0byBtZW50aW9uIGl0IGluIFNlY3Rpb24gMS4x LjQgKE5BTCBVbml0IEhlYWRlcikgYXMgcGFydCBvZiB0aGUgaW50cm9kdWN0aW9uIHRvIHRoZSBu YWxfdW5pdF90eXBlIGZpZWxkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QlIsIFlLPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTW8gWmFu YXR5IChtemFuYXR5KSBbbWFpbHRvOm16YW5hdHlAY2lzY28uY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IFR1ZXNkYXksIEF1Z3VzdCAyNywgMjAxMyA5OjIyIFBNPGJyPg0KPGI+VG86PC9iPiBXYW5n LCBZZS1LdWk8YnI+DQo8Yj5DYzo8L2I+IFJvc3MgRmlubGF5c29uOyBhdnRAaWV0Zi5vcmc7IHBh eWxvYWRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtBVlRDT1JFXSBbcGF5bG9h ZF0gQ2xhcmlmeWluZyB0aGUgSC4yNjUgUlRQIHBheWxvYWQgZm9ybWF0IHNwZWNpZmljYXRpb24n cyB0ZXh0IG9uIHdoZW4gdG8gc2V0IHRoZSBSVFAgJnF1b3Q7TSZxdW90OyBiaXQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSBZSyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Hb29kIHBvaW50IG9uIHRyYWls aW5nIG5vbi1WQ0wgTkFMIHVuaXRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoYXQgYnJpbmdzIHVwIGFub3RoZXIgcG9p bnQgb24gbm9uLVZDTCBOQUwgdW5pdHMuIEkgYXNzdW1lIHRoZSBub24tVkNMIE5BTCB1bml0cyBk ZWZpbmVkIGluIHRoaXMgZHJhZnQgKEFQL0ZVKSBjYW7igJl0IGFwcGVhciBpbiB0aGUgYml0c3Ry ZWFtIHByb2Nlc3NlZCBieSB0aGUNCiBSVFAgc2VuZGVyIHVzaW5nIHRoaXMgaW5mb3JtYXRpdmUg bm90ZS4gVGhhdCBpcywgdGhlIFJUUCBzZW5kZXIgbXVzdCBiZSBwcm9jZXNzaW5nIGFuIGVsZW1l bnRhcnkgc3RyZWFtIHRoYXQgb25seSBjb250YWlucyBOQUwgdW5pdHMgc3BlY2lmaWVkIGluIHRo ZSBILjI2NSBzdGFuZGFyZCBpdHNlbGYgWzAtNDddLCBhbmQgY2Fu4oCZdCBiZSBwcm9jZXNzaW5n IGEgYml0c3RyZWFtIHRoYXQgY2FtZSBmcm9tIGFub3RoZXIgUlRQIHNlbmRlciB3aGljaA0KIG1h eSBoYXZlIGluc2VydGVkIHVuc3BlY2lmaWVkIE5BTCB1bml0cyBbNDgtNjNdIGxpa2UgQVAvRlUs IHNpbmNlIHRoYXQgY291bGQgeWllbGQgaW1wcm9wZXIgcmVzdWx0cyBmb3IgdGhpcyBub3RlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPk9yIGRvIHdlIGFjdHVhbGx5IG5lZWQgdG8gc3BsaXQgQVAgYW5kIEZVIGVhY2ggaW50 byB0d28gbm9uLVZDTCB1bml0cywgb25lIGluIHRoZSBsZWFkaW5nIG5vbi1WQ0wgcmFuZ2UgWzQ4 LTU1XSBhbmQgYW5vdGhlciBpbiB0aGUgdHJhaWxpbmcgbm9uLVZDTCByYW5nZSBbNTYtNjNdPw0K IEkgd291bGQgbGlrZSB0byBhdm9pZCB0aGF0IGNvbXBsZXhpdHksIGJ1dCB0aGF0IHNlZW1zIHRv IGJlIHdoYXQgdGhlIHJ1bGVzIGluIEguMjY1IDcuNC4yLjQuNCByZXF1aXJlIHdoZW4gdXNpbmcg dGhlIHVuc3BlY2lmaWVkIHJhbmdlIFs0OC02M10uIERvIHlvdSByZWNhbGwgdGhlIG1vdGl2YXRp b24gZm9yIHJ1bGVzIG9uIHN1YnJhbmdlcyBvZiB0aGUgdW5zcGVjaWZpZWQgcmFuZ2U/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+QWxzbywgaXQgbWF5IGJlIHVzZWZ1bCB0byBpbmRpY2F0ZSBpbiB0aGUgaW5mb3JtYXRpdmUg bm90ZSBob3cgdG8gZGlmZmVyZW50aWF0ZSBWQ0wgTkFMIHVuaXRzIFswLTMxXSBmcm9tIG5vbi1W Q0wgTkFMIHVuaXRzIFszMi02M10sIGkuZS4gdGhlIE1TQiBvZiB0aGUgNi1iaXQNCiBOQUwgdW5p dCB0eXBlIGlzIDEgaW4gbm9uLVZDTCBOQUwgdW5pdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UmVnYXJkcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5NbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBXYW5nLCBZ ZS1LdWkgWzxhIGhyZWY9Im1haWx0bzp5ZWt1aXdAcXRpLnF1YWxjb21tLmNvbSI+bWFpbHRvOnll a3Vpd0BxdGkucXVhbGNvbW0uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBB dWd1c3QgMjcsIDIwMTMgOTozNiBQTTxicj4NCjxiPlRvOjwvYj4gTW8gWmFuYXR5IChtemFuYXR5 KTxicj4NCjxiPkNjOjwvYj4gUm9zcyBGaW5sYXlzb247IDxhIGhyZWY9Im1haWx0bzphdnRAaWV0 Zi5vcmciPmF2dEBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpwYXlsb2FkQGlldGYub3Jn Ij4NCnBheWxvYWRAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbQVZUQ09S RV0gW3BheWxvYWRdIENsYXJpZnlpbmcgdGhlIEguMjY1IFJUUCBwYXlsb2FkIGZvcm1hdCBzcGVj aWZpY2F0aW9uJ3MgdGV4dCBvbiB3aGVuIHRvIHNldCB0aGUgUlRQICZxdW90O00mcXVvdDsgYml0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SGkgTW8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90O1RoZSBjb250ZW50IG9mIGEg TkFMIHVuaXQmcXVvdDsgY2FuIHRlbGwgd2hldGhlciB0aGUgTkFMIHVuaXQgaXMgdGhlIGxhc3Qg c2xpY2Ugb2YgYSBwaWN0dXJlLCBidXQgdGhlIGxhc3QgTkFMIHVuaXQgb2YgYW4gQVUgY2FuIGFs c28gYmUgYSBub24tVkNMIE5BTCB1bml0LiBDb25zaWRlcmluZyB0aGlzLCAmcXVvdDt0aGUgY29u dGVudCBvZiBhIE5BTCB1bml0JnF1b3Q7IGRvZXMgbm90IHRlbGwgd2hldGhlciBhIE5BTCB1bml0 IGlzIHRoZQ0KIGxhc3QgTkFMIHVuaXQgb2YgYW4gQVUuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QlIsIFlLPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTW8gWmFu YXR5IChtemFuYXR5KSBbPGEgaHJlZj0ibWFpbHRvOm16YW5hdHlAY2lzY28uY29tIj5tYWlsdG86 bXphbmF0eUBjaXNjby5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEF1Z3Vz dCAyNywgMjAxMyAzOjU4IFBNPGJyPg0KPGI+VG86PC9iPiBXYW5nLCBZZS1LdWk8YnI+DQo8Yj5D Yzo8L2I+IFJvc3MgRmlubGF5c29uOyA8YSBocmVmPSJtYWlsdG86YXZ0QGlldGYub3JnIj5hdnRA aWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86cGF5bG9hZEBpZXRmLm9yZyI+DQpwYXlsb2Fk QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0FWVENPUkVdIFtwYXlsb2Fk XSBDbGFyaWZ5aW5nIHRoZSBILjI2NSBSVFAgcGF5bG9hZCBmb3JtYXQgc3BlY2lmaWNhdGlvbidz IHRleHQgb24gd2hlbiB0byBzZXQgdGhlIFJUUCAmcXVvdDtNJnF1b3Q7IGJpdDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN1Z2dlc3QgcmVw bGFjaW5nICZxdW90O1RoZSBjb250ZW50IG9mIGEgTkFMIHVuaXQmcXVvdDsgd2l0aCAmcXVvdDtU aGUgTkFMIHVuaXQgaGVhZGVyJnF1b3Q7LiBUaGUgY29udGVudCBkb2VzIHJldmVhbCBlbmQgb2Yg YWNjZXNzIHVuaXQgYm91bmRhcmllcyBpZiB5b3UncmUgd2lsbGluZyB0byBwYXJzZS9kZWNvZGUg aXQgYWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5NbzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQpPbiBBdWcgMjcsIDIw MTMsIGF0IDEyOjUxIEFNLCAmcXVvdDtXYW5nLCBZZS1LdWkmcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzp5ZWt1aXdAcXRpLnF1YWxjb21tLmNvbSI+eWVrdWl3QHF0aS5xdWFsY29tbS5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBSb3Nz LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+U29ycnkgZm9yIGEgc2xvdyByZXNwb25zZS4gSSBzdGFydGVkIHRvIGVkaXQg dGhpcyBkcmFmdCB0b2RheSwgYW5kIGhhdmUgaW5jbHVkZWQgdGhlIGZvbGxvd2luZyBub3RlIGFm dGVyIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIE0gYml0Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjlpbiI+SW5mb3JtYXRpdmUgbm90ZTogVGhlIGNvbnRlbnQgb2Yg YSBOQUwgdW5pdCBkb2VzIG5vdCB0ZWxsIHdoZXRoZXIgb3Igbm90IHRoZSBOQUwgdW5pdCBpcyB0 aGUgbGFzdCBOQUwgdW5pdCwgaW4gZGVjb2Rpbmcgb3JkZXIsIG9mIGFuIGFjY2VzcyB1bml0LiZu YnNwOyBBbiBSVFAgc2VuZGVyIGltcGxlbWVudGF0aW9uIG1heSBvYnRhaW4gdGhpcyBpbmZvcm1h dGlvbiBmcm9tIHRoZQ0KIHZpZGVvIGVuY29kZXIuJm5ic3A7IElmLCBob3dldmVyLCB0aGUgaW1w bGVtZW50YXRpb24gY2Fubm90IG9idGFpbiB0aGlzIGluZm9ybWF0aW9uIGRpcmVjdGx5IGZyb20g dGhlIGVuY29kZXIsIGUuZy4sIHdoZW4gdGhlIHN0cmVhbSB3YXMgcHJlLWVuY29kZWQsIGFuZCBh bHNvIHRoZXJlIGlzIG5vIHRpbWVzdGFtcCBhbGxvY2F0ZWQgZm9yIGVhY2ggTkFMIHVuaXQsIHRo ZW4gdGhlIHNlbmRlciBpbXBsZW1lbnRhdGlvbiBjYW4gaW5zcGVjdCBzdWJzZXF1ZW50DQogTkFM IHVuaXRzIGluIGRlY29kaW5nIG9yZGVyIHRvIGRldGVybWluZSB3aGV0aGVyIG9yIG5vdCB0aGUg TkFMIHVuaXQgaXMgdGhlIGxhc3QgTkFMIHVuaXQgb2YgYW4gYWNjZXNzIHVuaXQgYXMgZm9sbG93 cy4mbmJzcDsgQSBOQUwgdW5pdCBuYWx1WCBpcyB0aGUgbGFzdCBOQUwgdW5pdCBvZiBhbiBhY2Nl c3MgdW5pdCBpZiB0aGUgbmV4dCBWQ0wgTkFMIHVuaXQgbmFsdVkgaW4gZGVjb2Rpbmcgb3JkZXIg aGFzIHRoZSBoaWdoLW9yZGVyIGJpdCBvZiB0aGUNCiBmaXJzdCBieXRlIGFmdGVyIGl0cyBOQUwg dW5pdCBoZWFkZXIgZXF1YWwgdG8gMSwgYW5kIGFsbCBOQUwgdW5pdHMgYmV0d2VlbiBuYWx1WCBh bmQgbmFsdVksIHdoZW4gcHJlc2VudCwgaGF2ZSBuYWxfdW5pdF90eXBlIGluIHRoZSByYW5nZSBv ZiAzMiB0byAzNSwgaW5jbHVzaXZlLCBlcXVhbCB0byAzOSwgaW4gdGhlIHJhbmdlIG9mIDQxIHRv IDQ0LCBpbmNsdXNpdmUsIG9yIGluIHRoZSByYW5nZSBvZiA0OCB0byA1NSwgaW5jbHVzaXZlLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5Xb3VsZCB5b3UgYmUgZmluZSB3aXRoIHRoaXMgd29yZGluZz88L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSLCBZSzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQu MHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJl Zj0ibWFpbHRvOmF2dC1ib3VuY2VzQGlldGYub3JnIj5hdnQtYm91bmNlc0BpZXRmLm9yZzwvYT4g WzxhIGhyZWY9Im1haWx0bzphdnQtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmF2dC1ib3VuY2Vz QGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9zcyBGaW5sYXlzb248YnI+DQo8 Yj5TZW50OjwvYj4gTW9uZGF5LCBBdWd1c3QgMTIsIDIwMTMgMTI6MjUgUE08YnI+DQo8Yj5Ubzo8 L2I+IDxhIGhyZWY9Im1haWx0bzphdnRAaWV0Zi5vcmciPmF2dEBpZXRmLm9yZzwvYT47IDxhIGhy ZWY9Im1haWx0bzpwYXlsb2FkQGlldGYub3JnIj4NCnBheWxvYWRAaWV0Zi5vcmc8L2E+PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbQVZUQ09SRV0gW3BheWxvYWRdIENsYXJpZnlpbmcgdGhlIEgu MjY1IFJUUCBwYXlsb2FkIGZvcm1hdCBzcGVjaWZpY2F0aW9uJ3MgdGV4dCBvbiB3aGVuIHRvIHNl dCB0aGUgUlRQICZxdW90O00mcXVvdDsgYml0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WW91IGp1c3QgbmVlZCBvbmUgbW9yZSBsaXR0bGUg c3RlcCB0byBnZXQgZXZlcnl0aGluZyByaWdodCBoZXJlLCBpbnN0ZWFkIG9mIHRoaW5raW5nIG9m IGNvbXByb21pc2luZyB0aGUgaW1wbGVtZW50YXRpb248c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5KPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGF0IGlzLCByZWFkIHN1YmNsYXVzZSA3LjQuMi40 LjQgb2YgdGhlIEhFVkMgc3BlYy4gVGhlIG1vc3QgcmVsZXZhbnQgcGFyYWdyYXBocyBhcmUgY29w aWVkIGJlbG93IGZvciBjb252ZW5pZW5jZSAodGhlIGZpcnN0IHBhcmFncmFwaCBpdHNlbGYgY29u dGFpbnMgdGhlIGFuc3dlcg0KIHRvIHlvdXIgcXVlc3Rpb24sIGJ1dCB0aGUgc2Vjb25kIHBhcmFn cmFwaCBtYXkgYWxzbyBwcm92aWRlIGhlbHBmdWwgaW5mb3JtYXRpb24pPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhhbmtzIGZvciB0aGUgaW5mbzsgdGhhdCB3YXMgdXNlZnVsLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJlLCB0aGVuIGlzIHRo ZSB1cGRhdGVkIHRleHQgb2YgYSBwYXJhZ3JhcGggLSB0byBiZSBhZGRlZCBhZnRlciB0aGUgZXhp c3RpbmcgJ00gYml0JyB0ZXh0IC0gdGhhdCBjbGFyaWZpZXMgd2hlbi9ob3cgdG8gc2V0IGl0Ojxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlVuZm9ydHVuYXRlbHkgdGhlIGNvbnRlbnRzIG9mIGEgTkFMIHVuaXQsIGFsb25lLCBk byBub3QgdGVsbCBhIFJUUCBzZW5kZXIgaW1wbGVtZW50YXRpb24gd2hldGhlciBvciBub3QgdGhl IE5BTCB1bml0IGVuZHMgYW4gYWNjZXNzIHVuaXQuICZuYnNwO0luc3RlYWQsIHRoZSBpbXBsZW1l bnRhdGlvbiBtYXkgYmUgYWJsZSB0byBvYnRhaW4gdGhpcyBpbmZvcm1hdGlvbiBzZXBhcmF0ZWx5 LCBmcm9tIHRoZSBlbmNvZGVyLg0KICZuYnNwO0lmLCBob3dldmVyLCB0aGUgaW1wbGVtZW50YXRp b24gY2Fubm90IG9idGFpbiB0aGlzIGluZm9ybWF0aW9uIGRpcmVjdGx5IGZyb20gdGhlIGVuY29k ZXIgKGUuZy4sIGJlY2F1c2UgdGhlIGltcGxlbWVudGF0aW9uIGlzIHNlbmRpbmcgZGF0YSB0aGF0 IGNvbnNpc3RzIHNvbGVseSBvZiBhIHNlcXVlbmNlIG9mIHByZS1lbmNvZGVkIE5BTCB1bml0cyks IHRoZW4gaXQgbXVzdCBpbnN0ZWFkIGluc3BlY3Qgc3Vic2VxdWVudCBOQUwgdW5pdHMsIHRvDQog ZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IHRoZSBOQUwgdW5pdCBlbmRzIGFuIGFjY2VzcyB1bml0 LiAmbmJzcDtJZiB0aGUgTkFMIHVuaXRzIGhhdmUgYWxyZWFkeSBiZWVuIHRpbWVzdGFtcGVkLCB0 aGVuIHRoZXNlIHRpbWVzdGFtcHMgY2FuIGJlIHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSBhY2Nlc3Mg dW5pdCBib3VuZGFyaWVzLiAmbmJzcDtPdGhlcndpc2UsIHRoZSBhY2Nlc3MgdW5pdCBib3VuZGFy aWVzIChhbmQgdGltZXMpIG11c3QgYmUgZGV0ZXJtaW5lZCBieQ0KIGluc3BlY3RpbmcgdGhlIE5B TCB1bml0cycgY29udGVudHMgLSBzcGVjaWZpY2FsbHksIHRoZSAmcXVvdDtuYWxfdW5pdF90eXBl JnF1b3Q7IGFuZCAoZm9yIFZDTCBOQUwgdW5pdHMpIHRoZSAmcXVvdDtmaXJzdF9zbGljZV9zZWdt ZW50X2luX3BpY19mbGFnJnF1b3Q7LiAmbmJzcDtUaGUgZm9sbG93aW5nIHJ1bGUgY2FuIGJlIHVz ZWQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+Jm5ic3A7QSBOQUwgdW5pdCAoWCkgZW5k cyBhbiBhY2Nlc3MgdW5pdCBpZiB0aGUgbmV4dC1vY2N1cnJpbmcgVkNMIE5BTCB1bml0IChZKSBo YXMgdGhlIGhpZ2gtb3JkZXIgYml0IG9mIHRoZSBmaXJzdCBieXRlIGFmdGVyIGl0cyBOQUwgdW5p dCBoZWFkZXIgZXF1YWwgdG8gMSwgYW5kIGFsbCBOQUwgdW5pdHMsIGlmIGFueSwgYmV0d2VlbiAo WCkNCiBhbmQgKFkpIGhhdmUgYSAmcXVvdDtuYWxfdW5pdF90eXBlJnF1b3Q7IGluIG9uZSBvZiB0 aGUgZm9sbG93aW5nIHJhbmdlczogWzMyLDM1XSwgMzksIFs0MSw0NF0sIG9yIFs0OCw1NV0uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLS0t LS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Sb3NzIEZpbmxheXNvbjwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCjxzcGFuIGNsYXNz PSJhcHBsZS1zdHlsZS1zcGFuIj5MaXZlIE5ldHdvcmtzLCBJbmMuPC9zcGFuPjxicj4NCjxzcGFu IGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48YSBocmVmPSJodHRwOi8vd3d3LmxpdmU1NTUuY29t LyI+aHR0cDovL3d3dy5saXZlNTU1LmNvbS88L2E+PC9zcGFuPjwvc3Bhbj4NCjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpBdWRpby9WaWRlbyBUcmFu c3BvcnQgQ29yZSBNYWludGVuYW5jZTxicj4NCjxhIGhyZWY9Im1haWx0bzphdnRAaWV0Zi5vcmci PmF2dEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2F2dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9h dnQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_8BA7D4CEACFFE04BA2D902BF11719A833851364Fnasanexd02fnaqu_-- From ron.even.tlv@gmail.com Thu Aug 29 03:30:42 2013 Return-Path: X-Original-To: payload@ietfa.amsl.com Delivered-To: payload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D87221F9D0D for ; Thu, 29 Aug 2013 03:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukYcTNxzsFhR for ; Thu, 29 Aug 2013 03:30:42 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id C06A421F9CE3 for ; Thu, 29 Aug 2013 03:30:41 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hq12so263745wib.0 for ; Thu, 29 Aug 2013 03:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=l34rqeVUSffs98Afg9C4Spug1W9JnubM4hX8G5WqlVg=; b=ozL+/wB+ihg5i0dDP+fsPXM0m+NhixSVlv4wkFohXL1dF3EVWF+0EAbbeOTAK38gUo JI7AB3W8kc3y6l+4UJh/j0CnIhHrZPORpEuw+euDuO0TG85V5SGjxbVl+PpEmGBUUw4b gaYSSryRXH47s3k5rzJkgX3Ke1K982FlXvMdp1vFrmyiWRA8yXzySKst1pGsMtCqnLE0 GhGNbwdFV9HcQ9sS8mV8L5JLVXtKJ4QkHFCUt8whJjGJqc6MDrq40mdLXDsQ4AvJ0nIp P5xIsMKz/V1DfBAapR8Kf/b+yoH+nOrD4yHmZGPfMxGqDDdpAUqouAiLsktEGePJkk8W hi5g== X-Received: by 10.194.94.201 with SMTP id de9mr1536280wjb.78.1377772240932; Thu, 29 Aug 2013 03:30:40 -0700 (PDT) Received: from RoniE ([109.67.221.133]) by mx.google.com with ESMTPSA id i8sm11410056wib.1.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 29 Aug 2013 03:30:40 -0700 (PDT) From: "Roni Even" To: "'Harald Alvestrand'" , References: <51E6A4D9.30003@alvestrand.no> <957DBFE5-900D-44CB-BDE2-FB96BB83B3AE@iii.ca> <520B77F5.4000800@alvestrand.no> <520B7AEB.9080100@xiph.org> <520CE3D2.1070306@alvestrand.no> In-Reply-To: <520CE3D2.1070306@alvestrand.no> Date: Thu, 29 Aug 2013 13:28:10 +0300 Message-ID: <04d801cea4a2$77652e60$662f8b20$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEyAMYXfWpOJ4B5e4aB/j0C9vjRNgLbyv19ARHhAU4CHj+bogJ0dwyRAfipBKqakXp48A== Content-Language: en-us Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-09.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 10:30:42 -0000 Hi Harald, As individual I think this change make sense. H.264 has the level parameter and a default value for it. So having these two parameters as required or defining a default value if they are optional both work for. Roni > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf Of Harald Alvestrand > Sent: 15 August, 2013 5:21 PM > To: payload@ietf.org > Subject: Re: [payload] I-D Action: draft-ietf-payload-vp8-09.txt > > On 08/14/2013 02:41 PM, Timothy B. Terriberry wrote: > > Harald Alvestrand wrote: > >> These parameters were added because people on this list asked for > them. > >> So far, I do not think they have been added to any existing > >> implementation, and we don't seem to be seeing many interoperability > >> problems because of that. > >> > >> I don't think this is because of "luck". I think it's because these > >> are not the constraints that are the most constraining in most > >> practical situations - other constraints make sure we never reach the > >> limits that might have been encoded using max-fr and max-fs. > > > > I respectfully disagree. I think it's because implementations on > > resource-constrained mobile devices are still somewhat immature (ours > > certainly is). Earlier in this thread I pointed you to where we are > > adding support for these parameters for precisely this use-case. I > > thought we had agreement from the Chrome team that they would > support > > them as well (c.f. our WebRTC office hours call on June 10th, where I > > recall you saying something to the effect of, "If we put them in the > > spec, then we should support them."). If that is not the plan, then we > > have a problem. > > I fully think we should support them in our implementations (as in - parse > them and obey the constraints they imply). > > I just don't think we should, in the spec, mandate sending them. > > To be specific: The change I think Cullen is suggesting is: > > == OLD == > > Required parameters: none > > Optional parameters: > > max-fr, max-fs These parameters MAY be used to signal the > capabilities of a receiver implementation. These parameters > MUST NOT be used for any other purpose. > > > == NEW == > > Required parameters: > > max-fr, max-fs These parameters MUST be used to signal the > capabilities of a receiver implementation. These parameters > MUST NOT be used for any other purpose. > > Optional parameters: none > > == END == > > If that's not the change you're suggesting, Cullen, please clarify. > > (note: the MUST NOT language means that the parameters are not allowed > in a sendonly a=fmtp line, so they should probably be formally optional > anyway - either that, or my change proposal is incomplete.) > > > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload