From koen.vos@skype.net Sat May 1 01:01:08 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56B433A67D4 for ; Sat, 1 May 2010 01:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.751 X-Spam-Level: X-Spam-Status: No, score=-3.751 tagged_above=-999 required=5 tests=[AWL=-1.148, BAYES_50=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkutzGxhjq1D for ; Sat, 1 May 2010 01:01:05 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 21BE33A67B3 for ; Sat, 1 May 2010 01:01:04 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id D990F60133968; Sat, 1 May 2010 09:00:49 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=3NObJmBXQPBk 3vj5pwgE35Jyle4=; b=oxJaGJMeyHplcl/av+B8mgb3GmDd19V/OhDoZMg+gFhW B4sQn306LIbOkLBR0oCTqpsRI2tKoJ4ftUjf3L9PY6oUMQR0INKnvcitTZKg1Q3+ 5gpgV+mS3Vm9qed3lLOatqtxE8X0JuzKZeNmpqTPw2SQOvq761KkL2oRJE0nSOI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=WId7kVoh/hnXUFsEQhKM 034/2S2WO8Kamg5RqphnSP8ezvjFqF1HNQs9axpJn+1QkKu+6RJCb/1+be5jfeQ2 Kf4hhJSFtUeCwo4RnAgspcO2xboAC77+f5Yh6379PqMKqLW6wNRNBCy5c6orYmBn y7euD1dwUgfpkgyi0IG49Vs= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id D721760133967; Sat, 1 May 2010 09:00:49 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxJY54LEJ4we; Sat, 1 May 2010 09:00:47 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id D324060133911; Sat, 1 May 2010 09:00:47 +0100 (IST) Received: from adsl-71-141-115-202.dsl.snfc21.pacbell.net (adsl-71-141-115-202.dsl.snfc21.pacbell.net [71.141.115.202]) by mail.skype.net (Horde Framework) with HTTP; Sat, 01 May 2010 01:00:47 -0700 Message-ID: <20100501010047.65285zk6zval8ywf@mail.skype.net> Date: Sat, 01 May 2010 01:00:47 -0700 From: Koen Vos To: "Raymond (Juin-Hwey) Chen" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <20100423011559.20246ayxdicd9vzz@mail.skype.net> <20100425040049.69785q4ih4vowtep@mail.skype.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? (Bluetooth) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 08:01:08 -0000 Hi Raymond, I continue to fail to see the connection between the Internet codec =20 and Bluetooth, for the reasons below. (1) Bluetooth !=3D Internet: Bluetooth devices are wireless audio devices, not VoIP end points, and =20 are indeed used mostly for (mobile) PSTN calls. (2) Diverging requirements: A codec/mode that meets the BT requirements for ultra-low complexity =20 will have a relatively poor coding efficiency, resulting in lower =20 audio quality and/or a higher bitrate. Both of these negatively =20 impact the user experience over the Internet. Therefore, you do not =20 want to run a BT codec over the Internet if you can use a more =20 efficient codec instead. (3) Transcoding: Even when using a BT audio device, a well-designed VoIP end point will =20 always transcode between the Internet codec and the BT codec, because: a) the reason given in 2) above b) the BT device lacks the CPU power and memory to run the entire VoIP st= ack c) it allows for a packet-loss concealment operation in between two =20 lossy lags of the end-to-end connection. Note that such transcoding is also standard with DECT devices, where =20 base stations even transcode between G.722 and G.722 (yes: twice the =20 same codec). In short, there is no benefit from the BT and Internet codecs being =20 modes of one and the same codec. This complete lack of overlap means =20 that: I) it is better to standardize two separate codecs II) Bluetooth is out of scope for the Internet codec. best, koen. Quoting "Raymond (Juin-Hwey) Chen": > Hi Koen, > > For some reason the SPAM filter accidentally routed your email below =20 > (sent last Sunday) to my junk email folder and I just saw it. Sorry =20 > about the delay of my response. > > I agree that there are some fundamental differences in the =20 > requirements for cellular codecs and Bluetooth codecs which caused =20 > the codecs in these two types of devices to each go their own way. =20 > However, these differences are (or can be) substantially smaller =20 > between an Internet codec and Bluetooth codecs, so I think it is =20 > easier for Internet devices and Bluetooth devices to use the same =20 > codec to avoid the additional delay and coding distortion of =20 > transcoding. > > (1) Royalty-free requirement: > Cellular codecs are usually royalty-bearing, and that's acceptable =20 > in the cellular world. Not so with Bluetooth. Bluetooth devices =20 > are meant to be simple and low cost. As such, Bluetooth SIG =20 > basically only wants to standardize royalty-free technologies. =20 > That's an important reason why they picked the CVSD codec, a =20 > royalty-free old technology of 1970. We are trying to make the IETF =20 > codec royalty-free, so in this regard this goal is consistent with =20 > the Bluetooth SIG's royalty-free requirement for codec. > > (2) Bit-rate requirement: > Cellular radio spectrum is a limited, fixed resource that doesn't =20 > change with time, and cellular operators spent billions of dollars =20 > in radio spectrum auctions. Thus, it is extremely important for =20 > cellular codecs to have bit-rates as low as possible, with an =20 > average bit-rate often going below 1 bit/sample, to maximize the =20 > number of cellular subscribers a given amount of radio spectrum can =20 > support. In contrast, the bit-rate is not nearly as big a concern =20 > for Bluetooth. Initially Bluetooth SIG picked the relatively =20 > high-bit-rate 64 kb/s CVSD narrowband codec (8 bits/sample) for its =20 > simplicity and royalty-free nature among other things. Since the =20 > speeds of the Internet back bone and access networks keep growing =20 > with time, the bit-rate of an Internet codec is also not nearly as =20 > big a concern as in cellular codecs, and an Internet codec around 2 =20 > bits/sample can have better trade-offs (e.g. higher quality, lower =20 > delay, and lower complexity) for Internet applications than what =20 > cellular codecs can provide. Incidentally, Bluetooth SIG is moving =20 > toward 4 bits/sample. As you can see, in terms of the bit-rate =20 > requirement, an Internet codec is much closer to Bluetooth codecs =20 > than cellular codecs are. > > (3) Complexity requirement: > Bluetooth headsets have much lower processing power and much smaller =20 > batteries than cell phones. The complexity of cellular codecs, =20 > typically in the range of 20 to 40 MHz on a DSP, is too high to fit =20 > most Bluetooth headsets. However, unlike cell phones and Bluetooth =20 > headsets where each is a specific type of device with a relatively =20 > narrow range of device complexity, Internet voice/audio applications =20 > can potentially encompass a large variety of different device types, =20 > from desktop computers at the high end with > 3 GHz multi-core CPU =20 > to IP phones and possibly even Bluetooth headsets at the low end =20 > with a processor of only a few tens of MHz. It is up to the IETF =20 > codec WG how we want the complexity of the IETF codec to be. We can =20 > standardize just one codec mode that works well for =20 > computer-to-computer calls but can't fit in low-end devices, or we =20 > can keep that mode but also have a low-complexity mode that can be =20 > implemented in low-end devices. Frankly, I think the second =20 > approach makes much more sense since it allows many more devices to =20 > benefit from the IETF codec and enables the large number of =20 > Bluetooth headset users to avoid the additional distortion and delay =20 > associated with transcoding when making Internet calls. > > (4) Delay requirement: Due to the need for cellular codecs to =20 > achieve bit-rates as low as possible, they sacrificed the coding =20 > delay and used a 20 ms frame size, because using a 10 or 5 ms frame =20 > size would increase the bit-rate for a given level of speech =20 > quality. On the other hand, a Bluetooth headset needs to have a low =20 > delay since its delay is added to the already long cell phone delay. =20 > For the IETF codec, again it is up to the codec WG to decide what =20 > kind of codec delay we want, and again I think it makes sense to =20 > have a higher-delay, higher bit-rate efficiency mode for =20 > bit-rate-sensitive applications and another low-delay mode for =20 > delay-sensitive applications, since one size doesn't fit all. If =20 > the IETF codec delay is forced to be one size, the resulting codec =20 > will be (potentially very) suboptimal for some applications. > > You wrote: >> Do you think it's realistic for us to come up with a design that >> fulfills the needs of both worlds? > > With a one-size-fit-all approach, probably not, but with a =20 > multi-mode approach, then I think so. > > Best Regards, > > Raymond > > -----Original Message----- > From: Koen Vos [mailto:koen.vos@skype.net] > Sent: Sunday, April 25, 2010 4:01 AM > To: Raymond (Juin-Hwey) Chen > Cc: codec@ietf.org > Subject: RE: [codec] #16: Multicast? (Bluetooth) > > Hi Raymond, > > You seem to suggest that the IETF Internet codec should fit Bluetooth > requirements in order to enable transcoding-free operation all the way > from the Internet, through the Internet-connected device, to the BT > wireless audio device. > > A similar argument would hold for ITU-T cellular codecs: AMR-WB and > G.718 could have been designed with BT as an application. In reality, > these codecs have very little in common with BT codecs, because of the > vastly different requirements in terms of > - complexity > - memory footprint > - bitrate > - scalability > - bit error robustness > - packet loss robustness. > > Do you think it's realistic for us to come up with a design that > fulfills the needs of both worlds? > > The alternative is to separately design codecs for Internet > applications and BT devices, and continue the practice of transcoding > on the Internet-connected device. That would have a better chance of > maximizing quality in all scenarios. > > best, > koen. > > > Quoting "Raymond (Juin-Hwey) Chen": > >> Hi Koen, >> >> Responding to your earlier email about Bluetooth headset application: >> >> (1) Although BT SIG standardization is a preferred route, it is >> technically feasible to negotiate and use a non-Bluetooth-SIG codec. >> >> (2) Someone familiar with BT SIG told me that it would probably take >> only 6 months to add an optional codec to the BT SIG spec and 12 to >> 18 months to add a mandatory codec. >> >> (3) The IETF codec is scheduled to be finalized in 14 months and >> submitted to IESG in 18 months. Even if we take the BT SIG route >> and take 6 to 18 months there. The total time of 2 to 3 years from >> now means the Moore's Law would only increase the CPU resources 2X >> to 3X, and definitely no more than 4X max, not 10X. >> >> (4) Most importantly, guess what, in the last several years the >> Bluetooth headset chips have been growing its processing power at a >> MUCH, MUCH slower rate than what the Moore's Law says it should. >> Sometimes they did not increase the speed at all for years. The >> reasons? The ASP (average sale price) of Bluetooth chips plummeted >> very badly, making it unattractive to invest significant resources >> to make them significantly faster. Also, for low-end and mid-end BT >> headsets, the BT chips were often considered "good enough" and there >> wasn't a strong drive to increase the computing resources. In >> addition, the BT headsets got smaller over the last few years; the >> corresponding reduction in battery size required a reduction in >> power consumption, which also limited how fast the processor speed >> could grow. In the next several years, it is highly likely that the >> computing capabilities of Bluetooth headset chips will continue to >> grow at a rate substantially below what's predicted by the Moore's >> Law. >> >> (5) Although Bluetooth supports G.711 as an optional codec, >> basically no one uses it because it is too sensitive to bit errors. >> Essentially all the BT mono headsets on the market today are >> narrowband (8 kHz sampling) headsets using CVSD. There isn't any >> real wideband support yet, so your comment about G.722 doesn't >> apply. Even after wideband-capable BT headsets come out, for many >> years to come the majority of the BT headsets (especially mid- to >> low-end) will still be narrowband only, running only CVSD. Hence, >> the quality degradation of the CVSD transcoding is real and will be >> with us for quite a while, so it is desirable for the IETF codec to >> have a low-complexity mode that can directly run on the BT headsets >> to avoid the quality degradation of CVSD when using BT headsets to >> make Internet phone calls. >> >> (6) Even if you could use G.711 or G.722 in the BT headsets, they >> both operate at 64 kb/s. A low-complexity mode of the IETF codec >> can operate at half or one quarter of that bit-rate. This will help >> conserve BT headsets' radio power because of the lower transmit duty >> cycle. It will also help the Bluetooth + WiFi co-existence >> technologies. >> >> (7) Already a lot of people are used to using Bluetooth headsets to >> make phone calls today. If they have a choice, many of these people >> will also want to use Bluetooth headsets to make Internet phone >> calls, not only through computers, but also through smart phones >> connected to WiFi or cellular networks. As more and more states and >> countries pass laws to ban the use of cell phones that are not in >> hands-free mode while driving, the number of Bluetooth headset users >> will only increase with time, and many of them will want to make >> Internet-based phone calls. >> >> Given all the above, I would argue that Bluetooth headset is a very >> relevant application that the IETF codec should address with a >> low-complexity mode. >> >> Best Regards, >> >> Raymond >> >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On >> Behalf Of Koen Vos >> Sent: Friday, April 23, 2010 1:16 AM >> To: codec@ietf.org >> Subject: Re: [codec] #16: Multicast? >> >> By the time the BlueTooth Special Interest Group will have adopted a >> future IETF codec standard, Moore's law will surely have multiplied >> CPU resources in the BT device by one order of magnitude..? Not sure >> it makes sense to apply today's BT constraints to tomorrow's codec. >> >> I'm not even convinced BlueTooth is a relevant use case for an >> Internet codec. BT devices are audio devices more than VoIP end >> points: BT always connects to the Internet through another device. >> You could simply first decode incoming packets and send PCM data to >> the BT device, or use a high-quality/high-bitrate codec like G.722. >> The requirements for BT devices and the Internet are just too >> different. Similarly, GSM phones use AMR on the network side and a >> different codec towards the BT device. The required transcoding >> causes no quality problems because BT supports high bitrates. >> >> best, >> koen. >> >> >> Quoting Raymond (Juin-Hwey) Chen: >> >>> Hi Christian, >>> >>> My comments about your question of CODEC requirements are in-line. >>> >>> Raymond >>> >>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On >>> Behalf Of Christian Hoene >>> Sent: Wednesday, April 21, 2010 12:27 PM >>> To: 'stephen botzko' >>> Cc: codec@ietf.org >>> Subject: Re: [codec] #16: Multicast? >>> >>> Hi, >>> >>> if we take those two scenarios (high quality and scalable >>> teleconferencing), what are then the CODEC requirements? >>> >>> High quality: >>> >>> - Quite the same requirement as an end-to-end audio >>> transmission: high quality and low latency. >>> [Raymond]: High quality is a given, but I would like to emphasize >>> the importance of low latency. >>> (1) It is well-known that the longer the latency, the lower the >>> perceived quality of the communication link. The E-model in the >>> ITU-T Recommendation G.107 models such communication quality in >>> MOS_cqe, which among other things depends on the so-called "delay >>> impairment factor" Id. Basically, MOS_cqe is a monotonically >>> decreasing function of increasing latency, and beyond about 150 ms >>> one-way delay, the perceived quality of the communication link drops >>> rapidly with further delay increase. >>> (2) The lower the latency, the less audible the echo, and thus the >>> lower the required echo return loss. Hence, lower latency means >>> easier echo control and simpler echo canceller, and as people >>> already mentioned previously, below a certain delay, an echo is >>> simply perceived as a harmless side-tone and no echo canceller is >>> needed. It seems to me that echo control in conference calls is more >>> difficult than in point-to-point calls. While I hardly ever heard >>> echoes in domestic point-to-point calls, in my experience with >>> conference calls at work, even with the G.711 codec (which has >>> almost no delay), sometimes I still hear echoes (I just heard >>> another one this afternoon). If a relatively long-delay IETF codec >>> is used, the echo control will be even more problematic. >>> (3) In normal phone calls or conference calls, people routinely have >>> a need to interrupt each other, but beyond a certain point, long >>> latency makes it very difficult for people to interrupt each other >>> on the call. This is because when you try to interrupt another >>> person, that person doesn't hear your interruption until a certain >>> time later, so he keeps talking, but when you hear that he did not >>> stop talking when you interrupted, you stop; then, he hears your >>> interruption, so he stops. When you hear he stops, you start talking >>> again, but then he also hears you stopped (due to the long delay), >>> so he also starts talking again. The net result is that with a long >>> latency, when you try to interrupt him, you and he end up stopping >>> and starting at roughly the same time for a few cycles, making it >>> difficult to interrupt each other. >>> (4) We need to keep in mind that the IETF codec may not be the only >>> codec involved in a phone call or a conference call. We cannot >>> assume that all conference call participants will be using a >>> computer to conduct the call. Not only do people use cell phones for >>> point-to-point phone calls, they also often use cell phones to call >>> in to conference calls. The one-way delay for a cell phone call >>> through one carriers network is typically around 80 to 110 ms. A >>> call from a cell phone in a carrier network to another cell phone in >>> a different type of carrier network can easily double this delay to >>> 160 ~ 220 ms and makes the total one-way delay already far exceeding >>> the 150 ms mentioned in (1) above. Any coding delay added by the >>> IETF codec will be on top of that long delay, and such coding delay >>> will be applied twice when both cell phones call through the IETF >>> codec to a conference bridge. Even without the IETF codec delay, >>> when I previously called from a Verizon cell phone to an AT&T cell >>> phone, I already experienced the problem mentioned in (3) sometimes. >>> If the IETF codec has a relatively long delay, adding two times the >>> IETF codec one-way delay to the already long delay of 160 ~ 220 ms >>> will make the situation much worse. Even if just one cell phone is >>> involved in a conference call, adding twice the one-way delay of a >>> relatively long-delay IETF codec can still easily push the total >>> one-way delay beyond 150 ms. >>> To summarize, my point is that to help reduce potential echo >>> problems and to ensure a high-quality experience in such a >>> conference call, the IETF codec should have a delay as low as >>> possible while maintaining good enough speech quality and a >>> reasonable bit-rate. >>> >>> - Maybe additionally: variable bit rate encoding to achieve >>> a multiplexing gain at the receiver >>> >>> - and thus, a fast control loop to cope with variable >>> bitrates on transmission paths. >>> >>> - Maybe stereo/multichannel support to send the spatial >>> audio to the headphone or loudspeakers. >>> >>> Scalable: >>> >>> - Efficient encoding/transcoding for multiple different >>> qualities (at the conference bridge) >>> [Raymond]: I am not sure whether by "efficient", you meant coding >>> efficiency or computational efficiency. In any case, I would like >>> to take this opportunity to express my view that although codec >>> complexity isn't much of an issue for PC-to-PC calls where there are >>> GHz of processing power available, the codec complexity is an >>> important issue in certain application scenarios. The following are >>> just some examples. >>> 1) If a conference bridge has to decode a large number of voice >>> channels, mix, and re-encode, and if compressed-domain mixing cannot >>> be done (which is usually the case), then it is important to keep >>> the decoder complexity low. >>> 2) In topology b) of your other email >>> (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, >>> or VoIP gateway, often has to encode and decode thousands of voice >>> channels in a single box, so not only the computational complexity, >>> but also the per-instance RAM size requirement of the codec become >>> very important for achieving high channel density in the gateway. >>> 3) Many telephone terminal devices at the edge of the Internet use >>> embedded processors with limited processing power, and the >>> processors also have to handle many tasks other than speech coding. >>> If the IETF codec complexity is too high, some of such devices may >>> not have sufficient processing power to run it. Even if the codec >>> can fit, some battery-powered mobile devices may prefer to run a >>> lower-complexity codec to reduce power consumption and battery >>> drain. For example, even if you make a Internet phone call from a >>> computer, you may like the convenience of using a Bluetooth headset >>> that allows you to walk around a bit and have hands-free operation. >>> Currently most Bluetooth headsets have small form factors with a >>> tiny battery. This puts a severe constraint on power consumption. >>> Bluetooth headset chips typically have very limited processing >>> capability, and it has to handle many other tasks such as echo >>> cancellation and noise reduction. There is just not enough >>> processing power to handle a relatively high-complexity codec. Most >>> BT headsets today relies on the extremely low-complexity, >>> hardware-based CVSD codec at 64 kb/s to transmit narrowband voice, >>> but CVSD has audible coding noise, so it degrades the overall audio >>> quality. If the IETF codec has low enough complexity, it would be >>> possible to directly encode and decode the IETF codec bit-stream at >>> the BT headset, thus avoiding the quality degradation of CVSD >>> transcoding. >>> In summary, my point is that the IETF codec should attempt to >>> achieve a codec complexity as low as possible in both MHz >>> consumption and RAM size requirement while maintaining good enough >>> speech quality. >>> >>> - The control loop must not react (fast) because >>> (multicast) group communication requires to encode at low quality >>> anyhow. >>> >>> - Receiver side activity detection for music and voice >>> having low complexity (for the conference bridge) >>> >>> - Efficient mixing of two to four(?) active flows (is this >>> achievable without the complete process of decoding and encoding >>> again?) >>> >>> Are any teleconferencing requirements missing? >>> >>> Christian >>> >>> >>> >>> >>> --------------------------------------------------------------- >>> Dr.-Ing. Christian Hoene >>> Interactive Communication Systems (ICS), University of T=FCbingen >>> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >>> http://www.net.uni-tuebingen.de/ >>> >>> From: stephen botzko [mailto:stephen.botzko@gmail.com] >>> Sent: Wednesday, April 21, 2010 8:19 PM >>> To: Christian Hoene >>> Cc: codec@ietf.org >>> Subject: Re: [codec] #16: Multicast? >>> >>> Inline >>> On Wed, Apr 21, 2010 at 1:27 PM, Christian Hoene >>> > wrote: >>> Hi Stephen, >>> >>> not too bad. You answered faster than the mailing list distributes... >>> Not sure how that happened! >>> >>> Comments inline: >>> >>> >>> From: stephen botzko >>> [mailto:stephen.botzko@gmail.com] >>> Sent: Wednesday, April 21, 2010 7:10 PM >>> To: Christian Hoene >>> Cc: codec@ietf.org >>> >>> Subject: Re: [codec] #16: Multicast? >>> >>> I agree there are lots of use cases. >>> >>> >>> Though I don't see why high quality has to be given up in order to >>> be scalable. >>> CH: These are just experiences from our lab. A spatial audio >>> conference server including the acoustic 3D sound rendering needs a >>> LOT of processing power. In the end, we have to remain realistic. >>> Processing power is always limited thus if we need a lot then we >>> cannot serve many clients. >>> Also, I am not sure why you think central mixing is more scalable >>> than multicast (or why you think it is lower quality either). >>> CH: With multicast, you need N times 1:N multicast distribution >>> trees (somewhat small tan O(n)=3Dn=B2). With central mixing you need N >>> times 2 transmission paths (O(n)=3Dn). Also, this distributed mixing >>> you need N times the mixing at each client. With centralized, you >>> can live with one mixing for all (and some tricks for serving the >>> talkers). >>> I agree you need more distribution trees for multicast if you allow >>> every site to talk. There is a corresponding benefit, since there is >>> no central choke point and also less bandwidth on shared WAN links. >>> >>> In the distributed case, you don't need an N-way mixer at each >>> client, and you also don't need to continuously receive payload on >>> all N streams at each client either. In practice you can cap N at a >>> relatively small number (in the 3-8 range) no matter how large the >>> conference gets. In a large conference, you can even choose to drop >>> your comfort noise if you are receiving two or more streams, and >>> just send enough to keep your firewall pinhole open. This is all >>> assuming a suitable voice activity measure in the RTP packet. Of >>> course in the worst case, you will receive all N streams. >>> >>> Cheers, >>> Christian >>> >>> Stephen Botzko >>> On Wed, Apr 21, 2010 at 12:58 PM, Christian Hoene >>> > wrote: >>> Hi, >>> >>> the teleconferencing issue gets complex. I am trying to compile the >>> different requirements that have been mentioned on this list. >>> >>> - low complexity (with just one active speaker) vs. >>> multiple speaker mixing vs. spatial audio/stereo mixing >>> >>> - centralized vs. distributed >>> >>> - few participants vs. hundreds of listeners and talkers >>> >>> - individual distribution of audio streams vs. IP multicast >>> or RTP group communication >>> >>> - efficient encoding of multiple streams having the same >>> content (but different quality). >>> >>> - I bet I missed some. >>> >>> To make things easier, why not to split the teleconferencing >>> scenario in two: High quality and Scalable? >>> >>> The high quality scenario, intended for a low number of users, could >>> have features like >>> >>> - Distributed processing and mixing >>> >>> - High computational resources to support spatial audio >>> mixing (at the receiver) and multiple encodings of the same audio >>> stream at different qualities (at the sender) >>> >>> - Enough bandwidth to allow direct N to N transmissions of >>> audio streams (no multicast or group communication). This would be >>> good for the latency, too. >>> >>> The scalable scenario is the opposite: >>> >>> - Central processing and mixing for many participants . >>> >>> - N to 1 and 1 to N communication using efficient >>> distribution mechanisms (RTP group communication and IP multicast). >>> >>> - Low complexity mixing of many using tricks like VAD, >>> encoding at lowest rate to support many receivers having different >>> paths, you name it... >>> >>> Then, we need not to compare apples with oranges all the time. >>> >>> Christian >>> >>> --------------------------------------------------------------- >>> Dr.-Ing. Christian Hoene >>> Interactive Communication Systems (ICS), University of T=FCbingen >>> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >>> http://www.net.uni-tuebingen.de/ >>> >>> From: codec-bounces@ietf.org >>> [mailto:codec-bounces@ietf.org] On >>> Behalf Of stephen botzko >>> Sent: Wednesday, April 21, 2010 4:34 PM >>> To: Colin Perkins >>> Cc: trac@tools.ietf.org; >>> codec@ietf.org >>> Subject: Re: [codec] #16: Multicast? >>> >>> in-line >>> >>> Stephen Botzko >>> On Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins >>> > wrote: >>> On 21 Apr 2010, at 12:20, Marshall Eubanks wrote: >>> On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote: >>> On 21 Apr 2010, at 10:42, codec issue tracker wrote: >>> #16: Multicast? >>> ------------------------------------+---------------------------------- >>> Reporter: hoene@... | Owner: >>> Type: enhancement | Status: new >>> Priority: trivial | Milestone: >>> Component: requirements | Version: >>> Severity: Active WG Document | Keywords: >>> ------------------------------------+---------------------------------- >>> The question arrose whether the interactive CODEC MUST support >>> multicast in addition to teleconferencing. >>> >>> On 04/13/2010 11:35 AM, Christian Hoene wrote: >>> P.S. On the same note, does anybody here cares about using this >>> CODEC with multicast? Is there a single commercial multicast voice >>> deployment? From what I've seen all multicast does is making IETF >>> voice standards harder to understand or implement. >>> >>> I think that would be a mistake to ignore multicast - not because of >>> multicast itself, but because of Xcast (RFC 5058) which is a >>> promising technology to replace centralized conference bridges. >>> >>> Regarding multicast: >>> >>> I think we shall start at user requirements and scenarios. >>> Teleconference (including mono or spatial audio) might be good >>> starting point. Virtual environments like second live would require >>> multicast communication, too. If the requirements of these scenarios >>> are well understand, we can start to talk about potential solutions >>> like IP multicast, Xcast or conference bridges. >>> >>> >>> RTP is inherently a group communication protocol, and any codec >>> designed for use with RTP should consider operation in various >>> different types of group communication scenario (not just >>> multicast). RFC 5117 is a good place to start when considering the >>> different types of topology in which RTP is used, and the possible >>> placement of mixing and switching functions which the codec will >>> need to work with. >>> >>> It is not clear to me what supporting multicast would entail here. >>> If this is a codec over RTP, then what is to stop it from being >>> multicast ? >>> >>> Nothing. However group conferences implemented using multicast >>> require end system mixing of potentially large numbers of active >>> audio streams, whereas those implemented using conference bridges do >>> the mixing in a single central location, and generally suppress all >>> but one speaker. The differences in mixing and the number of >>> simultaneous active streams that might be received potentially >>> affect the design of the codec. >>> >>> Conference bridges with central mixing almost always mix multiple >>> speakers. As you add more streams into the mix, you reduce the >>> chance of missing onset speech and interruptions, but raise the >>> noise floor. So even if complexity is not a consideration, there is >>> value in gating the mixer (instead of always doing a full mix-minus). >>> >>> More on point, compressed domain mixing and easy detection of VAD >>> have both been advocated on these lists, and both simplify the >>> large-scale mixing problem. >>> >>> -- >>> Colin Perkins >>> http://csperkins.org/ >>> >>> >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>> >>> >>> >>> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> >> > > > > From trac@tools.ietf.org Sat May 1 02:47:42 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 706303A6ABE for ; Sat, 1 May 2010 02:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.21 X-Spam-Level: X-Spam-Status: No, score=-101.21 tagged_above=-999 required=5 tests=[AWL=-1.210, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+CgvPGfGOwF for ; Sat, 1 May 2010 02:47:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C42D33A67D3 for ; Sat, 1 May 2010 02:47:41 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O89IF-0003kL-47; Sat, 01 May 2010 02:47:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sat, 01 May 2010 09:47:27 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/13#comment:2 Message-ID: <071.791205ca9a47bcee1ebf5d2f98d94214@tools.ietf.org> References: <062.407382d901e5e6b8dea15d6e3ae1a2c8@tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <062.407382d901e5e6b8dea15d6e3ae1a2c8@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #13: reference use-cases and topologies! X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 09:47:42 -0000 #13: reference use-cases and topologies! ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: critical | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Christian]: At least use usages were mentioned previously: a) removing the need for echo cancelation because of ultra-low delay, when echoes are called side tones... b) Push-to-talk With are the topologies under study? a) IPend-to-IPend? b) IPend-to-transcoding_gateway-to-PSTNend? c) n to n (decentralized conferencing) e) IPend-to-legal_interception-to-X [Slava]: Henry, e2e (or p2p) is cool but what about Legal interception for example in this case, which every cellco has to implemenet? [Benjamin]: Whether or not we want to encourage it, interception of VoIP traffic does not require a re-encode. The encoded packets can just be copied to the additional receiver. [Cullen]: RFC 2804 [legal interception is out of scope] -- Ticket URL: codec From stephen.botzko@gmail.com Sat May 1 03:06:03 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47B543A6802 for ; Sat, 1 May 2010 03:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IovpCyVIrCXl for ; Sat, 1 May 2010 03:05:58 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 00EC03A67D3 for ; Sat, 1 May 2010 03:05:57 -0700 (PDT) Received: by wyb35 with SMTP id 35so732760wyb.31 for ; Sat, 01 May 2010 03:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=hkCISWz4xvzZcwHh60s+esrNXEbOwgwxwNm+87+uUwY=; b=OYYM5Qe6MP11+HTah8kyZtq9knlbbHBMnhX3R/XCqYaUhjXv/x+TIU4/7Ypvwj7uVL 1/gccZmbjatjU0LPeeZdvO9zRY4YHdBXPko+7Vw3WELepgyKY3Z8nHspGDBOR9uIpvAC X2dp7iu2DF5Z03rtMIdk4psE9oUhQGxWPuA1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=siBzaM2QuJI6hdyjR/AkGGOLdpdcrSh95x35wUsptwj1+keh3OngmB+nC62RfeYdT6 4UPkkc7+ksadS55zwYxQ3CN3iTR/59S71otkBT4RpfxLMwh98LTMQbogrXA1BANM+os/ JWfr1Pv+Tb44PNIgsfT97eQz6oEYOHRSt6xzQ= MIME-Version: 1.0 Received: by 10.216.90.4 with SMTP id d4mr3707264wef.135.1272708339978; Sat, 01 May 2010 03:05:39 -0700 (PDT) Received: by 10.216.28.139 with HTTP; Sat, 1 May 2010 03:05:39 -0700 (PDT) In-Reply-To: <071.791205ca9a47bcee1ebf5d2f98d94214@tools.ietf.org> References: <062.407382d901e5e6b8dea15d6e3ae1a2c8@tools.ietf.org> <071.791205ca9a47bcee1ebf5d2f98d94214@tools.ietf.org> Date: Sat, 1 May 2010 06:05:39 -0400 Message-ID: From: stephen botzko To: codec@ietf.org Content-Type: multipart/alternative; boundary=0016e6d6481581d17b04858580e8 Subject: Re: [codec] #13: reference use-cases and topologies! X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 10:06:03 -0000 --0016e6d6481581d17b04858580e8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Surely centralized conferencing is an important use case. Stephen Botzko On Sat, May 1, 2010 at 5:47 AM, codec issue tracker wr= ote: > #13: reference use-cases and topologies! > > ------------------------------------+------------------------------------= --- > Reporter: hoene@=85 | Owner: > Type: defect | Status: new > Priority: critical | Milestone: > Component: requirements | Version: > Severity: Active WG Document | Keywords: > > ------------------------------------+------------------------------------= --- > > Comment(by hoene@=85): > > [Christian]: > At least use usages were mentioned previously: > a) removing the need for echo cancelation because of ultra-low delay, wh= en > echoes are called side tones... > b) Push-to-talk > > With are the topologies under study? > a) IPend-to-IPend? > b) IPend-to-transcoding_gateway-to-PSTNend? > c) n to n (decentralized conferencing) > e) IPend-to-legal_interception-to-X > [Slava]: Henry, e2e (or p2p) is cool but what about Legal interception f= or > example in this case, which every cellco has to implemenet? > [Benjamin]: Whether or not we want to encourage it, interception of VoIP > traffic does not require a re-encode. The encoded packets can just be > copied to the additional receiver. > [Cullen]: RFC 2804 [legal interception is out of scope] > > -- > Ticket URL: > codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016e6d6481581d17b04858580e8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Surely centralized conferencing is an important use case.

Stephen Bo= tzko

On Sat, May 1, 2010 at 5:47 AM, code= c issue tracker <trac@tools.ietf.org> wrote:
#13: reference use-cases and topologies!
------------------------------------+--------------------------------------= -
=A0Reporter: =A0hoene@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Own= er:
=A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0St= atus: =A0new
=A0Priority: =A0critical =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Milestone: Component: =A0requirements =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
=A0Severity: =A0Active WG Document =A0 =A0 =A0| =A0 =A0Keywords:
------------------------------------+--------------------------------------= -

Comment(by hoene@=85):

=A0[Christian]:
=A0At least use usages were mentioned previously:
=A0a) removing the need for echo cancelation because of ultra-low delay, wh= en
=A0echoes are called side tones...
=A0b) Push-to-talk

=A0With are the topologies under study?
=A0a) IPend-to-IPend?
=A0b) IPend-to-transcoding_gateway-to-PSTNend?
=A0c) n to n (decentralized conferencing)
=A0e) IPend-to-legal_interception-to-X
=A0[Slava]: Henry, e2e (or p2p) is cool but what about Legal intercep= tion for
=A0example in this case, which every cellco has to implemenet?
=A0[Benjamin]: Whether or not we want to encourage it, interception of VoIP=
=A0traffic does not require a re-encode. =A0The encoded packets can just be=
=A0copied to the additional receiver.
=A0[Cullen]: RFC 2804 [legal interception is out of scope]

--
Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ti= cket/13#comment:2>
codec <http://tools.ietf.org/codec/>

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--0016e6d6481581d17b04858580e8-- From trac@tools.ietf.org Sat May 1 03:44:34 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C79E73A6AD2 for ; Sat, 1 May 2010 03:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.206 X-Spam-Level: X-Spam-Status: No, score=-101.206 tagged_above=-999 required=5 tests=[AWL=-1.206, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8K3JXLZG5-di for ; Sat, 1 May 2010 03:44:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D78E73A67F6 for ; Sat, 1 May 2010 03:44:33 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8ABH-00021R-69; Sat, 01 May 2010 03:44:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sat, 01 May 2010 10:44:19 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/3#comment:1 Message-ID: <071.5c139aff3b600414066c330b20c0e191@tools.ietf.org> References: <062.a837f2ff7647f7cb184f0c86b7e65747@tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <062.a837f2ff7647f7cb184f0c86b7e65747@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #3: 2.2. Conferencing: Support of binaural audio? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 10:44:34 -0000 #3: 2.2. Conferencing: Support of binaural audio? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Hoene]: I am trying to compile the different requirements that have been mentioned on this list. - low complexity (with just one active speaker) vs. multiple speaker mixing vs. spatial audio/stereo mixing - centralized vs. distributed - few participants vs. hundreds of listeners and talkers - individual distribution of audio streams vs. IP multicast or RTP group communication - efficient encoding of multiple streams having the same content (but different quality). To make things easier, why not to split the teleconferencing scenario in two: High quality and Scalable? The high quality scenario, intended for a low number of users, could have features like - Distributed processing and mixing - High computational resources to support spatial audio mixing (at the receiver) and multiple encodings of the same audio stream at different qualities (at the sender) - Enough bandwidth to allow direct N to N transmissions of audio streams (no multicast or group communication). This would be good for the latency, too. The scalable scenario is the opposite: - Central processing and mixing for many participants . - N to 1 and 1 to N communication using efficient distribution mechanisms (RTP group communication and IP multicast). - Low complexity mixing of many using tricks like VAD, encoding at lowest rate to support many receivers having different paths, you name it... High quality: - Quite the same requirement as an end-to-end audio transmission: high quality and low latency. - Maybe additionally: variable bit rate encoding to achieve a multiplexing gain at the receiver - and thus, a fast control loop to cope with variable bitrates on transmission paths. - Maybe stereo/multichannel support to send the spatial audio to the headphone or loudspeakers. Scalable: - Efficient encoding/transcoding for multiple different qualities (at the conference bridge) - The control loop must not react (fast) because (multicast) group communication requires to encode at low quality anyhow. - Receiver side activity detection for music and voice having low complexity (for the conference bridge) - Efficient mixing of two to four(?) active flows (is this achievable without the complete process of decoding and encoding again?) [Raymond]: High quality is a given, but I would like to emphasize the importance of low latency. (1) It is well-known that the longer the latency, the lower the perceived quality of the communication link. [...] (2) The lower the latency, the less audible the echo, and thus the lower the required echo return loss. Hence, lower latency means easier echo control and simpler echo canceller, and as people already mentioned previously, below a certain delay, an echo is simply perceived as a harmless side-tone and no echo canceller is needed. It seems to me that echo control in conference calls is more difficult than in point-to-point calls. While I hardly ever heard echoes in domestic point-to-point calls, in my experience with conference calls at work, even with the G.711 codec (which has almost no delay), sometimes I still hear echoes (I just heard another one this afternoon). If a relatively long-delay IETF codec is used, the echo control will be even more problematic. (3) In normal phone calls or conference calls, people routinely have a need to interrupt each other, but beyond a certain point, long latency makes it very difficult for people to interrupt each other on the call. This is because when you try to interrupt another person, that person doesn’t hear your interruption until a certain time later, so he keeps talking, but when you hear that he did not stop talking when you interrupted, you stop; then, he hears your interruption, so he stops. When you hear he stops, you start talking again, but then he also hears you stopped (due to the long delay), so he also starts talking again. The net result is that with a long latency, when you try to interrupt him, you and he end up stopping and starting at roughly the same time for a few cycles, making it difficult to interrupt each other. [Jean-Marc:] The decoder complexity is very important. Not only because of mixing issue, but also because the decoder is generally not allowed to take shortcuts to save on complexity (unlike the encoder). As for compressed- domain mixing, as you say it is not always available, but *if* we can do it (even if only partially), then that can result in a "free" reduction in decoder complexity for mixing. -- Ticket URL: codec From trac@tools.ietf.org Sat May 1 03:45:21 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF3823A6AD2 for ; Sat, 1 May 2010 03:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ogiCCXQ-66S for ; Sat, 1 May 2010 03:45:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 36EAA3A67F6 for ; Sat, 1 May 2010 03:45:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8AC3-00022o-HZ; Sat, 01 May 2010 03:45:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sat, 01 May 2010 10:45:07 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/codec/trac/ticket/18 Message-ID: <062.d51439b68d5cdc7daff30cac51ddab04@tools.ietf.org> X-Trac-Ticket-ID: 18 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #18: Frame Sizes X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 10:45:21 -0000 #18: Frame Sizes ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Which frame size(s) shall the CODEC support? -- Ticket URL: codec From trac@tools.ietf.org Sat May 1 03:46:42 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66C323A6AD2 for ; Sat, 1 May 2010 03:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8vcJBEDReYZ for ; Sat, 1 May 2010 03:46:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BC1283A67F6 for ; Sat, 1 May 2010 03:46:41 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8ADM-0002sa-2W; Sat, 01 May 2010 03:46:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sat, 01 May 2010 10:46:28 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/codec/trac/ticket/19 Message-ID: <062.f8b0d2abf056a9655a81ee25366bb354@tools.ietf.org> X-Trac-Ticket-ID: 19 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #19: How large is Serialization delay? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 10:46:42 -0000 #19: How large is Serialization delay? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Does it take longer to transmit larger packets? What is the typical serialization delay of todays Internet links? -- Ticket URL: codec From trac@tools.ietf.org Sat May 1 03:49:11 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CDB03A67F6 for ; Sat, 1 May 2010 03:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zy5hWdtCtCrn for ; Sat, 1 May 2010 03:49:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0EECA3A68C4 for ; Sat, 1 May 2010 03:49:06 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8AFg-0004Fi-CD; Sat, 01 May 2010 03:48:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sat, 01 May 2010 10:48:52 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/20 Message-ID: <062.8524135614c0f45c18915362cc459235@tools.ietf.org> X-Trac-Ticket-ID: 20 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #20: Computational complexity? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 10:49:11 -0000 #20: Computational complexity? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- How large shall the complexity of the CODEC be? How to measure it? Shall the CODEC support modes of different complexity? How much memory is the implementation instance going to consume? -- Ticket URL: codec From trac@tools.ietf.org Sat May 1 03:50:43 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46B183A6AD2 for ; Sat, 1 May 2010 03:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAjz2LlZJqAn for ; Sat, 1 May 2010 03:50:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 71B6F3A6AE7 for ; Sat, 1 May 2010 03:50:40 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8AHC-0004Jq-PG; Sat, 01 May 2010 03:50:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sat, 01 May 2010 10:50:26 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/21 Message-ID: <062.a00b15332f6e9da39f0d81d14d24c64d@tools.ietf.org> X-Trac-Ticket-ID: 21 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #21: Supporting Wireless Links? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 10:50:43 -0000 #21: Supporting Wireless Links? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Will Wireless IP be considered as important? What is about supporting Bluetooth headsets? -- Ticket URL: codec From stephen.botzko@gmail.com Sat May 1 03:57:26 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B05728C113 for ; Sat, 1 May 2010 03:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.026 X-Spam-Level: X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aif4EOhmacR5 for ; Sat, 1 May 2010 03:57:25 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 632FF3A6934 for ; Sat, 1 May 2010 03:57:25 -0700 (PDT) Received: by wwb24 with SMTP id 24so747046wwb.31 for ; Sat, 01 May 2010 03:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=VmAWSBRfWfCnWhqCQ07HJwgXywXaQki2elnS+q+kg+Y=; b=mBZcgoXF0O9ywScXiT9hAf80OY4F9jTi5g9RQFcjx6RMWR2W1HVEy6BcHy3P15nfKh 8LsAKrVTNJii67p21C98PfZzzsp7ixwctseHvUQjM56tzVH8dh278pB3eH/kbSJDub2H W9Y5E3usaV+cK4huDaDbLzK6xx+hTb6WXM8+Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NTdSfJX1+nT6dAVr41GCjz1+wcG8HdocC9pI/6ivDgGfEVpST/QKz2QnYv3cv57uGQ /FW6ud5No1eXP6X1FQv5USHzLQRKAb+mEpXN0X5CbTxSLb9gIjD2GFmyQrbYQkuJkAjn JTiy6csnFEXWVpgh7R1WX5fdpjxwdp9YULcqE= MIME-Version: 1.0 Received: by 10.216.172.68 with SMTP id s46mr1657803wel.73.1272711425864; Sat, 01 May 2010 03:57:05 -0700 (PDT) Received: by 10.216.28.139 with HTTP; Sat, 1 May 2010 03:57:05 -0700 (PDT) In-Reply-To: <062.d51439b68d5cdc7daff30cac51ddab04@tools.ietf.org> References: <062.d51439b68d5cdc7daff30cac51ddab04@tools.ietf.org> Date: Sat, 1 May 2010 06:57:05 -0400 Message-ID: From: stephen botzko To: codec@ietf.org Content-Type: multipart/alternative; boundary=001636416d9370b37d04858638e5 Subject: Re: [codec] #18: Frame Sizes X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 10:57:26 -0000 --001636416d9370b37d04858638e5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm not sure there ought to be a "SHALL" on this. Obviously it needs to be reasonably small for low delay. However, the possible frame sizes are often driven by the underlying technology (transform size being one example). If we decided on 10 and 20 ms for example, would we actually rule out a codec technology that had to run at 7.5, 15 and 22.5? Stephen Botzko On Sat, May 1, 2010 at 6:45 AM, codec issue tracker wr= ote: > #18: Frame Sizes > > ------------------------------------+------------------------------------= --- > Reporter: hoene@=85 | Owner: > Type: enhancement | Status: new > Priority: major | Milestone: > Component: requirements | Version: > Severity: - | Keywords: > > ------------------------------------+------------------------------------= --- > Which frame size(s) shall the CODEC support? > > -- > Ticket URL: > codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --001636416d9370b37d04858638e5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm not sure there ought to be a "SHALL" on this.=A0 Obviousl= y it needs to be reasonably small for low delay.=A0

However, the po= ssible frame sizes are often driven by the underlying technology (transform= size being one example).=A0 If we decided on 10 and 20 ms for example, wou= ld we actually rule out a codec technology that had to run at 7.5, 15 and 2= 2.5?

Stephen Botzko



On Sat, May 1,= 2010 at 6:45 AM, codec issue tracker <trac@tools.ietf.org> wrote:
#18: Frame Sizes
------------------------------------+--------------------------------------= -
=A0Reporter: =A0hoene@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Own= er:
=A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: = =A0new
=A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:<= br> Component: =A0requirements =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Keyw= ords:
------------------------------------+--------------------------------------= -
=A0Which frame size(s) shall the CODEC support?

--
Ticket URL: <https://svn.tools.ietf.org/wg/codec/trac/ticket/18>
codec <http:/= /tools.ietf.org/codec/>

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--001636416d9370b37d04858638e5-- From trac@tools.ietf.org Sat May 1 04:00:21 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 735ED28C0FD for ; Sat, 1 May 2010 04:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAftxqZL+NaE for ; Sat, 1 May 2010 04:00:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CA46428C0DE for ; Sat, 1 May 2010 04:00:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8AQZ-0004Vu-3o; Sat, 01 May 2010 04:00:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sat, 01 May 2010 11:00:07 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/22 Message-ID: <062.50559ef09aa4fd48fa3d3f5ca56fbf1b@tools.ietf.org> X-Trac-Ticket-ID: 22 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #22: Memory Usage? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 11:00:21 -0000 #22: Memory Usage? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- How much memory the CODEC is allow to demand? -- Ticket URL: codec From stephen.botzko@gmail.com Sat May 1 04:17:10 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 828313A6842 for ; Sat, 1 May 2010 04:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.16 X-Spam-Level: X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9r1ghiRfovV for ; Sat, 1 May 2010 04:17:09 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id B32A73A6834 for ; Sat, 1 May 2010 04:17:08 -0700 (PDT) Received: by wyb35 with SMTP id 35so754868wyb.31 for ; Sat, 01 May 2010 04:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=PyUVJpLf8KQDko3vllRCETlpkhRwaLZOdJLLsW7dfPg=; b=mibOpNYSDYJHQu/OlTjj8S18DavgKKvXDGfjvb14nwUzUcQMNZhez4abYs0EPB77r7 71js9ZCj9E5FlvTCFNOW9eqc9GttJ0xQPYGpn7lrciI8uUcf/SSloDJvXsZMKHbB1PNj BssPkERN0uMny9eUr/8cqq1IVBxaG3+2IccqA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=YRMW2PaPjPiqJf+RmAGg/wLGdUC+HGcDW2tW/SiUh5kreQctiD0pcbiAEXxQchL/vf JFUFuNyZCE2RrdfhnFkQlaLfCgC8uY53fsRaLZXI/AHtlOdmbtgGdwRh+sAe2IrhGKZu I6QXGl2uJlPcGDM/cEZ0Vhl6icA9uYoClVJKM= MIME-Version: 1.0 Received: by 10.216.90.201 with SMTP id e51mr4638504wef.72.1272712609710; Sat, 01 May 2010 04:16:49 -0700 (PDT) Received: by 10.216.28.139 with HTTP; Sat, 1 May 2010 04:16:49 -0700 (PDT) In-Reply-To: <062.f8b0d2abf056a9655a81ee25366bb354@tools.ietf.org> References: <062.f8b0d2abf056a9655a81ee25366bb354@tools.ietf.org> Date: Sat, 1 May 2010 07:16:49 -0400 Message-ID: From: stephen botzko To: codec@ietf.org Content-Type: multipart/alternative; boundary=0016e6d7e872037ba70485867f03 Subject: Re: [codec] #19: How large is Serialization delay? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 11:17:10 -0000 --0016e6d7e872037ba70485867f03 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Serialization delay is defined as being *Serialization Delay =3D Size of Packet (bits) / Transmission Rate (bps)* This is summed over all hops. For a typical low-speed backbone hop (OC3), the serialization delay for the bitrates we are talking about result in serialization delay on the order of 10 microseconds for 20 ms frame sizes. For a fast backbone hop (OC48) it i= s on the order of 1 microsecond. There is a handy calculator here: http://kt2t.us/serialization_delay.html Stephen Botzko On Sat, May 1, 2010 at 6:46 AM, codec issue tracker wr= ote: > #19: How large is Serialization delay? > > ------------------------------------+------------------------------------= --- > Reporter: hoene@=85 | Owner: > Type: enhancement | Status: new > Priority: minor | Milestone: > Component: requirements | Version: > Severity: - | Keywords: > > ------------------------------------+------------------------------------= --- > Does it take longer to transmit larger packets? What is the typical > serialization delay of todays Internet links? > > -- > Ticket URL: > codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016e6d7e872037ba70485867f03 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Serialization delay is defined as being

Serialization Delay =3D Size of Packet (bits) / Transmission Rate= (bps)

This is summed over all hops.

For a typical= low-speed backbone hop (OC3), the serialization delay for the bitrates we = are talking about result in serialization delay on the order of 10 microsec= onds for 20 ms frame sizes.=A0 For a fast backbone hop (OC48) it is on the = order of 1 microsecond.

There is a handy calculator here:=20 http://kt2t.us/serializ= ation_delay.html

Stephen Botzko

On Sat, May 1, 2010 at 6:46 AM, codec issue tracker <= ;trac@tools.ietf.org> = wrote:
#19: How large is= Serialization delay?
------------------------------------+--------------------------------------= -
=A0Reporter: =A0hoene@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Own= er:
=A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: = =A0new
=A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:<= br> Component: =A0requirements =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Keyw= ords:
------------------------------------+--------------------------------------= -
=A0Does it take longer to transmit larger packets? What is the typical
=A0serialization delay of todays Internet links?

--
Ticket URL: <https://svn.tools.ietf.org/wg/codec/trac/ticket/19>
codec <http:/= /tools.ietf.org/codec/>

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--0016e6d7e872037ba70485867f03-- From stephen.botzko@gmail.com Sat May 1 04:34:59 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33CD03A68EA for ; Sat, 1 May 2010 04:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxJfLN6tlSn7 for ; Sat, 1 May 2010 04:34:58 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 1D6393A68C4 for ; Sat, 1 May 2010 04:34:57 -0700 (PDT) Received: by wyb35 with SMTP id 35so760189wyb.31 for ; Sat, 01 May 2010 04:34:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=sk2Bqy+2fZ3x17I9EFpsAnHhc7uEj+X5bx4+HZVx1ZI=; b=ofpHKSQo+t0f/JIo+9SQJOfVb3K/8b32Zrd4sDpFrQoGmG4XMbwiH53syiuq4Rqsux uPOfr8PfFqPawQSEYct06o3YVZUuYBcOVVYMJsqiV7Ck389RoRCLK9x0mnoi5WWGqZNG cBhgct346jYeasjsaNDIc87FrsrBReYxS3T2A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BwNOaQyHfegYxGb21uRkAZk5sd7b7bW34vshCVMmQ5oCCOIK63ygw4iz/e/KAcnBMp 2sAhns4u2JJlnhbeLsbW1y57pS1SYObmij7zaofV38tEdNx0CpAs7kUdDcNigc7lqttB DbM+xxxZQ+ftNeuxFKMpDe7QdnnkLsC9vGdIE= MIME-Version: 1.0 Received: by 10.216.87.194 with SMTP id y44mr3509647wee.157.1272713680416; Sat, 01 May 2010 04:34:40 -0700 (PDT) Received: by 10.216.28.139 with HTTP; Sat, 1 May 2010 04:34:40 -0700 (PDT) In-Reply-To: <062.a00b15332f6e9da39f0d81d14d24c64d@tools.ietf.org> References: <062.a00b15332f6e9da39f0d81d14d24c64d@tools.ietf.org> Date: Sat, 1 May 2010 07:34:40 -0400 Message-ID: From: stephen botzko To: codec@ietf.org Content-Type: multipart/alternative; boundary=0016e6d56693d27274048586becc Subject: Re: [codec] #21: Supporting Wireless Links? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 11:34:59 -0000 --0016e6d56693d27274048586becc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bluetooth is clearly out-of-scope for this group. On Sat, May 1, 2010 at 6:50 AM, codec issue tracker wr= ote: > #21: Supporting Wireless Links? > > ------------------------------------+------------------------------------= --- > Reporter: hoene@=85 | Owner: > Type: defect | Status: new > Priority: major | Milestone: > Component: requirements | Version: > Severity: - | Keywords: > > ------------------------------------+------------------------------------= --- > Will Wireless IP be considered as important? What is about supporting > Bluetooth headsets? > > -- > Ticket URL: > codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016e6d56693d27274048586becc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Bluetooth is clearly out-of-scope for this group.

On Sat, May 1, 2010 at 6:50 AM, codec issue tracker <trac@tools.ietf.org><= /span> wrote:
#21: Supporting W= ireless Links?
------------------------------------+--------------------------------------= -
=A0Reporter: =A0hoene@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Own= er:
=A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0St= atus: =A0new
=A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:<= br> Component: =A0requirements =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0Keyw= ords:
------------------------------------+--------------------------------------= -
=A0Will Wireless IP be considered as important? What is about supporting =A0Bluetooth headsets?

--
Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/21>
codec <http:/= /tools.ietf.org/codec/>

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--0016e6d56693d27274048586becc-- From stephen.botzko@gmail.com Sat May 1 06:31:33 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EFBC3A6971 for ; Sat, 1 May 2010 06:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.798 X-Spam-Level: X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DI1eyDP598NA for ; Sat, 1 May 2010 06:31:32 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id A0F6F3A694D for ; Sat, 1 May 2010 06:31:26 -0700 (PDT) Received: by wyb35 with SMTP id 35so799576wyb.31 for ; Sat, 01 May 2010 06:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=uJGCnn0Punu6VcXmXSB60QC+Ko/ft7aOxsIpG/fhoTI=; b=kJ+4hNz3scseq3aZ1dT1b3ZXvBGczsZL5b9nsL4G75Wy8OwMVGUvacKTUM+9DdJBtl oNPtj6vxH84GDxM7bUdj6VQjRGFQT8l5wHsqDfckOPu7wKZ9eJk5oPi3lNrDz/H1NJAf wz+1iaV9+RzTyhSh49eaNFTEZnOda/HbmN24w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kNAKf4ic1bjG94FgOWdjJjs5p1pb8pIkCScOgzsHn6hufo5YRgibELZOuZNrfOHdlU 8yjJ1ZehPvvOxad4owSUG68tdJ3RKwljmplnxdcGKMSZtzG5QW6TOpBU2HM67HYUhtWM PKIK/xIWMF5cMdI2S0qtadZvwZ+jCgVavwU2Q= MIME-Version: 1.0 Received: by 10.216.87.194 with SMTP id y44mr3695170wee.157.1272720667048; Sat, 01 May 2010 06:31:07 -0700 (PDT) Received: by 10.216.28.139 with HTTP; Sat, 1 May 2010 06:31:06 -0700 (PDT) In-Reply-To: <20100430230756.13687lc1s5o89gsc@mail.skype.net> References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> Date: Sat, 1 May 2010 09:31:06 -0400 Message-ID: From: stephen botzko To: Koen Vos Content-Type: multipart/alternative; boundary=0016e6d56693421f630485885f4b Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 13:31:33 -0000 --0016e6d56693421f630485885f4b Content-Type: text/plain; charset=ISO-8859-1 If the frame-size multiplier is due to serialization, then I agree with Koen's assessment. In fact on many connections the multiplier would be less than 1. Dial-up is of course the worst case here, and on those links the multiplier ought to be close to 2. Variations due to congestion (and on some links, polling) are (IMHO) better modeled as jitter. Gateways are another matter, with the delays being highly dependent on the product architecture. Interupt latencies, context switching, bus architectures, etc. can dominate, so it is totally possible that reducing the frame size might actually increase the latency (since it increases the packets per second load on the gateway). So I agree with Koen on this as well. Anecdotal models based on industry experience can be useful guides - though if we are going to use these models to drive requirements, I'd prefer something more analytical. Stephen Botzko On Sat, May 1, 2010 at 2:07 AM, Koen Vos wrote: > Quoting "Raymond (Juin-Hwey) Chen": > > One-way delay = codec-independent delay + 3*(codec frame size) + (codec >> look-ahead) + (codec filtering delay if any) >> >> This formula was obtained from an experienced engineer who has been >> working on IP phones related fields for more than a decade, >> > > At Skype We have 100+ years of combined VoIP experience, and a focus on > minimizing delay as part of our goal to maximize quality. The consensus > among our engineers is that the multiplier is closer to 1 than to 2, at > least for software VoIP applications over typical Internet connections. > Some years ago the situation was slightly worse because dial-up was more > prevalent. > > > > Similar 3X multiplier is also observed in VoIP gateways. Even with a fast >> processor/system optimized from ground up to be low-delay, the measured >> "codec-dependent" one-way delay of such a VoIP gateway using the G.711 codec >> with a 5 ms frame/packet size is between 12 and 17 ms, or around 3X the >> frame size. >> > > As I've pointed out before, that doesn't say much about how the delay > increases with larger frame sizes. Perhaps the 12~17 ms includes a constant > delay of 7 ms, and the marginal growth of delay with frame size is 1x. > > best, > koen. > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016e6d56693421f630485885f4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If the frame-size multiplier is due to serialization, then I agree with Koe= n's assessment.=A0 In fact on many connections the multiplier would be = less than 1. Dial-up is of course the worst case here, and on those links t= he multiplier ought to be close to 2.=A0 Variations due to congestion (and= on some links, polling) are (IMHO)=20 better modeled as jitter.=A0

Gateways are another matter, with the = delays being highly dependent on the product architecture.=A0 Interupt late= ncies, context switching, bus architectures, etc. can dominate, so it is to= tally possible that reducing the frame size might actually increase the lat= ency (since it increases the packets per second load on the gateway).=A0 So= I agree with Koen on this as well.

Anecdotal models based on industry experience can be useful guides - th= ough if we are going to use these models to drive requirements, I'd pre= fer something more analytical.

Stephen Botzko

On Sat, May 1, 2010 at 2:07 AM, Koen Vos <koen.vos@skype.net> wrote:
Quoting "Raymond (Juin-Hwey) Chen":

=A0One-way delay =3D codec-independent delay + 3*(codec frame size) + (cod= ec look-ahead) + (codec filtering delay if any)

This formula was obtained from an experienced engineer who has been working= on IP phones related fields for more than a decade,

At Skype We have 100+ years of combined VoIP experience, and a focus on min= imizing delay as part of our goal to maximize quality. =A0The consensus amo= ng our engineers is that the multiplier is closer to 1 than to 2, at least = for software VoIP applications over typical Internet connections. =A0Some y= ears ago the situation was slightly worse because dial-up was more prevalen= t.



Similar 3X multiplier is also observed in VoIP gateways. =A0Even with a fas= t processor/system optimized from ground up to be low-delay, the measured &= quot;codec-dependent" one-way delay of such a VoIP gateway using the G= .711 codec with a 5 ms frame/packet size is between 12 and 17 ms, or around= 3X the frame size.

As I've pointed out before, that doesn't say much about how the del= ay increases with larger frame sizes. =A0Perhaps the 12~17 ms includes a co= nstant delay of 7 ms, and the marginal growth of delay with frame size is 1= x.

best,
koen.

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--0016e6d56693421f630485885f4b-- From trac@tools.ietf.org Sat May 1 07:12:09 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD53C3A6A6B for ; Sat, 1 May 2010 07:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[AWL=-1.203, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+yKqBiXh8si for ; Sat, 1 May 2010 07:12:08 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F10493A6B9A for ; Sat, 1 May 2010 07:10:59 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8DP3-0003zv-60; Sat, 01 May 2010 07:10:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sat, 01 May 2010 14:10:45 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/22#comment:1 Message-ID: <071.6815a304f033a6107bf10a7f7d821839@tools.ietf.org> References: <062.50559ef09aa4fd48fa3d3f5ca56fbf1b@tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <062.50559ef09aa4fd48fa3d3f5ca56fbf1b@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #22: Memory Usage? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 14:12:09 -0000 #22: Memory Usage? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Raymond]: (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, or VoIP gateway, often has to encode and decode thousands of voice channels in a single box, so not only the computational complexity, but also the per-instance RAM size requirement of the codec become very important for achieving high channel density in the gateway. [JM]: Agreed here, although I would say that per-instance RAM -- as long as it's reasonable -- is probably a bit less important than complexity. [Raymond]: per-instance RAM is definitely not unimportant. I have worked in a team that designed high-density VoIP gateways, and I know people did all kinds of tricks to reduce the RAM usage as much as possible because of the high cost of the external high-speed SRAM used by high-speed DSPs in such gateways. Currently, high-density VoIP gateways can have several tens of thousands of voice channels per box or per equipment rack. If codec A uses X kbytes more per-instance RAM than codec B, than implementing codec A rather than codec B in all channels will require X * (number of channels) more kbytes of high-speed SRAM, which can be a substantial additional cost. Similarly, if codec A requires a substantially higher DSP MHz than codec B, then implementing codec A in all channels will mean that more high- speed DSP chips need to be used to maintain the same number of channels. That's additional cost. Actually, the more likely scenario is that the number of DSP chips has already maxed out due to board space or heat dissipation constraint, then the gateway can only support a substantially smaller number of voice channels when compared with using codec B. Consequently, the channel density per box or per rack goes down substantially, and the per-channel deployment cost goes up substantially. Thus, even if implementing codec A or codec B makes no practical difference in a PC, it can make a very real and substantial cost difference in VoIP gateways. -- Ticket URL: codec From hoene@uni-tuebingen.de Sat May 1 07:20:11 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A63343A6BAE for ; Sat, 1 May 2010 07:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.071 X-Spam-Level: X-Spam-Status: No, score=-4.071 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJCKJPa828f7 for ; Sat, 1 May 2010 07:20:10 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id F361B3A6BA8 for ; Sat, 1 May 2010 07:20:06 -0700 (PDT) Received: from hoeneT60 ([178.2.215.148]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o41EJhIf018398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 1 May 2010 16:19:48 +0200 From: "Christian Hoene" To: "'Raymond \(Juin-Hwey\) Chen'" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> In-Reply-To: Date: Sat, 1 May 2010 16:19:43 +0200 Message-ID: <002c01cae939$5c01f400$1405dc00$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrimhyNUh3NLsf5RvSfcmuOhmvRfwBUwYUAAVLFoDA= Content-Language: de X-AntiVirus-Spam-Check: failed (checked by Avira MailGate: version: 3.0.0-4; spam filter version: unknown; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.224; VDF: 7.10.7.16; host: mx05); id=318-GhXfty Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 14:20:11 -0000 Hi Raymond, >I would like to respond to a comment and a question in your original email below. > >(1) Regarding your comment that "per-instance RAM -- as long as >it's reasonable -- is probably a bit less important than complexity", I think this may or may not be >true depending on what is defined as "reasonable", and it also depends on the VoIP gateway under >consideration. However, I think one thing is clear, though: per-instance RAM is definitely not >unimportant. I have worked in a team that designed high-density VoIP gateways, and I know people did >all kinds of tricks to reduce the RAM usage as much as possible because of the high cost of the >external high-speed SRAM used by high-speed DSPs in such gateways. > >Currently, high-density VoIP gateways can have several tens of thousands of voice channels per box or >per equipment rack. If codec A uses X kbytes more per-instance RAM than codec B, than implementing >codec A rather than codec B in all channels will require X * (number of channels) more kbytes of high- >speed SRAM, which can be a substantial additional cost. Similarly, if codec A requires a >substantially higher DSP MHz than codec B, then implementing codec A in all channels will mean that >more high-speed DSP chips need to be used to maintain the same number of channels. That's additional >cost. Actually, the more likely scenario is that the number of DSP chips has already maxed out due to >board space or heat dissipation constraint, then the gateway can only support a substantially smaller >number of voice channels when compared with using codec B. Consequently, the channel density per box >or per rack goes down substantially, and the per-channel deployment cost goes up substantially. Thus, >even if implementing codec A or codec B makes no practical difference in a PC, it can make a very real >and substantial cost difference in VoIP gateways. The arguments on costs of the gateways is raised often. Thus, it is worthwhile to consider in-depth. May I ask you for more information about the design of VoIP Gateways. Particular, I am interested in the partition between audio processing and protocol stack on DSP and CPU. Does DSP take over all codec processing? May the CPU do some parts of the computation before, during or after DSP does the signal processing? How do you count number of channels? Do all voice channels have the same weight regardless their sampling rate? Say suppose, if the mixing is done for 48kHz instead of 8kHz, how many resource are we allowed to consume more? With best regards, Christian From trac@tools.ietf.org Sat May 1 07:24:43 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F50A28C15D for ; Sat, 1 May 2010 07:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.2 X-Spam-Level: X-Spam-Status: No, score=-101.2 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1S0uiA8VPJAO for ; Sat, 1 May 2010 07:24:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 955343A6BBE for ; Sat, 1 May 2010 07:24:26 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8Dc4-0006nx-Pa; Sat, 01 May 2010 07:24:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sat, 01 May 2010 14:24:12 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/15#comment:1 Message-ID: <071.30b67e93d22f0bfedf46b5035d133441@tools.ietf.org> References: <062.bc75a3b3c4a980df34535f87c9484935@tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <062.bc75a3b3c4a980df34535f87c9484935@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #15: Efficiently combine pre-encoded audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 14:24:43 -0000 #15: Efficiently combine pre-encoded audio ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Colin:] > [...] conferences implemented using multicast require > end system mixing of potentially large numbers of active audio > streams, whereas those implemented using conference bridges do the > mixing in a single central location, and generally suppress all but > one speaker. The differences in mixing and the number of simultaneous > active streams that might be received potentially affect the design of > the codec. [Raymond]: I would like to take this opportunity to express my view that although codec complexity isn’t much of an issue for PC-to-PC calls where there are GHz of processing power available, the codec complexity is an important issue in certain application scenarios. The following are just some examples. 1) If a conference bridge has to decode a large number of voice channels, mix, and re-encode, and if compressed-domain mixing cannot be done (which is usually the case), then it is important to keep the decoder complexity low. [JM]: The decoder complexity is very important. Not only because of mixing issue, but also because the decoder is generally not allowed to take shortcuts to save on complexity (unlike the encoder). As for compressed- domain mixing, as you say it is not always available, but *if* we can do it (even if only partially), then that can result in a "free" reduction in decoder complexity for mixing. [Christian]: Scalable [conferencing] - Receiver side activity detection for music and voice having low complexity (for the conference bridge) - Efficient mixing of two to four(?) active flows (is this achievable without the complete process of decoding and encoding again?) -- Ticket URL: codec From trac@tools.ietf.org Sat May 1 07:31:05 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4700F3A6BCA for ; Sat, 1 May 2010 07:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.196 X-Spam-Level: X-Spam-Status: No, score=-101.196 tagged_above=-999 required=5 tests=[AWL=-1.196, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YM1P8-epj6C for ; Sat, 1 May 2010 07:31:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id BFF2528C17F for ; Sat, 1 May 2010 07:30:51 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8DiH-00025W-JC; Sat, 01 May 2010 07:30:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sat, 01 May 2010 14:30:37 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/20#comment:1 Message-ID: <071.993e5bdf78d45bb46b8790a7ef9b857f@tools.ietf.org> References: <062.8524135614c0f45c18915362cc459235@tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <062.8524135614c0f45c18915362cc459235@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #20: Computational complexity? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 14:31:05 -0000 #20: Computational complexity? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Raymond]: > 3) Many telephone terminal devices at the edge of the Internet use > embedded processors with limited processing power, and the processors > also have to handle many tasks other than speech coding. If the IETF > codec complexity is too high, some of such devices may not have > sufficient processing power to run it. Even if the codec can fit, some > battery-powered mobile devices may prefer to run a lower-complexity > codec to reduce power consumption and battery drain. For example, even > if you make a Internet phone call from a computer, you may like the > convenience of using a Bluetooth headset that allows you to walk > around a bit and have hands-free operation. Currently most Bluetooth > headsets have small form factors with a tiny battery. This puts a > severe constraint on power consumption. Bluetooth headset chips > typically have very limited processing capability, and it has to > handle many other tasks such as echo cancellation and noise reduction. > There is just not enough processing power to handle a relatively > high-complexity codec. Most BT headsets today relies on the extremely > low-complexity, hardware-based CVSD codec at 64 kb/s to transmit > narrowband voice, but CVSD has audible coding noise, so it degrades > the overall audio quality. If the IETF codec has low enough > complexity, it would be possible to directly encode and decode the > IETF codec bit-stream at the BT headset, thus avoiding the quality > degradation of CVSD transcoding. [Koen]: By the time the BlueTooth Special Interest Group will have adopted a future IETF codec standard, Moore's law will surely have multiplied CPU resources in the BT device by one order of magnitude..? Not sure it makes sense to apply today's BT constraints to tomorrow's codec. [Raymond]: Most importantly, guess what, in the last several years the Bluetooth headset chips have been growing its processing power at a MUCH, MUCH slower rate than what the Moore's Law says it should. Sometimes they did not increase the speed at all for years. The reasons? The ASP (average sale price) of Bluetooth chips plummeted very badly, making it unattractive to invest significant resources to make them significantly faster. Also, for low-end and mid-end BT headsets, the BT chips were often considered "good enough" and there wasn't a strong drive to increase the computing resources. In addition, the BT headsets got smaller over the last few years; the corresponding reduction in battery size required a reduction in power consumption, which also limited how fast the processor speed could grow. In the next several years, it is highly likely that the computing capabilities of Bluetooth headset chips will continue to grow at a rate substantially below what's predicted by the Moore's Law. [Raymond]: I would like to take this opportunity to express my view that although codec complexity isn’t much of an issue for PC-to-PC calls where there are GHz of processing power available, the codec complexity is an important issue in certain application scenarios. The following are just some examples. 1) If a conference bridge has to decode a large number of voice channels, mix, and re-encode, and if compressed-domain mixing cannot be done (which is usually the case), then it is important to keep the decoder complexity low. [JM]: The decoder complexity is very important. Not only because of mixing issue, but also because the decoder is generally not allowed to take shortcuts to save on complexity (unlike the encoder). As for compressed- domain mixing, as you say it is not always available, but *if* we can do it (even if only partially), then that can result in a "free" reduction in decoder complexity for mixing. [Koen]: A codec/mode that meets the BT requirements for ultra-low complexity will have a relatively poor coding efficiency, resulting in lower audio quality and/or a higher bitrate. Both of these negatively impact the user experience over the Internet. Therefore, you do not want to run a BT codec over the Internet if you can use a more efficient codec instead. [Raymond]: Bluetooth headsets have much lower processing power and much smaller batteries than cell phones. The complexity of cellular codecs, typically in the range of 20 to 40 MHz on a DSP, is too high to fit most Bluetooth headsets. However, unlike cell phones and Bluetooth headsets where each is a specific type of device with a relatively narrow range of device complexity, Internet voice/audio applications can potentially encompass a large variety of different device types, from desktop computers at the high end with > 3 GHz multi-core CPU to IP phones and possibly even Bluetooth headsets at the low end with a processor of only a few tens of MHz. It is up to the IETF codec WG how we want the complexity of the IETF codec to be. We can standardize just one codec mode that works well for computer-to-computer calls but can't fit in low-end devices, or we can keep that mode but also have a low-complexity mode that can be implemented in low-end devices. -- Ticket URL: codec From trac@tools.ietf.org Sat May 1 08:03:36 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D901C3A6A9F for ; Sat, 1 May 2010 08:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.192 X-Spam-Level: X-Spam-Status: No, score=-101.192 tagged_above=-999 required=5 tests=[AWL=-1.192, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bH-QXE9NEObJ for ; Sat, 1 May 2010 08:03:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 915CA3A6BD8 for ; Sat, 1 May 2010 08:03:35 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8EDx-0000PH-NJ; Sat, 01 May 2010 08:03:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sat, 01 May 2010 15:03:21 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/19#comment:1 Message-ID: <071.289e6095d248419b6000d50c06a497c5@tools.ietf.org> References: <062.f8b0d2abf056a9655a81ee25366bb354@tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <062.f8b0d2abf056a9655a81ee25366bb354@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #19: How large is the frame size depended delay / the serialization delay? (was: How large is Serialization delay?) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 15:03:37 -0000 #19: How large is the frame size depended delay / the serialization delay? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Koen]: For a well-designed system and a typical Internet connection: - one-way delay grows almost linearly with frame size. [Koen]: I meant that approximately: one-way delay = codec-independent delay + frame size ("codec algorithmic delay" would be more accurate than "frame size") [Raymond]: First, I agree that codec algorithmic buffering delay is more accurate than frame size since it can also include the “look-ahead” delay and filtering delay if sub-band analysis/synthesis is used. However, your formula implies that for the codec-related delay, the “multiplier” to be used for the codec frame size is only 1. That’s unrealistic and theoretically impossible. For that to happen, after you wait one frame of time for the current frame of input audio samples to arrive at your input signal buffer (that’s one frame of codec-related delay already), you need an infinitely fast processor to finish the encoding operation instantly, then you need an infinitely fast communication link to ship all the bits in the compressed frame to the decoder instantly, and then you need an infinitely fast processor to finish decoding the frame instantly and start playing back the current frame of audio without any delay. That’s just impossible. In reality, if the processor is just barely fast enough to implement the codec in real time, then you need nearly a full frame of time to finish the encoding and decoding operations. That makes the multiplier to be 2 already. If your communication link is just barely fast enough to transmit your packets at the same speed they are generated without piling up unsent packets, then it takes another frame of time to finish transmitting the compressed bits in a frame to the decoder. That makes the multiplier to be 3 already. Granted, in practice the processor and the communication link are usually faster than just barely enough, so the processing delay and the transmission delay can be less than 1 frame each. However, there are other miscellaneous uncounted delays that tends to depend on the codec size in various ways. Thus, a typical IP phone implementation would have One-way delay = codec-independent delay + 3*(codec frame size) + (codec look-ahead) + (codec filtering delay if any). Hence, the one-way delay difference between a 20 ms and a 5 ms codec frame size would be 45 ms + (codec look-ahead difference) + (codec filtering delay difference). Consequently, for the conference bridge application, the total difference in one-way delay can easily be in the 90 to 100 ms range. When adding this delay difference to all the other codec-independent delay components, it is still a huge difference that the users can easily notice, especially since it will most likely push the total one-way delay significantly beyond the 150 ms limit. [Koen]: And transmission delay increases (perhaps) linearly with the *packet size*, not with the *frame size*. For a 32 kbps codec with 5 ms frames, packets are just 30% smaller than with a 16 kbps codecs with 20 ms frames. [Stephen]: "Packet size" here has to include layer 2 overhead, not just IP overhead, making your argument even stronger. In the case of Ethernet, Layer-2 overhead is 38-42 bytes per packet (depending on whether a vlan tag is present), so it is about the same as the IP/UDP/RTP overhead. And of course there's encryption pads, VPN encapsulation, etc. that apply in many cases. [Raymond]: Agreed. My previous comments on transmission delay was based on the TDM rather than packet scenario, but I was just using that simplified TDM example to make a point that transmission delay cannot be zero, as your 1X frame size multiplier would imply. Even with your statement above, a larger codec frame size still makes a larger packet size, which then increases the transmission delay, so you can’t say transmission delay is zero or is independent of the codec size. In any case, these are really minor details. My key point is that your 1X multiplier for the codec frame size is simply theoretically impossible. The rule of thumb used by IP phone engineers is around 3X codec frame size. [Raymond]: The main debate now is centered on whether the multiplier of the codec frame size should be 1 as Koen said or 3 as I was told by experienced IP phone engineers. I argue that 1X is theoretically impossible. It is interesting to note that the ITU-T uses a multiplier of 2X. I think 2X is probably achievable for the idealized situation. In practice, however, many nitty-gritty details get in the way of getting that idealized situation, and little additional delays just keep getting added, resulting in a real-world realistic 3X multiplier. With a 3X multiplier, the one-way delay difference between a 20 ms and a 5 ms codec frame size would be 45 ms + (codec look-ahead difference) + (codec filtering delay difference). [Mikael]: I think what the 2X 3X factor is handling is what we in the networking world calls "serialisation delay". Most equipment today receives the packet, looks at it, then sends it out (store and forward). That means that on a 2 megabit/s link, it takes: 1/2000000*100*8 .0004 (0.4ms) to send out a 100 byte packet. With multiple such links for the packet to traverse, it might be possible to see those kind of amlifications of frame size (even though I can't get it to amplify that much, for instance when going from 5ms to 20ms packet interval). Could be if there are a lot of slow links for the packet to traverse (512 kilobits/s for instance). We stop worrying about serialisation delays when speeds go over several hundred megabit/s, because on a gigabit ethernet link serialisation delay for a 1500 byte packet is 0.012 ms. [Koen]: At Skype We have 100+ years of combined VoIP experience, and a focus on minimizing delay as part of our goal to maximize quality. The consensus among our engineers is that the multiplier is closer to 1 than to 2, at least for software VoIP applications over typical Internet connections. Some years ago the situation was slightly worse because dial-up was more prevalent. -- Ticket URL: codec From trac@tools.ietf.org Sat May 1 08:48:25 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFE0B3A69CF for ; Sat, 1 May 2010 08:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.188 X-Spam-Level: X-Spam-Status: No, score=-101.188 tagged_above=-999 required=5 tests=[AWL=-1.188, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1BE0VP+DXHz for ; Sat, 1 May 2010 08:48:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D8CC33A6822 for ; Sat, 1 May 2010 08:48:24 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8EvL-0000PS-19; Sat, 01 May 2010 08:48:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sat, 01 May 2010 15:48:10 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/18#comment:1 Message-ID: <071.65d7e4264840e0798639e1f3d4098d38@tools.ietf.org> References: <062.d51439b68d5cdc7daff30cac51ddab04@tools.ietf.org> X-Trac-Ticket-ID: 18 In-Reply-To: <062.d51439b68d5cdc7daff30cac51ddab04@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #18: Frame Sizes? (was: Frame Sizes) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 15:48:25 -0000 #18: Frame Sizes? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [JM]: As the author of CELT, I obviously agree that latency is an important aspect for this codec :-) That being said, I tend to say that 20 ms is still the most widely used frame size, so we might as well optimise for that. This is not really a problem because as the frame size goes down, the overhead of the IP/UDP/RTP headers go up, so the codec bit-rate becomes a bit less of an issue. For example, with 5 ms frames, we would already be sending 64 kb/s worth of headers (excluding the link layer), so we might as well spend about as many bits on the actual payload as we spend on the headers. And with 64 kb/s of payload, we can actually have high-quality full-band audio. [Raymond]: The way I see it, for conference bridge applications at least, I think it would be a big mistake for IETF to recommend a codec with a frame size of 20 ms or higher. From my analysis above, by doing that we will be stuck with too long a delay and the associated problems. [Mikael]: From my point of view as a network engineer, it would be a mistake to recommend *fixed* frame size at all. The codec needs to be able to handle everything from 5ms to 250ms frame size depending on network conditions (please see my emails from a few months back regarding the reality of the Internet today). [JM]: I think I may have been a bit ambiguous in my previous email. I am totally in favor of supporting 5 ms frames. TO me, it is becoming clear that we want to support both 5 ms *and* 20 ms frames. I don't think it would be too hard to support both. [Koen]: Let me ask you something: how often is G.729 used with 10 ms packets, or Broadvoice with 5 ms packets? [Raymond]: Not very often, but that’s because previously network routers/switches didn’t like to handle too many packets per second, and the higher packet header overhead associated with a smaller packet size means the overall bit-rate would be higher than desired or allowed, so the time of small packet size for low-delay VoIP hasn’t really come yet. However, with the help of Moore’s Law, network routers/switches are becoming much faster now, and I was told that they can handle a 5 ms packet size without problems; furthermore, the speed of backbone networks and access networks keep increasing with time, so the bit-rate concern will also decrease with time. Unlike processing speed and communication speed that continuously get improved with time for decades, delay is one thing that will NOT get improved with time and Moore’s Law cannot do anything about that! If the IETF codec has a minimum frame size of 20 ms, we will be stuck with the longer overall delay associated with that, and Moore’s Law will not help us reduce that delay in the future. On the other hand, in addition to using a 20 ms frame size for bit-rate-sensitive applications, if the IETF codec also has a low-delay mode that uses a 5 ms frame size, then at least for delay-sensitive applications, people have a choice to achieve a lower delay by paying the price of a higher overall bit-rate (i.e. with packet header counted), and this higher bit-rate will be less and less of a concern as the network speed keep increasing with time. [Raymond]: (4) Delay requirement: Due to the need for cellular codecs to achieve bit-rates as low as possible, they sacrificed the coding delay and used a 20 ms frame size, because using a 10 or 5 ms frame size would increase the bit-rate for a given level of speech quality. On the other hand, a Bluetooth headset needs to have a low delay since its delay is added to the already long cell phone delay. For the IETF codec, again it is up to the codec WG to decide what kind of codec delay we want, and again I think it makes sense to have a higher-delay, higher bit-rate efficiency mode for bit-rate-sensitive applications and another low-delay mode for delay-sensitive applications, since one size doesn't fit all. If the IETF codec delay is forced to be one size, the resulting codec will be (potentially very) suboptimal for some applications. -- Ticket URL: codec From hoene@uni-tuebingen.de Sat May 1 10:12:35 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 458C13A68DA for ; Sat, 1 May 2010 10:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.011 X-Spam-Level: X-Spam-Status: No, score=-4.011 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROosyAkWMHui for ; Sat, 1 May 2010 10:12:27 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id E69453A6BE6 for ; Sat, 1 May 2010 10:12:24 -0700 (PDT) Received: from hoeneT60 ([178.2.215.148]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o41HBpOi029088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 1 May 2010 19:11:58 +0200 From: "Christian Hoene" To: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> In-Reply-To: Date: Sat, 1 May 2010 19:11:52 +0200 Message-ID: <002f01cae951$6d802d60$48808820$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01CAE962.3108FD60" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrpMp+sn+iSbbxBTgGizlvP/ru38wAG8Fcg Content-Language: de X-AntiVirus-Spam-Check: failed (checked by Avira MailGate: version: 3.0.0-4; spam filter version: unknown; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.224; VDF: 7.10.7.16; host: mx05); id=318-HQt87a Subject: Re: [codec] #19: How large is the frame size depended delay / the serialization delay? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 17:12:35 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0030_01CAE962.3108FD60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I agree that serialization, processing, and implementation delay should = be distinguished. =20 Assume a low-cost VoIP phone with its processing power being fully = utilized by one call: Then, the DSP/CPU needs an entire frame duration to encode and decode frames. Thus, the latency is increase by = one frame length in addition to the serialization delay, propagation delay, algorithmic delay, dejittering delay, echo cancelling = delay, ... Running the chips at 100% load is of course cost saving compared to add some more computational resource. But is = this still a relevant issue today?=20 =20 I am not sure whether it always make sense for mobile device to run at = 100% load. Of course, from a energy consumption perceptive it make sense to run CMOS circuit at the lowest possible frequency as power = consumption drops quadratic. But maybe running the CPU/DSP at higher speed and switching to power save mode if after the a frame = has been decoded/encoded is be equally energy efficient=85 =20 Even if a gateways DSP is utilized fully, the processing delays must not = be very large. For example, take a gateway serving 10000 calls and all CPUs/DSPs are at 100%. Then, the time needed for = encoding/decoding should be frame duration/10000, if the encoding/decoding is well scheduled. =20 Also, I do not think we shall consider implementation delay, which = occurs due to suboptimal implementation. For example, some years ago we tested the RTT of two Linux softphones link directly together = using G.711. It was 400ms. The implementation delay could be a good performance metric to differentiate two otherwise equal products. = Also, the algorithmic processing delay might be subject to similar market optimization. =20 Having said this, I would anyhow suggest to include the processing delay = into the measurement of the end-to-end (acoustic round) trip time. Those measurements should be part of the control loop that = optimizes the overall conversation call quality. =20 Christian =20 --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of stephen botzko Sent: Saturday, May 01, 2010 3:31 PM To: Koen Vos Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? =20 If the frame-size multiplier is due to serialization, then I agree with = Koen's assessment. In fact on many connections the multiplier would be less than 1. Dial-up is of course the worst case = here, and on those links the multiplier ought to be close to 2. Variations due to congestion (and on some links, polling) are (IMHO) = better modeled as jitter. =20 Gateways are another matter, with the delays being highly dependent on = the product architecture. Interupt latencies, context switching, bus architectures, etc. can dominate, so it is totally = possible that reducing the frame size might actually increase the latency (since it increases the packets per second load on the gateway). = So I agree with Koen on this as well. Anecdotal models based on industry experience can be useful guides - = though if we are going to use these models to drive requirements, I'd prefer something more analytical. Stephen Botzko On Sat, May 1, 2010 at 2:07 AM, Koen Vos wrote: Quoting "Raymond (Juin-Hwey) Chen": One-way delay =3D codec-independent delay + 3*(codec frame size) + = (codec look-ahead) + (codec filtering delay if any) This formula was obtained from an experienced engineer who has been = working on IP phones related fields for more than a decade, =20 At Skype We have 100+ years of combined VoIP experience, and a focus on = minimizing delay as part of our goal to maximize quality. The consensus among our engineers is that the multiplier is closer to 1 = than to 2, at least for software VoIP applications over typical Internet connections. Some years ago the situation was slightly = worse because dial-up was more prevalent. Similar 3X multiplier is also observed in VoIP gateways. Even with a = fast processor/system optimized from ground up to be low-delay, the measured "codec-dependent" one-way delay of such a VoIP = gateway using the G.711 codec with a 5 ms frame/packet size is between 12 and 17 ms, or around 3X the frame size. =20 As I've pointed out before, that doesn't say much about how the delay = increases with larger frame sizes. Perhaps the 12~17 ms includes a constant delay of 7 ms, and the marginal growth of delay with = frame size is 1x. best, koen. _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec =20 ------=_NextPart_000_0030_01CAE962.3108FD60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,<= /font>

 

I agree that = serialization, processing, and implementation delay should be = distinguished.

 

Assume a low-cost = VoIP phone with its processing power being fully utilized by one call: Then, the = DSP/CPU needs an entire frame duration to encode and decode frames. Thus, the = latency is increase by one frame length in addition to the serialization delay, propagation delay, algorithmic delay, dejittering delay, echo cancelling = delay, ... =A0Running the chips at 100% = load is of course cost saving compared to add some more computational resource. But = is this still a relevant issue today?

 

I am not sure whether = it always make sense for mobile device to run at 100% load. Of course, from = a energy consumption perceptive it make sense to run CMOS circuit at the = lowest possible frequency as power consumption drops quadratic. But maybe = running the CPU/DSP at higher speed and switching to power save mode if after the a = frame has been decoded/encoded is be equally energy = efficient…

 

Even if a gateways = DSP is utilized fully, the processing delays must not be very large. For = example, take a gateway serving 10000 calls and all CPUs/DSPs are at 100%. Then, the = time needed for encoding/decoding should be frame duration/10000, if the encoding/decoding is well scheduled.

 

Also, I do not think = we shall consider implementation delay, which occurs due to suboptimal = implementation. For example, some years ago we tested the RTT of two Linux softphones = link directly together using G.711. It was 400ms. The implementation delay could be a = good performance metric to differentiate two otherwise equal products. Also, the = algorithmic processing delay might be subject to similar market = optimization.

 

Having said this, I = would anyhow suggest to include the processing delay into the measurement of = the end-to-end (acoustic round) trip time.=A0 = Those measurements should be part of the control loop that optimizes the = overall conversation call quality.

 

Christian=

 

---------------------------------------------------------------=

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of T=FCbingen =

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebingen= .de/

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On = Behalf Of stephen botzko
Sent: Saturday, May 01, = 2010 3:31 PM
To: Koen Vos
Cc: codec@ietf.org
Subject: Re: [codec] #16: = Multicast?

 

If the = frame-size multiplier is due to serialization, then I agree with Koen's = assessment.  In fact on many connections the multiplier would be less than 1. Dial-up = is of course the worst case here, and on those links the multiplier ought to = be close to 2.  Variations due to congestion (and on some links, polling) = are (IMHO) better modeled as jitter. 

Gateways are another matter, with the delays being highly dependent on = the product architecture.  Interupt latencies, context switching, bus architectures, etc. can dominate, so it is totally possible that = reducing the frame size might actually increase the latency (since it increases the = packets per second load on the gateway).  So I agree with Koen on this as = well.

Anecdotal models based on industry experience can be useful guides - = though if we are going to use these models to drive requirements, I'd prefer = something more analytical.

Stephen Botzko

On Sat, May 1, 2010 at 2:07 AM, Koen Vos <koen.vos@skype.net> = wrote:

Quoting = "Raymond (Juin-Hwey) Chen":

 One-way delay =3D codec-independent delay + 3*(codec frame = size) + (codec look-ahead) + (codec filtering delay if any)

This formula was obtained from an experienced engineer who has been = working on IP phones related fields for more than a = decade,

 

At Skype We have 100+ years of combined VoIP experience, and a = focus on minimizing delay as part of our goal to maximize quality.  The = consensus among our engineers is that the multiplier is closer to 1 than to 2, at = least for software VoIP applications over typical Internet connections. =  Some years ago the situation was slightly worse because dial-up was more = prevalent.



Similar 3X multiplier is also observed in VoIP gateways. =  Even with a fast processor/system optimized from ground up to be low-delay, = the measured "codec-dependent" one-way delay of such a VoIP gateway using = the G.711 codec with a 5 ms frame/packet size is between 12 and 17 ms, or = around 3X the frame size.

 

As I've pointed out before, that doesn't say much about how the = delay increases with larger frame sizes.  Perhaps the 12~17 ms includes a constant delay of 7 ms, and the marginal growth of delay with frame size = is 1x.

best,
koen.


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

 

------=_NextPart_000_0030_01CAE962.3108FD60-- From trac@tools.ietf.org Sat May 1 10:16:03 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4D413A68DA for ; Sat, 1 May 2010 10:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q22yPeTPJfrS for ; Sat, 1 May 2010 10:16:03 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id CD1523A6C39 for ; Sat, 1 May 2010 10:15:59 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8GI2-0000nA-0C; Sat, 01 May 2010 10:15:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sat, 01 May 2010 17:15:41 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/23 Message-ID: <062.b61c5855ce44adba1265c9026766b943@tools.ietf.org> X-Trac-Ticket-ID: 23 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #23: Impact of packet headers etc. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 17:16:04 -0000 #23: Impact of packet headers etc. ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Each IP has headers causing a packet overhead. In addition, link layers might contribute to each packets overhead. How large is the impact of packets on the codec parameters? -- Ticket URL: codec From trac@tools.ietf.org Sat May 1 10:17:43 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28E5F3A6809 for ; Sat, 1 May 2010 10:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5iF1u8Z-+YVM for ; Sat, 1 May 2010 10:17:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 05A323A6A67 for ; Sat, 1 May 2010 10:17:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8GJX-0004x4-6l; Sat, 01 May 2010 10:17:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sat, 01 May 2010 17:17:15 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/24 Message-ID: <062.6a10c93c1a05ea5f21f5afc0b48f2660@tools.ietf.org> X-Trac-Ticket-ID: 24 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #24: Negotiation of codec parameters? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 17:17:43 -0000 #24: Negotiation of codec parameters? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- How and when shall codec parameters be negotiated? Using SDP? During a call? -- Ticket URL: codec From stephen.botzko@gmail.com Sat May 1 10:24:38 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 844443A6A67 for ; Sat, 1 May 2010 10:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.102 X-Spam-Level: X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0O8q9T-E4tIE for ; Sat, 1 May 2010 10:24:36 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 6E8E83A68D6 for ; Sat, 1 May 2010 10:24:31 -0700 (PDT) Received: by wwb24 with SMTP id 24so887226wwb.31 for ; Sat, 01 May 2010 10:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=fvC8zod1I8FBudj5tBXS/qNPYEavQ9An/sijPR1j9U4=; b=Qu1jrGP5oE/IMqk/L4qjEpMQ9d4mdiw0kk/g0LWXObo25GFNTqa4L9LTKbdgb6F7fO J9x22IpForcKSwjyM6RUTKZUXYqqJhjeyQbr4tDR1vVIJQcZDPVdjHuiHi5efgophy3T dtMhuofSR+aI8WHrJGVfLbgCdVyWlZJWpj4Y0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZrXo0Zl/pYiOuQc9pdNyoKfVknkUeM21WoZ2cRVXHVkqel0gxJY11PgyizSU2MnKe4 zbAbAJ96+Jlyu5WiHGCM4FWJtNRCFgu8hXMlhFmyeajWqHXAx5ygKDySpKkK1++FtnzX e+zeUzgRAYJBnnNLh9t4kXT9wL2nLBSwySfSI= MIME-Version: 1.0 Received: by 10.216.168.71 with SMTP id j49mr3422212wel.175.1272734653455; Sat, 01 May 2010 10:24:13 -0700 (PDT) Received: by 10.216.28.139 with HTTP; Sat, 1 May 2010 10:24:13 -0700 (PDT) In-Reply-To: <002f01cae951$6d802d60$48808820$@de> References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <002f01cae951$6d802d60$48808820$@de> Date: Sat, 1 May 2010 13:24:13 -0400 Message-ID: From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=0016e649d7c6e9a53804858ba0f1 Cc: codec@ietf.org Subject: Re: [codec] #19: How large is the frame size depended delay / the serialization delay? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 17:24:38 -0000 --0016e649d7c6e9a53804858ba0f1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >>> Having said this, I would anyhow suggest to include the processing delay into the measurement of the end-to-end (acoustic round) trip time. Those measurements should be part of the control loop that optimizes the overall conversation call quality. >>> Hi Christian I don't understand what you have in mind on this control loop idea, or what the control loop has to do with acoustic round trip time. Maybe you could outline your thoughts on this control loop generally in mor= e detail? Stephen Botzko On Sat, May 1, 2010 at 1:11 PM, Christian Hoene wro= te: > Hi, > > > > I agree that serialization, processing, and implementation delay should b= e > distinguished. > > > > Assume a low-cost VoIP phone with its processing power being fully utiliz= ed > by one call: Then, the DSP/CPU needs an entire frame duration to encode a= nd > decode frames. Thus, the latency is increase by one frame length in addit= ion > to the serialization delay, propagation delay, algorithmic delay, > dejittering delay, echo cancelling delay, ... Running the chips at 100% > load is of course cost saving compared to add some more computational > resource. But is this still a relevant issue today? > > > > I am not sure whether it always make sense for mobile device to run at 10= 0% > load. Of course, from a energy consumption perceptive it make sense to ru= n > CMOS circuit at the lowest possible frequency as power consumption drops > quadratic. But maybe running the CPU/DSP at higher speed and switching to > power save mode if after the a frame has been decoded/encoded is be equal= ly > energy efficient=85 > > > > Even if a gateways DSP is utilized fully, the processing delays must not = be > very large. For example, take a gateway serving 10000 calls and all > CPUs/DSPs are at 100%. Then, the time needed for encoding/decoding should= be > frame duration/10000, if the encoding/decoding is well scheduled. > > > > Also, I do not think we shall consider implementation delay, which occurs > due to suboptimal implementation. For example, some years ago we tested t= he > RTT of two Linux softphones link directly together using G.711. It was > 400ms. The implementation delay could be a good performance metric to > differentiate two otherwise equal products. Also, the algorithmic process= ing > delay might be subject to similar market optimization. > > > > Having said this, I would anyhow suggest to include the processing delay > into the measurement of the end-to-end (acoustic round) trip time. Those > measurements should be part of the control loop that optimizes the overal= l > conversation call quality. > > > > Christian > > > > --------------------------------------------------------------- > > Dr.-Ing. Christian Hoene > > Interactive Communication Systems (ICS), University of T=FCbingen > > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > > > *From**:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On > Behalf Of *stephen botzko > *Sent:* Saturday, May 01, 2010 3:31 PM > *To:* Koen Vos > *Cc:* codec@ietf.org > *Subject:* Re: [codec] #16: Multicast? > > > > If the frame-size multiplier is due to serialization, then I agree with > Koen's assessment. In fact on many connections the multiplier would be l= ess > than 1. Dial-up is of course the worst case here, and on those links the > multiplier ought to be close to 2. Variations due to congestion (and on > some links, polling) are (IMHO) better modeled as jitter. > > Gateways are another matter, with the delays being highly dependent on th= e > product architecture. Interupt latencies, context switching, bus > architectures, etc. can dominate, so it is totally possible that reducing > the frame size might actually increase the latency (since it increases th= e > packets per second load on the gateway). So I agree with Koen on this as > well. > > Anecdotal models based on industry experience can be useful guides - thou= gh > if we are going to use these models to drive requirements, I'd prefer > something more analytical. > > Stephen Botzko > > On Sat, May 1, 2010 at 2:07 AM, Koen Vos wrote: > > Quoting "Raymond (Juin-Hwey) Chen": > > One-way delay =3D codec-independent delay + 3*(codec frame size) + (code= c > look-ahead) + (codec filtering delay if any) > > This formula was obtained from an experienced engineer who has been worki= ng > on IP phones related fields for more than a decade, > > > > At Skype We have 100+ years of combined VoIP experience, and a focus on > minimizing delay as part of our goal to maximize quality. The consensus > among our engineers is that the multiplier is closer to 1 than to 2, at > least for software VoIP applications over typical Internet connections. > Some years ago the situation was slightly worse because dial-up was more > prevalent. > > > > Similar 3X multiplier is also observed in VoIP gateways. Even with a > fast processor/system optimized from ground up to be low-delay, the measu= red > "codec-dependent" one-way delay of such a VoIP gateway using the G.711 co= dec > with a 5 ms frame/packet size is between 12 and 17 ms, or around 3X the > frame size. > > > > As I've pointed out before, that doesn't say much about how the delay > increases with larger frame sizes. Perhaps the 12~17 ms includes a const= ant > delay of 7 ms, and the marginal growth of delay with frame size is 1x. > > best, > koen. > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > --0016e649d7c6e9a53804858ba0f1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >>>
Having said this, I would anyhow suggest to include the processing delay into the measurement of=20 the end-to-end (acoustic round) trip time.=A0 Those measurements should be part of the control loop that optimizes the=20 overall conversation call quality.
>>>

Hi Christia= n

I don't understand what you have in mind on this control loop = idea, or what the control loop has to do with acoustic round trip time.=A0= =A0

Maybe you could outline your thoughts on this control loop generally in= more detail?

Stephen Botzko
<= span style=3D"font-size: 10.5pt;" lang=3D"EN-US">

On Sat, May 1, 2010 at 1:11 PM, Christian Hoene <hoene@uni-tuebingen.de> = wrote:

Hi,

=A0

I agree that serialization, processing, and implementation delay should be distinguished.

=A0

Assume a low-cost VoIP phone with its processing power being fully utilized by one call: Then, the DSP/C= PU needs an entire frame duration to encode and decode frames. Thus, the laten= cy is increase by one frame length in addition to the serialization delay, propagation delay, algorithmic delay, dejittering delay, echo cancelling de= lay, ... =A0Running the chips at 100% load is of course cost saving compared to add some more computational resource. But is this still a relevant issue today?

=A0

I am not sure whether it always make sense for mobile device to run at 100% load. Of course, from a energy consumption perceptive it make sense to run CMOS circuit at the lowe= st possible frequency as power consumption drops quadratic. But maybe running = the CPU/DSP at higher speed and switching to power save mode if after the a fra= me has been decoded/encoded is be equally energy efficient=85

=A0

Even if a gateways DSP is utilized fully, the processing delays must not be very large. For example, = take a gateway serving 10000 calls and all CPUs/DSPs are at 100%. Then, the time needed for encoding/decoding should be frame duration/10000, if the encoding/decoding is well scheduled.

=A0

Also, I do not think we shall consider implementation delay, which occurs due to suboptimal implementatio= n. For example, some years ago we tested the RTT of two Linux softphones link = directly together using G.711. It was 400ms. The implementation delay could be a goo= d performance metric to differentiate two otherwise equal products. Also, the algorithmic= processing delay might be subject to similar market optimization.

=A0

Having said this, I would anyhow suggest to include the processing delay into the measurement of the = end-to-end (acoustic round) trip time.=A0 Those measurements should be part of the control loop that optimizes the overall conversation call quality.

=A0

= Ch= ristian

= = =A0

---------------------------------------------------= ------------

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University= of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 = 2970532
= http://www.net.uni-tu= ebingen.de/

= = =A0

From<= font size=3D"2" face=3D"Tahoma">: codec-bounces@ietf.org [mailto:codec-b= ounces@ietf.org] On Behalf Of stephen botzko
Sent: Saturday, May 01, 20= 10 3:31 PM
To: Koen Vos
Cc: codec@ietf.org
Subject: Re: [codec] #16: = Multicast?

=A0

If the frame-size multiplier is due to serialization, then I agree with Koen's assessment= .=A0 In fact on many connections the multiplier would be less than 1. Dial-up is= of course the worst case here, and on those links the multiplier ought to be c= lose to 2.=A0 Variations due to congestion (and on some links, polling) are (IMHO) better modeled as jitter.=A0

Gateways are another matter, with the delays being highly dependent on the product architecture.=A0 Interupt latencies, context switching, bus architectures, etc. can dominate, so it is totally possible that reducing t= he frame size might actually increase the latency (since it increases the pack= ets per second load on the gateway).=A0 So I agree with Koen on this as well.
Anecdotal models based on industry experience can be useful guides - though= if we are going to use these models to drive requirements, I'd prefer some= thing more analytical.

Stephen Botzko

On Sat, May 1, 2010 at 2:07 AM, Koen Vos <koen.vos@skype.net>= wrote:

Quoting "Raymond (Juin-Hwey) Chen":

=A0One-way delay =3D codec-independent delay + 3*(co= dec frame size) + (codec look-ahead) + (codec filtering delay if any)

This formula was obtained from an experienced engineer who has been working= on IP phones related fields for more than a decade,

=A0

At Skype We have 100+ years of combined VoIP experie= nce, and a focus on minimizing delay as part of our goal to maximize quality. =A0The consensus among our engineers is that the multiplier is closer to 1 than to 2, at lea= st for software VoIP applications over typical Internet connections. =A0Some years ago the situation was slightly worse because dial-up was more prevale= nt.



Similar 3X multiplier is also observed in VoIP gatew= ays. =A0Even with a fast processor/system optimized from ground up to be low-delay, the = measured "codec-dependent" one-way delay of such a VoIP gateway using the G.711 codec with a 5 ms frame/packet size is between 12 and 17 ms, or aroun= d 3X the frame size.

=A0

As I've pointed out before, that doesn't say= much about how the delay increases with larger frame sizes. =A0Perhaps the 12~17 ms includes a constant delay of 7 ms, and the marginal growth of delay with frame size is= 1x.

best,
koen.


_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

=A0


_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec


--0016e649d7c6e9a53804858ba0f1-- From trac@tools.ietf.org Sun May 2 01:04:37 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CDE33A69C6 for ; Sun, 2 May 2010 01:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.185 X-Spam-Level: X-Spam-Status: No, score=-101.185 tagged_above=-999 required=5 tests=[AWL=-1.185, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAufHrjU1H7l for ; Sun, 2 May 2010 01:04:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1EEBF3A69AA for ; Sun, 2 May 2010 01:04:36 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8UA0-00064b-UC; Sun, 02 May 2010 01:04:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 02 May 2010 08:04:20 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/23#comment:1 Message-ID: <071.f4f7f24c367b1973a158c5441a6a2b8b@tools.ietf.org> References: <062.b61c5855ce44adba1265c9026766b943@tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <062.b61c5855ce44adba1265c9026766b943@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #23: Impact of packet headers and header compression (was: Impact of packet headers etc.) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2010 08:04:37 -0000 #23: Impact of packet headers and header compression ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [JM]: I tend to say that 20 ms is still the most widely used frame size, so we might as well optimise for that. This is not really a problem because as the frame size goes down, the overhead of the IP/UDP/RTP headers go up, so the codec bit-rate becomes a bit less of an issue. For example, with 5 ms frames, we would already be sending 64 kb/s worth of headers (excluding the link layer), so we might as well spend about as many bits on the actual payload as we spend on the headers. And with 64 kb/s of payload, we can actually have high-quality full-band audio. [JM]: About my comment about the overhead, my point was not to say that 64 kb/s overhead is necessarily unacceptable. My main point is that the codec's "sweet spot" should probably be such that the payload bit-rate be in the same order as the header overhead at the selected frame size. So when operating with 5 ms frames, since you're already paying 64 kb/s in headers, it's probably worth also having 64 kb/s of payload so that you can transmit full-band audio. On the other hand, when operating with 20 ms frames where the overhead is 16 kb/s, then a 16 kb/s payload is probably the sweet spot. That way you scale audio quality at the same time as you reduce latency. [Raymond]: Regarding your comment that the payload bit-rate should be the same order as the header bit-rate, although it seems to make sense intuitively, I think in reality there are situations where it may not make sense. For instance, in your example of a 5 ms frame/packet size with a 64 kb/s header bit-rate and 64 kb/s full-band audio bit-rate, what if an IP phone with a 8 kHz sampling rate is used to make a call? Then all the extra bit- rate spent on audio bandwidth above 3.4 kHz (or 4 kHz maximum) is wasted. Or what if the resulting 128 kb/s is too high for the link because the link still needs to support other data streams? Similarly, for the 20 ms frame size case, what if you want to transmit full-band audio and 16 kb/s just won't give you the high fidelity level you are looking for? I understand that you are only talking about a "sweet spot" and are not saying the payload bit-rate and the header bit-rate must be the same, but I am just saying that in certain situations the sweet spot may actually be somewhere else. Also, I think ideally we should do header compression to minimize the header bit-rate and increase the overall bit-rate efficiency of the system, then there is no "sweet spot" issue as discussed above. I understand that this may not be possible unless the networking gears support it at both ends, but just from a system perspective, it would seem to me that it doesn't make sense for speech/audio codec developers to try so hard to squeeze the speech/audio signal to as few bits as possible, only to see the packet header having very redundant and repetitive bits sent packet after packet. There are probably reasons why header compression is not more widely used (which I don't know since it's outside my expertise area), but from a system perspective, it just seems to me to be extremely unbalanced and inefficient to send so many unchanged bits in the header packet after packet, especially in light of the high degree of speech/audio compression done in the payload. [Koen]: Afaik, only RTP headers can be compressed between arbitrary Internet end points. You're still stuck with IP and UDP headers. [Raymond]: I am aware of a header compression technology for VoIP over Cable applications that can compress the header size to a very small fraction of the original size, but it is probably not widely used. [Koen]: Yes, header compression works between end-points on a cable. That's different from "between arbitrary Internet end points". [Christian]: IP header compression using ROHC is covered by patents ;-) [Koen]: And transmission delay increases (perhaps) linearly with the *packet size*, not with the *frame size*. For a 32 kbps codec with 5 ms frames, packets are just 30% smaller than with a 16 kbps codecs with 20 ms frames. [Stephen]: "Packet size" here has to include layer 2 overhead, not just IP overhead, making your argument even stronger. In the case of Ethernet, Layer-2 overhead is 38-42 bytes per packet (depending on whether a vlan tag is present), so it is about the same as the IP/UDP/RTP overhead. And of course there's encryption pads, VPN encapsulation, etc. that apply in many cases. [Christian]: To get a efficient, low power, and mobile device you have to consider the impact of packet scheduling. If packets are scheduled regular, the MAC protocol can work more efficient. The more irregular packet arrive, the more expensive a packet transmission gets. Actually, you can translate the cost of packet scheduling to bits per packet. Depending on the wireless technology, it might vary substantially. The worst case is 802.11b at 11 Mbps at long preamble - then, you can add about 1300 bytes to every packet just for physical headers and MAC scheduling. However, more modern technologies like LTE and IEEE 802.11n are much more efficient in terms of per packet overhead. [Stephen]: As we all know, the internet runs over multiple physical layers, and usually an end-to-end connection uses more than one physical layer. So I am not sure how we can translate layer 2 constraints into requirements for CODEC itself. I can see how it might impact the RTP packetization - allowing frames to be split across packets would allow media-aware devices to adjust the packetization to optimize delivery -- Ticket URL: codec From trac@tools.ietf.org Sun May 2 01:04:42 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8C093A69F4 for ; Sun, 2 May 2010 01:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+lTGjHNjsor for ; Sun, 2 May 2010 01:04:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3016A3A69ED for ; Sun, 2 May 2010 01:04:42 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8UA8-00064j-2j; Sun, 02 May 2010 01:04:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 02 May 2010 08:04:27 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/13#comment:3 Message-ID: <071.4cc6aa182977fd998ae464ed11eb0446@tools.ietf.org> References: <062.407382d901e5e6b8dea15d6e3ae1a2c8@tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <062.407382d901e5e6b8dea15d6e3ae1a2c8@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #13: reference use-cases and topologies! X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2010 08:04:43 -0000 #13: reference use-cases and topologies! ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: critical | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Colin]: See RFC 5117 [for topologies] -- Ticket URL: codec From trac@tools.ietf.org Sun May 2 01:05:35 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBFA43A69ED for ; Sun, 2 May 2010 01:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wgckXW6xH+Z for ; Sun, 2 May 2010 01:05:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2D2B93A69C6 for ; Sun, 2 May 2010 01:05:35 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8UAz-00067z-2T; Sun, 02 May 2010 01:05:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 02 May 2010 08:05:21 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/17#comment:1 Message-ID: <071.5efad967340a3b623c627a44bc4aeda7@tools.ietf.org> References: <062.4d06e5df10a25734771c5c65c2b40c5c@tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <062.4d06e5df10a25734771c5c65c2b40c5c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #17: Feedback and control loop? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2010 08:05:36 -0000 #17: Feedback and control loop? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Colin]: My suggestion would be that you specify how the codec can adapt based on the feedback that RTP/RTCP, and its various extensions, can provide. More on the style of "if you have this information, this is how you can adapt" than "you must use this information to adapt in this way". [Christian]: I would anyhow suggest to include the processing delay into the measurement of the end-to-end (acoustic round) trip time. Those measurements should be part of the control loop that optimizes the overall conversation call quality. -- Ticket URL: codec From trac@tools.ietf.org Sun May 2 01:32:30 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42D373A68C7 for ; Sun, 2 May 2010 01:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.183 X-Spam-Level: X-Spam-Status: No, score=-101.183 tagged_above=-999 required=5 tests=[AWL=-1.183, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHzk4fNd+FDa for ; Sun, 2 May 2010 01:32:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id AAE913A67B3 for ; Sun, 2 May 2010 01:32:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8Ub0-0003Z1-Fz; Sun, 02 May 2010 01:32:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 02 May 2010 08:32:14 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/24#comment:1 Message-ID: <071.e3c35995edbdbaccee3438f1a110069b@tools.ietf.org> References: <062.6a10c93c1a05ea5f21f5afc0b48f2660@tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <062.6a10c93c1a05ea5f21f5afc0b48f2660@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #24: Negotiation of codec parameters? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2010 08:32:30 -0000 #24: Negotiation of codec parameters? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [kpfleming@]: If our goal is to use RTP AVP/SAVP/AVPF/SAVPF profiles for transport (as seems likely), then differences in sample rates between stream offers must be listed separately in the SDP. Whether they have a different codec 'name' in the SDP or not seems less important, because the combination of the codec name and sample rate is required to uniquely identify the format in any case. Note that this is *sample rate*, and not bitstream rate. [Christian]: No, please not. Please keep the interface to the codec as simple as possible! In addition, one must consider the following requirements: 1) First, the sample rate MUST be changed dynamically to cope with varying transmission bandwidths. ... [Stephen]: Dynamically changing sample rates on the system level adds some complexity for RTP, since the timestamp granularity is supposed to be the sample rate. BTW, dynamically changing the sample rate may be in conflict with the idea of low-complexity compressed-domain mixing (even if the conversion is done internally). [Kevin]: If the desire is for the codec to be able to change sample rates to adjust to network conditions, then I agree with Stephen... the 'external' sample rate (input to the encoder and output from the decoder) should be fixed, and this is what would be negotiated in SDP and used for RTP timestamps. The codec can downsample in the encoder and upsample in the decoder if it has decided to transmit fewer bits across the network. [Stephen]: Something like: CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to optimize audio quality. This is free of any technology assumption about how the acoustic bandwidth is reduced. The MAY indicates that it is permissible. But if the CODEC algorithm doesn't need to reduce the acoustic bandwidth, then we are making no statement that it SHOULD (or SHOULD NOT). Kevin is distinguishing dynamic changes to the sample rate (for bandwidth management) from multiple fixed sample rates; and I agree that is a key distinction. I have not heard any clear application requirement for more than one fixed sampling rate. Though if there is such a requirement, IMHO we would have to negotiate the rate within SDP in the usual way, and it would affect the RTP timestamps, jitter buffers, etc. G.722.1 / G.722.1C is one precedent - it is the same core codec, but can run at two different sample rates (negotiated by SDP). [Christian]: It still might make sense to negotiate the maximal supported sampling rate via SDP or, if possible, to select one out of multiple sampling rates, if the audio receiver can cope with multiple rates well. The internal sampling frequency of the codec NEEDS NOT to be affected by the external sampling frequency. However, the decoder might want to signal to the encoder that the decoding is requiring too many computational resources and that a less complex coding mode (or a lower sampling frequency) should be taken. [Stephen]: This would make the signaling more complicated - personally I am not convinced it is worth it. I think a better avenue is to bound overall complexity, and to focus on dynamically adapting to network conditions (as opposed to dynamic complexity management). You can't dynamically negotiate complexity in many scenarios anyway - for instance it makes no sense if you are using multicast. [Christian]: > This would make the signaling more complicated - personally I am not convinced it is worth it. It is a difficult tradeoff. However, signaling overload is done in Skype. Such as signaling might be very useful for mobile devices, which want to save power and thus lower their CPU clock. Or wireless IP based headphones which do not have large batteries. I am thinking of signaling the states: overloaded, fine, and low. That should be enough for most operational cases. > I think a better avenue is to bound overall complexity, and to focus on dynamically adapting to network conditions (as opposed to dynamic complexity management). I just like to remind that the good old TCP does support both: congestion control to adapt to network conditions and flow control take into account an overloaded (=full) receiver. [Stephen]: TCP is a different case, since for this we are using RTCP to signal our feedback, and I don't think it has the facility you are envisioning. This concept seems pretty theoretical to me. If we need to manage complexity / quality tradeoffs, why not just use profiles (as AVC/H.264 does) or create a low complexity variant (like G.729A). I really don't see the need for dynamic complexity management. BTW, you seem to be assuming that a lower sample rate results in significantly less complexity. The savings there might not be as great as you think, especially if the receiver needs to resample anyway (to prevent those sound card limitations you were talking about before). [Roman]: RTCP is almost universally not implemented. The biggest VoIP gateway on the market does not generate RTCP. If we will rely on any RTCP functionality for bandwidth control it will probably be ignored. [Stephen]: Videoconferencing devices do almost always support RTCP. It is regrettable that so many VOIP devices do not. Anyway, I do not think our charter scope includes invention of a new mechanism for signaling the network quality. [Roman]: My remark about RTCP was to try to develop a CODEC that will function properly with RTCP absent. If we require RTCP based mechanisms in order for the CODEC to operate properly, this can impede the adoption of this CODEC. In no way do I propose to create new signaling mechanisms. [Stephen]: I rather like the idea of negotiating maximum audio bandwidth. For me that is different from dynamic complexity management, and is being signaled for a different purpose (wasting coded bits on unheard spectrum degrades the quality of the heard spectrum). {Ben]: Why would it need to be negotiated? For a suitably designed format, the encoder could choose not to waste bits on high frequencies without any negotiation or extra signalling. [...] I do agree that having "only one mode" would be ideal, to maximize interoperability. I wonder whether we can achieve high enough computational efficiency for this to be viable. [Koen]:Not all hardware supports arbitrary/high sampling rates. PSTN gateways don't go above 8 kHz. Same for some mobile devices. Without signaling, how would the encoder know that the farend decoder will not take advantage of frequencies above a certain threshold? [Ben]: When I say signalling, I mean signalling within the codec bitstream. The encoder can change its behavior based on knowledge of the receiver's configuration, but the bitstream does not need any extra signalling to indicate the change in behavior. If the receiver is a PSTN gateway, then an "internal codec rate" of 8 KHz would presumably produce as good quality/bitrate with lower encoder and decoder complexity. However, if we can make IWAC sufficiently low- complexity, operating at 48 KHz may be acceptable. It will help if we can structure the codec so that operating at lower bandwidth is very efficient. [Stephen]: When I said signaling I meant SDP, not anything in the bitstream itself. I was not excluding audio bandwidth changes mid-call as part of network adaptation. Though as we all agree this needs to be carefully designed. I agree it is best if the decoder does not require any knowledge of the SDP negotiation (or any other information beyond the RTP packet stream itself) in order to correctly decode the audio -- which I think is what you were concerned about. It would be a nice property if reducing the acoustic bandwidth also allowed the MIPS to be reduced, but I do not think it is a requirement; I'd personally rather manage complexity with a Low Complexity profile (if that is really needed), since then I could keep the acoustic bandwidth (accepting a higher bit rate instead). [Christian]: Negotiating codec parameters with SDP has a long tradition. Take for example µLaw (RTP payload type 0): Here you negotiate the sampling rate. Also, the number of channels are negotiated for many codecs. I think sampling rate and number of channels can be done with SDP. However, I would avoid other codec specific parameters. Especially, in case of AMR the negotiation is quite complex should be avoided for the Internet CODEC. [Stephen]: My point here was not that SDP negotiation should be avoided. I was tryiing to say that it is best if the RTP payload is complete (in the sense that it can be fully decoded even if you ignore the signaling, as long as you know the codec itself). For instance, if you negotiate the number of channels, it should be possible for the decoder to identify the number of channels from the RTP payload. There are codecs where this is not done. Though personally I think it is the best architectural approach, even if it costs some payload bits. One reason is that I think changing modes should be seamless, and there is a race condition between the signaling and the RTP payload. If you are adapting to network conditions, it is particularly useful to change on the fly. [Roni]: Negotiation of codec parameters is not a tradition it is needed if there are optional modes that the decoder can support in order to allow the sender to know if the receiver can receive the specific mode. If there are mandatory modes you may be able to provide the information in-band but this is not negotiation. Also note that while the signaling may use reliable channel the media path is not reliable and may suffer packet loss that may cause the loss of important parameters. We have such example in the H.264 parameter sets where they can be carried in the SDP for reliability on in-band as part of the payload. [Stephen]: Personally I favor carrying those H.264 parameter sets on the media path, since there are situations (switched multipoint calls for one) where the timing matters. With that use case, if reliable-but-too-late delivery occurs, there are decoding errors even if there is no packet loss. Though of course SDP transmission alone may be suitable for other applications, and it is perfectly legal to send them both ways. [Christian]: I am fine with dropping any SDP negotiation on codec parameters including sampling rate and channels. I like the idea of splitting signaling and transportation issues. But one question remains. We had the question on limiting the complexity for some kind of devices by choosing a lower sampling rate or a low number of channels. Shall this negotiation be done with SDP or inband? [Stephen]: All negotiation should be done with SDP (and should never be done in-band). And the RTP transport should be robust enough to permit seamless changes to any mode that is consistent with the negotiation (with no signaling). The first point I think is essential. The second reflects my own view on how RTP packetization should be done. [Christian]: I am getting confused… Do you mean that the parameter about sampling rate MUST be negotiated with SDP and not transmitted in-band? Or MUST NOT be negotiated inband but only transmitted inband? Inband means within RTP/RTCP/RTPextentions and/or the Internet CODEC payload. [Stephen]: In-band for me in this case means RTP only. Or in some other contexts RTP payload only. I think there is (a) negotiation - particularly defining what optional modes the receiver can handle. In the case of sample rates, number of channels, and any optional facilities, this is generally not changing mid-call. SDP is the right place for this. (SDP SHALL be used for this) (b) Feedback - messages related to QOS, packet loss, etc are what I mean by this. This should be done in RTCP, though given the lack of VOIP support perhaps there should be a SIP INFO backup path. Feedback should not be done with RTP. (c) Control - Per RFC 3551, RTCP can be used for "loosely controlled" sessions, but "may be fully or partially subsumed by a separate session control protocol". Given the statements on RTCP support in the VOIP infrastructure, we should be careful about putting unique controls in RTCP. However, it should not be done in RTP. Since most other audio codecs don't require this stuff, I suspect we won't either. Though we will see... (d) In-band (RTP). Not sure how else to say this. Ideally RTP streams carrying CODEC (with no out-of-band, no RTCP, no SDP parameter knowledge) can be decoded. That is, I think it should be possible to fully decode unencrypted CODEC bitstreams with only the RTP packets abstracted from Wireshark. Even if the operating mode changes mid-flight. RFC 5404 (G.719) is one example of a packetization that accomplishes this, but there are other packetization RFCs which do not. [Schwarz]: You should replace "SDP" by "SDP Offer/Anser" (protocol), in order to emphasize the requirement for a) indication and possibly b) negotiation of codec configurations. The number of potential parameters you are mentioning could result in a number of various codec configurations. If this is the case, then the SDP O/A extensions would be recommended: http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-sdp-media-capabilities/ which implies also support of http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-sdp-capability- negotiation/ [Instead of RFC 3264 defined SDP Offer/Answer, which may be sufficient for a single codec configuration, but definetely insufficient in case of multiple codec configurations] -- Ticket URL: codec From trac@tools.ietf.org Sun May 2 05:05:03 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 719C73A684C for ; Sun, 2 May 2010 05:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.55 X-Spam-Level: X-Spam-Status: No, score=-101.55 tagged_above=-999 required=5 tests=[AWL=-0.809, BAYES_20=-0.74, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cadY-J5ehBEz for ; Sun, 2 May 2010 05:05:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B77663A67F8 for ; Sun, 2 May 2010 05:05:02 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8Xuh-0000rZ-G4; Sun, 02 May 2010 05:04:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 02 May 2010 12:04:47 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/25 Message-ID: <062.fa1ef2502db4c466d61a6fc906191800@tools.ietf.org> X-Trac-Ticket-ID: 25 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #25: Supported audio contents X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2010 12:05:03 -0000 #25: Supported audio contents ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Which kind of audio content should be used to test the CODEC? Of course speech. Music at all rates? Mixed contents? What is about background noise and reverberations? Currently, the draft says: "Quality should be measured for multiple languages, including tonal languages. The case of multiple simultaneous voices (as sometimes happens in conferencing) should be evaluated as well." -- Ticket URL: codec From hoene@uni-tuebingen.de Sun May 2 05:11:45 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A99E83A68F0 for ; Sun, 2 May 2010 05:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.966 X-Spam-Level: X-Spam-Status: No, score=-3.966 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-fPxqlt030Q for ; Sun, 2 May 2010 05:11:44 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 453943A68C8 for ; Sun, 2 May 2010 05:11:43 -0700 (PDT) Received: from wm01.uni-tuebingen.de (wm01.uni-tuebingen.de [134.2.3.20]) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o42CBSnK011916; Sun, 2 May 2010 14:11:28 +0200 Received: by wm01.uni-tuebingen.de (Postfix, from userid 30) id 7C4B57241D7; Sun, 2 May 2010 14:11:27 +0200 (CEST) Received: from 178.2.215.148 ([178.2.215.148]) by webmail.uni-tuebingen.de (Horde Framework) with HTTP; Sun, 02 May 2010 14:11:27 +0200 Message-ID: <20100502141127.12023irv5xffij1r@webmail.uni-tuebingen.de> Date: Sun, 02 May 2010 14:11:27 +0200 From: "Dr. Christian Hoene" To: codec@ietf.org, codec issue tracker References: <062.fa1ef2502db4c466d61a6fc906191800@tools.ietf.org> In-Reply-To: <062.fa1ef2502db4c466d61a6fc906191800@tools.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.6) X-AntiVirus-Spam-Check: failed (checked by Avira MailGate: version: 3.0.0-4; spam filter version: unknown; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.224; VDF: 7.10.7.16; host: mx05); id=318-l0sojS Cc: codec@ietf.org Subject: Re: [codec] #25: Supported audio contents X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2010 12:11:45 -0000 Hi, some time ago I wrote that the CODEC shall support these contents: " At all bitrates the ACS must deliver speech in any language at good quality. The ACS must be tested for different speakers and at least with two languages and should support tonal languages as well. Frequently, speech needs to be transmitted not only without background noise but also at conditions including car, office and street noise. Background signals shall be considered not as the noise but as a part of the signals that convey information. Background signal can include background music at a SNR of 25 dB, office noise at a SNR of 20 dB, car noise at a SNR of 15 dB, babble Noise at a SNR of 25 dB, interfering talker at a SNR of 15 dB and street noise at a SNR of 20 dB. At high bitrates the quality must be excellent for any audio signal, especially music. Stereo is considered as a must. Also, for high quality audio conferencing, reverberant input signals should be considered for testing the modes. The speech and audio signals might have varying loudness. The transmission shall support a wide range of dynamics. The nominal input level of -36 dB, -26 dB and -16dB with respect to the overlapping bandwidth limit (OVL) point (-20 dBm0). " Actually, I copied those requirements from G.718. The testing plan for =20 G.719 considers mixed content (ads, film trailer, news with jingles) =20 and music (classical and modern). Are they important for the Internet CODEC as well? With best regards, Christian > #25: Supported audio contents > ------------------------------------+------------------------------------= --- > Reporter: hoene@=E2=80=A6 | Owner: > Type: defect | Status: new > Priority: major | Milestone: > Component: requirements | Version: > Severity: Active WG Document | Keywords: > ------------------------------------+------------------------------------= --- > Which kind of audio content should be used to test the CODEC? > Of course speech. Music at all rates? Mixed contents? What is about > background noise and reverberations? > > Currently, the draft says: "Quality should be measured for multiple > languages, including tonal languages. The case of multiple simultaneous > voices (as sometimes happens in conferencing) should be evaluated as > well." > > -- > Ticket URL: > codec > > From trac@tools.ietf.org Sun May 2 05:19:12 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26B563A68C4 for ; Sun, 2 May 2010 05:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZw7-Lowm9th for ; Sun, 2 May 2010 05:19:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 312213A68AE for ; Sun, 2 May 2010 05:19:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8Y8M-0007f1-Mt; Sun, 02 May 2010 05:18:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 02 May 2010 12:18:54 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/26 Message-ID: <062.e0143a819120da8641009b7ca8a91dcf@tools.ietf.org> X-Trac-Ticket-ID: 26 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #26: Comparing the CODEC to other codecs... X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2010 12:19:12 -0000 #26: Comparing the CODEC to other codecs... ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- With which other codecs shall the CODEC be compared to. The requirements document lists: o For narrowband: Speex (NB), GSM-FR, and iLBC(*) o For wideband: Speex (WB), G.722, G.722.1(*) o For super-wideband: Speex (UWB), G.722.1C(*) But aren't AMR, AMR-WB, G.719, and MP3 missing? How many comparisons shall be made? -- Ticket URL: codec From trac@tools.ietf.org Sun May 2 05:45:32 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64D133A695B for ; Sun, 2 May 2010 05:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.177 X-Spam-Level: X-Spam-Status: No, score=-101.177 tagged_above=-999 required=5 tests=[AWL=-1.177, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAHbYVMPqMox for ; Sun, 2 May 2010 05:45:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 028B33A691C for ; Sun, 2 May 2010 05:45:31 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8YXs-0007m6-Lz; Sun, 02 May 2010 05:45:16 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 02 May 2010 12:45:16 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/27 Message-ID: <062.5f24684b1812b35d7a153e141fffc149@tools.ietf.org> X-Trac-Ticket-ID: 27 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #27: Testing Impact on IP on Codec Performance X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2010 12:45:32 -0000 #27: Testing Impact on IP on Codec Performance ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- The CODEC shall be tested against realistic traces of IP packets. The draft writes "The actual packet loss "patterns" to be used in testing must be obtained from real packet loss traces collected on the Internet, rather than from loss models. These traces should be representative of the typical environments in which the applications of Section 2 operate. For example, traces related to VoIP calls should consider the loss patterns observed for typical home broadband and corporate connections." Hoene wrote " The testing of ACS and the quality characterization shall be performed with real network profiles such as with [TIA-921] or those given in the appendix [TS.26114-830], not with fixed set of "average distributed errors and losses". Later do not clearly reflect the Internet nature." The ITU-T has standardized G.1050 (aka TIA-921) and Telchemy is providing an open source implementation: http://www.ietf.org/mail-archive/web/avt/current/msg06710.html http://www.itu.int/rec/T-REC-G.1050-200711-I/en But then again, which glue (rate control, dejitter buffer) shall be used between IP and codec? -- Ticket URL: codec From trac@tools.ietf.org Sun May 2 05:46:28 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92AA3A698A for ; Sun, 2 May 2010 05:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.473 X-Spam-Level: X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLzpLQIFy8zW for ; Sun, 2 May 2010 05:46:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 389263A691C for ; Sun, 2 May 2010 05:46:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8YYo-00083k-0E; Sun, 02 May 2010 05:46:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 02 May 2010 12:46:13 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/27#comment:1 Message-ID: <071.a86f4ec559375b970017ef485e87767f@tools.ietf.org> References: <062.5f24684b1812b35d7a153e141fffc149@tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <062.5f24684b1812b35d7a153e141fffc149@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #27: Testing Impact of IP on Codec Performance (was: Testing Impact on IP on Codec Performance) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2010 12:46:28 -0000 #27: Testing Impact of IP on Codec Performance ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- -- Ticket URL: codec From trac@tools.ietf.org Sun May 2 06:10:44 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74D4E3A698E for ; Sun, 2 May 2010 06:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqmx91qA4KrY for ; Sun, 2 May 2010 06:10:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7EC0F3A695B for ; Sun, 2 May 2010 06:10:42 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8YwG-0006ML-Jy; Sun, 02 May 2010 06:10:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 02 May 2010 13:10:27 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/28 Message-ID: <062.23d5df12c0b3d27cb5b6b25801ab2a4d@tools.ietf.org> X-Trac-Ticket-ID: 28 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #28: Layered bit-stream X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2010 13:10:44 -0000 #28: Layered bit-stream ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Shall layered coding be supported? Who needs it? Can we drop this requirement? -- Ticket URL: codec From trac@tools.ietf.org Sun May 2 09:03:22 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A91E3A6A2D for ; Sun, 2 May 2010 09:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.545 X-Spam-Level: X-Spam-Status: No, score=-101.545 tagged_above=-999 required=5 tests=[AWL=-0.804, BAYES_20=-0.74, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vd1YsX03+T0d for ; Sun, 2 May 2010 09:03:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id ED5CD3A69CE for ; Sun, 2 May 2010 09:03:18 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8bdH-0006kT-6S; Sun, 02 May 2010 09:03:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 02 May 2010 16:03:03 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/14#comment:1 Message-ID: <071.e9aae5bb5ab172d79d732c721371a6c6@tools.ietf.org> References: <062.0a0a8ad9a1d9d19f0f66b4858f523549@tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <062.0a0a8ad9a1d9d19f0f66b4858f523549@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #14: VAD and CNG? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2010 16:03:22 -0000 #14: VAD and CNG? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Hoene]: Comfort noise used to be use to indicate that a transmission is ongoing. However, if high quality transmission shall be supported, artifical noise worsen the audio quality. Thus, the generation of idle channel noise should not be used to indicate that the call is still active. Instead, in case of transmission problems an acoustic or visual notification can be given. -- Ticket URL: codec From trac@tools.ietf.org Sun May 2 09:11:17 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49F403A6A38 for ; Sun, 2 May 2010 09:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.265 X-Spam-Level: X-Spam-Status: No, score=-101.265 tagged_above=-999 required=5 tests=[AWL=-1.079, BAYES_40=-0.185, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXsJlp33TEYo for ; Sun, 2 May 2010 09:11:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 954DE3A6A3B for ; Sun, 2 May 2010 09:11:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8bl0-0004AN-A1; Sun, 02 May 2010 09:11:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 02 May 2010 16:11:02 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/29 Message-ID: <062.7815381850dc9f0a504d2c451298e6bb@tools.ietf.org> X-Trac-Ticket-ID: 29 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #29: Packet loss concealment? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2010 16:11:17 -0000 #29: Packet loss concealment? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Any thoughts about the packet loss concealment? Extrapolation? Interpolation? Content specific? Mandatory or optional? Partial Redundancy? Combine Time stretching/loss concealment? Do we need adaptive loss resilience, packet loss robustness, and/or FEC? -- Ticket URL: codec From trac@tools.ietf.org Sun May 2 10:57:02 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E82A33A6AD3 for ; Sun, 2 May 2010 10:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsDI6DScfSUt for ; Sun, 2 May 2010 10:57:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 49BEF3A6A75 for ; Sun, 2 May 2010 10:57:02 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8dPM-0003MY-3o; Sun, 02 May 2010 10:56:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 02 May 2010 17:56:48 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/30 Message-ID: <062.c36de91b7a452074af754b94421f5053@tools.ietf.org> X-Trac-Ticket-ID: 30 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #30: Self-awareness X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2010 17:57:03 -0000 #30: Self-awareness ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Shall the CODEC be aware about the currently achieved speech and audio quality and the current acoustic round trip time? Shall the CODEC know that a link is failing or overloaded? Shall the CODEC be able to test himself (e.g., via feedback loops)? -- Ticket URL: codec From trac@tools.ietf.org Sun May 2 11:08:26 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F6EE3A68A7 for ; Sun, 2 May 2010 11:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.169 X-Spam-Level: X-Spam-Status: No, score=-101.169 tagged_above=-999 required=5 tests=[AWL=-1.169, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9t4XKyBtpMik for ; Sun, 2 May 2010 11:08:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 815FD3A6B1B for ; Sun, 2 May 2010 11:08:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O8daF-0003nv-CW; Sun, 02 May 2010 11:08:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 02 May 2010 18:08:03 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/17#comment:2 Message-ID: <071.1ac44de1d442be78da8321bab758d21c@tools.ietf.org> References: <062.4d06e5df10a25734771c5c65c2b40c5c@tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <062.4d06e5df10a25734771c5c65c2b40c5c@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #17: Feedback and control loop? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 May 2010 18:08:26 -0000 #17: Feedback and control loop? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Christian]: Requirement: Reliable on the Internet The ACS must be optimized towards acoustic real-time communications over the Internet, and must have the flexibility to adjust to the environment it operates in. Based on the quality of the end-to-end speech packet transmission, the codec should adapt its quality and delay to achieve an optimal benefit for the user. As most Internet transport, it should be used with a wide range of condition allowing a high reliability regardless the networking condition. The reliability of the audio transmission should be high, even in cases of low and varying bandwidth. This implies that the codec is used on top of a transport protocol that implements a congestion control algorithm and that the ACS adapts to changes of available bandwidth. For example, if the available transmission bandwidth is too low to allow the codec to transmit audio at a high quality, the application can lower the sampling, bit or frame rate of the stream at the cost of higher algorithmic delay or a degraded audio quality. Reiability and congestion control : The acoustic transmission should be reliable and robust. The ACS shall be not only robust against packet losses but also for periods of low bandwidth. The mean availability of the audio transmissions, calculated over all users, might be one of the metrics for assessing the performance of an Internet audio codec. The ACS should adapt to the current network situation. Also, the codecs of ACS themselves must be adaptable, because switching among multiple codecs is difficult to negotiate and unlikely to work well in situations of inter-operation. Responding to congestion is a more complex issue and out of the scope of this document. However, it shall be defined on how to use existing congestion control protocols like DCCP and TCP. The ACS shall provide the mechanisms that congestion control requires from the codec (i.e. bitrate/framerate adaptability). Because of the interactive nature of the acoustic transmission, the bidirectional transmission of audio content can be used for transmitting the required feedback and implementing a control loop. Side channel Congestion control should be must for all Internet applications also for the ACS. [RFC3550] suggests in Chapter 10 somewhere that the RTP profile should care for rate adaptation. Thus, the ACS should take advantage of a feedback loop for variable coding parameter control in order to allow a wide range of operation and to adapt to the the current available bandwidth and processing power. Congestion control per se is outside the review of this group, but providing the hooks for a congestion-control mechanism to interact with the codec is quite important. For example, running this codec on a TFRC-enabled or DCCP RTP stream - TFRC and DCCP need to be able to adjust (via the application) the bitrate of the codec in order to implement congestion control and perhaps adjust packetization periods/packet-rates. A side channel for adaptation can be added. This would make sense because in usage scenarios audio is always transmitted in both directions. Adding a control channel would give a real advantage to existing codec designs. Alternatively, such as side channel can be also added with alternative solutions, such as handling that communication in SIP/SDP and in RTP/RTCP. -- Ticket URL: codec From hoene@uni-tuebingen.de Sun May 2 22:02:42 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7722C3A6BE6 for ; Sun, 2 May 2010 22:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.931 X-Spam-Level: X-Spam-Status: No, score=-3.931 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id th7QpooY6wG8 for ; Sun, 2 May 2010 22:02:41 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id BE36D3A6BE5 for ; Sun, 2 May 2010 22:02:39 -0700 (PDT) Received: from hoeneT60 ([178.2.215.148]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4352HRN013980 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 3 May 2010 07:02:23 +0200 From: "Christian Hoene" To: References: <002e01cacab0$30c174c0$92445e40$@de> In-Reply-To: <002e01cacab0$30c174c0$92445e40$@de> Date: Mon, 3 May 2010 07:02:16 +0200 Message-ID: <000b01caea7d$d0ce8f10$726bad30$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrKsCdtwpSw1FXbTVG2gExdWSdl/AfzF6dg Content-Language: de X-AntiVirus-Spam-Check: failed (checked by Avira MailGate: version: 3.0.0-4; spam filter version: unknown; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.224; VDF: 7.10.7.17; host: mx05); id=7784-c1KqBs Subject: [codec] So many emails... X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 05:02:42 -0000 Hello Guys, Sorry for bombing you with emails this weekend.=20 First, I summarize the discussion and consolidate them in Trac comments. = Then, I went through my documents on codec requirements and tried to compare them with the current draft. For most things that are = missing and/or unclear I set up an issue on Trac. Now, most requirements should be listed (albeit not yet discussed or agreed upon). Trac sends out emails to all as soon as you make any changes. Thus, the = overload of emails... Christian --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ >-----Original Message----- >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Christian Hoene >Sent: Tuesday, March 23, 2010 6:42 PM >To: codec@ietf.org >Subject: [codec] Issue tracer and SVN > >Hi all, > >I just started to look in detail on the requirements document - please = give me some time to identify >all issues. I am comparing it >with other requirements document such as = http://tools.ietf.org/html/draft-hoene-avt-acs-requirements- >00 and the ITU and 3GPP >documents mention in this draft. > >In the meantime, I would suggest to >- Number all requirements and give them priorities >- Add the current versions of guideline and requirement xml drafts to = SVN > >With best regards, > > Christian > >--------------------------------------------------------------- >Dr.-Ing. Christian Hoene >Interactive Communication Systems (ICS), University of T=FCbingen >Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >http://www.net.uni-tuebingen.de/ > > > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From swmike@swm.pp.se Sun May 2 23:14:26 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3DFD3A6C1C for ; Sun, 2 May 2010 23:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.531 X-Spam-Level: X-Spam-Status: No, score=-4.531 tagged_above=-999 required=5 tests=[AWL=-0.882, BAYES_50=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNK0ssjYjARB for ; Sun, 2 May 2010 23:14:26 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by core3.amsl.com (Postfix) with ESMTP id D55AA3A6C10 for ; Sun, 2 May 2010 23:14:25 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 61F24A0; Mon, 3 May 2010 08:14:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 612D89C for ; Mon, 3 May 2010 08:14:06 +0200 (CEST) Date: Mon, 3 May 2010 08:14:06 +0200 (CEST) From: Mikael Abrahamsson To: codec@ietf.org In-Reply-To: <000b01caea7d$d0ce8f10$726bad30$@de> Message-ID: References: <002e01cacab0$30c174c0$92445e40$@de> <000b01caea7d$d0ce8f10$726bad30$@de> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [codec] So many emails... X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 06:14:26 -0000 On Mon, 3 May 2010, Christian Hoene wrote: > Hello Guys, > > Sorry for bombing you with emails this weekend. > > First, I summarize the discussion and consolidate them in Trac comments. Then, I went through my documents on codec requirements and > tried to compare them with the current draft. For most things that are missing and/or unclear I set up an issue on Trac. Now, most > requirements should be listed (albeit not yet discussed or agreed upon). Back after IETF75 I posted some network characteristics and examples of these, and how I thought the "solution" (not only the codec) should behave. There also was some discussion regarding where this should be handled and what part was codec and what was transport. Is there some agreement regarding these issues, and in that case, where could I read about that? is the email I'm talking about. -- Mikael Abrahamsson email: swmike@swm.pp.se From hoene@uni-tuebingen.de Mon May 3 00:34:48 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDF1A3A6962 for ; Mon, 3 May 2010 00:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.422 X-Spam-Level: X-Spam-Status: No, score=-4.422 tagged_above=-999 required=5 tests=[AWL=-0.773, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zijPa-AqcYhC for ; Mon, 3 May 2010 00:34:46 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id E431A3A684D for ; Mon, 3 May 2010 00:34:45 -0700 (PDT) Received: from hoeneT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o437YOgG029704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 May 2010 09:34:25 +0200 From: "Christian Hoene" To: "'Mikael Abrahamsson'" References: <002e01cacab0$30c174c0$92445e40$@de> <000b01caea7d$d0ce8f10$726bad30$@de> In-Reply-To: Date: Mon, 3 May 2010 09:34:23 +0200 Message-ID: <002101caea93$103e7060$30bb5120$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acrqh+ECG4fdQD7RRD+UM68mgDY3fgAB1wqQ Content-Language: de X-AntiVirus-Spam-Check: failed (checked by Avira MailGate: version: 3.0.0-4; spam filter version: unknown; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.224; VDF: 7.10.7.17; host: mx05); id=7784-8o0TeX Cc: codec@ietf.org Subject: Re: [codec] So many emails... X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 07:34:48 -0000 Hi Mikael, >Back after IETF75 I posted some network characteristics and examples of >these, and how I thought the "solution" (not only the codec) should >behave. There also was some discussion regarding where this should be >handled and what part was codec and what was transport. > >Is there some agreement regarding these issues, and in that case, where >could I read about that? #17: Feedback and control loop? http://www.ietf.org/mail-archive/web/codec/current/msg01522.html Koen wrote something about the impact of handovers many months ago. However, I do not find his email anymore. I made some comments at http://www.ietf.org/mail-archive/web/codec/current/msg00660.html > > is the >email I'm talking about. Let me cite the email again: >-----Original Message----- >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Michael Knappe >Sent: Tuesday, November 10, 2009 10:02 AM >To: Mikael Abrahamsson; codec@ietf.org >Subject: Re: [codec] questions to be answered > >Mikael, > >Thanks for the very useful industry examples and metrics. Handling of these examples fall either into >jitter buffer design (which so far in the BoF email correspondence, other than noting the need for >some form of adaptive jitter buffer algorithm, is being treated as largely outside the scope of the >proposed WG) Jitter buffering is not explicitly mentioned in the Codec BOF. However, it must be considered because the requirements regarding testing. As stated in http://www.ietf.org/mail-archive/web/codec/current/msg01527.html, we shall test the codec using real trace of IP packets. These tests can only be made with some kind of dejitter buffer between packets and codec. Thus, at some point of time, we must agree which playout buffer to take for the testing. Christian >or packet loss concealment (which IS often tied to the codec's design). As you've noted, >other than doing the best it can to maintain a balance between the impairment due to end-to-end >latency and impairment due to periods of packet loss concealment, there is really no crystal ball that >can be employed to recover large numbers of consecutively lost packets during wildly varying jitter >conditions. > >As you mention in your email, it is possible to more tightly couple PLC and the jitter buffer. For >instance, a proposed codec's decode operation could provide an intelligent feedback loop to the jitter >buffer at the receiving end to let it know how well it's packet loss concealment algorithm is >currently operating - for instance telling the jitter buffer to go ahead and rapidly increase its size >if the PLC algorithm is simply falling apart under enormous packet loss. There are also examples of >time varying / frequency invariant 'stretch' jitter buffers that are an integral component of the >codec design, and we should treat them as a whole while evaluating any such proposed codecs. > >Mike > > >On 11/10/09 12:03 AM, "Mikael Abrahamsson" wrote: > >On Mon, 9 Nov 2009, Henry Sinnreich wrote: > >> Metrics and values/numbers would be very interesting if you can share >> them, to better understand the requirements. Also to make sure in what >> usage scenarios they may occur. > >2 seconds jitter and 10% continous random packet loss should definitely be >handled gracefully (during the tsunami where several fiber optic cables >were severed in asia, packet loss from the region to the rest of the world >was continous 5-7% due to remaining paths being extremely congested). 2 >seconds is for multiple links in a row being full (typically Cisco 12000 >routers can buffer 600ms of data when congestion occurs). There are >numerous cases (ADSL2+ without interleave, high speed links with CRC >errors, ethernet duplex errors) where random packet loss can be seen. >Typically this is less than 1%, otherwise people tend to fix the problem >because TCP works very badly. > >We then have the 3G/wifi network issue, where jitter can also be at least >2 seconds, plus packet loss as well (some networks seem to buffer X >kilobytes, some Y number of packets, after that they tail drop. I've seen >both behaviours). > >Burst loss, where when you have a network re-route, you might lose >typically 0.05 - 2 seconds of data, and you might get re-ordering during >the convergence. Since this is a transient event, I don't think much can >be done about it but try to play data as they come in and just ignore out >of order packets. Perhaps jitter buffer should be increased when >out-of-order packets is seen, but when things calm down again it needs to >be reduced again. > >I've also seen networks which re-order packets constantly, I don't know >what the load-sharing algorithm used is, but I think the jitter buffer >size should be adapted and handle out of order packets so they're >presented to the codec correctly. > >When running voice over GSM GPRS, typically there is very low bandwidth >and high delay. Here bw should be kept as low as possible and the IP >header is a big overhead and pps should thus be kept at a minimum, for >instance 3-5 pps and the very lowest quality setting should be used. > >So, the SYSTEM (I'm not just talking codec here), as far as I can see it, >needs to gracefully handle at least 10% packet loss, out of order packets >(analyse the time they might be re-ordered and adapt jitter buffer >accordingly), or just plain jitter up to 2s. > >My reasoning here is mainly focused on voice over Internet, but as far as >I can see this applies to all sound, even though if it's not interactive I >guess the focus can be switched from low latency (it might be better for a >voice call to have lower latency than actually getting perfect sound) to >reliable sound delivery with higher latency (by increasing jitter buffer >and putting sound information in multiple packets so that single packet >loss doesn't mean silence in that interval). Basically I'd like to see >that as soon as jitter buffer is increased, the resiliancy to packet loss >should be increased as well by telling the other end that it can start to >do packet loss concealment information in the packets as well (whatever >it's called, I'm not a codec guy). If sender knows what the receiver >jitter buffer is, then this can be used to increase resiliency (I guess). > >Does this help? > >-- >Mikael Abrahamsson email: swmike@swm.pp.se >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec > >-- >Mikael Abrahamsson email: swmike@swm.pp.se >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From rchen@broadcom.com Tue May 4 16:27:20 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAE183A6985 for ; Tue, 4 May 2010 16:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.222 X-Spam-Level: X-Spam-Status: No, score=-0.222 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUoG5xtm95ox for ; Tue, 4 May 2010 16:27:16 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id ED3C63A6A24 for ; Tue, 4 May 2010 16:01:11 -0700 (PDT) Received: from [10.9.200.133] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 04 May 2010 16:00:45 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Tue, 4 May 2010 16:02:08 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Christian Hoene" Date: Tue, 4 May 2010 16:00:42 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcrimhyNUh3NLsf5RvSfcmuOhmvRfwBUwYUAAVLFoDAApwRsUA== Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> In-Reply-To: <002c01cae939$5c01f400$1405dc00$@de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67FE789731G114354521-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2010 23:27:21 -0000 Hi Christian, Sorry for the delay of my response. I was busy with other things and not a= vailable to respond to IETF emails until now. You wrote: > The arguments on costs of the gateways is raised often. Thus, it is worth= while to=20 > consider in-depth. > May I ask you for more information about the design of VoIP Gateways. Par= ticular, I am > interested in the partition between audio > processing and protocol stack on DSP and CPU. > Does DSP take over all codec processing? May the CPU do some parts of the= computation > before, during or after DSP does the signal > processing? [Raymond]: I asked an engineering manager who was deeply involved in the de= sign of high-density VoIP gateways. He said that in such gateways, due to t= he high number of voice channels (thousands) per box, a large number of DSP= s and micro-controllers are used, and they are usually structured in a hier= archical way. The DSPs typically take care of all speech codec processing,= echo cancellation, DMTF tone detection, and fax, etc. The DSPs are usuall= y divided into groups, with each groups of DSPs controlled by a single micr= o-controller, which handles things like RTP, jitter buffering, packetizatio= n, QoS statistics, and moving the voice traffic to and from the DSPs in the= group. Then, on top of that there may be higher-performance controllers, = each connected to many such groups of micro-controller + DSPs. These highe= r-performance controllers may handle things like call setup, UDP/IP/RTP, ro= uting to and from internal processor groups, and routing to and from extern= al networks/devices. > How do you count number of channels? Do all voice channels have the same = weight=20 > regardless their sampling rate? > Say suppose, if the mixing is done for 48kHz instead of 8kHz, how many re= source are we=20 > allowed to consume more? [Raymond]: I am not sure what you meant. The channel count is just counting= the actual physical voice channels that the gateway can handle simultaneou= sly; it is not a weighted sum. Are you thinking that a 48 kHz channel shoul= d be counted more than an 8 kHz channel because it requires more computatio= nal resources? Typical VoIP gateways only support 8 kHz telephone-bandwidth= speech, so 48 kHz is out of the picture. =20 With that said, the complexity difference between speech codecs can make a = big difference in the channel density. Let's say a VoIP gateway supports X= simultaneous voice channels running the G.711 codec. Since the complexity= of G.711 PCM is next to nothing, the complexity of each voice channel is d= ominated by the echo canceller (EC). Now if you replace the G.711 codec by= the G.729A codec which takes about 10 MIPS of computational complexity for= a full-duplex codec, that can easily decrease the channel density to X/2.5= per gateway, depending on the EC and other things. If you replace the G.7= 11 codec by the G.728 codec that takes 30+ MIPS, the channel density can ea= sily go down to X/4 ~ X/5 or worse. =20 Thus, if you choose a high-complexity codec, you would need to buy a lot mo= re VoIP gateways to support the same number of voice channels than if you u= se a low-complexity codec. The cost difference is very real and can be very= big. Raymond From rchen@broadcom.com Tue May 4 17:10:36 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 374933A687C for ; Tue, 4 May 2010 17:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.207 X-Spam-Level: X-Spam-Status: No, score=-0.207 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mPGJFRbrmiaU for ; Tue, 4 May 2010 17:10:24 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 64C3D3A657C for ; Tue, 4 May 2010 17:10:24 -0700 (PDT) Received: from [10.9.200.131] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 04 May 2010 17:10:00 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Tue, 4 May 2010 17:10:00 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Christian Hoene" , "codec@ietf.org" Date: Tue, 4 May 2010 17:09:53 -0700 Thread-Topic: [codec] #19: How large is the frame size depended delay / the serialization delay? Thread-Index: AcrpMp+sn+iSbbxBTgGizlvP/ru38wAG8FcgAKPVhSA= Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <002f01cae951$6d802d60$48808820$@de> In-Reply-To: <002f01cae951$6d802d60$48808820$@de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AigH CGxs DAAf DJOp DTif HIz7 Hxr2 IfbP Jsck LHRw MHcN MQKU PDSx Qw7w Sk9D WJ8m; 2; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAaABvAGUAbgBlAEAAdQBuAGkALQB0AHUAZQBiAGkAbgBnAGUAbgAuAGQAZQA=; Sosha1_v1; 7; {612FAF6A-FDEA-4305-BF94-20AD88568E7F}; cgBjAGgAZQBuAEAAYgByAG8AYQBkAGMAbwBtAC4AYwBvAG0A; Wed, 05 May 2010 00:09:53 GMT; UgBFADoAIABbAGMAbwBkAGUAYwBdACAAIwAxADkAOgAgAEgAbwB3ACAAbABhAHIAZwBlACAAaQBzACAAdABoAGUAIABmAHIAYQBtAGUAIABzAGkAegBlACAAZABlAHAAZQBuAGQAZQBkACAAZABlAGwAYQB5ACAALwAgAHQAaABlACAAcwBlAHIAaQBhAGwAaQB6AGEAdABpAG8AbgAgAGQAZQBsAGEAeQA/AA== x-cr-puzzleid: {612FAF6A-FDEA-4305-BF94-20AD88568E7F} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67FE68D238O196421366-01-01 Content-Type: multipart/alternative; boundary=_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B903454FAIRVEXCHCCR01c_ Subject: Re: [codec] #19: How large is the frame size depended delay / the serialization delay? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 00:10:37 -0000 --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B903454FAIRVEXCHCCR01c_ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Christian, Not all embedded processors can dynamically adjust their clock rate or adju= st it as frequently as once or twice per codec frame. Regarding the 10000-channel gateway example you gave, the actual processing= delay is MUCH larger than (frame size)/10000. Here are the reasons: (1) That (frame size)/10000 delay assumes that the gateway uses a single DS= P fast enough to handle 10000 channels simultaneously. No gateway is desig= ned that way since no DSP is that fast. Instead, typical VoIP gateways use= many, many DSPs, with each DSP handling only N voice channels, where N mig= ht be from single digit to a few dozens, so the actual time the DSP spent i= n processing the codec frame is (frame size)/N >> (frame size)/10000. (2) More importantly, the bulk of the processing delay is actually not the = (frame size)/N delay above, but the time that each voice channel spends wai= ting for their turn to get processed by the DSP, and other various bufferin= g delays and scheduling delays encountered by the DSPs and the micro-contro= llers, because there are so many voice channels that need to be handled sim= ultaneously, making the timing issue extremely complex. These delays depend= s on the codec frame size chosen. The engineering manager I mentioned in my last email (who is a different fr= om the IP phone expert I previously mentioned) told me that "the devil is i= n the details" and that excluding the jitter buffer delay and other codec-i= ndependent delays, a straightforward VoIP gateway implementation without pa= ying attention to minimizing delay may have a codec-dependent one-way delay= of 5X to 6X codec frame size because of all of the various delays of (2) a= bove due to complex timing issues that come with supporting so many channel= s simultaneously. Even after analyzing all delay components carefully and = "optimizing the delay to death" until there is no more room for delay reduc= tion, the worst-case one-way codec-dependent delay is still about 3X codec = frame size, excluding jitter and other codec-independent delay. This is an= independent corroboration of what the other IP phone expert said about the= codec-independent one-way delay of 3X codec frame size for VoIP gateways. = (The two of them worked on different projects in different companies.) My conclusion: while I am less familiar with VoIP soft client implementatio= ns on computers, at least for IP phones and VoIP gateways, the rule of thum= b that many engineers found to work well for codec-dependent one-way delay = is 3X (codec frame size) + other codec buffering delays (e.g. look-ahead an= d/or filtering delay). Raymond From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of C= hristian Hoene Sent: Saturday, May 01, 2010 10:12 AM To: codec@ietf.org Subject: Re: [codec] #19: How large is the frame size depended delay / the = serialization delay? Hi, I agree that serialization, processing, and implementation delay should be = distinguished. Assume a low-cost VoIP phone with its processing power being fully utilized= by one call: Then, the DSP/CPU needs an entire frame duration to encode an= d decode frames. Thus, the latency is increase by one frame length in addit= ion to the serialization delay, propagation delay, algorithmic delay, dejit= tering delay, echo cancelling delay, ... Running the chips at 100% load is= of course cost saving compared to add some more computational resource. Bu= t is this still a relevant issue today? I am not sure whether it always make sense for mobile device to run at 100%= load. Of course, from a energy consumption perceptive it make sense to run= CMOS circuit at the lowest possible frequency as power consumption drops q= uadratic. But maybe running the CPU/DSP at higher speed and switching to po= wer save mode if after the a frame has been decoded/encoded is be equally e= nergy efficient... Even if a gateways DSP is utilized fully, the processing delays must not be= very large. For example, take a gateway serving 10000 calls and all CPUs/D= SPs are at 100%. Then, the time needed for encoding/decoding should be fram= e duration/10000, if the encoding/decoding is well scheduled. Also, I do not think we shall consider implementation delay, which occurs d= ue to suboptimal implementation. For example, some years ago we tested the = RTT of two Linux softphones link directly together using G.711. It was 400m= s. The implementation delay could be a good performance metric to different= iate two otherwise equal products. Also, the algorithmic processing delay m= ight be subject to similar market optimization. Having said this, I would anyhow suggest to include the processing delay in= to the measurement of the end-to-end (acoustic round) trip time. Those mea= surements should be part of the control loop that optimizes the overall con= versation call quality. Christian --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of s= tephen botzko Sent: Saturday, May 01, 2010 3:31 PM To: Koen Vos Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? If the frame-size multiplier is due to serialization, then I agree with Koe= n's assessment. In fact on many connections the multiplier would be less t= han 1. Dial-up is of course the worst case here, and on those links the mul= tiplier ought to be close to 2. Variations due to congestion (and on some = links, polling) are (IMHO) better modeled as jitter. Gateways are another matter, with the delays being highly dependent on the = product architecture. Interupt latencies, context switching, bus architect= ures, etc. can dominate, so it is totally possible that reducing the frame = size might actually increase the latency (since it increases the packets pe= r second load on the gateway). So I agree with Koen on this as well. Anecdotal models based on industry experience can be useful guides - though= if we are going to use these models to drive requirements, I'd prefer some= thing more analytical. Stephen Botzko On Sat, May 1, 2010 at 2:07 AM, Koen Vos > wrote: Quoting "Raymond (Juin-Hwey) Chen": One-way delay =3D codec-independent delay + 3*(codec frame size) + (codec = look-ahead) + (codec filtering delay if any) This formula was obtained from an experienced engineer who has been working= on IP phones related fields for more than a decade, At Skype We have 100+ years of combined VoIP experience, and a focus on min= imizing delay as part of our goal to maximize quality. The consensus among= our engineers is that the multiplier is closer to 1 than to 2, at least fo= r software VoIP applications over typical Internet connections. Some years= ago the situation was slightly worse because dial-up was more prevalent. Similar 3X multiplier is also observed in VoIP gateways. Even with a fast = processor/system optimized from ground up to be low-delay, the measured "co= dec-dependent" one-way delay of such a VoIP gateway using the G.711 codec w= ith a 5 ms frame/packet size is between 12 and 17 ms, or around 3X the fram= e size. As I've pointed out before, that doesn't say much about how the delay incre= ases with larger frame sizes. Perhaps the 12~17 ms includes a constant del= ay of 7 ms, and the marginal growth of delay with frame size is 1x. best, koen. _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B903454FAIRVEXCHCCR01c_ Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Christian,

 

Not all embedded processors can dynamically adjust their clock = rate or adjust it as frequently as once or twice per codec frame.

 

Regarding the 10000-channel gateway example you gave, the actua= l processing delay is MUCH larger than (frame size)/10000.=A0 Here are the reasons:=

 

(1) That (frame size)/10000 delay assumes that the gateway uses= a single DSP fast enough to handle 10000 channels simultaneously.=A0 No gatew= ay is designed that way since no DSP is that fast.=A0 Instead, typical VoIP gatew= ays use many, many DSPs, with each DSP handling only N voice channels, where N = might be from single digit to a few dozens, so the actual time the DSP spent in processing the codec frame is (frame size)/N >> (frame size)/10000.

 

(2) More importantly, the bulk of the processing delay is actua= lly not the (frame size)/N delay above, but the time that each voice channel spends waiting for their turn to get processed by the DSP, and other various buffe= ring delays and scheduling delays encountered by the DSPs and the micro-controll= ers, because there are so many voice channels that need to be handled simultaneo= usly, making the timing issue extremely complex. These delays depends on the code= c frame size chosen.

 

The engineering manager I mentioned in my last email (who is a different from the IP phone expert I previously mentioned) told me that = 220;the devil is in the details” and that excluding the jitter buffer delay a= nd other codec-independent delays, a straightforward VoIP gateway implementati= on without paying attention to minimizing delay may have a codec-dependent one= -way delay of 5X to 6X codec frame size because of all of the various delays of = (2) above due to complex timing issues that come with supporting so many channe= ls simultaneously.=A0 Even after analyzing all delay components carefully and = “optimizing the delay to death” until there is no more room for delay reduction, = the worst-case one-way codec-dependent delay is still about 3X codec frame size= , excluding jitter and other codec-independent delay.=A0 This is an independe= nt corroboration of what the other IP phone expert said about the codec-independent one-way delay of 3X codec frame size for VoIP gateways. (The two of them worked on different projects in different companies.)

 

My conclusion: while I am less familiar with VoIP soft client implementations on computers, at least for IP phones and VoIP gateways, the rule of thumb that many engineers found to work well for codec-dependent one-way delay is 3X (codec frame size) + other codec buffering delays (e.g.= look-ahead and/or filtering delay).

 

Raymond

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Christian Hoene
Sent: Saturday, May 01, 2010 10:12 AM
To: codec@ietf.org
Subject: Re: [codec] #19: How large is the frame size depended delay= / the serialization delay?

 

Hi,

 

I agree that serialization, processing, and implementation delay should be distinguished.

 

Assume a low-cost VoIP phone with its processing po= wer being fully utilized by one call: Then, the DSP/CPU needs an entire frame d= uration to encode and decode frames. Thus, the latency is increase by one frame len= gth in addition to the serialization delay, propagation delay, algorithmic dela= y, dejittering delay, echo cancelling delay, ...=A0 Running the chips at 100% = load is of course cost saving compared to add some more computational resource. = But is this still a relevant issue today?

 

I am not sure whether it always make sense for mobi= le device to run at 100% load. Of course, from a energy consumption perceptive= it make sense to run CMOS circuit at the lowest possible frequency as power consumption drops quadratic. But maybe running the CPU/DSP at higher speed = and switching to power save mode if after the a frame has been decoded/encoded = is be equally energy efficient…

 

Even if a gateways DSP is utilized fully, the proce= ssing delays must not be very large. For example, take a gateway serving 10000 ca= lls and all CPUs/DSPs are at 100%. Then, the time needed for encoding/decoding should be frame duration/10000, if the encoding/decoding is well scheduled.=

 

Also, I do not think we shall consider implementati= on delay, which occurs due to suboptimal implementation. For example, some yea= rs ago we tested the RTT of two Linux softphones link directly together using G.711. It was 400ms. The implementation delay could be a good performance metric to differentiate two otherwise equal products. Also, the algorithmic processing delay might be subject to similar market optimization.

 

Having said this, I would anyhow suggest to include= the processing delay into the measurement of the end-to-end (acoustic round) tr= ip time.=A0 Those measurements should be part of the control loop that optimiz= es the overall conversation call quality.

 

Christian

 

------------------------------------------------------------= ---

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of T=FCb= ingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 <= br> http://www.net= .uni-tuebingen.de/

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = stephen botzko
Sent: Saturday, May 01, 2010 3:31 PM
To: Koen Vos
Cc: codec@ietf.org
Subject: Re: [codec] #16: Multicast?

 

If the = frame-size multiplier is due to serialization, then I agree with Koen's assessment.&nb= sp; In fact on many connections the multiplier would be less than 1. Dial-up is= of course the worst case here, and on those links the multiplier ought to be c= lose to 2.  Variations due to congestion (and on some links, polling) are (IMHO) better modeled as jitter. 

Gateways are another matter, with the delays being highly dependent on the product architecture.  Interupt latencies, context switching, bus architectures, etc. can dominate, so it is totally possible that reducing t= he frame size might actually increase the latency (since it increases the pack= ets per second load on the gateway).  So I agree with Koen on this as well= .

Anecdotal models based on industry experience can be useful guides - though= if we are going to use these models to drive requirements, I'd prefer somethin= g more analytical.

Stephen Botzko

On Sat, May 1, 2010 at 2:07 AM, Koen V= os <koen.vos@skype.net> wrote:

Quoting "Raymond (Juin-Hwey) Chen":

 One-way delay =3D codec-independ= ent delay + 3*(codec frame size) + (codec look-ahead) + (codec filtering delay if any= )

This formula was obtained from an experienced engineer who has been working= on IP phones related fields for more than a decade,

 

At Skype We have 100+ years of combine= d VoIP experience, and a focus on minimizing delay as part of our goal to maximize quality.  The consensus among our engineers is that the multiplier is closer to 1 than to 2, at least for software VoIP applications over typical Internet connections.  Some years ago the situation was slightly worse because dial-up was more prevalent.



Similar 3X multiplier is also observed= in VoIP gateways.  Even with a fast processor/system optimized from ground up = to be low-delay, the measured "codec-dependent" one-way delay of suc= h a VoIP gateway using the G.711 codec with a 5 ms frame/packet size is between= 12 and 17 ms, or around 3X the frame size.

 

As I've pointed out before, that doesn= 't say much about how the delay increases with larger frame sizes.  Perhaps t= he 12~17 ms includes a constant delay of 7 ms, and the marginal growth of dela= y with frame size is 1x.

best,
koen.


_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

 

--_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B903454FAIRVEXCHCCR01c_-- From rchen@broadcom.com Tue May 4 18:16:23 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02A063A698C for ; Tue, 4 May 2010 18:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.195 X-Spam-Level: X-Spam-Status: No, score=-0.195 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s09K5jFlmC83 for ; Tue, 4 May 2010 18:16:21 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 51B133A6995 for ; Tue, 4 May 2010 18:16:20 -0700 (PDT) Received: from [10.9.200.131] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 04 May 2010 18:15:56 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Tue, 4 May 2010 18:15:56 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Koen Vos" , "codec@ietf.org" Date: Tue, 4 May 2010 18:15:51 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: Acro9LURl2A6sjoqQQyK1rZVvgmFJAC8xHvA Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> In-Reply-To: <20100430230756.13687lc1s5o89gsc@mail.skype.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: BsSg Btj6 EXNO F4RZ Gkyo Hbn+ LrtI NDYV NVTN N/0E PsCu ScNg Sxb4 T3ua UY6a UhF5; 2; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAawBvAGUAbgAuAHYAbwBzAEAAcwBrAHkAcABlAC4AbgBlAHQA; Sosha1_v1; 7; {6D363085-0A56-480E-A56B-73C229C129F7}; cgBjAGgAZQBuAEAAYgByAG8AYQBkAGMAbwBtAC4AYwBvAG0A; Wed, 05 May 2010 01:15:51 GMT; UgBFADoAIABbAGMAbwBkAGUAYwBdACAAIwAxADYAOgAgAE0AdQBsAHQAaQBjAGEAcwB0AD8A x-cr-puzzleid: {6D363085-0A56-480E-A56B-73C229C129F7} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67FE194620S113846361-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 01:16:23 -0000 Hi Koen, I respect that Skype engineers have a lot of experience in VoIP soft client= s running on computers. Skype is the world leader in that area, no question= about that. However, here I am talking about the codec-dependent one-way = delay in typical IP phone and VoIP gateway implementations, which are quite= different from VoIP soft clients. How many of your 100+ years of combined= VoIP experience were spent in actually designing IP phones or VoIP gateway= s? =20 Regarding the 3X multiplier for VoIP gateways, I already stated clearly in = my original text that the 12 to 17 ms was the codec-dependent one-way delay= . There is no "constant delay of 7 ms" in that (if it were constant, it wo= uld not be codec-dependent). The whole 12 to 17 ms delay was proportional = to the codec frame size. As I said in my last email to Christian, there is another independent corro= boration by another person (who was deeply involved in VoIP gateway designs= ) that this 3*(codec frame size) worst-case codec-dependent one-way delay w= as about the lowest that can be achieved after they "optimized the delay to= death". What I didn't say is that this was actually for G.711 channels wi= th a 10 ms frame/packet size, where the actual processing time spent on enc= oding and decoding the 10 ms G.711 codec frame was next to nothing, and yet= the complex scheduling and buffering delays throughout the system, which a= re proportional to the 10 ms processing intervals, still added up to 3X fra= me size. Currently, 70% to 80% of the phone shipments to large enterprises are IP ph= ones. With small enterprises also counted, the overall average is about 60= % IP phones. The current industry projection is that within 5 years, the o= verall average would be 80% to 90% IP phones. (The large enterprises will p= robably be close to 100% IP phones by then.) Hence, there are already a hu= ge number of IP phones deployed, and in the future it would be almost all I= P phones in the workplace, especially in medium to large companies. I thin= k it would be a mistake for the IETF Internet codec to completely ignore su= ch IP phone applications, but if we want to address such a huge installed b= ase of IP phones, the 3*(codec frame size) delay is very real for IP phones= and it is desirable to have a low-delay mode for the IETF codec to enhance= the user experience when using the IETF codec in such IP phones. Raymond -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of K= oen Vos Sent: Friday, April 30, 2010 11:08 PM To: codec@ietf.org Subject: Re: [codec] #16: Multicast? Quoting "Raymond (Juin-Hwey) Chen": > One-way delay =3D codec-independent delay + 3*(codec frame size) + =20 > (codec look-ahead) + (codec filtering delay if any) > > This formula was obtained from an experienced engineer who has been =20 > working on IP phones related fields for more than a decade, At Skype We have 100+ years of combined VoIP experience, and a focus =20 on minimizing delay as part of our goal to maximize quality. The =20 consensus among our engineers is that the multiplier is closer to 1 =20 than to 2, at least for software VoIP applications over typical =20 Internet connections. Some years ago the situation was slightly worse =20 because dial-up was more prevalent. > Similar 3X multiplier is also observed in VoIP gateways. Even with =20 > a fast processor/system optimized from ground up to be low-delay, =20 > the measured "codec-dependent" one-way delay of such a VoIP gateway =20 > using the G.711 codec with a 5 ms frame/packet size is between 12 =20 > and 17 ms, or around 3X the frame size. As I've pointed out before, that doesn't say much about how the delay =20 increases with larger frame sizes. Perhaps the 12~17 ms includes a =20 constant delay of 7 ms, and the marginal growth of delay with frame =20 size is 1x. best, koen. _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From rchen@broadcom.com Tue May 4 18:56:14 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A82D3A69C3 for ; Tue, 4 May 2010 18:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zzndn3V+qpTt for ; Tue, 4 May 2010 18:55:43 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id C5B103A6898 for ; Tue, 4 May 2010 18:55:43 -0700 (PDT) Received: from [10.9.200.133] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 04 May 2010 18:55:14 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Tue, 4 May 2010 18:56:37 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Koen Vos" Date: Tue, 4 May 2010 18:55:11 -0700 Thread-Topic: [codec] #16: Multicast? (Bluetooth) Thread-Index: AcrpBHLO2ccEesD8TIS/TTbwa+emYQC7Lr4A Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <20100423011559.20246ayxdicd9vzz@mail.skype.net> <20100425040049.69785q4ih4vowtep@mail.skype.net> <20100501010047.65285zk6zval8ywf@mail.skype.net> In-Reply-To: <20100501010047.65285zk6zval8ywf@mail.skype.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67FE0F8831G114452481-01-01 Content-Type: multipart/alternative; boundary=_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B90345536IRVEXCHCCR01c_ Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? (Bluetooth) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 01:56:14 -0000 --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B90345536IRVEXCHCCR01c_ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Koen, In the same order as your numbered list below: (1) True, Bluetooth !=3D Internet for now, but why not look into the future= and explore what is possible and will be very good to have for the future? (2) Your argument here doesn't make sense to me. For PC-to-PC calls, there= is no reason to use an ultra-low-complexity mode, so you don't need to suf= fer the lower coding efficiency, and therefore your concern is not relevant= . For any call that involves a Bluetooth headset, it would be better to use= a low-complexity mode of the IETF codec on the Bluetooth headset than to g= o through CVSD transcoding and suffer the significant quality degradation o= f CVSD and the additional coding delay due to transcoding. (3) a) The reason in 2) is not a reason as I explained above. b) Didn't you say Moore's Law will take care of that? :-) Furthermore, I am= not sure it is necessary for the Bluetooth headset to run the entire VoIP = stack. c) It is not at all clear that doing PLC two times on each of the two lossy= links is necessarily better than doing PLC just once after the packets go = through the two lossy links. It may well be that the latter approach is be= tter, considering that the transcoding distortion of the second link may go= up substantially when encoding the output of the first PLC for the first l= ossy link. I) Standardizing two separate codecs takes more time and effort and require= s transcoding which increases total coding distortion and total coding dela= y. II) For you and some, it is out of the scope, but for others it is not. Di= fferent people have different views. My view is that if we can cover this = very useful usage scenario without too much trouble, why leave it out? Raymond -----Original Message----- From: Koen Vos [mailto:koen.vos@skype.net] Sent: Saturday, May 01, 2010 1:01 AM To: Raymond (Juin-Hwey) Chen Cc: codec@ietf.org Subject: RE: [codec] #16: Multicast? (Bluetooth) Hi Raymond, I continue to fail to see the connection between the Internet codec and Bluetooth, for the reasons below. (1) Bluetooth !=3D Internet: Bluetooth devices are wireless audio devices, not VoIP end points, and are indeed used mostly for (mobile) PSTN calls. (2) Diverging requirements: A codec/mode that meets the BT requirements for ultra-low complexity will have a relatively poor coding efficiency, resulting in lower audio quality and/or a higher bitrate. Both of these negatively impact the user experience over the Internet. Therefore, you do not want to run a BT codec over the Internet if you can use a more efficient codec instead. (3) Transcoding: Even when using a BT audio device, a well-designed VoIP end point will always transcode between the Internet codec and the BT codec, because: a) the reason given in 2) above b) the BT device lacks the CPU power and memory to run the entire VoIP s= tack c) it allows for a packet-loss concealment operation in between two lossy lags of the end-to-end connection. Note that such transcoding is also standard with DECT devices, where base stations even transcode between G.722 and G.722 (yes: twice the same codec). In short, there is no benefit from the BT and Internet codecs being modes of one and the same codec. This complete lack of overlap means that: I) it is better to standardize two separate codecs II) Bluetooth is out of scope for the Internet codec. best, koen. Quoting "Raymond (Juin-Hwey) Chen": > Hi Koen, > > For some reason the SPAM filter accidentally routed your email below > (sent last Sunday) to my junk email folder and I just saw it. Sorry > about the delay of my response. > > I agree that there are some fundamental differences in the > requirements for cellular codecs and Bluetooth codecs which caused > the codecs in these two types of devices to each go their own way. > However, these differences are (or can be) substantially smaller > between an Internet codec and Bluetooth codecs, so I think it is > easier for Internet devices and Bluetooth devices to use the same > codec to avoid the additional delay and coding distortion of > transcoding. > > (1) Royalty-free requirement: > Cellular codecs are usually royalty-bearing, and that's acceptable > in the cellular world. Not so with Bluetooth. Bluetooth devices > are meant to be simple and low cost. As such, Bluetooth SIG > basically only wants to standardize royalty-free technologies. > That's an important reason why they picked the CVSD codec, a > royalty-free old technology of 1970. We are trying to make the IETF > codec royalty-free, so in this regard this goal is consistent with > the Bluetooth SIG's royalty-free requirement for codec. > > (2) Bit-rate requirement: > Cellular radio spectrum is a limited, fixed resource that doesn't > change with time, and cellular operators spent billions of dollars > in radio spectrum auctions. Thus, it is extremely important for > cellular codecs to have bit-rates as low as possible, with an > average bit-rate often going below 1 bit/sample, to maximize the > number of cellular subscribers a given amount of radio spectrum can > support. In contrast, the bit-rate is not nearly as big a concern > for Bluetooth. Initially Bluetooth SIG picked the relatively > high-bit-rate 64 kb/s CVSD narrowband codec (8 bits/sample) for its > simplicity and royalty-free nature among other things. Since the > speeds of the Internet back bone and access networks keep growing > with time, the bit-rate of an Internet codec is also not nearly as > big a concern as in cellular codecs, and an Internet codec around 2 > bits/sample can have better trade-offs (e.g. higher quality, lower > delay, and lower complexity) for Internet applications than what > cellular codecs can provide. Incidentally, Bluetooth SIG is moving > toward 4 bits/sample. As you can see, in terms of the bit-rate > requirement, an Internet codec is much closer to Bluetooth codecs > than cellular codecs are. > > (3) Complexity requirement: > Bluetooth headsets have much lower processing power and much smaller > batteries than cell phones. The complexity of cellular codecs, > typically in the range of 20 to 40 MHz on a DSP, is too high to fit > most Bluetooth headsets. However, unlike cell phones and Bluetooth > headsets where each is a specific type of device with a relatively > narrow range of device complexity, Internet voice/audio applications > can potentially encompass a large variety of different device types, > from desktop computers at the high end with > 3 GHz multi-core CPU > to IP phones and possibly even Bluetooth headsets at the low end > with a processor of only a few tens of MHz. It is up to the IETF > codec WG how we want the complexity of the IETF codec to be. We can > standardize just one codec mode that works well for > computer-to-computer calls but can't fit in low-end devices, or we > can keep that mode but also have a low-complexity mode that can be > implemented in low-end devices. Frankly, I think the second > approach makes much more sense since it allows many more devices to > benefit from the IETF codec and enables the large number of > Bluetooth headset users to avoid the additional distortion and delay > associated with transcoding when making Internet calls. > > (4) Delay requirement: Due to the need for cellular codecs to > achieve bit-rates as low as possible, they sacrificed the coding > delay and used a 20 ms frame size, because using a 10 or 5 ms frame > size would increase the bit-rate for a given level of speech > quality. On the other hand, a Bluetooth headset needs to have a low > delay since its delay is added to the already long cell phone delay. > For the IETF codec, again it is up to the codec WG to decide what > kind of codec delay we want, and again I think it makes sense to > have a higher-delay, higher bit-rate efficiency mode for > bit-rate-sensitive applications and another low-delay mode for > delay-sensitive applications, since one size doesn't fit all. If > the IETF codec delay is forced to be one size, the resulting codec > will be (potentially very) suboptimal for some applications. > > You wrote: >> Do you think it's realistic for us to come up with a design that >> fulfills the needs of both worlds? > > With a one-size-fit-all approach, probably not, but with a > multi-mode approach, then I think so. > > Best Regards, > > Raymond > > -----Original Message----- > From: Koen Vos [mailto:koen.vos@skype.net] > Sent: Sunday, April 25, 2010 4:01 AM > To: Raymond (Juin-Hwey) Chen > Cc: codec@ietf.org > Subject: RE: [codec] #16: Multicast? (Bluetooth) > > Hi Raymond, > > You seem to suggest that the IETF Internet codec should fit Bluetooth > requirements in order to enable transcoding-free operation all the way > from the Internet, through the Internet-connected device, to the BT > wireless audio device. > > A similar argument would hold for ITU-T cellular codecs: AMR-WB and > G.718 could have been designed with BT as an application. In reality, > these codecs have very little in common with BT codecs, because of the > vastly different requirements in terms of > - complexity > - memory footprint > - bitrate > - scalability > - bit error robustness > - packet loss robustness. > > Do you think it's realistic for us to come up with a design that > fulfills the needs of both worlds? > > The alternative is to separately design codecs for Internet > applications and BT devices, and continue the practice of transcoding > on the Internet-connected device. That would have a better chance of > maximizing quality in all scenarios. > > best, > koen. > > > Quoting "Raymond (Juin-Hwey) Chen": > >> Hi Koen, >> >> Responding to your earlier email about Bluetooth headset application: >> >> (1) Although BT SIG standardization is a preferred route, it is >> technically feasible to negotiate and use a non-Bluetooth-SIG codec. >> >> (2) Someone familiar with BT SIG told me that it would probably take >> only 6 months to add an optional codec to the BT SIG spec and 12 to >> 18 months to add a mandatory codec. >> >> (3) The IETF codec is scheduled to be finalized in 14 months and >> submitted to IESG in 18 months. Even if we take the BT SIG route >> and take 6 to 18 months there. The total time of 2 to 3 years from >> now means the Moore's Law would only increase the CPU resources 2X >> to 3X, and definitely no more than 4X max, not 10X. >> >> (4) Most importantly, guess what, in the last several years the >> Bluetooth headset chips have been growing its processing power at a >> MUCH, MUCH slower rate than what the Moore's Law says it should. >> Sometimes they did not increase the speed at all for years. The >> reasons? The ASP (average sale price) of Bluetooth chips plummeted >> very badly, making it unattractive to invest significant resources >> to make them significantly faster. Also, for low-end and mid-end BT >> headsets, the BT chips were often considered "good enough" and there >> wasn't a strong drive to increase the computing resources. In >> addition, the BT headsets got smaller over the last few years; the >> corresponding reduction in battery size required a reduction in >> power consumption, which also limited how fast the processor speed >> could grow. In the next several years, it is highly likely that the >> computing capabilities of Bluetooth headset chips will continue to >> grow at a rate substantially below what's predicted by the Moore's >> Law. >> >> (5) Although Bluetooth supports G.711 as an optional codec, >> basically no one uses it because it is too sensitive to bit errors. >> Essentially all the BT mono headsets on the market today are >> narrowband (8 kHz sampling) headsets using CVSD. There isn't any >> real wideband support yet, so your comment about G.722 doesn't >> apply. Even after wideband-capable BT headsets come out, for many >> years to come the majority of the BT headsets (especially mid- to >> low-end) will still be narrowband only, running only CVSD. Hence, >> the quality degradation of the CVSD transcoding is real and will be >> with us for quite a while, so it is desirable for the IETF codec to >> have a low-complexity mode that can directly run on the BT headsets >> to avoid the quality degradation of CVSD when using BT headsets to >> make Internet phone calls. >> >> (6) Even if you could use G.711 or G.722 in the BT headsets, they >> both operate at 64 kb/s. A low-complexity mode of the IETF codec >> can operate at half or one quarter of that bit-rate. This will help >> conserve BT headsets' radio power because of the lower transmit duty >> cycle. It will also help the Bluetooth + WiFi co-existence >> technologies. >> >> (7) Already a lot of people are used to using Bluetooth headsets to >> make phone calls today. If they have a choice, many of these people >> will also want to use Bluetooth headsets to make Internet phone >> calls, not only through computers, but also through smart phones >> connected to WiFi or cellular networks. As more and more states and >> countries pass laws to ban the use of cell phones that are not in >> hands-free mode while driving, the number of Bluetooth headset users >> will only increase with time, and many of them will want to make >> Internet-based phone calls. >> >> Given all the above, I would argue that Bluetooth headset is a very >> relevant application that the IETF codec should address with a >> low-complexity mode. >> >> Best Regards, >> >> Raymond >> >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On >> Behalf Of Koen Vos >> Sent: Friday, April 23, 2010 1:16 AM >> To: codec@ietf.org >> Subject: Re: [codec] #16: Multicast? >> >> By the time the BlueTooth Special Interest Group will have adopted a >> future IETF codec standard, Moore's law will surely have multiplied >> CPU resources in the BT device by one order of magnitude..? Not sure >> it makes sense to apply today's BT constraints to tomorrow's codec. >> >> I'm not even convinced BlueTooth is a relevant use case for an >> Internet codec. BT devices are audio devices more than VoIP end >> points: BT always connects to the Internet through another device. >> You could simply first decode incoming packets and send PCM data to >> the BT device, or use a high-quality/high-bitrate codec like G.722. >> The requirements for BT devices and the Internet are just too >> different. Similarly, GSM phones use AMR on the network side and a >> different codec towards the BT device. The required transcoding >> causes no quality problems because BT supports high bitrates. >> >> best, >> koen. >> >> >> Quoting Raymond (Juin-Hwey) Chen: >> >>> Hi Christian, >>> >>> My comments about your question of CODEC requirements are in-line. >>> >>> Raymond >>> >>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On >>> Behalf Of Christian Hoene >>> Sent: Wednesday, April 21, 2010 12:27 PM >>> To: 'stephen botzko' >>> Cc: codec@ietf.org >>> Subject: Re: [codec] #16: Multicast? >>> >>> Hi, >>> >>> if we take those two scenarios (high quality and scalable >>> teleconferencing), what are then the CODEC requirements? >>> >>> High quality: >>> >>> - Quite the same requirement as an end-to-end audio >>> transmission: high quality and low latency. >>> [Raymond]: High quality is a given, but I would like to emphasize >>> the importance of low latency. >>> (1) It is well-known that the longer the latency, the lower the >>> perceived quality of the communication link. The E-model in the >>> ITU-T Recommendation G.107 models such communication quality in >>> MOS_cqe, which among other things depends on the so-called "delay >>> impairment factor" Id. Basically, MOS_cqe is a monotonically >>> decreasing function of increasing latency, and beyond about 150 ms >>> one-way delay, the perceived quality of the communication link drops >>> rapidly with further delay increase. >>> (2) The lower the latency, the less audible the echo, and thus the >>> lower the required echo return loss. Hence, lower latency means >>> easier echo control and simpler echo canceller, and as people >>> already mentioned previously, below a certain delay, an echo is >>> simply perceived as a harmless side-tone and no echo canceller is >>> needed. It seems to me that echo control in conference calls is more >>> difficult than in point-to-point calls. While I hardly ever heard >>> echoes in domestic point-to-point calls, in my experience with >>> conference calls at work, even with the G.711 codec (which has >>> almost no delay), sometimes I still hear echoes (I just heard >>> another one this afternoon). If a relatively long-delay IETF codec >>> is used, the echo control will be even more problematic. >>> (3) In normal phone calls or conference calls, people routinely have >>> a need to interrupt each other, but beyond a certain point, long >>> latency makes it very difficult for people to interrupt each other >>> on the call. This is because when you try to interrupt another >>> person, that person doesn't hear your interruption until a certain >>> time later, so he keeps talking, but when you hear that he did not >>> stop talking when you interrupted, you stop; then, he hears your >>> interruption, so he stops. When you hear he stops, you start talking >>> again, but then he also hears you stopped (due to the long delay), >>> so he also starts talking again. The net result is that with a long >>> latency, when you try to interrupt him, you and he end up stopping >>> and starting at roughly the same time for a few cycles, making it >>> difficult to interrupt each other. >>> (4) We need to keep in mind that the IETF codec may not be the only >>> codec involved in a phone call or a conference call. We cannot >>> assume that all conference call participants will be using a >>> computer to conduct the call. Not only do people use cell phones for >>> point-to-point phone calls, they also often use cell phones to call >>> in to conference calls. The one-way delay for a cell phone call >>> through one carriers network is typically around 80 to 110 ms. A >>> call from a cell phone in a carrier network to another cell phone in >>> a different type of carrier network can easily double this delay to >>> 160 ~ 220 ms and makes the total one-way delay already far exceeding >>> the 150 ms mentioned in (1) above. Any coding delay added by the >>> IETF codec will be on top of that long delay, and such coding delay >>> will be applied twice when both cell phones call through the IETF >>> codec to a conference bridge. Even without the IETF codec delay, >>> when I previously called from a Verizon cell phone to an AT&T cell >>> phone, I already experienced the problem mentioned in (3) sometimes. >>> If the IETF codec has a relatively long delay, adding two times the >>> IETF codec one-way delay to the already long delay of 160 ~ 220 ms >>> will make the situation much worse. Even if just one cell phone is >>> involved in a conference call, adding twice the one-way delay of a >>> relatively long-delay IETF codec can still easily push the total >>> one-way delay beyond 150 ms. >>> To summarize, my point is that to help reduce potential echo >>> problems and to ensure a high-quality experience in such a >>> conference call, the IETF codec should have a delay as low as >>> possible while maintaining good enough speech quality and a >>> reasonable bit-rate. >>> >>> - Maybe additionally: variable bit rate encoding to achieve >>> a multiplexing gain at the receiver >>> >>> - and thus, a fast control loop to cope with variable >>> bitrates on transmission paths. >>> >>> - Maybe stereo/multichannel support to send the spatial >>> audio to the headphone or loudspeakers. >>> >>> Scalable: >>> >>> - Efficient encoding/transcoding for multiple different >>> qualities (at the conference bridge) >>> [Raymond]: I am not sure whether by "efficient", you meant coding >>> efficiency or computational efficiency. In any case, I would like >>> to take this opportunity to express my view that although codec >>> complexity isn't much of an issue for PC-to-PC calls where there are >>> GHz of processing power available, the codec complexity is an >>> important issue in certain application scenarios. The following are >>> just some examples. >>> 1) If a conference bridge has to decode a large number of voice >>> channels, mix, and re-encode, and if compressed-domain mixing cannot >>> be done (which is usually the case), then it is important to keep >>> the decoder complexity low. >>> 2) In topology b) of your other email >>> (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, >>> or VoIP gateway, often has to encode and decode thousands of voice >>> channels in a single box, so not only the computational complexity, >>> but also the per-instance RAM size requirement of the codec become >>> very important for achieving high channel density in the gateway. >>> 3) Many telephone terminal devices at the edge of the Internet use >>> embedded processors with limited processing power, and the >>> processors also have to handle many tasks other than speech coding. >>> If the IETF codec complexity is too high, some of such devices may >>> not have sufficient processing power to run it. Even if the codec >>> can fit, some battery-powered mobile devices may prefer to run a >>> lower-complexity codec to reduce power consumption and battery >>> drain. For example, even if you make a Internet phone call from a >>> computer, you may like the convenience of using a Bluetooth headset >>> that allows you to walk around a bit and have hands-free operation. >>> Currently most Bluetooth headsets have small form factors with a >>> tiny battery. This puts a severe constraint on power consumption. >>> Bluetooth headset chips typically have very limited processing >>> capability, and it has to handle many other tasks such as echo >>> cancellation and noise reduction. There is just not enough >>> processing power to handle a relatively high-complexity codec. Most >>> BT headsets today relies on the extremely low-complexity, >>> hardware-based CVSD codec at 64 kb/s to transmit narrowband voice, >>> but CVSD has audible coding noise, so it degrades the overall audio >>> quality. If the IETF codec has low enough complexity, it would be >>> possible to directly encode and decode the IETF codec bit-stream at >>> the BT headset, thus avoiding the quality degradation of CVSD >>> transcoding. >>> In summary, my point is that the IETF codec should attempt to >>> achieve a codec complexity as low as possible in both MHz >>> consumption and RAM size requirement while maintaining good enough >>> speech quality. >>> >>> - The control loop must not react (fast) because >>> (multicast) group communication requires to encode at low quality >>> anyhow. >>> >>> - Receiver side activity detection for music and voice >>> having low complexity (for the conference bridge) >>> >>> - Efficient mixing of two to four(?) active flows (is this >>> achievable without the complete process of decoding and encoding >>> again?) >>> >>> Are any teleconferencing requirements missing? >>> >>> Christian >>> >>> >>> >>> >>> --------------------------------------------------------------- >>> Dr.-Ing. Christian Hoene >>> Interactive Communication Systems (ICS), University of T=FCbingen >>> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >>> http://www.net.uni-tuebingen.de/ >>> >>> From: stephen botzko [mailto:stephen.botzko@gmail.com] >>> Sent: Wednesday, April 21, 2010 8:19 PM >>> To: Christian Hoene >>> Cc: codec@ietf.org >>> Subject: Re: [codec] #16: Multicast? >>> >>> Inline >>> On Wed, Apr 21, 2010 at 1:27 PM, Christian Hoene >>> > wrote: >>> Hi Stephen, >>> >>> not too bad. You answered faster than the mailing list distributes... >>> Not sure how that happened! >>> >>> Comments inline: >>> >>> >>> From: stephen botzko >>> [mailto:stephen.botzko@gmail.com] >>> Sent: Wednesday, April 21, 2010 7:10 PM >>> To: Christian Hoene >>> Cc: codec@ietf.org >>> >>> Subject: Re: [codec] #16: Multicast? >>> >>> I agree there are lots of use cases. >>> >>> >>> Though I don't see why high quality has to be given up in order to >>> be scalable. >>> CH: These are just experiences from our lab. A spatial audio >>> conference server including the acoustic 3D sound rendering needs a >>> LOT of processing power. In the end, we have to remain realistic. >>> Processing power is always limited thus if we need a lot then we >>> cannot serve many clients. >>> Also, I am not sure why you think central mixing is more scalable >>> than multicast (or why you think it is lower quality either). >>> CH: With multicast, you need N times 1:N multicast distribution >>> trees (somewhat small tan O(n)=3Dn=B2). With central mixing you need N >>> times 2 transmission paths (O(n)=3Dn). Also, this distributed mixing >>> you need N times the mixing at each client. With centralized, you >>> can live with one mixing for all (and some tricks for serving the >>> talkers). >>> I agree you need more distribution trees for multicast if you allow >>> every site to talk. There is a corresponding benefit, since there is >>> no central choke point and also less bandwidth on shared WAN links. >>> >>> In the distributed case, you don't need an N-way mixer at each >>> client, and you also don't need to continuously receive payload on >>> all N streams at each client either. In practice you can cap N at a >>> relatively small number (in the 3-8 range) no matter how large the >>> conference gets. In a large conference, you can even choose to drop >>> your comfort noise if you are receiving two or more streams, and >>> just send enough to keep your firewall pinhole open. This is all >>> assuming a suitable voice activity measure in the RTP packet. Of >>> course in the worst case, you will receive all N streams. >>> >>> Cheers, >>> Christian >>> >>> Stephen Botzko >>> On Wed, Apr 21, 2010 at 12:58 PM, Christian Hoene >>> > wrote: >>> Hi, >>> >>> the teleconferencing issue gets complex. I am trying to compile the >>> different requirements that have been mentioned on this list. >>> >>> - low complexity (with just one active speaker) vs. >>> multiple speaker mixing vs. spatial audio/stereo mixing >>> >>> - centralized vs. distributed >>> >>> - few participants vs. hundreds of listeners and talkers >>> >>> - individual distribution of audio streams vs. IP multicast >>> or RTP group communication >>> >>> - efficient encoding of multiple streams having the same >>> content (but different quality). >>> >>> - I bet I missed some. >>> >>> To make things easier, why not to split the teleconferencing >>> scenario in two: High quality and Scalable? >>> >>> The high quality scenario, intended for a low number of users, could >>> have features like >>> >>> - Distributed processing and mixing >>> >>> - High computational resources to support spatial audio >>> mixing (at the receiver) and multiple encodings of the same audio >>> stream at different qualities (at the sender) >>> >>> - Enough bandwidth to allow direct N to N transmissions of >>> audio streams (no multicast or group communication). This would be >>> good for the latency, too. >>> >>> The scalable scenario is the opposite: >>> >>> - Central processing and mixing for many participants . >>> >>> - N to 1 and 1 to N communication using efficient >>> distribution mechanisms (RTP group communication and IP multicast). >>> >>> - Low complexity mixing of many using tricks like VAD, >>> encoding at lowest rate to support many receivers having different >>> paths, you name it... >>> >>> Then, we need not to compare apples with oranges all the time. >>> >>> Christian >>> >>> --------------------------------------------------------------- >>> Dr.-Ing. Christian Hoene >>> Interactive Communication Systems (ICS), University of T=FCbingen >>> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >>> http://www.net.uni-tuebingen.de/ >>> >>> From: codec-bounces@ietf.org >>> [mailto:codec-bounces@ietf.org] On >>> Behalf Of stephen botzko >>> Sent: Wednesday, April 21, 2010 4:34 PM >>> To: Colin Perkins >>> Cc: trac@tools.ietf.org; >>> codec@ietf.org >>> Subject: Re: [codec] #16: Multicast? >>> >>> in-line >>> >>> Stephen Botzko >>> On Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins >>> > wrote: >>> On 21 Apr 2010, at 12:20, Marshall Eubanks wrote: >>> On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote: >>> On 21 Apr 2010, at 10:42, codec issue tracker wrote: >>> #16: Multicast? >>> ------------------------------------+---------------------------------- >>> Reporter: hoene@... | Owner: >>> Type: enhancement | Status: new >>> Priority: trivial | Milestone: >>> Component: requirements | Version: >>> Severity: Active WG Document | Keywords: >>> ------------------------------------+---------------------------------- >>> The question arrose whether the interactive CODEC MUST support >>> multicast in addition to teleconferencing. >>> >>> On 04/13/2010 11:35 AM, Christian Hoene wrote: >>> P.S. On the same note, does anybody here cares about using this >>> CODEC with multicast? Is there a single commercial multicast voice >>> deployment? From what I've seen all multicast does is making IETF >>> voice standards harder to understand or implement. >>> >>> I think that would be a mistake to ignore multicast - not because of >>> multicast itself, but because of Xcast (RFC 5058) which is a >>> promising technology to replace centralized conference bridges. >>> >>> Regarding multicast: >>> >>> I think we shall start at user requirements and scenarios. >>> Teleconference (including mono or spatial audio) might be good >>> starting point. Virtual environments like second live would require >>> multicast communication, too. If the requirements of these scenarios >>> are well understand, we can start to talk about potential solutions >>> like IP multicast, Xcast or conference bridges. >>> >>> >>> RTP is inherently a group communication protocol, and any codec >>> designed for use with RTP should consider operation in various >>> different types of group communication scenario (not just >>> multicast). RFC 5117 is a good place to start when considering the >>> different types of topology in which RTP is used, and the possible >>> placement of mixing and switching functions which the codec will >>> need to work with. >>> >>> It is not clear to me what supporting multicast would entail here. >>> If this is a codec over RTP, then what is to stop it from being >>> multicast ? >>> >>> Nothing. However group conferences implemented using multicast >>> require end system mixing of potentially large numbers of active >>> audio streams, whereas those implemented using conference bridges do >>> the mixing in a single central location, and generally suppress all >>> but one speaker. The differences in mixing and the number of >>> simultaneous active streams that might be received potentially >>> affect the design of the codec. >>> >>> Conference bridges with central mixing almost always mix multiple >>> speakers. As you add more streams into the mix, you reduce the >>> chance of missing onset speech and interruptions, but raise the >>> noise floor. So even if complexity is not a consideration, there is >>> value in gating the mixer (instead of always doing a full mix-minus). >>> >>> More on point, compressed domain mixing and easy detection of VAD >>> have both been advocated on these lists, and both simplify the >>> large-scale mixing problem. >>> >>> -- >>> Colin Perkins >>> http://csperkins.org/ >>> >>> >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>> >>> >>> >>> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> >> > > > > --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B90345536IRVEXCHCCR01c_ Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Koen,

 

In the same order as your numbered list below:=

 

(1) True, Bluetooth !=3D Internet for now, but why = not look into the future and explore what is possible and will be very good to have = for the future?

 

(2) Your argument here doesn't make sense to me.=A0= For PC-to-PC calls, there is no reason to use an ultra-low-complexity mode, so = you don't need to suffer the lower coding efficiency, and therefore your concer= n is not relevant. For any call that involves a Bluetooth headset, it would be better to use a low-complexity mode of the IETF codec on the Bluetooth head= set than to go through CVSD transcoding and suffer the significant quality degradati= on of CVSD and the additional coding delay due to transcoding.

 

(3)

a) The reason in 2) is not a reason as I explained = above.

b) Didn’t you say Moore’s Law will take= care of that? :-) Furthermore, I am not sure it is necessary for the Bluetooth headset to run the entire VoIP stack.

c) It is not at all clear that doing PLC two times = on each of the two lossy links is necessarily better than doing PLC just once after the packets go through the two lossy links.=A0 It may well be that th= e latter approach is better, considering that the transcoding distortion of t= he second link may go up substantially when encoding the output of the first P= LC for the first lossy link.

 

I) Standardizing two separate codecs takes more tim= e and effort and requires transcoding which increases total coding distortion and total coding delay.

 

II) For you and some, it is out of the scope, but f= or others it is not.=A0 Different people have different views.=A0 My view is t= hat if we can cover this very useful usage scenario without too much trouble, why = leave it out?

 

Raymond

 

-----Original Message-----
From: Koen Vos [mailto:koen.vos@skype.net]
Sent: Saturday, May 01, 2010 1:01 AM
To: Raymond (Juin-Hwey) Chen
Cc: codec@ietf.org
Subject: RE: [codec] #16: Multicast? (Bluetooth)

 

Hi Raymond,

 

I continue to fail to see the connection between th= e Internet codec=A0

and Bluetooth, for the reasons below.

 

(1) Bluetooth !=3D Internet:

Bluetooth devices are wireless audio devices, not V= oIP end points, and=A0

are indeed used mostly for (mobile) PSTN calls.

 

(2) Diverging requirements:

A codec/mode that meets the BT requirements for ult= ra-low complexity=A0

will have a relatively poor coding efficiency, resu= lting in lower=A0

audio quality and/or a higher bitrate.=A0 Both of t= hese negatively=A0

impact the user experience over the Internet.=A0 Th= erefore, you do not=A0

want to run a BT codec over the Internet if you can= use a more=A0

efficient codec instead.

 

(3) Transcoding:

Even when using a BT audio device, a well-designed = VoIP end point will=A0

always transcode between the Internet codec and the= BT codec, because:

=A0=A0 a) the reason given in 2) above

=A0=A0 b) the BT device lacks the CPU power and mem= ory to run the entire VoIP stack

=A0=A0 c) it allows for a packet-loss concealment o= peration in between two=A0

lossy lags of the end-to-end connection.=

Note that such transcoding is also standard with DE= CT devices, where=A0

base stations even transcode between G.722 and G.72= 2 (yes: twice the=A0

same codec).

 

In short, there is no benefit from the BT and Inter= net codecs being=A0

modes of one and the same codec.=A0 This complete l= ack of overlap means=A0

that:

=A0=A0 I) it is better to standardize two separate = codecs

=A0 II) Bluetooth is out of scope for the Internet = codec.

 

best,

koen.

 

 

 

Quoting "Raymond (Juin-Hwey) Chen":<= /o:p>

 

> Hi Koen,

> 

> For some reason the SPAM filter accidentally r= outed your email below=A0

> (sent last Sunday) to my junk email folder and= I just saw it. Sorry=A0

> about the delay of my response.

> 

> I agree that there are some fundamental differ= ences in the=A0

> requirements for cellular codecs and Bluetooth codecs which caused=A0

> the codecs in these two types of devices to ea= ch go their own way.=A0=A0

> However, these differences are (or can be) substantially smaller=A0

> between an Internet codec and Bluetooth codecs= , so I think it is=A0

> easier for Internet devices and Bluetooth devi= ces to use the same=A0

> codec to avoid the additional delay and coding distortion of=A0

> transcoding.

> 

> (1) Royalty-free requirement:

> Cellular codecs are usually royalty-bearing, a= nd that's acceptable=A0

> in the cellular world.=A0 Not so with Bluetoot= h.=A0 Bluetooth devices=A0

> are meant to be simple and low cost.=A0 As suc= h, Bluetooth SIG=A0

> basically only wants to standardize royalty-fr= ee technologies.=A0=A0

> That's an important reason why they picked the= CVSD codec, a=A0

> royalty-free old technology of 1970.=A0 We are= trying to make the IETF=A0

> codec royalty-free, so in this regard this goa= l is consistent with=A0

> the Bluetooth SIG's royalty-free requirement f= or codec.

> 

> (2) Bit-rate requirement:

> Cellular radio spectrum is a limited, fixed re= source that doesn't=A0

> change with time, and cellular operators spent billions of dollars=A0

> in radio spectrum auctions. Thus, it is extrem= ely important for=A0

> cellular codecs to have bit-rates as low as possible, with an=A0

> average bit-rate often going below 1 bit/sampl= e, to maximize the=A0

> number of cellular subscribers a given amount = of radio spectrum can=A0

> support.=A0 In contrast, the bit-rate is not n= early as big a concern=A0

> for Bluetooth. Initially Bluetooth SIG picked = the relatively=A0

> high-bit-rate 64 kb/s CVSD narrowband codec (8 bits/sample) for its=A0

> simplicity and royalty-free nature among other things.=A0 Since the=A0

> speeds of the Internet back bone and access ne= tworks keep growing=A0

> with time, the bit-rate of an Internet codec i= s also not nearly as=A0

> big a concern as in cellular codecs, and an In= ternet codec around 2=A0

> bits/sample can have better trade-offs (e.g. h= igher quality, lower=A0

> delay, and lower complexity) for Internet applications than what=A0

> cellular codecs can provide.=A0 Incidentally, Bluetooth SIG is moving=A0

> toward 4 bits/sample.=A0 As you can see, in te= rms of the bit-rate=A0

> requirement, an Internet codec is much closer = to Bluetooth codecs=A0

> than cellular codecs are.

> 

> (3) Complexity requirement:

> Bluetooth headsets have much lower processing = power and much smaller=A0

> batteries than cell phones. The complexity of cellular codecs,=A0

> typically in the range of 20 to 40 MHz on a DS= P, is too high to fit=A0

> most Bluetooth headsets. However, unlike cell = phones and Bluetooth=A0

> headsets where each is a specific type of devi= ce with a relatively=A0

> narrow range of device complexity, Internet voice/audio applications=A0

> can potentially encompass a large variety of different device types,=A0

> from desktop computers at the high end with &g= t; 3 GHz multi-core CPU=A0

> to IP phones and possibly even Bluetooth heads= ets at the low end=A0

> with a processor of only a few tens of MHz.=A0= It is up to the IETF=A0

> codec WG how we want the complexity of the IET= F codec to be.=A0 We can=A0

> standardize just one codec mode that works wel= l for=A0

> computer-to-computer calls but can't fit in lo= w-end devices, or we =A0

> can keep that mode but also have a low-complex= ity mode that can be=A0

> implemented in low-end devices.=A0 Frankly, I = think the second=A0

> approach makes much more sense since it allows= many more devices to=A0

> benefit from the IETF codec and enables the la= rge number of=A0

> Bluetooth headset users to avoid the additiona= l distortion and delay=A0

> associated with transcoding when making Intern= et calls.

> 

> (4) Delay requirement: Due to the need for cel= lular codecs to=A0

> achieve bit-rates as low as possible, they sacrificed the coding=A0

> delay and used a 20 ms frame size, because usi= ng a 10 or 5 ms frame=A0

> size would increase the bit-rate for a given l= evel of speech=A0

> quality.=A0 On the other hand, a Bluetooth hea= dset needs to have a low=A0

> delay since its delay is added to the already = long cell phone delay.=A0

>=A0 For the IETF codec, again it is up to the c= odec WG to decide what=A0

> kind of codec delay we want, and again I think= it makes sense to=A0

> have a higher-delay, higher bit-rate efficienc= y mode for=A0

> bit-rate-sensitive applications and another low-delay mode for=A0

> delay-sensitive applications, since one size d= oesn't fit all.=A0 If=A0

> the IETF codec delay is forced to be one size,= the resulting codec=A0

> will be (potentially very) suboptimal for some applications.

> 

> You wrote:

>> Do you think it's realistic for us to come= up with a design that

>> fulfills the needs of both worlds?

> 

> With a one-size-fit-all approach, probably not= , but with a=A0

> multi-mode approach, then I think so.

> 

> Best Regards,

> 

> Raymond

> 

> -----Original Message-----

> From: Koen Vos [mailto:koen.vos@skype.net]

> Sent: Sunday, April 25, 2010 4:01 AM

> To: Raymond (Juin-Hwey) Chen

> Cc: codec@ietf.org

> Subject: RE: [codec] #16: Multicast? (Bluetoot= h)

> 

> Hi Raymond,

> 

> You seem to suggest that the IETF Internet cod= ec should fit Bluetooth

> requirements in order to enable transcoding-fr= ee operation all the way

> from the Internet, through the Internet-connec= ted device, to the BT

> wireless audio device.

> 

> A similar argument would hold for ITU-T cellul= ar codecs: AMR-WB and

> G.718 could have been designed with BT as an application.=A0 In reality,

> these codecs have very little in common with B= T codecs, because of the

> vastly different requirements in terms of=

> - complexity

> - memory footprint

> - bitrate

> - scalability

> - bit error robustness

> - packet loss robustness.

> 

> Do you think it's realistic for us to come up = with a design that

> fulfills the needs of both worlds?<= /p>

> 

> The alternative is to separately design codecs= for Internet

> applications and BT devices, and continue the practice of transcoding

> on the Internet-connected device.=A0 That woul= d have a better chance of

> maximizing quality in all scenarios.

> 

> best,

> koen.

> 

> 

> Quoting "Raymond (Juin-Hwey) Chen":<= o:p>

> 

>> Hi Koen,

>> 

>> Responding to your earlier email about Blu= etooth headset application:

>> 

>> (1) Although BT SIG standardization is a preferred route, it is

>> technically feasible to negotiate and use = a non-Bluetooth-SIG codec.

>> 

>> (2) Someone familiar with BT SIG told me t= hat it would probably take

>> only 6 months to add an optional codec to = the BT SIG spec and 12 to

>> 18 months to add a mandatory codec.

>> 

>> (3) The IETF codec is scheduled to be fina= lized in 14 months and

>> submitted to IESG in 18 months.=A0 Even if= we take the BT SIG route

>> and take 6 to 18 months there.=A0 The tota= l time of 2 to 3 years from

>> now means the Moore's Law would only incre= ase the CPU resources 2X

>> to 3X, and definitely no more than 4X max,= not 10X.

>> 

>> (4) Most importantly, guess what, in the l= ast several years the

>> Bluetooth headset chips have been growing = its processing power at a

>> MUCH, MUCH slower rate than what the Moore= 's Law says it should.

>> Sometimes they did not increase the speed = at all for years.=A0 The

>> reasons? The ASP (average sale price) of Bluetooth chips plummeted

>> very badly, making it unattractive to inve= st significant resources

>> to make them significantly faster.=A0 Also= , for low-end and mid-end BT

>> headsets, the BT chips were often consider= ed "good enough" and there

>> wasn't a strong drive to increase the comp= uting resources.=A0 In

>> addition, the BT headsets got smaller over= the last few years; the

>> corresponding reduction in battery size re= quired a reduction in

>> power consumption, which also limited how = fast the processor speed

>> could grow.=A0 In the next several years, = it is highly likely that the

>> computing capabilities of Bluetooth headse= t chips will continue to

>> grow at a rate substantially below what's predicted by the Moore's

>> Law.

>> 

>> (5) Although Bluetooth supports G.711 as a= n optional codec,

>> basically no one uses it because it is too sensitive to bit errors.

>> Essentially all the BT mono headsets on th= e market today are

>> narrowband (8 kHz sampling) headsets using CVSD.=A0 There isn't any

>> real wideband support yet, so your comment= about G.722 doesn't

>> apply.=A0 Even after wideband-capable BT h= eadsets come out, for many

>> years to come the majority of the BT heads= ets (especially mid- to

>> low-end) will still be narrowband only, ru= nning only CVSD. Hence,

>> the quality degradation of the CVSD transc= oding is real and will be

>> with us for quite a while, so it is desira= ble for the IETF codec to

>> have a low-complexity mode that can direct= ly run on the BT headsets

>> to avoid the quality degradation of CVSD w= hen using BT headsets to

>> make Internet phone calls.

>> 

>> (6) Even if you could use G.711 or G.722 i= n the BT headsets, they

>> both operate at 64 kb/s.=A0 A low-complexi= ty mode of the IETF codec

>> can operate at half or one quarter of that bit-rate.=A0 This will help

>> conserve BT headsets' radio power because = of the lower transmit duty

>> cycle.=A0 It will also help the Bluetooth = + WiFi co-existence

>> technologies.

>> 

>> (7) Already a lot of people are used to us= ing Bluetooth headsets to

>> make phone calls today.=A0 If they have a = choice, many of these people

>> will also want to use Bluetooth headsets t= o make Internet phone

>> calls, not only through computers, but als= o through smart phones

>> connected to WiFi or cellular networks.=A0= As more and more states and

>> countries pass laws to ban the use of cell phones that are not in

>> hands-free mode while driving, the number = of Bluetooth headset users

>> will only increase with time, and many of = them will want to make

>> Internet-based phone calls.

>> 

>> Given all the above, I would argue that Bluetooth headset is a very

>> relevant application that the IETF codec s= hould address with a

>> low-complexity mode.

>> 

>> Best Regards,

>> 

>> Raymond

>> 

>> -----Original Message-----

>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On

>> Behalf Of Koen Vos

>> Sent: Friday, April 23, 2010 1:16 AM<= /o:p>

>> To: codec@ietf.org

>> Subject: Re: [codec] #16: Multicast?<= /o:p>

>> 

>> By the time the BlueTooth Special Interest= Group will have adopted a

>> future IETF codec standard, Moore's law wi= ll surely have multiplied

>> CPU resources in the BT device by one orde= r of magnitude..?=A0 Not sure

>> it makes sense to apply today's BT constra= ints to tomorrow's codec.

>> 

>> I'm not even convinced BlueTooth is a rele= vant use case for an

>> Internet codec.=A0 BT devices are audio de= vices more than VoIP end

>> points: BT always connects to the Internet through another device.

>> You could simply first decode incoming pac= kets and send PCM data to

>> the BT device, or use a high-quality/high-bitrate codec like G.722.

>> The requirements for BT devices and the In= ternet are just too

>> different.=A0 Similarly, GSM phones use AM= R on the network side and a

>> different codec towards the BT device.=A0 = The required transcoding

>> causes no quality problems because BT supp= orts high bitrates.

>> 

>> best,

>> koen.

>> 

>> 

>> Quoting Raymond (Juin-Hwey) Chen:

>> 

>>> Hi Christian,

>>> 

>>> My comments about your question of COD= EC requirements are in-line.

>>> 

>>> Raymond

>>> 

>>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On

>>> Behalf Of Christian Hoene

>>> Sent: Wednesday, April 21, 2010 12:27 = PM

>>> To: 'stephen botzko'

>>> Cc: codec@ietf.org

>>> Subject: Re: [codec] #16: Multicast?

>>> 

>>> Hi,

>>> 

>>> if we take those two scenarios (high q= uality and scalable

>>> teleconferencing), what are then the C= ODEC requirements?

>>> 

>>> High quality:

>>> 

>>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Quite the= same requirement as an end-to-end audio

>>> transmission: high quality and low lat= ency.

>>> [Raymond]: High quality is a given, bu= t I would like to emphasize

>>> the importance of low latency.

>>> (1) It is well-known that the longer t= he latency, the lower the

>>> perceived quality of the communication link.=A0 The E-model in the

>>> ITU-T Recommendation G.107 models such communication quality in

>>> MOS_cqe, which among other things depe= nds on the so-called "delay

>>> impairment factor" Id.=A0 Basical= ly, MOS_cqe is a monotonically

>>> decreasing function of increasing late= ncy, and beyond about 150 ms

>>> one-way delay, the perceived quality o= f the communication link drops

>>> rapidly with further delay increase.

>>> (2) The lower the latency, the less au= dible the echo, and thus the

>>> lower the required echo return loss.= =A0 Hence, lower latency means

>>> easier echo control and simpler echo canceller, and as people

>>> already mentioned previously, below a certain delay, an echo is

>>> simply perceived as a harmless side-to= ne and no echo canceller is

>>> needed. It seems to me that echo contr= ol in conference calls is more

>>> difficult than in point-to-point calls= .=A0 While I hardly ever heard

>>> echoes in domestic point-to-point call= s, in my experience with

>>> conference calls at work, even with th= e G.711 codec (which has

>>> almost no delay), sometimes I still he= ar echoes (I just heard

>>> another one this afternoon).=A0 If a relatively long-delay IETF codec

>>> is used, the echo control will be even= more problematic.

>>> (3) In normal phone calls or conferenc= e calls, people routinely have

>>> a need to interrupt each other, but be= yond a certain point, long

>>> latency makes it very difficult for pe= ople to interrupt each other

>>> on the call.=A0 This is because when y= ou try to interrupt another

>>> person, that person doesn't hear your interruption until a certain

>>> time later, so he keeps talking, but w= hen you hear that he did not

>>> stop talking when you interrupted, you= stop; then, he hears your

>>> interruption, so he stops. When you he= ar he stops, you start talking

>>> again, but then he also hears you stop= ped (due to the long delay),

>>> so he also starts talking again.=A0 Th= e net result is that with a long

>>> latency, when you try to interrupt him= , you and he end up stopping

>>> and starting at roughly the same time = for a few cycles, making it

>>> difficult to interrupt each other.

>>> (4) We need to keep in mind that the I= ETF codec may not be the only

>>> codec involved in a phone call or a conference call.=A0 We cannot

>>> assume that all conference call partic= ipants will be using a

>>> computer to conduct the call. Not only= do people use cell phones for

>>> point-to-point phone calls, they also = often use cell phones to call

>>> in to conference calls.=A0 The one-way= delay for a cell phone call

>>> through one carriers network is typica= lly around 80 to 110 ms.=A0 A

>>> call from a cell phone in a carrier ne= twork to another cell phone in

>>> a different type of carrier network ca= n easily double this delay to

>>> 160 ~ 220 ms and makes the total one-w= ay delay already far exceeding

>>> the 150 ms mentioned in (1) above.=A0 = Any coding delay added by the

>>> IETF codec will be on top of that long delay, and such coding delay

>>> will be applied twice when both cell p= hones call through the IETF

>>> codec to a conference bridge.=A0 Even = without the IETF codec delay,

>>> when I previously called from a Verizo= n cell phone to an AT&T cell

>>> phone, I already experienced the probl= em mentioned in (3) sometimes.

>>>=A0 If the IETF codec has a relatively = long delay, adding two times the

>>> IETF codec one-way delay to the alread= y long delay of 160 ~ 220 ms

>>> will make the situation much worse.=A0= Even if just one cell phone is

>>> involved in a conference call, adding = twice the one-way delay of a

>>> relatively long-delay IETF codec can s= till easily push the total

>>> one-way delay beyond 150 ms.

>>> To summarize, my point is that to help reduce potential echo

>>> problems and to ensure a high-quality experience in such a

>>> conference call, the IETF codec should= have a delay as low as

>>> possible while maintaining good enough speech quality and a

>>> reasonable bit-rate.

>>> 

>>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Maybe add= itionally: variable bit rate encoding to achieve

>>> a multiplexing gain at the receiver

>>> 

>>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 and thus,= a fast control loop to cope with variable

>>> bitrates on transmission paths.

>>> 

>>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Maybe ste= reo/multichannel support to send the spatial

>>> audio to the headphone or loudspeakers= .

>>> 

>>> Scalable:

>>> 

>>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Efficient= encoding/transcoding for multiple different

>>> qualities (at the conference bridge)

>>> [Raymond]: I am not sure whether by "efficient", you meant coding

>>> efficiency or computational efficiency= .=A0 In any case, I would like

>>> to take this opportunity to express my= view that although codec

>>> complexity isn't much of an issue for PC-to-PC calls where there are

>>> GHz of processing power available, the= codec complexity is an

>>> important issue in certain application scenarios.=A0 The following are

>>> just some examples.

>>> 1) If a conference bridge has to decod= e a large number of voice

>>> channels, mix, and re-encode, and if compressed-domain mixing cannot

>>> be done (which is usually the case), t= hen it is important to keep

>>> the decoder complexity low.=

>>> 2) In topology b) of your other email<= o:p>

>>> (IPend-to-transcoding_gateway-to-PSTNe= nd), the transcoding gateway,

>>> or VoIP gateway, often has to encode a= nd decode thousands of voice

>>> channels in a single box, so not only = the computational complexity,

>>> but also the per-instance RAM size requirement of the codec become

>>> very important for achieving high chan= nel density in the gateway.

>>> 3) Many telephone terminal devices at = the edge of the Internet use

>>> embedded processors with limited proce= ssing power, and the

>>> processors also have to handle many ta= sks other than speech coding.

>>> If the IETF codec complexity is too hi= gh, some of such devices may

>>> not have sufficient processing power t= o run it.=A0 Even if the codec

>>> can fit, some battery-powered mobile d= evices may prefer to run a

>>> lower-complexity codec to reduce power consumption and battery

>>> drain.=A0 For example, even if you mak= e a Internet phone call from a

>>> computer, you may like the convenience= of using a Bluetooth headset

>>> that allows you to walk around a bit a= nd have hands-free operation.

>>> Currently most Bluetooth headsets have= small form factors with a

>>> tiny battery.=A0 This puts a severe co= nstraint on power consumption.

>>> Bluetooth headset chips typically have= very limited processing

>>> capability, and it has to handle many = other tasks such as echo

>>> cancellation and noise reduction.=A0 T= here is just not enough

>>> processing power to handle a relativel= y high-complexity codec.=A0 Most

>>> BT headsets today relies on the extrem= ely low-complexity,

>>> hardware-based CVSD codec at 64 kb/s t= o transmit narrowband voice,

>>> but CVSD has audible coding noise, so = it degrades the overall audio

>>> quality.=A0 If the IETF codec has low = enough complexity, it would be

>>> possible to directly encode and decode= the IETF codec bit-stream at

>>> the BT headset, thus avoiding the qual= ity degradation of CVSD

>>> transcoding.

>>> In summary, my point is that the IETF = codec should attempt to

>>> achieve a codec complexity as low as possible in both MHz

>>> consumption and RAM size requirement w= hile maintaining good enough

>>> speech quality.

>>> 

>>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 The contr= ol loop must not react (fast) because

>>> (multicast) group communication requir= es to encode at low quality

>>> anyhow.

>>> 

>>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Receiver = side activity detection for music and voice

>>> having low complexity (for the confere= nce bridge)

>>> 

>>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Efficient= mixing of two to four(?) active flows (is this

>>> achievable without the complete proces= s of decoding and encoding

>>> again?)

>>> 

>>> Are any teleconferencing requirements missing?

>>> 

>>>=A0 Christian

>>> 

>>> 

>>> 

>>> 

>>> ---------------------------------------------------------------<= /p>

>>> Dr.-Ing. Christian Hoene

>>> Interactive Communication Systems (ICS= ), University of T=FCbingen

>>> Sand 13, 72076 T=FCbingen, Germany, Ph= one +49 7071 2970532

>>> http://www.net.uni-tuebingen.de/<= /o:p>

>>> 

>>> From: stephen botzko [mailto:stephen.botzko@gmail.com]

>>> Sent: Wednesday, April 21, 2010 8:19 P= M

>>> To: Christian Hoene

>>> Cc: codec@ietf.org

>>> Subject: Re: [codec] #16: Multicast?

>>> 

>>> Inline

>>> On Wed, Apr 21, 2010 at 1:27 PM, Chris= tian Hoene

>>> <hoene@uni-tuebingen.de<mailto:hoene@uni-tuebingen.de>> wrote:<= o:p>

>>> Hi Stephen,

>>> 

>>> not too bad. You answered faster than = the mailing list distributes...

>>> Not sure how that happened!=

>>> 

>>> Comments inline:

>>> 

>>> 

>>> From: stephen botzko

>>> [mailto:stephen.botzko@gmail.com<mailto:stephen.botzko@gmail.com>]

>>> Sent: Wednesday, April 21, 2010 7:10 P= M

>>> To: Christian Hoene

>>> Cc: codec@ietf.org<mailto:codec@ietf.org>

>>> 

>>> Subject: Re: [codec] #16: Multicast?

>>> 

>>> I agree there are lots of use cases.

>>> 

>>> 

>>> Though I don't see why high quality ha= s to be given up in order to

>>> be scalable.

>>> CH: These are just experiences from ou= r lab. A spatial audio

>>> conference server including the acoust= ic 3D sound rendering needs a

>>> LOT of processing power. In the end, w= e have to remain realistic.

>>> Processing power is always limited thu= s if we need a lot then we

>>> cannot serve many clients.<= /p>

>>> Also, I am not sure why you think cent= ral mixing is more scalable

>>> than multicast (or why you think it is= lower quality either).

>>> CH: With multicast, you need N times 1= :N multicast distribution

>>> trees (somewhat small tan O(n)=3Dn=B2)= .=A0 With central mixing you need N

>>> times 2 transmission paths (O(n)=3Dn).= Also, this distributed mixing

>>> you need N times the mixing at each cl= ient. With centralized, you

>>> can live with one mixing for all (and = some tricks for serving the

>>> talkers).

>>> I agree you need more distribution tre= es for multicast if you allow

>>> every site to talk. There is a corresp= onding benefit, since there is

>>> no central choke point and also less bandwidth on shared WAN links.

>>> 

>>> In the distributed case,=A0 you don't = need an N-way mixer at each

>>> client, and you also don't need to continuously receive payload on

>>> all N streams at each client either.= =A0 In practice you can cap N at a

>>> relatively small number (in the 3-8 ra= nge) no matter how large the

>>> conference gets.=A0 In a large confere= nce, you can even choose to drop

>>> your comfort noise if you are receivin= g two or more streams, and

>>> just send enough to keep your firewall pinhole open.=A0 This is all

>>> assuming a suitable voice activity mea= sure in the RTP packet.=A0 Of

>>> course in the worst case, you will rec= eive all N streams.

>>> 

>>> Cheers,

>>>=A0 Christian

>>> 

>>> Stephen Botzko

>>> On Wed, Apr 21, 2010 at 12:58 PM, Chri= stian Hoene

>>> <hoene@uni-tuebingen.de<mailto:hoene@uni-tuebingen.de>> wrote:<= o:p>

>>> Hi,

>>> 

>>> the teleconferencing issue gets comple= x. I am trying to compile the

>>> different requirements that have been mentioned on this list.

>>> 

>>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 low compl= exity (with just one active speaker) vs.

>>> multiple speaker mixing vs. spatial audio/stereo mixing

>>> 

>>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 centraliz= ed vs. distributed

>>> 

>>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 few parti= cipants vs. hundreds of listeners and talkers

>>> 

>>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 individua= l distribution of audio streams vs. IP multicast

>>> or RTP group communication<= /p>

>>> 

>>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 efficient= encoding of multiple streams having the same

>>> content (but different quality).<= /o:p>

>>> 

>>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 I bet = I missed some.

>>> 

>>> To make things easier, why not to spli= t the teleconferencing

>>> scenario in two: High quality and Scal= able?

>>> 

>>> The high quality scenario, intended fo= r a low number of users, could

>>> have features like

>>> 

>>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Distribut= ed processing and mixing

>>> 

>>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 High comp= utational resources to support spatial audio

>>> mixing (at the receiver) and multiple encodings of the same audio

>>> stream at different qualities (at the sender)

>>> 

>>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Enough ba= ndwidth to allow direct N to N transmissions of

>>> audio streams (no multicast or group c= ommunication). This would be

>>> good for the latency, too.<= /p>

>>> 

>>> The scalable scenario is the opposite:=

>>> 

>>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Central p= rocessing and mixing for many participants .

>>> 

>>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 N to 1 an= d 1 to N communication using efficient

>>> distribution mechanisms (RTP group communication and IP multicast).

>>> 

>>> -=A0=A0=A0=A0=A0=A0=A0=A0=A0 Low compl= exity mixing of many using tricks like VAD,

>>> encoding at lowest rate to support man= y receivers having different

>>> paths, you name it...

>>> 

>>> Then, we need not to compare apples wi= th oranges all the time.

>>> 

>>> Christian

>>> 

>>> ---------------------------------------------------------------<= /p>

>>> Dr.-Ing. Christian Hoene

>>> Interactive Communication Systems (ICS= ), University of T=FCbingen

>>> Sand 13, 72076 T=FCbingen, Germany, Ph= one +49 7071 2970532

>>> http://www.net.uni-tuebingen.de/<= /o:p>

>>> 

>>> From: codec-bounces@ietf.org<mailto:codec-bounces@ietf.org>

>>> [mailto:codec-bounces@ietf.org<mailto:codec-bounces@ietf.org>] On

>>> Behalf Of stephen botzko

>>> Sent: Wednesday, April 21, 2010 4:34 P= M

>>> To: Colin Perkins

>>> Cc: trac@tools.ietf.org<mailto:trac@tools.ietf.org>;

>>> codec@ietf.org<mailto:codec@ietf.or= g>

>>> Subject: Re: [codec] #16: Multicast?

>>> 

>>> in-line

>>> 

>>> Stephen Botzko

>>> On Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins

>>> <csp@csperkins.org<mailto:csp@csperkins.org>> wrote:=

>>> On 21 Apr 2010, at 12:20, Marshall Eub= anks wrote:

>>> On Apr 21, 2010, at 6:48 AM, Colin Per= kins wrote:

>>> On 21 Apr 2010, at 10:42, codec issue = tracker wrote:

>>> #16: Multicast?

>>> ------------------------------------+----------------------------------

>>> Reporter:=A0 hoene@...=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0 Owner:

>>>=A0 Type:=A0 enhancement=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0 Status:=A0 new

>>> Priority:=A0 trivial=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0 Milestone:

>>> Component:=A0 requirements=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0 Version:

>>> Severity:=A0 Active WG Document=A0=A0= =A0=A0=A0 |=A0=A0=A0 Keywords:

>>> ------------------------------------+----------------------------------

>>> The question arrose whether the intera= ctive CODEC MUST support

>>> multicast in addition to teleconferenc= ing.

>>> 

>>> On 04/13/2010 11:35 AM, Christian Hoen= e wrote:

>>> P.S. On the same note, does anybody he= re cares about using this

>>> CODEC with multicast? Is there a singl= e commercial multicast voice

>>> deployment? From what I've seen all multicast does is making IETF

>>> voice standards harder to understand o= r implement.

>>> 

>>> I think that would be a mistake to ign= ore multicast - not because of

>>> multicast itself, but because of Xcast= (RFC 5058) which is a

>>> promising technology to replace centra= lized conference bridges.

>>> 

>>> Regarding multicast:

>>> 

>>> I think we shall start at user require= ments and scenarios.

>>> Teleconference (including mono or spat= ial audio) might be good

>>> starting point. Virtual environments l= ike second live would require

>>> multicast communication, too. If the requirements of these scenarios

>>> are well understand, we can start to t= alk about potential solutions

>>> like IP multicast, Xcast or conference bridges.

>>> 

>>> 

>>> RTP is inherently a group communicatio= n protocol, and any codec

>>> designed for use with RTP should consi= der operation in various

>>> different types of group communication scenario (not just

>>> multicast). RFC 5117 is a good place t= o start when considering the

>>> different types of topology in which R= TP is used, and the possible

>>> placement of mixing and switching func= tions which the codec will

>>> need to work with.

>>> 

>>> It is not clear to me what supporting multicast would entail here.

>>> If this is a codec over RTP, then what= is to stop it from being

>>> multicast ?

>>> 

>>> Nothing. However group conferences implemented using multicast

>>> require end system mixing of potential= ly large numbers of active

>>> audio streams, whereas those implement= ed using conference bridges do

>>> the mixing in a single central locatio= n, and generally suppress all

>>> but one speaker. The differences in mi= xing and the number of

>>> simultaneous active streams that might= be received potentially

>>> affect the design of the codec.

>>> 

>>> Conference bridges with central mixing almost always mix multiple

>>> speakers.=A0 As you add more streams i= nto the mix, you reduce the

>>> chance of missing onset speech and interruptions, but raise the

>>> noise floor. So even if complexity is = not a consideration, there is

>>> value in gating the mixer (instead of = always doing a full mix-minus).

>>> 

>>> More on point, compressed domain mixin= g and easy detection of VAD

>>> have both been advocated on these list= s, and both simplify the

>>> large-scale mixing problem.=

>>> 

>>> --

>>> Colin Perkins

>>> http://csperkins.org/

>>> 

>>> 

>>> 

>>> _______________________________________________

>>> codec mailing list

>>> codec@ietf.org<mailto:codec@ietf.or= g>

>>> https://www.ietf.org/mailman/listinfo/= codec

>>> 

>>> 

>>> 

>>> 

>> 

>> __________________________________________= _____

>> codec mailing list

>> codec@ietf.org

>> https://www.ietf.org/mailman/listinfo/code= c

>> 

>> 

>> 

> 

> 

> 

> 

 

 

--_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B90345536IRVEXCHCCR01c_-- From rchen@broadcom.com Tue May 4 19:22:27 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F1083A69DC for ; Tue, 4 May 2010 19:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.175 X-Spam-Level: X-Spam-Status: No, score=-0.175 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5x4qGltReojd for ; Tue, 4 May 2010 19:22:23 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id D31143A696A for ; Tue, 4 May 2010 19:22:17 -0700 (PDT) Received: from [10.9.200.131] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 04 May 2010 19:21:52 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Tue, 4 May 2010 19:21:53 -0700 From: "Raymond (Juin-Hwey) Chen" To: "stephen botzko" , "Koen Vos" Date: Tue, 4 May 2010 19:21:51 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcrpMqKR1zJG8xPcTj+7uXJ4Zlkn8QCw4aHw Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67FE09CA31G114469571-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 02:22:27 -0000 Hi Stephen, > If the frame-size multiplier is due to serialization, then I agree with=20 > Koen's assessment.=A0 In fact on many connections the multiplier would be= =20 > less than 1. Dial-up is of course the worst case here, and on those=20 > links the multiplier ought to be close to 2.=A0 Variations due to=20 > congestion (and on some links, polling) are (IMHO) better modeled as=20 > jitter.=A0=20 [Raymond]: The frame-size multiplier has many more components than just ser= ialization as I have discussed in my previous emails. How can the total mu= ltiplier be less than 1 when just buffering the current frame of input spee= ch samples will take one frame? Perhaps you are only talking about the ser= ialization delay component? I agree that delay variations due to congestio= n are better modeled as jitter. That's always the case, and my previous di= scussions did not include jitter in the codec-dependent delay. > Gateways are another matter, with the delays being highly dependent on=20 > the product architecture.=A0 Interupt latencies, context switching, bus=20 > architectures, etc. can dominate, so it is totally possible that=20 > reducing the frame size might actually increase the latency (since it=20 > increases the packets per second load on the gateway).=A0 So I agree with= =20 > Koen on this as well. [Raymond]: I agree with the first half of your paragraph above but not the = second half, because the second half contradicts with the real-world observ= ed behaviors: G.711 with a 5 ms frame/packet size gets 12 to 17 ms of codec= -dependent delay, while G.711 with a 10 ms frame/packet size gets 50 to 60 = ms of worst-case codec-dependent delay before delay optimization, and 30 ms= after delay optimization. In these two actual real-world VoIP gateway imp= lementations, the codec-dependent delay grow with the codec frame size with= about a 3X multiplier. > Anecdotal models based on industry experience can be useful guides -=20 > though if we are going to use these models to drive requirements, I'd=20 > prefer something more analytical. [Raymond]: We broke down the one-way delay into codec-independent delay and= codec-dependent delay, and then further broke down the codec-dependent del= ay into the components of codec buffering delay, processing delay, transmis= sion delay (I guess what you called serialization delay), and scheduling an= d buffering delays of the micro-controllers and DSPs due to many tasks to m= any channels competing for the processors, etc. We also analyzed which part= doesn't change with improving technology (e.g. codec buffering delay) and = how certain delay components may change with increasing processor speed and= transmission speed. Isn't that analytical? How much more analytical can = you get than that? We didn't just throw a few real-world observed codec-de= pendent delay values and ask everyone to believe the 3X multiplier without = any explanation or analysis. No, we just used these real-world values to su= pport our analysis. From stephen.botzko@gmail.com Wed May 5 04:06:50 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C40AD3A6AD2 for ; Wed, 5 May 2010 04:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[AWL=-0.705, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNYl3RdNiNzM for ; Wed, 5 May 2010 04:06:49 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 3478F3A6AEA for ; Wed, 5 May 2010 04:06:45 -0700 (PDT) Received: by wwi18 with SMTP id 18so1864699wwi.31 for ; Wed, 05 May 2010 04:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=RaUCS8Dr33gb7E9LRZ3q8c0sjSSgUKF0ds9K75FKddA=; b=SMW637zPskjY011ItSkOjm0auEMEKFXutwP+X6D4yl/fNJPK+dnMPGqQYwwgT4Z2yk 6iWs+ojaoDzXYdo7pp8IpzySHQA2EmAg1QudApDuaKJIeUuWDWpG4T5HHQs9OjRBHjOR bdZo/KTTlriMXyiy9HZx26gDvRAmNxuk2Jfa4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SJ7Pt6n20uAJp6VjY0k/YTEQf0H88//k7cd+Q9mvaAqDBxKSRczYcJyzNzxAEIFQcc yNfizwu9dMQOis0z+TigwLwcs9bfx1bv51lBUS4wbC7wM0WccD4j+thi3fLEfb8ELBTq WUnjkdLhJRuX2fcWDDw/H7d1jI8ho1GPIMJqA= MIME-Version: 1.0 Received: by 10.216.86.212 with SMTP id w62mr680210wee.131.1273057588049; Wed, 05 May 2010 04:06:28 -0700 (PDT) Received: by 10.216.28.139 with HTTP; Wed, 5 May 2010 04:06:27 -0700 (PDT) In-Reply-To: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> Date: Wed, 5 May 2010 07:06:27 -0400 Message-ID: From: stephen botzko To: "Raymond (Juin-Hwey) Chen" Content-Type: multipart/alternative; boundary=0016e6d9a3a25079570485d6d14c Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 11:06:50 -0000 --0016e6d9a3a25079570485d6d14c Content-Type: text/plain; charset=ISO-8859-1 In-line Regards Stephen Botzko On Tue, May 4, 2010 at 10:21 PM, Raymond (Juin-Hwey) Chen < rchen@broadcom.com> wrote: > Hi Stephen, > > > If the frame-size multiplier is due to serialization, then I agree with > > Koen's assessment. In fact on many connections the multiplier would be > > less than 1. Dial-up is of course the worst case here, and on those > > links the multiplier ought to be close to 2. Variations due to > > congestion (and on some links, polling) are (IMHO) better modeled as > > jitter. > [Raymond]: The frame-size multiplier has many more components than just > serialization as I have discussed in my previous emails. How can the total > multiplier be less than 1 when just buffering the current frame of input > speech samples will take one frame? Perhaps you are only talking about the > serialization delay component? I agree that delay variations due to > congestion are better modeled as jitter. That's always the case, and my > previous discussions did not include jitter in the codec-dependent delay. > Generally the need to buffer the current frame is treated as part of the algorithmic delay. At least I believe that is what the ITU-T does. So maybe we need a list of what all these components are? I'd suggest keeping the gateway out of it for the first pass. > > > Gateways are another matter, with the delays being highly dependent on > > the product architecture. Interupt latencies, context switching, bus > > architectures, etc. can dominate, so it is totally possible that > > reducing the frame size might actually increase the latency (since it > > increases the packets per second load on the gateway). So I agree with > > Koen on this as well. > [Raymond]: I agree with the first half of your paragraph above but not the > second half, because the second half contradicts with the real-world > observed behaviors: G.711 with a 5 ms frame/packet size gets 12 to 17 ms of > codec-dependent delay, while G.711 with a 10 ms frame/packet size gets 50 to > 60 ms of worst-case codec-dependent delay before delay optimization, and 30 > ms after delay optimization. In these two actual real-world VoIP gateway > implementations, the codec-dependent delay grow with the codec frame size > with about a 3X multiplier. > I've worked with Gateways\MCUs where the packet size had to be increased because packet loading in the product became too high. Also, if you have QOS features enabled in many routers, the routers themselves have to start using a "software path", which creates a similar throughput problem in the routers. Too many packets per second can overwhelm these devices, creating both capacity issues and excessive queuing delays. > > > Anecdotal models based on industry experience can be useful guides - > > though if we are going to use these models to drive requirements, I'd > > prefer something more analytical. > [Raymond]: We broke down the one-way delay into codec-independent delay and > codec-dependent delay, and then further broke down the codec-dependent delay > into the components of codec buffering delay, processing delay, transmission > delay (I guess what you called serialization delay), and scheduling and > buffering delays of the micro-controllers and DSPs due to many tasks to many > channels competing for the processors, etc. We also analyzed which part > doesn't change with improving technology (e.g. codec buffering delay) and > how certain delay components may change with increasing processor speed and > transmission speed. Isn't that analytical? How much more analytical can > you get than that? We didn't just throw a few real-world observed > codec-dependent delay values and ask everyone to believe the 3X multiplier > without any explanation or analysis. No, we just used these real-world > values to support our analysis. > Serialization is just one component of transmission delay, and is independent of distance. As it turns out, it is the network delay component that depends on packet size. I don't think the group has an agreed-upon model which names these components consistently, and describes are appropriately in-scope and which are out-of-scope. Perhaps that is one reason why Koen is saying multiplier the number is 1x. Also, there are real-world negative consequences to higher packet rates, and we have not yet considered them. --0016e6d9a3a25079570485d6d14c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In-line

Regards
Stephen Botzko

= On Tue, May 4, 2010 at 10:21 PM, Raymond (Juin-Hwey) Chen <rchen@broadcom.com> wrote:
Hi Stephen,

> If the frame-size multiplier is due to serialization, then I agree wit= h
> Koen's assessment.=A0 In fact on many connections the multiplier w= ould be
> less than 1. Dial-up is of course the worst case here, and on those > links the multiplier ought to be close to 2.=A0 Variations due to
> congestion (and on some links, polling) are (IMHO) better modeled as > jitter.=A0
[Raymond]: The frame-size multiplier has many more components than ju= st serialization as I have discussed in my previous emails. =A0How can the = total multiplier be less than 1 when just buffering the current frame of in= put speech samples will take one frame? =A0Perhaps you are only talking abo= ut the serialization delay component? =A0I agree that delay variations due = to congestion are better modeled as jitter. =A0That's always the case, = and my previous discussions did not include jitter in the codec-dependent d= elay.

Generally the need to buffer the current frame is tre= ated as part of the algorithmic delay.=A0 At least I believe that is what t= he ITU-T does.

So maybe we need a list of what all these components = are?=A0 I'd suggest keeping the gateway out of it for the first pass. =A0

> Gateways are another matter, with the delays being highly dependent on=
> the product architecture.=A0 Interupt latencies, context switching, bu= s
> architectures, etc. can dominate, so it is totally possible that
> reducing the frame size might actually increase the latency (since it<= br> > increases the packets per second load on the gateway).=A0 So I agree w= ith
> Koen on this as well.
[Raymond]: I agree with the first half of your paragraph above but no= t the second half, because the second half contradicts with the real-world = observed behaviors: G.711 with a 5 ms frame/packet size gets 12 to 17 ms of= codec-dependent delay, while G.711 with a 10 ms frame/packet size gets 50 = to 60 ms of worst-case codec-dependent delay before delay optimization, and= 30 ms after delay optimization. =A0In these two actual real-world VoIP gat= eway implementations, the codec-dependent delay grow with the codec frame s= ize with about a 3X multiplier.
I've worked with Gateways\MCUs where the packet size = had to be increased because packet loading in the product became too high.= =A0 Also, if you have QOS features enabled in many routers, the routers the= mselves have to start using a "software path", which creates a si= milar throughput problem in the routers.=A0 Too many packets per second can= overwhelm these devices, creating both capacity issues and excessive queui= ng delays.
=A0

> Anecdotal models based on industry experience can be useful guides - > though if we are going to use these models to drive requirements, I= 9;d
> prefer something more analytical.
[Raymond]: We broke down the one-way delay into codec-independent del= ay and codec-dependent delay, and then further broke down the codec-depende= nt delay into the components of codec buffering delay, processing delay, tr= ansmission delay (I guess what you called serialization delay), and schedul= ing and buffering delays of the micro-controllers and DSPs due to many task= s to many channels competing for the processors, etc. We also analyzed whic= h part doesn't change with improving technology (e.g. codec buffering d= elay) and how certain delay components may change with increasing processor= speed and transmission speed. =A0Isn't that analytical? =A0How much mo= re analytical can you get than that? =A0We didn't just throw a few real= -world observed codec-dependent delay values and ask everyone to believe th= e 3X multiplier without any explanation or analysis. No, we just used these= real-world values to support our analysis.
Serialization is just one component of transmission delay= , and is independent of distance.=A0 As it turns out, it is the network del= ay component that depends on packet size.

I don't think the grou= p has an agreed-upon model which names these components consistently, and d= escribes are appropriately in-scope and which are out-of-scope.=A0 Perhaps = that is one reason why Koen is saying multiplier the number is 1x.=A0

Also, there are real-world negative consequences to higher packet rates= , and we have not yet considered them.

--0016e6d9a3a25079570485d6d14c-- From hoene@uni-tuebingen.de Wed May 5 12:02:49 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84BEA3A68D7; Wed, 5 May 2010 12:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.902 X-Spam-Level: X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sCEjRgAwzOK; Wed, 5 May 2010 12:02:48 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 717CC3A6C7B; Wed, 5 May 2010 12:02:19 -0700 (PDT) Received: from hoeneT60 ([178.2.215.148]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o45J1vls014502 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 May 2010 21:02:03 +0200 From: "Christian Hoene" To: "'Vladimir Sviridenko'" , References: <5A3D7E7076F5DF42990A8C164308F8107884A0@mail-srv.spiritcorp.com> <5A3D7E7076F5DF42990A8C164308F8107FB29E@mail-srv.spiritcorp.com> <5A3D7E7076F5DF42990A8C164308F8107FB29F@mail-srv.spiritcorp.com> <5A3D7E7076F5DF42990A8C164308F8107FB2A7@mail-srv.spiritcorp.com> In-Reply-To: <5A3D7E7076F5DF42990A8C164308F8107FB2A7@mail-srv.spiritcorp.com> Date: Wed, 5 May 2010 21:01:56 +0200 Message-ID: <001501caec85$72c43ff0$584cbfd0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acrp+N7OZyC4AF1nTgyf7CZ16s3UtAANWOzAAAGk76AAT0iDIAABPRywAEDLfdAAAAxtwAABS4YwAAEZmgA= Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: 'Dmitry Yudin' , 'Slava Borilin' , codec@ietf.org Subject: Re: [codec] #28: Layered bit-stream X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 19:02:49 -0000 Hi Vladimir, >2/ we think that VoIP and Videoconferencing systems are users of such >codecs. Could you please explain your position a bit? As far as I understand, layered coding helps if multiple streams having the sample content but different rates must be generated. For example, if a conferencing system stream the same audio stream to N users but each users has a different bandwidth. Just encode all layers and drop the higher layers for the low bandwidth users. This approach is easy and efficient and reduce the encoding complexity. The arguments against are simple. a) First, this use case is a local optimization only. Thus, the must not be standardized. b) Second, instead of layered coding one can use other ways of tweaking the implementation performance. For example, if you calculate a 512 FFT do get two 256 FFTs for free. I bet there are thousand other shortcuts which I am not aware of. Thus, I have the opinion that layered coding is not worth the extra bandwidth of 20 or more percentage. It is just good locally but not needed for interoperability. Yours, Christian >Yours, >Vladimir Sviridenko >SPIRIT > >-----Original Message----- >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >Of codec issue tracker >Sent: Sunday, May 02, 2010 5:10 PM >To: hoene@uni-tuebingen.de >Cc: codec@ietf.org >Subject: [codec] #28: Layered bit-stream > >#28: Layered bit-stream >------------------------------------+----------------------------------- >---- > Reporter: hoene@... | Owner: > Type: defect | Status: new > Priority: minor | Milestone: >Component: requirements | Version: > Severity: Active WG Document | Keywords: >------------------------------------+----------------------------------- >---- > Shall layered coding be supported? > Who needs it? > Can we drop this requirement? > >-- >Ticket URL: >codec > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From rchen@broadcom.com Wed May 5 14:03:46 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD2BD3A6BBB for ; Wed, 5 May 2010 14:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.536 X-Spam-Level: X-Spam-Status: No, score=-0.536 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BefEOER98yNI for ; Wed, 5 May 2010 14:03:46 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 0C85E3A6CC9 for ; Wed, 5 May 2010 14:03:46 -0700 (PDT) Received: from [10.9.200.131] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 05 May 2010 14:03:18 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Wed, 5 May 2010 14:03:18 -0700 From: "Raymond (Juin-Hwey) Chen" To: "codec@ietf.org" Date: Wed, 5 May 2010 14:03:17 -0700 Thread-Topic: Internet Draft for BroadVoice codecs Thread-Index: AcrslmJg5vRilVkwRsS2kJJXxaQpQQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67FF029C38O197605704-03-01 Content-Type: multipart/alternative; boundary=_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B903456C0IRVEXCHCCR01c_ Subject: [codec] Internet Draft for BroadVoice codecs X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2010 21:03:46 -0000 --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B903456C0IRVEXCHCCR01c_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable All, I would like to bring to your attention that an Internet Draft for the Broa= dVoice codecs (BV16 and BV32) has been submitted to the IETF last week. It= is available at http://tools.ietf.org/html/draft-chen-bv-codec-00 . As Stephan just announced, the corresponding IPR disclosure from Broadcom w= as submitted today and is available at https://datatracker.ietf.org/ipr/1320/ . I believe such submissions meet the requirements for BroadVoice to be consi= dered a candidate for the IETF Internet codec. Thanks for your attention. Raymond --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B903456C0IRVEXCHCCR01c_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

All,

 

I would like to bring to your attention that an Internet Draft for the BroadV= oice codecs (BV16 and BV32) has been submitted to the IETF last week. &nb= sp;It is available at

http://tools.ietf.org/html/draft-chen-bv-codec-00 .

 

As Stephan just announced, the corresponding IPR discl= osure from Broadcom was submitted today and is available at

htt= ps://datatracker.ietf.org/ipr/1320/ .

 

I believe such submissions meet the requirements for BroadVoice to be considered a candidate for the IETF Internet codec.  = Thanks for your attention.

 

Raymond

--_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B903456C0IRVEXCHCCR01c_-- From hoene@uni-tuebingen.de Thu May 6 06:19:12 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1020F3A6BFF for ; Thu, 6 May 2010 06:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.345 X-Spam-Level: X-Spam-Status: No, score=-4.345 tagged_above=-999 required=5 tests=[AWL=-0.696, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAEyxVwb4xtG for ; Thu, 6 May 2010 06:19:07 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 6ED5E3A68AA for ; Thu, 6 May 2010 06:13:41 -0700 (PDT) Received: from hoeneT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o46DDNes001714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 May 2010 15:13:24 +0200 From: "Christian Hoene" To: "'Dmitry Yudin'" References: <5A3D7E7076F5DF42990A8C164308F8107884A0@mail-srv.spiritcorp.com> <5A3D7E7076F5DF42990A8C164308F8107FB29E@mail-srv.spiritcorp.com> <5A3D7E7076F5DF42990A8C164308F8107FB29F@mail-srv.spiritcorp.com> <5A3D7E7076F5DF42990A8C164308F8107FB2A7@mail-srv.spiritcorp.com> <001501caec85$72c43ff0$584cbfd0$@de> <5A3D7E7076F5DF42990A8C164308F8107FB370@mail-srv.spiritcorp.com> In-Reply-To: <5A3D7E7076F5DF42990A8C164308F8107FB370@mail-srv.spiritcorp.com> Date: Thu, 6 May 2010 15:13:23 +0200 Message-ID: <000201caed1d$e9ae4ff0$bd0aefd0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acrp+N7OZyC4AF1nTgyf7CZ16s3UtAANWOzAAAGk76AAT0iDIAABPRywAEDLfdAAAAxtwAABS4YwAAEZmgAAHY3rcAAIqVrw Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] #28: Layered bit-stream X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 13:19:12 -0000 Hi Dimitry, >Hi Christian, > >From application point of view, the layered stream structure allows >server manipulate channel bandwidth individually for each user with zero >performance overhead. I understand. Because you as an application programmer want to have an easy life, the codec designer shall develop a more complicated codec? In addition, everybody should suffer from a higher bit rate? No, that is not fair. > Obviously, conferencing is the most important use-case. No, end-to-end connections are more frequent than conference calls. > >> a) First, this use case is a local optimization only. Thus, the must >not be standardized. >What do you mean exactly? "local optimization" of what? I mean that the layered coding is only used within one computer. It is not important in-between computers. And, it is only a performance optimization that make the conference gateway faster. Sincerely, Christian > >> b) Second, instead of layered coding one can use other ways of >tweaking the implementation >> performance. For example, if you calculate a 512 FFT do get two 256 >FFTs for free. >> I bet there are thousand other shortcuts which I am not aware of. >How do this interrelates with scalability? Please, explain. > >Let's return back to the subject: > Shall layered coding be supported? - we think "yes", because ... >(see my first sentence) > Who needs it? - answered > Can we drop this requirement? - only if we have real good >reasons for it. Do we have them? > >Best regards, >Dmitry > >-----Original Message----- >From: Christian Hoene [mailto:hoene@uni-tuebingen.de] >Sent: Wednesday, May 05, 2010 11:02 PM >To: Vladimir Sviridenko; codec-bounces@ietf.org >Cc: Slava Borilin; Dmitry Yudin; codec@ietf.org >Subject: RE: [codec] #28: Layered bit-stream > >Hi Vladimir, > >>2/ we think that VoIP and Videoconferencing systems are users of such >>codecs. > >Could you please explain your position a bit? > >As far as I understand, layered coding helps if multiple streams having >the sample content but different rates must be generated. >For example, if a conferencing system stream the same audio stream to N >users but each users has a different bandwidth. Just encode >all layers and drop the higher layers for the low bandwidth users. This >approach is easy and efficient and reduce the encoding >complexity. > >The arguments against are simple. >a) First, this use case is a local optimization only. Thus, the must not >be standardized. >b) Second, instead of layered coding one can use other ways of tweaking >the implementation performance. For example, if you >calculate a 512 FFT do get two 256 FFTs for free. I bet there are >thousand other shortcuts which I am not aware of. > >Thus, I have the opinion that layered coding is not worth the extra >bandwidth of 20 or more percentage. It is just good locally but >not needed for interoperability. > >Yours, > > Christian > > > > > > >>Yours, >>Vladimir Sviridenko >>SPIRIT >> >>-----Original Message----- >>From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >>Of codec issue tracker >>Sent: Sunday, May 02, 2010 5:10 PM >>To: hoene@uni-tuebingen.de >>Cc: codec@ietf.org >>Subject: [codec] #28: Layered bit-stream >> >>#28: Layered bit-stream >>------------------------------------+---------------------------------- >- >>---- >> Reporter: hoene@... | Owner: >> Type: defect | Status: new >> Priority: minor | Milestone: >>Component: requirements | Version: >> Severity: Active WG Document | Keywords: >>------------------------------------+---------------------------------- >- >>---- >> Shall layered coding be supported? >> Who needs it? >> Can we drop this requirement? >> >>-- >>Ticket URL: >>codec >> >>_______________________________________________ >>codec mailing list >>codec@ietf.org >>https://www.ietf.org/mailman/listinfo/codec From stephen.botzko@gmail.com Thu May 6 06:57:25 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EFE83A6C74 for ; Thu, 6 May 2010 06:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.653 X-Spam-Level: X-Spam-Status: No, score=-0.653 tagged_above=-999 required=5 tests=[AWL=-0.655, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlP4mYRkEolO for ; Thu, 6 May 2010 06:57:24 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 3DD8128C1F1 for ; Thu, 6 May 2010 06:41:37 -0700 (PDT) Received: by wwi17 with SMTP id 17so520472wwi.31 for ; Thu, 06 May 2010 06:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=s/gD7STxviqBM+YsB9tqZkJUVOE3savcPNO/mLL+eNA=; b=gt0zQHZAJ8YX07k774S01YopgoaEuuuPirMf1JCpQwxypmHOVmNj5MqrtcraA9w5P2 3K4Xx8YmWj/RE6I8q1grgA+07TDYxU7ewytOye6TPOCQKu+TtNCyrY6AvAkq6JZJYEVT qo0AKYtdRhOjR3xzlaruuXzbmW1o7VlpPcLAM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Si6kWkzOlVrEXlzIHt34KeHnzN751oKMenQrhUljR/xoDBHAF/hFjU3racDDqmHTPJ 5cM0L1SfaROvIEGTX2NNa4HQy5/TeMn3zWjLBBiPpp3Ie/L0H65Q/oy2IM7iqWMatIRe sm0WGo2x3UdGtInNBBaOm9qqc+i0QpHjy99uk= MIME-Version: 1.0 Received: by 10.216.186.138 with SMTP id w10mr8293116wem.206.1273153279286; Thu, 06 May 2010 06:41:19 -0700 (PDT) Received: by 10.216.28.139 with HTTP; Thu, 6 May 2010 06:41:19 -0700 (PDT) In-Reply-To: <000201caed1d$e9ae4ff0$bd0aefd0$@de> References: <5A3D7E7076F5DF42990A8C164308F8107884A0@mail-srv.spiritcorp.com> <5A3D7E7076F5DF42990A8C164308F8107FB29E@mail-srv.spiritcorp.com> <5A3D7E7076F5DF42990A8C164308F8107FB29F@mail-srv.spiritcorp.com> <5A3D7E7076F5DF42990A8C164308F8107FB2A7@mail-srv.spiritcorp.com> <001501caec85$72c43ff0$584cbfd0$@de> <5A3D7E7076F5DF42990A8C164308F8107FB370@mail-srv.spiritcorp.com> <000201caed1d$e9ae4ff0$bd0aefd0$@de> Date: Thu, 6 May 2010 09:41:19 -0400 Message-ID: From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=0016367fa6a2f4defb0485ed18be Cc: Dmitry Yudin , codec@ietf.org Subject: Re: [codec] #28: Layered bit-stream X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 13:57:25 -0000 --0016367fa6a2f4defb0485ed18be Content-Type: text/plain; charset=ISO-8859-1 A couple of observations on this (a) I agree with Christian that layered codecs usually need higher bitrates to achieve the same quality. Of course we do want good quality over our desired bitrate range, and it is likely to be more difficult to achieve that with a layered codec. (b) I agree with Dimity that layered codecs reduce the complexity of VOIP gateways and perhaps conference bridges. Also, with layered codec designs you get wire-speed management of channel bandwidth, so there can be a delay benefit as well as a complexity reduction. (c) Arguing about the relative priority of multipoint conferences vs point to point calls is pointless, because they are clearly both MUSTS. I am not sure if Christian is arguing that layered codecs SHALL NOT be considered, or if the requirements allow but are not biased towards layered proposals. If might be useful to clarify this point. Stephen Botzko On Thu, May 6, 2010 at 9:13 AM, Christian Hoene wrote: > Hi Dimitry, > > >Hi Christian, > > > >From application point of view, the layered stream structure allows > >server manipulate channel bandwidth individually for each user with zero > >performance overhead. > > I understand. Because you as an application programmer want to have an easy > life, the codec designer shall develop a more > complicated codec? In addition, everybody should suffer from a higher bit > rate? No, that is not fair. > > > Obviously, conferencing is the most important use-case. > > No, end-to-end connections are more frequent than conference calls. > > > > >> a) First, this use case is a local optimization only. Thus, the must > >not be standardized. > >What do you mean exactly? "local optimization" of what? > > I mean that the layered coding is only used within one computer. It is not > important in-between computers. And, it is only a > performance optimization that make the conference gateway faster. > > Sincerely, > > Christian > > > > > >> b) Second, instead of layered coding one can use other ways of > >tweaking the implementation > >> performance. For example, if you calculate a 512 FFT do get two 256 > >FFTs for free. > >> I bet there are thousand other shortcuts which I am not aware of. > >How do this interrelates with scalability? Please, explain. > > > >Let's return back to the subject: > > Shall layered coding be supported? - we think "yes", because ... > >(see my first sentence) > > Who needs it? - answered > > Can we drop this requirement? - only if we have real good > >reasons for it. Do we have them? > > > >Best regards, > >Dmitry > > > >-----Original Message----- > >From: Christian Hoene [mailto:hoene@uni-tuebingen.de] > >Sent: Wednesday, May 05, 2010 11:02 PM > >To: Vladimir Sviridenko; codec-bounces@ietf.org > >Cc: Slava Borilin; Dmitry Yudin; codec@ietf.org > >Subject: RE: [codec] #28: Layered bit-stream > > > >Hi Vladimir, > > > >>2/ we think that VoIP and Videoconferencing systems are users of such > >>codecs. > > > >Could you please explain your position a bit? > > > >As far as I understand, layered coding helps if multiple streams having > >the sample content but different rates must be generated. > >For example, if a conferencing system stream the same audio stream to N > >users but each users has a different bandwidth. Just encode > >all layers and drop the higher layers for the low bandwidth users. This > >approach is easy and efficient and reduce the encoding > >complexity. > > > >The arguments against are simple. > >a) First, this use case is a local optimization only. Thus, the must not > >be standardized. > >b) Second, instead of layered coding one can use other ways of tweaking > >the implementation performance. For example, if you > >calculate a 512 FFT do get two 256 FFTs for free. I bet there are > >thousand other shortcuts which I am not aware of. > > > >Thus, I have the opinion that layered coding is not worth the extra > >bandwidth of 20 or more percentage. It is just good locally but > >not needed for interoperability. > > > >Yours, > > > > Christian > > > > > > > > > > > > > >>Yours, > >>Vladimir Sviridenko > >>SPIRIT > >> > >>-----Original Message----- > >>From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > >>Of codec issue tracker > >>Sent: Sunday, May 02, 2010 5:10 PM > >>To: hoene@uni-tuebingen.de > >>Cc: codec@ietf.org > >>Subject: [codec] #28: Layered bit-stream > >> > >>#28: Layered bit-stream > >>------------------------------------+---------------------------------- > >- > >>---- > >> Reporter: hoene@... | Owner: > >> Type: defect | Status: new > >> Priority: minor | Milestone: > >>Component: requirements | Version: > >> Severity: Active WG Document | Keywords: > >>------------------------------------+---------------------------------- > >- > >>---- > >> Shall layered coding be supported? > >> Who needs it? > >> Can we drop this requirement? > >> > >>-- > >>Ticket URL: > >>codec > >> > >>_______________________________________________ > >>codec mailing list > >>codec@ietf.org > >>https://www.ietf.org/mailman/listinfo/codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016367fa6a2f4defb0485ed18be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A couple of observations on this

(a) I agree with Christian that lay= ered codecs usually need higher bitrates to achieve the same quality. Of co= urse we do want good quality over our desired bitrate range, and it is like= ly to be more difficult to achieve that with a layered codec.

(b) I agree with Dimity that layered codecs reduce the complexity of VO= IP gateways and perhaps conference bridges.=A0 Also, with layered codec des= igns you get wire-speed management of channel bandwidth, so there can be a = delay benefit as well as a complexity reduction.

(c) Arguing about the relative priority of multipoint conferences vs po= int to point calls is pointless, because they are clearly both MUSTS.
I am not sure if Christian is arguing that layered codecs SHALL NOT be co= nsidered, or if the requirements allow but are not biased towards layered p= roposals.=A0 If might be useful to clarify this point.

Stephen Botzko



On Thu, May 6,= 2010 at 9:13 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote:
Hi Dimitry,

>Hi Christian,
>
>From application point of view, the layered stream structure allows
>server manipulate channel bandwidth individually for each user with zer= o
>performance overhead.

I understand. Because you as an application programmer want to have an easy= life, the codec designer shall develop a more
complicated codec? In addition, everybody should suffer from a higher bit r= ate? No, that is not fair.

> Obviously, conferencing is the most important use-case.

No, end-to-end connections are more frequent than conference calls.

>
>> a) First, this use case is a local optimization only. Thus, the mu= st
>not be standardized.
>What do you mean exactly? "local optimization" of what?=

I mean that the layered coding is only used within one computer. It is not = important in-between computers. And, it is only a
performance optimization that make the conference gateway faster.

Sincerely,

=A0Christian


>
>> b) Second, instead of layered coding one can use other ways of
>tweaking the implementation
>> performance. For example, if you calculate a 512 FFT do get two 25= 6
>FFTs for free.
>> I bet there are thousand other shortcuts which I am not aware of.<= br>
>How do this interrelates with scalability? Please, explain.
>
>Let's return back to the subject:
> =A0 =A0Shall layered coding be supported? - we think "yes", = because ...
>(see my first sentence)
> =A0 =A0Who needs it? =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- answ= ered
> =A0 =A0Can we drop this requirement? =A0 =A0 =A0- only if we have real= good
>reasons for it. Do we have them?
>
>Best regards,
>Dmitry
>
>-----Original Message-----
>From: Christian Hoene [mailto:hoene@uni-tuebingen.de]
>Sent: Wednesday, May 05, 2010 11:02 PM
>To: Vladimir Sviridenko; code= c-bounces@ietf.org
>Cc: Slava Borilin; Dmitry Yudin; code= c@ietf.org
>Subject: RE: [codec] #28: Layered bit-stream
>
>Hi Vladimir,
>
>>2/ we think that VoIP and Videoconferencing systems are users of su= ch
>>codecs.
>
>Could you please explain your position a bit?
>
>As far as I understand, layered coding helps if multiple streams having=
>the sample content but different rates must be generated.
>For example, if a conferencing system stream the same audio stream to N=
>users but each users has a different bandwidth. Just encode
>all layers and drop the higher layers for the low bandwidth users. This=
>approach is easy and efficient and reduce the encoding
>complexity.
>
>The arguments against are simple.
>a) First, this use case is a local optimization only. Thus, the must no= t
>be standardized.
>b) Second, instead of layered coding one can use other ways of tweaking=
>the implementation performance. For example, if you
>calculate a 512 FFT do get two 256 FFTs for free. I bet there are
>thousand other shortcuts which I am not aware of.
>
>Thus, I have the opinion that layered coding is not worth the extra
>bandwidth of 20 or more percentage. It is just good locally but
>not needed for interoperability.
>
>Yours,
>
> Christian
>
>
>
>
>
>
>>Yours,
>>Vladimir Sviridenko
>>SPIRIT
>>
>>-----Original Message-----
>>From: codec-bounces@ietf.= org [mailto:codec-bounces@iet= f.org] On Behalf
>>Of codec issue tracker
>>Sent: Sunday, May 02, 2010 5:10 PM
>>To: hoene@uni-tuebingen.d= e
>>Cc: codec@ietf.org
>>Subject: [codec] #28: Layered bit-stream
>>
>>#28: Layered bit-stream
>>------------------------------------+------------------------------= ----
>-
>>----
>> Reporter: =A0hoene@... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 Owner:
>> =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 = =A0 =A0Status: =A0new
>> Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Miles= tone:
>>Component: =A0requirements =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version= :
>> Severity: =A0Active WG Document =A0 =A0 =A0| =A0 =A0Keywords:
>>------------------------------------+------------------------------= ----
>-
>>----
>> Shall layered coding be supported?
>> Who needs it?
>> Can we drop this requirement?
>>
>>--
>>Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/tick= et/28>
>>codec <http://tools.ietf.org/codec/>
>>
>>_______________________________________________
>>codec mailing list
>>codec@ietf.org
>>https://www.ietf.org/mailman/listinfo/codec

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--0016367fa6a2f4defb0485ed18be-- From hoene@uni-tuebingen.de Thu May 6 07:20:50 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55FAD28C1C3 for ; Thu, 6 May 2010 07:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.281 X-Spam-Level: X-Spam-Status: No, score=-4.281 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PvpN56Km1sP for ; Thu, 6 May 2010 07:20:47 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 79F1D3A6B4B for ; Thu, 6 May 2010 06:57:48 -0700 (PDT) Received: from hoeneT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o46DvVDK009672 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 May 2010 15:57:32 +0200 From: "Christian Hoene" To: "'stephen botzko'" References: <5A3D7E7076F5DF42990A8C164308F8107884A0@mail-srv.spiritcorp.com> <5A3D7E7076F5DF42990A8C164308F8107FB29E@mail-srv.spiritcorp.com> <5A3D7E7076F5DF42990A8C164308F8107FB29F@mail-srv.spiritcorp.com> <5A3D7E7076F5DF42990A8C164308F8107FB2A7@mail-srv.spiritcorp.com> <001501caec85$72c43ff0$584cbfd0$@de> <5A3D7E7076F5DF42990A8C164308F8107FB370@mail-srv.spiritcorp.com> <000201caed1d$e9ae4ff0$bd0aefd0$@de> In-Reply-To: Date: Thu, 6 May 2010 15:57:30 +0200 Message-ID: <000301caed24$1265afa0$37310ee0$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01CAED34.D5EE7FA0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrtIdXKkQSKYbnwSKqDIHRCpL10lgAAN/gQ Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: 'Dmitry Yudin' , codec@ietf.org Subject: Re: [codec] #28: Layered bit-stream X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 14:20:50 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0004_01CAED34.D5EE7FA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I respect the requirements of gateway manufactures and I think it is = important to consider them. =20 Let me explain my arguments a bit more by discussion point b. =20 * (b) I agree with Dimity that layered codecs reduce the complexity of = VOIP gateways and perhaps conference bridges. =20 I see that there is an important need to reduce the computational = complexity at gateways and conference bridges. Layered coding is an easy solution that helps to reduce complexity. However, I think that = there are many other ways to achieve similar complexity reduction WITHOUT requiring layered coding. One example is a special = encoder that encodes multiple streams at the same time.=20 =20 * Also, with layered codec designs you get wire-speed management of = channel bandwidth, so there can be a delay benefit as well as a complexity reduction. =20 Also, a fast management of channel bandwidth can be achieved by = controlling the encoder (via a feedback channel not locally) =20 Thus, I would vote for a NEED NOT or even MUST NOT because the costs of = layered encoding are imposed to all users of the codec but the benefit is only to the gateways. =20 With best regards, =20 Christian =20 =20 =20 --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ =20 From: stephen botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Thursday, May 06, 2010 3:41 PM To: Christian Hoene Cc: Dmitry Yudin; codec@ietf.org Subject: Re: [codec] #28: Layered bit-stream =20 A couple of observations on this (a) I agree with Christian that layered codecs usually need higher = bitrates to achieve the same quality. Of course we do want good quality over our desired bitrate range, and it is likely to be more = difficult to achieve that with a layered codec. (b) I agree with Dimity that layered codecs reduce the complexity of = VOIP gateways and perhaps conference bridges. Also, with layered codec designs you get wire-speed management of channel = bandwidth, so there can be a delay benefit as well as a complexity reduction. (c) Arguing about the relative priority of multipoint conferences vs = point to point calls is pointless, because they are clearly both MUSTS. I am not sure if Christian is arguing that layered codecs SHALL NOT be = considered, or if the requirements allow but are not biased towards layered proposals. If might be useful to clarify this point. Stephen Botzko On Thu, May 6, 2010 at 9:13 AM, Christian Hoene = wrote: Hi Dimitry, >Hi Christian, > >From application point of view, the layered stream structure allows >server manipulate channel bandwidth individually for each user with = zero >performance overhead. I understand. Because you as an application programmer want to have an = easy life, the codec designer shall develop a more complicated codec? In addition, everybody should suffer from a higher = bit rate? No, that is not fair. > Obviously, conferencing is the most important use-case. No, end-to-end connections are more frequent than conference calls. > >> a) First, this use case is a local optimization only. Thus, the must >not be standardized. >What do you mean exactly? "local optimization" of what? I mean that the layered coding is only used within one computer. It is = not important in-between computers. And, it is only a performance optimization that make the conference gateway faster. Sincerely, Christian > >> b) Second, instead of layered coding one can use other ways of >tweaking the implementation >> performance. For example, if you calculate a 512 FFT do get two 256 >FFTs for free. >> I bet there are thousand other shortcuts which I am not aware of. >How do this interrelates with scalability? Please, explain. > >Let's return back to the subject: > Shall layered coding be supported? - we think "yes", because ... >(see my first sentence) > Who needs it? - answered > Can we drop this requirement? - only if we have real good >reasons for it. Do we have them? > >Best regards, >Dmitry > >-----Original Message----- >From: Christian Hoene [mailto:hoene@uni-tuebingen.de] >Sent: Wednesday, May 05, 2010 11:02 PM >To: Vladimir Sviridenko; codec-bounces@ietf.org >Cc: Slava Borilin; Dmitry Yudin; codec@ietf.org >Subject: RE: [codec] #28: Layered bit-stream > >Hi Vladimir, > >>2/ we think that VoIP and Videoconferencing systems are users of such >>codecs. > >Could you please explain your position a bit? > >As far as I understand, layered coding helps if multiple streams having >the sample content but different rates must be generated. >For example, if a conferencing system stream the same audio stream to N >users but each users has a different bandwidth. Just encode >all layers and drop the higher layers for the low bandwidth users. This >approach is easy and efficient and reduce the encoding >complexity. > >The arguments against are simple. >a) First, this use case is a local optimization only. Thus, the must = not >be standardized. >b) Second, instead of layered coding one can use other ways of tweaking >the implementation performance. For example, if you >calculate a 512 FFT do get two 256 FFTs for free. I bet there are >thousand other shortcuts which I am not aware of. > >Thus, I have the opinion that layered coding is not worth the extra >bandwidth of 20 or more percentage. It is just good locally but >not needed for interoperability. > >Yours, > > Christian > > > > > > >>Yours, >>Vladimir Sviridenko >>SPIRIT >> >>-----Original Message----- >>From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >>Of codec issue tracker >>Sent: Sunday, May 02, 2010 5:10 PM >>To: hoene@uni-tuebingen.de >>Cc: codec@ietf.org >>Subject: [codec] #28: Layered bit-stream >> >>#28: Layered bit-stream >>------------------------------------+----------------------------------= >- >>---- >> Reporter: hoene@... | Owner: >> Type: defect | Status: new >> Priority: minor | Milestone: >>Component: requirements | Version: >> Severity: Active WG Document | Keywords: >>------------------------------------+----------------------------------= >- >>---- >> Shall layered coding be supported? >> Who needs it? >> Can we drop this requirement? >> >>-- >>Ticket URL: >>codec >> >>_______________________________________________ >>codec mailing list >>codec@ietf.org >>https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec =20 ------=_NextPart_000_0004_01CAED34.D5EE7FA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I respect the requirements of gateway manufactures and I think it is = important to consider them.

 

Let me explain my arguments a bit more by discussion point = b.

 

=D8  (b) I = agree with Dimity that layered codecs reduce the complexity of VOIP gateways and = perhaps conference bridges. 

I see that there is an important need to reduce the computational complexity = at gateways and conference bridges. Layered coding is an easy solution that = helps to reduce complexity. However, I think that there are many other ways to achieve similar complexity reduction WITHOUT requiring layered coding. = One example is a special encoder that encodes multiple streams at the same = time.

 

=D8  Also, = with layered codec designs you get wire-speed management of channel = bandwidth, so there can be a delay benefit as well as a complexity = reduction.

 

Also, a fast management of channel bandwidth can be achieved by controlling = the encoder (via a feedback channel not = locally)

 

Thus, I would vote for a NEED NOT or even MUST NOT because the costs of = layered encoding are imposed to all users of the codec but the benefit is only = to the gateways.

 

With best regards,

 

=A0Christian

 

 

 

-----------= ----------------------------------------------------

Dr.-Ing. = Christian Hoene

Interactive= Communication Systems (ICS), University of T=FCbingen =

Sand 13, = 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebingen.de/

 

From: stephen botzko [mailto:stephen.botzko@gmail.com]
Sent: Thursday, May 06, = 2010 3:41 PM
To: Christian Hoene
Cc: Dmitry Yudin; = codec@ietf.org
Subject: Re: [codec] #28: = Layered bit-stream

 

A couple of = observations on this

(a) I agree with Christian that layered codecs usually need higher = bitrates to achieve the same quality. Of course we do want good quality over our = desired bitrate range, and it is likely to be more difficult to achieve that = with a layered codec.

(b) I agree with Dimity that layered codecs reduce the complexity of = VOIP gateways and perhaps conference bridges.  Also, with layered codec = designs you get wire-speed management of channel bandwidth, so there can be a = delay benefit as well as a complexity reduction.

(c) Arguing about the relative priority of multipoint conferences vs = point to point calls is pointless, because they are clearly both MUSTS.

I am not sure if Christian is arguing that layered codecs SHALL NOT be considered, or if the requirements allow but are not biased towards = layered proposals.  If might be useful to clarify this point.

Stephen Botzko


On Thu, May 6, 2010 at 9:13 AM, Christian Hoene <hoene@uni-tuebingen.de> = wrote:

Hi Dimitry,

>Hi Christian,
>
>From application point of view, the layered stream structure = allows
>server manipulate channel bandwidth individually for each user with = zero
>performance overhead.

I understand. Because you as an application programmer want to have an = easy life, the codec designer shall develop a more
complicated codec? In addition, everybody should suffer from a higher = bit rate? No, that is not fair.

> Obviously, conferencing is the most important use-case.

No, end-to-end connections are more frequent than conference = calls.


>
>> a) First, this use case is a local optimization only. Thus, the = must
>not be standardized.

>What do you mean exactly? "local optimization" of = what?

I mean that the layered coding is only used within one computer. It is = not important in-between computers. And, it is only a
performance optimization that make the conference gateway faster.

Sincerely,

 Christian



>
>> b) Second, instead of layered coding one can use other ways = of
>tweaking the implementation
>> performance. For example, if you calculate a 512 FFT do get two = 256
>FFTs for free.
>> I bet there are thousand other shortcuts which I am not aware = of.

>How do this interrelates with scalability? Please, = explain.
>
>Let's return back to the subject:
>    Shall layered coding be supported? - we think "yes", because ...
>(see my first sentence)
>    Who needs it?           =            - answered
>    Can we drop this requirement?      - = only if we have real good
>reasons for it. Do we have them?
>
>Best regards,
>Dmitry

>
>-----Original Message-----
>From: Christian Hoene [mailto:hoene@uni-tuebingen.de]
>Sent: Wednesday, May 05, 2010 11:02 PM
>To: Vladimir Sviridenko; codec-bounces@ietf.org
>Cc: Slava Borilin; Dmitry Yudin; codec@ietf.org
>Subject: RE: [codec] #28: Layered bit-stream
>
>Hi Vladimir,
>
>>2/ we think that VoIP and Videoconferencing systems are users of = such
>>codecs.
>
>Could you please explain your position a bit?
>
>As far as I understand, layered coding helps if multiple streams = having
>the sample content but different rates must be generated.
>For example, if a conferencing system stream the same audio stream = to N
>users but each users has a different bandwidth. Just encode
>all layers and drop the higher layers for the low bandwidth users. = This
>approach is easy and efficient and reduce the encoding
>complexity.
>
>The arguments against are simple.
>a) First, this use case is a local optimization only. Thus, the must = not
>be standardized.
>b) Second, instead of layered coding one can use other ways of = tweaking
>the implementation performance. For example, if you
>calculate a 512 FFT do get two 256 FFTs for free. I bet there = are
>thousand other shortcuts which I am not aware of.
>
>Thus, I have the opinion that layered coding is not worth the = extra
>bandwidth of 20 or more percentage. It is just good locally but
>not needed for interoperability.
>
>Yours,
>
> Christian
>
>
>
>
>
>
>>Yours,
>>Vladimir Sviridenko
>>SPIRIT
>>
>>-----Original Message-----
>>From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf
>>Of codec issue tracker
>>Sent: Sunday, May 02, 2010 5:10 PM
>>To: hoene@uni-tuebingen.de
>>Cc: codec@ietf.org
>>Subject: [codec] #28: Layered bit-stream
>>
>>#28: Layered bit-stream
>>------------------------------------+----------------------------= ------
>-
>>----
>> Reporter:  hoene@...           =       |       Owner:
>>     Type:  defect         =          |      Status:  new
>> Priority:  minor             =       |   Milestone:
>>Component:  requirements            |     Version:
>> Severity:  Active WG Document      |    Keywords:
>>------------------------------------+----------------------------= ------
>-
>>----
>> Shall layered coding be supported?
>> Who needs it?
>> Can we drop this requirement?
>>
>>--
>>Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/28&= gt;
>>codec <http://tools.ietf.org/codec/>
>>
>>_______________________________________________
>>codec mailing list
>>codec@ietf.org
>>https://www.ietf.org/mailman/listinfo/codec

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

 

------=_NextPart_000_0004_01CAED34.D5EE7FA0-- From Yudin@spiritdsp.com Thu May 6 02:45:23 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 054DB3A6965; Thu, 6 May 2010 02:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFzUm0TSexPp; Thu, 6 May 2010 02:45:22 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id B18E33A6956; Thu, 6 May 2010 02:45:20 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.14.4/8.14.4) with ESMTP id o469j4dT096321; Thu, 6 May 2010 13:45:05 +0400 (MSD) (envelope-from Yudin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 May 2010 13:45:15 +0400 Message-ID: <5A3D7E7076F5DF42990A8C164308F8107FB370@mail-srv.spiritcorp.com> X-MimeOLE: Produced By Microsoft Exchange V6.5 In-Reply-To: <001501caec85$72c43ff0$584cbfd0$@de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] #28: Layered bit-stream Thread-Index: Acrp+N7OZyC4AF1nTgyf7CZ16s3UtAANWOzAAAGk76AAT0iDIAABPRywAEDLfdAAAAxtwAABS4YwAAEZmgAAHY3rcA== References: <5A3D7E7076F5DF42990A8C164308F8107884A0@mail-srv.spiritcorp.com> <5A3D7E7076F5DF42990A8C164308F8107FB29E@mail-srv.spiritcorp.com> <5A3D7E7076F5DF42990A8C164308F8107FB29F@mail-srv.spiritcorp.com> <5A3D7E7076F5DF42990A8C164308F8107FB2A7@mail-srv.spiritcorp.com> <001501caec85$72c43ff0$584cbfd0$@de> From: "Dmitry Yudin" To: "Christian Hoene" , "Vladimir Sviridenko" , X-Scanned-By: MIMEDefang 2.67 on 192.168.125.15 X-Mailman-Approved-At: Thu, 06 May 2010 08:19:15 -0700 Cc: Slava Borilin , codec@ietf.org Subject: Re: [codec] #28: Layered bit-stream X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 09:47:12 -0000 Hi Christian, >From application point of view, the layered stream structure allows server manipulate channel bandwidth individually for each user with zero performance overhead. Obviously, conferencing is the most important use-case.=20 > a) First, this use case is a local optimization only. Thus, the must not be standardized. What do you mean exactly? "local optimization" of what? > b) Second, instead of layered coding one can use other ways of tweaking the implementation=20 > performance. For example, if you calculate a 512 FFT do get two 256 FFTs for free.=20 > I bet there are thousand other shortcuts which I am not aware of. How do this interrelates with scalability? Please, explain. Let's return back to the subject: Shall layered coding be supported? - we think "yes", because ... (see my first sentence) Who needs it? - answered Can we drop this requirement? - only if we have real good reasons for it. Do we have them?=20 Best regards, Dmitry -----Original Message----- From: Christian Hoene [mailto:hoene@uni-tuebingen.de]=20 Sent: Wednesday, May 05, 2010 11:02 PM To: Vladimir Sviridenko; codec-bounces@ietf.org Cc: Slava Borilin; Dmitry Yudin; codec@ietf.org Subject: RE: [codec] #28: Layered bit-stream Hi Vladimir, >2/ we think that VoIP and Videoconferencing systems are users of such >codecs. Could you please explain your position a bit? As far as I understand, layered coding helps if multiple streams having the sample content but different rates must be generated. For example, if a conferencing system stream the same audio stream to N users but each users has a different bandwidth. Just encode all layers and drop the higher layers for the low bandwidth users. This approach is easy and efficient and reduce the encoding complexity. The arguments against are simple.=20 a) First, this use case is a local optimization only. Thus, the must not be standardized. b) Second, instead of layered coding one can use other ways of tweaking the implementation performance. For example, if you calculate a 512 FFT do get two 256 FFTs for free. I bet there are thousand other shortcuts which I am not aware of. Thus, I have the opinion that layered coding is not worth the extra bandwidth of 20 or more percentage. It is just good locally but not needed for interoperability. Yours, Christian >Yours, >Vladimir Sviridenko >SPIRIT > >-----Original Message----- >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >Of codec issue tracker >Sent: Sunday, May 02, 2010 5:10 PM >To: hoene@uni-tuebingen.de >Cc: codec@ietf.org >Subject: [codec] #28: Layered bit-stream > >#28: Layered bit-stream >------------------------------------+---------------------------------- - >---- > Reporter: hoene@... | Owner: > Type: defect | Status: new > Priority: minor | Milestone: >Component: requirements | Version: > Severity: Active WG Document | Keywords: >------------------------------------+---------------------------------- - >---- > Shall layered coding be supported? > Who needs it? > Can we drop this requirement? > >-- >Ticket URL: >codec > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From Yudin@spiritdsp.com Thu May 6 08:12:56 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 858BD3A6D46 for ; Thu, 6 May 2010 08:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.001 X-Spam-Level: X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvbI7yocbg2c for ; Thu, 6 May 2010 08:12:55 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 1E9A828C33A for ; Thu, 6 May 2010 07:51:02 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.14.4/8.14.4) with ESMTP id o46Eomt5012830; Thu, 6 May 2010 18:50:48 +0400 (MSD) (envelope-from Yudin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 May 2010 18:50:58 +0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <5A3D7E7076F5DF42990A8C164308F8107FB4C1@mail-srv.spiritcorp.com> In-Reply-To: <000201caed1d$e9ae4ff0$bd0aefd0$@de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] #28: Layered bit-stream Thread-Index: Acrp+N7OZyC4AF1nTgyf7CZ16s3UtAANWOzAAAGk76AAT0iDIAABPRywAEDLfdAAAAxtwAABS4YwAAEZmgAAHY3rcAAIqVrwAAEUnaA= References: <5A3D7E7076F5DF42990A8C164308F8107884A0@mail-srv.spiritcorp.com> <5A3D7E7076F5DF42990A8C164308F8107FB29E@mail-srv.spiritcorp.com> <5A3D7E7076F5DF42990A8C164308F8107FB29F@mail-srv.spiritcorp.com> <5A3D7E7076F5DF42990A8C164308F8107FB2A7@mail-srv.spiritcorp.com> <001501caec85$72c43ff0$584cbfd0$@de> <5A3D7E7076F5DF42990A8C164308F8107FB370@mail-srv.spiritcorp.com> <000201caed1d$e9ae4ff0$bd0aefd0$@de> From: "Dmitry Yudin" To: "Christian Hoene" X-Scanned-By: MIMEDefang 2.67 on 192.168.125.15 X-Mailman-Approved-At: Thu, 06 May 2010 08:19:15 -0700 Cc: Vladimir Sviridenko , codec@ietf.org, Slava Borilin Subject: Re: [codec] #28: Layered bit-stream X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 15:12:56 -0000 Hi, > I understand. Because you as an application programmer want to have an easy life,=20 > the codec designer shall develop a more complicated codec? In addition, everybody=20 > should suffer from a higher bit rate? No, that is not fair. Sorry Christian, but I'm not share your idea to personalize this discussion. Definitely, there are number of applications that can (more or less efficiently) utilize=20 layered stream structure. At the same time, scalability makes codec more complex and cause bitrate penalty due to a simple fact that entropy(a+b)<=3Dentropy(a)+entropy(b).=20 The only question is: what penalty is acceptable and what is not? Based on IP-MR codec=20 experience I consider the price for scalability as not too high. >> Obviously, conferencing is the most important use-case. > No, end-to-end connections are more frequent than conference calls. Actually, the statement was "Obviously, conferencing is the most=20 important use-case for layered coder". > I mean that the layered coding is only used within one computer.=20 > It is not important in-between computers. And, it is only a > performance optimization that make the conference gateway faster. This is correct. No other benefits except performance saving. Regards, Dmitry -----Original Message----- From: Christian Hoene [mailto:hoene@uni-tuebingen.de]=20 Sent: Thursday, May 06, 2010 5:13 PM To: Dmitry Yudin Cc: codec@ietf.org Subject: RE: [codec] #28: Layered bit-stream Hi Dimitry, >Hi Christian, > >From application point of view, the layered stream structure allows >server manipulate channel bandwidth individually for each user with zero >performance overhead.=20 I understand. Because you as an application programmer want to have an easy life, the codec designer shall develop a more complicated codec? In addition, everybody should suffer from a higher bit rate? No, that is not fair. > Obviously, conferencing is the most important use-case. No, end-to-end connections are more frequent than conference calls. > >> a) First, this use case is a local optimization only. Thus, the must >not be standardized. >What do you mean exactly? "local optimization" of what? I mean that the layered coding is only used within one computer. It is not important in-between computers. And, it is only a performance optimization that make the conference gateway faster. Sincerely, Christian > >> b) Second, instead of layered coding one can use other ways of >tweaking the implementation >> performance. For example, if you calculate a 512 FFT do get two 256 >FFTs for free. >> I bet there are thousand other shortcuts which I am not aware of. >How do this interrelates with scalability? Please, explain. > >Let's return back to the subject: > Shall layered coding be supported? - we think "yes", because ... >(see my first sentence) > Who needs it? - answered > Can we drop this requirement? - only if we have real good >reasons for it. Do we have them? > >Best regards, >Dmitry > >-----Original Message----- >From: Christian Hoene [mailto:hoene@uni-tuebingen.de] >Sent: Wednesday, May 05, 2010 11:02 PM >To: Vladimir Sviridenko; codec-bounces@ietf.org >Cc: Slava Borilin; Dmitry Yudin; codec@ietf.org >Subject: RE: [codec] #28: Layered bit-stream > >Hi Vladimir, > >>2/ we think that VoIP and Videoconferencing systems are users of such >>codecs. > >Could you please explain your position a bit? > >As far as I understand, layered coding helps if multiple streams having >the sample content but different rates must be generated. >For example, if a conferencing system stream the same audio stream to N >users but each users has a different bandwidth. Just encode >all layers and drop the higher layers for the low bandwidth users. This >approach is easy and efficient and reduce the encoding >complexity. > >The arguments against are simple. >a) First, this use case is a local optimization only. Thus, the must not >be standardized. >b) Second, instead of layered coding one can use other ways of tweaking >the implementation performance. For example, if you >calculate a 512 FFT do get two 256 FFTs for free. I bet there are >thousand other shortcuts which I am not aware of. > >Thus, I have the opinion that layered coding is not worth the extra >bandwidth of 20 or more percentage. It is just good locally but >not needed for interoperability. > >Yours, > > Christian > > > > > > >>Yours, >>Vladimir Sviridenko >>SPIRIT >> >>-----Original Message----- >>From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >>Of codec issue tracker >>Sent: Sunday, May 02, 2010 5:10 PM >>To: hoene@uni-tuebingen.de >>Cc: codec@ietf.org >>Subject: [codec] #28: Layered bit-stream >> >>#28: Layered bit-stream >>------------------------------------+--------------------------------- - >- >>---- >> Reporter: hoene@... | Owner: >> Type: defect | Status: new >> Priority: minor | Milestone: >>Component: requirements | Version: >> Severity: Active WG Document | Keywords: >>------------------------------------+--------------------------------- - >- >>---- >> Shall layered coding be supported? >> Who needs it? >> Can we drop this requirement? >> >>-- >>Ticket URL: >>codec >> >>_______________________________________________ >>codec mailing list >>codec@ietf.org >>https://www.ietf.org/mailman/listinfo/codec From Yudin@spiritdsp.com Thu May 6 09:11:35 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CE553A6914 for ; Thu, 6 May 2010 09:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KBaU3I+WBMz for ; Thu, 6 May 2010 09:11:25 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 426893A6C01 for ; Thu, 6 May 2010 09:08:23 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.14.4/8.14.4) with ESMTP id o46G7iNE014592; Thu, 6 May 2010 20:07:45 +0400 (MSD) (envelope-from Yudin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAED36.3FDB63D3" Date: Thu, 6 May 2010 20:07:55 +0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <5A3D7E7076F5DF42990A8C164308F8107FB522@mail-srv.spiritcorp.com> In-Reply-To: <000301caed24$1265afa0$37310ee0$@de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] #28: Layered bit-stream Thread-Index: AcrtIdXKkQSKYbnwSKqDIHRCpL10lgAAN/gQAAMtf4A= References: <5A3D7E7076F5DF42990A8C164308F8107884A0@mail-srv.spiritcorp.com> <5A3D7E7076F5DF42990A8C164308F8107FB29E@mail-srv.spiritcorp.com> <5A3D7E7076F5DF42990A8C164308F8107FB29F@mail-srv.spiritcorp.com> <5A3D7E7076F5DF42990A8C164308F8107FB2A7@mail-srv.spiritcorp.com> <001501caec85$72c43ff0$584cbfd0$@de> <5A3D7E7076F5DF42990A8C164308F8107FB370@mail-srv.spiritcorp.com> <000201caed1d$e9ae4ff0$bd0aefd0$@de> <000301caed24$1265afa0$37310ee0$@de> From: "Dmitry Yudin" To: "Christian Hoene" , "stephen botzko" X-Scanned-By: MIMEDefang 2.67 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] #28: Layered bit-stream X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 16:11:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAED36.3FDB63D3 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 > However, I think that there are many other ways to achieve similar = complexity reduction WITHOUT=20 > requiring layered coding. One example is a special encoder that = encodes multiple streams at the same time. Do you mean each user should delivery several independent stream at = time? =20 > Thus, I would vote for a NEED NOT or even MUST NOT because the costs = of layered encoding are=20 > imposed to all users of the codec but the benefit is only to the = gateways. Christian, I'm really very appreciate your point of view, but = unfortunately I find it a little bit not enough=20 constructive to discuss. Of course you right "costs of layered encoding = ..." - this is all true. But the thing is that=20 this is not a point we should stand on. Let's stay on a point of = problems and solutions.=20 The problem is: gateway have to recompress data to fit user bandwidth = and it would be very desired to=20 decrease recompression cost: Does this problem live only in my mind? - any = considerations are welcome. Possible solution : The layered stream structure allows zero cost = recompression (but increases bitrate/quality ratio). All other solutions are also welcome. =20 Best regards, Dmitry =20 =20 From: Christian Hoene [mailto:hoene@uni-tuebingen.de]=20 Sent: Thursday, May 06, 2010 5:58 PM To: 'stephen botzko' Cc: Dmitry Yudin; codec@ietf.org Subject: RE: [codec] #28: Layered bit-stream =20 Hi, =20 I respect the requirements of gateway manufactures and I think it is = important to consider them. =20 Let me explain my arguments a bit more by discussion point b. =20 =D8 (b) I agree with Dimity that layered codecs reduce the complexity = of VOIP gateways and perhaps conference bridges. =20 I see that there is an important need to reduce the computational = complexity at gateways and conference bridges. Layered coding is an easy = solution that helps to reduce complexity. However, I think that there = are many other ways to achieve similar complexity reduction WITHOUT = requiring layered coding. One example is a special encoder that encodes = multiple streams at the same time.=20 =20 =D8 Also, with layered codec designs you get wire-speed management of = channel bandwidth, so there can be a delay benefit as well as a = complexity reduction. =20 Also, a fast management of channel bandwidth can be achieved by = controlling the encoder (via a feedback channel not locally) =20 Thus, I would vote for a NEED NOT or even MUST NOT because the costs of = layered encoding are imposed to all users of the codec but the benefit = is only to the gateways. =20 With best regards, =20 Christian =20 =20 =20 --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ =20 =20 From: stephen botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Thursday, May 06, 2010 3:41 PM To: Christian Hoene Cc: Dmitry Yudin; codec@ietf.org Subject: Re: [codec] #28: Layered bit-stream =20 A couple of observations on this (a) I agree with Christian that layered codecs usually need higher = bitrates to achieve the same quality. Of course we do want good quality = over our desired bitrate range, and it is likely to be more difficult to = achieve that with a layered codec. (b) I agree with Dimity that layered codecs reduce the complexity of = VOIP gateways and perhaps conference bridges. Also, with layered codec = designs you get wire-speed management of channel bandwidth, so there can = be a delay benefit as well as a complexity reduction. (c) Arguing about the relative priority of multipoint conferences vs = point to point calls is pointless, because they are clearly both MUSTS. I am not sure if Christian is arguing that layered codecs SHALL NOT be = considered, or if the requirements allow but are not biased towards = layered proposals. If might be useful to clarify this point. Stephen Botzko On Thu, May 6, 2010 at 9:13 AM, Christian Hoene = wrote: Hi Dimitry, >Hi Christian, > >From application point of view, the layered stream structure allows >server manipulate channel bandwidth individually for each user with = zero >performance overhead. I understand. Because you as an application programmer want to have an = easy life, the codec designer shall develop a more complicated codec? In addition, everybody should suffer from a higher = bit rate? No, that is not fair. > Obviously, conferencing is the most important use-case. No, end-to-end connections are more frequent than conference calls. > >> a) First, this use case is a local optimization only. Thus, the must >not be standardized. >What do you mean exactly? "local optimization" of what? I mean that the layered coding is only used within one computer. It is = not important in-between computers. And, it is only a performance optimization that make the conference gateway faster. Sincerely, Christian > >> b) Second, instead of layered coding one can use other ways of >tweaking the implementation >> performance. For example, if you calculate a 512 FFT do get two 256 >FFTs for free. >> I bet there are thousand other shortcuts which I am not aware of. >How do this interrelates with scalability? Please, explain. > >Let's return back to the subject: > Shall layered coding be supported? - we think "yes", because ... >(see my first sentence) > Who needs it? - answered > Can we drop this requirement? - only if we have real good >reasons for it. Do we have them? > >Best regards, >Dmitry > >-----Original Message----- >From: Christian Hoene [mailto:hoene@uni-tuebingen.de] >Sent: Wednesday, May 05, 2010 11:02 PM >To: Vladimir Sviridenko; codec-bounces@ietf.org >Cc: Slava Borilin; Dmitry Yudin; codec@ietf.org >Subject: RE: [codec] #28: Layered bit-stream > >Hi Vladimir, > >>2/ we think that VoIP and Videoconferencing systems are users of such >>codecs. > >Could you please explain your position a bit? > >As far as I understand, layered coding helps if multiple streams having >the sample content but different rates must be generated. >For example, if a conferencing system stream the same audio stream to N >users but each users has a different bandwidth. Just encode >all layers and drop the higher layers for the low bandwidth users. This >approach is easy and efficient and reduce the encoding >complexity. > >The arguments against are simple. >a) First, this use case is a local optimization only. Thus, the must = not >be standardized. >b) Second, instead of layered coding one can use other ways of tweaking >the implementation performance. For example, if you >calculate a 512 FFT do get two 256 FFTs for free. I bet there are >thousand other shortcuts which I am not aware of. > >Thus, I have the opinion that layered coding is not worth the extra >bandwidth of 20 or more percentage. It is just good locally but >not needed for interoperability. > >Yours, > > Christian > > > > > > >>Yours, >>Vladimir Sviridenko >>SPIRIT >> >>-----Original Message----- >>From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >>Of codec issue tracker >>Sent: Sunday, May 02, 2010 5:10 PM >>To: hoene@uni-tuebingen.de >>Cc: codec@ietf.org >>Subject: [codec] #28: Layered bit-stream >> >>#28: Layered bit-stream >>------------------------------------+----------------------------------= >- >>---- >> Reporter: hoene@... | Owner: >> Type: defect | Status: new >> Priority: minor | Milestone: >>Component: requirements | Version: >> Severity: Active WG Document | Keywords: >>------------------------------------+----------------------------------= >- >>---- >> Shall layered coding be supported? >> Who needs it? >> Can we drop this requirement? >> >>-- >>Ticket URL: >>codec >> >>_______________________________________________ >>codec mailing list >>codec@ietf.org >>https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec =20 ------_=_NextPart_001_01CAED36.3FDB63D3 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

> However, I think that there are many other ways to = achieve similar complexity reduction WITHOUT

> requiring layered coding. One example is a special = encoder that encodes multiple streams at the same time.

Do you mean each user should delivery several independent = stream at time?

 

> Thus, I would vote for a NEED NOT = or even MUST NOT because the costs of layered encoding are =

> imposed to all users of the codec but the benefit is = only to the gateways.

Christian, I’m really very appreciate your point of = view, but unfortunately I find it a little bit not enough =

constructive to discuss. Of course you right = “costs of layered encoding …” - this is all true. But the thing is that

this is not a point we should stand on. Let’s stay = on a point of problems and solutions.

The problem is: gateway have to recompress data to fit = user bandwidth and it would be very desired to

decrease recompression cost:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Does this problem live only in my mind? - any considerations are welcome.

Possible solution :

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = The layered stream structure allows zero cost recompression (but increases bitrate/quality = ratio).

All other solutions are also = welcome.

 

Best regards,

Dmitry

 

 

From: Christian Hoene [mailto:hoene@uni-tuebingen.de]
Sent: Thursday, May 06, 2010 5:58 PM
To: 'stephen botzko'
Cc: Dmitry Yudin; codec@ietf.org
Subject: RE: [codec] #28: Layered = bit-stream

 

Hi,

 

I respect the requirements of gateway manufactures and I = think it is important to consider them.

 

Let me explain my arguments a bit more by discussion = point b.

 

=D8  (b) I agree with Dimity that layered codecs reduce the = complexity of VOIP gateways and perhaps conference bridges. 

I see that there is an important need to reduce the = computational complexity at gateways and conference bridges. Layered coding is an easy solution that helps to reduce complexity. However, I think that there = are many other ways to achieve similar complexity reduction WITHOUT requiring = layered coding. One example is a special encoder that encodes multiple streams = at the same time.

 

=D8  Also, with layered codec designs you get wire-speed = management of channel bandwidth, so there can be a delay benefit as well as a = complexity reduction.

 

Also, a fast management of channel bandwidth can be = achieved by controlling the encoder (via a feedback channel not = locally)

 

Thus, I would vote for a NEED NOT or even MUST NOT = because the costs of layered encoding are imposed to all users of the codec but the = benefit is only to the gateways.

 

With best regards,

 

 Christian

 

 

 

----------------------------------------------------------= -----

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of = T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 = 2970532
http://www.net.uni-tuebingen.de/=

 

From:= = stephen botzko [mailto:stephen.botzko@gmail.com]
Sent: Thursday, May 06, 2010 3:41 PM
To: Christian Hoene
Cc: Dmitry Yudin; codec@ietf.org
Subject: Re: [codec] #28: Layered = bit-stream

 

A = couple of observations on this

(a) I agree with Christian that layered codecs usually need higher = bitrates to achieve the same quality. Of course we do want good quality over our = desired bitrate range, and it is likely to be more difficult to achieve that = with a layered codec.

(b) I agree with Dimity that layered codecs reduce the complexity of = VOIP gateways and perhaps conference bridges.  Also, with layered codec = designs you get wire-speed management of channel bandwidth, so there can be a = delay benefit as well as a complexity reduction.

(c) Arguing about the relative priority of multipoint conferences vs = point to point calls is pointless, because they are clearly both MUSTS.

I am not sure if Christian is arguing that layered codecs SHALL NOT be considered, or if the requirements allow but are not biased towards = layered proposals.  If might be useful to clarify this point.

Stephen Botzko

On Thu, May 6, 2010 at 9:13 AM, = Christian Hoene <hoene@uni-tuebingen.de> wrote:

Hi Dimitry,

>Hi Christian,
>
>From application point of view, the layered stream structure = allows
>server manipulate channel bandwidth individually for each user with = zero
>performance overhead.

I understand. Because you as an application programmer want to have an = easy life, the codec designer shall develop a more
complicated codec? In addition, everybody should suffer from a higher = bit rate? No, that is not fair.

> Obviously, conferencing is the most important use-case.

No, end-to-end connections are more frequent than conference = calls.


>
>> a) First, this use case is a local optimization only. Thus, the = must
>not be standardized.

>What do you mean exactly? = "local optimization" of what?

I mean that the layered coding is only used within one computer. It is = not important in-between computers. And, it is only a
performance optimization that make the conference gateway faster.

Sincerely,

 Christian



>
>> b) Second, instead of layered coding one can use other ways = of
>tweaking the implementation
>> performance. For example, if you calculate a 512 FFT do get two = 256
>FFTs for free.
>> I bet there are thousand other shortcuts which I am not aware = of.

>How do this interrelates with = scalability? Please, explain.
>
>Let's return back to the subject:
>    Shall layered coding be supported? - we think "yes", because ...
>(see my first sentence)
>    Who needs it?           =            - answered
>    Can we drop this requirement?      - = only if we have real good
>reasons for it. Do we have them?
>
>Best regards,
>Dmitry

>
>-----Original Message-----
>From: Christian Hoene [mailto:hoene@uni-tuebingen.de]
>Sent: Wednesday, May 05, 2010 11:02 PM
>To: Vladimir Sviridenko; codec-bounces@ietf.org
>Cc: Slava Borilin; Dmitry Yudin; codec@ietf.org
>Subject: RE: [codec] #28: Layered bit-stream
>
>Hi Vladimir,
>
>>2/ we think that VoIP and Videoconferencing systems are users of = such
>>codecs.
>
>Could you please explain your position a bit?
>
>As far as I understand, layered coding helps if multiple streams = having
>the sample content but different rates must be generated.
>For example, if a conferencing system stream the same audio stream = to N
>users but each users has a different bandwidth. Just encode
>all layers and drop the higher layers for the low bandwidth users. = This
>approach is easy and efficient and reduce the encoding
>complexity.
>
>The arguments against are simple.
>a) First, this use case is a local optimization only. Thus, the must = not
>be standardized.
>b) Second, instead of layered coding one can use other ways of = tweaking
>the implementation performance. For example, if you
>calculate a 512 FFT do get two 256 FFTs for free. I bet there = are
>thousand other shortcuts which I am not aware of.
>
>Thus, I have the opinion that layered coding is not worth the = extra
>bandwidth of 20 or more percentage. It is just good locally but
>not needed for interoperability.
>
>Yours,
>
> Christian
>
>
>
>
>
>
>>Yours,
>>Vladimir Sviridenko
>>SPIRIT
>>
>>-----Original Message-----
>>From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf
>>Of codec issue tracker
>>Sent: Sunday, May 02, 2010 5:10 PM
>>To: hoene@uni-tuebingen.de
>>Cc: codec@ietf.org
>>Subject: [codec] #28: Layered bit-stream
>>
>>#28: Layered bit-stream
>>------------------------------------+----------------------------= ------
>-
>>----
>> Reporter:  hoene@...           =       |       Owner:
>>     Type:  defect         =          |      Status:  new
>> Priority:  minor             =       |   Milestone:
>>Component:  requirements            |     Version:
>> Severity:  Active WG Document      |    Keywords:
>>------------------------------------+----------------------------= ------
>-
>>----
>> Shall layered coding be supported?
>> Who needs it?
>> Can we drop this requirement?
>>
>>--
>>Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/28&= gt;
>>codec <http://tools.ietf.org/codec/>
>>
>>_______________________________________________
>>codec mailing list
>>codec@ietf.org
>>https://www.ietf.org/mailman/listinfo/codec

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

 

------_=_NextPart_001_01CAED36.3FDB63D3-- From rchen@broadcom.com Thu May 6 12:04:23 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FCB63A6989 for ; Thu, 6 May 2010 12:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.176 X-Spam-Level: X-Spam-Status: No, score=-0.176 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfzHF5UN771C for ; Thu, 6 May 2010 12:04:22 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 0111C3A6BBC for ; Thu, 6 May 2010 12:04:20 -0700 (PDT) Received: from [10.9.200.131] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 06 May 2010 12:03:26 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Thu, 6 May 2010 12:03:12 -0700 From: "Raymond (Juin-Hwey) Chen" To: "stephen botzko" Date: Thu, 6 May 2010 12:03:08 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcrsQwno3Hpz1jahRX+JkGogPbxfdgBA0v1g Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67FDCDF738O198894993-14-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 19:04:23 -0000 Hi Stephen, Sorry, I was too busy to respond yesterday. You wrote: > Generally the need to buffer the current frame is treated as part of the= =20 > algorithmic delay.=A0 At least I believe that is what the ITU-T does. > So maybe we need a list of what all these components are?=A0=20 [Raymond]: Sure, my previous analysis was an attempt to do just that, but p= erhaps my list was not complete enough. > I'd suggest keeping the gateway out of it for the first pass. [Raymond]: May I ask why?=A0 > I've worked with Gateways\MCUs where the packet size had to be increased= =20 > because packet loading in the product became too high.=A0 Also, if you=20 > have QOS features enabled in many routers, the routers themselves have=20 > to start using a "software path", which creates a similar throughput=20 > problem in the routers.=A0 Too many packets per second can overwhelm thes= e=20 > devices, creating both capacity issues and excessive queuing delays.=20 =A0 [Raymond]: OK, now I see what you meant when you said "it is totally possib= le that reducing the frame size might actually increase the latency". This = is probably more likely to happen many years ago but less of a problem now,= as I was told by networking guys that nowadays networking gears can handle= 5 ms packets without problems. In fact, the VoIP gateway I talked about, = which has a 12 to 17 ms codec-dependent one-way delay for a 5 ms frame/pack= et size, was done 6 or 7 years ago. Even back then the gateway can handle = it without problems.=20 > I don't think the group has an agreed-upon model which names these=20 > components consistently, and describes are appropriately in-scope and=20 > which are out-of-scope.=A0 Perhaps that is one reason why Koen is saying= =20 > multiplier the number is 1x.=A0=20 > Also, there are real-world negative consequences to higher packet rates,= =20 > and we have not yet considered them.=20 [Raymond]: Yes, higher packet rates means higher packet header overhead bit= -rates, more burden on networking gears in I/O bandwidth and throughput, et= c. However, that's the price to pay if we need low latency, just like if w= e want to avoid all these, the price to pay is higher latency. It's all a = matter of trade-off and the best choice depends on the application at hand.= =20 In Section 2 of Jean-Marc's Internet Draft draft-ietf-codec-requirements-00= , 6 specific applications for the IETF codec were listed. Fully 5 of these= 6 applications list less than 10 ms of codec delay as either a requirement= or a desirable feature. (The only exception is point-to-point calls.) The= only way to achieve this less than 10 ms codec delay is with a codec frame= size of less than 10 ms, and to get the kind of low latency that these 5 a= pplications desire, each packet had better contain only one codec frame as = payload (rather than multiple frames).=20 So, yeah, there is negative consequences of the resulting higher packet rat= es, but hey, if we want to get low latency as desired or required by these = 5 applications, that's the price we will need to be prepared to pay. There= is no free lunch. If we want to use a 20 ms frame/packet size to avoid th= ose consequences, then we need pay the price of not achieving the low laten= cy that these 5 applications desire or require. Raymond From stephen.botzko@gmail.com Thu May 6 12:12:40 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B05F93A6A6D for ; Thu, 6 May 2010 12:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.609 X-Spam-Level: X-Spam-Status: No, score=-0.609 tagged_above=-999 required=5 tests=[AWL=-0.611, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QDbcWSHS7zP for ; Thu, 6 May 2010 12:12:39 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id CE0133A68A0 for ; Thu, 6 May 2010 12:12:37 -0700 (PDT) Received: by wwb18 with SMTP id 18so236704wwb.31 for ; Thu, 06 May 2010 12:12:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=6WhCNSre5jjD2w9Wou4ZHAQRZXDjIqqsN+jwE6RlZVQ=; b=W19h3lW+z8w2dUatPFUxE20BEAwF5AJ71rbjz0+mfzYeI8kKOhqhqW7HMdKNHI0oMW 0zt/gsLXvg5tFnXYAD+ITkdoIEAIvQI0VKzUOg9OpsSBQ42AaPeKlI8PiG1EMwb5M9LY c0DNnPQcw1YQBPaq7gup9QbcYReZ1zCnvJaZk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QexFI5fwLPghY15ShbcfvxIiuahggYzUXv0/oMxpD+Cfq8axndsJ7QNATP3Xu48tzl Ymgb7wNbyzSGEc5P6JPvP0BMuuP3x5ixXKsiwj3YbcWk3Eht3U1DlvFOitnqrJlHZJjg 3Aq9gsas7bUT6FJyN2UuxRIYIqYJL1iAxDzfk= MIME-Version: 1.0 Received: by 10.216.90.84 with SMTP id d62mr3235605wef.211.1273173141211; Thu, 06 May 2010 12:12:21 -0700 (PDT) Received: by 10.216.28.139 with HTTP; Thu, 6 May 2010 12:12:20 -0700 (PDT) In-Reply-To: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> Date: Thu, 6 May 2010 15:12:20 -0400 Message-ID: From: stephen botzko To: "Raymond (Juin-Hwey) Chen" Content-Type: multipart/alternative; boundary=0016e6d643ffd1cbbe0485f1b831 Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2010 19:12:40 -0000 --0016e6d643ffd1cbbe0485f1b831 Content-Type: text/plain; charset=ISO-8859-1 I basically agree with your points below. There are lots of tradeoffs in codec design, including this one. Personally I think there is value in a moderate delay 20 ms frame size, possibly augmented with a low-delay mode. 20 ms works quite well for video conferencing, since the video frame rate is no faster than 60 fps (about 15 ms per frame). Regards Stephen Botzko On Thu, May 6, 2010 at 3:03 PM, Raymond (Juin-Hwey) Chen wrote: > Hi Stephen, > > Sorry, I was too busy to respond yesterday. > > You wrote: > > Generally the need to buffer the current frame is treated as part of the > > algorithmic delay. At least I believe that is what the ITU-T does. > > So maybe we need a list of what all these components are? > > [Raymond]: Sure, my previous analysis was an attempt to do just that, but > perhaps my list was not complete enough. > > > I'd suggest keeping the gateway out of it for the first pass. > > [Raymond]: May I ask why? > > > I've worked with Gateways\MCUs where the packet size had to be increased > > because packet loading in the product became too high. Also, if you > > have QOS features enabled in many routers, the routers themselves have > > to start using a "software path", which creates a similar throughput > > problem in the routers. Too many packets per second can overwhelm these > > devices, creating both capacity issues and excessive queuing delays. > > [Raymond]: OK, now I see what you meant when you said "it is totally > possible that reducing the frame size might actually increase the latency". > This is probably more likely to happen many years ago but less of a problem > now, as I was told by networking guys that nowadays networking gears can > handle 5 ms packets without problems. In fact, the VoIP gateway I talked > about, which has a 12 to 17 ms codec-dependent one-way delay for a 5 ms > frame/packet size, was done 6 or 7 years ago. Even back then the gateway > can handle it without problems. > > > I don't think the group has an agreed-upon model which names these > > components consistently, and describes are appropriately in-scope and > > which are out-of-scope. Perhaps that is one reason why Koen is saying > > multiplier the number is 1x. > > > Also, there are real-world negative consequences to higher packet rates, > > and we have not yet considered them. > > [Raymond]: Yes, higher packet rates means higher packet header overhead > bit-rates, more burden on networking gears in I/O bandwidth and throughput, > etc. However, that's the price to pay if we need low latency, just like if > we want to avoid all these, the price to pay is higher latency. It's all a > matter of trade-off and the best choice depends on the application at hand. > > In Section 2 of Jean-Marc's Internet Draft > draft-ietf-codec-requirements-00, 6 specific applications for the IETF codec > were listed. Fully 5 of these 6 applications list less than 10 ms of codec > delay as either a requirement or a desirable feature. (The only exception is > point-to-point calls.) The only way to achieve this less than 10 ms codec > delay is with a codec frame size of less than 10 ms, and to get the kind of > low latency that these 5 applications desire, each packet had better contain > only one codec frame as payload (rather than multiple frames). > > So, yeah, there is negative consequences of the resulting higher packet > rates, but hey, if we want to get low latency as desired or required by > these 5 applications, that's the price we will need to be prepared to pay. > There is no free lunch. If we want to use a 20 ms frame/packet size to > avoid those consequences, then we need pay the price of not achieving the > low latency that these 5 applications desire or require. > > Raymond > > --0016e6d643ffd1cbbe0485f1b831 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I basically agree with your points below.=A0

There are lots of trad= eoffs in codec design, including this one.=A0 Personally I think there is v= alue in a moderate delay 20 ms frame size, possibly augmented with a low-de= lay mode.=A0 20 ms works quite well for video conferencing, since the video= frame rate is no faster than 60 fps (about 15 ms per frame).

Regards
Stephen Botzko





On Thu, May 6, 2010 at 3:03 PM, Raymond (Juin-Hwey) Chen <rchen@broadcom.com> wrote:
Hi Stephen,

Sorry, I was too busy to respond yesterday.

You wrote:
> Generally the need to buffer the current frame is treated as part of t= he
> algorithmic delay.=A0 At least I believe that is what the ITU-T does.<= br> > So maybe we need a list of what all these components are?=A0

[Raymond]: Sure, my previous analysis was an attempt to do just that,= but perhaps my list was not complete enough.

> I'd suggest keeping the gateway out of it for the first pass.

[Raymond]: May I ask why?=A0

> I've worked with Gateways\MCUs where the packet size had to be inc= reased
> because packet loading in the product became too high.=A0 Also, if you=
> have QOS features enabled in many routers, the routers themselves have=
> to start using a "software path", which creates a similar th= roughput
> problem in the routers.=A0 Too many packets per second can overwhelm t= hese
> devices, creating both capacity issues and excessive queuing delays. =A0
[Raymond]: OK, now I see what you meant when you said "it is tot= ally possible that reducing the frame size might actually increase the late= ncy". This is probably more likely to happen many years ago but less o= f a problem now, as I was told by networking guys that nowadays networking = gears can handle 5 ms packets without problems. =A0In fact, the VoIP gatewa= y I talked about, which has a 12 to 17 ms codec-dependent one-way delay for= a 5 ms frame/packet size, was done 6 or 7 years ago. =A0Even back then the= gateway can handle it without problems.

> I don't think the group has an agreed-upon model which names these=
> components consistently, and describes are appropriately in-scope and<= br> > which are out-of-scope.=A0 Perhaps that is one reason why Koen is sayi= ng
> multiplier the number is 1x.=A0

> Also, there are real-world negative consequences to higher packet rate= s,
> and we have not yet considered them.

[Raymond]: Yes, higher packet rates means higher packet header overhe= ad bit-rates, more burden on networking gears in I/O bandwidth and throughp= ut, etc. =A0However, that's the price to pay if we need low latency, ju= st like if we want to avoid all these, the price to pay is higher latency. = =A0It's all a matter of trade-off and the best choice depends on the ap= plication at hand.

In Section 2 of Jean-Marc's Internet Draft draft-ietf-codec-requirement= s-00, 6 specific applications for the IETF codec were listed. =A0Fully 5 of= these 6 applications list less than 10 ms of codec delay as either a requi= rement or a desirable feature. (The only exception is point-to-point calls.= ) =A0The only way to achieve this less than 10 ms codec delay is with a cod= ec frame size of less than 10 ms, and to get the kind of low latency that t= hese 5 applications desire, each packet had better contain only one codec f= rame as payload (rather than multiple frames).

So, yeah, there is negative consequences of the resulting higher packet rat= es, but hey, if we want to get low latency as desired or required by these = 5 applications, that's the price we will need to be prepared to pay. = =A0There is no free lunch. =A0If we want to use a 20 ms frame/packet size t= o avoid those consequences, then we need pay the price of not achieving the= low latency that these 5 applications desire or require.

Raymond


--0016e6d643ffd1cbbe0485f1b831-- From rchen@broadcom.com Thu May 6 18:41:05 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA96E3A68AD for ; Thu, 6 May 2010 18:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.26 X-Spam-Level: X-Spam-Status: No, score=-0.26 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwgdSfDto4hh for ; Thu, 6 May 2010 18:40:56 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 4A6D83A62C1 for ; Thu, 6 May 2010 18:40:56 -0700 (PDT) Received: from [10.9.200.133] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 06 May 2010 18:40:31 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Thu, 6 May 2010 18:41:54 -0700 From: "Raymond (Juin-Hwey) Chen" To: "stephen botzko" Date: Thu, 6 May 2010 18:40:19 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcrtUBWP0+WgmjltSLWgp3JWO0wGLwAMpvxw Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: DPLW DbHH FHvR HR2g H0uV IgfJ K4yW VAO4 WxFo YRm8 YS8r Zo8/ cY69 gQE6 gctD kWnF; 3; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAawBvAGUAbgAuAHYAbwBzAEAAcwBrAHkAcABlAC4AbgBlAHQAOwBzAHQAZQBwAGgAZQBuAC4AYgBvAHQAegBrAG8AQABnAG0AYQBpAGwALgBjAG8AbQA=; Sosha1_v1; 7; {702E8C36-3BA1-4F5A-9C0C-A893D8BF9FD7}; cgBjAGgAZQBuAEAAYgByAG8AYQBkAGMAbwBtAC4AYwBvAG0A; Fri, 07 May 2010 01:40:19 GMT; UgBFADoAIABbAGMAbwBkAGUAYwBdACAAIwAxADYAOgAgAE0AdQBsAHQAaQBjAGEAcwB0AD8A x-cr-puzzleid: {702E8C36-3BA1-4F5A-9C0C-A893D8BF9FD7} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67FDB00538O199213408-01-01 Content-Type: multipart/alternative; boundary=_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B90345A89IRVEXCHCCR01c_ Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 01:41:05 -0000 --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B90345A89IRVEXCHCCR01c_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Stephen, I agree with your points below. I had never said a 20 ms codec frame size s= hould not be used. I agree and had previously said that there are applicat= ions where that 20 ms frame size makes sense. All I have been arguing in t= he last couple of weeks was that there are also application scenarios where= a low-delay mode is needed, and there are applications where low codec com= plexity is desirable or even important. Even draft-ietf-codec-requirements-00 talks about a low-delay mode. Althou= gh the codec WG charter says that "it is not the goal of working group to p= roduce more than one codec", it does acknowledge that "based on the working= group's analysis of the design space, the working group might determine that it needs to produce more than one codec, or a co= dec with multiple modes". Thus, I believe that my proposal to have multipl= e coding modes in the IETF codec (to address the needs of low bit-rate, low= delay, or low complexity in different applications) is completely within t= he scope of the codec WG's charter. One more comment about the coding delay issue. When we compare VoIP with t= raditional circuit-switched PSTN telephony, VoIP is better in most aspects = except one: it has substantially longer one-way delay than PSTN telephony. = In this area of delay, PSTN still beats VoIP by far. As Moore's Law impro= ves technologies over time, the processing speed and communication speed im= proves with time, so the codec complexity and encoding bit-rate are going t= o be less and less of an issue as time goes. However, delay is one thing t= hat doesn't get improved with Moore's Law once a codec frame size is chosen= and fixed. Therefore, if we take a long-term view and attempt to make VoIP better than= or at least not significantly worse than PSTN in all aspects, then I belie= ve that we should address the VoIP's long-delay issue head-on with a low-de= lay mode in the IETF codec. Raymond From: stephen botzko [mailto:stephen.botzko@gmail.com] Sent: Thursday, May 06, 2010 12:12 PM To: Raymond (Juin-Hwey) Chen Cc: Koen Vos; codec@ietf.org Subject: Re: [codec] #16: Multicast? I basically agree with your points below. There are lots of tradeoffs in codec design, including this one. Personall= y I think there is value in a moderate delay 20 ms frame size, possibly aug= mented with a low-delay mode. 20 ms works quite well for video conferencin= g, since the video frame rate is no faster than 60 fps (about 15 ms per fra= me). Regards Stephen Botzko On Thu, May 6, 2010 at 3:03 PM, Raymond (Juin-Hwey) Chen > wrote: Hi Stephen, Sorry, I was too busy to respond yesterday. You wrote: > Generally the need to buffer the current frame is treated as part of the > algorithmic delay. At least I believe that is what the ITU-T does. > So maybe we need a list of what all these components are? [Raymond]: Sure, my previous analysis was an attempt to do just that, but p= erhaps my list was not complete enough. > I'd suggest keeping the gateway out of it for the first pass. [Raymond]: May I ask why? > I've worked with Gateways\MCUs where the packet size had to be increased > because packet loading in the product became too high. Also, if you > have QOS features enabled in many routers, the routers themselves have > to start using a "software path", which creates a similar throughput > problem in the routers. Too many packets per second can overwhelm these > devices, creating both capacity issues and excessive queuing delays. [Raymond]: OK, now I see what you meant when you said "it is totally possib= le that reducing the frame size might actually increase the latency". This = is probably more likely to happen many years ago but less of a problem now,= as I was told by networking guys that nowadays networking gears can handle= 5 ms packets without problems. In fact, the VoIP gateway I talked about, = which has a 12 to 17 ms codec-dependent one-way delay for a 5 ms frame/pack= et size, was done 6 or 7 years ago. Even back then the gateway can handle = it without problems. > I don't think the group has an agreed-upon model which names these > components consistently, and describes are appropriately in-scope and > which are out-of-scope. Perhaps that is one reason why Koen is saying > multiplier the number is 1x. > Also, there are real-world negative consequences to higher packet rates, > and we have not yet considered them. [Raymond]: Yes, higher packet rates means higher packet header overhead bit= -rates, more burden on networking gears in I/O bandwidth and throughput, et= c. However, that's the price to pay if we need low latency, just like if w= e want to avoid all these, the price to pay is higher latency. It's all a = matter of trade-off and the best choice depends on the application at hand. In Section 2 of Jean-Marc's Internet Draft draft-ietf-codec-requirements-00= , 6 specific applications for the IETF codec were listed. Fully 5 of these= 6 applications list less than 10 ms of codec delay as either a requirement= or a desirable feature. (The only exception is point-to-point calls.) The= only way to achieve this less than 10 ms codec delay is with a codec frame= size of less than 10 ms, and to get the kind of low latency that these 5 a= pplications desire, each packet had better contain only one codec frame as = payload (rather than multiple frames). So, yeah, there is negative consequences of the resulting higher packet rat= es, but hey, if we want to get low latency as desired or required by these = 5 applications, that's the price we will need to be prepared to pay. There= is no free lunch. If we want to use a 20 ms frame/packet size to avoid th= ose consequences, then we need pay the price of not achieving the low laten= cy that these 5 applications desire or require. Raymond --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B90345A89IRVEXCHCCR01c_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi Stephen,

 

I agree with your points below. I had never said a 20 ms codec = frame size should not be used.  I agree and had previously said that there a= re applications where that 20 ms frame size makes sense.  All I have been arguing in the last couple of weeks was that there are also application scenarios where a low-delay mode is needed, and there are applications wher= e low codec complexity is desirable or even important.

 

Even draft-ietf-codec-requirements-00 talks about a low-delay mode.  Although the codec WG charter says that “it is not the go= al of working group to produce more than one codec”, it does acknowledge that “based on the working group's analysis of the design space, the working

group might determine that it needs to produce more than one co= dec, or a codec with multiple modes”.  Thus, I believe that my propos= al to have multiple coding modes in the IETF codec (to address the needs of lo= w bit-rate, low delay, or low complexity in different applications) is comple= tely within the scope of the codec WG’s charter.

 

One more comment about the coding delay issue.  When we compare VoIP with traditional circuit-switched PSTN telephony, VoIP is bett= er in most aspects except one: it has substantially longer one-way delay than = PSTN telephony.  In this area of delay, PSTN still beats VoIP by far. = As Moore’s Law improves technologies over time, the processing speed and communication speed improves with time, so the codec complexity and encodin= g bit-rate are going to be less and less of an issue as time goes.  Howe= ver, delay is one thing that doesn’t get improved with Moore’s Law o= nce a codec frame size is chosen and fixed. 

 

Therefore, if we take a long-term view and attempt to make VoIP= better than or at least not significantly worse than PSTN in all aspects, then I believe that we should address the VoIP’s long-delay issue head-on wi= th a low-delay mode in the IETF codec.

 

Raymond

 

From: stephen botzk= o [mailto:stephen.botzko@gmail.com]
Sent: Thursday, May 06, 2010 12:12 PM
To: Raymond (Juin-Hwey) Chen
Cc: Koen Vos; codec@ietf.org
Subject: Re: [codec] #16: Multicast?

 

I basically agree with = your points below. 

There are lots of tradeoffs in codec design, including this one.  Personally I think there is value in a moderate delay 20 ms frame size, possibly augmented with a low-delay mode.  20 ms works quite well for video conferencing, since the video frame rate is no faster than 60 fps (ab= out 15 ms per frame).

Regards
Stephen Botzko




On Thu, May 6, 2010 at 3:03 PM, Raymond (Juin-Hwey) Ch= en <rchen@broadcom.com> wrote:=

Hi Stephen,

Sorry, I was too busy to respond yesterday.


You wrote:
> Generally the need to buffer the current frame is treated as part of t= he
> algorithmic delay.  At least I believe that is what the ITU-T doe= s.
> So maybe we need a list of what all these components are? 

[Raymond]: Sure, my previous analysis was an attempt t= o do just that, but perhaps my list was not complete enough.


> I'd suggest keeping the gateway out of it for the first pass.

[Raymond]: May I ask why? 


> I've worked with Gateways\MCUs where the packet size had to be increas= ed
> because packet loading in the product became too high.  Also, if = you
> have QOS features enabled in many routers, the routers themselves have=
> to start using a "software path", which creates a similar throughput
> problem in the routers.  Too many packets per second can overwhel= m these
> devices, creating both capacity issues and excessive queuing delays.  

[Raymond]: OK, now I see what you meant when you said "it is totally possible that reducing the frame size might actually increase the latency". This is probably more likely to happen many yea= rs ago but less of a problem now, as I was told by networking guys that nowada= ys networking gears can handle 5 ms packets without problems.  In fact, t= he VoIP gateway I talked about, which has a 12 to 17 ms codec-dependent one-wa= y delay for a 5 ms frame/packet size, was done 6 or 7 years ago.  Even b= ack then the gateway can handle it without problems.


> I don't think the group has an agreed-upon model which names these
> components consistently, and describes are appropriately in-scope and<= br> > which are out-of-scope.  Perhaps that is one reason why Koen is saying
> multiplier the number is 1x. 

> Also, there are real-world negative consequences to higher packet rate= s,
> and we have not yet considered them.

[Raymond]: Yes, higher = packet rates means higher packet header overhead bit-rates, more burden on network= ing gears in I/O bandwidth and throughput, etc.  However, that's the price= to pay if we need low latency, just like if we want to avoid all these, the pr= ice to pay is higher latency.  It's all a matter of trade-off and the best= choice depends on the application at hand.

In Section 2 of Jean-Marc's Internet Draft draft-ietf-codec-requirements-00= , 6 specific applications for the IETF codec were listed.  Fully 5 of thes= e 6 applications list less than 10 ms of codec delay as either a requirement or= a desirable feature. (The only exception is point-to-point calls.)  The = only way to achieve this less than 10 ms codec delay is with a codec frame size = of less than 10 ms, and to get the kind of low latency that these 5 applicatio= ns desire, each packet had better contain only one codec frame as payload (rat= her than multiple frames).

So, yeah, there is negative consequences of the resulting higher packet rat= es, but hey, if we want to get low latency as desired or required by these 5 applications, that's the price we will need to be prepared to pay.  Th= ere is no free lunch.  If we want to use a 20 ms frame/packet size to avoi= d those consequences, then we need pay the price of not achieving the low lat= ency that these 5 applications desire or require.

Raymond

 

--_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B90345A89IRVEXCHCCR01c_-- From koen.vos@skype.net Thu May 6 20:41:28 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C69BE3A68EE for ; Thu, 6 May 2010 20:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.361 X-Spam-Level: X-Spam-Status: No, score=-4.361 tagged_above=-999 required=5 tests=[AWL=-0.362, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afNuigtLXTuB for ; Thu, 6 May 2010 20:41:27 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 154653A67B2 for ; Thu, 6 May 2010 20:41:26 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 395AD60130C02; Fri, 7 May 2010 04:41:13 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=XSJMHDcH8GOQ QwTGyTdpQXRIPkk=; b=F8ct8dWWVovNQYKRW2Bq8TCcFrLrXxmuO/QJ2j7Fp/fJ VCKSdTk2H1L1l5Wjq4zBaGdVMsZ3odXstxL4nRMhHKJjZd2RAaHdmI3ZxmQUmm0M dJSlNxR9uC6FDvXA1AfRhVRbqy4NASzZ4Lny9FD7ZFo84x1F6ji8kT/EjcqQwEo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=wW4fgaXWB+LuJ1rZtgUy j1CQDL3wfB27skg9/7hYhE5FxIk6RSsOOMHpG8sXg4Wk0ICl7l5H5BUUjyRSXgbI Sg8JePaV567wC/xCSj4GiLJdhqzBpUpSn3m1J9KvOxyUht2B1bMtA6zgcU+3sOXT 0VPTC7ZO98wPnKm2gF4E3sI= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 3647E60130B8C; Fri, 7 May 2010 04:41:13 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u--Qg7wT9ARL; Fri, 7 May 2010 04:41:11 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id B800E60130B8D; Fri, 7 May 2010 04:41:11 +0100 (IST) Received: from adsl-71-141-115-202.dsl.snfc21.pacbell.net (adsl-71-141-115-202.dsl.snfc21.pacbell.net [71.141.115.202]) by mail.skype.net (Horde Framework) with HTTP; Thu, 06 May 2010 20:41:11 -0700 Message-ID: <20100506204111.16825idu95klhy3b@mail.skype.net> Date: Thu, 06 May 2010 20:41:11 -0700 From: Koen Vos To: "Raymond (Juin-Hwey) Chen" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 03:41:28 -0000 Hi Raymond, > I agree and had previously said that there are applications where > that 20 ms frame size makes sense. That's an interesting way to put it... 20 ms is in fact the norm. Anyway, I think we're all aligned here: ultra-low delay is important and has been part of the requirements from day one. Has anyone disagreed? Personally I'm convinced that people want super-wideband and probably even full-band audio before they want a < 20 ms codec, if they have the bitrate to support either. Yes, even for interactive voice. Audio bandwidth just has a bigger impact on user experience. The analysis we've done within our Skype network supports this conclusion. But maybe it's different with IP phones which apparently have problems with delay, dunno.. best, koen. Quoting "Raymond (Juin-Hwey) Chen" : > Hi Stephen, > > I agree with your points below. I had never said a 20 ms codec frame > size should not be used. I agree and had previously said that there > are applications where that 20 ms frame size makes sense. All I > have been arguing in the last couple of weeks was that there are > also application scenarios where a low-delay mode is needed, and > there are applications where low codec complexity is desirable or > even important. > > Even draft-ietf-codec-requirements-00 talks about a low-delay mode. > Although the codec WG charter says that "it is not the goal of > working group to produce more than one codec", it does acknowledge > that "based on the working group's analysis of the design space, the > working > group might determine that it needs to produce more than one codec, > or a codec with multiple modes". Thus, I believe that my proposal > to have multiple coding modes in the IETF codec (to address the > needs of low bit-rate, low delay, or low complexity in different > applications) is completely within the scope of the codec WG's > charter. > > One more comment about the coding delay issue. When we compare VoIP > with traditional circuit-switched PSTN telephony, VoIP is better in > most aspects except one: it has substantially longer one-way delay > than PSTN telephony. In this area of delay, PSTN still beats VoIP > by far. As Moore's Law improves technologies over time, the > processing speed and communication speed improves with time, so the > codec complexity and encoding bit-rate are going to be less and less > of an issue as time goes. However, delay is one thing that doesn't > get improved with Moore's Law once a codec frame size is chosen and > fixed. > > Therefore, if we take a long-term view and attempt to make VoIP > better than or at least not significantly worse than PSTN in all > aspects, then I believe that we should address the VoIP's long-delay > issue head-on with a low-delay mode in the IETF codec. > > Raymond > > From: stephen botzko [mailto:stephen.botzko@gmail.com] > Sent: Thursday, May 06, 2010 12:12 PM > To: Raymond (Juin-Hwey) Chen > Cc: Koen Vos; codec@ietf.org > Subject: Re: [codec] #16: Multicast? > > I basically agree with your points below. > > There are lots of tradeoffs in codec design, including this one. > Personally I think there is value in a moderate delay 20 ms frame > size, possibly augmented with a low-delay mode. 20 ms works quite > well for video conferencing, since the video frame rate is no faster > than 60 fps (about 15 ms per frame). > > Regards > Stephen Botzko > > > > > On Thu, May 6, 2010 at 3:03 PM, Raymond (Juin-Hwey) Chen > > wrote: > Hi Stephen, > > Sorry, I was too busy to respond yesterday. > > You wrote: >> Generally the need to buffer the current frame is treated as part of the >> algorithmic delay. At least I believe that is what the ITU-T does. >> So maybe we need a list of what all these components are? > [Raymond]: Sure, my previous analysis was an attempt to do just > that, but perhaps my list was not complete enough. > >> I'd suggest keeping the gateway out of it for the first pass. > [Raymond]: May I ask why? > >> I've worked with Gateways\MCUs where the packet size had to be increased >> because packet loading in the product became too high. Also, if you >> have QOS features enabled in many routers, the routers themselves have >> to start using a "software path", which creates a similar throughput >> problem in the routers. Too many packets per second can overwhelm these >> devices, creating both capacity issues and excessive queuing delays. > > [Raymond]: OK, now I see what you meant when you said "it is totally > possible that reducing the frame size might actually increase the > latency". This is probably more likely to happen many years ago but > less of a problem now, as I was told by networking guys that > nowadays networking gears can handle 5 ms packets without problems. > In fact, the VoIP gateway I talked about, which has a 12 to 17 ms > codec-dependent one-way delay for a 5 ms frame/packet size, was done > 6 or 7 years ago. Even back then the gateway can handle it without > problems. > >> I don't think the group has an agreed-upon model which names these >> components consistently, and describes are appropriately in-scope and >> which are out-of-scope. Perhaps that is one reason why Koen is saying >> multiplier the number is 1x. > >> Also, there are real-world negative consequences to higher packet rates, >> and we have not yet considered them. > [Raymond]: Yes, higher packet rates means higher packet header > overhead bit-rates, more burden on networking gears in I/O bandwidth > and throughput, etc. However, that's the price to pay if we need > low latency, just like if we want to avoid all these, the price to > pay is higher latency. It's all a matter of trade-off and the best > choice depends on the application at hand. > > In Section 2 of Jean-Marc's Internet Draft > draft-ietf-codec-requirements-00, 6 specific applications for the > IETF codec were listed. Fully 5 of these 6 applications list less > than 10 ms of codec delay as either a requirement or a desirable > feature. (The only exception is point-to-point calls.) The only way > to achieve this less than 10 ms codec delay is with a codec frame > size of less than 10 ms, and to get the kind of low latency that > these 5 applications desire, each packet had better contain only one > codec frame as payload (rather than multiple frames). > > So, yeah, there is negative consequences of the resulting higher > packet rates, but hey, if we want to get low latency as desired or > required by these 5 applications, that's the price we will need to > be prepared to pay. There is no free lunch. If we want to use a 20 > ms frame/packet size to avoid those consequences, then we need pay > the price of not achieving the low latency that these 5 applications > desire or require. > > Raymond > > From hoene@uni-tuebingen.de Fri May 7 05:32:11 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32DD33A69F0 for ; Fri, 7 May 2010 05:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.879 X-Spam-Level: X-Spam-Status: No, score=-3.879 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kpp3SHNWR1em for ; Fri, 7 May 2010 05:32:09 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id DF3103A683C for ; Fri, 7 May 2010 05:32:07 -0700 (PDT) Received: from hoeneT60 ([178.2.215.148]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o47CVisD006995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 May 2010 14:31:50 +0200 From: "Christian Hoene" To: "'Raymond \(Juin-Hwey\) Chen'" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> In-Reply-To: Date: Fri, 7 May 2010 14:31:42 +0200 Message-ID: <009901caede1$43f366d0$cbda3470$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrimhyNUh3NLsf5RvSfcmuOhmvRfwBUwYUAAVLFoDAApwRsUACBX9Bg Content-Language: de X-AntiVirus-Spam-Check: failed (checked by Avira MailGate: version: 3.0.0-4; spam filter version: unknown; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.236; VDF: 7.10.7.64; host: mx05); id=30568-DyPR2Z Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 12:32:11 -0000 Hello Raymond, thank you for your insights into high-density VoIP gateways. I have been = told that similar statement are valid also for other gateway manufactures and that the design of high-density gateways is = much more demanding than of softphones: Because data and code memory is limited and code cannot be loaded on demand, costs are already = high, power consumption is a problem, execution is highly paralleled, etc... Thus, it makes sense to have a codec (profile) = optimized for this use case.=20 What are those specific codec requirements, then? - narrow-band? - 5ms or 10ms frame size? - low complexity - low memory footprint - transcoding robust ... And, are these requirements unique or are they covered by existing = codecs like G.711 and G.729 already? Is it likely that gateways, which operate already on their limits, can support yet another codec? With best regards, Christian Hoene --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ >-----Original Message----- >From: Raymond (Juin-Hwey) Chen [mailto:rchen@broadcom.com] >Sent: Wednesday, May 05, 2010 1:01 AM >To: Christian Hoene >Cc: codec@ietf.org >Subject: RE: [codec] #16: Multicast? > >Hi Christian, > >Sorry for the delay of my response. I was busy with other things and = not available to respond to IETF >emails until now. > >You wrote: >> The arguments on costs of the gateways is raised often. Thus, it is = worthwhile to >> consider in-depth. > >> May I ask you for more information about the design of VoIP Gateways. = Particular, I am > interested >in the partition between audio >> processing and protocol stack on DSP and CPU. > >> Does DSP take over all codec processing? May the CPU do some parts of = the computation > before, >during or after DSP does the signal >> processing? > >[Raymond]: I asked an engineering manager who was deeply involved in = the design of high-density VoIP >gateways. He said that in such gateways, due to the high number of = voice channels (thousands) per box, >a large number of DSPs and micro-controllers are used, and they are = usually structured in a >hierarchical way. The DSPs typically take care of all speech codec = processing, echo cancellation, >DMTF tone detection, and fax, etc. The DSPs are usually divided into = groups, with each groups of DSPs >controlled by a single micro-controller, which handles things like RTP, = jitter buffering, >packetization, QoS statistics, and moving the voice traffic to and from = the DSPs in the group. Then, >on top of that there may be higher-performance controllers, each = connected to many such groups of >micro-controller + DSPs. These higher-performance controllers may = handle things like call setup, >UDP/IP/RTP, routing to and from internal processor groups, and routing = to and from external >networks/devices. > >> How do you count number of channels? Do all voice channels have the = same weight >> regardless their sampling rate? >> Say suppose, if the mixing is done for 48kHz instead of 8kHz, how = many resource are we >> allowed to consume more? > >[Raymond]: I am not sure what you meant. The channel count is just = counting the actual physical voice >channels that the gateway can handle simultaneously; it is not a = weighted sum. Are you thinking that a >48 kHz channel should be counted more than an 8 kHz channel because it = requires more computational >resources? Typical VoIP gateways only support 8 kHz telephone-bandwidth = speech, so 48 kHz is out of >the picture. >With that said, the complexity difference between speech codecs can = make a big difference in the >channel density. Let's say a VoIP gateway supports X simultaneous = voice channels running the G.711 >codec. Since the complexity of G.711 PCM is next to nothing, the = complexity of each voice channel is >dominated by the echo canceller (EC). Now if you replace the G.711 = codec by the G.729A codec which >takes about 10 MIPS of computational complexity for a full-duplex = codec, that can easily decrease the >channel density to X/2.5 per gateway, depending on the EC and other = things. If you replace the G.711 >codec by the G.728 codec that takes 30+ MIPS, the channel density can = easily go down to X/4 ~ X/5 or >worse. >Thus, if you choose a high-complexity codec, you would need to buy a = lot more VoIP gateways to support >the same number of voice channels than if you use a low-complexity = codec. The cost difference is very >real and can be very big. > >Raymond > From gmaxwell@juniper.net Fri May 7 11:33:08 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261F43A67FA for ; Fri, 7 May 2010 11:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qN2AREpS5Ztw for ; Fri, 7 May 2010 11:33:07 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 3207C3A67EF for ; Fri, 7 May 2010 11:33:07 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKS+Rc0C56liAp77aDRmIQFD+lpoX6ekuC@postini.com; Fri, 07 May 2010 11:32:55 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Fri, 7 May 2010 11:31:19 -0700 From: Gregory Maxwell To: Christian Hoene Date: Fri, 7 May 2010 11:31:19 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcrimhyNUh3NLsf5RvSfcmuOhmvRfwBUwYUAAVLFoDAApwRsUACBX9BgAA3Nn9w= Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> In-Reply-To: <009901caede1$43f366d0$cbda3470$@de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 18:33:08 -0000 Christian Hoene [hoene@uni-tuebingen.de] wrote: [snip] > And, are these requirements unique or are they covered by existing > codecs like G.711 and G.729 already? Is it likely that gateways, > which operate already on their limits, can support yet another codec? I think this is an essential question. =20 There are a number of excellent pre-existing codecs out there=97 during the formation of this working group we concluded that there was a=20 significant non-addressed application space which a new codec=20 could satisfy, but I've seen a number of requirements raised here which may be specific to applications for which existing codecs are already well suited. =20 In particular while computational burden is an essential concern, I don't think it is reasonable to subject a full-band / super-band / wideband codec to the same criteria which would be reasonable for a narrow band codec. If your gateway can't scale to acceptable size except with very computationally cheap codecs, then you probably ought to be using one of the already established narrow-band codecs. I don't think it's a good idea to design for very high levels of complexity but we ought to keep in mind that the working group is already targeted at something high quality (and thus more complex) than narrow=20 band. Together with the normal "moore's law" progress in transistor density, I think these factors may suggest a slight bias towards additional computational complexity at least where the increase in complexity can be effectively used. From rchen@broadcom.com Fri May 7 13:12:35 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 147803A694A for ; Fri, 7 May 2010 13:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.164 X-Spam-Level: X-Spam-Status: No, score=-0.164 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nU8uiZGJQr6z for ; Fri, 7 May 2010 13:12:32 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 85A153A6853 for ; Fri, 7 May 2010 13:12:29 -0700 (PDT) Received: from [10.9.200.133] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 07 May 2010 13:11:59 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Fri, 7 May 2010 13:13:22 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Christian Hoene" Date: Fri, 7 May 2010 13:11:58 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcrimhyNUh3NLsf5RvSfcmuOhmvRfwBUwYUAAVLFoDAApwRsUACBX9BgABAsmGA= Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> <009901caede1$43f366d0$cbda3470$@de> In-Reply-To: <009901caede1$43f366d0$cbda3470$@de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67FAAB8538O200290143-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 20:12:35 -0000 Hi Christian, > What are those specific codec requirements, then? > - narrow-band? > - 5ms or 10ms frame size? > - low complexity > - low memory footprint > - transcoding robust ... [Raymond]:=20 - For the foreseeable future, I think most of the VoIP gateway voice channels will still be narrowband. We may start to see some wideband (16 kHz sampling). - There are different VoIP gateway customers. Some just want the lowest possible cost of deployment and don't care too=20 much about call quality or latency; they will probably=20 use 20 ms packets. However, some want to compete seriously=20 with the PSTN telephony offered by incumbent telcos.=20 There they have to have good quality and low latency since PSTN latency is very low. These customers will want to=20 use 10 ms packets or even 5 ms packets if their hardware can=20 handle it. - Yes, relatively low complexity and low memory footprint are both importan= t for VoIP gateway implementation of codecs. - Good transcoding performance is also a plus, although=20 generally if a codec's single encoding performance is already=20 high, then it transcoding performance is usually good as well. > And, are these requirements unique or are they covered by=20 > existing codecs like G.711 and G.729 already? Is it likely=20 > that gateways, which operate already on their limits, can=20 > support yet another codec? [Raymond]: - G.729 has a 10 ms frame size, but its complexity is around=20 20 MIPS or so. G.729A can be optimized to around 10 MIPS, so=20 it's better for gateways, but G.729A voice quality is somewhat=20 lower than G.729. The biggest issue with G.729 and G.729A,=20 though, is that they are royalty-bearing. G.711 has good=20 quality, low delay, low complexity, and is royalty-free. =20 However, at 8 bits/sample, G.711 is inefficient with the bit- rate. A 16 kb/s codec will reduce the payload bit-rate by a=20 factor of 4 and reduce the overall bit-rate (including packet=20 header, without header compression) by a factor of about 2X=20 and 1.6X for 10 ms and 5 ms packets, respectively, which are=20 still significant saving in transmission bandwidth and I/O=20 bandwidth/throughput. - Supporting yet another codec is not a problem for gateways=20 because it just means a little additional storage of the codec=20 program and data tables in ROM, which is cheap. The gateways=20 are already at or near their limits in terms of MIPS, RAM, and=20 I/O bandwidth, not in terms of ROM. More importantly, you=20 don't run the additional codec as additional voice channels;=20 you simply replace some of the existing codecs already=20 supported by the gateway in some (or all) of the channels.=20 Therefore, as long as the new codec added does not require=20 significantly more MHz or RAM than the existing supported=20 codecs, it shouldn't be an issue. From koen.vos@skype.net Fri May 7 14:08:13 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DF1E3A6A1A for ; Fri, 7 May 2010 14:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.335 X-Spam-Level: X-Spam-Status: No, score=-4.335 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BFY1hav9e46 for ; Fri, 7 May 2010 14:08:11 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 0922B3A6A12 for ; Fri, 7 May 2010 14:08:10 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id E7567601369D5; Fri, 7 May 2010 22:07:57 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=0bKjp4utCerw /+tt20anEL6qmlU=; b=jHQnAlL6lmdiMyucnqJXzt4Vp43j/xk5ndKiIP+h+6WN 9HL087bIbj8vvR8d49pmQIpGRTOscrOuYqLtZ1nJpNKpbIhzULYgPXl4yoRZc9t/ 0qVKEa4dMbjRKqBn8dpGVLmx1UD06A6HlzTAD+5Ku8sFwDkQmcDiFq3Oc9LiS4k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=VyrlVKrYsEifQ4Jc/t8V 3TBgKjIfwL2mR+pjVPQKra0JGhJjCnwaMSKQqcNGYsHxj7BVe18wxdNdycvFPJOs Dj1AOnL4TykTjV01rmQ3MFIDCXqJfcml/Ur2syMnh1cCechz/5Ss27J0HBujepuu DZz0Es/KNEpg5thTA+xQ6WE= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id E5318601369D4; Fri, 7 May 2010 22:07:57 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJfxAfzHzmkI; Fri, 7 May 2010 22:07:57 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id 03514601369D3; Fri, 7 May 2010 22:07:57 +0100 (IST) Received: from adsl-71-141-115-202.dsl.snfc21.pacbell.net (adsl-71-141-115-202.dsl.snfc21.pacbell.net [71.141.115.202]) by mail.skype.net (Horde Framework) with HTTP; Fri, 07 May 2010 14:07:56 -0700 Message-ID: <20100507140756.83037heeq3wiapf0@mail.skype.net> Date: Fri, 07 May 2010 14:07:56 -0700 From: Koen Vos To: "Raymond (Juin-Hwey) Chen" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 21:08:13 -0000 Hi Raymond, > However, delay is one thing that doesn't get improved with Moore's > Law once a codec frame size is chosen and fixed. You've said this before, and it's not true. Moore's law has reduced the delay that users experience a lot: 1. Faster networks reduce transmission delays. In Skype we've seen the average network roundtrip time during a call gradually go down from well over 500 ms in 2005 to below 300 ms today. Skype calls now have lower delay than mobile phone calls. 2. Faster CPUs enable tighter scheduling of audio I/O. As a result, the buffering delay in the OS/driver has gone done over the years. 3. Faster CPUs mean less processing time delay. For example, SILK in superwideband mode takes less than 10% of real-time on an iPhone. best, koen. Quoting "Raymond (Juin-Hwey) Chen" : > Hi Stephen, > > I agree with your points below. I had never said a 20 ms codec frame > size should not be used. I agree and had previously said that there > are applications where that 20 ms frame size makes sense. All I > have been arguing in the last couple of weeks was that there are > also application scenarios where a low-delay mode is needed, and > there are applications where low codec complexity is desirable or > even important. > > Even draft-ietf-codec-requirements-00 talks about a low-delay mode. > Although the codec WG charter says that "it is not the goal of > working group to produce more than one codec", it does acknowledge > that "based on the working group's analysis of the design space, the > working > group might determine that it needs to produce more than one codec, > or a codec with multiple modes". Thus, I believe that my proposal > to have multiple coding modes in the IETF codec (to address the > needs of low bit-rate, low delay, or low complexity in different > applications) is completely within the scope of the codec WG's > charter. > > One more comment about the coding delay issue. When we compare VoIP > with traditional circuit-switched PSTN telephony, VoIP is better in > most aspects except one: it has substantially longer one-way delay > than PSTN telephony. In this area of delay, PSTN still beats VoIP > by far. As Moore's Law improves technologies over time, the > processing speed and communication speed improves with time, so the > codec complexity and encoding bit-rate are going to be less and less > of an issue as time goes. However, delay is one thing that doesn't > get improved with Moore's Law once a codec frame size is chosen and > fixed. > > Therefore, if we take a long-term view and attempt to make VoIP > better than or at least not significantly worse than PSTN in all > aspects, then I believe that we should address the VoIP's long-delay > issue head-on with a low-delay mode in the IETF codec. > > Raymond > > From: stephen botzko [mailto:stephen.botzko@gmail.com] > Sent: Thursday, May 06, 2010 12:12 PM > To: Raymond (Juin-Hwey) Chen > Cc: Koen Vos; codec@ietf.org > Subject: Re: [codec] #16: Multicast? > > I basically agree with your points below. > > There are lots of tradeoffs in codec design, including this one. > Personally I think there is value in a moderate delay 20 ms frame > size, possibly augmented with a low-delay mode. 20 ms works quite > well for video conferencing, since the video frame rate is no faster > than 60 fps (about 15 ms per frame). > > Regards > Stephen Botzko > > > > > On Thu, May 6, 2010 at 3:03 PM, Raymond (Juin-Hwey) Chen > > wrote: > Hi Stephen, > > Sorry, I was too busy to respond yesterday. > > You wrote: >> Generally the need to buffer the current frame is treated as part of the >> algorithmic delay. At least I believe that is what the ITU-T does. >> So maybe we need a list of what all these components are? > [Raymond]: Sure, my previous analysis was an attempt to do just > that, but perhaps my list was not complete enough. > >> I'd suggest keeping the gateway out of it for the first pass. > [Raymond]: May I ask why? > >> I've worked with Gateways\MCUs where the packet size had to be increased >> because packet loading in the product became too high. Also, if you >> have QOS features enabled in many routers, the routers themselves have >> to start using a "software path", which creates a similar throughput >> problem in the routers. Too many packets per second can overwhelm these >> devices, creating both capacity issues and excessive queuing delays. > > [Raymond]: OK, now I see what you meant when you said "it is totally > possible that reducing the frame size might actually increase the > latency". This is probably more likely to happen many years ago but > less of a problem now, as I was told by networking guys that > nowadays networking gears can handle 5 ms packets without problems. > In fact, the VoIP gateway I talked about, which has a 12 to 17 ms > codec-dependent one-way delay for a 5 ms frame/packet size, was done > 6 or 7 years ago. Even back then the gateway can handle it without > problems. > >> I don't think the group has an agreed-upon model which names these >> components consistently, and describes are appropriately in-scope and >> which are out-of-scope. Perhaps that is one reason why Koen is saying >> multiplier the number is 1x. > >> Also, there are real-world negative consequences to higher packet rates, >> and we have not yet considered them. > [Raymond]: Yes, higher packet rates means higher packet header > overhead bit-rates, more burden on networking gears in I/O bandwidth > and throughput, etc. However, that's the price to pay if we need > low latency, just like if we want to avoid all these, the price to > pay is higher latency. It's all a matter of trade-off and the best > choice depends on the application at hand. > > In Section 2 of Jean-Marc's Internet Draft > draft-ietf-codec-requirements-00, 6 specific applications for the > IETF codec were listed. Fully 5 of these 6 applications list less > than 10 ms of codec delay as either a requirement or a desirable > feature. (The only exception is point-to-point calls.) The only way > to achieve this less than 10 ms codec delay is with a codec frame > size of less than 10 ms, and to get the kind of low latency that > these 5 applications desire, each packet had better contain only one > codec frame as payload (rather than multiple frames). > > So, yeah, there is negative consequences of the resulting higher > packet rates, but hey, if we want to get low latency as desired or > required by these 5 applications, that's the price we will need to > be prepared to pay. There is no free lunch. If we want to use a 20 > ms frame/packet size to avoid those consequences, then we need pay > the price of not achieving the low latency that these 5 applications > desire or require. > > Raymond > > From rchen@broadcom.com Fri May 7 14:29:18 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91CBA3A67EA for ; Fri, 7 May 2010 14:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_50=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySXWPsliehju for ; Fri, 7 May 2010 14:29:17 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 44F323A6980 for ; Fri, 7 May 2010 14:29:16 -0700 (PDT) Received: from [10.9.200.131] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 07 May 2010 14:28:48 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Fri, 7 May 2010 14:28:49 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Gregory Maxwell" , "Christian Hoene" Date: Fri, 7 May 2010 14:28:47 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcrimhyNUh3NLsf5RvSfcmuOhmvRfwBUwYUAAVLFoDAApwRsUACBX9BgAA3Nn9wABCPpQA== Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67FA599A20S117777147-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 21:29:18 -0000 Hi Gregory, > There are a number of excellent pre-existing codecs out there- during > the formation of this working group we concluded that there was a=20 > significant non-addressed application space which a new codec=20 > could satisfy, but I've seen a number of requirements raised here > which may be specific to applications for which existing codecs are > already well suited. =20 [Raymond]: I am not sure which codecs satisfy the three conditions=20 listed in the codec WG charter. Would you please share which=20 codecs you have in mind? Thanks. > In particular while computational burden is an essential concern, I don't > think it is reasonable to subject a full-band / super-band / wideband > codec to the same criteria which would be reasonable for a narrow band > codec. [Raymond]: Agreed. I never propose that we should subject full- /super-/wide-band codecs to the same complexity constraints as for=20 narrowband codecs. What I am proposing, though, is that for a=20 particular sampling-rate, be it 16, 32, 44.1, or 48 kHz, when we=20 consider different codec options, we should not ignore the codec=20 complexity, because high codec complexity have negative consequences=20 in low-end devices and gateways.=20 My other point is that although the WG does want a wideband/super- wideband/full-band audio codec, we shouldn't completely ignore=20 narrowband, because that's still how most of the point-to-point=20 voice calls and multi-party voice conferencing (the first two of the=20 six applications listed in the charter) are conducted today and in=20 the foreseeable future. Just North American cable operators alone=20 have tens of millions of VoIP telephony subscribers. If you add=20 other countries, telcos, independent VoIP operators like Vonage, and=20 enterprise IP phone users, although I don't have the stats, I=20 wouldn't be surprised if the total VoIP users worldwide exceed 100M,=20 probably significantly. Most of these are still narrowband. =20 Therefore, it makes the most sense for the IETF codec to be able to=20 also address narrowband speech coding so it has a chance to be used=20 by these VoIP users. If a call goes through the IETF codec and=20 reaches out to a conventional phone through a VoIP gateway, then it=20 is better if the call doesn't have to be transcoded to another=20 medium- or low-bit-rate codec so the additional codec distortion and=20 coding delay can be avoided. This is where the recent discussion of=20 VoIP gateways come in. > I don't think it's a good idea to design for very high levels of complexi= ty > but we ought to keep in mind that the working group is already targeted > at something high quality (and thus more complex) than narrow=20 > band. Together with the normal "moore's law" progress in transistor > density, I think these factors may suggest a slight bias towards > additional computational complexity at least where the increase in > complexity can be effectively used. [Raymond]: I completely agree with you that we should allow=20 additional complexity (compared with narrowband) to enable higher- bandwidth, higher-quality audio. On the other hand, if we are=20 evaluating, say, two wideband (16 kHz) codecs, where one requires 50=20 MHz on a DSP while the other requires 20 MHz, then such a=20 substantial difference in computational complexity should be taken=20 into account when considering all other aspects of the codecs. _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From koen.vos@skype.net Fri May 7 14:49:10 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64E553A6897 for ; Fri, 7 May 2010 14:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.613 X-Spam-Level: X-Spam-Status: No, score=-5.613 tagged_above=-999 required=5 tests=[AWL=0.986, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRzLhwUwxAUb for ; Fri, 7 May 2010 14:49:09 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 60ACF3A67B3 for ; Fri, 7 May 2010 14:49:09 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id C8D9060136B11; Fri, 7 May 2010 22:48:56 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=E4g2wvR1gFr6 IMM9K9nwaVGggd8=; b=FkSo5kVWxc/OjPBnfz88Eo9grlkp1DonhiQp5UxQt0HM 4o54z2uYHt+qhQnrlVmbrhd3x841NFwSFhMXjIBOzFdQiAe1O1BoB3W0eKsl6FnL NFpSWWgIUBQvMu8mGmKvKJ1LkA2S79aZGRVwrTsI56XgSMWkzOxbexK90q61QZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=MGQM0OjVSrl1f/Os91qB +y7B5MJY9z9mYUs+ZlILvLUJb75JZrus2VlnyyJDnpeCzzKiSTcQaHou8gkPtmjc 6woNXrVokapmSw27V+5hI7W1VTv7MWL2SYU0HWLS3avFLH/iht8yVVCx8901HeXg bowtuCyhFSgFoItCKsWd6S0= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id C6F8C60136B0F; Fri, 7 May 2010 22:48:56 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kct4zQf3Fa3L; Fri, 7 May 2010 22:48:56 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id 29B5D60136B10; Fri, 7 May 2010 22:48:56 +0100 (IST) Received: from adsl-71-141-115-202.dsl.snfc21.pacbell.net (adsl-71-141-115-202.dsl.snfc21.pacbell.net [71.141.115.202]) by mail.skype.net (Horde Framework) with HTTP; Fri, 07 May 2010 14:48:56 -0700 Message-ID: <20100507144856.171013mxhy3wdfbc@mail.skype.net> Date: Fri, 07 May 2010 14:48:56 -0700 From: Koen Vos To: "Raymond (Juin-Hwey) Chen" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 21:49:10 -0000 Quoting "Raymond (Juin-Hwey) Chen": > I wouldn't be surprised if the total VoIP users worldwide exceed 100M, > probably significantly. Correct, Skype alone has > 100M active users... > Most of these are still narrowband. No: super-wideband. Are IP phones that come on the market today still using only narrowband? That must be a quickly reducing segment, no? I do agree that "we shouldn't completely ignore narrowband." koen. From rchen@broadcom.com Fri May 7 17:34:04 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03E7D3A68CE for ; Fri, 7 May 2010 17:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.145 X-Spam-Level: X-Spam-Status: No, score=-0.145 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJTqL7mdHypJ for ; Fri, 7 May 2010 17:34:02 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 783583A68B7 for ; Fri, 7 May 2010 17:34:02 -0700 (PDT) Received: from [10.9.200.133] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 07 May 2010 17:33:30 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Fri, 7 May 2010 17:34:53 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Koen Vos" Date: Fri, 7 May 2010 17:33:25 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcruKWa39922CLfSSjmBR/Jq0XOlkAAE205A Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <20100507140756.83037heeq3wiapf0@mail.skype.net> In-Reply-To: <20100507140756.83037heeq3wiapf0@mail.skype.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Bvww C3LY FHB7 F6rh F8ir GeOg IDWU LCt/ MPpY N9jQ On4g PeDw QUBn RJpv ULOO VU/Z; 2; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAawBvAGUAbgAuAHYAbwBzAEAAcwBrAHkAcABlAC4AbgBlAHQA; Sosha1_v1; 7; {2CF06BC7-1070-45CA-8200-5225E8CD4F18}; cgBjAGgAZQBuAEAAYgByAG8AYQBkAGMAbwBtAC4AYwBvAG0A; Sat, 08 May 2010 00:33:25 GMT; UgBFADoAIABbAGMAbwBkAGUAYwBdACAAIwAxADYAOgAgAE0AdQBsAHQAaQBjAGEAcwB0AD8A x-cr-puzzleid: {2CF06BC7-1070-45CA-8200-5225E8CD4F18} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67FA6ED020S117895762-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2010 00:34:04 -0000 Hi Koen, Ah, sorry, I should have been more specific and said that the codec bufferi= ng delay (frame size + look-ahead) does not get improved with Moore's Law. = Before my original sentence that you quoted below, I wrote "As Moore's Law= improves technologies over time, the processing speed and communication sp= eed improves with time,..." From that context, it should be clear that wit= h increased processing speed and communication speed, the time spent on pro= cessing and transmitting a codec frame would decrease with time. However, your previous argument that the frame size multiplier is closer to= 1X than 2X already assumes that the processing delay and transmission dela= y are essentially negligible (at least for computer IP phone calls accordin= g to you). Therefore, you are not going to get much more help from Moore's= Law for these two already small delay components.=20 On the other hand, devices like VoIP gateways are already using very fast p= rocessors and connected to very fast networks, and yet the codec-dependent = one-way delay are still around 3X codec frame size because of complicated t= iming issues and processor buffering needs due to the large number of voice= channels competing for resources. As Moore's Law makes the processor even= faster, chances are each processor will handle even more voice channels, s= o although the time spent on processing each codec frame size will decrease= (it is already fairly small), the scheduling/timing issue and the associat= ed buffering needs probably will get even worse, so I am not convinced that= the net result is that the codec-dependent delay will get much smaller tha= n 3X codec frame size in the future. In the email below, you said the average network roundtrip time is below 30= 0 ms. You didn't say below 250 ms or below 200 ms, so I assume that it is j= ust below 300 ms, which means that the one-way network delay is just below = 150 ms. Is that correct? Doesn't this totally depends on what packet size = (or packet rate) you use and how much jitter buffer delay you allow? =20 When I used some websites to test the Internet connection between my work l= ocation in Orange County, California to Los Angeles, I routinely get as low= as 2 or 3 ms delay. Such a low network delay for close-by cities is what m= akes the live music performance over the Internet (the sixth application id= entified in the codec WG charter) possible, right? If all Internet connect= ions has close to 150 ms delay one-way, we might as well forget about all t= hose applications that list low delay as required or highly desirable (whic= h leaves only point-to-point calls as the only application). BTW, I thought you once told me the one-way delay of a Skype call is about = 200 ms (which probably makes sense if your one-way network delay is just be= low 150 ms). If so, I am confused by your comment below that "Skype calls = now have lower delay than mobile phone calls", since mobile phone calls typ= ically have one-way delays of 80 to 110 ms. Would you please explain this = apparent contradiction? Thanks. Best Regards, Raymond -----Original Message----- From: Koen Vos [mailto:koen.vos@skype.net]=20 Sent: Friday, May 07, 2010 2:08 PM To: Raymond (Juin-Hwey) Chen Cc: codec@ietf.org Subject: RE: [codec] #16: Multicast? Hi Raymond, > However, delay is one thing that doesn't get improved with Moore's =20 > Law once a codec frame size is chosen and fixed. You've said this before, and it's not true. Moore's law has reduced =20 the delay that users experience a lot: 1. Faster networks reduce transmission delays. In Skype we've seen =20 the average network roundtrip time during a call gradually go down =20 from well over 500 ms in 2005 to below 300 ms today. Skype calls now =20 have lower delay than mobile phone calls. 2. Faster CPUs enable tighter scheduling of audio I/O. As a result, =20 the buffering delay in the OS/driver has gone done over the years. 3. Faster CPUs mean less processing time delay. For example, SILK in =20 superwideband mode takes less than 10% of real-time on an iPhone. best, koen. Quoting "Raymond (Juin-Hwey) Chen" : > Hi Stephen, > > I agree with your points below. I had never said a 20 ms codec frame =20 > size should not be used. I agree and had previously said that there =20 > are applications where that 20 ms frame size makes sense. All I =20 > have been arguing in the last couple of weeks was that there are =20 > also application scenarios where a low-delay mode is needed, and =20 > there are applications where low codec complexity is desirable or =20 > even important. > > Even draft-ietf-codec-requirements-00 talks about a low-delay mode. =20 > Although the codec WG charter says that "it is not the goal of =20 > working group to produce more than one codec", it does acknowledge =20 > that "based on the working group's analysis of the design space, the =20 > working > group might determine that it needs to produce more than one codec, =20 > or a codec with multiple modes". Thus, I believe that my proposal =20 > to have multiple coding modes in the IETF codec (to address the =20 > needs of low bit-rate, low delay, or low complexity in different =20 > applications) is completely within the scope of the codec WG's =20 > charter. > > One more comment about the coding delay issue. When we compare VoIP =20 > with traditional circuit-switched PSTN telephony, VoIP is better in =20 > most aspects except one: it has substantially longer one-way delay =20 > than PSTN telephony. In this area of delay, PSTN still beats VoIP =20 > by far. As Moore's Law improves technologies over time, the =20 > processing speed and communication speed improves with time, so the =20 > codec complexity and encoding bit-rate are going to be less and less =20 > of an issue as time goes. However, delay is one thing that doesn't =20 > get improved with Moore's Law once a codec frame size is chosen and =20 > fixed. > > Therefore, if we take a long-term view and attempt to make VoIP =20 > better than or at least not significantly worse than PSTN in all =20 > aspects, then I believe that we should address the VoIP's long-delay =20 > issue head-on with a low-delay mode in the IETF codec. > > Raymond > > From: stephen botzko [mailto:stephen.botzko@gmail.com] > Sent: Thursday, May 06, 2010 12:12 PM > To: Raymond (Juin-Hwey) Chen > Cc: Koen Vos; codec@ietf.org > Subject: Re: [codec] #16: Multicast? > > I basically agree with your points below. > > There are lots of tradeoffs in codec design, including this one. =20 > Personally I think there is value in a moderate delay 20 ms frame =20 > size, possibly augmented with a low-delay mode. 20 ms works quite =20 > well for video conferencing, since the video frame rate is no faster =20 > than 60 fps (about 15 ms per frame). > > Regards > Stephen Botzko > > > > > On Thu, May 6, 2010 at 3:03 PM, Raymond (Juin-Hwey) Chen =20 > > wrote: > Hi Stephen, > > Sorry, I was too busy to respond yesterday. > > You wrote: >> Generally the need to buffer the current frame is treated as part of the >> algorithmic delay. At least I believe that is what the ITU-T does. >> So maybe we need a list of what all these components are? > [Raymond]: Sure, my previous analysis was an attempt to do just =20 > that, but perhaps my list was not complete enough. > >> I'd suggest keeping the gateway out of it for the first pass. > [Raymond]: May I ask why? > >> I've worked with Gateways\MCUs where the packet size had to be increased >> because packet loading in the product became too high. Also, if you >> have QOS features enabled in many routers, the routers themselves have >> to start using a "software path", which creates a similar throughput >> problem in the routers. Too many packets per second can overwhelm these >> devices, creating both capacity issues and excessive queuing delays. > > [Raymond]: OK, now I see what you meant when you said "it is totally =20 > possible that reducing the frame size might actually increase the =20 > latency". This is probably more likely to happen many years ago but =20 > less of a problem now, as I was told by networking guys that =20 > nowadays networking gears can handle 5 ms packets without problems. =20 > In fact, the VoIP gateway I talked about, which has a 12 to 17 ms =20 > codec-dependent one-way delay for a 5 ms frame/packet size, was done =20 > 6 or 7 years ago. Even back then the gateway can handle it without =20 > problems. > >> I don't think the group has an agreed-upon model which names these >> components consistently, and describes are appropriately in-scope and >> which are out-of-scope. Perhaps that is one reason why Koen is saying >> multiplier the number is 1x. > >> Also, there are real-world negative consequences to higher packet rates, >> and we have not yet considered them. > [Raymond]: Yes, higher packet rates means higher packet header =20 > overhead bit-rates, more burden on networking gears in I/O bandwidth =20 > and throughput, etc. However, that's the price to pay if we need =20 > low latency, just like if we want to avoid all these, the price to =20 > pay is higher latency. It's all a matter of trade-off and the best =20 > choice depends on the application at hand. > > In Section 2 of Jean-Marc's Internet Draft =20 > draft-ietf-codec-requirements-00, 6 specific applications for the =20 > IETF codec were listed. Fully 5 of these 6 applications list less =20 > than 10 ms of codec delay as either a requirement or a desirable =20 > feature. (The only exception is point-to-point calls.) The only way =20 > to achieve this less than 10 ms codec delay is with a codec frame =20 > size of less than 10 ms, and to get the kind of low latency that =20 > these 5 applications desire, each packet had better contain only one =20 > codec frame as payload (rather than multiple frames). > > So, yeah, there is negative consequences of the resulting higher =20 > packet rates, but hey, if we want to get low latency as desired or =20 > required by these 5 applications, that's the price we will need to =20 > be prepared to pay. There is no free lunch. If we want to use a 20 =20 > ms frame/packet size to avoid those consequences, then we need pay =20 > the price of not achieving the low latency that these 5 applications =20 > desire or require. > > Raymond > > From rchen@broadcom.com Fri May 7 18:08:13 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BD963A67B4 for ; Fri, 7 May 2010 18:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.018 X-Spam-Level: X-Spam-Status: No, score=0.018 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_50=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cq23rvjAZhPU for ; Fri, 7 May 2010 18:08:12 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 7B0993A6407 for ; Fri, 7 May 2010 18:08:12 -0700 (PDT) Received: from [10.9.200.131] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 07 May 2010 18:07:48 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Fri, 7 May 2010 18:07:48 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Koen Vos" Date: Fri, 7 May 2010 18:07:47 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcruLx+T9dFfem1CQAeXD6j4ni17EQAFvWvQ Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> <20100507144856.171013mxhy3wdfbc@mail.skype.net> In-Reply-To: <20100507144856.171013mxhy3wdfbc@mail.skype.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67FA66EE31G118488680-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 May 2010 01:08:13 -0000 Hi Koen, >> I wouldn't be surprised if the total VoIP users worldwide exceed 100M, >> probably significantly. > Correct, Skype alone has > 100M active users... [Raymond]: I knew Skype has hundreds of millions of subscribers. My=20 comment above was specifically referring to the non-computer-based=20 VoIP subscribers where a physical telephone set is involved in a=20 VoIP phone call. Sorry for not making it clear. >> Most of these are still narrowband. > No: super-wideband. [Raymond]: See my comment above. For those VoIP phone calls that=20 involve at least a physical telephone set, most of them are still=20 narrowband calls today. I trust that what you said (super-wideband)=20 must be correct for computer-to-computer calls since Skype dominates=20 that market there and you know that market better than I do, but I=20 am talking about something totally different here. > Are IP phones that come on the market today still using only =20 > narrowband? That must be a quickly reducing segment, no? [Raymond]: Many enterprise IP phones shipped today indeed have=20 wideband (16 kHz) capabilities. However, a lot of enterprises may=20 still configure them to do only narrowband calls. Even if some=20 enterprises do enable wideband calls on these phones, wideband calls=20 are typically only available for IP-phone-to-IP-phone calls between=20 IP phones in their own corporate network. The moment an employee=20 dial out of the corporate network, it's essentially all narrowband. =20 There are some wideband cell phone trials in Europe. However, when=20 I spoke to a veteran in the cell phone industry, his assessment was=20 that the up-take on wideband cell phones would be pretty slow, and=20 the narrowband cell phones would be here to stay for a VERY, VERY=20 long time. He said even today we still have to support the very=20 first digital cellular standard codec, the 13 kb/s GSM Full-Rate=20 codec, about 20 years after it came out. His point was that=20 narrowband cell phones would not go away for a long, long time. I=20 guess similar things can be said for narrowband land-line=20 telephones. > I do agree that "we shouldn't completely ignore narrowband." [Raymond]: Glad that we have an agreement here :o) Have a good weekend. From koen.vos@skype.net Sat May 8 23:08:32 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D273F3A6818 for ; Sat, 8 May 2010 23:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.374 X-Spam-Level: X-Spam-Status: No, score=-4.374 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOS2g9D9+UIx for ; Sat, 8 May 2010 23:08:31 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id B842E3A67F8 for ; Sat, 8 May 2010 23:08:30 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id C854A60139BBF; Sun, 9 May 2010 07:08:17 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=s2JSrDxLObVo ewxpFIFIafOm8Ik=; b=STCTVArzrit5yWBzz6M8PkEcSUtZ4BVieD124/AqW4PH XZXnbqmBNNbhTAWljGlABXFZKVKvzAK1oRg74M7MyPGOSmEiixrwwHpvB5Z7Xy8r 7iHvKyNo3NfTYXAobsRzFKSOo5teuHuKSjNgMpxSieBk4Wt/rHHCe5OCBXytweA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=QabutMvmllu+oGB6oQ0B 7qlx47r4Msf5G2JZsm75+eqjv1+LubOrwxXQ7ZnFUcKunSlEVB/6ttpQcQREfsDz 12Ov2ZDFNBGp8Ws2M/CH0FM/JRuu8zc15mYSspWF9Qc005FPDQb9sCxfu+qOWIgY X2HRa1+XtcA6rq9aaX2zxJU= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id C5B1860139BBD; Sun, 9 May 2010 07:08:17 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+XBsjcNAuTb; Sun, 9 May 2010 07:08:16 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id A8ED760139344; Sun, 9 May 2010 07:08:16 +0100 (IST) Received: from adsl-71-141-115-202.dsl.snfc21.pacbell.net (adsl-71-141-115-202.dsl.snfc21.pacbell.net [71.141.115.202]) by mail.skype.net (Horde Framework) with HTTP; Sat, 08 May 2010 23:08:16 -0700 Message-ID: <20100508230816.15934vyssn6jjyog@mail.skype.net> Date: Sat, 08 May 2010 23:08:16 -0700 From: Koen Vos To: "Raymond (Juin-Hwey) Chen" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <20100507140756.83037heeq3wiapf0@mail.skype.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 06:08:32 -0000 Hi Raymond, The discussion seems to be turning a bit tiresome and less relevant. To help you with the apparent contradiction: I should have said "mobile-to-mobile calls," not just "mobile phone calls." The round-trip time between two mobile phones equals 4x the mobile-to-core-network delay you mention, plus any additional network interconnect delay. So at least 320~440 ms, and for ILD calls easily 500+ ms. best, koen. Quoting "Raymond (Juin-Hwey) Chen" : > Hi Koen, > > Ah, sorry, I should have been more specific and said that the codec > buffering delay (frame size + look-ahead) does not get improved with > Moore's Law. Before my original sentence that you quoted below, I > wrote "As Moore's Law improves technologies over time, the > processing speed and communication speed improves with time,..." > From that context, it should be clear that with increased processing > speed and communication speed, the time spent on processing and > transmitting a codec frame would decrease with time. > > However, your previous argument that the frame size multiplier is > closer to 1X than 2X already assumes that the processing delay and > transmission delay are essentially negligible (at least for computer > IP phone calls according to you). Therefore, you are not going to > get much more help from Moore's Law for these two already small > delay components. > > On the other hand, devices like VoIP gateways are already using very > fast processors and connected to very fast networks, and yet the > codec-dependent one-way delay are still around 3X codec frame size > because of complicated timing issues and processor buffering needs > due to the large number of voice channels competing for resources. > As Moore's Law makes the processor even faster, chances are each > processor will handle even more voice channels, so although the time > spent on processing each codec frame size will decrease (it is > already fairly small), the scheduling/timing issue and the > associated buffering needs probably will get even worse, so I am not > convinced that the net result is that the codec-dependent delay will > get much smaller than 3X codec frame size in the future. > > In the email below, you said the average network roundtrip time is > below 300 ms. You didn't say below 250 ms or below 200 ms, so I > assume that it is just below 300 ms, which means that the one-way > network delay is just below 150 ms. Is that correct? Doesn't this > totally depends on what packet size (or packet rate) you use and how > much jitter buffer delay you allow? > > When I used some websites to test the Internet connection between my > work location in Orange County, California to Los Angeles, I > routinely get as low as 2 or 3 ms delay. Such a low network delay > for close-by cities is what makes the live music performance over > the Internet (the sixth application identified in the codec WG > charter) possible, right? If all Internet connections has close to > 150 ms delay one-way, we might as well forget about all those > applications that list low delay as required or highly desirable > (which leaves only point-to-point calls as the only application). > > BTW, I thought you once told me the one-way delay of a Skype call is > about 200 ms (which probably makes sense if your one-way network > delay is just below 150 ms). If so, I am confused by your comment > below that "Skype calls now have lower delay than mobile phone > calls", since mobile phone calls typically have one-way delays of 80 > to 110 ms. Would you please explain this apparent contradiction? > > Thanks. > > Best Regards, > > Raymond > > -----Original Message----- > From: Koen Vos [mailto:koen.vos@skype.net] > Sent: Friday, May 07, 2010 2:08 PM > To: Raymond (Juin-Hwey) Chen > Cc: codec@ietf.org > Subject: RE: [codec] #16: Multicast? > > Hi Raymond, > >> However, delay is one thing that doesn't get improved with Moore's >> Law once a codec frame size is chosen and fixed. > > You've said this before, and it's not true. Moore's law has reduced > the delay that users experience a lot: > > 1. Faster networks reduce transmission delays. In Skype we've seen > the average network roundtrip time during a call gradually go down > from well over 500 ms in 2005 to below 300 ms today. Skype calls now > have lower delay than mobile phone calls. > > 2. Faster CPUs enable tighter scheduling of audio I/O. As a result, > the buffering delay in the OS/driver has gone done over the years. > > 3. Faster CPUs mean less processing time delay. For example, SILK in > superwideband mode takes less than 10% of real-time on an iPhone. > > best, > koen. > > > > Quoting "Raymond (Juin-Hwey) Chen" : > >> Hi Stephen, >> >> I agree with your points below. I had never said a 20 ms codec frame >> size should not be used. I agree and had previously said that there >> are applications where that 20 ms frame size makes sense. All I >> have been arguing in the last couple of weeks was that there are >> also application scenarios where a low-delay mode is needed, and >> there are applications where low codec complexity is desirable or >> even important. >> >> Even draft-ietf-codec-requirements-00 talks about a low-delay mode. >> Although the codec WG charter says that "it is not the goal of >> working group to produce more than one codec", it does acknowledge >> that "based on the working group's analysis of the design space, the >> working >> group might determine that it needs to produce more than one codec, >> or a codec with multiple modes". Thus, I believe that my proposal >> to have multiple coding modes in the IETF codec (to address the >> needs of low bit-rate, low delay, or low complexity in different >> applications) is completely within the scope of the codec WG's >> charter. >> >> One more comment about the coding delay issue. When we compare VoIP >> with traditional circuit-switched PSTN telephony, VoIP is better in >> most aspects except one: it has substantially longer one-way delay >> than PSTN telephony. In this area of delay, PSTN still beats VoIP >> by far. As Moore's Law improves technologies over time, the >> processing speed and communication speed improves with time, so the >> codec complexity and encoding bit-rate are going to be less and less >> of an issue as time goes. However, delay is one thing that doesn't >> get improved with Moore's Law once a codec frame size is chosen and >> fixed. >> >> Therefore, if we take a long-term view and attempt to make VoIP >> better than or at least not significantly worse than PSTN in all >> aspects, then I believe that we should address the VoIP's long-delay >> issue head-on with a low-delay mode in the IETF codec. >> >> Raymond >> >> From: stephen botzko [mailto:stephen.botzko@gmail.com] >> Sent: Thursday, May 06, 2010 12:12 PM >> To: Raymond (Juin-Hwey) Chen >> Cc: Koen Vos; codec@ietf.org >> Subject: Re: [codec] #16: Multicast? >> >> I basically agree with your points below. >> >> There are lots of tradeoffs in codec design, including this one. >> Personally I think there is value in a moderate delay 20 ms frame >> size, possibly augmented with a low-delay mode. 20 ms works quite >> well for video conferencing, since the video frame rate is no faster >> than 60 fps (about 15 ms per frame). >> >> Regards >> Stephen Botzko >> >> >> >> >> On Thu, May 6, 2010 at 3:03 PM, Raymond (Juin-Hwey) Chen >> > wrote: >> Hi Stephen, >> >> Sorry, I was too busy to respond yesterday. >> >> You wrote: >>> Generally the need to buffer the current frame is treated as part of the >>> algorithmic delay. At least I believe that is what the ITU-T does. >>> So maybe we need a list of what all these components are? >> [Raymond]: Sure, my previous analysis was an attempt to do just >> that, but perhaps my list was not complete enough. >> >>> I'd suggest keeping the gateway out of it for the first pass. >> [Raymond]: May I ask why? >> >>> I've worked with Gateways\MCUs where the packet size had to be increased >>> because packet loading in the product became too high. Also, if you >>> have QOS features enabled in many routers, the routers themselves have >>> to start using a "software path", which creates a similar throughput >>> problem in the routers. Too many packets per second can overwhelm these >>> devices, creating both capacity issues and excessive queuing delays. >> >> [Raymond]: OK, now I see what you meant when you said "it is totally >> possible that reducing the frame size might actually increase the >> latency". This is probably more likely to happen many years ago but >> less of a problem now, as I was told by networking guys that >> nowadays networking gears can handle 5 ms packets without problems. >> In fact, the VoIP gateway I talked about, which has a 12 to 17 ms >> codec-dependent one-way delay for a 5 ms frame/packet size, was done >> 6 or 7 years ago. Even back then the gateway can handle it without >> problems. >> >>> I don't think the group has an agreed-upon model which names these >>> components consistently, and describes are appropriately in-scope and >>> which are out-of-scope. Perhaps that is one reason why Koen is saying >>> multiplier the number is 1x. >> >>> Also, there are real-world negative consequences to higher packet rates, >>> and we have not yet considered them. >> [Raymond]: Yes, higher packet rates means higher packet header >> overhead bit-rates, more burden on networking gears in I/O bandwidth >> and throughput, etc. However, that's the price to pay if we need >> low latency, just like if we want to avoid all these, the price to >> pay is higher latency. It's all a matter of trade-off and the best >> choice depends on the application at hand. >> >> In Section 2 of Jean-Marc's Internet Draft >> draft-ietf-codec-requirements-00, 6 specific applications for the >> IETF codec were listed. Fully 5 of these 6 applications list less >> than 10 ms of codec delay as either a requirement or a desirable >> feature. (The only exception is point-to-point calls.) The only way >> to achieve this less than 10 ms codec delay is with a codec frame >> size of less than 10 ms, and to get the kind of low latency that >> these 5 applications desire, each packet had better contain only one >> codec frame as payload (rather than multiple frames). >> >> So, yeah, there is negative consequences of the resulting higher >> packet rates, but hey, if we want to get low latency as desired or >> required by these 5 applications, that's the price we will need to >> be prepared to pay. There is no free lunch. If we want to use a 20 >> ms frame/packet size to avoid those consequences, then we need pay >> the price of not achieving the low latency that these 5 applications >> desire or require. >> >> Raymond >> >> > > > > > From trac@tools.ietf.org Sun May 9 10:21:20 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA4403A6A76 for ; Sun, 9 May 2010 10:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.13 X-Spam-Level: X-Spam-Status: No, score=-101.13 tagged_above=-999 required=5 tests=[AWL=-1.131, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKzHLhiJvM26 for ; Sun, 9 May 2010 10:21:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D21203A6A89 for ; Sun, 9 May 2010 10:21:08 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1OBABS-0003ds-DF; Sun, 09 May 2010 10:20:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 09 May 2010 17:20:54 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/19#comment:2 Message-ID: <071.d8b4cc2e3960f92569ae8bff500e48e0@tools.ietf.org> References: <062.f8b0d2abf056a9655a81ee25366bb354@tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <062.f8b0d2abf056a9655a81ee25366bb354@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #19: How large is the frame size depended delay / the serialization delay / frame size depended processing delay? (was: How large is the frame size depended delay / the serialization delay?) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 17:21:20 -0000 #19: How large is the frame size depended delay / the serialization delay / frame size depended processing delay? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Stephen]: There's algorithmic delay (including framing) + flight time + dejittering. Flight time depends on the network path, not on the frame size. And the amount of jitter is due principally to cross-congestion. [Raymond]: My main point was not the absolute one-way delay value for the 5 ms frame size but the relative delay between 5 ms and 20 ms frame sizes. I agree that the 5X delay might be too simplistic. I tried to use a simple formula to make it is easier for people to follow, but I did realize its limitation especially at a small frame size, so I added that “Even if you use a longer jitter buffer, …” sentence. Regardless of whether 5X frame size is overly simplistic, the fact remains that cellular codecs have a 20 ms frame size and have a typical one-way delay around 80 to 110 ms or so, and the cellular networks probably don’t have the kind of jitter that the Internet has. What would make us believe that an IETF codec with a 20 ms frame size will get a one-way delay much below 80 ms? Chances are an Internet call using an IETF codec with a 20 ms frame size will likely have a one-way delay at least as long as the one-way delay of a cell phone call, and more likely to be longer, because PC audio driver software tends to add quite a bit of delay, and an Internet call incurs additional jitter buffer delay when compared with cell phone calls. Therefore, regardless of the accuracy of the 5X frame size formula, the conclusion remains the same: for the conference bridge application, a 20 ms codec frame size will result in the total one-way delay far exceeding the ITU-T’s 150 ms guideline, thus substantially degrading the perceived quality of the communication links, and with one or even two cell phone callers joining the conference, the long latency and the associated problems will just get much worse. Therefore, it is necessary for the IETF codec to have a low-delay mode using a small codec frame size such as 5 ms to address delay-sensitive applications such as bridge-based conference calls. [Mikhael]: The light-speed-in-fiber delay RTT is 1ms per 100km. Europe - US West coast is ~150ms RTT. I'm in Thailand at the momen. I have 350ms RTT to Sweden currently (because the path goes sweden->us->singapore>thailand), just to give some datapoints. Add then ADSL2+ 25ms RTT just over the access layer, and I'd say that 200ms network RTT (100ms one-way) might be a low percentage of the calls, but it's still definitely going to happen. Considering the prices of internationall calls out of a place like this, a lot of people are going to want to use it to get around it. [Raymond]: First, I agree that codec algorithmic buffering delay is more accurate than frame size since it can also include the “look-ahead” delay and filtering delay if sub-band analysis/synthesis is used. However, your formula implies that for the codec-related delay, the “multiplier” to be used for the codec frame size is only 1. That’s unrealistic and theoretically impossible. For that to happen, after you wait one frame of time for the current frame of input audio samples to arrive at your input signal buffer (that’s one frame of codec-related delay already), you need an infinitely fast processor to finish the encoding operation instantly, then you need an infinitely fast communication link to ship all the bits in the compressed frame to the decoder instantly, and then you need an infinitely fast processor to finish decoding the frame instantly and start playing back the current frame of audio without any delay. That’s just impossible. In reality, if the processor is just barely fast enough to implement the codec in real time, then you need nearly a full frame of time to finish the encoding and decoding operations. That makes the multiplier to be 2 already. If your communication link is just barely fast enough to transmit your packets at the same speed they are generated without piling up unsent packets, then it takes another frame of time to finish transmitting the compressed bits in a frame to the decoder. That makes the multiplier to be 3 already. Granted, in practice the processor and the communication link are usually faster than just barely enough, so the processing delay and the transmission delay can be less than 1 frame each. However, there are other miscellaneous uncounted delays that tend to depend on the codec size in various ways. Thus, a typical IP phone implementation would have One-way delay = codec-independent delay + 3*(codec frame size) + (codec look-ahead) + (codec filtering delay if any). Hence, the one-way delay difference between a 20 ms and a 5 ms codec frame size would be 45 ms + (codec look-ahead difference) + (codec filtering delay difference). Consequently, for the conference bridge application, the total difference in one-way delay can easily be in the 90 to 100 ms range. When adding this delay difference to all the other codec-independent delay components, it is still a huge difference that the users can easily notice, especially since it will most likely push the total one-way delay significantly beyond the 150 ms limit. [Stephen]: There is a floor transmission delay when you send the minimum size packets the network path allows. There is an incremental delay due to serialization when you send larger size packets than the minimum. (At each hop you wait until you receive last bit in the packet before you forward the first bit). I'd agree that a reasonable model for the incremental delay is that it scales linearly with the increase in packet size. But the floor delay is usually too large for this to matter dominate. And on top of that is the variable delay (jitter) due to congestion, layer 2 retransmission, and the like. That also will not scale linearly with frame size or packet size. [Koen]: Processing time matters on low-end hardware - a small fraction of today's VoIP end points. Even then, the higher coding efficiency of longer frames can be translated into lower complexity. [Raymond]: Processing time certainly matters for IP phones, and there are a lot of enterprise IP phones deployed today. I heard that it is actually significantly cheaper for enterprises to have their entire phone systems IP-phone-based than analog-phone-based. I won’t be surprised that before too long the vast majority of enterprises will use only IP phones. Even consumer phones and cell phones are moving toward IP-based. Eventually that would be a very large percentage of VoIP end points. [Koen]: And transmission delay increases (perhaps) linearly with the *packet size*, not with the *frame size*. For a 32 kbps codec with 5 ms frames, packets are just 30% smaller than with a 16 kbps codecs with 20 ms frames. [Raymond]: Agreed. My previous comments on transmission delay was based on the TDM rather than packet scenario, but I was just using that simplified TDM example to make a point that transmission delay cannot be zero, as your 1X frame size multiplier would imply. Even with your statement above, a larger codec frame size still makes a larger packet size, which then increases the transmission delay, so you can’t say transmission delay is zero or is independent of the codec size. In any case, these are really minor details. My key point is that your 1X multiplier for the codec frame size is simply theoretically impossible. The rule of thumb used by IP phone engineers is around 3X codec frame size. [Koen]: Let me ask you something: how often is G.729 used with 10 ms packets, or Broadvoice with 5 ms packets? [Raymond]: Not very often, but that’s because previously network routers/switches didn’t like to handle too many packets per second, and the higher packet header overhead associated with a smaller packet size means the overall bit-rate would be higher than desired or allowed, so the time of small packet size for low-delay VoIP hasn’t really come yet. However, with the help of Moore’s Law, network routers/switches are becoming much faster now, and I was told that they can handle a 5 ms packet size without problems; furthermore, the speed of backbone networks and access networks keep increasing with time, so the bit-rate concern will also decrease with time. Unlike processing speed and communication speed that continuously get improved with time for decades, delay is one thing that will NOT get improved with time and Moore’s Law cannot do anything about that! If the IETF codec has a minimum frame size of 20 ms, we will be stuck with the longer overall delay associated with that, and Moore’s Law will not help us reduce that delay in the future. On the other hand, in addition to using a 20 ms frame size for bit-rate-sensitive applications, if the IETF codec also has a low-delay mode that uses a 5 ms frame size, then at least for delay-sensitive applications, people have a choice to achieve a lower delay by paying the price of a higher overall bit-rate (i.e. with packet header counted), and this higher bit-rate will be less and less of a concern as the network speed keep increasing with time. Therefore, recognizing that delay cannot be helped by Moore’s Law but bit- rate can, it would be wise for the IETF codec WG to adopt a low-delay mode for the codec in order to be future-proof. [Raymond]:[…] one-way delay = codec-independent delay + 3*(codec frame size) + (codec look-ahead) + (codec filtering delay if any). The main debate now is centered on whether the multiplier of the codec frame size should be 1 as Koen said or 3 as I was told by experienced IP phone engineers. I argue that 1X is theoretically impossible. It is interesting to note that the ITU-T uses a multiplier of 2X. I think 2X is probably achievable for the idealized situation. In practice, however, many nitty-gritty details get in the way of getting that idealized situation, and little additional delays just keep getting added, resulting in a real-world realistic 3X multiplier. With a 3X multiplier, the one- way delay difference between a 20 ms and a 5 ms codec frame size would be 45 ms + (codec look-ahead difference) + (codec filtering delay difference). For the conference bridge application, the total difference in one-way delay will double to the 90 to 100 ms range. That’s a VERY significant difference that typical users will notice (it’s like adding another cell phone call delay), especially if it pushes the total one-way delay significantly beyond the 150 ms guideline. Therefore, I argue that for the best user experience in conference bridge calls, the IETF codec should have a low-delay mode with a small codec frame size such as 5 ms, and let the continually increasing speed of communication links make the header overhead bit-rate become less and less of an issue in the future. (Even now, for those people who have high speed connection to their computers, it is already not an issue. It is better for them to get low delay than to worry about bit-rate or packet header overhead.) [Stephen]: Serialization delay is defined as being Serialization Delay = Size of Packet (bits) / Transmission Rate (bps) This is summed over all hops. For a typical low-speed backbone hop (OC3), the serialization delay for the bitrates we are talking about result in serialization delay on the order of 10 microseconds for 20 ms frame sizes. For a fast backbone hop (OC48) it is on the order of 1 microsecond. There is a handy calculator here: http://kt2t.us/serialization_delay.html [Stephen]: If the frame-size multiplier is due to serialization, then I agree with Koen's assessment. In fact on many connections the multiplier would be less than 1. Dial-up is of course the worst case here, and on those links the multiplier ought to be close to 2. Variations due to congestion (and on some links, polling) are (IMHO) better modeled as jitter. Gateways are another matter, with the delays being highly dependent on the product architecture. Interupt latencies, context switching, bus architectures, etc. can dominate, so it is totally possible that reducing the frame size might actually increase the latency (since it increases the packets per second load on the gateway). So I agree with Koen on this as well. Anecdotal models based on industry experience can be useful guides - though if we are going to use these models to drive requirements, I'd prefer something more analytical. [Christian]: I agree that serialization, processing, and implementation delay should be distinguished. Assume a low-cost VoIP phone with its processing power being fully utilized by one call: Then, the DSP/CPU needs an entire frame duration to encode and decode frames. Thus, the latency is increase by one frame length in addition to the serialization delay, propagation delay, algorithmic delay, dejittering delay, echo cancelling delay, ... Running the chips at 100% load is of course cost saving compared to add some more computational resource. But is this still a relevant issue today? I am not sure whether it always make sense for mobile device to run at 100% load. Of course, from a energy consumption perceptive it make sense to run CMOS circuit at the lowest possible frequency as power consumption drops quadratic. But maybe running the CPU/DSP at higher speed and switching to power save mode if after a frame has been decoded/encoded is be equally energy efficient… Also, I do not think we shall consider implementation delay, which occurs due to suboptimal implementation. For example, some years ago we tested the RTT of two Linux softphones link directly together using G.711. It was 400ms. The implementation delay could be a good performance metric to differentiate two otherwise equal products. Also, the algorithmic processing delay might be subject to similar market optimization. Having said this, I would anyhow suggest to include the processing delay into the measurement of the end-to-end (acoustic round) trip time. Those measurements should be part of the control loop that optimizes the overall conversation call quality. [Koen]: > Gateways are another matter, with the delays being highly dependent on > the product architecture. Interupt latencies, context switching, bus > architectures, etc. can dominate, so it is totally possible that > reducing the frame size might actually increase the latency (since it > increases the packets per second load on the gateway). So I agree > with Koen on this as well. [Raymond]: I agree with the first half of your paragraph above but not the second half, because the second half contradicts with the real-world observed behaviors: G.711 with a 5 ms frame/packet size gets 12 to 17 ms of codec-dependent delay, while G.711 with a 10 ms frame/packet size gets 50 to 60 ms of worst-case codec-dependent delay before delay optimization, and 30 ms after delay optimization. In these two actual real-world VoIP gateway implementations, the codec-dependent delay grow with the codec frame size with about a 3X multiplier. [Raymond]: The frame-size multiplier has many more components than just serialization as I have discussed in my previous emails. How can the total multiplier be less than 1 when just buffering the current frame of input speech samples will take one frame? Perhaps you are only talking about the serialization delay component? I agree that delay variations due to congestion are better modeled as jitter. That's always the case, and my previous discussions did not include jitter in the codec-dependent delay. [Raymond]: We broke down the one-way delay into codec-independent delay and codec-dependent delay, and then further broke down the codec-dependent delay into the components of codec buffering delay, processing delay, transmission delay (I guess what you called serialization delay), and scheduling and buffering delays of the micro-controllers and DSPs due to many tasks to many channels competing for the processors, etc. We also analyzed which part doesn't change with improving technology (e.g. codec buffering delay) and how certain delay components may change with increasing processor speed and transmission speed. Isn't that analytical? How much more analytical can you get than that? We didn't just throw a few real-world observed codec-dependent delay values and ask everyone to believe the 3X multiplier without any explanation or analysis. No, we just used these real-world values to support our analysis. [Stephen]: Generally the need to buffer the current frame is treated as part of the algorithmic delay. At least I believe that is what the ITU-T does. -- Ticket URL: codec From trac@tools.ietf.org Sun May 9 10:25:15 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB7BB3A6A83 for ; Sun, 9 May 2010 10:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BKEq1Zo8oIn for ; Sun, 9 May 2010 10:25:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 43AA228C0CE for ; Sun, 9 May 2010 10:25:03 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1OBAFH-0003fk-Rd; Sun, 09 May 2010 10:24:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 09 May 2010 17:24:51 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/31 Message-ID: <062.033384855453e54a2a3d58ff06d7ccb1@tools.ietf.org> X-Trac-Ticket-ID: 31 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #31: Requirements of high-density VoIP gateways (and low cost VoIP phone)? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 17:25:15 -0000 #31: Requirements of high-density VoIP gateways (and low cost VoIP phone)? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- What are the special requirements of high-density VoIP gateways? What is different as compared to soft-phones? How do the latency laws differ? Are those requirements novell or covered by existing codecs? -- Ticket URL: codec From trac@tools.ietf.org Sun May 9 10:30:39 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B97613A6987 for ; Sun, 9 May 2010 10:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.97 X-Spam-Level: X-Spam-Status: No, score=-100.97 tagged_above=-999 required=5 tests=[AWL=-1.285, BAYES_50=0.001, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jZS6GN6Dtyn for ; Sun, 9 May 2010 10:30:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0C35B3A688F for ; Sun, 9 May 2010 10:30:38 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1OBAKg-0007KV-UI; Sun, 09 May 2010 10:30:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 09 May 2010 17:30:26 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/31#comment:1 Message-ID: <071.ed8f4214802ed6fa1cfed32aff870c5a@tools.ietf.org> References: <062.033384855453e54a2a3d58ff06d7ccb1@tools.ietf.org> X-Trac-Ticket-ID: 31 In-Reply-To: <062.033384855453e54a2a3d58ff06d7ccb1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #31: Requirements of high-density VoIP gateways (and low cost VoIP phone)? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 17:30:39 -0000 #31: Requirements of high-density VoIP gateways (and low cost VoIP phone)? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Christian]: > Does DSP take over all codec processing? May the CPU do some parts of > the computation > before, during or after DSP does the signal processing? [Raymond]: I asked an engineering manager who was deeply involved in the design of high-density VoIP gateways. He said that in such gateways, due to the high number of voice channels (thousands) per box, a large number of DSPs and micro-controllers are used, and they are usually structured in a hierarchical way. The DSPs typically take care of all speech codec processing, echo cancellation, DMTF tone detection, and fax, etc. The DSPs are usually divided into groups, with each groups of DSPs controlled by a single micro-controller, which handles things like RTP, jitter buffering, packetization, QoS statistics, and moving the voice traffic to and from the DSPs in the group. Then, on top of that there may be higher- performance controllers, each connected to many such groups of micro- controller + DSPs. These higher-performance controllers may handle things like call setup, UDP/IP/RTP, routing to and from internal processor groups, and routing to and from external networks/devices. [Christian]: > How do you count number of channels? Do all voice channels have the > same weight regardless their sampling rate? > Say suppose, if the mixing is done for 48kHz instead of 8kHz, how many > resource are we allowed to consume more? [Raymond]: I am not sure what you meant. The channel count is just counting the actual physical voice channels that the gateway can handle simultaneously; it is not a weighted sum. Are you thinking that a 48 kHz channel should be counted more than an 8 kHz channel because it requires more computational resources? Typical VoIP gateways only support 8 kHz telephone-bandwidth speech, so 48 kHz is out of the picture. With that said, the complexity difference between speech codecs can make a big difference in the channel density. Let's say a VoIP gateway supports X simultaneous voice channels running the G.711 codec. Since the complexity of G.711 PCM is next to nothing, the complexity of each voice channel is dominated by the echo canceller (EC). Now if you replace the G.711 codec by the G.729A codec which takes about 10 MIPS of computational complexity for a full-duplex codec, that can easily decrease the channel density to X/2.5 per gateway, depending on the EC and other things. If you replace the G.711 codec by the G.728 codec that takes 30+ MIPS, the channel density can easily go down to X/4 ~ X/5 or worse. Thus, if you choose a high-complexity codec, you would need to buy a lot more VoIP gateways to support the same number of voice channels than if you use a low-complexity codec. The cost difference is very real and can be very big. The engineering manager I mentioned in my last email (who is a different from the IP phone expert I previously mentioned) told me that “the devil is in the details” and that excluding the jitter buffer delay and other codec-independent delays, a straightforward VoIP gateway implementation without paying attention to minimizing delay may have a codec-dependent one-way delay of 5X to 6X codec frame size because of all of the various delays of (2) above due to complex timing issues that come with supporting so many channels simultaneously. Even after analyzing all delay components carefully and “optimizing the delay to death” until there is no more room for delay reduction, the worst-case one-way codec-dependent delay is still about 3X codec frame size, excluding jitter and other codec-independent delay. This is an independent corroboration of what the other IP phone expert said about the codec-independent one-way delay of 3X codec frame size for VoIP gateways. (The two of them worked on different projects in different companies.) My conclusion: while I am less familiar with VoIP soft client implementations on computers, at least for IP phones and VoIP gateways, the rule of thumb that many engineers found to work well for codec- dependent one-way delay is 3X (codec frame size) + other codec buffering delays (e.g. look-ahead and/or filtering delay). [Raymond]: Regarding the 3X multiplier for VoIP gateways, I already stated clearly in my original text that the 12 to 17 ms was the codec-dependent one-way delay. There is no "constant delay of 7 ms" in that (if it were constant, it would not be codec-dependent). The whole 12 to 17 ms delay was proportional to the codec frame size. As I said in my last email to Christian, there is another independent corroboration by another person (who was deeply involved in VoIP gateway designs) that this 3*(codec frame size) worst-case codec-dependent one-way delay was about the lowest that can be achieved after they "optimized the delay to death". What I didn't say is that this was actually for G.711 channels with a 10 ms frame/packet size, where the actual processing time spent on encoding and decoding the 10 ms G.711 codec frame was next to nothing, and yet the complex scheduling and buffering delays throughout the system, which are proportional to the 10 ms processing intervals, still added up to 3X frame size. Currently, 70% to 80% of the phone shipments to large enterprises are IP phones. With small enterprises also counted, the overall average is about 60% IP phones. The current industry projection is that within 5 years, the overall average would be 80% to 90% IP phones. (The large enterprises will probably be close to 100% IP phones by then.) Hence, there are already a huge number of IP phones deployed, and in the future it would be almost all IP phones in the workplace, especially in medium to large companies. I think it would be a mistake for the IETF Internet codec to completely ignore such IP phone applications, but if we want to address such a huge installed base of IP phones, the 3*(codec frame size) delay is very real for IP phones and it is desirable to have a low-delay mode for the IETF codec to enhance the user experience when using the IETF codec in such IP phones. [Stephen]: I've worked with Gateways\MCUs where the packet size had to be increased because packet loading in the product became too high. Also, if you have QOS features enabled in many routers, the routers themselves have to start using a "software path", which creates a similar throughput problem in the routers. Too many packets per second can overwhelm these devices, creating both capacity issues and excessive queuing delays. [Raymond]: OK, now I see what you meant when you said "it is totally possible that reducing the frame size might actually increase the latency". This is probably more likely to happen many years ago but less of a problem now, as I was told by networking guys that nowadays networking gears can handle 5 ms packets without problems. In fact, the VoIP gateway I talked about, which has a 12 to 17 ms codec-dependent one- way delay for a 5 ms frame/packet size, was done 6 or 7 years ago. Even back then the gateway can handle it without problems. … Yes, higher packet rates means higher packet header overhead bit-rates, more burden on networking gears in I/O bandwidth and throughput, etc. However, that's the price to pay if we need low latency, just like if we want to avoid all these, the price to pay is higher latency. It's all a matter of trade-off and the best choice depends on the application at hand. In Section 2 of Jean-Marc's Internet Draft draft-ietf-codec- requirements-00, 6 specific applications for the IETF codec were listed. Fully 5 of these 6 applications list less than 10 ms of codec delay as either a requirement or a desirable feature. (The only exception is point- to-point calls.) The only way to achieve this less than 10 ms codec delay is with a codec frame size of less than 10 ms, and to get the kind of low latency that these 5 applications desire, each packet had better contain only one codec frame as payload (rather than multiple frames). So, yeah, there is negative consequences of the resulting higher packet rates, but hey, if we want to get low latency as desired or required by these 5 applications, that's the price we will need to be prepared to pay. There is no free lunch. If we want to use a 20 ms frame/packet size to avoid those consequences, then we need pay the price of not achieving the low latency that these 5 applications desire or require. [Raymond]: All I have been arguing in the last couple of weeks was that there are also application scenarios where a low-delay mode is needed, and there are applications where low codec complexity is desirable or even important. Even draft-ietf-codec-requirements-00 talks about a low-delay mode. Although the codec WG charter says that “it is not the goal of working group to produce more than one codec”, it does acknowledge that “based on the working group's analysis of the design space, the working group might determine that it needs to produce more than one codec, or a codec with multiple modes”. Thus, I believe that my proposal to have multiple coding modes in the IETF codec (to address the needs of low bit-rate, low delay, or low complexity in different applications) is completely within the scope of the codec WG’s charter. One more comment about the coding delay issue. When we compare VoIP with traditional circuit-switched PSTN telephony, VoIP is better in most aspects except one: it has substantially longer one-way delay than PSTN telephony. In this area of delay, PSTN still beats VoIP by far. As Moore’s Law improves technologies over time, the processing speed and communication speed improves with time, so the codec complexity and encoding bit-rate are going to be less and less of an issue as time goes. However, delay is one thing that doesn’t get improved with Moore’s Law once a codec frame size is chosen and fixed. Therefore, if we take a long-term view and attempt to make VoIP better than or at least not significantly worse than PSTN in all aspects, then I believe that we should address the VoIP’s long-delay issue head-on with a low-delay mode in the IETF codec. [Koen]: Ultra-low delay is important and has been part of the requirements from day one. [...] Personally I'm convinced that people want super-wideband and probably even full-band audio before they want a < 20 ms codec, if they have the bitrate to support either. Yes, even for interactive voice. Audio bandwidth just has a bigger impact on user experience. The analysis we've done within our Skype network supports this conclusion. But maybe it's different with IP phones which apparently have problems with delay, dunno.. [Hoene]: I have been told that similar statement are valid also for other gateway manufactures and that the design of high-density gateways is much more demanding than of softphones: Because data and code memory is limited and code cannot be loaded on demand, costs are already high, power consumption is a problem, execution is highly paralleled, etc... Thus, it makes sense to have a codec (profile) optimized for this use case. […] And, are these requirements unique or are they covered by existing codecs like G.711 and G.729 already? Is it likely that gateways, which operate already on their limits, can support yet another codec? [Gregory]: There are a number of excellent pre-existing codecs out there— during the formation of this working group we concluded that there was a significant non-addressed application space which a new codec could satisfy, but I've seen a number of requirements raised here which may be specific to applications for which existing codecs are already well suited. In particular while computational burden is an essential concern, I don't think it is reasonable to subject a full-band / super-band / wideband codec to the same criteria which would be reasonable for a narrow band codec. If your gateway can't scale to acceptable size except with very computationally cheap codecs, then you probably ought to be using one of the already established narrow-band codecs. I don't think it's a good idea to design for very high levels of complexity but we ought to keep in mind that the working group is already targeted at something high quality (and thus more complex) than narrow band. Together with the normal "moore's law" progress in transistor density, I think these factors may suggest a slight bias towards additional computational complexity at least where the increase in complexity can be effectively used. [Christian]: > What are those specific codec requirements, then? > - narrow-band? > - 5ms or 10ms frame size? > - low complexity > - low memory footprint > - transcoding robust ... [Raymond]: - For the foreseeable future, I think most of the VoIP gateway voice channels will still be narrowband. We may start to see some wideband (16 kHz sampling). - There are different VoIP gateway customers. Some just want the lowest possible cost of deployment and don't care too much about call quality or latency; they will probably use 20 ms packets. However, some want to compete seriously with the PSTN telephony offered by incumbent telcos. There they have to have good quality and low latency since PSTN latency is very low. These customers will want to use 10 ms packets or even 5 ms packets if their hardware can handle it. - Yes, relatively low complexity and low memory footprint are both important for VoIP gateway implementation of codecs. - Good transcoding performance is also a plus, although generally if a codec's single encoding performance is already high, then it transcoding performance is usually good as well. [Raymond]: I never propose that we should subject full- /super-/wide-band codecs to the same complexity constraints as for narrowband codecs. What I am proposing, though, is that for a particular sampling-rate, be it 16, 32, 44.1, or 48 kHz, when we consider different codec options, we should not ignore the codec complexity, because high codec complexity have negative consequences in low-end devices and gateways. My other point is that although the WG does want a wideband/super- wideband/full-band audio codec, we shouldn't completely ignore narrowband, because that's still how most of the point-to-point voice calls and multi- party voice conferencing (the first two of the six applications listed in the charter) are conducted today and in the foreseeable future. Just North American cable operators alone have tens of millions of VoIP telephony subscribers. If you add other countries, telcos, independent VoIP operators like Vonage, and enterprise IP phone users, although I don't have the stats, I wouldn't be surprised if the total VoIP users worldwide exceed 100M, probably significantly. Most of these are still narrowband. Therefore, it makes the most sense for the IETF codec to be able to also address narrowband speech coding so it has a chance to be used by these VoIP users. If a call goes through the IETF codec and reaches out to a conventional phone through a VoIP gateway, then it is better if the call doesn't have to be transcoded to another medium- or low-bit-rate codec so the additional codec distortion and coding delay can be avoided. This is where the recent discussion of VoIP gateways come in. [Raymond]: devices like VoIP gateways are already using very fast processors and connected to very fast networks, and yet the codec- dependent one-way delay are still around 3X codec frame size because of complicated timing issues and processor buffering needs due to the large number of voice channels competing for resources. As Moore's Law makes the processor even faster, chances are each processor will handle even more voice channels, so although the time spent on processing each codec frame size will decrease (it is already fairly small), the scheduling/timing issue and the associated buffering needs probably will get even worse, so I am not convinced that the net result is that the codec-dependent delay will get much smaller than 3X codec frame size in the future. -- Ticket URL: codec From trac@tools.ietf.org Sun May 9 10:32:03 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 674E43A688F for ; Sun, 9 May 2010 10:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.124 X-Spam-Level: X-Spam-Status: No, score=-101.124 tagged_above=-999 required=5 tests=[AWL=-1.124, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHuJTSI7uhpq for ; Sun, 9 May 2010 10:32:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 589033A6817 for ; Sun, 9 May 2010 10:32:02 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1OBAM3-0007Mi-AS; Sun, 09 May 2010 10:31:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 09 May 2010 17:31:51 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/28#comment:1 Message-ID: <071.ae971d97e4ce49d214b97c95cb88df4b@tools.ietf.org> References: <062.23d5df12c0b3d27cb5b6b25801ab2a4d@tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <062.23d5df12c0b3d27cb5b6b25801ab2a4d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #28: Layered bit-stream X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 17:32:03 -0000 #28: Layered bit-stream ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Vladimir]: We'd like to express SPIRIT's point of view on the topic. It is as follows: 1/ we support layered coding in our IPMR-codec. Such approach is used by ITU-T Recs G.711.1 and G.718, for example. 2/ we think that VoIP and Videoconferencing systems are users of such codecs. 3/ we consider that it is not needed to drop scalability and layered coding. [Christian]: As far as I understand, layered coding helps if multiple streams having the sample content but different rates must be generated. For example, if a conferencing system stream the same audio stream to N users but each users has a different bandwidth. Just encode all layers and drop the higher layers for the low bandwidth users. This approach is easy and efficient and reduces the encoding complexity. The arguments against are simple. a) First, this use case is a local optimization only. Thus, the must not be standardized. b) Second, instead of layered coding one can use other ways of tweaking the implementation performance. For example, if you calculate a 512 FFT do get two 256 FFTs for free. I bet there are thousand other shortcuts which I am not aware of. Thus, I have the opinion that layered coding is not worth the extra bandwidth of 20 or more percentage. It is just good locally but not needed for interoperability. [Dmitry]: From application point of view, the layered stream structure allows server manipulate channel bandwidth individually for each user with zero performance overhead. Obviously, conferencing is the most important use- case. […] Shall layered coding be supported? - we think "yes", because ... (see my first sentence) Who needs it? - answered Can we drop this requirement? - only if we have real good reasons for it. Do we have them? [Christian]: Because […] an application programmer want[s] to have an easy life, the codec designer shall develop a more complicated codec? In addition, everybody should suffer from a higher bit rate? No, that is not fair. > Obviously, conferencing is the most important use-case. No, end-to-end connections are more frequent than conference calls. > "local optimization" of what? I mean that the layered coding is only used within one computer. It is not important in-between computers. And, it is only a performance optimization that makes the conference gateway faster. [Stephen]: A couple of observations on this (a) I agree with Christian that layered codecs usually need higher bitrates to achieve the same quality. Of course we do want good quality over our desired bitrate range, and it is likely to be more difficult to achieve that with a layered codec. (b) I agree with Dimity that layered codecs reduce the complexity of VOIP gateways and perhaps conference bridges. Also, with layered codec designs you get wire-speed management of channel bandwidth, so there can be a delay benefit as well as a complexity reduction. (c) Arguing about the relative priority of multipoint conferences vs point to point calls is pointless, because they are clearly both MUSTS. I am not sure if Christian is arguing that layered codecs SHALL NOT be considered, or if the requirements allow but are not biased towards layered proposals. If might be useful to clarify this point. [Christian]: Let me explain my arguments a bit more by discussion point b. (b) I agree with Dimity that layered codecs reduce the complexity of VOIP gateways and perhaps conference bridges. I see that there is an important need to reduce the computational complexity at gateways and conference bridges. Layered coding is an easy solution that helps to reduce complexity. However, I think that there are many other ways to achieve similar complexity reduction WITHOUT requiring layered coding. One example is a special encoder that encodes multiple streams at the same time. Also, with layered codec designs you get wire-speed management of channel bandwidth, so there can be a delay benefit as well as a complexity reduction. Also, a fast management of channel bandwidth can be achieved by controlling the encoder (via a feedback channel not locally) Thus, I would vote for a NEED NOT or even MUST NOT because the costs of layered encoding are imposed to all users of the codec but the benefit is only to the gateways. [Dimitry]: Definitely, there are number of applications that can (more or less efficiently) utilize layered stream structure. At the same time, scalability makes codec more complex and cause bitrate penalty due to a simple fact that entropy(a+b)<=entropy(a)+entropy(b). The only question is: what penalty is acceptable and what is not? Based on IP-MR codec experience I consider the price for scalability as not too high. > I mean that the layered coding is only used within one computer. > It is not important in-between computers. And, it is only a > performance optimization that make the conference gateway faster. This is correct. No other benefits except performance saving. [Dimitry]: […] But the thing is that this is not a point we should stand on. Let’s stay on a point of problems and solutions. The problem is: gateways have to recompress data to fit user bandwidth and it would be very desired to decrease recompression cost: Does this problem live only in my mind? - any considerations are welcome. Possible solution : The layered stream structure allows zero cost recompression (but increases bitrate/quality ratio). All other solutions are also welcome. -- Ticket URL: codec From trac@tools.ietf.org Sun May 9 10:33:42 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA1473A6817 for ; Sun, 9 May 2010 10:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.214 X-Spam-Level: X-Spam-Status: No, score=-101.214 tagged_above=-999 required=5 tests=[AWL=-1.028, BAYES_40=-0.185, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqN--BhzPfBG for ; Sun, 9 May 2010 10:33:40 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7A04F3A6987 for ; Sun, 9 May 2010 10:33:38 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1OBANb-0007QK-F4; Sun, 09 May 2010 10:33:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 09 May 2010 17:33:27 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/19#comment:3 Message-ID: <071.c3241f7f83c9b7119f4ad52b2f3b91a7@tools.ietf.org> References: <062.f8b0d2abf056a9655a81ee25366bb354@tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <062.f8b0d2abf056a9655a81ee25366bb354@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #19: How large is the frame size depended delay / the serialization delay / frame size depended processing delay? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 17:33:42 -0000 #19: How large is the frame size depended delay / the serialization delay / frame size depended processing delay? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Stephen]: There's algorithmic delay (including framing) + flight time + dejittering. Flight time depends on the network path, not on the frame size. And the amount of jitter is due principally to cross-congestion. [Raymond]: My main point was not the absolute one-way delay value for the 5 ms frame size but the relative delay between 5 ms and 20 ms frame sizes. I agree that the 5X delay might be too simplistic. I tried to use a simple formula to make it is easier for people to follow, but I did realize its limitation especially at a small frame size, so I added that “Even if you use a longer jitter buffer, …” sentence. Regardless of whether 5X frame size is overly simplistic, the fact remains that cellular codecs have a 20 ms frame size and have a typical one-way delay around 80 to 110 ms or so, and the cellular networks probably don’t have the kind of jitter that the Internet has. What would make us believe that an IETF codec with a 20 ms frame size will get a one-way delay much below 80 ms? Chances are an Internet call using an IETF codec with a 20 ms frame size will likely have a one-way delay at least as long as the one-way delay of a cell phone call, and more likely to be longer, because PC audio driver software tends to add quite a bit of delay, and an Internet call incurs additional jitter buffer delay when compared with cell phone calls. Therefore, regardless of the accuracy of the 5X frame size formula, the conclusion remains the same: for the conference bridge application, a 20 ms codec frame size will result in the total one-way delay far exceeding the ITU-T’s 150 ms guideline, thus substantially degrading the perceived quality of the communication links, and with one or even two cell phone callers joining the conference, the long latency and the associated problems will just get much worse. Therefore, it is necessary for the IETF codec to have a low-delay mode using a small codec frame size such as 5 ms to address delay-sensitive applications such as bridge-based conference calls. [Mikhael]: The light-speed-in-fiber delay RTT is 1ms per 100km. Europe - US West coast is ~150ms RTT. I'm in Thailand at the momen. I have 350ms RTT to Sweden currently (because the path goes sweden->us->singapore>thailand), just to give some datapoints. Add then ADSL2+ 25ms RTT just over the access layer, and I'd say that 200ms network RTT (100ms one-way) might be a low percentage of the calls, but it's still definitely going to happen. Considering the prices of internationall calls out of a place like this, a lot of people are going to want to use it to get around it. [Raymond]: First, I agree that codec algorithmic buffering delay is more accurate than frame size since it can also include the “look-ahead” delay and filtering delay if sub-band analysis/synthesis is used. However, your formula implies that for the codec-related delay, the “multiplier” to be used for the codec frame size is only 1. That’s unrealistic and theoretically impossible. For that to happen, after you wait one frame of time for the current frame of input audio samples to arrive at your input signal buffer (that’s one frame of codec-related delay already), you need an infinitely fast processor to finish the encoding operation instantly, then you need an infinitely fast communication link to ship all the bits in the compressed frame to the decoder instantly, and then you need an infinitely fast processor to finish decoding the frame instantly and start playing back the current frame of audio without any delay. That’s just impossible. In reality, if the processor is just barely fast enough to implement the codec in real time, then you need nearly a full frame of time to finish the encoding and decoding operations. That makes the multiplier to be 2 already. If your communication link is just barely fast enough to transmit your packets at the same speed they are generated without piling up unsent packets, then it takes another frame of time to finish transmitting the compressed bits in a frame to the decoder. That makes the multiplier to be 3 already. Granted, in practice the processor and the communication link are usually faster than just barely enough, so the processing delay and the transmission delay can be less than 1 frame each. However, there are other miscellaneous uncounted delays that tend to depend on the codec size in various ways. Thus, a typical IP phone implementation would have One-way delay = codec-independent delay + 3*(codec frame size) + (codec look-ahead) + (codec filtering delay if any). Hence, the one-way delay difference between a 20 ms and a 5 ms codec frame size would be 45 ms + (codec look-ahead difference) + (codec filtering delay difference). Consequently, for the conference bridge application, the total difference in one-way delay can easily be in the 90 to 100 ms range. When adding this delay difference to all the other codec-independent delay components, it is still a huge difference that the users can easily notice, especially since it will most likely push the total one-way delay significantly beyond the 150 ms limit. [Stephen]: There is a floor transmission delay when you send the minimum size packets the network path allows. There is an incremental delay due to serialization when you send larger size packets than the minimum. (At each hop you wait until you receive last bit in the packet before you forward the first bit). I'd agree that a reasonable model for the incremental delay is that it scales linearly with the increase in packet size. But the floor delay is usually too large for this to matter dominate. And on top of that is the variable delay (jitter) due to congestion, layer 2 retransmission, and the like. That also will not scale linearly with frame size or packet size. [Koen]: Processing time matters on low-end hardware - a small fraction of today's VoIP end points. Even then, the higher coding efficiency of longer frames can be translated into lower complexity. [Raymond]: Processing time certainly matters for IP phones, and there are a lot of enterprise IP phones deployed today. I heard that it is actually significantly cheaper for enterprises to have their entire phone systems IP-phone-based than analog-phone-based. I won’t be surprised that before too long the vast majority of enterprises will use only IP phones. Even consumer phones and cell phones are moving toward IP-based. Eventually that would be a very large percentage of VoIP end points. [Koen]: And transmission delay increases (perhaps) linearly with the *packet size*, not with the *frame size*. For a 32 kbps codec with 5 ms frames, packets are just 30% smaller than with a 16 kbps codecs with 20 ms frames. [Raymond]: Agreed. My previous comments on transmission delay was based on the TDM rather than packet scenario, but I was just using that simplified TDM example to make a point that transmission delay cannot be zero, as your 1X frame size multiplier would imply. Even with your statement above, a larger codec frame size still makes a larger packet size, which then increases the transmission delay, so you can’t say transmission delay is zero or is independent of the codec size. In any case, these are really minor details. My key point is that your 1X multiplier for the codec frame size is simply theoretically impossible. The rule of thumb used by IP phone engineers is around 3X codec frame size. [Koen]: Let me ask you something: how often is G.729 used with 10 ms packets, or Broadvoice with 5 ms packets? [Raymond]: Not very often, but that’s because previously network routers/switches didn’t like to handle too many packets per second, and the higher packet header overhead associated with a smaller packet size means the overall bit-rate would be higher than desired or allowed, so the time of small packet size for low-delay VoIP hasn’t really come yet. However, with the help of Moore’s Law, network routers/switches are becoming much faster now, and I was told that they can handle a 5 ms packet size without problems; furthermore, the speed of backbone networks and access networks keep increasing with time, so the bit-rate concern will also decrease with time. Unlike processing speed and communication speed that continuously get improved with time for decades, delay is one thing that will NOT get improved with time and Moore’s Law cannot do anything about that! If the IETF codec has a minimum frame size of 20 ms, we will be stuck with the longer overall delay associated with that, and Moore’s Law will not help us reduce that delay in the future. On the other hand, in addition to using a 20 ms frame size for bit-rate-sensitive applications, if the IETF codec also has a low-delay mode that uses a 5 ms frame size, then at least for delay-sensitive applications, people have a choice to achieve a lower delay by paying the price of a higher overall bit-rate (i.e. with packet header counted), and this higher bit-rate will be less and less of a concern as the network speed keep increasing with time. Therefore, recognizing that delay cannot be helped by Moore’s Law but bit- rate can, it would be wise for the IETF codec WG to adopt a low-delay mode for the codec in order to be future-proof. [Raymond]:[…] one-way delay = codec-independent delay + 3*(codec frame size) + (codec look-ahead) + (codec filtering delay if any). The main debate now is centered on whether the multiplier of the codec frame size should be 1 as Koen said or 3 as I was told by experienced IP phone engineers. I argue that 1X is theoretically impossible. It is interesting to note that the ITU-T uses a multiplier of 2X. I think 2X is probably achievable for the idealized situation. In practice, however, many nitty-gritty details get in the way of getting that idealized situation, and little additional delays just keep getting added, resulting in a real-world realistic 3X multiplier. With a 3X multiplier, the one- way delay difference between a 20 ms and a 5 ms codec frame size would be 45 ms + (codec look-ahead difference) + (codec filtering delay difference). For the conference bridge application, the total difference in one-way delay will double to the 90 to 100 ms range. That’s a VERY significant difference that typical users will notice (it’s like adding another cell phone call delay), especially if it pushes the total one-way delay significantly beyond the 150 ms guideline. Therefore, I argue that for the best user experience in conference bridge calls, the IETF codec should have a low-delay mode with a small codec frame size such as 5 ms, and let the continually increasing speed of communication links make the header overhead bit-rate become less and less of an issue in the future. (Even now, for those people who have high speed connection to their computers, it is already not an issue. It is better for them to get low delay than to worry about bit-rate or packet header overhead.) [Stephen]: Serialization delay is defined as being Serialization Delay = Size of Packet (bits) / Transmission Rate (bps) This is summed over all hops. For a typical low-speed backbone hop (OC3), the serialization delay for the bitrates we are talking about result in serialization delay on the order of 10 microseconds for 20 ms frame sizes. For a fast backbone hop (OC48) it is on the order of 1 microsecond. There is a handy calculator here: http://kt2t.us/serialization_delay.html [Stephen]: If the frame-size multiplier is due to serialization, then I agree with Koen's assessment. In fact on many connections the multiplier would be less than 1. Dial-up is of course the worst case here, and on those links the multiplier ought to be close to 2. Variations due to congestion (and on some links, polling) are (IMHO) better modeled as jitter. Gateways are another matter, with the delays being highly dependent on the product architecture. Interupt latencies, context switching, bus architectures, etc. can dominate, so it is totally possible that reducing the frame size might actually increase the latency (since it increases the packets per second load on the gateway). So I agree with Koen on this as well. Anecdotal models based on industry experience can be useful guides - though if we are going to use these models to drive requirements, I'd prefer something more analytical. [Christian]: I agree that serialization, processing, and implementation delay should be distinguished. Assume a low-cost VoIP phone with its processing power being fully utilized by one call: Then, the DSP/CPU needs an entire frame duration to encode and decode frames. Thus, the latency is increase by one frame length in addition to the serialization delay, propagation delay, algorithmic delay, dejittering delay, echo cancelling delay, ... Running the chips at 100% load is of course cost saving compared to add some more computational resource. But is this still a relevant issue today? I am not sure whether it always make sense for mobile device to run at 100% load. Of course, from a energy consumption perceptive it make sense to run CMOS circuit at the lowest possible frequency as power consumption drops quadratic. But maybe running the CPU/DSP at higher speed and switching to power save mode if after a frame has been decoded/encoded is be equally energy efficient… Also, I do not think we shall consider implementation delay, which occurs due to suboptimal implementation. For example, some years ago we tested the RTT of two Linux softphones link directly together using G.711. It was 400ms. The implementation delay could be a good performance metric to differentiate two otherwise equal products. Also, the algorithmic processing delay might be subject to similar market optimization. Having said this, I would anyhow suggest to include the processing delay into the measurement of the end-to-end (acoustic round) trip time. Those measurements should be part of the control loop that optimizes the overall conversation call quality. [Koen]: > Gateways are another matter, with the delays being highly dependent on > the product architecture. Interupt latencies, context switching, bus > architectures, etc. can dominate, so it is totally possible that > reducing the frame size might actually increase the latency (since it > increases the packets per second load on the gateway). So I agree > with Koen on this as well. [Raymond]: I agree with the first half of your paragraph above but not the second half, because the second half contradicts with the real-world observed behaviors: G.711 with a 5 ms frame/packet size gets 12 to 17 ms of codec-dependent delay, while G.711 with a 10 ms frame/packet size gets 50 to 60 ms of worst-case codec-dependent delay before delay optimization, and 30 ms after delay optimization. In these two actual real-world VoIP gateway implementations, the codec-dependent delay grow with the codec frame size with about a 3X multiplier. [Raymond]: The frame-size multiplier has many more components than just serialization as I have discussed in my previous emails. How can the total multiplier be less than 1 when just buffering the current frame of input speech samples will take one frame? Perhaps you are only talking about the serialization delay component? I agree that delay variations due to congestion are better modeled as jitter. That's always the case, and my previous discussions did not include jitter in the codec-dependent delay. [Raymond]: We broke down the one-way delay into codec-independent delay and codec-dependent delay, and then further broke down the codec-dependent delay into the components of codec buffering delay, processing delay, transmission delay (I guess what you called serialization delay), and scheduling and buffering delays of the micro-controllers and DSPs due to many tasks to many channels competing for the processors, etc. We also analyzed which part doesn't change with improving technology (e.g. codec buffering delay) and how certain delay components may change with increasing processor speed and transmission speed. Isn't that analytical? How much more analytical can you get than that? We didn't just throw a few real-world observed codec-dependent delay values and ask everyone to believe the 3X multiplier without any explanation or analysis. No, we just used these real-world values to support our analysis. [Stephen]: Generally the need to buffer the current frame is treated as part of the algorithmic delay. At least I believe that is what the ITU-T does. So maybe we need a list of what all these components are? -- Ticket URL: codec From trac@tools.ietf.org Sun May 9 10:42:49 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14393A69F1 for ; Sun, 9 May 2010 10:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.309 X-Spam-Level: X-Spam-Status: No, score=-101.309 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PIyI5m8VZWh for ; Sun, 9 May 2010 10:42:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 84CB83A6950 for ; Sun, 9 May 2010 10:42:48 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1OBAWT-0007i4-G8; Sun, 09 May 2010 10:42:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 09 May 2010 17:42:37 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/32 Message-ID: <062.b8ceb20e92d29837ff18a0b34358b30a@tools.ietf.org> X-Trac-Ticket-ID: 32 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #32: Playout/Dejittering Buffer X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 17:42:50 -0000 #32: Playout/Dejittering Buffer ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- This ticket summarized the discussions regarding dejittering buffer issues... -- Ticket URL: codec From trac@tools.ietf.org Sun May 9 10:43:25 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C39BC3A6A8B for ; Sun, 9 May 2010 10:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.116 X-Spam-Level: X-Spam-Status: No, score=-101.116 tagged_above=-999 required=5 tests=[AWL=-1.116, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfomDn41M9WX for ; Sun, 9 May 2010 10:43:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5B8AE3A6A89 for ; Sun, 9 May 2010 10:43:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1OBAX2-0007ik-Am; Sun, 09 May 2010 10:43:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 09 May 2010 17:43:12 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/32#comment:1 Message-ID: <071.7888e6ea3c53994d4429980e148138ab@tools.ietf.org> References: <062.b8ceb20e92d29837ff18a0b34358b30a@tools.ietf.org> X-Trac-Ticket-ID: 32 In-Reply-To: <062.b8ceb20e92d29837ff18a0b34358b30a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #32: Playout/Dejittering Buffer X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 17:43:25 -0000 #32: Playout/Dejittering Buffer ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Koen]: Also, note that for a given probability of packets arriving too late to be played out, the jitter buffer delay is independent of the frame size. [Raymond]: That may be true theoretically, but in practical implementations, selecting a jitter buffer delay that is not divisible by the packet size would make the adaptive jitter buffer pretty messy to implement. If we make the it divisible by the packet size, then a smaller packet size gives you more granularity to work with and can result in lower average delay as the codec frames go through the adaptive jitter buffer. [Koen]: Jitter buffers have no problem implementing a non-integer-frame delay, because packets are queued and read non-synchronously. [Raymond]: I am talking about adaptive jitter buffer that tries to minimize the delay through the jitter buffer dynamically depending on the observed network jitter. If the jitter is small, you decrease that delay, and if it is large, you increase that delay. An engineer who actually implemented such an adaptive jitter buffer in an IP phone told me that the non-integer-frame delay made it pretty messy to implement (I didn’t say it was not possible; it’s just messy), so for implementation simplicity’s sake, the jitter delay was often chosen to be an integer number of frames. He also said that a smaller frame size gives you more frequent observations of the network jitter and thus makes the jitter estimate more responsive and accurate. [Mikhael]: 2 seconds jitter and 10% continous random packet loss should definitely be handled gracefully (during the tsunami where several fiber optic cables were severed in asia, packet loss from the region to the rest of the world was continous 5-7% due to remaining paths being extremely congested). 2 seconds is for multiple links in a row being full (typically Cisco 12000 routers can buffer 600ms of data when congestion occurs). There are numerous cases (ADSL2+ without interleave, high speed links with CRC errors, ethernet duplex errors) where random packet loss can be seen. Typically this is less than 1%, otherwise people tend to fix the problem because TCP works very badly. We then have the 3G/wifi network issue, where jitter can also be at least 2 seconds, plus packet loss as well (some networks seem to buffer X kilobytes, some Y number of packets, after that they tail drop. I've seen both behaviours). Burst loss, where when you have a network re-route, you might lose typically 0.05 - 2 seconds of data, and you might get re-ordering during the convergence. Since this is a transient event, I don't think much can be done about it but try to play data as they come in and just ignore out of order packets. Perhaps jitter buffer should be increased when out-of-order packets is seen, but when things calm down again it needs to be reduced again. I've also seen networks which re-order packets constantly, I don't know what the load-sharing algorithm used is, but I think the jitter buffer size should be adapted and handle out of order packets so they're presented to the codec correctly. When running voice over GSM GPRS, typically there is very low bandwidth and high delay. Here bw should be kept as low as possible and the IP header is a big overhead and pps should thus be kept at a minimum, for instance 3-5 pps and the very lowest quality setting should be used. So, the SYSTEM (I'm not just talking codec here), as far as I can see it, needs to gracefully handle at least 10% packet loss, out of order packets (analyse the time they might be re-ordered and adapt jitter buffer accordingly), or just plain jitter up to 2s. My reasoning here is mainly focused on voice over Internet, but as far as I can see this applies to all sound, even though if it's not interactive I guess the focus can be switched from low latency (it might be better for a voice call to have lower latency than actually getting perfect sound) to reliable sound delivery with higher latency (by increasing jitter buffer and putting sound information in multiple packets so that single packet loss doesn't mean silence in that interval). Basically I'd like to see that as soon as jitter buffer is increased, the resiliancy to packet loss should be increased as well by telling the other end that it can start to do packet loss concealment information in the packets as well (whatever it's called, I'm not a codec guy). If sender knows what the receiver jitter buffer is, then this can be used to increase resiliency (I guess). [Michael]: >Thanks for the very useful industry examples and metrics. Handling of >these examples fall either into jitter buffer design (which so far in >the BoF email correspondence, other than noting the need for some form >of adaptive jitter buffer algorithm, is being treated as largely >outside the scope of the proposed WG) [Christian]: Jitter buffering is not explicitly mentioned in the Codec BOF. However, it must be considered because the requirements regarding testing. As stated in http://www.ietf.org/mail-archive/web/codec/current/msg01527.html, we shall test the codec using real trace of IP packets. These tests can only be made with some kind of dejitter buffer between packets and codec. Thus, at some point of time, we must agree which playout buffer to take for the testing. -- Ticket URL: codec From trac@tools.ietf.org Sun May 9 10:56:07 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDB983A6A7C for ; Sun, 9 May 2010 10:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.113 X-Spam-Level: X-Spam-Status: No, score=-101.113 tagged_above=-999 required=5 tests=[AWL=-1.113, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upTuxUyrePBL for ; Sun, 9 May 2010 10:56:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E688B3A6A81 for ; Sun, 9 May 2010 10:56:04 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1OBAjJ-0001nP-TJ; Sun, 09 May 2010 10:55:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 09 May 2010 17:55:53 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/21#comment:1 Message-ID: <071.09efd48992c6281692d6860b09d86a77@tools.ietf.org> References: <062.a00b15332f6e9da39f0d81d14d24c64d@tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <062.a00b15332f6e9da39f0d81d14d24c64d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #21: Supporting Wireless Links? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 17:56:08 -0000 #21: Supporting Wireless Links? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Raymond]: Many telephone terminal devices at the edge of the Internet use embedded processors with limited processing power, and the processors also have to handle many tasks other than speech coding. If the IETF codec complexity is too high, some of such devices may not have sufficient processing power to run it. Even if the codec can fit, some battery-powered mobile devices may prefer to run a lower-complexity codec to reduce power consumption and battery drain. For example, even if you make a Internet phone call from a computer, you may like the convenience of using a Bluetooth headset that allows you to walk around a bit and have hands-free operation. Currently most Bluetooth headsets have small form factors with a tiny battery. This puts a severe constraint on power consumption. Bluetooth headset chips typically have very limited processing capability, and it has to handle many other tasks such as echo cancellation and noise reduction. There is just not enough processing power to handle a relatively high-complexity codec. Most BT headsets today relies on the extremely low-complexity, hardware-based CVSD codec at 64 kb/s to transmit narrowband voice, but CVSD has audible coding noise, so it degrades the overall audio quality. If the IETF codec has low enough complexity, it would be possible to directly encode and decode the IETF codec bit-stream at the BT headset, thus avoiding the quality degradation of CVSD transcoding. [Koen]: By the time the BlueTooth Special Interest Group will have adopted a future IETF codec standard, Moore's law will surely have multiplied CPU resources in the BT device by one order of magnitude..? Not sure it makes sense to apply today's BT constraints to tomorrow's codec. I'm not even convinced BlueTooth is a relevant use case for an Internet codec. BT devices are audio devices more than VoIP end points: BT always connects to the Internet through another device. You could simply first decode incoming packets and send PCM data to the BT device, or use a high-quality/high-bitrate codec like G.722. The requirements for BT devices and the Internet are just too different. Similarly, GSM phones use AMR on the network side and a different codec towards the BT device. The required transcoding causes no quality problems because BT supports high bitrates. [Raymond]: Hi Koen, Responding to your earlier email about Bluetooth headset application: (1) Although BT SIG standardization is a preferred route, it is technically feasible to negotiate and use a non-Bluetooth-SIG codec. (2) Someone familiar with BT SIG told me that it would probably take only 6 months to add an optional codec to the BT SIG spec and 12 to 18 months to add a mandatory codec. (3) The IETF codec is scheduled to be finalized in 14 months and submitted to IESG in 18 months. Even if we take the BT SIG route and take 6 to 18 months there. The total time of 2 to 3 years from now means the Moore's Law would only increase the CPU resources 2X to 3X, and definitely no more than 4X max, not 10X. (4) Most importantly, guess what, in the last several years the Bluetooth headset chips have been growing its processing power at a MUCH, MUCH slower rate than what the Moore's Law says it should. Sometimes they did not increase the speed at all for years. The reasons? The ASP (average sale price) of Bluetooth chips plummeted very badly, making it unattractive to invest significant resources to make them significantly faster. Also, for low-end and mid-end BT headsets, the BT chips were often considered "good enough" and there wasn't a strong drive to increase the computing resources. In addition, the BT headsets got smaller over the last few years; the corresponding reduction in battery size required a reduction in power consumption, which also limited how fast the processor speed could grow. In the next several years, it is highly likely that the computing capabilities of Bluetooth headset chips will continue to grow at a rate substantially below what's predicted by the Moore's Law. (5) Although Bluetooth supports G.711 as an optional codec, basically no one uses it because it is too sensitive to bit errors. Essentially all the BT mono headsets on the market today are narrowband (8 kHz sampling) headsets using CVSD. There isn't any real wideband support yet, so your comment about G.722 doesn't apply. Even after wideband-capable BT headsets come out, for many years to come the majority of the BT headsets (especially mid- to low-end) will still be narrowband only, running only CVSD. Hence, the quality degradation of the CVSD transcoding is real and will be with us for quite a while, so it is desirable for the IETF codec to have a low-complexity mode that can directly run on the BT headsets to avoid the quality degradation of CVSD when using BT headsets to make Internet phone calls. (6) Even if you could use G.711 or G.722 in the BT headsets, they both operate at 64 kb/s. A low-complexity mode of the IETF codec can operate at half or one quarter of that bit-rate. This will help conserve BT headsets' radio power because of the lower transmit duty cycle. It will also help the Bluetooth + WiFi co-existence technologies. (7) Already a lot of people are used to using Bluetooth headsets to make phone calls today. If they have a choice, many of these people will also want to use Bluetooth headsets to make Internet phone calls, not only through computers, but also through smart phones connected to WiFi or cellular networks. As more and more states and countries pass laws to ban the use of cell phones that are not in hands-free mode while driving, the number of Bluetooth headset users will only increase with time, and many of them will want to make Internet-based phone calls. Given all the above, I would argue that Bluetooth headset is a very relevant application that the IETF codec should address with a low- complexity mode. [Koen]: You seem to suggest that the IETF Internet codec should fit Bluetooth requirements in order to enable transcoding-free operation all the way from the Internet, through the Internet-connected device, to the BT wireless audio device. A similar argument would hold for ITU-T cellular codecs: AMR-WB and G.718 could have been designed with BT as an application. In reality, these codecs have very little in common with BT codecs, because of the vastly different requirements in terms of - complexity - memory footprint - bitrate - scalability - bit error robustness - packet loss robustness. Do you think it's realistic for us to come up with a design that fulfills the needs of both worlds? The alternative is to separately design codecs for Internet applications and BT devices, and continue the practice of transcoding on the Internet- connected device. That would have a better chance of maximizing quality in all scenarios. [Raymond]: […] If a high-quality, low-complexity, wider bandwidth IETF codec mode can be implemented in Skype and the Bluetooth headset to avoid the CVSD transcoding (together with wideband upgrade of the transducers and audio path in the BT headset, of course), then not only will you get much better speech quality in your Skype calls than what you have experienced, but also you will get a lower latency. This is because transcoding between the Skype codec and CVSD not only accumulates the coding distortion of the two codecs, but also accumulates the coding delays. Although CVSD is a sample-by-sample codec, BT headsets still transmit the CVSD bit-stream in 3.75 ms or 7.5 ms packets, and they can potentially add a one-way delay up to 20 ~ 25 ms through the Bluetooth headset (the exact delay depends on the implementation). While we were discussing whether a 5 ms packet size can even be considered, for many years Bluetooth headsets have been using an even smaller 3.75 ms packet size. [Raymond]: I agree that there are some fundamental differences in the requirements for cellular codecs and Bluetooth codecs which caused the codecs in these two types of devices to each go their own way. However, these differences are (or can be) substantially smaller between an Internet codec and Bluetooth codecs, so I think it is easier for Internet devices and Bluetooth devices to use the same codec to avoid the additional delay and coding distortion of transcoding. (1) Royalty-free requirement: Cellular codecs are usually royalty-bearing, and that's acceptable in the cellular world. Not so with Bluetooth. Bluetooth devices are meant to be simple and low cost. As such, Bluetooth SIG basically only wants to standardize royalty-free technologies. That's an important reason why they picked the CVSD codec, a royalty-free old technology of 1970. We are trying to make the IETF codec royalty-free, so in this regard this goal is consistent with the Bluetooth SIG's royalty-free requirement for codec. (2) Bit-rate requirement: Cellular radio spectrum is a limited, fixed resource that doesn't change with time, and cellular operators spent billions of dollars in radio spectrum auctions. Thus, it is extremely important for cellular codecs to have bit-rates as low as possible, with an average bit-rate often going below 1 bit/sample, to maximize the number of cellular subscribers a given amount of radio spectrum can support. In contrast, the bit-rate is not nearly as big a concern for Bluetooth. Initially Bluetooth SIG picked the relatively high-bit-rate 64 kb/s CVSD narrowband codec (8 bits/sample) for its simplicity and royalty-free nature among other things. Since the speeds of the Internet back bone and access networks keep growing with time, the bit-rate of an Internet codec is also not nearly as big a concern as in cellular codecs, and an Internet codec around 2 bits/sample can have better trade-offs (e.g. higher quality, lower delay, and lower complexity) for Internet applications than what cellular codecs can provide. Incidentally, Bluetooth SIG is moving toward 4 bits/sample. As you can see, in terms of the bit-rate requirement, an Internet codec is much closer to Bluetooth codecs than cellular codecs are. (3) Complexity requirement: Bluetooth headsets have much lower processing power and much smaller batteries than cell phones. The complexity of cellular codecs, typically in the range of 20 to 40 MHz on a DSP, is too high to fit most Bluetooth headsets. However, unlike cell phones and Bluetooth headsets where each is a specific type of device with a relatively narrow range of device complexity, Internet voice/audio applications can potentially encompass a large variety of different device types, from desktop computers at the high end with > 3 GHz multi-core CPU to IP phones and possibly even Bluetooth headsets at the low end with a processor of only a few tens of MHz. It is up to the IETF codec WG how we want the complexity of the IETF codec to be. We can standardize just one codec mode that works well for computer-to-computer calls but can't fit in low-end devices, or we can keep that mode but also have a low-complexity mode that can be implemented in low-end devices. Frankly, I think the second approach makes much more sense since it allows many more devices to benefit from the IETF codec and enables the large number of Bluetooth headset users to avoid the additional distortion and delay associated with transcoding when making Internet calls. (4) Delay requirement: Due to the need for cellular codecs to achieve bit- rates as low as possible, they sacrificed the coding delay and used a 20 ms frame size, because using a 10 or 5 ms frame size would increase the bit-rate for a given level of speech quality. On the other hand, a Bluetooth headset needs to have a low delay since its delay is added to the already long cell phone delay. For the IETF codec, again it is up to the codec WG to decide what kind of codec delay we want, and again I think it makes sense to have a higher-delay, higher bit-rate efficiency mode for bit-rate-sensitive applications and another low-delay mode for delay- sensitive applications, since one size doesn't fit all. If the IETF codec delay is forced to be one size, the resulting codec will be (potentially very) suboptimal for some applications. You wrote: > Do you think it's realistic for us to come up with a design that > fulfills the needs of both worlds? With a one-size-fit-all approach, probably not, but with a multi-mode approach, then I think so. [Stephen]: Though the Bluetooth angle is interesting, it is clearly out-of-scope for this WG. Of course Bluetooth SIG could pick up CODEC later on if they think it meets their requirements. [Christian]: I just want to share some insights from the recent development of Bluetooth's Hands-Free Profile (HFP) version 1.5, which supports wideband speech. One main requirement were on the frame size of 7.5 ms because the Bluetooth MAC protocol support scheduling at this interval. Actually, to achieve this they modified SBC to work on 15 blocks instead of 4,8,12 or 16 blocks and they decided against G.722. The lesson to learn is about the importance of MAC protocol. To get a efficient, low power, and mobile device you have to consider the impact of packet scheduling. If packets are scheduled regular, the MAC protocol can work more efficient. The more irregular packet arrive, the more expensive a packet transmission gets. Actually, you can translate the cost of packet scheduling to bits per packet. Depending on the wireless technology, it might vary substantially. The worst case is 802.11b at 11 Mbps at long preamble - then, you can add about 1300 bytes to every packet just for physical headers and MAC scheduling. However, more modern technologies like LTE and IEEE 802.11n are much more efficient in terms of per packet overhead. If you ask me, one important usage scenario is over wireless links supporting low-power mobile devices. If we ignore this scenario it will be a judge mistake: a) Battery powered mobile devices must be energy efficient to reduce the size of the batteries. Also, they should not demand to many computational resources, otherwise they would consume to much energy. b) Wireless IP access is also in scope because many devices get Internet access LTE, WLAN, Wimax, UMTS, etc. Bluetooth headsets are somewhat a special case. Actually, they are two cases: 1) Headphones (A2DP): For me it is not clear whether supporting the Internet CODEC on top of A2DP (which is - by the way - already possible according to Bluetooth spec A2DP V1.2) or using the Internet CODEC till the Bluetooth AP and transcoding to SBC is more efficient, cost effect, or energy saving. 2) Mic (HFP): Here is the scheduling of 3.75 or 7.5ms might be an important requirement that the Internet CODEC cannot fulfill always because it must adapt its parameters to the Internet transmission path not just to the Bluetooth link. Thus, I would recommend to write a liaison statement to Bluetooth AVT group and ask whether they would have interest to include the Internet CODEC into a future version of A2DP. Definitely, this must not happen soon because the they can do is only if the Internet CODEC is finishing. Supporting HFP might be more difficult than A2DP because of the very tough requirements on efficiency. PS: No, not version 1.5 but its not yet published successor. [Roni]: I think that this is going to a wrong direction. I already suggested that since the group will do one codec we first need to decide on the applications. The initial request was for a wideband codec for the Internet and this is the application that should dictate the requirements. We can look at the other applications in the requirements and charter and continue with the requirements that are in-line with the original application. Other applications are nice to have if they do not add more requirements to the codec to be defined here. We are talking here on more requirements which in my understanding are not in the scope of the WG [Stephen]: I agree that Wireless IP is in scope, one could also argue that LTE might be in scope, since it will be using IPv6. As we all know, the internet runs over multiple physical layers, and usually an end-to-end connection uses more than one physical layer. So I am not sure how we can translate layer 2 constraints into requirements for CODEC itself. I can see how it might impact the RTP packetization - allowing frames to be split across packets would allow media-aware devices to adjust the packetization to optimize delivery. [Koen]: I continue to fail to see the connection between the Internet codec and Bluetooth, for the reasons below. (1) Bluetooth != Internet: Bluetooth devices are wireless audio devices, not VoIP end points, and are indeed used mostly for (mobile) PSTN calls. (2) Diverging requirements: A codec/mode that meets the BT requirements for ultra-low complexity will have a relatively poor coding efficiency, resulting in lower audio quality and/or a higher bitrate. Both of these negatively impact the user experience over the Internet. Therefore, you do not want to run a BT codec over the Internet if you can use a more efficient codec instead. (3) Transcoding: Even when using a BT audio device, a well-designed VoIP end point will always transcode between the Internet codec and the BT codec, because: a) the reason given in 2) above b) the BT device lacks the CPU power and memory to run the entire VoIP stack c) it allows for a packet-loss concealment operation in between two lossy lags of the end-to-end connection. Note that such transcoding is also standard with DECT devices, where base stations even transcode between G.722 and G.722 (yes: twice the same codec). In short, there is no benefit from the BT and Internet codecs being modes of one and the same codec. This complete lack of overlap means that: I) it is better to standardize two separate codecs II) Bluetooth is out of scope for the Internet codec. [Raymond]: In the same order as your numbered list below: (1) True, Bluetooth != Internet for now, but why not look into the future and explore what is possible and will be very good to have for the future? (2) Your argument here doesn't make sense to me. For PC-to-PC calls, there is no reason to use an ultra-low-complexity mode, so you don't need to suffer the lower coding efficiency, and therefore your concern is not relevant. For any call that involves a Bluetooth headset, it would be better to use a low-complexity mode of the IETF codec on the Bluetooth headset than to go through CVSD transcoding and suffer the significant quality degradation of CVSD and the additional coding delay due to transcoding. (3) a) The reason in 2) is not a reason as I explained above. b) Didn’t you say Moore’s Law will take care of that? :-) Furthermore, I am not sure it is necessary for the Bluetooth headset to run the entire VoIP stack. c) It is not at all clear that doing PLC two times on each of the two lossy links is necessarily better than doing PLC just once after the packets go through the two lossy links. It may well be that the latter approach is better, considering that the transcoding distortion of the second link may go up substantially when encoding the output of the first PLC for the first lossy link. I) Standardizing two separate codecs takes more time and effort and requires transcoding which increases total coding distortion and total coding delay. II) For you and some, it is out of the scope, but for others it is not. Different people have different views. My view is that if we can cover this very useful usage scenario without too much trouble, why leave it out? [Stephen]: Bluetooth is clearly out-of-scope for this group. -- Ticket URL: codec From hoene@uni-tuebingen.de Sun May 9 11:10:58 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7823A6A8B for ; Sun, 9 May 2010 11:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ke+EiA8GqgYS for ; Sun, 9 May 2010 11:10:56 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id EDD823A68BC for ; Sun, 9 May 2010 11:10:54 -0700 (PDT) Received: from hoeneT60 ([178.2.215.148]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o49IAXDo015956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 9 May 2010 20:10:38 +0200 From: "Christian Hoene" To: Date: Sun, 9 May 2010 20:10:32 +0200 Message-ID: <002e01caefa2$ef88c9a0$ce9a5ce0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrvouSxwCvhij/GQOaYD+wavcY/Sw== Content-language: de x-cr-hashedpuzzle: 5rg= A9+j Bjba Bocb Ci/E DIEL EFkd Fn+J GbPw I7I4 JAud JrNX KZTY KxNG LIj1 L1k9; 1; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {463A1A8B-810A-4219-A93E-280B540E0A7C}; aABvAGUAbgBlAEAAdQBuAGkALQB0AHUAZQBiAGkAbgBnAGUAbgAuAGQAZQA=; Sun, 09 May 2010 18:10:23 GMT; dABoAGkAcwAgAHcAZQBlAGsAcwAgAHMAdQBtAG0AYQByAHkA x-cr-puzzleid: {463A1A8B-810A-4219-A93E-280B540E0A7C} X-AntiVirus-Spam-Check: failed (checked by Avira MailGate: version: 3.0.0-4; spam filter version: unknown; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.236; VDF: 7.10.7.66; host: mx05); id=30568-sUCjZJ Subject: [codec] this weeks summary X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 18:10:58 -0000 Hi all, Again, many emails this week. Any important results? My personal summary = after reading them all again: Raymond did a great job explaining the special requirements of = high-density VoIP gateway. They are differ substantially to those of soft-phones (but are somewhat similar to VoIP phones with embedded = CPUs). The requirements include low memory footprint, ultra-low delay, low complexity and mostly narrow band. But aren't those = requirements already covered by existing codecs? Shall this working group provide a codec profile for end-to-gateway beside the profile for = an end-to-end codec? SpiritDSP and Christian were discussing the need for layered coding - no = consensus yet... The week before, we were discussing whether to consider Bluetooth and = Wireless IP as use cases. It seems to be a rough consensus that wireless IP is in-scope and that Bluetooth is out-of-scope because = it requires too special optimizations. However, battery powered, wireless devices might require low-complexity and low-bandwidth = (and are in-scope?). With best regards, Christian --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ From koen.vos@skype.net Sun May 9 14:36:51 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 804D03A67F6 for ; Sun, 9 May 2010 14:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[AWL=-0.511, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oon9FqNMB5YS for ; Sun, 9 May 2010 14:36:50 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 01E7E3A67AD for ; Sun, 9 May 2010 14:36:49 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id C9366607AB661; Sun, 9 May 2010 22:36:37 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=oIxI40okm179 WprtXP/WfnLZiqw=; b=kVhf1Tfxky40Hi6i/1NEL9UCaqtGwceFSnXI2yT53RMb /HwDN/qsuH0z8uGwbqxB5xOsHAIQQ/lJDCn9svnQdril47uP6ADaGI6C0ZPHqhm5 i3PvFqAYkw6FMJG1K2TVvrDvBuvn2EcEWOzY6bmVZkikFQmYXfl0mw73rijLSO4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=p3YXVkDPt6eKdRO8E08u acFj7hY/2nNHSNDpJUNLapKJETRFs4KII1IQ4sF1crhyMKy5dTn2TfS+5a0QZb6I uF2bhtb+TNR2JEb3jolGvx/bC87rX9Luam6kmTNKSBrAtiB+0lei6btFxAgOknf3 bnZVVwI/vZZ2HmzE3VUI2H4= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id C71FC6078C068; Sun, 9 May 2010 22:36:37 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqfHAqlNgjih; Sun, 9 May 2010 22:36:36 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id DDC25607AB660; Sun, 9 May 2010 22:36:36 +0100 (IST) Received: from adsl-71-141-115-202.dsl.snfc21.pacbell.net (adsl-71-141-115-202.dsl.snfc21.pacbell.net [71.141.115.202]) by mail.skype.net (Horde Framework) with HTTP; Sun, 09 May 2010 14:36:36 -0700 Message-ID: <20100509143636.21296os5ryogl1ic@mail.skype.net> Date: Sun, 09 May 2010 14:36:36 -0700 From: Koen Vos To: "Raymond (Juin-Hwey) Chen" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> <20100507144856.171013mxhy3wdfbc@mail.skype.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 21:36:51 -0000 Hi Raymond, I can still only come to one conclusion: For typical VoIP applications, Moore's law has lessened the pressure to reduce bitrates, delay and complexity, and has shifted the focus to fidelity instead. This trend is also visible in recent ITU-T standards like G.718, G.719 and G.729.1. Some exceptions to the rule may exist, but, like ITU-T, we don't need to cover every imaginable use case in one standard. All in all I'm happy with the current requirements document, and it's unclear what specific changes (besides a Bluetooth mode) you have in mind...? best, koen. Quoting "Raymond (Juin-Hwey) Chen" : > Hi Koen, > >>> I wouldn't be surprised if the total VoIP users worldwide exceed 100M, >>> probably significantly. > >> Correct, Skype alone has > 100M active users... > > [Raymond]: I knew Skype has hundreds of millions of subscribers. My > comment above was specifically referring to the non-computer-based > VoIP subscribers where a physical telephone set is involved in a > VoIP phone call. Sorry for not making it clear. > >>> Most of these are still narrowband. > >> No: super-wideband. > > [Raymond]: See my comment above. For those VoIP phone calls that > involve at least a physical telephone set, most of them are still > narrowband calls today. I trust that what you said (super-wideband) > must be correct for computer-to-computer calls since Skype dominates > that market there and you know that market better than I do, but I > am talking about something totally different here. > >> Are IP phones that come on the market today still using only >> narrowband? That must be a quickly reducing segment, no? > > [Raymond]: Many enterprise IP phones shipped today indeed have > wideband (16 kHz) capabilities. However, a lot of enterprises may > still configure them to do only narrowband calls. Even if some > enterprises do enable wideband calls on these phones, wideband calls > are typically only available for IP-phone-to-IP-phone calls between > IP phones in their own corporate network. The moment an employee > dial out of the corporate network, it's essentially all narrowband. > > There are some wideband cell phone trials in Europe. However, when > I spoke to a veteran in the cell phone industry, his assessment was > that the up-take on wideband cell phones would be pretty slow, and > the narrowband cell phones would be here to stay for a VERY, VERY > long time. He said even today we still have to support the very > first digital cellular standard codec, the 13 kb/s GSM Full-Rate > codec, about 20 years after it came out. His point was that > narrowband cell phones would not go away for a long, long time. I > guess similar things can be said for narrowband land-line > telephones. > >> I do agree that "we shouldn't completely ignore narrowband." > > [Raymond]: Glad that we have an agreement here :o) > Have a good weekend. > > > From bmschwar@fas.harvard.edu Sun May 9 14:52:36 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56DE53A6A7A for ; Sun, 9 May 2010 14:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-3.600, BAYES_50=0.001, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IaImEisyNJS for ; Sun, 9 May 2010 14:52:35 -0700 (PDT) Received: from smtpx1.unix.fas.harvard.edu (smtpx1.unix.fas.harvard.edu [140.247.34.254]) by core3.amsl.com (Postfix) with ESMTP id 7DB823A6A6F for ; Sun, 9 May 2010 14:52:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpx1.unix.fas.harvard.edu (Postfix) with ESMTP id 857AC17CAA; Sun, 9 May 2010 17:52:23 -0400 (EDT) X-Amavis-Alert: BAD HEADER SECTION, Header line longer than 998 characters: References: <06... Received: from us41.unix.fas.harvard.edu (us41.unix.fas.harvard.edu [140.247.35.232]) by smtpx1.unix.fas.harvard.edu (Postfix) with ESMTP; Sun, 9 May 2010 17:52:19 -0400 (EDT) Received: from c-71-192-160-188.hsd1.nh.comcast.net (c-71-192-160-188.hsd1.nh.comcast.net [71.192.160.188]) by webmail.fas.harvard.edu (IMP) with HTTP for ; Sun, 9 May 2010 17:52:19 -0400 Message-ID: <1273441939.4be72e937fdf5@webmail.fas.harvard.edu> Date: Sun, 9 May 2010 17:52:19 -0400 From: "Benjamin M. Schwartz" To: Koen Vos References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.5 X-Originating-IP: 71.192.160.188 Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bens@alum.mit.edu List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 21:52:36 -0000 Quoting Koen Vos : > For typical VoIP applications, Moore's law has lessened the pressure > to reduce bitrates, delay and complexity, and has shifted the focus to > fidelity instead. I think this is a typo, and you mean "lessened the pressure to reduce bitrates and complexity, and has shifted the focus to fidelity and delay instead". > All in all I'm happy with the current requirements document, and it's > unclear what specific changes (besides a Bluetooth mode) you have in > mind...? Me too; I'd also like some clarification as to whether we're talking about (a) existing Bluetooth headsets or (b) future hardware designed to support the IWAC. If (b), then this is just a matter of negotiating the acceptable encode+decode complexity, for eventual implementation by DSP or ASIC. If (a) ... I'm surprised that such a retrofit is even conceivable. If it is in fact possible, I would very much appreciate instructions on how to experiment with new codecs on existing headsets. Once we know how to build test rigs, we can see what the complexity requirement there is. If we can't test it, I don't think we can target it. --Ben From rchen@broadcom.com Mon May 10 12:08:01 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 153DA28C311 for ; Mon, 10 May 2010 12:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.172 X-Spam-Level: X-Spam-Status: No, score=0.172 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_50=0.001, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvCcekaLkWEb for ; Mon, 10 May 2010 12:08:00 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id DCB4128C355 for ; Mon, 10 May 2010 12:00:19 -0700 (PDT) Received: from [10.9.200.131] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 10 May 2010 11:59:55 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Mon, 10 May 2010 11:59:55 -0700 From: "Raymond (Juin-Hwey) Chen" To: "bens@alum.mit.edu" , "Koen Vos" Date: Mon, 10 May 2010 11:59:54 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: Acrvweu7X98uXAVhT2uRwBDUSypKvwAsEEFA Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> In-Reply-To: <1273441939.4be72e937fdf5@webmail.fas.harvard.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67F6882120S120580362-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 19:08:01 -0000 Hi Ben, > I think this is a typo, and you mean "lessened the pressure to reduce bit= rates > and complexity, and has shifted the focus to fidelity and delay instead". [Raymond]: I agree with you here. >> All in all I'm happy with the current requirements document, and it's >> unclear what specific changes (besides a Bluetooth mode) you have in >> mind...? > Me too; I'd also like some clarification as to whether we're talking abou= t (a) > existing Bluetooth headsets or (b) future hardware designed to supp= ort the > IWAC. If (b), then this is just a matter of negotiating the acceptable > encode+decode complexity, for eventual implementation by DSP or ASIC. If= (a) > ... I'm surprised that such a retrofit is even conceivable. If it is in = fact > possible, I would very much appreciate instructions on how to experiment = with > new codecs on existing headsets. Once we know how to build test rigs, we= can > see what the complexity requirement there is. If we can't test it, I don= 't > think we can target it. [Raymond]: I was definitely talking about (b), not (a). From rchen@broadcom.com Mon May 10 12:27:27 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2C4B28C3B7 for ; Mon, 10 May 2010 12:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.113 X-Spam-Level: X-Spam-Status: No, score=-0.113 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uteFLUajWgrW for ; Mon, 10 May 2010 12:27:26 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 15ABF28C1F3 for ; Mon, 10 May 2010 12:11:55 -0700 (PDT) Received: from [10.9.200.133] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 10 May 2010 12:11:33 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Mon, 10 May 2010 12:12:56 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Koen Vos" Date: Mon, 10 May 2010 12:11:32 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: Acrvv780XCFpA/L3T9e9ynvyOmGX6gAsFXmw Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> <20100507144856.171013mxhy3wdfbc@mail.skype.net> <20100509143636.21296os5ryogl1ic@mail.skype.net> In-Reply-To: <20100509143636.21296os5ryogl1ic@mail.skype.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67F685EF38O203136089-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 19:27:27 -0000 Hi Koen, > All in all I'm happy with the current requirements document, and it's =20 > unclear what specific changes (besides a Bluetooth mode) you have in =20 > mind...? [Raymond]: Correction: I never argued that we should add a "Bluetooth mode". My main = point in this area is just that there are complexity-sensitive applications= such as low-end devices and VoIP gateways where a low codec complexity is = important or even necessary. In other words, if the IETF codec complexity = is too high, then either it will become much more expensive for some applic= ations (e.g. gateways), or it may not even be feasible to put the codec in = some low-end devices. Bluetooth headset was merely given as an example. =20 Considering that there are a very large number of Bluetooth headset users a= nd that the current Bluetooth headsets can already be used for making VoIP = phone calls, it would be great if the IETF codec can be implemented in futu= re Bluetooth headsets to avoid the additional coding distortion and delay a= ssociated with transcoding. However, with that said, I didn't mean to push = a "Bluetooth mode" for the IETF codec. I merely wanted to use Bluetooth hea= dset as an example to make a point that a low codec complexity is desirable= and a high codec complexity can have negative consequences. Raymond From kpfleming@digium.com Mon May 10 12:44:05 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 103AF3A6D45 for ; Mon, 10 May 2010 12:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.273 X-Spam-Level: X-Spam-Status: No, score=-104.273 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYO9suDFxaCq for ; Mon, 10 May 2010 12:44:03 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 3340128C272 for ; Mon, 10 May 2010 12:32:52 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1OBYiW-0003xM-IY for codec@ietf.org; Mon, 10 May 2010 14:32:40 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 8D531D8024 for ; Mon, 10 May 2010 14:32:40 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jJE9ETKdtuS for ; Mon, 10 May 2010 14:32:40 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 17275D8023 for ; Mon, 10 May 2010 14:32:40 -0500 (CDT) Message-ID: <4BE85F57.9040205@digium.com> Date: Mon, 10 May 2010 14:32:39 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: codec@ietf.org References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> <20100507144856.171013mxhy3wdfbc@mail.skype.net> <20100509143636.21296os5ryogl1ic@mail.skype.net> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 19:44:05 -0000 On 05/10/2010 02:11 PM, Raymond (Juin-Hwey) Chen wrote: > Considering that there are a very large number of Bluetooth headset users and that the current Bluetooth headsets can already be used for making VoIP phone calls, it would be great if the IETF codec can be implemented in future Bluetooth headsets to avoid the additional coding distortion and delay associated with transcoding. However, with that said, I didn't mean to push a "Bluetooth mode" for the IETF codec. I merely wanted to use Bluetooth headset as an example to make a point that a low codec complexity is desirable and a high codec complexity can have negative consequences. This is all perfectly reasonable, but given the likely timeframe we are talking about for this codec to be produced and published as a standards-track RFC, the definition of 'low complexity' in this discussion is really talking about the 2012-2013 version of 'low complexity', not today's. It seems highly likely that the MIPS capacity of the DSPs designed into Bluetooth headsets in 2012 will be vastly greater than what is used today, if there is an application to take advantage of the additional MIPS. I'd hate to see this codec's development constrained in any significant way by the requirements of a low-complexity device designed in 2009 or earlier. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From rchen@broadcom.com Mon May 10 13:07:00 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C299C3A69AA for ; Mon, 10 May 2010 13:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.109 X-Spam-Level: X-Spam-Status: No, score=-0.109 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5XSbjkO7iiR for ; Mon, 10 May 2010 13:06:59 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 2333E3A6A94 for ; Mon, 10 May 2010 12:58:12 -0700 (PDT) Received: from [10.9.200.131] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 10 May 2010 12:57:53 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Mon, 10 May 2010 12:57:53 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Christian Hoene" , "codec@ietf.org" Date: Mon, 10 May 2010 12:57:51 -0700 Thread-Topic: [codec] this weeks summary Thread-Index: AcrvouSxwCvhij/GQOaYD+wavcY/SwA0ddGw Message-ID: References: <002e01caefa2$ef88c9a0$ce9a5ce0$@de> In-Reply-To: <002e01caefa2$ef88c9a0$ce9a5ce0$@de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67F6BACB20S120629110-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [codec] this weeks summary X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 20:07:00 -0000 Hi Christian, > Raymond did a great job explaining the special requirements of high-densi= ty=20 > VoIP gateway. They are differ substantially to those of > soft-phones (but are somewhat similar to VoIP phones with embedded CPUs).= The=20 > requirements include low memory footprint, ultra-low > delay, low complexity and mostly narrow band. But aren't those requiremen= ts=20 > already covered by existing codecs? Shall this working > group provide a codec profile for end-to-gateway beside the profile for a= n=20 > end-to-end codec? [Raymond]: Which existing codecs satisfy all these requirements and the three conditions listed at the beginning of the IETF=20 codec WG charter? Also, we are not talking about an additional codec=20 profile for "end-to-gateway"; no, what we are talking about is just part of= =20 the "IPend-to-transcoding_gateway-to-PSTNend" scenario that you listed in=20 one of your original emails that discussed the codec requirements. > SpiritDSP and Christian were discussing the need for layered coding - no= =20 > consensus yet... [Raymond]: I think layered coding (or embedded coding) is a nice feature to= =20 have. Some of the other SDOs have standardized layered codecs. Besides=20 the pros and cons of layered coding already discussed last week, I think=20 another potential benefit is that as the packets of layer-coded bit-stream= =20 traverse the network, higher-layer bits can be stripped off by network=20 nodes to reduce congestion. (This is probably not done, but can be done.) > The week before, we were discussing whether to consider Bluetooth and Wir= eless=20 > IP as use cases. It seems to be a rough consensus > that wireless IP is in-scope and that Bluetooth is out-of-scope because i= t > requires too special optimizations. However, battery > powered, wireless devices might require low-complexity and low-bandwidth = (and=20 > are in-scope?). [Raymond]: I read an article that says that PC was the big thing in=20 the decade of 1990-2000, Internet was the big thing in the decade of 2000- 2010, and Mobile Internet will be the next big thing in the decade of 2010- 2020. Judging from the recent trends in smart phones, netbooks, and=20 Tablets/iPad, it seems that Mobile Internet indeed will be the next big=20 thing this decade. Given this, I think battery-powered wireless Internet- capable devices should be in-scope, and low codec complexity is an=20 important consideration in these devices. From rchen@broadcom.com Mon May 10 13:35:07 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFCD63A6964 for ; Mon, 10 May 2010 13:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UiyKOk5hxGd for ; Mon, 10 May 2010 13:35:06 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 2D3E63A6C3A for ; Mon, 10 May 2010 13:26:25 -0700 (PDT) Received: from [10.9.200.131] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 10 May 2010 13:26:00 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Mon, 10 May 2010 13:26:00 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Kevin P. Fleming" , "codec@ietf.org" Date: Mon, 10 May 2010 13:25:59 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcrweSYx81GgbVfnTFaPGSA5qPSCxQAAhvrw Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> <20100507144856.171013mxhy3wdfbc@mail.skype.net> <20100509143636.21296os5ryogl1ic@mail.skype.net> <4BE85F57.9040205@digium.com> In-Reply-To: <4BE85F57.9040205@digium.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67F6B45220S120652012-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 20:35:08 -0000 Hi Kevin, I completely agree with you that the IETF codec development should not=20 be constrained by a low-complexity device designed in 2009 or earlier,=20 and we should look toward the time frame of 2012 and 2013 instead. =20 In my previous emails I have indicated that due to many reasons, over=20 the last several years the processing power of Bluetooth headsets has=20 been increasing at a rate much slower than what's predicted by Moore's=20 Law, and it doesn't look like this will change significantly in the next=20 few years. I also said that for the current-generation Bluetooth=20 headset chips, the maximum codec complexity it can support is probably=20 somewhere around 5 MIPS on a 16-bit fixed-point DSP, and by the time the=20 IETF codec becomes a standard, the number may go up to 10 MIPS, or 15=20 MIPS at most. =20 Thus, if we want mono Bluetooth headsets in the FUTURE (i.e. in the next=20 several years) to be able to run the IETF codec in the narrowband or=20 wideband mode at least, a good complexity target to shoot for is 10 to=20 20 MIPS on a fixed-point DSP. Raymond -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of K= evin P. Fleming Sent: Monday, May 10, 2010 12:33 PM To: codec@ietf.org Subject: Re: [codec] #16: Multicast? On 05/10/2010 02:11 PM, Raymond (Juin-Hwey) Chen wrote: > Considering that there are a very large number of Bluetooth headset users= and that the current Bluetooth headsets can already be used for making VoI= P phone calls, it would be great if the IETF codec can be implemented in fu= ture Bluetooth headsets to avoid the additional coding distortion and delay= associated with transcoding. However, with that said, I didn't mean to pus= h a "Bluetooth mode" for the IETF codec. I merely wanted to use Bluetooth h= eadset as an example to make a point that a low codec complexity is desirab= le and a high codec complexity can have negative consequences. This is all perfectly reasonable, but given the likely timeframe we are talking about for this codec to be produced and published as a standards-track RFC, the definition of 'low complexity' in this discussion is really talking about the 2012-2013 version of 'low complexity', not today's. It seems highly likely that the MIPS capacity of the DSPs designed into Bluetooth headsets in 2012 will be vastly greater than what is used today, if there is an application to take advantage of the additional MIPS. I'd hate to see this codec's development constrained in any significant way by the requirements of a low-complexity device designed in 2009 or earlier. --=20 Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From jean-marc.valin@octasic.com Mon May 10 13:54:05 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B5AA3A69FC for ; Mon, 10 May 2010 13:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syAV-pvbwdyN for ; Mon, 10 May 2010 13:54:04 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 5C91E3A6CA6 for ; Mon, 10 May 2010 13:49:53 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 May 2010 16:49:41 -0400 Message-ID: <4BE87165.2030401@octasic.com> Date: Mon, 10 May 2010 16:49:41 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "Raymond (Juin-Hwey) Chen" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> <20100507144856.171013mxhy3wdfbc@mail.skype.net> <20100509143636.21296os5ryogl1ic@mail.skype.net> <4BE85F57.9040205@digium.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 May 2010 20:49:41.0953 (UTC) FILETIME=[5071CB10:01CAF082] Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 20:54:05 -0000 Hi Raymond, I'm just curious about where you got your MIPS figures for Bluetooth? I'm not familiar with the type of DSPs used in those applications, but from a quick search of more "general-purpose" DSPs (TI, ADI and similar), the lowest speed I was able to find (sold in 2010) was a 50 MIPS DSP. Any idea what type of DSPs are currently used in Bluetooth? Cheers, Jean-Marc Raymond (Juin-Hwey) Chen wrote: > Hi Kevin, > > I completely agree with you that the IETF codec development should not > be constrained by a low-complexity device designed in 2009 or earlier, > and we should look toward the time frame of 2012 and 2013 instead. > > In my previous emails I have indicated that due to many reasons, over > the last several years the processing power of Bluetooth headsets has > been increasing at a rate much slower than what's predicted by Moore's > Law, and it doesn't look like this will change significantly in the next > few years. I also said that for the current-generation Bluetooth > headset chips, the maximum codec complexity it can support is probably > somewhere around 5 MIPS on a 16-bit fixed-point DSP, and by the time the > IETF codec becomes a standard, the number may go up to 10 MIPS, or 15 > MIPS at most. > > Thus, if we want mono Bluetooth headsets in the FUTURE (i.e. in the next > several years) to be able to run the IETF codec in the narrowband or > wideband mode at least, a good complexity target to shoot for is 10 to > 20 MIPS on a fixed-point DSP. > > Raymond > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Kevin P. Fleming > Sent: Monday, May 10, 2010 12:33 PM > To: codec@ietf.org > Subject: Re: [codec] #16: Multicast? > > On 05/10/2010 02:11 PM, Raymond (Juin-Hwey) Chen wrote: > >> Considering that there are a very large number of Bluetooth headset users and that the current Bluetooth headsets can already be used for making VoIP phone calls, it would be great if the IETF codec can be implemented in future Bluetooth headsets to avoid the additional coding distortion and delay associated with transcoding. However, with that said, I didn't mean to push a "Bluetooth mode" for the IETF codec. I merely wanted to use Bluetooth headset as an example to make a point that a low codec complexity is desirable and a high codec complexity can have negative consequences. > > This is all perfectly reasonable, but given the likely timeframe we are > talking about for this codec to be produced and published as a > standards-track RFC, the definition of 'low complexity' in this > discussion is really talking about the 2012-2013 version of 'low > complexity', not today's. It seems highly likely that the MIPS capacity > of the DSPs designed into Bluetooth headsets in 2012 will be vastly > greater than what is used today, if there is an application to take > advantage of the additional MIPS. > > I'd hate to see this codec's development constrained in any significant > way by the requirements of a low-complexity device designed in 2009 or > earlier. > > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > skype: kpfleming | jabber: kfleming@digium.com > Check us out at www.digium.com & www.asterisk.org > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From rchen@broadcom.com Mon May 10 14:27:21 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B83E3A6A5D for ; Mon, 10 May 2010 14:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.405 X-Spam-Level: X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[AWL=1.194, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wy2DotGnPOJ for ; Mon, 10 May 2010 14:27:19 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 105513A6AAF for ; Mon, 10 May 2010 14:24:24 -0700 (PDT) Received: from [10.9.200.131] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 10 May 2010 14:24:03 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Mon, 10 May 2010 14:24:03 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Kevin P. Fleming" , "codec@ietf.org" Date: Mon, 10 May 2010 14:24:02 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcrweSYx81GgbVfnTFaPGSA5qPSCxQAAhvrwAAGTgCA= Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> <20100507144856.171013mxhy3wdfbc@mail.skype.net> <20100509143636.21296os5ryogl1ic@mail.skype.net> <4BE85F57.9040205@digium.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67F6A6F920S120701563-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 21:27:21 -0000 I should have clarified: I am not proposing that we limit the complexity of all IETF codec modes=20 to 10 to 20 MIPS. That would be unreasonable, especially for high- sampling-rate and high-fidelity applications.=20 Just like we seemed to have reached a consensus that a low-delay mode=20 is necessary to address delay-sensitive applications (as is specified=20 in the codec requirement document), we can also have a low-complexity=20 mode to address complexity-sensitive applications such as low- end/mobile devices and gateways. It is for such a low-complexity mode=20 that 10 - 20 MIPS is a good target to shoot for, at least for=20 narrowband and wideband. (Super-wideband and full-band can be layered=20 coding on top of that and do not need to be subject to this 10 - 20=20 MIPS target.) For other coding modes that require more processing=20 power, this 10 - 20 MIPS target obviously would not apply. Also, if we don't like to have too many different coding modes, and if=20 some modes can be combined, for example, if the low-delay mode can also=20 achieve low complexity, then we can combine the low-delay mode and the=20 low-complexity mode into a single mode. We can have another mode=20 that's more efficient in bit-rate but may have higher delay and=20 complexity to address those applications that are less sensitive=20 to delay and complexity. Raymond -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of R= aymond (Juin-Hwey) Chen Sent: Monday, May 10, 2010 1:26 PM To: Kevin P. Fleming; codec@ietf.org Subject: Re: [codec] #16: Multicast? Hi Kevin, I completely agree with you that the IETF codec development should not=20 be constrained by a low-complexity device designed in 2009 or earlier,=20 and we should look toward the time frame of 2012 and 2013 instead. =20 In my previous emails I have indicated that due to many reasons, over=20 the last several years the processing power of Bluetooth headsets has=20 been increasing at a rate much slower than what's predicted by Moore's=20 Law, and it doesn't look like this will change significantly in the next=20 few years. I also said that for the current-generation Bluetooth=20 headset chips, the maximum codec complexity it can support is probably=20 somewhere around 5 MIPS on a 16-bit fixed-point DSP, and by the time the=20 IETF codec becomes a standard, the number may go up to 10 MIPS, or 15=20 MIPS at most. =20 Thus, if we want mono Bluetooth headsets in the FUTURE (i.e. in the next=20 several years) to be able to run the IETF codec in the narrowband or=20 wideband mode at least, a good complexity target to shoot for is 10 to=20 20 MIPS on a fixed-point DSP. Raymond -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of K= evin P. Fleming Sent: Monday, May 10, 2010 12:33 PM To: codec@ietf.org Subject: Re: [codec] #16: Multicast? On 05/10/2010 02:11 PM, Raymond (Juin-Hwey) Chen wrote: > Considering that there are a very large number of Bluetooth headset users= and that the current Bluetooth headsets can already be used for making VoI= P phone calls, it would be great if the IETF codec can be implemented in fu= ture Bluetooth headsets to avoid the additional coding distortion and delay= associated with transcoding. However, with that said, I didn't mean to pus= h a "Bluetooth mode" for the IETF codec. I merely wanted to use Bluetooth h= eadset as an example to make a point that a low codec complexity is desirab= le and a high codec complexity can have negative consequences. This is all perfectly reasonable, but given the likely timeframe we are talking about for this codec to be produced and published as a standards-track RFC, the definition of 'low complexity' in this discussion is really talking about the 2012-2013 version of 'low complexity', not today's. It seems highly likely that the MIPS capacity of the DSPs designed into Bluetooth headsets in 2012 will be vastly greater than what is used today, if there is an application to take advantage of the additional MIPS. I'd hate to see this codec's development constrained in any significant way by the requirements of a low-complexity device designed in 2009 or earlier. --=20 Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From jean-marc.valin@octasic.com Mon May 10 14:33:17 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36FE73A68C0 for ; Mon, 10 May 2010 14:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRkb3OZkEY3R for ; Mon, 10 May 2010 14:33:15 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 27DF13A6801 for ; Mon, 10 May 2010 14:33:06 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 10 May 2010 17:32:54 -0400 Message-ID: <4BE87B86.2080801@octasic.com> Date: Mon, 10 May 2010 17:32:54 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "Raymond (Juin-Hwey) Chen" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> <20100507144856.171013mxhy3wdfbc@mail.skype.net> <20100509143636.21296os5ryogl1ic@mail.skype.net> <4BE85F57.9040205@digium.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 May 2010 21:32:54.0869 (UTC) FILETIME=[59F16050:01CAF088] Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 21:33:17 -0000 Oh, I realise your original message did not state 10-20 MIPS as the target for all modes. My only questions was about how you came to the 10-20 MIPS figure in the first place. Any DSP vendor(s) roadmap or something? Or what would be the relevant existing DSP for which we could extrapolate future performance? As I said, I'm not too familiar about the DSPs used in Bluetooth because all the regular DSPs I can find are 50 MIPS or above. Jean-Marc Raymond (Juin-Hwey) Chen wrote: > I should have clarified: > I am not proposing that we limit the complexity of all IETF codec modes > to 10 to 20 MIPS. That would be unreasonable, especially for high- > sampling-rate and high-fidelity applications. > > Just like we seemed to have reached a consensus that a low-delay mode > is necessary to address delay-sensitive applications (as is specified > in the codec requirement document), we can also have a low-complexity > mode to address complexity-sensitive applications such as low- > end/mobile devices and gateways. It is for such a low-complexity mode > that 10 - 20 MIPS is a good target to shoot for, at least for > narrowband and wideband. (Super-wideband and full-band can be layered > coding on top of that and do not need to be subject to this 10 - 20 > MIPS target.) For other coding modes that require more processing > power, this 10 - 20 MIPS target obviously would not apply. > > Also, if we don't like to have too many different coding modes, and if > some modes can be combined, for example, if the low-delay mode can also > achieve low complexity, then we can combine the low-delay mode and the > low-complexity mode into a single mode. We can have another mode > that's more efficient in bit-rate but may have higher delay and > complexity to address those applications that are less sensitive > to delay and complexity. > > Raymond > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Raymond (Juin-Hwey) Chen > Sent: Monday, May 10, 2010 1:26 PM > To: Kevin P. Fleming; codec@ietf.org > Subject: Re: [codec] #16: Multicast? > > Hi Kevin, > > I completely agree with you that the IETF codec development should not > be constrained by a low-complexity device designed in 2009 or earlier, > and we should look toward the time frame of 2012 and 2013 instead. > > In my previous emails I have indicated that due to many reasons, over > the last several years the processing power of Bluetooth headsets has > been increasing at a rate much slower than what's predicted by Moore's > Law, and it doesn't look like this will change significantly in the next > few years. I also said that for the current-generation Bluetooth > headset chips, the maximum codec complexity it can support is probably > somewhere around 5 MIPS on a 16-bit fixed-point DSP, and by the time the > IETF codec becomes a standard, the number may go up to 10 MIPS, or 15 > MIPS at most. > > Thus, if we want mono Bluetooth headsets in the FUTURE (i.e. in the next > several years) to be able to run the IETF codec in the narrowband or > wideband mode at least, a good complexity target to shoot for is 10 to > 20 MIPS on a fixed-point DSP. > > Raymond > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Kevin P. Fleming > Sent: Monday, May 10, 2010 12:33 PM > To: codec@ietf.org > Subject: Re: [codec] #16: Multicast? > > On 05/10/2010 02:11 PM, Raymond (Juin-Hwey) Chen wrote: > >> Considering that there are a very large number of Bluetooth headset users and that the current Bluetooth headsets can already be used for making VoIP phone calls, it would be great if the IETF codec can be implemented in future Bluetooth headsets to avoid the additional coding distortion and delay associated with transcoding. However, with that said, I didn't mean to push a "Bluetooth mode" for the IETF codec. I merely wanted to use Bluetooth headset as an example to make a point that a low codec complexity is desirable and a high codec complexity can have negative consequences. > > This is all perfectly reasonable, but given the likely timeframe we are > talking about for this codec to be produced and published as a > standards-track RFC, the definition of 'low complexity' in this > discussion is really talking about the 2012-2013 version of 'low > complexity', not today's. It seems highly likely that the MIPS capacity > of the DSPs designed into Bluetooth headsets in 2012 will be vastly > greater than what is used today, if there is an application to take > advantage of the additional MIPS. > > I'd hate to see this codec's development constrained in any significant > way by the requirements of a low-complexity device designed in 2009 or > earlier. > > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > skype: kpfleming | jabber: kfleming@digium.com > Check us out at www.digium.com & www.asterisk.org > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From rchen@broadcom.com Mon May 10 15:03:27 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 512AF3A6801 for ; Mon, 10 May 2010 15:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.142 X-Spam-Level: X-Spam-Status: No, score=-0.142 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zScKvt650mhk for ; Mon, 10 May 2010 15:03:25 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 33A263A6C1F for ; Mon, 10 May 2010 15:03:25 -0700 (PDT) Received: from [10.9.200.131] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 10 May 2010 15:03:00 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Mon, 10 May 2010 15:03:01 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Jean-Marc Valin" Date: Mon, 10 May 2010 15:02:59 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcrwglZlRdRMon4wRWWDChT4kHf3/QABZ4eg Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> <20100507144856.171013mxhy3wdfbc@mail.skype.net> <20100509143636.21296os5ryogl1ic@mail.skype.net> <4BE85F57.9040205@digium.com> <4BE87165.2030401@octasic.com> In-Reply-To: <4BE87165.2030401@octasic.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67F65D1E31G121278090-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 22:03:27 -0000 Hi Jean-Marc, I didn't just cook up those MIPS numbers out of my head :o) I have been wo= rking with Bluetooth engineers on voice/audio processing for Bluetooth head= sets in the last few years. =20 Bluetooth headsets normally don't use general-purpose DSPs from those tradi= tional DSP houses that you mentioned below. A lot of mid- to low-end Bluet= ooth headsets (where most of the shipping volume is) don't even have any DS= P and instead just rely on an ARM processor to do all voice/audio processin= g and Bluetooth protocol stack. The 5 MIPS number for current-generation B= T headsets was quoted to me by an experienced Bluetooth audio engineering m= anager in terms of MIPS on an ARM processor, but since most speech coding e= ngineers are more familiar with the MIPS for a general-purpose 16-bit fixed= -point DSP, so I converted the MIPS on an ARM to the equivalent MIPS on a f= ixed-point DSP, and it came to around 5 MIPS. The 10 to 20 MIPS number is = what we may expect in a several years as Moore's Law helps to increase the = processing power of Bluetooth headsets. High-end Bluetooth headset chips may have a DSP on-chip, but it is usually = either a proprietary DSP or a DSP core not from the traditional DSP houses = but from companies like ARM. One thing to keep in mind, though, is that even if you have a DSP on a Blue= tooth headset chip, and it is clocked at 50 MHz or higher, it doesn't mean = that you can use all or most of that DSP processing power for speech or aud= io coding. This is because it has to handle many other signal processing t= asks such as acoustic echo canceller, single-mic or multi-mic noise suppres= sion, wind noise suppression, packet loss concealment, voice prompt decodin= g, and even voice command recognition, to name just a few. You can't even = get half of the DSP processing power solely dedicated to speech coding. Yo= u will be lucky if you can get 20% of the DSP for speech coding. Remember = that currently the speech coding part (CVSD codec) takes 0% of the DSP or A= RM because it is done in chip hardware. Raymond -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com]=20 Sent: Monday, May 10, 2010 1:50 PM To: Raymond (Juin-Hwey) Chen Cc: Kevin P. Fleming; codec@ietf.org Subject: Re: [codec] #16: Multicast? Hi Raymond, I'm just curious about where you got your MIPS figures for Bluetooth? I'm=20 not familiar with the type of DSPs used in those applications, but from a=20 quick search of more "general-purpose" DSPs (TI, ADI and similar), the=20 lowest speed I was able to find (sold in 2010) was a 50 MIPS DSP. Any idea= =20 what type of DSPs are currently used in Bluetooth? Cheers, Jean-Marc Raymond (Juin-Hwey) Chen wrote: > Hi Kevin, >=20 > I completely agree with you that the IETF codec development should not > be constrained by a low-complexity device designed in 2009 or earlier, > and we should look toward the time frame of 2012 and 2013 instead. >=20 > In my previous emails I have indicated that due to many reasons, over > the last several years the processing power of Bluetooth headsets has > been increasing at a rate much slower than what's predicted by Moore's > Law, and it doesn't look like this will change significantly in the next > few years. I also said that for the current-generation Bluetooth > headset chips, the maximum codec complexity it can support is probably > somewhere around 5 MIPS on a 16-bit fixed-point DSP, and by the time the > IETF codec becomes a standard, the number may go up to 10 MIPS, or 15 > MIPS at most. >=20 > Thus, if we want mono Bluetooth headsets in the FUTURE (i.e. in the next > several years) to be able to run the IETF codec in the narrowband or > wideband mode at least, a good complexity target to shoot for is 10 to > 20 MIPS on a fixed-point DSP. >=20 > Raymond >=20 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of= Kevin P. Fleming > Sent: Monday, May 10, 2010 12:33 PM > To: codec@ietf.org > Subject: Re: [codec] #16: Multicast? >=20 > On 05/10/2010 02:11 PM, Raymond (Juin-Hwey) Chen wrote: >=20 >> Considering that there are a very large number of Bluetooth headset user= s and that the current Bluetooth headsets can already be used for making Vo= IP phone calls, it would be great if the IETF codec can be implemented in f= uture Bluetooth headsets to avoid the additional coding distortion and dela= y associated with transcoding. However, with that said, I didn't mean to pu= sh a "Bluetooth mode" for the IETF codec. I merely wanted to use Bluetooth = headset as an example to make a point that a low codec complexity is desira= ble and a high codec complexity can have negative consequences. >=20 > This is all perfectly reasonable, but given the likely timeframe we are > talking about for this codec to be produced and published as a > standards-track RFC, the definition of 'low complexity' in this > discussion is really talking about the 2012-2013 version of 'low > complexity', not today's. It seems highly likely that the MIPS capacity > of the DSPs designed into Bluetooth headsets in 2012 will be vastly > greater than what is used today, if there is an application to take > advantage of the additional MIPS. >=20 > I'd hate to see this codec's development constrained in any significant > way by the requirements of a low-complexity device designed in 2009 or > earlier. >=20 > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > skype: kpfleming | jabber: kfleming@digium.com > Check us out at www.digium.com & www.asterisk.org > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From rchen@broadcom.com Mon May 10 15:06:33 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 332893A6767 for ; Mon, 10 May 2010 15:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.438 X-Spam-Level: X-Spam-Status: No, score=-1.438 tagged_above=-999 required=5 tests=[AWL=1.161, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6U2aJnoTfdOc for ; Mon, 10 May 2010 15:06:31 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 41FEE3A6800 for ; Mon, 10 May 2010 15:06:30 -0700 (PDT) Received: from [10.9.200.133] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 10 May 2010 15:06:02 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Mon, 10 May 2010 15:07:25 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Jean-Marc Valin" Date: Mon, 10 May 2010 15:06:01 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcrwiGUjWbDe5NOHQqG6jJ5k6VuV9wABDfOQ Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> <20100507144856.171013mxhy3wdfbc@mail.skype.net> <20100509143636.21296os5ryogl1ic@mail.skype.net> <4BE85F57.9040205@digium.com> <4BE87B86.2080801@octasic.com> In-Reply-To: <4BE87B86.2080801@octasic.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67F65CC020S120734540-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 22:06:33 -0000 Hi Jean-Marc, My email below was meant to be an additional note to my previous email and = not as a reply to your first email today. Sorry for the confusion. =20 I hope my last email has answered your questions. Best Regards, Raymond -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com]=20 Sent: Monday, May 10, 2010 2:33 PM To: Raymond (Juin-Hwey) Chen Cc: Kevin P. Fleming; codec@ietf.org Subject: Re: [codec] #16: Multicast? Oh, I realise your original message did not state 10-20 MIPS as the target= =20 for all modes. My only questions was about how you came to the 10-20 MIPS=20 figure in the first place. Any DSP vendor(s) roadmap or something? Or what= =20 would be the relevant existing DSP for which we could extrapolate future=20 performance? As I said, I'm not too familiar about the DSPs used in=20 Bluetooth because all the regular DSPs I can find are 50 MIPS or above. Jean-Marc Raymond (Juin-Hwey) Chen wrote: > I should have clarified: > I am not proposing that we limit the complexity of all IETF codec modes > to 10 to 20 MIPS. That would be unreasonable, especially for high- > sampling-rate and high-fidelity applications. >=20 > Just like we seemed to have reached a consensus that a low-delay mode > is necessary to address delay-sensitive applications (as is specified > in the codec requirement document), we can also have a low-complexity > mode to address complexity-sensitive applications such as low- > end/mobile devices and gateways. It is for such a low-complexity mode > that 10 - 20 MIPS is a good target to shoot for, at least for > narrowband and wideband. (Super-wideband and full-band can be layered > coding on top of that and do not need to be subject to this 10 - 20 > MIPS target.) For other coding modes that require more processing > power, this 10 - 20 MIPS target obviously would not apply. >=20 > Also, if we don't like to have too many different coding modes, and if > some modes can be combined, for example, if the low-delay mode can also > achieve low complexity, then we can combine the low-delay mode and the > low-complexity mode into a single mode. We can have another mode > that's more efficient in bit-rate but may have higher delay and > complexity to address those applications that are less sensitive > to delay and complexity. >=20 > Raymond >=20 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of= Raymond (Juin-Hwey) Chen > Sent: Monday, May 10, 2010 1:26 PM > To: Kevin P. Fleming; codec@ietf.org > Subject: Re: [codec] #16: Multicast? >=20 > Hi Kevin, >=20 > I completely agree with you that the IETF codec development should not > be constrained by a low-complexity device designed in 2009 or earlier, > and we should look toward the time frame of 2012 and 2013 instead. >=20 > In my previous emails I have indicated that due to many reasons, over > the last several years the processing power of Bluetooth headsets has > been increasing at a rate much slower than what's predicted by Moore's > Law, and it doesn't look like this will change significantly in the next > few years. I also said that for the current-generation Bluetooth > headset chips, the maximum codec complexity it can support is probably > somewhere around 5 MIPS on a 16-bit fixed-point DSP, and by the time the > IETF codec becomes a standard, the number may go up to 10 MIPS, or 15 > MIPS at most. >=20 > Thus, if we want mono Bluetooth headsets in the FUTURE (i.e. in the next > several years) to be able to run the IETF codec in the narrowband or > wideband mode at least, a good complexity target to shoot for is 10 to > 20 MIPS on a fixed-point DSP. >=20 > Raymond >=20 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of= Kevin P. Fleming > Sent: Monday, May 10, 2010 12:33 PM > To: codec@ietf.org > Subject: Re: [codec] #16: Multicast? >=20 > On 05/10/2010 02:11 PM, Raymond (Juin-Hwey) Chen wrote: >=20 >> Considering that there are a very large number of Bluetooth headset user= s and that the current Bluetooth headsets can already be used for making Vo= IP phone calls, it would be great if the IETF codec can be implemented in f= uture Bluetooth headsets to avoid the additional coding distortion and dela= y associated with transcoding. However, with that said, I didn't mean to pu= sh a "Bluetooth mode" for the IETF codec. I merely wanted to use Bluetooth = headset as an example to make a point that a low codec complexity is desira= ble and a high codec complexity can have negative consequences. >=20 > This is all perfectly reasonable, but given the likely timeframe we are > talking about for this codec to be produced and published as a > standards-track RFC, the definition of 'low complexity' in this > discussion is really talking about the 2012-2013 version of 'low > complexity', not today's. It seems highly likely that the MIPS capacity > of the DSPs designed into Bluetooth headsets in 2012 will be vastly > greater than what is used today, if there is an application to take > advantage of the additional MIPS. >=20 > I'd hate to see this codec's development constrained in any significant > way by the requirements of a low-complexity device designed in 2009 or > earlier. >=20 > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > skype: kpfleming | jabber: kfleming@digium.com > Check us out at www.digium.com & www.asterisk.org > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From rchen@broadcom.com Mon May 10 18:16:52 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3178F3A6AB9 for ; Mon, 10 May 2010 18:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.172 X-Spam-Level: X-Spam-Status: No, score=-0.172 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quReFQ-T-Uxt for ; Mon, 10 May 2010 18:16:51 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 416903A67AF for ; Mon, 10 May 2010 18:16:51 -0700 (PDT) Received: from [10.9.200.133] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 10 May 2010 18:16:28 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Mon, 10 May 2010 18:17:51 -0700 From: "Raymond (Juin-Hwey) Chen" To: "codec@ietf.org" , "hoene@uni-tuebingen.de" Date: Mon, 10 May 2010 18:16:26 -0700 Thread-Topic: [codec] #14: VAD and CNG? Thread-Index: AcrqEP1L4yhHB3lyQwyufxmCXZX+UwGkcRfw Message-ID: References: <062.0a0a8ad9a1d9d19f0f66b4858f523549@tools.ietf.org> <071.e9aae5bb5ab172d79d732c721371a6c6@tools.ietf.org> In-Reply-To: <071.e9aae5bb5ab172d79d732c721371a6c6@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67F6706620S120860434-01-01 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Subject: Re: [codec] #14: VAD and CNG? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 01:16:52 -0000 SGkgQ2hyaXN0aWFuLA0KDQpJIHRoaW5rIGNvbWZvcnQgbm9pc2UgaXMgbW9yZSB0aGFuIGp1c3Qg dG8gbGV0IHRoZSB0ZWxlcGhvbmUgdXNlciBrbm93IHRoYXQgdGhlIGNvbm5lY3Rpb24gaXMgbm90 IGRlYWQuICBJZiB2b2ljZSBwYWNrZXRzIGFyZSBzZW50IG9ubHkgZHVyaW5nIGFjdGl2ZSB2b2lj ZSByZWdpb25zIG9mIHRoZSBzaWduYWwgKGluIERUWCkgYW5kIG5vdCBkdXJpbmcgc2lsZW5jZS9i YWNrZ3JvdW5kIG5vaXNlIHJlZ2lvbnMsIGFuZCBpZiB0aGVyZSBpcyBhdWRpYmxlIGJhY2tncm91 bmQgbm9pc2UgYW5kIGNvbWZvcnQgbm9pc2UgaXMgbm90IGFkZGVkIGR1cmluZyBiYWNrZ3JvdW5k IG5vaXNlIHJlZ2lvbnMsIGF0IHRoZSByZWNlaXZpbmcgZW5kIHRoZSBiYWNrZ3JvdW5kIG5vaXNl IHdpbGwgYmUgIm9uIiBvbmx5IGR1cmluZyBhY3RpdmUgdm9pY2UgYW5kICJvZmYiIG90aGVyd2lz ZS4gIFRoaXMgZnJlcXVlbnQgb24tb2ZmIHN3aXRjaGluZyB3aWxsIG1ha2UgdGhlIGJhY2tncm91 bmQgbm9pc2Ugc291bmQgdW5uYXR1cmFsIGFuZCB3aWxsIGJvdGhlciBtYW55IHVzZXJzLiAgQWRk aW5nIGNvbWZvcnQgbm9pc2UgZHVyaW5nIGJhY2tncm91bmQgbm9pc2UgcmVnaW9ucyB3aWxsIG1h a2Ugc3VjaCBiYWNrZ3JvdW5kIG5vaXNlIHNvdW5kIG1vcmUgbmF0dXJhbC4NCg0KT2YgY291cnNl LCB0aGlzIHdvcmtzIHdlbGwgb25seSBpZiB0aGUgYmFja2dyb3VuZCBub2lzZSBpcyByZWxhdGl2 ZWx5IHN0YXRpb25hcnkuICBJZiB0aGUgYmFja2dyb3VuZCBub2lzZSBpcyBkeW5hbWljYWxseSBj aGFuZ2luZywgdGhlbiBjb21mb3J0IG5vaXNlIGNhbid0IHJlYWxseSBzb3VuZCBsaWtlIHRoZSB0 cnVlIGJhY2tncm91bmQgbm9pc2UuICBUb2RheSBJIHdhcyBwdXQgb24gaG9sZCBpbiBhIHBob25l IGNhbGwgd2l0aCBtdXNpYyBwbGF5aW5nLiAgQXBwYXJlbnRseSB0aGUgc3lzdGVtIHRyZWF0ZWQg c29tZSBwYXJ0cyBvZiB0aGUgbXVzaWMgYXMgYmFja2dyb3VuZCBub2lzZSBhbmQgcmVwbGFjZWQg dGhlbSB3aXRoIGNvbWZvcnQgbm9pc2UuIFRoZSByZXN1bHQgaXMgcHJldHR5IGFubm95aW5nLCBv ciBhbXVzaW5nLCBkZXBlbmRpbmcgb24gd2hpY2ggd2F5IHlvdSBsb29rIGF0IGl0Lg0KDQpUaGVy ZWZvcmUsIEkgdGhpbmsgY29tZm9ydCBub2lzZSBoYXMgaXRzIHZhbHVlIGlmIERUWCBpcyB1c2Vk IGFuZCB0aGUgYmFja2dyb3VuZCBub2lzZSBpcyBmYWlybHkgc3RhdGlvbmFyeSwgYnV0IGlmIHRo ZSBiYWNrZ3JvdW5kIG5vaXNlIG9yIG11c2ljIGlzIGNoYW5naW5nIGR5bmFtaWNhbGx5IGFuZCBo aWdoIGF1ZGlvIHF1YWxpdHkgaXMgZGVzaXJlZCwgdGhlbiB0aGUgRFRYIGFuZCBjb21mb3J0IG5v aXNlIHNob3VsZCBiZSB0dXJuZWQgb2ZmIGFuZCBhbGwgcGFydHMgb2YgdGhlIHNpZ25hbCBuZWVk IHRvIGJlIHRyYW5zbWl0dGVkLg0KDQpSYXltb25kICANCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBjb2RlYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y29kZWMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGNvZGVjIGlzc3VlIHRyYWNrZXINClNlbnQ6IFN1 bmRheSwgTWF5IDAyLCAyMDEwIDk6MDMgQU0NClRvOiBob2VuZUB1bmktdHVlYmluZ2VuLmRlDQpD YzogY29kZWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbY29kZWNdICMxNDogVkFEIGFuZCBDTkc/ DQoNCiMxNDogVkFEIGFuZCBDTkc/DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogUmVwb3J0ZXI6ICBo b2VuZUDigKYgICAgICAgICAgICAgICAgIHwgICAgICAgT3duZXI6ICAgICANCiAgICAgVHlwZTog IGRlZmVjdCAgICAgICAgICAgICAgICAgIHwgICAgICBTdGF0dXM6ICBuZXcNCiBQcmlvcml0eTog IG1ham9yICAgICAgICAgICAgICAgICAgIHwgICBNaWxlc3RvbmU6ICAgICANCkNvbXBvbmVudDog IHJlcXVpcmVtZW50cyAgICAgICAgICAgIHwgICAgIFZlcnNpb246ICAgICANCiBTZXZlcml0eTog IC0gICAgICAgICAgICAgICAgICAgICAgIHwgICAgS2V5d29yZHM6ICAgICANCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KQ29tbWVudChieSBob2VuZUDigKYpOg0KDQogW0hvZW5lXTogQ29tZm9ydCBu b2lzZSB1c2VkIHRvIGJlIHVzZSB0byBpbmRpY2F0ZSB0aGF0IGEgdHJhbnNtaXNzaW9uIGlzDQog b25nb2luZy4gSG93ZXZlciwgaWYgaGlnaCBxdWFsaXR5IHRyYW5zbWlzc2lvbiBzaGFsbCBiZSBz dXBwb3J0ZWQsDQogYXJ0aWZpY2FsIG5vaXNlIHdvcnNlbiB0aGUgYXVkaW8gcXVhbGl0eS4gVGh1 cywgdGhlIGdlbmVyYXRpb24gb2YgaWRsZQ0KIGNoYW5uZWwgbm9pc2Ugc2hvdWxkIG5vdCBiZSB1 c2VkIHRvIGluZGljYXRlIHRoYXQgdGhlIGNhbGwgaXMgc3RpbGwNCiBhY3RpdmUuIEluc3RlYWQs IGluIGNhc2Ugb2YgdHJhbnNtaXNzaW9uIHByb2JsZW1zIGFuIGFjb3VzdGljIG9yIHZpc3VhbA0K IG5vdGlmaWNhdGlvbiBjYW4gYmUgZ2l2ZW4uDQoNCi0tIA0KVGlja2V0IFVSTDogPGh0dHA6Ly90 cmFjLnRvb2xzLmlldGYub3JnL3dnL2NvZGVjL3RyYWMvdGlja2V0LzE0I2NvbW1lbnQ6MT4NCmNv ZGVjIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvY29kZWMvPg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY29kZWMgbWFpbGluZyBsaXN0DQpjb2RlY0Bp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb2RlYw0K From hoene@uni-tuebingen.de Mon May 10 23:00:06 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C1C28C122 for ; Mon, 10 May 2010 23:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.335 X-Spam-Level: * X-Spam-Status: No, score=1.335 tagged_above=-999 required=5 tests=[AWL=-5.373, BAYES_50=0.001, FM_VIAGRA_SPAM1114=10.357, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jy7QmLd--TLR for ; Mon, 10 May 2010 23:00:04 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id E3F403A6AE0 for ; Mon, 10 May 2010 23:00:03 -0700 (PDT) Received: from hoeneT60 ([178.2.215.148]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4B5xeiI013108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 May 2010 07:59:46 +0200 From: "Christian Hoene" To: "'Raymond \(Juin-Hwey\) Chen'" , "'Jean-Marc Valin'" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> <20100507144856.171013mxhy3wdfbc@mail.skype.net> <20100509143636.21296os5ryogl1ic@mail.skype.net> <4BE85F57.9040205@digium.com> <4BE87165.2030401@octasic.com> In-Reply-To: Date: Tue, 11 May 2010 07:59:32 +0200 Message-ID: <000001caf0cf$282a2e70$787e8b50$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrwglZlRdRMon4wRWWDChT4kHf3/QABZ4egABF0sYA= Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 06:00:06 -0000 Hello, what do you think about STL2005/9 described in ITU-T G.191. It might be = a good metric to measure the codec performance in low-complexity mode. STL2009 is not yet published officially but the STL = 2005 manual is available for free. http://www.itu.int/rec/T-REC-G.191-200508-I/en Chapter 13, Page 159 describes a set of basic operator and their = complexity weights. STL2009 is similar but has guidelines on data movement and program ROM estimation tool for fixed-point c code and a = complexity evaluation tool for floating-point C Code. However, STL2005 might not be optimal for soft-phone complexity = prediction because many operations have overflow control and saturation, that typically cannot be translated into a single native = assembler instruction. Thus, for soft-phone I would recommend to use slightly modified measures... With best regards, Christian --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ >-----Original Message----- >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Raymond (Juin-Hwey) Chen >Sent: Tuesday, May 11, 2010 12:03 AM >To: Jean-Marc Valin >Cc: codec@ietf.org >Subject: Re: [codec] #16: Multicast? > >Hi Jean-Marc, > >I didn't just cook up those MIPS numbers out of my head :o) I have = been working with Bluetooth >engineers on voice/audio processing for Bluetooth headsets in the last = few years. > >Bluetooth headsets normally don't use general-purpose DSPs from those = traditional DSP houses that you >mentioned below. A lot of mid- to low-end Bluetooth headsets (where = most of the shipping volume is) >don't even have any DSP and instead just rely on an ARM processor to do = all voice/audio processing and >Bluetooth protocol stack. The 5 MIPS number for current-generation BT = headsets was quoted to me by an >experienced Bluetooth audio engineering manager in terms of MIPS on an = ARM processor, but since most >speech coding engineers are more familiar with the MIPS for a = general-purpose 16-bit fixed-point DSP, >so I converted the MIPS on an ARM to the equivalent MIPS on a = fixed-point DSP, and it came to around 5 >MIPS. The 10 to 20 MIPS number is what we may expect in a several = years as Moore's Law helps to >increase the processing power of Bluetooth headsets. > >High-end Bluetooth headset chips may have a DSP on-chip, but it is = usually either a proprietary DSP or >a DSP core not from the traditional DSP houses but from companies like = ARM. > >One thing to keep in mind, though, is that even if you have a DSP on a = Bluetooth headset chip, and it >is clocked at 50 MHz or higher, it doesn't mean that you can use all or = most of that DSP processing >power for speech or audio coding. This is because it has to handle = many other signal processing tasks >such as acoustic echo canceller, single-mic or multi-mic noise = suppression, wind noise suppression, >packet loss concealment, voice prompt decoding, and even voice command = recognition, to name just a >few. You can't even get half of the DSP processing power solely = dedicated to speech coding. You will >be lucky if you can get 20% of the DSP for speech coding. Remember = that currently the speech coding >part (CVSD codec) takes 0% of the DSP or ARM because it is done in chip = hardware. > >Raymond > >-----Original Message----- >From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] >Sent: Monday, May 10, 2010 1:50 PM >To: Raymond (Juin-Hwey) Chen >Cc: Kevin P. Fleming; codec@ietf.org >Subject: Re: [codec] #16: Multicast? > >Hi Raymond, > >I'm just curious about where you got your MIPS figures for Bluetooth? = I'm >not familiar with the type of DSPs used in those applications, but from = a >quick search of more "general-purpose" DSPs (TI, ADI and similar), the >lowest speed I was able to find (sold in 2010) was a 50 MIPS DSP. Any = idea >what type of DSPs are currently used in Bluetooth? > >Cheers, > > Jean-Marc > >Raymond (Juin-Hwey) Chen wrote: >> Hi Kevin, >> >> I completely agree with you that the IETF codec development should = not >> be constrained by a low-complexity device designed in 2009 or = earlier, >> and we should look toward the time frame of 2012 and 2013 instead. >> >> In my previous emails I have indicated that due to many reasons, over >> the last several years the processing power of Bluetooth headsets has >> been increasing at a rate much slower than what's predicted by = Moore's >> Law, and it doesn't look like this will change significantly in the = next >> few years. I also said that for the current-generation Bluetooth >> headset chips, the maximum codec complexity it can support is = probably >> somewhere around 5 MIPS on a 16-bit fixed-point DSP, and by the time = the >> IETF codec becomes a standard, the number may go up to 10 MIPS, or 15 >> MIPS at most. >> >> Thus, if we want mono Bluetooth headsets in the FUTURE (i.e. in the = next >> several years) to be able to run the IETF codec in the narrowband or >> wideband mode at least, a good complexity target to shoot for is 10 = to >> 20 MIPS on a fixed-point DSP. >> >> Raymond >> >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On = Behalf Of Kevin P. Fleming >> Sent: Monday, May 10, 2010 12:33 PM >> To: codec@ietf.org >> Subject: Re: [codec] #16: Multicast? >> >> On 05/10/2010 02:11 PM, Raymond (Juin-Hwey) Chen wrote: >> >>> Considering that there are a very large number of Bluetooth headset = users and that the current >Bluetooth headsets can already be used for making VoIP phone calls, it = would be great if the IETF >codec can be implemented in future Bluetooth headsets to avoid the = additional coding distortion and >delay associated with transcoding. However, with that said, I didn't = mean to push a "Bluetooth mode" >for the IETF codec. I merely wanted to use Bluetooth headset as an = example to make a point that a low >codec complexity is desirable and a high codec complexity can have = negative consequences. >> >> This is all perfectly reasonable, but given the likely timeframe we = are >> talking about for this codec to be produced and published as a >> standards-track RFC, the definition of 'low complexity' in this >> discussion is really talking about the 2012-2013 version of 'low >> complexity', not today's. It seems highly likely that the MIPS = capacity >> of the DSPs designed into Bluetooth headsets in 2012 will be vastly >> greater than what is used today, if there is an application to take >> advantage of the additional MIPS. >> >> I'd hate to see this codec's development constrained in any = significant >> way by the requirements of a low-complexity device designed in 2009 = or >> earlier. >> >> -- >> Kevin P. Fleming >> Digium, Inc. | Director of Software Technologies >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >> skype: kpfleming | jabber: kfleming@digium.com >> Check us out at www.digium.com & www.asterisk.org >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec > > > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From koen.vos@skype.net Mon May 10 23:23:08 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47B383A6AE6 for ; Mon, 10 May 2010 23:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7YYCm6GLtUo for ; Mon, 10 May 2010 23:23:06 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id D30643A67DB for ; Mon, 10 May 2010 23:22:46 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 41B986012BD72; Tue, 11 May 2010 07:22:35 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=pTxPFEQjahK2 CUJA7O8ABr0hSxM=; b=YiYowTVorvY/yV/HkMBxspr+E8ajCyUPtywK4yslQWCg OnEF0MJHKMhWcjDB5AZu1vswrAg/LnsGaiShhehDa5vPkPBf09Y+udxlG577Dnb3 WfV1lYB4wzYj9oBQT0cKj+jAo0Yf36hAZyaz/dNb3N21CXT1zEFxsaR2O03BfqQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=TlYQU/lx9sdJJDboOeI5 7G4QPZnPdnvQ2QkX2n/BS7nk3KjweHX9oHEEcHdBhC8uaoFl+X8Tt2p9GO4UdRdg +3W8t22EZxMhgSgyrtv0TEmA3OTsWogzn+dctd8xm3wQUyFSklxcKD3G+bAZ8Rpq SHuS3X0zDSCPZcTyO4ms+q0= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 3F4576012BD60; Tue, 11 May 2010 07:22:35 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPXOf2S1lOLo; Tue, 11 May 2010 07:22:34 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id 5E01E6012BD71; Tue, 11 May 2010 07:22:34 +0100 (IST) Received: from port-87-234-197-99.static.qsc.de (port-87-234-197-99.static.qsc.de [87.234.197.99]) by mail.skype.net (Horde Framework) with HTTP; Mon, 10 May 2010 23:22:34 -0700 Message-ID: <20100510232234.16632o6l2ecu3wyy@mail.skype.net> Date: Mon, 10 May 2010 23:22:34 -0700 From: Koen Vos To: bens@alum.mit.edu, "Benjamin M. Schwartz" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> In-Reply-To: <1273441939.4be72e937fdf5@webmail.fas.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 06:23:08 -0000 Quoting Benjamin M. Schwartz: > Quoting Koen Vos : >> For typical VoIP applications, Moore's law has lessened the pressure >> to reduce bitrates, delay and complexity, and has shifted the focus to >> fidelity instead. > > I think this is a typo, and you mean "lessened the pressure to > reduce bitrates and complexity, and has shifted the focus to > fidelity and delay instead". Not a typo: codecs have become more wasteful with delay, while delivering better fidelity. G.718 evolved out of AMR-WB and has more than twice the delay. Same for G.729.1 versus G.729. This is not by accident. The main rationale for codec delay being less important today is that faster hardware has reduced end-to-end delay in every step along the way. As a result, a typical VoIP connection now operates at a flatter part of the "impairment-vs-delay" curve, meaning that reducing delay by N ms at a given fidelity gives a smaller improvement to end users today than it did some years ago. Therefore, the weight on minimizing delay in the "codec design problem" has gone down, and the optimum codec operating point has naturally shifted towards higher delay, in favor of fidelity. I've mentioned before that average delay on Internet connections seems to be 40% to 50% lower now than just 5 years ago, which is just one contributor to lower end-to-end delay. That doesn't mean high-delay connections don't exist - they do, for instance over dial-up or 3G. But in those cases it's still better to use a moderate packet rate (and bitrate), to minimize congestion risk. The confusion may come from the fact that the trade-off between fidelity and delay changes towards high quality levels: once fidelity saturates, delay gets priority. Even more so because such high fidelity enables new, delay-sensitive applications like distributed music performances. This is reflected in the ultra-low delay requirements in the requirements document. To summarize, the case for using sub-20 ms frame sizes with medium-fidelity quality is now weaker than ever, because the relative importance of fidelity has gone up. koen. From hoene@uni-tuebingen.de Tue May 11 07:39:50 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC3A93A698A for ; Tue, 11 May 2010 07:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzLD8mlj7WHI for ; Tue, 11 May 2010 07:39:43 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id BFB133A6911 for ; Tue, 11 May 2010 07:39:36 -0700 (PDT) Received: from hoeneT60 ([178.2.215.148]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4BEcf5e023269 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 May 2010 16:38:48 +0200 From: "Christian Hoene" To: "'Koen Vos'" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> <20100510232234.16632o6l2ecu3wyy@mail.skype.net> In-Reply-To: <20100510232234.16632o6l2ecu3wyy@mail.skype.net> Date: Tue, 11 May 2010 16:38:40 +0200 Message-ID: <006101caf117$aaf3b2c0$00db1840$@de> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_0062_01CAF128.6E7C82C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acrw0m8GNXZpDck0Qjy3nWpGN9Rz1gAQeaxw Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 14:39:51 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0062_01CAF128.6E7C82C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0063_01CAF128.6E7C82C0" ------=_NextPart_001_0063_01CAF128.6E7C82C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 may I present some results of the ITU-T SG12 on the perceptual effects = of delay? For many years, it was assumed that 150ms is the boundary for = interactive voice conversations (see Nobuhiko Kitawaki, and Kenzo Itoh: Pure Delay Effects on Speech Quality in Telecommunications, IEEE = J. on Selected Areas in Commun., Vol.9, No.4, pp.586-593, May 1991) Until 400ms quality is still acceptable (about toll quality). The = ITU-T G.107 quality model reflects this opinion. However, in the recent years, new results have shown that the impact of = delay on conversation quality is NOT as strong as assumed. At the ITU-T, numerous contributions have been made on this issue: Contribution of BT =93Comparison of E-Model and subjective test data for = pure-delay conditions=94 from 2007-01-08: Legend: MOS-CQS are subjective conversational tests MOS-CQE is the E-Modell (G.107) MOS-LQO are result from listening-only tests. =20 Also, LM Ericsson described very interesting results in =93Investigation = of the influence of pure delay, packet loss and audio-video synchronization for different conversation tasks=94 from 2007-09-24. For = example: =20 and Overall, it seems that the limit of 150ms is greatly overestimated. A = much relaxed timing is allowed. Seeing these figures, I have to assume that the ITU-T G.107 standard was = a plot of the telcos to make life of VoIP vendors hard. Well done... =20 With best regards, =20 Christian Hoene =20 =20 =20 =20 --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ =20 =20 >-----Original Message----- >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Koen Vos >Sent: Tuesday, May 11, 2010 8:23 AM >To: bens@alum.mit.edu; Benjamin M. Schwartz >Cc: codec@ietf.org >Subject: Re: [codec] #16: Multicast? >=20 >Quoting Benjamin M. Schwartz: >=20 >> Quoting Koen Vos : >>> For typical VoIP applications, Moore's law has lessened the pressure >>> to reduce bitrates, delay and complexity, and has shifted the focus = to >>> fidelity instead. >>=20 >> I think this is a typo, and you mean "lessened the pressure to >> reduce bitrates and complexity, and has shifted the focus to >> fidelity and delay instead". >=20 >Not a typo: codecs have become more wasteful with delay, while >delivering better fidelity. G.718 evolved out of AMR-WB and has more >than twice the delay. Same for G.729.1 versus G.729. This is not by >accident. >=20 >The main rationale for codec delay being less important today is that >faster hardware has reduced end-to-end delay in every step along the >way. As a result, a typical VoIP connection now operates at a flatter >part of the "impairment-vs-delay" curve, meaning that reducing delay >by N ms at a given fidelity gives a smaller improvement to end users >today than it did some years ago. Therefore, the weight on minimizing >delay in the "codec design problem" has gone down, and the optimum >codec operating point has naturally shifted towards higher delay, in >favor of fidelity. >=20 >I've mentioned before that average delay on Internet connections seems >to be 40% to 50% lower now than just 5 years ago, which is just one >contributor to lower end-to-end delay. That doesn't mean high-delay >connections don't exist - they do, for instance over dial-up or 3G. >But in those cases it's still better to use a moderate packet rate >(and bitrate), to minimize congestion risk. >=20 >The confusion may come from the fact that the trade-off between >fidelity and delay changes towards high quality levels: once fidelity >saturates, delay gets priority. Even more so because such high >fidelity enables new, delay-sensitive applications like distributed >music performances. This is reflected in the ultra-low delay >requirements in the requirements document. >=20 >To summarize, the case for using sub-20 ms frame sizes with >medium-fidelity quality is now weaker than ever, because the relative >importance of fidelity has gone up. >=20 >koen. >=20 >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec ------=_NextPart_001_0063_01CAF128.6E7C82C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello,

 

may I present some results of the ITU-T SG12 on the perceptual = effects of delay?

For many years, it was assumed that 150ms is the boundary for interactive voice conversations (see Nobuhiko Kitawaki, and Kenzo Itoh: = Pure Delay Effects on Speech Quality in Telecommunications, IEEE J. on = Selected Areas in Commun., Vol.9, No.4, pp.586-593, May 1991) Until 400ms quality = is still acceptable (about toll quality). The ITU-T G.107 quality model = reflects this opinion.

However, in the recent years, new results have shown that the = impact of delay on conversation quality is NOT as strong as assumed. At the ITU-T, numerous contributions have been made on this = issue:

Contribution of BT “Comparison of E-Model and subjective = test data for pure-delay conditions” from = 2007-01-08:

Legend:

MOS-CQS are subjective conversational = tests

MOS-CQE is the E-Modell (G.107)

MOS-LQO are result from listening-only = tests.

 

Also, LM Ericsson described very interesting results in “Investigation of the influence of pure delay, packet loss and audio-video synchronization for different conversation tasks” from 2007-09-24. For example:

 

and

Overall, it seems that the limit of 150ms is greatly = overestimated. A much relaxed timing is allowed.

Seeing these figures, I have to assume that the ITU-T G.107 = standard was a plot of the telcos to make life of VoIP vendors hard. Well = done...

 

With best regards,

 

=A0Christian Hoene

 

 

 

 

----------------------------------------------= -----------------

Dr.-Ing. Christian = Hoene

Interactive Communication Systems (ICS), = University of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 = 7071 2970532

http://www.net.uni-tuebingen.de/

 

 

>-----Original Message-----

>From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Koen = Vos

>Sent: Tuesday, May 11, 2010 8:23 AM

>To: bens@alum.mit.edu; Benjamin M. Schwartz

>Cc: codec@ietf.org

>Subject: Re: [codec] #16: Multicast?

> 

>Quoting Benjamin M. Schwartz:

> 

>> Quoting Koen Vos = <koen.vos@skype.net>:

>>> For typical VoIP applications, Moore's law has lessened the = pressure

>>> to reduce bitrates, delay and complexity, and has shifted the focus = to

>>> fidelity instead.

>> 

>> I think this is a typo, and you mean "lessened the pressure = to

>> reduce bitrates and complexity, and has shifted the focus = to

>> fidelity and delay instead".

> 

>Not a typo: codecs have become more wasteful with delay, = while

>delivering better fidelity.=A0 G.718 evolved out of AMR-WB and has = more

>than twice the delay.=A0 Same for G.729.1 versus G.729.=A0 This is not = by

>accident.

> 

>The main rationale for codec delay being less important today is = that

>faster hardware has reduced end-to-end delay in every step along = the

>way.=A0 As a result, a typical VoIP connection now operates at a = flatter

>part of the "impairment-vs-delay" curve, meaning that reducing = delay

>by N ms at a given fidelity gives a smaller improvement to end = users

>today than it did some years ago.=A0 Therefore, the weight on = minimizing

>delay in the "codec design problem" has gone down, and the = optimum

>codec operating point has naturally shifted towards higher delay, = in

>favor of fidelity.

> 

>I've mentioned before that average delay on Internet connections = seems

>to be 40% to 50% lower now than just 5 years ago, which is just = one

>contributor to lower end-to-end delay.=A0 That doesn't mean = high-delay

>connections don't exist - they do, for instance over dial-up or = 3G.

>But in those cases it's still better to use a moderate packet = rate

>(and bitrate), to minimize congestion risk.

> 

>The confusion may come from the fact that the trade-off = between

>fidelity and delay changes towards high quality levels: once = fidelity

>saturates, delay gets priority.=A0 Even more so because such = high

>fidelity enables new, delay-sensitive applications like = distributed

>music performances.=A0 This is reflected in the ultra-low = delay

>requirements in the requirements document.

> 

>To summarize, the case for using sub-20 ms frame sizes = with

>medium-fidelity quality is now weaker than ever, because the = relative

>importance of fidelity has gone up.

> 

>koen.

> 

>__________________________________________= _____

>codec mailing list

>codec@ietf.org

>https://www.ietf.org/mailman/listinfo/code= c

------=_NextPart_001_0063_01CAF128.6E7C82C0-- ------=_NextPart_000_0062_01CAF128.6E7C82C0 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAkMAAAExCAYAAAB/O6bMAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAIR2SURBVHhe 7Z0HfBTVE8dn90oujSRA6L0XQVBRUIoUARVEQLHwt6EUETWUEEIIIYRwhABGQQQbCoIVC4qACiIq TUHpSu8dAqRd2fKf2XAxCSkX0q7M+/zvL7nbfeX79vZ+O2/ejD42Nha4MAEmwASYABNgAkzAWwno vXXgPG4mwASYABNgAkyACRABFkN8HTABJsAEmAATYAJeTYDFkFdPPw+eCTABJsAEmAATYDHE1wAT YAJMgAkwASbg1QRcVgxNnjw5Cmfmf149Ozx4JsAEmAAT8FYCGTjw3lOnTj3vrQDKctwuK4YQQm18 NStLGNwWE2ACTIAJMAEXImBwob54dFdcWQzZPJo8D44JMAEmwASYQP4E0vEjlQGVDQFXFkNlQ4Bb YQJMgAkwASbABLyagAeIIRn2rl0B6/YcB5k0dOXG8OSAByDU16vnlQfPBJgAE2ACTIAJOEnA/cWQ dALeMy8Aa+8n4d56fqBUCAGD6OTo+TAmwASYABNgAkzA6wm4vRhSzx+Diw1uh3HDn4FWgV4/nwyA CTABJsAEmAATKCIBtxdD5w7shiN/fQczxl4Cf9DBvU+/DIM6NufQ2kW8EPhwJsAEmAATYALeSsDt xRBUbAHPDJ0GfZ/tBUGp+yE6YiYYgmbDo60q5pjTDz74AP79919QVVV7iaLnr6V501hpshVFAUEQ tJenFxqrN1zDjnn0lrn1tu+sN423cuXKMHr0aK/63rrTfdjtxVC1Vl3h+VbXkVdsBg10V2Hz7/tR DLXPMQ8dOnSA5s2bw6ZNm2Dr1q3w6quvutM83VRf16xZAydOnIAXXnjhps53t5OmTJkCzz//PNSu TSGqPLtMmjQJxo4dCyEhIZ490OujmzVrFnTr1g1uu+02jx7v999/D2fPnoUhQ4Z49Dgdg6MH1C++ +AKioijGrmeX3bt3Q1JSEowZM8azB+qmo3N7MbTn+/nw45XWEPZkR5wCO1xO94Wa9arcMB1NmzbV 3pMkCdLS0uCuu+5y0ylzvtsXL16E4OBgrxgrUWnWrBl07NgRqlWr5jwkNz2SrufOnTuDn5+fm46g aN1u0aIFtG/fHtq2bVu0E93s6HPnzmkPMN5wf6KpqVixIpBI8IbxksV6+fLlbnZFek933V4MVa5a FfZ8PR9mpeyBQNtFUO/qBg/dXT/fGbRarWC3271ihr1prA6hm5FBEew9v5Cop7F6ixii76zFYvH4 iaXvrM3mPfFmaU7pWvaGQvNqMHBAaVeda7cXQ1VvHwhzImvCl7/8A2pwKxg28CEIdftRuerlwv1i AkyACTABJuB5BDxCNgTWbw/P4IsLE2ACTIAJMAEmwASKSsAjxFBRB83HMwEmwASYABNgAkzAQYDF EF8LTIAJMAEmwASYgFcTYDHk1dPPg2cCTIAJMAEmwARYDPE1wASYABNgAkyACXg1ARZDXj39PHgm wASYABNgAkyAxRBfA0yACTABJsAEmIBXE2Ax5NXTz4NnAkyACTABJsAEWAzxNcAEmAATYAJMgAl4 NQEWQ149/Tx4JsAEmAATYAJMgMUQXwNMgAkwASbABJiAVxNgMeTV08+DZwJMgAkwASbABFgM8TXA BJgAE2ACTIAJeDUBFkNePf08eCbABJgAE2ACTIDFEF8DTIAJMAEmwASYgFcTYDHk1dPPg2cCTIAJ MAEmwARYDPE1wASYABNgAkyACXg1ARZDXj39PHgmwASYABNgAkyAxRBfA0yACTABJsAEmIBXE2Ax 5NXTz4NnAkyACTABJsAE3EYMbV/9Aew33gGPd7sl16zZ4NcP34IVe06DThQAqreGV194Eqr78+Qy ASbABJgAE2ACTKBwAm4hhjIOrYInnhoB9Uctv1EMWY/Cp0vWQa0Xx0Pvhv4gGwMhyKfwgfMRTIAJ MAEmwASYABMgAm4ghlLho/c+h9SgalC3svGGWVPOn4RrDRvBXS3rQdVKflA9NIRnlgkwASbABJgA E2ACThNweTG0b8V82KXeA+P/Z4e9lrQbBnbqnx1waPNP8OF8OwRKNmja60l4tm9nCBDzZuDj4wN6 vcsP2+kJLOhAo9EIBoOhROpyh0poXk0mkzt0tdh99Kaxak9tOLf03fX04m3fWW+6H3vD9evO30+X VgXylf3w7rpLMCpxPBx/42fY5xN4A+uAJj0g7rUe0LVbKxDgNEx8djQsC20Ew+6ukePYQ4cOwbVr 12DPnj1w8uRJ+Ouvv9x53pzq+7///gunTp3yirESkDNnzsC2bdugZs2aTvFx54POnj0LW7duheDg YHcehtN9p+t4165dIAjoF+jBhb6z58+f95rv7IEDB+D06dNeMV66frm4LgGXFkMbP3oDfv77KtSc Nxv++P5vOGhaDGu7tIDurapnEQ2p2wq61XX8WRnq+cqwf+cxgFxiaP369fDPP//A8ePHNTG0bNky 152VEuoZ3WiuXr0KOp2uhGp07Wr2798PK1asgKCgINfuaAn07uDBg7B8+XLw9fUtgdpcvwp6iLFY LLB7927X72wxekhiKDU11eNFnwPRxYsXtfuyN9yPSdA3aNCgGFcHn1qaBFxaDDXrOxwSm52GtDQL HAvxg7N+NaBKUM6b/9+fTYOPTraEWWP6I6c0OJXqAw1b1L6B2fPPP6+9R0/T69atgwkTJpQmV5eo e82aNUAWsZEjR7pEf0q7E+PGjYPIyEioVKlSaTdV7vW/8sorMGfOHK9Z8o2NjYUBAwZAq1atyp19 aXbg+++/1x7YRowYUZrNuEzdR48ehYULF4LZbHaZPpVWR/7++2/44osvSqt6rreYBFxaDIWi1ac7 vqhYdyyB9KCu0KpOMBzY+DVsTa0Dg3veBg3adQffrW/C2Ml/gb+SAZX7DIaBd9bKFws9ddETpjeU tLQ0yMjI8IahZl4jVqu2FOoNYshms2lWP28Yq2Nu6bvr6cXbvrMpKSna99Ybijdcv+48jy4thrKD 7TniNbhHF6y9ValOc7jVVkH7d4X6HSB2UnX4bccxUH0qwJ3t24J3LBy482XHfWcCTIAJMAEm4DoE 3EYMBVWpDQ5PkIq1mkLFbAzF4HrQuUs916HKPWECTIAJMAEmwATchoDbiCG3IcodZQJMgAkwASbA BNyKAIsht5ou7iwTYAJMgAkwASZQ0gRYDJU0Ua6PCTABJsAEmAATcCsCLIbcarq4s0yACTABJsAE mEBJE2AxVNJES6C+pUuXalFZ8yohISHwwgsvlEArXAUTYAJMgAkwASZABFgMueB1MHXqVKBoynkV iitDASQ9PS2BC04Ld4kJMAEmwAQ8lACLIRecWLL+5FcqVsweVMAFO89dYgJMgAkwASbgZgRYDLnZ hHF38ydA1jJvycPmbdcBz6u3zTiPlwmULQEWQ2XLm1srRQKyLEN6enoptuA6Vev1evDz83OdDpVi T2heKa2MuywNq6qqJVulJLo0T+5QKA0I9dXHx8cdust9ZAIlTsA9vqklPmyu0BMJUILLGTNmwAcf fOCJw8sxpkuXLsEff/wBnTt39vixHjhwAN566y2g5LTuUCRJgubNm8OiRYvgvvvuc4cuQ8+ePeHB Bx+EiRMnukV/uZNMoKQJsBgqaaIlUN+VK1fyrYUSG7rLE3IJoHC6ir1798LmzZu14w8dOgQNGzZ0 +lx3O3DLli3w7bffgiiK0KFDBzAYDO42hCL1d86cOZrFjwSRO2Q3f+edd+DUqVMwe/ZstxBD69ev 14Q19fnFF1+EgnwWizRxfDATcCMCLIZccLKGDBkCR48ehYsXL8Lnn3+u9ZCWROhGRSb4v/76C9q2 bVtoz00mExiNxkKP84QD3n77bY0XlXfffdctfjRvlvubb74JtKxB18akSZM0K4SnFhK5X331lTY8 CjkxdOhQaNCggcsOl65Buhap/Pzzz/Drr79Cp06dnO4vLVOV5XdWURSYO3cu2O12OHbsGHzyySfa fYYLE/A2AiyGXHDGx48fr/Vq1apVWWKI/CZq1qypWQImTJig+VC89tpr2k3MZrPlOYrt27fDmTNn YMOGDS44ypLpElnJyDJCAshRFi5cCAMHDtQYkXj0lEJjpSWYJUuWaEOiuadrITo62iN9pWheSQA5 RO6JEyfg/fffhwceeEDj4GqFLHU7d+6EHTt2aF2j7yVZh0jcWK1Wp7r7999/w4ULF8rkO0vXE/k2 ffnll1l9S0pKgieffBKCghxpsZ3qNh/EBNyeAIshF57C0aNHZ/WObqZjxoyBESNGwJ133gm0XDZy 5Eho0aKF9qSclyD6559/gJbcfvzxRxceZfG6Rjf01atXa5YSR0lOToawsDDo1q2bx4mh7D9cNN4V K1Zooqhdu3ZAT/meVK5evQrz58/PMaTExESwWCyac7IrFrLaZS/ffPMNUDgMepBxpuzbtw+uXbtW Jt9Z+u58+umnObpF8c1IgD777LNe46DvzLzwMZ5PgMWQi87xe++9B4cPH76hd127doVBgwZp75NZ e/ny5fDyyy/n6Tfyww8/aP4znmz2Jkfi7FYhBzBiExERAf7+/i46w0XvFl0P5DeTu9AyWWxsbNEr dPEzyEKa27JHwo8Cj0ZGRrpc70lY5LWbkYR6XFycU/0lazBtBBg+fLhTxxfnoD179sC8efNuqIL8 sg4ePKj53d1zzz3Qpk2b4jTD5zIBtyDAYsgFp4ksG451/Nzdox+IAQMGaNtg69atC71799Z+CMlK VKNGjRyHkwnc07eaT5kyRVsKzF1OnjwJ9BlZEjyl0HKYY8ko+5jIwZhStHiS7xA5iS9evPiGqSNx tGDBAujTpw+0atXKZaaWBMy0adPyXA5buXKltuR9//33F9rfsvzOkr8Z3Wvy+u6QtblKlSqa5WjZ smVw++23azvO2Lm60CnkA9yUAIshF5w48glx+B3k7h5ZPKZPnw6TJ0/WPqJlMlrjp+WEvASRCw6v xLpEjPJ6snU0QOZ+TxFDv/32m/ajlF+hJVVaLvSUsmnTJjh37lyewyHhQXPvamJo9+7defaXLEMk iJwRQ2U1f2Q1/vrrr/NtjoTo1q1boV+/frBr1y5ttxlZ48hSREt+tATNhQl4EgEWQy44m3Xq1IGP Pvooz57Rk3GzZs1yfEaC6H//+5/2xPzwww/Dbbfd5oKjKvkukZ/Uhx9+mBV1mv5NzrWhoaFaY56U uoTmnX6gyEmXCjkS03JpQECAx42VBtS3b9+seaS/P/vsM20HZePGjbXxulp8JbLK5fedpf66knCj /pBlmR668gvTUatWLY0zOX+TVYhe5H9IgpysdrTDj3IkkqN1/fr1S/7LzTUygTImwGKojIE70xwJ mqIWEkjPPfecZgm54447gLbne3oKA3Iappej0E4ccvwMDg4uKj6XP562Z2ffok1P6sOGDfPYmFPk r5I9VhT5S9EOQRL+rljIj2nw4MGu2LU8+3Qzlh36XpH1mQr5G5EgJx8uEkNPPPEEVKtWzW3Gzx1l ArkJeJQYktMvw1XJBBUreFaaAloWIGtRYYVuSrRcRstD9KpcuXKWJaGwcz3hc9plRD4QniiGcs8P jfXy5cuaM7E3FAqTQLvLuLgGgZYtW2phA6g4lqPJP/Ghhx7SltIqVKjgGh3lXjABJwl4jhiynYFX Bw+AjK7T4L1Xujs5fNc/jNb2+/fvD08//XSeO4nyGgE9oZL/yKxZs+CRRx5x/UFyD5kAE3BbAnS/ IRFEgpUexijQZGBgoMs5ubstYO54mRDwGDG0ZdksmP/tNnjmPs+JuExOl+QXQk9c5A9EEaUp0KIz hXaZ0bIRRavmwgSYABMoTQIkfuhFOzhpWz7FOCOfJAqcSeFAmjZtCrVr1y7NLnDdTKBYBDxCDGUc +RmW/abCE493gyDRUiwgrnIyBUqkdfjsW+MpOixFon7jjTec6mb79u21oHyUtoHEEd2suDABJsAE SpNAo0aNgF60meHPP//Uwgr89NNPmrM1xTyjgJmUdoQLE3AlAu4vhpSr8P47S+DWJydBhS2TYK1U cPoFCsLn6l9EsgjR8hb5heQuFH+IHKOdsRDR+XTzIX8j2hb70ksveVQsmtxsaOeLtwg+Gqs3+WXQ d9aTAmjm9yNAOQjJAuwJhXY+UrR8epGj9S+//KKFBaHr9q677tKS2NK/XTWaeEnPgTdcvyXNrCzr c3MxpMKW9xPg+5P14LXmfrBy+QW4WuUcXEm3Q7BfzkzelEmaQt1TfiMKyEf5f1y1UOwcunnkV8hC RLFLHE7V9G9HOo7sEXvJXE2h/clCRMHcaPs9bbunreeU3sOT8nYRK0qMSU623iAS6Ifl1Vdf9Zgf zsK+i7///ru29FK9evXCDnXrzw8cOKCl2qH/elIh8U7b+cmyTUv3FECUdqbRfYhyJ1KuOXqQofsV HeNp9yaay9OnT2sWMy6uScDNxZACl+0qVDachXnxcbBr4wE4H/AZ/PxAN+jfLmcuIHoKIVFAgcS2 bdumbUN31XL+/Hlth0ZeheKC0NZ7urlQKgoqPXr00NbkqWS/iXz//fea+CMRRDciOodC7derV09b x/c0QXT27FnNouZsHihXnX9n+kWC3psSapJA6NKlC9x6663O4HHbY2jDBAWbfOqpp9x2DPl1nO5d jsTKZOGmnZ+nTp2CtWvXav+mB7rHH39c2yFJ9zF6ICRh5CmFRCDlfuPimgTcXAzp4P4XzeAIcr/g 1b3we52RNwghQk8CgApZDih9g6sFQct+eXzwwQeaeKEggrkLWY3oiWrNmjVZ1i1ylCarCAXgox9I WkYjE3WTJk20p61bbrklqxq6CTluRGS+9qRC6QNat259Q1oSTxqjYyxk3aOcUY6gi544xuxjIosQ BTZ05e9tScwB5RKkhxZPHyexovRB5GBNwo9SfRw9ehQ+/vhjbQmN7k2uGlPqZueZdtuxGLpZeqV/ npuLoZyAWnYeCP7BBe9YoKcPMsm6ciEhRILIEXXY0VfaUeZI4NirV6+sIdBTMz1Z0X/ffvttLXs5 +ViQ9YD8huiHkyL6UiF/hPDwcC04I910PSkJIz1FkrXLG4pjrN4ihug761gK9uT5JWuIq9+fSpI/ fV/pvtWxY0ftRVZuetB78803gfynKIDszQShLck+llRd3nD9lhSr8qjHo8RQp4GjoFN5UCylNilz Pd0YKVkiOUznl8nasa2VukGxhRyFMmWTIKLltBEjRmhv07G0lERPnpT0lW42dJynR6supSniapkA EygmgewpQSiK9TPPPKPVuHnzZli3bp0WM41iGVGS2OxW7mI2y6czgRwEPEoMedrckoWIHL9JvFDg xaIWyidEUagpRQUFRaNCFiQKo0/ip0OHDrBx40YYMGCAFtSRnsDoyZTapRcXJsAEmEB5ESAfT3od OXJEs3iTpZwsoXQ/I2u3q+8KLi9u3O7NEeBfvJvjVmZnkan4ZoQQdZCWyBxxihxJS+m/8fHxWf3f vn275rBJO5PIAkXiidrs3j0zijdZjhyJT8ts0NwQE2ACTOA6AUozRBs/qNASGlm/aXcs+RmRuwDF L+LCBIpLgMVQcQm6+fmODPfkzEjOi2FhYZrViJ7EqGzatClrmz/lI7r//kx3dW/JieWq00v+Xp4S j8ZVGXO/XI8AiR/yK6IHPdoIQiKJltnIek47Ddmi7Xpz5i49YjHkLjNVyv2kGwktkS1cuBBGjx4N UVFRWou0Xf3YsWPavylukeN9WoJzBDikbOresJ29lKfA6eppRyRlcafdNyRQuTABbyJAD2sUwHDC hAlASaxpd/Ann3wCX331leZTREtrjt3D3sSFx1o8AiyGisfPo86mJTF6siJnbYr3QbGLyKGRXlRo yys5MlKhJTVaXqNCAoqCpVGhre0Uw4gKmbe5lCwB4tyvXz8tmi8F5vvuu++gcePGJdsI18YE3IQA BZ6lF92baMn/t99+05LF0oMaxVcjt4Dcy2gUey0mJgamTZvmFWE43GQqy72bLIbKfQpcqwO01Z4E 0ezZszVzNCWKzas89thjWW+TU7ZDGO3evRvmzJmjfUbRVh1LOWTe5qe14s01cab5ICFEhWKWkDCi 4JrMtnhs+Wz3J0BL/vS6cuWKtrxP9yGyIFG8tSFDhmQNkB7kFi1apIVq+Oijj9x/4DyCEiHAYqhE MHpWJWRqJp8hei1evFjbaVZQoS2v9KLSrFkzbf2eyrfffpsVJZvCBNAWf9oNQlYnCgpJpSTjHFGO I0/N/0MOowMHDtSCa2YvlGKGnN3JsZRD/XvW95BHc3MEgoODNd9GetEy2jfffKOFJXHsrHUkuqbv DEWFbtu27c01xGd5FAEWQx41nSU7mGHDhsG7776rBYCk7axFLY5Aj3Qe5U8jXxda5qGt/RQYkgrF EHHEOKLt//QUlz3uiLNtUt4fSrVCZnIKFeCOJb98TBQr6tFHH4UtW7bkOSzyHyIL0YoVK6Bhw4bu OHTuMxMoFQK0hPbyyy9rfkX0MEaJqykFCJWLFy/CW2+9lbVZpFQ6wJW6DQEWQ24zVeXT0RdeeEGL dXSzgsjRa7LY0It2rc2cOTNrMBRUzeFvtGzZMs1hm9b7+/Tpo4kienXu3LnAwdNNjcTAn3/+qfkN UPyRBx98sHyA5WqVlg8pwWhBhYQh+f6Q9SevQjdxEnsFlb1792pLm+QvwYUJMIGcBCidC1mladOB 40GMjqD72rhx47SHMC7eTYDFkHfPv1OjHzp0aJaFiJa4SnJLd7du3bL6QAKI8veQbwxZpByFEjlS odxUdAwV8muifpBIoGCRJISoUGh/6iPtLCGfp5sp+YmS7HVdvnwZaOnPmVJYBm5aMqQdfPnFSyHL GQk8eqolYZpXoThRtAwwceJETUxSxHHK++Qt6TqcmQc+xrsJ0IMC5X7LXmgH7YwZMzRrNRfvJsBi yLvn3+nRk4WInA5p6Sw6OrpUdjCRwHGkFpk6dWpW32j5i5bZaIv/2LFjtffJR4msP5Rn7Y8//sgx DhIztOT25ZdfQu/evbM+Ix8Bik9SUKElqZ07dxbKhfrpjPWJtr5TAtmSKLRrj4QR5ajLXsgiNGbM GO0tWiYkB1IKgUD5y8iPiJ56SXBlX7Ysif5wHUzAXQjQ0hjFJcqrkEM1LaWx75C7zGbp9JPFUOlw 9chan3vuOS3qK/0o07IUxRoqi0IZrB3F4cy9Z88ebRt/foUsTOTITcfT8hwtt9E2W4fjdn7nkXgh C0xhpbB6Cjv/Zj6nMZCPA+Wrc1jOsgshqpOSXVJ54IEHtP/Srprff/9dS2VAu9BIcJLViCxNFDiT gjdyYQKeTmD58uVw/vz5PFN4ULJYesCg71Z5fK89nb27jI/FkLvMlIv0k4IrkhWCfoTph5QSvpZl cdysaMmMMlu/9NJL+TZP1iTacn7fffdpIqCs+1paXGipjHaRkTB1WIRyt+XgdM899wC9qJCAJCf2 pKQkbVsx+VHUrVtXi9FCMaW4MAFPJUAPcgWlNSKL8c1s3PBUXt44LhZD3jjrxRwzbV0ls/K8efO0 qNWOlB7FrLZIp5O4GTlypGbxGDVqVJ7nkh8A3QQ9sZBJPyIiokhDc0Srvvvuu7XzKCYULatR9F5y QicfIwpUR/PboEGDItXNBzMBVybgWH535T5y38qXAIuh8uXvtq2THww57b7++uvaj2h5WV3IMuRY +nHAJKsI+TcVFh/JbeFjx0mEkm9UcTJ3UzwpetGSIm09pjpp+Y2sRrRFn56UyWqUfZnSnZlx35kA E2AC+RFgMcTXxk0TIJ8TshBNnz4dKOAhOVbTf8u6UEA1+iGnJSNHfjVPFkIlzZfmzGEJSkxM1Kr/ /PPPNZYU+oAsbCSKyLJEwpcdTUt6Brg+JsAEypsAi6HyngE3bz80NFTbmrphwwbNj4gEiZ+fX5mP ipbKqA+UpJF2vnEpHgEK8kiFYrJQnKP169dru/PIWkTBHWkpjUQo7W4jgcSFCTABJuDOBFgMufPs uUjfaanG4aRM+YAoZk55pMUg5262CJXsRUFLjiR4SRw5BNIPP/ygbd8PCwvTxBJZjFq0aKHtLqQd e1yYABNgAu5GgMWQu82YC/eXstWTlYCy3lNU15IMzujMsGnLOQVdpOCDXEqPAO1io0KxnMiBnZyw N2/eDL/++qsW24gsg2Sdo/+S4yoXJsAEmICrE2Ax5Ooz5Gb9ozg35IA7a9YszXLAEZDdbAKL0F2H 2CWrIL0osB0FxiSHbPIfI4thp06dtKU1csKmbfw3W8iviWPA3Cw9Po8JMIHCCLi8GDq+6TOY9elm EA014PkJY6BVpcxs5/8VK/y0YA58s/ccGPT4WY02MO7Fp6GGf2FD589LiwCl2KAdXpQdmrZqU7JE Lp5PgJYp6UWle/fuWkwj2tVH1iPaxk9WOxJNDkdsinPkTDl48KDmr8QRtJ2hxccwASZwMwRcWgyl HV0Dr0Quh6dmTYYqu76AyAlxMC9pMtTzF/4bq+UI3ij/hGZjJ8ODjfzBLpqgoulmUPA5JUmAkqvS ktmUKVNg4MCBTqWuKMn2ua7yJ0C51sg6SIWEEaU6+fnnn2HlypXatUFpQsgfiSKF51eOHz+uBcsj MUU7F7/44guoWrVq+Q+Oe8AEmIBHEXBpMSQYa8HYGdOg0x2NAeqfheiPZsGhSzKKof+6rZw7CSn1 a0HjUBMoKISa4b+5uAaBDh06AL0o4jFt1XY44LpG77gXZUmAhBG9HIEfyfGaMoZTfCNHFHFaYqW4 R3QMLYlRhvFevXrB/v37ta6SbxLlg/v+++9LLN9bWTLgtpgAE3BdAi4thvxqtIRONTCNwPrPYe6s 16BBz0joXCdnl0/8uxOObN4AXwZgkk97BtTu+DAMGdATgvIZGfk5eMtWYPLZcIXcU2QdoAzv9CPm yJlVGl8JmtfyiHNUGmMprE5ahiyPEAaF9cvZz0nsDBkyRDv88uXL2n/JavTZZ59pOdNoHindikMI Oerdtm2b5rj91VdfaelEXLVQyhS61h3Lhs7201W+s872t7jH0Tx7y/24rDeUFHduvO18lxZDjsnw D6kKPR8fBD/+ugHW7u8MvZsEZc1T8C19YfbbD2FQuEb43gWY9MxI+Khqc3ipS+0cc0l5mZKTk4Fu pocOHdKeMj29/P3339qTd3mPlX74GjdurKXvOHDgANASGjnZknWgJAstqdCOJlf+kSyp8dKSEwVE JGuLOxdyriZhR4UCP9LS2bfffquFZ8ivbNmyRbMQUVwrhwAuTBjS9Ub5pwoq5NtEr5stdJ2HhIRo flIUvPKOO+7Q/p2enq5tKnCm7NixAy5cuFDu31ln+loSxxw+fFizAJb3PaokxlJYHTt37izsEP68 HAm4tBiiH0u6wdS7tbP2OvZjd/hyzS4UQ5mZuakE1WgMd6H16PpfUAfj/e3fdwoglxgiEURPmfTF ox/N1atXlyP2smn6n3/+0eLBuMJYaR6bNWsGf/zxByxevBh69Oih7TSjjNElVWgnE2Vmp4CAnl5O nDihiSFPtITRmEjskG9RfuWvv/6CVatWaZZPCrZJIrigQsu1FJCzoEJhAAqLj0ViidKg5BZNFHyS RB2FlaCHLip//vmnlqbm+eef13bSOXOtUwLea9eulfl3lr6LFJqiMMFY0t8ryiRP9+SyvEfRXNE8 k0N/ccRvUVnQd7Z27ZwP6UWtg48vPQIuLYbO/Po2xP2gg7fih4IAl+GKFAzNmuQ0jf/1yRR470gz mBf5OFK6BidSfaBp6xu38DqC8dGPMf2IFDXJZelNQenVTMHxyAr24osvll4jN1EziSF6SqJo1YX9 +BSlevqxmThxovZ07umFbuRkffDU7eaUCoR2ItKyWe5CAujDDz+Exx+n73ymczZd5wUVcsDeu3dv gcc0atRIy8lWUCHBk1+uNrPZDGlpaTecTtZZyvnmTCGBRw9rFN27LMvp06c1x3QSCmVZaKwLFiyA adOmlWWzmoWarNVlWeiel9f1XJZ94LbyJ+DSYqhG2/ugzteR8MLYg1BJvQJVeo2AZ7o1hH9+/QI2 p9SFZx9oB0069oPqO5Pg5Yi/wE+1Qb2BQ2DgHfn7EtCPCJnMvaHQEyyZ6F2tkDCl7dL040E/eGQx KolCT7VkCfMGMUTCjywQ5F/jiYWWv0g0kygi/yBHITGydOnSHDvQaKnwtttuKxADfU6Wj4IKpRwh y2JhhfqTe4n333//hW+++SbPU8lXjixEy5Yty9oJR6Ijr7kr7lJdYX3P63MaM/k3kRikB6iy3K1H QrasrVH0cEgCzJE+6GaY3cw5ZPHj4roEXFoMCRUawkTzm/D37mMgGQLg1lubAWVB0je5AzraAzSq /rXaQlRUAmzbdxJUIx7TOvMYLq5NgG68dFOaP3++Fq24fv36rt1h7l2ZEyBnYtqF+MQTT2j/peUz 8sEpaCt+QZ10+Cbldwwt3dKrsLJr164blrwmTJhQ4Gm0REI/vo5lTeoL+RTl7hP5Q5FDuSNyN6U5 Kc3EuLTESPGb6KGJLBcDBgzQRJ2nRnGnHIYkhKiMHTtWi5geHh5e2JTz515AwKXFkMbfFApt7gjN MRVBVetBDrdR/2pw+x3VvGC6PGuItNOGlgMWLlyo5RRr2rSpZw2QR1NsAmRBIQsRWQ/69OkDjz32 WLHrLG4FZOXJXcjp+6mnnoLly5ff8Fm9evU0/6bsFlCyUpGwI+tt9kKihCzXZOGkQlYlCkFQUGnT po0W6bugUqNGjRt2H9LuPRKWZC13lI0bN2pWIvLXohhQpV3IqldWu6woThXtUMxexo8frwnSghz2 S5sB1+8aBFxfDLkGJ+5FKRGg6NQjRozQntaeffbZMl/HL6VhcbUlSIB+LNu1a4c7Ru8qwVpLtiqy +Hz66acwaNAgLVq2o9D1TZaW3EvB9AM8dOjQGzqR22eIRNORI0cK7CztGqVo7wUVWpLLLm6o3smT J2v+VrkL+VVS+IJnnnmmxHd85m6LfJXIGkYW4tIqtGNx69at+YpK8l0kX6+oqCgtdQwX7yTAYsg7 592lRk07LGjJjHyIaFs8Obd7S+wRl5oIF+4MWUtc0f8tOzKyYpE/E1mIKFI2Xddr1qwpkk9cbj8/ Ek2FOfrS54UFNKWdtCQ6HIWsUnkJIcfnlHiXxOftt99eqlcFbaAgh/jSTOhLvnWFWdfef/99iIyM LHMH8lKFy5UXiQCLoSLh4oNLi0CtWrVg5syZ2k4/2p5MT2uF+XiUVl+4XiZwswTIikWCiIRQSW4O uNn+OM6j+E30chRabiQrVn5O35RomXxqSrtQOAxyLCYBWZqFljZpSdAR4DN7WyQmySm+rHfSleZ4 ue6iE2AxVHRmfEYpEaCnRHLmJFM1CaJXX33VJSJol9JwuVoPJUCWjjlz5rj06KiPn3zyiSbYcvs5 zZgxo0yEEAEiIeRM/KXiwuzatatmraPlv+x+WhTok/yyaEMHF+8mwGLIu+ffJUdPjrJkFXr99de1 m7KnxtJxSfjcKa8hQFasjz76SAtfsGLFCm3cFLtq3LhxHsmABBEJn379+mlhKchSRpYxFkIeOd1F HhSLoSIj4xPKgkDv3r21uDC0HfmVV14B2mbNhQkwgZIlQIKIwhYMHjwYWrdu7bFCyEGNdt2RozsF eXz77bd5B2vJXk5uXRuLIbeePs/uPFmIaB2fdsrQ1vuyDAbn2WR5dEzgPwK0ZEaCyFvKfffdB/Ti wgSyE2AxxNeDSxO4//77NUFEgdEox1OXLl1cur/cOSbABJgAE3A/AiyG3G/OvK7HPXv21ERQUlKS Fg+EgsJxYQJMgAkwASZQUgRYDJUUSa6nVAmQzxA5dpIPEe02I4sRFybABJgAE2ACJUGAxVBJUOQ6 yoQALZfRdnvyIaKcQuRTlL1QFOCKFSuWSV+4ESbABJgAE/AcAiyGPGcuvWIkDgsRBYULCAiAs2fP AiXBpEJ5lRISErKy1rPTtVdcEjxIJsAEmECxCTgthpLMMfVSJH0lSeqxIza2g5QYF9M8VQJfDAgD sdHR24vdE66ACThJgJbJyEIUHR2tRa3OXn7//fesP8nPiHegOQmVD2MCTIAJeDGBQsXQ7t27dau+ /WayxQpDFVGsbvT7q3dC/LrOVhnCkJsfyApMiZvxpa/R8HZExNg1XsySh16GBGg7MC2LFVQ4nUcZ Tgg3xQSYABNwYwKFiqGfVq3qJEnyZEkVQBSEk0ZI6WCXpYky/o1P6EcEUOursnWAXRYr4G6fzWFh YTemQXZjQNx1JsAEmAATYAJMwLMJFCqGJEUeIysKCDrjOdFk6CpItg/taA0S9UYwmvwn6m0pDdNt 0jRVVXpgVPfWiOtXz0bGo2MCTIAJMAEmwAQ8iUChYkhVQcEXgE48HmgwXLNY06sr2p+603pf/V8G STqCFqJpoB0EgifB4bG4NwGDweDeA+DeMwEmwASYQJkQKFQMCYJ6Ef1V0fAjN7BZLJvtslqfNI8o 6g5LKReS7XZhIYkjURXWS1LG7jLpNTfCBJCAminA8y20y6xVq1bMigkwASbABJhAgQQKFUN6H9+p Ors0RLLbKqVbhEr0AyTofMBHL6iSRX/OKkuohAyKKurmRkaGX2beTKCsCFAi14IKJWQ8cOAADBky BAIDA8uqW9wOE2ACTIAJuBmBQsVQcnLyqQA/v0g0DT1tlZR0nc6QbvDxe6dKlZAfz544/o0o6v1F o8+c6MjwL8tt7LYLsGnLPoDAWtChTYNy6wY3XLYEhg0bBr169cpq9PXXX4dBgwZB9erVtXxmTZo0 gR9//BHmzZsHnTt3hnvuuadsO8itMQEmwASYgFsQKFQMxcbGyjiSBHphbKEOFsXe3ZKeXO3w4eQh IBq/gEbd3ogZ3MFWXqOVzu+F2VNnwj8BtcH/xHFY//AoGPdoO2BvkfKakbJrt27dukAvR/nmm2+g e/fuULly5az3nnzySdi1axe8/fbbcPz4cejfvz+YTKay6yS3xASYABNgAi5PoFAxRCNIionxyzCI 79sk6I1eGkFZo1LsAAd+ejY2bkNCTHTEkvIY7YldG+CkTwdYNGM4wKnv4J6n4+HeTl9Bh2rsy10e 81GebdpsNkhJSckhhqg/5Dc0d+5cWLx4MZA1aeLEidCsWbPy7Cq3zQSYABNgAi5EoFAxtHt3jM7q o//SZpN6KYIOvVYFDPkrnaYxoNvQY5IqdVBV4f34hMRrURHh35T12Op1HwFzuwNYUy7Dpu9/g4oN 2kCtCiyEynoe3KE9Ss/Ro0cPWLhwoeZ8PWrUKKhSpYo7dJ37yASYABNgAqVIoFAxtGalqaskWVEI 6cFg9F00KXJchKM/C8zmz5Jl+1GrXTLKdv0rZrN5Q2RkZHIp9veGqjNljwxbVr4HC5dvgca9x0JA AWtkFLWYohd7Q6HlIG8ZK80nbaX38/MrcGpr1KgBU6ZMgd9++w2mT58O999/fw6/I3e5Lmis/v7+ 7tLdYveTxltYxPFiN+ICFXjbd5a+r94SAsMbrl8X+ArddBcKFUO4dywMYy6CIOpP+ehN07K3NCIy 8sxsc3yCXVKicft9N73el/Yxb7jp3tz0iTro/Hg4dH50EIzq9xy82ag5TOrTMEdtCxYsgL1798LJ kyfh1KlTWoJPTy+HDh2Ca9euaTuqvKH88ssvcPnyZahQoUKBw6U0HXQDJutQREQEkK9RamoqNGjQ AK5cuQIKXfAuXtavXw+vvPKK1/g/bdq0Cfbt2wfVqlVz8ZkpXvcOHjyoXYv//vtv8Spyk7MvXbqk 3ZczMjLcpMc3383Tp0/z8vzN4yv1MwsVQ9l6QEaYvNafsr9XcOCXUhjO8b9+gsNKY7j3dnSk1dWG RlUC4MSFG41T/fr105ZINm/eDFu3btV+SDy9/PDDD1pG9+eff97Th6qNj4TMs88+C7Vq1XJqvKIo woQJE+DMmTMwf/58zd+Ils7oCc7Vb84XL17U/J+Cg4OdGqu7H2TH8PbdunWDtm3buvtQCuz/qlWr tAe15557zqPH6Rjc/v374YsvvvCK+/G2bdu0zRxcXJNAoWII4y2+hr8ZD6JvUA2rZJmEw8j6ls4z m1vbZHm8ghJIVGEtPmyX+UxbT/8NM99+H1KixkCVazvhsF9reLL3jYH2aLs1FfrhO3LkCDRq1Mg1 Z6QEe0VPXPQj4g1jJWwVK1aExo0bQ82aNYtEka6NWbNmwbJly2DNmjWaaG7atGmR6ijrg0NCQrQ+ ekv8JNohWL9+fY+/lh1C3lu+sxQrrFKlSh4/r3R/ICsYi6GyvlM6316hYqjXg5b1K1foV0s2qbfd mv5sTEzcBXSgPoNxXJqIoL6Aecr0gs4g6Qy6NzBJ6xXnmy6ZIxs/OA5mm96B95Z/DqIpGIZEx0Kb qujonU8hcSDLFC3A8wvdaAoLTOhJFGheaUfZzRSysIwcORJ++uknTRhRvCISRZhq5maqK/VzijPW Uu9cKTRA46XvrqcXb/vOetP92BuuX3f+fhYqhm65JVb+6fOYgYpBXGSzyw+gESic1sLo5iTTqplg 2IdiaDruJFtRXiCadx8Ks3BHGRcmUFwCJIDolZiYCBTBOj4+HqpWrVrcavl8JsAEmAATcGEChYoh 6ntYbGw6/uexpLiY5lcl6JblGCT6WGNjIt914fFx15jATREIDw+HPXv2aKKIltHGjh17U/XwSUyA CTABJuD6BAoVQ4lxcS0tkhSKWaBoiw2Jop+zhqVYhJiYmI74t06vNwmBgb7bcansmusPm3vIBAon 0LJlSxgzZgysXLkSpk2bpkW37tChQ+En8hFMgAkwASbgVgQKFUOqwTAD18T64D7kAgcmigKu6UO3 HGLJrVBwZ5nAjQQoLtHQoUPh22+/1Xa90C4u2tXkTTF++LpgAkyACXg6gULFEIqgTG9kQURnUnGn qkjbrkOhBE/kXSriy3g9NssZTwfG4/NOAn379oUHHnhAC9i4bt06LT6Rp8e88c6Z5lEzASbgjQQK FUM6UXkNt9e3FEAIFAW1Iu7DCtQZfJINOr9wiyX0YmzsYKs3guMxex8B3EEJcXFxWkC8qKgoLeYN xSXiwgSYABNgAu5NoFAxNDYi6kf0C2oeYlKqpNnFqWgeqiso0iMWe/JTgnBVioubtl2S7EvQZwgw AvW3kZFh59wbCfeeCRRMgOL7zJw5E3788UcgR+tHH30U7rzzTsbGBJgAE2ACbkqgUDFE44rN3E12 FF9P098J8fHD0YOoLa6fDbdJ9s74VmfyGcKIvj3w3yyG3PRi4G47T4ACxT3++OMQFBQEy5cvh08+ +USzGrEvkfMM+UgmwASYgKsQcEoMUWeTkmIC01LE0bIC9XDJ7ClZkRUF/YhEveFfRbJ/henswcdH OegqA+N+MIGyIECJXnv27AkbN26EiRMnwu233w5PP609M3BhAkyACTABNyFQqBhKNJtvs9qtb0qK WBGtP9VQBO3R6Y0/6kXDJAxwfO6RZYvP3rJvn3eEdHaTSeVuli0B8iXq1KmTllZg9erVMGfOHHjw wQddPqVH2VLi1pgAE2ACrkugUDGEPkKTVQXaZ26sFzbi/62XJS3lQT98qZ8PGqT/HMDXYPCBgAC/ uRhn6KjrDpd7xgRKj0CLFi2AXu+//z6888470L9/f2jfvj2QWOLCBJgAE2ACrkugcDGkqr5a91ER ybJyN/6LXjcU3HYPVqv4PX7AYsh155t7VgYEhgwZAikpKdqy2Q8//KBtw/fz8yuDlrkJJsAEmAAT uBkChYshALOiqssKq1zB1PWKklbmWesL6xd/zgTKgwBlk587dy5s3bpVSwDbp08feOSRR8qjK9wm E2ACTIAJFEKgUDEUHhm5nikyASZwcwRoyz0leiVfItyVqTlX169f/+Yq47OYABNgAkygVAgUKoZK pVWulAl4EYG6devC8OHD4eOPP4YlS5bAPffcA127dqVQFF5EgYfKBJgAE3BdAiyGXHduuGceRuCJ J56ACxcugNlshr1798Lzzz/PvkQeNsc8HCbABNyTAIsh95w37rWbEggNDdW23q9duxZGjBgBzz33 nGYl4sIEmAATYALlR4DFUPmx55a9mED37t3htttug48++kgTRq+++iqQUOLCBJgAE2ACZU+AxVDZ M+cWmYBGICQkRNtp9v3338PChQvh1ltvhb59+zIdJsAEmAATKGMCLIbKGDg3xwSyE6CAjCSAKFjj 0qVLteSvlPPs7rvzDOfF8JgAE2ACTKAUCLi8GEo+tAW+3/gvqMYQ6P5QX6ieGQIyW1Hh6J+/wKZ/ T4BdxjjZIfWgb8/OEOJTCrS4SiZQSgQaNmwIkydPhh07dmiCaNu2bdo2fEoEy4UJMAEmwARKl4BL i6H0A2vgqUdGQ+3HX4HQ/R/A69/8AUvmTYFmFbNtSZZPwoKoeDh7xwPQvjYqJV8rYPxHLkzALQnQ Ulnz5s3hvffeg/nz52vBGlu1anXDWEwmE1SsWNEtx8idZgJMgAm4GgGXFkNXLlyCzi/OgvEjHkBu D8Olnk/Csl8PwdR+jf/jeOEonK19F0yMGw1NOGyLq11f3J+bIGA0GuHFF1/Utt+/8cYb0KtXL6hZ sybs27cvq7adO3dqYikgIADTBwpaHjSKes2FCTABJsAEik7ApcVQjbufhPEO1wnrVbiWdg3q+hly jPLCob1wbN/3EPfiJfDX+cD9Q8fAQ23rgJAPiwoVKoCv7w1rbUUn5wZn0I+jN+XEImsJOSV7SiE/ ogULFsCvv/4KzzzzDPzzzz85hvbzzz9n/d27d2+PFkP0nfWGJUP6zvr7+3vKJVzoOIKDg4G+t95Q vOH6ded5dGkxlAVWPgczRr8M/zQbBLM718vB22aqCQ88OAr6DesLISn7ISFxOujCEqFPk5xPyZ99 9hkcPHgQDh8+DEeOHMGks7I7z5tTfd+zZw8kJydrL28ov/32G8THx3uUICKrDzlZ+/jk7wRHxyQk JEClSpU8dpop/MCpU6egTp06HjtGGtju3bvh6tWrcPHiRY8ep2Nw586d0/zjpk+f7vHjPXbsGIfP cOFZdn0xlHEaEsYPgW/lnvDV6+OgSq7fhJq394Hw268TrhwMDaRZsH79XhRDd+XATvmgHEsKGRkZ 0KZNGxeelpLpWnp6umYF84axErHNmzdr/jbVqlUrGYAuUguJHUrpQc7V+ZWWLVt63Lizj5XG3rhx Y21+PbmkpqZqQshbvrNHjx6F48ePe8V4DQaDJnS5uCYB1xZDykWYFf4c7KzyDKyd/CTkZUz9d90S 2JLeCp7uQ+JGglSrH4RWv3GppF27dtoMOJxOH3iA/JA8u9CP6KFDh8AbxkozSdYD2qbuicELaYdZ QaVHjx4ebTXZunUr0BjJwdyTi6IocOLECa/5zpKlnsSQN9yj6CHtyy+/9OTL163H5tJi6M/FMTDt u2uQOCsY1nz5BdhkI7Tteh9UuPYvHEgLgnta1Qd/owyrl8wCe0Y/qGA5A2kt28Gj9zTMd1LIWmK1 Wt160pztPFnAvGWsxMRmswE9WXuiGKKx5VfoiZOWye69914gC+gdd9zh7CXiNsfR+Om76+mFvrMW i8XTh5k1vrS0NO176w3FG65fd55HlxZDFVs+CDMiW4P19H44TDGEwA8a22TwSbsCl65mdr1Wx2ch KbgaLPtxH1zzrQQvvPw00A57LkzAkwjQj0Z+hX5MBgwYALTDbP/+/bBs2TJtOz6l/KhatWqB/kae xIjHwgSYABO4WQIuLYYatHsARmSubuUsNe6F2tneqXJLbwjDFxcm4KkE7rnnHs3q5Sjbt28H8hNy OFaTjwmJH1pmoS345Ig7c+ZMTQxVr14dOnXqBE2bNvVUPDwuJsAEmECxCLi0GCrWyPhkJuBBBF54 4QWgl6NQYtc5c+ZoO82yF1EUNZFEr8cee0wTRVu2bIGPP/4YLly4oAkmckTOK5CjB+HioTABJsAE ikSAxVCRcPHBTMA1CJAv2JUrVwrdTn/LLbcAvcgXhXYprVq1CigEQeXKlbX4LuRf9dRTT7nGoLgX TIAJMIFyIsBiqJzAc7NMoCwJUIiF2rVrw7Bhw7RmKQzByZMnISUlBYYPH64tp/Xs2VNbUqM8aVyY ABNgAt5EgMWQN802j5UJXCfQvn37LBaUyoO2c3/66adaag+9Xq9tYSdx5E0RzPniYAJMwHsJsBjy 3rnnkTMBjQClRKAX+RHR9t+NGzdq8alGjx4NjRo10gId0nZ9TwtmydPPBJgAE3AQYDHE1wITYAJZ BMgSRMEN6SVJkracRrnRKOgh+Sndf//9QDnTqlSpwtSYABNgAh5DgMWQx0wlD4QJlCwBWi7r2LGj 9qKdaJRbaf369dpyGgkiiub+8MMPe1Vi0ZIlzLUxASbgKgRYDLnKTHA/mIALE6BdZ/RyRLdeuXIl UF6pKVOmaBGEBw8erO1sY+drF55E7hoTYAL5EmAxxBcHE2ACRSbw4IMPauecOXNGCwb54YcfwuXL l6FZs2aaAzbFOerSpUuR6+UTmAATYALlQYDFUHlQ5zaZgIcQoK34VKZNm6b9lxJRUuqQP//8Ez75 5BNo3bo13HnnndCkSRMIDAz0kFHzMJgAE/A0AiyGPG1GeTxMoBwJUI40Rzl37pzmeE0+RuSYTbGO evXqpe1ayx05u7AuG41G7XwuTIAJMIHSIMBiqDSocp1MgAlogRz79u2rvWir/t69e+Hbb7+Ft956 S3PKrlmzJtx7771AKUSyF9rF9u+//2p51hzl1KlTWmoRElFBQUFQp04dJswEmAATKDECLIZKDCVX xASYQH4EyLGaXuRrRKlBaDltw4YNsG7dOi3Q43PPPaelCKlQoYImgigoZPbEtFTvu+++q1U/cOBA +OKLLxg2E2ACTKDECLAYKjGUXBETYAKFESArkL+/f1Y+tD179sClS5dg/vz5Wq41Wkaj3Wl2u72w qvhzJsAEmECJEWAxVGIouSImwASKSoB2nVHp3LmzFuTxvffeA/I1ImtRfiX3slpR2+TjmQATYAK5 CbAY4muCCTABlyBAW/IpaawsyzBnzhywWCx59quoztcuMTjuBBNgAi5NgMWQS08Pd44JeB+B5ORk UFU134HTtv1Ro0Zpn4eEhMATTzyRdSxFxeYcat53zfCImUBxCbAYKi5BPp8JMIESJUBCiPyG8itN mzaF8PBw7WMK9PjOO+9kHUrb72kXm6Pcdttt0KlTpxLtH1fGBJiA5xFgMeR5c8ojYgJuTYCWy8jC c/r06TzHQbvN6tatq31G/23btm3WcVevXoXVq1dn/b1lyxZYunRp1t8dOnTQAkBSoe35tL2fCxNg AkzAI8TQvrUfwecbjwLo/KHPc6PgtuoGnlkmwATclAAtfX399dewfPnyrBH88ssv0KhRI028UNDG /ArFIHrsscdyfEzWI0f58ccftVhHVEh0UTBHR6GYR47ca/SeyWRymiClIzl79myex1PIgOeff97p uvhAJsAEyp6A24uhf1bOgiGjl8Ej8WYI/OsdeOq5g7DkwyS4rSoLorK/nLhFJlAyBNq1awf0chRK 90HxhZo3b17kBsjK5CgklBxiiUTSH3/8kfXZ5s2bYfHixVl/kxXJ4X9EaUUKsiJNnToVDh8+nGff qA4WQ0WeNj6BCZQpAbcXQ/rg+jB+wUfQv1sLgEfvgv33D4SvthyF2x5qXKYguTEmwARKj0B6eroW h6gkC4kkimvkKPRvq9Wa9fdXX30F27dv1/4moZTdj4miapPvkqMEBATk27XsYqwk+891MQEmUHIE 3F4MNbpnIDRy8Dj1J+w4nwZP1gzOlxCZxr1la643jZUmnObVYPAOiyDF2sm+xFNytwTXrKms5tbH xycLwOOPP57175SUFDh48GDW3z///LOWiNZRzpw5ky+4gmIm5T7J276z9H31lvuxt9ybXPMOUniv 3F4MZQ3x4nZ4ekQ0+D88Dh6/LTTHyCms/4ULF7T3Tp48qUW8PXLkSOF03PwIckClcXvDWGmqaEs2 LVV4Q/RichSmH+fg4PyFv5tfvjm6T9/ZY8eOQaVKlcplWPRDVqNGjay2Bw0alCN3Gokjxz0mdwfJ opT7O0iWpNxilqxflION6jl69KhWTUEhBooLoiCRVprtZu83jZOWK73hHnX8+PHiThmfX4oEPEIM ZZzYCKNeHQdSpwnw2fh+8J9LZCa5ffv2ZfkCkBgikUCB3Ty9UHLMa9euaS9vKH///bcWwZjyW3l6 2blzp5bCoihOvu7MZOvWrZpIWL9+vcsMI7uYoKjZ+RUSchREMnv56aefclia6LOuXbtq4pbGSfnb 8hIrJPRL4t5F4s7Pzy/PNkgI0T2jLAQRsaH7c24+LjPJJdgR+t25GZ+3EuwCV1UAAbcXQ7bjWyAi PBKqD3oTpj3+3xbb7GPO7oz5+++/azfUqKgoj78wVq5cqWULf+WVVzx+rDTA0aNHQ0REhFcE3aOg gzNnztR+0LyhxMTEwMMPP5xjG70rjfuHH37I1zJUvXp1mDt3bo7ukuN2bofr8+fPw6+//qodR0KI YiZRQMnsyyu0o64kClkWKVZTWlraDdVRe2+99ZbWfmmXAwcOaHGi6Fr29ELBQmmXZEkVs9lcNTIy Mn8VnqshszmmqmSFNyUVdHiBgdHXf2dURHhMUqL57nSLPdwqoYGA0uAIPp/FxkR+TKcnJcbdm2aR X7VJKuXHoQ9VHx/fk1Zr+iuxsbFKUlJSsPVq8t1WFYbKKoh4jKrT+6iCyS86Ojxsd35jxb7XALst 2iIr1TOvd52q8/HZGB0ZkZj9nMTEuI42izrWJslZ7eNxZ2SrZRS2L2P7QdaU5LusMryYo329X2x0 ZNjfRWHt5mJIga/fmgQfbQOY2GkLJM1ZB7LqD/c+8iTcXjdv6wA5SHrDMgpdBN40Vhov5baiJ2pv KI6xeosYou9sfuk5XGG+e/fuDf/++2+eXaHlr9wl9245x/eVhAht0R86dKgmVBYtWpTjfkVWT0p0 6yj0N+1UK2q+tnHjxsG7776bL7q4uDioXbt2qaOlOaVr2RtKSV6/iXEx7SRVXB0z1fx17ORIp+I2 6CUIQEkxECi4O77sdoWik8bIkq2GoqoPZ84Bag5ROIT/+NgcF3O3XYHlGNbrv+2YeKLVhmlyBGM1 POYRKT0t0gZCuKxqYkkrWB+IVqF1nDlpAAqSHbnnNjExYZgi2V+zy0rWk5yqyiDZrA/HxiWEKFJ6 FAodNQ7HqCrwJbafze9FBZkCsur01H5/e0baOJsiRN3QviDcFmdO7B8dGZ65A8KJ4uZiCKDDM9Ph 8+6XITUlDYUQjdgEQb5uPywnpo4PYQJMwFUIvPbaazBgwIA8u+OsYCXn7SpVqmi71hzb+PEJOked JLj27NmT9R6J/5EjR+ZY0rrzzjuhceP/dtOSfxJF4s5eCloCo6XXooorV5kHb+gHCqF7rAqskBSl Igi2ITFTZ6THTp7wcqFj14MCNiDliT+QKqiKJOD1VVGUoDIKDs0olJkERzj/YVJMBVkVVsqKGgyC 7rTRYPjBZrMs0ovQHYOejlcE+8Bp5oRNOlmqKymqIIiGi6piv8/XqIu12eWHcCm3gaiTKOBXDjGE 7YUIihyOlh4/EPW4dVMfZRJtl7D5RXaJOiEP9fML+Q3b/1VQhdVYN45Rdwbb/wnbfxfb74LtRyqK +vC0+IQtOkWueb39ZGy/B7Y/EdsfKMtSHVE0DMb2vUUMiVC7WTt8FXoZ8AFMgAkwgVIjQMtanTt3 Lnb95A9UkE8QbefPvqWfGqRt/tkLLdlRcMnsZcWKFTn+piWbgkpgYGCxx8IVlDwBFELtUQh9iRab TGsNmk5AsY6KmTpdHzt54otOtSiIaPxR0QaktgfR92kQpaGKrNDf18UQ6C5mGIcoii0YRQ4IJt/x URFjHWHcNyTET+2VbpPvUiUFz9dhk3iuKPr4BIX6t4ALj+9JEUfLEsoRSf0td3+MevifJUPGtV4B DEbTtkmR4bPpmNnm+HQcyS2SJC9OT08+cV4xouCxVRRE3P1tMkXhct6i63VtSJg+tWeGVe6oKPKd OtxVi7Yoat+I7Qd1Cb3w5PrD4hgZFZIkq5uc4nH9IDahFIUWH8sEmAATcDECuTcMPPLII0Cv7GXd unU5/t60Kf/fCUp38uWXX+bYudeyZUto0KCBi43cu7qTEBvTBxeIlqEBJadS1QSRbURM7DQTKLqx sbGR/4VczwsROsjrMQwJLi3h0pQ9XQ9Yo2gEUbWDQqYhEXxQFvWnf4s6/IMsStmKqDOoIgoQGds1 6HTHdKK9rixZA61XLv26TRV3iXrjEjx8UWx0+KXczRtASsugJMwoyLD1aMfnYyOjPsN/00srieb4 JzPb14FRNORsnwQatq9g+4JOdxzbr4Pt+2P761Yna+0vwyrex/Yzt5A7WVgMOQmKD2MCTIAJuCuB bt265ej6smX0e5F3ITG0f/9+oNQmjrJt2zbIy/eJPm/Tpg107949z8qojoJ2PJbFjjXqWEEWN1oS pPhOrl5QEdRDHZGPyY4EhtoSx0B+OAWLITyARIaCfniCaB8sSUINvQF9qmU7GXm0gmIo+3ZrMr9k FWrJ8Ydq8p3kI1su2RVhkkSWIoDWimRJRJUSFRNn7hMS6HvCkpoyNsOe6Rem1wm3on+SVgP6ip3M j3mu9gXcQEF90KMvkQ1PvZ7FGW1ZJt8p2P5pbD8K278Hj2mF7Zux/ciYuITHQEpfQ/5Hzsyt618B zoyCj2ECTIAJMAGnCRTkzEtiiHbbZnfUpqCTJJDyKnv37oUpU6bk+Rn5QOW3A44S5lLsprIIRrhk yRKgHYl5FYoZlZiYYxOT0xzL8sDImNh5CXExFpsMC3FH2H8ChZx9RP0GkAP6xsaGORFHRUDNo8fJ tIWqgtwZF5nAIKh7sJaGOB5MyCeiShK24t/tVbS+oG9Sag4xpOICGL6hbR1LT2+fbtMvDTHpH82Q LLKkh1BBhiV2VW6DtX6KIhSd3oSs7czahjU8j5bkDAZfcogbSHXjrrWWV9OVunjtrUXxgr5Ewp94 XDNqX1HEkyEmaJ9mFz+PnTp9lVGQAkiz0QIdKnRq/wNs/wlsX8L2K2L7i7H9O0RB+c4YEEpZmfPO k5Nr8lgMleXVzG0xASbABFyAAFls8ksTQo7cFGcouxgiH6Lbb789z57T+0899VSen1FgUPJhyqtQ GAESUhQfLPcu0Lp168JDDz2U53nUF0fOOGdRUiqX/IIeFhQ93Nn6y+q4iOjYd3G5jJp7R1MkmhAy /gyGio/ETh7hhBDKPMcmq2/7COrDNrvUERfNQJFhtk5VY/Gz2qg+rFVEu/mETnjFjtYiW5oaHh+f WEMUpa/RxDbDapeaamJIp7uqSpaX8J8vJVvF7wBCBoXok3VpqmCh3UwoeAJtiu4vPOd///HBLf06 YaZVVmrYbdZuaL25z6RXLqGAWY1WwlBBZ9yakDB7sg/YJth0wv/ssgSWjKtjQNVHom/TNVWxPo97 2TQ5pdPrTqqyZRj+MQzbX4PtP4LtQ/r19smhCu1ROaxaBc0Ti6Gyuoq5HSbABJiAixAgSwglv82r kDN4SQUuJatQQbGRvvsOf0Ox5I6FRtHG582bl2f/KP5Rftv+q1ateoO/FFVSUOoad0trExGjCSI0 6AjvS4JhM1SoOSA27JkrTlxaZJTRfvP1oj5Apwh+tEwpiALuHtQHoE+133UP6oqHLXDepFeH4Vb8 t9EV+R67Pe0ePPZ1vDYMJHNQCe3ViaaeIkjTZUV6WlbtfbQcABbQowjSkeOzKOrmRoaHbcTm6JVV Zs2c0UaxWMeh0ArGxbIfrLQNXPufgEMSkxXF/4+wyLGXcWv9EOzae9j+/SiAOgkK+GWtd6HPkU01 RPgKUnudIL2M7WOSweRL2D6eouoFdOwWBXGOlHrBKauQxsQJgHwIE2ACTIAJeBAB2u7v7Jb/0hw2 CSVKsZJbMNHf+fkh0ZJd7t1xjj5SROsXX7xxU9WuXbtKcxhlXjcKokXmuLjjkl7c4aQQAszaaMf1 J4ohhEoFLqFYOCZIciVyZtbrlStoHaLke7gkplykgIr473cS4uMMkqyMt8mK5rOD2slm8PE5iRU9 GhkZdiYpMXEGmpX+QUvPcNQ0lPwBIw7p7Li5K17v77M6LzApqenj/Xx81gpgj0ELVW3SY+S8pDP4 /C7bMoZERo/QsiVHR8cuSjDH6tG1KQpjEhlRCCWjRUhBFy8TGn2qqlLGUtUYMNpXvToyQ1Yicrav m6H3N62KjpqQw/m6oIliMVTmlzE3yASYABNgAkTgZtKL0DLZ4MEUQibvQpG8cxcKMEnZBzypREZH ry3KeNBqQg7LzWkrumS5Ro5AC/Bv3JhlRdcbfBMAMw+jdpAsWQIiIip6/tKYmHf+8xZDNWTJkKZO naoZacLCw/fhf/ahP9asrL6g73VMdAR6Y+ddYuncqKjVzWNifhh03fWHQgRMjppwwzkRkTHvYPsf ZG8/KMhUNT1VHoN74FB82beER8dswvb/iyCqtT853/bz6xeLoaJcTXwsE2ACTIAJuDQBctrOXbLv jHPpzpdi567vqipIJORpRRkcG5vjHBRCN/QS6y6y+NiH1qfYrP1r+Q88d/t4JIm6MdnPuJn2c7fI YqgULz6umgkwASbABMqfQEFperwlhU/5z4Jr94DFkGvPD/eOCTABJsAEikmAAkbee++9edZCcZK4 MAEWQ3wNMAEmwASYgEcToLxx+eWO8+iB8+CcJsBiyGlUfCATYAJMgAkwASbgiQRYDHnirPKYmAAT YAJMgAkwAacJsBhyGhUfyASYABNgAkyACXgiARZDnjirPCYmwASYABNgAtkImM0x1TGkEObtwrRe GGXcYPLbPmnC+HFJiebO6Rb7FKuWOAyjSwu+S2JjIhbRqbMTYh/MsKlj7ZKamVIMs8EajaYTNlvG UMohZjabq4BiuRcDI47AoIcUmFHR6X3AoDdMiIwM35rfBCTGxTWWVGWKBdNyUL2CoFN0Pr6/R0eG Z2Wyp3MTEuJ62W1qhF3CWNjX29cZTacxOOPz2L4Fo1S/IsvwMOV+xZItXxtmLhN078TGRC119iJg MeQsKT6OCTABJsAEmICbEtBL4IeSooeWcgNfkl2hiNFgl2yVMZN818xhUaoN9U/6V3xczH2yAp/g K+C/IWPQRYpjrTNWiYnZ1CfAR55okYRX5etqhI6TJSul1vjKbE7sn5cgmp1gDrOBOgejWpPA0YqK gRIla3rX2GkJIYq91ujY2MF2c1xMV7sCn2L7Qdnbl+2YnEOnx/Y/7GvQQTP87Hrfs0+Mpo5+LcpU sRgqCi0+lgkwASbABJhAORGIi415VlHhVXzlLDr9eZAbYNb6wbZ8u4b5WMEGmLuU0nCpJECMZnNS VXyntoLhFskolFmtcPHDpJhgzKvxNQoRP0yVcdjHaFxptWa8rxehB2aWn6LI9l5Gn1//lmWlqoSd EXQ+F1TZ2t7XqJtqs8uDMV9ZDRsYHsbKcliH0JJUVVDsr9jQ0oP5y9Ixg8dok95yCQNQf4KpOShj 7MN+fmdXYfu/y6rwrayo/lj5EWx/Fbb/DrZ/r6KocYos9wD9uemYr+wsdVrUGa9gepEHJMmSkqmu cECq7VxRponFUFFo8bFMgAkwASbABMqJAK4D1caf+TY3NK/CFbT1OJmhXQSdqJmH2uHC0v8EURym UJZ5TB2vGXgww+r5DONIWbb5CToDrpr5Rk4MH/vZ9Tb/ToifOiDDJndQZKmlDhOFUXoPFFJ+hgoh zarrkoefThG3yJJiVST79tz9NIrwhMWu1icLlN5o2jopMvxtOgaX4x6yW3QtFFn4JD392tlzqNOw fX9qH5fPYiZGjF3iaH/m9Kn9M6xyZ1W1Pyrq9WdUm0QJXqUGDe7dPnhwBy2v2c0UFkM3Q43PYQJM gAkwASZQ9gTys/ykOd8VFbPW60BC5SPZ7Cl6/H8Qjbg6plBmMiyKD2Z+f0DTRZjE1QfzuGavGwUK ZoaXgZbGDDrdv3rR3lSSrP62FPvKw6p4TNQbP8RUqu/HRkYeu7FPUgouyaEWEtGgI010fD42ImYV /pteWkk0xz/saN8o6tAB6L8iiAZUYJRKDWqpgliL1toUyVpx//7VR2JiVmtDQKsTruSZZqAP0jxn ubiNGFIlCWScQD1OQ+5iT7sK5y5eBjSzARj9oVb1qmDMgc9ZHHwcE2ACTIAJMAFPJoBJ4nV6END3 RxBtL0iSUEuPzjeCjOnFsrKT0TpTVrnxR5cEB75UP/8Yk2o5bpOEKZKk3I0n1VEky2SQdeExcQkP h4aIh1KuWCdb0MOaik4QmuECnXayJEmYKza/kqN9FROx6kMgJCAsNuwKKqEs689/q4UqmagqU5ey 1ehXlFl0CzGU8u+3MGb0rzDyczO09c+tci7D/JeGwlp7ZahbEf3Bat4GE0Y9BzWzuXwVBQgfywSY ABNgAkzARQnk95ttKkp/ZRB34vE1FEFpp6AyMYD6J+qTFvgeCggRlYu4Hv++S0FNYlGU9Ox14/IY mR0yt26lpPROtYmfmUzG51AEXTGZIBR3rH1qV+W7BFCWWq36WKznacf5dGKmskJvIYPJjP/oQ38l muPuTLcpDdEfaSXuEruGtW/A45pS+zZFPB1qgjuv2K9+Fzs1/ke9IAeTUkPb0nlBhUtYZXNRb7ps 1PveYrEkX9VqVyRAq1COfhfGx8XFkB12rV4EL0Ukwr6zbeClvMw9yYdgR0ZdmLZsDrRma1Bh882f MwEmwASYgPsSSMaun7ih+4JwFv2ic7tV5z1KdPCxy/Chj6A+bLVLncifGh2o5+lUNQ6db/zwD1uA aJtl0Qnj7bJdUNPU6HhzQhNFsi3XiTDLZpNaUEM6vXgGl6dI6Dxrscq/AJgG6SWLSREE1Fbog4Qf 2BSfzYqc2ve/jgjgoxPewi31texWW+eYWHN/kxEu4Zrbt6qqVhBF456EhNnhPmCdpNMJz9tlSZQy rk5KVvXhoiidVhXboMx1QpRieuMS1Z6Wiu3EoElLkCQ7WYK09TMqMWZzEFgsF1BckdN4ocXFxZAF /jh4CYaMjYB13/4DaWk4zuCciif91DFIlvfDpwmJsNo3EPo8NRRaVGZVVOjM8wFMgAkwASbgVgRs CizEDr93Q6dxiQt3khXsPCxpxhztN1+v1wfpZSHQSo7T6Hqi14vBqh230GtySq10xgKXjKI6GD9a rKhSW5tVbosCZwbuAaNt86iEdH/aBOjlp9cn4M6xF2TV3gU36Z9L1WQH1alHP2zx9cjwUdo2/exl dmJCOyXDMtkm2wPxnC8tuFM+s+DynV63Nz1d91tEbGxKfGzMY9j+Umy/M1a75b8lPDoU7U6qjhy0 21B3UKiFoA3pYPZ2dLRDLjS0Kb6335lJdnExFAhDRkUCJG+CNct35VgMdAzu7NmLYLJWhka3NIGK qcfhw3mJ8L+Xw6FVpbwFUYUKFcDX19cZNm5/TEBAAPj5FWnZ1K3HbEIbbXBwsFuPwdnO+/j4QEhI iLOHu/1x9J2l766nF2/7zgYFBQF9b72hlMT1i1YOsnxkWT+Kws2gB4vVBjtQrNCP4yncUrZHsMuo WjQxdE6yw1/4fhX8/CS2Q7Lo4wRznB59gcbbJIWEFBqPQDL6+JywWeHJ2MmRyYmJiWaDLO8QZHWE hH7ZmZpGLwlgitOLBrQW3VjGhkfEJJrNawSwTkExVjvzHFFCh+ffZWv6yNjYCZq/UlRM7BcJ5liD XYIou6RQ3RQVUsENbP64DlZflTKWopf0HrDbdlMN+Mrp6I0DQdHn9O4yFxdD10Gm5x86oUGPEfAx vjKLHfY/+wh8+sMeaPVE6xyz8NFHH8H+/fvh6NGjcOzYMbQyFcH5vihXnAsd+88//8CVK1fgzJkz LtSr0uvKL7/8Alar1SsE0W+//QYRERFeI+zXrVsHR44cgVq1apXeBeQCNe/duxfdMFLg1KlTLtCb 0u/C+fPn4e+//4bJkyeXfmPl3MKJEyegZs2a5daLsMhYuqjaZOuAtq09W/kkd+ciIqNpS7tjW/sN fQ8PDz+Mb9KOLad3bVEl4ZGRG/E/PQuDEREZ8zEeQ6+ssmCBuVLyJeUl3FNlEH2Mq6dMivq9sHqc +dw9xFABI7lwZBcki7WhSd1gPAojROFusmsUVjxXufXWW6F27dqwfft2tPDpoHv37s7wcetjDAaD JoS8Yaw0Ubt374a7774bqlev7tbz5kzn6Qekc+fOXmEtIR6HDx+GO+64A1q2bOkMHrc9hu5NFy5c 8JrvLM3r5cuXvWK8u3btgrNn0bWHS7EIjBgReQkrmFqsSvI42T3EEHqGp6WmY1yEzBFYUq9AOkYS r1jBD879+QVMWJ0Bs+PCIDB1PxzzqQzd725yw1BbtWqlvUcCISMjA7p0wSVODy9k/Tp06JBXjJWm 8ptvvoGuXbtC1apVPXxmAb744gu47777vGaJgSxDJHTbtGnj0XN77do1OH78uNd8Z8lSQhZsb7gf 0xLoV1995dHXrzsPzj3EkF9V6NztTqiC4SupHNz6Hfx6tQG82P9uuOWRKJggzIbZ06aB3qcCPD56 KnRu4J/vnFjQW8tmy3/ZzZ0nM3ffvWmsNHY7xrJITy/Sbkq3nW4aK4ldb/G3oPHSQ4ynF2/7ztKc 0tx6Q/GG69ed59E9xFClW2Bc1C1ZnG/p9j/I+kswQsdHIvHlztPAfWcCTIAJMAEmwATKi4B7iKHy osPtMgEmwASYABNgAh5PgMWQx08xD5AJMAEmwAS8nQCltMAgBnUcYX1wiT0jMjLyTFJSjD+uVlb9 L96PKTk2NpKCO2ol0RzTIDUrFhCGVjSFpEdGhuXwBDfHxDT4r94AiIzUdpnlWfDYmnisD1Zkwfxl p/M7LikpyTcjObn6f02bMJyI77mwsLAcW8GTzOZayRYLpp/ILCZTwe3n1x6LIW//hvD4mQATYAJM wO0ImOPjX5YU/1+io8MotUahJcAEtTHO0F7cdI2JyUSQQLcOT+op2429FUn6VEtMhu9j/KF4fB+j OgPMmBY7264Ir16PTYTvYPRqKf1kTJy5f2x05J9JiYn3ZmSkP4sBGJ/CQICaU6/VbpHj4hMmREdF zMqzUzr4WFCEu0VZR1vi89zJhIIpRDXoltsF6Iz1ZgYNFGxwLVX9LSbGPADF2gV6y2yO6yFLCoUE oKBrWvs2rX1zdHRUJKX7cLqwGHIaFR/IBJgAE2ACTKD8CcxOMA9VZOUNQWc9smnTpiYdOnRwKuUE 9txH6z1FT7RrKcYwZ70N048JOaIUL42JMRzTi/E2WRmjqgJFk1Yxb9gujD9dV5astTCw4g9x5qR+ RiVjjE1R+yoqZgkD9W9RFNpg7jIM/qxLjEuYfS46YmxeMYrIioPtqYa8SJrNMaEyCia7Xe5K4gyD TV9SVeWUoCqtZbu1I+gMX8aYkx7xU5Jbo+/9VzgKfxGTuCuKTMEXDdh+U0VRp8fGJYiKVGsmRuZ2 ykOfxVD5X9fcAybABJgAE2ACThEwm80VRVl+CfN2oZ4Q6v+04bfBKIY+dOpk1D6oLvQCiiGM4tzU nJjUUVQNDykqpm5FPXM9VX1KcoC+npIhh6uUDF6n/8TkY1ocETF2VVxMTFvUJ9/YFam2oFo2oAjC tBhoEtL7nouJntB2tjn20Qyr+gF+7geSIb8Ik45AgHlG0hYVcahdVbqDoFNEnX6Wn8nvg/DwsH3m uJhnMKfau7IsdxR11pEo4LrLquoPgmGfXq97Kypq8lxcCvTBFKafS7LcV1Xt0/QBp79ALv86w4bF kDOU+BgmwASYABNgAi5AwAhSnwxZvjUzjZgEsk3/EgqkFej/k+XnU2A3UcBgElRcfVLrojXlbgHk niqaX7Q1Ji0dveibIYlTZRRbot4A+kD/ZRFhYavo4+jY2L8SzdOOSRZ7bUxeT2k8tKZUxV5l6nTz O7JVfN9k8rvfbkndq9gM+Vlk8k0ouyDJXBcFWJiMmWN1RoNaoVYNc9gzz1yhNmrUCfnqzMlrb2XY ZL2oSqMw7qAfWY6MJp99URPC59IxmEbEOjsx/vuMDHtfu4z9k9VYfPtxZ6aNxZAzlPgYJsAEmAAT YALlTAAtHwY/gzhBUq7rCbLwKLZ2NsWXUlug348zBZ1wMJGqJCt4qk0QFMUiiD6AC2GAb2GhPGRK bU0XoY+QXpZzJAVUBZ0BPYcyc4XqDZ8aZfttdklqLFulF9Cx5wWL1fInqqiPY2PC5tAh2OeA7L0y 6XLmEMv+mWSXfHDFLZTeo7bt51Mq4T81MZSRYcIlvjTsm4wGMbUivYepXXG9Tc1yntZ6r+j9UeDh v1Q6MjP3mROFxZATkPgQJsAEmAATYALlTcDPJD5ttSqNs5tWVEUGQZUSzImJByLDwymTeyGFss6j D7VsQcOKHCXJoq9eh9LjP68jPOA/HyLURzksPJQkPlOIoNwwmj6LGj/+8YT42DCrXe2IS2YV0Fp1 Hy6c3YE+O5WCAn1+8tXrv8rARGKZBR23VTUArVL59pEEjqMYDIGpuJvtznSbsU5QUKV9uChHkVd9 sh9DyVuzV4ZqidYPtbfwuLwztufROouhwq4b/pwJMAEmwASYQDkTwJ1bzSRJHYcOwzf8bquSva6i 00eg4/NTg2NjC06xgEtimIR+majC7bIiN1XI+gPKO6qqDkR/ooooddLREToJk9l/ImMqLNWihi5d utRn8ODBVtzGXs0mWX1IfejxADXlanxMTOyjoDe+HjslMokQTZ8a8zU6XvdDjTIRl6pO4LE5xApp qOvC6IZltJBU6WiqXvcFVv2IhMt0yZAsBCjQE3scd+XKuT0ohozkUa2CsAJVTisJs9db7HZfs3lB aGTkiAu4Hd8f/cFDaJkNnbzJUfx1Z6eNxZCzpPg4JsAEmAATYALlRAC3jC9AN5hmeTWvogO0LNkH HTeFkO/Mb4V1UVXUbTpRrW2X1KYkGmTc5o7iojeeR8tPusa+tm93ScJ+9AtqotjV2YcPH+mP/jgr dIIQh5vQKpAgEXW6xeiw1BUVx+PY+AMoisajqApC408XFCvkg7RVsum+skpSth1luK9fgJ9kVWiv yLbauIQ2PKuvuHSHQYK+CQBprqgI90uy3R+uXPs2XYUluJaXhiuCLUlFCaLukiAapuvBin5BEKVK 1u529eJu7F+MThSHSJKC/lRoE9KLf9l8fVYUxsLxOYshZ0nxcUyACTABJsAEyomA1SqNQU+YHP47 2buCwkVEYwptL8+7YGAh/ED7zUfH6Eq4V6syOQkJokiO0JVxMSw002ajhj4UFpu+Jyamp0EU1uCO raaSZO+OH3QnEw+KEQr9MzMqMiIiwRwfrpft49GCVBlPXaAthikoRETDSZ1OPweDM57L3RlzbEwg WqGwGVsj/GyB43MBV7QExfd0eFTYt/GxMU/qROFzdPC+A9u8I/uqGp5rkmxSO0mBeIMOKuGOthGy bK+C9byF2/9Rp+GSn6jbokpin9hcARoLmjoWQ+V0YXOzTIAJMAEmwAScJYA7uZzwB8q/NkkPlzBu YZymFkD8CW03x0V0lKYdWXo9/CbZMNCiQGJLWE+1RMbGHpuXmNg3xWZ5xmLTZA468+BGfKPv2ajI 8Hn0RrrFNitEr/8+DZQnbLjXXWtdNKiq0f/NqMiwM/n05g18v871z7IchATc2i8q9r30flRM7IrZ CfH9LBap4/V6VYx1RLvg7lQk5T7s8lzwC/1hUvioFxPi4w9bbLYgWhjDU1WDwQj+/r5vYqTqi86y peNYDBWFFh/LBJgAE2ACTMANCURGxtLW+8nZuq6JnmxlS+5hjQoPP4DvTcpvuLg0RbakPQUdk/vc yJjYt53BNzYiajUeR6+sQr5Lxw8fbobSTJAM0gn6ICIqKtGZ+go7hsVQYYT4cybABJgAE2ACTKDc CZATN3ZiR2l0hMVQaVDlOpkAE2ACTIAJMAG3IcBiyG2mijvKBJgAE2ACTIAJlAYBFkOlQZXrZAJM gAkwASbABNyGAIsht5kq7igTYAJMgAkwASZQGgRYDJUGVa6TCTABJsAEmAATcBsCLIbcZqq4o0yA CTABJsAEmEBpEPAgMXQJfvp8B7R46F6o4YMxpbgwASbABJgAE2ACTMAJAp4hhtLPQFLEMEj8yAjf D+wKNZwYOB/CBJgAE2ACTIAJMAEi4P5iKOMkvB4XCd8d1kOjNrUwLCVG5Dby5DIBJsAEmAATYAJM wDkC7i+GjJXg4ZFmGKkegefHrgCLDQdegBgyGo2Yh8X9h+3M9BoMBq8ZK/HQ6XTg4+PjDBq3P8ab xqo9teF3lr67nl687TtLc0rXsjcUb7h+3Xke3V8V6Hyhbu1aACf+hQybjDno8p6O48ePQ2pqKhw4 cADOnDkDe/dq+eA8uhw5cgROnTrlFWOlibxw4QLs2bMHrly54tHzSoO7ePEi7Ny5E4KDgz1+rDTA s2fPwv79+8HX19ejx0vf2XPnznnNd5bux/S99Yb7MV2/XFyXgPuLIQdbWdVS1uZXVq9eDfv27YMT J05oAuGdd95x3VkpoZ4dPHgQrl69Cna7vYRqdO1qSAh9/PHHEBQU5NodLYHe0bW8ZMkSMJlMJVCb 61fx999/w7Vr12Dr1q2u39li9JDEQUpKClitlILJ8wuJehJC3nA/Pn36NDRu3NjzJ9VNR+g5YghU UBVKoJt3GTZsmPbB5s2bYd26dTBx4kQ3nTLnu71q1So4dOgQjBo1yvmT3PjIMWPGQGRkJISGhrrx KJzrOs3p7NmzvWZZMCYmBgYMGAC33nqrc4Dc9Khvv/1We2AbOXKkm46gaN0+fPgwLFy4EBISEop2 ohsevX37dli+fLkb9tw7uuw5YkhVQVYUlEQFl7S0NMjIyPCK2aWxpqene8VYaZAWi0V7qvYGMUSW A1r29RYfKZpbup49vdD31VvuTzSXdA3T3HpDoetXwd8oLq5JwHPEUM0OMPuNFlC1EJeCO++8E1q0 aOGas1HCverRo4fXmNsJHVmFqlSpUsIUXbO66Ohor1gOdNB/9dVXvWK8PXv29JplbZpbWjYKDw93 zS9ZCfeqbdu20LBhwxKulasrKQKeI4aMgVC/YWChXAIDA4Fe3lC8xbnWMZe1a9f2hmnVxlinTh2v GSsNtEYN74geFhIS4lXzSg7xtWrhBhgvKAEBAUAvLq5JwHPEkGvy5V4xASbABJgAE2ACLk6AxZCL TxB3jwkwASbABJgAEyhdAiyGSpcv184EmAATYAJMgAm4OAEWQy4+Qdw9JsAEmAATYAJMoHQJeKcY wm34+YaqLl3epVg7BRXII+xkXmP1yPFnovXE4ao4KCGP0Op5zbj7Ty3GC8Pr+IYrOc+B5XPNl+K3 rLSqzneO87hV8RyX1iyUYb0efj2XIckSa8q7xJBqg98/mQtv/rQf/H2qw7DJEdCumnuH91ds1+Dz meHw2QEAv9Rz0PLpKTC2XxswKBmwetFs+HjLCfDzbwgvTR4Dt4SI8OeX8yDxuz0QoK8MQ6Inwj21 /UvsYirTis7/CWHxS2FQeALcXcsIaae2Q1zifEhOtULj7i9C2BN3A1w9CIkJc+DopXSofuujMG7Y gzjuMu1lsRqzp12E5e8vgJ93n4CLxtowOTIMbq0RAFcP/QqTZ78PlnQVWg8YDSMfuhVsF3ZDfMIb cO5qBtS7ZwiEPdMVfAsKyV6snpXGyRLsXfkOxH+8HUzyVegw1AzPdWsIOtUCvyx9A95efwj8TbVg eEwE3B5qhN0rF8LUz7aBvy4YnoqKhm5O7CQtjV7fTJ1r35gLx+reC0P6tQIl7Qy8NScBdp5MheCG PWD8q49DJUyvl3piK8QmLoRraXZo1usleGXQXaBc2Q8zZ7wGxy+nQ83bn4SxL/TC8d9MD8rwnJTd MDv2Z3gg9iVo7muFNfMnwzsbr0AF+1mo8uBYmPzUveCns8OWz9+E11btgwBDFRgyeSLcXdMXDvz0 AUz+4HfwEQNgUEQMPNAyuAw7fhNNnd0KM+f8BY/GD4f6Bsf5Knz3ViRsMXaHuOfvA1AssHbJa/DB b0fB37cujJgSDm0qGuDvFfNh+pc78P4UAs9ETYIu9XnX2U3MQLFOcaOfhmKNUzv51Pq38Qt3BqbN mQWWNa/BpOmz4YOZk6CyG2c02LNiJsz97iIkfPYBVD+6FB4bNwEaNvscOpxcCO9ukmHO7FlwdFkc TJ27BMz3+8GcLw/BxFmzwOf3BTA23gxvz54GNd1OD1lg8aSX4fUP7fBgOP4aKJfgrenTQd8xGmbd 5wuTxkXB4noVoeLaBDhRbTDMimwOSePDYMbX1WDaI7cX/0Iqkxqs8MXrU+CfhsMxQm8r+C5+KEyI /Rg+n/sQvG5Oghr9Z8DINhkQFjEdvqwzFdI/M0N6y5dh1sNVIG7sOHijeg2I6NW0THpaEo2kH1wD 4UkrYNgby+Bu60/wVPwEaN7mM2iy522Y++NlMON39up3syA+6R2YOag2zFy2HUbPmAVVdy+Bl6dP gbqvzYaGFUqiJ6VXh2w7D18tioOxry6G/u+u1RpaheLgD/U+mDurGyyOfQWmLK0Oc59pBfPiZ4J/ 91iY3EUHE8ZFw9J60yBg9XQ4U/tZmDWxEcwKD4PEb6vBlIddNCK3qsDlfzfA6JfD4JvNdeCBxJfh 8uZFYH5vG4xZ9gXcafkZHnsxBt5p+AUMDl4Fs745CjF4rxI2vAkT58yDWc+3hYRFG2DI1NnQ7OQ3 8CLep+u89jrcUtEF1Z8qw5mdP8LLI0fDr0fugP4zh2ddRJd3fgLDw2dCk1fu0t47tmYuzP8lDRJx rOeWz4BpSYtgxsOVYdZnuyE8IRGCty+CV81x0DgpAWr4ld61yDXfSMCLxJAMv6zZALVuGwHNKmOc oYceguAl8fDrqTTo39Dt1EDWTNbt+Dx82rUa1KyEFq46w2BAna9g1949kL51G7ToNB7qBAVCnf59 YdEr78Lc81ao3vZZuLUajr9vX6j2fhSsP3IFBt/i4k9cua7bs5u+gRVH/eDOTmTVw5vj2S2w/bgJ xve5FWNIAfS/vT4sWDQfgmw2eHRKD+29R+5tCWNX/gKpKIbc4pnr8h7YvE+Ge7tKsPK776BC71fh g9o1IWPvCthzORSm924MgTj0vs0qw2cL3wS/DB8YOqY9BGKYmgF3NQDzdxvAhmLIXfK829OS4QrO TIumIRCqtIYgwwdgz7DAph9/h3p3joLGlXAS+z0ElYe/BnPf3QhBzfpDh9qofmr1hQYLXoWf/jkP De907YCbB375HFbsNsJjTw8A1UC33jOwduNJ6Dm5D16jfjDw/g7w/KLf4XC3VNh7JgDGP9gS8G14 uE1teO89vJ6tCjz+bFcIxGEP7NgcJuL1nI5iyCV/M61nYcknn0OlO/pAd980SElVoF6TvrB41WCo U41yBw6E59sshk17/4bNGb+j5bY/3FKV7ksPQZ3l0+GNBTvBUO8+uK8hXtANH4SW876BNX+fhlu6 uWAssdSjsOiTr6FhlwEgV1XARqkgyTIkXYAPP9wANdtgsMXKmSLu5zW/Q+P2E6BBSCA06I+/QS++ CfMWSVC55WPQriZObPW+UPftcbD28DV46hYXV/cepqi8SAylw7nLIvi0uB7UzMcfAo0inL2AIf7d WAxVqFYfHF+ZMxsWwMcn9fD2rdVhw/cC+IZc/8QvGCrI12DHPyp0uKNS5iWs94Mgkw7Hn4J/uI8Y Uq/ugXkfrocnwsbDqqVvgg19KuznLsE1fTU0O2cOrXLlKnDl0FpIrtwcgq4jCAmuDLa083AVjw9w g+Uj6dxR+HPHNrB8sxYaV1Tg2E8/QPtHX4H7bamQiku8ftcfkEMrVYLz67aCocZtUOG6pq8UUhky riYDJa9wFzEUdEsfCO+xFUY/NxrqW45C9a4vQ8eaOph7WgVT8+vXp28FCAELbNlnhduaXxc+gg+E +Bnh7LmrOFrXFkNNe7wEi3Gl5ItJY2CDhN21X4CL1ooobjJvw0FBlUCwnYPjBy9Cms9/13No5VBI RnF7JfSWrOu5Is6xNSUZruF5LimGTDXglSlvgpC8BZ4a8jFYJRV8K9UGR6jQ9H1fwpvbLkPUiCZw 6WMbGBpdvy8bA6CiwQ6/7E6DFg845tMAFQNMcO78ZRytC4qhwAYw0bwA4PhaGDT6R8ChamXjsjlw KrQ3jB2owPco7AFscDbZCKaK1xNJ4/UcpKbC9n0StGt1PZ+iaIJgXwNezzizLIbKVG55kRii3GXo nJn9h1CQtfc8oZzd+iH0j/oUBka+Be0bhMD3qTbwyfGjL2GYf3QwznLExQ8Fxb3GjzeO5W+9D0LX F2HgA/7wzbsS+OASp4gmefptcQxXEFVQJAkkTAPkGC79V0VztrtkBkpNuQaSEAh9R46BPnVEuLph Pjzx5hKo82R10KMQ+m+suEqojRWdjq+/KQg4fhyrO13ZyfvWw8870+B/I9AKZN0NC5euhb96twIR LSg5vrMg43WsgJLrOnaHnE+ZXZbAil9E7d903WqOtJl3IO0tukZxfHK2m5IgAsg4x3j4f8fiwQq+ 4cpzrA0LRYCE99js/v/XDqyEx16eBbePnAkPtakLby60gJxtPgVtjpFD9pPwXqXIrjra6xOIY6Xf EyNaha7uWgWLNgoQNb8fHJ33Fah68sUQQJLp2nVMLm0UyOt6xrFzDrMy/1n2IjHkB1WCVTh7NTUT st0CGVYRqoa65HNVkS6EAz/MhaEzv4LHJ38AYffVx3PTILSCDS5fu56k1ZoK6UII3NIkA50w6Qka i2yB9AwBqlR2i0WjzD5f2gtfrdoAUjMBXl17HDb9tQcsc96CWo/VgepwGecTj8Er+sqlqxBcrwEu ulyGNJpufOi8huLCxxQMQW5gFaKh+lUIhho1b4GGtfGXkP6uURsqWf8Fq19TCLHvBQv9MOJHVy5f g8qNGoK/cgHSaLrxnnv12jXwC6gL7rT4+8d3y+FApW7weqe2OIi2cMuygfDpbwfhjqpo9bl6PUGr NR1SVX+4pakPCFeSr39HbJCSrkDDUHdZUsj8QVfpx84YCqHGa2DBJSQqqWnXQNAHQM1GFaGC7RJY bPgmOlMnX74KIQ0aQqB6EdIJBRoWruEcm9Di6/KJha7rF4eMObd1KbwwaT60feEtmP44+TupUClE hf04Hq1IGXDVbsL8kQbQXyNLkPYmLrPJmID5ukXl+ruu9h9tbyMqV3oI3f7Tl7Bz32WYO/ZV+Gfz RjionoOvuzSB6ng9H7nmuJ7TIBXt+i2b2kB1XM8qJmDG73HjKi4/s66Gv9j98SIxpIcOXW6Fr79e B5eVTpDx2zo4U6MetMfdOe5czm78AF6M+xiem70Cnrmz8vWh+EPHTs0hftNaSB/cCo7+/CNcaHgb RKNzcSI+cZ+1dwf9pvVwtFJ1GFfPjXIhBbeBN79eCakoaG1n/oS9+45B9wdxjb2ZCPVCFsIPv5+G VjjG7//aC3c/MR4q/ZIE36/fAV2eagarf/8LGnUd5fo/Htdn0Ni0A9xV/WNY/eNJaN6zFuz/czso 9W6HO9q3hx/e+xR++uMKvNDGAqv+OQa9hkwA61czYdWvh+H2fqGw6s990Krbo/Q76jalfsvmIK/f BAcsz0Fj227Yn6yHVk2awl1Vm8EXn6/F5c32cGXDWjhRowXEDKgFs99ZB4cz0Ido76/wj39FeK5J VbcZq4yWIbuVlk1qQofWAbDu543waOuu8COOP7T9IGhcpy36+r0PP2w8D80762DVjv3QeXAEVPhp Dl7Pe6Djkw1g1eYd0LTrWNcXvGi9slntoMcl+dSDq9GZeA50jvwUwns3uj5fAtzV5Xb47OOf4bzU A+D3dXCwYn3cZdYa5r65DnZeewIan9oEf4t+MKmVi+cwQ6ue1WqFFBSxdw+fBSueSMEHFBusVP+B 76Xu0KlFHTjfoRGsWrsOUp67A86t/wnO1GkNk/tUgsQP1sFx6wNQ4a8NcCAoFF6tF+w217OndNSL xBCq7d6joP/OiTD8heHgZ/eFsEnRUNvfTUwF+VxxW3/9Ec7Zg2HbsljY9D4+YeCTc7+XJsADj4RD 938iYOiw4WCQgmF07Fi4vbYeHvk7Al4cOhwCbQYYETkZGrmLqYTGrzdCcEgV7QXBadC8eTNoUrc6 +OKNduSo52HMrJdh+Cc+ULHtc/BC7/YgNh0FG2PjYPhvfmCq1QcmPt4lr0hMrvldFqrC0NgIeOut RBi+3AJKUC2YML4/BPsFwivDB8HY14bBH2iPr3Hvy/BUlzsho/JQGG0eB8O/M0GFpv+DCf1uc81x 5dOrxg+8DCPxep2A12ZF3HZdqddIeOrOauAnjYAHN0XCMPzOmiR/GBUTA7c38IfBO3bDK0OHQUVJ hGfHxULrypkWNNcvAlSoUhWqBpM3lwj9R02EbdHTYPjwj0AMbgfRYb1B9NHBy6OegTFzXoThi32g crsX4Pn77gK1wUswZupkGL7eF/zqDYAJj97t+tcz+ibWrF0NgvCX5uDGNfDvtQpQfdUb8OLXVlzm 00PX/42Bx3uMgMd3RMEInONAuxGGRk2Bdi0qwrO7d8LEYUMhBJeeHn1lGrSvnrVf3TWnGf2datas Akb8SfHxC4Kq+KLSrFlzOCI3g0roDV+pbxj02jVBu559JPwuT8HruZ4JntgxAUbhtR9sF+GF8THu dV92zdkocq+8SgyBIQhjkrwOD164DCI+TQb7uf/wHxizCO4bZUETu+W6/4AIAUFo7cEb6ovT3oJH L1wBn8DKEGjK/LF4ZNwc6HbxIgi+IRDi7+I3l4Iu56BbYM7890DUZXoSh97WD95/pzMkY+ydKqEV M8+s3xH9EVrDxas2qFilMq2guVWpVOs2iJrcCC5ctYAvPi0GXncCq9V5MCxu2xuuWnW4zBmsjcnY she8/c5dcBmXEyqHVqIVNPcqukDoFz4fulw8D3bBBKGVri976YPhuclz4SH8zuoDKkGQb+Z8P/gy xpd64gKoPkFQMdCdbGB6eCh8MvQlRyAsPlVbQ+Kb78P55AwICg3N8vOr2m4ALHr3XriSjkvZodet tw07w1sLb4WL1+xQCa9nF9xkfuM1V/VOeO2tO0DEL5/yZAJsf8QGabiem+mqKYBfIF6/OgMMGv8a 9Lh4CUS8LwVfvy91GxoHtw+4AHZ9IFQOcv34J0L9e2He/C6gy3Wj6T50NnRzyFafiviQ8yYMuJAM hoDKUME38zroF5YInfG+rOJSfsUAd9n24F63mMJ6626/D4WNx4nP9VAx1LV3nTgxiKxD9AYj0MvX Py+fCSP+MOYeqwgVcbeV2xd0rtTrc16+Bv8QqJLLUUb0qQBV3Hi4gtb/G+fWJ7AS5HYr0PsGQxX3 jiEKwXlem3qodMN1LECIm17HDgGf9R00BOAc37hcb8QHthuuZ1MQVHF9XfDf7QW/pzry+MeiQ8uu L7388nJN0OV5XwqqdH2XlTvcsFDg5rolab2+Yb5x3/2N17PottezO0yNM330QjHkDBY+hgkwASbA BJgAE/AWAiyGvGWmeZxMgAkwASbABJhAngRYDPGFwQSYABNgAkyACXg1AVcWQ67cN6++aHjwTIAJ MAEmUOoEaGeAe293LnVEJdeAKwsOiqp2ruSGyjUxASbABJgAE3AbAhnY0+zByN2m4+7YUVcWQ1MR qNkdoXKfmQATYAJMgAkUkwAFILieRqCYNfHphRJwWTE0depUSq5ALy5MgAkwASbABJgAEyg1Ai4r hkptxFwxE2ACTIAJMAEmwASyEWAxxJcDE2ACTIAJMAEm4NUEWAx59fTz4JkAE2ACTIAJMAEWQ3wN MAEmwASYABNgAl5NgMWQV08/D54JMAEmwASYABNgMcTXABNgAkyACTABJuDVBFgMefX08+CZABNg AkyACTABFkN8DTABJsAEmAATYAJeTYDFkFdPPw+eCTABJsAEmAATYDHE1wATcEMCZnNMiGKDV2xK ViJHSuio6o1+YDL6LwsPH7W/oGHNTjD/z2KxNJJEI/iZ/NeGh4f9WlIYEuNjH02XxJZ6vTHZak1/ Y+rUWEorUKwyOyHhPovN0lECozUo0DcpLCyM0xQUiyifzASYQHYCLIb4emACbkhAL0FlzFUzJXfX ZbsVbKA+kZg47yEURP/mNzRUJyPx1QHw/xRF1eFxJSKGkhLNd9kV4TMQUJuJ+rCSEEI0Bh9RPGIT hB9UWYL0dFslfGusG04bd5kJMAEXJcBiyEUnhrvFBAokoMds1jaQBVGnE0Xha1mSfjLodYNkSe5k t9uagJg+Ac9/jur48MMY0+HDmRak2NhYyoRNGujaf/Ur2ntUYmJiTPgf7VgslBtQxJcvvuz4UvB8 Gx5D4slw/RgbvqfQv5cuXWqUZWWsJMsg6I2SUa/743p90KBBAzh8+LBmvcLjLdfbonqz/s6rD3ie +swzz1hGhYcfTIyPn2pXbZMl1fio2Zy0ODIybMd/Y+B/MQEmwARungCLoZtnx2cygXInIAgiGEy+ ayeHj31zwYIFn129fPFYutXuq8jKoKSkpDm29PT/2SXhKdQc/iCI6bFxCe/6mcSPBRCyBBCAzvIh iqCzPvpPRAHuUVQw4sBS9QbTQT+D8UuLJeVZm6oLNZl81+H7T1cw6nukSfJ7Chh0OqPxIXzvj+sg BElWesqon3SCuCQw0HRAthn2Z9gk8eTx42Qr8kURlh47ddqvBpBIdHWhPk2dnrBS9vMJiw0LyzDH xY7BPozBPvigJtMfO35aSkhInBAREf4eiMpKURAmy4pcG3vYEM9nMVTuVyB3gAl4BgEWQ54xjzwK byagKP40/BEjRlyYZY5L0gkQqaqqn91mX4JWolvtoFMNBuENUZEetSnWSVbJt6GvTrP0aCYi1C7C RT9jlM1iv08VDRkGEd7F5agRsmTvbNEZftPrdZJkV2pKilQbBZafJMA4XFqrqTPqwKTPsiJByvH9 FXAVK0MAXZCoE6/4+lqsVwBqUyN2BSS9wfCpIkuDZdn+uE3UXzTq1XWyLA9UJGmYPsXnDfRjai0r 6mxV0IPRqP9BkSypkmS9xyaKL2Av3zP4mvwl2QJ2SQKbJPuh1UlAK1Ox/ZG8+dLhsTMBJpBJgMUQ XwlMwIMI4HLZWhxOpKZzFOlWO5pYQBSOoejYJ4o6f0C1osjyE6pOVNRMIYSLX7KPLt2WKAFMDg0I bpRhS+5hRTuOiufaJDXDz6hfZbNb7lBk9R673f6YIsnNQdCBKIrvp6ambnPgS9P5R4KQXpUq1Qsq 3Vu02um/OoPxSgU/n9WpKdcGywralIw+x/yNurVpaakDtb9N9onYnTRNWmG7+BZ2UFyl1/slRUeF a/5MuASHOk8bGK7RKbF+ISHL8a9sFi4PmkgeChNgAmVKgMVQmeLmxphAqRDIso6IesMkVbKj/kHZ oMqa4QcUqaYKarxVUS7jXxdQZaDPj1oD/41LUVpJhxBTA59r9mmX0i42RtHUBC00uEqlKROpRhDM P2QVX5FlKUiWdZGSoobgCtYFRW+cFRs7XnaMCK1RAXgarsDh/zQd5Cj0liCgCNMsWJpLkoBqSpH8 ss4FoaYq6l/Q6+Xmdlzmk+1yD+xBD0VNP4XLaN+hkBqv0/ngip+N1BAJosDMirgwASbABIpPgMVQ 8RlyDUygvAlogiQxIaGvXVY60W579NnZhbaUIFQLdUBv+mNK9IR7sncyMcG8GjVLL3pPFMHXmibN tylKBxX0B00+PtNVuyU8w66Qk3TAYyMiLydMi12G5poXcb2ssaxi/QbxcnR42L7cA0d/HxQqRV+5 wtOM4eQkHRczxGQ0PalItq9UUXwaBVgTkJXhdru8y2DQbcisWRNTRW+kvGeJ22cCTMBlCbAYctmp 4Y4xgUIJ6BRFAmuGNA79Z/6Hy1YtFUXRoVczGm50b+oEpaleFEbbZVvbuDjzBFG1tLPJQj3R6PtN gEG4kq12vA8oQZqG0Yk7QLGg9pAM6NxMh5ApBkSD8aBettrQB8mIW+bxHYM5t8+OarPNQiH0MFpt QmVcysLKtFO1dlTtj/8sOfg3Krgs85EqCKkYn2iARYb5iipX1etNEw2ifAT9iZqg9qJyDlfE9Fof sV+4fT8+OTlZ25XGhQkwASZQXAIshopLkM9nAuVHwI7iQ4f6oBp2oRoKIRQKhh2CTv92VMTYhejs HGiUlRaq3dZLkixmWr7SG3zQOdknFlRLCzxHyYwzBCkocN436KSZdtk6MEPRDdTr9IqAW+RFQe1p TkpaEBkROcc8bcpL6AjdQKfTY3BH3b7oqJzOy/f3lw5997VOp0roMC2pKKJC0A0pFV/kog12VD6k kLRt+PQ3qiOyaGX+rarGVJuywmQQe9kk6QWbbJ+OFagi9kOvE6PDw8d+kWQ2dyD/IhHFmF4PR6Ki Mrf0c2ECTIAJFJcAi6HiEuTzmUA5EEi1wAn88jbXZEX2ououRUdFJNNbGKU5BWP/9Dt9+HDtVMA9 YOjUow/wlSLCwo6azeY/0XgzSUEtku6jOxcbFpWSGBf3jR0UQUVTjI/JpNpTUwH/8IsMCzuP2/br oOXJHz1/0DCjW+drSN6Se9g7djTBjWfHdulkWxf0zm6Olhs9OnA3Q02DDkLk/my8JINM2/NBVCUr GHxTlNT0FZqBCNflcGcYCafhcXExiWjw0sYlCiY1KjL8IP3brki3keAT9PpLRtFA/k9cmAATYAIl QoDFUIlg5EqYQNkSQOFAW+MPFdbq4MGDKXCiJiayl8jIyNO53wuPjr7hODpm5ozps2026RlFVSrh tvc0jPM4Myws9oZ0GNTWGwnx8bgTrYsK0gMZVn3f6OjoJbnayRbsUfvkSu5+REfH3tCP5s1jRBn0 MxRcbTPohO8wfcjvhY2dP2cCTIAJOEuAxZCzpPg4JuClBNBVuQJGld6Ebj4Z6Dy0CJfgfsgPxaX0 er+Y9AcjcXs8WXGaTZ4cI5RESo5HB4H6lE5aIojGiiIYo7x0KnjYTIAJlBIBFkOlBJarZQKeQiA8 cuJQZ8cSGzuYHK5nOI6fOtXZMws+bioGV5yI+dRKpjauhQkwASaQkwCLIb4imAATYAJMgAkwAa8m wGLIq6efB88EmAATYAJMgAmwGOJrgAkwASbABJgAE/BqAiyGvHr6efBMgAkwASbABJgAiyG+BpgA E2ACTIAJMAGvJsBiyKunnwfPBJgAE2ACTIAJsBjia4AJMAEmwASYABPwagL/B8HofVk52iWRAAAA AElFTkSuQmCC ------=_NextPart_000_0062_01CAF128.6E7C82C0 Content-Type: image/png; name="image002.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAeoAAAE4CAYAAACUm7AeAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAALfkSURBVHhe 7F0DYFzNFv5WsW3VSo3Utm3btm3b7V/btm27adTY3GzembvZNknTNkX6ssnM//Y1u3vv3JlvZueb gzlHOmnSJPDCEeAIcAQ4AhwBjkDGRECaMZvFW8UR4AhwBDgCHAGOAEOAEzWfBxwBjgBHgCPAEcjA CHCizsCDw5vGEeAIcAQ4AhwBTtR8DnAEOAIcAY4ARyADI/Bdop4wYYI9tds5A7edN40jwBHgCHAE OAKZAYFY6sRtcu6OT60zqRI1kXTOXr16HS1QoED2zIAA7wNHgCPAEeAIcAQyKgLr1q0LvXv3rg21 LyLNRE0XOpYpUyZ7mzZtMmq/eLs4AhwBjgBHgCOQKRC4c+dOFBH1d/vyPdV3XHh4eKYAgHeCI8AR 4AhwBDgCGRmBmJiYhB+1jzuTZeTR423jCHAEOAIcgSyPACfqLD8FOAAcAY4AR4AjkJER4ESdkUeH t40jwBHgCHAEsjwCnKiz/BTgAHAEOAIcAY5ARkaAE3VGHh3eNo4AR4AjwBHI8ghwos7yU4ADwBHg CHAEOAIZGQFO1Bl5dHjbOAIcAY4ARyDLI8CJOstPAQ4AR4AjwBHgCGRkBDhR/4XReXp0LsatvIg4 kQhieiEhAQp6wSwnxk+bjeI2klSeEg+Pawex9ko8Bg5vBqPvtiMaWyd3wB7/clg1vy8sMuGIKWKC cWD1BgTnrYfOVbLj0qpuGL0vHnPWL4ebrdZfGKG/WIU8CCvGdMJ1vU4YWz0M/UesQp0xm9GvmgPe nN6Frc/0MXxAXWj/xUempapLm0dj3l45Jm+choLGslRvifO6jaHDpkK36khM7+SWlmp//RpFHF6c 2ondb0wxvG8taH63hkhsmz4AhzzdMKyNBGNHr0PtsYRjVUfcPzAHk1afQUCsHkYtWgfDuzMwfetd hOs4Y+aSlXCzS98fQXxMIPat2IjIwg3RoYLLr2OQ5jsisWN0f+wPzY65c0bCPo2TJsrvIZYuuYgK fXughEVyhI8t7opVDxwwf9E4ZNOntYiXTIFA+s74TAHRzzvh/eQM9h85+e2FUkd0HTcv9QpiPTCy V3uc0BiE4UTU3y9y3D+7Cwc+ijFvHhH1z5ujdlf43VyDFv3HYMCW6kLb9c2ckDtnPPRkGXChiY/C jeMHsUU3L0Y3LoecuXLD0lgfkL9B/67t8SLPLIwb8O+HwOvxaRw6FImekVOJqFN/fnyoBw7tOAQj o1bpR9ShT9C7Uwd4FV+IcX1/hIMUTy/vw86b0ejbowVy5s4NCyNdusEX86fPwMFnZmjdrQVs5U/R d/Qc3BMXR9s2LjDRT/8ly+fKCjQfNAWjdtdJ54GMxcMTe7DLtyTGTk87UR9e2B/Dp0fj4pD+37Tv 5ZU9OHTcFaNnM6JO5+bz6v8ZAuk/6/9ZV/5/DyrRfhGulPFDfPBTDO3YE15lhmPHsHqAtjGyab7H jJ6dsPmCD8RG+TB27kK0KmuLtYM6YP+zCMTIVsCtqRgnd47Bx11T0GPqbsSKNOFcrjEWzRyJ7IZS aOvpQmKgC3GKLkb53cGotv1w4mMQDPNUxNQ5s1Atu6FwlTzMH2umdMKSQ68BLUf0njoXvesWwI11 fTBifzgalLPBwQ0HEWWdF/3nr0F76+do3XII5KV6YP3MjtCjOt5fWI1Oo7eh2ZSFsLu7EqPWX0CC pjm1cS0G1MuFqytGYfKRd8jvJMPpCy/QZf5ONDW5ib6DZuFlQCwMXQpj6sIVqJpD2abQlyfQo+8I PPCIg45VToyYvw4NTB6jV88ZkCMOG4Y1hES+DS1M5AgIDEWsQtlj31sHMXjUWNzxjINZkaZYvXQM 8uoHYWyXFnhnXhPZwu9gz7UPsK/QEqtnDIKTvkYypF6fWI2BY5bhrXY2tKjqjGtnPTBo01JY31qJ gcvvY+zGnajmIsOl1QMx5r9PGL9pO0rEHUf7rmPwKkABXcfCGD9zIeoVNIdIJIYOSSrGNCYJsVEI Dg5DbPh7rOw3EOc85EgImIWyjZ8iG14huuAg7JrQGGy7Ee91Ee1bjYFDp+mY0bE8bv83CH1X3kev Wf+hY1mWqC4Eq4d2xba3JqhZSAOH955FoFyKfNVaYMEMWsR1Umhl4kKxZc5ozNl6FsaFasNNpgmR VAv6ehoI87qF0d174vSbSJgXrYuFcyajqI0ORGIZDIwAYwNDKGJ8MWNAR2y5+B4ybX3U6j0dEztV RdzrQ2jdfRYK912NKc3zCTh+vLAcncbtRed529G2BNsqxuLq1inoN303ommuOpZugEWzxyCnUThm 9uqEq58VEJ2firKdYnBgw1CYJY6GPOITFo4ego2nHiFX1RYwiTeGoQU1KC4KQUEhQHQwdk7qib33 Q6Cho4uA18GYO60TrnkCelaBCI+yRzaaSq9PrES/kYvwIVqEkq1HY9HItpC5H0O3znNgUKoIPhw9 Co1qw7B1YRdoh3lj2ZgeWHHqFcRmuTB2ziq0drPCw12j0G/dW9StmhenNu9EkL4LOs9Zia42L9Cr 11xqcQxWD6hHTVqP+V3LCj3we3wQfXsvhm3VCvA8tw2Pg4zQash0DGtfGVqiBLy/uA7dhs6HZ4QY RrlKY/qsOaiUk839GByZOwpj1x1DrEwXjQbOxej2laArFUFb3xA6MfowMQA8zs9H06G70GjMKoxo XBChH69hbN++OPU6EmaF62L18mnA+ZkYvvQ61SlBuzJ1MW/LRjQtpEIY0NSl5xnqQ0dPhJiAt5g5 rB22XwuE1KwwJs2fgyYl7GhxiMCl/6ZhxIKDCI4TwZnqWTBvMnIZaiD45TmMHDYMl+iZMgMr9J2x Fl0qZ1OuPYoonFo1EaMWH6TMEVpoOnwJxnUqB015KPbMHYipW24gJkGGonU7Yv6kgbDQyoAb7f8f TfzRkzlR/xF8ypsNrHOhDL0QbQgz0kQFOxRA2bLsx+2HweVLYtFTHfRoXwuBd46jda2qiDh3DjlL lYHtzmvw1syJWuUKw+/cRvQatAguTfsje/wzrFw5EQOcy+Lo8CpEDt9O+LjAp+hTuxH2hOZEl9ol cGL9YtSsH46Xd7Ygu0YAZnashHFHw9CpVyPg1SX0a1AdkaduwdX3Oa4cPQ/PkGZoVKsU9i7agI4t 9FDpzgxYKp5i4fIV6DegHcpZi3F60yJcvB8B09ndcOZ+DNXVAto+DzC2eQ3Enz2GvN5vcPrYHrwq UReN6jaDq+we2tdvhw/ZGqNFYyecXrUYXbub4tKJJXAQf8Dojt3xUKcMGjWwx8Wt89Cl/2gU3DYI pUvkxcHnt5CtYGkUdDLBx9MHcWBbOLrPmoewt7tRs2orBOaqQ+11wbVtc1G1egBO7+mH93euYPvz h2jcszvKZfPEmmUj0ccoFw5ObQjVxA58uRutWvTGG+ty6FTREYdXLcJ9HyO0iIiBxruHuHT5HLzC FMI4+ry4iStXPuDNi4vYP7U3PpnURMPSRji2bj46jLDBu+NzYCxVbh4kMi2Eez3Gtl07YVxnEOqW LAmLrTcRYZ4XtStVguL6XUycNRc3BzdGKf14HFwyCdsuPcWqWXmF+x2y5cSLawuxYMsZIupOkH+6 h03/7cE1X+DiATGqdRyCivofsXrxWPQxzod9E7/2id1/YVlvtBuzDeVb9kJRgw9Ytu4qsVldhL+m DUa79nhsWQNtWmTDo+ObULOmO85f2oV8Gsq2a2lHYO/03lh68jPatm4Iryu7MLt/V+Qr8QLtsuWB 7P0NbFqxCYObz4Yx/LF0/DCcf18eC3KYCvd7X96M3oMWwKnpQOQSvcSa5VPQx74UTo+rhDxFisHs 8GPEWedDxeK5kqi+I7FxeAsMW/4cjXt1hI3fJSw9/Ra2xQwQ7vEI23ftgmn9sWheoDRsjdjvwgr5 CuWiDUoAjh96B01zZ7jmssbTU7PQsNFk5G7ZBy0c4nBgcQ80DovF2paauHr5Atwf+6BTh1ooUbUY dKO8MalNVcx+Yoqh7Vog6Pl5tK9XDeKrV+Hi/xqXT+2ljVhdtKlaEcdXr0Tf1n2R/+hklHHLgyOv 7yJ74TIo5PKVBGNCPHDxyjl8fvASnbo3Q7EHJzG+U31I7V5jSFF39O82FFGF26GBowL7li9HR60c +Lh9GK4u74WWw/ajeveOMPx4FNO71KWxuo9pzV2ETZymjh7Caf6P6DUOEXn7omGlfAj/dAHNKzfB a7uaaNsiOx6f2IyqNb2xckIDlMpjgY+3gBIVy8DOOPmmVBggTV0oAp9hWJOaWPXeDN1b1YIXmdma Va+JHbcuoqIfbYY7z4BL8/5o7BiCzbTB76ZfAKdnVcGIVg2xIyQfejavhWdH1mFYl85wvngCVR20 cWJORzQdfxXN+neBA95jVY+GCJMeQBscQYdRG1GpxzDkT3iBFXOGIsHSFVsG09r1F9ZXXgW+rGcc i7+AgCIsAnIyTStio4XaPp3ehPWX36Pr+odY3skVCGyEl9kqYNnK47i/bgLKLFiCc0aNMHNAQ8QH vSdpewmMTDWxePouxNGa6vXmg5IUUmnbpxsHsf2OB/rsu465jexQ3ckQN7XKwozMk0HPTmDtvieo P/0U1o+qRuLcC/jkKoI1izdiVElSL0ptMHrxBnQtrIsC0Y/QaeULfJRaY8jIflhRZxaOXv+IcnWi sfv0exSt1YAW5n2wKd0f7Vu0gCy8CG6faY4lC7ZhYm4xxGJLDF+yDb1L6CPh7R509VEgUOMT9PN1 x4QFBaGZsyQsmclUbI1O4+ehAi39706swLsQMcLffUCYaW4MGNAcozc9Qr0+U9G6gj32nyCaJalP XzcCFxavwv0YR+zfcRANsxGmFfXh1HABtp0oD5G2CGZFu2LjirnQD7uBB85l4P70I0nnXyf2w/07 cTfUCIuOH0D/0oY4Z/UaVYbfhoQkY6mmNv2rD1kiwDItwoYkRB1jF5IgF6C61Bh3di6AV5QYIe6e 8KFhNdZO1GuQD4JYqgl96ptMxxrVmg5G/onL4FGkDcb2a4uwQgGYt28IDl30QalaQVi15RJsq41H i5LKhd+ydCv0qzED0w7sxuulnaC4egRPI83RtHVZHNu2H++9Q9GnbR/kLtoC+SuWTz4HEjywc/NB aOdpiE3bl8GJ6jMJdsHE4xG4fWQPTr0IQqf+ndCigjVKGfvi0KBVWH/qI+ZX1hIWzphYKcq16o/Z uQOhH3Qdw94EAlEyfPjwCSLXHBjWvy7KzDyF+6QdKON1EBsvR6LJtIGkUlcCZZK/KiYtWEYmCh0s n7EHMWyuvnpDuNdGg36DsWjhZoSV6ICpvUmrpCpBT7Bt63U41RqPPcsnUTu8EPTGBUciYwhHI+hr SCDS0INb45EoMW0FLhnXwZyp/SCOLoONc/fAuEpPIrKqWNSkLz5ou2BCh7Zkn42H9tsLpOlZi3OF Wgl+ARX6z8L6SfWFp4Y+3orNh5+hWI9FaNmiKqLdbXHmTA8sWnYWM4vQ1SIDDJy5GiOrWqOS/hvU m/ISYRYF0b9fU4ze/AyN+k9D+8os86CyiMVSAb+KQxZj/cTGlJDwDt5md8N/q//D4O19MHTWUoQZ mOHU2unwp0kY9+kzgqI9sWnZFuiX64YtqxZA52Nt6C24iyZlLammaNKC0M4+/A1GdmmJs+LquLdr FnLQ9L+5dw9OvgtE7yGd0aKiNdxM/XBwwGrcjZmELs1dsfN2DMYuHoWCKdVs1EKpDvD46E5su/EJ fXeew7zmlK3YswaZk2ph7bqTyFkxBjTi0PD0Q94uPWke1IJL+arQiPOGt3cYwqK8EGJWAIOnzEMn 7ZyEM20GYt5i0+q90MrfBO3atoAVAuB+5TjWLVyH7HXliEQC3n6OQd/+g5C7XGcUq1SMk3Qq6/bv fsQl6t9F7of3KfeR/j6epCISoUBeZ+XVJi5wJeePS15vEBkZgTgFOZ3Jo+jnSgvdvRMYMWIMIi0L oV3Nenh2bz7i5anmEBeqiomKoZ8GEQepuFipNWAyaiW26YO3h/BDLFAgh/ITiQ0K2Rvjoc8r+AfR XYaWsDdROhxpGtGvWqSgzQVgV6ML6jhMJxvXBbTT9MLdKCuMq1MJu0j1/P70UpQ4NBfxYk2YW5oi Z2wc/GNioKVhCHszZlukarLVxq4t49F52AyMacPszdoo23Uq8pIK2C7qDVbNHI9Nd/zQos8AVMx9 BTvc5ZDH0YIaylKwJiAyNIj+tVdqEMS04MRGwt0zAFpmtshmq+yKRb6CcEQ43L38SAFLqtzszhCe TmyhTYt9nFS5mKqKjwchoWWOPI5K9btD9pz0//fI34/6HM8kaTFkUiUBacgIE6kMsT6PsXLBOGx5 EokOJK27OV3CsTg54lPNb8OcB2mc4kkFTtXFx4YL46lfsjYqmY/G1WP7cTM+AGc9dDBqVVsYfmmc Edp0bIE5rZbjMJkNNA/vg7h4eyxfMhAnHGToNXsVGp5cBeg6Y9D8tcjXrTI0vtwbhbBwOcydHL44 IbrmzQ7poQgEkAo5jrBcP6QOltEc0dQ3hqW1A8QhgTR2EiIbgiM+BOcP7kePiTtQvHkv1KtYEAu2 PUC8QjnfijZuB4fhrXHm7FV43NwFf93C6Ny2whdMPUiSHDFiNELN8qNDHZqrd18inrAU4Aml5xMO 8phwUvjS/FLdRertCALGIY9T4viYwzW7NQ7c/zrHRUINwYih3a4iLlKYw2YhIcLmNy4mkg0yvKgO Udgr9KxeGDH0IAMzS1jrFEJoeBjNGyC701diDffzpdpIU/LfCORfRaSooQtLU2vkiAxBcDwxqYYJ HCyUc1dGpiX6AGJqTvL5+LW+BLY5o6vy5lFqRaDrAFdLHRz1/YhPr19g7vhROBeog06d26Cw9TXc pN+vXBGNqFgR9Iz0aFyoOFbDkoW0eRZKEKS0OQx6cRUH9WjDqLiP83cCkaOUCZl+ggknETYMrYPl ScYxzucTfGMYZnEIDqAazVM4DhIIkgT6bfp4IYp+GfnzOCgfZZsD+Ukh8uTtK7hMGIhd056h6+QN aFtjO8152kRPX4l8w+pj/q5NkPcfilVDW4JmH3JW6gWHAgtRzCgQvgnaCHl2CDWLkCChkMLEyhyW ZlKU6D4Gq8PC0HfhItQ6sAik98e4ZRuRp3WpVIWMLxOJ/5FmBDhRpxmqX7lQuaJbO+Ug+TGB1Kv3 0bdkeTL63sOVTzGwqu4Kba0YxNAPTkw2K+bXfGXvRrzxccb1t+dQKuIcDi6aDx0bK6Ge1Oha18iA aIoo5+5boJotzs0fgA2vrTGV7NqmLrlgQ4vW5Qs3gbpOZP58hgsvfWBUoSisjcjpTa6AnF5C3ap/ 2eoqcUH7Lo3Qf9U6TPCVQy9HbdSvUQKHh0bBxm0ozu6bAPMYTxzaeRyxecpC59QUxNLiJRc2FGJE f/aCr3FxzNl3H2Xz62F200qYvHYmrowgFVvwGay59Bp9193Eks5FMbnmUloRjcDWyQRiayYFa+kp yZR5zUOhQJymPnLnskP09ru4+ywaBYpo4c2l86R0M0EXFzs8E8tpo0MEyp5OJEP7nm9KjgIkTUTf xrVHHgSTHa5dv0HXkA1VJCMNoYzINxyBiarvD5/IGCrVxoebh0gT4o0Jhx9hIuHX+9RMxBuYwIKJ bKxtqRaGaTwkGjrCeEIjB7p3LoOmG5Zh+AVfSPPUQrtKyT2I89Rvj9ou23Bs2QR8visn9WhtSII+ w9StOc6/Wk6SMklexWpgweRV6NWpMnJ8WZP1YW6mDc9X9/EmDCimH4nz1x9DLs0LE1NDWhwT0GXB Jcxokxc+Dy/i6K23KF41FxLCL4HWV0j9ycSxfQ9c6k3ExS2jcHdJSyzYKYOZmVK1relcFR3rWmLR 9NFw8rqMHPUWopqDyvs+ARf2bsIrT3tcenUR5eRXcHTJXEisLIX5CNoAqXBI5o+sZQBqGu7euEWy WCeYxrzBhYefaHOUxiWI6iU6hQU5TyToOmHTufOok1MXD47uwc1QY5R19MMKGpp4mg+qokskzvyp creYj4OL20Hi+wJ7j1yGSfFKML17iDU2ce6y+77+yhRE4jRDyDckcT4mVsg2kGz0b1y9BLTITTuA R7jsHgqnMoXhc287jtDGbumtZ+hTXIFm2ycSiZrCXNMQxkakrXj+nIwItEcOuIS2HVaj1vipaFPC kjbIYZCYlMWeo7Nxpn9VjOoxHo0fLoW9JVs5EtB5/kXMbJuPHkXjePMdStUoiLcradBplhlQvd8U 9nskrZCtc3YYkJhw+epjdCpQFPKnt3DdizbvtDbE+LtDw7UObZKmIZ/hJ3QqXhobJi1D3/YlEB5j ju5zD2B7qbw4PaUtms1agS0X+qNYSztYyCKgn60JTp1eh9z6oThLmh9P/VzQp02FbYWOuDlwMyzC zqJ2iSaYNW09erQqBVuu+/7OevFrH6fxV/JrlWbZqxVyhJIYEBQeJUBgVbwpBjbbgvFjG6PS6aLk THUPAVa1sXR4fXLsCYeZhT7cL5ADySApmuQuCQPFEvSsUQc28vd4QQJEtvfugjQRExZOjmr0SgKs nVtTDKi7BdPHtkS18wXI3nkK/jb1MIAucsxRHYN710DvBd1Q+vF6wP0J7saWxrbJ7aG5aSMRdzBi E8XDmAhy4mESS7ySbKu17gyTWfWwl9axTutWIJtdQQwm6arF6LVo0/Y1LKI/4eQZP4w+WwEF4iNJ cgqiupQNSyAV3tSu9XBfnA81imWH5/tgOJRrhRJ0nEaqmw8l9OKxcWpPfNxniOsXyRgr84ZXcDxs ze1pQQ3H8mHNoRW9EtmkTMwOQUiIJqr1Gow6GxpjYL1i2J7fFk8vnUPpFrPQpV4edB5DanYTJdbE 2AgJjENYWLRSsksshZp3IRPADkxsWR7Xy+fGs5sPaAlmC6QOXAoXgjk2YUjjUjhUlNTcxx+Tn1QO GOUojOL6G7BsWFvcXy7Bufs0GNae+ByeAAv9BESEJCBQHEXaADk54ySQqpDUEWIjWFpo4eKR6Wg8 QI7Vi3qjWpdhKLykOi59AppObovsKY/f6BRA7x6lUX3ELlJnVMLmjhUQcGYCOjSeBt1i1VHIToz3 Yi3UatkAdknXZJEV2vfugpXt5qJOqXIobCPHuTM+tNnJAbdm3dHl3FVsHtcRn47nhOeDq/ioWRGH 2/eBJDgGQQS7AanqqxRxxowjC1G73g14PTnPVAGk9qQvCRHWl5ZdumNJo/F4SErOOV3qK0lYKCLk LlwCOliEPjRX7RM+4gnxht2Hj4gk4HV0SYI318DBA5PRbHAsVszrATO2WBvkR7e+jXB8PB2vcnsH Z4kXqehJdZ0tBnGkOQmiSRQhSIoKhAUHIlAUQX+xtyQ5BsshCg2j92J0HEpOYuf6YFTH1tjuoof7 J0/BpcsS1CooJfmUtMjRX4naMF8djOxRFQPXT0GbwJMQe7/AmQcyrLrTAfZx4fTDChSkd1Zio0Lp /4OE90bmdtS/ECwe1AzygIWkHSqp1AKQuUSP/nq6bRKqfdyP0Cc38DTOHuu7NkMB7CW7bSBmdmuI MxaROPKWCFPzDbwTzNBr1GDsaTINNUtWg738Fc7fC4Z54wFE1LYI9/uMeJ2cKF7KDWWmjcay6mMx Zm0nrGjRD13XnMB/4zvB44RyHD9oVsKZtl1ha0lSvmI/OtfshKmL5qBO/q929Ohw0py4ByJnrdbo 12gvJgypDff9heD39DZN7caYNLg+Yl6sRc+GA2mzXQElyTvviUIDZdqQ572OHIPHd8Cax1LUrlIC cZ6PoZW9EqoXIXWWWB9DxgzGxU4r0LV1GzgZhuDiwYdouWIPCjzag1ZtZ8PSrTbyWsbiM6nzGzav B3NO0klWoj/7kxP1n+GX7G4RLYBNenaAXyGyR7OiZYHR20/Ced4gbL/8GUbkNLRw4gSUs2dqNl06 djIFUZvPEG/GonTHMVgZLsOeW69QouEMtG56C1f8tUHcQF7EPeDnVwKGSexRYh1HTN13ABZDJuD0 +wCUajOOfkhjUMyEPVgH3ZcchW2+oVh97A2QvwH2jpmEujlMcL9wE3ToEQsXI+XQ5yFP6Q7EdfY6 ysp16Ic5amR/HHU3wtCGrB8i1B21BScdZ2DejuuQ62THrAMb0b9yAdzzq4WOXQoju7HyXu1sNXHh +lVMmD4PT7xika1yT6ydMhUuTBizrop121Zh+n8nIHZyw7YeHbFt3x3EBkdDs0BjLJl8E0cf0qJF +lHHcq1J5RxO50rjyImoEvZdPI2p06bjvlccqg1dgbmTu8JU8Rk12nVAHruiSo9Uwr5lz86Izlko meOF1Lgk1h7agUnT18PTNC8mlLVDr5FHEU4qVesKfbB9nR/WHH8GmW0+zFpUBxfu+qBS7faoYSam tp4mW3s17O3SFtuPvEFUOBGJvi6qtiSnIJ1isCSnoV6dO6JsdhLzRLYYPmEqNHZfRSzZXZnaV+ZQ HMULGeLaNQdyaKv0jdc+a3aZVoPRn5wN9cq2QUF9Uk2To9TVM9kwYdkBhNN+pcWYtRg3uPU357IL t52JE2T3X7bnIuKdymBDs7o4c0sEJ5eSWHLiBLKPHomzryNgX7U3Vk4ajaKmEtpYOKI9zU+DKtXQ t6gbYrUX4qXCCJNW7MSNA/tgLVH6VgjzomQZwcP6lUtdNCmdaLpJ/K5Mp7FY4S3GwTuvUbT+FLRt fo883g0QQvDo6OXBqMlTobfvBuIZDowHhQVbhkZjN2GXfm7suPAYRoV7Y0Pjj7gTUAiOLjro3aUT yuUyouukqNe+N/LolFf2WdceHciTXKdEfoG4TYt3wYmzNpgybRU+RCpQc8x6LBjTFiKPy2jfoQPy ulp/6QMkhui98jBs847B+tOvAJsy2DJvAloVMMFLr9ro0KUAEYtS7ncp0QgdOvjDSUsB7YKNsXTC bZx4TCc5IpUbP9aFBNLaxJC+otWgiXD2OYV7slrYRA5g7Qszybst1q/xwarjN2FVoi0OdmqF3ecC 4B+agAKNJ+PwbgvM3nISUaISmD5iKEY0L073RKFki+7oHuYEMe31zKt1x/L+b/A67CPi9BtjNW1C 8o8fjTOv6LdANvrlk8aioLkmwhoPxpiXmnhG+6qYaLoxSSlYoxs62NmS9sIeo3edhu3M/th7MxAu 1XpjzeRxKGFF/bXqj2tXbDB23lb4RytQvdd8TBjTGXpkAVp18iZcZ03BqYd+kDlXxt4J81E7t/Kc V7H2c3HKPAdmrDqK0HgT9F9/AJM6VaJvquKKkRMmrT1OGx1ddJ6xHWPIPyEVN7dkbeVv0o4AJ+q0 Y/XTK0X62TBs4cbk10n00Wr4WnqlvF2EfDW6YyO9VMVx9Dy0+vKuAf30laXegJVI4pbztSKZI/qT g9i3pynZyiJBnV4L6JX8uYWbjMPGJl8/K91iDEmoSa/RRfNxi9A82W0ilKVjMGVbJ6+rSIvB2JDs XtL4OpamH3LpVLHKX687ttFLVarVU/UQaD9uJdp/+cYNG5VHqoWi4VAMk1ftS4GrJQbMTIK1QXaM puAYqRXzgqTF2Flb+OrV7n5k3Ysj+zRJXnRcqUrnafT6eldH1Z8N+mAHvVSl+hfMpGg/dsOXti5f 9/WsbdFGA/EfvViJDfHHkwdHcf5GCBzrtEetnOzA27dFx94NizYlDT4iRs4qnbCdXj8uElRoPVh4 qUqbL9A6YeD8HVC25GuRWhXCFLIdqsrcrTu+/N2gpsrDQYGQz964c/AIHpCypXn79nAmN4ZkRWxG GMxPMl6NksxbOjLVdAi9Umk9Oe41GzidXl+/65j457K1SgcwVvpOWfb1AoM8mLactEJJioVrLSzZ qWpv4hf25TB/Y7lUHqqFBv3n0Sv5V7lqDKTf3tfPXOvQ+y9DaYpOE+loYsraSK3MjDRSh1IYP6Zb im81UKXraHp9/bj21x8zijbti530Sl600WAUte3Lh+boRacwvhTyTxhAR+IGpLhL37k0pq5O/TdW pes8VPlyvSE60OaowzeoiGBbqhk27P42foNI3xl9p67H947A56/VA1vplbyQHw4tNHtSLjapjAb/ 6PcQ4ET9e7jxu9QUgaho5tJDRP09U/Nf6teNTeNRecAKxFvmx45xHf55pLLf70YUNvRphEF7b8Oy XBs6p58a+f1+7ep8J3NAZIr1uJivmgd17g9vu/ogwIlafcaKt/QvIJCj9ijcutUTDnQmNz1LoWbD cJm8uHWss9HZcLL7qk3RQovp61BqaCQscxSCs9K/jBdCwKJwM5y6RSYo50Svb44KR+AfIcCJ+h8B zR+TMRDQMXVEcXqldzGwdoYbvdSvSGCdswDSdxujfqiwFmvoWaBQ8cwYxFc9xyMrtZoTdVYabd5X jgBHgCPAEVA7BDhRq92Q8QZzBDgCHAGOQFZCgBN1VhrtNPVVjienLyDQyAXli6dnir80NYYuSsCr m0fwKMgc1auWgkEWmbGfHj+i8KrOyGujj9c3KLqZlyFq1akMijD7x8Xn2RP46dmigIPxb9cVT0Ez 7njGo1hB5+9En1LgwZnjFNUsGyq65f6tWMWelBHs/NNoVKhVC/aUnCbk/Uu8iTNC0ZyW8Ht5BRef haNEpcpwMMq4B4E8nzxGsLEj8tlS1o3vFM/H1/H4oyYq1S3yg7Sgvz1U/MZMgEAWWfYywUj9oy4o PC6gTct6KDDmbAYhagV2TmmC8beq4YXXUYq2lPlLwL21qFJzHvocvEZETZGwds/E6Es54UrJPkw1 /yyKRPizHahcZRxarj/3+0Qd+wF9GtbAk1zjcGVd6nb42wdmo06jUTBrNB239o0SsrH9anlxmjK2 rQzE+nL1KEDJNTSs0houg3ZjHRH1wx0j0WziC2yi6GbtjX615n9zfejDjahcYya67bz0Q6IOerAL TXvswzpK9tEiZwbLv/5voOJP+QkCnKj5FEmCgALndv+HdxTham5b5TnNyE+3sWXfFYRTyknznEXQ ok45IZBBtP8rHNx7CRZFiyHy+Tm8DtKCW53WFOlIuWpGuN/Gf3svU7B+KdwadoKbsyo5bjhOb1mP xxSi1CR3GXSsXTLJ84NwdNUWvIyg7yiZR9u6peluEYX6NIKMQip63D6PUzceQkKpOVs1rU6ZrFIO XjBlQdqC5xQpxChHCbSrVyZJRC3g0en1OPuYYihTjObmHZrChtbEZxe3UcYqC5ShBfLCuTtIsMiO Fq3rwujzA2zYewM2RaujdimlZsHv5TXsO/cYZVt0hsGrI5Ra8z1EetZo2q4V7Cg6x5PTe3EnSJMC hUTj9lMPlG/RF0V0XmPT1pMUeYvisjvnR4tGVSkcTWKJ/ITtW/fCOywBGhbZ0LpNfeh/foSls5bj td8HCu+5HIWNuqBY/d4YlEuf0gYm3hfhjp1b98GTouFYulaj7E/5CXAv7Nt3GDo5y8DA7yFuvQuC NbW9RRkW21xZoj4/w4rZi/Dc5z0lfViNE5bdKW6zPWUou4b/Dt2gGOUaKNukM0o4qFoYhyv7V+P2 ewrzoaGNyi16Ir95FM6unoOdV1/BIPYo1h7MhrYN3JRhU4WH+GHnvAFoPW67EKAkD+XqTra1UITi 3K6teKtZEO0alYZWjB+O7tyHUJuyaFU1H+IC32DP7jPQK1wbrhXbYpB2FBzkb7FjxXRceP8R0ec2 42AxMxgamkCkbw65911sPn8LIVpWlBilOXKbfrukvbywE8fueUJkaIcWbZvDWjMB9w9vwTUPDdSl rFqOtIt4RmkrzzxSoGHPpoi5eQJXvXXg6hiPK9df0NjkQ+u21b9sEm8fXIfLb0OgZZMX7VvWFDYh UfR7OLzvIgzz5UX405v4SIHPPG5uw6vP73FlxwoUMeuLyvl0cXrHGjymwD1SHSOKONcZOejnkr9+ axQduw7/bTyExtObJ5uzKWc4f581EeBEnTXHPfVex/piz95diM9JqSfJuTWS4o53aNQEZ3yNaDHy hcfnSJyYfRibhtUlAr+CoT27wdvYEk5Gcnz+GADFgv+w68wllIvYh/r1++NucAK0JWGQz99Lwf53 oGMxYHrXtpi95xo0dPURRlGRjvaZi00zOkJH7oU5Pdth/LrL0DXVpuQSEdg1YhP2TmsDLUpckPDx GAb1eozPn97CNzAKN31PYiPFRlaRQAJl/lnYtwPGrL4AHVMduj8M2wevxYHZnaArokxgk/qj14w1 iNczRVRgGFbuPotde5bgztaR6LbGA7lcXRHq8RLegdHY+WgHTvY2xZwBveBRoh8+XFkMc7EC++f1 Rs813ujx8iEubt8GvwQNxFFylUU7b+HY0am4tnYaeuy6D2tbW8RqZYNp7jzYMLcztj2RUJatEHzy CsW+sduwZ0oraER/xNgWVTCdUk062lvis/s7HP+wCyurx+H42ec0PrE4tWUtXCvUhv2FsRiy1RkV WjamWOs30admC6y/+5kSjGkhKGQabszZjpktdDG7X0/cFDugoJ0GXj2mSGoUBcx/3xH0qUppx6hE ej/GweMP6S8FLuxaixxlGqCQ4iKaNR6Eh+EiaCWEIX7RASzasRltS1li1/jW6LP4MAyMzfHxgwf0 SAo/fmAxzh0/Aroc4Y+OYPmuwmiahKgVn+/RWF9B895D8OHwKmV41WRFhAubx2HKybwoFXMJLs+P 0KapJyKzNUfFNzshv74VrXtORK9tr6H7cQGGjPeDRbZ5OH38kjDW909vxm63BuhmYghpzCfKt9wX 8T4eeOcXgII3vHB27VBQELbEEocTS0ag8/jViJPpIIbGatnuW7TBnAnNsOeUW3oGTgaaYHNzEZrW aIPg0kPRsndznFw1Bd2334ONowPk4eHwDQjCoYdrsX9GG+yZ3BkDF+ynzG2UmpIir209Pgr714+E lsdVDOnRHd6U8MZOXwxdKwfEez6ldshxZvtG5CtXHh7bF2LQ0vMwNjTAW8rGNnPLFZw8sgoFjFxR L78ORh/cifejm+M7sXH4SpWFEeBEnYUHP2XX5SFv8epRNLJ3zClkpHr54DT2kARapddELB7fELdW rIGHsUwI+sDS8zEpypTimZ8/shT6z3egcOnWmDN/PsW2XoXbkhK47X0YeWUe6FbSFaOmL4FlUwmm bD6HAfs+YGYjR1xZ2BHlBo9CHYplXc13A8atO4du215iSSsj9C1fHvf9QkBRIiFKoCxbYZroseIU pdOUo2vxnNiyeh9mEFGrchu9PL6WSPo0OlB6whXtLDCgUlnc9AsSQrDKHx/AqIlrkLP3Rpxf1gEB FxYjT6UBmLqsFmpSNiUSR9FhzgGMqEJZq4rmx+oVO+A1az9mDCyFJotP4vqHeNS3e4UjJx/DsXJd 3N2wAlrNVsJ3bQ/SJuxD4VJNMXaVG+qZUPxWEYVWpM3CyNoU6/zMLHQ974XibaeSlNwRrzeuwFND bWV40bg4WBdsjoOTu0D6eC8mjhqFY7uPQDZmIzYuu4o8LfdixqHL6FfBjsI6EvPo60NXT46T48dg 1a1IrLz4AT3KGWJd5wroOmIcyuQeLSS9MNCviD0318Hg+hLkqjIY+4/c+0LUpoWI4FfeQ67GazB6 23WMqWuCIW6VcE+3Nh6+3onslO6kXdGCGDhpLRof7oKDW/YgWN8N09auQeUE0jCcf0c5SYwwbcNm HM9VBdqNFuPS+k7JbNQKPWcs2XEeJUgarXx0OcITk758mWsUM7pZ+25YcHIuJUqJhc7rR9DS10aC 2AevveIRff8aZa4oi+71syN4CUUYpxzaRrlrY+2GeThUsA+aTTuC1QPK4SKl2YyLjUHprguwrl8l bOhZEN027sIDSo1ZxVZpyI96fw5jhi2AdecNuLu8I4IfbEdBCq83YnEtHB41HWtuXMCg2QPQ4FAM PLM1xNm9c2ChQRmyKMsWpYBC2+kHMbN1AezoVw2tF87DEidfrJhCOcDnXsTeIeXx/vA05G84FvMa N8NUVwPh92Bbvjtu7JsMK1pZn+7oj/ytdmLqwZsYWMEflfUOQe5QHVPXrkCez2ew624I4qPo12Sk jRyUuzvu3DuSwCOIqJUZvXjhCKgQ4ETN58IXBCK8P+IDJVgonU2ZGs+mYFW0LrIZ21YMRKGdC1G0 eAUMrptfWJDYAsxUm1WbUIIDlrHBtToaFnXA3lObKJ2BFAr/a6id14GSYMkQRRJJ4KsrOJ3NglzD pPhvYGVsG0Dqv3jSDyYE4eHdF8il5UsbAB2UdKVsVxQVe/bRR9DRZ0r2eERROk04VEK1kpaUF4Ey eTmaQ3EjjNJ4fC2+n9yJALVQoiC7X0Yk9zDxfsow9vAO3OnTvm0aCs46NhUbUtzzEXhw4xJcWfpM q2KoUZriLRMf5ilKH3xgscuA6h37wHFeO+y+8BSlnI/iQqg9BlYpiD13jsGHJGhnh2nCPR4Uz1ly 5haKUEICbYv8qFyStYE2MbnLo1MZB6zZMhbFDq1C8WJl0HtCZyGjU4KGEbSkfphI2crElHvyUyip +A1iBUlVIlGKhGJWuapINCCJDKAYzc9h5FoJdcqxfMZAnU6tYbxhKG4+ckc0BT3PU74WJf+gn3X2 PLDSEguZtJIW9ixWJDJCgvJav6B40YqAc6iai8aKxibCN4zG6ipeJwxH824dcGzMJvSoWogScRRF uUaD4GpDOv6ABEG6FVGSipS50qVmlL+Y5YgIuYVoSnDBUk+mLPkq1EA+qxW4eO4E4t+8QbU2PRD3 /AkunD8L+cWHyFlzMAoSV50REsWwBzEslO0WJf6bIKfoYJp2qEXJIyT0vZ0LzVmynYcJsa+VRB3m +QYeNHXk+8fB8ch4GqsEeLKMqievIGJUFUrzuAgb95fApVvAsF3HQBp1KrQpjImAlFJ4Nq1VSOhn jfYtYbesBw4dOk+Zv8S0wewAh0XxkIliaSMZj/uXHiKkmEyI5V6yZg2BpJWNVXZexNKgwgVtutfB jQVH0apMfuQrVgTV245GTjOl0cAxWyGyJ23DO49gysbDifqbSZPFP+BEncUnQNLus/jXTFpW5WfW ca6AlfsPocrJu4gOeYUFw+ah+aNAPP1wCE4k6TAK8A9kWYNZiYBveCw0dOwgjngDHYtc6NynFUyk CkSGRUCmTUTovZPIVIwyjbqjfHZdylgUiRhaV0sWpxzFt+OIkmPwOZCtpPr4cOM4vAwLokIxyqXM qqf1jOXMhhZFW6ZNgphySCfJUQKpRExEE0NqcXa/ET6SndFDLy8qlsgOXX09wevYL5BlSCKxMy4U n0ltqUGZnrRktN2gRM+UfItKHGJZBifKhc0ygunlqYPGlZ1wetd/WOF4C4bZKqJW+bzYOEYOW7ea 6Fq3IETyGERGRcMiV0kEkU0+gfJ1J6Z1hoZ1cSzcfRRlj11FVMRHLBsxg9JHeiOv5wU43VqNbpP+ Q+Nxq/Df5A6YXdkQk0K0WevgT9I226xo6SoXbJYHmaX9TCByNdTVRNSnECFhBzNmspzLoaT/0KfP BdaUKok5gTY3LEGakNs7SVGmgaRNgQ7VLQpDdHQ4RU8rhm49G8NQEk85wSMRr5UdFqTWzzdiGQ7m r4yXPpG4tXMJ1pAqXMMhH5Y2IrKmGKwS2Q8cn5gm5Du/LbF1CTQskQ27ji2Hd4wc5fo2Rz4dD2w5 tB4vXxig0fRqwr1yVQJw1n0h9SQNlWYiibEYsBTPXpFI5nGUyYwBIE7SXxbyk+VWy1asLjrWyAdR HI1VdDRMnCsJfgJ3j+zHa4pnrq+tieNkyhjSeBIsifXFrF7Kpx3MbibH+Eh/wjhBB/o6UqpPgaKV W6FhcRvEx0RRrukYZC9VgAbivvB7kAnpOJVFmTpTBA1ttuHUQvvpm2Ff9gDc/SNxbt0cLBjYBPoO 9zCpUZ7E35wOdNgmixeOQAoE+KzgU+ILAjrm1rChxf+Vh4/w2ftTlNSjx2JUG0DJQkpURxHXlfgQ YgC2liTQYsaW6VOLh2FR9igYPN2Pbfe80XX1dtT2nonmE59Bxy4/itiEYNWACYhoPh1zm7bE0vmH 8DlMG0WKFMGTfUuw9ZoYFXsOQwG3isittQKrp09B9p7FsXpwC5yWNcaLW3tIcqFFmGJ0q5bA+LhY xMbKk8mKOctUQT7t1VhD9+cOKY11Q1vgWHxNPHh4BHnK1EUVuxlYMmooXONbw+/8Wpz1NMGsDo1g fnwjrcT6X2J/x8tpN0B1C2SrYYzOXVphV6cZmEQq25YzZ6JUGUfUKmSA/2iFz0Z90Ha/ijETj6HF prowTYhDdCxtGBKFWM8ra1CjwzSU6jodXStWRskia/DklT4MaN1OEKTRGGhraOD8hslYcp42EW5a gqOehpT9fwiuHTsAN8sGJE2yXKe0qaH0k/W6NMSEJgswZtQKtC9ngi0jFkOvYHs0LO+Mc1Posi85 RxWEEeX0TqF61pCxusNw6/hOPHKiTGpN3XBhmSf0nAqiiLkvlvadAnnrWRhFNv9+9SriuKI8Fk/q glpVi2Ht2Ve0ISCSlkaS6UMBzxeXcep2YVQmU8S3CwklsIiNpeenlk1dB43b18CkxjMQTfbZMRVL wpFs663IbJJAubDrVCskzD95PO1GYpVx2UVCu+Pw7MZR3KpoiwS2KSGSjE8EW8GuTRHD3Zwc7Rrl 08N+StqdY1QRSN9ewOjpx9BmQ2dEUZrKdu1mwKT7MmyoG4Fa9Yej3WhXnJjVhJwXDaCgvMoTRoxH RNNC2EsJSELtKmMY5VVPuH5aUNEXprH3ubYLk3Y+xYQW/WFIGw4WATw2SX+V4xiKW6dPobyJI6Z3 6oCnFnUxf2gTSCsVxPZb5Hymp8x96uVB2b3ElLPbKGUGFL5AcQRYTjleOAKJCGha5UPhEkbYevel IIk4l2mBse3uYeC41lhJBGRdsCK27p8BZxJlA4jMmNRXmtIP7h7bATfeRqNO75mY2LYCbBNcMM+3 L8a3rAZyaEbOyt3xX+OycKK8ibv3BqB33yEot1EOsVkBTJq/CkVMScIzbYKduxegc7tRaHyK0lu6 lMH8BZPhQuexJLpmMDYj5yGhnSLokXOThblBMrWrWYGm2LF3MTq3GYHGjRdB07kk5i6cQQnu6X79 Ylh+4BCG9m2LNo33UOrE7Bi1it7XyottJ3VhbG4MaaL4p2tIz7JQPYs8chu3gtvkVTgZ7YoezUqQ hCrBtF2ksu3dEQ3LUcIKkQFqdZ+L1kXz4ISOAczNdGhjoQTUtlhDTOl+C31ndMGmiZTGMHcprDu4 CLlI+FW4tcPU5scweUp7XCpUHc3b1saeq2/xyFeBUmUbo2aeTdg+pTd0KF1hKTt7aqMRpQAFpUyc hP1z5eg1pR8OLCA1fomWOL51JoqY0MbI0JjU54lSrkST8p2bwlg/udRrV7wuGhVag4Pz+5FDlD22 zdiJwKjuGNekMiJorPJU74P/mlA2L11DSsM6Ae+GDEP9chshIUm2zZTNGFyfHNNkZmjZpBwmb1uH LgO1cP3qXNil/BWJpDAxt4CGoW6qkrVzqSpwM1yOp3bFkN1aDIv8pcipygCi/JVQwEoJoKauCY0F GUtI3SF1qYQ21VywecdkjNfPgaFFrem7z2Q+UF1rDGPjWGgyPXhiERvmJsfFYxD37Eh92E7T1Rj1 +y9Em2LaWNxlAj46l8Le4d1QKpsI49tswqjNE3G8exlSpSugZZYPTtG3aL5Mh9iqKJb/NwcVS+WG 0+Ht6N+lByqWm0tCsj16jF+GGjRJI59IYWZsTOlPv57pdnarT+afjXS8sCt5ee/HmBnj0KfHQFQv t4Tys5ug1+Id6FLJiVobj5d3yFSTtzjy2HC1N1+Qv0WAEzWfFV8RkFqifIXS2Lz2Ap5FjkdRAwe0 m7Yd9YcuBRPMZDqGMEhUzTF1bAzJuDnrDcSa7csREqWAMTlTKdXR9ui/9ADaT6Ik9vROx9gU2ol6 6kL1++JCpdYIiyX7pUwPJgaqCB4SuNYdiCvv2yOCVJ4iTX2Y6CkXvS6LbqJ1vAyGwqV6GLaanKzo ffIz1WLkr9UPl9+1QXiK+4UWFa2BnRffICCMNhgSLZJclAti02kXUHuihDyo2TsZus87hbZxEhiq 1lutAthy8w0ixLowoXzRrJjlcMPaE/cxS9CNSmHKvLiotFhwEPXiRTBIbJhYl/KTj96A6r3nCqp0 qZaeoLpmRaxti5E7zqA7eadr6JlAT0OBqeT8pm0khkxWHgdvvUU4YSTT1INMfBy1Bqrq1UeNIYvx iIiGaek19E2hNOUXIScyyj2uoTyxLHKqirPPX0FM9yctMms37LzyEmExCkikJL3paGPg6iPoOCNY OVYmNFaJXJerQlscudoAgWTSYBskU1Mh2TkVQwxddgKdZzIZMuU4qC4piF1XnyFBqp1q5jCZdUUc evcOcRJtMlRQ7fma4Oq7KoiX6grqf1Yq9duGN90SoGdAuEucsPTgfUyNihParaVZG2/qyek75bG/ Kn3W401nBfRTSKSWucthw5lHmBvC2qoaKzm6zD6F7jrGNKbMwQIYuPEmOpBpREJOezvDQqGQmmHQ 8uNYRue4QfPUOHGeOhVvgoM3qyIwkqVJ1YSpsRJfRe4GOP+mKiS0WVMVTYeKOEBjwrCWatJvR0+G M3cbIJjdSxs+UxPWcyqx73DhfhgKVqxER8WSGnS+VMX/yOIIcKLO4hMgefclqN+yNUwWtsP63c9R tEMe4WtDItqURUHOPEH0oW9QOKTaRqATVSmKCEamqade0tA3wfeSMmkZmXw9k5tYo7aecZLFXgRt faPvpo3UpPu/G7xLw5DIJnkzteiMdlKZU0vP8JvnazJJNWX3JDpUV3I1pZb+t/ey2/SNvtNbkQZM iBiVhRZuc8GbSSiMvFW0yJyjtFLgq0d1JqNgCREm9f1LIeczQ+Mk75O0X0a2eZNkgpvku2PFNkyp RkOj404mJj9Q05JEbWD0o8hnEugxL/kvRUyakuTtlWkbwCRJv8Up3msmGRSZNm3svpmDiZUT+Zua Ju2wFOaWVslGVETXmFiwa+Rkpw9CrG8kOUyKYGz97diJtGkepXiWmE5BGJp8O/NkbByTDJQklXs/ ntqKox8TMKN9KzVKh/rNksA/SEcEOFGnI7jqWLVugfqYN3YagnSZU9b3i651IQwaMAAOJdM/E5U6 4sjbrK4IiFCieS8MKiSFwz/SQkfIXDB6+CK0Lft1o6au6PF2pw8CnKjTB1c1rlUfzelM78+Krl1x jFtY/GeX8e85AmqGgASlOwyFMi7fvyl5a7RH3hr/5ln8KeqJACdq9Rw33mqOAEeAI8ARyCIIcKLO IgPNu8kR4AhwBDgC6okAJ2r1HDfeao4AR4AjwBHIIghwos4iA827yRHgCHAEOALqiQAnavUcN95q jgBHgCPAEcgiCHCiziIDzbvJEeAIcAQ4AuqJACdq9Rw33mqOAEeAI8ARyCIIcKLOIgPNu8kR4Ahw BDgC6okAJ2r1HDfeao4AR4AjwBHIIghwos4iA827yRHgCHAEOALqiYDaE3VUwAdcuXwXAZSvGCIt 5KW8xK52yow6vHAEOAIcAY4AR0DdEVB7or69ZTGmHw1B43qFkCDShiPL/ccLR4AjwBHgCHAEMgkC ak7U0Xjup0DtoVPQr7pNJhkS3g2OAEeAI8AR4Ah8RUC9iTouAB/fXsGVV9F4f0AMx7INMahVdWgk Jr7nA80R4AhwBDgCHAF1R0C9iTo+BvY5GmJgzSYo5WSI8xunYOp/hpjcvuQ345KQkCB8JhJxFlf3 ScvbzxHgCHAEshIC6k3UWi7oNXnsl/Fyy2uPHduPwq9dSZin4OOlS5fiyZMniI6ORtGiRaGtrQ0V eWelAed95QhwBDIHAmz9io+PR5EiRVCqVKnM0Snei1QRUGuijv38EDuOPUOtTq1gTt2LiYyHtokN dFMRmrt27Qq5XI7Ro0fj4MGD6Ny5M8LDw/m04AhwBDgCaomAWCzGhw8fYGPD/XPUcgB/odFqTdQS LR28ursbL8ITUNJBF+/ehaJuqzbQSQUAJkGzoqurK0zswoULIzg4+Beg4pdyBDgCHIGMg4BMJkNI SAgYYfOSuRFQb6I2zIGpM+dj66ZdePkSKFR/MKq7Wv9wxJi6SKFQIDY2FnFxdPaaF44AR4AjoIYI qNYyNWw6b/IvIqDWRC30Vc8JbfoM/8Vu88s5AhwBjgBHgCOgHgioP1GrB868lRwBjgBHgCPAEfgt BDhR/xZs/CaOAEeAI8AR4Aj8GwQ4Uf8bnPlTOAIcAY4AR4Aj8FsIcKL+Ldj4TRwBjgBHgCPAEfg3 CHCi/jc486dwBDgCHAGOAEfgtxDgRP1bsPGbOAIcAY4AR4Aj8G8Q4ET9b3DmT+EIcAQ4AhwBjsBv IcCJ+rdg4zdxBDgCHAGOAEfg3yDAifrf4MyfwhHgCHAEOAIcgd9CgBP1b8HGb+IIcAQ4AhwBjsC/ QYAT9b/BmT+FI8AR4AhwBDgCv4UAJ+rfgo3fxBHgCHAEOAIcgX+DACfqf4MzfwpHgCPAEeAIcAR+ CwFO1L8FG7+JI8AR4AhwBDgC/wYBtSDqyE83sOnMBzRr1xJmKVr8+fFprNx4EpFSCSDSQ+V2vVAj n9m/QY8/hSPAEeAIcAQ4AumMgBoQdSgW9+uMUa+Ko27HlingSMCtffvxODoPxveoAIUCMLfVS2fI ePUcAY4AR4AjwBH4dwhkeKJ+e34XDj2LRqECRkiIJ2CStjghCu6KBOQuXRxmZmYwtrGB9r/Djj+J I8AR4AhwBDgC6Y5AhibquIAbWL3jDbqN6oej518gRp6CqGO88PL6RTx8IULoTSm07HKiZ5ducDHV THfg+AM4AhwBjgBHgCPwLxDIuEQdH4pdq3fDvu0wdHK4jv1nXkNfKwUkEkO0GLoaw0uXhR1pvK8s 649JSw9j7YSmkH0HPW1tbWhqasLQ0BAJCQn/AmP+DI4AR4Aj8NcRkMlkkEqlfB3768hmvAozLFEH 3tuHRZuuoLzUFlN2XsaLxx7YuPMc+raojC9WaJk5ylQ3/4KqnaMDQi8+QFBCU1iIvoL99OlTHDly RPjgwoULCAkJwcKFCxEdHZ3xRoS3iCPAEeAIpAEBsVgMDQ0N5M2bNw1X80vUGYEMS9S62atg4WoH hIRG4LP8FbR1Q2FnZ5lMUo7xuILRs/ej86x5yEfGaV9PX+jnKA6TJCTNBodJz6rJfOvWLWG8XFxc EBkZqc5jx9vOEeAIZGEEJBIJAgMDyYmWvGh5ydQIZFii1jS2R+ny9gL44Tb+2PUIqFomHzQCnmHj iaeo1qApbCzzwy3vISwaPgSWRjrQMLZG/+7Vk/mbsfvt7OyEFyuMqD99+oTatWsLkjUvHAGOAEdA HRFgau+zZ88iLi5OHZvP2/wLCGRYok7aB63cDbFqbk0Ip6O1FHj19g3y+sth62SEpj2nId+dm/CL VMDJtSwcjMQ/7H5sbKwwsSMiIoQXLxwBjgBHQB0RYEQdHx8PkSiFClEdO8Pb/EME1IKopTrGsNdR 9iM2VIz8uRxhZalyF5MhT7GyyMMHmiPAEeAIcAQ4ApkQAbUg6qS4S02zoVE9J5DzNi8cAY4AR4Aj wBHI9AioHVGLNTShrZHpx4V3kCPAEeAIcAQ4AgICakfUfNw4AhwBjgBHgCOQlRDgRJ2VRpv3lSPA EeAIcATUDgFO1Go3ZLzBHAGOAEeAI5CVEOBEnZVGm/eVI8AR4AhwBNQOAU7UajdkvMEcAY4AR4Aj kJUQ4ESdlUab95UjwBHgCHAE1A4BTtRqN2S8wRwBjgBHgCOQlRDgRJ2VRpv3lSPAEeAIcATUDgFO 1Go3ZLzBHAGOAEeAI5CVEOBEnZVGm/eVI8AR4AhwBNQOAU7UajdkvMEcAY4AR4AjkJUQyDREHel5 G/uu+6Je4zow/HGmy6w0vryvHAGOAEeAI6DmCGQSog7Fwn6dMO5DGXg1IaJW80HhzecIcAQ4AhwB joAKgUxB1G8v7Mb+O8FwdTNGQgJ1jedR5zOcI8AR4AhwBDIJAmpP1PLAW1i74w06j+yFs3c+I4YR NS8cAY4AR4AjwBHIJAioN1ErwrB77S7YthqCbpbncfxGAAwkPx4ZbW1taGpqwtDQkKRvzuqZZB7z bnAEshwCUqkU7MXXscw/9GpN1L43d2De+uuorXsQ8/afwuunfth+7AY61S4F7RRjd/jwYXz48AFX r15FcHAwVq1ahaioqMw/wryHHAGOQKZEQCKRCCSdN2/eTNk/3qmvCKg1Ueu5VMCUuRYID4+El4c2 pDJN6OvrIDWnb319fZiamoJJ1JGRkYJEraGhwecCR4AjwBFQSwTEYrGwlnGJWi2H75cardZErWOZ E7Xq5hQ6HOgQgKMfXqBWOVdopgJBxYoVhU9fvHiBT58+oXnz5oJkzQtHgCPAEVBHBJja++zZs4iN jVXH5vM2/wICak3USfupm78plkyNgcFPvL5jYmKEiR0WFkaSePgvQMUv5QhwBDgCGQcBRtRyuRwi ET/mknFGJX1akmmIWtPACrkM0gckXitHgCPAEeAIcAT+XwhkGqL+fwHIn8sR+FcIMMFJIhELNsn4 eH5i4V/hzp/DEfh/I8CJ+v89Avz5HIE0ICAWi4ikRQgNjYWWlpSOGIoRE6MgtWcabuaXcAQ4AmqN ACdqtR4+3visgAAjaX19KdaseYft298iTx4TTJ3qCl1dCXn9xnOyzgqTgPcxSyPAiTpLD3/m6DyL W6OhIYaOjoQkzjhlGNkMVn5V8mV90NOTQiYTC0S8evU7LF/+inolwrVrPhg5MgGzZhWEubkm4uIU 5BgpF9ThaX1ORsQogw0Zbw5HIMMgwIk6wwwFb8jvIMAIh0mW7u5RuEGR6Ro0sBG8YBl5pZW0fuW5 7HlSqUgg0PQqSlu0CKdOfYavbxS8vGKwa9dHehx7JtN1a+DWLV8MGfIQFSuaEUED9erZwMhIRl7A f3+XolAk0EkJRXp1l9fLEeAI/AQBTtR8iqgtAkqpUwJ//1iMHfuIzsj70Rn5CAwbllsg6Z85XDGn LKlULBB9WgsjUD+/GLx7x472pc1ArK0tweHDXrhy5TMUCiYh//w+imVBzwgl8tUk9TYjSfZK+nOV 4N69AOpvJLUnklTiHwkLDar/x0TN+szi/LRu7UwRrfQRHf0zAk4gfKTIkUM/UVPx840AGxcm4bO2 pKWvrE0ZQcJnw2JgIBNs/1FR3KSQ1t8Evy79EeBEnf4YZ/gnqKRETU0JSWSKDOekxIhOueAnJQmR oO5+7RWCQUPvw+NFIH0vw86dLxCqiMWEIflp8Rf9MGoTu9/bOxr793uQxJg2UtHSEuPhwxAiST96 XtoJnrW9Rg1rsjXLfrqBYBMmIUFB11uhbVtHBAbGYvDgB3j9OkjoIyNtDQ0RJk1yRZ061oLkfe2a b+Im4MfTjTmhPXsWSvc+SEH837svQdgANGxoKxDvzwlVQWSnSQGF7MjpTfLTjQN7KtNOsA1T2iJs iQg/hbDBSMN+J02/PdYnmUwkzDHmB1C4sDGKFjUWzCi8cAQyAgKcqDPCKPwf28AWKUY+ERHxePIk CJaWOrCz0xbe/+pCyJye0noPsycz6fRHhdWlIIHv3r1gkirZovn1epUX9PnFITB9ZgRbWAhEzqjc fXccGl+5jphY0gn/oLDnh4XFkvSUAAcHHUFd/rPC8KKcLhg3zpWkTD0ijB8/Q1Ufe5arq5Hgrf0z qVd5j0i4jkmmVlZaWLCgEJH1fbx6FUh1aGDCBFfUrm2FoKBYlCtnhqpVLYX+/6wwQvT1jcbbt2HC RuZHRTWe69d/oAhY3nTpz9X9jPDc3cNpw/SRyO/nRC0WK1C5sjWqV7cUHON+VkSiBJiZaSFfPoM0 bXhYfaxeZhL43txkY8M2bXPnvsSOHa8o1LABFi0qQhoHA4SExKV5Tv+s7fx7jsDvIsCJ+neRywT3 qUia2TinTHmGixc94OhoiPnzi9C/OoJEwaRZtoj9rLBFMCxMnmjL/DEBMBvvunXvSbUb9sPFnxEF k55OnvxM1zESTVqvkpSeoi/ywjxZ894iGI2NNqF0JWPERn+/5UyCk0gSULq0BQoVMkyDGvhrXb+y KVHdFRkppw3Qz5D89ntG1paWWpgzpxAR9EPUr+9AJG0tkDQrTE3LXmkpSulRTJsG47RcLlwzd65r GiRpZXVsI3L2rC+ZIYLp3Y81Dmwe+PvHEKm7C6+0FQVJ+JpE7hY/tZsrN1Uiku4dhI0YU2mnLGze fiXpd/S1FgICosj+fw/z5jGy1ieyZtG/0tY6fhVHID0Q4ESdHqiqSZ1M+mF23LFjnxBJe7JlFh8/ hgmS2/z5hWkxN8SdO0ECoTLp60eLFVOb7979CY8fB9K1TFX9fRDYdxERscid25AuYurpHwGmQOPG tmjTxlGQeFXXJpBklUAkazeE8qSlWOMtLDUwd4krLG01kcCI+oeLrEiQikNDf20x/rkK+O9NAoYX I2sLC03y9C4ieIMHB/9efGeV7T6txM568SskxZzOKlWyIAnZiu78sYTPVM0xMfFEpPaJau+fSfgQ TBSrVr2ljUAItevHG0hGwG/fhpN/gCfZ2VO336s2LqGhMdRethyyNkjx+XMU+vW7i2nTXFGkiNEv beL+3sjzmjgCSgQ4UWfRmcAkQrZIDR/+CNevM7WmKpOYTCDrnj3vomBBI/ougEg1hiRPlvf2x4TK bJldu+ZIg3pXqb5Uqmt/XpJG4kqgtTlejxyVZArIgmWQMa+rFEVTJIFhtBb8KKtagoxUnnEiSCN+ PtX/Jfn+vNfJr2BkySRC5vjG/Aj+ZflVXCIi5GluHusX0978Spk/v2CanNQYUT9/HkqbzQAyI6S+ 0WQaoytXAnDhAtuoMvu/qig3cErTBhenf2V8+LV/H4Gfr15//5m8xgyEwPcceNjizFS1JUqYEPk6 w9j450d/mK2P2VPZJuBnhUnyTEpkJVWJjZ7PSJkRMisJYpKgiXQlERJYbbMW3ptdNIP2x28XeQ0f TRRvWArurd0RZReFGPMY+FX0g0hOi3U8vZhtluoXx/5cpf+zfvzr79Pj+NW/7kPS57F5lppK+kdt SquEz3LusE1Arlz6362OzVl2tG3yZDGOHv2USNbxlAZXRtqLwihZ0oS0F9xO/f+cI/zZXKLOsnOA OSoxx6I5cwqS6ltMqm8vwoJJ1XFkz9MXVN958hgIqknmYZtWqYrZqX+1fKk7kd8ZCccZxEESJYHu R13Ea8bD5qANTG6bCESt+14Xcl16DuPZVKR8OUncvpV9YbvPViBnSTQFQskXKpC7RwsPhOQPEe6L dI4UiFsanrhf/bkv1q92jV+fDgikdS6qtBA/2ggo7dhicg7Mx7aMRNbvyLSgi9mzOUn/6dCxDIUD Bw4kHwCVtu5Pa8w894eEhNBGcBbs7e3T1CkuUacJpsx5EbP5Mo9vFo5yzBjg0iVPImmlM5mzsw55 B8f8kn3yl1FiUjPZmRWaSqlZROpJhYSOHgVrwG6PnUDI1oesv1TrV8EPcgc53Nu5w6e6j0DA9jvt oRGYfCGINY7Fxw4f8WbgG4GoHbY6QCNAA3pv9ZBvLFuQAUbmn1p8EiRun9o+wrOZ3VvQctI/rG5e Mj8CKjJnZD1iRG6SpKWkRTIVNElMkubl9xHw9fWlTX40pk+f/vuVZNI7x48fTybGj5mHqN8+uISP gSLkL1UOFqmYsuIi/PH00QsERjHnGhmcChSFi/mv2bwy6Vz4abfYIsWkZUbWTKJ49cqWVNe6NHm0 f9m56qcPE5iYOJCRIZV43XgoNMjOHCKD4RND4W/b3bYwemAkSLiMfKOto/Gx3Uf4l/cXCDeoWJBw nSRGAnE0HXMign/X851A9kkLk5KZ5C2ozcns+HrAayRoJECTVOIGLwyEzYDjf46wPWArELjzOmeh Ds8mnggqGiSQNpO6mQTOCPsLaXOJO03DrG4Xsd8Bc4JjJhsWLIdJ4Fzd/eejyJwFzczM6MRC2nxR /vyJ6lODhYUFzbe0m94yrkRN7rrnVs/BqpteyGMrwtYjtzFkTH/kNU3e5Ltb52HUtveoUDE3qUJ1 AZu8nKh/Yb6qyFpbW0xShLngWf07Z6h/9Mh4nXiB9MRxYsEuzEiRSblaXlrQ/qQNs6tmX273bOyJ eO14gZQDygQIqmmFlIJbkF1ZGkljn+J4kzTs51NYFkpsTSTLiD2gZIDwrBBX8hqmOm322kAzQBO6 b3WRY34OZTto4faq76W8vnQAAtyoHUzaJ+Jn/zKVfBqOLP/CKPBLMwICzBzEzk0LU+DnbhYZockZ vg0KFgiBl28Q+FVcfr7K/Z9ATohyx7UHAeg6YQWqOdI5345VsORgaazoXCpJi6Lx+EM0ao1aiOEU xYmX30OALUrMSUku/4FzVxqrFiTmRK2xXEdZn8ktE4HgjO5RYJL9ZDcm8mUe25EOSq/s1wNfI7BU oPB5aB6yJRORC5IsI0Qq4pi07zy/20zqo2CPVnl/J0r3n9p+Ukr21B7dd7oCGTtsc4DhY0NB2rfb ZYcYixh41/JGUEkWGQwILEFH0KS08aBNh9A2VjdJ/LxwBDgCHIH0QCDDErVIJyfGrlhIYlAU3O9d xOswQ1TJ75wcA3kIPH1u48rWWfh8SoxsFZujd72S6YETr/NHCDCiJ+cugWAjJV/I0Gmdk2BnNr9A AUkSbb/MHhyeMxxxhnHwrs2OhdFXLNQnETz7VxamlH7TvTBzNJPSEyVy1vaw3CwAC/Bi7AtBimeS tsUpC+i/1ofTJic4bXYS2uZfzh8KLQX8y/rDr5IfxJFixJqQ6YU4W3BM+xftT3eA+AM4ApkDAf9H JzBl/WlItO3QbfhA5DGmxSjkORZMW453eoUwYlgn2JFG8d2t/XgWnQN1y+dPteMPjy7G2lPvoCFV ChByqQmatWuL8EeHISvSGlVym6QbYBmWqFU9jnx/G3OW/YcA3WzIZ5bCezAuhCJnFUGT6k1QxtkA 1/evxLx4HQxpWOC7gEmlUjoTLCG7rJbg6JDVC5NoVXZjFRaMwNjZ41QLfaw6MhVHHuJx4jhBpW1x 1kKQmo1vG8P2jK3yVuK96BLR8O3ki08tPwnXMbszc+Ri9euEJ/ElUGnI/p8Ooqo2sK6TMiDBJAGf u3+GP/lB+HTzEVThtntsYfiIpG1/GSwmUNjShXQdqUzfdHyDaNtowZ7OvNRlCjrjnXgul/Wbk3dW /6X9/f6ztYzZOdMWI/3vP/9f1PjyZQAdrzP97UdFuZ/H2NnbULLzINi/PoAxU+Zh48z+uLJqCTzM 3ZA98BwmrbXH6l5FcPDUHbg0LPPdZ908vRcv4upjXpdqwjW+z45hSqdu+JDgjR6z6mdtotbJVh5L 1pXHlSW9MGLqWuxfNwwGKg7RzokRyxZ/AVb3jTUG7NqPjg0KwDQJz9y+fRubNm0Srrt+/Tqd3w3H xIkTyYHk96I7/fasyWg3kuTHJEqmEk5aGBHHmsYqnagSJWEmMTMVMSMdbU+KBkakVk9UD3Ui6gjq X0Ze7Ht2/QLJAryi/2Ic6fxybjq/HCuCeL1Sfc0ImhG62sSQEM5zK89ws8IkbUVuUpWT3dvS0xKi GBEa0X9VV1YVcGDHwJjK/5zOOeym/1g/o2yiBJJnqnLBzs4LR+AvIMCctczNzSmCoOtfqC3jVTFl ykWKQncJW7a0R8WKZP/8jXL32G6EW5ZDp8qFgUpG2NVkGM68bgDPNxEo2Ls1qvp64vq1ALy9ew5h VhVQNz/LGZB6kWgbwcWlwFe8XV1wbuM6nDojh4FO+koYGXbVkAe9wakrb+FWrwaMCTeXbM6QXAoG k4ENEnGMC3iJ09c+oWy9qsJncrkE2jq6oMRCyUrevHnJm3OY8NmMGTPg4+OD9u3bU2xqpaozKxam 6mWkW7R7UWiFayWDIFYSi6dTniK4SLBAPoxkzC6bQfcDYUte0g7nHYh/yOZM/8UUihFI/W2ft/Bs 5CmQEUVWphQZJGEnel+ryD5T4Jy4cWF2eHlXpQ1eTv9d1roMmyOUE/o+ea2HSlHvYj2Upf9Yca/q jhjLGOEomG9FXwEjIegKFSHoCve3yRRT4193gknUz549y5QCx4wZVzB+/AmCNAFNmmzBoUPtUaZM 2s4cfx0HBXw8Y6FjlnifSBc2lFHnja8m6jUrhBkLeuM8/XYbdSiN01duo2a7Zj+MTs9+sfHyr0f2 Qt9ewdMgEzjkVVAo5rTF2v/dOZJhiVpER2jObZuNix7RaFjIAjcvfUCt1r1gFh2E95/DYe1gT/FP Y3Fi7wI8JL6t6KyLh68+o0LjHkgZh0hXV5dCL5JHOBUTExPyao6giEWOdAQj+HdxU/v7VETtZOQE SXiKM8M05/Sv6+N16dew32cP0+um0H5MUjQBy445BdQLEM4e+0f5w7+kP+L0SP1NhMOOTTHbrSX9 x4hcKGyXlclLPOioGf3n3sodHzp8gDRKCrMbZhBRQghmEihxvoSgSkcISddHowSPdq+GXsIRs4js EYIEzjZNgn1btRFItHMzHJmGQwjwkqQwrYRwPSf5TD67vt89RtTv3r2j8KjqMQk+fQqh5DHJs+Cl 1rv9+19g9Oij9BUL6SqlNK8RFD3uP5KsmyF79rTZgZ2cjCjQSgIio2MRY6ByRqUNspR+f5R0JU/T 3ugdexQ+BnmRS34fx+wLIP7OarTeegl5KrfH0I41QNFlkxVdWQyu7l6Knq8OC59H0JG+xqNmI8/B 6YiM+fVAT78ycTMsUUsMcmLWkiVYuXITBdWXIH+NvmhdKS/kAbewYPkRdOw/HkXsCmDenJl0zVYc fiJG4bp90ax04hGb76DAdj5sYsfFxX3xcv4VwDLLtcyuJZaTE1RCLLTpv5TF7LAZ2IsV30q+8O2g tDMLntw0gdkRKiEwCDmPaQQlV/sw4spqhRGqVJ54fIzI1resr0C6fq5+eN73uUDEdtvtoPNJBzYb bYQXKz41fRBtE41Iu0j41PERxoSd82aOaYzIGdaaXpqwOaG8XlUYcXvXJ2c8FbFnNcB5fwUE1Mk+ 3azZHty8+ZpaTXlif1iUMTGUgTPZjlWLMsVFUO51Zr78WSAitmmhGO8vBiJ3LmOYGWtA60vKOjmi I2UwNWEaRE2UqtOY/g3EivneKFDKGBuWXkbHvj1xYP4S7CteAm1SZJiLlGugaO2WmN6nptB6saYe jHQjMWRnTJojN/7utM2wRM06JDHLiz5jZyXrm0hqiLy5HKCppZTYZOYF0G/czN/tP7/vOwj41PKB ext34YgUO3Mcr0UOUswjm/0O6JWW88tZFlxm+1eFJaVpymzcDL+3/d8Kx7hYGFMmJZtfMoflcUsY 3zOGJqnjXFa5CJ7zHi0pzGmBEITlCBPMCq5DXGFy41tJgo3Nh24kwZOqnReOQEZHYMOG+mRuZFnK fnyU8cCBF2SiPJV4HSPmGOjoaGHNmoZpl6gdlXrVXEVzwG/bHYSSH4mB9ws8IQFlaPav0Q7fnTkA P8uS6GgfiEW+MrgWKoirFFo5MOJbR2OWcldDx0DQyn4psf5gae+19AzTFX61+4XHyw1QrlRJuJj9 bGeVrrhlmsqZRJxaibIlFVGJIMiCZMnONGeajv+rjiQeAxM2lXRWm61RjITZv+yY2vsu7wXnOpv9 NgLhGjw3+BJ4hZ3XZnZtFq0ttaLtrf1NVLZ/1S3+HI7AryKQJ0/yvPHfu79ECVtBQp05k5E1yxin j717W6FGjey/+khkq9wFta+MQqeeI2AZ6oOy7UainEOiBjD4DbZfcUeN7u2gbRGB+hUPoV/XntCx ckX7PN86lUmktBam3GNINMki6I/9i8fg00Gl95RBDjf0bl8fFI32r5W/WNVfa9MPK9IwtUY+evHy hwgwjRJNusCSgdD0T66KYmeCvRp4QfOz5jce4X/4VH47MxckBnJRCRbseBzTXjDPcrYxYuNhct0E NodtoPGQFpXvmCCZ+pudR2eWBuahL3jTs41BCi9+DjpHQN0QmDGjCiVLkeDatefo37/qb5G00GeZ GQXNmoOi919CoWONovkcvkKhbYH2fQfAzoyp2Y3QY9AMFH/pDpschWGl/63U33TICtSVqFyZE6uR mGD44oNw96JNNUV1ZEXD0BJ0LPuvFrUj6r/a+yxcmSoJxbOJz5RZqJIWWuyZTVU4S/1jLVUWRvAv dF3lMMYCvSSGOWWqb3bWnMUdZypyVkq2KCkkFElZzM+bo1iHYoJU/aHzByGdJ4uYxtTljNy/OJz9 habyKjgC/xqBiRMr0iPZ6w+L1AiFi6cSCEvTAPZJZRRdMxQp8jWcccqn6ptYfeOozBZII6tswis9 Cyfq9ERXDepmntqplkSJWw26kHmayPZFJBWzs9msqJKNMC/y1Ao7k82c2ExumsDinIVg9w7PFQ6P Jh6ChM2yiPlWIae2xHSgqsArwjN4yNPMM294TzI9ApyoM/0Q/6SDPNxlhp0BQiIQCiLzse1HOK13 StZOuaEcTyc+FWKkG981ht5rPYGcndY6IffM3MrMX6RiZwFYWGGJUd71eCdI23Jt8n4lT3OmIk8m dfO5kGHnAm9Y1kaAE3XWHn/e+4yMADNB0Pl0dubatypJxkmK4ElOqUJZ9rFIx0jBMY2pu1lAFRZM hUVQs99tD71XekLAGiZ1F+1aVKghPHs4vOt4C8QuJByhv7+URFMHk7iFYCzc9JGRZwhvWxZBIB2J mvL7un+CoY0D9Ogpn948QXC0DNnz50rl1G4WQZt3kyPwqwgk+gswiTg5UydmFWPnrSl6nCrDGAs4 ozpbzTzKmfqcqcT1X+kLoV9ZcJtsK7MJSUYY2bO8344bHQXbNjuXHVAqQJDEmb07wjlCONf9JcIc NUCIqMYl718dRX49R+CPEEgnoo7AkUV90GP2c6y9fAG29yahegfKcEVHgar2moLVs0fB+VvfmD/q CL+ZI5BpEWCe3Gm0KSf1+P5ylpvuj7aioCr2kQLRCnm+6T9G4jb7bKDlrQUddx1kX5RdeLHCVOOf q3wWos2xYCwsT7ggqRPpC0lZEjcQqjSfmRZ73jGOQAZAIF2IOvLdZUyasgVVx51BeYuPaDtoFmzb LMWRxjI0ajwEC4vXxKJOhTNA93kTOAJZAAESgoXc2UyVTUVIMsKYloT0T60T83FT7m2mJmffsWA2 2VZkExzU2Hu7T3Zw2kgSOBE7U8OzEKgsaho74x2WK0w4IcCkcNUmQXVMLAsgy7vIEfgnCKQLUX9+ ex+BASXRrXdFiO7NwQlPC0xv0xrFKmijnsU8fHr6ljrHifqfjDB/CEcgBQICkSYWIcIcyxBGJKxy PGNf3S12V5n+lC61PmotqMh13+rCeY2z8GKFnbcPcAsQ/nZv545oy2iBtFkaUxaJjUngwgaBhULl tm4+DzkCv41AuhC1TJMiJsEH4aEJuH78KKLN7VGygDEQfBrXfH3gavH7+UV/u6f8xkyMAMmHCTLK YEM2WEkURKKfB/7PxGD8etcSj4V9CcTCakhCrCz4DVN3M1L/0OmDQOoaIRpwXukMHQ8d6L/Qh9Vx K8Fpjd3n2dATIQVDBLs5c1wLLRAqELhA2Kqz44ke57/eWH4HRyDrIZAuRG3pWgUVy89Bz/JFEP78 IaoP24jCsrtoV7QtnlsXx5xWblkPad7jdEMgPl4XBgbPYG+/FW/f9kFMjBnE4vTNZpNunckoFSdx GFPFdWdq8Cj7KIFsmQ37/rL7AjmzXOSGj5X5yBlp2+22g/0ue8GuzpzgggsFCyr0993eI8YsRnBQ Y/+yI2bsGsGWrjq3zx3VMsoMyBztUMTh1OpJ2PEoBNLYWFTpMQEtittAEfAAMyYuxTvdgpSpqyey Gcjw4sp2PIvNh8aVU8/vfXvvDKw48RG6WiySGRAnMkDjtu0R8Xg/NEt2Re383w+W8qdgpgtRy4wK YNn6regzahEiSrXEzOntoRVwDRZlu+D0uFEob588//GfdoLfn5URYKKfCJaWJ+h1mqRqPTx9OpFS 3AUmFwuzMkR/qe9Jg7GwKgVHMjoVFpEtAqF56bw2S/ZFtuqPHT4KXuSyQBmc1zkLZMzydBfvUFwg bFa863kjLG+YkI3tc43Pgppd8ChnQnlirm4WGU+we3O1+V8awaxXzcPdEzB2+W2M3bwKRo9WodfA wbDbsxzBm1cjPHdduPkfxZS1p7G+X1EcOf8M+VrU+C5I9y6fhI9+MyztW0u4xu/ZEYzv2R2vFQHo 79watdMR3nQhatZe7WwVsX5Xxa9NtyiNeetLp2NXeNVZDwERpSrVhba2F2xsDgndNzO7AH39FwgJ KUSxgv1IDa461sRFtXSZH8xRLcnxMEa4LCIaI9s4gzg8mvNIyGGu/1wfem+UZ7oNHhvAbq8dLM5Y QBohheNmR6FpLHb5u54UlIVs34zcoxyiEGsU+zVXt6oD6TqUql1Buj4kXYYiU1T6hnrRN5We1P3O 5z/ptFXhxli7fwhcs5G5tdAkNNnXEBfvvYTBx2jk7lobVXyf4/ztMLy+eZa0RVVQM+f3811LtQ1h Z5UdLi4uwlNdXLqg+LKlOHUqDnrayVP9/u2xSDei/tsN/W59sZ+xY8M6vAuQonyz7iibw+ifPZo/ 6P+BAKlT45UamYQEMUnO/siXbxzZpiOFzzQ0guDktIHS6eWBr28lUoNbEVnL6VrlVBeLY4T3XExL n7FjBC3EiBcQTgyaQpzHPMTZuWwmHTMHNPe27kJQFkbYjMDjNeNhes0URXoW+dIw38q+CM8Rjjjj OHjV9/ryuRBalQnaLCgLk+r/osStUEhprkhoPrF0jJys02eW/KBWBvvJVL5PkkvjV9pkmbMYLBNv CLm3E8c/xWCKqyuy6xTCpLndcFKsiebdyuLUzTuo16ElRepjueBTz6jBpllcTCTi4pgPDM3jF6fw KNgS2QtRtL/4FHEOfqWRabg2/YhaEY4zm+dhzNRN8I1nE16MMk2HY/aEbrDR+zupRRJivTGv5wA8 c6qBpgVisGziGERMmoUa2fkh7TSMvdpcwgiZrcZySnHKiJZJzNraHnB2XksLaji0tJJH7bKyOgH2 cnZeQz8qQ4SH58THj+0Egg4Pz4HYWHP6OxZSKREHLcYi5t3MF+X0mw8ppG5GrMyezYqgJmdBWYi0 WeIRbQ9twWOc5ei23WcLwyeGQq5ux00kddMwMY/yt73eIs4oTgiHypzVkgVlYasp4/Eknu1p6xid EVdooFChAQgMLEbzpT0n67QBl/arXtClZCr5YWHXpFaC6MM7aX8U8tO1SSysYc8OosGgVSjTfy5q 2OtCZN8TwyQX4aefA5YBV/DBsQBCLi9Gsx3XkbNcS4zs0Qj6SlP0l6Iri8H1/avQ581x4bMocmBt P3ku7m0bh6iY9PWJSR+iTgjFlnGt0W76BdTt1ANVrChFCRH3yf96o+zjRzi1axmyp8gW9gtD8OXS BHk0HMo0QosOrWBPPbm1rxwOX31BRF3sd6rj92QoBJgnt/SLJzeTmJ2c1lMC+U+wsDgjtDQ0NA9k suBUWx0Wlhv+/mVosY2Gnd0emJufF64LDi5MZJ2dyNoEnz61pE+UC7RCwdLokGezlEnmXJJK16nA iDQxFafKUY1BzqKhscxhTH3Ojop9avVJIHHrQ9ZCQBYWdc38rDkKDikoNC/GMgZ+FfwEqTrSIRIe zTyUgWHof0yNzv794m3+PambnqsgaT6O8iJZ6V6BsfEdet2CT2BVREdbQhpP0tNflNjTFdeMXnlH auDN32zkHrqPvdJantOFuZUXe93cgs5jV6Fc3+WY0qxQYg0acC1fjf72xZJ5fnAtbYJNC+5iwJgR 2D1lBvaVKY8OhZOfToqM00SpBu2xaIDSGi3W0IamJAjX1scK+bPTs6QLUQc9PYGJs4+i+viDODyp /pf2j+5YFkVL9cGCnR2xrFvxP+6XWMcZzbs4IyHgNbZuWo1rkfkxo/ZX1VlqD5BIJCSViWlBlgov XjIWAkyrxCRouVyPSDiUJONLyJZtLUnNLOVjKKKi8sHTswu8vOoL0nLx4h3oc+Y4lrxokMTm5dVF 8AD39W1CUrMIhoaPiLR3kjT+iOzXL8nGtEtQc/r41ERAQFki6zj4+ZUSiJupPpn0zlZpNk3odl7S GwEmZFOGTqEwvJkihT773JKczYiwmYOaTwsfaARrCGlBXVa4wPy+uXCdzUEbZNuWTZCkmW38fY/3 iNOLRZhFFEJzUihUlraVvpNEiYUxj1coxS127EzvrQYMAkUUlIkxAWuECDkT9uP1p4lQZKeIbHRv Rixs/WLzWm3KTmopHRr4YXlK3zZN5Ypm9NnkX+ip0oyMoHt70W/8KjSeuBfdy1h8U8HLYwcQYlcG ZRz8MD9YDEdHR+hL6FhhjFK9nbTEx9PmT6pB64f2149jyY9CroBMO321uOnCVCHe7gijPlWuWTlZ R/VyV0E5Q0N4vvxIn/85Uasqj4oMg5/IHDks4/Di8UsUrZwn2XMjIiJoIVYGZggKCiL7ZRg8PDxI IlNmFuLl/40AU2vrETGKYG0tpR9CABwc/oOu7kci6ydEpJo0Xs0QGelIUnI5uk65gxWLA4mI6xCR hn3TgYiIbCQ9+9I1n4iombTMFrTCuH27iLBQMw9xTU1fktA9YGu7hSTuLTAhPxJb21IkxeuQ+rMU Pn+uLpzL9iLzqJwJaKQ6ZxJ3guCVnM5b6P/3kGTA5zObNyPWBE3Cnvj5yQRa1RODslidIOnX2why DYkQoEV/tD0koLPeFgoE1XwnBF6Jto7Cx6b+MNJ+Cavsu8ihIVaQpg2H94XeDkpY0v9aYq8TYK5/ GS/DrsPdQxdSuWr3kLFAYUQdHU1Z0NSFrJU+gz8u7KeVGuexexMl5J9V8fV7BU7uXY+7PtrIfnQB hu6NoW2YPur3GICKuejHHvQKe+76onb3otA0i0TzascwoHsvGDuXQvd835K6JpGxjkYKypRowVQj DIcWj8T7vfrCow1zlcWALo1h9BfZ9S9W9RUes+yusKf4Jv8tXYWuJYfANHFD+mD7DOz09sfgMkrV 1d8qOvZFMHBQETxePwC9Vu1CrcoTkNR379mzZ9i0aZPwuJs3b4IR94YNG0j9mTF/gH8Ll4xcDwtQ wgiPqZyZZ7aFxVlSOYZj4sQEIuhI4fOgoCLYubM8Tp7UoQVJRqT7gYiTbbm/EqVcri9I4CmLWPyS SPV+Iqmqvv3q0cs2BgkJTHK2Jmm9vHBBhw4JcHOLJIc0D+TOPR05c84T7p88WUKkLaKNgr1A4Iyw xWK241YI9m1lgBVe0gMBtqlir+RFTPODDIiCb4GyxOpIYGhxH3qGL6DVVFMIzmIMe0xyKwGdentp V0eSMnmcO1jHQsI0JXcppvk7ErvYlHhH9c+fkPwReT7gwZUeOLOpFkRi5iiU8TZmTDNobm6OkiVL pgf0/586mSTMPL9TliRCbNobJkJdiuFRtgcF3QmjDbZwoxRWtkpChZ4tug8YBHMDNr/00b7/TLh9 9Ia5Q04YpXKCuOmwVWggTtEQiQmGLz2Gz37BiIpT+l1I9Uygm3LKpr3RqV6ZLkSt51wZi+YNRpOe o1Hs0R4ibfpRJUTj5YMHKN1zLgbVy/GHzVbeHuN1A7OXnULLCeORg7zj4xM0YW5mASY/JS3Fixcn FalSgh8zZgzZJj9h1KhRdIQn5K+0g1eSdgTYcSpG0lpaXoK0yjy0dXXfk3T7mSoxJCLMjffvGwjS c0iIK3LliiWvbkW6BTBhRMzawwrbt929y8wiEbQAnhMIwsLiHCZNukXfsh/hW2qXEf0rhrt7W8HW zUpUlB39P+V/pv4waT/pRiLtyGS1K5OqbMmZjLytWeCapIXhz7z4mWe/qihIZW1g8IRMGLuSYE2j Q+YKHZ33wtgoSZWNw2v6/xf45NmGxs2J1N6kiflIR8WeGsFqYHvggyUYB0srngbqHPlmAPp2E6Fs 8ZZ0r3PiszLWGDGJ+sKFC4JUnWkK+ymq3LT/uFMi6BmZC69Ui0wX5kkdxjT1kSNnIomncoO2nlGq mR91ja3hQq/0LOlC1GzXUqbTPDwpUQOzFuyAf6LXd6tBq9GrcaG/1h8NUxdYit5g6rBxKOhoAD9/ LfTt0wLJf+7JHycnHWY8udLHxMQIL17SFwGl5My2l0x6lhHxnSLV9ifBVqyl5SMsrL6+lckM0Z9U zI0ECZbZnpkTGFugle/Tt40UZ0t4ANMgytiekiR0H586wr9M1f7yZbRgs3Z03Cio2ZnXee7cvYQ+ xcSY08avhaB+ZM5rYWE5hUVdpY1k0rfyOFjWLMwhUHU07isCbHP09Z1y4/aZzB7/CRsypWmBka82 aVlu0tn4y0nAU2pTIiKy05xxEbz3lWNHDmihZfHhQyeaLybJMI+NNRaIXCQitTnd7iuWwH3BRyh0 XkH6zhr5TY/CQPtb42kCuShrajyizaNjogd4xhpDto4p2HEiXjI9AulC1PKoYHzy8IfIIB+Gz5zN Vj4BSHYG7dXLl9A3s4O16Y/oNG24izQt0H3qcuQ/cQpe4Qmo0aoO8lnzqGdpQy+9rlIusvHxmkKU MEbKjNxsbffSonsXenpvyN6rL0jML18OIynWlGzJRQRyYxIpW4RlMpWm4//jKMMWdJXdm5E1s1nL 5Tp4/nxMouTmLpA1K8wT3cFhi9BmJ6fVgnTNPMrfveshqO9jYixI4rFJtG+HCWShLBlPlZr2GcGI 9uvYMJJMXSKWkqbEh+aA55eqmUSscupTmg9YXRLCj0nOgQJ2qo2Nsl4NvHo1OFGqVW2sRaRtKZCI a/JdHDsdoDxu97WwTZ9ybiUWsoHK2VlsKuElyYfhdH0YVGj0Tfffd/aEZ247yCTsGB8vHIH/HwLp QtTet/5DhYr98Yn6JZFpQENKdibyqI0WzppJ0GH6MWwcVf0v9VoPpWs2/kt18Wp+DwHVUSotwd7M JCgTk1swMronqI51dd8J1fr41CbpuQo5hjUXFmCWRINdrwz3mTGLkliZLZo5rzHnwwRB4vf3V9q1 g4KKCf1lfbSxOSh8Zml5CsWKdRH+ZsfEAgJYbHuRcByMbVJYHUy7wAhFLGbOQMwG+v/ZlPwYdSVR qkwD7FpG0Ky9SWOpx8fLBDK2sTmQaLtXbda0aHN2m4j58TePYf4H7Hy7MgANmz8S8rivJJxhZsSa tLB5otTKfCVgpuHQ0PD7PdzY8bDE/N5i8i+QPM4HXLL5po0R5T9C5EoG0+h0WSYz5oTnrcqQCKTL DNQwtIajkRifghWwKFofI1uXh4aOPcpWKQx9+g3r6Kdf8PIMiXKmbJRSqmIkxQKRMA9qJi2bmNwg FeZRISAJI6XoaCs8fjxHOJMaGppXuF4prVLeY+nPoh9kROAoGhZJgkppUKkmZxJgRIQLXrwYIxAK 24iwvjE7vIvLaoG4GZExrQKLqhYUVJyOmDUS1KnMDs9Us4ywlNHVGBGyzUFqEneCIN2zZ/9ZhjA2 bkkd8FQbLZ1kgDMpWUfHXfAhUBXWfiOjB2S62J0o+aok4hBBao2KomQcX5zrGNFr4tmzSSQRO3yx 87J58zXwzFezANu0MExSOgcqiTs1PP58cyOlPNzeDT8gsJz3N5ONnemWhP9lr6CMOKV5mzI8AulC 1JaFmmLHuaPYTUHOIz0fYOHsmRDp58Erj7IwEBugSqvOMP9+SNUMD1pWbqBSFUyRfQTP51gi57dE zIfIwee54OTDyufP1cje3ECQoJkNV7XIqiKBZSb8VKpsZitVOpJRhilSfzPCZhsTP7+KRFZagp2V 4cMInNnnra2VzkuBgSWFzUxEhBORd2OBhBkZK22q8V9Co7J62efMO55J6QzXr3HMv4eokihZXV8L 22gwM4My5Cor7HumEWDk+9UZjpkvmER8l8iaHadMXpj0q7THM4lYuWHx9y9LG4+CgpYgaVHaqJMf aWPP+Z5EnFJ1nZ7zhUnWseaxQjawlIUd6VIFUEnPNvC6OQI/QyBdiJo91LZwTQykF2WnhYnTboT7 P8bkiZPAZKkPhqVQrj9P0PGzwfm337MY2tqJjlDJ8zkrHYLY97rCAm9mdkmQtJhzFfPKZfexRfvZ s4nCQh0dbSFI0yxgicru/G/78v98GiPCr06KDDemQQgIKC3EHmcqYyZNs6NhjLwtLY8TgQcIanNn 53UC4Xl6NiWSz0+4agj3qaRsqTRYCJsaGpoPjx7NIi1GYKIqWqk6Zn4ByQlSgzZSr8ie/pI+Vkqk SvK9L6ipVUTP7mUbCDaOERFJPZwThHF8+HCBICkrSVzpcsLeMxPAV5s7Mw1EC31Nar9m16u0D9+O yp9LxH880tQERsYS+Xck5wzQxD/uI69A7RFIF6JWUICAe4dWYcWhu2Tf8celm48hMymJeQcPw5pc 4vO7/b1gJ2o/AhmiA0pphx15YfZU5gClsjUzKY55X7MFmB2lYgTNnIEYebNr/fwqCI49TMpjpKw6 V5yR7c7/EnKVdMg2OCrVdlSUMsMA8xZ3d28tYG1peVLAz9DwibABYoWRIMOYYe3h0VQgUyb5Ms2E mdlV4cgR2xQoJeL3lI97W6LqWOU1rSnYhzU0AgQiV5EqI1Km8QgPz/1F+mUbhKCgErQJYOOY8jSE 8rx40sLU26ze1Gzr/1Ii/pdjyZ/FEfh/IZAuRO19azNaNulPp04Bk8J1MaxnH8g0DGCUEI/4WJIu fALgZGT1/+ozf24KBOLi9AWnr5w55xJ5tCLJeELi8Sg/Qa3t7Lz+y2IfEFCKvHCHkHq7hqBWjY01 EoiDSda8pAUB5kCWkghFwnEwZhP29g6nc+Td6G8JeZNvE4iZ2bdZsggWpIUVdua8SJFegkMaq4uR MJNamTpc5aDFrmMSMNtAsSNLUVG2XyRi9h27Vnlu+evxHrZRUI5jSjHyex7qXNxMy4jzazgCf4pA uhC1SELnZa1tEEPe3vFeNzFn9jVaTCjwfWwcFBSUpP2UPSiamxP1nw7e37lfLJCyg8NWoTqW8IIl u2AOUMz+rKXlTZJWUTpKNZRU2tbCUSql5MwcmhScoP/KIDDHOmUYVCbZxsQokwG8fj1I8LhmEnfB ggMFk4OqMLX4u3e9hONMyrPHYsExjTm1pVQ1KzcGyc/bMh8DdiQq9aLOR8f+yoDwSjIRAhEBXvjo 5YsYOc1rLSPkzukMbbJ0eL58ghBNa+R1Uv7eEqKCEBQtgYlx6hmjYkJ98cnLD2EUOIcVibYpCuR2 QEyIP2I1jWCglS50KjwrXWq2Lt4WF963FKxiCd+kFSF7kDRF/rBMNCnUqyvMBskclM6RJ+9Doema mn4UCWy84BAVGFicHIQqCIE8mHpV6QDEokRxSSq9xpltflQqaka4SqKmI0RJzwGzRYI2V0yT8fZt 3y/H25iNmI9Peo0Mr1c9EfDH8r49cVnDCbksyIfD2hWDnZ3he3s9xs87Tul89NFi2AS0LWGHw9sX wdO8IXrVK5RqVw8t6IoZlzVQpbCz8H3QZw8YO5ZFlMcx5OmwEn0q2qcbROlC1CKK/KOhyY81pNuo /aWKlSrTWMHbN6nEFRdnhCdPpglxrVkaSeWxGZVXLCfpvwR/mqph6m17+13CeeSkhZG5s/NqGiO3 RLuyKqAHH580AcsvUgME2CmSHfQaSa/fzE4V+A7PxXkwc9Ms5P3S42DMW3UaZQetQbnPCzHi4BXU d86He97m6NAmdZJmtwZHKFCsYS/M6VtFWVPEQ7Qs0wz7/KRY0iV9+S5diFoNZgBvIiHAHMXMzS99 QwJSaYigZmUe3CklOQ7cv0OAOX2JxYyAxYKdOWVRHuViSU2ybojSfzca/En/HoF59MiN9CpGr4a/ 9fjwT+/gH3YXq8ZMgKGmHup17ofidpowMdOE54dneBcUihwORrhz6gJsKzaDc8pEEUmeKpZIIUm6 D9ZlETYpANJrpvFK3w0yJ+rfGn71v0l1JCdbtsXfdIZ57bKjQuysLEs8kTJSlPr3Xj16oPKedndv I3h+p1aYbTvp2Wf16BlvJUfgZwg8pwv2J1407beJ2j84Cua6eVGhRmWYhn/ArmXTIRoyHi0Hdca4 kYuwybAYxnfSxoFrxmhbUY6jR47ApUgV5LH5Nl2XJvmCvL5zDgcOKP1JfF9dho9VHTSs9jgx6ubP +vT733Oi/n3s1PpOlS2URdFSnY9N2iEmrbFMV0lDRap1h9W48T+P4Ja+u3k1ho43PUMhMJFa8yoN LWIR8lg2PVXM/wf0dw96Me1SWrVHTBq3hlOFTlhHL2Upg/t7m2D30Yco1qE85m5mYYATcPK/JbDP WRBH1k/DHU9KtHPwEkZOmwZXi+S+VBJKlRrq701Onq+F2kTGJbBweVUs6d+cHNXSNzkKJ+o0TJvM eQkLkiGm87ktvgnZqOovI4g/C1WZOZHjveIIcAR+BwEWpvXDT25koW1Zwht2Rl9VGDmvphfFZEfq HtnfVqoM8ev1/Aa8EpxQLC87ZUTJdsR60KTTSKoS7XEDt/wM0KygP0ZeisemUyuxuHUHnH3tR0Sd PP57ZJwGitVuj2G9Kn59nMIHYTEUKptyWqRn4USdnuiqQd2qY0HfbyqX1tRgGHkTOQJqgMCqNLZx GF03N5Vrl9FnFdJYh/Ky0NfnMXGvJ8aP7AuDyLfwMLBB9bK5lF/GhePI7uOwKtUTuR28YWQahkP7 D+JDXALqmHzrvBYTFUIBiJJuIKgOOvIVHfoZb188wQtLpQZAqmsMRztLyP7i0pmhiToh7AN2bz0M Hzq25lK6HuoWc/pmkEI9HuHQ4csIjKMMRCJtFK/dDG7ZjH5pMPnFHAGOAEeAI5ARELj/HZJmbetO LxYON+0ld/2RmKqxDOtXrYSYzjq3HjwZJWwT7c9hXgi1LYJGRUhy1rLB8G61sWTPWRRtMxgNc38r uRco1wja+tmSP1xmhJq1auD048NY+VyZ6MYwdzkM6toERn+RXf9iVWkHLy1XKqLeYHSLZnho3QQd SgGTBrTDi5FrMLRe7mS339q6BptvaKBrq5JkbaBQivxYWFrg5ddwBDgCHIEMiIALtek4vVI77vQD l+zv9kSEQjX7YjFLO5GymORE5+Y5v3yat0pHrKDX90q5pv1RLuWXJBw26rcA32Yz/7vQZlyijohE tpo90atXDziSTd8l2gdDdx+lw+i5wQIfKksUXoeLUblrHzSvwwaYl7QiwOLQaGgo6HiPiIKZKHU0 7H1cnFhIuqB6H0sZhHjhCHAEOAL/BgFDekxqrPpvnp5Rn5JhiVpq5opu/V2/4Pb87WvoGRVJHkot xhdvH5/D9WeReHdQBKui1TC4Y1MYaX7fOCAWs/zBFB1NIhFeWbWIxQkUr1sTpqYswhXDS0RxpjUp tncMeXtTwBqNOErcoE3fs3SWWRUl3m+OQMZFgK1fbC3jJfMjkGGJOin0lzcOxfgHRti6vjmSKz9E KFZ1IBrVqIei9gY4tWQwJq01wbw+VShExNcSExNDMZAjhA8iIyMplnIMRXQKpIhOoZl/hL/TQ0ND OVasKEKhQyUYPPg+4ROP2bNLo0QJf3Tq9AzHjuXB5s22mD//siBhfxMJNssixzvOEcgYCEilUtKA sZj7nKwzxoikXysyOFHH4dzKwRh8KAQrVq1HWZevSm8BEk0HtOzb5Qs6BXI7Yu1/5+Hfuwoskszd hw8fYv369cJ1N2/epCAe4ViyZAklNFAGV8+KRSpNIHKOxunTrXD9+lGUK3eIEm/kouxZ3rhx4xhu 326KHDmeEG6rScIWcaLOipOE9zlDI8C0g5aWlihWjEXu4iUzI5CBiToeZ1cMwtxbmti+YzPypHJ8 LsbrFpZtuYHmw/rDjog5PDACOtbZYJBig1miRAmSFEsI4zhy5Eg6O+yB4cOHU4hM1YH6zDzE3+tb AuWWlmPlyg9Yu7YHbGyqoEABI3z86ERZmSqgTBl/zJwZQOaBoUTUXPedFWcI73PGRoBJ1JcvX6as dqo4/Bm7vbx1v49AhiXqsIfb0XPcVpTsORP3D6zHlRg5bPJUQKVCBrhx5y0KuZWFkaE1EkJvY87k BchnrYtA/wS06VgDWj/Ag2XzSvr6fejU/86oKDH69HlDZJyAefOyU0pLBf3oxYKdeuHCh5QHOZ7e SykxR3wysmYOaEzK5hq39J0DzNzANB/Mn0Dl5CeTKSMgsffsOzZ2fDzSdxwyau3fZibMqC3l7fpT BDIsUUssi2He6jWIjIpEVGw8LUoyIfC5mBKTHTt9BnpOJVHCyR5DJizAyf1H4BWRgMqthqGEc9oi 16jI+k8BVOf72QIfFibFwIGv4Ourgf37bYXuhIRI0a9fYTIRMGcVkKQdipYt3clUoHS+MzKKpdSY MQJBqAqrhyWRUBVu0/7zmcEIOjhYJuBsaRlNvhUSCrigjIBkbh5D78Xw9NQSvPXNzGKTjcefP53X kNER4ESd0Ufo77UvwxK1jlVu1G+c/Mw067bc9yny5XaGiUli02VmqNG8499DJIvVZGAgx4kTVjhz xvJLzyMjJQIBFCsWTE53MmzbZi+8VMXVNQRVq/pSzmqJYLtmkneDBl7Q1ZWnShbs+BcjFS6B/9rk YmOzerULjhyxxvLl91C8eBBGjcov4L1o0QMy4xTBvXtGmDz5KWxto8lRMuueYvg1ZPnVHAH1QiDD EvV3YdSxR53qpjBNaYhWL9z/761lBGtkFIezZy0wZIgrqlX7LBzH0teXk/ZCgVev9AUpOl++UFy5 YkaOZ0wFrhAkulWrXMiu7SQQL1O/ss927LCHpma8cCbbzi4K3bq9F1S2TMo2NIxD9uzhX0icnc1m JK/KDsXAUJ3lTgswKpUwa2t4uJQkfbHwbF3deNIGyKgukP09XmhvaGjywPppqT+jXBMRIUHDhl4C /t26FcWuXTcFkg4NlWL06Py4eNEMU6Y8I0dAfwEHXjgCHIHvIxDqHwSZkRG0heOotOaEeeDa/Xcw ss+H/M6myhvlobh7+yl0HF0pg5bSeTnS7yPCNaxgYZhawBVa/z69wHvPQESS5pcVTaucKJnTCp89 PaBnYQfdv7AEqd2vW6pnAAt68fJnCDBSY5I0k9BKlAjEnDmP0LZtCYG8p059QiRdEv37F8LBg9dR tGgwPSxBIGZGqJUr+33xAtfSIqe/s5aCZMcKI/mjR63piNdXT1QTk1jUqeNDdlWlXbtIkSBUqOAv 2MNZYZ8xYlURN3sGI/LvFabq9fHRImnTGc2be8DePgoPHhgKhMbeMzXxxYvmePLEkPrknuiTkLGO sKgCzrC+fK+wTU7evKHYsOE2+vYtTK9Cgh/B8+f6gvZiyZIHqFnTR1CPM/zYhkWF8Z/NDn43RyBz IfD2zHL0H/UY0y4vQyEiarn3Y0yavgBhRrYIf7cVVQaPQ6uitji5dgrWXvFHvNQQQybNQBm7ECxZ uRzFmo1GldSIWh6I2QMb4552NZRyZsFagOdvNiOfiw0evX2GAfN3oaLNnzvjqh1RZ67p8//rDZOE X77UR9my/pgx4wlJu2Ii7CCULh0gSMJz5z7C7t12RJhiIeBJUpsz+16lxmZ20+rVPxMRs8w4EO5t 0sRTkGQZ8TKnM6a+PXvWnHwMKJYc1bd9uz2RaYxAKqxeJhn36vVOkLzZ9WwTwchc9Qz2WVLilsmY c5UI//3niIcPjegI2R1S1WuTlO+M9u3dadNgLGwycuUKQ8eOH37reBl7NutLWovKBMDalpbCNjQf P+qSh73uD4++sXr19OLRuvUnUnHnEUwIrNStS0kEaFN1/DjLCqTc7OTIESZoM1J66TOVeFJ/AlX7 UvssLW3n13AE0guBGzeAw4cByjKJW7dA8RyAiROVLxKGyZ/mF58cF4LTW+Zj6JydCI4rCakG+/0o cHLzbHwyb4yN4xvB+/R8dFi+DpVnNMXRU0GYuGUDHsxsh8O338L282PE2VRF+dxKEv6mKGIQKbFC 476T0asUNZBK/NN9KFK+A9ydq2LUX8rMwYn6F8c9s1zOHMa6dHkvqK7Zgs3Uqew9W/CZ+pg5K/Xp 81aQ0lI6hqVUUzMVbdLYvEzCFYsjv0C1dOkDoQ72LPYc5rQWHa1UfTMJ8fRpC0GyT1oY+atU54xw Gzf2FAhIFXylUKEQ7Nx5g5zeCgnSZuXKvgLR375thAkT8oHZ0efPfyhoAFif2GYgrYW1i20MIiPT /vNgmoV9++xok2AoqPt/Zo9nqvr7943o3DrLvfvjwnBg2CUN57pnjx09z1bw/laVbNkiyFQRIjid scJMAJqaCkGrYGUVnexaVifDK2U72aaIEfvP2v+zNvPvOQK/gwDbzE+fDtrIg46esbUItBGnXA+T QEdqf6PG+GgEazlj0YKp2Lj+FiJYSmvdUDx6Gob8TQsKFVrnLwpDzx14I9eAjVkc7ly7CV9ypM1O 15275oGqHVrhR9prsSS5xCwxM4W2JI5+h+T8/JcUeWlfiX4DI35LxkVApcaOjVVKtey9igjZ34wA fnexVkl9qt6r6qEgSgJxdO2q3BCwwo4X1avnhaAgjUSbtwJbtzrg2TMDgcgZ6Z08aYl165wF4mH3 MVU9k+BZXUwNz+zjjx4ZEpGJiPALCN8vWPBQkETZZ35+mrh0ySzNdnBmB752zVR4LtvEpAUHRnzM js/IUmWr/9HoM8xNTOIwdOgDQXX/vZjqrI/s2gkT8uLtWz2BXL29tYRNzMyZT5AnT6iw6WGS+ebN joKWRNVeplZn748dsyLbtkLAjxVWH/MSZ+PA7PhJN142NlGC0xoj7KSFzQflnEiuMVDNmYw703nL 1AmB4sWBTZtAGravrWaEvXx58s/S3CctSzRr1RH4fBHLo2izLnBqGHwjxLDRSaRfmSbN60AEyF3Q pWddjFiwDOZuLVFD4z2O2xSHw6dL2HYiEOXqNYC9XgrmFcugIQ/AlQMbofdaaed+eecGXJv0gJW/ NyJi2e/lz9maE3WaRzzzXZhSUv7Z+99FIGm9jPiYxK4q7Dum6jYw+CqBjxz5UiAE1Wbi1ClLwQ7L pEp274YNjgLxssIkckZIST2e2VGxIUMKCmp2DY0EgdgYkTFSSqu6l6n7W7b8BEdHFnI2bTYmZieu UcNHaJOKFH+GGWtP0mNtSa9nZMy+nzIlDx4/NqTF6j4OHbKBsXGs0OfZs3PSZw+QM2cYnX2PJru/ X7LHMZJn9z18aPiFjBmmGhrxZNawF+pVjY0Sa+VGyM0tUDAtqEid4V6jxmcKghPwje+AhUW00N+U c+erw2ByBPixvZ/NiMz7/eDBZL99/uP+sd+dDimZ2DyJYtIvFRktF6dPg04/KOdoWsqaNSAzUJIr o+XKDaywz9SEvgbleohP3HRSpeIE2vyK4mFepBnW/9eMrvPD4gU7UKykEWYu2QUtUpmffOSO2VP6 wzIZa9JGnlTp0ZHhdNRVeXQyT92uGJcnEu36zYIibZawn3aJE/VPIeIXpCcCSkleGUAlaWGfqyR9 5jClsosz4mLStGrBZ+e5Z87M9eUMOKtDZV9mP3pWLyOx7t3fk1NcoCB9prUw9f+vkC4jXGYGYBuF tEjhKiL8XnuYDXr+/ByCHZr5EdSq5U2R5FwE2/Ts2Y8Fh7+OHYsJ2oP8+UO+UdVTpFy4uEQIUnfS wnCpWPGrMx/7jn3GtA9Mc8E0EKpELMyWzt5PnJhX2CglXShZH5nznpNTxDcagRw5wonwA775/Hsb k9RMLGkdpz+5js0r1leVE55qnqnmI+szm2u/cirhT9qTme9lOP8swc/3rknLvWnCTiB6A9iYR+GT TwD97YD4IG+EUpQ3B+OvAsTTM0chdykMA/dj+EDJLQ8tKI+m9WbjNcXrsDRMslYpYhEjNUe1Nv3Q s+RXO7b83XHEKCTQ1ErbJv9nbedE/TOE+Pf/FwRURMz+TXn0iEmUquNlN2+a4MIFc8HrmS227AfN JPQ5cx6T6jtOIC8mnatUt+y6tBZm6/0VYk9a79+QHBnpV6rkR+fZgwTS8/TUEfwGWGHhX5cuvS94 tjPzASOSlM9kRMq0AalpBJhNndWRskya9CyZepsRVWCgBsWDN000AyhFBLaBuXHDhBx/rJOZB5QO hMpnss2DyobONjGM9NlxM2aaSOocyNrp7BwhHD1LSohsU8DGPjWNw9/AV7WZYm1hXvSqmPZhYTKa O8pjimwOsL4wrL6n+UjrfMrq182dmzYENm4EnRxRStassLGuVAk099N2f6pXxceRf0w44oSJo4V6 TRqg/6p1OJuvI17sOAqnOo2QL1GtHRPwHAcvvUPloe2R5/UbyI7dxa5Nvoi3NIOVVgo1NtUXERJA R1QZ6X8lagVN3lCf97h7/RY0rJRkrW/ljFx2icfAfrErnKh/ETB++f8fAbb4MzswU38zFTc7612l ii8RVzY6WvYU48blQ+fORQVJk9lmVWpcZcv/3F70rxBgUmbu3GECYTD7N1tjChUKFh4fHKwhRIdj 2gZ23a8GlGGSbWpmgKTOaapFkpE1c+5LWhghs81Djx7vkn3ONg2srcxezswUKps2U9Uzx7np078N YsQqYAFzkjq8KW34sWjUyIs2IslV6z/yyGcbq7SSONussJMCt24Zk+bikfC88ePzCZuG7t3fCe0f MyY/edh7Cf1n/eIlfRG4cwd0tBN09BD0+yZrchjQooXyM3d3YNas33y+cTa0alsH9krtNGwrdMPQ gMXYt3s3TFwaYEavelDp2iKCAuFYvj5KGRLBFmuD/tUDcOh+EPqPGYLsKY9SS/VRt2U3GGU3TtYw mXletGlUBS8v7YVH4pKTvUILTtS/OXz8NjVEgNmamZQ3cWI+QbW7bNl9wYOaSXIFC4YIkmanTsXR u3dhbNx4R5Cy1VF1mVIiZu9VkihT0TKCVjmhpVXV/qvDzepVhZpNeS/7jtnBUxammh816kUy9T8j cDZmT54YJBsLpuE4f94czA9BtXFQEbGvr6bgWKjy/he2WfRMtllh/gOqc/iq5zOPYSbFfyuZi4Rw uMk3GkJtwkZo3TonSvVakI4kPhROIPTu/VbQUjDSvn7dhJzu3qnl/PnVsc4I1+fKBXLkZH4SQO3a zHQF8sEAHbVU/v3bxTgH2nfJkex2t8b94db42xpNspdBm+yqz2Wo0G4Ivb7zZIkBGrb/VtQXGTqj 68h5v93clDfyLeJfg5JX9K8QYFIfIwPmdObgoMwzzhboadOeCDbiwoWDsXixUi2s9Er+Sx4d/6qD avIcBuv3nPOSOgyy7qiO5zGP8uSEmSAEdUkqmTMyZlqEY8es8eaN3hcJWZWcZM8eW8GTPbVStepn YW6o2sXU1ba2UYItXdUO1X3sFAKT5K2tozBoUEHywC8oOB+yjd3w4a5C1L6ZMx8Lse55eNZ/Myn1 9ZUkzYqLy9dnqj77N63IeE/hRJ3xxoS3KA0IMEmSpeJMeu63fHmlgxST3FjwFualrAwhqj7q7jR0 XS0vUUnmqREe+y7psS9G6sw2XL++l+DApirKOkDqcM9vnNSYFM2c7lhEuqRH6hi5Hzhggy1bHJIR NauLbRoaNvQU7O21a/vQaQIn4Zo1a5wF2zjb+NWs+Vk4ccALR+D/iQAn6v8n+vzZv41AUjWwSu2r IgHVdz8KQ/rbD+Y3/nUElEFsvt1MfS9+uZNT5DfnuVmjmFSeUjJnKuyTJ62EJDOqorKjM/I+c8ZC +Jg5kzE1PJtDbHM3ZcoTCrLjRaFq2Rnbv95lXiFH4JcQ4ET9S3DxizkCHIH/NwI/OteeklTZJoCd bWfkrCoq6Z4F2mGhc5ljIivMJs18Hdg9TO3OzpMz728eqe33Rpx5PnOz0/exi2fqoTQWtSfqT9d3 YtbKU+RxT9mTCjfB+K71oKv2vUrj6PHLOAIcgWQIpOaO8D3JnHnNM2c4RtxjxypJWhXc5fJlMyE8 LUt8wqRtZbY3DvavIGBEwblfvXpFIX77/sptWeLap0+fUmjftmnuq1pTWpzvVQztMxHO/deid5FI DBg0DsNhgmU9y6QZAH4hR4AjkDURYCcBWOz5cePyCyFjmU161qxcdHIgGB06fKBXcSG5CwsuY2QU myxWetZE7Nd6bWZmRvH4d9IRKzpjxUsyBHTokDjDJ61FrYlapOWIkev3oUChPGAdmdT0MPpfv4lo IuqvFqm0QsGv4whwBLIKAkw6Zh7e69c7CWlD2fl75lC2aZOjoPouUiQY8+Y9EtThb9/qolSp5ElN sgpOf9pPY2NjCnmb/Izxn9aZFe9Xa6KWGtihcKHEYYt2x7JDV5C3dmOK5Pr9oqGhQbFjZaTO0qUd Mp3P4IUjwBHIsgh06hSInj39BM/v2FhDSp2qjDMfGGhKpwZiKULWw0SVt8GXSFkZBSwphb2U0OFx bgfOKCOSfu1Qa6L+AkusNyYP6Ip7jm1xsnvFVA/j3L59m2IW++HFixfw9/cnT9CTdOZWeQaXF44A RyBrIsDOTDNiVoVgTRmO9XvhWTMCWoykWejKPHnyZITm8DakIwLqT9TBzzFhcE/cNG6FE7N7wuQ7 ORfev39PwRPewNfXl0IDhlD6v5d05jY6HaHlVXMEOAIcgfRDQEy7DE1NlkDl7yR+SL+W8pr/FAG1 JmpFhAdmDOqFdzn748SoJj/Eonnz5sL3sbGxFDPWnUIGDqZABsF/ih+/nyPAEeAI/F8QYCa8U6dO UXCYmP/L8/lD/x0Cak3UAQ8PY+sFHxTWuYNhQ64gVq5AzrIt0L1ZaXwvllAUJTllE5tJ1aGhydP/ /TvY+ZM4AhwBjsCfIcBs1HIKgC3i58b+DEg1uFutidq4SDtcuNEQEeT+H5uYBFzHyFLwAOeFI8AR 4AhwBDgCmQEBteY0qZYeLOgFS+vMMBa8DxwBjgBHgCPAEfgGAbUmaj6eHAGOAEeAI8ARyOwIcKLO 7CPM+8cR4AhwBDgCao0AJ2q1Hj7eeI4AR4AjwBHI7Ahwos7sI8z7xxHgCHAEOAJqjQAnarUePt54 jgBHgCPAEcjsCHCizuwjzPvHEeAIcAQ4AmqNACdqtR4+3niOAEeAI8ARyOwIcKLO7CPM+8cR4Ahw BDgCao0AJ2q1Hj7eeI4AR4AjwBHI7Ahwos7sI8z7xxHgCHAEOAJqjQAnarUePt54jgBHgCPAEcjs CHCizuwjzPvHEeAIcAQ4AmqNACdqtR4+3niOAEeAI8ARyOwIqAVR3929D/4OxVCjpMM34+F17wgW rTmBWC3KQC3WQ7WO/VG7gHlmHzfeP44AR4AjwBHIIghkcKKOwqU9M9C5+Wq03n2WiDrlqChw6+Ax fNIphml9KyFeroCBlWEWGTreTY4AR4AjwBHICghkaKK+f3AJZu99jZI1ykAmEX07HglR8EyIh0N+ Z8TGxsLcKRdMNLPCsPE+cgQ4AhwBjkBWQSBDE3Xuyt2xq44mdo4YiVfRsd+OSbQnXly7gmdvNRH3 RAaxqQ06d+mFPJY63x0/mUwGqVQKbW1txMTEZJVx5v3kCHAEMhkCbC2TSCRISEjIZD3j3UmJQIYm am19I2pvFKKiYyASpSJRy8zQadIWOBQvDDMN4MbKgZi6+CDWT2uFpIK1r68vXrx4IfT93bt38PPz w9WrVxEREcFnBEeAI8ARUEsEGEkHBQUJggcvmRsBNRhhxXdHIEFigiJlTL58b2Vnh8hzzxBCG0yL JLzu7e2N06dPC9d9+PABYWFhuHHjBqKjozP36PLecQQ4ApkWAbFYDD09PU7UmXaEv3ZMDYgaUMTH Q6H4Vr0T63EZQ6ftQOc5y1BYH/D+5A3DvGVhmkL4LliwINiLFTa53d3dMWrUKAQHB2eBIeZd5Ahw BDIjAkySZgIIFzgy4+gm75NaELVMUxMyqVhoeZzvY6w78hB1mraBvXVh1Cp9BsuH94Oxvjb0bbNh SPdqkPxg3NikZo5nISEhCA0NzfwjzHvIEeAIZEoEGFHL5fLUzYKZssdZt1NqQNQ6aDNhMuRaesIo SXUl8PLxgk+gHPYGeqjdfgLyFnuIgCgFbHMVhZXyMl44AhwBjgBHgCOQKRBQA6IWQc/kqx06loTg fDkcYG1NAU6EIoZT3sJwyhTDwTvBEeAIcAQ4AhyB5AioAVEnb7DMPAcaNcgGDfLy5oUjwBHgCHAE OAKZHQG1I2qxVAbO0Zl9WvL+cQQ4AhwBjoAKAbUjaj50HAGOAEeAI8ARyEoIcKLOSqPN+8oR4Ahw BDgCaocAJ2q1GzLeYI4AR4AjwBHISghwos5Ko837yhHgCHAEOAJqhwAnarUbMt5gjgBHgCPAEchK CHCizkqjzfvKEeAIcAQ4AmqHACdqtRsy3mCOAEeAI8ARyEoIcKLOSqPN+8oR4AhwBDgCaocAJ2q1 GzLeYI4AR4AjwBHISghwos5Ko837yhHgCHAEOAJqhwAnarUbMt5gjgBHgCPAEchKCGQqok5QJEAk FmWl8eN95QhwBDgCHIFMjkAmIeoQLO8xFVrNe6BzleyZfMh49zgCHAGOAEcgKyGg9kQd7vMA82aM xNLVTzG8ae+sNHa8rxwBjgBHgCOQBRBQe6J+fvMiImxroUdHJ8TFxGSBIeNd5AhwBDgCHIGshIDa E3XxBgNQHHIs7tUXgfKEn46dtrY2NDU1YWRk9NNr+QUcAY4ARyCjIiCVSqGrq5tRm8fb9RcRUHui VmIRAXk8OZL9wI9sz549ePfuHc6ePYvQ0FDMmzcP0dHRfxHK9KlKQ0MDcXFxSEj4+SYkfVrwa7Wy xYO1NT4+/tdu/D9dLZFIIBaLBYzVoajbfJDJZFAoFGo1H0S0kMjl8gw/Hdi89fLyQufOnTN8W3kD /wyBTELUPwfBzs4ObNF48eIFHjx4QKQuEt5n5MJI7+TJk3B1dYWlpaWw4GXkwvC8evUqDAwMUKBA gQxPfgxfNh/8/PxQoUIFxMbGZmR4wdp7/PhxFCtWDKamphl+PrBNxYULF4S5mytXrgxPfmz+Pnr0 COHh4ShdunSGn7+MqJ89ewaGMy+ZG4FMQtQJiImKQkzc94msVKlSwkgaGxvj1KlTmDp1qlqM7PDh w9G1a1fkzJlTLdq7dOlS2Nvbo0GDBmrRXjYXHj58iGHDhqlFewcPHoxBgwYJGKtDmT17NooUKYKq VauqQ3Oxb98++Pj4oHdv9XBM7devHwoXLqwW2PJG/j4CmYSopXAhCS7SSu+nSOjp6SFbtmw/vS6j XBASEoIo2oSoSwkLCxMkEnUpERERYG1Wl6KO84FhrC5F3eYDM+Opi1lMXeZARmxnJiFqPbQYnjaJ iO3u2UtdSvv27cHU9upSateurVYOLkwacXBwUBd40bFjR0GVrC6lYcOGMDMzU5fmws3NDZGRkWrT Xmaf5o6xajNcv93QTELUv93/DH9jmTJlMnwbkzawYMGCatVeJycnsJe6lHLlyqlLU4V2Fi1aVK3a mz27egVMYr4VvGR+BDhRZ/4x5j3kCHAEOAIcATVGgBO1Gg8ebzpHgCPAEeAIZH4EOFFn/jHmPeQI cAQ4AhwBNUaAE7UaDx5vOkeAI8AR4AhkfgQ4UWf+MeY95AhwBDgCHAE1RiALEbUc53evwOn7XnAq 1ghdG5eAOEMNXBBOb7+FnPWrwFFXOSyvLu3A+hOPYGxfEj17NYCh8GkMTm1bjgtPfJHdrRk61/v3 R8287h3Gyu1XESeKQ566PdG+fA4g1gfrl6/Am8+xKN20H+oWtRFaG+95D9NW7EaU3BQtKVBHQUvJ P0f93rHV2H3lA4wd3dCrRz3oJ+J4cutyXHzqixylm6NT3cSgEVEeWLV8FT76JaBC6/6o4Wrxz9ur euDt45vgru+GJmWVwW6enPkPW849h7lLOfTsWgvKKM+ROLxpGa6/DECeCm3Rrkb+f97el2d3YPOp h0iQUAxfHRu06NINBa014f/4JGZtvQhtwxzoNqgT7LWUTbt3fAN2X34Ny5yV0bNjVSR+/M/a/f7m Iaw/eAMxunbo3LMHcpuyORmBgxuW4ebrQOSr1B5tquVVtifsPRYvWwOfIBmqdRqESrmN/lk76deD O8c2Y9+V18IzpVIxoiKiUb3bWFSjdtw9thZ7rryDdZ4q6NGuCjSFq0KxZ80y3HsfgoLVu6BFRfpt 8qL2CGQZor63YyaWXwIGt6uJQ2sXYaZsOEbXyyBHiSJ9sHRcL0xZHo3DAdXgSNPK78YWTFx7A617 tMGnA2sxYhmwok8D3P5vGtbe0sWg1tWwZ/U8zNMciyHV8/yziRj+5ih6tB2CXAOXoJ7BAwwYSRGc Zi6C8d0VuBrphq7VJFi+cBwSJi9DPWt3TJo4D5JKnVEt5g4mTZ6MWXMmIofOD4Ky/9WeJODef1Mw do8/ho9shce7V2PIvHisGNIQdzZPw7o7+hjUqirhOBcLtCdhUBU7rJ8+AXf1a6JT5VgsmTsWCZMW oqazzl9tVVoqi3xxEC3adEehkccEova+uBZTtzxF5x7N8WznKoxeJ8GiLtVxac1kbH1uhQHNKmH7 yhkI056C3uVd0vKIv3RNKI5t2gf/vE3RvVo2xIs0YGsgRdS7MxgzeztKtO0Bw/u7MGL6Kqyb3AOB Z5Zj5q4P6NW9EW5tXYGxYgnmtq/0l9ry82o+XFiHeRdj0blJE7w4tgJdOk3Gkf3j8Xj9ZGx/aYsB TSpi64rpCNebhR4l9bBs8kS8tm+E1vkCsWDGWEhnzEM5GyUlpn8RwyFfKdQzzg2RRAPvT8zH4MOh aDlaFx5nlmHWXnf07toA17eswHixJma1KYPjiydgv3cu9K1XABtXTEaU7kx0LG6b/k3lT0hXBLIG Ucd7Yu+Bi6jcaycFNDCBTfB1dN+yHz2IqE3TFd40VE6S6MqZo3DolQS5SzghQcHk/Dgc3bMb1qVH oG4ZN8DaD3UHHsGzlgVx+Ngt1Bq4F24ldWHifQkDth9AVyJqpbSd/iVBwwq9FmxCjRpukKAGpj17 hSUrZsNCQ4p+i1qjuBHgdfUYDh+6goJFH+FFbDasa12FpNjiOH2mFfZdeI8Rtf8dkeg4FcPIycVQ vqAF8kVewKZlVxHZtxQOHLuJOkP2w624Dow9L2HYnuNolSsnzj+KwpBtzVCIxNV3F49g997LqDm0 RvoDm/QJCSHYuHY3oo2tYGfGNgnxOLh7H1wqT0d1t0KoaPARDccewetGTjhMkmyjcVPg5iqD9ttz GLvtMDqUH5Aobf+DZkf7wdvQFCXLFKPAMQYwN1cGNzl9cBti7KuiC80TlNfF/hZTcNm9Pj4cPo78 teagkltuFNd4icZT9uJt60rI9k9WItpU7L8KlyoD4exgDfuOQ2FVMgjxYc+w9/gjNJ06A255xZC9 PIvpe06hgYUhrryRYNKMhshJ7Xt07ih2HryFcr3+1Vl2ESwc89CLAE2gNWxmIAYsXIOipnGYt+MQ CtZehopu2VFE8gzN5x6Ge00DHDv/Cq3mLoAbBV+Mf3QKc7fRvC7eNVHa/gfzgT8iXRD4Jz+PdGn5 r1Qa4YPP4WYobqWUjCwsnCAOuQUfSphk+v/OyyE1Rr2e09FF4oFefbchWkjiFA6Pz5qwKJeodjWy hnGCBO/fvkVAjBVKWyp39FaWTkDgC/hToirDf6RR1ncoitqqQF4xn3D0/mtYWbMEHKYwVeqU4WTp iLC3HnhjHg4tU5fERUIDTgbmeOz1ma74V0QtQu5ytZEbsbh4aC2WLjqBJoPXQV/hA+8wc1S0SIJj sCfevfdBnJYzTBIzBzpZOCDw42eiSdCm5N+VR/uW4ZVmFQxqGQ93Icd6OLz8dQlnJQlqmNhBX66g +fAewXE2sDRXTmIbS2fE+XsjmBKt6f4jpUW01xu8vnkWz8O1cE83ApZFaqF/24bw94mHoW1iPHIt Y9ho6uHT29fwCjaEjY2J0F49M3voRl2FR8j/2jsP8Cir7A+/M8mkl0kvpJEAgYTeIZQQQRBY2sJS FwwoHSQCKp0gTcoq4N9H14auCyKwCiKwWBYRpCggJjTphBoIJaRNyuR/JzMiCIgFJyRzzsM85Jn5 5rvnvud+3++2+U4xUT5WcDj3HPuOnCdH8yFXNl3iDA50GzYe3/wfSDcEEeBrXgyrEBhB0eYMTpzI p9g1Er3lLhnhG8Lnqv2a8thZwdvbGlzK8kV8k1WJ5e3VUwoLT3D2igexQfqSYzx8w3DJO8Cx46e4 YQwlwDL6CFH3h9yvLqvWgwi19S7fP6Uk2xDq3DyuqzSYmNbQTDdd9X9BcTZ5pkdol7ZQqymrCsFB kH6c3PwiNCX3CgOZhkI8dRZ5UNODxfa55FzOIlPlHdFY3raz15BvVPUwJX1y/lPax71PqsRu9lOD 2BPZk/c6ujDqn4csviu+OiP5BuXrVQM5qg5md7VoHfLJUWtsVrfifLR2LsS1asSJPV9xJjpCrUgq 0LdwLFTtIetyLlkq7eWPomynKyLPkKPmN6wn1LkntrN0axajFyayf85G0pxNcyWFXFftwUvF24xS o9aDc8lW7UFp3C3tQW0VKFLtwZSbxko9C41XZYZPfZsGHeMwycZbzz3OG2v98dbak+9gcUI1ao2D gdwM5W9+MYG31MOoyVZtQjlcsk78J5t65nj6+aMEdUpm5tCGFBxcRaeJ86nwbCsMKhPVT9eVmeON DHuy7FUaVItbdg6F5F7NwYp4LSXfYP1nB6jbawbqTqGcy+G6SkBk/JGjup8VaU3tIZvrKiug+R5i ug6LyS/MVncTsbJOwDaE2sOTAF0+hSV3MCWDeQZ0Gg/0lhHgQxFEU0fCZCUuuhGg8osYsi1pFwsN GA1O+ET546fNU/Uw37ANufk42HviaW2Rvn6EGeOGsNn5r3z80gh8Dr2Pe34W+SZFUxn3crILcXbz JSjkKq4HVa7wEt0oUhthtHh5e1gft8aN5h36qFdd+iSM4bNG4whzLkRhLbE8xVGnVW2komoThh9U J069qRDnZBfh5qa34manIj58ZS5bUn0JX/Ii2z5NIc37DXbGPU2waViXa8mRXJCPMd8F3yg//DS5 N+uRq+rhpPPEwwqa92MQHb0iadPxpxmSyEBPPvj+MEEebjjnWDplxgLys3XoIwIJcFa51XPM9SjO VwEwuuNtDZE2Fag2Y3n4NaStZeOgrnJNojWrOXzNjgo6w23twVGnJzDCDc+8yyUdNZPlZBXj6aG3 Vh/o5nViSNvJ7nNaBrW2bBR09iDQqZDiXHPOd6OaddEWuuIf5YOfUXUsLbeNvJwCnB316m4iVtYJ 2IZQO4URHWpgb8opulevSkrKbnRVowmx9vzVL7aW4pL8wsXFJqV2oXqsB8v2p0CPaK4d2sslbzdi w2PZH3CDvaln6Fg5nO9UPVxiGmLNfcnGnNPMf2Y4J6NH8cW4ruYahcXga/8uKSdQeYdhxw8HCGne l5joInL+vZVz6pCKxRfYfe0KbWJNC27Wsjw+XDCeI+FDeKaHusnduI6dSwARlauQHZCpOJ6lQ1RY CUen6ASqRFRVa7srSD2tpu+VmzvUVG2l+P7Wcrakd9Bs0CR8T14iO8fAAQ8nrup90bvqqR7txEcp B6B9OOcP7CYz0IuYsFhCfa6y90A6j4T6syd1D5412uFlRY8v7nqPOWsuMXNWUokgnLuQjXedBtTx OsdHH+5V08St0Zw5xBFtEQMrqb0UkVo2KCEnIYgT+3eTq9aKK1uro+lZiSZVitijdpx37q12dV8+ zUVjELH1qpPmlaE4ZhAf7MPulL14xPSkcqQXuvwNHL6kton4FbLj9AmqdbV+utlzqTvIdKxE9VBL 3mlNALFV7Pg6RXFs6c/RVMUx1I9qqj0EeF5k7+Esmvi6sWv/Pvxr9bHefgUrtjtbK8o2hFqNnvsM HcGYWVOZfrgyJ0/pGD2xz0O6bmMSanva9BvHpxOSGTMtldyjZ+g94jnVi/agl8pN/dS8Z5m+L4KT Z/QkTephGsRazX7Y+CrzPzxJr6FHmD0zWU2tFVO7XSJDEjswNXkgqWFOpDk9wnPta+DuGkH32ttJ euJZqhrT8UsYSZe61syk5EituJasf2UyU/fXpij7Ms0GDyG+YhgxKuvQ6PnPMH1vuOLozegpHXHW uzK4exOmTxzMt8Fazvp0YFIna+b6Vbt8qzZUL3M4M79din14a6KVeET2HcPGyXMZP30n146eZ8BT k/Bx8qHfoAEkLXqK6dsrcPJ8KE9P6aRaj/XMr1Ijwh3mMmHcdHzc1Ihe/QSuX9saVHXxosH65xig 3tdfOEHz/mOoqXcmut9TrJ/8DyZM30z60XQGj52kpsmt5K/GnR4jh7Pk3XfUfcCZaxlnaZ6ofkrm F4ZPYl/GLBnF9a1BnLxQkVHT2uCs1v6f6BDLC0+PYLN3PhkRPRnZzhIcK7lsKibt0EU0waozfHNg 4UCXQWP5cupLTLz8ORePXWLwuMm4OwWR+PjfGLd4KOmbfDmZEcuYEW2tPgNgRTQ2U5Q1r+lShepT oz0vzQ1i3/Gr9I1pTGXLxrJSderWwv3qMu/lKLwtu8K0AdWZNW8O278/jUefGOpGB5Yc7V+vK4tn h5FyKpO/12hClJ91f4Ua0nwomzZ2I1vlwVXLZCUWGOxJTOMR/CNkC6euaqnRpBlmt9zp+ewsIr/e Q5bGh7hmNa3aqTCNUCObdGdhSGW+PZKhNraF07SWORe5f71uLJ4VRuqpG/RXHCMtHOv1Hs+C6K2c va6jdlxTvK3ZC/pZY/zLqMW0djDvDNKF1uOFeTPZuf8s3n+vSa0oc4cnpGkvFvtGcvBMNom14wi3 ssNa78okTXiBHV9/T47RjupNW+JfEvsQxs+ax5Zdh7DT9yeujnl63DGiCfPnJ/PNwQv4Pl6bGhHm jWXWMp+qLZiQFMy2lNM4qPbQzNIeQpr1ZbFfJQ6dzWFgnWaEeZk3r5hmOLxqbudithP1mzey6rLC j0xq9X6Wf6pr6dYfhblExrFgnp5vlYj7Jdaherh5HiXykYEsCq7GkfMGnqzfQv1Uzlq9IGtF0DbL sRmhNoXXJ6IOCREPaaDtXQkNt2w3trjo6FuJ+IQ70+75RdUjwaw3Vjc3Nfqoq153s6jaLbjDLTtP GjS33u9k7+aXR2gtEiwbkG/93D+q/l042hFdtyVqBr/UzTvo9sbqEhBNK/X6uQVVaUiQ9Wdkf3LD wZfG8Ql38nINpkUr84NvbjW3oBhaqVdpmaMS5IS7XFfB0Y0IvgOvA7ENWhJbWs6qcj0DQ+7680v3 4FhaqdfPLbRaE0Kt92iFUiRjO0XblFDbTlilpkJACAgBIVBeCIhQl5dISj2EgBAQAkKgXBIQoS6X YZVKCQEhIASEQHkhIEJdXiIp9RACQkAICIFySUCEulyGVSolBISAEBAC5YWACHV5iaTUQwgIASEg BMolARHqchlWqZQQEAJCQAiUFwIi1OUlklIPISAEhIAQKJcERKjLZVilUkJACAgBIVBeCIhQl5dI Sj2EgBAQAkKgXBIQoS6XYbWxShWcZNHoaXxx+iKZKt+1OWGohgrV+/LMYD9enLSIU7kOPDJ0FpO7 1+PYZ0uZ/urHpF/NwGDOFKjMg74TF/Dko3c+izNl3UvMWJrOlNeTqWl5BvSdhK/xztRkUh1bMnNS l9+d8OX09pUk/2MFZ6/m0WvqyzzeIuKPBTPnB6YNGcfuG/ZUa9hPJRzpJtmU/hhR+bYQsDoBEWqr I5cCHziBoitsfPtdNvvWoH3jKqZU0iVCbXfhf/R8dBk5Ie1o4HGOKYl9CKv8JbHHv+G91f+hTuu/ ojIZWswNF8e7Xw4Zh7ewavUhBi6a+gtCncuOtavY5ObJtD8g1BlHd/LuqtVEt+yNs8MDSCytscdd 78i3K1fx7bloJohQP/DmJycUAn82ARHqP5uwnN8KBOywU8mO2gyfz+qJbW+Wl//dP6nTOY3XPt7A Y0EHaaSJYc3nO6no4YqvXQWWbFxF3D208GrqGoYlzWR/ejCNa95A6+SPTmvORHQt9T8MTXqeg+nQ avgc5g1pp7KCaXHx8MTT1Vn9pazgBh8sHMbsZSkqB3YEAycPI+uDxaQ1eYqXhykf89JIfnIAeW3n Mqdfw5s+a7R26FVm50lvL6NnRfjkpWd4Z8d1At0us/X7DBKfnUbguY+Y9c4uWvSZwsKk9uhMPZOi bFbNHsvc1dsx6rzoNHYuk3o2Ruccybgl/+LMoe94P0tr6cRYISRShBAQAg+MgAj1A0MpJypNAk4u atS4dgkTsr68KUYxrfuw7+Rg7JWQndjwAUfxpmfDmrgf30ah8RoLRkzkE0uWRY1XBIlPPEklLw2F mQcY1XMAH+TGMLRdBb5Z9ybFxibYOzpQfG03/bs8yaXYzsTHw/qJo/H3/y8Tu/rcHMmbsjweXL2A qfP30HJAWzJ2rmXs2FcZXPcyby78F5OVULsdWMPC9/Yy+fGAn2EzqW4xWdcK1P86zu3fysoV22nV YyBhml2M7p5As25PUNUtnSXTp9CmfUv+UtWVE1+8StLUFdQb0h+P458zd/ZMHotfQ6NAU0/kKnkF RWg1NxMal2aopGwhIAR+IwER6t8ITA5/CAko/bHX6bh4cCfvX9x/08HHwtvRT2VfPLvlNTp0nEWV xJcY3qwiBw7kU1Scx7Z1y/nOnHYYbWh9HuttEmq4krqJTw448/znq5mUEMTmSpd5dGwadkrzrn3/ PzYdu64kfxeGtGJOXznC8tUfKaEeg65kdF6MSWJDGnVmxsJYTqeuZXPadQqv5FJrai+iPpvNRwdz qPT+Srzj/8bfW4b/AlC12m6auvZ/lDc/eBPNiiQ29lrJM6+8Tttjc1gR9zKnL10DJdQ6B1P3IJOD e/cQUbk5cxM7EO7xAKbOH8Jwi0tCwNYIiFDbWsTLY32VnmVnZhGf9C4bkrveVsPT29+iW9+nqdB/ CeveGlKyySsrOws7rT/vfX+CRy0j6lu/VJiXh4EiXHTmy8PLxwc70kzL3lw5fwaDVk/LTr1oHOZC To88Amo0VUdlU2Q0Kb6dGgfDV2uWMGrW5/R/ejzt66eyeJc7jeLbUbfyq6xd8Dz2+6/SvGsvgu5z BRqLNegc3VX5alycU4CTNgS9C1xXf6Mm3O3tzKPkoPrdWLy0gI9XLmPF2n+zdeOXOAXVZGj83XOH l8dmIHUSAuWVgAh1eY2sTdVLKbX6d/q7zaz7xOHm1Hdx5inmjBnBbmMr3ugazpfr1+Ef2xCNzpF8 YyafrfyEgpCfQIVUa0itSD+8Y+Ko5z6BBS/MpdK1JvzrxffIozpFaod4aP3WVHNehMEtnEbVNTw3 8XU61+ynTlJEQX6BmlLXqjXqIj7dsJ5013okxNVly9dzMBoC0QbE8HRiAg0Gz8cY1Y7Ng1reN0pF hQUYDAYK1ZHGQjUTYHTA0VmVpt5XC+FqZsB8igOb3mLmvP/SZeRI5jTfwaznlnLs4vX7nl8OEAJC 4OEnIEL98MdIPLwfATU9HBgeyuZPX6PzupdvOdo0GnXD02E3I3v8hfxCI4+/so5h/hXx87Rj0chO LDSNgktMy8AF63k9qQ1OgU1Z8lYy3YfOpMvGD4lvFYN3sB+agkIcIjvwxuLh9B6TSNwsaNBvKp3i TKPWDFy8vNG72iuZtmPgiHF8PGwGndoMoEvPplTTXOR4BnTs34+owa+hbdaOpr7mzWm3m0l5Nbh6 mufknd298PX1LBlR2zu74+Oj/lY+ax1c8fT0xtnefI7o+N50q/Uxs5KGqI11jtRLnMGodlUtp9bj pNOqzoJF1e/HUz4XAkLgoSIgQv1QhUOc+V0EHKry4lffMVfNPf9cijQlG6iKKbZ84OTmgZMmnj2P JGL88U1LoU6unpa/7KjdfSp7Ww/HUOiEXm/P9UwDHnqTXGpoOvD/SO2SjEEJpoevr5qANpkXE5dv oEDjWLLrO7rTeHa1SCSvyBlfH1eyMjK4fGEHr6vd3Jc1fiT1aFcivnfItPIpjyzWv/0m1QZ1o/fs ZXQu0GLyrLjHDPY8VoSH0nBt89EcOzZECbrZZwevSCYt28LQy5mqthrcfX3Mv+UuyOCLNcv55mg6 2sCSiQcxISAEyhgBEeoyFjBx9y4E1IjaTY1m3X4DHG/T/PF9zF3vi7vlGB9v02atn8zd+6fPzO9q lWjqbzvGTX3/R5/c1Dr34U/mMm72cmoNmMbwRyvdtXRnryCiQkPYsHgK1eo1pU6Xatws2dEV7xL1 VaZzUaNrtVh9mzngozoOt5khjTdnvsCRPHfqVgm8a+fgfhzkcyEgBEqXgAh16fKX0m2IQJ2+s7n4 t+dxcHIy/9b6Lhb92Ch2HhleMgNgrzOP1f+QudVk6c6jajpedSUsG93+0Pnky0JACFidgAi11ZFL gbZKQKueyuJkejLLL5hGa4/jPZ6Q9vu4adU6vWPJTnQxISAEyiYBEeqyGTfxWggIASEgBGyEgAi1 jQRaqikEhIAQEAJlk4AIddmMm3gtBISAEBACNkJAhNpGAi3VFAJCQAgIgbJJQIS6bMZNvBYCQkAI CAEbISBCbSOBlmoKASEgBIRA2SQgQl024yZeCwEhIASEgI0QEKG2kUBLNYWAEBACQqBsEhChLptx E6+FgBAQAkLARgiIUNtIoKWaQkAICAEhUDYJiFCXzbiJ10JACAgBIWAjBESobSTQUk0hIASEgBAo mwREqMtm3MRrISAEhIAQsBEC9xJqnZvbb8nuayO0pJpCQAgIASEgBB4wAUdHR80vnfJeQn1q27Zt RzMzM++e3f4BOymnEwJCQAgIASFgqwT27dvn/JuFOjk5+Ydp06YlqC9WtFVwUm8hIASEgBAQAlYi kK/KybtXWfdco1Zinaa+ZHqJCQEhIASEgBAQAqVEQDaTlRJ4KVYICAEhIASEwK8hIEL9ayjJMUJA CAgBISAESomACHUpgZdihYAQEAJCQAj8GgIi1L+GkhwjBISAEBACQqCUCPw/c5qhvlCaP1cAAAAA SUVORK5CYII= ------=_NextPart_000_0062_01CAF128.6E7C82C0 Content-Type: image/png; name="image004.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAeQAAAElCAYAAAA1GpHoAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAH9ZSURBVHhe 7V0FfFPJE/6oQnF3d3f3w939jxx+cHC4HO7u7u5W7HB3d3d3CgVa2iL/mU1fSEtLk5CmaTtzvxxN 8t7u7Leb9+3Ozs44DBo0CCKCgCAgCAgCgoAgELIIOIRs9VK7ICAICAKCgCAgCDACQsgyDgQBQUAQ EAQEARtAQAjZBjpBVBAEBAFBQBAQBISQZQwIAoKAICAICAI2gIAQsg10gqggCAgCgoAgIAgESsjf vn1rGDt27CIeHh6CkiAgCAgCgoAgIAj8BgL29vb4/Pmze7Ro0fq/e/fOO6CiAiXkiBEjVmzXrl2j 36hfbhUEBAFBQBAQBAQBQiBChAhYuXKl999//z20U6dOphEysflHZnQRQUAQEAQEAUFAEPh9BGih +9bNze17YCX9cg+ZzNaws7P7fS2kBEFAEBAEBAFBIJwj8P17oFyskBGnrnA+QKT5goAgIAgIAraB gBCybfSDaCEICAKCgCAQzhEQQg7nA0CaLwgIAoKAIGAbCAgh20Y/iBaCgCAgCAgC4RwBIeRwPgCk +YKAICAICAK2gYAQsm30g2ghCAgCgoAgEM4REEIO5wNAmi8ICAKCgCBgGwgIIdtGP4gWVkDAw+MT 3r17ryLmxI0bFw4OMvytALtFq/j69StevnwJPs9JIQgRJUoUi5YvhQkCIYmAPJFCEn2pG8uXLsX7 Dx8CRCJ58hSoWLGCxVBauXw5OvzTCRHsHHH69AlkSJ/eYmWHtoJevnyBdevWK7VLly6DtGnThIom PHn0CLlyZoen9xdMmDgZtWpWw+rVa5TuFSpURIoUyUNFO0RJQSAgBISQZVyEGALDhw5Fn379Aq0/ a7YcQRLyvbt34e3jgxgxYiJ+/Hi/bIu3tze0ZClfv34LsXZbu2K2DDx69FhVmzx5clD4PgwZNBBT p89Un02fMTvUEPLXb1/x/r07vlDAo89e3hg5bCjGTpik2rF23QbEixeX2vpIvU+VOjUcxQpi7eEm 9f0GAkLIvwGe3Pp7CGTImBG9e/fmDCiYPWsmPnl4UoER0KJlC8SPFw+ZMmf5ZQU+Pt4oV6Y0bt29 hxat/sLc2dN/eb0+NnsEB2W2Di+yd88eVKlaTTX3wMHDKFa0MDp36YZYcXQTmMKFC4QqKBwdHfCF Vsgc1vfvjp3gEjW60r9A/nxw3bAejf7XmN7Z4er1a8iYPl2oapsoG74REEIO3/0foq2vWasW+MWy avlSPSH369cfyZMl1RHIgQMY0L8vXrx8DS8vL0SNGhU1a9bCgAH9MWHsWNx98EBdt2bVchw7cgAd 6AGdI2tGtGzVBu/ev4dL5MhwiRQJw0aMQuxYsQJtLwV8x7GjR1VdnrTy4pCzWbJkw5Qpk/CK9iwn jB+HE6dO4+PHj4hMZfJkYfGiRbh65SKat2iFCPaOiPDVC95fv8OBkrLUql0P/fr2xsjhQ7Fy9Vok SJQE2//bgufPnqJq5Urquh69+iBn9syYMnky9uzdh0+fPoFSnmLkqDGoUL4sTp86Re2gsu0cYI+v ZKb1Qdas2ZElY1qsWLVa7YfzPuo/nbqgetVK6Na1K46dOAm2BMSicjKT/rNmTMOYUSP17W7SuBHi xk+IgdTOM6dOwsvnC0qRyZrbdeTwYfSnz9+7f4APfc77s382b4lO/3TAO7e3qFqlMtw/esKRwtvz 6tTO0VHpM2fOLESiVbcmXP/I4cOx3tUVX74wcTogopMDvOnvXHnyoUSR/Bg/cQocnSJh/77dpOMM LKatC5ZmzZqjffu2GDRgANaQSZ31ikX9FiNWbKxetZIsIdHV/jGLI9UfAd9xlPqNJXeu3Birb+s3 VK5UkdoQDU523+Hz7TsaNmqMHt27YsWypRg1Zqzqs00bNyBpkiQh+juQygUBDQEhZBkLIY7A69ev wYlMNGFyZELeuWM7ypXX7SHHiRsfuXNmw46du3Dx4kXEI1JxI5LQTM/u7u9x9ep7PHnyBJvXr8KV q1fxb5++2LFtC86cPY9G9DDOnzt7oG11Xb8OzVu28vP9VSqjcOGCmDVtKq7evKW+q1q1KjZv2oQr V64QUdqjfu0auHDhwk/l8meJEiXE/Xv31ff3Hj4hXb/iA+2XnyJ9WG7QCm7CqKE4ff4i0qbLgOZ/ /okhZMavV68etlPbnYj4/Jd9lepdRfcmSJgE//buhX7UxjGjx+KrtweWrViJosVKoEC+3Bgzdhwu Ur3Pnz3DzRs39Po9oAnM0+cvCafH2Lptu/q8AxH64YMHUKFSZfU+Ge3dp6a92H00GercqaOaBDWs XwcnT5yA1xe/pn6uw4MsG0uXLISLi4tvu65jwKBBAWLt5OyCtCmS6Nv15ctX3Lt3T//+2fPnePf2 LU2gRiJJ0uRo27Ythg8dgs80GSlbriJmTpuESDTB+uzzURHyu3du2L17t6qrZs3aeP3mtb7eu3fu 0N+cHEenM1tg/ve/Bnj54oW+Pk9llRERBGwDASFk2+gH0cIAAc20PGzIEP2nU6dORR0iv8IF8+P4 yTNYsmQp/tvqipW0Urz/8BHq1GtIK8HhahXs4NhTrfCYSL75eClCfu/2Cjt9H9z+weaV5tgxo/Uf b9n6H7JlyYyvNEmYOH48btI+NUujRk2wdOki9O3dE8NGjsb27TtQslgRg/u24fbNa+jUuYv6bP36 9ahTqwYWka6f3N9hIjkh3b97U30Xnwh1/55duHLtKq0UnTGY2lq/bm1a4Y3AB7r26LHjqFK+jL7s MmUrYM7sGahXp7ZaqceOEwdFihaltj9QRB89ejQ0odUlt/nTp4+YTHp70arwwoWL6N61C3r/21eV tWLFKhQqVBBPHj8gsz2UJeD506dYsXi+vi5e+Rema7JlyYRrN29j0+YtaNq4oVoxe71zR3da2deq VhmFChZUVLd9+zZ4enrqCXnI4B9kPHXqdCRLmghVq1VX5TOZOjk5qb+dI0ZRWwfOzs76ur9+/UIr +AS0T6xb/bOsXLYYV2/cxuWL53Dp0mW1B05LdbVSNsxGlzlLFvQbMAit27Slu+ywm0z1adOkQrs2 rbGV+ur2rZs4cuQo5s+fp8rNmi0X1RFVX7f8IQiENAJCyCHdA1L/Twho27vPaHXHkit3XhQtUpge vvaIEll3zCVipIjKkcuJVkks/Dc7LDE5jR41CvdpJeju7k4m5Svq+wi0b+wS0RGfiDj8yzcigefP X6iP/yhdHsWorqi+ZODt9ZnMrl8RLUYsMh+3UNewOZiFTdeGR6dSpUqFTx/e6YtnsmhGq95ePbrh xeu3uE2r5acP7uvalCuXWrEfJDOxS+RIuHLpIlrv3omo1I6IVF/MmLHIavBVX1a3bl1V+7p17472 7drT9efJ2zgn6jdoQGbYHuA2zJ4zR63AeU/+mwLxO+ESA4kS/zDJ8uo3GVkfXr96ociYxYec4rT2 Fy9RCtmyZaVJjaMiT62dTH6aqZid57it2i48E3UEgzStvCpnSZ0mPaqQmfvRo4c/Ya594H8vn1e9 fKyJTdbcVz6ExYtXb9TlESI4KvIOLIWdMxF1PPI90CQ5rfKTJUuGPn37YRdtCXjTKnvypCm4eVNn MWhM5vsECRIEqpt8IQhYGwEhZGsjLvUZjYBmxr5FD9DHjx8pE7BG1rw3yaI9nLWV0qKFC8hU3Ud9 x6ulmLTnePHSJaKmX4tW17kzZ/CKTOgaIWt3eXz8gGPHjqFE8WLQVvBMZIamdiZC3j/VRPuuePHi WE0ewEtIt29fdN9zOe/evFR/f/v+DSmJ4P76qy2toifRCtJR1XGIzMj6+j081J+169RF9eo1MHLE cKxeswYrV6zAli3byLz9DW/J+zh5qrQYPmQQ9uzcBp9PnxU+PgY62dv/nN+cr9F0vXD+HN68eUMT gpiMrqqT22ko/J7bGphoZT198gh3yboQI4ZupRuQRIkaRb9i5u8dHBzRs3s3LFy8BE7OkTB37lxc Pn8Wb966GdWHhrpq/ZQ3f35UrVgea1034fDhg0qNqNGiIytZAEQEAVtCQAjZlnojHOvyg9i+6feF 2//9N7p0606rPnfaZ3yAx2SePe27/8pe2CyfyOmHZcumDThK+4O8Z8sSwd4JfzZrhlHDButQNSAd EAEaCpMve3aPo+MzbmTavv/gEfbs2olVa9bSyrwo4seJpVa4N2gf+erVK5g1a5a6PSatPiPRSt1Q DFdvGjk0+7OFIuRPn36ct27UqCE8ybQ8beoUuJMz12YyC1coX45Mte/oSNJg2s+thKSJE/4o2ncm 0qVTJyRPmZq8i/8h4nyNS5ev4KPBqrxunTrIkSMrPhIZa/L5s5f+7xEjRtAqcYKfiUOixInRpm0b dO3Ri/Zk3+Le/Qc0GdiPm7d1pvoEvsfJtD7S2qihaDgp4es7/PMPjhyn9nl64NDhI7h+5cceewS7 CPD0JXMvsj5UqVwF169e1uvHZT0jEzpL3vwFlXNbv397+vbhNzXB8K+HdjOvttnxTyffMJS2AQb0 74ekSZPREai0yrytnySVKIny5cv76Tt5IwiENAJCyCHdA1K/esgarizZ7MxSt359zJ47D9evX0f9 +nX1SOUrUJC8nyeq9+UrVsT8hYuUk1LhwoVQhJyaUpFJ9i7tK6dKaRgk4ivVoacQP2ZPNpM2J2/i lavW4AmRQak/SqiynSO6YAg91F88f4IZs+Zg0YJ56sUSl5zMli5dDI+P7/2QiSE5aav4pGRqTkGm 0/sPdabb3PkK0PlYeyROm5ZMzg1VG103rFMvTdLSkbA0qVIYlK1brfKqecKkSehEzlaa1KhZBw4R viqvZN5H55cmvBebg0zb6Sjwx81bt7HRdT127NqFyRPG+Rl5deo3wKQp0/CQzvCWpaNkmrAj1bBh Q5S3s9ZH3D/KhO17EX9uOBGpSJOJAnlz4/ipM+jfT2etsCcy5D15T1rpFy5aDHFor/81OW9t3brF jx5cdvUaNbFj9x4cObhXRVT7IV8VoWp68N+GePPkLHOWrEhAk7XnZPaeP28ulpOj20PaJuhHJvCF ZKF4+eatKu7ff3v7qVfeCAK2gIAQsi30QjjXgc2ju/fuVwE++Bxyet+zo4lp73Pv3r24f/++2htW D3Yy5WYksuK9UZaZs+egZes26m++Jh1F3+IH83Py1mVCtLenI0P2dDiG2MOOVlBMCmz3TpUyhR/U M5FD0KFDh/CcPHB1R3XsED9BQqRJnUrt9zZu+qd6+POL941jx4mrSI49wrVjNxlI7+RJE+vf8742 SxYqez8R6dOnur1V1lE7gjVt5kw0a95CEZrWRi4/NQW1iEp7s1rZ6TNkUPcuoWhjb4hUWA/WkV8F CujOEXc+ftxXx+/K7M3XMF758uXD3n378JAmKSzk66XalZ32ir/Sm9Rp0iAeEd/BgwfxlPZ/2bEq QgRd2dmyZae9chdl9t5/6LDaT09GE4y4tI/Ox8SYlB0dnRDdd8+dy48aNRr+27GTJlI3lA7HyEGt Z8/uqu4PdKSqZMk/cOToEWWGZmFv9Qi0ov1GuiRJmlQdQ8pJmHNfMSZcPq94v9NVqcm0n5MmGDxW UqdOQ45mLj8wIlz5iNQh2pfnbQdt0hCDHN68vb30Ww3ssR87lq5vRAQBW0JACNmWeiOc6sIElDtP ngBbnzBhQvArMOHVbUHy9vUjRC4pU6Y0GU3ex+WXf2FHop/q8L2IJxOG3zF5xfGzqtNdyGFA+eVf HGjCEFjZfK3/7zJkyBhou35VDk9u+GUo8ePH9/M+eQrSkV4BiSN5RufNm8/PVwX8427wLTulafp4 0ASJyZaFz1rznnm69LoJRmCS33eSEdD3ho5bAWGUhiwP/DKUVxQq9O1b3ZGo/zVuQpMpv9//Uhn5 UhCwEgJCyFYCWqoRBMIrAlHoKFaRIrrjYSlS/DzhsQYu27dvR4HCRZV/QqaM4TeGuTWwljrMR0AI 2Xzs5E5BQBAwAoGChQqp7YCQlOYtWlJEtZYhqYLULQgEiYAQcpAQyQWCgCAgCAgCgkDwIyCEHPwY Sw2CgCAgCAgCgkCQCAghBwmRXCAICAKCgCAgCAQ/AkLIwY+x1CAICAKCgCAgCASJgBBykBDJBYKA ICAICAKCQPAjIIQc/BhLDYKAICAICAKCQJAICCEHCZFcYAkEOITjuLFjKMLSFxVDuESJEpYo1mJl nDt7BqtWr6HyIqBjxw6UyCKRxcoOCwVpoTH9Z2cKjW0zDPPJ7flOEcFGjRqJd5ScI3+BQqhRvWpo bJboHAYQEEIOA50YGprQr09vTJk2g9ILxkKHDh1sTuWzp0/RQ3mU0qtmrVpCyL49xKErJ44fh8lT p6lPON53wQJ+I3bZXGcGotALCqd6iMKD9u7dCz4UIMTJmWOVD0Qlir3tTBHfuP/tKNToFUrYkSGD BA8JLf0alvQUQg5LvWmjbTlDKQ3Xb3BV2mXOlJlCOCa2OU0j+ub+ZcU4HnJ4lVMnT2AOJbugyN+Y NHkiIlGO4Xfv3sHDN/3jd4MczZbA6BGl1RwyeIgqqnfvPhTy1DAhiGk1+Ph4o0e3bpRH+TPq1GuA MqVK+ilg/bo1aPd3R4rTzbHNdaE869erh3oN/ocm/6uvYpRzHPOJkyZj5gzdBEREELAmAkLI1kQ7 nNZ1/dpVyqKkS6wwcEB/PQr8Oecq9vb+gogRnVGhQkWVyGDf3j0q8QA/IL9RogMOgxyFEhaUL1dW f+9+SjrxjBJB8IM1OiVxqFSxgv67b0Qa69dvUKn4uAyOm5wzR3Y/6O+nOl77JjeIGSu2SkKhhJIq bHR1pbjTydTbYpTLmBMvBCQ3rl9T6Q81qVixElxcIuHwoYOUpOKlyiPMsbZTp0mr6r9HuYHPnD1L qzAH2H3/ii++8Z1L/vGHSjZx5PAhPHv+AqxPqT9K4g0lSNi3f78qvjCFnkyYIAGOHztK6SEfqqQL LpGjkHm1mvr+0YMHOHHqlCo7ApWtkkZw8gXC8xzlOPahrQKOyV2+fAVKyBAZBw/sV33C+DlRnOoM NFHKkikjZkybhgWUi5glQ8YMKpFH67ZtkSCRbhKl4fKViGsD4WSY9KNcuXKUWCIq3Gl7YhdllPoe wR4OlH5ZZYdS5WVClsw/chBz3cuXLsGcOXNU2VGjxVCr7zJly6pkFb/qY8569eTJUxob36nO6KhS pRJ279yJiZOnqLKePn+J925vVGKQVL7xyTm+dZMmTTF69CjcuXVTZZ1iWbd2LWZMn4Ka1SpTmkxX 0n1PgP0tHwoCwY2AEHJwIyzlw5kyD2kSO7Zu9XnyxHHUqFGDsgs9JzKOqBLely1XATu2/4dOHf/G xSvXf0JuxszZaNq4EVo0b4ZVZDrlZIpajtthw0fh3949cIAIbMDAgThw4IAiGk7VxwS3hnIbc1pF Jos2rVtiNb335UNVT0bKpkTJjdRn3bp11dfNOXl5ZZXE36q+L6XvW7iI0j76TjT4hgIFC1Pqx8RY t4EmA96cuUonXP/27Ttw9cJZ/Nmq9U/tKlK0BLZs2YihgwZi++69SJ8xK+UIvoi7d++gDuU3Zlm2 fCVOHD2EufPmwYNWgI400fAhUuzUpRtGDh9K7d6Hxs3+9FM2p4iMHNER9x891mNct15D1KhSAQ3+ 11hdq5XDma3Gjx2Lhb5kzN917dKZ/m+PqZTq8m/fbQYmsYdE/r1798YBMv8aSvkKlbBm9Uo8e/YU tX31Nvw+XvwENFFaj8KFdMlAeO92zMgR+kvGjxuj/t7guhGbKBXlokWLf+rjzp06YJPrBkWs3tT+ CFwOvcZTLusDu7bpy9q6eSP4NXzEKPTu1UN9XqZsefVieXD/nv5atthEjx4dkaNEVZ/ZU2pMTjcZ hbJtiQgC1kRACNmaaIfTuhwdfhCyZips2by5IuPadRti1YrF6PtvX31+3ahRoimkkiZLqVY+i+bO wicvH/z1V3vwXu8KImOWFSvXIFXyxMhfsBD6UBL7ArS6Wr54gY6MnSPj1ctnGNjvX0yYPBXNW7bC g7u3iFzXYuXqter+wkWKIVf2rPhMpM2r3Rs3+On+DY3+1wT3796mFIFHcerEMfTr1x8L5uvyILOc P38e06dPhxs5ASVJmkKtrHgFyivG48eOqGuKFS+Jgf37omOH9rh89Trate+A5k3q68to3KQZbl2/ iuMnT9KKer8ijrjxdNmXPn50x4ULF3H0yGH99f9t2Yx1q1fg85dvGD12POrWrI4UtPKbOH4sWRYq wDADElsM6lF+4xVLFuHVq0+oU78RVixdhL59+ihLQzQinw4dO6Jx46b44u2JQoWLUM7nZ+jRqzdK FC+KfQc47rQd6tarQ6vstJTqMrqvHhEo3eQ7LJk/W0/GEydORtxY0dGqdWts37YV4+n9X61bEI3T yphepUqXRUxKf7iWcH/54jnatvkLF2liEoFmP2w6rlmnLpnI56vyy5OFJHWq1DhOqRkXEBkH1McJ E8RH984dFBlPmTYTtWtUxUja++UUi5WqVqUJzR41GcqdJy9y58qJQoV0qSn9S99//9V/1L17d5Wa 09PTS31259Z1TJ06Hb18iTzAAuRDQSAYEBBCDgZQpcgfCPBKY9iwoT9BEidOHPXZ7l3bUaduA0ye NEG/t8wZeVhy5M6NaVOnIHWKZOjanVY5ZIqdM3eOWhUlT5kaUVwi4ijl2tXk4sXLytzMUqZMaVy+ fAnXb9xS71+QeZtlwQLdwz9atOjKfF66dCn13nX9WhykfL8sM2ZMxxJKZs+EzPL5s+5BrcnGDesV GdtRHt+mTRpj6NDB6qvXr19gzboNaqXVpXMnsCm6HJlfmZC9vD6rXMI6scdcaseUiRMUIbN8/OBO bexOK/fVePLoAXaS2XTzet3Eo3LVGnj7+qUi4zjxEiBl8qQ4ZEDWHz9+QnQXzhmsk7nz5qM2EfZ9 Ipade/aSKXc7EXRDTGKMfb3HeRLz8eMHbNm8RX9f0qTJ0LBRYx0hk+l+Mpl/48eLC54MKKHPbtKs hVe5LBkzZ0Pbtm3IFO6EHj26weP5K3h88lD9o0kX2tNNlSyJImQWNuN/pwv4GiblVpTLWiPkf/v0 RdHCBVHUdwWdIoA+ZgtGHMpF/eb9B0ygFfXdO7cxaNBgWuFGA3vy9+rZUxEy7yH37MYr/J9l9swZ OEq5o1nKV6yMunVr+bmIczizxUZEELA2AkLI1kY8nNXHe7hp0qTBqbPnVcu1Pce15OQ1ccIEjKH9 PDYJ86sXOfWMIPOrnb3ukf6N9h5ZMmXy3XfkRPb0sGQTJT/MeW+UH5x9+/ZV5sWsWTPpyZPNz9u2 bUNOIvX8lLc3XnxdTuUIvnQRg/ZsOZexJuzMo4mbm5veiYk/syfPW0Ox58JJ2CM3Veof6QT5Qc7C ZB8/fjz1t2YR4DIMjwy9ffuWTM8e+mLtiOyyZM0GJ9pz9vL5ir20x/30mW7fPWWK5PD5/FGnP63k bhApspNVH17xUruzZ8uKy+fP6MtKny6d+nv5qlWYOHEixtAKct3a1erVuUt3Ivy7RPzrEDFSZPxR sgSthQlrX109PD7py/H09FR/a+1Sbab67akfWNLSnqy3txftk/9om3+sPn74oIhSk5++pwmbJry9 YIiZ/z6OHDkyqlWrguJFC2LsmLGYRXvPE8hCMJMIdtmy5ShdqoQeb22c6Qv3/WPO7Nlo81c79a5U 6XJknVlO/aUzVRuK4Xj46Uv5QBAIJgSEkIMJWClWhwDvDzemhPArfM3E2gP56dOnGDxkCDp37oxW Lf7EOtdNtCe7WEfIvoT3jkiLE9qPHjlSV9g3H3LQSY379+7i7ZvXKEd7zvny5VFf8b4mE3XSpElx 7dZt3Ll7H5s2uuq7gR2qWNIRWR04fAQPaQ/xMjlk5c6dC8dptXT5yg/nrKD6LnnKVIhIDlKfyWls 06YtaP5nM5w/d44csl6qW589fYyTp8+SCb0AHj58pD7jVawhsfmvgx3QmGzZlDx85Ghl/mWJ5BIV //zTEcvJ/MzTlE+0ks6WPSeqVK6ovn/y+Ak5tUXHGbpfE21194y2BIYMGUqr9c5oQTpuIF0njNft 07KMHD0GNatWIketH57NP3T8TnvYd5GCnNvs7XUTEN6tjUZ1pUyVEm/PXyR8NxKpRyJz93P9RMiD SNyUs8qGZ4JvUb+VKlmcJlZZceT4iZ/6+Mnjx4TBd1plf8VMItZ+/fuTib0Ibt99QHvsK1CpQjnC WOc9zbobChPs3Dmz0b793+rj/5G5fsnihX6u+e67aRIxkoveEcx/P8l7QSA4ERBCDk50pWyFgBsd m9FEM9uWLFYM8RImRkl6AJ88dVp9bbhi5fdHDh9AQTKtXrp0UX1foWJVDB86APnz5MH7d25o2bKF IlReLa5evRonTp5CvwED0JAclq5evoDq5DQWM0YMXL50Gecvkje3lyd9PxBz5y9Qj96Zs2ZixfIl 2LFzlx8zq3+TJU8KDKVxkyaYOmkiTp49hyNkOm7WtCkWLV5MzkBOcCTu8qHl5kIyee/e8R82b9ER a3NyRItMHtg6+aqIw9As+oFWkjwRSZNGt7rVxNHRiRzKEoFNvxxY5T0ROwcuYYsCWxAWL1mCdeRR HoW8mzXRiKVE0aJIkCQpkVYxnDqtW0FHJIL/7vURXl+/Yy05YO3duU2/d+9OZngHbb+ftgcq0/nc v9q1R9bMGXRF0/56hgwZaYLwD5r82YLef0GzZs1wkBzKXru9R4yYsVG3dk18oFWvZpz3JvOx4WrT 3d3dT/vY7K/JX21a4tTJ42jYoD7htzDAPuYVf5dOncjUXIlIMyXu33+obo8VK6Z+dczv582egZfP HuOfTl2UMx+v0ttRW3R0zROkD2jTpjWt8H0IkyjkXT4FkSM5q+9SUR9wf4kIAtZGQAjZ2oiHw/qS JU+h9iJfvHyFgQMHkSf1VtqrbIiz5y/gxIkTSJMuPTKTuZY9d1k00mYzMzvrlClThhyeEmA2ESgf i5pEQSo2btqkPGEvX76sVmRlaa82sosLqlavgQ7t2+PWnTu0Un1KK8jHcKIjVY0aNVLm8kTkUTuL yuFz0UyC79w/oGmzFihJK61VZOLlBzaXk5HM5BxRjKUQmbz9y6SpUzGIzs9608r0ytWrSscBAwbh 6ZNHmL9ggdLt5avXqoy8efPjX3IQ2rNrp2+Z9ohED//MWbLo68ifP7+qonbdujh37izpr1vhNW3W XB2dYo/x2eT8tICIiicg3G4WrjcFr3CJQDV9tYlNfSK2CzQZYYzT0tGvLNlyYCB5ct+9fRtLiMi5 /S9Ix8qVKynMkyZLgSY0ueDV5bXr15WH+o0bN8msXVxfNpuna9apR3vfp3D33n3cunmTCCytMrd3 7dadJlBkFSBrRSVqN5NyMto/jhMntv7+5MlT6rcNWH+2IowgH4MDtH//lY64Xbx4AT179VTe5Etp 1eu3j8vTMaxMaNiwPuFzDy9fvkDJUqVp/zgmOQX2Ikc+Z8yYNYsmKUsVOb98+RK8NcDC+9z16tVV 0bhY2Int8SMdmUeOEh2P6QjVA19rhpevqT4c/lSlySGMgBByCHdAeKi+CK3U8uXJhc3/7dDvi06a MjXQpmtmzDz5C2DrRp0DkaG0/esv8CswmUxk+SthRyJ++ZemtNrTpFbt2uBXYFKAVu68R/2zFCQn tboB3laqTFnwS5OGDRsRuTTycy2f49WiYvkvpC4FseBXYOJfn6nTZwR4af58+dCgYcNAyxlPe/v+ haNZGcq0QMrma5LRBGGLP2wCxkq3pdHr3z7o5a/CdOR30Ii2OgKSsmXLBKp7A8KTX/4lCjnarVi5 KtD7/tu6BXv2HVDft2zZMtDr5AtBIDgREEIOTnSlbD0CBQsVUYT84MF9nCVTby46khKYaCZiNqGK CALBjQCb1Hdu366qSUye5o3/1yC4q5TyBYEAERBCloFhFQR605GWXOTxzI5QbIL9lbDDjtu79/pz uVZRUCoJ1wiw5aJ0ufIqqpsthnYN150TjhovhByOOjukm1qOwjYaI4WLFDXmMrlGELAIAnw0rwoF FRERBEIaASHkkO4BqV8QEAQEAUFAECAEwiQhP370iKL/zFXHLbQsNRxHt1fP7uSRq52phEo+MJ0c gNzoSAR7nLJEoID4Pem6+PF1YQxFBAFBQBAQBAQBayAQJgn5HgXlHzxYF84wfXpdXtOUqdKgZw8m 5B+wcjhDDjzvRSEJOeoQnwO1s3Ok4AHtiJCtAb/UIQgIAoKAICAI6BAIk4SsOQ01oLi8y5fqgtQH JHx+NTKlsIsTNSZu0nlKEUFAEBAEBAFBIKQQCJOErIX/u37tGtatW0cBGLIiQ3q/EZA0wDlYhBsF D1ixciV5VyZFsaKFf9kXHN/3OgVNYDLnFzuEcMB8EUFAEBAErI0A56vmPNciYQOBMEnIHNUoduzY uHP7JmVyqUuJBRKoSE1jx4z202tMqJxw/THF/G3SuDGFPnRAzRq1KLXeNIOUc347moNW8N4038v7 07yyzpkz8DO1YWOYSCsEAUHAlhDg5xA/gwxjgduSfqKLeQiESULOmSs37lDoRB6svPrNnDEdJTCf iFq1aqFgAV2IQhY2Vx86elxdx6/KFJx+xYpllCe3CNq3axsgoi4UVjFv3rzqO45FzK/cdL5WRBAQ BAQBQUAQ+B0EwiQh80o3OiVhZ+Fk7DFjxMJTiqO8k5IIGBIyzzCjRYumxy8WpeRj2Uw5YgMjZEOw mYwlTdvvDD+5VxAQBAQBQUBDIEwS8szp0/Hi9Rt0794Nm1w3KDJOmDgZ+vzbm5LIv8IiSvOXPkMm OFOg/KPHjlFA/Wb44P5OnxFn9CjfdH8yTgQBQUAQEAQEASshECYJeaOrKy5fu45HDx+AHbuyZ8+O fv36kwOWvcqx2o1S2RUoVIxM1KUxh5KcX7lylUzPHogdNx7atutAKeYCdgCzUp9INYKAICAICALh EIEwScjbdu5UXckmZWfniH7OHs+cOUt917RxI7Rt2xp9+vZTaeb4DDJ7TIsIAoKAICAICAIhgUCY ZiBO7eZfHj58iHHjJigy1oS9skUEAUFAEBAEBIGQRCBME3JAwK5d93N+3ZDsAKlbEBAEBAFBQBBg BMIdIUu3CwKCgCAgCAgCtoiAELIt9oroJAgIAoKAIBDuEBBCDnddLg0WBAQBQUAQsEUEhJBtsVdE J0FAEBAEBIFwh4AQcrjrcmmwICAICAKCgC0iIIRsi70iOgkCgoAgIAiEOwTCNSF7eXlhzKhRePvu Hdzd3VWCCTs7BwwePBAJEyYMd4NBGiwICAKCgCAQcgiEc0L+jKFDBsHryzdkz5ED9hStKwIR8ufP XiHXI1KzICAICAKCQLhEIFwTMmd74hSMcaLGwvlz50weABwJTMJtmgyb3CAICAKCgCAQAALhmpDZ RM3pE1+/eoFZs2cjWfIUqFCu7C8HyjVKVsHmbXt7e3h6euLp06c4ffq0DC5BQBAQBKyGAD+7eEGR JUsWBBQi2GqKSEUWRSBcE7KdnT1ldsqAJ89foGuXLvD28UGF8hWxcOECxIwZI0CgeUXs6OioCNmH ruekFPxeRBAQBAQBayGgETKTskjYQSBcE3KUKFFw8MhR1Zs8wMuV/gObNrli3vxi6Na1c4C9nDZt Wv3nvELm1TKndxQRBAQBQUAQEAR+B4FwTcgMnLOzsx6/aNGiq78PHDgQKCEbgs1e2l+/fv0d/OVe QUAQEAQEAUFAIRCuCXndmjU4evw4WrZqDff3bjhGf7OMGjlShocgIAgIAoKAIGBVBMI1IV+6dAmb N2/GE3LM8vr8GanSpEXPOnWRNm1qq3aCVCYICAKCgCAgCIRrQh44eDD4JSIICAKCgCAgCIQ0AuGa kEMafKlfEBAEBAFBQBDQEBBClrEgCAgCgoAgIAjYAAJCyDbQCaKCICAICAKCgCAghCxjQBAQBAQB QUAQsAEEhJBtoBNEBUFAEBAEBAFBQAhZxoAgIAgIAoKAIGADCAgh20AniAqCgCAgCAgCgoAQsowB QUAQEAQEAUHABhAQQraBThAVBAFBQBAQBASBME/IF8+fx+27d1G2bDlEiRLZT49zLuTdu3bBw9MD Xl7e6rsIEexQsWIFRIsWTUaHICAICAKCgCBgNQTCNCEfPLAftWrWxOu3bqhdpz5Wr1yGCJS/WBMP j0+oW7smPnh8hpOTk0r4bWfniLNnT9skIe/btw/r1q1TqSI/fPjgR8ciRYqgfv36Vhs4UpEgIAgI AoKAZREIs4TMpNW6RUtFxiwnT55SRGaYzpsJmIk4frTYuHv3FpwcHfGZkky4uLgYhbK1k4PnyZMH adKkgZubGwYMGIBhw4bp9eTcziKCgCAgCAgCoReBMEvIC+bNxY07d/Q9ExjJEkfjyxcfPHjwALFj xUa8eHF/2Zvv379X+ZKZjH18fPD8+XNs2bLFKiPA3t4eDg4OanXs7e2Na9eu6evlvMySm9kq3SCV CAIhjoBaXNAzqGTJkogc2e9WXIgrJwqYjUCYJOQXRJLTpk9HhkyZESdGdBw+ejRQgJycHPH81Utk ypgR8RMkQudO/6B9+/Y/7TdrBUSNGhVlypRRb93d3XHixAmULl3a7A4w50ZeIW/btg3FihUz53a5 RxAQBEI5AhohOzs7h/KWiPqGCIRJQm7UoD7OnjuPd+4fMWroIEXIvLq0o5ehuLhExu59+2m16aNW ly2bN0WvXj2RPkNGVK9WJcCRYkd70JEiRVLf8SrVkczcESNGtOqo4tU+r5StXa9VGymVCQKCgCAQ zhAIk4T87OlTODg6YdTIYdi2Y4fq0mfPnmDrf9tQiTyoNWGSzpw5i/59sqTJceHSVYwfPyFQQjYc HzxL5Ze15du3byFSr7XbaWv1HTt2DK6urkot7gOenLHwBKlnz54yQbK1DhN9BIFQhkCYJOSde/bS MSYvvHr9GmdPnVJdEjFiJGTJnBkfP34EP1jjJ0gIRwc7cua6h9JlysLT4yPu3rurrh0woF8o60ZR 1xoIpEqVCjXJa//Tp08YMWIEBg0apCwvbK1gS4mIICAICAK/g0CYJOTESZIoTFKlTo106dLh2ImT SEKfJU+eDLdv3aQzyWVRslQ55M2ZFWPGjUOduvXw6YM77j98jAYNG6FggQK/g6ncG0YRiB8/PvjF q+P169ejUKFCYbSl0ixBQBAICQTCJCEbAjlsxEj0H6hbybDs9DVhFyiQD3169UC3Hj3AntNsfmSH rbhxf+1lHRKdJHXaFgIeHh7kmf9F+R1o48q2NBRtBAFBIDQiEOYJmUmWX5osXrIErVq3xbChg9WZ 5Mh0fldIODQOXdFZEBAEBIGwhUCYJ2T/3bVv/wG9l3TY6kppjSAgCAgCgkBoRiDcEbJ2ZCk0dxo7 EGkevqG5HaK7ICAICAKCwA8Ewh0hh7bOf02e4rxnqREwR+d59+6ditb1+PHjn5rDx7DixYsHCRgQ 2npa9BUEBIHwjoAQso2PgLuUqerRo0f6YzXsRMQRwl69eoXzlMmKhb1+NWFCLly4sE0SMrfl0qVL KuQfh/vjI2iaJE+eHDly5LDx3hD1BAFBQBAIPgSEkIMPW4uVzATmP5GF4Xvt75AIUmJKI3llf+PG DZXAgwNs1KtXT98uWdGbgqRcKwgIAmERASFkG+9VjYw10jUkZ2tnm/pdqHLlygV+sbApnqNbiQgC goAgIAjoEBBClpFgdQTY5M6R1LQA+VZXQCoUBAQBQcAGERBC9u2URw8fYP+Bg8ibNz8yZEhng10l KtkKAryPz9YJCQpiKz0ieggCYQMBIWTqxzt3bqMGZXe6dOU6kiZPhSOH9iNp0qTB2sO8lzpx4kRV x5s3bxA9enQVE5mFYyZ37949WOuXwo1D4MWLFyp2teblzv+yMxqv8tlJjUnZcO+e/06UKJFNOtUZ 12K5ShAQBEIKASFkQr5/nz6KjO1o1fPowV0VStMYQubzwOauktKnT68SFLBw/uVOnTohceLE6r1h ogJzzhvbeqIDJycnRXChYQ/8/v376niZhinrzcfQ3r59i4sXL/ohZC37F0d+Eye1kHqkSb2CQOhF INwT8ulTJ+G6aZPqQQeKpfnVPuIvSZb3PvkBzWTCKyU3Nze1UjJVNJMnP+B5ZcyrMD5brD3UeWXG wnWYQspc7sOHD9WxouASjZSeUppLligUftTT01PFdmbhRB6cq9nwOJamC+vH7WSP6zt37tg8KTP5 aiZqboOhk51/73d+z/334MED1f7QMOEIrjEi5VoHAV442PoE3DpIhI1awjUhM7mOGzMGzi5RUL5C RbhuWK/iW/9KfHx8FOHxw5bvZ8Lkc8LmCpMbmz+5TD4O5N/8yZ+ZQsisx8uXL/2QiLm6BXYfTyDY zH7u3Dl1yZYtW1C0aFFldmfJkyeP+lsjaMNytIkMT0AYN1slLc3hjPs4IEI2JGetfdo9PJnidpna b5buJykv7CKgjbWECSmNrKT+DDMdHa4JedCA/li5Zi127dkHu+9fVUo9zgn1q/CavBosWbKkGgBM lgcPHkTx4sV/a0CsXbtWlRk7duyfyjl79izYbMpmXmOEf6j58uXzk1DDmPvMuaZq1arqNp5QDBgw ANGiRTOqGJ7UbN26FSVKlDDq+pC86PTp02qyZAr+BQsWlHjpIdlpUrcgEEoRCNeE/JZWeS4uLlix bIlaVbJ8+/YFi5YsxYB+fYPsUiZkTsP3u8JlcFkBCa8yTV1F8qrOMMPV7+oX1P3e3t7KBG0sIbN5 m9ts68eeWD9z8Q8LMdOD6nf5XhAQBCyLQLgm5FFjx2HgkKGKTJZSWkY2vX4nQi5UoIBlUbZAaUwO bCrmlZq2WtMchzTiYGIMDaKZgE2daFiybWwN4f1/Fp6U8YRI2/OuVq0a4sSJY8nqpCxBQBAQBIJE IFwTMu9z8itBggTIkiWLSspgb++MNGlSBwmctS9g0jhx4gSOHTsGNvmyGXvSpElKDSbkTJkyoUyZ Msq5ypaEI3L5PzbEJm5t711zhDLUmb2U2SkqOIVXvtoeN+NYqVIlxI8fX49ncNYtZQsCgoAgEBAC 4ZqQDQGpVbs2KlWurD4KTg/lgDqBV4yB7VFqjkFshk6TJo2aPDCJ8erY0MzNJlJbXCHfu3fPT3IM 7RwvO4VxcgxDQtY8zAsVKhTshFynTh19V9y8eRPt2rULcA9fHhuCgCAgCFgLASFkX6TZUzE4vRWZ mNg07v/cMtfJ+9cXLlwAe0waeiZrHtj8L5tT2aEssH1a/j4gr2ZrDCQ2pQe2Z+o/cIY19DG1Dp7s 8NnzgJzqTC1LrhcEBAFBwFwEhJDNRc7E+3jPkk3O/lffTFi8UpwzZ44iXG0fk//lVTMfJ2JTOjtB 8WcBne01URWzLudVJJuftWhiWiE8WXjy5IkypfOEwvDYFq9+2TzNk47AkmOE5D6yWUDITYKAICAI BBMCQsjBBGxgxfpPkai918y1/t9bWb1Aq+NjSky6vJdtKEy2nON48eLFavVuOKHg73hCwWZ2S3ij hyQW3C88QWJLgBbUhSdQmgWA28dBREQEAUFAEDAXASFkc5Ez8T4tUIT/YBFaCEn+N6DvTKzG6pfb eg5mSwHCTmYcKpOtHOxUd/36dUyfPl31GWPA+/t8ljyw42uW0kPKEQQEgbCLgBBy2O1bi7bM3AlF WDFJ8wqYvbDz58+vVsj+PdrZW9+aVoDt27crnwQW3gbhiYDmQ8C6yX64RYe/FCYIWAUBIWSrwCyV 2DICbFr3b4pnfbVJCK+AmWyZ5LSjUf7bw2RoTS93Tm7Be/osy5cvR6lSpfS68QpeRBAQBEIfAkLI oa/PRGMzEGATMwcC8e/lzqTLyUJ4f5yTYhju4bMDGyfC4H/5OsOzywGpENCZajNUNeqWhg0b6q9j pzrOFsbnt0UEAUEg9CIghBxCfccOQppzkHYOmc8Ws1OUNVda5jZf019LQcnvbVn/NWvW4OTJkz+t hJlsOUkGBy8xdEpj8mUzNJt/Y8SIYVVztKl9wuZqNl8LIZuKnFwvCNgWAkLIIdQfly9fVsTLTkGc HYgdhpjQNAeh4I5U9bvNvnLlisp2xfo/f/5c/cs626r+rBt7Rfs/L82ErJmseS9W8xJnQmYztua0 9bt4yf2CgCAgCASFQJgkZE86fjJq1EisWbsO3wmBqtVqoE2rFkiZIgVvDOox4WMqTRv/D88pMMeb N28VmdjbO2Hjxg1InTpVUNj91vf88NdiUefKlUuZQzVzqX+z6m9VFEw3s/5adDH/+kvawWACXYoV BASBMI1AmCTkM6dPYdDgIWjRoiWtfhwwasQwrCVyvnHtsp89xC9ffPAfna/18PJWoRN1e4X2tJKK HOydnoImB4F5ILNTTkhF3TK24cmTJw9Sf8OJBU82eCXKK1VuG2PNK1Bt3/VXGa+M1UmuCz0IzJo1 C8+ePVMKa1YIbULaokULJE2aNPQ0RjQVBCyEQJgk5By5coNNqpxwgWXRvDl4+eoV/fVjdcyfMxkw QcSKlxjTpk0zGVJe4Rq7mvVv+gxOT1hjc/ea0uDf1Z/JmJ2POLcwJ8C4e/cu9u/frydk3v/ks7yM S3Dpb0p7tWvNObYVHPr/SvfAvMTNaa+17uF45ewwxyQ8fPhwNGjQAClTplTjgSPTiQgC4RGBMEnI vFeYMUMGFSN65fJlcHCOhD69e9FM3C8h88PA09MDb9+7o9H//ocMGTOjZ/eufkI9+h8UHBiCj5zw Co/3UJlkdu3a9cuxww+ZVzQhMCVWtqFXr7GkwNfxiz2Gtb8tMai5LMbyd/RnQucH8IMHD5RuBQsW VOSsCU9s+MWr5+PHj1tUf64joLCfv8KGdeRVO+/zm4r/4cOHVdHG3mdMH2k5pP2XyZixB/nGjRuR OHHin0Kr8oRTC13KTmsB6cS/A47lbc0gL9r+POvGv1f+PfGL9/CPHDli8xYiY/osOK/RcokXLlw4 wCN7wVm3lB18CIRJQma41q5djb37DmDVimXIlDU7ihcv9tPDiB8GdevVw4tXb3D71i2sI0/c+XPn 4DA9EBInShgg6qlTp1bHYzSC4Qclp24MSk6dOmVSHGr+wWnRu4x9UGrXsTk8atSoFiWEM2fOmKw/ k4W2smZPYLZY5MyZU09Whu3ilTHv6TNhBIf+PJFistcmFZqHu/aedeW/taNNGv6mJMfQ2pMqVSq9 OT6ocWHs9zNnzlQxz/07pfFq/BaN3f/++8+PN7imf8uWLRXuPE5dXV3VJIPbzoTInuUsXEb16tX1 Pg3G6mSJ61gXnijwZIK3QYwd65aoOzSXoRGyta0xoRmz0KB7mCXkOnXrg1+1a9VE9WrVUbRIESxd tgz16v5IuxcpkgsWLl6q76fyZUphx+69GDp0GGZMnxpg/xkmrmfSY9MrJ1UISnilYmpiCHNWufxD ZZNfzJgxg1LJpO9/V39uC682f3WkS9tPZvN1rFixTNIvqIs1D3C+jkmWjwnxtgZPGHj1fPbsWUXI jF/WrFlV9KuAwpkGVQ/fz7G7edVnSeEjWNwG/4TMOvPKkrdPtP15rpfHGreTdeHxyRMexpT/5T5Y unQpmjZtqq7he3nP1tjtF0u2i8vi3xHryLqKCALhGYEwS8hap5YqXQZRyUnr48tXOLD/gB9C9t/x mnewsaZGLQOTMQPImjP/4HAIC0v6M1nxClHzMWAC5r7U2mjO5MNwDARHCE1tReR/bGrvtcmb//fa WGDibtasmV5Nzt7Vtm1bY4ZusF/D/REUZmxhWbJkiX5Cx32kxQ3nVWLjxo2DPYd2sAMhFYR7BMIk Iffp3Rs7d+9GkSJFaanwFc+IjNPT/nCnzv/gwf17aPtXOxQr/gciR3LEkqXL0L1HT7x7+xrbdu6m 1UIk9O3zb7gfGGEZACY3XlVywI+AJCRzS1sDdzZfs/8Dr5ZN8QsILt24L4I6d88TDbYSsM78mjFj hppQMBkbpvcMLh0tUe6bN2/AedFZ2ILCWwbaJJAtWrwdJhK+EQiThFybzNKPnz5VDlt29EPu0KED 2v/dAenSpsWli+fBgfk9PvugXRvd/trRI4fJxPeVjj61R5UqVch8JqazsP6z4AehNVf9YR3PX7WP ceZ9bs6N7f+MOpvJn9JvlbcMeBtB29bRxQSwVyTFJm02q9etW1dfzenTp/Hnn3+GKljv37+PVatW qTbu27eP/FqK6/OLZ8uWTQg5VPVm8CgbJgk5Z85cWLRoUYCIdenchWanUTFk8AAUo1y99erXDx5k pVRBIBgRMAxdyiSnhS61dpILY5rI5uh169bhwoULATql8edsfubkHZrpmtvB++VdunRB+vTp/VTD q3veB+d7glpZG6Ofta7JnTs3+MXSvn17TJgwwVpVSz2hBAGLEvKC+fNw99591fTq1WvQ4Mulh2Hx ooW4dfsOkiRNjjatW6rP+Yc1aeIEOiP8Gs60J5QoURK0b/djX4s9nxdR4ntvby/yDLWjuMJlKavN H78FbfkKFdF/4BAULVr4t8qRmwWBkEKAzbdMYmx65lUkhy5lImMC49UXE5ilncp+t62sV0BWCcPP tb+5Lu1aW7VisNc7H3kMSDiwCZ8UCEy4r/jFpwoCyjL2u1jL/aEXAYsS8qQJ43Hh8lWFBnsvXzh3 Rnl27tqxDU2b/TAvxY0bB5GcHfFPp87KlBUxYiSa7Xqq+2ZQ0veZM2fQ0aLEqFa1Cq5ev6FHd9So UbhEMaCzZM5sNuJdu3Uz+165URCwBQQ0T3rNEY2P4fGKkgmNyZpXy/y3LYUw1TzW/evE71ln/0f8 tGNbxjpYWrtfOC82n6tn4edSrVq1VGAbFkufcLB226S+kEPAooQcI3o0fUueP38BD8/P4MMrkyZM VJ9zYI5v377j6tWr2LB6hSLjrHRGeMOG9Th5/Bj69+9LR1EuYcy4CUifOoUi46jRomPHju2I6OSI Q4ePSBSfkBsrUrMNIcBH2wIjq6DSRNpQM0KtKtp5em7AVgq/W6JECfD5cxFB4HcQsCghcyIHFkcH e3zx+Yzx4yegSaMG2LZjpzI5O9gBPrDHtKlT4faGIlc5OaN1m9YqkQO/Fi9agNt378OBjmh8+apL sv7x4wfMnj0HHcgpq2PHjr/TVrlXEAgzCATH0bYwA46VG8Je37x9ICII/C4CFiVkTRkHByf4fPHE oyfPMHbsGHzjL77T/79HoOxLEeBGoSe9fL4gVuxYaN6iub4NPl+++pLwJzRv3hI7d+zClWvXsHDB fCxauFARc8uWP67/3cbL/YKAICAICAKCgK0gECyE/I2OLLBsct0AZwfd38WLl8C50yfg7eFNDhu6 mNJ82beviq6V2NN+EouHxydkoWANl8m0PYeywixdthQHDx1GK0qh6EEz0Y4d2tsKfqKHICAImIEA O6OxyZ3PIPP+Mb/XZVuLIHGszcBTbgkbCAQLIRctVhzxY0XDslVrQA7SiBkrLrp374bmTRvD/dNn xE+QGG9fPadziW7kwDUT3bp2UeeA3T+4K1R96EgDH6L/+PEjWrVpg3Tp0qLEH6XUdxs3bhJCDhtj T1oRjhHgcKVaYBI+f/zixQt16oJN8ewUFVJhPMNxl+ibzn3AIYE5cImhE552NpyzcnFoWU34FExL OhP+9MVL1KlTD23atFJftf+rDW7cuqPCtAYUFnXunNmYMnUaOSE6q5M0o0aPRflyZczqAt4y4Ohz nBzo+cvX5Ewcm8obhbx58qjy+Dv2aufPkyVLqrzcZ5Pz8JZt29GzZ08UL1ZMX+9LGostyXLrTvzj 5vYOBQoWRq9ePZCSPOfd3N6iAeU/iJ84ORYtmGuWrr+6yaKEzA1m4QhIadLqPA5Z6tVvgMKFCuLl Gzf1/i/KPbxlw1ocPXkaEyZOxDtq5KkTx3Gc3rO0atkCI4cPxdjxE9GwUSN4GezPjBo10uIgSIGC QFhFICBPa21Vyv9aWzRHND6qpT0vmICZlPnFwkeBbO3Y1i8for6xxK2NZXDVx2e8ly9fjhs3bvhJ OMIkxn3TjU6qpKUgS5p8pa1GTm7y5t17vKCoiDVrVgfHo9+7Zw+uEyF/polWQJKYTgcUoRwD0chx 19Pzk0owYq4cpQxrpcuWRdJkyVHqj5JYSFuc1WvUhOv6ddi5bStGjZuIIoUL4tjxU/hv6xakT5cG 7Tt0RNp0GcEe84bCFtrNW/+jo7guaEaLyMWL5mMphW1dQhOLMqVKYMeu3UTIycxV9Zf3WfQXmSNH TnyL4IAkiZOgNYWnPEae06/fvkOGDGlVeLsC+fLA+8s3lfd00dLlmDplMnbt2YvFdNaYI/Gw52Kd OnXRonkzjB87Fhy95tjRo2qWlitXLlSqVAVZs+hyHFtKeJBxFh0+JhI9ekw6w/ljoFmqDilHEAgJ BPh3w6THEbIMz/NyQA1+sRUqoNCZTIbBtULV9ODfdmDHspgQtAAhgU0otGxd1sCVdeb0o4ylf31Y D07HyiEx+biZ1j7t2BZ7w4em4CX+8fR/Djygc+G6jF1RFSFfvnQRW7ftQLMm/1OTKjvainCn1J6c bY0nXJEjRyFSj6Se5xUoJgS/Hj16iNhx4uIjjVOO2JYhfQa4RHbBTZoQfKBVKgdTeUMWlRu0yuX3 fJQ2WtRo9KxOp9RlS8uQIYPV3/90/Addu3ZGfPJPGjVuPP4jXdauXEn1RsX/aHG3jVbEkyZPQSTH CIhCEeDmzJ6JiMQ9hqL1cZZs2ZUFt2zpP1CLVv6LlixF5Yrl4GRP7aV7g0MsSshz5i/0o+OOXXv8 vD924pSf9xMJmMCkC83C+BWcwg+lurVr0mxom6omeoxY+Ouvv9C5U0c5XhWcwEvZwY4APzh5kstE wbm4Na9sftjwuOdwlYcOHVL7toYPWb6Oj/AE91lafoj+SjTzKJ/1ZcLT9OeHP5u22UTJZm7DLF5a eWyhs2SMbq573rx5OHfuXICRxo7SooExDijSWNeuXZExY8Zg729LV2B4NlwrW5tkBFwX+wrRGXhH B3T65x+kpVMzTJwRI0XBccLnn06d0Kv3v1i/bg0uXrpM+QN6YfSoEbTgOoxChYtSnIoWsPvqhQVE ert271Gr3Ab16uDshUsqzGiXTv/AzikS/tegHnpTbvvkKdLg2rXLyufgOy2mrl29QkdkY5C5vLVS L2WqlOrfSC6RVXrPO/efEPE/Up+tWb1SXXvi5ClkyuA3Cpxh27QwrpwWVPEDlRPcgWosSsiWHhTB Xd5XjpbzyZPiy66mGVtO1K9dAyNHDEN9CqfJM9ughGfExq4krBmkwZIPIw2D8Kq/OYEpbAn/wLJA +f9c62f+3NL6c3nmjB/+fXE0LMMJhZbGkz/jHN086TBMa8rkWbJkSYu2gScths5nhs8F/4FNtOeB Rl4B5SvmsrS0l0E9Y0LL92zVSJ4yNRrWq4URI0fRKnQqPn74SNuNn/BHmTJkyn6piLElWT+TkFl5 9eo1ipDt7exVE9kROA/t9zIhT5o0BU8fPyKn3uuUFCgL/mrdikzft1GmXHnazy2IKpUqYc36DZhK +88dOvyt7nemQFMePt76scCTNkXIFL1u0uTJ6NNvIK5eu45UKVNRNMm7iBM7Dl4+e4qHlGyI0/AW KJDfj3newd6OTgO9UbHHe9G+dMrU6VW4ZW2bJbj6JVwTcmQyqeym2ZcmWq5ZZ2enQPFm89+RI0fU zIwHIa80duzY8cv+4WvZ5GXKnp3mbcoPGGNJQXvI8oxd+9sSA4fL4tWItfQ/duyYRfVnDPgBbqr+ vIrjHzYnNzBGNMx55fnr1YQxpfm9xpzxo+U+ZtLQSMtwXAQ0Rhgj1p/FHBINqGU8htk8bg7+mmOR 4QpZS3vK/zKx+c8zHhz68ypdix9u2EbDiY0hnppex48fx4MHD36yQjx8+FAluQnInM1tDWolpqXj 5D1YQwcr00eWZe5gfbzo99KiZSuKW76WVqErwGdmosWMg+t0Wmbyzh147/6RTL1RaB1Nq03K3GUo /Dv7m8zNgwcNxB0iTM7K503l/UkpQ7duXIcbFHb5zKkTKFSokGovm8M/EOErUYd2KOIb/afhqT3L 2ZKSJ18BFVyKk3uUptDL+QsUwnvK7te3/wA8fnAPDx49xkN6JaXokJronu9eKixtt569UalyFSRP lgzPicSDU8I1ITOw96nz2URy7OgRXL/9ABtcN9Eehm5vIiBhpwaeybGwOY0ferwf8ivhzuW9EVOC OWgPdH4oBvXj1OrW4v+yiYxno5YS1p/32U3Vnx9K5uifIUOGn36wv9sWXk3xQ9DY1Z+WotG/SfdX emj4s/6WfkiaM360lZ2x44fbxuSWmULTWtKpiomTszPx+DEFf20VqZlP1bPXN8xmQCZVTX+O5W3s JMqYccV6a/iboj9fmyhRIgoDnMTPhIjx4PHBnzNxGPYPt4t1N3byElz709pk1BAfxiGgCZB2jQd5 ZXN2rj8pTHLvPn0RgZ5dTIj1KUvXJ9omGTZ8BGrVqIbp06b99Czx8dGtaAcMGICOnbti/IQHytkr S+YMWLrwLWFkh9lz5qFsmdL6Y3JffY/M8vFZLy9KNkJ1Xbx0CXkoh8LJU7rt0S+0atZk5rSpuEOB p1LQSv7c2fto+3dH7N+5TRGy/98Ix8SInzAx/iHzu6FoiyNjF0nGjC/Da8I9IfP0ige/E4XmjECh PddTVpp05CGeKVPA+z58LXsQsvCPgX9Y2vtfgc+mNVMejNrDx5yO570bS+8BWlt/boMlxdDhxthy DYnA2Hv4Ot5LtCQhcJnm4m/qKpfHKOtvyQkdl2kO/lp8a1Ow1/T3vwIzpYyArjVVf20Pn1f4vEI2 tFAwIfNknj/nCb5hykluc0Eyy1pyQmRq21kHjsvNzzfDiQHryePQ/2ST2/qWLCCfv0TAJw9P9Pq3 D65cvoSlK1bh6+dPcIgUUanwncImc5AnjjyhxQH/4utL8P697shrsuQpFR7vyBGsbPmK5MhbCU8e PUCbv9qjYYMG2Lx5E57RNsbOPfuwbOlidQ9PfPr264uOnbqgMO1HjxszEnPJnylr9pyUsrM2Pn38 hEGDBmDM2HEYOmwEmpLDWeECBTCUHMHcaaUcNWp0aqejHqZvNPFg4aN5/oV18/76Hc9opXzx4kX1 tR2Z3dnBzNjJ2q/6I9wTcgry+P6TX3SO7taN4liyZBHu0w/l4IEfpuzAANQC+hsz4E0lY2PK/JVe v3N/QPeK/sYjaoolwdhSQzP+WhIMY9v6u9dZGv/f0Z9Xmjyx80/IWppMwxWnZhXTPMx/Fwdz72fS bdKkSaALCP+TPA513KlLVyKqCPrgTu0o1HFUcpKNQmRXuWJ5rFq5gkzGd4mV6dgrOc5y1j+WRGQl 4PfZ6YQOS8XKlSn3wThcv3kbXbrqnHpbt22n9nn3HzxEhLyFPPB9kCBhQn3zWJ8O/3RWaXUPHTlK e8XXVJk9evZCiuTJcOfOHbyl88RtKKZF/Xp1lWWi97//4sSpkxTm2RF16FhuwgQ/fIaikVMg3584 6c9Hm3ibs0vnf+gol48+xa+TcyT06tndIla9cE3Id27fVpG/okePQQfX46u/WYxZ8Zo72OU+QUAQ CP0IGOajZlI1zEdt6EFujFOdoRXMHItYcKBpig8KrwxHjBrjR42ChQqDX5oUK148QDVTkJPVdMrw pwljyStd/9K4aTPw61fyZ4uW4Jd/YTP63Ll+g3i0pVgYbdEuwOI4eIihToYXsRl9HMXHCC4J14R8 7txZMl80oZlcbOTMnoUCk5xC0eIlMXPGjwESXMBLuYKAIBA6EWCyukR7lexxywTy7Nkz5eCpmZ85 aIalfQhCJ1KitakIhGtCrk1BSNiBhfc92Clg1OgxSEWzqSgGYeFMBVSuFwQEgbCPgLbPzmbmhGQ+ NfSMNnW/OeyjJS00FoFwTcgMUsZMmY3FSq4TBAQBQUDtrXJs5sDMy7wHHFTgE4FREAgIgXBPyDIs BAFBQBAwFYGQdrwyVV+5PnQgIIQcOvpJtBQEfgsBXs3xvqaW5pAdcbTzruwBzMdzrOnJ/VuNkZsF gTCKgBByGO1YaZYgoCGgJZngyFBMvmxOvUZHQ1avXq2CLDA5c/xqPu5i6SNDluoFLba1dtZT82zm /VpuE79k1WoptKWckEJACDmkkJd6BQErIsArZI4KxYTLAR/qUvQkTjLBogV/sOUVMuvo5uamQqDy hIJD1vKkQiNkXu1rzlVWhFWqEgQsioAQskXhlMIEAdtDQIuwVKFChQAdkZiI+QiPLRMyr4w5nvph ynvLwhl4OOa5JpzSNWnSpOJMZXvDTzQyAQEhZBPAkksFgdCKAJMt7xOHVuGYyByjPUeOHKoJhgkz +D2bq7UVf2hto+gtCAghyxgQBAQBm0eATe5Mur/aJ7aVKFcBgaltGWjtYBM8BxLhF28j8ITDli0U Nj9AwoiCQshhpCOlGYKAIGCbCOhS+XnjxIkTinz5xfGV9+7dqxzp+HvOGBdQ7mTbbJFoFVwIhElC 5j2z1atXYePGTYhEM9BixUqgQf26fhJQM6Bs4hoyeBDevHXDe8ouogvu7oAxY0YjceJEwYW5lCsI CALhCAEtuQTntNYChhSn2M6cY5mFV8v+czqHI3ikqQYIhElCPkHOHg0aNETefPlwhvKwLpg/HwsX LsLe3TthZ89ps3XCCajHEfl6ffmG/PnzqzOaEYiQJcqO/EYEAUHAUghoTnX169fXO9UxSRuaqD9+ /KhI2dR0mZbSUcqxDQTCJCFzPOoVK1aAfwAXzp9XCauv37zJmb/8iC5YQhTEiRoLx48fN7lH/OcL /VUBTPbW2iNiM5ilJbTrzw86U/E3JeONId62gr+t6M8e0qEZf17B/q7+PPaYdI2R4Bg/xtQr14Q8 AmGSkONTnFkmYxb+ETCZ2EX4sTLWYOcfCa+GP7x8hkmTJiF5ilSoXq3KL3vl8uXLcHd3V2WyI8YT SpbNe0O/En4wsnnKMNm3MV3PM2ZTAzVwXedpEsIPQUs5uXA5bygBubX0v3DhgkX1Z6zfvXtnsv7m xCRmrM6ePauzttDflhJzxg/rz3uXpggTD+vPfW0J/TUnJt4SMmX88H382/Ty8jIp8Tvrf+7cOZvS 39i9YQ1vY8YPP7v4+uzZs6tz5ZYUfu5wfwXkQMd1Ro8e3U+f8DPKdcN6vHf/QNuA7Jym06ZuvXqI GyeOJVUzqSwv0mXhosXK8hCDcjM3aFDvl/cfP3YUFy9dBh8P5CN0mrx4/hz/bdum8ODfU/4CBdUi j+XVq5fYsmUr5XdOhjKlS5mkX0AXh0lCNmzokMED4eXzBd27dSVztd8HJD80s2XPhifPXmDgwIH4 SMdCSv1RCsuXL0esWDEDBJeDK2imJR6cTHxBpVrj67guc8SchyLrqDmLmFOn/3usrT8/YPhlTtsD a6+5K3xzdGDdtXy5lsCfy7D2+LGk/vzANgd/c1f4jL8lxz/r/7srZFPGgTHjRyNkc8ZnULrw8+3K lStqEWE47vhzft7lo63AWLFi6YvxpklTy+bN8O6DB4VjjUZY6Z6zxYqXCFZCXrVyBebNX4C/O/6D qpUr+WnWzp070KdPH5pc6iZnTKSnz57BwP79sMnVFSvXrEFk8i+KESsOJowbgyePH6N06dJImiwV qlar5qesK1cuo3nz5uqzaNGi0UTxC+rUrYfJkybgwb276rsiJUoJIQc1sHp064Ydu/YgU+YsqFe3 FiLQf4bC5uoDh47oPypdshh27NiOWbPnoHevHgEWz8muNeEVMkcPypIlS1CqYNeuXWqGZYo5ih8C pu4p8Q81Xbp0auBYUvbs2WNV/XkWbknZsWOHyY4zWtxnU/Rg/Pm8LB9nsaSYM35Yfy3UpLG68EM3 Q4YMQU4yjS1Pu04L22nsfYwjP0hNTWWo6R8lShRjqzLqup07d5o0fszRXyPZ4Bg/RjXS4CLWhbE0 JHwtRKn/svgaHu/fHSPj/t3biBolcqDV+d8n/9W+OVtIAhu/TLCXKSc1/y5KlSmPcmVKq2v5ecmr +ymTJuL06TOYOGky6tSuiQrlymH82DHIlCE9etLiLH6SFKhasQxGjh6LQgUL4Pb1KyoN7+Ahg5Ag fnw/+jvSOGSp16AxFi2Yg1o1qmLxogXIkTMnalSpqCNqihRnCQmTK2QmykEDB2DMuHHInDU7dmz/ D4kSBew1bTgDjBJFR2InT540Cls2pxlrUvY/uI2qwMyLTDVTGlNNWNDfmHb6v8bUfWe+X0tWb059 gd1jLv7m6h+U1ceUtvGD1RwvYtbdXP1N0S+oa3kibW39LT2hC6qNAZGsfwvFrywWusmEPWJE/7EQ GNS/LzZu+Q9r1q7Hnp3bMGXadFSqXBX5cufAiFGjaYLvQ6dZkuDhgwdkBi6ESZMnwplItVWL5njr /hGxY8Wg7cBTtGKtjuHDhihSffn6Ffg5nTFjJlw8d1qpvWnjBty5dR1t2rRB7ty58Zqu2fLfdqRL n5FO19RDvHjxyPJZEhcvX8Fnynv/6ZMH4sSOrepmGdCvL520eYv5CxcTedcKFKpv376rBdVff7XD 1m074f7ho8kLpqD6IUwS8oH9+zBq9BgkSJSYPKzn0iCJrswvkSK54P07N5o1TSJTdU5EdLTHzt27 0bZtO7i/f4tDvmH5Ro4cERRu8r0gIAgIAoKALwK8On37wR3dunUnq4YjvSIiR67cGDhkmNqTjehk R89gdyLNVti94z9avZ5GyT/KoH///vi7bWvMnTubVrqlcWjPLixYvARduvVAj26dUZHuXbhwIZmk K+LMqZN45fYe69atR8WKFTB29EgcO3mKzMd10bZ1K/1q2p5WySyRyXzOZMyiRXFLnCQp/vyzGbZu 30X7wjvU1th9mhBUqlINzZr8D194e4XuD2gr4Ou3L3j58gVNDoYjRsw4qFi+LG1zGueoZ+xACZOE fPTIUfzxxx+IHTsOli1dqu+M6tVrIkvm9Bg1ahQKFCqGurWqqXi4H2im4+39Gdlz5kLt2nWQOlVK Y/GT6wQBQUAQCPcI6PaXnVChYkW4RIqo9p7Tp0+PTh07YOLkKQqfGTNmIWWKFGoPlqVKlcpqP7pM 2XI4de4CXr2kle3Wreo73tddvHABPZvfk2OfN/bt249YtKp1cImOmjWrq2s0czbXG5Bj23fSSRNt 649XuNNnzcb169dVcJZrVy8jSrQYuHrxPCpVqoTHjx4iXvzEtHX5309+GxfPn0Xfvv3wlbY+129Y h7x5cuPkiR/x1C0xCMIkIQ8eOjRQbJrT7Ijl7/Zt0ahhA3Tu0sUSOEoZgoAgIAiEGQR4K45N9YZb Btq2SUDbCPydAxEjp/G093XqYjAiuUTyxUR37pqv07YJtW0ArTzNIz9GzNgYMXwYbQd+UU5ikYjg 2XdnCjlRfbePSGZnL0QkYtXu4+8N5Zuvm7ehl7i2Qv7ke/SM/STWr1uD+w8fkc5p8OD+PVSrUQtD B/TB0+evQdZp+HfDzZEzD2bPnu2nLks71YVJQv7VryICHX+aN3+hImMRQUAQEAQEAb8IMMnEjBlT 7Y8aOpVqjmoBOVp5UdTDz1/sdIRrp6OyhRSQaTRtHcZPkAhRXZzRrl1bFCpUkI4gxVDfnz5zFg8f PsSZM7q94ChRo6AABWhav2kzLly8jBnTp+DZ0yd48vQ5JRXJro4uRozy4/SLRrKHDh0mc3Njva68 x5wjaxacv3gOXbv3JEtoDcyj/eFYZDFNmSK5qmvViuVkLh+IrmQaT5kiKXib88jhI+qkjaOzX6c0 beIQUMAo7TtjfYmCGmvhjpDn0SAREQQEAUFAEAgYAV7B8skRzevb/1X+T34wgadMlRov3rwjy2N7 8o4nQiYHr+1bNiEukbHrBlfs37MT4ydOwtLlK5A2pe6M75ZNrnhDMSDOnr9A+8yV1NGlmtWq4gMR 6LIli+Hp8QFXr15BXDIhb93sCk6x6RAxqn5/t2Gj/2EbnQ/esmkjWtD+bocOHSkmeE7aN45LTlfb ULtWLfKGXojLF84hWYqUWErbl7np/PDRo0fRh0zPsePEpz3vLsqreuWyZdjoup5M3y74t09fOBhE dGRzeAKKbRE3btyfAHN21n334tkTtKe2s8SNFx/9yFFM28s2ZZyFO0I2BRy5VhAQBASB8IiAKcct nYmwDh45pk6c8CpWmZKJpNkzmlfT7DGeM0c2dV7482cvWp0uVZB26doV7dv9pY7Y8TWa+Xf7zl0U dOmzbkVMZUf1PVJ0is4Uszg7Oal/09Ee9WEiV95j5qNOMWP+OBudiDyoD9LK2ZNW7nzqRjN9830c TIVX547kfOZCMRtYdu7Zq/ek93/CIE++/Lh9+3aAgW2yZc+hvlMBpj58UGU5OOiOX5kjQsjmoCb3 CAKCgCAgCOgR4GBELIGd/+bz5PxisuMcAizM25oXtCGUdmTy5uv8E2NAR8HYoYtfAdXrQJOBqPzy d0Y4oCN9mv4BdSlbDAI7BsjEq32nmeJ/Z1gIIf8OenKvICAICAKCgEkIFCpcVEXR4rPBIn4REEKW ESEICAKCgCBgNQTy5S8Afon8jIAQsowKQUAQEAQEAUHABhAQQraBThAVBAFBQBAQBASBcE3I7A14 +NBBjB03XnnFpU2XAf/27qmcAMzNriNDShAQBAQBQUAQMAeBcE3IH8lNvWL5ckiVNj2defOAK6Xl WrBgIQ4fPoD0lDFJRBAQBAQBQUAQsBYC4ZqQI5Kr/opVa1CufAXC+zvy58mFcxQhxts31mpQncBn 5IxNum5OPtig6g/se1NSPBpbR2jX35r5bG0Ff3PzCVtafy0tnqmZm2xFf/6Nh/bxY+zvXK4LWQTC NSHzg6JylSqqBx5Qxg8+tM7iN2uy3w66cOGCOoTOBMWh2x49eoQjR37kVA6oO/nB8ubNG7Ny05oa ko3rOnPmjJooWCrOKpfz+vVrq+l/9uxZi+rPfcJ5q42dPGl9yIf9TU1lyVidOnVKPcAthT/rY874 MUd/1pv15/FtCf21+MQc5MEU/Pk+xp5/Y/7Pkf7qkcn6cyYhS+qvBbwwVX/Gn/Xn87fGiIa3MeNH i6KVK1cuivWsxYs2pha5xpYRCNeEbNgxc2fPxLWbt1C/YWOk+kW2Jz78zT8w/uF/orinL168QJw4 cYLsYyZ/c3KqmvNQjE7pJvlHas69gTWE2xya9Wf8TV2h+Y/lG2Qn+17A+PMq05L4mzN+fkd/tv5Y Sn8O8m8u/ub4cjD+ltSfCZnJ2NTxw/iZq39Q40cjZHPKN3Ycy3XWR0AImTBfMH8ehg0fSbFN46Hz Px304dQC6o7kyXXByVk8aN/51atXKs1YUMKzfFMJzZwHKv9QU6VKBX4oWVKsqT/HrLVE1BvD9nMk H3PwN2VVxPUx/mnTplWhAC0p5uJvqv6MEesfWGQic9vE5ZmCv2EiA1OIkOvgzECmrKqNaZOp44d1 ZrI0ZSKikWxwjB9j2ijXhDwC4Z6Q51A6rdZt2iBmrFjk1LWB8nPmNbpX2KRmrEnZlIeR0QoEcmFA WUl+t8zwqr8pZKBhzOPC0oRsLv7m6m9JQubxaI7+rLs5+lt6/PMK3xz9tQmaqb+94Bg/puog14cM AuGakB/T/i+TMcvMmbOQOVNGPH36VJkbY1MybBFBQBAQBAQBQcBaCIRrQj548CCqklOXA+2Pnjp5 Avv37VW4p0uXHp06/WOtPpB6BAFBQBAQBAQBhGtCbtioEfglIggIAoKAICAIhDQC4ZqQQxp8qV8Q EAQEAUFAENAQEEKWsSAICAKCgCAgCNgAAkLINtAJooIgIAgIAoKAICCELGNAEBAEBAFBQBCwAQSE kG2gE0QFQUAQEAQEAUFACFnGgCAgCAgCgoAgYAMICCHbQCeICoKAICAICAKCgBCyjAFBQBAQBAQB QcAGEBBCtoFOEBUEAUFAEBAEBIEwTcivXr7A+g2uSJ8hI0oUL/ZTb3MQ+tWrVuHDx4/w9PRUgezt 7OzRpEljxKJkEyKCgCAgCAgCgoC1EAiThMzkOnrUKMyZMwdPKFlE3fqNAiRkT08PtGrxJzy9vygC 5vyldvaOqFixohCytUag1CMICAKCgCCgEAiThHzm9CkMHDQIJYoVU4TMuUwDEibgSJFcECNOdDx9 8lBd8p1eEYwcHE6UlMLYBOGc29hawjlYLS2iv/GI2hL+PMZNFUvrz+WZM35Yd1vQn3NKm6M/424L +pva/3J9yCEQJgk5e46cuHz5Ml48e4L9ZQ7+Mqcqm6k9PD7h8OHDiBc/AdKlTfPL3nhEKRs9PDzU D/TTp094+/Ytbt269ct7+Ef5kczipv6oWTdT87ByXffv36eJRiSzHgaBTVw+fPhgVf05n7A5D7PA OsIc/Bl7Y/Nda/Wyznfv3lUpPG1Bf87la4po+keMGNFi+rMO/FsxZfyzHnwfbyuZMkHg++7duwdL 6s9jwBz9+T7Wnyfuxog2XowZP/xs4OuTJ09udPnG6CDXhCwCYZKQo0aNisyZM+PRg3tBohs9ejQ8 fvYcRYsWRfQYMdGqZSv0798XXEZA8ubNG7x7906tjD9//qzI+fnz50ESspeXl0kPJLVaNzNBO08S WD9LEQKXY0393dzc4O7ubjH9GUtO+m4qHkzIpk6IuC4eI0w+ptb3q0FkDv7m6M868/ixlP6GxGoq HuZOiCytPxOrOeOHf7+mTuj4HmPGj0bISZIkCfIZJxeEHgTCJCFr8POg/ZVEjhwFBw8fxRf6wfGP v0Hd2hg7djRy5MyBRg0bBHhrjhw59J8zIXNOZSbzoOTMmTO4efOmSbNZfigaaxI3bHOePHkCnVAE pWdg3587dw43btywiv65c+dGtGjRzFU1wPtOnjyJO3fumKQ/r8yMXd0Y4p8/f35lobCk8PhhS4wp +pijP/8O8uXLB7ZQWFJOnDihVq7G6s+/Xb6WV7pB/Y4N9WT98+bNi8iRI1tSffD44ZWrKfoz/qbo r3MqtUNwjB+LgiGFBRsCYZqQg0KNB3/SZMn0lyVIkJD+Po958+YHSsiGZTIhG2sS5JmyqSuEoPQP 7HteTQW2wje3TGvrb66egd3HD2pT8TfXQsH4W5qQzcH/d/S3JCGz2dba+FuSkPk3bm39LT1+LP17 kvKCB4EwTcjanpWh2ciNzHHbd+xAsuQp4ORgj0u011yjRi18+uiOK1evKpSHDRsaPGhLqYKAICAI CAKCQCAIhElCvkempTFjx+LlixdImjQpbt28jnbt2qFaterIkjkDGjZsiCLF/kDxwvkxYdIkbNu2 HR6fPsDjsxfat++AnDmyy4ARBAQBQUAQEASsikCYJGR2dOjXrx95ZzqR6TaKckhiL8moUaNh6uSJ CuBKFcuhW9cu6Nu/PzQPYj4exd6xIoKAICAICAKCgLURCJOE7EjOIAkT8n6wTphkNSehXbt2o2ev f9GrZw/1HZ8xZMcLEUFAEBAEBAFBICQRCJOE/CtA9+zbF5J4S92CgCAgCAgCgkCACIQ7QpZxIAgI AoKAICAI2CICQsi22CuikyAgCAgCgkC4Q0AIOdx1uTRYEBAEBAFBwBYREEK2xV4RnQQBQUAQEATC HQJCyOGuy6XBgoAgIAgIAraIgBCyLfaK6CQICAKCgCAQ7hAQQqYu51i7U6dMRvSYcdD8z6bhbhBI gwUBQUAQEARCHoFwTcgc43rpksUYNGgw7lEO4YSJkwshh/yYFA0EAUFAEAiXCIRrQuZwmt26dkM2 Sqn48sVzxIgR3aRBwBHAjE2PyJmGeAJgbH5dLZetloLRmBR0WnYfY1PEmdLY8Ki/lg7P2D7W8A+O 8Kvm4G+q/tp4sLT+nIaQxdTxz/oz9qbm9ra0/hzNzxr6a/1laf1N+Z3LtSGLQLgm5ChRIuPYiZOI 7BIJqVIkNyqZOOdEZSLnhwT/++rVK1z1zRL1q650d3dXYTpNEf6Bvn79WqV4NCbRuUYIV65cQfTo QU8u+CHPOrHJPih5//692fqz7qbqHyNGjKBUUukUjdWf8TeWWLliLptxf/nypYp1bsxESsP/0qVL 4LjoxgiTlTH4mzp+zNGf9eV2sv7Gpu80Rn/GUfvNGIOJhj/j8uzZM9VvxkxIDfU3Np+2Mfrz2P34 8aPJ40fTn8eoMfprhGzM+OFruY8zZcpkLKRyXShAwDSGCAUNMkVFOzt7pEmTWmWF8vH5YtSt/GBh cuKHhKenJ7y9vdX7oKRSpUqoWrWqUT9Mw7L4YWDMj9nwHn6oGqMT63/nzh1kyZIlKPVRsWJFVKlS xWRdglN/zkd969YtZM2aNUj9GXtTHuxagcGpPyc9uXnzplH6V65cmbKVVQt2/LWVuDHjh8f+jRs3 jNK/evXqVsHfVP2vX7+ObNmyBTl+GHtbGj/8TOCJzsmTJ5EvX74g9ZcLQgcC4ZqQDR+6NNk0Sgwf /kwI/KMoWLCgUffa2kX8QA3N+vMKhNsQWvFnsmdSDq36MynwbyC06s+/Rw8Pj1Ct/4YNG2ztsSL6 /AYCQsgEHs+qzRGNkM251xbuEf1DthfYQsETotAqYUF/Y7ZSbLV/+Per7c/bqo6il2kICCETXsr8 8x3KBG2KaGYjU+6xpWtF/5DtDcE/ZPHn2kPzhCgs6B/yI8C2NAjXhMwzzEED+uP5y1dIly4tIrlE Rtu2benvDOjSpVOQPcWOL4ULFw7yOlu9IHLkyKFe/yJFitgqvEHq5eLigtCsP+cRD836szdz0aJF g+wnW72AT1OEZv1tFdeQ1CtcEzL/IHv920fhHzVaNHyjPT32qHVw0B3TCErYezJ27NhBXWaz34d2 /dnJJjTjL/qH7E+DjxSG5vET2vUP2d63zdrDNSHz3rHh8SA7ItiYMWPaZk+JVoKAICAICAJhGoFw TchhumelcYKAICAICAKhCgEh5FDVXaKsICAICAKCQFhFQAg5rPastEsQEAQEAUEgVCEghByqukuU FQQEAUFAEAirCAghh9WelXYJAoKAICAIhCoEhJBDVXeJsoKAICAICAJhFQEh5LDas9IuQUAQEAQE gVCFgBByqOouUVYQEAQEAUEgrCIghBzCPfuFMhadPHUKCRIkRKpUKf1o853SKB4+ckTlqI0UyQV5 8uaBnW8ijIsXzsPtnS5HMadfC4kg88+fP1fp9zjiVMpUqZA4USKl/7lzZ+Hu/kHfFtaRg7AkTJgQ KVPq2njp4gW8dXun9M+bNy84DGBIyaMHD/DoyRPCMT/pY69X48L5c3j3XpfH2j/Gly9dxJu3buq7 PHnyIKSSyn//TmPkcNBjxD/GVy5fwus3b5X+uXPnBofBtLa8fv0K16/fULmyWY/8+Rn/H48kwzHi H+NrlPP7JeUK5+tz5cpFv49IVlP/6NGjcKEwuzlyZPdT5/17d/Hg4SP1e+A8xbFixdJ//+jhA9y9 d199ly5desSLF1f/3VMae7du31bfpU6dhn4nCazWFqnIthAQQg6h/mCyXblyJWbOnImDhw6hZeu/ MGfWdKXNN0p24bp+HWbPno0dO3epz1KkSos7t67jAyVK79unDxbMn4cPnzzUd/UaNMT8uXPpIWG9 h9LNG9dRsuQfeEoJ5FnS0kOmefMW6NWzO/5u1w5Hj5/4Cdm/2nXAtKmT0KVTJ8wn/d0/flLX1K5T DwsXzEfkyC5W7w1+6FenXLd37z9Ay1ZtMWf2DJVLul/fvoTxfHyk9HwsDRr+D4sXLQBPoP7t3RsL SN93vpOOGjVrq++iRIliNf05MYXrhvVqjGzfsfOnMdKPxsh80vGDL8Z16jXAsqWL8f3bV/Tu2QsL Fs6nCZ27uq9qtRpYsngRokWLajX93759g7JlyuDc+QvgXGuU2wX/a9yUMJ9LKTW90Kf3vwrj9x8+ Kp1q1a6L5cuWqIld71691Hh5QxM6loqVq2E5tS169GjBpz8pePzEcYwfNw5r1q5FhkzZcO3KBX19 gwYMIEwXKEJmyZ07L1w3uiJJ4kQYPnSoGu93iJBZslL+ZVdXV6SiyemYUaMwj767cfOW+i5DxozU r65Inz5d8LVFSrZZBISQQ6hrDh8+hIaNGiFZ0mRKA0eD+Nk8+69Ttx6cI0bC1q1b1QqGSZpj126m H/nkKVOQI1debNywFq1aNMeqFcuRJlVqDB062Gqt+UQP+qxZs6nJxMoVK9C3Xz+MnzAJPXt0x3rX jSrPLwuvfgrSyv6l23sULlQQu3Zsw8TJk+mhlBNbNruibetWWLtmFVLTCnvkyOFW01+rqFmTJoqM WXbs2KH+3bp5E6ZMnYpcefJjw7rVaNn8T6xYvhTZ6UGaN3cOTJg0CRkzZ8WF/7ag/V9tsWH9Wgwk 68bYMaOtpv+1a1dRp05dODlHxOYtW5CXVumGY2QSjZHsOXNjk+t6tGnVEmtWrVD6FymUD+MnTkTa 9Jlw/sI2dPy7PTZu3ID+A1Ji4oRxVtN/xbJliozLla+oJjO5smfD0iWLVJKXgvnzqDGSOUt2XNy6 Ce3atsG6tasxImtWlCpZDOPGj0eKlGlwlu7v/E9HNd769O2HqVMmBZv+bm5vUb5sWTiRJcHB3s6P ReQ0WbgGDh4MR2cXPCBry9jRozFl2jR06twVw4cMxMCBA+Dz9Tvu3L2L2TNnYNToMWjfviOmTBqP wYMH0aTPU1maVixbSuUMQdNmzXH82OFga4sUbLsICCGHUN+kTpMG69ath4MdUK1GTUrK/EORF8+e KjN16dJlaRVaUv3NmZlYJozXPTR79+qJZMmSoVu3rti5ew9evHpt1ZbkpEnC9h3bVZ1t2rTGkMED afXC774jfvz4el0W0arBzd0dmYnAGjVqgCIFC+j0763Tv3v3bthGKzxr6886rF29CmcvXNTrGjWq boU1ccIEnY49dTp27dIFu/bsxXPCeMpk3UO/F63S+LseNAHZ8t82vHhpXfxfkGXiK42LP0qVQak/ /vA3Rsb7GyNdsJ0sLYyxpj+vMnX698DGzVtI/1dWHT8+ZGlQo4UGDVsWPD09EC9+QlSsWAE9unT2 HSM6HXmMbN22nUzUb/T6//tvb/Vdr549FCEHt/4uZL2ZNWcOMtDKlbcv+DepyayZOsuW9ptk3ZiQ P376hPnz5hAZf0P3Hr3Uirh3716KkJmEl9AEhP/9u0MnmoikQ0/qkxHDhuHZixdW7QupzHYQEEIO ob5IlCgxatasoVa8/mXwkCHqo+3btigi5v3hwUOHo2f3rjQz1+21FimiS/voQT9oFnv7kOvKgZTC 0svnK8rSCsK/7N+3F94+X9C/f1/1lQPPQJT+urSJHr4mYWvr//HTR0yhVWT8BImQOEE8Wm2d16vu 6KjbR9Yw9vysw9iB9vicHHU4F/VNuxlS+g+hlRTLzh3/BTBGdNnKfmD82Rd7B9Jf+04bPzqTvLXx b9m6De7euYtlZF2JEycOEidJio2bNiFThvTw8dFZV4oW9TtGHGiM6/H3TZv4yUrjx5ksEfXq1cNz mizzeDYUZ1//h0KFCqmPOWOcwpT2t/1/p/lWcFucffuiIFmOWNxp4soTc0eDfXQ/FcmbMI9AyD3F wzy0xjXQcKat3aF+mCS5cudRs+4DRGq9enRDwgQJECNGDPWdRgS8p6YT3oWzvuzauRMrV61W5nSe MPzQB7hz+xZ208qyWIk/aLVfyo9yIa1/i2ZNcZCcoR4+forZ0yYrQvZPSj/rSM9LX7xDWn9tjOTM lZv2tHsZN0Zo28NW9L916xbevXuntjbiEiF/oP34SRMnYRRtW2gOcgFhHNL6e3t7B/oj8/TUTdwi 2Pn+JglvTfTfBfB7/fk76/+OpUbbQEAI2Tb6wY8WGsWmon3hauRwFMnZkfYtJ5M39hn+uatrtYcW e2ayaCZAazZn//59qF2rpnLOWrpsOZmlM/mpfh6Z+B4/eYpSZSogpu9EwttbZ6p0olzULCGl/8nj x1X9q1Ysw+69e9XfL148xaFDh0kn3SpSj7HdD4y9fFdHjr6WipDSX3uup0z58xiJAJ0V4scY0b3n MeLtrVvdOYWw/u1pX/jYyVOYNHkq/mrbGi3+bIbZs2aQ2Tq+OlGgdPRdeRpirK1OnZx0fRRS+BsO dE0nB98Vr73BeNF/5+sj8kNfb/h80fUFr5ZZ7NRvOQL1UeCkb1iv/B32EBBCDuE+1faGHQ2O/XTr 3h0N/9cYjx49UivhK5cvKy0zZEiHb146r9Oe5Ck7Z/ZMjB87Vr1PlTKFVVtym1Y4lSpWgr2jEzkF bUbVqpX91M+6T6N9NJaOHf/Wf5cqdWp6EJ+mvb9ean9tXAjpv/m/7WBz52s6OuPioiMAB3po8v53 ihQpcOjoMdrT60lOODMxbpwvximSI8IXnfm3N3laL16wAOPG6L5LbWX8eYzUb9gIj381Rnr0xNy5 s/VjhHV0ttPtffYmL+alixcS/mN0+vs7chfcg4mdpFhK/lFSbcmUKFEcS2hSxx7uadKkpW+2qzGy YME8P2MkqouOiBn/FcuX6b+zlv76/On6lS6dgEihO8o3eNAgFCqQH5MmTVTvU9J4SZY8hfp76NAh 1MaidMpgiu93KZDE16Fz5MgR5HFeCgvmzYbXl69IS/4lIuETASHkEOr3+/fv0cNyHvj4EMuRQwfQ l47alCpVGuUqVERR2iM+RJ/VqlkLR48cwt8dO9FxorZ4Rw+ym0SG7PX75vVLnDx9mo5MtVXOLdaU ObNmwoNMdBlphXbp0gWcPKlbcfJRqFKl/sD0qZPhTseymjRtjpwG5zWnTJuO1+RctJq8ft3evsbx kyfRrEUr9CFHGGtKFvLY1WQL7ePv3bcfMWPGUl6+E8jD9/HTp3RMaAlevXyBU2fOoHXb9mpi8cH9 PR1RuYH1a9fA/Z0bTtFRmMbUxn79+1hTfZQtXwHFaY/1wKGD5ItQE8eOHvEzRvhc68qVy/H2zSuc IC/g5q3aoFOnjvj48YPSf+OGdahe/R3Onj5Fk78mYD8Aa8qffESOJgU1qtdA/Xp1MHniBMSKHRc1 qlZBoUIFcPXqVawh73se7ydOnEDTP1ugW9fO8CBHqZvXr8OVPOGrVauOC+fOoG6DRuRUOChY1Wez 8iTS8QmNC5YXz56o32vatOSMRZODp08eY9rMWahUuRJePH1CznalMXLEcLIMRafjijcxjszxFWkC 6+72BkWKFqdJ3mjEixsX9+7ewbARo1CpUiV4f/6EfAUKKq9zkfCJgBByCPV7LHr4ly9fXpmkhwwd Rl6mnvSw/IjkyZOrgALbyKv00ePH6jM24Wnm4Bh03+YtW+m840P1Ha/uOAiBtaVJsz/pId9amdd4 P5PPxbKw5ytL567d0Kx5S3pgpfWzr8yk57p5M+7TUaOQ1N8QrwHkINWJ9HVyclbtiB07DrbQcbOH dKZUp2NkwjijuiVqtOjY4LqJ9L+vzoRHIvwzhwD+MWPGJM/jbWRFCXiMbKKjUA8e/DxGokSJinXr XXGP9SfnIx5b3DbDvX9rjKUevXqjOp0u8Pz8WenRoGFD5W2d3Hf8GI4RQ4xdyMlx1dr1uHfvnq/+ kZCR8NcC5gSX7ryK/+OPUvhC3tV//90BX8jc7ObmRpO4mMpsPnXGTHTo1BmfaMLApmse95F8g62M nTARrdr+pb5jR6/UZCWK4ntqYujwkTSh+1NZwtgPI2XKVFY9Dx5ceEm55iEghGwebr99V7To0fVe sAEVFpkeThkyZAiwHn5ABfbdbytmZAGZs2T55ZXx4sWnaEQ/jj8ZXhyRzleHtP6G+iQgZzl+GQqT cGA6OtODNn0gfWMkfBa5LHLkX4wRItrA9Of9+/Tp01tEh98pJN0vdPjVGOG9ZWvrr6K1USSxX8mv dDL3u9/BV+4NfQgIIYe+PhONBQFBQBAQBMIgAkLIYbBTpUmCgCAgCAgCoQ8BIeTQ12eisSAgCAgC gkAYREAIOQx2qjRJEBAEBAFBIPQhIIQc+vpMNBYEBAFBQBAIgwgIIYfBTpUmCQKCgCAgCIQ+BISQ Q1+ficaCgCAgCAgCYRABIeQw2KnSJEFAEBAEBIHQh4AQcujrM9FYEBAEBAFBIAwiIIQcBjtVmiQI CAKCgCAQ+hAQQg59fSYaCwKCgCAgCIRBBISQw2CnSpMEAUFAEBAEQh8CQsihr89EYxMR+EDZqDhz Fss3ytbDGZ2iR49BmamSqs841Z8myZIlp6xDkUEX4Q6lxvPy8lbX830sWQ3SNvpX4/z5c+jQoSPS pc+IeZSHOCDh7FicmnLdho34p3NX1K5Z3cTW/Lj8K2UcavK/Rnj45Ck+U9ak8ZRViNN2misd/26P Q0eOqqxLDo7OKg1g0qQ6jEQEAUEg+BEQQg5+jKWGEEZg5/ZtqF2vvh8tEiVNgdbNm+LSxQtEjq76 74oVK47NlB4yatQoqFqxAq7evO3nvp69/qU8t8MCbNGgAQNw+PBhvHztFmiLOW1g167dwfRetXqt 30KGJwr79+3F05evkSpVasSJE+e3ysuRIyfOnjun2sDyifJZiwgCgoD1EBBCth7WUlMIIaDlaubq lyxZihw5slM+26+0ip2La9dvIH+BQnB7/QI3b9/BwYMHsJ4IulnTxrQq/qo0rlixMkaNGqH+9vH5 8lMrHj9+pPISc35cFl5havL8+XPcpZV2xEiRkStnDso/HAlODvb4TPVzjl1Nzpw+BS9vH5XwPm5c 44k1Ck0caAaA8hUqImOGHykV3755gxs3byJP3rxwpNSBx44dU1UVKFDAT+7jc2fPwMvnKwrkz4fm LVvCwcEOR44eoxVyRJWfV0QQEASsh4AQsvWwlppCCIEIESLoa+a8tFl8czlPmTpF//mWTa6oUq2G ev/q1Wv1LyeeZ4lNK0/tHv9NGDFsKObNm4c79+7rv9LqmzBuLObMnUekfx3OlAO63V/tUKZsGbhQ PuvP7h/Aea15hT502HCsXr1a3Z8te3a0a9ceKZImxrYdO4nIXWhFPhzr1qwic/IxRIseE4MHDfgJ Sa5z5YoVOH7iBBGuHXbt2IYr166jPE0mIjnZY4PrRnVPm7btMI1M5k8ePcTYceMxl0zrnp+9Ubdu XZp0jFamehFBQBAIGQSEkEMGd6k1hBAoXryYItqixUrgv62b9VqcPHlS/3fVqpXV3xo3rVi+FBvW r1Wf7dq1m1aZukT1ly5exKCBA+D15ZtaRZ87exLPnr+Es7Mz7ty+TcQ5EO8+fML0GbNw5MBuTJgw DkuXLafVuY+639PTE5s2uoJX0bPnzMPuHVuxeu16zF+4BIXyZsekyVMRwcEZnTp1wpjRo3Di9DmU LVcxQOS4TtcN67FqjU7PuHHjInasWNj+3xa4RI6CcuXKYffuXZg1czoyZcqIQ/v2YC1ZAqrWqI1q Fcth0ZIltF/uJaviEBqXUq0gwAgIIcs4CFcI/PNPJ6ROnQoJEibSt3vc2DEYMkxnkq5XryHix4ur HLmIktVnufPkRcsWzdXfKVOm0N83e/ZMRcbxEybFViL3Rg3qYfnK1bT/HBWLFi1UZOzo6IQ9RIT7 9u5R9716+QyRnZ3U3/ZkEu7Tb4By7urTuxcOHj6iPrej1W6Llm2wbt16vH3/ATWqVVNkzDJgQL8A +4v15XpZkqdMg727d6Jp40Y4TObnOtSmhfNmIW6s6Hjt5o63b93w9avOHH+Q9qDTEh5btm5FlMiR 6b4dAZYvHwoCgkDwIyCEHPwYSw02hEBL2idlQtZk9MiR6Nm7t3rb9M+WWDh/jvpb86rmv7NlywG+ z7/Y+5rCNRP1t28/zL1MqpqwB3QVIlVnJ2d88vCE65qV6itHJ0fMmz0LXXv0RLRo0eFC5mkWXqlm yZoF0aNFxSPyoD5+4ji4tLTpMyBO7FhBohkvfgJy8kpJTlmf1LW8IueXtuJ3dHLCjNlzEDdBf9yj /e1xY0dj7pxZ2H/gIGJEjx5k+XKBICAIBA8CQsjBg6uUakMIGDp1nT9/nsyyTG8RyEHLW+8xXbBQ EfTq0Q0PHz4kxyZHJEgQ33eVDLx48RzsHc3iRGSWOHFi9XdcIj52fHr96jnGjB0HDz0BfiGTcTwd 6TpHwsRJkxA3TmyqMgIuXriAtSuWqu/ekRPYnOmT8P79e9Rr8D94fnDDXapHW722a/832v3dQd3H bShZshTSpUsXKLJaO318dCZxTfhzw6Nbn8lU7kQOZaNHj8b+vXuxa/cepcMnz8+wJ4czEUFAEAgZ BISQQwZ3qdWKCBiudmvX9j1qZOdIzk525NDkpTQ5fuwIMmfOpFbG+QoUxoljh5UnNsumjRvUiyVr tpxEqmfV3126dMOsGdPx6Olz9OjeTd+il69e4a927XDjxjVMmTYDadOk9v3ODpUqV6E9bPJe/vqN nLsio36Dhhg+cjRmz5ymv5/PKrPUqVcP8+cvwOmzZxE5SjT8UbLEL1H7QueSWTRC1v798bmuXJ5E NPlfA2zZtlNfXtp06ZEsSWLcvnrRij0jVQkCgoAhAkLIMh7CPAKly5bD8ePHVTt59cmrRfZE5oVy BN+jPUzEGnFHjRpNXbuOPJM9aNXI12ur1sjkIKVJJJdIRGo7lHMW36sdE3KhvVg7chybPHU6GjVu SsSuHZWKQObvbOTwdVMdcUpDR5xix4pJ55FrqvvZ9M0vvp+FzdhZMmdUhOxMK+26dWv/1FeaXkzi 7K39F62qNR1XrFxFJnIPOp8cV6369x86oiYZSZIkhTuV1auPm6qPndw4AEiiRInwzdeurZUb5geH NFAQsCEEhJBtqDNEleBBIFbs2MhPL1Mla7bsQd7CBPsryZ9f55FtKDly5vLzPqBr+ILDhw5i4ZJl 6tp69eviC5miHQzOLvPn9nY6E/MhurZnjx4wLCuLv6hiuXPn0debOPEPpzbtw+XLluq9tNnhTEQQ EASsi4AQsnXxltoEAaMRiB07DooWLaq8vMePG8dbyX7EngJ+bNu5G95E1LxKjxJF5xRmruTImRNs up44cRIVEQEpUiQ3tyi5TxAQBMxAQAjZDNDkFkHAGghkz5GDIocdDLQqNjenSq3tT/++RpkyZf79 QqQEQUAQMBsBIWSzoZMbBQFBQBAQBAQByyEghGw5LKUkQUAQEAQEAUHAbASEkM2GTm4UBAQBQUAQ EAQsh4AQsuWwlJIEAUFAEBAEBAGzERBCNhs6uVEQEAQEAUFAELAcAkLIlsNSShIEBAFBQBAQBMxG QAjZbOjkRkFAEBAEBAFBwHIICCFbDkspSRAQBAQBQUAQMBsBIWSzoZMbBQFBQBAQBAQByyHwS0LW guVbrjopSRAQBAQBQUAQCJ8IaLnTA2t9oIRM2V6iSMaX8DlopNWCgCAgCAgClkWAyfjz58+xYsaM 6S8q/Y96AiVkuvG/6dOnu3tQ+jYRQUAQEAQEAUFAEDAfAU5zSrzqPnDgQO93794FWFCghEzm6uVu bm7Lza9e7hQEBAFBQBAQBAQBQwQCI2O+Rpy6ZKwIAoKAICAICAI2gIAQsg10gqggCAgCgoAgIAgI IcsYEAQEAUFAEBAEbAABIWQb6ARRQRAQBAQBQUAQEEKWMSAICAKCgCAgCNgAAv8H5AahAsq+KYAA AAAASUVORK5CYII= ------=_NextPart_000_0062_01CAF128.6E7C82C0-- From bmschwar@fas.harvard.edu Tue May 11 09:30:36 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F8F73A6C42 for ; Tue, 11 May 2010 09:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.68 X-Spam-Level: X-Spam-Status: No, score=-4.68 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gP1qcns+CuK7 for ; Tue, 11 May 2010 09:30:34 -0700 (PDT) Received: from us20.unix.fas.harvard.edu (us20.unix.fas.harvard.edu [140.247.35.200]) by core3.amsl.com (Postfix) with ESMTP id 5FA463A6BE6 for ; Tue, 11 May 2010 09:30:30 -0700 (PDT) Received: from [172.23.141.103] (bwhmaincampuspat25.partners.org [170.223.207.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar) by us20.unix.fas.harvard.edu (Postfix) with ESMTPSA id 8DFA3110686; Tue, 11 May 2010 12:30:19 -0400 (EDT) From: Ben Schwartz To: Christian Hoene In-Reply-To: <006101caf117$aaf3b2c0$00db1840$@de> References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> <20100510232234.16632o6l2ecu3wyy@mail.skype.net> <006101caf117$aaf3b2c0$00db1840$@de> Content-Type: text/plain; charset="UTF-8" Date: Tue, 11 May 2010 12:30:15 -0400 Message-ID: <1273595415.1684.33.camel@dell-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 16:30:36 -0000 On Tue, 2010-05-11 at 16:38 +0200, Christian Hoene wrote: > Until 400ms quality is still acceptable (about toll quality). The > ITU-T G.107 quality model reflects this opinion. > > However, in the recent years, new results have shown that the impact > of delay on conversation quality is NOT as strong as assumed. I have been unable to locate the paper that is the source of these claims. However, I will note that (1) The results conflict with common sense. A round-trip delay of 800 ms makes normal conversation extremely irritating in practice. I'm not surprised these results don't show up in laboratory tests, because fast conversations with interjections and rapid responses typically require a social context not available in a lab test. It's possible that the ITU regards "extremely irritating" as "acceptable", since effective conversation is still possible. In that case, I would say that the working group intends to enable applications with much better than "acceptable" quality. (2) Tests may have been done in G.711 narrowband, which introduces its own intelligibility problems and reduces quality expectation. Higher fidelity makes latency more apparent. Similarly, the equipment used may have introduced quality impairments that make the delay merely one problem among many. (3) I presume the tests were done with careful equipment setup to avoid echo. The perceived quality impact of echo at 200 ms one-way delay is enormous, as shown in http://downloads.hindawi.com/journals/asp/2008/185248.pdf Using an echo-canceller impairs quality significantly. Imperfect echo cancellation leaves some residual artifact, which is also irritating at long delays. The tests (even in the paper above) were performed using a telephone handset and earpiece. High-quality telephony with a freestanding speaker instead of an earpiece demands especially low delay due to the difficulties with echo cancellation. --Ben From tme@americafree.tv Tue May 11 09:48:45 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B9AF3A6933 for ; Tue, 11 May 2010 09:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.565 X-Spam-Level: X-Spam-Status: No, score=-100.565 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1RhJoAkN4Aw for ; Tue, 11 May 2010 09:48:44 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 0BD083A67CC for ; Tue, 11 May 2010 09:48:43 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id CFD6870DAF07; Tue, 11 May 2010 12:48:31 -0400 (EDT) Message-Id: <2B114368-93C0-410B-AB66-53CA33E921A8@americafree.tv> From: Marshall Eubanks To: Ben Schwartz In-Reply-To: <1273595415.1684.33.camel@dell-desktop> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 11 May 2010 12:48:29 -0400 References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> <20100510232234.16632o6l2ecu3wyy@mail.skype.net> <006101caf117$aaf3b2c0$00db1840$@de> <1273595415.1684.33.camel@dell-desktop> X-Mailer: Apple Mail (2.936) Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 16:48:45 -0000 On May 11, 2010, at 12:30 PM, Ben Schwartz wrote: > On Tue, 2010-05-11 at 16:38 +0200, Christian Hoene wrote: >> Until 400ms quality is still acceptable (about toll quality). The >> ITU-T G.107 quality model reflects this opinion. >> >> However, in the recent years, new results have shown that the impact >> of delay on conversation quality is NOT as strong as assumed. > > I have been unable to locate the paper that is the source of these > claims. However, I will note that > As a point of order, I object to any graphs without an available paper behind them. > (1) The results conflict with common sense. A round-trip delay of 800 > ms makes normal conversation extremely irritating in practice. I'm > not > surprised these results don't show up in laboratory tests, because > fast > conversations with interjections and rapid responses typically > require a > social context not available in a lab test. > This depends a lot on what sort of discussion is at issue (and, also on the culture of the participants). For example, in my experience telepresence sessions tend to be structured meetings and can typically tolerate even half second delays without too much disruption, while for a one-on-one conversation on the same equipment the same delay can be pretty objectionable. Having said that, I myself also find the previously attached graphs a little odd, and want to see a written description of just what sort of experiments they describe. > It's possible that the ITU regards "extremely irritating" as > "acceptable", since effective conversation is still possible. In that > case, I would say that the working group intends to enable > applications > with much better than "acceptable" quality. > > (2) Tests may have been done in G.711 narrowband, which introduces its > own intelligibility problems and reduces quality expectation. Higher > fidelity makes latency more apparent. Similarly, the equipment used > may > have introduced quality impairments that make the delay merely one > problem among many. Again, without the papers behind them, we are wasting our time having such discussions. Regards Marshall P.S. This thread has wandered far from multicast... > > (3) I presume the tests were done with careful equipment setup to > avoid > echo. The perceived quality impact of echo at 200 ms one-way delay is > enormous, as shown in > > http://downloads.hindawi.com/journals/asp/2008/185248.pdf > > Using an echo-canceller impairs quality significantly. Imperfect echo > cancellation leaves some residual artifact, which is also irritating > at > long delays. > > The tests (even in the paper above) were performed using a telephone > handset and earpiece. High-quality telephony with a freestanding > speaker instead of an earpiece demands especially low delay due to the > difficulties with echo cancellation. > > --Ben > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From br@brianrosen.net Tue May 11 10:23:41 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C11373A6D33 for ; Tue, 11 May 2010 10:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.038 X-Spam-Level: X-Spam-Status: No, score=-0.038 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Que4O-MUw80c for ; Tue, 11 May 2010 10:23:38 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id 1414C3A6960 for ; Tue, 11 May 2010 10:22:13 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.74]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1OBt9T-0007FN-V2; Tue, 11 May 2010 12:21:52 -0500 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Tue, 11 May 2010 13:21:56 -0400 From: Brian Rosen To: Ben Schwartz , Christian Hoene Message-ID: Thread-Topic: [codec] #16: Multicast? Thread-Index: AcrxLnSSfKoFo8Pq2U2anBoBkEol1A== In-Reply-To: <1273595415.1684.33.camel@dell-desktop> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 17:23:41 -0000 I agree with this. I was in a group that did some research on this (unpublished, unfortunately) and we confirmed that there is a cliff, around 500 ms round trip, after which conversation is impaired. It is remarkably consistent, is more or less independent of culture (with one interesting exception), and is really a cliff: under it and further improvement is hard to notice, over it and conversation is impaired, and the difference between say 750 and 1500ms isn't all that significant. Engineers who believe delay is a "less is better" quantity need to be educated that it is not. It is a threshold. The interesting exception has to do where you notice the impairment first. It is when you argue. Turn-taking is what is impaired, and arguing requires rapid turn-taking. So the exception is in cultures where arguing verbally is discouraged. Politeness masks the delay, somewhat. Brian On 5/11/10 12:30 PM, "Ben Schwartz" wrote: > On Tue, 2010-05-11 at 16:38 +0200, Christian Hoene wrote: >> Until 400ms quality is still acceptable (about toll quality). The >> ITU-T G.107 quality model reflects this opinion. >> >> However, in the recent years, new results have shown that the impact >> of delay on conversation quality is NOT as strong as assumed. > > I have been unable to locate the paper that is the source of these > claims. However, I will note that > > (1) The results conflict with common sense. A round-trip delay of 800 > ms makes normal conversation extremely irritating in practice. I'm not > surprised these results don't show up in laboratory tests, because fast > conversations with interjections and rapid responses typically require a > social context not available in a lab test. > > It's possible that the ITU regards "extremely irritating" as > "acceptable", since effective conversation is still possible. In that > case, I would say that the working group intends to enable applications > with much better than "acceptable" quality. > > (2) Tests may have been done in G.711 narrowband, which introduces its > own intelligibility problems and reduces quality expectation. Higher > fidelity makes latency more apparent. Similarly, the equipment used may > have introduced quality impairments that make the delay merely one > problem among many. > > (3) I presume the tests were done with careful equipment setup to avoid > echo. The perceived quality impact of echo at 200 ms one-way delay is > enormous, as shown in > > http://downloads.hindawi.com/journals/asp/2008/185248.pdf > > Using an echo-canceller impairs quality significantly. Imperfect echo > cancellation leaves some residual artifact, which is also irritating at > long delays. > > The tests (even in the paper above) were performed using a telephone > handset and earpiece. High-quality telephony with a freestanding > speaker instead of an earpiece demands especially low delay due to the > difficulties with echo cancellation. > > --Ben > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From hoene@uni-tuebingen.de Tue May 11 10:47:58 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A6FF28C223 for ; Tue, 11 May 2010 10:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttwaGctAIXvG for ; Tue, 11 May 2010 10:47:57 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id A3EEC28C1E9 for ; Tue, 11 May 2010 10:47:56 -0700 (PDT) Received: from hoeneT60 ([178.2.215.148]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4BHla1Q002100 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 May 2010 19:47:42 +0200 From: "Christian Hoene" To: "'Marshall Eubanks'" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> <20100510232234.16632o6l2ecu3wyy@mail.skype.net> <006101caf117$aaf3b2c0$00db1840$@de> <1273595415.1684.33.camel@dell-desktop> <2B114368-93C0-410B-AB66-53CA33E921A8@americafree.tv> In-Reply-To: <2B114368-93C0-410B-AB66-53CA33E921A8@americafree.tv> Date: Tue, 11 May 2010 19:47:31 +0200 Message-ID: <009f01caf132$0df158e0$29d40aa0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrxKdJwmS5c5MCnS/Wh6L1AC6/79QACBipA Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.236; VDF: 7.10.7.90; host: mx05); id=5136-oFVKwe Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 17:47:58 -0000 Hi, I will ask the ITU-T SG12 chair and the authors, whether we can make = those documents public. With best regards, Christian --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ >-----Original Message----- >From: Marshall Eubanks [mailto:tme@americafree.tv] >Sent: Tuesday, May 11, 2010 6:48 PM >To: Ben Schwartz >Cc: Christian Hoene; codec@ietf.org >Subject: Re: [codec] #16: Multicast? > > >On May 11, 2010, at 12:30 PM, Ben Schwartz wrote: > >> On Tue, 2010-05-11 at 16:38 +0200, Christian Hoene wrote: >>> Until 400ms quality is still acceptable (about toll quality). The >>> ITU-T G.107 quality model reflects this opinion. >>> >>> However, in the recent years, new results have shown that the impact >>> of delay on conversation quality is NOT as strong as assumed. >> >> I have been unable to locate the paper that is the source of these >> claims. However, I will note that >> > >As a point of order, I object to any graphs without an available paper >behind them. > >> (1) The results conflict with common sense. A round-trip delay of = 800 >> ms makes normal conversation extremely irritating in practice. I'm >> not >> surprised these results don't show up in laboratory tests, because >> fast >> conversations with interjections and rapid responses typically >> require a >> social context not available in a lab test. >> > >This depends a lot on what sort of discussion is at issue (and, also >on the culture of the participants). > >For example, in my experience telepresence sessions tend to be >structured meetings and can typically tolerate even half second delays >without too much disruption, while for a one-on-one conversation on >the same equipment the same delay can be pretty objectionable. > >Having said that, I myself also find the previously attached graphs a >little odd, and want to see a written description of just what sort of >experiments they describe. > >> It's possible that the ITU regards "extremely irritating" as >> "acceptable", since effective conversation is still possible. In = that >> case, I would say that the working group intends to enable >> applications >> with much better than "acceptable" quality. >> >> (2) Tests may have been done in G.711 narrowband, which introduces = its >> own intelligibility problems and reduces quality expectation. Higher >> fidelity makes latency more apparent. Similarly, the equipment used >> may >> have introduced quality impairments that make the delay merely one >> problem among many. > >Again, without the papers behind them, we are wasting our time having >such discussions. > >Regards >Marshall > >P.S. This thread has wandered far from multicast... > > >> >> (3) I presume the tests were done with careful equipment setup to >> avoid >> echo. The perceived quality impact of echo at 200 ms one-way delay = is >> enormous, as shown in >> >> http://downloads.hindawi.com/journals/asp/2008/185248.pdf >> >> Using an echo-canceller impairs quality significantly. Imperfect = echo >> cancellation leaves some residual artifact, which is also irritating >> at >> long delays. >> >> The tests (even in the paper above) were performed using a telephone >> handset and earpiece. High-quality telephony with a freestanding >> speaker instead of an earpiece demands especially low delay due to = the >> difficulties with echo cancellation. >> >> --Ben >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> From jean-marc.valin@octasic.com Tue May 11 10:53:40 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 902B728C192 for ; Tue, 11 May 2010 10:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16S9hUWjR6p2 for ; Tue, 11 May 2010 10:53:39 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 087DD3A69E3 for ; Tue, 11 May 2010 10:53:38 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 May 2010 13:53:27 -0400 Message-ID: <4BE99997.2090307@octasic.com> Date: Tue, 11 May 2010 13:53:27 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Brian Rosen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 May 2010 17:53:27.0459 (UTC) FILETIME=[DBF7CF30:01CAF132] Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 17:53:40 -0000 Brian Rosen wrote: > Engineers who believe delay is a "less is better" quantity need to be > educated that it is not. It is a threshold. Considering that the network delay is not a constant, you no longer have an absolute cliff. So reducing the delay means you can increase the distance without falling off the cliff. Jean-Marc > On 5/11/10 12:30 PM, "Ben Schwartz" wrote: > >> On Tue, 2010-05-11 at 16:38 +0200, Christian Hoene wrote: >>> Until 400ms quality is still acceptable (about toll quality). The >>> ITU-T G.107 quality model reflects this opinion. >>> >>> However, in the recent years, new results have shown that the impact >>> of delay on conversation quality is NOT as strong as assumed. >> I have been unable to locate the paper that is the source of these >> claims. However, I will note that >> >> (1) The results conflict with common sense. A round-trip delay of 800 >> ms makes normal conversation extremely irritating in practice. I'm not >> surprised these results don't show up in laboratory tests, because fast >> conversations with interjections and rapid responses typically require a >> social context not available in a lab test. >> >> It's possible that the ITU regards "extremely irritating" as >> "acceptable", since effective conversation is still possible. In that >> case, I would say that the working group intends to enable applications >> with much better than "acceptable" quality. >> >> (2) Tests may have been done in G.711 narrowband, which introduces its >> own intelligibility problems and reduces quality expectation. Higher >> fidelity makes latency more apparent. Similarly, the equipment used may >> have introduced quality impairments that make the delay merely one >> problem among many. >> >> (3) I presume the tests were done with careful equipment setup to avoid >> echo. The perceived quality impact of echo at 200 ms one-way delay is >> enormous, as shown in >> >> http://downloads.hindawi.com/journals/asp/2008/185248.pdf >> >> Using an echo-canceller impairs quality significantly. Imperfect echo >> cancellation leaves some residual artifact, which is also irritating at >> long delays. >> >> The tests (even in the paper above) were performed using a telephone >> handset and earpiece. High-quality telephony with a freestanding >> speaker instead of an earpiece demands especially low delay due to the >> difficulties with echo cancellation. >> >> --Ben >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From bmschwar@fas.harvard.edu Tue May 11 11:06:28 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 110413A6A70 for ; Tue, 11 May 2010 11:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.03 X-Spam-Level: X-Spam-Status: No, score=-4.03 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZrfrCTBS5z8 for ; Tue, 11 May 2010 11:06:26 -0700 (PDT) Received: from us12.unix.fas.harvard.edu (us12.unix.fas.harvard.edu [140.247.35.203]) by core3.amsl.com (Postfix) with ESMTP id 65B923A69ED for ; Tue, 11 May 2010 11:06:26 -0700 (PDT) Received: from [172.23.141.103] (bwhmaincampuspat25.partners.org [170.223.207.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar) by us12.unix.fas.harvard.edu (Postfix) with ESMTPSA id 0D8B26653F4; Tue, 11 May 2010 14:06:15 -0400 (EDT) From: Ben Schwartz To: Marshall Eubanks In-Reply-To: <2B114368-93C0-410B-AB66-53CA33E921A8@americafree.tv> References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> <20100510232234.16632o6l2ecu3wyy@mail.skype.net> <006101caf117$aaf3b2c0$00db1840$@de> <1273595415.1684.33.camel@dell-desktop> <2B114368-93C0-410B-AB66-53CA33E921A8@americafree.tv> Content-Type: text/plain; charset="UTF-8" Date: Tue, 11 May 2010 14:06:14 -0400 Message-ID: <1273601174.1684.79.camel@dell-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Thresholds and delay. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 18:06:28 -0000 On Tue, 2010-05-11 at 12:48 -0400, Marshall Eubanks wrote: > As a point of order, I object to any graphs without an available paper > behind them. I have located the first paper mentioned by Christian Hoene at http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=81952 but of course it's paywalled. One test in that paper told trained subjects to "Take turns reading random numbers aloud as fast as possible", on a pair of handsets with narrowband uncompressed audio and no echo. Subjects were able to detect round-trip delays down to 90 ms. Conversational efficiency was impaired even with round-trip delay of 100 ms. Let me emphasize again that these delays are round-trip, not one-way, there is no echo, and the task, while designed to expose latency, is probably less demanding than musical performance. In the presence of echo, round-trip delay must be kept below 30 ms to ensure that the echo is perceived as sidetone, according to the Springer handbook of speech processing: (http://books.google.com/books?id=Slg10ekZBkAC&lpg=PA83&ots=wc9yM9WrCs&dq=sidetone%20delay%2030%20ms&lr&pg=PA84#v=onepage&q&f=false) Such low delays are clearly impossible on many paths, but for Boston to New York City (or London to Paris), ping times can be less than 18 ms, making echo->sidetone conversion just barely possible for a codec with 5ms frames. I accept Brian Rosen's claim that a slow conversation doesn't normally suffer greatly from round-trip latencies up to 500 ms, but under some circumstances much lower latencies are valuable. Let's make sure they're achievable for those who can use them. --Ben From rchen@broadcom.com Tue May 11 11:22:02 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 106043A6C34 for ; Tue, 11 May 2010 11:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.334 X-Spam-Level: X-Spam-Status: No, score=0.334 tagged_above=-999 required=5 tests=[AWL=-0.668, BAYES_50=0.001, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhba+-pQHvuU for ; Tue, 11 May 2010 11:21:50 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id A5AE03A6C36 for ; Tue, 11 May 2010 11:18:31 -0700 (PDT) Received: from [10.9.200.133] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 11 May 2010 11:15:39 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Tue, 11 May 2010 11:17:02 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Christian Hoene" , "'Koen Vos'" Date: Tue, 11 May 2010 11:15:30 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: Acrw0m8GNXZpDck0Qjy3nWpGN9Rz1gAQeaxwAAXDTKA= Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> <20100510232234.16632o6l2ecu3wyy@mail.skype.net> <006101caf117$aaf3b2c0$00db1840$@de> In-Reply-To: <006101caf117$aaf3b2c0$00db1840$@de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-cr-hashedpuzzle: C9zW D8NC Hotn J1mh MplF M25d RmVI RvQp YjPa dteL d37V ff5K gbYp gxmJ iSl9 kxmW; 3; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAaABvAGUAbgBlAEAAdQBuAGkALQB0AHUAZQBiAGkAbgBnAGUAbgAuAGQAZQA7AGsAbwBlAG4ALgB2AG8AcwBAAHMAawB5AHAAZQAuAG4AZQB0AA==; Sosha1_v1; 7; {5A4376BE-A677-4DCE-9A1D-90028296F3BF}; cgBjAGgAZQBuAEAAYgByAG8AYQBkAGMAbwBtAC4AYwBvAG0A; Tue, 11 May 2010 18:15:30 GMT; UgBFADoAIABbAGMAbwBkAGUAYwBdACAAIwAxADYAOgAgAE0AdQBsAHQAaQBjAGEAcwB0AD8A x-cr-puzzleid: {5A4376BE-A677-4DCE-9A1D-90028296F3BF} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67F7414120S121750474-01-01 Content-Type: multipart/related; boundary=_006_CB68DF4CFBEF4942881AD37AE1A7E8C74B90346104IRVEXCHCCR01c_; type="multipart/alternative" Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 18:22:02 -0000 --_006_CB68DF4CFBEF4942881AD37AE1A7E8C74B90346104IRVEXCHCCR01c_ Content-Type: multipart/alternative; boundary=_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B90346104IRVEXCHCCR01c_ Content-Transfer-Encoding: 7bit --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B90346104IRVEXCHCCR01c_ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Other than potential echo issues, the biggest problem with a one-way delay = longer than a few hundred ms is that such a long delay makes it very diffic= ult to interrupt each other, resulting in the start-stop-start-stop cycles = I previously talked about. Therefore, I agree with Ben that if the lab tes= t did not have echoes and did not involve the test subjects trying to inter= rupt each other, then the test results may appear more benign than what one= would experience in the real world. Note that the top curve in the first figure below is for "listening-only te= sts". Well, in that case there was no interaction/interruption at all, so = if there was no echoes, either, then it is no wonder that the curve stayed = essentially flat. I do wonder what made the curve go down at 1300 ms; I gu= ess to understand this we need to know what the lab set up was for this tes= t. Thus, I echo Marshall's opinion that we need the original paper/contrib= ution. My personal experience with the delay impairment is much worse than the mid= dle curve (MOS-CQS) would suggest and is close to the bottom curve (MOS-CQE= ). Back in early 1980s the phone calls I made from southern California to = East Asia were carried through geosynchronous satellites with a one-way del= ay slightly more than 500 ms (see http://en.wikipedia.org/wiki/Geostationar= y_orbit). I absolutely hated it, because turn-taking was severely impaired= and the only way to interrupt the person at the other side was to keep tal= king (rudely, I may say) until the other person finally stopped. Then, sta= rting in late 1980s undersea cables were used to carry my traditional circu= it-switched calls to the same person in East Asia, and all of a sudden the = delay was much shorter and interrupting each other felt as easy as face-to-= face conversation. It's a night-and-day difference! Even in early 2000s w= hen I used my cell phone to call my son's cell phone in another cellular ne= twork, I could tell that there was a significant delay that noticeably impa= ired our turn-taking and our ability to interrupt each other, and I didn't = like it at all. Now you know why I advocate low-delay voice communications= , have been working on low-delay speech coding for two decades, and have ev= en published a book chapter on low-delay speech coding :o) Raymond From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of C= hristian Hoene Sent: Tuesday, May 11, 2010 7:39 AM To: 'Koen Vos' Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? Hello, may I present some results of the ITU-T SG12 on the perceptual effects of d= elay? For many years, it was assumed that 150ms is the boundary for interactive v= oice conversations (see Nobuhiko Kitawaki, and Kenzo Itoh: Pure Delay Effec= ts on Speech Quality in Telecommunications, IEEE J. on Selected Areas in Co= mmun., Vol.9, No.4, pp.586-593, May 1991) Until 400ms quality is still acce= ptable (about toll quality). The ITU-T G.107 quality model reflects this op= inion. However, in the recent years, new results have shown that the impact of del= ay on conversation quality is NOT as strong as assumed. At the ITU-T, numer= ous contributions have been made on this issue: Contribution of BT "Comparison of E-Model and subjective test data for pure= -delay conditions" from 2007-01-08: [cid:image001.png@01CAF0F1.660D1B40] Legend: MOS-CQS are subjective conversational tests MOS-CQE is the E-Modell (G.107) MOS-LQO are result from listening-only tests. Also, LM Ericsson described very interesting results in "Investigation of t= he influence of pure delay, packet loss and audio-video synchronization for= different conversation tasks" from 2007-09-24. For example: [cid:image002.png@01CAF0F1.660D1B40] and [cid:image003.png@01CAF0F1.660D1B40] Overall, it seems that the limit of 150ms is greatly overestimated. A much = relaxed timing is allowed. Seeing these figures, I have to assume that the ITU-T G.107 standard was a = plot of the telcos to make life of VoIP vendors hard. Well done... With best regards, Christian Hoene --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ >-----Original Message----- >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Koen Vos >Sent: Tuesday, May 11, 2010 8:23 AM >To: bens@alum.mit.edu; Benjamin M. Schwartz >Cc: codec@ietf.org >Subject: Re: [codec] #16: Multicast? > >Quoting Benjamin M. Schwartz: > >> Quoting Koen Vos : >>> For typical VoIP applications, Moore's law has lessened the pressure >>> to reduce bitrates, delay and complexity, and has shifted the focus to >>> fidelity instead. >> >> I think this is a typo, and you mean "lessened the pressure to >> reduce bitrates and complexity, and has shifted the focus to >> fidelity and delay instead". > >Not a typo: codecs have become more wasteful with delay, while >delivering better fidelity. G.718 evolved out of AMR-WB and has more >than twice the delay. Same for G.729.1 versus G.729. This is not by >accident. > >The main rationale for codec delay being less important today is that >faster hardware has reduced end-to-end delay in every step along the >way. As a result, a typical VoIP connection now operates at a flatter >part of the "impairment-vs-delay" curve, meaning that reducing delay >by N ms at a given fidelity gives a smaller improvement to end users >today than it did some years ago. Therefore, the weight on minimizing >delay in the "codec design problem" has gone down, and the optimum >codec operating point has naturally shifted towards higher delay, in >favor of fidelity. > >I've mentioned before that average delay on Internet connections seems >to be 40% to 50% lower now than just 5 years ago, which is just one >contributor to lower end-to-end delay. That doesn't mean high-delay >connections don't exist - they do, for instance over dial-up or 3G. >But in those cases it's still better to use a moderate packet rate >(and bitrate), to minimize congestion risk. > >The confusion may come from the fact that the trade-off between >fidelity and delay changes towards high quality levels: once fidelity >saturates, delay gets priority. Even more so because such high >fidelity enables new, delay-sensitive applications like distributed >music performances. This is reflected in the ultra-low delay >requirements in the requirements document. > >To summarize, the case for using sub-20 ms frame sizes with >medium-fidelity quality is now weaker than ever, because the relative >importance of fidelity has gone up. > >koen. > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B90346104IRVEXCHCCR01c_ Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Other than potential echo issues, the biggest problem with a on= e-way delay longer than a few hundred ms is that such a long delay makes it very difficult to interrupt each other, resulting in the start-stop-start-stop cycles I previously talked about.=A0 Therefore, I agree with Ben that if th= e lab test did not have echoes and did not involve the test subjects trying to interrupt each other, then the test results may appear more benign than wha= t one would experience in the real world.=A0

 

Note that the top curve in the first figure below is for “= ;listening-only tests”.=A0 Well, in that case there was no interaction/interruption a= t all, so if there was no echoes, either, then it is no wonder that the curve stay= ed essentially flat.=A0 I do wonder what made the curve go down at 1300 ms; I = guess to understand this we need to know what the lab set up was for this test.=A0 T= hus, I echo Marshall’s opinion that we need the original paper/contribution.=

 

My personal experience with the delay impairment is much worse = than the middle curve (MOS-CQS) would suggest and is close to the bottom curve (MOS-CQE).=A0 Back in early 1980s the phone calls I made from southern Cali= fornia to East Asia were carried through geosynchronous satellites with a one-way delay slightly more than 500 ms (see http://en.wikiped= ia.org/wiki/Geostationary_orbit).=A0 I absolutely hated it, because turn-taking was severely impaired and the on= ly way to interrupt the person at the other side was to keep talking (rudely, = I may say) until the other person finally stopped.=A0 Then, starting in late = 1980s undersea cables were used to carry my traditional circuit-switched calls to the same person in East Asia, and all of a sudden the delay was much shorter and interrupting each other felt as easy as face-to-face conversation.=A0 It= 217;s a night-and-day difference!=A0 Even in early 2000s when I used my cell phon= e to call my son’s cell phone in another cellular network, I could tell th= at there was a significant delay that noticeably impaired our turn-taking and = our ability to interrupt each other, and I didn’t like it at all.=A0 Now = you know why I advocate low-delay voice communications, have been working on low-delay speech coding for two decades, and have even published a book cha= pter on low-delay speech coding :o)

 

Raymond

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Christian Hoene
Sent: Tuesday, May 11, 2010 7:39 AM
To: 'Koen Vos'
Cc: codec@ietf.org
Subject: Re: [codec] #16: Multicast?

 

Hello,

 

may I present some results of the ITU-T SG12 on the perceptual effects of delay?

For many years, it was assumed that 150ms is the bound= ary for interactive voice conversations (see Nobuhiko Kitawaki, and Kenzo Itoh: Pure Delay Effects on Speech Quality in Telecommunications, IEEE J. on Sele= cted Areas in Commun., Vol.9, No.4, pp.586-593, May 1991) Until 400ms quality is still acceptable (about toll quality). The ITU-T G.107 quality model reflec= ts this opinion.

However, in the recent years, new results have shown t= hat the impact of delay on conversation quality is NOT as strong as assumed. At= the ITU-T, numerous contributions have been made on this issue:

Contribution of BT “Comparison of E-Model and subjective test data for pure-delay conditions” from 2007-01-08:=

=

Legend:

MOS-CQS are subjective conversational tests=

MOS-CQE is the E-Modell (G.107)

MOS-LQO are result from listening-only tests.

 

Also, LM Ericsson described very interesting results i= n “Investigation of the influence of pure delay, packet loss and audio-video synchronization for different conversation tasks” from 2007-09-24. For example:

 

=

and

=

Overall, it seems that the limit of 150ms is greatly overestimated. A much relaxed timing is allowed.

Seeing these figures, I have to assume that the ITU-T = G.107 standard was a plot of the telcos to make life of VoIP vendors hard. Well done...

 

With best regards,

 

 Christian Hoene

 

 

 

 

---------------------------------------------------= ------------

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University= of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 = 2970532

http://www.net.uni-tuebingen.de/

 

 

>-----Original Message-----=

>From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Koen Vos

>Sent: Tuesday, May 11, 2010 8:2= 3 AM

>To: bens@alum.mit.edu; Benjamin= M. Schwartz

>Cc: codec@ietf.org

>Subject: Re: [codec] #16: Multi= cast?

> 

>Quoting Benjamin M. Schwartz:

> 

>> Quoting Koen Vos <koen.vos@skype.net>:

>>> For typical VoIP appli= cations, Moore's law has lessened the pressure

>>> to reduce bitrates, de= lay and complexity, and has shifted the focus to

>>> fidelity instead.=

>> 

>> I think this is a typo, an= d you mean "lessened the pressure to

>> reduce bitrates and comple= xity, and has shifted the focus to

>> fidelity and delay instead= ".

> 

>Not a typo: codecs have become = more wasteful with delay, while

>delivering better fidelity.&nbs= p; G.718 evolved out of AMR-WB and has more

>than twice the delay.  Sam= e for G.729.1 versus G.729.  This is not by

>accident.

> 

>The main rationale for codec de= lay being less important today is that

>faster hardware has reduced end= -to-end delay in every step along the

>way.  As a result, a typic= al VoIP connection now operates at a flatter

>part of the "impairment-vs-delay" curve, meaning that reducing delay

>by N ms at a given fidelity giv= es a smaller improvement to end users

>today than it did some years ag= o.  Therefore, the weight on minimizing

>delay in the "codec design problem" has gone down, and the optimum

>codec operating point has natur= ally shifted towards higher delay, in

>favor of fidelity.

> 

>I've mentioned before that aver= age delay on Internet connections seems

>to be 40% to 50% lower now than= just 5 years ago, which is just one

>contributor to lower end-to-end delay.  That doesn't mean high-delay

>connections don't exist - they = do, for instance over dial-up or 3G.

>But in those cases it's still b= etter to use a moderate packet rate

>(and bitrate), to minimize cong= estion risk.

> 

>The confusion may come from the= fact that the trade-off between

>fidelity and delay changes towa= rds high quality levels: once fidelity

>saturates, delay gets priority.=   Even more so because such high

>fidelity enables new, delay-sen= sitive applications like distributed

>music performances.  This = is reflected in the ultra-low delay

>requirements in the requirement= s document.

> 

>To summarize, the case for usin= g sub-20 ms frame sizes with

>medium-fidelity quality is now = weaker than ever, because the relative

>importance of fidelity has gone= up.

> 

>koen.

> 

>_______________________________= ________________

>codec mailing list

>codec@ietf.org

>https://www.ietf.org/mailman/li= stinfo/codec

--_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B90346104IRVEXCHCCR01c_-- --_006_CB68DF4CFBEF4942881AD37AE1A7E8C74B90346104IRVEXCHCCR01c_ Content-Type: image/png; name=image001.png Content-Description: image001.png Content-Disposition: inline; filename=image001.png; size=34038; creation-date="Tue, 11 May 2010 11:15:38 GMT"; modification-date="Tue, 11 May 2010 11:15:38 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAkMAAAExCAYAAAB/O6bMAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAIR2SURBVHhe 7Z0HfBTVE8dn90oujSRA6L0XQVBRUIoUARVEQLHwt6EUETWUEEIIIYRwhABGQQQbCoIVC4qACiIq TUHpSu8dAqRd2fKf2XAxCSkX0q7M+/zvL7nbfeX79vZ+O2/ejD42Nha4MAEmwASYABNgAkzAWwno vXXgPG4mwASYABNgAkyACRABFkN8HTABJsAEmAATYAJeTYDFkFdPPw+eCTABJsAEmAATYDHE1wAT YAJMgAkwASbg1QRcVgxNnjw5Cmfmf149Ozx4JsAEmAAT8FYCGTjw3lOnTj3vrQDKctwuK4YQQm18 NStLGNwWE2ACTIAJMAEXImBwob54dFdcWQzZPJo8D44JMAEmwASYQP4E0vEjlQGVDQFXFkNlQ4Bb YQJMgAkwASbABLyagAeIIRn2rl0B6/YcB5k0dOXG8OSAByDU16vnlQfPBJgAE2ACTIAJOEnA/cWQ dALeMy8Aa+8n4d56fqBUCAGD6OTo+TAmwASYABNgAkzA6wm4vRhSzx+Diw1uh3HDn4FWgV4/nwyA CTABJsAEmAATKCIBtxdD5w7shiN/fQczxl4Cf9DBvU+/DIM6NufQ2kW8EPhwJsAEmAATYALeSsDt xRBUbAHPDJ0GfZ/tBUGp+yE6YiYYgmbDo60q5pjTDz74AP79919QVVV7iaLnr6V501hpshVFAUEQ tJenFxqrN1zDjnn0lrn1tu+sN423cuXKMHr0aK/63rrTfdjtxVC1Vl3h+VbXkVdsBg10V2Hz7/tR DLXPMQ8dOnSA5s2bw6ZNm2Dr1q3w6quvutM83VRf16xZAydOnIAXXnjhps53t5OmTJkCzz//PNSu TSGqPLtMmjQJxo4dCyEhIZ490OujmzVrFnTr1g1uu+02jx7v999/D2fPnoUhQ4Z49Dgdg6MH1C++ +AKioijGrmeX3bt3Q1JSEowZM8azB+qmo3N7MbTn+/nw45XWEPZkR5wCO1xO94Wa9arcMB1NmzbV 3pMkCdLS0uCuu+5y0ylzvtsXL16E4OBgrxgrUWnWrBl07NgRqlWr5jwkNz2SrufOnTuDn5+fm46g aN1u0aIFtG/fHtq2bVu0E93s6HPnzmkPMN5wf6KpqVixIpBI8IbxksV6+fLlbnZFek933V4MVa5a FfZ8PR9mpeyBQNtFUO/qBg/dXT/fGbRarWC3271ihr1prA6hm5FBEew9v5Cop7F6ixii76zFYvH4 iaXvrM3mPfFmaU7pWvaGQvNqMHBAaVeda7cXQ1VvHwhzImvCl7/8A2pwKxg28CEIdftRuerlwv1i AkyACTABJuB5BDxCNgTWbw/P4IsLE2ACTIAJMAEmwASKSsAjxFBRB83HMwEmwASYABNgAkzAQYDF EF8LTIAJMAEmwASYgFcTYDHk1dPPg2cCTIAJMAEmwARYDPE1wASYABNgAkyACXg1ARZDXj39PHgm wASYABNgAkyAxRBfA0yACTABJsAEmIBXE2Ax5NXTz4NnAkyACTABJsAEWAzxNcAEmAATYAJMgAl4 NQEWQ149/Tx4JsAEmAATYAJMgMUQXwNMgAkwASbABJiAVxNgMeTV08+DZwJMgAkwASbABFgM8TXA BJgAE2ACTIAJeDUBFkNePf08eCbABJgAE2ACTIDFEF8DTIAJMAEmwASYgFcTYDHk1dPPg2cCTIAJ MAEmwARYDPE1wASYABNgAkyACXg1ARZDXj39PHgmwASYABNgAkyAxRBfA0yACTABJsAEmIBXE2Ax 5NXTz4NnAkyACTABJsAE3EYMbV/9Aew33gGPd7sl16zZ4NcP34IVe06DThQAqreGV194Eqr78+Qy ASbABJgAE2ACTKBwAm4hhjIOrYInnhoB9Uctv1EMWY/Cp0vWQa0Xx0Pvhv4gGwMhyKfwgfMRTIAJ MAEmwASYABMgAm4ghlLho/c+h9SgalC3svGGWVPOn4RrDRvBXS3rQdVKflA9NIRnlgkwASbABJgA E2ACThNweTG0b8V82KXeA+P/Z4e9lrQbBnbqnx1waPNP8OF8OwRKNmja60l4tm9nCBDzZuDj4wN6 vcsP2+kJLOhAo9EIBoOhROpyh0poXk0mkzt0tdh99Kaxak9tOLf03fX04m3fWW+6H3vD9evO30+X VgXylf3w7rpLMCpxPBx/42fY5xN4A+uAJj0g7rUe0LVbKxDgNEx8djQsC20Ew+6ukePYQ4cOwbVr 12DPnj1w8uRJ+Ouvv9x53pzq+7///gunTp3yirESkDNnzsC2bdugZs2aTvFx54POnj0LW7duheDg YHcehtN9p+t4165dIAjoF+jBhb6z58+f95rv7IEDB+D06dNeMV66frm4LgGXFkMbP3oDfv77KtSc Nxv++P5vOGhaDGu7tIDurapnEQ2p2wq61XX8WRnq+cqwf+cxgFxiaP369fDPP//A8ePHNTG0bNky 152VEuoZ3WiuXr0KOp2uhGp07Wr2798PK1asgKCgINfuaAn07uDBg7B8+XLw9fUtgdpcvwp6iLFY LLB7927X72wxekhiKDU11eNFnwPRxYsXtfuyN9yPSdA3aNCgGFcHn1qaBFxaDDXrOxwSm52GtDQL HAvxg7N+NaBKUM6b/9+fTYOPTraEWWP6I6c0OJXqAw1b1L6B2fPPP6+9R0/T69atgwkTJpQmV5eo e82aNUAWsZEjR7pEf0q7E+PGjYPIyEioVKlSaTdV7vW/8sorMGfOHK9Z8o2NjYUBAwZAq1atyp19 aXbg+++/1x7YRowYUZrNuEzdR48ehYULF4LZbHaZPpVWR/7++2/44osvSqt6rreYBFxaDIWi1ac7 vqhYdyyB9KCu0KpOMBzY+DVsTa0Dg3veBg3adQffrW/C2Ml/gb+SAZX7DIaBd9bKFws9ddETpjeU tLQ0yMjI8IahZl4jVqu2FOoNYshms2lWP28Yq2Nu6bvr6cXbvrMpKSna99Ybijdcv+48jy4thrKD 7TniNbhHF6y9ValOc7jVVkH7d4X6HSB2UnX4bccxUH0qwJ3t24J3LBy482XHfWcCTIAJMAEm4DoE 3EYMBVWpDQ5PkIq1mkLFbAzF4HrQuUs916HKPWECTIAJMAEmwATchoDbiCG3IcodZQJMgAkwASbA BNyKAIsht5ou7iwTYAJMgAkwASZQ0gRYDJU0Ua6PCTABJsAEmAATcCsCLIbcarq4s0yACTABJsAE mEBJE2AxVNJES6C+pUuXalFZ8yohISHwwgsvlEArXAUTYAJMgAkwASZABFgMueB1MHXqVKBoynkV iitDASQ9PS2BC04Ld4kJMAEmwAQ8lACLIRecWLL+5FcqVsweVMAFO89dYgJMgAkwASbgZgRYDLnZ hHF38ydA1jJvycPmbdcBz6u3zTiPlwmULQEWQ2XLm1srRQKyLEN6enoptuA6Vev1evDz83OdDpVi T2heKa2MuywNq6qqJVulJLo0T+5QKA0I9dXHx8cdust9ZAIlTsA9vqklPmyu0BMJUILLGTNmwAcf fOCJw8sxpkuXLsEff/wBnTt39vixHjhwAN566y2g5LTuUCRJgubNm8OiRYvgvvvuc4cuQ8+ePeHB Bx+EiRMnukV/uZNMoKQJsBgqaaIlUN+VK1fyrYUSG7rLE3IJoHC6ir1798LmzZu14w8dOgQNGzZ0 +lx3O3DLli3w7bffgiiK0KFDBzAYDO42hCL1d86cOZrFjwSRO2Q3f+edd+DUqVMwe/ZstxBD69ev 14Q19fnFF1+EgnwWizRxfDATcCMCLIZccLKGDBkCR48ehYsXL8Lnn3+u9ZCWROhGRSb4v/76C9q2 bVtoz00mExiNxkKP84QD3n77bY0XlXfffdctfjRvlvubb74JtKxB18akSZM0K4SnFhK5X331lTY8 CjkxdOhQaNCggcsOl65Buhap/Pzzz/Drr79Cp06dnO4vLVOV5XdWURSYO3cu2O12OHbsGHzyySfa fYYLE/A2AiyGXHDGx48fr/Vq1apVWWKI/CZq1qypWQImTJig+VC89tpr2k3MZrPlOYrt27fDmTNn YMOGDS44ypLpElnJyDJCAshRFi5cCAMHDtQYkXj0lEJjpSWYJUuWaEOiuadrITo62iN9pWheSQA5 RO6JEyfg/fffhwceeEDj4GqFLHU7d+6EHTt2aF2j7yVZh0jcWK1Wp7r7999/w4ULF8rkO0vXE/k2 ffnll1l9S0pKgieffBKCghxpsZ3qNh/EBNyeAIshF57C0aNHZ/WObqZjxoyBESNGwJ133gm0XDZy 5Eho0aKF9qSclyD6559/gJbcfvzxRxceZfG6Rjf01atXa5YSR0lOToawsDDo1q2bx4mh7D9cNN4V K1Zooqhdu3ZAT/meVK5evQrz58/PMaTExESwWCyac7IrFrLaZS/ffPMNUDgMepBxpuzbtw+uXbtW Jt9Z+u58+umnObpF8c1IgD777LNe46DvzLzwMZ5PgMWQi87xe++9B4cPH76hd127doVBgwZp75NZ e/ny5fDyyy/n6Tfyww8/aP4znmz2Jkfi7FYhBzBiExERAf7+/i46w0XvFl0P5DeTu9AyWWxsbNEr dPEzyEKa27JHwo8Cj0ZGRrpc70lY5LWbkYR6XFycU/0lazBtBBg+fLhTxxfnoD179sC8efNuqIL8 sg4ePKj53d1zzz3Qpk2b4jTD5zIBtyDAYsgFp4ksG451/Nzdox+IAQMGaNtg69atC71799Z+CMlK VKNGjRyHkwnc07eaT5kyRVsKzF1OnjwJ9BlZEjyl0HKYY8ko+5jIwZhStHiS7xA5iS9evPiGqSNx tGDBAujTpw+0atXKZaaWBMy0adPyXA5buXKltuR9//33F9rfsvzOkr8Z3Wvy+u6QtblKlSqa5WjZ smVw++23azvO2Lm60CnkA9yUAIshF5w48glx+B3k7h5ZPKZPnw6TJ0/WPqJlMlrjp+WEvASRCw6v xLpEjPJ6snU0QOZ+TxFDv/32m/ajlF+hJVVaLvSUsmnTJjh37lyewyHhQXPvamJo9+7defaXLEMk iJwRQ2U1f2Q1/vrrr/NtjoTo1q1boV+/frBr1y5ttxlZ48hSREt+tATNhQl4EgEWQy44m3Xq1IGP Pvooz57Rk3GzZs1yfEaC6H//+5/2xPzwww/Dbbfd5oKjKvkukZ/Uhx9+mBV1mv5NzrWhoaFaY56U uoTmnX6gyEmXCjkS03JpQECAx42VBtS3b9+seaS/P/vsM20HZePGjbXxulp8JbLK5fedpf66knCj /pBlmR668gvTUatWLY0zOX+TVYhe5H9IgpysdrTDj3IkkqN1/fr1S/7LzTUygTImwGKojIE70xwJ mqIWEkjPPfecZgm54447gLbne3oKA3Iappej0E4ccvwMDg4uKj6XP562Z2ffok1P6sOGDfPYmFPk r5I9VhT5S9EOQRL+rljIj2nw4MGu2LU8+3Qzlh36XpH1mQr5G5EgJx8uEkNPPPEEVKtWzW3Gzx1l ArkJeJQYktMvw1XJBBUreFaaAloWIGtRYYVuSrRcRstD9KpcuXKWJaGwcz3hc9plRD4QniiGcs8P jfXy5cuaM7E3FAqTQLvLuLgGgZYtW2phA6g4lqPJP/Ghhx7SltIqVKjgGh3lXjABJwl4jhiynYFX Bw+AjK7T4L1Xujs5fNc/jNb2+/fvD08//XSeO4nyGgE9oZL/yKxZs+CRRx5x/UFyD5kAE3BbAnS/ IRFEgpUexijQZGBgoMs5ubstYO54mRDwGDG0ZdksmP/tNnjmPs+JuExOl+QXQk9c5A9EEaUp0KIz hXaZ0bIRRavmwgSYABMoTQIkfuhFOzhpWz7FOCOfJAqcSeFAmjZtCrVr1y7NLnDdTKBYBDxCDGUc +RmW/abCE493gyDRUiwgrnIyBUqkdfjsW+MpOixFon7jjTec6mb79u21oHyUtoHEEd2suDABJsAE SpNAo0aNgF60meHPP//Uwgr89NNPmrM1xTyjgJmUdoQLE3AlAu4vhpSr8P47S+DWJydBhS2TYK1U cPoFCsLn6l9EsgjR8hb5heQuFH+IHKOdsRDR+XTzIX8j2hb70ksveVQsmtxsaOeLtwg+Gqs3+WXQ d9aTAmjm9yNAOQjJAuwJhXY+UrR8epGj9S+//KKFBaHr9q677tKS2NK/XTWaeEnPgTdcvyXNrCzr c3MxpMKW9xPg+5P14LXmfrBy+QW4WuUcXEm3Q7BfzkzelEmaQt1TfiMKyEf5f1y1UOwcunnkV8hC RLFLHE7V9G9HOo7sEXvJXE2h/clCRMHcaPs9bbunreeU3sOT8nYRK0qMSU623iAS6Ifl1Vdf9Zgf zsK+i7///ru29FK9evXCDnXrzw8cOKCl2qH/elIh8U7b+cmyTUv3FECUdqbRfYhyJ1KuOXqQofsV HeNp9yaay9OnT2sWMy6uScDNxZACl+0qVDachXnxcbBr4wE4H/AZ/PxAN+jfLmcuIHoKIVFAgcS2 bdumbUN31XL+/Hlth0ZeheKC0NZ7urlQKgoqPXr00NbkqWS/iXz//fea+CMRRDciOodC7derV09b x/c0QXT27FnNouZsHihXnX9n+kWC3psSapJA6NKlC9x6663O4HHbY2jDBAWbfOqpp9x2DPl1nO5d jsTKZOGmnZ+nTp2CtWvXav+mB7rHH39c2yFJ9zF6ICRh5CmFRCDlfuPimgTcXAzp4P4XzeAIcr/g 1b3we52RNwghQk8CgApZDih9g6sFQct+eXzwwQeaeKEggrkLWY3oiWrNmjVZ1i1ylCarCAXgox9I WkYjE3WTJk20p61bbrklqxq6CTluRGS+9qRC6QNat259Q1oSTxqjYyxk3aOcUY6gi544xuxjIosQ BTZ05e9tScwB5RKkhxZPHyexovRB5GBNwo9SfRw9ehQ+/vhjbQmN7k2uGlPqZueZdtuxGLpZeqV/ npuLoZyAWnYeCP7BBe9YoKcPMsm6ciEhRILIEXXY0VfaUeZI4NirV6+sIdBTMz1Z0X/ffvttLXs5 +ViQ9YD8huiHkyL6UiF/hPDwcC04I910PSkJIz1FkrXLG4pjrN4ihug761gK9uT5JWuIq9+fSpI/ fV/pvtWxY0ftRVZuetB78803gfynKIDszQShLck+llRd3nD9lhSr8qjHo8RQp4GjoFN5UCylNilz Pd0YKVkiOUznl8nasa2VukGxhRyFMmWTIKLltBEjRmhv07G0lERPnpT0lW42dJynR6supSniapkA EygmgewpQSiK9TPPPKPVuHnzZli3bp0WM41iGVGS2OxW7mI2y6czgRwEPEoMedrckoWIHL9JvFDg xaIWyidEUagpRQUFRaNCFiQKo0/ip0OHDrBx40YYMGCAFtSRnsDoyZTapRcXJsAEmEB5ESAfT3od OXJEs3iTpZwsoXQ/I2u3q+8KLi9u3O7NEeBfvJvjVmZnkan4ZoQQdZCWyBxxihxJS+m/8fHxWf3f vn275rBJO5PIAkXiidrs3j0zijdZjhyJT8ts0NwQE2ACTOA6AUozRBs/qNASGlm/aXcs+RmRuwDF L+LCBIpLgMVQcQm6+fmODPfkzEjOi2FhYZrViJ7EqGzatClrmz/lI7r//kx3dW/JieWq00v+Xp4S j8ZVGXO/XI8AiR/yK6IHPdoIQiKJltnIek47Ddmi7Xpz5i49YjHkLjNVyv2kGwktkS1cuBBGjx4N UVFRWou0Xf3YsWPavylukeN9WoJzBDikbOresJ29lKfA6eppRyRlcafdNyRQuTABbyJAD2sUwHDC hAlASaxpd/Ann3wCX331leZTREtrjt3D3sSFx1o8AiyGisfPo86mJTF6siJnbYr3QbGLyKGRXlRo yys5MlKhJTVaXqNCAoqCpVGhre0Uw4gKmbe5lCwB4tyvXz8tmi8F5vvuu++gcePGJdsI18YE3IQA BZ6lF92baMn/t99+05LF0oMaxVcjt4Dcy2gUey0mJgamTZvmFWE43GQqy72bLIbKfQpcqwO01Z4E 0ezZszVzNCWKzas89thjWW+TU7ZDGO3evRvmzJmjfUbRVh1LOWTe5qe14s01cab5ICFEhWKWkDCi 4JrMtnhs+Wz3J0BL/vS6cuWKtrxP9yGyIFG8tSFDhmQNkB7kFi1apIVq+Oijj9x/4DyCEiHAYqhE MHpWJWRqJp8hei1evFjbaVZQoS2v9KLSrFkzbf2eyrfffpsVJZvCBNAWf9oNQlYnCgpJpSTjHFGO I0/N/0MOowMHDtSCa2YvlGKGnN3JsZRD/XvW95BHc3MEgoODNd9GetEy2jfffKOFJXHsrHUkuqbv DEWFbtu27c01xGd5FAEWQx41nSU7mGHDhsG7776rBYCk7axFLY5Aj3Qe5U8jXxda5qGt/RQYkgrF EHHEOKLt//QUlz3uiLNtUt4fSrVCZnIKFeCOJb98TBQr6tFHH4UtW7bkOSzyHyIL0YoVK6Bhw4bu OHTuMxMoFQK0hPbyyy9rfkX0MEaJqykFCJWLFy/CW2+9lbVZpFQ6wJW6DQEWQ24zVeXT0RdeeEGL dXSzgsjRa7LY0It2rc2cOTNrMBRUzeFvtGzZMs1hm9b7+/Tpo4kienXu3LnAwdNNjcTAn3/+qfkN UPyRBx98sHyA5WqVlg8pwWhBhYQh+f6Q9SevQjdxEnsFlb1792pLm+QvwYUJMIGcBCidC1mladOB 40GMjqD72rhx47SHMC7eTYDFkHfPv1OjHzp0aJaFiJa4SnJLd7du3bL6QAKI8veQbwxZpByFEjlS odxUdAwV8muifpBIoGCRJISoUGh/6iPtLCGfp5sp+YmS7HVdvnwZaOnPmVJYBm5aMqQdfPnFSyHL GQk8eqolYZpXoThRtAwwceJETUxSxHHK++Qt6TqcmQc+xrsJ0IMC5X7LXmgH7YwZMzRrNRfvJsBi yLvn3+nRk4WInA5p6Sw6OrpUdjCRwHGkFpk6dWpW32j5i5bZaIv/2LFjtffJR4msP5Rn7Y8//sgx DhIztOT25ZdfQu/evbM+Ix8Bik9SUKElqZ07dxbKhfrpjPWJtr5TAtmSKLRrj4QR5ajLXsgiNGbM GO0tWiYkB1IKgUD5y8iPiJ56SXBlX7Ysif5wHUzAXQjQ0hjFJcqrkEM1LaWx75C7zGbp9JPFUOlw 9chan3vuOS3qK/0o07IUxRoqi0IZrB3F4cy9Z88ebRt/foUsTOTITcfT8hwtt9E2W4fjdn7nkXgh C0xhpbB6Cjv/Zj6nMZCPA+Wrc1jOsgshqpOSXVJ54IEHtP/Srprff/9dS2VAu9BIcJLViCxNFDiT gjdyYQKeTmD58uVw/vz5PFN4ULJYesCg71Z5fK89nb27jI/FkLvMlIv0k4IrkhWCfoTph5QSvpZl cdysaMmMMlu/9NJL+TZP1iTacn7fffdpIqCs+1paXGipjHaRkTB1WIRyt+XgdM899wC9qJCAJCf2 pKQkbVsx+VHUrVtXi9FCMaW4MAFPJUAPcgWlNSKL8c1s3PBUXt44LhZD3jjrxRwzbV0ls/K8efO0 qNWOlB7FrLZIp5O4GTlypGbxGDVqVJ7nkh8A3QQ9sZBJPyIiokhDc0Srvvvuu7XzKCYULatR9F5y QicfIwpUR/PboEGDItXNBzMBVybgWH535T5y38qXAIuh8uXvtq2THww57b7++uvaj2h5WV3IMuRY +nHAJKsI+TcVFh/JbeFjx0mEkm9UcTJ3UzwpetGSIm09pjpp+Y2sRrRFn56UyWqUfZnSnZlx35kA E2AC+RFgMcTXxk0TIJ8TshBNnz4dKOAhOVbTf8u6UEA1+iGnJSNHfjVPFkIlzZfmzGEJSkxM1Kr/ /PPPNZYU+oAsbCSKyLJEwpcdTUt6Brg+JsAEypsAi6HyngE3bz80NFTbmrphwwbNj4gEiZ+fX5mP ipbKqA+UpJF2vnEpHgEK8kiFYrJQnKP169dru/PIWkTBHWkpjUQo7W4jgcSFCTABJuDOBFgMufPs uUjfaanG4aRM+YAoZk55pMUg5262CJXsRUFLjiR4SRw5BNIPP/ygbd8PCwvTxBJZjFq0aKHtLqQd e1yYABNgAu5GgMWQu82YC/eXstWTlYCy3lNU15IMzujMsGnLOQVdpOCDXEqPAO1io0KxnMiBnZyw N2/eDL/++qsW24gsg2Sdo/+S4yoXJsAEmICrE2Ax5Ooz5Gb9ozg35IA7a9YszXLAEZDdbAKL0F2H 2CWrIL0osB0FxiSHbPIfI4thp06dtKU1csKmbfw3W8iviWPA3Cw9Po8JMIHCCLi8GDq+6TOY9elm EA014PkJY6BVpcxs5/8VK/y0YA58s/ccGPT4WY02MO7Fp6GGf2FD589LiwCl2KAdXpQdmrZqU7JE Lp5PgJYp6UWle/fuWkwj2tVH1iPaxk9WOxJNDkdsinPkTDl48KDmr8QRtJ2hxccwASZwMwRcWgyl HV0Dr0Quh6dmTYYqu76AyAlxMC9pMtTzF/4bq+UI3ij/hGZjJ8ODjfzBLpqgoulmUPA5JUmAkqvS ktmUKVNg4MCBTqWuKMn2ua7yJ0C51sg6SIWEEaU6+fnnn2HlypXatUFpQsgfiSKF51eOHz+uBcsj MUU7F7/44guoWrVq+Q+Oe8AEmIBHEXBpMSQYa8HYGdOg0x2NAeqfheiPZsGhSzKKof+6rZw7CSn1 a0HjUBMoKISa4b+5uAaBDh06AL0o4jFt1XY44LpG77gXZUmAhBG9HIEfyfGaMoZTfCNHFHFaYqW4 R3QMLYlRhvFevXrB/v37ta6SbxLlg/v+++9LLN9bWTLgtpgAE3BdAi4thvxqtIRONTCNwPrPYe6s 16BBz0joXCdnl0/8uxOObN4AXwZgkk97BtTu+DAMGdATgvIZGfk5eMtWYPLZcIXcU2QdoAzv9CPm yJlVGl8JmtfyiHNUGmMprE5ahiyPEAaF9cvZz0nsDBkyRDv88uXL2n/JavTZZ59pOdNoHindikMI Oerdtm2b5rj91VdfaelEXLVQyhS61h3Lhs7201W+s872t7jH0Tx7y/24rDeUFHduvO18lxZDjsnw D6kKPR8fBD/+ugHW7u8MvZsEZc1T8C19YfbbD2FQuEb43gWY9MxI+Khqc3ipS+0cc0l5mZKTk4Fu pocOHdKeMj29/P3339qTd3mPlX74GjdurKXvOHDgANASGjnZknWgJAstqdCOJlf+kSyp8dKSEwVE JGuLOxdyriZhR4UCP9LS2bfffquFZ8ivbNmyRbMQUVwrhwAuTBjS9Ub5pwoq5NtEr5stdJ2HhIRo flIUvPKOO+7Q/p2enq5tKnCm7NixAy5cuFDu31ln+loSxxw+fFizAJb3PaokxlJYHTt37izsEP68 HAm4tBiiH0u6wdS7tbP2OvZjd/hyzS4UQ5mZuakE1WgMd6H16PpfUAfj/e3fdwoglxgiEURPmfTF ox/N1atXlyP2smn6n3/+0eLBuMJYaR6bNWsGf/zxByxevBh69Oih7TSjjNElVWgnE2Vmp4CAnl5O nDihiSFPtITRmEjskG9RfuWvv/6CVatWaZZPCrZJIrigQsu1FJCzoEJhAAqLj0ViidKg5BZNFHyS RB2FlaCHLip//vmnlqbm+eef13bSOXOtUwLea9eulfl3lr6LFJqiMMFY0t8ryiRP9+SyvEfRXNE8 k0N/ccRvUVnQd7Z27ZwP6UWtg48vPQIuLYbO/Po2xP2gg7fih4IAl+GKFAzNmuQ0jf/1yRR470gz mBf5OFK6BidSfaBp6xu38DqC8dGPMf2IFDXJZelNQenVTMHxyAr24osvll4jN1EziSF6SqJo1YX9 +BSlevqxmThxovZ07umFbuRkffDU7eaUCoR2ItKyWe5CAujDDz+Exx+n73ymczZd5wUVcsDeu3dv gcc0atRIy8lWUCHBk1+uNrPZDGlpaTecTtZZyvnmTCGBRw9rFN27LMvp06c1x3QSCmVZaKwLFiyA adOmlWWzmoWarNVlWeiel9f1XJZ94LbyJ+DSYqhG2/ugzteR8MLYg1BJvQJVeo2AZ7o1hH9+/QI2 p9SFZx9oB0069oPqO5Pg5Yi/wE+1Qb2BQ2DgHfn7EtCPCJnMvaHQEyyZ6F2tkDCl7dL040E/eGQx KolCT7VkCfMGMUTCjywQ5F/jiYWWv0g0kygi/yBHITGydOnSHDvQaKnwtttuKxADfU6Wj4IKpRwh y2JhhfqTe4n333//hW+++SbPU8lXjixEy5Yty9oJR6Ijr7kr7lJdYX3P63MaM/k3kRikB6iy3K1H QrasrVH0cEgCzJE+6GaY3cw5ZPHj4roEXFoMCRUawkTzm/D37mMgGQLg1lubAWVB0je5AzraAzSq /rXaQlRUAmzbdxJUIx7TOvMYLq5NgG68dFOaP3++Fq24fv36rt1h7l2ZEyBnYtqF+MQTT2j/peUz 8sEpaCt+QZ10+Cbldwwt3dKrsLJr164blrwmTJhQ4Gm0REI/vo5lTeoL+RTl7hP5Q5FDuSNyN6U5 Kc3EuLTESPGb6KGJLBcDBgzQRJ2nRnGnHIYkhKiMHTtWi5geHh5e2JTz515AwKXFkMbfFApt7gjN MRVBVetBDrdR/2pw+x3VvGC6PGuItNOGlgMWLlyo5RRr2rSpZw2QR1NsAmRBIQsRWQ/69OkDjz32 WLHrLG4FZOXJXcjp+6mnnoLly5ff8Fm9evU0/6bsFlCyUpGwI+tt9kKihCzXZOGkQlYlCkFQUGnT po0W6bugUqNGjRt2H9LuPRKWZC13lI0bN2pWIvLXohhQpV3IqldWu6woThXtUMxexo8frwnSghz2 S5sB1+8aBFxfDLkGJ+5FKRGg6NQjRozQntaeffbZMl/HL6VhcbUlSIB+LNu1a4c7Ru8qwVpLtiqy +Hz66acwaNAgLVq2o9D1TZaW3EvB9AM8dOjQGzqR22eIRNORI0cK7CztGqVo7wUVWpLLLm6o3smT J2v+VrkL+VVS+IJnnnmmxHd85m6LfJXIGkYW4tIqtGNx69at+YpK8l0kX6+oqCgtdQwX7yTAYsg7 592lRk07LGjJjHyIaFs8Obd7S+wRl5oIF+4MWUtc0f8tOzKyYpE/E1mIKFI2Xddr1qwpkk9cbj8/ Ek2FOfrS54UFNKWdtCQ6HIWsUnkJIcfnlHiXxOftt99eqlcFbaAgh/jSTOhLvnWFWdfef/99iIyM LHMH8lKFy5UXiQCLoSLh4oNLi0CtWrVg5syZ2k4/2p5MT2uF+XiUVl+4XiZwswTIikWCiIRQSW4O uNn+OM6j+E30chRabiQrVn5O35RomXxqSrtQOAxyLCYBWZqFljZpSdAR4DN7WyQmySm+rHfSleZ4 ue6iE2AxVHRmfEYpEaCnRHLmJFM1CaJXX33VJSJol9JwuVoPJUCWjjlz5rj06KiPn3zyiSbYcvs5 zZgxo0yEEAEiIeRM/KXiwuzatatmraPlv+x+WhTok/yyaEMHF+8mwGLIu+ffJUdPjrJkFXr99de1 m7KnxtJxSfjcKa8hQFasjz76SAtfsGLFCm3cFLtq3LhxHsmABBEJn379+mlhKchSRpYxFkIeOd1F HhSLoSIj4xPKgkDv3r21uDC0HfmVV14B2mbNhQkwgZIlQIKIwhYMHjwYWrdu7bFCyEGNdt2RozsF eXz77bd5B2vJXk5uXRuLIbeePs/uPFmIaB2fdsrQ1vuyDAbn2WR5dEzgPwK0ZEaCyFvKfffdB/Ti wgSyE2AxxNeDSxO4//77NUFEgdEox1OXLl1cur/cOSbABJgAE3A/AiyG3G/OvK7HPXv21ERQUlKS Fg+EgsJxYQJMgAkwASZQUgRYDJUUSa6nVAmQzxA5dpIPEe02I4sRFybABJgAE2ACJUGAxVBJUOQ6 yoQALZfRdnvyIaKcQuRTlL1QFOCKFSuWSV+4ESbABJgAE/AcAiyGPGcuvWIkDgsRBYULCAiAs2fP AiXBpEJ5lRISErKy1rPTtVdcEjxIJsAEmECxCTgthpLMMfVSJH0lSeqxIza2g5QYF9M8VQJfDAgD sdHR24vdE66ACThJgJbJyEIUHR2tRa3OXn7//fesP8nPiHegOQmVD2MCTIAJeDGBQsXQ7t27dau+ /WayxQpDFVGsbvT7q3dC/LrOVhnCkJsfyApMiZvxpa/R8HZExNg1XsySh16GBGg7MC2LFVQ4nUcZ Tgg3xQSYABNwYwKFiqGfVq3qJEnyZEkVQBSEk0ZI6WCXpYky/o1P6EcEUOursnWAXRYr4G6fzWFh YTemQXZjQNx1JsAEmAATYAJMwLMJFCqGJEUeIysKCDrjOdFk6CpItg/taA0S9UYwmvwn6m0pDdNt 0jRVVXpgVPfWiOtXz0bGo2MCTIAJMAEmwAQ8iUChYkhVQcEXgE48HmgwXLNY06sr2p+603pf/V8G STqCFqJpoB0EgifB4bG4NwGDweDeA+DeMwEmwASYQJkQKFQMCYJ6Ef1V0fAjN7BZLJvtslqfNI8o 6g5LKReS7XZhIYkjURXWS1LG7jLpNTfCBJCAminA8y20y6xVq1bMigkwASbABJhAgQQKFUN6H9+p Ors0RLLbKqVbhEr0AyTofMBHL6iSRX/OKkuohAyKKurmRkaGX2beTKCsCFAi14IKJWQ8cOAADBky BAIDA8uqW9wOE2ACTIAJuBmBQsVQcnLyqQA/v0g0DT1tlZR0nc6QbvDxe6dKlZAfz544/o0o6v1F o8+c6MjwL8tt7LYLsGnLPoDAWtChTYNy6wY3XLYEhg0bBr169cpq9PXXX4dBgwZB9erVtXxmTZo0 gR9//BHmzZsHnTt3hnvuuadsO8itMQEmwASYgFsQKFQMxcbGyjiSBHphbKEOFsXe3ZKeXO3w4eQh IBq/gEbd3ogZ3MFWXqOVzu+F2VNnwj8BtcH/xHFY//AoGPdoO2BvkfKakbJrt27dukAvR/nmm2+g e/fuULly5az3nnzySdi1axe8/fbbcPz4cejfvz+YTKay6yS3xASYABNgAi5PoFAxRCNIionxyzCI 79sk6I1eGkFZo1LsAAd+ejY2bkNCTHTEkvIY7YldG+CkTwdYNGM4wKnv4J6n4+HeTl9Bh2rsy10e 81GebdpsNkhJSckhhqg/5Dc0d+5cWLx4MZA1aeLEidCsWbPy7Cq3zQSYABNgAi5EoFAxtHt3jM7q o//SZpN6KYIOvVYFDPkrnaYxoNvQY5IqdVBV4f34hMRrURHh35T12Op1HwFzuwNYUy7Dpu9/g4oN 2kCtCiyEynoe3KE9Ss/Ro0cPWLhwoeZ8PWrUKKhSpYo7dJ37yASYABNgAqVIoFAxtGalqaskWVEI 6cFg9F00KXJchKM/C8zmz5Jl+1GrXTLKdv0rZrN5Q2RkZHIp9veGqjNljwxbVr4HC5dvgca9x0JA AWtkFLWYohd7Q6HlIG8ZK80nbaX38/MrcGpr1KgBU6ZMgd9++w2mT58O999/fw6/I3e5Lmis/v7+ 7tLdYveTxltYxPFiN+ICFXjbd5a+r94SAsMbrl8X+ArddBcKFUO4dywMYy6CIOpP+ehN07K3NCIy 8sxsc3yCXVKicft9N73el/Yxb7jp3tz0iTro/Hg4dH50EIzq9xy82ag5TOrTMEdtCxYsgL1798LJ kyfh1KlTWoJPTy+HDh2Ca9euaTuqvKH88ssvcPnyZahQoUKBw6U0HXQDJutQREQEkK9RamoqNGjQ AK5cuQIKXfAuXtavXw+vvPKK1/g/bdq0Cfbt2wfVqlVz8ZkpXvcOHjyoXYv//vtv8Spyk7MvXbqk 3ZczMjLcpMc3383Tp0/z8vzN4yv1MwsVQ9l6QEaYvNafsr9XcOCXUhjO8b9+gsNKY7j3dnSk1dWG RlUC4MSFG41T/fr105ZINm/eDFu3btV+SDy9/PDDD1pG9+eff97Th6qNj4TMs88+C7Vq1XJqvKIo woQJE+DMmTMwf/58zd+Ils7oCc7Vb84XL17U/J+Cg4OdGqu7H2TH8PbdunWDtm3buvtQCuz/qlWr tAe15557zqPH6Rjc/v374YsvvvCK+/G2bdu0zRxcXJNAoWII4y2+hr8ZD6JvUA2rZJmEw8j6ls4z m1vbZHm8ghJIVGEtPmyX+UxbT/8NM99+H1KixkCVazvhsF9reLL3jYH2aLs1FfrhO3LkCDRq1Mg1 Z6QEe0VPXPQj4g1jJWwVK1aExo0bQ82aNYtEka6NWbNmwbJly2DNmjWaaG7atGmR6ijrg0NCQrQ+ ekv8JNohWL9+fY+/lh1C3lu+sxQrrFKlSh4/r3R/ICsYi6GyvlM6316hYqjXg5b1K1foV0s2qbfd mv5sTEzcBXSgPoNxXJqIoL6Aecr0gs4g6Qy6NzBJ6xXnmy6ZIxs/OA5mm96B95Z/DqIpGIZEx0Kb qujonU8hcSDLFC3A8wvdaAoLTOhJFGheaUfZzRSysIwcORJ++uknTRhRvCISRZhq5maqK/VzijPW Uu9cKTRA46XvrqcXb/vOetP92BuuX3f+fhYqhm65JVb+6fOYgYpBXGSzyw+gESic1sLo5iTTqplg 2IdiaDruJFtRXiCadx8Ks3BHGRcmUFwCJIDolZiYCBTBOj4+HqpWrVrcavl8JsAEmAATcGEChYoh 6ntYbGw6/uexpLiY5lcl6JblGCT6WGNjIt914fFx15jATREIDw+HPXv2aKKIltHGjh17U/XwSUyA CTABJuD6BAoVQ4lxcS0tkhSKWaBoiw2Jop+zhqVYhJiYmI74t06vNwmBgb7bcansmusPm3vIBAon 0LJlSxgzZgysXLkSpk2bpkW37tChQ+En8hFMgAkwASbgVgQKFUOqwTAD18T64D7kAgcmigKu6UO3 HGLJrVBwZ5nAjQQoLtHQoUPh22+/1Xa90C4u2tXkTTF++LpgAkyACXg6gULFEIqgTG9kQURnUnGn qkjbrkOhBE/kXSriy3g9NssZTwfG4/NOAn379oUHHnhAC9i4bt06LT6Rp8e88c6Z5lEzASbgjQQK FUM6UXkNt9e3FEAIFAW1Iu7DCtQZfJINOr9wiyX0YmzsYKs3guMxex8B3EEJcXFxWkC8qKgoLeYN xSXiwgSYABNgAu5NoFAxNDYi6kf0C2oeYlKqpNnFqWgeqiso0iMWe/JTgnBVioubtl2S7EvQZwgw AvW3kZFh59wbCfeeCRRMgOL7zJw5E3788UcgR+tHH30U7rzzTsbGBJgAE2ACbkqgUDFE44rN3E12 FF9P098J8fHD0YOoLa6fDbdJ9s74VmfyGcKIvj3w3yyG3PRi4G47T4ACxT3++OMQFBQEy5cvh08+ +USzGrEvkfMM+UgmwASYgKsQcEoMUWeTkmIC01LE0bIC9XDJ7ClZkRUF/YhEveFfRbJ/henswcdH OegqA+N+MIGyIECJXnv27AkbN26EiRMnwu233w5PP609M3BhAkyACTABNyFQqBhKNJtvs9qtb0qK WBGtP9VQBO3R6Y0/6kXDJAxwfO6RZYvP3rJvn3eEdHaTSeVuli0B8iXq1KmTllZg9erVMGfOHHjw wQddPqVH2VLi1pgAE2ACrkugUDGEPkKTVQXaZ26sFzbi/62XJS3lQT98qZ8PGqT/HMDXYPCBgAC/ uRhn6KjrDpd7xgRKj0CLFi2AXu+//z6888470L9/f2jfvj2QWOLCBJgAE2ACrkugcDGkqr5a91ER ybJyN/6LXjcU3HYPVqv4PX7AYsh155t7VgYEhgwZAikpKdqy2Q8//KBtw/fz8yuDlrkJJsAEmAAT uBkChYshALOiqssKq1zB1PWKklbmWesL6xd/zgTKgwBlk587dy5s3bpVSwDbp08feOSRR8qjK9wm E2ACTIAJFEKgUDEUHhm5nikyASZwcwRoyz0leiVfItyVqTlX169f/+Yq47OYABNgAkygVAgUKoZK pVWulAl4EYG6devC8OHD4eOPP4YlS5bAPffcA127dqVQFF5EgYfKBJgAE3BdAiyGXHduuGceRuCJ J56ACxcugNlshr1798Lzzz/PvkQeNsc8HCbABNyTAIsh95w37rWbEggNDdW23q9duxZGjBgBzz33 nGYl4sIEmAATYALlR4DFUPmx55a9mED37t3htttug48++kgTRq+++iqQUOLCBJgAE2ACZU+AxVDZ M+cWmYBGICQkRNtp9v3338PChQvh1ltvhb59+zIdJsAEmAATKGMCLIbKGDg3xwSyE6CAjCSAKFjj 0qVLteSvlPPs7rvzDOfF8JgAE2ACTKAUCLi8GEo+tAW+3/gvqMYQ6P5QX6ieGQIyW1Hh6J+/wKZ/ T4BdxjjZIfWgb8/OEOJTCrS4SiZQSgQaNmwIkydPhh07dmiCaNu2bdo2fEoEy4UJMAEmwARKl4BL i6H0A2vgqUdGQ+3HX4HQ/R/A69/8AUvmTYFmFbNtSZZPwoKoeDh7xwPQvjYqJV8rYPxHLkzALQnQ Ulnz5s3hvffeg/nz52vBGlu1anXDWEwmE1SsWNEtx8idZgJMgAm4GgGXFkNXLlyCzi/OgvEjHkBu D8Olnk/Csl8PwdR+jf/jeOEonK19F0yMGw1NOGyLq11f3J+bIGA0GuHFF1/Utt+/8cYb0KtXL6hZ sybs27cvq7adO3dqYikgIADTBwpaHjSKes2FCTABJsAEik7ApcVQjbufhPEO1wnrVbiWdg3q+hly jPLCob1wbN/3EPfiJfDX+cD9Q8fAQ23rgJAPiwoVKoCv7w1rbUUn5wZn0I+jN+XEImsJOSV7SiE/ ogULFsCvv/4KzzzzDPzzzz85hvbzzz9n/d27d2+PFkP0nfWGJUP6zvr7+3vKJVzoOIKDg4G+t95Q vOH6ded5dGkxlAVWPgczRr8M/zQbBLM718vB22aqCQ88OAr6DesLISn7ISFxOujCEqFPk5xPyZ99 9hkcPHgQDh8+DEeOHMGks7I7z5tTfd+zZw8kJydrL28ov/32G8THx3uUICKrDzlZ+/jk7wRHxyQk JEClSpU8dpop/MCpU6egTp06HjtGGtju3bvh6tWrcPHiRY8ep2Nw586d0/zjpk+f7vHjPXbsGIfP cOFZdn0xlHEaEsYPgW/lnvDV6+OgSq7fhJq394Hw268TrhwMDaRZsH79XhRDd+XATvmgHEsKGRkZ 0KZNGxeelpLpWnp6umYF84axErHNmzdr/jbVqlUrGYAuUguJHUrpQc7V+ZWWLVt63Lizj5XG3rhx Y21+PbmkpqZqQshbvrNHjx6F48ePe8V4DQaDJnS5uCYB1xZDykWYFf4c7KzyDKyd/CTkZUz9d90S 2JLeCp7uQ+JGglSrH4RWv3GppF27dtoMOJxOH3iA/JA8u9CP6KFDh8AbxkozSdYD2qbuicELaYdZ QaVHjx4ebTXZunUr0BjJwdyTi6IocOLECa/5zpKlnsSQN9yj6CHtyy+/9OTL163H5tJi6M/FMTDt u2uQOCsY1nz5BdhkI7Tteh9UuPYvHEgLgnta1Qd/owyrl8wCe0Y/qGA5A2kt28Gj9zTMd1LIWmK1 Wt160pztPFnAvGWsxMRmswE9WXuiGKKx5VfoiZOWye69914gC+gdd9zh7CXiNsfR+Om76+mFvrMW i8XTh5k1vrS0NO176w3FG65fd55HlxZDFVs+CDMiW4P19H44TDGEwA8a22TwSbsCl65mdr1Wx2ch KbgaLPtxH1zzrQQvvPw00A57LkzAkwjQj0Z+hX5MBgwYALTDbP/+/bBs2TJtOz6l/KhatWqB/kae xIjHwgSYABO4WQIuLYYatHsARmSubuUsNe6F2tneqXJLbwjDFxcm4KkE7rnnHs3q5Sjbt28H8hNy OFaTjwmJH1pmoS345Ig7c+ZMTQxVr14dOnXqBE2bNvVUPDwuJsAEmECxCLi0GCrWyPhkJuBBBF54 4QWgl6NQYtc5c+ZoO82yF1EUNZFEr8cee0wTRVu2bIGPP/4YLly4oAkmckTOK5CjB+HioTABJsAE ikSAxVCRcPHBTMA1CJAv2JUrVwrdTn/LLbcAvcgXhXYprVq1CigEQeXKlbX4LuRf9dRTT7nGoLgX TIAJMIFyIsBiqJzAc7NMoCwJUIiF2rVrw7Bhw7RmKQzByZMnISUlBYYPH64tp/Xs2VNbUqM8aVyY ABNgAt5EgMWQN802j5UJXCfQvn37LBaUyoO2c3/66adaag+9Xq9tYSdx5E0RzPniYAJMwHsJsBjy 3rnnkTMBjQClRKAX+RHR9t+NGzdq8alGjx4NjRo10gId0nZ9TwtmydPPBJgAE3AQYDHE1wITYAJZ BMgSRMEN6SVJkracRrnRKOgh+Sndf//9QDnTqlSpwtSYABNgAh5DgMWQx0wlD4QJlCwBWi7r2LGj 9qKdaJRbaf369dpyGgkiiub+8MMPe1Vi0ZIlzLUxASbgKgRYDLnKTHA/mIALE6BdZ/RyRLdeuXIl UF6pKVOmaBGEBw8erO1sY+drF55E7hoTYAL5EmAxxBcHE2ACRSbw4IMPauecOXNGCwb54YcfwuXL l6FZs2aaAzbFOerSpUuR6+UTmAATYALlQYDFUHlQ5zaZgIcQoK34VKZNm6b9lxJRUuqQP//8Ez75 5BNo3bo13HnnndCkSRMIDAz0kFHzMJgAE/A0AiyGPG1GeTxMoBwJUI40Rzl37pzmeE0+RuSYTbGO evXqpe1ayx05u7AuG41G7XwuTIAJMIHSIMBiqDSocp1MgAlogRz79u2rvWir/t69e+Hbb7+Ft956 S3PKrlmzJtx7771AKUSyF9rF9u+//2p51hzl1KlTWmoRElFBQUFQp04dJswEmAATKDECLIZKDCVX xASYQH4EyLGaXuRrRKlBaDltw4YNsG7dOi3Q43PPPaelCKlQoYImgigoZPbEtFTvu+++q1U/cOBA +OKLLxg2E2ACTKDECLAYKjGUXBETYAKFESArkL+/f1Y+tD179sClS5dg/vz5Wq41Wkaj3Wl2u72w qvhzJsAEmECJEWAxVGIouSImwASKSoB2nVHp3LmzFuTxvffeA/I1ImtRfiX3slpR2+TjmQATYAK5 CbAY4muCCTABlyBAW/IpaawsyzBnzhywWCx59quoztcuMTjuBBNgAi5NgMWQS08Pd44JeB+B5ORk UFU134HTtv1Ro0Zpn4eEhMATTzyRdSxFxeYcat53zfCImUBxCbAYKi5BPp8JMIESJUBCiPyG8itN mzaF8PBw7WMK9PjOO+9kHUrb72kXm6Pcdttt0KlTpxLtH1fGBJiA5xFgMeR5c8ojYgJuTYCWy8jC c/r06TzHQbvN6tatq31G/23btm3WcVevXoXVq1dn/b1lyxZYunRp1t8dOnTQAkBSoe35tL2fCxNg AkzAI8TQvrUfwecbjwLo/KHPc6PgtuoGnlkmwATclAAtfX399dewfPnyrBH88ssv0KhRI028UNDG /ArFIHrsscdyfEzWI0f58ccftVhHVEh0UTBHR6GYR47ca/SeyWRymiClIzl79myex1PIgOeff97p uvhAJsAEyp6A24uhf1bOgiGjl8Ej8WYI/OsdeOq5g7DkwyS4rSoLorK/nLhFJlAyBNq1awf0chRK 90HxhZo3b17kBsjK5CgklBxiiUTSH3/8kfXZ5s2bYfHixVl/kxXJ4X9EaUUKsiJNnToVDh8+nGff qA4WQ0WeNj6BCZQpAbcXQ/rg+jB+wUfQv1sLgEfvgv33D4SvthyF2x5qXKYguTEmwARKj0B6eroW h6gkC4kkimvkKPRvq9Wa9fdXX30F27dv1/4moZTdj4miapPvkqMEBATk27XsYqwk+891MQEmUHIE 3F4MNbpnIDRy8Dj1J+w4nwZP1gzOlxCZxr1la643jZUmnObVYPAOiyDF2sm+xFNytwTXrKms5tbH xycLwOOPP57175SUFDh48GDW3z///LOWiNZRzpw5ky+4gmIm5T7J276z9H31lvuxt9ybXPMOUniv 3F4MZQ3x4nZ4ekQ0+D88Dh6/LTTHyCms/4ULF7T3Tp48qUW8PXLkSOF03PwIckClcXvDWGmqaEs2 LVV4Q/RichSmH+fg4PyFv5tfvjm6T9/ZY8eOQaVKlcplWPRDVqNGjay2Bw0alCN3Gokjxz0mdwfJ opT7O0iWpNxilqxflION6jl69KhWTUEhBooLoiCRVprtZu83jZOWK73hHnX8+PHiThmfX4oEPEIM ZZzYCKNeHQdSpwnw2fh+8J9LZCa5ffv2ZfkCkBgikUCB3Ty9UHLMa9euaS9vKH///bcWwZjyW3l6 2blzp5bCoihOvu7MZOvWrZpIWL9+vcsMI7uYoKjZ+RUSchREMnv56aefclia6LOuXbtq4pbGSfnb 8hIrJPRL4t5F4s7Pzy/PNkgI0T2jLAQRsaH7c24+LjPJJdgR+t25GZ+3EuwCV1UAAbcXQ7bjWyAi PBKqD3oTpj3+3xbb7GPO7oz5+++/azfUqKgoj78wVq5cqWULf+WVVzx+rDTA0aNHQ0REhFcE3aOg gzNnztR+0LyhxMTEwMMPP5xjG70rjfuHH37I1zJUvXp1mDt3bo7ukuN2bofr8+fPw6+//qodR0KI YiZRQMnsyyu0o64kClkWKVZTWlraDdVRe2+99ZbWfmmXAwcOaHGi6Fr29ELBQmmXZEkVs9lcNTIy Mn8VnqshszmmqmSFNyUVdHiBgdHXf2dURHhMUqL57nSLPdwqoYGA0uAIPp/FxkR+TKcnJcbdm2aR X7VJKuXHoQ9VHx/fk1Zr+iuxsbFKUlJSsPVq8t1WFYbKKoh4jKrT+6iCyS86Ojxsd35jxb7XALst 2iIr1TOvd52q8/HZGB0ZkZj9nMTEuI42izrWJslZ7eNxZ2SrZRS2L2P7QdaU5LusMryYo329X2x0 ZNjfRWHt5mJIga/fmgQfbQOY2GkLJM1ZB7LqD/c+8iTcXjdv6wA5SHrDMgpdBN40Vhov5baiJ2pv KI6xeosYou9sfuk5XGG+e/fuDf/++2+eXaHlr9wl9245x/eVhAht0R86dKgmVBYtWpTjfkVWT0p0 6yj0N+1UK2q+tnHjxsG7776bL7q4uDioXbt2qaOlOaVr2RtKSV6/iXEx7SRVXB0z1fx17ORIp+I2 6CUIQEkxECi4O77sdoWik8bIkq2GoqoPZ84Bag5ROIT/+NgcF3O3XYHlGNbrv+2YeKLVhmlyBGM1 POYRKT0t0gZCuKxqYkkrWB+IVqF1nDlpAAqSHbnnNjExYZgi2V+zy0rWk5yqyiDZrA/HxiWEKFJ6 FAodNQ7HqCrwJbafze9FBZkCsur01H5/e0baOJsiRN3QviDcFmdO7B8dGZ65A8KJ4uZiCKDDM9Ph 8+6XITUlDYUQjdgEQb5uPywnpo4PYQJMwFUIvPbaazBgwIA8u+OsYCXn7SpVqmi71hzb+PEJOked JLj27NmT9R6J/5EjR+ZY0rrzzjuhceP/dtOSfxJF4s5eCloCo6XXooorV5kHb+gHCqF7rAqskBSl Igi2ITFTZ6THTp7wcqFj14MCNiDliT+QKqiKJOD1VVGUoDIKDs0olJkERzj/YVJMBVkVVsqKGgyC 7rTRYPjBZrMs0ovQHYOejlcE+8Bp5oRNOlmqKymqIIiGi6piv8/XqIu12eWHcCm3gaiTKOBXDjGE 7YUIihyOlh4/EPW4dVMfZRJtl7D5RXaJOiEP9fML+Q3b/1VQhdVYN45Rdwbb/wnbfxfb74LtRyqK +vC0+IQtOkWueb39ZGy/B7Y/EdsfKMtSHVE0DMb2vUUMiVC7WTt8FXoZ8AFMgAkwgVIjQMtanTt3 Lnb95A9UkE8QbefPvqWfGqRt/tkLLdlRcMnsZcWKFTn+piWbgkpgYGCxx8IVlDwBFELtUQh9iRab TGsNmk5AsY6KmTpdHzt54otOtSiIaPxR0QaktgfR92kQpaGKrNDf18UQ6C5mGIcoii0YRQ4IJt/x URFjHWHcNyTET+2VbpPvUiUFz9dhk3iuKPr4BIX6t4ALj+9JEUfLEsoRSf0td3+MevifJUPGtV4B DEbTtkmR4bPpmNnm+HQcyS2SJC9OT08+cV4xouCxVRRE3P1tMkXhct6i63VtSJg+tWeGVe6oKPKd OtxVi7Yoat+I7Qd1Cb3w5PrD4hgZFZIkq5uc4nH9IDahFIUWH8sEmAATcDECuTcMPPLII0Cv7GXd unU5/t60Kf/fCUp38uWXX+bYudeyZUto0KCBi43cu7qTEBvTBxeIlqEBJadS1QSRbURM7DQTKLqx sbGR/4VczwsROsjrMQwJLi3h0pQ9XQ9Yo2gEUbWDQqYhEXxQFvWnf4s6/IMsStmKqDOoIgoQGds1 6HTHdKK9rixZA61XLv26TRV3iXrjEjx8UWx0+KXczRtASsugJMwoyLD1aMfnYyOjPsN/00srieb4 JzPb14FRNORsnwQatq9g+4JOdxzbr4Pt+2P761Yna+0vwyrex/Yzt5A7WVgMOQmKD2MCTIAJuCuB bt265ej6smX0e5F3ITG0f/9+oNQmjrJt2zbIy/eJPm/Tpg107949z8qojoJ2PJbFjjXqWEEWN1oS pPhOrl5QEdRDHZGPyY4EhtoSx0B+OAWLITyARIaCfniCaB8sSUINvQF9qmU7GXm0gmIo+3ZrMr9k FWrJ8Ydq8p3kI1su2RVhkkSWIoDWimRJRJUSFRNn7hMS6HvCkpoyNsOe6Rem1wm3on+SVgP6ip3M j3mu9gXcQEF90KMvkQ1PvZ7FGW1ZJt8p2P5pbD8K278Hj2mF7Zux/ciYuITHQEpfQ/5Hzsyt618B zoyCj2ECTIAJMAGnCRTkzEtiiHbbZnfUpqCTJJDyKnv37oUpU6bk+Rn5QOW3A44S5lLsprIIRrhk yRKgHYl5FYoZlZiYYxOT0xzL8sDImNh5CXExFpsMC3FH2H8ChZx9RP0GkAP6xsaGORFHRUDNo8fJ tIWqgtwZF5nAIKh7sJaGOB5MyCeiShK24t/tVbS+oG9Sag4xpOICGL6hbR1LT2+fbtMvDTHpH82Q LLKkh1BBhiV2VW6DtX6KIhSd3oSs7czahjU8j5bkDAZfcogbSHXjrrWWV9OVunjtrUXxgr5Ewp94 XDNqX1HEkyEmaJ9mFz+PnTp9lVGQAkiz0QIdKnRq/wNs/wlsX8L2K2L7i7H9O0RB+c4YEEpZmfPO k5Nr8lgMleXVzG0xASbABFyAAFls8ksTQo7cFGcouxgiH6Lbb789z57T+0899VSen1FgUPJhyqtQ GAESUhQfLPcu0Lp168JDDz2U53nUF0fOOGdRUiqX/IIeFhQ93Nn6y+q4iOjYd3G5jJp7R1MkmhAy /gyGio/ETh7hhBDKPMcmq2/7COrDNrvUERfNQJFhtk5VY/Gz2qg+rFVEu/mETnjFjtYiW5oaHh+f WEMUpa/RxDbDapeaamJIp7uqSpaX8J8vJVvF7wBCBoXok3VpqmCh3UwoeAJtiu4vPOd///HBLf06 YaZVVmrYbdZuaL25z6RXLqGAWY1WwlBBZ9yakDB7sg/YJth0wv/ssgSWjKtjQNVHom/TNVWxPo97 2TQ5pdPrTqqyZRj+MQzbX4PtP4LtQ/r19smhCu1ROaxaBc0Ti6Gyuoq5HSbABJiAixAgSwglv82r kDN4SQUuJatQQbGRvvsOf0Ox5I6FRtHG582bl2f/KP5Rftv+q1ateoO/FFVSUOoad0trExGjCSI0 6AjvS4JhM1SoOSA27JkrTlxaZJTRfvP1oj5Apwh+tEwpiALuHtQHoE+133UP6oqHLXDepFeH4Vb8 t9EV+R67Pe0ePPZ1vDYMJHNQCe3ViaaeIkjTZUV6WlbtfbQcABbQowjSkeOzKOrmRoaHbcTm6JVV Zs2c0UaxWMeh0ArGxbIfrLQNXPufgEMSkxXF/4+wyLGXcWv9EOzae9j+/SiAOgkK+GWtd6HPkU01 RPgKUnudIL2M7WOSweRL2D6eouoFdOwWBXGOlHrBKauQxsQJgHwIE2ACTIAJeBAB2u7v7Jb/0hw2 CSVKsZJbMNHf+fkh0ZJd7t1xjj5SROsXX7xxU9WuXbtKcxhlXjcKokXmuLjjkl7c4aQQAszaaMf1 J4ohhEoFLqFYOCZIciVyZtbrlStoHaLke7gkplykgIr473cS4uMMkqyMt8mK5rOD2slm8PE5iRU9 GhkZdiYpMXEGmpX+QUvPcNQ0lPwBIw7p7Li5K17v77M6LzApqenj/Xx81gpgj0ELVW3SY+S8pDP4 /C7bMoZERo/QsiVHR8cuSjDH6tG1KQpjEhlRCCWjRUhBFy8TGn2qqlLGUtUYMNpXvToyQ1Yicrav m6H3N62KjpqQw/m6oIliMVTmlzE3yASYABNgAkTgZtKL0DLZ4MEUQibvQpG8cxcKMEnZBzypREZH ry3KeNBqQg7LzWkrumS5Ro5AC/Bv3JhlRdcbfBMAMw+jdpAsWQIiIip6/tKYmHf+8xZDNWTJkKZO naoZacLCw/fhf/ahP9asrL6g73VMdAR6Y+ddYuncqKjVzWNifhh03fWHQgRMjppwwzkRkTHvYPsf ZG8/KMhUNT1VHoN74FB82beER8dswvb/iyCqtT853/bz6xeLoaJcTXwsE2ACTIAJuDQBctrOXbLv jHPpzpdi567vqipIJORpRRkcG5vjHBRCN/QS6y6y+NiH1qfYrP1r+Q88d/t4JIm6MdnPuJn2c7fI YqgULz6umgkwASbABMqfQEFperwlhU/5z4Jr94DFkGvPD/eOCTABJsAEikmAAkbee++9edZCcZK4 MAEWQ3wNMAEmwASYgEcToLxx+eWO8+iB8+CcJsBiyGlUfCATYAJMgAkwASbgiQRYDHnirPKYmAAT YAJMgAkwAacJsBhyGhUfyASYABNgAkyACXgiARZDnjirPCYmwASYABNgAtkImM0x1TGkEObtwrRe GGXcYPLbPmnC+HFJiebO6Rb7FKuWOAyjSwu+S2JjIhbRqbMTYh/MsKlj7ZKamVIMs8EajaYTNlvG UMohZjabq4BiuRcDI47AoIcUmFHR6X3AoDdMiIwM35rfBCTGxTWWVGWKBdNyUL2CoFN0Pr6/R0eG Z2Wyp3MTEuJ62W1qhF3CWNjX29cZTacxOOPz2L4Fo1S/IsvwMOV+xZItXxtmLhN078TGRC119iJg MeQsKT6OCTABJsAEmICbEtBL4IeSooeWcgNfkl2hiNFgl2yVMZN818xhUaoN9U/6V3xczH2yAp/g K+C/IWPQRYpjrTNWiYnZ1CfAR55okYRX5etqhI6TJSul1vjKbE7sn5cgmp1gDrOBOgejWpPA0YqK gRIla3rX2GkJIYq91ujY2MF2c1xMV7sCn2L7Qdnbl+2YnEOnx/Y/7GvQQTP87Hrfs0+Mpo5+LcpU sRgqCi0+lgkwASbABJhAORGIi415VlHhVXzlLDr9eZAbYNb6wbZ8u4b5WMEGmLuU0nCpJECMZnNS VXyntoLhFskolFmtcPHDpJhgzKvxNQoRP0yVcdjHaFxptWa8rxehB2aWn6LI9l5Gn1//lmWlqoSd EXQ+F1TZ2t7XqJtqs8uDMV9ZDRsYHsbKcliH0JJUVVDsr9jQ0oP5y9Ixg8dok95yCQNQf4KpOShj 7MN+fmdXYfu/y6rwrayo/lj5EWx/Fbb/DrZ/r6KocYos9wD9uemYr+wsdVrUGa9gepEHJMmSkqmu cECq7VxRponFUFFo8bFMgAkwASbABMqJAK4D1caf+TY3NK/CFbT1OJmhXQSdqJmH2uHC0v8EURym UJZ5TB2vGXgww+r5DONIWbb5CToDrpr5Rk4MH/vZ9Tb/ToifOiDDJndQZKmlDhOFUXoPFFJ+hgoh zarrkoefThG3yJJiVST79tz9NIrwhMWu1icLlN5o2jopMvxtOgaX4x6yW3QtFFn4JD392tlzqNOw fX9qH5fPYiZGjF3iaH/m9Kn9M6xyZ1W1Pyrq9WdUm0QJXqUGDe7dPnhwBy2v2c0UFkM3Q43PYQJM gAkwASZQ9gTys/ykOd8VFbPW60BC5SPZ7Cl6/H8Qjbg6plBmMiyKD2Z+f0DTRZjE1QfzuGavGwUK ZoaXgZbGDDrdv3rR3lSSrP62FPvKw6p4TNQbP8RUqu/HRkYeu7FPUgouyaEWEtGgI010fD42ImYV /pteWkk0xz/saN8o6tAB6L8iiAZUYJRKDWqpgliL1toUyVpx//7VR2JiVmtDQKsTruSZZqAP0jxn ubiNGFIlCWScQD1OQ+5iT7sK5y5eBjSzARj9oVb1qmDMgc9ZHHwcE2ACTIAJMAFPJoBJ4nV6END3 RxBtL0iSUEuPzjeCjOnFsrKT0TpTVrnxR5cEB75UP/8Yk2o5bpOEKZKk3I0n1VEky2SQdeExcQkP h4aIh1KuWCdb0MOaik4QmuECnXayJEmYKza/kqN9FROx6kMgJCAsNuwKKqEs689/q4UqmagqU5ey 1ehXlFl0CzGU8u+3MGb0rzDyczO09c+tci7D/JeGwlp7ZahbEf3Bat4GE0Y9BzWzuXwVBQgfywSY ABNgAkzARQnk95ttKkp/ZRB34vE1FEFpp6AyMYD6J+qTFvgeCggRlYu4Hv++S0FNYlGU9Ox14/IY mR0yt26lpPROtYmfmUzG51AEXTGZIBR3rH1qV+W7BFCWWq36WKznacf5dGKmskJvIYPJjP/oQ38l muPuTLcpDdEfaSXuEruGtW/A45pS+zZFPB1qgjuv2K9+Fzs1/ke9IAeTUkPb0nlBhUtYZXNRb7ps 1PveYrEkX9VqVyRAq1COfhfGx8XFkB12rV4EL0Ukwr6zbeClvMw9yYdgR0ZdmLZsDrRma1Bh882f MwEmwASYgPsSSMaun7ih+4JwFv2ic7tV5z1KdPCxy/Chj6A+bLVLncifGh2o5+lUNQ6db/zwD1uA aJtl0Qnj7bJdUNPU6HhzQhNFsi3XiTDLZpNaUEM6vXgGl6dI6Dxrscq/AJgG6SWLSREE1Fbog4Qf 2BSfzYqc2ve/jgjgoxPewi31texWW+eYWHN/kxEu4Zrbt6qqVhBF456EhNnhPmCdpNMJz9tlSZQy rk5KVvXhoiidVhXboMx1QpRieuMS1Z6Wiu3EoElLkCQ7WYK09TMqMWZzEFgsF1BckdN4ocXFxZAF /jh4CYaMjYB13/4DaWk4zuCciif91DFIlvfDpwmJsNo3EPo8NRRaVGZVVOjM8wFMgAkwASbgVgRs CizEDr93Q6dxiQt3khXsPCxpxhztN1+v1wfpZSHQSo7T6Hqi14vBqh230GtySq10xgKXjKI6GD9a rKhSW5tVbosCZwbuAaNt86iEdH/aBOjlp9cn4M6xF2TV3gU36Z9L1WQH1alHP2zx9cjwUdo2/exl dmJCOyXDMtkm2wPxnC8tuFM+s+DynV63Nz1d91tEbGxKfGzMY9j+Umy/M1a75b8lPDoU7U6qjhy0 21B3UKiFoA3pYPZ2dLRDLjS0Kb6335lJdnExFAhDRkUCJG+CNct35VgMdAzu7NmLYLJWhka3NIGK qcfhw3mJ8L+Xw6FVpbwFUYUKFcDX19cZNm5/TEBAAPj5FWnZ1K3HbEIbbXBwsFuPwdnO+/j4QEhI iLOHu/1x9J2l766nF2/7zgYFBQF9b72hlMT1i1YOsnxkWT+Kws2gB4vVBjtQrNCP4yncUrZHsMuo WjQxdE6yw1/4fhX8/CS2Q7Lo4wRznB59gcbbJIWEFBqPQDL6+JywWeHJ2MmRyYmJiWaDLO8QZHWE hH7ZmZpGLwlgitOLBrQW3VjGhkfEJJrNawSwTkExVjvzHFFCh+ffZWv6yNjYCZq/UlRM7BcJ5liD XYIou6RQ3RQVUsENbP64DlZflTKWopf0HrDbdlMN+Mrp6I0DQdHn9O4yFxdD10Gm5x86oUGPEfAx vjKLHfY/+wh8+sMeaPVE6xyz8NFHH8H+/fvh6NGjcOzYMbQyFcH5vihXnAsd+88//8CVK1fgzJkz LtSr0uvKL7/8Alar1SsE0W+//QYRERFeI+zXrVsHR44cgVq1apXeBeQCNe/duxfdMFLg1KlTLtCb 0u/C+fPn4e+//4bJkyeXfmPl3MKJEyegZs2a5daLsMhYuqjaZOuAtq09W/kkd+ciIqNpS7tjW/sN fQ8PDz+Mb9KOLad3bVEl4ZGRG/E/PQuDEREZ8zEeQ6+ssmCBuVLyJeUl3FNlEH2Mq6dMivq9sHqc +dw9xFABI7lwZBcki7WhSd1gPAojROFusmsUVjxXufXWW6F27dqwfft2tPDpoHv37s7wcetjDAaD JoS8Yaw0Ubt374a7774bqlev7tbz5kzn6Qekc+fOXmEtIR6HDx+GO+64A1q2bOkMHrc9hu5NFy5c 8JrvLM3r5cuXvWK8u3btgrNn0bWHS7EIjBgReQkrmFqsSvI42T3EEHqGp6WmY1yEzBFYUq9AOkYS r1jBD879+QVMWJ0Bs+PCIDB1PxzzqQzd725yw1BbtWqlvUcCISMjA7p0wSVODy9k/Tp06JBXjJWm 8ptvvoGuXbtC1apVPXxmAb744gu47777vGaJgSxDJHTbtGnj0XN77do1OH78uNd8Z8lSQhZsb7gf 0xLoV1995dHXrzsPzj3EkF9V6NztTqiC4SupHNz6Hfx6tQG82P9uuOWRKJggzIbZ06aB3qcCPD56 KnRu4J/vnFjQW8tmy3/ZzZ0nM3ffvWmsNHY7xrJITy/Sbkq3nW4aK4ldb/G3oPHSQ4ynF2/7ztKc 0tx6Q/GG69ed59E9xFClW2Bc1C1ZnG/p9j/I+kswQsdHIvHlztPAfWcCTIAJMAEmwATKi4B7iKHy osPtMgEmwASYABNgAh5PgMWQx08xD5AJMAEmwAS8nQCltMAgBnUcYX1wiT0jMjLyTFJSjD+uVlb9 L96PKTk2NpKCO2ol0RzTIDUrFhCGVjSFpEdGhuXwBDfHxDT4r94AiIzUdpnlWfDYmnisD1Zkwfxl p/M7LikpyTcjObn6f02bMJyI77mwsLAcW8GTzOZayRYLpp/ILCZTwe3n1x6LIW//hvD4mQATYAJM wO0ImOPjX5YU/1+io8MotUahJcAEtTHO0F7cdI2JyUSQQLcOT+op2429FUn6VEtMhu9j/KF4fB+j OgPMmBY7264Ir16PTYTvYPRqKf1kTJy5f2x05J9JiYn3ZmSkP4sBGJ/CQICaU6/VbpHj4hMmREdF zMqzUzr4WFCEu0VZR1vi89zJhIIpRDXoltsF6Iz1ZgYNFGxwLVX9LSbGPADF2gV6y2yO6yFLCoUE oKBrWvs2rX1zdHRUJKX7cLqwGHIaFR/IBJgAE2ACTKD8CcxOMA9VZOUNQWc9smnTpiYdOnRwKuUE 9txH6z1FT7RrKcYwZ70N048JOaIUL42JMRzTi/E2WRmjqgJFk1Yxb9gujD9dV5astTCw4g9x5qR+ RiVjjE1R+yoqZgkD9W9RFNpg7jIM/qxLjEuYfS46YmxeMYrIioPtqYa8SJrNMaEyCia7Xe5K4gyD TV9SVeWUoCqtZbu1I+gMX8aYkx7xU5Jbo+/9VzgKfxGTuCuKTMEXDdh+U0VRp8fGJYiKVGsmRuZ2 ykOfxVD5X9fcAybABJgAE2ACThEwm80VRVl+CfN2oZ4Q6v+04bfBKIY+dOpk1D6oLvQCiiGM4tzU nJjUUVQNDykqpm5FPXM9VX1KcoC+npIhh6uUDF6n/8TkY1ocETF2VVxMTFvUJ9/YFam2oFo2oAjC tBhoEtL7nouJntB2tjn20Qyr+gF+7geSIb8Ik45AgHlG0hYVcahdVbqDoFNEnX6Wn8nvg/DwsH3m uJhnMKfau7IsdxR11pEo4LrLquoPgmGfXq97Kypq8lxcCvTBFKafS7LcV1Xt0/QBp79ALv86w4bF kDOU+BgmwASYABNgAi5AwAhSnwxZvjUzjZgEsk3/EgqkFej/k+XnU2A3UcBgElRcfVLrojXlbgHk niqaX7Q1Ji0dveibIYlTZRRbot4A+kD/ZRFhYavo4+jY2L8SzdOOSRZ7bUxeT2k8tKZUxV5l6nTz O7JVfN9k8rvfbkndq9gM+Vlk8k0ouyDJXBcFWJiMmWN1RoNaoVYNc9gzz1yhNmrUCfnqzMlrb2XY ZL2oSqMw7qAfWY6MJp99URPC59IxmEbEOjsx/vuMDHtfu4z9k9VYfPtxZ6aNxZAzlPgYJsAEmAAT YALlTAAtHwY/gzhBUq7rCbLwKLZ2NsWXUlug348zBZ1wMJGqJCt4qk0QFMUiiD6AC2GAb2GhPGRK bU0XoY+QXpZzJAVUBZ0BPYcyc4XqDZ8aZfttdklqLFulF9Cx5wWL1fInqqiPY2PC5tAh2OeA7L0y 6XLmEMv+mWSXfHDFLZTeo7bt51Mq4T81MZSRYcIlvjTsm4wGMbUivYepXXG9Tc1yntZ6r+j9UeDh v1Q6MjP3mROFxZATkPgQJsAEmAATYALlTcDPJD5ttSqNs5tWVEUGQZUSzImJByLDwymTeyGFss6j D7VsQcOKHCXJoq9eh9LjP68jPOA/HyLURzksPJQkPlOIoNwwmj6LGj/+8YT42DCrXe2IS2YV0Fp1 Hy6c3YE+O5WCAn1+8tXrv8rARGKZBR23VTUArVL59pEEjqMYDIGpuJvtznSbsU5QUKV9uChHkVd9 sh9DyVuzV4ZqidYPtbfwuLwztufROouhwq4b/pwJMAEmwASYQDkTwJ1bzSRJHYcOwzf8bquSva6i 00eg4/NTg2NjC06xgEtimIR+majC7bIiN1XI+gPKO6qqDkR/ooooddLREToJk9l/ImMqLNWihi5d utRn8ODBVtzGXs0mWX1IfejxADXlanxMTOyjoDe+HjslMokQTZ8a8zU6XvdDjTIRl6pO4LE5xApp qOvC6IZltJBU6WiqXvcFVv2IhMt0yZAsBCjQE3scd+XKuT0ohozkUa2CsAJVTisJs9db7HZfs3lB aGTkiAu4Hd8f/cFDaJkNnbzJUfx1Z6eNxZCzpPg4JsAEmAATYALlRAC3jC9AN5hmeTWvogO0LNkH HTeFkO/Mb4V1UVXUbTpRrW2X1KYkGmTc5o7iojeeR8tPusa+tm93ScJ+9AtqotjV2YcPH+mP/jgr dIIQh5vQKpAgEXW6xeiw1BUVx+PY+AMoisajqApC408XFCvkg7RVsum+skpSth1luK9fgJ9kVWiv yLbauIQ2PKuvuHSHQYK+CQBprqgI90uy3R+uXPs2XYUluJaXhiuCLUlFCaLukiAapuvBin5BEKVK 1u529eJu7F+MThSHSJKC/lRoE9KLf9l8fVYUxsLxOYshZ0nxcUyACTABJsAEyomA1SqNQU+YHP47 2buCwkVEYwptL8+7YGAh/ED7zUfH6Eq4V6syOQkJokiO0JVxMSw002ajhj4UFpu+Jyamp0EU1uCO raaSZO+OH3QnEw+KEQr9MzMqMiIiwRwfrpft49GCVBlPXaAthikoRETDSZ1OPweDM57L3RlzbEwg WqGwGVsj/GyB43MBV7QExfd0eFTYt/GxMU/qROFzdPC+A9u8I/uqGp5rkmxSO0mBeIMOKuGOthGy bK+C9byF2/9Rp+GSn6jbokpin9hcARoLmjoWQ+V0YXOzTIAJMAEmwAScJYA7uZzwB8q/NkkPlzBu YZymFkD8CW03x0V0lKYdWXo9/CbZMNCiQGJLWE+1RMbGHpuXmNg3xWZ5xmLTZA468+BGfKPv2ajI 8Hn0RrrFNitEr/8+DZQnbLjXXWtdNKiq0f/NqMiwM/n05g18v871z7IchATc2i8q9r30flRM7IrZ CfH9LBap4/V6VYx1RLvg7lQk5T7s8lzwC/1hUvioFxPi4w9bbLYgWhjDU1WDwQj+/r5vYqTqi86y peNYDBWFFh/LBJgAE2ACTMANCURGxtLW+8nZuq6JnmxlS+5hjQoPP4DvTcpvuLg0RbakPQUdk/vc yJjYt53BNzYiajUeR6+sQr5Lxw8fbobSTJAM0gn6ICIqKtGZ+go7hsVQYYT4cybABJgAE2ACTKDc CZATN3ZiR2l0hMVQaVDlOpkAE2ACTIAJMAG3IcBiyG2mijvKBJgAE2ACTIAJlAYBFkOlQZXrZAJM gAkwASbABNyGAIsht5kq7igTYAJMgAkwASZQGgRYDJUGVa6TCTABJsAEmAATcBsCLIbcZqq4o0yA CTABJsAEmEBpEPAgMXQJfvp8B7R46F6o4YMxpbgwASbABJgAE2ACTMAJAp4hhtLPQFLEMEj8yAjf D+wKNZwYOB/CBJgAE2ACTIAJMAEi4P5iKOMkvB4XCd8d1kOjNrUwLCVG5Dby5DIBJsAEmAATYAJM wDkC7i+GjJXg4ZFmGKkegefHrgCLDQdegBgyGo2Yh8X9h+3M9BoMBq8ZK/HQ6XTg4+PjDBq3P8ab xqo9teF3lr67nl687TtLc0rXsjcUb7h+3Xke3V8V6Hyhbu1aACf+hQybjDno8p6O48ePQ2pqKhw4 cADOnDkDe/dq+eA8uhw5cgROnTrlFWOlibxw4QLs2bMHrly54tHzSoO7ePEi7Ny5E4KDgz1+rDTA s2fPwv79+8HX19ejx0vf2XPnznnNd5bux/S99Yb7MV2/XFyXgPuLIQdbWdVS1uZXVq9eDfv27YMT J05oAuGdd95x3VkpoZ4dPHgQrl69Cna7vYRqdO1qSAh9/PHHEBQU5NodLYHe0bW8ZMkSMJlMJVCb 61fx999/w7Vr12Dr1q2u39li9JDEQUpKClitlILJ8wuJehJC3nA/Pn36NDRu3NjzJ9VNR+g5YghU UBVKoJt3GTZsmPbB5s2bYd26dTBx4kQ3nTLnu71q1So4dOgQjBo1yvmT3PjIMWPGQGRkJISGhrrx KJzrOs3p7NmzvWZZMCYmBgYMGAC33nqrc4Dc9Khvv/1We2AbOXKkm46gaN0+fPgwLFy4EBISEop2 ohsevX37dli+fLkb9tw7uuw5YkhVQVYUlEQFl7S0NMjIyPCK2aWxpqene8VYaZAWi0V7qvYGMUSW A1r29RYfKZpbup49vdD31VvuTzSXdA3T3HpDoetXwd8oLq5JwHPEUM0OMPuNFlC1EJeCO++8E1q0 aOGas1HCverRo4fXmNsJHVmFqlSpUsIUXbO66Ohor1gOdNB/9dVXvWK8PXv29JplbZpbWjYKDw93 zS9ZCfeqbdu20LBhwxKulasrKQKeI4aMgVC/YWChXAIDA4Fe3lC8xbnWMZe1a9f2hmnVxlinTh2v GSsNtEYN74geFhIS4lXzSg7xtWrhBhgvKAEBAUAvLq5JwHPEkGvy5V4xASbABJgAE2ACLk6AxZCL TxB3jwkwASbABJgAEyhdAiyGSpcv184EmAATYAJMgAm4OAEWQy4+Qdw9JsAEmAATYAJMoHQJeKcY wm34+YaqLl3epVg7BRXII+xkXmP1yPFnovXE4ao4KCGP0Op5zbj7Ty3GC8Pr+IYrOc+B5XPNl+K3 rLSqzneO87hV8RyX1iyUYb0efj2XIckSa8q7xJBqg98/mQtv/rQf/H2qw7DJEdCumnuH91ds1+Dz meHw2QEAv9Rz0PLpKTC2XxswKBmwetFs+HjLCfDzbwgvTR4Dt4SI8OeX8yDxuz0QoK8MQ6Inwj21 /UvsYirTis7/CWHxS2FQeALcXcsIaae2Q1zifEhOtULj7i9C2BN3A1w9CIkJc+DopXSofuujMG7Y gzjuMu1lsRqzp12E5e8vgJ93n4CLxtowOTIMbq0RAFcP/QqTZ78PlnQVWg8YDSMfuhVsF3ZDfMIb cO5qBtS7ZwiEPdMVfAsKyV6snpXGyRLsXfkOxH+8HUzyVegw1AzPdWsIOtUCvyx9A95efwj8TbVg eEwE3B5qhN0rF8LUz7aBvy4YnoqKhm5O7CQtjV7fTJ1r35gLx+reC0P6tQIl7Qy8NScBdp5MheCG PWD8q49DJUyvl3piK8QmLoRraXZo1usleGXQXaBc2Q8zZ7wGxy+nQ83bn4SxL/TC8d9MD8rwnJTd MDv2Z3gg9iVo7muFNfMnwzsbr0AF+1mo8uBYmPzUveCns8OWz9+E11btgwBDFRgyeSLcXdMXDvz0 AUz+4HfwEQNgUEQMPNAyuAw7fhNNnd0KM+f8BY/GD4f6Bsf5Knz3ViRsMXaHuOfvA1AssHbJa/DB b0fB37cujJgSDm0qGuDvFfNh+pc78P4UAs9ETYIu9XnX2U3MQLFOcaOfhmKNUzv51Pq38Qt3BqbN mQWWNa/BpOmz4YOZk6CyG2c02LNiJsz97iIkfPYBVD+6FB4bNwEaNvscOpxcCO9ukmHO7FlwdFkc TJ27BMz3+8GcLw/BxFmzwOf3BTA23gxvz54GNd1OD1lg8aSX4fUP7fBgOP4aKJfgrenTQd8xGmbd 5wuTxkXB4noVoeLaBDhRbTDMimwOSePDYMbX1WDaI7cX/0Iqkxqs8MXrU+CfhsMxQm8r+C5+KEyI /Rg+n/sQvG5Oghr9Z8DINhkQFjEdvqwzFdI/M0N6y5dh1sNVIG7sOHijeg2I6NW0THpaEo2kH1wD 4UkrYNgby+Bu60/wVPwEaN7mM2iy522Y++NlMON39up3syA+6R2YOag2zFy2HUbPmAVVdy+Bl6dP gbqvzYaGFUqiJ6VXh2w7D18tioOxry6G/u+u1RpaheLgD/U+mDurGyyOfQWmLK0Oc59pBfPiZ4J/ 91iY3EUHE8ZFw9J60yBg9XQ4U/tZmDWxEcwKD4PEb6vBlIddNCK3qsDlfzfA6JfD4JvNdeCBxJfh 8uZFYH5vG4xZ9gXcafkZHnsxBt5p+AUMDl4Fs745CjF4rxI2vAkT58yDWc+3hYRFG2DI1NnQ7OQ3 8CLep+u89jrcUtEF1Z8qw5mdP8LLI0fDr0fugP4zh2ddRJd3fgLDw2dCk1fu0t47tmYuzP8lDRJx rOeWz4BpSYtgxsOVYdZnuyE8IRGCty+CV81x0DgpAWr4ld61yDXfSMCLxJAMv6zZALVuGwHNKmOc oYceguAl8fDrqTTo39Dt1EDWTNbt+Dx82rUa1KyEFq46w2BAna9g1949kL51G7ToNB7qBAVCnf59 YdEr78Lc81ao3vZZuLUajr9vX6j2fhSsP3IFBt/i4k9cua7bs5u+gRVH/eDOTmTVw5vj2S2w/bgJ xve5FWNIAfS/vT4sWDQfgmw2eHRKD+29R+5tCWNX/gKpKIbc4pnr8h7YvE+Ge7tKsPK776BC71fh g9o1IWPvCthzORSm924MgTj0vs0qw2cL3wS/DB8YOqY9BGKYmgF3NQDzdxvAhmLIXfK829OS4QrO TIumIRCqtIYgwwdgz7DAph9/h3p3joLGlXAS+z0ElYe/BnPf3QhBzfpDh9qofmr1hQYLXoWf/jkP De907YCbB375HFbsNsJjTw8A1UC33jOwduNJ6Dm5D16jfjDw/g7w/KLf4XC3VNh7JgDGP9gS8G14 uE1teO89vJ6tCjz+bFcIxGEP7NgcJuL1nI5iyCV/M61nYcknn0OlO/pAd980SElVoF6TvrB41WCo U41yBw6E59sshk17/4bNGb+j5bY/3FKV7ksPQZ3l0+GNBTvBUO8+uK8hXtANH4SW876BNX+fhlu6 uWAssdSjsOiTr6FhlwEgV1XARqkgyTIkXYAPP9wANdtgsMXKmSLu5zW/Q+P2E6BBSCA06I+/QS++ CfMWSVC55WPQriZObPW+UPftcbD28DV46hYXV/cepqi8SAylw7nLIvi0uB7UzMcfAo0inL2AIf7d WAxVqFYfHF+ZMxsWwMcn9fD2rdVhw/cC+IZc/8QvGCrI12DHPyp0uKNS5iWs94Mgkw7Hn4J/uI8Y Uq/ugXkfrocnwsbDqqVvgg19KuznLsE1fTU0O2cOrXLlKnDl0FpIrtwcgq4jCAmuDLa083AVjw9w g+Uj6dxR+HPHNrB8sxYaV1Tg2E8/QPtHX4H7bamQiku8ftcfkEMrVYLz67aCocZtUOG6pq8UUhky riYDJa9wFzEUdEsfCO+xFUY/NxrqW45C9a4vQ8eaOph7WgVT8+vXp28FCAELbNlnhduaXxc+gg+E +Bnh7LmrOFrXFkNNe7wEi3Gl5ItJY2CDhN21X4CL1ooobjJvw0FBlUCwnYPjBy9Cms9/13No5VBI RnF7JfSWrOu5Is6xNSUZruF5LimGTDXglSlvgpC8BZ4a8jFYJRV8K9UGR6jQ9H1fwpvbLkPUiCZw 6WMbGBpdvy8bA6CiwQ6/7E6DFg845tMAFQNMcO78ZRytC4qhwAYw0bwA4PhaGDT6R8ChamXjsjlw KrQ3jB2owPco7AFscDbZCKaK1xNJ4/UcpKbC9n0StGt1PZ+iaIJgXwNezzizLIbKVG55kRii3GXo nJn9h1CQtfc8oZzd+iH0j/oUBka+Be0bhMD3qTbwyfGjL2GYf3QwznLExQ8Fxb3GjzeO5W+9D0LX F2HgA/7wzbsS+OASp4gmefptcQxXEFVQJAkkTAPkGC79V0VztrtkBkpNuQaSEAh9R46BPnVEuLph Pjzx5hKo82R10KMQ+m+suEqojRWdjq+/KQg4fhyrO13ZyfvWw8870+B/I9AKZN0NC5euhb96twIR LSg5vrMg43WsgJLrOnaHnE+ZXZbAil9E7d903WqOtJl3IO0tukZxfHK2m5IgAsg4x3j4f8fiwQq+ 4cpzrA0LRYCE99js/v/XDqyEx16eBbePnAkPtakLby60gJxtPgVtjpFD9pPwXqXIrjra6xOIY6Xf EyNaha7uWgWLNgoQNb8fHJ33Fah68sUQQJLp2nVMLm0UyOt6xrFzDrMy/1n2IjHkB1WCVTh7NTUT st0CGVYRqoa65HNVkS6EAz/MhaEzv4LHJ38AYffVx3PTILSCDS5fu56k1ZoK6UII3NIkA50w6Qka i2yB9AwBqlR2i0WjzD5f2gtfrdoAUjMBXl17HDb9tQcsc96CWo/VgepwGecTj8Er+sqlqxBcrwEu ulyGNJpufOi8huLCxxQMQW5gFaKh+lUIhho1b4GGtfGXkP6uURsqWf8Fq19TCLHvBQv9MOJHVy5f g8qNGoK/cgHSaLrxnnv12jXwC6gL7rT4+8d3y+FApW7weqe2OIi2cMuygfDpbwfhjqpo9bl6PUGr NR1SVX+4pakPCFeSr39HbJCSrkDDUHdZUsj8QVfpx84YCqHGa2DBJSQqqWnXQNAHQM1GFaGC7RJY bPgmOlMnX74KIQ0aQqB6EdIJBRoWruEcm9Di6/KJha7rF4eMObd1KbwwaT60feEtmP44+TupUClE hf04Hq1IGXDVbsL8kQbQXyNLkPYmLrPJmID5ukXl+ruu9h9tbyMqV3oI3f7Tl7Bz32WYO/ZV+Gfz RjionoOvuzSB6ng9H7nmuJ7TIBXt+i2b2kB1XM8qJmDG73HjKi4/s66Gv9j98SIxpIcOXW6Fr79e B5eVTpDx2zo4U6MetMfdOe5czm78AF6M+xiem70Cnrmz8vWh+EPHTs0hftNaSB/cCo7+/CNcaHgb RKNzcSI+cZ+1dwf9pvVwtFJ1GFfPjXIhBbeBN79eCakoaG1n/oS9+45B9wdxjb2ZCPVCFsIPv5+G VjjG7//aC3c/MR4q/ZIE36/fAV2eagarf/8LGnUd5fo/Htdn0Ni0A9xV/WNY/eNJaN6zFuz/czso 9W6HO9q3hx/e+xR++uMKvNDGAqv+OQa9hkwA61czYdWvh+H2fqGw6s990Krbo/Q76jalfsvmIK/f BAcsz0Fj227Yn6yHVk2awl1Vm8EXn6/F5c32cGXDWjhRowXEDKgFs99ZB4cz0Ido76/wj39FeK5J VbcZq4yWIbuVlk1qQofWAbDu543waOuu8COOP7T9IGhcpy36+r0PP2w8D80762DVjv3QeXAEVPhp Dl7Pe6Djkw1g1eYd0LTrWNcXvGi9slntoMcl+dSDq9GZeA50jvwUwns3uj5fAtzV5Xb47OOf4bzU A+D3dXCwYn3cZdYa5r65DnZeewIan9oEf4t+MKmVi+cwQ6ue1WqFFBSxdw+fBSueSMEHFBusVP+B 76Xu0KlFHTjfoRGsWrsOUp67A86t/wnO1GkNk/tUgsQP1sFx6wNQ4a8NcCAoFF6tF+w217OndNSL xBCq7d6joP/OiTD8heHgZ/eFsEnRUNvfTUwF+VxxW3/9Ec7Zg2HbsljY9D4+YeCTc7+XJsADj4RD 938iYOiw4WCQgmF07Fi4vbYeHvk7Al4cOhwCbQYYETkZGrmLqYTGrzdCcEgV7QXBadC8eTNoUrc6 +OKNduSo52HMrJdh+Cc+ULHtc/BC7/YgNh0FG2PjYPhvfmCq1QcmPt4lr0hMrvldFqrC0NgIeOut RBi+3AJKUC2YML4/BPsFwivDB8HY14bBH2iPr3Hvy/BUlzsho/JQGG0eB8O/M0GFpv+DCf1uc81x 5dOrxg+8DCPxep2A12ZF3HZdqddIeOrOauAnjYAHN0XCMPzOmiR/GBUTA7c38IfBO3bDK0OHQUVJ hGfHxULrypkWNNcvAlSoUhWqBpM3lwj9R02EbdHTYPjwj0AMbgfRYb1B9NHBy6OegTFzXoThi32g crsX4Pn77gK1wUswZupkGL7eF/zqDYAJj97t+tcz+ibWrF0NgvCX5uDGNfDvtQpQfdUb8OLXVlzm 00PX/42Bx3uMgMd3RMEInONAuxGGRk2Bdi0qwrO7d8LEYUMhBJeeHn1lGrSvnrVf3TWnGf2datas Akb8SfHxC4Kq+KLSrFlzOCI3g0roDV+pbxj02jVBu559JPwuT8HruZ4JntgxAUbhtR9sF+GF8THu dV92zdkocq+8SgyBIQhjkrwOD164DCI+TQb7uf/wHxizCO4bZUETu+W6/4AIAUFo7cEb6ovT3oJH L1wBn8DKEGjK/LF4ZNwc6HbxIgi+IRDi7+I3l4Iu56BbYM7890DUZXoSh97WD95/pzMkY+ydKqEV M8+s3xH9EVrDxas2qFilMq2guVWpVOs2iJrcCC5ctYAvPi0GXncCq9V5MCxu2xuuWnW4zBmsjcnY she8/c5dcBmXEyqHVqIVNPcqukDoFz4fulw8D3bBBKGVri976YPhuclz4SH8zuoDKkGQb+Z8P/gy xpd64gKoPkFQMdCdbGB6eCh8MvQlRyAsPlVbQ+Kb78P55AwICg3N8vOr2m4ALHr3XriSjkvZodet tw07w1sLb4WL1+xQCa9nF9xkfuM1V/VOeO2tO0DEL5/yZAJsf8QGabiem+mqKYBfIF6/OgMMGv8a 9Lh4CUS8LwVfvy91GxoHtw+4AHZ9IFQOcv34J0L9e2He/C6gy3Wj6T50NnRzyFafiviQ8yYMuJAM hoDKUME38zroF5YInfG+rOJSfsUAd9n24F63mMJ6626/D4WNx4nP9VAx1LV3nTgxiKxD9AYj0MvX Py+fCSP+MOYeqwgVcbeV2xd0rtTrc16+Bv8QqJLLUUb0qQBV3Hi4gtb/G+fWJ7AS5HYr0PsGQxX3 jiEKwXlem3qodMN1LECIm17HDgGf9R00BOAc37hcb8QHthuuZ1MQVHF9XfDf7QW/pzry+MeiQ8uu L7388nJN0OV5XwqqdH2XlTvcsFDg5rolab2+Yb5x3/2N17PottezO0yNM330QjHkDBY+hgkwASbA BJgAE/AWAiyGvGWmeZxMgAkwASbABJhAngRYDPGFwQSYABNgAkyACXg1AVcWQ67cN6++aHjwTIAJ MAEmUOoEaGeAe293LnVEJdeAKwsOiqp2ruSGyjUxASbABJgAE3AbAhnY0+zByN2m4+7YUVcWQ1MR qNkdoXKfmQATYAJMgAkUkwAFILieRqCYNfHphRJwWTE0depUSq5ALy5MgAkwASbABJgAEyg1Ai4r hkptxFwxE2ACTIAJMAEmwASyEWAxxJcDE2ACTIAJMAEm4NUEWAx59fTz4JkAE2ACTIAJMAEWQ3wN MAEmwASYABNgAl5NgMWQV08/D54JMAEmwASYABNgMcTXABNgAkyACTABJuDVBFgMefX08+CZABNg AkyACTABFkN8DTABJsAEmAATYAJeTYDFkFdPPw+eCTABJsAEmAATYDHE1wATcEMCZnNMiGKDV2xK ViJHSuio6o1+YDL6LwsPH7W/oGHNTjD/z2KxNJJEI/iZ/NeGh4f9WlIYEuNjH02XxJZ6vTHZak1/ Y+rUWEorUKwyOyHhPovN0lECozUo0DcpLCyM0xQUiyifzASYQHYCLIb4emACbkhAL0FlzFUzJXfX ZbsVbKA+kZg47yEURP/mNzRUJyPx1QHw/xRF1eFxJSKGkhLNd9kV4TMQUJuJ+rCSEEI0Bh9RPGIT hB9UWYL0dFslfGusG04bd5kJMAEXJcBiyEUnhrvFBAokoMds1jaQBVGnE0Xha1mSfjLodYNkSe5k t9uagJg+Ac9/jur48MMY0+HDmRak2NhYyoRNGujaf/Ur2ntUYmJiTPgf7VgslBtQxJcvvuz4UvB8 Gx5D4slw/RgbvqfQv5cuXWqUZWWsJMsg6I2SUa/743p90KBBAzh8+LBmvcLjLdfbonqz/s6rD3ie +swzz1hGhYcfTIyPn2pXbZMl1fio2Zy0ODIybMd/Y+B/MQEmwARungCLoZtnx2cygXInIAgiGEy+ ayeHj31zwYIFn129fPFYutXuq8jKoKSkpDm29PT/2SXhKdQc/iCI6bFxCe/6mcSPBRCyBBCAzvIh iqCzPvpPRAHuUVQw4sBS9QbTQT+D8UuLJeVZm6oLNZl81+H7T1cw6nukSfJ7Chh0OqPxIXzvj+sg BElWesqon3SCuCQw0HRAthn2Z9gk8eTx42Qr8kURlh47ddqvBpBIdHWhPk2dnrBS9vMJiw0LyzDH xY7BPozBPvigJtMfO35aSkhInBAREf4eiMpKURAmy4pcG3vYEM9nMVTuVyB3gAl4BgEWQ54xjzwK byagKP40/BEjRlyYZY5L0gkQqaqqn91mX4JWolvtoFMNBuENUZEetSnWSVbJt6GvTrP0aCYi1C7C RT9jlM1iv08VDRkGEd7F5agRsmTvbNEZftPrdZJkV2pKilQbBZafJMA4XFqrqTPqwKTPsiJByvH9 FXAVK0MAXZCoE6/4+lqsVwBqUyN2BSS9wfCpIkuDZdn+uE3UXzTq1XWyLA9UJGmYPsXnDfRjai0r 6mxV0IPRqP9BkSypkmS9xyaKL2Av3zP4mvwl2QJ2SQKbJPuh1UlAK1Ox/ZG8+dLhsTMBJpBJgMUQ XwlMwIMI4HLZWhxOpKZzFOlWO5pYQBSOoejYJ4o6f0C1osjyE6pOVNRMIYSLX7KPLt2WKAFMDg0I bpRhS+5hRTuOiufaJDXDz6hfZbNb7lBk9R673f6YIsnNQdCBKIrvp6ambnPgS9P5R4KQXpUq1Qsq 3Vu02um/OoPxSgU/n9WpKdcGywralIw+x/yNurVpaakDtb9N9onYnTRNWmG7+BZ2UFyl1/slRUeF a/5MuASHOk8bGK7RKbF+ISHL8a9sFi4PmkgeChNgAmVKgMVQmeLmxphAqRDIso6IesMkVbKj/kHZ oMqa4QcUqaYKarxVUS7jXxdQZaDPj1oD/41LUVpJhxBTA59r9mmX0i42RtHUBC00uEqlKROpRhDM P2QVX5FlKUiWdZGSoobgCtYFRW+cFRs7XnaMCK1RAXgarsDh/zQd5Cj0liCgCNMsWJpLkoBqSpH8 ss4FoaYq6l/Q6+Xmdlzmk+1yD+xBD0VNP4XLaN+hkBqv0/ngip+N1BAJosDMirgwASbABIpPgMVQ 8RlyDUygvAlogiQxIaGvXVY60W579NnZhbaUIFQLdUBv+mNK9IR7sncyMcG8GjVLL3pPFMHXmibN tylKBxX0B00+PtNVuyU8w66Qk3TAYyMiLydMi12G5poXcb2ssaxi/QbxcnR42L7cA0d/HxQqRV+5 wtOM4eQkHRczxGQ0PalItq9UUXwaBVgTkJXhdru8y2DQbcisWRNTRW+kvGeJ22cCTMBlCbAYctmp 4Y4xgUIJ6BRFAmuGNA79Z/6Hy1YtFUXRoVczGm50b+oEpaleFEbbZVvbuDjzBFG1tLPJQj3R6PtN gEG4kq12vA8oQZqG0Yk7QLGg9pAM6NxMh5ApBkSD8aBettrQB8mIW+bxHYM5t8+OarPNQiH0MFpt QmVcysLKtFO1dlTtj/8sOfg3Krgs85EqCKkYn2iARYb5iipX1etNEw2ifAT9iZqg9qJyDlfE9Fof sV+4fT8+OTlZ25XGhQkwASZQXAIshopLkM9nAuVHwI7iQ4f6oBp2oRoKIRQKhh2CTv92VMTYhejs HGiUlRaq3dZLkixmWr7SG3zQOdknFlRLCzxHyYwzBCkocN436KSZdtk6MEPRDdTr9IqAW+RFQe1p TkpaEBkROcc8bcpL6AjdQKfTY3BH3b7oqJzOy/f3lw5997VOp0roMC2pKKJC0A0pFV/kog12VD6k kLRt+PQ3qiOyaGX+rarGVJuywmQQe9kk6QWbbJ+OFagi9kOvE6PDw8d+kWQ2dyD/IhHFmF4PR6Ki Mrf0c2ECTIAJFJcAi6HiEuTzmUA5EEi1wAn88jbXZEX2ououRUdFJNNbGKU5BWP/9Dt9+HDtVMA9 YOjUow/wlSLCwo6azeY/0XgzSUEtku6jOxcbFpWSGBf3jR0UQUVTjI/JpNpTUwH/8IsMCzuP2/br oOXJHz1/0DCjW+drSN6Se9g7djTBjWfHdulkWxf0zm6Olhs9OnA3Q02DDkLk/my8JINM2/NBVCUr GHxTlNT0FZqBCNflcGcYCafhcXExiWjw0sYlCiY1KjL8IP3brki3keAT9PpLRtFA/k9cmAATYAIl QoDFUIlg5EqYQNkSQOFAW+MPFdbq4MGDKXCiJiayl8jIyNO53wuPjr7hODpm5ozps2026RlFVSrh tvc0jPM4Myws9oZ0GNTWGwnx8bgTrYsK0gMZVn3f6OjoJbnayRbsUfvkSu5+REfH3tCP5s1jRBn0 MxRcbTPohO8wfcjvhY2dP2cCTIAJOEuAxZCzpPg4JuClBNBVuQJGld6Ebj4Z6Dy0CJfgfsgPxaX0 er+Y9AcjcXs8WXGaTZ4cI5RESo5HB4H6lE5aIojGiiIYo7x0KnjYTIAJlBIBFkOlBJarZQKeQiA8 cuJQZ8cSGzuYHK5nOI6fOtXZMws+bioGV5yI+dRKpjauhQkwASaQkwCLIb4imAATYAJMgAkwAa8m wGLIq6efB88EmAATYAJMgAmwGOJrgAkwASbABJgAE/BqAiyGvHr6efBMgAkwASbABJgAiyG+BpgA E2ACTIAJMAGvJsBiyKunnwfPBJgAE2ACTIAJsBjia4AJMAEmwASYABPwagL/B8HofVk52iWRAAAA AElFTkSuQmCC --_006_CB68DF4CFBEF4942881AD37AE1A7E8C74B90346104IRVEXCHCCR01c_ Content-Type: image/png; name=image002.png Content-Description: image002.png Content-Disposition: inline; filename=image002.png; size=47204; creation-date="Tue, 11 May 2010 11:15:38 GMT"; modification-date="Tue, 11 May 2010 11:15:38 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAeoAAAE4CAYAAACUm7AeAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAALfkSURBVHhe 7F0DYFzNFv5WsW3VSo3Utm3btm3b7V/btm27adTY3GzembvZNknTNkX6ssnM//Y1u3vv3JlvZueb gzlHOmnSJPDCEeAIcAQ4AhwBjkDGRECaMZvFW8UR4AhwBDgCHAGOAEOAEzWfBxwBjgBHgCPAEcjA CHCizsCDw5vGEeAIcAQ4AhwBTtR8DnAEOAIcAY4ARyADI/Bdop4wYYI9tds5A7edN40jwBHgCHAE OAKZAYFY6sRtcu6OT60zqRI1kXTOXr16HS1QoED2zIAA7wNHgCPAEeAIcAQyKgLr1q0LvXv3rg21 LyLNRE0XOpYpUyZ7mzZtMmq/eLs4AhwBjgBHgCOQKRC4c+dOFBH1d/vyPdV3XHh4eKYAgHeCI8AR 4AhwBDgCGRmBmJiYhB+1jzuTZeTR423jCHAEOAIcgSyPACfqLD8FOAAcAY4AR4AjkJER4ESdkUeH t40jwBHgCHAEsjwCnKiz/BTgAHAEOAIcAY5ARkaAE3VGHh3eNo4AR4AjwBHI8ghwos7yU4ADwBHg CHAEOAIZGQFO1Bl5dHjbOAIcAY4ARyDLI8CJOstPAQ4AR4AjwBHgCGRkBDhR/4XReXp0LsatvIg4 kQhieiEhAQp6wSwnxk+bjeI2klSeEg+Pawex9ko8Bg5vBqPvtiMaWyd3wB7/clg1vy8sMuGIKWKC cWD1BgTnrYfOVbLj0qpuGL0vHnPWL4ebrdZfGKG/WIU8CCvGdMJ1vU4YWz0M/UesQp0xm9GvmgPe nN6Frc/0MXxAXWj/xUempapLm0dj3l45Jm+choLGslRvifO6jaHDpkK36khM7+SWlmp//RpFHF6c 2ondb0wxvG8taH63hkhsmz4AhzzdMKyNBGNHr0PtsYRjVUfcPzAHk1afQUCsHkYtWgfDuzMwfetd hOs4Y+aSlXCzS98fQXxMIPat2IjIwg3RoYLLr2OQ5jsisWN0f+wPzY65c0bCPo2TJsrvIZYuuYgK fXughEVyhI8t7opVDxwwf9E4ZNOntYiXTIFA+s74TAHRzzvh/eQM9h85+e2FUkd0HTcv9QpiPTCy V3uc0BiE4UTU3y9y3D+7Cwc+ijFvHhH1z5ujdlf43VyDFv3HYMCW6kLb9c2ckDtnPPRkGXChiY/C jeMHsUU3L0Y3LoecuXLD0lgfkL9B/67t8SLPLIwb8O+HwOvxaRw6FImekVOJqFN/fnyoBw7tOAQj o1bpR9ShT9C7Uwd4FV+IcX1/hIMUTy/vw86b0ejbowVy5s4NCyNdusEX86fPwMFnZmjdrQVs5U/R d/Qc3BMXR9s2LjDRT/8ly+fKCjQfNAWjdtdJ54GMxcMTe7DLtyTGTk87UR9e2B/Dp0fj4pD+37Tv 5ZU9OHTcFaNnM6JO5+bz6v8ZAuk/6/9ZV/5/DyrRfhGulPFDfPBTDO3YE15lhmPHsHqAtjGyab7H jJ6dsPmCD8RG+TB27kK0KmuLtYM6YP+zCMTIVsCtqRgnd47Bx11T0GPqbsSKNOFcrjEWzRyJ7IZS aOvpQmKgC3GKLkb53cGotv1w4mMQDPNUxNQ5s1Atu6FwlTzMH2umdMKSQ68BLUf0njoXvesWwI11 fTBifzgalLPBwQ0HEWWdF/3nr0F76+do3XII5KV6YP3MjtCjOt5fWI1Oo7eh2ZSFsLu7EqPWX0CC pjm1cS0G1MuFqytGYfKRd8jvJMPpCy/QZf5ONDW5ib6DZuFlQCwMXQpj6sIVqJpD2abQlyfQo+8I PPCIg45VToyYvw4NTB6jV88ZkCMOG4Y1hES+DS1M5AgIDEWsQtlj31sHMXjUWNzxjINZkaZYvXQM 8uoHYWyXFnhnXhPZwu9gz7UPsK/QEqtnDIKTvkYypF6fWI2BY5bhrXY2tKjqjGtnPTBo01JY31qJ gcvvY+zGnajmIsOl1QMx5r9PGL9pO0rEHUf7rmPwKkABXcfCGD9zIeoVNIdIJIYOSSrGNCYJsVEI Dg5DbPh7rOw3EOc85EgImIWyjZ8iG14huuAg7JrQGGy7Ee91Ee1bjYFDp+mY0bE8bv83CH1X3kev Wf+hY1mWqC4Eq4d2xba3JqhZSAOH955FoFyKfNVaYMEMWsR1Umhl4kKxZc5ozNl6FsaFasNNpgmR VAv6ehoI87qF0d174vSbSJgXrYuFcyajqI0ORGIZDIwAYwNDKGJ8MWNAR2y5+B4ybX3U6j0dEztV RdzrQ2jdfRYK912NKc3zCTh+vLAcncbtRed529G2BNsqxuLq1inoN303ommuOpZugEWzxyCnUThm 9uqEq58VEJ2firKdYnBgw1CYJY6GPOITFo4ego2nHiFX1RYwiTeGoQU1KC4KQUEhQHQwdk7qib33 Q6Cho4uA18GYO60TrnkCelaBCI+yRzaaSq9PrES/kYvwIVqEkq1HY9HItpC5H0O3znNgUKoIPhw9 Co1qw7B1YRdoh3lj2ZgeWHHqFcRmuTB2ziq0drPCw12j0G/dW9StmhenNu9EkL4LOs9Zia42L9Cr 11xqcQxWD6hHTVqP+V3LCj3we3wQfXsvhm3VCvA8tw2Pg4zQash0DGtfGVqiBLy/uA7dhs6HZ4QY RrlKY/qsOaiUk839GByZOwpj1x1DrEwXjQbOxej2laArFUFb3xA6MfowMQA8zs9H06G70GjMKoxo XBChH69hbN++OPU6EmaF62L18mnA+ZkYvvQ61SlBuzJ1MW/LRjQtpEIY0NSl5xnqQ0dPhJiAt5g5 rB22XwuE1KwwJs2fgyYl7GhxiMCl/6ZhxIKDCI4TwZnqWTBvMnIZaiD45TmMHDYMl+iZMgMr9J2x Fl0qZ1OuPYoonFo1EaMWH6TMEVpoOnwJxnUqB015KPbMHYipW24gJkGGonU7Yv6kgbDQyoAb7f8f TfzRkzlR/xF8ypsNrHOhDL0QbQgz0kQFOxRA2bLsx+2HweVLYtFTHfRoXwuBd46jda2qiDh3DjlL lYHtzmvw1syJWuUKw+/cRvQatAguTfsje/wzrFw5EQOcy+Lo8CpEDt9O+LjAp+hTuxH2hOZEl9ol cGL9YtSsH46Xd7Ygu0YAZnashHFHw9CpVyPg1SX0a1AdkaduwdX3Oa4cPQ/PkGZoVKsU9i7agI4t 9FDpzgxYKp5i4fIV6DegHcpZi3F60yJcvB8B09ndcOZ+DNXVAto+DzC2eQ3Enz2GvN5vcPrYHrwq UReN6jaDq+we2tdvhw/ZGqNFYyecXrUYXbub4tKJJXAQf8Dojt3xUKcMGjWwx8Wt89Cl/2gU3DYI pUvkxcHnt5CtYGkUdDLBx9MHcWBbOLrPmoewt7tRs2orBOaqQ+11wbVtc1G1egBO7+mH93euYPvz h2jcszvKZfPEmmUj0ccoFw5ObQjVxA58uRutWvTGG+ty6FTREYdXLcJ9HyO0iIiBxruHuHT5HLzC FMI4+ry4iStXPuDNi4vYP7U3PpnURMPSRji2bj46jLDBu+NzYCxVbh4kMi2Eez3Gtl07YVxnEOqW LAmLrTcRYZ4XtStVguL6XUycNRc3BzdGKf14HFwyCdsuPcWqWXmF+x2y5cSLawuxYMsZIupOkH+6 h03/7cE1X+DiATGqdRyCivofsXrxWPQxzod9E7/2id1/YVlvtBuzDeVb9kJRgw9Ytu4qsVldhL+m DUa79nhsWQNtWmTDo+ObULOmO85f2oV8Gsq2a2lHYO/03lh68jPatm4Iryu7MLt/V+Qr8QLtsuWB 7P0NbFqxCYObz4Yx/LF0/DCcf18eC3KYCvd7X96M3oMWwKnpQOQSvcSa5VPQx74UTo+rhDxFisHs 8GPEWedDxeK5kqi+I7FxeAsMW/4cjXt1hI3fJSw9/Ra2xQwQ7vEI23ftgmn9sWheoDRsjdjvwgr5 CuWiDUoAjh96B01zZ7jmssbTU7PQsNFk5G7ZBy0c4nBgcQ80DovF2paauHr5Atwf+6BTh1ooUbUY dKO8MalNVcx+Yoqh7Vog6Pl5tK9XDeKrV+Hi/xqXT+2ljVhdtKlaEcdXr0Tf1n2R/+hklHHLgyOv 7yJ74TIo5PKVBGNCPHDxyjl8fvASnbo3Q7EHJzG+U31I7V5jSFF39O82FFGF26GBowL7li9HR60c +Lh9GK4u74WWw/ajeveOMPx4FNO71KWxuo9pzV2ETZymjh7Caf6P6DUOEXn7omGlfAj/dAHNKzfB a7uaaNsiOx6f2IyqNb2xckIDlMpjgY+3gBIVy8DOOPmmVBggTV0oAp9hWJOaWPXeDN1b1YIXmdma Va+JHbcuoqIfbYY7z4BL8/5o7BiCzbTB76ZfAKdnVcGIVg2xIyQfejavhWdH1mFYl85wvngCVR20 cWJORzQdfxXN+neBA95jVY+GCJMeQBscQYdRG1GpxzDkT3iBFXOGIsHSFVsG09r1F9ZXXgW+rGcc i7+AgCIsAnIyTStio4XaPp3ehPWX36Pr+odY3skVCGyEl9kqYNnK47i/bgLKLFiCc0aNMHNAQ8QH vSdpewmMTDWxePouxNGa6vXmg5IUUmnbpxsHsf2OB/rsu465jexQ3ckQN7XKwozMk0HPTmDtvieo P/0U1o+qRuLcC/jkKoI1izdiVElSL0ptMHrxBnQtrIsC0Y/QaeULfJRaY8jIflhRZxaOXv+IcnWi sfv0exSt1YAW5n2wKd0f7Vu0gCy8CG6faY4lC7ZhYm4xxGJLDF+yDb1L6CPh7R509VEgUOMT9PN1 x4QFBaGZsyQsmclUbI1O4+ehAi39706swLsQMcLffUCYaW4MGNAcozc9Qr0+U9G6gj32nyCaJalP XzcCFxavwv0YR+zfcRANsxGmFfXh1HABtp0oD5G2CGZFu2LjirnQD7uBB85l4P70I0nnXyf2w/07 cTfUCIuOH0D/0oY4Z/UaVYbfhoQkY6mmNv2rD1kiwDItwoYkRB1jF5IgF6C61Bh3di6AV5QYIe6e 8KFhNdZO1GuQD4JYqgl96ptMxxrVmg5G/onL4FGkDcb2a4uwQgGYt28IDl30QalaQVi15RJsq41H i5LKhd+ydCv0qzED0w7sxuulnaC4egRPI83RtHVZHNu2H++9Q9GnbR/kLtoC+SuWTz4HEjywc/NB aOdpiE3bl8GJ6jMJdsHE4xG4fWQPTr0IQqf+ndCigjVKGfvi0KBVWH/qI+ZX1hIWzphYKcq16o/Z uQOhH3Qdw94EAlEyfPjwCSLXHBjWvy7KzDyF+6QdKON1EBsvR6LJtIGkUlcCZZK/KiYtWEYmCh0s n7EHMWyuvnpDuNdGg36DsWjhZoSV6ICpvUmrpCpBT7Bt63U41RqPPcsnUTu8EPTGBUciYwhHI+hr SCDS0INb45EoMW0FLhnXwZyp/SCOLoONc/fAuEpPIrKqWNSkLz5ou2BCh7Zkn42H9tsLpOlZi3OF Wgl+ARX6z8L6SfWFp4Y+3orNh5+hWI9FaNmiKqLdbXHmTA8sWnYWM4vQ1SIDDJy5GiOrWqOS/hvU m/ISYRYF0b9fU4ze/AyN+k9D+8os86CyiMVSAb+KQxZj/cTGlJDwDt5md8N/q//D4O19MHTWUoQZ mOHU2unwp0kY9+kzgqI9sWnZFuiX64YtqxZA52Nt6C24iyZlLammaNKC0M4+/A1GdmmJs+LquLdr FnLQ9L+5dw9OvgtE7yGd0aKiNdxM/XBwwGrcjZmELs1dsfN2DMYuHoWCKdVs1EKpDvD46E5su/EJ fXeew7zmlK3YswaZk2ph7bqTyFkxBjTi0PD0Q94uPWke1IJL+arQiPOGt3cYwqK8EGJWAIOnzEMn 7ZyEM20GYt5i0+q90MrfBO3atoAVAuB+5TjWLVyH7HXliEQC3n6OQd/+g5C7XGcUq1SMk3Qq6/bv fsQl6t9F7of3KfeR/j6epCISoUBeZ+XVJi5wJeePS15vEBkZgTgFOZ3Jo+jnSgvdvRMYMWIMIi0L oV3Nenh2bz7i5anmEBeqiomKoZ8GEQepuFipNWAyaiW26YO3h/BDLFAgh/ITiQ0K2Rvjoc8r+AfR XYaWsDdROhxpGtGvWqSgzQVgV6ML6jhMJxvXBbTT9MLdKCuMq1MJu0j1/P70UpQ4NBfxYk2YW5oi Z2wc/GNioKVhCHszZlukarLVxq4t49F52AyMacPszdoo23Uq8pIK2C7qDVbNHI9Nd/zQos8AVMx9 BTvc5ZDH0YIaylKwJiAyNIj+tVdqEMS04MRGwt0zAFpmtshmq+yKRb6CcEQ43L38SAFLqtzszhCe TmyhTYt9nFS5mKqKjwchoWWOPI5K9btD9pz0//fI34/6HM8kaTFkUiUBacgIE6kMsT6PsXLBOGx5 EokOJK27OV3CsTg54lPNb8OcB2mc4kkFTtXFx4YL46lfsjYqmY/G1WP7cTM+AGc9dDBqVVsYfmmc Edp0bIE5rZbjMJkNNA/vg7h4eyxfMhAnHGToNXsVGp5cBeg6Y9D8tcjXrTI0vtwbhbBwOcydHL44 IbrmzQ7poQgEkAo5jrBcP6QOltEc0dQ3hqW1A8QhgTR2EiIbgiM+BOcP7kePiTtQvHkv1KtYEAu2 PUC8QjnfijZuB4fhrXHm7FV43NwFf93C6Ny2whdMPUiSHDFiNELN8qNDHZqrd18inrAU4Aml5xMO 8phwUvjS/FLdRertCALGIY9T4viYwzW7NQ7c/zrHRUINwYih3a4iLlKYw2YhIcLmNy4mkg0yvKgO Udgr9KxeGDH0IAMzS1jrFEJoeBjNGyC701diDffzpdpIU/LfCORfRaSooQtLU2vkiAxBcDwxqYYJ HCyUc1dGpiX6AGJqTvL5+LW+BLY5o6vy5lFqRaDrAFdLHRz1/YhPr19g7vhROBeog06d26Cw9TXc pN+vXBGNqFgR9Iz0aFyoOFbDkoW0eRZKEKS0OQx6cRUH9WjDqLiP83cCkaOUCZl+ggknETYMrYPl ScYxzucTfGMYZnEIDqAazVM4DhIIkgT6bfp4IYp+GfnzOCgfZZsD+Ukh8uTtK7hMGIhd056h6+QN aFtjO8152kRPX4l8w+pj/q5NkPcfilVDW4JmH3JW6gWHAgtRzCgQvgnaCHl2CDWLkCChkMLEyhyW ZlKU6D4Gq8PC0HfhItQ6sAik98e4ZRuRp3WpVIWMLxOJ/5FmBDhRpxmqX7lQuaJbO+Ug+TGB1Kv3 0bdkeTL63sOVTzGwqu4Kba0YxNAPTkw2K+bXfGXvRrzxccb1t+dQKuIcDi6aDx0bK6Ge1Oha18iA aIoo5+5boJotzs0fgA2vrTGV7NqmLrlgQ4vW5Qs3gbpOZP58hgsvfWBUoSisjcjpTa6AnF5C3ap/ 2eoqcUH7Lo3Qf9U6TPCVQy9HbdSvUQKHh0bBxm0ozu6bAPMYTxzaeRyxecpC59QUxNLiJRc2FGJE f/aCr3FxzNl3H2Xz62F200qYvHYmrowgFVvwGay59Bp9193Eks5FMbnmUloRjcDWyQRiayYFa+kp yZR5zUOhQJymPnLnskP09ru4+ywaBYpo4c2l86R0M0EXFzs8E8tpo0MEyp5OJEP7nm9KjgIkTUTf xrVHHgSTHa5dv0HXkA1VJCMNoYzINxyBiarvD5/IGCrVxoebh0gT4o0Jhx9hIuHX+9RMxBuYwIKJ bKxtqRaGaTwkGjrCeEIjB7p3LoOmG5Zh+AVfSPPUQrtKyT2I89Rvj9ou23Bs2QR8visn9WhtSII+ w9StOc6/Wk6SMklexWpgweRV6NWpMnJ8WZP1YW6mDc9X9/EmDCimH4nz1x9DLs0LE1NDWhwT0GXB Jcxokxc+Dy/i6K23KF41FxLCL4HWV0j9ycSxfQ9c6k3ExS2jcHdJSyzYKYOZmVK1relcFR3rWmLR 9NFw8rqMHPUWopqDyvs+ARf2bsIrT3tcenUR5eRXcHTJXEisLIX5CNoAqXBI5o+sZQBqGu7euEWy WCeYxrzBhYefaHOUxiWI6iU6hQU5TyToOmHTufOok1MXD47uwc1QY5R19MMKGpp4mg+qokskzvyp creYj4OL20Hi+wJ7j1yGSfFKML17iDU2ce6y+77+yhRE4jRDyDckcT4mVsg2kGz0b1y9BLTITTuA R7jsHgqnMoXhc287jtDGbumtZ+hTXIFm2ycSiZrCXNMQxkakrXj+nIwItEcOuIS2HVaj1vipaFPC kjbIYZCYlMWeo7Nxpn9VjOoxHo0fLoW9JVs5EtB5/kXMbJuPHkXjePMdStUoiLcradBplhlQvd8U 9nskrZCtc3YYkJhw+epjdCpQFPKnt3DdizbvtDbE+LtDw7UObZKmIZ/hJ3QqXhobJi1D3/YlEB5j ju5zD2B7qbw4PaUtms1agS0X+qNYSztYyCKgn60JTp1eh9z6oThLmh9P/VzQp02FbYWOuDlwMyzC zqJ2iSaYNW09erQqBVuu+/7OevFrH6fxV/JrlWbZqxVyhJIYEBQeJUBgVbwpBjbbgvFjG6PS6aLk THUPAVa1sXR4fXLsCYeZhT7cL5ADySApmuQuCQPFEvSsUQc28vd4QQJEtvfugjQRExZOjmr0SgKs nVtTDKi7BdPHtkS18wXI3nkK/jb1MIAucsxRHYN710DvBd1Q+vF6wP0J7saWxrbJ7aG5aSMRdzBi E8XDmAhy4mESS7ySbKu17gyTWfWwl9axTutWIJtdQQwm6arF6LVo0/Y1LKI/4eQZP4w+WwEF4iNJ cgqiupQNSyAV3tSu9XBfnA81imWH5/tgOJRrhRJ0nEaqmw8l9OKxcWpPfNxniOsXyRgr84ZXcDxs ze1pQQ3H8mHNoRW9EtmkTMwOQUiIJqr1Gow6GxpjYL1i2J7fFk8vnUPpFrPQpV4edB5DanYTJdbE 2AgJjENYWLRSsksshZp3IRPADkxsWR7Xy+fGs5sPaAlmC6QOXAoXgjk2YUjjUjhUlNTcxx+Tn1QO GOUojOL6G7BsWFvcXy7Bufs0GNae+ByeAAv9BESEJCBQHEXaADk54ySQqpDUEWIjWFpo4eKR6Wg8 QI7Vi3qjWpdhKLykOi59AppObovsKY/f6BRA7x6lUX3ELlJnVMLmjhUQcGYCOjSeBt1i1VHIToz3 Yi3UatkAdknXZJEV2vfugpXt5qJOqXIobCPHuTM+tNnJAbdm3dHl3FVsHtcRn47nhOeDq/ioWRGH 2/eBJDgGQQS7AanqqxRxxowjC1G73g14PTnPVAGk9qQvCRHWl5ZdumNJo/F4SErOOV3qK0lYKCLk LlwCOliEPjRX7RM+4gnxht2Hj4gk4HV0SYI318DBA5PRbHAsVszrATO2WBvkR7e+jXB8PB2vcnsH Z4kXqehJdZ0tBnGkOQmiSRQhSIoKhAUHIlAUQX+xtyQ5BsshCg2j92J0HEpOYuf6YFTH1tjuoof7 J0/BpcsS1CooJfmUtMjRX4naMF8djOxRFQPXT0GbwJMQe7/AmQcyrLrTAfZx4fTDChSkd1Zio0Lp /4OE90bmdtS/ECwe1AzygIWkHSqp1AKQuUSP/nq6bRKqfdyP0Cc38DTOHuu7NkMB7CW7bSBmdmuI MxaROPKWCFPzDbwTzNBr1GDsaTINNUtWg738Fc7fC4Z54wFE1LYI9/uMeJ2cKF7KDWWmjcay6mMx Zm0nrGjRD13XnMB/4zvB44RyHD9oVsKZtl1ha0lSvmI/OtfshKmL5qBO/q929Ohw0py4ByJnrdbo 12gvJgypDff9heD39DZN7caYNLg+Yl6sRc+GA2mzXQElyTvviUIDZdqQ572OHIPHd8Cax1LUrlIC cZ6PoZW9EqoXIXWWWB9DxgzGxU4r0LV1GzgZhuDiwYdouWIPCjzag1ZtZ8PSrTbyWsbiM6nzGzav B3NO0klWoj/7kxP1n+GX7G4RLYBNenaAXyGyR7OiZYHR20/Ced4gbL/8GUbkNLRw4gSUs2dqNl06 djIFUZvPEG/GonTHMVgZLsOeW69QouEMtG56C1f8tUHcQF7EPeDnVwKGSexRYh1HTN13ABZDJuD0 +wCUajOOfkhjUMyEPVgH3ZcchW2+oVh97A2QvwH2jpmEujlMcL9wE3ToEQsXI+XQ5yFP6Q7EdfY6 ysp16Ic5amR/HHU3wtCGrB8i1B21BScdZ2DejuuQ62THrAMb0b9yAdzzq4WOXQoju7HyXu1sNXHh +lVMmD4PT7xika1yT6ydMhUuTBizrop121Zh+n8nIHZyw7YeHbFt3x3EBkdDs0BjLJl8E0cf0qJF +lHHcq1J5RxO50rjyImoEvZdPI2p06bjvlccqg1dgbmTu8JU8Rk12nVAHruiSo9Uwr5lz86Izlko meOF1Lgk1h7agUnT18PTNC8mlLVDr5FHEU4qVesKfbB9nR/WHH8GmW0+zFpUBxfu+qBS7faoYSam tp4mW3s17O3SFtuPvEFUOBGJvi6qtiSnIJ1isCSnoV6dO6JsdhLzRLYYPmEqNHZfRSzZXZnaV+ZQ HMULGeLaNQdyaKv0jdc+a3aZVoPRn5wN9cq2QUF9Uk2To9TVM9kwYdkBhNN+pcWYtRg3uPU357IL t52JE2T3X7bnIuKdymBDs7o4c0sEJ5eSWHLiBLKPHomzryNgX7U3Vk4ajaKmEtpYOKI9zU+DKtXQ t6gbYrUX4qXCCJNW7MSNA/tgLVH6VgjzomQZwcP6lUtdNCmdaLpJ/K5Mp7FY4S3GwTuvUbT+FLRt fo883g0QQvDo6OXBqMlTobfvBuIZDowHhQVbhkZjN2GXfm7suPAYRoV7Y0Pjj7gTUAiOLjro3aUT yuUyouukqNe+N/LolFf2WdceHciTXKdEfoG4TYt3wYmzNpgybRU+RCpQc8x6LBjTFiKPy2jfoQPy ulp/6QMkhui98jBs847B+tOvAJsy2DJvAloVMMFLr9ro0KUAEYtS7ncp0QgdOvjDSUsB7YKNsXTC bZx4TCc5IpUbP9aFBNLaxJC+otWgiXD2OYV7slrYRA5g7Qszybst1q/xwarjN2FVoi0OdmqF3ecC 4B+agAKNJ+PwbgvM3nISUaISmD5iKEY0L073RKFki+7oHuYEMe31zKt1x/L+b/A67CPi9BtjNW1C 8o8fjTOv6LdANvrlk8aioLkmwhoPxpiXmnhG+6qYaLoxSSlYoxs62NmS9sIeo3edhu3M/th7MxAu 1XpjzeRxKGFF/bXqj2tXbDB23lb4RytQvdd8TBjTGXpkAVp18iZcZ03BqYd+kDlXxt4J81E7t/Kc V7H2c3HKPAdmrDqK0HgT9F9/AJM6VaJvquKKkRMmrT1OGx1ddJ6xHWPIPyEVN7dkbeVv0o4AJ+q0 Y/XTK0X62TBs4cbk10n00Wr4WnqlvF2EfDW6YyO9VMVx9Dy0+vKuAf30laXegJVI4pbztSKZI/qT g9i3pynZyiJBnV4L6JX8uYWbjMPGJl8/K91iDEmoSa/RRfNxi9A82W0ilKVjMGVbJ6+rSIvB2JDs XtL4OpamH3LpVLHKX687ttFLVarVU/UQaD9uJdp/+cYNG5VHqoWi4VAMk1ftS4GrJQbMTIK1QXaM puAYqRXzgqTF2Flb+OrV7n5k3Ysj+zRJXnRcqUrnafT6eldH1Z8N+mAHvVSl+hfMpGg/dsOXti5f 9/WsbdFGA/EfvViJDfHHkwdHcf5GCBzrtEetnOzA27dFx94NizYlDT4iRs4qnbCdXj8uElRoPVh4 qUqbL9A6YeD8HVC25GuRWhXCFLIdqsrcrTu+/N2gpsrDQYGQz964c/AIHpCypXn79nAmN4ZkRWxG GMxPMl6NksxbOjLVdAi9Umk9Oe41GzidXl+/65j457K1SgcwVvpOWfb1AoM8mLactEJJioVrLSzZ qWpv4hf25TB/Y7lUHqqFBv3n0Sv5V7lqDKTf3tfPXOvQ+y9DaYpOE+loYsraSK3MjDRSh1IYP6Zb im81UKXraHp9/bj21x8zijbti530Sl600WAUte3Lh+boRacwvhTyTxhAR+IGpLhL37k0pq5O/TdW pes8VPlyvSE60OaowzeoiGBbqhk27P42foNI3xl9p67H947A56/VA1vplbyQHw4tNHtSLjapjAb/ 6PcQ4ET9e7jxu9QUgaho5tJDRP09U/Nf6teNTeNRecAKxFvmx45xHf55pLLf70YUNvRphEF7b8Oy XBs6p58a+f1+7ep8J3NAZIr1uJivmgd17g9vu/ogwIlafcaKt/QvIJCj9ijcutUTDnQmNz1LoWbD cJm8uHWss9HZcLL7qk3RQovp61BqaCQscxSCs9K/jBdCwKJwM5y6RSYo50Svb44KR+AfIcCJ+h8B zR+TMRDQMXVEcXqldzGwdoYbvdSvSGCdswDSdxujfqiwFmvoWaBQ8cwYxFc9xyMrtZoTdVYabd5X jgBHgCPAEVA7BDhRq92Q8QZzBDgCHAGOQFZCgBN1VhrtNPVVjienLyDQyAXli6dnir80NYYuSsCr m0fwKMgc1auWgkEWmbGfHj+i8KrOyGujj9c3KLqZlyFq1akMijD7x8Xn2RP46dmigIPxb9cVT0Ez 7njGo1hB5+9En1LgwZnjFNUsGyq65f6tWMWelBHs/NNoVKhVC/aUnCbk/Uu8iTNC0ZyW8Ht5BRef haNEpcpwMMq4B4E8nzxGsLEj8tlS1o3vFM/H1/H4oyYq1S3yg7Sgvz1U/MZMgEAWWfYywUj9oy4o PC6gTct6KDDmbAYhagV2TmmC8beq4YXXUYq2lPlLwL21qFJzHvocvEZETZGwds/E6Es54UrJPkw1 /yyKRPizHahcZRxarj/3+0Qd+wF9GtbAk1zjcGVd6nb42wdmo06jUTBrNB239o0SsrH9anlxmjK2 rQzE+nL1KEDJNTSs0houg3ZjHRH1wx0j0WziC2yi6GbtjX615n9zfejDjahcYya67bz0Q6IOerAL TXvswzpK9tEiZwbLv/5voOJP+QkCnKj5FEmCgALndv+HdxTham5b5TnNyE+3sWXfFYRTyknznEXQ ok45IZBBtP8rHNx7CRZFiyHy+Tm8DtKCW53WFOlIuWpGuN/Gf3svU7B+KdwadoKbsyo5bjhOb1mP xxSi1CR3GXSsXTLJ84NwdNUWvIyg7yiZR9u6peluEYX6NIKMQip63D6PUzceQkKpOVs1rU6ZrFIO XjBlQdqC5xQpxChHCbSrVyZJRC3g0en1OPuYYihTjObmHZrChtbEZxe3UcYqC5ShBfLCuTtIsMiO Fq3rwujzA2zYewM2RaujdimlZsHv5TXsO/cYZVt0hsGrI5Ra8z1EetZo2q4V7Cg6x5PTe3EnSJMC hUTj9lMPlG/RF0V0XmPT1pMUeYvisjvnR4tGVSkcTWKJ/ITtW/fCOywBGhbZ0LpNfeh/foSls5bj td8HCu+5HIWNuqBY/d4YlEuf0gYm3hfhjp1b98GTouFYulaj7E/5CXAv7Nt3GDo5y8DA7yFuvQuC NbW9RRkW21xZoj4/w4rZi/Dc5z0lfViNE5bdKW6zPWUou4b/Dt2gGOUaKNukM0o4qFoYhyv7V+P2 ewrzoaGNyi16Ir95FM6unoOdV1/BIPYo1h7MhrYN3JRhU4WH+GHnvAFoPW67EKAkD+XqTra1UITi 3K6teKtZEO0alYZWjB+O7tyHUJuyaFU1H+IC32DP7jPQK1wbrhXbYpB2FBzkb7FjxXRceP8R0ec2 42AxMxgamkCkbw65911sPn8LIVpWlBilOXKbfrukvbywE8fueUJkaIcWbZvDWjMB9w9vwTUPDdSl rFqOtIt4RmkrzzxSoGHPpoi5eQJXvXXg6hiPK9df0NjkQ+u21b9sEm8fXIfLb0OgZZMX7VvWFDYh UfR7OLzvIgzz5UX405v4SIHPPG5uw6vP73FlxwoUMeuLyvl0cXrHGjymwD1SHSOKONcZOejnkr9+ axQduw7/bTyExtObJ5uzKWc4f581EeBEnTXHPfVex/piz95diM9JqSfJuTWS4o53aNQEZ3yNaDHy hcfnSJyYfRibhtUlAr+CoT27wdvYEk5Gcnz+GADFgv+w68wllIvYh/r1++NucAK0JWGQz99Lwf53 oGMxYHrXtpi95xo0dPURRlGRjvaZi00zOkJH7oU5Pdth/LrL0DXVpuQSEdg1YhP2TmsDLUpckPDx GAb1eozPn97CNzAKN31PYiPFRlaRQAJl/lnYtwPGrL4AHVMduj8M2wevxYHZnaArokxgk/qj14w1 iNczRVRgGFbuPotde5bgztaR6LbGA7lcXRHq8RLegdHY+WgHTvY2xZwBveBRoh8+XFkMc7EC++f1 Rs813ujx8iEubt8GvwQNxFFylUU7b+HY0am4tnYaeuy6D2tbW8RqZYNp7jzYMLcztj2RUJatEHzy CsW+sduwZ0oraER/xNgWVTCdUk062lvis/s7HP+wCyurx+H42ec0PrE4tWUtXCvUhv2FsRiy1RkV WjamWOs30admC6y/+5kSjGkhKGQabszZjpktdDG7X0/cFDugoJ0GXj2mSGoUBcx/3xH0qUppx6hE ej/GweMP6S8FLuxaixxlGqCQ4iKaNR6Eh+EiaCWEIX7RASzasRltS1li1/jW6LP4MAyMzfHxgwf0 SAo/fmAxzh0/Aroc4Y+OYPmuwmiahKgVn+/RWF9B895D8OHwKmV41WRFhAubx2HKybwoFXMJLs+P 0KapJyKzNUfFNzshv74VrXtORK9tr6H7cQGGjPeDRbZ5OH38kjDW909vxm63BuhmYghpzCfKt9wX 8T4eeOcXgII3vHB27VBQELbEEocTS0ag8/jViJPpIIbGatnuW7TBnAnNsOeUW3oGTgaaYHNzEZrW aIPg0kPRsndznFw1Bd2334ONowPk4eHwDQjCoYdrsX9GG+yZ3BkDF+ynzG2UmpIir209Pgr714+E lsdVDOnRHd6U8MZOXwxdKwfEez6ldshxZvtG5CtXHh7bF2LQ0vMwNjTAW8rGNnPLFZw8sgoFjFxR L78ORh/cifejm+M7sXH4SpWFEeBEnYUHP2XX5SFv8epRNLJ3zClkpHr54DT2kARapddELB7fELdW rIGHsUwI+sDS8zEpypTimZ8/shT6z3egcOnWmDN/PsW2XoXbkhK47X0YeWUe6FbSFaOmL4FlUwmm bD6HAfs+YGYjR1xZ2BHlBo9CHYplXc13A8atO4du215iSSsj9C1fHvf9QkBRIiFKoCxbYZroseIU pdOUo2vxnNiyeh9mEFGrchu9PL6WSPo0OlB6whXtLDCgUlnc9AsSQrDKHx/AqIlrkLP3Rpxf1gEB FxYjT6UBmLqsFmpSNiUSR9FhzgGMqEJZq4rmx+oVO+A1az9mDCyFJotP4vqHeNS3e4UjJx/DsXJd 3N2wAlrNVsJ3bQ/SJuxD4VJNMXaVG+qZUPxWEYVWpM3CyNoU6/zMLHQ974XibaeSlNwRrzeuwFND bWV40bg4WBdsjoOTu0D6eC8mjhqFY7uPQDZmIzYuu4o8LfdixqHL6FfBjsI6EvPo60NXT46T48dg 1a1IrLz4AT3KGWJd5wroOmIcyuQeLSS9MNCviD0318Hg+hLkqjIY+4/c+0LUpoWI4FfeQ67GazB6 23WMqWuCIW6VcE+3Nh6+3onslO6kXdGCGDhpLRof7oKDW/YgWN8N09auQeUE0jCcf0c5SYwwbcNm HM9VBdqNFuPS+k7JbNQKPWcs2XEeJUgarXx0OcITk758mWsUM7pZ+25YcHIuJUqJhc7rR9DS10aC 2AevveIRff8aZa4oi+71syN4CUUYpxzaRrlrY+2GeThUsA+aTTuC1QPK4SKl2YyLjUHprguwrl8l bOhZEN027sIDSo1ZxVZpyI96fw5jhi2AdecNuLu8I4IfbEdBCq83YnEtHB41HWtuXMCg2QPQ4FAM PLM1xNm9c2ChQRmyKMsWpYBC2+kHMbN1AezoVw2tF87DEidfrJhCOcDnXsTeIeXx/vA05G84FvMa N8NUVwPh92Bbvjtu7JsMK1pZn+7oj/ytdmLqwZsYWMEflfUOQe5QHVPXrkCez2ew624I4qPo12Sk jRyUuzvu3DuSwCOIqJUZvXjhCKgQ4ETN58IXBCK8P+IDJVgonU2ZGs+mYFW0LrIZ21YMRKGdC1G0 eAUMrptfWJDYAsxUm1WbUIIDlrHBtToaFnXA3lObKJ2BFAr/a6id14GSYMkQRRJJ4KsrOJ3NglzD pPhvYGVsG0Dqv3jSDyYE4eHdF8il5UsbAB2UdKVsVxQVe/bRR9DRZ0r2eERROk04VEK1kpaUF4Ey eTmaQ3EjjNJ4fC2+n9yJALVQoiC7X0Yk9zDxfsow9vAO3OnTvm0aCs46NhUbUtzzEXhw4xJcWfpM q2KoUZriLRMf5ilKH3xgscuA6h37wHFeO+y+8BSlnI/iQqg9BlYpiD13jsGHJGhnh2nCPR4Uz1ly 5haKUEICbYv8qFyStYE2MbnLo1MZB6zZMhbFDq1C8WJl0HtCZyGjU4KGEbSkfphI2crElHvyUyip +A1iBUlVIlGKhGJWuapINCCJDKAYzc9h5FoJdcqxfMZAnU6tYbxhKG4+ckc0BT3PU74WJf+gn3X2 PLDSEguZtJIW9ixWJDJCgvJav6B40YqAc6iai8aKxibCN4zG6ipeJwxH824dcGzMJvSoWogScRRF uUaD4GpDOv6ABEG6FVGSipS50qVmlL+Y5YgIuYVoSnDBUk+mLPkq1EA+qxW4eO4E4t+8QbU2PRD3 /AkunD8L+cWHyFlzMAoSV50REsWwBzEslO0WJf6bIKfoYJp2qEXJIyT0vZ0LzVmynYcJsa+VRB3m +QYeNHXk+8fB8ch4GqsEeLKMqievIGJUFUrzuAgb95fApVvAsF3HQBp1KrQpjImAlFJ4Nq1VSOhn jfYtYbesBw4dOk+Zv8S0wewAh0XxkIliaSMZj/uXHiKkmEyI5V6yZg2BpJWNVXZexNKgwgVtutfB jQVH0apMfuQrVgTV245GTjOl0cAxWyGyJ23DO49gysbDifqbSZPFP+BEncUnQNLus/jXTFpW5WfW ca6AlfsPocrJu4gOeYUFw+ah+aNAPP1wCE4k6TAK8A9kWYNZiYBveCw0dOwgjngDHYtc6NynFUyk CkSGRUCmTUTovZPIVIwyjbqjfHZdylgUiRhaV0sWpxzFt+OIkmPwOZCtpPr4cOM4vAwLokIxyqXM qqf1jOXMhhZFW6ZNgphySCfJUQKpRExEE0NqcXa/ET6SndFDLy8qlsgOXX09wevYL5BlSCKxMy4U n0ltqUGZnrRktN2gRM+UfItKHGJZBifKhc0ygunlqYPGlZ1wetd/WOF4C4bZKqJW+bzYOEYOW7ea 6Fq3IETyGERGRcMiV0kEkU0+gfJ1J6Z1hoZ1cSzcfRRlj11FVMRHLBsxg9JHeiOv5wU43VqNbpP+ Q+Nxq/Df5A6YXdkQk0K0WevgT9I226xo6SoXbJYHmaX9TCByNdTVRNSnECFhBzNmspzLoaT/0KfP BdaUKok5gTY3LEGakNs7SVGmgaRNgQ7VLQpDdHQ4RU8rhm49G8NQEk85wSMRr5UdFqTWzzdiGQ7m r4yXPpG4tXMJ1pAqXMMhH5Y2IrKmGKwS2Q8cn5gm5Du/LbF1CTQskQ27ji2Hd4wc5fo2Rz4dD2w5 tB4vXxig0fRqwr1yVQJw1n0h9SQNlWYiibEYsBTPXpFI5nGUyYwBIE7SXxbyk+VWy1asLjrWyAdR HI1VdDRMnCsJfgJ3j+zHa4pnrq+tieNkyhjSeBIsifXFrF7Kpx3MbibH+Eh/wjhBB/o6UqpPgaKV W6FhcRvEx0RRrukYZC9VgAbivvB7kAnpOJVFmTpTBA1ttuHUQvvpm2Ff9gDc/SNxbt0cLBjYBPoO 9zCpUZ7E35wOdNgmixeOQAoE+KzgU+ILAjrm1rChxf+Vh4/w2ftTlNSjx2JUG0DJQkpURxHXlfgQ YgC2liTQYsaW6VOLh2FR9igYPN2Pbfe80XX1dtT2nonmE59Bxy4/itiEYNWACYhoPh1zm7bE0vmH 8DlMG0WKFMGTfUuw9ZoYFXsOQwG3isittQKrp09B9p7FsXpwC5yWNcaLW3tIcqFFmGJ0q5bA+LhY xMbKk8mKOctUQT7t1VhD9+cOKY11Q1vgWHxNPHh4BHnK1EUVuxlYMmooXONbw+/8Wpz1NMGsDo1g fnwjrcT6X2J/x8tpN0B1C2SrYYzOXVphV6cZmEQq25YzZ6JUGUfUKmSA/2iFz0Z90Ha/ijETj6HF prowTYhDdCxtGBKFWM8ra1CjwzSU6jodXStWRskia/DklT4MaN1OEKTRGGhraOD8hslYcp42EW5a gqOehpT9fwiuHTsAN8sGJE2yXKe0qaH0k/W6NMSEJgswZtQKtC9ngi0jFkOvYHs0LO+Mc1Posi85 RxWEEeX0TqF61pCxusNw6/hOPHKiTGpN3XBhmSf0nAqiiLkvlvadAnnrWRhFNv9+9SriuKI8Fk/q glpVi2Ht2Ve0ISCSlkaS6UMBzxeXcep2YVQmU8S3CwklsIiNpeenlk1dB43b18CkxjMQTfbZMRVL wpFs663IbJJAubDrVCskzD95PO1GYpVx2UVCu+Pw7MZR3KpoiwS2KSGSjE8EW8GuTRHD3Zwc7Rrl 08N+StqdY1QRSN9ewOjpx9BmQ2dEUZrKdu1mwKT7MmyoG4Fa9Yej3WhXnJjVhJwXDaCgvMoTRoxH RNNC2EsJSELtKmMY5VVPuH5aUNEXprH3ubYLk3Y+xYQW/WFIGw4WATw2SX+V4xiKW6dPobyJI6Z3 6oCnFnUxf2gTSCsVxPZb5Hymp8x96uVB2b3ElLPbKGUGFL5AcQRYTjleOAKJCGha5UPhEkbYevel IIk4l2mBse3uYeC41lhJBGRdsCK27p8BZxJlA4jMmNRXmtIP7h7bATfeRqNO75mY2LYCbBNcMM+3 L8a3rAZyaEbOyt3xX+OycKK8ibv3BqB33yEot1EOsVkBTJq/CkVMScIzbYKduxegc7tRaHyK0lu6 lMH8BZPhQuexJLpmMDYj5yGhnSLokXOThblBMrWrWYGm2LF3MTq3GYHGjRdB07kk5i6cQQnu6X79 Ylh+4BCG9m2LNo33UOrE7Bi1it7XyottJ3VhbG4MaaL4p2tIz7JQPYs8chu3gtvkVTgZ7YoezUqQ hCrBtF2ksu3dEQ3LUcIKkQFqdZ+L1kXz4ISOAczNdGhjoQTUtlhDTOl+C31ndMGmiZTGMHcprDu4 CLlI+FW4tcPU5scweUp7XCpUHc3b1saeq2/xyFeBUmUbo2aeTdg+pTd0KF1hKTt7aqMRpQAFpUyc hP1z5eg1pR8OLCA1fomWOL51JoqY0MbI0JjU54lSrkST8p2bwlg/udRrV7wuGhVag4Pz+5FDlD22 zdiJwKjuGNekMiJorPJU74P/mlA2L11DSsM6Ae+GDEP9chshIUm2zZTNGFyfHNNkZmjZpBwmb1uH LgO1cP3qXNil/BWJpDAxt4CGoW6qkrVzqSpwM1yOp3bFkN1aDIv8pcipygCi/JVQwEoJoKauCY0F GUtI3SF1qYQ21VywecdkjNfPgaFFrem7z2Q+UF1rDGPjWGgyPXhiERvmJsfFYxD37Eh92E7T1Rj1 +y9Em2LaWNxlAj46l8Le4d1QKpsI49tswqjNE3G8exlSpSugZZYPTtG3aL5Mh9iqKJb/NwcVS+WG 0+Ht6N+lByqWm0tCsj16jF+GGjRJI59IYWZsTOlPv57pdnarT+afjXS8sCt5ee/HmBnj0KfHQFQv t4Tys5ug1+Id6FLJiVobj5d3yFSTtzjy2HC1N1+Qv0WAEzWfFV8RkFqifIXS2Lz2Ap5FjkdRAwe0 m7Yd9YcuBRPMZDqGMEhUzTF1bAzJuDnrDcSa7csREqWAMTlTKdXR9ui/9ADaT6Ik9vROx9gU2ol6 6kL1++JCpdYIiyX7pUwPJgaqCB4SuNYdiCvv2yOCVJ4iTX2Y6CkXvS6LbqJ1vAyGwqV6GLaanKzo ffIz1WLkr9UPl9+1QXiK+4UWFa2BnRffICCMNhgSLZJclAti02kXUHuihDyo2TsZus87hbZxEhiq 1lutAthy8w0ixLowoXzRrJjlcMPaE/cxS9CNSmHKvLiotFhwEPXiRTBIbJhYl/KTj96A6r3nCqp0 qZaeoLpmRaxti5E7zqA7eadr6JlAT0OBqeT8pm0khkxWHgdvvUU4YSTT1INMfBy1Bqrq1UeNIYvx iIiGaek19E2hNOUXIScyyj2uoTyxLHKqirPPX0FM9yctMms37LzyEmExCkikJL3paGPg6iPoOCNY OVYmNFaJXJerQlscudoAgWTSYBskU1Mh2TkVQwxddgKdZzIZMuU4qC4piF1XnyFBqp1q5jCZdUUc evcOcRJtMlRQ7fma4Oq7KoiX6grqf1Yq9duGN90SoGdAuEucsPTgfUyNihParaVZG2/qyek75bG/ Kn3W401nBfRTSKSWucthw5lHmBvC2qoaKzm6zD6F7jrGNKbMwQIYuPEmOpBpREJOezvDQqGQmmHQ 8uNYRue4QfPUOHGeOhVvgoM3qyIwkqVJ1YSpsRJfRe4GOP+mKiS0WVMVTYeKOEBjwrCWatJvR0+G M3cbIJjdSxs+UxPWcyqx73DhfhgKVqxER8WSGnS+VMX/yOIIcKLO4hMgefclqN+yNUwWtsP63c9R tEMe4WtDItqURUHOPEH0oW9QOKTaRqATVSmKCEamqade0tA3wfeSMmkZmXw9k5tYo7aecZLFXgRt faPvpo3UpPu/G7xLw5DIJnkzteiMdlKZU0vP8JvnazJJNWX3JDpUV3I1pZb+t/ey2/SNvtNbkQZM iBiVhRZuc8GbSSiMvFW0yJyjtFLgq0d1JqNgCREm9f1LIeczQ+Mk75O0X0a2eZNkgpvku2PFNkyp RkOj404mJj9Q05JEbWD0o8hnEugxL/kvRUyakuTtlWkbwCRJv8Up3msmGRSZNm3svpmDiZUT+Zua Ju2wFOaWVslGVETXmFiwa+Rkpw9CrG8kOUyKYGz97diJtGkepXiWmE5BGJp8O/NkbByTDJQklXs/ ntqKox8TMKN9KzVKh/rNksA/SEcEOFGnI7jqWLVugfqYN3YagnSZU9b3i651IQwaMAAOJdM/E5U6 4sjbrK4IiFCieS8MKiSFwz/SQkfIXDB6+CK0Lft1o6au6PF2pw8CnKjTB1c1rlUfzelM78+Krl1x jFtY/GeX8e85AmqGgASlOwyFMi7fvyl5a7RH3hr/5ln8KeqJACdq9Rw33mqOAEeAI8ARyCIIcKLO IgPNu8kR4AhwBDgC6okAJ2r1HDfeao4AR4AjwBHIIghwos4iA827yRHgCHAEOALqiQAnavUcN95q jgBHgCPAEcgiCHCiziIDzbvJEeAIcAQ4AuqJACdq9Rw33mqOAEeAI8ARyCIIcKLOIgPNu8kR4Ahw BDgC6okAJ2r1HDfeao4AR4AjwBHIIghwos4iA827yRHgCHAEOALqiYDaE3VUwAdcuXwXAZSvGCIt 5KW8xK52yow6vHAEOAIcAY4AR0DdEVB7or69ZTGmHw1B43qFkCDShiPL/ccLR4AjwBHgCHAEMgkC ak7U0Xjup0DtoVPQr7pNJhkS3g2OAEeAI8AR4Ah8RUC9iTouAB/fXsGVV9F4f0AMx7INMahVdWgk Jr7nA80R4AhwBDgCHAF1R0C9iTo+BvY5GmJgzSYo5WSI8xunYOp/hpjcvuQ345KQkCB8JhJxFlf3 ScvbzxHgCHAEshIC6k3UWi7oNXnsl/Fyy2uPHduPwq9dSZin4OOlS5fiyZMniI6ORtGiRaGtrQ0V eWelAed95QhwBDIHAmz9io+PR5EiRVCqVKnM0Snei1QRUGuijv38EDuOPUOtTq1gTt2LiYyHtokN dFMRmrt27Qq5XI7Ro0fj4MGD6Ny5M8LDw/m04AhwBDgCaomAWCzGhw8fYGPD/XPUcgB/odFqTdQS LR28ursbL8ITUNJBF+/ehaJuqzbQSQUAJkGzoqurK0zswoULIzg4+Beg4pdyBDgCHIGMg4BMJkNI SAgYYfOSuRFQb6I2zIGpM+dj66ZdePkSKFR/MKq7Wv9wxJi6SKFQIDY2FnFxdPaaF44AR4AjoIYI qNYyNWw6b/IvIqDWRC30Vc8JbfoM/8Vu88s5AhwBjgBHgCOgHgioP1GrB868lRwBjgBHgCPAEfgt BDhR/xZs/CaOAEeAI8AR4Aj8GwQ4Uf8bnPlTOAIcAY4AR4Aj8FsIcKL+Ldj4TRwBjgBHgCPAEfg3 CHCi/jc486dwBDgCHAGOAEfgtxDgRP1bsPGbOAIcAY4AR4Aj8G8Q4ET9b3DmT+EIcAQ4AhwBjsBv IcCJ+rdg4zdxBDgCHAGOAEfg3yDAifrf4MyfwhHgCHAEOAIcgd9CgBP1b8HGb+IIcAQ4AhwBjsC/ QYAT9b/BmT+FI8AR4AhwBDgCv4UAJ+rfgo3fxBHgCHAEOAIcgX+DACfqf4MzfwpHgCPAEeAIcAR+ CwFO1L8FG7+JI8AR4AhwBDgC/wYBtSDqyE83sOnMBzRr1xJmKVr8+fFprNx4EpFSCSDSQ+V2vVAj n9m/QY8/hSPAEeAIcAQ4AumMgBoQdSgW9+uMUa+Ko27HlingSMCtffvxODoPxveoAIUCMLfVS2fI ePUcAY4AR4AjwBH4dwhkeKJ+e34XDj2LRqECRkiIJ2CStjghCu6KBOQuXRxmZmYwtrGB9r/Djj+J I8AR4AhwBDgC6Y5AhibquIAbWL3jDbqN6oej518gRp6CqGO88PL6RTx8IULoTSm07HKiZ5ducDHV THfg+AM4AhwBjgBHgCPwLxDIuEQdH4pdq3fDvu0wdHK4jv1nXkNfKwUkEkO0GLoaw0uXhR1pvK8s 649JSw9j7YSmkH0HPW1tbWhqasLQ0BAJCQn/AmP+DI4AR4Aj8NcRkMlkkEqlfB3768hmvAozLFEH 3tuHRZuuoLzUFlN2XsaLxx7YuPMc+raojC9WaJk5ylQ3/4KqnaMDQi8+QFBCU1iIvoL99OlTHDly RPjgwoULCAkJwcKFCxEdHZ3xRoS3iCPAEeAIpAEBsVgMDQ0N5M2bNw1X80vUGYEMS9S62atg4WoH hIRG4LP8FbR1Q2FnZ5lMUo7xuILRs/ej86x5yEfGaV9PX+jnKA6TJCTNBodJz6rJfOvWLWG8XFxc EBkZqc5jx9vOEeAIZGEEJBIJAgMDyYmWvGh5ydQIZFii1jS2R+ny9gL44Tb+2PUIqFomHzQCnmHj iaeo1qApbCzzwy3vISwaPgSWRjrQMLZG/+7Vk/mbsfvt7OyEFyuMqD99+oTatWsLkjUvHAGOAEdA HRFgau+zZ88iLi5OHZvP2/wLCGRYok7aB63cDbFqbk0Ip6O1FHj19g3y+sth62SEpj2nId+dm/CL VMDJtSwcjMQ/7H5sbKwwsSMiIoQXLxwBjgBHQB0RYEQdHx8PkSiFClEdO8Pb/EME1IKopTrGsNdR 9iM2VIz8uRxhZalyF5MhT7GyyMMHmiPAEeAIcAQ4ApkQAbUg6qS4S02zoVE9J5DzNi8cAY4AR4Aj wBHI9AioHVGLNTShrZHpx4V3kCPAEeAIcAQ4AgICakfUfNw4AhwBjgBHgCOQlRDgRJ2VRpv3lSPA EeAIcATUDgFO1Go3ZLzBHAGOAEeAI5CVEOBEnZVGm/eVI8AR4AhwBNQOAU7UajdkvMEcAY4AR4Aj kJUQ4ESdlUab95UjwBHgCHAE1A4BTtRqN2S8wRwBjgBHgCOQlRDgRJ2VRpv3lSPAEeAIcATUDgFO 1Go3ZLzBHAGOAEeAI5CVEOBEnZVGm/eVI8AR4AhwBNQOAU7UajdkvMEcAY4AR4AjkJUQyDREHel5 G/uu+6Je4zow/HGmy6w0vryvHAGOAEeAI6DmCGQSog7Fwn6dMO5DGXg1IaJW80HhzecIcAQ4AhwB joAKgUxB1G8v7Mb+O8FwdTNGQgJ1jedR5zOcI8AR4AhwBDIJAmpP1PLAW1i74w06j+yFs3c+I4YR NS8cAY4AR4AjwBHIJAioN1ErwrB77S7YthqCbpbncfxGAAwkPx4ZbW1taGpqwtDQkKRvzuqZZB7z bnAEshwCUqkU7MXXscw/9GpN1L43d2De+uuorXsQ8/afwuunfth+7AY61S4F7RRjd/jwYXz48AFX r15FcHAwVq1ahaioqMw/wryHHAGOQKZEQCKRCCSdN2/eTNk/3qmvCKg1Ueu5VMCUuRYID4+El4c2 pDJN6OvrIDWnb319fZiamoJJ1JGRkYJEraGhwecCR4AjwBFQSwTEYrGwlnGJWi2H75cardZErWOZ E7Xq5hQ6HOgQgKMfXqBWOVdopgJBxYoVhU9fvHiBT58+oXnz5oJkzQtHgCPAEVBHBJja++zZs4iN jVXH5vM2/wICak3USfupm78plkyNgcFPvL5jYmKEiR0WFkaSePgvQMUv5QhwBDgCGQcBRtRyuRwi ET/mknFGJX1akmmIWtPACrkM0gckXitHgCPAEeAIcAT+XwhkGqL+fwHIn8sR+FcIMMFJIhELNsn4 eH5i4V/hzp/DEfh/I8CJ+v89Avz5HIE0ICAWi4ikRQgNjYWWlpSOGIoRE6MgtWcabuaXcAQ4AmqN ACdqtR4+3visgAAjaX19KdaseYft298iTx4TTJ3qCl1dCXn9xnOyzgqTgPcxSyPAiTpLD3/m6DyL W6OhIYaOjoQkzjhlGNkMVn5V8mV90NOTQiYTC0S8evU7LF/+inolwrVrPhg5MgGzZhWEubkm4uIU 5BgpF9ThaX1ORsQogw0Zbw5HIMMgwIk6wwwFb8jvIMAIh0mW7u5RuEGR6Ro0sBG8YBl5pZW0fuW5 7HlSqUgg0PQqSlu0CKdOfYavbxS8vGKwa9dHehx7JtN1a+DWLV8MGfIQFSuaEUED9erZwMhIRl7A f3+XolAk0EkJRXp1l9fLEeAI/AQBTtR8iqgtAkqpUwJ//1iMHfuIzsj70Rn5CAwbllsg6Z85XDGn LKlULBB9WgsjUD+/GLx7x472pc1ArK0tweHDXrhy5TMUCiYh//w+imVBzwgl8tUk9TYjSfZK+nOV 4N69AOpvJLUnklTiHwkLDar/x0TN+szi/LRu7UwRrfQRHf0zAk4gfKTIkUM/UVPx840AGxcm4bO2 pKWvrE0ZQcJnw2JgIBNs/1FR3KSQ1t8Evy79EeBEnf4YZ/gnqKRETU0JSWSKDOekxIhOueAnJQmR oO5+7RWCQUPvw+NFIH0vw86dLxCqiMWEIflp8Rf9MGoTu9/bOxr793uQxJg2UtHSEuPhwxAiST96 XtoJnrW9Rg1rsjXLfrqBYBMmIUFB11uhbVtHBAbGYvDgB3j9OkjoIyNtDQ0RJk1yRZ061oLkfe2a b+Im4MfTjTmhPXsWSvc+SEH837svQdgANGxoKxDvzwlVQWSnSQGF7MjpTfLTjQN7KtNOsA1T2iJs iQg/hbDBSMN+J02/PdYnmUwkzDHmB1C4sDGKFjUWzCi8cAQyAgKcqDPCKPwf28AWKUY+ERHxePIk CJaWOrCz0xbe/+pCyJye0noPsycz6fRHhdWlIIHv3r1gkirZovn1epUX9PnFITB9ZgRbWAhEzqjc fXccGl+5jphY0gn/oLDnh4XFkvSUAAcHHUFd/rPC8KKcLhg3zpWkTD0ijB8/Q1Ufe5arq5Hgrf0z qVd5j0i4jkmmVlZaWLCgEJH1fbx6FUh1aGDCBFfUrm2FoKBYlCtnhqpVLYX+/6wwQvT1jcbbt2HC RuZHRTWe69d/oAhY3nTpz9X9jPDc3cNpw/SRyO/nRC0WK1C5sjWqV7cUHON+VkSiBJiZaSFfPoM0 bXhYfaxeZhL43txkY8M2bXPnvsSOHa8o1LABFi0qQhoHA4SExKV5Tv+s7fx7jsDvIsCJ+neRywT3 qUia2TinTHmGixc94OhoiPnzi9C/OoJEwaRZtoj9rLBFMCxMnmjL/DEBMBvvunXvSbUb9sPFnxEF k55OnvxM1zESTVqvkpSeoi/ywjxZ894iGI2NNqF0JWPERn+/5UyCk0gSULq0BQoVMkyDGvhrXb+y KVHdFRkppw3Qz5D89ntG1paWWpgzpxAR9EPUr+9AJG0tkDQrTE3LXmkpSulRTJsG47RcLlwzd65r GiRpZXVsI3L2rC+ZIYLp3Y81Dmwe+PvHEKm7C6+0FQVJ+JpE7hY/tZsrN1Uiku4dhI0YU2mnLGze fiXpd/S1FgICosj+fw/z5jGy1ieyZtG/0tY6fhVHID0Q4ESdHqiqSZ1M+mF23LFjnxBJe7JlFh8/ hgmS2/z5hWkxN8SdO0ECoTLp60eLFVOb7979CY8fB9K1TFX9fRDYdxERscid25AuYurpHwGmQOPG tmjTxlGQeFXXJpBklUAkazeE8qSlWOMtLDUwd4krLG01kcCI+oeLrEiQikNDf20x/rkK+O9NAoYX I2sLC03y9C4ieIMHB/9efGeV7T6txM568SskxZzOKlWyIAnZiu78sYTPVM0xMfFEpPaJau+fSfgQ TBSrVr2ljUAItevHG0hGwG/fhpN/gCfZ2VO336s2LqGhMdRethyyNkjx+XMU+vW7i2nTXFGkiNEv beL+3sjzmjgCSgQ4UWfRmcAkQrZIDR/+CNevM7WmKpOYTCDrnj3vomBBI/ougEg1hiRPlvf2x4TK bJldu+ZIg3pXqb5Uqmt/XpJG4kqgtTlejxyVZArIgmWQMa+rFEVTJIFhtBb8KKtagoxUnnEiSCN+ PtX/Jfn+vNfJr2BkySRC5vjG/Aj+ZflVXCIi5GluHusX0978Spk/v2CanNQYUT9/HkqbzQAyI6S+ 0WQaoytXAnDhAtuoMvu/qig3cErTBhenf2V8+LV/H4Gfr15//5m8xgyEwPcceNjizFS1JUqYEPk6 w9j450d/mK2P2VPZJuBnhUnyTEpkJVWJjZ7PSJkRMisJYpKgiXQlERJYbbMW3ptdNIP2x28XeQ0f TRRvWArurd0RZReFGPMY+FX0g0hOi3U8vZhtluoXx/5cpf+zfvzr79Pj+NW/7kPS57F5lppK+kdt SquEz3LusE1Arlz6362OzVl2tG3yZDGOHv2USNbxlAZXRtqLwihZ0oS0F9xO/f+cI/zZXKLOsnOA OSoxx6I5cwqS6ltMqm8vwoJJ1XFkz9MXVN958hgIqknmYZtWqYrZqX+1fKk7kd8ZCccZxEESJYHu R13Ea8bD5qANTG6bCESt+14Xcl16DuPZVKR8OUncvpV9YbvPViBnSTQFQskXKpC7RwsPhOQPEe6L dI4UiFsanrhf/bkv1q92jV+fDgikdS6qtBA/2ggo7dhicg7Mx7aMRNbvyLSgi9mzOUn/6dCxDIUD Bw4kHwCVtu5Pa8w894eEhNBGcBbs7e3T1CkuUacJpsx5EbP5Mo9vFo5yzBjg0iVPImmlM5mzsw55 B8f8kn3yl1FiUjPZmRWaSqlZROpJhYSOHgVrwG6PnUDI1oesv1TrV8EPcgc53Nu5w6e6j0DA9jvt oRGYfCGINY7Fxw4f8WbgG4GoHbY6QCNAA3pv9ZBvLFuQAUbmn1p8EiRun9o+wrOZ3VvQctI/rG5e Mj8CKjJnZD1iRG6SpKWkRTIVNElMkubl9xHw9fWlTX40pk+f/vuVZNI7x48fTybGj5mHqN8+uISP gSLkL1UOFqmYsuIi/PH00QsERjHnGhmcChSFi/mv2bwy6Vz4abfYIsWkZUbWTKJ49cqWVNe6NHm0 f9m56qcPE5iYOJCRIZV43XgoNMjOHCKD4RND4W/b3bYwemAkSLiMfKOto/Gx3Uf4l/cXCDeoWJBw nSRGAnE0HXMign/X851A9kkLk5KZ5C2ozcns+HrAayRoJECTVOIGLwyEzYDjf46wPWArELjzOmeh Ds8mnggqGiSQNpO6mQTOCPsLaXOJO03DrG4Xsd8Bc4JjJhsWLIdJ4Fzd/eejyJwFzczM6MRC2nxR /vyJ6lODhYUFzbe0m94yrkRN7rrnVs/BqpteyGMrwtYjtzFkTH/kNU3e5Ltb52HUtveoUDE3qUJ1 AZu8nKh/Yb6qyFpbW0xShLngWf07Z6h/9Mh4nXiB9MRxYsEuzEiRSblaXlrQ/qQNs6tmX273bOyJ eO14gZQDygQIqmmFlIJbkF1ZGkljn+J4kzTs51NYFkpsTSTLiD2gZIDwrBBX8hqmOm322kAzQBO6 b3WRY34OZTto4faq76W8vnQAAtyoHUzaJ+Jn/zKVfBqOLP/CKPBLMwICzBzEzk0LU+DnbhYZockZ vg0KFgiBl28Q+FVcfr7K/Z9ATohyx7UHAeg6YQWqOdI5345VsORgaazoXCpJi6Lx+EM0ao1aiOEU xYmX30OALUrMSUku/4FzVxqrFiTmRK2xXEdZn8ktE4HgjO5RYJL9ZDcm8mUe25EOSq/s1wNfI7BU oPB5aB6yJRORC5IsI0Qq4pi07zy/20zqo2CPVnl/J0r3n9p+Ukr21B7dd7oCGTtsc4DhY0NB2rfb ZYcYixh41/JGUEkWGQwILEFH0KS08aBNh9A2VjdJ/LxwBDgCHIH0QCDDErVIJyfGrlhIYlAU3O9d xOswQ1TJ75wcA3kIPH1u48rWWfh8SoxsFZujd72S6YETr/NHCDCiJ+cugWAjJV/I0Gmdk2BnNr9A AUkSbb/MHhyeMxxxhnHwrs2OhdFXLNQnETz7VxamlH7TvTBzNJPSEyVy1vaw3CwAC/Bi7AtBimeS tsUpC+i/1ofTJic4bXYS2uZfzh8KLQX8y/rDr5IfxJFixJqQ6YU4W3BM+xftT3eA+AM4ApkDAf9H JzBl/WlItO3QbfhA5DGmxSjkORZMW453eoUwYlgn2JFG8d2t/XgWnQN1y+dPteMPjy7G2lPvoCFV ChByqQmatWuL8EeHISvSGlVym6QbYBmWqFU9jnx/G3OW/YcA3WzIZ5bCezAuhCJnFUGT6k1QxtkA 1/evxLx4HQxpWOC7gEmlUjoTLCG7rJbg6JDVC5NoVXZjFRaMwNjZ41QLfaw6MhVHHuJx4jhBpW1x 1kKQmo1vG8P2jK3yVuK96BLR8O3ki08tPwnXMbszc+Ri9euEJ/ElUGnI/p8Ooqo2sK6TMiDBJAGf u3+GP/lB+HTzEVThtntsYfiIpG1/GSwmUNjShXQdqUzfdHyDaNtowZ7OvNRlCjrjnXgul/Wbk3dW /6X9/f6ztYzZOdMWI/3vP/9f1PjyZQAdrzP97UdFuZ/H2NnbULLzINi/PoAxU+Zh48z+uLJqCTzM 3ZA98BwmrbXH6l5FcPDUHbg0LPPdZ908vRcv4upjXpdqwjW+z45hSqdu+JDgjR6z6mdtotbJVh5L 1pXHlSW9MGLqWuxfNwwGKg7RzokRyxZ/AVb3jTUG7NqPjg0KwDQJz9y+fRubNm0Srrt+/Tqd3w3H xIkTyYHk96I7/fasyWg3kuTHJEqmEk5aGBHHmsYqnagSJWEmMTMVMSMdbU+KBkakVk9UD3Ui6gjq X0Ze7Ht2/QLJAryi/2Ic6fxybjq/HCuCeL1Sfc0ImhG62sSQEM5zK89ws8IkbUVuUpWT3dvS0xKi GBEa0X9VV1YVcGDHwJjK/5zOOeym/1g/o2yiBJJnqnLBzs4LR+AvIMCctczNzSmCoOtfqC3jVTFl ykWKQncJW7a0R8WKZP/8jXL32G6EW5ZDp8qFgUpG2NVkGM68bgDPNxEo2Ls1qvp64vq1ALy9ew5h VhVQNz/LGZB6kWgbwcWlwFe8XV1wbuM6nDojh4FO+koYGXbVkAe9wakrb+FWrwaMCTeXbM6QXAoG k4ENEnGMC3iJ09c+oWy9qsJncrkE2jq6oMRCyUrevHnJm3OY8NmMGTPg4+OD9u3bU2xqpaozKxam 6mWkW7R7UWiFayWDIFYSi6dTniK4SLBAPoxkzC6bQfcDYUte0g7nHYh/yOZM/8UUihFI/W2ft/Bs 5CmQEUVWphQZJGEnel+ryD5T4Jy4cWF2eHlXpQ1eTv9d1roMmyOUE/o+ea2HSlHvYj2Upf9Yca/q jhjLGOEomG9FXwEjIegKFSHoCve3yRRT4193gknUz549y5QCx4wZVzB+/AmCNAFNmmzBoUPtUaZM 2s4cfx0HBXw8Y6FjlnifSBc2lFHnja8m6jUrhBkLeuM8/XYbdSiN01duo2a7Zj+MTs9+sfHyr0f2 Qt9ewdMgEzjkVVAo5rTF2v/dOZJhiVpER2jObZuNix7RaFjIAjcvfUCt1r1gFh2E95/DYe1gT/FP Y3Fi7wI8JL6t6KyLh68+o0LjHkgZh0hXV5dCL5JHOBUTExPyao6giEWOdAQj+HdxU/v7VETtZOQE SXiKM8M05/Sv6+N16dew32cP0+um0H5MUjQBy445BdQLEM4e+0f5w7+kP+L0SP1NhMOOTTHbrSX9 x4hcKGyXlclLPOioGf3n3sodHzp8gDRKCrMbZhBRQghmEihxvoSgSkcISddHowSPdq+GXsIRs4js EYIEzjZNgn1btRFItHMzHJmGQwjwkqQwrYRwPSf5TD67vt89RtTv3r2j8KjqMQk+fQqh5DHJs+Cl 1rv9+19g9Oij9BUL6SqlNK8RFD3uP5KsmyF79rTZgZ2cjCjQSgIio2MRY6ByRqUNspR+f5R0JU/T 3ugdexQ+BnmRS34fx+wLIP7OarTeegl5KrfH0I41QNFlkxVdWQyu7l6Knq8OC59H0JG+xqNmI8/B 6YiM+fVAT78ycTMsUUsMcmLWkiVYuXITBdWXIH+NvmhdKS/kAbewYPkRdOw/HkXsCmDenJl0zVYc fiJG4bp90ax04hGb76DAdj5sYsfFxX3xcv4VwDLLtcyuJZaTE1RCLLTpv5TF7LAZ2IsV30q+8O2g tDMLntw0gdkRKiEwCDmPaQQlV/sw4spqhRGqVJ54fIzI1resr0C6fq5+eN73uUDEdtvtoPNJBzYb bYQXKz41fRBtE41Iu0j41PERxoSd82aOaYzIGdaaXpqwOaG8XlUYcXvXJ2c8FbFnNcB5fwUE1Mk+ 3azZHty8+ZpaTXlif1iUMTGUgTPZjlWLMsVFUO51Zr78WSAitmmhGO8vBiJ3LmOYGWtA60vKOjmi I2UwNWEaRE2UqtOY/g3EivneKFDKGBuWXkbHvj1xYP4S7CteAm1SZJiLlGugaO2WmN6nptB6saYe jHQjMWRnTJojN/7utM2wRM06JDHLiz5jZyXrm0hqiLy5HKCppZTYZOYF0G/czN/tP7/vOwj41PKB ext34YgUO3Mcr0UOUswjm/0O6JWW88tZFlxm+1eFJaVpymzcDL+3/d8Kx7hYGFMmJZtfMoflcUsY 3zOGJqnjXFa5CJ7zHi0pzGmBEITlCBPMCq5DXGFy41tJgo3Nh24kwZOqnReOQEZHYMOG+mRuZFnK fnyU8cCBF2SiPJV4HSPmGOjoaGHNmoZpl6gdlXrVXEVzwG/bHYSSH4mB9ws8IQFlaPav0Q7fnTkA P8uS6GgfiEW+MrgWKoirFFo5MOJbR2OWcldDx0DQyn4psf5gae+19AzTFX61+4XHyw1QrlRJuJj9 bGeVrrhlmsqZRJxaibIlFVGJIMiCZMnONGeajv+rjiQeAxM2lXRWm61RjITZv+yY2vsu7wXnOpv9 NgLhGjw3+BJ4hZ3XZnZtFq0ttaLtrf1NVLZ/1S3+HI7AryKQJ0/yvPHfu79ECVtBQp05k5E1yxin j717W6FGjey/+khkq9wFta+MQqeeI2AZ6oOy7UainEOiBjD4DbZfcUeN7u2gbRGB+hUPoV/XntCx ckX7PN86lUmktBam3GNINMki6I/9i8fg00Gl95RBDjf0bl8fFI32r5W/WNVfa9MPK9IwtUY+evHy hwgwjRJNusCSgdD0T66KYmeCvRp4QfOz5jce4X/4VH47MxckBnJRCRbseBzTXjDPcrYxYuNhct0E NodtoPGQFpXvmCCZ+pudR2eWBuahL3jTs41BCi9+DjpHQN0QmDGjCiVLkeDatefo37/qb5G00GeZ GQXNmoOi919CoWONovkcvkKhbYH2fQfAzoyp2Y3QY9AMFH/pDpschWGl/63U33TICtSVqFyZE6uR mGD44oNw96JNNUV1ZEXD0BJ0LPuvFrUj6r/a+yxcmSoJxbOJz5RZqJIWWuyZTVU4S/1jLVUWRvAv dF3lMMYCvSSGOWWqb3bWnMUdZypyVkq2KCkkFElZzM+bo1iHYoJU/aHzByGdJ4uYxtTljNy/OJz9 habyKjgC/xqBiRMr0iPZ6w+L1AiFi6cSCEvTAPZJZRRdMxQp8jWcccqn6ptYfeOozBZII6tswis9 Cyfq9ERXDepmntqplkSJWw26kHmayPZFJBWzs9msqJKNMC/y1Ao7k82c2ExumsDinIVg9w7PFQ6P Jh6ChM2yiPlWIae2xHSgqsArwjN4yNPMM294TzI9ApyoM/0Q/6SDPNxlhp0BQiIQCiLzse1HOK13 StZOuaEcTyc+FWKkG981ht5rPYGcndY6IffM3MrMX6RiZwFYWGGJUd71eCdI23Jt8n4lT3OmIk8m dfO5kGHnAm9Y1kaAE3XWHn/e+4yMADNB0Pl0dubatypJxkmK4ElOqUJZ9rFIx0jBMY2pu1lAFRZM hUVQs99tD71XekLAGiZ1F+1aVKghPHs4vOt4C8QuJByhv7+URFMHk7iFYCzc9JGRZwhvWxZBIB2J mvL7un+CoY0D9Ogpn948QXC0DNnz50rl1G4WQZt3kyPwqwgk+gswiTg5UydmFWPnrSl6nCrDGAs4 ozpbzTzKmfqcqcT1X+kLoV9ZcJtsK7MJSUYY2bO8344bHQXbNjuXHVAqQJDEmb07wjlCONf9JcIc NUCIqMYl718dRX49R+CPEEgnoo7AkUV90GP2c6y9fAG29yahegfKcEVHgar2moLVs0fB+VvfmD/q CL+ZI5BpEWCe3Gm0KSf1+P5ylpvuj7aioCr2kQLRCnm+6T9G4jb7bKDlrQUddx1kX5RdeLHCVOOf q3wWos2xYCwsT7ggqRPpC0lZEjcQqjSfmRZ73jGOQAZAIF2IOvLdZUyasgVVx51BeYuPaDtoFmzb LMWRxjI0ajwEC4vXxKJOhTNA93kTOAJZAAESgoXc2UyVTUVIMsKYloT0T60T83FT7m2mJmffsWA2 2VZkExzU2Hu7T3Zw2kgSOBE7U8OzEKgsaho74x2WK0w4IcCkcNUmQXVMLAsgy7vIEfgnCKQLUX9+ ex+BASXRrXdFiO7NwQlPC0xv0xrFKmijnsU8fHr6ljrHifqfjDB/CEcgBQICkSYWIcIcyxBGJKxy PGNf3S12V5n+lC61PmotqMh13+rCeY2z8GKFnbcPcAsQ/nZv545oy2iBtFkaUxaJjUngwgaBhULl tm4+DzkCv41AuhC1TJMiJsEH4aEJuH78KKLN7VGygDEQfBrXfH3gavH7+UV/u6f8xkyMAMmHCTLK YEM2WEkURKKfB/7PxGD8etcSj4V9CcTCakhCrCz4DVN3M1L/0OmDQOoaIRpwXukMHQ8d6L/Qh9Vx K8Fpjd3n2dATIQVDBLs5c1wLLRAqELhA2Kqz44ke57/eWH4HRyDrIZAuRG3pWgUVy89Bz/JFEP78 IaoP24jCsrtoV7QtnlsXx5xWblkPad7jdEMgPl4XBgbPYG+/FW/f9kFMjBnE4vTNZpNunckoFSdx GFPFdWdq8Cj7KIFsmQ37/rL7AjmzXOSGj5X5yBlp2+22g/0ue8GuzpzgggsFCyr0993eI8YsRnBQ Y/+yI2bsGsGWrjq3zx3VMsoMyBztUMTh1OpJ2PEoBNLYWFTpMQEtittAEfAAMyYuxTvdgpSpqyey Gcjw4sp2PIvNh8aVU8/vfXvvDKw48RG6WiySGRAnMkDjtu0R8Xg/NEt2Re383w+W8qdgpgtRy4wK YNn6regzahEiSrXEzOntoRVwDRZlu+D0uFEob588//GfdoLfn5URYKKfCJaWJ+h1mqRqPTx9OpFS 3AUmFwuzMkR/qe9Jg7GwKgVHMjoVFpEtAqF56bw2S/ZFtuqPHT4KXuSyQBmc1zkLZMzydBfvUFwg bFa863kjLG+YkI3tc43Pgppd8ChnQnlirm4WGU+we3O1+V8awaxXzcPdEzB2+W2M3bwKRo9WodfA wbDbsxzBm1cjPHdduPkfxZS1p7G+X1EcOf8M+VrU+C5I9y6fhI9+MyztW0u4xu/ZEYzv2R2vFQHo 79watdMR3nQhatZe7WwVsX5Xxa9NtyiNeetLp2NXeNVZDwERpSrVhba2F2xsDgndNzO7AH39FwgJ KUSxgv1IDa461sRFtXSZH8xRLcnxMEa4LCIaI9s4gzg8mvNIyGGu/1wfem+UZ7oNHhvAbq8dLM5Y QBohheNmR6FpLHb5u54UlIVs34zcoxyiEGsU+zVXt6oD6TqUql1Buj4kXYYiU1T6hnrRN5We1P3O 5z/ptFXhxli7fwhcs5G5tdAkNNnXEBfvvYTBx2jk7lobVXyf4/ztMLy+eZa0RVVQM+f3811LtQ1h Z5UdLi4uwlNdXLqg+LKlOHUqDnrayVP9/u2xSDei/tsN/W59sZ+xY8M6vAuQonyz7iibw+ifPZo/ 6P+BAKlT45UamYQEMUnO/siXbxzZpiOFzzQ0guDktIHS6eWBr28lUoNbEVnL6VrlVBeLY4T3XExL n7FjBC3EiBcQTgyaQpzHPMTZuWwmHTMHNPe27kJQFkbYjMDjNeNhes0URXoW+dIw38q+CM8Rjjjj OHjV9/ryuRBalQnaLCgLk+r/osStUEhprkhoPrF0jJys02eW/KBWBvvJVL5PkkvjV9pkmbMYLBNv CLm3E8c/xWCKqyuy6xTCpLndcFKsiebdyuLUzTuo16ElRepjueBTz6jBpllcTCTi4pgPDM3jF6fw KNgS2QtRtL/4FHEOfqWRabg2/YhaEY4zm+dhzNRN8I1nE16MMk2HY/aEbrDR+zupRRJivTGv5wA8 c6qBpgVisGziGERMmoUa2fkh7TSMvdpcwgiZrcZySnHKiJZJzNraHnB2XksLaji0tJJH7bKyOgH2 cnZeQz8qQ4SH58THj+0Egg4Pz4HYWHP6OxZSKREHLcYi5t3MF+X0mw8ppG5GrMyezYqgJmdBWYi0 WeIRbQ9twWOc5ei23WcLwyeGQq5ux00kddMwMY/yt73eIs4oTgiHypzVkgVlYasp4/Eknu1p6xid EVdooFChAQgMLEbzpT0n67QBl/arXtClZCr5YWHXpFaC6MM7aX8U8tO1SSysYc8OosGgVSjTfy5q 2OtCZN8TwyQX4aefA5YBV/DBsQBCLi9Gsx3XkbNcS4zs0Qj6SlP0l6Iri8H1/avQ581x4bMocmBt P3ku7m0bh6iY9PWJSR+iTgjFlnGt0W76BdTt1ANVrChFCRH3yf96o+zjRzi1axmyp8gW9gtD8OXS BHk0HMo0QosOrWBPPbm1rxwOX31BRF3sd6rj92QoBJgnt/SLJzeTmJ2c1lMC+U+wsDgjtDQ0NA9k suBUWx0Wlhv+/mVosY2Gnd0emJufF64LDi5MZJ2dyNoEnz61pE+UC7RCwdLokGezlEnmXJJK16nA iDQxFafKUY1BzqKhscxhTH3Ojop9avVJIHHrQ9ZCQBYWdc38rDkKDikoNC/GMgZ+FfwEqTrSIRIe zTyUgWHof0yNzv794m3+PambnqsgaT6O8iJZ6V6BsfEdet2CT2BVREdbQhpP0tNflNjTFdeMXnlH auDN32zkHrqPvdJantOFuZUXe93cgs5jV6Fc3+WY0qxQYg0acC1fjf72xZJ5fnAtbYJNC+5iwJgR 2D1lBvaVKY8OhZOfToqM00SpBu2xaIDSGi3W0IamJAjX1scK+bPTs6QLUQc9PYGJs4+i+viDODyp /pf2j+5YFkVL9cGCnR2xrFvxP+6XWMcZzbs4IyHgNbZuWo1rkfkxo/ZX1VlqD5BIJCSViWlBlgov XjIWAkyrxCRouVyPSDiUJONLyJZtLUnNLOVjKKKi8sHTswu8vOoL0nLx4h3oc+Y4lrxokMTm5dVF 8AD39W1CUrMIhoaPiLR3kjT+iOzXL8nGtEtQc/r41ERAQFki6zj4+ZUSiJupPpn0zlZpNk3odl7S GwEmZFOGTqEwvJkihT773JKczYiwmYOaTwsfaARrCGlBXVa4wPy+uXCdzUEbZNuWTZCkmW38fY/3 iNOLRZhFFEJzUihUlraVvpNEiYUxj1coxS127EzvrQYMAkUUlIkxAWuECDkT9uP1p4lQZKeIbHRv Rixs/WLzWm3KTmopHRr4YXlK3zZN5Ypm9NnkX+ip0oyMoHt70W/8KjSeuBfdy1h8U8HLYwcQYlcG ZRz8MD9YDEdHR+hL6FhhjFK9nbTEx9PmT6pB64f2149jyY9CroBMO321uOnCVCHe7gijPlWuWTlZ R/VyV0E5Q0N4vvxIn/85Uasqj4oMg5/IHDks4/Di8UsUrZwn2XMjIiJoIVYGZggKCiL7ZRg8PDxI IlNmFuLl/40AU2vrETGKYG0tpR9CABwc/oOu7kci6ydEpJo0Xs0QGelIUnI5uk65gxWLA4mI6xCR hn3TgYiIbCQ9+9I1n4iombTMFrTCuH27iLBQMw9xTU1fktA9YGu7hSTuLTAhPxJb21IkxeuQ+rMU Pn+uLpzL9iLzqJwJaKQ6ZxJ3guCVnM5b6P/3kGTA5zObNyPWBE3Cnvj5yQRa1RODslidIOnX2why DYkQoEV/tD0koLPeFgoE1XwnBF6Jto7Cx6b+MNJ+Cavsu8ihIVaQpg2H94XeDkpY0v9aYq8TYK5/ GS/DrsPdQxdSuWr3kLFAYUQdHU1Z0NSFrJU+gz8u7KeVGuexexMl5J9V8fV7BU7uXY+7PtrIfnQB hu6NoW2YPur3GICKuejHHvQKe+76onb3otA0i0TzascwoHsvGDuXQvd835K6JpGxjkYKypRowVQj DIcWj8T7vfrCow1zlcWALo1h9BfZ9S9W9RUes+yusKf4Jv8tXYWuJYfANHFD+mD7DOz09sfgMkrV 1d8qOvZFMHBQETxePwC9Vu1CrcoTkNR379mzZ9i0aZPwuJs3b4IR94YNG0j9mTF/gH8Ll4xcDwtQ wgiPqZyZZ7aFxVlSOYZj4sQEIuhI4fOgoCLYubM8Tp7UoQVJRqT7gYiTbbm/EqVcri9I4CmLWPyS SPV+Iqmqvv3q0cs2BgkJTHK2Jmm9vHBBhw4JcHOLJIc0D+TOPR05c84T7p88WUKkLaKNgr1A4Iyw xWK241YI9m1lgBVe0gMBtqlir+RFTPODDIiCb4GyxOpIYGhxH3qGL6DVVFMIzmIMe0xyKwGdentp V0eSMnmcO1jHQsI0JXcppvk7ErvYlHhH9c+fkPwReT7gwZUeOLOpFkRi5iiU8TZmTDNobm6OkiVL pgf0/586mSTMPL9TliRCbNobJkJdiuFRtgcF3QmjDbZwoxRWtkpChZ4tug8YBHMDNr/00b7/TLh9 9Ia5Q04YpXKCuOmwVWggTtEQiQmGLz2Gz37BiIpT+l1I9Uygm3LKpr3RqV6ZLkSt51wZi+YNRpOe o1Hs0R4ibfpRJUTj5YMHKN1zLgbVy/GHzVbeHuN1A7OXnULLCeORg7zj4xM0YW5mASY/JS3Fixcn FalSgh8zZgzZJj9h1KhRdIQn5K+0g1eSdgTYcSpG0lpaXoK0yjy0dXXfk3T7mSoxJCLMjffvGwjS c0iIK3LliiWvbkW6BTBhRMzawwrbt929y8wiEbQAnhMIwsLiHCZNukXfsh/hW2qXEf0rhrt7W8HW zUpUlB39P+V/pv4waT/pRiLtyGS1K5OqbMmZjLytWeCapIXhz7z4mWe/qihIZW1g8IRMGLuSYE2j Q+YKHZ33wtgoSZWNw2v6/xf45NmGxs2J1N6kiflIR8WeGsFqYHvggyUYB0srngbqHPlmAPp2E6Fs 8ZZ0r3PiszLWGDGJ+sKFC4JUnWkK+ymq3LT/uFMi6BmZC69Ui0wX5kkdxjT1kSNnIomncoO2nlGq mR91ja3hQq/0LOlC1GzXUqbTPDwpUQOzFuyAf6LXd6tBq9GrcaG/1h8NUxdYit5g6rBxKOhoAD9/ LfTt0wLJf+7JHycnHWY8udLHxMQIL17SFwGl5My2l0x6lhHxnSLV9ifBVqyl5SMsrL6+lckM0Z9U zI0ECZbZnpkTGFugle/Tt40UZ0t4ANMgytiekiR0H586wr9M1f7yZbRgs3Z03Cio2ZnXee7cvYQ+ xcSY08avhaB+ZM5rYWE5hUVdpY1k0rfyOFjWLMwhUHU07isCbHP09Z1y4/aZzB7/CRsypWmBka82 aVlu0tn4y0nAU2pTIiKy05xxEbz3lWNHDmihZfHhQyeaLybJMI+NNRaIXCQitTnd7iuWwH3BRyh0 XkH6zhr5TY/CQPtb42kCuShrajyizaNjogd4xhpDto4p2HEiXjI9AulC1PKoYHzy8IfIIB+Gz5zN Vj4BSHYG7dXLl9A3s4O16Y/oNG24izQt0H3qcuQ/cQpe4Qmo0aoO8lnzqGdpQy+9rlIusvHxmkKU MEbKjNxsbffSonsXenpvyN6rL0jML18OIynWlGzJRQRyYxIpW4RlMpWm4//jKMMWdJXdm5E1s1nL 5Tp4/nxMouTmLpA1K8wT3cFhi9BmJ6fVgnTNPMrfveshqO9jYixI4rFJtG+HCWShLBlPlZr2GcGI 9uvYMJJMXSKWkqbEh+aA55eqmUSscupTmg9YXRLCj0nOgQJ2qo2Nsl4NvHo1OFGqVW2sRaRtKZCI a/JdHDsdoDxu97WwTZ9ybiUWsoHK2VlsKuElyYfhdH0YVGj0Tfffd/aEZ247yCTsGB8vHIH/HwLp QtTet/5DhYr98Yn6JZFpQENKdibyqI0WzppJ0GH6MWwcVf0v9VoPpWs2/kt18Wp+DwHVUSotwd7M JCgTk1swMronqI51dd8J1fr41CbpuQo5hjUXFmCWRINdrwz3mTGLkliZLZo5rzHnwwRB4vf3V9q1 g4KKCf1lfbSxOSh8Zml5CsWKdRH+ZsfEAgJYbHuRcByMbVJYHUy7wAhFLGbOQMwG+v/ZlPwYdSVR qkwD7FpG0Ky9SWOpx8fLBDK2sTmQaLtXbda0aHN2m4j58TePYf4H7Hy7MgANmz8S8rivJJxhZsSa tLB5otTKfCVgpuHQ0PD7PdzY8bDE/N5i8i+QPM4HXLL5po0R5T9C5EoG0+h0WSYz5oTnrcqQCKTL DNQwtIajkRifghWwKFofI1uXh4aOPcpWKQx9+g3r6Kdf8PIMiXKmbJRSqmIkxQKRMA9qJi2bmNwg FeZRISAJI6XoaCs8fjxHOJMaGppXuF4prVLeY+nPoh9kROAoGhZJgkppUKkmZxJgRIQLXrwYIxAK 24iwvjE7vIvLaoG4GZExrQKLqhYUVJyOmDUS1KnMDs9Us4ywlNHVGBGyzUFqEneCIN2zZ/9ZhjA2 bkkd8FQbLZ1kgDMpWUfHXfAhUBXWfiOjB2S62J0o+aok4hBBao2KomQcX5zrGNFr4tmzSSQRO3yx 87J58zXwzFezANu0MExSOgcqiTs1PP58cyOlPNzeDT8gsJz3N5ONnemWhP9lr6CMOKV5mzI8AulC 1JaFmmLHuaPYTUHOIz0fYOHsmRDp58Erj7IwEBugSqvOMP9+SNUMD1pWbqBSFUyRfQTP51gi57dE zIfIwee54OTDyufP1cje3ECQoJkNV7XIqiKBZSb8VKpsZitVOpJRhilSfzPCZhsTP7+KRFZagp2V 4cMInNnnra2VzkuBgSWFzUxEhBORd2OBhBkZK22q8V9Co7J62efMO55J6QzXr3HMv4eokihZXV8L 22gwM4My5Cor7HumEWDk+9UZjpkvmER8l8iaHadMXpj0q7THM4lYuWHx9y9LG4+CgpYgaVHaqJMf aWPP+Z5EnFJ1nZ7zhUnWseaxQjawlIUd6VIFUEnPNvC6OQI/QyBdiJo91LZwTQykF2WnhYnTboT7 P8bkiZPAZKkPhqVQrj9P0PGzwfm337MY2tqJjlDJ8zkrHYLY97rCAm9mdkmQtJhzFfPKZfexRfvZ s4nCQh0dbSFI0yxgicru/G/78v98GiPCr06KDDemQQgIKC3EHmcqYyZNs6NhjLwtLY8TgQcIanNn 53UC4Xl6NiWSz0+4agj3qaRsqTRYCJsaGpoPjx7NIi1GYKIqWqk6Zn4ByQlSgzZSr8ie/pI+Vkqk SvK9L6ipVUTP7mUbCDaOERFJPZwThHF8+HCBICkrSVzpcsLeMxPAV5s7Mw1EC31Nar9m16u0D9+O yp9LxH880tQERsYS+Xck5wzQxD/uI69A7RFIF6JWUICAe4dWYcWhu2Tf8celm48hMymJeQcPw5pc 4vO7/b1gJ2o/AhmiA0pphx15YfZU5gClsjUzKY55X7MFmB2lYgTNnIEYebNr/fwqCI49TMpjpKw6 V5yR7c7/EnKVdMg2OCrVdlSUMsMA8xZ3d28tYG1peVLAz9DwibABYoWRIMOYYe3h0VQgUyb5Ms2E mdlV4cgR2xQoJeL3lI97W6LqWOU1rSnYhzU0AgQiV5EqI1Km8QgPz/1F+mUbhKCgErQJYOOY8jSE 8rx40sLU26ze1Gzr/1Ii/pdjyZ/FEfh/IZAuRO19azNaNulPp04Bk8J1MaxnH8g0DGCUEI/4WJIu fALgZGT1/+ozf24KBOLi9AWnr5w55xJ5tCLJeELi8Sg/Qa3t7Lz+y2IfEFCKvHCHkHq7hqBWjY01 EoiDSda8pAUB5kCWkghFwnEwZhP29g6nc+Td6G8JeZNvE4iZ2bdZsggWpIUVdua8SJFegkMaq4uR MJNamTpc5aDFrmMSMNtAsSNLUVG2XyRi9h27Vnlu+evxHrZRUI5jSjHyex7qXNxMy4jzazgCf4pA uhC1SELnZa1tEEPe3vFeNzFn9jVaTCjwfWwcFBSUpP2UPSiamxP1nw7e37lfLJCyg8NWoTqW8IIl u2AOUMz+rKXlTZJWUTpKNZRU2tbCUSql5MwcmhScoP/KIDDHOmUYVCbZxsQokwG8fj1I8LhmEnfB ggMFk4OqMLX4u3e9hONMyrPHYsExjTm1pVQ1KzcGyc/bMh8DdiQq9aLOR8f+yoDwSjIRAhEBXvjo 5YsYOc1rLSPkzukMbbJ0eL58ghBNa+R1Uv7eEqKCEBQtgYlx6hmjYkJ98cnLD2EUOIcVibYpCuR2 QEyIP2I1jWCglS50KjwrXWq2Lt4WF963FKxiCd+kFSF7kDRF/rBMNCnUqyvMBskclM6RJ+9Doema mn4UCWy84BAVGFicHIQqCIE8mHpV6QDEokRxSSq9xpltflQqaka4SqKmI0RJzwGzRYI2V0yT8fZt 3y/H25iNmI9Peo0Mr1c9EfDH8r49cVnDCbksyIfD2hWDnZ3he3s9xs87Tul89NFi2AS0LWGHw9sX wdO8IXrVK5RqVw8t6IoZlzVQpbCz8H3QZw8YO5ZFlMcx5OmwEn0q2qcbROlC1CKK/KOhyY81pNuo /aWKlSrTWMHbN6nEFRdnhCdPpglxrVkaSeWxGZVXLCfpvwR/mqph6m17+13CeeSkhZG5s/NqGiO3 RLuyKqAHH580AcsvUgME2CmSHfQaSa/fzE4V+A7PxXkwc9Ms5P3S42DMW3UaZQetQbnPCzHi4BXU d86He97m6NAmdZJmtwZHKFCsYS/M6VtFWVPEQ7Qs0wz7/KRY0iV9+S5diFoNZgBvIiHAHMXMzS99 QwJSaYigZmUe3CklOQ7cv0OAOX2JxYyAxYKdOWVRHuViSU2ybojSfzca/En/HoF59MiN9CpGr4a/ 9fjwT+/gH3YXq8ZMgKGmHup17ofidpowMdOE54dneBcUihwORrhz6gJsKzaDc8pEEUmeKpZIIUm6 D9ZlETYpANJrpvFK3w0yJ+rfGn71v0l1JCdbtsXfdIZ57bKjQuysLEs8kTJSlPr3Xj16oPKedndv I3h+p1aYbTvp2Wf16BlvJUfgZwg8pwv2J1407beJ2j84Cua6eVGhRmWYhn/ArmXTIRoyHi0Hdca4 kYuwybAYxnfSxoFrxmhbUY6jR47ApUgV5LH5Nl2XJvmCvL5zDgcOKP1JfF9dho9VHTSs9jgx6ubP +vT733Oi/n3s1PpOlS2URdFSnY9N2iEmrbFMV0lDRap1h9W48T+P4Ja+u3k1ho43PUMhMJFa8yoN LWIR8lg2PVXM/wf0dw96Me1SWrVHTBq3hlOFTlhHL2Upg/t7m2D30Yco1qE85m5mYYATcPK/JbDP WRBH1k/DHU9KtHPwEkZOmwZXi+S+VBJKlRrq701Onq+F2kTGJbBweVUs6d+cHNXSNzkKJ+o0TJvM eQkLkiGm87ktvgnZqOovI4g/C1WZOZHjveIIcAR+BwEWpvXDT25koW1Zwht2Rl9VGDmvphfFZEfq HtnfVqoM8ev1/Aa8EpxQLC87ZUTJdsR60KTTSKoS7XEDt/wM0KygP0ZeisemUyuxuHUHnH3tR0Sd PP57ZJwGitVuj2G9Kn59nMIHYTEUKptyWqRn4USdnuiqQd2qY0HfbyqX1tRgGHkTOQJqgMCqNLZx GF03N5Vrl9FnFdJYh/Ky0NfnMXGvJ8aP7AuDyLfwMLBB9bK5lF/GhePI7uOwKtUTuR28YWQahkP7 D+JDXALqmHzrvBYTFUIBiJJuIKgOOvIVHfoZb188wQtLpQZAqmsMRztLyP7i0pmhiToh7AN2bz0M Hzq25lK6HuoWc/pmkEI9HuHQ4csIjKMMRCJtFK/dDG7ZjH5pMPnFHAGOAEeAI5ARELj/HZJmbetO LxYON+0ld/2RmKqxDOtXrYSYzjq3HjwZJWwT7c9hXgi1LYJGRUhy1rLB8G61sWTPWRRtMxgNc38r uRco1wja+tmSP1xmhJq1auD048NY+VyZ6MYwdzkM6toERn+RXf9iVWkHLy1XKqLeYHSLZnho3QQd SgGTBrTDi5FrMLRe7mS339q6BptvaKBrq5JkbaBQivxYWFrg5ddwBDgCHIEMiIALtek4vVI77vQD l+zv9kSEQjX7YjFLO5GymORE5+Y5v3yat0pHrKDX90q5pv1RLuWXJBw26rcA32Yz/7vQZlyijohE tpo90atXDziSTd8l2gdDdx+lw+i5wQIfKksUXoeLUblrHzSvwwaYl7QiwOLQaGgo6HiPiIKZKHU0 7H1cnFhIuqB6H0sZhHjhCHAEOAL/BgFDekxqrPpvnp5Rn5JhiVpq5opu/V2/4Pb87WvoGRVJHkot xhdvH5/D9WeReHdQBKui1TC4Y1MYaX7fOCAWs/zBFB1NIhFeWbWIxQkUr1sTpqYswhXDS0RxpjUp tncMeXtTwBqNOErcoE3fs3SWWRUl3m+OQMZFgK1fbC3jJfMjkGGJOin0lzcOxfgHRti6vjmSKz9E KFZ1IBrVqIei9gY4tWQwJq01wbw+VShExNcSExNDMZAjhA8iIyMplnIMRXQKpIhOoZl/hL/TQ0ND OVasKEKhQyUYPPg+4ROP2bNLo0QJf3Tq9AzHjuXB5s22mD//siBhfxMJNssixzvOEcgYCEilUtKA sZj7nKwzxoikXysyOFHH4dzKwRh8KAQrVq1HWZevSm8BEk0HtOzb5Qs6BXI7Yu1/5+Hfuwoskszd hw8fYv369cJ1N2/epCAe4ViyZAklNFAGV8+KRSpNIHKOxunTrXD9+lGUK3eIEm/kouxZ3rhx4xhu 326KHDmeEG6rScIWcaLOipOE9zlDI8C0g5aWlihWjEXu4iUzI5CBiToeZ1cMwtxbmti+YzPypHJ8 LsbrFpZtuYHmw/rDjog5PDACOtbZYJBig1miRAmSFEsI4zhy5Eg6O+yB4cOHU4hM1YH6zDzE3+tb AuWWlmPlyg9Yu7YHbGyqoEABI3z86ERZmSqgTBl/zJwZQOaBoUTUXPedFWcI73PGRoBJ1JcvX6as dqo4/Bm7vbx1v49AhiXqsIfb0XPcVpTsORP3D6zHlRg5bPJUQKVCBrhx5y0KuZWFkaE1EkJvY87k BchnrYtA/wS06VgDWj/Ag2XzSvr6fejU/86oKDH69HlDZJyAefOyU0pLBf3oxYKdeuHCh5QHOZ7e SykxR3wysmYOaEzK5hq39J0DzNzANB/Mn0Dl5CeTKSMgsffsOzZ2fDzSdxwyau3fZibMqC3l7fpT BDIsUUssi2He6jWIjIpEVGw8LUoyIfC5mBKTHTt9BnpOJVHCyR5DJizAyf1H4BWRgMqthqGEc9oi 16jI+k8BVOf72QIfFibFwIGv4Ourgf37bYXuhIRI0a9fYTIRMGcVkKQdipYt3clUoHS+MzKKpdSY MQJBqAqrhyWRUBVu0/7zmcEIOjhYJuBsaRlNvhUSCrigjIBkbh5D78Xw9NQSvPXNzGKTjcefP53X kNER4ESd0Ufo77UvwxK1jlVu1G+c/Mw067bc9yny5XaGiUli02VmqNG8499DJIvVZGAgx4kTVjhz xvJLzyMjJQIBFCsWTE53MmzbZi+8VMXVNQRVq/pSzmqJYLtmkneDBl7Q1ZWnShbs+BcjFS6B/9rk YmOzerULjhyxxvLl91C8eBBGjcov4L1o0QMy4xTBvXtGmDz5KWxto8lRMuueYvg1ZPnVHAH1QiDD EvV3YdSxR53qpjBNaYhWL9z/761lBGtkFIezZy0wZIgrqlX7LBzH0teXk/ZCgVev9AUpOl++UFy5 YkaOZ0wFrhAkulWrXMiu7SQQL1O/ss927LCHpma8cCbbzi4K3bq9F1S2TMo2NIxD9uzhX0icnc1m JK/KDsXAUJ3lTgswKpUwa2t4uJQkfbHwbF3deNIGyKgukP09XmhvaGjywPppqT+jXBMRIUHDhl4C /t26FcWuXTcFkg4NlWL06Py4eNEMU6Y8I0dAfwEHXjgCHIHvIxDqHwSZkRG0heOotOaEeeDa/Xcw ss+H/M6myhvlobh7+yl0HF0pg5bSeTnS7yPCNaxgYZhawBVa/z69wHvPQESS5pcVTaucKJnTCp89 PaBnYQfdv7AEqd2vW6pnAAt68fJnCDBSY5I0k9BKlAjEnDmP0LZtCYG8p059QiRdEv37F8LBg9dR tGgwPSxBIGZGqJUr+33xAtfSIqe/s5aCZMcKI/mjR63piNdXT1QTk1jUqeNDdlWlXbtIkSBUqOAv 2MNZYZ8xYlURN3sGI/LvFabq9fHRImnTGc2be8DePgoPHhgKhMbeMzXxxYvmePLEkPrknuiTkLGO sKgCzrC+fK+wTU7evKHYsOE2+vYtTK9Cgh/B8+f6gvZiyZIHqFnTR1CPM/zYhkWF8Z/NDn43RyBz IfD2zHL0H/UY0y4vQyEiarn3Y0yavgBhRrYIf7cVVQaPQ6uitji5dgrWXvFHvNQQQybNQBm7ECxZ uRzFmo1GldSIWh6I2QMb4552NZRyZsFagOdvNiOfiw0evX2GAfN3oaLNnzvjqh1RZ67p8//rDZOE X77UR9my/pgx4wlJu2Ii7CCULh0gSMJz5z7C7t12RJhiIeBJUpsz+16lxmZ20+rVPxMRs8w4EO5t 0sRTkGQZ8TKnM6a+PXvWnHwMKJYc1bd9uz2RaYxAKqxeJhn36vVOkLzZ9WwTwchc9Qz2WVLilsmY c5UI//3niIcPjegI2R1S1WuTlO+M9u3dadNgLGwycuUKQ8eOH37reBl7NutLWovKBMDalpbCNjQf P+qSh73uD4++sXr19OLRuvUnUnHnEUwIrNStS0kEaFN1/DjLCqTc7OTIESZoM1J66TOVeFJ/AlX7 UvssLW3n13AE0guBGzeAw4cByjKJW7dA8RyAiROVLxKGyZ/mF58cF4LTW+Zj6JydCI4rCakG+/0o cHLzbHwyb4yN4xvB+/R8dFi+DpVnNMXRU0GYuGUDHsxsh8O338L282PE2VRF+dxKEv6mKGIQKbFC 476T0asUNZBK/NN9KFK+A9ydq2LUX8rMwYn6F8c9s1zOHMa6dHkvqK7Zgs3Uqew9W/CZ+pg5K/Xp 81aQ0lI6hqVUUzMVbdLYvEzCFYsjv0C1dOkDoQ72LPYc5rQWHa1UfTMJ8fRpC0GyT1oY+atU54xw Gzf2FAhIFXylUKEQ7Nx5g5zeCgnSZuXKvgLR375thAkT8oHZ0efPfyhoAFif2GYgrYW1i20MIiPT /vNgmoV9++xok2AoqPt/Zo9nqvr7943o3DrLvfvjwnBg2CUN57pnjx09z1bw/laVbNkiyFQRIjid scJMAJqaCkGrYGUVnexaVifDK2U72aaIEfvP2v+zNvPvOQK/gwDbzE+fDtrIg46esbUItBGnXA+T QEdqf6PG+GgEazlj0YKp2Lj+FiJYSmvdUDx6Gob8TQsKFVrnLwpDzx14I9eAjVkc7ly7CV9ypM1O 15275oGqHVrhR9prsSS5xCwxM4W2JI5+h+T8/JcUeWlfiX4DI35LxkVApcaOjVVKtey9igjZ34wA fnexVkl9qt6r6qEgSgJxdO2q3BCwwo4X1avnhaAgjUSbtwJbtzrg2TMDgcgZ6Z08aYl165wF4mH3 MVU9k+BZXUwNz+zjjx4ZEpGJiPALCN8vWPBQkETZZ35+mrh0ySzNdnBmB752zVR4LtvEpAUHRnzM js/IUmWr/9HoM8xNTOIwdOgDQXX/vZjqrI/s2gkT8uLtWz2BXL29tYRNzMyZT5AnT6iw6WGS+ebN joKWRNVeplZn748dsyLbtkLAjxVWH/MSZ+PA7PhJN142NlGC0xoj7KSFzQflnEiuMVDNmYw703nL 1AmB4sWBTZtAGravrWaEvXx58s/S3CctSzRr1RH4fBHLo2izLnBqGHwjxLDRSaRfmSbN60AEyF3Q pWddjFiwDOZuLVFD4z2O2xSHw6dL2HYiEOXqNYC9XgrmFcugIQ/AlQMbofdaaed+eecGXJv0gJW/ NyJi2e/lz9maE3WaRzzzXZhSUv7Z+99FIGm9jPiYxK4q7Dum6jYw+CqBjxz5UiAE1Wbi1ClLwQ7L pEp274YNjgLxssIkckZIST2e2VGxIUMKCmp2DY0EgdgYkTFSSqu6l6n7W7b8BEdHFnI2bTYmZieu UcNHaJOKFH+GGWtP0mNtSa9nZMy+nzIlDx4/NqTF6j4OHbKBsXGs0OfZs3PSZw+QM2cYnX2PJru/ X7LHMZJn9z18aPiFjBmmGhrxZNawF+pVjY0Sa+VGyM0tUDAtqEid4V6jxmcKghPwje+AhUW00N+U c+erw2ByBPixvZ/NiMz7/eDBZL99/uP+sd+dDimZ2DyJYtIvFRktF6dPg04/KOdoWsqaNSAzUJIr o+XKDaywz9SEvgbleohP3HRSpeIE2vyK4mFepBnW/9eMrvPD4gU7UKykEWYu2QUtUpmffOSO2VP6 wzIZa9JGnlTp0ZHhdNRVeXQyT92uGJcnEu36zYIibZawn3aJE/VPIeIXpCcCSkleGUAlaWGfqyR9 5jClsosz4mLStGrBZ+e5Z87M9eUMOKtDZV9mP3pWLyOx7t3fk1NcoCB9prUw9f+vkC4jXGYGYBuF tEjhKiL8XnuYDXr+/ByCHZr5EdSq5U2R5FwE2/Ts2Y8Fh7+OHYsJ2oP8+UO+UdVTpFy4uEQIUnfS wnCpWPGrMx/7jn3GtA9Mc8E0EKpELMyWzt5PnJhX2CglXShZH5nznpNTxDcagRw5wonwA775/Hsb k9RMLGkdpz+5js0r1leVE55qnqnmI+szm2u/cirhT9qTme9lOP8swc/3rknLvWnCTiB6A9iYR+GT TwD97YD4IG+EUpQ3B+OvAsTTM0chdykMA/dj+EDJLQ8tKI+m9WbjNcXrsDRMslYpYhEjNUe1Nv3Q s+RXO7b83XHEKCTQ1ErbJv9nbedE/TOE+Pf/FwRURMz+TXn0iEmUquNlN2+a4MIFc8HrmS227AfN JPQ5cx6T6jtOIC8mnatUt+y6tBZm6/0VYk9a79+QHBnpV6rkR+fZgwTS8/TUEfwGWGHhX5cuvS94 tjPzASOSlM9kRMq0AalpBJhNndWRskya9CyZepsRVWCgBsWDN000AyhFBLaBuXHDhBx/rJOZB5QO hMpnss2DyobONjGM9NlxM2aaSOocyNrp7BwhHD1LSohsU8DGPjWNw9/AV7WZYm1hXvSqmPZhYTKa O8pjimwOsL4wrL6n+UjrfMrq182dmzYENm4EnRxRStassLGuVAk099N2f6pXxceRf0w44oSJo4V6 TRqg/6p1OJuvI17sOAqnOo2QL1GtHRPwHAcvvUPloe2R5/UbyI7dxa5Nvoi3NIOVVgo1NtUXERJA R1QZ6X8lagVN3lCf97h7/RY0rJRkrW/ljFx2icfAfrErnKh/ETB++f8fAbb4MzswU38zFTc7612l ii8RVzY6WvYU48blQ+fORQVJk9lmVWpcZcv/3F70rxBgUmbu3GECYTD7N1tjChUKFh4fHKwhRIdj 2gZ23a8GlGGSbWpmgKTOaapFkpE1c+5LWhghs81Djx7vkn3ONg2srcxezswUKps2U9Uzx7np078N YsQqYAFzkjq8KW34sWjUyIs2IslV6z/yyGcbq7SSONussJMCt24Zk+bikfC88ePzCZuG7t3fCe0f MyY/edh7Cf1n/eIlfRG4cwd0tBN09BD0+yZrchjQooXyM3d3YNas33y+cTa0alsH9krtNGwrdMPQ gMXYt3s3TFwaYEavelDp2iKCAuFYvj5KGRLBFmuD/tUDcOh+EPqPGYLsKY9SS/VRt2U3GGU3TtYw mXletGlUBS8v7YVH4pKTvUILTtS/OXz8NjVEgNmamZQ3cWI+QbW7bNl9wYOaSXIFC4YIkmanTsXR u3dhbNx4R5Cy1VF1mVIiZu9VkihT0TKCVjmhpVXV/qvDzepVhZpNeS/7jtnBUxammh816kUy9T8j cDZmT54YJBsLpuE4f94czA9BtXFQEbGvr6bgWKjy/he2WfRMtllh/gOqc/iq5zOPYSbFfyuZi4Rw uMk3GkJtwkZo3TonSvVakI4kPhROIPTu/VbQUjDSvn7dhJzu3qnl/PnVsc4I1+fKBXLkZH4SQO3a zHQF8sEAHbVU/v3bxTgH2nfJkex2t8b94db42xpNspdBm+yqz2Wo0G4Ivb7zZIkBGrb/VtQXGTqj 68h5v93clDfyLeJfg5JX9K8QYFIfIwPmdObgoMwzzhboadOeCDbiwoWDsXixUi2s9Er+Sx4d/6qD avIcBuv3nPOSOgyy7qiO5zGP8uSEmSAEdUkqmTMyZlqEY8es8eaN3hcJWZWcZM8eW8GTPbVStepn YW6o2sXU1ba2UYItXdUO1X3sFAKT5K2tozBoUEHywC8oOB+yjd3w4a5C1L6ZMx8Lse55eNZ/Myn1 9ZUkzYqLy9dnqj77N63IeE/hRJ3xxoS3KA0IMEmSpeJMeu63fHmlgxST3FjwFualrAwhqj7q7jR0 XS0vUUnmqREe+y7psS9G6sw2XL++l+DApirKOkDqcM9vnNSYFM2c7lhEuqRH6hi5Hzhggy1bHJIR NauLbRoaNvQU7O21a/vQaQIn4Zo1a5wF2zjb+NWs+Vk4ccALR+D/iQAn6v8n+vzZv41AUjWwSu2r IgHVdz8KQ/rbD+Y3/nUElEFsvt1MfS9+uZNT5DfnuVmjmFSeUjJnKuyTJ62EJDOqorKjM/I+c8ZC +Jg5kzE1PJtDbHM3ZcoTCrLjRaFq2Rnbv95lXiFH4JcQ4ET9S3DxizkCHIH/NwI/OteeklTZJoCd bWfkrCoq6Z4F2mGhc5ljIivMJs18Hdg9TO3OzpMz728eqe33Rpx5PnOz0/exi2fqoTQWtSfqT9d3 YtbKU+RxT9mTCjfB+K71oKv2vUrj6PHLOAIcgWQIpOaO8D3JnHnNM2c4RtxjxypJWhXc5fJlMyE8 LUt8wqRtZbY3DvavIGBEwblfvXpFIX77/sptWeLap0+fUmjftmnuq1pTWpzvVQztMxHO/deid5FI DBg0DsNhgmU9y6QZAH4hR4AjkDURYCcBWOz5cePyCyFjmU161qxcdHIgGB06fKBXcSG5CwsuY2QU myxWetZE7Nd6bWZmRvH4d9IRKzpjxUsyBHTokDjDJ61FrYlapOWIkev3oUChPGAdmdT0MPpfv4lo IuqvFqm0QsGv4whwBLIKAkw6Zh7e69c7CWlD2fl75lC2aZOjoPouUiQY8+Y9EtThb9/qolSp5ElN sgpOf9pPY2NjCnmb/Izxn9aZFe9Xa6KWGtihcKHEYYt2x7JDV5C3dmOK5Pr9oqGhQbFjZaTO0qUd Mp3P4IUjwBHIsgh06hSInj39BM/v2FhDSp2qjDMfGGhKpwZiKULWw0SVt8GXSFkZBSwphb2U0OFx bgfOKCOSfu1Qa6L+AkusNyYP6Ip7jm1xsnvFVA/j3L59m2IW++HFixfw9/cnT9CTdOZWeQaXF44A RyBrIsDOTDNiVoVgTRmO9XvhWTMCWoykWejKPHnyZITm8DakIwLqT9TBzzFhcE/cNG6FE7N7wuQ7 ORfev39PwRPewNfXl0IDhlD6v5d05jY6HaHlVXMEOAIcgfRDQEy7DE1NlkDl7yR+SL+W8pr/FAG1 JmpFhAdmDOqFdzn748SoJj/Eonnz5sL3sbGxFDPWnUIGDqZABsF/ih+/nyPAEeAI/F8QYCa8U6dO UXCYmP/L8/lD/x0Cak3UAQ8PY+sFHxTWuYNhQ64gVq5AzrIt0L1ZaXwvllAUJTllE5tJ1aGhydP/ /TvY+ZM4AhwBjsCfIcBs1HIKgC3i58b+DEg1uFutidq4SDtcuNEQEeT+H5uYBFzHyFLwAOeFI8AR 4AhwBDgCmQEBteY0qZYeLOgFS+vMMBa8DxwBjgBHgCPAEfgGAbUmaj6eHAGOAEeAI8ARyOwIcKLO 7CPM+8cR4AhwBDgCao0AJ2q1Hj7eeI4AR4AjwBHI7Ahwos7sI8z7xxHgCHAEOAJqjQAnarUePt54 jgBHgCPAEcjsCHCizuwjzPvHEeAIcAQ4AmqNACdqtR4+3niOAEeAI8ARyOwIcKLO7CPM+8cR4Ahw BDgCao0AJ2q1Hj7eeI4AR4AjwBHI7Ahwos7sI8z7xxHgCHAEOAJqjQAnarUePt54jgBHgCPAEcjs CHCizuwjzPvHEeAIcAQ4AmqNACdqtR4+3niOAEeAI8ARyOwIqAVR3929D/4OxVCjpMM34+F17wgW rTmBWC3KQC3WQ7WO/VG7gHlmHzfeP44AR4AjwBHIIghkcKKOwqU9M9C5+Wq03n2WiDrlqChw6+Ax fNIphml9KyFeroCBlWEWGTreTY4AR4AjwBHICghkaKK+f3AJZu99jZI1ykAmEX07HglR8EyIh0N+ Z8TGxsLcKRdMNLPCsPE+cgQ4AhwBjkBWQSBDE3Xuyt2xq44mdo4YiVfRsd+OSbQnXly7gmdvNRH3 RAaxqQ06d+mFPJY63x0/mUwGqVQKbW1txMTEZJVx5v3kCHAEMhkCbC2TSCRISEjIZD3j3UmJQIYm am19I2pvFKKiYyASpSJRy8zQadIWOBQvDDMN4MbKgZi6+CDWT2uFpIK1r68vXrx4IfT93bt38PPz w9WrVxEREcFnBEeAI8ARUEsEGEkHBQUJggcvmRsBNRhhxXdHIEFigiJlTL58b2Vnh8hzzxBCG0yL JLzu7e2N06dPC9d9+PABYWFhuHHjBqKjozP36PLecQQ4ApkWAbFYDD09PU7UmXaEv3ZMDYgaUMTH Q6H4Vr0T63EZQ6ftQOc5y1BYH/D+5A3DvGVhmkL4LliwINiLFTa53d3dMWrUKAQHB2eBIeZd5Ahw BDIjAkySZgIIFzgy4+gm75NaELVMUxMyqVhoeZzvY6w78hB1mraBvXVh1Cp9BsuH94Oxvjb0bbNh SPdqkPxg3NikZo5nISEhCA0NzfwjzHvIEeAIZEoEGFHL5fLUzYKZssdZt1NqQNQ6aDNhMuRaesIo SXUl8PLxgk+gHPYGeqjdfgLyFnuIgCgFbHMVhZXyMl44AhwBjgBHgCOQKRBQA6IWQc/kqx06loTg fDkcYG1NAU6EIoZT3sJwyhTDwTvBEeAIcAQ4AhyB5AioAVEnb7DMPAcaNcgGDfLy5oUjwBHgCHAE OAKZHQG1I2qxVAbO0Zl9WvL+cQQ4AhwBjoAKAbUjaj50HAGOAEeAI8ARyEoIcKLOSqPN+8oR4Ahw BDgCaocAJ2q1GzLeYI4AR4AjwBHISghwos5Ko837yhHgCHAEOAJqhwAnarUbMt5gjgBHgCPAEchK CHCizkqjzfvKEeAIcAQ4AmqHACdqtRsy3mCOAEeAI8ARyEoIcKLOSqPN+8oR4AhwBDgCaocAJ2q1 GzLeYI4AR4AjwBHISghwos5Ko837yhHgCHAEOAJqhwAnarUbMt5gjgBHgCPAEchKCGQqok5QJEAk FmWl8eN95QhwBDgCHIFMjkAmIeoQLO8xFVrNe6BzleyZfMh49zgCHAGOAEcgKyGg9kQd7vMA82aM xNLVTzG8ae+sNHa8rxwBjgBHgCOQBRBQe6J+fvMiImxroUdHJ8TFxGSBIeNd5AhwBDgCHIGshIDa E3XxBgNQHHIs7tUXgfKEn46dtrY2NDU1YWRk9NNr+QUcAY4ARyCjIiCVSqGrq5tRm8fb9RcRUHui VmIRAXk8OZL9wI9sz549ePfuHc6ePYvQ0FDMmzcP0dHRfxHK9KlKQ0MDcXFxSEj4+SYkfVrwa7Wy xYO1NT4+/tdu/D9dLZFIIBaLBYzVoajbfJDJZFAoFGo1H0S0kMjl8gw/Hdi89fLyQufOnTN8W3kD /wyBTELUPwfBzs4ObNF48eIFHjx4QKQuEt5n5MJI7+TJk3B1dYWlpaWw4GXkwvC8evUqDAwMUKBA gQxPfgxfNh/8/PxQoUIFxMbGZmR4wdp7/PhxFCtWDKamphl+PrBNxYULF4S5mytXrgxPfmz+Pnr0 COHh4ShdunSGn7+MqJ89ewaGMy+ZG4FMQtQJiImKQkzc94msVKlSwkgaGxvj1KlTmDp1qlqM7PDh w9G1a1fkzJlTLdq7dOlS2Nvbo0GDBmrRXjYXHj58iGHDhqlFewcPHoxBgwYJGKtDmT17NooUKYKq VauqQ3Oxb98++Pj4oHdv9XBM7devHwoXLqwW2PJG/j4CmYSopXAhCS7SSu+nSOjp6SFbtmw/vS6j XBASEoIo2oSoSwkLCxMkEnUpERERYG1Wl6KO84FhrC5F3eYDM+Opi1lMXeZARmxnJiFqPbQYnjaJ iO3u2UtdSvv27cHU9upSateurVYOLkwacXBwUBd40bFjR0GVrC6lYcOGMDMzU5fmws3NDZGRkWrT Xmaf5o6xajNcv93QTELUv93/DH9jmTJlMnwbkzawYMGCatVeJycnsJe6lHLlyqlLU4V2Fi1aVK3a mz27egVMYr4VvGR+BDhRZ/4x5j3kCHAEOAIcATVGgBO1Gg8ebzpHgCPAEeAIZH4EOFFn/jHmPeQI cAQ4AhwBNUaAE7UaDx5vOkeAI8AR4AhkfgQ4UWf+MeY95AhwBDgCHAE1RiALEbUc53evwOn7XnAq 1ghdG5eAOEMNXBBOb7+FnPWrwFFXOSyvLu3A+hOPYGxfEj17NYCh8GkMTm1bjgtPfJHdrRk61/v3 R8287h3Gyu1XESeKQ566PdG+fA4g1gfrl6/Am8+xKN20H+oWtRFaG+95D9NW7EaU3BQtKVBHQUvJ P0f93rHV2H3lA4wd3dCrRz3oJ+J4cutyXHzqixylm6NT3cSgEVEeWLV8FT76JaBC6/6o4Wrxz9ur euDt45vgru+GJmWVwW6enPkPW849h7lLOfTsWgvKKM+ROLxpGa6/DECeCm3Rrkb+f97el2d3YPOp h0iQUAxfHRu06NINBa014f/4JGZtvQhtwxzoNqgT7LWUTbt3fAN2X34Ny5yV0bNjVSR+/M/a/f7m Iaw/eAMxunbo3LMHcpuyORmBgxuW4ebrQOSr1B5tquVVtifsPRYvWwOfIBmqdRqESrmN/lk76deD O8c2Y9+V18IzpVIxoiKiUb3bWFSjdtw9thZ7rryDdZ4q6NGuCjSFq0KxZ80y3HsfgoLVu6BFRfpt 8qL2CGQZor63YyaWXwIGt6uJQ2sXYaZsOEbXyyBHiSJ9sHRcL0xZHo3DAdXgSNPK78YWTFx7A617 tMGnA2sxYhmwok8D3P5vGtbe0sWg1tWwZ/U8zNMciyHV8/yziRj+5ih6tB2CXAOXoJ7BAwwYSRGc Zi6C8d0VuBrphq7VJFi+cBwSJi9DPWt3TJo4D5JKnVEt5g4mTZ6MWXMmIofOD4Ky/9WeJODef1Mw do8/ho9shce7V2PIvHisGNIQdzZPw7o7+hjUqirhOBcLtCdhUBU7rJ8+AXf1a6JT5VgsmTsWCZMW oqazzl9tVVoqi3xxEC3adEehkccEova+uBZTtzxF5x7N8WznKoxeJ8GiLtVxac1kbH1uhQHNKmH7 yhkI056C3uVd0vKIv3RNKI5t2gf/vE3RvVo2xIs0YGsgRdS7MxgzeztKtO0Bw/u7MGL6Kqyb3AOB Z5Zj5q4P6NW9EW5tXYGxYgnmtq/0l9ry82o+XFiHeRdj0blJE7w4tgJdOk3Gkf3j8Xj9ZGx/aYsB TSpi64rpCNebhR4l9bBs8kS8tm+E1vkCsWDGWEhnzEM5GyUlpn8RwyFfKdQzzg2RRAPvT8zH4MOh aDlaFx5nlmHWXnf07toA17eswHixJma1KYPjiydgv3cu9K1XABtXTEaU7kx0LG6b/k3lT0hXBLIG Ucd7Yu+Bi6jcaycFNDCBTfB1dN+yHz2IqE3TFd40VE6S6MqZo3DolQS5SzghQcHk/Dgc3bMb1qVH oG4ZN8DaD3UHHsGzlgVx+Ngt1Bq4F24ldWHifQkDth9AVyJqpbSd/iVBwwq9FmxCjRpukKAGpj17 hSUrZsNCQ4p+i1qjuBHgdfUYDh+6goJFH+FFbDasa12FpNjiOH2mFfZdeI8Rtf8dkeg4FcPIycVQ vqAF8kVewKZlVxHZtxQOHLuJOkP2w624Dow9L2HYnuNolSsnzj+KwpBtzVCIxNV3F49g997LqDm0 RvoDm/QJCSHYuHY3oo2tYGfGNgnxOLh7H1wqT0d1t0KoaPARDccewetGTjhMkmyjcVPg5iqD9ttz GLvtMDqUH5Aobf+DZkf7wdvQFCXLFKPAMQYwN1cGNzl9cBti7KuiC80TlNfF/hZTcNm9Pj4cPo78 teagkltuFNd4icZT9uJt60rI9k9WItpU7L8KlyoD4exgDfuOQ2FVMgjxYc+w9/gjNJ06A255xZC9 PIvpe06hgYUhrryRYNKMhshJ7Xt07ih2HryFcr3+1Vl2ESwc89CLAE2gNWxmIAYsXIOipnGYt+MQ CtZehopu2VFE8gzN5x6Ge00DHDv/Cq3mLoAbBV+Mf3QKc7fRvC7eNVHa/gfzgT8iXRD4Jz+PdGn5 r1Qa4YPP4WYobqWUjCwsnCAOuQUfSphk+v/OyyE1Rr2e09FF4oFefbchWkjiFA6Pz5qwKJeodjWy hnGCBO/fvkVAjBVKWyp39FaWTkDgC/hToirDf6RR1ncoitqqQF4xn3D0/mtYWbMEHKYwVeqU4WTp iLC3HnhjHg4tU5fERUIDTgbmeOz1ma74V0QtQu5ytZEbsbh4aC2WLjqBJoPXQV/hA+8wc1S0SIJj sCfevfdBnJYzTBIzBzpZOCDw42eiSdCm5N+VR/uW4ZVmFQxqGQ93Icd6OLz8dQlnJQlqmNhBX66g +fAewXE2sDRXTmIbS2fE+XsjmBKt6f4jpUW01xu8vnkWz8O1cE83ApZFaqF/24bw94mHoW1iPHIt Y9ho6uHT29fwCjaEjY2J0F49M3voRl2FR8j/2jsP8Cir7A+/M8mkl0kvpJEAgYTeIZQQQRBY2sJS FwwoHSQCKp0gTcoq4N9H14auCyKwCiKwWBYRpCggJjTphBoIJaRNyuR/JzMiCIgFJyRzzsM85Jn5 5rvnvud+3++2+U4xUT5WcDj3HPuOnCdH8yFXNl3iDA50GzYe3/wfSDcEEeBrXgyrEBhB0eYMTpzI p9g1Er3lLhnhG8Lnqv2a8thZwdvbGlzK8kV8k1WJ5e3VUwoLT3D2igexQfqSYzx8w3DJO8Cx46e4 YQwlwDL6CFH3h9yvLqvWgwi19S7fP6Uk2xDq3DyuqzSYmNbQTDdd9X9BcTZ5pkdol7ZQqymrCsFB kH6c3PwiNCX3CgOZhkI8dRZ5UNODxfa55FzOIlPlHdFY3raz15BvVPUwJX1y/lPax71PqsRu9lOD 2BPZk/c6ujDqn4csviu+OiP5BuXrVQM5qg5md7VoHfLJUWtsVrfifLR2LsS1asSJPV9xJjpCrUgq 0LdwLFTtIetyLlkq7eWPomynKyLPkKPmN6wn1LkntrN0axajFyayf85G0pxNcyWFXFftwUvF24xS o9aDc8lW7UFp3C3tQW0VKFLtwZSbxko9C41XZYZPfZsGHeMwycZbzz3OG2v98dbak+9gcUI1ao2D gdwM5W9+MYG31MOoyVZtQjlcsk78J5t65nj6+aMEdUpm5tCGFBxcRaeJ86nwbCsMKhPVT9eVmeON DHuy7FUaVItbdg6F5F7NwYp4LSXfYP1nB6jbawbqTqGcy+G6SkBk/JGjup8VaU3tIZvrKiug+R5i ug6LyS/MVncTsbJOwDaE2sOTAF0+hSV3MCWDeQZ0Gg/0lhHgQxFEU0fCZCUuuhGg8osYsi1pFwsN GA1O+ET546fNU/Uw37ANufk42HviaW2Rvn6EGeOGsNn5r3z80gh8Dr2Pe34W+SZFUxn3crILcXbz JSjkKq4HVa7wEt0oUhthtHh5e1gft8aN5h36qFdd+iSM4bNG4whzLkRhLbE8xVGnVW2komoThh9U J069qRDnZBfh5qa34manIj58ZS5bUn0JX/Ii2z5NIc37DXbGPU2waViXa8mRXJCPMd8F3yg//DS5 N+uRq+rhpPPEwwqa92MQHb0iadPxpxmSyEBPPvj+MEEebjjnWDplxgLys3XoIwIJcFa51XPM9SjO VwEwuuNtDZE2Fag2Y3n4NaStZeOgrnJNojWrOXzNjgo6w23twVGnJzDCDc+8yyUdNZPlZBXj6aG3 Vh/o5nViSNvJ7nNaBrW2bBR09iDQqZDiXHPOd6OaddEWuuIf5YOfUXUsLbeNvJwCnB316m4iVtYJ 2IZQO4URHWpgb8opulevSkrKbnRVowmx9vzVL7aW4pL8wsXFJqV2oXqsB8v2p0CPaK4d2sslbzdi w2PZH3CDvaln6Fg5nO9UPVxiGmLNfcnGnNPMf2Y4J6NH8cW4ruYahcXga/8uKSdQeYdhxw8HCGne l5joInL+vZVz6pCKxRfYfe0KbWJNC27Wsjw+XDCeI+FDeKaHusnduI6dSwARlauQHZCpOJ6lQ1RY CUen6ASqRFRVa7srSD2tpu+VmzvUVG2l+P7Wcrakd9Bs0CR8T14iO8fAAQ8nrup90bvqqR7txEcp B6B9OOcP7CYz0IuYsFhCfa6y90A6j4T6syd1D5412uFlRY8v7nqPOWsuMXNWUokgnLuQjXedBtTx OsdHH+5V08St0Zw5xBFtEQMrqb0UkVo2KCEnIYgT+3eTq9aKK1uro+lZiSZVitijdpx37q12dV8+ zUVjELH1qpPmlaE4ZhAf7MPulL14xPSkcqQXuvwNHL6kton4FbLj9AmqdbV+utlzqTvIdKxE9VBL 3mlNALFV7Pg6RXFs6c/RVMUx1I9qqj0EeF5k7+Esmvi6sWv/Pvxr9bHefgUrtjtbK8o2hFqNnvsM HcGYWVOZfrgyJ0/pGD2xz0O6bmMSanva9BvHpxOSGTMtldyjZ+g94jnVi/agl8pN/dS8Z5m+L4KT Z/QkTephGsRazX7Y+CrzPzxJr6FHmD0zWU2tFVO7XSJDEjswNXkgqWFOpDk9wnPta+DuGkH32ttJ euJZqhrT8UsYSZe61syk5EituJasf2UyU/fXpij7Ms0GDyG+YhgxKuvQ6PnPMH1vuOLozegpHXHW uzK4exOmTxzMt8Fazvp0YFIna+b6Vbt8qzZUL3M4M79din14a6KVeET2HcPGyXMZP30n146eZ8BT k/Bx8qHfoAEkLXqK6dsrcPJ8KE9P6aRaj/XMr1Ijwh3mMmHcdHzc1Ihe/QSuX9saVHXxosH65xig 3tdfOEHz/mOoqXcmut9TrJ/8DyZM30z60XQGj52kpsmt5K/GnR4jh7Pk3XfUfcCZaxlnaZ6ofkrm F4ZPYl/GLBnF9a1BnLxQkVHT2uCs1v6f6BDLC0+PYLN3PhkRPRnZzhIcK7lsKibt0EU0waozfHNg 4UCXQWP5cupLTLz8ORePXWLwuMm4OwWR+PjfGLd4KOmbfDmZEcuYEW2tPgNgRTQ2U5Q1r+lShepT oz0vzQ1i3/Gr9I1pTGXLxrJSderWwv3qMu/lKLwtu8K0AdWZNW8O278/jUefGOpGB5Yc7V+vK4tn h5FyKpO/12hClJ91f4Ua0nwomzZ2I1vlwVXLZCUWGOxJTOMR/CNkC6euaqnRpBlmt9zp+ewsIr/e Q5bGh7hmNa3aqTCNUCObdGdhSGW+PZKhNraF07SWORe5f71uLJ4VRuqpG/RXHCMtHOv1Hs+C6K2c va6jdlxTvK3ZC/pZY/zLqMW0djDvDNKF1uOFeTPZuf8s3n+vSa0oc4cnpGkvFvtGcvBMNom14wi3 ssNa78okTXiBHV9/T47RjupNW+JfEvsQxs+ax5Zdh7DT9yeujnl63DGiCfPnJ/PNwQv4Pl6bGhHm jWXWMp+qLZiQFMy2lNM4qPbQzNIeQpr1ZbFfJQ6dzWFgnWaEeZk3r5hmOLxqbudithP1mzey6rLC j0xq9X6Wf6pr6dYfhblExrFgnp5vlYj7Jdaherh5HiXykYEsCq7GkfMGnqzfQv1Uzlq9IGtF0DbL sRmhNoXXJ6IOCREPaaDtXQkNt2w3trjo6FuJ+IQ70+75RdUjwaw3Vjc3Nfqoq153s6jaLbjDLTtP GjS33u9k7+aXR2gtEiwbkG/93D+q/l042hFdtyVqBr/UzTvo9sbqEhBNK/X6uQVVaUiQ9Wdkf3LD wZfG8Ql38nINpkUr84NvbjW3oBhaqVdpmaMS5IS7XFfB0Y0IvgOvA7ENWhJbWs6qcj0DQ+7680v3 4FhaqdfPLbRaE0Kt92iFUiRjO0XblFDbTlilpkJACAgBIVBeCIhQl5dISj2EgBAQAkKgXBIQoS6X YZVKCQEhIASEQHkhIEJdXiIp9RACQkAICIFySUCEulyGVSolBISAEBAC5YWACHV5iaTUQwgIASEg BMolARHqchlWqZQQEAJCQAiUFwIi1OUlklIPISAEhIAQKJcERKjLZVilUkJACAgBIVBeCIhQl5dI Sj2EgBAQAkKgXBIQoS6XYbWxShWcZNHoaXxx+iKZKt+1OWGohgrV+/LMYD9enLSIU7kOPDJ0FpO7 1+PYZ0uZ/urHpF/NwGDOFKjMg74TF/Dko3c+izNl3UvMWJrOlNeTqWl5BvSdhK/xztRkUh1bMnNS l9+d8OX09pUk/2MFZ6/m0WvqyzzeIuKPBTPnB6YNGcfuG/ZUa9hPJRzpJtmU/hhR+bYQsDoBEWqr I5cCHziBoitsfPtdNvvWoH3jKqZU0iVCbXfhf/R8dBk5Ie1o4HGOKYl9CKv8JbHHv+G91f+hTuu/ ojIZWswNF8e7Xw4Zh7ewavUhBi6a+gtCncuOtavY5ObJtD8g1BlHd/LuqtVEt+yNs8MDSCytscdd 78i3K1fx7bloJohQP/DmJycUAn82ARHqP5uwnN8KBOywU8mO2gyfz+qJbW+Wl//dP6nTOY3XPt7A Y0EHaaSJYc3nO6no4YqvXQWWbFxF3D208GrqGoYlzWR/ejCNa95A6+SPTmvORHQt9T8MTXqeg+nQ avgc5g1pp7KCaXHx8MTT1Vn9pazgBh8sHMbsZSkqB3YEAycPI+uDxaQ1eYqXhykf89JIfnIAeW3n Mqdfw5s+a7R26FVm50lvL6NnRfjkpWd4Z8d1At0us/X7DBKfnUbguY+Y9c4uWvSZwsKk9uhMPZOi bFbNHsvc1dsx6rzoNHYuk3o2Ruccybgl/+LMoe94P0tr6cRYISRShBAQAg+MgAj1A0MpJypNAk4u atS4dgkTsr68KUYxrfuw7+Rg7JWQndjwAUfxpmfDmrgf30ah8RoLRkzkE0uWRY1XBIlPPEklLw2F mQcY1XMAH+TGMLRdBb5Z9ybFxibYOzpQfG03/bs8yaXYzsTHw/qJo/H3/y8Tu/rcHMmbsjweXL2A qfP30HJAWzJ2rmXs2FcZXPcyby78F5OVULsdWMPC9/Yy+fGAn2EzqW4xWdcK1P86zu3fysoV22nV YyBhml2M7p5As25PUNUtnSXTp9CmfUv+UtWVE1+8StLUFdQb0h+P458zd/ZMHotfQ6NAU0/kKnkF RWg1NxMal2aopGwhIAR+IwER6t8ITA5/CAko/bHX6bh4cCfvX9x/08HHwtvRT2VfPLvlNTp0nEWV xJcY3qwiBw7kU1Scx7Z1y/nOnHYYbWh9HuttEmq4krqJTw448/znq5mUEMTmSpd5dGwadkrzrn3/ PzYdu64kfxeGtGJOXznC8tUfKaEeg65kdF6MSWJDGnVmxsJYTqeuZXPadQqv5FJrai+iPpvNRwdz qPT+Srzj/8bfW4b/AlC12m6auvZ/lDc/eBPNiiQ29lrJM6+8Tttjc1gR9zKnL10DJdQ6B1P3IJOD e/cQUbk5cxM7EO7xAKbOH8Jwi0tCwNYIiFDbWsTLY32VnmVnZhGf9C4bkrveVsPT29+iW9+nqdB/ CeveGlKyySsrOws7rT/vfX+CRy0j6lu/VJiXh4EiXHTmy8PLxwc70kzL3lw5fwaDVk/LTr1oHOZC To88Amo0VUdlU2Q0Kb6dGgfDV2uWMGrW5/R/ejzt66eyeJc7jeLbUbfyq6xd8Dz2+6/SvGsvgu5z BRqLNegc3VX5alycU4CTNgS9C1xXf6Mm3O3tzKPkoPrdWLy0gI9XLmPF2n+zdeOXOAXVZGj83XOH l8dmIHUSAuWVgAh1eY2sTdVLKbX6d/q7zaz7xOHm1Hdx5inmjBnBbmMr3ugazpfr1+Ef2xCNzpF8 YyafrfyEgpCfQIVUa0itSD+8Y+Ko5z6BBS/MpdK1JvzrxffIozpFaod4aP3WVHNehMEtnEbVNTw3 8XU61+ynTlJEQX6BmlLXqjXqIj7dsJ5013okxNVly9dzMBoC0QbE8HRiAg0Gz8cY1Y7Ng1reN0pF hQUYDAYK1ZHGQjUTYHTA0VmVpt5XC+FqZsB8igOb3mLmvP/SZeRI5jTfwaznlnLs4vX7nl8OEAJC 4OEnIEL98MdIPLwfATU9HBgeyuZPX6PzupdvOdo0GnXD02E3I3v8hfxCI4+/so5h/hXx87Rj0chO LDSNgktMy8AF63k9qQ1OgU1Z8lYy3YfOpMvGD4lvFYN3sB+agkIcIjvwxuLh9B6TSNwsaNBvKp3i TKPWDFy8vNG72iuZtmPgiHF8PGwGndoMoEvPplTTXOR4BnTs34+owa+hbdaOpr7mzWm3m0l5Nbh6 mufknd298PX1LBlR2zu74+Oj/lY+ax1c8fT0xtnefI7o+N50q/Uxs5KGqI11jtRLnMGodlUtp9bj pNOqzoJF1e/HUz4XAkLgoSIgQv1QhUOc+V0EHKry4lffMVfNPf9cijQlG6iKKbZ84OTmgZMmnj2P JGL88U1LoU6unpa/7KjdfSp7Ww/HUOiEXm/P9UwDHnqTXGpoOvD/SO2SjEEJpoevr5qANpkXE5dv oEDjWLLrO7rTeHa1SCSvyBlfH1eyMjK4fGEHr6vd3Jc1fiT1aFcivnfItPIpjyzWv/0m1QZ1o/fs ZXQu0GLyrLjHDPY8VoSH0nBt89EcOzZECbrZZwevSCYt28LQy5mqthrcfX3Mv+UuyOCLNcv55mg6 2sCSiQcxISAEyhgBEeoyFjBx9y4E1IjaTY1m3X4DHG/T/PF9zF3vi7vlGB9v02atn8zd+6fPzO9q lWjqbzvGTX3/R5/c1Dr34U/mMm72cmoNmMbwRyvdtXRnryCiQkPYsHgK1eo1pU6Xatws2dEV7xL1 VaZzUaNrtVh9mzngozoOt5khjTdnvsCRPHfqVgm8a+fgfhzkcyEgBEqXgAh16fKX0m2IQJ2+s7n4 t+dxcHIy/9b6Lhb92Ch2HhleMgNgrzOP1f+QudVk6c6jajpedSUsG93+0Pnky0JACFidgAi11ZFL gbZKQKueyuJkejLLL5hGa4/jPZ6Q9vu4adU6vWPJTnQxISAEyiYBEeqyGTfxWggIASEgBGyEgAi1 jQRaqikEhIAQEAJlk4AIddmMm3gtBISAEBACNkJAhNpGAi3VFAJCQAgIgbJJQIS6bMZNvBYCQkAI CAEbISBCbSOBlmoKASEgBIRA2SQgQl024yZeCwEhIASEgI0QEKG2kUBLNYWAEBACQqBsEhChLptx E6+FgBAQAkLARgiIUNtIoKWaQkAICAEhUDYJiFCXzbiJ10JACAgBIWAjBESobSTQUk0hIASEgBAo mwREqMtm3MRrISAEhIAQsBEC9xJqnZvbb8nuayO0pJpCQAgIASEgBB4wAUdHR80vnfJeQn1q27Zt RzMzM++e3f4BOymnEwJCQAgIASFgqwT27dvn/JuFOjk5+Ydp06YlqC9WtFVwUm8hIASEgBAQAlYi kK/KybtXWfdco1Zinaa+ZHqJCQEhIASEgBAQAqVEQDaTlRJ4KVYICAEhIASEwK8hIEL9ayjJMUJA CAgBISAESomACHUpgZdihYAQEAJCQAj8GgIi1L+GkhwjBISAEBACQqCUCPw/c5qhvlCaP1cAAAAA SUVORK5CYII= --_006_CB68DF4CFBEF4942881AD37AE1A7E8C74B90346104IRVEXCHCCR01c_ Content-Type: image/png; name=image003.png Content-Description: image003.png Content-Disposition: inline; filename=image003.png; size=32729; creation-date="Tue, 11 May 2010 11:15:38 GMT"; modification-date="Tue, 11 May 2010 11:15:38 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAeQAAAElCAYAAAA1GpHoAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAH9ZSURBVHhe 7V0FfFPJE/6oQnF3d3f3w939jxx+cHC4HO7u7u5W7HB3d3d3CgVa2iL/mU1fSEtLk5CmaTtzvxxN 8t7u7Leb9+3Ozs44DBo0CCKCgCAgCAgCgoAgELIIOIRs9VK7ICAICAKCgCAgCDACQsgyDgQBQUAQ EAQEARtAQAjZBjpBVBAEBAFBQBAQBISQZQwIAoKAICAICAI2gIAQsg10gqggCAgCgoAgIAgESsjf vn1rGDt27CIeHh6CkiAgCAgCgoAgIAj8BgL29vb4/Pmze7Ro0fq/e/fOO6CiAiXkiBEjVmzXrl2j 36hfbhUEBAFBQBAQBAQBQiBChAhYuXKl999//z20U6dOphEysflHZnQRQUAQEAQEAUFAEPh9BGih +9bNze17YCX9cg+ZzNaws7P7fS2kBEFAEBAEBAFBIJwj8P17oFyskBGnrnA+QKT5goAgIAgIAraB gBCybfSDaCEICAKCgCAQzhEQQg7nA0CaLwgIAoKAIGAbCAgh20Y/iBaCgCAgCAgC4RwBIeRwPgCk +YKAICAICAK2gYAQsm30g2ghCAgCgoAgEM4REEIO5wNAmi8ICAKCgCBgGwgIIdtGP4gWVkDAw+MT 3r17ryLmxI0bFw4OMvytALtFq/j69StevnwJPs9JIQgRJUoUi5YvhQkCIYmAPJFCEn2pG8uXLsX7 Dx8CRCJ58hSoWLGCxVBauXw5OvzTCRHsHHH69AlkSJ/eYmWHtoJevnyBdevWK7VLly6DtGnThIom PHn0CLlyZoen9xdMmDgZtWpWw+rVa5TuFSpURIoUyUNFO0RJQSAgBISQZVyEGALDhw5Fn379Aq0/ a7YcQRLyvbt34e3jgxgxYiJ+/Hi/bIu3tze0ZClfv34LsXZbu2K2DDx69FhVmzx5clD4PgwZNBBT p89Un02fMTvUEPLXb1/x/r07vlDAo89e3hg5bCjGTpik2rF23QbEixeX2vpIvU+VOjUcxQpi7eEm 9f0GAkLIvwGe3Pp7CGTImBG9e/fmDCiYPWsmPnl4UoER0KJlC8SPFw+ZMmf5ZQU+Pt4oV6Y0bt29 hxat/sLc2dN/eb0+NnsEB2W2Di+yd88eVKlaTTX3wMHDKFa0MDp36YZYcXQTmMKFC4QqKBwdHfCF Vsgc1vfvjp3gEjW60r9A/nxw3bAejf7XmN7Z4er1a8iYPl2oapsoG74REEIO3/0foq2vWasW+MWy avlSPSH369cfyZMl1RHIgQMY0L8vXrx8DS8vL0SNGhU1a9bCgAH9MWHsWNx98EBdt2bVchw7cgAd 6AGdI2tGtGzVBu/ev4dL5MhwiRQJw0aMQuxYsQJtLwV8x7GjR1VdnrTy4pCzWbJkw5Qpk/CK9iwn jB+HE6dO4+PHj4hMZfJkYfGiRbh65SKat2iFCPaOiPDVC95fv8OBkrLUql0P/fr2xsjhQ7Fy9Vok SJQE2//bgufPnqJq5Urquh69+iBn9syYMnky9uzdh0+fPoFSnmLkqDGoUL4sTp86Re2gsu0cYI+v ZKb1Qdas2ZElY1qsWLVa7YfzPuo/nbqgetVK6Na1K46dOAm2BMSicjKT/rNmTMOYUSP17W7SuBHi xk+IgdTOM6dOwsvnC0qRyZrbdeTwYfSnz9+7f4APfc77s382b4lO/3TAO7e3qFqlMtw/esKRwtvz 6tTO0VHpM2fOLESiVbcmXP/I4cOx3tUVX74wcTogopMDvOnvXHnyoUSR/Bg/cQocnSJh/77dpOMM LKatC5ZmzZqjffu2GDRgANaQSZ31ikX9FiNWbKxetZIsIdHV/jGLI9UfAd9xlPqNJXeu3Birb+s3 VK5UkdoQDU523+Hz7TsaNmqMHt27YsWypRg1Zqzqs00bNyBpkiQh+juQygUBDQEhZBkLIY7A69ev wYlMNGFyZELeuWM7ypXX7SHHiRsfuXNmw46du3Dx4kXEI1JxI5LQTM/u7u9x9ep7PHnyBJvXr8KV q1fxb5++2LFtC86cPY9G9DDOnzt7oG11Xb8OzVu28vP9VSqjcOGCmDVtKq7evKW+q1q1KjZv2oQr V64QUdqjfu0auHDhwk/l8meJEiXE/Xv31ff3Hj4hXb/iA+2XnyJ9WG7QCm7CqKE4ff4i0qbLgOZ/ /okhZMavV68etlPbnYj4/Jd9lepdRfcmSJgE//buhX7UxjGjx+KrtweWrViJosVKoEC+3Bgzdhwu Ur3Pnz3DzRs39Po9oAnM0+cvCafH2Lptu/q8AxH64YMHUKFSZfU+Ge3dp6a92H00GercqaOaBDWs XwcnT5yA1xe/pn6uw4MsG0uXLISLi4tvu65jwKBBAWLt5OyCtCmS6Nv15ctX3Lt3T//+2fPnePf2 LU2gRiJJ0uRo27Ythg8dgs80GSlbriJmTpuESDTB+uzzURHyu3du2L17t6qrZs3aeP3mtb7eu3fu 0N+cHEenM1tg/ve/Bnj54oW+Pk9llRERBGwDASFk2+gH0cIAAc20PGzIEP2nU6dORR0iv8IF8+P4 yTNYsmQp/tvqipW0Urz/8BHq1GtIK8HhahXs4NhTrfCYSL75eClCfu/2Cjt9H9z+weaV5tgxo/Uf b9n6H7JlyYyvNEmYOH48btI+NUujRk2wdOki9O3dE8NGjsb27TtQslgRg/u24fbNa+jUuYv6bP36 9ahTqwYWka6f3N9hIjkh3b97U30Xnwh1/55duHLtKq0UnTGY2lq/bm1a4Y3AB7r26LHjqFK+jL7s MmUrYM7sGahXp7ZaqceOEwdFihaltj9QRB89ejQ0odUlt/nTp4+YTHp70arwwoWL6N61C3r/21eV tWLFKhQqVBBPHj8gsz2UJeD506dYsXi+vi5e+Rema7JlyYRrN29j0+YtaNq4oVoxe71zR3da2deq VhmFChZUVLd9+zZ4enrqCXnI4B9kPHXqdCRLmghVq1VX5TOZOjk5qb+dI0ZRWwfOzs76ur9+/UIr +AS0T6xb/bOsXLYYV2/cxuWL53Dp0mW1B05LdbVSNsxGlzlLFvQbMAit27Slu+ywm0z1adOkQrs2 rbGV+ur2rZs4cuQo5s+fp8rNmi0X1RFVX7f8IQiENAJCyCHdA1L/Twho27vPaHXHkit3XhQtUpge vvaIEll3zCVipIjKkcuJVkks/Dc7LDE5jR41CvdpJeju7k4m5Svq+wi0b+wS0RGfiDj8yzcigefP X6iP/yhdHsWorqi+ZODt9ZnMrl8RLUYsMh+3UNewOZiFTdeGR6dSpUqFTx/e6YtnsmhGq95ePbrh xeu3uE2r5acP7uvalCuXWrEfJDOxS+RIuHLpIlrv3omo1I6IVF/MmLHIavBVX1a3bl1V+7p17472 7drT9efJ2zgn6jdoQGbYHuA2zJ4zR63AeU/+mwLxO+ESA4kS/zDJ8uo3GVkfXr96ociYxYec4rT2 Fy9RCtmyZaVJjaMiT62dTH6aqZid57it2i48E3UEgzStvCpnSZ0mPaqQmfvRo4c/Ya594H8vn1e9 fKyJTdbcVz6ExYtXb9TlESI4KvIOLIWdMxF1PPI90CQ5rfKTJUuGPn37YRdtCXjTKnvypCm4eVNn MWhM5vsECRIEqpt8IQhYGwEhZGsjLvUZjYBmxr5FD9DHjx8pE7BG1rw3yaI9nLWV0qKFC8hU3Ud9 x6ulmLTnePHSJaKmX4tW17kzZ/CKTOgaIWt3eXz8gGPHjqFE8WLQVvBMZIamdiZC3j/VRPuuePHi WE0ewEtIt29fdN9zOe/evFR/f/v+DSmJ4P76qy2toifRCtJR1XGIzMj6+j081J+169RF9eo1MHLE cKxeswYrV6zAli3byLz9DW/J+zh5qrQYPmQQ9uzcBp9PnxU+PgY62dv/nN+cr9F0vXD+HN68eUMT gpiMrqqT22ko/J7bGphoZT198gh3yboQI4ZupRuQRIkaRb9i5u8dHBzRs3s3LFy8BE7OkTB37lxc Pn8Wb966GdWHhrpq/ZQ3f35UrVgea1034fDhg0qNqNGiIytZAEQEAVtCQAjZlnojHOvyg9i+6feF 2//9N7p0606rPnfaZ3yAx2SePe27/8pe2CyfyOmHZcumDThK+4O8Z8sSwd4JfzZrhlHDButQNSAd EAEaCpMve3aPo+MzbmTavv/gEfbs2olVa9bSyrwo4seJpVa4N2gf+erVK5g1a5a6PSatPiPRSt1Q DFdvGjk0+7OFIuRPn36ct27UqCE8ybQ8beoUuJMz12YyC1coX45Mte/oSNJg2s+thKSJE/4o2ncm 0qVTJyRPmZq8i/8h4nyNS5ev4KPBqrxunTrIkSMrPhIZa/L5s5f+7xEjRtAqcYKfiUOixInRpm0b dO3Ri/Zk3+Le/Qc0GdiPm7d1pvoEvsfJtD7S2qihaDgp4es7/PMPjhyn9nl64NDhI7h+5cceewS7 CPD0JXMvsj5UqVwF169e1uvHZT0jEzpL3vwFlXNbv397+vbhNzXB8K+HdjOvttnxTyffMJS2AQb0 74ekSZPREai0yrytnySVKIny5cv76Tt5IwiENAJCyCHdA1K/esgarizZ7MxSt359zJ47D9evX0f9 +nX1SOUrUJC8nyeq9+UrVsT8hYuUk1LhwoVQhJyaUpFJ9i7tK6dKaRgk4ivVoacQP2ZPNpM2J2/i lavW4AmRQak/SqiynSO6YAg91F88f4IZs+Zg0YJ56sUSl5zMli5dDI+P7/2QiSE5aav4pGRqTkGm 0/sPdabb3PkK0PlYeyROm5ZMzg1VG103rFMvTdLSkbA0qVIYlK1brfKqecKkSehEzlaa1KhZBw4R viqvZN5H55cmvBebg0zb6Sjwx81bt7HRdT127NqFyRPG+Rl5deo3wKQp0/CQzvCWpaNkmrAj1bBh Q5S3s9ZH3D/KhO17EX9uOBGpSJOJAnlz4/ipM+jfT2etsCcy5D15T1rpFy5aDHFor/81OW9t3brF jx5cdvUaNbFj9x4cObhXRVT7IV8VoWp68N+GePPkLHOWrEhAk7XnZPaeP28ulpOj20PaJuhHJvCF ZKF4+eatKu7ff3v7qVfeCAK2gIAQsi30QjjXgc2ju/fuVwE++Bxyet+zo4lp73Pv3r24f/++2htW D3Yy5WYksuK9UZaZs+egZes26m++Jh1F3+IH83Py1mVCtLenI0P2dDiG2MOOVlBMCmz3TpUyhR/U M5FD0KFDh/CcPHB1R3XsED9BQqRJnUrt9zZu+qd6+POL941jx4mrSI49wrVjNxlI7+RJE+vf8742 SxYqez8R6dOnur1V1lE7gjVt5kw0a95CEZrWRi4/NQW1iEp7s1rZ6TNkUPcuoWhjb4hUWA/WkV8F CujOEXc+ftxXx+/K7M3XMF758uXD3n378JAmKSzk66XalZ32ir/Sm9Rp0iAeEd/BgwfxlPZ/2bEq QgRd2dmyZae9chdl9t5/6LDaT09GE4y4tI/Ox8SYlB0dnRDdd8+dy48aNRr+27GTJlI3lA7HyEGt Z8/uqu4PdKSqZMk/cOToEWWGZmFv9Qi0ov1GuiRJmlQdQ8pJmHNfMSZcPq94v9NVqcm0n5MmGDxW UqdOQ45mLj8wIlz5iNQh2pfnbQdt0hCDHN68vb30Ww3ssR87lq5vRAQBW0JACNmWeiOc6sIElDtP ngBbnzBhQvArMOHVbUHy9vUjRC4pU6Y0GU3ex+WXf2FHop/q8L2IJxOG3zF5xfGzqtNdyGFA+eVf HGjCEFjZfK3/7zJkyBhou35VDk9u+GUo8ePH9/M+eQrSkV4BiSN5RufNm8/PVwX8427wLTulafp4 0ASJyZaFz1rznnm69LoJRmCS33eSEdD3ho5bAWGUhiwP/DKUVxQq9O1b3ZGo/zVuQpMpv9//Uhn5 UhCwEgJCyFYCWqoRBMIrAlHoKFaRIrrjYSlS/DzhsQYu27dvR4HCRZV/QqaM4TeGuTWwljrMR0AI 2Xzs5E5BQBAwAoGChQqp7YCQlOYtWlJEtZYhqYLULQgEiYAQcpAQyQWCgCAgCAgCgkDwIyCEHPwY Sw2CgCAgCAgCgkCQCAghBwmRXCAICAKCgCAgCAQ/AkLIwY+x1CAICAKCgCAgCASJgBBykBDJBYKA ICAICAKCQPAjIIQc/BhLDYKAICAICAKCQJAICCEHCZFcYAkEOITjuLFjKMLSFxVDuESJEpYo1mJl nDt7BqtWr6HyIqBjxw6UyCKRxcoOCwVpoTH9Z2cKjW0zDPPJ7flOEcFGjRqJd5ScI3+BQqhRvWpo bJboHAYQEEIOA50YGprQr09vTJk2g9ILxkKHDh1sTuWzp0/RQ3mU0qtmrVpCyL49xKErJ44fh8lT p6lPON53wQJ+I3bZXGcGotALCqd6iMKD9u7dCz4UIMTJmWOVD0Qlir3tTBHfuP/tKNToFUrYkSGD BA8JLf0alvQUQg5LvWmjbTlDKQ3Xb3BV2mXOlJlCOCa2OU0j+ub+ZcU4HnJ4lVMnT2AOJbugyN+Y NHkiIlGO4Xfv3sHDN/3jd4MczZbA6BGl1RwyeIgqqnfvPhTy1DAhiGk1+Ph4o0e3bpRH+TPq1GuA MqVK+ilg/bo1aPd3R4rTzbHNdaE869erh3oN/ocm/6uvYpRzHPOJkyZj5gzdBEREELAmAkLI1kQ7 nNZ1/dpVyqKkS6wwcEB/PQr8Oecq9vb+gogRnVGhQkWVyGDf3j0q8QA/IL9RogMOgxyFEhaUL1dW f+9+SjrxjBJB8IM1OiVxqFSxgv67b0Qa69dvUKn4uAyOm5wzR3Y/6O+nOl77JjeIGSu2SkKhhJIq bHR1pbjTydTbYpTLmBMvBCQ3rl9T6Q81qVixElxcIuHwoYOUpOKlyiPMsbZTp0mr6r9HuYHPnD1L qzAH2H3/ii++8Z1L/vGHSjZx5PAhPHv+AqxPqT9K4g0lSNi3f78qvjCFnkyYIAGOHztK6SEfqqQL LpGjkHm1mvr+0YMHOHHqlCo7ApWtkkZw8gXC8xzlOPahrQKOyV2+fAVKyBAZBw/sV33C+DlRnOoM NFHKkikjZkybhgWUi5glQ8YMKpFH67ZtkSCRbhKl4fKViGsD4WSY9KNcuXKUWCIq3Gl7YhdllPoe wR4OlH5ZZYdS5WVClsw/chBz3cuXLsGcOXNU2VGjxVCr7zJly6pkFb/qY8569eTJUxob36nO6KhS pRJ279yJiZOnqLKePn+J925vVGKQVL7xyTm+dZMmTTF69CjcuXVTZZ1iWbd2LWZMn4Ka1SpTmkxX 0n1PgP0tHwoCwY2AEHJwIyzlw5kyD2kSO7Zu9XnyxHHUqFGDsgs9JzKOqBLely1XATu2/4dOHf/G xSvXf0JuxszZaNq4EVo0b4ZVZDrlZIpajtthw0fh3949cIAIbMDAgThw4IAiGk7VxwS3hnIbc1pF Jos2rVtiNb335UNVT0bKpkTJjdRn3bp11dfNOXl5ZZXE36q+L6XvW7iI0j76TjT4hgIFC1Pqx8RY t4EmA96cuUonXP/27Ttw9cJZ/Nmq9U/tKlK0BLZs2YihgwZi++69SJ8xK+UIvoi7d++gDuU3Zlm2 fCVOHD2EufPmwYNWgI400fAhUuzUpRtGDh9K7d6Hxs3+9FM2p4iMHNER9x891mNct15D1KhSAQ3+ 11hdq5XDma3Gjx2Lhb5kzN917dKZ/m+PqZTq8m/fbQYmsYdE/r1798YBMv8aSvkKlbBm9Uo8e/YU tX31Nvw+XvwENFFaj8KFdMlAeO92zMgR+kvGjxuj/t7guhGbKBXlokWLf+rjzp06YJPrBkWs3tT+ CFwOvcZTLusDu7bpy9q6eSP4NXzEKPTu1UN9XqZsefVieXD/nv5atthEjx4dkaNEVZ/ZU2pMTjcZ hbJtiQgC1kRACNmaaIfTuhwdfhCyZips2by5IuPadRti1YrF6PtvX31+3ahRoimkkiZLqVY+i+bO wicvH/z1V3vwXu8KImOWFSvXIFXyxMhfsBD6UBL7ArS6Wr54gY6MnSPj1ctnGNjvX0yYPBXNW7bC g7u3iFzXYuXqter+wkWKIVf2rPhMpM2r3Rs3+On+DY3+1wT3796mFIFHcerEMfTr1x8L5uvyILOc P38e06dPhxs5ASVJmkKtrHgFyivG48eOqGuKFS+Jgf37omOH9rh89Trate+A5k3q68to3KQZbl2/ iuMnT9KKer8ijrjxdNmXPn50x4ULF3H0yGH99f9t2Yx1q1fg85dvGD12POrWrI4UtPKbOH4sWRYq wDADElsM6lF+4xVLFuHVq0+oU78RVixdhL59+ihLQzQinw4dO6Jx46b44u2JQoWLUM7nZ+jRqzdK FC+KfQc47rQd6tarQ6vstJTqMrqvHhEo3eQ7LJk/W0/GEydORtxY0dGqdWts37YV4+n9X61bEI3T yphepUqXRUxKf7iWcH/54jnatvkLF2liEoFmP2w6rlmnLpnI56vyy5OFJHWq1DhOqRkXEBkH1McJ E8RH984dFBlPmTYTtWtUxUja++UUi5WqVqUJzR41GcqdJy9y58qJQoV0qSn9S99//9V/1L17d5Wa 09PTS31259Z1TJ06Hb18iTzAAuRDQSAYEBBCDgZQpcgfCPBKY9iwoT9BEidOHPXZ7l3bUaduA0ye NEG/t8wZeVhy5M6NaVOnIHWKZOjanVY5ZIqdM3eOWhUlT5kaUVwi4ijl2tXk4sXLytzMUqZMaVy+ fAnXb9xS71+QeZtlwQLdwz9atOjKfF66dCn13nX9WhykfL8sM2ZMxxJKZs+EzPL5s+5BrcnGDesV GdtRHt+mTRpj6NDB6qvXr19gzboNaqXVpXMnsCm6HJlfmZC9vD6rXMI6scdcaseUiRMUIbN8/OBO bexOK/fVePLoAXaS2XTzet3Eo3LVGnj7+qUi4zjxEiBl8qQ4ZEDWHz9+QnQXzhmsk7nz5qM2EfZ9 Ipade/aSKXc7EXRDTGKMfb3HeRLz8eMHbNm8RX9f0qTJ0LBRYx0hk+l+Mpl/48eLC54MKKHPbtKs hVe5LBkzZ0Pbtm3IFO6EHj26weP5K3h88lD9o0kX2tNNlSyJImQWNuN/pwv4GiblVpTLWiPkf/v0 RdHCBVHUdwWdIoA+ZgtGHMpF/eb9B0ygFfXdO7cxaNBgWuFGA3vy9+rZUxEy7yH37MYr/J9l9swZ OEq5o1nKV6yMunVr+bmIczizxUZEELA2AkLI1kY8nNXHe7hp0qTBqbPnVcu1Pce15OQ1ccIEjKH9 PDYJ86sXOfWMIPOrnb3ukf6N9h5ZMmXy3XfkRPb0sGQTJT/MeW+UH5x9+/ZV5sWsWTPpyZPNz9u2 bUNOIvX8lLc3XnxdTuUIvnQRg/ZsOZexJuzMo4mbm5veiYk/syfPW0Ox58JJ2CM3Veof6QT5Qc7C ZB8/fjz1t2YR4DIMjwy9ffuWTM8e+mLtiOyyZM0GJ9pz9vL5ir20x/30mW7fPWWK5PD5/FGnP63k bhApspNVH17xUruzZ8uKy+fP6MtKny6d+nv5qlWYOHEixtAKct3a1erVuUt3Ivy7RPzrEDFSZPxR sgSthQlrX109PD7py/H09FR/a+1Sbab67akfWNLSnqy3txftk/9om3+sPn74oIhSk5++pwmbJry9 YIiZ/z6OHDkyqlWrguJFC2LsmLGYRXvPE8hCMJMIdtmy5ShdqoQeb22c6Qv3/WPO7Nlo81c79a5U 6XJknVlO/aUzVRuK4Xj46Uv5QBAIJgSEkIMJWClWhwDvDzemhPArfM3E2gP56dOnGDxkCDp37oxW Lf7EOtdNtCe7WEfIvoT3jkiLE9qPHjlSV9g3H3LQSY379+7i7ZvXKEd7zvny5VFf8b4mE3XSpElx 7dZt3Ll7H5s2uuq7gR2qWNIRWR04fAQPaQ/xMjlk5c6dC8dptXT5yg/nrKD6LnnKVIhIDlKfyWls 06YtaP5nM5w/d44csl6qW589fYyTp8+SCb0AHj58pD7jVawhsfmvgx3QmGzZlDx85Ghl/mWJ5BIV //zTEcvJ/MzTlE+0ks6WPSeqVK6ovn/y+Ak5tUXHGbpfE21194y2BIYMGUqr9c5oQTpuIF0njNft 07KMHD0GNatWIketH57NP3T8TnvYd5GCnNvs7XUTEN6tjUZ1pUyVEm/PXyR8NxKpRyJz93P9RMiD SNyUs8qGZ4JvUb+VKlmcJlZZceT4iZ/6+Mnjx4TBd1plf8VMItZ+/fuTib0Ibt99QHvsK1CpQjnC WOc9zbobChPs3Dmz0b793+rj/5G5fsnihX6u+e67aRIxkoveEcx/P8l7QSA4ERBCDk50pWyFgBsd m9FEM9uWLFYM8RImRkl6AJ88dVp9bbhi5fdHDh9AQTKtXrp0UX1foWJVDB86APnz5MH7d25o2bKF IlReLa5evRonTp5CvwED0JAclq5evoDq5DQWM0YMXL50Gecvkje3lyd9PxBz5y9Qj96Zs2ZixfIl 2LFzlx8zq3+TJU8KDKVxkyaYOmkiTp49hyNkOm7WtCkWLV5MzkBOcCTu8qHl5kIyee/e8R82b9ER a3NyRItMHtg6+aqIw9As+oFWkjwRSZNGt7rVxNHRiRzKEoFNvxxY5T0ROwcuYYsCWxAWL1mCdeRR HoW8mzXRiKVE0aJIkCQpkVYxnDqtW0FHJIL/7vURXl+/Yy05YO3duU2/d+9OZngHbb+ftgcq0/nc v9q1R9bMGXRF0/56hgwZaYLwD5r82YLef0GzZs1wkBzKXru9R4yYsVG3dk18oFWvZpz3JvOx4WrT 3d3dT/vY7K/JX21a4tTJ42jYoD7htzDAPuYVf5dOncjUXIlIMyXu33+obo8VK6Z+dczv582egZfP HuOfTl2UMx+v0ttRW3R0zROkD2jTpjWt8H0IkyjkXT4FkSM5q+9SUR9wf4kIAtZGQAjZ2oiHw/qS JU+h9iJfvHyFgQMHkSf1VtqrbIiz5y/gxIkTSJMuPTKTuZY9d1k00mYzMzvrlClThhyeEmA2ESgf i5pEQSo2btqkPGEvX76sVmRlaa82sosLqlavgQ7t2+PWnTu0Un1KK8jHcKIjVY0aNVLm8kTkUTuL yuFz0UyC79w/oGmzFihJK61VZOLlBzaXk5HM5BxRjKUQmbz9y6SpUzGIzs9608r0ytWrSscBAwbh 6ZNHmL9ggdLt5avXqoy8efPjX3IQ2rNrp2+Z9ohED//MWbLo68ifP7+qonbdujh37izpr1vhNW3W XB2dYo/x2eT8tICIiicg3G4WrjcFr3CJQDV9tYlNfSK2CzQZYYzT0tGvLNlyYCB5ct+9fRtLiMi5 /S9Ix8qVKynMkyZLgSY0ueDV5bXr15WH+o0bN8msXVxfNpuna9apR3vfp3D33n3cunmTCCytMrd3 7dadJlBkFSBrRSVqN5NyMto/jhMntv7+5MlT6rcNWH+2IowgH4MDtH//lY64Xbx4AT179VTe5Etp 1eu3j8vTMaxMaNiwPuFzDy9fvkDJUqVp/zgmOQX2Ikc+Z8yYNYsmKUsVOb98+RK8NcDC+9z16tVV 0bhY2Int8SMdmUeOEh2P6QjVA19rhpevqT4c/lSlySGMgBByCHdAeKi+CK3U8uXJhc3/7dDvi06a MjXQpmtmzDz5C2DrRp0DkaG0/esv8CswmUxk+SthRyJ++ZemtNrTpFbt2uBXYFKAVu68R/2zFCQn tboB3laqTFnwS5OGDRsRuTTycy2f49WiYvkvpC4FseBXYOJfn6nTZwR4af58+dCgYcNAyxlPe/v+ haNZGcq0QMrma5LRBGGLP2wCxkq3pdHr3z7o5a/CdOR30Ii2OgKSsmXLBKp7A8KTX/4lCjnarVi5 KtD7/tu6BXv2HVDft2zZMtDr5AtBIDgREEIOTnSlbD0CBQsVUYT84MF9nCVTby46khKYaCZiNqGK CALBjQCb1Hdu366qSUye5o3/1yC4q5TyBYEAERBCloFhFQR605GWXOTxzI5QbIL9lbDDjtu79/pz uVZRUCoJ1wiw5aJ0ufIqqpsthnYN150TjhovhByOOjukm1qOwjYaI4WLFDXmMrlGELAIAnw0rwoF FRERBEIaASHkkO4BqV8QEAQEAUFAECAEwiQhP370iKL/zFXHLbQsNRxHt1fP7uSRq52phEo+MJ0c gNzoSAR7nLJEoID4Pem6+PF1YQxFBAFBQBAQBAQBayAQJgn5HgXlHzxYF84wfXpdXtOUqdKgZw8m 5B+wcjhDDjzvRSEJOeoQnwO1s3Ok4AHtiJCtAb/UIQgIAoKAICAI6BAIk4SsOQ01oLi8y5fqgtQH JHx+NTKlsIsTNSZu0nlKEUFAEBAEBAFBIKQQCJOErIX/u37tGtatW0cBGLIiQ3q/EZA0wDlYhBsF D1ixciV5VyZFsaKFf9kXHN/3OgVNYDLnFzuEcMB8EUFAEBAErI0A56vmPNciYQOBMEnIHNUoduzY uHP7JmVyqUuJBRKoSE1jx4z202tMqJxw/THF/G3SuDGFPnRAzRq1KLXeNIOUc347moNW8N4038v7 07yyzpkz8DO1YWOYSCsEAUHAlhDg5xA/gwxjgduSfqKLeQiESULOmSs37lDoRB6svPrNnDEdJTCf iFq1aqFgAV2IQhY2Vx86elxdx6/KFJx+xYpllCe3CNq3axsgoi4UVjFv3rzqO45FzK/cdL5WRBAQ BAQBQUAQ+B0EwiQh80o3OiVhZ+Fk7DFjxMJTiqO8k5IIGBIyzzCjRYumxy8WpeRj2Uw5YgMjZEOw mYwlTdvvDD+5VxAQBAQBQUBDIEwS8szp0/Hi9Rt0794Nm1w3KDJOmDgZ+vzbm5LIv8IiSvOXPkMm OFOg/KPHjlFA/Wb44P5OnxFn9CjfdH8yTgQBQUAQEAQEASshECYJeaOrKy5fu45HDx+AHbuyZ8+O fv36kwOWvcqx2o1S2RUoVIxM1KUxh5KcX7lylUzPHogdNx7atutAKeYCdgCzUp9INYKAICAICALh EIEwScjbdu5UXckmZWfniH7OHs+cOUt917RxI7Rt2xp9+vZTaeb4DDJ7TIsIAoKAICAICAIhgUCY ZiBO7eZfHj58iHHjJigy1oS9skUEAUFAEBAEBIGQRCBME3JAwK5d93N+3ZDsAKlbEBAEBAFBQBBg BMIdIUu3CwKCgCAgCAgCtoiAELIt9oroJAgIAoKAIBDuEBBCDnddLg0WBAQBQUAQsEUEhJBtsVdE J0FAEBAEBIFwh4AQcrjrcmmwICAICAKCgC0iIIRsi70iOgkCgoAgIAiEOwTCNSF7eXlhzKhRePvu Hdzd3VWCCTs7BwwePBAJEyYMd4NBGiwICAKCgCAQcgiEc0L+jKFDBsHryzdkz5ED9hStKwIR8ufP XiHXI1KzICAICAKCQLhEIFwTMmd74hSMcaLGwvlz50weABwJTMJtmgyb3CAICAKCgCAQAALhmpDZ RM3pE1+/eoFZs2cjWfIUqFCu7C8HyjVKVsHmbXt7e3h6euLp06c4ffq0DC5BQBAQBKyGAD+7eEGR JUsWBBQi2GqKSEUWRSBcE7KdnT1ldsqAJ89foGuXLvD28UGF8hWxcOECxIwZI0CgeUXs6OioCNmH ruekFPxeRBAQBAQBayGgETKTskjYQSBcE3KUKFFw8MhR1Zs8wMuV/gObNrli3vxi6Na1c4C9nDZt Wv3nvELm1TKndxQRBAQBQUAQEAR+B4FwTcgMnLOzsx6/aNGiq78PHDgQKCEbgs1e2l+/fv0d/OVe QUAQEAQEAUFAIRCuCXndmjU4evw4WrZqDff3bjhGf7OMGjlShocgIAgIAoKAIGBVBMI1IV+6dAmb N2/GE3LM8vr8GanSpEXPOnWRNm1qq3aCVCYICAKCgCAgCIRrQh44eDD4JSIICAKCgCAgCIQ0AuGa kEMafKlfEBAEBAFBQBDQEBBClrEgCAgCgoAgIAjYAAJCyDbQCaKCICAICAKCgCAghCxjQBAQBAQB QUAQsAEEhJBtoBNEBUFAEBAEBAFBQAhZxoAgIAgIAoKAIGADCAgh20AniAqCgCAgCAgCgoAQsowB QUAQEAQEAUHABhAQQraBThAVBAFBQBAQBASBME/IF8+fx+27d1G2bDlEiRLZT49zLuTdu3bBw9MD Xl7e6rsIEexQsWIFRIsWTUaHICAICAKCgCBgNQTCNCEfPLAftWrWxOu3bqhdpz5Wr1yGCJS/WBMP j0+oW7smPnh8hpOTk0r4bWfniLNnT9skIe/btw/r1q1TqSI/fPjgR8ciRYqgfv36Vhs4UpEgIAgI AoKAZREIs4TMpNW6RUtFxiwnT55SRGaYzpsJmIk4frTYuHv3FpwcHfGZkky4uLgYhbK1k4PnyZMH adKkgZubGwYMGIBhw4bp9eTcziKCgCAgCAgCoReBMEvIC+bNxY07d/Q9ExjJEkfjyxcfPHjwALFj xUa8eHF/2Zvv379X+ZKZjH18fPD8+XNs2bLFKiPA3t4eDg4OanXs7e2Na9eu6evlvMySm9kq3SCV CAIhjoBaXNAzqGTJkogc2e9WXIgrJwqYjUCYJOQXRJLTpk9HhkyZESdGdBw+ejRQgJycHPH81Utk ypgR8RMkQudO/6B9+/Y/7TdrBUSNGhVlypRRb93d3XHixAmULl3a7A4w50ZeIW/btg3FihUz53a5 RxAQBEI5AhohOzs7h/KWiPqGCIRJQm7UoD7OnjuPd+4fMWroIEXIvLq0o5ehuLhExu59+2m16aNW ly2bN0WvXj2RPkNGVK9WJcCRYkd70JEiRVLf8SrVkczcESNGtOqo4tU+r5StXa9VGymVCQKCgCAQ zhAIk4T87OlTODg6YdTIYdi2Y4fq0mfPnmDrf9tQiTyoNWGSzpw5i/59sqTJceHSVYwfPyFQQjYc HzxL5Ze15du3byFSr7XbaWv1HTt2DK6urkot7gOenLHwBKlnz54yQbK1DhN9BIFQhkCYJOSde/bS MSYvvHr9GmdPnVJdEjFiJGTJnBkfP34EP1jjJ0gIRwc7cua6h9JlysLT4yPu3rurrh0woF8o60ZR 1xoIpEqVCjXJa//Tp08YMWIEBg0apCwvbK1gS4mIICAICAK/g0CYJOTESZIoTFKlTo106dLh2ImT SEKfJU+eDLdv3aQzyWVRslQ55M2ZFWPGjUOduvXw6YM77j98jAYNG6FggQK/g6ncG0YRiB8/PvjF q+P169ejUKFCYbSl0ixBQBAICQTCJCEbAjlsxEj0H6hbybDs9DVhFyiQD3169UC3Hj3AntNsfmSH rbhxf+1lHRKdJHXaFgIeHh7kmf9F+R1o48q2NBRtBAFBIDQiEOYJmUmWX5osXrIErVq3xbChg9WZ 5Mh0fldIODQOXdFZEBAEBIGwhUCYJ2T/3bVv/wG9l3TY6kppjSAgCAgCgkBoRiDcEbJ2ZCk0dxo7 EGkevqG5HaK7ICAICAKCwA8Ewh0hh7bOf02e4rxnqREwR+d59+6ditb1+PHjn5rDx7DixYsHCRgQ 2npa9BUEBIHwjoAQso2PgLuUqerRo0f6YzXsRMQRwl69eoXzlMmKhb1+NWFCLly4sE0SMrfl0qVL KuQfh/vjI2iaJE+eHDly5LDx3hD1BAFBQBAIPgSEkIMPW4uVzATmP5GF4Xvt75AIUmJKI3llf+PG DZXAgwNs1KtXT98uWdGbgqRcKwgIAmERASFkG+9VjYw10jUkZ2tnm/pdqHLlygV+sbApnqNbiQgC goAgIAjoEBBClpFgdQTY5M6R1LQA+VZXQCoUBAQBQcAGERBC9u2URw8fYP+Bg8ibNz8yZEhng10l KtkKAryPz9YJCQpiKz0ieggCYQMBIWTqxzt3bqMGZXe6dOU6kiZPhSOH9iNp0qTB2sO8lzpx4kRV x5s3bxA9enQVE5mFYyZ37949WOuXwo1D4MWLFyp2teblzv+yMxqv8tlJjUnZcO+e/06UKJFNOtUZ 12K5ShAQBEIKASFkQr5/nz6KjO1o1fPowV0VStMYQubzwOauktKnT68SFLBw/uVOnTohceLE6r1h ogJzzhvbeqIDJycnRXChYQ/8/v376niZhinrzcfQ3r59i4sXL/ohZC37F0d+Eye1kHqkSb2CQOhF INwT8ulTJ+G6aZPqQQeKpfnVPuIvSZb3PvkBzWTCKyU3Nze1UjJVNJMnP+B5ZcyrMD5brD3UeWXG wnWYQspc7sOHD9WxouASjZSeUppLligUftTT01PFdmbhRB6cq9nwOJamC+vH7WSP6zt37tg8KTP5 aiZqboOhk51/73d+z/334MED1f7QMOEIrjEi5VoHAV442PoE3DpIhI1awjUhM7mOGzMGzi5RUL5C RbhuWK/iW/9KfHx8FOHxw5bvZ8Lkc8LmCpMbmz+5TD4O5N/8yZ+ZQsisx8uXL/2QiLm6BXYfTyDY zH7u3Dl1yZYtW1C0aFFldmfJkyeP+lsjaMNytIkMT0AYN1slLc3hjPs4IEI2JGetfdo9PJnidpna b5buJykv7CKgjbWECSmNrKT+DDMdHa4JedCA/li5Zi127dkHu+9fVUo9zgn1q/CavBosWbKkGgBM lgcPHkTx4sV/a0CsXbtWlRk7duyfyjl79izYbMpmXmOEf6j58uXzk1DDmPvMuaZq1arqNp5QDBgw ANGiRTOqGJ7UbN26FSVKlDDq+pC86PTp02qyZAr+BQsWlHjpIdlpUrcgEEoRCNeE/JZWeS4uLlix bIlaVbJ8+/YFi5YsxYB+fYPsUiZkTsP3u8JlcFkBCa8yTV1F8qrOMMPV7+oX1P3e3t7KBG0sIbN5 m9ts68eeWD9z8Q8LMdOD6nf5XhAQBCyLQLgm5FFjx2HgkKGKTJZSWkY2vX4nQi5UoIBlUbZAaUwO bCrmlZq2WtMchzTiYGIMDaKZgE2daFiybWwN4f1/Fp6U8YRI2/OuVq0a4sSJY8nqpCxBQBAQBIJE IFwTMu9z8itBggTIkiWLSspgb++MNGlSBwmctS9g0jhx4gSOHTsGNvmyGXvSpElKDSbkTJkyoUyZ Msq5ypaEI3L5PzbEJm5t711zhDLUmb2U2SkqOIVXvtoeN+NYqVIlxI8fX49ncNYtZQsCgoAgEBAC 4ZqQDQGpVbs2KlWurD4KTg/lgDqBV4yB7VFqjkFshk6TJo2aPDCJ8erY0MzNJlJbXCHfu3fPT3IM 7RwvO4VxcgxDQtY8zAsVKhTshFynTh19V9y8eRPt2rULcA9fHhuCgCAgCFgLASFkX6TZUzE4vRWZ mNg07v/cMtfJ+9cXLlwAe0waeiZrHtj8L5tT2aEssH1a/j4gr2ZrDCQ2pQe2Z+o/cIY19DG1Dp7s 8NnzgJzqTC1LrhcEBAFBwFwEhJDNRc7E+3jPkk3O/lffTFi8UpwzZ44iXG0fk//lVTMfJ2JTOjtB 8WcBne01URWzLudVJJuftWhiWiE8WXjy5IkypfOEwvDYFq9+2TzNk47AkmOE5D6yWUDITYKAICAI BBMCQsjBBGxgxfpPkai918y1/t9bWb1Aq+NjSky6vJdtKEy2nON48eLFavVuOKHg73hCwWZ2S3ij hyQW3C88QWJLgBbUhSdQmgWA28dBREQEAUFAEDAXASFkc5Ez8T4tUIT/YBFaCEn+N6DvTKzG6pfb eg5mSwHCTmYcKpOtHOxUd/36dUyfPl31GWPA+/t8ljyw42uW0kPKEQQEgbCLgBBy2O1bi7bM3AlF WDFJ8wqYvbDz58+vVsj+PdrZW9+aVoDt27crnwQW3gbhiYDmQ8C6yX64RYe/FCYIWAUBIWSrwCyV 2DICbFr3b4pnfbVJCK+AmWyZ5LSjUf7bw2RoTS93Tm7Be/osy5cvR6lSpfS68QpeRBAQBEIfAkLI oa/PRGMzEGATMwcC8e/lzqTLyUJ4f5yTYhju4bMDGyfC4H/5OsOzywGpENCZajNUNeqWhg0b6q9j pzrOFsbnt0UEAUEg9CIghBxCfccOQppzkHYOmc8Ws1OUNVda5jZf019LQcnvbVn/NWvW4OTJkz+t hJlsOUkGBy8xdEpj8mUzNJt/Y8SIYVVztKl9wuZqNl8LIZuKnFwvCNgWAkLIIdQfly9fVsTLTkGc HYgdhpjQNAeh4I5U9bvNvnLlisp2xfo/f/5c/cs626r+rBt7Rfs/L82ErJmseS9W8xJnQmYztua0 9bt4yf2CgCAgCASFQJgkZE86fjJq1EisWbsO3wmBqtVqoE2rFkiZIgVvDOox4WMqTRv/D88pMMeb N28VmdjbO2Hjxg1InTpVUNj91vf88NdiUefKlUuZQzVzqX+z6m9VFEw3s/5adDH/+kvawWACXYoV BASBMI1AmCTkM6dPYdDgIWjRoiWtfhwwasQwrCVyvnHtsp89xC9ffPAfna/18PJWoRN1e4X2tJKK HOydnoImB4F5ILNTTkhF3TK24cmTJw9Sf8OJBU82eCXKK1VuG2PNK1Bt3/VXGa+M1UmuCz0IzJo1 C8+ePVMKa1YIbULaokULJE2aNPQ0RjQVBCyEQJgk5By5coNNqpxwgWXRvDl4+eoV/fVjdcyfMxkw QcSKlxjTpk0zGVJe4Rq7mvVv+gxOT1hjc/ea0uDf1Z/JmJ2POLcwJ8C4e/cu9u/frydk3v/ks7yM S3Dpb0p7tWvNObYVHPr/SvfAvMTNaa+17uF45ewwxyQ8fPhwNGjQAClTplTjgSPTiQgC4RGBMEnI vFeYMUMGFSN65fJlcHCOhD69e9FM3C8h88PA09MDb9+7o9H//ocMGTOjZ/eufkI9+h8UHBiCj5zw Co/3UJlkdu3a9cuxww+ZVzQhMCVWtqFXr7GkwNfxiz2Gtb8tMai5LMbyd/RnQucH8IMHD5RuBQsW VOSsCU9s+MWr5+PHj1tUf64joLCfv8KGdeRVO+/zm4r/4cOHVdHG3mdMH2k5pP2XyZixB/nGjRuR OHHin0Kr8oRTC13KTmsB6cS/A47lbc0gL9r+POvGv1f+PfGL9/CPHDli8xYiY/osOK/RcokXLlw4 wCN7wVm3lB18CIRJQma41q5djb37DmDVimXIlDU7ihcv9tPDiB8GdevVw4tXb3D71i2sI0/c+XPn 4DA9EBInShgg6qlTp1bHYzSC4Qclp24MSk6dOmVSHGr+wWnRu4x9UGrXsTk8atSoFiWEM2fOmKw/ k4W2smZPYLZY5MyZU09Whu3ilTHv6TNhBIf+PJFistcmFZqHu/aedeW/taNNGv6mJMfQ2pMqVSq9 OT6ocWHs9zNnzlQxz/07pfFq/BaN3f/++8+PN7imf8uWLRXuPE5dXV3VJIPbzoTInuUsXEb16tX1 Pg3G6mSJ61gXnijwZIK3QYwd65aoOzSXoRGyta0xoRmz0KB7mCXkOnXrg1+1a9VE9WrVUbRIESxd tgz16v5IuxcpkgsWLl6q76fyZUphx+69GDp0GGZMnxpg/xkmrmfSY9MrJ1UISnilYmpiCHNWufxD ZZNfzJgxg1LJpO9/V39uC682f3WkS9tPZvN1rFixTNIvqIs1D3C+jkmWjwnxtgZPGHj1fPbsWUXI jF/WrFlV9KuAwpkGVQ/fz7G7edVnSeEjWNwG/4TMOvPKkrdPtP15rpfHGreTdeHxyRMexpT/5T5Y unQpmjZtqq7he3nP1tjtF0u2i8vi3xHryLqKCALhGYEwS8hap5YqXQZRyUnr48tXOLD/gB9C9t/x mnewsaZGLQOTMQPImjP/4HAIC0v6M1nxClHzMWAC5r7U2mjO5MNwDARHCE1tReR/bGrvtcmb//fa WGDibtasmV5Nzt7Vtm1bY4ZusF/D/REUZmxhWbJkiX5Cx32kxQ3nVWLjxo2DPYd2sAMhFYR7BMIk Iffp3Rs7d+9GkSJFaanwFc+IjNPT/nCnzv/gwf17aPtXOxQr/gciR3LEkqXL0L1HT7x7+xrbdu6m 1UIk9O3zb7gfGGEZACY3XlVywI+AJCRzS1sDdzZfs/8Dr5ZN8QsILt24L4I6d88TDbYSsM78mjFj hppQMBkbpvcMLh0tUe6bN2/AedFZ2ILCWwbaJJAtWrwdJhK+EQiThFybzNKPnz5VDlt29EPu0KED 2v/dAenSpsWli+fBgfk9PvugXRvd/trRI4fJxPeVjj61R5UqVch8JqazsP6z4AehNVf9YR3PX7WP ceZ9bs6N7f+MOpvJn9JvlbcMeBtB29bRxQSwVyTFJm02q9etW1dfzenTp/Hnn3+GKljv37+PVatW qTbu27eP/FqK6/OLZ8uWTQg5VPVm8CgbJgk5Z85cWLRoUYCIdenchWanUTFk8AAUo1y99erXDx5k pVRBIBgRMAxdyiSnhS61dpILY5rI5uh169bhwoULATql8edsfubkHZrpmtvB++VdunRB+vTp/VTD q3veB+d7glpZG6Ofta7JnTs3+MXSvn17TJgwwVpVSz2hBAGLEvKC+fNw99591fTq1WvQ4Mulh2Hx ooW4dfsOkiRNjjatW6rP+Yc1aeIEOiP8Gs60J5QoURK0b/djX4s9nxdR4ntvby/yDLWjuMJlKavN H78FbfkKFdF/4BAULVr4t8qRmwWBkEKAzbdMYmx65lUkhy5lImMC49UXE5ilncp+t62sV0BWCcPP tb+5Lu1aW7VisNc7H3kMSDiwCZ8UCEy4r/jFpwoCyjL2u1jL/aEXAYsS8qQJ43Hh8lWFBnsvXzh3 Rnl27tqxDU2b/TAvxY0bB5GcHfFPp87KlBUxYiSa7Xqq+2ZQ0veZM2fQ0aLEqFa1Cq5ev6FHd9So UbhEMaCzZM5sNuJdu3Uz+165URCwBQQ0T3rNEY2P4fGKkgmNyZpXy/y3LYUw1TzW/evE71ln/0f8 tGNbxjpYWrtfOC82n6tn4edSrVq1VGAbFkufcLB226S+kEPAooQcI3o0fUueP38BD8/P4MMrkyZM VJ9zYI5v377j6tWr2LB6hSLjrHRGeMOG9Th5/Bj69+9LR1EuYcy4CUifOoUi46jRomPHju2I6OSI Q4ePSBSfkBsrUrMNIcBH2wIjq6DSRNpQM0KtKtp5em7AVgq/W6JECfD5cxFB4HcQsCghcyIHFkcH e3zx+Yzx4yegSaMG2LZjpzI5O9gBPrDHtKlT4faGIlc5OaN1m9YqkQO/Fi9agNt378OBjmh8+apL sv7x4wfMnj0HHcgpq2PHjr/TVrlXEAgzCATH0bYwA46VG8Je37x9ICII/C4CFiVkTRkHByf4fPHE oyfPMHbsGHzjL77T/79HoOxLEeBGoSe9fL4gVuxYaN6iub4NPl+++pLwJzRv3hI7d+zClWvXsHDB fCxauFARc8uWP67/3cbL/YKAICAICAKCgK0gECyE/I2OLLBsct0AZwfd38WLl8C50yfg7eFNDhu6 mNJ82beviq6V2NN+EouHxydkoWANl8m0PYeywixdthQHDx1GK0qh6EEz0Y4d2tsKfqKHICAImIEA O6OxyZ3PIPP+Mb/XZVuLIHGszcBTbgkbCAQLIRctVhzxY0XDslVrQA7SiBkrLrp374bmTRvD/dNn xE+QGG9fPadziW7kwDUT3bp2UeeA3T+4K1R96EgDH6L/+PEjWrVpg3Tp0qLEH6XUdxs3bhJCDhtj T1oRjhHgcKVaYBI+f/zixQt16oJN8ewUFVJhPMNxl+ibzn3AIYE5cImhE552NpyzcnFoWU34FExL OhP+9MVL1KlTD23atFJftf+rDW7cuqPCtAYUFnXunNmYMnUaOSE6q5M0o0aPRflyZczqAt4y4Ohz nBzo+cvX5Ewcm8obhbx58qjy+Dv2aufPkyVLqrzcZ5Pz8JZt29GzZ08UL1ZMX+9LGostyXLrTvzj 5vYOBQoWRq9ePZCSPOfd3N6iAeU/iJ84ORYtmGuWrr+6yaKEzA1m4QhIadLqPA5Z6tVvgMKFCuLl Gzf1/i/KPbxlw1ocPXkaEyZOxDtq5KkTx3Gc3rO0atkCI4cPxdjxE9GwUSN4GezPjBo10uIgSIGC QFhFICBPa21Vyv9aWzRHND6qpT0vmICZlPnFwkeBbO3Y1i8for6xxK2NZXDVx2e8ly9fjhs3bvhJ OMIkxn3TjU6qpKUgS5p8pa1GTm7y5t17vKCoiDVrVgfHo9+7Zw+uEyF/polWQJKYTgcUoRwD0chx 19Pzk0owYq4cpQxrpcuWRdJkyVHqj5JYSFuc1WvUhOv6ddi5bStGjZuIIoUL4tjxU/hv6xakT5cG 7Tt0RNp0GcEe84bCFtrNW/+jo7guaEaLyMWL5mMphW1dQhOLMqVKYMeu3UTIycxV9Zf3WfQXmSNH TnyL4IAkiZOgNYWnPEae06/fvkOGDGlVeLsC+fLA+8s3lfd00dLlmDplMnbt2YvFdNaYI/Gw52Kd OnXRonkzjB87Fhy95tjRo2qWlitXLlSqVAVZs+hyHFtKeJBxFh0+JhI9ekw6w/ljoFmqDilHEAgJ BPh3w6THEbIMz/NyQA1+sRUqoNCZTIbBtULV9ODfdmDHspgQtAAhgU0otGxd1sCVdeb0o4ylf31Y D07HyiEx+biZ1j7t2BZ7w4em4CX+8fR/Djygc+G6jF1RFSFfvnQRW7ftQLMm/1OTKjvainCn1J6c bY0nXJEjRyFSj6Se5xUoJgS/Hj16iNhx4uIjjVOO2JYhfQa4RHbBTZoQfKBVKgdTeUMWlRu0yuX3 fJQ2WtRo9KxOp9RlS8uQIYPV3/90/Addu3ZGfPJPGjVuPP4jXdauXEn1RsX/aHG3jVbEkyZPQSTH CIhCEeDmzJ6JiMQ9hqL1cZZs2ZUFt2zpP1CLVv6LlixF5Yrl4GRP7aV7g0MsSshz5i/0o+OOXXv8 vD924pSf9xMJmMCkC83C+BWcwg+lurVr0mxom6omeoxY+Ouvv9C5U0c5XhWcwEvZwY4APzh5kstE wbm4Na9sftjwuOdwlYcOHVL7toYPWb6Oj/AE91lafoj+SjTzKJ/1ZcLT9OeHP5u22UTJZm7DLF5a eWyhs2SMbq573rx5OHfuXICRxo7SooExDijSWNeuXZExY8Zg729LV2B4NlwrW5tkBFwX+wrRGXhH B3T65x+kpVMzTJwRI0XBccLnn06d0Kv3v1i/bg0uXrpM+QN6YfSoEbTgOoxChYtSnIoWsPvqhQVE ert271Gr3Ab16uDshUsqzGiXTv/AzikS/tegHnpTbvvkKdLg2rXLyufgOy2mrl29QkdkY5C5vLVS L2WqlOrfSC6RVXrPO/efEPE/Up+tWb1SXXvi5ClkyuA3Cpxh27QwrpwWVPEDlRPcgWosSsiWHhTB Xd5XjpbzyZPiy66mGVtO1K9dAyNHDEN9CqfJM9ughGfExq4krBmkwZIPIw2D8Kq/OYEpbAn/wLJA +f9c62f+3NL6c3nmjB/+fXE0LMMJhZbGkz/jHN086TBMa8rkWbJkSYu2gScths5nhs8F/4FNtOeB Rl4B5SvmsrS0l0E9Y0LL92zVSJ4yNRrWq4URI0fRKnQqPn74SNuNn/BHmTJkyn6piLElWT+TkFl5 9eo1ipDt7exVE9kROA/t9zIhT5o0BU8fPyKn3uuUFCgL/mrdikzft1GmXHnazy2IKpUqYc36DZhK +88dOvyt7nemQFMePt76scCTNkXIFL1u0uTJ6NNvIK5eu45UKVNRNMm7iBM7Dl4+e4qHlGyI0/AW KJDfj3newd6OTgO9UbHHe9G+dMrU6VW4ZW2bJbj6JVwTcmQyqeym2ZcmWq5ZZ2enQPFm89+RI0fU zIwHIa80duzY8cv+4WvZ5GXKnp3mbcoPGGNJQXvI8oxd+9sSA4fL4tWItfQ/duyYRfVnDPgBbqr+ vIrjHzYnNzBGNMx55fnr1YQxpfm9xpzxo+U+ZtLQSMtwXAQ0Rhgj1p/FHBINqGU8htk8bg7+mmOR 4QpZS3vK/zKx+c8zHhz68ypdix9u2EbDiY0hnppex48fx4MHD36yQjx8+FAluQnInM1tDWolpqXj 5D1YQwcr00eWZe5gfbzo99KiZSuKW76WVqErwGdmosWMg+t0Wmbyzh147/6RTL1RaB1Nq03K3GUo /Dv7m8zNgwcNxB0iTM7K503l/UkpQ7duXIcbFHb5zKkTKFSokGovm8M/EOErUYd2KOIb/afhqT3L 2ZKSJ18BFVyKk3uUptDL+QsUwnvK7te3/wA8fnAPDx49xkN6JaXokJronu9eKixtt569UalyFSRP lgzPicSDU8I1ITOw96nz2URy7OgRXL/9ABtcN9Eehm5vIiBhpwaeybGwOY0ferwf8ivhzuW9EVOC OWgPdH4oBvXj1OrW4v+yiYxno5YS1p/32U3Vnx9K5uifIUOGn36wv9sWXk3xQ9DY1Z+WotG/SfdX emj4s/6WfkiaM360lZ2x44fbxuSWmULTWtKpiomTszPx+DEFf20VqZlP1bPXN8xmQCZVTX+O5W3s JMqYccV6a/iboj9fmyhRIgoDnMTPhIjx4PHBnzNxGPYPt4t1N3byElz709pk1BAfxiGgCZB2jQd5 ZXN2rj8pTHLvPn0RgZ5dTIj1KUvXJ9omGTZ8BGrVqIbp06b99Czx8dGtaAcMGICOnbti/IQHytkr S+YMWLrwLWFkh9lz5qFsmdL6Y3JffY/M8vFZLy9KNkJ1Xbx0CXkoh8LJU7rt0S+0atZk5rSpuEOB p1LQSv7c2fto+3dH7N+5TRGy/98Ix8SInzAx/iHzu6FoiyNjF0nGjC/Da8I9IfP0ige/E4XmjECh PddTVpp05CGeKVPA+z58LXsQsvCPgX9Y2vtfgc+mNVMejNrDx5yO570bS+8BWlt/boMlxdDhxthy DYnA2Hv4Ot5LtCQhcJnm4m/qKpfHKOtvyQkdl2kO/lp8a1Ow1/T3vwIzpYyArjVVf20Pn1f4vEI2 tFAwIfNknj/nCb5hykluc0Eyy1pyQmRq21kHjsvNzzfDiQHryePQ/2ST2/qWLCCfv0TAJw9P9Pq3 D65cvoSlK1bh6+dPcIgUUanwncImc5AnjjyhxQH/4utL8P697shrsuQpFR7vyBGsbPmK5MhbCU8e PUCbv9qjYYMG2Lx5E57RNsbOPfuwbOlidQ9PfPr264uOnbqgMO1HjxszEnPJnylr9pyUsrM2Pn38 hEGDBmDM2HEYOmwEmpLDWeECBTCUHMHcaaUcNWp0aqejHqZvNPFg4aN5/oV18/76Hc9opXzx4kX1 tR2Z3dnBzNjJ2q/6I9wTcgry+P6TX3SO7taN4liyZBHu0w/l4IEfpuzAANQC+hsz4E0lY2PK/JVe v3N/QPeK/sYjaoolwdhSQzP+WhIMY9v6u9dZGv/f0Z9Xmjyx80/IWppMwxWnZhXTPMx/Fwdz72fS bdKkSaALCP+TPA513KlLVyKqCPrgTu0o1HFUcpKNQmRXuWJ5rFq5gkzGd4mV6dgrOc5y1j+WRGQl 4PfZ6YQOS8XKlSn3wThcv3kbXbrqnHpbt22n9nn3HzxEhLyFPPB9kCBhQn3zWJ8O/3RWaXUPHTlK e8XXVJk9evZCiuTJcOfOHbyl88RtKKZF/Xp1lWWi97//4sSpkxTm2RF16FhuwgQ/fIaikVMg3584 6c9Hm3ibs0vnf+gol48+xa+TcyT06tndIla9cE3Id27fVpG/okePQQfX46u/WYxZ8Zo72OU+QUAQ CP0IGOajZlI1zEdt6EFujFOdoRXMHItYcKBpig8KrwxHjBrjR42ChQqDX5oUK148QDVTkJPVdMrw pwljyStd/9K4aTPw61fyZ4uW4Jd/YTP63Ll+g3i0pVgYbdEuwOI4eIihToYXsRl9HMXHCC4J14R8 7txZMl80oZlcbOTMnoUCk5xC0eIlMXPGjwESXMBLuYKAIBA6EWCyukR7lexxywTy7Nkz5eCpmZ85 aIalfQhCJ1KitakIhGtCrk1BSNiBhfc92Clg1OgxSEWzqSgGYeFMBVSuFwQEgbCPgLbPzmbmhGQ+ NfSMNnW/OeyjJS00FoFwTcgMUsZMmY3FSq4TBAQBQUDtrXJs5sDMy7wHHFTgE4FREAgIgXBPyDIs BAFBQBAwFYGQdrwyVV+5PnQgIIQcOvpJtBQEfgsBXs3xvqaW5pAdcbTzruwBzMdzrOnJ/VuNkZsF gTCKgBByGO1YaZYgoCGgJZngyFBMvmxOvUZHQ1avXq2CLDA5c/xqPu5i6SNDluoFLba1dtZT82zm /VpuE79k1WoptKWckEJACDmkkJd6BQErIsArZI4KxYTLAR/qUvQkTjLBogV/sOUVMuvo5uamQqDy hIJD1vKkQiNkXu1rzlVWhFWqEgQsioAQskXhlMIEAdtDQIuwVKFChQAdkZiI+QiPLRMyr4w5nvph ynvLwhl4OOa5JpzSNWnSpOJMZXvDTzQyAQEhZBPAkksFgdCKAJMt7xOHVuGYyByjPUeOHKoJhgkz +D2bq7UVf2hto+gtCAghyxgQBAQBm0eATe5Mur/aJ7aVKFcBgaltGWjtYBM8BxLhF28j8ITDli0U Nj9AwoiCQshhpCOlGYKAIGCbCOhS+XnjxIkTinz5xfGV9+7dqxzp+HvOGBdQ7mTbbJFoFVwIhElC 5j2z1atXYePGTYhEM9BixUqgQf26fhJQM6Bs4hoyeBDevHXDe8ouogvu7oAxY0YjceJEwYW5lCsI CALhCAEtuQTntNYChhSn2M6cY5mFV8v+czqHI3ikqQYIhElCPkHOHg0aNETefPlwhvKwLpg/HwsX LsLe3TthZ89ps3XCCajHEfl6ffmG/PnzqzOaEYiQJcqO/EYEAUHAUghoTnX169fXO9UxSRuaqD9+ /KhI2dR0mZbSUcqxDQTCJCFzPOoVK1aAfwAXzp9XCauv37zJmb/8iC5YQhTEiRoLx48fN7lH/OcL /VUBTPbW2iNiM5ilJbTrzw86U/E3JeONId62gr+t6M8e0qEZf17B/q7+PPaYdI2R4Bg/xtQr14Q8 AmGSkONTnFkmYxb+ETCZ2EX4sTLWYOcfCa+GP7x8hkmTJiF5ilSoXq3KL3vl8uXLcHd3V2WyI8YT SpbNe0O/En4wsnnKMNm3MV3PM2ZTAzVwXedpEsIPQUs5uXA5bygBubX0v3DhgkX1Z6zfvXtnsv7m xCRmrM6ePauzttDflhJzxg/rz3uXpggTD+vPfW0J/TUnJt4SMmX88H382/Ty8jIp8Tvrf+7cOZvS 39i9YQ1vY8YPP7v4+uzZs6tz5ZYUfu5wfwXkQMd1Ro8e3U+f8DPKdcN6vHf/QNuA7Jym06ZuvXqI GyeOJVUzqSwv0mXhosXK8hCDcjM3aFDvl/cfP3YUFy9dBh8P5CN0mrx4/hz/bdum8ODfU/4CBdUi j+XVq5fYsmUr5XdOhjKlS5mkX0AXh0lCNmzokMED4eXzBd27dSVztd8HJD80s2XPhifPXmDgwIH4 SMdCSv1RCsuXL0esWDEDBJeDK2imJR6cTHxBpVrj67guc8SchyLrqDmLmFOn/3usrT8/YPhlTtsD a6+5K3xzdGDdtXy5lsCfy7D2+LGk/vzANgd/c1f4jL8lxz/r/7srZFPGgTHjRyNkc8ZnULrw8+3K lStqEWE47vhzft7lo63AWLFi6YvxpklTy+bN8O6DB4VjjUZY6Z6zxYqXCFZCXrVyBebNX4C/O/6D qpUr+WnWzp070KdPH5pc6iZnTKSnz57BwP79sMnVFSvXrEFk8i+KESsOJowbgyePH6N06dJImiwV qlar5qesK1cuo3nz5uqzaNGi0UTxC+rUrYfJkybgwb276rsiJUoJIQc1sHp064Ydu/YgU+YsqFe3 FiLQf4bC5uoDh47oPypdshh27NiOWbPnoHevHgEWz8muNeEVMkcPypIlS1CqYNeuXWqGZYo5ih8C pu4p8Q81Xbp0auBYUvbs2WNV/XkWbknZsWOHyY4zWtxnU/Rg/Pm8LB9nsaSYM35Yfy3UpLG68EM3 Q4YMQU4yjS1Pu04L22nsfYwjP0hNTWWo6R8lShRjqzLqup07d5o0fszRXyPZ4Bg/RjXS4CLWhbE0 JHwtRKn/svgaHu/fHSPj/t3biBolcqDV+d8n/9W+OVtIAhu/TLCXKSc1/y5KlSmPcmVKq2v5ecmr +ymTJuL06TOYOGky6tSuiQrlymH82DHIlCE9etLiLH6SFKhasQxGjh6LQgUL4Pb1KyoN7+Ahg5Ag fnw/+jvSOGSp16AxFi2Yg1o1qmLxogXIkTMnalSpqCNqihRnCQmTK2QmykEDB2DMuHHInDU7dmz/ D4kSBew1bTgDjBJFR2InT540Cls2pxlrUvY/uI2qwMyLTDVTGlNNWNDfmHb6v8bUfWe+X0tWb059 gd1jLv7m6h+U1ceUtvGD1RwvYtbdXP1N0S+oa3kibW39LT2hC6qNAZGsfwvFrywWusmEPWJE/7EQ GNS/LzZu+Q9r1q7Hnp3bMGXadFSqXBX5cufAiFGjaYLvQ6dZkuDhgwdkBi6ESZMnwplItVWL5njr /hGxY8Wg7cBTtGKtjuHDhihSffn6Ffg5nTFjJlw8d1qpvWnjBty5dR1t2rRB7ty58Zqu2fLfdqRL n5FO19RDvHjxyPJZEhcvX8Fnynv/6ZMH4sSOrepmGdCvL520eYv5CxcTedcKFKpv376rBdVff7XD 1m074f7ho8kLpqD6IUwS8oH9+zBq9BgkSJSYPKzn0iCJrswvkSK54P07N5o1TSJTdU5EdLTHzt27 0bZtO7i/f4tDvmH5Ro4cERRu8r0gIAgIAoKALwK8On37wR3dunUnq4YjvSIiR67cGDhkmNqTjehk R89gdyLNVti94z9avZ5GyT/KoH///vi7bWvMnTubVrqlcWjPLixYvARduvVAj26dUZHuXbhwIZmk K+LMqZN45fYe69atR8WKFTB29EgcO3mKzMd10bZ1K/1q2p5WySyRyXzOZMyiRXFLnCQp/vyzGbZu 30X7wjvU1th9mhBUqlINzZr8D194e4XuD2gr4Ou3L3j58gVNDoYjRsw4qFi+LG1zGueoZ+xACZOE fPTIUfzxxx+IHTsOli1dqu+M6tVrIkvm9Bg1ahQKFCqGurWqqXi4H2im4+39Gdlz5kLt2nWQOlVK Y/GT6wQBQUAQCPcI6PaXnVChYkW4RIqo9p7Tp0+PTh07YOLkKQqfGTNmIWWKFGoPlqVKlcpqP7pM 2XI4de4CXr2kle3Wreo73tddvHABPZvfk2OfN/bt249YtKp1cImOmjWrq2s0czbXG5Bj23fSSRNt 649XuNNnzcb169dVcJZrVy8jSrQYuHrxPCpVqoTHjx4iXvzEtHX5309+GxfPn0Xfvv3wlbY+129Y h7x5cuPkiR/x1C0xCMIkIQ8eOjRQbJrT7Ijl7/Zt0ahhA3Tu0sUSOEoZgoAgIAiEGQR4K45N9YZb Btq2SUDbCPydAxEjp/G093XqYjAiuUTyxUR37pqv07YJtW0ArTzNIz9GzNgYMXwYbQd+UU5ikYjg 2XdnCjlRfbePSGZnL0QkYtXu4+8N5Zuvm7ehl7i2Qv7ke/SM/STWr1uD+w8fkc5p8OD+PVSrUQtD B/TB0+evQdZp+HfDzZEzD2bPnu2nLks71YVJQv7VryICHX+aN3+hImMRQUAQEAQEAb8IMMnEjBlT 7Y8aOpVqjmoBOVp5UdTDz1/sdIRrp6OyhRSQaTRtHcZPkAhRXZzRrl1bFCpUkI4gxVDfnz5zFg8f PsSZM7q94ChRo6AABWhav2kzLly8jBnTp+DZ0yd48vQ5JRXJro4uRozy4/SLRrKHDh0mc3Njva68 x5wjaxacv3gOXbv3JEtoDcyj/eFYZDFNmSK5qmvViuVkLh+IrmQaT5kiKXib88jhI+qkjaOzX6c0 beIQUMAo7TtjfYmCGmvhjpDn0SAREQQEAUFAEAgYAV7B8skRzevb/1X+T34wgadMlRov3rwjy2N7 8o4nQiYHr+1bNiEukbHrBlfs37MT4ydOwtLlK5A2pe6M75ZNrnhDMSDOnr9A+8yV1NGlmtWq4gMR 6LIli+Hp8QFXr15BXDIhb93sCk6x6RAxqn5/t2Gj/2EbnQ/esmkjWtD+bocOHSkmeE7aN45LTlfb ULtWLfKGXojLF84hWYqUWErbl7np/PDRo0fRh0zPsePEpz3vLsqreuWyZdjoup5M3y74t09fOBhE dGRzeAKKbRE3btyfAHN21n334tkTtKe2s8SNFx/9yFFM28s2ZZyFO0I2BRy5VhAQBASB8IiAKcct nYmwDh45pk6c8CpWmZKJpNkzmlfT7DGeM0c2dV7482cvWp0uVZB26doV7dv9pY7Y8TWa+Xf7zl0U dOmzbkVMZUf1PVJ0is4Uszg7Oal/09Ee9WEiV95j5qNOMWP+OBudiDyoD9LK2ZNW7nzqRjN9830c TIVX547kfOZCMRtYdu7Zq/ek93/CIE++/Lh9+3aAgW2yZc+hvlMBpj58UGU5OOiOX5kjQsjmoCb3 CAKCgCAgCOgR4GBELIGd/+bz5PxisuMcAizM25oXtCGUdmTy5uv8E2NAR8HYoYtfAdXrQJOBqPzy d0Y4oCN9mv4BdSlbDAI7BsjEq32nmeJ/Z1gIIf8OenKvICAICAKCgEkIFCpcVEXR4rPBIn4REEKW ESEICAKCgCBgNQTy5S8Afon8jIAQsowKQUAQEAQEAUHABhAQQraBThAVBAFBQBAQBASBcE3I7A14 +NBBjB03XnnFpU2XAf/27qmcAMzNriNDShAQBAQBQUAQMAeBcE3IH8lNvWL5ckiVNj2defOAK6Xl WrBgIQ4fPoD0lDFJRBAQBAQBQUAQsBYC4ZqQI5Kr/opVa1CufAXC+zvy58mFcxQhxts31mpQncBn 5IxNum5OPtig6g/se1NSPBpbR2jX35r5bG0Ff3PzCVtafy0tnqmZm2xFf/6Nh/bxY+zvXK4LWQTC NSHzg6JylSqqBx5Qxg8+tM7iN2uy3w66cOGCOoTOBMWh2x49eoQjR37kVA6oO/nB8ubNG7Ny05oa ko3rOnPmjJooWCrOKpfz+vVrq+l/9uxZi+rPfcJ5q42dPGl9yIf9TU1lyVidOnVKPcAthT/rY874 MUd/1pv15/FtCf21+MQc5MEU/Pk+xp5/Y/7Pkf7qkcn6cyYhS+qvBbwwVX/Gn/Xn87fGiIa3MeNH i6KVK1cuivWsxYs2pha5xpYRCNeEbNgxc2fPxLWbt1C/YWOk+kW2Jz78zT8w/uF/orinL168QJw4 cYLsYyZ/c3KqmvNQjE7pJvlHas69gTWE2xya9Wf8TV2h+Y/lG2Qn+17A+PMq05L4mzN+fkd/tv5Y Sn8O8m8u/ub4cjD+ltSfCZnJ2NTxw/iZq39Q40cjZHPKN3Ycy3XWR0AImTBfMH8ehg0fSbFN46Hz Px304dQC6o7kyXXByVk8aN/51atXKs1YUMKzfFMJzZwHKv9QU6VKBX4oWVKsqT/HrLVE1BvD9nMk H3PwN2VVxPUx/mnTplWhAC0p5uJvqv6MEesfWGQic9vE5ZmCv2EiA1OIkOvgzECmrKqNaZOp44d1 ZrI0ZSKikWxwjB9j2ijXhDwC4Z6Q51A6rdZt2iBmrFjk1LWB8nPmNbpX2KRmrEnZlIeR0QoEcmFA WUl+t8zwqr8pZKBhzOPC0oRsLv7m6m9JQubxaI7+rLs5+lt6/PMK3xz9tQmaqb+94Bg/puog14cM AuGakB/T/i+TMcvMmbOQOVNGPH36VJkbY1MybBFBQBAQBAQBQcBaCIRrQj548CCqklOXA+2Pnjp5 Avv37VW4p0uXHp06/WOtPpB6BAFBQBAQBAQBhGtCbtioEfglIggIAoKAICAIhDQC4ZqQQxp8qV8Q EAQEAUFAENAQEEKWsSAICAKCgCAgCNgAAkLINtAJooIgIAgIAoKAICCELGNAEBAEBAFBQBCwAQSE kG2gE0QFQUAQEAQEAUFACFnGgCAgCAgCgoAgYAMICCHbQCeICoKAICAICAKCgBCyjAFBQBAQBAQB QcAGEBBCtoFOEBUEAUFAEBAEBIEwTcivXr7A+g2uSJ8hI0oUL/ZTb3MQ+tWrVuHDx4/w9PRUgezt 7OzRpEljxKJkEyKCgCAgCAgCgoC1EAiThMzkOnrUKMyZMwdPKFlE3fqNAiRkT08PtGrxJzy9vygC 5vyldvaOqFixohCytUag1CMICAKCgCCgEAiThHzm9CkMHDQIJYoVU4TMuUwDEibgSJFcECNOdDx9 8lBd8p1eEYwcHE6UlMLYBOGc29hawjlYLS2iv/GI2hL+PMZNFUvrz+WZM35Yd1vQn3NKm6M/424L +pva/3J9yCEQJgk5e46cuHz5Ml48e4L9ZQ7+Mqcqm6k9PD7h8OHDiBc/AdKlTfPL3nhEKRs9PDzU D/TTp094+/Ytbt269ct7+Ef5kczipv6oWTdT87ByXffv36eJRiSzHgaBTVw+fPhgVf05n7A5D7PA OsIc/Bl7Y/Nda/Wyznfv3lUpPG1Bf87la4po+keMGNFi+rMO/FsxZfyzHnwfbyuZMkHg++7duwdL 6s9jwBz9+T7Wnyfuxog2XowZP/xs4OuTJ09udPnG6CDXhCwCYZKQo0aNisyZM+PRg3tBohs9ejQ8 fvYcRYsWRfQYMdGqZSv0798XXEZA8ubNG7x7906tjD9//qzI+fnz50ESspeXl0kPJLVaNzNBO08S WD9LEQKXY0393dzc4O7ubjH9GUtO+m4qHkzIpk6IuC4eI0w+ptb3q0FkDv7m6M868/ixlP6GxGoq HuZOiCytPxOrOeOHf7+mTuj4HmPGj0bISZIkCfIZJxeEHgTCJCFr8POg/ZVEjhwFBw8fxRf6wfGP v0Hd2hg7djRy5MyBRg0bBHhrjhw59J8zIXNOZSbzoOTMmTO4efOmSbNZfigaaxI3bHOePHkCnVAE pWdg3587dw43btywiv65c+dGtGjRzFU1wPtOnjyJO3fumKQ/r8yMXd0Y4p8/f35lobCk8PhhS4wp +pijP/8O8uXLB7ZQWFJOnDihVq7G6s+/Xb6WV7pB/Y4N9WT98+bNi8iRI1tSffD44ZWrKfoz/qbo r3MqtUNwjB+LgiGFBRsCYZqQg0KNB3/SZMn0lyVIkJD+Po958+YHSsiGZTIhG2sS5JmyqSuEoPQP 7HteTQW2wje3TGvrb66egd3HD2pT8TfXQsH4W5qQzcH/d/S3JCGz2dba+FuSkPk3bm39LT1+LP17 kvKCB4EwTcjanpWh2ciNzHHbd+xAsuQp4ORgj0u011yjRi18+uiOK1evKpSHDRsaPGhLqYKAICAI CAKCQCAIhElCvkempTFjx+LlixdImjQpbt28jnbt2qFaterIkjkDGjZsiCLF/kDxwvkxYdIkbNu2 HR6fPsDjsxfat++AnDmyy4ARBAQBQUAQEASsikCYJGR2dOjXrx95ZzqR6TaKckhiL8moUaNh6uSJ CuBKFcuhW9cu6Nu/PzQPYj4exd6xIoKAICAICAKCgLURCJOE7EjOIAkT8n6wTphkNSehXbt2o2ev f9GrZw/1HZ8xZMcLEUFAEBAEBAFBICQRCJOE/CtA9+zbF5J4S92CgCAgCAgCgkCACIQ7QpZxIAgI AoKAICAI2CICQsi22CuikyAgCAgCgkC4Q0AIOdx1uTRYEBAEBAFBwBYREEK2xV4RnQQBQUAQEATC HQJCyOGuy6XBgoAgIAgIAraIgBCyLfaK6CQICAKCgCAQ7hAQQqYu51i7U6dMRvSYcdD8z6bhbhBI gwUBQUAQEARCHoFwTcgc43rpksUYNGgw7lEO4YSJkwshh/yYFA0EAUFAEAiXCIRrQuZwmt26dkM2 Sqn48sVzxIgR3aRBwBHAjE2PyJmGeAJgbH5dLZetloLRmBR0WnYfY1PEmdLY8Ki/lg7P2D7W8A+O 8Kvm4G+q/tp4sLT+nIaQxdTxz/oz9qbm9ra0/hzNzxr6a/1laf1N+Z3LtSGLQLgm5ChRIuPYiZOI 7BIJqVIkNyqZOOdEZSLnhwT/++rVK1z1zRL1q650d3dXYTpNEf6Bvn79WqV4NCbRuUYIV65cQfTo QU8u+CHPOrHJPih5//692fqz7qbqHyNGjKBUUukUjdWf8TeWWLliLptxf/nypYp1bsxESsP/0qVL 4LjoxgiTlTH4mzp+zNGf9eV2sv7Gpu80Rn/GUfvNGIOJhj/j8uzZM9VvxkxIDfU3Np+2Mfrz2P34 8aPJ40fTn8eoMfprhGzM+OFruY8zZcpkLKRyXShAwDSGCAUNMkVFOzt7pEmTWmWF8vH5YtSt/GBh cuKHhKenJ7y9vdX7oKRSpUqoWrWqUT9Mw7L4YWDMj9nwHn6oGqMT63/nzh1kyZIlKPVRsWJFVKlS xWRdglN/zkd969YtZM2aNUj9GXtTHuxagcGpPyc9uXnzplH6V65cmbKVVQt2/LWVuDHjh8f+jRs3 jNK/evXqVsHfVP2vX7+ObNmyBTl+GHtbGj/8TOCJzsmTJ5EvX74g9ZcLQgcC4ZqQDR+6NNk0Sgwf /kwI/KMoWLCgUffa2kX8QA3N+vMKhNsQWvFnsmdSDq36MynwbyC06s+/Rw8Pj1Ct/4YNG2ztsSL6 /AYCQsgEHs+qzRGNkM251xbuEf1DthfYQsETotAqYUF/Y7ZSbLV/+Per7c/bqo6il2kICCETXsr8 8x3KBG2KaGYjU+6xpWtF/5DtDcE/ZPHn2kPzhCgs6B/yI8C2NAjXhMwzzEED+uP5y1dIly4tIrlE Rtu2benvDOjSpVOQPcWOL4ULFw7yOlu9IHLkyKFe/yJFitgqvEHq5eLigtCsP+cRD836szdz0aJF g+wnW72AT1OEZv1tFdeQ1CtcEzL/IHv920fhHzVaNHyjPT32qHVw0B3TCErYezJ27NhBXWaz34d2 /dnJJjTjL/qH7E+DjxSG5vET2vUP2d63zdrDNSHz3rHh8SA7ItiYMWPaZk+JVoKAICAICAJhGoFw TchhumelcYKAICAICAKhCgEh5FDVXaKsICAICAKCQFhFQAg5rPastEsQEAQEAUEgVCEghByqukuU FQQEAUFAEAirCAghh9WelXYJAoKAICAIhCoEhJBDVXeJsoKAICAICAJhFQEh5LDas9IuQUAQEAQE gVCFgBByqOouUVYQEAQEAUEgrCIghBzCPfuFMhadPHUKCRIkRKpUKf1o853SKB4+ckTlqI0UyQV5 8uaBnW8ijIsXzsPtnS5HMadfC4kg88+fP1fp9zjiVMpUqZA4USKl/7lzZ+Hu/kHfFtaRg7AkTJgQ KVPq2njp4gW8dXun9M+bNy84DGBIyaMHD/DoyRPCMT/pY69X48L5c3j3XpfH2j/Gly9dxJu3buq7 PHnyIKSSyn//TmPkcNBjxD/GVy5fwus3b5X+uXPnBofBtLa8fv0K16/fULmyWY/8+Rn/H48kwzHi H+NrlPP7JeUK5+tz5cpFv49IVlP/6NGjcKEwuzlyZPdT5/17d/Hg4SP1e+A8xbFixdJ//+jhA9y9 d199ly5desSLF1f/3VMae7du31bfpU6dhn4nCazWFqnIthAQQg6h/mCyXblyJWbOnImDhw6hZeu/ MGfWdKXNN0p24bp+HWbPno0dO3epz1KkSos7t67jAyVK79unDxbMn4cPnzzUd/UaNMT8uXPpIWG9 h9LNG9dRsuQfeEoJ5FnS0kOmefMW6NWzO/5u1w5Hj5/4Cdm/2nXAtKmT0KVTJ8wn/d0/flLX1K5T DwsXzEfkyC5W7w1+6FenXLd37z9Ay1ZtMWf2DJVLul/fvoTxfHyk9HwsDRr+D4sXLQBPoP7t3RsL SN93vpOOGjVrq++iRIliNf05MYXrhvVqjGzfsfOnMdKPxsh80vGDL8Z16jXAsqWL8f3bV/Tu2QsL Fs6nCZ27uq9qtRpYsngRokWLajX93759g7JlyuDc+QvgXGuU2wX/a9yUMJ9LKTW90Kf3vwrj9x8+ Kp1q1a6L5cuWqIld71691Hh5QxM6loqVq2E5tS169GjBpz8pePzEcYwfNw5r1q5FhkzZcO3KBX19 gwYMIEwXKEJmyZ07L1w3uiJJ4kQYPnSoGu93iJBZslL+ZVdXV6SiyemYUaMwj767cfOW+i5DxozU r65Inz5d8LVFSrZZBISQQ6hrDh8+hIaNGiFZ0mRKA0eD+Nk8+69Ttx6cI0bC1q1b1QqGSZpj126m H/nkKVOQI1debNywFq1aNMeqFcuRJlVqDB062Gqt+UQP+qxZs6nJxMoVK9C3Xz+MnzAJPXt0x3rX jSrPLwuvfgrSyv6l23sULlQQu3Zsw8TJk+mhlBNbNruibetWWLtmFVLTCnvkyOFW01+rqFmTJoqM WXbs2KH+3bp5E6ZMnYpcefJjw7rVaNn8T6xYvhTZ6UGaN3cOTJg0CRkzZ8WF/7ag/V9tsWH9Wgwk 68bYMaOtpv+1a1dRp05dODlHxOYtW5CXVumGY2QSjZHsOXNjk+t6tGnVEmtWrVD6FymUD+MnTkTa 9Jlw/sI2dPy7PTZu3ID+A1Ji4oRxVtN/xbJliozLla+oJjO5smfD0iWLVJKXgvnzqDGSOUt2XNy6 Ce3atsG6tasxImtWlCpZDOPGj0eKlGlwlu7v/E9HNd769O2HqVMmBZv+bm5vUb5sWTiRJcHB3s6P ReQ0WbgGDh4MR2cXPCBry9jRozFl2jR06twVw4cMxMCBA+Dz9Tvu3L2L2TNnYNToMWjfviOmTBqP wYMH0aTPU1maVixbSuUMQdNmzXH82OFga4sUbLsICCGHUN+kTpMG69ath4MdUK1GTUrK/EORF8+e KjN16dJlaRVaUv3NmZlYJozXPTR79+qJZMmSoVu3rti5ew9evHpt1ZbkpEnC9h3bVZ1t2rTGkMED afXC774jfvz4el0W0arBzd0dmYnAGjVqgCIFC+j0763Tv3v3bthGKzxr6886rF29CmcvXNTrGjWq boU1ccIEnY49dTp27dIFu/bsxXPCeMpk3UO/F63S+LseNAHZ8t82vHhpXfxfkGXiK42LP0qVQak/ /vA3Rsb7GyNdsJ0sLYyxpj+vMnX698DGzVtI/1dWHT8+ZGlQo4UGDVsWPD09EC9+QlSsWAE9unT2 HSM6HXmMbN22nUzUb/T6//tvb/Vdr549FCEHt/4uZL2ZNWcOMtDKlbcv+DepyayZOsuW9ptk3ZiQ P376hPnz5hAZf0P3Hr3Uirh3716KkJmEl9AEhP/9u0MnmoikQ0/qkxHDhuHZixdW7QupzHYQEEIO ob5IlCgxatasoVa8/mXwkCHqo+3btigi5v3hwUOHo2f3rjQz1+21FimiS/voQT9oFnv7kOvKgZTC 0svnK8rSCsK/7N+3F94+X9C/f1/1lQPPQJT+urSJHr4mYWvr//HTR0yhVWT8BImQOEE8Wm2d16vu 6KjbR9Yw9vysw9iB9vicHHU4F/VNuxlS+g+hlRTLzh3/BTBGdNnKfmD82Rd7B9Jf+04bPzqTvLXx b9m6De7euYtlZF2JEycOEidJio2bNiFThvTw8dFZV4oW9TtGHGiM6/H3TZv4yUrjx5ksEfXq1cNz mizzeDYUZ1//h0KFCqmPOWOcwpT2t/1/p/lWcFucffuiIFmOWNxp4soTc0eDfXQ/FcmbMI9AyD3F wzy0xjXQcKat3aF+mCS5cudRs+4DRGq9enRDwgQJECNGDPWdRgS8p6YT3oWzvuzauRMrV61W5nSe MPzQB7hz+xZ208qyWIk/aLVfyo9yIa1/i2ZNcZCcoR4+forZ0yYrQvZPSj/rSM9LX7xDWn9tjOTM lZv2tHsZN0Zo28NW9L916xbevXuntjbiEiF/oP34SRMnYRRtW2gOcgFhHNL6e3t7B/oj8/TUTdwi 2Pn+JglvTfTfBfB7/fk76/+OpUbbQEAI2Tb6wY8WGsWmon3hauRwFMnZkfYtJ5M39hn+uatrtYcW e2ayaCZAazZn//59qF2rpnLOWrpsOZmlM/mpfh6Z+B4/eYpSZSogpu9EwttbZ6p0olzULCGl/8nj x1X9q1Ysw+69e9XfL148xaFDh0kn3SpSj7HdD4y9fFdHjr6WipDSX3uup0z58xiJAJ0V4scY0b3n MeLtrVvdOYWw/u1pX/jYyVOYNHkq/mrbGi3+bIbZs2aQ2Tq+OlGgdPRdeRpirK1OnZx0fRRS+BsO dE0nB98Vr73BeNF/5+sj8kNfb/h80fUFr5ZZ7NRvOQL1UeCkb1iv/B32EBBCDuE+1faGHQ2O/XTr 3h0N/9cYjx49UivhK5cvKy0zZEiHb146r9Oe5Ck7Z/ZMjB87Vr1PlTKFVVtym1Y4lSpWgr2jEzkF bUbVqpX91M+6T6N9NJaOHf/Wf5cqdWp6EJ+mvb9ean9tXAjpv/m/7WBz52s6OuPioiMAB3po8v53 ihQpcOjoMdrT60lOODMxbpwvximSI8IXnfm3N3laL16wAOPG6L5LbWX8eYzUb9gIj381Rnr0xNy5 s/VjhHV0ttPtffYmL+alixcS/mN0+vs7chfcg4mdpFhK/lFSbcmUKFEcS2hSxx7uadKkpW+2qzGy YME8P2MkqouOiBn/FcuX6b+zlv76/On6lS6dgEihO8o3eNAgFCqQH5MmTVTvU9J4SZY8hfp76NAh 1MaidMpgiu93KZDE16Fz5MgR5HFeCgvmzYbXl69IS/4lIuETASHkEOr3+/fv0cNyHvj4EMuRQwfQ l47alCpVGuUqVERR2iM+RJ/VqlkLR48cwt8dO9FxorZ4Rw+ym0SG7PX75vVLnDx9mo5MtVXOLdaU ObNmwoNMdBlphXbp0gWcPKlbcfJRqFKl/sD0qZPhTseymjRtjpwG5zWnTJuO1+RctJq8ft3evsbx kyfRrEUr9CFHGGtKFvLY1WQL7ePv3bcfMWPGUl6+E8jD9/HTp3RMaAlevXyBU2fOoHXb9mpi8cH9 PR1RuYH1a9fA/Z0bTtFRmMbUxn79+1hTfZQtXwHFaY/1wKGD5ItQE8eOHvEzRvhc68qVy/H2zSuc IC/g5q3aoFOnjvj48YPSf+OGdahe/R3Onj5Fk78mYD8Aa8qffESOJgU1qtdA/Xp1MHniBMSKHRc1 qlZBoUIFcPXqVawh73se7ydOnEDTP1ugW9fO8CBHqZvXr8OVPOGrVauOC+fOoG6DRuRUOChY1Wez 8iTS8QmNC5YXz56o32vatOSMRZODp08eY9rMWahUuRJePH1CznalMXLEcLIMRafjijcxjszxFWkC 6+72BkWKFqdJ3mjEixsX9+7ewbARo1CpUiV4f/6EfAUKKq9zkfCJgBByCPV7LHr4ly9fXpmkhwwd Rl6mnvSw/IjkyZOrgALbyKv00ePH6jM24Wnm4Bh03+YtW+m840P1Ha/uOAiBtaVJsz/pId9amdd4 P5PPxbKw5ytL567d0Kx5S3pgpfWzr8yk57p5M+7TUaOQ1N8QrwHkINWJ9HVyclbtiB07DrbQcbOH dKZUp2NkwjijuiVqtOjY4LqJ9L+vzoRHIvwzhwD+MWPGJM/jbWRFCXiMbKKjUA8e/DxGokSJinXr XXGP9SfnIx5b3DbDvX9rjKUevXqjOp0u8Pz8WenRoGFD5W2d3Hf8GI4RQ4xdyMlx1dr1uHfvnq/+ kZCR8NcC5gSX7ryK/+OPUvhC3tV//90BX8jc7ObmRpO4mMpsPnXGTHTo1BmfaMLApmse95F8g62M nTARrdr+pb5jR6/UZCWK4ntqYujwkTSh+1NZwtgPI2XKVFY9Dx5ceEm55iEghGwebr99V7To0fVe sAEVFpkeThkyZAiwHn5ABfbdbytmZAGZs2T55ZXx4sWnaEQ/jj8ZXhyRzleHtP6G+iQgZzl+GQqT cGA6OtODNn0gfWMkfBa5LHLkX4wRItrA9Of9+/Tp01tEh98pJN0vdPjVGOG9ZWvrr6K1USSxX8mv dDL3u9/BV+4NfQgIIYe+PhONBQFBQBAQBMIgAkLIYbBTpUmCgCAgCAgCoQ8BIeTQ12eisSAgCAgC gkAYREAIOQx2qjRJEBAEBAFBIPQhIIQc+vpMNBYEBAFBQBAIgwgIIYfBTpUmCQKCgCAgCIQ+BISQ Q1+ficaCgCAgCAgCYRABIeQw2KnSJEFAEBAEBIHQh4AQcujrM9FYEBAEBAFBIAwiIIQcBjtVmiQI CAKCgCAQ+hAQQg59fSYaCwKCgCAgCIRBBISQw2CnSpMEAUFAEBAEQh8CQsihr89EYxMR+EDZqDhz Fss3ytbDGZ2iR49BmamSqs841Z8myZIlp6xDkUEX4Q6lxvPy8lbX830sWQ3SNvpX4/z5c+jQoSPS pc+IeZSHOCDh7FicmnLdho34p3NX1K5Z3cTW/Lj8K2UcavK/Rnj45Ck+U9ak8ZRViNN2misd/26P Q0eOqqxLDo7OKg1g0qQ6jEQEAUEg+BEQQg5+jKWGEEZg5/ZtqF2vvh8tEiVNgdbNm+LSxQtEjq76 74oVK47NlB4yatQoqFqxAq7evO3nvp69/qU8t8MCbNGgAQNw+PBhvHztFmiLOW1g167dwfRetXqt 30KGJwr79+3F05evkSpVasSJE+e3ysuRIyfOnjun2sDyifJZiwgCgoD1EBBCth7WUlMIIaDlaubq lyxZihw5slM+26+0ip2La9dvIH+BQnB7/QI3b9/BwYMHsJ4IulnTxrQq/qo0rlixMkaNGqH+9vH5 8lMrHj9+pPISc35cFl5havL8+XPcpZV2xEiRkStnDso/HAlODvb4TPVzjl1Nzpw+BS9vH5XwPm5c 44k1Ck0caAaA8hUqImOGHykV3755gxs3byJP3rxwpNSBx44dU1UVKFDAT+7jc2fPwMvnKwrkz4fm LVvCwcEOR44eoxVyRJWfV0QQEASsh4AQsvWwlppCCIEIESLoa+a8tFl8czlPmTpF//mWTa6oUq2G ev/q1Wv1LyeeZ4lNK0/tHv9NGDFsKObNm4c79+7rv9LqmzBuLObMnUekfx3OlAO63V/tUKZsGbhQ PuvP7h/Aea15hT502HCsXr1a3Z8te3a0a9ceKZImxrYdO4nIXWhFPhzr1qwic/IxRIseE4MHDfgJ Sa5z5YoVOH7iBBGuHXbt2IYr166jPE0mIjnZY4PrRnVPm7btMI1M5k8ePcTYceMxl0zrnp+9Ubdu XZp0jFamehFBQBAIGQSEkEMGd6k1hBAoXryYItqixUrgv62b9VqcPHlS/3fVqpXV3xo3rVi+FBvW r1Wf7dq1m1aZukT1ly5exKCBA+D15ZtaRZ87exLPnr+Es7Mz7ty+TcQ5EO8+fML0GbNw5MBuTJgw DkuXLafVuY+639PTE5s2uoJX0bPnzMPuHVuxeu16zF+4BIXyZsekyVMRwcEZnTp1wpjRo3Di9DmU LVcxQOS4TtcN67FqjU7PuHHjInasWNj+3xa4RI6CcuXKYffuXZg1czoyZcqIQ/v2YC1ZAqrWqI1q Fcth0ZIltF/uJaviEBqXUq0gwAgIIcs4CFcI/PNPJ6ROnQoJEibSt3vc2DEYMkxnkq5XryHix4ur HLmIktVnufPkRcsWzdXfKVOm0N83e/ZMRcbxEybFViL3Rg3qYfnK1bT/HBWLFi1UZOzo6IQ9RIT7 9u5R9716+QyRnZ3U3/ZkEu7Tb4By7urTuxcOHj6iPrej1W6Llm2wbt16vH3/ATWqVVNkzDJgQL8A +4v15XpZkqdMg727d6Jp40Y4TObnOtSmhfNmIW6s6Hjt5o63b93w9avOHH+Q9qDTEh5btm5FlMiR 6b4dAZYvHwoCgkDwIyCEHPwYSw02hEBL2idlQtZk9MiR6Nm7t3rb9M+WWDh/jvpb86rmv7NlywG+ z7/Y+5rCNRP1t28/zL1MqpqwB3QVIlVnJ2d88vCE65qV6itHJ0fMmz0LXXv0RLRo0eFC5mkWXqlm yZoF0aNFxSPyoD5+4ji4tLTpMyBO7FhBohkvfgJy8kpJTlmf1LW8IueXtuJ3dHLCjNlzEDdBf9yj /e1xY0dj7pxZ2H/gIGJEjx5k+XKBICAIBA8CQsjBg6uUakMIGDp1nT9/nsyyTG8RyEHLW+8xXbBQ EfTq0Q0PHz4kxyZHJEgQ33eVDLx48RzsHc3iRGSWOHFi9XdcIj52fHr96jnGjB0HDz0BfiGTcTwd 6TpHwsRJkxA3TmyqMgIuXriAtSuWqu/ekRPYnOmT8P79e9Rr8D94fnDDXapHW722a/832v3dQd3H bShZshTSpUsXKLJaO318dCZxTfhzw6Nbn8lU7kQOZaNHj8b+vXuxa/cepcMnz8+wJ4czEUFAEAgZ BISQQwZ3qdWKCBiudmvX9j1qZOdIzk525NDkpTQ5fuwIMmfOpFbG+QoUxoljh5UnNsumjRvUiyVr tpxEqmfV3126dMOsGdPx6Olz9OjeTd+il69e4a927XDjxjVMmTYDadOk9v3ODpUqV6E9bPJe/vqN nLsio36Dhhg+cjRmz5ymv5/PKrPUqVcP8+cvwOmzZxE5SjT8UbLEL1H7QueSWTRC1v798bmuXJ5E NPlfA2zZtlNfXtp06ZEsSWLcvnrRij0jVQkCgoAhAkLIMh7CPAKly5bD8ePHVTt59cmrRfZE5oVy BN+jPUzEGnFHjRpNXbuOPJM9aNXI12ur1sjkIKVJJJdIRGo7lHMW36sdE3KhvVg7chybPHU6GjVu SsSuHZWKQObvbOTwdVMdcUpDR5xix4pJ55FrqvvZ9M0vvp+FzdhZMmdUhOxMK+26dWv/1FeaXkzi 7K39F62qNR1XrFxFJnIPOp8cV6369x86oiYZSZIkhTuV1auPm6qPndw4AEiiRInwzdeurZUb5geH NFAQsCEEhJBtqDNEleBBIFbs2MhPL1Mla7bsQd7CBPsryZ9f55FtKDly5vLzPqBr+ILDhw5i4ZJl 6tp69eviC5miHQzOLvPn9nY6E/MhurZnjx4wLCuLv6hiuXPn0debOPEPpzbtw+XLluq9tNnhTEQQ EASsi4AQsnXxltoEAaMRiB07DooWLaq8vMePG8dbyX7EngJ+bNu5G95E1LxKjxJF5xRmruTImRNs up44cRIVEQEpUiQ3tyi5TxAQBMxAQAjZDNDkFkHAGghkz5GDIocdDLQqNjenSq3tT/++RpkyZf79 QqQEQUAQMBsBIWSzoZMbBQFBQBAQBAQByyEghGw5LKUkQUAQEAQEAUHAbASEkM2GTm4UBAQBQUAQ EAQsh4AQsuWwlJIEAUFAEBAEBAGzERBCNhs6uVEQEAQEAUFAELAcAkLIlsNSShIEBAFBQBAQBMxG QAjZbOjkRkFAEBAEBAFBwHIICCFbDkspSRAQBAQBQUAQMBsBIWSzoZMbBQFBQBAQBAQByyHwS0LW guVbrjopSRAQBAQBQUAQCJ8IaLnTA2t9oIRM2V6iSMaX8DlopNWCgCAgCAgClkWAyfjz58+xYsaM 6S8q/Y96AiVkuvG/6dOnu3tQ+jYRQUAQEAQEAUFAEDAfAU5zSrzqPnDgQO93794FWFCghEzm6uVu bm7Lza9e7hQEBAFBQBAQBAQBQwQCI2O+Rpy6ZKwIAoKAICAICAI2gIAQsg10gqggCAgCgoAgIAgI IcsYEAQEAUFAEBAEbAABIWQb6ARRQRAQBAQBQUAQEEKWMSAICAKCgCAgCNgAAv8H5AahAsq+KYAA AAAASUVORK5CYII= --_006_CB68DF4CFBEF4942881AD37AE1A7E8C74B90346104IRVEXCHCCR01c_-- From stephen.botzko@gmail.com Tue May 11 11:22:58 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5916B28C1DA for ; Tue, 11 May 2010 11:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.571 X-Spam-Level: X-Spam-Status: No, score=-0.571 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kxgbFQcxcxD for ; Tue, 11 May 2010 11:22:53 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 3153128C256 for ; Tue, 11 May 2010 11:19:37 -0700 (PDT) Received: by wyb42 with SMTP id 42so320959wyb.31 for ; Tue, 11 May 2010 11:19:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=S44Uq4nVwkjh7lRYsBamntW1NED3r8vO7DjTHebJLFI=; b=FggGgo7bw1u6W9PRkdEQQ34L18eR7FCyrA/hY1S5OaVD/NPCZG3Z6WhS2k9LDICyAV u8uwYISMNYAhB3QQsdJVoZUGfCgHOyqnfXhfkx4h4k123HXVSTeAwJVOvQ2vEs2JYD5M U0h/7/F5UYa1ihuts/itm3gk+pCme/SR7RCm4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IQCjwOHa8qnZC9RXjRBef9LmrMmczhKFteD4hf77jfrJhT8nfamwAqDXBq3Z/RnmsZ 5DCF2DPRoUJP0/LcwFG6A6W3SiJfBQb2rJQnHVYqamvgNi5ignz3795wlDcxEU85NDT+ H6ETv7+KB+zekD2+oOGk5PeP+U89Oe+pvL+zw= MIME-Version: 1.0 Received: by 10.227.134.142 with SMTP id j14mr5632310wbt.18.1273601962837; Tue, 11 May 2010 11:19:22 -0700 (PDT) Received: by 10.216.23.5 with HTTP; Tue, 11 May 2010 11:19:22 -0700 (PDT) In-Reply-To: <1273601174.1684.79.camel@dell-desktop> References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <002c01cae939$5c01f400$1405dc00$@de> <009901caede1$43f366d0$cbda3470$@de> <20100510232234.16632o6l2ecu3wyy@mail.skype.net> <006101caf117$aaf3b2c0$00db1840$@de> <1273595415.1684.33.camel@dell-desktop> <2B114368-93C0-410B-AB66-53CA33E921A8@americafree.tv> <1273601174.1684.79.camel@dell-desktop> Date: Tue, 11 May 2010 14:19:22 -0400 Message-ID: From: stephen botzko To: Ben Schwartz Content-Type: multipart/alternative; boundary=0016368330b29486fd048655904d Cc: codec@ietf.org Subject: Re: [codec] Thresholds and delay. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 18:22:58 -0000 --0016368330b29486fd048655904d Content-Type: text/plain; charset=ISO-8859-1 >>> In the presence of echo, round-trip delay must be kept below 30 ms to ensure that the echo is perceived as sidetone, according to the Springer handbook of speech processing: >>> Though true, I don't think this is a mainstream consideration. VOIP phones that are capable of speakerphone operation all have acoustic echo cancelers, and those cancelers are already tuned to deal with internet delays with other voice codecs. Certainly our phones and videoconferencing systems do not have problems with path delays of this order (hundreds of milliseconds). >From my own experience (not testing) I agree with Brian's claim that 500 ms round trip is acceptable for most conversation. It does depend on what you are doing, and there are certainly tasks where much lower delays are needed. Regards, Stephen Botzko On Tue, May 11, 2010 at 2:06 PM, Ben Schwartz wrote: > On Tue, 2010-05-11 at 12:48 -0400, Marshall Eubanks wrote: > > As a point of order, I object to any graphs without an available paper > > behind them. > > I have located the first paper mentioned by Christian Hoene at > http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=81952 > but of course it's paywalled. > > One test in that paper told trained subjects to "Take turns reading > random numbers aloud as fast as possible", on a pair of handsets with > narrowband uncompressed audio and no echo. Subjects were able to detect > round-trip delays down to 90 ms. Conversational efficiency was impaired > even with round-trip delay of 100 ms. > > Let me emphasize again that these delays are round-trip, not one-way, > there is no echo, and the task, while designed to expose latency, is > probably less demanding than musical performance. > > In the presence of echo, round-trip delay must be kept below 30 ms to > ensure that the echo is perceived as sidetone, according to the Springer > handbook of speech processing: > > ( > http://books.google.com/books?id=Slg10ekZBkAC&lpg=PA83&ots=wc9yM9WrCs&dq=sidetone%20delay%2030%20ms&lr&pg=PA84#v=onepage&q&f=false > ) > > Such low delays are clearly impossible on many paths, but for Boston to > New York City (or London to Paris), ping times can be less than 18 ms, > making echo->sidetone conversion just barely possible for a codec with > 5ms frames. > > I accept Brian Rosen's claim that a slow conversation doesn't normally > suffer greatly from round-trip latencies up to 500 ms, but under some > circumstances much lower latencies are valuable. Let's make sure > they're achievable for those who can use them. > > --Ben > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016368330b29486fd048655904d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
In the presence of echo, round-trip delay must be kept belo= w 30 ms to
ensure that the echo is perceived as sidetone, according to the Springer handbook of speech processing:
>>>
Though true, I don't = think this is a mainstream consideration.=A0

VOIP phones that are c= apable of speakerphone operation all have acoustic echo cancelers, and thos= e cancelers are already tuned to deal with internet delays with other voice= codecs.=A0 Certainly our phones and videoconferencing systems do not have = problems with path delays of this order (hundreds of milliseconds).=A0

From my own experience (not testing) I agree with Brian's claim tha= t 500 ms round trip is acceptable for most conversation.=A0

It does= depend on what you are doing, and there are certainly tasks where much low= er delays are needed.

Regards,
Stephen Botzko



On= Tue, May 11, 2010 at 2:06 PM, Ben Schwartz <bmschwar@fas.harvard.edu> wrote:
On Tue, 2010-05-1= 1 at 12:48 -0400, Marshall Eubanks wrote:
> As a point of order, I object to any graphs without an available paper=
> behind them.

I have located the first paper mentioned by Christian Hoene at
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber= =3D81952
but of course it's paywalled.

One test in that paper told trained subjects to "Take turns reading random numbers aloud as fast as possible", on a pair of handsets with<= br> narrowband uncompressed audio and no echo. =A0Subjects were able to detect<= br> round-trip delays down to 90 ms. =A0Conversational efficiency was impaired<= br> even with round-trip delay of 100 ms.

Let me emphasize again that these delays are round-trip, not one-way,
there is no echo, and the task, while designed to expose latency, is
probably less demanding than musical performance.

In the presence of echo, round-trip delay must be kept below 30 ms to
ensure that the echo is perceived as sidetone, according to the Springer handbook of speech processing:

(http://books.google.c= om/books?id=3DSlg10ekZBkAC&lpg=3DPA83&ots=3Dwc9yM9WrCs&dq=3Dsid= etone%20delay%2030%20ms&lr&pg=3DPA84#v=3Donepage&q&f=3Dfals= e)

Such low delays are clearly impossible on many paths, but for Boston to
New York City (or London to Paris), ping times can be less than 18 ms,
making echo->sidetone conversion just barely possible for a codec with 5ms frames.

I accept Brian Rosen's claim that a slow conversation doesn't norma= lly
suffer greatly from round-trip latencies up to 500 ms, but under some
circumstances much lower latencies are valuable. =A0Let's make sure
they're achievable for those who can use them.

--Ben

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--0016368330b29486fd048655904d-- From hoene@uni-tuebingen.de Tue May 11 11:46:21 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5198828C227 for ; Tue, 11 May 2010 11:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.483 X-Spam-Level: X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuHY+TXs0zvP for ; Tue, 11 May 2010 11:46:12 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 9D3E728C1E5 for ; Tue, 11 May 2010 11:45:56 -0700 (PDT) Received: from hoeneT60 ([178.2.215.148]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4BIjPhA007729 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 May 2010 20:45:31 +0200 From: "Christian Hoene" To: "'Koen Vos'" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> <20100510232234.16632o6l2ecu3wyy@mail.skype.net> <006101caf117$aaf3b2c0$00db1840$@de> In-Reply-To: <006101caf117$aaf3b2c0$00db1840$@de> Date: Tue, 11 May 2010 20:45:24 +0200 Message-ID: <00ac01caf13a$21f741d0$65e5c570$@de> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_00AD_01CAF14A.E58011D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acrw0m8GNXZpDck0Qjy3nWpGN9Rz1gAQeaxwAAio1BA= Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.236; VDF: 7.10.7.90; host: mx05); id=5136-P8aefP Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 18:46:21 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00AD_01CAF14A.E58011D0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00AE_01CAF14A.E58011D0" ------=_NextPart_001_00AE_01CAF14A.E58011D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry, for the lacking description. I added some more information into = the email. =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Christian Hoene Sent: Tuesday, May 11, 2010 4:39 PM To: 'Koen Vos' Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? =20 Hello, =20 may I present some results of the ITU-T SG12 on the perceptual effects = of delay? For many years, it was assumed that 150ms is the boundary for = interactive voice conversations (see Nobuhiko Kitawaki, and Kenzo Itoh: Pure Delay Effects on Speech Quality in Telecommunications, IEEE = J. on Selected Areas in Commun., Vol.9, No.4, pp.586-593, May 1991) Until 400ms quality is still acceptable (about toll quality). The = ITU-T G.107 quality model reflects this opinion. However, in the recent years, new results have shown that the impact of = delay on conversation quality is NOT as strong as assumed. At the ITU-T, numerous contributions have been made on this issue: Contribution of BT =93Comparison of E-Model and subjective test data for = pure-delay conditions=94 from 2007-01-08: Link = http://www.itu.int/md/T05-SG12-C-0030/en The conversational tests were done in controlled environments with nine = pairs of subjects. Two subjects had the common tasks of their set of sorting pictures in the same order. Other conditions: No = echos, G.711, no frame loss =20 Legend: MOS-CQS are subjective conversational tests MOS-CQE is the E-Modell (G.107) MOS-LQO are result from PESQ. The delay is a one-way delay. Beside MOS values, they also studied the = subjective rating of percentage difficultly (%D). Starting at about 150ms is goes up at reaches 35% at 900ms. After that it remains = constant. =20 Also, LM Ericsson described very interesting results in =93Investigation = of the influence of pure delay, packet loss and audio-video synchronization for different conversation tasks=94 from 2007-09-24.=20 = http://www.itu.int/md/T05-SG12-C-0119/en For example: The done conversational tests similar to ITU-T P.805. The = conversation lasted about 3 to 5 minutes. 11 pairs of experts were taken part. =20 The tasks at 160ms were done about 50s faster than the same task at = 600ms =20 And in the second tests about 60 na=EFve subjects and experts were taken = part to solve a conversational task. =20 If they were asked for interactivity the ratings look worse. =20 Overall, it seems that the limit of 150ms is greatly overestimated. A = much relaxed timing is allowed. Seeing these figures, I have to assume that the ITU-T G.107 standard was = a plot of the telcos to make life of VoIP vendors hard. Well done... =20 Hopefully, I will not get trouble because of providing these = information. With best regards, =20 Christian Hoene =20 =20 =20 =20 --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ =20 =20 >-----Original Message----- >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Koen Vos >Sent: Tuesday, May 11, 2010 8:23 AM >To: bens@alum.mit.edu; Benjamin M. Schwartz >Cc: codec@ietf.org >Subject: Re: [codec] #16: Multicast? >=20 >Quoting Benjamin M. Schwartz: >=20 >> Quoting Koen Vos : >>> For typical VoIP applications, Moore's law has lessened the pressure >>> to reduce bitrates, delay and complexity, and has shifted the focus = to >>> fidelity instead. >>=20 >> I think this is a typo, and you mean "lessened the pressure to >> reduce bitrates and complexity, and has shifted the focus to >> fidelity and delay instead". >=20 >Not a typo: codecs have become more wasteful with delay, while >delivering better fidelity. G.718 evolved out of AMR-WB and has more >than twice the delay. Same for G.729.1 versus G.729. This is not by >accident. >=20 >The main rationale for codec delay being less important today is that >faster hardware has reduced end-to-end delay in every step along the >way. As a result, a typical VoIP connection now operates at a flatter >part of the "impairment-vs-delay" curve, meaning that reducing delay >by N ms at a given fidelity gives a smaller improvement to end users >today than it did some years ago. Therefore, the weight on minimizing >delay in the "codec design problem" has gone down, and the optimum >codec operating point has naturally shifted towards higher delay, in >favor of fidelity. >=20 >I've mentioned before that average delay on Internet connections seems >to be 40% to 50% lower now than just 5 years ago, which is just one >contributor to lower end-to-end delay. That doesn't mean high-delay >connections don't exist - they do, for instance over dial-up or 3G. >But in those cases it's still better to use a moderate packet rate >(and bitrate), to minimize congestion risk. >=20 >The confusion may come from the fact that the trade-off between >fidelity and delay changes towards high quality levels: once fidelity >saturates, delay gets priority. Even more so because such high >fidelity enables new, delay-sensitive applications like distributed >music performances. This is reflected in the ultra-low delay >requirements in the requirements document. >=20 >To summarize, the case for using sub-20 ms frame sizes with >medium-fidelity quality is now weaker than ever, because the relative >importance of fidelity has gone up. >=20 >koen. >=20 >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec ------=_NextPart_001_00AE_01CAF14A.E58011D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Sorry, for the lacking = description. I added some more information into the email.

 <= /p>

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Christian Hoene
Sent: Tuesday, May 11, = 2010 4:39 PM
To: 'Koen Vos'
Cc: codec@ietf.org
Subject: Re: [codec] #16: Multicast?

 

Hello,

 

may I present some results of the ITU-T SG12 on the perceptual = effects of delay?

For many years, it was assumed that 150ms is the boundary for interactive voice conversations (see Nobuhiko Kitawaki, and Kenzo Itoh: = Pure Delay Effects on Speech Quality in Telecommunications, IEEE J. on = Selected Areas in Commun., Vol.9, No.4, pp.586-593, May 1991) Until 400ms quality = is still acceptable (about toll quality). The ITU-T G.107 quality model reflects = this opinion.

However, in the recent years, new results have shown that the = impact of delay on conversation quality is NOT as strong as assumed. At the ITU-T, numerous contributions have been made on this = issue:

Contribution of BT “Comparison of E-Model and subjective = test data for pure-delay conditions” from = 2007-01-08:

Link http://www.itu.int/md/T05-SG12-C-0030/en

The conversational tests were done in controlled environments with nine pairs of subjects. = Two subjects had the common tasks of their set of sorting pictures in the = same order. Other conditions: No echos, G.711, no frame = loss

=A0

=

Legend:

MOS-CQS are subjective conversational = tests

MOS-CQE is the E-Modell (G.107)

MOS-LQO are result from PESQ.

The delay is a one-way delay. = Beside MOS values, they also studied the subjective rating of percentage = difficultly (%D). Starting at about 150ms is goes up at reaches 35% at 900ms. After that = it remains constant.

 

Also, LM Ericsson described very interesting results in “Investigation of the influence of pure delay, packet loss and audio-video synchronization for different conversation tasks” from 2007-09-24.

http://www.itu.int/md/T05-SG12-C-0119/en

For example: The done conversational tests similar to ITU-T P.805. The conversation lasted = about 3 to 5 minutes. 11 pairs of experts were taken = part.

 

The tasks at 160ms were done = about 50s faster than the same task at 600ms

 <= /p>

And in the = second tests about 60 na=EFve subjects and experts were taken part to solve a conversational task.

 <= /p>

If they were asked for = interactivity the ratings look worse.

 <= /p>

Overall, it seems that the limit of 150ms is greatly = overestimated. A much relaxed timing is allowed.

Seeing these figures, I have to assume that the ITU-T G.107 = standard was a plot of the telcos to make life of VoIP vendors hard. Well = done...

 <= /p>

Hopefully, I will not get = trouble because of providing these information.

With best regards,

 

 Christian Hoene

 

 

 

 

----------------------------------------------= -----------------

Dr.-Ing. Christian = Hoene

Interactive Communication Systems (ICS), = University of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 = 7071 2970532

http://www.net.uni-tuebingen.de/

 

 

>-----Original Message-----

>From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Koen = Vos

>Sent: Tuesday, May 11, 2010 8:23 AM

>To: bens@alum.mit.edu; Benjamin M. Schwartz

>Cc: codec@ietf.org

>Subject: Re: [codec] #16: Multicast?

> 

>Quoting Benjamin M. Schwartz:

> 

>> Quoting Koen Vos = <koen.vos@skype.net>:

>>> For typical VoIP applications, Moore's law has lessened the = pressure

>>> to reduce bitrates, delay and complexity, and has shifted the focus = to

>>> fidelity instead.

>> 

>> I think this is a typo, and you mean "lessened the pressure = to

>> reduce bitrates and complexity, and has shifted the focus = to

>> fidelity and delay instead".

> 

>Not a typo: codecs have become more wasteful with delay, = while

>delivering better fidelity.  G.718 evolved out of AMR-WB and has = more

>than twice the delay.  Same for G.729.1 versus G.729.  This is not = by

>accident.

> 

>The main rationale for codec delay being less important today is = that

>faster hardware has reduced end-to-end delay in every step along = the

>way.  As a result, a typical VoIP connection now operates at a = flatter

>part of the "impairment-vs-delay" curve, meaning that reducing = delay

>by N ms at a given fidelity gives a smaller improvement to end = users

>today than it did some years ago.  Therefore, the weight on = minimizing

>delay in the "codec design problem" has gone down, and the = optimum

>codec operating point has naturally shifted towards higher delay, = in

>favor of fidelity.

> 

>I've mentioned before that average delay on Internet connections = seems

>to be 40% to 50% lower now than just 5 years ago, which is just = one

>contributor to lower end-to-end delay.  That doesn't mean = high-delay

>connections don't exist - they do, for instance over dial-up or = 3G.

>But in those cases it's still better to use a moderate packet = rate

>(and bitrate), to minimize congestion risk.

> 

>The confusion may come from the fact that the trade-off = between

>fidelity and delay changes towards high quality levels: once = fidelity

>saturates, delay gets priority.  Even more so because such = high

>fidelity enables new, delay-sensitive applications like = distributed

>music performances.  This is reflected in the ultra-low = delay

>requirements in the requirements document.

> 

>To summarize, the case for using sub-20 ms frame sizes = with

>medium-fidelity quality is now weaker than ever, because the = relative

>importance of fidelity has gone up.

> 

>koen.

> 

>__________________________________________= _____

>codec mailing list

>codec@ietf.org

>https://www.ietf.org/mailman/listinfo/code= c

------=_NextPart_001_00AE_01CAF14A.E58011D0-- ------=_NextPart_000_00AD_01CAF14A.E58011D0 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAkMAAAExCAYAAAB/O6bMAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAIR2SURBVHhe 7Z0HfBTVE8dn90oujSRA6L0XQVBRUIoUARVEQLHwt6EUETWUEEIIIYRwhABGQQQbCoIVC4qACiIq TUHpSu8dAqRd2fKf2XAxCSkX0q7M+/zvL7nbfeX79vZ+O2/ejD42Nha4MAEmwASYABNgAkzAWwno vXXgPG4mwASYABNgAkyACRABFkN8HTABJsAEmAATYAJeTYDFkFdPPw+eCTABJsAEmAATYDHE1wAT YAJMgAkwASbg1QRcVgxNnjw5Cmfmf149Ozx4JsAEmAAT8FYCGTjw3lOnTj3vrQDKctwuK4YQQm18 NStLGNwWE2ACTIAJMAEXImBwob54dFdcWQzZPJo8D44JMAEmwASYQP4E0vEjlQGVDQFXFkNlQ4Bb YQJMgAkwASbABLyagAeIIRn2rl0B6/YcB5k0dOXG8OSAByDU16vnlQfPBJgAE2ACTIAJOEnA/cWQ dALeMy8Aa+8n4d56fqBUCAGD6OTo+TAmwASYABNgAkzA6wm4vRhSzx+Diw1uh3HDn4FWgV4/nwyA CTABJsAEmAATKCIBtxdD5w7shiN/fQczxl4Cf9DBvU+/DIM6NufQ2kW8EPhwJsAEmAATYALeSsDt xRBUbAHPDJ0GfZ/tBUGp+yE6YiYYgmbDo60q5pjTDz74AP79919QVVV7iaLnr6V501hpshVFAUEQ tJenFxqrN1zDjnn0lrn1tu+sN423cuXKMHr0aK/63rrTfdjtxVC1Vl3h+VbXkVdsBg10V2Hz7/tR DLXPMQ8dOnSA5s2bw6ZNm2Dr1q3w6quvutM83VRf16xZAydOnIAXXnjhps53t5OmTJkCzz//PNSu TSGqPLtMmjQJxo4dCyEhIZ490OujmzVrFnTr1g1uu+02jx7v999/D2fPnoUhQ4Z49Dgdg6MH1C++ +AKioijGrmeX3bt3Q1JSEowZM8azB+qmo3N7MbTn+/nw45XWEPZkR5wCO1xO94Wa9arcMB1NmzbV 3pMkCdLS0uCuu+5y0ylzvtsXL16E4OBgrxgrUWnWrBl07NgRqlWr5jwkNz2SrufOnTuDn5+fm46g aN1u0aIFtG/fHtq2bVu0E93s6HPnzmkPMN5wf6KpqVixIpBI8IbxksV6+fLlbnZFek933V4MVa5a FfZ8PR9mpeyBQNtFUO/qBg/dXT/fGbRarWC3271ihr1prA6hm5FBEew9v5Cop7F6ixii76zFYvH4 iaXvrM3mPfFmaU7pWvaGQvNqMHBAaVeda7cXQ1VvHwhzImvCl7/8A2pwKxg28CEIdftRuerlwv1i AkyACTABJuB5BDxCNgTWbw/P4IsLE2ACTIAJMAEmwASKSsAjxFBRB83HMwEmwASYABNgAkzAQYDF EF8LTIAJMAEmwASYgFcTYDHk1dPPg2cCTIAJMAEmwARYDPE1wASYABNgAkyACXg1ARZDXj39PHgm wASYABNgAkyAxRBfA0yACTABJsAEmIBXE2Ax5NXTz4NnAkyACTABJsAEWAzxNcAEmAATYAJMgAl4 NQEWQ149/Tx4JsAEmAATYAJMgMUQXwNMgAkwASbABJiAVxNgMeTV08+DZwJMgAkwASbABFgM8TXA BJgAE2ACTIAJeDUBFkNePf08eCbABJgAE2ACTIDFEF8DTIAJMAEmwASYgFcTYDHk1dPPg2cCTIAJ MAEmwARYDPE1wASYABNgAkyACXg1ARZDXj39PHgmwASYABNgAkyAxRBfA0yACTABJsAEmIBXE2Ax 5NXTz4NnAkyACTABJsAE3EYMbV/9Aew33gGPd7sl16zZ4NcP34IVe06DThQAqreGV194Eqr78+Qy ASbABJgAE2ACTKBwAm4hhjIOrYInnhoB9Uctv1EMWY/Cp0vWQa0Xx0Pvhv4gGwMhyKfwgfMRTIAJ MAEmwASYABMgAm4ghlLho/c+h9SgalC3svGGWVPOn4RrDRvBXS3rQdVKflA9NIRnlgkwASbABJgA E2ACThNweTG0b8V82KXeA+P/Z4e9lrQbBnbqnx1waPNP8OF8OwRKNmja60l4tm9nCBDzZuDj4wN6 vcsP2+kJLOhAo9EIBoOhROpyh0poXk0mkzt0tdh99Kaxak9tOLf03fX04m3fWW+6H3vD9evO30+X VgXylf3w7rpLMCpxPBx/42fY5xN4A+uAJj0g7rUe0LVbKxDgNEx8djQsC20Ew+6ukePYQ4cOwbVr 12DPnj1w8uRJ+Ouvv9x53pzq+7///gunTp3yirESkDNnzsC2bdugZs2aTvFx54POnj0LW7duheDg YHcehtN9p+t4165dIAjoF+jBhb6z58+f95rv7IEDB+D06dNeMV66frm4LgGXFkMbP3oDfv77KtSc Nxv++P5vOGhaDGu7tIDurapnEQ2p2wq61XX8WRnq+cqwf+cxgFxiaP369fDPP//A8ePHNTG0bNky 152VEuoZ3WiuXr0KOp2uhGp07Wr2798PK1asgKCgINfuaAn07uDBg7B8+XLw9fUtgdpcvwp6iLFY LLB7927X72wxekhiKDU11eNFnwPRxYsXtfuyN9yPSdA3aNCgGFcHn1qaBFxaDDXrOxwSm52GtDQL HAvxg7N+NaBKUM6b/9+fTYOPTraEWWP6I6c0OJXqAw1b1L6B2fPPP6+9R0/T69atgwkTJpQmV5eo e82aNUAWsZEjR7pEf0q7E+PGjYPIyEioVKlSaTdV7vW/8sorMGfOHK9Z8o2NjYUBAwZAq1atyp19 aXbg+++/1x7YRowYUZrNuEzdR48ehYULF4LZbHaZPpVWR/7++2/44osvSqt6rreYBFxaDIWi1ac7 vqhYdyyB9KCu0KpOMBzY+DVsTa0Dg3veBg3adQffrW/C2Ml/gb+SAZX7DIaBd9bKFws9ddETpjeU tLQ0yMjI8IahZl4jVqu2FOoNYshms2lWP28Yq2Nu6bvr6cXbvrMpKSna99Ybijdcv+48jy4thrKD 7TniNbhHF6y9ValOc7jVVkH7d4X6HSB2UnX4bccxUH0qwJ3t24J3LBy482XHfWcCTIAJMAEm4DoE 3EYMBVWpDQ5PkIq1mkLFbAzF4HrQuUs916HKPWECTIAJMAEmwATchoDbiCG3IcodZQJMgAkwASbA BNyKAIsht5ou7iwTYAJMgAkwASZQ0gRYDJU0Ua6PCTABJsAEmAATcCsCLIbcarq4s0yACTABJsAE mEBJE2AxVNJES6C+pUuXalFZ8yohISHwwgsvlEArXAUTYAJMgAkwASZABFgMueB1MHXqVKBoynkV iitDASQ9PS2BC04Ld4kJMAEmwAQ8lACLIRecWLL+5FcqVsweVMAFO89dYgJMgAkwASbgZgRYDLnZ hHF38ydA1jJvycPmbdcBz6u3zTiPlwmULQEWQ2XLm1srRQKyLEN6enoptuA6Vev1evDz83OdDpVi T2heKa2MuywNq6qqJVulJLo0T+5QKA0I9dXHx8cdust9ZAIlTsA9vqklPmyu0BMJUILLGTNmwAcf fOCJw8sxpkuXLsEff/wBnTt39vixHjhwAN566y2g5LTuUCRJgubNm8OiRYvgvvvuc4cuQ8+ePeHB Bx+EiRMnukV/uZNMoKQJsBgqaaIlUN+VK1fyrYUSG7rLE3IJoHC6ir1798LmzZu14w8dOgQNGzZ0 +lx3O3DLli3w7bffgiiK0KFDBzAYDO42hCL1d86cOZrFjwSRO2Q3f+edd+DUqVMwe/ZstxBD69ev 14Q19fnFF1+EgnwWizRxfDATcCMCLIZccLKGDBkCR48ehYsXL8Lnn3+u9ZCWROhGRSb4v/76C9q2 bVtoz00mExiNxkKP84QD3n77bY0XlXfffdctfjRvlvubb74JtKxB18akSZM0K4SnFhK5X331lTY8 CjkxdOhQaNCggcsOl65Buhap/Pzzz/Drr79Cp06dnO4vLVOV5XdWURSYO3cu2O12OHbsGHzyySfa fYYLE/A2AiyGXHDGx48fr/Vq1apVWWKI/CZq1qypWQImTJig+VC89tpr2k3MZrPlOYrt27fDmTNn YMOGDS44ypLpElnJyDJCAshRFi5cCAMHDtQYkXj0lEJjpSWYJUuWaEOiuadrITo62iN9pWheSQA5 RO6JEyfg/fffhwceeEDj4GqFLHU7d+6EHTt2aF2j7yVZh0jcWK1Wp7r7999/w4ULF8rkO0vXE/k2 ffnll1l9S0pKgieffBKCghxpsZ3qNh/EBNyeAIshF57C0aNHZ/WObqZjxoyBESNGwJ133gm0XDZy 5Eho0aKF9qSclyD6559/gJbcfvzxRxceZfG6Rjf01atXa5YSR0lOToawsDDo1q2bx4mh7D9cNN4V K1Zooqhdu3ZAT/meVK5evQrz58/PMaTExESwWCyac7IrFrLaZS/ffPMNUDgMepBxpuzbtw+uXbtW Jt9Z+u58+umnObpF8c1IgD777LNe46DvzLzwMZ5PgMWQi87xe++9B4cPH76hd127doVBgwZp75NZ e/ny5fDyyy/n6Tfyww8/aP4znmz2Jkfi7FYhBzBiExERAf7+/i46w0XvFl0P5DeTu9AyWWxsbNEr dPEzyEKa27JHwo8Cj0ZGRrpc70lY5LWbkYR6XFycU/0lazBtBBg+fLhTxxfnoD179sC8efNuqIL8 sg4ePKj53d1zzz3Qpk2b4jTD5zIBtyDAYsgFp4ksG451/Nzdox+IAQMGaNtg69atC71799Z+CMlK VKNGjRyHkwnc07eaT5kyRVsKzF1OnjwJ9BlZEjyl0HKYY8ko+5jIwZhStHiS7xA5iS9evPiGqSNx tGDBAujTpw+0atXKZaaWBMy0adPyXA5buXKltuR9//33F9rfsvzOkr8Z3Wvy+u6QtblKlSqa5WjZ smVw++23azvO2Lm60CnkA9yUAIshF5w48glx+B3k7h5ZPKZPnw6TJ0/WPqJlMlrjp+WEvASRCw6v xLpEjPJ6snU0QOZ+TxFDv/32m/ajlF+hJVVaLvSUsmnTJjh37lyewyHhQXPvamJo9+7defaXLEMk iJwRQ2U1f2Q1/vrrr/NtjoTo1q1boV+/frBr1y5ttxlZ48hSREt+tATNhQl4EgEWQy44m3Xq1IGP Pvooz57Rk3GzZs1yfEaC6H//+5/2xPzwww/Dbbfd5oKjKvkukZ/Uhx9+mBV1mv5NzrWhoaFaY56U uoTmnX6gyEmXCjkS03JpQECAx42VBtS3b9+seaS/P/vsM20HZePGjbXxulp8JbLK5fedpf66knCj /pBlmR668gvTUatWLY0zOX+TVYhe5H9IgpysdrTDj3IkkqN1/fr1S/7LzTUygTImwGKojIE70xwJ mqIWEkjPPfecZgm54447gLbne3oKA3Iappej0E4ccvwMDg4uKj6XP562Z2ffok1P6sOGDfPYmFPk r5I9VhT5S9EOQRL+rljIj2nw4MGu2LU8+3Qzlh36XpH1mQr5G5EgJx8uEkNPPPEEVKtWzW3Gzx1l ArkJeJQYktMvw1XJBBUreFaaAloWIGtRYYVuSrRcRstD9KpcuXKWJaGwcz3hc9plRD4QniiGcs8P jfXy5cuaM7E3FAqTQLvLuLgGgZYtW2phA6g4lqPJP/Ghhx7SltIqVKjgGh3lXjABJwl4jhiynYFX Bw+AjK7T4L1Xujs5fNc/jNb2+/fvD08//XSeO4nyGgE9oZL/yKxZs+CRRx5x/UFyD5kAE3BbAnS/ IRFEgpUexijQZGBgoMs5ubstYO54mRDwGDG0ZdksmP/tNnjmPs+JuExOl+QXQk9c5A9EEaUp0KIz hXaZ0bIRRavmwgSYABMoTQIkfuhFOzhpWz7FOCOfJAqcSeFAmjZtCrVr1y7NLnDdTKBYBDxCDGUc +RmW/abCE493gyDRUiwgrnIyBUqkdfjsW+MpOixFon7jjTec6mb79u21oHyUtoHEEd2suDABJsAE SpNAo0aNgF60meHPP//Uwgr89NNPmrM1xTyjgJmUdoQLE3AlAu4vhpSr8P47S+DWJydBhS2TYK1U cPoFCsLn6l9EsgjR8hb5heQuFH+IHKOdsRDR+XTzIX8j2hb70ksveVQsmtxsaOeLtwg+Gqs3+WXQ d9aTAmjm9yNAOQjJAuwJhXY+UrR8epGj9S+//KKFBaHr9q677tKS2NK/XTWaeEnPgTdcvyXNrCzr c3MxpMKW9xPg+5P14LXmfrBy+QW4WuUcXEm3Q7BfzkzelEmaQt1TfiMKyEf5f1y1UOwcunnkV8hC RLFLHE7V9G9HOo7sEXvJXE2h/clCRMHcaPs9bbunreeU3sOT8nYRK0qMSU623iAS6Ifl1Vdf9Zgf zsK+i7///ru29FK9evXCDnXrzw8cOKCl2qH/elIh8U7b+cmyTUv3FECUdqbRfYhyJ1KuOXqQofsV HeNp9yaay9OnT2sWMy6uScDNxZACl+0qVDachXnxcbBr4wE4H/AZ/PxAN+jfLmcuIHoKIVFAgcS2 bdumbUN31XL+/Hlth0ZeheKC0NZ7urlQKgoqPXr00NbkqWS/iXz//fea+CMRRDciOodC7derV09b x/c0QXT27FnNouZsHihXnX9n+kWC3psSapJA6NKlC9x6663O4HHbY2jDBAWbfOqpp9x2DPl1nO5d jsTKZOGmnZ+nTp2CtWvXav+mB7rHH39c2yFJ9zF6ICRh5CmFRCDlfuPimgTcXAzp4P4XzeAIcr/g 1b3we52RNwghQk8CgApZDih9g6sFQct+eXzwwQeaeKEggrkLWY3oiWrNmjVZ1i1ylCarCAXgox9I WkYjE3WTJk20p61bbrklqxq6CTluRGS+9qRC6QNat259Q1oSTxqjYyxk3aOcUY6gi544xuxjIosQ BTZ05e9tScwB5RKkhxZPHyexovRB5GBNwo9SfRw9ehQ+/vhjbQmN7k2uGlPqZueZdtuxGLpZeqV/ npuLoZyAWnYeCP7BBe9YoKcPMsm6ciEhRILIEXXY0VfaUeZI4NirV6+sIdBTMz1Z0X/ffvttLXs5 +ViQ9YD8huiHkyL6UiF/hPDwcC04I910PSkJIz1FkrXLG4pjrN4ihug761gK9uT5JWuIq9+fSpI/ fV/pvtWxY0ftRVZuetB78803gfynKIDszQShLck+llRd3nD9lhSr8qjHo8RQp4GjoFN5UCylNilz Pd0YKVkiOUznl8nasa2VukGxhRyFMmWTIKLltBEjRmhv07G0lERPnpT0lW42dJynR6supSniapkA EygmgewpQSiK9TPPPKPVuHnzZli3bp0WM41iGVGS2OxW7mI2y6czgRwEPEoMedrckoWIHL9JvFDg xaIWyidEUagpRQUFRaNCFiQKo0/ip0OHDrBx40YYMGCAFtSRnsDoyZTapRcXJsAEmEB5ESAfT3od OXJEs3iTpZwsoXQ/I2u3q+8KLi9u3O7NEeBfvJvjVmZnkan4ZoQQdZCWyBxxihxJS+m/8fHxWf3f vn275rBJO5PIAkXiidrs3j0zijdZjhyJT8ts0NwQE2ACTOA6AUozRBs/qNASGlm/aXcs+RmRuwDF L+LCBIpLgMVQcQm6+fmODPfkzEjOi2FhYZrViJ7EqGzatClrmz/lI7r//kx3dW/JieWq00v+Xp4S j8ZVGXO/XI8AiR/yK6IHPdoIQiKJltnIek47Ddmi7Xpz5i49YjHkLjNVyv2kGwktkS1cuBBGjx4N UVFRWou0Xf3YsWPavylukeN9WoJzBDikbOresJ29lKfA6eppRyRlcafdNyRQuTABbyJAD2sUwHDC hAlASaxpd/Ann3wCX331leZTREtrjt3D3sSFx1o8AiyGisfPo86mJTF6siJnbYr3QbGLyKGRXlRo yys5MlKhJTVaXqNCAoqCpVGhre0Uw4gKmbe5lCwB4tyvXz8tmi8F5vvuu++gcePGJdsI18YE3IQA BZ6lF92baMn/t99+05LF0oMaxVcjt4Dcy2gUey0mJgamTZvmFWE43GQqy72bLIbKfQpcqwO01Z4E 0ezZszVzNCWKzas89thjWW+TU7ZDGO3evRvmzJmjfUbRVh1LOWTe5qe14s01cab5ICFEhWKWkDCi 4JrMtnhs+Wz3J0BL/vS6cuWKtrxP9yGyIFG8tSFDhmQNkB7kFi1apIVq+Oijj9x/4DyCEiHAYqhE MHpWJWRqJp8hei1evFjbaVZQoS2v9KLSrFkzbf2eyrfffpsVJZvCBNAWf9oNQlYnCgpJpSTjHFGO I0/N/0MOowMHDtSCa2YvlGKGnN3JsZRD/XvW95BHc3MEgoODNd9GetEy2jfffKOFJXHsrHUkuqbv DEWFbtu27c01xGd5FAEWQx41nSU7mGHDhsG7776rBYCk7axFLY5Aj3Qe5U8jXxda5qGt/RQYkgrF EHHEOKLt//QUlz3uiLNtUt4fSrVCZnIKFeCOJb98TBQr6tFHH4UtW7bkOSzyHyIL0YoVK6Bhw4bu OHTuMxMoFQK0hPbyyy9rfkX0MEaJqykFCJWLFy/CW2+9lbVZpFQ6wJW6DQEWQ24zVeXT0RdeeEGL dXSzgsjRa7LY0It2rc2cOTNrMBRUzeFvtGzZMs1hm9b7+/Tpo4kienXu3LnAwdNNjcTAn3/+qfkN UPyRBx98sHyA5WqVlg8pwWhBhYQh+f6Q9SevQjdxEnsFlb1792pLm+QvwYUJMIGcBCidC1mladOB 40GMjqD72rhx47SHMC7eTYDFkHfPv1OjHzp0aJaFiJa4SnJLd7du3bL6QAKI8veQbwxZpByFEjlS odxUdAwV8muifpBIoGCRJISoUGh/6iPtLCGfp5sp+YmS7HVdvnwZaOnPmVJYBm5aMqQdfPnFSyHL GQk8eqolYZpXoThRtAwwceJETUxSxHHK++Qt6TqcmQc+xrsJ0IMC5X7LXmgH7YwZMzRrNRfvJsBi yLvn3+nRk4WInA5p6Sw6OrpUdjCRwHGkFpk6dWpW32j5i5bZaIv/2LFjtffJR4msP5Rn7Y8//sgx DhIztOT25ZdfQu/evbM+Ix8Bik9SUKElqZ07dxbKhfrpjPWJtr5TAtmSKLRrj4QR5ajLXsgiNGbM GO0tWiYkB1IKgUD5y8iPiJ56SXBlX7Ysif5wHUzAXQjQ0hjFJcqrkEM1LaWx75C7zGbp9JPFUOlw 9chan3vuOS3qK/0o07IUxRoqi0IZrB3F4cy9Z88ebRt/foUsTOTITcfT8hwtt9E2W4fjdn7nkXgh C0xhpbB6Cjv/Zj6nMZCPA+Wrc1jOsgshqpOSXVJ54IEHtP/Srprff/9dS2VAu9BIcJLViCxNFDiT gjdyYQKeTmD58uVw/vz5PFN4ULJYesCg71Z5fK89nb27jI/FkLvMlIv0k4IrkhWCfoTph5QSvpZl cdysaMmMMlu/9NJL+TZP1iTacn7fffdpIqCs+1paXGipjHaRkTB1WIRyt+XgdM899wC9qJCAJCf2 pKQkbVsx+VHUrVtXi9FCMaW4MAFPJUAPcgWlNSKL8c1s3PBUXt44LhZD3jjrxRwzbV0ls/K8efO0 qNWOlB7FrLZIp5O4GTlypGbxGDVqVJ7nkh8A3QQ9sZBJPyIiokhDc0Srvvvuu7XzKCYULatR9F5y QicfIwpUR/PboEGDItXNBzMBVybgWH535T5y38qXAIuh8uXvtq2THww57b7++uvaj2h5WV3IMuRY +nHAJKsI+TcVFh/JbeFjx0mEkm9UcTJ3UzwpetGSIm09pjpp+Y2sRrRFn56UyWqUfZnSnZlx35kA E2AC+RFgMcTXxk0TIJ8TshBNnz4dKOAhOVbTf8u6UEA1+iGnJSNHfjVPFkIlzZfmzGEJSkxM1Kr/ /PPPNZYU+oAsbCSKyLJEwpcdTUt6Brg+JsAEypsAi6HyngE3bz80NFTbmrphwwbNj4gEiZ+fX5mP ipbKqA+UpJF2vnEpHgEK8kiFYrJQnKP169dru/PIWkTBHWkpjUQo7W4jgcSFCTABJuDOBFgMufPs uUjfaanG4aRM+YAoZk55pMUg5262CJXsRUFLjiR4SRw5BNIPP/ygbd8PCwvTxBJZjFq0aKHtLqQd e1yYABNgAu5GgMWQu82YC/eXstWTlYCy3lNU15IMzujMsGnLOQVdpOCDXEqPAO1io0KxnMiBnZyw N2/eDL/++qsW24gsg2Sdo/+S4yoXJsAEmICrE2Ax5Ooz5Gb9ozg35IA7a9YszXLAEZDdbAKL0F2H 2CWrIL0osB0FxiSHbPIfI4thp06dtKU1csKmbfw3W8iviWPA3Cw9Po8JMIHCCLi8GDq+6TOY9elm EA014PkJY6BVpcxs5/8VK/y0YA58s/ccGPT4WY02MO7Fp6GGf2FD589LiwCl2KAdXpQdmrZqU7JE Lp5PgJYp6UWle/fuWkwj2tVH1iPaxk9WOxJNDkdsinPkTDl48KDmr8QRtJ2hxccwASZwMwRcWgyl HV0Dr0Quh6dmTYYqu76AyAlxMC9pMtTzF/4bq+UI3ij/hGZjJ8ODjfzBLpqgoulmUPA5JUmAkqvS ktmUKVNg4MCBTqWuKMn2ua7yJ0C51sg6SIWEEaU6+fnnn2HlypXatUFpQsgfiSKF51eOHz+uBcsj MUU7F7/44guoWrVq+Q+Oe8AEmIBHEXBpMSQYa8HYGdOg0x2NAeqfheiPZsGhSzKKof+6rZw7CSn1 a0HjUBMoKISa4b+5uAaBDh06AL0o4jFt1XY44LpG77gXZUmAhBG9HIEfyfGaMoZTfCNHFHFaYqW4 R3QMLYlRhvFevXrB/v37ta6SbxLlg/v+++9LLN9bWTLgtpgAE3BdAi4thvxqtIRONTCNwPrPYe6s 16BBz0joXCdnl0/8uxOObN4AXwZgkk97BtTu+DAMGdATgvIZGfk5eMtWYPLZcIXcU2QdoAzv9CPm yJlVGl8JmtfyiHNUGmMprE5ahiyPEAaF9cvZz0nsDBkyRDv88uXL2n/JavTZZ59pOdNoHindikMI Oerdtm2b5rj91VdfaelEXLVQyhS61h3Lhs7201W+s872t7jH0Tx7y/24rDeUFHduvO18lxZDjsnw D6kKPR8fBD/+ugHW7u8MvZsEZc1T8C19YfbbD2FQuEb43gWY9MxI+Khqc3ipS+0cc0l5mZKTk4Fu pocOHdKeMj29/P3339qTd3mPlX74GjdurKXvOHDgANASGjnZknWgJAstqdCOJlf+kSyp8dKSEwVE JGuLOxdyriZhR4UCP9LS2bfffquFZ8ivbNmyRbMQUVwrhwAuTBjS9Ub5pwoq5NtEr5stdJ2HhIRo flIUvPKOO+7Q/p2enq5tKnCm7NixAy5cuFDu31ln+loSxxw+fFizAJb3PaokxlJYHTt37izsEP68 HAm4tBiiH0u6wdS7tbP2OvZjd/hyzS4UQ5mZuakE1WgMd6H16PpfUAfj/e3fdwoglxgiEURPmfTF ox/N1atXlyP2smn6n3/+0eLBuMJYaR6bNWsGf/zxByxevBh69Oih7TSjjNElVWgnE2Vmp4CAnl5O nDihiSFPtITRmEjskG9RfuWvv/6CVatWaZZPCrZJIrigQsu1FJCzoEJhAAqLj0ViidKg5BZNFHyS RB2FlaCHLip//vmnlqbm+eef13bSOXOtUwLea9eulfl3lr6LFJqiMMFY0t8ryiRP9+SyvEfRXNE8 k0N/ccRvUVnQd7Z27ZwP6UWtg48vPQIuLYbO/Po2xP2gg7fih4IAl+GKFAzNmuQ0jf/1yRR470gz mBf5OFK6BidSfaBp6xu38DqC8dGPMf2IFDXJZelNQenVTMHxyAr24osvll4jN1EziSF6SqJo1YX9 +BSlevqxmThxovZ07umFbuRkffDU7eaUCoR2ItKyWe5CAujDDz+Exx+n73ymczZd5wUVcsDeu3dv gcc0atRIy8lWUCHBk1+uNrPZDGlpaTecTtZZyvnmTCGBRw9rFN27LMvp06c1x3QSCmVZaKwLFiyA adOmlWWzmoWarNVlWeiel9f1XJZ94LbyJ+DSYqhG2/ugzteR8MLYg1BJvQJVeo2AZ7o1hH9+/QI2 p9SFZx9oB0069oPqO5Pg5Yi/wE+1Qb2BQ2DgHfn7EtCPCJnMvaHQEyyZ6F2tkDCl7dL040E/eGQx KolCT7VkCfMGMUTCjywQ5F/jiYWWv0g0kygi/yBHITGydOnSHDvQaKnwtttuKxADfU6Wj4IKpRwh y2JhhfqTe4n333//hW+++SbPU8lXjixEy5Yty9oJR6Ijr7kr7lJdYX3P63MaM/k3kRikB6iy3K1H QrasrVH0cEgCzJE+6GaY3cw5ZPHj4roEXFoMCRUawkTzm/D37mMgGQLg1lubAWVB0je5AzraAzSq /rXaQlRUAmzbdxJUIx7TOvMYLq5NgG68dFOaP3++Fq24fv36rt1h7l2ZEyBnYtqF+MQTT2j/peUz 8sEpaCt+QZ10+Cbldwwt3dKrsLJr164blrwmTJhQ4Gm0REI/vo5lTeoL+RTl7hP5Q5FDuSNyN6U5 Kc3EuLTESPGb6KGJLBcDBgzQRJ2nRnGnHIYkhKiMHTtWi5geHh5e2JTz515AwKXFkMbfFApt7gjN MRVBVetBDrdR/2pw+x3VvGC6PGuItNOGlgMWLlyo5RRr2rSpZw2QR1NsAmRBIQsRWQ/69OkDjz32 WLHrLG4FZOXJXcjp+6mnnoLly5ff8Fm9evU0/6bsFlCyUpGwI+tt9kKihCzXZOGkQlYlCkFQUGnT po0W6bugUqNGjRt2H9LuPRKWZC13lI0bN2pWIvLXohhQpV3IqldWu6woThXtUMxexo8frwnSghz2 S5sB1+8aBFxfDLkGJ+5FKRGg6NQjRozQntaeffbZMl/HL6VhcbUlSIB+LNu1a4c7Ru8qwVpLtiqy +Hz66acwaNAgLVq2o9D1TZaW3EvB9AM8dOjQGzqR22eIRNORI0cK7CztGqVo7wUVWpLLLm6o3smT J2v+VrkL+VVS+IJnnnmmxHd85m6LfJXIGkYW4tIqtGNx69at+YpK8l0kX6+oqCgtdQwX7yTAYsg7 592lRk07LGjJjHyIaFs8Obd7S+wRl5oIF+4MWUtc0f8tOzKyYpE/E1mIKFI2Xddr1qwpkk9cbj8/ Ek2FOfrS54UFNKWdtCQ6HIWsUnkJIcfnlHiXxOftt99eqlcFbaAgh/jSTOhLvnWFWdfef/99iIyM LHMH8lKFy5UXiQCLoSLh4oNLi0CtWrVg5syZ2k4/2p5MT2uF+XiUVl+4XiZwswTIikWCiIRQSW4O uNn+OM6j+E30chRabiQrVn5O35RomXxqSrtQOAxyLCYBWZqFljZpSdAR4DN7WyQmySm+rHfSleZ4 ue6iE2AxVHRmfEYpEaCnRHLmJFM1CaJXX33VJSJol9JwuVoPJUCWjjlz5rj06KiPn3zyiSbYcvs5 zZgxo0yEEAEiIeRM/KXiwuzatatmraPlv+x+WhTok/yyaEMHF+8mwGLIu+ffJUdPjrJkFXr99de1 m7KnxtJxSfjcKa8hQFasjz76SAtfsGLFCm3cFLtq3LhxHsmABBEJn379+mlhKchSRpYxFkIeOd1F HhSLoSIj4xPKgkDv3r21uDC0HfmVV14B2mbNhQkwgZIlQIKIwhYMHjwYWrdu7bFCyEGNdt2RozsF eXz77bd5B2vJXk5uXRuLIbeePs/uPFmIaB2fdsrQ1vuyDAbn2WR5dEzgPwK0ZEaCyFvKfffdB/Ti wgSyE2AxxNeDSxO4//77NUFEgdEox1OXLl1cur/cOSbABJgAE3A/AiyG3G/OvK7HPXv21ERQUlKS Fg+EgsJxYQJMgAkwASZQUgRYDJUUSa6nVAmQzxA5dpIPEe02I4sRFybABJgAE2ACJUGAxVBJUOQ6 yoQALZfRdnvyIaKcQuRTlL1QFOCKFSuWSV+4ESbABJgAE/AcAiyGPGcuvWIkDgsRBYULCAiAs2fP AiXBpEJ5lRISErKy1rPTtVdcEjxIJsAEmECxCTgthpLMMfVSJH0lSeqxIza2g5QYF9M8VQJfDAgD sdHR24vdE66ACThJgJbJyEIUHR2tRa3OXn7//fesP8nPiHegOQmVD2MCTIAJeDGBQsXQ7t27dau+ /WayxQpDFVGsbvT7q3dC/LrOVhnCkJsfyApMiZvxpa/R8HZExNg1XsySh16GBGg7MC2LFVQ4nUcZ Tgg3xQSYABNwYwKFiqGfVq3qJEnyZEkVQBSEk0ZI6WCXpYky/o1P6EcEUOursnWAXRYr4G6fzWFh YTemQXZjQNx1JsAEmAATYAJMwLMJFCqGJEUeIysKCDrjOdFk6CpItg/taA0S9UYwmvwn6m0pDdNt 0jRVVXpgVPfWiOtXz0bGo2MCTIAJMAEmwAQ8iUChYkhVQcEXgE48HmgwXLNY06sr2p+603pf/V8G STqCFqJpoB0EgifB4bG4NwGDweDeA+DeMwEmwASYQJkQKFQMCYJ6Ef1V0fAjN7BZLJvtslqfNI8o 6g5LKReS7XZhIYkjURXWS1LG7jLpNTfCBJCAminA8y20y6xVq1bMigkwASbABJhAgQQKFUN6H9+p Ors0RLLbKqVbhEr0AyTofMBHL6iSRX/OKkuohAyKKurmRkaGX2beTKCsCFAi14IKJWQ8cOAADBky BAIDA8uqW9wOE2ACTIAJuBmBQsVQcnLyqQA/v0g0DT1tlZR0nc6QbvDxe6dKlZAfz544/o0o6v1F o8+c6MjwL8tt7LYLsGnLPoDAWtChTYNy6wY3XLYEhg0bBr169cpq9PXXX4dBgwZB9erVtXxmTZo0 gR9//BHmzZsHnTt3hnvuuadsO8itMQEmwASYgFsQKFQMxcbGyjiSBHphbKEOFsXe3ZKeXO3w4eQh IBq/gEbd3ogZ3MFWXqOVzu+F2VNnwj8BtcH/xHFY//AoGPdoO2BvkfKakbJrt27dukAvR/nmm2+g e/fuULly5az3nnzySdi1axe8/fbbcPz4cejfvz+YTKay6yS3xASYABNgAi5PoFAxRCNIionxyzCI 79sk6I1eGkFZo1LsAAd+ejY2bkNCTHTEkvIY7YldG+CkTwdYNGM4wKnv4J6n4+HeTl9Bh2rsy10e 81GebdpsNkhJSckhhqg/5Dc0d+5cWLx4MZA1aeLEidCsWbPy7Cq3zQSYABNgAi5EoFAxtHt3jM7q o//SZpN6KYIOvVYFDPkrnaYxoNvQY5IqdVBV4f34hMRrURHh35T12Op1HwFzuwNYUy7Dpu9/g4oN 2kCtCiyEynoe3KE9Ss/Ro0cPWLhwoeZ8PWrUKKhSpYo7dJ37yASYABNgAqVIoFAxtGalqaskWVEI 6cFg9F00KXJchKM/C8zmz5Jl+1GrXTLKdv0rZrN5Q2RkZHIp9veGqjNljwxbVr4HC5dvgca9x0JA AWtkFLWYohd7Q6HlIG8ZK80nbaX38/MrcGpr1KgBU6ZMgd9++w2mT58O999/fw6/I3e5Lmis/v7+ 7tLdYveTxltYxPFiN+ICFXjbd5a+r94SAsMbrl8X+ArddBcKFUO4dywMYy6CIOpP+ehN07K3NCIy 8sxsc3yCXVKicft9N73el/Yxb7jp3tz0iTro/Hg4dH50EIzq9xy82ag5TOrTMEdtCxYsgL1798LJ kyfh1KlTWoJPTy+HDh2Ca9euaTuqvKH88ssvcPnyZahQoUKBw6U0HXQDJutQREQEkK9RamoqNGjQ AK5cuQIKXfAuXtavXw+vvPKK1/g/bdq0Cfbt2wfVqlVz8ZkpXvcOHjyoXYv//vtv8Spyk7MvXbqk 3ZczMjLcpMc3383Tp0/z8vzN4yv1MwsVQ9l6QEaYvNafsr9XcOCXUhjO8b9+gsNKY7j3dnSk1dWG RlUC4MSFG41T/fr105ZINm/eDFu3btV+SDy9/PDDD1pG9+eff97Th6qNj4TMs88+C7Vq1XJqvKIo woQJE+DMmTMwf/58zd+Ils7oCc7Vb84XL17U/J+Cg4OdGqu7H2TH8PbdunWDtm3buvtQCuz/qlWr tAe15557zqPH6Rjc/v374YsvvvCK+/G2bdu0zRxcXJNAoWII4y2+hr8ZD6JvUA2rZJmEw8j6ls4z m1vbZHm8ghJIVGEtPmyX+UxbT/8NM99+H1KixkCVazvhsF9reLL3jYH2aLs1FfrhO3LkCDRq1Mg1 Z6QEe0VPXPQj4g1jJWwVK1aExo0bQ82aNYtEka6NWbNmwbJly2DNmjWaaG7atGmR6ijrg0NCQrQ+ ekv8JNohWL9+fY+/lh1C3lu+sxQrrFKlSh4/r3R/ICsYi6GyvlM6316hYqjXg5b1K1foV0s2qbfd mv5sTEzcBXSgPoNxXJqIoL6Aecr0gs4g6Qy6NzBJ6xXnmy6ZIxs/OA5mm96B95Z/DqIpGIZEx0Kb qujonU8hcSDLFC3A8wvdaAoLTOhJFGheaUfZzRSysIwcORJ++uknTRhRvCISRZhq5maqK/VzijPW Uu9cKTRA46XvrqcXb/vOetP92BuuX3f+fhYqhm65JVb+6fOYgYpBXGSzyw+gESic1sLo5iTTqplg 2IdiaDruJFtRXiCadx8Ks3BHGRcmUFwCJIDolZiYCBTBOj4+HqpWrVrcavl8JsAEmAATcGEChYoh 6ntYbGw6/uexpLiY5lcl6JblGCT6WGNjIt914fFx15jATREIDw+HPXv2aKKIltHGjh17U/XwSUyA CTABJuD6BAoVQ4lxcS0tkhSKWaBoiw2Jop+zhqVYhJiYmI74t06vNwmBgb7bcansmusPm3vIBAon 0LJlSxgzZgysXLkSpk2bpkW37tChQ+En8hFMgAkwASbgVgQKFUOqwTAD18T64D7kAgcmigKu6UO3 HGLJrVBwZ5nAjQQoLtHQoUPh22+/1Xa90C4u2tXkTTF++LpgAkyACXg6gULFEIqgTG9kQURnUnGn qkjbrkOhBE/kXSriy3g9NssZTwfG4/NOAn379oUHHnhAC9i4bt06LT6Rp8e88c6Z5lEzASbgjQQK FUM6UXkNt9e3FEAIFAW1Iu7DCtQZfJINOr9wiyX0YmzsYKs3guMxex8B3EEJcXFxWkC8qKgoLeYN xSXiwgSYABNgAu5NoFAxNDYi6kf0C2oeYlKqpNnFqWgeqiso0iMWe/JTgnBVioubtl2S7EvQZwgw AvW3kZFh59wbCfeeCRRMgOL7zJw5E3788UcgR+tHH30U7rzzTsbGBJgAE2ACbkqgUDFE44rN3E12 FF9P098J8fHD0YOoLa6fDbdJ9s74VmfyGcKIvj3w3yyG3PRi4G47T4ACxT3++OMQFBQEy5cvh08+ +USzGrEvkfMM+UgmwASYgKsQcEoMUWeTkmIC01LE0bIC9XDJ7ClZkRUF/YhEveFfRbJ/henswcdH OegqA+N+MIGyIECJXnv27AkbN26EiRMnwu233w5PP609M3BhAkyACTABNyFQqBhKNJtvs9qtb0qK WBGtP9VQBO3R6Y0/6kXDJAxwfO6RZYvP3rJvn3eEdHaTSeVuli0B8iXq1KmTllZg9erVMGfOHHjw wQddPqVH2VLi1pgAE2ACrkugUDGEPkKTVQXaZ26sFzbi/62XJS3lQT98qZ8PGqT/HMDXYPCBgAC/ uRhn6KjrDpd7xgRKj0CLFi2AXu+//z6888470L9/f2jfvj2QWOLCBJgAE2ACrkugcDGkqr5a91ER ybJyN/6LXjcU3HYPVqv4PX7AYsh155t7VgYEhgwZAikpKdqy2Q8//KBtw/fz8yuDlrkJJsAEmAAT uBkChYshALOiqssKq1zB1PWKklbmWesL6xd/zgTKgwBlk587dy5s3bpVSwDbp08feOSRR8qjK9wm E2ACTIAJFEKgUDEUHhm5nikyASZwcwRoyz0leiVfItyVqTlX169f/+Yq47OYABNgAkygVAgUKoZK pVWulAl4EYG6devC8OHD4eOPP4YlS5bAPffcA127dqVQFF5EgYfKBJgAE3BdAiyGXHduuGceRuCJ J56ACxcugNlshr1798Lzzz/PvkQeNsc8HCbABNyTAIsh95w37rWbEggNDdW23q9duxZGjBgBzz33 nGYl4sIEmAATYALlR4DFUPmx55a9mED37t3htttug48++kgTRq+++iqQUOLCBJgAE2ACZU+AxVDZ M+cWmYBGICQkRNtp9v3338PChQvh1ltvhb59+zIdJsAEmAATKGMCLIbKGDg3xwSyE6CAjCSAKFjj 0qVLteSvlPPs7rvzDOfF8JgAE2ACTKAUCLi8GEo+tAW+3/gvqMYQ6P5QX6ieGQIyW1Hh6J+/wKZ/ T4BdxjjZIfWgb8/OEOJTCrS4SiZQSgQaNmwIkydPhh07dmiCaNu2bdo2fEoEy4UJMAEmwARKl4BL i6H0A2vgqUdGQ+3HX4HQ/R/A69/8AUvmTYFmFbNtSZZPwoKoeDh7xwPQvjYqJV8rYPxHLkzALQnQ Ulnz5s3hvffeg/nz52vBGlu1anXDWEwmE1SsWNEtx8idZgJMgAm4GgGXFkNXLlyCzi/OgvEjHkBu D8Olnk/Csl8PwdR+jf/jeOEonK19F0yMGw1NOGyLq11f3J+bIGA0GuHFF1/Utt+/8cYb0KtXL6hZ sybs27cvq7adO3dqYikgIADTBwpaHjSKes2FCTABJsAEik7ApcVQjbufhPEO1wnrVbiWdg3q+hly jPLCob1wbN/3EPfiJfDX+cD9Q8fAQ23rgJAPiwoVKoCv7w1rbUUn5wZn0I+jN+XEImsJOSV7SiE/ ogULFsCvv/4KzzzzDPzzzz85hvbzzz9n/d27d2+PFkP0nfWGJUP6zvr7+3vKJVzoOIKDg4G+t95Q vOH6ded5dGkxlAVWPgczRr8M/zQbBLM718vB22aqCQ88OAr6DesLISn7ISFxOujCEqFPk5xPyZ99 9hkcPHgQDh8+DEeOHMGks7I7z5tTfd+zZw8kJydrL28ov/32G8THx3uUICKrDzlZ+/jk7wRHxyQk JEClSpU8dpop/MCpU6egTp06HjtGGtju3bvh6tWrcPHiRY8ep2Nw586d0/zjpk+f7vHjPXbsGIfP cOFZdn0xlHEaEsYPgW/lnvDV6+OgSq7fhJq394Hw268TrhwMDaRZsH79XhRDd+XATvmgHEsKGRkZ 0KZNGxeelpLpWnp6umYF84axErHNmzdr/jbVqlUrGYAuUguJHUrpQc7V+ZWWLVt63Lizj5XG3rhx Y21+PbmkpqZqQshbvrNHjx6F48ePe8V4DQaDJnS5uCYB1xZDykWYFf4c7KzyDKyd/CTkZUz9d90S 2JLeCp7uQ+JGglSrH4RWv3GppF27dtoMOJxOH3iA/JA8u9CP6KFDh8AbxkozSdYD2qbuicELaYdZ QaVHjx4ebTXZunUr0BjJwdyTi6IocOLECa/5zpKlnsSQN9yj6CHtyy+/9OTL163H5tJi6M/FMTDt u2uQOCsY1nz5BdhkI7Tteh9UuPYvHEgLgnta1Qd/owyrl8wCe0Y/qGA5A2kt28Gj9zTMd1LIWmK1 Wt160pztPFnAvGWsxMRmswE9WXuiGKKx5VfoiZOWye69914gC+gdd9zh7CXiNsfR+Om76+mFvrMW i8XTh5k1vrS0NO176w3FG65fd55HlxZDFVs+CDMiW4P19H44TDGEwA8a22TwSbsCl65mdr1Wx2ch KbgaLPtxH1zzrQQvvPw00A57LkzAkwjQj0Z+hX5MBgwYALTDbP/+/bBs2TJtOz6l/KhatWqB/kae xIjHwgSYABO4WQIuLYYatHsARmSubuUsNe6F2tneqXJLbwjDFxcm4KkE7rnnHs3q5Sjbt28H8hNy OFaTjwmJH1pmoS345Ig7c+ZMTQxVr14dOnXqBE2bNvVUPDwuJsAEmECxCLi0GCrWyPhkJuBBBF54 4QWgl6NQYtc5c+ZoO82yF1EUNZFEr8cee0wTRVu2bIGPP/4YLly4oAkmckTOK5CjB+HioTABJsAE ikSAxVCRcPHBTMA1CJAv2JUrVwrdTn/LLbcAvcgXhXYprVq1CigEQeXKlbX4LuRf9dRTT7nGoLgX TIAJMIFyIsBiqJzAc7NMoCwJUIiF2rVrw7Bhw7RmKQzByZMnISUlBYYPH64tp/Xs2VNbUqM8aVyY ABNgAt5EgMWQN802j5UJXCfQvn37LBaUyoO2c3/66adaag+9Xq9tYSdx5E0RzPniYAJMwHsJsBjy 3rnnkTMBjQClRKAX+RHR9t+NGzdq8alGjx4NjRo10gId0nZ9TwtmydPPBJgAE3AQYDHE1wITYAJZ BMgSRMEN6SVJkracRrnRKOgh+Sndf//9QDnTqlSpwtSYABNgAh5DgMWQx0wlD4QJlCwBWi7r2LGj 9qKdaJRbaf369dpyGgkiiub+8MMPe1Vi0ZIlzLUxASbgKgRYDLnKTHA/mIALE6BdZ/RyRLdeuXIl UF6pKVOmaBGEBw8erO1sY+drF55E7hoTYAL5EmAxxBcHE2ACRSbw4IMPauecOXNGCwb54YcfwuXL l6FZs2aaAzbFOerSpUuR6+UTmAATYALlQYDFUHlQ5zaZgIcQoK34VKZNm6b9lxJRUuqQP//8Ez75 5BNo3bo13HnnndCkSRMIDAz0kFHzMJgAE/A0AiyGPG1GeTxMoBwJUI40Rzl37pzmeE0+RuSYTbGO evXqpe1ayx05u7AuG41G7XwuTIAJMIHSIMBiqDSocp1MgAlogRz79u2rvWir/t69e+Hbb7+Ft956 S3PKrlmzJtx7771AKUSyF9rF9u+//2p51hzl1KlTWmoRElFBQUFQp04dJswEmAATKDECLIZKDCVX xASYQH4EyLGaXuRrRKlBaDltw4YNsG7dOi3Q43PPPaelCKlQoYImgigoZPbEtFTvu+++q1U/cOBA +OKLLxg2E2ACTKDECLAYKjGUXBETYAKFESArkL+/f1Y+tD179sClS5dg/vz5Wq41Wkaj3Wl2u72w qvhzJsAEmECJEWAxVGIouSImwASKSoB2nVHp3LmzFuTxvffeA/I1ImtRfiX3slpR2+TjmQATYAK5 CbAY4muCCTABlyBAW/IpaawsyzBnzhywWCx59quoztcuMTjuBBNgAi5NgMWQS08Pd44JeB+B5ORk UFU134HTtv1Ro0Zpn4eEhMATTzyRdSxFxeYcat53zfCImUBxCbAYKi5BPp8JMIESJUBCiPyG8itN mzaF8PBw7WMK9PjOO+9kHUrb72kXm6Pcdttt0KlTpxLtH1fGBJiA5xFgMeR5c8ojYgJuTYCWy8jC c/r06TzHQbvN6tatq31G/23btm3WcVevXoXVq1dn/b1lyxZYunRp1t8dOnTQAkBSoe35tL2fCxNg AkzAI8TQvrUfwecbjwLo/KHPc6PgtuoGnlkmwATclAAtfX399dewfPnyrBH88ssv0KhRI028UNDG /ArFIHrsscdyfEzWI0f58ccftVhHVEh0UTBHR6GYR47ca/SeyWRymiClIzl79myex1PIgOeff97p uvhAJsAEyp6A24uhf1bOgiGjl8Ej8WYI/OsdeOq5g7DkwyS4rSoLorK/nLhFJlAyBNq1awf0chRK 90HxhZo3b17kBsjK5CgklBxiiUTSH3/8kfXZ5s2bYfHixVl/kxXJ4X9EaUUKsiJNnToVDh8+nGff qA4WQ0WeNj6BCZQpAbcXQ/rg+jB+wUfQv1sLgEfvgv33D4SvthyF2x5qXKYguTEmwARKj0B6eroW h6gkC4kkimvkKPRvq9Wa9fdXX30F27dv1/4moZTdj4miapPvkqMEBATk27XsYqwk+891MQEmUHIE 3F4MNbpnIDRy8Dj1J+w4nwZP1gzOlxCZxr1la643jZUmnObVYPAOiyDF2sm+xFNytwTXrKms5tbH xycLwOOPP57175SUFDh48GDW3z///LOWiNZRzpw5ky+4gmIm5T7J276z9H31lvuxt9ybXPMOUniv 3F4MZQ3x4nZ4ekQ0+D88Dh6/LTTHyCms/4ULF7T3Tp48qUW8PXLkSOF03PwIckClcXvDWGmqaEs2 LVV4Q/RichSmH+fg4PyFv5tfvjm6T9/ZY8eOQaVKlcplWPRDVqNGjay2Bw0alCN3Gokjxz0mdwfJ opT7O0iWpNxilqxflION6jl69KhWTUEhBooLoiCRVprtZu83jZOWK73hHnX8+PHiThmfX4oEPEIM ZZzYCKNeHQdSpwnw2fh+8J9LZCa5ffv2ZfkCkBgikUCB3Ty9UHLMa9euaS9vKH///bcWwZjyW3l6 2blzp5bCoihOvu7MZOvWrZpIWL9+vcsMI7uYoKjZ+RUSchREMnv56aefclia6LOuXbtq4pbGSfnb 8hIrJPRL4t5F4s7Pzy/PNkgI0T2jLAQRsaH7c24+LjPJJdgR+t25GZ+3EuwCV1UAAbcXQ7bjWyAi PBKqD3oTpj3+3xbb7GPO7oz5+++/azfUqKgoj78wVq5cqWULf+WVVzx+rDTA0aNHQ0REhFcE3aOg gzNnztR+0LyhxMTEwMMPP5xjG70rjfuHH37I1zJUvXp1mDt3bo7ukuN2bofr8+fPw6+//qodR0KI YiZRQMnsyyu0o64kClkWKVZTWlraDdVRe2+99ZbWfmmXAwcOaHGi6Fr29ELBQmmXZEkVs9lcNTIy Mn8VnqshszmmqmSFNyUVdHiBgdHXf2dURHhMUqL57nSLPdwqoYGA0uAIPp/FxkR+TKcnJcbdm2aR X7VJKuXHoQ9VHx/fk1Zr+iuxsbFKUlJSsPVq8t1WFYbKKoh4jKrT+6iCyS86Ojxsd35jxb7XALst 2iIr1TOvd52q8/HZGB0ZkZj9nMTEuI42izrWJslZ7eNxZ2SrZRS2L2P7QdaU5LusMryYo329X2x0 ZNjfRWHt5mJIga/fmgQfbQOY2GkLJM1ZB7LqD/c+8iTcXjdv6wA5SHrDMgpdBN40Vhov5baiJ2pv KI6xeosYou9sfuk5XGG+e/fuDf/++2+eXaHlr9wl9245x/eVhAht0R86dKgmVBYtWpTjfkVWT0p0 6yj0N+1UK2q+tnHjxsG7776bL7q4uDioXbt2qaOlOaVr2RtKSV6/iXEx7SRVXB0z1fx17ORIp+I2 6CUIQEkxECi4O77sdoWik8bIkq2GoqoPZ84Bag5ROIT/+NgcF3O3XYHlGNbrv+2YeKLVhmlyBGM1 POYRKT0t0gZCuKxqYkkrWB+IVqF1nDlpAAqSHbnnNjExYZgi2V+zy0rWk5yqyiDZrA/HxiWEKFJ6 FAodNQ7HqCrwJbafze9FBZkCsur01H5/e0baOJsiRN3QviDcFmdO7B8dGZ65A8KJ4uZiCKDDM9Ph 8+6XITUlDYUQjdgEQb5uPywnpo4PYQJMwFUIvPbaazBgwIA8u+OsYCXn7SpVqmi71hzb+PEJOked JLj27NmT9R6J/5EjR+ZY0rrzzjuhceP/dtOSfxJF4s5eCloCo6XXooorV5kHb+gHCqF7rAqskBSl Igi2ITFTZ6THTp7wcqFj14MCNiDliT+QKqiKJOD1VVGUoDIKDs0olJkERzj/YVJMBVkVVsqKGgyC 7rTRYPjBZrMs0ovQHYOejlcE+8Bp5oRNOlmqKymqIIiGi6piv8/XqIu12eWHcCm3gaiTKOBXDjGE 7YUIihyOlh4/EPW4dVMfZRJtl7D5RXaJOiEP9fML+Q3b/1VQhdVYN45Rdwbb/wnbfxfb74LtRyqK +vC0+IQtOkWueb39ZGy/B7Y/EdsfKMtSHVE0DMb2vUUMiVC7WTt8FXoZ8AFMgAkwgVIjQMtanTt3 Lnb95A9UkE8QbefPvqWfGqRt/tkLLdlRcMnsZcWKFTn+piWbgkpgYGCxx8IVlDwBFELtUQh9iRab TGsNmk5AsY6KmTpdHzt54otOtSiIaPxR0QaktgfR92kQpaGKrNDf18UQ6C5mGIcoii0YRQ4IJt/x URFjHWHcNyTET+2VbpPvUiUFz9dhk3iuKPr4BIX6t4ALj+9JEUfLEsoRSf0td3+MevifJUPGtV4B DEbTtkmR4bPpmNnm+HQcyS2SJC9OT08+cV4xouCxVRRE3P1tMkXhct6i63VtSJg+tWeGVe6oKPKd OtxVi7Yoat+I7Qd1Cb3w5PrD4hgZFZIkq5uc4nH9IDahFIUWH8sEmAATcDECuTcMPPLII0Cv7GXd unU5/t60Kf/fCUp38uWXX+bYudeyZUto0KCBi43cu7qTEBvTBxeIlqEBJadS1QSRbURM7DQTKLqx sbGR/4VczwsROsjrMQwJLi3h0pQ9XQ9Yo2gEUbWDQqYhEXxQFvWnf4s6/IMsStmKqDOoIgoQGds1 6HTHdKK9rixZA61XLv26TRV3iXrjEjx8UWx0+KXczRtASsugJMwoyLD1aMfnYyOjPsN/00srieb4 JzPb14FRNORsnwQatq9g+4JOdxzbr4Pt+2P761Yna+0vwyrex/Yzt5A7WVgMOQmKD2MCTIAJuCuB bt265ej6smX0e5F3ITG0f/9+oNQmjrJt2zbIy/eJPm/Tpg107949z8qojoJ2PJbFjjXqWEEWN1oS pPhOrl5QEdRDHZGPyY4EhtoSx0B+OAWLITyARIaCfniCaB8sSUINvQF9qmU7GXm0gmIo+3ZrMr9k FWrJ8Ydq8p3kI1su2RVhkkSWIoDWimRJRJUSFRNn7hMS6HvCkpoyNsOe6Rem1wm3on+SVgP6ip3M j3mu9gXcQEF90KMvkQ1PvZ7FGW1ZJt8p2P5pbD8K278Hj2mF7Zux/ciYuITHQEpfQ/5Hzsyt618B zoyCj2ECTIAJMAGnCRTkzEtiiHbbZnfUpqCTJJDyKnv37oUpU6bk+Rn5QOW3A44S5lLsprIIRrhk yRKgHYl5FYoZlZiYYxOT0xzL8sDImNh5CXExFpsMC3FH2H8ChZx9RP0GkAP6xsaGORFHRUDNo8fJ tIWqgtwZF5nAIKh7sJaGOB5MyCeiShK24t/tVbS+oG9Sag4xpOICGL6hbR1LT2+fbtMvDTHpH82Q LLKkh1BBhiV2VW6DtX6KIhSd3oSs7czahjU8j5bkDAZfcogbSHXjrrWWV9OVunjtrUXxgr5Ewp94 XDNqX1HEkyEmaJ9mFz+PnTp9lVGQAkiz0QIdKnRq/wNs/wlsX8L2K2L7i7H9O0RB+c4YEEpZmfPO k5Nr8lgMleXVzG0xASbABFyAAFls8ksTQo7cFGcouxgiH6Lbb789z57T+0899VSen1FgUPJhyqtQ GAESUhQfLPcu0Lp168JDDz2U53nUF0fOOGdRUiqX/IIeFhQ93Nn6y+q4iOjYd3G5jJp7R1MkmhAy /gyGio/ETh7hhBDKPMcmq2/7COrDNrvUERfNQJFhtk5VY/Gz2qg+rFVEu/mETnjFjtYiW5oaHh+f WEMUpa/RxDbDapeaamJIp7uqSpaX8J8vJVvF7wBCBoXok3VpqmCh3UwoeAJtiu4vPOd///HBLf06 YaZVVmrYbdZuaL25z6RXLqGAWY1WwlBBZ9yakDB7sg/YJth0wv/ssgSWjKtjQNVHom/TNVWxPo97 2TQ5pdPrTqqyZRj+MQzbX4PtP4LtQ/r19smhCu1ROaxaBc0Ti6Gyuoq5HSbABJiAixAgSwglv82r kDN4SQUuJatQQbGRvvsOf0Ox5I6FRtHG582bl2f/KP5Rftv+q1ateoO/FFVSUOoad0trExGjCSI0 6AjvS4JhM1SoOSA27JkrTlxaZJTRfvP1oj5Apwh+tEwpiALuHtQHoE+133UP6oqHLXDepFeH4Vb8 t9EV+R67Pe0ePPZ1vDYMJHNQCe3ViaaeIkjTZUV6WlbtfbQcABbQowjSkeOzKOrmRoaHbcTm6JVV Zs2c0UaxWMeh0ArGxbIfrLQNXPufgEMSkxXF/4+wyLGXcWv9EOzae9j+/SiAOgkK+GWtd6HPkU01 RPgKUnudIL2M7WOSweRL2D6eouoFdOwWBXGOlHrBKauQxsQJgHwIE2ACTIAJeBAB2u7v7Jb/0hw2 CSVKsZJbMNHf+fkh0ZJd7t1xjj5SROsXX7xxU9WuXbtKcxhlXjcKokXmuLjjkl7c4aQQAszaaMf1 J4ohhEoFLqFYOCZIciVyZtbrlStoHaLke7gkplykgIr473cS4uMMkqyMt8mK5rOD2slm8PE5iRU9 GhkZdiYpMXEGmpX+QUvPcNQ0lPwBIw7p7Li5K17v77M6LzApqenj/Xx81gpgj0ELVW3SY+S8pDP4 /C7bMoZERo/QsiVHR8cuSjDH6tG1KQpjEhlRCCWjRUhBFy8TGn2qqlLGUtUYMNpXvToyQ1Yicrav m6H3N62KjpqQw/m6oIliMVTmlzE3yASYABNgAkTgZtKL0DLZ4MEUQibvQpG8cxcKMEnZBzypREZH ry3KeNBqQg7LzWkrumS5Ro5AC/Bv3JhlRdcbfBMAMw+jdpAsWQIiIip6/tKYmHf+8xZDNWTJkKZO naoZacLCw/fhf/ahP9asrL6g73VMdAR6Y+ddYuncqKjVzWNifhh03fWHQgRMjppwwzkRkTHvYPsf ZG8/KMhUNT1VHoN74FB82beER8dswvb/iyCqtT853/bz6xeLoaJcTXwsE2ACTIAJuDQBctrOXbLv jHPpzpdi567vqipIJORpRRkcG5vjHBRCN/QS6y6y+NiH1qfYrP1r+Q88d/t4JIm6MdnPuJn2c7fI YqgULz6umgkwASbABMqfQEFperwlhU/5z4Jr94DFkGvPD/eOCTABJsAEikmAAkbee++9edZCcZK4 MAEWQ3wNMAEmwASYgEcToLxx+eWO8+iB8+CcJsBiyGlUfCATYAJMgAkwASbgiQRYDHnirPKYmAAT YAJMgAkwAacJsBhyGhUfyASYABNgAkyACXgiARZDnjirPCYmwASYABNgAtkImM0x1TGkEObtwrRe GGXcYPLbPmnC+HFJiebO6Rb7FKuWOAyjSwu+S2JjIhbRqbMTYh/MsKlj7ZKamVIMs8EajaYTNlvG UMohZjabq4BiuRcDI47AoIcUmFHR6X3AoDdMiIwM35rfBCTGxTWWVGWKBdNyUL2CoFN0Pr6/R0eG Z2Wyp3MTEuJ62W1qhF3CWNjX29cZTacxOOPz2L4Fo1S/IsvwMOV+xZItXxtmLhN078TGRC119iJg MeQsKT6OCTABJsAEmICbEtBL4IeSooeWcgNfkl2hiNFgl2yVMZN818xhUaoN9U/6V3xczH2yAp/g K+C/IWPQRYpjrTNWiYnZ1CfAR55okYRX5etqhI6TJSul1vjKbE7sn5cgmp1gDrOBOgejWpPA0YqK gRIla3rX2GkJIYq91ujY2MF2c1xMV7sCn2L7Qdnbl+2YnEOnx/Y/7GvQQTP87Hrfs0+Mpo5+LcpU sRgqCi0+lgkwASbABJhAORGIi415VlHhVXzlLDr9eZAbYNb6wbZ8u4b5WMEGmLuU0nCpJECMZnNS VXyntoLhFskolFmtcPHDpJhgzKvxNQoRP0yVcdjHaFxptWa8rxehB2aWn6LI9l5Gn1//lmWlqoSd EXQ+F1TZ2t7XqJtqs8uDMV9ZDRsYHsbKcliH0JJUVVDsr9jQ0oP5y9Ixg8dok95yCQNQf4KpOShj 7MN+fmdXYfu/y6rwrayo/lj5EWx/Fbb/DrZ/r6KocYos9wD9uemYr+wsdVrUGa9gepEHJMmSkqmu cECq7VxRponFUFFo8bFMgAkwASbABMqJAK4D1caf+TY3NK/CFbT1OJmhXQSdqJmH2uHC0v8EURym UJZ5TB2vGXgww+r5DONIWbb5CToDrpr5Rk4MH/vZ9Tb/ToifOiDDJndQZKmlDhOFUXoPFFJ+hgoh zarrkoefThG3yJJiVST79tz9NIrwhMWu1icLlN5o2jopMvxtOgaX4x6yW3QtFFn4JD392tlzqNOw fX9qH5fPYiZGjF3iaH/m9Kn9M6xyZ1W1Pyrq9WdUm0QJXqUGDe7dPnhwBy2v2c0UFkM3Q43PYQJM gAkwASZQ9gTys/ykOd8VFbPW60BC5SPZ7Cl6/H8Qjbg6plBmMiyKD2Z+f0DTRZjE1QfzuGavGwUK ZoaXgZbGDDrdv3rR3lSSrP62FPvKw6p4TNQbP8RUqu/HRkYeu7FPUgouyaEWEtGgI010fD42ImYV /pteWkk0xz/saN8o6tAB6L8iiAZUYJRKDWqpgliL1toUyVpx//7VR2JiVmtDQKsTruSZZqAP0jxn ubiNGFIlCWScQD1OQ+5iT7sK5y5eBjSzARj9oVb1qmDMgc9ZHHwcE2ACTIAJMAFPJoBJ4nV6END3 RxBtL0iSUEuPzjeCjOnFsrKT0TpTVrnxR5cEB75UP/8Yk2o5bpOEKZKk3I0n1VEky2SQdeExcQkP h4aIh1KuWCdb0MOaik4QmuECnXayJEmYKza/kqN9FROx6kMgJCAsNuwKKqEs689/q4UqmagqU5ey 1ehXlFl0CzGU8u+3MGb0rzDyczO09c+tci7D/JeGwlp7ZahbEf3Bat4GE0Y9BzWzuXwVBQgfywSY ABNgAkzARQnk95ttKkp/ZRB34vE1FEFpp6AyMYD6J+qTFvgeCggRlYu4Hv++S0FNYlGU9Ox14/IY mR0yt26lpPROtYmfmUzG51AEXTGZIBR3rH1qV+W7BFCWWq36WKznacf5dGKmskJvIYPJjP/oQ38l muPuTLcpDdEfaSXuEruGtW/A45pS+zZFPB1qgjuv2K9+Fzs1/ke9IAeTUkPb0nlBhUtYZXNRb7ps 1PveYrEkX9VqVyRAq1COfhfGx8XFkB12rV4EL0Ukwr6zbeClvMw9yYdgR0ZdmLZsDrRma1Bh882f MwEmwASYgPsSSMaun7ih+4JwFv2ic7tV5z1KdPCxy/Chj6A+bLVLncifGh2o5+lUNQ6db/zwD1uA aJtl0Qnj7bJdUNPU6HhzQhNFsi3XiTDLZpNaUEM6vXgGl6dI6Dxrscq/AJgG6SWLSREE1Fbog4Qf 2BSfzYqc2ve/jgjgoxPewi31texWW+eYWHN/kxEu4Zrbt6qqVhBF456EhNnhPmCdpNMJz9tlSZQy rk5KVvXhoiidVhXboMx1QpRieuMS1Z6Wiu3EoElLkCQ7WYK09TMqMWZzEFgsF1BckdN4ocXFxZAF /jh4CYaMjYB13/4DaWk4zuCciif91DFIlvfDpwmJsNo3EPo8NRRaVGZVVOjM8wFMgAkwASbgVgRs CizEDr93Q6dxiQt3khXsPCxpxhztN1+v1wfpZSHQSo7T6Hqi14vBqh230GtySq10xgKXjKI6GD9a rKhSW5tVbosCZwbuAaNt86iEdH/aBOjlp9cn4M6xF2TV3gU36Z9L1WQH1alHP2zx9cjwUdo2/exl dmJCOyXDMtkm2wPxnC8tuFM+s+DynV63Nz1d91tEbGxKfGzMY9j+Umy/M1a75b8lPDoU7U6qjhy0 21B3UKiFoA3pYPZ2dLRDLjS0Kb6335lJdnExFAhDRkUCJG+CNct35VgMdAzu7NmLYLJWhka3NIGK qcfhw3mJ8L+Xw6FVpbwFUYUKFcDX19cZNm5/TEBAAPj5FWnZ1K3HbEIbbXBwsFuPwdnO+/j4QEhI iLOHu/1x9J2l766nF2/7zgYFBQF9b72hlMT1i1YOsnxkWT+Kws2gB4vVBjtQrNCP4yncUrZHsMuo WjQxdE6yw1/4fhX8/CS2Q7Lo4wRznB59gcbbJIWEFBqPQDL6+JywWeHJ2MmRyYmJiWaDLO8QZHWE hH7ZmZpGLwlgitOLBrQW3VjGhkfEJJrNawSwTkExVjvzHFFCh+ffZWv6yNjYCZq/UlRM7BcJ5liD XYIou6RQ3RQVUsENbP64DlZflTKWopf0HrDbdlMN+Mrp6I0DQdHn9O4yFxdD10Gm5x86oUGPEfAx vjKLHfY/+wh8+sMeaPVE6xyz8NFHH8H+/fvh6NGjcOzYMbQyFcH5vihXnAsd+88//8CVK1fgzJkz LtSr0uvKL7/8Alar1SsE0W+//QYRERFeI+zXrVsHR44cgVq1apXeBeQCNe/duxfdMFLg1KlTLtCb 0u/C+fPn4e+//4bJkyeXfmPl3MKJEyegZs2a5daLsMhYuqjaZOuAtq09W/kkd+ciIqNpS7tjW/sN fQ8PDz+Mb9KOLad3bVEl4ZGRG/E/PQuDEREZ8zEeQ6+ssmCBuVLyJeUl3FNlEH2Mq6dMivq9sHqc +dw9xFABI7lwZBcki7WhSd1gPAojROFusmsUVjxXufXWW6F27dqwfft2tPDpoHv37s7wcetjDAaD JoS8Yaw0Ubt374a7774bqlev7tbz5kzn6Qekc+fOXmEtIR6HDx+GO+64A1q2bOkMHrc9hu5NFy5c 8JrvLM3r5cuXvWK8u3btgrNn0bWHS7EIjBgReQkrmFqsSvI42T3EEHqGp6WmY1yEzBFYUq9AOkYS r1jBD879+QVMWJ0Bs+PCIDB1PxzzqQzd725yw1BbtWqlvUcCISMjA7p0wSVODy9k/Tp06JBXjJWm 8ptvvoGuXbtC1apVPXxmAb744gu47777vGaJgSxDJHTbtGnj0XN77do1OH78uNd8Z8lSQhZsb7gf 0xLoV1995dHXrzsPzj3EkF9V6NztTqiC4SupHNz6Hfx6tQG82P9uuOWRKJggzIbZ06aB3qcCPD56 KnRu4J/vnFjQW8tmy3/ZzZ0nM3ffvWmsNHY7xrJITy/Sbkq3nW4aK4ldb/G3oPHSQ4ynF2/7ztKc 0tx6Q/GG69ed59E9xFClW2Bc1C1ZnG/p9j/I+kswQsdHIvHlztPAfWcCTIAJMAEmwATKi4B7iKHy osPtMgEmwASYABNgAh5PgMWQx08xD5AJMAEmwAS8nQCltMAgBnUcYX1wiT0jMjLyTFJSjD+uVlb9 L96PKTk2NpKCO2ol0RzTIDUrFhCGVjSFpEdGhuXwBDfHxDT4r94AiIzUdpnlWfDYmnisD1Zkwfxl p/M7LikpyTcjObn6f02bMJyI77mwsLAcW8GTzOZayRYLpp/ILCZTwe3n1x6LIW//hvD4mQATYAJM wO0ImOPjX5YU/1+io8MotUahJcAEtTHO0F7cdI2JyUSQQLcOT+op2429FUn6VEtMhu9j/KF4fB+j OgPMmBY7264Ir16PTYTvYPRqKf1kTJy5f2x05J9JiYn3ZmSkP4sBGJ/CQICaU6/VbpHj4hMmREdF zMqzUzr4WFCEu0VZR1vi89zJhIIpRDXoltsF6Iz1ZgYNFGxwLVX9LSbGPADF2gV6y2yO6yFLCoUE oKBrWvs2rX1zdHRUJKX7cLqwGHIaFR/IBJgAE2ACTKD8CcxOMA9VZOUNQWc9smnTpiYdOnRwKuUE 9txH6z1FT7RrKcYwZ70N048JOaIUL42JMRzTi/E2WRmjqgJFk1Yxb9gujD9dV5astTCw4g9x5qR+ RiVjjE1R+yoqZgkD9W9RFNpg7jIM/qxLjEuYfS46YmxeMYrIioPtqYa8SJrNMaEyCia7Xe5K4gyD TV9SVeWUoCqtZbu1I+gMX8aYkx7xU5Jbo+/9VzgKfxGTuCuKTMEXDdh+U0VRp8fGJYiKVGsmRuZ2 ykOfxVD5X9fcAybABJgAE2ACThEwm80VRVl+CfN2oZ4Q6v+04bfBKIY+dOpk1D6oLvQCiiGM4tzU nJjUUVQNDykqpm5FPXM9VX1KcoC+npIhh6uUDF6n/8TkY1ocETF2VVxMTFvUJ9/YFam2oFo2oAjC tBhoEtL7nouJntB2tjn20Qyr+gF+7geSIb8Ik45AgHlG0hYVcahdVbqDoFNEnX6Wn8nvg/DwsH3m uJhnMKfau7IsdxR11pEo4LrLquoPgmGfXq97Kypq8lxcCvTBFKafS7LcV1Xt0/QBp79ALv86w4bF kDOU+BgmwASYABNgAi5AwAhSnwxZvjUzjZgEsk3/EgqkFej/k+XnU2A3UcBgElRcfVLrojXlbgHk niqaX7Q1Ji0dveibIYlTZRRbot4A+kD/ZRFhYavo4+jY2L8SzdOOSRZ7bUxeT2k8tKZUxV5l6nTz O7JVfN9k8rvfbkndq9gM+Vlk8k0ouyDJXBcFWJiMmWN1RoNaoVYNc9gzz1yhNmrUCfnqzMlrb2XY ZL2oSqMw7qAfWY6MJp99URPC59IxmEbEOjsx/vuMDHtfu4z9k9VYfPtxZ6aNxZAzlPgYJsAEmAAT YALlTAAtHwY/gzhBUq7rCbLwKLZ2NsWXUlug348zBZ1wMJGqJCt4qk0QFMUiiD6AC2GAb2GhPGRK bU0XoY+QXpZzJAVUBZ0BPYcyc4XqDZ8aZfttdklqLFulF9Cx5wWL1fInqqiPY2PC5tAh2OeA7L0y 6XLmEMv+mWSXfHDFLZTeo7bt51Mq4T81MZSRYcIlvjTsm4wGMbUivYepXXG9Tc1yntZ6r+j9UeDh v1Q6MjP3mROFxZATkPgQJsAEmAATYALlTcDPJD5ttSqNs5tWVEUGQZUSzImJByLDwymTeyGFss6j D7VsQcOKHCXJoq9eh9LjP68jPOA/HyLURzksPJQkPlOIoNwwmj6LGj/+8YT42DCrXe2IS2YV0Fp1 Hy6c3YE+O5WCAn1+8tXrv8rARGKZBR23VTUArVL59pEEjqMYDIGpuJvtznSbsU5QUKV9uChHkVd9 sh9DyVuzV4ZqidYPtbfwuLwztufROouhwq4b/pwJMAEmwASYQDkTwJ1bzSRJHYcOwzf8bquSva6i 00eg4/NTg2NjC06xgEtimIR+majC7bIiN1XI+gPKO6qqDkR/ooooddLREToJk9l/ImMqLNWihi5d utRn8ODBVtzGXs0mWX1IfejxADXlanxMTOyjoDe+HjslMokQTZ8a8zU6XvdDjTIRl6pO4LE5xApp qOvC6IZltJBU6WiqXvcFVv2IhMt0yZAsBCjQE3scd+XKuT0ohozkUa2CsAJVTisJs9db7HZfs3lB aGTkiAu4Hd8f/cFDaJkNnbzJUfx1Z6eNxZCzpPg4JsAEmAATYALlRAC3jC9AN5hmeTWvogO0LNkH HTeFkO/Mb4V1UVXUbTpRrW2X1KYkGmTc5o7iojeeR8tPusa+tm93ScJ+9AtqotjV2YcPH+mP/jgr dIIQh5vQKpAgEXW6xeiw1BUVx+PY+AMoisajqApC408XFCvkg7RVsum+skpSth1luK9fgJ9kVWiv yLbauIQ2PKuvuHSHQYK+CQBprqgI90uy3R+uXPs2XYUluJaXhiuCLUlFCaLukiAapuvBin5BEKVK 1u529eJu7F+MThSHSJKC/lRoE9KLf9l8fVYUxsLxOYshZ0nxcUyACTABJsAEyomA1SqNQU+YHP47 2buCwkVEYwptL8+7YGAh/ED7zUfH6Eq4V6syOQkJokiO0JVxMSw002ajhj4UFpu+Jyamp0EU1uCO raaSZO+OH3QnEw+KEQr9MzMqMiIiwRwfrpft49GCVBlPXaAthikoRETDSZ1OPweDM57L3RlzbEwg WqGwGVsj/GyB43MBV7QExfd0eFTYt/GxMU/qROFzdPC+A9u8I/uqGp5rkmxSO0mBeIMOKuGOthGy bK+C9byF2/9Rp+GSn6jbokpin9hcARoLmjoWQ+V0YXOzTIAJMAEmwAScJYA7uZzwB8q/NkkPlzBu YZymFkD8CW03x0V0lKYdWXo9/CbZMNCiQGJLWE+1RMbGHpuXmNg3xWZ5xmLTZA468+BGfKPv2ajI 8Hn0RrrFNitEr/8+DZQnbLjXXWtdNKiq0f/NqMiwM/n05g18v871z7IchATc2i8q9r30flRM7IrZ CfH9LBap4/V6VYx1RLvg7lQk5T7s8lzwC/1hUvioFxPi4w9bbLYgWhjDU1WDwQj+/r5vYqTqi86y peNYDBWFFh/LBJgAE2ACTMANCURGxtLW+8nZuq6JnmxlS+5hjQoPP4DvTcpvuLg0RbakPQUdk/vc yJjYt53BNzYiajUeR6+sQr5Lxw8fbobSTJAM0gn6ICIqKtGZ+go7hsVQYYT4cybABJgAE2ACTKDc CZATN3ZiR2l0hMVQaVDlOpkAE2ACTIAJMAG3IcBiyG2mijvKBJgAE2ACTIAJlAYBFkOlQZXrZAJM gAkwASbABNyGAIsht5kq7igTYAJMgAkwASZQGgRYDJUGVa6TCTABJsAEmAATcBsCLIbcZqq4o0yA CTABJsAEmEBpEPAgMXQJfvp8B7R46F6o4YMxpbgwASbABJgAE2ACTMAJAp4hhtLPQFLEMEj8yAjf D+wKNZwYOB/CBJgAE2ACTIAJMAEi4P5iKOMkvB4XCd8d1kOjNrUwLCVG5Dby5DIBJsAEmAATYAJM wDkC7i+GjJXg4ZFmGKkegefHrgCLDQdegBgyGo2Yh8X9h+3M9BoMBq8ZK/HQ6XTg4+PjDBq3P8ab xqo9teF3lr67nl687TtLc0rXsjcUb7h+3Xke3V8V6Hyhbu1aACf+hQybjDno8p6O48ePQ2pqKhw4 cADOnDkDe/dq+eA8uhw5cgROnTrlFWOlibxw4QLs2bMHrly54tHzSoO7ePEi7Ny5E4KDgz1+rDTA s2fPwv79+8HX19ejx0vf2XPnznnNd5bux/S99Yb7MV2/XFyXgPuLIQdbWdVS1uZXVq9eDfv27YMT J05oAuGdd95x3VkpoZ4dPHgQrl69Cna7vYRqdO1qSAh9/PHHEBQU5NodLYHe0bW8ZMkSMJlMJVCb 61fx999/w7Vr12Dr1q2u39li9JDEQUpKClitlILJ8wuJehJC3nA/Pn36NDRu3NjzJ9VNR+g5YghU UBVKoJt3GTZsmPbB5s2bYd26dTBx4kQ3nTLnu71q1So4dOgQjBo1yvmT3PjIMWPGQGRkJISGhrrx KJzrOs3p7NmzvWZZMCYmBgYMGAC33nqrc4Dc9Khvv/1We2AbOXKkm46gaN0+fPgwLFy4EBISEop2 ohsevX37dli+fLkb9tw7uuw5YkhVQVYUlEQFl7S0NMjIyPCK2aWxpqene8VYaZAWi0V7qvYGMUSW A1r29RYfKZpbup49vdD31VvuTzSXdA3T3HpDoetXwd8oLq5JwHPEUM0OMPuNFlC1EJeCO++8E1q0 aOGas1HCverRo4fXmNsJHVmFqlSpUsIUXbO66Ohor1gOdNB/9dVXvWK8PXv29JplbZpbWjYKDw93 zS9ZCfeqbdu20LBhwxKulasrKQKeI4aMgVC/YWChXAIDA4Fe3lC8xbnWMZe1a9f2hmnVxlinTh2v GSsNtEYN74geFhIS4lXzSg7xtWrhBhgvKAEBAUAvLq5JwHPEkGvy5V4xASbABJgAE2ACLk6AxZCL TxB3jwkwASbABJgAEyhdAiyGSpcv184EmAATYAJMgAm4OAEWQy4+Qdw9JsAEmAATYAJMoHQJeKcY wm34+YaqLl3epVg7BRXII+xkXmP1yPFnovXE4ao4KCGP0Op5zbj7Ty3GC8Pr+IYrOc+B5XPNl+K3 rLSqzneO87hV8RyX1iyUYb0efj2XIckSa8q7xJBqg98/mQtv/rQf/H2qw7DJEdCumnuH91ds1+Dz meHw2QEAv9Rz0PLpKTC2XxswKBmwetFs+HjLCfDzbwgvTR4Dt4SI8OeX8yDxuz0QoK8MQ6Inwj21 /UvsYirTis7/CWHxS2FQeALcXcsIaae2Q1zifEhOtULj7i9C2BN3A1w9CIkJc+DopXSofuujMG7Y gzjuMu1lsRqzp12E5e8vgJ93n4CLxtowOTIMbq0RAFcP/QqTZ78PlnQVWg8YDSMfuhVsF3ZDfMIb cO5qBtS7ZwiEPdMVfAsKyV6snpXGyRLsXfkOxH+8HUzyVegw1AzPdWsIOtUCvyx9A95efwj8TbVg eEwE3B5qhN0rF8LUz7aBvy4YnoqKhm5O7CQtjV7fTJ1r35gLx+reC0P6tQIl7Qy8NScBdp5MheCG PWD8q49DJUyvl3piK8QmLoRraXZo1usleGXQXaBc2Q8zZ7wGxy+nQ83bn4SxL/TC8d9MD8rwnJTd MDv2Z3gg9iVo7muFNfMnwzsbr0AF+1mo8uBYmPzUveCns8OWz9+E11btgwBDFRgyeSLcXdMXDvz0 AUz+4HfwEQNgUEQMPNAyuAw7fhNNnd0KM+f8BY/GD4f6Bsf5Knz3ViRsMXaHuOfvA1AssHbJa/DB b0fB37cujJgSDm0qGuDvFfNh+pc78P4UAs9ETYIu9XnX2U3MQLFOcaOfhmKNUzv51Pq38Qt3BqbN mQWWNa/BpOmz4YOZk6CyG2c02LNiJsz97iIkfPYBVD+6FB4bNwEaNvscOpxcCO9ukmHO7FlwdFkc TJ27BMz3+8GcLw/BxFmzwOf3BTA23gxvz54GNd1OD1lg8aSX4fUP7fBgOP4aKJfgrenTQd8xGmbd 5wuTxkXB4noVoeLaBDhRbTDMimwOSePDYMbX1WDaI7cX/0Iqkxqs8MXrU+CfhsMxQm8r+C5+KEyI /Rg+n/sQvG5Oghr9Z8DINhkQFjEdvqwzFdI/M0N6y5dh1sNVIG7sOHijeg2I6NW0THpaEo2kH1wD 4UkrYNgby+Bu60/wVPwEaN7mM2iy522Y++NlMON39up3syA+6R2YOag2zFy2HUbPmAVVdy+Bl6dP gbqvzYaGFUqiJ6VXh2w7D18tioOxry6G/u+u1RpaheLgD/U+mDurGyyOfQWmLK0Oc59pBfPiZ4J/ 91iY3EUHE8ZFw9J60yBg9XQ4U/tZmDWxEcwKD4PEb6vBlIddNCK3qsDlfzfA6JfD4JvNdeCBxJfh 8uZFYH5vG4xZ9gXcafkZHnsxBt5p+AUMDl4Fs745CjF4rxI2vAkT58yDWc+3hYRFG2DI1NnQ7OQ3 8CLep+u89jrcUtEF1Z8qw5mdP8LLI0fDr0fugP4zh2ddRJd3fgLDw2dCk1fu0t47tmYuzP8lDRJx rOeWz4BpSYtgxsOVYdZnuyE8IRGCty+CV81x0DgpAWr4ld61yDXfSMCLxJAMv6zZALVuGwHNKmOc oYceguAl8fDrqTTo39Dt1EDWTNbt+Dx82rUa1KyEFq46w2BAna9g1949kL51G7ToNB7qBAVCnf59 YdEr78Lc81ao3vZZuLUajr9vX6j2fhSsP3IFBt/i4k9cua7bs5u+gRVH/eDOTmTVw5vj2S2w/bgJ xve5FWNIAfS/vT4sWDQfgmw2eHRKD+29R+5tCWNX/gKpKIbc4pnr8h7YvE+Ge7tKsPK776BC71fh g9o1IWPvCthzORSm924MgTj0vs0qw2cL3wS/DB8YOqY9BGKYmgF3NQDzdxvAhmLIXfK829OS4QrO TIumIRCqtIYgwwdgz7DAph9/h3p3joLGlXAS+z0ElYe/BnPf3QhBzfpDh9qofmr1hQYLXoWf/jkP De907YCbB375HFbsNsJjTw8A1UC33jOwduNJ6Dm5D16jfjDw/g7w/KLf4XC3VNh7JgDGP9gS8G14 uE1teO89vJ6tCjz+bFcIxGEP7NgcJuL1nI5iyCV/M61nYcknn0OlO/pAd980SElVoF6TvrB41WCo U41yBw6E59sshk17/4bNGb+j5bY/3FKV7ksPQZ3l0+GNBTvBUO8+uK8hXtANH4SW876BNX+fhlu6 uWAssdSjsOiTr6FhlwEgV1XARqkgyTIkXYAPP9wANdtgsMXKmSLu5zW/Q+P2E6BBSCA06I+/QS++ CfMWSVC55WPQriZObPW+UPftcbD28DV46hYXV/cepqi8SAylw7nLIvi0uB7UzMcfAo0inL2AIf7d WAxVqFYfHF+ZMxsWwMcn9fD2rdVhw/cC+IZc/8QvGCrI12DHPyp0uKNS5iWs94Mgkw7Hn4J/uI8Y Uq/ugXkfrocnwsbDqqVvgg19KuznLsE1fTU0O2cOrXLlKnDl0FpIrtwcgq4jCAmuDLa083AVjw9w g+Uj6dxR+HPHNrB8sxYaV1Tg2E8/QPtHX4H7bamQiku8ftcfkEMrVYLz67aCocZtUOG6pq8UUhky riYDJa9wFzEUdEsfCO+xFUY/NxrqW45C9a4vQ8eaOph7WgVT8+vXp28FCAELbNlnhduaXxc+gg+E +Bnh7LmrOFrXFkNNe7wEi3Gl5ItJY2CDhN21X4CL1ooobjJvw0FBlUCwnYPjBy9Cms9/13No5VBI RnF7JfSWrOu5Is6xNSUZruF5LimGTDXglSlvgpC8BZ4a8jFYJRV8K9UGR6jQ9H1fwpvbLkPUiCZw 6WMbGBpdvy8bA6CiwQ6/7E6DFg845tMAFQNMcO78ZRytC4qhwAYw0bwA4PhaGDT6R8ChamXjsjlw KrQ3jB2owPco7AFscDbZCKaK1xNJ4/UcpKbC9n0StGt1PZ+iaIJgXwNezzizLIbKVG55kRii3GXo nJn9h1CQtfc8oZzd+iH0j/oUBka+Be0bhMD3qTbwyfGjL2GYf3QwznLExQ8Fxb3GjzeO5W+9D0LX F2HgA/7wzbsS+OASp4gmefptcQxXEFVQJAkkTAPkGC79V0VztrtkBkpNuQaSEAh9R46BPnVEuLph Pjzx5hKo82R10KMQ+m+suEqojRWdjq+/KQg4fhyrO13ZyfvWw8870+B/I9AKZN0NC5euhb96twIR LSg5vrMg43WsgJLrOnaHnE+ZXZbAil9E7d903WqOtJl3IO0tukZxfHK2m5IgAsg4x3j4f8fiwQq+ 4cpzrA0LRYCE99js/v/XDqyEx16eBbePnAkPtakLby60gJxtPgVtjpFD9pPwXqXIrjra6xOIY6Xf EyNaha7uWgWLNgoQNb8fHJ33Fah68sUQQJLp2nVMLm0UyOt6xrFzDrMy/1n2IjHkB1WCVTh7NTUT st0CGVYRqoa65HNVkS6EAz/MhaEzv4LHJ38AYffVx3PTILSCDS5fu56k1ZoK6UII3NIkA50w6Qka i2yB9AwBqlR2i0WjzD5f2gtfrdoAUjMBXl17HDb9tQcsc96CWo/VgepwGecTj8Er+sqlqxBcrwEu ulyGNJpufOi8huLCxxQMQW5gFaKh+lUIhho1b4GGtfGXkP6uURsqWf8Fq19TCLHvBQv9MOJHVy5f g8qNGoK/cgHSaLrxnnv12jXwC6gL7rT4+8d3y+FApW7weqe2OIi2cMuygfDpbwfhjqpo9bl6PUGr NR1SVX+4pakPCFeSr39HbJCSrkDDUHdZUsj8QVfpx84YCqHGa2DBJSQqqWnXQNAHQM1GFaGC7RJY bPgmOlMnX74KIQ0aQqB6EdIJBRoWruEcm9Di6/KJha7rF4eMObd1KbwwaT60feEtmP44+TupUClE hf04Hq1IGXDVbsL8kQbQXyNLkPYmLrPJmID5ukXl+ruu9h9tbyMqV3oI3f7Tl7Bz32WYO/ZV+Gfz RjionoOvuzSB6ng9H7nmuJ7TIBXt+i2b2kB1XM8qJmDG73HjKi4/s66Gv9j98SIxpIcOXW6Fr79e B5eVTpDx2zo4U6MetMfdOe5czm78AF6M+xiem70Cnrmz8vWh+EPHTs0hftNaSB/cCo7+/CNcaHgb RKNzcSI+cZ+1dwf9pvVwtFJ1GFfPjXIhBbeBN79eCakoaG1n/oS9+45B9wdxjb2ZCPVCFsIPv5+G VjjG7//aC3c/MR4q/ZIE36/fAV2eagarf/8LGnUd5fo/Htdn0Ni0A9xV/WNY/eNJaN6zFuz/czso 9W6HO9q3hx/e+xR++uMKvNDGAqv+OQa9hkwA61czYdWvh+H2fqGw6s990Krbo/Q76jalfsvmIK/f BAcsz0Fj227Yn6yHVk2awl1Vm8EXn6/F5c32cGXDWjhRowXEDKgFs99ZB4cz0Ido76/wj39FeK5J VbcZq4yWIbuVlk1qQofWAbDu543waOuu8COOP7T9IGhcpy36+r0PP2w8D80762DVjv3QeXAEVPhp Dl7Pe6Djkw1g1eYd0LTrWNcXvGi9slntoMcl+dSDq9GZeA50jvwUwns3uj5fAtzV5Xb47OOf4bzU A+D3dXCwYn3cZdYa5r65DnZeewIan9oEf4t+MKmVi+cwQ6ue1WqFFBSxdw+fBSueSMEHFBusVP+B 76Xu0KlFHTjfoRGsWrsOUp67A86t/wnO1GkNk/tUgsQP1sFx6wNQ4a8NcCAoFF6tF+w217OndNSL xBCq7d6joP/OiTD8heHgZ/eFsEnRUNvfTUwF+VxxW3/9Ec7Zg2HbsljY9D4+YeCTc7+XJsADj4RD 938iYOiw4WCQgmF07Fi4vbYeHvk7Al4cOhwCbQYYETkZGrmLqYTGrzdCcEgV7QXBadC8eTNoUrc6 +OKNduSo52HMrJdh+Cc+ULHtc/BC7/YgNh0FG2PjYPhvfmCq1QcmPt4lr0hMrvldFqrC0NgIeOut RBi+3AJKUC2YML4/BPsFwivDB8HY14bBH2iPr3Hvy/BUlzsho/JQGG0eB8O/M0GFpv+DCf1uc81x 5dOrxg+8DCPxep2A12ZF3HZdqddIeOrOauAnjYAHN0XCMPzOmiR/GBUTA7c38IfBO3bDK0OHQUVJ hGfHxULrypkWNNcvAlSoUhWqBpM3lwj9R02EbdHTYPjwj0AMbgfRYb1B9NHBy6OegTFzXoThi32g crsX4Pn77gK1wUswZupkGL7eF/zqDYAJj97t+tcz+ibWrF0NgvCX5uDGNfDvtQpQfdUb8OLXVlzm 00PX/42Bx3uMgMd3RMEInONAuxGGRk2Bdi0qwrO7d8LEYUMhBJeeHn1lGrSvnrVf3TWnGf2datas Akb8SfHxC4Kq+KLSrFlzOCI3g0roDV+pbxj02jVBu559JPwuT8HruZ4JntgxAUbhtR9sF+GF8THu dV92zdkocq+8SgyBIQhjkrwOD164DCI+TQb7uf/wHxizCO4bZUETu+W6/4AIAUFo7cEb6ovT3oJH L1wBn8DKEGjK/LF4ZNwc6HbxIgi+IRDi7+I3l4Iu56BbYM7890DUZXoSh97WD95/pzMkY+ydKqEV M8+s3xH9EVrDxas2qFilMq2guVWpVOs2iJrcCC5ctYAvPi0GXncCq9V5MCxu2xuuWnW4zBmsjcnY she8/c5dcBmXEyqHVqIVNPcqukDoFz4fulw8D3bBBKGVri976YPhuclz4SH8zuoDKkGQb+Z8P/gy xpd64gKoPkFQMdCdbGB6eCh8MvQlRyAsPlVbQ+Kb78P55AwICg3N8vOr2m4ALHr3XriSjkvZodet tw07w1sLb4WL1+xQCa9nF9xkfuM1V/VOeO2tO0DEL5/yZAJsf8QGabiem+mqKYBfIF6/OgMMGv8a 9Lh4CUS8LwVfvy91GxoHtw+4AHZ9IFQOcv34J0L9e2He/C6gy3Wj6T50NnRzyFafiviQ8yYMuJAM hoDKUME38zroF5YInfG+rOJSfsUAd9n24F63mMJ6626/D4WNx4nP9VAx1LV3nTgxiKxD9AYj0MvX Py+fCSP+MOYeqwgVcbeV2xd0rtTrc16+Bv8QqJLLUUb0qQBV3Hi4gtb/G+fWJ7AS5HYr0PsGQxX3 jiEKwXlem3qodMN1LECIm17HDgGf9R00BOAc37hcb8QHthuuZ1MQVHF9XfDf7QW/pzry+MeiQ8uu L7388nJN0OV5XwqqdH2XlTvcsFDg5rolab2+Yb5x3/2N17PottezO0yNM330QjHkDBY+hgkwASbA BJgAE/AWAiyGvGWmeZxMgAkwASbABJhAngRYDPGFwQSYABNgAkyACXg1AVcWQ67cN6++aHjwTIAJ MAEmUOoEaGeAe293LnVEJdeAKwsOiqp2ruSGyjUxASbABJgAE3AbAhnY0+zByN2m4+7YUVcWQ1MR qNkdoXKfmQATYAJMgAkUkwAFILieRqCYNfHphRJwWTE0depUSq5ALy5MgAkwASbABJgAEyg1Ai4r hkptxFwxE2ACTIAJMAEmwASyEWAxxJcDE2ACTIAJMAEm4NUEWAx59fTz4JkAE2ACTIAJMAEWQ3wN MAEmwASYABNgAl5NgMWQV08/D54JMAEmwASYABNgMcTXABNgAkyACTABJuDVBFgMefX08+CZABNg AkyACTABFkN8DTABJsAEmAATYAJeTYDFkFdPPw+eCTABJsAEmAATYDHE1wATcEMCZnNMiGKDV2xK ViJHSuio6o1+YDL6LwsPH7W/oGHNTjD/z2KxNJJEI/iZ/NeGh4f9WlIYEuNjH02XxJZ6vTHZak1/ Y+rUWEorUKwyOyHhPovN0lECozUo0DcpLCyM0xQUiyifzASYQHYCLIb4emACbkhAL0FlzFUzJXfX ZbsVbKA+kZg47yEURP/mNzRUJyPx1QHw/xRF1eFxJSKGkhLNd9kV4TMQUJuJ+rCSEEI0Bh9RPGIT hB9UWYL0dFslfGusG04bd5kJMAEXJcBiyEUnhrvFBAokoMds1jaQBVGnE0Xha1mSfjLodYNkSe5k t9uagJg+Ac9/jur48MMY0+HDmRak2NhYyoRNGujaf/Ur2ntUYmJiTPgf7VgslBtQxJcvvuz4UvB8 Gx5D4slw/RgbvqfQv5cuXWqUZWWsJMsg6I2SUa/743p90KBBAzh8+LBmvcLjLdfbonqz/s6rD3ie +swzz1hGhYcfTIyPn2pXbZMl1fio2Zy0ODIybMd/Y+B/MQEmwARungCLoZtnx2cygXInIAgiGEy+ ayeHj31zwYIFn129fPFYutXuq8jKoKSkpDm29PT/2SXhKdQc/iCI6bFxCe/6mcSPBRCyBBCAzvIh iqCzPvpPRAHuUVQw4sBS9QbTQT+D8UuLJeVZm6oLNZl81+H7T1cw6nukSfJ7Chh0OqPxIXzvj+sg BElWesqon3SCuCQw0HRAthn2Z9gk8eTx42Qr8kURlh47ddqvBpBIdHWhPk2dnrBS9vMJiw0LyzDH xY7BPozBPvigJtMfO35aSkhInBAREf4eiMpKURAmy4pcG3vYEM9nMVTuVyB3gAl4BgEWQ54xjzwK byagKP40/BEjRlyYZY5L0gkQqaqqn91mX4JWolvtoFMNBuENUZEetSnWSVbJt6GvTrP0aCYi1C7C RT9jlM1iv08VDRkGEd7F5agRsmTvbNEZftPrdZJkV2pKilQbBZafJMA4XFqrqTPqwKTPsiJByvH9 FXAVK0MAXZCoE6/4+lqsVwBqUyN2BSS9wfCpIkuDZdn+uE3UXzTq1XWyLA9UJGmYPsXnDfRjai0r 6mxV0IPRqP9BkSypkmS9xyaKL2Av3zP4mvwl2QJ2SQKbJPuh1UlAK1Ox/ZG8+dLhsTMBJpBJgMUQ XwlMwIMI4HLZWhxOpKZzFOlWO5pYQBSOoejYJ4o6f0C1osjyE6pOVNRMIYSLX7KPLt2WKAFMDg0I bpRhS+5hRTuOiufaJDXDz6hfZbNb7lBk9R673f6YIsnNQdCBKIrvp6ambnPgS9P5R4KQXpUq1Qsq 3Vu02um/OoPxSgU/n9WpKdcGywralIw+x/yNurVpaakDtb9N9onYnTRNWmG7+BZ2UFyl1/slRUeF a/5MuASHOk8bGK7RKbF+ISHL8a9sFi4PmkgeChNgAmVKgMVQmeLmxphAqRDIso6IesMkVbKj/kHZ oMqa4QcUqaYKarxVUS7jXxdQZaDPj1oD/41LUVpJhxBTA59r9mmX0i42RtHUBC00uEqlKROpRhDM P2QVX5FlKUiWdZGSoobgCtYFRW+cFRs7XnaMCK1RAXgarsDh/zQd5Cj0liCgCNMsWJpLkoBqSpH8 ss4FoaYq6l/Q6+Xmdlzmk+1yD+xBD0VNP4XLaN+hkBqv0/ngip+N1BAJosDMirgwASbABIpPgMVQ 8RlyDUygvAlogiQxIaGvXVY60W579NnZhbaUIFQLdUBv+mNK9IR7sncyMcG8GjVLL3pPFMHXmibN tylKBxX0B00+PtNVuyU8w66Qk3TAYyMiLydMi12G5poXcb2ssaxi/QbxcnR42L7cA0d/HxQqRV+5 wtOM4eQkHRczxGQ0PalItq9UUXwaBVgTkJXhdru8y2DQbcisWRNTRW+kvGeJ22cCTMBlCbAYctmp 4Y4xgUIJ6BRFAmuGNA79Z/6Hy1YtFUXRoVczGm50b+oEpaleFEbbZVvbuDjzBFG1tLPJQj3R6PtN gEG4kq12vA8oQZqG0Yk7QLGg9pAM6NxMh5ApBkSD8aBettrQB8mIW+bxHYM5t8+OarPNQiH0MFpt QmVcysLKtFO1dlTtj/8sOfg3Krgs85EqCKkYn2iARYb5iipX1etNEw2ifAT9iZqg9qJyDlfE9Fof sV+4fT8+OTlZ25XGhQkwASZQXAIshopLkM9nAuVHwI7iQ4f6oBp2oRoKIRQKhh2CTv92VMTYhejs HGiUlRaq3dZLkixmWr7SG3zQOdknFlRLCzxHyYwzBCkocN436KSZdtk6MEPRDdTr9IqAW+RFQe1p TkpaEBkROcc8bcpL6AjdQKfTY3BH3b7oqJzOy/f3lw5997VOp0roMC2pKKJC0A0pFV/kog12VD6k kLRt+PQ3qiOyaGX+rarGVJuywmQQe9kk6QWbbJ+OFagi9kOvE6PDw8d+kWQ2dyD/IhHFmF4PR6Ki Mrf0c2ECTIAJFJcAi6HiEuTzmUA5EEi1wAn88jbXZEX2ououRUdFJNNbGKU5BWP/9Dt9+HDtVMA9 YOjUow/wlSLCwo6azeY/0XgzSUEtku6jOxcbFpWSGBf3jR0UQUVTjI/JpNpTUwH/8IsMCzuP2/br oOXJHz1/0DCjW+drSN6Se9g7djTBjWfHdulkWxf0zm6Olhs9OnA3Q02DDkLk/my8JINM2/NBVCUr GHxTlNT0FZqBCNflcGcYCafhcXExiWjw0sYlCiY1KjL8IP3brki3keAT9PpLRtFA/k9cmAATYAIl QoDFUIlg5EqYQNkSQOFAW+MPFdbq4MGDKXCiJiayl8jIyNO53wuPjr7hODpm5ozps2026RlFVSrh tvc0jPM4Myws9oZ0GNTWGwnx8bgTrYsK0gMZVn3f6OjoJbnayRbsUfvkSu5+REfH3tCP5s1jRBn0 MxRcbTPohO8wfcjvhY2dP2cCTIAJOEuAxZCzpPg4JuClBNBVuQJGld6Ebj4Z6Dy0CJfgfsgPxaX0 er+Y9AcjcXs8WXGaTZ4cI5RESo5HB4H6lE5aIojGiiIYo7x0KnjYTIAJlBIBFkOlBJarZQKeQiA8 cuJQZ8cSGzuYHK5nOI6fOtXZMws+bioGV5yI+dRKpjauhQkwASaQkwCLIb4imAATYAJMgAkwAa8m wGLIq6efB88EmAATYAJMgAmwGOJrgAkwASbABJgAE/BqAiyGvHr6efBMgAkwASbABJgAiyG+BpgA E2ACTIAJMAGvJsBiyKunnwfPBJgAE2ACTIAJsBjia4AJMAEmwASYABPwagL/B8HofVk52iWRAAAA AElFTkSuQmCC ------=_NextPart_000_00AD_01CAF14A.E58011D0 Content-Type: image/png; name="image002.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAeoAAAE4CAYAAACUm7AeAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAALfkSURBVHhe 7F0DYFzNFv5WsW3VSo3Utm3btm3b7V/btm27adTY3GzembvZNknTNkX6ssnM//Y1u3vv3JlvZueb gzlHOmnSJPDCEeAIcAQ4AhwBjkDGRECaMZvFW8UR4AhwBDgCHAGOAEOAEzWfBxwBjgBHgCPAEcjA CHCizsCDw5vGEeAIcAQ4AhwBTtR8DnAEOAIcAY4ARyADI/Bdop4wYYI9tds5A7edN40jwBHgCHAE OAKZAYFY6sRtcu6OT60zqRI1kXTOXr16HS1QoED2zIAA7wNHgCPAEeAIcAQyKgLr1q0LvXv3rg21 LyLNRE0XOpYpUyZ7mzZtMmq/eLs4AhwBjgBHgCOQKRC4c+dOFBH1d/vyPdV3XHh4eKYAgHeCI8AR 4AhwBDgCGRmBmJiYhB+1jzuTZeTR423jCHAEOAIcgSyPACfqLD8FOAAcAY4AR4AjkJER4ESdkUeH t40jwBHgCHAEsjwCnKiz/BTgAHAEOAIcAY5ARkaAE3VGHh3eNo4AR4AjwBHI8ghwos7yU4ADwBHg CHAEOAIZGQFO1Bl5dHjbOAIcAY4ARyDLI8CJOstPAQ4AR4AjwBHgCGRkBDhR/4XReXp0LsatvIg4 kQhieiEhAQp6wSwnxk+bjeI2klSeEg+Pawex9ko8Bg5vBqPvtiMaWyd3wB7/clg1vy8sMuGIKWKC cWD1BgTnrYfOVbLj0qpuGL0vHnPWL4ebrdZfGKG/WIU8CCvGdMJ1vU4YWz0M/UesQp0xm9GvmgPe nN6Frc/0MXxAXWj/xUempapLm0dj3l45Jm+choLGslRvifO6jaHDpkK36khM7+SWlmp//RpFHF6c 2ondb0wxvG8taH63hkhsmz4AhzzdMKyNBGNHr0PtsYRjVUfcPzAHk1afQUCsHkYtWgfDuzMwfetd hOs4Y+aSlXCzS98fQXxMIPat2IjIwg3RoYLLr2OQ5jsisWN0f+wPzY65c0bCPo2TJsrvIZYuuYgK fXughEVyhI8t7opVDxwwf9E4ZNOntYiXTIFA+s74TAHRzzvh/eQM9h85+e2FUkd0HTcv9QpiPTCy V3uc0BiE4UTU3y9y3D+7Cwc+ijFvHhH1z5ujdlf43VyDFv3HYMCW6kLb9c2ckDtnPPRkGXChiY/C jeMHsUU3L0Y3LoecuXLD0lgfkL9B/67t8SLPLIwb8O+HwOvxaRw6FImekVOJqFN/fnyoBw7tOAQj o1bpR9ShT9C7Uwd4FV+IcX1/hIMUTy/vw86b0ejbowVy5s4NCyNdusEX86fPwMFnZmjdrQVs5U/R d/Qc3BMXR9s2LjDRT/8ly+fKCjQfNAWjdtdJ54GMxcMTe7DLtyTGTk87UR9e2B/Dp0fj4pD+37Tv 5ZU9OHTcFaNnM6JO5+bz6v8ZAuk/6/9ZV/5/DyrRfhGulPFDfPBTDO3YE15lhmPHsHqAtjGyab7H jJ6dsPmCD8RG+TB27kK0KmuLtYM6YP+zCMTIVsCtqRgnd47Bx11T0GPqbsSKNOFcrjEWzRyJ7IZS aOvpQmKgC3GKLkb53cGotv1w4mMQDPNUxNQ5s1Atu6FwlTzMH2umdMKSQ68BLUf0njoXvesWwI11 fTBifzgalLPBwQ0HEWWdF/3nr0F76+do3XII5KV6YP3MjtCjOt5fWI1Oo7eh2ZSFsLu7EqPWX0CC pjm1cS0G1MuFqytGYfKRd8jvJMPpCy/QZf5ONDW5ib6DZuFlQCwMXQpj6sIVqJpD2abQlyfQo+8I PPCIg45VToyYvw4NTB6jV88ZkCMOG4Y1hES+DS1M5AgIDEWsQtlj31sHMXjUWNzxjINZkaZYvXQM 8uoHYWyXFnhnXhPZwu9gz7UPsK/QEqtnDIKTvkYypF6fWI2BY5bhrXY2tKjqjGtnPTBo01JY31qJ gcvvY+zGnajmIsOl1QMx5r9PGL9pO0rEHUf7rmPwKkABXcfCGD9zIeoVNIdIJIYOSSrGNCYJsVEI Dg5DbPh7rOw3EOc85EgImIWyjZ8iG14huuAg7JrQGGy7Ee91Ee1bjYFDp+mY0bE8bv83CH1X3kev Wf+hY1mWqC4Eq4d2xba3JqhZSAOH955FoFyKfNVaYMEMWsR1Umhl4kKxZc5ozNl6FsaFasNNpgmR VAv6ehoI87qF0d174vSbSJgXrYuFcyajqI0ORGIZDIwAYwNDKGJ8MWNAR2y5+B4ybX3U6j0dEztV RdzrQ2jdfRYK912NKc3zCTh+vLAcncbtRed529G2BNsqxuLq1inoN303ommuOpZugEWzxyCnUThm 9uqEq58VEJ2firKdYnBgw1CYJY6GPOITFo4ego2nHiFX1RYwiTeGoQU1KC4KQUEhQHQwdk7qib33 Q6Cho4uA18GYO60TrnkCelaBCI+yRzaaSq9PrES/kYvwIVqEkq1HY9HItpC5H0O3znNgUKoIPhw9 Co1qw7B1YRdoh3lj2ZgeWHHqFcRmuTB2ziq0drPCw12j0G/dW9StmhenNu9EkL4LOs9Zia42L9Cr 11xqcQxWD6hHTVqP+V3LCj3we3wQfXsvhm3VCvA8tw2Pg4zQash0DGtfGVqiBLy/uA7dhs6HZ4QY RrlKY/qsOaiUk839GByZOwpj1x1DrEwXjQbOxej2laArFUFb3xA6MfowMQA8zs9H06G70GjMKoxo XBChH69hbN++OPU6EmaF62L18mnA+ZkYvvQ61SlBuzJ1MW/LRjQtpEIY0NSl5xnqQ0dPhJiAt5g5 rB22XwuE1KwwJs2fgyYl7GhxiMCl/6ZhxIKDCI4TwZnqWTBvMnIZaiD45TmMHDYMl+iZMgMr9J2x Fl0qZ1OuPYoonFo1EaMWH6TMEVpoOnwJxnUqB015KPbMHYipW24gJkGGonU7Yv6kgbDQyoAb7f8f TfzRkzlR/xF8ypsNrHOhDL0QbQgz0kQFOxRA2bLsx+2HweVLYtFTHfRoXwuBd46jda2qiDh3DjlL lYHtzmvw1syJWuUKw+/cRvQatAguTfsje/wzrFw5EQOcy+Lo8CpEDt9O+LjAp+hTuxH2hOZEl9ol cGL9YtSsH46Xd7Ygu0YAZnashHFHw9CpVyPg1SX0a1AdkaduwdX3Oa4cPQ/PkGZoVKsU9i7agI4t 9FDpzgxYKp5i4fIV6DegHcpZi3F60yJcvB8B09ndcOZ+DNXVAto+DzC2eQ3Enz2GvN5vcPrYHrwq UReN6jaDq+we2tdvhw/ZGqNFYyecXrUYXbub4tKJJXAQf8Dojt3xUKcMGjWwx8Wt89Cl/2gU3DYI pUvkxcHnt5CtYGkUdDLBx9MHcWBbOLrPmoewt7tRs2orBOaqQ+11wbVtc1G1egBO7+mH93euYPvz h2jcszvKZfPEmmUj0ccoFw5ObQjVxA58uRutWvTGG+ty6FTREYdXLcJ9HyO0iIiBxruHuHT5HLzC FMI4+ry4iStXPuDNi4vYP7U3PpnURMPSRji2bj46jLDBu+NzYCxVbh4kMi2Eez3Gtl07YVxnEOqW LAmLrTcRYZ4XtStVguL6XUycNRc3BzdGKf14HFwyCdsuPcWqWXmF+x2y5cSLawuxYMsZIupOkH+6 h03/7cE1X+DiATGqdRyCivofsXrxWPQxzod9E7/2id1/YVlvtBuzDeVb9kJRgw9Ytu4qsVldhL+m DUa79nhsWQNtWmTDo+ObULOmO85f2oV8Gsq2a2lHYO/03lh68jPatm4Iryu7MLt/V+Qr8QLtsuWB 7P0NbFqxCYObz4Yx/LF0/DCcf18eC3KYCvd7X96M3oMWwKnpQOQSvcSa5VPQx74UTo+rhDxFisHs 8GPEWedDxeK5kqi+I7FxeAsMW/4cjXt1hI3fJSw9/Ra2xQwQ7vEI23ftgmn9sWheoDRsjdjvwgr5 CuWiDUoAjh96B01zZ7jmssbTU7PQsNFk5G7ZBy0c4nBgcQ80DovF2paauHr5Atwf+6BTh1ooUbUY dKO8MalNVcx+Yoqh7Vog6Pl5tK9XDeKrV+Hi/xqXT+2ljVhdtKlaEcdXr0Tf1n2R/+hklHHLgyOv 7yJ74TIo5PKVBGNCPHDxyjl8fvASnbo3Q7EHJzG+U31I7V5jSFF39O82FFGF26GBowL7li9HR60c +Lh9GK4u74WWw/ajeveOMPx4FNO71KWxuo9pzV2ETZymjh7Caf6P6DUOEXn7omGlfAj/dAHNKzfB a7uaaNsiOx6f2IyqNb2xckIDlMpjgY+3gBIVy8DOOPmmVBggTV0oAp9hWJOaWPXeDN1b1YIXmdma Va+JHbcuoqIfbYY7z4BL8/5o7BiCzbTB76ZfAKdnVcGIVg2xIyQfejavhWdH1mFYl85wvngCVR20 cWJORzQdfxXN+neBA95jVY+GCJMeQBscQYdRG1GpxzDkT3iBFXOGIsHSFVsG09r1F9ZXXgW+rGcc i7+AgCIsAnIyTStio4XaPp3ehPWX36Pr+odY3skVCGyEl9kqYNnK47i/bgLKLFiCc0aNMHNAQ8QH vSdpewmMTDWxePouxNGa6vXmg5IUUmnbpxsHsf2OB/rsu465jexQ3ckQN7XKwozMk0HPTmDtvieo P/0U1o+qRuLcC/jkKoI1izdiVElSL0ptMHrxBnQtrIsC0Y/QaeULfJRaY8jIflhRZxaOXv+IcnWi sfv0exSt1YAW5n2wKd0f7Vu0gCy8CG6faY4lC7ZhYm4xxGJLDF+yDb1L6CPh7R509VEgUOMT9PN1 x4QFBaGZsyQsmclUbI1O4+ehAi39706swLsQMcLffUCYaW4MGNAcozc9Qr0+U9G6gj32nyCaJalP XzcCFxavwv0YR+zfcRANsxGmFfXh1HABtp0oD5G2CGZFu2LjirnQD7uBB85l4P70I0nnXyf2w/07 cTfUCIuOH0D/0oY4Z/UaVYbfhoQkY6mmNv2rD1kiwDItwoYkRB1jF5IgF6C61Bh3di6AV5QYIe6e 8KFhNdZO1GuQD4JYqgl96ptMxxrVmg5G/onL4FGkDcb2a4uwQgGYt28IDl30QalaQVi15RJsq41H i5LKhd+ydCv0qzED0w7sxuulnaC4egRPI83RtHVZHNu2H++9Q9GnbR/kLtoC+SuWTz4HEjywc/NB aOdpiE3bl8GJ6jMJdsHE4xG4fWQPTr0IQqf+ndCigjVKGfvi0KBVWH/qI+ZX1hIWzphYKcq16o/Z uQOhH3Qdw94EAlEyfPjwCSLXHBjWvy7KzDyF+6QdKON1EBsvR6LJtIGkUlcCZZK/KiYtWEYmCh0s n7EHMWyuvnpDuNdGg36DsWjhZoSV6ICpvUmrpCpBT7Bt63U41RqPPcsnUTu8EPTGBUciYwhHI+hr SCDS0INb45EoMW0FLhnXwZyp/SCOLoONc/fAuEpPIrKqWNSkLz5ou2BCh7Zkn42H9tsLpOlZi3OF Wgl+ARX6z8L6SfWFp4Y+3orNh5+hWI9FaNmiKqLdbXHmTA8sWnYWM4vQ1SIDDJy5GiOrWqOS/hvU m/ISYRYF0b9fU4ze/AyN+k9D+8os86CyiMVSAb+KQxZj/cTGlJDwDt5md8N/q//D4O19MHTWUoQZ mOHU2unwp0kY9+kzgqI9sWnZFuiX64YtqxZA52Nt6C24iyZlLammaNKC0M4+/A1GdmmJs+LquLdr FnLQ9L+5dw9OvgtE7yGd0aKiNdxM/XBwwGrcjZmELs1dsfN2DMYuHoWCKdVs1EKpDvD46E5su/EJ fXeew7zmlK3YswaZk2ph7bqTyFkxBjTi0PD0Q94uPWke1IJL+arQiPOGt3cYwqK8EGJWAIOnzEMn 7ZyEM20GYt5i0+q90MrfBO3atoAVAuB+5TjWLVyH7HXliEQC3n6OQd/+g5C7XGcUq1SMk3Qq6/bv fsQl6t9F7of3KfeR/j6epCISoUBeZ+XVJi5wJeePS15vEBkZgTgFOZ3Jo+jnSgvdvRMYMWIMIi0L oV3Nenh2bz7i5anmEBeqiomKoZ8GEQepuFipNWAyaiW26YO3h/BDLFAgh/ITiQ0K2Rvjoc8r+AfR XYaWsDdROhxpGtGvWqSgzQVgV6ML6jhMJxvXBbTT9MLdKCuMq1MJu0j1/P70UpQ4NBfxYk2YW5oi Z2wc/GNioKVhCHszZlukarLVxq4t49F52AyMacPszdoo23Uq8pIK2C7qDVbNHI9Nd/zQos8AVMx9 BTvc5ZDH0YIaylKwJiAyNIj+tVdqEMS04MRGwt0zAFpmtshmq+yKRb6CcEQ43L38SAFLqtzszhCe TmyhTYt9nFS5mKqKjwchoWWOPI5K9btD9pz0//fI34/6HM8kaTFkUiUBacgIE6kMsT6PsXLBOGx5 EokOJK27OV3CsTg54lPNb8OcB2mc4kkFTtXFx4YL46lfsjYqmY/G1WP7cTM+AGc9dDBqVVsYfmmc Edp0bIE5rZbjMJkNNA/vg7h4eyxfMhAnHGToNXsVGp5cBeg6Y9D8tcjXrTI0vtwbhbBwOcydHL44 IbrmzQ7poQgEkAo5jrBcP6QOltEc0dQ3hqW1A8QhgTR2EiIbgiM+BOcP7kePiTtQvHkv1KtYEAu2 PUC8QjnfijZuB4fhrXHm7FV43NwFf93C6Ny2whdMPUiSHDFiNELN8qNDHZqrd18inrAU4Aml5xMO 8phwUvjS/FLdRertCALGIY9T4viYwzW7NQ7c/zrHRUINwYih3a4iLlKYw2YhIcLmNy4mkg0yvKgO Udgr9KxeGDH0IAMzS1jrFEJoeBjNGyC701diDffzpdpIU/LfCORfRaSooQtLU2vkiAxBcDwxqYYJ HCyUc1dGpiX6AGJqTvL5+LW+BLY5o6vy5lFqRaDrAFdLHRz1/YhPr19g7vhROBeog06d26Cw9TXc pN+vXBGNqFgR9Iz0aFyoOFbDkoW0eRZKEKS0OQx6cRUH9WjDqLiP83cCkaOUCZl+ggknETYMrYPl ScYxzucTfGMYZnEIDqAazVM4DhIIkgT6bfp4IYp+GfnzOCgfZZsD+Ukh8uTtK7hMGIhd056h6+QN aFtjO8152kRPX4l8w+pj/q5NkPcfilVDW4JmH3JW6gWHAgtRzCgQvgnaCHl2CDWLkCChkMLEyhyW ZlKU6D4Gq8PC0HfhItQ6sAik98e4ZRuRp3WpVIWMLxOJ/5FmBDhRpxmqX7lQuaJbO+Ug+TGB1Kv3 0bdkeTL63sOVTzGwqu4Kba0YxNAPTkw2K+bXfGXvRrzxccb1t+dQKuIcDi6aDx0bK6Ge1Oha18iA aIoo5+5boJotzs0fgA2vrTGV7NqmLrlgQ4vW5Qs3gbpOZP58hgsvfWBUoSisjcjpTa6AnF5C3ap/ 2eoqcUH7Lo3Qf9U6TPCVQy9HbdSvUQKHh0bBxm0ozu6bAPMYTxzaeRyxecpC59QUxNLiJRc2FGJE f/aCr3FxzNl3H2Xz62F200qYvHYmrowgFVvwGay59Bp9193Eks5FMbnmUloRjcDWyQRiayYFa+kp yZR5zUOhQJymPnLnskP09ru4+ywaBYpo4c2l86R0M0EXFzs8E8tpo0MEyp5OJEP7nm9KjgIkTUTf xrVHHgSTHa5dv0HXkA1VJCMNoYzINxyBiarvD5/IGCrVxoebh0gT4o0Jhx9hIuHX+9RMxBuYwIKJ bKxtqRaGaTwkGjrCeEIjB7p3LoOmG5Zh+AVfSPPUQrtKyT2I89Rvj9ou23Bs2QR8visn9WhtSII+ w9StOc6/Wk6SMklexWpgweRV6NWpMnJ8WZP1YW6mDc9X9/EmDCimH4nz1x9DLs0LE1NDWhwT0GXB Jcxokxc+Dy/i6K23KF41FxLCL4HWV0j9ycSxfQ9c6k3ExS2jcHdJSyzYKYOZmVK1relcFR3rWmLR 9NFw8rqMHPUWopqDyvs+ARf2bsIrT3tcenUR5eRXcHTJXEisLIX5CNoAqXBI5o+sZQBqGu7euEWy WCeYxrzBhYefaHOUxiWI6iU6hQU5TyToOmHTufOok1MXD47uwc1QY5R19MMKGpp4mg+qokskzvyp creYj4OL20Hi+wJ7j1yGSfFKML17iDU2ce6y+77+yhRE4jRDyDckcT4mVsg2kGz0b1y9BLTITTuA R7jsHgqnMoXhc287jtDGbumtZ+hTXIFm2ycSiZrCXNMQxkakrXj+nIwItEcOuIS2HVaj1vipaFPC kjbIYZCYlMWeo7Nxpn9VjOoxHo0fLoW9JVs5EtB5/kXMbJuPHkXjePMdStUoiLcradBplhlQvd8U 9nskrZCtc3YYkJhw+epjdCpQFPKnt3DdizbvtDbE+LtDw7UObZKmIZ/hJ3QqXhobJi1D3/YlEB5j ju5zD2B7qbw4PaUtms1agS0X+qNYSztYyCKgn60JTp1eh9z6oThLmh9P/VzQp02FbYWOuDlwMyzC zqJ2iSaYNW09erQqBVuu+/7OevFrH6fxV/JrlWbZqxVyhJIYEBQeJUBgVbwpBjbbgvFjG6PS6aLk THUPAVa1sXR4fXLsCYeZhT7cL5ADySApmuQuCQPFEvSsUQc28vd4QQJEtvfugjQRExZOjmr0SgKs nVtTDKi7BdPHtkS18wXI3nkK/jb1MIAucsxRHYN710DvBd1Q+vF6wP0J7saWxrbJ7aG5aSMRdzBi E8XDmAhy4mESS7ySbKu17gyTWfWwl9axTutWIJtdQQwm6arF6LVo0/Y1LKI/4eQZP4w+WwEF4iNJ cgqiupQNSyAV3tSu9XBfnA81imWH5/tgOJRrhRJ0nEaqmw8l9OKxcWpPfNxniOsXyRgr84ZXcDxs ze1pQQ3H8mHNoRW9EtmkTMwOQUiIJqr1Gow6GxpjYL1i2J7fFk8vnUPpFrPQpV4edB5DanYTJdbE 2AgJjENYWLRSsksshZp3IRPADkxsWR7Xy+fGs5sPaAlmC6QOXAoXgjk2YUjjUjhUlNTcxx+Tn1QO GOUojOL6G7BsWFvcXy7Bufs0GNae+ByeAAv9BESEJCBQHEXaADk54ySQqpDUEWIjWFpo4eKR6Wg8 QI7Vi3qjWpdhKLykOi59AppObovsKY/f6BRA7x6lUX3ELlJnVMLmjhUQcGYCOjSeBt1i1VHIToz3 Yi3UatkAdknXZJEV2vfugpXt5qJOqXIobCPHuTM+tNnJAbdm3dHl3FVsHtcRn47nhOeDq/ioWRGH 2/eBJDgGQQS7AanqqxRxxowjC1G73g14PTnPVAGk9qQvCRHWl5ZdumNJo/F4SErOOV3qK0lYKCLk LlwCOliEPjRX7RM+4gnxht2Hj4gk4HV0SYI318DBA5PRbHAsVszrATO2WBvkR7e+jXB8PB2vcnsH Z4kXqehJdZ0tBnGkOQmiSRQhSIoKhAUHIlAUQX+xtyQ5BsshCg2j92J0HEpOYuf6YFTH1tjuoof7 J0/BpcsS1CooJfmUtMjRX4naMF8djOxRFQPXT0GbwJMQe7/AmQcyrLrTAfZx4fTDChSkd1Zio0Lp /4OE90bmdtS/ECwe1AzygIWkHSqp1AKQuUSP/nq6bRKqfdyP0Cc38DTOHuu7NkMB7CW7bSBmdmuI MxaROPKWCFPzDbwTzNBr1GDsaTINNUtWg738Fc7fC4Z54wFE1LYI9/uMeJ2cKF7KDWWmjcay6mMx Zm0nrGjRD13XnMB/4zvB44RyHD9oVsKZtl1ha0lSvmI/OtfshKmL5qBO/q929Ohw0py4ByJnrdbo 12gvJgypDff9heD39DZN7caYNLg+Yl6sRc+GA2mzXQElyTvviUIDZdqQ572OHIPHd8Cax1LUrlIC cZ6PoZW9EqoXIXWWWB9DxgzGxU4r0LV1GzgZhuDiwYdouWIPCjzag1ZtZ8PSrTbyWsbiM6nzGzav B3NO0klWoj/7kxP1n+GX7G4RLYBNenaAXyGyR7OiZYHR20/Ced4gbL/8GUbkNLRw4gSUs2dqNl06 djIFUZvPEG/GonTHMVgZLsOeW69QouEMtG56C1f8tUHcQF7EPeDnVwKGSexRYh1HTN13ABZDJuD0 +wCUajOOfkhjUMyEPVgH3ZcchW2+oVh97A2QvwH2jpmEujlMcL9wE3ToEQsXI+XQ5yFP6Q7EdfY6 ysp16Ic5amR/HHU3wtCGrB8i1B21BScdZ2DejuuQ62THrAMb0b9yAdzzq4WOXQoju7HyXu1sNXHh +lVMmD4PT7xika1yT6ydMhUuTBizrop121Zh+n8nIHZyw7YeHbFt3x3EBkdDs0BjLJl8E0cf0qJF +lHHcq1J5RxO50rjyImoEvZdPI2p06bjvlccqg1dgbmTu8JU8Rk12nVAHruiSo9Uwr5lz86Izlko meOF1Lgk1h7agUnT18PTNC8mlLVDr5FHEU4qVesKfbB9nR/WHH8GmW0+zFpUBxfu+qBS7faoYSam tp4mW3s17O3SFtuPvEFUOBGJvi6qtiSnIJ1isCSnoV6dO6JsdhLzRLYYPmEqNHZfRSzZXZnaV+ZQ HMULGeLaNQdyaKv0jdc+a3aZVoPRn5wN9cq2QUF9Uk2To9TVM9kwYdkBhNN+pcWYtRg3uPU357IL t52JE2T3X7bnIuKdymBDs7o4c0sEJ5eSWHLiBLKPHomzryNgX7U3Vk4ajaKmEtpYOKI9zU+DKtXQ t6gbYrUX4qXCCJNW7MSNA/tgLVH6VgjzomQZwcP6lUtdNCmdaLpJ/K5Mp7FY4S3GwTuvUbT+FLRt fo883g0QQvDo6OXBqMlTobfvBuIZDowHhQVbhkZjN2GXfm7suPAYRoV7Y0Pjj7gTUAiOLjro3aUT yuUyouukqNe+N/LolFf2WdceHciTXKdEfoG4TYt3wYmzNpgybRU+RCpQc8x6LBjTFiKPy2jfoQPy ulp/6QMkhui98jBs847B+tOvAJsy2DJvAloVMMFLr9ro0KUAEYtS7ncp0QgdOvjDSUsB7YKNsXTC bZx4TCc5IpUbP9aFBNLaxJC+otWgiXD2OYV7slrYRA5g7Qszybst1q/xwarjN2FVoi0OdmqF3ecC 4B+agAKNJ+PwbgvM3nISUaISmD5iKEY0L073RKFki+7oHuYEMe31zKt1x/L+b/A67CPi9BtjNW1C 8o8fjTOv6LdANvrlk8aioLkmwhoPxpiXmnhG+6qYaLoxSSlYoxs62NmS9sIeo3edhu3M/th7MxAu 1XpjzeRxKGFF/bXqj2tXbDB23lb4RytQvdd8TBjTGXpkAVp18iZcZ03BqYd+kDlXxt4J81E7t/Kc V7H2c3HKPAdmrDqK0HgT9F9/AJM6VaJvquKKkRMmrT1OGx1ddJ6xHWPIPyEVN7dkbeVv0o4AJ+q0 Y/XTK0X62TBs4cbk10n00Wr4WnqlvF2EfDW6YyO9VMVx9Dy0+vKuAf30laXegJVI4pbztSKZI/qT g9i3pynZyiJBnV4L6JX8uYWbjMPGJl8/K91iDEmoSa/RRfNxi9A82W0ilKVjMGVbJ6+rSIvB2JDs XtL4OpamH3LpVLHKX687ttFLVarVU/UQaD9uJdp/+cYNG5VHqoWi4VAMk1ftS4GrJQbMTIK1QXaM puAYqRXzgqTF2Flb+OrV7n5k3Ysj+zRJXnRcqUrnafT6eldH1Z8N+mAHvVSl+hfMpGg/dsOXti5f 9/WsbdFGA/EfvViJDfHHkwdHcf5GCBzrtEetnOzA27dFx94NizYlDT4iRs4qnbCdXj8uElRoPVh4 qUqbL9A6YeD8HVC25GuRWhXCFLIdqsrcrTu+/N2gpsrDQYGQz964c/AIHpCypXn79nAmN4ZkRWxG GMxPMl6NksxbOjLVdAi9Umk9Oe41GzidXl+/65j457K1SgcwVvpOWfb1AoM8mLactEJJioVrLSzZ qWpv4hf25TB/Y7lUHqqFBv3n0Sv5V7lqDKTf3tfPXOvQ+y9DaYpOE+loYsraSK3MjDRSh1IYP6Zb im81UKXraHp9/bj21x8zijbti530Sl600WAUte3Lh+boRacwvhTyTxhAR+IGpLhL37k0pq5O/TdW pes8VPlyvSE60OaowzeoiGBbqhk27P42foNI3xl9p67H947A56/VA1vplbyQHw4tNHtSLjapjAb/ 6PcQ4ET9e7jxu9QUgaho5tJDRP09U/Nf6teNTeNRecAKxFvmx45xHf55pLLf70YUNvRphEF7b8Oy XBs6p58a+f1+7ep8J3NAZIr1uJivmgd17g9vu/ogwIlafcaKt/QvIJCj9ijcutUTDnQmNz1LoWbD cJm8uHWss9HZcLL7qk3RQovp61BqaCQscxSCs9K/jBdCwKJwM5y6RSYo50Svb44KR+AfIcCJ+h8B zR+TMRDQMXVEcXqldzGwdoYbvdSvSGCdswDSdxujfqiwFmvoWaBQ8cwYxFc9xyMrtZoTdVYabd5X jgBHgCPAEVA7BDhRq92Q8QZzBDgCHAGOQFZCgBN1VhrtNPVVjienLyDQyAXli6dnir80NYYuSsCr m0fwKMgc1auWgkEWmbGfHj+i8KrOyGujj9c3KLqZlyFq1akMijD7x8Xn2RP46dmigIPxb9cVT0Ez 7njGo1hB5+9En1LgwZnjFNUsGyq65f6tWMWelBHs/NNoVKhVC/aUnCbk/Uu8iTNC0ZyW8Ht5BRef haNEpcpwMMq4B4E8nzxGsLEj8tlS1o3vFM/H1/H4oyYq1S3yg7Sgvz1U/MZMgEAWWfYywUj9oy4o PC6gTct6KDDmbAYhagV2TmmC8beq4YXXUYq2lPlLwL21qFJzHvocvEZETZGwds/E6Es54UrJPkw1 /yyKRPizHahcZRxarj/3+0Qd+wF9GtbAk1zjcGVd6nb42wdmo06jUTBrNB239o0SsrH9anlxmjK2 rQzE+nL1KEDJNTSs0houg3ZjHRH1wx0j0WziC2yi6GbtjX615n9zfejDjahcYya67bz0Q6IOerAL TXvswzpK9tEiZwbLv/5voOJP+QkCnKj5FEmCgALndv+HdxTham5b5TnNyE+3sWXfFYRTyknznEXQ ok45IZBBtP8rHNx7CRZFiyHy+Tm8DtKCW53WFOlIuWpGuN/Gf3svU7B+KdwadoKbsyo5bjhOb1mP xxSi1CR3GXSsXTLJ84NwdNUWvIyg7yiZR9u6peluEYX6NIKMQip63D6PUzceQkKpOVs1rU6ZrFIO XjBlQdqC5xQpxChHCbSrVyZJRC3g0en1OPuYYihTjObmHZrChtbEZxe3UcYqC5ShBfLCuTtIsMiO Fq3rwujzA2zYewM2RaujdimlZsHv5TXsO/cYZVt0hsGrI5Ra8z1EetZo2q4V7Cg6x5PTe3EnSJMC hUTj9lMPlG/RF0V0XmPT1pMUeYvisjvnR4tGVSkcTWKJ/ITtW/fCOywBGhbZ0LpNfeh/foSls5bj td8HCu+5HIWNuqBY/d4YlEuf0gYm3hfhjp1b98GTouFYulaj7E/5CXAv7Nt3GDo5y8DA7yFuvQuC NbW9RRkW21xZoj4/w4rZi/Dc5z0lfViNE5bdKW6zPWUou4b/Dt2gGOUaKNukM0o4qFoYhyv7V+P2 ewrzoaGNyi16Ir95FM6unoOdV1/BIPYo1h7MhrYN3JRhU4WH+GHnvAFoPW67EKAkD+XqTra1UITi 3K6teKtZEO0alYZWjB+O7tyHUJuyaFU1H+IC32DP7jPQK1wbrhXbYpB2FBzkb7FjxXRceP8R0ec2 42AxMxgamkCkbw65911sPn8LIVpWlBilOXKbfrukvbywE8fueUJkaIcWbZvDWjMB9w9vwTUPDdSl rFqOtIt4RmkrzzxSoGHPpoi5eQJXvXXg6hiPK9df0NjkQ+u21b9sEm8fXIfLb0OgZZMX7VvWFDYh UfR7OLzvIgzz5UX405v4SIHPPG5uw6vP73FlxwoUMeuLyvl0cXrHGjymwD1SHSOKONcZOejnkr9+ axQduw7/bTyExtObJ5uzKWc4f581EeBEnTXHPfVex/piz95diM9JqSfJuTWS4o53aNQEZ3yNaDHy hcfnSJyYfRibhtUlAr+CoT27wdvYEk5Gcnz+GADFgv+w68wllIvYh/r1++NucAK0JWGQz99Lwf53 oGMxYHrXtpi95xo0dPURRlGRjvaZi00zOkJH7oU5Pdth/LrL0DXVpuQSEdg1YhP2TmsDLUpckPDx GAb1eozPn97CNzAKN31PYiPFRlaRQAJl/lnYtwPGrL4AHVMduj8M2wevxYHZnaArokxgk/qj14w1 iNczRVRgGFbuPotde5bgztaR6LbGA7lcXRHq8RLegdHY+WgHTvY2xZwBveBRoh8+XFkMc7EC++f1 Rs813ujx8iEubt8GvwQNxFFylUU7b+HY0am4tnYaeuy6D2tbW8RqZYNp7jzYMLcztj2RUJatEHzy CsW+sduwZ0oraER/xNgWVTCdUk062lvis/s7HP+wCyurx+H42ec0PrE4tWUtXCvUhv2FsRiy1RkV WjamWOs30admC6y/+5kSjGkhKGQabszZjpktdDG7X0/cFDugoJ0GXj2mSGoUBcx/3xH0qUppx6hE ej/GweMP6S8FLuxaixxlGqCQ4iKaNR6Eh+EiaCWEIX7RASzasRltS1li1/jW6LP4MAyMzfHxgwf0 SAo/fmAxzh0/Aroc4Y+OYPmuwmiahKgVn+/RWF9B895D8OHwKmV41WRFhAubx2HKybwoFXMJLs+P 0KapJyKzNUfFNzshv74VrXtORK9tr6H7cQGGjPeDRbZ5OH38kjDW909vxm63BuhmYghpzCfKt9wX 8T4eeOcXgII3vHB27VBQELbEEocTS0ag8/jViJPpIIbGatnuW7TBnAnNsOeUW3oGTgaaYHNzEZrW aIPg0kPRsndznFw1Bd2334ONowPk4eHwDQjCoYdrsX9GG+yZ3BkDF+ynzG2UmpIir209Pgr714+E lsdVDOnRHd6U8MZOXwxdKwfEez6ldshxZvtG5CtXHh7bF2LQ0vMwNjTAW8rGNnPLFZw8sgoFjFxR L78ORh/cifejm+M7sXH4SpWFEeBEnYUHP2XX5SFv8epRNLJ3zClkpHr54DT2kARapddELB7fELdW rIGHsUwI+sDS8zEpypTimZ8/shT6z3egcOnWmDN/PsW2XoXbkhK47X0YeWUe6FbSFaOmL4FlUwmm bD6HAfs+YGYjR1xZ2BHlBo9CHYplXc13A8atO4du215iSSsj9C1fHvf9QkBRIiFKoCxbYZroseIU pdOUo2vxnNiyeh9mEFGrchu9PL6WSPo0OlB6whXtLDCgUlnc9AsSQrDKHx/AqIlrkLP3Rpxf1gEB FxYjT6UBmLqsFmpSNiUSR9FhzgGMqEJZq4rmx+oVO+A1az9mDCyFJotP4vqHeNS3e4UjJx/DsXJd 3N2wAlrNVsJ3bQ/SJuxD4VJNMXaVG+qZUPxWEYVWpM3CyNoU6/zMLHQ974XibaeSlNwRrzeuwFND bWV40bg4WBdsjoOTu0D6eC8mjhqFY7uPQDZmIzYuu4o8LfdixqHL6FfBjsI6EvPo60NXT46T48dg 1a1IrLz4AT3KGWJd5wroOmIcyuQeLSS9MNCviD0318Hg+hLkqjIY+4/c+0LUpoWI4FfeQ67GazB6 23WMqWuCIW6VcE+3Nh6+3onslO6kXdGCGDhpLRof7oKDW/YgWN8N09auQeUE0jCcf0c5SYwwbcNm HM9VBdqNFuPS+k7JbNQKPWcs2XEeJUgarXx0OcITk758mWsUM7pZ+25YcHIuJUqJhc7rR9DS10aC 2AevveIRff8aZa4oi+71syN4CUUYpxzaRrlrY+2GeThUsA+aTTuC1QPK4SKl2YyLjUHprguwrl8l bOhZEN027sIDSo1ZxVZpyI96fw5jhi2AdecNuLu8I4IfbEdBCq83YnEtHB41HWtuXMCg2QPQ4FAM PLM1xNm9c2ChQRmyKMsWpYBC2+kHMbN1AezoVw2tF87DEidfrJhCOcDnXsTeIeXx/vA05G84FvMa N8NUVwPh92Bbvjtu7JsMK1pZn+7oj/ytdmLqwZsYWMEflfUOQe5QHVPXrkCez2ew624I4qPo12Sk jRyUuzvu3DuSwCOIqJUZvXjhCKgQ4ETN58IXBCK8P+IDJVgonU2ZGs+mYFW0LrIZ21YMRKGdC1G0 eAUMrptfWJDYAsxUm1WbUIIDlrHBtToaFnXA3lObKJ2BFAr/a6id14GSYMkQRRJJ4KsrOJ3NglzD pPhvYGVsG0Dqv3jSDyYE4eHdF8il5UsbAB2UdKVsVxQVe/bRR9DRZ0r2eERROk04VEK1kpaUF4Ey eTmaQ3EjjNJ4fC2+n9yJALVQoiC7X0Yk9zDxfsow9vAO3OnTvm0aCs46NhUbUtzzEXhw4xJcWfpM q2KoUZriLRMf5ilKH3xgscuA6h37wHFeO+y+8BSlnI/iQqg9BlYpiD13jsGHJGhnh2nCPR4Uz1ly 5haKUEICbYv8qFyStYE2MbnLo1MZB6zZMhbFDq1C8WJl0HtCZyGjU4KGEbSkfphI2crElHvyUyip +A1iBUlVIlGKhGJWuapINCCJDKAYzc9h5FoJdcqxfMZAnU6tYbxhKG4+ckc0BT3PU74WJf+gn3X2 PLDSEguZtJIW9ixWJDJCgvJav6B40YqAc6iai8aKxibCN4zG6ipeJwxH824dcGzMJvSoWogScRRF uUaD4GpDOv6ABEG6FVGSipS50qVmlL+Y5YgIuYVoSnDBUk+mLPkq1EA+qxW4eO4E4t+8QbU2PRD3 /AkunD8L+cWHyFlzMAoSV50REsWwBzEslO0WJf6bIKfoYJp2qEXJIyT0vZ0LzVmynYcJsa+VRB3m +QYeNHXk+8fB8ch4GqsEeLKMqievIGJUFUrzuAgb95fApVvAsF3HQBp1KrQpjImAlFJ4Nq1VSOhn jfYtYbesBw4dOk+Zv8S0wewAh0XxkIliaSMZj/uXHiKkmEyI5V6yZg2BpJWNVXZexNKgwgVtutfB jQVH0apMfuQrVgTV245GTjOl0cAxWyGyJ23DO49gysbDifqbSZPFP+BEncUnQNLus/jXTFpW5WfW ca6AlfsPocrJu4gOeYUFw+ah+aNAPP1wCE4k6TAK8A9kWYNZiYBveCw0dOwgjngDHYtc6NynFUyk CkSGRUCmTUTovZPIVIwyjbqjfHZdylgUiRhaV0sWpxzFt+OIkmPwOZCtpPr4cOM4vAwLokIxyqXM qqf1jOXMhhZFW6ZNgphySCfJUQKpRExEE0NqcXa/ET6SndFDLy8qlsgOXX09wevYL5BlSCKxMy4U n0ltqUGZnrRktN2gRM+UfItKHGJZBifKhc0ygunlqYPGlZ1wetd/WOF4C4bZKqJW+bzYOEYOW7ea 6Fq3IETyGERGRcMiV0kEkU0+gfJ1J6Z1hoZ1cSzcfRRlj11FVMRHLBsxg9JHeiOv5wU43VqNbpP+ Q+Nxq/Df5A6YXdkQk0K0WevgT9I226xo6SoXbJYHmaX9TCByNdTVRNSnECFhBzNmspzLoaT/0KfP BdaUKok5gTY3LEGakNs7SVGmgaRNgQ7VLQpDdHQ4RU8rhm49G8NQEk85wSMRr5UdFqTWzzdiGQ7m r4yXPpG4tXMJ1pAqXMMhH5Y2IrKmGKwS2Q8cn5gm5Du/LbF1CTQskQ27ji2Hd4wc5fo2Rz4dD2w5 tB4vXxig0fRqwr1yVQJw1n0h9SQNlWYiibEYsBTPXpFI5nGUyYwBIE7SXxbyk+VWy1asLjrWyAdR HI1VdDRMnCsJfgJ3j+zHa4pnrq+tieNkyhjSeBIsifXFrF7Kpx3MbibH+Eh/wjhBB/o6UqpPgaKV W6FhcRvEx0RRrukYZC9VgAbivvB7kAnpOJVFmTpTBA1ttuHUQvvpm2Ff9gDc/SNxbt0cLBjYBPoO 9zCpUZ7E35wOdNgmixeOQAoE+KzgU+ILAjrm1rChxf+Vh4/w2ftTlNSjx2JUG0DJQkpURxHXlfgQ YgC2liTQYsaW6VOLh2FR9igYPN2Pbfe80XX1dtT2nonmE59Bxy4/itiEYNWACYhoPh1zm7bE0vmH 8DlMG0WKFMGTfUuw9ZoYFXsOQwG3isittQKrp09B9p7FsXpwC5yWNcaLW3tIcqFFmGJ0q5bA+LhY xMbKk8mKOctUQT7t1VhD9+cOKY11Q1vgWHxNPHh4BHnK1EUVuxlYMmooXONbw+/8Wpz1NMGsDo1g fnwjrcT6X2J/x8tpN0B1C2SrYYzOXVphV6cZmEQq25YzZ6JUGUfUKmSA/2iFz0Z90Ha/ijETj6HF prowTYhDdCxtGBKFWM8ra1CjwzSU6jodXStWRskia/DklT4MaN1OEKTRGGhraOD8hslYcp42EW5a gqOehpT9fwiuHTsAN8sGJE2yXKe0qaH0k/W6NMSEJgswZtQKtC9ngi0jFkOvYHs0LO+Mc1Posi85 RxWEEeX0TqF61pCxusNw6/hOPHKiTGpN3XBhmSf0nAqiiLkvlvadAnnrWRhFNv9+9SriuKI8Fk/q glpVi2Ht2Ve0ISCSlkaS6UMBzxeXcep2YVQmU8S3CwklsIiNpeenlk1dB43b18CkxjMQTfbZMRVL wpFs663IbJJAubDrVCskzD95PO1GYpVx2UVCu+Pw7MZR3KpoiwS2KSGSjE8EW8GuTRHD3Zwc7Rrl 08N+StqdY1QRSN9ewOjpx9BmQ2dEUZrKdu1mwKT7MmyoG4Fa9Yej3WhXnJjVhJwXDaCgvMoTRoxH RNNC2EsJSELtKmMY5VVPuH5aUNEXprH3ubYLk3Y+xYQW/WFIGw4WATw2SX+V4xiKW6dPobyJI6Z3 6oCnFnUxf2gTSCsVxPZb5Hymp8x96uVB2b3ElLPbKGUGFL5AcQRYTjleOAKJCGha5UPhEkbYevel IIk4l2mBse3uYeC41lhJBGRdsCK27p8BZxJlA4jMmNRXmtIP7h7bATfeRqNO75mY2LYCbBNcMM+3 L8a3rAZyaEbOyt3xX+OycKK8ibv3BqB33yEot1EOsVkBTJq/CkVMScIzbYKduxegc7tRaHyK0lu6 lMH8BZPhQuexJLpmMDYj5yGhnSLokXOThblBMrWrWYGm2LF3MTq3GYHGjRdB07kk5i6cQQnu6X79 Ylh+4BCG9m2LNo33UOrE7Bi1it7XyottJ3VhbG4MaaL4p2tIz7JQPYs8chu3gtvkVTgZ7YoezUqQ hCrBtF2ksu3dEQ3LUcIKkQFqdZ+L1kXz4ISOAczNdGhjoQTUtlhDTOl+C31ndMGmiZTGMHcprDu4 CLlI+FW4tcPU5scweUp7XCpUHc3b1saeq2/xyFeBUmUbo2aeTdg+pTd0KF1hKTt7aqMRpQAFpUyc hP1z5eg1pR8OLCA1fomWOL51JoqY0MbI0JjU54lSrkST8p2bwlg/udRrV7wuGhVag4Pz+5FDlD22 zdiJwKjuGNekMiJorPJU74P/mlA2L11DSsM6Ae+GDEP9chshIUm2zZTNGFyfHNNkZmjZpBwmb1uH LgO1cP3qXNil/BWJpDAxt4CGoW6qkrVzqSpwM1yOp3bFkN1aDIv8pcipygCi/JVQwEoJoKauCY0F GUtI3SF1qYQ21VywecdkjNfPgaFFrem7z2Q+UF1rDGPjWGgyPXhiERvmJsfFYxD37Eh92E7T1Rj1 +y9Em2LaWNxlAj46l8Le4d1QKpsI49tswqjNE3G8exlSpSugZZYPTtG3aL5Mh9iqKJb/NwcVS+WG 0+Ht6N+lByqWm0tCsj16jF+GGjRJI59IYWZsTOlPv57pdnarT+afjXS8sCt5ee/HmBnj0KfHQFQv t4Tys5ug1+Id6FLJiVobj5d3yFSTtzjy2HC1N1+Qv0WAEzWfFV8RkFqifIXS2Lz2Ap5FjkdRAwe0 m7Yd9YcuBRPMZDqGMEhUzTF1bAzJuDnrDcSa7csREqWAMTlTKdXR9ui/9ADaT6Ik9vROx9gU2ol6 6kL1++JCpdYIiyX7pUwPJgaqCB4SuNYdiCvv2yOCVJ4iTX2Y6CkXvS6LbqJ1vAyGwqV6GLaanKzo ffIz1WLkr9UPl9+1QXiK+4UWFa2BnRffICCMNhgSLZJclAti02kXUHuihDyo2TsZus87hbZxEhiq 1lutAthy8w0ixLowoXzRrJjlcMPaE/cxS9CNSmHKvLiotFhwEPXiRTBIbJhYl/KTj96A6r3nCqp0 qZaeoLpmRaxti5E7zqA7eadr6JlAT0OBqeT8pm0khkxWHgdvvUU4YSTT1INMfBy1Bqrq1UeNIYvx iIiGaek19E2hNOUXIScyyj2uoTyxLHKqirPPX0FM9yctMms37LzyEmExCkikJL3paGPg6iPoOCNY OVYmNFaJXJerQlscudoAgWTSYBskU1Mh2TkVQwxddgKdZzIZMuU4qC4piF1XnyFBqp1q5jCZdUUc evcOcRJtMlRQ7fma4Oq7KoiX6grqf1Yq9duGN90SoGdAuEucsPTgfUyNihParaVZG2/qyek75bG/ Kn3W401nBfRTSKSWucthw5lHmBvC2qoaKzm6zD6F7jrGNKbMwQIYuPEmOpBpREJOezvDQqGQmmHQ 8uNYRue4QfPUOHGeOhVvgoM3qyIwkqVJ1YSpsRJfRe4GOP+mKiS0WVMVTYeKOEBjwrCWatJvR0+G M3cbIJjdSxs+UxPWcyqx73DhfhgKVqxER8WSGnS+VMX/yOIIcKLO4hMgefclqN+yNUwWtsP63c9R tEMe4WtDItqURUHOPEH0oW9QOKTaRqATVSmKCEamqade0tA3wfeSMmkZmXw9k5tYo7aecZLFXgRt faPvpo3UpPu/G7xLw5DIJnkzteiMdlKZU0vP8JvnazJJNWX3JDpUV3I1pZb+t/ey2/SNvtNbkQZM iBiVhRZuc8GbSSiMvFW0yJyjtFLgq0d1JqNgCREm9f1LIeczQ+Mk75O0X0a2eZNkgpvku2PFNkyp RkOj404mJj9Q05JEbWD0o8hnEugxL/kvRUyakuTtlWkbwCRJv8Up3msmGRSZNm3svpmDiZUT+Zua Ju2wFOaWVslGVETXmFiwa+Rkpw9CrG8kOUyKYGz97diJtGkepXiWmE5BGJp8O/NkbByTDJQklXs/ ntqKox8TMKN9KzVKh/rNksA/SEcEOFGnI7jqWLVugfqYN3YagnSZU9b3i651IQwaMAAOJdM/E5U6 4sjbrK4IiFCieS8MKiSFwz/SQkfIXDB6+CK0Lft1o6au6PF2pw8CnKjTB1c1rlUfzelM78+Krl1x jFtY/GeX8e85AmqGgASlOwyFMi7fvyl5a7RH3hr/5ln8KeqJACdq9Rw33mqOAEeAI8ARyCIIcKLO IgPNu8kR4AhwBDgC6okAJ2r1HDfeao4AR4AjwBHIIghwos4iA827yRHgCHAEOALqiQAnavUcN95q jgBHgCPAEcgiCHCiziIDzbvJEeAIcAQ4AuqJACdq9Rw33mqOAEeAI8ARyCIIcKLOIgPNu8kR4Ahw BDgC6okAJ2r1HDfeao4AR4AjwBHIIghwos4iA827yRHgCHAEOALqiYDaE3VUwAdcuXwXAZSvGCIt 5KW8xK52yow6vHAEOAIcAY4AR0DdEVB7or69ZTGmHw1B43qFkCDShiPL/ccLR4AjwBHgCHAEMgkC ak7U0Xjup0DtoVPQr7pNJhkS3g2OAEeAI8AR4Ah8RUC9iTouAB/fXsGVV9F4f0AMx7INMahVdWgk Jr7nA80R4AhwBDgCHAF1R0C9iTo+BvY5GmJgzSYo5WSI8xunYOp/hpjcvuQ345KQkCB8JhJxFlf3 ScvbzxHgCHAEshIC6k3UWi7oNXnsl/Fyy2uPHduPwq9dSZin4OOlS5fiyZMniI6ORtGiRaGtrQ0V eWelAed95QhwBDIHAmz9io+PR5EiRVCqVKnM0Snei1QRUGuijv38EDuOPUOtTq1gTt2LiYyHtokN dFMRmrt27Qq5XI7Ro0fj4MGD6Ny5M8LDw/m04AhwBDgCaomAWCzGhw8fYGPD/XPUcgB/odFqTdQS LR28ursbL8ITUNJBF+/ehaJuqzbQSQUAJkGzoqurK0zswoULIzg4+Beg4pdyBDgCHIGMg4BMJkNI SAgYYfOSuRFQb6I2zIGpM+dj66ZdePkSKFR/MKq7Wv9wxJi6SKFQIDY2FnFxdPaaF44AR4AjoIYI qNYyNWw6b/IvIqDWRC30Vc8JbfoM/8Vu88s5AhwBjgBHgCOgHgioP1GrB868lRwBjgBHgCPAEfgt BDhR/xZs/CaOAEeAI8AR4Aj8GwQ4Uf8bnPlTOAIcAY4AR4Aj8FsIcKL+Ldj4TRwBjgBHgCPAEfg3 CHCi/jc486dwBDgCHAGOAEfgtxDgRP1bsPGbOAIcAY4AR4Aj8G8Q4ET9b3DmT+EIcAQ4AhwBjsBv IcCJ+rdg4zdxBDgCHAGOAEfg3yDAifrf4MyfwhHgCHAEOAIcgd9CgBP1b8HGb+IIcAQ4AhwBjsC/ QYAT9b/BmT+FI8AR4AhwBDgCv4UAJ+rfgo3fxBHgCHAEOAIcgX+DACfqf4MzfwpHgCPAEeAIcAR+ CwFO1L8FG7+JI8AR4AhwBDgC/wYBtSDqyE83sOnMBzRr1xJmKVr8+fFprNx4EpFSCSDSQ+V2vVAj n9m/QY8/hSPAEeAIcAQ4AumMgBoQdSgW9+uMUa+Ko27HlingSMCtffvxODoPxveoAIUCMLfVS2fI ePUcAY4AR4AjwBH4dwhkeKJ+e34XDj2LRqECRkiIJ2CStjghCu6KBOQuXRxmZmYwtrGB9r/Djj+J I8AR4AhwBDgC6Y5AhibquIAbWL3jDbqN6oej518gRp6CqGO88PL6RTx8IULoTSm07HKiZ5ducDHV THfg+AM4AhwBjgBHgCPwLxDIuEQdH4pdq3fDvu0wdHK4jv1nXkNfKwUkEkO0GLoaw0uXhR1pvK8s 649JSw9j7YSmkH0HPW1tbWhqasLQ0BAJCQn/AmP+DI4AR4Aj8NcRkMlkkEqlfB3768hmvAozLFEH 3tuHRZuuoLzUFlN2XsaLxx7YuPMc+raojC9WaJk5ylQ3/4KqnaMDQi8+QFBCU1iIvoL99OlTHDly RPjgwoULCAkJwcKFCxEdHZ3xRoS3iCPAEeAIpAEBsVgMDQ0N5M2bNw1X80vUGYEMS9S62atg4WoH hIRG4LP8FbR1Q2FnZ5lMUo7xuILRs/ej86x5yEfGaV9PX+jnKA6TJCTNBodJz6rJfOvWLWG8XFxc EBkZqc5jx9vOEeAIZGEEJBIJAgMDyYmWvGh5ydQIZFii1jS2R+ny9gL44Tb+2PUIqFomHzQCnmHj iaeo1qApbCzzwy3vISwaPgSWRjrQMLZG/+7Vk/mbsfvt7OyEFyuMqD99+oTatWsLkjUvHAGOAEdA HRFgau+zZ88iLi5OHZvP2/wLCGRYok7aB63cDbFqbk0Ip6O1FHj19g3y+sth62SEpj2nId+dm/CL VMDJtSwcjMQ/7H5sbKwwsSMiIoQXLxwBjgBHQB0RYEQdHx8PkSiFClEdO8Pb/EME1IKopTrGsNdR 9iM2VIz8uRxhZalyF5MhT7GyyMMHmiPAEeAIcAQ4ApkQAbUg6qS4S02zoVE9J5DzNi8cAY4AR4Aj wBHI9AioHVGLNTShrZHpx4V3kCPAEeAIcAQ4AgICakfUfNw4AhwBjgBHgCOQlRDgRJ2VRpv3lSPA EeAIcATUDgFO1Go3ZLzBHAGOAEeAI5CVEOBEnZVGm/eVI8AR4AhwBNQOAU7UajdkvMEcAY4AR4Aj kJUQ4ESdlUab95UjwBHgCHAE1A4BTtRqN2S8wRwBjgBHgCOQlRDgRJ2VRpv3lSPAEeAIcATUDgFO 1Go3ZLzBHAGOAEeAI5CVEOBEnZVGm/eVI8AR4AhwBNQOAU7UajdkvMEcAY4AR4AjkJUQyDREHel5 G/uu+6Je4zow/HGmy6w0vryvHAGOAEeAI6DmCGQSog7Fwn6dMO5DGXg1IaJW80HhzecIcAQ4AhwB joAKgUxB1G8v7Mb+O8FwdTNGQgJ1jedR5zOcI8AR4AhwBDIJAmpP1PLAW1i74w06j+yFs3c+I4YR NS8cAY4AR4AjwBHIJAioN1ErwrB77S7YthqCbpbncfxGAAwkPx4ZbW1taGpqwtDQkKRvzuqZZB7z bnAEshwCUqkU7MXXscw/9GpN1L43d2De+uuorXsQ8/afwuunfth+7AY61S4F7RRjd/jwYXz48AFX r15FcHAwVq1ahaioqMw/wryHHAGOQKZEQCKRCCSdN2/eTNk/3qmvCKg1Ueu5VMCUuRYID4+El4c2 pDJN6OvrIDWnb319fZiamoJJ1JGRkYJEraGhwecCR4AjwBFQSwTEYrGwlnGJWi2H75cardZErWOZ E7Xq5hQ6HOgQgKMfXqBWOVdopgJBxYoVhU9fvHiBT58+oXnz5oJkzQtHgCPAEVBHBJja++zZs4iN jVXH5vM2/wICak3USfupm78plkyNgcFPvL5jYmKEiR0WFkaSePgvQMUv5QhwBDgCGQcBRtRyuRwi ET/mknFGJX1akmmIWtPACrkM0gckXitHgCPAEeAIcAT+XwhkGqL+fwHIn8sR+FcIMMFJIhELNsn4 eH5i4V/hzp/DEfh/I8CJ+v89Avz5HIE0ICAWi4ikRQgNjYWWlpSOGIoRE6MgtWcabuaXcAQ4AmqN ACdqtR4+3visgAAjaX19KdaseYft298iTx4TTJ3qCl1dCXn9xnOyzgqTgPcxSyPAiTpLD3/m6DyL W6OhIYaOjoQkzjhlGNkMVn5V8mV90NOTQiYTC0S8evU7LF/+inolwrVrPhg5MgGzZhWEubkm4uIU 5BgpF9ThaX1ORsQogw0Zbw5HIMMgwIk6wwwFb8jvIMAIh0mW7u5RuEGR6Ro0sBG8YBl5pZW0fuW5 7HlSqUgg0PQqSlu0CKdOfYavbxS8vGKwa9dHehx7JtN1a+DWLV8MGfIQFSuaEUED9erZwMhIRl7A f3+XolAk0EkJRXp1l9fLEeAI/AQBTtR8iqgtAkqpUwJ//1iMHfuIzsj70Rn5CAwbllsg6Z85XDGn LKlULBB9WgsjUD+/GLx7x472pc1ArK0tweHDXrhy5TMUCiYh//w+imVBzwgl8tUk9TYjSfZK+nOV 4N69AOpvJLUnklTiHwkLDar/x0TN+szi/LRu7UwRrfQRHf0zAk4gfKTIkUM/UVPx840AGxcm4bO2 pKWvrE0ZQcJnw2JgIBNs/1FR3KSQ1t8Evy79EeBEnf4YZ/gnqKRETU0JSWSKDOekxIhOueAnJQmR oO5+7RWCQUPvw+NFIH0vw86dLxCqiMWEIflp8Rf9MGoTu9/bOxr793uQxJg2UtHSEuPhwxAiST96 XtoJnrW9Rg1rsjXLfrqBYBMmIUFB11uhbVtHBAbGYvDgB3j9OkjoIyNtDQ0RJk1yRZ061oLkfe2a b+Im4MfTjTmhPXsWSvc+SEH837svQdgANGxoKxDvzwlVQWSnSQGF7MjpTfLTjQN7KtNOsA1T2iJs iQg/hbDBSMN+J02/PdYnmUwkzDHmB1C4sDGKFjUWzCi8cAQyAgKcqDPCKPwf28AWKUY+ERHxePIk CJaWOrCz0xbe/+pCyJye0noPsycz6fRHhdWlIIHv3r1gkirZovn1epUX9PnFITB9ZgRbWAhEzqjc fXccGl+5jphY0gn/oLDnh4XFkvSUAAcHHUFd/rPC8KKcLhg3zpWkTD0ijB8/Q1Ufe5arq5Hgrf0z qVd5j0i4jkmmVlZaWLCgEJH1fbx6FUh1aGDCBFfUrm2FoKBYlCtnhqpVLYX+/6wwQvT1jcbbt2HC RuZHRTWe69d/oAhY3nTpz9X9jPDc3cNpw/SRyO/nRC0WK1C5sjWqV7cUHON+VkSiBJiZaSFfPoM0 bXhYfaxeZhL43txkY8M2bXPnvsSOHa8o1LABFi0qQhoHA4SExKV5Tv+s7fx7jsDvIsCJ+neRywT3 qUia2TinTHmGixc94OhoiPnzi9C/OoJEwaRZtoj9rLBFMCxMnmjL/DEBMBvvunXvSbUb9sPFnxEF k55OnvxM1zESTVqvkpSeoi/ywjxZ894iGI2NNqF0JWPERn+/5UyCk0gSULq0BQoVMkyDGvhrXb+y KVHdFRkppw3Qz5D89ntG1paWWpgzpxAR9EPUr+9AJG0tkDQrTE3LXmkpSulRTJsG47RcLlwzd65r GiRpZXVsI3L2rC+ZIYLp3Y81Dmwe+PvHEKm7C6+0FQVJ+JpE7hY/tZsrN1Uiku4dhI0YU2mnLGze fiXpd/S1FgICosj+fw/z5jGy1ieyZtG/0tY6fhVHID0Q4ESdHqiqSZ1M+mF23LFjnxBJe7JlFh8/ hgmS2/z5hWkxN8SdO0ECoTLp60eLFVOb7979CY8fB9K1TFX9fRDYdxERscid25AuYurpHwGmQOPG tmjTxlGQeFXXJpBklUAkazeE8qSlWOMtLDUwd4krLG01kcCI+oeLrEiQikNDf20x/rkK+O9NAoYX I2sLC03y9C4ieIMHB/9efGeV7T6txM568SskxZzOKlWyIAnZiu78sYTPVM0xMfFEpPaJau+fSfgQ TBSrVr2ljUAItevHG0hGwG/fhpN/gCfZ2VO336s2LqGhMdRethyyNkjx+XMU+vW7i2nTXFGkiNEv beL+3sjzmjgCSgQ4UWfRmcAkQrZIDR/+CNevM7WmKpOYTCDrnj3vomBBI/ougEg1hiRPlvf2x4TK bJldu+ZIg3pXqb5Uqmt/XpJG4kqgtTlejxyVZArIgmWQMa+rFEVTJIFhtBb8KKtagoxUnnEiSCN+ PtX/Jfn+vNfJr2BkySRC5vjG/Aj+ZflVXCIi5GluHusX0978Spk/v2CanNQYUT9/HkqbzQAyI6S+ 0WQaoytXAnDhAtuoMvu/qig3cErTBhenf2V8+LV/H4Gfr15//5m8xgyEwPcceNjizFS1JUqYEPk6 w9j450d/mK2P2VPZJuBnhUnyTEpkJVWJjZ7PSJkRMisJYpKgiXQlERJYbbMW3ptdNIP2x28XeQ0f TRRvWArurd0RZReFGPMY+FX0g0hOi3U8vZhtluoXx/5cpf+zfvzr79Pj+NW/7kPS57F5lppK+kdt SquEz3LusE1Arlz6362OzVl2tG3yZDGOHv2USNbxlAZXRtqLwihZ0oS0F9xO/f+cI/zZXKLOsnOA OSoxx6I5cwqS6ltMqm8vwoJJ1XFkz9MXVN958hgIqknmYZtWqYrZqX+1fKk7kd8ZCccZxEESJYHu R13Ea8bD5qANTG6bCESt+14Xcl16DuPZVKR8OUncvpV9YbvPViBnSTQFQskXKpC7RwsPhOQPEe6L dI4UiFsanrhf/bkv1q92jV+fDgikdS6qtBA/2ggo7dhicg7Mx7aMRNbvyLSgi9mzOUn/6dCxDIUD Bw4kHwCVtu5Pa8w894eEhNBGcBbs7e3T1CkuUacJpsx5EbP5Mo9vFo5yzBjg0iVPImmlM5mzsw55 B8f8kn3yl1FiUjPZmRWaSqlZROpJhYSOHgVrwG6PnUDI1oesv1TrV8EPcgc53Nu5w6e6j0DA9jvt oRGYfCGINY7Fxw4f8WbgG4GoHbY6QCNAA3pv9ZBvLFuQAUbmn1p8EiRun9o+wrOZ3VvQctI/rG5e Mj8CKjJnZD1iRG6SpKWkRTIVNElMkubl9xHw9fWlTX40pk+f/vuVZNI7x48fTybGj5mHqN8+uISP gSLkL1UOFqmYsuIi/PH00QsERjHnGhmcChSFi/mv2bwy6Vz4abfYIsWkZUbWTKJ49cqWVNe6NHm0 f9m56qcPE5iYOJCRIZV43XgoNMjOHCKD4RND4W/b3bYwemAkSLiMfKOto/Gx3Uf4l/cXCDeoWJBw nSRGAnE0HXMign/X851A9kkLk5KZ5C2ozcns+HrAayRoJECTVOIGLwyEzYDjf46wPWArELjzOmeh Ds8mnggqGiSQNpO6mQTOCPsLaXOJO03DrG4Xsd8Bc4JjJhsWLIdJ4Fzd/eejyJwFzczM6MRC2nxR /vyJ6lODhYUFzbe0m94yrkRN7rrnVs/BqpteyGMrwtYjtzFkTH/kNU3e5Ltb52HUtveoUDE3qUJ1 AZu8nKh/Yb6qyFpbW0xShLngWf07Z6h/9Mh4nXiB9MRxYsEuzEiRSblaXlrQ/qQNs6tmX273bOyJ eO14gZQDygQIqmmFlIJbkF1ZGkljn+J4kzTs51NYFkpsTSTLiD2gZIDwrBBX8hqmOm322kAzQBO6 b3WRY34OZTto4faq76W8vnQAAtyoHUzaJ+Jn/zKVfBqOLP/CKPBLMwICzBzEzk0LU+DnbhYZockZ vg0KFgiBl28Q+FVcfr7K/Z9ATohyx7UHAeg6YQWqOdI5345VsORgaazoXCpJi6Lx+EM0ao1aiOEU xYmX30OALUrMSUku/4FzVxqrFiTmRK2xXEdZn8ktE4HgjO5RYJL9ZDcm8mUe25EOSq/s1wNfI7BU oPB5aB6yJRORC5IsI0Qq4pi07zy/20zqo2CPVnl/J0r3n9p+Ukr21B7dd7oCGTtsc4DhY0NB2rfb ZYcYixh41/JGUEkWGQwILEFH0KS08aBNh9A2VjdJ/LxwBDgCHIH0QCDDErVIJyfGrlhIYlAU3O9d xOswQ1TJ75wcA3kIPH1u48rWWfh8SoxsFZujd72S6YETr/NHCDCiJ+cugWAjJV/I0Gmdk2BnNr9A AUkSbb/MHhyeMxxxhnHwrs2OhdFXLNQnETz7VxamlH7TvTBzNJPSEyVy1vaw3CwAC/Bi7AtBimeS tsUpC+i/1ofTJic4bXYS2uZfzh8KLQX8y/rDr5IfxJFixJqQ6YU4W3BM+xftT3eA+AM4ApkDAf9H JzBl/WlItO3QbfhA5DGmxSjkORZMW453eoUwYlgn2JFG8d2t/XgWnQN1y+dPteMPjy7G2lPvoCFV ChByqQmatWuL8EeHISvSGlVym6QbYBmWqFU9jnx/G3OW/YcA3WzIZ5bCezAuhCJnFUGT6k1QxtkA 1/evxLx4HQxpWOC7gEmlUjoTLCG7rJbg6JDVC5NoVXZjFRaMwNjZ41QLfaw6MhVHHuJx4jhBpW1x 1kKQmo1vG8P2jK3yVuK96BLR8O3ki08tPwnXMbszc+Ri9euEJ/ElUGnI/p8Ooqo2sK6TMiDBJAGf u3+GP/lB+HTzEVThtntsYfiIpG1/GSwmUNjShXQdqUzfdHyDaNtowZ7OvNRlCjrjnXgul/Wbk3dW /6X9/f6ztYzZOdMWI/3vP/9f1PjyZQAdrzP97UdFuZ/H2NnbULLzINi/PoAxU+Zh48z+uLJqCTzM 3ZA98BwmrbXH6l5FcPDUHbg0LPPdZ908vRcv4upjXpdqwjW+z45hSqdu+JDgjR6z6mdtotbJVh5L 1pXHlSW9MGLqWuxfNwwGKg7RzokRyxZ/AVb3jTUG7NqPjg0KwDQJz9y+fRubNm0Srrt+/Tqd3w3H xIkTyYHk96I7/fasyWg3kuTHJEqmEk5aGBHHmsYqnagSJWEmMTMVMSMdbU+KBkakVk9UD3Ui6gjq X0Ze7Ht2/QLJAryi/2Ic6fxybjq/HCuCeL1Sfc0ImhG62sSQEM5zK89ws8IkbUVuUpWT3dvS0xKi GBEa0X9VV1YVcGDHwJjK/5zOOeym/1g/o2yiBJJnqnLBzs4LR+AvIMCctczNzSmCoOtfqC3jVTFl ykWKQncJW7a0R8WKZP/8jXL32G6EW5ZDp8qFgUpG2NVkGM68bgDPNxEo2Ls1qvp64vq1ALy9ew5h VhVQNz/LGZB6kWgbwcWlwFe8XV1wbuM6nDojh4FO+koYGXbVkAe9wakrb+FWrwaMCTeXbM6QXAoG k4ENEnGMC3iJ09c+oWy9qsJncrkE2jq6oMRCyUrevHnJm3OY8NmMGTPg4+OD9u3bU2xqpaozKxam 6mWkW7R7UWiFayWDIFYSi6dTniK4SLBAPoxkzC6bQfcDYUte0g7nHYh/yOZM/8UUihFI/W2ft/Bs 5CmQEUVWphQZJGEnel+ryD5T4Jy4cWF2eHlXpQ1eTv9d1roMmyOUE/o+ea2HSlHvYj2Upf9Yca/q jhjLGOEomG9FXwEjIegKFSHoCve3yRRT4193gknUz549y5QCx4wZVzB+/AmCNAFNmmzBoUPtUaZM 2s4cfx0HBXw8Y6FjlnifSBc2lFHnja8m6jUrhBkLeuM8/XYbdSiN01duo2a7Zj+MTs9+sfHyr0f2 Qt9ewdMgEzjkVVAo5rTF2v/dOZJhiVpER2jObZuNix7RaFjIAjcvfUCt1r1gFh2E95/DYe1gT/FP Y3Fi7wI8JL6t6KyLh68+o0LjHkgZh0hXV5dCL5JHOBUTExPyao6giEWOdAQj+HdxU/v7VETtZOQE SXiKM8M05/Sv6+N16dew32cP0+um0H5MUjQBy445BdQLEM4e+0f5w7+kP+L0SP1NhMOOTTHbrSX9 x4hcKGyXlclLPOioGf3n3sodHzp8gDRKCrMbZhBRQghmEihxvoSgSkcISddHowSPdq+GXsIRs4js EYIEzjZNgn1btRFItHMzHJmGQwjwkqQwrYRwPSf5TD67vt89RtTv3r2j8KjqMQk+fQqh5DHJs+Cl 1rv9+19g9Oij9BUL6SqlNK8RFD3uP5KsmyF79rTZgZ2cjCjQSgIio2MRY6ByRqUNspR+f5R0JU/T 3ugdexQ+BnmRS34fx+wLIP7OarTeegl5KrfH0I41QNFlkxVdWQyu7l6Knq8OC59H0JG+xqNmI8/B 6YiM+fVAT78ycTMsUUsMcmLWkiVYuXITBdWXIH+NvmhdKS/kAbewYPkRdOw/HkXsCmDenJl0zVYc fiJG4bp90ax04hGb76DAdj5sYsfFxX3xcv4VwDLLtcyuJZaTE1RCLLTpv5TF7LAZ2IsV30q+8O2g tDMLntw0gdkRKiEwCDmPaQQlV/sw4spqhRGqVJ54fIzI1resr0C6fq5+eN73uUDEdtvtoPNJBzYb bYQXKz41fRBtE41Iu0j41PERxoSd82aOaYzIGdaaXpqwOaG8XlUYcXvXJ2c8FbFnNcB5fwUE1Mk+ 3azZHty8+ZpaTXlif1iUMTGUgTPZjlWLMsVFUO51Zr78WSAitmmhGO8vBiJ3LmOYGWtA60vKOjmi I2UwNWEaRE2UqtOY/g3EivneKFDKGBuWXkbHvj1xYP4S7CteAm1SZJiLlGugaO2WmN6nptB6saYe jHQjMWRnTJojN/7utM2wRM06JDHLiz5jZyXrm0hqiLy5HKCppZTYZOYF0G/czN/tP7/vOwj41PKB ext34YgUO3Mcr0UOUswjm/0O6JWW88tZFlxm+1eFJaVpymzcDL+3/d8Kx7hYGFMmJZtfMoflcUsY 3zOGJqnjXFa5CJ7zHi0pzGmBEITlCBPMCq5DXGFy41tJgo3Nh24kwZOqnReOQEZHYMOG+mRuZFnK fnyU8cCBF2SiPJV4HSPmGOjoaGHNmoZpl6gdlXrVXEVzwG/bHYSSH4mB9ws8IQFlaPav0Q7fnTkA P8uS6GgfiEW+MrgWKoirFFo5MOJbR2OWcldDx0DQyn4psf5gae+19AzTFX61+4XHyw1QrlRJuJj9 bGeVrrhlmsqZRJxaibIlFVGJIMiCZMnONGeajv+rjiQeAxM2lXRWm61RjITZv+yY2vsu7wXnOpv9 NgLhGjw3+BJ4hZ3XZnZtFq0ttaLtrf1NVLZ/1S3+HI7AryKQJ0/yvPHfu79ECVtBQp05k5E1yxin j717W6FGjey/+khkq9wFta+MQqeeI2AZ6oOy7UainEOiBjD4DbZfcUeN7u2gbRGB+hUPoV/XntCx ckX7PN86lUmktBam3GNINMki6I/9i8fg00Gl95RBDjf0bl8fFI32r5W/WNVfa9MPK9IwtUY+evHy hwgwjRJNusCSgdD0T66KYmeCvRp4QfOz5jce4X/4VH47MxckBnJRCRbseBzTXjDPcrYxYuNhct0E NodtoPGQFpXvmCCZ+pudR2eWBuahL3jTs41BCi9+DjpHQN0QmDGjCiVLkeDatefo37/qb5G00GeZ GQXNmoOi919CoWONovkcvkKhbYH2fQfAzoyp2Y3QY9AMFH/pDpschWGl/63U33TICtSVqFyZE6uR mGD44oNw96JNNUV1ZEXD0BJ0LPuvFrUj6r/a+yxcmSoJxbOJz5RZqJIWWuyZTVU4S/1jLVUWRvAv dF3lMMYCvSSGOWWqb3bWnMUdZypyVkq2KCkkFElZzM+bo1iHYoJU/aHzByGdJ4uYxtTljNy/OJz9 habyKjgC/xqBiRMr0iPZ6w+L1AiFi6cSCEvTAPZJZRRdMxQp8jWcccqn6ptYfeOozBZII6tswis9 Cyfq9ERXDepmntqplkSJWw26kHmayPZFJBWzs9msqJKNMC/y1Ao7k82c2ExumsDinIVg9w7PFQ6P Jh6ChM2yiPlWIae2xHSgqsArwjN4yNPMM294TzI9ApyoM/0Q/6SDPNxlhp0BQiIQCiLzse1HOK13 StZOuaEcTyc+FWKkG981ht5rPYGcndY6IffM3MrMX6RiZwFYWGGJUd71eCdI23Jt8n4lT3OmIk8m dfO5kGHnAm9Y1kaAE3XWHn/e+4yMADNB0Pl0dubatypJxkmK4ElOqUJZ9rFIx0jBMY2pu1lAFRZM hUVQs99tD71XekLAGiZ1F+1aVKghPHs4vOt4C8QuJByhv7+URFMHk7iFYCzc9JGRZwhvWxZBIB2J mvL7un+CoY0D9Ogpn948QXC0DNnz50rl1G4WQZt3kyPwqwgk+gswiTg5UydmFWPnrSl6nCrDGAs4 ozpbzTzKmfqcqcT1X+kLoV9ZcJtsK7MJSUYY2bO8344bHQXbNjuXHVAqQJDEmb07wjlCONf9JcIc NUCIqMYl718dRX49R+CPEEgnoo7AkUV90GP2c6y9fAG29yahegfKcEVHgar2moLVs0fB+VvfmD/q CL+ZI5BpEWCe3Gm0KSf1+P5ylpvuj7aioCr2kQLRCnm+6T9G4jb7bKDlrQUddx1kX5RdeLHCVOOf q3wWos2xYCwsT7ggqRPpC0lZEjcQqjSfmRZ73jGOQAZAIF2IOvLdZUyasgVVx51BeYuPaDtoFmzb LMWRxjI0ajwEC4vXxKJOhTNA93kTOAJZAAESgoXc2UyVTUVIMsKYloT0T60T83FT7m2mJmffsWA2 2VZkExzU2Hu7T3Zw2kgSOBE7U8OzEKgsaho74x2WK0w4IcCkcNUmQXVMLAsgy7vIEfgnCKQLUX9+ ex+BASXRrXdFiO7NwQlPC0xv0xrFKmijnsU8fHr6ljrHifqfjDB/CEcgBQICkSYWIcIcyxBGJKxy PGNf3S12V5n+lC61PmotqMh13+rCeY2z8GKFnbcPcAsQ/nZv545oy2iBtFkaUxaJjUngwgaBhULl tm4+DzkCv41AuhC1TJMiJsEH4aEJuH78KKLN7VGygDEQfBrXfH3gavH7+UV/u6f8xkyMAMmHCTLK YEM2WEkURKKfB/7PxGD8etcSj4V9CcTCakhCrCz4DVN3M1L/0OmDQOoaIRpwXukMHQ8d6L/Qh9Vx K8Fpjd3n2dATIQVDBLs5c1wLLRAqELhA2Kqz44ke57/eWH4HRyDrIZAuRG3pWgUVy89Bz/JFEP78 IaoP24jCsrtoV7QtnlsXx5xWblkPad7jdEMgPl4XBgbPYG+/FW/f9kFMjBnE4vTNZpNunckoFSdx GFPFdWdq8Cj7KIFsmQ37/rL7AjmzXOSGj5X5yBlp2+22g/0ue8GuzpzgggsFCyr0993eI8YsRnBQ Y/+yI2bsGsGWrjq3zx3VMsoMyBztUMTh1OpJ2PEoBNLYWFTpMQEtittAEfAAMyYuxTvdgpSpqyey Gcjw4sp2PIvNh8aVU8/vfXvvDKw48RG6WiySGRAnMkDjtu0R8Xg/NEt2Re383w+W8qdgpgtRy4wK YNn6regzahEiSrXEzOntoRVwDRZlu+D0uFEob588//GfdoLfn5URYKKfCJaWJ+h1mqRqPTx9OpFS 3AUmFwuzMkR/qe9Jg7GwKgVHMjoVFpEtAqF56bw2S/ZFtuqPHT4KXuSyQBmc1zkLZMzydBfvUFwg bFa863kjLG+YkI3tc43Pgppd8ChnQnlirm4WGU+we3O1+V8awaxXzcPdEzB2+W2M3bwKRo9WodfA wbDbsxzBm1cjPHdduPkfxZS1p7G+X1EcOf8M+VrU+C5I9y6fhI9+MyztW0u4xu/ZEYzv2R2vFQHo 79watdMR3nQhatZe7WwVsX5Xxa9NtyiNeetLp2NXeNVZDwERpSrVhba2F2xsDgndNzO7AH39FwgJ KUSxgv1IDa461sRFtXSZH8xRLcnxMEa4LCIaI9s4gzg8mvNIyGGu/1wfem+UZ7oNHhvAbq8dLM5Y QBohheNmR6FpLHb5u54UlIVs34zcoxyiEGsU+zVXt6oD6TqUql1Buj4kXYYiU1T6hnrRN5We1P3O 5z/ptFXhxli7fwhcs5G5tdAkNNnXEBfvvYTBx2jk7lobVXyf4/ztMLy+eZa0RVVQM+f3811LtQ1h Z5UdLi4uwlNdXLqg+LKlOHUqDnrayVP9/u2xSDei/tsN/W59sZ+xY8M6vAuQonyz7iibw+ifPZo/ 6P+BAKlT45UamYQEMUnO/siXbxzZpiOFzzQ0guDktIHS6eWBr28lUoNbEVnL6VrlVBeLY4T3XExL n7FjBC3EiBcQTgyaQpzHPMTZuWwmHTMHNPe27kJQFkbYjMDjNeNhes0URXoW+dIw38q+CM8Rjjjj OHjV9/ryuRBalQnaLCgLk+r/osStUEhprkhoPrF0jJys02eW/KBWBvvJVL5PkkvjV9pkmbMYLBNv CLm3E8c/xWCKqyuy6xTCpLndcFKsiebdyuLUzTuo16ElRepjueBTz6jBpllcTCTi4pgPDM3jF6fw KNgS2QtRtL/4FHEOfqWRabg2/YhaEY4zm+dhzNRN8I1nE16MMk2HY/aEbrDR+zupRRJivTGv5wA8 c6qBpgVisGziGERMmoUa2fkh7TSMvdpcwgiZrcZySnHKiJZJzNraHnB2XksLaji0tJJH7bKyOgH2 cnZeQz8qQ4SH58THj+0Egg4Pz4HYWHP6OxZSKREHLcYi5t3MF+X0mw8ppG5GrMyezYqgJmdBWYi0 WeIRbQ9twWOc5ei23WcLwyeGQq5ux00kddMwMY/yt73eIs4oTgiHypzVkgVlYasp4/Eknu1p6xid EVdooFChAQgMLEbzpT0n67QBl/arXtClZCr5YWHXpFaC6MM7aX8U8tO1SSysYc8OosGgVSjTfy5q 2OtCZN8TwyQX4aefA5YBV/DBsQBCLi9Gsx3XkbNcS4zs0Qj6SlP0l6Iri8H1/avQ581x4bMocmBt P3ku7m0bh6iY9PWJSR+iTgjFlnGt0W76BdTt1ANVrChFCRH3yf96o+zjRzi1axmyp8gW9gtD8OXS BHk0HMo0QosOrWBPPbm1rxwOX31BRF3sd6rj92QoBJgnt/SLJzeTmJ2c1lMC+U+wsDgjtDQ0NA9k suBUWx0Wlhv+/mVosY2Gnd0emJufF64LDi5MZJ2dyNoEnz61pE+UC7RCwdLokGezlEnmXJJK16nA iDQxFafKUY1BzqKhscxhTH3Ojop9avVJIHHrQ9ZCQBYWdc38rDkKDikoNC/GMgZ+FfwEqTrSIRIe zTyUgWHof0yNzv794m3+PambnqsgaT6O8iJZ6V6BsfEdet2CT2BVREdbQhpP0tNflNjTFdeMXnlH auDN32zkHrqPvdJantOFuZUXe93cgs5jV6Fc3+WY0qxQYg0acC1fjf72xZJ5fnAtbYJNC+5iwJgR 2D1lBvaVKY8OhZOfToqM00SpBu2xaIDSGi3W0IamJAjX1scK+bPTs6QLUQc9PYGJs4+i+viDODyp /pf2j+5YFkVL9cGCnR2xrFvxP+6XWMcZzbs4IyHgNbZuWo1rkfkxo/ZX1VlqD5BIJCSViWlBlgov XjIWAkyrxCRouVyPSDiUJONLyJZtLUnNLOVjKKKi8sHTswu8vOoL0nLx4h3oc+Y4lrxokMTm5dVF 8AD39W1CUrMIhoaPiLR3kjT+iOzXL8nGtEtQc/r41ERAQFki6zj4+ZUSiJupPpn0zlZpNk3odl7S GwEmZFOGTqEwvJkihT773JKczYiwmYOaTwsfaARrCGlBXVa4wPy+uXCdzUEbZNuWTZCkmW38fY/3 iNOLRZhFFEJzUihUlraVvpNEiYUxj1coxS127EzvrQYMAkUUlIkxAWuECDkT9uP1p4lQZKeIbHRv Rixs/WLzWm3KTmopHRr4YXlK3zZN5Ypm9NnkX+ip0oyMoHt70W/8KjSeuBfdy1h8U8HLYwcQYlcG ZRz8MD9YDEdHR+hL6FhhjFK9nbTEx9PmT6pB64f2149jyY9CroBMO321uOnCVCHe7gijPlWuWTlZ R/VyV0E5Q0N4vvxIn/85Uasqj4oMg5/IHDks4/Di8UsUrZwn2XMjIiJoIVYGZggKCiL7ZRg8PDxI IlNmFuLl/40AU2vrETGKYG0tpR9CABwc/oOu7kci6ydEpJo0Xs0QGelIUnI5uk65gxWLA4mI6xCR hn3TgYiIbCQ9+9I1n4iombTMFrTCuH27iLBQMw9xTU1fktA9YGu7hSTuLTAhPxJb21IkxeuQ+rMU Pn+uLpzL9iLzqJwJaKQ6ZxJ3guCVnM5b6P/3kGTA5zObNyPWBE3Cnvj5yQRa1RODslidIOnX2why DYkQoEV/tD0koLPeFgoE1XwnBF6Jto7Cx6b+MNJ+Cavsu8ihIVaQpg2H94XeDkpY0v9aYq8TYK5/ GS/DrsPdQxdSuWr3kLFAYUQdHU1Z0NSFrJU+gz8u7KeVGuexexMl5J9V8fV7BU7uXY+7PtrIfnQB hu6NoW2YPur3GICKuejHHvQKe+76onb3otA0i0TzascwoHsvGDuXQvd835K6JpGxjkYKypRowVQj DIcWj8T7vfrCow1zlcWALo1h9BfZ9S9W9RUes+yusKf4Jv8tXYWuJYfANHFD+mD7DOz09sfgMkrV 1d8qOvZFMHBQETxePwC9Vu1CrcoTkNR379mzZ9i0aZPwuJs3b4IR94YNG0j9mTF/gH8Ll4xcDwtQ wgiPqZyZZ7aFxVlSOYZj4sQEIuhI4fOgoCLYubM8Tp7UoQVJRqT7gYiTbbm/EqVcri9I4CmLWPyS SPV+Iqmqvv3q0cs2BgkJTHK2Jmm9vHBBhw4JcHOLJIc0D+TOPR05c84T7p88WUKkLaKNgr1A4Iyw xWK241YI9m1lgBVe0gMBtqlir+RFTPODDIiCb4GyxOpIYGhxH3qGL6DVVFMIzmIMe0xyKwGdentp V0eSMnmcO1jHQsI0JXcppvk7ErvYlHhH9c+fkPwReT7gwZUeOLOpFkRi5iiU8TZmTDNobm6OkiVL pgf0/586mSTMPL9TliRCbNobJkJdiuFRtgcF3QmjDbZwoxRWtkpChZ4tug8YBHMDNr/00b7/TLh9 9Ia5Q04YpXKCuOmwVWggTtEQiQmGLz2Gz37BiIpT+l1I9Uygm3LKpr3RqV6ZLkSt51wZi+YNRpOe o1Hs0R4ibfpRJUTj5YMHKN1zLgbVy/GHzVbeHuN1A7OXnULLCeORg7zj4xM0YW5mASY/JS3Fixcn FalSgh8zZgzZJj9h1KhRdIQn5K+0g1eSdgTYcSpG0lpaXoK0yjy0dXXfk3T7mSoxJCLMjffvGwjS c0iIK3LliiWvbkW6BTBhRMzawwrbt929y8wiEbQAnhMIwsLiHCZNukXfsh/hW2qXEf0rhrt7W8HW zUpUlB39P+V/pv4waT/pRiLtyGS1K5OqbMmZjLytWeCapIXhz7z4mWe/qihIZW1g8IRMGLuSYE2j Q+YKHZ33wtgoSZWNw2v6/xf45NmGxs2J1N6kiflIR8WeGsFqYHvggyUYB0srngbqHPlmAPp2E6Fs 8ZZ0r3PiszLWGDGJ+sKFC4JUnWkK+ymq3LT/uFMi6BmZC69Ui0wX5kkdxjT1kSNnIomncoO2nlGq mR91ja3hQq/0LOlC1GzXUqbTPDwpUQOzFuyAf6LXd6tBq9GrcaG/1h8NUxdYit5g6rBxKOhoAD9/ LfTt0wLJf+7JHycnHWY8udLHxMQIL17SFwGl5My2l0x6lhHxnSLV9ifBVqyl5SMsrL6+lckM0Z9U zI0ECZbZnpkTGFugle/Tt40UZ0t4ANMgytiekiR0H586wr9M1f7yZbRgs3Z03Cio2ZnXee7cvYQ+ xcSY08avhaB+ZM5rYWE5hUVdpY1k0rfyOFjWLMwhUHU07isCbHP09Z1y4/aZzB7/CRsypWmBka82 aVlu0tn4y0nAU2pTIiKy05xxEbz3lWNHDmihZfHhQyeaLybJMI+NNRaIXCQitTnd7iuWwH3BRyh0 XkH6zhr5TY/CQPtb42kCuShrajyizaNjogd4xhpDto4p2HEiXjI9AulC1PKoYHzy8IfIIB+Gz5zN Vj4BSHYG7dXLl9A3s4O16Y/oNG24izQt0H3qcuQ/cQpe4Qmo0aoO8lnzqGdpQy+9rlIusvHxmkKU MEbKjNxsbffSonsXenpvyN6rL0jML18OIynWlGzJRQRyYxIpW4RlMpWm4//jKMMWdJXdm5E1s1nL 5Tp4/nxMouTmLpA1K8wT3cFhi9BmJ6fVgnTNPMrfveshqO9jYixI4rFJtG+HCWShLBlPlZr2GcGI 9uvYMJJMXSKWkqbEh+aA55eqmUSscupTmg9YXRLCj0nOgQJ2qo2Nsl4NvHo1OFGqVW2sRaRtKZCI a/JdHDsdoDxu97WwTZ9ybiUWsoHK2VlsKuElyYfhdH0YVGj0Tfffd/aEZ247yCTsGB8vHIH/HwLp QtTet/5DhYr98Yn6JZFpQENKdibyqI0WzppJ0GH6MWwcVf0v9VoPpWs2/kt18Wp+DwHVUSotwd7M JCgTk1swMronqI51dd8J1fr41CbpuQo5hjUXFmCWRINdrwz3mTGLkliZLZo5rzHnwwRB4vf3V9q1 g4KKCf1lfbSxOSh8Zml5CsWKdRH+ZsfEAgJYbHuRcByMbVJYHUy7wAhFLGbOQMwG+v/ZlPwYdSVR qkwD7FpG0Ky9SWOpx8fLBDK2sTmQaLtXbda0aHN2m4j58TePYf4H7Hy7MgANmz8S8rivJJxhZsSa tLB5otTKfCVgpuHQ0PD7PdzY8bDE/N5i8i+QPM4HXLL5po0R5T9C5EoG0+h0WSYz5oTnrcqQCKTL DNQwtIajkRifghWwKFofI1uXh4aOPcpWKQx9+g3r6Kdf8PIMiXKmbJRSqmIkxQKRMA9qJi2bmNwg FeZRISAJI6XoaCs8fjxHOJMaGppXuF4prVLeY+nPoh9kROAoGhZJgkppUKkmZxJgRIQLXrwYIxAK 24iwvjE7vIvLaoG4GZExrQKLqhYUVJyOmDUS1KnMDs9Us4ywlNHVGBGyzUFqEneCIN2zZ/9ZhjA2 bkkd8FQbLZ1kgDMpWUfHXfAhUBXWfiOjB2S62J0o+aok4hBBao2KomQcX5zrGNFr4tmzSSQRO3yx 87J58zXwzFezANu0MExSOgcqiTs1PP58cyOlPNzeDT8gsJz3N5ONnemWhP9lr6CMOKV5mzI8AulC 1JaFmmLHuaPYTUHOIz0fYOHsmRDp58Erj7IwEBugSqvOMP9+SNUMD1pWbqBSFUyRfQTP51gi57dE zIfIwee54OTDyufP1cje3ECQoJkNV7XIqiKBZSb8VKpsZitVOpJRhilSfzPCZhsTP7+KRFZagp2V 4cMInNnnra2VzkuBgSWFzUxEhBORd2OBhBkZK22q8V9Co7J62efMO55J6QzXr3HMv4eokihZXV8L 22gwM4My5Cor7HumEWDk+9UZjpkvmER8l8iaHadMXpj0q7THM4lYuWHx9y9LG4+CgpYgaVHaqJMf aWPP+Z5EnFJ1nZ7zhUnWseaxQjawlIUd6VIFUEnPNvC6OQI/QyBdiJo91LZwTQykF2WnhYnTboT7 P8bkiZPAZKkPhqVQrj9P0PGzwfm337MY2tqJjlDJ8zkrHYLY97rCAm9mdkmQtJhzFfPKZfexRfvZ s4nCQh0dbSFI0yxgicru/G/78v98GiPCr06KDDemQQgIKC3EHmcqYyZNs6NhjLwtLY8TgQcIanNn 53UC4Xl6NiWSz0+4agj3qaRsqTRYCJsaGpoPjx7NIi1GYKIqWqk6Zn4ByQlSgzZSr8ie/pI+Vkqk SvK9L6ipVUTP7mUbCDaOERFJPZwThHF8+HCBICkrSVzpcsLeMxPAV5s7Mw1EC31Nar9m16u0D9+O yp9LxH880tQERsYS+Xck5wzQxD/uI69A7RFIF6JWUICAe4dWYcWhu2Tf8celm48hMymJeQcPw5pc 4vO7/b1gJ2o/AhmiA0pphx15YfZU5gClsjUzKY55X7MFmB2lYgTNnIEYebNr/fwqCI49TMpjpKw6 V5yR7c7/EnKVdMg2OCrVdlSUMsMA8xZ3d28tYG1peVLAz9DwibABYoWRIMOYYe3h0VQgUyb5Ms2E mdlV4cgR2xQoJeL3lI97W6LqWOU1rSnYhzU0AgQiV5EqI1Km8QgPz/1F+mUbhKCgErQJYOOY8jSE 8rx40sLU26ze1Gzr/1Ii/pdjyZ/FEfh/IZAuRO19azNaNulPp04Bk8J1MaxnH8g0DGCUEI/4WJIu fALgZGT1/+ozf24KBOLi9AWnr5w55xJ5tCLJeELi8Sg/Qa3t7Lz+y2IfEFCKvHCHkHq7hqBWjY01 EoiDSda8pAUB5kCWkghFwnEwZhP29g6nc+Td6G8JeZNvE4iZ2bdZsggWpIUVdua8SJFegkMaq4uR MJNamTpc5aDFrmMSMNtAsSNLUVG2XyRi9h27Vnlu+evxHrZRUI5jSjHyex7qXNxMy4jzazgCf4pA uhC1SELnZa1tEEPe3vFeNzFn9jVaTCjwfWwcFBSUpP2UPSiamxP1nw7e37lfLJCyg8NWoTqW8IIl u2AOUMz+rKXlTZJWUTpKNZRU2tbCUSql5MwcmhScoP/KIDDHOmUYVCbZxsQokwG8fj1I8LhmEnfB ggMFk4OqMLX4u3e9hONMyrPHYsExjTm1pVQ1KzcGyc/bMh8DdiQq9aLOR8f+yoDwSjIRAhEBXvjo 5YsYOc1rLSPkzukMbbJ0eL58ghBNa+R1Uv7eEqKCEBQtgYlx6hmjYkJ98cnLD2EUOIcVibYpCuR2 QEyIP2I1jWCglS50KjwrXWq2Lt4WF963FKxiCd+kFSF7kDRF/rBMNCnUqyvMBskclM6RJ+9Doema mn4UCWy84BAVGFicHIQqCIE8mHpV6QDEokRxSSq9xpltflQqaka4SqKmI0RJzwGzRYI2V0yT8fZt 3y/H25iNmI9Peo0Mr1c9EfDH8r49cVnDCbksyIfD2hWDnZ3he3s9xs87Tul89NFi2AS0LWGHw9sX wdO8IXrVK5RqVw8t6IoZlzVQpbCz8H3QZw8YO5ZFlMcx5OmwEn0q2qcbROlC1CKK/KOhyY81pNuo /aWKlSrTWMHbN6nEFRdnhCdPpglxrVkaSeWxGZVXLCfpvwR/mqph6m17+13CeeSkhZG5s/NqGiO3 RLuyKqAHH580AcsvUgME2CmSHfQaSa/fzE4V+A7PxXkwc9Ms5P3S42DMW3UaZQetQbnPCzHi4BXU d86He97m6NAmdZJmtwZHKFCsYS/M6VtFWVPEQ7Qs0wz7/KRY0iV9+S5diFoNZgBvIiHAHMXMzS99 QwJSaYigZmUe3CklOQ7cv0OAOX2JxYyAxYKdOWVRHuViSU2ybojSfzca/En/HoF59MiN9CpGr4a/ 9fjwT+/gH3YXq8ZMgKGmHup17ofidpowMdOE54dneBcUihwORrhz6gJsKzaDc8pEEUmeKpZIIUm6 D9ZlETYpANJrpvFK3w0yJ+rfGn71v0l1JCdbtsXfdIZ57bKjQuysLEs8kTJSlPr3Xj16oPKedndv I3h+p1aYbTvp2Wf16BlvJUfgZwg8pwv2J1407beJ2j84Cua6eVGhRmWYhn/ArmXTIRoyHi0Hdca4 kYuwybAYxnfSxoFrxmhbUY6jR47ApUgV5LH5Nl2XJvmCvL5zDgcOKP1JfF9dho9VHTSs9jgx6ubP +vT733Oi/n3s1PpOlS2URdFSnY9N2iEmrbFMV0lDRap1h9W48T+P4Ja+u3k1ho43PUMhMJFa8yoN LWIR8lg2PVXM/wf0dw96Me1SWrVHTBq3hlOFTlhHL2Upg/t7m2D30Yco1qE85m5mYYATcPK/JbDP WRBH1k/DHU9KtHPwEkZOmwZXi+S+VBJKlRrq701Onq+F2kTGJbBweVUs6d+cHNXSNzkKJ+o0TJvM eQkLkiGm87ktvgnZqOovI4g/C1WZOZHjveIIcAR+BwEWpvXDT25koW1Zwht2Rl9VGDmvphfFZEfq HtnfVqoM8ev1/Aa8EpxQLC87ZUTJdsR60KTTSKoS7XEDt/wM0KygP0ZeisemUyuxuHUHnH3tR0Sd PP57ZJwGitVuj2G9Kn59nMIHYTEUKptyWqRn4USdnuiqQd2qY0HfbyqX1tRgGHkTOQJqgMCqNLZx GF03N5Vrl9FnFdJYh/Ky0NfnMXGvJ8aP7AuDyLfwMLBB9bK5lF/GhePI7uOwKtUTuR28YWQahkP7 D+JDXALqmHzrvBYTFUIBiJJuIKgOOvIVHfoZb188wQtLpQZAqmsMRztLyP7i0pmhiToh7AN2bz0M Hzq25lK6HuoWc/pmkEI9HuHQ4csIjKMMRCJtFK/dDG7ZjH5pMPnFHAGOAEeAI5ARELj/HZJmbetO LxYON+0ld/2RmKqxDOtXrYSYzjq3HjwZJWwT7c9hXgi1LYJGRUhy1rLB8G61sWTPWRRtMxgNc38r uRco1wja+tmSP1xmhJq1auD048NY+VyZ6MYwdzkM6toERn+RXf9iVWkHLy1XKqLeYHSLZnho3QQd SgGTBrTDi5FrMLRe7mS339q6BptvaKBrq5JkbaBQivxYWFrg5ddwBDgCHIEMiIALtek4vVI77vQD l+zv9kSEQjX7YjFLO5GymORE5+Y5v3yat0pHrKDX90q5pv1RLuWXJBw26rcA32Yz/7vQZlyijohE tpo90atXDziSTd8l2gdDdx+lw+i5wQIfKksUXoeLUblrHzSvwwaYl7QiwOLQaGgo6HiPiIKZKHU0 7H1cnFhIuqB6H0sZhHjhCHAEOAL/BgFDekxqrPpvnp5Rn5JhiVpq5opu/V2/4Pb87WvoGRVJHkot xhdvH5/D9WeReHdQBKui1TC4Y1MYaX7fOCAWs/zBFB1NIhFeWbWIxQkUr1sTpqYswhXDS0RxpjUp tncMeXtTwBqNOErcoE3fs3SWWRUl3m+OQMZFgK1fbC3jJfMjkGGJOin0lzcOxfgHRti6vjmSKz9E KFZ1IBrVqIei9gY4tWQwJq01wbw+VShExNcSExNDMZAjhA8iIyMplnIMRXQKpIhOoZl/hL/TQ0ND OVasKEKhQyUYPPg+4ROP2bNLo0QJf3Tq9AzHjuXB5s22mD//siBhfxMJNssixzvOEcgYCEilUtKA sZj7nKwzxoikXysyOFHH4dzKwRh8KAQrVq1HWZevSm8BEk0HtOzb5Qs6BXI7Yu1/5+Hfuwoskszd hw8fYv369cJ1N2/epCAe4ViyZAklNFAGV8+KRSpNIHKOxunTrXD9+lGUK3eIEm/kouxZ3rhx4xhu 326KHDmeEG6rScIWcaLOipOE9zlDI8C0g5aWlihWjEXu4iUzI5CBiToeZ1cMwtxbmti+YzPypHJ8 LsbrFpZtuYHmw/rDjog5PDACOtbZYJBig1miRAmSFEsI4zhy5Eg6O+yB4cOHU4hM1YH6zDzE3+tb AuWWlmPlyg9Yu7YHbGyqoEABI3z86ERZmSqgTBl/zJwZQOaBoUTUXPedFWcI73PGRoBJ1JcvX6as dqo4/Bm7vbx1v49AhiXqsIfb0XPcVpTsORP3D6zHlRg5bPJUQKVCBrhx5y0KuZWFkaE1EkJvY87k BchnrYtA/wS06VgDWj/Ag2XzSvr6fejU/86oKDH69HlDZJyAefOyU0pLBf3oxYKdeuHCh5QHOZ7e SykxR3wysmYOaEzK5hq39J0DzNzANB/Mn0Dl5CeTKSMgsffsOzZ2fDzSdxwyau3fZibMqC3l7fpT BDIsUUssi2He6jWIjIpEVGw8LUoyIfC5mBKTHTt9BnpOJVHCyR5DJizAyf1H4BWRgMqthqGEc9oi 16jI+k8BVOf72QIfFibFwIGv4Ourgf37bYXuhIRI0a9fYTIRMGcVkKQdipYt3clUoHS+MzKKpdSY MQJBqAqrhyWRUBVu0/7zmcEIOjhYJuBsaRlNvhUSCrigjIBkbh5D78Xw9NQSvPXNzGKTjcefP53X kNER4ESd0Ufo77UvwxK1jlVu1G+c/Mw067bc9yny5XaGiUli02VmqNG8499DJIvVZGAgx4kTVjhz xvJLzyMjJQIBFCsWTE53MmzbZi+8VMXVNQRVq/pSzmqJYLtmkneDBl7Q1ZWnShbs+BcjFS6B/9rk YmOzerULjhyxxvLl91C8eBBGjcov4L1o0QMy4xTBvXtGmDz5KWxto8lRMuueYvg1ZPnVHAH1QiDD EvV3YdSxR53qpjBNaYhWL9z/761lBGtkFIezZy0wZIgrqlX7LBzH0teXk/ZCgVev9AUpOl++UFy5 YkaOZ0wFrhAkulWrXMiu7SQQL1O/ss927LCHpma8cCbbzi4K3bq9F1S2TMo2NIxD9uzhX0icnc1m JK/KDsXAUJ3lTgswKpUwa2t4uJQkfbHwbF3deNIGyKgukP09XmhvaGjywPppqT+jXBMRIUHDhl4C /t26FcWuXTcFkg4NlWL06Py4eNEMU6Y8I0dAfwEHXjgCHIHvIxDqHwSZkRG0heOotOaEeeDa/Xcw ss+H/M6myhvlobh7+yl0HF0pg5bSeTnS7yPCNaxgYZhawBVa/z69wHvPQESS5pcVTaucKJnTCp89 PaBnYQfdv7AEqd2vW6pnAAt68fJnCDBSY5I0k9BKlAjEnDmP0LZtCYG8p059QiRdEv37F8LBg9dR tGgwPSxBIGZGqJUr+33xAtfSIqe/s5aCZMcKI/mjR63piNdXT1QTk1jUqeNDdlWlXbtIkSBUqOAv 2MNZYZ8xYlURN3sGI/LvFabq9fHRImnTGc2be8DePgoPHhgKhMbeMzXxxYvmePLEkPrknuiTkLGO sKgCzrC+fK+wTU7evKHYsOE2+vYtTK9Cgh/B8+f6gvZiyZIHqFnTR1CPM/zYhkWF8Z/NDn43RyBz IfD2zHL0H/UY0y4vQyEiarn3Y0yavgBhRrYIf7cVVQaPQ6uitji5dgrWXvFHvNQQQybNQBm7ECxZ uRzFmo1GldSIWh6I2QMb4552NZRyZsFagOdvNiOfiw0evX2GAfN3oaLNnzvjqh1RZ67p8//rDZOE X77UR9my/pgx4wlJu2Ii7CCULh0gSMJz5z7C7t12RJhiIeBJUpsz+16lxmZ20+rVPxMRs8w4EO5t 0sRTkGQZ8TKnM6a+PXvWnHwMKJYc1bd9uz2RaYxAKqxeJhn36vVOkLzZ9WwTwchc9Qz2WVLilsmY c5UI//3niIcPjegI2R1S1WuTlO+M9u3dadNgLGwycuUKQ8eOH37reBl7NutLWovKBMDalpbCNjQf P+qSh73uD4++sXr19OLRuvUnUnHnEUwIrNStS0kEaFN1/DjLCqTc7OTIESZoM1J66TOVeFJ/AlX7 UvssLW3n13AE0guBGzeAw4cByjKJW7dA8RyAiROVLxKGyZ/mF58cF4LTW+Zj6JydCI4rCakG+/0o cHLzbHwyb4yN4xvB+/R8dFi+DpVnNMXRU0GYuGUDHsxsh8O338L282PE2VRF+dxKEv6mKGIQKbFC 476T0asUNZBK/NN9KFK+A9ydq2LUX8rMwYn6F8c9s1zOHMa6dHkvqK7Zgs3Uqew9W/CZ+pg5K/Xp 81aQ0lI6hqVUUzMVbdLYvEzCFYsjv0C1dOkDoQ72LPYc5rQWHa1UfTMJ8fRpC0GyT1oY+atU54xw Gzf2FAhIFXylUKEQ7Nx5g5zeCgnSZuXKvgLR375thAkT8oHZ0efPfyhoAFif2GYgrYW1i20MIiPT /vNgmoV9++xok2AoqPt/Zo9nqvr7943o3DrLvfvjwnBg2CUN57pnjx09z1bw/laVbNkiyFQRIjid scJMAJqaCkGrYGUVnexaVifDK2U72aaIEfvP2v+zNvPvOQK/gwDbzE+fDtrIg46esbUItBGnXA+T QEdqf6PG+GgEazlj0YKp2Lj+FiJYSmvdUDx6Gob8TQsKFVrnLwpDzx14I9eAjVkc7ly7CV9ypM1O 15275oGqHVrhR9prsSS5xCwxM4W2JI5+h+T8/JcUeWlfiX4DI35LxkVApcaOjVVKtey9igjZ34wA fnexVkl9qt6r6qEgSgJxdO2q3BCwwo4X1avnhaAgjUSbtwJbtzrg2TMDgcgZ6Z08aYl165wF4mH3 MVU9k+BZXUwNz+zjjx4ZEpGJiPALCN8vWPBQkETZZ35+mrh0ySzNdnBmB752zVR4LtvEpAUHRnzM js/IUmWr/9HoM8xNTOIwdOgDQXX/vZjqrI/s2gkT8uLtWz2BXL29tYRNzMyZT5AnT6iw6WGS+ebN joKWRNVeplZn748dsyLbtkLAjxVWH/MSZ+PA7PhJN142NlGC0xoj7KSFzQflnEiuMVDNmYw703nL 1AmB4sWBTZtAGravrWaEvXx58s/S3CctSzRr1RH4fBHLo2izLnBqGHwjxLDRSaRfmSbN60AEyF3Q pWddjFiwDOZuLVFD4z2O2xSHw6dL2HYiEOXqNYC9XgrmFcugIQ/AlQMbofdaaed+eecGXJv0gJW/ NyJi2e/lz9maE3WaRzzzXZhSUv7Z+99FIGm9jPiYxK4q7Dum6jYw+CqBjxz5UiAE1Wbi1ClLwQ7L pEp274YNjgLxssIkckZIST2e2VGxIUMKCmp2DY0EgdgYkTFSSqu6l6n7W7b8BEdHFnI2bTYmZieu UcNHaJOKFH+GGWtP0mNtSa9nZMy+nzIlDx4/NqTF6j4OHbKBsXGs0OfZs3PSZw+QM2cYnX2PJru/ X7LHMZJn9z18aPiFjBmmGhrxZNawF+pVjY0Sa+VGyM0tUDAtqEid4V6jxmcKghPwje+AhUW00N+U c+erw2ByBPixvZ/NiMz7/eDBZL99/uP+sd+dDimZ2DyJYtIvFRktF6dPg04/KOdoWsqaNSAzUJIr o+XKDaywz9SEvgbleohP3HRSpeIE2vyK4mFepBnW/9eMrvPD4gU7UKykEWYu2QUtUpmffOSO2VP6 wzIZa9JGnlTp0ZHhdNRVeXQyT92uGJcnEu36zYIibZawn3aJE/VPIeIXpCcCSkleGUAlaWGfqyR9 5jClsosz4mLStGrBZ+e5Z87M9eUMOKtDZV9mP3pWLyOx7t3fk1NcoCB9prUw9f+vkC4jXGYGYBuF tEjhKiL8XnuYDXr+/ByCHZr5EdSq5U2R5FwE2/Ts2Y8Fh7+OHYsJ2oP8+UO+UdVTpFy4uEQIUnfS wnCpWPGrMx/7jn3GtA9Mc8E0EKpELMyWzt5PnJhX2CglXShZH5nznpNTxDcagRw5wonwA775/Hsb k9RMLGkdpz+5js0r1leVE55qnqnmI+szm2u/cirhT9qTme9lOP8swc/3rknLvWnCTiB6A9iYR+GT TwD97YD4IG+EUpQ3B+OvAsTTM0chdykMA/dj+EDJLQ8tKI+m9WbjNcXrsDRMslYpYhEjNUe1Nv3Q s+RXO7b83XHEKCTQ1ErbJv9nbedE/TOE+Pf/FwRURMz+TXn0iEmUquNlN2+a4MIFc8HrmS227AfN JPQ5cx6T6jtOIC8mnatUt+y6tBZm6/0VYk9a79+QHBnpV6rkR+fZgwTS8/TUEfwGWGHhX5cuvS94 tjPzASOSlM9kRMq0AalpBJhNndWRskya9CyZepsRVWCgBsWDN000AyhFBLaBuXHDhBx/rJOZB5QO hMpnss2DyobONjGM9NlxM2aaSOocyNrp7BwhHD1LSohsU8DGPjWNw9/AV7WZYm1hXvSqmPZhYTKa O8pjimwOsL4wrL6n+UjrfMrq182dmzYENm4EnRxRStassLGuVAk099N2f6pXxceRf0w44oSJo4V6 TRqg/6p1OJuvI17sOAqnOo2QL1GtHRPwHAcvvUPloe2R5/UbyI7dxa5Nvoi3NIOVVgo1NtUXERJA R1QZ6X8lagVN3lCf97h7/RY0rJRkrW/ljFx2icfAfrErnKh/ETB++f8fAbb4MzswU38zFTc7612l ii8RVzY6WvYU48blQ+fORQVJk9lmVWpcZcv/3F70rxBgUmbu3GECYTD7N1tjChUKFh4fHKwhRIdj 2gZ23a8GlGGSbWpmgKTOaapFkpE1c+5LWhghs81Djx7vkn3ONg2srcxezswUKps2U9Uzx7np078N YsQqYAFzkjq8KW34sWjUyIs2IslV6z/yyGcbq7SSONussJMCt24Zk+bikfC88ePzCZuG7t3fCe0f MyY/edh7Cf1n/eIlfRG4cwd0tBN09BD0+yZrchjQooXyM3d3YNas33y+cTa0alsH9krtNGwrdMPQ gMXYt3s3TFwaYEavelDp2iKCAuFYvj5KGRLBFmuD/tUDcOh+EPqPGYLsKY9SS/VRt2U3GGU3TtYw mXletGlUBS8v7YVH4pKTvUILTtS/OXz8NjVEgNmamZQ3cWI+QbW7bNl9wYOaSXIFC4YIkmanTsXR u3dhbNx4R5Cy1VF1mVIiZu9VkihT0TKCVjmhpVXV/qvDzepVhZpNeS/7jtnBUxammh816kUy9T8j cDZmT54YJBsLpuE4f94czA9BtXFQEbGvr6bgWKjy/he2WfRMtllh/gOqc/iq5zOPYSbFfyuZi4Rw uMk3GkJtwkZo3TonSvVakI4kPhROIPTu/VbQUjDSvn7dhJzu3qnl/PnVsc4I1+fKBXLkZH4SQO3a zHQF8sEAHbVU/v3bxTgH2nfJkex2t8b94db42xpNspdBm+yqz2Wo0G4Ivb7zZIkBGrb/VtQXGTqj 68h5v93clDfyLeJfg5JX9K8QYFIfIwPmdObgoMwzzhboadOeCDbiwoWDsXixUi2s9Er+Sx4d/6qD avIcBuv3nPOSOgyy7qiO5zGP8uSEmSAEdUkqmTMyZlqEY8es8eaN3hcJWZWcZM8eW8GTPbVStepn YW6o2sXU1ba2UYItXdUO1X3sFAKT5K2tozBoUEHywC8oOB+yjd3w4a5C1L6ZMx8Lse55eNZ/Myn1 9ZUkzYqLy9dnqj77N63IeE/hRJ3xxoS3KA0IMEmSpeJMeu63fHmlgxST3FjwFualrAwhqj7q7jR0 XS0vUUnmqREe+y7psS9G6sw2XL++l+DApirKOkDqcM9vnNSYFM2c7lhEuqRH6hi5Hzhggy1bHJIR NauLbRoaNvQU7O21a/vQaQIn4Zo1a5wF2zjb+NWs+Vk4ccALR+D/iQAn6v8n+vzZv41AUjWwSu2r IgHVdz8KQ/rbD+Y3/nUElEFsvt1MfS9+uZNT5DfnuVmjmFSeUjJnKuyTJ62EJDOqorKjM/I+c8ZC +Jg5kzE1PJtDbHM3ZcoTCrLjRaFq2Rnbv95lXiFH4JcQ4ET9S3DxizkCHIH/NwI/OteeklTZJoCd bWfkrCoq6Z4F2mGhc5ljIivMJs18Hdg9TO3OzpMz728eqe33Rpx5PnOz0/exi2fqoTQWtSfqT9d3 YtbKU+RxT9mTCjfB+K71oKv2vUrj6PHLOAIcgWQIpOaO8D3JnHnNM2c4RtxjxypJWhXc5fJlMyE8 LUt8wqRtZbY3DvavIGBEwblfvXpFIX77/sptWeLap0+fUmjftmnuq1pTWpzvVQztMxHO/deid5FI DBg0DsNhgmU9y6QZAH4hR4AjkDURYCcBWOz5cePyCyFjmU161qxcdHIgGB06fKBXcSG5CwsuY2QU myxWetZE7Nd6bWZmRvH4d9IRKzpjxUsyBHTokDjDJ61FrYlapOWIkev3oUChPGAdmdT0MPpfv4lo IuqvFqm0QsGv4whwBLIKAkw6Zh7e69c7CWlD2fl75lC2aZOjoPouUiQY8+Y9EtThb9/qolSp5ElN sgpOf9pPY2NjCnmb/Izxn9aZFe9Xa6KWGtihcKHEYYt2x7JDV5C3dmOK5Pr9oqGhQbFjZaTO0qUd Mp3P4IUjwBHIsgh06hSInj39BM/v2FhDSp2qjDMfGGhKpwZiKULWw0SVt8GXSFkZBSwphb2U0OFx bgfOKCOSfu1Qa6L+AkusNyYP6Ip7jm1xsnvFVA/j3L59m2IW++HFixfw9/cnT9CTdOZWeQaXF44A RyBrIsDOTDNiVoVgTRmO9XvhWTMCWoykWejKPHnyZITm8DakIwLqT9TBzzFhcE/cNG6FE7N7wuQ7 ORfev39PwRPewNfXl0IDhlD6v5d05jY6HaHlVXMEOAIcgfRDQEy7DE1NlkDl7yR+SL+W8pr/FAG1 JmpFhAdmDOqFdzn748SoJj/Eonnz5sL3sbGxFDPWnUIGDqZABsF/ih+/nyPAEeAI/F8QYCa8U6dO UXCYmP/L8/lD/x0Cak3UAQ8PY+sFHxTWuYNhQ64gVq5AzrIt0L1ZaXwvllAUJTllE5tJ1aGhydP/ /TvY+ZM4AhwBjsCfIcBs1HIKgC3i58b+DEg1uFutidq4SDtcuNEQEeT+H5uYBFzHyFLwAOeFI8AR 4AhwBDgCmQEBteY0qZYeLOgFS+vMMBa8DxwBjgBHgCPAEfgGAbUmaj6eHAGOAEeAI8ARyOwIcKLO 7CPM+8cR4AhwBDgCao0AJ2q1Hj7eeI4AR4AjwBHI7Ahwos7sI8z7xxHgCHAEOAJqjQAnarUePt54 jgBHgCPAEcjsCHCizuwjzPvHEeAIcAQ4AmqNACdqtR4+3niOAEeAI8ARyOwIcKLO7CPM+8cR4Ahw BDgCao0AJ2q1Hj7eeI4AR4AjwBHI7Ahwos7sI8z7xxHgCHAEOAJqjQAnarUePt54jgBHgCPAEcjs CHCizuwjzPvHEeAIcAQ4AmqNACdqtR4+3niOAEeAI8ARyOwIqAVR3929D/4OxVCjpMM34+F17wgW rTmBWC3KQC3WQ7WO/VG7gHlmHzfeP44AR4AjwBHIIghkcKKOwqU9M9C5+Wq03n2WiDrlqChw6+Ax fNIphml9KyFeroCBlWEWGTreTY4AR4AjwBHICghkaKK+f3AJZu99jZI1ykAmEX07HglR8EyIh0N+ Z8TGxsLcKRdMNLPCsPE+cgQ4AhwBjkBWQSBDE3Xuyt2xq44mdo4YiVfRsd+OSbQnXly7gmdvNRH3 RAaxqQ06d+mFPJY63x0/mUwGqVQKbW1txMTEZJVx5v3kCHAEMhkCbC2TSCRISEjIZD3j3UmJQIYm am19I2pvFKKiYyASpSJRy8zQadIWOBQvDDMN4MbKgZi6+CDWT2uFpIK1r68vXrx4IfT93bt38PPz w9WrVxEREcFnBEeAI8ARUEsEGEkHBQUJggcvmRsBNRhhxXdHIEFigiJlTL58b2Vnh8hzzxBCG0yL JLzu7e2N06dPC9d9+PABYWFhuHHjBqKjozP36PLecQQ4ApkWAbFYDD09PU7UmXaEv3ZMDYgaUMTH Q6H4Vr0T63EZQ6ftQOc5y1BYH/D+5A3DvGVhmkL4LliwINiLFTa53d3dMWrUKAQHB2eBIeZd5Ahw BDIjAkySZgIIFzgy4+gm75NaELVMUxMyqVhoeZzvY6w78hB1mraBvXVh1Cp9BsuH94Oxvjb0bbNh SPdqkPxg3NikZo5nISEhCA0NzfwjzHvIEeAIZEoEGFHL5fLUzYKZssdZt1NqQNQ6aDNhMuRaesIo SXUl8PLxgk+gHPYGeqjdfgLyFnuIgCgFbHMVhZXyMl44AhwBjgBHgCOQKRBQA6IWQc/kqx06loTg fDkcYG1NAU6EIoZT3sJwyhTDwTvBEeAIcAQ4AhyB5AioAVEnb7DMPAcaNcgGDfLy5oUjwBHgCHAE OAKZHQG1I2qxVAbO0Zl9WvL+cQQ4AhwBjoAKAbUjaj50HAGOAEeAI8ARyEoIcKLOSqPN+8oR4Ahw BDgCaocAJ2q1GzLeYI4AR4AjwBHISghwos5Ko837yhHgCHAEOAJqhwAnarUbMt5gjgBHgCPAEchK CHCizkqjzfvKEeAIcAQ4AmqHACdqtRsy3mCOAEeAI8ARyEoIcKLOSqPN+8oR4AhwBDgCaocAJ2q1 GzLeYI4AR4AjwBHISghwos5Ko837yhHgCHAEOAJqhwAnarUbMt5gjgBHgCPAEchKCGQqok5QJEAk FmWl8eN95QhwBDgCHIFMjkAmIeoQLO8xFVrNe6BzleyZfMh49zgCHAGOAEcgKyGg9kQd7vMA82aM xNLVTzG8ae+sNHa8rxwBjgBHgCOQBRBQe6J+fvMiImxroUdHJ8TFxGSBIeNd5AhwBDgCHIGshIDa E3XxBgNQHHIs7tUXgfKEn46dtrY2NDU1YWRk9NNr+QUcAY4ARyCjIiCVSqGrq5tRm8fb9RcRUHui VmIRAXk8OZL9wI9sz549ePfuHc6ePYvQ0FDMmzcP0dHRfxHK9KlKQ0MDcXFxSEj4+SYkfVrwa7Wy xYO1NT4+/tdu/D9dLZFIIBaLBYzVoajbfJDJZFAoFGo1H0S0kMjl8gw/Hdi89fLyQufOnTN8W3kD /wyBTELUPwfBzs4ObNF48eIFHjx4QKQuEt5n5MJI7+TJk3B1dYWlpaWw4GXkwvC8evUqDAwMUKBA gQxPfgxfNh/8/PxQoUIFxMbGZmR4wdp7/PhxFCtWDKamphl+PrBNxYULF4S5mytXrgxPfmz+Pnr0 COHh4ShdunSGn7+MqJ89ewaGMy+ZG4FMQtQJiImKQkzc94msVKlSwkgaGxvj1KlTmDp1qlqM7PDh w9G1a1fkzJlTLdq7dOlS2Nvbo0GDBmrRXjYXHj58iGHDhqlFewcPHoxBgwYJGKtDmT17NooUKYKq VauqQ3Oxb98++Pj4oHdv9XBM7devHwoXLqwW2PJG/j4CmYSopXAhCS7SSu+nSOjp6SFbtmw/vS6j XBASEoIo2oSoSwkLCxMkEnUpERERYG1Wl6KO84FhrC5F3eYDM+Opi1lMXeZARmxnJiFqPbQYnjaJ iO3u2UtdSvv27cHU9upSateurVYOLkwacXBwUBd40bFjR0GVrC6lYcOGMDMzU5fmws3NDZGRkWrT Xmaf5o6xajNcv93QTELUv93/DH9jmTJlMnwbkzawYMGCatVeJycnsJe6lHLlyqlLU4V2Fi1aVK3a mz27egVMYr4VvGR+BDhRZ/4x5j3kCHAEOAIcATVGgBO1Gg8ebzpHgCPAEeAIZH4EOFFn/jHmPeQI cAQ4AhwBNUaAE7UaDx5vOkeAI8AR4AhkfgQ4UWf+MeY95AhwBDgCHAE1RiALEbUc53evwOn7XnAq 1ghdG5eAOEMNXBBOb7+FnPWrwFFXOSyvLu3A+hOPYGxfEj17NYCh8GkMTm1bjgtPfJHdrRk61/v3 R8287h3Gyu1XESeKQ566PdG+fA4g1gfrl6/Am8+xKN20H+oWtRFaG+95D9NW7EaU3BQtKVBHQUvJ P0f93rHV2H3lA4wd3dCrRz3oJ+J4cutyXHzqixylm6NT3cSgEVEeWLV8FT76JaBC6/6o4Wrxz9ur euDt45vgru+GJmWVwW6enPkPW849h7lLOfTsWgvKKM+ROLxpGa6/DECeCm3Rrkb+f97el2d3YPOp h0iQUAxfHRu06NINBa014f/4JGZtvQhtwxzoNqgT7LWUTbt3fAN2X34Ny5yV0bNjVSR+/M/a/f7m Iaw/eAMxunbo3LMHcpuyORmBgxuW4ebrQOSr1B5tquVVtifsPRYvWwOfIBmqdRqESrmN/lk76deD O8c2Y9+V18IzpVIxoiKiUb3bWFSjdtw9thZ7rryDdZ4q6NGuCjSFq0KxZ80y3HsfgoLVu6BFRfpt 8qL2CGQZor63YyaWXwIGt6uJQ2sXYaZsOEbXyyBHiSJ9sHRcL0xZHo3DAdXgSNPK78YWTFx7A617 tMGnA2sxYhmwok8D3P5vGtbe0sWg1tWwZ/U8zNMciyHV8/yziRj+5ih6tB2CXAOXoJ7BAwwYSRGc Zi6C8d0VuBrphq7VJFi+cBwSJi9DPWt3TJo4D5JKnVEt5g4mTZ6MWXMmIofOD4Ky/9WeJODef1Mw do8/ho9shce7V2PIvHisGNIQdzZPw7o7+hjUqirhOBcLtCdhUBU7rJ8+AXf1a6JT5VgsmTsWCZMW oqazzl9tVVoqi3xxEC3adEehkccEova+uBZTtzxF5x7N8WznKoxeJ8GiLtVxac1kbH1uhQHNKmH7 yhkI056C3uVd0vKIv3RNKI5t2gf/vE3RvVo2xIs0YGsgRdS7MxgzeztKtO0Bw/u7MGL6Kqyb3AOB Z5Zj5q4P6NW9EW5tXYGxYgnmtq/0l9ry82o+XFiHeRdj0blJE7w4tgJdOk3Gkf3j8Xj9ZGx/aYsB TSpi64rpCNebhR4l9bBs8kS8tm+E1vkCsWDGWEhnzEM5GyUlpn8RwyFfKdQzzg2RRAPvT8zH4MOh aDlaFx5nlmHWXnf07toA17eswHixJma1KYPjiydgv3cu9K1XABtXTEaU7kx0LG6b/k3lT0hXBLIG Ucd7Yu+Bi6jcaycFNDCBTfB1dN+yHz2IqE3TFd40VE6S6MqZo3DolQS5SzghQcHk/Dgc3bMb1qVH oG4ZN8DaD3UHHsGzlgVx+Ngt1Bq4F24ldWHifQkDth9AVyJqpbSd/iVBwwq9FmxCjRpukKAGpj17 hSUrZsNCQ4p+i1qjuBHgdfUYDh+6goJFH+FFbDasa12FpNjiOH2mFfZdeI8Rtf8dkeg4FcPIycVQ vqAF8kVewKZlVxHZtxQOHLuJOkP2w624Dow9L2HYnuNolSsnzj+KwpBtzVCIxNV3F49g997LqDm0 RvoDm/QJCSHYuHY3oo2tYGfGNgnxOLh7H1wqT0d1t0KoaPARDccewetGTjhMkmyjcVPg5iqD9ttz GLvtMDqUH5Aobf+DZkf7wdvQFCXLFKPAMQYwN1cGNzl9cBti7KuiC80TlNfF/hZTcNm9Pj4cPo78 teagkltuFNd4icZT9uJt60rI9k9WItpU7L8KlyoD4exgDfuOQ2FVMgjxYc+w9/gjNJ06A255xZC9 PIvpe06hgYUhrryRYNKMhshJ7Xt07ih2HryFcr3+1Vl2ESwc89CLAE2gNWxmIAYsXIOipnGYt+MQ CtZehopu2VFE8gzN5x6Ge00DHDv/Cq3mLoAbBV+Mf3QKc7fRvC7eNVHa/gfzgT8iXRD4Jz+PdGn5 r1Qa4YPP4WYobqWUjCwsnCAOuQUfSphk+v/OyyE1Rr2e09FF4oFefbchWkjiFA6Pz5qwKJeodjWy hnGCBO/fvkVAjBVKWyp39FaWTkDgC/hToirDf6RR1ncoitqqQF4xn3D0/mtYWbMEHKYwVeqU4WTp iLC3HnhjHg4tU5fERUIDTgbmeOz1ma74V0QtQu5ytZEbsbh4aC2WLjqBJoPXQV/hA+8wc1S0SIJj sCfevfdBnJYzTBIzBzpZOCDw42eiSdCm5N+VR/uW4ZVmFQxqGQ93Icd6OLz8dQlnJQlqmNhBX66g +fAewXE2sDRXTmIbS2fE+XsjmBKt6f4jpUW01xu8vnkWz8O1cE83ApZFaqF/24bw94mHoW1iPHIt Y9ho6uHT29fwCjaEjY2J0F49M3voRl2FR8j/2jsP8Cir7A+/M8mkl0kvpJEAgYTeIZQQQRBY2sJS FwwoHSQCKp0gTcoq4N9H14auCyKwCiKwWBYRpCggJjTphBoIJaRNyuR/JzMiCIgFJyRzzsM85Jn5 5rvnvud+3++2+U4xUT5WcDj3HPuOnCdH8yFXNl3iDA50GzYe3/wfSDcEEeBrXgyrEBhB0eYMTpzI p9g1Er3lLhnhG8Lnqv2a8thZwdvbGlzK8kV8k1WJ5e3VUwoLT3D2igexQfqSYzx8w3DJO8Cx46e4 YQwlwDL6CFH3h9yvLqvWgwi19S7fP6Uk2xDq3DyuqzSYmNbQTDdd9X9BcTZ5pkdol7ZQqymrCsFB kH6c3PwiNCX3CgOZhkI8dRZ5UNODxfa55FzOIlPlHdFY3raz15BvVPUwJX1y/lPax71PqsRu9lOD 2BPZk/c6ujDqn4csviu+OiP5BuXrVQM5qg5md7VoHfLJUWtsVrfifLR2LsS1asSJPV9xJjpCrUgq 0LdwLFTtIetyLlkq7eWPomynKyLPkKPmN6wn1LkntrN0axajFyayf85G0pxNcyWFXFftwUvF24xS o9aDc8lW7UFp3C3tQW0VKFLtwZSbxko9C41XZYZPfZsGHeMwycZbzz3OG2v98dbak+9gcUI1ao2D gdwM5W9+MYG31MOoyVZtQjlcsk78J5t65nj6+aMEdUpm5tCGFBxcRaeJ86nwbCsMKhPVT9eVmeON DHuy7FUaVItbdg6F5F7NwYp4LSXfYP1nB6jbawbqTqGcy+G6SkBk/JGjup8VaU3tIZvrKiug+R5i ug6LyS/MVncTsbJOwDaE2sOTAF0+hSV3MCWDeQZ0Gg/0lhHgQxFEU0fCZCUuuhGg8osYsi1pFwsN GA1O+ET546fNU/Uw37ANufk42HviaW2Rvn6EGeOGsNn5r3z80gh8Dr2Pe34W+SZFUxn3crILcXbz JSjkKq4HVa7wEt0oUhthtHh5e1gft8aN5h36qFdd+iSM4bNG4whzLkRhLbE8xVGnVW2komoThh9U J069qRDnZBfh5qa34manIj58ZS5bUn0JX/Ii2z5NIc37DXbGPU2waViXa8mRXJCPMd8F3yg//DS5 N+uRq+rhpPPEwwqa92MQHb0iadPxpxmSyEBPPvj+MEEebjjnWDplxgLys3XoIwIJcFa51XPM9SjO VwEwuuNtDZE2Fag2Y3n4NaStZeOgrnJNojWrOXzNjgo6w23twVGnJzDCDc+8yyUdNZPlZBXj6aG3 Vh/o5nViSNvJ7nNaBrW2bBR09iDQqZDiXHPOd6OaddEWuuIf5YOfUXUsLbeNvJwCnB316m4iVtYJ 2IZQO4URHWpgb8opulevSkrKbnRVowmx9vzVL7aW4pL8wsXFJqV2oXqsB8v2p0CPaK4d2sslbzdi w2PZH3CDvaln6Fg5nO9UPVxiGmLNfcnGnNPMf2Y4J6NH8cW4ruYahcXga/8uKSdQeYdhxw8HCGne l5joInL+vZVz6pCKxRfYfe0KbWJNC27Wsjw+XDCeI+FDeKaHusnduI6dSwARlauQHZCpOJ6lQ1RY CUen6ASqRFRVa7srSD2tpu+VmzvUVG2l+P7Wcrakd9Bs0CR8T14iO8fAAQ8nrup90bvqqR7txEcp B6B9OOcP7CYz0IuYsFhCfa6y90A6j4T6syd1D5412uFlRY8v7nqPOWsuMXNWUokgnLuQjXedBtTx OsdHH+5V08St0Zw5xBFtEQMrqb0UkVo2KCEnIYgT+3eTq9aKK1uro+lZiSZVitijdpx37q12dV8+ zUVjELH1qpPmlaE4ZhAf7MPulL14xPSkcqQXuvwNHL6kton4FbLj9AmqdbV+utlzqTvIdKxE9VBL 3mlNALFV7Pg6RXFs6c/RVMUx1I9qqj0EeF5k7+Esmvi6sWv/Pvxr9bHefgUrtjtbK8o2hFqNnvsM HcGYWVOZfrgyJ0/pGD2xz0O6bmMSanva9BvHpxOSGTMtldyjZ+g94jnVi/agl8pN/dS8Z5m+L4KT Z/QkTephGsRazX7Y+CrzPzxJr6FHmD0zWU2tFVO7XSJDEjswNXkgqWFOpDk9wnPta+DuGkH32ttJ euJZqhrT8UsYSZe61syk5EituJasf2UyU/fXpij7Ms0GDyG+YhgxKuvQ6PnPMH1vuOLozegpHXHW uzK4exOmTxzMt8Fazvp0YFIna+b6Vbt8qzZUL3M4M79din14a6KVeET2HcPGyXMZP30n146eZ8BT k/Bx8qHfoAEkLXqK6dsrcPJ8KE9P6aRaj/XMr1Ijwh3mMmHcdHzc1Ihe/QSuX9saVHXxosH65xig 3tdfOEHz/mOoqXcmut9TrJ/8DyZM30z60XQGj52kpsmt5K/GnR4jh7Pk3XfUfcCZaxlnaZ6ofkrm F4ZPYl/GLBnF9a1BnLxQkVHT2uCs1v6f6BDLC0+PYLN3PhkRPRnZzhIcK7lsKibt0EU0waozfHNg 4UCXQWP5cupLTLz8ORePXWLwuMm4OwWR+PjfGLd4KOmbfDmZEcuYEW2tPgNgRTQ2U5Q1r+lShepT oz0vzQ1i3/Gr9I1pTGXLxrJSderWwv3qMu/lKLwtu8K0AdWZNW8O278/jUefGOpGB5Yc7V+vK4tn h5FyKpO/12hClJ91f4Ua0nwomzZ2I1vlwVXLZCUWGOxJTOMR/CNkC6euaqnRpBlmt9zp+ewsIr/e Q5bGh7hmNa3aqTCNUCObdGdhSGW+PZKhNraF07SWORe5f71uLJ4VRuqpG/RXHCMtHOv1Hs+C6K2c va6jdlxTvK3ZC/pZY/zLqMW0djDvDNKF1uOFeTPZuf8s3n+vSa0oc4cnpGkvFvtGcvBMNom14wi3 ssNa78okTXiBHV9/T47RjupNW+JfEvsQxs+ax5Zdh7DT9yeujnl63DGiCfPnJ/PNwQv4Pl6bGhHm jWXWMp+qLZiQFMy2lNM4qPbQzNIeQpr1ZbFfJQ6dzWFgnWaEeZk3r5hmOLxqbudithP1mzey6rLC j0xq9X6Wf6pr6dYfhblExrFgnp5vlYj7Jdaherh5HiXykYEsCq7GkfMGnqzfQv1Uzlq9IGtF0DbL sRmhNoXXJ6IOCREPaaDtXQkNt2w3trjo6FuJ+IQ70+75RdUjwaw3Vjc3Nfqoq153s6jaLbjDLTtP GjS33u9k7+aXR2gtEiwbkG/93D+q/l042hFdtyVqBr/UzTvo9sbqEhBNK/X6uQVVaUiQ9Wdkf3LD wZfG8Ql38nINpkUr84NvbjW3oBhaqVdpmaMS5IS7XFfB0Y0IvgOvA7ENWhJbWs6qcj0DQ+7680v3 4FhaqdfPLbRaE0Kt92iFUiRjO0XblFDbTlilpkJACAgBIVBeCIhQl5dISj2EgBAQAkKgXBIQoS6X YZVKCQEhIASEQHkhIEJdXiIp9RACQkAICIFySUCEulyGVSolBISAEBAC5YWACHV5iaTUQwgIASEg BMolARHqchlWqZQQEAJCQAiUFwIi1OUlklIPISAEhIAQKJcERKjLZVilUkJACAgBIVBeCIhQl5dI Sj2EgBAQAkKgXBIQoS6XYbWxShWcZNHoaXxx+iKZKt+1OWGohgrV+/LMYD9enLSIU7kOPDJ0FpO7 1+PYZ0uZ/urHpF/NwGDOFKjMg74TF/Dko3c+izNl3UvMWJrOlNeTqWl5BvSdhK/xztRkUh1bMnNS l9+d8OX09pUk/2MFZ6/m0WvqyzzeIuKPBTPnB6YNGcfuG/ZUa9hPJRzpJtmU/hhR+bYQsDoBEWqr I5cCHziBoitsfPtdNvvWoH3jKqZU0iVCbXfhf/R8dBk5Ie1o4HGOKYl9CKv8JbHHv+G91f+hTuu/ ojIZWswNF8e7Xw4Zh7ewavUhBi6a+gtCncuOtavY5ObJtD8g1BlHd/LuqtVEt+yNs8MDSCytscdd 78i3K1fx7bloJohQP/DmJycUAn82ARHqP5uwnN8KBOywU8mO2gyfz+qJbW+Wl//dP6nTOY3XPt7A Y0EHaaSJYc3nO6no4YqvXQWWbFxF3D208GrqGoYlzWR/ejCNa95A6+SPTmvORHQt9T8MTXqeg+nQ avgc5g1pp7KCaXHx8MTT1Vn9pazgBh8sHMbsZSkqB3YEAycPI+uDxaQ1eYqXhykf89JIfnIAeW3n Mqdfw5s+a7R26FVm50lvL6NnRfjkpWd4Z8d1At0us/X7DBKfnUbguY+Y9c4uWvSZwsKk9uhMPZOi bFbNHsvc1dsx6rzoNHYuk3o2Ruccybgl/+LMoe94P0tr6cRYISRShBAQAg+MgAj1A0MpJypNAk4u atS4dgkTsr68KUYxrfuw7+Rg7JWQndjwAUfxpmfDmrgf30ah8RoLRkzkE0uWRY1XBIlPPEklLw2F mQcY1XMAH+TGMLRdBb5Z9ybFxibYOzpQfG03/bs8yaXYzsTHw/qJo/H3/y8Tu/rcHMmbsjweXL2A qfP30HJAWzJ2rmXs2FcZXPcyby78F5OVULsdWMPC9/Yy+fGAn2EzqW4xWdcK1P86zu3fysoV22nV YyBhml2M7p5As25PUNUtnSXTp9CmfUv+UtWVE1+8StLUFdQb0h+P458zd/ZMHotfQ6NAU0/kKnkF RWg1NxMal2aopGwhIAR+IwER6t8ITA5/CAko/bHX6bh4cCfvX9x/08HHwtvRT2VfPLvlNTp0nEWV xJcY3qwiBw7kU1Scx7Z1y/nOnHYYbWh9HuttEmq4krqJTw448/znq5mUEMTmSpd5dGwadkrzrn3/ PzYdu64kfxeGtGJOXznC8tUfKaEeg65kdF6MSWJDGnVmxsJYTqeuZXPadQqv5FJrai+iPpvNRwdz qPT+Srzj/8bfW4b/AlC12m6auvZ/lDc/eBPNiiQ29lrJM6+8Tttjc1gR9zKnL10DJdQ6B1P3IJOD e/cQUbk5cxM7EO7xAKbOH8Jwi0tCwNYIiFDbWsTLY32VnmVnZhGf9C4bkrveVsPT29+iW9+nqdB/ CeveGlKyySsrOws7rT/vfX+CRy0j6lu/VJiXh4EiXHTmy8PLxwc70kzL3lw5fwaDVk/LTr1oHOZC To88Amo0VUdlU2Q0Kb6dGgfDV2uWMGrW5/R/ejzt66eyeJc7jeLbUbfyq6xd8Dz2+6/SvGsvgu5z BRqLNegc3VX5alycU4CTNgS9C1xXf6Mm3O3tzKPkoPrdWLy0gI9XLmPF2n+zdeOXOAXVZGj83XOH l8dmIHUSAuWVgAh1eY2sTdVLKbX6d/q7zaz7xOHm1Hdx5inmjBnBbmMr3ugazpfr1+Ef2xCNzpF8 YyafrfyEgpCfQIVUa0itSD+8Y+Ko5z6BBS/MpdK1JvzrxffIozpFaod4aP3WVHNehMEtnEbVNTw3 8XU61+ynTlJEQX6BmlLXqjXqIj7dsJ5013okxNVly9dzMBoC0QbE8HRiAg0Gz8cY1Y7Ng1reN0pF hQUYDAYK1ZHGQjUTYHTA0VmVpt5XC+FqZsB8igOb3mLmvP/SZeRI5jTfwaznlnLs4vX7nl8OEAJC 4OEnIEL98MdIPLwfATU9HBgeyuZPX6PzupdvOdo0GnXD02E3I3v8hfxCI4+/so5h/hXx87Rj0chO LDSNgktMy8AF63k9qQ1OgU1Z8lYy3YfOpMvGD4lvFYN3sB+agkIcIjvwxuLh9B6TSNwsaNBvKp3i TKPWDFy8vNG72iuZtmPgiHF8PGwGndoMoEvPplTTXOR4BnTs34+owa+hbdaOpr7mzWm3m0l5Nbh6 mufknd298PX1LBlR2zu74+Oj/lY+ax1c8fT0xtnefI7o+N50q/Uxs5KGqI11jtRLnMGodlUtp9bj pNOqzoJF1e/HUz4XAkLgoSIgQv1QhUOc+V0EHKry4lffMVfNPf9cijQlG6iKKbZ84OTmgZMmnj2P JGL88U1LoU6unpa/7KjdfSp7Ww/HUOiEXm/P9UwDHnqTXGpoOvD/SO2SjEEJpoevr5qANpkXE5dv oEDjWLLrO7rTeHa1SCSvyBlfH1eyMjK4fGEHr6vd3Jc1fiT1aFcivnfItPIpjyzWv/0m1QZ1o/fs ZXQu0GLyrLjHDPY8VoSH0nBt89EcOzZECbrZZwevSCYt28LQy5mqthrcfX3Mv+UuyOCLNcv55mg6 2sCSiQcxISAEyhgBEeoyFjBx9y4E1IjaTY1m3X4DHG/T/PF9zF3vi7vlGB9v02atn8zd+6fPzO9q lWjqbzvGTX3/R5/c1Dr34U/mMm72cmoNmMbwRyvdtXRnryCiQkPYsHgK1eo1pU6Xatws2dEV7xL1 VaZzUaNrtVh9mzngozoOt5khjTdnvsCRPHfqVgm8a+fgfhzkcyEgBEqXgAh16fKX0m2IQJ2+s7n4 t+dxcHIy/9b6Lhb92Ch2HhleMgNgrzOP1f+QudVk6c6jajpedSUsG93+0Pnky0JACFidgAi11ZFL gbZKQKueyuJkejLLL5hGa4/jPZ6Q9vu4adU6vWPJTnQxISAEyiYBEeqyGTfxWggIASEgBGyEgAi1 jQRaqikEhIAQEAJlk4AIddmMm3gtBISAEBACNkJAhNpGAi3VFAJCQAgIgbJJQIS6bMZNvBYCQkAI CAEbISBCbSOBlmoKASEgBIRA2SQgQl024yZeCwEhIASEgI0QEKG2kUBLNYWAEBACQqBsEhChLptx E6+FgBAQAkLARgiIUNtIoKWaQkAICAEhUDYJiFCXzbiJ10JACAgBIWAjBESobSTQUk0hIASEgBAo mwREqMtm3MRrISAEhIAQsBEC9xJqnZvbb8nuayO0pJpCQAgIASEgBB4wAUdHR80vnfJeQn1q27Zt RzMzM++e3f4BOymnEwJCQAgIASFgqwT27dvn/JuFOjk5+Ydp06YlqC9WtFVwUm8hIASEgBAQAlYi kK/KybtXWfdco1Zinaa+ZHqJCQEhIASEgBAQAqVEQDaTlRJ4KVYICAEhIASEwK8hIEL9ayjJMUJA CAgBISAESomACHUpgZdihYAQEAJCQAj8GgIi1L+GkhwjBISAEBACQqCUCPw/c5qhvlCaP1cAAAAA SUVORK5CYII= ------=_NextPart_000_00AD_01CAF14A.E58011D0 Content-Type: image/png; name="image003.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAeQAAAElCAYAAAA1GpHoAAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAH9ZSURBVHhe 7V0FfFPJE/6oQnF3d3f3w939jxx+cHC4HO7u7u5W7HB3d3d3CgVa2iL/mU1fSEtLk5CmaTtzvxxN 8t7u7Leb9+3Ozs44DBo0CCKCgCAgCAgCgoAgELIIOIRs9VK7ICAICAKCgCAgCDACQsgyDgQBQUAQ EAQEARtAQAjZBjpBVBAEBAFBQBAQBISQZQwIAoKAICAICAI2gIAQsg10gqggCAgCgoAgIAgESsjf vn1rGDt27CIeHh6CkiAgCAgCgoAgIAj8BgL29vb4/Pmze7Ro0fq/e/fOO6CiAiXkiBEjVmzXrl2j 36hfbhUEBAFBQBAQBAQBQiBChAhYuXKl999//z20U6dOphEysflHZnQRQUAQEAQEAUFAEPh9BGih +9bNze17YCX9cg+ZzNaws7P7fS2kBEFAEBAEBAFBIJwj8P17oFyskBGnrnA+QKT5goAgIAgIAraB gBCybfSDaCEICAKCgCAQzhEQQg7nA0CaLwgIAoKAIGAbCAgh20Y/iBaCgCAgCAgC4RwBIeRwPgCk +YKAICAICAK2gYAQsm30g2ghCAgCgoAgEM4REEIO5wNAmi8ICAKCgCBgGwgIIdtGP4gWVkDAw+MT 3r17ryLmxI0bFw4OMvytALtFq/j69StevnwJPs9JIQgRJUoUi5YvhQkCIYmAPJFCEn2pG8uXLsX7 Dx8CRCJ58hSoWLGCxVBauXw5OvzTCRHsHHH69AlkSJ/eYmWHtoJevnyBdevWK7VLly6DtGnThIom PHn0CLlyZoen9xdMmDgZtWpWw+rVa5TuFSpURIoUyUNFO0RJQSAgBISQZVyEGALDhw5Fn379Aq0/ a7YcQRLyvbt34e3jgxgxYiJ+/Hi/bIu3tze0ZClfv34LsXZbu2K2DDx69FhVmzx5clD4PgwZNBBT p89Un02fMTvUEPLXb1/x/r07vlDAo89e3hg5bCjGTpik2rF23QbEixeX2vpIvU+VOjUcxQpi7eEm 9f0GAkLIvwGe3Pp7CGTImBG9e/fmDCiYPWsmPnl4UoER0KJlC8SPFw+ZMmf5ZQU+Pt4oV6Y0bt29 hxat/sLc2dN/eb0+NnsEB2W2Di+yd88eVKlaTTX3wMHDKFa0MDp36YZYcXQTmMKFC4QqKBwdHfCF Vsgc1vfvjp3gEjW60r9A/nxw3bAejf7XmN7Z4er1a8iYPl2oapsoG74REEIO3/0foq2vWasW+MWy avlSPSH369cfyZMl1RHIgQMY0L8vXrx8DS8vL0SNGhU1a9bCgAH9MWHsWNx98EBdt2bVchw7cgAd 6AGdI2tGtGzVBu/ev4dL5MhwiRQJw0aMQuxYsQJtLwV8x7GjR1VdnrTy4pCzWbJkw5Qpk/CK9iwn jB+HE6dO4+PHj4hMZfJkYfGiRbh65SKat2iFCPaOiPDVC95fv8OBkrLUql0P/fr2xsjhQ7Fy9Vok SJQE2//bgufPnqJq5Urquh69+iBn9syYMnky9uzdh0+fPoFSnmLkqDGoUL4sTp86Re2gsu0cYI+v ZKb1Qdas2ZElY1qsWLVa7YfzPuo/nbqgetVK6Na1K46dOAm2BMSicjKT/rNmTMOYUSP17W7SuBHi xk+IgdTOM6dOwsvnC0qRyZrbdeTwYfSnz9+7f4APfc77s382b4lO/3TAO7e3qFqlMtw/esKRwtvz 6tTO0VHpM2fOLESiVbcmXP/I4cOx3tUVX74wcTogopMDvOnvXHnyoUSR/Bg/cQocnSJh/77dpOMM LKatC5ZmzZqjffu2GDRgANaQSZ31ikX9FiNWbKxetZIsIdHV/jGLI9UfAd9xlPqNJXeu3Birb+s3 VK5UkdoQDU523+Hz7TsaNmqMHt27YsWypRg1Zqzqs00bNyBpkiQh+juQygUBDQEhZBkLIY7A69ev wYlMNGFyZELeuWM7ypXX7SHHiRsfuXNmw46du3Dx4kXEI1JxI5LQTM/u7u9x9ep7PHnyBJvXr8KV q1fxb5++2LFtC86cPY9G9DDOnzt7oG11Xb8OzVu28vP9VSqjcOGCmDVtKq7evKW+q1q1KjZv2oQr V64QUdqjfu0auHDhwk/l8meJEiXE/Xv31ff3Hj4hXb/iA+2XnyJ9WG7QCm7CqKE4ff4i0qbLgOZ/ /okhZMavV68etlPbnYj4/Jd9lepdRfcmSJgE//buhX7UxjGjx+KrtweWrViJosVKoEC+3Bgzdhwu Ur3Pnz3DzRs39Po9oAnM0+cvCafH2Lptu/q8AxH64YMHUKFSZfU+Ge3dp6a92H00GercqaOaBDWs XwcnT5yA1xe/pn6uw4MsG0uXLISLi4tvu65jwKBBAWLt5OyCtCmS6Nv15ctX3Lt3T//+2fPnePf2 LU2gRiJJ0uRo27Ythg8dgs80GSlbriJmTpuESDTB+uzzURHyu3du2L17t6qrZs3aeP3mtb7eu3fu 0N+cHEenM1tg/ve/Bnj54oW+Pk9llRERBGwDASFk2+gH0cIAAc20PGzIEP2nU6dORR0iv8IF8+P4 yTNYsmQp/tvqipW0Urz/8BHq1GtIK8HhahXs4NhTrfCYSL75eClCfu/2Cjt9H9z+weaV5tgxo/Uf b9n6H7JlyYyvNEmYOH48btI+NUujRk2wdOki9O3dE8NGjsb27TtQslgRg/u24fbNa+jUuYv6bP36 9ahTqwYWka6f3N9hIjkh3b97U30Xnwh1/55duHLtKq0UnTGY2lq/bm1a4Y3AB7r26LHjqFK+jL7s MmUrYM7sGahXp7ZaqceOEwdFihaltj9QRB89ejQ0odUlt/nTp4+YTHp70arwwoWL6N61C3r/21eV tWLFKhQqVBBPHj8gsz2UJeD506dYsXi+vi5e+Rema7JlyYRrN29j0+YtaNq4oVoxe71zR3da2deq VhmFChZUVLd9+zZ4enrqCXnI4B9kPHXqdCRLmghVq1VX5TOZOjk5qb+dI0ZRWwfOzs76ur9+/UIr +AS0T6xb/bOsXLYYV2/cxuWL53Dp0mW1B05LdbVSNsxGlzlLFvQbMAit27Slu+ywm0z1adOkQrs2 rbGV+ur2rZs4cuQo5s+fp8rNmi0X1RFVX7f8IQiENAJCyCHdA1L/Twho27vPaHXHkit3XhQtUpge vvaIEll3zCVipIjKkcuJVkks/Dc7LDE5jR41CvdpJeju7k4m5Svq+wi0b+wS0RGfiDj8yzcigefP X6iP/yhdHsWorqi+ZODt9ZnMrl8RLUYsMh+3UNewOZiFTdeGR6dSpUqFTx/e6YtnsmhGq95ePbrh xeu3uE2r5acP7uvalCuXWrEfJDOxS+RIuHLpIlrv3omo1I6IVF/MmLHIavBVX1a3bl1V+7p17472 7drT9efJ2zgn6jdoQGbYHuA2zJ4zR63AeU/+mwLxO+ESA4kS/zDJ8uo3GVkfXr96ociYxYec4rT2 Fy9RCtmyZaVJjaMiT62dTH6aqZid57it2i48E3UEgzStvCpnSZ0mPaqQmfvRo4c/Ya594H8vn1e9 fKyJTdbcVz6ExYtXb9TlESI4KvIOLIWdMxF1PPI90CQ5rfKTJUuGPn37YRdtCXjTKnvypCm4eVNn MWhM5vsECRIEqpt8IQhYGwEhZGsjLvUZjYBmxr5FD9DHjx8pE7BG1rw3yaI9nLWV0qKFC8hU3Ud9 x6ulmLTnePHSJaKmX4tW17kzZ/CKTOgaIWt3eXz8gGPHjqFE8WLQVvBMZIamdiZC3j/VRPuuePHi WE0ewEtIt29fdN9zOe/evFR/f/v+DSmJ4P76qy2toifRCtJR1XGIzMj6+j081J+169RF9eo1MHLE cKxeswYrV6zAli3byLz9DW/J+zh5qrQYPmQQ9uzcBp9PnxU+PgY62dv/nN+cr9F0vXD+HN68eUMT gpiMrqqT22ko/J7bGphoZT198gh3yboQI4ZupRuQRIkaRb9i5u8dHBzRs3s3LFy8BE7OkTB37lxc Pn8Wb966GdWHhrpq/ZQ3f35UrVgea1034fDhg0qNqNGiIytZAEQEAVtCQAjZlnojHOvyg9i+6feF 2//9N7p0606rPnfaZ3yAx2SePe27/8pe2CyfyOmHZcumDThK+4O8Z8sSwd4JfzZrhlHDButQNSAd EAEaCpMve3aPo+MzbmTavv/gEfbs2olVa9bSyrwo4seJpVa4N2gf+erVK5g1a5a6PSatPiPRSt1Q DFdvGjk0+7OFIuRPn36ct27UqCE8ybQ8beoUuJMz12YyC1coX45Mte/oSNJg2s+thKSJE/4o2ncm 0qVTJyRPmZq8i/8h4nyNS5ev4KPBqrxunTrIkSMrPhIZa/L5s5f+7xEjRtAqcYKfiUOixInRpm0b dO3Ri/Zk3+Le/Qc0GdiPm7d1pvoEvsfJtD7S2qihaDgp4es7/PMPjhyn9nl64NDhI7h+5cceewS7 CPD0JXMvsj5UqVwF169e1uvHZT0jEzpL3vwFlXNbv397+vbhNzXB8K+HdjOvttnxTyffMJS2AQb0 74ekSZPREai0yrytnySVKIny5cv76Tt5IwiENAJCyCHdA1K/esgarizZ7MxSt359zJ47D9evX0f9 +nX1SOUrUJC8nyeq9+UrVsT8hYuUk1LhwoVQhJyaUpFJ9i7tK6dKaRgk4ivVoacQP2ZPNpM2J2/i lavW4AmRQak/SqiynSO6YAg91F88f4IZs+Zg0YJ56sUSl5zMli5dDI+P7/2QiSE5aav4pGRqTkGm 0/sPdabb3PkK0PlYeyROm5ZMzg1VG103rFMvTdLSkbA0qVIYlK1brfKqecKkSehEzlaa1KhZBw4R viqvZN5H55cmvBebg0zb6Sjwx81bt7HRdT127NqFyRPG+Rl5deo3wKQp0/CQzvCWpaNkmrAj1bBh Q5S3s9ZH3D/KhO17EX9uOBGpSJOJAnlz4/ipM+jfT2etsCcy5D15T1rpFy5aDHFor/81OW9t3brF jx5cdvUaNbFj9x4cObhXRVT7IV8VoWp68N+GePPkLHOWrEhAk7XnZPaeP28ulpOj20PaJuhHJvCF ZKF4+eatKu7ff3v7qVfeCAK2gIAQsi30QjjXgc2ju/fuVwE++Bxyet+zo4lp73Pv3r24f/++2htW D3Yy5WYksuK9UZaZs+egZes26m++Jh1F3+IH83Py1mVCtLenI0P2dDiG2MOOVlBMCmz3TpUyhR/U M5FD0KFDh/CcPHB1R3XsED9BQqRJnUrt9zZu+qd6+POL941jx4mrSI49wrVjNxlI7+RJE+vf8742 SxYqez8R6dOnur1V1lE7gjVt5kw0a95CEZrWRi4/NQW1iEp7s1rZ6TNkUPcuoWhjb4hUWA/WkV8F CujOEXc+ftxXx+/K7M3XMF758uXD3n378JAmKSzk66XalZ32ir/Sm9Rp0iAeEd/BgwfxlPZ/2bEq QgRd2dmyZae9chdl9t5/6LDaT09GE4y4tI/Ox8SYlB0dnRDdd8+dy48aNRr+27GTJlI3lA7HyEGt Z8/uqu4PdKSqZMk/cOToEWWGZmFv9Qi0ov1GuiRJmlQdQ8pJmHNfMSZcPq94v9NVqcm0n5MmGDxW UqdOQ45mLj8wIlz5iNQh2pfnbQdt0hCDHN68vb30Ww3ssR87lq5vRAQBW0JACNmWeiOc6sIElDtP ngBbnzBhQvArMOHVbUHy9vUjRC4pU6Y0GU3ex+WXf2FHop/q8L2IJxOG3zF5xfGzqtNdyGFA+eVf HGjCEFjZfK3/7zJkyBhou35VDk9u+GUo8ePH9/M+eQrSkV4BiSN5RufNm8/PVwX8427wLTulafp4 0ASJyZaFz1rznnm69LoJRmCS33eSEdD3ho5bAWGUhiwP/DKUVxQq9O1b3ZGo/zVuQpMpv9//Uhn5 UhCwEgJCyFYCWqoRBMIrAlHoKFaRIrrjYSlS/DzhsQYu27dvR4HCRZV/QqaM4TeGuTWwljrMR0AI 2Xzs5E5BQBAwAoGChQqp7YCQlOYtWlJEtZYhqYLULQgEiYAQcpAQyQWCgCAgCAgCgkDwIyCEHPwY Sw2CgCAgCAgCgkCQCAghBwmRXCAICAKCgCAgCAQ/AkLIwY+x1CAICAKCgCAgCASJgBBykBDJBYKA ICAICAKCQPAjIIQc/BhLDYKAICAICAKCQJAICCEHCZFcYAkEOITjuLFjKMLSFxVDuESJEpYo1mJl nDt7BqtWr6HyIqBjxw6UyCKRxcoOCwVpoTH9Z2cKjW0zDPPJ7flOEcFGjRqJd5ScI3+BQqhRvWpo bJboHAYQEEIOA50YGprQr09vTJk2g9ILxkKHDh1sTuWzp0/RQ3mU0qtmrVpCyL49xKErJ44fh8lT p6lPON53wQJ+I3bZXGcGotALCqd6iMKD9u7dCz4UIMTJmWOVD0Qlir3tTBHfuP/tKNToFUrYkSGD BA8JLf0alvQUQg5LvWmjbTlDKQ3Xb3BV2mXOlJlCOCa2OU0j+ub+ZcU4HnJ4lVMnT2AOJbugyN+Y NHkiIlGO4Xfv3sHDN/3jd4MczZbA6BGl1RwyeIgqqnfvPhTy1DAhiGk1+Ph4o0e3bpRH+TPq1GuA MqVK+ilg/bo1aPd3R4rTzbHNdaE869erh3oN/ocm/6uvYpRzHPOJkyZj5gzdBEREELAmAkLI1kQ7 nNZ1/dpVyqKkS6wwcEB/PQr8Oecq9vb+gogRnVGhQkWVyGDf3j0q8QA/IL9RogMOgxyFEhaUL1dW f+9+SjrxjBJB8IM1OiVxqFSxgv67b0Qa69dvUKn4uAyOm5wzR3Y/6O+nOl77JjeIGSu2SkKhhJIq bHR1pbjTydTbYpTLmBMvBCQ3rl9T6Q81qVixElxcIuHwoYOUpOKlyiPMsbZTp0mr6r9HuYHPnD1L qzAH2H3/ii++8Z1L/vGHSjZx5PAhPHv+AqxPqT9K4g0lSNi3f78qvjCFnkyYIAGOHztK6SEfqqQL LpGjkHm1mvr+0YMHOHHqlCo7ApWtkkZw8gXC8xzlOPahrQKOyV2+fAVKyBAZBw/sV33C+DlRnOoM NFHKkikjZkybhgWUi5glQ8YMKpFH67ZtkSCRbhKl4fKViGsD4WSY9KNcuXKUWCIq3Gl7YhdllPoe wR4OlH5ZZYdS5WVClsw/chBz3cuXLsGcOXNU2VGjxVCr7zJly6pkFb/qY8569eTJUxob36nO6KhS pRJ279yJiZOnqLKePn+J925vVGKQVL7xyTm+dZMmTTF69CjcuXVTZZ1iWbd2LWZMn4Ka1SpTmkxX 0n1PgP0tHwoCwY2AEHJwIyzlw5kyD2kSO7Zu9XnyxHHUqFGDsgs9JzKOqBLely1XATu2/4dOHf/G xSvXf0JuxszZaNq4EVo0b4ZVZDrlZIpajtthw0fh3949cIAIbMDAgThw4IAiGk7VxwS3hnIbc1pF Jos2rVtiNb335UNVT0bKpkTJjdRn3bp11dfNOXl5ZZXE36q+L6XvW7iI0j76TjT4hgIFC1Pqx8RY t4EmA96cuUonXP/27Ttw9cJZ/Nmq9U/tKlK0BLZs2YihgwZi++69SJ8xK+UIvoi7d++gDuU3Zlm2 fCVOHD2EufPmwYNWgI400fAhUuzUpRtGDh9K7d6Hxs3+9FM2p4iMHNER9x891mNct15D1KhSAQ3+ 11hdq5XDma3Gjx2Lhb5kzN917dKZ/m+PqZTq8m/fbQYmsYdE/r1798YBMv8aSvkKlbBm9Uo8e/YU tX31Nvw+XvwENFFaj8KFdMlAeO92zMgR+kvGjxuj/t7guhGbKBXlokWLf+rjzp06YJPrBkWs3tT+ CFwOvcZTLusDu7bpy9q6eSP4NXzEKPTu1UN9XqZsefVieXD/nv5atthEjx4dkaNEVZ/ZU2pMTjcZ hbJtiQgC1kRACNmaaIfTuhwdfhCyZips2by5IuPadRti1YrF6PtvX31+3ahRoimkkiZLqVY+i+bO wicvH/z1V3vwXu8KImOWFSvXIFXyxMhfsBD6UBL7ArS6Wr54gY6MnSPj1ctnGNjvX0yYPBXNW7bC g7u3iFzXYuXqter+wkWKIVf2rPhMpM2r3Rs3+On+DY3+1wT3796mFIFHcerEMfTr1x8L5uvyILOc P38e06dPhxs5ASVJmkKtrHgFyivG48eOqGuKFS+Jgf37omOH9rh89Trate+A5k3q68to3KQZbl2/ iuMnT9KKer8ijrjxdNmXPn50x4ULF3H0yGH99f9t2Yx1q1fg85dvGD12POrWrI4UtPKbOH4sWRYq wDADElsM6lF+4xVLFuHVq0+oU78RVixdhL59+ihLQzQinw4dO6Jx46b44u2JQoWLUM7nZ+jRqzdK FC+KfQc47rQd6tarQ6vstJTqMrqvHhEo3eQ7LJk/W0/GEydORtxY0dGqdWts37YV4+n9X61bEI3T yphepUqXRUxKf7iWcH/54jnatvkLF2liEoFmP2w6rlmnLpnI56vyy5OFJHWq1DhOqRkXEBkH1McJ E8RH984dFBlPmTYTtWtUxUja++UUi5WqVqUJzR41GcqdJy9y58qJQoV0qSn9S99//9V/1L17d5Wa 09PTS31259Z1TJ06Hb18iTzAAuRDQSAYEBBCDgZQpcgfCPBKY9iwoT9BEidOHPXZ7l3bUaduA0ye NEG/t8wZeVhy5M6NaVOnIHWKZOjanVY5ZIqdM3eOWhUlT5kaUVwi4ijl2tXk4sXLytzMUqZMaVy+ fAnXb9xS71+QeZtlwQLdwz9atOjKfF66dCn13nX9WhykfL8sM2ZMxxJKZs+EzPL5s+5BrcnGDesV GdtRHt+mTRpj6NDB6qvXr19gzboNaqXVpXMnsCm6HJlfmZC9vD6rXMI6scdcaseUiRMUIbN8/OBO bexOK/fVePLoAXaS2XTzet3Eo3LVGnj7+qUi4zjxEiBl8qQ4ZEDWHz9+QnQXzhmsk7nz5qM2EfZ9 Ipade/aSKXc7EXRDTGKMfb3HeRLz8eMHbNm8RX9f0qTJ0LBRYx0hk+l+Mpl/48eLC54MKKHPbtKs hVe5LBkzZ0Pbtm3IFO6EHj26weP5K3h88lD9o0kX2tNNlSyJImQWNuN/pwv4GiblVpTLWiPkf/v0 RdHCBVHUdwWdIoA+ZgtGHMpF/eb9B0ygFfXdO7cxaNBgWuFGA3vy9+rZUxEy7yH37MYr/J9l9swZ OEq5o1nKV6yMunVr+bmIczizxUZEELA2AkLI1kY8nNXHe7hp0qTBqbPnVcu1Pce15OQ1ccIEjKH9 PDYJ86sXOfWMIPOrnb3ukf6N9h5ZMmXy3XfkRPb0sGQTJT/MeW+UH5x9+/ZV5sWsWTPpyZPNz9u2 bUNOIvX8lLc3XnxdTuUIvnQRg/ZsOZexJuzMo4mbm5veiYk/syfPW0Ox58JJ2CM3Veof6QT5Qc7C ZB8/fjz1t2YR4DIMjwy9ffuWTM8e+mLtiOyyZM0GJ9pz9vL5ir20x/30mW7fPWWK5PD5/FGnP63k bhApspNVH17xUruzZ8uKy+fP6MtKny6d+nv5qlWYOHEixtAKct3a1erVuUt3Ivy7RPzrEDFSZPxR sgSthQlrX109PD7py/H09FR/a+1Sbab67akfWNLSnqy3txftk/9om3+sPn74oIhSk5++pwmbJry9 YIiZ/z6OHDkyqlWrguJFC2LsmLGYRXvPE8hCMJMIdtmy5ShdqoQeb22c6Qv3/WPO7Nlo81c79a5U 6XJknVlO/aUzVRuK4Xj46Uv5QBAIJgSEkIMJWClWhwDvDzemhPArfM3E2gP56dOnGDxkCDp37oxW Lf7EOtdNtCe7WEfIvoT3jkiLE9qPHjlSV9g3H3LQSY379+7i7ZvXKEd7zvny5VFf8b4mE3XSpElx 7dZt3Ll7H5s2uuq7gR2qWNIRWR04fAQPaQ/xMjlk5c6dC8dptXT5yg/nrKD6LnnKVIhIDlKfyWls 06YtaP5nM5w/d44csl6qW589fYyTp8+SCb0AHj58pD7jVawhsfmvgx3QmGzZlDx85Ghl/mWJ5BIV //zTEcvJ/MzTlE+0ks6WPSeqVK6ovn/y+Ak5tUXHGbpfE21194y2BIYMGUqr9c5oQTpuIF0njNft 07KMHD0GNatWIketH57NP3T8TnvYd5GCnNvs7XUTEN6tjUZ1pUyVEm/PXyR8NxKpRyJz93P9RMiD SNyUs8qGZ4JvUb+VKlmcJlZZceT4iZ/6+Mnjx4TBd1plf8VMItZ+/fuTib0Ibt99QHvsK1CpQjnC WOc9zbobChPs3Dmz0b793+rj/5G5fsnihX6u+e67aRIxkoveEcx/P8l7QSA4ERBCDk50pWyFgBsd m9FEM9uWLFYM8RImRkl6AJ88dVp9bbhi5fdHDh9AQTKtXrp0UX1foWJVDB86APnz5MH7d25o2bKF IlReLa5evRonTp5CvwED0JAclq5evoDq5DQWM0YMXL50Gecvkje3lyd9PxBz5y9Qj96Zs2ZixfIl 2LFzlx8zq3+TJU8KDKVxkyaYOmkiTp49hyNkOm7WtCkWLV5MzkBOcCTu8qHl5kIyee/e8R82b9ER a3NyRItMHtg6+aqIw9As+oFWkjwRSZNGt7rVxNHRiRzKEoFNvxxY5T0ROwcuYYsCWxAWL1mCdeRR HoW8mzXRiKVE0aJIkCQpkVYxnDqtW0FHJIL/7vURXl+/Yy05YO3duU2/d+9OZngHbb+ftgcq0/nc v9q1R9bMGXRF0/56hgwZaYLwD5r82YLef0GzZs1wkBzKXru9R4yYsVG3dk18oFWvZpz3JvOx4WrT 3d3dT/vY7K/JX21a4tTJ42jYoD7htzDAPuYVf5dOncjUXIlIMyXu33+obo8VK6Z+dczv582egZfP HuOfTl2UMx+v0ttRW3R0zROkD2jTpjWt8H0IkyjkXT4FkSM5q+9SUR9wf4kIAtZGQAjZ2oiHw/qS JU+h9iJfvHyFgQMHkSf1VtqrbIiz5y/gxIkTSJMuPTKTuZY9d1k00mYzMzvrlClThhyeEmA2ESgf i5pEQSo2btqkPGEvX76sVmRlaa82sosLqlavgQ7t2+PWnTu0Un1KK8jHcKIjVY0aNVLm8kTkUTuL yuFz0UyC79w/oGmzFihJK61VZOLlBzaXk5HM5BxRjKUQmbz9y6SpUzGIzs9608r0ytWrSscBAwbh 6ZNHmL9ggdLt5avXqoy8efPjX3IQ2rNrp2+Z9ohED//MWbLo68ifP7+qonbdujh37izpr1vhNW3W XB2dYo/x2eT8tICIiicg3G4WrjcFr3CJQDV9tYlNfSK2CzQZYYzT0tGvLNlyYCB5ct+9fRtLiMi5 /S9Ix8qVKynMkyZLgSY0ueDV5bXr15WH+o0bN8msXVxfNpuna9apR3vfp3D33n3cunmTCCytMrd3 7dadJlBkFSBrRSVqN5NyMto/jhMntv7+5MlT6rcNWH+2IowgH4MDtH//lY64Xbx4AT179VTe5Etp 1eu3j8vTMaxMaNiwPuFzDy9fvkDJUqVp/zgmOQX2Ikc+Z8yYNYsmKUsVOb98+RK8NcDC+9z16tVV 0bhY2Int8SMdmUeOEh2P6QjVA19rhpevqT4c/lSlySGMgBByCHdAeKi+CK3U8uXJhc3/7dDvi06a MjXQpmtmzDz5C2DrRp0DkaG0/esv8CswmUxk+SthRyJ++ZemtNrTpFbt2uBXYFKAVu68R/2zFCQn tboB3laqTFnwS5OGDRsRuTTycy2f49WiYvkvpC4FseBXYOJfn6nTZwR4af58+dCgYcNAyxlPe/v+ haNZGcq0QMrma5LRBGGLP2wCxkq3pdHr3z7o5a/CdOR30Ii2OgKSsmXLBKp7A8KTX/4lCjnarVi5 KtD7/tu6BXv2HVDft2zZMtDr5AtBIDgREEIOTnSlbD0CBQsVUYT84MF9nCVTby46khKYaCZiNqGK CALBjQCb1Hdu366qSUye5o3/1yC4q5TyBYEAERBCloFhFQR605GWXOTxzI5QbIL9lbDDjtu79/pz uVZRUCoJ1wiw5aJ0ufIqqpsthnYN150TjhovhByOOjukm1qOwjYaI4WLFDXmMrlGELAIAnw0rwoF FRERBEIaASHkkO4BqV8QEAQEAUFAECAEwiQhP370iKL/zFXHLbQsNRxHt1fP7uSRq52phEo+MJ0c gNzoSAR7nLJEoID4Pem6+PF1YQxFBAFBQBAQBAQBayAQJgn5HgXlHzxYF84wfXpdXtOUqdKgZw8m 5B+wcjhDDjzvRSEJOeoQnwO1s3Ok4AHtiJCtAb/UIQgIAoKAICAI6BAIk4SsOQ01oLi8y5fqgtQH JHx+NTKlsIsTNSZu0nlKEUFAEBAEBAFBIKQQCJOErIX/u37tGtatW0cBGLIiQ3q/EZA0wDlYhBsF D1ixciV5VyZFsaKFf9kXHN/3OgVNYDLnFzuEcMB8EUFAEBAErI0A56vmPNciYQOBMEnIHNUoduzY uHP7JmVyqUuJBRKoSE1jx4z202tMqJxw/THF/G3SuDGFPnRAzRq1KLXeNIOUc347moNW8N4038v7 07yyzpkz8DO1YWOYSCsEAUHAlhDg5xA/gwxjgduSfqKLeQiESULOmSs37lDoRB6svPrNnDEdJTCf iFq1aqFgAV2IQhY2Vx86elxdx6/KFJx+xYpllCe3CNq3axsgoi4UVjFv3rzqO45FzK/cdL5WRBAQ BAQBQUAQ+B0EwiQh80o3OiVhZ+Fk7DFjxMJTiqO8k5IIGBIyzzCjRYumxy8WpeRj2Uw5YgMjZEOw mYwlTdvvDD+5VxAQBAQBQUBDIEwS8szp0/Hi9Rt0794Nm1w3KDJOmDgZ+vzbm5LIv8IiSvOXPkMm OFOg/KPHjlFA/Wb44P5OnxFn9CjfdH8yTgQBQUAQEAQEASshECYJeaOrKy5fu45HDx+AHbuyZ8+O fv36kwOWvcqx2o1S2RUoVIxM1KUxh5KcX7lylUzPHogdNx7atutAKeYCdgCzUp9INYKAICAICALh EIEwScjbdu5UXckmZWfniH7OHs+cOUt917RxI7Rt2xp9+vZTaeb4DDJ7TIsIAoKAICAICAIhgUCY ZiBO7eZfHj58iHHjJigy1oS9skUEAUFAEBAEBIGQRCBME3JAwK5d93N+3ZDsAKlbEBAEBAFBQBBg BMIdIUu3CwKCgCAgCAgCtoiAELIt9oroJAgIAoKAIBDuEBBCDnddLg0WBAQBQUAQsEUEhJBtsVdE J0FAEBAEBIFwh4AQcrjrcmmwICAICAKCgC0iIIRsi70iOgkCgoAgIAiEOwTCNSF7eXlhzKhRePvu Hdzd3VWCCTs7BwwePBAJEyYMd4NBGiwICAKCgCAQcgiEc0L+jKFDBsHryzdkz5ED9hStKwIR8ufP XiHXI1KzICAICAKCQLhEIFwTMmd74hSMcaLGwvlz50weABwJTMJtmgyb3CAICAKCgCAQAALhmpDZ RM3pE1+/eoFZs2cjWfIUqFCu7C8HyjVKVsHmbXt7e3h6euLp06c4ffq0DC5BQBAQBKyGAD+7eEGR JUsWBBQi2GqKSEUWRSBcE7KdnT1ldsqAJ89foGuXLvD28UGF8hWxcOECxIwZI0CgeUXs6OioCNmH ruekFPxeRBAQBAQBayGgETKTskjYQSBcE3KUKFFw8MhR1Zs8wMuV/gObNrli3vxi6Na1c4C9nDZt Wv3nvELm1TKndxQRBAQBQUAQEAR+B4FwTcgMnLOzsx6/aNGiq78PHDgQKCEbgs1e2l+/fv0d/OVe QUAQEAQEAUFAIRCuCXndmjU4evw4WrZqDff3bjhGf7OMGjlShocgIAgIAoKAIGBVBMI1IV+6dAmb N2/GE3LM8vr8GanSpEXPOnWRNm1qq3aCVCYICAKCgCAgCIRrQh44eDD4JSIICAKCgCAgCIQ0AuGa kEMafKlfEBAEBAFBQBDQEBBClrEgCAgCgoAgIAjYAAJCyDbQCaKCICAICAKCgCAghCxjQBAQBAQB QUAQsAEEhJBtoBNEBUFAEBAEBAFBQAhZxoAgIAgIAoKAIGADCAgh20AniAqCgCAgCAgCgoAQsowB QUAQEAQEAUHABhAQQraBThAVBAFBQBAQBASBME/IF8+fx+27d1G2bDlEiRLZT49zLuTdu3bBw9MD Xl7e6rsIEexQsWIFRIsWTUaHICAICAKCgCBgNQTCNCEfPLAftWrWxOu3bqhdpz5Wr1yGCJS/WBMP j0+oW7smPnh8hpOTk0r4bWfniLNnT9skIe/btw/r1q1TqSI/fPjgR8ciRYqgfv36Vhs4UpEgIAgI AoKAZREIs4TMpNW6RUtFxiwnT55SRGaYzpsJmIk4frTYuHv3FpwcHfGZkky4uLgYhbK1k4PnyZMH adKkgZubGwYMGIBhw4bp9eTcziKCgCAgCAgCoReBMEvIC+bNxY07d/Q9ExjJEkfjyxcfPHjwALFj xUa8eHF/2Zvv379X+ZKZjH18fPD8+XNs2bLFKiPA3t4eDg4OanXs7e2Na9eu6evlvMySm9kq3SCV CAIhjoBaXNAzqGTJkogc2e9WXIgrJwqYjUCYJOQXRJLTpk9HhkyZESdGdBw+ejRQgJycHPH81Utk ypgR8RMkQudO/6B9+/Y/7TdrBUSNGhVlypRRb93d3XHixAmULl3a7A4w50ZeIW/btg3FihUz53a5 RxAQBEI5AhohOzs7h/KWiPqGCIRJQm7UoD7OnjuPd+4fMWroIEXIvLq0o5ehuLhExu59+2m16aNW ly2bN0WvXj2RPkNGVK9WJcCRYkd70JEiRVLf8SrVkczcESNGtOqo4tU+r5StXa9VGymVCQKCgCAQ zhAIk4T87OlTODg6YdTIYdi2Y4fq0mfPnmDrf9tQiTyoNWGSzpw5i/59sqTJceHSVYwfPyFQQjYc HzxL5Ze15du3byFSr7XbaWv1HTt2DK6urkot7gOenLHwBKlnz54yQbK1DhN9BIFQhkCYJOSde/bS MSYvvHr9GmdPnVJdEjFiJGTJnBkfP34EP1jjJ0gIRwc7cua6h9JlysLT4yPu3rurrh0woF8o60ZR 1xoIpEqVCjXJa//Tp08YMWIEBg0apCwvbK1gS4mIICAICAK/g0CYJOTESZIoTFKlTo106dLh2ImT SEKfJU+eDLdv3aQzyWVRslQ55M2ZFWPGjUOduvXw6YM77j98jAYNG6FggQK/g6ncG0YRiB8/PvjF q+P169ejUKFCYbSl0ixBQBAICQTCJCEbAjlsxEj0H6hbybDs9DVhFyiQD3169UC3Hj3AntNsfmSH rbhxf+1lHRKdJHXaFgIeHh7kmf9F+R1o48q2NBRtBAFBIDQiEOYJmUmWX5osXrIErVq3xbChg9WZ 5Mh0fldIODQOXdFZEBAEBIGwhUCYJ2T/3bVv/wG9l3TY6kppjSAgCAgCgkBoRiDcEbJ2ZCk0dxo7 EGkevqG5HaK7ICAICAKCwA8Ewh0hh7bOf02e4rxnqREwR+d59+6ditb1+PHjn5rDx7DixYsHCRgQ 2npa9BUEBIHwjoAQso2PgLuUqerRo0f6YzXsRMQRwl69eoXzlMmKhb1+NWFCLly4sE0SMrfl0qVL KuQfh/vjI2iaJE+eHDly5LDx3hD1BAFBQBAIPgSEkIMPW4uVzATmP5GF4Xvt75AIUmJKI3llf+PG DZXAgwNs1KtXT98uWdGbgqRcKwgIAmERASFkG+9VjYw10jUkZ2tnm/pdqHLlygV+sbApnqNbiQgC goAgIAjoEBBClpFgdQTY5M6R1LQA+VZXQCoUBAQBQcAGERBC9u2URw8fYP+Bg8ibNz8yZEhng10l KtkKAryPz9YJCQpiKz0ieggCYQMBIWTqxzt3bqMGZXe6dOU6kiZPhSOH9iNp0qTB2sO8lzpx4kRV x5s3bxA9enQVE5mFYyZ37949WOuXwo1D4MWLFyp2teblzv+yMxqv8tlJjUnZcO+e/06UKJFNOtUZ 12K5ShAQBEIKASFkQr5/nz6KjO1o1fPowV0VStMYQubzwOauktKnT68SFLBw/uVOnTohceLE6r1h ogJzzhvbeqIDJycnRXChYQ/8/v376niZhinrzcfQ3r59i4sXL/ohZC37F0d+Eye1kHqkSb2CQOhF INwT8ulTJ+G6aZPqQQeKpfnVPuIvSZb3PvkBzWTCKyU3Nze1UjJVNJMnP+B5ZcyrMD5brD3UeWXG wnWYQspc7sOHD9WxouASjZSeUppLligUftTT01PFdmbhRB6cq9nwOJamC+vH7WSP6zt37tg8KTP5 aiZqboOhk51/73d+z/334MED1f7QMOEIrjEi5VoHAV442PoE3DpIhI1awjUhM7mOGzMGzi5RUL5C RbhuWK/iW/9KfHx8FOHxw5bvZ8Lkc8LmCpMbmz+5TD4O5N/8yZ+ZQsisx8uXL/2QiLm6BXYfTyDY zH7u3Dl1yZYtW1C0aFFldmfJkyeP+lsjaMNytIkMT0AYN1slLc3hjPs4IEI2JGetfdo9PJnidpna b5buJykv7CKgjbWECSmNrKT+DDMdHa4JedCA/li5Zi127dkHu+9fVUo9zgn1q/CavBosWbKkGgBM lgcPHkTx4sV/a0CsXbtWlRk7duyfyjl79izYbMpmXmOEf6j58uXzk1DDmPvMuaZq1arqNp5QDBgw ANGiRTOqGJ7UbN26FSVKlDDq+pC86PTp02qyZAr+BQsWlHjpIdlpUrcgEEoRCNeE/JZWeS4uLlix bIlaVbJ8+/YFi5YsxYB+fYPsUiZkTsP3u8JlcFkBCa8yTV1F8qrOMMPV7+oX1P3e3t7KBG0sIbN5 m9ts68eeWD9z8Q8LMdOD6nf5XhAQBCyLQLgm5FFjx2HgkKGKTJZSWkY2vX4nQi5UoIBlUbZAaUwO bCrmlZq2WtMchzTiYGIMDaKZgE2daFiybWwN4f1/Fp6U8YRI2/OuVq0a4sSJY8nqpCxBQBAQBIJE IFwTMu9z8itBggTIkiWLSspgb++MNGlSBwmctS9g0jhx4gSOHTsGNvmyGXvSpElKDSbkTJkyoUyZ Msq5ypaEI3L5PzbEJm5t711zhDLUmb2U2SkqOIVXvtoeN+NYqVIlxI8fX49ncNYtZQsCgoAgEBAC 4ZqQDQGpVbs2KlWurD4KTg/lgDqBV4yB7VFqjkFshk6TJo2aPDCJ8erY0MzNJlJbXCHfu3fPT3IM 7RwvO4VxcgxDQtY8zAsVKhTshFynTh19V9y8eRPt2rULcA9fHhuCgCAgCFgLASFkX6TZUzE4vRWZ mNg07v/cMtfJ+9cXLlwAe0waeiZrHtj8L5tT2aEssH1a/j4gr2ZrDCQ2pQe2Z+o/cIY19DG1Dp7s 8NnzgJzqTC1LrhcEBAFBwFwEhJDNRc7E+3jPkk3O/lffTFi8UpwzZ44iXG0fk//lVTMfJ2JTOjtB 8WcBne01URWzLudVJJuftWhiWiE8WXjy5IkypfOEwvDYFq9+2TzNk47AkmOE5D6yWUDITYKAICAI BBMCQsjBBGxgxfpPkai918y1/t9bWb1Aq+NjSky6vJdtKEy2nON48eLFavVuOKHg73hCwWZ2S3ij hyQW3C88QWJLgBbUhSdQmgWA28dBREQEAUFAEDAXASFkc5Ez8T4tUIT/YBFaCEn+N6DvTKzG6pfb eg5mSwHCTmYcKpOtHOxUd/36dUyfPl31GWPA+/t8ljyw42uW0kPKEQQEgbCLgBBy2O1bi7bM3AlF WDFJ8wqYvbDz58+vVsj+PdrZW9+aVoDt27crnwQW3gbhiYDmQ8C6yX64RYe/FCYIWAUBIWSrwCyV 2DICbFr3b4pnfbVJCK+AmWyZ5LSjUf7bw2RoTS93Tm7Be/osy5cvR6lSpfS68QpeRBAQBEIfAkLI oa/PRGMzEGATMwcC8e/lzqTLyUJ4f5yTYhju4bMDGyfC4H/5OsOzywGpENCZajNUNeqWhg0b6q9j pzrOFsbnt0UEAUEg9CIghBxCfccOQppzkHYOmc8Ws1OUNVda5jZf019LQcnvbVn/NWvW4OTJkz+t hJlsOUkGBy8xdEpj8mUzNJt/Y8SIYVVztKl9wuZqNl8LIZuKnFwvCNgWAkLIIdQfly9fVsTLTkGc HYgdhpjQNAeh4I5U9bvNvnLlisp2xfo/f/5c/cs626r+rBt7Rfs/L82ErJmseS9W8xJnQmYztua0 9bt4yf2CgCAgCASFQJgkZE86fjJq1EisWbsO3wmBqtVqoE2rFkiZIgVvDOox4WMqTRv/D88pMMeb N28VmdjbO2Hjxg1InTpVUNj91vf88NdiUefKlUuZQzVzqX+z6m9VFEw3s/5adDH/+kvawWACXYoV BASBMI1AmCTkM6dPYdDgIWjRoiWtfhwwasQwrCVyvnHtsp89xC9ffPAfna/18PJWoRN1e4X2tJKK HOydnoImB4F5ILNTTkhF3TK24cmTJw9Sf8OJBU82eCXKK1VuG2PNK1Bt3/VXGa+M1UmuCz0IzJo1 C8+ePVMKa1YIbULaokULJE2aNPQ0RjQVBCyEQJgk5By5coNNqpxwgWXRvDl4+eoV/fVjdcyfMxkw QcSKlxjTpk0zGVJe4Rq7mvVv+gxOT1hjc/ea0uDf1Z/JmJ2POLcwJ8C4e/cu9u/frydk3v/ks7yM S3Dpb0p7tWvNObYVHPr/SvfAvMTNaa+17uF45ewwxyQ8fPhwNGjQAClTplTjgSPTiQgC4RGBMEnI vFeYMUMGFSN65fJlcHCOhD69e9FM3C8h88PA09MDb9+7o9H//ocMGTOjZ/eufkI9+h8UHBiCj5zw Co/3UJlkdu3a9cuxww+ZVzQhMCVWtqFXr7GkwNfxiz2Gtb8tMai5LMbyd/RnQucH8IMHD5RuBQsW VOSsCU9s+MWr5+PHj1tUf64joLCfv8KGdeRVO+/zm4r/4cOHVdHG3mdMH2k5pP2XyZixB/nGjRuR OHHin0Kr8oRTC13KTmsB6cS/A47lbc0gL9r+POvGv1f+PfGL9/CPHDli8xYiY/osOK/RcokXLlw4 wCN7wVm3lB18CIRJQma41q5djb37DmDVimXIlDU7ihcv9tPDiB8GdevVw4tXb3D71i2sI0/c+XPn 4DA9EBInShgg6qlTp1bHYzSC4Qclp24MSk6dOmVSHGr+wWnRu4x9UGrXsTk8atSoFiWEM2fOmKw/ k4W2smZPYLZY5MyZU09Whu3ilTHv6TNhBIf+PJFistcmFZqHu/aedeW/taNNGv6mJMfQ2pMqVSq9 OT6ocWHs9zNnzlQxz/07pfFq/BaN3f/++8+PN7imf8uWLRXuPE5dXV3VJIPbzoTInuUsXEb16tX1 Pg3G6mSJ61gXnijwZIK3QYwd65aoOzSXoRGyta0xoRmz0KB7mCXkOnXrg1+1a9VE9WrVUbRIESxd tgz16v5IuxcpkgsWLl6q76fyZUphx+69GDp0GGZMnxpg/xkmrmfSY9MrJ1UISnilYmpiCHNWufxD ZZNfzJgxg1LJpO9/V39uC682f3WkS9tPZvN1rFixTNIvqIs1D3C+jkmWjwnxtgZPGHj1fPbsWUXI jF/WrFlV9KuAwpkGVQ/fz7G7edVnSeEjWNwG/4TMOvPKkrdPtP15rpfHGreTdeHxyRMexpT/5T5Y unQpmjZtqq7he3nP1tjtF0u2i8vi3xHryLqKCALhGYEwS8hap5YqXQZRyUnr48tXOLD/gB9C9t/x mnewsaZGLQOTMQPImjP/4HAIC0v6M1nxClHzMWAC5r7U2mjO5MNwDARHCE1tReR/bGrvtcmb//fa WGDibtasmV5Nzt7Vtm1bY4ZusF/D/REUZmxhWbJkiX5Cx32kxQ3nVWLjxo2DPYd2sAMhFYR7BMIk Iffp3Rs7d+9GkSJFaanwFc+IjNPT/nCnzv/gwf17aPtXOxQr/gciR3LEkqXL0L1HT7x7+xrbdu6m 1UIk9O3zb7gfGGEZACY3XlVywI+AJCRzS1sDdzZfs/8Dr5ZN8QsILt24L4I6d88TDbYSsM78mjFj hppQMBkbpvcMLh0tUe6bN2/AedFZ2ILCWwbaJJAtWrwdJhK+EQiThFybzNKPnz5VDlt29EPu0KED 2v/dAenSpsWli+fBgfk9PvugXRvd/trRI4fJxPeVjj61R5UqVch8JqazsP6z4AehNVf9YR3PX7WP ceZ9bs6N7f+MOpvJn9JvlbcMeBtB29bRxQSwVyTFJm02q9etW1dfzenTp/Hnn3+GKljv37+PVatW qTbu27eP/FqK6/OLZ8uWTQg5VPVm8CgbJgk5Z85cWLRoUYCIdenchWanUTFk8AAUo1y99erXDx5k pVRBIBgRMAxdyiSnhS61dpILY5rI5uh169bhwoULATql8edsfubkHZrpmtvB++VdunRB+vTp/VTD q3veB+d7glpZG6Ofta7JnTs3+MXSvn17TJgwwVpVSz2hBAGLEvKC+fNw99591fTq1WvQ4Mulh2Hx ooW4dfsOkiRNjjatW6rP+Yc1aeIEOiP8Gs60J5QoURK0b/djX4s9nxdR4ntvby/yDLWjuMJlKavN H78FbfkKFdF/4BAULVr4t8qRmwWBkEKAzbdMYmx65lUkhy5lImMC49UXE5ilncp+t62sV0BWCcPP tb+5Lu1aW7VisNc7H3kMSDiwCZ8UCEy4r/jFpwoCyjL2u1jL/aEXAYsS8qQJ43Hh8lWFBnsvXzh3 Rnl27tqxDU2b/TAvxY0bB5GcHfFPp87KlBUxYiSa7Xqq+2ZQ0veZM2fQ0aLEqFa1Cq5ev6FHd9So UbhEMaCzZM5sNuJdu3Uz+165URCwBQQ0T3rNEY2P4fGKkgmNyZpXy/y3LYUw1TzW/evE71ln/0f8 tGNbxjpYWrtfOC82n6tn4edSrVq1VGAbFkufcLB226S+kEPAooQcI3o0fUueP38BD8/P4MMrkyZM VJ9zYI5v377j6tWr2LB6hSLjrHRGeMOG9Th5/Bj69+9LR1EuYcy4CUifOoUi46jRomPHju2I6OSI Q4ePSBSfkBsrUrMNIcBH2wIjq6DSRNpQM0KtKtp5em7AVgq/W6JECfD5cxFB4HcQsCghcyIHFkcH e3zx+Yzx4yegSaMG2LZjpzI5O9gBPrDHtKlT4faGIlc5OaN1m9YqkQO/Fi9agNt378OBjmh8+apL sv7x4wfMnj0HHcgpq2PHjr/TVrlXEAgzCATH0bYwA46VG8Je37x9ICII/C4CFiVkTRkHByf4fPHE oyfPMHbsGHzjL77T/79HoOxLEeBGoSe9fL4gVuxYaN6iub4NPl+++pLwJzRv3hI7d+zClWvXsHDB fCxauFARc8uWP67/3cbL/YKAICAICAKCgK0gECyE/I2OLLBsct0AZwfd38WLl8C50yfg7eFNDhu6 mNJ82beviq6V2NN+EouHxydkoWANl8m0PYeywixdthQHDx1GK0qh6EEz0Y4d2tsKfqKHICAImIEA O6OxyZ3PIPP+Mb/XZVuLIHGszcBTbgkbCAQLIRctVhzxY0XDslVrQA7SiBkrLrp374bmTRvD/dNn xE+QGG9fPadziW7kwDUT3bp2UeeA3T+4K1R96EgDH6L/+PEjWrVpg3Tp0qLEH6XUdxs3bhJCDhtj T1oRjhHgcKVaYBI+f/zixQt16oJN8ewUFVJhPMNxl+ibzn3AIYE5cImhE552NpyzcnFoWU34FExL OhP+9MVL1KlTD23atFJftf+rDW7cuqPCtAYUFnXunNmYMnUaOSE6q5M0o0aPRflyZczqAt4y4Ohz nBzo+cvX5Ewcm8obhbx58qjy+Dv2aufPkyVLqrzcZ5Pz8JZt29GzZ08UL1ZMX+9LGostyXLrTvzj 5vYOBQoWRq9ePZCSPOfd3N6iAeU/iJ84ORYtmGuWrr+6yaKEzA1m4QhIadLqPA5Z6tVvgMKFCuLl Gzf1/i/KPbxlw1ocPXkaEyZOxDtq5KkTx3Gc3rO0atkCI4cPxdjxE9GwUSN4GezPjBo10uIgSIGC QFhFICBPa21Vyv9aWzRHND6qpT0vmICZlPnFwkeBbO3Y1i8for6xxK2NZXDVx2e8ly9fjhs3bvhJ OMIkxn3TjU6qpKUgS5p8pa1GTm7y5t17vKCoiDVrVgfHo9+7Zw+uEyF/polWQJKYTgcUoRwD0chx 19Pzk0owYq4cpQxrpcuWRdJkyVHqj5JYSFuc1WvUhOv6ddi5bStGjZuIIoUL4tjxU/hv6xakT5cG 7Tt0RNp0GcEe84bCFtrNW/+jo7guaEaLyMWL5mMphW1dQhOLMqVKYMeu3UTIycxV9Zf3WfQXmSNH TnyL4IAkiZOgNYWnPEae06/fvkOGDGlVeLsC+fLA+8s3lfd00dLlmDplMnbt2YvFdNaYI/Gw52Kd OnXRonkzjB87Fhy95tjRo2qWlitXLlSqVAVZs+hyHFtKeJBxFh0+JhI9ekw6w/ljoFmqDilHEAgJ BPh3w6THEbIMz/NyQA1+sRUqoNCZTIbBtULV9ODfdmDHspgQtAAhgU0otGxd1sCVdeb0o4ylf31Y D07HyiEx+biZ1j7t2BZ7w4em4CX+8fR/Djygc+G6jF1RFSFfvnQRW7ftQLMm/1OTKjvainCn1J6c bY0nXJEjRyFSj6Se5xUoJgS/Hj16iNhx4uIjjVOO2JYhfQa4RHbBTZoQfKBVKgdTeUMWlRu0yuX3 fJQ2WtRo9KxOp9RlS8uQIYPV3/90/Addu3ZGfPJPGjVuPP4jXdauXEn1RsX/aHG3jVbEkyZPQSTH CIhCEeDmzJ6JiMQ9hqL1cZZs2ZUFt2zpP1CLVv6LlixF5Yrl4GRP7aV7g0MsSshz5i/0o+OOXXv8 vD924pSf9xMJmMCkC83C+BWcwg+lurVr0mxom6omeoxY+Ouvv9C5U0c5XhWcwEvZwY4APzh5kstE wbm4Na9sftjwuOdwlYcOHVL7toYPWb6Oj/AE91lafoj+SjTzKJ/1ZcLT9OeHP5u22UTJZm7DLF5a eWyhs2SMbq573rx5OHfuXICRxo7SooExDijSWNeuXZExY8Zg729LV2B4NlwrW5tkBFwX+wrRGXhH B3T65x+kpVMzTJwRI0XBccLnn06d0Kv3v1i/bg0uXrpM+QN6YfSoEbTgOoxChYtSnIoWsPvqhQVE ert271Gr3Ab16uDshUsqzGiXTv/AzikS/tegHnpTbvvkKdLg2rXLyufgOy2mrl29QkdkY5C5vLVS L2WqlOrfSC6RVXrPO/efEPE/Up+tWb1SXXvi5ClkyuA3Cpxh27QwrpwWVPEDlRPcgWosSsiWHhTB Xd5XjpbzyZPiy66mGVtO1K9dAyNHDEN9CqfJM9ughGfExq4krBmkwZIPIw2D8Kq/OYEpbAn/wLJA +f9c62f+3NL6c3nmjB/+fXE0LMMJhZbGkz/jHN086TBMa8rkWbJkSYu2gScths5nhs8F/4FNtOeB Rl4B5SvmsrS0l0E9Y0LL92zVSJ4yNRrWq4URI0fRKnQqPn74SNuNn/BHmTJkyn6piLElWT+TkFl5 9eo1ipDt7exVE9kROA/t9zIhT5o0BU8fPyKn3uuUFCgL/mrdikzft1GmXHnazy2IKpUqYc36DZhK +88dOvyt7nemQFMePt76scCTNkXIFL1u0uTJ6NNvIK5eu45UKVNRNMm7iBM7Dl4+e4qHlGyI0/AW KJDfj3newd6OTgO9UbHHe9G+dMrU6VW4ZW2bJbj6JVwTcmQyqeym2ZcmWq5ZZ2enQPFm89+RI0fU zIwHIa80duzY8cv+4WvZ5GXKnp3mbcoPGGNJQXvI8oxd+9sSA4fL4tWItfQ/duyYRfVnDPgBbqr+ vIrjHzYnNzBGNMx55fnr1YQxpfm9xpzxo+U+ZtLQSMtwXAQ0Rhgj1p/FHBINqGU8htk8bg7+mmOR 4QpZS3vK/zKx+c8zHhz68ypdix9u2EbDiY0hnppex48fx4MHD36yQjx8+FAluQnInM1tDWolpqXj 5D1YQwcr00eWZe5gfbzo99KiZSuKW76WVqErwGdmosWMg+t0Wmbyzh147/6RTL1RaB1Nq03K3GUo /Dv7m8zNgwcNxB0iTM7K503l/UkpQ7duXIcbFHb5zKkTKFSokGovm8M/EOErUYd2KOIb/afhqT3L 2ZKSJ18BFVyKk3uUptDL+QsUwnvK7te3/wA8fnAPDx49xkN6JaXokJronu9eKixtt569UalyFSRP lgzPicSDU8I1ITOw96nz2URy7OgRXL/9ABtcN9Eehm5vIiBhpwaeybGwOY0ferwf8ivhzuW9EVOC OWgPdH4oBvXj1OrW4v+yiYxno5YS1p/32U3Vnx9K5uifIUOGn36wv9sWXk3xQ9DY1Z+WotG/SfdX emj4s/6WfkiaM360lZ2x44fbxuSWmULTWtKpiomTszPx+DEFf20VqZlP1bPXN8xmQCZVTX+O5W3s JMqYccV6a/iboj9fmyhRIgoDnMTPhIjx4PHBnzNxGPYPt4t1N3byElz709pk1BAfxiGgCZB2jQd5 ZXN2rj8pTHLvPn0RgZ5dTIj1KUvXJ9omGTZ8BGrVqIbp06b99Czx8dGtaAcMGICOnbti/IQHytkr S+YMWLrwLWFkh9lz5qFsmdL6Y3JffY/M8vFZLy9KNkJ1Xbx0CXkoh8LJU7rt0S+0atZk5rSpuEOB p1LQSv7c2fto+3dH7N+5TRGy/98Ix8SInzAx/iHzu6FoiyNjF0nGjC/Da8I9IfP0ige/E4XmjECh PddTVpp05CGeKVPA+z58LXsQsvCPgX9Y2vtfgc+mNVMejNrDx5yO570bS+8BWlt/boMlxdDhxthy DYnA2Hv4Ot5LtCQhcJnm4m/qKpfHKOtvyQkdl2kO/lp8a1Ow1/T3vwIzpYyArjVVf20Pn1f4vEI2 tFAwIfNknj/nCb5hykluc0Eyy1pyQmRq21kHjsvNzzfDiQHryePQ/2ST2/qWLCCfv0TAJw9P9Pq3 D65cvoSlK1bh6+dPcIgUUanwncImc5AnjjyhxQH/4utL8P697shrsuQpFR7vyBGsbPmK5MhbCU8e PUCbv9qjYYMG2Lx5E57RNsbOPfuwbOlidQ9PfPr264uOnbqgMO1HjxszEnPJnylr9pyUsrM2Pn38 hEGDBmDM2HEYOmwEmpLDWeECBTCUHMHcaaUcNWp0aqejHqZvNPFg4aN5/oV18/76Hc9opXzx4kX1 tR2Z3dnBzNjJ2q/6I9wTcgry+P6TX3SO7taN4liyZBHu0w/l4IEfpuzAANQC+hsz4E0lY2PK/JVe v3N/QPeK/sYjaoolwdhSQzP+WhIMY9v6u9dZGv/f0Z9Xmjyx80/IWppMwxWnZhXTPMx/Fwdz72fS bdKkSaALCP+TPA513KlLVyKqCPrgTu0o1HFUcpKNQmRXuWJ5rFq5gkzGd4mV6dgrOc5y1j+WRGQl 4PfZ6YQOS8XKlSn3wThcv3kbXbrqnHpbt22n9nn3HzxEhLyFPPB9kCBhQn3zWJ8O/3RWaXUPHTlK e8XXVJk9evZCiuTJcOfOHbyl88RtKKZF/Xp1lWWi97//4sSpkxTm2RF16FhuwgQ/fIaikVMg3584 6c9Hm3ibs0vnf+gol48+xa+TcyT06tndIla9cE3Id27fVpG/okePQQfX46u/WYxZ8Zo72OU+QUAQ CP0IGOajZlI1zEdt6EFujFOdoRXMHItYcKBpig8KrwxHjBrjR42ChQqDX5oUK148QDVTkJPVdMrw pwljyStd/9K4aTPw61fyZ4uW4Jd/YTP63Ll+g3i0pVgYbdEuwOI4eIihToYXsRl9HMXHCC4J14R8 7txZMl80oZlcbOTMnoUCk5xC0eIlMXPGjwESXMBLuYKAIBA6EWCyukR7lexxywTy7Nkz5eCpmZ85 aIalfQhCJ1KitakIhGtCrk1BSNiBhfc92Clg1OgxSEWzqSgGYeFMBVSuFwQEgbCPgLbPzmbmhGQ+ NfSMNnW/OeyjJS00FoFwTcgMUsZMmY3FSq4TBAQBQUDtrXJs5sDMy7wHHFTgE4FREAgIgXBPyDIs BAFBQBAwFYGQdrwyVV+5PnQgIIQcOvpJtBQEfgsBXs3xvqaW5pAdcbTzruwBzMdzrOnJ/VuNkZsF gTCKgBByGO1YaZYgoCGgJZngyFBMvmxOvUZHQ1avXq2CLDA5c/xqPu5i6SNDluoFLba1dtZT82zm /VpuE79k1WoptKWckEJACDmkkJd6BQErIsArZI4KxYTLAR/qUvQkTjLBogV/sOUVMuvo5uamQqDy hIJD1vKkQiNkXu1rzlVWhFWqEgQsioAQskXhlMIEAdtDQIuwVKFChQAdkZiI+QiPLRMyr4w5nvph ynvLwhl4OOa5JpzSNWnSpOJMZXvDTzQyAQEhZBPAkksFgdCKAJMt7xOHVuGYyByjPUeOHKoJhgkz +D2bq7UVf2hto+gtCAghyxgQBAQBm0eATe5Mur/aJ7aVKFcBgaltGWjtYBM8BxLhF28j8ITDli0U Nj9AwoiCQshhpCOlGYKAIGCbCOhS+XnjxIkTinz5xfGV9+7dqxzp+HvOGBdQ7mTbbJFoFVwIhElC 5j2z1atXYePGTYhEM9BixUqgQf26fhJQM6Bs4hoyeBDevHXDe8ouogvu7oAxY0YjceJEwYW5lCsI CALhCAEtuQTntNYChhSn2M6cY5mFV8v+czqHI3ikqQYIhElCPkHOHg0aNETefPlwhvKwLpg/HwsX LsLe3TthZ89ps3XCCajHEfl6ffmG/PnzqzOaEYiQJcqO/EYEAUHAUghoTnX169fXO9UxSRuaqD9+ /KhI2dR0mZbSUcqxDQTCJCFzPOoVK1aAfwAXzp9XCauv37zJmb/8iC5YQhTEiRoLx48fN7lH/OcL /VUBTPbW2iNiM5ilJbTrzw86U/E3JeONId62gr+t6M8e0qEZf17B/q7+PPaYdI2R4Bg/xtQr14Q8 AmGSkONTnFkmYxb+ETCZ2EX4sTLWYOcfCa+GP7x8hkmTJiF5ilSoXq3KL3vl8uXLcHd3V2WyI8YT SpbNe0O/En4wsnnKMNm3MV3PM2ZTAzVwXedpEsIPQUs5uXA5bygBubX0v3DhgkX1Z6zfvXtnsv7m xCRmrM6ePauzttDflhJzxg/rz3uXpggTD+vPfW0J/TUnJt4SMmX88H382/Ty8jIp8Tvrf+7cOZvS 39i9YQ1vY8YPP7v4+uzZs6tz5ZYUfu5wfwXkQMd1Ro8e3U+f8DPKdcN6vHf/QNuA7Jym06ZuvXqI GyeOJVUzqSwv0mXhosXK8hCDcjM3aFDvl/cfP3YUFy9dBh8P5CN0mrx4/hz/bdum8ODfU/4CBdUi j+XVq5fYsmUr5XdOhjKlS5mkX0AXh0lCNmzokMED4eXzBd27dSVztd8HJD80s2XPhifPXmDgwIH4 SMdCSv1RCsuXL0esWDEDBJeDK2imJR6cTHxBpVrj67guc8SchyLrqDmLmFOn/3usrT8/YPhlTtsD a6+5K3xzdGDdtXy5lsCfy7D2+LGk/vzANgd/c1f4jL8lxz/r/7srZFPGgTHjRyNkc8ZnULrw8+3K lStqEWE47vhzft7lo63AWLFi6YvxpklTy+bN8O6DB4VjjUZY6Z6zxYqXCFZCXrVyBebNX4C/O/6D qpUr+WnWzp070KdPH5pc6iZnTKSnz57BwP79sMnVFSvXrEFk8i+KESsOJowbgyePH6N06dJImiwV qlar5qesK1cuo3nz5uqzaNGi0UTxC+rUrYfJkybgwb276rsiJUoJIQc1sHp064Ydu/YgU+YsqFe3 FiLQf4bC5uoDh47oPypdshh27NiOWbPnoHevHgEWz8muNeEVMkcPypIlS1CqYNeuXWqGZYo5ih8C pu4p8Q81Xbp0auBYUvbs2WNV/XkWbknZsWOHyY4zWtxnU/Rg/Pm8LB9nsaSYM35Yfy3UpLG68EM3 Q4YMQU4yjS1Pu04L22nsfYwjP0hNTWWo6R8lShRjqzLqup07d5o0fszRXyPZ4Bg/RjXS4CLWhbE0 JHwtRKn/svgaHu/fHSPj/t3biBolcqDV+d8n/9W+OVtIAhu/TLCXKSc1/y5KlSmPcmVKq2v5ecmr +ymTJuL06TOYOGky6tSuiQrlymH82DHIlCE9etLiLH6SFKhasQxGjh6LQgUL4Pb1KyoN7+Ahg5Ag fnw/+jvSOGSp16AxFi2Yg1o1qmLxogXIkTMnalSpqCNqihRnCQmTK2QmykEDB2DMuHHInDU7dmz/ D4kSBew1bTgDjBJFR2InT540Cls2pxlrUvY/uI2qwMyLTDVTGlNNWNDfmHb6v8bUfWe+X0tWb059 gd1jLv7m6h+U1ceUtvGD1RwvYtbdXP1N0S+oa3kibW39LT2hC6qNAZGsfwvFrywWusmEPWJE/7EQ GNS/LzZu+Q9r1q7Hnp3bMGXadFSqXBX5cufAiFGjaYLvQ6dZkuDhgwdkBi6ESZMnwplItVWL5njr /hGxY8Wg7cBTtGKtjuHDhihSffn6Ffg5nTFjJlw8d1qpvWnjBty5dR1t2rRB7ty58Zqu2fLfdqRL n5FO19RDvHjxyPJZEhcvX8Fnynv/6ZMH4sSOrepmGdCvL520eYv5CxcTedcKFKpv376rBdVff7XD 1m074f7ho8kLpqD6IUwS8oH9+zBq9BgkSJSYPKzn0iCJrswvkSK54P07N5o1TSJTdU5EdLTHzt27 0bZtO7i/f4tDvmH5Ro4cERRu8r0gIAgIAoKALwK8On37wR3dunUnq4YjvSIiR67cGDhkmNqTjehk R89gdyLNVti94z9avZ5GyT/KoH///vi7bWvMnTubVrqlcWjPLixYvARduvVAj26dUZHuXbhwIZmk K+LMqZN45fYe69atR8WKFTB29EgcO3mKzMd10bZ1K/1q2p5WySyRyXzOZMyiRXFLnCQp/vyzGbZu 30X7wjvU1th9mhBUqlINzZr8D194e4XuD2gr4Ou3L3j58gVNDoYjRsw4qFi+LG1zGueoZ+xACZOE fPTIUfzxxx+IHTsOli1dqu+M6tVrIkvm9Bg1ahQKFCqGurWqqXi4H2im4+39Gdlz5kLt2nWQOlVK Y/GT6wQBQUAQCPcI6PaXnVChYkW4RIqo9p7Tp0+PTh07YOLkKQqfGTNmIWWKFGoPlqVKlcpqP7pM 2XI4de4CXr2kle3Wreo73tddvHABPZvfk2OfN/bt249YtKp1cImOmjWrq2s0czbXG5Bj23fSSRNt 649XuNNnzcb169dVcJZrVy8jSrQYuHrxPCpVqoTHjx4iXvzEtHX5309+GxfPn0Xfvv3wlbY+129Y h7x5cuPkiR/x1C0xCMIkIQ8eOjRQbJrT7Ijl7/Zt0ahhA3Tu0sUSOEoZgoAgIAiEGQR4K45N9YZb Btq2SUDbCPydAxEjp/G093XqYjAiuUTyxUR37pqv07YJtW0ArTzNIz9GzNgYMXwYbQd+UU5ikYjg 2XdnCjlRfbePSGZnL0QkYtXu4+8N5Zuvm7ehl7i2Qv7ke/SM/STWr1uD+w8fkc5p8OD+PVSrUQtD B/TB0+evQdZp+HfDzZEzD2bPnu2nLks71YVJQv7VryICHX+aN3+hImMRQUAQEAQEAb8IMMnEjBlT 7Y8aOpVqjmoBOVp5UdTDz1/sdIRrp6OyhRSQaTRtHcZPkAhRXZzRrl1bFCpUkI4gxVDfnz5zFg8f PsSZM7q94ChRo6AABWhav2kzLly8jBnTp+DZ0yd48vQ5JRXJro4uRozy4/SLRrKHDh0mc3Njva68 x5wjaxacv3gOXbv3JEtoDcyj/eFYZDFNmSK5qmvViuVkLh+IrmQaT5kiKXib88jhI+qkjaOzX6c0 beIQUMAo7TtjfYmCGmvhjpDn0SAREQQEAUFAEAgYAV7B8skRzevb/1X+T34wgadMlRov3rwjy2N7 8o4nQiYHr+1bNiEukbHrBlfs37MT4ydOwtLlK5A2pe6M75ZNrnhDMSDOnr9A+8yV1NGlmtWq4gMR 6LIli+Hp8QFXr15BXDIhb93sCk6x6RAxqn5/t2Gj/2EbnQ/esmkjWtD+bocOHSkmeE7aN45LTlfb ULtWLfKGXojLF84hWYqUWErbl7np/PDRo0fRh0zPsePEpz3vLsqreuWyZdjoup5M3y74t09fOBhE dGRzeAKKbRE3btyfAHN21n334tkTtKe2s8SNFx/9yFFM28s2ZZyFO0I2BRy5VhAQBASB8IiAKcct nYmwDh45pk6c8CpWmZKJpNkzmlfT7DGeM0c2dV7482cvWp0uVZB26doV7dv9pY7Y8TWa+Xf7zl0U dOmzbkVMZUf1PVJ0is4Uszg7Oal/09Ee9WEiV95j5qNOMWP+OBudiDyoD9LK2ZNW7nzqRjN9830c TIVX547kfOZCMRtYdu7Zq/ek93/CIE++/Lh9+3aAgW2yZc+hvlMBpj58UGU5OOiOX5kjQsjmoCb3 CAKCgCAgCOgR4GBELIGd/+bz5PxisuMcAizM25oXtCGUdmTy5uv8E2NAR8HYoYtfAdXrQJOBqPzy d0Y4oCN9mv4BdSlbDAI7BsjEq32nmeJ/Z1gIIf8OenKvICAICAKCgEkIFCpcVEXR4rPBIn4REEKW ESEICAKCgCBgNQTy5S8Afon8jIAQsowKQUAQEAQEAUHABhAQQraBThAVBAFBQBAQBASBcE3I7A14 +NBBjB03XnnFpU2XAf/27qmcAMzNriNDShAQBAQBQUAQMAeBcE3IH8lNvWL5ckiVNj2defOAK6Xl WrBgIQ4fPoD0lDFJRBAQBAQBQUAQsBYC4ZqQI5Kr/opVa1CufAXC+zvy58mFcxQhxts31mpQncBn 5IxNum5OPtig6g/se1NSPBpbR2jX35r5bG0Ff3PzCVtafy0tnqmZm2xFf/6Nh/bxY+zvXK4LWQTC NSHzg6JylSqqBx5Qxg8+tM7iN2uy3w66cOGCOoTOBMWh2x49eoQjR37kVA6oO/nB8ubNG7Ny05oa ko3rOnPmjJooWCrOKpfz+vVrq+l/9uxZi+rPfcJ5q42dPGl9yIf9TU1lyVidOnVKPcAthT/rY874 MUd/1pv15/FtCf21+MQc5MEU/Pk+xp5/Y/7Pkf7qkcn6cyYhS+qvBbwwVX/Gn/Xn87fGiIa3MeNH i6KVK1cuivWsxYs2pha5xpYRCNeEbNgxc2fPxLWbt1C/YWOk+kW2Jz78zT8w/uF/orinL168QJw4 cYLsYyZ/c3KqmvNQjE7pJvlHas69gTWE2xya9Wf8TV2h+Y/lG2Qn+17A+PMq05L4mzN+fkd/tv5Y Sn8O8m8u/ub4cjD+ltSfCZnJ2NTxw/iZq39Q40cjZHPKN3Ycy3XWR0AImTBfMH8ehg0fSbFN46Hz Px304dQC6o7kyXXByVk8aN/51atXKs1YUMKzfFMJzZwHKv9QU6VKBX4oWVKsqT/HrLVE1BvD9nMk H3PwN2VVxPUx/mnTplWhAC0p5uJvqv6MEesfWGQic9vE5ZmCv2EiA1OIkOvgzECmrKqNaZOp44d1 ZrI0ZSKikWxwjB9j2ijXhDwC4Z6Q51A6rdZt2iBmrFjk1LWB8nPmNbpX2KRmrEnZlIeR0QoEcmFA WUl+t8zwqr8pZKBhzOPC0oRsLv7m6m9JQubxaI7+rLs5+lt6/PMK3xz9tQmaqb+94Bg/puog14cM AuGakB/T/i+TMcvMmbOQOVNGPH36VJkbY1MybBFBQBAQBAQBQcBaCIRrQj548CCqklOXA+2Pnjp5 Avv37VW4p0uXHp06/WOtPpB6BAFBQBAQBAQBhGtCbtioEfglIggIAoKAICAIhDQC4ZqQQxp8qV8Q EAQEAUFAENAQEEKWsSAICAKCgCAgCNgAAkLINtAJooIgIAgIAoKAICCELGNAEBAEBAFBQBCwAQSE kG2gE0QFQUAQEAQEAUFACFnGgCAgCAgCgoAgYAMICCHbQCeICoKAICAICAKCgBCyjAFBQBAQBAQB QcAGEBBCtoFOEBUEAUFAEBAEBIEwTcivXr7A+g2uSJ8hI0oUL/ZTb3MQ+tWrVuHDx4/w9PRUgezt 7OzRpEljxKJkEyKCgCAgCAgCgoC1EAiThMzkOnrUKMyZMwdPKFlE3fqNAiRkT08PtGrxJzy9vygC 5vyldvaOqFixohCytUag1CMICAKCgCCgEAiThHzm9CkMHDQIJYoVU4TMuUwDEibgSJFcECNOdDx9 8lBd8p1eEYwcHE6UlMLYBOGc29hawjlYLS2iv/GI2hL+PMZNFUvrz+WZM35Yd1vQn3NKm6M/424L +pva/3J9yCEQJgk5e46cuHz5Ml48e4L9ZQ7+Mqcqm6k9PD7h8OHDiBc/AdKlTfPL3nhEKRs9PDzU D/TTp094+/Ytbt269ct7+Ef5kczipv6oWTdT87ByXffv36eJRiSzHgaBTVw+fPhgVf05n7A5D7PA OsIc/Bl7Y/Nda/Wyznfv3lUpPG1Bf87la4po+keMGNFi+rMO/FsxZfyzHnwfbyuZMkHg++7duwdL 6s9jwBz9+T7Wnyfuxog2XowZP/xs4OuTJ09udPnG6CDXhCwCYZKQo0aNisyZM+PRg3tBohs9ejQ8 fvYcRYsWRfQYMdGqZSv0798XXEZA8ubNG7x7906tjD9//qzI+fnz50ESspeXl0kPJLVaNzNBO08S WD9LEQKXY0393dzc4O7ubjH9GUtO+m4qHkzIpk6IuC4eI0w+ptb3q0FkDv7m6M868/ixlP6GxGoq HuZOiCytPxOrOeOHf7+mTuj4HmPGj0bISZIkCfIZJxeEHgTCJCFr8POg/ZVEjhwFBw8fxRf6wfGP v0Hd2hg7djRy5MyBRg0bBHhrjhw59J8zIXNOZSbzoOTMmTO4efOmSbNZfigaaxI3bHOePHkCnVAE pWdg3587dw43btywiv65c+dGtGjRzFU1wPtOnjyJO3fumKQ/r8yMXd0Y4p8/f35lobCk8PhhS4wp +pijP/8O8uXLB7ZQWFJOnDihVq7G6s+/Xb6WV7pB/Y4N9WT98+bNi8iRI1tSffD44ZWrKfoz/qbo r3MqtUNwjB+LgiGFBRsCYZqQg0KNB3/SZMn0lyVIkJD+Po958+YHSsiGZTIhG2sS5JmyqSuEoPQP 7HteTQW2wje3TGvrb66egd3HD2pT8TfXQsH4W5qQzcH/d/S3JCGz2dba+FuSkPk3bm39LT1+LP17 kvKCB4EwTcjanpWh2ciNzHHbd+xAsuQp4ORgj0u011yjRi18+uiOK1evKpSHDRsaPGhLqYKAICAI CAKCQCAIhElCvkempTFjx+LlixdImjQpbt28jnbt2qFaterIkjkDGjZsiCLF/kDxwvkxYdIkbNu2 HR6fPsDjsxfat++AnDmyy4ARBAQBQUAQEASsikCYJGR2dOjXrx95ZzqR6TaKckhiL8moUaNh6uSJ CuBKFcuhW9cu6Nu/PzQPYj4exd6xIoKAICAICAKCgLURCJOE7EjOIAkT8n6wTphkNSehXbt2o2ev f9GrZw/1HZ8xZMcLEUFAEBAEBAFBICQRCJOE/CtA9+zbF5J4S92CgCAgCAgCgkCACIQ7QpZxIAgI AoKAICAI2CICQsi22CuikyAgCAgCgkC4Q0AIOdx1uTRYEBAEBAFBwBYREEK2xV4RnQQBQUAQEATC HQJCyOGuy6XBgoAgIAgIAraIgBCyLfaK6CQICAKCgCAQ7hAQQqYu51i7U6dMRvSYcdD8z6bhbhBI gwUBQUAQEARCHoFwTcgc43rpksUYNGgw7lEO4YSJkwshh/yYFA0EAUFAEAiXCIRrQuZwmt26dkM2 Sqn48sVzxIgR3aRBwBHAjE2PyJmGeAJgbH5dLZetloLRmBR0WnYfY1PEmdLY8Ki/lg7P2D7W8A+O 8Kvm4G+q/tp4sLT+nIaQxdTxz/oz9qbm9ra0/hzNzxr6a/1laf1N+Z3LtSGLQLgm5ChRIuPYiZOI 7BIJqVIkNyqZOOdEZSLnhwT/++rVK1z1zRL1q650d3dXYTpNEf6Bvn79WqV4NCbRuUYIV65cQfTo QU8u+CHPOrHJPih5//692fqz7qbqHyNGjKBUUukUjdWf8TeWWLliLptxf/nypYp1bsxESsP/0qVL 4LjoxgiTlTH4mzp+zNGf9eV2sv7Gpu80Rn/GUfvNGIOJhj/j8uzZM9VvxkxIDfU3Np+2Mfrz2P34 8aPJ40fTn8eoMfprhGzM+OFruY8zZcpkLKRyXShAwDSGCAUNMkVFOzt7pEmTWmWF8vH5YtSt/GBh cuKHhKenJ7y9vdX7oKRSpUqoWrWqUT9Mw7L4YWDMj9nwHn6oGqMT63/nzh1kyZIlKPVRsWJFVKlS xWRdglN/zkd969YtZM2aNUj9GXtTHuxagcGpPyc9uXnzplH6V65cmbKVVQt2/LWVuDHjh8f+jRs3 jNK/evXqVsHfVP2vX7+ObNmyBTl+GHtbGj/8TOCJzsmTJ5EvX74g9ZcLQgcC4ZqQDR+6NNk0Sgwf /kwI/KMoWLCgUffa2kX8QA3N+vMKhNsQWvFnsmdSDq36MynwbyC06s+/Rw8Pj1Ct/4YNG2ztsSL6 /AYCQsgEHs+qzRGNkM251xbuEf1DthfYQsETotAqYUF/Y7ZSbLV/+Per7c/bqo6il2kICCETXsr8 8x3KBG2KaGYjU+6xpWtF/5DtDcE/ZPHn2kPzhCgs6B/yI8C2NAjXhMwzzEED+uP5y1dIly4tIrlE Rtu2benvDOjSpVOQPcWOL4ULFw7yOlu9IHLkyKFe/yJFitgqvEHq5eLigtCsP+cRD836szdz0aJF g+wnW72AT1OEZv1tFdeQ1CtcEzL/IHv920fhHzVaNHyjPT32qHVw0B3TCErYezJ27NhBXWaz34d2 /dnJJjTjL/qH7E+DjxSG5vET2vUP2d63zdrDNSHz3rHh8SA7ItiYMWPaZk+JVoKAICAICAJhGoFw TchhumelcYKAICAICAKhCgEh5FDVXaKsICAICAKCQFhFQAg5rPastEsQEAQEAUEgVCEghByqukuU FQQEAUFAEAirCAghh9WelXYJAoKAICAIhCoEhJBDVXeJsoKAICAICAJhFQEh5LDas9IuQUAQEAQE gVCFgBByqOouUVYQEAQEAUEgrCIghBzCPfuFMhadPHUKCRIkRKpUKf1o853SKB4+ckTlqI0UyQV5 8uaBnW8ijIsXzsPtnS5HMadfC4kg88+fP1fp9zjiVMpUqZA4USKl/7lzZ+Hu/kHfFtaRg7AkTJgQ KVPq2njp4gW8dXun9M+bNy84DGBIyaMHD/DoyRPCMT/pY69X48L5c3j3XpfH2j/Gly9dxJu3buq7 PHnyIKSSyn//TmPkcNBjxD/GVy5fwus3b5X+uXPnBofBtLa8fv0K16/fULmyWY/8+Rn/H48kwzHi H+NrlPP7JeUK5+tz5cpFv49IVlP/6NGjcKEwuzlyZPdT5/17d/Hg4SP1e+A8xbFixdJ//+jhA9y9 d199ly5desSLF1f/3VMae7du31bfpU6dhn4nCazWFqnIthAQQg6h/mCyXblyJWbOnImDhw6hZeu/ MGfWdKXNN0p24bp+HWbPno0dO3epz1KkSos7t67jAyVK79unDxbMn4cPnzzUd/UaNMT8uXPpIWG9 h9LNG9dRsuQfeEoJ5FnS0kOmefMW6NWzO/5u1w5Hj5/4Cdm/2nXAtKmT0KVTJ8wn/d0/flLX1K5T DwsXzEfkyC5W7w1+6FenXLd37z9Ay1ZtMWf2DJVLul/fvoTxfHyk9HwsDRr+D4sXLQBPoP7t3RsL SN93vpOOGjVrq++iRIliNf05MYXrhvVqjGzfsfOnMdKPxsh80vGDL8Z16jXAsqWL8f3bV/Tu2QsL Fs6nCZ27uq9qtRpYsngRokWLajX93759g7JlyuDc+QvgXGuU2wX/a9yUMJ9LKTW90Kf3vwrj9x8+ Kp1q1a6L5cuWqIld71691Hh5QxM6loqVq2E5tS169GjBpz8pePzEcYwfNw5r1q5FhkzZcO3KBX19 gwYMIEwXKEJmyZ07L1w3uiJJ4kQYPnSoGu93iJBZslL+ZVdXV6SiyemYUaMwj767cfOW+i5DxozU r65Inz5d8LVFSrZZBISQQ6hrDh8+hIaNGiFZ0mRKA0eD+Nk8+69Ttx6cI0bC1q1b1QqGSZpj126m H/nkKVOQI1debNywFq1aNMeqFcuRJlVqDB062Gqt+UQP+qxZs6nJxMoVK9C3Xz+MnzAJPXt0x3rX jSrPLwuvfgrSyv6l23sULlQQu3Zsw8TJk+mhlBNbNruibetWWLtmFVLTCnvkyOFW01+rqFmTJoqM WXbs2KH+3bp5E6ZMnYpcefJjw7rVaNn8T6xYvhTZ6UGaN3cOTJg0CRkzZ8WF/7ag/V9tsWH9Wgwk 68bYMaOtpv+1a1dRp05dODlHxOYtW5CXVumGY2QSjZHsOXNjk+t6tGnVEmtWrVD6FymUD+MnTkTa 9Jlw/sI2dPy7PTZu3ID+A1Ji4oRxVtN/xbJliozLla+oJjO5smfD0iWLVJKXgvnzqDGSOUt2XNy6 Ce3atsG6tasxImtWlCpZDOPGj0eKlGlwlu7v/E9HNd769O2HqVMmBZv+bm5vUb5sWTiRJcHB3s6P ReQ0WbgGDh4MR2cXPCBry9jRozFl2jR06twVw4cMxMCBA+Dz9Tvu3L2L2TNnYNToMWjfviOmTBqP wYMH0aTPU1maVixbSuUMQdNmzXH82OFga4sUbLsICCGHUN+kTpMG69ath4MdUK1GTUrK/EORF8+e KjN16dJlaRVaUv3NmZlYJozXPTR79+qJZMmSoVu3rti5ew9evHpt1ZbkpEnC9h3bVZ1t2rTGkMED afXC774jfvz4el0W0arBzd0dmYnAGjVqgCIFC+j0763Tv3v3bthGKzxr6886rF29CmcvXNTrGjWq boU1ccIEnY49dTp27dIFu/bsxXPCeMpk3UO/F63S+LseNAHZ8t82vHhpXfxfkGXiK42LP0qVQak/ /vA3Rsb7GyNdsJ0sLYyxpj+vMnX698DGzVtI/1dWHT8+ZGlQo4UGDVsWPD09EC9+QlSsWAE9unT2 HSM6HXmMbN22nUzUb/T6//tvb/Vdr549FCEHt/4uZL2ZNWcOMtDKlbcv+DepyayZOsuW9ptk3ZiQ P376hPnz5hAZf0P3Hr3Uirh3716KkJmEl9AEhP/9u0MnmoikQ0/qkxHDhuHZixdW7QupzHYQEEIO ob5IlCgxatasoVa8/mXwkCHqo+3btigi5v3hwUOHo2f3rjQz1+21FimiS/voQT9oFnv7kOvKgZTC 0svnK8rSCsK/7N+3F94+X9C/f1/1lQPPQJT+urSJHr4mYWvr//HTR0yhVWT8BImQOEE8Wm2d16vu 6KjbR9Yw9vysw9iB9vicHHU4F/VNuxlS+g+hlRTLzh3/BTBGdNnKfmD82Rd7B9Jf+04bPzqTvLXx b9m6De7euYtlZF2JEycOEidJio2bNiFThvTw8dFZV4oW9TtGHGiM6/H3TZv4yUrjx5ksEfXq1cNz mizzeDYUZ1//h0KFCqmPOWOcwpT2t/1/p/lWcFucffuiIFmOWNxp4soTc0eDfXQ/FcmbMI9AyD3F wzy0xjXQcKat3aF+mCS5cudRs+4DRGq9enRDwgQJECNGDPWdRgS8p6YT3oWzvuzauRMrV61W5nSe MPzQB7hz+xZ208qyWIk/aLVfyo9yIa1/i2ZNcZCcoR4+forZ0yYrQvZPSj/rSM9LX7xDWn9tjOTM lZv2tHsZN0Zo28NW9L916xbevXuntjbiEiF/oP34SRMnYRRtW2gOcgFhHNL6e3t7B/oj8/TUTdwi 2Pn+JglvTfTfBfB7/fk76/+OpUbbQEAI2Tb6wY8WGsWmon3hauRwFMnZkfYtJ5M39hn+uatrtYcW e2ayaCZAazZn//59qF2rpnLOWrpsOZmlM/mpfh6Z+B4/eYpSZSogpu9EwttbZ6p0olzULCGl/8nj x1X9q1Ysw+69e9XfL148xaFDh0kn3SpSj7HdD4y9fFdHjr6WipDSX3uup0z58xiJAJ0V4scY0b3n MeLtrVvdOYWw/u1pX/jYyVOYNHkq/mrbGi3+bIbZs2aQ2Tq+OlGgdPRdeRpirK1OnZx0fRRS+BsO dE0nB98Vr73BeNF/5+sj8kNfb/h80fUFr5ZZ7NRvOQL1UeCkb1iv/B32EBBCDuE+1faGHQ2O/XTr 3h0N/9cYjx49UivhK5cvKy0zZEiHb146r9Oe5Ck7Z/ZMjB87Vr1PlTKFVVtym1Y4lSpWgr2jEzkF bUbVqpX91M+6T6N9NJaOHf/Wf5cqdWp6EJ+mvb9ean9tXAjpv/m/7WBz52s6OuPioiMAB3po8v53 ihQpcOjoMdrT60lOODMxbpwvximSI8IXnfm3N3laL16wAOPG6L5LbWX8eYzUb9gIj381Rnr0xNy5 s/VjhHV0ttPtffYmL+alixcS/mN0+vs7chfcg4mdpFhK/lFSbcmUKFEcS2hSxx7uadKkpW+2qzGy YME8P2MkqouOiBn/FcuX6b+zlv76/On6lS6dgEihO8o3eNAgFCqQH5MmTVTvU9J4SZY8hfp76NAh 1MaidMpgiu93KZDE16Fz5MgR5HFeCgvmzYbXl69IS/4lIuETASHkEOr3+/fv0cNyHvj4EMuRQwfQ l47alCpVGuUqVERR2iM+RJ/VqlkLR48cwt8dO9FxorZ4Rw+ym0SG7PX75vVLnDx9mo5MtVXOLdaU ObNmwoNMdBlphXbp0gWcPKlbcfJRqFKl/sD0qZPhTseymjRtjpwG5zWnTJuO1+RctJq8ft3evsbx kyfRrEUr9CFHGGtKFvLY1WQL7ePv3bcfMWPGUl6+E8jD9/HTp3RMaAlevXyBU2fOoHXb9mpi8cH9 PR1RuYH1a9fA/Z0bTtFRmMbUxn79+1hTfZQtXwHFaY/1wKGD5ItQE8eOHvEzRvhc68qVy/H2zSuc IC/g5q3aoFOnjvj48YPSf+OGdahe/R3Onj5Fk78mYD8Aa8qffESOJgU1qtdA/Xp1MHniBMSKHRc1 qlZBoUIFcPXqVawh73se7ydOnEDTP1ugW9fO8CBHqZvXr8OVPOGrVauOC+fOoG6DRuRUOChY1Wez 8iTS8QmNC5YXz56o32vatOSMRZODp08eY9rMWahUuRJePH1CznalMXLEcLIMRafjijcxjszxFWkC 6+72BkWKFqdJ3mjEixsX9+7ewbARo1CpUiV4f/6EfAUKKq9zkfCJgBByCPV7LHr4ly9fXpmkhwwd Rl6mnvSw/IjkyZOrgALbyKv00ePH6jM24Wnm4Bh03+YtW+m840P1Ha/uOAiBtaVJsz/pId9amdd4 P5PPxbKw5ytL567d0Kx5S3pgpfWzr8yk57p5M+7TUaOQ1N8QrwHkINWJ9HVyclbtiB07DrbQcbOH dKZUp2NkwjijuiVqtOjY4LqJ9L+vzoRHIvwzhwD+MWPGJM/jbWRFCXiMbKKjUA8e/DxGokSJinXr XXGP9SfnIx5b3DbDvX9rjKUevXqjOp0u8Pz8WenRoGFD5W2d3Hf8GI4RQ4xdyMlx1dr1uHfvnq/+ kZCR8NcC5gSX7ryK/+OPUvhC3tV//90BX8jc7ObmRpO4mMpsPnXGTHTo1BmfaMLApmse95F8g62M nTARrdr+pb5jR6/UZCWK4ntqYujwkTSh+1NZwtgPI2XKVFY9Dx5ceEm55iEghGwebr99V7To0fVe sAEVFpkeThkyZAiwHn5ABfbdbytmZAGZs2T55ZXx4sWnaEQ/jj8ZXhyRzleHtP6G+iQgZzl+GQqT cGA6OtODNn0gfWMkfBa5LHLkX4wRItrA9Of9+/Tp01tEh98pJN0vdPjVGOG9ZWvrr6K1USSxX8mv dDL3u9/BV+4NfQgIIYe+PhONBQFBQBAQBMIgAkLIYbBTpUmCgCAgCAgCoQ8BIeTQ12eisSAgCAgC gkAYREAIOQx2qjRJEBAEBAFBIPQhIIQc+vpMNBYEBAFBQBAIgwgIIYfBTpUmCQKCgCAgCIQ+BISQ Q1+ficaCgCAgCAgCYRABIeQw2KnSJEFAEBAEBIHQh4AQcujrM9FYEBAEBAFBIAwiIIQcBjtVmiQI CAKCgCAQ+hAQQg59fSYaCwKCgCAgCIRBBISQw2CnSpMEAUFAEBAEQh8CQsihr89EYxMR+EDZqDhz Fss3ytbDGZ2iR49BmamSqs841Z8myZIlp6xDkUEX4Q6lxvPy8lbX830sWQ3SNvpX4/z5c+jQoSPS pc+IeZSHOCDh7FicmnLdho34p3NX1K5Z3cTW/Lj8K2UcavK/Rnj45Ck+U9ak8ZRViNN2misd/26P Q0eOqqxLDo7OKg1g0qQ6jEQEAUEg+BEQQg5+jKWGEEZg5/ZtqF2vvh8tEiVNgdbNm+LSxQtEjq76 74oVK47NlB4yatQoqFqxAq7evO3nvp69/qU8t8MCbNGgAQNw+PBhvHztFmiLOW1g167dwfRetXqt 30KGJwr79+3F05evkSpVasSJE+e3ysuRIyfOnjun2sDyifJZiwgCgoD1EBBCth7WUlMIIaDlaubq lyxZihw5slM+26+0ip2La9dvIH+BQnB7/QI3b9/BwYMHsJ4IulnTxrQq/qo0rlixMkaNGqH+9vH5 8lMrHj9+pPISc35cFl5havL8+XPcpZV2xEiRkStnDso/HAlODvb4TPVzjl1Nzpw+BS9vH5XwPm5c 44k1Ck0caAaA8hUqImOGHykV3755gxs3byJP3rxwpNSBx44dU1UVKFDAT+7jc2fPwMvnKwrkz4fm LVvCwcEOR44eoxVyRJWfV0QQEASsh4AQsvWwlppCCIEIESLoa+a8tFl8czlPmTpF//mWTa6oUq2G ev/q1Wv1LyeeZ4lNK0/tHv9NGDFsKObNm4c79+7rv9LqmzBuLObMnUekfx3OlAO63V/tUKZsGbhQ PuvP7h/Aea15hT502HCsXr1a3Z8te3a0a9ceKZImxrYdO4nIXWhFPhzr1qwic/IxRIseE4MHDfgJ Sa5z5YoVOH7iBBGuHXbt2IYr166jPE0mIjnZY4PrRnVPm7btMI1M5k8ePcTYceMxl0zrnp+9Ubdu XZp0jFamehFBQBAIGQSEkEMGd6k1hBAoXryYItqixUrgv62b9VqcPHlS/3fVqpXV3xo3rVi+FBvW r1Wf7dq1m1aZukT1ly5exKCBA+D15ZtaRZ87exLPnr+Es7Mz7ty+TcQ5EO8+fML0GbNw5MBuTJgw DkuXLafVuY+639PTE5s2uoJX0bPnzMPuHVuxeu16zF+4BIXyZsekyVMRwcEZnTp1wpjRo3Di9DmU LVcxQOS4TtcN67FqjU7PuHHjInasWNj+3xa4RI6CcuXKYffuXZg1czoyZcqIQ/v2YC1ZAqrWqI1q Fcth0ZIltF/uJaviEBqXUq0gwAgIIcs4CFcI/PNPJ6ROnQoJEibSt3vc2DEYMkxnkq5XryHix4ur HLmIktVnufPkRcsWzdXfKVOm0N83e/ZMRcbxEybFViL3Rg3qYfnK1bT/HBWLFi1UZOzo6IQ9RIT7 9u5R9716+QyRnZ3U3/ZkEu7Tb4By7urTuxcOHj6iPrej1W6Llm2wbt16vH3/ATWqVVNkzDJgQL8A +4v15XpZkqdMg727d6Jp40Y4TObnOtSmhfNmIW6s6Hjt5o63b93w9avOHH+Q9qDTEh5btm5FlMiR 6b4dAZYvHwoCgkDwIyCEHPwYSw02hEBL2idlQtZk9MiR6Nm7t3rb9M+WWDh/jvpb86rmv7NlywG+ z7/Y+5rCNRP1t28/zL1MqpqwB3QVIlVnJ2d88vCE65qV6itHJ0fMmz0LXXv0RLRo0eFC5mkWXqlm yZoF0aNFxSPyoD5+4ji4tLTpMyBO7FhBohkvfgJy8kpJTlmf1LW8IueXtuJ3dHLCjNlzEDdBf9yj /e1xY0dj7pxZ2H/gIGJEjx5k+XKBICAIBA8CQsjBg6uUakMIGDp1nT9/nsyyTG8RyEHLW+8xXbBQ EfTq0Q0PHz4kxyZHJEgQ33eVDLx48RzsHc3iRGSWOHFi9XdcIj52fHr96jnGjB0HDz0BfiGTcTwd 6TpHwsRJkxA3TmyqMgIuXriAtSuWqu/ekRPYnOmT8P79e9Rr8D94fnDDXapHW722a/832v3dQd3H bShZshTSpUsXKLJaO318dCZxTfhzw6Nbn8lU7kQOZaNHj8b+vXuxa/cepcMnz8+wJ4czEUFAEAgZ BISQQwZ3qdWKCBiudmvX9j1qZOdIzk525NDkpTQ5fuwIMmfOpFbG+QoUxoljh5UnNsumjRvUiyVr tpxEqmfV3126dMOsGdPx6Olz9OjeTd+il69e4a927XDjxjVMmTYDadOk9v3ODpUqV6E9bPJe/vqN nLsio36Dhhg+cjRmz5ymv5/PKrPUqVcP8+cvwOmzZxE5SjT8UbLEL1H7QueSWTRC1v798bmuXJ5E NPlfA2zZtlNfXtp06ZEsSWLcvnrRij0jVQkCgoAhAkLIMh7CPAKly5bD8ePHVTt59cmrRfZE5oVy BN+jPUzEGnFHjRpNXbuOPJM9aNXI12ur1sjkIKVJJJdIRGo7lHMW36sdE3KhvVg7chybPHU6GjVu SsSuHZWKQObvbOTwdVMdcUpDR5xix4pJ55FrqvvZ9M0vvp+FzdhZMmdUhOxMK+26dWv/1FeaXkzi 7K39F62qNR1XrFxFJnIPOp8cV6369x86oiYZSZIkhTuV1auPm6qPndw4AEiiRInwzdeurZUb5geH NFAQsCEEhJBtqDNEleBBIFbs2MhPL1Mla7bsQd7CBPsryZ9f55FtKDly5vLzPqBr+ILDhw5i4ZJl 6tp69eviC5miHQzOLvPn9nY6E/MhurZnjx4wLCuLv6hiuXPn0debOPEPpzbtw+XLluq9tNnhTEQQ EASsi4AQsnXxltoEAaMRiB07DooWLaq8vMePG8dbyX7EngJ+bNu5G95E1LxKjxJF5xRmruTImRNs up44cRIVEQEpUiQ3tyi5TxAQBMxAQAjZDNDkFkHAGghkz5GDIocdDLQqNjenSq3tT/++RpkyZf79 QqQEQUAQMBsBIWSzoZMbBQFBQBAQBAQByyEghGw5LKUkQUAQEAQEAUHAbASEkM2GTm4UBAQBQUAQ EAQsh4AQsuWwlJIEAUFAEBAEBAGzERBCNhs6uVEQEAQEAUFAELAcAkLIlsNSShIEBAFBQBAQBMxG QAjZbOjkRkFAEBAEBAFBwHIICCFbDkspSRAQBAQBQUAQMBsBIWSzoZMbBQFBQBAQBAQByyHwS0LW guVbrjopSRAQBAQBQUAQCJ8IaLnTA2t9oIRM2V6iSMaX8DlopNWCgCAgCAgClkWAyfjz58+xYsaM 6S8q/Y96AiVkuvG/6dOnu3tQ+jYRQUAQEAQEAUFAEDAfAU5zSrzqPnDgQO93794FWFCghEzm6uVu bm7Lza9e7hQEBAFBQBAQBAQBQwQCI2O+Rpy6ZKwIAoKAICAICAI2gIAQsg10gqggCAgCgoAgIAgI IcsYEAQEAUFAEBAEbAABIWQb6ARRQRAQBAQBQUAQEEKWMSAICAKCgCAgCNgAAv8H5AahAsq+KYAA AAAASUVORK5CYII= ------=_NextPart_000_00AD_01CAF14A.E58011D0 Content-Type: image/png; name="image004.png" Content-Transfer-Encoding: base64 Content-ID: iVBORw0KGgoAAAANSUhEUgAAAVEAAADMCAMAAAD9J2BZAAAAAXNSR0ICQMB9xQAAAWJQTFRFAAAA AAAAAAMICwsNAAAECgsNDQoIAwAEAAQICAMAAAADCAoLDQgECAoNCgQABAgNDQsKBAAAAAQKDQsL CAYECwsLCwYDAwYLDQgKAwMDCwgKCwoICgoIAwADCAgICwsKBAYIAwAABAADAAMEBAMABAgKBAgL CgYDCwgEBAQACggECAoKAwMICAMEAwQEBAYLCAQICwYEAwQKCgQDAAMDAwMACgsLCgQEBAQKBAQE CAYKAwYKBAMIBAQDAwMECAYDCAQEBAAECAMDBAMDCAQDAwQICgsKCwYICAQAYWFhcXFxfHx8bW1t aWlpeHh4gICAk5OTjY2NiYmJlJSUnZ2dh4eHhoaGkpKSmpqas7Ozvb29pqamra2tsLCwvLy8qqqq pKSkurq6oKCgpaWlsrKyxsbG3d3d2dnZ19fX0NDQw8PD8fHx7Ozs+Pj44uLi9fX15ubm6+vr4eHh /f396enp////Eeri7AAAAAF0Uk5TAEDm2GYAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAAZdEVYdFNv ZnR3YXJlAE1pY3Jvc29mdCBPZmZpY2V/7TVxAAAKAUlEQVR42u2diZvbVhXF8+yxGxtZ8lIkJkNJ HUg7CZMm06FNQguBsg4FQktZTJuyhikwNGz6/7n3Pi3WWE+yxxr7ST73+7xfaezfnLcdPT1du4ZA IHYwniKqiDmgIaKKeAqiIAqiIIoAURAFUUTTiTqtduYRRMuA7XXksftSJ+dTeneOaH4OiC4Qda73 +l/oqf4gdFWrTa+84UiN6cV4Qu++3PpizwvdsUOPSil+CqJlRJXnjll/fqvtBvQq/FJnONpvtW+0 tUZdQutpjfr8FETLiLbafuuAiLqkwTGXctIoPUtKvbP3ZXmkV91XvmJT0bedqM8QmagbTHr7KVES 7DiqR6kesKjQW0305qg/YGkGTNQnib46VcyS6lEiTDWBkO0PfGVRoW9EfzTuG4BoVWFTS48xE4iC KIgiQBRE3cD40epe0rJb+JvrDmyc6PDWoCKiPOy/uEXGitIveGjgFf3VuhOl7jiNg2i8c70XOUuh vndp/P7Vr/Xll9NzIkEdd+1BibkkSfT6Nm9Nu7jO1pQeTWmvirZkY2ogiZTwmnhXTHbqbdBL2ThR MZOYLI0eW6/LC3mL7m4csuOkc268vtehB/GgxGfS2/Fr3pqdqFe1Rn1OjLdkK0oSOSsWrMP/uqDJ RB1RH/tHd8RPEn+Jgchovq0HQXSLx/eH7DNJkmzFW/NwPyIqiXejLbtJImVFREmimxxXbb7U8w/3 BRdpVH6nNBv+HFF+7mt82jHZH0dtS7w1O1GxRjnxMCUaN0L+WBMVoE3WqFYR1aMkpUCcJRFc0J2q lAs9vzlS2l3iUqxrTkplTfL73NzcHkk9yh948f9iOOp/XRI5i30p3TKNm1yPDkdeqtWNxQYPR22+ PxqVys0SbXJ/tPEBotsn6iirDus0gahNB3UaotGoTWnS5PmtEqWuyFHcTKPurYbo5F4HRCsk6vOQ BEQr1ejc1gAIoiAKoiAKoiC6a0QVB4hWqtGd5gmiWyaqDwvPuXkguh5R5437YdbNA9G1iE4eHAjR MjdPrWutSeO2C27e8aB7X56UuHkVaLTOMl+e6ESf3haWunkgunzLRBrtvlnq5oHoSr2nk8yswYVt /nF+fq7odv5PEK2mP/p8Npspus0+B1EQrS3RZQb+ILqaRst5gWiVRP96dnam6Hb2AkSrIfq7eBfn u000qh1BtEKNqhKNpg0SiF4MNyggKmLN1aiCRg2hTb3wovkkbtHHsyh+UeBJFftKn8REP9iVmWSR qWcu9TNDPQqNGiIx9UC0GqKpqXdlRKOqeIdapgWNPjulUHz3aRnR81iBz4s0Otv13lM50Q8pFN/9 HkSrIZok/NJMNBokgGhlRKN6AURBFETrQVQqQRCtVKOnxRqNkINoZUSjWIdoPSZSrkC0O5WFVHJm klVA9F+fUSi++7RAo3U4WrLaDIg3w/mZZIlz85ME2B8M3lOS8P4sGmR+nE34aVLTfhLv4oMrmFJl m/fk6NmO6VoDl9PoLEejHyVE/1iuUauL/ypz8+LVfRdmkm2aqNXFfyWNRlPIFmaSgejliPrcJOXO JAPRy2o0NMwkA9E1iF7Yukqi0RjAQPTfCfKPQHRpjZ4WaHQpojZ0AppF1AbxgiiILkV0i8W/sRrd mlhBdPtEIwtqC0Sj7lX9iDo8JvIJm8OjIxrNX1wMVSyorWj0dF2NbqB+zSP6jaP28NZbnsPX8gly lut1NOKnl3TzdOS5eacFbt77ScKvYov1T9ld/CypF4qMP7UFN4+vKsc3V9b+Xbj40fwFprai0T/H RP+W3cWHCdGiUn/ltUEe0bE/dl/ryaLevEiyurj26pV5TxskenXFP5dod7r3tqyXPukFCyv2+qoZ Gi3i+dkziv9oJ/gh//rho4xF5CqPWxs5nNGd8nrTQTHRSY+XkuZZeLIQtXmZ7qYSlR/0d0KxH2ii 2fC98OHjt785fBS1KieDYqKrKLzpRN+513l4VxY5904Gw3cPplIFkl6Pv6UCzRpEVyIaOMSNr8nh ePTcoxqPr6nHRKlzeXvEeKWP2Vii0RjgPD6D+r/Z2jFB/mxpouHJt594VLwdb/judzrHujKlB1Ls I8fj1/pwZnM1KjGLM15ckmjcMhGo7ktP5KoacrWYri719DAefrdDDXgnOUCcNNcgWnWAKIiCKIga o7KZZOsT1afnXIJo1BmwRqMyPSdnTbLNa3R2aY1KPIu7Vy+2TVTm5i2uSbZ5N29mcvOyRH+dSfh5 kvCbOOG3252bN3lvkEq11hr9S5xwtl2NxvaLBW5eM4jKoPZKZ5LtnEbndWo5Ud0ZqAXRC1vbq9HZ Ohr9/DnF/8J4HJ8Trlz8cM50TrwSEM2Ls+gnODlmu5y5zZ5z5+G86fwyiC5L1A38wJEmhK+/qfbu cDMiDqk/bzqD6HJElfImPfHyfLGb73pao9pznjedUeqX1ujwe0dtISoII6LiOYfzpjOIFhJ9ES2h SuJrfX/gcKlvtaXU88V1x9pzDjOmc2J3gOgyscrVEneVaLS6jBVEtzc3r1qNzizq4cdOidXe06zM e5pZ4D0lRLc727F5Go1NPRCtiuicWQKiVRCNZqqAaIX1aAiNgiiIgiiIgiiIgiiIgugWiDpyXNCG mWQNIdr9wQMhuu6aZPCekphoole3JtnOlXpNtCYzyWpFtBYzyWpRj07rNJOsNr2nmswkQ38UREEU REEUREEUREG0uUQdjOurJRpZUCBanUbj4f3TBoUdRMOc6y4bKtp1MuzYBYjWiahYUNV9ERBFgCiI gigCREEUREEURG0k6ujTouneVXnn/Mmper5SdJ+fEPKp7HpxBVNCuntDhiw1b06Q75h+bPweVhAV R0pOHZPlEXJTeCoKDWGNCc4b92XrJ4aEdPemXfje5N4TY4J8x3R74/ewRKM82vcf9wfxyfwGILJG b37C5MHBfflw35CQ7t60i+7R4bgggb9j+rHxi1pE9PidyXvGLyqn6vEEH1PC8aBbTDTdvWkXw5Fq FlEqRycDvTzCYsibrFNDAi9trnhJhZPHhj2kuy/4G3rr/AT5rw/KdmJLPcqOFEtEL4+Qg0NO1eOf YEgIZZka/tCUkO7elMFrNRwYE/TErWnZTmzRKAJEQRREQRQwQBREQRRRa6K8fuIPR7Kspz58Pelp a8gfZ7LmF7D0+4PQtrCIaKsd/qjj73XimWr5RDPDnLllfUA0lyjha7WT00/50mckV756oWr9OJCr wzn8QvGpqb7qD0C0pNQHYfeV6DKloRuQRl12qH2m1zpsHY5DfVlD4kjUucSDaJlGhyMvFqsmGkip d4Pu0c1bb3kZopwMoiUa3bvDmtQtk5R6cYt0qW+70lylRF2U+jVDN1BO5tgQ2vo1Im75rQ/08EEU REEUAaIgCqIIEAXRhhJFVBPXEAgEAoGwL/4P09eKIfiNieAAAAAASUVORK5CYII= ------=_NextPart_000_00AD_01CAF14A.E58011D0-- From bmschwar@fas.harvard.edu Tue May 11 11:46:56 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7CE3A6A79 for ; Tue, 11 May 2010 11:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.813 X-Spam-Level: X-Spam-Status: No, score=-3.813 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xd2ls85GBW4Z for ; Tue, 11 May 2010 11:46:55 -0700 (PDT) Received: from us18.unix.fas.harvard.edu (us18.unix.fas.harvard.edu [140.247.35.198]) by core3.amsl.com (Postfix) with ESMTP id 671D828C203 for ; Tue, 11 May 2010 11:46:45 -0700 (PDT) Received: from [172.23.141.103] (bwhmaincampuspat25.partners.org [170.223.207.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar) by us18.unix.fas.harvard.edu (Postfix) with ESMTPSA id 775604D5F14; Tue, 11 May 2010 14:46:34 -0400 (EDT) From: Ben Schwartz To: stephen botzko In-Reply-To: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <002c01cae939$5c01f400$1405dc00$@de> <009901caede1$43f366d0$cbda3470$@de> <20100510232234.16632o6l2ecu3wyy@mail.skype.net> <006101caf117$aaf3b2c0$00db1840$@de> <1273595415.1684.33.camel@dell-desktop> <2B114368-93C0-410B-AB66-53CA33E921A8@americafree.tv> <1273601174.1684.79.camel@dell-desktop> Content-Type: text/plain; charset="UTF-8" Date: Tue, 11 May 2010 14:46:34 -0400 Message-ID: <1273603594.1684.102.camel@dell-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Thresholds and delay. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 18:46:56 -0000 On Tue, 2010-05-11 at 14:19 -0400, stephen botzko wrote: > >>> > In the presence of echo, round-trip delay must be kept below 30 ms to > ensure that the echo is perceived as sidetone, according to the > Springer > handbook of speech processing: > >>> > Though true, I don't think this is a mainstream consideration. > > VOIP phones that are capable of speakerphone operation all have > acoustic echo cancelers, and those cancelers are already tuned to deal > with internet delays with other voice codecs. In my experience, the biggest problem is in complex conferences with many users at different latencies, and endpoints consisting of multiple-microphone multiple-speaker systems scattered across a room and frequently repositioned. Anyway, I don't think it's very contentious that (a) on high latency links (e.g. long distances), AEC will always be needed in speakerphones, (b) the perceived audio quality in the presence of AEC is improved by very low round-trip acoustic latency, and (c) AEC may be retuned at very low round-trip acoustic latency for further improvement in perceived audio quality. Very high audio quality may not yet be a major concern in this market, but I think this working group is going to change that. --Ben From mknappe@juniper.net Tue May 11 11:58:52 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F6613A6BF6 for ; Tue, 11 May 2010 11:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.655 X-Spam-Level: X-Spam-Status: No, score=-4.655 tagged_above=-999 required=5 tests=[AWL=-1.157, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0KAIvoARgHN for ; Tue, 11 May 2010 11:58:50 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 172C73A6A5E for ; Tue, 11 May 2010 11:58:50 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKS+mo1ZvqoYb0ugn90wO9ez33rG2HxrFF@postini.com; Tue, 11 May 2010 11:58:40 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 11 May 2010 11:56:49 -0700 From: Michael Knappe To: "stephen.botzko@gmail.com" , "bmschwar@fas.harvard.edu" Date: Tue, 11 May 2010 11:56:48 -0700 Thread-Topic: [codec] Thresholds and delay. Thread-Index: AcrxNwRz7jmtZalKQL+8yRAIZ5yTkAABK9yE Message-ID: <05542EC42316164383B5180707A489EE1D593774EC@EMBX02-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_05542EC42316164383B5180707A489EE1D593774ECEMBX02HQjnprn_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] Thresholds and delay. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 18:58:52 -0000 --_000_05542EC42316164383B5180707A489EE1D593774ECEMBX02HQjnprn_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3RlcGhlbiwNCg0KQWdyZWVkIHRoYXQgYWNoaWV2aW5nIGxvdyBlbm91Z2ggbGF0ZW5jaWVzIGZv ciBzaWRldG9uZSBwZXJjZXB0aW9uIHNob3VsZCBub3QgYmUgYSBnb2FsIG9mIHRoZSB3ZywgYnV0 IHdlIHNob3VsZCBiZSBhaW1pbmcgaWYgYXQgYWxsIHBvc3NpYmxlIGZvciBiZXR0ZXIgdGhhbiAy NTAgbXMgb25lLXdheSBkZWxheSBpbiB0eXBpY2FsIChhbmQgbm9uLXRhbmRlbWVkKSBkZXBsb3lt ZW50cy4gVGhlIGtuZWUgb2YgdGhlIG9uZS13YXkgZGVsYXkgaW1wYWlybWVudCBmYWN0b3IgYmVn aW5zIHJpc2luZyBub24tbGluZWFybHkgc29tZXdoZXJlIGJldHdlZW4gMTUwIGFuZCAyNTAgbXMu DQoNCk1pa2UNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IGNvZGVj LWJvdW5jZXNAaWV0Zi5vcmcgPGNvZGVjLWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzogQmVuIFNjaHdh cnR6IDxibXNjaHdhckBmYXMuaGFydmFyZC5lZHU+DQpDYzogY29kZWNAaWV0Zi5vcmcgPGNvZGVj QGlldGYub3JnPg0KU2VudDogVHVlIE1heSAxMSAxNDoxOToyMiAyMDEwDQpTdWJqZWN0OiBSZTog W2NvZGVjXSBUaHJlc2hvbGRzIGFuZCBkZWxheS4NCg0KPj4+DQpJbiB0aGUgcHJlc2VuY2Ugb2Yg ZWNobywgcm91bmQtdHJpcCBkZWxheSBtdXN0IGJlIGtlcHQgYmVsb3cgMzAgbXMgdG8NCmVuc3Vy ZSB0aGF0IHRoZSBlY2hvIGlzIHBlcmNlaXZlZCBhcyBzaWRldG9uZSwgYWNjb3JkaW5nIHRvIHRo ZSBTcHJpbmdlcg0KaGFuZGJvb2sgb2Ygc3BlZWNoIHByb2Nlc3Npbmc6DQo+Pj4NClRob3VnaCB0 cnVlLCBJIGRvbid0IHRoaW5rIHRoaXMgaXMgYSBtYWluc3RyZWFtIGNvbnNpZGVyYXRpb24uDQoN ClZPSVAgcGhvbmVzIHRoYXQgYXJlIGNhcGFibGUgb2Ygc3BlYWtlcnBob25lIG9wZXJhdGlvbiBh bGwgaGF2ZSBhY291c3RpYyBlY2hvIGNhbmNlbGVycywgYW5kIHRob3NlIGNhbmNlbGVycyBhcmUg YWxyZWFkeSB0dW5lZCB0byBkZWFsIHdpdGggaW50ZXJuZXQgZGVsYXlzIHdpdGggb3RoZXIgdm9p Y2UgY29kZWNzLiAgQ2VydGFpbmx5IG91ciBwaG9uZXMgYW5kIHZpZGVvY29uZmVyZW5jaW5nIHN5 c3RlbXMgZG8gbm90IGhhdmUgcHJvYmxlbXMgd2l0aCBwYXRoIGRlbGF5cyBvZiB0aGlzIG9yZGVy IChodW5kcmVkcyBvZiBtaWxsaXNlY29uZHMpLg0KDQpGcm9tIG15IG93biBleHBlcmllbmNlIChu b3QgdGVzdGluZykgSSBhZ3JlZSB3aXRoIEJyaWFuJ3MgY2xhaW0gdGhhdCA1MDAgbXMgcm91bmQg dHJpcCBpcyBhY2NlcHRhYmxlIGZvciBtb3N0IGNvbnZlcnNhdGlvbi4NCg0KSXQgZG9lcyBkZXBl bmQgb24gd2hhdCB5b3UgYXJlIGRvaW5nLCBhbmQgdGhlcmUgYXJlIGNlcnRhaW5seSB0YXNrcyB3 aGVyZSBtdWNoIGxvd2VyIGRlbGF5cyBhcmUgbmVlZGVkLg0KDQpSZWdhcmRzLA0KU3RlcGhlbiBC b3R6a28NCg0KDQoNCk9uIFR1ZSwgTWF5IDExLCAyMDEwIGF0IDI6MDYgUE0sIEJlbiBTY2h3YXJ0 eiA8Ym1zY2h3YXJAZmFzLmhhcnZhcmQuZWR1PG1haWx0bzpibXNjaHdhckBmYXMuaGFydmFyZC5l ZHU+PiB3cm90ZToNCk9uIFR1ZSwgMjAxMC0wNS0xMSBhdCAxMjo0OCAtMDQwMCwgTWFyc2hhbGwg RXViYW5rcyB3cm90ZToNCj4gQXMgYSBwb2ludCBvZiBvcmRlciwgSSBvYmplY3QgdG8gYW55IGdy YXBocyB3aXRob3V0IGFuIGF2YWlsYWJsZSBwYXBlcg0KPiBiZWhpbmQgdGhlbS4NCg0KSSBoYXZl IGxvY2F0ZWQgdGhlIGZpcnN0IHBhcGVyIG1lbnRpb25lZCBieSBDaHJpc3RpYW4gSG9lbmUgYXQN Cmh0dHA6Ly9pZWVleHBsb3JlLmllZWUub3JnL3hwbC9mcmVlYWJzX2FsbC5qc3A/YXJudW1iZXI9 ODE5NTINCmJ1dCBvZiBjb3Vyc2UgaXQncyBwYXl3YWxsZWQuDQoNCk9uZSB0ZXN0IGluIHRoYXQg cGFwZXIgdG9sZCB0cmFpbmVkIHN1YmplY3RzIHRvICJUYWtlIHR1cm5zIHJlYWRpbmcNCnJhbmRv bSBudW1iZXJzIGFsb3VkIGFzIGZhc3QgYXMgcG9zc2libGUiLCBvbiBhIHBhaXIgb2YgaGFuZHNl dHMgd2l0aA0KbmFycm93YmFuZCB1bmNvbXByZXNzZWQgYXVkaW8gYW5kIG5vIGVjaG8uICBTdWJq ZWN0cyB3ZXJlIGFibGUgdG8gZGV0ZWN0DQpyb3VuZC10cmlwIGRlbGF5cyBkb3duIHRvIDkwIG1z LiAgQ29udmVyc2F0aW9uYWwgZWZmaWNpZW5jeSB3YXMgaW1wYWlyZWQNCmV2ZW4gd2l0aCByb3Vu ZC10cmlwIGRlbGF5IG9mIDEwMCBtcy4NCg0KTGV0IG1lIGVtcGhhc2l6ZSBhZ2FpbiB0aGF0IHRo ZXNlIGRlbGF5cyBhcmUgcm91bmQtdHJpcCwgbm90IG9uZS13YXksDQp0aGVyZSBpcyBubyBlY2hv LCBhbmQgdGhlIHRhc2ssIHdoaWxlIGRlc2lnbmVkIHRvIGV4cG9zZSBsYXRlbmN5LCBpcw0KcHJv YmFibHkgbGVzcyBkZW1hbmRpbmcgdGhhbiBtdXNpY2FsIHBlcmZvcm1hbmNlLg0KDQpJbiB0aGUg cHJlc2VuY2Ugb2YgZWNobywgcm91bmQtdHJpcCBkZWxheSBtdXN0IGJlIGtlcHQgYmVsb3cgMzAg bXMgdG8NCmVuc3VyZSB0aGF0IHRoZSBlY2hvIGlzIHBlcmNlaXZlZCBhcyBzaWRldG9uZSwgYWNj b3JkaW5nIHRvIHRoZSBTcHJpbmdlcg0KaGFuZGJvb2sgb2Ygc3BlZWNoIHByb2Nlc3Npbmc6DQoN CihodHRwOi8vYm9va3MuZ29vZ2xlLmNvbS9ib29rcz9pZD1TbGcxMGVrWkJrQUMmbHBnPVBBODMm b3RzPXdjOXlNOVdyQ3MmZHE9c2lkZXRvbmUlMjBkZWxheSUyMDMwJTIwbXMmbHImcGc9UEE4NCN2 PW9uZXBhZ2UmcSZmPWZhbHNlKQ0KDQpTdWNoIGxvdyBkZWxheXMgYXJlIGNsZWFybHkgaW1wb3Nz aWJsZSBvbiBtYW55IHBhdGhzLCBidXQgZm9yIEJvc3RvbiB0bw0KTmV3IFlvcmsgQ2l0eSAob3Ig TG9uZG9uIHRvIFBhcmlzKSwgcGluZyB0aW1lcyBjYW4gYmUgbGVzcyB0aGFuIDE4IG1zLA0KbWFr aW5nIGVjaG8tPnNpZGV0b25lIGNvbnZlcnNpb24ganVzdCBiYXJlbHkgcG9zc2libGUgZm9yIGEg Y29kZWMgd2l0aA0KNW1zIGZyYW1lcy4NCg0KSSBhY2NlcHQgQnJpYW4gUm9zZW4ncyBjbGFpbSB0 aGF0IGEgc2xvdyBjb252ZXJzYXRpb24gZG9lc24ndCBub3JtYWxseQ0Kc3VmZmVyIGdyZWF0bHkg ZnJvbSByb3VuZC10cmlwIGxhdGVuY2llcyB1cCB0byA1MDAgbXMsIGJ1dCB1bmRlciBzb21lDQpj aXJjdW1zdGFuY2VzIG11Y2ggbG93ZXIgbGF0ZW5jaWVzIGFyZSB2YWx1YWJsZS4gIExldCdzIG1h a2Ugc3VyZQ0KdGhleSdyZSBhY2hpZXZhYmxlIGZvciB0aG9zZSB3aG8gY2FuIHVzZSB0aGVtLg0K DQotLUJlbg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KY29kZWMgbWFpbGluZyBsaXN0DQpjb2RlY0BpZXRmLm9yZzxtYWlsdG86Y29kZWNAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvZGVjDQoNCg== --_000_05542EC42316164383B5180707A489EE1D593774ECEMBX02HQjnprn_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PHA+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD4NClN0ZXBoZW4sPGJyPjxicj5B Z3JlZWQgdGhhdCBhY2hpZXZpbmcgbG93IGVub3VnaCBsYXRlbmNpZXMgZm9yIHNpZGV0b25lIHBl cmNlcHRpb24gc2hvdWxkIG5vdCBiZSBhIGdvYWwgb2YgdGhlIHdnLCBidXQgd2Ugc2hvdWxkIGJl IGFpbWluZyBpZiBhdCBhbGwgcG9zc2libGUgZm9yIGJldHRlciB0aGFuIDI1MCBtcyBvbmUtd2F5 IGRlbGF5IGluIHR5cGljYWwgKGFuZCBub24tdGFuZGVtZWQpIGRlcGxveW1lbnRzLiBUaGUga25l ZSBvZiB0aGUgb25lLXdheSBkZWxheSBpbXBhaXJtZW50IGZhY3RvciBiZWdpbnMgcmlzaW5nIG5v bi1saW5lYXJseSBzb21ld2hlcmUgYmV0d2VlbiAxNTAgYW5kIDI1MCBtcy48YnI+PGJyPk1pa2U8 L2ZvbnQ+PC9wPg0KPHA+PGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyIHRhYmlu ZGV4PS0xPg0KPGZvbnQgZmFjZT1UYWhvbWEgc2l6ZT0yPg0KPGI+RnJvbTwvYj46IGNvZGVjLWJv dW5jZXNAaWV0Zi5vcmcgJmx0O2NvZGVjLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DTxicj48Yj5Ubzwv Yj46IEJlbiBTY2h3YXJ0eiAmbHQ7Ym1zY2h3YXJAZmFzLmhhcnZhcmQuZWR1Jmd0Ow08YnI+PGI+ Q2M8L2I+OiBjb2RlY0BpZXRmLm9yZyAmbHQ7Y29kZWNAaWV0Zi5vcmcmZ3Q7DTxicj48Yj5TZW50 PC9iPjogVHVlIE1heSAxMSAxNDoxOToyMiAyMDEwPGJyPjxiPlN1YmplY3Q8L2I+OiBSZTogW2Nv ZGVjXSBUaHJlc2hvbGRzIGFuZCBkZWxheS4NPGJyPjwvZm9udD48L3A+DQomZ3Q7Jmd0OyZndDs8 YnI+SW4gdGhlIHByZXNlbmNlIG9mIGVjaG8sIHJvdW5kLXRyaXAgZGVsYXkgbXVzdCBiZSBrZXB0 IGJlbG93IDMwIG1zIHRvPGJyPg0KZW5zdXJlIHRoYXQgdGhlIGVjaG8gaXMgcGVyY2VpdmVkIGFz IHNpZGV0b25lLCBhY2NvcmRpbmcgdG8gdGhlIFNwcmluZ2VyPGJyPg0KaGFuZGJvb2sgb2Ygc3Bl ZWNoIHByb2Nlc3Npbmc6PGJyPiZndDsmZ3Q7Jmd0Ozxicj5UaG91Z2ggdHJ1ZSwgSSBkb24mIzM5 O3QgdGhpbmsgdGhpcyBpcyBhIG1haW5zdHJlYW0gY29uc2lkZXJhdGlvbi7CoCA8YnI+PGJyPlZP SVAgcGhvbmVzIHRoYXQgYXJlIGNhcGFibGUgb2Ygc3BlYWtlcnBob25lIG9wZXJhdGlvbiBhbGwg aGF2ZSBhY291c3RpYyBlY2hvIGNhbmNlbGVycywgYW5kIHRob3NlIGNhbmNlbGVycyBhcmUgYWxy ZWFkeSB0dW5lZCB0byBkZWFsIHdpdGggaW50ZXJuZXQgZGVsYXlzIHdpdGggb3RoZXIgdm9pY2Ug Y29kZWNzLsKgIENlcnRhaW5seSBvdXIgcGhvbmVzIGFuZCB2aWRlb2NvbmZlcmVuY2luZyBzeXN0 ZW1zIGRvIG5vdCBoYXZlIHByb2JsZW1zIHdpdGggcGF0aCBkZWxheXMgb2YgdGhpcyBvcmRlciAo aHVuZHJlZHMgb2YgbWlsbGlzZWNvbmRzKS7CoCA8YnI+DQo8YnI+RnJvbSBteSBvd24gZXhwZXJp ZW5jZSAobm90IHRlc3RpbmcpIEkgYWdyZWUgd2l0aCBCcmlhbiYjMzk7cyBjbGFpbSB0aGF0IDUw MCBtcyByb3VuZCB0cmlwIGlzIGFjY2VwdGFibGUgZm9yIG1vc3QgY29udmVyc2F0aW9uLsKgIDxi cj48YnI+SXQgZG9lcyBkZXBlbmQgb24gd2hhdCB5b3UgYXJlIGRvaW5nLCBhbmQgdGhlcmUgYXJl IGNlcnRhaW5seSB0YXNrcyB3aGVyZSBtdWNoIGxvd2VyIGRlbGF5cyBhcmUgbmVlZGVkLjxicj4N Cjxicj5SZWdhcmRzLDxicj5TdGVwaGVuIEJvdHprbzxicj48YnI+PGJyPjxicj48ZGl2IGNsYXNz PSJnbWFpbF9xdW90ZSI+T24gVHVlLCBNYXkgMTEsIDIwMTAgYXQgMjowNiBQTSwgQmVuIFNjaHdh cnR6IDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmJtc2Nod2FyQGZhcy5oYXJ2 YXJkLmVkdSI+Ym1zY2h3YXJAZmFzLmhhcnZhcmQuZWR1PC9hPiZndDs8L3NwYW4+IHdyb3RlOjxi cj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB0IDBw dCAwcHQgMC44ZXg7IGJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBw YWRkaW5nLWxlZnQ6IDFleDsiPk9uIFR1ZSwgMjAxMC0wNS0xMSBhdCAxMjo0OCAtMDQwMCwgTWFy c2hhbGwgRXViYW5rcyB3cm90ZTo8YnI+DQomZ3Q7IEFzIGEgcG9pbnQgb2Ygb3JkZXIsIEkgb2Jq ZWN0IHRvIGFueSBncmFwaHMgd2l0aG91dCBhbiBhdmFpbGFibGUgcGFwZXI8YnI+DQomZ3Q7IGJl aGluZCB0aGVtLjxicj4NCjxicj4NCkkgaGF2ZSBsb2NhdGVkIHRoZSBmaXJzdCBwYXBlciBtZW50 aW9uZWQgYnkgQ2hyaXN0aWFuIEhvZW5lIGF0PGJyPg0KPGEgaHJlZj0iaHR0cDovL2llZWV4cGxv cmUuaWVlZS5vcmcveHBsL2ZyZWVhYnNfYWxsLmpzcD9hcm51bWJlcj04MTk1MiIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly9pZWVleHBsb3JlLmllZWUub3JnL3hwbC9mcmVlYWJzX2FsbC5qc3A/YXJu dW1iZXI9ODE5NTI8L2E+PGJyPg0KYnV0IG9mIGNvdXJzZSBpdCYjMzk7cyBwYXl3YWxsZWQuPGJy Pg0KPGJyPg0KT25lIHRlc3QgaW4gdGhhdCBwYXBlciB0b2xkIHRyYWluZWQgc3ViamVjdHMgdG8g JnF1b3Q7VGFrZSB0dXJucyByZWFkaW5nPGJyPg0KcmFuZG9tIG51bWJlcnMgYWxvdWQgYXMgZmFz dCBhcyBwb3NzaWJsZSZxdW90Oywgb24gYSBwYWlyIG9mIGhhbmRzZXRzIHdpdGg8YnI+DQpuYXJy b3diYW5kIHVuY29tcHJlc3NlZCBhdWRpbyBhbmQgbm8gZWNoby4gwqBTdWJqZWN0cyB3ZXJlIGFi bGUgdG8gZGV0ZWN0PGJyPg0Kcm91bmQtdHJpcCBkZWxheXMgZG93biB0byA5MCBtcy4gwqBDb252 ZXJzYXRpb25hbCBlZmZpY2llbmN5IHdhcyBpbXBhaXJlZDxicj4NCmV2ZW4gd2l0aCByb3VuZC10 cmlwIGRlbGF5IG9mIDEwMCBtcy48YnI+DQo8YnI+DQpMZXQgbWUgZW1waGFzaXplIGFnYWluIHRo YXQgdGhlc2UgZGVsYXlzIGFyZSByb3VuZC10cmlwLCBub3Qgb25lLXdheSw8YnI+DQp0aGVyZSBp cyBubyBlY2hvLCBhbmQgdGhlIHRhc2ssIHdoaWxlIGRlc2lnbmVkIHRvIGV4cG9zZSBsYXRlbmN5 LCBpczxicj4NCnByb2JhYmx5IGxlc3MgZGVtYW5kaW5nIHRoYW4gbXVzaWNhbCBwZXJmb3JtYW5j ZS48YnI+DQo8YnI+DQpJbiB0aGUgcHJlc2VuY2Ugb2YgZWNobywgcm91bmQtdHJpcCBkZWxheSBt dXN0IGJlIGtlcHQgYmVsb3cgMzAgbXMgdG88YnI+DQplbnN1cmUgdGhhdCB0aGUgZWNobyBpcyBw ZXJjZWl2ZWQgYXMgc2lkZXRvbmUsIGFjY29yZGluZyB0byB0aGUgU3ByaW5nZXI8YnI+DQpoYW5k Ym9vayBvZiBzcGVlY2ggcHJvY2Vzc2luZzo8YnI+DQo8YnI+DQooPGEgaHJlZj0iaHR0cDovL2Jv b2tzLmdvb2dsZS5jb20vYm9va3M/aWQ9U2xnMTBla1pCa0FDJmFtcDtscGc9UEE4MyZhbXA7b3Rz PXdjOXlNOVdyQ3MmYW1wO2RxPXNpZGV0b25lJTIwZGVsYXklMjAzMCUyMG1zJmFtcDtsciZhbXA7 cGc9UEE4NCN2PW9uZXBhZ2UmYW1wO3EmYW1wO2Y9ZmFsc2UiIHRhcmdldD0iX2JsYW5rIj5odHRw Oi8vYm9va3MuZ29vZ2xlLmNvbS9ib29rcz9pZD1TbGcxMGVrWkJrQUMmYW1wO2xwZz1QQTgzJmFt cDtvdHM9d2M5eU05V3JDcyZhbXA7ZHE9c2lkZXRvbmUlMjBkZWxheSUyMDMwJTIwbXMmYW1wO2xy JmFtcDtwZz1QQTg0I3Y9b25lcGFnZSZhbXA7cSZhbXA7Zj1mYWxzZTwvYT4pPGJyPg0KDQo8YnI+ DQpTdWNoIGxvdyBkZWxheXMgYXJlIGNsZWFybHkgaW1wb3NzaWJsZSBvbiBtYW55IHBhdGhzLCBi dXQgZm9yIEJvc3RvbiB0bzxicj4NCk5ldyBZb3JrIENpdHkgKG9yIExvbmRvbiB0byBQYXJpcyks IHBpbmcgdGltZXMgY2FuIGJlIGxlc3MgdGhhbiAxOCBtcyw8YnI+DQptYWtpbmcgZWNoby0mZ3Q7 c2lkZXRvbmUgY29udmVyc2lvbiBqdXN0IGJhcmVseSBwb3NzaWJsZSBmb3IgYSBjb2RlYyB3aXRo PGJyPg0KNW1zIGZyYW1lcy48YnI+DQo8YnI+DQpJIGFjY2VwdCBCcmlhbiBSb3NlbiYjMzk7cyBj bGFpbSB0aGF0IGEgc2xvdyBjb252ZXJzYXRpb24gZG9lc24mIzM5O3Qgbm9ybWFsbHk8YnI+DQpz dWZmZXIgZ3JlYXRseSBmcm9tIHJvdW5kLXRyaXAgbGF0ZW5jaWVzIHVwIHRvIDUwMCBtcywgYnV0 IHVuZGVyIHNvbWU8YnI+DQpjaXJjdW1zdGFuY2VzIG11Y2ggbG93ZXIgbGF0ZW5jaWVzIGFyZSB2 YWx1YWJsZS4gwqBMZXQmIzM5O3MgbWFrZSBzdXJlPGJyPg0KdGhleSYjMzk7cmUgYWNoaWV2YWJs ZSBmb3IgdGhvc2Ugd2hvIGNhbiB1c2UgdGhlbS48YnI+DQo8YnI+DQotLUJlbjxicj4NCjxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KY29k ZWMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmNvZGVjQGlldGYub3JnIj5jb2Rl Y0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2NvZGVjIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jb2RlYzwvYT48YnI+DQo8L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPg0K --_000_05542EC42316164383B5180707A489EE1D593774ECEMBX02HQjnprn_-- From stephen.botzko@gmail.com Tue May 11 12:03:28 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1328C28C285 for ; Tue, 11 May 2010 12:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.537 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-BrEH92zlVF for ; Tue, 11 May 2010 12:03:26 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id C42D53A6C23 for ; Tue, 11 May 2010 12:02:51 -0700 (PDT) Received: by wwb28 with SMTP id 28so601281wwb.31 for ; Tue, 11 May 2010 12:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=2jp3y3S562WAXNRucBz5zRiBiDJYUlCkJMplsE8ovSU=; b=JFFP52Wh+OoLvnpePA5Ib/hHtrTMcqbb1Q5oPFBusV4XAshFTMNap/udd8G4blOq+8 PvYWQK/sgRVxcQqphEuuVXDjsq9M6gliMRjuSGBRdr/lntibzALNwQLzV6RWYtJYgOVp ie7NR5LBLGoHwgS/ZPbB6abq5kmB6YruGTX0E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cyBmfHnHLl2I96554KG3AxWnzKL+YMA60wnOAS0gt58MDtkIa3xoIf0Nv3i78vSKJV I/kI9gkrsAMplEF/hqlL2KlnmmvT2Ci0fU7lSjYg5XTPCo7Uh8WjXKq7zucA2QP3o041 wueiZhYfHCYSYd+mSYhjh72o46pph4b88sMog= MIME-Version: 1.0 Received: by 10.216.176.141 with SMTP id b13mr3841033wem.65.1273604555546; Tue, 11 May 2010 12:02:35 -0700 (PDT) Received: by 10.216.23.5 with HTTP; Tue, 11 May 2010 12:02:35 -0700 (PDT) In-Reply-To: <05542EC42316164383B5180707A489EE1D593774EC@EMBX02-HQ.jnpr.net> References: <05542EC42316164383B5180707A489EE1D593774EC@EMBX02-HQ.jnpr.net> Date: Tue, 11 May 2010 15:02:35 -0400 Message-ID: From: stephen botzko To: Michael Knappe Content-Type: multipart/alternative; boundary=0016e64c1ada1e22590486562bd6 Cc: "codec@ietf.org" Subject: Re: [codec] Thresholds and delay. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 19:03:28 -0000 --0016e64c1ada1e22590486562bd6 Content-Type: text/plain; charset=ISO-8859-1 I agree, I wasn't meaning to propose 500 ms round trip times as the goal. Stephen Botzko On Tue, May 11, 2010 at 2:56 PM, Michael Knappe wrote: > Stephen, > > Agreed that achieving low enough latencies for sidetone perception should > not be a goal of the wg, but we should be aiming if at all possible for > better than 250 ms one-way delay in typical (and non-tandemed) deployments. > The knee of the one-way delay impairment factor begins rising non-linearly > somewhere between 150 and 250 ms. > > Mike > > ------------------------------ > *From*: codec-bounces@ietf.org > *To*: Ben Schwartz > *Cc*: codec@ietf.org > *Sent*: Tue May 11 14:19:22 2010 > *Subject*: Re: [codec] Thresholds and delay. > >>> > In the presence of echo, round-trip delay must be kept below 30 ms to > ensure that the echo is perceived as sidetone, according to the Springer > handbook of speech processing: > >>> > Though true, I don't think this is a mainstream consideration. > > VOIP phones that are capable of speakerphone operation all have acoustic > echo cancelers, and those cancelers are already tuned to deal with internet > delays with other voice codecs. Certainly our phones and videoconferencing > systems do not have problems with path delays of this order (hundreds of > milliseconds). > > From my own experience (not testing) I agree with Brian's claim that 500 ms > round trip is acceptable for most conversation. > > It does depend on what you are doing, and there are certainly tasks where > much lower delays are needed. > > Regards, > Stephen Botzko > > > > On Tue, May 11, 2010 at 2:06 PM, Ben Schwartz wrote: > >> On Tue, 2010-05-11 at 12:48 -0400, Marshall Eubanks wrote: >> > As a point of order, I object to any graphs without an available paper >> > behind them. >> >> I have located the first paper mentioned by Christian Hoene at >> http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=81952 >> but of course it's paywalled. >> >> One test in that paper told trained subjects to "Take turns reading >> random numbers aloud as fast as possible", on a pair of handsets with >> narrowband uncompressed audio and no echo. Subjects were able to detect >> round-trip delays down to 90 ms. Conversational efficiency was impaired >> even with round-trip delay of 100 ms. >> >> Let me emphasize again that these delays are round-trip, not one-way, >> there is no echo, and the task, while designed to expose latency, is >> probably less demanding than musical performance. >> >> In the presence of echo, round-trip delay must be kept below 30 ms to >> ensure that the echo is perceived as sidetone, according to the Springer >> handbook of speech processing: >> >> ( >> http://books.google.com/books?id=Slg10ekZBkAC&lpg=PA83&ots=wc9yM9WrCs&dq=sidetone%20delay%2030%20ms&lr&pg=PA84#v=onepage&q&f=false >> ) >> >> Such low delays are clearly impossible on many paths, but for Boston to >> New York City (or London to Paris), ping times can be less than 18 ms, >> making echo->sidetone conversion just barely possible for a codec with >> 5ms frames. >> >> I accept Brian Rosen's claim that a slow conversation doesn't normally >> suffer greatly from round-trip latencies up to 500 ms, but under some >> circumstances much lower latencies are valuable. Let's make sure >> they're achievable for those who can use them. >> >> --Ben >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> > > --0016e64c1ada1e22590486562bd6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree, I wasn't meaning to propose 500 ms round trip times as the goa= l.

Stephen Botzko

On Tue, May 11, = 2010 at 2:56 PM, Michael Knappe <mknappe@juniper.net> wrote:

Stephen,

Agreed that achieving low enough latencies for sidetone per= ception should not be a goal of the wg, but we should be aiming if at all p= ossible for better than 250 ms one-way delay in typical (and non-tandemed) = deployments. The knee of the one-way delay impairment factor begins rising = non-linearly somewhere between 150 and 250 ms.

Mike

From: co= dec-bounces@ietf.org <codec-bounces@ietf.org>
To: Ben Schwartz <bmschwar@fas.harvard.edu>
Cc: codec@ie= tf.org <codec@ie= tf.org>
Sent: Tue May 11 14:19:22 2010
Subject: Re: [codec] Th= resholds and delay.
>>>
In the presence of echo, round-trip delay must be kept belo= w 30 ms to
ensure that the echo is perceived as sidetone, according to the Springer handbook of speech processing:
>>>
Though true, I don't = think this is a mainstream consideration.=A0

VOIP phones that are capable of speakerphone operation all have acoustic = echo cancelers, and those cancelers are already tuned to deal with internet= delays with other voice codecs.=A0 Certainly our phones and videoconferenc= ing systems do not have problems with path delays of this order (hundreds o= f milliseconds).=A0

From my own experience (not testing) I agree with Brian's claim tha= t 500 ms round trip is acceptable for most conversation.=A0

It does= depend on what you are doing, and there are certainly tasks where much low= er delays are needed.

Regards,
Stephen Botzko



On Tue, May 11, 2010 at 2:06 PM, Ben Schwartz <bmschwar@fas.harvard.edu> wrote:
On Tue, 2010-05-11 at 12:48 -0400, Marshall Eubanks wrote:
> As a point of order, I object to any graphs without an available paper=
> behind them.

I have located the first paper mentioned by Christian Hoene at
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber= =3D81952
but of course it's paywalled.

One test in that paper told trained subjects to "Take turns reading random numbers aloud as fast as possible", on a pair of handsets with<= br> narrowband uncompressed audio and no echo. =A0Subjects were able to detect<= br> round-trip delays down to 90 ms. =A0Conversational efficiency was impaired<= br> even with round-trip delay of 100 ms.

Let me emphasize again that these delays are round-trip, not one-way,
there is no echo, and the task, while designed to expose latency, is
probably less demanding than musical performance.

In the presence of echo, round-trip delay must be kept below 30 ms to
ensure that the echo is perceived as sidetone, according to the Springer handbook of speech processing:

(http://books.google.c= om/books?id=3DSlg10ekZBkAC&lpg=3DPA83&ots=3Dwc9yM9WrCs&dq=3Dsid= etone%20delay%2030%20ms&lr&pg=3DPA84#v=3Donepage&q&f=3Dfals= e)

Such low delays are clearly impossible on many paths, but for Boston to
New York City (or London to Paris), ping times can be less than 18 ms,
making echo->sidetone conversion just barely possible for a codec with 5ms frames.

I accept Brian Rosen's claim that a slow conversation doesn't norma= lly
suffer greatly from round-trip latencies up to 500 ms, but under some
circumstances much lower latencies are valuable. =A0Let's make sure
they're achievable for those who can use them.

--Ben

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec


--0016e64c1ada1e22590486562bd6-- From rchen@broadcom.com Tue May 11 17:17:46 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A24C63A6C14 for ; Tue, 11 May 2010 17:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.935 X-Spam-Level: X-Spam-Status: No, score=0.935 tagged_above=-999 required=5 tests=[AWL=-1.232, BAYES_50=0.001, FF_IHOPE_YOU_SINK=2.166] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kF-PKeFaEzto for ; Tue, 11 May 2010 17:17:45 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 1BB3F3A6AA9 for ; Tue, 11 May 2010 17:17:45 -0700 (PDT) Received: from [10.9.200.133] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 11 May 2010 17:17:24 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Tue, 11 May 2010 17:18:47 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Christian Hoene" , "'Jean-Marc Valin'" Date: Tue, 11 May 2010 17:17:22 -0700 Thread-Topic: [codec] #20: Computational complexity? Thread-Index: AcrwglZlRdRMon4wRWWDChT4kHf3/QABZ4egABF0sYAAJg33cA== Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> <20100507144856.171013mxhy3wdfbc@mail.skype.net> <20100509143636.21296os5ryogl1ic@mail.skype.net> <4BE85F57.9040205@digium.com> <4BE87165.2030401@octasic.com> <000001caf0cf$282a2e70$787e8b50$@de> In-Reply-To: <000001caf0cf$282a2e70$787e8b50$@de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67F72C1E20S122033864-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #20: Computational complexity? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 00:17:46 -0000 Hi Christian, (I changed the subject line to better reflect the nature of the email threa= d below...) The ITU-T software tool library has been used to measure the complexity of = many fixed-point standard speech codecs, and we have done that, too. So, y= es, I think it is a good and well-accepted way to measure the complexity of= fixed-point codecs. For floating-point implementations, although I don't know of a similar soft= ware tool for complexity measurement, it is not that difficult to do someth= ing similar and add some complexity counting code to an existing floating-p= oint C code to measure the complexity of a floating-point codec. Best Regards, Raymond -----Original Message----- From: Christian Hoene [mailto:hoene@uni-tuebingen.de]=20 Sent: Monday, May 10, 2010 11:00 PM To: Raymond (Juin-Hwey) Chen; 'Jean-Marc Valin' Cc: codec@ietf.org Subject: RE: [codec] #16: Multicast? Hello, what do you think about STL2005/9 described in ITU-T G.191. It might be a g= ood metric to measure the codec performance in low-complexity mode. STL2009 is not yet published officially but the STL 20= 05 manual is available for free. http://www.itu.int/rec/T-REC-G.191-200508-I/en Chapter 13, Page 159 describes a set of basic operator and their complexity= weights. STL2009 is similar but has guidelines on data movement and program ROM estimation tool for fixed-point c code and a compl= exity evaluation tool for floating-point C Code. However, STL2005 might not be optimal for soft-phone complexity prediction = because many operations have overflow control and saturation, that typically cannot be translated into a single native assemb= ler instruction. Thus, for soft-phone I would recommend to use slightly modified measures... With best regards, Christian --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ >-----Original Message----- >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Raymond (Juin-Hwey) Chen >Sent: Tuesday, May 11, 2010 12:03 AM >To: Jean-Marc Valin >Cc: codec@ietf.org >Subject: Re: [codec] #16: Multicast? > >Hi Jean-Marc, > >I didn't just cook up those MIPS numbers out of my head :o) I have been w= orking with Bluetooth >engineers on voice/audio processing for Bluetooth headsets in the last few= years. > >Bluetooth headsets normally don't use general-purpose DSPs from those trad= itional DSP houses that you >mentioned below. A lot of mid- to low-end Bluetooth headsets (where most = of the shipping volume is) >don't even have any DSP and instead just rely on an ARM processor to do al= l voice/audio processing and >Bluetooth protocol stack. The 5 MIPS number for current-generation BT hea= dsets was quoted to me by an >experienced Bluetooth audio engineering manager in terms of MIPS on an ARM= processor, but since most >speech coding engineers are more familiar with the MIPS for a general-purp= ose 16-bit fixed-point DSP, >so I converted the MIPS on an ARM to the equivalent MIPS on a fixed-point = DSP, and it came to around 5 >MIPS. The 10 to 20 MIPS number is what we may expect in a several years a= s Moore's Law helps to >increase the processing power of Bluetooth headsets. > >High-end Bluetooth headset chips may have a DSP on-chip, but it is usually= either a proprietary DSP or >a DSP core not from the traditional DSP houses but from companies like ARM= . > >One thing to keep in mind, though, is that even if you have a DSP on a Blu= etooth headset chip, and it >is clocked at 50 MHz or higher, it doesn't mean that you can use all or mo= st of that DSP processing >power for speech or audio coding. This is because it has to handle many o= ther signal processing tasks >such as acoustic echo canceller, single-mic or multi-mic noise suppression= , wind noise suppression, >packet loss concealment, voice prompt decoding, and even voice command rec= ognition, to name just a >few. You can't even get half of the DSP processing power solely dedicated= to speech coding. You will >be lucky if you can get 20% of the DSP for speech coding. Remember that c= urrently the speech coding >part (CVSD codec) takes 0% of the DSP or ARM because it is done in chip ha= rdware. > >Raymond > >-----Original Message----- >From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] >Sent: Monday, May 10, 2010 1:50 PM >To: Raymond (Juin-Hwey) Chen >Cc: Kevin P. Fleming; codec@ietf.org >Subject: Re: [codec] #16: Multicast? > >Hi Raymond, > >I'm just curious about where you got your MIPS figures for Bluetooth? I'm >not familiar with the type of DSPs used in those applications, but from a >quick search of more "general-purpose" DSPs (TI, ADI and similar), the >lowest speed I was able to find (sold in 2010) was a 50 MIPS DSP. Any idea >what type of DSPs are currently used in Bluetooth? > >Cheers, > > Jean-Marc > >Raymond (Juin-Hwey) Chen wrote: >> Hi Kevin, >> >> I completely agree with you that the IETF codec development should not >> be constrained by a low-complexity device designed in 2009 or earlier, >> and we should look toward the time frame of 2012 and 2013 instead. >> >> In my previous emails I have indicated that due to many reasons, over >> the last several years the processing power of Bluetooth headsets has >> been increasing at a rate much slower than what's predicted by Moore's >> Law, and it doesn't look like this will change significantly in the next >> few years. I also said that for the current-generation Bluetooth >> headset chips, the maximum codec complexity it can support is probably >> somewhere around 5 MIPS on a 16-bit fixed-point DSP, and by the time the >> IETF codec becomes a standard, the number may go up to 10 MIPS, or 15 >> MIPS at most. >> >> Thus, if we want mono Bluetooth headsets in the FUTURE (i.e. in the next >> several years) to be able to run the IETF codec in the narrowband or >> wideband mode at least, a good complexity target to shoot for is 10 to >> 20 MIPS on a fixed-point DSP. >> >> Raymond >> >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf O= f Kevin P. Fleming >> Sent: Monday, May 10, 2010 12:33 PM >> To: codec@ietf.org >> Subject: Re: [codec] #16: Multicast? >> >> On 05/10/2010 02:11 PM, Raymond (Juin-Hwey) Chen wrote: >> >>> Considering that there are a very large number of Bluetooth headset use= rs and that the current >Bluetooth headsets can already be used for making VoIP phone calls, it wou= ld be great if the IETF >codec can be implemented in future Bluetooth headsets to avoid the additio= nal coding distortion and >delay associated with transcoding. However, with that said, I didn't mean = to push a "Bluetooth mode" >for the IETF codec. I merely wanted to use Bluetooth headset as an example= to make a point that a low >codec complexity is desirable and a high codec complexity can have negativ= e consequences. >> >> This is all perfectly reasonable, but given the likely timeframe we are >> talking about for this codec to be produced and published as a >> standards-track RFC, the definition of 'low complexity' in this >> discussion is really talking about the 2012-2013 version of 'low >> complexity', not today's. It seems highly likely that the MIPS capacity >> of the DSPs designed into Bluetooth headsets in 2012 will be vastly >> greater than what is used today, if there is an application to take >> advantage of the additional MIPS. >> >> I'd hate to see this codec's development constrained in any significant >> way by the requirements of a low-complexity device designed in 2009 or >> earlier. >> >> -- >> Kevin P. Fleming >> Digium, Inc. | Director of Software Technologies >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >> skype: kpfleming | jabber: kfleming@digium.com >> Check us out at www.digium.com & www.asterisk.org >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec > > > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From rchen@broadcom.com Tue May 11 19:18:51 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D657328C0F0 for ; Tue, 11 May 2010 19:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.115 X-Spam-Level: X-Spam-Status: No, score=-0.115 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKuacx2UlU1F for ; Tue, 11 May 2010 19:18:48 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id B56A628C0ED for ; Tue, 11 May 2010 19:18:47 -0700 (PDT) Received: from [10.9.200.133] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 11 May 2010 19:18:26 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Tue, 11 May 2010 19:19:49 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Koen Vos" , "bens@alum.mit.edu" , "Benjamin M. Schwartz" Date: Tue, 11 May 2010 19:18:25 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: Acrw0mATDtvAvsPcTemmFkzsF3mL4AAlncHA Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <002c01cae939$5c01f400$1405dc00$@de> , <009901caede1$43f366d0$cbda3470$@de> <20100510232234.16632o6l2ecu3wyy@mail.skype.net> In-Reply-To: <20100510232234.16632o6l2ecu3wyy@mail.skype.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67F4D07820S122105949-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 02:18:51 -0000 Hi Koen, You wrote: > Not a typo: codecs have become more wasteful with delay, while =20 > delivering better fidelity. G.718 evolved out of AMR-WB and has more =20 > than twice the delay. Same for G.729.1 versus G.729. This is not by =20 > accident. [Raymond]: If you read the published technical papers on G.718 and=20 G.729.1 carefully, I think you will find that the real reason for the=20 increased delay is not because they needed a longer delay to achieve=20 better fidelity for speech, but because they wanted to extend speech=20 codecs to also get good performance when coding general audio (music,=20 etc.). To get good music coding performance, most audio codecs use=20 Modified Discrete Cosine Transform (MDCT) with at least a transform=20 window size that is fairly large, so most of the audio codecs have=20 longer coding delays than speech codecs. =20 To code music well, G.718 and G.729.1 developers naturally had to use=20 long MDCT transform windows on top of the codec delay already in AMR- WB and G.729. Even so, the resulting longer delays of G.718 and=20 G.729.1 are still not any longer than typical delays of audio codecs;=20 in fact, they are probably somewhat shorter.=20 My point is that the increased delays of G.718 and G.729.1 are purely=20 a result of changing from "speech-only" to "speech and music". It's=20 not because the G.718 and G.729.1 developers knew the network delay=20 was getting shorter so they could be more wasteful with delay. =20 Furthermore, even after they changed the codecs to handle music as=20 well as speech, they still chose to make their codec delays shorter=20 than the delays of most audio codecs. Why? They wanted to make=20 their codec delays as short as they could. In fact, they even made=20 an effort to introduce a "low-delay mode" into both G.718 and=20 G.729.1. That shows they were pretty concerned about the higher=20 delays they needed to have in order to code music well.=20 By the way, G.718 does NOT have "more than twice the delay" of AMR-WB=20 as you said. AMR-WB has a 20 ms frame size, 5 ms look-ahead, and=20 1.875 ms of filtering delay, for a total algorithmic buffering delay=20 of 26.875 ms. The "normal mode" of G.718 has a buffering delay of=20 42.875 ms for 16 kHz wideband input/output. That's only 59.5% higher=20 than AMR-WB. For Layers 1 and 2 coding of speech, the "low-delay=20 mode" shaves 10 ms off to give a delay of 32.875 ms, or only 22.3%=20 higher than AMR-WB. When G.729.1 was first standardized in May 2006, there was already a=20 low-delay mode for narrowband speech at 8 and 12 kb/s with a=20 algorithmic buffering delay of 25 ms. Later in August 2007, the=20 developers made an effort to add another low-delay mode for wideband=20 at 14 kb/s that has a buffering delay of 28.94 ms. If they wanted to=20 sacrifice delay to get higher fidelity as you suggested, then why=20 would they bother to go back and add another low-delay mode for=20 wideband?=20 In fact, only a few months ago in their G.729.1 paper in IEEE=20 Communications Magazine, October 2009, Varga, Proust, and Taddei=20 still emphasized in multiple instances the importance of achieving a=20 low coding delay. I will quote two of the instances:=20 "The low-delay mode... was added to the first wideband layer at 14=20 kb/s of G.729.1 (August 2007). The motivation was to address=20 applications such as VoIP in enterprise networks where low end-to-end=20 delay is crucial" and=20 "Indeed, delay is an important performance parameter, and=20 transmitting speech with low end-to-end delay is also required in=20 several applications making use of wideband signals". In summary, I do not see a clear trend where codec developers are=20 becoming more wasteful with delay in order to get higher fidelity. If=20 anything, in recent years I saw a trend of low-delay audio coding,=20 such as low-delay AAC and the CELT codec, and I saw the effort by=20 G.718 and G.729.1 developers to introduce low-delay modes. In any case, I thought a few days ago a consensus was already reached=20 in the WG email reflector that the IETF codec needs to have a low- delay mode with a 5 to 10 ms codec frame size so that it can handle=20 delay-sensitive applications (that is 5 out of 6 applications listed=20 in the charter and codec requirement document). Therefore, I think=20 the discussion in your last email and my current email is mostly of=20 academic interest only and doesn't and shouldn't affect how the IETF=20 codec is to be designed. Best Regards, Raymond From jari.hagqvist@nokia.com Wed May 12 01:01:50 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8BC33A6836 for ; Wed, 12 May 2010 01:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRJfNLjRPU16 for ; Wed, 12 May 2010 01:01:49 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 323BF3A67F5 for ; Wed, 12 May 2010 01:01:49 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o4C81PYJ023297; Wed, 12 May 2010 03:01:37 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 May 2010 11:01:34 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 May 2010 11:01:25 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 May 2010 11:01:21 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Wed, 12 May 2010 10:01:20 +0200 From: To: Date: Wed, 12 May 2010 10:01:18 +0200 Thread-Topic: [codec] Thresholds and delay. Thread-Index: AcrxNwEJ3XyZfic9SVOFRSImfpVKyAAbsIUg Message-ID: <0E94BEEABCAE4C4EAC18B13A7A5C2456529E25A60C@NOK-EUMSG-01.mgdnok.nokia.com> References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <002c01cae939$5c01f400$1405dc00$@de> <009901caede1$43f366d0$cbda3470$@de> <20100510232234.16632o6l2ecu3wyy@mail.skype.net> <006101caf117$aaf3b2c0$00db1840$@de> <1273595415.1684.33.camel@dell-desktop> <2B114368-93C0-410B-AB66-53CA33E921A8@americafree.tv> <1273601174.1684.79.camel@dell-desktop> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0E94BEEABCAE4C4EAC18B13A7A5C2456529E25A60CNOKEUMSG01mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 12 May 2010 08:01:21.0111 (UTC) FILETIME=[4F070E70:01CAF1A9] X-Nokia-AV: Clean Cc: codec@ietf.org Subject: Re: [codec] Thresholds and delay. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 08:01:50 -0000 --_000_0E94BEEABCAE4C4EAC18B13A7A5C2456529E25A60CNOKEUMSG01mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stephen&co, Generally I believe that AECs mainly take care of the acoustic echo generat= ed in the phone itself (operating on the microphone signal, acoustic delay = up to a few ms). Do you mean that there is additional processing on the rec= eiving side for the echo returning from the B user side? Best regards, Jari From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of e= xt stephen botzko Sent: 11 May, 2010 21:19 To: Ben Schwartz Cc: codec@ietf.org Subject: Re: [codec] Thresholds and delay. >>> In the presence of echo, round-trip delay must be kept below 30 ms to ensure that the echo is perceived as sidetone, according to the Springer handbook of speech processing: >>> Though true, I don't think this is a mainstream consideration. VOIP phones that are capable of speakerphone operation all have acoustic ec= ho cancelers, and those cancelers are already tuned to deal with internet d= elays with other voice codecs. Certainly our phones and videoconferencing = systems do not have problems with path delays of this order (hundreds of mi= lliseconds). >From my own experience (not testing) I agree with Brian's claim that 500 ms= round trip is acceptable for most conversation. It does depend on what you are doing, and there are certainly tasks where m= uch lower delays are needed. Regards, Stephen Botzko On Tue, May 11, 2010 at 2:06 PM, Ben Schwartz > wrote: On Tue, 2010-05-11 at 12:48 -0400, Marshall Eubanks wrote: > As a point of order, I object to any graphs without an available paper > behind them. I have located the first paper mentioned by Christian Hoene at http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=3D81952 but of course it's paywalled. One test in that paper told trained subjects to "Take turns reading random numbers aloud as fast as possible", on a pair of handsets with narrowband uncompressed audio and no echo. Subjects were able to detect round-trip delays down to 90 ms. Conversational efficiency was impaired even with round-trip delay of 100 ms. Let me emphasize again that these delays are round-trip, not one-way, there is no echo, and the task, while designed to expose latency, is probably less demanding than musical performance. In the presence of echo, round-trip delay must be kept below 30 ms to ensure that the echo is perceived as sidetone, according to the Springer handbook of speech processing: (http://books.google.com/books?id=3DSlg10ekZBkAC&lpg=3DPA83&ots=3Dwc9yM9WrC= s&dq=3Dsidetone%20delay%2030%20ms&lr&pg=3DPA84#v=3Donepage&q&f=3Dfalse) Such low delays are clearly impossible on many paths, but for Boston to New York City (or London to Paris), ping times can be less than 18 ms, making echo->sidetone conversion just barely possible for a codec with 5ms frames. I accept Brian Rosen's claim that a slow conversation doesn't normally suffer greatly from round-trip latencies up to 500 ms, but under some circumstances much lower latencies are valuable. Let's make sure they're achievable for those who can use them. --Ben _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_0E94BEEABCAE4C4EAC18B13A7A5C2456529E25A60CNOKEUMSG01mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stephen&co,

 

Generally I believe that AECs mainly take care of the acoust= ic echo generated in the phone itself (operating on the microphone signal, aco= ustic delay up to a few ms). Do you mean that there is additional processing on t= he receiving side for the echo returning from the B user side?

 

Best regards,

Jari

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = ext stephen botzko
Sent: 11 May, 2010 21:19
To: Ben Schwartz
Cc: codec@ietf.org
Subject: Re: [codec] Thresholds and delay.

 

>>>
In the presence of echo, round-trip delay must be kept below 30 ms to
ensure that the echo is perceived as sidetone, according to the Springer handbook of speech processing:
>>>
Though true, I don't think this is a mainstream consideration. 

VOIP phones that are capable of speakerphone operation all have acoustic ec= ho cancelers, and those cancelers are already tuned to deal with internet dela= ys with other voice codecs.  Certainly our phones and videoconferencing systems do not have problems with path delays of this order (hundreds of milliseconds). 

>From my own experience (not testing) I agree with Brian's claim that 500 ms round trip is acceptable for most conversation. 

It does depend on what you are doing, and there are certainly tasks where m= uch lower delays are needed.

Regards,
Stephen Botzko


On Tue, May 11, 2010 at 2:06 PM, Ben Schwartz <bmschwar@fas.harvard.edu> w= rote:

On Tue, 2010-05-11 at 12:48 -0400, Marshall Eubanks wr= ote:
> As a point of order, I object to any graphs without an available paper=
> behind them.

I have located the first paper mentioned by Christian Hoene at
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber= =3D81952
but of course it's paywalled.

One test in that paper told trained subjects to "Take turns reading random numbers aloud as fast as possible", on a pair of handsets with<= br> narrowband uncompressed audio and no echo.  Subjects were able to dete= ct
round-trip delays down to 90 ms.  Conversational efficiency was impair= ed
even with round-trip delay of 100 ms.

Let me emphasize again that these delays are round-trip, not one-way,
there is no echo, and the task, while designed to expose latency, is
probably less demanding than musical performance.

In the presence of echo, round-trip delay must be kept below 30 ms to
ensure that the echo is perceived as sidetone, according to the Springer handbook of speech processing:

(http://books.google.com/books?id=3DSlg10ekZBkAC&lpg= =3DPA83&ots=3Dwc9yM9WrCs&dq=3Dsidetone%20delay%2030%20ms&lr&= ;pg=3DPA84#v=3Donepage&q&f=3Dfalse)

Such low delays are clearly impossible on many paths, but for Boston to
New York City (or London to Paris), ping times can be less than 18 ms,
making echo->sidetone conversion just barely possible for a codec with 5ms frames.

I accept Brian Rosen's claim that a slow conversation doesn't normally
suffer greatly from round-trip latencies up to 500 ms, but under some
circumstances much lower latencies are valuable.  Let's make sure
they're achievable for those who can use them.

--Ben

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

 

--_000_0E94BEEABCAE4C4EAC18B13A7A5C2456529E25A60CNOKEUMSG01mgd_-- From stephen.botzko@gmail.com Wed May 12 03:43:24 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A952C3A68D8 for ; Wed, 12 May 2010 03:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.207 X-Spam-Level: X-Spam-Status: No, score=-0.207 tagged_above=-999 required=5 tests=[AWL=-0.809, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iL9ZgyWP2M6v for ; Wed, 12 May 2010 03:43:23 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id C1DA33A6843 for ; Wed, 12 May 2010 03:43:22 -0700 (PDT) Received: by wwb28 with SMTP id 28so1210054wwb.31 for ; Wed, 12 May 2010 03:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=01jXcwiCJpBk4wd6iWOktwTT/r0pr+GnBrTDTLFLVNM=; b=SqxtOLhkni3+OkGfrLEdh92VlHVz7JjqfLm3FQ+JksREQDyIw9e63PQU5tRmXwDMT7 lie/JLEM6s9lYUlRwNGzT1wJtM6lQdwiatmXcGtlbt6eWvTuwGen+Qrw6JhI671n5s67 y+73MR/785fgCr8eeqdBXxZzNP7pA2IoKIL5I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UpmNUmjdGrN4NIzbltrHyAjPMKM/DQcxEA6Y3sF8NT+xainDn1ABvuI7uhuDns9yRG O7u+N2bVbqomcq0LLI/iSgUuLKvsIm0nDzrAabYO7HUHF7mKbFJhKdd6ndTWZotIm3dA gfRks0eE6iCqObQHGVccP6MSoymQjyMVvxNlo= MIME-Version: 1.0 Received: by 10.216.158.1 with SMTP id p1mr4317326wek.202.1273660988920; Wed, 12 May 2010 03:43:08 -0700 (PDT) Received: by 10.216.23.5 with HTTP; Wed, 12 May 2010 03:43:08 -0700 (PDT) In-Reply-To: <0E94BEEABCAE4C4EAC18B13A7A5C2456529E25A60C@NOK-EUMSG-01.mgdnok.nokia.com> References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <009901caede1$43f366d0$cbda3470$@de> <20100510232234.16632o6l2ecu3wyy@mail.skype.net> <006101caf117$aaf3b2c0$00db1840$@de> <1273595415.1684.33.camel@dell-desktop> <2B114368-93C0-410B-AB66-53CA33E921A8@americafree.tv> <1273601174.1684.79.camel@dell-desktop> <0E94BEEABCAE4C4EAC18B13A7A5C2456529E25A60C@NOK-EUMSG-01.mgdnok.nokia.com> Date: Wed, 12 May 2010 06:43:08 -0400 Message-ID: From: stephen botzko To: jari.hagqvist@nokia.com Content-Type: multipart/alternative; boundary=0016e649c490cf19360486634e2a Cc: codec@ietf.org Subject: Re: [codec] Thresholds and delay. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 10:43:25 -0000 --0016e649c490cf19360486634e2a Content-Type: text/plain; charset=ISO-8859-1 Acoustic echo cancelers remove the signal from the local speaker(s) that is feeding back into the local microphone(s). So if *my* AEC is turned off, then *you* will hear the echo (and I will not). The echo that *you* hear is delayed by the round trip transport time, the processing delays in the sender and receiver, and the acoustic path delay between the speaker and the microphone. However, the echo that the *AEC*detects is only delayed the acoustic path delay and whatever processing delay (buffering) the receiver has on its audio capture and render circuitry. So you are correct if you are thinking that the network transport time and codec delay do not impact the requirements for the AEC. There can also be path delay between the receiver output and the actual speaker. For instance in a video conferencing application, the video processing in the TV itself can add delay, and the TV will delay the audio to maintain sync. So if your phone system can be connected to external sound systems, then that can effect the delays the AEC has to accommodate. Also, in larger rooms the acoustic path delay can be substantial since sound takes about 100 ms to travel 100 feet (341 meters per second). Regards Stephen Botzko On Wed, May 12, 2010 at 4:01 AM, wrote: > Stephen&co, > > > > Generally I believe that AECs mainly take care of the acoustic echo > generated in the phone itself (operating on the microphone signal, acoustic > delay up to a few ms). Do you mean that there is additional processing on > the receiving side for the echo returning from the B user side? > > > > Best regards, > > Jari > > > > *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On Behalf > Of *ext stephen botzko > *Sent:* 11 May, 2010 21:19 > *To:* Ben Schwartz > *Cc:* codec@ietf.org > > *Subject:* Re: [codec] Thresholds and delay. > > > > >>> > > In the presence of echo, round-trip delay must be kept below 30 ms to > ensure that the echo is perceived as sidetone, according to the Springer > handbook of speech processing: > >>> > Though true, I don't think this is a mainstream consideration. > > VOIP phones that are capable of speakerphone operation all have acoustic > echo cancelers, and those cancelers are already tuned to deal with internet > delays with other voice codecs. Certainly our phones and videoconferencing > systems do not have problems with path delays of this order (hundreds of > milliseconds). > > From my own experience (not testing) I agree with Brian's claim that 500 ms > round trip is acceptable for most conversation. > > It does depend on what you are doing, and there are certainly tasks where > much lower delays are needed. > > Regards, > Stephen Botzko > > > On Tue, May 11, 2010 at 2:06 PM, Ben Schwartz > wrote: > > On Tue, 2010-05-11 at 12:48 -0400, Marshall Eubanks wrote: > > As a point of order, I object to any graphs without an available paper > > behind them. > > I have located the first paper mentioned by Christian Hoene at > http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=81952 > but of course it's paywalled. > > One test in that paper told trained subjects to "Take turns reading > random numbers aloud as fast as possible", on a pair of handsets with > narrowband uncompressed audio and no echo. Subjects were able to detect > round-trip delays down to 90 ms. Conversational efficiency was impaired > even with round-trip delay of 100 ms. > > Let me emphasize again that these delays are round-trip, not one-way, > there is no echo, and the task, while designed to expose latency, is > probably less demanding than musical performance. > > In the presence of echo, round-trip delay must be kept below 30 ms to > ensure that the echo is perceived as sidetone, according to the Springer > handbook of speech processing: > > ( > http://books.google.com/books?id=Slg10ekZBkAC&lpg=PA83&ots=wc9yM9WrCs&dq=sidetone%20delay%2030%20ms&lr&pg=PA84#v=onepage&q&f=false > ) > > Such low delays are clearly impossible on many paths, but for Boston to > New York City (or London to Paris), ping times can be less than 18 ms, > making echo->sidetone conversion just barely possible for a codec with > 5ms frames. > > I accept Brian Rosen's claim that a slow conversation doesn't normally > suffer greatly from round-trip latencies up to 500 ms, but under some > circumstances much lower latencies are valuable. Let's make sure > they're achievable for those who can use them. > > --Ben > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > --0016e649c490cf19360486634e2a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Acoustic echo cancelers remove the signal from the local speaker(s) that is= feeding back into the local microphone(s).=A0 So if my AEC is turne= d off, then you will hear the echo (and I will not).=A0

The = echo that you hear is delayed by the round trip transport time, the = processing delays in the sender and receiver, and the acoustic path delay b= etween the speaker and the microphone.=A0 However, the echo that the AEC= detects is only delayed the acoustic path delay and whatever processin= g delay (buffering) the receiver has on its audio capture and render circui= try.

So you are correct if you are thinking that the network transport time = and codec delay do not impact the requirements for the AEC.

There ca= n also be path delay between the receiver output and the actual=20 speaker.=A0 For instance in a video conferencing application, the video=20 processing in the TV itself can add delay, and the TV will delay the audio to maintain sync.=A0 So if your phone system can b= e connected to external sound systems, then that can effect the delays the = AEC has to accommodate.

Also, in larger rooms the acoustic path dela= y can be substantial since sound takes about 100 ms to travel 100 feet=A0 (= 341 meters per second).

Regards
Stephen Botzko

On Wed, May= 12, 2010 at 4:01 AM, <jari.hagqvist@nokia.com> wrote:

Stephen&co,

=A0

Generally I believe that AECs mainly take care of the acoustic echo generated in the phone itself (operating on the microphone signal, aco= ustic delay up to a few ms). Do you mean that there is additional processing on t= he receiving side for the echo returning from the B user side?

=A0

Best regards,

Jari

=A0

From:= codec-bounces@i= etf.org [mailto:codec-bounces@ietf.org] On Behalf Of ext stephen botzko
Sent: 11 May, 2010 21:19
To: Ben Schwartz
Cc: codec@ietf.o= rg


Subject: Re: [codec] Thresholds and delay.

=A0

>>>

=

In the presence of echo, round-trip delay must be kept below 30 ms to
ensure that the echo is perceived as sidetone, according to the Springer handbook of speech processing:
>>>
Though true, I don't think this is a mainstream consideration.=A0

VOIP phones that are capable of speakerphone operation all have acoustic ec= ho cancelers, and those cancelers are already tuned to deal with internet dela= ys with other voice codecs.=A0 Certainly our phones and videoconferencing systems do not have problems with path delays of this order (hundreds of milliseconds).=A0

>From my own experience (not testing) I agree with Brian's claim that 50= 0 ms round trip is acceptable for most conversation.=A0

It does depend on what you are doing, and there are certainly tasks where m= uch lower delays are needed.

Regards,
Stephen Botzko


On Tue, May 11, 2010 at 2:06 PM, Ben Schwartz <bmschwar@fas.ha= rvard.edu> wrote:

On Tue, 2010-05-11 at 12:48 -0400, Marshall Eubanks = wrote:
> As a point of order, I object to any graphs without an available paper=
> behind them.

I have located the first paper mentioned by Christian Hoene at
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber= =3D81952
but of course it's paywalled.

One test in that paper told trained subjects to "Take turns reading random numbers aloud as fast as possible", on a pair of handsets with<= br> narrowband uncompressed audio and no echo. =A0Subjects were able to detect<= br> round-trip delays down to 90 ms. =A0Conversational efficiency was impaired<= br> even with round-trip delay of 100 ms.

Let me emphasize again that these delays are round-trip, not one-way,
there is no echo, and the task, while designed to expose latency, is
probably less demanding than musical performance.

In the presence of echo, round-trip delay must be kept below 30 ms to
ensure that the echo is perceived as sidetone, according to the Springer handbook of speech processing:

(http://books.google.c= om/books?id=3DSlg10ekZBkAC&lpg=3DPA83&ots=3Dwc9yM9WrCs&dq=3Dsid= etone%20delay%2030%20ms&lr&pg=3DPA84#v=3Donepage&q&f=3Dfals= e)

Such low delays are clearly impossible on many paths, but for Boston to
New York City (or London to Paris), ping times can be less than 18 ms,
making echo->sidetone conversion just barely possible for a codec with 5ms frames.

I accept Brian Rosen's claim that a slow conversation doesn't norma= lly
suffer greatly from round-trip latencies up to 500 ms, but under some
circumstances much lower latencies are valuable. =A0Let's make sure
they're achievable for those who can use them.

--Ben

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

=A0


--0016e649c490cf19360486634e2a-- From bmschwar@fas.harvard.edu Wed May 12 05:28:08 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77DD328C147 for ; Wed, 12 May 2010 05:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.192 X-Spam-Level: X-Spam-Status: No, score=-4.192 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCy0iOkaN80M for ; Wed, 12 May 2010 05:28:07 -0700 (PDT) Received: from us19.unix.fas.harvard.edu (us19.unix.fas.harvard.edu [140.247.35.199]) by core3.amsl.com (Postfix) with ESMTP id 7D1633A67A6 for ; Wed, 12 May 2010 05:23:14 -0700 (PDT) Received: from [192.168.1.139] (c-71-192-160-188.hsd1.nh.comcast.net [71.192.160.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar) by us19.unix.fas.harvard.edu (Postfix) with ESMTPSA id 5DBAFB002D; Wed, 12 May 2010 08:23:03 -0400 (EDT) From: Ben Schwartz To: jari.hagqvist@nokia.com In-Reply-To: <0E94BEEABCAE4C4EAC18B13A7A5C2456529E25A60C@NOK-EUMSG-01.mgdnok.nokia.com> References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <002c01cae939$5c01f400$1405dc00$@de> <009901caede1$43f366d0$cbda3470$@de> <20100510232234.16632o6l2ecu3wyy@mail.skype.net> <006101caf117$aaf3b2c0$00db1840$@de> <1273595415.1684.33.camel@dell-desktop> <2B114368-93C0-410B-AB66-53CA33E921A8@americafree.tv> <1273601174.1684.79.camel@dell-desktop> <0E94BEEABCAE4C4EAC18B13A7A5C2456529E25A60C@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 12 May 2010 08:23:02 -0400 Message-ID: <1273666982.5250.18.camel@dell-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org, stephen.botzko@gmail.com Subject: Re: [codec] Thresholds and delay. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 12:28:08 -0000 On Wed, 2010-05-12 at 10:01 +0200, jari.hagqvist@nokia.com wrote: > > Generally I believe that AECs mainly take care of the acoustic echo > generated in the phone itself (operating on the microphone signal, > acoustic delay up to a few ms). Do you mean that there is additional > processing on the receiving side for the echo returning from the B > user side? Only in the user's head. The psychoacoustics of echo are very different depending on the echo time. This means that the perceived echo-canceler fidelity depends on the acoustic round-trip delay. It also means that the AEC should be retuned depending on the round-trip delay. --Ben From tme@americafree.tv Wed May 12 06:09:30 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9E883A68DF for ; Wed, 12 May 2010 06:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.25 X-Spam-Level: X-Spam-Status: No, score=-100.25 tagged_above=-999 required=5 tests=[AWL=-0.851, BAYES_50=0.001, J_CHICKENPOX_72=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aF3R+WJGGDqr for ; Wed, 12 May 2010 06:09:29 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id DCDBE28C177 for ; Wed, 12 May 2010 06:06:20 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 8B18C712187A; Wed, 12 May 2010 09:06:10 -0400 (EDT) Message-Id: <10633E60-D35F-4CDB-8AF2-F3847C389724@americafree.tv> From: Marshall Eubanks To: stephen botzko In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 12 May 2010 09:06:10 -0400 References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <009901caede1$43f366d0$cbda3470$@de> <20100510232234.16632o6l2ecu3wyy@mail.skype.net> <006101caf117$aaf3b2c0$00db1840$@de> <1273595415.1684.33.camel@dell-desktop> <2B114368-93C0-410B-AB66-53CA33E921A8@americafree.tv> <1273601174.1684.79.camel@dell-desktop> <0E94BEEABCAE4C4EAC18B13A7A5C2456529E25A60C@NOK-EUMSG-01.mgdnok.nokia.com> X-Mailer: Apple Mail (2.936) Cc: codec@ietf.org Subject: Re: [codec] Thresholds and delay. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 13:09:30 -0000 Dear Stephen; On May 12, 2010, at 6:43 AM, stephen botzko wrote: > Acoustic echo cancelers remove the signal from the local speaker(s) > that is feeding back into the local microphone(s). So if my AEC is > turned off, then you will hear the echo (and I will not). > > The echo that you hear is delayed by the round trip transport time, > the processing delays in the sender and receiver, and the acoustic > path delay between the speaker and the microphone. However, the > echo that the AEC detects is only delayed the acoustic path delay > and whatever processing delay (buffering) the receiver has on its > audio capture and render circuitry. > > So you are correct if you are thinking that the network transport > time and codec delay do not impact the requirements for the AEC. > > There can also be path delay between the receiver output and the > actual speaker. For instance in a video conferencing application, > the video processing in the TV itself can add delay, and the TV will > delay the audio to maintain sync. So if your phone system can be > connected to external sound systems, then that can effect the delays > the AEC has to accommodate. > > Also, in larger rooms the acoustic path delay can be substantial > since sound takes about 100 ms to travel 100 feet (341 meters per > second). It is not clear to me if the CODEC charter includes stereo (not typically used in telephony, but reasonably common in video conferencing); stereo AEC is tougher than mono and I believe that there is some serious IPR in this area. Regards Marshall > > Regards > Stephen Botzko > > On Wed, May 12, 2010 at 4:01 AM, wrote: > Stephen&co, > > > Generally I believe that AECs mainly take care of the acoustic echo > generated in the phone itself (operating on the microphone signal, > acoustic delay up to a few ms). Do you mean that there is additional > processing on the receiving side for the echo returning from the B > user side? > > > Best regards, > > Jari > > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > Behalf Of ext stephen botzko > Sent: 11 May, 2010 21:19 > To: Ben Schwartz > Cc: codec@ietf.org > > > Subject: Re: [codec] Thresholds and delay. > > > >>> > > > In the presence of echo, round-trip delay must be kept below 30 ms to > ensure that the echo is perceived as sidetone, according to the > Springer > handbook of speech processing: > >>> > Though true, I don't think this is a mainstream consideration. > > VOIP phones that are capable of speakerphone operation all have > acoustic echo cancelers, and those cancelers are already tuned to > deal with internet delays with other voice codecs. Certainly our > phones and videoconferencing systems do not have problems with path > delays of this order (hundreds of milliseconds). > > From my own experience (not testing) I agree with Brian's claim that > 500 ms round trip is acceptable for most conversation. > > It does depend on what you are doing, and there are certainly tasks > where much lower delays are needed. > > Regards, > Stephen Botzko > > > On Tue, May 11, 2010 at 2:06 PM, Ben Schwartz > wrote: > > On Tue, 2010-05-11 at 12:48 -0400, Marshall Eubanks wrote: > > As a point of order, I object to any graphs without an available > paper > > behind them. > > I have located the first paper mentioned by Christian Hoene at > http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=81952 > but of course it's paywalled. > > One test in that paper told trained subjects to "Take turns reading > random numbers aloud as fast as possible", on a pair of handsets with > narrowband uncompressed audio and no echo. Subjects were able to > detect > round-trip delays down to 90 ms. Conversational efficiency was > impaired > even with round-trip delay of 100 ms. > > Let me emphasize again that these delays are round-trip, not one-way, > there is no echo, and the task, while designed to expose latency, is > probably less demanding than musical performance. > > In the presence of echo, round-trip delay must be kept below 30 ms to > ensure that the echo is perceived as sidetone, according to the > Springer > handbook of speech processing: > > (http://books.google.com/books?id=Slg10ekZBkAC&lpg=PA83&ots=wc9yM9WrCs&dq=sidetone%20delay%2030%20ms&lr&pg=PA84#v > =onepage&q&f=false) > > Such low delays are clearly impossible on many paths, but for Boston > to > New York City (or London to Paris), ping times can be less than 18 ms, > making echo->sidetone conversion just barely possible for a codec with > 5ms frames. > > I accept Brian Rosen's claim that a slow conversation doesn't normally > suffer greatly from round-trip latencies up to 500 ms, but under some > circumstances much lower latencies are valuable. Let's make sure > they're achievable for those who can use them. > > --Ben > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From stephen.botzko@gmail.com Wed May 12 08:01:35 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19E6A28C28B for ; Wed, 12 May 2010 08:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.465 X-Spam-Level: X-Spam-Status: No, score=-0.465 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0-675VkN9pN for ; Wed, 12 May 2010 08:01:33 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 4E4DA28C2E2 for ; Wed, 12 May 2010 07:48:08 -0700 (PDT) Received: by wwb28 with SMTP id 28so49655wwb.31 for ; Wed, 12 May 2010 07:47:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=0nwi7076IsGuXN5yNopG7wmesX5OIQV3G6DD8atL9Nw=; b=IutZHQQ1kwxEiKXZ8HidMGyj6BPum+GlHi17prNxmk+yD9Aj+dngeZIy9xsEaLtRRH HK5WV6ZCf1y3V6aTbMkSN7dVUHutgz6+l+GHPVT5FS+MLv7IVgw45xU4J5C6xUzVQltp iHDbV+q6B5lcZ8nn2aOnSg6OZjHo4g+tIdMC8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mKiEzjQm7fAziYmzt8Hu/A5re9F4GtwNhMdQPrlTE6HZEHnELtj5B1KIcjmgR2MT3n GbcFlCdxd4LsvpEdUxoKWlgOQ3Ag5gPt0gTZbgdrJKc+8bhQeen+U9GXZjmDoThhkVgD Xsknh1Ig8iP8F/WUjmwtyGEjtqQuWZPYcB7pE= MIME-Version: 1.0 Received: by 10.216.91.80 with SMTP id g58mr1018977wef.181.1273675674860; Wed, 12 May 2010 07:47:54 -0700 (PDT) Received: by 10.216.23.5 with HTTP; Wed, 12 May 2010 07:47:54 -0700 (PDT) In-Reply-To: <1273666982.5250.18.camel@dell-desktop> References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <20100510232234.16632o6l2ecu3wyy@mail.skype.net> <006101caf117$aaf3b2c0$00db1840$@de> <1273595415.1684.33.camel@dell-desktop> <2B114368-93C0-410B-AB66-53CA33E921A8@americafree.tv> <1273601174.1684.79.camel@dell-desktop> <0E94BEEABCAE4C4EAC18B13A7A5C2456529E25A60C@NOK-EUMSG-01.mgdnok.nokia.com> <1273666982.5250.18.camel@dell-desktop> Date: Wed, 12 May 2010 10:47:54 -0400 Message-ID: From: stephen botzko To: Ben Schwartz Content-Type: multipart/alternative; boundary=0016e6d9762628bf93048666ba66 Cc: codec@ietf.org Subject: Re: [codec] Thresholds and delay. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 15:01:35 -0000 --0016e6d9762628bf93048666ba66 Content-Type: text/plain; charset=ISO-8859-1 >>> It also means that the AEC should be retuned depending on the round-trip delay. >>> Jari is (I think) pointing out that this last statement is not true. I agree with Jari's assessment, though I am not sure exactly what you mean by "retuning". The far-end user will perceive the fed-back echo in various ways, and that does depend on the round-trip time. However, the job of the AEC is to remove the echo, so there is no fed-back echo to hear. And the algorithms which remove echo do *not* depend on the round-trip delay to the far end. At least not the good ones. Perhaps more substantively, I do not think this AEC discussion actually matters in this WG context. We are not working on an AEC, we are working on an Internet Codec. Even if (for argumentation purposes) you accept the idea that somehow the AEC needs to be tuned to the round-trip delay, the round-trip delay varies enormously depending on the connection, and this round-trip time in general is not even discoverable (esp. if gateways or SBCs are used). Nothing we are doing in this group will change any of the above. As far as sidetone goes, I do not understand why that keeps coming up either. For the speakerphone use case eliminating AECs from both ends requires two conditions: (a) the round trip delay has to be very low (30 ms or less, from all delay sources) (b) there has to be sufficient attenuation on the loop. The first condition has been brought up repeatedly. For general internet WAN connections it is clearly not met, and it is in fact difficult to meet even on more local connections. The second condition has not been discussed much. But if you do have low delay but do not have enough attenuation, what you get is feedback, and not sidetone. Since users have control over the speaker volume, the second condition (in general) also can not be guaranteed. All speakerphones that I know of are either half-duplex or use AECs. This is true even for PSTN phones used in local-loop circuit-switched calls, which is the lowest delay telephony connection that there is. So for telephony at least, it is clear that AECs are needed. So I do not think continued debate on the value of sidetone is productive. I agree with Michael's comment "achieving low enough latencies for sidetone perception should not be a goal of the wg" Stephen Botzko On Wed, May 12, 2010 at 8:23 AM, Ben Schwartz wrote: > On Wed, 2010-05-12 at 10:01 +0200, jari.hagqvist@nokia.com wrote: > > > > Generally I believe that AECs mainly take care of the acoustic echo > > generated in the phone itself (operating on the microphone signal, > > acoustic delay up to a few ms). Do you mean that there is additional > > processing on the receiving side for the echo returning from the B > > user side? > > Only in the user's head. The psychoacoustics of echo are very different > depending on the echo time. This means that the perceived echo-canceler > fidelity depends on the acoustic round-trip delay. It also means that > the AEC should be retuned depending on the round-trip delay. > > --Ben > > > --0016e6d9762628bf93048666ba66 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
=A0=A0 It also means that the AEC should be retuned dependi= ng on the round-trip delay.
>>>
Jari is (I think) pointing o= ut that this last statement is not true.=A0

I agree with Jari's= assessment, though I am not sure exactly what you mean by "retuning&q= uot;.=A0 The far-end user will perceive the fed-back echo in various ways, = and that does depend on the round-trip time.=A0 However, the job of the AEC= is to remove the echo, so there is no fed-back echo to hear.=A0 And the al= gorithms which remove echo do not depend on the=20 round-trip delay to the far end.=A0 At least not the good ones.

Perhaps more substantively, I do not think this AEC discussion actually= matters in this WG context.=A0 We are not working on an AEC, we are workin= g on an Internet Codec.=A0 Even if (for argumentation purposes) you accept = the idea that somehow the AEC needs to be tuned to the round-trip delay, th= e round-trip delay varies enormously depending on the connection, and this = round-trip time in general is not even discoverable (esp. if gateways or SB= Cs are used).=A0 Nothing we are doing in this group will change any of the = above.
=A0
As far as sidetone goes, I do not understand why that keeps coming u= p either.

For the speakerphone use case eliminating AECs from both e= nds requires two conditions:
(a) the r= ound trip delay has to be very low (30 ms or less, from all delay sources)<= br> (b) there has to be sufficient attenuation on the loop.

The fi= rst condition has been brought up repeatedly.=A0 For general internet WAN c= onnections it is clearly not met, and it is in fact difficult to meet even = on more local connections.

The second condition has not been discussed much.=A0 But if you do have= low delay but do not have enough attenuation, what you get is feedback, an= d not sidetone.=A0 Since users have control over the speaker volume, the se= cond condition (in general) also can not be guaranteed.

All speakerphones that I know of are either half-duplex or use AECs.=A0= This is true even for PSTN phones used in local-loop circuit-switched call= s, which is the lowest delay telephony connection that there is.=A0 So for = telephony at least, it is clear that AECs are needed.

So I do not think continued debate on the value of sidetone is producti= ve.=A0 I agree with Michael's comment "achieving low enough latencies=20 for sidetone perception should not be a goal of the wg"

= Stephen Botzko

On Wed, May 12, 2010 at 8:= 23 AM, Ben Schwartz <bmschwar@fas.harvard.edu> wrote:=
On Wed, 2010= -05-12 at 10:01 +0200, jari.hagqvist@nokia.com wrote:
>
> Generally I believe that AECs mainly take care of the acoustic echo > generated in the phone itself (operating on the microphone signal,
> acoustic delay up to a few ms). Do you mean that there is additional > processing on the receiving side for the echo returning from the B
> user side?

Only in the user's head. =A0The psychoacoustics of echo are very = different
depending on the echo time. =A0This means that the perceived echo-canceler<= br> fidelity depends on the acoustic round-trip delay. =A0It also means that the AEC should be retuned depending on the round-trip delay.

--Ben



--0016e6d9762628bf93048666ba66-- From fluffy@cisco.com Wed May 12 08:12:14 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B951E3A6891 for ; Wed, 12 May 2010 08:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcLCraar3Rft for ; Wed, 12 May 2010 08:12:13 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5E38A3A6CC2 for ; Wed, 12 May 2010 08:00:24 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAItf6ktAZnwM/2dsb2JhbACeLXGhOJlshRIEg0A X-IronPort-AV: E=Sophos;i="4.53,215,1272844800"; d="scan'208";a="110542173" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 12 May 2010 15:00:12 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4CF0B0m004865; Wed, 12 May 2010 15:00:11 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Wed, 12 May 2010 09:00:10 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <07C815A7-8F3C-4F85-A275-4352D0080EEA@cisco.com> References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> To: Raymond (Juin-Hwey) Chen X-Mailer: Apple Mail (2.1078) Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 15:12:14 -0000 On May 4, 2010, at 7:15 PM, Raymond (Juin-Hwey) Chen wrote: > the 3*(codec frame size) delay is very real for IP phone This does not match the measurements I have. And I certainly don't have = 100+ year voip experience but I do have two of the #1 selling enterprise = phones connected to an oscilloscope. Test with other phones suggest most = the major vendors of IP hard phones have fairly comparable performance = when it comes to delay.=20 =20 Cullen= From fluffy@cisco.com Wed May 12 08:19:15 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7217D3A684D for ; Wed, 12 May 2010 08:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.376 X-Spam-Level: X-Spam-Status: No, score=-108.376 tagged_above=-999 required=5 tests=[AWL=-0.977, BAYES_50=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0IUfYa+kWGL for ; Wed, 12 May 2010 08:19:10 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 2E05828C128 for ; Wed, 12 May 2010 08:05:58 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADNh6kurR7Hu/2dsb2JhbACeLXGhP5lsglCCQgSDQA X-IronPort-AV: E=Sophos;i="4.53,215,1272844800"; d="scan'208";a="255428347" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 12 May 2010 15:05:48 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o4CF5lXR007289; Wed, 12 May 2010 15:05:47 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=windows-1252 Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <071.30b67e93d22f0bfedf46b5035d133441@tools.ietf.org> Date: Wed, 12 May 2010 09:05:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1F68067D-33B9-4F0C-B31B-B3A56A72DBA4@cisco.com> References: <062.bc75a3b3c4a980df34535f87c9484935@tools.ietf.org> <071.30b67e93d22f0bfedf46b5035d133441@tools.ietf.org> To: codec@ietf.org X-Mailer: Apple Mail (2.1078) Subject: Re: [codec] #15: Efficiently combine pre-encoded audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 15:19:15 -0000 For conference bridges, it's probably more important to be able to = decide who the active speakers are with low CPU complexity than the = actually act of mixing the the selected speakers. Consider a typical = call with 7 people who might be speakers and the 3 most active are = selected and mixed. In many systems today, most the MIPS goes to = decoding all 7 streams to do speaker detection before the resulting 4 = streams are formed and encoded. If there was a cheap way to figure out = who the active speakers were without doing a full decode of all 7 = streams, that would be sort of nice the for conferences bridges.=20 On May 1, 2010, at 8:24 AM, codec issue tracker wrote: > #15: Efficiently combine pre-encoded audio > = ------------------------------------+-------------------------------------= -- > Reporter: hoene@=85 | Owner: =20 > Type: enhancement | Status: new > Priority: minor | Milestone: =20 > Component: requirements | Version: =20 > Severity: Active WG Document | Keywords: =20 > = ------------------------------------+-------------------------------------= -- >=20 > Comment(by hoene@=85): >=20 > [Colin:] >> [...] conferences implemented using multicast require >> end system mixing of potentially large numbers of active audio >> streams, whereas those implemented using conference bridges do the >> mixing in a single central location, and generally suppress all but >> one speaker. The differences in mixing and the number of simultaneous >> active streams that might be received potentially affect the design = of >> the codec. >=20 > [Raymond]: I would like to take this opportunity to express my view = that > although codec complexity isn=92t much of an issue for PC-to-PC calls = where > there are GHz of processing power available, the codec complexity is = an > important issue in certain application scenarios. The following are = just > some examples. > 1) If a conference bridge has to decode a large number of voice = channels, > mix, and re-encode, and if compressed-domain mixing cannot be done = (which > is usually the case), then it is important to keep the decoder = complexity > low. >=20 > [JM]: The decoder complexity is very important. Not only because of = mixing > issue, but also because the decoder is generally not allowed to take > shortcuts to save on complexity (unlike the encoder). As for = compressed- > domain mixing, as you say it is not always available, but *if* we can = do > it (even if only partially), then that can result in a "free" = reduction in > decoder complexity for mixing. >=20 > [Christian]: Scalable [conferencing] > - Receiver side activity detection for music and voice having = low > complexity (for the conference bridge) > - Efficient mixing of two to four(?) active flows (is this > achievable without the complete process of decoding and encoding = again?) >=20 > --=20 > Ticket URL: = > codec >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Wed May 12 08:24:59 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 454F828C2C6 for ; Wed, 12 May 2010 08:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.935 X-Spam-Level: X-Spam-Status: No, score=-109.935 tagged_above=-999 required=5 tests=[AWL=0.664, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCQA95kNFbVu for ; Wed, 12 May 2010 08:24:55 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id CA9A53A68D6 for ; Wed, 12 May 2010 08:08:55 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADNh6kurR7Ht/2dsb2JhbACeLXGhP5lshRIEg0A X-IronPort-AV: E=Sophos;i="4.53,215,1272844800"; d="scan'208";a="325248663" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 12 May 2010 15:08:45 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4CF8jTq002230; Wed, 12 May 2010 15:08:45 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=windows-1252 Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Wed, 12 May 2010 09:08:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <73686D4E-E010-425F-8982-74B06BD5845D@cisco.com> References: <062.d51439b68d5cdc7daff30cac51ddab04@tools.ietf.org> To: stephen botzko X-Mailer: Apple Mail (2.1078) Cc: codec@ietf.org Subject: Re: [codec] #18: Frame Sizes X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 15:25:00 -0000 +1=20 Also, it seems that people working on maximizing efficient use of the = network might want size much long than 20 ms.=20 On May 1, 2010, at 4:57 AM, stephen botzko wrote: > I'm not sure there ought to be a "SHALL" on this. Obviously it needs = to be reasonably small for low delay. =20 >=20 > However, the possible frame sizes are often driven by the underlying = technology (transform size being one example). If we decided on 10 and = 20 ms for example, would we actually rule out a codec technology that = had to run at 7.5, 15 and 22.5?=20 >=20 > Stephen Botzko >=20 >=20 >=20 > On Sat, May 1, 2010 at 6:45 AM, codec issue tracker = wrote: > #18: Frame Sizes > = ------------------------------------+-------------------------------------= -- > Reporter: hoene@=85 | Owner: > Type: enhancement | Status: new > Priority: major | Milestone: > Component: requirements | Version: > Severity: - | Keywords: > = ------------------------------------+-------------------------------------= -- > Which frame size(s) shall the CODEC support? >=20 > -- > Ticket URL: > codec >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Wed May 12 08:33:29 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C75CB3A6BB6 for ; Wed, 12 May 2010 08:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.216 X-Spam-Level: X-Spam-Status: No, score=-109.216 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RZ6H7bWINwE for ; Wed, 12 May 2010 08:33:28 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6346328C19F for ; Wed, 12 May 2010 08:21:00 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADtk6kurRN+K/2dsb2JhbACeLXGhSJlrhRIEg0A X-IronPort-AV: E=Sophos;i="4.53,215,1272844800"; d="scan'208";a="196550855" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 12 May 2010 15:20:50 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o4CFKn9p029445; Wed, 12 May 2010 15:20:49 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <002e01caefa2$ef88c9a0$ce9a5ce0$@de> Date: Wed, 12 May 2010 09:20:49 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0527FF7A-A0BA-4309-8FF5-A152339F2611@cisco.com> References: <002e01caefa2$ef88c9a0$ce9a5ce0$@de> To: Christian Hoene X-Mailer: Apple Mail (2.1078) Cc: codec@ietf.org Subject: Re: [codec] this weeks summary X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 15:33:29 -0000 On May 9, 2010, at 12:10 PM, Christian Hoene wrote: > Raymond did a great job explaining the special requirements of = high-density VoIP gateway. They are differ substantially to those of > soft-phones (but are somewhat similar to VoIP phones with embedded = CPUs). The requirements include low memory footprint, ultra-low > delay, Uh, can someone walk me through the low delay part? I either missed of = failed to understand that=20 > low complexity and mostly narrow band. But aren't those requirements = already covered by existing codecs? Shall this working > group provide a codec profile for end-to-gateway beside the profile = for an end-to-end codec? Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From br@brianrosen.net Wed May 12 08:36:53 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A4FC28C187 for ; Wed, 12 May 2010 08:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.978 X-Spam-Level: X-Spam-Status: No, score=0.978 tagged_above=-999 required=5 tests=[AWL=-1.353, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_72=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMZgEyR7FQXa for ; Wed, 12 May 2010 08:36:52 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id CB25428C2D4 for ; Wed, 12 May 2010 08:25:34 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.74]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1OCDoC-0006bL-AO; Wed, 12 May 2010 10:25:16 -0500 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Wed, 12 May 2010 11:25:17 -0400 From: Brian Rosen To: Cullen Jennings , Message-ID: Thread-Topic: [codec] #15: Efficiently combine pre-encoded audio Thread-Index: Acrx51NBPNPYs3gITUaVqNolKeFZIg== In-Reply-To: <1F68067D-33B9-4F0C-B31B-B3A56A72DBA4@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Subject: Re: [codec] #15: Efficiently combine pre-encoded audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 15:36:53 -0000 Excellent idea. Been there, never really did it. It's complex. Effectively, you need a distributed adaptive threshold mechanism. However, if you had it, user experience in multispeaker environments gets a win. Brian On 5/12/10 11:05 AM, "Cullen Jennings" wrote: >=20 > For conference bridges, it's probably more important to be able to decide= who > the active speakers are with low CPU complexity than the actually act of > mixing the the selected speakers. Consider a typical call with 7 people w= ho > might be speakers and the 3 most active are selected and mixed. In many > systems today, most the MIPS goes to decoding all 7 streams to do speaker > detection before the resulting 4 streams are formed and encoded. If there= was > a cheap way to figure out who the active speakers were without doing a fu= ll > decode of all 7 streams, that would be sort of nice the for conferences > bridges.=20 >=20 >=20 >=20 >=20 > On May 1, 2010, at 8:24 AM, codec issue tracker wrote: >=20 >> #15: Efficiently combine pre-encoded audio >> ------------------------------------+-----------------------------------= ---- >> Reporter: hoene@=8A | Owner: >> Type: enhancement | Status: new >> Priority: minor | Milestone: >> Component: requirements | Version: >> Severity: Active WG Document | Keywords: >> ------------------------------------+-----------------------------------= ---- >>=20 >> Comment(by hoene@=8A): >>=20 >> [Colin:] >>> [...] conferences implemented using multicast require >>> end system mixing of potentially large numbers of active audio >>> streams, whereas those implemented using conference bridges do the >>> mixing in a single central location, and generally suppress all but >>> one speaker. The differences in mixing and the number of simultaneous >>> active streams that might be received potentially affect the design of >>> the codec. >>=20 >> [Raymond]: I would like to take this opportunity to express my view that >> although codec complexity isn=B9t much of an issue for PC-to-PC calls wher= e >> there are GHz of processing power available, the codec complexity is an >> important issue in certain application scenarios. The following are jus= t >> some examples. >> 1) If a conference bridge has to decode a large number of voice channels= , >> mix, and re-encode, and if compressed-domain mixing cannot be done (whic= h >> is usually the case), then it is important to keep the decoder complexit= y >> low. >>=20 >> [JM]: The decoder complexity is very important. Not only because of mixi= ng >> issue, but also because the decoder is generally not allowed to take >> shortcuts to save on complexity (unlike the encoder). As for compressed- >> domain mixing, as you say it is not always available, but *if* we can do >> it (even if only partially), then that can result in a "free" reduction = in >> decoder complexity for mixing. >>=20 >> [Christian]: Scalable [conferencing] >> - Receiver side activity detection for music and voice having low >> complexity (for the conference bridge) >> - Efficient mixing of two to four(?) active flows (is this >> achievable without the complete process of decoding and encoding again?) >>=20 >> --=20 >> Ticket URL: >> codec >>=20 >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From bmschwar@fas.harvard.edu Wed May 12 08:37:23 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7606A3A6C63 for ; Wed, 12 May 2010 08:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.261 X-Spam-Level: X-Spam-Status: No, score=-4.261 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UngLX139m3TN for ; Wed, 12 May 2010 08:37:21 -0700 (PDT) Received: from us26.unix.fas.harvard.edu (us26.unix.fas.harvard.edu [140.247.35.202]) by core3.amsl.com (Postfix) with ESMTP id 6C40628C2EF for ; Wed, 12 May 2010 08:26:15 -0700 (PDT) Received: from us26.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us26.unix.fas.harvard.edu (Postfix) with ESMTP id ADD621F73C7 for ; Wed, 12 May 2010 11:26:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s=mail; bh= golQHJ9OqDZQsax6pBxECFK2ZKeSgR5Lzlyb2tAs0QE=; b=vrQ1eCthK3Q5BQfY 1EgFvpPlYvDhnqEM1QVnUVAxY9ewwx48gYbVmbLJ/VRGOUjbWC1mZvACLGQUdbgj TqqSvMo2uD3456/wErMW8wCSC7HgfMTL0PrVS2yBnjeuSGfFmmkNKqTOm4Xo30CX zLQkuFlAXR4rWGT1/6a7rCEWkgA= DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; q=dns; s= mail; b=ktb6awjFnK9ENPOy5GovwZf22ZUiKiz+v2SlgRaZtHUQxetD23fd2bpM QiDWBHTECj6VEt+/K39GeImg3LbKHSyDMfjtDSq0XSfPqdneSqVkS9ChmGe5nyMa 5cTPL3EoxZ6eWx2PieIqxdlR3WWODTuAudInq4H36Y+cU48BoAI= Received: from [172.23.141.103] (bwhmaincampuspat25.partners.org [170.223.207.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us26.unix.fas.harvard.edu (Postfix) with ESMTPSA id A12E31F7236 for ; Wed, 12 May 2010 11:26:04 -0400 (EDT) Message-ID: <4BEAC888.50109@fas.harvard.edu> Date: Wed, 12 May 2010 11:26:00 -0400 From: "Benjamin M. Schwartz" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: codec@ietf.org References: <062.bc75a3b3c4a980df34535f87c9484935@tools.ietf.org> <071.30b67e93d22f0bfedf46b5035d133441@tools.ietf.org> <1F68067D-33B9-4F0C-B31B-B3A56A72DBA4@cisco.com> In-Reply-To: <1F68067D-33B9-4F0C-B31B-B3A56A72DBA4@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [codec] #15: Efficiently combine pre-encoded audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bens@alum.mit.edu List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 15:37:23 -0000 On 05/12/2010 11:05 AM, Cullen Jennings wrote: > If there was a cheap way to figure out who the active speakers were without doing a full decode of all 7 streams, that would be sort of nice the for conferences bridges. The cheapest solution, of course, is transmit-side activity detection. Maybe we need to specify a way for a receiver to request that the transmitter employ (or not employ) VAD. --Ben From swmike@swm.pp.se Wed May 12 08:44:37 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 102BB28C125 for ; Wed, 12 May 2010 08:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_50=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kRjJXqVaZt3 for ; Wed, 12 May 2010 08:44:36 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by core3.amsl.com (Postfix) with ESMTP id 431B028C11C for ; Wed, 12 May 2010 08:34:16 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 81330A2; Wed, 12 May 2010 17:34:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 801DF9F for ; Wed, 12 May 2010 17:34:01 +0200 (CEST) Date: Wed, 12 May 2010 17:34:01 +0200 (CEST) From: Mikael Abrahamsson To: codec@ietf.org In-Reply-To: <73686D4E-E010-425F-8982-74B06BD5845D@cisco.com> Message-ID: References: <062.d51439b68d5cdc7daff30cac51ddab04@tools.ietf.org> <73686D4E-E010-425F-8982-74B06BD5845D@cisco.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [codec] #18: Frame Sizes X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 15:44:37 -0000 On Wed, 12 May 2010, Cullen Jennings wrote: > Also, it seems that people working on maximizing efficient use of the > network might want size much long than 20 ms. My blief is that the solution needs to support frame sizes ranging from 5ms up to somewhere around 100-250ms. It might be that internally it's actually only doing 5-20 ms and it's the transport that package it together so that the fps is way down, but I think it still needs to be taken into account when design is done. -- Mikael Abrahamsson email: swmike@swm.pp.se From bmschwar@fas.harvard.edu Wed May 12 08:51:19 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1179D3A68D9 for ; Wed, 12 May 2010 08:51:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.051 X-Spam-Level: X-Spam-Status: No, score=-5.051 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4p24ZpiIZWF for ; Wed, 12 May 2010 08:51:18 -0700 (PDT) Received: from us24.unix.fas.harvard.edu (us24.unix.fas.harvard.edu [140.247.35.204]) by core3.amsl.com (Postfix) with ESMTP id 286C228C224 for ; Wed, 12 May 2010 08:40:33 -0700 (PDT) Received: from us24.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us24.unix.fas.harvard.edu (Postfix) with ESMTP id 8571F46E1D2 for ; Wed, 12 May 2010 11:40:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s=mail; bh= NYN2v10syH0udTBHF8v3sgiTRroZ3+YC8dUmplRUnuo=; b=oX82tMiXsce7Ufe6 CCr297XHDPcE4bXCkwqTu/ItG/HHnuuh2/LwmyGGus8Er+QplSpYBbv7d4MYTDNd sdFgn/3as/NEHcDakJO261iyjI5BGb2j2tI7cG/4PDIFapQmpRahYSarKOr+5eur A+L+pRg2ZCVuq3FCyyKVvqfjZvw= DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; q=dns; s= mail; b=IcQqDvb9D79AeTPT0UkZMX49UsOWJFg0SHPxIuutbmqGwW+MAi5w2KNy B9ngzMQjt5lBNi/C8H+scwUDO70soNR/eOJU3RtuREqZrWJKKgtybiRNEa6fX5pc CH84xcSBdKNELRjm4eUnhjgz9myY7ODid+a/DdZDna/ZdvuXjUM= Received: from [172.23.141.103] (bwhmaincampuspat25.partners.org [170.223.207.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us24.unix.fas.harvard.edu (Postfix) with ESMTPSA id 823E746E1BD for ; Wed, 12 May 2010 11:40:22 -0400 (EDT) Message-ID: <4BEACBE5.2080502@fas.harvard.edu> Date: Wed, 12 May 2010 11:40:21 -0400 From: "Benjamin M. Schwartz" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: codec@ietf.org References: <062.d51439b68d5cdc7daff30cac51ddab04@tools.ietf.org> <73686D4E-E010-425F-8982-74B06BD5845D@cisco.com> In-Reply-To: <73686D4E-E010-425F-8982-74B06BD5845D@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [codec] #18: Frame Sizes X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bens@alum.mit.edu List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 15:51:19 -0000 On 05/12/2010 11:08 AM, Cullen Jennings wrote: > Also, it seems that people working on maximizing efficient use of the network might want size much long than 20 ms. I agree. The CELT RTP encapsulation draft provides, I think, a logical implementation of this, by allowing tight packing of several codec frames into a single RTP packet [1]. --Ben [1] http://tools.ietf.org/html/draft-valin-celt-rtp-profile-01#section-3.3 From mknappe@juniper.net Wed May 12 08:55:35 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D57DA3A6BA7 for ; Wed, 12 May 2010 08:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.616 X-Spam-Level: X-Spam-Status: No, score=-4.616 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuQFo+-vToIu for ; Wed, 12 May 2010 08:55:34 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 7F82B3A6BA1 for ; Wed, 12 May 2010 08:43:57 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKS+rMr3r3E6f/v5nJcqLBGHZKDPcj56D7@postini.com; Wed, 12 May 2010 08:43:47 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 12 May 2010 08:43:36 -0700 From: Michael Knappe To: stephen botzko , Ben Schwartz Date: Wed, 12 May 2010 08:43:30 -0700 Thread-Topic: [codec] Thresholds and delay. Thread-Index: Acrx5ATwcmHgc2YcRr2WZP6vf/NYHQABdnLk Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] Thresholds and delay. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 15:55:35 -0000 WWVzLCBsZXTigJlzIGNsb3NlIG9mZiBvbiB0aGUgQUVDIGFuZCBzaWRldG9uZSBkaXNjdXNzaW9u LCAgbXkgY29tbWVudHMgYWdhaW4gZnJvbSBlYXJsaWVyIGluIHRoaXMgdGhyZWFkOg0KDQoNCkFn cmVlZCB0aGF0IGFjaGlldmluZyBsb3cgZW5vdWdoIGxhdGVuY2llcyBmb3Igc2lkZXRvbmUgcGVy Y2VwdGlvbiBzaG91bGQgbm90IGJlIGEgZ29hbCBvZiB0aGUgd2csIGJ1dCB3ZSBzaG91bGQgYmUg YWltaW5nIGlmIGF0IGFsbCBwb3NzaWJsZSBmb3IgYmV0dGVyIHRoYW4gMjUwIG1zIG9uZS13YXkg ZGVsYXkgaW4gdHlwaWNhbCAoYW5kIG5vbi10YW5kZW1lZCkgZGVwbG95bWVudHMuIFRoZSBrbmVl IG9mIHRoZSBvbmUtd2F5IGRlbGF5IGltcGFpcm1lbnQgZmFjdG9yIGJlZ2lucyByaXNpbmcgbm9u LWxpbmVhcmx5IHNvbWV3aGVyZSBiZXR3ZWVuIDE1MCBhbmQgMjUwIG1zLg0KDQpDaGVlcnMsDQoN Ck1pa2UNCg0KT24gNS8xMi8xMCA3OjQ3IEFNLCAic3RlcGhlbiBib3R6a28iIDxzdGVwaGVuLmJv dHprb0BnbWFpbC5jb20+IHdyb3RlOg0KDQo+Pj4NCiAgIEl0IGFsc28gbWVhbnMgdGhhdCB0aGUg QUVDIHNob3VsZCBiZSByZXR1bmVkIGRlcGVuZGluZyBvbiB0aGUgcm91bmQtdHJpcCBkZWxheS4N Cj4+Pg0KSmFyaSBpcyAoSSB0aGluaykgcG9pbnRpbmcgb3V0IHRoYXQgdGhpcyBsYXN0IHN0YXRl bWVudCBpcyBub3QgdHJ1ZS4NCg0KSSBhZ3JlZSB3aXRoIEphcmkncyBhc3Nlc3NtZW50LCB0aG91 Z2ggSSBhbSBub3Qgc3VyZSBleGFjdGx5IHdoYXQgeW91IG1lYW4gYnkgInJldHVuaW5nIi4gIFRo ZSBmYXItZW5kIHVzZXIgd2lsbCBwZXJjZWl2ZSB0aGUgZmVkLWJhY2sgZWNobyBpbiB2YXJpb3Vz IHdheXMsIGFuZCB0aGF0IGRvZXMgZGVwZW5kIG9uIHRoZSByb3VuZC10cmlwIHRpbWUuICBIb3dl dmVyLCB0aGUgam9iIG9mIHRoZSBBRUMgaXMgdG8gcmVtb3ZlIHRoZSBlY2hvLCBzbyB0aGVyZSBp cyBubyBmZWQtYmFjayBlY2hvIHRvIGhlYXIuICBBbmQgdGhlIGFsZ29yaXRobXMgd2hpY2ggcmVt b3ZlIGVjaG8gZG8gbm90IGRlcGVuZCBvbiB0aGUgcm91bmQtdHJpcCBkZWxheSB0byB0aGUgZmFy IGVuZC4gIEF0IGxlYXN0IG5vdCB0aGUgZ29vZCBvbmVzLg0KDQpQZXJoYXBzIG1vcmUgc3Vic3Rh bnRpdmVseSwgSSBkbyBub3QgdGhpbmsgdGhpcyBBRUMgZGlzY3Vzc2lvbiBhY3R1YWxseSBtYXR0 ZXJzIGluIHRoaXMgV0cgY29udGV4dC4gIFdlIGFyZSBub3Qgd29ya2luZyBvbiBhbiBBRUMsIHdl IGFyZSB3b3JraW5nIG9uIGFuIEludGVybmV0IENvZGVjLiAgRXZlbiBpZiAoZm9yIGFyZ3VtZW50 YXRpb24gcHVycG9zZXMpIHlvdSBhY2NlcHQgdGhlIGlkZWEgdGhhdCBzb21laG93IHRoZSBBRUMg bmVlZHMgdG8gYmUgdHVuZWQgdG8gdGhlIHJvdW5kLXRyaXAgZGVsYXksIHRoZSByb3VuZC10cmlw IGRlbGF5IHZhcmllcyBlbm9ybW91c2x5IGRlcGVuZGluZyBvbiB0aGUgY29ubmVjdGlvbiwgYW5k IHRoaXMgcm91bmQtdHJpcCB0aW1lIGluIGdlbmVyYWwgaXMgbm90IGV2ZW4gZGlzY292ZXJhYmxl IChlc3AuIGlmIGdhdGV3YXlzIG9yIFNCQ3MgYXJlIHVzZWQpLiAgTm90aGluZyB3ZSBhcmUgZG9p bmcgaW4gdGhpcyBncm91cCB3aWxsIGNoYW5nZSBhbnkgb2YgdGhlIGFib3ZlLg0KDQpBcyBmYXIg YXMgc2lkZXRvbmUgZ29lcywgSSBkbyBub3QgdW5kZXJzdGFuZCB3aHkgdGhhdCBrZWVwcyBjb21p bmcgdXAgZWl0aGVyLg0KDQpGb3IgdGhlIHNwZWFrZXJwaG9uZSB1c2UgY2FzZSBlbGltaW5hdGlu ZyBBRUNzIGZyb20gYm90aCBlbmRzIHJlcXVpcmVzIHR3byBjb25kaXRpb25zOg0KKGEpIHRoZSBy b3VuZCB0cmlwIGRlbGF5IGhhcyB0byBiZSB2ZXJ5IGxvdyAoMzAgbXMgb3IgbGVzcywgZnJvbSBh bGwgZGVsYXkgc291cmNlcykNCihiKSB0aGVyZSBoYXMgdG8gYmUgc3VmZmljaWVudCBhdHRlbnVh dGlvbiBvbiB0aGUgbG9vcC4NCg0KVGhlIGZpcnN0IGNvbmRpdGlvbiBoYXMgYmVlbiBicm91Z2h0 IHVwIHJlcGVhdGVkbHkuICBGb3IgZ2VuZXJhbCBpbnRlcm5ldCBXQU4gY29ubmVjdGlvbnMgaXQg aXMgY2xlYXJseSBub3QgbWV0LCBhbmQgaXQgaXMgaW4gZmFjdCBkaWZmaWN1bHQgdG8gbWVldCBl dmVuIG9uIG1vcmUgbG9jYWwgY29ubmVjdGlvbnMuDQoNClRoZSBzZWNvbmQgY29uZGl0aW9uIGhh cyBub3QgYmVlbiBkaXNjdXNzZWQgbXVjaC4gIEJ1dCBpZiB5b3UgZG8gaGF2ZSBsb3cgZGVsYXkg YnV0IGRvIG5vdCBoYXZlIGVub3VnaCBhdHRlbnVhdGlvbiwgd2hhdCB5b3UgZ2V0IGlzIGZlZWRi YWNrLCBhbmQgbm90IHNpZGV0b25lLiAgU2luY2UgdXNlcnMgaGF2ZSBjb250cm9sIG92ZXIgdGhl IHNwZWFrZXIgdm9sdW1lLCB0aGUgc2Vjb25kIGNvbmRpdGlvbiAoaW4gZ2VuZXJhbCkgYWxzbyBj YW4gbm90IGJlIGd1YXJhbnRlZWQuDQoNCkFsbCBzcGVha2VycGhvbmVzIHRoYXQgSSBrbm93IG9m IGFyZSBlaXRoZXIgaGFsZi1kdXBsZXggb3IgdXNlIEFFQ3MuICBUaGlzIGlzIHRydWUgZXZlbiBm b3IgUFNUTiBwaG9uZXMgdXNlZCBpbiBsb2NhbC1sb29wIGNpcmN1aXQtc3dpdGNoZWQgY2FsbHMs IHdoaWNoIGlzIHRoZSBsb3dlc3QgZGVsYXkgdGVsZXBob255IGNvbm5lY3Rpb24gdGhhdCB0aGVy ZSBpcy4gIFNvIGZvciB0ZWxlcGhvbnkgYXQgbGVhc3QsIGl0IGlzIGNsZWFyIHRoYXQgQUVDcyBh cmUgbmVlZGVkLg0KDQpTbyBJIGRvIG5vdCB0aGluayBjb250aW51ZWQgZGViYXRlIG9uIHRoZSB2 YWx1ZSBvZiBzaWRldG9uZSBpcyBwcm9kdWN0aXZlLiAgSSBhZ3JlZSB3aXRoIE1pY2hhZWwncyBj b21tZW50ICJhY2hpZXZpbmcgbG93IGVub3VnaCBsYXRlbmNpZXMgZm9yIHNpZGV0b25lIHBlcmNl cHRpb24gc2hvdWxkIG5vdCBiZSBhIGdvYWwgb2YgdGhlIHdnIg0KDQpTdGVwaGVuIEJvdHprbw0K DQpPbiBXZWQsIE1heSAxMiwgMjAxMCBhdCA4OjIzIEFNLCBCZW4gU2Nod2FydHogPGJtc2Nod2Fy QGZhcy5oYXJ2YXJkLmVkdT4gd3JvdGU6DQpPbiBXZWQsIDIwMTAtMDUtMTIgYXQgMTA6MDEgKzAy MDAsIGphcmkuaGFncXZpc3RAbm9raWEuY29tIHdyb3RlOg0KPg0KPiBHZW5lcmFsbHkgSSBiZWxp ZXZlIHRoYXQgQUVDcyBtYWlubHkgdGFrZSBjYXJlIG9mIHRoZSBhY291c3RpYyBlY2hvDQo+IGdl bmVyYXRlZCBpbiB0aGUgcGhvbmUgaXRzZWxmIChvcGVyYXRpbmcgb24gdGhlIG1pY3JvcGhvbmUg c2lnbmFsLA0KPiBhY291c3RpYyBkZWxheSB1cCB0byBhIGZldyBtcykuIERvIHlvdSBtZWFuIHRo YXQgdGhlcmUgaXMgYWRkaXRpb25hbA0KPiBwcm9jZXNzaW5nIG9uIHRoZSByZWNlaXZpbmcgc2lk ZSBmb3IgdGhlIGVjaG8gcmV0dXJuaW5nIGZyb20gdGhlIEINCj4gdXNlciBzaWRlPw0KDQpPbmx5 IGluIHRoZSB1c2VyJ3MgaGVhZC4gIFRoZSBwc3ljaG9hY291c3RpY3Mgb2YgZWNobyBhcmUgdmVy eSBkaWZmZXJlbnQNCmRlcGVuZGluZyBvbiB0aGUgZWNobyB0aW1lLiAgVGhpcyBtZWFucyB0aGF0 IHRoZSBwZXJjZWl2ZWQgZWNoby1jYW5jZWxlcg0KZmlkZWxpdHkgZGVwZW5kcyBvbiB0aGUgYWNv dXN0aWMgcm91bmQtdHJpcCBkZWxheS4gIEl0IGFsc28gbWVhbnMgdGhhdA0KdGhlIEFFQyBzaG91 bGQgYmUgcmV0dW5lZCBkZXBlbmRpbmcgb24gdGhlIHJvdW5kLXRyaXAgZGVsYXkuDQoNCi0tQmVu DQoNCg0KDQoNCg== From jean-marc.valin@octasic.com Wed May 12 08:56:53 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C98803A6ABC for ; Wed, 12 May 2010 08:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.525 X-Spam-Level: X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8CGPrmLKrsb for ; Wed, 12 May 2010 08:56:53 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id D94BF28C124 for ; Wed, 12 May 2010 08:44:36 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 May 2010 11:44:23 -0400 Message-ID: <4BEACCD7.8080401@octasic.com> Date: Wed, 12 May 2010 11:44:23 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: bens@alum.mit.edu References: <062.bc75a3b3c4a980df34535f87c9484935@tools.ietf.org> <071.30b67e93d22f0bfedf46b5035d133441@tools.ietf.org> <1F68067D-33B9-4F0C-B31B-B3A56A72DBA4@cisco.com> <4BEAC888.50109@fas.harvard.edu> In-Reply-To: <4BEAC888.50109@fas.harvard.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 May 2010 15:44:23.0674 (UTC) FILETIME=[FEB9BDA0:01CAF1E9] Cc: codec@ietf.org Subject: Re: [codec] #15: Efficiently combine pre-encoded audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 15:56:53 -0000 Benjamin M. Schwartz wrote: > The cheapest solution, of course, is transmit-side activity detection. > Maybe we need to specify a way for a receiver to request that the > transmitter employ (or not employ) VAD. I think you can do better than an encoder VAD. All you need to do is make sure that the relevant information you need for a VAD can easily be decoded from the bit-stream without having to do a full decoding. For example, if you're able to easily extract the gain and spectral envelope, you can do a VAD based on that without even having to look at the other parameters in the bit-stream. Jean-Marc From stephen.botzko@gmail.com Wed May 12 08:58:53 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08AB53A6932 for ; Wed, 12 May 2010 08:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLnjBoOGYW0c for ; Wed, 12 May 2010 08:58:51 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id EE2143A690C for ; Wed, 12 May 2010 08:46:03 -0700 (PDT) Received: by wwb28 with SMTP id 28so108315wwb.31 for ; Wed, 12 May 2010 08:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Y9wnSe7Ll29KcGNuN6nBqTmg9regpb3bTwcTO0eoa7s=; b=n7ZZemVllNMLknCEzZPSQzEe46kXBMJT8DZyFtPAdz214L+9mLYH3aRXC0FcIYdj0H R0TxiMZ0KxN4JV5qO9cRqI0vaCiD+s4RayYC7rAtsaHANZt9Fp5z6VqTep0S9SctRldV 5UsGjdD/C2eyWd7P8NvrTWqC20NZ/4Np9ChY0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=inXWKReFtDnO6l5BDuz++L381OYHfn5mR6WzPeRky1oNIh9DNjYQVxwA2dhO5+rhHu 13iI9rBj8PigD3pz7njHYAuhHK9+nOwjg3jt5Na+fnib6evhWVG+ECpnZZMVzjRs/dg6 8d2PRnMvwN2s6sq36BxunuTv9GgDJ9KaGWIS8= MIME-Version: 1.0 Received: by 10.216.87.132 with SMTP id y4mr4217495wee.174.1273679150529; Wed, 12 May 2010 08:45:50 -0700 (PDT) Received: by 10.216.23.5 with HTTP; Wed, 12 May 2010 08:45:50 -0700 (PDT) In-Reply-To: References: <1F68067D-33B9-4F0C-B31B-B3A56A72DBA4@cisco.com> Date: Wed, 12 May 2010 11:45:50 -0400 Message-ID: From: stephen botzko To: Brian Rosen Content-Type: multipart/alternative; boundary=0016e6d99ba7533ca904866789ca Cc: codec@ietf.org Subject: Re: [codec] #15: Efficiently combine pre-encoded audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 15:58:53 -0000 --0016e6d99ba7533ca904866789ca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The adaptive threshold doesn't have to be distributed, as the conference bridge is selecting the highest scores. You do need a consistent way to compute the scores in the endpoints, ideall= y using a method which is not simply energy. I realize the bridge can alternatively generate scores from bitstream information; I am thinking that is equivalent to including a metric in the RTP payload. Stephen Botzko On Wed, May 12, 2010 at 11:25 AM, Brian Rosen wrote: > Excellent idea. Been there, never really did it. It's complex. > Effectively, you need a distributed adaptive threshold mechanism. > > However, if you had it, user experience in multispeaker environments gets= a > win. > > Brian > > > On 5/12/10 11:05 AM, "Cullen Jennings" wrote: > > > > > For conference bridges, it's probably more important to be able to deci= de > who > > the active speakers are with low CPU complexity than the actually act o= f > > mixing the the selected speakers. Consider a typical call with 7 people > who > > might be speakers and the 3 most active are selected and mixed. In man= y > > systems today, most the MIPS goes to decoding all 7 streams to do speak= er > > detection before the resulting 4 streams are formed and encoded. If the= re > was > > a cheap way to figure out who the active speakers were without doing a > full > > decode of all 7 streams, that would be sort of nice the for conferences > > bridges. > > > > > > > > > > On May 1, 2010, at 8:24 AM, codec issue tracker wrote: > > > >> #15: Efficiently combine pre-encoded audio > >> > ------------------------------------+------------------------------------= --- > >> Reporter: hoene@=C5=A0 | Owner: > >> Type: enhancement | Status: new > >> Priority: minor | Milestone: > >> Component: requirements | Version: > >> Severity: Active WG Document | Keywords: > >> > ------------------------------------+------------------------------------= --- > >> > >> Comment(by hoene@=C5=A0): > >> > >> [Colin:] > >>> [...] conferences implemented using multicast require > >>> end system mixing of potentially large numbers of active audio > >>> streams, whereas those implemented using conference bridges do the > >>> mixing in a single central location, and generally suppress all but > >>> one speaker. The differences in mixing and the number of simultaneous > >>> active streams that might be received potentially affect the design o= f > >>> the codec. > >> > >> [Raymond]: I would like to take this opportunity to express my view th= at > >> although codec complexity isn=C2=B9t much of an issue for PC-to-PC cal= ls > where > >> there are GHz of processing power available, the codec complexity is a= n > >> important issue in certain application scenarios. The following are > just > >> some examples. > >> 1) If a conference bridge has to decode a large number of voice > channels, > >> mix, and re-encode, and if compressed-domain mixing cannot be done > (which > >> is usually the case), then it is important to keep the decoder > complexity > >> low. > >> > >> [JM]: The decoder complexity is very important. Not only because of > mixing > >> issue, but also because the decoder is generally not allowed to take > >> shortcuts to save on complexity (unlike the encoder). As for compresse= d- > >> domain mixing, as you say it is not always available, but *if* we can = do > >> it (even if only partially), then that can result in a "free" reductio= n > in > >> decoder complexity for mixing. > >> > >> [Christian]: Scalable [conferencing] > >> - Receiver side activity detection for music and voice having lo= w > >> complexity (for the conference bridge) > >> - Efficient mixing of two to four(?) active flows (is this > >> achievable without the complete process of decoding and encoding again= ?) > >> > >> -- > >> Ticket URL: < > http://trac.tools.ietf.org/wg/codec/trac/ticket/15#comment:1> > >> codec > >> > >> _______________________________________________ > >> codec mailing list > >> codec@ietf.org > >> https://www.ietf.org/mailman/listinfo/codec > > > > > > Cullen Jennings > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > > > _______________________________________________ > > codec mailing list > > codec@ietf.org > > https://www.ietf.org/mailman/listinfo/codec > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016e6d99ba7533ca904866789ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The adaptive threshold doesn't have to be distributed, as the conferenc= e bridge is selecting the highest scores.=C2=A0

You do need a consi= stent way to compute the scores in the endpoints, ideally using a method wh= ich is not simply energy.

I realize the bridge can alternatively generate scores from bitstream i= nformation; I am thinking that is equivalent to including a metric in the R= TP payload.

Stephen Botzko

On Wed,= May 12, 2010 at 11:25 AM, Brian Rosen <br@brianrosen.net> wrote:
Excellent idea. = =C2=A0Been there, never really did it. =C2=A0It's complex.
Effectively, you need a distributed adaptive threshold mechanism.

However, if you had it, user experience in multispeaker environments gets a=
win.

Brian


On 5/12/10 11:05 AM, "Cullen Jennings" <fluffy@cisco.com> wrote:

>
> For conference bridges, it's probably more important to be able to= decide who
> the active speakers are with low CPU complexity than the actually act = of
> mixing the the selected speakers. Consider a typical call with 7 peopl= e who
> might be speakers and =C2=A0the 3 most active are selected and mixed. = In many
> systems today, most the MIPS goes to decoding all 7 streams to do spea= ker
> detection before the resulting 4 streams are formed and encoded. If th= ere was
> a cheap way to figure out who the active speakers were without doing a= full
> decode of all 7 streams, that would be sort of nice the for conference= s
> bridges.
>
>
>
>
> On May 1, 2010, at 8:24 AM, codec issue tracker wrote:
>
>> #15: Efficiently combine pre-encoded audio
>> ------------------------------------+-----------------------------= ----------
>> Reporter: =C2=A0hoene@=C5=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 Owner:
>> =C2=A0 =C2=A0 Type: =C2=A0enhancement =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0Status: =C2=A0new
>> Priority: =C2=A0minor =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | =C2=A0 Milestone:
>> Component: =C2=A0requirements =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0| =C2=A0 =C2=A0 Version:
>> Severity: =C2=A0Active WG Document =C2=A0 =C2=A0 =C2=A0| =C2=A0 = =C2=A0Keywords:
>> ------------------------------------+-----------------------------= ----------
>>
>> Comment(by hoene@=C5=A0):
>>
>> [Colin:]
>>> [...] conferences implemented using multicast require
>>> end system mixing of potentially large numbers of active audio=
>>> streams, whereas those implemented using conference bridges do= the
>>> mixing in a single central location, and generally suppress al= l but
>>> one speaker. The differences in mixing and the number of simul= taneous
>>> active streams that might be received potentially affect the d= esign of
>>> the codec.
>>
>> [Raymond]: I would like to take this opportunity to express my vie= w that
>> although codec complexity isn=C2=B9t much of an issue for PC-to-PC= calls where
>> there are GHz of processing power available, the codec complexity = is an
>> important issue in certain application scenarios. =C2=A0The follow= ing are just
>> some examples.
>> 1) If a conference bridge has to decode a large number of voice ch= annels,
>> mix, and re-encode, and if compressed-domain mixing cannot be done= (which
>> is usually the case), then it is important to keep the decoder com= plexity
>> low.
>>
>> [JM]: The decoder complexity is very important. Not only because o= f mixing
>> issue, but also because the decoder is generally not allowed to ta= ke
>> shortcuts to save on complexity (unlike the encoder). As for compr= essed-
>> domain mixing, as you say it is not always available, but *if* we = can do
>> it (even if only partially), then that can result in a "free&= quot; reduction in
>> decoder complexity for mixing.
>>
>> [Christian]: Scalable [conferencing]
>> - =C2=A0 =C2=A0 =C2=A0 Receiver side activity detection for music = and voice having low
>> complexity (for the conference bridge)
>> - =C2=A0 =C2=A0 =C2=A0 Efficient mixing of two to four(?) active f= lows (is this
>> achievable without the complete process of decoding and encoding a= gain?)
>>
>> --
>> Ticket URL: <http://trac.tools.ietf.org/wg/code= c/trac/ticket/15#comment:1>
>> codec <http://tools.ietf.org/codec/>
>>
>> _______________________________________________
>> codec mailing list
>> codec@ietf.org
>> https://www.ietf.org/mailman/listinfo/codec
>
>
> Cullen Jennings
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/le= gal/cri/index.html
>
>
>
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec


_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--0016e6d99ba7533ca904866789ca-- From bmschwar@fas.harvard.edu Wed May 12 09:06:51 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9E6328C223 for ; Wed, 12 May 2010 09:06:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.206 X-Spam-Level: X-Spam-Status: No, score=-5.206 tagged_above=-999 required=5 tests=[AWL=0.774, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrKBPXGd3oKK for ; Wed, 12 May 2010 09:06:45 -0700 (PDT) Received: from us12.unix.fas.harvard.edu (us12.unix.fas.harvard.edu [140.247.35.203]) by core3.amsl.com (Postfix) with ESMTP id BE3343A6939 for ; Wed, 12 May 2010 08:52:43 -0700 (PDT) Received: from us12.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us12.unix.fas.harvard.edu (Postfix) with ESMTP id 28EF4665348; Wed, 12 May 2010 11:52:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; s=mail; bh=h0O0364HRFI4yNPvg3rHjg7JJHcAExI26roYReI+t/U=; b=U1XA IzygHk91QjYE7lyIlSoQtzNQkl9aWKNK4sjQd+02G+9I6PkcpURRYVciv8dWGjkc zrDiAaYq4VE279XunumKtifYgVgdIo7JNgql81bMKuW3IxEWpKDpVWzNDTapTfSW kaQTT7dy9mP2HnUX0vhAPSM3TG8UC+VHmq9BGtI= DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; q=dns; s=mail; b=g+odrbvO/7is6RPVZkZRxWEIMJAEB9ehjF4eF6Ft+DTKpb bbGTm3yzrB8Uba2Qq3rwtn/TKqTQnv+EOfgZhB3M5N7DiQZRpKynSPCKTYVtJ8Is Ooi9UddBKQdhYj7TMw67fopKLmKsahHHJ/10sEN3E+LPzVc4+S5dF5ecalLD0= Received: from [172.23.141.103] (bwhmaincampuspat25.partners.org [170.223.207.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us12.unix.fas.harvard.edu (Postfix) with ESMTPSA id 232936652F8; Wed, 12 May 2010 11:52:33 -0400 (EDT) Message-ID: <4BEACEBF.7080403@fas.harvard.edu> Date: Wed, 12 May 2010 11:52:31 -0400 From: "Benjamin M. Schwartz" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jean-Marc Valin References: <062.bc75a3b3c4a980df34535f87c9484935@tools.ietf.org> <071.30b67e93d22f0bfedf46b5035d133441@tools.ietf.org> <1F68067D-33B9-4F0C-B31B-B3A56A72DBA4@cisco.com> <4BEAC888.50109@fas.harvard.edu> <4BEACCD7.8080401@octasic.com> In-Reply-To: <4BEACCD7.8080401@octasic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] #15: Efficiently combine pre-encoded audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bens@alum.mit.edu List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 16:06:51 -0000 On 05/12/2010 11:44 AM, Jean-Marc Valin wrote: > Benjamin M. Schwartz wrote: >> The cheapest solution, of course, is transmit-side activity detection. >> Maybe we need to specify a way for a receiver to request that the >> transmitter employ (or not employ) VAD. > > I think you can do better than an encoder VAD. I know that CELT makes decoder VAD very efficient, but how is decoder VAD better than encoder VAD? Encoder VAD saves even more CPU, saves bandwidth, and enables easier jitter buffering. Are you thinking about some sort of adaptive thresholding that requires knowing all streams' volume levels? Anyway, VAD can run on both encode and decode sides at the same time. --Ben From mknappe@juniper.net Wed May 12 09:10:59 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59DC628C32E for ; Wed, 12 May 2010 09:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.586 X-Spam-Level: X-Spam-Status: No, score=-4.586 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8lZaOvzwFlb for ; Wed, 12 May 2010 09:10:56 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 8DD403A6D03 for ; Wed, 12 May 2010 08:55:26 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKS+rPYaJ9G6+QTzUXf6XcFxY9b0rBmA4W@postini.com; Wed, 12 May 2010 08:55:16 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Wed, 12 May 2010 08:54:27 -0700 From: Michael Knappe To: Mikael Abrahamsson , "codec@ietf.org" Date: Wed, 12 May 2010 08:54:24 -0700 Thread-Topic: [codec] #18: Frame Sizes Thread-Index: Acrx6gKOYifXgAkTREOMXwtBnC0voAAAWH/n Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] #18: Frame Sizes X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 16:10:59 -0000 Mikael, Why would you need frame sizes approaching 250 ms? This would no longer be supporting two-way communications in a human interactive sense. Mike On 5/12/10 8:34 AM, "Mikael Abrahamsson" wrote: > On Wed, 12 May 2010, Cullen Jennings wrote: >=20 >> Also, it seems that people working on maximizing efficient use of the >> network might want size much long than 20 ms. >=20 > My blief is that the solution needs to support frame sizes ranging from > 5ms up to somewhere around 100-250ms. It might be that internally it's > actually only doing 5-20 ms and it's the transport that package it > together so that the fps is way down, but I think it still needs to be > taken into account when design is done. From stephen.botzko@gmail.com Wed May 12 09:20:34 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19EE928C163 for ; Wed, 12 May 2010 09:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.961 X-Spam-Level: X-Spam-Status: No, score=-0.961 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9O31R5fjTmGU for ; Wed, 12 May 2010 09:20:31 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 56DCC28C320 for ; Wed, 12 May 2010 09:01:33 -0700 (PDT) Received: by wyb36 with SMTP id 36so159134wyb.31 for ; Wed, 12 May 2010 09:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=/NjalqnPGHw6Q0WbtGVhiS/6+HfLKeSMsz194DrUVsM=; b=qsyU/41GQCqci3muMyHh4LZk83VNDiUXqgLAQaIPSRFV7qddAATA+EdFEgGnDEw3b+ idiHSZOZ3iCfcRQ9H/Rd7m0rSvP6N7Vk86nKZ1dvrFTAJn1j8zP4uz0K5bzAN/hFrT3u m29ZC6yVkHuZWA/xKw0QO+2c6RHkHNeMcCQyY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Q272C/G8EvMHwuUmlzg+bL2gI1ZN/wno0vHjK7jSgr7NfuHZ7cw5k/75FF7VDS6HmR BqcP0LQciBRL81M/LW2qZJYE9NY8pwBwmWxvnSvlpSdL4ChR8AKHDMBjx9GAjW+GeWxl g3am/oROe9kA7bABKyXZmdpbF+dlUMrTtKF14= MIME-Version: 1.0 Received: by 10.216.186.16 with SMTP id v16mr4723444wem.133.1273680079391; Wed, 12 May 2010 09:01:19 -0700 (PDT) Received: by 10.216.23.5 with HTTP; Wed, 12 May 2010 09:01:19 -0700 (PDT) In-Reply-To: <4BEACCD7.8080401@octasic.com> References: <062.bc75a3b3c4a980df34535f87c9484935@tools.ietf.org> <071.30b67e93d22f0bfedf46b5035d133441@tools.ietf.org> <1F68067D-33B9-4F0C-B31B-B3A56A72DBA4@cisco.com> <4BEAC888.50109@fas.harvard.edu> <4BEACCD7.8080401@octasic.com> Date: Wed, 12 May 2010 12:01:19 -0400 Message-ID: From: stephen botzko To: Jean-Marc Valin Content-Type: multipart/alternative; boundary=0016364267a5b08ed3048667c01d Cc: bens@alum.mit.edu, codec@ietf.org Subject: Re: [codec] #15: Efficiently combine pre-encoded audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 16:20:34 -0000 --0016364267a5b08ed3048667c01d Content-Type: text/plain; charset=ISO-8859-1 It might be valuable to be able to obtain the VAD without having to decrypt the bitstream, since that also can become a problem as the number of streams grows. There is a security consideration (traffic analysis), however, it still might be worth thinking about. Stephen Botzko On Wed, May 12, 2010 at 11:44 AM, Jean-Marc Valin < jean-marc.valin@octasic.com> wrote: > Benjamin M. Schwartz wrote: > >> The cheapest solution, of course, is transmit-side activity detection. >> Maybe we need to specify a way for a receiver to request that the >> transmitter employ (or not employ) VAD. >> > > I think you can do better than an encoder VAD. All you need to do is make > sure that the relevant information you need for a VAD can easily be decoded > from the bit-stream without having to do a full decoding. For example, if > you're able to easily extract the gain and spectral envelope, you can do a > VAD based on that without even having to look at the other parameters in the > bit-stream. > > Jean-Marc > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016364267a5b08ed3048667c01d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It might be valuable to be able to obtain the VAD without having to decrypt= the bitstream, since that also can become a problem as the number of strea= ms grows.

There is a security consideration (traffic analysis), howe= ver, it still might be worth thinking about.

Stephen Botzko

On Wed, May 12, 2010 a= t 11:44 AM, Jean-Marc Valin <jean-marc.valin@octasic.com> wrote:
=
Benjamin M. Schwartz wrote:
The cheapest solution, of course, is transmit-side activity detection.
Maybe we need to specify a way for a receiver to request that the
transmitter employ (or not employ) VAD.

I think you can do better than an encoder VAD. All you need to do is make s= ure that the relevant information you need for a VAD can easily be decoded = from the bit-stream without having to do a full decoding. For example, if y= ou're able to easily extract the gain and spectral envelope, you can do= a VAD based on that without even having to look at the other parameters in= the bit-stream.

=A0 =A0 =A0 =A0Jean-Marc

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--0016364267a5b08ed3048667c01d-- From jean-marc.valin@octasic.com Wed May 12 09:23:26 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FA4428C1B1 for ; Wed, 12 May 2010 09:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.347 X-Spam-Level: X-Spam-Status: No, score=-0.347 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0NzAS9c0TZe for ; Wed, 12 May 2010 09:23:25 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 7449228C1B2 for ; Wed, 12 May 2010 09:03:30 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 May 2010 12:03:20 -0400 Message-ID: <4BEAD147.8080307@octasic.com> Date: Wed, 12 May 2010 12:03:19 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: bens@alum.mit.edu References: <062.bc75a3b3c4a980df34535f87c9484935@tools.ietf.org> <071.30b67e93d22f0bfedf46b5035d133441@tools.ietf.org> <1F68067D-33B9-4F0C-B31B-B3A56A72DBA4@cisco.com> <4BEAC888.50109@fas.harvard.edu> <4BEACCD7.8080401@octasic.com> <4BEACEBF.7080403@fas.harvard.edu> In-Reply-To: <4BEACEBF.7080403@fas.harvard.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 May 2010 16:03:20.0182 (UTC) FILETIME=[A4231960:01CAF1EC] Cc: codec@ietf.org Subject: Re: [codec] #15: Efficiently combine pre-encoded audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 16:23:26 -0000 Benjamin M. Schwartz wrote: >> I think you can do better than an encoder VAD. > > I know that CELT makes decoder VAD very efficient, Not only CELT. You can do that with an LPC-based codec too. > but how is decoder VAD > better than encoder VAD? Encoder VAD saves even more CPU, saves > bandwidth, and enables easier jitter buffering. There's a few reasons why I think decoder-side is better: - The decision for an encoder-size VAD would take some amount of space in the bit-stream - If we make an encode-size VAD mandatory, then all encoders will have to spend the CPU cycles, even when it's not needed. If it's not mandatory, then the decoder cannot rely on it, so it still needs to implement a VAD - A decoder VAD does not need to be specified in an exact way, so implementers can choose different implementations depending on that information they need. - You cannot "game" a decode-size VAD. > Are you thinking about some sort of adaptive thresholding that requires > knowing all streams' volume levels? Well, knowing the relative amplitudes of each stream can allow you to take more intelligent decisions, e.g. when you have to choose the "most active speaker". That's something you can't really get from an encoder VAD. > Anyway, VAD can run on both encode and decode sides at the same time. That would just mean nobody would bother implementing the encode side. Jean-Marc From mknappe@juniper.net Wed May 12 09:25:26 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DC8628C170 for ; Wed, 12 May 2010 09:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.982 X-Spam-Level: X-Spam-Status: No, score=-4.982 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEU3TIQWqLjn for ; Wed, 12 May 2010 09:25:25 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id D8BE128C1D1 for ; Wed, 12 May 2010 09:04:59 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKS+rRoVZ7KGfnORsTo45oW4S1rXIxl9I4@postini.com; Wed, 12 May 2010 09:04:50 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 12 May 2010 09:01:33 -0700 From: Michael Knappe To: "bens@alum.mit.edu" , "codec@ietf.org" Date: Wed, 12 May 2010 09:01:29 -0700 Thread-Topic: [codec] #18: Frame Sizes Thread-Index: Acrx6vJ0hWP3m0U7Q/e/TuP/14yxOgAAW9pz Message-ID: In-Reply-To: <4BEACBE5.2080502@fas.harvard.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] #18: Frame Sizes X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 16:25:26 -0000 Yes, the option and decision to pack multiple frames into an RTP packet should be up to the implementer of an overall voice system, and should also be supported by the receiving jitter buffer mechanism, whether or not that receiving jitter buffer is part and parcel of the defined codec. Many voice systems today already support this, for instance it is typical for many of today's VoIP gateway solutions to pack two G.729A frames into each RTP packet. Mike=20 On 5/12/10 8:40 AM, "Benjamin M. Schwartz" wrote= : > On 05/12/2010 11:08 AM, Cullen Jennings wrote: >> Also, it seems that people working on maximizing efficient use of the ne= twork >> might want size much long than 20 ms. >=20 > I agree. The CELT RTP encapsulation draft provides, I think, a logical > implementation of this, by allowing tight packing of several codec frames > into a single RTP packet [1]. >=20 > --Ben >=20 > [1] http://tools.ietf.org/html/draft-valin-celt-rtp-profile-01#section-3.= 3 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From bmschwar@fas.harvard.edu Wed May 12 09:40:58 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 992F03A6CF8 for ; Wed, 12 May 2010 09:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.387 X-Spam-Level: X-Spam-Status: No, score=-4.387 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOknxkR5Y0dp for ; Wed, 12 May 2010 09:40:57 -0700 (PDT) Received: from us12.unix.fas.harvard.edu (us12.unix.fas.harvard.edu [140.247.35.203]) by core3.amsl.com (Postfix) with ESMTP id 5795928C178 for ; Wed, 12 May 2010 09:22:36 -0700 (PDT) Received: from us12.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us12.unix.fas.harvard.edu (Postfix) with ESMTP id CA2B96652BD; Wed, 12 May 2010 12:22:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; s=mail; bh= WOw4pc2QQjzZPZhsQPf5Ef79PhxUoerxmksmex5I9JA=; b=n56NfKWGZ3vvcfaY FmqWtQkd5OvkrhXRw5RXsqsJRmz3QLf3mBs22C0+UXZ2o1kVYc4a6+hiu26krcWJ 0q9swZwt0dHUwfPUKnXT/rqSZvLjgATXH198MSAEwRRH0maBTZtajtRWIass0bND vcJjdLQbmJNd0MJn/80FH/nBBnU= DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; q=dns; s= mail; b=M2PA8fyZoi++wKar4XyEg/Drvaxelf3S1mc9CBZwfUTnciyeWicqEsTe by2bqjMWM92TM+jLOW2kVSaHlXC6bsENWwvQ04B02v+HzFGw/zpp5AEAZp/XN4kl 7i407skYJnijaqGyFxcaju4dkCVL8wO9G7/hU6OtE6+dUKW4pD4= Received: from [172.23.141.103] (bwhmaincampuspat25.partners.org [170.223.207.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us12.unix.fas.harvard.edu (Postfix) with ESMTPSA id C3E26665221; Wed, 12 May 2010 12:22:25 -0400 (EDT) Message-ID: <4BEAD5C1.4000802@fas.harvard.edu> Date: Wed, 12 May 2010 12:22:25 -0400 From: "Benjamin M. Schwartz" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jean-Marc Valin , codec@ietf.org References: <062.bc75a3b3c4a980df34535f87c9484935@tools.ietf.org> <071.30b67e93d22f0bfedf46b5035d133441@tools.ietf.org> <1F68067D-33B9-4F0C-B31B-B3A56A72DBA4@cisco.com> <4BEAC888.50109@fas.harvard.edu> <4BEACCD7.8080401@octasic.com> <4BEACEBF.7080403@fas.harvard.edu> <4BEAD147.8080307@octasic.com> In-Reply-To: <4BEAD147.8080307@octasic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [codec] #15: Efficiently combine pre-encoded audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bens@alum.mit.edu List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 16:40:58 -0000 On 05/12/2010 12:03 PM, Jean-Marc Valin wrote: > Benjamin M. Schwartz wrote: >> but how is decoder VAD >> better than encoder VAD? Encoder VAD saves even more CPU, saves >> bandwidth, and enables easier jitter buffering. > > There's a few reasons why I think decoder-side is better: > - The decision for an encoder-size VAD would take some amount of space > in the bit-stream I think I failed to communicate that by VAD I mean _not sending packets_ during inactivity. For the packets that are sent, the overhead should average much less than 1 bit per frame. I'm not suggesting sending 200 packets a second containing a flag indicating no voice activity, followed by carefully coded background noise. That would be silly. > - If we make an encode-size VAD mandatory, then all encoders will have > to spend the CPU cycles, even when it's not needed. If it's not > mandatory, then the decoder cannot rely on it, so it still needs to > implement a VAD I don't see this as "mandatory". The encoder can turn off VAD, and probably should for full-quality applications. > - A decoder VAD does not need to be specified in an exact way, so > implementers can choose different implementations depending on that > information they need. The only thing that needs exact specification is the signalling. The encoder may use it or not use it as it pleases. > - You cannot "game" a decode-size VAD. I don't know what this means. >> Are you thinking about some sort of adaptive thresholding that requires >> knowing all streams' volume levels? > > Well, knowing the relative amplitudes of each stream can allow you to > take more intelligent decisions, e.g. when you have to choose the "most > active speaker". That's something you can't really get from an encoder VAD. > >> Anyway, VAD can run on both encode and decode sides at the same time. > > That would just mean nobody would bother implementing the encode side. I expect encode-side VAD on a conference call to save more than a factor of 2 in bandwidth, which makes it very desirable, especially for large deployments. People will use it to save bandwidth (especially if it's on by default in the reference implementation). The decode-side CPU savings are just a minor bonus side-effect. --Ben From jean-marc.valin@octasic.com Wed May 12 09:56:02 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B308828C3E7 for ; Wed, 12 May 2010 09:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.371 X-Spam-Level: X-Spam-Status: No, score=-0.371 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmWq2a3EMWpg for ; Wed, 12 May 2010 09:56:02 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 325783A6D84 for ; Wed, 12 May 2010 09:38:05 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 May 2010 12:37:55 -0400 Message-ID: <4BEAD963.4010300@octasic.com> Date: Wed, 12 May 2010 12:37:55 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: bens@alum.mit.edu References: <062.bc75a3b3c4a980df34535f87c9484935@tools.ietf.org> <071.30b67e93d22f0bfedf46b5035d133441@tools.ietf.org> <1F68067D-33B9-4F0C-B31B-B3A56A72DBA4@cisco.com> <4BEAC888.50109@fas.harvard.edu> <4BEACCD7.8080401@octasic.com> <4BEACEBF.7080403@fas.harvard.edu> <4BEAD147.8080307@octasic.com> <4BEAD5C1.4000802@fas.harvard.edu> In-Reply-To: <4BEAD5C1.4000802@fas.harvard.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 May 2010 16:37:55.0744 (UTC) FILETIME=[7944BA00:01CAF1F1] Cc: codec@ietf.org Subject: Re: [codec] #15: Efficiently combine pre-encoded audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 16:56:02 -0000 Benjamin M. Schwartz wrote: > I think I failed to communicate that by VAD I mean _not sending packets_ > during inactivity. For the packets that are sent, the overhead should > average much less than 1 bit per frame. What you're describing is called DTX (discontinuous transmission). This can be useful feature, but it's very different from what we were originally talking about in terms of conference mixing. Jean-Marc From bmschwar@fas.harvard.edu Wed May 12 10:02:33 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10DB13A6D08 for ; Wed, 12 May 2010 10:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.283 X-Spam-Level: X-Spam-Status: No, score=-5.283 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvx5ADbo87UN for ; Wed, 12 May 2010 10:02:32 -0700 (PDT) Received: from us12.unix.fas.harvard.edu (us12.unix.fas.harvard.edu [140.247.35.203]) by core3.amsl.com (Postfix) with ESMTP id 4F95728C1EA for ; Wed, 12 May 2010 09:44:08 -0700 (PDT) Received: from us12.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us12.unix.fas.harvard.edu (Postfix) with ESMTP id EA164665269; Wed, 12 May 2010 12:43:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; s=mail; bh=E0dGisNq4u7rUj7TacP0PO02WugxTAd00Sik9Xx50jo=; b=OBVj eDCW8bdFfRhuSk+Pmg2ZVg3Ki5EkkV5H4WgN4hLYx2Fvrk20htZDc3QMlzdBc27J KrffOeUdfj3VTvdbJOB6qOjXfBQnLY5BF94cKPwpj9Tnfd0UBthjM62/XQjLPUNN jXxYBhSgbCsQJVHNhFmZro+tD/uSxUgE0m3xJlc= DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; q=dns; s=mail; b=WEaJs2ksL7U89GoY1wX7qwXldVXqVO7IzYlrZ4ki+OCWIs +BWVY61lqkeIyUyQQOqod3hUp/gnVVZoPAApSQumoaA1D0JPDCjh32h9wUc6LSYG eCJTHEetFvdFQ17Z7AKab0PxrKWmfqL0T9m1KcluwgDo9iuHniJMRIxcSkNkM= Received: from [172.23.141.103] (bwhmaincampuspat25.partners.org [170.223.207.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us12.unix.fas.harvard.edu (Postfix) with ESMTPSA id E1DDE664FAB; Wed, 12 May 2010 12:43:57 -0400 (EDT) Message-ID: <4BEADACD.4080609@fas.harvard.edu> Date: Wed, 12 May 2010 12:43:57 -0400 From: "Benjamin M. Schwartz" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jean-Marc Valin References: <062.bc75a3b3c4a980df34535f87c9484935@tools.ietf.org> <071.30b67e93d22f0bfedf46b5035d133441@tools.ietf.org> <1F68067D-33B9-4F0C-B31B-B3A56A72DBA4@cisco.com> <4BEAC888.50109@fas.harvard.edu> <4BEACCD7.8080401@octasic.com> <4BEACEBF.7080403@fas.harvard.edu> <4BEAD147.8080307@octasic.com> <4BEAD5C1.4000802@fas.harvard.edu> <4BEAD963.4010300@octasic.com> In-Reply-To: <4BEAD963.4010300@octasic.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] #15: Efficiently combine pre-encoded audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bens@alum.mit.edu List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 17:02:33 -0000 On 05/12/2010 12:37 PM, Jean-Marc Valin wrote: > Benjamin M. Schwartz wrote: >> I think I failed to communicate that by VAD I mean _not sending packets_ >> during inactivity. For the packets that are sent, the overhead should >> average much less than 1 bit per frame. > > What you're describing is called DTX (discontinuous transmission). Oops. Right. What I'm trying to say is that DTX, based on encoder-side VAD, also greatly reduces the (average) computational burden on a conference mixer. Of course, if everyone's really talking at once then VAD can't help. --Ben From roman@telurix.com Wed May 12 11:38:45 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F29F3A6CB2 for ; Wed, 12 May 2010 11:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xULM3Of4OXth for ; Wed, 12 May 2010 11:38:44 -0700 (PDT) Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.211.173]) by core3.amsl.com (Postfix) with ESMTP id 9ECF23A6CD4 for ; Wed, 12 May 2010 11:12:19 -0700 (PDT) Received: by ywh3 with SMTP id 3so146920ywh.31 for ; Wed, 12 May 2010 11:12:06 -0700 (PDT) Received: by 10.101.210.25 with SMTP id m25mr4980105anq.265.1273687926596; Wed, 12 May 2010 11:12:06 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by mx.google.com with ESMTPS id n18sm1059703anl.12.2010.05.12.11.12.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 12 May 2010 11:12:05 -0700 (PDT) Received: by gwb19 with SMTP id 19so179604gwb.31 for ; Wed, 12 May 2010 11:12:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.128.41 with SMTP id a41mr11890032ybd.177.1273687924115; Wed, 12 May 2010 11:12:04 -0700 (PDT) Received: by 10.150.186.7 with HTTP; Wed, 12 May 2010 11:12:04 -0700 (PDT) In-Reply-To: <4BEADACD.4080609@fas.harvard.edu> References: <062.bc75a3b3c4a980df34535f87c9484935@tools.ietf.org> <071.30b67e93d22f0bfedf46b5035d133441@tools.ietf.org> <1F68067D-33B9-4F0C-B31B-B3A56A72DBA4@cisco.com> <4BEAC888.50109@fas.harvard.edu> <4BEACCD7.8080401@octasic.com> <4BEACEBF.7080403@fas.harvard.edu> <4BEAD147.8080307@octasic.com> <4BEAD5C1.4000802@fas.harvard.edu> <4BEAD963.4010300@octasic.com> <4BEADACD.4080609@fas.harvard.edu> Date: Wed, 12 May 2010 14:12:04 -0400 Message-ID: From: Roman Shpount To: bens@alum.mit.edu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: codec@ietf.org Subject: Re: [codec] #15: Efficiently combine pre-encoded audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 18:38:45 -0000 There is one more application to efficiently combining pre-encoded audio: playing announcements or recorded audio. Standard network or IVR announcements can be encoded once and efficiently inserted or combined into audio stream. If pre-encoded audio is supported and the client supports AVT tones, it is trivial to develop a very efficient IVR server which does not require any CODEC encoding or decoding. Efficient decoder side VAD is also very helpful in case of speech recognition, where it allows to save cycles in end-pointer. This way audio only needs to be decoded and passed to the speech recognition system only when voice is present. Bottom line, if we have both efficient decoder side VAD and combining pre-encoded audio we can develop some very efficient VXML servers, voice mail and IVR system, not just conferencing servers. _____________________________ Roman Shpount - www.telurix.com On Wed, May 12, 2010 at 12:43 PM, Benjamin M. Schwartz wrote: > On 05/12/2010 12:37 PM, Jean-Marc Valin wrote: >> >> Benjamin M. Schwartz wrote: >>> >>> I think I failed to communicate that by VAD I mean _not sending packets= _ >>> during inactivity. For the packets that are sent, the overhead should >>> average much less than 1 bit per frame. >> >> What you're describing is called DTX (discontinuous transmission). > > Oops. Right. =A0What I'm trying to say is that DTX, based on encoder-side= VAD, > also greatly reduces the (average) computational burden on a conference > mixer. =A0Of course, if everyone's really talking at once then VAD can't = help. > > --Ben > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From rchen@broadcom.com Wed May 12 11:48:53 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35A7A3A6B78 for ; Wed, 12 May 2010 11:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.038 X-Spam-Level: * X-Spam-Status: No, score=1.038 tagged_above=-999 required=5 tests=[AWL=-1.263, BAYES_50=0.001, MANGLED_WRLDWD=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2rBKiEC52fg for ; Wed, 12 May 2010 11:48:52 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id C155328C2B5 for ; Wed, 12 May 2010 11:28:58 -0700 (PDT) Received: from [10.9.200.131] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 12 May 2010 11:28:39 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Wed, 12 May 2010 11:28:39 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Cullen Jennings" Date: Wed, 12 May 2010 11:28:37 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: Acrx49plujeniwH8SDWDM1aXftrgHwAGhC9g Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <07C815A7-8F3C-4F85-A275-4352D0080EEA@cisco.com> In-Reply-To: <07C815A7-8F3C-4F85-A275-4352D0080EEA@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67F42CDD31G123459208-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 18:48:53 -0000 Hi Cullen, Hmm... That's interesting. Would you please share more details of=20 your measurement equipment setup, the codec used, the codec frame=20 size, the number of codec frames in each packet, the way you=20 measured the delay, and the measured delay value, etc.? =20 I didn't come up with this 3*(codec frame size) delay number for IP=20 phones myself. A very senior technical lead in Broadcom's IP phone=20 chips group told me that, and Broadcom is currently the #1 world- wide market share leader in IP phone chips, accounting for more than=20 half of the world's IP phone chip shipments. Most of the world's=20 tier-1 IP phone manufacturers use our IP phone chips at least in=20 some of their product lines. I would be very interested to learn more about your measurements to=20 try to reconcile these seemingly contradictory statements from two=20 different sources. Thanks. Best Regards, Raymond -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Wednesday, May 12, 2010 8:00 AM To: Raymond (Juin-Hwey) Chen Cc: Koen Vos; codec@ietf.org Subject: Re: [codec] #16: Multicast? On May 4, 2010, at 7:15 PM, Raymond (Juin-Hwey) Chen wrote: > the 3*(codec frame size) delay is very real for IP phone This does not match the measurements I have. And I certainly don't have 100= + year voip experience but I do have two of the #1 selling enterprise phone= s connected to an oscilloscope. Test with other phones suggest most the maj= or vendors of IP hard phones have fairly comparable performance when it com= es to delay.=20 =20 Cullen From rchen@broadcom.com Wed May 12 12:13:02 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5D5B3A6D16 for ; Wed, 12 May 2010 12:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.08 X-Spam-Level: X-Spam-Status: No, score=-0.08 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAYeQYrapzRn for ; Wed, 12 May 2010 12:13:00 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id DFE5D3A6D2D for ; Wed, 12 May 2010 12:02:25 -0700 (PDT) Received: from [10.9.200.133] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 12 May 2010 12:01:58 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Wed, 12 May 2010 12:02:21 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Cullen Jennings" , "Christian Hoene" Date: Wed, 12 May 2010 12:00:57 -0700 Thread-Topic: [codec] this weeks summary Thread-Index: Acrx6H7kKxCEHm4TQGiEqSjlQlFUYAAGJ7eA Message-ID: References: <002e01caefa2$ef88c9a0$ce9a5ce0$@de> <0527FF7A-A0BA-4309-8FF5-A152339F2611@cisco.com> In-Reply-To: <0527FF7A-A0BA-4309-8FF5-A152339F2611@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67F424AC20S122958996-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] this weeks summary X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 19:13:02 -0000 Hi Cullen, In my original email discussion of VoIP gateways, I did not use the=20 phrase "ultra-low delay". What I did say was that due to the large=20 number of voice channels that the DSPs and the (possibly two layers of)=20 micro-controllers have to handle simultaneously, the timing/scheduling=20 can be quite complex, and the necessary buffering at the (possibly=20 three) hierarchical layers of processors can add substantial delay. =20 Therefore, the worst-case codec-dependent one-way delay may be up to 5X=20 to 6X the codec frame size before delay optimization, and even after=20 the engineers "optimize the delay to death", they could only manage to=20 get the worst-case codec-dependent delay down to around 3X codec frame=20 size. =20 Again, I didn't come up with that myself. A senior technical guy who=20 was deeply involved in high-density VoIP gateway designs told me that,=20 and another technical guy who worked at a different company than the=20 first guy and who was involved in the design of a different VoIP=20 gateway based on a different DSP chip and a different system=20 architecture independently gave me a range of codec-dependent one-way=20 delay around 3X codec frame size, and he didn't know that I talked to=20 the first guy. Due to this 3X multiplier, an increase in the codec frame size will=20 have a larger delay impact in VoIP gateways than, say, a softphone=20 that has a lower multiplier. Perhaps it was due to this larger=20 multiplier that Christian used the phrase "ultra-low delay", but I=20 myself didn't use that phrase. I hope this answered your question. Best Regards, Raymond -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of C= ullen Jennings Sent: Wednesday, May 12, 2010 8:21 AM To: Christian Hoene Cc: codec@ietf.org Subject: Re: [codec] this weeks summary On May 9, 2010, at 12:10 PM, Christian Hoene wrote: > Raymond did a great job explaining the special requirements of high-densi= ty VoIP gateway. They are differ substantially to those of > soft-phones (but are somewhat similar to VoIP phones with embedded CPUs).= The requirements include low memory footprint, ultra-low > delay, Uh, can someone walk me through the low delay part? I either missed of fail= ed to understand that=20 > low complexity and mostly narrow band. But aren't those requirements alre= ady covered by existing codecs? Shall this working > group provide a codec profile for end-to-gateway beside the profile for a= n end-to-end codec? Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From swmike@swm.pp.se Wed May 12 15:27:59 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B77B3A697F for ; Wed, 12 May 2010 15:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.538 X-Spam-Level: X-Spam-Status: No, score=-4.538 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_20=-0.74, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwVSsQx1MDLt for ; Wed, 12 May 2010 15:27:58 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by core3.amsl.com (Postfix) with ESMTP id 3C2D13A688F for ; Wed, 12 May 2010 15:27:27 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 89008A5; Thu, 13 May 2010 00:27:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 880D19C; Thu, 13 May 2010 00:27:11 +0200 (CEST) Date: Thu, 13 May 2010 00:27:11 +0200 (CEST) From: Mikael Abrahamsson To: Michael Knappe In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "codec@ietf.org" Subject: Re: [codec] #18: Frame Sizes X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 22:27:59 -0000 On Wed, 12 May 2010, Michael Knappe wrote: > Why would you need frame sizes approaching 250 ms? This would no longer > be supporting two-way communications in a human interactive sense. Because it might work better over your GSM data network which in itself has 1s delay. And you're wrong, I communicate over skype all the time with 2+ second RTT. It's free, the 500ms RTT version costs quite a lot of money. Doing bidirectional talk over long RTT is a matter of practice. I'd rather have 2s RTT for free than paying 1USD / minute. -- Mikael Abrahamsson email: swmike@swm.pp.se From mknappe@juniper.net Wed May 12 17:41:04 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07CE63A69E2 for ; Wed, 12 May 2010 17:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.444 X-Spam-Level: X-Spam-Status: No, score=-4.444 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGPiKnmCTsx1 for ; Wed, 12 May 2010 17:41:03 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 168613A694D for ; Wed, 12 May 2010 17:41:00 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKS+tKj3d1SId3Cd0SVOhrkG1KGTyDAQ2c@postini.com; Wed, 12 May 2010 17:40:50 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 12 May 2010 17:37:44 -0700 From: Michael Knappe To: "swmike@swm.pp.se" Date: Wed, 12 May 2010 17:37:43 -0700 Thread-Topic: [codec] #18: Frame Sizes Thread-Index: AcryIkY+VoRsDkJ3QLCOJ76yN1mdLQAEjkFd Message-ID: <05542EC42316164383B5180707A489EE1D593774F6@EMBX02-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] #18: Frame Sizes X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 00:41:04 -0000 Fair enough, although a service provider's decision to offer a free service= with long round trip delays is likely less dependent on the header efficie= ncy gains made with such large payloads and more on their ability to carry = said traffic cheaply as lower priority traffic over non-QoS controlled netw= ork hops.=20 In any case, the ability to carry multiple codec frames within an RTP packe= t is already standard voip system implementation practice and, with the exc= eption of jitter buffer support for unpacking these composite RTP packets w= hen received, is outside the scope of the codec wg. Mike ----- Original Message ----- From: Mikael Abrahamsson To: Michael Knappe Cc: codec@ietf.org Sent: Wed May 12 18:27:11 2010=0A= Subject: Re: [codec] #18: Frame Sizes On Wed, 12 May 2010, Michael Knappe wrote: > Why would you need frame sizes approaching 250 ms? This would no longer=20 > be supporting two-way communications in a human interactive sense. Because it might work better over your GSM data network which in itself=20 has 1s delay. And you're wrong, I communicate over skype all the time with 2+ second=20 RTT. It's free, the 500ms RTT version costs quite a lot of money. Doing=20 bidirectional talk over long RTT is a matter of practice. I'd rather have 2s RTT for free than paying 1USD / minute. --=20 Mikael Abrahamsson email: swmike@swm.pp.se From swmike@swm.pp.se Wed May 12 22:34:59 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42CC33A6A79 for ; Wed, 12 May 2010 22:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.157 X-Spam-Level: X-Spam-Status: No, score=-4.157 tagged_above=-999 required=5 tests=[AWL=-0.508, BAYES_50=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYlBlZGzQEfc for ; Wed, 12 May 2010 22:34:58 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by core3.amsl.com (Postfix) with ESMTP id 973F93A6A8B for ; Wed, 12 May 2010 22:31:58 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id F02FD9C; Thu, 13 May 2010 07:31:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id ED3779A; Thu, 13 May 2010 07:31:43 +0200 (CEST) Date: Thu, 13 May 2010 07:31:43 +0200 (CEST) From: Mikael Abrahamsson To: Michael Knappe In-Reply-To: <05542EC42316164383B5180707A489EE1D593774F6@EMBX02-HQ.jnpr.net> Message-ID: References: <05542EC42316164383B5180707A489EE1D593774F6@EMBX02-HQ.jnpr.net> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "codec@ietf.org" Subject: Re: [codec] #18: Frame Sizes X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 05:34:59 -0000 On Wed, 12 May 2010, Michael Knappe wrote: > Fair enough, although a service provider's decision to offer a free > service with long round trip delays is likely less dependent on the > header efficiency gains made with such large payloads and more on their > ability to carry said traffic cheaply as lower priority traffic over > non-QoS controlled network hops. This is not a service provider service, this is often a way of doing it without the service provider wanting me to do it this way, that's the only reason it's with 0 marginal cost to me and why it's long RTT. > In any case, the ability to carry multiple codec frames within an RTP > packet is already standard voip system implementation practice and, with > the exception of jitter buffer support for unpacking these composite RTP > packets when received, is outside the scope of the codec wg. As long as this works, I'm fine. As I said, the whole *system* needs to support this, and I have historically very bad experience with decisions being made on each level that this is "out of scope for us" and the resulting *system* then works very poorly, that's why I'm saying what I'm saying. We're aiming at much wider network conditions here, and quite a lot of months back provided quite a lot of different network examples and what I thought the *system* needed to handle. Since you asked about 250ms it's obvious you didn't read my email (or you don't agree with the contents of it), so it still worries me that quite a lot of people here don't understand the network conditions the codec needs to work in, and that we do not have consensus on this point. -- Mikael Abrahamsson email: swmike@swm.pp.se From mknappe@juniper.net Wed May 12 22:47:50 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 932173A6A51 for ; Wed, 12 May 2010 22:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.389 X-Spam-Level: X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IY4Xo3ajW2TE for ; Wed, 12 May 2010 22:47:49 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by core3.amsl.com (Postfix) with ESMTP id F15543A6A58 for ; Wed, 12 May 2010 22:46:53 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKS+uSQdPD4SC4kdNU7iupJaDHzGH9KRP3@postini.com; Wed, 12 May 2010 22:46:44 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Wed, 12 May 2010 22:45:46 -0700 From: Michael Knappe To: "swmike@swm.pp.se" Date: Wed, 12 May 2010 22:45:45 -0700 Thread-Topic: [codec] #18: Frame Sizes Thread-Index: AcryXZqtcpoa8UMxQeaHmO/ME7xg9QAAexgk Message-ID: <05542EC42316164383B5180707A489EE1D593774FC@EMBX02-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] #18: Frame Sizes X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 05:47:50 -0000 Mikael, I did miss reading that email, I will find it and read it. Cheers, Mike ----- Original Message ----- From: Mikael Abrahamsson To: Michael Knappe Cc: codec@ietf.org Sent: Thu May 13 01:31:43 2010=0A= Subject: Re: [codec] #18: Frame Sizes On Wed, 12 May 2010, Michael Knappe wrote: > Fair enough, although a service provider's decision to offer a free=20 > service with long round trip delays is likely less dependent on the=20 > header efficiency gains made with such large payloads and more on their=20 > ability to carry said traffic cheaply as lower priority traffic over=20 > non-QoS controlled network hops. This is not a service provider service, this is often a way of doing it=20 without the service provider wanting me to do it this way, that's the only= =20 reason it's with 0 marginal cost to me and why it's long RTT. > In any case, the ability to carry multiple codec frames within an RTP=20 > packet is already standard voip system implementation practice and, with= =20 > the exception of jitter buffer support for unpacking these composite RTP= =20 > packets when received, is outside the scope of the codec wg. As long as this works, I'm fine. As I said, the whole *system* needs to=20 support this, and I have historically very bad experience with decisions=20 being made on each level that this is "out of scope for us" and the=20 resulting *system* then works very poorly, that's why I'm saying what I'm=20 saying. We're aiming at much wider network conditions here, and quite a lot of=20 months back provided quite a lot of different network examples and what I=20 thought the *system* needed to handle. Since you asked about 250ms it's=20 obvious you didn't read my email (or you don't agree with the contents of=20 it), so it still worries me that quite a lot of people here don't=20 understand the network conditions the codec needs to work in, and that we=20 do not have consensus on this point. --=20 Mikael Abrahamsson email: swmike@swm.pp.se From mknappe@juniper.net Fri May 14 08:56:29 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1A9B3A63EB for ; Fri, 14 May 2010 08:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.345 X-Spam-Level: X-Spam-Status: No, score=-4.345 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mE3whhKmeD3B for ; Fri, 14 May 2010 08:56:28 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 635AB3A68B0 for ; Fri, 14 May 2010 08:56:28 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKS+1ymI4omANmF9F8xUuUjXAUevO6Pdj7@postini.com; Fri, 14 May 2010 08:56:19 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 14 May 2010 08:53:13 -0700 From: Michael Knappe To: Christian Hoene , "codec@ietf.org" Date: Fri, 14 May 2010 08:53:09 -0700 Thread-Topic: [codec] this weeks summary Thread-Index: AcrvouSxwCvhij/GQOaYD+wavcY/SwD2qf68 Message-ID: In-Reply-To: <002e01caefa2$ef88c9a0$ce9a5ce0$@de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] this weeks summary X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 15:56:29 -0000 Yes, thanks everyone for a lot of great discussion over the past several weeks on a number of different issues. I think we're at a good point to review this discussion and see what strong consensus points have emerged, and also highlight any remaining issues for particular discussion as we lea= d up to the Maastricht meeting in July. I will be writing up a summary of tracker issues this weekend to send out t= o the alias, let's make a big push in the next two weeks to close issues wher= e possible in preparation for the July meeting. Cheers, Mike On 5/9/10 11:10 AM, "Christian Hoene" wrote: > Hi all, >=20 > Again, many emails this week. Any important results? My personal summary = after > reading them all again: >=20 > Raymond did a great job explaining the special requirements of high-densi= ty > VoIP gateway. They are differ substantially to those of > soft-phones (but are somewhat similar to VoIP phones with embedded CPUs).= The > requirements include low memory footprint, ultra-low > delay, low complexity and mostly narrow band. But aren't those requiremen= ts > already covered by existing codecs? Shall this working > group provide a codec profile for end-to-gateway beside the profile for a= n > end-to-end codec? >=20 > SpiritDSP and Christian were discussing the need for layered coding - no > consensus yet... >=20 > The week before, we were discussing whether to consider Bluetooth and Wir= eless > IP as use cases. It seems to be a rough consensus > that wireless IP is in-scope and that Bluetooth is out-of-scope because i= t > requires too special optimizations. However, battery > powered, wireless devices might require low-complexity and low-bandwidth = (and > are in-scope?). >=20 > With best regards, >=20 > Christian >=20 > --------------------------------------------------------------- > Dr.-Ing. Christian Hoene > Interactive Communication Systems (ICS), University of T=FCbingen > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ >=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From koen.vos@skype.net Sun May 16 01:28:42 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23C83A691E for ; Sun, 16 May 2010 01:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lt997u7okZF1 for ; Sun, 16 May 2010 01:28:41 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 597FC3A68F5 for ; Sun, 16 May 2010 01:28:41 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 69AB66012BF8F; Sun, 16 May 2010 09:28:31 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=xMjHDqS0rrAI 0eGRmW9+MXCNJ2I=; b=IGhJ93uEzBOqN6hcnSZg+B/Lg6CmasHWWGKgR+iQTOTg DYt9F1rJ89O/yTmTEU4ahF4UC2iI2C6TQDej4YsThT3FnzIODiUy6n9zjm/Pj6+W C3iEDqFYNCWtAhtB7cZvzCMn8WG5it2rZv+05L5LbHTzODQtztdx6Wm+bqaoj0I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=tODDa9k7XgejlAZzB2t7 qOWV4ltR/DKXnFP/lvrGZJHITnmWgn2J3LwAWbVz6YxbAdhn5IcNPAdSH3bMEN9/ GwN54tWXFl0zMr6ABmhCUXkaofyEaDJ+3renS/jB1rZFJ2+YQulmDP416nLZtp49 dpfkfTIQqH4DtmXUNX91n0M= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 678866012BF78; Sun, 16 May 2010 09:28:31 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+HI23XLwNN5; Sun, 16 May 2010 09:28:30 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id AEA836012BF82; Sun, 16 May 2010 09:28:30 +0100 (IST) Received: from aas.attingo.nl (aas.attingo.nl [77.241.230.241]) by mail.skype.net (Horde Framework) with HTTP; Sun, 16 May 2010 01:28:30 -0700 Message-ID: <20100516012830.989257nt8p7l2p4e@mail.skype.net> Date: Sun, 16 May 2010 01:28:30 -0700 From: Koen Vos To: "Raymond (Juin-Hwey) Chen" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <07C815A7-8F3C-4F85-A275-4352D0080EEA@cisco.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 May 2010 08:28:42 -0000 Quoting "Raymond (Juin-Hwey) Chen": > I didn't come up with this 3*(codec frame size) delay number for IP > phones myself. A very senior technical lead in Broadcom's IP phone > chips group told me that Still: - You've presented no satisfactory explanation for your theory - Nor any verifiable empirical evidence - It comes from an anonymous source - It has changed over time (going from 5x to 3x) - It goes against accepted wisdom So I'd say the burden of proof is on you.. koen. From hoene@uni-tuebingen.de Sun May 16 01:59:47 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 468763A6965 for ; Sun, 16 May 2010 01:59:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFUuSgnJmMEN for ; Sun, 16 May 2010 01:59:45 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 704773A695F for ; Sun, 16 May 2010 01:59:45 -0700 (PDT) Received: from hoeneT60 ([178.2.216.228]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4G8xGNv020803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 16 May 2010 10:59:22 +0200 From: "Christian Hoene" To: "'Koen Vos'" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <07C815A7! -8F3C-4F85-A275-4352D00 80EEA@cisco.com> <20100516012830.989257nt8p7l2p4e@mail.skype.net> In-Reply-To: <20100516012830.989257nt8p7l2p4e@mail.skype.net> Date: Sun, 16 May 2010 10:59:15 +0200 Message-ID: <000301caf4d6$13e824c0$3bb86e40$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr00c7lCTYNe9/TQciy5po8uV4kZgAAcgaw Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.242; VDF: 7.10.7.111; host: mx05); id=4664-p2aMaf Cc: frank.kettler@head-acoustics.de, codec@ietf.org Subject: Re: [codec] #16: Delay factor: algorithmic delay vs. transmission latency. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 May 2010 08:59:47 -0000 Hi,=20 some recent studies on the speech quality of gateways and IP phones are = present in=20 http://www.head-acoustics.de/telecomfiles/5th_ETSI_SQTE_Anonymous_Test_Re= port.doc Please have a look at the document first... At the first glance, I did see evidence for the 3x factor for IP = gateways. The best in class at a 40.4 ms one-way delay for G.711 (20ms packets) and a 54.3 ms delay for G.729 (20ms packets) referring to = Tables 4.1 and 4.2. The algorithmic delay of G.729 is 15ms (5ms lookahead). Thus, the algorithmic delay was 20ms for G.711 (plus = an unknown delay of PLC) and 25ms for G.729. Thus, a factor of 3 seems to be valid (5msx2,9=3D53,3-40,4) In case of IP phones it is not that clear. Actually, I did not fully = understand the document. That is 2N and 8N application force? I bet the experts from HEAD acoustic could bring some light into this = discussion and explain, whether they have seen something like a 3x factor between the algorithmic delay and the final latency. For, we could officially send a liaison statement to ETSI asking for = more data. With best regards, Christian --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ >-----Original Message----- >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Koen Vos >Sent: Sunday, May 16, 2010 10:29 AM >To: Raymond (Juin-Hwey) Chen >Cc: codec@ietf.org >Subject: Re: [codec] #16: Multicast? > >Quoting "Raymond (Juin-Hwey) Chen": > >> I didn't come up with this 3*(codec frame size) delay number for IP >> phones myself. A very senior technical lead in Broadcom's IP phone >> chips group told me that > >Still: >- You've presented no satisfactory explanation for your theory >- Nor any verifiable empirical evidence >- It comes from an anonymous source >- It has changed over time (going from 5x to 3x) >- It goes against accepted wisdom > >So I'd say the burden of proof is on you.. > >koen. >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From swmike@swm.pp.se Sun May 16 02:33:39 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19E413A6986 for ; Sun, 16 May 2010 02:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.494 X-Spam-Level: X-Spam-Status: No, score=-4.494 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_20=-0.74, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USbSll0nlOMw for ; Sun, 16 May 2010 02:33:38 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by core3.amsl.com (Postfix) with ESMTP id 6B0153A696A for ; Sun, 16 May 2010 02:33:36 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9BCE79C; Sun, 16 May 2010 11:33:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 9AEDA9A; Sun, 16 May 2010 11:33:22 +0200 (CEST) Date: Sun, 16 May 2010 11:33:22 +0200 (CEST) From: Mikael Abrahamsson To: Christian Hoene In-Reply-To: <000301caf4d6$13e824c0$3bb86e40$@de> Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <07C815A7! -8F3C-4F85-A275-4352D00 80EEA@cisco.com> <20100516012830.989257nt8p7l2p4e@mail.skype.net> <000301caf4d6$13e824c0$3bb86e40$@de> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: codec@ietf.org, frank.kettler@head-acoustics.de Subject: Re: [codec] #16: Delay factor: algorithmic delay vs. transmission latency. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 May 2010 09:33:39 -0000 On Sun, 16 May 2010, Christian Hoene wrote: > At the first glance, I did see evidence for the 3x factor for IP > gateways. The best in class at a 40.4 ms one-way delay for G.711 (20ms > packets) and a 54.3 ms delay for G.729 (20ms packets) referring to > Tables 4.1 and 4.2. The algorithmic delay of G.729 is 15ms (5ms > lookahead). Thus, the algorithmic delay was 20ms for G.711 (plus an > unknown delay of PLC) and 25ms for G.729. Thus, a factor of 3 seems to > be valid (5msx2,9=53,3-40,4) One-way delay of 40.4ms for G.711 sounds like 20ms for packet size and 20ms for jitter buffer. I wouldn't call that "algorithmic delay", that's packet and jitter buffer delay, "algorithmic delay" for G.711 should be "zero" or am I getting the concepts wrong (since it doesn't do any compression). -- Mikael Abrahamsson email: swmike@swm.pp.se From roman@telurix.com Sun May 16 14:21:59 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CFD53A69A9 for ; Sun, 16 May 2010 14:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.444 X-Spam-Level: X-Spam-Status: No, score=-0.444 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAswhRKMS1QI for ; Sun, 16 May 2010 14:21:58 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 0BB4A3A69EE for ; Sun, 16 May 2010 14:21:35 -0700 (PDT) Received: by gyh4 with SMTP id 4so2051028gyh.31 for ; Sun, 16 May 2010 14:21:25 -0700 (PDT) Received: by 10.100.244.38 with SMTP id r38mr4783077anh.29.1274044884535; Sun, 16 May 2010 14:21:24 -0700 (PDT) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.210.182]) by mx.google.com with ESMTPS id 20sm3124772yxe.12.2010.05.16.14.21.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 16 May 2010 14:21:23 -0700 (PDT) Received: by yxe12 with SMTP id 12so2149250yxe.32 for ; Sun, 16 May 2010 14:21:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.165.13 with SMTP id n13mr4878058ybe.389.1274044881581; Sun, 16 May 2010 14:21:21 -0700 (PDT) Received: by 10.150.186.7 with HTTP; Sun, 16 May 2010 14:21:21 -0700 (PDT) In-Reply-To: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <20100516012830.989257nt8p7l2p4e@mail.skype.net> <000301caf4d6$13e824c0$3bb86e40$@de> Date: Sun, 16 May 2010 17:21:21 -0400 Message-ID: From: Roman Shpount To: codec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [codec] #16: Delay factor: algorithmic delay vs. transmission latency. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 May 2010 21:21:59 -0000 This is a great discussion, but I don't see how it is relevant. If the question is should the new CODEC support 5 ms frames, then the answer is probably yes. If there a compelling reason (like achieving better quality or having algorithm delay that makes this irrelevant) we might agree to a bigger minimum frame size. If the question is if the CODEC should support 20ms and bigger compound frames, then the answer is absolutely yes. There are use cases for both. I guess, the only question for me, is if in case of 5 ms frames we care about compression. The packet header overhead is fairly big that you might use PCMU in this case. P.S. From what I know about soft phones the delay component dependent on frame size is 1x. There are other delay components, but they are not frame size dependent. _____________________________ Roman Shpount - www.telurix.com On Sun, May 16, 2010 at 5:33 AM, Mikael Abrahamsson wrot= e: > On Sun, 16 May 2010, Christian Hoene wrote: > >> At the first glance, I did see evidence for the 3x factor for IP gateway= s. >> The best in class at a 40.4 ms one-way delay for G.711 (20ms packets) an= d a >> 54.3 ms delay for G.729 (20ms packets) referring to Tables 4.1 and 4.2. = The >> algorithmic delay of G.729 is 15ms (5ms lookahead). =A0Thus, the algorit= hmic >> delay was 20ms for G.711 (plus an unknown delay of PLC) and 25ms for G.7= 29. >> Thus, a factor of 3 seems to be valid (5msx2,9=3D53,3-40,4) > > One-way delay of 40.4ms for G.711 sounds like 20ms for packet size and 20= ms > for jitter buffer. I wouldn't call that "algorithmic delay", that's packe= t > and jitter buffer delay, "algorithmic delay" for G.711 should be "zero" o= r > am I getting the concepts wrong (since it doesn't do any compression). > > -- > Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From stephen.botzko@gmail.com Sun May 16 16:08:59 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6283A6B5B for ; Sun, 16 May 2010 16:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.506 X-Spam-Level: X-Spam-Status: No, score=-0.506 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BKzbJGksVc0 for ; Sun, 16 May 2010 16:08:57 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 6B7F73A6B58 for ; Sun, 16 May 2010 16:08:56 -0700 (PDT) Received: by wyb42 with SMTP id 42so2197810wyb.31 for ; Sun, 16 May 2010 16:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=yUYVbu+uCRg2J19RytTc0GQF8EksgabKRTq99q6imJ4=; b=LLJD084NT7dhXeB93oYS8NgN+t74JzOra2tgRw7+xC/D1E7XdsAHfgM5pdk/9CH+ly v9xDywBBTLUflIvtQoQbq33ROK3z3lp0DbtgNXXf/vZf6iN46mcrAz1Z7VsOZxBaoFY+ /m1aSlxk8pQw2AcdgsSYCcOeEhYCcu3X537Hs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ov3125IVQ4pUyB6YyEysjoqPknzQb9mfOFnUzosHcKNgkWKrlzP4I3MrM+6ESqyAtZ ZyMYZtfFeuCl9Hk2YXs+znxD9RvJKzeCcuNw0vhjajwOQ7oZn90B/phCSxsE57upnnkW tUZY2S2tNOF8ROz42WfhQIizWq/Iwyl/xHd5E= MIME-Version: 1.0 Received: by 10.216.158.65 with SMTP id p43mr2646989wek.50.1274051324067; Sun, 16 May 2010 16:08:44 -0700 (PDT) Received: by 10.216.23.5 with HTTP; Sun, 16 May 2010 16:08:44 -0700 (PDT) In-Reply-To: <000301caf4d6$13e824c0$3bb86e40$@de> References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <20100516012830.989257nt8p7l2p4e@mail.skype.net> <000301caf4d6$13e824c0$3bb86e40$@de> Date: Sun, 16 May 2010 19:08:44 -0400 Message-ID: From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=0016367fb7d998bef60486be30a8 Cc: codec@ietf.org, frank.kettler@head-acoustics.de Subject: Re: [codec] #16: Delay factor: algorithmic delay vs. transmission latency. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 May 2010 23:08:59 -0000 --0016367fb7d998bef60486be30a8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>> Thus, the algorithmic delay was 20ms for G.711 (plus an unknown delay of PLC) and 25ms for G.729. >>> I am not sure what you are calling "algorithmic delay". Generally it is th= e delay inherent to the algorithm (the delay you would get if you had an infinitely fast processor). Total algorithmic delay for G.711 should be no more than .125 ms, total algorithmic delay for G.729 is 20 ms (15 ms per frame and 5 ms look-ahead). References are here: http://en.wikipedia.org/wiki/G.711 http://en.wikipedia.org/wiki/G.729 Regards, Stephen Botzko On Sun, May 16, 2010 at 4:59 AM, Christian Hoene wr= ote: > Hi, > > some recent studies on the speech quality of gateways and IP phones are > present in > > http://www.head-acoustics.de/telecomfiles/5th_ETSI_SQTE_Anonymous_Test_Re= port.doc > Please have a look at the document first... > > At the first glance, I did see evidence for the 3x factor for IP gateways= . > The best in class at a 40.4 ms one-way delay for G.711 > (20ms packets) and a 54.3 ms delay for G.729 (20ms packets) referring to > Tables 4.1 and 4.2. The algorithmic delay of G.729 is 15ms > (5ms lookahead). Thus, the algorithmic delay was 20ms for G.711 (plus an > unknown delay of PLC) and 25ms for G.729. Thus, a factor > of 3 seems to be valid (5msx2,9=3D53,3-40,4) > > In case of IP phones it is not that clear. Actually, I did not fully > understand the document. That is 2N and 8N application force? > > I bet the experts from HEAD acoustic could bring some light into this > discussion and explain, whether they have seen something like > a 3x factor between the algorithmic delay and the final latency. > > For, we could officially send a liaison statement to ETSI asking for more > data. > > With best regards, > > Christian > > > > > --------------------------------------------------------------- > Dr.-Ing. Christian Hoene > Interactive Communication Systems (ICS), University of T=FCbingen > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > >-----Original Message----- > >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf O= f > Koen Vos > >Sent: Sunday, May 16, 2010 10:29 AM > >To: Raymond (Juin-Hwey) Chen > >Cc: codec@ietf.org > >Subject: Re: [codec] #16: Multicast? > > > >Quoting "Raymond (Juin-Hwey) Chen": > > > >> I didn't come up with this 3*(codec frame size) delay number for IP > >> phones myself. A very senior technical lead in Broadcom's IP phone > >> chips group told me that > > > >Still: > >- You've presented no satisfactory explanation for your theory > >- Nor any verifiable empirical evidence > >- It comes from an anonymous source > >- It has changed over time (going from 5x to 3x) > >- It goes against accepted wisdom > > > >So I'd say the burden of proof is on you.. > > > >koen. > >_______________________________________________ > >codec mailing list > >codec@ietf.org > >https://www.ietf.org/mailman/listinfo/codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016367fb7d998bef60486be30a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>>>
=A0=A0 Thus, the algorithmic delay was 20ms for G.711 (plus an unknown= delay of PLC) and 25ms for G.729.
>>>
I am not sure what you are calling "algorithmic delay".=A0 G= enerally it is the delay inherent to the algorithm (the delay you would get= if you had an infinitely fast processor).
=A0
=A0
Total algorithmic delay for G.711 should be=A0no more than .125 ms, to= tal algorithmic delay for G.729 is 20 ms (15 ms per frame and 5 ms look-ahe= ad).=A0 References are here:
=A0
=A0
Regards,
Stephen Botzko
On Sun, May 16, 2010 at 4:59 AM, Christian Hoene= <hoene@uni-= tuebingen.de> wrote:
Hi,

some recent studies o= n the speech quality of gateways and IP phones are present in
http://www.head-acoustics.de/telecomfiles/5th_ET= SI_SQTE_Anonymous_Test_Report.doc
Please have a look at the document first...

At the first glance, I d= id see evidence for the 3x factor for IP gateways. The best in class at a 4= 0.4 ms one-way delay for G.711
(20ms packets) and a 54.3 ms delay for G.= 729 (20ms packets) referring to Tables 4.1 and 4.2. The algorithmic delay o= f G.729 is 15ms
(5ms lookahead). =A0Thus, the algorithmic delay was 20ms for G.711 (plus an= unknown delay of PLC) and 25ms for G.729. Thus, a factor
of 3 seems to = be valid (5msx2,9=3D53,3-40,4)

In case of IP phones it is not that c= lear. Actually, I did not fully understand the document. That is 2N and 8N = application force?

I bet the experts from HEAD acoustic could bring some light into this d= iscussion and explain, whether they have seen something like
a 3x factor= between the algorithmic delay and the final latency.

For, we could = officially send a liaison statement to ETSI asking for more data.

With best regards,

=A0Christian




-------------= --------------------------------------------------
Dr.-Ing. Christian Ho= ene
Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebin= gen.de/

>-----Original Message-----
>From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Ko= en Vos
>Sent: Sunday, May 16, 2010 10:29 AM
>To: Raymond (Juin-Hwey) Chen=
>Cc: codec@ietf.org
>Sub= ject: Re: [codec] #16: Multicast?
>
>Quoting "Raymond (Jui= n-Hwey) Chen":
>
>> I didn't come up with this 3*(codec frame size) delay = number for IP
>> phones myself. =A0A very senior technical lead in= Broadcom's IP phone
>> chips group told me that
>
>Still:
>- You've presented no satisfactory explanation for yo= ur theory
>- Nor any verifiable empirical evidence
>- It comes = from an anonymous source
>- It has changed over time (going from 5x t= o 3x)
>- It goes against accepted wisdom
>
>So I'd say the bur= den of proof is on you..
>
>koen.
>______________________= _________________________
>codec mailing list
>codec@ietf.org
>https://www.ietf.org/mailman/listinfo/codec

_________________= ______________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--0016367fb7d998bef60486be30a8-- From rchen@broadcom.com Mon May 17 19:36:13 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939763A6BF6 for ; Mon, 17 May 2010 19:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.078 X-Spam-Level: X-Spam-Status: No, score=-0.078 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzBl+OUsxU2I for ; Mon, 17 May 2010 19:36:12 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id D900328C148 for ; Mon, 17 May 2010 19:33:09 -0700 (PDT) Received: from [10.9.200.131] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 17 May 2010 19:32:50 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Mon, 17 May 2010 19:32:50 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Koen Vos" Date: Mon, 17 May 2010 19:32:44 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: Acr00cm5M2ksDsGeS6eUJbwN7imhXQBUE0SQ Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <07C815A7-8F3C-4F85-A275-4352D0080EEA@cisco.com> <20100516012830.989257nt8p7l2p4e@mail.skype.net> In-Reply-To: <20100516012830.989257nt8p7l2p4e@mail.skype.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: B5iF CbvK Cysg EGY3 FqMN Jana MZ2w MaZg M4GI M+Je PqSL SVlF U6xP bdfD bnm+ b9uP; 3; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAZgBsAHUAZgBmAHkAQABjAGkAcwBjAG8ALgBjAG8AbQA7AGsAbwBlAG4ALgB2AG8AcwBAAHMAawB5AHAAZQAuAG4AZQB0AA==; Sosha1_v1; 7; {14528D8F-C077-4CEA-BD0B-46EFE02D1CE3}; cgBjAGgAZQBuAEAAYgByAG8AYQBkAGMAbwBtAC4AYwBvAG0A; Tue, 18 May 2010 02:32:45 GMT; UgBFADoAIABbAGMAbwBkAGUAYwBdACAAIwAxADYAOgAgAE0AdQBsAHQAaQBjAGEAcwB0AD8A x-cr-puzzleid: {14528D8F-C077-4CEA-BD0B-46EFE02D1CE3} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67EF23D820S128147746-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 02:36:13 -0000 Hi Koen, I agree with Roman that this 1X versus 3X debate has reached a=20 point that it is almost irrelevant. What's really relevant now is=20 the question of whether the IETF codec should have a low-delay mode=20 with a codec frame size of 5 to 10 ms, and for that question you=20 previously wrote on May 6: > Anyway, I think we're all aligned here: ultra-low delay is=20 > important and has been part of the requirements from day one. Has=20 > anyone disagreed? After this email of yours, I have not seen anyone explicitly=20 disagreed. In fact, of the 6 intended applications listed in the=20 WG charter, draft-ietf-codec-requirements-00 lists 2 of them having=20 < 10 ms codec delay as a requirement and 3 of them having < 10 ms=20 codec delay as "desirable" or "highly desirable". It seems to me=20 that the consensus in the WG is that we need a low-delay mode with=20 a 5 to 10 ms codec frame size to address delay-sensitive=20 applications, and we need another higher-delay mode with perhaps a=20 20 ms frame size to get higher bit-rate efficiency for applications=20 that are less sensitive to delay. If we agree with that (and I=20 thought you already agreed on May 6), then whether the frame size=20 multiplier is 1X or 3X doesn't really matter and shouldn't affect=20 the codec requirements or the direction of the codec design.=20 With that said, I don't want you to think I impolitely ignored your=20 comments in your email below, so I will respond to them in-line. =20 (For those who are not interested, please ignore the rest of this=20 email.) You wrote: > Quoting "Raymond (Juin-Hwey) Chen": >> I didn't come up with this 3*(codec frame size) delay number for IP >> phones myself. A very senior technical lead in Broadcom's IP phone >> chips group told me that > Still: > - You've presented no satisfactory explanation for your theory [Raymond]: I already explained and analyzed it in my previous emails. =20 The codec-dependent delay =3D (codec frame size) + (codec look-ahead) +=20 (codec filtering delay) + (processing delay to encode and decode one=20 frame) + (transmission delay to send one frame of compressed bit- stream) + (multi-tasking delay due to processor not immediately=20 available to start encoding and decoding operations as soon as one=20 frame of input audio samples or received bit-stream is ready) +=20 (possibly miscellaneous other delays) Although the processing delay is short (but not zero) for a PC having=20 2 ~ 3 GHz CPU, for IP phones the clock speed of the processor is much=20 lower, resulting in significantly higher processing delay than in a=20 PC. Also, the multi-tasking delay can be quite significant, and it=20 is dependent on the codec frame size in IP phones. All these delay=20 components here and there can easily add up to 3X codec frame size. If you have a copy of the 1995 Elsevier book "Speech Coding and=20 Synthesis" edited by W.B. Kleijn and K.K. Paliwal, please go read=20 Section 2 and see Fig. 1 of my chapter 6 on low-delay coding of=20 speech. It should help you understand what I have been saying. =20 Unfortunately due to copyright restrictions, I cannot scan those=20 pages and attach with this email. > - Nor any verifiable empirical evidence [Raymond]: The one-way delay measurement was done at the lab of=20 Broadcom's IP phone chip group. I don't know how I can make that=20 "verifiable" to you. =20 > - It comes from an anonymous source [Raymond]: I didn't just say that I heard it from someone who worked=20 at some (unnamed) company; I specifically said this info came from=20 Broadcom's IP phone group. Is that not sufficient? > - It has changed over time (going from 5x to 3x) [Raymond]: I admit that this was my mistake due to a misunderstanding=20 of what that senior technical lead I mentioned above told me.=20 Initially he said the real-world one-way delay was about 5X codec=20 frame size. I thought he meant codec-dependent delay; that's why I=20 initially used 5X. Later he clarified to me that when he said 5X, he=20 included codec-independent delay, and the codec-dependent delay=20 component was really 3X, so I corrected myself to 3X. > - It goes against accepted wisdom [Raymond]: No, the commonly accepted wisdom back in late 1980s and=20 early 1990s (when several dozen low-delay speech coding papers were=20 published) was 3X codec frame size, although some might have used 2X=20 as the best-case scenario. Since then the CPU of PCs has increased in=20 speed by more than 30X (in early 1990s a popular CPU was the 90 MHz=20 Pentium) and the network speed also increased a lot, so I can believe=20 you that PC-based softphones could potentially reach below 2X as you=20 said, but IP phone processors are much slower than the CPUs of PCs,=20 making it harder to get below 2X. In any case, 1X was never the=20 commonly accepted wisdom, since it is theoretically impossible. > So I'd say the burden of proof is on you. [Raymond]: Broadcom currently ships more than half of the world's IP=20 phone chips, and Broadcom's IP phone group has also measured the one- way codec-dependent delay carefully in the lab with carefully chosen=20 signals, equipment, and methodology, so I don't see why Broadcom's=20 measurement is any less valid than Cullen's, to the point that the=20 burden of proof is on us. I don't believe Broadcom's IP phone=20 implementation is particularly bad in delay compared with others,=20 either (otherwise we are unlikely to be the market leader). In any=20 case, I didn't say that I believe Cullen's results must be wrong. I=20 was just surprised at the discrepancy of the measurement results from=20 these two different sources and would like to find out why and=20 possibly reconcile the seemingly contradictory results. That's why I=20 asked Cullen to share more details about his measurements. Raymond From fluffy@cisco.com Tue May 18 10:37:57 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA1CB3A6A91 for ; Tue, 18 May 2010 10:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.555 X-Spam-Level: X-Spam-Status: No, score=-107.555 tagged_above=-999 required=5 tests=[AWL=-1.856, BAYES_50=0.001, MANGLED_WRLDWD=2.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SWBBTTTPqgA for ; Tue, 18 May 2010 10:37:56 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id E69003A6C4F for ; Tue, 18 May 2010 10:34:28 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAO5r8kurR7Hu/2dsb2JhbACeAXGlIJoAhRAEg0A X-IronPort-AV: E=Sophos;i="4.53,256,1272844800"; d="scan'208";a="223027669" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 18 May 2010 17:34:21 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o4IHYKQ3009574; Tue, 18 May 2010 17:34:20 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Tue, 18 May 2010 11:34:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <909E12B9-984F-4051-A93E-2291EFE0A40E@cisco.com> References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <07C815A7- 8F3C-4F85-A275-4352D0080EEA@cisco.com> To: Raymond (Juin-Hwey) Chen X-Mailer: Apple Mail (2.1078) Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 May 2010 17:37:57 -0000 On May 12, 2010, at 12:28 PM, Raymond (Juin-Hwey) Chen wrote: > Hi Cullen, >=20 > Hmm... That's interesting. Would you please share more details of=20 > your measurement equipment setup, the codec used, the codec frame=20 > size, the number of codec frames in each packet, the way you=20 > measured the delay, and the measured delay value, etc.? =20 Sure - it's really simple to set up. I use a signal generator that makes = a tone burst. Typically I do something like 550 Hz tone that is a 200 ms = long burst that occurs once a second. I play this into a speaker near = the microphone on one phone and also put it into 1 channel of a scope. = I think put a microphone near the speaker of the other phone and put = that on another channel of the scope and measure the mouth to ear delay. = It's really easy to see the starts of the two bursts from the speaker = and microphone and measure the delay within a few ms. I've done lots of = clever things over the years using stats from software in the phones but = this technique is easy and pretty fool proof on getting good results. = The phones were plugged into Netgear 100Mbps hub as I sometimes look at = the timing of the ethernet packets too. I set up phones for G.711, one = frame per packet - I choose this as it is easy to change the length of = each frame but results are similar with other codecs.=20 I was using two Cisco 7960 phones - no idea what version of the software = and may have been a development build but it's pretty unlikely that = current production software would have different results from what I = tested. I set the phones for G.711 with 20 ms packets, measured delay, = then set the phones for 30 ms packets and measured delay. For a given = packet length, when I make multiple phone calls or reboot one of the = phones, the measurements stay consistent.=20 The resulting change in delay between the two experiments was much less = than 30ms that a (3x 30 ms - 3 x 20 ms) would have predicted. I feel = like a total tool not providing the details of the exact measurements = but lots of measurements like this Cisco considers confidential and I'm = just not up to arguing with folks about what can and can not be said = publicly. I probably should have done a test with 10 ms packets too but = I did not. Yes I realize how nuts it is to consider something that = anyone can easily measure as confidential. If anyone really cares, I = will go do the work to be able to provide the numbers.=20 >=20 > I didn't come up with this 3*(codec frame size) delay number for IP=20 > phones myself. A very senior technical lead in Broadcom's IP phone=20 > chips group told me that, and Broadcom is currently the #1 world- > wide market share leader in IP phone chips, accounting for more than=20= > half of the world's IP phone chip shipments. > Most of the world's=20 > tier-1 IP phone manufacturers use our IP phone chips at least in=20 > some of their product lines. Yah, again, Cisco considers chipsets confidential but if you poke around = with google, such as=20 http://lmgtfy.com/?q=3Dteardown+analysis+cisco+7960 Folks claim the 7960 uses a Broadcom chip - of course that looks like it = is for the ethernet switch on the phone not much to do with software = that impacts audio latency.=20 >=20 > I would be very interested to learn more about your measurements to=20 > try to reconcile these seemingly contradictory statements from two=20 > different sources. Thanks. Be glad to talk to whoever it is. I really don't know relevant this all = is too figuring out what packets sizes we need to support. >=20 > Best Regards, >=20 > Raymond >=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: Wednesday, May 12, 2010 8:00 AM > To: Raymond (Juin-Hwey) Chen > Cc: Koen Vos; codec@ietf.org > Subject: Re: [codec] #16: Multicast? >=20 >=20 > On May 4, 2010, at 7:15 PM, Raymond (Juin-Hwey) Chen wrote: >=20 >> the 3*(codec frame size) delay is very real for IP phone >=20 > This does not match the measurements I have. And I certainly don't = have 100+ year voip experience but I do have two of the #1 selling = enterprise phones connected to an oscilloscope. Test with other phones = suggest most the major vendors of IP hard phones have fairly comparable = performance when it comes to delay.=20 >=20 >=20 > Cullen >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From jean-marc.valin@octasic.com Thu May 20 13:40:16 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C99413A67AD for ; Thu, 20 May 2010 13:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.247 X-Spam-Level: X-Spam-Status: No, score=-0.247 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WV1rEddohfe4 for ; Thu, 20 May 2010 13:40:15 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id F2F9F3A67D2 for ; Thu, 20 May 2010 13:40:06 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 May 2010 16:39:59 -0400 Message-ID: <4BF59E1E.7040502@octasic.com> Date: Thu, 20 May 2010 16:39:58 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "codec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 May 2010 20:39:59.0197 (UTC) FILETIME=[9D39C8D0:01CAF85C] Subject: [codec] Codec development update X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 20:40:16 -0000 Hi folks, Here's a quick update on actual development of the codec. So far, in terms of integration, we are still at the experiment stage with the simulated files (these were not actual codecs) I sent earlier combining SILK, BroadVoice and CELT. The original email is at http://www.ietf.org/mail-archive/web/codec/current/msg01241.html and the files are at: http://jmvalin.ca/codec_experiment1/ At the same time, CELT has been improved to facilitate potential integration within a future codec. These are the changes made so far: - Reducing the code size - Improving support for 20 ms frames - Allowing dynamic switching of frame size (between 2.5, 5, 10 and 20 ms) - Adding a configuration option for skipping the low frequencies - Improving the tuning for lower bit-rate speech Those who want to follow the development from the CELT side (and try the latest code) can do so by getting the "master" branch in the git repository. See http://git.xiph.org/?p=celt.git for details. Note that this code is *not* bit-stream compatible with the latest release (0.7.1), nor with the latest I-D (based on 0.6.1). Cheers, Jean-Marc From koen.vos@skype.net Thu May 20 14:03:49 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7582B3A683C for ; Thu, 20 May 2010 14:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.324 X-Spam-Level: X-Spam-Status: No, score=-4.324 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kh5ceksWdzGG for ; Thu, 20 May 2010 14:03:48 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id E47B43A681B for ; Thu, 20 May 2010 14:03:47 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id D64266012CF1F for ; Thu, 20 May 2010 22:03:40 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=ivdCoJ9WtZ0L QzHyLGJ+ef3Yj+k=; b=hPbAVryut7clTk4jK5gBxVZ3ctIGjq1Fxx0IMrPOymGU JCcDoo1wlMA/Zgbz/MOTLehPL8YiFNniYVix0JN0KWMbw8HkXPcPdtcx3NWtxcrS 6J52GgjoDv4pvvpgZXf4hwa+80vytbKAIWmR+t3CTO7RwimjGcHPtaA2wSdIKh0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=XvIfv+YgcrX96ioT9IJi RKyu862q8s1Xz6aX+q/72I5r2pjF3wF78dztF/SzKKKw0qqWfOFLEqiqaQhbueD0 q/2aQHRjWYCAvmi+acJahu+HIJTNq9WmMnKvt0uMc3FfIoUrODoyC5GFh5LGu7JV gogWBIEMQkH2nOzs1S6/l5E= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id D4CD86012CF1C for ; Thu, 20 May 2010 22:03:40 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofFyU8pjjSCD for ; Thu, 20 May 2010 22:03:39 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id CA1FC6012CF1D; Thu, 20 May 2010 22:03:39 +0100 (IST) Received: from adsl-71-141-115-202.dsl.snfc21.pacbell.net (adsl-71-141-115-202.dsl.snfc21.pacbell.net [71.141.115.202]) by mail.skype.net (Horde Framework) with HTTP; Thu, 20 May 2010 14:03:39 -0700 Message-ID: <20100520140339.865664oe2ogdtsq3@mail.skype.net> Date: Thu, 20 May 2010 14:03:39 -0700 From: Koen Vos To: codec@ietf.org References: <4BF59E1E.7040502@octasic.com> In-Reply-To: <4BF59E1E.7040502@octasic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Subject: Re: [codec] Codec development update X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 May 2010 21:03:49 -0000 Here's a similar update about SILK: We've modified SILK based on general feedback and to make it more suited for a hybrid implementation: - Added a 10 ms frame size mode - Added resamplers so that the API can now also handle input/output signals with 32 or 48 kHz sampling rate - Added a configuration option to use CELT's range coder - Reducing program size, mostly through smaller ROM tables (ongoing) We're working on setting up a git repository for sharing the latest version and to facilitate collaboration. best, koen. Quoting Jean-Marc Valin: > Hi folks, > > Here's a quick update on actual development of the codec. So far, in > terms of integration, we are still at the experiment stage with the > simulated files (these were not actual codecs) I sent earlier > combining SILK, BroadVoice and CELT. The original email is at > http://www.ietf.org/mail-archive/web/codec/current/msg01241.html and > the files are at: http://jmvalin.ca/codec_experiment1/ > > At the same time, CELT has been improved to facilitate potential > integration within a future codec. These are the changes made so far: > > - Reducing the code size > - Improving support for 20 ms frames > - Allowing dynamic switching of frame size (between 2.5, 5, 10 and 20 ms) > - Adding a configuration option for skipping the low frequencies > - Improving the tuning for lower bit-rate speech > > Those who want to follow the development from the CELT side (and try > the latest code) can do so by getting the "master" branch in the git > repository. See http://git.xiph.org/?p=celt.git for details. Note > that this code is *not* bit-stream compatible with the latest > release (0.7.1), nor with the latest I-D (based on 0.6.1). > > Cheers, > > Jean-Marc > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From trac@tools.ietf.org Mon May 24 07:13:24 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFC393A6E9D for ; Mon, 24 May 2010 07:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.063 X-Spam-Level: X-Spam-Status: No, score=-101.063 tagged_above=-999 required=5 tests=[AWL=-1.063, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uF5ATPi4rgrz for ; Mon, 24 May 2010 07:13:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 639ED3A6BF3 for ; Mon, 24 May 2010 07:13:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OGYOt-00006k-Sg; Mon, 24 May 2010 07:13:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: jean-marc.valin@usherbrooke.ca, hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 May 2010 14:13:03 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/21#comment:2 Message-ID: <071.809b8d0a6eb5c7e6fc19038c4dd2d758@tools.ietf.org> References: <062.a00b15332f6e9da39f0d81d14d24c64d@tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <062.a00b15332f6e9da39f0d81d14d24c64d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jean-marc.valin@usherbrooke.ca, hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #21: Supporting Wireless Links? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 14:13:25 -0000 #21: Supporting Wireless Links? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: jean-marc.valin@… Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Changes (by hoene@…): * owner: => jean-marc.valin@… Comment: [Benjamin:] > Me too; I'd also like some clarification as to whether we're talking > about (a) > existing Bluetooth headsets or > ... If (a) > ... I'm surprised that such a retrofit is even conceivable. If it is > in fact possible, I would very much appreciate instructions on how to > experiment with new codecs on existing headsets. Once we know how to > build test rigs, we can see what the complexity requirement there is. > If we can't test it, I don't think we can target it. [Raymond]: I was definitely talking about (b), not (a). [Raymond]: Correction: I never argued that we should add a "Bluetooth mode". ... Bluetooth headset was merely given as an example. Considering that there are a very large number of Bluetooth headset users and that the current Bluetooth headsets can already be used for making VoIP phone calls, it would be great if the IETF codec can be implemented in future Bluetooth headsets to avoid the additional coding distortion and delay associated with transcoding. However, with that said, I didn't mean to push a "Bluetooth mode" for the IETF codec. I merely wanted to use Bluetooth headset as an example to make a point that a low codec complexity is desirable and a high codec complexity can have negative consequences. [Christian]: > The week before, we were discussing whether to consider Bluetooth and > Wireless IP as use cases. It seems to be a rough consensus that > wireless IP is in-scope and that Bluetooth is out-of-scope because it > requires too special optimizations. However, battery powered, wireless > devices might require low-complexity and low-bandwidth (and are > in-scope?). [Raymond]: I read an article that says that PC was the big thing in the decade of 1990-2000, Internet was the big thing in the decade of 2000- 2010, and Mobile Internet will be the next big thing in the decade of 2010- 2020. Judging from the recent trends in smart phones, netbooks, and Tablets/iPad, it seems that Mobile Internet indeed will be the next big thing this decade. Given this, I think battery-powered wireless Internet- capable devices should be in-scope, and low codec complexity is an important consideration in these devices. CONSENSUS: Wireless IP is in scope; non-IP Bluetooth is out. -- Ticket URL: codec From trac@tools.ietf.org Mon May 24 07:14:43 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD3073A6BBE for ; Mon, 24 May 2010 07:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.677 X-Spam-Level: X-Spam-Status: No, score=-99.677 tagged_above=-999 required=5 tests=[AWL=-2.443, BAYES_50=0.001, FF_IHOPE_YOU_SINK=2.166, J_CHICKENPOX_66=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCbMs7XuWiam for ; Mon, 24 May 2010 07:14:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DE2C13A6BF8 for ; Mon, 24 May 2010 07:14:41 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OGYQI-0004En-GO; Mon, 24 May 2010 07:14:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 May 2010 14:14:30 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/20#comment:2 Message-ID: <071.1e13fb419ab1efbd5ed09c3d0b550bf8@tools.ietf.org> References: <062.8524135614c0f45c18915362cc459235@tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <062.8524135614c0f45c18915362cc459235@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #20: Computational complexity? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 14:14:44 -0000 #20: Computational complexity? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Benjamin]: I think this is a typo, and you mean "lessened the pressure to reduce bitrates and complexity, and has shifted the focus to fidelity and delay instead". ... I'd also like some clarification as to whether we're talking about ... or (b) future hardware designed to support the IWAC. If (b), then this is just a matter of negotiating the acceptable encode+decode complexity, for eventual implementation by DSP or ASIC. [Raymond]: My main point in this area is just that there are complexity-sensitive applications such as low-end devices and VoIP gateways where a low codec complexity is important or even necessary. In other words, if the IETF codec complexity is too high, then either it will become much more expensive for some applications (e.g. gateways), or it may not even be feasible to put the codec in some low-end devices. ... I merely wanted to use Bluetooth headset as an example to make a point that a low codec complexity is desirable and a high codec complexity can have negative consequences. [Kevin]: This is all perfectly reasonable, but given the likely timeframe we are talking about for this codec to be produced and published as a standards-track RFC, the definition of 'low complexity' in this discussion is really talking about the 2012-2013 version of 'low complexity', not today's. It seems highly likely that the MIPS capacity of the DSPs designed into Bluetooth headsets in 2012 will be vastly greater than what is used today, if there is an application to take advantage of the additional MIPS. [Raymond]: I completely agree with you that the IETF codec development should not be constrained by a low-complexity device designed in 2009 or earlier, and we should look toward the time frame of 2012 and 2013 instead. In my previous emails I have indicated that due to many reasons, over the last several years the processing power of Bluetooth headsets has been increasing at a rate much slower than what's predicted by Moore's Law, and it doesn't look like this will change significantly in the next few years. I also said that for the current-generation Bluetooth headset chips, the maximum codec complexity it can support is probably somewhere around 5 MIPS on a 16-bit fixed-point DSP, and by the time the IETF codec becomes a standard, the number may go up to 10 MIPS, or 15 MIPS at most. Thus, if we want mono Bluetooth headsets in the FUTURE (i.e. in the next several years) to be able to run the IETF codec in the narrowband or wideband mode at least, a good complexity target to shoot for is 10 to 20 MIPS on a fixed-point DSP. [JM] I'm just curious about where you got your MIPS figures for Bluetooth? I'm not familiar with the type of DSPs used in those applications, but from a quick search of more "general-purpose" DSPs (TI, ADI and similar), the lowest speed I was able to find (sold in 2010) was a 50 MIPS DSP. Any idea what type of DSPs are currently used in Bluetooth? [Raymond]: I should have clarified: I am not proposing that we limit the complexity of all IETF codec modes to 10 to 20 MIPS. That would be unreasonable, especially for high- sampling- rate and high-fidelity applications. Just like we seemed to have reached a consensus that a low-delay mode is necessary to address delay-sensitive applications (as is specified in the codec requirement document), we can also have a low-complexity mode to address complexity-sensitive applications such as low- end/mobile devices and gateways. It is for such a low-complexity mode that 10 - 20 MIPS is a good target to shoot for, at least for narrowband and wideband. (Super- wideband and full-band can be layered coding on top of that and do not need to be subject to this 10 - 20 MIPS target.) For other coding modes that require more processing power, this 10 - 20 MIPS target obviously would not apply. Also, if we don't like to have too many different coding modes, and if some modes can be combined, for example, if the low-delay mode can also achieve low complexity, then we can combine the low-delay mode and the low-complexity mode into a single mode. We can have another mode that's more efficient in bit-rate but may have higher delay and complexity to address those applications that are less sensitive to delay and complexity. [JM]: Oh, I realise your original message did not state 10-20 MIPS as the target for all modes. My only questions was about how you came to the 10-20 MIPS figure in the first place. Any DSP vendor(s) roadmap or something? Or what would be the relevant existing DSP for which we could extrapolate future performance? As I said, I'm not too familiar about the DSPs used in Bluetooth because all the regular DSPs I can find are 50 MIPS or above. [Raymond]: Bluetooth headsets normally don't use general-purpose DSPs from those traditional DSP houses that you mentioned below. A lot of mid- to low-end Bluetooth headsets (where most of the shipping volume is) don't even have any DSP and instead just rely on an ARM processor to do all voice/audio processing and Bluetooth protocol stack. The 5 MIPS number for current-generation BT headsets was quoted to me by an experienced Bluetooth audio engineering manager in terms of MIPS on an ARM processor, but since most speech coding engineers are more familiar with the MIPS for a general-purpose 16-bit fixed-point DSP, so I converted the MIPS on an ARM to the equivalent MIPS on a fixed-point DSP, and it came to around 5 MIPS. The 10 to 20 MIPS number is what we may expect in a several years as Moore's Law helps to increase the processing power of Bluetooth headsets. High-end Bluetooth headset chips may have a DSP on-chip, but it is usually either a proprietary DSP or a DSP core not from the traditional DSP houses but from companies like ARM. One thing to keep in mind, though, is that even if you have a DSP on a Bluetooth headset chip, and it is clocked at 50 MHz or higher, it doesn't mean that you can use all or most of that DSP processing power for speech or audio coding. This is because it has to handle many other signal processing tasks such as acoustic echo canceller, single-mic or multi-mic noise suppression, wind noise suppression, packet loss concealment, voice prompt decoding, and even voice command recognition, to name just a few. You can't even get half of the DSP processing power solely dedicated to speech coding. You will be lucky if you can get 20% of the DSP for speech coding. Remember that currently the speech coding part (CVSD codec) takes 0% of the DSP or ARM because it is done in chip hardware. [Christan]: what do you think about STL2005/9 described in ITU-T G.191. It might be a good metric to measure the codec performance in low-complexity mode. STL2009 is not yet published officially but the STL 2005 manual is available for free. http://www.itu.int/rec/T-REC-G.191-200508-I/en Chapter 13, Page 159 describes a set of basic operator and their complexity weights. STL2009 is similar but has guidelines on data movement and program ROM estimation tool for fixed-point c code and a complexity evaluation tool for floating-point C Code. However, STL2005 might not be optimal for soft-phone complexity prediction because many operations have overflow control and saturation, that typically cannot be translated into a single native assembler instruction. Thus, for soft-phone I would recommend to use slightly modified measures... [Raymond]: The ITU-T software tool library has been used to measure the complexity of many fixed-point standard speech codecs, and we have done that, too. So, yes, I think it is a good and well-accepted way to measure the complexity of fixed-point codecs. For floating-point implementations, although I don't know of a similar software tool for complexity measurement, it is not that difficult to do something similar and add some complexity counting code to an existing floating-point C code to measure the complexity of a floating-point codec. -- Ticket URL: codec From trac@tools.ietf.org Mon May 24 07:15:02 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0013A6C12 for ; Mon, 24 May 2010 07:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.355 X-Spam-Level: X-Spam-Status: No, score=-102.355 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrerAWPtvkuv for ; Mon, 24 May 2010 07:15:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5FAF63A6BF8 for ; Mon, 24 May 2010 07:14:59 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OGYQb-00055N-Pp; Mon, 24 May 2010 07:14:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 May 2010 14:14:49 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/28#comment:2 Message-ID: <071.2abd605356e39281676cf3607d5cd168@tools.ietf.org> References: <062.23d5df12c0b3d27cb5b6b25801ab2a4d@tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <062.23d5df12c0b3d27cb5b6b25801ab2a4d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #28: Layered bit-stream X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 14:15:02 -0000 #28: Layered bit-stream ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Raymond]: I think layered coding (or embedded coding) is a nice feature to have. Some of the other SDOs have standardized layered codecs. Besides the pros and cons of layered coding already discussed last week, I think another potential benefit is that as the packets of layer-coded bit- stream traverse the network, higher-layer bits can be stripped off by network nodes to reduce congestion. (This is probably not done, but can be done.) -- Ticket URL: codec From trac@tools.ietf.org Mon May 24 07:16:02 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D883A6E9D for ; Mon, 24 May 2010 07:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.055 X-Spam-Level: X-Spam-Status: No, score=-101.055 tagged_above=-999 required=5 tests=[AWL=-1.055, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkCYGUkavo7j for ; Mon, 24 May 2010 07:15:54 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C11383A6AC1 for ; Mon, 24 May 2010 07:15:54 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OGYRX-00088D-Dr; Mon, 24 May 2010 07:15:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 May 2010 14:15:47 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/33 Message-ID: <062.f33215ed513b5540d72cce71ceca2a9a@tools.ietf.org> X-Trac-Ticket-ID: 33 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #33: Impact of transmission delay X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 14:16:02 -0000 #33: Impact of transmission delay ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- [Koen]: For typical VoIP applications, Moore's law has lessened the pressure to reduce bitrates, delay and complexity, and has shifted the focus to fidelity instead. [Benjamin]: I think this is a typo, and you mean "lessened the pressure to reduce bitrates and complexity, and has shifted the focus to fidelity and delay instead". [Koen]: Not a typo: codecs have become more wasteful with delay, while delivering better fidelity. G.718 evolved out of AMR-WB and has more than twice the delay. Same for G.729.1 versus G.729. This is not by accident. The main rationale for codec delay being less important today is that faster hardware has reduced end-to-end delay in every step along the way. As a result, a typical VoIP connection now operates at a flatter part of the "impairment-vs-delay" curve, meaning that reducing delay by N ms at a given fidelity gives a smaller improvement to end users today than it did some years ago. Therefore, the weight on minimizing delay in the "codec design problem" has gone down, and the optimum codec operating point has naturally shifted towards higher delay, in favor of fidelity. I've mentioned before that average delay on Internet connections seems to be 40% to 50% lower now than just 5 years ago, which is just one contributor to lower end-to-end delay. That doesn't mean high-delay connections don't exist - they do, for instance over dial-up or 3G. But in those cases it's still better to use a moderate packet rate (and bitrate), to minimize congestion risk. The confusion may come from the fact that the trade-off between fidelity and delay changes towards high quality levels: once fidelity saturates, delay gets priority. Even more so because such high fidelity enables new, delay-sensitive applications like distributed music performances. This is reflected in the ultra-low delay requirements in the requirements document. To summarize, the case for using sub-20 ms frame sizes with medium- fidelity quality is now weaker than ever, because the relative importance of fidelity has gone up. [Christian]: may I present some results of the ITU-T SG12 on the perceptual effects of delay? For many years, it was assumed that 150ms is the boundary for interactive voice conversations (see Nobuhiko Kitawaki, and Kenzo Itoh: Pure Delay Effects on Speech Quality in Telecommunications, IEEE J. on Selected Areas in Commun., Vol.9, No.4, pp.586-593, May 1991) Until 400ms quality is still acceptable (about toll quality). The ITU-T G.107 quality model reflects this opinion. However, in the recent years, new results have shown that the impact of delay on conversation quality is NOT as strong as assumed. At the ITU-T, numerous contributions have been made on this issue: Contribution of BT “Comparison of E-Model and subjective test data for pure-delay conditions” from 2007-01-08: Link http://www.itu.int/md/T05-SG12-C-0030/en The conversational tests were done in controlled environments with nine pairs of subjects. Two subjects had the common tasks of their set of sorting pictures in the same order. Other conditions: No echos, G.711, no frame loss [PICTURE at http://www.ietf.org/mail- archive/web/codec/current/msg01588.html] Legend: MOS-CQS are subjective conversational tests MOS-CQE is the E-Modell (G.107) MOS-LQO are result from PESQ. The delay is a one-way delay. Beside MOS values, they also studied the subjective rating of percentage difficultly (%D). Starting at about 150ms is goes up at reaches 35% at 900ms. After that it remains constant. Also, LM Ericsson described very interesting results in “Investigation of the influence of pure delay, packet loss and audio-video synchronization for different conversation tasks” from 2007-09-24. http://www.itu.int/md/T05-SG12-C-0119/en For example: The done conversational tests similar to ITU-T P.805. The conversation lasted about 3 to 5 minutes. 11 pairs of experts were taken part. [PICTURE at http://www.ietf.org/mail- archive/web/codec/current/msg01588.html] The tasks at 160ms were done about 50s faster than the same task at 600ms And in the second tests about 60 naïve subjects and experts were taken part to solve a conversational task. If they were asked for interactivity the ratings look worse. Overall, it seems that the limit of 150ms is greatly overestimated. A much relaxed timing is allowed. [Benjamin]: (1) The results conflict with common sense. A round-trip delay of 800 ms makes normal conversation extremely irritating in practice. I'm not surprised these results don't show up in laboratory tests, because fast conversations with interjections and rapid responses typically require a social context not available in a lab test. It's possible that the ITU regards "extremely irritating" as "acceptable", since effective conversation is still possible. In that case, I would say that the working group intends to enable applications with much better than "acceptable" quality. (2) Tests may have been done in G.711 narrowband, which introduces its own intelligibility problems and reduces quality expectation. Higher fidelity makes latency more apparent. Similarly, the equipment used may have introduced quality impairments that make the delay merely one problem among many. (3) I presume the tests were done with careful equipment setup to avoid echo. The perceived quality impact of echo at 200 ms one-way delay is enormous, as shown in http://downloads.hindawi.com/journals/asp/2008/185248.pdf Using an echo-canceller impairs quality significantly. Imperfect echo cancellation leaves some residual artifact, which is also irritating at long delays. The tests (even in the paper above) were performed using a telephone handset and earpiece. High-quality telephony with a freestanding speaker instead of an earpiece demands especially low delay due to the difficulties with echo cancellation. [Marshall]: This depends a lot on what sort of discussion is at issue (and, also on the culture of the participants). For example, in my experience telepresence sessions tend to be structured meetings and can typically tolerate even half second delays without too much disruption, while for a one-on-one conversation on the same equipment the same delay can be pretty objectionable. Having said that, I myself also find the previously attached graphs a little odd, and want to see a written description of just what sort of experiments they describe. [Brian]: I agree with this. I was in a group that did some research on this (unpublished, unfortunately) and we confirmed that there is a cliff, around 500 ms round trip, after which conversation is impaired. It is remarkably consistent, is more or less independent of culture (with one interesting exception), and is really a cliff: under it and further improvement is hard to notice, over it and conversation is impaired, and the difference between say 750 and 1500ms isn't all that significant. Engineers who believe delay is a "less is better" quantity need to be educated that it is not. It is a threshold [JM]: Considering that the network delay is not a constant, you no longer have an absolute cliff. So reducing the delay means you can increase the distance without falling off the cliff. [Benjamin]: One test in that paper told trained subjects to "Take turns reading random numbers aloud as fast as possible", on a pair of handsets with narrowband uncompressed audio and no echo. Subjects were able to detect round-trip delays down to 90 ms. Conversational efficiency was impaired even with round-trip delay of 100 ms. Let me emphasize again that these delays are round-trip, not one-way, there is no echo, and the task, while designed to expose latency, is probably less demanding than musical performance. ... I accept Brian Rosen's claim that a slow conversation doesn't normally suffer greatly from round-trip latencies up to 500 ms, but under some circumstances much lower latencies are valuable. Let's make sure they're achievable for those who can use them. [Raymond]: Other than potential echo issues, the biggest problem with a one-way delay longer than a few hundred ms is that such a long delay makes it very difficult to interrupt each other, resulting in the start-stop- start-stop cycles I previously talked about. Therefore, I agree with Ben that if the lab test did not have echoes and did not involve the test subjects trying to interrupt each other, then the test results may appear more benign than what one would experience in the real world. Note that the top curve in the first figure below is for “listening-only tests”. Well, in that case there was no interaction/interruption at all, so if there was no echoes, either, then it is no wonder that the curve stayed essentially flat. I do wonder what made the curve go down at 1300 ms; I guess to understand this we need to know what the lab set up was for this test. Thus, I echo Marshall’s opinion that we need the original paper/contribution. My personal experience with the delay impairment is much worse than the middle curve (MOS-CQS) would suggest and is close to the bottom curve (MOS-CQE). Back in early 1980s the phone calls I made from southern California to East Asia were carried through geosynchronous satellites with a one-way delay slightly more than 500 ms (see http://en.wikipedia.org/wiki/Geostationary_orbit). I absolutely hated it, because turn-taking was severely impaired and the only way to interrupt the person at the other side was to keep talking (rudely, I may say) until the other person finally stopped. Then, starting in late 1980s undersea cables were used to carry my traditional circuit-switched calls to the same person in East Asia, and all of a sudden the delay was much shorter and interrupting each other felt as easy as face-to-face conversation. It’s a night-and-day difference! Even in early 2000s when I used my cell phone to call my son’s cell phone in another cellular network, I could tell that there was a significant delay that noticeably impaired our turn- taking and our ability to interrupt each other, and I didn’t like it at all. Now you know why I advocate low-delay voice communications, have been working on low-delay speech coding for two decades, and have even published a book chapter on low-delay speech coding :o) [Stephen]: From my own experience (not testing) I agree with Brian's claim that 500 ms round trip is acceptable for most conversation. It does depend on what you are doing, and there are certainly tasks where much lower delays are needed. [Mike]: Agreed that achieving low enough latencies for sidetone perception should not be a goal of the wg, but we should be aiming if at all possible for better than 250 ms one-way delay in typical (and non-tandemed) deployments. The knee of the one-way delay impairment factor begins rising non-linearly somewhere between 150 and 250 ms. [Raymond]: If you read the published technical papers on G.718 and G.729.1 carefully, I think you will find that the real reason for the increased delay is not because they needed a longer delay to achieve better fidelity for speech, but because they wanted to extend speech codecs to also get good performance when coding general audio (music, etc.). To get good music coding performance, most audio codecs use Modified Discrete Cosine Transform (MDCT) with at least a transform window size that is fairly large, so most of the audio codecs have longer coding delays than speech codecs. To code music well, G.718 and G.729.1 developers naturally had to use long MDCT transform windows on top of the codec delay already in AMR- WB and G.729. Even so, the resulting longer delays of G.718 and G.729.1 are still not any longer than typical delays of audio codecs; in fact, they are probably somewhat shorter. My point is that the increased delays of G.718 and G.729.1 are purely a result of changing from "speech-only" to "speech and music". It's not because the G.718 and G.729.1 developers knew the network delay was getting shorter so they could be more wasteful with delay. Furthermore, even after they changed the codecs to handle music as well as speech, they still chose to make their codec delays shorter than the delays of most audio codecs. Why? They wanted to make their codec delays as short as they could. In fact, they even made an effort to introduce a "low-delay mode" into both G.718 and G.729.1. That shows they were pretty concerned about the higher delays they needed to have in order to code music well. By the way, G.718 does NOT have "more than twice the delay" of AMR-WB as you said. AMR-WB has a 20 ms frame size, 5 ms look-ahead, and 1.875 ms of filtering delay, for a total algorithmic buffering delay of 26.875 ms. The "normal mode" of G.718 has a buffering delay of 42.875 ms for 16 kHz wideband input/output. That's only 59.5% higher than AMR-WB. For Layers 1 and 2 coding of speech, the "low-delay mode" shaves 10 ms off to give a delay of 32.875 ms, or only 22.3% higher than AMR-WB. When G.729.1 was first standardized in May 2006, there was already a low- delay mode for narrowband speech at 8 and 12 kb/s with a algorithmic buffering delay of 25 ms. Later in August 2007, the developers made an effort to add another low-delay mode for wideband at 14 kb/s that has a buffering delay of 28.94 ms. If they wanted to sacrifice delay to get higher fidelity as you suggested, then why would they bother to go back and add another low-delay mode for wideband? In fact, only a few months ago in their G.729.1 paper in IEEE Communications Magazine, October 2009, Varga, Proust, and Taddei still emphasized in multiple instances the importance of achieving a low coding delay. I will quote two of the instances: "The low-delay mode... was added to the first wideband layer at 14 kb/s of G.729.1 (August 2007). The motivation was to address applications such as VoIP in enterprise networks where low end-to-end delay is crucial" and "Indeed, delay is an important performance parameter, and transmitting speech with low end-to-end delay is also required in several applications making use of wideband signals". In summary, I do not see a clear trend where codec developers are becoming more wasteful with delay in order to get higher fidelity. If anything, in recent years I saw a trend of low-delay audio coding, such as low-delay AAC and the CELT codec, and I saw the effort by G.718 and G.729.1 developers to introduce low-delay modes. In any case, I thought a few days ago a consensus was already reached in the WG email reflector that the IETF codec needs to have a low- delay mode with a 5 to 10 ms codec frame size so that it can handle delay-sensitive applications (that is 5 out of 6 applications listed in the charter and codec requirement document). Therefore, I think the discussion in your last email and my current email is mostly of academic interest only and doesn't and shouldn't affect how the IETF codec is to be designed. [Mike]: Agreed that achieving low enough latencies for sidetone perception should not be a goal of the wg, but we should be aiming if at all possible for better than 250 ms one-way delay in typical (and non-tandemed) deployments. The knee of the one-way delay impairment factor begins rising non-linearly somewhere between 150 and 250 ms. CONSENSUS: Impairments start somewhere between 150 and 250ms one-way delay. -- Ticket URL: codec From trac@tools.ietf.org Mon May 24 07:16:43 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B56D73A6EAE for ; Mon, 24 May 2010 07:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.053 X-Spam-Level: X-Spam-Status: No, score=-101.053 tagged_above=-999 required=5 tests=[AWL=-1.053, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLNCtSAvmUuD for ; Mon, 24 May 2010 07:16:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id D0B303A6C1B for ; Mon, 24 May 2010 07:16:15 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OGYRn-0000Q1-Lv; Mon, 24 May 2010 07:16:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 May 2010 14:16:03 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/6#comment:1 Message-ID: <071.a293d99e07bda620ab6842af73477e74@tools.ietf.org> References: <062.f22210f0e625bdcff3a3a9cbfacf433e@tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <062.f22210f0e625bdcff3a3a9cbfacf433e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #6: Echo and Ultra-low Delay X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 14:16:44 -0000 #6: Echo and Ultra-low Delay ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Benjamin]: In the presence of echo, round-trip delay must be kept below 30 ms to ensure that the echo is perceived as sidetone, according to the Springer handbook of speech processing: (http://books.google.com/books?id=Slg10ekZBkAC&lpg=PA83&ots=wc9yM9WrCs&dq=sidetone%20delay%2030%20ms&lr&pg=PA84#v=onepage&q&f=false) [Stephen]: VOIP phones that are capable of speakerphone operation all have acoustic echo cancelers, and those cancelers are already tuned to deal with internet delays with other voice codecs. Certainly our phones and videoconferencing systems do not have problems with path delays of this order (hundreds of milliseconds). Such low delays are clearly impossible on many paths, but for Boston to New York City (or London to Paris), ping times can be less than 18 ms, making echo->sidetone conversion just barely possible for a codec with 5ms frames. -- Ticket URL: codec From trac@tools.ietf.org Mon May 24 07:17:17 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC3063A6E9B for ; Mon, 24 May 2010 07:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+L2T17uEpy8 for ; Mon, 24 May 2010 07:17:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id F01823A6BF8 for ; Mon, 24 May 2010 07:17:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OGYSr-0003gu-MO; Mon, 24 May 2010 07:17:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 May 2010 14:17:09 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/33#comment:1 Message-ID: <071.80b429c2ce7e096146355bea303ea016@tools.ietf.org> References: <062.f33215ed513b5540d72cce71ceca2a9a@tools.ietf.org> X-Trac-Ticket-ID: 33 In-Reply-To: <062.f33215ed513b5540d72cce71ceca2a9a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #33: Impact of transmission delay X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 14:17:17 -0000 #33: Impact of transmission delay ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: requirements | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by hoene@…): * status: new => closed * resolution: => fixed -- Ticket URL: codec From trac@tools.ietf.org Mon May 24 07:18:02 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38C3E3A6BF8 for ; Mon, 24 May 2010 07:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.051 X-Spam-Level: X-Spam-Status: No, score=-101.051 tagged_above=-999 required=5 tests=[AWL=-1.051, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edWg9XHvCpCA for ; Mon, 24 May 2010 07:18:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id EB4C23A6E9E for ; Mon, 24 May 2010 07:17:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OGYTW-0005FZ-Hc; Mon, 24 May 2010 07:17:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 May 2010 14:17:50 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/6#comment:2 Message-ID: <071.573763b5e2835137f48b7677222d17a9@tools.ietf.org> References: <062.f22210f0e625bdcff3a3a9cbfacf433e@tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <062.f22210f0e625bdcff3a3a9cbfacf433e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #6: Echo and Ultra-low Delay X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 14:18:02 -0000 #6: Echo and Ultra-low Delay ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: requirements | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by hoene@…): * status: new => closed * resolution: => fixed Comment: [Stephen]: VOIP phones that are capable of speakerphone operation all have acoustic echo cancelers, and those cancelers are already tuned to deal with internet delays with other voice codecs. Certainly our phones and videoconferencing systems do not have problems with path delays of this order (hundreds of milliseconds). [Benjamin]: In my experience, the biggest problem is in complex conferences with many users at different latencies, and endpoints consisting of multiple- microphone multiple-speaker systems scattered across a room and frequently repositioned. Anyway, I don't think it's very contentious that (a) on high latency links (e.g. long distances), AEC will always be needed in speakerphones, (b) the perceived audio quality in the presence of AEC is improved by very low round-trip acoustic latency, and (c) AEC may be retuned at very low round-trip acoustic latency for further improvement in perceived audio quality. Very high audio quality may not yet be a major concern in this market, but I think this working group is going to change that. [Jari]: Generally I believe that AECs mainly take care of the acoustic echo generated in the phone itself (operating on the microphone signal, acoustic delay up to a few ms). Do you mean that there is additional processing on the receiving side for the echo returning from the B user side? [Stephen]: Acoustic echo cancelers remove the signal from the local speaker(s) that is feeding back into the local microphone(s). So if my AEC is turned off, then you will hear the echo (and I will not). The echo that you hear is delayed by the round trip transport time, the processing delays in the sender and receiver, and the acoustic path delay between the speaker and the microphone. However, the echo that the AEC detects is only delayed the acoustic path delay and whatever processing delay (buffering) the receiver has on its audio capture and render circuitry. So you are correct if you are thinking that the network transport time and codec delay do not impact the requirements for the AEC. There can also be path delay between the receiver output and the actual speaker. For instance in a video conferencing application, the video processing in the TV itself can add delay, and the TV will delay the audio to maintain sync. So if your phone system can be connected to external sound systems, then that can effect the delays the AEC has to accommodate. Also, in larger rooms the acoustic path delay can be substantial since sound takes about 100 ms to travel 100 feet (341 meters per second). [Benjamin]: "Do you mean that there is additional processing on the receiving side for the echo returning from the B user side?" Only in the user's head. The psychoacoustics of echo are very different depending on the echo time. This means that the perceived echo-canceler fidelity depends on the acoustic round-trip delay. It also means that the AEC should be retuned depending on the round-trip delay. [Marshall]: It is not clear to me if the CODEC charter includes stereo (not typically used in telephony, but reasonably common in video conferencing); stereo AEC is tougher than mono and I believe that there is some serious IPR in this area. [Stephen]: I agree with Jari's assessment, though I am not sure exactly what you mean by "retuning". The far-end user will perceive the fed-back echo in various ways, and that does depend on the round-trip time. However, the job of the AEC is to remove the echo, so there is no fed-back echo to hear. And the algorithms which remove echo do not depend on the round- trip delay to the far end. At least not the good ones. Perhaps more substantively, I do not think this AEC discussion actually matters in this WG context. We are not working on an AEC, we are working on an Internet Codec. Even if (for argumentation purposes) you accept the idea that somehow the AEC needs to be tuned to the round-trip delay, the round-trip delay varies enormously depending on the connection, and this round-trip time in general is not even discoverable (esp. if gateways or SBCs are used). Nothing we are doing in this group will change any of the above. As far as sidetone goes, I do not understand why that keeps coming up either. For the speakerphone use case eliminating AECs from both ends requires two conditions: (a) the round trip delay has to be very low (30 ms or less, from all delay sources) (b) there has to be sufficient attenuation on the loop. The first condition has been brought up repeatedly. For general internet WAN connections it is clearly not met, and it is in fact difficult to meet even on more local connections. The second condition has not been discussed much. But if you do have low delay but do not have enough attenuation, what you get is feedback, and not sidetone. Since users have control over the speaker volume, the second condition (in general) also can not be guaranteed. All speakerphones that I know of are either half-duplex or use AECs. This is true even for PSTN phones used in local-loop circuit-switched calls, which is the lowest delay telephony connection that there is. So for telephony at least, it is clear that AECs are needed. So I do not think continued debate on the value of sidetone is productive. I agree with Michael's comment "achieving low enough latencies for sidetone perception should not be a goal of the wg" CONCENSUS: Achieving low enough latencies for sidetone perception is out of scope. -- Ticket URL: codec From trac@tools.ietf.org Mon May 24 07:22:31 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9148B3A6D2F for ; Mon, 24 May 2010 07:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.049 X-Spam-Level: X-Spam-Status: No, score=-101.049 tagged_above=-999 required=5 tests=[AWL=-1.049, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id butW5a3tGuYP for ; Mon, 24 May 2010 07:22:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0B75F3A6C08 for ; Mon, 24 May 2010 07:22:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OGYXY-0004eu-Ty; Mon, 24 May 2010 07:22:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 May 2010 14:22:00 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/18#comment:2 Message-ID: <071.5a6467d9ead8acf164405de6cff1ef6a@tools.ietf.org> References: <062.d51439b68d5cdc7daff30cac51ddab04@tools.ietf.org> X-Trac-Ticket-ID: 18 In-Reply-To: <062.d51439b68d5cdc7daff30cac51ddab04@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #18: Frame Sizes? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 14:22:31 -0000 #18: Frame Sizes? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Stephen]: However, the possible frame sizes are often driven by the underlying technology (transform size being one example). If we decided on 10 and 20 ms for example, would we actually rule out a codec technology that had to run at 7.5, 15 and 22.5? [Cullen]: +1 Also, it seems that people working on maximizing efficient use of the network might want size much long than 20 ms. [Mikael]: My belief is that the solution needs to support frame sizes ranging from 5ms up to somewhere around 100-250ms. It might be that internally it's actually only doing 5-20 ms and it's the transport that package it together so that the fps is way down, but I think it still needs to be taken into account when design is done. [Ben]: I agree. The CELT RTP encapsulation draft provides, I think, a logical implementation of this, by allowing tight packing of several codec frames into a single RTP packet: http://tools.ietf.org/html/draft-valin-celt-rtp- profile-01#section-3.3 [Mike]: Why would you need frame sizes approaching 250 ms? This would no longer be supporting two-way communications in a human interactive sense. ... Yes, the option and decision to pack multiple frames into an RTP packet should be up to the implementer of an overall voice system, and should also be supported by the receiving jitter buffer mechanism, whether or not that receiving jitter buffer is part and parcel of the defined codec. Many voice systems today already support this, for instance it is typical for many of today's VoIP gateway solutions to pack two G.729A frames into each RTP packet. [Mikael]: Because it might work better over your GSM data network which in itself has 1s delay. And you're wrong, I communicate over skype all the time with 2+ second RTT. It's free, the 500ms RTT version costs quite a lot of money. Doing bidirectional talk over long RTT is a matter of practice. [Mike]: Fair enough, although a service provider's decision to offer a free service with long round trip delays is likely less dependent on the header efficiency gains made with such large payloads and more on their ability to carry said traffic cheaply as lower priority traffic over non- QoS controlled network hops. In any case, the ability to carry multiple codec frames within an RTP packet is already standard voip system implementation practice and, with the exception of jitter buffer support for unpacking these composite RTP packets when received, is outside the scope of the codec wg. [Mikael]: As long as this works, I'm fine. As I said, the whole *system* needs to support this, and I have historically very bad experience with decisions being made on each level that this is "out of scope for us" and the resulting *system* then works very poorly, that's why I'm saying what I'm saying. We're aiming at much wider network conditions here, and quite a lot of months back provided quite a lot of different network examples and what I thought the *system* needed to handle. Since you asked about 250ms it's obvious you didn't read my email (or you don't agree with the contents of it), so it still worries me that quite a lot of people here don't understand the network conditions the codec needs to work in, and that we do not have consensus on this point. -- Ticket URL: codec From trac@tools.ietf.org Mon May 24 07:22:31 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AF2F3A6D5A for ; Mon, 24 May 2010 07:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.894 X-Spam-Level: X-Spam-Status: No, score=-99.894 tagged_above=-999 required=5 tests=[AWL=-2.194, BAYES_50=0.001, MANGLED_WRLDWD=2.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgElp6sLIA74 for ; Mon, 24 May 2010 07:22:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 17A843A6944 for ; Mon, 24 May 2010 07:21:58 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OGYXO-00041N-OB; Mon, 24 May 2010 07:21:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 May 2010 14:21:50 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/19#comment:4 Message-ID: <071.9ea7ae626659c7d13ac94a0416b13f7b@tools.ietf.org> References: <062.f8b0d2abf056a9655a81ee25366bb354@tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <062.f8b0d2abf056a9655a81ee25366bb354@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #19: How large is the frame size depended delay / the serialization delay / frame size depended processing delay? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 14:22:31 -0000 #19: How large is the frame size depended delay / the serialization delay / frame size depended processing delay? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Cullen]: This does not match the measurements I have. And I certainly don't have 100+ year voip experience but I do have two of the #1 selling enterprise phones connected to an oscilloscope. Test with other phones suggest most the major vendors of IP hard phones have fairly comparable performance when it comes to delay. [Raymond]: Hmm... That's interesting. Would you please share more details of your measurement equipment setup, the codec used, the codec frame size, the number of codec frames in each packet, the way you measured the delay, and the measured delay value, etc.? [Cullen]: Sure - it's really simple to set up. I use a signal generator that makes a tone burst. Typically I do something like 550 Hz tone that is a 200 ms long burst that occurs once a second. I play this into a speaker near the microphone on one phone and also put it into 1 channel of a scope. I think put a microphone near the speaker of the other phone and put that on another channel of the scope and measure the mouth to ear delay. It's really easy to see the starts of the two bursts from the speaker and microphone and measure the delay within a few ms. I've done lots of clever things over the years using stats from software in the phones but this technique is easy and pretty fool proof on getting good results. The phones were plugged into Netgear 100Mbps hub as I sometimes look at the timing of the ethernet packets too. I set up phones for G.711, one frame per packet - I choose this as it is easy to change the length of each frame but results are similar with other codecs. I was using two Cisco 7960 phones - no idea what version of the software and may have been a development build but it's pretty unlikely that current production software would have different results from what I tested. I set the phones for G.711 with 20 ms packets, measured delay, then set the phones for 30 ms packets and measured delay. For a given packet length, when I make multiple phone calls or reboot one of the phones, the measurements stay consistent. The resulting change in delay between the two experiments was much less than 30ms that a (3x 30 ms - 3 x 20 ms) would have predicted. I feel like a total tool not providing the details of the exact measurements but lots of measurements like this Cisco considers confidential and I'm just not up to arguing with folks about what can and can not be said publicly. I probably should have done a test with 10 ms packets too but I did not. Yes I realize how nuts it is to consider something that anyone can easily measure as confidential. If anyone really cares, I will go do the work to be able to provide the numbers. [Raymond]: I didn't come up with this 3*(codec frame size) delay number for IP phones myself. A very senior technical lead in Broadcom's IP phone chips group told me that, and Broadcom is currently the #1 world- wide market share leader in IP phone chips, accounting for more than half of the world's IP phone chip shipments. Most of the world's tier-1 IP phone manufacturers use our IP phone chips at least in some of their product lines. In my original email discussion of VoIP gateways, I did not use the phrase "ultra-low delay". What I did say was that due to the large number of voice channels that the DSPs and the (possibly two layers of) micro- controllers have to handle simultaneously, the timing/scheduling can be quite complex, and the necessary buffering at the (possibly three) hierarchical layers of processors can add substantial delay. Therefore, the worst-case codec-dependent one-way delay may be up to 5X to 6X the codec frame size before delay optimization, and even after the engineers "optimize the delay to death", they could only manage to get the worst-case codec-dependent delay down to around 3X codec frame size. Again, I didn't come up with that myself. A senior technical guy who was deeply involved in high-density VoIP gateway designs told me that, and another technical guy who worked at a different company than the first guy and who was involved in the design of a different VoIP gateway based on a different DSP chip and a different system architecture independently gave me a range of codec-dependent one-way delay around 3X codec frame size, and he didn't know that I talked to the first guy. Due to this 3X multiplier, an increase in the codec frame size will have a larger delay impact in VoIP gateways than, say, a softphone that has a lower multiplier. [Koen]: Still: - You've presented no satisfactory explanation for your theory - Nor any verifiable empirical evidence - It comes from an anonymous source - It has changed over time (going from 5x to 3x) - It goes against accepted wisdom [Christian]: some recent studies on the speech quality of gateways and IP phones are present in http://www.head- acoustics.de/telecomfiles/5th_ETSI_SQTE_Anonymous_Test_Report.doc Please have a look at the document first... At the first glance, I did see evidence for the 3x factor for IP gateways. The best in class at a 40.4 ms one-way delay for G.711 (20ms packets) and a 54.3 ms delay for G.729 (20ms packets) referring to Tables 4.1 and 4.2. The algorithmic delay of G.729 is 15ms (5ms lookahead). Thus, the algorithmic delay was 20ms for G.711 (plus an unknown delay of PLC) and 25ms for G.729. Thus, a factor of 3 seems to be valid (5msx2,9=53,3-40,4) [Mikael]: One-way delay of 40.4ms for G.711 sounds like 20ms for packet size and 20ms for jitter buffer. I wouldn't call that "algorithmic delay", that's packet and jitter buffer delay, "algorithmic delay" for G.711 should be "zero" or am I getting the concepts wrong (since it doesn't do any compression). [Roman]: This is a great discussion, but I don't see how it is relevant. If the question is should the new CODEC support 5 ms frames, then the answer is probably yes. If there a compelling reason (like achieving better quality or having algorithm delay that makes this irrelevant) we might agree to a bigger minimum frame size. If the question is if the CODEC should support 20ms and bigger compound frames, then the answer is absolutely yes. There are use cases for both. I guess, the only question for me, is if in case of 5 ms frames we care about compression. The packet header overhead is fairly big that you might use PCMU in this case. P.S. From what I know about soft phones the delay component dependent on frame size is 1x. There are other delay components, but they are not frame size dependent. [Stephen]: Total algorithmic delay for G.711 should be no more than .125 ms, total algorithmic delay for G.729 is 20 ms (15 ms per frame and 5 ms look- ahead). References are here: http://en.wikipedia.org/wiki/G.711 http://en.wikipedia.org/wiki/G.729 [Frank Kettler] We did not explicitly verify the relation between algorithmic delay and the measured delay, because all manufactures typically built "something around". We tested "end products" (gateways, IP phones, ...) and there might always be some internal overhead compared to pure coders... [Raymond]: I agree with Roman that this 1X versus 3X debate has reached a point that it is almost irrelevant. What's really relevant now is the question of whether the IETF codec should have a low-delay mode with a codec frame size of 5 to 10 ms, and for that question you previously wrote on May 6: CONSENSUS: No further discussions and clarifications on this issues. -- Ticket URL: codec From trac@tools.ietf.org Mon May 24 07:22:31 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A471C3A6D87 for ; Mon, 24 May 2010 07:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.047 X-Spam-Level: X-Spam-Status: No, score=-101.047 tagged_above=-999 required=5 tests=[AWL=-1.047, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyfEc3io7Rjp for ; Mon, 24 May 2010 07:22:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 106B43A6C12 for ; Mon, 24 May 2010 07:22:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OGYXg-0005Z8-Bk; Mon, 24 May 2010 07:22:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 May 2010 14:22:08 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/15#comment:2 Message-ID: <071.ec17032c829ac2dce0dbc4374c8280b6@tools.ietf.org> References: <062.bc75a3b3c4a980df34535f87c9484935@tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <062.bc75a3b3c4a980df34535f87c9484935@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #15: Efficiently combine pre-encoded audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 14:22:31 -0000 #15: Efficiently combine pre-encoded audio ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Cullen]: For conference bridges, it's probably more important to be able to decide who the active speakers are with low CPU complexity than the actually act of mixing the the selected speakers. Consider a typical call with 7 people who might be speakers and the 3 most active are selected and mixed. In many systems today, most the MIPS goes to decoding all 7 streams to do speaker detection before the resulting 4 streams are formed and encoded. If there was a cheap way to figure out who the active speakers were without doing a full decode of all 7 streams, that would be sort of nice the for conferences bridges. [Brian]: Excellent idea. Been there, never really did it. It's complex. Effectively, you need a distributed adaptive threshold mechanism. However, if you had it, user experience in multispeaker environments gets a win. [Benjamin]: The cheapest solution, of course, is transmit-side activity detection. Maybe we need to specify a way for a receiver to request that the transmitter employ (or not employ) VAD. [JM]: I think you can do better than an encoder VAD. All you need to do is make sure that the relevant information you need for a VAD can easily be decoded from the bit-stream without having to do a full decoding. For example, if you're able to easily extract the gain and spectral envelope, you can do a VAD based on that without even having to look at the other parameters in the bit-stream. [Brian]: The adaptive threshold doesn't have to be distributed, as the conference bridge is selecting the highest scores. You do need a consistent way to compute the scores in the endpoints, ideally using a method which is not simply energy. I realize the bridge can alternatively generate scores from bitstream information; I am thinking that is equivalent to including a metric in the RTP payload. -- Ticket URL: codec From trac@tools.ietf.org Mon May 24 07:22:35 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 165EF3A6D5A for ; Mon, 24 May 2010 07:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.039 X-Spam-Level: X-Spam-Status: No, score=-101.039 tagged_above=-999 required=5 tests=[AWL=-1.039, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhJvD3470PlA for ; Mon, 24 May 2010 07:22:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 748BC3A6C1B for ; Mon, 24 May 2010 07:22:22 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OGYXn-0005io-3h; Mon, 24 May 2010 07:22:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 May 2010 14:22:15 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/14#comment:2 Message-ID: <071.305e71a2ad840434c74fe5953992951a@tools.ietf.org> References: <062.0a0a8ad9a1d9d19f0f66b4858f523549@tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <062.0a0a8ad9a1d9d19f0f66b4858f523549@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #14: VAD and CNG? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 14:22:35 -0000 #14: VAD and CNG? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Raymond]: I think comfort noise is more than just to let the telephone user know that the connection is not dead. If voice packets are sent only during active voice regions of the signal (in DTX) and not during silence/background noise regions, and if there is audible background noise and comfort noise is not added during background noise regions, at the receiving end the background noise will be "on" only during active voice and "off" otherwise. This frequent on-off switching will make the background noise sound unnatural and will bother many users. Adding comfort noise during background noise regions will make such background noise sound more natural. [Benjamin]: The cheapest solution, of course, is transmit-side activity detection. Maybe we need to specify a way for a receiver to request that the transmitter employ (or not employ) VAD. [Benjamin]: I know that CELT makes decoder VAD very efficient, but how is decoder VAD better than encoder VAD? Encoder VAD saves even more CPU, saves bandwidth, and enables easier jitter buffering. Are you thinking about some sort of adaptive thresholding that requires knowing all streams' volume levels? Anyway, VAD can run on both encode and decode sides at the same time. [Stephen]: It might be valuable to be able to obtain the VAD without having to decrypt the bitstream, since that also can become a problem as the number of streams grows. There is a security consideration (traffic analysis), however, it still might be worth thinking about. [JM]: > I know that CELT makes decoder VAD very efficient, Not only CELT. You can do that with an LPC-based codec too. > but how is decoder VAD > better than encoder VAD? Encoder VAD saves even more CPU, saves > bandwidth, and enables easier jitter buffering. There's a few reasons why I think decoder-side is better: - The decision for an encoder-size VAD would take some amount of space in the bit-stream - If we make an encode-size VAD mandatory, then all encoders will have to spend the CPU cycles, even when it's not needed. If it's not mandatory, then the decoder cannot rely on it, so it still needs to implement a VAD - A decoder VAD does not need to be specified in an exact way, so implementers can choose different implementations depending on that information they need. - You cannot "game" a decode-size VAD. > Are you thinking about some sort of adaptive thresholding that > requires knowing all streams' volume levels? Well, knowing the relative amplitudes of each stream can allow you to take more intelligent decisions, e.g. when you have to choose the "most active speaker". That's something you can't really get from an encoder VAD. > Anyway, VAD can run on both encode and decode sides at the same time. That would just mean nobody would bother implementing the encode side. [Benjamin]: I think I failed to communicate that by VAD I mean _not sending packets_ during inactivity. For the packets that are sent, the overhead should average much less than 1 bit per frame. I'm not suggesting sending 200 packets a second containing a flag indicating no voice activity, followed by carefully coded background noise. That would be silly. > - If we make an encode-size VAD mandatory, then all encoders will have > to spend the CPU cycles, even when it's not needed. If it's not > mandatory, then the decoder cannot rely on it, so it still needs to > implement a VAD I don't see this as "mandatory". The encoder can turn off VAD, and probably should for full-quality applications. > - A decoder VAD does not need to be specified in an exact way, so > implementers can choose different implementations depending on that > information they need. The only thing that needs exact specification is the signalling. The encoder may use it or not use it as it pleases. > - You cannot "game" a decode-size VAD. I don't know what this means. >> Are you thinking about some sort of adaptive thresholding that >> requires knowing all streams' volume levels? > > Well, knowing the relative amplitudes of each stream can allow you to > take more intelligent decisions, e.g. when you have to choose the > "most active speaker". That's something you can't really get from an encoder VAD. > >> Anyway, VAD can run on both encode and decode sides at the same time. > > That would just mean nobody would bother implementing the encode side. I expect encode-side VAD on a conference call to save more than a factor of 2 in bandwidth, which makes it very desirable, especially for large deployments. People will use it to save bandwidth (especially if it's on by default in the reference implementation). The decode-side CPU savings are just a minor bonus side-effect. [JM]: What you're describing is called DTX (discontinuous transmission). This can be useful feature, but it's very different from what we were originally talking about in terms of conference mixing. [Ben]: Oops. Right. What I'm trying to say is that DTX, based on encoder- side VAD, also greatly reduces the (average) computational burden on a conference mixer. Of course, if everyone's really talking at once then VAD can't help. [Roman]: There is one more application to efficiently combining pre- encoded audio: playing announcements or recorded audio. Standard network or IVR announcements can be encoded once and efficiently inserted or combined into audio stream. If pre-encoded audio is supported and the client supports AVT tones, it is trivial to develop a very efficient IVR server which does not require any CODEC encoding or decoding. Efficient decoder side VAD is also very helpful in case of speech recognition, where it allows to save cycles in end-pointer. This way audio only needs to be decoded and passed to the speech recognition system only when voice is present. Bottom line, if we have both efficient decoder side VAD and combining pre- encoded audio we can develop some very efficient VXML servers, voice mail and IVR system, not just conferencing servers. Of course, this works well only if the background noise is relatively stationary. If the background noise is dynamically changing, then comfort noise can't really sound like the true background noise. Today I was put on hold in a phone call with music playing. Apparently the system treated some parts of the music as background noise and replaced them with comfort noise. The result is pretty annoying, or amusing, depending on which way you look at it. Therefore, I think comfort noise has its value if DTX is used and the background noise is fairly stationary, but if the background noise or music is changing dynamically and high audio quality is desired, then the DTX and comfort noise should be turned off and all parts of the signal need to be transmitted. -- Ticket URL: codec From hoene@uni-tuebingen.de Mon May 24 07:42:51 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F91C3A6816 for ; Mon, 24 May 2010 07:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.571 X-Spam-Level: X-Spam-Status: No, score=-0.571 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_60=1, HELO_EQ_DE=0.35, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+vs2AaIAATa for ; Mon, 24 May 2010 07:42:50 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id D92073A6832 for ; Mon, 24 May 2010 07:42:49 -0700 (PDT) Received: from hoeneT60 ([82.113.121.147]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4OEgRGl002116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 24 May 2010 16:42:36 +0200 From: "Christian Hoene" To: Date: Mon, 24 May 2010 16:42:24 +0200 Message-ID: <003301cafb4f$595f0cb0$0c1d2610$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr7TwrC27L7xT0UQgGZrqmDNMKm4Q== Content-Language: de x-cr-hashedpuzzle: BhAJ Cf9q C4J8 DemI EtBr Ewoj G0P/ HHpI HqSr H8Qm I9WP Jdf3 Jg5W KUBu Kmr3 LLdB; 1; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {5AD1B79B-DAF3-4AD7-B17E-ABFDF74340B4}; aABvAGUAbgBlAEAAdQBuAGkALQB0AHUAZQBiAGkAbgBnAGUAbgAuAGQAZQA=; Mon, 24 May 2010 14:40:23 GMT; UwB1AG0AbQBhAHIAeQAgAG8AZgAgAGwAYQBzAHQAIAB0AHcAbwAgAHcAZQBlAGsAcwA= x-cr-puzzleid: {5AD1B79B-DAF3-4AD7-B17E-ABFDF74340B4} X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Subject: [codec] Summary of last two weeks X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 14:42:51 -0000 Hi all, my personal summary of the last two weeks emails. - Wireless IP is in, Bluetooth is out. Consensus. - The need for a low complexity mode was stated (e.g. 10-20 MIPS), which = must not support all audio qualities. No clear consensus on this issue yet... - Which is the complexity of the low complexity mode? - How to measure the complexity? - Delay threshold for telephony is somewhere in between 150-250 one way. = Consensus. - 5ms frames should be supported because of different reasons. = Consensus.=20 - There is no consensus why. Arguments were given distributed ensemble = performances, sidetone, high-density gateways and hardware phones. Consensus that we do not need to understand all those arguments = and scenarios. - Upper limit frame size limit shall be between 100-250ms. If required, = larger packets can be generated by putting multiple frames in one packet. - Supporting Layered coding? No consensus yet. - VAD, CNG, DTX? And how to efficiently combine pre-encoded audio? The = discussion is still not finished... With best regards, Christian --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ From br@brianrosen.net Mon May 24 07:48:32 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84E93A6359 for ; Mon, 24 May 2010 07:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.341 X-Spam-Level: X-Spam-Status: No, score=0.341 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSCLRGIzuJhf for ; Mon, 24 May 2010 07:48:30 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id AAB7A3A6813 for ; Mon, 24 May 2010 07:48:30 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.195]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1OGYwx-0003Rn-0q; Mon, 24 May 2010 09:48:15 -0500 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 24 May 2010 10:48:18 -0400 From: Brian Rosen To: , Message-ID: Thread-Topic: [codec] #14: VAD and CNG? Thread-Index: Acr7UCWVvG5Svlx6n0WnvziJ/5NDvA== In-Reply-To: <071.305e71a2ad840434c74fe5953992951a@tools.ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Subject: Re: [codec] #14: VAD and CNG? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 14:48:32 -0000 I hope we are assuming VAD (or DTX) is negotiable. It is essential (for emergency calls) that VAD is disabled. While in many cases the endpoint will know that it is in an emergency call, and disable VAD, it is not alway= s possible to know. Brian On 5/24/10 10:22 AM, "codec issue tracker" wrote: > #14: VAD and=20 > CNG? ------------------------------------+------------------------------------ > --- Reporter: hoene@=8A | Owner: Type: defect > | Status: new Priority: major | Milestone: > Component: requirements | Version: Severity: - > | Keywords: =20 > ------------------------------------+--------------------------------------= - > Comment(by hoene@=8A): [Raymond]: I think comfort noise is more than just to > let the telephone user know that the connection is not dead. If voice > packets are sent only during active voice regions of the signal (in DTX) and > not during silence/background noise regions, and if there is audible > background noise and comfort noise is not added during background noise > regions, at the receiving end the background noise will be "on" only during > active voice and "off" otherwise. This frequent on-off switching will make > the background noise sound unnatural and will bother many users. Adding > comfort noise during background noise regions will make such background noise > sound more natural. [Benjamin]: The cheapest solution, of course, is > transmit-side activity detection. Maybe we need to specify a way for a > receiver to request that the transmitter employ (or not employ) VAD. > [Benjamin]: I know that CELT makes decoder VAD very efficient, but how is > decoder VAD better than encoder VAD? Encoder VAD saves even more CPU, saves > bandwidth, and enables easier jitter buffering. Are you thinking about some > sort of adaptive thresholding that requires knowing all streams' volume > levels? Anyway, VAD can run on both encode and decode sides at the same > time. [Stephen]: It might be valuable to be able to obtain the VAD without > having to decrypt the bitstream, since that also can become a problem as the > number of streams grows. There is a security consideration (traffic > analysis), however, it still might be worth thinking about. [JM]: > I know > that CELT makes decoder VAD very efficient, Not only CELT. You can do that > with an LPC-based codec too. > but how is decoder VAD > better than encoder > VAD? Encoder VAD saves even more CPU, saves > bandwidth, and enables easier > jitter buffering. There's a few reasons why I think decoder-side is better: > - The decision for an encoder-size VAD would take some amount of space in= the > bit-stream - If we make an encode-size VAD mandatory, then all encoders will > have to spend the CPU cycles, even when it's not needed. If it's not > mandatory, then the decoder cannot rely on it, so it still needs to implement > a VAD - A decoder VAD does not need to be specified in an exact way, so > implementers can choose different implementations depending on that > information they need. - You cannot "game" a decode-size VAD. > Are you > thinking about some sort of adaptive thresholding that > requires knowing all > streams' volume levels? Well, knowing the relative amplitudes of each stream > can allow you to take more intelligent decisions, e.g. when you have to > choose the "most active speaker". That's something you can't really get from > an encoder VAD. > Anyway, VAD can run on both encode and decode sides at the > same time. That would just mean nobody would bother implementing the encode > side. [Benjamin]: I think I failed to communicate that by VAD I mean _not > sending packets_ during inactivity. For the packets that are sent, the > overhead should average much less than 1 bit per frame. I'm not suggesting > sending 200 packets a second containing a flag indicating no voice activity, > followed by carefully coded background noise. That would be silly. > - If > we make an encode-size VAD mandatory, then all encoders will have > to spend > the CPU cycles, even when it's not needed. If it's not > mandatory, then the > decoder cannot rely on it, so it still needs to > implement a VAD I don't > see this as "mandatory". The encoder can turn off VAD, and probably should > for full-quality applications. > - A decoder VAD does not need to be > specified in an exact way, so > implementers can choose different > implementations depending on that > information they need. The only thing > that needs exact specification is the signalling. The encoder may use it or > not use it as it pleases. > - You cannot "game" a decode-size VAD. I don't > know what this means. >> Are you thinking about some sort of adaptive > thresholding that >> requires knowing all streams' volume levels? > > Well, > knowing the relative amplitudes of each stream can allow you to > take more > intelligent decisions, e.g. when you have to choose the > "most active > speaker". That's something you can't really get from an encoder VAD. > >> > Anyway, VAD can run on both encode and decode sides at the same time. > > > That would just mean nobody would bother implementing the encode side. I > expect encode-side VAD on a conference call to save more than a factor of 2 > in bandwidth, which makes it very desirable, especially for large > deployments. People will use it to save bandwidth (especially if it's on= by > default in the reference implementation). The decode-side CPU savings are > just a minor bonus side-effect. [JM]: What you're describing is called DTX > (discontinuous transmission). This can be useful feature, but it's very > different from what we were originally talking about in terms of conference > mixing. [Ben]: Oops. Right. What I'm trying to say is that DTX, based on > encoder- side VAD, also greatly reduces the (average) computational burden on > a conference mixer. Of course, if everyone's really talking at once then > VAD can't help. [Roman]: There is one more application to efficiently > combining pre- encoded audio: playing announcements or recorded audio. > Standard network or IVR announcements can be encoded once and efficiently > inserted or combined into audio stream. If pre-encoded audio is supported and > the client supports AVT tones, it is trivial to develop a very efficient IVR > server which does not require any CODEC encoding or decoding. Efficient > decoder side VAD is also very helpful in case of speech recognition, where it > allows to save cycles in end-pointer. This way audio only needs to be decoded > and passed to the speech recognition system only when voice is present. > Bottom line, if we have both efficient decoder side VAD and combining pre= - > encoded audio we can develop some very efficient VXML servers, voice mail= and > IVR system, not just conferencing servers. Of course, this works well only > if the background noise is relatively stationary. If the background noise is > dynamically changing, then comfort noise can't really sound like the true > background noise. Today I was put on hold in a phone call with music > playing. Apparently the system treated some parts of the music as background > noise and replaced them with comfort noise. The result is pretty annoying, or > amusing, depending on which way you look at it. Therefore, I think comfort > noise has its value if DTX is used and the background noise is fairly > stationary, but if the background noise or music is changing dynamically and > high audio quality is desired, then the DTX and comfort noise should be > turned off and all parts of the signal need to be transmitted. -- Ticket > URL: codec > ______________________________________________ > _ codec mailing=20 > list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From trac@tools.ietf.org Mon May 24 07:50:57 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 060553A659A for ; Mon, 24 May 2010 07:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yasSsUsjWz3J for ; Mon, 24 May 2010 07:50:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 54D793A6359 for ; Mon, 24 May 2010 07:50:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OGYzR-0001d8-0T; Mon, 24 May 2010 07:50:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 May 2010 14:50:48 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/11#comment:1 Message-ID: <071.5b4b96f3cb44413669132d1625997ced@tools.ietf.org> References: <062.348f1aead12a1cf82f83703f06be8fb5@tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <062.348f1aead12a1cf82f83703f06be8fb5@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #11: Packet loss concealment? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 14:50:57 -0000 #11: Packet loss concealment? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: requirements | Version: Severity: - | Resolution: duplicate Keywords: | ------------------------------------+--------------------------------------- Changes (by hoene@…): * status: new => closed * resolution: => duplicate -- Ticket URL: codec From trac@tools.ietf.org Mon May 24 07:52:27 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 600603A68AA for ; Mon, 24 May 2010 07:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.338 X-Spam-Level: X-Spam-Status: No, score=-102.338 tagged_above=-999 required=5 tests=[AWL=0.262, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcBfstPRLF0f for ; Mon, 24 May 2010 07:52:26 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 96D0B3A6813 for ; Mon, 24 May 2010 07:52:26 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OGZ0t-0001eL-AN; Mon, 24 May 2010 07:52:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Mon, 24 May 2010 14:52:19 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/29#comment:1 Message-ID: <071.d63396ba97fcff9ddfe2027fa317d364@tools.ietf.org> References: <062.7815381850dc9f0a504d2c451298e6bb@tools.ietf.org> X-Trac-Ticket-ID: 29 In-Reply-To: <062.7815381850dc9f0a504d2c451298e6bb@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #29: Packet loss concealment? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 14:52:27 -0000 #29: Packet loss concealment? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): Comments from ticket #11 Will PLC be a mandatory component of the codec? Will the codec provide an implementation of PLC, but with the hooks to allow different and potentially improved (or network condition specific) implementations of PLC to be substituted in the codec? -- Ticket URL: codec From hoene@uni-tuebingen.de Mon May 24 07:54:50 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965E73A6813 for ; Mon, 24 May 2010 07:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.904 X-Spam-Level: X-Spam-Status: No, score=-0.904 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyvWXrNUBq4Z for ; Mon, 24 May 2010 07:54:49 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 476BA3A68AA for ; Mon, 24 May 2010 07:54:48 -0700 (PDT) Received: from hoeneT60 ([82.113.121.147]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4OEsVZs002841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 24 May 2010 16:54:38 +0200 From: "Christian Hoene" To: Date: Mon, 24 May 2010 16:54:28 +0200 Message-ID: <003401cafb51$079bbc50$16d334f0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr7UQCYjOdpIA70QmKTQgml1a7kBQ== Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Subject: [codec] Other issues regarding the codec requirement document. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 14:54:50 -0000 Hello, I have gone through the tickets and identified the following issues as = not well discussed. Packet loss concealment: http://trac.tools.ietf.org/wg/codec/trac/ticket/29 Memory Usage... http://trac.tools.ietf.org/wg/codec/trac/ticket/22 Joint stereo coding http://trac.tools.ietf.org/wg/codec/trac/ticket/9 Multi-channel frame ordering? http://trac.tools.ietf.org/wg/codec/trac/ticket/10 bit-exact vs. bit-compatible? http://trac.tools.ietf.org/wg/codec/trac/ticket/12 However, I think that there will be consensus on bit-compatible... Also, some other issues have been raised on the a) the codec testing b) the payload/transmission specification c) the charter We should add some more "components" to the ticket system to sort those = issues according to their scope. Christian --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ From oej@edvina.net Mon May 24 08:30:41 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF7733A6813 for ; Mon, 24 May 2010 08:30:40 -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_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zydkvpr2igg6 for ; Mon, 24 May 2010 08:30:38 -0700 (PDT) Received: from smtp6.webway.se (smtp2.webway.se [87.96.134.128]) by core3.amsl.com (Postfix) with ESMTP id F37823A6A82 for ; Mon, 24 May 2010 08:30:37 -0700 (PDT) Received: from [192.168.40.12] (ns.webway.se [87.96.134.125]) by smtp6.webway.se (Postfix) with ESMTPA id BEDAF552E64; Mon, 24 May 2010 15:33:39 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: Date: Mon, 24 May 2010 17:30:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Brian Rosen X-Mailer: Apple Mail (2.1078) Cc: codec@ietf.org Subject: Re: [codec] #14: VAD and CNG? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 15:30:41 -0000 24 maj 2010 kl. 16.48 skrev Brian Rosen: > I hope we are assuming VAD (or DTX) is negotiable. It is essential = (for > emergency calls) that VAD is disabled. While in many cases the = endpoint > will know that it is in an emergency call, and disable VAD, it is not = always > possible to know. Just for curiosity, Brian. Why is it essential for emergency calls to = disable VAD? /O From hoene@uni-tuebingen.de Mon May 24 08:53:12 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 903923A6AD4 for ; Mon, 24 May 2010 08:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.945 X-Spam-Level: X-Spam-Status: No, score=-0.945 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4lEzhdOToI1 for ; Mon, 24 May 2010 08:53:11 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 7D9A93A6AA3 for ; Mon, 24 May 2010 08:53:11 -0700 (PDT) Received: from hoeneT60 ([82.113.121.147]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4OFqqob026989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 24 May 2010 17:53:00 +0200 From: "Christian Hoene" To: Date: Mon, 24 May 2010 17:52:47 +0200 Message-ID: <000001cafb59$2e5e8d10$8b1ba730$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr7UCWVvG5Svlx6n0WnvziJ/5NDvAAAQ96QAACcZScAAVuYMA== Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.242; VDF: 7.10.7.162; host: mx05); id=17691-CgtSZU Subject: [codec] FW: #14: VAD and CNG? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 15:53:12 -0000 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Monday, May 24, 2010 5:13 PM To: Christian Hoene Subject: Re: [codec] #14: VAD and CNG? When you make an emergency call, background is a very important source of information. For example, if the call taker hears someone threaten the caller, that will inform the response. Often the caller is in distress, and may put the phone down, or speak faintly. There are no laws or regulations governing this, but it really is 'best practice'. Brian On 5/24/10 10:57 AM, "Christian Hoene" wrote: >> I hope we are assuming VAD (or DTX) is negotiable. It is essential (for >> emergency calls) that VAD is disabled. > > Hi Brian, > > Any laws somewhere on this requirement? Positioning for emergency call is > required by law in many countries. But I never heard > anything about switching off DTX... > > Christian > > From br@brianrosen.net Mon May 24 08:53:21 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B6163A6B02 for ; Mon, 24 May 2010 08:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.067 X-Spam-Level: X-Spam-Status: No, score=0.067 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qU1hkmA9tAsV for ; Mon, 24 May 2010 08:53:20 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id A91E43A6AA3 for ; Mon, 24 May 2010 08:53:20 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.195]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1OGZxh-00033v-46; Mon, 24 May 2010 10:53:05 -0500 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 24 May 2010 11:53:08 -0400 From: Brian Rosen To: "Olle E. Johansson" Message-ID: Thread-Topic: [codec] #14: VAD and CNG? Thread-Index: Acr7WTQ0TWNTp065pEyGl+SXCIY/gg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: codec@ietf.org Subject: Re: [codec] #14: VAD and CNG? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 15:53:21 -0000 When you make an emergency call, background is a very important source of information. For example, if the call taker hears someone threaten the caller, that will inform the response. Often the caller is in distress, and may put the phone down, or speak faintly. VAD will "zero out" the background sounds. Brian On 5/24/10 11:30 AM, "Olle E. Johansson" wrote: > > 24 maj 2010 kl. 16.48 skrev Brian Rosen: > >> I hope we are assuming VAD (or DTX) is negotiable. It is essential (for >> emergency calls) that VAD is disabled. While in many cases the endpoint >> will know that it is in an emergency call, and disable VAD, it is not always >> possible to know. > > > Just for curiosity, Brian. Why is it essential for emergency calls to disable > VAD? > > /O > > From hoene@uni-tuebingen.de Mon May 24 09:00:40 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0AA83A6B05 for ; Mon, 24 May 2010 09:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.97 X-Spam-Level: X-Spam-Status: No, score=-0.97 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDi4nEfEvbHv for ; Mon, 24 May 2010 09:00:39 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 5EF8C3A6A56 for ; Mon, 24 May 2010 09:00:39 -0700 (PDT) Received: from hoeneT60 ([82.113.121.147]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4OG0GLZ006372 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 May 2010 18:00:24 +0200 From: "Christian Hoene" To: "'Brian Rosen'" , "'Olle E. Johansson'" References: In-Reply-To: Date: Mon, 24 May 2010 18:00:13 +0200 Message-ID: <000101cafb5a$37c5f8b0$a751ea10$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr7WTQ0TWNTp065pEyGl+SXCIY/ggAAB+/w Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] #14: VAD and CNG? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 16:00:40 -0000 Hi Brian, I would say: This is a task of the phone to amplify the signal during an emergency call. Of course, the phone knows that a emergency has been called and that any vague signal can be of importance. It should then switch over to a emergency mode (disabling background-noise removals, changed automatic gain control, etc). This requirement needs not be covered by signaling nor codec. The phone can take care of it much better. Christian >-----Original Message----- >From: Brian Rosen [mailto:br@brianrosen.net] >Sent: Monday, May 24, 2010 5:53 PM >To: Olle E. Johansson >Cc: codec@ietf.org; hoene@uni-tuebingen.de >Subject: Re: [codec] #14: VAD and CNG? > >When you make an emergency call, background is a very important source of >information. For example, if the call taker hears someone threaten the >caller, that will inform the response. Often the caller is in distress, and >may put the phone down, or speak faintly. VAD will "zero out" the >background sounds. > >Brian > > >On 5/24/10 11:30 AM, "Olle E. Johansson" wrote: > >> >> 24 maj 2010 kl. 16.48 skrev Brian Rosen: >> >>> I hope we are assuming VAD (or DTX) is negotiable. It is essential (for >>> emergency calls) that VAD is disabled. While in many cases the endpoint >>> will know that it is in an emergency call, and disable VAD, it is not always >>> possible to know. >> >> >> Just for curiosity, Brian. Why is it essential for emergency calls to disable >> VAD? >> >> /O >> >> From mknappe@juniper.net Mon May 24 09:09:54 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57D8E3A6C50 for ; Mon, 24 May 2010 09:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.011 X-Spam-Level: X-Spam-Status: No, score=-4.011 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_50=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4WhtPuhVACW for ; Mon, 24 May 2010 09:09:52 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 21D053A6B33 for ; Mon, 24 May 2010 09:09:31 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKS/qkiFvjXnAjrsQ5Ba+ghG4j6D9o236M@postini.com; Mon, 24 May 2010 09:09:45 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 24 May 2010 09:06:01 -0700 From: Michael Knappe To: Brian Rosen , "codec@ietf.org" , "hoene@uni-tuebingen.de" Date: Mon, 24 May 2010 09:05:59 -0700 Thread-Topic: [codec] #14: VAD and CNG? Thread-Index: Acr7UCWVvG5Svlx6n0WnvziJ/5NDvAACtovz Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] #14: VAD and CNG? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 16:09:54 -0000 I agree that VAD (or DTX) needs to be negotiable. Mike On 5/24/10 7:48 AM, "Brian Rosen" wrote: > I hope we are assuming VAD (or DTX) is negotiable. It is essential (for > emergency calls) that VAD is disabled. While in many cases the endpoint > will know that it is in an emergency call, and disable VAD, it is not alw= ays > possible to know. >=20 > Brian >=20 >=20 > On 5/24/10 10:22 AM, "codec issue tracker" wrote: >=20 >> #14: VAD and=20 >> CNG? > ------------------------------------+------------------------------------ >> --- > Reporter: hoene@=A9 | Owner: > Type: defect >> | Status: new > Priority: major | Milestone: >>=20 > Component: requirements | Version: > Severity: - >> | Keywords: =20 >>=20 > ------------------------------------+------------------------------------= --- >=20 >>=20 > Comment(by hoene@=A9): >=20 > [Raymond]: I think comfort noise is more than just to >> let the telephone > user know that the connection is not dead. If voice >> packets are sent only > during active voice regions of the signal (in DTX) and >> not during > silence/background noise regions, and if there is audible >> background noise > and comfort noise is not added during background noise >> regions, at the > receiving end the background noise will be "on" only during >> active voice > and "off" otherwise. This frequent on-off switching will make >> the > background noise sound unnatural and will bother many users. Adding >=20 >> comfort noise during background noise regions will make such background > noise >> sound more natural. >=20 > [Benjamin]: The cheapest solution, of course, is >> transmit-side activity > detection. > Maybe we need to specify a way for a >> receiver to request that the > transmitter employ (or not employ) VAD. >=20 >=20 >=20 >> [Benjamin]: > I know that CELT makes decoder VAD very efficient, but how is >> decoder VAD > better than encoder VAD? Encoder VAD saves even more CPU, saves >=20 >> bandwidth, and enables easier jitter buffering. > Are you thinking about some >> sort of adaptive thresholding that requires > knowing all streams' volume >> levels? > Anyway, VAD can run on both encode and decode sides at the same >> time. >=20 >=20 > [Stephen]: It might be valuable to be able to obtain the VAD without >=20 >> having to decrypt the bitstream, since that also can become a problem as > the >> number of streams grows. > There is a security consideration (traffic >> analysis), however, it still > might be worth thinking about. >=20 > [JM]: >> I know >> that CELT makes decoder VAD very efficient, > Not only CELT. You can do that >> with an LPC-based codec too. >=20 >> but how is decoder VAD >> better than encoder >> VAD? Encoder VAD saves even more CPU, saves >> bandwidth, and enables easier >> jitter buffering. >=20 > There's a few reasons why I think decoder-side is better: >=20 >> - The decision for an encoder-size VAD would take some amount of space i= n the >> bit-stream > - If we make an encode-size VAD mandatory, then all encoders will >> have to > spend the CPU cycles, even when it's not needed. If it's not >> mandatory, > then the decoder cannot rely on it, so it still needs to implement >> a VAD > - A decoder VAD does not need to be specified in an exact way, so >=20 >> implementers can choose different implementations depending on that >=20 >> information they need. > - You cannot "game" a decode-size VAD. >=20 >> Are you >> thinking about some sort of adaptive thresholding that >> requires knowing all >> streams' volume levels? >=20 > Well, knowing the relative amplitudes of each stream >> can allow you to take > more intelligent decisions, e.g. when you have to >> choose the "most active > speaker". That's something you can't really get from >> an encoder VAD. >=20 >> Anyway, VAD can run on both encode and decode sides at the >> same time. >=20 > That would just mean nobody would bother implementing the encode >> side. >=20 >=20 > [Benjamin]: >=20 > I think I failed to communicate that by VAD I mean _not >> sending packets_ > during inactivity. For the packets that are sent, the >> overhead should > average much less than 1 bit per frame. >=20 > I'm not suggesting >> sending 200 packets a second containing a flag > indicating no voice activity, >> followed by carefully coded background > noise. That would be silly. >=20 >> - If >> we make an encode-size VAD mandatory, then all encoders will have >> to spend >> the CPU cycles, even when it's not needed. If it's not >> mandatory, then the >> decoder cannot rely on it, so it still needs to >> implement a VAD >=20 > I don't >> see this as "mandatory". The encoder can turn off VAD, and > probably should >> for full-quality applications. >=20 >> - A decoder VAD does not need to be >> specified in an exact way, so >> implementers can choose different >> implementations depending on that >> information they need. >=20 > The only thing >> that needs exact specification is the signalling. The > encoder may use it or >> not use it as it pleases. >=20 >> - You cannot "game" a decode-size VAD. >=20 > I don't >> know what this means. >=20 >>> Are you thinking about some sort of adaptive >> thresholding that >>> requires knowing all streams' volume levels? >>=20 >> Well, >> knowing the relative amplitudes of each stream can allow you to >> take more >> intelligent decisions, e.g. when you have to choose the >> "most active >> speaker". That's something you can't really get from an > encoder VAD. >>=20 >>>=20 >> Anyway, VAD can run on both encode and decode sides at the same time. >>=20 >>=20 >> That would just mean nobody would bother implementing the encode side. >=20 > I >> expect encode-side VAD on a conference call to save more than a factor > of 2 >> in bandwidth, which makes it very desirable, especially for large >=20 >> deployments. People will use it to save bandwidth (especially if it's o= n by >> default in the reference implementation). The decode-side CPU savings > are >> just a minor bonus side-effect. >=20 > [JM]: > What you're describing is called DTX >> (discontinuous transmission). This > can be useful feature, but it's very >> different from what we were > originally talking about in terms of conference >> mixing. >=20 > [Ben]: Oops. Right. What I'm trying to say is that DTX, based on >> encoder- > side VAD, also greatly reduces the (average) computational burden on >> a > conference mixer. Of course, if everyone's really talking at once then >=20 >> VAD can't help. >=20 > [Roman]: There is one more application to efficiently >> combining pre- > encoded > audio: playing announcements or recorded audio. >> Standard network or IVR > announcements can be encoded once and efficiently >> inserted or combined > into audio stream. If pre-encoded audio is supported and >> the client > supports AVT tones, it is trivial to develop a very efficient IVR >> server > which does not require any CODEC encoding or decoding. >=20 > Efficient >> decoder side VAD is also very helpful in case of speech > recognition, where it >> allows to save cycles in end-pointer. This way audio > only needs to be decoded >> and passed to the speech recognition system only > when voice is present. >=20 >=20 >> Bottom line, if we have both efficient decoder side VAD and combining pr= e- >=20 >> encoded audio we can develop some very efficient VXML servers, voice mai= l and >> IVR system, not just conferencing servers. >=20 > Of course, this works well only >> if the background noise is relatively > stationary. If the background noise is >> dynamically changing, then comfort > noise can't really sound like the true >> background noise. Today I was put > on hold in a phone call with music >> playing. Apparently the system treated > some parts of the music as background >> noise and replaced them with comfort > noise. The result is pretty annoying, or >> amusing, depending on which way > you look at it. >=20 > Therefore, I think comfort >> noise has its value if DTX is used and the > background noise is fairly >> stationary, but if the background noise or > music is changing dynamically and >> high audio quality is desired, then the > DTX and comfort noise should be >> turned off and all parts of the signal > need to be transmitted. From mknappe@juniper.net Mon May 24 09:12:15 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A382A3A6C4D for ; Mon, 24 May 2010 09:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.626 X-Spam-Level: X-Spam-Status: No, score=-4.626 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XaSCfxKhLOQ for ; Mon, 24 May 2010 09:12:14 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 51DCA3A6C2C for ; Mon, 24 May 2010 09:12:14 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKS/qlQd9kHg7nTM860CFB18uBlx/TRJUQ@postini.com; Mon, 24 May 2010 09:12:07 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 24 May 2010 09:09:45 -0700 From: Michael Knappe To: Brian Rosen , "Olle E. Johansson" Date: Mon, 24 May 2010 09:09:43 -0700 Thread-Topic: [codec] #14: VAD and CNG? Thread-Index: Acr7WTQ0TWNTp065pEyGl+SXCIY/ggAAlESK Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] #14: VAD and CNG? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 16:12:15 -0000 Not to mention any possibility of chopping off a portion of a syllable here or there... Mike On 5/24/10 8:53 AM, "Brian Rosen" wrote: > When you make an emergency call, background is a very important source of > information. For example, if the call taker hears someone threaten the > caller, that will inform the response. Often the caller is in distress, = and > may put the phone down, or speak faintly. VAD will "zero out" the > background sounds. >=20 > Brian >=20 >=20 > On 5/24/10 11:30 AM, "Olle E. Johansson" wrote: >=20 >>=20 >> 24 maj 2010 kl. 16.48 skrev Brian Rosen: >>=20 >>> I hope we are assuming VAD (or DTX) is negotiable. It is essential (fo= r >>> emergency calls) that VAD is disabled. While in many cases the endpoin= t >>> will know that it is in an emergency call, and disable VAD, it is not a= lways >>> possible to know. >>=20 >>=20 >> Just for curiosity, Brian. Why is it essential for emergency calls to di= sable >> VAD? >>=20 >> /O >>=20 >>=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From kpfleming@digium.com Mon May 24 09:12:30 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD8043A6C2C for ; Mon, 24 May 2010 09:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.354 X-Spam-Level: X-Spam-Status: No, score=-104.354 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6f7a9PebSA5 for ; Mon, 24 May 2010 09:12:27 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id B0D3D3A6C41 for ; Mon, 24 May 2010 09:12:27 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1OGaGI-0000GT-Rh for codec@ietf.org; Mon, 24 May 2010 11:12:18 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id BEF08D8025 for ; Mon, 24 May 2010 11:12:18 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRncTkde0EOS for ; Mon, 24 May 2010 11:12:18 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 6EDB6D8023 for ; Mon, 24 May 2010 11:12:18 -0500 (CDT) Message-ID: <4BFAA562.1040007@digium.com> Date: Mon, 24 May 2010 11:12:18 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: codec@ietf.org References: <003301cafb4f$595f0cb0$0c1d2610$@de> In-Reply-To: <003301cafb4f$595f0cb0$0c1d2610$@de> X-Enigmail-Version: 1.0.1 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [codec] Summary of last two weeks X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 16:12:31 -0000 On 05/24/2010 09:42 AM, Christian Hoene wrote: > - The need for a low complexity mode was stated (e.g. 10-20 MIPS), which must not support all audio qualities. No clear consensus on > this issue yet... > - Which is the complexity of the low complexity mode? > - How to measure the complexity? s/must not/is not required to/. If the low complexity mode *can* support all audio qualities (given some other compromises), there's no reason not to allow it to do so. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From hoene@uni-tuebingen.de Mon May 24 09:31:40 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6CFA3A6C5F for ; Mon, 24 May 2010 09:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=1.383, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxHkMlMVhh3T for ; Mon, 24 May 2010 09:31:39 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id A5BD73A6C8D for ; Mon, 24 May 2010 09:31:24 -0700 (PDT) Received: from hoeneT60 ([82.113.121.147]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4OGV217029716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 May 2010 18:31:12 +0200 From: "Christian Hoene" To: "'Kevin P. Fleming'" , References: <003301cafb4f$595f0cb0$0c1d2610$@de> <4BFAA562.1040007@digium.com> In-Reply-To: <4BFAA562.1040007@digium.com> Date: Mon, 24 May 2010 18:30:56 +0200 Message-ID: <000501cafb5e$843ba740$8cb2f5c0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr7W+9eoC8rpMjBQy2UO+aX10ynVwAAm9Og Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.242; VDF: 7.10.7.162; host: mx05); id=17691-KapBc5 Subject: Re: [codec] Summary of last two weeks X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 16:31:40 -0000 >s/must not/is not required to/. If the low complexity mode *can* support >all audio qualities (given some other compromises), there's no reason >not to allow it to do so. Ja, you are right. Auf Wiedersehen. Herr Hoene From bmschwar@fas.harvard.edu Mon May 24 09:54:23 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBE153A6C63 for ; Mon, 24 May 2010 09:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.37 X-Spam-Level: X-Spam-Status: No, score=-4.37 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnX1tlY9-9Fe for ; Mon, 24 May 2010 09:54:22 -0700 (PDT) Received: from us26.unix.fas.harvard.edu (us26.unix.fas.harvard.edu [140.247.35.202]) by core3.amsl.com (Postfix) with ESMTP id 77F6D3A6C44 for ; Mon, 24 May 2010 09:54:22 -0700 (PDT) Received: from us26.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us26.unix.fas.harvard.edu (Postfix) with ESMTP id 855381F7388; Mon, 24 May 2010 12:54:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; s=mail; bh=+8E3nmUjb8nL6To jLoBoOQyrqc0q0yRWOxHbPqrVMjA=; b=vn0c8R2hkIBl7rrNPmNtkyc1CR+864x VZIEl1sj6Ot2yTuchHS//c1L6krtOCYDmD2Mmu9mHb2LJu5lVS3DZyWwpPdQBiXx un+jG8KnyQrRMYAqktoniG9D3fu+ORBo6Nq96F5uw5GlrRwBHGprAddjOgO7wO4a nsjOVCuRTng8= DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; q=dns; s=mail; b=qvzJ3Js1r wUzm2u3W/W8+gO4xgOP/U2YE74o7s0LWTU6QCElmRSKjgcg5qPnm0LDaeg3wMnVx ae078psamDFy0Kk5Kx5wxFSqHs2YPJJstha0nJSGked6g/Z3wghOu38fGxrp6CM8 ZT5BcVM4GvIhLU59twXEtwkwKIjtoO8OVA= Received: from [172.23.141.149] (bwhmaincampuspat25.partners.org [170.223.207.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us26.unix.fas.harvard.edu (Postfix) with ESMTPSA id 807331F7375; Mon, 24 May 2010 12:54:13 -0400 (EDT) Message-ID: <4BFAAF34.202@fas.harvard.edu> Date: Mon, 24 May 2010 12:54:12 -0400 From: "Benjamin M. Schwartz" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Michael Knappe References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5C2DEF1A4D23CED2D23CD005" Cc: "codec@ietf.org" Subject: Re: [codec] #14: VAD and CNG? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bens@alum.mit.edu List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 16:54:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5C2DEF1A4D23CED2D23CD005 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable On 05/24/2010 12:05 PM, Michael Knappe wrote: > I agree that VAD (or DTX) needs to be negotiable. Me too. Specifically, I think that DTX should always be allowed within any stream. The decoder always MUST correctly decode a stream with or without DTX, and the encoder SHOULD obey the decoder's preference for or against DTX, as expressed in SDP, unless there is a reason not to obey this preference. Decoders MAY express no preference. In particular, decoders must handle adaptive jitter buffering properly with or without DTX. Examples: An encoder operating with push-to-talk hardware (microphone active only when a button is depressed) should always use DTX, regardless of decoder preference. A decoder that cares about average bandwidth should probably request DTX enabled, whereas a decoder that cares only about peak bandwidth should request DTX disabled. A decoder that cares about non-voice background sounds should request DTX= disabled. --Ben --------------enig5C2DEF1A4D23CED2D23CD005 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkv6rzUACgkQUJT6e6HFtqTU3wCdG4T9dLn/s0P6CZZ/Il1EmQeF hTUAnRqRqAzsWe/4s+MaL6P9rEc5EC7l =cht5 -----END PGP SIGNATURE----- --------------enig5C2DEF1A4D23CED2D23CD005-- From hoene@uni-tuebingen.de Mon May 24 09:55:55 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 502BE3A6C51 for ; Mon, 24 May 2010 09:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.886, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-w+SUk9qwMx for ; Mon, 24 May 2010 09:55:54 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 77EDD3A6C44 for ; Mon, 24 May 2010 09:55:53 -0700 (PDT) Received: from hoeneT60 ([82.113.121.147]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4OGtWm4009646 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 May 2010 18:55:40 +0200 From: "Christian Hoene" To: "'Michael Knappe'" , "'Brian Rosen'" , References: In-Reply-To: Date: Mon, 24 May 2010 18:55:28 +0200 Message-ID: <000f01cafb61$efe237e0$cfa6a7a0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr7UCWVvG5Svlx6n0WnvziJ/5NDvAACtovzAAFh2jA= Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Subject: Re: [codec] #14: VAD and CNG? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 16:55:55 -0000 Hello, I do not like the idea that a user should decide on parameters that he = does not understand. Can't we develop some intelligent, automatic decision on when to use = DTX? For example, switch VAD on if a) if bandwidth is limited (dynamically controlled) b) if transmission energy needs to be saved on mobile devices = (controlled/negotiated for both sender and receiver) c) if a lot of background noise is present (sender initiated, no = negotiation required) d) if the background noise is important (sender initiated, e.g. = emergency call, but then again, the sender can amplify the background noise instead) Shall the controlling/negotiation take place in-band or using SDP? With best regards, Christian --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ >-----Original Message----- >From: Michael Knappe [mailto:mknappe@juniper.net] >Sent: Monday, May 24, 2010 6:06 PM >To: Brian Rosen; codec@ietf.org; hoene@uni-tuebingen.de >Subject: Re: [codec] #14: VAD and CNG? > >I agree that VAD (or DTX) needs to be negotiable. > >Mike > > >On 5/24/10 7:48 AM, "Brian Rosen" wrote: > >> I hope we are assuming VAD (or DTX) is negotiable. It is essential = (for >> emergency calls) that VAD is disabled. While in many cases the = endpoint >> will know that it is in an emergency call, and disable VAD, it is not = always >> possible to know. >> >> Brian >> >> >> On 5/24/10 10:22 AM, "codec issue tracker" = wrote: >> >>> #14: VAD and >>> CNG? >> = ------------------------------------+------------------------------------= >>> --- >> Reporter: hoene@=A9 | Owner: >> Type: defect >>> | Status: new >> Priority: major | Milestone: >>> >> Component: requirements | Version: >> Severity: - >>> | Keywords: >>> >> = ------------------------------------+------------------------------------= --- >> >>> >> Comment(by hoene@=A9): >> >> [Raymond]: I think comfort noise is more than just to >>> let the telephone >> user know that the connection is not dead. If voice >>> packets are sent only >> during active voice regions of the signal (in DTX) and >>> not during >> silence/background noise regions, and if there is audible >>> background noise >> and comfort noise is not added during background noise >>> regions, at the >> receiving end the background noise will be "on" only during >>> active voice >> and "off" otherwise. This frequent on-off switching will make >>> the >> background noise sound unnatural and will bother many users. Adding >> >>> comfort noise during background noise regions will make such = background >> noise >>> sound more natural. >> >> [Benjamin]: The cheapest solution, of course, is >>> transmit-side activity >> detection. >> Maybe we need to specify a way for a >>> receiver to request that the >> transmitter employ (or not employ) VAD. >> >> >> >>> [Benjamin]: >> I know that CELT makes decoder VAD very efficient, but how is >>> decoder VAD >> better than encoder VAD? Encoder VAD saves even more CPU, saves >> >>> bandwidth, and enables easier jitter buffering. >> Are you thinking about some >>> sort of adaptive thresholding that requires >> knowing all streams' volume >>> levels? >> Anyway, VAD can run on both encode and decode sides at the same >>> time. >> >> >> [Stephen]: It might be valuable to be able to obtain the VAD without >> >>> having to decrypt the bitstream, since that also can become a = problem as >> the >>> number of streams grows. >> There is a security consideration (traffic >>> analysis), however, it still >> might be worth thinking about. >> >> [JM]: >>> I know >>> that CELT makes decoder VAD very efficient, >> Not only CELT. You can do that >>> with an LPC-based codec too. >> >>> but how is decoder VAD >>> better than encoder >>> VAD? Encoder VAD saves even more CPU, saves >>> bandwidth, and enables easier >>> jitter buffering. >> >> There's a few reasons why I think decoder-side is better: >> >>> - The decision for an encoder-size VAD would take some amount of = space in the >>> bit-stream >> - If we make an encode-size VAD mandatory, then all encoders will >>> have to >> spend the CPU cycles, even when it's not needed. If it's not >>> mandatory, >> then the decoder cannot rely on it, so it still needs to implement >>> a VAD >> - A decoder VAD does not need to be specified in an exact way, so >> >>> implementers can choose different implementations depending on that >> >>> information they need. >> - You cannot "game" a decode-size VAD. >> >>> Are you >>> thinking about some sort of adaptive thresholding that >>> requires knowing all >>> streams' volume levels? >> >> Well, knowing the relative amplitudes of each stream >>> can allow you to take >> more intelligent decisions, e.g. when you have to >>> choose the "most active >> speaker". That's something you can't really get from >>> an encoder VAD. >> >>> Anyway, VAD can run on both encode and decode sides at the >>> same time. >> >> That would just mean nobody would bother implementing the encode >>> side. >> >> >> [Benjamin]: >> >> I think I failed to communicate that by VAD I mean _not >>> sending packets_ >> during inactivity. For the packets that are sent, the >>> overhead should >> average much less than 1 bit per frame. >> >> I'm not suggesting >>> sending 200 packets a second containing a flag >> indicating no voice activity, >>> followed by carefully coded background >> noise. That would be silly. >> >>> - If >>> we make an encode-size VAD mandatory, then all encoders will have >>> to spend >>> the CPU cycles, even when it's not needed. If it's not >>> mandatory, then the >>> decoder cannot rely on it, so it still needs to >>> implement a VAD >> >> I don't >>> see this as "mandatory". The encoder can turn off VAD, and >> probably should >>> for full-quality applications. >> >>> - A decoder VAD does not need to be >>> specified in an exact way, so >>> implementers can choose different >>> implementations depending on that >>> information they need. >> >> The only thing >>> that needs exact specification is the signalling. The >> encoder may use it or >>> not use it as it pleases. >> >>> - You cannot "game" a decode-size VAD. >> >> I don't >>> know what this means. >> >>>> Are you thinking about some sort of adaptive >>> thresholding that >>>> requires knowing all streams' volume levels? >>> >>> Well, >>> knowing the relative amplitudes of each stream can allow you to >>> take more >>> intelligent decisions, e.g. when you have to choose the >>> "most active >>> speaker". That's something you can't really get from an >> encoder VAD. >>> >>>> >>> Anyway, VAD can run on both encode and decode sides at the same = time. >>> >>> >>> That would just mean nobody would bother implementing the encode = side. >> >> I >>> expect encode-side VAD on a conference call to save more than a = factor >> of 2 >>> in bandwidth, which makes it very desirable, especially for large >> >>> deployments. People will use it to save bandwidth (especially if = it's on by >>> default in the reference implementation). The decode-side CPU = savings >> are >>> just a minor bonus side-effect. >> >> [JM]: >> What you're describing is called DTX >>> (discontinuous transmission). This >> can be useful feature, but it's very >>> different from what we were >> originally talking about in terms of conference >>> mixing. >> >> [Ben]: Oops. Right. What I'm trying to say is that DTX, based on >>> encoder- >> side VAD, also greatly reduces the (average) computational burden on >>> a >> conference mixer. Of course, if everyone's really talking at once = then >> >>> VAD can't help. >> >> [Roman]: There is one more application to efficiently >>> combining pre- >> encoded >> audio: playing announcements or recorded audio. >>> Standard network or IVR >> announcements can be encoded once and efficiently >>> inserted or combined >> into audio stream. If pre-encoded audio is supported and >>> the client >> supports AVT tones, it is trivial to develop a very efficient IVR >>> server >> which does not require any CODEC encoding or decoding. >> >> Efficient >>> decoder side VAD is also very helpful in case of speech >> recognition, where it >>> allows to save cycles in end-pointer. This way audio >> only needs to be decoded >>> and passed to the speech recognition system only >> when voice is present. >> >> >>> Bottom line, if we have both efficient decoder side VAD and = combining pre- >> >>> encoded audio we can develop some very efficient VXML servers, voice = mail and >>> IVR system, not just conferencing servers. >> >> Of course, this works well only >>> if the background noise is relatively >> stationary. If the background noise is >>> dynamically changing, then comfort >> noise can't really sound like the true >>> background noise. Today I was put >> on hold in a phone call with music >>> playing. Apparently the system treated >> some parts of the music as background >>> noise and replaced them with comfort >> noise. The result is pretty annoying, or >>> amusing, depending on which way >> you look at it. >> >> Therefore, I think comfort >>> noise has its value if DTX is used and the >> background noise is fairly >>> stationary, but if the background noise or >> music is changing dynamically and >>> high audio quality is desired, then the >> DTX and comfort noise should be >>> turned off and all parts of the signal >> need to be transmitted. From br@brianrosen.net Mon May 24 10:01:21 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FE5B3A6D96 for ; Mon, 24 May 2010 10:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.078 X-Spam-Level: X-Spam-Status: No, score=0.078 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXQl2ck2iDEi for ; Mon, 24 May 2010 10:01:20 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id E68883A6C5E for ; Mon, 24 May 2010 10:01:19 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.195]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1OGb1R-0000e3-Ac; Mon, 24 May 2010 12:01:01 -0500 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 24 May 2010 13:01:04 -0400 From: Brian Rosen To: Christian Hoene , "'Olle E. Johansson'" Message-ID: Thread-Topic: [codec] #14: VAD and CNG? Thread-Index: Acr7WTQ0TWNTp065pEyGl+SXCIY/ggAAB+/wAAJXcJI= In-Reply-To: <000101cafb5a$37c5f8b0$a751ea10$@de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: codec@ietf.org Subject: Re: [codec] #14: VAD and CNG? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 17:01:21 -0000 I'll be happy to go into the details, but phones may not know they are in an emergency call. No phone knows this today. There is some proposed signaling that would tell them, IF the phone, and the service provider implement it, but even then, there are circumstances where the phone won't know. Brian On 5/24/10 12:00 PM, "Christian Hoene" wrote: > Hi Brian, > > I would say: This is a task of the phone to amplify the signal during an > emergency call. Of course, the phone knows that a emergency > has been called and that any vague signal can be of importance. It should then > switch over to a emergency mode (disabling > background-noise removals, changed automatic gain control, etc). > > This requirement needs not be covered by signaling nor codec. The phone can > take care of it much better. > > Christian > > >> -----Original Message----- >> From: Brian Rosen [mailto:br@brianrosen.net] >> Sent: Monday, May 24, 2010 5:53 PM >> To: Olle E. Johansson >> Cc: codec@ietf.org; hoene@uni-tuebingen.de >> Subject: Re: [codec] #14: VAD and CNG? >> >> When you make an emergency call, background is a very important source of >> information. For example, if the call taker hears someone threaten the >> caller, that will inform the response. Often the caller is in distress, and >> may put the phone down, or speak faintly. VAD will "zero out" the >> background sounds. >> >> Brian >> >> >> On 5/24/10 11:30 AM, "Olle E. Johansson" wrote: >> >>> >>> 24 maj 2010 kl. 16.48 skrev Brian Rosen: >>> >>>> I hope we are assuming VAD (or DTX) is negotiable. It is essential (for >>>> emergency calls) that VAD is disabled. While in many cases the endpoint >>>> will know that it is in an emergency call, and disable VAD, it is not >>>> always >>>> possible to know. >>> >>> >>> Just for curiosity, Brian. Why is it essential for emergency calls to >>> disable >>> VAD? >>> >>> /O >>> >>> > > From bmschwar@fas.harvard.edu Mon May 24 10:24:24 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D7453A6D18 for ; Mon, 24 May 2010 10:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.633 X-Spam-Level: X-Spam-Status: No, score=-5.633 tagged_above=-999 required=5 tests=[AWL=0.966, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVtU+ClcBvS2 for ; Mon, 24 May 2010 10:24:23 -0700 (PDT) Received: from us17.unix.fas.harvard.edu (us17.unix.fas.harvard.edu [140.247.35.197]) by core3.amsl.com (Postfix) with ESMTP id 3EF923A6CE6 for ; Mon, 24 May 2010 10:24:23 -0700 (PDT) Received: from us17.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us17.unix.fas.harvard.edu (Postfix) with ESMTP id BDB6041E161; Mon, 24 May 2010 13:24:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; s=mail; bh=E5DLsKxBI1yFkhI 4L3UtG6e1ULI3ycVx9LFsXJ3yLu4=; b=tniUmaky3eaAwSLhlZRC8cyUFEWSiFm 0e+Lb7eLijNO8Z07XutYgiHr/m2uAlKj2gZijuGVVLTbiB2tdocdqtEEnNiG8Cxl 5WxskZrdxHxVP0pdEwayhQb1UkPYVPSKwhQKmEAuKbHw7L9D6flfeZAOCyw9pKMM jPXn593EWmSg= DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; q=dns; s=mail; b=nFJ2MvOw6 YLSX1FeFQqfsiXTv0UKYjxbFxZ/AVo59ELRnRVqGVsS+qkohRzl8JQBO+O8g9Y1T ZAGnB1OrBzOogBtTJEPdTBafInM9HmijyTr8oRhBYs7HrdUfSbPEvVpuF78lanBz jcd968SXgN4PyGPAsSXUMNTdAT0hM810Cg= Received: from [172.23.141.149] (bwhmaincampuspat25.partners.org [170.223.207.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us17.unix.fas.harvard.edu (Postfix) with ESMTPSA id B895941E0CF; Mon, 24 May 2010 13:24:14 -0400 (EDT) Message-ID: <4BFAB63E.3090408@fas.harvard.edu> Date: Mon, 24 May 2010 13:24:14 -0400 From: "Benjamin M. Schwartz" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: Christian Hoene References: <000f01cafb61$efe237e0$cfa6a7a0$@de> In-Reply-To: <000f01cafb61$efe237e0$cfa6a7a0$@de> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0A63B575E3324E7C57E7C40A" Cc: codec@ietf.org Subject: Re: [codec] #14: VAD and CNG? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bens@alum.mit.edu List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 17:24:24 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0A63B575E3324E7C57E7C40A Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable On 05/24/2010 12:55 PM, Christian Hoene wrote: > I do not like the idea that a user should decide on parameters that he = does not understand. In general, parameters for bitrate, jitter buffer, sample rate, filtering= , and AEC are not exposed to the user. They are typically managed accordin= g to some customized algorithm designed for the hardware, network, and application. DTX is just one more of these settings, and would be no mor= e likely to be exposed to the user. We don't need to worry about the user interface, because in most cases there won't be one. I think it's a good idea for the reference implementation to provide some= intelligent heuristics for use of DTX, but these heuristics should not be= a requirement of any RFC. --Ben --------------enig0A63B575E3324E7C57E7C40A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkv6tj4ACgkQUJT6e6HFtqSG3ACfTbj9hsFf8T7tPUIOWHnz7SGc XUcAnRXM5Hp6H57xnLMo5jlxYs0xNcGz =Kqkq -----END PGP SIGNATURE----- --------------enig0A63B575E3324E7C57E7C40A-- From roman@telurix.com Mon May 24 10:28:25 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBB593A6C64 for ; Mon, 24 May 2010 10:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.069 X-Spam-Level: X-Spam-Status: No, score=0.069 tagged_above=-999 required=5 tests=[AWL=-1.154, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnR0QnyOtFSu for ; Mon, 24 May 2010 10:28:25 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id C759B3A6B47 for ; Mon, 24 May 2010 10:28:24 -0700 (PDT) Received: by vws14 with SMTP id 14so503029vws.31 for ; Mon, 24 May 2010 10:28:11 -0700 (PDT) Received: by 10.220.62.75 with SMTP id w11mr3941989vch.273.1274722090386; Mon, 24 May 2010 10:28:10 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx.google.com with ESMTPS id w29sm19917282vcr.2.2010.05.24.10.28.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 May 2010 10:28:08 -0700 (PDT) Received: by qyk11 with SMTP id 11so6100876qyk.13 for ; Mon, 24 May 2010 10:28:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.17.196 with SMTP id t4mr3207111qaa.254.1274722085608; Mon, 24 May 2010 10:28:05 -0700 (PDT) Received: by 10.150.186.7 with HTTP; Mon, 24 May 2010 10:28:05 -0700 (PDT) In-Reply-To: <071.ec17032c829ac2dce0dbc4374c8280b6@tools.ietf.org> References: <062.bc75a3b3c4a980df34535f87c9484935@tools.ietf.org> <071.ec17032c829ac2dce0dbc4374c8280b6@tools.ietf.org> Date: Mon, 24 May 2010 13:28:05 -0400 Message-ID: From: Roman Shpount To: codec@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [codec] #15: Efficiently combine pre-encoded audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 17:28:25 -0000 I would like to remind that this issue is not about efficient VAD, but about efficiently combining pre-encoded streams. There are two use cases that I can think of: a. Conference servers, where the active speaker was determined by either receiver or decoder side VAD. As it was mentioned before, it is possible to implement an efficient decoder side VAD without implementing a complete decoder. If we can combine pre-encoded audio we can combine multiple streams on the conference server without going through decoder/encoder cycle greatly decreasing both CPU requirements and mixer delay. b. Announcement and IVR servers, where a small set of pre-encoded announcements are played to the user. Standard network or IVR announcements can be encoded once and efficiently inserted or combined into audio stream. If pre-encoded audio is supported and the client supports AVT tones, it is trivial to develop a very efficient IVR server which does not require any CODEC encoding or decoding. _____________ Roman Shpount On Mon, May 24, 2010 at 10:22 AM, codec issue tracker wrote: > #15: Efficiently combine pre-encoded audio > ------------------------------------+------------------------------------= --- > =A0Reporter: =A0hoene@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 O= wner: > =A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status:= =A0new > =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone= : > Component: =A0requirements =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version: > =A0Severity: =A0Active WG Document =A0 =A0 =A0| =A0 =A0Keywords: > ------------------------------------+------------------------------------= --- > > Comment(by hoene@=85): > > =A0[Cullen]: > =A0For conference bridges, it's probably more important to be able to dec= ide > =A0who the active speakers are with low CPU complexity than the actually = act > =A0of mixing the the selected speakers. Consider a typical call with 7 pe= ople > =A0who might be speakers and =A0the 3 most active are selected and mixed.= In > =A0many systems today, most the MIPS goes to decoding all 7 streams to do > =A0speaker detection before the resulting 4 streams are formed and encode= d. > =A0If there was a cheap way to figure out who the active speakers were > =A0without doing a full decode of all 7 streams, that would be sort of ni= ce > =A0the for conferences bridges. > > =A0[Brian]: Excellent idea. =A0Been there, never really did it. =A0It's c= omplex. > =A0Effectively, you need a distributed adaptive threshold mechanism. > =A0However, if you had it, user experience in multispeaker environments g= ets > =A0a win. > > =A0[Benjamin]: =A0The cheapest solution, of course, is transmit-side acti= vity > =A0detection. > =A0Maybe we need to specify a way for a receiver to request that the > =A0transmitter employ (or not employ) VAD. > > =A0[JM]: > =A0I think you can do better than an encoder VAD. All you need to do is m= ake > =A0sure that the relevant information you need for a VAD can easily be > =A0decoded from the bit-stream without having to do a full decoding. For > =A0example, if you're able to easily extract the gain and spectral envelo= pe, > =A0you can do a VAD based on that without even having to look at the othe= r > =A0parameters in the bit-stream. > > =A0[Brian]: > =A0The adaptive threshold doesn't have to be distributed, as the conferen= ce > =A0bridge is selecting the highest scores. > =A0You do need a consistent way to compute the scores in the endpoints, > =A0ideally using a method which is not simply energy. > =A0I realize the bridge can alternatively generate scores from bitstream > =A0information; I am thinking that is equivalent to including a metric in= the > =A0RTP payload. > > -- > Ticket URL: > codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From hoene@uni-tuebingen.de Mon May 24 10:37:38 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92BC53A6BC8 for ; Mon, 24 May 2010 10:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 tagged_above=-999 required=5 tests=[AWL=0.330, BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWvv7vwGAbSe for ; Mon, 24 May 2010 10:37:37 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id D34F63A6B03 for ; Mon, 24 May 2010 10:37:36 -0700 (PDT) Received: from hoeneT60 ([82.113.121.147]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4OHbFSM001345 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 May 2010 19:37:23 +0200 From: "Christian Hoene" To: "'Brian Rosen'" References: <000101cafb5a$37c5f8b0$a751ea10$@de> In-Reply-To: Date: Mon, 24 May 2010 19:37:11 +0200 Message-ID: <002301cafb67$c3dc5300$4b94f900$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr7WTQ0TWNTp065pEyGl+SXCIY/ggAAB+/wAAJXcJIAAQwYkA== Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.242; VDF: 7.10.7.163; host: mx05); id=17691-KoC1vn Cc: codec@ietf.org Subject: Re: [codec] #14: VAD and CNG? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 17:37:38 -0000 Hi Brian, >I'll be happy to go into the details, but phones may not know they are in an >emergency call. No phone knows this today. There is some proposed >signaling that would tell them, IF the phone, and the service provider >implement it, but even then, there are circumstances where the phone won't >know. If(called.number==112 || called.number==911 || called.number=XYZ) EmergencyCall(); See more at http://en.wikipedia.org/wiki/1-1-2 It is so easy to know... I do not get your arguments. With best regards, Christian From hoene@uni-tuebingen.de Mon May 24 10:43:29 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 806A03A6C44 for ; Mon, 24 May 2010 10:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKJIOMdD7j97 for ; Mon, 24 May 2010 10:43:28 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 420F83A6D09 for ; Mon, 24 May 2010 10:43:28 -0700 (PDT) Received: from hoeneT60 ([82.113.121.147]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4OHh83E001665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 May 2010 19:43:16 +0200 From: "Christian Hoene" To: References: <000f01cafb61$efe237e0$cfa6a7a0$@de> <4BFAB63E.3090408@fas.harvard.edu> In-Reply-To: <4BFAB63E.3090408@fas.harvard.edu> Date: Mon, 24 May 2010 19:43:04 +0200 Message-ID: <002701cafb68$960cc3f0$c2264bd0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr7ZfQndiA3cTteQqqUaOWA1c3n/QAAbp0g Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.242; VDF: 7.10.7.163; host: mx05); id=17691-2IRMfd Cc: codec@ietf.org Subject: Re: [codec] #14: VAD and CNG? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 17:43:29 -0000 Hi Benjamin, >In general, parameters for bitrate, jitter buffer, sample rate, filtering, and AEC are not exposed to >the user. They are typically managed according to some customized algorithm designed for the >hardware, network, and application. DTX is just one more of these settings, and would be no more >likely to be exposed to the user. We don't need to worry about the user interface, because in most >cases there won't be one. Actually, I meant two kind of users: Those of the phone and those of the codec. > >I think it's a good idea for the reference implementation to provide some intelligent heuristics for >use of DTX, but these heuristics should not be a requirement of any RFC. Yes, you are true. But we must be precise. The requirement for some heuristics on how to set those parameters MUST be part of the requirements document. However, the heuristics NEED NOT to be implemented in every phone but the implementer CAN choose any superior algorithm to optimize particular application needs. Thus, a heuristic on how to select DTX should only ensure some minimal system quality. Christian > >--Ben From br@brianrosen.net Mon May 24 11:26:33 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 140D53A717C for ; Mon, 24 May 2010 11:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.088 X-Spam-Level: X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dz63N7TV6M0c for ; Mon, 24 May 2010 11:26:32 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id EE6273A7141 for ; Mon, 24 May 2010 11:20:14 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.195]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1OGcFo-0000GB-8Y; Mon, 24 May 2010 13:19:57 -0500 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 24 May 2010 14:20:00 -0400 From: Brian Rosen To: Christian Hoene Message-ID: Thread-Topic: [codec] #14: VAD and CNG? Thread-Index: Acr7WTQ0TWNTp065pEyGl+SXCIY/ggAAB+/wAAJXcJIAAQwYkAABtaCB In-Reply-To: <002301cafb67$c3dc5300$4b94f900$@de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: codec@ietf.org Subject: Re: [codec] #14: VAD and CNG? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2010 18:26:33 -0000 Okay, you asked for it :) In any country, the codes used in another country for emergency numbers are used as service invocations for other services. You have to know what country you are in to know what emergency numbers are. It is roughly impossible (today) to know that with sufficient reliability. You can place an emergency call to an e.164 in many countries. This may depend on which service. The emergency call center (PSAP) can call you back. A call placed to a call center can be transferred or upgraded to an emergency call. This happens with relay centers used by disabled individuals. In all of these circumstances, VAD must be disabled. Emergency calling systems are filled with a lot of complexity that handle seldom occurring circumstances. However, when it comes to saving lives, seldom occurring circumstances are important. Brian ps - I have been working in this field for a number of years. You can learn a bit more about emergency calling from draft-ietf-ecrit-framework. The inability to turn off VAD in VoIP systems believed to have caused actual harm according to some of my associates who work in PSAPs. On 5/24/10 1:37 PM, "Christian Hoene" wrote: > Hi Brian, > >> I'll be happy to go into the details, but phones may not know they are in an >> emergency call. No phone knows this today. There is some proposed >> signaling that would tell them, IF the phone, and the service provider >> implement it, but even then, there are circumstances where the phone won't >> know. > > If(called.number==112 || called.number==911 || called.number=XYZ) > EmergencyCall(); > > See more at http://en.wikipedia.org/wiki/1-1-2 > It is so easy to know... I do not get your arguments. > > With best regards, > > Christian > > > From rchen@broadcom.com Mon May 24 18:40:43 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B23E3A7257 for ; Mon, 24 May 2010 18:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.074 X-Spam-Level: * X-Spam-Status: No, score=1.074 tagged_above=-999 required=5 tests=[AWL=-1.227, BAYES_50=0.001, MANGLED_WRLDWD=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBxpBJhFoyGE for ; Mon, 24 May 2010 18:40:41 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id E8F1B3A70EC for ; Mon, 24 May 2010 18:39:34 -0700 (PDT) Received: from [10.9.200.131] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 24 May 2010 18:38:50 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Mon, 24 May 2010 18:38:50 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Cullen Jennings" Date: Mon, 24 May 2010 18:38:47 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: Acr2sGCVc3eeVeE1QUeAeCyK+oTN9QE8OoVw Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <07C815A7-8F3C-4F85-A275-4352D0080EEA@cisco.com> <909E12B9-984F-4051-A93E-2291EFE0A40E@cisco.com> In-Reply-To: <909E12B9-984F-4051-A93E-2291EFE0A40E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67E5F5A038O217469696-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2010 01:40:43 -0000 Hi Cullen, Sorry for the delay of my reply. I was busy last week and could not respon= d earlier. Thank you for sharing the details of your delay measurements on Cisco 7960 = IP phones. What you observed does NOT conflict with what I have been saying. The reason is that the 20 ms and 30 ms you quoted are the "packet sizes", n= ot the "codec frame sizes". Codec frame size and packet size have different impacts on one-way delay. The G.711 codec that you used is a sample-by- sample codec. Theoretically its "codec frame size" is only one sample, or 0.125 ms, so the (3 x 30 ms - 3 x 20 ms) formula is not the right target for comparison. Furthermore, many telephones have G.711 encoder and decoder directly built into the chip hardware of A/D and D/A, so they can directly digitize the input audio signal into 8-bit G.711 codewords and directly playback 8-bit G.711 codewords as the output audio signal; thus, there is essentially no processing delay for G.711. Even if the G.711 encoding/decoding is done in software or firmware, the G.711 codec complexity is so low that it takes almost no time to do G.711 processing. The almost-zero processing delay ca= n contribute to the extra low delay of G.711-based VoIP systems. There have been so many discussions about how the codec frame size and pack= et size may affect the one-way delay, there has been confusion, and there have been criticism that there wasn't any rigorous theoretical analysis, so I thought I would spend some time to give a more rigorous delay analysis belo= w so we can hopefully settle such disputes. At the end of my analysis, you wi= ll see how the lower bound and upper bound of the one-way delay depend on the codec frame size AND the packet size under various conditions. Please read = on if you are interested; ignore if you are not; or you can quickly scroll dow= n to Equations (1) through (3), which are the main results of my delay analysis, and read the last few paragraphs after Eq. (3). Before I did the following delay analysis, I consulted extensively with thr= ee Broadcom senior technical leads who have many years of extensive real-time system architecture and design experiences in IP phones, VoIP gateways, and video systems (such as cable/satellite set-top boxes), respectively. What they told me were consistent with each other and consistent with what I hav= e been saying. Before I start the analysis, let me first discuss the multi-tasking, or Rea= l- Time Scheduling (RTS) delay, because it is a critical component of the tota= l one-way delay and needs to be clarified first. In real-time audio or video systems, many tasks have definite completion deadlines beyond which the real-time operation will be lost and there will = be audible or visible glitches. One way to handle a real-time task is by interrupting the processor in the hope that the processor will put down whatever it is doing and service the interrupt first. If there is only one real-time task and all other tasks in the system do not have real-time requirements, then the interrupt will be serviced immediately and there is = no RTS delay. However, this is rarely the case, since the system typically al= so has other real-time tasks. (For example, an IP phone needs to handle the encoding of the send-path signal, decoding of the receive-path signal, echo canceller, side-tone, and other real-time tasks at the same time.) Then, th= e interrupts generated by different real-time tasks need to be prioritized. There can be only one highest-priority task. Any of the other tasks will have a lower priority and need to wait for its turn if it tries to interrup= t a higher-priority task. That wait time, plus the time it takes the processo= r to complete the task, is the RTS delay of that task. The entire audio or video stream will need to be buffered and delayed by at least the worst-cas= e wait time in order to have a smooth playback without any gaps or glitch. If there are a large number of real-time tasks in the system, then a prioritized interrupt-driven RTS system will become very complex and messy, and the associated context switching for all the interrupts will reduce the system efficiency. Therefore, in IP phones, VoIP gateways, and cable/satellite set-top boxes, usually a different kind of real-time scheduling scheme is used, where each real-time task is allowed to run to completion, but to simplify RT scheduling, all real-time tasks are requeste= d in a periodic manner, or with similar assumptions such as a minimum interva= l. In many of these designs, all real time tasks on any one processor have the same period (or "thread interval") for maximum real time efficiency. In th= e case of real-time voice communication systems, the most convenient and comm= on thread interval is the codec frame size. Thus, the codec frame size determines how much RTS delay the system has. I have consulted my Broadcom colleague Sandy MacInnis, a senior architect who specializes in video and system design, and who is knowledgeable about real time scheduling. He was the chair of the MPEG Systems committee for MPEG-1 and MPEG-2 (i.e. MPEG Transport, MPEG Programs streams, and MPEG-1 Systems). I will quote him below: "For most efficient scheduling, all tasks should have the same period, and = in the general case, each task may be served any time from immediately after t= he request to the last instant before the next request. So, for such efficient= , general and robust systems, the RTS (real time scheduling) latency is up to one request period, which in this case is a frame duration. When the reques= t is serviced earlier, the data has to be buffered up because the end-end del= ay needs to be constant. While someone might say that they think an RTS scheme can service requests with consistently less latency than a frame time, I would challenge them for a theoretical basis that shows they can do so reliably. What happens when all the requests happen at the same time? That can certainly happen, in general. ... An extremely standard basic assumption of RTS, and in particular Rate Monotonic Scheduling (RMS), is th= at for each task, the deadline equals the period. That means that from the tim= e a requester makes a request, the RTS system needs to ensure that the reques= t is completely serviced (finished, not just started) before the period from that request to the next request expires. Other assumptions are possible, b= ut longer deadlines don't usually help much and they make the system more complex, and shorter deadlines make scheduling harder. If there is a set o= f tasks with exactly the same period, i.e. synchronous, then it's possible to schedule the shared resource to 100% of capacity while ensuring RT performance. However, in the more typical case, the various tasks do not ha= ve the same period, in which case in general the maximum utilization of the shared resource that can be scheduled for real time tasks is significantly less than 100%. Whether the system is real-time schedulable or not can be determined in various ways, including critical instant analysis. In either case, in general the latency of any given request can be anywhere from zero plus processing time, to exactly the period =3D deadline." For a PC with a very powerful processor and a very light real-time load, it may be reasonable to expect the processor to perform the encoding and decoding tasks very shortly after they are requested, with the requests bei= ng driven by interrupts, and the processing time of each task may be very shor= t relative to the interval between requests. The resulting RTS delay may be a= s low as a few percent of the frame interval. This is possible because a typical PC has much higher processing power than is required by a speech coder. The same is not true for VoIP gateways or IP phones, where the processor is heavily loaded with real-time tasks and is often just barely fast enough to handle the designated number of voice channels (many for gateways and one f= or IP phones). For example, rather than having a 2 to 3 GHz processor as in a PC, the processor used to do speech coding in a low-end IP phone may only have a clock rate of slightly more than 100 MHz. In this case, it is reasonable to expect that the time required to service each request, including processing time, may be as much as the full frame interval. OK, now that the RTS delay has been discussed, let me proceed with my delay analysis. I will break down the delay into many components, with each component occurring after the components listed earlier. Let the codec fra= me size be F ms and the packet size be P ms. Let each packet contain N codec frames, so P =3D N*F. For simplicity, we will not consider the codec look- ahead L ms and codec filtering delay R ms in this analysis and will just ad= d them at the end because we know their multiplier is 1X. The one-way mouth-to-ear delay includes the following codec-dependent delay components: (1) Encoder buffering delay: d1 =3D a1*F, where a1 =3D 1. This is the time it takes to buffer all input samples of a codec frame. (2) Encoder RTS delay: d2 =3D a2*F, where 0 < a2 <=3D 1. This includes the encoder processing delay; see the discussion above. (3) Packetization delay: d3 =3D a3*F, where a3 =3D (N-1). This is the amount of time the first frame in the packet need to wait until the last frame of encoded bits in the packet is ready. (4) Packet transmission delay: d4 =3D a4*F, where 0 < a4 <=3D N. This is the time it takes to ship all bits in the packets out of the transmitter; this can also be considered the decoder bit buffering delay, since it is the time the decoder needs to wait to get all bits in the packe= t. If the speed of the communication channel is very high, then d4 can be a ve= ry small fraction of the packet size P =3D N*F ms, but it will not be zero. I= f the channel speed is exactly the same as the bit-rate of the packet (including the packet header), then d4 =3D P =3D N*F ms. Even for the case= of high-speed channel, if we view the bit transmission task as a real-time scheduling problem for the micro-controller (which may run at a different thread rate than the DSP), then the scheduling wait time plus the processin= g time (i.e. the time to actually transmit bits) may still take up to one thread interval, which is P =3D N*F ms in this case. (5) Decoder RTS delay: d5 =3D a5*F, where 0 < a5 <=3D 1. This includes the decoder processing delay; see the discussion above. There may be other delay components that may depend on the codec frame size= . For example, in gateways where a few layers of processors are used, each processor may have its own real-time scheduling delays for all tasks that i= t handles. However, at least the delay components listed above are the major ones that are commonly encountered. If we omit the other possible codec- dependent components for the moment but add back the codec look-ahead L and codec filtering delay R (if any), the total codec-dependent one-way delay i= s then D =3D d1 + d2 +... + d5 + L + R =3D {1 + (0,1] + (N-1) + (0,N] + (0,1]}*F += L + R Hence, the one-way delay D has a possible range of N*F + L + R < D <=3D (2*N + 2)*F + L + R, or P + L + R < D <=3D 2*P + 2*F + L + R Eq. (1) For heavily loaded real-time systems such as VoIP gateways or IP phones, if we assume the worst case of one full frame of encoder RTS delay and decoder RTS delay, then a2 =3D 1 and a5 =3D 1, and we get a tighter range for the o= ne-way delay: P + 2*F + L + R < D <=3D 2*P + 2*F + L + R Eq. (2) In the special case of N =3D 1 (each packet contains only one codec frame), then we get 3*F + L + R < D <=3D 4*F + L + R Eq. (3) The delay lower bounds in Eq. (1) through Eq. (3) above (under their individual assumptions) are consistent with what I have been saying. If the other omitted codec-dependent delay components are significant, or if the system implementers have not been careful about minimizing the delay= , then the delay upper bounds can be even higher than what are shown in Eq. (= 1) through Eq. (3). In your Cisco 7960 IP phone delay measurements, P =3D 20 ms or 30 ms, L =3D= 0, R =3D 0, and theoretically F =3D 0.125 ms. If you look at Eq. (2) above, the= n it is clear that you won't see 3 times the packet size difference as the delay difference. However, here the codec frame size is 0.125 ms, not 20 or 30 m= s, so this result doesn't conflict with what I have been saying (i.e. 3X codec frame size). Of course, in reality it is unlikely that an IP phone will use 0.125 ms as the thread interval. A more likely thread interval is P. Then, my delay analysis above does not apply directly. However, it is not difficult to follow the same logic and procedure to see what will happen in this case. = If G.711 encoding and decoding is built right into the A/D and D/A, then the 8= - bit G.711 codewords directly arrives at the input buffer or leave the outpu= t buffer and the RTS system does not need to schedule G.711 encoding and decoding tasks, so d2 =3D d5 =3D 0. Also, in this case d1 =3D P, d3 =3D 0, = and 0 < d4 <=3D P. Thus, the total one-way delay is P < D <=3D 2*P. Even if the G.711 encoding and decoding operations are done in software/firmware, the G.711 complexity is so low that it takes the process= or almost no time to do encoding and decoding. In this case, the IP phone is closer to the case of a PC that has much more processing power than is required for speech coding, and if the Cisco engineers did a good job of optimizing RTS to minimize d2 and d5, then d2 and d5 would be closer to 0 than to P. Then, the total one-way codec-dependent delay would be closer t= o P than to 3*P. This is probably what you have observed. Best Regards, Raymond -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com] Sent: Tuesday, May 18, 2010 10:34 AM To: Raymond (Juin-Hwey) Chen Cc: Koen Vos; codec@ietf.org Subject: Re: [codec] #16: Multicast? On May 12, 2010, at 12:28 PM, Raymond (Juin-Hwey) Chen wrote: > Hi Cullen, > > Hmm... That's interesting. Would you please share more details of > your measurement equipment setup, the codec used, the codec frame > size, the number of codec frames in each packet, the way you > measured the delay, and the measured delay value, etc.? Sure - it's really simple to set up. I use a signal generator that makes a = tone burst. Typically I do something like 550 Hz tone that is a 200 ms long= burst that occurs once a second. I play this into a speaker near the micro= phone on one phone and also put it into 1 channel of a scope. I think put = a microphone near the speaker of the other phone and put that on another ch= annel of the scope and measure the mouth to ear delay. It's really easy to = see the starts of the two bursts from the speaker and microphone and measur= e the delay within a few ms. I've done lots of clever things over the years= using stats from software in the phones but this technique is easy and pre= tty fool proof on getting good results. The phones were plugged into Netgea= r 100Mbps hub as I sometimes look at the timing of the ethernet packets too= . I set up phones for G.711, one frame per packet - I choose this as it is= easy to change the length of each frame but results are similar with other= codecs. I was using two Cisco 7960 phones - no idea what version of the software an= d may have been a development build but it's pretty unlikely that current p= roduction software would have different results from what I tested. I set t= he phones for G.711 with 20 ms packets, measured delay, then set the phones= for 30 ms packets and measured delay. For a given packet length, when I ma= ke multiple phone calls or reboot one of the phones, the measurements stay = consistent. The resulting change in delay between the two experiments was much less tha= n 30ms that a (3x 30 ms - 3 x 20 ms) would have predicted. I feel like a to= tal tool not providing the details of the exact measurements but lots of me= asurements like this Cisco considers confidential and I'm just not up to ar= guing with folks about what can and can not be said publicly. I probably sh= ould have done a test with 10 ms packets too but I did not. Yes I realize h= ow nuts it is to consider something that anyone can easily measure as confi= dential. If anyone really cares, I will go do the work to be able to provid= e the numbers. > > I didn't come up with this 3*(codec frame size) delay number for IP > phones myself. A very senior technical lead in Broadcom's IP phone > chips group told me that, and Broadcom is currently the #1 world- > wide market share leader in IP phone chips, accounting for more than > half of the world's IP phone chip shipments. > Most of the world's > tier-1 IP phone manufacturers use our IP phone chips at least in > some of their product lines. Yah, again, Cisco considers chipsets confidential but if you poke around wi= th google, such as http://lmgtfy.com/?q=3Dteardown+analysis+cisco+7960 Folks claim the 7960 uses a Broadcom chip - of course that looks like it is= for the ethernet switch on the phone not much to do with software that imp= acts audio latency. > > I would be very interested to learn more about your measurements to > try to reconcile these seemingly contradictory statements from two > different sources. Thanks. Be glad to talk to whoever it is. I really don't know relevant this all is = too figuring out what packets sizes we need to support. > > Best Regards, > > Raymond > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Wednesday, May 12, 2010 8:00 AM > To: Raymond (Juin-Hwey) Chen > Cc: Koen Vos; codec@ietf.org > Subject: Re: [codec] #16: Multicast? > > > On May 4, 2010, at 7:15 PM, Raymond (Juin-Hwey) Chen wrote: > >> the 3*(codec frame size) delay is very real for IP phone > > This does not match the measurements I have. And I certainly don't have 1= 00+ year voip experience but I do have two of the #1 selling enterprise pho= nes connected to an oscilloscope. Test with other phones suggest most the m= ajor vendors of IP hard phones have fairly comparable performance when it c= omes to delay. > > > Cullen > Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From koen.vos@skype.net Wed May 26 15:13:42 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C87C3A6A2C for ; Wed, 26 May 2010 15:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.3 X-Spam-Level: *** X-Spam-Status: No, score=3.3 tagged_above=-999 required=5 tests=[BAYES_60=1, MANGLED_WRLDWD=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9J63DXL+HloN for ; Wed, 26 May 2010 15:13:40 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id A0D2A3A6A31 for ; Wed, 26 May 2010 15:13:39 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 363C420074882; Thu, 27 May 2010 00:13:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=kHBwXSim4FpT fudc5UW0s0Bmscs=; b=Vi5DC7J6wU5YbAI3vCES9lx6uX/IuhofTh0a5VWeOXUg X/+MxMNs4B4CTDHk+k6Zk0jLQlRRJ05r4PoxIiSFRgIpNG9rlYF/QUttAx9hWdxl MEROXtNYVSfg4cyy5opHq++DBIS4sQSiwDKs5/HUDE0FnXugPI6F6kYGkL/pekc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=sP2J/B2zXqD/gVdPycYy QAInq2KpBCHbPz0XPNHoGuY/GgMsfHzVHpaEO+SAs2+Gx849IiNVK1Si41e7OnI4 xUzfvpkcIh+03dPQ+O29rmPxNbfzon2j77iSYjrEPcjsadYdg5WhsBosuyt3miWY 8dR3n9sikFOAtQSVcm8HxwI= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 3391C20074457; Thu, 27 May 2010 00:13:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDW3thWdflHJ; Thu, 27 May 2010 00:13:27 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 819B320074881; Thu, 27 May 2010 00:13:27 +0200 (CEST) Received: from adsl-71-141-115-202.dsl.snfc21.pacbell.net (adsl-71-141-115-202.dsl.snfc21.pacbell.net [71.141.115.202]) by mail.skype.net (Horde Framework) with HTTP; Wed, 26 May 2010 15:13:26 -0700 Message-ID: <20100526151326.2882694zuaeslk3q@mail.skype.net> Date: Wed, 26 May 2010 15:13:26 -0700 From: Koen Vos To: "Raymond (Juin-Hwey) Chen" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <07C815A7-8F3C-4F85-A275-4352D0080EEA@cisco.com> <909E12B9-984F-4051-A93E-2291EFE0A40E@cisco.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 22:13:42 -0000 Hi Raymond, Thanks for the detailed explanation, this clarifies your earlier statements about the 3x multiplier. The essence, if I understand you correctly, is that there still exist low-end platforms with barely enough processing power to run a VoIP call. If such platforms use a naive FIFO scheduler, they'll create up to one frame of processing delay for encoder and decoder each, on top of the frame of buffering delay. The good news is that Moore's law will continue to drive down the fraction of platforms with such processing delay problems. I'm a bit surprised by your analysis of "packet transmission delay", as it has little bearing on our multiplier (ie the change in delay as a function of frame size). See old posts. best, koen. Quoting "Raymond (Juin-Hwey) Chen": > Hi Cullen, > > Sorry for the delay of my reply. I was busy last week and could not respond > earlier. > > Thank you for sharing the details of your delay measurements on Cisco 7960 IP > phones. What you observed does NOT conflict with what I have been saying. > The reason is that the 20 ms and 30 ms you quoted are the "packet sizes", not > the "codec frame sizes". Codec frame size and packet size have different > impacts on one-way delay. The G.711 codec that you used is a sample-by- > sample codec. Theoretically its "codec frame size" is only one sample, or > 0.125 ms, so the (3 x 30 ms - 3 x 20 ms) formula is not the right target > for comparison. > > Furthermore, many telephones have G.711 encoder and decoder directly built > into the chip hardware of A/D and D/A, so they can directly digitize the > input audio signal into 8-bit G.711 codewords and directly playback 8-bit > G.711 codewords as the output audio signal; thus, there is essentially no > processing delay for G.711. Even if the G.711 encoding/decoding is done in > software or firmware, the G.711 codec complexity is so low that it takes > almost no time to do G.711 processing. The almost-zero processing delay can > contribute to the extra low delay of G.711-based VoIP systems. > > There have been so many discussions about how the codec frame size and packet > size may affect the one-way delay, there has been confusion, and there have > been criticism that there wasn't any rigorous theoretical analysis, so I > thought I would spend some time to give a more rigorous delay analysis below > so we can hopefully settle such disputes. At the end of my analysis, you will > see how the lower bound and upper bound of the one-way delay depend on the > codec frame size AND the packet size under various conditions. Please read on > if you are interested; ignore if you are not; or you can quickly scroll down > to Equations (1) through (3), which are the main results of my delay > analysis, and read the last few paragraphs after Eq. (3). > > Before I did the following delay analysis, I consulted extensively with three > Broadcom senior technical leads who have many years of extensive real-time > system architecture and design experiences in IP phones, VoIP gateways, and > video systems (such as cable/satellite set-top boxes), respectively. What > they told me were consistent with each other and consistent with what I have > been saying. > > Before I start the analysis, let me first discuss the multi-tasking, or Real- > Time Scheduling (RTS) delay, because it is a critical component of the total > one-way delay and needs to be clarified first. > > In real-time audio or video systems, many tasks have definite completion > deadlines beyond which the real-time operation will be lost and there will be > audible or visible glitches. One way to handle a real-time task is by > interrupting the processor in the hope that the processor will put down > whatever it is doing and service the interrupt first. If there is only one > real-time task and all other tasks in the system do not have real-time > requirements, then the interrupt will be serviced immediately and there is no > RTS delay. However, this is rarely the case, since the system typically also > has other real-time tasks. (For example, an IP phone needs to handle the > encoding of the send-path signal, decoding of the receive-path signal, echo > canceller, side-tone, and other real-time tasks at the same time.) Then, the > interrupts generated by different real-time tasks need to be prioritized. > There can be only one highest-priority task. Any of the other tasks will > have a lower priority and need to wait for its turn if it tries to interrupt > a higher-priority task. That wait time, plus the time it takes the processor > to complete the task, is the RTS delay of that task. The entire audio or > video stream will need to be buffered and delayed by at least the worst-case > wait time in order to have a smooth playback without any gaps or glitch. > > If there are a large number of real-time tasks in the system, then a > prioritized interrupt-driven RTS system will become very complex and messy, > and the associated context switching for all the interrupts will reduce the > system efficiency. Therefore, in IP phones, VoIP gateways, and > cable/satellite set-top boxes, usually a different kind of real-time > scheduling scheme is used, where each real-time task is allowed to run to > completion, but to simplify RT scheduling, all real-time tasks are requested > in a periodic manner, or with similar assumptions such as a minimum interval. > In many of these designs, all real time tasks on any one processor have the > same period (or "thread interval") for maximum real time efficiency. In the > case of real-time voice communication systems, the most convenient and common > thread interval is the codec frame size. Thus, the codec frame size > determines how much RTS delay the system has. I have consulted my Broadcom > colleague Sandy MacInnis, a senior architect who specializes in video and > system design, and who is knowledgeable about real time scheduling. He was > the chair of the MPEG Systems committee for MPEG-1 and MPEG-2 (i.e. MPEG > Transport, MPEG Programs streams, and MPEG-1 Systems). I will quote him > below: > > "For most efficient scheduling, all tasks should have the same period, and in > the general case, each task may be served any time from immediately after the > request to the last instant before the next request. So, for such efficient, > general and robust systems, the RTS (real time scheduling) latency is up to > one request period, which in this case is a frame duration. When the request > is serviced earlier, the data has to be buffered up because the end-end delay > needs to be constant. While someone might say that they think an RTS scheme > can service requests with consistently less latency than a frame time, I > would challenge them for a theoretical basis that shows they can do so > reliably. What happens when all the requests happen at the same time? That > can certainly happen, in general. ... An extremely standard basic > assumption of RTS, and in particular Rate Monotonic Scheduling (RMS), is that > for each task, the deadline equals the period. That means that from the time > a requester makes a request, the RTS system needs to ensure that the request > is completely serviced (finished, not just started) before the period from > that request to the next request expires. Other assumptions are possible, but > longer deadlines don't usually help much and they make the system more > complex, and shorter deadlines make scheduling harder. If there is a set of > tasks with exactly the same period, i.e. synchronous, then it's possible to > schedule the shared resource to 100% of capacity while ensuring RT > performance. However, in the more typical case, the various tasks do not have > the same period, in which case in general the maximum utilization of the > shared resource that can be scheduled for real time tasks is significantly > less than 100%. Whether the system is real-time schedulable or not can be > determined in various ways, including critical instant analysis. In either > case, in general the latency of any given request can be anywhere from zero > plus processing time, to exactly the period = deadline." > > For a PC with a very powerful processor and a very light real-time load, it > may be reasonable to expect the processor to perform the encoding and > decoding tasks very shortly after they are requested, with the requests being > driven by interrupts, and the processing time of each task may be very short > relative to the interval between requests. The resulting RTS delay may be as > low as a few percent of the frame interval. This is possible because a > typical PC has much higher processing power than is required by a speech > coder. > > The same is not true for VoIP gateways or IP phones, where the processor is > heavily loaded with real-time tasks and is often just barely fast enough to > handle the designated number of voice channels (many for gateways and one for > IP phones). For example, rather than having a 2 to 3 GHz processor as in a > PC, the processor used to do speech coding in a low-end IP phone may only > have a clock rate of slightly more than 100 MHz. In this case, it is > reasonable to expect that the time required to service each request, > including processing time, may be as much as the full frame interval. > > OK, now that the RTS delay has been discussed, let me proceed with my delay > analysis. I will break down the delay into many components, with each > component occurring after the components listed earlier. Let the codec frame > size be F ms and the packet size be P ms. Let each packet contain N codec > frames, so P = N*F. For simplicity, we will not consider the codec look- > ahead L ms and codec filtering delay R ms in this analysis and will just add > them at the end because we know their multiplier is 1X. > > The one-way mouth-to-ear delay includes the following codec-dependent delay > components: > > (1) Encoder buffering delay: d1 = a1*F, where a1 = 1. > This is the time it takes to buffer all input samples of a codec frame. > > (2) Encoder RTS delay: d2 = a2*F, where 0 < a2 <= 1. > This includes the encoder processing delay; see the discussion above. > > (3) Packetization delay: d3 = a3*F, where a3 = (N-1). > This is the amount of time the first frame in the packet need to wait until > the last frame of encoded bits in the packet is ready. > > (4) Packet transmission delay: d4 = a4*F, where 0 < a4 <= N. > This is the time it takes to ship all bits in the packets out of the > transmitter; this can also be considered the decoder bit buffering delay, > since it is the time the decoder needs to wait to get all bits in the packet. > If the speed of the communication channel is very high, then d4 can be a very > small fraction of the packet size P = N*F ms, but it will not be zero. If > the channel speed is exactly the same as the bit-rate of the packet > (including the packet header), then d4 = P = N*F ms. Even for the case of > high-speed channel, if we view the bit transmission task as a real-time > scheduling problem for the micro-controller (which may run at a different > thread rate than the DSP), then the scheduling wait time plus the processing > time (i.e. the time to actually transmit bits) may still take up to one > thread interval, which is P = N*F ms in this case. > > (5) Decoder RTS delay: d5 = a5*F, where 0 < a5 <= 1. > This includes the decoder processing delay; see the discussion above. > > There may be other delay components that may depend on the codec frame size. > For example, in gateways where a few layers of processors are used, each > processor may have its own real-time scheduling delays for all tasks that it > handles. However, at least the delay components listed above are the major > ones that are commonly encountered. If we omit the other possible codec- > dependent components for the moment but add back the codec look-ahead L and > codec filtering delay R (if any), the total codec-dependent one-way delay is > then > > D = d1 + d2 +... + d5 + L + R = {1 + (0,1] + (N-1) + (0,N] + (0,1]}*F + L + R > > Hence, the one-way delay D has a possible range of > > N*F + L + R < D <= (2*N + 2)*F + L + R, or > > P + L + R < D <= 2*P + 2*F + L + R Eq. (1) > > For heavily loaded real-time systems such as VoIP gateways or IP phones, if > we assume the worst case of one full frame of encoder RTS delay and decoder > RTS delay, then a2 = 1 and a5 = 1, and we get a tighter range for the one-way > delay: > > P + 2*F + L + R < D <= 2*P + 2*F + L + R Eq. (2) > > In the special case of N = 1 (each packet contains only one codec frame), > then we get > > 3*F + L + R < D <= 4*F + L + R Eq. (3) > > The delay lower bounds in Eq. (1) through Eq. (3) above (under their > individual assumptions) are consistent with what I have been saying. > If the other omitted codec-dependent delay components are significant, or > if the system implementers have not been careful about minimizing the delay, > then the delay upper bounds can be even higher than what are shown > in Eq. (1) through Eq. (3). > > In your Cisco 7960 IP phone delay measurements, P = 20 ms or 30 ms, L = 0, R > = 0, and theoretically F = 0.125 ms. If you look at Eq. (2) above, then it > is clear that you won't see 3 times the packet size difference as the delay > difference. However, here the codec frame size is 0.125 ms, not 20 or 30 ms, > so this result doesn't conflict with what I have been saying (i.e. 3X codec > frame size). > > Of course, in reality it is unlikely that an IP phone will use 0.125 ms as > the thread interval. A more likely thread interval is P. Then, my delay > analysis above does not apply directly. However, it is not difficult to > follow the same logic and procedure to see what will happen in this case. If > G.711 encoding and decoding is built right into the A/D and D/A, then the 8- > bit G.711 codewords directly arrives at the input buffer or leave the output > buffer and the RTS system does not need to schedule G.711 encoding and > decoding tasks, so d2 = d5 = 0. Also, in this case d1 = P, d3 = 0, and 0 < d4 > <= P. Thus, the total one-way delay is P < D <= 2*P. > > Even if the G.711 encoding and decoding operations are done in > software/firmware, the G.711 complexity is so low that it takes the processor > almost no time to do encoding and decoding. In this case, the IP phone is > closer to the case of a PC that has much more processing power than is > required for speech coding, and if the Cisco engineers did a good job of > optimizing RTS to minimize d2 and d5, then d2 and d5 would be closer to 0 > than to P. Then, the total one-way codec-dependent delay would be closer to > P than to 3*P. This is probably what you have observed. > > Best Regards, > > Raymond > > > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, May 18, 2010 10:34 AM > To: Raymond (Juin-Hwey) Chen > Cc: Koen Vos; codec@ietf.org > Subject: Re: [codec] #16: Multicast? > > > On May 12, 2010, at 12:28 PM, Raymond (Juin-Hwey) Chen wrote: > >> Hi Cullen, >> >> Hmm... That's interesting. Would you please share more details of >> your measurement equipment setup, the codec used, the codec frame >> size, the number of codec frames in each packet, the way you >> measured the delay, and the measured delay value, etc.? > > Sure - it's really simple to set up. I use a signal generator that > makes a tone burst. Typically I do something like 550 Hz tone that > is a 200 ms long burst that occurs once a second. I play this into a > speaker near the microphone on one phone and also put it into 1 > channel of a scope. I think put a microphone near the speaker of > the other phone and put that on another channel of the scope and > measure the mouth to ear delay. It's really easy to see the starts > of the two bursts from the speaker and microphone and measure the > delay within a few ms. I've done lots of clever things over the > years using stats from software in the phones but this technique is > easy and pretty fool proof on getting good results. The phones were > plugged into Netgear 100Mbps hub as I sometimes look at the timing > of the ethernet packets too. I set up phones for G.711, one frame > per packet - I choose this as it is easy to change the length of > each frame but results are similar with other codecs. > > I was using two Cisco 7960 phones - no idea what version of the > software and may have been a development build but it's pretty > unlikely that current production software would have different > results from what I tested. I set the phones for G.711 with 20 ms > packets, measured delay, then set the phones for 30 ms packets and > measured delay. For a given packet length, when I make multiple > phone calls or reboot one of the phones, the measurements stay > consistent. > > The resulting change in delay between the two experiments was much > less than 30ms that a (3x 30 ms - 3 x 20 ms) would have predicted. I > feel like a total tool not providing the details of the exact > measurements but lots of measurements like this Cisco considers > confidential and I'm just not up to arguing with folks about what > can and can not be said publicly. I probably should have done a test > with 10 ms packets too but I did not. Yes I realize how nuts it is > to consider something that anyone can easily measure as > confidential. If anyone really cares, I will go do the work to be > able to provide the numbers. > > >> >> I didn't come up with this 3*(codec frame size) delay number for IP >> phones myself. A very senior technical lead in Broadcom's IP phone >> chips group told me that, and Broadcom is currently the #1 world- >> wide market share leader in IP phone chips, accounting for more than >> half of the world's IP phone chip shipments. >> Most of the world's >> tier-1 IP phone manufacturers use our IP phone chips at least in >> some of their product lines. > > Yah, again, Cisco considers chipsets confidential but if you poke > around with google, such as > > http://lmgtfy.com/?q=teardown+analysis+cisco+7960 > > Folks claim the 7960 uses a Broadcom chip - of course that looks > like it is for the ethernet switch on the phone not much to do with > software that impacts audio latency. > >> >> I would be very interested to learn more about your measurements to >> try to reconcile these seemingly contradictory statements from two >> different sources. Thanks. > > Be glad to talk to whoever it is. I really don't know relevant this > all is too figuring out what packets sizes we need to support. > >> >> Best Regards, >> >> Raymond >> >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Wednesday, May 12, 2010 8:00 AM >> To: Raymond (Juin-Hwey) Chen >> Cc: Koen Vos; codec@ietf.org >> Subject: Re: [codec] #16: Multicast? >> >> >> On May 4, 2010, at 7:15 PM, Raymond (Juin-Hwey) Chen wrote: >> >>> the 3*(codec frame size) delay is very real for IP phone >> >> This does not match the measurements I have. And I certainly don't >> have 100+ year voip experience but I do have two of the #1 selling >> enterprise phones connected to an oscilloscope. Test with other >> phones suggest most the major vendors of IP hard phones have fairly >> comparable performance when it comes to delay. >> >> >> Cullen >> > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > From rchen@broadcom.com Wed May 26 18:24:17 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD2D23A67AB for ; Wed, 26 May 2010 18:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3rCMShBsDky for ; Wed, 26 May 2010 18:24:14 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 7BF8F3A67DB for ; Wed, 26 May 2010 18:24:13 -0700 (PDT) Received: from [10.9.200.131] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 26 May 2010 18:23:46 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Wed, 26 May 2010 18:23:46 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Koen Vos" Date: Wed, 26 May 2010 18:23:38 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: Acr9ILZGd4UZ+spOSrulXwNDxrUjNgACl3Dg Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <07C815A7-8F3C-4F85-A275-4352D0080EEA@cisco.com> <909E12B9-984F-4051-A93E-2291EFE0A40E@cisco.com> <20100526151326.2882694zuaeslk3q@mail.skype.net> In-Reply-To: <20100526151326.2882694zuaeslk3q@mail.skype.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AuI6 A4mO DFTH EECI IgkJ OiEi OzJg QCi6 RgUn TMdj UKbs UPf/ V8hZ XrNE XwWj YQ9D; 2; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAawBvAGUAbgAuAHYAbwBzAEAAcwBrAHkAcABlAC4AbgBlAHQA; Sosha1_v1; 7; {FEF090C4-D196-4364-9E54-6B0EAE0497BC}; cgBjAGgAZQBuAEAAYgByAG8AYQBkAGMAbwBtAC4AYwBvAG0A; Thu, 27 May 2010 01:23:38 GMT; UgBFADoAIABbAGMAbwBkAGUAYwBdACAAIwAxADYAOgAgAE0AdQBsAHQAaQBjAGEAcwB0AD8A x-cr-puzzleid: {FEF090C4-D196-4364-9E54-6B0EAE0497BC} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67E3162831G137681456-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 01:24:18 -0000 Hi Koen, In-line below... You wrote: > The essence, if I understand you correctly, is that there still exist =20 > low-end platforms with barely enough processing power to run a VoIP =20 > call. If such platforms use a naive FIFO scheduler, they'll create up =20 > to one frame of processing delay for encoder and decoder each, on top =20 > of the frame of buffering delay. [Raymond]: It doesn't have to be low-end platforms. I wouldn't consider=20 high-density VoIP gateways "low-end". What matters is whether the=20 processor is heavily loaded (i.e. busy at a high percentage of time)=20 with real-time tasks (and thus is just fast enough). I think this is=20 true for typical implementations of IP phones and VoIP gateways. I also wouldn't use the term "a na=EFve FIFO scheduler" to describe the=20 "run to completion" real-time scheduler that I talked about in my last=20 email, because that term seems to imply that it is a very simple-minded=20 and inferior approach used by an inexperienced person who doesn't know=20 anything better. My understanding from talking to the three senior=20 technical leads of Broadcom is that the reality is when you have many=20 real-time tasks that you need to handle concurrently, using a=20 prioritized interrupt-driven scheduler is just way too complex and=20 messy, and it doesn't even guarantee that you will get a lower delay if=20 you do go through the trouble. In contrast, the kind of "run to=20 completion" real-time scheduler that I talked about is a more elegant=20 solution as it simplifies the scheduling problem substantially and also=20 allows you to have more efficient utilization of the processor.=20 Other than these two points, your understanding of my main point is=20 correct. > The good news is that Moore's law will continue to drive down the =20 > fraction of platforms with such processing delay problems. [Raymond]: This may be true for PC but probably not true in general.=20 PC is a general-purpose computing device that has to handle numerous=20 possible tasks, and a voice phone call takes only a very small fraction=20 of the worst-case computational power requirement of a PC. In contrast,=20 for special-purpose dedicated hardware devices such as IP phones or=20 VoIP gateways, it would make no sense to use a processor that is many=20 times faster than the worst-case computational power requirement. For=20 the sake of cost and power efficiency, the designers of such special- purpose devices will want to use a processor that's just slightly faster than required, because then they can use the cheapest and/or lowest=20 power-consuming processor that's fast enough to get the job done. =20 If they choose to use a processor much faster than is required, then=20 competitors using processors just fast enough can have lower costs=20 and power consumption and can take market share away from them. A case in point: after its first appearance several decades ago, 8-bit=20 microprocessors are still widely used in many devices today despite the=20 several orders of magnitude of speed improvement provided by Moore's=20 Law, because those devices just don't need anything faster, so using=20 anything faster would be a waste of money and power consumption. My point is that we should not expect that future IP phones or gateways=20 will operate at a very low percentage point of the processor load just=20 because Moore's Law can improve processor speed over time. Therefore,=20 don't expect the 3X multiplier for codec frame size to go down much=20 below where they are now. In fact, if in addition to a VoIP call, a PC is heavily loaded with a=20 lot of other concurrent tasks, many of which may be real-time tasks=20 (e.g. video, playing/burning CD/DVD, networking, etc.), then it will be=20 difficult for the PC to have small encoding and decoding RTS delays (d2=20 and d5 in my delay analysis). In this case, the codec frame size=20 multiplier will be closer to 3X than to 1X, unless you are willing to=20 let the voice stream occasionally run out of real time and produce an=20 audible glitch (which is not acceptable from the voice quality=20 perspective). If you agree with this and agree that a PC sometimes=20 does get very heavily loaded, then if you don't want the voice stream to run out of real time, the worst-case codec-dependent delay for=20 PC can still be around 3X the codec frame size. > I'm a bit surprised by your analysis of "packet transmission delay", =20 > as it has little bearing on our multiplier (ie the change in delay as =20 > a function of frame size). See old posts. [Raymond]: I am not sure I understand what you are saying. You probably=20 misunderstood the goal of my analysis. I mentioned in my last email that=20 my delay analysis aimed to derive the lower and upper bounds of the=20 codec-dependent one-way delay as functions of both the codec frame size=20 AND the packet size. That "packet transmission delay" does depend on=20 the packet size, so it should be included. Also, including it doesn't=20 increase the lower bound of the delay (and the codec frame size=20 multiplier there); it only affects the upper bound. Or, are you saying the "packet transmission delay" depends on the packet=20 size, not the codec frame size, and therefore is not codec-dependent?=20 Well, we know the packet size should be a positive integer multiple of=20 the codec frame size. Once the codec frame size is determined, there=20 are only limited choices of packet sizes you can use, so in this sense=20 the packet size does depend on the codec frame size. Therefore, the=20 "packet transmission delay" indirectly depends on the choice of the=20 codec. Best Regards, Raymond From fluffy@cisco.com Wed May 26 20:37:03 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDB1C3A659C for ; Wed, 26 May 2010 20:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.495 X-Spam-Level: X-Spam-Status: No, score=-108.495 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7UKTGLwsDB3 for ; Wed, 26 May 2010 20:37:02 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 39DF53A63C9 for ; Wed, 26 May 2010 20:37:02 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMGABGF/UurR7H+/2dsb2JhbACSGIwOcaZNmgKCYIIzBINC X-IronPort-AV: E=Sophos;i="4.53,308,1272844800"; d="scan'208";a="258331335" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 27 May 2010 03:36:53 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o4R3aqWR015332; Thu, 27 May 2010 03:36:52 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Wed, 26 May 2010 21:36:51 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2575CD49-B0DE-4257-B9B7-A0F84D1A8F3F@cisco.com> References: To: codec@ietf.org X-Mailer: Apple Mail (2.1078) Subject: Re: [codec] #14: VAD and CNG? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 03:37:04 -0000 I think that the bulk of the people that work on emergency calls in the = ECRIT WG and much of the IESG are going to be very strong supporters of = exactly what Brian is saying here. The implications aren't a big deal = for the CODEC WG, just that you need to be able to use SDP to signal no = VAD. No one thinks an end user is going to go and change the = configuration in their phone before making an emergency call.=20 If you want the CODEC chairs to go ask the ECRIT WG Chairs if they think = this is a requirement for an internet codec, it's easy to make that = happen but they are going to tell us the same thing Brian is.=20 On May 24, 2010, at 12:20 PM, Brian Rosen wrote: > Okay, you asked for it :) >=20 > In any country, the codes used in another country for emergency = numbers are > used as service invocations for other services. You have to know what > country you are in to know what emergency numbers are. It is roughly > impossible (today) to know that with sufficient reliability. >=20 > You can place an emergency call to an e.164 in many countries. This = may > depend on which service. >=20 > The emergency call center (PSAP) can call you back. >=20 > A call placed to a call center can be transferred or upgraded to an > emergency call. This happens with relay centers used by disabled > individuals. >=20 > In all of these circumstances, VAD must be disabled. Emergency = calling > systems are filled with a lot of complexity that handle seldom = occurring > circumstances. However, when it comes to saving lives, seldom = occurring > circumstances are important. >=20 > Brian >=20 > ps - I have been working in this field for a number of years. You can = learn > a bit more about emergency calling from draft-ietf-ecrit-framework. = The > inability to turn off VAD in VoIP systems believed to have caused = actual > harm according to some of my associates who work in PSAPs. >=20 >=20 >=20 >=20 > On 5/24/10 1:37 PM, "Christian Hoene" wrote: >=20 >> Hi Brian, >>=20 >>> I'll be happy to go into the details, but phones may not know they = are in an >>> emergency call. No phone knows this today. There is some proposed >>> signaling that would tell them, IF the phone, and the service = provider >>> implement it, but even then, there are circumstances where the phone = won't >>> know. >>=20 >> If(called.number=3D=3D112 || called.number=3D=3D911 || = called.number=3DXYZ) >> EmergencyCall(); >>=20 >> See more at http://en.wikipedia.org/wiki/1-1-2 >> It is so easy to know... I do not get your arguments. >>=20 >> With best regards, >>=20 >> Christian=20 >>=20 >>=20 >>=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From koen.vos@skype.net Wed May 26 21:43:09 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AE953A677D for ; Wed, 26 May 2010 21:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.65 X-Spam-Level: * X-Spam-Status: No, score=1.65 tagged_above=-999 required=5 tests=[AWL=1.649, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpIlsm0orXhU for ; Wed, 26 May 2010 21:43:07 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id CEFEB3A680F for ; Wed, 26 May 2010 21:43:06 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 075892006D5CE; Thu, 27 May 2010 06:42:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=5mxlDc30daVA HMOJdHLngkFyKzM=; b=a+z4g+M00V5nEB+MmSmaNTJv9UxQc/mtQhbbaQO4R+u0 CXPrja8TZoM1141WWsQDnbCtDAqCBNWURkqRBf9s9GZv6erCgs7pJyVxKENb1ENG E/2GRQVxw3ANbKzLToRW4jh2HnCDsm+ops8piRrMLT6ptTeJCCGz+ll4Pj6QgJg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=RHwMe/kgnMI8T7cTaYFq R+vsrQkfRBS3Fzij5S3YWIhqWEgoCedz7Esl7RQIMx6ubDx/4aSCsUfUm5GBypvQ ImL1zod2mwMJvNuN/ELL933y9usNRVNeMDVt6Lh0BqK/dIM4vnP3UsCOUYD0cieM ivHIem+Yqc/NuJZbEs8KPW0= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 03CE32006D5CA; Thu, 27 May 2010 06:42:57 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixRvxviF9lhj; Thu, 27 May 2010 06:42:55 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 71BA12006D5CB; Thu, 27 May 2010 06:42:55 +0200 (CEST) Received: from adsl-71-141-115-202.dsl.snfc21.pacbell.net (adsl-71-141-115-202.dsl.snfc21.pacbell.net [71.141.115.202]) by mail.skype.net (Horde Framework) with HTTP; Wed, 26 May 2010 21:42:55 -0700 Message-ID: <20100526214255.206532jzf8wjld1r@mail.skype.net> Date: Wed, 26 May 2010 21:42:55 -0700 From: Koen Vos To: "Raymond (Juin-Hwey) Chen" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <07C815A7-8F3C-4F85-A275-4352D0080EEA@cisco.com> <909E12B9-984F-4051-A93E-2291EFE0A40E@cisco.com> <20100526151326.2882694zuaeslk3q@mail.skype.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 04:43:09 -0000 Quoting "Raymond (Juin-Hwey) Chen": > My point is that we should not expect that future IP phones or gateways > will operate at a very low percentage point of the processor load just > because Moore's Law can improve processor speed over time. In other words, future manufacturers won't spend a few dimes on =20 reducing delay, even though today they're happy to add several dollars =20 to the price just to enable wideband? That's a statement about the =20 relative importance of delay. For the discussion about transmission delay vs. frame size, see e.g. http://www.ietf.org/mail-archive/web/codec/current/msg01477.html koen. > Hi Koen, > > In-line below... > > You wrote: >> The essence, if I understand you correctly, is that there still exist >> low-end platforms with barely enough processing power to run a VoIP >> call. If such platforms use a naive FIFO scheduler, they'll create up >> to one frame of processing delay for encoder and decoder each, on top >> of the frame of buffering delay. > > [Raymond]: It doesn't have to be low-end platforms. I wouldn't consider > high-density VoIP gateways "low-end". What matters is whether the > processor is heavily loaded (i.e. busy at a high percentage of time) > with real-time tasks (and thus is just fast enough). I think this is > true for typical implementations of IP phones and VoIP gateways. > > I also wouldn't use the term "a na=EFve FIFO scheduler" to describe the > "run to completion" real-time scheduler that I talked about in my last > email, because that term seems to imply that it is a very simple-minded > and inferior approach used by an inexperienced person who doesn't know > anything better. My understanding from talking to the three senior > technical leads of Broadcom is that the reality is when you have many > real-time tasks that you need to handle concurrently, using a > prioritized interrupt-driven scheduler is just way too complex and > messy, and it doesn't even guarantee that you will get a lower delay if > you do go through the trouble. In contrast, the kind of "run to > completion" real-time scheduler that I talked about is a more elegant > solution as it simplifies the scheduling problem substantially and also > allows you to have more efficient utilization of the processor. > > Other than these two points, your understanding of my main point is > correct. > >> The good news is that Moore's law will continue to drive down the >> fraction of platforms with such processing delay problems. > > [Raymond]: This may be true for PC but probably not true in general. > PC is a general-purpose computing device that has to handle numerous > possible tasks, and a voice phone call takes only a very small fraction > of the worst-case computational power requirement of a PC. In contrast, > for special-purpose dedicated hardware devices such as IP phones or > VoIP gateways, it would make no sense to use a processor that is many > times faster than the worst-case computational power requirement. For > the sake of cost and power efficiency, the designers of such special- > purpose devices will want to use a processor that's just slightly faster > than required, because then they can use the cheapest and/or lowest > power-consuming processor that's fast enough to get the job done. > If they choose to use a processor much faster than is required, then > competitors using processors just fast enough can have lower costs > and power consumption and can take market share away from them. > > A case in point: after its first appearance several decades ago, 8-bit > microprocessors are still widely used in many devices today despite the > several orders of magnitude of speed improvement provided by Moore's > Law, because those devices just don't need anything faster, so using > anything faster would be a waste of money and power consumption. > > My point is that we should not expect that future IP phones or gateways > will operate at a very low percentage point of the processor load just > because Moore's Law can improve processor speed over time. Therefore, > don't expect the 3X multiplier for codec frame size to go down much > below where they are now. > > In fact, if in addition to a VoIP call, a PC is heavily loaded with a > lot of other concurrent tasks, many of which may be real-time tasks > (e.g. video, playing/burning CD/DVD, networking, etc.), then it will be > difficult for the PC to have small encoding and decoding RTS delays (d2 > and d5 in my delay analysis). In this case, the codec frame size > multiplier will be closer to 3X than to 1X, unless you are willing to > let the voice stream occasionally run out of real time and produce an > audible glitch (which is not acceptable from the voice quality > perspective). If you agree with this and agree that a PC sometimes > does get very heavily loaded, then if you don't want the voice stream > to run out of real time, the worst-case codec-dependent delay for > PC can still be around 3X the codec frame size. > >> I'm a bit surprised by your analysis of "packet transmission delay", >> as it has little bearing on our multiplier (ie the change in delay as >> a function of frame size). See old posts. > > [Raymond]: I am not sure I understand what you are saying. You probably > misunderstood the goal of my analysis. I mentioned in my last email that > my delay analysis aimed to derive the lower and upper bounds of the > codec-dependent one-way delay as functions of both the codec frame size > AND the packet size. That "packet transmission delay" does depend on > the packet size, so it should be included. Also, including it doesn't > increase the lower bound of the delay (and the codec frame size > multiplier there); it only affects the upper bound. > > Or, are you saying the "packet transmission delay" depends on the packet > size, not the codec frame size, and therefore is not codec-dependent? > Well, we know the packet size should be a positive integer multiple of > the codec frame size. Once the codec frame size is determined, there > are only limited choices of packet sizes you can use, so in this sense > the packet size does depend on the codec frame size. Therefore, the > "packet transmission delay" indirectly depends on the choice of the > codec. > > Best Regards, > > Raymond > > > From hoene@uni-tuebingen.de Thu May 27 03:45:25 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 216E63A68BA for ; Thu, 27 May 2010 03:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07KWe7yF1YTP for ; Thu, 27 May 2010 03:45:23 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id E4E2A3A68F9 for ; Thu, 27 May 2010 03:45:22 -0700 (PDT) Received: from hoeneT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4RAj7ID018674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 May 2010 12:45:08 +0200 From: "Christian Hoene" To: "'Koen Vos'" , "'Raymond \(Juin-Hwey\) Chen'" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <07C815A7! -8F3C-4F85-A275-4352D00 80EEA@cisco.com> <909E12B9-984F-4051-A93E-2291EFE0A40E@cisco.com> <20100526151326.2882694zuaeslk3q@mail.skype.net> <20100526214255.206532jzf8wjld1r@mail.skype.net> In-Reply-To: <20100526214255.206532jzf8wjld1r@mail.skype.net> Date: Thu, 27 May 2010 12:45:07 +0200 Message-ID: <002901cafd89$acf402e0$06dc08a0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr9Vx30wv2d857zRZSFAlE/S8FBegAKgh/g Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.242; VDF: 7.10.7.182; host: mx05); id=31713-1nSDjL Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 10:45:25 -0000 Hello Koen and Raymond, yesterdays, I had a brief look on ITU-T G.114 http://www1.cs.columbia.edu/~andreaf/new/documents/other/T-REC-G.114-2003= 05.pdf It might help in your discussion... Regarding Moore-law and so: We shall keep in mind that cannot continue = forever. Already today, due to Quantum tunneling and subthreshold leakage current very small semiconductor structures consume = increasing amounts of energy. Thus, it might not always be advisable to use the latest technology if power consumption shall be = low.=20 It is know that "CMOS circuits dissipate power by charging the various = load capacitances (mostly gate and wire capacitance, but also drain and some source capacitances) whenever they are switched. The = charge moved is the capacitance multiplied by the voltage change. Multiply by the switching frequency on the load capacitances to = get the current used, and multiply by voltage again to get the characteristic switching power dissipated by a CMOS device: P =3D = CV=B2f". C is the capacity (depending on the size of the structure) V is Voltage f is the powering frequency P is the power Thus, the power does not decrease if the calculation (e.g., the encoding = and decoding) is done faster or slower.=20 In order to save power in mobile device, Dynamic frequency scaling and = Dynamic voltage scaling change the frequency and/or the voltage to save power. If power consumption needs to be reduced, the = device reduces voltage and frequency and thus the calculation takes longer. Thus, even if the CPU can do the encoding/decoding at full = speed and in a fraction of the frame duration, it is not always advisable to do it like that. Instead, if energy supply is = limited, then calculations shall be slowed down. My argumentations above support the position of Raymond that device with = low processing power will be used and that this increases to the transmission delay. However, I am not an expert in system or chip = design and thus, I might have missed a few details or tradeoffs.=20 Nevertheless, in the end, my position is simple. The lesser the = computational complexity, the smaller the battery. This statement will remain true for future semiconductor technologies, too. Thus, a low = complexity mode and low delay mode is advisable for small, portable battery-powered devices such as wireless headsets, hearing = aids, or wireless sensor nodes. Or other kind of devices, which have problems with head dissipation. With best regards, Christian Hoene --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ >-----Original Message----- >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Koen Vos >Sent: Thursday, May 27, 2010 6:43 AM >To: Raymond (Juin-Hwey) Chen >Cc: codec@ietf.org >Subject: Re: [codec] #16: Multicast? > >Quoting "Raymond (Juin-Hwey) Chen": >> My point is that we should not expect that future IP phones or = gateways >> will operate at a very low percentage point of the processor load = just >> because Moore's Law can improve processor speed over time. > >In other words, future manufacturers won't spend a few dimes on >reducing delay, even though today they're happy to add several dollars >to the price just to enable wideband? That's a statement about the >relative importance of delay. > >For the discussion about transmission delay vs. frame size, see e.g. >http://www.ietf.org/mail-archive/web/codec/current/msg01477.html > >koen. > > > >> Hi Koen, >> >> In-line below... >> >> You wrote: >>> The essence, if I understand you correctly, is that there still = exist >>> low-end platforms with barely enough processing power to run a VoIP >>> call. If such platforms use a naive FIFO scheduler, they'll create = up >>> to one frame of processing delay for encoder and decoder each, on = top >>> of the frame of buffering delay. >> >> [Raymond]: It doesn't have to be low-end platforms. I wouldn't = consider >> high-density VoIP gateways "low-end". What matters is whether the >> processor is heavily loaded (i.e. busy at a high percentage of time) >> with real-time tasks (and thus is just fast enough). I think this is >> true for typical implementations of IP phones and VoIP gateways. >> >> I also wouldn't use the term "a na=EFve FIFO scheduler" to describe = the >> "run to completion" real-time scheduler that I talked about in my = last >> email, because that term seems to imply that it is a very = simple-minded >> and inferior approach used by an inexperienced person who doesn't = know >> anything better. My understanding from talking to the three senior >> technical leads of Broadcom is that the reality is when you have many >> real-time tasks that you need to handle concurrently, using a >> prioritized interrupt-driven scheduler is just way too complex and >> messy, and it doesn't even guarantee that you will get a lower delay = if >> you do go through the trouble. In contrast, the kind of "run to >> completion" real-time scheduler that I talked about is a more elegant >> solution as it simplifies the scheduling problem substantially and = also >> allows you to have more efficient utilization of the processor. >> >> Other than these two points, your understanding of my main point is >> correct. >> >>> The good news is that Moore's law will continue to drive down the >>> fraction of platforms with such processing delay problems. >> >> [Raymond]: This may be true for PC but probably not true in general. >> PC is a general-purpose computing device that has to handle numerous >> possible tasks, and a voice phone call takes only a very small = fraction >> of the worst-case computational power requirement of a PC. In = contrast, >> for special-purpose dedicated hardware devices such as IP phones or >> VoIP gateways, it would make no sense to use a processor that is many >> times faster than the worst-case computational power requirement. = For >> the sake of cost and power efficiency, the designers of such special- >> purpose devices will want to use a processor that's just slightly = faster >> than required, because then they can use the cheapest and/or lowest >> power-consuming processor that's fast enough to get the job done. >> If they choose to use a processor much faster than is required, then >> competitors using processors just fast enough can have lower costs >> and power consumption and can take market share away from them. >> >> A case in point: after its first appearance several decades ago, = 8-bit >> microprocessors are still widely used in many devices today despite = the >> several orders of magnitude of speed improvement provided by Moore's >> Law, because those devices just don't need anything faster, so using >> anything faster would be a waste of money and power consumption. >> >> My point is that we should not expect that future IP phones or = gateways >> will operate at a very low percentage point of the processor load = just >> because Moore's Law can improve processor speed over time. Therefore, >> don't expect the 3X multiplier for codec frame size to go down much >> below where they are now. >> >> In fact, if in addition to a VoIP call, a PC is heavily loaded with a >> lot of other concurrent tasks, many of which may be real-time tasks >> (e.g. video, playing/burning CD/DVD, networking, etc.), then it will = be >> difficult for the PC to have small encoding and decoding RTS delays = (d2 >> and d5 in my delay analysis). In this case, the codec frame size >> multiplier will be closer to 3X than to 1X, unless you are willing to >> let the voice stream occasionally run out of real time and produce an >> audible glitch (which is not acceptable from the voice quality >> perspective). If you agree with this and agree that a PC sometimes >> does get very heavily loaded, then if you don't want the voice stream >> to run out of real time, the worst-case codec-dependent delay for >> PC can still be around 3X the codec frame size. >> >>> I'm a bit surprised by your analysis of "packet transmission delay", >>> as it has little bearing on our multiplier (ie the change in delay = as >>> a function of frame size). See old posts. >> >> [Raymond]: I am not sure I understand what you are saying. You = probably >> misunderstood the goal of my analysis. I mentioned in my last email = that >> my delay analysis aimed to derive the lower and upper bounds of the >> codec-dependent one-way delay as functions of both the codec frame = size >> AND the packet size. That "packet transmission delay" does depend on >> the packet size, so it should be included. Also, including it = doesn't >> increase the lower bound of the delay (and the codec frame size >> multiplier there); it only affects the upper bound. >> >> Or, are you saying the "packet transmission delay" depends on the = packet >> size, not the codec frame size, and therefore is not codec-dependent? >> Well, we know the packet size should be a positive integer multiple = of >> the codec frame size. Once the codec frame size is determined, there >> are only limited choices of packet sizes you can use, so in this = sense >> the packet size does depend on the codec frame size. Therefore, the >> "packet transmission delay" indirectly depends on the choice of the >> codec. >> >> Best Regards, >> >> Raymond >> >> >> > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From hoene@uni-tuebingen.de Thu May 27 03:49:18 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFA333A6781; Thu, 27 May 2010 03:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3haxnM9nonQU; Thu, 27 May 2010 03:49:16 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 567C23A6880; Thu, 27 May 2010 03:49:16 -0700 (PDT) Received: from hoeneT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4RAmvSu003951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 May 2010 12:48:58 +0200 From: "Christian Hoene" To: "'Cullen Jennings'" , References: <2575CD49-B0DE-4257-B9B7-A0F84D1A8F3F@cisco.com> In-Reply-To: <2575CD49-B0DE-4257-B9B7-A0F84D1A8F3F@cisco.com> Date: Thu, 27 May 2010 12:48:58 +0200 Message-ID: <002a01cafd8a$3691f610$a3b5e230$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr9TeFvwAIcoQvjTqijHtTrJC4yEQAON8cg Content-Language: de x-cr-hashedpuzzle: IYQt Ix0f I6YU Jh7D LrlL Ocnd P51K Q/Cb TqJJ VuXt WLse ZFae eIEq jrbT k+Jd lzBm; 4; YgByAEAAYgByAGkAYQBuAHIAbwBzAGUAbgAuAG4AZQB0ADsAYwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAZQBjAHIAaQB0AEAAaQBlAHQAZgAuAG8AcgBnADsAZgBsAHUAZgBmAHkAQABjAGkAcwBjAG8ALgBjAG8AbQA=; Sosha1_v1; 7; {F07F4252-EE12-49CE-A695-F7B5DDFFBE02}; aABvAGUAbgBlAEAAdQBuAGkALQB0AHUAZQBiAGkAbgBnAGUAbgAuAGQAZQA=; Thu, 27 May 2010 10:48:09 GMT; UwBwAGUAZQBjAGgAIABRAHUAYQBsAGkAdAB5ACAAQQBzAHAAZQBjAHQAcwAgAGkAbgAgAGUAbQBlAHIAZwBlAG4AYwB5ACAAYwBhAGwAbABzAA== x-cr-puzzleid: {F07F4252-EE12-49CE-A695-F7B5DDFFBE02} X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: ecrit@ietf.org Subject: [codec] Speech Quality Aspects in emergency calls X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 10:49:18 -0000 Hello Cullen, dear ECRIT experts, >I think that the bulk of the people that work on emergency calls in the ECRIT WG and much of the IESG >are going to be very strong supporters of exactly what Brian is saying here. I agree that the support of emergency call are important, also in the IETF WG Codec. However, at this point of time it is not clear to me what the service requirements of an emergency call are going to be. Which speech/audio quality requirements do the emergency agencies have? Brian is suggesting a technical solution to become a requirement. But, don't we have to listen to the users, first? Only then, we can develop a technical solutions that might affect our work in the Codec WG. > The implications aren't a >big deal for the CODEC WG, just that you need to be able to use SDP to signal no VAD. Are you sure that this is the only requirement? I think that there are other important things in case of emergency calls. Do they need audio quality? Do they need ultra-low-delay or is any transmission delay fine? What shall happen, if the transmission quality is bad? Push-to-talk? > No one thinks an >end user is going to go and change the configuration in their phone before making an emergency call. No, he does know VAD and he does not care about. Some part of the system must take care of. However, the user does know that he wants to make a emergency call and the phone might have a button called "emergency call". >If you want the CODEC chairs to go ask the ECRIT WG Chairs if they think this is a requirement for an >internet codec, it's easy to make that happen but they are going to tell us the same thing Brian is. Good idea, I carbon-copied this email to the ECRIT mailing list, if you do not mind. With best regards, Christian > > > >On May 24, 2010, at 12:20 PM, Brian Rosen wrote: > >> Okay, you asked for it :) >> >> In any country, the codes used in another country for emergency numbers are >> used as service invocations for other services. You have to know what >> country you are in to know what emergency numbers are. It is roughly >> impossible (today) to know that with sufficient reliability. >> >> You can place an emergency call to an e.164 in many countries. This may >> depend on which service. >> >> The emergency call center (PSAP) can call you back. >> >> A call placed to a call center can be transferred or upgraded to an >> emergency call. This happens with relay centers used by disabled >> individuals. >> >> In all of these circumstances, VAD must be disabled. Emergency calling >> systems are filled with a lot of complexity that handle seldom occurring >> circumstances. However, when it comes to saving lives, seldom occurring >> circumstances are important. >> >> Brian >> >> ps - I have been working in this field for a number of years. You can learn >> a bit more about emergency calling from draft-ietf-ecrit-framework. The >> inability to turn off VAD in VoIP systems believed to have caused actual >> harm according to some of my associates who work in PSAPs. >> >> >> >> >> On 5/24/10 1:37 PM, "Christian Hoene" wrote: >> >>> Hi Brian, >>> >>>> I'll be happy to go into the details, but phones may not know they are in an >>>> emergency call. No phone knows this today. There is some proposed >>>> signaling that would tell them, IF the phone, and the service provider >>>> implement it, but even then, there are circumstances where the phone won't >>>> know. >>> >>> If(called.number==112 || called.number==911 || called.number=XYZ) >>> EmergencyCall(); >>> >>> See more at http://en.wikipedia.org/wiki/1-1-2 >>> It is so easy to know... I do not get your arguments. >>> >>> With best regards, >>> >>> Christian >>> >>> >>> >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec From jean-marc.valin@usherbrooke.ca Thu May 27 04:48:00 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89F533A6ACA for ; Thu, 27 May 2010 04:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEYdB0OBw2CX for ; Thu, 27 May 2010 04:47:59 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id A212D3A6AC9 for ; Thu, 27 May 2010 04:47:59 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from [192.168.1.14] ([70.81.109.112]) by VL-MR-MR001.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0L32001QSU3PWAH0@VL-MR-MR001.ip.videotron.ca> for codec@ietf.org; Thu, 27 May 2010 07:47:50 -0400 (EDT) Message-id: <4BFE5BE7.503@usherbrooke.ca> Date: Thu, 27 May 2010 07:47:51 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 To: Christian Hoene References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <909E12B9-984F-4051-A93E-2291EFE0A40E@cisco.com> <20100526151326.2882694zuaeslk3q@mail.skype.net> <20100526214255.206532jzf8wjld1r@mail.skype.net> <002901cafd89$acf402e0$06dc08a0$@de> In-reply-to: <002901cafd89$acf402e0$06dc08a0$@de> Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 11:48:00 -0000 Christian, please leave semiconductor physics out of this. FYI, see below: On 10-05-27 06:45 AM, Christian Hoene wrote: > Regarding Moore-law and so: We shall keep in mind that cannot continue forever. Already today, due to Quantum tunneling and > subthreshold leakage current very small semiconductor structures consume increasing amounts of energy. Thus, it might not always be > advisable to use the latest technology if power consumption shall be low. Although power no longer scales linearly with the area of the transistors, it still decreases when one uses a smaller technology (with the exception being the huge leakage from 65 nm). > It is know that "CMOS circuits dissipate power by charging the various load capacitances (mostly gate and wire capacitance, but also > drain and some source capacitances) whenever they are switched. The charge moved is the capacitance multiplied by the voltage > change. Multiply by the switching frequency on the load capacitances to get the current used, and multiply by voltage again to get > the characteristic switching power dissipated by a CMOS device: P = CVf". > ... > Thus, the power does not decrease if the calculation (e.g., the encoding and decoding) is done faster or slower. Euh?? what about f? That's the part that takes into account faster vs slower. Even if you don't change the clock, the amount of calculations you have still has an impact on power. Once you've paid for the idle (static) power, the dynamic power is pretty much proportional to how fast you do your calculation. That being said, there's also about 100 other factors involved in the power consumption, including the technology used (low/standard/high threshold gates), tons of architectural decisions (cache, branch prediction, parallelism, ...), power-saving features, and so on. > In order to save power in mobile device, Dynamic frequency scaling and Dynamic voltage scaling change the frequency and/or the > voltage to save power. If power consumption needs to be reduced, the device reduces voltage and frequency and thus the calculation > takes longer. Thus, even if the CPU can do the encoding/decoding at full speed and in a fraction of the frame duration, it is not > always advisable to do it like that. Instead, if energy supply is limited, then calculations shall be slowed down. Many people have found that for a given CPU, it's very often more efficient to do the calculation at full-speed and then enter the low-power state as quickly as possible -- as opposed to making the calculation slower and being in low-power state for less time. The term for that is "race to idle". > My argumentations above support the position of Raymond that device with low processing power will be used and that this increases > to the transmission delay. However, I am not an expert in system or chip design and thus, I might have missed a few details or > tradeoffs. No need to go into chip design to say that "lower complexity is better". The key is deciding what's acceptable and what's the tradeoff. If complexity was the only issue, we'd all be using G.711. No matter what the final complexity will be, there will be chips that aren't powerful to execute it and there will be chips that are so powerful that they don't wouldn't notice if the complexity doubled. Cheers, Jean-Marc From herve.taddei@huawei.com Thu May 27 04:53:58 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27AB13A6AC2 for ; Thu, 27 May 2010 04:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0Si0YOL3pBL for ; Thu, 27 May 2010 04:53:56 -0700 (PDT) Received: from lhrga04-in.huawei.com (lhrga04-in.huawei.com [195.33.106.149]) by core3.amsl.com (Postfix) with ESMTP id 1CEB33A6AB5 for ; Thu, 27 May 2010 04:53:56 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3200L7ZUDIO0@lhrga04-in.huawei.com> for codec@ietf.org; Thu, 27 May 2010 12:53:43 +0100 (BST) Received: from h00900001 ([10.200.70.185]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3200149UDDC5@lhrga04-in.huawei.com> for codec@ietf.org; Thu, 27 May 2010 12:53:42 +0100 (BST) Date: Thu, 27 May 2010 13:53:36 +0200 From: Herve Taddei In-reply-to: <002901cafd89$acf402e0$06dc08a0$@de> To: 'Christian Hoene' , 'Koen Vos' , "'Raymond (Juin-Hwey) Chen'" Message-id: <19367DD02EBD40829869907AEA0CE128@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: Acr9Vx30wv2d857zRZSFAlE/S8FBegAKgh/gAANeldA= iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated. References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <"CB68DF4CFBEF49428 8C74B9043D30B"@IRVEXCHCCR01.corp.ad.broadcom.com> <909E12B9-984F-4051-A93E-2291EFE0A40E@cisco.com> <20100526151326.2882694zuaeslk3q@mail.skype.net> <20100526214255.206532jzf8wjld1r@mail.skype.net> <002901cafd89$acf402e0$06dc08a0$@de> Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 11:53:58 -0000 Hi Christian, > Nevertheless, in the end, my position is simple. The lesser the computational > complexity, the smaller the battery. This statement > will remain true for future semiconductor technologies, too. Thus, a = low complexity > mode and low delay mode is advisable for small, > portable battery-powered devices such as wireless headsets, hearing = aids, or > wireless sensor nodes. Or other kind of devices, which > have problems with head dissipation. Are all those devices being of interest for the codec under development? = For example is it your plan to make use of the IETF codec in hearing aids? = In that case, perhaps requirements for hearing aids should be discussed and added to the requirements. But I am not sure it is really relevant for = an audio codec designed specifically for use over the Internet. Best regards Herve Taddei > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of > Christian Hoene > Sent: Thursday, May 27, 2010 12:45 PM > To: 'Koen Vos'; 'Raymond (Juin-Hwey) Chen' > Cc: codec@ietf.org > Subject: Re: [codec] #16: Multicast? >=20 > Hello Koen and Raymond, >=20 > yesterdays, I had a brief look on ITU-T G.114 > http://www1.cs.columbia.edu/~andreaf/new/documents/other/T-REC-G.114- > 200305.pdf > It might help in your discussion... >=20 > Regarding Moore-law and so: We shall keep in mind that cannot continue forever. > Already today, due to Quantum tunneling and > subthreshold leakage current very small semiconductor structures = consume > increasing amounts of energy. Thus, it might not always be > advisable to use the latest technology if power consumption shall be = low. >=20 > It is know that "CMOS circuits dissipate power by charging the various load > capacitances (mostly gate and wire capacitance, but also > drain and some source capacitances) whenever they are switched. The = charge > moved is the capacitance multiplied by the voltage > change. Multiply by the switching frequency on the load capacitances = to get the > current used, and multiply by voltage again to get > the characteristic switching power dissipated by a CMOS device: P =3D = CV=B2f". >=20 > C is the capacity (depending on the size of the structure) > V is Voltage > f is the powering frequency > P is the power >=20 > Thus, the power does not decrease if the calculation (e.g., the = encoding and > decoding) is done faster or slower. >=20 > In order to save power in mobile device, Dynamic frequency scaling and Dynamic > voltage scaling change the frequency and/or the > voltage to save power. If power consumption needs to be reduced, the device > reduces voltage and frequency and thus the calculation > takes longer. Thus, even if the CPU can do the encoding/decoding at = full speed > and in a fraction of the frame duration, it is not > always advisable to do it like that. Instead, if energy supply is = limited, then > calculations shall be slowed down. >=20 > My argumentations above support the position of Raymond that device = with low > processing power will be used and that this increases > to the transmission delay. However, I am not an expert in system or = chip design > and thus, I might have missed a few details or > tradeoffs. >=20 > Nevertheless, in the end, my position is simple. The lesser the computational > complexity, the smaller the battery. This statement > will remain true for future semiconductor technologies, too. Thus, a = low complexity > mode and low delay mode is advisable for small, > portable battery-powered devices such as wireless headsets, hearing = aids, or > wireless sensor nodes. Or other kind of devices, which > have problems with head dissipation. >=20 > With best regards, >=20 > Christian Hoene >=20 > --------------------------------------------------------------- > Dr.-Ing. Christian Hoene > Interactive Communication Systems (ICS), University of T=FCbingen > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ >=20 >=20 > >-----Original Message----- > >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On = Behalf Of > Koen Vos > >Sent: Thursday, May 27, 2010 6:43 AM > >To: Raymond (Juin-Hwey) Chen > >Cc: codec@ietf.org > >Subject: Re: [codec] #16: Multicast? > > > >Quoting "Raymond (Juin-Hwey) Chen": > >> My point is that we should not expect that future IP phones or = gateways > >> will operate at a very low percentage point of the processor load = just > >> because Moore's Law can improve processor speed over time. > > > >In other words, future manufacturers won't spend a few dimes on > >reducing delay, even though today they're happy to add several = dollars > >to the price just to enable wideband? That's a statement about the > >relative importance of delay. > > > >For the discussion about transmission delay vs. frame size, see e.g. > >http://www.ietf.org/mail-archive/web/codec/current/msg01477.html > > > >koen. > > > > > > > >> Hi Koen, > >> > >> In-line below... > >> > >> You wrote: > >>> The essence, if I understand you correctly, is that there still = exist > >>> low-end platforms with barely enough processing power to run a = VoIP > >>> call. If such platforms use a naive FIFO scheduler, they'll = create up > >>> to one frame of processing delay for encoder and decoder each, on = top > >>> of the frame of buffering delay. > >> > >> [Raymond]: It doesn't have to be low-end platforms. I wouldn't consider > >> high-density VoIP gateways "low-end". What matters is whether the > >> processor is heavily loaded (i.e. busy at a high percentage of = time) > >> with real-time tasks (and thus is just fast enough). I think this = is > >> true for typical implementations of IP phones and VoIP gateways. > >> > >> I also wouldn't use the term "a na=EFve FIFO scheduler" to describe = the > >> "run to completion" real-time scheduler that I talked about in my = last > >> email, because that term seems to imply that it is a very = simple-minded > >> and inferior approach used by an inexperienced person who doesn't = know > >> anything better. My understanding from talking to the three senior > >> technical leads of Broadcom is that the reality is when you have = many > >> real-time tasks that you need to handle concurrently, using a > >> prioritized interrupt-driven scheduler is just way too complex and > >> messy, and it doesn't even guarantee that you will get a lower = delay if > >> you do go through the trouble. In contrast, the kind of "run to > >> completion" real-time scheduler that I talked about is a more = elegant > >> solution as it simplifies the scheduling problem substantially and = also > >> allows you to have more efficient utilization of the processor. > >> > >> Other than these two points, your understanding of my main point is > >> correct. > >> > >>> The good news is that Moore's law will continue to drive down the > >>> fraction of platforms with such processing delay problems. > >> > >> [Raymond]: This may be true for PC but probably not true in = general. > >> PC is a general-purpose computing device that has to handle = numerous > >> possible tasks, and a voice phone call takes only a very small = fraction > >> of the worst-case computational power requirement of a PC. In contrast, > >> for special-purpose dedicated hardware devices such as IP phones or > >> VoIP gateways, it would make no sense to use a processor that is = many > >> times faster than the worst-case computational power requirement. = For > >> the sake of cost and power efficiency, the designers of such = special- > >> purpose devices will want to use a processor that's just slightly faster > >> than required, because then they can use the cheapest and/or lowest > >> power-consuming processor that's fast enough to get the job done. > >> If they choose to use a processor much faster than is required, = then > >> competitors using processors just fast enough can have lower costs > >> and power consumption and can take market share away from them. > >> > >> A case in point: after its first appearance several decades ago, = 8-bit > >> microprocessors are still widely used in many devices today despite = the > >> several orders of magnitude of speed improvement provided by = Moore's > >> Law, because those devices just don't need anything faster, so = using > >> anything faster would be a waste of money and power consumption. > >> > >> My point is that we should not expect that future IP phones or = gateways > >> will operate at a very low percentage point of the processor load = just > >> because Moore's Law can improve processor speed over time. = Therefore, > >> don't expect the 3X multiplier for codec frame size to go down much > >> below where they are now. > >> > >> In fact, if in addition to a VoIP call, a PC is heavily loaded with = a > >> lot of other concurrent tasks, many of which may be real-time tasks > >> (e.g. video, playing/burning CD/DVD, networking, etc.), then it = will be > >> difficult for the PC to have small encoding and decoding RTS delays = (d2 > >> and d5 in my delay analysis). In this case, the codec frame size > >> multiplier will be closer to 3X than to 1X, unless you are willing = to > >> let the voice stream occasionally run out of real time and produce = an > >> audible glitch (which is not acceptable from the voice quality > >> perspective). If you agree with this and agree that a PC sometimes > >> does get very heavily loaded, then if you don't want the voice = stream > >> to run out of real time, the worst-case codec-dependent delay for > >> PC can still be around 3X the codec frame size. > >> > >>> I'm a bit surprised by your analysis of "packet transmission = delay", > >>> as it has little bearing on our multiplier (ie the change in delay = as > >>> a function of frame size). See old posts. > >> > >> [Raymond]: I am not sure I understand what you are saying. You probably > >> misunderstood the goal of my analysis. I mentioned in my last email that > >> my delay analysis aimed to derive the lower and upper bounds of the > >> codec-dependent one-way delay as functions of both the codec frame = size > >> AND the packet size. That "packet transmission delay" does depend = on > >> the packet size, so it should be included. Also, including it = doesn't > >> increase the lower bound of the delay (and the codec frame size > >> multiplier there); it only affects the upper bound. > >> > >> Or, are you saying the "packet transmission delay" depends on the packet > >> size, not the codec frame size, and therefore is not = codec-dependent? > >> Well, we know the packet size should be a positive integer multiple = of > >> the codec frame size. Once the codec frame size is determined, = there > >> are only limited choices of packet sizes you can use, so in this = sense > >> the packet size does depend on the codec frame size. Therefore, = the > >> "packet transmission delay" indirectly depends on the choice of the > >> codec. > >> > >> Best Regards, > >> > >> Raymond > >> > >> > >> > > > >_______________________________________________ > >codec mailing list > >codec@ietf.org > >https://www.ietf.org/mailman/listinfo/codec >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From hoene@uni-tuebingen.de Thu May 27 05:50:21 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9C933A68BA for ; Thu, 27 May 2010 05:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.019 X-Spam-Level: X-Spam-Status: No, score=-4.019 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iruY2Uck4DB for ; Thu, 27 May 2010 05:50:17 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 889CF3A68B9 for ; Thu, 27 May 2010 05:50:16 -0700 (PDT) Received: from hoeneT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4RCngLt007312 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 May 2010 14:49:43 +0200 From: "Christian Hoene" To: "'Herve Taddei'" , "'Koen Vos'" , "'Raymond \(Juin-Hwey\) Chen'" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <"CB68DF4! CFBEF49428 8C74B9043D30 B"@IRVEXCHCCR01.corp.ad.broadcom.com> <909E12B9-984F-4051-A93E-2291EFE0A40E@cisco.com> <20100526151326.2882694zuaeslk3q@mail.skype.net> <20100526214255.206532jzf8wjld1r@mail.skype.net> <002901cafd89$acf402e0$06dc08a0$@de> <19367DD02EBD40829869907AEA0CE128@china.huawei.com> In-Reply-To: <19367DD02EBD40829869907AEA0CE128@china.huawei.com> Date: Thu, 27 May 2010 14:49:42 +0200 Message-ID: <000601cafd9b$148fd850$3daf88f0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Acr9Vx30wv2d857zRZSFAlE/S8FBegAKgh/gAANeldAAAYk3sA== Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.242; VDF: 7.10.7.183; host: mx05); id=31713-PiQOox Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 12:50:21 -0000 Guys, all I want to do is to find an end to this discussion. Sometimes it = helps to come up with some provocative statements. The example of hearing aids was mentioned only as an example of a device = that might include a phone in future. If you will, I forgot to mention the tooth-phone = http://www.wired.com/science/discoveries/news/2002/06/53302=20 Anyhow, shall we consider that a) devices have plenty of power to do the coding (<2% needed for the = codec)=20 b) devices are already fully loaded and need all time for encoding and = decoding (100% needed for codec and signal processing) xy) between X% and Y%. What is the minimal complexity of the codec? Enough to run at 100% load = on a=20 a) 10 MIPS DSP b) 50 MIPS DSP c) 8000 MIPS DSP d) 60 MHz Pentium e) 1 GHz Pentium How to measure the complexity? a) with gettimeofday on a reference PC setup b) with ITU-T G.191 library c) With a reference virtual machine=20 Decide and continue... Christian --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ >-----Original Message----- >From: Herve Taddei [mailto:herve.taddei@huawei.com] >Sent: Thursday, May 27, 2010 1:54 PM >To: 'Christian Hoene'; 'Koen Vos'; 'Raymond (Juin-Hwey) Chen' >Cc: codec@ietf.org >Subject: RE: [codec] #16: Multicast? > >Hi Christian, > >> Nevertheless, in the end, my position is simple. The lesser the >computational >> complexity, the smaller the battery. This statement >> will remain true for future semiconductor technologies, too. Thus, a = low >complexity >> mode and low delay mode is advisable for small, >> portable battery-powered devices such as wireless headsets, hearing = aids, >or >> wireless sensor nodes. Or other kind of devices, which >> have problems with head dissipation. >Are all those devices being of interest for the codec under = development? For >example is it your plan to make use of the IETF codec in hearing aids? = In >that case, perhaps requirements for hearing aids should be discussed = and >added to the requirements. But I am not sure it is really relevant for = an >audio codec designed specifically for use over the Internet. > >Best regards > >Herve Taddei > >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On = Behalf Of >> Christian Hoene >> Sent: Thursday, May 27, 2010 12:45 PM >> To: 'Koen Vos'; 'Raymond (Juin-Hwey) Chen' >> Cc: codec@ietf.org >> Subject: Re: [codec] #16: Multicast? >> >> Hello Koen and Raymond, >> >> yesterdays, I had a brief look on ITU-T G.114 >> http://www1.cs.columbia.edu/~andreaf/new/documents/other/T-REC-G.114- >> 200305.pdf >> It might help in your discussion... >> >> Regarding Moore-law and so: We shall keep in mind that cannot = continue >forever. >> Already today, due to Quantum tunneling and >> subthreshold leakage current very small semiconductor structures = consume >> increasing amounts of energy. Thus, it might not always be >> advisable to use the latest technology if power consumption shall be = low. >> >> It is know that "CMOS circuits dissipate power by charging the = various >load >> capacitances (mostly gate and wire capacitance, but also >> drain and some source capacitances) whenever they are switched. The = charge >> moved is the capacitance multiplied by the voltage >> change. Multiply by the switching frequency on the load capacitances = to >get the >> current used, and multiply by voltage again to get >> the characteristic switching power dissipated by a CMOS device: P =3D = CV=B2f". >> >> C is the capacity (depending on the size of the structure) >> V is Voltage >> f is the powering frequency >> P is the power >> >> Thus, the power does not decrease if the calculation (e.g., the = encoding >and >> decoding) is done faster or slower. >> >> In order to save power in mobile device, Dynamic frequency scaling = and >Dynamic >> voltage scaling change the frequency and/or the >> voltage to save power. If power consumption needs to be reduced, the >device >> reduces voltage and frequency and thus the calculation >> takes longer. Thus, even if the CPU can do the encoding/decoding at = full >speed >> and in a fraction of the frame duration, it is not >> always advisable to do it like that. Instead, if energy supply is = limited, >then >> calculations shall be slowed down. >> >> My argumentations above support the position of Raymond that device = with >low >> processing power will be used and that this increases >> to the transmission delay. However, I am not an expert in system or = chip >design >> and thus, I might have missed a few details or >> tradeoffs. >> >> Nevertheless, in the end, my position is simple. The lesser the >computational >> complexity, the smaller the battery. This statement >> will remain true for future semiconductor technologies, too. Thus, a = low >complexity >> mode and low delay mode is advisable for small, >> portable battery-powered devices such as wireless headsets, hearing = aids, >or >> wireless sensor nodes. Or other kind of devices, which >> have problems with head dissipation. >> >> With best regards, >> >> Christian Hoene >> >> --------------------------------------------------------------- >> Dr.-Ing. Christian Hoene >> Interactive Communication Systems (ICS), University of T=FCbingen >> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >> http://www.net.uni-tuebingen.de/ >> >> >> >-----Original Message----- >> >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On = Behalf Of >> Koen Vos >> >Sent: Thursday, May 27, 2010 6:43 AM >> >To: Raymond (Juin-Hwey) Chen >> >Cc: codec@ietf.org >> >Subject: Re: [codec] #16: Multicast? >> > >> >Quoting "Raymond (Juin-Hwey) Chen": >> >> My point is that we should not expect that future IP phones or = gateways >> >> will operate at a very low percentage point of the processor load = just >> >> because Moore's Law can improve processor speed over time. >> > >> >In other words, future manufacturers won't spend a few dimes on >> >reducing delay, even though today they're happy to add several = dollars >> >to the price just to enable wideband? That's a statement about the >> >relative importance of delay. >> > >> >For the discussion about transmission delay vs. frame size, see e.g. >> >http://www.ietf.org/mail-archive/web/codec/current/msg01477.html >> > >> >koen. >> > >> > >> > >> >> Hi Koen, >> >> >> >> In-line below... >> >> >> >> You wrote: >> >>> The essence, if I understand you correctly, is that there still = exist >> >>> low-end platforms with barely enough processing power to run a = VoIP >> >>> call. If such platforms use a naive FIFO scheduler, they'll = create up >> >>> to one frame of processing delay for encoder and decoder each, on = top >> >>> of the frame of buffering delay. >> >> >> >> [Raymond]: It doesn't have to be low-end platforms. I wouldn't >consider >> >> high-density VoIP gateways "low-end". What matters is whether the >> >> processor is heavily loaded (i.e. busy at a high percentage of = time) >> >> with real-time tasks (and thus is just fast enough). I think this = is >> >> true for typical implementations of IP phones and VoIP gateways. >> >> >> >> I also wouldn't use the term "a na=EFve FIFO scheduler" to = describe the >> >> "run to completion" real-time scheduler that I talked about in my = last >> >> email, because that term seems to imply that it is a very = simple-minded >> >> and inferior approach used by an inexperienced person who doesn't = know >> >> anything better. My understanding from talking to the three = senior >> >> technical leads of Broadcom is that the reality is when you have = many >> >> real-time tasks that you need to handle concurrently, using a >> >> prioritized interrupt-driven scheduler is just way too complex and >> >> messy, and it doesn't even guarantee that you will get a lower = delay if >> >> you do go through the trouble. In contrast, the kind of "run to >> >> completion" real-time scheduler that I talked about is a more = elegant >> >> solution as it simplifies the scheduling problem substantially and = also >> >> allows you to have more efficient utilization of the processor. >> >> >> >> Other than these two points, your understanding of my main point = is >> >> correct. >> >> >> >>> The good news is that Moore's law will continue to drive down the >> >>> fraction of platforms with such processing delay problems. >> >> >> >> [Raymond]: This may be true for PC but probably not true in = general. >> >> PC is a general-purpose computing device that has to handle = numerous >> >> possible tasks, and a voice phone call takes only a very small = fraction >> >> of the worst-case computational power requirement of a PC. In >contrast, >> >> for special-purpose dedicated hardware devices such as IP phones = or >> >> VoIP gateways, it would make no sense to use a processor that is = many >> >> times faster than the worst-case computational power requirement. = For >> >> the sake of cost and power efficiency, the designers of such = special- >> >> purpose devices will want to use a processor that's just slightly >faster >> >> than required, because then they can use the cheapest and/or = lowest >> >> power-consuming processor that's fast enough to get the job done. >> >> If they choose to use a processor much faster than is required, = then >> >> competitors using processors just fast enough can have lower costs >> >> and power consumption and can take market share away from them. >> >> >> >> A case in point: after its first appearance several decades ago, = 8-bit >> >> microprocessors are still widely used in many devices today = despite the >> >> several orders of magnitude of speed improvement provided by = Moore's >> >> Law, because those devices just don't need anything faster, so = using >> >> anything faster would be a waste of money and power consumption. >> >> >> >> My point is that we should not expect that future IP phones or = gateways >> >> will operate at a very low percentage point of the processor load = just >> >> because Moore's Law can improve processor speed over time. = Therefore, >> >> don't expect the 3X multiplier for codec frame size to go down = much >> >> below where they are now. >> >> >> >> In fact, if in addition to a VoIP call, a PC is heavily loaded = with a >> >> lot of other concurrent tasks, many of which may be real-time = tasks >> >> (e.g. video, playing/burning CD/DVD, networking, etc.), then it = will be >> >> difficult for the PC to have small encoding and decoding RTS = delays (d2 >> >> and d5 in my delay analysis). In this case, the codec frame size >> >> multiplier will be closer to 3X than to 1X, unless you are willing = to >> >> let the voice stream occasionally run out of real time and produce = an >> >> audible glitch (which is not acceptable from the voice quality >> >> perspective). If you agree with this and agree that a PC = sometimes >> >> does get very heavily loaded, then if you don't want the voice = stream >> >> to run out of real time, the worst-case codec-dependent delay for >> >> PC can still be around 3X the codec frame size. >> >> >> >>> I'm a bit surprised by your analysis of "packet transmission = delay", >> >>> as it has little bearing on our multiplier (ie the change in = delay as >> >>> a function of frame size). See old posts. >> >> >> >> [Raymond]: I am not sure I understand what you are saying. You >probably >> >> misunderstood the goal of my analysis. I mentioned in my last = email >that >> >> my delay analysis aimed to derive the lower and upper bounds of = the >> >> codec-dependent one-way delay as functions of both the codec frame = size >> >> AND the packet size. That "packet transmission delay" does depend = on >> >> the packet size, so it should be included. Also, including it = doesn't >> >> increase the lower bound of the delay (and the codec frame size >> >> multiplier there); it only affects the upper bound. >> >> >> >> Or, are you saying the "packet transmission delay" depends on the >packet >> >> size, not the codec frame size, and therefore is not = codec-dependent? >> >> Well, we know the packet size should be a positive integer = multiple of >> >> the codec frame size. Once the codec frame size is determined, = there >> >> are only limited choices of packet sizes you can use, so in this = sense >> >> the packet size does depend on the codec frame size. Therefore, = the >> >> "packet transmission delay" indirectly depends on the choice of = the >> >> codec. >> >> >> >> Best Regards, >> >> >> >> Raymond >> >> >> >> >> >> >> > >> >_______________________________________________ >> >codec mailing list >> >codec@ietf.org >> >https://www.ietf.org/mailman/listinfo/codec >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec From br@brianrosen.net Thu May 27 06:15:25 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099EC3A6931; Thu, 27 May 2010 06:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.935 X-Spam-Level: X-Spam-Status: No, score=0.935 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YyGjsGGMTxk; Thu, 27 May 2010 06:15:18 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [67.18.150.162]) by core3.amsl.com (Postfix) with ESMTP id E0C1B3A68E4; Thu, 27 May 2010 06:15:15 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[192.168.128.195]) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1OHcvK-0000A8-JP; Thu, 27 May 2010 08:14:58 -0500 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Thu, 27 May 2010 09:14:56 -0400 From: Brian Rosen To: Christian Hoene , Cullen Jennings , Message-ID: Thread-Topic: Speech Quality Aspects in emergency calls Thread-Index: Acr9TeFvwAIcoQvjTqijHtTrJC4yEQAON8cgAAX2Tq4= In-Reply-To: <002a01cafd8a$3691f610$a3b5e230$@de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net Cc: ecrit@ietf.org Subject: Re: [codec] Speech Quality Aspects in emergency calls X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 13:15:25 -0000 Generally, high fidelity is a good thing for emergency calls. This has to be balanced against how many codecs each PSAP implements, but at least in the evolving North American standards, which are currently believed to be the most advanced, it is recommended that PSAPs implement one or two wideband codecs. Graceful fallback in cases of congestion would be nice, but not a hard requirement. Delay below 150ms is unlikely to be of much use. Sometimes, an emergency call can have audio+video and the delays must match (lip sync). Frame time really doesn't matter much independent of its effect on delay. I personally think delay over 150ms is not acceptable, but we've had this discussion and there are some who persist in believing you can get good quality with 250 ms. In an emergency call, stress is a big factor, and social skills are not nuanced. This means turn taking is an issue, and anything that gets in the way of an interruption is bad. All of my testing indicates that turn taking, especially argument, is impaired above around 150 ms. All of the above doesn't really rise to hard requirements other than the soft requirement that delay doesn't impair turn taking. The ability to disable VAD is a hard requirement. I believe that is it with respect to codec. See ietf-ecrit-phonebcp for the actual requirements. Brian On 5/27/10 6:48 AM, "Christian Hoene" wrote: > Hello Cullen, > dear ECRIT experts, > >> I think that the bulk of the people that work on emergency calls in the ECRIT >> WG and much of the IESG >> are going to be very strong supporters of exactly what Brian is saying here. > > I agree that the support of emergency call are important, also in the IETF WG > Codec. However, at this point of time it is not clear > to me what the service requirements of an emergency call are going to be. > Which speech/audio quality requirements do the emergency > agencies have? > > Brian is suggesting a technical solution to become a requirement. But, don't > we have to listen to the users, first? Only then, we > can develop a technical solutions that might affect our work in the Codec WG. > >> The implications aren't a >> big deal for the CODEC WG, just that you need to be able to use SDP to signal >> no VAD. > > Are you sure that this is the only requirement? I think that there are other > important things in case of emergency calls. Do they > need audio quality? Do they need ultra-low-delay or is any transmission delay > fine? What shall happen, if the transmission quality > is bad? Push-to-talk? > >> No one thinks an >> end user is going to go and change the configuration in their phone before >> making an emergency call. > > No, he does know VAD and he does not care about. Some part of the system must > take care of. However, the user does know that he > wants to make a emergency call and the phone might have a button called > "emergency call". > >> If you want the CODEC chairs to go ask the ECRIT WG Chairs if they think this >> is a requirement for an >> internet codec, it's easy to make that happen but they are going to tell us >> the same thing Brian is. > > Good idea, I carbon-copied this email to the ECRIT mailing list, if you do not > mind. > > With best regards, > > Christian > >> >> >> >> On May 24, 2010, at 12:20 PM, Brian Rosen wrote: >> >>> Okay, you asked for it :) >>> >>> In any country, the codes used in another country for emergency numbers are >>> used as service invocations for other services. You have to know what >>> country you are in to know what emergency numbers are. It is roughly >>> impossible (today) to know that with sufficient reliability. >>> >>> You can place an emergency call to an e.164 in many countries. This may >>> depend on which service. >>> >>> The emergency call center (PSAP) can call you back. >>> >>> A call placed to a call center can be transferred or upgraded to an >>> emergency call. This happens with relay centers used by disabled >>> individuals. >>> >>> In all of these circumstances, VAD must be disabled. Emergency calling >>> systems are filled with a lot of complexity that handle seldom occurring >>> circumstances. However, when it comes to saving lives, seldom occurring >>> circumstances are important. >>> >>> Brian >>> >>> ps - I have been working in this field for a number of years. You can learn >>> a bit more about emergency calling from draft-ietf-ecrit-framework. The >>> inability to turn off VAD in VoIP systems believed to have caused actual >>> harm according to some of my associates who work in PSAPs. >>> >>> >>> >>> >>> On 5/24/10 1:37 PM, "Christian Hoene" wrote: >>> >>>> Hi Brian, >>>> >>>>> I'll be happy to go into the details, but phones may not know they are in >>>>> an >>>>> emergency call. No phone knows this today. There is some proposed >>>>> signaling that would tell them, IF the phone, and the service provider >>>>> implement it, but even then, there are circumstances where the phone won't >>>>> know. >>>> >>>> If(called.number==112 || called.number==911 || called.number=XYZ) >>>> EmergencyCall(); >>>> >>>> See more at http://en.wikipedia.org/wiki/1-1-2 >>>> It is so easy to know... I do not get your arguments. >>>> >>>> With best regards, >>>> >>>> Christian >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec > From jean-marc.valin@octasic.com Thu May 27 06:54:10 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4095B3A6AD5 for ; Thu, 27 May 2010 06:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpQjSwenSqEv for ; Thu, 27 May 2010 06:54:09 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 5AC1C3A691D for ; Thu, 27 May 2010 06:54:09 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 27 May 2010 09:53:59 -0400 Message-ID: <4BFE7977.3040901@octasic.com> Date: Thu, 27 May 2010 09:53:59 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Herve Taddei References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <"CB68DF4CFBEF49428 8C74B9043D30B"@IRVEXCHCCR01.corp.ad.broadcom.com> <909E12B9-984F-4051-A93E-2291EFE0A40E@cisco.com> <20100526151326.2882694zuaeslk3q@mail.skype.net> <20100526214255.206532jzf8wjld1r@mail.skype.net> <002901cafd89$acf402e0$06dc08a0$@de> <19367DD02EBD40829869907AEA0CE128@china.huawei.com> In-Reply-To: <19367DD02EBD40829869907AEA0CE128@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 May 2010 13:53:59.0581 (UTC) FILETIME=[0EA79CD0:01CAFDA4] Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 13:54:10 -0000 Hi Herve, Herve Taddei wrote: > Are all those devices being of interest for the codec under development? For > example is it your plan to make use of the IETF codec in hearing aids? In > that case, perhaps requirements for hearing aids should be discussed and > added to the requirements. But I am not sure it is really relevant for an > audio codec designed specifically for use over the Internet. I agree here. We are not chartered to address hearing aids and every device on the planet. If what we do turns out to be useful for non-Internet applications, that's always a nice bonus. If not, then tough. Jean-Marc From macinnis@broadcom.com Thu May 27 07:54:27 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5F783A6905 for ; Thu, 27 May 2010 07:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TG382jslb9Eq for ; Thu, 27 May 2010 07:54:25 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id D0CEE3A6901 for ; Thu, 27 May 2010 07:54:25 -0700 (PDT) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 27 May 2010 07:54:08 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Thu, 27 May 2010 07:54:08 -0700 From: "Sandy (Alexander) MacInnis" To: "Christian Hoene" , "'Herve Taddei'" , "'Koen Vos'" , "Raymond (Juin-Hwey) Chen" Date: Thu, 27 May 2010 07:54:45 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: Acr9Vx30wv2d857zRZSFAlE/S8FBegAKgh/gAANeldAAAYk3sAAFCOhg Message-ID: <568A92CB079CCF43BA5C8D7B08BCB4AE817DCBA900@SJEXCHCCR02.corp.ad.broadcom.com> References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <"CB68DF4! CFBEF49428 8C74B9043D30 B"@IRVEXCHCCR01.corp.ad.broadcom.com> <909E12B9-984F-4051-A93E-2291EFE0A40E@cisco.com> <20100526151326.2882694zuaeslk3q@mail.skype.net> <20100526214255.206532jzf8wjld1r@mail.skype.net> <002901cafd89$acf402e0$06dc08a0$@de> <19367DD02EBD40829869907AEA0CE128@china.huawei.com> <000601cafd9b$148fd850$3daf88f0$@de> In-Reply-To: <000601cafd9b$148fd850$3daf88f0$@de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {EA129795-3330-4FC6-B0A6-25D09DE03A4E} x-cr-hashedpuzzle: EeCF E/AF FBWY KjvB MyB8 SCQ5 V9qV XfO/ ZgbV cyyU c+rM odn5 q2bj sQST uqLj vIW5; 4; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAaABlAHIAdgBlAC4AdABhAGQAZABlAGkAQABoAHUAYQB3AGUAaQAuAGMAbwBtADsAaABvAGUAbgBlAEAAdQBuAGkALQB0AHUAZQBiAGkAbgBnAGUAbgAuAGQAZQA7AGsAbwBlAG4ALgB2AG8AcwBAAHMAawB5AHAAZQAuAG4AZQB0AA==; Sosha1_v1; 7; {EA129795-3330-4FC6-B0A6-25D09DE03A4E}; bQBhAGMAaQBuAG4AaQBzAEAAYgByAG8AYQBkAGMAbwBtAC4AYwBvAG0A; Thu, 27 May 2010 14:54:45 GMT; UgBFADoAIABbAGMAbwBkAGUAYwBdACAAIwAxADYAOgAgAE0AdQBsAHQAaQBjAGEAcwB0AD8A acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67E0581A38O220317577-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 14:54:27 -0000 Everyone, Sorry for stepping in here... full disclosure: I'm not a speech coding expe= rt, and I work at Broadcom, where Raymond works. I too would like to end this discussion; it seems to have diverged from a d= iscussion of the requirements for the CODEC algorithm to have a mode with l= ow algorithmic delay, which AFAIK is already agreed anyway, to some rather = tangential discussions related to, but not really addressing, real time sch= eduling of the algorithm on a processor. The point from Raymond that is the head of this particular discussion trail= is RTS, i.e. real time scheduling. I know his note about that is long; it = might be worth reading it again. It's not a fair assumption that 100% of a shared resource - in this instanc= e, a processor - can be spent performing real-time-scheduled tasks. If ther= e is a set of RT (real time) tasks that have different periods, and periods= =3D deadlines, all being scheduled on the same processor, the best you can= do is less than 100%. How close you can get depends on the details; it mig= ht be e.g. 68%, or it could be significantly less; there's a lot of literat= ure on this. If the system is optimally designed for the purposes of RTS, i= .e. all other tasks are treated as non-real time and have lower priority th= an all real time tasks, there are no priority inversions, task switching is= very efficient, etc. the RTS performance can come close to theory, but if = any of these assumptions are not true, it be significantly worse. If the total RT demands are only a very small fraction of the total shared = resource, i.e. processor cycles, it tends to be easier to perform the sched= uling and ensure that it works correctly. Such a scenario may be more impor= tant than RTS indicates if the system is not well designed for real time op= eration, i.e. a PC. And, such systems draw MUCH more power than well-design= ed embedded products. Conversely, low power and modest clock rates are good= design principles for embedded products, if those that are wall (mains) po= wered. E.g. someone noted leakage power at 65nm - have you looked at 40nm? = It just keeps getting worse. Designing for slower max clock rate saves subs= tantial power. There are good reasons why a common convention of real time scheduling is t= he assumption that period =3D deadline. As Raymond noted, other design assu= mptions are possible, but they have their own problems. Note also, as Raymond pointed out, that RTS also applies to intermediate po= ints in the end-end system, such as gateways. Such a device may have very p= owerful processors, and if so, it should be for the specific purpose perfor= ming a large number of RT tasks, loading the processors as much as can be g= uaranteed. I would hope that this committee is not planning to be in the position of d= ictating that all implementations of the algorithm require a processor that= is so fast that the system can guarantee service that latency is much less= than the period of an audio frame. And if not, then a reasonable assumptio= n is that, in general, the deadline of service latency does equal the perio= d of an audio frame. That assumption is part of one of upper-limit calculat= ions from Raymond. --Sandy -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of C= hristian Hoene Sent: Thursday, May 27, 2010 5:50 AM To: 'Herve Taddei'; 'Koen Vos'; Raymond (Juin-Hwey) Chen Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? Guys, all I want to do is to find an end to this discussion. Sometimes it helps t= o come up with some provocative statements. The example of hearing aids was mentioned only as an example of a device th= at might include a phone in future. If you will, I forgot to mention the tooth-phone http://www.wired.com/science/discoveries/news/20= 02/06/53302 Anyhow, shall we consider that a) devices have plenty of power to do the coding (<2% needed for the codec) b) devices are already fully loaded and need all time for encoding and deco= ding (100% needed for codec and signal processing) xy) between X% and Y%. What is the minimal complexity of the codec? Enough to run at 100% load on = a a) 10 MIPS DSP b) 50 MIPS DSP c) 8000 MIPS DSP d) 60 MHz Pentium e) 1 GHz Pentium How to measure the complexity? a) with gettimeofday on a reference PC setup b) with ITU-T G.191 library c) With a reference virtual machine Decide and continue... Christian --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ >-----Original Message----- >From: Herve Taddei [mailto:herve.taddei@huawei.com] >Sent: Thursday, May 27, 2010 1:54 PM >To: 'Christian Hoene'; 'Koen Vos'; 'Raymond (Juin-Hwey) Chen' >Cc: codec@ietf.org >Subject: RE: [codec] #16: Multicast? > >Hi Christian, > >> Nevertheless, in the end, my position is simple. The lesser the >computational >> complexity, the smaller the battery. This statement >> will remain true for future semiconductor technologies, too. Thus, a low >complexity >> mode and low delay mode is advisable for small, >> portable battery-powered devices such as wireless headsets, hearing aids= , >or >> wireless sensor nodes. Or other kind of devices, which >> have problems with head dissipation. >Are all those devices being of interest for the codec under development? F= or >example is it your plan to make use of the IETF codec in hearing aids? In >that case, perhaps requirements for hearing aids should be discussed and >added to the requirements. But I am not sure it is really relevant for an >audio codec designed specifically for use over the Internet. > >Best regards > >Herve Taddei > >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf O= f >> Christian Hoene >> Sent: Thursday, May 27, 2010 12:45 PM >> To: 'Koen Vos'; 'Raymond (Juin-Hwey) Chen' >> Cc: codec@ietf.org >> Subject: Re: [codec] #16: Multicast? >> >> Hello Koen and Raymond, >> >> yesterdays, I had a brief look on ITU-T G.114 >> http://www1.cs.columbia.edu/~andreaf/new/documents/other/T-REC-G.114- >> 200305.pdf >> It might help in your discussion... >> >> Regarding Moore-law and so: We shall keep in mind that cannot continue >forever. >> Already today, due to Quantum tunneling and >> subthreshold leakage current very small semiconductor structures consume >> increasing amounts of energy. Thus, it might not always be >> advisable to use the latest technology if power consumption shall be low= . >> >> It is know that "CMOS circuits dissipate power by charging the various >load >> capacitances (mostly gate and wire capacitance, but also >> drain and some source capacitances) whenever they are switched. The char= ge >> moved is the capacitance multiplied by the voltage >> change. Multiply by the switching frequency on the load capacitances to >get the >> current used, and multiply by voltage again to get >> the characteristic switching power dissipated by a CMOS device: P =3D CV= =B2f". >> >> C is the capacity (depending on the size of the structure) >> V is Voltage >> f is the powering frequency >> P is the power >> >> Thus, the power does not decrease if the calculation (e.g., the encoding >and >> decoding) is done faster or slower. >> >> In order to save power in mobile device, Dynamic frequency scaling and >Dynamic >> voltage scaling change the frequency and/or the >> voltage to save power. If power consumption needs to be reduced, the >device >> reduces voltage and frequency and thus the calculation >> takes longer. Thus, even if the CPU can do the encoding/decoding at full >speed >> and in a fraction of the frame duration, it is not >> always advisable to do it like that. Instead, if energy supply is limite= d, >then >> calculations shall be slowed down. >> >> My argumentations above support the position of Raymond that device with >low >> processing power will be used and that this increases >> to the transmission delay. However, I am not an expert in system or chip >design >> and thus, I might have missed a few details or >> tradeoffs. >> >> Nevertheless, in the end, my position is simple. The lesser the >computational >> complexity, the smaller the battery. This statement >> will remain true for future semiconductor technologies, too. Thus, a low >complexity >> mode and low delay mode is advisable for small, >> portable battery-powered devices such as wireless headsets, hearing aids= , >or >> wireless sensor nodes. Or other kind of devices, which >> have problems with head dissipation. >> >> With best regards, >> >> Christian Hoene >> >> --------------------------------------------------------------- >> Dr.-Ing. Christian Hoene >> Interactive Communication Systems (ICS), University of T=FCbingen >> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >> http://www.net.uni-tuebingen.de/ >> >> >> >-----Original Message----- >> >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of >> Koen Vos >> >Sent: Thursday, May 27, 2010 6:43 AM >> >To: Raymond (Juin-Hwey) Chen >> >Cc: codec@ietf.org >> >Subject: Re: [codec] #16: Multicast? >> > >> >Quoting "Raymond (Juin-Hwey) Chen": >> >> My point is that we should not expect that future IP phones or gatewa= ys >> >> will operate at a very low percentage point of the processor load jus= t >> >> because Moore's Law can improve processor speed over time. >> > >> >In other words, future manufacturers won't spend a few dimes on >> >reducing delay, even though today they're happy to add several dollars >> >to the price just to enable wideband? That's a statement about the >> >relative importance of delay. >> > >> >For the discussion about transmission delay vs. frame size, see e.g. >> >http://www.ietf.org/mail-archive/web/codec/current/msg01477.html >> > >> >koen. >> > >> > >> > >> >> Hi Koen, >> >> >> >> In-line below... >> >> >> >> You wrote: >> >>> The essence, if I understand you correctly, is that there still exis= t >> >>> low-end platforms with barely enough processing power to run a VoIP >> >>> call. If such platforms use a naive FIFO scheduler, they'll create = up >> >>> to one frame of processing delay for encoder and decoder each, on to= p >> >>> of the frame of buffering delay. >> >> >> >> [Raymond]: It doesn't have to be low-end platforms. I wouldn't >consider >> >> high-density VoIP gateways "low-end". What matters is whether the >> >> processor is heavily loaded (i.e. busy at a high percentage of time) >> >> with real-time tasks (and thus is just fast enough). I think this is >> >> true for typical implementations of IP phones and VoIP gateways. >> >> >> >> I also wouldn't use the term "a na=EFve FIFO scheduler" to describe t= he >> >> "run to completion" real-time scheduler that I talked about in my las= t >> >> email, because that term seems to imply that it is a very simple-mind= ed >> >> and inferior approach used by an inexperienced person who doesn't kno= w >> >> anything better. My understanding from talking to the three senior >> >> technical leads of Broadcom is that the reality is when you have many >> >> real-time tasks that you need to handle concurrently, using a >> >> prioritized interrupt-driven scheduler is just way too complex and >> >> messy, and it doesn't even guarantee that you will get a lower delay = if >> >> you do go through the trouble. In contrast, the kind of "run to >> >> completion" real-time scheduler that I talked about is a more elegant >> >> solution as it simplifies the scheduling problem substantially and al= so >> >> allows you to have more efficient utilization of the processor. >> >> >> >> Other than these two points, your understanding of my main point is >> >> correct. >> >> >> >>> The good news is that Moore's law will continue to drive down the >> >>> fraction of platforms with such processing delay problems. >> >> >> >> [Raymond]: This may be true for PC but probably not true in general. >> >> PC is a general-purpose computing device that has to handle numerous >> >> possible tasks, and a voice phone call takes only a very small fracti= on >> >> of the worst-case computational power requirement of a PC. In >contrast, >> >> for special-purpose dedicated hardware devices such as IP phones or >> >> VoIP gateways, it would make no sense to use a processor that is many >> >> times faster than the worst-case computational power requirement. Fo= r >> >> the sake of cost and power efficiency, the designers of such special- >> >> purpose devices will want to use a processor that's just slightly >faster >> >> than required, because then they can use the cheapest and/or lowest >> >> power-consuming processor that's fast enough to get the job done. >> >> If they choose to use a processor much faster than is required, then >> >> competitors using processors just fast enough can have lower costs >> >> and power consumption and can take market share away from them. >> >> >> >> A case in point: after its first appearance several decades ago, 8-bi= t >> >> microprocessors are still widely used in many devices today despite t= he >> >> several orders of magnitude of speed improvement provided by Moore's >> >> Law, because those devices just don't need anything faster, so using >> >> anything faster would be a waste of money and power consumption. >> >> >> >> My point is that we should not expect that future IP phones or gatewa= ys >> >> will operate at a very low percentage point of the processor load jus= t >> >> because Moore's Law can improve processor speed over time. Therefore, >> >> don't expect the 3X multiplier for codec frame size to go down much >> >> below where they are now. >> >> >> >> In fact, if in addition to a VoIP call, a PC is heavily loaded with a >> >> lot of other concurrent tasks, many of which may be real-time tasks >> >> (e.g. video, playing/burning CD/DVD, networking, etc.), then it will = be >> >> difficult for the PC to have small encoding and decoding RTS delays (= d2 >> >> and d5 in my delay analysis). In this case, the codec frame size >> >> multiplier will be closer to 3X than to 1X, unless you are willing to >> >> let the voice stream occasionally run out of real time and produce an >> >> audible glitch (which is not acceptable from the voice quality >> >> perspective). If you agree with this and agree that a PC sometimes >> >> does get very heavily loaded, then if you don't want the voice stream >> >> to run out of real time, the worst-case codec-dependent delay for >> >> PC can still be around 3X the codec frame size. >> >> >> >>> I'm a bit surprised by your analysis of "packet transmission delay", >> >>> as it has little bearing on our multiplier (ie the change in delay a= s >> >>> a function of frame size). See old posts. >> >> >> >> [Raymond]: I am not sure I understand what you are saying. You >probably >> >> misunderstood the goal of my analysis. I mentioned in my last email >that >> >> my delay analysis aimed to derive the lower and upper bounds of the >> >> codec-dependent one-way delay as functions of both the codec frame si= ze >> >> AND the packet size. That "packet transmission delay" does depend on >> >> the packet size, so it should be included. Also, including it doesn'= t >> >> increase the lower bound of the delay (and the codec frame size >> >> multiplier there); it only affects the upper bound. >> >> >> >> Or, are you saying the "packet transmission delay" depends on the >packet >> >> size, not the codec frame size, and therefore is not codec-dependent? >> >> Well, we know the packet size should be a positive integer multiple o= f >> >> the codec frame size. Once the codec frame size is determined, there >> >> are only limited choices of packet sizes you can use, so in this sens= e >> >> the packet size does depend on the codec frame size. Therefore, the >> >> "packet transmission delay" indirectly depends on the choice of the >> >> codec. >> >> >> >> Best Regards, >> >> >> >> Raymond >> >> >> >> >> >> >> > >> >_______________________________________________ >> >codec mailing list >> >codec@ietf.org >> >https://www.ietf.org/mailman/listinfo/codec >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From hoene@uni-tuebingen.de Thu May 27 08:48:57 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 566113A659A for ; Thu, 27 May 2010 08:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.328 X-Spam-Level: X-Spam-Status: No, score=-4.328 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqUuT-pOZbyF for ; Thu, 27 May 2010 08:48:54 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 1F1D73A6359 for ; Thu, 27 May 2010 08:48:53 -0700 (PDT) Received: from hoeneT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4RFmMOa031049 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 May 2010 17:48:22 +0200 From: "Christian Hoene" To: "'Sandy \(Alexander\) MacInnis'" , "'Herve Taddei'" , "'Koen Vos'" , "'Raymond \(Juin-Hwey\) Chen'" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <"CB68DF4! ! CFBEF49428 8C74B9043D 30 B"@IRVEXCHCCR01.corp.ad.broadcom.com> <909E12B9-984F-4051-A93E-2291EFE0A40E@cisco.com> <20100526151326.2882694zuaeslk3q@mail.skype.net> <20100526214255.206532jzf8wjld1r@mail.skype.net> <002901cafd89$acf402e0$06dc08a0$@de> <19367DD02EBD40829869907AEA0CE128@china.huawei.com> <000601cafd9b$148fd850$3daf88f0$@de> <568A92CB079CCF43BA5C8D7B08BCB4AE817DCBA900@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <568A92CB079CCF43BA5C8D7B08BCB4AE817DCBA900@SJEXCHCCR02.corp.ad.broadcom.com> Date: Thu, 27 May 2010 17:48:21 +0200 Message-ID: <002501cafdb4$09394810$1babd830$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr9Vx30wv2d857zRZSFAlE/S8FBegAKgh/gAANeldAAAYk3sAAFCOhgAAH7QiA= Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.242; VDF: 7.10.7.186; host: mx05); id=31713-6H83GF Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 15:48:57 -0000 So, we have consensus on=20 1) low delay mode 2) low complexity mode (whatever this means) 3) technical understanding on how latency sums up on different platforms The remaining discussion seems to be on which kind of platforms to = support: a) fast PC and softphone=20 b) embedded, slow CPU on hardphones (+conferences server)=20 A bit it is also about how to make money with phone calls in future: a) Selling services in addition to offering calls via softphones b) Selling devices that help to conduct calls I know that there it has a long tradition in standardization to fortify = the own market position as early as possible. Thus, it is well understandable that a) and b) are competing. However, wouldn't it = make sense if we support both a) and b) and let future market forces decide?=20 With best regards, Christian --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ >-----Original Message----- >From: Sandy (Alexander) MacInnis [mailto:macinnis@broadcom.com] >Sent: Thursday, May 27, 2010 4:55 PM >To: Christian Hoene; 'Herve Taddei'; 'Koen Vos'; Raymond (Juin-Hwey) = Chen >Cc: codec@ietf.org >Subject: RE: [codec] #16: Multicast? > >Everyone, > >Sorry for stepping in here... full disclosure: I'm not a speech coding = expert, and I work at Broadcom, >where Raymond works. > >I too would like to end this discussion; it seems to have diverged from = a discussion of the >requirements for the CODEC algorithm to have a mode with low = algorithmic delay, which AFAIK is already >agreed anyway, to some rather tangential discussions related to, but = not really addressing, real time >scheduling of the algorithm on a processor. > >The point from Raymond that is the head of this particular discussion = trail is RTS, i.e. real time >scheduling. I know his note about that is long; it might be worth = reading it again. > >It's not a fair assumption that 100% of a shared resource - in this = instance, a processor - can be >spent performing real-time-scheduled tasks. If there is a set of RT = (real time) tasks that have >different periods, and periods =3D deadlines, all being scheduled on = the same processor, the best you >can do is less than 100%. How close you can get depends on the details; = it might be e.g. 68%, or it >could be significantly less; there's a lot of literature on this. If = the system is optimally designed >for the purposes of RTS, i.e. all other tasks are treated as non-real = time and have lower priority >than all real time tasks, there are no priority inversions, task = switching is very efficient, etc. the >RTS performance can come close to theory, but if any of these = assumptions are not true, it be >significantly worse. > >If the total RT demands are only a very small fraction of the total = shared resource, i.e. processor >cycles, it tends to be easier to perform the scheduling and ensure that = it works correctly. Such a >scenario may be more important than RTS indicates if the system is not = well designed for real time >operation, i.e. a PC. And, such systems draw MUCH more power than = well-designed embedded products. >Conversely, low power and modest clock rates are good design principles = for embedded products, if >those that are wall (mains) powered. E.g. someone noted leakage power = at 65nm - have you looked at >40nm? It just keeps getting worse. Designing for slower max clock rate = saves substantial power. > >There are good reasons why a common convention of real time scheduling = is the assumption that period =3D >deadline. As Raymond noted, other design assumptions are possible, but = they have their own problems. > >Note also, as Raymond pointed out, that RTS also applies to = intermediate points in the end-end system, >such as gateways. Such a device may have very powerful processors, and = if so, it should be for the >specific purpose performing a large number of RT tasks, loading the = processors as much as can be >guaranteed. > >I would hope that this committee is not planning to be in the position = of dictating that all >implementations of the algorithm require a processor that is so fast = that the system can guarantee >service that latency is much less than the period of an audio frame. = And if not, then a reasonable >assumption is that, in general, the deadline of service latency does = equal the period of an audio >frame. That assumption is part of one of upper-limit calculations from = Raymond. > >--Sandy > > >-----Original Message----- >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Christian Hoene >Sent: Thursday, May 27, 2010 5:50 AM >To: 'Herve Taddei'; 'Koen Vos'; Raymond (Juin-Hwey) Chen >Cc: codec@ietf.org >Subject: Re: [codec] #16: Multicast? > >Guys, > >all I want to do is to find an end to this discussion. Sometimes it = helps to come up with some >provocative statements. >The example of hearing aids was mentioned only as an example of a = device that might include a phone in >future. If you will, I forgot >to mention the tooth-phone = http://www.wired.com/science/discoveries/news/2002/06/53302 > >Anyhow, shall we consider that > >a) devices have plenty of power to do the coding (<2% needed for the = codec) >b) devices are already fully loaded and need all time for encoding and = decoding (100% needed for codec >and signal processing) >xy) between X% and Y%. > >What is the minimal complexity of the codec? Enough to run at 100% load = on a >a) 10 MIPS DSP >b) 50 MIPS DSP >c) 8000 MIPS DSP >d) 60 MHz Pentium >e) 1 GHz Pentium > >How to measure the complexity? >a) with gettimeofday on a reference PC setup >b) with ITU-T G.191 library >c) With a reference virtual machine > >Decide and continue... > >Christian > >--------------------------------------------------------------- >Dr.-Ing. Christian Hoene >Interactive Communication Systems (ICS), University of T=FCbingen >Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >http://www.net.uni-tuebingen.de/ > >>-----Original Message----- >>From: Herve Taddei [mailto:herve.taddei@huawei.com] >>Sent: Thursday, May 27, 2010 1:54 PM >>To: 'Christian Hoene'; 'Koen Vos'; 'Raymond (Juin-Hwey) Chen' >>Cc: codec@ietf.org >>Subject: RE: [codec] #16: Multicast? >> >>Hi Christian, >> >>> Nevertheless, in the end, my position is simple. The lesser the >>computational >>> complexity, the smaller the battery. This statement >>> will remain true for future semiconductor technologies, too. Thus, a = low >>complexity >>> mode and low delay mode is advisable for small, >>> portable battery-powered devices such as wireless headsets, hearing = aids, >>or >>> wireless sensor nodes. Or other kind of devices, which >>> have problems with head dissipation. >>Are all those devices being of interest for the codec under = development? For >>example is it your plan to make use of the IETF codec in hearing aids? = In >>that case, perhaps requirements for hearing aids should be discussed = and >>added to the requirements. But I am not sure it is really relevant for = an >>audio codec designed specifically for use over the Internet. >> >>Best regards >> >>Herve Taddei >> >>> -----Original Message----- >>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On = Behalf Of >>> Christian Hoene >>> Sent: Thursday, May 27, 2010 12:45 PM >>> To: 'Koen Vos'; 'Raymond (Juin-Hwey) Chen' >>> Cc: codec@ietf.org >>> Subject: Re: [codec] #16: Multicast? >>> >>> Hello Koen and Raymond, >>> >>> yesterdays, I had a brief look on ITU-T G.114 >>> = http://www1.cs.columbia.edu/~andreaf/new/documents/other/T-REC-G.114- >>> 200305.pdf >>> It might help in your discussion... >>> >>> Regarding Moore-law and so: We shall keep in mind that cannot = continue >>forever. >>> Already today, due to Quantum tunneling and >>> subthreshold leakage current very small semiconductor structures = consume >>> increasing amounts of energy. Thus, it might not always be >>> advisable to use the latest technology if power consumption shall be = low. >>> >>> It is know that "CMOS circuits dissipate power by charging the = various >>load >>> capacitances (mostly gate and wire capacitance, but also >>> drain and some source capacitances) whenever they are switched. The = charge >>> moved is the capacitance multiplied by the voltage >>> change. Multiply by the switching frequency on the load capacitances = to >>get the >>> current used, and multiply by voltage again to get >>> the characteristic switching power dissipated by a CMOS device: P = =3D CV=B2f". >>> >>> C is the capacity (depending on the size of the structure) >>> V is Voltage >>> f is the powering frequency >>> P is the power >>> >>> Thus, the power does not decrease if the calculation (e.g., the = encoding >>and >>> decoding) is done faster or slower. >>> >>> In order to save power in mobile device, Dynamic frequency scaling = and >>Dynamic >>> voltage scaling change the frequency and/or the >>> voltage to save power. If power consumption needs to be reduced, = the >>device >>> reduces voltage and frequency and thus the calculation >>> takes longer. Thus, even if the CPU can do the encoding/decoding at = full >>speed >>> and in a fraction of the frame duration, it is not >>> always advisable to do it like that. Instead, if energy supply is = limited, >>then >>> calculations shall be slowed down. >>> >>> My argumentations above support the position of Raymond that device = with >>low >>> processing power will be used and that this increases >>> to the transmission delay. However, I am not an expert in system or = chip >>design >>> and thus, I might have missed a few details or >>> tradeoffs. >>> >>> Nevertheless, in the end, my position is simple. The lesser the >>computational >>> complexity, the smaller the battery. This statement >>> will remain true for future semiconductor technologies, too. Thus, a = low >>complexity >>> mode and low delay mode is advisable for small, >>> portable battery-powered devices such as wireless headsets, hearing = aids, >>or >>> wireless sensor nodes. Or other kind of devices, which >>> have problems with head dissipation. >>> >>> With best regards, >>> >>> Christian Hoene >>> >>> --------------------------------------------------------------- >>> Dr.-Ing. Christian Hoene >>> Interactive Communication Systems (ICS), University of T=FCbingen >>> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >>> http://www.net.uni-tuebingen.de/ >>> >>> >>> >-----Original Message----- >>> >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On = Behalf Of >>> Koen Vos >>> >Sent: Thursday, May 27, 2010 6:43 AM >>> >To: Raymond (Juin-Hwey) Chen >>> >Cc: codec@ietf.org >>> >Subject: Re: [codec] #16: Multicast? >>> > >>> >Quoting "Raymond (Juin-Hwey) Chen": >>> >> My point is that we should not expect that future IP phones or = gateways >>> >> will operate at a very low percentage point of the processor load = just >>> >> because Moore's Law can improve processor speed over time. >>> > >>> >In other words, future manufacturers won't spend a few dimes on >>> >reducing delay, even though today they're happy to add several = dollars >>> >to the price just to enable wideband? That's a statement about the >>> >relative importance of delay. >>> > >>> >For the discussion about transmission delay vs. frame size, see = e.g. >>> >http://www.ietf.org/mail-archive/web/codec/current/msg01477.html >>> > >>> >koen. >>> > >>> > >>> > >>> >> Hi Koen, >>> >> >>> >> In-line below... >>> >> >>> >> You wrote: >>> >>> The essence, if I understand you correctly, is that there still = exist >>> >>> low-end platforms with barely enough processing power to run a = VoIP >>> >>> call. If such platforms use a naive FIFO scheduler, they'll = create up >>> >>> to one frame of processing delay for encoder and decoder each, = on top >>> >>> of the frame of buffering delay. >>> >> >>> >> [Raymond]: It doesn't have to be low-end platforms. I wouldn't >>consider >>> >> high-density VoIP gateways "low-end". What matters is whether = the >>> >> processor is heavily loaded (i.e. busy at a high percentage of = time) >>> >> with real-time tasks (and thus is just fast enough). I think this = is >>> >> true for typical implementations of IP phones and VoIP gateways. >>> >> >>> >> I also wouldn't use the term "a na=EFve FIFO scheduler" to = describe the >>> >> "run to completion" real-time scheduler that I talked about in my = last >>> >> email, because that term seems to imply that it is a very = simple-minded >>> >> and inferior approach used by an inexperienced person who doesn't = know >>> >> anything better. My understanding from talking to the three = senior >>> >> technical leads of Broadcom is that the reality is when you have = many >>> >> real-time tasks that you need to handle concurrently, using a >>> >> prioritized interrupt-driven scheduler is just way too complex = and >>> >> messy, and it doesn't even guarantee that you will get a lower = delay if >>> >> you do go through the trouble. In contrast, the kind of "run to >>> >> completion" real-time scheduler that I talked about is a more = elegant >>> >> solution as it simplifies the scheduling problem substantially = and also >>> >> allows you to have more efficient utilization of the processor. >>> >> >>> >> Other than these two points, your understanding of my main point = is >>> >> correct. >>> >> >>> >>> The good news is that Moore's law will continue to drive down = the >>> >>> fraction of platforms with such processing delay problems. >>> >> >>> >> [Raymond]: This may be true for PC but probably not true in = general. >>> >> PC is a general-purpose computing device that has to handle = numerous >>> >> possible tasks, and a voice phone call takes only a very small = fraction >>> >> of the worst-case computational power requirement of a PC. In >>contrast, >>> >> for special-purpose dedicated hardware devices such as IP phones = or >>> >> VoIP gateways, it would make no sense to use a processor that is = many >>> >> times faster than the worst-case computational power requirement. = For >>> >> the sake of cost and power efficiency, the designers of such = special- >>> >> purpose devices will want to use a processor that's just slightly >>faster >>> >> than required, because then they can use the cheapest and/or = lowest >>> >> power-consuming processor that's fast enough to get the job done. >>> >> If they choose to use a processor much faster than is required, = then >>> >> competitors using processors just fast enough can have lower = costs >>> >> and power consumption and can take market share away from them. >>> >> >>> >> A case in point: after its first appearance several decades ago, = 8-bit >>> >> microprocessors are still widely used in many devices today = despite the >>> >> several orders of magnitude of speed improvement provided by = Moore's >>> >> Law, because those devices just don't need anything faster, so = using >>> >> anything faster would be a waste of money and power consumption. >>> >> >>> >> My point is that we should not expect that future IP phones or = gateways >>> >> will operate at a very low percentage point of the processor load = just >>> >> because Moore's Law can improve processor speed over time. = Therefore, >>> >> don't expect the 3X multiplier for codec frame size to go down = much >>> >> below where they are now. >>> >> >>> >> In fact, if in addition to a VoIP call, a PC is heavily loaded = with a >>> >> lot of other concurrent tasks, many of which may be real-time = tasks >>> >> (e.g. video, playing/burning CD/DVD, networking, etc.), then it = will be >>> >> difficult for the PC to have small encoding and decoding RTS = delays (d2 >>> >> and d5 in my delay analysis). In this case, the codec frame size >>> >> multiplier will be closer to 3X than to 1X, unless you are = willing to >>> >> let the voice stream occasionally run out of real time and = produce an >>> >> audible glitch (which is not acceptable from the voice quality >>> >> perspective). If you agree with this and agree that a PC = sometimes >>> >> does get very heavily loaded, then if you don't want the voice = stream >>> >> to run out of real time, the worst-case codec-dependent delay for >>> >> PC can still be around 3X the codec frame size. >>> >> >>> >>> I'm a bit surprised by your analysis of "packet transmission = delay", >>> >>> as it has little bearing on our multiplier (ie the change in = delay as >>> >>> a function of frame size). See old posts. >>> >> >>> >> [Raymond]: I am not sure I understand what you are saying. You >>probably >>> >> misunderstood the goal of my analysis. I mentioned in my last = email >>that >>> >> my delay analysis aimed to derive the lower and upper bounds of = the >>> >> codec-dependent one-way delay as functions of both the codec = frame size >>> >> AND the packet size. That "packet transmission delay" does = depend on >>> >> the packet size, so it should be included. Also, including it = doesn't >>> >> increase the lower bound of the delay (and the codec frame size >>> >> multiplier there); it only affects the upper bound. >>> >> >>> >> Or, are you saying the "packet transmission delay" depends on the >>packet >>> >> size, not the codec frame size, and therefore is not = codec-dependent? >>> >> Well, we know the packet size should be a positive integer = multiple of >>> >> the codec frame size. Once the codec frame size is determined, = there >>> >> are only limited choices of packet sizes you can use, so in this = sense >>> >> the packet size does depend on the codec frame size. Therefore, = the >>> >> "packet transmission delay" indirectly depends on the choice of = the >>> >> codec. >>> >> >>> >> Best Regards, >>> >> >>> >> Raymond >>> >> >>> >> >>> >> >>> > >>> >_______________________________________________ >>> >codec mailing list >>> >codec@ietf.org >>> >https://www.ietf.org/mailman/listinfo/codec >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec > > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From rchen@broadcom.com Thu May 27 12:36:20 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9535D3A6BB7 for ; Thu, 27 May 2010 12:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-MNQ65K8ylq for ; Thu, 27 May 2010 12:36:19 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 95C193A6C78 for ; Thu, 27 May 2010 12:30:56 -0700 (PDT) Received: from [10.9.200.131] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 27 May 2010 12:28:02 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Thu, 27 May 2010 12:28:02 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Koen Vos" Date: Thu, 27 May 2010 12:27:57 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: Acr9VxuWeN8tqHdQQDKXjHHu3l2CZwAb91Yg Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <07C815A7-8F3C-4F85-A275-4352D0080EEA@cisco.com> <909E12B9-984F-4051-A93E-2291EFE0A40E@cisco.com> <20100526151326.2882694zuaeslk3q@mail.skype.net> <20100526214255.206532jzf8wjld1r@mail.skype.net> In-Reply-To: <20100526214255.206532jzf8wjld1r@mail.skype.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: XSE= BKH0 BsTI CwXq C52F DtSn Etgg E7rE Gqzs GyI/ LfWc M1MO NhU2 OUSp Ptyp QlxI; 2; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAawBvAGUAbgAuAHYAbwBzAEAAcwBrAHkAcABlAC4AbgBlAHQA; Sosha1_v1; 7; {E9A2D3FB-2E29-4703-B23A-D8FE9BDC3F09}; cgBjAGgAZQBuAEAAYgByAG8AYQBkAGMAbwBtAC4AYwBvAG0A; Thu, 27 May 2010 19:27:57 GMT; UgBFADoAIABbAGMAbwBkAGUAYwBdACAAIwAxADYAOgAgAE0AdQBsAHQAaQBjAGEAcwB0AD8A x-cr-puzzleid: {E9A2D3FB-2E29-4703-B23A-D8FE9BDC3F09} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67E0184838O220584277-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 19:36:20 -0000 Hi Koen, I too don't want to see this discussion drags on, but some of your comments= =20 seem misleading to me, so I would like to respond with some quick comments.= =20 Wideband is a new feature in some devices and is a check box that a product= =20 manager needs to check off to remain competitive. That doesn't mean=20 wideband is more important than existing features in a device. Also, I=20 am not sure the cost difference is a few dimes versus several dollars. In=20 some devices the extra cost of adding wideband is minimal. Furthermore, it= =20 is not only a cost issue but also a power consumption issue. No one in his= =20 or her right mind will use a processor that's 5X to 10X faster than=20 necessary just in order to reduce the encoder and decoder RTS delays to a=20 small fraction of the codec frame size; this is just the way it is and has= =20 nothing to do with the relative importance of delay or anything else. =20 You were presenting it as if this were a reasonable choice that device=20 designers could easily make but chose not to make, but that's just not=20 true. It has always been the case that the designers will use processors=20 just fast enough for the job, perhaps with a little margin for the=20 unexpected, but not 5X or 10X. Given this, the bottom line is that ~ 3X=20 codec frame size is the "norm" or a "necessary result" for special-purpose= =20 hardware devices rather than by a design choice, and you are just lucky to= =20 get < 2X in PC-based VoIP calls because PCs were not designed for voice=20 calls but for other much more computationally demanding tasks. (Even there= =20 you can't guarantee that PCs will always give you a multiplier of < 2X. =20 What if the PC is heavily loaded with other tasks? Then you are more likel= y to get 3X if you don't want your voice stream to run out of real time.) Best Regards, Raymond -----Original Message----- From: Koen Vos [mailto:koen.vos@skype.net]=20 Sent: Wednesday, May 26, 2010 9:43 PM To: Raymond (Juin-Hwey) Chen Cc: codec@ietf.org Subject: RE: [codec] #16: Multicast? Quoting "Raymond (Juin-Hwey) Chen": > My point is that we should not expect that future IP phones or gateways > will operate at a very low percentage point of the processor load just > because Moore's Law can improve processor speed over time. In other words, future manufacturers won't spend a few dimes on =20 reducing delay, even though today they're happy to add several dollars =20 to the price just to enable wideband? That's a statement about the =20 relative importance of delay. For the discussion about transmission delay vs. frame size, see e.g. http://www.ietf.org/mail-archive/web/codec/current/msg01477.html koen. > Hi Koen, > > In-line below... > > You wrote: >> The essence, if I understand you correctly, is that there still exist >> low-end platforms with barely enough processing power to run a VoIP >> call. If such platforms use a naive FIFO scheduler, they'll create up >> to one frame of processing delay for encoder and decoder each, on top >> of the frame of buffering delay. > > [Raymond]: It doesn't have to be low-end platforms. I wouldn't consider > high-density VoIP gateways "low-end". What matters is whether the > processor is heavily loaded (i.e. busy at a high percentage of time) > with real-time tasks (and thus is just fast enough). I think this is > true for typical implementations of IP phones and VoIP gateways. > > I also wouldn't use the term "a na=EFve FIFO scheduler" to describe the > "run to completion" real-time scheduler that I talked about in my last > email, because that term seems to imply that it is a very simple-minded > and inferior approach used by an inexperienced person who doesn't know > anything better. My understanding from talking to the three senior > technical leads of Broadcom is that the reality is when you have many > real-time tasks that you need to handle concurrently, using a > prioritized interrupt-driven scheduler is just way too complex and > messy, and it doesn't even guarantee that you will get a lower delay if > you do go through the trouble. In contrast, the kind of "run to > completion" real-time scheduler that I talked about is a more elegant > solution as it simplifies the scheduling problem substantially and also > allows you to have more efficient utilization of the processor. > > Other than these two points, your understanding of my main point is > correct. > >> The good news is that Moore's law will continue to drive down the >> fraction of platforms with such processing delay problems. > > [Raymond]: This may be true for PC but probably not true in general. > PC is a general-purpose computing device that has to handle numerous > possible tasks, and a voice phone call takes only a very small fraction > of the worst-case computational power requirement of a PC. In contrast, > for special-purpose dedicated hardware devices such as IP phones or > VoIP gateways, it would make no sense to use a processor that is many > times faster than the worst-case computational power requirement. For > the sake of cost and power efficiency, the designers of such special- > purpose devices will want to use a processor that's just slightly faster > than required, because then they can use the cheapest and/or lowest > power-consuming processor that's fast enough to get the job done. > If they choose to use a processor much faster than is required, then > competitors using processors just fast enough can have lower costs > and power consumption and can take market share away from them. > > A case in point: after its first appearance several decades ago, 8-bit > microprocessors are still widely used in many devices today despite the > several orders of magnitude of speed improvement provided by Moore's > Law, because those devices just don't need anything faster, so using > anything faster would be a waste of money and power consumption. > > My point is that we should not expect that future IP phones or gateways > will operate at a very low percentage point of the processor load just > because Moore's Law can improve processor speed over time. Therefore, > don't expect the 3X multiplier for codec frame size to go down much > below where they are now. > > In fact, if in addition to a VoIP call, a PC is heavily loaded with a > lot of other concurrent tasks, many of which may be real-time tasks > (e.g. video, playing/burning CD/DVD, networking, etc.), then it will be > difficult for the PC to have small encoding and decoding RTS delays (d2 > and d5 in my delay analysis). In this case, the codec frame size > multiplier will be closer to 3X than to 1X, unless you are willing to > let the voice stream occasionally run out of real time and produce an > audible glitch (which is not acceptable from the voice quality > perspective). If you agree with this and agree that a PC sometimes > does get very heavily loaded, then if you don't want the voice stream > to run out of real time, the worst-case codec-dependent delay for > PC can still be around 3X the codec frame size. > >> I'm a bit surprised by your analysis of "packet transmission delay", >> as it has little bearing on our multiplier (ie the change in delay as >> a function of frame size). See old posts. > > [Raymond]: I am not sure I understand what you are saying. You probably > misunderstood the goal of my analysis. I mentioned in my last email that > my delay analysis aimed to derive the lower and upper bounds of the > codec-dependent one-way delay as functions of both the codec frame size > AND the packet size. That "packet transmission delay" does depend on > the packet size, so it should be included. Also, including it doesn't > increase the lower bound of the delay (and the codec frame size > multiplier there); it only affects the upper bound. > > Or, are you saying the "packet transmission delay" depends on the packet > size, not the codec frame size, and therefore is not codec-dependent? > Well, we know the packet size should be a positive integer multiple of > the codec frame size. Once the codec frame size is determined, there > are only limited choices of packet sizes you can use, so in this sense > the packet size does depend on the codec frame size. Therefore, the > "packet transmission delay" indirectly depends on the choice of the > codec. > > Best Regards, > > Raymond > > > From roman@telurix.com Thu May 27 12:48:48 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BB2D3A6936 for ; Thu, 27 May 2010 12:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.624 X-Spam-Level: X-Spam-Status: No, score=0.624 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ize6TzTc308t for ; Thu, 27 May 2010 12:48:45 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 832443A6924 for ; Thu, 27 May 2010 12:48:45 -0700 (PDT) Received: by vws19 with SMTP id 19so7259vws.31 for ; Thu, 27 May 2010 12:48:33 -0700 (PDT) Received: by 10.229.226.211 with SMTP id ix19mr2423529qcb.127.1274989712948; Thu, 27 May 2010 12:48:32 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by mx.google.com with ESMTPS id bv23sm809761qcb.7.2010.05.27.12.48.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 May 2010 12:48:29 -0700 (PDT) Received: by gyh4 with SMTP id 4so301185gyh.31 for ; Thu, 27 May 2010 12:48:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.170.11 with SMTP id s11mr589885ybe.390.1274989708023; Thu, 27 May 2010 12:48:28 -0700 (PDT) Received: by 10.150.186.7 with HTTP; Thu, 27 May 2010 12:48:27 -0700 (PDT) In-Reply-To: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <07C815A7-8F3C-4F85-A275-4352D0080EEA@cisco.com> <909E12B9-984F-4051-A93E-2291EFE0A40E@cisco.com> <20100526151326.2882694zuaeslk3q@mail.skype.net> <20100526214255.206532jzf8wjld1r@mail.skype.net> Date: Thu, 27 May 2010 15:48:27 -0400 Message-ID: From: Roman Shpount To: "Raymond (Juin-Hwey) Chen" Content-Type: multipart/alternative; boundary=000e0cd563f4a39747048798acc5 Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 May 2010 19:48:48 -0000 --000e0cd563f4a39747048798acc5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Raymond, What we heard so far was a lot of unsubstantiated claims with some semi-theoretical arguments attributed to unknown exports supporting them. First of all, this is all irrelevant. Second, unless someone takes a reasonable set of different hardware, including high density gateways, soft and hard phones, and actually measures the delay for different codecs and packet sizes we will not know what the answer is. So. please. lets can this discussion for now. _____________ Roman Shpount On Thu, May 27, 2010 at 3:27 PM, Raymond (Juin-Hwey) Chen < rchen@broadcom.com> wrote: > Hi Koen, > > I too don't want to see this discussion drags on, but some of your commen= ts > seem misleading to me, so I would like to respond with some quick comment= s. > > Wideband is a new feature in some devices and is a check box that a produ= ct > manager needs to check off to remain competitive. That doesn't mean > wideband is more important than existing features in a device. Also, I > am not sure the cost difference is a few dimes versus several dollars. In > some devices the extra cost of adding wideband is minimal. Furthermore, i= t > is not only a cost issue but also a power consumption issue. No one in h= is > or her right mind will use a processor that's 5X to 10X faster than > necessary just in order to reduce the encoder and decoder RTS delays to a > small fraction of the codec frame size; this is just the way it is and ha= s > nothing to do with the relative importance of delay or anything else. > > You were presenting it as if this were a reasonable choice that device > designers could easily make but chose not to make, but that's just not > true. It has always been the case that the designers will use processors > just fast enough for the job, perhaps with a little margin for the > unexpected, but not 5X or 10X. Given this, the bottom line is that ~ 3X > codec frame size is the "norm" or a "necessary result" for special-purpos= e > hardware devices rather than by a design choice, and you are just lucky t= o > get < 2X in PC-based VoIP calls because PCs were not designed for voice > calls but for other much more computationally demanding tasks. (Even the= re > you can't guarantee that PCs will always give you a multiplier of < 2X. > What if the PC is heavily loaded with other tasks? Then you are more > likely > to get 3X if you don't want your voice stream to run out of real time.) > > Best Regards, > > Raymond > > -----Original Message----- > From: Koen Vos [mailto:koen.vos@skype.net] > Sent: Wednesday, May 26, 2010 9:43 PM > To: Raymond (Juin-Hwey) Chen > Cc: codec@ietf.org > Subject: RE: [codec] #16: Multicast? > > Quoting "Raymond (Juin-Hwey) Chen": > > My point is that we should not expect that future IP phones or gateways > > will operate at a very low percentage point of the processor load just > > because Moore's Law can improve processor speed over time. > > In other words, future manufacturers won't spend a few dimes on > reducing delay, even though today they're happy to add several dollars > to the price just to enable wideband? That's a statement about the > relative importance of delay. > > For the discussion about transmission delay vs. frame size, see e.g. > http://www.ietf.org/mail-archive/web/codec/current/msg01477.html > > koen. > > > > > Hi Koen, > > > > In-line below... > > > > You wrote: > >> The essence, if I understand you correctly, is that there still exist > >> low-end platforms with barely enough processing power to run a VoIP > >> call. If such platforms use a naive FIFO scheduler, they'll create up > >> to one frame of processing delay for encoder and decoder each, on top > >> of the frame of buffering delay. > > > > [Raymond]: It doesn't have to be low-end platforms. I wouldn't conside= r > > high-density VoIP gateways "low-end". What matters is whether the > > processor is heavily loaded (i.e. busy at a high percentage of time) > > with real-time tasks (and thus is just fast enough). I think this is > > true for typical implementations of IP phones and VoIP gateways. > > > > I also wouldn't use the term "a na=EFve FIFO scheduler" to describe the > > "run to completion" real-time scheduler that I talked about in my last > > email, because that term seems to imply that it is a very simple-minded > > and inferior approach used by an inexperienced person who doesn't know > > anything better. My understanding from talking to the three senior > > technical leads of Broadcom is that the reality is when you have many > > real-time tasks that you need to handle concurrently, using a > > prioritized interrupt-driven scheduler is just way too complex and > > messy, and it doesn't even guarantee that you will get a lower delay if > > you do go through the trouble. In contrast, the kind of "run to > > completion" real-time scheduler that I talked about is a more elegant > > solution as it simplifies the scheduling problem substantially and also > > allows you to have more efficient utilization of the processor. > > > > Other than these two points, your understanding of my main point is > > correct. > > > >> The good news is that Moore's law will continue to drive down the > >> fraction of platforms with such processing delay problems. > > > > [Raymond]: This may be true for PC but probably not true in general. > > PC is a general-purpose computing device that has to handle numerous > > possible tasks, and a voice phone call takes only a very small fraction > > of the worst-case computational power requirement of a PC. In contrast= , > > for special-purpose dedicated hardware devices such as IP phones or > > VoIP gateways, it would make no sense to use a processor that is many > > times faster than the worst-case computational power requirement. For > > the sake of cost and power efficiency, the designers of such special- > > purpose devices will want to use a processor that's just slightly faste= r > > than required, because then they can use the cheapest and/or lowest > > power-consuming processor that's fast enough to get the job done. > > If they choose to use a processor much faster than is required, then > > competitors using processors just fast enough can have lower costs > > and power consumption and can take market share away from them. > > > > A case in point: after its first appearance several decades ago, 8-bit > > microprocessors are still widely used in many devices today despite the > > several orders of magnitude of speed improvement provided by Moore's > > Law, because those devices just don't need anything faster, so using > > anything faster would be a waste of money and power consumption. > > > > My point is that we should not expect that future IP phones or gateways > > will operate at a very low percentage point of the processor load just > > because Moore's Law can improve processor speed over time. Therefore, > > don't expect the 3X multiplier for codec frame size to go down much > > below where they are now. > > > > In fact, if in addition to a VoIP call, a PC is heavily loaded with a > > lot of other concurrent tasks, many of which may be real-time tasks > > (e.g. video, playing/burning CD/DVD, networking, etc.), then it will be > > difficult for the PC to have small encoding and decoding RTS delays (d2 > > and d5 in my delay analysis). In this case, the codec frame size > > multiplier will be closer to 3X than to 1X, unless you are willing to > > let the voice stream occasionally run out of real time and produce an > > audible glitch (which is not acceptable from the voice quality > > perspective). If you agree with this and agree that a PC sometimes > > does get very heavily loaded, then if you don't want the voice stream > > to run out of real time, the worst-case codec-dependent delay for > > PC can still be around 3X the codec frame size. > > > >> I'm a bit surprised by your analysis of "packet transmission delay", > >> as it has little bearing on our multiplier (ie the change in delay as > >> a function of frame size). See old posts. > > > > [Raymond]: I am not sure I understand what you are saying. You probabl= y > > misunderstood the goal of my analysis. I mentioned in my last email tha= t > > my delay analysis aimed to derive the lower and upper bounds of the > > codec-dependent one-way delay as functions of both the codec frame size > > AND the packet size. That "packet transmission delay" does depend on > > the packet size, so it should be included. Also, including it doesn't > > increase the lower bound of the delay (and the codec frame size > > multiplier there); it only affects the upper bound. > > > > Or, are you saying the "packet transmission delay" depends on the packe= t > > size, not the codec frame size, and therefore is not codec-dependent? > > Well, we know the packet size should be a positive integer multiple of > > the codec frame size. Once the codec frame size is determined, there > > are only limited choices of packet sizes you can use, so in this sense > > the packet size does depend on the codec frame size. Therefore, the > > "packet transmission delay" indirectly depends on the choice of the > > codec. > > > > Best Regards, > > > > Raymond > > > > > > > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --000e0cd563f4a39747048798acc5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Raymond,

What we heard so far was a lot of unsubstantiated claims wi= th some semi-theoretical arguments attributed to unknown exports supporting= them. First of all, this is all irrelevant. Second, unless someone takes a= reasonable set of different hardware, including high density gateways, sof= t and hard phones, and actually measures the delay for different codecs and= packet sizes we will not know what the answer is. So. please. lets can thi= s discussion for now.
_____________
Roman Shpount


On Thu, May 27, 2010 at 3:27 PM, Raymond= (Juin-Hwey) Chen <rchen@broadcom.com> wrote:
Hi Koen,

I too don't want to see this discussion drags on, but some of your comm= ents
seem misleading to me, so I would like to respond with some quick comments.=

Wideband is a new feature in some devices and is a check box that a product=
manager needs to check off to remain competitive. =A0That doesn't mean<= br> wideband is more important than existing features in a device. =A0Also, I am not sure the cost difference is a few dimes versus several dollars. In some devices the extra cost of adding wideband is minimal. Furthermore, it<= br> is not only a cost issue but also a power consumption issue. =A0No one in h= is
or her right mind will use a processor that's 5X to 10X faster than
necessary just in order to reduce the encoder and decoder RTS delays to a small fraction of the codec frame size; this is just the way it is and has<= br> nothing to do with the relative importance of delay or anything else.

You were presenting it as if this were a reasonable choice that device
designers could easily make but chose not to make, but that's just not<= br> true. =A0It has always been the case that the designers will use processors=
just fast enough for the job, perhaps with a little margin for the
unexpected, but not 5X or 10X. =A0Given this, the bottom line is that ~ 3X<= br> codec frame size is the "norm" or a "necessary result" = for special-purpose
hardware devices rather than by a design choice, and you are just lucky to<= br> get < 2X in PC-based VoIP calls because PCs were not designed for voice<= br> calls but for other much more computationally demanding tasks. =A0(Even the= re
you can't guarantee that PCs will always give you a multiplier of < = 2X.
What if the PC is heavily loaded with other tasks? =A0Then you are more lik= ely
to get 3X if you don't want your voice stream to run out of real time.)=

Best Regards,

Raymond

-----Original Message-----
From: Koen Vos [mailto:koen.vos@skype= .net]
Sent: Wednesday, May 26, 2010 9:43 PM
To: Raymond (Juin-Hwey) Chen
Cc: codec@ietf.org
Subject: RE: [codec] #16: Multicast= ?

Quoting "Raymond (Juin-Hwey) Chen":
> My point is that we should not expect that future IP phones or gateway= s
> will operate at a very low percentage point of the processor load just=
> because Moore's Law can improve processor speed over time.

In other words, future manufacturers won't spend a few dimes on
reducing delay, even though today they're happy to add several dollars<= br> to the price just to enable wideband? =A0That's a statement about the relative importance of delay.

For the discussion about transmission delay vs. frame size, see e.g.
http://www.ietf.org/mail-archive/web/codec/current/msg0= 1477.html

koen.



> Hi Koen,
>
> In-line below...
>
> You wrote:
>> The essence, if I understand you correctly, is that there still ex= ist
>> low-end platforms with barely enough processing power to run a VoI= P
>> call. =A0If such platforms use a naive FIFO scheduler, they'll= create up
>> to one frame of processing delay for encoder and decoder each, on = top
>> of the frame of buffering delay.
>
> [Raymond]: It doesn't have to be low-end platforms. =A0I wouldn= 9;t consider
> high-density VoIP gateways "low-end". =A0What matters is whe= ther the
> processor is heavily loaded (i.e. busy at a high percentage of time) > with real-time tasks (and thus is just fast enough). I think this is > true for typical implementations of IP phones and VoIP gateways.
>
> I also wouldn't use the term "a na=EFve FIFO scheduler" = to describe the
> "run to completion" real-time scheduler that I talked about = in my last
> email, because that term seems to imply that it is a very simple-minde= d
> and inferior approach used by an inexperienced person who doesn't = know
> anything better. =A0My understanding from talking to the three senior<= br> > technical leads of Broadcom is that the reality is when you have many<= br> > real-time tasks that you need to handle concurrently, using a
> prioritized interrupt-driven scheduler is just way too complex and
> messy, and it doesn't even guarantee that you will get a lower del= ay if
> you do go through the trouble. =A0In contrast, the kind of "run t= o
> completion" real-time scheduler that I talked about is a more ele= gant
> solution as it simplifies the scheduling problem substantially and als= o
> allows you to have more efficient utilization of the processor.
>
> Other than these two points, your understanding of my main point is > correct.
>
>> The good news is that Moore's law will continue to drive down = the
>> fraction of platforms with such processing delay problems.
>
> [Raymond]: This may be true for PC but probably not true in general. > PC is a general-purpose computing device that has to handle numerous > possible tasks, and a voice phone call takes only a very small fractio= n
> of the worst-case computational power requirement of a PC. =A0In contr= ast,
> for special-purpose dedicated hardware devices such as IP phones or > VoIP gateways, it would make no sense to use a processor that is many<= br> > times faster than the worst-case computational power requirement. =A0F= or
> the sake of cost and power efficiency, the designers of such special-<= br> > purpose devices will want to use a processor that's just slightly = faster
> than required, because then they can use the cheapest and/or lowest > power-consuming processor that's fast enough to get the job done.<= br> > If they choose to use a processor much faster than is required, then > competitors using processors just fast enough can have lower costs
> and power consumption and can take market share away from them.
>
> A case in point: after its first appearance several decades ago, 8-bit=
> microprocessors are still widely used in many devices today despite th= e
> several orders of magnitude of speed improvement provided by Moore'= ;s
> Law, because those devices just don't need anything faster, so usi= ng
> anything faster would be a waste of money and power consumption.
>
> My point is that we should not expect that future IP phones or gateway= s
> will operate at a very low percentage point of the processor load just=
> because Moore's Law can improve processor speed over time. Therefo= re,
> don't expect the 3X multiplier for codec frame size to go down muc= h
> below where they are now.
>
> In fact, if in addition to a VoIP call, a PC is heavily loaded with a<= br> > lot of other concurrent tasks, many of which may be real-time tasks > (e.g. video, playing/burning CD/DVD, networking, etc.), then it will b= e
> difficult for the PC to have small encoding and decoding RTS delays (d= 2
> and d5 in my delay analysis). =A0In this case, the codec frame size > multiplier will be closer to 3X than to 1X, unless you are willing to<= br> > let the voice stream occasionally run out of real time and produce an<= br> > audible glitch (which is not acceptable from the voice quality
> perspective). =A0If you agree with this and agree that a PC sometimes<= br> > does get very heavily loaded, then if you don't want the voice str= eam
> to run out of real time, the worst-case codec-dependent delay for
> PC can still be around 3X the codec frame size.
>
>> I'm a bit surprised by your analysis of "packet transmiss= ion delay",
>> as it has little bearing on our multiplier (ie the change in delay= as
>> a function of frame size). See old posts.
>
> [Raymond]: I am not sure I understand what you are saying. =A0You prob= ably
> misunderstood the goal of my analysis. I mentioned in my last email th= at
> my delay analysis aimed to derive the lower and upper bounds of the > codec-dependent one-way delay as functions of both the codec frame siz= e
> AND the packet size. =A0That "packet transmission delay" doe= s depend on
> the packet size, so it should be included. =A0Also, including it doesn= 't
> increase the lower bound of the delay (and the codec frame size
> multiplier there); it only affects the upper bound.
>
> Or, are you saying the "packet transmission delay" depends o= n the packet
> size, not the codec frame size, and therefore is not codec-dependent?<= br> > Well, we know the packet size should be a positive integer multiple of=
> the codec frame size. =A0Once the codec frame size is determined, ther= e
> are only limited choices of packet sizes you can use, so in this sense=
> the packet size does depend on the codec frame size. =A0Therefore, the=
> "packet transmission delay" indirectly depends on the choice= of the
> codec.
>
> Best Regards,
>
> Raymond
>
>
>



_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--000e0cd563f4a39747048798acc5-- From herve.taddei@huawei.com Fri May 28 02:56:00 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D9833A6912 for ; Fri, 28 May 2010 02:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5SBlT229kuz for ; Fri, 28 May 2010 02:55:58 -0700 (PDT) Received: from lhrga04-in.huawei.com (lhrga04-in.huawei.com [195.33.106.149]) by core3.amsl.com (Postfix) with ESMTP id DF2893A68F2 for ; Fri, 28 May 2010 02:55:56 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3400IYCJKXHM@lhrga04-in.huawei.com> for codec@ietf.org; Fri, 28 May 2010 10:55:46 +0100 (BST) Received: from h00900001 ([10.200.70.185]) by lhrga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3400KS4JKTEL@lhrga04-in.huawei.com> for codec@ietf.org; Fri, 28 May 2010 10:55:45 +0100 (BST) Date: Fri, 28 May 2010 11:55:40 +0200 From: Herve Taddei In-reply-to: <002501cafdb4$09394810$1babd830$@de> To: 'Christian Hoene' Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: Acr9Vx30wv2d857zRZSFAlE/S8FBegAKgh/gAANeldAAAYk3sAAFCOhgAAH7QiAAIOEvQA== iPlanet-SMTP-Warning: Lines longer than SMTP allows found and truncated. References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> <20100430230756.13687lc1s5o89gsc@mail.skype.net> <"CB68DF4! ! CFBEF 043D 30 B"@IRVEXCHCCR01.corp.ad.broadcom.com> <909E12B9-984F-4051-A93E-2291EFE0A40E@cisco.com> <20100526151326.2882694zuaeslk3q@mail.skype.net> <20100526214255.206532jzf8wjld1r@mail.skype.net> <002901cafd89$acf402e0$06dc08a0$@de> <19367DD02EBD40829869907AEA0CE128@china.huawei.com> <000601cafd9b$148fd850$3daf88f0$@de> <568A92CB079CCF43BA5C8D7B08BCB4AE817DCBA900@SJEXCHCCR02.corp.ad.broadcom.com> <002501cafdb4$09394810$1babd830$@de> Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 May 2010 09:56:00 -0000 Dear Christian, Some questions for clarification > So, we have consensus on > 1) low delay mode What is the consensus then? Both low delay and longer delay modes will = be supported by the codec? What is the value of the delay of the so called = low delay mode (10ms, 5 ms, lower, higher)?=20 > 2) low complexity mode (whatever this means) It is strange to me to say we have consensus on low delay mode if we are = not sure on what it means. Or perhaps you mean it is still to be discussed? What do you call low complexity? Which value? I can say my codec is 200 WMOPS and the low complexity mode is 100 WMOPS. Would that fit your requirements? > 3) technical understanding on how latency sums up on different = platforms This I must have missed, I saw many discussions, I have not seen large agreements. The last email I read was rather in the spirit of: please = stop discussing we don=92t believe what you wrote. The discussions were very interesting but obviously coming from two different worlds.=20 > The remaining discussion seems to be on which kind of platforms to support: > a) fast PC and softphone > b) embedded, slow CPU on hardphones (+conferences server) Do you think you need to distinguish between slow PC and fast PC? What = are the complexity values you have in mind for a) and b)? > A bit it is also about how to make money with phone calls in future: > a) Selling services in addition to offering calls via softphones > b) Selling devices that help to conduct calls Did that ever come in the discussion? > I know that there it has a long tradition in standardization to = fortify the own market > position as early as possible. Thus, it is Could you clarify that? > well understandable that a) and b) are competing. However, wouldn't it make sense How are a) and b) competing? You can sell devices (e.g. iPhone) and make money on additional services (e.g. Applications). =20 > if we support both a) and b) and let future market Could you prevent to a) and/or b) from happening with this new codec? I = am not sure on where you want to go with this discussion. Is that needed? Best regards Herv=E9 > forces decide? >=20 > With best regards, >=20 > Christian >=20 >=20 >=20 > --------------------------------------------------------------- > Dr.-Ing. Christian Hoene > Interactive Communication Systems (ICS), University of T=FCbingen > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ >=20 >=20 > >-----Original Message----- > >From: Sandy (Alexander) MacInnis [mailto:macinnis@broadcom.com] > >Sent: Thursday, May 27, 2010 4:55 PM > >To: Christian Hoene; 'Herve Taddei'; 'Koen Vos'; Raymond (Juin-Hwey) = Chen > >Cc: codec@ietf.org > >Subject: RE: [codec] #16: Multicast? > > > >Everyone, > > > >Sorry for stepping in here... full disclosure: I'm not a speech = coding expert, and I > work at Broadcom, > >where Raymond works. > > > >I too would like to end this discussion; it seems to have diverged = from a > discussion of the > >requirements for the CODEC algorithm to have a mode with low = algorithmic delay, > which AFAIK is already > >agreed anyway, to some rather tangential discussions related to, but = not really > addressing, real time > >scheduling of the algorithm on a processor. > > > >The point from Raymond that is the head of this particular discussion trail is RTS, > i.e. real time > >scheduling. I know his note about that is long; it might be worth = reading it again. > > > >It's not a fair assumption that 100% of a shared resource - in this instance, a > processor - can be > >spent performing real-time-scheduled tasks. If there is a set of RT = (real time) tasks > that have > >different periods, and periods =3D deadlines, all being scheduled on = the same > processor, the best you > >can do is less than 100%. How close you can get depends on the = details; it might > be e.g. 68%, or it > >could be significantly less; there's a lot of literature on this. If = the system is > optimally designed > >for the purposes of RTS, i.e. all other tasks are treated as non-real time and have > lower priority > >than all real time tasks, there are no priority inversions, task switching is very > efficient, etc. the > >RTS performance can come close to theory, but if any of these = assumptions are > not true, it be > >significantly worse. > > > >If the total RT demands are only a very small fraction of the total shared resource, > i.e. processor > >cycles, it tends to be easier to perform the scheduling and ensure = that it works > correctly. Such a > >scenario may be more important than RTS indicates if the system is = not well > designed for real time > >operation, i.e. a PC. And, such systems draw MUCH more power than = well- > designed embedded products. > >Conversely, low power and modest clock rates are good design = principles for > embedded products, if > >those that are wall (mains) powered. E.g. someone noted leakage power = at 65nm > - have you looked at > >40nm? It just keeps getting worse. Designing for slower max clock = rate saves > substantial power. > > > >There are good reasons why a common convention of real time = scheduling is the > assumption that period =3D > >deadline. As Raymond noted, other design assumptions are possible, = but they > have their own problems. > > > >Note also, as Raymond pointed out, that RTS also applies to = intermediate points > in the end-end system, > >such as gateways. Such a device may have very powerful processors, = and if so, it > should be for the > >specific purpose performing a large number of RT tasks, loading the processors > as much as can be > >guaranteed. > > > >I would hope that this committee is not planning to be in the = position of dictating > that all > >implementations of the algorithm require a processor that is so fast = that the > system can guarantee > >service that latency is much less than the period of an audio frame. = And if not, > then a reasonable > >assumption is that, in general, the deadline of service latency does equal the > period of an audio > >frame. That assumption is part of one of upper-limit calculations = from Raymond. > > > >--Sandy > > > > > >-----Original Message----- > >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On = Behalf Of > Christian Hoene > >Sent: Thursday, May 27, 2010 5:50 AM > >To: 'Herve Taddei'; 'Koen Vos'; Raymond (Juin-Hwey) Chen > >Cc: codec@ietf.org > >Subject: Re: [codec] #16: Multicast? > > > >Guys, > > > >all I want to do is to find an end to this discussion. Sometimes it = helps to come up > with some > >provocative statements. > >The example of hearing aids was mentioned only as an example of a = device that > might include a phone in > >future. If you will, I forgot > >to mention the tooth-phone > http://www.wired.com/science/discoveries/news/2002/06/53302 > > > >Anyhow, shall we consider that > > > >a) devices have plenty of power to do the coding (<2% needed for the codec) > >b) devices are already fully loaded and need all time for encoding = and decoding > (100% needed for codec > >and signal processing) > >xy) between X% and Y%. > > > >What is the minimal complexity of the codec? Enough to run at 100% = load on a > >a) 10 MIPS DSP > >b) 50 MIPS DSP > >c) 8000 MIPS DSP > >d) 60 MHz Pentium > >e) 1 GHz Pentium > > > >How to measure the complexity? > >a) with gettimeofday on a reference PC setup > >b) with ITU-T G.191 library > >c) With a reference virtual machine > > > >Decide and continue... > > > >Christian > > > >--------------------------------------------------------------- > >Dr.-Ing. Christian Hoene > >Interactive Communication Systems (ICS), University of T=FCbingen > >Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > >http://www.net.uni-tuebingen.de/ > > > >>-----Original Message----- > >>From: Herve Taddei [mailto:herve.taddei@huawei.com] > >>Sent: Thursday, May 27, 2010 1:54 PM > >>To: 'Christian Hoene'; 'Koen Vos'; 'Raymond (Juin-Hwey) Chen' > >>Cc: codec@ietf.org > >>Subject: RE: [codec] #16: Multicast? > >> > >>Hi Christian, > >> > >>> Nevertheless, in the end, my position is simple. The lesser the > >>computational > >>> complexity, the smaller the battery. This statement > >>> will remain true for future semiconductor technologies, too. Thus, = a low > >>complexity > >>> mode and low delay mode is advisable for small, > >>> portable battery-powered devices such as wireless headsets, = hearing aids, > >>or > >>> wireless sensor nodes. Or other kind of devices, which > >>> have problems with head dissipation. > >>Are all those devices being of interest for the codec under = development? For > >>example is it your plan to make use of the IETF codec in hearing = aids? In > >>that case, perhaps requirements for hearing aids should be discussed = and > >>added to the requirements. But I am not sure it is really relevant = for an > >>audio codec designed specifically for use over the Internet. > >> > >>Best regards > >> > >>Herve Taddei > >> > >>> -----Original Message----- > >>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On = Behalf Of > >>> Christian Hoene > >>> Sent: Thursday, May 27, 2010 12:45 PM > >>> To: 'Koen Vos'; 'Raymond (Juin-Hwey) Chen' > >>> Cc: codec@ietf.org > >>> Subject: Re: [codec] #16: Multicast? > >>> > >>> Hello Koen and Raymond, > >>> > >>> yesterdays, I had a brief look on ITU-T G.114 > >>> = http://www1.cs.columbia.edu/~andreaf/new/documents/other/T-REC-G.114- > >>> 200305.pdf > >>> It might help in your discussion... > >>> > >>> Regarding Moore-law and so: We shall keep in mind that cannot = continue > >>forever. > >>> Already today, due to Quantum tunneling and > >>> subthreshold leakage current very small semiconductor structures consume > >>> increasing amounts of energy. Thus, it might not always be > >>> advisable to use the latest technology if power consumption shall = be low. > >>> > >>> It is know that "CMOS circuits dissipate power by charging the = various > >>load > >>> capacitances (mostly gate and wire capacitance, but also > >>> drain and some source capacitances) whenever they are switched. = The charge > >>> moved is the capacitance multiplied by the voltage > >>> change. Multiply by the switching frequency on the load = capacitances to > >>get the > >>> current used, and multiply by voltage again to get > >>> the characteristic switching power dissipated by a CMOS device: P = =3D CV=B2f". > >>> > >>> C is the capacity (depending on the size of the structure) > >>> V is Voltage > >>> f is the powering frequency > >>> P is the power > >>> > >>> Thus, the power does not decrease if the calculation (e.g., the encoding > >>and > >>> decoding) is done faster or slower. > >>> > >>> In order to save power in mobile device, Dynamic frequency scaling = and > >>Dynamic > >>> voltage scaling change the frequency and/or the > >>> voltage to save power. If power consumption needs to be reduced, = the > >>device > >>> reduces voltage and frequency and thus the calculation > >>> takes longer. Thus, even if the CPU can do the encoding/decoding = at full > >>speed > >>> and in a fraction of the frame duration, it is not > >>> always advisable to do it like that. Instead, if energy supply is limited, > >>then > >>> calculations shall be slowed down. > >>> > >>> My argumentations above support the position of Raymond that = device with > >>low > >>> processing power will be used and that this increases > >>> to the transmission delay. However, I am not an expert in system = or chip > >>design > >>> and thus, I might have missed a few details or > >>> tradeoffs. > >>> > >>> Nevertheless, in the end, my position is simple. The lesser the > >>computational > >>> complexity, the smaller the battery. This statement > >>> will remain true for future semiconductor technologies, too. Thus, = a low > >>complexity > >>> mode and low delay mode is advisable for small, > >>> portable battery-powered devices such as wireless headsets, = hearing aids, > >>or > >>> wireless sensor nodes. Or other kind of devices, which > >>> have problems with head dissipation. > >>> > >>> With best regards, > >>> > >>> Christian Hoene > >>> > >>> --------------------------------------------------------------- > >>> Dr.-Ing. Christian Hoene > >>> Interactive Communication Systems (ICS), University of T=FCbingen > >>> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > >>> http://www.net.uni-tuebingen.de/ > >>> > >>> > >>> >-----Original Message----- > >>> >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of > >>> Koen Vos > >>> >Sent: Thursday, May 27, 2010 6:43 AM > >>> >To: Raymond (Juin-Hwey) Chen > >>> >Cc: codec@ietf.org > >>> >Subject: Re: [codec] #16: Multicast? > >>> > > >>> >Quoting "Raymond (Juin-Hwey) Chen": > >>> >> My point is that we should not expect that future IP phones or gateways > >>> >> will operate at a very low percentage point of the processor = load just > >>> >> because Moore's Law can improve processor speed over time. > >>> > > >>> >In other words, future manufacturers won't spend a few dimes on > >>> >reducing delay, even though today they're happy to add several dollars > >>> >to the price just to enable wideband? That's a statement about = the > >>> >relative importance of delay. > >>> > > >>> >For the discussion about transmission delay vs. frame size, see = e.g. > >>> >http://www.ietf.org/mail-archive/web/codec/current/msg01477.html > >>> > > >>> >koen. > >>> > > >>> > > >>> > > >>> >> Hi Koen, > >>> >> > >>> >> In-line below... > >>> >> > >>> >> You wrote: > >>> >>> The essence, if I understand you correctly, is that there = still exist > >>> >>> low-end platforms with barely enough processing power to run a VoIP > >>> >>> call. If such platforms use a naive FIFO scheduler, they'll create up > >>> >>> to one frame of processing delay for encoder and decoder each, = on top > >>> >>> of the frame of buffering delay. > >>> >> > >>> >> [Raymond]: It doesn't have to be low-end platforms. I wouldn't > >>consider > >>> >> high-density VoIP gateways "low-end". What matters is whether = the > >>> >> processor is heavily loaded (i.e. busy at a high percentage of time) > >>> >> with real-time tasks (and thus is just fast enough). I think = this is > >>> >> true for typical implementations of IP phones and VoIP = gateways. > >>> >> > >>> >> I also wouldn't use the term "a na=EFve FIFO scheduler" to = describe the > >>> >> "run to completion" real-time scheduler that I talked about in = my last > >>> >> email, because that term seems to imply that it is a very simple-minded > >>> >> and inferior approach used by an inexperienced person who = doesn't know > >>> >> anything better. My understanding from talking to the three = senior > >>> >> technical leads of Broadcom is that the reality is when you = have many > >>> >> real-time tasks that you need to handle concurrently, using a > >>> >> prioritized interrupt-driven scheduler is just way too complex = and > >>> >> messy, and it doesn't even guarantee that you will get a lower delay if > >>> >> you do go through the trouble. In contrast, the kind of "run = to > >>> >> completion" real-time scheduler that I talked about is a more elegant > >>> >> solution as it simplifies the scheduling problem substantially = and also > >>> >> allows you to have more efficient utilization of the processor. > >>> >> > >>> >> Other than these two points, your understanding of my main = point is > >>> >> correct. > >>> >> > >>> >>> The good news is that Moore's law will continue to drive down = the > >>> >>> fraction of platforms with such processing delay problems. > >>> >> > >>> >> [Raymond]: This may be true for PC but probably not true in general. > >>> >> PC is a general-purpose computing device that has to handle numerous > >>> >> possible tasks, and a voice phone call takes only a very small fraction > >>> >> of the worst-case computational power requirement of a PC. In > >>contrast, > >>> >> for special-purpose dedicated hardware devices such as IP = phones or > >>> >> VoIP gateways, it would make no sense to use a processor that = is many > >>> >> times faster than the worst-case computational power = requirement. For > >>> >> the sake of cost and power efficiency, the designers of such special- > >>> >> purpose devices will want to use a processor that's just = slightly > >>faster > >>> >> than required, because then they can use the cheapest and/or = lowest > >>> >> power-consuming processor that's fast enough to get the job = done. > >>> >> If they choose to use a processor much faster than is required, then > >>> >> competitors using processors just fast enough can have lower = costs > >>> >> and power consumption and can take market share away from them. > >>> >> > >>> >> A case in point: after its first appearance several decades = ago, 8-bit > >>> >> microprocessors are still widely used in many devices today = despite the > >>> >> several orders of magnitude of speed improvement provided by Moore's > >>> >> Law, because those devices just don't need anything faster, so using > >>> >> anything faster would be a waste of money and power = consumption. > >>> >> > >>> >> My point is that we should not expect that future IP phones or gateways > >>> >> will operate at a very low percentage point of the processor = load just > >>> >> because Moore's Law can improve processor speed over time. Therefore, > >>> >> don't expect the 3X multiplier for codec frame size to go down = much > >>> >> below where they are now. > >>> >> > >>> >> In fact, if in addition to a VoIP call, a PC is heavily loaded = with a > >>> >> lot of other concurrent tasks, many of which may be real-time = tasks > >>> >> (e.g. video, playing/burning CD/DVD, networking, etc.), then it will be > >>> >> difficult for the PC to have small encoding and decoding RTS = delays (d2 > >>> >> and d5 in my delay analysis). In this case, the codec frame = size > >>> >> multiplier will be closer to 3X than to 1X, unless you are = willing to > >>> >> let the voice stream occasionally run out of real time and = produce an > >>> >> audible glitch (which is not acceptable from the voice quality > >>> >> perspective). If you agree with this and agree that a PC = sometimes > >>> >> does get very heavily loaded, then if you don't want the voice stream > >>> >> to run out of real time, the worst-case codec-dependent delay = for > >>> >> PC can still be around 3X the codec frame size. > >>> >> > >>> >>> I'm a bit surprised by your analysis of "packet transmission delay", > >>> >>> as it has little bearing on our multiplier (ie the change in = delay as > >>> >>> a function of frame size). See old posts. > >>> >> > >>> >> [Raymond]: I am not sure I understand what you are saying. You > >>probably > >>> >> misunderstood the goal of my analysis. I mentioned in my last = email > >>that > >>> >> my delay analysis aimed to derive the lower and upper bounds of = the > >>> >> codec-dependent one-way delay as functions of both the codec = frame size > >>> >> AND the packet size. That "packet transmission delay" does = depend on > >>> >> the packet size, so it should be included. Also, including it doesn't > >>> >> increase the lower bound of the delay (and the codec frame size > >>> >> multiplier there); it only affects the upper bound. > >>> >> > >>> >> Or, are you saying the "packet transmission delay" depends on = the > >>packet > >>> >> size, not the codec frame size, and therefore is not codec-dependent? > >>> >> Well, we know the packet size should be a positive integer = multiple of > >>> >> the codec frame size. Once the codec frame size is determined, there > >>> >> are only limited choices of packet sizes you can use, so in = this sense > >>> >> the packet size does depend on the codec frame size. = Therefore, the > >>> >> "packet transmission delay" indirectly depends on the choice of = the > >>> >> codec. > >>> >> > >>> >> Best Regards, > >>> >> > >>> >> Raymond > >>> >> > >>> >> > >>> >> > >>> > > >>> >_______________________________________________ > >>> >codec mailing list > >>> >codec@ietf.org > >>> >https://www.ietf.org/mailman/listinfo/codec > >>> > >>> _______________________________________________ > >>> codec mailing list > >>> codec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/codec > > > > > >_______________________________________________ > >codec mailing list > >codec@ietf.org > >https://www.ietf.org/mailman/listinfo/codec >=20 From hoene@uni-tuebingen.de Sat May 29 01:29:13 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD1973A6858 for ; Sat, 29 May 2010 01:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoKFAR0aKFcs for ; Sat, 29 May 2010 01:29:13 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 6F7D13A67AC for ; Sat, 29 May 2010 01:29:10 -0700 (PDT) Received: from hoeneT60 (dslb-094-216-241-118.pools.arcor-ip.net [94.216.241.118]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4T8SMXC015980 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 29 May 2010 10:28:28 +0200 From: "Christian Hoene" To: Date: Sat, 29 May 2010 10:28:20 +0200 Message-ID: <000601caff08$ea3c92e0$beb5b8a0$@de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01CAFF19.ADC562E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acr3JL1IiwlyB/6vTvaO1s4zE2jbTwHXP5Tw Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: holubjan@fel.cvut.cz Subject: [codec] Call duration vs. speech quality X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2010 08:29:13 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0007_01CAFF19.ADC562E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, At the last IETF meeting there were some slides on the call duration vs. quality. I found the following publication on this topic supporting the correlation between call duration and quality. With best regards, Christian -----Original Message----- From: Jan Holub [mailto:holubjan@fel.cvut.cz] Sent: Wednesday, May 19, 2010 9:27 AM To: Christian Hoene Subject: Re: Call duration Hi Christian, attached, enjoy. I am not aware about any similar work but I am highly interested in any new data, [...] We are working on this topic continuously and have some better processing methods developed (but not published yet). Best, Jan Assoc. Prof. Ing. Jan Holub, Ph.D., MIET Czech Technical University Faculty of Electrical Engineering Dept. of Measurement K13138 Technicka 2 166 27 PRAGUE 6 Czech Republic Phone: +420-224-352-131 GSM: +420-602-649-654 Fax: +420-233-339-929 http://measure.feld.cvut.cz/usr/staff/holub/ mailto: holubjan@fel.cvut.cz ===================================================== This email and attachment are confidential to the addressee. If you have received this message in error, please notify the sender immediately and delete the message from your computer. We have taken steps to ensure that this email is virus free but the recipient should take the necessary steps to make certain. ===================================================== ------=_NextPart_000_0007_01CAFF19.ADC562E0 Content-Type: application/pdf; name="CallDurationPaper_v11.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="CallDurationPaper_v11.pdf" JVBERi0xLjMNJeLjz9MNCjU4IDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyA2MCANL0ggWyAx MjQwIDQ2NCBdIA0vTCAyMzIwMzYgDS9FIDk2NzY5IA0vTiA3IA0vVCAyMzA3NTggDT4+IA1lbmRv YmoNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTU4IDQwIA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDExNDcgMDAwMDAgbg0KMDAw MDAwMTcwNCAwMDAwMCBuDQowMDAwMDAxOTExIDAwMDAwIG4NCjAwMDAwMDIwNzAgMDAwMDAgbg0K MDAwMDAwMjEwOSAwMDAwMCBuDQowMDAwMDAyMjcyIDAwMDAwIG4NCjAwMDAwMDI2NjYgMDAwMDAg bg0KMDAwMDAwMjY4NyAwMDAwMCBuDQowMDAwMDAzNjQ4IDAwMDAwIG4NCjAwMDAwMDM4MDYgMDAw MDAgbg0KMDAwMDAwNDIwOCAwMDAwMCBuDQowMDAwMDA0NTgyIDAwMDAwIG4NCjAwMDAwMDQ3NDcg MDAwMDAgbg0KMDAwMDAwNDc2OCAwMDAwMCBuDQowMDAwMDA1NTUyIDAwMDAwIG4NCjAwMDAwMDU1 NzMgMDAwMDAgbg0KMDAwMDAwNjQyMiAwMDAwMCBuDQowMDAwMDA2NDQzIDAwMDAwIG4NCjAwMDAw MDczMTQgMDAwMDAgbg0KMDAwMDAwNzMzNSAwMDAwMCBuDQowMDAwMDA4MjYxIDAwMDAwIG4NCjAw MDAwMDgyODIgMDAwMDAgbg0KMDAwMDAwOTExMyAwMDAwMCBuDQowMDAwMDA5MTM0IDAwMDAwIG4N CjAwMDAwMTAwNTcgMDAwMDAgbg0KMDAwMDAxMDA3OCAwMDAwMCBuDQowMDAwMDEwODAwIDAwMDAw IG4NCjAwMDAwMTM0NzcgMDAwMDAgbg0KMDAwMDA0Njc3NiAwMDAwMCBuDQowMDAwMDQ2ODU0IDAw MDAwIG4NCjAwMDAwNDczNDEgMDAwMDAgbg0KMDAwMDA0NzU3NCAwMDAwMCBuDQowMDAwMDcxNDky IDAwMDAwIG4NCjAwMDAwNzE3MTkgMDAwMDAgbg0KMDAwMDA3MjI0MyAwMDAwMCBuDQowMDAwMDcy NDg2IDAwMDAwIG4NCjAwMDAwNzMxNTYgMDAwMDAgbg0KMDAwMDAwMTI0MCAwMDAwMCBuDQowMDAw MDAxNjgzIDAwMDAwIG4NCnRyYWlsZXINPDwNL1NpemUgOTgNL0luZm8gNTYgMCBSIA0vUm9vdCA1 OSAwIFIgDS9QcmV2IDIzMDc0OCANL0lEWzw5ZGM3NDgwNDJmNTE0YjVmNDM2YjY2OWU5MmZlYTk5 Mz48YzFiZDdlY2UwM2NjZDQ4N2VlNWZhYzM5OTc4NGIyMGQ+XQ0+Pg1zdGFydHhyZWYNMA0lJUVP Rg0gICAgDTU5IDAgb2JqDTw8IA0vVHlwZSAvQ2F0YWxvZyANL1BhZ2VzIDU1IDAgUiANL01ldGFk YXRhIDU3IDAgUiANL1BhZ2VMYWJlbHMgNTQgMCBSIA0+PiANZW5kb2JqDTk2IDAgb2JqDTw8IC9T IDI2OCAvTCA0MTYgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA5NyAwIFIgPj4gDXN0cmVh bQ0KSIliYGBgZmBgucHAxsAglMcgyIAAgkAxNgYWBo4WRiYJBoYNWsx6nOKK74uWemjuYGDwuL7Y tqSBARkwHuFpmFd6/Gbuig6OQjV+S07tyPjOZ3Pm3jXKW3WzzUJ3Q2fThJqTGg5fF1cmt7Evql0e c3Ln+1vPslfd1eG2VLsWnX1qrfS8Y54cC18+aTjSeX1+4YrCw23JjRtOaiiyK067U3ltYR/7IwZG QYkOEGBg4ACSQBcwqaVldEABkMsohMQHKQuFSjAIwoUYIUageQkI5BmYdq4F0ipAbAUWEWUQYNjF 0MUgxNDHWAoMrDUMnYy1jIkME4AW/wbybYA4CIg7gVgLiNuA4nu5Ehr/MVgyXmK4EhvJcI7xO8M9 ps7oiQxtDB0MMswuDD0MLQznPLcxHFT1ZjguK8OwQ2kB4wrGZEZfxiyGB4yqjNaMYUjBasrAXCsD pJmA2BsgwABmm3s9DWVuZHN0cmVhbQ1lbmRvYmoNOTcgMCBvYmoNMzUxIA1lbmRvYmoNNjAgMCBv YmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDU1IDAgUiANL1Jlc291cmNlcyA2MSAwIFIgDS9D b250ZW50cyBbIDY2IDAgUiA3MiAwIFIgNzQgMCBSIDc2IDAgUiA3OCAwIFIgODAgMCBSIDgyIDAg UiA4NCAwIFIgXSANL01lZGlhQm94IFsgMCAwIDU5NSA4NDIgXSANL0Nyb3BCb3ggWyAwIDAgNTk1 IDg0MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNNjEgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BE RiAvVGV4dCBdIA0vRm9udCA8PCAvVFQxIDYzIDAgUiAvVFQyIDY3IDAgUiAvVFQzIDcwIDAgUiA+ PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDg3IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNiA2MiAw IFIgPj4gDT4+IA1lbmRvYmoNNjIgMCBvYmoNWyANL0lDQ0Jhc2VkIDg1IDAgUiANXQ1lbmRvYmoN NjMgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTAgDS9CYXNlRm9udCAvQkRL QUdMK1RpbWVzTmV3Um9tYW4sQm9sZCANL0VuY29kaW5nIC9JZGVudGl0eS1IIA0vRGVzY2VuZGFu dEZvbnRzIFsgODggMCBSIF0gDS9Ub1VuaWNvZGUgNjQgMCBSIA0+PiANZW5kb2JqDTY0IDAgb2Jq DTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMzIwID4+IA1zdHJlYW0NCkiJVFLJbsIw EL3nK+ZIxcFLFoqEIlGQKtRVJe3dOBMaqXEsJxz4+8YeF+jBtt7MvDeb2Wa33Zl2BPbuer3HEZrW 1A6H/uQ0wgGPrQEhoW71GFG4dacssIm8Pw8jdjvT9LBaJexjcg6jO8PsYfu0fnyeV5WY8ztgb65G 15ojzKpMfn5Nlv3J2h/s0IzAoSyhxiZhmxdlX1WHwG75V191tggyYBEr6WscrNLolDkirDjnaemf XJeApv7vT3JiHRr9rVxyjZa89EjUAaXrgGQWUCYILQkVhDShZZlMWaLe/Z86JfOCPIQJQVm2lIV0 haJkUb6gkAXppmRsKESScROMKdFTqicnehZrpQaKaCR6Tj0WRM/zy3ymZyFjA1Syn5jf7WUR+uTc tKPwAcIK/PBbg5c/Ynvr5+xP8ivAAK+kpDQKZW5kc3RyZWFtDWVuZG9iag02NSAwIG9iag04ODMg DWVuZG9iag02NiAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDY1IDAgUiA+ PiANc3RyZWFtDQpIiZxWTYvkOAy951fkvBC3LUu2A0UOuwsLe53chjl0V3cNDMxc6jB/f2VZ/kh3 TQaWorBjK9KT9CTlz3162nc3u3m/Tc6bNc2Wf2WXyFiYo40m0Erz/n16+use5utdZOx8v/6Ynv75 5Oav92mxxlrLaq6Tnfef0+eLtYB85HmN1mKylryujtc47EPZZ1kkPed7et5WEy7loAqLQlZMq57l F/gZn7sSCHp2y//ty/7v5MhE61dGvf89CVbKWC8dIQ3KsnW88grdqJwr8vzs13Kf5UYPfBz0sDzx HT8WfaH88brt33K8A4TQMYFTTMVullkATMSQ5sUZF11s8JOKeizQm79XDR6v7lUhWY0hKoTqalJo GluKj12VeHtN4G1w+UGoKGTYTCpQUkFhFMzgrME0B1yNxcymTplMFsbqan5fNLQ39Y2yzljZKRsg DkiYA6Fhl7zoU1UOJbrdMJFxvzRsb2p0BPA87GkgINkDg4uzR2DeOwOPcdERl/dkAAZcSyfm5wGZ p47mLYfZbtF4Foi4LUyPXCFRWP4OSeKAn4WIs+RLlhYgk5D5xzSLiJhp9iCSLiYDrJGBO/ChxRJq ErkmIJV/LcRcDz4NcR66QSZP9UwSvv4Pwt66LXrV9zI5X3r0mr2kHaaR+AGx3MrOzVyZJqbzBAJ4 45BFOeNhCEellrjOMD301iDwbh2m1I0dkh0L9NZOXG+I9ZyqC/ieigunGkmaBVHrFUHx4Ie64v9r 1wO+pKBh1PQIzlXTMJ69fiyfWjrnZVNs0Uk8nKZX0gz67KSfF+bq0GJXPbu6eEOc4uYyVkZicVNY NHRmMRWPRcD9yWpuZRd5ZsBM6ExobQOgVmdL1HVDmVKcATBOJsq2uIRmvQjDQDatP8YqTsO7AjEN t11rG0GD0ho36fnN/FGIpyeT4aCqKX/ZuNWkCnW15YV+XenXLzFVP8JDlDZrhEudCadeVHtS8Cpw AkQ6G6cZgPt9ZnaIfQzGmo7KsVYXH0b4tmD0xZnDR8b774suxxm1Bb7vQr23FMFUEHtJ/e8H/2NE dDLFi9wqhnrFS1T2PyQKLtQo4OmX0bYQd7VUaekvnUKXthzEPnwXFcmrLKMj7Y1VrzidBjUiBwF8 9/zc9a3HNFQR/hJSZZgaBqa3hu5gCt/0XQ8nAZOB9Z8AAwAj+UD7DWVuZHN0cmVhbQ1lbmRvYmoN NjcgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTAgDS9CYXNlRm9udCAvQkRL QUhDK1RpbWVzTmV3Um9tYW4gDS9FbmNvZGluZyAvSWRlbnRpdHktSCANL0Rlc2NlbmRhbnRGb250 cyBbIDk0IDAgUiBdIA0vVG9Vbmljb2RlIDY4IDAgUiANPj4gDWVuZG9iag02OCAwIG9iag08PCAv RmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDMyOCA+PiANc3RyZWFtDQpIiVSSTW+DMAyG7/wK Hzv1QAiUrRJCWumkVdM+tLLdQzAd0ghRSg/990ts1m4HiJ7XtvzGTlzttjvTTxC/uVHvcYKuN63D 43hyGqHBQ28gkdD2epqJ/npQFmJfvD8fJxx2phuhKKL43QePkzvDYrN9un+slnUtl+IG4lfXouvN ARZ1Jj8+vbI/WfuNA5oJBJQltNhFcfWs7IsaEOK/9ddYfbYIkjiZnYwtHq3S6JQ5IBRCiLQMB8oS 0LT/49EdVzWd/lIu8mlSUHa6LQOlSLTaEGUcW3HsNiN6YFKNJylkTtQkREnKlDOtiYKRQiS5KCPv Z+6c//pgW1fbgrt4WySuWdQscjPRESUtixWJkutSRUeW8AVYXHFmzmLDjZqMTVazLTYSJhZ2e1mE Pjnnd0QPgFYQht8bvLwRO9ow5/BFPwIMAPQypVAKZW5kc3RyZWFtDWVuZG9iag02OSAwIG9iag08 PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDMwMCA+PiANc3RyZWFtDQpIiVSRTW+DMAyG 7/wKHzv1kARYxaQKaYPD2LQPrWz3NDEMaYQo0AP/fiSm7XZILD9+7cQ2K6qyMt0E7N0N6oATNJ3R Dsfh5BTCEdvOgIhBd2pavXCrXlpgS/JhHifsK9MMsN9H7GMJjpObYfNQPt8/Pm3rOtnyG2BvTqPr TAubOo0/vxZyOFn7gz2aCTjkOWhsIla8SPsqewT2N/8aq2eLEAdfrD8ZNI5WKnTStAh7znmSe3Or c0Cj/8fPWcdGfUsXXdUxz6NFvfLsrKIkLzsGGVekzvIAm+AJQbAIUKQEd8EkIsB4fUUGk3KCazFN 8C7AhFNeTLAkSDWTjDqjmml66XMxO7E2QF/2nfsdXQaqTs4tsw6LDKP0Q+wMXnZtB+vn5U/0K8AA vx+ZSgplbmRzdHJlYW0NZW5kb2JqDTcwIDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUg L1R5cGUwIA0vQmFzZUZvbnQgL0JES0FISitUaW1lc05ld1JvbWFuLEl0YWxpYyANL0VuY29kaW5n IC9JZGVudGl0eS1IIA0vRGVzY2VuZGFudEZvbnRzIFsgOTIgMCBSIF0gDS9Ub1VuaWNvZGUgNjkg MCBSIA0+PiANZW5kb2JqDTcxIDAgb2JqDTcwNiANZW5kb2JqDTcyIDAgb2JqDTw8IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlIC9MZW5ndGggNzEgMCBSID4+IA1zdHJlYW0NCkiJnFZJrtswDN3nFF0XiKFZ MmD4AF1n9/EXiYHc/wiVOIlS7LboQrBN8T0OIinfvjZjoq/L1RXrysaEFb/Du64D343f7664JTd9 V9+XsqGm3gmp7pa6EjIBa1UJhdir3NoR447GZjdEDHaIKdAT9wruWWKvz0YIflqyGhW2yVfkGPAJ 425yWE33tX8/ft0eP29maZQ/HscN8hOQLwSVk2bnQE4bAmQjmsq/EV8gGxQ5xMCZYD/ThKd4tEzs qRhE/zSGCZ92C8kV59/jMbCizwgWI9EgQezBNEcqoUqSLZykcOxhgehzBS86D5B3v6IsDrsvBWyh hzyqx8ysL8GJfgutnSUAQsTdQEQQLmse7P8foX33nHOQtXN8qfwn7WzQH0LrPmlUfBPsWqvwAXyx qbV3GMT9VPXuPSLT7pa4TYmRl0E1q7L9eySMOs8t734eH3j56p4PVbKKJcZ9qKSrWCYH1olIuAe2 uUyfFKWDgqaE36HkXZ8L+51MFn4LIjubFN6Tg9UXv/HUEkTq50aawqswapZ2zW43Rq2pNN59kk7Y LB4cu5UWAMfLCW0U9bprsKqEAmnLIDtlGUN/fuLhKnp1W4SJw/xJMn9Sr0vdEDH1Kqbymyq4msEY Yj8olhFKWsFSakxnSn22XBHTlmnZKnThQu0ewj7eDcRcD6PhrfAl+HaR7FBIw7VlVynP1rcek25x lgfsbuhBr1W6xE3z09OZZBfkHtGTmuUxabqgP8qk6agJZ+qOUPdQ9obstsqxnK6s8aSCCY7cI5oN +7gXvrCuOu6htIyU1v/+a9jicu+mq4talPLuL0tN19n0o1BoxF7/peionJWojPnHP5Waooj1yA1q 13xSCl0KlRM5cv59NJ4zHiXjw1a7o8pMIS9K8eyG4k7r5FZjmiUpblGT2FwrnZXzL/sWRtP3bwEG ABUoTQsNZW5kc3RyZWFtDWVuZG9iag03MyAwIG9iag03NzEgDWVuZG9iag03NCAwIG9iag08PCAv RmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDczIDAgUiA+PiANc3RyZWFtDQpIiXRWu47cMAzs 7yu2DnCGXpRkwHCVKvV2wRW7Rvb/PyESxZEo3W1lWySH5PAh3/983H99mM0YS7f79fH3MCYEY4jK Mxtj/PkZTNpcPSc5v06/7fUgn65Jdpy85IUuEU0A6fy0Gx0NmmJ5xhWStEpIAmB9A6iR2e/nlOD2 UV5yfXGLJYl11M6iDhJYgGD1q5lMCk4l/GMU4cncfN2ZXKY0Sc5enladWeHhanA+L8mGidclB4qn 3cKxmoJFXUdIu0mNs2YzWCvurJ21fTpN4+P5AxQBKqsgOfJORo/UNQfg0+d9bh5WIND2yU2JnkQe 1Zhy4ZybrbppYClwGBCRFZUoZtRUKzF8fg2deg7uBaYUr7j3h/hLYmAGQD9zs0MNAlVuaXsM9qCQ JJjhjQR1R/83DdREDF1on1mskAiSN4XcXhVgMhVI/wWWK8nO9cmv+k8poJF2fZ1hi5h29HykVrtL hCgqzh9ato9G1zp6JNWwixjtwnnbPhH6s0fWPZnK5BxYWsOHH0HpCqVOrpUpaHu7fjzmIFLvd/ET 1tQ01zb2ji4GmKrQPyuytfuWJAdFbT+O8yyJJY8ij3wWHXFQ8/Yqb+Bogq2jzhYHVVsWHaQVlj0a sE7oWIBcR9hHYhDKMMtm+ya22jvSe/QtASnD/FviSxOd9dXaqQAJBXC7VNaishJOawK88E3GIb6a KzK5LUsvHCaYSI+PA6C3few1rEbigL0at9k4SgC9zSbxulbJBgGFT30HQEp+lWIM5wzUXA5g3F8T r6EvkSRLPx/qksfuVsOOrVYbcsdNk5abBkK+JfKhoan3fzvQ6jwN/jDq0pALKh/KhHvXL7bDg12y aTtU2fNw2dV3lz4X9bde3pjXGsXjBzJ6Ig4qPB/pXSRFT9dqXKtmlIMvntzOKsjeNikFIS+0G5fV 1JUJtUK4bo7HiFo0zPNsDeThNPTka3C2/IslCjdzu//mME3/I/VOhuPCQp7X1x4bMJrNzW2tVOr/ pRu/oDUPibT1/vn1X4ABAHz1Su4NZW5kc3RyZWFtDWVuZG9iag03NSAwIG9iag03OTMgDWVuZG9i ag03NiAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDc1IDAgUiA+PiANc3Ry ZWFtDQpIiYxWuW7cMBDt9ytUB1iGw1uAoCqVa3WBi41gFQHy/21IzsHDu4ZhLERp7jdvhj7ebncw ykTvljsoCDEux6+bVlpDPp2331s+Oa213e8QV+Xyu8vvHvIzjt8h5PdzB6hvvcTH3Skopn/yL03u wm7Er7tYkw+Dao7os7n3lIX4PengDeZWrZJHKxFC/qhsjUlOEjkKeC7P3tQ/9tFDK4RdvYj0IsaT VB77+/F2O35U1LUvqG+o7S1ZJ/RW0NP5m3cIAwJWvJbM8i8/Afbj7+3nccACy3HdwCw6/+VHsMql xUStcox/GM1RtNJiAPRuTsy/evQIKQNfa4oUsUJN0QxFy14pYD1Fr6JZjAsqSUzhlX1Z4n4PEZRH wC0Cxi0HwkbvmbjUe1IJDPLIA/Y1sIeKdI9Jh0Oc0/fQwX1NsrOPFZnxtmN8bXFuuDEQPg1aYEAK u7aqbpAaF70T8AbLLiJ5JqrjRNXQBmOTrz0Y2UBFZmgSzUz0u1aJlQtCH6MB+wo7Vo2ygDLHGa/0 E660CuJk48sEVJdlKMLkkgsU19iVflbAMXCVAmljVtSTpYaJyJcK10GpIs3zWluWtm4JuBW1LhKI L/dRcg9bt8y8R0mkasXGcYhSZV2MV0lEVhsbdgNQWqCvUe5XCemYwpyvIR6EyWXLUlRpbc+q3ojq OkmANsDZoVOrvoa9lYTEX0y1sU6ZUnjdnr7DS5+N444XTDefbCkyWkTM1nEptQKN02jniLb9xdWE o5PKYNe2XXV2jTaVLYYah4wyRDuZILzPnjN2ukOjS625I4k/sa8RNXUAFice56jeqPCUuTU/OzPi MdmnLkgBAWBUMGlv67JvMCu0FJ+u7TElWds9n2FgF7RJRx/UTBlyaqBI8mTrxl8C2ULC0Jl+pq4C vper1DheZmjKHxkFlzqacFQY9bwV13zTsKUlMnUX9xD2zE3z21henyezcQhnxhTq5ozDrcMQmm8N qMddG3Mu4UX7ZKWQyotb1wIOxJf/qwyqVhIfPRSnawfodA1/I1CnJjfkGLvcRnInvP8XYADiFEvH DWVuZHN0cmVhbQ1lbmRvYmoNNzcgMCBvYmoNODQ4IA1lbmRvYmoNNzggMCBvYmoNPDwgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA3NyAwIFIgPj4gDXN0cmVhbQ0KSIl0Vjuu4zAM7HOK1As8 Qx9SkgHD1VZbp1u84jlAir3/AVaiSIqyk8KII5FDcjSk/Phze/y6ucU5j/fH8/Z3cw6Kc7jWX6jP a4/LWhex9AXMvABlD0toL9k5F/cvH/OSN7byb9Yb7FGfWB/k/6k/7f1i/5TQvi4uuM3bJpGOh273 oTuk3S8g9hC7fRAUWOedlrD9H90O5A5lVDMZVCjXI8UpT/snUOLfj0EwCMGxVZzYhplo+CF4wncH JxEpWHdwz9lIAdZBATw5i5/ZFiu1cFwDkQ8Mn/N+Y4qoDUJv2cQiL2lrRc3/W+rAqHSgz3m/ZdLQ JoxiaXKh0SRQrBkQjbz4KT1p5BDe749/t4BLDpDu4Bafcr4/ft++CLII84FPlPCO/SuOgrC/0w6M SNOeegA0Bfitq/fiL4rMjPXsIr5GC02puL0LuXaDxlcRVz2vzKBBd07w3btRGFJH0ZPgvdo/nuh/ W1WejSlYomOqTVTlke71V0iex4f2t7aCNiblbrfGeHlWuWuLe85n6qx1mkbazKwEOE8RwUCxfBuC kpXjiqz0NDrBe2YrmLnhlUGu4rg6DB2dS3Wv3W0n409J8vbBWBOrEp3PRaZM1jF+nsOelcIV11OJ dNggwxhnw6lkqRi6PoLOvr4AabQCG0NuRcXNWNFgTmL+af6zOzIbeZvXB7EcWl7IKOuxitg0aZNs vbpgSixqriCT5Zyzgae7DywhCuk/zPzzaUCQxcjpFpNyMkZ00EVvMEmlA6Asif4Ud/ivrBqZIAOw uKHRspkXIh5sJES582wl14sByH3VtGzH84wJQ3UauBjv9zebZEZX1cSxpbjfK9OsvNxt0nFBxkfj g06TzWSmGHPYvQoxRNLOqpIp3XXsVc04/TbRcoSzNMEIshWHoLjxLVZGRcQaTMloCVWZA26O1OQT euJv54UZCNoWMitU5kVQ++UiXzAuGsJR7mpBMV3s6JORMCO7jZkihLZlWC2xfQZSNBnWSW/+Vs2H S0m1EWynmSS51WO/S178gkKA4+s4rsifL2J6tGTt56foS0xJscgDZDvB+PEVpPbZ+qDRjsSkBnG9 r5AaXxSsiesXOk4ZhKFnAdChL9b4Y/Xcudm//wswAJY4gFoNZW5kc3RyZWFtDWVuZG9iag03OSAw IG9iag03NTMgDWVuZG9iag04MCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3Ro IDc5IDAgUiA+PiANc3RyZWFtDQpIiaRWu47jMAzs8xVbHxBDkqmHAcPVVlunO2yRGLf//wknUSRF KgauuMKIQw1HfIwoP75ud7+E4NNH/fUp54/H580tzjn4eJy337tza/2zhvqk9nLc/bb4agZwLvr6 m405VFSwphiOe1hS89nsQsXBqz7FMqfODj/9ifW/93aXs2+uydzh/VJUZPH8J60J5gjdvUV0vq1f mMQlxvqUkUiI3YXMFff9+Lo9fmE9ddbNUbJfy7Jx+Ff21EpJqW3DP1JeyHsODOeKHADCgdhE/smu x2drld9VhH5ioMpjNBSlZhQ5MGM63BLay0qAQmG8uCj3pjcvemt5IDO28bjDAnvnby12qhW459kF RijBtxhi2Hp7QNYLv0G1uSXvpIeT9j2tp9TrmncV3hFBqrkvcR+c+LvJvoXUN+906l3aQUHUiLdw vAqVhkrmiLvKucR4oj1XuPUoFlXlSTl82PK6rG0AVFEU7KGk9DKA2sqqGlYHPN8B/yFdosB+v0nI QoBOIac/NZWDITOatpFXsnpMokd3ULuxyWm3x7OGbGQEfxg1tzq41BuYe8kIBSOcgaiHpuwGhv3f 9gm4Gpo4Sgl8NizCSwp5nH5h40wROkUNVcKrGgFCm/nNoEGvqDd9KEY9Bxtwmla8Po/xcABdK6SI kwyQ1ECLEQ+hQesFyMoTdZjoUFywuJdiwskIymD2e14M9tQHAqo/zI60WBMPMmDEo713bUcdbp2D K13C5IWtb+t5poitoCJHmtR80EwEG9mjKbyay8cqovRKu2RuXMk7c8/UJpIPv7hTdPwz+fBtchIU J8FzAglhOYL0jvslqKxpkgpSxh5vlt+DwDqCZJT6PSYMcjWNS4k+HMyOSRuw3KasUYZxA207E218 VYJewiYWA8ICBJZVZqT6Vlojze98ULteFIq6NxhkOiaVphvcSzkGnHcPcwRRBa6+gMgwbTvcAt+b fXnr28RxmzID8M5pwkq1/BXVCAG/bI7vvwIMAJf9Rm8NZW5kc3RyZWFtDWVuZG9iag04MSAwIG9i ag04NDUgDWVuZG9iag04MiAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDgx IDAgUiA+PiANc3RyZWFtDQpIiZRWuW4jMQzt/RWpF7ChizqAwVSptna3SOHMxv//CSvxEjUxAmxh QENSPB+ffP99uf+6uJtzvr3dj8ufzblU+u/Y0y32D8j9V+QDjCb1D6hGO++E/vPOubhfG9wSi1Jb RCF38zAOhcIMnXde7aHbp0pRF92Qp1M2eKF+dxRdN6jj0A3iSTlve1sHx5Q46am92D368n71E9L3 wCntH/fZ3STdxaw50ZFw9x7RaY9PB/fcr+7mN/IH7CygZPRQDW1z0AxG/FvmKNjzbKJlrJij9RLS YwlhHVnTYYbmKmj2I/M0vC1BHXkei9t9IHt4lbiBB2WTtfccRts0hhA5RnbbUtPS8qwt75Mddp+j O4kbh6FmgQMKgq064QumW1U9wWNMqArsRkVfY26r1zEzSRRM8kDlCAAlgU91b51wWp5aIuBJDLhT IUsbT1nYbcLOPsz1hrZ9I+Ot8UYaOYIOC7X9dUEJ4/ghQ9Ex1gLgzke3biSLLZisGPpRIc+KyJGR rqoAkGUNM+2Qi6HFN/d2fydMmJx7rRk99pE0pj1Z7EDMFPPucFy4qJmGZPSyM9Hh58vVzrLaeVuM z6WKGAZIqVSs4SpFdLHPpWgpVUvJk3ItfpHdwma7I4InH+BgdsQMUsFSRwJhmwBLjIYISvvLNSAG lWuyJ+TjcdqReWFI44rJeS1oEjCplS9Oo0UcDfiKrT73DQC6yPC9In71wRu0ScAfcflUZFMrFSdi BhhyE29JaArGafnjuvKNGa4Dtp+CLj/DO89IGk10RXOqegLxQt3knGZRmt3iKcm7cmJm1pua6uC9 wH2g2b6I/bXQMBgaFjdzmxCXgXelCYc9GGPAqVbmt8qYeRgeK7OvNS6kbEUgjC3BZWP0MWvy1K2A ZMVh0pOVrebhbvrAwHa6i6bEpPQMNrFYSmyTr4M8ss3kWxbyNV2lRkoPcsdW4e2V/Uon+lKbsgce nnnEM+XppXA20X8QaxPUV2LSE7wejJJj0qrYDua3ecuwckdckV0WmzO1078Ci7CiTJj4bmSO8/yE 0iG7yTKLxtYDKWEOjAu2rNah+b+q1mNsybwBVilU9yJw73M8if7+T5bLiw9Opmqy/r5n0xvv2cc/ AQYAYaN8yg1lbmRzdHJlYW0NZW5kb2JqDTgzIDAgb2JqDTY0NCANZW5kb2JqDTg0IDAgb2JqDTw8 IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggODMgMCBSID4+IA1zdHJlYW0NCkiJhFW7jtww DOz3K1wHWEeUqIcBw1XSXK3ukGLXhy0C5P/bIyVSkvcVHIzVUdRwOKSo/HHKP05mNgb8lPfT52oM 7pubF1p4oG8hQ6LfQF/UDbOBLStMm52t+rZ9cjZuO0ePs+f/LX3+zhY2mJEXaQypEIgCjHQOb2pN T4CdMGRHHFnY7QzVjbau4Qkv5cDnD0FwTLezszXRghFMo4DL9id3JZ0qWSgpmlXd4jquWEHRD6O4 Rw5RlWHKml2xMam4duOAtMtWwULJKGqeHAWgEP2ZM0ww5dsJ7GToj36cWSZrw2xwyv9KHqZ1BHg+ Knmnqp2Drgdv4a5NILyU/N6b6HA+9NKpRnhVn6X6RGoCLWCpLUgnasAwBClkSn5mosJDnPKvmsjC iTAeSrsVceQY892ruM4IFxRobaskIdOQY9jyX1bSipIUScQsK2dJcpwgpdmpogCqqIs1W1UFTKrd vkhH3epXkrp0dfFy9PeC0zpN8QAr3kWqYSUb12+B+tR7skj0w86bGjUfbsjnNeLG9NqYXvEey0XR rYVQihZiL1tTy7+t23a21smdqvf9dQ1HD61kRUhVgdCTONg9rQ8jqO3EkiDnAW4GExO1AGfQyAcp 01DCOvNEjGu/9fCl4Axtb93Lx066I4l8EvdOv2GiYx8wtXbRzWEdBtM46b3wGmfpwwhs84WNgrkU zH6mvQ2Ht4O773Z35vjkNNfDGFHjMEt6TCsPxdfb8b3og0DUxoGNrValZ9N/Wqh7NLpJp6xTOfh9 CPqQwXpXAN31D1NUwYC5Nj2LiXrQ1ERGUVLLLAzt2SO8kiatLwBGaWiQDdL0EK9vVzhIU73k2fmd T98CDAAKrLzFDWVuZHN0cmVhbQ1lbmRvYmoNODUgMCBvYmoNPDwgL04gMyAvQWx0ZXJuYXRlIC9E ZXZpY2VSR0IgL0xlbmd0aCAyNTc1IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ nJZ5VFN3Fsd/b8mekJWww2MNW4CwBpA1bGGRHQRRCEkIARJCSNgFQUQFFEVEhKqVMtZtdEZPRZ0u rmOtDtZ96tID9TDq6Di0FteOnRc4R51OZ6bT7x/v9zn3d+/v3d+9953zAKAnpaq11TALAI3WoM9K jMUWFRRipAkAAwogAhEAMnmtLi07IQfgksZLsFrcCfyLnl4HkGm9IkzKwDDw/4kt1+kNAEAZOAco lLVynDtxrqo36Ez2GZx5pZUmhlET6/EEcbY0sWqeved85jnaxAqNVoGzKWedQqMw8WmcV9cZlTgj qTh31amV9ThfxdmlyqhR4/zcFKtRymoBQOkmu0EpL8fZD2e6PidLgvMCAMh01Ttc+g4blA0G06Uk 1bpGvVpVbsDc5R6YKDRUjCUp66uUBoMwQyavlOkVmKRao5NpGwGYv/OcOKbaYniRg0WhwcFCfx/R O4X6r5u/UKbeztOTzLmeQfwLb20/51c9CoB4Fq/N+re20i0AjK8EwPLmW5vL+wAw8b4dvvjOffim eSk3GHRhvr719fU+aqXcx1TQN/qfDr9A77zPx3Tcm/JgccoymbHKgJnqJq+uqjbqsVqdTK7EhD8d 4l8d+PN5eGcpy5R6pRaPyMOnTK1V4e3WKtQGdbUWU2v/UxN/ZdhPND/XuLhjrwGv2AewLvIA8rcL AOXSAFK0Dd+B3vQtlZIHMvA13+He/NzPCfr3U+E+06NWrZqLk2TlYHKjvm5+z/RZAgKgAibgAStg D5yBOxACfxACwkE0iAfJIB3kgAKwFMhBOdAAPagHLaAddIEesB5sAsNgOxgDu8F+cBCMg4/BCfBH cB58Ca6BW2ASTIOHYAY8Ba8gCCJBDIgLWUEOkCvkBflDYigSiodSoSyoACqBVJAWMkIt0AqoB+qH hqEd0G7o99BR6AR0DroEfQVNQQ+g76CXMALTYR5sB7vBvrAYjoFT4Bx4CayCa+AmuBNeBw/Bo/A+ +DB8Aj4PX4Mn4YfwLAIQGsJHHBEhIkYkSDpSiJQheqQV6UYGkVFkP3IMOYtcQSaRR8gLlIhyUQwV ouFoEpqLytEatBXtRYfRXehh9DR6BZ1CZ9DXBAbBluBFCCNICYsIKkI9oYswSNhJ+IhwhnCNME14 SiQS+UQBMYSYRCwgVhCbib3ErcQDxOPES8S7xFkSiWRF8iJFkNJJMpKB1EXaQtpH+ox0mTRNek6m kR3I/uQEciFZS+4gD5L3kD8lXybfI7+isCiulDBKOkVBaaT0UcYoxygXKdOUV1Q2VUCNoOZQK6jt 1CHqfuoZ6m3qExqN5kQLpWXS1LTltCHa72if06ZoL+gcuiddQi+iG+nr6B/Sj9O/oj9hMBhujGhG IcPAWMfYzTjF+Jrx3Ixr5mMmNVOYtZmNmB02u2z2mElhujJjmEuZTcxB5iHmReYjFoXlxpKwZKxW 1gjrKOsGa5bNZYvY6WwNu5e9h32OfZ9D4rhx4jkKTifnA84pzl0uwnXmSrhy7gruGPcMd5pH5Al4 Ul4Fr4f3W94Eb8acYx5onmfeYD5i/on5JB/hu/Gl/Cp+H/8g/zr/pYWdRYyF0mKNxX6LyxbPLG0s oy2Vlt2WByyvWb60wqzirSqtNliNW92xRq09rTOt6623WZ+xfmTDswm3kdt02xy0uWkL23raZtk2 235ge8F21s7eLtFOZ7fF7pTdI3u+fbR9hf2A/af2Dxy4DpEOaocBh88c/oqZYzFYFTaEncZmHG0d kxyNjjscJxxfOQmccp06nA443XGmOoudy5wHnE86z7g4uKS5tLjsdbnpSnEVu5a7bnY96/rMTeCW 77bKbdztvsBSIBU0CfYKbrsz3KPca9xH3a96ED3EHpUeWz2+9IQ9gzzLPUc8L3rBXsFeaq+tXpe8 Cd6h3lrvUe8bQrowRlgn3Cuc8uH7pPp0+Iz7PPZ18S303eB71ve1X5Bfld+Y3y0RR5Qs6hAdE33n 7+kv9x/xvxrACEgIaAs4EvBtoFegMnBb4J+DuEFpQauCTgb9IzgkWB+8P/hBiEtISch7ITfEPHGG uFf8eSghNDa0LfTj0BdhwWGGsINhfw8XhleG7wm/v0CwQLlgbMHdCKcIWcSOiMlILLIk8v3IySjH KFnUaNQ30c7Riuid0fdiPGIqYvbFPI71i9XHfhT7TBImWSY5HofEJcZ1x03Ec+Jz44fjv05wSlAl 7E2YSQxKbE48nkRISknakHRDaieVS3dLZ5JDkpcln06hp2SnDKd8k+qZqk89lganJadtTLu90HWh duF4OkiXpm9Mv5MhyKjJ+EMmMTMjcyTzL1mirJass9nc7OLsPdlPc2Jz+nJu5brnGnNP5jHzivJ2 5z3Lj8vvz59c5Lto2aLzBdYF6oIjhaTCvMKdhbOL4xdvWjxdFFTUVXR9iWBJw5JzS62XVi39pJhZ LCs+VEIoyS/ZU/KDLF02KpstlZa+Vzojl8g3yx8qohUDigfKCGW/8l5ZRFl/2X1VhGqj6kF5VPlg +SO1RD2s/rYiqWJ7xbPK9MoPK3+syq86oCFrSjRHtRxtpfZ0tX11Q/UlnZeuSzdZE1azqWZGn6Lf WQvVLqk9YuDhP1MXjO7Glcapusi6kbrn9Xn1hxrYDdqGC42ejWsa7zUlNP2mGW2WN59scWxpb5la FrNsRyvUWtp6ss25rbNtenni8l3t1PbK9j91+HX0d3y/In/FsU67zuWdd1cmrtzbZdal77qxKnzV 9tXoavXqiTUBa7ased2t6P6ix69nsOeHXnnvF2tFa4fW/riubN1EX3DftvXE9dr11zdEbdjVz+5v 6r+7MW3j4QFsoHvg+03Fm84NBg5u30zdbNw8OZT6TwCkAVv+mLiZJJmQmfyaaJrVm0Kbr5wcnImc 951kndKeQJ6unx2fi5/6oGmg2KFHobaiJqKWowajdqPmpFakx6U4pammGqaLpv2nbqfgqFKoxKk3 qamqHKqPqwKrdavprFys0K1ErbiuLa6hrxavi7AAsHWw6rFgsdayS7LCszizrrQltJy1E7WKtgG2 ebbwt2i34LhZuNG5SrnCuju6tbsuu6e8IbybvRW9j74KvoS+/796v/XAcMDswWfB48JfwtvDWMPU xFHEzsVLxcjGRsbDx0HHv8g9yLzJOsm5yjjKt8s2y7bMNcy1zTXNtc42zrbPN8+40DnQutE80b7S P9LB00TTxtRJ1MvVTtXR1lXW2Ndc1+DYZNjo2WzZ8dp22vvbgNwF3IrdEN2W3hzeot8p36/gNuC9 4UThzOJT4tvjY+Pr5HPk/OWE5g3mlucf56noMui86Ubp0Opb6uXrcOv77IbtEe2c7ijutO9A78zw WPDl8XLx//KM8xnzp/Q09ML1UPXe9m32+/eK+Bn4qPk4+cf6V/rn+3f8B/yY/Sn9uv5L/tz/bf// AgwA94Tz+wplbmRzdHJlYW0NZW5kb2JqDTg2IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl IC9MZW5ndGggMzMyMDggL0xlbmd0aDEgNTAzMDggPj4gDXN0cmVhbQ0KSIlcVQlUlNcV/u57/z+D 4L4NUSsDI4gyiChuaJQIgyjuK1gTGUQWl4hr1JqoMS4HXBLreo6aWA/FxFQHU40a26BH0xhj3Ncm oo3GpdVaY1J71Hn9oJvpfOefc9//3/fud++773sQALWwABr1x82a4f5+wJWFfLMJcB7JLy6Y3GVm eQIQkgPY0wsmzclvfi/YCEjsD7yxqXC8P+/z0D/R/QjH6FzIF43aNCgD6pzjuFXh5Bmz/742cRfH j4HGyZOmjPMrf8cMYNdtjtMm+2cXh82QX3K+l/7u4mnji8/kxz0CopKAeuH2Skbtjwg+LfQaNAfM dT43+NwO9jNP7YnwBCeYa5qM8Jt/P0A01uFdtMIDScRhVKIffo2XMBhr0AcnsQt1MUeOw4IHadiO aImAQjpcYmMjLmMMpuEmriEWmbgqDbmOD8Voim7mDv8zsczsp1coUrETB2SSDEMC7QzllThGXmUq 4UKsOWEucbQZN6WVqUAGre/QAK0xH++gISbgC/O0ukLIRbnMkzuIRA5KrSSrxExEd+zBecmkNQBz 7Eu19mASZ20Tl1SaKnMLv7cE47nSm1hGxrtRqdrpVPs9uBGDFzEQfn79BS5LI0nUKaa16W028m05 Hqo49Zl2kkcc+mIsVmArq3EBN/CDhEkn2Sw7iNNy375EbpmYibnsi82sXjk+xH5JlETlUi5Wy4U2 GMFvq1DG+B/hlGRKtlTKIV1mtw/2Mo1NE3PLGLRFFhm+i0OM8Uja04cRdJSeYbW0Ztgdni1khnns tVM4TR5XWfcf8FjaEtfVG2q+GWW2m5vkEoIIdMUQjMYUzMJr+BV39TCO4G/yRNWi50nrqD3XfmBW s7Yx6E3ug+g9jGuXcpd2Yx9xgVk2EDez6CoDZagUyCpZJ/vkslxWDhWppqq7OqCP66+tzrZtkrlS U7RkXA9GoZA78AarvZr5bsdRHJMmEiPxzOgC5/+ouqs0Yps6qa7qxXqV9dReErwW/HPwiSmBk13W h3WYiQ9Yhb9KU3JoIxNkunxL5m+r3+q6ur726E76JT1cZ+tleo3+XH9lTbN2WFfsvrbf3uH0B18N njaZ5i3WQuAgr9bwIgld2D/57KaJ5FdMTMM8LEQJVrJfVuM97GDen+IYzuMb/IU7AIkk5yJGn8yu WywriY3yoRySo3JMrsuP1VBRRKzqrHqpVJWuCtRiYo06pS6o27qFHqfn6wXEFr1XX7ZgWZaxOxAZ dqld7jjujHVmOHNDvnx671nbZ9nPrgYRbBb8eXBd8FDwlhlp5pB/NOLRjkyXkuVG9mAZ8QE7cS8+ w5e4WMP1oSix2fHh4mE3eLlrvaSP9CUGyBBiBDFKRhN+yZVCYr4skDdlkbwlK2RtDTYwtzJ5X/YS H8sB4rxUyXdyVx4qNrHS7OZo1VolqG7MNFX1UYPUUKJATSGK1TQ1iztUrj5S+9UF3UhH63jt11P1 Rr1TH9bn9D8sZXmtBKuHNdIqsBZZJ63T1iXriR1h++xCe4t92NHckeQY4Zjg2ODY5bjteOp0OAc7 c53znOecJiSaavUH5r0Hz/8SHCdlut3Ymq2qeC7CdbG9VEawYg41XE/SK/UZO18eaLdckRJdpCea bTpdPdZTZKT6VKJ0hJ2s87EcRnao6+qRumU1keHqjsRa78jHaopOVY7qIPZZq4m1yKYGq4tIVq9L pTqqF+lF5ndItrdIlb1FnYbbuqYaoYqneqlaz0lfqSJViiwryX6CItb9fXs2691TLZO2+py1BTe1 R30vD2QdVeOE9LNaqVdUN9lBxX0mLXFPpqJY1iJFPpFvZB9Etuty6a9qc7cCqo504TV0QkfKOR2K 7GqOEqOayGD1QI3QBx2ndCcRqsQZzBUt7dk7//kF8SpPwBrVmprmo5qclQ4Ix3rq/aPgwWrFti/Z peyzrdqLoWiPl9VxJPNs3CSysAQdcIA9uAzt1QbMMwskj7o/gPqpsE8mIEHCqJYucpvP+6KpiqIW jmXUx9T/L6j6mXIfr4mbJ6sSsVb1l+WWj8qUQ/0tJfLwMkebsNqxxz6LQeICLHdwC7v8a7zCO+db xm+GHuQ3GlstL1m7qcxTOWNTMAMpxBIcF4XXybknz/lgK4PKu85MYIZFvKP68048hiKzHqncu6Fm kSnFWLPVjEEBhpnt1N9ZZjc6Y6mdrUbacVYSNfaYHOF99EcppW5n4Ar1KFrCcZfYSUY97U9QYl2k dvYyy815NGE9olihXN6iNzAZ91m3DF2JjsGBqsKk62LeUFUYYspNhISi0Eyi8h5EmdOm9ixAS7ss JSWlV88Xe3RP7ta1S+dOSR07JLZPaBfvjWvbJrZ1THQrT1SkO6Llz1o0b/ZCuKtp40YNG9SvV7dO 7bDQWiFOh21pJfD6POk57kBMTsCK8WRkxFePPX6+8D/3Iifg5qv0n/oE3Dk1bu6feqbQM///PFP+ 5ZnyX0+p7+6BHvFet8/jDpxI87j3yeghWbRXpHmy3YF7NfaAGvvtGrsO7chITnD7wgvT3AHJcfsC 6bMKS3w5aVyuIiw01ZM6PjTei4rQMJphtAIuT3GFuHpKjaFcvuQKhZA6JBVo5knzBV7wpFUzCOho nz8vMHhIli+teWRkdrw3IKnjPLkBeHoH6sXVuCC1JkzAkRpw1oRxF1Vng1J3hbeyZPm++sjNiaud 58nzj8kKaH92dYwGcYybFnDNvRH+vyEXb5iatfT5r811ie+f3Fd9bFTHEZ/39r13F4LxYZsv25A7 H2fkL8xHbTi7kEvMXQymIf7A3LlOe4CJADcJFR8pahSMEiA5IA1pGxFEEEJtinAbnoE0ppWQUUVR 0gKtWoPy0ZaS0pY2gQhBJQjx62/23TvOBym0av+p5d/N7M7O7uzszM6+0cu83EwkNnnN3Y3RdKmP f2MxzGGqgUg8EcHCW+DChmYv1lI3xKKmsgELenkfvCd7d0v8Ye6JL/ea9/gf9C9NLI/jYPITJjWt 9R3Izw8dts5SftibaIn6feb9Bf7YwlmFPXmUaFp7cEzIO2awpKK8xzPcdmvPsOwkMzQrnVmSkklO DmeuoSnlV4Ut8s9GOJjexV5YEvVjT9P5Z8l0SiyejmH4iynQMjtwHsvMe+riCU8N+j2sb+oBj9+b uEo4f//HHw3uWZjsMQKeq8QsR0kq0CB3eLOszCwt5QBx1eFEYeNM2a6qKF/Tq5r+FR4vCNxHj8C3 C2M1lXC+z8fHu7k3RIvQMLsao3bbS4sKDlCosixmqnGW9DmSEfNZ0uVIUupxP+L4EPGXwQjTXZz6 z/aMzA0vrTGVkf9CvMSWNzT7Gxrbot5wIp70bUPLoJYtn56SJTnFFsDhphaAp2b7EXpNbVHuwL8e iPjDy+L1SDXYaObWRUWBGrM5tUDIqRC/7amZuREdynNpAUPGf0evy40Alj2KN2J64vX2b2yIz3eX Sr3WJ6wlyU215J7MmrLB7dpB7UHmDU0IGKwVqw0tbYnEkEGyCC6rRCLi90YS8cTCXqtrkd/r8ScO i6iIJlaE487x91o/2VxgRrbEsImlSk0FvxHJ5RsI0wIPfbpqoMlTIw8r7U/PMoJKIXOqA7xOxSza oOH7CfiasY/qjSAq3NepEbIWYCL6t2nPUgDjn0C7GXSbGiSB/jnAJ0A50Ax4gUVAFJgLPA00YqwJ vMhzOBBbqd31FVqoHyeP3kpFwBzwfu1DKtVWkg98Pbex3lQxlkrBF0FW4hqLscet8yzHuCI5rhV6 K6kL8plo3wvkuLZSAWg2kIv+fMyzl20GbRBHea/WJfBrYMds8J+CRmDrLNC56J8HfgaQBZ0vqkFr Mfjh4GfAN8PBDwXC0LvGOhifBRs7IM9DW+WxWDcLtIDHYs4ScUYpUHbgPXKGerQWyoN8mAT2zXt2 9sT2s02fgwjblw7bPgm2Vb1p2y1QM7BETJVntT65153qCVohdluXwfuNPAozXGdoHPb3ERDUOmiM a6z1V9g4Wz9EVWi7gdESPOdO2iiuUAiyMuMVxE0HzVQnQ1BlXVe/SWONAD2E/cLfNAG2xzj2EAvj Ma5Z6nfQOO085YMPMdxEf075Cb7B2TeA1sHvF91kfYw56hiY5zBwFPqjsH4l+4DPXWkd6MbYC5A9 BaxEjIwBRkG+WcYwdFgf6zzAa9jnQB4ZgwDHHjDFQfJ8HNzrQPp/n8RIYBQwDeB1XwF+CjwMfIfH YN6RGD8OdjzDMcOxyfHBsSHjH/EkY5bPcSV8wzFm58z31cfoeSAPKMeDfmMSpRgr84XPkW3mXOC5 ObY4ZhwKebEd98ol3ifHVBr16+VybZmDHFtptIRjn6kIyT2UqH1UzTFr+9qh0oYw5yPnhEMdezg/ ZY6Aik7KZd/xuTvU8UWK7qYAZHP1d+khbTItEMcQ/+3gHwGdBv/skjl4Sfsu/UndQKqrj8pxlpy7 r2bQ7QxXv7Ic8/XBl8XaCXpV0n61SOtXdL3buqB3q8/YcPh0mgmlz5YxZaTL/t3+/wTqab2bHgP/ N73fsrR+ehl7JdfflUmA16HoPwB0AaXuMmW7u1Ppdc0nD+LmCvCkFsK3X4imaX10vzZC5l0A/fMx d6XWSbXQE/jKeUHMpz1GN31B9OMcsZZ6mp5l8PygK1JxlBlzt8aSpE683oZyDmQ5VOZU0Pq9zKug 9QeZk0FrwKYU5NrA97OsDyTv5uFOvKbi8jUqFlfT4jMjTtPisxZ6nsy4TKPDmCZrS5aTp9AZybWG 9y/vx1aZT/Keg+yAMz6TpvT3Ua+6z3pf3sMnqM3Ja2AyEID8Z8l7BPcwzptr5lar3XjKahdzrHbs 88fGJtDL1kF1gtWTqqkBmpK8y/KdWsp+0k9QYaqOBmhe8j4LcD3V9qKG23U0V9bPv9Bo/bK826ZI ezkPOQcrce9NQB3/h3Vdy6EnxAtEAnnJ/YiRRpZpbhoh/og7dw6tErus34ht8g4KiwGKiTLkMHTh s9G6SoX6LGqADsn5eAwo97H9hob45LugHm2clXMv89kb1ykLmKBfxH3UijH75F4D8h7fTuPZD1J3 NeoK5nKVUY6mUllyTEDqPI73gvQH7sA0XyRr80ye02iSMZstdaZa1905FGTor1M11g/Iteqpxh2k Yr3VuijfFTn0sDhOk0Q93Qc+X8b9JtSoEtTLetRHQHwIDCA2PXZb1mpJrWuy3q+T9XyoXkkL5HuC ZQaNM0poIkPzQxanCvE65nkScXUd/BuWJd8Hv6PhvDb6I8n3Cb8TVJkvv4be21TBOcY2yHrD9uxA vJ2i+7gmuvbAh0M4BxUF/i5M1sEctFXQb6XhpWRfoU0Vn/outUpZC51Vj6j71SNWJ78DxXv0VfE9 nN9+8ok21O9jqI21qOFz4KtfUVScBF+E/l3AGrz9VlG2lk0d4hzGTYFsBfROYI49kDM2QucD0Ddo hniHlok+vA/O8RuBfNpq0EeBWVSn/JA61WvUaVSjJtdar8n5GausL0vsQd08l9RNQtrq4HY2r8Xb 7jb2SlvT7WQbb2Mfz8HzSj2M0TTKJrI+AAI2HWhUt1I3sFt9D2O/RGuVvXjm76SIch7YmcSPqF7S HqAROValPA1M1KroLWA9+HLQI8B+u007gPeBDZj7KOhBA58KDPVBxDMo+nYB24FfOLJ08Fq360+H XkCD229SF0O5Yn3GyByvradqrFetzSBiiAv0EsNYR22uNdQmcD9o4zBnRhvrTNHepOV3sudOUE7R JOlDG6G72ePdgnOX6/N/a767Bc53HfCotOEi7mM7hoYpp6kItBW0VaymbzDQrkA75vhTuYJYY+yl b8v+1PnZ/YgVElyzM/oz25nneqe2ehBv3TQ4cZCKh5fpOYZ2P8YDmW332/QcwzgG2bFb29oP7oA2 vFF2SJtIxlhG25hHjzPU8bA1X+psYaTap/CtAfBYqZ9FWxkydwH1EC1jpORVtJmR5tdq9ivWlHLn fJxzyTwf2BfSTgJteM+epEmgzaAPODQV38n7YlDMN9rxnmrzXXI+Y8zNnLiZG8iVz5vz/wnInXeA 48DP/9drKbgf+I7wAPKNWkthowpvz1bC5+pnvyS6kQeai7qAzLtxFvxvwS8CysC/hb7toM+DYpob A+i3UEf+yXrVBkV1neFz7ln2g+WyK0WCIt5dLquLrAHXtvixce/CooVlAlGrLM1k+ZCYMTqs1Zpp CkGnNY1NUmi1mmgjJA20E6Dcvat2UVuZdNpOOp1Kf7XTcRRb//VHSdLaSYvS55xd/JiSaTKT3Xme 55z3fc/7nnvu2bvnYivdPWtaivM7IS8ByHE3nh575zbwXDrHnUuE/OdPGRxMj599BdgMH3bh7DkA u3f2p0AYY+bzfA/9/dBfor8lnWsW7Ts3gW8DEeBUWme/A3C/DTX+yM8jC7yHfqb6ce8fn1Qz7xmB ef2fd4hPoxs/kT70zjF///+fzr9LLKBiHTLzNz8wn497x3lIsX9s6S8hE3OT7GayttavpaDljwo1 vGV+4TCWLvP/nN2URslKosBwwygoEp7rRnV1pvHFdelGctVq/41QNrtO/g5I7Dq7QbzpUUnvo/6Z kAwDZS8QB6VEIYM4yeqARDT252TpCv/AFfY7+H/L3iO7xLD3DHmRHwl/w35G8nDivcDOZzznk7mL /CR0AItAySR4CpgGZgAT6WI/Jr1AHzAO4AgGVoAKoJFb2AgbwTyHMN4BrgC6gD7ARLazd2B/ljP7 CdtDSjD2FXaCLIa+zI4LfRu6FPoW7Muhb6LPdSDTPwPl/tMZ++voF0Bfy+gp2IugJ9Hn+oNM/xD+ FPi4gxkdZAeM5YoztBx+F1AJMLROoHUCS3eC/1uDKfsm2ysqJaB+6L60Yrl6DLcq7lFP8pEl/kEs aQ+Wvgcr14OV6yEmuLrnY7rTMatZN2K6EdONmG6sSiU7gHoH+PYBOwEXwLDuB7Du3K6DJ4EpYf8W uB8Y5D32HNaxDLM6xvYYXgWbbHdyveYPXmJPY6k19nRySbG/737Pls03IjQ3ow4e2ym8nUlbDrd2 JpcWpxVRz4ZyWQf5BiCRfHAp8HkgDJhYh1FaoVxkj5N9VqLlKr1SL+s19WaZKsM07wrzkyY8WxWS x1aTAALKlFiAVrXa4rbDNua0uWyVNs3WZMvqYr2sjzGFVbAga2QxlpWamzQsG9ZCtC3mDWv77YN2 3T5pn7Jn6eZJ85R52jxjznKZK82aucncao6bD5v7zYNmW7+53yK12uP2w3bmtLvslXbN3mTPUix0 MHSUtfN/DbATiAP9gAlrHIPdxZ4CYrgbMSzFU/wMCiboOYEptKehWeg5EOdAnANWB6wOWAmYe5qA ViCe8ZrveebH8PgZ7gH4cSUX1lys7TR4hreAevRk9GT0ZERNSbOYoRPsApoAJmzTAHYNeN5XmfG3 AmbhnxEx8z6Nj5VmtbaVk2VUL6ODZbS/jGqBYMivlYDy8vJiaswT88aGTF1ql6fL2zVkalQbPY3e xiFTUA16gt7gkKlCrfBUeCuGTIqqeBSvMmTqaxhvuNJwtcEUa+hq6G1gVbh1SaO80i+0xMP1vLFk qb/KEXoM74aUxMADwA2AEQdYASqAINAFZEnjwjoG6xisY6QRiAFZGDXGHzFgJePj9gHh4y3ulx7y M1z8qLFhbWOoAY/dGDAAMOQehX9URKdb48Kug6eFvTETPyjsPEoB5sfxh2CLeNy14GfYQoJADIgD WeQq20luAMgOVoA4MA6YWAu+O9lOaQzfUWmU+TR5zWKFFBTgSJO3yOoMOaUc7AUZx2DOrwk+Jjgo uFTLrZdv18u/qJdfrJdXoiF5SQiOE4Ldmj0knwvJjSG5LCQj2yPETWRpsWAzZ/o3wY8L9mn5bvkj t/yhW37fLb/hlve75cfcfNwy/IZlKV+wnTM9Kbhe8ArNrsi/VuSdilylyCGZnqWoTqoFLxdcxJl+ cM4RdhDbJfoBCSMTNQJlSkoiQuicEQhB7hqBLZA7RuAs5N9G4LhymX5ExV8bvW2U3lJCi+k/aJ2J 9z/M6Pu0joxAZ6C7ocMkQD3Qt43AER7/I4w/jf5bpMTK498kTWLcAK0T9jcy435o+NpR9Yzh+zqq niY+UfWU4bsF63HDdwzyfcO3F9JnePgE9xiBVUpoEd1NSiUe20E8Ep9JQ6bil5B5L3RLenCt4eOj wrxAitYY6hrISj7Ly1QlTaKcYqjiIouJKlIsI6qYdBHxCM2lDjF5mZQItRrqEWQxn/PcUv4VuMQv nPyTOoyzyl8v4/p2oPsXWmeMKH+Y4MtlKFd9Keq5oPxevaT8qjRFdxjKpC9lheOKLyXR80oCi6wj VqIXlHHfbmVMFd4hFV7c6oHAauWM2qK87kHfUI74LvNpkH244h1wR32blIbAiLLZk6JwawEU07KV DepXlfUwr0vRuuSIsqY0xadSiRwjF5RVqLhCFVP5ctVF6QvEQr+m+SwHLe2WHZYnLBstay2rLS5L sWWZJd+aZ3Vac6051myr1Wq2mqySlVjzU3PTGo71lOSbnVzMJs4m0XZKnEH86S9Rq4Tfjv45FpEi 26qpnhchke3VelV5JGWZ26qvK4/o1qavNCco/W4UPV16KUXJ9mZsUG46WqTn1TRPEEorjr5axLX7 6KvRKI3okx0k0u7Sb2/DdWQ/0aJnqdWFpOBQsDCYt2nR+s3hBag1w+X3P4XlD34Ki/WTkW3N+jvF Ud3PG3PF0Yi+ZZvryeYJab/UVRuekOJcos0T9Hlpf+1WbqfPh6P3wkiJFEcYzuTxdFiSlPAwUkKT IqxBhGGbltSGEyUl6aB3aR0PwvZ5VwTtTucqRQnkauKCMGk5KRW5SqXlPAz7IZ3M8WCyHEIdIpkj h4hky3hQwuNBiM/DQxJVHgQkPFXCPXLfrXrS04kSj6jjoVFRh9L7Md50DHZBJkayIqb8s/x0Vn+K YJpsu7aro7ZTrW1VazuBVv3lQ88U6ofbXa7Ermvc4dLZitb2jme4tnXq19TOsL5LDbsSbR0LuDu4 u00NJ0hH7fbmRIfWGTbatLZatS0cTQ731kQeqnXsXq2a3gWS9fJkNbzWcGQBd4S7h3mtCK8V4bWG tWFRK7K1mkaamhNWUh2teTKtScmejd9Da5E7Wl3gjG8SP46N7sIXii6aCP627OVRPUet1mXgv2RX fXBTxxG/u6f35CfJ0tO3nuXYlmTJtYRtWZYENrJ1ApsvYRcwTWwmwsIFzMdgY2Q1BUxsSkNaTxJD OwGmYbCnpZCGtjYfAY1pQ0ohSZPpkGmaTpt/Qls3wzTRJG0dYAIW3ZM9mXT65nb3tHfv3Wr3d3t7 bKgqVhVjQ7A72ZAW1Lr5IdvTix32Kfzy/JAEar1rCfIhW8v25i9bKpUaYJRO+4APpG153QBsWkd7 fHLZ2g0dk5HJSMskTTZ3YhaO9PyztINK1yK3IqQvMhQZjYxFJiJ8Ot0JasM15y0n6XL2OYeco84x 54RTYANPdlymkTHnp04uDWjCA/C0NOfXTIOExn4OpFPsQbBACmhuOV/at7Qj5kTfhKoXQ4VehYxA LqA6oHYgHv0W+HtAfwf6D5ACHQL+Q6CfAF1kGq6Kq2qxbW9mK3b6WNKxcYGL/lBgUQbkpq1zsn3D nGxpm5ORWMAG8kK0ThXTQQGO0RTwt4E+APon0BdAPBfgAvmPp+dQ25lCKR8G8xH8GGAs5RvAPuhg 5u6BlM+HGDGAQwRgqg//L+4RTqURuAICAgIm5bUp9lqayS/nwTmJwAOsZkZK1Hqe4KvkNShWleTa BcQrMuS1SxxSKVnnVYzkAoG/BuMEcbgSiXgn3ohsPuluZDbSJs1EWmcjKAp96SGwWr9D79C7gUHq Rw/LuNcfUh49QGWK1+H96UfT+A1+J9IgG9p2lbyCZCTC9UIMLwoiSmPBAnbZMJU4gqqi+9qeMKLe UPAsugL2ZriVVwqVXCE1qqEfooUIqRQStQRVVHFflu5mZ7J6Q31NFkWzUemjWj/uz/9RH17WjF2c JxQM1wUsZpOSY1xwOZkGb/N0CEtramKK3upYrBoI93DeUFF09eq4zffQH6ti6qoY81L80V/5B2B5 LWpEK3En9aD47TiR4ljQinZ1mUVrL5NjwnJvnx3K9bq+JfvsgiKA46zyNlmCTNIFWkOwktZV+ONL K7qVyeJkZTKwpXF3YKDxgzKNptBnFJoCscpiTSHxCkIGr6bOpmJTU1Mxp1hQXeWvUeK6Yq+wwNdk jIli7QlETkCpkuHWXlq0zMWJGTJE1dLyWxaLpK5l/sL+i6jFI/waCq0m/CY4upK8caU4Whq3WosK M/gQNcqlHuw5mAzh0NXF5/tKd5cSKGGqqL050iX3yUPyqDwmT8jX5Fvyh/KnskqWV0HWP3TRsX4D nJBtM4nW7EyCtT3SbFvLluaPWqWZLGt3AQoMEVJWykazM3lpsNZjoGe11b4D0g0MoYKWJ+l3EKwE hKo/gRN7+rHDLAhEabHUBcILrQKLVIUwH6+FHuAL5wIpKC3WcChY4alwh0F6XE7BbLIYPWw2dOBt hRmffqJ9srfzueUtSZPbfXrXup9tHnyz/6fXf/lZjfPp7gNPHTuaGRqZLLFU5r4zuL9zyROdzt9/ d2vjt/eOpKNpbrtbGc1dH9nWHl9pf/5w547eb0zu2/uvg9ueaTy3YdnzPTvGu/72qz8cqS638+rF x55csXFvQ+3eWfnSmf0tZzbt/HGAFTprORcuyqN9LbWrtMMlPWG1DRCtWQQso35L/Wf1HbVCgzJ4 /RWB00JgRMSwrdJoxF3ccOH602yXZQHVbRJzMIq2sg2G9wCyjV/F9KmwNVhVtbgoDAt+bb+PNiz2 u4/m/sJsWJ9bRQb5F5ARNVDXMf1ZPTms+b6eqE6IenQCGyEPqMSXtc41AhaGTes3sgUT2dlIPoIQ vVo/grBgs6fCQ0ISWsiCYzZZSwgZPL7lyEkcuLv/VJujaNWBXJ979dajeOSPOIwf9XqbP8kdu/mn iZGzPwIbqsGGx/M21NPySoW3YAXPweJ6MMII1ZuoAgPKBL9ABU4YNnec/n8jcMIYslgtBrOElKFw 2ACBrybVJ7aMnszdurd/rNUhxwf5zd741h/knno/93YO97pbPsY7b74/OXKGWdCbOwdXt7eQFbXT ik7Sab1h4URrUn5X5kSMlAqFrsCALhuoRq1o0JlLzcNmzpzBXiildV06opNtJ8EoyHWJ1tkESzHT hnrAsLWeWYb7jaFwHooup3IeqXMQ7e3pF5VKtdtgqm2Ih5f0jObOLXCOrjEWiiaxoa52Waqr5zyL UTseJh1wMeRQlJYRfvixzeEhHrNyeZLjEJHwGpzER/A4fhcLsLGDr6JhBduEsNMSzEc1WeD5XWR0 mB3thJ99QKzH2ZePQr7tQ9eRGvloMaKCmqMibQiJNBrqEvGYOCES8RnNjn3sW/0AK/bfav3ur+ZI VEPzqfF6nlfXUPZd7tE0aYKIcmgdFRH/Tinkagx5uYIWEs5ECJgNOUgNyC6lpjLOzyW53dw4d5sT uKv4F+QdRQb3nf8wj+4Z5tBINPIsn08NtX4fxi5MmnLmNfhj/oUvHudfgW+hVY/ucFf4bUhC5Wjq wqaCMrhtXeB5MxOFhUUZrKMGsQh5qIdQT9Iz7rntUXj0TK3tQn1oCI2icTjvZPcULgHXzkcTNlai /25rdh5mS/fS1bjcVe4sJwLBHCaC0l1sf8xeYucEo0fnVntsslUmgkOh70alQlE3NmmhZ9FArxyX dWN7ATCDZO5GsgpYvhZlzJsnr/egMWhgCcxq0ZsIeLjCs1Cy5lNdWM9yWR5CZNVzAxuSJwdf+t57 3dcP7rrRUt8fHiip9pfXVzY0h1YEyak7+OvrYmM3cxOf5C6/+I/f3MvdOf/ipj0/x/V3Xkr5HY3t uZMQo8/g2BLAYxZ0nJqoLWkbt922KZCN2si30GFEtDEj3o5jcJ6PIyec7KxfAH0XBPg+0uHtyAIa hP9N4barIyLBvFigIRyawvdg+kpq0Gp1VB/y64Z0R3TjOoVOtk6Rcjw971xfpFXKTudPgmhEzzZM Pfo8+xB/7vPls0p/wuiu05ssFqvZEWoi/2W6WoObuM7ofndfWkkrrbS2pJUtWWtZki3hB0hyMHXx 5REImAQ6NOHp2nEy4GASsBtoMDAWDozDK3ZToKSkIMIjAcIU6uIIwyRtJzShw5T+aIfQx6BSN43T cZsfdFISbPqtLEI0o7t37s7szD3fOec7X9IAwLj/5zBfV+tXjpOWqS6zGPKGZnIfHv2qt3Oqn4RC xDe5i/xlXzTgLzF4OAnveAbv6Ic5tEf0WOrcnuJvJzwUF81Y7H6Xq0KsF+eJp0SBBlZwy00r3Ms9 7aYXHS8637D81Pa64x3LO7ar/FX3R56b7puebOAud9ddWAg+TuOLCjWX5vZ5RMlt8Vh8CW2uttPd FxA9GiFur2bVBJnVCC943IYLqxy21TYqSbTA2pCSQMqwcWpVeG+fBkYjJdoQG0fg9g4AsfozsBcz jHB7odqsrlO7VU7NgEhVipfyMgEaSAXYlkA6QALaJbiLOpOB0oJmso50kz7yPrlObpH/EBPRSobg 1Yd8Hq6fYHTT4ygrxRDW6FhTR33DWEds2PCrXBmw6RLFVt+r8Fs/sH1gRKXOJqzHRFxi9STDTPRT MVibbzCCSER9Sm3tI+yZ5ntZeBoCh1949kg4pF0/dOKvNfNP3p0OrWuXzPECP/5VCGbCwVPbTm7o uPibP/SvXv3mhfHPpyqTjRi+GDX8FFZrCiy4yJjvZ39urZOMYFRvrZshPWqeY2ks5a5LUFExtYIm WhLXE9nEF2aRScAMqTvYVXW67GLZUNXVqlvBW6E/V31WOhKyzjNVZGDPQHm5wmTI8MDva6AmwyYu sLziAlcGjlzw0Vh1wpeBWQOKXFF+CdqYAkYif6eWRYgw6c8hjHUaOGcFawb68bwyVUn6K9OVpBLP LzSL3Xj3DPkHNdMEpBO/TJAEutr0d6n6vkpULW7Yyadfw5/DfrSp446xDGM2RmOJjXY2jDaNGuE0 5zC1VdX+sNnOCaV6UC/TQzon8CFbOGxG66jmKlvBb8edbom0glmqEmpaoUT2GV6i1OfzfnQb/nIK 6mQw5qq1OUfBOrlyxdLzLciN0jK8JZeSUFpBQ2VGZcW2aee3H1syc2hrav1r4//a+Uy1rnkdL7lD 0VU/DnpLYgeeCCw88ti2lkNt3Pyd+9csXL7v8OTBzee2vT074ptk4hsEy+G1Cxun+spn+M3f275w dfdJw6EDqMWLWF0zIzM3aLlLBjvzqEztLLVD1AqFItopsBIvAGe1yAxnlTnBKqNmiqlTNBWIosnE cqJgNTElMsiX4A2cRyxwhMo8CJJJEEw8Z7Vyl2AeqsEEq6hFkuwsHGF/xhI2A19QDzTkxGOHFnSj rJ21C1QEUbN9QyEd9bkK1aM8cPuJYkwuDXXVCvZPTKljnfWOOkdOIb1VMS4fVO12O/pVJ8agjk4o DDqCDj0JcXwAe3HwxNivyYYXToyXwZ1Xx38Cq1Jsz7095OhYs+FOrcj3TfwCRgeBzjrOgXOZ/zl/ N98tdPv2cHt9YpIk9SfZJwNL9Pbijfym4l6yy7ur+Bj7tpQOZoN2Jgh2xeFUC11uUwH2VdaAyhHQ saFyAd1bVMyKHo7H0yMDgYCuDqFPeFiVIqZwmyG3dR0HsCGYzhTB3AspMW3wGP6LPA4CDbYESRAF cndQIWkddOMjVApQJa0QRSsdgv0wkkNsuAlNXGky0MlRe/jrXJ8jNHq6YSu9pqoYj3Ax+UzUgX4y a+VSamnn1jmf9a/n1/v4pmUYlURd5AymCsI3klKepMjRCLCbnhhvWwbSoR1Ltn/n+5u61lUFvZHq xsc3nD+8+/nLwPELTg9GDr+SaR9MRR5ZPKU4puiJ892b/zitUiR2g4VLEfPzyEIPU86M0ugGaaP5 B7Ye6WZoJCQILGxlu7gu1w43V28qF3g2qJVrAhtoNoEJPWIwgANR2I4Ra++Ah+GNiDFglwFBpEYt qNPiZaI0Smi0JZqOZqNcVJvAF18xqqIG1BqVqv1qWhVVreJh0LiHsXE4nzRyloC2jOjh5GSMRROY oTFMKg5JTl+xv5gIjpAcDklBlL5S1MroNtyVmcOtUOwMtDKlVlyYB9HCcIOcF0ChjRUfGLYRLRwJ Z1ltHIxx6AHE6Orsge1vHWsv6//h7murt1zb/fR7r4H9f+1j15xz58TnLdn5ytbwEr4tJC9888Od z2TPnd5zeuUA+AbhsfGlY7N7F7f8bWb18YNnvgwY/F5wf5g9gfy2MGcvMtz97IBaNJ3P3M/SGG40 E/BsVJrJULlFTsu/havkY/iYZGUEESzAyFRmCc9hEvwR9bKkgGUJx8o8nZvkb6Ne5iaF24AEzsDr g2kLWDQrP0Q+ZVjyT2plOIWj3CIuzfHcZfIJY80jbUwNwzkjvmN0vpgyGpvIlb22rQ/6XCeChikZ I6aOUUuM/I7cGK9fD/vHd3fUfDfu4xeEv3yPu1JU1WJBO2O2IJt2IZs0JszEoYsOLcNxJV4Sj0bW xbtKU5aUNeVNFfWEUuFd8VOeE963QgPWX3jfDV+KXDFfsdyQXSJjBkEmXinikt3ekByyNcIeeFne YTvF2L7FTINGphHmlTfDisjK+BpmDTxHVofXRNrim2FLZOOkLfE+ro9PiSlTj6PH2VfQ5zrIHTDt cxxwHnKdDJ+NnI1nuEHTiOUz64htJDIypUKUpcg0pg6mTuFnmxirN8LlFsWdy8sCX2k8VNk3Q0J3 lpDXxr8G9wo6qsIkaZLQZEsyncwmuWTwMr5gkeFRZLi5xk3d/W7WrSWG4N95ezAi9J2cNYwO35lI 0QadIc/oKbFqf6nDxZkKQzofxMgs+lphUkG0lalyYl8r5bDR+Y3IHHNVtjLVjsoJXueJbXQ5w0o6 jKqFH45Voss9MZ9EjLNQbZ7YBs1VwXjkex7sPNp07dTxj9aeOVe34E/nf7X2qU0w+SW6cdWqVHJy 7eJFe59f2xP+P9lVA9vEdcffe3f+SmLfO8efd/b56y626xCbnJ0Q45EjbRlQQkLXhIQlI5TyMUAr SdqEQOlSykigq4JAY3wIFsRQ6RoJCCQ40NK1mtCASS1bx4Cug24qlJVI1RahAXO6d2fYqGb7/f/v ns/W6f3/7/fxXfTO5sHGze8Pd8w7sLp//vL2gYs9SzoXHb+8ZmPdD7u76pIr45O3Zh1ue23f+oWz q1YRhFlAuv4I6QknCMMiRd4Qvqr7U/BqmF5J9+g2GtebuovWmXuKu/1vGF8vLjAZB6JoulEXdgXC Lh0lSDQw6E7DpcAFlZPhesJPBHcUU1x6USLqFghqeSw6gkA/Pel0ArNLxRcOMqeAFVv9VsqahcsI 1kSVaG+UUqJt0cHojSgdhSpCBchtSsH7BajAHfmWKhnPy5JcHrurH0IPniCl0tBbU4RavZ7gRSNb VIIlT0moxGcOPA+8jGptjGTmLxSIv2FJCJqkx/FHLZSG+M5URYW1Mo/rlQ8lCSJQBNUC5Suk4dCa TTcuRff/eOB3yzece6t7x1/OHTyLZGtNT23zluaZi8te9UjoZSgeXfbZqeE33t72zoO/Tva8tgqN bZq/5PN1gwf+0N1YSqpwjDjb7dQxgj1OUHOccmehpHjNKyq2uweJQVOAoYjANaPYieFNbrcP2pH9 XSgRVvg9BHmkmND0sWb7YGsMPmZ5ix+bw4Bqeskojc+sUTN1TLskI1dck5/VqLwjwU/pFqqTYIYB vHJcb8hS4VFdHb2YRvRZah65gaLCBDLBN73K9DSR2L0A1ZMwCD4GN4gv1et1OoQwhB9DmIAKHIQU gBj6iQltMRlomqJAi7HpB+qTZzS1creVyBFtCqpb22OZXIbImlxmaoKAm/aW6MoH59VBdT478Sx5 AAyA7phuNfAAHxxSeKOFYcy4QDD56gN6O1OMOZbjeY/Lqw8QTT4spdR0ItGU1HKsTMvD0fyyvyS/ zAn5Zae2PGzXkvJzXJw0M4Xkz6uYucwsPEeoCzQzC3GDrUlYxazAK4Uu3Ev3WbYxfbjPulXo9+1j 9uE97D5hjBnD73FjwkXmAv6t94LwKXMFf8V8ib8U7jH/wve894RSE/MMj3wE8H0CAl5B8JgsBbzJ 4XHyDiMy8EY7a+Pt6wQG+7Hg8QRZbGPXspDFjMWSRecVFgk2hASf9zAAa2EvROSsjShFRsxQdofD aDQZPVl4XzEx5DfosEVhsyhxok6AQhbdUSx+xVJv+dpCWd7yr96mtZGby7WOuzhVH6l2Sy0IiRNE MeUyfZa8LOprtZS5Yn3EbsVcAI9D/Ov/j314428yhgz5aPop9ugFifAMGDRwswdSFZUVlVCGjvyF inKFiHo798+W4PTnJxsa3PIM+FkIXqlq/V7u9oKqyI9u3oHnLteFfXGDJDGuxE665cHu/gU6SaLL AqWLoRmJuT+rPBcEgL5JmFwAMTANNSuJRWCRsBX0C1vlPdz+8BA3FL7N/T18K140DawP98h7y/fI h8VfyVe4K+ErkQI6nUW3TjArKtJqU3iCSTUrf7M7k7ISKCXBLSTLlVCEBN6bfEp8StrKXYWXxWvy F5KBFqFkLseUXc9zNsEhOiL2RFn50+Lc5ELY5F4U3oVYDHC6AS4S29Jr073pwbSRS3Dl9YDCBk4U Iu44rUeU4BTq5H5xr3hVNvjTSro+vRQtpdp0bfo2Q1uiS9/JdfJrhZfEzvD6yGb9Fn6LMCD3pi/E r8W/Eu+L7mYj4+NNgSD28Y5ASBYBRZeCVMwnUsHotFKZKgtGUimTIxpxOh2oLKI2ynaiFtWuT6e0 VKOm3hPVM5Pq5YknZ2lZsZH1eYs9sEBIeJCngY75ppVOVb/AT6esCtEwCJBwg6ZodbHAzCYBDf00 JMLo0mhpEDMHqtLvwksgAJZAF4Gu2PyJTO14jpz51vYnm8bAVGrKbV5L483EImbU5usY13qnIw/4 ZLCqWCdQr8I9m5ecsZgG+TPjyVDEJUADx7t5pNeXiISI5JKIq0SGccNUGYaEEplKwqkyFeajMkzo ymQgeYMyEMqplEx0F7GlmcfIIO9OiVmCHR0doKP9v4QOCEXAPHXrQ4GUXF5ZkWIJTRNfGlC9KlmX HCo/5PncwD7UrCpzGKjhN2ct6b3+Ra5XbpCc3nCtjOb+cumuA6/kNkiLq3bsnP/h6RfqX2ofOdv4 4cCMJh6dFGpafrJsrEGqCHVQa14NlEou8VT38oOMwVC9qbb7iOPBi/yhdXU7nqN1qpKd+83nOoZg owgeKDUmIQ7jKE7FfbuYPcIh5pB1lDllLTQK5OmJgdhgX+d4k9rm2E/t4oaoM5SpiLLQyDubaqZ0 cSNmRZ6IVt0I4iE8DbLUM6P+vbqIh4JZdH2EjR3DEGepmSMD5l+YkTlLxZWozYSGAISwHA8dZaGP rWYRyymkuUwZvwsyLp8LueZILyzN03lH7TixEnc72onyaieQk2ufaJ24WT1+Z4LAiCrGzmt19dt5 fZFB4koKSxySnjdNAUV2Eoxu3RRY4DRPUQkcPk7fHcRBFIe03UZ2m1Xd/Eqnng75VZVlFVU6V0tW SV/y+WbcPNh3bWPX+O7NF3p8yye/PjN5dGzbKKx+b+fAE1bexhXqVk/KH41unfzkenbyH9vbj9hG jtw//e+L8Lkzsx3FfIKwUYiwUQ9BHAdp7I+U7xfyhd4t+Gf4j1jXhbtsfXh38R77ef689xNsdLFW m1egDHbYx/ULKGLU+3hA1LuPNwdCzoDbF7FYzMgdcTiA0ZOps8K8WEpYFavOOiekHiuuOkVsrz8E 14YGQzdCVCjgJOr/QHBJflMztblMLRFJHbG76v7+79hUPTomHk5g7FiylQiMpxFydhK8rK8R8sXu xkc7qfow0vWt7fK3m9tPW+3YoA+EyQYCgmWkt0Nyo+jwqF0cIXT/nQ+GPph8+T+EVw1sE+cZvu87 23dn+y5nJ7HPOSfnO+fsS/x3iX+AxJALIYSVrfHaQEs7DxihpWuqOvyVNqqSSdtYGRNIK9XY1Ayt ZdK2dKPQMo92IdqmTtPajYkOVq0SmcQmEGWllJZNYGfvnUkDlarJcb7v7mxL3/O+z/M+z9/H115A ndU/XXlgm7pI3kaOjIfi6p7q9OnqP6ff/koQrUR+FEArms1+bQe9fgXQSxPvG2uM7MPBJ4I/0H8i TOmv6bNZem2g5ChR4/Q4M+GYoPbR+ximVRKbZUWVxJgcpmWOkxiRpmSMJYdIBXkRozDYgeY0cTiW JBJ8AifK+LSxKh6PQS8cbhYvBIPNNDNF046pHmqcwgTFU4MUSe1MTsVjUiIFXxhpmgqJhnhOJMV7 C9kSRAgyS/CK2jqZmf0V2m2ZLjAo0LrFy9eK5ytgYC7neQvr92BWwlK1hiYoFXzM9KT85fcI/iNU W8w6gH4UkUc2uzDtCUei0KyypwE0w+xVuEfWVGUBebOfYYemUPv2aMahqhznvWdN9QyvLf7Xti36 sl5tx41Luh4L+Ztah3RbY120Md2pbbbjyoVwcntV2xQMa9XeB6L+UGrZ09Up1c8bm8jRr7VoavXs o4XGOqiEDJWQoBIJRLyspcqoxVikDucYG+M8kiK/FzsReyP2Dnk6dtF20XnDdsPJlOwlxzjUZsI+ 4dgHtaEpJ9OOKdntLqOIwdIi1SyJfllxQHHMO2120cFZM6lFEiNyOBbXnLTbBmYRhd0s608Q4Qih 8RrWzIqp0WgE+/x0NKZNEW2IaNMhKpQgIex3OCQKDVLopBU5XjWcBKe0NE8mb2PANctRflwctZIC FOTfxU/qYUUFKylAs1sVqcyvUBeQDphHyGPWASqTxOGwB7w+KEa68Talny8KPEcvXF8zyKoqivav uM46Q3G9o3JCH4oIrFOCSpMfsOGm/s1fhUpcWv14NTt4l1pd+7Ac8Aqq2hF6ihyp7atn1q/TTD6s Av3+Keh3BlLAkNO2MokD0SYN8wIfwKGckduQ20WXhFJgV/t+YX/giHAk4Eqkdrp2u0ghl2wq5Eq5 vbaXbLM5m5v8pmsmR66iAW3hQ8Vr1iKcsRT9mKXo6Bj4pdVGrOP7cb8gKA4tTnKawqCYBEnXU/Du 9+I676AXmxo07p3z2rzeMv6PwTvzhQiqi0gRHPlcdnjPvJZXPk5ZqFfy560wYqLNz0v5Le3JhGIU T6tatC3aHiUdbhjRdbKnG4Uk3kPFnAmCDcM/PsR1E0zUkUAulUvcimemHTVHck3jYxaBzKFsKj1U I2Qay5rUe8xBm5UbQZwcjR6Y0JbuA6sgyPms2LbIdhHKN/TkdLWye/S5DydW7+2Veu/BbODu5oZt s89Un3jz4NqHjh74411PPr64vl4kYQYMHfrijrdeev831ZkDERV966EeORLJqI9VNy7ruvnr68de /O0j9wltjeE0VNCcB88Dj/qJ3xujpYFDA6cGZgds9QOTQSNXgC2GUrhkRZHEoKxkJDEpK/2SuExW sCQ65XC9JIpyGPQtIYezkrhUDsNPhltbxWVLl7pcTpxMJIJBkfbWK9hQ0DkFhRRdKSmHlFPKrOJQ yjhkNPEDGwZmBsjQABroV5VsIbMhgzOTKze+K8S+wF/balKEH91qsaSSX/D68KpxZN4A1QIl2PaF nrdgBVw/TQr5s2ly6yvoMN4J/IjpOl5hKRUQJK7rldf1eyOByh7rUUfltVvUgSe4v0OPgWU4i76+ pUYYP987fPPAAnvQ89VNt3Hp0ds+ZnIpDXF2F1RCIsaMomxo2YC80TOcoyURy4ogiV5ZCUgiksOM JHrksNcDUkQLAYUp0RP0LE3O0UinC/QGmlxPz9CnaJLeGCrJE/KsTOpyQd4gkzPyKRmbsN4NWAIN RkctcC3RqQEYi6mfgcg8hnjXpw4NcFhgqHcohLm/+ay1t+bm3D9ID5wtTBw1uvu9aH39+gY87C/5 v+H+Wd2MavcKSFcNFTfRteM2Wwf1CUHeF8AI6w1GAy40oIYy6TTUgMYyzUGFYXTaoPfRP6R/QdtP 0ufoOThyk3oOjN5sq1rGHcfk2R+Zvv180RRXMBrmUS9fLo725C0v/onJ4JtEp7vJHexGLqfoCnQT ILF5i7pbwTuP1i9AAPxULHrOk3MepjctJIS+F7d/eSQgx0PpqL9VTFnA2KMWGpVHDk5/p5jvCEjt D+aWD5GTNXCQmQHtfwNs+rBhfDDGTXN4hEDjxA48xu3Un8w+lTvpPMHSjxHIa+tPQkPk8Bq8GU/g Z4z9+KBxjH2FO5E+0fdX9mwn63UhksMObO/8NrG7c5KYQoe4v3TSLnC5BLa7JaaFbSdUlGJ6mEFm L/FG5h3iaqaOcQVcOsritLHcKPT/GL2ADxvH8XHnkeVvEe8Sp9Db+Ax5ibiErqCPnFfcV1nBl/Zl Mp16ZggdJJ5ln+s8kGEcLCU6TO2WlZQkarKS710q5u02m2ivs7RcksSoHO7OdIndiCAUjm0A89hL EGX8B2NIzzToeoZAbKbX3q8TvRlbF4uw2+VkKIorcSc5zEUoG0X5fIEpId/drWnRpV1dbW2Rqajg 9zsc9ii20/nv2jhdT9km7KhkR/YyXmy4DbbA4gkWHWERW8b//WWqTpFaJlf0v47yVrALzAe7Sh5a ZCukO0tXeBgKPXxtW8nzC6/aBbROMQVRDv4QvHdzydjT/O9gEcxVIHgYIzMwBMzljgtQKLCpxOjW vvsNJpVO9KaWJ/psxXXFWN+X7jecOcHH9jhDDUs6y3Ozx/klBs8tQeW5C0e5JQTcOWpdzRzlzauZ l2Gp6R7Mm3VmkgA3gHw+PxDYym9R9H9FzpNbRCyyYp95j8OUg8LD6NrYz++rjHWl67PVuNXBycr0 bZRfnkzFJaFhB2pbJrZ3SuhqfNWWz/texVeqdWPrwOtFBSGSQX+urr7DNyhCTeuM4erG+hHEP6i1 /I/tso9t4rzj+PN7zsmdQ2yfzy939tn47vx2TrB9mCRgEpZjrNCUsqDCeFujDdFmaQckhPCSdJtC eQnJKso2tWm7KWOsZSCQoGSEsFJBpcHW0UnRNHW8VBp/QMtgVrWNtWsJzp7nHLKyLYmf57k4inz3 /X1/v89XjBIO8Tcu9J4hLkgRnjtNXKCgPabMIx4UpICprcTfwtvwgPKqckQ5o1SCNgr7zFnOp+q+ hp+cjkknZFTNP1t2z9MqIjKvRpWIggxkIgZ9FHLzOBTFDEdssB6P4l+b0/wi6RoVQ+ralkn4IoLe vUtZmMaOGy20I9Ax0knHiMioD+cJX2JylFjgW2d7We269+GsFXGfFSha169U+MrcznU/+V4bbGOL ++NzlC7m2zRMxKHK7B4/tizi82a2lBxf/ndyrwa8Y95ySeBEnOgMOHRXylVlM1hhHszLrpbaoU3a kO2WBuG17CXpqnQL7kgOh0RSZLmx0GDqpDpjkcT4jaSUMJhyqcwQRaYapchVPZor5qXaQK3RmGvO taEetFXqDnQZA6hf2m28igaNI+iQcSB3Ivee+K50PveBeEUayxXE29LtwPXcJ+hz8VMj/ig0iQuz a2C1uCL7rLg9cFG6YLwvvW/clG4aTuJpu6opETmoahnL7wQHODXKW8SsWl6nmIbAi6QAgoAkUaN/ ych6DUk0slIWsuSzi8FAQMR2jkPIMJI6Z3ydzMBANqMpinpAPaHSgXVdLVeHzBzkgGj47gjvGppp jbCp9PhJCz2Qlp4tEiEnnVriA+JPd76Py1SXUX9yxJ/0IP0HF8gI3ET82ELtJ2d5b2UjlBY+L0nu vMQLecRJeXF0YuyUmBcNb54mTlR6rQYyHVTLZQ97jAIdwBfm5hfeBmbh/btyfKlR1A2SRb3Oxcug F/4KN6A3u5Jk0/jS7P3zxsqo//4/bVvGt343UhWP1yidzNY1ejgZv3fNZl2OD0y9MXDv+2TCTtyc uE1I/HGUhAFz8YAAwosA2GyufRGDEMaQxGnPHM92zyv4z3gCsx5NE3gKcJpKAU5jqJ5RL9UzKghu wFgTNK8gaMRvB01X8hhU2O2A5SAn2Bmqg+kUlrndCm/wJs/wQynSkEy+sdZMgZKCA6nrKZzyeK2/ U1VDg/MaaAF97cESfpdmMZFuU2c1VY//kE7mxpJohUJfSS9Eck/e0orlG2gIpV1TtwsBIQWNKC80 o8eEb6A1Qjt6VugRfgxH4C04JVyCz0H4GANF7tWIhKNNRNszCE8cHp4uNGLyOYdJkxVIVx0h1WGG 8vR4cnKTrW0kkCdgRY+XTZeQF/xCHvM+8grkPeR3J6flyb8ZK23/OuXNY9P9oBXTXmx90fJALQyp jpqHICr63+WSoB1Zhg5mHpUeLtOiiI0/LyeaSYXQiqifVx+uL3t8nGWcDzS/12/7yvjbUxVw/JEZ HjsxjpXGtpM0Volk9KY5c1A4zB6pOMLbtkE32wd7WdsCzqEjxqeX26WGCJNlMGJ4RmEMxmTKmKYw FTHYWKuEzTAOuxt4u2LHLnvEju1NoafWPYhOhSX8JiIbOVjJySKoHMiu+LREMOFJOCvdaSSDlAYv S07+MnLiKxxpCGCyCJwvjUSbzwpKU0+regexIun4bh6pdJ1dJ5Kn5eYpYgluPpnABeBgZ7GneKd4 q7jzg3Ofjmzs37dh+Nxn/RtJ3Gkv/rF4qdgG+6ABFrz3ZlPf4eLZ4i+H90IVzIcnj+6lz4b0XFu1 Rdcz4KtnUIbc6o/m1mYzW6QuuSv0Hb0j81KI7ZZOx36lX5Ovha7GygNJPqMn8vF8sl43MmuSzyQ7 Mr2ZaRcRBEOp0OLQnwLX5LLDOvwudkW8GruSvKzfiZWHzGhY55y0GWoQkVk1SlqlT42isDKjKqw3 RpujOBplfVW63+/DHMsJKMgHjaAZ7AiWBZsykxKgDJiZExn808z5zFiGycwAzeUcSmdGYduwunbd FLQ88NCSBaTGE0z6L7K1FVZbTM8XCKlkW0i4zQulyUakCsVSYkiK64mUmJgFsRBZkoGqWRCXSR6c lGTHDtS0nHDxdNIeovU2bbpST4SJILByLareYeFGJ4m0LTRy/W8HpBWfI3fopbyc9FukTIOuxsLr ocSSmvtvkbnplcnchL+N/GH/td/O7Jxf+0S4bfDRXctnLcXPFbf0RsjcnBPpYtbT0+KTPYfGnIsq Kn7Wu2pwsYfWerG9rJvUug8l0H0z9QisYl8CptwJK8mpFbbCHtiPXuZ+47qJ7DaXib4MzAqOGbSN 4jEzy/l1nkHTj3EcpYUO1Its6AmOczDVWkPEk/Vg5OE9isfwmJ4yT5P+wBe6qWM92MA7FAd2OSIO 7GhK/j9f3CBPvdBC3NHQWODvlhxi2hNKPJSYVllRiculeCwaj+LyiE9LQ9geJJZwkSXhJpeqd3qa 3JVcSTY7F3D60xAVyEIQsoH+WAJVke9JFVrKKPMlYjHKdri25CAvgikDza6zZhKzp7UwOFC8WPyo df/ynj4YAIISsJs4qmek/YV9G0+d3dz3WP5t14lDlUrZ08NPz52/FuR3wIAfFjcUf/9Zca/t9vM/ L54onj7Z338QGv5xqLeb+ipK0ksb8ZWOauCcOdqngbA7cSF6Ic00xX6RxlJEzLTGGDvY44n4IrQK 2nF77Dl4Dm+ObFa2atvjA9CnvJI+CkfjpxNn0xMxX7myC16I7Uq+FnsDXseHYsfT59KXjY/TE2mH gPwQxIJO/DJzbmau0Rp7JltRxeFQCHwR2aVqKK7LiCRIJ8mOETmkRk08Ix6LaRi8GEPsGFYwW5V6 g+XZpew3WWY/e4DFLJKPhWpG4QemK6eHwyHscjpJXOIElbL2qlq6mWpzLVKPq7iZYAlWT/F1YNZ1 1I3VMXU1nOb3DdWuPWNliUkq4Vs6yZSrrqauzJZcmZ105SScFAr8v/ku+9gmzjuO33O+V5/tO/v8 fva9xDn7HCe+c2yH2IXkpA1KSQpBsyBJY4LES8PClhelEQxloK5tgFYqb20h+wOqbiNQWqAMMAwN 2u5FSExtt3/Q/hggdd2mjTXSsmkIkuy5C+xVWiI/z93llEhPvt/f9/OFtqyO6lajiES5+0/aA/CV ouHHdSEzyeETP8kZYcu2TTkxIalNCT0PciJcsnWNeSRRb8jNeYA8EQbsrKNQFKM20VxBVFgaXFZp mPnAX9KsUuG3YwxezlzkSgbHwuACi3kFaUZRgO3X/+dn0qoYoPmxo6Gh8YH5N+eLedktcrFkZ9F2 tk3E4M+3f/H6O++C8Mb9Q4+W8TH6o58e/055E/otFID58f/0d/upFyZqyfldr3S70CNg+sXdx3nI yXsW7mE49Hgrut6M+N5oBCxgUcaBsJiGpPHMGrAGpb3lGlhhftrS2hJ1CFh/uD/SH+0XCNyNe5CG G2VsjBlzj3nG2WFxWBrWh4191CvMpHvS8xI7mZnGpvOcz513F9zFeD5eiBchlqJNmCzKUjrdlG8D bWg7ZkQM0ZAMZVlhWXGle2VDhVnnXs+tS6/LxCUgoUJeKgotlXAlUon2NPfl+wp9xb6W3iUeB8Ok eUZIJxi5/FTaKI/6Rvl99UfJo/oxY1q/oX3Y8LPMjfJM2b+aahWQIVQ4Cz4BKNgNALiK1Bwdprs4 lYsJ8SFJEMWrcetJITLlh8Zf6vL4XS5PxtXgwZK0vREJMAdbhZZzJDQ/jZ4BplhXAEBKgmQNJExO 9173one8QPae9d7xOrw1dPKydEbMcNCZ1gvS8Sy4nv0yuwDDxny6aGY/gTcOJCtnDRhBWPYaWIGU wAoQXhR5tZoZgYNudPb+HAygudGSnlmkATtzLOyGC5R0xmPxNsL9aRbq+T5sWtZVFXAj9x+PxZZ6 g+S1JNNI55E0awUSDxfSgLfOJlceYVyNmRQH44n1pBtUH4woSicswWfsKLKXRYqA0ofCr0JGpDcx W93Pc5syWLWnCmA+IiOITfguJsyWMIMt5Q3WJrYe4E1k0UQdEYCKD4monVcWv9cRZMKbF9FFlaeS 9clksdCSb7bmacsSx7uqr3qmb2Bvpu0PP36148trTxWkj6OROKmq0e6L2ycOLimn5r93uPPue9t3 toaiihMySmbyxIbda9vyHRNbv3Fk7dQdGm8XdfDZoYMbX+pt3toofjz2WuXQr4oRSYc0j7RBWjln 08pNs9wLetHeeK84CAbRwfigSOlKu7JGOYq/JUzjPxBIFMRFOO44pY62pmCCDCcQCeVYSqmhN0ye BhnEDHnafSz8dV3IWZh1NVS7TNF1oaCUEa3x5rF+jIic2C+eEDHxKqohQfTGBXlzNZzh/jZbteaY CKchU7Re/4BhC/DsMp9zS+eWztonjphMEX6ePP/Cxo+5pRAnuJvcTatpQVLgE0nrbBP/NV4sMIbH zWNvs0mGl56vXIfwq899aJHwO/1aYRWZ5PDO+Y8q9eUlD2efUC/m8vDb+0CbdVrMwl38PDytLAhf QQxI+A16wbBIX663d7MSjBU0okx0EjtZTE2oqeZEc2p5Ynnq+ykynSql0C5jjNnFTqWup/6eJJZ6 YISgSp0kCRGlrkESgJLgJSGsJGCNhTmCqpqbbkhb7cZH05TpKlEmpAPKoFAqav89ub3IGWDYOGGc M+4amCHJdT7fbh4M8YCP6LOPa1DVrkGrIcJBbICutu4sE9kZsdhQO9buPL+Egj5JKprTW6ckFJRg 1ZRa75GbEM6bdKWbAONUOLUJ0RjVgmqwSAkQESxDQOEjI5Y/wD8biJ+wZ3wSzvV/LyZ+W+yPp73j M3A335UJrL1/6zdfGPLyZ/PoqkKlPhLvfH3g5V8+C6c7nlLVr0gjc7++de/tqRd7/or6JlararF+ dO78mlujq8Yu3kbV3XKj9d/xwVbyvqVl8J7pdbKEhPo4BQQppnQqCOyQDdsheyFfLNh7o27v5lty ovAX30NpRnFcDV0J/yh6TnlA4qciZ6LX8EvEFRL23ZPEKfJ04GQQ/y55gD3gmwoeUPBtgc2hMWyn c4+C9wbXh7qULcQ2En+O7KGec27w9ARwU+lCKo71+NcIXFYKWGtgBfKMB1eJNKlRWkAL4hChFEPZ qHyq4AgOBIQNcALrodyCRwqJglRbmDS9QZKQKZKE4e+HuYgThCWHYjAE70ISCxkCQUmCfhgCod8Z QTN4IDgTxIK/NwJmoCtwLjATwOXAxsBwYE8AC9TQP16SlTeVwf0w+KEsIrPVz6tI2CZ4+D2JL45R uIftiwwcqBYe/O8KjTZS/deXHeyQz0et4Uc7w74Sa/pKmFVxuRJF8SUS1tlLfMmp8dbT2+fZ0pNG BmkABAgSxn0CWK5NQaEQ1pgEYHEipor4+yvVYno+pc5jKS7yTBvasKE1C3qAqZeX4y68U3UruS0P v40d7PVLCVxV6Wx989cf/dbhHWuKFxnoIqgNYeEeOQG1UUKnzQhNuEkX5aRJp9MgSqTPE+ZLLvgR LFFQdAHue6w9BndzAV600EV9Fd2DddMnaSJJZKhGRnNpvBZNCw1aKtdClKIF42niq2QHs1KoEN1k N9Xj7HZ1R7uNSm4bsZnczgxEB4TB/Dg2ToyT484dzC7XrugOYSK2Q35Bfxl7jdof26vvNfblDpHH mMP84fCx6FHhiPaGfsSYpk7Tp5nT0WnhVOx0/KR+gbxAXXbWoj80fm48oB4wj+IP5FUD+hZjILeP xlqF7eKQ9M0mbAu5hRqgHR10p7RS69CxHmG9vtZwdJFdVC/jwEjECbkhFtQbYmkpR5YYmo7FKJp2 xiAJiCKFEFCPfNQvmAFe09OC5nN5BV9KTAqpUq5VKNUWhi8IjFOuLQyZfoMiZRfD1AnwfSH6D7qr Nratqwyfc+6nfa+T6884zo19bec6TmzHdmMntuPOt0269DuBtmnHMLFGaUWhLPZExUbbuetH1Fbb ghADoZZ2qPvQJtHQr6XrEAEEBQ2ksl/7gbYgBRgrkYLUVUCXhPdcR6x/sHXPe+9xHL0+z/s87/Oq qt9itdIydbepsKEm20UxlEq6UqlkmhcE+omaSsNj2unojEZhaEREslpFUbAM/Ih/JQ3HfsXIpilj C2YwIolUJpWup6fSzEh6PF1JT5gPc+nFtJj+SPyb5fNS23Wf9DbRkA//x5AMeVS+IzPya4WBGXLg aqPi75cX5luVea+ydM80zbGlv/7PJ5uhQYHJpiMNCnx2Ix55iBT/nxUPr4LSVBThLShF2pVWX6CS IJHUSFCmuKJRj63kp4uWgiXgdUgl8w8atAit8mKVGg0NNbnh7KRDGH0/tLlKmHBWOJJd73fFlk9F l99d/kPH8sGE7NowgO97s7k4lv4c1dw+m7O11dlFlI5cJoFZTOLtnshaoFIkEz7x4Bbz5U/Ps/uO tkR0XU+FwkeXBDJZe3xNxGlziDxsdfU+uxQgdw+nWqJik0619/XlA6QCDlpAxwyvYcFIsDAsF2GI IvARhB2WlhYfQwE1skwDV4aSK9yfVRiNmWDqDFtnphhykcHMJMdPYzxKKoSQVhFcY/pq8L0vAIDb 71XN3gXo1QC+7Ru+MkQRhDmIegCwgvk8PWsctAfdcJHK8kY8s/wBDi0fEPDIv89BnluWv0oYM88T RodhuWghFQuGTHkhgpHCsRHCOEpgVSFdjMk0zzWSpcHwQ7Kcxk1wdY6tc1McuchhbjIFRocgyPMd nEZBtBMjZKZa3tZIs0g7L820/FCqjUyrZSekmYVrC+S5EfL8gPvav5ZH+L3wHzetLDCnmctoDVpL dhlPSuqZXuLY0YcdWiBfL71uuWFlHDHHEXSk9xQ6K53N8u0OT0Ep1UusRd3KbeU3aBtCWwtG6XS7 aG0SNBTahLdYN0mbslv6Bwub1u6W9ksnLSesJ6TmnZ7jHhIojZdIRexFmWJPVyJzC9gvI3ll9oYl L0elvEwPwFfIKkAsQtlVkRnNDIdkVi56QdSNLik/4h33Pullkt5nvcR7NKBgRfcLqaJRJMU4O5Go J0gi2xVPzTCPGnZW6plN4ERFR702Wc5kem/h/agDRslZw9WUR3pAr+tTOmvoizqp61i/RQYBNjfg Eci7Z/B+w9+WzKcFoymvCaNCXWAUAS8KeFTAwuAjg99oWJ9qrRbbBjNATKHzAwWjQXTlfhks0L2l +bKyUC0t1ODTmD3fqKskTBb5RjGBIRrODqhhztmf68sR3iJaRcIHQ1qI8FkpryF7u1NFDmdzwKbi UHiAy6soJ2Y0nM1IDlVRcVMIlgJfVOkU0JghVn1TdzcYp2O4hqtgnKo1GBz2XCk5cBmYH0O0kV5L w0/rmVmZu6KY4UZTvl+DHwtd9YpMw5whSXmvJuVb4IJetWj4JGixUr4/SqMVohWiBaLFnEIefj2G yjrICzi0bKa/r68fpMP0Zy2uxp45g7R4wK95PNQ+97tNN2eH74DYwBYZfr6jb+34t/1d7/5j946S HiHJiJ6cvvDM9gHVYW1pVmR3cWJfuoC/Hx8ZGsttPXHQ3vrcgcH00LfGOk7vC4XihZ41mcTYVFdg fezk8u+OD7gEWzH30tB3cbnYGq/kN44jRFYerMwzN7kXkAcqY9F4WongS/wN/rrwcQDUZdBW7tMi 32QOsaeYSfZV5k1RGBZwQXR12tY5/a4hb4uM2DYPAhcYfIwIbbpF8qcDlLkV4PBljuHuyh6ga4cs K7ZR24RtysbWYZm2Mcim2DRbCm5nbXdsgg3K/61i1lbRf7nFLKwYlIqpRVBKS+VaYyatlewt+U8W PsWfmJUTbdUYSYhojF/DPqtXRa1eSVZFeAqwQQ23Sm0qaufbNESxwbFVM37sGNQDlEAZSgNAANsn NE4+Q8dFoVPvtdspJH2riOGBkz98/r0fn31z9JWxZs2rdjdhZ6L3YP7x8+f3ZrNRcv/mP/9473v1 QoG5fm6jTwlPLEWX/rSm97c/n/5ZmwsU8VE44c2gM0H83DWRxY4wZfpT3YkMCtPzbbHt5ojq3Mnu ABu7U9jTtkcV9nOHuDqqB6+1/Vq7o82hv3CWfjyMx7y71PFwxVtRD3lr6hnHC84p+5T3VXyJXA5f xb/At4XbrX8X59WPtXvYy5PNjt2Os4GzWj28GBbsGn5nZQ5pcAWg4lE7ohqRAuQqwXqQoKACVnkU rPJEcCp4MTgdnAXTPBdcDNqC+9o/bMbNtz26RWgHGbriytNg5Bz59jQjBX8fkPGI/KJM5KSCUshA FTSBptA0mkVzyEI3CHrjKd9xHxn14Qs+7JvBsuFY5DHiFV7jU7zBc/xgaPAm+Q4yoa9Vty2Ua9Wl anm+agIfi5UWFqqm2Mw7QDRyuRzOgbhTCFHNbPXXkOKl9nIRTDCnKHlM24pCSTz7U6XBTQw9v4rp zESyGWQCD/fUETeI6WrQkNmsv3/83EcYX5v8STo+4LdL4fAje9d+7uXTT2zvz+AvXv8V5j98Hze9 uC2SjLgPBfybn3j50oPBnqeBTWhoZZ7lgE0BlMA9N1ES7O7wcCZJEV8f68lUkofZw9wZtp68nJxN CkayniQo6el2x3Zxu8SdsZcEYaOAtWS/ddg6Zv0B+1r3xaQwm1yMEU1DWvBtAE8CVdpQ1Ea0L2n7 rF/XntEuoAvaG8JN4TfdUkR0dsrrHH7nkLu907NO9bcPBeBrEht3I3DtQiCO4/EAIwWQFJQ1qvAO d8VT91z2MAGYa4jnbtcoTy16tCdD41vDWX6wZ/DZBiFB5pdqZRB4+oJWC2xcoHxUTEIi5TNe+iIx VuzUI2KXhmIsLFFB13A3FzeZiBscLOcojP+luupj2yjv8L332vcV53z+9sUXf8R3jhPnHLuxUztN 4mvspMFpGrfNmg+TxmorMdCm2BbtWKWpKaUrAbRYneiWCppOg24rfxBKWhm00rLBoIyt0TaxAUIt Usf+YJEyUVVoXaK9dw6w2Xrvp99778nn93l/z+95SqqrLZeQwZGIGi+aES/GvynFGjs69P64KYx/ jRP+Tno2e+b2l7/9/ggqyYZQPTDJRp/dJddtrIWJ7oPt4/35pe/kHxrouf/222DH8K+e1yrz/ic/ 2yGY/KUb4G+ZYnLk2+++91cVtZ2oQvfCJcyKNeJphTdPO6f4AlawfgD1vFdA7C8k7YqQ9KgwMuls jPKohevRdioY06bzreGYi+Dpcct++7Rj0plvIAGkCZKmDHrbA8Qc/gxxyvAUd7Lx5/hLzsuWv+Af Gj/i7uJfQIsZ9VyKIzmqQBaoImqzc/Sb5LvGNdKgA2T9EzikVdgJBHu6kx7Ad9AjnlF8lD6Al/E5 yxy/YHmBfoGpUpfpJeYd/B/4bcNdxkqtkEggrpC4l6yQ58klUkf+QGfFInab+q4Wc9I8bTtmW7Td Qp7V5vqzDiDPuILqWjWUl2oOUhlE/jJaV/egC7gkE0m+T9mDrqTRDmbsx+zzdmi/a7XOUiBCVSg8 Qs1TtyjIUQqF/gK1RN2mCOoia9Nhc2h3q7BNMUdYhc2xEGM51svCNRaw6pvQaDPZtDu9SflISwyv l1S+L02hsIokA6fWf1mlgFDZlGxXe/iMDfVwTWiohKAJUiyRwEpTID2+TGAAx0sTmsxQP1qjfw0j 0Y/V+ZMGRU7Wo0Gp7BBMkrWgHvVLrlrmqt3bzJhaxtQyWssUlk7aOD7Je03JejS0E/1/zX/CQjjU /rHVsUk2ZpVsJJ9mMZqIj8ChQ6cmT8oe23s/ffHzf105+7v1U+CXeo4/2Ln3BL7t/UcfPfiYde5T AD78HJC/v9g1LiaU46iPjGAYPKp/BguBRqX3ae+CbSEAMzBjGORPwpMG/VkdaJeP+SpEhVykFulz 3DnTkkxzBEfi063TIVyg2GU3dboJLLvJKqQUj9+96L7mxt0mUXKAUA5JyUhri9lEUCTDIdCrYM+r 80g+VvF7l0BrqAo4pT7YAsxGE3faaASiCuCrhUJMi11dtZhK1aIY1aJiF3yxCgtU2KfZInudXWEJ lm97HRKQrJH9VA2p4VUEpyYcu1H4bOpOGTEMco3d6+Xu1DoSju2hkMYtZqnZag9ItoBkDwpYs1UU wCajqDSCoQFMVrT9HTZfHGHQGTf54x1IbWlyS2P8GuEjkWXrsIELgtS7d/2TlmAff+nS+OXSw+Nd MbejI+vxBMKK8E+4c/3CbFObKAYzB/DJwe65Nw5n5IQ77vuuxRJ96IO+QQxiPRsD8GPU37dhD2AT +N+Vx8323E8CC50Qk7k8fqT1yF4cayXCxJ6nvbrU1pH8zNbDgWJ+XjevP+F4wjkff6r3RP/80A9H nnU861wYqepe0y87lp03YjeGrudX8rfza3lXg9fWwcWtnZ68/hdUtjPlwuyw05d1YXzabOKMbL2h jqFpi8VKU0jImyUVAqshpUalDlneRell6ZoEpSo4p7DjoVkfMC/6XvZd80Hf5lItopU+dYm5kgVZ Bc1mFTSVzVmBtQqoK1ScWEiDdBVGFQOfZdp5kONneZy/iv8JIzAaDmPd6BZDkPxusLutzTj8Bowg QeBG1yQ2DCOKk4uAmch8ZDECI/FkGM6OglHJEwRB9T0bHQ2x+SAYCRaD14MrQV3wsDcfySv582gT 9HntMNUZYnl2/swAGIh67cBoL9pvIiKq4lcVy0IKpKIRmIN4DgIMchCH6j/iG2NqvIKehA9P5l8H jyEZxrwyhwzkvZAqMTVjslq+w4VK9xDdlJHMuIPO5Cq3usk865+pPJTiVsvcXTTQQ4iLEA0t3/Td 8uFTE+W7q6h5qbl0S1Jz9QybzA7N36AB1PiV1Tk6NNbVL8aFRocT6APSlmhHNBaFxPbASCAstQb2 SaMCELa5BWwoPuzF+kDKi/XoUwKWk4cFbE9o1AsyzgEBfKt5TAD7xhq7XGi5axu2M5r1gqFsvFPB 017EFL26bgHsat8tYHtbdnuxfkda0CRwzRl9c9EK5+tPK6qh45pjmlLJtKRRp8KEOXQG4pxZtUhr r5g1LTUBApsOBjGbQ1PQhN+/Kag0++LQvpvaulmzQOirPQWa0AJHTWA3BwDxvxnK46OTfzh/ovCb EAsJPTSGvpd468XMjjaPLyIU/9gzNfPIc/ffPDlUZ4qT07FQEtiyhzKx3M4D/R0bX7ZHug5dXX6p I3b2U7Cr5ccTT76l6Ana0cDoicHi7BVrIGk1eUkd1NP1xT2lg6fHtnQ6nVIffdAT9fj346eOHD03 1lc+ujjZ95/jHeNSROw9Nhiz23WoqWD1iH2/QMquE/u30p5QWuNMooBEgFEyBmYTlYRuKXE9sZKA IQLkEoVEUZ1SEsBLOVvcpio0KqYmucXdnG1iWtxc1u9rcQeqkFXC/nhzeHvMHc8Ab3MnhjW26UjU JUwmjuGdIl1hwBIDjEyRWWRuMjpGPeqSjPnEsEfOyQW5KOtm5YqML8kAkY18XV6RdXJh6wWk2Lh7 U6qDWte6qRoRn6qwI83WbUrWTJSKunYurQ2CniIkV0DQ8wIgqQayUaXVTbsESmWktFF1hIBJ5dGa a0XobnLsVkSymmAjSE2uoVkkpL+aRCoODM88vn1X0WVhmYiy0WtTtjDQk4lEH8nakgMbXT1+q9Po abC1s8Cs/9H6gaP9+x5ULm78egyZLVFsDnC7QObM/vbYyIawP+wRRQuT2Ad7aooO6YtuJOFIhEwd 1oR9rPAVERTEolgRz4trot4r5kRcUS+iygdbtsS0mOiqRTlSi35Ji0qYb4ghxCzZpvoWtxnh1Mxv 97p9GQNvsFQIQCQxrMlAWsz/ZbzsYtu2rjjOS1GiRFEiqS9SkkVSlmSZoiNbtimZkVpRsWMnsZWo cfyhDF6czVs2pFtlA/lYkqZegSLoViTahqJAM9Qehm59Geq4QecBG2AEWdACxeI9DEPeBixoGyRG 85BtGJbKu5eSE2fYgAkU79WlIED/c87//A5VdwCHjqxldVBDi8EUNctJmnYFXXHBUHUBnYWyu/vr AqgIYFaoCXVhWXgoWIXV2OrPzfggSNlEQYFsvdnsd9BxoF+wrehAtDErE2qPhtXWxIJqyPtEaFPn 5LbQSiqfT6UK+YvBTKkxOJgOO0gx1NbpBj7rZfSgkErlG9Ev5UkdKhsqTIDjb3bJQSYOddz6emMY XLFegToq2Ocf/jQEbEGgor+h5zSXugqT3VAral19z/1eZFm1yfDDomph4cmGagnZO5NyKSl2DgW9 IUcqGJYVmgysAbfhYVvC0WT4Dyyz5AVeNHl0pZoSGiOaJa3yfAhqF5ekugwYGczKy/JD2SKvptQ/ RpFa6kHEeoUy+2XhILv3G0Oflh9ByaAzQ48uFtGuWNA502yhQz2dRNg20c1EEm2M1AZEdxjZINhm BQiHUNZnRW3tECsE+v5D2061UFChhIsfLX9lOhMNhbnjUSEdeKrwFfNxSi005MffvH93TyzW6yKn ElM/wt94S42aKgOMwzCChtmaw/PGFqNLOu6xsQBeP3G8SdWddfoq8zZ31fO2tKR/QFF6UA8dY49x x6QX2Ze4l6SruOO+uCnhi47vu29ZbjH38HvMJveFx17kikJRGpCL+jCzQJ1i7N14ipUTcke3PgAG WNLPToDD7BGZiLFTYIr5lP0ba93P7ZNuOG5Qf6WsvCPAShFJ2ovvYWxOjvG6QnSEEd2SbdwyQYxb q+wR7ojXFmQiEVEaxwmWATjn8XrZoBQSg2nobMl2CneIFDK2ZCyb7C5pYnYI68acXpaNy5JPBrgs MSwkANwHAA7gPCsZjBcQSZyhWFagchjGr4EHxphAf+J0UjaoezAoUM4eepHGH9Jgg/4LjdfodRqn u3l+SQBCSNKBDr0Qi3d3Y2k2vZJeT2+krZU0WEzX03h6dkBfA2c/iP7iu2YCzcPhtYz6+kF24e9o +2gGWuQTXyygR8VCEKZQN2rZvA79r3DJnRZU98vszUv21gaDXxBaFcpuAna9eb+Ent0kSVizCwvz kERnFsCM+cLmsXlzCGG3Pjd8sJlKnRAL4DtiwPh3MjqObMSpO9HC6UxzcTQXGi7XYGKbs0zTDGD3 hYyL+qnW35HUon6bjSS9Zr9FjpBFjRQgf+CbRpzb6cSH7h2g7dEOcPnwd0r373+tvScefL4x2BHu bHwWTJcb6eGY38m45ZA/xQHWevlx7U9DHpr2RXBZxtP5O40/n492u6l4HPi9fB840dioDgggHuec fPQFy56lkTAXQ1n+HPRkBma5H7v66zq/zj/kLbw5Hwz3o9XYref7Ab/qmstWeGDwFX6Wr/F1fhl+ kaQVkTzQDhTRloz5kq6SV/QN+TGMtFEYiLvo1s/QpsFq+f46DSo0mKVrdJ1eph/SVno1sMNgm52v WHhqqRBtzJEBOuqzLrqt0flg/0ijWEyH3JIQ6uQAZ738r9LkQMR0TItxdcRsPM1atvVA8p8CQ0Zb P7lR/SJgWawCrorIQHWBehUCgKyIwhr++Hp7ThEzcGM428cUceRAO6eIPGSA6zFVEXvWLK7rsZIi DsON8XxsIlkuHREnhuxKrmzoSqcdIxMjk1Nkocua6KIpJ2kjrOTIcKZH4KkqNE+Wi0d7ZFCTV2Rc XgOaweSUtBof6MmBWm4lh+fQWaA8VYqPjUnlShlfLNfLOFZmy3gZ8bEv0F+ena6u4UdhubwirIG5 11DJqNumyz5CDHG3uRQOIgfG0HRWQDMavMpm7SDsRRaMPaGLbb5oj9OMKxHriNPRNuBm2t2JnXwB 8UIF0Ithqpp48V8go5XG5uRGkvzTwD05JnfQxzPG3Qcqc55d3+qbvOA/cXl0/3w04KKyzzUK3nyU p4hwclI7OYbj/t3DjcyY7rRGuw5ltfFdwcxoI1/sDZn2nmSAT8UfzDEdqbljZ0dHJ3ZfaJyelAMQ Rng2xlXAD2ppQ9vnVBujJqHAgjgMzzJGpCvX8B/NhuPxcH4CfPWtrmYbgLlDQ578B8ydPmA3dmuQ J+0aypoeraLNajWtrll3EcAw94vw04pmW9E2NHxFA7PwYF2zROwBRWSaaKkoYvxAu10R3QdiEUWM NdEyk0yVesTMUBsW6+0jQ104GY/FGMZN8YE4WbeDFTtg7DX7kv22nbAjtAwrfZF4SlIqyqxSU4hF pa6sKBZMYRVcQeXmgGmizPY38VL9//HSIwQtNiIRtPBtwGoTrKHt4MPYz8zDC+IlLFXwP9kSxnHn 4dNa7QOjP/vx6ItywO3M7GnkvUYfRZTKZ0473Sh8vuEM5MpW9DZvjE4WLjS+NyUFTapkDoEzL8+/ 2ojMBCIwPiNz4Mi7+0JmdHBs79Zdy29gdBgsAqaNvZ5FP/hl4MPA78HHjpuROw6b5zMK7HPsDUz5 XwNvOF5n7oRJyejVCGkQxnBJArf8H4dwQwL77WwCI/mE3ekhkIIqtP9DMK4E2ED3CjFL1Ig6sULY iAe0AR8a9BJscIPi4KigHmQfLajlTcTx6uhK5/joSuWFo9docf81idh/+Oj07zB6ax0j4FvaWh8Y GKgOTv8WC1l6MQLzWXrvsffCOz7CAq0iWNo0I5IFEU/C3YEn2jqohK2DY3wy/KchGQQccCeQcOd1 sTIIW+DN7+RlLGiFt2b/efKClQuQx8IQgsFpgzuFn7Kdo865z3nOBk4Jp9rsM1XYB9EU6WhjOT0M 3340RDpbQ2QvGh1trQExm+Xb0SzoaY2COLZx8eTp26/cPnfi5U/GtZN7ll49fvHbI5b337n0/vnH i+/+8FcX/3mmVHznwkf/5rtMY9s2zzjOl5QsiZTES5RFipJIUxR1UJJtWXZodzHTXI5z2EWGxkri 2DlabFm6+MC2BmtrdWuzZstmbwmaei7qYOuGosVizx82pUCaowXWIV2THc0ODO0+GEGCRms3ZAWK wPJeUna67cME8CUlUiTwPHz+/9+/9v7ZN++eHIZ9W/601ou9DvumIQZwmE/hXVY/DGoLtYc6QTuO 66BL7+7aqu/RD9OH9XH3MfqY/oz7J67b7k89vuaugUKp7Uibw+wCeTeWTDEs1G7+eBMLFVxTEE3u 06LIBpTJJDFHjmoH7aUGF+rKqX6CD/lbW2L4FI4O42V8DsfwDyXUxtywJPXLIzJalgEiU/K8fEm+ Ljvl4c4rW1cs6gHKHqKxqmVTNszSjfcTAOanLJG1eybliy6fW21LeBPNatHVKoG8Dy4FT7sEWoic BNl2tTl2ZoPgMZjB1ALXbvMsF3DZldZWVbIQ/I+Q5qzPV2uHXXtLTVEgJDZP9n177+hzI6/2tidb G42tNYnv0FiOUqIhFbR5/I/tPLT2ob3mQHM+jhljN47tP/LMH6ozExyZrd3eV4iqKggSLYewA6Xm kH+i9upRpXNgx6Pnfze6I8RYU7ah1utAYLciFpWb5wRSiD5MYSBr26cU0vqzqJktZ19Ons06moVm uTu9JtNHmYIp96V7MgNkv1CK9su700OZo9QB4YB8NP0ENSpMREflicyzwnczL5LPCy9Gn5dfSL+U eSX4U+E18WeZ88E3Mr/J/CVzJ3Mvk5ay4+p4cpI9w54JXMq6drKgye2H+KGt4Ec4REZjmCKkQKrE EIoaCblcDf5wGInF/FZ3FSQGpgA6DMpgDmDgw0QLxfVz6EXuGvcRh3Hr9fUT9hiPjm2vwhZDmbTo 0uaRaveS1WjGWNHIUDzJNsYbExKSZOGiBhUJaIGUVG+qZZJwlGBX12SQz7jF6hdsYUM9tiC2d3Zg 9ZbCUbIiDPalUKG31squiQRCe57b8uxvQeBNYzjRWfymdqh75OyPx7v2YnP3Hh1oFVWVIgxoW0f6 /nn1NlAlSYwv5cE5qJpvXD5/qQA9yweb9kvYryTysnkUggbZiraSJmqS33C4zDQYSoOYNSo22RxX NBgIE1FtA4ITaTogUcARKluRj/ICbwnDEBdkl6EGYMJ0mIulQRqhYf6LSaAsTUkoIlGQZS5J1yWn NJyyCB6W8T6NjC2OjtlVpKpj1UG6Th0GQn0GeWOWp3CWodTj3QofrHjI/1LxtvFjHT1tcWUXx3DZ Ztb34NpaZlMTjzt9ihDTcMBhc+++u17X2jcGUvtqW7Zp0DDiQdv5D579nFhPdoeWF9H3YHVaMI+Z 8ui8jjJMziQMPUkYoUDJuzsxQ52OO3EXnsRTw4WRQrnQQBYqQDK/Bd/3q76r/rfib6l/VG7E/6zf dNxUbsZv6wTTrQ/qX84+qU+CSXQSK3NloRwuiyeykzkfCUgUxzzeBhHX3276teIWsWCAEYMRPhXW pz3T+Ix0SjkVJ5iML6n36n2FocLjqcf14/5XlLnCLeym6E25W6LIBTQKYiAPM1kFZBaQC7kKEEw6 HYryF8JRISYASpAEVLBO8heC1skmhokrPsJBavbOGQW/QnL5dAuCONW0S3gK5rYKtskMBPNRlSHQ dxgAmGvyB/JHMiZXsIBJjJBgmBwhp0iMrIB2k9cEPhdzA7c+q4FhbUQra5ikNWuo9jrMia1A+vnW 1f5vr47dtZljaXD9wMKyDAZLRh46zMIygIdQQ6uL8Dy0OYtGFqnqCpI2GtCfcIg/cR8R8PkIGOvs MFcKIdSdu1WY1ajq3Wr92D60Z1JMpmISRTe4YjTE1oaUW4SvZVREXEmnCFYH02IYeHPPPdcn1Cf0 vaRjsASBFr5+8Ed+Fsyis9gs8UPfFDclTIWnxOmmM8ps1gudESIvAs0TXkbklXz8O/pMfEZ3DpYs v6STEm94krwBTNxA4Ra24iBuCBZE8LiRgz/p9uYxvFSU6fZL1gLNdSFs2DveiFeWby2whlLfwbx0 6xesoYfY+r2Y+r1IGEVNBj6CMXSJsf7zsUmS8DLSwCgffI7PusHHJuODz/HBa+AWou0Nyfy/D6xN CY4graxoEYynjfVZtO1FoQuW3VgRNm67v2VRFu+hU3Lia3s3PSzFhn5w9cJXPn9E5hp9siy+dGDj rv2197PZma+3by/QFOPF5mpvnzrcm12TTOU2H/zRk9NRXACbT37vIWPjvqlOY9foC42kP2SxdmD5 H+gDjstIGLlxHvEt3zLXeY0hMISi3ZFpepq/yF0MVvhbvGs2Ak4IoM/b5xvyDvn+FYKsyoW0EBbk QryAAWsJhM8CjGt2VEDYFAHWjKKgwVt06yQRvMZ9YKv+I4HwOwhRAXdMXYJSl8tH5iNoBAHA4XDG A/0sKLMAYSl2nr3EXmf/xjaww+JrJ1ZpYMnGaGrw7iAkNvjKQ7BeWrSEjqrCU4sAih1i+0ZLM/R3 2+bHMoAucApt631HwXaDRJFWiu1Q5TpA740bhaS8ltaU8obcQPr7HePZxpTjcu33m5bOldamkgcO FoYOol+Qg1/sSTwCq4VC9l3CTiMq8lezCDTLjCXNmsp5zdFGdMQ6pZ5Yj+QU3GyfxUVyX1TVFLcG 1rmi7g0SoUbcFbDRZHFEVaEQNER0vx8ncIKQJcsy/cg8ACQYAbPgGnAAK3aoDC/EGaafnWLRMlzm Wcyqj7RSIVifxJWJ/zYAKACwUrBQVuyo1qOHNez3k4c9v1RYJGmRFESEosNURETs1PH00/C9hNNn m2hrR6NTKa6WDBqCqyivFBJ+04rYQVIOxjR/7e/Zrz6xcfuoLnb0gHWl7sxjW43d2Oml92Y3i7Qy eqX8YOlkGUyvaw0DdWmm3N++DXXt6EBVWE8a1rMK6ymhnaaH2YkPhPbwGF9Z/tMCUWyyZnA/Vwzw AUHxNP2b7WqLbds6wzy6mDxHF5K6kYeybpZIipYsOZZkm4IHcWhzcdsgXrFkWAYhAdpsyVCgsbEg DRDBHobG9sNgYGu3ttiQoMCWDsPWJk5sp8ZWF/CGvKzLwxK0eWkf3G7F4s0rsiBAY3v/keIt3Sbh 8Dvn56FEUf/3f99PMnI6lFPTNK3VsU3qIVut0br2hDCKHye71d10VDsh/ER4Ff9Uey1+vucX3BvC z/Dr9HXtjfhvhat4gSyoi/RtbTm+0nNTvUfuqZ9rfecxYt8yP3C02sbCrg4mrQ7u3dtB0+xgNttB WW6j49DuqthzFlzHhOuk92z6u94X5bkeXBeqpKra8d93rWTe1/gZMqtOU/dQaJ/qCquRZJiLp5Nc iMjJ0NL2OaeINZpWKe3HJIIxiWtaDgswE/gur8cjgAKFQ6ASXJdGfeoSSjihIwRJJEfOkwXyJ+Il LRxn2SM5XeULwjXhPcEttDA9pS2jOJfmMNyvGKpidt800cbLAzUGi/4ah1ewCy+hdxakHjTV03ka sIvhghiuZhj5qARtzMTdJitd2qb6CYVkU+9q6wwn1PWO2WgnGWPgdEc9pr0ltT0pgIysI2nl0SOY kCa0bjv1sJ1zBTQB1f0qSccCDQEK8iIgzoE9WNr+CGo0AXBI2BbSUKRhtN081y6l4Uy0U0bD4bZD N7K1TLQLPA3KIsNgrh692W1a0Zu3FMHXU0WFaiTbvbVsbV2L5VPygPsl3Uhn+7e6XIHhRBCLPl33 yMk9D/7m9g6WJSywKhnYXvNegTwtunsuhUrsr+9u1GImGDFZN9OlI6UT+GTpU/3T/H39ft7PNlwO 19r7rsdT1UypZD07mKA0Fc9KJQ8xEkbRsI2DykXlonrREHz6UG7IPMA9hfbzo8Le3B5zf36/NcNP SVPy9/WZ/Iw1VXpNeolt1pela/q1/Dul6/r1/Af6B/kbpRTn9fBdUY+Cdd7E+S6rpjwmPSaPeZ/m D6lPW7O+OWlGnaWz2Rl9xpgqKdP4nDJtuAP46+i0dFr2QKbBU9J1gnjINUmRk1I6m0mmOauY5EQS TIopmkymIFXnhbyZXtpuOY6q59ICL2A+Z+UjlpWHp6yb/QKOCAIGXaDRHNEjhOjZXK5fpRFVpZaR pWBqIasJl88sozuQmkl0Zz6FRJmtJC4IqkBEUZLA6KY5FwsirghbIPXVZfRtKLoC+rkj5h242Vwu 70s/EI8RMGaXrqxwx6zsEhKcqBMvj1F0gaLf0D/SD6GW/CBXBtLEF9OijiQd6SzBff6qvowkzuCi wBu/Q8pHDOQYU4bLAGm6gltmWXgbyCOAkBFoOtBUfiPvysOlV+HS/AW+3b2OWWjKQpwlWWnLsd6y VqwbFm8d7fu3Xq3fLTTHqba+uQbOafwhYyCkQQBOq2saiBgbjEKMQBpTMmh/AEYevjvz9Y5ZA051 uBUEbgk7JBMejRT+H93+98hLwogw0qbhOGLN0wSzJc0CY6AhRfwNZnbmAcOMfQlbeQQiDDYuK7bO INpeXYp2CMlejI9dHTqajH0dMu7Q8+EaZd0ddgbQFKjK6u+qqhkbQVf2JSPCjXcjpo0yX7O23rM+ 3vqnvnU7MTwCLPUku1PFzX+gX02PKEG3rrsVKRuJbn6GPh9Mh5MuXQ+cePBX1+jmots1WglA8sQ5 zv1nYO2w+5izHdpN0FxgLjgnTxvT1Vu+W8pt83YFiyWD6L6cf4Kc8n0ywHfXS+LhQU+p4W1IDXnY aOTtan991HdAOiDvSY4aT+WfrDr1Q/SQPlY/xU/6JqVJeTI2qbzMn5fOyxfVZSMZ9IqSKIvFlJSS U0WLWEq5TqT6QXx4cKzuMYAL0GmZ1WqN+Pz+ikowz1OjWqtWanpoLlaWkVzzBwIxf6JFx5IoWdaf z05mXdm5LMpSvVSyK32fWZZZGYMf2KqhmtfL65TnczU9Uqvp/php9lf8kUrFD89axX6lYurUN1x2 eg2VuP1VviZ2o+5Uqlgul8KSaxiESJaZupQ8faivL5lMED94lKvPx1CspC+h4HyaIsoqmV+qOfQt +hHdoB4WYKpCl12DXIXj0bcu10omMHCeq6DKsutdzubqrv3zmT8AGQr3mtA1SJuFZmF8HbxbJ9ub O6oBXqV9kEaarFVtmziW7NCGTAdbndRmE6SG7FZZvSOtNWFbeY0dYDTLTYhI7aV09g7MeEEaCY5M B6WR1uoqg1VhlQcQIAopP9FsMsUZ58Yh269xPkhiYvuWtu8vYlthrQLM/zIPGAV0cLfcCDhxqaGy KCwYOmEl2PA6IV+DV+EwyGZ1pqiAVl5kn7axINp6WmS69f5l0eYZc0R7AGAhACcC7QhrMYw0GzLE ZHYdOJ+21kET0ga5o3zxgC3B75dhKNCPSJJoyzCKTtQOd2gY60CIaU+UNTAbTjhqDwpRO98fsS0Y shCzcfvDYrblyDCi9gAb8M0K+3YY7PJL8n/I/MXXf7c16AsnGPF32pkhRvUdHebDsZgSzdQGWNQ0 WTFor5kFH2J6HUdvWpmsL/blJ/f1GGhwV27XwdbaV/fZW2N9NOyc++HjfX1bN3Nx4/DKr5/4ypeg FHQr6oDUc/z4M1o0AYVA7Zm4uLV0Zpc7l4sEFaW5uvoNWTVduZw3kji9/eC5Iabh/q097rtQDQbQ c84vsQR/VbDwsuUKV0uxZwe/532xy4WxNyRQQcOFiGbgXCinGYVhNBiqxfeGjuPj5AT9pvZM/Hjx BeEMOUNPa9+Jv1CcJbP0Fe4V/GPtR4Vl7kb1464sCGqhUOztJaht3ihzfMWBh47PENJU0/p7SQQ2 FAuFttcr9MIlvRr2EKEISEEmhexD12cy7gXhbs1y1k6IVUXRKJO6+BxBH5IN4jpKTpK/EzdpNfAB fAS7cQuajKCTKPyL/WqPbeo64985916/77228fUrwfaN7cTxOwkm2HndkEBTII8WaEmHeWxEjIIg yQAxWNdoGi1aO5E/mLZVSOnWaRPrGBvpsqBtpaN0qiZ1QxNMVGqVjgXGpBpVKKBpxfa+67gj0UCa Nu3xh23/zjn33HuPz/f6fd/5vegjom/CR33Ht0ZJItoRpVFX07JT8nfxxBDpw+KtdzY7MpufwwNV diTft2qo+wZ09OZnI/ORiUFISpGoW5B2sFej9KFZ5n5mISNqmEUeXJ2VyrPS0WLB+baZ1JYyhom8 KsVi8sw7Fq2uJkLCwZBT7yq8sPzMYy3rmpNyOmTwPBLoLPxUlF1mRxO6Q93SulWFRvLX+pBVb+Sx fnPKQse9vUePdUfDTXaxfXCCTnrjfpPZhH5Qj1lhD/qBRLYqK6w61slOsBP8hHCKnWa1Ew7COw7w DcsHYJM4IDFVrENYIm5hHxdn2EuiFu6azZ2SRz3CBpRGjnvN4DGygigGGNbGMCxjpKxITIKDZ0Qq sAMc4ZK8SWPeKhIxSahB/BltBwFY2q5EGRKfwN3EB3iS5BV+mGd4d8LR4eh3MA5T3JgCSqjL7vjW PIX2zY30zs32mbN30Wpz2VkzfpFH86OtpSaNJimRJ57yEFiDP//MRScx57CwulPuVOqD0QjW2iXe E4qXFD2yHJPEhlWdjMeBqKhXAXtanC6+N2VPsyGbOrw6ZUuzw1Z1OD5lTbNOSR3enJJwKJaGPxYX kwYywiBh5BSRa1Rb+5tliciNasQzm433rtJthcvbW5dUsSENA/mXSN+utQ6zkbgKfwowYZe/cU0h eO+yP+rbCcUitAJQLbeX1sIVDGQNfPUXADWKkfS7ybPu427qRu679lpPhBDXOXoaDYzElB1JoXY/ ZCWa4vYCA2lFRI0SESevUA6DCKZJ/ifMl6mL5aapflK+/p2SmnvnyoGQ6M1l5/2Y+JfQVOHdml3c 3sL3yCC6D9wozmrdcAGM4AA/fF0Z9gWVIAVFY1KsTsXjsVo1xipFVrpSstKRmpBnZCrK/fJxHLD7 5PNyUWbkqyKWq10pSX1AmpGoKPVLx3HA7pPOS0WJka4yin4sk/JiUNN+/YyeHlcb/V8C198vV5iR fKn9pCtnVrVmzKk7DzbaJVs5xuSHjMnGhNIZj3d20nexWThQLpQu4+X7C3o0QvEWeYu1UAF1sfQc UKZOMQC4ObKTfaQHN3e9z3xX1SDuQk7JrOXj91k/eetRoNDF7GTWc7vBDjH4khIiILBOR7DKG6rR WYwhpWbKYVGMU+BggEmglcSgNzgWZLAQCStiVeZltOybouAVxgRGUOf0bOaMjdhc8cQ02T8pb3hq ntl6c3mMFGzKpNbRi1U2/uZDhJTDJI3bmy9VVfppWqCV4IOnyepN6wx6no9a69vWNHftOUo/NaQY jSZj1F7f1rti5dPPcbvr4zta/LwgtkWTq/Zv3HG6tjazub1aEMwtkYae0Y27TqseXdYCYeAiAPsK oMzDDWMNFAgNM6r/ZtWM9UtmiNxGXbmhX1mqd2E24Mx6G0zxio2pRuVwGdHhdYwhYaAqJs2uquqf kzDI8DvSBvPOnM/m7tN6WXDVM5aouVdlY3+Ndl625nlBtZpbO4Nuo0kwWt2WULs3nOnaPdjCDCXa UrUpryhq9a2xxurakQ0HtyuqNQsXmfXwNkZBAl5Q2k5WnYyfSkwn3k78OaE5LBxwfEU46mCdruo6 IKwo68Im51RYCRhhyqqYjA0d1ZmBGBFj3thYjImVTPxyHal7k82IklcawxBQ5RJdyYaFxlWFupvN Z0dzyIC5WfypUi206Ygq32LxymbkHjL/uaEOg5E32O32cGtv88rdz5PPPNlrMJh4u8OCpl7evedo 4WI4nW1DQ+p0rZFkz+iTu34YCMeGWvwCr9O1R5KrD6CxVauV2Io5gx7+6uS4kzhVanU1Ni4bdp5x fuRkfM4BJ1Ww2eYcd7Lq3ckVmWWlPpac7/3BUq8EXe5lpnqPdk0Nqfdo1vilOr7T5pG6ea0dtFqN AQhPAqbS+sszy8ZNZMBExk0fmeg207CJms46zr5SIgqVHHLIDEgPHa3W9J3cPXInEkFFlWq47Eg2 QkaJxWa3N6lFGmrIUsrTNdq6IDnibugsdHXFq/Raj7s6JBAbcybveyJdHQi4WzeS7V+L+lxiYFiV m/XQfdwu0MBqxXYYjpBR9jD3rIajDIgaorlCp0lMsbG/JSxL1IkT1KXVnfi7VXNZSzoBidyH6qDk pHhGbOKam8jZ6de9xHLdw3rI2suXMXrGin9gOS3BfLAcFa6FGZgh3wC/YiPeFiK2kImW8y20JX5I zQiZc/QHn2SE0RSUPwcXgyT/EcwOxE2Mzj2IW/fBvYi4AaBpR/wIQHsNQPcrAMN+ANPjADy+J1wF MHcDWGoBlmQAbG8ASAMLcHsxnAJAFaJ6DGDp6wDeHgDfbzDJjQME3Ii7ALVWgHonQJgFiG4CiG8G SBwCaMBnGy8BpKIAK/D/0hsAMrhmG66n7F2MTnsZbyxGN+5/dQigxwbw6K8B1g0D9OkAHkN51x8D 2IDrP4G6HqwGeIoCbEbZs+8BbD0BsH0lwKfx/3aYAXZ+H+CzKPvTuNYefGf4OYD9+MzBkwCH+v6D OPZfwAf/G3z+2oNx2D2PIz7E6jJu/mv4wr1/H8/M/XP44pYFOFlBBRVUUEEFFVRQQQUVVFBBBRVU 8H8JAsCZ4Ta0wj7ggIIZEtCJc+8Ui8DgNd4H+s2XrNu3DG4VW+/oXDpQP9/+49ILan927QfGj/fn XzRndAJe6vF59Q342wC2nWpzCmVuZHN0cmVhbQ1lbmRvYmoNODcgMCBvYmoNPDwgDS9UeXBlIC9F eHRHU3RhdGUgDS9TQSBmYWxzZSANL1NNIDAuMDIgDS9UUjIgL0RlZmF1bHQgDT4+IA1lbmRvYmoN ODggMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvQ0lERm9udFR5cGUyIA0vQmFzZUZv bnQgL0JES0FHTCtUaW1lc05ld1JvbWFuLEJvbGQgDS9Gb250RGVzY3JpcHRvciA4OSAwIFIgDS9D SURTeXN0ZW1JbmZvIDw8IC9SZWdpc3RyeSAoQWRvYmUpL09yZGVyaW5nIChJZGVudGl0eSkvU3Vw cGxlbWVudCAwID4+IA0vRFcgMTAwMCANL1cgWyAzIFsgMjUwIF0gMTYgWyAzMzMgMjUwIF0gMjAg MjYgNTAwIDI5IFsgMzMzIF0gMzYgWyA3MjIgXSAzOCAzOSA3MjIgDTQxIFsgNjEwIF0gNDQgWyAz ODkgXSA0NyBbIDY2NiA5NDMgNzIyIDc3NyBdIDUyIFsgNzc3IDcyMiA1NTYgNjY2IDcyMiBdIA01 NyBbIDcyMiBdIDY4IFsgNTAwIDU1NiA0NDMgNTU2IDQ0MyAzMzMgNTAwIDU1NiAyNzcgMzMzIF0g NzkgWyAyNzcgODMzIDU1NiA1MDAgNTU2IF0gDTg1IFsgNDQzIDM4OSAzMzMgNTU2IDUwMCA3MjIg NTAwIF0gOTIgWyA1MDAgXSBdIA0+PiANZW5kb2JqDTg5IDAgb2JqDTw8IA0vVHlwZSAvRm9udERl c2NyaXB0b3IgDS9Bc2NlbnQgODkxIA0vQ2FwSGVpZ2h0IDY1NiANL0Rlc2NlbnQgLTIxNiANL0Zs YWdzIDYgDS9Gb250QkJveCBbIC01NTggLTMwNyAyMDM0IDEwMjYgXSANL0ZvbnROYW1lIC9CREtB R0wrVGltZXNOZXdSb21hbixCb2xkIA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDE2MCANL1hIZWln aHQgMCANL0ZvbnRGaWxlMiA5MCAwIFIgDT4+IA1lbmRvYmoNOTAgMCBvYmoNPDwgL0ZpbHRlciAv RmxhdGVEZWNvZGUgL0xlbmd0aCAyMzgyNyAvTGVuZ3RoMSAzOTM0MCA+PiANc3RyZWFtDQpIiVxV CVCV1xX+zr3/fQ9REIMIrvzwAFEguKDiFh7wHgJu2DFRUUcQUFCxRBnFpS64NKI2pBqi0bQa0aYh Ux51Q61K1Eab4F6to46iEotRou3ExBh5t4dnp0n6n/lnzn//c889y3e+CwLQBisg4ZezoNjM9m1q 5JXtgJfXjKKZhf/yf1bMeiWgUmfOWTTj/q1wbyDOAMa1y8/Lzj0T9f0eYCvbYGA+L/inddgN+Dzi 77D8wuKSKiOmAPD1AzoOmfPLnGxaG3QJWNP67SjMLiny6Usbef94tjeL5uUVjX92ogUIHQV02K9+ g2A1yvN2k5vRFdB3+OX4dJM7Xb9Qs2Fzz9IN0h+gsJfvf59wrEYYmlCB45iKL4SEk17FRBgUhM4Q NBgjyQ+BUOSNSNgwEhkIQDq+JB9Uoy++ohSspHCM5UqEYgw6IRHvYAeN0A+wEpepAFW8+yOyoydG Uaq+jXHI0Af5DGAo3sP75Itg/uNNNn2LPczHr3EYV6GRiS1qB3vJwC8wVx/EFFykTJqsuyENc7EM W7ATR9FIb1GdoXQWBmA65pGV/ClSluqPEK+utdmvT+kL8GP7nez1kYgyUvTXsKPJIJ3PnfRHf5a5 +BAHcJOCaIBMhi/i+KypWIpqGckxpmId53aYllC19NWVnM0g5GA5GqiE6kSIuqae6MV4hfOL40jL UIlPcRIP2VsKjZeF7gQ9BgQvRMHJJ63GWvyJK3eC5RS1pxBKY8+f0i26I+fK++z5D2jGt3hGkVRA y0SCKFX9Wlbq/YjgDO3sIw0TMAefUATZaTLv3S4WimViuTwgbxqRxmMdr0/Cgli2LcXHnNc5XMY/ uF8pNJquimVyr1qrl3C8scjnLFZjNw7hKSlqQ+2oI5nUnwZxZkuoju6I7sImJsrpslpt0Iv0RoQw VqYij3fOwiqswUGcx108RDN14Z2xvDOBMmgjvU2nxHk5QU6RFYbdqDCqjBPGC9VBnXBfdDdw1Vv9 9MFolqmYgcVc61qWk7hOkrpSD/Y0nNLZ0zSaQUupnN6lXbSHDtBpukAP6DF9L4LEBrFZHBF/FefF Bdld9pYO+XtZb4QY140frNkt3d3H3Y91Wx2l++tyvV3f0M2eLnRjxCcgmdE1m2d5NcrxLj7gmu/D WVxh3N32SCOecA9+IAujqTNHFEo26knRnN0EmkgLqYw2USV9RneokV4IiHYilKW3GCjSxRRRKh6J F9Jb2mSiLJHvyUvyubFI9WOpUvvVE0ujNdyr/sW2lltuuAvcFe5tegBj0cLI8+eZi0MSYy6du5yL N1nmYQEWco0Wc8W3M3Kq8WccwRnUc+3P4wZueuJtlQfciW/QAjcJ7qciL5aXsffhziQzWrIoj3v7 UpZQKa2jLSzb6He0k+t7kS7RZbpN9+gp5wQRIxLFCM4oQ0wWU1mmiRyxUqwX+1jOiavihrgrnks/ 2UEGy57SKWfKt2SZdMl98u/yihFhJBqpxmzjtHGRM09VaWqaylHr1U61S51Qn6tGpS2bLB9aai1N Vm/rQGuGdbx1nfWP1iPWm1bt1ZPxNJqj74Ufn0002YgV5aRFLed9TBTLL8RmqvqJBVQZR5CLaaJW HhUfLC2Xd+UnohQwHJ7fw5nF6vEX1KvLRoBqwmnRBV8zH26W2eKY2CqCaKAcaqwx6pl1FnGcu8Rt YRXVbPGQuzENr1Nn/Nt4A4+5/udVGdc0RdyiKvGZSGckX0OlOIKt2IE8GsTR5WI/nuMdOiRNOsC4 W44LeISGH6M1YluSRIIlSCywDOEOHaJx+rTopR/y1N+hNbghnzP236AxFIs9uMddv0JxFGy4ja64 yMzXA9sYtf/EXp7Bz40wnqCnOCTjkGk0cM9jW/7mdqhiuYq+FYnczkAPc49tZWPm4C3MVa086otq RgKziGeiH+IshXIVL1uu4328jcMyAOFyt1ghtDxjmPgtGuQoPvVXzE/dKI49FYJvLcPU992V7GEW 4hFP0ykTDv6Tih66kCPfw1xk11P0VjVJReEcjaIAHGf2CuIqVqg27ma23MdzeAOptB573bmo43sl iMKpH6OpWS1Q5epjtU8dU2ctfVHCU7uNu3gX3/CtYVIO1+IrfMdYT+Lpieb5SeQoUvkOmyMmyaNI pi4oYg6MZN5O4hpkcifns5dSbOB52s13yDk8IT+agmO4xpMTyHOew+d7sZ+ReJ27Ph97mB1X0V5e yUUP9OY6PSdfihfFfF4rz1Ywz9ZxTDdxn5lDe+KKpqHk4O7l4LvWWeYTBiKDapCiDzASxsAh6/El wvh2TeIZreR9WYwNX3THYHWPBKLdY3S8KJBHqRPfhr6MqvF8sw+nNzmK9pxHCwJoLAa4R2Aw37Er kKF22+32hNeGDxs6ZHD8oAFx/fv17RP7akx0VO9ekT0jwsNsoSFmcI/u3bp26RwU2Cmgo/8rHfza +/q0a+vdxstqUYYUhGinLSXLdEVkuYwIW2pqTOu3LZsXsn+ykOUyeSnl5zYuM8tjZv7c0s6WM/7P 0v7S0v4/S/Izh2FYTLTptJmusw6bWUuZ4yayvtFhm2S6mj36aI9e7tF9WA8J4Q2mMyjfYbooy3S6 UhbklzmzHOyupq13si05zzsmGjXebVlty5or0FZUQ4GvkUcRgc4hNQJePhyUq4vN4XR1tjlaI3DJ cGd2ritj3ESno2tIyKSYaBcl59imu2BLcrWP8pgg2XOMy5LssnqOMQtas8F6sya6rmxDrR+mZ0W1 y/0P91UfFNV1xc/73MWiLBj8AIy7roCwixo/wletKLAKKAqi2bU2XRSNyhi1jLbWqiTVqE9tGjNN TMsYJ9P0A9v4NJmEdKwlk462nWH6RwcnTRrJNNrRRE3SSTqdJvL6O3ffW3ZXUm2n/acMP84999x7 37nn/u45F39b66qwqbRG+BuZAXy3xhz7zcvjhlQsnlUd3p9ozVWM2nEbvKwaxn6veaIpnGj18d9I BGtgrpwfihohfPowgtiwzIuvyfsiYVPah096eSe8q9j+1vpruSe60Wum+ef71xsboziaHMOk5h2+ Mzk5Va9a71BOrddoCft95txcf6S1Ju/0PWQ073hxfJV3fLKlJHjakxkL7OlRGXYjfWRiY23cJlpi OLcamuORldgjfx0IYXrXeOFJ2I89lfGftWVkrCnDMPxEJMwy23AiG8y06qjhqeB+nm9q+R6/1/iE wAD/jevJPa12j57v+YS4yTyJUw12p20GAmZxMVPEVY0zhY9fEvrskuD2HvlZ/xaPFwLho6WIbWuk YhrC7/PxAR/qqaLVUMzOpnBM99Lq3DNUNS0QMeUoW3odS/ZytnQ6lvj0qB9Mfon4/4ts010Q/83w jBldu77ClMb8C/PamL1hmb+haWXYW2tE7dg2tCRpMXtZ3Ga3zNHVYSVXtltyriKsIOWq+GBWwumm mo9fXZC6rcflBitFj+QNmZ7owtjfyAif7y4n9Vgf8iwhhqbZbpoVgWS9MklPci/dUOCwWiA3tKw0 jBFJthAykGGE/N6QETVae6zO1X6vx2+8itdKobGlNuqcaI/1i0O5ZuhwBJtYL1WUcLBdvsFaesBD nx4cbPbUivAnvjNG6uVSHrdkB910St1KJv7hmwIscRN9R++mZrmcDsssu2k8+r+mPk5TMH4+9BmQ K2GX0V8P7AdmAD5gJlALLLLlQmAufwM4hjWKeB0hiXa5ttIq7QJ5tBUUgGwCctEuUt+lqXo5LQMC ygQxdgzaU2ErcB2hIoybAH0pxs1iCb1A7aCNsNejPZ3XxD6yIEcBWej34fsX2WfIavVH9KRK1g20 C7D2KswNKEeoEXIJ5BL0z0f/YughzCmWu60LaNegHUBsFnG/2HsHFQKNmNMAP5vEeh00F7bR+G4m 5DQgE/ZspZCel16nZyG/rBZRutg3xoh9rxjaE+QC4dMwYB/Zv0SwT3K59RHwNvCu7VvdbWC/EkG0 RplJlZCdgJ/Xl/uw52aSYK/Q/kGVDDdZt7Cvy8AYtY0yoF+Dn03aSzSbdWCUAL8Lu+DTx9QIW0B/ iqaif5Z8Hzi2jqbKP6QyPZ/SsL+VGFsDdAjuMRfaqAXnYUGOVK9QDmyTgQKc4Sk7Th6ODXQ+X+zP +gB+XMeYJmAZc0vwq408+D7HnM8+U1oxCG5a12D7CvBV7KsSuB/2h8HhiJiD+Vi30uZhUVwCzL0E TGEfHPA5OYhxhLKBe2wUAq8De4EngC3AOh6DdYsxnnnSjjVroU9ifjA3sBafQ73NnUzwu0hwLHZn vo841gPjgAwdd8vGSIzN5vvCnBX3BXeB+cjcYs44kvkteH9SeoX3yWeeIHO1S7SMfRB7B7cSZAHz jKXSS8VCFtMU5izzzZHiTsb8L+A74ci4P7iffEdYqgHK57vKXIxL3FOORVyOpSKsuVh/Dr5/nR5Q C6leaad56kqqU0zkn0H+nnVD7acX5N9QwNUrOIM90jMpks/5mKtf2qj10suIZb7aR89A+tV+eZLa L2naSeuadlLeHYPTTpSpkHpjNpaMRNu/2/+fQL6onaR1aL+n9ePu9NNR7JVc70vTAa8j0X8G6ASK 3QHpmLtd6nEtx30i+hjYrFbhrldRqdqLnJBNVYhTPvqX698D59qpEGvfkqvoPNpvIPeVKoT7iW/J F5EvAF4fcnECj5I4NwyXhHT4OowM2FwSkvmMvPamLd+y5U3IIDhZyLWB8zPXB87RwMI4Xx1eFlIQ ssHhZypPbX422vy8nZdDciZktV1bOHdn8T3Ft1z2nV3F+ZFzHOdIznOc45zxqTI+v5uexh7eEHm4 D3Nj93oiEACCsO+w8wjysLVX5MM2a5srZG1TS6xterl1QH8fcr21Xd5pbYrXVJXus3OZz6mloo6e pTSnjmrt1GHnNK67s7RK1KZYHRX1U58DP9aL+haEPobvobiDhyhL3om4FtIItZTWKedIURpRN9Gv liAns20rTVZuUp56ELnuSeu68gTNEXVzIa1VolTOc5UzlKE9Qj7tj6hlO60PxXpcryC5j/3X19E8 zgXaJlF7N9r5OMhn79Yp3a1SoRjTh9w0QFm8FxGDepok4sBzH8HrB2u5rtFEtVzEwcsQc/5G6RwP jlFSLGK1uV6sOSDy2Six9gC++VtawdAnUr3rLeRM/tYmiqbJnBetq3bNrkM9rVOewzsonUjwv4/S lVLKRa0M2Vig7kLMOzC2y35XsETeF/X+JnIVOKIdpGbxnmDbt/HueY0WMNRumqzPRX6sRO7fRnn6 BMSohfyC14ti30Z/nXifcJ3idwLflzmUrkcxH/dC+MD1htcuErGtA0fnuUegtqymDLlbksC9PPH2 68a5d0v8jno8Ad+1+/JiUvLJV0V9ZdtN+Zx8Sj5ntYt6X0pB5Weojx8gx78CPoynOfIaKpMNKlPT 8Db7ItrfojLlp8BRxGCnNaCORQ6vQf8PgP2Y9wfEMwO2jzDmJ+DBXsy9F+23qVp5mcq0R6Hng6vn IQeAv2PeF+iw8gId1j20T15jHRXrM3YO/pXB6/E8YJoj2VcHw/r8Y0of1t+aIT/jPg7jH6/B64p5 PKbUGiCy/gTkx+Rgk3yETgIn5Dcxt5d2S08RSTgn6QrQZePntFDI00ATznC3dABYCqjqbjoOWQL5 HtAPdAFngZvqbMTiCL0G+aKOfxUY8jkKs4T9eeCXwCXHlgj+1nD9iVD/Qkm6NoP2MOQg3oRBun38 cZqlfgO5djrekoCynZYy9FG02eWmzfKf0b8C81J0bQo9rW6me+/kz50g/Z6mixjGUHU3e7xb8BuN 6/N/a727Bc53D/CQiP8Jmio4dBXxd1GadJYelN6heUoXLWLYelTE8zhNd84J/QdEf8r5gSv3K81U ldqP9qMMR0891zvpWPdUIhweOHDNoMcY6iWMB1J1dyc9xtCZY0Gh72I4evy7n4cWmoU4hSBJcCxF Rw7ZxpC3QD9GzPNNjLjegndVS4yfDMR2AwMxJAb6HmIgdsTA2L2MhLiGOa74Js8l53wcnqeeD/ul /hrjLtMktHNSZZzfdr5I4nxTjO9xnXPJlZQxQ3di6G7grnzemv9PwN35HXABOP+//paE/MA5wsN5 gt+oD+Ot+iDuRR/NJbq1h+jTXxF9Blbc+uyfrFcLbFvVGT4P14nj3NhJ+kzaHmO7wb1tanOTtCUa yXUf0AFuU1Zt2uiagJi7FkQM3UPtCnY7TYA00WidVBK0JlC2dhTR5FzWuoSApWkMhlAyNCnpY3W3 FgGlkKwbdH2l+85xijZUxCZN0fd9/znnP//5z3+uc++BDkF78I6ogv4GiKIPb4crS6HTgT9i7Dze I/hkH0+6qsiuie9KjI2vgt+TQLYQZ3wq7FrE/xDYAzyB/neBJBAAlN/tE3gY48cLc8d/CH0c7YvQ HwBvoQ9P9OVHYL8ArIX9MfBPYDcQLcS7BL9Lh9T3yHXuof9f/YL7x3+rhfsGMa/p5+8Q/5M++OX6 +TvHtfP/Mr12l7iO6jpM3Jve/7e7zxfdcf5D8fx4Cn+EHL6ac3Fn+XLLzkLnLdAqI3MtPSCrZloD Ls46yY1EoIPKqdV6hMglSyaMhYsLhmPWWvm4+tAfBZiLuCiJFGY5kQXW2GtoUz5OfJSqXn7Z8U/G avyK46u07LifX8Cb4AJhpJf3kRzASDv/hKQBBvcDsvYmtRA/4JSUWX74j5IAkAE46QFT3bYB5T/q VE5V4d+TvnI9Ly9j9QXD8U+3WuKT+XHk8yZ/h4SI4H+Fzob+HjoL+jp/gxg6z+ccn9/KYL09cN/D N5O5GP4l30Is6D7+KKnWbkdkWWGdIzJiWvESvpdv1S6b+EOkHvoAv19aItDPn0OmNj/reLwqv7PS P8Ua4B/gAjYZXqfhNU34BviDJAqonWQdj2F1xEt5FtvMoiwCOVLSrdnm70gEwnq/5hkyFWODfBuZ An2eb5dTRK6fn9dun6ooWO9ZWVynxDHKrFzcg7sERcXPoeLn9Gr/cGoWWyRew39KYgBDUU/BOgXL j4tLDGgB2oE00A3g/w//CCMfwSfKT5AUP0Y6gG7YLoTcLFHBw9oIR6zD/BG+FZXw96N2FL2POp4y ldlWWVGp3bY6pWVW8wAfxk91GDFtPuJMm2619/Mn9VY6nOnVasKfpKcUpftR4SwwcYs6gwGe4dt1 JbbpCvS+iiYlPv5jPfmqU1pupXH6a9BsB+8AhoBRwAW3NdjDGtIKcLi3OGU+y9fPv6Unf1WW1YkB vgJbX6GrtUJOCeqcb3NgrO7nd+AhWcVXyvsEElwtMVmNrnQWN1qxfr5Sb3ilFKFCt6ycoY1bpafw 8Cx1SsrVcsu04zxZXKa750387rjpTJ5mCTyMjXpLder9gqtnAIgBGfSoiluOvwKP+H3c0mlbpA3o AXoBFw7SgruFg7TISd3j4wuxp4V4sSzEtlPgMYCh/ybSDOwAXgNOApN0bxvA0B/DCm3gDoAhYhRt P9gG2oAM0APkgDGgiAzyWqxTC+8YOAP0AnnAhQOZjzzmY6yCB8gVvDkFvkE77UaaJmmaZmmedqUn pf3p8mK7Yc58y96oaIGiCGhRmyflyXh4zGN7Wjzc7wl4WPZqThY11kHsCndj3dHEmcTFBK9Y1OHu KGKD8VJaTvLAKMDJIPWj5UfLbz/GB5vyTaNNfDCRT4wm+OCJ/InRE3ywNl87WsvtRHWjtaiVttM0 3UFdgkZpM11FXa28naf5Du4SPMqb8Sy42rwpb8bLY17b2+Llfm/Ayzq8Pd5eb8475J3U6865h9wn 3WPuSS3uNnfKnXF3uHvcblEULWoust2usfhSdgxF7QH3AoxkwB3a8uuRHHhItzt0uw2c0m0b3KKt EDimLCCkr54UcY5ixlHtp9ohcEy1gRD+hR9BXwrcATB2xJ4ZjIXtMPOHA2FGwnQsTIfCJ8OsN5wL s1y8kY3oLEeQ5YjOcgQzR/TaI4gLCwgh22HtNwy/Ye03DD9lXa+vDZzSlg1u0VYIHFMWG5ahRb74 DPY0IraCu4E8wEkU3Ay065YPLADGngbbrMu5cb6VybIuWYN/hpBgQWYXZKYWZ0aV1Rr3sS6E7ULY Lh2oC4G6EBqtqznWKZcp3055S0Ea6/Lxm/G6VOl04qbTiXRXgbu1FQU3a+uA9vF91u4Fn9RWCtzz 2bxWbSk/AVyb72Jd+OuE5WNb0LvF9jIyFd97pKK8uCLLXpYbKkSWvSQjfohTEKkkXsk4zsCgH2t+ UXO35p9r/oZmn+0NGRdCxu9Cxt6QES9ht5Mwusc0f6B5o10WNt4PG6+HjT1h49mw0U9PkSAGbrCr gsa7QePPQeNQ0Hg+aOwMGmuDxuqgcWdQhYqQADHYLMV0neaZ9rSAcTlg/CVgvBUw3ggYzwSMbwaM xgDc6Tm8PA3cRhTv0txwqN4Q9caseuNlhtrQu6WPePoZo3cTg5dIs0lkuUcLu0Em5kBmykQcUi0T d0GqZOJhSKVM7BRxD/PRPnyZCFZG+4qVlkpzG4a9BSmW5jrIJGneLLJ0XJohyCWZnAW5KJOzIZ/K ZD3kEyWv0L+TJEMY+jeZ3I3w9AyJqLD0PVLD9kOzMtEM70OF1elLpInOQbcktsqCviBNJEf3STMC 2SvNMORXBdkjTQF5RiYXQHbL5E7IL2TyNKRLRh5Q8TpJRMd5itRo3SQT1Rh+SCZUhJRMRCHtMtEA uV82vQ3ZIJtOq6nraR/F002TxNSZ3iOTJoZbJzbybRLRw2tJg458m0yoktyqgsQNunxiI8voUvWB R5fQPh3FlmYMbk3SrIHcUqjcV2RyHmSxjKDGdJGM7EblFk4sMFedzys0jDRUoJA098NJyORcyGyZ XA6pVjORVOXEqhWkSSdVLk3l5ZdmQLxKvSSpI5aQGtp1UFxB3EtNWfp1KS7a2WIqxfkI5KA4m7hX fJjI4vNWnMHPeP9BkYfriSaYtlccN0+LY8mg+IMJD7tavGkuEL+t2SyykX7hJGaLPiTWm7xXHEjq CC/WYJoU+yJZRjG7J3mneMqcJ3bVZFUOP4PzY2oNBPqJuVlsr9kmvo9H4XuJJ8Qmc5ZIRdaJjRG1 0DSxwbxLfBcbWY8530muF/eYO0Vbg854nfm2+FqD3sMdyX8RX3XBTVxX+J67u9q1fldrW5LlP2ll C8NiGyzboMFYiyy5AVXG4aeVCEptM05NwuAa23RoE4a08RCgtDyUdpr0Jy8pNIVWwg7IQItn6HTa mSY4k3b6wlC3dZu+aDqdGjqd+KfnrlxMZnjqS69079k957v33PvtPXfPGiva2WkYnnlhT203zgAN EWbAGWzDfdmCXZvabjGOSCN0Tb5Xu3/LbYpvYziF9ZjeJP5MPCkOiPvEKL531on1ol+sEcskRZIl u2SVzJIkmSReohJ+zdKy/MqcrhE8wcpMMhMmnrW8cS1T1mLDchMKEiW7SLaUS9DE3mh2i5bIiyt7 slu1RFbsfS6VA/h6GhLZmUMkMeDLPtobyIP52QNZIRCFrJIgiX1RD4Kz9PU8kH2pPKywHhOVWaUr NU0ANk6cr2Sye+J8Ok1cxyOeiNLpDHfHntL0rbbxmLZWPJr2ibvq7LcSe1PZd6rT2RZ2sVKdTmTX 7/UdTE3TI/TFeGyavsREOjUNQ/RIfA/Tw1AsjbBtBox00pcQRpJMIIweJJ0MhvqDT8Agh+pYrrOz CNoNOQbCoNltgA4UQV1Pgrhz0GWAurhzBuj7RYcbcB7oUGcCYcIRssFwuEE4YsA8DJYLBnGkF4IM kmsJIiAXbDHMz66ZG4rmq0XzVWbOA6zZ24LF2TaQoOEhSBsQo/0fy2D0f+gEk9uPH03FBwPxvkB8 EGtf9tzxIU/21IDPlzt6nBl8WS7YN3BoiMn+wezxwGAsezQQ8+W2p55iTjHz9kAsR1LxfalcSh+M Xduub48H+mPpyZ5Xt458wteZx762vvqUwV5lg21lvnpGnmIeYeYe5muE+Rphvnr0HsNXYk8UEr2p nESi6a6DRTlJLWaMlr5Kfzrqkr/QaYTONr/nZOVNnsBlYtHSWWsgmrVhZabGHY07mAlDmpnsqHas mjwnt/krb8LlVZOMamcgSsY88cMx/I9iGRsbx4Icj44WufYUDWNa3LAjYAyvxoyCSLxmddTQrtrH yPha0bQiloxqXalcMhn3HI5VYjI/yfJvLT1KNK3oUNMI+sRVGwm/y0j4LSZX6HfJvyQfJrkZI9Of xTpnZPozmOXPYp3DTL+Gm+mc7Zzr5GaSs8k5xD6YfTD3gJtpnG2ca+S2rM6AuUoDznDtN66NjjO1 BsZqjXXj7Zg2qrEl/5cDvNOYlrGCpag3+mk4iva4r7Z2MVo0jhtditrRx/sXz1Y8WbER8IdrEUl0 isJdk5jnJL2UCPxdjphF/i6QCskk3KXcbdhBSqAePkM8mvyoY6mjR17oSC51kAhey4vYbN7kd/qd 9djgOU4WfdzMoi6Qj4mPn2EHeQsM0xO0E315dSt+QhCvABX81fMerUeel/9KmpOFzZvA3+anJ5am 6adg+B7rdWDlI7gErcRC1Cmy02Th8lCqW3wlm0poSYV1+AzrvZhJFkiE9W5xlZeZAmqwrbUdSHf/ QDze3w+thojHB9h4p3Gxh4Qh4iZfvU3scBXaiARvX1c/Jw6LFDAJYRoR/o05rAvextTwX6QcNS5K dbtDIoIkWlFZCxQwQ9Rlu73XMez4qYOTHeCo8Nh/ji8tif6SeKgb/mAwNY88ZTIdSXkpw7iKKOGH hUV4qEFGwwk7y1yuUKjc3xZqaW9vc7YGgwFVXFdP33R1J2uX2us+u8urbPaFdirwT2Ho4x+/Et9Y X9/QfYreeb7Z76ubN3jFFX0XV1RF/qbXvU5/Qq9w3DrrRY6aLWYLEKFSecs15aKuKopzMlukqjz0 XVea3Vk3dedBvQaKxGLBYmuV8lzdlF0AK5K8oFcSQRaocF/50FEFd6qgylvjALgDABXVNyEFF4jx 5DIj8qPMSHJhKTNPIpECix69VNJdtoiku+3YVDiwsYXZpksjCV3sdeNGh4hwM8cIMmSlbMhrVc6I gZ13hsNOJQxYM86wEsZb+ddIWYZk/P42orS1Gly1t4daXPjYRRP4kcMtIa538U8w/L2vPP/G/vr2 +xc+/07frsHlK1B/ZMcGtc4F70LThcPn3rDN5Psu7Zw4M738rqLFGY/+lT9zZ5FHjdzTa0WH2zGk ndAmyidcb5ZedP1I+aHrZqmlsSpSRcskyMNFvYQQmeUofgsmkX2Y0/jpb/Bt9j7xEgmXY3O2Grwq 5Sjp+9d1u+C1kTL8aJjyAQjmm3CRWMB7vaZIc54z33B+SNbL6+l6vNadDje4vY2OGqjRS8tbayo2 PsG5hpyPJAuZhUJGXlhyhpsrvIUO4olEvAVNk5fm5Xkl3JwpKOEiXdDWSZ9kC2NEZJQRv7qOhUqo xY27sKUdMdB8LKWfOPC1gfpn/nj2/I39z41/efm95eUru8NRzV8t392/68UZejngD4937P3iN22X Ll8ZTZxrC186+dvl34cbIk077NIPxg+c+QiJCeG+vIp8momNfEf3RGwQAuDww1MsMQuSzUp4yWaz WPJwUJcJlOEjsBAQJYsNeHILFvFYMlNZt0ogSFYbwSSSSre4EhxYhD7d08xHeOrga3nKex2EUUQq 7A//UaQHd2QmudBhRFwEj6lHHbh52EZSwqebNP4V+RcOh6PITSmEnKHyAB5c/i1+Z4i+9qWXX14u LJf3w1lY4Q4vfvve8ixsukfduEPiK/PcpPBpokKv3mQ3QYm5wtxAGji+zFxeWV7FbTXtNN0QOIsA 3kpzFV8tY1vNg5fnuOIqVVylqjhUIKqsUhVPkCmF8MDn4e/XFR93h6MIVCfx+PRipq+bHaW1pbT0 vtVG8/RXk/CBRG5RE1FJNTzUvbrUK70lcZK3Tv7gGyqojAO1IlDkYEE7lpzHTVLAo3UBA7OQKeA5 zYJPL+N0DDFOx3jjWIRyLFaNiFseMYKTx12LCH41KPnVIDUkQpm8VmY1umjpQoZ10mtUNqjKBlXZ oCobVNURpuqKpYjV0qeFJg3JJ07FzR6HG/cnGcnAscx/+K7W2CiuKzz3zu7Mzuzu7Oxj9jU73p2Z ndm192EHGzsOa3t4FIUUxxBQwYiNZUflZYFso5pXUUxCjUylQpI2AfJCVSBJfxQqaliTVlCXJgr+ QdQkUqukFZEoFVWctorjViVeeu6uE9xW6q505t7Z/XPO+b7zfWcQqbTK2kIEmjb9K1QGQ/Ct4DKp aix6EB/49txfGlH35ZM/KJdPne1uX5pJrelty8ZTj+0uny7PyM321eXyEferT//64F8PtWcfzCxL rKgTXXvXn/+YrBOroX+TldmfAo5zARptCQ4HMV+6909L8gWa6uik9I5EdzjsWjgct3Om9Et8HTaD H4FMcujUuGmKlB1WQ/7nolv72FVCn1ygorXhEn533BONR3GUENcZII0IRNJfNQJ4Ov2oONs5SzQK xn/9tDh9q4JFgsgHGpbvs/KywfuTZkxWZMz4DME0eK0P1XijfVTCAyfdafYh2R/vo1Q3hIpbqFS0 LnPoEFUELSkiScBsc8s8vYkGAuV9ScRIAV+1iGIKJgA9Of7Rk3pWWbrsxNSu67sPfrDnI/Rc+V3H 4ryayz+8PLMqbd8Wyz9z42QNF/jDldGb+8eQ48VbaOzO3K6j1tFyucnofw0Ftq+YZ8MNYANPPW85 KS5ix4wDqM2X0CuWp0poHlE0xyIHS/TE5UvgKxhTWMQYA8wvcpzDRrmYEp6yeC7qOs4idtb5xQR6 hujm7SKpGZGUAohGFbiYYAwTjGGCMfw1cG/5qnA6UoEXArITctsRoIZhdb+KUD8aLP/5zLqHTLOP TpdbY7aeTM06dOZfJ8AFUefAY3xJT4LHCFGLJqgIuL6Iz9/ErKJY1yqf00Ov4rJXJCRFwr+7Uekp DBdifKYrniOz0HX4FzqQb1VsR2/vinknQk/2Vp1I79zQfU+CQUYo+3nApUolUYP1nCY6fR1bxGFx j35EHNV/4r4kss+7L7gxSuqY0nRd5QWnwofUsBJycojDDoULeiUliJI8pQV36x4xoVOqqGJVx2rO Kwa8XlHHuorTgicgCB48LCCB3+9Fqlf02IK66hWwDYV0j5ZMQ9cQuiVaoocGUeB5zuEJouBl9BSl o7ylJ/hIgzlgjpinzffMmyZjiGbCtMw18Oa4ed5kj+2EAg2KxZlItHNuugiaVBDh21GIEv8zB3P4 a+4XQddbjwj5jAN6Bs8wORSvZYjst7aGKXEaiVersbjwwoqFAlsAtwnCVoTqqyxgHCYFmCiQfxCZ YPXSuKgFJkfKTKVoml5fVltjeXlHuW3V499Af/KjOytzWvvcgNyVCDI4tuP6e+ipw8syrbLoMAzn Ey/aHrr7xiu1cbthBMUan59b9jl6v5wD1K+994l9g70fOqVMUMF7Ixc4vilWqj6Z+acbnlY3HFxR Tm72d0ZHg9+PHpPHYo5+b79vn3efb8z7OvOG+0zondCUzDNBylweXBobCX4vNCofjl2yvVXD15vb 4nuYYfewPOq/7GFbBK8vqVCbsILAfAQsOKpven2CfYdCCzskDvXUe5E3OmAi02fsmkCLKkZh+UaL 8/BxHvOdkchM552ifKF6mu5+VCzOFgm/AMRQ7k9noLTTM9MUsVjfXLfvZ4scMJeSwRjjdpkhw8Gx HGZk0x3kDYqJQXCGBYPionYDVWdRXQZGESoOUjDLCSeRVydeliHN8ZH50yKRqZSsTCViOMgr+4ZU 9m8nnvzggY7N114a+XB46B9nfl8+d2kKdU8ee3VzJFHP2vvLdaVrzw6/MHGx/OHJgbHv7On/KVpZ mkSbr7Yn6xsJe2RgzyDMIZnKIKe1OToChddJEEnIkLDVvy281ThVW0rbt3q3w+UF74nga37mCYFN KJSmORKKoOmxvEfA2mJZphy+XMyjxBWstDsaWLQGJtPBbNt4lfuDsPUQPw/FFSlTNLHZSQXEQEOA DjRDSaHIF83OhgCq3Ka7wfOLoL1gzKqFfZwU9hE9I0Z9fq8fM+lUbaouRTP3b5gJSiEpLEUkG5M0 MqJpoDoS9CiElD9GQgbeZQxJM6iMWJhXgzryIXoAqwV8GslO0TK/VOiLVai5TwqASjA6DWsH6UBL sxdUIWXKuSUdHi64vDWHez7/4fhbm5+9crTt6U2iX258fePex5ZuedgwEtJ2+rvbmlLGsrXl0o1j f3+5J+qy3bv7x/Um7xk6hVYg+0v7s3FgSJ6ibGehH1mkWp2sjeOztOZ8xGln7AwPxaJNm8mbTtPV Ra/ku5xb+GF+lBf21x7Pj9vG+bdtb/O3bbf5WfsszwsJJaDpSkKRNM1cm82WcNrakVJMjwM51rpc U5ziADPIrsV4ilHYmoSS1HQHy5rY1eXGXci8YiAjej6P8hRye4S4gIV2xUPFATPtNTVKJBeQsukk TqO0y+1OBgSllbwwqLSRxJIjl/8FwjCS2xALXMoQIQLhFgszBVDt+sJ05YIAEAAFsOEAiUKhQiq4 3xZvV/6UAU59SolfFP/rSbBAuDKIvI2VnaVCFn3BMtiysHPkVxBv3JjaNNTl0nX/m/2pEDRrbklu STIqOEnjbHtrhd07Cz+2lefebx7ZObfhVwfKvaRdhiRo4S3V1pUPjB2WQZupWiDOZ9CjOHXUyqlW S6yDTyhY06IJxadpckJBmu5MKF5N93kxRo6oR47LWG53gle6aoVX6h03edTAW/wAf5W39UDAfCSh kh9lWWm6qaIB9aqKG1RL7VFH1PNwYdqGgT/FwaEM4dBQpsIiIEdHgYCV6Kjxv5lLOlFwRqpUBn+2 MGH8G3L2OKEQxn8kWT1/eRjOkKkJ08ENmRrUMau5D+1BB/SBlO24fjx5NknfT3q1Vk03CRZJ1pMU ZYjGgDFinDbsRglNWGJCTWOoBYItxPgt9TIq4XNW8H5ZImZDykqdTtFtG0mWBBWQ3szMHOCGOJjC TLFAVpBQayXZinTR/y9doGcFGnZ3491/s13+sU2cZxx/3/Nv353vfP5x5/Odf9zlHMeX2AFiE6eU eIOAgKSk1fiRVF4po00KKCPZGiMYG5pWAkOaUtgIEevEJsjKJk0MArhMq1CFKOuqjcGmsK3qUFep 01QkJiHERnLZ89rplEpzdM/73r3vH7l7v8/zfL7di976zlO1t5b0yLbh3eOv5PAHVsP/efvTg0Wf p/vM6fpZuwbhCxTwxtJIjLAFHcOe2P4Y1dreVeht/ym6iRyGUsAVVFEq6iE0poypk+qb6j/V/6jM nvZ77VRciAfiQb6BNxycwAW4IGpAhqfgXCyabIea0ha+YrxDNTQ9l1Dzml6dP1xahVQlgRFKK9Gg okRRoYBQixoLqmoM4YKq2OJYRoU8hamUoSqC343Q8vYoL2N5pff39N9oipbbibY8Sqyt9g+1kw7r CYXb2mPxdC5L1vxkLXsvS13L3spS2cjy9ir+0sUkqK6Km18zzWcelmuigyQ1R0ySpnBAEZKmEqiQ /EismUSx6AaSdACWwCjVJqZUtzAkb8sjpM2hYRPjzwt0cepiHfuBSsK1Z+HC4lO23cJ7qHTzioYI R4dXF5vnVtTnc4+luQcOdkvZavW1PJOmKVg0qQz+ne2bcKpJ6aXZby9K6PtPTPv7s107xKWdhoHj bTn6eVv/wLJGAwgOqUApE3DmSTx8QRAgLx9fYItkKFWYIq8oHK+oKsd2qO5atouaRnWoLk33J9Rw 9wI7Qt1N8oqIOVVdWcd5NaohP+fDWBWTbii0iBLDbs6DCVey+AUWswd6dazz/rSCorg3ilH0q5Ae B7Ra6vMPh8sj5AB6SJWszUhRrQOiUKy5IQHwsMaEY/YD1xE8lOr8Rz79GL/iwPUxwHtyCqvAp6L5 8yUzkEcczy1HI4k9yYOJg8nX0Tg3nhhPTqPpJGtP2JMZeyOtBTKyk6/OP38hkIdhqhQQ8naM+CDm +XF8WjnPn1fc4KNMPFw2+8BrXOLdwWgnbL1X8ghSJ3L7Ap2oOv9g4Y4LdnLV+U8uwh4Y/3LBJ3bW /Rg4sz6M/UCdLshmHxXyExnUlVEABTRCIc9ji3pDbx3G1zY/ldRmd+3qSljxPVtV84srHd2zV6i1 +8wOCiBU37jtyYT9ldmfvPocHHD/btuvGwoaZUD36oXTfQAMyqIY/nlp2SA/GDjpnRFmInflu8qM +ongcUmumEhJjCiLSiPfGGgMpmVvjKCQSEJoAVS5RcBKRjdJqx2EZMkuTIIwgU9Qk85J9wlmgp2i pph3He96bqgzeIZlKbvL7fQ4vSIWKZER2bDqeTnysrLXUWFGI6PqBHdZuqzORB+46c0+Xx7ZwnmX R6Aj8aGtNTn0AEFFUJQHifSUbNgm5xKdCSrBCXGBEoCjSDcdJjxV4j63Qei5X18icFXzYISrniVc tQLHeENNBVMew5GKyJJMOTlWMOA7RQ0ccsNMdMLMz/gMzCoURBzwhg0k2yGY5gr4q6NU7TSBZ9Ew sZ7TbqdQdFTnH5ZooUhJQpGBi6rO/+OCv8hU5z+FwUHu2KIH7n7JFpG58OvDn81AWrgB+XkXlUw0 pvw8ckDl8PN1DBPyPJCRCBT1g4mb1nHr2M0f4VO4/eqLG/dtmhzo2rp9xynHC4w1ZN22rOvW7OPr mMVZfLz77R9aH1hnp76+tIQjH8EzeogQca/1Pce/QB/gK/BvSl12ejAyqAwYdrCy3sA6bl1gjD3K HeGPCEcDYyHvarzKO6gNGJPsBD8hTIampJ8lzqTe494LsGGigAQJzIJCYgsjvzBKRDGdMEnVxEIC Qh6P18vQDsbJewVv+Av8euEQdzjAVJgKvzdc0UaNo94J6Qa+4fU863vbiyGx7pYkzt9GpyFMob+j T2kbovWomPfbXFDbLxrNba4qLkzbljjzjip+qeSn47eR27lF8EUa07uTRFBQ4ImgWKQTr9sTlK8B 2JHGQLNCW7reqGuiMsuPiKiuLNpziWyJElmRxft9xBateAR2yOy8T8pSEUpDuS6zbiKzApNKgswi hpFKhHUDx5iogSQeQkqAWy0UN+DjKywMDC1zooEbAhBAFQDr/ILGFhQ2/NkcnBNIrcSzvL8YgosD jQXgQnUdlR1hIpUQMVGNKRASSiZIxItkRGjedif7zrF0y0TlqvXX9Y+sO/gk7sBFfMJ6xxqa3v7c /s0TJzft79nGvHbI/XTq8vk2vA87cSs+bu22/mA9tvY5HL96w/rQOvPmq187izfgNceqoChCUX+G fqKjFry31LlJHpFPhmxuXdI3yGuVtdqLylc0l4AcyMk7eKe9NTcQrUQr2mH9/ehv9Vs592T4j/K/ pSeRJ7Ij52aq1J+modtouDZxajoLk1IRKEIHOKgVhBZdC+q69i39KBwmyijJ6EHtY+2hZuO1Xu2W ZrulYU3MKJqeMrLRKv6oJOoIORtasoGAQCVuJ5Oa5nS63ICk2FHyMCjDZ6jMh2LVRpXCTIMBTZLD cUzhFobpJX0r+/RbOAKczwMYEJYnPYmfI1xPGLV2d7/GcTX2nyMegAhjeKRc9JOeVSZNq+wDUpBq lAAiSTQ2B+WQEUmljeZgJocbZQhmuCWHm6RUDsnR/xk3s27aSKV5C6WhSdNM0XQzRUUKhFbielMp w44aZEAnWVpYgAkwdeFwKAgEggEYxVAS22qGIt8GbiERXV2eW//lVVEYqdFHH4/v7voGXlOKNhWs TdaGvuLR7258/cfUTus7Q0XNMPT2IdseMlt9Zf+J7SvjVr4vHLcZ1E5qcu4Xy17bder7hCt2zt+z J6GyFDEuFaXWLU2VpM3pwx7OZTpbJU40WziTb/LntITZ0FzIFMyBpiNNRzLn2qqZq22Boor6KRXj Kl5XCqF+rhAvUIVzS4AC+xNqPBHH8Sqoa02sH8m8TMnnQk0m505xNMcptMLZR7nRplPcWfoSfZ1z mk0cbdcd+SU2/b9kl31sE+cdx+853/nubMd+7MS5Ozv2ne9yfo1fknMIfsE5IBQSQnBKWwqdl2wV jEIpcVSYxkRNC4y266smyDqmwarCVmCFsS0EugnWlolJbI20Tc3+YENrVE2M0E0LTBo42fPYmdpp su6eR+dHZ/n5Pb/v9/PtdHNrwRDYASrgVUCD9UQQopw5AaBhd3lyqP/TOQcrIXBHj34qtSfE7ATI /HjBg6ZnsCSgpi9Nl2pughC9VK41fYaAt0qzMzi0zc7U57Upxvcy4vdGHNoUsxthXv3jbqJUBSc1 xcyoTh33Ky5FMJQgO9OL9A6+9qTL9J414vt4/+avun1G8uTtdQ/O/euaMfpISvJkXZrWdu/1kQP6 lv0X3lx/+2fLCsmDXo+/gd42lz/54faVcTWZCDy0c8uWb5y842ltCkdIYurj3YOpjYNLH9v7vaE3 p6FtqbwEV6oPdawNdaxMnL5AKEhDBU9awXKYg660rBiojS4rVApNSHCdYe6jugiyDyoKJ/sciOCv ezz3/T6J8YQJmYQOlhgBuHBRQ0HEJ3EkVxChAGShKLwmmAQZSkCWilJFek2ipIsgSgjkOz+p6TK8 i+JeHqILB6KFyFfNo528RcAq6oD6BIF1GQPYQtZV/w+oa6CtOmlbqzzQExzaxC/PxqvZegb88guF 9XyQ7p97vbIj4Lp38zNMppqzg4fBDrwjqfkb9FtoRxLAZHxfcIgKKVhCSlT9uvqy/RX1jPobdV7l 0DqSMEEASWgaQZheaa7wF+xXw1Phv4bttOq2Q0UOBNX2wEaFeS9wRyVP2MftpM4ysg8oiiT7BEWJ ygkfobQ6MVerAs8D9E7b1lYOcbFckcCQNC+R0p5UykgVUyOpYyk6xToYiSGZQiRSjILonuQCL6OM grWoxsvlOi/P1MUo9l+RUQJhzmEJBjW7ZtXYJBEKN6gwCZQAF7IlCYeCbniLa66zIDTlUWQ6o404 upgXgsuCoISC9QxaDzRm5DSIV2tKw6TIn6trc2LXM8NPHVkT9MUfBH9oyfQ7G7pnf3d2eN+THuMR ul8LZJ+ubhnfNfD4O1Nk5LEB5HtaIiGvq1Y//f25pHH1bfLbOzMKwLWAiGDP1fKJ5QKholOZ9bSm J1WgU2NuEqpgMQ8y/BP82/wETzXzvFsQRZ6ggY8QkVi77b4GG2v12QIiiijGxPxLxiKeMcsswSC6 Ypg4j1qSd9Nmc5gX0Ux0s4yZstEiL/JulqaZQIONIBkzh7Lp5fPx3rTK8x7iIkgQPHjOcMk2Az0b tgGbqKhPBl7d/lmAjHnENdWqMLBiU88nsdpBzudRWgRILJBsHFyTiGEHoHFoRJPSBzGPQNQCzOfv pfpwENrz+EJqgiqCImUMuM1YyVWAQ0I9WbqbmtHxqQk6Lg59ri8bXTcXD8wlH8qsJV9sflTmYQIE gC3VLEuxlagGtuUdF+7NUove7+E0rdnhc7Vvq5bIDdv7PP6EzYnTwxfm/2n6k+l9op3IkznDbYYw Q8kw02Hke9Lf7PwWc6TTVMBC8aXVneMZ8AxzIn46fz7+q/hU4KP4VOcnca6TWcH0NfbxvZ2P8pvZ Q8SRzuNgHIyzNp0BewtvUN+Jf7edIgrFwuPNw4VR/rD7DDievQRuFCxsc7HwdM60iiXdLjeZw7/y AZ/5NAc6dJZjmVhbONamxdoief2U/q5uovQl+hp9j/6yflT/kf4L/bf6dX1Gt47oQM81sQF2E7uT pUg2x/azu9kX2KPsCfYq+0eWs7JedoQ1NblYk9AQlGLojZHNydwqsmOMKCWTpGBEYmmHIAlDwg7h qHBGuCQwfxZuCfeRkgmGHaYFErWj1dEmtSXbutuotp7IcocmaaR2kyCSXDdX4S5xlIwGkuAg0sIJ 8K4BjcLeAmkUhgtk4Ydu4PbifxcuhrvnvcAbI7pgF9nVQRuqlt6BwhuZog26SA/TFC0uWfwwOmLt B2otX46tmSnPlmO/LCHJnC2VRjGO3MXe1O3KxJLoe9T/szNwBlZnp2HdrUZd+ObM1JAkA3/Nwrw9 n0d5FozWRKJjcbZFtUAT5UDQGtCswUzQ7nf6CZvM+YGiZk1dfgK2NPiBRUG3xVTOT2DoBAuiUdON Z58Fo+USgS5QjhEYWjWkD0Hkaxq2uPphxRa48BTZHXbEurx08VhMgiGnub5K7yB7Tz1f3DoBOnkj vDTqaQn25rofHr321IEjvN3S1ODx+ju29RQ3Wr6WCwXEeMeLY0+s3XbqlS9u7Yr4XIJbioXbV/Tr q/Y9UF4WHZs7ZASgJvQtX30IZFYOLupKqF50zmPz05QXaQxPhMCg4XA9wBI85EkgiM5WiZ8Atw2v GtxvYvxBq9U+6nBAK08QEHGlwXhcEVS9c6s78WAszi1JFyOTETIVMSLFyEjkWORs5HKEidjthEOU RFKMOl0GBClowCK8DCcRA4vhgXKNJss1qIPIgMVAN8RhRpBr4zle6sZgj20xk4Sl0VistjRSXxpZ WBr53NK7M6Wa6MBpDCoxkx3m86BUL7FHoxporTXo9bSg0MsFZU2jlBDw2UQ/0WCXLGiumoMh4Gnw +4kA6w/9T4mjuMQoPal76BFuRK60HmZ/QJ9gz1Psc+wBjqxQFUtFqmiH6bFWM0LRcmkDcOIK43rX KoucOR3CuoUglV9wlDQmIXBm10vDJ4d3X9vXvytzRGEsMR3sN1v6c3pv+6LQMmQb1eru8uTzb/x7 X2rRJur4YGOLl9Sqb80NV9Rcb/b0jY+KWewYA/PTpiGkWirxD2P7HTNo5cAG7oT/CnlFnQI3wV9I xsKCNjLatF7azH1F2sXtsoz6xxpPN55umiAvNo37L6pX/B9qTgK4GwmTvWWSuIHOyCS4AUgKNKEk EGhELiP83QmcfxOCViawirI67MAeA7gQHWI3Hg0v50w7ADgGzv6H6aqPbeI84/fexWc7ufOdff6M HZ/vfP482+ck53zHPpKGpkCAipYCq9uNUZQ2bfOxUUq7jY+2fHVidGyiEp0IbBpVqymsoTRQTTBN VGKaVNNJiJU/qDQ0bZVSQINqUpuw571z2CLd87z35u61/TzP7/f8HnijeSZxCziBi4gRMtJmrz+H /dm0qtfsCC9h+HDp9pDSdchs6SponBEsOXFLh+XNKVN0zk/yfYBfN+C4G4vPAKAYFBGONMAuYcIH NGQnjrkFsZSpM60OgcNNGeLApfGPv9j66rW33h/q6h1x0oGAWJT1xx7pXNm64U7wRztQ8ycX3pr5 +abuh1ZvqYRC7SPHX7/TqxYIiMMawMoQYCUK890rRvxt9l32HPuRv8Hj6XQQUT5KBsS80xE8KUYv xS2tAvg5g07SIiy+85FDfZ2Bjgzy/WkjFNghJb12OIogHDyobtCCfJAMZs0AuiBCHFqDyNMgJ5s1 C2XYzQLIsDe8EK+1Wk0jJ7RpjdTEJEoaGC+GD7+6hLIa38CHCl27gw9IE8cUMKR+bd3NW0oT5Drg ZZ6/N/8tule1IPMANGk5ywpKIp4gaU8yncqkSNqVkIVkisiyYBJuKYVSnGpCBZkoyZoo0SbYCWFC nsie1i5q9IRrp+elwM74RObV/N7Awfzb7FH/sdxv/e/nzudcu7gDbhJnsbrRRLdmoVuro1uroxuf vtGc8AA8IF1Klvha4lETW/GSYGZ8KeWd1Ge0I9+1uO3h8eWzo4+Nfjg6ONrrZIoD+1aMJYIJTc8H 0htW21Z985cXvFKsQRr5xfry9J4/HL31ir4MNY/5WyLZhb2HvOI7J37/XlI4aFUBVQWM+YgYKhkb aM9Kb9U77h31PRPc4bUnGk+Rn5CX3VfIK9Q19prv39R/2MadPuBLwaevp7ZS4/J2aqf8GrXX9SX7 T58z67jvRw6nU8VlEHNQjqot5ifQcv8cSp8JJwW7bQ5FZ5kmpx9ntwmy6zdCsu5/lsAIwskG2OM4 Nbl07I2gu0Q0a3JFflq+JTfIsQyHRIBhG19HnumjHssni7pZNQyUUw30fEiqI7CK+W5koXoTY1BV cbGoqqms5+8uYHF9t3oT8ZcnzQqBLtmSCIJuJOmIR4wSzV5/FEXd4SgK+MBYdZFVd6OqipM8iSQL jVbDwwn0QP7s+hJYfVR14b5z09D3+jZ3yavmdtTG1i+8d+jKV/GEL65Lveje+efXDT7hP7Z7eveF L5HvXydPvCx62jcei0MoBgiCGrCNAUJV40lDQ7QgKiRHE3aR5u0NWZVAKOPmWYbxAOGrPMcoov2S jBSRBsyGxXAlTM2AFGlL7vGhvOu1HDwC7bhRMwKuCqeJ2g2N0kAIoyAOWzEU1oPRjGyAlw9ntM9v 5FH+KkFk6kHPMjUOcVdrwJBXWdaTYXDM4SDsDS3TpseYGkOCwmCKzC7mMDPN0ATDM981lzXmNmNn QjGtqJEF7c/SebQF0UQQkgEae3IK0yL0uMmbkyB9zNU/+K/Vu3+E7GHhXV1S3jAQAXNiGgUZDZnr s2NftxjiACgLUp0wR5ZJmCFL7aWU/j8SxYxqtSnaF/C1+9ANb2z9wt8qJe/+/eivZ17dvqJf74fR gQ+0pMiD1NDC9qeCCUpRULi4ijyweUg7fPHJrvxAh+SMuDlfI1cszWzfDGkiRhaXU9cBSUWin1iF fmM8muCbuEousc+5P38k82HDOecHmbOF28q9hxob250lupvuja22OQC2GWdG7BKHxZ863sgec57K nxpsMoaVAYnNBHmC6rEr3nKG1RhToTdDsZcNT3fZSKb0shEVwfiCerGM8L9nPUG9PEc1GD6vF0PU 29J5lGFaNJIytFadmqMiBgMV3HpUsw8lW7hhE2qeCvZGI3zb2DAaHg72zN2vmdTL9qCetuCUnURT oh1puLtRtJHJDRjwEhiuog0gbkAcIAeGJR5v8uYmjzhe5El+jrIZ3qRehKNIHXG6qJO6ISXVHP48 EXZzRjqj57BA5nLjuZ/lqLW5Wo7MbR8BeWwqKcDtzT6cb36+Ciiu24Xq5LdQI/PmtqpaQO5bUPtA C2vzWDPPqybmVSyO4UJ1jy93t1klIGxVBBOXP1AXNCkZs2x7Z5u5Yce1gsm40zLYtrfZrWfazAqi rFZcv0uSv0K9s61CcPzCCnoq399Z/t1nayZHH9/97k9qm4ae2vPcD/a+/MXp6oqetWs6+tbmY9u2 St0v/frN41z4BeqdF1vTHb1bjqyz9WaUAlkw3nj8Tam19Yli4ZGQMTW0p9g6/eyBy+Vtc78cf/H4 7LLiN3fcYql93YrBkDvqx0ppOUE0dEEvz6Eb5wj6/u0PmroLJipXlnTbcpJcW6gVSLvNRvvpJN3A sYRM5ESWl/kc7ZlxXXCRYUQIiuiaI68bbjmliHJcdioiG49HFFGaIz83vh9PK2IuHkdheJUIbm2w y5LkcrGNDtGJnFmvYEjLKoIx9LAuGP0lwRiEq7sHboqtYFJpMGoejKyAgaoVDN6tfyogTkAx4VOB 5AUk4JHKc7GAxMLpAqkVJnAkyiX8Q2bhKNPDaaaHA00PJ5k+VzC94YKiLxCWPMumU+YWfLHbKaSl LqZqKQpvzXb26KYHTJgevpT5qLNF0lOh/GpLYuD6gcoDzqn28fWhCKgKBjTMVw/+sJgHdoIuAtRU wZLO3KYwJaGqqQAkjMymimR+hpepuEDxWHeCn4U7IFGXEeLAhPmKC+sDyVtZOn8jpjVUnYKaVaFk 3R2WCIcpKwAU1wFs5jaHMdqOae//9kCY/2lk19CGH2fS/YvJtpDHo4bTq3Kc0LuY7A25U2XQ4X9/ dHDLvunFI2Mlu6LYpeZn0Ikf9kqdQ4tNW0KyQ1HomH+MOvuc7kiAVsiCbIzbnieaiAhx3fBHd7kD Fc5NeIiI6OY9fIQOKKIHi0SZVUQ3XsSDihj5GH0FEp6GX+vWO/QZGtEGgZgI7XE3OnEMIrBLOHkn 6TSoDMNwrMiSbDYYMOD4AA5GTwm72VhcN70QML2h5Yv66QD6L+HlHxu3WcZxv747X3K+nH2OL3c+ 5+y7s89O4jgXN07TKNedry3J9UfSCEpZUoVm61oEK5B0HaINcFnp0JgQQQU6TfyxappAm4QWlq3N H5MaqYJuaFIjEB0IISLRiXUj0oSqCgG98ryvL/05iSjy8/r1e5b8PN/neT7PQhKRIS855ynjCq0q 08o5ZVEJFpWysgCLFWVNYTJjK1BQIHA3p0hR8cPG31hvdJbyOqkXxNUWutsrNrfe72fwqVGZPOB5 k5Pv9Wyvhx9RxJ5toaNkw/MO1IduyYcGgrpO55OH6DwswW+3L9eH0S3o4izlUH/Bg+EnntKWcqk+ dKT3iHO897jzvHiq95Sz2LvorPSt9bF9hGJicZdyeIfu1lUHj64xLfVR/gWBc6IMdiKcuQCew85M LAcCnkjJvJyVe2VPHpen5Rl5Xm6WlwPhJcOyiJ+Tn+bnj7ot/Cwe410Q10VrzaIpi7do6236KrWJ /oA0aZ547Y7H+Gv12XUoutYUdtx6w2tTs9SDngszjTXpvrhaJjfKpWnGB4g7n/AmJsvlyYn34tJP T849vbXT6EY0z0vJHBNBAWR9JvTkRBl7tzxRL/13y3OVLx57YqS7YttRPtGkxeMdBXHr15Pr9Da3 XAwXoBZaoFIdaiFPgbQErNFpAS0KiAtRDMWrIZ7heYYFRCJKBVYKEaUCOvHYy20a/JIJRagN6GGx Dllfh9gs2a7LNvSIraeBIBdZtMAiiuVZmp1ThXPCohAoCmVhQVgR1oSQgM87rovtebvHjRM54nJy nx6JFDdkCPvoIfEt3RXdnv98447UAu88jqUGX7+HopingUKG6TFPHaGRIKheRBlo4lqpEjWstkKZ GmbQ5gFJV8Vl+v0387audsDCE/MVXS1peU5XWzXNM1FeV81l+o8XNG8IDejqEKy9Lm2brg5rWjhv b86FUVApbToSVI5EIsEwNcyUhjpMsTVS9aCzE6T4vJJ3qeq56mJ1pRqsAmjGOE7laK4rLUGTkHBH eEm6KF2RAp60INHS9Vy+q8eGRzZ5ZF+0r9gBz16wafs6xQ2oA/RA17YKwaBM3p2urFXoc5XFykol UITLaiVQkUaqy/TnlnK4hFs+WZL6TVCidGvDTpXGMFbOYnbAwyGuAKVRmBnX40KS0AIOAv6/W8nJ cKAXHTnDtoSYXqPdcEI9CmLCGTatoGhLkdmkIDmq+CMCX7J4HMpn4I/aue+EJ6jZpuZsk2KG1Oac SWVzTWGEewbUdDJg6tPVtSrNRPWoG/WqV9nQ3tDeprHmvexKNbSF3svsjf6bCWK6nT3mj5VVkFRb hjh6iU+UoR78awnaCrHQbIDKP7lj4y3+Plhyz7H+Pdd4zjd+Bxbf/4odpO42OOTPqQl/Lv3/7QdT N9kK470HBPzu6HfHJk/mxn88/thTtvlIPTMoC6KVsR6148lKvd20ObEod+SK/fBMIV0q8Iu5fdv3 7Z8cn/j+2fozR13oSiFTfgyd+faOXLlcjxxOF3AWaM5n0ZmapyfU3fXIoTJDetdRmie9yyekAcgL iw5iQvrwLXawmUE21tKW3f3jNgoBHRWYwJ/oq4E/pAMJph+4KXAV/VWmBS5G5ShLjfE53nqdu8g1 Ibld1FXOpyUDCEnLR4CeCC1lMS0lNGAoS9Ny2SzHxSLSkVAgGJaX0cGlVYTQ8u23vP2pfnSCoiwm QvgpkRAxQImgfU5EWfGKSIsYpkQAKRGDlOj1b4YL8I+Ic0PESCVimhIxTYmYpngRiRihONVetOmi PQNpA/xkN/iJWHiJ3eAou8FNdoOn7AZPEZ9wwFF2O0epuO2bpnEHpAxUNFaMVSNgNEDKaICU4QOU 7hpS912AIvzE3wNQsHNj6q62SDryDYK6Yc0CQJXWfZh6iKKyPkVlNyiKwxSV3aAojsy0mKI4TFHc gxQF0H8MqB9AyqKgsjbU/ClCflizl6qn9xz4psiDJM3+JC9Y6f27zP662ZDnibGRw7sHX67/5CiB qIJ0CJ17qpSbq7Nf3hK+T4bgzF23rwUugA5bqBza56Uup5EZRcIXmmJGC6LCSSPc3MRmvCDxN5TR oGdYLhdEwbSGP2h3PzEjvikTszS41cXW0zssd0Vb1WhK87RpDS9DnvaSRmucoAq04K2yiDQueC+x 8Gpsz0djLivl4R3zb5r9W2Zx5fSDN7o+NcZv0O5NCNXoOuUHqLROyuEOlOMLdEFVsgrNiK2JVpph DLk93S61BxiuRTDhKzMKamsWFCoVzpgoHo2ZSAnEFNQaSSpUeyhpUo0aY1ldVlcXVEwohk4HGkQ7 0U7+RDQ0w9SiNX5GmmcWogv8vPQO/Rs1UgvPtMxwtdRCeL5lnltINaEpamp2AqY6hKuTiMc3ut8V knmGUAdgxwAEFMfTQPWTv/vq4ZPv//7a9St9O5MxttpjK2aLaBTSgUvf+fD5y997GXVcehdZI6N/ ++2TUyO7pPzWgyj3Wi2TwBE067uCcBBGqCI67klCsYljqDAVVxk+zMeZ1qIGdKurYQwTLOYL5tda g4c9WbNPJ8NxAdiXKRgqy4RjfCfq9OS04PjxxWZpaKuLrdcLWTjurDp0r+M5486ME3SEBpa0CF4U 9Ua96Hh0JboaDUWl3rFZQmqzJFmi8Boph6v5ylIqS+wbSRWnwwRpf/wUjio56vhHncZR556jN0EB GErWfUbGCRnjcb9stMOs0Z1SpIJlZAyz0J3qNJGhwKUrbZuoo71gUlQjtJbf5IZ0rzziavhSS9WU mlHrDh4Xa9JM5lvajFmznhV/oJ0VX0i9qLyY/5n+c/HV/Gv6efFtXdiRQBTEdgreN1GABG3ruzdD cwlYkrYkYuIEuiTxxpwJ+YxeT/YO3/qYUBN6zunbuf9Lrz564JdfGd2+aWD/45s1d9DwDlcO1l+p uqlCgc4lpwN/xuQ+V80WT31w+ocfz+XTr5wc3PePf04MncGMtZuiAl8DBXQi04uwBjvIilHeTyko yGD/viSrrtVgPrDzb6j95Daj+NscT6xnim0ub6Gz7I8smpVa4i6XoRSqU83wCt/JoMT/2C7X2Diu Ko7fO6/d2VnP3JnZndmXZ8b79D68a5xxbBeHnTRNolJiO0UNtWCTVHkQGiriRK2ahFDRGKyq0JRH otIIUYrUqHwgxS7JtnzAkUoACSmRKKLwobWQVaG0Lq3iloTIXs6dXYeispbvuXf3zJ07c8/9n98x TBOln7ctH1XNy3a3j6qZrF2k0dSdCQ0onjUKipcaqitfpkkGFQWrO6Q0UOhVvAtxeNfFpwNXAwsB FuLxVU9CRcW0oVYqZdLteEv72cB1fZt0fOtFNMOdT+NDaYzSJM2k/1Yau2+tCmij6vJyY2mJLLZr J1CDcpkGR8APDhobUAp0uBYQq7wmt+3aoNBGAyEaNenJ9LWWbmQh7wNC4zsbhzdtrA6OBUJd3Yli 1MGBcG14NbChHAzl+9lzr39v1+b6ps/exQlGuv7Aw38ZHiHJOAtQMHKM4SeMVIKn+X57a5F5HfZo gJnxviT1R0mdI13FCOkuckLEiFzOXc7/lVwjN0mgSHKlYbK+NCOdzpzOvij9LNOUXs5IfJjvChaj 4a3SPWHBk7wwow3Y6CxjY0zzDvYkrf4TmszxZk9HZ7UafOHWrpdjdvxs0k4kqLCCy9MJnGjig14m fta4rml8vhzQrLwmdc6xp0Vd/EUN9ZAepoe+eklS3PYoLdNxFcTalrGcUFxcc8fdXe7X3Mfc867g akrQDjJBDy5o99KJYi+9K1yh9OJeP02CtPfG11FNp5I+Vd62CPUbVYhfBR3IkkG/LoQLgl6kpx4c jWagMXIwhKV3EifNAB8dBunvXNjjwOPDWhc8EWbo2QlX05XPwQS+hTl8C9NQO3t7pvLkoj+DF8de bwzeYEqFhiShkU1ouoy24ySUlvRGlmUpdavZ+vtcONK24EHtLLj7jr7fK4gHntLAl7fAkbfAi4+s uZB3acWKydLyEiLvUsHzlJoXUus1T1SggWehbtSp7UXvnOuDpcE5vjrXtvCowBW5PiAMGP3JE6GT 6wPoyDVbH8yBVoJdvEhlNgVC+l90nkRTcBSoboFwYT3jczJNR9xtpYKjkGHX0fwEcgVHo5AfdOGo mPSLIeaHSnrDyY3FOyIOzjfGntqx6ZAl9Rg9JN334y39G0YP/KjvztPf/dzWpKoZMfbS6qWnDgxl k/Hi757cMXZmoiQN4Inp6U+X+rdsfXD43j1fPZ9TFEhOKN+6zpzhVlAcPePJp6RTYcZvpDCKN/EF 2B4uEmGjJxksOFK/5EmsdFjcJ0sM28Sy181LF8KJJOY4pPA2z/Al3YgejUR0D16+TuOJQG1W0+f1 qzqrxxNUOSD24PUCCC77rAdwN0YgtcAQ1VcWG3UozCjyLY9i8geofKfQFFbXRTO+zg8MmW3RGFQz oBNDuPnmm0qebLzD2n5h8rgaOvaNX97Jraz+fM/Kb7bXuvcY83s2pM/gm5nJ145Sra63FrlPsedQ Gn//FZSF1b0AtJ+9mmXEcDJcCt8d5kbCz6ZeTDVT3D8D7wWZtCd1uT20UXik2zzRubcCuBXAkMj5 TEbJ2nomY2XtdCbDC3wovk+UQhJKp+EFCEgodbKzJVB4F4DmBQB4gQK8QNldoNguUGwXKMULlN0F yu5XBKwI2BGuCAwSiMAIFORDWVoTZIHhsx2Gz3bYPdthd2pnS+2fYeZsB+Gp9eIAD/NZbGdfyjK1 7KEsk43YURwtKVRX5mBiuUPwcofg5fZkvuzoAPLvy7gmz8tXZVaOZzpI3xH10W0U6dfIkH6WGx8f 0RSx5DM9/PnE6PN8Y4rmBgAC/0wcLuMOatOjkM93cnln19cP+UP2j70bVk9u+vbnx4+XCp/BJ/Ri MtvdO0y5eyV7EID7xMTdDzz+PD5CAXvlm3vvsPTEOF7uVH060PZ7sPspPO0lNAYxWEMa5vqtSXMy NmFdDC9Y71sBi2borkGLPng+Zbt1Y9zYIbABOWgHOBObyZhttncF87ZgkKhtNFtPeA8qKOUkU6kt CokoCsEI7VRk6MkpGSNOIA4IBKFi2U88wpCkqSSJImM+BUkvEBCEFJKS/yJH+xVPmVBYpSFfwx5c 4qcXBz+HGRpMVzCLJ+jK5kbHXX+FyUzBtbwuxSXWbus5a8HiiIVfgudguoET2LmeS3Diyu3dWJ6C c7cSX24sx5b8XE33QzNHsKqNjMBP0J2pluUT5LUZvhrzO+UYIkuYzLfbxv8af/MatBzzohZdrEUX yxA1Vce0gdhZmI2M+CZKzY1ZSanjNTnkMVU4wDXI/yCDuu5rHowFAQ7YO6u/HXHMPvxBTY1Vnj0+ 2DeCByrDw6u/TzF/PplJiLmcali5/as/xbXH19sFJpcT1k+vpOkpV1uL/Czsc4X5wssaUnEF7uyd 0yIuYhEnGZJJEGEJF6hFakbNrEfqRt0cj4wb4+b9/P3aDushfn9or3RAO2gcNPda++1HyDHthPF1 84h11Hm0cKr6TPkN4R/obfla5Qb6MPSh9JF8q5IXQoIkyBzhVc7yqhPV3VURY0bTVF1HISLZIUBj O8YVcKHcaxeQSERG5IK2aOoOrEw3bDPv5Oy812w9MqeyDFSyR7yv2KjilCuVLbYTsW1HRyISbAbt tC0YWhwrspjdqZKIqhLQGcRsUTXoa4RjGU6sWLqGkaBKDn7HueUwTrlglx0bvlUJh0OVQj5mhkSh wjJIqtKYrwxWfQ0Ydn3r9PjWi8UTbtWTZBfBMzHnq7hqmonCw47dxH0XvN3qIZVRf437kINE8I5S 3hAfE1si2y964oTIivG+apPZ4UdiE1e+BfUkFY5EHFQjEVtJxFdiY5v33fV2oy0YtKSkIgGf26E5 BT0VgnNbtRyEoORnIDqn5E/2/IgtJz4es+X/G7rtdoYER4OjNMU0GiBCPj1YrYU5YBTSvG1vAB+M GMHIiAn/eC102Qy7Fr3t4PV5lcbuJ0KZXWyhW+7N4UJ8HX6jP+s8MR2y+mr4rWGre/rRRH4IR6vr y6v/TjG/WLmXeeFszZFzuZSm3rf6A/xQ7J7/sF+2sU1VYRx/zr29L7Ce3rK2a+8t7dno7VpWbu86 28LuOldgK5OJQFgiGAomBgcLErcvYIKGRAOifCCY8JYYYH6AmMVEDCiIL4l+gOgHo0bFECBCTCTO 4MKLiW743F5kmEhi4ieTe5LfPef09J7etv/nOf9ntpxM8mq4oQ+ny3q1lO5BpRe2Tqi20k2sPS6h 0i1upNyXih1gnDbTb3H1R+PEoltaT1l8vS/Imtlmbq/vYO4cuVSSsSyV/WF/xBMJy1IZrQuTlknX sSKQRDVfaE76daLrNbuqdOnFhGhLYFtA7TpYPF3ksgYxY3FGzZiPUUsBg1iKRDExqjGNqbqRZHrR msuKp0VSy44RrC8iCTaLJQpmnhWycR+mwto1oR4yR01utbnLPGPyZmyfMmqdsfjV1i7rtsI/ruxQ Dll8rKJYmEItw9YjCgv7s+XtaJKvGGSFsc0YNb4yPAapp2kMIYGESJIMk5eIsJN+wm4zvp+9yF5j x5jnDXqB3qL8q+QAeZ/w59Gnr6EsSCmzyvWJLoUoVDEVy8MIo8xklscyDRZTKJHFeyO1WNATohqR xOmHSx+XuBI+0rvKjHwJg8H+jU6i48RjWzxNfEBI/Li5O/YBiYPBbYYOKHGVd5rG7UR8Y+zWBLqf muAz1Xtaryk93D40lNnhQ5FX7TaUqQmSoBDxXyK2IMOG0wfTTq/Ea/1x9FqOLlH/KGXcBIMBt6hN YYa9O/K3VH7/lVQftKJgq2YwQjAMM8+b1UipdLGE461mNRPBIVrZIagdAFoh05PhBmFD3UB8MHuU jLLRxlPsM/oTnY613yr8iCoJNIT/qu/yqVSt6LNPd3wF3e1c3gkgqXYYYKk7974Y4jaN9Oei5sTt zljj8h5TlANNcyb3dA9tXHJk6WOtnBjNywKvPtK8LGGQvs7BBVzn5OdHMmEO68CGwMzS/nU9NIBS VHS979AwadmzAIOI1Et+xS+ZLxc3zQnFhGSSW/R07fSYrPBjGFMmeeqEQhnlvLblfysQethDgmQx LKa92irtiejK7KA2GF2f3Rl9L3o26ksH0sF5ME+rQIUOiAPSgHe/eQyOad+qFHelJvWaPtErMTGk NrCQXyAC8TCsTAIs2BJKpfWMzzQrmhrUNNVLaQTLFroGSBCoracmU1N91AtSKGWCbg+JIGj6tczu uKJfi4eCWD8IogZ1T+Yu567n+JwdtTSYzudQnkrIDHEhNAPlsDB7dmMqn+pO8alzTRkQvkDHrrbm powCpuYlNyaqV9GYOxodvmcUlvjHusbGbDGhAIjd17fvkLMZxzD47qZfcBbb/8k3OFdJ9jtZ1066 VTQBD8qbnGQbwVoBZAvHsYFkfPLL7vlZ8msu3Xb4mY7cw6Q9a3VP3lyX61m/YmBRvq2TEFlWItF0 sZk78Xov5lJuVqT52ck9JLqvIzkHfYLQ+fZE3+Qfpf61C61Hywub6+piLXvhbtv4HxlBxqcgn2KG 9gJ4VgMIWQDxFwC5BDBNvI/tD6auzcGL+/j6HZTfpvD/MMWMqwCB7wBCJwHC3zhoaYCZrQCx7wHi PwM0bgFouvHv0S8ANL8JkJYBWnwAmVEAYyWA+TVAmwXw0DBA/rJD4SLAvFsAHS8AdJYBuhY4lH8E 6OYQ/O4VfIZevLfvQ4Cl9QDLvS4uLi4uLi4uLi4uLi4uLi4uLv8bCIDgh3EowQYQgAM/mDAfQHrl zh3gcY7rwB04+NFz59euVUo3ZVUGu41cKVTs/njfZfH3nRO7/D1yAafT8P32HfDnACxEMjEKZW5k c3RyZWFtDWVuZG9iag05MSAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50 IDg5MSANL0NhcEhlaWdodCA2NTYgDS9EZXNjZW50IC0yMTYgDS9GbGFncyA2IA0vRm9udEJCb3gg WyAtNTY4IC0zMDcgMjAyOCAxMDA3IF0gDS9Gb250TmFtZSAvQkRLQUhDK1RpbWVzTmV3Um9tYW4g DS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgOTQgDS9YSGVpZ2h0IDAgDS9Gb250RmlsZTIgODYgMCBS IA0+PiANZW5kb2JqDTkyIDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL0NJREZvbnRU eXBlMiANL0Jhc2VGb250IC9CREtBSEorVGltZXNOZXdSb21hbixJdGFsaWMgDS9Gb250RGVzY3Jp cHRvciA5MyAwIFIgDS9DSURTeXN0ZW1JbmZvIDw8IC9SZWdpc3RyeSAoQWRvYmUpL09yZGVyaW5n IChJZGVudGl0eSkvU3VwcGxlbWVudCAwID4+IA0vRFcgMTAwMCANL1cgWyAzIFsgMjUwIF0gMTEg MTIgMzMzIDE1IFsgMjUwIDMzMyAyNTAgXSAyMCAyMiA1MDAgMzUgWyA5MTkgNjEwIF0gMzcgDVsg NjEwIDY2NiA3MjIgNjEwIF0gNDEgWyA2MTAgNzIyIF0gNDQgWyAzMzMgNDQzIF0gNDggWyA4MzMg NjY2IDcyMiBdIA01MiBbIDcyMiA2MTAgNTAwIDU1NiA3MjIgXSA2OCA2OSA1MDAgNzAgWyA0NDMg NTAwIDQ0MyAyNzcgNTAwIF0gDTc1IFsgNTAwIDI3NyBdIDc3IFsgMjc3IDQ0MyAyNzcgNzIyIDUw MCBdIDgyIDg0IDUwMCA4NSA4NiAzODkgODcgDVsgMjc3IDUwMCA0NDMgNjY2IDQ0MyBdIDkyIFsg NDQzIDM4OSBdIF0gDT4+IA1lbmRvYmoNOTMgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRv ciANL0FzY2VudCA4OTEgDS9DYXBIZWlnaHQgNjU2IA0vRGVzY2VudCAtMjE2IA0vRmxhZ3MgNzAg DS9Gb250QkJveCBbIC00OTggLTMwNyAxMTIwIDEwMjMgXSANL0ZvbnROYW1lIC9CREtBSEorVGlt ZXNOZXdSb21hbixJdGFsaWMgDS9JdGFsaWNBbmdsZSAtMTUgDS9TdGVtViA4My4zMTc5OSANL1hI ZWlnaHQgMCANL0ZvbnRGaWxlMiA5NSAwIFIgDT4+IA1lbmRvYmoNOTQgMCBvYmoNPDwgDS9UeXBl IC9Gb250IA0vU3VidHlwZSAvQ0lERm9udFR5cGUyIA0vQmFzZUZvbnQgL0JES0FIQytUaW1lc05l d1JvbWFuIA0vRm9udERlc2NyaXB0b3IgOTEgMCBSIA0vQ0lEU3lzdGVtSW5mbyA8PCAvUmVnaXN0 cnkgKEFkb2JlKS9PcmRlcmluZyAoSWRlbnRpdHkpL1N1cHBsZW1lbnQgMCA+PiANL0RXIDEwMDAg DS9XIFsgMyBbIDI1MCAzMzMgXSA5IFsgNzc3IDE4MCAzMzMgXSAxMiBbIDMzMyBdIDE1IFsgMjUw IDMzMyAyNTAgMjc3IDUwMCBdIA0yMCAyOCA1MDAgMjkgWyAyNzcgXSAzMiBbIDU2MyBdIDM2IFsg NzIyIDY2NiBdIDM4IFsgNjY2IDcyMiA2MTAgNTU2IDcyMiBdIA00MyBbIDcyMiAzMzMgMzg5IDcy MiA2MTAgODg5IDcyMiBdIDUwIFsgNzIyIDU1NiA3MjIgNjY2IDU1NiA2MTAgNzIyIF0gDTU3IFsg NzIyIDk0MyBdIDYyIFsgMzMzIF0gNjQgWyAzMzMgXSA2OCBbIDQ0MyA1MDAgNDQzIDUwMCA0NDMg MzMzIDUwMCBdIA03NSBbIDUwMCAyNzcgXSA3NyBbIDI3NyA1MDAgMjc3IDc3NyA1MDAgXSA4MiA4 NCA1MDAgODUgWyAzMzMgMzg5IDI3NyA1MDAgXSANODkgWyA1MDAgNzIyIDUwMCBdIDkyIFsgNTAw IDQ0MyBdIDExNiBbIDI3NyBdIDE3NyBbIDUwMCBdIDE3OSAxODAgDTQ0MyAxODIgWyAzMzMgXSAy MjYgWyA1NTYgXSBdIA0+PiANZW5kb2JqDTk1IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl IC9MZW5ndGggMjMzNzEgL0xlbmd0aDEgMzU2ODQgPj4gDXN0cmVhbQ0KSIlcVQt0TWcW/vb+z7k3 kogQckNoTtwkyMMjVLwSqdxLSjNNNEaixuSKPAQVUzSypPXoIImiWvFuq52WCs0NQpi2UtWh1LLU IIylzJRSpegoS5J7Zue2a0bn7HXW2v9/9n/23t/+9v5BANpgARQCc+fONkzHu2tlZxNgLckvLphR n1HbAPh0BPTEgunz8vd/7JwBRL0K/D6+MM815bOqMj+gMlbODCyUDf8y63igbaasIwpnzC7ZsnPi LVmXAAGjp8/MdVHYVB9gfr2sM2e4Sop9dtJyOe8v9kbxn/KKF7346VQg9DDg26CvEK/PIEzermoW QgDzirzXW1/PaLNZnwa7p9D8p0qS02t+fX95IrENK8gPZVgEJ+LxFxzDNBQjAzUYhjt0DqOgidVL 6IVktCCYXBhJCbJaAZt5TL48b97ga2Csx0LcwxycRS7+Bgs2UH9EYBC+QqJZgCC9EQOxBGvMf8Cq DcD7aDQvmh6k4l000jB6Ti3QkzAepZiP5WSjaBpE8xElMZTgEzRwYJs6+CMNv0MmslCAPRqJTx3p qKEzKkU8ZaGSnqQGcwcMiSoKcXiKBnKMeQBPIBoDMBTD8We8iXU4R70pUfXT9sMmObmwnwIomLrT QXMTwkTSMFEiXY4qbMdxHKcwyuQ+Kkf/0HMdAZgpEZahEmdwl3xpPJVwvdrpGW4WmbvNw3I6Qfw4 MFriLsNayW4r9qIBnwkmjdSN0mkt3dZm6/EtCz2nPJfNYPMu2kms41CIF/AKyqU2b+EQLuBbPCSN fKg9HeK+fEEFaG/pNhPm0lYGoA+eErRKsBTLRPbLiS/IoJ7Un2bTWQ7gdjydX+Zq/kGVq1r1L+07 M8XcZn4umN+AFXaRKIyVqpZJ1VZK7XbgI9ShHkfxPe7g34JkEVVSLdXRA+7IO/mM1qw36nfMzWYz /ATtSMSir0h/QXAUnpZYXsAGqdSXOIGLeIRHFEqD6WVaShW0gtZQFX1DP/MSPsmXVJX6ULnVUY20 eK1Ir9QvWzKsLk+VZ4M5RrILkn8PEN4kCYZ5wsUXhRObBMdd2IeDEtsDNAkuQZJtBA2lsVRC82kh raR36DynchHP5GJFqpuyqx5qmRamVWuntAt6qV7pifJkm73RyhtfYcNQiTtL5I/IFy+lIpWCQw0+ lmodEdbeEDbfR5N4Y6mzH3WicOpBTpFxUvUsmkQuKqQyeo+q6QLd5kAO4e68kt/k9/hr/k7NUm+o jWq3Oq08mqn76fEiY/Rsybdav2cZZym3jrBOtm71+aoluuVoyyWPv6eTp4fnOc+rnr+aWeZc8yVz i7nV3GnWmA3eTlXC3W7CL0OkB3pL54zBM5gk8U/DLOFkBVbhdZGtksNu7MFhYdwpfI1L+EbkGq5L ZW96c7qPZskphOzUT/iSQBNpMuVTMZV6ZRGto/W0kdx0kBroGJ2mc9RIl0V+pgf0kDtwEPfhBHbw KH6Wx3Iu53Exv8LreCN/wPv4AH8hVT7L5/gqe1RXqYRTpao/qEmCyDy1UG1R+9Tf1RnVqK6oh4KN JjUK1+xapDZEK9AWa5f1noLTFL1If1vkkMXPUmSpsey2HLdct1qsPa2p1nTrB9ZdVlM6pQarpUsf e4Rx26gXPy9RKvqc99AbdIJ3abc4gLKpVIHjtFjheBqucbmKpCRVQqHSx6/haVaCYQBv5lHC7tZn rHRxf+Fhpn5a60RbAV5ChTJvTgp/xojNMhxApNmI9njdnIY6sklH5ZnrpRcW0BhqkB4q4Fn8vdas AoWhV9R54c016f0BVGU5jokcI2xLxNsIxmCp5yXMI4N7YwLWq2VS6XB0RrQ2XZcZTvfULmznKi7n PeaXDPwgc2+CNoqgXZa5H40wuomPJLZjfJrLqU6z0BZ6VmLoqnyEH0cQwZuRp+aQxgv4J60R53kw T1CxdE/rpxTSpU6LkU03yQc7qIofUjjW0ALJ/ird5KuYjZ/I5Ba1kgvpKB2hYI6hEaovPHyFJks0 Ebit28iHE6SPLMKra7xd5dNGnNYPqYtamtoLjT6lBG5WBjsoTQ0ybyHS8lC19ZwxU+Bg01yt+bX8 KOjMwnnzsIrTXNroprqmk2yj1WqGnmXe85TpizkJ+foNayLmcYpMiJNyF9Ugmn7kLoJ7mOwMEaRs 2qqmJs5AN75D91FCK6U7IiSTTJkcNSigbWKry900XG6BR1wtUzNNzZE5sxeHhe3zZbYHca7cM4U0 Fiy3hOa9DzYIG+5qUzFPbv90fCK3abVoT+jvJycnD09KHDZ0yOBBCU8O6B/fr2+f3nGxMdG9evaI ioywdw83wp7o1jW0S+cQW3CnjkEd2ge2C2jr7+fbxsdq0TXFhFinfWSO4Y7KcWtR9tTUuNa13SUb rsc2ctyGbI38rY3byPGaGb+1TBbL/P+zTP7FMvm/lhRoDMOwuFjDaTfcJxx2o54mZGSJ/prDnm24 b3n1NK++yqu3FT08XA4YzpBCh+GmHMPpHjm3sMKZ45Df1fr5pthT8nzjYlHr6yeqn2hum724lmxJ 5FXY5hxSy/BpK0G5u9gdTndnu6M1AreKdLqmuNMzspyO0PDw7LhYN6Xk2ie7YR/hbhfjNUGK143b kuK2et0YU1uzQaVRG9tQsbw+EJNzYvyn2Ke4Jma5lSu71Uf7GPHrcNtKvw3531J+3iEla+njX0NV hTNkqtG6rKhYarjfych6/Ot/aK8aqKiOK3zfm/d2iaKS+ldBZckWUBERqIpE66JZqpLEnwABDrEr UWvFBBPbGG1JSIxtz/qL0VSjpklq0hxomnXx6KKV+BNB26LVlHiOqSY92pNYi1qP2pgSpt+dfW8F bBvTcwr77Z25M/fOnTt37p1N4O/iYuiArJ6Y6/PnYulV7MSvp8EQNp+3Et7UXLeXOb4FrsBd7onu +f4FPpxHrD9AM5cmBGNjPfXyY4r1uvz5Re6EwIQ4d/Hs+wbu6EP+mUvrBnhcAzqPpA7fEXN32Js7 evayGtE9OjbmRsZUS03nVt7MiDs1tsg9BVEQcD3qgiVFbmwki7/mZpH/0SxMw1+xBqnAHBzD9wJ3 TfL5Y7KZz/IBMzHG7fJfJxy7u/VvnTmzLY4jMeY6cZODIxJfGLfbgZSUwLBhHBfOSThI2Pgt1R+V OvypkH7JvSjGBQL30fQiiBVnp8HnCQl8qitDHipDJ1A1oyjcd1FZXJA8aSnFAd3HI/vtkb4FPFJl j0TEfW6E707iR3zfQFRS5NMrpl9v7/zsgNbvvwzPDY/nPeTOm1FS5PL6fZZv8/I79cLjWZExqxXo PalIxOlWS48TahSRWBqZzJ2i6ICRiI9DRfKckDMKoag4mis3EOObHP4u7paQcIdCIXmFpRS5JWaZ GchO6dy/t1O/k3nRfgGDjSQ9L7/E7+/WaSwXacfvz3W7cv0+/+yQrCpzu2Lc/no88QL+RV6ffaIh uWdlXCB3VTE2MV/LTlXlGr+eEtq99HBUeZvZ1h51A79dnB3ruah2jNUGcku3UUMvi1ItySB6ESh0 1NA6x1gq03ZpPTC2Sq+RCQZp95jzqEEneRG80ZDz6mPlXsxfBlQCLuA+wANMAZ4DPgUeBO6FzDLg G9DxEnCEKfiNzlKabZyTW4ETZiH5zSZ5CO2TwDGzidag/1usv1+slnvMQnnUWCwbHDVyH9pNGF+G ecdBWccJ6OtpLKa16J82zmmEfdwEfwl4Ici1iUHUQx9Lp8UgmSl8lGWQvKzXaPMhNxIYLVYzj5JB PfrY9i0YP4r+UMgUof8q+H3Qngb9bp4HjMOcwaCp0D0Melsxns98zB2O/bhhdwgoxViTyKTVeia1 ikz5XSOf+lj7foX3zXu296TsD9t0G6CXdXs6ImzfLdyy7UtxBjb9EfRJIB17adOb6W0jjRYa1L7b 0YdWMpyncO412mYg2phDA5yD5AbYONncSaPQZ8wCSiB/1dgqT4pr5MFYiuMlWg/+ZD0dMTaKgvoP 6bwDv26x31SsZ3KcwG/rVCzMUX7TQQcbf5Hvoc39ROcgrZvlp63sG+dqSoX8aKx1CXa0Gos1P/AD 2BYEqtkerJ8Gn/tw7ru1wvZa6Lkbsfd9YAT2VRmGPIcYrgYvB/MGRxE9a61zsgM9ybHXEdb52Dht Q/m+Bi+4GmoEbsCWJOAAUAm5D0HTwH8QdCZisRHzMzleERdXwrEp3+bYQLz/AfwxbLvaA+KbYyx8 b7Rl+jz6BVABvOAges3C85ij7gvHLNtp6W7l2OKYsakVG4f1WrybeZ8cVxZVd+8sJSsbsHeOrQjF vePYV/QC7jTTjTSFY5Z1RmiTygfj+D7ibJMi1LKH7yfyxhlFL1ChFevjbGr54lCErpa7MFbp6E/b jEzEfgh3IJn6iavIQWfgw8doKt9jYyO9rK+gPs6LlIaznAZdm7vQTQxni7YA+vbDn41GM20G3WS0 6PcYLZpp1soLRqu236zVn+H27bQr7LlMGR3Hvir/f4H+gVmLN3yt/KvZIqXRQuuxV3Je1EYCLpuC HwSqgGFRKdqmqHIt5CygGMTNNaDC8FC26UHM7acJRl+VvxPBL3AQ/K9RnvEKLcbv1h6iQEty1NJC UYA7irX0D2g5g/WDLorEUTjWsm16WyxZ1I7XLvQI53zOuzZVdw951aJFnfrZ9E2uDZyfuT5wjmaE 41W+HonL9aghH96Kz85xKm92iM8XoTO9a1x2oGeZcm3h/M61BevPwvrboOsN3r/Kj8hxnCM5z+HO P2DP70oj8jXaPuSH3SoPN1OJfa8BvuefYux+K48gD9NOlQ8r6BFHIRWLMfSAykeTaZZ5nFyqBlk1 1QjKX6pchvtk11JVR1vk2kgdHSSvhvOZPKzyzQFZz/dT1U3UT/NVrbd5lOJUXllMv1H3kO/gZ5SN tQrEr5Bz2+QS8NLFeORe8MUlKlFjpyheLIGcITdwTRSPUaKqj6dkhZhAE5TsCukxPkPdfhO1wtKn 5oCaGxGTeAs4fHRA5YISjhHqaedjPntnudzrnCUPOuZQozkd+ymjP2MvzcoHIdmo/MCy/WUq+8KZ L9eJG7Idc36vwDLlsl75Az7q6AtVm/lNAZ2OCtqo/MEyy+mTqCJ5nmHOp6ccn2MdrGWORy2ZKBvM ibJa5VYHatxS7DMetS2axnPcO5+QUsTLY3YdFg2UKCrlG2ac3A7fDbX4yZz3+U3C7w1+Q5i/5tov Q0rmBN5p3cjDMJIRl+U0T2wHfkK9zO14i4TkC+qt0EJDhCFrRCXeN+H3Cb8RCtR9qZBvmkEaxndM 2YA1+O7jPA4hlxYil+Q4V8q3DJ0yEHOj4O9pwFzAa/UPWjgUhnY8PEfTMZ6v/4Na0S5F+zt6g/iR 3kBj+B0o3pct4ll5WK+Wz4iHaZ84Jk/oA+ldPQp2vCc/F+9TsXaZGkUVHRBT8G5aRE3iiDwvDsmz eneaqo+T28QOKhfLZbN4kqaJx6FvHR0WP5NXxBq5VmxEjF6ng+J3coWRRe8a3aHrLDVqP6Yt+t9p i+N+isF6OUp/Fa2F/n4KyxEnkOsIZauN220u0xMp2rK3pJO9bKttp22jbd8a1DLLPt4361VymGNM pqlE8k9AYpi2z8CZlHBeVznLi9wThVz0CI3DeCzRF1eBnWhXY+4N4DzaTwN+tH8K/BN4HXgc865B zSggHv1vG7H0tJVnKjA/BbyFAOS+OIn+YLSz0G4GBhC1fQL6BDAB7ZsA+G2mhQKgF2QwT/Ja6Rbv MuZvBU6j/RroQ2FeWx3aPSy6B9gAPAOMVO/XLu+S/wP9t/XoTmmXOpTetaZ8Jeq9I9qpBtnn/2XU qi2lt1HLD/Y+Otjzn2peJ4r4abD+qR4peG+d15vhCYGmjFA0OGRoRnggNimjKqe32Es/B94BjgPQ ge94QBd79XcomeIxuT7YL05JhYITJ1qN0VnhRt2w1IyPcrrh8XcZ0EVI1NOQsFTdkBEZV3K6g6FB 7W7SAIHbEi92ieeC2fG9cvqLOooRQXIB04FFwMeAA8bU0UfAZUACBn1NvBX8F+vVHtzGUcZ39ySd ZPvsk/yS7USrh+9iW4lt3cmW60d0fsiBCOfltFh5OUCTJqSlaW23lDRV0tYzjadNp5TyCJBAB5hg h/gsxbGcuElmmIEpM5kyTP+AmQ6U1ITycHlMyZg2tvh2ZRooHfiHW+/3u93v9z127/Pd6sYJekU4 gw/hU+Dkq+hFOzYKaNKStJIkSQpk8DIxEc5ew+Wpiv1aJnstva9yP6R5DA+xiVeEp3E5iw97O5kK 6UYGoJ5DGraFo7omhz4lh6u8HFOBHLtC/9YcbIsJ/U0yOS0Ygq8WAv013ap2aHPCk6yhVjuapoay S/dkYJ277gXCO2mlXi+BIXsOB68Ix2FLxrgsZHMNmsx0W3dqBQw3bdX8DDf0aYXMRa+eB2A41A2a S+ke4KSUpjObVJ3uYtRIh+a6DA47kJ591yhVOnS30rRTkxU1rNmUOr0A4meyy0a1sk4vaG3Qta8p 48ol5VXFYlWaQau1aBWtta0trYJbKQeHF2qUFsUyJxxnDSl2ZMi0iLLk6ecpyaeNOqzqL2nKl32M NUSBVEojg+KkSAZtkzbiPwd8x7kGCPyGkXeO+jV/ILiNLSmZqtU5+NmmJFMeL3j77YwnqGse2AxW WMmLn9isaepavTMv+46QRPCjLLsIGAT8PZi06l6wTEd7NQ/DhlbNxTzV63wIRcn9q7qFDT++McwQ NpKDT3cDGAWrdb/aqGl+VW+B+ItGngrBHWqVTxu7AqGwkGQNqbCwehqhtgZb1CacIZPkKnmNWM4I k8JV4TXB8iCwnhcEKjQIUWGzMChYizqbyAI83EGQZ6D/CrqAGkBGoT/IR5NQQxhtBgkeEQHtJGjZ XZRVMdcMfkjD/j+wkBJSZAGaCQ28GJURjBqxgQnGyIEJsqPycngRuJx2ozOfHCEBFEYS7uAywmWV URmWng9LT4elA2EpEZa2h6WPhaW1YakmLHXKpAl5kUSqmMS3ufwhl1u4XGtUeqU/e6UrXulLXukx r/RZr/QprzTolXq8UqeE1+MWJKEOLhu5XM0kXrpQ1FeEHFfxEupDkjAFW1uKKClNqWGaISUpNQpg T3ku084KYoPDGgatFfoEdMsKCoha2DxGIfYWwO+jAL4H8HxKraMZ/IMcTDCfnaX4LFKZFf4u8mAF 8Dtogo9fRiGO317Bb6YC94PZNxh0OvDX4fQPQSCAzoM8klLrQX1/KvQw7XTiQxCTTR9A1ZwWgxJh GF0xC6Q8p+kc9iEPYUN0QX2MLoG9kqLv6Rk7TtG/V2fIRIq+rWYwjH4DulMpOh+CkZFP3wrN0xuh E/Rnaobgi/Sn6nV6XclYgDgT4sTzKndyzgOTwD8d2kO/op6mL+Z8j1Vz0lOwmRNGMX0SljQSmKeH wc29gYfpnpyr3QGewd03+agf8gHYrPPJTSpzXEw3hO6jveoE7Q5dp+sDe2grhfmL9K7qeRoJ8Fj1 AW5e54HFQSa1gQm6JjRB747M4R8hEY9BDxr1YlJ8SDwo7hfjoiG2iM3iOtEv+sQSu8su2wvtBfY8 u91us1vscMy0l2Sybxpw4MGoxCYzsFmYtPB7mTAJgn1SCLYTOJKZxUKcxPu7zEgwnhGz28yWYNx0 bNk5MIXxyQSOm9c+g+Kf9pq3+gMZnLd1h2kNdGHTFUfx7V1uIJvkmQxG2wcyOMssRqtMV/cAfLOw MfpcFcPE6HOJBCp7JOqOutY77+rt+Qixd0UG71zu4L9f7tXml+P9A+b46oSpsZvs6kTc3NDv3TUw S46SI7GeWfI4g8TALO4lR2Pb2Dzu7Ul8QIOCehxoUNSP52hJ5GE0qO4kp+3J0ShYA01hwGhnEeU0 is8yGpQZ401N0FjPFKWcYzmMJjhnwnI4x1E45+a/cKwyusk5N60yD1fOKdXVQAlVM8qUvxoIU9V+ rt56Rx3IqY/m1Ee5+nN31HpOPZ5Tj4M6+H+69nX9L0bsYH8Xjm8ZmLKjrkT3rhyWyYfX8zpwTncc q7qEVwm/QPnBhJkX6DLzA10oGnUH5XbcsNtWYNpgToTO6G0+9xNVlywItpzRC2BaWlGt61zXyVRQ zkxVCNNFKyr3E20+CHJ2RSXDtBOCQB3X90NdHoqZdXsBAj0J5I4d7IG/FRiCa2RkZGhoeIRdYKD2 x82OrTsGplQ1Zlbs7UkEY+6DPcP/Zf0obtaBUZQZiWLMNMBoaCjI7YLBkdwN+Ga3H76Gc3OcioJD H8xj5neIeQli2NJM9pdpzyr+1Z0O6m41qM/C763jUy6dkRN4aJhZg6+chyHuFf6/2S8raPC1FFH0 AsGLNjFD9hvFyGpZFFCeaFnEqMJusy7CuRNvTDtefgOeyq32pfZN8rvtfUvtKAr38m0QoUaf0+dU QMCrBN32CtduG1b0PvJarsGr5NnljcKY9SSSUfuMaMe42OF0ZfDxdBH6Hs7gWNqa1+bI4Humi7qt Fc6uWSIjdxBC9C0szctLC/JNKIdQI96NRXWN2iRHXLjcJtpIaQk+7n80XPPSDD7lnh354qXlHfJb 558Zw11Z3IJrAifGX186e2sOTqy+5Y2E8vjdMw6I73QUOz8ivpFX1F1kpVZirYT03p7awrK4tfs/ 0oiUlZeVyiLBa5ojza6mMK7zP6rXvpRZvo+nYT1SfAPSWH5lefnHyz+nY99/nSQgDcjjD8tZLKML qAQ1GAWopORP0UKcLMSFzkt4GFnI9Axan19R+sDfcqv/4/wCatj90IL8aqhRhEhN4TUq24Bws66V lZbYxNJ4Q7XN0iiIbTW10WdHf+0P1yiuInujw1kWXN+lJS5qsPfN+AtkH87CM16VRk8RnBGcF62k wvLASRZlvk+eRw1LsCzRFyH7apfeq8XZ0VGwi2V/B7mmUT7yzEKFvJCy5UMRDE87Kgr+mSAct8Ay wpMJ+Fli48G29rq6trZ0G5PQ2YfkKJh/0noAVaGfGJX/oLpagJu4ruh7b1daWZKt1WcleSXZ3l3J FqxkCcu2JMeNPmCIA7apCQ7BCJIpCS7kg4s/bRMoDJMSSAKBadI0gVJK4pbPUIqxEca/tu5MM5mk YUraTjsT0sR8i8O0lV1mHMm9a0NCtdK+fXd236zuOfee8xget5ANpIt0UEP5KtAj1oZtBlpjAAAi vRoGqxM6cDMM4vFRkKMC2OwUwpzHWaAla8AU0nhZg+EqyBfYscIBnEE8lR/PcziQSsPoEb5AeQFn nuh6iw3YkKbK4joWOyGGbdipHSBe/DmwC5qLLNfK7CiWp1LjtZMKlWO1bGZiV0G5vJUdk40mW9SO 2MkJ+Us8idgJzI7OnRUGpFA7xmrOYrVB1qpnD/MsQKWSyJR5qEdzw87QWm02W9DMz+cE8TpHqFKB D+fjb6rapg9/y+cpYzweojMVlXdTnnqdxSx59e61kKsSyNUo5MqFjsSFfZof6g5q3tCe1JzQj2gG 9B9qPrRrb1M36X9ab9tond41BDkqhPx0IyeOxDkXZbPTVhUUhpkyqSkbbaWxLk1IXJ93wqAqtF8F NPT6EWKD0v8vKkJqsFAuQs6Y+OIBPIVvz1bdVMP4BDs1Dvlgs7Wx7DjkASvJgG/5xC3EZrHCR5TC KUGoQuZ7f7p6jpQMFCYWKqrDIfK7bIrQPQ3bn3q1VQqNfWfH6eLgjrHcefxI80ab14PHMO7e2bZz F7tj36+3rVrauf+T3OVFUYUvi2auU0cgB+Xog/PIMjMaX2x0xlL+Z/wdpVv9e/1v+d/VHrP/yn+B XGD6tOftI/6CtWgdJk9aOi1ERfIM+nmUmrJSbssh/3H/sH+SY2iLxUIsA9ReWD7Ti3GBOEABs8Bw OvJ1g/jHSEvA1sO0QCUrvtJG5SMVFvrjRhwwYuMI/ikKIi1QTUcZECa23kAxLh6kUiiA/kCtQUpT TGUykDao1oxSFZnx2MSEKRqYGE8puWpvx+0pGVd9zZHqezVsVc5QPXfr2lZEQhXKTaU4+u/ulvVL Nj/qqTz6RNeB3b9o2/ja9J5tCTnk4Xl262LP6s6m4+SKy7Np2bebNrys6+h+9ek1xxfKR9q3Tu/2 FXmlCo1qse1i1+NvpMDQPZFbzPigAybRI7gx3tGDehK3EhTD2bguKwV17h1afsl6Hd1MTNWpXjTt tPZwPdaR4MiCoRCzwtjsWlG3cknr8vXseo5xm2Sne8kD+UvzFxkXcUwbepJscO1C9PfQHjSdoBLJ ZCiJmpoXJBME0Tqan9+UCBF6oQMNkmH0IPkULSTD/SjJJknSkCaXz5aiJONMk+GzhciBHQk9+QQt I5+havBil5GNfIwYGMvJuTPV2uYBWIImfz+7YMHKFt0gxOeTNJT65ThrgGf5lqjHUL+9/mf1VP0A +Rsyk8v9BhGLhStbhshfkUDGyBCy4/CLstyYUbp6amKuvWcmjIBV9gqKZbKAYvZqir0Si02wqcns FYX62BRVBriJfW8XWwBiB3Aqn0gEsMWUWmkFABtIAXFLIg0FaKJDJcgcIkgQ3aSKNaFQBW3iLGSu T4bVc6MprNDAFga7DnUzt8gcR1TbOxNOuaT+gwPv5v7Ufy3Xce19vPkSZvCxjprVudLcxS9ybZ/d wSPTf8QNp45+uXtZg+lHZxYteXbo4JbWhY+xwm+XNrQvf2CJr2b7KyWRemo41/7pd90lvgP4oTMn sPj2ZK7yztXcS7/BPDbkvsid/Ac+dAdr8HsYn8idO38u95N3HkpEWns3/mDjftzWvqKu7llzU8fv X1sVa1p1bs3h9clG2B3MHESIfly1CYnIg/fHd1AcstJ2StCIWkntZvQSDkgxqUlaJz0nbZP2Sm9J F6RrJVMlOpWgklTuoBASg+46V524UnzGtV58yt1l6RR/KV7iPhb+Iv3ZbS4Vg5Ygt8BFz0M+R8AZ cNFl8cKaytK4uabS7JFMFrckQW8VS7QmnUvrEoQ0ccQfFoUilysPa1x5Ts7hckocJwmiRRBEySRx pqI52XB7LB7JbM4TEeVyOrXaPA0lGkUiIkngLG7aVBrkMJeeGe3V1VRyaSp5TtomxgsdleLdmJim HuxDSgTdjaA0TsbzcZytqTTgAG7CFAhtY1/py5KISgao1VTrrOhkUnJGlqdkOXNVTt3lVEpptXDE apWGAReKBGlAg2C0yzRc2O/XHzhrbn01YwrYWkbF1tYytQotZRlYiRR5UmjJWWxWawgkKlQxq1Fh gVF/pVrVYXhHgS7eoDGYEw267E2dLTHPxeq0bO6FPQF7Za0u95zu4fbN1PyjuW68UrVp+s2mQi/n cno8TrOveMvJC7GwvaSceDxU6k26MdebvYGomYvAifOqZUhAPhTGb8e7GBAhYvIFY55YsCnYWrkx 9Hxoc/SV4OvaQ97DwXe0p+adCPbSfdpBz0jQ3OIbo4kY9vt9Zt7iMmMHcmGf31/EOyw878ircgfK zfPLcbhcdIeqygPiPsBMNGNi1ohhn5+PeB08m5dX5q8AI9wb02P9AE6iMjDF6rjRVKlWsGLtMGJb X9Q35P/ckabq4gUmXkHyND/Kf8RTPNzUZ6wK8phP4y39kTzexke0A3gL5u7ZhkYFxpS8UNkJ8rCk 0xhTnuottSnj9l6vfXbe74d53BiV5zx4w3h2HNqNLDfcyLTfKFQ6jrIaOBC4jCJ7LAaRFNjM2QNi u1SzTuT/wGfYWZhTS097YUvRCVuKM5WFnvTMtUjkMdhnyBB8EIJ9bq/kFb0RiOIUvGdcHxS5aIUo RMvgN/s64GKFCut9EsSopa+9zKxKma1zUgR6he+7DBTg8e+PrDs28nxH29EtzadyhvxGp9do9/6n ONxgHEy4Pnr/hZfckdzPn/7GwX+93lNS/j+6qzw2iuuMz5vZw2+Pmd3ZWe8x82bXu3OsvZeN15il xh5Cw2k3VCWhQJyWwzgVCsUNIUACdkJiHFASxW2ANKIUtUAdghrABnNFKZRIrSqKaJSoaZuQ1iW0 HKGSm6oCr/vejCkG2v1j3ptjd7Tf7/o+u6429zQ/dSqb27GobXB52K/SXr+k9TB1j1ep6ZFz9EBP +5Oem4vYk7uf2cKQDmDL6Gf23dhZdOpVQ1F809zTfI862t2rXWvcT8vdvm2+fdQRqt/j3cu/z9MO DtCDoMWAZUpvWa0eZ4KDdOCof1kYUkTFjHyI7sFd/gOH9B6i1n6hSA2zmCAGLxkz5hQkQyjukoDU lmrbELawxRCNpHEqDGFpjgw1NVy76hsyYxxXjUnqOSY5zq/rax22ZEIhbq7g/DYv2Xe3KTa7MnPl tMPd+xfPvTS49fet+ZWl4RN7R6nu62DX75Y+MzEcVqrsK0qzVjY89qC+ZMPQyV+cvfLscz/fs/XW a5+An97IC0Iee+wZPKH9BOspSmWpT49R0uhlo9aPmTNfXKevT2/VB2SHV2CRF7MTAVGSZCGIe51g MufN5ADtLRNyqaDgqzzOdFIOi6KO4yBE5XFXBQPFVXmQFz+QjjOACjIP9vOcAATC+hwUQkLuPtZ3 mJQXMMXx7whjVCer4cZcF4xwUbiX763Y7Fr+ZhGdIplqNtj2e3lNOJ3GjIyTkGRp2z1UtFvNNq6t Yg5cmIcg4wEHQQDAHy168nrp7+dHTnsfElMBpNyQCs2gpfRxRZCPTt4JvI+s7734UR3m4MbSP958 8eb2I/NV2uNHVZ1MYXG9XqXdgt8TfbIdTjVawfTzV/5K5rQLuOocrno96DP2GpH+CP1i5PXIngiz WerWt0nbs/vEfdkTtgF+QDqadbVLa6RuirFzAjcrwtQaYtGG1RZJBIKNURFwuGPkfD7KmWHZb5Uh J1JwQOUK9fXv5lHOMZOmF9uRQ3whFLoRRaItAzJqGmUon0/GIaUoan0uQ+dYjgtm6FAOlSmTUqri c/Q5jSTflHcCp9QnGqFwQcTMPopmFMTeXG8W743yqFTYlf0iS2ejRfotLNq3uD7qDR+BWjWhVoBC nnMLoYKCUesi56bhKSHFMrzJdxle2kJfsQxPGbRYoIyxgKzE8BRMgnEEGL40fIn0WOmW4Vvp9FC+ NT10mwvXiN813E+IVnPK+Ce4azHvWFsz7Tbj5805BCeeFXlYmaYYmaTZPSeTVvzVWhfvplOyvsJ8 TNd0LUlvf7OzZ31G3Zrik1OWPLcpEPF/de2ZK61q183L3q+JKV5Ur0t1LUEPc26e6owmplYfsDMj l7+xqiQ0ZtKFSKlpaiIqsFv2lzZjYvFS5SZmwtKCllZLx3KxOiUX5gmjzmFGLcCMyoOZA8EE52+s IcXfhPsZOxtkt2v7tFO2Af9RzQlYlgIYb8wXr5fwpRyFULn+eD6/OIX023wJcgIK2lSgygpSKY6T kSwgJOdzKp3zsmxQpcuDZag6JSPMFcppOOnfOj910k69l9KqNUObq63S7Fq0hvqAI4yQcQx6eA7F UB4xXQggwoRqiN9c7cLbg7fGEcGiAbLgR2Pwo9smgDD+6L7Q62jB0Hf8F/qG/wc9NQ7n+5HfjJHf 8EscgaZbpO8C3MLb6mzuIK3dRtoE+oc/PrT26Sbt5RT39e/2r4nXr/CMYISjqYCofoGitc0em7RM c88qprbabSOfz15X4hv0KdNK7U8oasqpmq5R2cXULJ0UVXm11NeYeqDF58Jp9croRftvcFpNpM4Y zQEcJ4q3KBRrZtUs5JfHVsPV3nVVa9IveLbFjlAD8HjwY9eHKb9YISExykdQtHoC7eb9fjlRIST8 XKJCjEbzKkfHaJoeZGjD46yt7Z2YZ9hlKhRJio2F2cQe6gQ28kl4JO00uEr81kqSZpVt9W2PmjFG Usz3JUkxorWGq3iqIT1Hw+ayXJol8iFtxz0mTBEXHitonHH4BZ6UOGBKhajGSdoEJ0OmFzzVFPiJ ZH4Zi7zTbRo8sKP0q7M7T/96woKFS4PRqsckN11wtUyP+LVlL/2s9cPSl50/+NPzh8++9lS+PJKU cPo9PEdZsr30x89Lf363dJWPgdaZaSWAdB0kKsXnS31f0XcDuOkdMOUPTfOrA6EMUdJ7FMXMxEqS wff7QYIrlg+OfmIYXKCRinFx+uHQG4HDItMVBzRkEA15wIcDiAcRHI9+lw/5w5GIDF0ChC7eT9Og DMZSLugLn6QDVAQrwUUHcKvIwRjMw074KrTDrnARYq0eSteR5WhtHTQ0vUD2RihV1wXfg+fhRXgD P4lpDw0sbUjUE4MwBGOmjwbG+Sh2K1MaREVGEBq8uwkaggcfyr34EGKbzF+G2GKhIfPm2eF4gKym 4OCY4MzrnGyuh/Si9aVgsgl2cRHrppu/vTaaa9I87zIgVik0UoJ596BgKfXuj6XbO2o1JxL2fwwi dzRLJNnakU6r9wvQqRHamPIsB/92j1xg54mZYEXyqhyta/HQHrcRy+bVK/FIvWqKTM6vYyYsL0SV gKoCTpjdeetcRyySDGDsj49+hifOZtwXXjtGUfhPeXxN+qC12kgJ5vn8jXbKrodtYWUn2qmeUJ3r Y5vKdniYlDJJ+U6MIfNiGABgpxHwYe0mdETZHQ45nhDi8URI9L/jBhQt1rphPJVKxH32jY7EIJhu uBwX4vFvx1fFmfggM91ws1DoDb/NGlyRJe/lpMmFh1jARlLxUDzlajjGzB4DfayhJOUcbgXXhnzj ArAB9/nFe2o7Vs9WMtiZRSV8ARVWCZ1EebjTxKrDPftYB9pI11vF1unZdLm7fV7u7ZoJ0/7y8upn 5xSyxWiFFs8tnT81UfN6RcNie7MKZu0a2d+3YO0rK5ob5k7U47LGBhOZhRufOEDTHZJW7cB1PkVR zmW4zjXg3OEIDQD5i3swSx8BC2WaT5TVoRnidPRNaT5qp/orPkL/Qi5deh/Ry1E3OoIYDYFsAiNB VeODTHY12WpUw0Dbfygv89gorjuOvzez3mt21+OZ2Zn17M7uzqz3vryXjY2Jh+JwmcNgCKddGkxx TSJziMOAsVsC2EElkkuLYkAhlKYhonUTY2xONxIVbcUfJeUfglSBAm2RalUpKFULXvre7AJtqCp1 V5o382Y0I/2O7+/zlUjN2AViQSnAmMskxu/BAwxCbYBBQkK9aS7aPfRdn8vJuVzOeCzm87g5j8fN sKwr4PdLksuYAiRBAEJyQVL0iGlk/dweGk2rU2ex6dKM2IyfZjVj5pCy2rW7Vrv+hMuJGvrYyrJe sUc8gVzfZeIgyCB5mQ9icItKeVS6LOtRLdasp/gCT/GFeFXL0Js8e9Ki4BFET9pc16nlGnU4Pak1 EErzo0KfRyfQDS3hyOcJNaib8GXhiP/Psn9Al3BooxBtOAo7xuLOf2m6l4/PSUize6UuB8qWpKAD wAfc0wBJewsCZtmuf9aPGI9Qv2bS1VWoX6GPfD5D8VY1DASC1UR/N8nCxjdYudr7mHcGFjtMk78y O+eFPKnYnScPQj1/81S1U/nplHNtzOuDQblukblk3uNLuga/wWBd0PnkVGM0yEl+P0+veJdkHn+s W/jk/Aa/P4gmarpiB/lQcRj8WNevPb2rd6CaC8NmdauBFZgQV8XUBmaCV5lZ9naiizjloJaw2xxn HeReCCnGIlEaSof9ISlsJkyS2cU7JReuJeyBIMHZcQWxDMdCwDL+igofjyXIHqYosxkXjpFjTTwb CTGsnadhkh0jX1E5Tq12ISuTLq9XuY1cL3eC03FjZHzYBN7FfKxSPH6Axw/wuJZYPIB+ORyOZ7VV qtBWtVzM1fML+R7+HX6IL+H3REyswAssH9F46uqzeok+rxMkDdGvMNXk7z2vGE176/+zToz/Z3lg 34pUBMIC+irBgiCjP/TBrzFTIeGN8MdfuLKzLFYKnrU0yEnBK+c/rchP+9KZWm3Ov2ZrcoY5qQJa gytaKZTpW6T4epU/ArFY2+Xk1scndTueDK/JBIIaMzFSbA85VBcn/YAAO5/eLbmCSIkGCvj5iFdB A07A43s2OsmW17pqlYby2a5GZQmxzNbMLbWvlFrd6+wdrg7PNnana7dnH3dIOqI/zB5zDUpn7ePS ZbfTYDOyRFkGkGLGaBLGEAyVWRAMWdTVOYs6qy1rWefz4l2HTpWn1+tUNCN16J4O39Op5TndGBTO bUTmB2MT3fKVlgwETviINXoCddYmnJc0Kh0OOVMlEMDkUyEoGIY0Ba4qmFLyywO/2zaZb//8+O/X jeaht7dt/FLj6oEjq4a+uf3kQMmGrfd3fZ6Xnxy8t+EK3PKP/erau+fuXDt0e+Wb/fD0WN8NFJ9v 5ZtKLqP4+JHzrFAXZPkZJTOqu+iD9CB9mr5MG8MwB3KwJlVb/WpiTmph9VJXs3dJeGlkUWJ1elWm LbIm0ZHdFtqd3Rc+lD4cOpo6F7mQvpRx5nCgYzjQJnTSRUMzZb8IHYABkGz4hPyCGSPdwzYqaR4j B1STYdRWGsi4SRTMBpVLJoAJAl6QBB+AHBAcAApj8NgoALkYdVrhL6D3xFB8rSKKqoijKq6bktMi ruCIKzjiCrqn4HuKOiOnaBGvgTUvRfwBmo6YUScwo0Y1Rq0BjvqJ+ygPk4+Qpk7ep+9ptg/VNFI7 0FJSgkehDqdA0KPcIExV9IYgDCA6BSCj5Qzo2JdSRSzL56dl00uh0N55dI68Pv/n48uO/Gm1LxYT 4OCVq9AEj187fGNz/p/5XcdwFlcNHFn5i9YdJwc8NyhL/fyV9OG9SsbMOmGDCMUTt+FNCHfc3/HH fOhhycxnaX3jbfjR6IHPACCe3gBAdxJpWwBN1LfVbiNvCtZFZoN5kbnRlaAD7ALbPV3xH+kH4x9F zgvjkfFE2Qf6swZC7+Jd/XGSDKZSOgtrlSyUzixRIodcQ0DxS4GUTudmOY5lOYQ1bpweAGUYTibE cAJCIBIBi4WigFGRIdDF2HSIY+nYBbIHuJFSheJZN1Ysl7uwsg604sxkYCZ1U4dtIUewIyxGVLZI n6wGkAg/WbW0/BW2iJd4dxRRJTvdUYP3zjE1CKK1U/wVtvgV7Rb6Si8LWUzIaSSJbPrf9DBahKUX v6J/1Gpk/oMCOEHmxRjFtYIYinkOUdr0/J+qeAB7yKIoyqQ+WJiDX/ONhmoZA5bewPLoFsR1o4mn gWy+Na9pqyDxr5smH1JzxTDr9U04Gmda4IU/XP3N0FuVazZQk8vV9Jlfd3d7Y8QPIJ3/dlN1xMEY /X4S+cfkdjKzOJ5Qof/D/r23pPyWgeV6P3HbNH6oc5sRZQ/YEOG+hhRgKlyq7tsX+26SaLW22lpL O6ydts7STrrb2mPrKd1F98Z7E8esx23HSukQiFiz8SXx9XJbfLdxl21zot+4P7I/ftQyaBukf5j5 EPzMMmQbKj1D/yRxOnkeXrFcso3Tw4lzyUcJN59YRDVZmq2r4kuSej0ncHMts21z6bcS+tK4NaEz hCSkDao51Gb3/VWW7SRxESYAADVos8yQyWaBiY4y5jPeyspKohI9OuLrU7x9qMW/MeKR78iEXJiR eBkud2bxqjqVYDYp18u9MimL06JnGDWRY64jXztVs7Yj74E7SAux2UIPAlXIgQuwCtTBqo+7i862 Zf49lPdH0YkFNJ6Zz65bcCng2pj4C63RNTopQ+WC070ZtoBNcJPAZopCgD0t/ms0jSqAL/jYDOkr 5Bo/BnARYOTGumKwbVQMQ9/f2+dJXl/rStz8YEras7hWbyuTIq5Au6I7sbf9e80wuvzN61117ZuD 4lTZA/8+p7L/zPvfaZjSfKMttWjFod9SekUgSHcq/0qdv2twZ9PMnvzd91et/7SDj5Y2ofy/A0BJ GimFDKOqj8S9Z1XomhEr1LiZoRAyl5B9hLdPJmioh/AiaQRmIGOaLauRaVAJNuLYkUaVdtJmiiqy tMlldiLVVjlAyJeRwTGzjFFUQk6a+ozREBmlUlujicLqCxdWtzdbYGWHmO0R3xOHECuPEe5RxSQK omJe/8LoRAupiEYRgI6I2NP+i++qj23iPsP3u7N9ts/nnM8+27FjO7F954svifNhOzhx7BvQjZAv AqRQQgZjGQMGpQn9orQsiLIM6KAjzWCUkXZi7SY2AQlQM0oLhf5RadP6R7WpqOo6KVJDJYtKhWrr iLP3d3bEQNqi2O/vvnyne97neZ9H89qulKeUPnF9i7dnPNg7lXJmXillTCWbvpfmZtNpzelgBivP cV8OIHdMwavPYLFAuYEA0tnUQ74XD+cqDTVAKYQ0eO/bWhTC4h9CNTrDdsleG/zZjwp3mtTeOsvs JOPpjvpiUVTe+9Th1RWivrNwrCfTLlbcW3O2WmoQxXLbYy9T19PDmwGXm+BO9wIujajxEhGY+3Sq zJ7R44m6DRbjofOWC+xlp26FfnlgB7svpDPWGWMpvjWiM1UoERIZIG16Kyt8XqK20UdoAm4wmfzR Wkc0WlsZDIZ4h4PnHV6PB2SbtA6KpjLOFg7p+SjfJNdGHVzwp7wKsstrQl2ewVVlbal6XuWX8RTH I/5tqpswgWZH4Z2XJ6IadnJcq0qtVlW+oSVeGUXRZ5tMURfvgt+GgZ89t/2+GS0iiIBJA1p0eSC5 5B9yovNB5X9KbTG+avDQVlKLr/OBtZhXwYpicCgrqaXaefWNIAvZxqzuSPgOirTl/NHvn9i+NvRs bdsAg84wnYsaA2Pf2X373J++YYyBn1SkdkCmJX1LBwuVI7LavPPNjtHPn0YnX41VxfQQFDu2Fkx3 b/3q8/HWRTVb0Z8HY2K1ASYyUT83Q12j9sNETqCPVbep0liVQC+iF6Pj6Jh3LHqs7vdNFxWmHiPs sjiyp5ynGshkdGklaQmWJyzWoBy34mMpWGRdPa51LqqtHllU2LSAqbzk/FiakShE6nQETBBRkgQL 64zEGiXRqWsQapp8Uo4aV+1EJBwMErRM6HQBQXIIghTLzX0yBSYtlqPqwFN5OEZIypLAsQcsV9Ai QkdShADPT70l/UFQ4TwBA2sNiXFC4IR6gXpZQLBrZHJFQrhCjoMz2wMuzwdNUBeP+/C5LikS942s SEz4bvtIX2NScAlJc+P1IodL8xcYfEm7aJmcxRdNAWG16i5tg6XTallpPzyIr9iaWj3nSs1P8Me6 bt1RBoYU5Q4w9+t8cYRrEq3MN5LizhJYq6fB7YF+21LwT8ACjN4oPm6EluNu3MDdRIDUD2tBl+g4 G13Rcbald83qd4nE3EdEHD7y3AwRmZtZAH+luEvRxZiL46xLU3Jos2ZoRG3FN2P36Gqmg7SB1Fqz Gfcfde26kzIbLawQ+VbwkSMZRXEKex/v6Wzf8u7Yjo1tvUL4fXXJxonFNdtGTi+k9s+u6WdNnMXE +frdm7Yp1Q3LOk4vbti5ZQJ9b8tKdelwRbqvMDm6uOf1v/6jrxP3XhL3nv4Q4SLCSK9y/V5kNCPa 1Eus0l+u0Eklu4SrCjkybtNDjA273YTrEesXsrPe1eVmUZUHWQlCJmCvO8BaHSxrrQr7U1URHc1O e8IMw4qyleX8OWqPWkYD3ofpv9BkgEb0Bvfb0EQuFCZYuFG0Ps5imZYTWpG0gm/PaqoPt7/Kfsh+ yVJsDrVeEFkXK5pzZOBcqWHmNX86PwtEvzUPbx5yk4avsYgv4jVE+dTdvHIP3QU805oLQ0Oaix9G VBIjUcxXEVSU8iCdoPBI5ovjmCZ73l9/uPvxl3KFL0aPTqD6EOeqFZTqwc7VVw72ZwYmJf2h2a7B pUdeeL1wbXJI59opeFielr75Z/Me1Hhi7abxfaDjaXj3W4H3MmLVb4O3sGZl/FVH1CAlUidniAxq 0WciGfkl8mDV/shp8lT4QmAqzAXATXt05XpPJCAb9knouciByBtVlFOPsLRO2jTFnXRqBfiYmJDP yKQMCLHlthzSnfeFzbQIijHl5bJQP1GD/pQYoRjiA8cT5REWAIqxWbaHXcfqytgAS7KeaBBj5zfA oayhx7DOsN2gGzG8ZjhruGr40KA3lFcrj2p2CNjVdaubK+Caz0/D21cUQADBC09xHwzAWwaAhjBj qoAxdcCYyzDBZiAEzGCeDGnxViyRgw9rOJQIkiGLSNxPT5R300dPH5o4jaoObtsqVVQHqstiZrsv seHq4uVPDnYd/e7NF556bfSXSL7UvzBTE5T99spaByNYHQd+fPz4xme6fgD9DxTVrYT+j4HLfU89 SfuRI1helmVAOM3wYdRkOm7GX4w7nogzamMTbDYm4l6zh9ls3sz83fwpY8gKPcI6oa9Jd/+yYEs8 mWj3t7f21Y0mfoFedRwX3iAuopz5gu98fCphXUkgCaGvEsjihlPN+HztojZVTLSpoTAsKhIOhxAK S5J9qxmZmVhByqGvVEmuq491hRxNqXrJ25IMOSg75h5FxKiAXYL8JTWFK+lUbu7mpD+VwsrNuN1W xp6WJTsHZoyaks7YGdwZ5iQ8Z+PJOHPAjN1QEp580ck4ZKBFqpmajo0Tds5O2osCbv8jCHgSesDq hR7wwkN6VV847i3SFRfVBqp+24u85WmIUmlz45sPshKkd2h69ms8yRXuzgPim83/Nz1xq/BYfDFL SySF1tF4atSIWlTzIRjnoMHKMBqeF3gIUkXL9X8l1p5svk9qTGdCu4TQrSz8tsJmYvngsuCSMTVY 44/8/JnlHZ1D75zY9cNkt7SBoS1lQpUr4V2a2l24vbBuE9Dz0L8H1/vNPOteLww+X1+TWv/8Z4+2 jj45jpZv6atpQmtFp+wRrDZanN2hdhfWv9PRg97DuqsC94eA+x5CJApqsoxjRDfnFnWEkTOS/Apj r4mUTVFxganVv4RuN7ablpj7jau4PnFM92vdb+yTuosiF8GvvU1KmIIVtqwxCP7caDKa9F7CaBIq iQNe1WjOsF6fN+alvF4mFOZpfYRhKlvKhIBACp4I0U5iWrusAKl1RF6WtarwQxNWZC2XlOvu+Qnc 9a9pHG268th25SHmDij5EkqEDdO6CAlopzarTSAs8CgmLDA2c9ZYqjSuJksGb09CLU5kQGzAPs9n 10O0pw0RgKqUgO7Qu9cs2bdXyP/tyCs55BzbsnHhqt89ceOVgV27/kN1tca2bZ1RXpE2LYmSKJIi 9bBJSZT40MOWZFGKJMdibMtxLCuPOnVqN26aZWma5+ImXeOlWZE9mjZY06JBCqxoUxRZN2Bris5p MgXZC4NXIGuHDegwoCiwFpiXrguMbkARoECl7ZKSnOzHx4/UgyDvued852jpR/4BFjOh2VOlvX23 69+4ANZdnilNT+1Zr/rdav6HlVj2Q5hnm681x9GbkOujQL6OoPBx5pJl1FhD+v54uVvnNnAjBQSj KrqiZkXjc79PhJkPHiqQ8hWdheWF5SSzFePrpEMLhWVZQC2jI5gYwQTLqDwC3ZMgM7DIC4HBC+sj SQSIOry/WAcHdToSQboDEatLGFNkgcwVYRysW5pLXNpRt6A6maJ1SLnLYwInjNkyH7UZ9MV8Y7Wx ukYZw/s24kPlxgq50vEtwHAqEJIzy8vO5TNd5LJzaI0obQ+FwReGz2ExrGIAnmDhIb5s0YeYcjic nCuHjENFpztuadbMMriIWnCTP+1wagLTsjEw0ECTLOZbJ+2h2YKwwy/4T9yyh3rxyKbJ/Ys7dw7F hMFoIOohcSsd3zUZcq5/6y3n9Eg+UcpNXpqY2tkfEWS/1eErZ0a1wAS6MNKsNj+++PH9GyI+JTgQ ZlnaiVu78NzBvbHbljdGuA2zJ0ZmZ2tJMRXxkQM9TtymaAulfyEQ3JvNcSwO+TWArEemgE0vvDj6 OvVT+mfspdHLG9+mfsPfEK6M2qgD5IHqIrlYfbn6ZrXb7XIJw5PM8PCkyz08iQ2HvFLhbE8dHVxK IJAp53Vh4N3BSAKvRLwuys1MWAawHimVGw4RIriATaSZX6EZpBdJQZ+LoWndqhJF8ZC6odj7S2hw oHgiKlTLmKYae8clKVlSBX9WgXq99t6U19DJBUMlV0nDnX5GNqAJNRA1q9VM/n2xCtFfhdwrcIUO +umUyb2r1bCDLbsMonW6ixwmDcLB3gYVQtomlzlHOY7lDNgM3AzgIJJmk9pwc7jJvnZWAt0d7I1o JGHxvp/QRxd+f0BjIpt+93p2cPGz5558/4FCPPDt/m3fPXL6yz9VH07WZicWzj80qu0ZU5qhbdND Mz9+/r3qoRJafTQ38L19++zBBOlmQu6klNUq9z1TK31di8/z9MZIXJnLec7tOPcJH3x1686/n6x9 rfjIxcbj0ePrRuLDu2vyOEtAD6VCHX0TcjoHtuiHqe34jHpJRfd377ce5A/Ji9ZF/qR0Uu6ZRg5K lmnNmO0aDQsASyyeSCA0k6v0zylaKlcDYhL0IwhOEEIgyAQCQSSB5BJCsp9JJvvFNIYnEzavPZBX goH+JMmcpeGcvELg0WAdRJaIaMAYkAkLupT7IGm4VmhWjb7EFczWq5mfwrlu9ljW7DpV1D5PgqQv H+CSXCBvyzzdonxHeg31XYGQwy1h5pW2ApSH4Mjsao1MuAe8cdiRNWfbGZlnSOepZZhYTCGAw7L6 dgZ6rhz0XD8PhtfBrQC3jG4FXqLQDwt6gL9do5lhJtySgFkAqDbf0bsz1WlpzVS6pcqtbYTjIsib l7hmmW1+eu39+ZTe+y3ObXe4C+uE8OKOcHRAPMb6mL7o2Kz3mVhAfwlsEuMCFfV0nftKA9Q7I/mR h5rzUz1OypHYTGtPpQeiiRPghWqc8bKxx4SPxqf/iJ140q90o7IxPR/47z8t/V0sYkdUENFl7khR Y79Z1Ki4Tmlx3RfIzhLAJwKWUyuhOUVJqTUCOdpdR1/R/QSuEC5CdQl8iOH5UMDOx5QQT3JnWQjo Oy7rUZSog41L6MOuOhB/oR6ieD2g8QZoxVKWb4NndN0K0eR1Idi6omk2m+Kf5y28L8ZzfMz2xNP/ l2NbMqzbeWPG8roDHoybsQ6zt1PqbG2lsXKLbKNtYn2PNULurJIdcI28Mm/e8iqnE0zZYcJX4CB6 xulVV4HTXYW2kkMhv0eb6Xvw7FijNUA18IdYsaSqpWL+XYZ2uDyFoji2c2xYzfq+ExQCbKWLLcbU UkmNFZvHGqMbnSRDJqe5Rzdq6Wh0Bvz2SC/bazcwav6oOW4Z7vJAjFLIp9eojO4isxnjlQOy2fU+ h7bLsSv6oPSgfD7V5VdBqiLNKQOp1BpYIQInHETKIUQlJhqV2Ho4Qrqi8L2iaUWKkhArM+HEtBdQ oKNbUQu6I0PU0fiVLRKAZvm1qxK/Qhf9dVTT7dLtdJSLptcoRt65Y0js/KoZWtrLHUfgVO2sOGTU 2oK3l9uEkHHAJ3AaTwGLgCXdXel7lxm0DShkEdcamxxr+py75NHAh7FSKQar2GxU/vOD8oZ0sI+l fE4LShDbjiU/CcVDDrfD1+UxfwSrefyr0//+S1ERBmgX7afteBeG7XsZRRYIr4TCxAp9DuKFmngb auIgOKbvIMJMQdMdrqymezRNJzWb3UZ47T7iPuT77jdIPM+VtXFuhsMCUZ/kT6LwJhigGcYL9T0i uwHAZEV2KwgvONzOlIPA7ClisBmvg17do2RSgzWE8XqFiMREIhLAAIIZPifjlhm3WwayxGCEDGD2 hBFlUBHUOKOqcQfRrSo2/oJfDtvjKunwa/xZoQ6uX/OuROrMivRrdABuoOcQxYIicXBjKfOBakpq IKu2tNS8hCZNbdPRnKi2oqb6sipnBg9IurZ6rjRu3YH62VjdTN6CICPlWmMF6udQRz9bugmFszVO 1yTVmKtepA0/Qq4CSEbzSN7Ee8ihnqEzxvGUYbec5PKyuUFMngOQNwOGJIliPoR3mwLJGmP2biyR JRRHoWh2SGfZ3Fx57MY6ihAToh1ctVUPD+4NzrDBHE0zbi5bEg8fT8U4Zf7Zfa+Aqd6uqMhloHCq uy9O+RxW0iZJmCxV+6YmTv9VUdzStO/ZHaESeOmJ5qvY47t9tDdoM/fFFqiau+G+6AOqPmlFAIUI QND92nZke+/nwpccZgvaU3bdvtWO2fsqnjmlN9VXg9ChSB8qUB6GojwuO8UrHoq8+8NDtv/xXa3B TVxX+N5dW2utpfXqYa20a2t39ZYlWbKQbEsy9ho/kGwMtmWb8UNAkwAJJYBpoQHaAh3IYB6TaVJD 2oQxKY8MNoYGAhUOLXSSPmh+lJnO9EenM/3jZkInLjMdpmmng+jdXRmcQqvx1dE9u2uN7nfOd75v Dn6E/qVL0uFuIzDCO8Z7RsyYhymJtGuNjNFOfmtVcarJGkfRokaEG0O1GBUajdpajJLPrOyuuS1q 1uSsRFkRZSX5Ronm1OsVtuJTFIOyevXu69aEUbIsKtdF/bow//CL3H/TKIJ7EdKcTKK5ABxXeLlc /h5SfoOIPz9wJopyCT6HLOET3L5WmLaZKET9Cfv63lTcs0yAFaLHx4SRMRwZNleYDf4h/vW4J+Zw 7cCnv2Gw8oQbIeF8/HnpNqROs1iHdMiGJm1jCA5rR3Xr9WvNY425ZC61rmmw/2XTK5YtwT26PZa9 wdeaJvBjwWNNE22n8Xeod+pPt70PZ/TvNVxsvJK4krySutw03X6243rjjeSNtPvr9S83bGnH+8Fw e38/PlF/pP3tDnxjYm/9ruS+9t3pswmND7oT3pXhwe0DpaIjW+iW23nA1x/J9gB9koCZVj2ZhKA7 VmcwtNYRRPZXgDDbbLw/gvo3QiaTfKrZnEo1gzTIpvlMtzmT6faUZ9JpRGSkfwAN3OZUd4Z2HBVl lWQzuyN5uUBsbr9ExTf4/+zH/HksdmN7El5JwqRsfSpTkjOekriq2PYUTPWSkHQ3z6bm4B2QxvAP u2f772ZUOaUEZ1wJvBKuoYeUrU3d1gSVrcSEY7HtmQcZLGMb8DMpJsP4B54qrCVzWWaJhYcPF3I0 UuALuXGUX6K4igWkfGp5orpKixSxRH7NN9FImy9AJMEMqhJDf0sHdk55qfVm0CPN1YQWcOgSXSjW y7+gIlGhqPVEiRqAmsyqgSlKNIfDtLTWh0EO4ooFU+UaYWxYItyYZ5Rbw1J35nwyjJDPw52mRUry wlvfW7t8/Ug8GV3BrDz7Zt+a2pRxm0urIUlbIira9o94nGH/KI/h5bqKmvDR19Z0nJqpstCiu+ln Mdu6H9y0Ej5en9LiE4XlU73fbhSkaN2aAqzb196yItla2LefokjCFExX+o5HI87I92Hrdp0JDT4q sP8vp77Aci+IHGv1Pga7Ggp/wI4MmLQWp07uHC+abbOoc+rhG6p2DRW1q/RuUbyWhS2Aw7hwSR/R r+239wl74L7QhP2C95xvDpvzlI/BMd9tiI9oR+wjgmIVtthVo6AZqumLb/WgvvmqUQgoPiGk+gQA nUEIQlNOiExBCSCWGIYAqA/wwZA5GAwFA4tmIRR8jlmQ8RyLc3ls8mr8bki2hwE064JKgQfVi0pI KkEeccGifQiqEzCocCQyGQ+CMCjbh+D/sA+BnoX5+YeBZx3Ec/wDKt6dsFi69FdcxP8xEaj4ZOOK 5h7+HL/wjL5Ux+GTqkN19snhj349Fm2t3ltJa3WGeAufyyZr3UHHNy2sqcrbdWY4zEdP3hCcrM7u 0aBySkDmJyviTS8VRjM0ZdLXDJkOJ7whT2QXfLO7xmyzhn733uDG89jOccYilmhcyC00oZq5hmpG D2xgVmotw7S4hsTPmS5bz3BXjVctP7dqRq3DtsOm49ZJ02nreSNRb0raVpoytrVlQ8YBE0HqdAZX OYGXljKuknJzHj8oGYkD3dkYcaAt/gYxRWCEjaXktBfIEwRI6BqQ2uJAiqJljwMgIBUsgTOgFHzM BT62IoT+oSLUc18Fq+c+aFmQKUZ+U8kCHa0ZSTr5/IwudLSEfGSYcrZG/NpUYf71idmLkDt0aObC aPqtLzdkTnyJ9Z4s/PHSlWNvQd+ly525Fwuj99ZvhmeRnHpsL3Thv0Gn4ARRmJW6B+EJ3WndrO6W vjRR2Q06qc7KdM2gZiO1i9rDXvLdLLvlv1lzl6XaHL1giMIjIOaQAA71rrooRQELy0QslZQ5Uuns 4PLwfYnyOSLOHuCCYQ8EXDiPn5Accnv4AAWcFM9yZpblPC6yHD1VwUJ2mY9j6eAcfhAQqKBr44Rc 1341eJUgVQpxQuLjawgoEb3EDuIMcYcoJebwFFIkgQ85pzPPott+Go2zkt3YIn+WjFVow1XHHrCQ sy1jGXYZmceTHwwVJb/aFHs/t4bphUdq1QbuqwphHDF8y8JSs1WkcrkZEs+RgUj1NaHXdz55ghVR r9Y/QIh5lR6wLCPEhvqngj9uQtA148pGQ8Bfdrw6Mzz83cKP/hbtiWQsTKxHW/CTuVbXI4YXqmPb ml+Jbd3c35qp2/r7OnziswObToz/qZCwVBUKqxgLb3C7Sxr341uzZs5OeB+ZupI7J3/7Yu/gPy8g tEEIof0pQlsEYdgpkRpOU7U81BUq8crHlENqqoyLYbvhtOGicdZxwXPOOx2aqb3uLZ/0vFs7w+Gb 4EHP8Vo8bevihiCeCKXCnRAPkaFwvRc/BWBYEGmSLo+QWlgW0RoEd0Aw0A7RWhuifWIen5RMwO2q rpbhh5CnRTNNi4E8XivpKstJLUVHfCJNg1uI80R4BPhQ45hu0w9ojD6QjdOSBy3eEaNVqpODJLAo xyJgrdAqo21FstUqcXHr1gjN0BEyehN+BhaNHUK1yH65+w8XFhVgEV7qKbz0vAywPKUNiSLOS/FV sR1Xp3YAFKUgo4KqwLrIburAZRqUBgVF8jPinxZuWhgzHyULIvmC1VNnP3poZ1/nS5vm3t69YeUY w69cndhb+HtbZHnPrtP4xL9PrrYwYpnO7S7TVrS/Chd+sbrh7PpTcNWWbMeqHT+W+gtjc92r2zfD NlnLe1ATJBC+fvAvqRVDM1BEqw8O4uu068h+/zR+qWLaep7VHmYn2ccBfKLkhyWYnech6BD/6vNH QA/EzALGY1AM66E+D6ckh9mt0UDCB9FNPC+IZkEQBZ70iQId0UraXi2uncMkgCb+Vf9dQQallkkI Umx5TJCCcUFyoeVAixdQoqo6BgQIhCnhtnBPeCA8FjRo9h25HhCY/7Bd7bFN3Hf8fnd+v+3Lne9l +86Ps2M7fsR2bCeOfVDeCQklUBraECjdeIgV0U5DrdYXS9nwNECrUIegK1s32rW0iARGijoNaSxT 2KZ2Uv+pJlWdFtr1j6idBmxa67Dv75zykCbrd1/ZdzpL38/3+3l062ng+uL6pVJzrTndpd+RpDY8 8LNupe6Wo+9j9PI5rDmAMB2jblsdDERcvW1r7qiM/tMONHr07JH7C4oa5rr8ioE0W+xet1Aa2ZYM Jk3y8Xdkd4fCVKj7KwsCSu1fFo8trXUFQ7TJYnFpj5xcOvK4/xnyW3syPofHCt2/NQ9J6lPofo64 qEW7EfKHRU/DYje4OTvj7o0bE/aI+zhFZVEDDaNxZEDTyKDZMjNEzmyMdpr5aXRBKzIznN8eiHrt ZJOYQZrP3liHEJp19b4vfyx/IVPPykegf5dlg3zK0qseE5r8DKfLfhFGPwdHCRdPcZc5kvtu/hJa hh6FBfDcwJN/HeT++thYC/hubh5kpVGbm29fx3S2wsNMRVTMQvpEQwP1UAqditAFoK1u3LgMWSpC d/34e5n8tD9m3Lm2vjqQPzD41sSqLYqvyx/rj5ke3z446pGmCj/aKwuuHd5UACT6zwefWpZTaj2H j2o7fxZ2ZNCynzyzsZ4I1z7YXdp20EjFszDBm6CH3zQ8TwSR6R3CCAZuH7hfzV39hfFz8ksXtVFs EjcRFQ30Eg+5KLcckMlnYZDIIOFyI4PRbCYCUlBEghQIckbegCygSTxvMFAvEqdIZKLtYM1CLA8k zLOhBM96yNVuKkSRtyhE7ZGJs2Z303UJIcIM4cPhY7WeavEy+z5LsnpyDVmhLaF7kmsK23Y3i5Mq q0leuAAP6SGxdROoBE/0XJtrMM0Y25YKet7SkwOMsr+dCapVfYqNtRryzLZzAeYYbKAK5sj/9U4R zDakf+hl78kzksfOd3IjysPrK9V0RX7tJdtjP95seH7hi0Zrclzy+iIdO/iDZbWc6tlL3hcP7n8R swV2QFdgXmvoJW3C0sv3kr5SfmV+Q203+yTzFHuG+T3xX8a6MbOhb7eVGmA2EJsZqoeoMaSS6KyS b1pRVW0khhPjiRvMTfZG1dzRV6vRVpsar1R7Wb+xwNRoNS72ZwqFRS+cMtcIE0FRIbrWQdM1zmUX 6X5wwzXaY2tat1I48om1t2jwSLTG8UVaY0ohepgep4/Qr9BGGtKh5ijERC2DMjH5mE9su2FcpuBx vXYw7Zou6lXjI4liTtTEUyIl8v1W0U/74U9t+3+nY3hP5AMoL4haxNfQXwCbh+s5tqrDuRYnwXn9 SYiFt00zlpC7kIUsuKgmX4sIAIwBxcagzVFt6cBjwzGcvcospr0+ODk4QTiLCQ7BPraBvxt3wPxe 92wyx3vK95rsOlkuU1fejjvt3s6R4PBIuRBPOz0Db1x7JKOlN8leG5NcExrYoPXEsoktcZ5Rdp97 YglL7WudeSHi84b2+J/uU9ORcGXNfxY++0DLD5xApb2iwxvcyn67nMrGen648JuJCO1f+vc/fDiI JykNk9SESVKJL7UlFxFKaJ5SQnPAcZVGyQepXxs+VAydUp+0mqQqYWSx2pDD6TJzZjOSo8BzDDKH ZHvIl/U1fJQPdOeiO85hz4ypbTJZ0hlOVEufc7c4UuY07jnuKPceZ+SERKgpE6tVfN/RUWqow+q4 +lvVoL5LRfASEzIehUxRbr9HFyg+1glaBC9fJz8nH5VPAZXKOVmTKXmalKbi3R9xeLH1kZiHBZ/z zA8tfl8L6oMtQ+36PA/QZhGA2zYDcJMYo2NAD/DpKesfAEenSl2IsPRESJ1M00gJ0aLX4nqam+hQ nPaxQiSpeYTDP+24GuMG+V4+Qw3U16zdd2Loq6YyFSolgqKwLCl3Ly8UsoN/nfb/hXzy5YIVuh65 9Q/jAHQ9hUY1O8fwImlhrCKZxLk37nDWNwkjyW8IW5MfC8YkkxVr7CpxXHw4+Zi4J7Qr9cv4+ZTd 14UnPddbxBX8dle7TXoJ6WUq2L6p5fxSUUjOIsQR4WZsJqWqYPjNkijyPGcnKYPRZPTyYkqQQvas vWGn7IDiBeMBtxd5p6my5kDX+CZ3QEg1iWvCNHlYs4lNKTYcHY+S0WkqO5m8JuF/AxrFdTJVwkVz Z3qKkqaUcpImrZMo6RKgmqYq59oQLSIEnq3VmvfAaY0BQO29A1pt6BTbvi4CNsdl9ci6uO3nRVg2 P7Rr0luFEfvogrcqhN36+o2Cd0+BKCJaR/Jr2dOxNJtIoGSE4dQBLcVYmvUjavPyt3f22wxlNhPt rLqDm3b/rRxbsrA9bY66I3wh0IVCNZ/JgE5Qh1q+P03tyrJeayTGhFL9hWLXAz94deGzCnm+NYje /PcO2W+K3vfawunvhcnT2Fm8C/s1AUivQBZtuxObAjNhThL9qN5BsChKRBB25If4V9Gv+DeSr/ef bXhWwQp6/NuVJ5RZ/o+K0RpxJNdHKAMvCGQymapr9ZqWUMKkIIQSWkciodWTIJPe0tLmihnCi816 iOm12QhzaaYaz2RUuyHJ15XmK+H3wmR41knOLb+EVhIaik4KBxLYKAb4ubrWN1Csa4FSvb5SdmrO I86zToNTWNXNr5xGHRi0IVDET8YACNgl7EY+mQfunceIYbRac/rFc30e43ebSD2zZounZgGa9VzR KXQMgZNHeNOwAt6xeos+j2bvlsq4SpHtuuhb8L2eMiCnQ4d25Hlf54ORR1UukCq4pSgDMZBT6g+s pwUnI5Xjkca2slpRmKUnt/RXEwqXluWo4HLQ2Z/zdaN/zSp/kDpULEaPT+Q2eWwZRXXxVo9UPLbw +nDIn1nj+85QuhFHnQv/HOoOsDElLfs96leVf7mW9JBRjOzWhRXUQUC2gmjtoRN5lOd6S1Ze4Dv5 fv40eZ68JJxPTHfPUDOGq/xVwblaHBV3iZQhn8tmjYFUUMgLXkMum+lKJSTRouSNJjOQ6//YL7/Y KKoojH8zd3eY7c7M/pvttNhlu13aFbrp7rTbzrbdbC9YlKVqCzGISgMhkaDxQUggRl+IPml4aBD/ xiYVY2KiD4AY1wcCiYaE1ESe9UFikBizCCFAlLi7njsj1Nc+msxufnPn3r135mZPzne/E9ZUKzD6 VvmiiTXrLw3m1kUydekCd+wYD8dLkVg6Jsce1g5bQgQXrCVLnrOOWqcs1msVaYxZtYly7bwjTTmz zh6HOXWW5XrgV1v4G1v4G1vkpkUyumAv2TdsNmcfteVeu2hzm9lCRMfvi+i8l6LzwghRxzX1VzHV bAgNdd2Pxzji4up6oMB3Fc+PSoekzk4r8UBOV3JQASmqewh6VtSLKn2ZG9WcNNO3Vs9XDjnb7bBi TOaK6/PVl1rf//Te8VK6sGnA1NWEGlyjRJza3qGyUd6cHAuxNyeeP9Eyt370+BtzvdFY2EiMZDYM 1/jscmv3n58/U0jneChYUIMdfdv2VeVXF6eVfhG/b6niyrKDMKXp03G93v6Fx/smSppIUbaO7nQl M8rq7QYnFRuTl6Uf5GX2I7vHlDybZDV9l7ZLf0Hez16Rj7BFbVH/VP6Y6aFWINBQiyFzi2E0EkVT jxtpyHWpm4fImiqBOEtr1PuyI9xBNVqWG6G6LNU6zXeY+1oxpGlh/lBvaSoshd9OiuT7iuLRnB+s XKfz7HZF+P/KtSZJ4DdgJLvkeZhrnjSvdR/TvvA1yTHjMbPq+RGhpdeiYhVPGsInGZwWGOKlhjDA hlDuldnS0PUGonf+bdxz8r7w8jgjT894KltlPCkupqe6iUxSygxTfo6wzKiU6RMHZ/Yz+TWSxf4D 5UKq/+nmYfls68pziR4nNcAOdjeL0dJ062ZKvhxURibx4HNgFfxGgXz5P1wF5B5i/wrsOBB4Fwj+ vnrUKtCxA9DeB/STQKQLiL0IJB4FzLMenaeArq4V1h4DemgvqQWPNO0zQ3vIEv0bgYF7q2PDEWDj LSBP7dAfQHEfMPwkUBoDxvKAcxkY3wZM0nilAfABYPOzwCN7gS0077EhYOsXQO0mMLMbeIKOpVn6 j7YrwI4rwFNLwM5hHx8fHx8fHx8fHx+f/z0SVYAncAsVqheDkBFFAZuoIny93QajPv0O+YMPB3OJ 1J5I5Y7arbpF6Cfp+jnRnpn5+a+/g81j6l21SN0QzRcr8I8AAwBuo8rDCmVuZHN0cmVhbQ1lbmRv YmoNMSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNTUgMCBSIA0vUmVzb3VyY2VzIDIg MCBSIA0vQ29udGVudHMgMyAwIFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94 IFsgMCAwIDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTIgMCBvYmoNPDwgDS9Qcm9j U2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvVFQxIDYzIDAgUiAvVFQyIDY3IDAgUiA+PiAN L0V4dEdTdGF0ZSA8PCAvR1MxIDg3IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNiA2MiAwIFIg Pj4gDT4+IA1lbmRvYmoNMyAwIG9iag08PCAvTGVuZ3RoIDc2MDMgL0ZpbHRlciAvRmxhdGVEZWNv ZGUgPj4gDXN0cmVhbQ0KSImkV0vPW7kN3X+/wusCcfTWFWB40RmgQLf1LujCduICA0w3WfTvjx48 JKV7PUlbDDLftURSfPPwr7ePz7ebPdnT7fVhzblsJ1P/G1/Jn8N2yj6coy/5dPv94/Mv39Pp+b3T mNP3578/Pv/tH/b0r+8f5myMKafb88Ocbv/5uBhjY/1n678w/hpvjHsZE57GxFT/5fq91b+Wztrf +6ALgX5n4mv0bpzFQnxxyOm0mWQQTTsLr8Hr8Q69GdP19luz2rHVxsHq+pXjOdf/W9t+VJu7ZblZ 9qVa5UKTev1kzXZOF5IY6fUy/srris5crTvbS9Plas+BWMNjKD0MVeTtrLwXQWY3kzalALtQcYVB A6U6XVP6udDd6/c509ud47XXK8Tx+uyCq+9qRXf95+3vH1WMczad6l+bcvXcr92H1sGHUD18G4K8 Obt2nKBlldcf44/msnKRmGuu0vS20DtOl121LuFBXnvSQYxg0+RNgtdUVv+g5NKPhxEmeUdr2gkT E+qfb03VRA9xlT6mEKB21NXIkATFKPGt7WG5/WWEIXAqZ4ozxdNv/uzhtG3Es/qItdrKuHZDh5Ht TEqZmBZiDxE9R8MwnV9g/skh2/riJATvM2l3RLe8a7JqAHcxebiOKhItNjpBtjPvDzzBAh7aFQnu 5lz39A/akxsam6E+kXNPG9FSibPLa1CXs3PDj/ssbOqicvzDZrrTYWqrKkIk8UA1HWWEpOZX0Xld JPdwFeFnyfApebmH8ANpMbR/R/rm0v1KEhHgSIy60GeRaJkrR0CBp/lCtZpmAxJzIpHy5DahGxQG gYgu4+64xdFtT5B+uVFhwNjJHra0iHpw7ac+4zbuz7lKB0m9sxhWSJRqhyGpPUKgniYxTuW+aR0a qLjo+2ad504cUqHheJ37hoipBlelymVWBOSJEvlPdaA3At9vYgMsXoeltTN3xxUP8RS9u612mBV9 aKdbywnNfUo5koS5vNHIGs4Lap6r+3u7j+TcMMImPK8R2MCuHlxypoGZljAHlU4tf6WWT26W2SMU tFXKokMtnuhydrrcghqe9Isc1HpFAO7Ymxv2huAuPucYCDDZoICjShlfXTvH84cJhLQnotuLoO4R goBFZp8u6IGWUPRmL71IdNGg1j+RnzYmjPz1tX0hG0NSgRNTKMUA/yDY79/tsaOUXoWAZsTSLVoG tl+0DMzypq6I2W3jKNzBuuCXbVcxmGc1CJ7D4aGpG8bo8ZCvHNcgwI/0SDZ1Dl/RqW3mm2vkOOAy qLLu70clDQgNfTy5ocMRFsAQxJwB7ZEJrPY0KybnJHbO3QCWhFGRrudNxxytllyWOlGgns81SEgi J7cERA/iCOSZuWlKXp1kHrzTp1fE9BqPEHsHah58rytenUSWeSg6T+WP+JCojURhfPmLvGbZpN3B fYJy5PaIDctbGcAcX3qQRPFVMRr9wjtdnZY2gJaQ2ZAcZACi2eXZxTT2EEz1SmUrruMnkBIcZjvh Bm2GSoQhIjOg8TB8NiPTuijpcryEdMsepK0GLdzG0EJLnlE7sosvvEpKlRayGvAEJ44xwYmrqR8u M0F3kdUOYM2CmaH3pMlBY6LlhL9mEC+TUeVbn8XvMN2Mz4uGzXpF6aYh94DcIw/kd0B/3r6kW/E4 oNUxLp2Ony0M0TRixe3Orf/LFqLTqXA6LSuPC5HAXA0vin6Y1UpzQ1v1CAmWAaGjvap5hTWAtJ41 5TK/dSAwqdP2A5kIlv4dB4x3a0ujc0GREB9IPPrjGwMxBiZzJslh/i1QdH1J3mZ5jneTaUybzCFB jmSaSrzZ0dyvLTs3u9O1CXQZx6UfrxHFuW8/q5t8ms/fV40hFCNVwjw7kH6gQzzgsxSqPG9Ssdmu Skc6/9AhJMP4vaKb228fn283e6q7wOuj4siynUz9b3y1fWk7RWvPxpc63n8f7vX0hI0jm/C3+cU9 0a2opABUJvOH+37spuFqBvFpqXwj0aT9Zpjj2BzjYE79yvGc3Sls+VwdZ9kczpaf072GwFnVUVEf xxpqCtETcvIIZc1jmqNluUlqOpGXgKKYpjUrLp0g01I9/gTJtKFy3bQlylX81qop5eqPX9ft5L+D 1X0MRzdAFtMP5wg38b0OeCK2ye62o7f1VsToAuyyqfhp9yDL9fpq4wbYaGWJomTUBLpuus5pub/r p2QNY1iw20KxubAEXqZkSewJKlFQoKFzBsB1mcDv0lAokIZKQhoxgN0zj9DViNNkVU3RRt23Y6AW +FxjQ+OJxsZDPKKvF/siT+pIobuT6MNZPJpf85R5qA5pxwQNaC/otABpHJVKRJkYcqCCqRYHhfDW KtwRdqu67wrYXmJR/XsRLdRJQD4DMD2JMWDGrkJggj6p3i3w7jbNBes5iapy5qBrteTzXHycLBP1 SGt/kcCFVMaTKI07U7gDiU8Eme9Yfh1GnwY+1XJ9X/rG5gmealq1KV1WDXD6/+kxohqHTDQ1YM+X 9OhGs11WOeQlnZSybyhMThOkIZ+hkRrzSI0M9QkAva0BRb5CloxgHU0HwmgwUtcBs/7JBCKCmvj8 srJMcpbt2RAoq9aPOU2513VL83FPZSxT6K96JBhJSNWFp47LNM+d1E13cjWHVPfml+xIEkJg1XBv 63Jp2vgUnPSF6xFcgRpKi2vWE4KSrCM3WnJ0fMHZbCFO+EDtMOjwLC3RiCf11IxfHM5Y+TqKJN65 9BbY7EoR6JGUgQNyJKrmkRd9+zJx4OxvEMnN+S5iQdUd0EfSlaLX1gk0tsbV2zmArTOM1EShJz54 bNOBfqhnYlmzXMvh5RKqNdhapv0v6yhHcoLn5YZ9VmEn2pjlVsFl30zlmrjPLG2Y/aRwJXI6f0E8 OavVeH8KjksLw7rLFj/Oy8GoVxknyGWUMw8d1dp6Q6Y23ceOqmjc9apEtVagyy2Szns9L/do0qAZ MNDqdt+BPEnQePW1SFIYyHC1hovSr3cGtD2uUE9JF5D8h/qCavIlySV/jBE3SUh8MqFD5/Rg5/cd 53X4RumVdHq9sE1S3oAhE2F9bpz0xe45U7N40t46iG9cVhVqz48XZOZZjN5qy+gKbEIvNDRkFgA1 WVJhSdUrkRs8xLE1j91TbIRIvxuFNWGRiGj+p7VvyvGg4flAGwh1QYdvvLzQIRNbdi2zRTEJrgiX /SVDNtkc+tfXaiAagX6raEF654JALwSsrBpKqxDQjMHK9m6DMeBQ6RiY5WBbJMa21iHnd0JRlFFc R8MNrZjh/2jTWF3UsBJ0PF96cx0P+srp08JZWiMBDOiTpGf/tpfTswrL7iQDybUpCbxCgRtbUTmQ HFmJZRrzE44qgQ0NNAh5ZdsO3hQCPLAYRB7+QrUyeKjBDoZWJChPj7eIRs2zYPLZHpEnPmuf1s7k LqDyDoRELtSm9FlppyY/d16MTn4ZDm99ZxbymnXU7K3GiaosgtVM5jNxBHSOglhw2yM+JfPGuIKM GG1rbVLc5wRcSCdFP7SZhhVztNBlddtz3xMwd9soAh9mdv+t4Z0qxtRe2zPlReC/34S2Zk636iK8 u4jqAqFnjfJSrrkMO5J4AUNIXNRqME5uYbOd4M9pR3PrjtYlAlo/KZuwatjRjUadRDXKeku7H5Uo 6eN242hcVdfXHI9Hvh/3Zm1N6ATrRLGClfL6yorqbLQ8aHT+fZp9Ih6eBbfer3Is5hGzVVU6B9xp MfCco3bHH8IBn/BEzafBF9NjvCTRtPU2j1RwSAAc3Y/M0NteDyvMSf7M+HF3thOur0VvZc/ofbrw rc7F7u8kqvRlJFtZXzZKv14Oam74PLCs7S0NSM4+pchA4f0+63A3dkDgXFGAbgtk82CMGCn9I+v7 Ppd4gOVZVChcmVTX7x+i3jeEyfo3oWLBZDTYG2I3Yokl1/c2ialxxghCZx4HThVyPh8WEh2jeWTN rjc6SgQoBZjW4bIl5pd6tzGyJJ0DbtWaFjDh3n5CD7Ye2EHeevGjx9sub48Zq+WdcSPm0zeVMiHT hKwlwurk+dIX0uRJMoE+NZFOdM4TunNPGbQy6Xnmrip31jjGdBt+oHPaLMcVkFSAVnbzEPWbFq2o zPO4rrkQYkTSrznp5kJSOamynugZL/mRhevQxLk8C/dGr4tV8JJnGAheqe1NMkkK+vEH61WzI7nN A+/7FPMCO9GPJduA0ac8wty+U3dn+hAg73+NRLIoUvbMLvAFyWLcEiVRFFlVnE4y8vt0+pVrimS0 tXVi+PqXko4l7qpBrXKfzZcVlecWJIy3MOq3hxlBePnqwoIenOM8HNu+PejQL/4MI2NkLO29NDR5 pxUtR6PRwRKA4pmMovb0VawbLJMLV3z9RNK48GnH9CsF0+s61VZM/ZXSOgZnKFyvJEA+hvd0glPA nrhYiBNV7oBI4Z6yjct5C93YndizKpmAnGd6iGjnpGHpETkGHLPQ4zShfRZBAgnqKJv+7rePv3/8 8fER31qxv37E8L5vb6H9x19dB2xvcW8NV95b5v7Dj7DIkT2ViKQ1hdr/cCNyyqXfiiKHn94UZWNl orUL34V4Dq5cL+n1GtHK9dpXI+v1rfUH70vC3QZfdEDUQ0CvVBLGGyYkLZRozc6ArD1QdPRm8ccH D83T5SLbLzJ34IOapXqImV1LByjXPJQpcJ3f4UhKvN5Pxj29tb+xri1of3L4im0CSzYQJzoICV/L kEcytHJ5EPDuE/BiDlF+iQ3BLcAfRpIWxBR+x0X0LqMVRv0Z1nOwK4oIAA1Twsltwknr63YezmO4 4L1FNkQHdnFDMImgY3+idltCtrUf3J/4UQ2IpMTv2ckdhddfXQV5kfRFf6l65TXtUKYyHh1pVN2L bpWVajlscWNKVbLCWUqrNlN5COhoV+nOSQ8rzodeBS5Uu+Yd2iBcM5trUqCeuK7NvuD5uNrFbidt BcwgKoueqU3mjYOWoba5GpXmLONGaWkE3wlO+/Kd2drafPLUEm6Fq/vV1MFy+DNW+NSd43zrMYzH HA4gRz7MR/EKUKtZHxbatpUvWhP7+yJtpAQpbVRX7Zo2m08bmdphfXXgt8X5OtuPQlfUSOrN3Tk5 tIreaD2tQUsL3k8emk6oY04rFN7UICvktxrfw7puip2qt4d4VZlZ2DOEozRm1nCo/FbEicGI5+qX WK1b6o73z5OAHw3s5m2/aAaoSvbg5TmyHGvTU+t5OJ31pMU6UKzRMt+KUE1l4ylcqt03GREVHk6E lTTFgQfFhrViE31RP1J8gBOCWRFM+vjsV9wO/35ARaRufxikL+aJyaPb6x5801GPEeNkneS02+bp jNEi7SFdXM63l7ZbFetBnU7XD48eYYQW+vwpWdxPWy2Ydl5YDX5oF7G52ZZxicMxdQnDpj1NkMea kDap+i/zxouEghqQ13iWayd7mgN7WNXjDcTNqZ+V0X1cjfnIBUu5HumAPgWabBHOCo/5BM8s4xlH nSXkbAHKuYvh0uRQu86616WJZCmRoNwKfMTxJ+k6XbxyVvQmdkOFXXS7k9kovoxFw7ufcG+qY+5J KH5PEHKPPHJBGkHtSqs3QE77nKu8xtnzGHU+2YgHA6q6bmq8XM8oNk50TGFRm9yzXmuyTKesOvuc EsHUBwXkOfsn2MIJYbMxZZuNyKhM0nMpaAlIT6xC7jJkc6oQIjCNtoMlCcZG6AriVRyDaItg5bwc t8pHuwGxF4v5RXfF6jEofZSqSL/NQ5scdY4gk+qm11vvBZ0yK9KMfvLvJskIAp63cJAuk1j+nHBw HWiVllW48xZUVejg3h+1mGzm60xWmywt9rUJkMDKpxwwy23OpqJ803zWurvISrVc5FXEMTql3+/p 7cIDV0lV/k0Wj5Y9YmtGU70NqGdcdtJUM7QZGhpyGP+UAeKxlQlqQTr+jPtKGUmiZMLF8uB6UfIQ 2zxDu4yj7jRXX6ejqyh8twyzCvgYoFCEPADRcBbGS/YHO5EkXEiJsE77aVxIlM/Heaeew//rzgCy KXt8yts+stA4b8fPwtxZQIhViytj3ua0jkFz95qOQ9LueIHl+GIBpcbQo673MAeiYHTsv294nCwY cU4Skb8uEF6ZBfUP4Y74lc2kirPghGGrGFkBvC9xTyeGVYWSFnNvUxB4+rUwcvZC7wWTN45NXv38 OXbGnWKj5MlzrdJDfEOeavMlTImcuL6rSh4QFNaXp/GpAlCrINWNpeC3Dapd0J8/H2anIpj3aaJz N9At82jyFK7KND/BlI5bHvw07HK/WC+RMuILSamNKngxd1jfODO6RO177cwy+bPjf/+K3aEwMFUM kpxjhhbiDLSECI5MchPgmieKBqduI8T2eKpdo6VevB9tVrnx7Zthq20EGtP9RdeLF0U6amMQ0juk CI7AGDe9+ZiLQRKQPZ4TcLUJSA3H9NQ1KNeZn4qVcxMzaQCY2yQ1MGvhwprffbHrdH1H34MMM8Na ek6EjSRlrR8ZoYP2Utj0Do4apzomWq6kalLlzBVpWUjfLO6UYz1DuQuI/X6hKdZIKm42QwqLQSTV G4/JbJU2y8kETHYVvB5XRWOFiVifL9TTVS7UoWNTntHuQPuUMrgcjY8GYJuMHA477Rqjb6tuPxcF CIZoHandjwTLHeMK2iEb3u/ZoCuTfpWuBJfD5ofOtSCIMtWT/L79NZbDetl7o0VfyHlQ7d79NIqe 8Vp3q+fV7nf1NzBhfoVJg6tVdBm8zhlMq3f513VJlMnxY0g9vWBgeLwbM51mOcQJFrgvEgLS1xPq 0hVNO0o4rZ2SxaVpNaNftXQKoYbD+lxEj/X4hRAZOZmeQDQJj1GL89FcRMUqqefASbKIElcDY0yU oJallDi4ZQgiveolPs50LHOL0PcTgBmGQIlMzwSDjH24XRTWiO/buuQTbahcXKzkzlw4C1oQFDuE jJURTmlj4XIbistOzDpDx+9B5SfpDLRG08bF5sQ6MHcc/GvqiBD3YYh7de8mMmK0VxbdTLiMg3QA oY0qkNVwXWYE7zInJ0ZxO05cXbjaM+eb7mXtRg7ArhWZ3EWXuo01OXTBp7cTwsw6vwAT0EmNW22Y Mk9fqt8JJ45zJh2Ye/h6LJA3kBAQ7E5emnwTSYvn1dzfwlBWMh4evH9pf9Pr9vH3j/biqbQGNPis P8b68Bz1z3rp933M3/iYNP26Hz/hyIxPo1FCYIv1pSnOzNyRCxB0uSX0iotoWxmx9uHRWanYleUB Msyu05FtwtPv0DNA+VKO7Ni+TSdZ+NCxehsASvCxDyIihoCSVmaiAfhyeVAXEANbLPhokLru6u50 3VUOJQeXhP+7yEK0ktw7oAw2cxJEoWnNyJB6ln5SD2VgWCI32o9YZUx3rVJKBEho2Kq1AEouk0Md V6H5AhD6GLnytZIIquR5IbM+jnLqwjVrPSN7hme0DdznlKLiDUBIx94yslI+qjq8JqRRFGkaXGck Nn33SDKcBHbn9ydzvTEY7Ob3Llg3bTgUXGAhLNjEnsy9GRbBkBXzfrhZvaLbU8Xf5Kck0MjESSyn R7By7w5oupCXZbBeClUw+cZazShUXeAMFz1CdfjQwUoYXc88/Uqvbz3rIcI6OvT03epp3ev/VvRu t8f5JniGESB7Bs3EkTIasUuNPfRp6dujOfQK13aJi+TF7jEc4xcSW/srmFjMmbblZMSq4ZzTn1+d CLB7BO3hVNrTj7ug7gqUWXYoAyPuVz+pMAlC0dAofrrQVg1tGbfQAK8mwDjQfN5FsW27vLlEmrcg FszHiLq1oyt33+rhJ0vVM5TF5ec+Pg3myGluj+jvcu932Y7zq6hHwKNl3Exl8V60LqKUPUKI/Mji rG0NGGKa1Pjj4yO+NXR5/Yip6Z7w1v7ksL/lvVFrkxv/eB3UOSpKX5SqqVDomFUOhS488QpLLyXJ auz73+AZtiUEO5nEyeaN+ElfOTVyWd7y2sQLecvqe1G4PPnYYpYKVTT7ChQ5e6wzEV9YTcjy4N37 LtBC2Jmah2O+5TipoQpn7+Ztx0nazshp5JG2SNGdMnZeumAAvBuX5wXJXXqTxu89pVZxs+RMthUl +qqyVeIvomDi6ZdMEl9qV7Jt3HqsmDWpbA1yEDDISYVn9Sajl8JeZ3+kGZvnJf/ifOggxOAaVTJq NcCNGtqni0kTieQCKiCm8UPdASneLWjJo8vHGIEextOnTaCihUhQh1+Y9W+qbWGm3LasjmkCZ9KN u+EmZnR8wIR0uo5uQ0voZqv4oHvs8g9hdJe8T6vHJG/jJo3eteMjQHitp+OL/ctYZwO8xEgrP1mF slvFiO5f5a111CwZBpbgZG67HC7SMDpPdG+8LYzTeFYMqXOPcYMk4kEBDjb4aPhudB1bp/0mUOB6 xtF7bW5YnUe3KReB5AgvF/7FKKEsD9lLGaHhXfdRmZpGaiJXyaabY/uW2ZnyMq1+olSTL5tZvUyG PVJaT+rgYlwBIunWYq1bFiSts/r1ZYeJHkWosV0F5sSgp7UJ55R43Y8tQy7J296tFvyX8GrJdRuG gfueohdoYcn62MBDV+0NuusqNfruf4RKFIcfWUkWAQKTkiiKnBmiTAnGtsWQcjibjj+mtLHOVCvc MbdZN54+ISuLwfIydnBjoRkgTYFzhAsnFKRemIWP3ShNNyjzzeeZ8EUEdjgb4mjUvaLfmEFouwvM noWfrMaAWNdbxcy+WexXQ53ZvFreHmujDl874q3EUiEWsq3FPIML/3C3okwK33g9uwUNneeHO+gC o5bJ98EZwlSZT43zcll1LLtJ7ZPcFQbiCq3mpKG2eILtWltuHcLizmrRIvP1xeum8nq1W/1QLYG8 QidqNJhvrOrgr/30v7z7J/cOKK+6vMh0Sj2WGdQIfWTCLUxEdWIYfBfv56rdekC7S4XwPjH1Bqv2 1UuS1nQnAqpxRllEZZBHTmgkYSkC21fTdtNRhKrhjqUyetK0xWPluTnsbLNXNbri7UDH/thNR0Ns 1NIoGmQH3xTvlEw1YJ2hZTuhsoL7uC/gSGVoJLGx8eMcMkqatMPa2i4iceYWAzxxFCQEFsWrp6T/ 2wMLfYKM+kQ+oDWKyaFp4UT4hvq3isFJhwQV8I5O9UWTtxQeDtTUXybYL1TsGC42R+zwBSq44w2J 50lYjH13ERPJRO9kg97F5Dz53dO5hskO1+Mx/Agbdm4HIxDxrUu1yBOR7ybxmEAmCBmEJm8Ctegd EMUG+uSdCaAnn/1NbcAPMDV/o3WJIfMytVYdp4ddR4mWU1R8GLmxMVSGYM5fwfSEVZMBhJtEjVlj YQa82LF4595F0Lx22S6HkWAoEB1ElsHW0LWO9sSyXjjzVstrYScQaad+tjzwbx3icT/BWPX84hCF FIcr5WRLGQ28M7xFmSOR4mEpPzZJvB0IwNrkBVjRMcca+W2o15AJQaYx3fU2KeYUp3UTWt4uQcQ9 Ht3Z1LiTC+i+w26x41RpQKuE6NEd3EatcINNPOIOdUaXDgz8N/1QJg/CdepRQp8O0nvxLrrwtZSA h8xqBXAc5NA6wkKs7hXZSEMjMw0iymZ6kE2eZiBlXwotBptDUVf5UOpV0H9sBLADJZmnF49DPkVT ywis/4SheN3ECIy9nZlBydOXPPiSyvSSTmoZiU3otMyEUttVftJV9ta/5buSejRvQR2dNrLSc9O7 R31oGOnoDEjrAUXWDPRnRB2FSW72eD9vfgqZ49i+WoMs0QPbzYcTX/PzdnyQi/+jTH27p2qSLItn AVFDBihb40s2yHHk8WYqPrxBKsxc/b4oTIvkzL8iCAAa52im+BivR88pYoeNRtryAa04rDwgafs5 7di7rjKfU78x9HLn/HlLxUzb7RKzQMO3mIbcSpjyirfP09ht3aAs6oIGTeEoXze8qs5MAFmK7NSo gedjZ66iDhlSc8cTI308R1emghV8QTtfEL8qAo4i5EjnKpRwX4xNqZ6jH83YhG+k67QXdw55Wli4 zhLqYrG7fxY4m0rOLxoZdqqfXVA7AbV3EDioSTbsiaw2kfYSJmiH3Ye+Mvpf8E7YqAwRQVkTmKg+ 7j2fI0RGftllR3Ens1pX0ICQZ+oqeb1Z/OSQTuu4poPoEFiuJ18M7oxtXoQS01p1pQu5ft4jRGzL 1x6DwAAIBLM5RWaHAJAf1jwjwmBGI42K2e7X7y//BwC1PXUICmVuZHN0cmVhbQ1lbmRvYmoNNCAw IG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgNTUgMCBSIA0vUmVzb3VyY2VzIDUgMCBSIA0v Q29udGVudHMgNiAwIFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAw IDU5NSA4NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTUgMCBvYmoNPDwgDS9Qcm9jU2V0IFsg L1BERiAvVGV4dCAvSW1hZ2VDIC9JbWFnZUkgXSANL0ZvbnQgPDwgL1RUMSA2MyAwIFIgL1RUMiA2 NyAwIFIgL1RUMyA3MCAwIFIgL1RUNCAzMSAwIFIgL1RUNSAzMiAwIFIgPj4gDS9YT2JqZWN0IDw8 IC9JbTEgNyAwIFIgL0ltMiA4IDAgUiAvSW0zIDkgMCBSIC9JbTQgMTAgMCBSID4+IA0vRXh0R1N0 YXRlIDw8IC9HUzEgODcgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDYyIDAgUiAvQ3M4IDMz IDAgUiA+PiANPj4gDWVuZG9iag02IDAgb2JqDTw8IC9MZW5ndGggMzUyMiAvRmlsdGVyIC9GbGF0 ZURlY29kZSA+PiANc3RyZWFtDQpIiZxXS4sjyRG+61fobOiayncVCB3Wawy+WrfBB7U8MiysD56D /74j45URqVLDmqaRlPHIeMeXv9xO3263cA7n2/MU4nmFP/ioacnbuaW0lO18+/307c8/6/nxE8nr +efj36dvf/17OP/r52ld1nUF6cdpPd/+e7rAjwb/AU7TusYK/42+l31d8wafBf7hvGz02Wmpf0T4 599dBnkTf4K+3Mz3St+RN/MZfOYnfH+Q3oyf19tv3cPIHoK57CR+a21p57buy4ZudmdC7s58B0fS /fpRl+3Sr7rGJVz6fdePnMIS+2HmQ3RGHFqvIR7JNJQp7ZqQWqIn5E9yQILkaPYiTyDP3dlDbggU PrRKrnWc7foRlip6hKX/sGwp9zQCsV0oL6lc/3H72wlkc9jjGT5Dbe18+/X0gcVQJX7rJ0mX7fqR +KLrip70PGF+GuWrXxhTQSa4LOBlktD+7xikEBrzPF55UiGeXiglyv299Lrb9GudLh4UtVOvKK8k KcHp5unGoN8auCUBRt+VBDkLnDM9uquVVjclqof/9idqvSjRxkhtzFPJdMxjzku+zC02zqWI8sQ/ Wtfw7mALeR8pmo7Kt2Nzfs63QNj2y0Gn/pMF5aqykkD1BRCCp6cGCpN0zmZjMjo4u9EgjfG4kk3z 1Snu09XSEiraSzNdPLsedkswLpuVnZWX0eB6xkErmYW1h8uxhXgLByRBbWgezYhFpXdzmfCpZWNS 6CD4IXH8biocJZokuPKsaKKiTQaFWCjTyvXZ9UtH67E0jvBL4bozKLi53JSml4tGzES8TGbI4WAr rHR2pw+qwCy+ufXOOmwRHmy2NGLQkzX7Ma6Ik8LnSyiDRuuHq+oiVV3E5p0tdY7s7FkxhZZz0q7N +3QmQtRInohLLMo2Uc6HXn6Fmb9dDm4KMqOF9d5Zd5PL/MN0NYvFhygs4a2ZPT7F3bmTsTt7+BRW +dLnMcmUuzU/4KC1QQ46OrrxspRxqaN4Yq16/1M6U7Ynj3J3qBIP/jI0jqOmamVRNK9GObCAFQEM DWH+cZ/saKYFi7U2l9F/YzpN1ypGkQMZSc0S63QuIwyRm8SakELTYOvOlA7QhpZyaFLqQsv1usqG 3mR5N2n+XDTxs1JHb1RQY75ZKm39xutLJuLDtPfLNX1gpfmSQme6H58TPVgD0NO7Mx2bxZlfAhnY hoEDrFgOqvfV4SiVHu75/amDZjNLoI1uDYmGgiBve4bVi1a75sGt1ZHMZVWkYsW6t/EyppOcE/oU 4Cm0jWSwDTSyZjS7EczcHY127Zg/eYI0zxOm37LNZ75Xa1k+uzgqEg5p/K9p/g2vjDL3J2OmqGiD WXoMwwAND2QUdwTQijqm9gVYvJoOL1kNM+16sI2kTor8qVj5aSUNPSl2HpXDJIgTy9hbxF2LRlv4 +i6mU2JdMDxODjprQn6Nf9p1uHNUaefgeqsXM9WQEV4oiJBbJ/dap9cuSOHTw4Bs4kfPxDYdr0Rq tobRArkdBhxLNTnZ+EQ3A9lt0eBenMSnVW882O1F95EgIlN+ulgIFhHiy0ujU81F6JkqLNI2cqAy bCrF0wOSQKk0cZTwSjTDeEDZGuHjl6wYGpV3krZ5ijmymA4uMKkSJfyuQSfuZvQF7RLGPnKZtW6/ ukhQB/oQewQSCsXIu9vHisCO9QWDOoTu4QVGYJdhKYikiD1sxbfbLZ/BhOcJ+iy1cIb3XsoNXlS/ 8tJO3b6pvcdEp/7qn9EBKIFOg2+kXuauHYCyyWxXmkE3yfstcb39dmpL3sH4sITaWjd+AI7L6z0e /nR5iEOkOHxsyx431BVBuegKm+QJZwj2PES4wk6vmDyBaD1V4bP7CDtjZagaqiNv1HIRHCRyc+Qe od2S6wv50yi/f2Iq/3I7FcBg9VwSvO7iOQIiq9t5XfJ2/s+P01OoYQcH6RhqtRFtb/3wmBZSXUJ+ R2x5Se+0xg5636mNBdr2ndq4QRreqf3ldgqQEziHP/pWU2cp+KMDmt8xaTFK0vqwwAagcUGPRgIJ tEl74wZ6JoRNAg1BLoXgDeZMCJS7TITM/9ymPXNBpZjQCwKJPZMFaqYd5Q2czflt3ta2xMqhiEtg YgVnshBT85Kc1WPJfVusIKRiCErKjyU7tca3slwRb2SBur01WArmWDaG9O5SKaY3gpCO+NZgqbVj WSg2MySnsoMAp3hOEcBr20svOxqagQdPZAA6Vu4YmCkNAIuD6WFX+1cD73h4vg61tFSY5W4qsl1S +6/g6A8M5Ue/A/ZFTqGPyw2qdC1jcbSvYsA+dJ/kiZR5x435aux5DABP0MOiDhs7P8wjrNwMVQNd soaos7zoWNhHDhAOyTPxSqOA8FSxeIqfinfetci+exg9ayFcKUhjiIX5x93JU9KBvl101dEPa0hT C7M1/KUgBEQcOTncy4wZOoKN1jXWhX7T67Ej8wDjxZTXh0c0lMn+6CwG1aXClj8MzuYzAIOMCo0Y 3lZ7W/bGwy+AVHpDN+jCFvYm837NsvCzNx3ugLqYuzdtbSkZtMSuTHToKw7qgo3L9NqrVMBhlwIe tBmjpkpLBgs2miZ9evps6Iix55Pmd7JQOwhTKR1t2dKWZgxkan0uJ2zAdQwlHALcpIHrRt8JsJSS oEBTL3KOTSovmm3EQr/XVxn7GFA9XxeeZ5688ZqLwmwzkj1+4yflTm+sOrJoj0svxGAmgBA2NpKz im8LGZvbqATDjhVvAihT5+Wq8vAEmXDFIn7HUmRhPEkaH109CtBQ/BB6+AoU3fuwa326l4kEzA3I 1QyPPA0PIUISCf5g0u7G8LuJkVt3RrOtCj7DRCeb6BDG5LUJMI874UF65aixKxpRO3VFZ2UahC6S jw/eUPhO1Bi9KyiA31og1TiLqciX1ZWJazIip6lENLxG+vUYJ82dXJyskGeYsYDbUsYS7vSH1wcP 1jgutMO6EYNNFB+1axxV8dDZJBWlo1U7+rA4rhT0q9yCJaLLK9Hw2/tObYYRV7W63Dw7LBbC/y5R gKyj0RDG5Rz6UV94bIU8bNj/mFGsYleq5JTEcAomQQVVVy7EUZgZlKGR0RR5B3UCghi0ApbdIfQd oa172QdCy18htPoF8jxAbd23Yub1EaL9v5BcUOS9b7K74Vta93MGJBMSQHde3UFgd2hji4lDSQy7 8+Y7gLnRDMPiRoSHlS9AIqaOIDJ0V40ejHw/WJqxVaxF6scNi6k3W72M2Di+el2pHNoIsCSsK0Zb DZQt0kplFJ0oc8mrPDaf75IGclskI0Tnw59bGKe8fQ5suh3ewUXM2aYzoVH9U2u4VceHvOLduhP+ LrhJE/PiS9rdjLWubPLzRSGtQVHmLkxlHnapWCa3AYmEeF8x+d3SUu60Skst47aPTY4A4NPR4B+v sdkL3Rqkt7loy8TVJY4T7ZN14WYrHEfdDvLecvuF9+EnR/Vuuvkxvh9OEIaYAoHxbMfx1C0c8wlw PiQB59O+bWHMp2Sfae/U++binl9tI01rX4GXGVb3jjVw+0NEI8G9g/kwwJK4wAMBmjeEtJ3hE2ZB Gi40PwM6wGsGS8ZCv0sUStn0W2MUVdIXxGMtUqpKeXP7rtyvY0+57/LNydi2l7N8XSc2GF0QiE0K sE3UA4P32efB85SAOPtM7KCuV7WO9/YXs2fVt5FgQxw5+4hIZixo8ZJFbCFnvG+e8HLu0LU5dz0l A3jiyeVVH24CBBbb2PeOQQzJB5f2qbxfji3tMyuMRJnFMC3CYzxXx/aXlxumM5fFgrkKGSwXT8NJ bZAefjYH/mZ1eG4eiI7GCM4hL8dwH7FnXDezGLQo5SuYUbXI6OAXRFchVRELA3n0xkYsasD6riHQ CXZepvWNu2u8FJh1yJj1nFPF1YHVXkZFqZRlQsApzM9ZbW5M1XtEB2zXMqnCEO0XD6j1HlyA6fIa Im8y1GMTlMvFmnN854+tvORQw8abbBu69HtlcJCk7JLM0tXAaw58f9XyJGPowMw9S9JEfHSkNHOA 7eNAaU10qFodNealx68QM3H/x3m17DQQw8D7fkV+gLBxnJeEOCA4cKxUiXurVuJQEPz/gUmcZLMt VBXqobvZxLEntjNT1xfE6QzxHk3qxuVslyCXu33wpQfmL+RsObKme/ZzJ4elHx3Xmc6pKla0JXPW Weo3zi0rDJh0aneFdPa1t7fls2Ut8cZhZKV9+MXB+TohLsqtwPSynb4mo97V5IOeIUIsMPeKcOtY r4wLOqrvw/SmPjCvjmaVcCefZBHHpJ1X+9N0/3oy6vlz2uD3tM10wgmdkFUwjEqJeZuoueiKQip6 7ttZOpSTtJCjBNHXycIn7RceQtSkXpFyWc0MsSRtFcM5k7fSHFVmh9wigWfNnwDTjKlRi8qpRudd NbhZTU4aV+7FZGTcP3eHuBgN5o33fWNYS1b72PAGYl559GFWlCi/COAkgA9mCcyPsCvj+vM3ghya GC0PcJ5gJ8COzwtF/1GsEa8S7LhCgIzTjlY+W4Q/w3XLGgpSnLbdaeSIXecIuoEOiBQsOratTaed fHh0VfbhoTfWxZPKY2viEa49kFiwWddzx3QdSyWQBkUzUohxaKOZojoRq26cvVR5HzHtqaiY4ty8 q71qf1Zv1pTDJZNw+EO9Bf674PCtLrPB58QVMHkouQYiRzlCivnv1kLD5FJoHBawVnUm4AxBybn/ CDAA0JuW7wplbmRzdHJlYW0NZW5kb2JqDTcgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCA1NjAgL0hlaWdodCA0MjAgL0JpdHNQZXJDb21wb25lbnQgOCANL0Nv bG9yU3BhY2UgMzMgMCBSIC9MZW5ndGggMTExNTMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0 cmVhbQ0KSInsV4G26ygI5P9/mt1zIzCgpokaTfuc3XebGKMWpsPAvLGxsbGxsbGxsbGxsbGxsbGx sbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbGxsbHxMEj+0P/oXIp6 15AVxpxn1HficQdK8e5fYtyBGjbXz97gdp4FVxh2nj4C2wojDjRkBVli0IHaNi/c9C42YIUR0Rh6 pr7F+gU4W+K7+TKaMD/GF6YhP0nyt3Mxsh6NXGGY2o460aACOY4va+tRv1T69XpXGHOe/jV0hSEH ohESPvJADdv7z1Hr9a4wLBKvOtBQvvSu1LP5sO3HFqQBeNeBhmimXHQv1bH5qLiOal+HNZ5vOtD3 8wX0pb8cDl1hRHl+3YHG/Qx4lYEZA+O87/YoGfr4zQhdbfoV/42RXFIC66e8GIYpDn0T1ohEI/4O PGYlNYUYgeNOE5nvDEGTxKdXaqF9On/T8UWE6S/vuFISBiCM5l7/6XxilBDhlChMPbTfKSKn+B7C bL68Af8gX3wt8rWJxGIAYY4LCZcGTitSjRSZefHPvhRfQxjgy+qYbdzGWr50L0RbXxrRFvx38+XD cxJLQr3+RTulcmC/mRdVtCdvLq7z5dNvQKWlzJe/oNDBheNJmS/yei2uP8mXxsy/mS90YYb3vAx3 xgV5KBWKIWRpjOiMMD9ptDqSNxl22l6+mG12E5Uwpi6JNQQ+20jESXpQR9hHtjD83aJzO2sY8FU4 3f1iyapNIfecqjMpzk/TyUjGsgD870WM7SO7srrnWbeUba2Jfy9f6MKcE76gm/n7/DBTC5tN19za PmRdFkMPxjo7JEVXkCSRUqloiqZxqDXz7+XL5RaqMoP8YwLbVJhp6qLzSdovEx1RndR1CQl0XJVD uWRCpA9cKxYJMokw+jXv4sV8ueJfzmaALCgNimFyfHF1SUgmb0utkfKmgTebREgXER4gDLghPjPZ jyLxvQHfz5fPr4sAcC1MBHRBKUE2yCMJuOmGTkdvQ8gFq25JrCxxnjBFX/MAo36TL/Vac3V1JABU k8o5oHKRJV5owOqBJM+4qL3kXa1JiTHEeSP7mKs0v+dfLjz/8LLzvOg+TrcTS6I00MKmqmPSgqln UI4Cb5znzWe1pLz5vebf4rv50rs21BEtRnQSKuWJ3ZDWNCLjiZAJ7qGOodsFTbIsl4vTUFKcr9ks 3f8GX44Bqjywo7hHSVK0Spk/NXuiD/RGe6RQglybZC5oid1tp8vv8sVZkuMazGu2scoIuTHK6aPq 4PyMsMlbEZnpUuU0Y/PlHbtT+IRSUdrZDIsbBWqJOzEJ0QpFYmxw2NjAJ/xYpC/tjcSv8iXXl9Af UTbbXEgYhisMeEEnQqPjPE4lb7MQibr1pbC2p4sIQr6zNkZqcnAYliPodpQcrLex3zGTzG7oYlIf g/+ad6O6DvP4oq610DhBZ+MiqY0RTELxSB+BRnlyGAXGvC5l5Hk/XX6YL8GMOGaYKSH91Nx6yxPb Kp9dsDAx3QyTvJ3Jriej3e3+NF+KFuW4onyIpRnyLRXwJ0pJaH/Q9/rs+BmxZD1IjBOMielszNw9 9Dp+SIuN/+15RyOVRVIscmO0MSdjw4StlaNHvJ8EZ/tborgOU3fPVDj3JRwdDHEWW6g0xy2IjdQv Y0NSJPC78NdfTULR8N8I4krM3b1IF1YBgDbHZlB8UQnhChSISk4Aq0jpTi/7ydKyQiEWrTGcjDfs ntRZtMGJdf5T1KKlDREMOSGJKcqzG6WmgwI3sf1u8/ZacqSauAKUGWDmJCjKLrLBjC5WvDh3wp/V 5QnmsB2oNWTr8Aa+sFYkZilGFGf4jkpnmb3BIqWJNsdrkhS9yxz/ku3ZE7J1WMwXMbdkV6GDEpNM xhqKN1qbsFnyycq0BbJYJcxAJsWldj1qPYA6FAIm4LmAGnotJAP+6O+WgEBnWTNeedbM6Zy23+07 gHne6Fh0GrlpduPaoyMZsUnKf94wdToq3/FewKbgiJB8zN69CNAX72SKk6x7gpskKMAasb/Oxyg1 opRMa5AYL7viNQfRCbyBL1hqkDJxCrOyCjywGBftj+AjFBZGeuiIs8cP08W2/ia/u5Yv+YY5X8pz HN2RLpQ8b8j0ZdWIxetBoMAMC+DDWMqXkg6TOtmK2WXzL4wGJ7kdKz9eUrjcLsUyRTNNjJXC9gjO Q6EedZ296QBF9RCiBMIovZAj+A0o8kQ9cFKqK9mbaHm7+NL+ZiPSfuv0pd4XFPUFVaVQjVgVxGVc uiN2CXoZukI4C9gUreDL2Z55cxTvOPDNEwOqC9kjHJcb53WixMyrTF0xnATnGxftXtk040tWnJgz OkGCGVMuT92EkK+Lae3lRWFFrZc9QZyCtXw535OAMunCDQQCYW/q3C3Dfy7tHNIGn5Or1t9pumI4 Ccdpgd6v8S8c2SSND9BE3tZ/PvGstDn+IWWuictE7nSFcB3exRdyM1NBCY1R3hxButl8CyN5joee DdHWxKFn0RXCdZi9O5V2NP2IXjaKiqfLIetCq5SFgyjCFe9xIj+uDo9HTwRXYvrucUNC44KEUX4w g3XRKuX8rrMuYH0+cuAykcZBPMGoAM7F2t3FcghrUH3Q6+InuuDM11qZEj3ikKc8eycMeYo8PWH/ p/mSKYLZXdAX+wf3YE7AmrB4et8eFSkwuSnyp+gI2Uqs5kvSl4KSHJeiPmiVjwcsBkWZgXyhvCUq 1h50N6f8GUsubq9I/xpfcMeU62MYFSQRRm0vm6gIXdS+GF2EQJATSNHHjF8xPEPAmy83NiTdmVQf zImoepiwaEskFLA7yXNwKpr5LPVauAgvuDL7Ie7o92sL4Eo8tntlYSgvrqiYYrDIDs6EigSVS8oJ B4HJCgxS6YQNJ4ZnHG/02GMDOwlP7V5zdM6+5l4X/a2wRCXFL5ykiciZFhGrOKwPMybY5ST/y110 +U2+mDktbafVBpugSBF2o2lBVR5WTRFpSjdqawoEsNdK2vMpy6OQjtcT2nWYyxcZIqUCIV2sE7L6 7owN4cJKDq1rKCCyuC9GbCOT1KSGrtCuwzO7E/wtPQDeWOikASKjTWibyAijH1qujiyQN7Gu/PBF kjzLJK2VXbFdhUd2p/AZHhHwhsJkbIDSABmNRMdFWpQCLMKhSkS5jJR5sEJnesL+g3yp64v3u5zR xU/4uxdhEJaongh/zMGIGgEPwOHyEmpEgB/rie0qTPa7iSGU0cK5WzQpYl/lTaAIG0kOFv3lA8qQ UMlyFXN3L9MDoGZ3+924bGVpUYPseVF2rLZAf2Qu2XjjhARMjLLtYt6f1yDWktsc2nV4avczxaXy c1eF7JrkB4lyAV3RMYeNJkoXqWWOCi+oSbz5cmvhmvh4Dsmd+V2CHoe9vhBWHleR8rFSBp+iRmW7 HgPzo3z5tGXNDOO19UKpSBEqCVvpshxA/lWI7mZzIDNqK3cQ5l/hS6kR+jAdFMTMi1UeIAtkICZI hl5QiACfA/ApjmswbXcKRImNUXGyEUYlBkyJc7vKDbAwbyRKQvl7XwvkSszavWJmueJ8w1RtQMH6 Kl1gyLqnlBVveMmXBH8/F/Ll2iK5Dsv5Uvil2RBUImiXVEvseeJPqkroX9gI5PojlaiJJIFT2Ndr ieQMpJ+iFvSpu/sahJJS4wuMJ3siz1LY9VZsDCNhTINWcOIUQvaX64s1HPqznLZ73esWTuGsS7oW gVF7K5PM0sq9TQJzg6n6nM1HkYTt9f5lJV+qmxWapbIIQfpT1BllBPWIpHOS7sml6opteZIz4s03 X67tXhiv6Etes0RIiKT+gAth+3pEMqtAmAIhptYr8+DtkZyBCl/aD962+4UH2RDwhVQ2hD5HDphM f9JDqVPFlJ3cFkeGAQz77binFeZgrb5wLTwf+GJUQcIgXUxOGFkib1gBew2Y4Bs0BHIOZvKlXnlK 49kTAroQUEaLkfMy3t0Yu45vSdLB6p/VSBrZIjBncRwLC/sEvtyLRJEw9okMEN8i7ZHVHqWINEqm Lqw0KbZHF3qmR3A3TDE2D4Pm8aXqVW7PFllhU5ckGcdjUrWBKiSZ0ErkXW7BvKyiS1P4Z9YjiXX6 eGj3YXwRSmd8kSeWcCOKdkussk86scaNouo8jFtRikFZhQd2vydcJ7PR65IUIbG1bNxJCWblCkzF cjSHBp9hutce3lW4u/vn+RQ+O2ajkWVQROgvVEHY+g4xM0AfnfAiA/Nqvzto9yvfcZi+hFqlM1Os hR/WIKlXUX/sxCVUptLNPKhpv4tv4su1mjvc7/o70q4nVizxuMxAmAt58xfPQ3nbgs2XE3kRUthM ElHRRoiAMup1rT2qp2sRoF+7HKQQr3W4tfvVSnMvEtXZxIFNwgiQGKAKS/skL2fEKNaj+bDjt+B7 +HLdyd5XrZMH5AbUsySmGEm0jVLuUK0gnYjPDNgXaMD38OWmkx2AvFZhwyNmxiqStUhE1iXFVNFq hZHjNcdkHZ7wL+OQ7eeVgZUewA0W/SmSYnEpMjTHcfPlZLsYVjIySCmSPog5aMeplHCVUbPQHpSV uLl7+8/i2urZbUYXTbNUn8zNkFOXc887mjAX1jPCDwnSZNzd/Vm6UHS3cgvOSd1qCroRQ83Nx6yV yfKo4mQLt0dpJdbubpDaAgKGHLGbI/bqXLBCgbk5T3skxsSyBExtj9RCvIQv4lQySTEm6Q3Jn9AA +XJVyFIhZ9U5TyBStDVUK/EOvighJOsyqKqjdyIOLEyyBLBRoUQb/GmfTJuGjlitw2v4ggywUW17 lDAp0/aGjLClHjSnkCb54+kyhTZuw/ZYLcQr+GI+VuyKDnunEsqNvGaGAPhQIQAIUlgsJvZhdAVr Gd7AF6FHKjPoeLUakTJJDS4QSgigj7SJqqZ/aSn6O0BftBbhDXxBp8J2JNcyifqAqLCOKwWMYTE3 eoWjxcvC7Sj4DbuCtQqv4AtLs0PAF1EUJylESiFxL+phQImMREUZOaHDHMkxwWyL1To8v/uVHdDr evPCyghrlVgUx7VIx1ybrMnnnAPw9HKKuwhSXPG5eD6Hx3e/9juyWQQj0hIJOUiGwaOoI9a5aniF SDHfWMEe5MMHtAd0JZ7eHQ3JnXOYGdEyFAqT1KZEHltHHzE44xNuLHG97YHffCm+pnUn6YXY3//Y Lxc1SVUYCOf9Xzr77TSpVLh4AQWd6Zyz090KouS3UnFYBBWJd194SeHRBTBzTG4jhnZ0RtDWq9/w zasL/d0ekx+EWVFqkdQ8DqxJUKJ8ZqMvqh84nfDR+UNben+4gbSP+1fPTUl9jOQHNPIiJBpmU8yz 4gJUgHx+6X2vyPR4eMHs39O7Q/zLNF4OLCI5MOJtEmNiDjYNgglO1xc0SGSSWWAeQAniY6eGtvT+ WMLLrn8JeacJ7HftCHdRqaraFNhac8EiUCjLUMwW/xrJe+e05/vdRj36eYAJq26el/yARlxyusXK jYQZahR5tfoI05PExaJnM3sn9gS9dhP1pbQnxU2FMa4YGmGLVxFBhVImgg2uspS0oTmI0mXEJb17 RT3ipmgSL4e8boZLKD71+xQBLkYPitQnLUp/7d8zZIaL7bX7eV2U4t7Fy9U3G3obX4BusF7SJPQY sC5Ja0QYHfIq5nCWx0CDNElf5ApeBmxa64oNv7t5xLCgqxQYWNeUW13NRGYyPrRc7451zutaJ92o 3+6p1ffMa9ddZQxW1igp5e4IAyR4XSMm/uebsDieXo8uWf0GXsp9q2ykZN8yD2zVKDjcz3WoPYIm LWCjerB7w1bGmdXvccgbdFTGVj2wKyYnJOEdEqb0b2EM2Jf38FLvbGeszFMk+2Y/JdGBypMyEpIU nE7ph++Do3Zs3r5dGMv0pUeQt3hJ1YeRsHVSip7SG/2Pgc7hPbxc6V+sXhxZMn43c5u55GRXwAcM MTmbZjVa4Gm6d/KP8rL3hjEcfIS6ocr1TEXAlOuNe15najomHt1b+SJeBlS0suzmxRyKDJjWTpu5 TXyomxklNnaL0s0I4fL1hzi6devi5OoXViMtKlLNkJS2dpMXh8SEJlU+pGkbiSmK83mIP+BfLruo uFTwrCgl9lvCiGo1Iu0Ra5asLoEeYaGZzUgRX17omjtXNeXILCtbFC1+/XzDi1nYF/Vy5FxoNDFV ryutg/cEV6Su+HW8HKjNNZGgI3VsVJORZTGnoVR7TFmIS/H/Qu6CAZ4JTN/m/k1evExkNyLxR+lf gEU6Ig4M+VvlUuT0OCFZ7qaSMgjMb+OlEIXGoLIa0Wfd78LWYLTgMgKFkdQkQW/o0xRqTURSh/Z3 VVy+emk6GsNqDiTMlmKY5Me4hnmxATjALpUxt76NPE4DSfuB+WW8HNOXRocTW6FsGATDaxC7ZkuC 90bwK+570kiqDfyrwOZGfugxzsVv4+WQf9mfVuEp2hKQEipSgkNwzn4zi8dBuAkYu6+e+Gu8NE8F DSjGB6WwuqL04ZzYP6W+x4qSpgKVm8/jeR5hBJ/61Re+5iYuG8BUzrKYfMqP80j1yC2uOlZSBQau 2A5fAMMZYNCk9e7uyrhl9R11aZ8uz7rxVSHhIHcDITF+rBohL8BG0XNVADG6aobmJm6u3twJMXv1 PV5ygQErShpiJ8zXqumMZ9tPJlBAxGdeO4sTo3sH18Xk1bebJymAccfhXlf8hKm6mPzYF1SuYBsU rllyHdHpwGyX7b0tXBVzV5fsMz+LjJbjYUDIv9iXcCLlQokHNytcpcKp+8tQFl+/e3y5pr64fy3G o+REqDCDqhGEqgaFan4wY6ad3itDtReYP8XLtn8peaHxblXYiCix4k7HVQTWVoPYRN1ZUI2AdtcO 3h7pHvH+4V6fxEtZj8J4ExchStJ4s7iYLVaijBMlRCpsaPvUjdG9g/cHFQK8mvNWDzey1x7lDVKG jzgoVKTcvgAgRW+UrG/2l1hZoC+dbndaxoT+rOSlviIkpNxGKX+alpjBtf8TPI6LS5ZQLwVM7O+W 170LJO2Ul2kZg7Iv5qUWQnezc0fi/8z+MiT4SrXNlMYoo4YpIjG3InXv1aSQKi8Dd35ZeHXZVWl3 KVx0lDyvQi7Mt3ympAftROJ6jHr2qXdiX0iNl2mrb4TlWnbvR+gzLz+uKaDlk2lMqKc9HNdZCtO9 819exBzGgbuBWGCaUP0hx2ymlitdLWslHpMq0sBuTYqH8pL1OVvjFEM911SQQIlLN2rUz1nDIfqX raRezwku3b9d90cE5Vm8wKVq83bcu7LfJWcLeRfXngKXjKWyL1I6fW/sG7WN3ZoRiej4MW31nfDE 1u+Hagz/EJopNNKP4zlhk/cl4+H2ZXHGnsAL+psmLj7Gfir8Lk+jhokKj0+SUI7Y5M6P7t3qnXhJ TF29tZiQLDSmRZnI6k3WNTkciQ4Fc04SatkKVJ5fj5avziajPClMRTkTU823kkuhWXUwnB94E7qE oTMZmP6K9Dd4Ea4o1bto7aDhQtPpJ/NC5QraI8hMeqtDc3S4T7qUFBDTuZMrY9LqXCnq55vVyG0t cBGjT5gy8cGAxjsoAsYyFsXlBDO9eGn41rn3f4UX951n78PFgi9Weh6zIz6PKxJ0ihM2lP6B2FTb 3a1cGHNWp+anY0GvSHSFUKBsIBwwfhsxUhQk75fiwGnIfPVlcxFi5vx8MjGwvk1evELFd5loADZr HK/Vye7NXBbT9CVrZc7dirdIAEYkTLIVYt0CEV6RwIapDLVah7EZocsA/fZHO8vsVOwt/5d4Qc7V 306qTuRr7BRyRO2Si4o4erbChbi0RlkdHNjKdTGTl8092qYpmVvTicCETxb6j3okUh/rmvgtJ1yq Ke4WkzYwA7j8DV7U07ZxI9vqAyiYB55sby5Zm5QeMk9F3hyXmR7my8vYQl5BNodwiyQ8TRNSAsPi pokUJJheF5lAkko+oMj1Qlz+Ci/b4R1N846EAOEjbGFgSBgCUiavSLE5Uhyv0qDNHwPEjG7VmngI L5bzdlUir5tNIiXhmkSmif58RsYWiarZEQMzBgxWHtupVfEUXqjaNG4J3rRxLtWo4HZhdritQhnC i575mn0qVlakLy8/QeKxAQz523gKtYnQ8SLEpiaqCGRngwfNDozSgoLZvVHr4jG8sHg0RYSsSjHZ xkiEyk2MWV93KeZu0EJ5y7SHxwVFqXufVsZzePHmqFWUZOM8lbKgUgEXp4Q+vEbRvzjm+vj6l2si OI/qWW3xJPkAB8gKErvcnBmHyq1vHy5HZw1s0bp4Ji8btpeFIz/O9Qx9jzIIdWDQJ4l5HB6k3eRs sCLdW//lhYObm9aI+FmegRdCMWJDG7lhhDRHrMDrQly++nJNsKttj9i+cWHsCjTc6uYkWHdlhqYB zBUA9W/8l5c8MgUpbjGoT+UBInLIEFcZQIPiAyEqzIteqzBq6w/uzq0Rdgkfs1Y/G0FByleReam9 qJQNITFRShhIYSwyYHaTPnT+4f6FUiD2MW/1s1H0OvlpkqDsRbWnw6NS90M2plAPHxRd8Q3uBQt1 782ECGbQD7ySF65GmcDgp3CblXLEtiQDBsXKzO4dLpcE7fG8xD3WZ/NCaae/rWHC70KwLj4i1KQa Cy48t3dH8nz/khaq1KPP3T8uMntVv0WTEKF3IWUCwiN+yF7rOipuhel3ixYdACkZpY7E4wbnhG3M C/QFsaMvEI98tOfDtZ/TFWCIrkalBlXM9xYtB0DiDPTtyIyI2/oOXur+BScNjfgwwdNYJQIuWqEh N7daDNHs14jCfFZ4dH+UVgpt0tzVO2OTl8SKPxgXXB9jAJhyqLrIUNaVvxcqUtJxhpfiSt07PyVj Rsj7eMmzH095MTIJqfdMKEoEA3+Bq8jYGXW7dWc95BrnZCzdIO3SzNWHYgMXeEd38oIiVQ78+S5R WWAiReiC2aAGC4do0vzHK3h55urdIfhHuLDeZAYGbwh7lNAtoSsalZR9fgjzzkdfF+/kBZYFdsSO 4sUVHgtJ5YYq4CKhaTqgLZT9M6xglvYKzJeX05HcK766g/G6472gvcnMizdWAZS8CTqS+xOcBDvd u/dfXk4HFxyqRuJIhPPomowl4EJ5NAEK2Fxfm4xo4Xs8/fDr4o28FMpiv+EnI06KrglHBQczGVBh zdkXnNNEmSnX3r3/8nIyHIUSF3MlXI2SYZFwCTrBjjcjSLPvJR1HeWGfRMgMPP6aeCEvKD/RNNrb m9KeRtqbnKUnWGDkURv5r0PRGr2DDVTwy8usMLPq5lZRjIKT9LITlYi9LgFjTVMNkiYzPSZHv7zM DEhGsCSAoxzHPRTapUJgxDGqk9E61Gtiuh9+XbySF4fA2yExQ5sJiZNi6kHNCSoDE3Ms/TSrR2D8 /s4/+8p4Jy/UHBkuyHQ2iukQzETjVCRcK99qZ/nAeSfD99fx6Ovipbz8hAgVG1FSG4xQhsYNMspB gCB+WrU6QsIpWlwT+566c7euiRfzYgbXuqKKKQjFR83RqjJfrhHpQ3ONwZ9Cew5zovlX7d76Ly+d ISn/bmYyu6tsc93rkiBRQ+SiYiQWwHT4lAo5X17WhKfYnEktC+wUBEXJIAt0kIwoH8olKKa/cXwD GNLErufu3bBL4rW8eKbp18/X+nBlvytETZ5tqnOBCZeiwUhX737w3omXxCt58eQLIPEXtvpIECDK F7HA2WxyEQ53gMOTxx5+XbyRF+SUdN2BicmQMCmRwt1UEp3w6lupykDhY4zLGXSw0MDTr4wX8uLN kNK/+MvHBmCoJJGOKEyFuyHPLTVO581Km5qhx18Xr+VFse1OSMEL/RCayBcQOGAWAOqIwE7ZIPWy ozoAzJeXc0H1h8yLhm9kZdIgvNLBsagj4ei4T4Ez5obqHDB5/aJ1h55/VbyOF0ajdLjxiEBPvH3y gqMhg7DB5HeLFqlAoUToSJjYDW3AmngdL1npyc9IZYyEU25QWFJyjKr9USCMTE+Liq1TX32ZFTVU Psdz/2JHqG4l8+D5V686SrkMlJiSnNCS9lAntf/x18Xv4aVQEjoGaREDyK0sOiSSj1CtYu1iELbU pbQu8VT31s/J2Ofxso9pq18b9VfTxYXsjBS82BDiBIdCkmNblOO0JyStIQHDzqefENYjhI9pq18d bVxy7REjRhUtDukLUqd0ymb5VKNqS00aUVQ3fGk8R9fD3xO/hpdKuGzUjke/S9SY4uSlyH7zAc10 oo6Pt1tMZHbSOrHeJ50Tv5mXirbwccrOBjDonLh1Qv4Zit0qRBNKdfEy2PWgs6LKi2nj68PSXRy3 j4q+qDIkYrXHk8tqUfetEaN8TGjFAkr1m917xHnZEjis36kvhdfl4zSC7C18rM3kdkiRWrPNJR8F MplVyZUlSNe3Hi0NS0BpYMS/YlioOJhpchIMh6r//cd+Gai7isJAOO//0tn97jGTCaCtQqHazO6t rSKI/GcyxPWvCk2jTYsmM5jMuyu1h4syMJvFUEhBHPZsQbHUso0WAbcyGq3PxxoWq5v4052f5wRF UB7JSzvvxpNCtch3KYKLMbyIlXA52A8Fq9knitOvRexv9pftTyUepo0+RXv2EgzGcTGP8RK1ARLX 2fE6sJeGu7S5IsKuvvu1K/YgXhThlc6EIy3932+xvx/YB3IKbZsKkg6o8G4a8bgoeMnLckm1Qwr+ wpEYuWQDgaJvC4FtX4Vl38u+hx6k4gOgJl2Z5EI9ipdGTeIT8Ay/4IVJ2GV2TIEXu27zokop91I+ 5skprtMP8RKrkcHjlMA+tDCLChRtg8WZNvLDRaozviQvA9XYdvj2R4uKZD7j69mOrR6GDZRQuIpq FCJPcfQG9XOenOMq3ZsXaf9sZ14LKMAKxqHVqtcsNECq25W+Qxx6eNEuXJKX65I2MM05CUqQX68q BtKsFp/crukahwoVz5wt88tsNd767kJI8e/fOa4PcWE9ojRg4PMET7ua0TkO1MnLfJ3hheIL2wuS DDYuXkPUa1hBRsNYyJd2HMa+GYs9s16nG/PSLD6NhQh518KDEj1YU8V3I0cjAwEgD8jRYKKlFKfU iOmc9irdl5dmuG1MSAgstpfCUMhq6IQR0rSK1vfDLIOy1HrOs/Neo/vychRuNeJkLUM9om2R2Yal mC2WhlZkKRRUCpQOylEM1OkvC3S0y3AsvBFxsUUIspHCSKyDMsEc+Md+eqG7LSv3zXqdHsoLLkUT spoUqhGAQfC14qS+bSr9o6xEvtNqtfBm1kXfrNfpzry0wi2uRJzqCLN9dy5QhXw9EWEsphozOxWp KF0lLEJm1TPplbo1Ly/Ci4RvMcBgY7Rd9u0QvERx1SpIvfyOiHXRZsfPcuYdOuc5ujcvOyJ3KFyG ELLMsv1wZLywuKvgSm0nhE6ZfkuHoTzdO7lVeiQvlFNiyEHVQVXZmm+tYh3xgMzbmxBQQqApcNmN v0eF9L25rdMzeaHCYyHETwtcwxyD65VfhREQGbWLOGFakKSRJr+S/vJ1Il5UlNHxYOsbI4k4ETix DMGg2Cik8iVCqHnCCb02tZV6KC8hqvhXJF7fpBAwxIeHG97aUJhxGyngAR6VEbFLpb98l8hbNG6U to0R0iwHW2tCWRjN4UrBN9TY2Cwj4hKbhft6prZSD+WlwsUMRhgBKfLJdivxInybI8AgkMuUuycp f5MZdc5slZ7KS/AUP4O8CZNR+AK15JDzd2u0D87DhEsdYRiaAE/fxD4vwYuiw7TRF6iIL/5D6ANl BBaCRrATCsyBFRAmURGqejNFTnZ5Yh+X12I6TBt9iWgPQuxgiRUwIMDw24jhpSxegpPIzg0s9Ohn x7xmiXaN+nxeisXnX6g2qk5Ecc+/XyhXCkOhFd9MqF2NYC+2o4rbpxHT+rSewcuVJ5aAjIQT/DVE HRQh2k5ZGhZCSVGgKqMJCVmJt4tz92eboWY96nz66ZKLwDQKlO+HKOH6GGjkudbXW3C/0VOzAtNR 9O63X5r7xNXyx9XAy5zRhymWltN3Sv3diHAEBCdRkSys0F6H/brFS8DKk1AXMPZ0c+R/UT7uj/HS mDqwCX9JcA9YhHrdCUsuXqOqCEPnVRm2u+RdelO35OX6QxsEQoSEPrFDimOIZRgle2YGfAMVAkyx G7JihgB8WVNWrPEu7shLsdJn78S6xU5idWpmXscFlUedHWyfAiDRZFTjjZc1Z8U2pmkyM0cfpi5/ wf9FVQv1pwaFogug4G2ScULVCBhR3v3XaT8ui1fsZrz05BeKJ0UvEiFq5F2OLr7bUcalKEHU1IMj kLo0A+tipX6IF8KCVhC9Vrxw2IFNkH8oFx0tcfH6FMe18Hz5xScvp3R9KyoMW6sTKtJFzjMbUS7s nEdQZxgXrk6Ix17DLk9jpW7HS8cTU9bdud7K05vTcMBVTyKlmbRFnkV56OIsrt02SPfjpUf7f9V1 qAk3IbhuPlMXH0KGi5bFW69IIRZdmsNK/RYvB7jILi9mBoJE08oqe7888yI492zzVq/Yj/FSyVcO CbdqspmFIqhSTqk5qXCx4qVU1zqASV7e0mce1FIoTKQeB9scb0OrXn5WDOG0mkMRPdceeaXuwsv1 /cRxr0guCg8p25BlaGyrO57CXoMOlG7pwCV5eUcd75e7aHe7XeGYQk3YI7yt+w4BEs9ZGbLvti0y KpOXz6mfl5ZBSbgStrx2xn4YDXaXAUMkVS5TOhBVrA6/TF5eq2c/4T2U9wuO5jPmAcYEChSZC6Bp xJWqKFkr3cgDOdcnk7y8lBTHi13U0cQ+PYw6DqhPtMGhTOzBlTgQUGHBRcGHR5deo1ypW/DS7y87 HUQr8WhB9MASEHFjRQoJB1kFBcm6VW/UCUzy8oY688ueQXm3iDK2QYqLrO4RoT94ibNAecUrEuIL dkrdc1mj3+Bl16Di33oMLIrtklcp0KTWiGBiUFDHnDhq0TGT5OUtjaj6rR6k/m6pw74rfrqXbA0p 26r/2wkvCDmZXyao80HfMih3ISsa5CceaN12zF0ouSjjU9iUw9U5k3W6DS+9esugLLPEZLtdQbrF ngguovAUgsI2RLaroiDTN5GV+hle3pophxSJiEnYLym2PpuXUJQpihRuhD+lvzxGvrgefXHFQQnO Qp5DmRd1iv+zK32PuFLJS1QARoorVlt8B4V8QmnW65QVMHeaflySly8S+YVqhYvS8qsSBdtP4wXN AmDIv5lfniIEjdZr8Sy8RVaKLKrKlQhbJurTresuvHg+s8PM0W8g3xC9AAY8AJCQdbdPSruqw3CZ ygvX5Ybn/riQR5qvxQjAHkk0QsEFSchb2LP6cZmzYl5Yk5c9wSfauKhtj/7amoeox1vPwMAFJIk4 OJ2P2Xn/26Okv7RllXlbTs+7ZSNCybKLbiYCiIwkS7huKw/hxaPMj8r3N9jM7IYX/wasJABjGyP1 XZI6Ur1/ojJxtWSHlzmjf6+8xBwlUgmfxIdEfiwEU4VS2i6NeOfJy3RJ8d2Kh5ILNG+wF4dKJCoM G2oRFSSwcpClrz78JyXJyyZ2EOEztvqtW/wzuodvmyzrKruM+oHzctfTz1HysokXzY8IIO13Elaa ClcMKPhqeBhC9rHT+9nHn6K/PwShw8zRv0fF0vMp/ns6uEkVDqNOT/hBjgLPQf7tfvx1+j1eCl8l TApuytviSVp6CZ2IeobZrgiYGfC+k5epqitRFWLatbp6UxK/4h6BiSuFGIlZ+vp7T17mqmSh8Aku UO++HOqSk69ih4TgWw968flX6fd4qaMIn2/UmNcdehZEcMHGyTARtpee3Ju8TNbeYrGnyJk1FWyr gIjQzoJOv3qEdx9/nX6Ql51iwCEm1KVWs+KMEF8WdRFiuNc41MWnX6lf5OUAl22BOdPE9lKuOvNi t8pWkIpuGjcOevh5+klemqJCVGyR2oVEQhNPJwBFrFAVQ6S/PENgQeqfdVCVeEXoCmqRlrhk3n2Q ikVs8RJMp6LLgy3ti5r9Jy9PULHAUvHAiSWeJZdBgClfbfSpyy8+efkaSeNnI/hKPBt4MV9p49Kb dfvuHKHk5ZXCOu9UIb9qWVcoAXMH/S88eflyHeddra5yfqmA6X/fycuXK4RT9pJm/bL0UjdpbZku Ps46JS+v1bCJ8ixfsbDbqkjSD0zy8vVqv6TqrKfhf+VINkBw6a9U9b7y5OUxQhHacBFHxIDR5CVl 8tDirFhRqnZVPYOsU/IyUlIjo8InrFnXGCuVvAyVAJmtIglFGEl/SQV5VtmA8cgrxFL3GOuUvIwT cPDcq+EzeUm5vNwEXv74YZPpHWaStp0eHWaO/nhJACaUHylY6hxnkgSbumF7u5SLTIT/8Ssf8ran rJgIW0ryMl4UUqrTg5JL6PHDookkLx8QV6LdBrfjpVGP3HdSPcLr3G/QH10mrpb8FVgRx8Y/U/2K +4idBoPGmSChkpS8fEAccz89zgyJTyZ5+YSEX/Enh5mj5OXTkimvdNqKWYEVrrPJyzhJcfzsKGuU vAzUs/zlC0d/mp6UX75x9KepycvgV5y8PEjSwmXsO05enqSmuwx9ycnLo5W8pE5o/JYpeXmwpDgO 7HKNkpfPKv0ldUqZX1JnJDqYmeTl2ZINl1FvOnl5uAY7TPLyA0peUic0cpeUvDxeUhyHdLZGycsM pb+kTinzS+qMkpfUKcmwN528/ISGvejk5cZa8PqSl/tqXJU5M+ZKJS8dGphizw06YZT/VR0Gjv5t /Ux5oDO8fN3EXg8ixWHk6N/Wz4wHOvUGv25i74yUvAzsR162eK+fk0pePtFP+kv/IE1eUnfTFF7+ Bqp5SXVoyf5oing3lLwMkzz2LVKtTV7G6bEvMXlJnZEFmL+8NCs2pVKpVCqVSqVSqVQqlUqlUqlU KpVKpVKpVCqVSqVSqVQqlUqlUqlUKpVKpVKpVCqVSqVSqdRL/TcAOXq5oQplbmRzdHJlYW0NZW5k b2JqDTggMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1MjMg L0hlaWdodCA0MjAgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMzMgMCBSIC9MZW5n dGggMjAwNyAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiezX0XabSBBFUf7/p5lJ dGVh2XJUDW0a2PvBo2QNBV06ke15BgAAAAAAAAAAAAAAAAAA4IVpzXV/vkz/axowtV15v27NvVc9 9Lzy3vO6pa+998/T11w3Lf/wq3dece/WCxfXtZ97/XWr7v3P6euua/ynucWt21eywe2bMlz5abjm 3v+4wxbXNQ7Z8967pTBP21w3XgrH/aBcd/NV3xhXXjfoN4jGj7tN7r7i3it+3vx40Xzv5m+o6+/9 8/x11617pA3+ZR7v3utTaL/3G9Pbr1v1XFt8hzjevds/yj4/wrZWP9W6ja77he6Q955HTWH9T3zN 37g2uO6Q9573/gENvqUqbjr9YsrxSIGQArFIYeJouqWw/Gt20fDmbeZFCo2D2q/mr9/c+bfTpDCK 39z5t9MGSOG9/+v0emzt/XEfDyCF/fXYWoPxf6Xc+43qr7iPPmuWwgiK++izZimMoLiPPms+Qgpv 2fvdXKV41D4blMIIikfts0EpjKB41D4blMIIikfts0EpjKB41D4blMIIikfts0EpjKB41D4blMII ikfts0EpjKB41D4blMIIikfts0EpjKB41D4blMIIikfts0EpjKB41D4blMIIikfts0EpjKB41D4b lMIIikfts0EpjKB41D4bPE0K79n7PX+heIg+u5HCCIqH6LMbKYygeIg+u5HCCIqH6LMbKYygeIg+ u5HCCIqH6LMbKYygeIg+u5HCCIqH6LMbKYygeIg+u5HCCIqH6LMbKYygeIg+u5HCCIqH6LMbKYyg eIiNFpFRjweQwv6Kh9hgD485zy+vYu/3/IXiITbYw9McKYyieIgN9vA0RwqjKB5igz085ixf1p/l uHZ+y18pPv8Ge/j4snz/L5PBHzu+3T8pHmKDPTzmfPk2cRF7v+cvFA+xwR4Wc6bPf3sVe7/nLxQP scEeFnOkMJLiITZaxHInmw0+jF3f8NeKh+izGymMoHiIPruRwgiKh+izGymMoHiIPruRwgiKh+iz GymMoHiIPruRwgiKh+izGymMoHiIPruRwgiKh+izGymMoHiIPruRwgiKh+izGymMoHiIPruRwgiK h+izGymMoHiIPruRwgiKh+izGymMoHiIPruRwgiKh+izGymMoHiIPruRwgiKh+izGymMoHiIPruR wgiKh+izm4ul8BYpEFIgpEBIgZACIQVCCoQUCCkQUiCkQEiBuFwK09N/uZMCIQVCCsR1U6g/y8kN nEJLOW9MffovdwOncHu+zQ/ca/DhXSyFSQovXSyFeZLCK1dLwafCS5dLofvgw5ICIQVCCoQUCCkQ UiCkQEiBkAIhBUIKhBQIKRBSIKRASIGQAiEFQgqEFAgpEFIgpEBIgZACIQVCCoQUCCkQUiCkQEiB uEYK0/3L4wGk8OxCKcyLJKTw1bVSWPxBCs+kQFwrheU3iPqznNzAKbSU82rUcuTnv+Ju4BRuz7fN Kb9Ok8KzK6QwPaZM89dX3FwhhXmSwhsukcLiU+HjCaTw7Bop/Obgw5ICIQVCCoQUCCkQUiCkQEiB kAIhBUIKhBQIKRBSIKRASIGQAiEFQgqEFAgpEFIgpEBIgZACIQVCCoQUCCkQUqBECsRZUlg8gRTa nCWFxTgptDlNCo95UmhznhQ+BkqhzYlSuE9seBbmnVJoKeetuYuvVO2Swu3OHQ7Ta/AlSIE4SwrT Y6QU2pwlhfnxAFJoc5oUfmHwyUmBkAIhBUIKhBQIKRBSIKRASIGQAiEFQgqEFAgpEFIgpEBIgZAC IQVCCoQUCCkQUiCkQEiBkAIhBUIKhBQIKRBSIKRAHDqF+22nvN5s8CUdOoXFjOnxRym0OXYKT0Ok sMbBU/g8RQprHD2FefkDwvQ40jbDL2WXFFrKeT3sMXL5F1TtksLtzlud4HmaFNqcJYXnXyYoO3QK ix8QpLDaoVOYF3d9PIEU2hw7hd8dfHJSIKRASIGQAiEFQgqEFAgpEFIgpEBIgZACIQVCCoQUCCkQ UiCkQEiBkAIhBUIKhBQIKRBSIKRASIGQAiEFQgqEFAgpEKdJ4fEAUmhzlhSmx0gptDlLCouRUmgj BeKMKdSfhXmnFFrKeWdoXmw8+Cp2SeF25w6H6TX4EqRAnCUFv0yudpYU5scDSKHNaVL4hcEnJwVC CoQUCCkQUiCkQEiBkAIhBUIKhBQIKRBSIKRA9HiT37xzj6FdB5+cFAgpEFIgpEBIgZACIQVCCoQU CCkQUiCkQEiBkAIhBUIKhBSIY6eQZ5seLzcafEWHTmF6zHl+SdmhU3ieI4U1pECcJYXlN4heT3xy u6Sw3dCPMYuJMmhzqk+FbQdfzVlSWIyTQptDp7D4AUEKqx06hXnxbI/nlEKbY6fwu4NPTgqEFAgp EFIgpEBIgZACIQVCCuxOCoQUCCkQUiCkQEiBkAIhBUIKhBQIKRBSIKRASIGQAiEFQgqEFAgpEFIg pEBIgdj+HZu2GOzqo139w8TjHsrVW5j+2mCwq4929XfjfCpc8urvxt1T+Ph8aJyz7ilcXbpw3bv1 YuinFDiSXilweZvHxVFJgTspAN+b5sUnxN8XHX5K5RCWv0x8dKGFK5ICd9Pnl1K4LJ8KhBS4+fIb hBTI54MU+D8AKRC3DKZbEnLgr8lHAx+kwB8+FYjJzwqEEggfCwAAAAAAV/KfAAMAggksTgplbmRz dHJlYW0NZW5kb2JqDTkgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9X aWR0aCA1NjAgL0hlaWdodCA0MjAgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMzMg MCBSIC9MZW5ndGggMjA2MSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiezXwXbj OBJFQfz/T2u6RKoozXSfxnM5kYQnYkF5QRIS8pqyHw8AAAAAAAAAAAAAAAAAAAAAFhh/Cc+dvWSE 10Tnj3GcMn3/L12QfID0/MfxiaNNjS/4buP3Yfrc6UtGeE12/kjfU3jB54nff/55Qrap8QXfLV62 uJdgjfF2yO6fzCee5+z55/Mu+AUZ1yNFL4+4l/j+8QKlvZzPiuwBOX7/uEEv9/o+eqx4nOe9RF+o X+lln++j1x+Ms5d8qZdojXScv86cX+D9xPnzg/un4z8uCKfwveLnS3Uv0Rpf6aV0gej+X+xlfoEC 0bIjuWSEvXycVNdL7QLZ/cPn13FB9gG+W10vbx9u9nGerPF546keH9E80wXS+z+27OVx/Y82d+6Y v2S83X/mmt/nT63xeeOJ+7+dWbJAev/H+Q08v0HXBcEUoIE8CXR9/bEnvZDQC4n3/13ZjV6Y1vK9 oJdt6YWEXsgK6Pg/5XqT3VvF2KCXt9Xpl02sqITJ1emXTayohMnV6ZdNrKiEydXpl02sqITJ1emX TayohMnV6ZdNrKiEydXpl02sqITJ1emXTayohMnV6ZdNrKiEydUpUjaxqhvPrU6RsolV3XhudYqU TazqxnOrU6RsYlU3nludImUTq7rx3OoUKZtY1Y3nVqdI2cSqbjy3OkXKJlZ147nVKVI2saobz61O kbKJVd14bnUSrbM66GUjrbM66GUjrbM66GUjrbM66GUjrbM66GUjrbM66GUjrbM66GUjrbM66GUj rbM66GUjrbM66GUjrbM66GUjrbM66GUjrbM66GUjrbM6LH0P52e+Pnrv9m9n5az+wcr3MI7DuNbt HsBmFs7qnyx/D3r5utWz+ht66bZ6AH/G91G3hQP4M8vf7rmeXj4sHMA3WP580ct/WTiAb7D07Y7r qJeXlQP4c3rptnIAf25tL8f+XLvUOqibWDmAP9f7drtndQetA4jppVvrAGJ66dY6gJheurUOIKaX bq0DiOmlW+sAYnrp1jqAmF66tQ4gppdurQOI6aVb6wBieunWOoCYXrq1DiCmlwqtm1pKLxVaN7WU Xiq0bmopvVRo3dRSeqnQuqml9FKhdVNL6aVC66aW0kuF1k0tpZcKrZtaSi8VWje1lF4qtG5qKb1U aN3UUnqp0LqppfRSoXVTS+mlQuumltJLhdZNLaWXCq2bWkov01p36i70Mq11p+5CL9Nad+ou9DKt dafuYtUuPNc5d/3a/N4AQot26t5W9nI083p5HneyaKfuTS/TFu3Uvell2qKduje9TFu0U7e1dBf0 8jPoZdqinbq3Nbsw9PJDLNqFoZefYeX30ePc9WvzewMILdqpe+vdhe4EIq07dRd6mda6U3ehl2mt O3UXepnWulN3oZdprTt1F3qZ1rpTd6GXaa07dRd6mda6U3fx/95L68ffkF5I6IWEXkjohYReSOzT S/dd+UUvJPRCQi8k9EJCLyT0QkIvJPRCQi8k9EJCLyT0QkIvJPRC4if2Qh29kNALCb2QWDWG5zrn 2K/p62U3K3s5mnm9PI962czS58vxg142phcSvo+YtHQMr79zx0MvO1v+fNHL1taM4fNL6O1HvWxm 0RiGXn6Gpf8fnXO/pq+X3fSOQS+70QsJvZDQCwm9kNALCb2Q0AsJvZDQCwm9kNALCb2Q0AsJvZDQ Cwm9kNALCb2Q0AsJvZDQCwm9kNALCb2Q0AsJvZDQCwm9kNALCb2Q0AuJJWN4Dfwc+zV9vexmzRjG dRyvl+dRL5tZNIbxdtDLxlaNYTz08hMsG8PQy+YWj2Ho5QfQCwm9kFgyhs9Q9LKxNWM45/358tDL fnrHoJfd6IWEXkjohYReSOiFhF5I6IWEXkjohYReSOiFhF5I6IWEXkjohYReSOiFhF5I6IWEXkjo hYReSOiFhF5I6IWEXkjohYReSOiFhF5I6IWEXkgsGcNr4OfYr+nrZTdrxjCu43i9PI962cyiMYy3 n/SysVVjGNcPetnYsjEM30ebWzyG8TjX08vGlvbytqRe9rSyl89/k55HvWxmyRhehehle2vGcM77 nPs1fb3spncMetmNXkjohYReSOiFhF5I6IWEXkjohYReSOiFhF5I6IWEXkjohYReSOiFhF5I6IWE XkjohYReSOiFhF5I6IWEXkjohYReSOiFhF5I6IWEXkjohcSaMZzz/nx56GU/S8YwjsPny/Ool82s G4NefgK9kNALk1aO4bmQXvbn+UJCLySWjOEzFL1sbM0Yznl/vjz0sp/eMehlN3ohoRcSeiGhFxJ6 IaEXEnohoRcSeiGhFxJ6IaEXEnohoRcSeiGhFxJ6IaEXEnohoRcSeiGhFxJ6IaEXEnohoRcSeiGh FxJ6IaEXEnohoRcSa8Zwzvvz5aGX/SwZwzgOny/Po142s24Mr0eKXnamFxIre/F9tLWVY3gudK6n l40tf77oZWtL/34Z15J62dOSMbwK0cv21ozhnPc592v6etlN7xj0shu9kNALCb2Q0AsJvZDQCwm9 kNALCb2Q0AsJvZDQC4nmXlpXJ6cXEnohoRcSeiGhFxJ6IaEXEnohoRcSeiGhFxJ6IaEXEnohoRcS eiGhFxJ6IbFsYr8WGn+5Xr6w+u7n3+4NlX+ALxvnWuP18pXVdz//dm/onr2MJ73c7w3ds5fz4aKX 272h3XphN0t6OSr5317gb+mFyNALAb0Q+RXI+ffSuj+bAAAAAAAAAAAAAAAAAAAA/sV/BBgA9u9S aAplbmRzdHJlYW0NZW5kb2JqDTEwIDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9J bWFnZSAvV2lkdGggNTYwIC9IZWlnaHQgNDIwIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNw YWNlIDMzIDAgUiAvTGVuZ3RoIDM0MjIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0K SInsl9uW4yAMBPn/n87u5H5xHIOF6MZVD+PZM2lL4FqsnE4AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAJBCafn834/yn6pgqUvcPt9Sq627U2uxtl3MWVg0Tb6cnrzpXqm5Vo2cj8/XF2v/ fP+FhbNrZ+rC+x5C/SbtqFcTbT04W2q1JuJI9CW11r5ytf/n93z+GL5oH9s7qjW9Ixo/f6D3UeUh vKtaS63axP3zDcVK9Yu5uVbbtgey63xJqta4QWnF2n1pKDWU5pU2dr7nhSRcrPpAav9fN1qY1pW2 PY22r7j1m5Ra7Ei+tI+s1W/SHZ9ve8+nFcucAocPMAA/QVKooPb1DscGX6AGfIEannwp4MZYX9pv IJ0yaDF1YbvAF98UvnRJGbSIL0IpgxZ9fDk9xib9DcKXkFgQY6tDPfgCNTj6op8yaPFA7yP9lEGL +CKUMmgRX4RSBi0eyBcYx2BfCsZ4Mfx8QRgrhvuCMFaM9+VU/U6adizUTyn4Ut3EtNuqn9LwpbKL abdVPyXiS907adpt1U+p+NIwxcAIZHwZ3QpsQsgXjhgDlHwZ3Q38RsuXbe1MOxbqp9R82fROmnZb 9VNyvmzpaNpt1U8J+vK7pWm3VT+l6Avfk4RR9AVjdNH0ZXRf8A1VXzhiNJH1ZeWP046F+illX75P Nx1qxaYMWjTwpZy5XDdV//JOmnZb9VO550t5/Hz6dTWx9Ilpt1U/lfw+Kq8/tlRn7JUi+XGUU60v fFGSIvthlFdfrqPMbaJZvpYff+eacr2Nn7mU2vNl+8egPxa+vL2Tph0L9VMmvrx+ctpt1U+l+nIV pcmX5yNm2m3VT+WeL2/TbWX1uzHTbqt+avAoWVk9fzqHN6x8wZjhmPkyuuHDY+cLwgzFz5fWd5LB WKifcvSlURiDbdVPefqS+B7Dl5BYEM1LbThiDLZVP2XpyyXK3DsCW19Gt35QjH3hiBmAsy+juz8i jr6UxV+71+of00+5+1LxTjLYVv2UvS/bjTHYVv3UBL5svYvBtuqnLH35vA1zbxZT+DJ6GQdiEl8Q JolZfOGdlIOjL19SP25mMBbqp2by5cfdDLZVPzWVL+vvJINt1U/N5cuqMQbbqp+y9CX7lvBgOl/4 otSV+XwZvaa5mdEXhOlH9tb+1Svl9s7oNaotvZMMxkL91AhfyqNuv6V+GmOwrfqpVF/KmRxfPj9l sK36qdzzpeSdL6ePI8ZgW/VTo325jjK3iSb4Wjrd95jXct/ONErI+VJTD2KZ25fFL0qwg+T9LMm+ cMQE4+hLXaq8XXvW2hnTT6X/93uebpOWWvLc3BnTTw0+rpOWevmylFNrT0w/dQxfTvcxO6NWe0w/ ZelLUyXm3hCO4svolc7CcXxBmAgO5AvvpAAcfWlP1SeZd0NiQaRvUHUUX0JiQeRvUO07CV9CYkGM 2KA6Y/AlJBbEmOqMve0c0Re+KLVzSF9GL9uYg/qCMI04+hKS2vhOYt4NiQUxdIM2GYMvIbEgBm/Q hhvhS0gsiNEb9PuIwZeQWBDjp87xHXhxdF8UWnDi8L5s/aIEZ/BFpQsPHH0JT7X9qbGYdQpfLn/7 +kd8CYkFobNB34zBl5BYEEobtPx3fAmJBSE1afJFaQP48oRYO4qkblEp5//D10t29Q2o9aNH5g6V y4/yqCv3fHgn/cDRl66pN2OYd0Ni7bXUfXn7IL6ExNpqnYeXF1/eJppt11L5+do6pbTcP+DaVrck 9ffYliTOJU/y58vLZzlfQmJ7ainPuzdkGxsNvizDF6VlHOfdHJR7G0fqrrxNneLPRLq5UYzdFO0B 7z6cZxTzSOHLeqZ1jFFfGL5IpQxaxJc+qbYTxmBhTSlLX5KxaDILfPlN6xAzI/iyBYy5gS/b8Om0 L46+DEnVHTFGC0uJBaG/QU+pGmOsFpYQC0J/g8rXf/QuJpnCl6rU5iPGbWG9Y0H4TZF+HceCL5UY thwJvtRS90VpNvClniMb4+jL+NTPe41vsU8KX9pSv44YgRa7pPClNbV+O4kWO6TwpTm1ej+NFuNT lr6IcMixF192YN5+C/iyB/f+68GXXRzuneToi1Rq2RipFgNT+LI/tfQRsRbDUvgSkFo4YtRajErh S0jq41N6Lcakcn0p5fxf8XrJrt6TaRbyi8yFlsuP8qg7zzYf5YsSvkRxDGPwJY65VrPMYF/eJppt 11L5+dY61dcyJF+6r+ta595eFrfHfdp3vginytu1a7EBqdHnS/t9RFO7vvjpp/AlOlWelte9WHrK 0hdxplzUjQHzy+kxNs25tXOu6sLYtU26s7nfIlLBly5Ma4yjL/qp25SWUmzaeTequn7qL9ZwxHgs bCD6G7RnW6uzLgsbhv4G7drW2rDNwkYx61R4Y76xF1/6MtsK8aUzky0RX3oz1zvJ0Rf91GtsszFu C0tHf4NitnXjXfwWloz+BgVt67YjxnBhuehvUNi2brmR5cIymWoU/MEca8WXNKb4ooQviUxgDL6k Yr9gR1/0U99jq0eM88JS0N+g+G1t+1NbrfAUvnRJrca+/818Yf3R36Ae2/r1neS+sO7Yj3+N+K4b X4Zgu3B8GcPq9yRh8GUUnsY4+qKf2hb7+NAsC+uG/gZ13db3I2aahe3nXKeU8w5dL83V9VObY2Xl X9G1IlKpvlycuV3aq+untsfK13/E1wpIWfoyFWZjL74Mx8qYwb68TTQHvZZBdeuu5d5mApwva/gc MY6+6KfqY0+b0r3WjlSSLwVftiSmXFhbGXz5GSmTLqy9ztt06/DkM7e1cYrRX1gYNmNeDgbbgS9K 6H9Pwhct1I3BFzW098TRF/3UrmK1R4zBwqLQf/IDfKlNGywsCv0nP8SXurjBwqLQf/JjfKl6Jxks LArt2W4ooluDL6po7g2+yFL7PSkFfBFG0BhHX/RTYcW2GGOwsCj0n/xgX7YYY7CwKPSf/HBfft/L YGFR6D95AV9+HTEGC4tCb57TRGfwxRcPVHYKX0wQOWLwxQaJzXL0RT/Vp9i3cbhHreBYEPpPXsmX L+8kg4VFof/kpXxZ/oTBwqLQf/Jivix9xGBhUUiMcF4M/p505OqmDDUGXwwZuG344si4Iyar8F+d cuZy3VNdP9W/WFn8tU+tgFhbnbL4a9u9pFMJxcrCb71q7Y811imvPwyevKwvj3eSwcKa65QTvoSl Sv4mZvvyd3325TrK3CYarsLX2/iZQnn8svt8gTvpX5TwxZzkLcwpV/ClG7l7mFStPA26zLvBqaaY w7z7Nt06PHkHX5py4r5EVtdPZbfYEMQXoVR6i/XvpAP5Agu0TTH1ZVKqaFafjJTNxJd5yDhi8GUm +u+noy/6qWEtbr/DgeZd/dS4Fje/k/BFKDWyxY03wReh1NAWt93lQL7AOj2/J+HLjPQzBl/mpNfO 4sukdDpiHH3RT0m0uH63A827+imNFldvhy9CKZEW195J+CKUkmnxuzEH8gUqCN5ifJmd2C9K+DI/ kbuMLwcgcJsdfdFPqbW48E460Lyrn9Jr8eND+CKUEmzx/VP4IpRSbPHtnXQgX6CNhSmm/h77b2Fb /Xjs3++sJ1aerqXcTMeXZHYfMQN8KY9/40s6O7c805dyZr8v+inlFvcd7annS4k5X/RT0i2WpwfQ vVgrX3y5jjK3iWbbtVR+vrVO+rU05UpWnXssgdt5wvkikSoW50uQL7Cf1oMi54nddS74okLqeVtd Bl/kaNr83PfR5foYm/BlJC3vpLFPTH0snHbefTnl+xeLwmRbtYvtSVVn8aVHyqDFp4Gyf7EobLZV udjOVJ0xjr5ALDVPAV+g5ojBFzhVPAh8gT+2PglHX/RTBi2+pza+k/ClR8qgxc/UpvvgS4+UQYsL qS03wpceKYMWl1Ib3kmOvkA3fhqDL/DCj0eCL/DK+hGDL/DO2lNx9EU/ZdBioxT40iNl0OL6W+fr X/GlR8qgxV9z7Ze/40uPlEGLP1PLxjj6AjksGYMv8J3P54MvsMLHEYMvsEpZ/WcyUgNeYMqgxc2p svKvbCQ3KCBl0OL21Ms7CV96pAxarEk9GYMvPVIGLdalyscvnTnXKeVs6vWSWB32kv3Eyq1WuV0y q8N+cp8Yvtjz9NxyiuGLN3/vpFRfLtI8+/I20Wy7lsrPt9ZJv5amXEnqr9zbS+Cqyl3RPeeLfsqg xdSFtdV5HrHxxTKV5EvBlzlSWedLYd6dg8z30fNYl1sdohj7xPDFDXyBGhx90U8ZtKg974ZW108Z tIgvQimDFvFFKGXQ4oF8gXHgC9SAL1ADvkANjr7opwxaPNC8q58yaBFfhFIGLeKLUMqgxQP5AuPA F6gBX6AGfIEaHH3RTxm0eKB5Vz9l0CK+CKUMWsQXoZRBiwfyBcaBL1ADvkAN+AI1OPqinzJo8UDz rn7KoEVxX851yn8el+bq+imDFg18uThzu7RX108ZtIgvQimDFvFFKGXQoqcv4EaiL9dB98kXgGWW zxeAJQq+QA0FX6CGp/nllDg2AQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArPNPgAEAjo4U 8wplbmRzdHJlYW0NZW5kb2JqDTExIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA1NSAw IFIgDS9SZXNvdXJjZXMgMTIgMCBSIA0vQ29udGVudHMgMTMgMCBSIA0vTWVkaWFCb3ggWyAwIDAg NTk1IDg0MiBdIA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9i ag0xMiAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUMgL0ltYWdlSSBdIA0v Rm9udCA8PCAvVFQxIDYzIDAgUiAvVFQyIDY3IDAgUiAvVFQzIDcwIDAgUiAvVFQ0IDMxIDAgUiAv VFQ1IDMyIDAgUiAvVFQ2IDM1IDAgUiA+PiANL1hPYmplY3QgPDwgL0ltNSAxNCAwIFIgL0ltNiAx NSAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA4NyAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9D czYgNjIgMCBSIC9DczggMzMgMCBSID4+IA0+PiANZW5kb2JqDTEzIDAgb2JqDTw8IC9MZW5ndGgg NDk0MiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIibRXO48ktxHO91dMLGD7mm8S GHQg2zDg1JsdHMy0tAIM2IEv8N93sV4s9nTfSYEhHbaH9WDxqwc//vzx9uXjw9/c7ePzza3L6m8r /EdfOSyx3kpIS/YraPzr7cufvuXb/g111tu3/d9vX/76d3f77dsbGKwOdPa39fbx37ev93VNZQtL 6h9+e3dLg681bO/RLwE+Y93cUrs0G9W4i826OU9L0crr7OTZvcO/x7Q8jBPox0yKVqGx32S2xAXH +rJPJX3YI7ZpyWcwi/2jzKoa6lNOfXAW1q3bBUQFF/LsYUTfty3kIH5u//j4G6ALRi6Xcvv4M4Ee O+gdb4ybz9DdtcS7b35x3VsHK6CngMh3ZTw9psH1BE6WPoGsCDKMSiyTDqI/myECVRHIBgHRSOzz MUdaTLYpQA69K7mV0ZTFlA+Chz1Oo10lNlUa55XgrNi3baUji158iJ47uHIRM/LxE+UhSx4EEjm0 c4ziIT+63hMUbIK4aAGHeJ91eamXMyN11EDRTlqPUfg2CAwwcRqotKIAG8wm5EWOo3D/6DipAxbv JwA09sZ5kVJSOW/oJly1vr9TVz4E/N1bi1qqN5dpLVHQynMMz8GBS7Yq1Ep27tFP6pnKwtVRHiLz +/a+zg1hxaMQ80ZjYNrR2SPKRMJRKbD3BAJgS1TTdhVsG2evMl9EgxplQrwq4qAZFi+1kbjp4q+U K5QIktQZhZQCzy6r1KuKfuSDthmuvRTG8PR34+NYzUnyXTjfK5VAnlUSm+HJ01yU6W7CMlseVK56 5oCMOtJTm9movlSYBfOvApA3TvA+gDQ1qZBiMjoEB3wwGbrQ7A/TrbqJczDtwmG3UDYelU9zdcmO qeMsNzHWowXD5JhDtsaxibGgObkeibD7VjLNm58s/1geJLNjtNgLE304SXS1C91pFKdOnLqX5NJc avPJeHnYPuXGHxVGhsU4xrTJ7SUt64wbY4j1j1XvbeUftzWOmAthz+kpi53u4+aNZmhYxz23+b5O 7Gsg+95nyJqUlew0zaj8IWIoMIY9yWr8lE1oAtOqI5fATyPx07CEnAIQoLL4klJnQLSZXhG+0Ya9 F2ge02zWbZ92I/i32ptoZE9IF2XSEhYIjnPgJXF4D9Pfrhs5BsAfCdsCrV8x6FJj7EFfRtouIs0c afq/RvoOGW/uBn9CAJgVXd/Rvdu8HTNGf/3pmDTb7rZrxliF2+fjn29QXHBvNHhWMLHVfbUhdm7Z 3TbFOMpoPemo7zYT7PlelxiDO1Lq1ekF6JitrBu2bTqArTcX/B8Jgf4cCCKXoUvmRL5HI6KKNCVS ayn48SBrVR5k8EUPMp/g0ucHGd7XQRK02kHAvsOqnBKGNxyaXhCpJn1BsHkq35sVGB6Y56VlV26z i1UpQxiIVRouyT6DZuTMi8Y6k4DGfKZ/MHgkgHoMILPN7y/CUyxolJg7H+1/WIDdF6QtUNriAog7 rmTJDWL/l4+31JaSbz7D3IZU+rZAgntW//Pr26cIgbD5SMs+QYmS0IW8+Cuhh1s0x0tpbQvk6EL6 88ePa87XJa2j5nyQhLs+TD77mN3eAYyEt4ZDmoBfcOenljKSARdkGS36WNuZPNNbauATKv45x8fn ZeVjwLGLn/A5Fwo+F1LG51wK+Fyg4tISLCp66+FM/KQTIypItx78D3hAiolYuguCHyMSu9IBDUhW ukSjk/lLNM6FgsaFlNE4l16jsfrFMRoTBvWIwc7HzEDwWnI4JxSHRt+IRz3gAGGEKxxca/1M5zhc CBmHKynhcCG9xMFV4KwWh3xWC5WPKnjAazHGWJEeTlhUVjpg0aNyl1jU3Lv7AotzoWBxIWUszqXX WJS0lDMspppIZhA8+S+AFVpMSDQnPDIrpAMeNcHFcIVHCTr4XvE4FwoeF1LG41x6jUf2OkcRj3JW GztjUvjIO82MVzwEuIgeZjyKv56gAOL1BL0QCh4XUsbjXHqNR2w6QSc8pvqIPBJe/gEmMdLzUTGJ jEs+qRH4czlHXcx9uFDokFWSwXkgvywrWGLDkPE6NeyyXK8sBcxTUw+fzl+aMtKnpnSVu/OrPKzt VkJnJ60oeWR+grXmGDom6PJGSU/hp0x1DzzT74MLCclLbXA31In01un/lJc9rnjZREfgIcBngK/g 4az+Vvpzwcshxmuzb5Ms35dt+QnrW0T+IUzdrsV9o1Iibm4Elodm4rcTp1RsoB5XIjjjoTPWXvns weahVPlp2OZz1grwmKAPTAE93dwSXfP2IUNvtybACKFXrNcNAE33+RQSUYLXKkYM7C1gD9q4Jw3M fddq/IRIXn6hng/j7FIb8pCcbCftfXMYnHXNS6PCRBRjp5UY5efsZ+XK7RUdH6Lv3KzV2apIIOu0 FnRtFQxO9aLGv6uew6R8/MRJ0McRPU66WtWz4VfuB9A3UtT1Kl+xdg03WxUuo50mH5ZsdEP2HNaz dG7gsT4Soj4msKspBGs3+4A8ZdtFsfAhp5B2elON/hGJtcHa1IDOdY5HFexxumWBPgU+iB+12Hs2 yaBgiDJ0RaFjRMoMVZ2VJXzdFElXYG/YR2hlB4IYrU8xkhGLN9VqfqeRR7HqJeeo0GQ4W4v8avHo 42IfRS7rNKQtOPTW/So5LfxvPw5kU13AbGlkbETa7WIvEY+ZRyQS5ziSC8F8dsOyOAoZq2Q31SO6 fTjX+6tA4McNG8ecaMA5rf5oZn3iwUajVvQnKaeTxu95QUmBOEmQ5h4CDffjLYiyvoeLgdqD1Pv2 03KvzzS8RbOTaDZCOY8ExaZqvUkoIESFMt5vy5Aa3KJwM2DunZ7DJMbxWyz+4EKXHIh+H7OEt0Uv 5bm9Zg3xn+QG4xDNFXboYE/nxLuwJRqGjNJznEFFdS68ZEHlFF3lMME6YtwbyTqVppLfoVxsDkcN 393Jag+tMnAmfEYRPE52+QEiOsJsAU9Nj1PRTkYtek5w5XrYwtR8vA6b8dR99nNp78uyVe2DNJh+ G7a9Ydx99ChbhNgvTFDC6QWykPiHjaycboznSKMMtcBfzsNR2UgdB3l2ijRf1MwF1Z0QW3zFCOxf OR/olNNoOapO19xkMrygerilRFUnbb1wgZTSjBkPr4lkx0yz4XtumzwrG5BfgJOr41C2Jg1y4v4e +8VAKt5HD82saTR+Gh6IEWEon+aecrr6kC/M2srcUa2M5ncJaWZikXbx1CjteSMaRoyDcrBZZjZH AYdiYT44atJ1uh0yci040XsJaaZkUgVCycQO6TIldUbkj7qdGEOdhocbPZu8I0JUTCd6oQpYRCft KFaplwOqHyka5jxz4Xnuzl5S06Yq7NmRCaHOkULpxfS5jQfNiFI9NIlkUk67KdzkixLcocHNPSts 6yFAp+6zrfhVax3vyCg1e6zzMNYIw4GnjgKh2XeWe/pW27oJixUQ2LkoOv6b5cmBbl4CG/JUSCem wxZoqPuuhqOxi2Qd6zPgrk+o12dtL0Ov5KU/YvD+gltPaCJ94A2sLLPzL6XxnWrpoK+TahpxTprm opW1sG7pPj+jOjNzUxDOhvZCpEQrb/7+ezwMrkhaeJk8jTZMJ883x0FTg3iOC4x51wvEOnOlxw31 KAWnfn/1Cv/nJdzCMtoaSLVOPzFWfVm1+yS88hHNFSdLhSIY/tphQTUM/T8am+ebTDMZ1BKSPIFO o+TLVRaQyGHDf/KKNZvKLU7lNjG0dMp4E2Wt76BzMPIAajSiuEp+mc8slvlgoB9dKTp2b+pzPyrq 5hi4rtbBi9lNf2tK4LyEo7ZxBY5xbDUMPp5UD+0Yx4vt4F1jVfqhHG3uONbqtRfvFy4mvjxmzehX Lz2EA58v3pgzSUermSOysBee4Y+H0tPvjOlMi7SYmp9Q9mQHgJ16PApORqMpafW8vw6jlxOhIXdm LJ7WJIzKg+I51XIR9PoT0b5Y0amT8bzzDzz99OMhvIUJqPDm4/qnuBvWvc7k5pHb0dr0m2mQWHkf jtfK4Eysz6HrXthyeM/tPa35PhpBbILBWv3o0U2FuJU5g5egjJo9yTgFGRip5WQTb/P/47xqWl25 Yeg+v2L+wMsbf44NIYvyuuiyEOiiqyT0Qh/clvb/L2pbOrLsmYS2hMtNbFmWZOnoSHJYwDFXi2Xy KW3CDkCmLcPmG/yaJHW7DKGtlXbpW+IPDZM3O4gbbcRRw0TV7o/qfoLdoaFI+8TRhw4I91KU804D QqLHLdEE3KfN4wp4kz5VVWRQnBMc61EFweiMH3MV4qlYRG2x48ogsK8TvX2co9hsGQBi1Cg6xGdX ZHbzDBFpLv8X0dgEajm5I+MHkiLskGIIu0yPLfGIqdWUr5Ao6bdliYVEwrP3CKLwVJWFl04TRMc0 EJkUBB/78NqP8w24WSEdDqpm0OfUq9AM98bwFktJCVYI4TgtP2QLNSAgxiI2X1fpvJ2sfGmBlv7Y 5ogCRvyuGPG4hzhs1HHM9frOcoBHEJZK8i1W51qV1UnoOait/bTfF5AjgdTVeaTvdlmlwPlqTXOy HLTFBRde3eBr/nh46gf9fU+Nt9GiFrH5ODhQiomQuMdI5ruPQdEc4WOeErjLdr6ShK+85AKSFYYg nPqDDLZh3P0Xk5M5aAW8djQ54dr/PznJhcKwcK0lkDYa3S2RK1O0GUd/er1X8wAqGTHW5+gs2+4A yOlCqy0fHhzGO3BYS7fiNRDfeLnjbq0/JV+LNKg+RC9XzBAuyq66GZTK+rMWbHPp6+1mlpIzH6eS fTkta/nQN7fmxZtwXl0uIPpJnlfHq98boYOJ2rKVSGjqF7ncSVWrRBgSlVeeEefenWm/PWf6E+l5 vX2v9lqxtxAatrd8c9adbfmXS9exYrDDU9VZBM3PevR0R2Oaam6He0/+0ezDPLWigpv8RMdbfsaR S/AJpbo++aZQEjo3uA9JuqRVlx/BBUfExDhehrbh1EsMqhOp3l6oM7BRTpTSqplTW43JdqlZG7dC b75RxJOQzPs6jAXBKet8M+4OvtzSWniWleCgrJ3fBI3CIC9iw6zrtx08SQAVPLGcAie+SLMse1Ff WlFvg1U0P8CEUXVhI7w3R0Kd37vML6Qb7CoEEhlAVKL2rU45dV/faO6LY6PiV//oGSSSXZcRuYF1 sJanlqirhWdUU0sdhmwrhnAudJs7lYit27ltrDqs16eyqCviMl4VLsRqNwb14Rz39ProDdQ4eP1+ cFF7c05ktnvO5NgpDfGiB/iVcKgrUdyq2YfAlcpd/A0gdPGRjNHi/ro0bM9cmnVguWY7FzZ3FlGp Lm6lhOxH0vpoLgNVptZcow86ofknbpjao5dM1TiWEB1zhGQMkdYaQV20SuKHqrom2a69BSyqgIk6 GG9QELNBHCTHDbse3ZqqF/x79ufJK4SXUZsVMFtqtcPFgC3ZzD06HQZ+RVYho2ARY4HC7FXGCGdp LlkfnIJ5wH6FVy5g4ts3RWzWuuOIju3pRW9yMnKgOV0VpuNGLKr02vem56SS227Y36Ya1XSmCQ+p GiRVpwxpJmdxWdNPTXDgsVA8OcYcry9k/SNqlOLFYuo6PbGolg6l5CndJb4ZoaRUA5ZmWN6Psb5N SOCLTi6jRKV3GibsFiiz0c+m9TpNmYYMNl5pyLMbllzgJX1iQIoA+E9HSKFPJRYKnN3kMgZNQ/5+ QCWkBUDghlz6kEPzTXG0AoBtE1uZpc+3OL1lSIfjA4wKVK/7yUK2RjZ/eEIvv1CiGY67qC9qbBFp iqaZIAOq7tg84jjaaFWsWN7WTk9ltCHY4x+K1sXQyR/PTLqYk+7XM6OaZyiLIj2aobx+E/7tX8xS dS+8KSUZPmBUoyHeCZFgXjlutArFrCtCiO0s3P2VMtrf1U47LS16O0HWpHcwtParwDE7HtV2WhlO BzX6vVOP5N59qSfztpasenNHzbO9edJFXAjuEQsYSFRSaBwv08EKRhnY7BhTIpA3aoDY5h0dBiiU VhHRrjW6Ze5+4Dz3ab0fhKf91gRLkTteWSuoxZoauxJtKoCqqtZeVQ1cLeIR2PTAnTn5CVjoD3di u15nLz0keZXmOlNk3qq5wPfmcUMNEd04LRCvzHFlt72G7We1tEKBlhIfJAYPYKl2Hsg0qWgpnfCs Opz2iHB4FDlmG0HaKTWS46GHZVsGAACEkm/79+8EFCoCQ8mm9zLT+c6deKk9tD0Wb81Bo//ojbKe 5UMdPYDtPdrwCVe0RpSnu1QxwdowmTblb59GjvAmU+NqKQbqrTfmOZWWW2/j4UhLxyn/x1Ot3JCv RBFMhTVnlxWAphKkH3bHlqBX6nLTJzAjxN7lJMenxIK25xCa6eUJh9nil2QRg2Jrllu/rhO4fRMN IMeCIEltwHZ2lTvtj7fTXyez/L6cYjx7u5SXKxYt1pTciosJBWn98vdvp1+WP4ogL6/l84X36Fj0 2zkvz8/T158+w/Ltz9PP5fPD7fT1dgtLcerjRKeKZl8cjUux5ByX2+fpS/XbwW1KiUJsGsy4SNGy qRh0tq6Gqcm3MFVGECsnJifrbNai/rzevmu/0nlbnCn2DW6l116lpZ3xhbVukZ2Ko1NxdsqefVyc bcH4d1710LB/Pv83//4ZAG1OIXQKZW5kc3RyZWFtDWVuZG9iag0xNCAwIG9iag08PCAvVHlwZSAv WE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDU2MCAvSGVpZ2h0IDQyMCAvQml0c1BlckNv bXBvbmVudCA4IA0vQ29sb3JTcGFjZSAzMyAwIFIgL0xlbmd0aCAzNDM4IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJ7JeLdqNIDET1/z/tSWw8xoRHP9TqKlH37AmTNUWr5RsQj4cQ QgghhBBCCCGEEEIIIYQQQgghhBBCCCGEEEIIIYQQQgghhBBCCCGECMFazv/9YT9UBa0u8T6/Za22 6h6ti7V1MWZj3jT58lh5M3yl5rVq5PycX79Y+/njN+ZOV2fqwn1fQn2TOtaribbeOFvWak34EehL 6Fp9y9X+zfecfw9fsG/bHas1PSMaz7/R86jyJty1WstatYn/5zcsZtUP5ua12truSNf9JWi1xgaF LdbuS8NSU2neaWPlPQ8k4MWqb0jtf3WzhWndadu30faKW9+k0MXu5Ev7yFr9JO04v+05H7ZY5BQ4 fYAR4hBb9JSkoojVO4CEEdfY9w8hDlgeQfaQL6IC+/LFBBvxwqx9abwEeoqgxNCNdSBfmFPyZUiK oEQCXxZR5AtvKvb+ssxLn7EJv0HyxSXmxNzVRT2TfZEwZMy+v7Ssn/a2jZ+SL0NSBCWS+tJSQNq2 4qfm+9JQQdq24qcAfNFLEhMAvkgYIhB8kTA8QPgiYWjA8KWujLRjIX4KxZeqOtK2FT8F40tNIWnb ip/C8aWikrRtxU8B+aKhlwEgXyQMAUi+SBh8oHyRMPBg+VJWTtqxED+F5ktRPWnbip+C86WkoLRt xU/h+VJQUdq24qcAfdHQiwygLxIGGERfJAwukL5IGFgwfTkvK+1YiJ9C9eW0rrRtxU9N8cV+uFy9 7aOzVQNTBCXy+GKfddvuImnbip8C9kVDLyLAvkgYQCb7sowy74lmc7SD/6/jjKP9/zpiKb6//NY5 uhhRB7Yv+2ekHQvxU/C+7J2Stq34KXxfds5J21b81JR3kM/YVLT6n5PSthU/NfmdtWx1Db04MPgi YXCg8EXCwMDhi4RBgdGXtGMhforFl68z07YVP0Xjy/rUtG3FT/H4sjo3bVvxU0S+PExD73yIfJld rHjM/gpqV5cws+HyRcLMhsyXZyLtWIifovPlN5K2rfgpPl9+Mmnbip8i9OVhaduKn2L0RUPvRBh9 kTDzoPRFwkyD0xcJMwtGX35T9UMvwViIn6L1pT5L0Fb8FLEvtWGCtuKnmH2pTBO0FT9F6YtXXNRD 7YuECYfbFwkTDbkvEiaYyH7bk9exZ3U7/KU41bbW6Bh+Kvbv0z4/V/9svMz+b6WptrUGx/BTwfdz +/7hs9XCixC0FT8V/fy3h78vhVchaCt+KnxetG9fllHmPdE0Hq0zr2PJ8T1+xmL995e9i4oYcvgi YaJI4ouECSKyz4so7vNu2aUIxkL8VOzf5Wa69d3q1bUI2oqfmnwfd93qxcUI2oqfyuTLxdUI2oqf ovQl6nLiL6l8eZiMGUwuX2bvJz/ZfJEwY2H0pW2uJRgL8VMJfTn6mKCt+KmMvhx8TtBW/FRKX/ZP IGgrforSl3nXFTl9eZiMGUNSX2ZvLC1pfZEwQ2D0pTC1eSYRjIX4qcy+bE4kaCt+KrcvX2cStBU/ ldyX9akEbcVPUfqCtcK9yO6LhPElvS8SxpX8vkgYTxh9qU2Zxa3VFcNP3cKXV4Kgrfipm/jyGyFo K37qLr78ZAjaip+i9AV9qczcxhcJ40J0F5+Tp5lNWF3CODDBl9XbbezqEqaf0CfCk35fmlNtL1aN i6VMhT8RPO4v7an6pHxxiTUvtvFlGWXeE03Z0SrPb10n/GhNOQuqz/6XF4ZNvr/UZ3V/cYk14uNL XwmaensI7p5N90WvSV3c0BcJ00F079ZT57RvTs+kZuZ2btqAV3wJzbsuMSfmNaj0GvLFJebExAYV XkS+uMScmNmgsiFGvrjEnLjz6pzc+huTMNXc2pfp6/Nxb1/mF8AGoy+eqatrad51iTkB0KCLi8kX l5gTCA06v5p8cYk5AdGg08vJF5eYExjjJkYVHMiXB0wZDMiXXwylEHjkywsZUwajL2NS+59r3nWJ OQHVoN0T5ItLzAmsBu2dIV9cYk6ANWjnFPniEnMCbchEqwcP+fIFXEFoyJdvDK8kKOTLFsSacGD0 ZXDKDn8ZsBhZSr7snbk6Vb64xJxAbZDt/GvYYkwp+XJxsnxxiTUuZs9b/XKIXr0K3MrmEtkXe/2w z7rA3wpwaTORL0cg1zYP+XIIdHGzCPXlObx8+bKZaMqOVnl+8zrWsk7HsW09C6rv044gnks++u8v canm/qBvjOL9aP1SxOFLcFvxU/LlKkVQYmBK8+4lDDXGEdqNzdRJ8l1QFBnF3GZwfBUcVcYgXwoI fYvEhtGXCanaMM3GgmJO4DfINseQxXBT8qU0VRcn2lhIzAn8Bn1SVUMM08YiYk5wzZFc1Y5BvlRA Vu4I5EsNVc+klMiXOvgq9oXRl6mpsssQbmxozAn8Bv1NFV2HcWMjY07gN2gnVTLEUG5sYMwJ/Abt pq4vNb3EQSlKX+bDWnc/8qWJkmdSSuRLI8Sl9yBfWmGuvR1GX0BSZ88kkBLdU/KlJ3X8IUyJzin5 0pU6/BSnRN+UfOlLHX0MVKJritIXJM6GmIzIl14y7KEc+dJNik2UIl/6udMzidEXvNSfs/BK9EnJ F5/U9jTAEl1Ssb6YPW/dy6F5dcTU5pmEWKJHKtQXe/2wz7r4DSpPfRmDWWJ/itIXVHLtZh/54kiy 7ewx2ZfNRKMj8NHe31YYr/Xy3l8SbmgL4/MIOZXuxc8n1r5Wcl+W1yToEjtS8sU/ZZGLBadiH7ib 6ZahQS0pwy+Rwxew1YcR+xYRinwZQlpj5Msgkm5Nvowi5y2G0Rf81PodcPhimnfpU0usNkyzsVng N6ivrZXPJJ6NTQK/Qb1trcozbWwKKUfCb5JtUb6MJtce5ctwKocYbORLAIm2yegLfmobK7wK38aC wW+QU1vLnkmEG4sFv0FubS25EOXGIsFvkF9bC67EubFAEg2C16R4T5IvgSQwRr6EQr9h+RIL+y2G 0Rf81Fms7aO2tdxT8mVI6jR2/Bn5xsaD36ARbT18JrFvbDj4DRrT1oOP+Tc2GPLhrx3ajcuXObC+ J8mXWXAaI1/mwbj7qJqf65g9/6iWQ/Pq+KnC2PYWk2Zj/dh7LXsf2lfHTxXH7OQ377U8UvJlSKo8 Zoe/+K/lkJIvQ1IVsfUzKdXG+jjwZTPR3PL4/A+gjus6P4PncDzvL+kgaoN8QSDsz7abmEJNvlzA 0omgOk3zbkEi5cY61tlMtwwNimurWdKNOYLfoMi2Nk4x+BtzA79BoW3FT1H6khf89yT5ggW6MfIF DeyeyBc4oG8xjL7gpzoXq0sTbMwL/G9+zvtR1S2GYGNe4H/zc3ypMoZgY17gf/OzfKm4BMHGvECe 7KYDOffKF2AAjZEv0MA1SL5gg3aLYfQFP+W52OWlCDbmBf43P9+Xy2sRbMwL/G8ewJerZxLBxrzA /+YRfLkwhmBjXoANc8CgdEq+kADyoiRfaIBolnzhAeEWw+gLfmrUYrvGEGzMC/xvHsuX3VMINuYF /jeP5svOLYZgY17gf/Nwvvw1hmBjXgAMcIxMbJt8YWTem1LUwr/r2JPXMXb1fMzqXKQvy2Lbf4oW Jt1iQn1ZqdLjC34qZLG+mzT4vLvam3zxStmqlaPX6os1r2PfviyjzHuiKTta5fmt64QfrSlnQfW9 x88Q7PMP3V88U8awsY51HHwRa2IH35jFTL4MJNKYoKVsNejKF3fi+hj6PNpMnfLFjfg5dAr4kyv8 vPt51YxYS74MSU0psS4tX4BSc0qsusXIF6DUrBIrLnAjX8Qhw+de+ZKMwcbIl3QMbap8ycfIWwyj L/ip2SUWGHOjeRc/Nb/ES2PkC1AKocQLY+QLUAqjxNPL3cgXUciAwVe+pMbdGPmSHGdj5Et6XI1h 9AU/BVbinjE3mnfxU3Al/jVGvgClAEvcniVfgFKIJW5uMTfyRbThMfjKlzvRb4x8uRe9xsiXu9Fn DKMv+CnsEp/G3GjexU+hl/hjjHwBSuGX2PpUki8jUgQlNgoT5YutjmbvYjXvTqTJmAm+2Od3+TKV BmMifbEn8gWIamNC7y+m+wsclcZM9mUZZd4TTdnRKs9vXSf8aE0561zXrGzdz2kBvO8nHvcX/BRB iV+pcg3ky4gUQYl2+qvzYrXYex2TL6CpwltM0P3FPH0RQyj6MmKfR6/jZ2ySL0iU3GLmfmPyBYtr Y+SLWGMXyjD6gp8iKPE4dWqMfBmRIijxVIoTmZoW8wKlQd4pghIvHjtHH8uXESmCEq9SB4MMoy8i hj1j5Is45q8x8kWcsTVGvohzvo1h9AU/RVBiRWptjHwZkSIosSr1eVmSLyNSBCXWphZj5MuIFEGJ 9amnMYy+iEn8GCNfRAUmX0QN8kXUwOgLfoqgxNCNeYHfIPniEnMCv0HyxSXmBH6D5ItLzAnNu2zI F1GDfBE1yBdRA6Mv+CmCEm807+KnCEoE9+W5jv3wOTSvjp8iKJHAl5cz70P76vgpghLlC1CKoET5 ApQiKJHBl5c0a18EG5G+PJ7rrXwRYp//zyP5Ii4x+SJqsP15V4h9XpK85qXAsUkIIYQQQgghhBBC CCGEEEIIIYQQQgghhBBCCCGEEEIIIYQQQgghzvknwABeAyHmCmVuZHN0cmVhbQ1lbmRvYmoNMTUg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1NjAgL0hlaWdo dCA0MjAgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMzMgMCBSIC9MZW5ndGggMzQz NSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIieyX22KjOhAE9f8/7d3YJr4Rg8Ro 1C2qHkLOCe0ZiVoxvlwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACCF0nL/z4/yn6pg qUss97fUauvu0lqsbRdzFhZNky+XJ2+6V2quVSPn4/76Yu33919YOId2pi587CHUb9KBejXR1oOz pVZrIo5EX1JrHStX+2/+yP3n8EX72D5Qrekd0Xj/id5HlYfwoWottWoTv/c3FCvVL+bmWm3bHsih 8yWpWuMGpRVr96Wh1FCaV9rY+ZEXknCx6gOp/V/daGFaV9r2NNq+4tZvUmqxM/nSPrJWv0kP3N/2 nk8rljkFDh9gAL7yYyeSwl5K/esdTkq5vf7wBTa5voIK5wtU8OFLATeShXnzpfFT1FMGLaYurBV8 MU9lzxEFX6xT+NIlZdCihy/Xeo+xSX+D8CUkFsTY6lAPvkANjr7opwxaPNH7SD9l0CK+CKUMWsQX oZRBiyfyBcaBL1ADvkAN+AI1OPqinzJo8UTzrn7KoEV8EUoZtIgvQimDFk/kC4wDX6AGfIEa8AVq cPRFP2XQ4onmXf2UQYv4IpQyaBFfhFIGLZ7IFxgHvkAN+AI1ZD6xcuV2Xf5PYnkIIPWBlcfP5deW +tOOhfqp5DdCef2BL26pNF/ur6ByefOlpYFpt1U/lT5xlldf7qPMMtHsu5bK+1vrpF9LU64k9beM n7mUt/OFL0lWCPiCMEYo+IIwPmQ+qrson74gjA2pT+pt6nyqXtXGtF8j9FOD/2WXld9qUm21+qcM WjT3paaRabdVP6XjS0Un026rfkrIF4ZeB4R8QRgDlHxBGH2kfEEYebR82dfOtGOhfkrNl139TLut +ik5X/Y0NO226qfwpUvKoMVZfGHmlUbPF4RRRtAXhBFG0ZdLwRhVJH3ZaGvasVA/perL176m3Vb9 lKwvjX9qqxWeMmhxNl8az562WtEpgxan84WvSYoI+4Iwgij7gjB6SPtyKRgjhrYv63dMOxbqp4b4 UspybuyovnLLtNuqnxrhS3nU3VP9855pt1U/ZeDL503Tbqt+ytIXGMdgX+6jzDLRrF/Lxt+5plzL 8rSSqT1fOGGEsPAFYWTw8OX1xmnHQv2Uiy8vd067rfqpISf9Y2yqqF5Wf62pmpgyaNHIl7bqZeW3 XrWOpgxanN6Xy4jvcvCGkS+jm4XL6EdQWx1hRuPlC8KMxsyXa2LasVA/ZefLT2TabdVP+fnyPzPt tuqnDH25lGm3VT/l6AtD70AcfUGYcVj6gjDD8PQFYUbh6MtPqn7oNRgL9VO2vtRnDbZVP2XsS23Y YFv1U86+VKYNtlU/ZelLVBzqsfYFYdLx9gVhsjH3BWGScfTlJVX2fobBWKif8vdl94cYbKt+agZf dn6Kwbbqp1J9KVdu1yPVP1K7PsZgW/VTuedLefx8+jXsg6E/uTtdXn/EVUeYJJI3ulz6+IIwSWTv c3n15T7KLBMNV+HrMn7mUo6fL+uprc8yGAv1U/nneDdftj7MYFv1UzP5svFpBtuqn0r15S5KN1++ f5zBtuqncs+Xt+k2vnr+OHY2xm5wfHWE6ctsviBMX6bzBWG64ujLRuqPPxuMhfqpGX354+8G26qf mtKX9RsMtlU/Nacvl7Jyi8G26qcsfdn1yYy9XZjVl9Erm5V5fUGYHkzsC8J0wNGX3any53/E14qI 6afm9uXlToNt1U9N7svzrQbbqp+a3Zenew22VT9l6YtaiTMxvS8IE8r8vlwKxsRxAl8wJhBHXxpS xWIs1E+dxZf/GYNt1U+dxpfWdxK+hMSC0N8gfAmJBZFanaE3gOxN/KlXyvJyyK2OMMcZ4Et51E2u jjCHydzCcmWgLwhzmOwJIuJ8OZCqjjLvhsSai735ch9llolm37VU3t9aJ/1amnIlqb/y214aZfT5 8nOtinO+hMQaUfClLo8vIbFWytDvR79djCk7A6f0BWGaGfGN9jE2DXtuCNPI2I0bVx1h2nD0JSS1 82sS825ILIihG7TLGHwJiQUxeIN2fBC+hMSCGL1B25+ELyGxIIZPncMbcOPkvgh04MXZfVFowYnT +7LvaxLccfQlOvXt85h3Q2JBiGxQ258ai1mn8GXjb/gSEgtCZoP+HGLwJSQWhNCoKdSKMviyoNSL Lvjyy5/vJHiAL0+ItaOIoy/9Up/3MO+GxIKQ26CPdxK+hMSCENygN2PwJSQWhOQGlT//o0Mxs5Sl L73R7EoDfFlBtC0F8GUN1b7Gk7ozpVynyfslu3oNso2NJnNjyu1HedTVHfAOGq27sGMpfNm4H19C Yu21bHx57rN/MZNUri/X4eXFl7eJZt+1VN7fXKe01DlwbatXkvp7bEcS15KX4+dLHqnbY0H6+8jK F4cOc8GXDThiXnCcd5OxaDKL1M14mzodvhCUtqTHwvJiQehv0P3rQWIx6RS+7EvVhm0WlhQLQn+D yts1pZhuytKXIRi12hN82Uv9EDMj+LIfr277gC8VmLXbA0dfxqV2v5PcFtY7FoT+Br2ndn6K38L6 xoLQ36CP1L6PMVxY11gQ+hv0mdr1TnJcWM9YEJ4D5O4pZkLwpQXXvo+DL02c9ojBl0aMWz+Coy8a qa+fp9FifApf2lPf3kkiLYan8OVIqvHwMU7hy6HUn3/VaTE2ZemLEKf7noQvBzmZMfhymCkWsRd8 Oc6ZjhhHX/RSH3fptRiTwpeY1Pttgi2GpHJ9KeV6dN8vzdUVU2/vJMUWI1KpvpTbj/Koq79B+1Mv xmi2eDxl6Ysqc61mHXwJ5ARflAb78jbRcBW+luVppXGrN+/5cplxRa84vo+kU+Vped2LpafwJT5V Moslp/ClQ6rot2jhyzI+PcYm/Q1qSrWOhfqpwfPZtNNh7veIRPClE5MuDV96MecRgy/9mHF1jr7o p5avf5Vpm4WNQn+DDm5rnTFGCxuD/gYd3taaD7Ba2Aj0N+j4tlYcMV4LG8CME+EnM31TwpcM5lkn vqQwzRGDL0lMslRHX/RTa7Edn+S5sET0NyhwW7ffSaYLy0N/g0K3dcsY24Vlob9Bwdv63RjjheUw yRBYg/k3JXxJx3rR+JKP8xGDLyPwXbejL/qpzdgf35+61IpM4UuX1HZs9Z00w8K6or9B/bZ1xZg5 FtYR/Q3qua0fN82ysACudUq5/qO6XxKri2L4RSnTl5szyyWzuix2G4AvY3E7YvBlNF7GDPblbaLZ dy2V97fWybqW5/bq8yWpz982M4g8X/RTtbHish2jz5fmz9JO1ceeNqV7rQOpJF8KvuxJTLmwtjLM u1t4zL2Z76NlfHqMTRZblIbDbozt0WGHEjE4YvBFCnljHH3RTx0oVm+MwcKi0H/y6b7UG2OwsCj0 n/wAX2rTBguLQv/JD/Gl7ogxWFgU6tPdOFQHX3xRRXNv8EUWySMGX4QRNMbRF/1UWLE9xhgsLAr9 Jz/Ylz3GGCwsCv0nP9yX7c8yWFgU+k9ewJetI8ZgYVHozXOa6Ay++OKBijH44oKGMfjig8JuOfqi n+pUbP2IMVhYFPpPXsqX9TsMFhaF/pMX82XtiDFYWBT6T17NlxVjDBYWhcIE58fIb0r44sg4Y7IK /9QpV27X3OrzMWrnMn25F3v/FVoYdMSk+vKkyhFf9FMpxY4d0uLz7tPa8CUqdXuvGyysvU559eU+ yiwTzb5rqby/tU76tTTlSlJ/y/iZQnn8wvkSmmp8hCbnS4Qv8ELq5JtTq+BLTxK3ManUYzDDlw7k HTGp76O3qRNf4sgyZuwT059c9efdJVVpjPi8G1ldPzWmxSpj8EUoNarFig/AF6HUsBb3HzEn8gW+ 0HnwxZfp6GoMvkxIR2PwZUpKL2UcfdFPKbS4YcyJ5l39lEaLXz8OX4RSIi1+O2LwRSgl0+LfxpzI F6ggePDFl+kJNQZfTkCgMfhyCsKMcfRFPyXY4vtdJ5p39VOKLb4dMfgilNJs8cUYfBFKqbb4ZMyJ fIF2jg6++HI2jhmDL+fjiDH4ckZKszJZT6w8Xctvu6Jj4eGUQYuNxgzwpTz+22Bbm1IGLZa2XKYv 5Qq+qKRajpjU86Vwvmil6qODfbmPMstEw1X4WpanlcFynkScLxBIpQH4cnqqDo2cJ/Y7jBd8UWS/ MUlPrET6op8yaPEttdeY3PfR7foYm+y2VbFYUGqfMWPfCIbbqlcsLLXHGHzpkTJocTW1bYyjL9CP rS9L+AJvfDUGX+CDL48FX+CTv48YR1/0UwYtbqT+MgZfeqQMWtz+JrT+DaqpWBRSGxSYMmhxR2rN GHzpkTJocVfq0xhHXyCPd2PwBb7zagy+wBbPxuALbFN+lXH0RT9l0GJt6m4MvvRIGbRYn7oagy89 UgYttqT+G4MvPVIGLTamHH2BceAL1IAvUAO+QA2OvuinDFpMXVgU+huELyGxtjqlXL+P3S/N1fVT Bi0a+HJzZrm0V9dPGbSIL0IpgxbxRShl0KKDLzdpnn0BNzJ9uVzrPfkCsM7v+whfYJOCL1BDWZ93 Ada5SXKblxLHJgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgO/8E2AAasAb3gplbmRzdHJl YW0NZW5kb2JqDTE2IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA1NSAwIFIgDS9SZXNv dXJjZXMgMTcgMCBSIA0vQ29udGVudHMgMTggMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBd IA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xNyAwIG9i ag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUMgL0ltYWdlSSBdIA0vRm9udCA8PCAv VFQ0IDMxIDAgUiAvVFQ1IDMyIDAgUiA+PiANL1hPYmplY3QgPDwgL0ltNyAxOSAwIFIgL0ltOCAy MCAwIFIgL0ltOSAyMSAwIFIgL0ltMTAgMjIgMCBSIC9JbTExIDIzIDAgUiAvSW0xMiAyNCAwIFIg Pj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA4NyAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgNjIg MCBSIC9DczggMzMgMCBSID4+IA0+PiANZW5kb2JqDTE4IDAgb2JqDTw8IC9MZW5ndGggOTk0IC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ7JdNbxMxEIbv+yt8Rorj8bel1R5KEYJb xUocEIc2IgikFEEO/H1m/LHrTTZNNhcqiqrtJh6P7XfmGdu56Zt132sGrN82ILiQTOBf+mQV154Z 57kywbJ+16xf7y3b7GMfwfabx2b99gOwr/sGHYTAPptGsP5386kVQgYh9AafeyEA0KzwfZ/e0mG7 FsLkN7XRm/rSYwy+ff5e+uFYRuKTx4rfIdmoPY7/kG3oa8jP5zUUfzvOWXyF6lahjW5C4TjKdp/7 96hjBRysc6y/TfIkySNl9cxxJlytCR0A123WsU1z0dhG2NgucG2AnoAewncSR2+nPbTtVoKbdtSp Q7V+n9ts+hw9QSZPk31M1ddUayj9QreScd7Su7YaV6z6gcaIcehfNaup/Do55XMMrJ1J0nYMV+lX kl186Xv0fci+991KCe7bPAzFDIacBC6C8UNSoKzqGDcUo1VLUFBYbVu3yShVtYcYFvsyGAevIyTJ QnAB+oFKz9h6OabnkBzhPS6Oc4ieRjPBdhmM5yBM/iN2eW3PFzTP4452CWegHZeU5U1NGhgVW0+z VnospW3wm+Gt2GriCnWD33/unid3UnMjFNOaKwAdw/3k/mZMjFjJdd12fMSONq2JU9cu3OOK99wu Z1PulOjSwCMUo1FvunzQzBIipyuLnJzgb6jGmpOidEhHed/nZXjND/fiIWrZFrnKlNaH+GD32Z7T WdvEA9V52gcqpsu5E0SeoewR5/k+wef1wOfvf/kAl0EtZFu/ILblNWyHMNn066YD0nPzKdCLeYbz bEqYwyHmw212mODyy+w/yTneH8Avw9y8IMz1cswPr9GHcD9B9WmoB6YhHQ4TplU78Y9Iq5eJ9Ju+ +dkA+8YaqzhejI3HoHgmASNiGRjHnWa/vjQf2SN2zM2CUeKTLbk5vCpjODa7Zv1u59jtj+YO/276 Zt33huG5vm2Sm2VSYQl5ZoLndF7sUizV9OqJv15jblTiDA9jrh2uiv4jatEl3haonmyqqXL1jAHZ dP33Wpzh3jOFR7q3S8RFN6Mlt1mbr7SNigLXlqmgeJCXKyI5Ug1ypDzSM9XggGbBdHJgSnHFLHe+ LL9ajgdqN8Q5LUbkYbEY0nCTtXvFnT3ujPV93dx2MlxbZeJuyAX+qsLo20D5X5CL6KakI3pSMsJc MjBZGFtwSMwCujAR19OlBI4nY+2EJZKyHxWPLZpAzIjSqAbBNSGKv1SVo1ygqqCvVgUzNeNPa/Is OcWKKSUDMKfIoyeWjKYCW1QyyOF1ahIXduH+lv0id2WDAzmbI4vKwTkK1zJFC6n7I8AAxVV83wpl bmRzdHJlYW0NZW5kb2JqDTE5IDAgb2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFn ZSAvV2lkdGggNTYwIC9IZWlnaHQgNDIwIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNl IDMzIDAgUiAvTGVuZ3RoIDM5OTcgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIns l9uC6yAIRfn/n+6Z0yZNmpuCgKB7PUzmki3WrFHyegEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAF0hy//8v9AcrSLzEer+klmx2L2kx2Sr6fDBtRL68dt6YVxLX4si53c8v Jr/f/oOp07QyvHDbQ+AvUkM9TlS6cUpqSRN6OPriWqutHPd/vuX+OXyJvW03VBOdEcL7JzqPmJtw UzVJLW7ie7+gGLEPZnEt2bIr0rS/OFUTLpBbMbkvglJdEX9S4cxbDqTAxdgbkvy/rrcw0k8qexqy V1z+IrkWm8kXecvKPkkb7ped827FPLvA7g0MAEUgKWDAPd7B3MAXwAG+AA47Xwhko68vFXdW/7qm rFOq+xTLI7l+sCbqfbn5e++HEayYyBfpRgFfLFLdpzipL9c39H4YwYqN7stra5vgi02qon1J5Aun et/5ZUX2f6gysinwxYZ5fZHttsJaaqneU6zwZdDz6Ooe+FJKwRduSlZLK9V7iqWByPmDaVFV/XQT fCml4AvgUOGL0ci21FWHMFzgC+BQWLGGBe3sC4SxwG576e1LnTH0+GN1Lb9U5ynW+JK23+ULA18K qaF94QsDXwqpmvYlry81ZxJ84aQG96VmFmh5Gdi9HgXxpTwN+MJgfF/KZxKEqed5rZpWMoovpv8U szGFL/XCoN8tpGp8Sd3vLj9V/l/Al0JqEl8Ks4Evlamqf7shfKkTBr48pyby5fFMQstbh2G7G86X xxlBmCrm8uVhSvClirou0GBsZejN5/pU/f5MgjA1jOLL/k3u+aXu+ffod59Thi8Nzv+x9Pvlvvqj MPDlOTWOL+9yNb7cnknfAUSlvVJxfaGamzjFjKFfX5ZWZu1o9te73//PXv/++Xo/XpgriXJ0/L1s fcp1vtPzhOr2l9s/ouUtYdnu+i9/vS/Xf4UvJaqOI4vBTWD4ct3EQJgCw/iyiFLvy+UN8KXAML7s 27ra6lfC4P3oMVXnS5L3I3b1sx3w5Tn1MApV3cUp5ktV9bMwdrWUUvDFhrrqpwURTRq+zOLLWRDh kTQHdb7oD+5AdXWlM2kK7pdGYdGS+AJh6oEv71txJtVhehzl8WV3Mx1/oV+rMdWz3630ZeR+93D3 SRyDWm2pmL7Q7Q/iYs4wqy9H0Jbi5OHLdL4sgV2K0cTAlwl9wXtSEdPXo3S+XLwnqcxkHG7XQ2Wh 0vlyDjHOpBmAL8UUhNkBX04p0Zk0fb9LDz9JizkjXqCjMRUDTeJL7fYyly/nj18cCr4o1MrrC3uL gS8KtVL68k2rnMiDYdvupvbl9K8FY+6XVGltcvuCLeYEfOEMAWHgSyH1u8Xcjzh5v3v8fZJ+9389 ovUZ6yzrjzG3Tczcvpx+nccX2upqLWvNFgNfFGq5+kJvLHw5bDG1KVktuxh8ORVT2F/o8sjZ//L2 TBof43a3ty9LK7N2NDXX2/uJNw6uzCutq+8Hte0vu+leTfxnixHMbgRUmzfLgSqriX05uV0wZlJh xvLl/UAFvvy6Qt/fXtz5U+r6Lxyy9bvVvX6Gflfmy+nQvHfi9bDFwBeFWu7b9r5bral+1WHR899v hIEvCrU6H/OF6jft+HG7Od503RXDF4VacX3hvLs9GcOeU25q/sHUx3fjrjrDlTVwN/JkwkzoC1uW JXXz81TCVB9HugW8uHq9Ec/ozhj5iPmYy5dKWW5vOuZ/tpgp+t364yh9v1u/szzd9zvId4sppGS1 1GPwpbI652WoNOdLY/4u8EWhVgRf+C9Dpb//GnP1S7VaqjH4Uqze0N8+jUvnH6boeq8+pOoH7+yL WXk6/9fNIMzovliOTcfv7ewMA3xpGX0nyGKMab0AwJe21N4YUcH8/e7NoEn7XfPU1xjZDpPLF8b2 Al9ub1/b3fc33DDv9rYYfDGpzj9UVlHo9WJ2vfBFJaaEW/VVksG73vr2RbGCI47V11NJcCblAb5o Flv7mN6f2g74YlBuYGHgi25qJ0zlINn73dshJ+p3G1K0fa0bBb6oxJTosKzMMwm+qMSExejzn00/ r7f8YZpSyxZTOU4qXzjtSwJflgf1fV69drfvmTRa18vYXvRK2BHFl614bdebBPhiNRPWmZSG0Xz5 PKC9L4eOxvlKnerm/Dz0Hd6Jd8lX+/6ikqpsYnL3uw8DZul3o/iynUmPw8EXlVhLrSC+bBN52mTh i0pMXkuh31VLLYf+04ipfXkaL4Ev+7asQ/Urqs6kNHB8USrhS//HNJQw8MVhCu8dL8RUWuG0L2o1 XAnxkJYm5qnrzYHD9pLSF+3U0xaTqd9l+ZKh31Wqrp+6Fwa+qMSUiOLL90xSqgVfbAjjy3omabWM EXwpfGBRrZS+2LAIE2lKTFi+6NRwJtTDeeh6cwBffPm/t1w2MUmAL97cNDFJoIefbGp4E6ffXW+i gzCJ+l3e9jJRv2uaep9JW9cLX1RiSgT05XAmwReVmBIRffk9k9L6UhprIl/MOTYxOfBod+HLJX9b zK6HSQJ86cin7e09CxbwpSf5ziS6/cGqiDsh+931/veZlLXfLQ41Ub/rlaLPu5JPsfYUfOmdkjcx 8MWE4L68DySRMR0+GLN9mcgXT/K8J7m0u75PbPlf3f5lEzwIymLMeL7Q5wttdRM8hvVFqfcsisCX MKTYYujme7sq1mj54p/6bDGMETr3uxUDJeh3L3w5dDR1V2LeL61zuO5eloyusvFJ6fPVff6H56vO +rhf2faX5bv65cL+okDe8+jzLaPv7etLzTgT+dKN0G9KTF/aq5iT3pd96xQNn9cj3yd26MoS+hJ3 i/HZXjo/sYgLXyKoMfAlbKriUPKfIteXBP2uVvXuqfIWA19M6P7kpamSMT19qRsFvvimnoWBLybE axvrCdb3cn1pLtODOMstgajY9/oBXxIQaIuh0ze2ZboQZK3lxDmU4EuO1PWh5D5F9nE0Ub8bLHW1 xcAXE4I9eWHq4lDq50vtGPClY+p0JsEXE0J0iir07nud2l34osV13+tX/vSNcZ0uDOTLxaHkWvxw ta7Th6F86XoowZeMqe8W063frR5ion43cmoxBr6YEPnJS1MNja88xT+O4EuUFHwxY7B+d8X/Tcmr 3YUvNngbA1+S09DFiMr9XOwL+dRZlnBbyXF9cTZmSF+WF7/d+1/wzlWc2v49WPnmfpcxQPB+d0Zf 2MbAl5868/nCNKbVF04+py+HjqbuSsz7pXV0risV99fe93ulxnx1Hfb52oDm/pINh3V2W0744oC5 MH6vmz5PjOb2xdwYv9V0emI0uS/Gxgzny+vY1rVUj5+6jJWNEU9R4Evw9yPN6vFTN7GSMW2+8NLw JVDqNvYsDHwxqR4/9RB7Mga+hK7eCYPGV+BLS6VuTOmLwavS9+3THPjSA21j4MvoqArjdxyl9CV+ qiZ2YYx0ihJfJup346fqYidjWnzhZuFLoFRt7GAMfDGpHj9VH/sxBr6Erh4CjcbX7/UIvvSn3Rjy W0n4EoBWY+DLbLQZA1+SpwQxEitDIl8m6nfjp0QxqTC0vCFxUyLgi0VKWky0yZDoOIIvgVLiYiRQ Br5MDV8Zx3YXvkTkvy4MZyTtixT4EhOOMvAFvBjKwJfsKa1iqzKPw5HIl4n63fgpxWJlZbjvU/e1 7GKiOmvjv336+E++uy+vRYh7Z4b1ZSl2/FY2VuiUerEnZcb1ZadKiy9zcquMZ7vr7MvnWNp+hi8s NmXo57eeU3CuQ7++LB99XQFcy9e9MvTphn3qn0S1hLZvsL+0cdxlht5fNHyJn7Iutu0un/3FspZK jF0FviindsqY12qPscvsGl34opRalfGo1RiT1dl3aQ3V46fcir3PI6daLTEl0O+249ruwpf8wBfA wnMV4Ut+4Ev2lO8URbGJ+t34KecpSnLwJVAKvtgQ/8mn8EUSnMgXcMRvHeHLCMAXwMJtIeHLEMCX 1Cn3KfKTE/W78VP+U2RH4UugFHyxIf6Tz+ILOzuRL+ACp6WEL4MAXwALn7WEL6MAX/KmekyRGZ6o 342f6jJFXhq+BErBFxviP3n4ohIT1/l/pT98q8+Bx2p28IW2n+GLJqP5Qm/gixkOy+m6vxD2F1PG 92VpZdaOpu5KzPulddyvJMpRY766znd4B9b9RGN/iZ/qNUXGACnej+CLbWoUX2itQ/DFMjWKLy/S 9AXcYr6gvufR57q1TfBFmWF8iVh9RKxXFL6MBXzJmOo3xeohYve7qtXjpzpOsXYM+BIoBV9siP/k 4YtKTAn0u/rYril8GQ34AliYLip8GQ74ki7VdYp1o0zU78ZP9Z1i1TDwJVAKvtgQ/8nDF5WYEuh3 TTBcVvgyIPAFcIAvgIXdumb0JX6q9xQrBpqo342f6j7F8kjwJVCq+xThS6pU9ynCF8DCamXhy5hk 9+Vdh/7YLo7V52MEXz7OrBfP6hNitLQZfYmfCjDF0ljB+1344p0qDJbBl480e18OHU3dlZj3S+u4 X0mUI6fPS9/pObCo8nncL+wv9qkB9pddSfS75pgsrs8TI/jiT2Jf1tblpdLvgioy+/I6tnW+1efE YnX7PrEAbaFJKsYUH4cL3u9qVo+fijFF+JIlFWSKT+PBl0CpIFOEL4CF/vrCl5GBL4ADfAEs1Bc4 oy/xU2GmKOuFhcXsibKs2qkwU4QvKVJxpnj7R/gSKBVnivAFsFBeYvgyOPAFcIAvgIXuGmf0JX4q 0hRv/jxRvxs/FWmK8CV+KtQUr/8OXwKlQk1xel8AC9VFhi/jo7nK8GV84AtgobjMXk/sXYf+2C7i 6vFTwaZ4dUfwfpfWWrRe5NXjp4JNEb4ET0Wb4sUt8CVQKtoUh/Hl0NHgGvhK69PyYFe+eX8BbNQW OuN5BNgk84XgS2e0VtrpiRH63b6p000J+t21fdrapnDLqpSKN8VsvmhWj58KOMXjXfAlUCrgFCf2 BQhQWmr4Mgs6aw1fZgG+ABYqi53Rl/ipkFOkh5/Ui9kQcVk1UiGnCF/CpmJOkW5/MChmQshlVUjF nOKsvgAZGqsNXyZCYbnhy0TAF8BhUl/ip6JOkS6/NSpmQNBlbU5FnSJ8iZkKO0W6+M6smD5Rl7U1 FXaKU/oCxDQvOHyZi9YVhy9zAV8Ahxl9iZ8KPEU6XE2LaRN3WdtSgaeYwRd687m+vhdx9fipyFNs Wnqn/YW2r7Re5NXjpyJPMYMvO0fgS+dUCl/edeBLiFTL0vv1u3TpC8iGly+bKDtfALgDvgAO8AVU 8isKfAEFlkbp9wIAAAAAAAAAAAAAAAAAAADAP/bgkAAAAABA0P/XzrAAAAAAAAAAAADwSwABBgCw ihumCmVuZHN0cmVhbQ1lbmRvYmoNMjAgMCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUg L0ltYWdlIC9XaWR0aCA1NjAgL0hlaWdodCA0MjAgL0JpdHNQZXJDb21wb25lbnQgOCANL0NvbG9y U3BhY2UgMzMgMCBSIC9MZW5ndGggNDMwNiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFt DQpIieyXi5akIAxE8/8/7e60L+QlCQkIVJ3d0bYpgngbi22DIAiCIAiCIAiCIAiCIAiCIAiCIAiC IAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCIAiCmogk7f/+0H+xjMRznO0ltWSj26TFZLPY5sa0JeJl c7gxrySuxYHzbs8vJm9vf2PqqpoZnrnuIfAnqaIexypdOCW1pA49NeSlaa26ctzffE37NXj59rJd UU30jhC2X+h9xFyEq6pJanEdV3tBMWK/mMW1ZNOuqKr1pVE14QQ1KybnRVCqq8R3Khx5zQvpw8XY C5L8V9cbGOmdyp6GbIvLn6SmxVbiRR5Z2W/Sivay93yzYi1TYPcAA0GvAqQQQ9zXO7S2wAvEEXiB OHJ4IWg09eUl+f15EmsRuVZwG7I7Fc5Py2LkfyrqpumNVYnFSyEcP7Ty8IMXhVrz8EJvyIAXhVpf 5OW6SsGH4PS6RJkvX77ICryo2Kp0x6YsL9FD2vX2LXhRqNV5X1vOS3kw73tH3VXKi7z7jmLwUj7S tYFZnpczxpD/fbpXokjwxftIodYovDxmoWzMfivwolBrYl78ZuBFodZAvNyNS8ccTKRA4EXFpqRE dXp+SWeEUep+ai2Yd9V4WREY8JLgxXLVHVjL8kJ+M/BSIvASDcClI2fvqpL+BjbkXVn1RFyR8MLf VSXsLWzgRVa9hBcCL1HXirz8rr/xwn0hgReFWkPx8rjE5mURrZh3NXlZDRjwEm8OXuICL/H24CWu VXmJfkX3XzYvy+Rd01w3Fi8nKht4SbnAS2CgXItkDfCiUOujvKTvmrz/5UXAi0KtIXk5jwi8ERW/ p6Xd9xSfF3e1AC8RgZeoBbwkNBEv9NN+fKmeuWu6/oKXiCbixXnU7mm85ctXyLsJ11R5l55/2vDy VqvA28gGXmLlinjJjOv3Ssu6I0XBi0qt5i/357M+As2VaIqOv3+XrcBHsjrtj4X348/Hy2et4xk/ 24qK1pccx/erCIE31Ex5dy9Yy8u1RoGXiMBL7DvwktJEvBygFPHy0g/PvhIwE/Hixrqa6jJesD9S qNX5pyecIAIvSRd4CV3c5cnlhbklBC8qNiVV8sIKvHQ6wYu81pC83D7mBqkqNQ2imfKuWnUmL17c AS813fdUbXVZ4AUvNd33lC0v5BLixtyZgQEvGVfaT49o+/dBxgvyropNSfq87MvIvYGKtgUv4OW6 sq8sYZPoRUYtlsCLiaonyO8gBlDkK/CyEi+ZDjK8BBfnTL3Iu28dvCwcCWDIeGJ7CbzkO3iklVh/ cV6mXWHAS7aD5wJTzItW/e8JvLy6ynjhslTaQtGGvGtSXY+X9wGAFxWbkpSmNYvEeTX7ZXmtMoEX E4EXdRd4Ke9GgsRskRd5t7ibRG/gRbX7ntKqTrneXopQ9HRYgZfSfpKdFS8w4KWg+57SioX/r1C6 r+zq41yPdYG8q2IT668e0flk1KY1Q8sbL/cXsakGLyo2sejx8tDj5b39iWiAFngRF7MV/WTCS0H7 Y2WL2O/FDrwY2cTFNNYXQdnHSWKBifIynGbKuyEvR5Q5E43RkZ5Hin7fYBxtjmTV7zlL7URd1pdg XYkuMNRuPJaaaX35Ki83K+MDMxUvG2nwwnbRWTp1gZIDGi3vFuMyQt79FC/kXiLwYmoTy02V7aY1 yCbnCO6BgBdLm5La8eIl+yDKHIseeLGxKalV9cw20F3pqPd81Ms47i7CS9kQCLwU9N9TX3g67i7J erbtBV6sBV54/fdUt1gYu06x2UbeVbEp6Qu8uFsk8GJkU9L3ePGbgRcVm5KMp5XclmkX3X+D6QYv KjYlmWczooIST16oyPNVIe9Wdl5Sgp5/es9KjcBLZd8iXrZhlxjwUtt1ITD+ajQoMOBF5goffM4V 4YXxOsuWb+xC3hW5guf+4tqnmUIjeFGxKclqWily/gMitfuhEw7wYmJTUs0Evbxfgg8Ucd7w7DSF pIEXFZuSaqpnvJT49NwyUcgHBbyMJuRdvpdSHx9RhoLGPi8jAgNeuN4gn4S8uEHl8W3khTSYwEvS GzXHrsbQSEI0+AIDXhKuxMRENz9bYIidHry4Wyjx7CPvmqgbLxGLG2quZSq+iBUOsYcLvCRcfF6S gefR63X1dInGCF40dKz094Kvzku8w92QLEZOo7CMaJDgRUHuc3aekbQzJi/pYjlecr4vaqa8q8xL zJ1bX/IDiwxoRGDAS7ozNV6czmILzEjATMXL/jt2efESDe9IQl/xkYz7NznK5/PlSNd0NBJtx2Pe 6taXTBBNdPi73WyX0XcPiceJvKsgd8mv5eWOHJEKScfr2LxW1+xzf1fgRUH9eCmv5fFyc8JbisGL gg5QPs3L3vHd1sWEMVrwoiEvjdVUd6Dzr9aJfrS4i4kImF6aaX+kWd2OlzCxUHDyXYGXjNOCl1hn AwEDXjLO5rx8HxjwEndFecl2x691Z2o3/xZb+ULeNanenpfnjqnQyhd4Maneipc/yx1dbk4KegIv JhJPEF1nxd1V8uL28N4VeDGRuLqAF1EZIvf1M8A+CXk3Z7Tmxe/1+8CAl5yRYhfVNRIw4CVnbMPL AxgKr31J4CXqEvBSEyYfqTe8pFusykWlfSyUd51ti7c3MKn1O4T7JO3NmI4LvERdMV5eOqt8GO5G 6R0Y8GKigXh5nP+eCnhpLmn12DalwZ141YqfTUNZj2kaXprciI/n94gBL1lfbKGxFPkFv0YMeMn7 ohslS5Ff8VvEgJeYK+CloCO1CEp+zcgzQt410ZC8nBdzWRu8mGhQXo6nQsEwTIqxXOAl5vIfVEk/ uo/wqJuKT+DFRPWDLudFWdf+qNsIopoq79I+u0RBZGT245/3eFpO3D1v6gNbpZl4OR6t84RH5iWa d7sDA15SHTnnnZ5SLO/2Bga8RPoR8WIRQSnkpOrG6l0z5d0IL16iKTveUcGxv/r4dcqObnhxj4L+ iu4jOMrrMes0T2jHZP5Ot/svv5vHp47ryzEcf69EWF80ZPI+6s+L2+oix7BY1gVeEv04n3pnzM0F hrwLrQeCvBvvx/n0AV6cMRA9Pzcex0S8uLGupvoXeXHT4H6TvYZh3L9t9ybVP8nLLie/9BkVeHl1 FXbSJoJWbZGQd02qf5mX621E2/2CsisWuMDLq+tjvByLiyShgReT6gO47vzCWWLAi0X1D8XbtGi7 3keNt6DG/dt2b1F9CF7c91HLAYMXHVNznaN0Xk1NyoIXFVN7kXPSbsjgJTR9P+/ur6Ejv5QDg7xr UX0UXvaTI8AU9VM/RCruA7xY1FKY1iPAlIwavFhUH4yXa3l5Hzd4Mag+SNx1db6P7Idezou4QE8t wsv1PjIfO3hR8XTX+T6yHjx4UfH01/k+Mn+c4CWwjJZ39yvHEpPrEHlXv/qovFwJJrNNAi/V1f0W 8tTYnZdr8EliwEt19al42SNveoUEL9XVvd/imGHX0ZlijG5k+bw7Gy/3Rukn/d7BC6v993VulPYP 2p3Pwsv+s6Jjssqni7zX8ww6J+F3rtz1TLwcE+TME5OXqh/lF/Lu8+s/ZBSWz8cPqriLj+dd8PL8 /rqV+uXzMUHgxWk0Dy9X3o39HuS1pufFSzTRIz2Czw+gbPvE8bVOryORd39cf7NxWuzoEtJcX2bS +bgVezPVALzcrSbk5bdYbpyg+tKZRjfZCi1E4CWpc33RIGYWXo7f0F5QzMuUuGz3+lJ/f9Pwsrnx 6Y5NZbz4+6Ip9keP1sf6IltiptwfSasvwct2rC+y5QG8+C0W4OVcXyRG9xS8bIvwcqwv/HcSePFb FKedwbWvLxUbpXnyrrT6Urxsx/oiJga8UPB3btFWQwx4WY2XixZZAgIvwd958+55m8ydEvJu0GAp XrYfMuVvJHLPwMt1IO+idi1Fl0KxcmDAS9BgQV7KgQEvQYMnL2uI+JskaUzmlego8JLRBQznzQRe rsNqvBzAUHn4BS/ulmg5Xn7A/FgpfDeBlygva+Td/cK+wvz+vbuQdxfnZdtp2XFJ9Qlewgar8nK9 hzIZBryEDZblxfkyBYzLS3nd6XlZL+56otetEocX8SB6CrwwdL2a0i3Ay31cnpdjecnulMDLdQJe TmDAy3sDdyrWzLt3Kw8YZ2IYZefOu+DFbfbkQrYGf5yXvzrnYnovqeBF4qInMdPychTzT19t+wl4 cdq5MWZeXhxUaniBjkWa/Kv2c9SWl/21dH8GL0LR+X5/XJyPl98v4/58/kjOO88dS9utcnST4P3J sO7dfQP5CwV7fcHyEujHiDMzLeZoFF7cpsvn3dtA7kuJxcun8y6BFyPXHzHxNKNfq8LGLuMEXfCi 6jqjC9P/bV42Nz7dvwTwouE6p5Nl/zgvwupRXiBPdCwyTUr1FIMXKKNj1W5UqZ/Ai5KazRN4mUNN Fpet9wOR8YK8G3MxiZk973JcslqKrj5DxP4IvHBc4AW8cFzgBXmXpQazBV4mEngBLxyBF/DCEXhB 3uW4OP6F8i54SbkYHYCX2lqKLvBiI/Ci6wIvLUYxj+ynC7zMpNV5AS48gReIJfMJG5EX5N2kq7yH KfMueGG6wIvAJaul6QIvNgIvyq5peCHnSP9VVh15lyvrGevAC92fwYu2ZuKFfgIvlpqJl2NxAS+G mpyXI8qciabsSMz20jrNjyTyUaPx0TW8BjrXE431BfujtKu4iyH2R+DF2jUHL3TWIfBi65qDl400 eYHSmirvHsc7NoEXbc3Ci6w6eOEKvEAcgRe+S1ZL04W8ayPwou0CL3yXrJamC7zYCLyou0r7WIgX KCPjKQMvkwm8QByBF4gj8MJ2yWppupB3bQRe1F3ghe2S1dJ0gRcbgRd1F3iBOELehTgCLxBH4AXi CLywXbJami7kXRuBF3UXeGG7ZLU0XeDFRuBF3QVeII6QdyGOJuHlV4f+6z4UVAcvbE3Ey87MeSip Dl7YAi+FV0tG0MqFvFsr8NLINRMvOzQuL16iKTsSs720TvMjiXzUaHx0Da+BDlT2x70Vri+Jr7G+ ZFwzrS9OyRpeoIymyLsEXprJdtIaPRIS5V3wItAUvGx+rCuqDl4EmoMXUXXkXYGrsJOP511RdfAi cIEXpktWS9UFXmwEXvRd4AXiCHkX4gi8QByBF4gj8MJ0yWqpupB3bQRe9F3ghemS1VJ1gRcbgRd9 F3iBOELehTgCLxBH4AXi6B/79babMAxEAdD//9O05RpQk3gdr1vMzAOWgk4WwREs+hJMtc3qmrLv 5tCX/il9CabaZnVN6UsOfemf0hci7LtE6AsR+kJI6rs26iM5zynfHsf+dPtuS6ruLv983y23WeV2 VEzXl5aUvtRdrngFo1L6cpS+DEvN3JeXjeblLCvXnVtnybrv/eMYYDH+8PcLm6b5f9Tr94hNE/Sl 6Ms4E/TlVOy7w1LT7LvLNbZqur60pKboS9N0fWlJ6Uss1Tara0pfcth3E8yw77ZN15cW+kKEvhDx sX1Ze9a+u5n62H1XX5pS+hJKtc3qm9KXHPqSkNIXIuy7ROgLEfpChL6EUm2z+qbsuzn0JSNVdRt9 OTSrb0pfcuhLRkpfiMh83/RlPvpChL4QoS+RVNusvin7bg59yUi9fV/K2eU83Y/d6frSlnr7vlyn lMtDebmyk6q/XvMaxqT05aCyeNCX5NQEfTnP0ZcxqRn68jPol77wbkb15VGURV9gjb4QoS9Uei6K vrDjuig9HwAAAAAAAAAAAAAAAAAAAH/vS4ABAPIhJXIKZW5kc3RyZWFtDWVuZG9iag0yMSAwIG9i ag08PCAvVHlwZSAvWE9iamVjdCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDU2MCAvSGVpZ2h0IDQy MCAvQml0c1BlckNvbXBvbmVudCA4IA0vQ29sb3JTcGFjZSAzMyAwIFIgL0xlbmd0aCA1NTIzIC9G aWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJ7NeLgusoCAZg3v+l2bOTqKAmUURz6c/u mU5bkVy+UcKMQCAQCAQCgUAgEAgEAoFAIBAIBAKBQCAQCAQCgUAgEAgEAoFAIBAIBAKBQCAQCAQC gUAgEAgEAoFYEmQZ//8P+hddidSXEcZbatmOjq3FbFdxzYl5h8kLCzfTK5lr9eBM4/uL2cfPPzH3 GLoyfcljN6H/Ig3U60m1LpyWWtYMv1joZWmtsXK9f/Mj43/Dy7OX7YFqpj3COP6H9qPORXiomqVW b0YcbyhG3RuzuZbtsjvG0PqyqJrxAi0rZvdiKHVrmM/UeOQjG9KDi3UvSPa/urvBWM/Udjdsj7j9 F2lpsV/yYm9Zu3fSgfG2fX5ZsZVd4O0NDAJxGUCK6Ije7R3x2wEviJ6AF0RPCC+EeFvc6+V4EBVv //7tj3Tbv/A2nQdVs7eP9ryYUx9XO9j+sKU5ZDVPsfTEhsLJCxm9MLzYa8FLy8H2B7z4BbxMzPqg Fy5ub3VM8dbVC8PLeLHl0eeFm7wcODB6eVvMPiF4+VbAS3xr8UKxCPYjj1q/54WVl8vzhxeXNKdo 9sLw0pYFL3EkvDRkwYsa2e6FYtqQl7cF+l010sfL37Dk5Utm4EWNHPWSPt4elODlYfNbq6/wQvDy uPmt1V28UIMX0keRHxH6XZc0pxj2QtoLSS906IVKL6TrNByh8cQmZ8GLGqm8sDQTs5q9EMPLWLHl cVIdXkxZ8KLejnjh0gunVub6iF4Rv9rvHnzl54Xh5Ynzm6sPe6GqlzhMPEPto6+O6BUBL9mnhRcu vQQB+9fhq6qXiE589eKAl+zTQy+7gSEvVHhBv+uS5hRTvNChlzjLoReClylpTgEv3lnwkn0apbD2 Qgde6NILw4ux2PLw90IjXqj08rZAv5t9mrwwvJQBL9mn7l5iAwQvD5hf1aJ0gy+rW7zsWIITgpfX zV8pRtmvZ2PLTxu80KEXyZS4xQv6XZc0Y5D+AS/uWd/y8lfuOV7CpNsulrwkSvDik2YO0l5I3vi2 18Qj2Qle6hEHhnnUBJX1Ja4zi19tdWnR8cXLtDTojvWF9sJX60uc9+bnRnvMPm54qXp57WMSvOTZ /l4YXh4zf1Gr1cvhFPByFl/yIts6Y3XthZu87E62fjeVzb1Q1Yvx+tjSHLKap1h6Yl4x2wu3e9mf 3OBlSppTuHvhMy8ML6O14GWbBl7mpjnFBC907aVoZk+8vC0+1e+OV4eXi4CXPGHQC1W88ImXl8GB lzxh17C9hZcs4CVP2Ag0emFq8sLH/e5tnastC/1uniC98IEXrnqh5KW6wpReCF580pxihhdu81KK IXiZluYUj/ZC8OKW5hRP9hLJvCrQ7+YJHl5iByMOAF6eML9z9RVeCF7um9+5utkLXXoJa0t8xIKX G+Z3ru7ghbq8oN91SXMKVy8EL/BSJpReuOKFLF62H/Din+YUS71Qk5c0Gbz4pTmFmxc+9ULKC515 ocwL+t218ztXb/PCFS9U81KuHvBy7/zO1R29EJ96oaH96LaAlzyh3cs2QAhg0hwuvIRd7E0BL3nC Ui9hmukn5pX1tX53u0vxdhvS1V996YUHvSgpwkvfocKLU4QOsvJ40py+/be9H/QSjyC+wsuMNFut 0BTwEi+hpiRSeqEwqzhElUOWQ4UXjxBPqKu9cJVBaHbCzlRfiWyHek98qt8tvcQ+It2vq9ewSMTP 452NJtS8Gol4H+dNKmrDJL+ffk2XaVnQwvUlDNi+FnSkl8P1hTMvWF/WzJ9Xu8MLV7zwhZd8fYGX NfPn5Z7khZIXSttX+G7Ii+2yOmQ1T2G88b/nhTMv6fNDLwQvg2nmSF2mqTq8XGR9zctg9cVeGF58 0pxiihfu8sJVL5R7WfwgaY6P9buj1U+9kIuX8BEnhvQeMPCSJ7h5oWsvaXuClzXzO1ffn60GvDDL RYNTW7tN3ObluXbgpUy48sItXkRTMsEL+t0p4e8ljLvwwnt3EsZILxx1FF5IHobriXllwUuZsNaL 6Hvh5Te8cLMXPvVC8AIv5144eRF7Evrde2KaF27zEsfUvBC8rJ/fufoULxz2mgsvTHGA8XznB7yU CcNeuNELF17iDE8lAy9lwkovZPOCfndKwIt3FryUCWu8UPSSyWF4uSvgxTsLXsqEUS9c8yJ6W+mF 087EHV5uC/S7ZcJsL2koMbysnd+5evQS3l954UEvVPdC8HJHLPfCwgtfeSHhJTU2uyV4uSGWeNlb 3DYvrL2EJKp5OTl69LtT4i4v+1RqDcq8EGVLTfASdjZ4WR8P9CK4wItbmrEYpatuq557YR8v+6zJ i1Rz5IXgZW7Im536iP4pirtO4X8xsPTCh172945ebosv9buP9xISDr2w/uru7bwS8FJO0eQl/lLx QjFTZZx5CZud/gpeptba71yqG+5DuB2m17hDUPX7PyX6tqtf0nFoJTUvBSX1+eB5PP01nu2q2Bb2 8fWFKguDaX05Osau9SVVqpXvP7uxrOYpjDd++X602gvbvFSWmjCb8gQv8+IVXqjwIja6fQ65yMDL tJA3+y4vcpZqgbSWlF7ioxK8LInwVxrbJpuX4hJtt/Lghvl5SWvMpZfbYvZB3HuSi72oL6u1VSML L+vnd65u9cKll/r8F17CG+XFuljOCHipJczyoleNzEt8w7mXrTa8TA/Xfveo4Rz0kvOIe5ImhH53 QdzoJS+tWtwuL3H/Gjkxryx4KRPcvVDYtcQGxBUvLL2wXmP2bth6Yl5Z8FImdHhJMvq8iLdnXrJl ZuDEvLLgpZZQXqJmL8QXXlh5iRa1l+SISy93XlP0u7UENy/xZ2TQ4IWEF4aXhXGXF0pS9hGtXkSD Q9JLXJosZ+UY8FJLaPVCTV6o7iWK2FWEAbLBzb1QfhyrA17KhKLf3X8WXmjcCxVexKiwfpVe0O9O iTd4oZSjvJDarTj7sPfExJkMZcFLmbDMCx97IXi5Ie7xQsoLnXkJY6nuJWTGNgZepobNS/USmbzI 3YWrXvjCi2yIM0S3xOy6v+WFrrwIFtJL+CJlwMsdsdBLWCTU7b/2QnUvXPPC8PK06t5ewiNQHCm3 nfD9lZc4M6XZ4OUR1Zv73e2zVi9U9SI1UfKilpKdCcvBHNcdy9mNZaHfLRP6vchVIC0XVPdCnV7C BpT2IniZFE/wEneR6CVtUZmXZCVreuVqAy/zwuqlMsmRFxrwQurXsFm1eqkdq/PlKLPgpXGSYS+k vSgErV7CEpSlLIxP9bvhz5jCVXyAF273kpaNvLktRsOLVy2Se8qdXij3QkdeMgjbSYTeOMMEL861 lnsRK4nZi4LA515ITgEvo7UcvPT1u1UvdOiluh2ZveyrjO3ELFlf6ncrXvbLGa5q2yvp93T4ebxf so7ykr4tb/PRx3F+Nc2JF2o9P2ocd3D+k1/j2S+L/fb8/crpZ/c0B2+Lz+l0fSFKajm9Le54liK8 hA4538W4MoPhxCyX4+Pri32eytvswvl7CfnxR/TC2ksY0PlnCS9lrVn9bj7bgRcVVi9EcfaaF7Ud pk1xSaDfbZu2mE17oV4vLEcJL8oEhS6b0iT5ZPAyUIxUdzvXC3V7oaqX0KEkCIrO7qVon+HlqdUz L4FiuxcBgtMv5170HHIN0u2RGLgk4OUyq9VLpckQXji86/dCqq1RRVg8LF2fLvrdKdU9vHDphS+8 7J/VvKjdqfCSEudfDni5zDr1Em1UvPC5F7HBxDHlIqP45E9KYWFRPc3UywEvl1n1t0depIJTL3Ev OfdSRPkVB3xxz5t3OeCld5KtabV4CW+kFw5ftXjh7FV8HvfFy0XG9WK8bv4F1a+9hHuWPmSbl7Dm EOcmlKKyrxZdM7zcXL3dS2pNWXuR0yQvXPfCygvrGvFNbke0vR4n3XgxXjf/guqHXvK//dKLTtnf NHjR3fCBF4aXZ1Rv6HfdvMSvql5Ye4kFRbHCy/4UNelyoN+9zCL9a9xrCi+pial5iXNIL1x44eAl zFB6EcuI/II5/TLtcsDLZda4Fz1d+qLihTn3ErcdzuqFseJjuSxVTh9eplSf64UPvNSrxFFx/eBs SeH0STouMYnv5YCXnkkKL2zxctUhxUo1L1zxctDkVNeYwUC/2zPJYi/yJahg0VWHqrshzryEA/IM eOmZpMvLUfleLyy8cOZF7UNpmdlT4OWO6rd40QMvvKSGhfZ+Ru5QQydfOaap8UYvpF9zL3TtZR97 6CV70+ulaLbjopLsSErVys2Bfrcxy+wljHXzEkpzu5fUFh9Ubg54acx6gJfiTfASPeiHJbG+sPRC Z3UuAl4asxq9cGw4rV46jv7My9a7yC2J4WVh9RVeGurnn8nDknsTCztquQmPSR73Yvb9/BUv8Y89 JszxUh2mdkfV2DC8rKv+Gi+svTBFQ7mX4dvxFS/7Lk2UXoarv8kLix1IPB5x3JlC0zMYX/Ky7+ii tVvX70ovceyEfvfgq8BBNrtlJ0NkuSCf7Hdf5KVay3iIWTHhJb5Ln8OLrgMvcn1JXuQCM1rr416y jqbtlfQr6e/1+k6Rjrwjclh73bFXvY6Iozw4vuZXWnP88eIuCc/1Rc6pJ9nXF3F2NLi+OAWls1de xPNROOjhQlPjp72sD7H2cRJC2SY6cHTf8ELwEotuRyOOL1GJH/66l+0+3eaFH+VFtr5ppcl1Dz4L zIqV+1HYntMuPXZNDF66Kxqvz1GaPNbEReARdky1bFntcctf2WD1Ri/8bC9yVVFdcDpYQy14Oc46 80LP9KIHic1HkOl9dIWXxqwjL/RyL9uTU3NpeOnLvvTCA16mxg45+CgfmuTI5imnxme8xKeuF3lh 8cAkO66AqFhKm+abGvBybygvod/dn4/EQxK8DFenr3jZf0kri+5lwped802KN3oJQFZ4WdcWUjp0 FnC27/5jv9y2YwWBIMr//zRnnbTIRSXNRSbT7HpoZhLKhriDZY0X8q7KVePFfyMv57ES8q4Py09O mt96wcuTyxov3kdeQvY9mXGVEwZeVK5bXlzKi/86XrIUE8iJzCh6wcuzdwUv61XkXRf2VHskpe63 V/dJzefFWeHlzLs5L79tAV6evVZ58Vl2SXOw95Xn0ul+e3Wf01JevBvsuEbJgzXLuyHV1Hh5DsVT V/cxzc+7+RvplZc1Kxza2M8n59OkG5k5d3Tbq2GPG+VdBS/eAC8+4hHzb8KLu7jgpeIyzUvcjr/y 4sOeblzw8uSyzcvxPb4npSnmiZeWPW7ES/Cu4OXDKvNuGs+u21mwxy/nJb7y2OQlpN70iRSjry/+ gvBS9Yb3zXgpo7x478/DxVd5Kd+d5i/n5eu/130TXvyVl2ybWdyFl7uZSd59nZeP5l35YYxp2cPo +mxq4sV43t2Xl/T3Rd7NeXGWePnZULyX2auN1p9/3pmX4n3p4MUpLjG4wqW8ZHe2sTu8eH+eJ+dG k/emI8uY4iVBZYSX8JM98m6iM++G0BuO6sDR+3tcy4s/j8z3ePF2eZFnTthUzDIx+1rjRe7x+T0+ el2838oxBr7i98VT3pXzO/v9uTHLL1Hv9Tsvv0AufuB8GZfL/jMSWKydLzN4OdBIeHE5L95o3k1m ho128/Kn866Dl7muNPQGUAzxctxDaQgv4640xcWnrx1ektsZUxS8dLuOf7cQ184wY4aX0e6XmYt4 +aOKvBTpxUreHe0OLzcq8y683MwMjzJ4ueHFwUs588KL35qXAxoPLw8zAyKNvHSe1X8076YWF14/ m3jZJu/Cy9VV7Pa9XvAybYUTbKO8OHi5znQJGpEXtzcvMfe+2+sreZFhDS/fomZeevu8fP1Z3eGl rvB6BC/lzEZe/B68+GPn8FLOhJcHyebfbvLy9Wd11+RdV/LiXUKJ5bwrYxMvG+XdX3jx2/LSskd4 2Z0XDy93M3/n5fi1h5fpvb6SF4mvD7yEWTe8WFcTL909Pil4mSm3YJP78LKF4OUys42XT+9wseDl MvM4M3Jefr7d89Leq2+FE2zjrp4/aHez9YKXyS54ucyEl4oLXi4z4aXiMsNL+lbrzts6Le8qeNlC ZvJuwouL3+Flskzx4sJt9fDyktzbO156vjjOl5dlnZcjyoREoxkPLuTTzc+frtva5wOj6/K5Retz 5/IWKJwnM86X9P3owkuYten7kfoSSzfW2wdeXnYZ4cWFPm4qLw5eSpcNXk7up/Diu3jZQ2/veO3z 6Ljb522Fl9mywstod3jRCV7KmfBSE7yUM8m7NZeRvDvcvY+Xvl7jLnh5R1N5cTkv/b3GXfDyjuBl tgteypmPeTfnZeYyv0jk3XLmhRcHL1HwUs6El5rgpZyZ8hJfi+BFtD0vrpyZ5t0WXsi7E3rBy/gK 59ngZbw7vDS54KWcCS81F7yUM8m7NZF3y5nwUhO8lDPhpSZ4KWdWePn/SX9lk4KXcmYl71Z5Ie9O 6AUv4yucZ4OX8e7w0uSCl3ImvNRc8FLOJO/WRN4tZ8JLTVZ4+enzc0vPQdcdXppkiRdhJgzK7vDS JHiRSt7VuazkXXhZ4zLFi0CT8lIkGs2YAXL9WvG19fnAWF3/4+gWrS/+eRfoQOV/vxnnS3amcL50 XOIbzpek5QgvycOogZc9ZCPvOnhZJBu8hOjip+RdeHmWEV58GevU3eGlSVZ46e7+kHfbeSHvTugF L+MrnGeDl/Hu8NLkghep8KJzwYtU8q5O5F2p8KITvEiFF53gRSq86AQvUsm7Ohd5V+qVFw8vNy54 kQovOhe8SIUXnQtepF7zbisve4i8KxVedIIXqfCiE7xIhRed4EUqeVfnIu9KhRedC16kPvPi4KXn Envz4uGl8RIb8eK7eNlD5F2p8KITvEjV8tJwZZOCF6nwopMVXn76/NzSc9B1b8y7ue16oa51r7KR d7M+wkwYlN3hpckFL1LhReeCF6kPvHh42YqXItFoxtu8m0h7HcbGMf55FyhpP3y+JOt/PF921dt/ gG98HsHLs2zw4uBlkWzwIvd7Zd59ulDzwrtc5N1RpfEpxiZ4me2ywkt3d3hpcsGLVHjRueBFKnlX JyN5t787vDQJXqTCi07wIhVedIIXqeRdnYu8KxVedC54kQovOhe8SIUXnQtepJJ3dSLvSoUXneBF KrzoBC9S4UUneJFK3tW5yLtS4UXnghep8KJzwYtUeNG54EUqeVcn8q5UeNEJXqTCi07wIhVedIIX qeRdnYu8KxVedC4TvBw3U27uOei6w0uTywQv4aZLccVPVFZ40bls8JIwAi+vuozwIm818gFeXnRZ 4eV/oxte0LdpFS8RlIQXhJ4EL6hF8IKUykGBF/SLjqCUDwghhBBCCCGEEEIIIYQQQgghhBBCCCGE EEIIIYQQQgghhBBCCCH0ef0TYADyCx1ZCmVuZHN0cmVhbQ1lbmRvYmoNMjIgMCBvYmoNPDwgL1R5 cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1NjAgL0hlaWdodCA0MjAgL0JpdHNQ ZXJDb21wb25lbnQgOCANL0NvbG9yU3BhY2UgMzMgMCBSIC9MZW5ndGggMzkyMiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PiANc3RyZWFtDQpIieyX7WKkIAxF8/4vzW6VLx2dMRBCIvf8qG13bhPxLMQQ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAK1PL5vy/0H1aQeIn0+ZZa bd2F1mJtq6hzY9I0+RIqb4ZXaq7FkbN8nl+s/fPjb0ycrpXhhfseAn+ROupxoq0bZ0ut1oQcir6o 1uorx/0/3/P5NXyxvW13VGs6Ixo/v9B5xNyEu6q11OIm8ucbihH7YG6u1bbsgnTtL0rVGhdIrVi7 Lw2lptJ8p42d9xxIhouxN6T2/3WzhWm907an0faKy18k1WIr+dI+srJP0o7Pt53zasU0p8DpAwwA P4GkgAH3eAdrA18AB/gCOFS+EPDGXF/a/4DplIMWVW+sC/jiNwVfhqQctAhfDKUctOjHl1DGJvsL BF9EYkLMrQ74wBfAwaMv9lMOWlzoPLKfctAifDGUctAifDGUctDiQr6AecAXwAG+AA7wBXDw6Iv9 lIMWF5p37acctAhfDKUctAhfDKUctLiQL2Ae8AVwgC+AA3wBHDz6Yj/loMWF5l37KQctwhdDKQct whdDKQctLuQLmAd8ARzgC+Cg+cRoY7/qVwcSqD4xKl+rbxv/jOWUgxZdzLt0/OJggeCLSKwVCvDF c0p9gqCjL3GUSRPNsysxP99aR/1KTTlS6i+Nn7pQ//4C5gFfAAf4AjhoPrEoCnxxjOoTO02dHl4I 8H4kEhPC/gLBF5GYEPYXCL6IxISwv0DwRSQmBOZdb8AXwAG+AA7wBXDw6Iv9lIMWF5p37acctAhf DKUctAhfDKUctLiQL8//POZpaV7tC4wR5+W+wBhhXu8LjBHFoy/s1GaMg7HQfurdvpQP/jfGwbLa T73bl/ooajyV4ItITIjxt1o0oSZj4ItITAiN6v17DCi83xcYI8kKvhzqwJguXu3L9b4CYzrw6Ev3 +xHDGMy7IrFm/upRflWZ9n702Bj4IhJrhmJJ6qjOS1VuNhgDX0RibbU2tH1JalRl618L1+qK2U/p 7i8ks780FU7f0eWvwUMm+xJHmTTRaFyJdOu95poWTxGatL8EiVclELS35Im+wBgRlBeL9N+PqlRt zMO/h3lXJNbKXF/uBt8vfxC+iMSaqafbGQt0fSjd/0X4IhITYsYCXWpy+yfhi0hMiDnVizFX34Fv rOjLjTFzWnHGmr5cDr4Q5gGr+nI1xkCY33j0RSj1SBjMuyIxIeYu0OfscvGZploOnjx8aUh9CnP+ FHwRiQkxfYHoQxTafuh9a5p+Y4NSLn0Z00Ixh0w0ZpPlfTnuLOW3EzrxAHy5nnZtdGYP+BIgDAOP vsinLoShnlpmbkw6BV+O/1hejOKv4ItITAg7C3SYeqtXJPgiEhPC0gKVLSbKQu21TN2YZMqlL4Og 0w+mmrMCfCmcX49sdWcD+FJxEqZrgnkp8KWGjt/us++sZkzi0ZeBqWJHnHYb5xhzNyaUgi+3H9s3 GPgiEhPC4gLRRtpg4ItIrLHY9iDSpbm6Qiq/HsEXkVh7LcrPQbk6j9oTu13qA1+uyRtMaN5jXgl8 uYFKj5SaBrq+5FeO/CxOE42xaxx9aXYfNq7pRUCNrWTo319UUmUzpHQ4Mf6C4RvrSumfR158CXkz TDsi51CyfGM9Kfjy/fN02FaevzFZvrGelMt5VymV+qTDr6ruJYs5SenO/afp1vT70fVuQlcWrcTc 27a96FSu+ds4/HJmmVcBX+5JZybtc0z5Cb4sWf0nWY2yw+Q3JuOtj8KjL3qpZAcdp5m/33z/c9Zv zMe8K1Rd35fte6q2GKr3HKFiHlLw5Ueo+JL/BJ3PKKliDlLw5XeKzj8RfJmEj6HxIMzFDLwS8OU3 lRlUhNnH4OPH3g98+Q2FogZ8Wbf6U+qzpz6Q4vflYwvg0Rf1FNFRizy+UH55Ok0zTm5MLSaE/QWi 8oWqLSb+QPFd6XxmebkxtZgQ9heo+JKv5SyidC7BFx3sL9DVSBs1Kd9U00z8lLcbGx0TwtuISKHW JJ5KtS9UPvVO4AuL8npEVB1ARKEcTfDlpdUboEqY4kscfPcvBF9eWr2FG1/SHkN5q3kpHn2ZmYq7 x2nCDR++NFWzvxzwhZ3KvoTqG/iigv0Fukjte0vly35CZVniNzNbHJaCL/xUOYuovBSlV6aQd5m0 AzFK218Ol77MhijNMZQ3mDzn5h0mqrLJNLlhQVRvJe7TZbt2upC1L/X0eziadq3gS2ctqrdovwuZ D6LthzK3hHQ0ZV/I821+AF9aObwElTn3OPTCl95aAr7YSB18OewxJ3HSOaXfonxqti+niebZlZif b63z40rHPq58qX9dtXH3d3/9+00fwvd1f7/pRy3S4w5v2F/2f81bx4cf9c8Pb9fOjUnH2mu95jza /5WOL0WVLAG+dPKuefcPyq9J2YvjtlK28e1Ds/vtB770sKsSJ4joS6BiyGGb8X+7QfkWqrFuQvUB ZF/ibnLhS9lvnr8nGWbuDbhfvp3sS/zvcHh/gi+zq9tLVXaEypPjm1L81KQWZVLwRSp192pUj7z7 ADytRYEUfJFK0WlcKaaE88+3BUzemEhMCPsL1OdLfQ5Vg0w5lgi++KkuSvQl1MfPnS9xk9n/cXbj POCLENu2EW6GmN2mUPuSZ5vZjfOAL0Jc+RKO2hw3Hvjirboo2ZdQ/DgMNGdfqnHGER59MZlKvoTi C518OX9z9qXRHcy7XlPJl3Blxs3b0/6+tMfN3lh3TAj7CyTny60wAb6MrW42lR/7pSLXFtXWmL2x 7pgQzoa9Z5xH27Mn977M7vwB8EWc6Eu9yRxm33BpzBa0vx7wRZ5tjPniy80GU3YZw8sCX+S59qUc UrdvSnH3CYZPJ4++WE/tbuwPvtamHmruX5fYvmDedZ6KJ8qdL/X5c3cycSrDF+epMoEcfXnKPvjC F6nq9lO1L6GyAL70YXOmk+Pgy2NhUmx291fAl6Fsg0jcWm43mvMvQvwyu/kr4MtQytz7xZdbfww6 o9XQVmffltNFsfo0Lubejxelr75YWyFNX3Zn0qW9uv1UjuVr7QtzkBnTovF5d3FftkMptPnyyxn4 8uBv2U7d+BKYvqRPf+9jJV/2FckTzbMrMT/fWkf4epp7n1qTzrLqNi7/7vj+c3kFJPcXpzA3ltqX 6mCavGTwRY12XypxZi+ZTnmCLxvw5WkZ+PIH05BPX2j2kmmeR/XY1lPdfuoudqHDxS9utEq+0Gno tHBjSth/8sLL+kWHn77QwRf6WautwzExIew/+SG+/DDm+z/Dl/elvvgS0oncw/4nulpcyBf/9PpC 4WOK0ep8RlEj1SdCD8YY+GKs+kzgi7/qU+nz5WPq1VpJj77YTz2IUTyTerSJ29RfNXafC8279lMP fek9luLgDF+8p575EkLIz/ygAdMXgi/OU49iFL98KPPcl+q7ER3KxYRYeN6d7UtP09NY2peN5Eu4 1OAxcSXHryd8mQtdbzHwxWB1C2Rf+oSBL65Tz2PFly5h+L4sNO/aT6n7QnEIGtChSEwI+09eZ1kF fKl2mREddsaEsP/kNX0JLW9G8GVV+n0hzLsLkX3psWZ8kzOBLwdom1nhi9HqBun0ZfyCevTFfqq5 GAUtXxaad+2neorR5kyzMWM7VPPlr066o3Jf9p+8vi/7N/AlFzt/2/a3TKckfGlTZnCHur5UqvT4 8n6o2o85srzn/ag6gODLT1p8CRqvR9q+bC8A5ee0haadFNf62uDLyH5iGR3qo7n8jP3lmvy/iefM C/cXCV/sp2SKsX3h/O83Pe8SfGlINfjylvcjqgZd+PI0xR9i3uJLqMencl/2n/xcX7Yv2zbz1JvB HU6eODHv/ib78kCZ8QsKX6yTPIAvs6s7oZzekudRazOjCxiu7gT40lndfkq2WPr1g+MI867L1CBf fhnDKQtfDKXGFPvuS4AvblNDfbk/mOALqPjpy/hxF7444m+1dl/udxiNHuYBX7hsSnwZZIbXH13A cHWPwJc3pgYWo/iVrqRh1F1o3rWfGu7Ldv00Br74TCkU2305vSvBF58pHV8CfAEs6KTM+AWFL55J voT0cgRfwE92X/4uCrUUalit/hYo7TEatRRqSFe3n9JtcROF68tC8679FHwZg/0n78aXAF/8pua0 +CZfqLpS+h+BeVeUN827lS9UfoYvkrzNF9qAL6N4my9xc4Evg1jAlzjKpInm2ZWYn2+to36lphwp 9Ue5PQXSfiKxv9hPOWjRxfsRfHGeUvKFUh2CL65TWvsLSfoC5qF7Hu3XMjbBF2/MfWLwxRvwBXDw 6Iv9lIMWbc+7otXtpxy0CF8MpRy0CF8MpRy0uJAvYB7wBXCAL4ADfAEcPPpiP+WgxYXmXfspBy3C F0MpBy3CF0MpBy0u5AuYB3wBHOAL4ABfAAePvthPOWhxoXnXfspBi/DFUMpBi/DFUMpBiwv5AuYB XwAHrSe21aH/lItidSCFpi+7M+miWR1I4dEX+ykHLRqfd+HLK1K6vuzS1L6cJppnV2J+vrWO+pWa cqTUH+X2FIiq7I87YH9xmtI/jwR8AfPQeWIEX16C0hMjyXkXzEPzPKrHOt3qQIq5T8z+gId5VyQm hP0Fgi8iMSHsLxB8EYkJYX+B4ItITAjMu96AL4ADfAEc4Avg4NEX+ykHLS4079pPOWgRvhhKOWgR vhhKOWhxIV/APOAL4ABfAAf4Ajh49MV+ykGLC8279lMOWoQvhlIOWoQvhlIOWlzIFzAP+AI4wBfA Ab4ADlpPbKtD/ymX5ur2Uw5aND7vUqpF6dJe3X7KQYvwxVDKQYvwxVDKQYs+fTlNNLgavlJ6WhpU 5bv3FzAPj+cRmIfOEyP48hKUnhhh3n1FSvU8SuNTGZvsLxB8EYkJYX+B4ItITAj7CwRfRGJCYN71 BnwBHOAL4ABfAAePvthPOWhxoXnXfspBi/DFUMpBi/DFUMpBiwv5AuYBXwAH+AI4wBfAwaMv9lMO Wlxo3rWfctAifDGUctAifDGUctDiQr6AecAXwAG+AA7wBXDw6Iv9lIMW/7FbxzgMwjAARX3/S1OJ RC2gVi0ZUhveG4iEZMjwB99o380/VeCKmXuJVTuX5zH89/xTBa6YuZf+l2iPOLwZ/FrmqQJXTN3L phG9VJ6atr/EopcLTM3bd+NtL1Qzq5dXKJte4BO9cIZe+NE+FL3wRV+U9gcAAAAAAAAAAAAAAAAA AMD/PQQYAMe2L78KZW5kc3RyZWFtDWVuZG9iag0yMyAwIG9iag08PCAvVHlwZSAvWE9iamVjdCAv U3VidHlwZSAvSW1hZ2UgL1dpZHRoIDU2MCAvSGVpZ2h0IDQyMCAvQml0c1BlckNvbXBvbmVudCA4 IA0vQ29sb3JTcGFjZSAzMyAwIFIgL0xlbmd0aCAzMzMxIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+ IA1zdHJlYW0NCkiJ7JcBduM2DAVx/0urWZuUFCduDAoCP6SZ1652W/8ApGZJeFkAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAACAFG/n8v1/sC1fQfIn++ZFaY90to8XGdjFnYdEM+bLsvDm9 0nAtj5zb5/3Fxj9//sLCObQzvvCxl+DfpAP1PNHRg3Ok1mgijkRfUmsdK+f9O3/k8/fwRfvYPlBt 6I4Y/PyN7iPnIXyo2kgtb2L9/EAxc1/Mw7XGtj2QQ+dLUrXBDUorNu7LQKmpDK90sPMjF5JwMfeB NP63brYwoysdextjX3H9m5Ra7E6+jI+s7pv0wOfH7vm0YplT4PQBBuBPkBQceK93uDf4Ah7wBTzs fDGoxlxfxn+AdKpAi6kLOwS+1E3hyympAi3ii1CqQIt1fFm2sUl/g/AlJBbE3OrgB1/AQ0Vf9FMF WrzRfaSfKtAivgilCrSIL0KpAi3eyBeYB76AB3wBD/gCHir6op8q0OKN5l39VIEW8UUoVaBFfBFK FWjxRr7APPAFPOALeMAX8FDRF/1UgRZvNO/qpwq0iC9CqQIt4otQqkCLN/IF5oEv4AFfwEPmG7MH z2d+dYgg9Y3Z9uvut4M/RjlVoMUS8659/6XABuFLSGwUW/Clcip9grDvvrRRpk80nz3N+fnROulP G8pZUn99/MzFjp8vMA98AQ/4Ah4y31gTBV8Kk/rGXqbOCl8I+H4UEgtCf4PwJSQWhP4G4UtILAj9 DcKXkFgQzLvVwBfwgC/gAV/AQ0Vf9FMFWrzRvKufKtAivgilCrSIL0KpAi3eyBeYB76AB3wBD/gC Hir6op8q0OKN5l39VIEW8UUoVaBFfBFKFWjxRr7APPAFPOALeMAX8FDRF/1UgRaLzLv/6tkXR6rr pwq0WMcX2+rqbxC+hMTGaj3Al8Kp3PPFYs4XmMdkX9oo0ycansJP628rD+N8KQ6+gIfkN2Z8Pyqd wpdTUgVarOHLsp9uK2wQvoTEgtDfIHwJiQXBvFsNfAEP+AIe8AU8VPRFP1WgxRvNu/qpAi3ii1Cq QIv4IpQq0OKNfIF54At4wBfwgC971PrRo6IvJ6Z+fIh5NyQWhN4G2cvH8CUkFoTaBtmPz+FLSCwI uQ36IQy+hMSCUJsv7XEfqXWlBL5842nL6xADK/jynS9Vfg4xsIIvryDM/1HRl5NT34YY5t2QWBCa G7QfYvAlJBaE6Aa14+XAvSS6sMOpXF/MHn9p22O4+vmpberFl5DYeC3rj+zqPtoQo9vgJPDlDXbo Pros+PIOhPmNVF+e+7/35WWikXqaeH/p+9F3I4tHyeX4+ZKVas2O7JH2wsZT+fdRIV/61Dui2kCx Cil8+SNkY0OM/MLK+BIw7yan1js0o5h4Knf8f5keS3z5ODDEXJG521DiJbTjpUSvp4Mvf4MwG/jy AYNDzBWp6Et+qh0vnw8xVRaWFQtCf4P6YO68k8osLCkWhP4G2e43DmEKLSwlFoT+Btn+d/bxnVRp YRmxIEpNkLa4jphrgi+fgzCz115s5811J10SfHFx+yOmoi8zUx8KU29h58aC0N+gH6nP7qSCCzs1 FoT+Bv2S+uSIKbmwE2NB6G/Qb6kPhJnd4lmpkr5M58bfk/BliNt+T8KXMVZh6i5hCHwZZL2PCq9h gIq+iKT+74gRaTE8hS8HUqssPz+k0mJ0Cl+OpOztESPTYnAKX46l3h0xQi2Gpkr6osT7I+aapK7S 7Lm91jf3Cnu8fVG6wmr+InON9vzFtrrX2OHNmNmdnA++RNCNuf4RU9EXxVS/kOxqC4uJjdf67svL RPPZ05yfH60z9vP//W7w59hQzs5d11ZnbS+L/rqX650vy37oHd1W/dTs82X85yim2t/FnGJTUiV9 0cVWY662sg6+xGJ9dddb2oMJ88uyjU1X3NR+H11xbbNXddE9fdqS+10iiYq+FEg9b12vMfoLw5dT Uut95DOmxsImor9Bo9u63kceYyosbCwWhP4GDW/rdh99/iNKLGwmV5wIO9vpcqXBF19OY3cfXWed +HIi2310mYXiy6ms99FVVlrRF/3ULtbvI/tgjCm1sBnob1DAtq7C/PnDii0sH/0NitjW9T7Cl4Po b1DMtvb76I+fVm9hyVxlCvyTdh/VXy++5NDuo/LG4EsS/T4qbgy+ZLG6UnrRFX3RT72Jtfvo7RFT dmFZ6G9Q7Lb2M8Z+V6buwpLQ36BwX/r/s18+VHdhSehvUPC22rL5Yrs/HSkmsbAcSo9+I/TbyFZZ im0BviTTJxdr/7wdfjXBl3T295G9mXxlyer2OenZeh7nVtfCrP3zFObxn2b39CmZvrSd+f4lYfBn aaf+ilm/l57mbH86oVZoCl9OSX0Qs3bO2Db9XmNhMeDLj4/0+6iZM1xMbWEhvPHlZaL57GnOz4/W Ofdp63Ndjw39PEvq29b2Eog8Xy5Eew3rUx58mUtXZWkHzOx+/iKnQcOXN7Sd6WeL/IYkNWj48pY+ 8PbJV5rM+2g/1h2prp9yxTZRnrPvmbWOpib/Ddd/8xm+9H+W9u3PWVV2YfHov/m0bX1q0oZelzPi C4tE/83nbetufrF+4JxVazhV0pdr0i+kPulpbg6+SLHdR/giV12R3X0kuTn4osV6H4keMBV90U8d Kda+G9lzAP7gBxVYWBT6bz7flza/tJvJvv2v8FpZsSD03/wEX/bzS7+e8OVAdf3U4WKPq6gZ0/74 9mcWWFgUihOdCNZm3peTZjb4IkubX6zfSKawW/iii62a2HrMzAZfdNm+IT0vJwVhKvqin4oqtnnS xpl26JxR69RYEPpvfq4vy2bLv9+0WwlfrpYKLNYupfbrU5uzap0XC0L/zUv40kaY7sqLMQUWFoXA AKeO9e9F1oaZ1Zcpm4cv6qyHSbuMrE8w+AK/sO3RNr+Y/TL3JnczA3z5m90ebfPLwxZ8uUrqpGJ9 fulfms6sFRsLQv/NS/myzi/9G9PjjCmwsLE662Jtxl+NAtv6gS+Lrf8uO3dOqBUaG6tjv/527GdJ p07zpW1em2Oep8vYIFPBl50qR3y5L6sabX6xdabJ6yC1ji34EsF+fkn9ppTsyzqfNV923xAXnq6n 9XnQkur28TMF237D+XKcH/NL+nvMqhPgi37q9GL9eN4d0afVioi5q+DLCalt4l3cQ6+0L8v2VwBf 4lLPo+V5yJxd61hsrM7LdFvhzUv7cmR+EfdFsXp92m00Mr+MV5wIvkQwNL8M15oJvsQwML+MVkqq o1j9SuBL5dSEFt3frYZq4cspqRm+OMP4IpQq0CK+CKUKtHgjX2Ae+AIe8AU84At4qOiLfqpAizea d/VTBVrEF6FUgRbxRShVoMUb+QLzwBfwgC/gAV/AQ0Vf9FMFWrzRvKufKtAivgilCrSIL0KpAi2K +2K7p32RWx2imOCLbX/Gl2pk+mIP8KUyqeeLcb5UZ7IvbZTpE81nT3N+frRO+tOGcpbUn63tJdDP k4jzRT9VoMUS34/wpXgqyRfrdQxfSqeyzheL9AXmkXsfPZ/b2IQv1Zj7xvClGvgCHir6op8q0KL2 vBtaXT9VoEV8EUoVaBFfhFIFWryRLzAPfAEP+AIe8AU8VPRFP1WgxRvNu/qpAi3ii1CqQIv4IpQq 0OKNfIF54At4wBfwgC/goaIv+qkCLd5o3tVPFWgRX4RSBVrEF6FUgRZv5AvMA1/AQ9Ybe9SxL7ZH YnWIItOXpzP9kVkdoqjoi36qQIvi8y6+XCKV68tTmr0vLxPNZ09zfn60TvrThnKW1J+t7SXQVHm+ 7oXzpWgq/z4K8AXmkfPGDF8uQtIbs8h5F+aReR/tx7rc6hDF3DemP+Ax74bEgtDfIHwJiQWhv0H4 EhILQn+D8CUkFgTzbjXwBTzgC3jAF/BQ0Rf9VIEWbzTv6qcKtIgvQqkCLeKLUKpAizfyBeaBL+AB X8ADvoCHir7opwq0eKN5Vz9VoEV8EUoVaBFfhFIFWryRLzAPfAEP+AIe8AU8ZL2xRx37YnsMV9dP FWhRfN61Xsv6Y7y6fqpAi/gilCrQIr4IpQq0WNOXl4mGp/DT+tvKYFf+8PkC86h4H8E8ct6Y4ctF SHpjxrx7iVTqfdTHp21s0t8gfAmJBaG/QfgSEgtCf4PwJSQWBPNuNfAFPOALeMAX8FDRF/1UgRZv NO/qpwq0iC9CqQIt4otQqkCLN/IF5oEv4AFfwAO+gIeKvuinCrR4o3lXP1WgRXwRShVoEV+EUgVa vJEvMA98AQ/4Ah7wBTxU9EU/VaDFG827+qkCLSr7Yg+ez2V9DFfXTxVoUdmXVsWev9jLfxn8acqp Ai1K+7JzBF8qp9LmF1vw5QKpvHnXfvUFqpHlyybKzheAd+ALeMAX+JDvouAL/EEblL4/AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA5vOfAAMA2gmfPgplbmRzdHJlYW0NZW5kb2JqDTI0IDAg b2JqDTw8IC9UeXBlIC9YT2JqZWN0IC9TdWJ0eXBlIC9JbWFnZSAvV2lkdGggNTYwIC9IZWlnaHQg NDIwIC9CaXRzUGVyQ29tcG9uZW50IDggDS9Db2xvclNwYWNlIDMzIDAgUiAvTGVuZ3RoIDI4MTAg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSInsl9Fi2zgMBPH/P+1LbCtyfElqUDC4 K848RO2dNwDJKQVfLgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0EKMfP7zR3yQCkYu sX1+pNZYd5fRYmO72LOwaoZ8uTx48/ZKw7Uycu6fzxcb//z7F1bOoZ3JhY8dQn6TDtTLREcvzpFa o4k6Gn1prXWsXPbf/JHPr+GL9rV9oNrQO2Lw8wu9j5KX8KFqI7Wyia/PDxSL9It5uNbYthdy6H5p qja4QW3Fxn0ZKDWV4ZUOdn7khSRcLH0hjf+rmy3M6ErHTmPsK25+k1qLreTL+MiafpMe+PzYe76t WOcUOH2AAfgnSAoJsq93WBt8gQz4AhkefAlwY64v479AOmXQYuvCDoEvvil8eUvKoEV8EUoZtOjj y2Ufm/Q3CF9KYkXMrQ558AUyOPqinzJocaH3kX7KoEV8EUoZtIgvQimDFhfyBeaBL5ABXyADvkAG R1/0UwYtLjTv6qcMWsQXoZRBi/gilDJocSFfYB74AhnwBTLgC2Rw9EU/ZdDiQvOufsqgRXwRShm0 iC9CKYMWF/IF5oEvkAFfIEPnicWV27O/OlTQemKx/3z44+CvUU4ZtGgx78b3HwYbhC8lsVHigi/O qfYJIr77ch9ltonmtWckPz9ap/0ZQ7lo6m8bP3uJ4/cLzANfIAO+QIbOE7uLgi/GtJ7Y09Tp8IWA 70clsSL0NwhfSmJF6G8QvpTEitDfIHwpiRXBvOsGvkAGfIEM+AIZHH3RTxm0uNC8q58yaBFfhFIG LeKLUMqgxYV8gXngC2TAF8iAL5DB0Rf9lEGLC827+imDFvFFKGXQIr4IpQxaXMgXmAe+QAZ8gQz4 AhkcfdFPGbRoMu9+1osPjlTXTxm06ONL7HX1NwhfSmJjta7gi3Gq936JmvsF5jHZl/sos000PIWf sZ1WH8H9Yg6+QIbmEwu+H1mn8OUtKYMWPXy5PE63DhuELyWxIvQ3CF9KYkUw77qBL5ABXyADvkAG R1/0UwYtLjTv6qcMWsQXoZRBi/gilDJocSFfYB74AhnwBTLgC2Rw9EU/ZdDiQvOufsqgRXwRShm0 iC9CKYMWF/IF5oEvkAFfIAO+QAZHX/RTBi0uNO/qpwxaxBehlEGLDr7EB/tjuLp+yqBFA1/i9iP2 usy7buALZMAXyNDqy3V4+ebL00TDU/gZ22l1cS15OX6/6KcMWnSZd/HFOYUvb0kZtOjiS8G8q58y aNHAl2182scmvh+5MffE8MUNfIEM+AIZHH3RTxm06DDvFlXXTxm0iC9CKYMW8UUoZdDiQr7APPAF MuALZMAXyODoi37KoMWF5l39lEGL+CKUMmgRX4RSBi0u5AvMA18gA75ABnyBDI6+6KcMWlxo3tVP GbSIL0IpgxbxRShl0OJCvsA8Wk8sPtgf3dWhgM4Ti9uP2OueypdTLeY38KWMr1vzzDj6opp6EEa1 xaOp2b48TTSvPSP5+dE67c8YykVTf/HVXhfbcV/Oeb9cHja4o9iE1Oz7Zfz3qKbuN0VPsfaUpS/a fF7cs3t4H/hSTvdbvpUJ88vDhp50X098xcxd12l39bRXjKMv+qlLDF0xDgsbixWhv0HD2zpyxVgs bCb6G3RgW/NXjMnC5qG/QUe2NbJ3jMvCpnHSofCL831Rwpe3kr5i1MGXN3OyKwZf3s31q9LsJspw 9EU/9S0WL18xZgvrR3+DSrb11SvGbmHd6G9Qzba+eMX4LawZ/Q2q2taXrhjHhbVynjnwn8Q55l58 aeMUwuBLH2e4YvClE39hHH3RT/0ai8tfxhgvrAf9Dare1j/fSc4La0F/g+q39Y8rxnthDehv0Bu2 9XbF/PQJ84W9H+/Zb5i/pxhp8GUGYWsMvszh95eSNl0dX+vcd2jfKL/9qiMujsZ0+nJzZnuMV9dP vRT7/0vpJAurAF9++tSTMadZ2HHw5efPfRtjTrSwo/ziy9NE89ozkp8frdP1jMf28vlo6vOrzQ4q 75dz8f8xRhl8mc/3l5I2PV0GvvyJzxXT1GTgy5/YvJQ630fbrbtfvvpfCNq+RtxeSj21xlOT/4Xr n3zjto5OMfILq0P/5Du3dXDu1V9YGfon37qtY1OMwcKqMBjwepGfe/FFjPG5twV8kUP6isEXPZSv GEdf9FNHi12NaarVEitC/+Tn+PL5x5evGIOFVaF/8rN8+dTlRWMMFlaF/slP8+V1YwwWVoXoUKfC 9aWktUf4okzIGYMv2qgZgy/qaBnj6It+qrbYP4wxWFgV+iev4Mv1f3w601LrLbEi9E9ew5frFXP5 xRiDhVWhf/Iivlzub6SfjDFYWBUqU5wFvxvT2cTC1e2IqzJTjcEXK+7GTGxgXunp1T2JmzOzqs8q fKC6fuq9xZ6EMVhYFfonr+jLNvr21CqJDdXZbtJ9tfonr+nLN2MMFjZYJ37849jvkk41FFvBlwdV jvgCn8yZeXt9ub2W9r/jixvNvnw+H325v4a3tzFP4ec2frYQ+x+4X4xx9EU/ZdCi9Lwb+HKOVNf9 Eg+DLr74pnrfR0/TrcMG4UtJrAjmXTfwBTLgC2TAF8jg6It+yqDFheZd/ZRBi/gilDJoEV+EUgYt LuQLzANfIAO+QAZ8gQyOvuinDFpcaN7VTxm0iC9CKYMW8UUoZdDiQr7APPAFMuALZMAXyODoi37K oMWF5l39lEGL+CKUMmgRX4RSBi2K+xIPz/igtzpUMcGX2P+OL250+hJX8MWZ1vsluF/cmezLfZTZ JprXnpH8/Gid9mcM5aKpv/hqr4HtPqm4X/RTBi1afD/CF/NUky+x1Ql8sU513S9R6QvMo/d9dHvu YxO+uDH3xPDFDXyBDI6+6KcMWtSed0ur66cMWsQXoZRBi/gilDJocSFfYB74AhnwBTLgC2Rw9EU/ ZdDiQvOufsqgRXwRShm0iC9CKYMWF/IF5oEvkAFfIAO+QAZHX/RTBi0uNO/qpwxaxBehlEGL+CKU MmhxIV9gHvgCGbpO7FonPtgfjdWhik5fbs5sj87qUIWjL/opgxbF5118OUWq15ebNI++PE00rz0j +fnROu3PGMpFU3/x1V4Dd1Vux33hfjFN9b+PCnyBefScWODLSWg6saicd2Eene+jx7GutzpUMffE 9Ac85t2SWBH6G4QvJbEi9DcIX0piRehvEL6UxIpg3nUDXyADvkAGfIEMjr7opwxaXGje1U8ZtIgv QimDFvFFKGXQ4kK+wDzwBTLgC2TAF8jg6It+yqDFheZd/ZRBi/gilDJoEV+EUgYtLuQLzANfIAO+ QAZ8gQxdJ3atEx/sj+Hq+imDFsXn3dhqxfYYr66fMmgRX4RSBi3ii1DKoEVPX54mGp7Cz9hOq4OH 8ofvF5iH4/sI5tFzYoEvJ6HpxIJ59xSp1vfRNj7tY5P+BuFLSawI/Q3Cl5JYEfobhC8lsSKYd93A F8iAL5ABXyCDoy/6KYMWF5p39VMGLeKLUMqgRXwRShm0uJAvMA98gQz4AhnwBTI4+qKfMmhxoXlX P2XQIr4IpQxaxBehlEGLC/kC88AXyIAvkAFfIIOjL/opgxYXmnf1UwYtKvsSV27Py9djuLp+yqBF ZV/uVeL2I57+y+BvU04ZtCjty4Mj+OKcaptf4oIvJ0j1zbvxoy/gRpcvuygPvgD8Br5ABnyBF/ku Cr7AP7gPSt8fAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8/lPgAEABjJpkAplbmRzdHJl YW0NZW5kb2JqDTI1IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCA1NSAwIFIgDS9SZXNv dXJjZXMgMjYgMCBSIA0vQ29udGVudHMgMjcgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNTk1IDg0MiBd IA0vQ3JvcEJveCBbIDAgMCA1OTUgODQyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0yNiAwIG9i ag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9UVDEgNjMgMCBSIC9UVDIg NjcgMCBSIC9UVDMgNzAgMCBSIC9UVDcgMzYgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgODcg MCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M2IDYyIDAgUiA+PiANPj4gDWVuZG9iag0yNyAwIG9i ag08PCAvTGVuZ3RoIDY5ODggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImsV8uO XLcR3fdX3HWAuSKLb2DQi8hBAAPJRrMzvOhuaYIYmmy00O/7FFl83juKDRhCa7rJYr0fpz58/Oa3 j582lf99+vjvi95+3vT226Z2G7fvm1bbv7ZfflXb58uHf37S23++geK/2yXFnWizNu06bm8XnfQe 6s+vF/Jhj3azgXZlcU34ktpv3Aez3Kfd++Heu91E8NN7zNdZm/ITtzrtyXfhFNXuqUv/dPn7y+XD ywvBkJfXi999to7/UtC7hWCTdorabi9vlw/sgsc3ccG3x/8uant58H/fL89KaXd9+e3y5KC/c9sT 7dFZt738lO8s3+k9bbTbelboaXcwEuc6QqeR/Cnsxni7PemdVNLzs7CT3Flv/HQHg0wxSONlzNqW b+wtD/cY/LKK2Ci8cvfMUe0uQGElvJzOp4hWIt9PM63ZdcBzAjOV6s2jcUlxoT+cVt6eyPTTyiF4 tUp88rumENityUc935ndKWfWF9A8eL/I9HtU0W0zl4cEQhmdVi4cRq2P9gSKYdUcSUdHD5pdeaQo bo11Qe6sLdoMCUfINKQm7UGVfOss1G4SHA1WJlBjkYUiBpwbU4rYR1Md6vgdYbWzTj9gaPbEiXXG EBboSM2+eioqIETUU7hqp99jFjmgZknu//vKlDM0Bcn6BJ2M5jrMRJUQ+R5nHqrRSJn6XKZ/Trzd I/tr9cBOR7+gCsM7Veg0N6+lCrXiV4pZ6bmyyg1k25hsySNV40lKQl3vvG3d4B4zxw3RTijteprK KUiVrubdQ+1FzhA/GNjcTtncztjcgmSXT9plNlyzkxUKVRZoLkC5crsiFOyZgdrvSVyYvxEhEqgW iiI+u/DmRQRZFBzqv/tQruyuggosIgUd5jvaDcXeLxozS8pt/QHKWYOsJNPNV0JEQCXpHqrdHos8 5oFEYGtAXvSm6hrPeWd318uoXP3j5aIVeqjfjMvzEHPUW56r8ruPstr5qXgLkw19BSPRYCTiz9hW OM+5FYJobZy9DZZGxWNm7XYW/nIlWpU2j5+AMGbh+Yu2Fr1yM5jb8E869jXON7QhH9xShBgCMReh W4owoKEhO6G4p5O+9i5DBDCdMRwqVXIMcq3a0WbgZJXsnF6Q63xY8uRoNPvcAZwkr+cwOwz81B0s CT7EKzBGMR6JjiBP3QF2hTC5vLzuEGbVI3C6sR7WNecLulj0KKecaZorB1jBsw3INILF9efXC3IG A224dooRWb9PjsFVuyetWId2HzGtUf9eM257u0RwY2ribOY01qz4961daK530AEMbZiuFbgJ6uRz DDe5eLukfE4xoYgYAKLVat9/1yo5xBuoFEOXPAa7nuPtWftSv/iSXNbeESs3hrUHkBD8xDRodakF 8K5aF6VUM/P+Wptoqo1qoGsJfP9Syci0s8+lLtF/NaOi1jFOBd3+mKDbiaDbZ5mnuvTNrvy9EPNY WM84RdvZo5yhv7Zxc8vKA8qr3EF4Woi0E6a3E6a3I9NbZhqBHjNlbPJjZWkPkxFWHcZin5RBas4E N5LejgxvR4a3I8MyHhkLZ9xeIxbkWOc5Y/V0zKaEMkuNXKgv0usQS55Pf52d9Nea6d2pnSqd2el2 crOdrbeZup4tlRh4TQOQ832V6WOAkQRMiqEmvADDuNtgC2D2y+5C3OwFqdsZyALcegJymK7aigC5 4fyZLSwXwBjgFIozszJobcU5doA55JDVJtWG03E3qQPvoQ8pnRuzs3nCv3VDebQNAbB1HmhdAjav V4eACT3x1jXR2y8VqOJC8RARPnEeUksgk/TTDoWzAA3ckjTjIaXivOE+sT+om15OhxmqscWgnYcM tEemQ+9naoAniGdnaQ5+xIjxBgnS2rbzFZoO+6WXSclzFVEJ5HeH2WMgztWfXy+WIYTfAjY6xYjN YkbF9pvvE+IQMF093yJMUX7JnBJ7gBVhan3NDT8Wo3jUBYGaaOdKPUQvLBUc8qqXhUm+61Vn4Cli sEg1DLgA50eBaxXNiustbwEmNx4d4xSAM/jJVmaGmuGrOPUuVYoe3ZyqpdtFNRxmQp4PvGccYKqP KykvaHmn5Awca5uTeBuPSxIvxsP7MCko+KDDJSsMTPC8mAWfaK7miGkJNMBLmGpLxQFado8YtMbi ELfgO2hp3Whqg33prDVCovTM0EZ4b7KTueW44x1OkZQtDQu+7UFcM0PzgLDAb7pmBirTSHbYB8cQ f33F6F6FoTeNt4MvkNwAkzb6ncZcQ+0og4w2hI9v46mHG0hNUZhdjIak2RkqazWPEC1RUG2PzN+4 2BFwg53LpFBt4q2xpHzAR5e/rI+J1Qx8+LvDJxR1q4n82z0KPVmh5/vXcu680Pq5KUIhcXf5FuDC nCWlLbJejPEel1/YLhGmzPVJAykbTnR1Rdsj/kZFjAtXmw9GMtbFmfKxr0KAbJUvXijCepOZ6sJY vS48G5HGYWdU2Tv4yoaJDj9ui/5N5L0xiQuJ6NDOAdtN6cjAH/mpEN0G/wjRqOSvLz/nnVanAnl8 yHWbk0fr6uUcWiiDATooYwE5gthab67cDksXkjNYU8SOT5D+Qjiwte2xOTyuSZaZRDQGTspYyWoY 6k1Oq3By5ucz1zg4SWSbxlO78M0pTU3qyL1bno4G5ZTvXK14NB65j17OwXn5mwSDWjBqzWW3U4n6 Uw2tsHlURWg4rdXIKVnMoKa6ey7G589D0vZxkFScyor19hgxK3LFInF635qLGgIqcGiNqZjDClXL jRTmVVwp3aaHjqunkcWuLWs4nDaa/MJmD7HOjBmsDzyhjHG5N7IyNIIHbSuAQMFgpywDbSRXrS7M 7YqhpyWNMUiGTJXozq4CScDzyVVlYI+ustZUGhZnu6sQB6lgDOjnIaFbQ9PTAaona3crn6pX/j1k oQ3DK6OuxXll5pzxy61nfFMyq2m3KIYqLupyV2pZz85yjjO3uo3LZFar9CfGMmTG/pT9Eqpf8ps0 uN6KiYNpOticU+SvrBItxxz5PCkeZX5Q8ZsrXTTXrz+JZwK6/rPxNGM4daDaK4w006bzmjqUgFBm UY8fidLB6bHKOHzov7H4nSXHUv71NJdivFadeJgEN5MgJPUaGipp0RjRLk+l4TJvQc28gUP/ij4/ 0g+cUE7D0zKkALfIhTULsKnVLEg1WHBlTqn6hXudLhrecvHI8TB7rSCGnEJWBnUZ/8KsvRrH//Ay j147jl43PEdHYZj/XGDU+I5eV5WqaLeoNhH5oZptHwrvPKj2Two30+7jtJnxVVOo4aKbPHDdymYx 9XprKVECMxyhv9ic6mN/qXEfcVHHQRVhJqnt1wHOvS/ox8zy3xUbHl5WPMWXAPxSDVRE3gU8RonH KMJmxDyP8Fb5puGIBoySqdXB681z1U26KTqSOscOKZVSatihDsHpdoIMpkEGewoZRiDRGrtwKsDN P4/6d51/DCDMewBC5yXJ/WEEkWe2m6ZiquJdzcu8BKTnE3FYdUxYm7aepT0R4q6wkS3thuxpZcT3 KqNe9l4jOWPHS3dVDYXmqSBjdshpOVL3A/gKzrqzCeR5o+M1Kn/RzgH7bOhre9RlwyuJzmvosnFp FzBIQAvcQ4x23oZW+1zgdhk9iwyPYTqJaMF8/HjH05733lVgWT9zjB/DrkWClgWmjKBC7nLnb2jQ tkI3rd4qE7+0e3fgVdBA20FGqWO/q5Lr2lhXK7WTg+NOp5YgjCKwKNH2EG4fn9lpxItvShsQLRfA KWR1R8hqdx/UgpV42vxOepXkOJIjwa/keYAUuJMBJPSKufVJUpf+/4Th4uYLIzJrqvtQKGWQdDp9 MTdjZaR9pb+1L8VdaEjgjOAQ0/N9XVP24tSMmgUHLzt5rrFeP6qcH7UFMTBUgDcZ4zYE1ng9G+f4 LrD2Gqy1LKN8HzQhREJ63gO4zRSQ5FilQNcKtLIlFpbc84eorrMHPTM0ozTIegZ3rfwE3P0FuMPS AvdkfWFh+zO441VncD9W0iz/paz13RvIHzl4pRMX3sLnMjPWOyLHdpz0AKOFatKhyhA0rvMms9sw AdV7m3AMw7Hmf2zCpktqOdh5TizZOggW+rRUhCNRQfdbaXHD9bJHq7iJv2iIYqVFXJDUx4yeLXXR GHAf0z8KBavd3nsLhKERE3vR4Xug0b7+puuCYzHKV8o822rE3Wpql1PsWtzM2nDNPjffICmj5Lzs HA3N4FhyUhtYl/q0rKX8LLcmSRjEZa/EuGsScPkQ2lJ5Wa7neCYw1W1vuTthrvtiGBVeFWhgBag7 rxD9yutu9MaYCE4jeP8WFztnJG9XCeuDPvqNQ+1DvnvduYmU5xpCIyzjKtjHncw6vTBcS/oNDdiz VUPastXl54mhhC4qOwsKrh/IGwv6np2EmgYfCq7eQlnkJETFP6eFEOuCzoUYozZ65Z1QSvTqfGgD wTgUGVjVovtFp/OkbiE8yRERiWsgs8qDCLzMaLsddQ/gD/lcDZjPCR3NB6XJE8jjq00svnJ6Abq8 v6POcLOT31pb+vgst3q4dI2/B/A3pAnSuaNwnyV9L3Y8sKO/yVOqKc/hI3Z4LqXPjcb0E/xiQLun eIZEgyNSa70kNwwuhH07Xu91FUO8hfBRYqcgTfHsZKmHIh2uFMQLKuM4La+CamrqzSJoX1QeTcGz zLtxvAZMgyjjcVZholc+7VbDIOVzHqVWFntYNPiW/BFOvcATe0IzonaI41MiRfsS+vCmH3lsIZ33 2XoTHsTKPEsq/Ujs2JGZTypSMOche1DuLDyAVnCB873ZCvAC4MwrHnAOE49BszAkpwO/Zuj++5+t JiSXTXIybw8ECsjv0JszOomi03kuRYfq90FXJXprw76yYsTVwhXF2rUoT8a7vbdnY70T2jwvDA/O MLODXMOLx3lzdBSjLg1dLIjKQiCv6aEnv5C+JOlnekVw1wlrb2s1m8DNouOLTtOjt2PnKR/FxZur a3p858VvGr+2WycXnb3dMsONr5rO5D5zjKDcxKHZkynRdTucaYjMMtM0WD688GOkJKGx/G7oNxXD nsAcpmBZhP57ggSOBujsleYXfwGgqgeHHrBGALNYj0iYxJVK51EBqjF5lxBRsdlH+DJJBGRiH6Ku KKMxBG7GHFM1pdlYYT1bt5TD7EBRl05oMTUvyjQnVl6sQnseoddoOmmlF+vBYXIMrGgUpWUniWa2 b3ZvKrZYy/0VfiEabzMXX0pZs6oqYq61vAy/yfCafuxDuPCZSudqjSNBZpcW0w4t+DDgy0IDNT8i ElfiFfbPrgp0nWNqw59nd+hDs3UStZgaRvxNDKrTRAPXH2b7YIIVM7GZL+xD61WWv/QTtAlx0Y/Z Fb62l5m75UeC0f/7qWi//jL71DUvrmefoQlFDailTovJIGBDTduH4sT/ZITqkVgUX4VEYXdggwfd pPZvda1fTX1NjIRYB6XM/NGQZupwBkwwF2akB/2/gaeZKDIaeW11g8wJszYg7NgmOhutA5GhLoCG M/BV/b64kkVPpesbw8w31PHTFsVg5KEbjtQ8oVDogUGJ/BMiRFtk1tuTLzUxYGw09GykCEPq10SX ymg0vz356o6IgFxrCtPtrWCJiDuwWx4AnM5m4+CNUbxmdMVLsa1o8SdWecxg/B7iNSaHJVzQRGjF 6dehKq5I5WGSnsnXVHNWbKZdbA4NJ/yM0+3elJlM3bBpJHznxvyGXvK+3zNHuUvzBpwvQEVHIlat VaIQGPpngThrPN9C6wW917hjRjgb46UvWTMwEtWZZoLv3PI4PnojxpgjQhcqhdj1KPnBS14j1B1O bl0QtI9uZIT6fGmkaorMp8bbKiaqGtWNN73VIz1/feCXNsCH1MYi+Zpm0m5Kk5kqDICOr9SMWEix dXQsrZVVSvOFIVJABmqEeub5KfdRVPp/XS79K56fSkf/YS8Ms4vn1yilvAZKzejRGifD6W9wC3Bp qWehEuS3O57t8W2aefAOMXj8fKoP34XnGd+o2T/9KMia9rEkCmVlHSSCSV6LW5PEdmC2+21y0NI2 GVbmT5qEZcVkJVHbNMKHjAbsuq6IcAvZ5z/An3i4apKW7vHwK2T+Hltd5Vf5p2QwHpGeLvvUadkw iUmQTUf/2ZAp+4Byi6nGPxSvecBD+kjxuIV/VdQ5tNvRuyP1KbaKGvjynrjS77nSfN5qPlCmwYkq FQKRZQa18CXs5eiQGokuzJRTo/DCpLrhS1tId/v3C3edt2JJ0PwuiMV3k0G/+w5/mJNCxhkHVV8c ZR2QzV55Y5UnPh4M9H0Y/0WMIjDpFRGnwNns4DsKaJA7FnM0WE4PK19q94zYqFLv7VH9O7xG2/kv TR3XyjXlpMv1TMU3XCcOZLZNs3POcnb0peRQ8AvXwOjH/8Mh3j1jWhhOmo5gNsrDn4TfD8w2A6V6 I3wKyPbRTuK235o3FOTFDLl1SkTWZ0dkNrscXAS9I0hbsP65lIFcVkXZZCqpFywHVXR8Lz9JG253 clo3caaZTlcm/eCpQnRgFbOZJYo5HlanZOVzoBGQ6KW6xEGpNhLNZ4ajiap21AtXLzbki0OJDo1U z3+ZgvN0rLgC5hNgXMHnw9o78dNAYKIeAp5q1jPPYwQt6vHLKKr57RtKcZXSW7m16YeQV9DHT0JL 4V2sfjK/E7hXeSXsASSLvey4jqO6+CpGdORE4Zdxzay5I9wlk1bHJs0tk+ZetvJ8YCAKuQrOPdF9 ix+bxT6JaXFelu1iU6X5pKW2dq9WnV5frEYb8vPBFcD5hsFhU6mKw0oDwchVM6De2yAjsQ5UKhsA zaXxxKgpgKqluWEq3BM4iefLysuxooHH35IAxiCZ1ts4XKhBBR0XrMjumTHoElQAtmFQF3yuAkp+ /7a2/qAUsXXRSiU0xMjOGpIG8EsuYtkNG0J8z5xlog436nndSkpQBDVcex4WfA9W7X/3ZmzWL5sf 8MPsOulc7H7RD92nfIoX5xguiJshL02lmM1OfjAbF4BXKQr0BDY93/TUHumqqlFNSuYRGNxYlrNP 9rMZbDm4GYughGFVUUIwaQMzRjMxKrMnEVeYBciU2am5E31TGSOO+WZ2SnPbbNeeGNsV55+gXjKi aEsG3GBrr+oVx0O6jQ3po9H1j8MXkisUzYVtjcP5WsWBPEgU8oGvwCrvF1Tekj/C98o1FjWWihNp yTED3engScmGDBXNyQq1YcnrryxXddXDXKZhAMLFl3JZ8sWKB8nHyuKWGMA0JB4ZQxU8Hg4RPF9G qctDoDMKLto6lk7cxrAmMMnxO+eszTIEswaKfb8u5lTgOEGApgdYbIO7cEjVw7EjdhdDXwv9e8x2 bcSRtFGSByUgWNmbXFHWoialUjQ+pUV3XzIY8W0CU1IjKTtm3XMMIriKDXIasRc0KSn7tPYt1eXD OpMR4/Z8CdNSZCs4zXjh4vYMJiHNdrLop4cUz85YNXUvxQG0hGBNXwo2FAIzVY1Fgr5XI+9XrE9s DEbEbKwpVHhuOxPVMFym28Rt3AK3kSdvBkUxg0KGffqSSMeLOKc0CQi68HUH5mB20AYA8kOgRWVn bsykJ4lXphT94pVbwpDR1+rK8Q81lXKZWQ8Jim2msEiEsWNn9viO2YB4jjjmv1H2TCGnczuUy7DF PIiqtqr6XWigH4To0Vccw9TD0/aA09ZjFAgnh0IYw0z1Y6xltZZ+uevBvg4kYCZcMvM4drkIProw Takt3KiK9Jd+s6F8GLeDs7sb8s8P5ZfjpR0Pj/2F9O2b92M1qxo2ccYGNeVMcLGetmfCFa/9FAYn NIJ3ymP/4JmYMuKHinm2slFQ/3GRab9lOrXEhJhzXScs3xfS6F1dkfnTdOPFNGI/zoYyuzhUfIj5 nr6+uZB5AEiLnWh06nDCo8uWqRMfwW4i1jsFeho+kn/AO0iUyqikkGwpA88TGdj15rfyKlDuUBlR umVmUgOpuvMlUOt5XA2kKZ5g8C/18mENck7HkMcf1ofcOMxD1gKm7rwQMJW3wzwKychMXUBlCRH5 hJ87InKJDqGSKCeBmQ19XPSb5vhIPMvG34gVvBaH2SLQ/rTA97ft2uT+R3i1JMcRwtD9nKIvYALi I6jKKlU5QeYC8VSySNnrXD8PkJpPj2NvzACt79OT+O+r8xSUZi3L/Kib+xCpXy4vossLVhAlMhJq snxdLj/0bO3bYZljphFDEx64DDLIMhxsjLHcm/hU94IOGNMAct5PJ1ILj37tRu7z9cMwQ1caY5iM 0ulF715fJhMJqLwx5b2INRMcX8Yz4tMuX+VOJSUzqcLitFe+A4He/9y+3O/+gM+/b44QBXvgnysY 6OlIyRsC37zfrKqP9RNYlyn2kKlNr3IQ8jgAVXcF3BWgI6DSmj9erthf8l2x4zuyddPlbk4+nEuG 6IjemRhDtQeXfqZ6iY3tVreFI7x7jlj7PphNLoq0yTlGzUMauhmnsNzC7BX4tMNZMc7zMK5bPKJ2 tSCHI6INxliKCI8t0vDcF48nojc+QaJErwWpGMLZ4Qzh8nLyEg2xn6L92NxhNuJNVnWPJ8mQ1JGx +Vnq4BA9dyjUfz2mp0MuNCPQOxMecd64nDU8QXQ3R2p3zUmT7eJqOtkEIE22v4xptDUcIQYnIlMR yxWOtjsaTBpJs82d73cUc6Dj73GL2RT4Edn4cLzf+Fy/ofZBBYggcJVwVH3FQn6/3X7cvt0n+MJd K5hklOdRsokQljCvS2SwImY17lUNhDEOr5mcJlVYpF3VrsARUpsXDRgQbIXOVQPVKE4aKKD1faYg w/9VQTSOqTxVABdKmBRgweETDRQ6ipYggV7y0yAhohXRESBtGixAl/X3Rz6U2PwOZFgqDm+IxjCb hvElIfgQC3/0Q9DZRHMdQyi8wumomKQT3morSKTmU1FFHCuSFFiKHCmpWANXFbcFObAM7rrT4LM2 AHKb4GulCvwtdQOYl1R7QwU2oL2dZQ/eAV/n01YpN2tcV95XLjdcpJqGTfvUCkzwXGobKuSVj4Tj QXCR3CB5rc7sYLhd7qK/1W72TEqtZvLbfeyiUfK0e5IZiN1OLDg4wZfJFr3LkcMu25sUU953P5IL b3i/ixEyUNq1uU3bQ7Qxca4RjDaXRU6FIZKEGFsKJxF3xM04ccBUZa6AvPGZKuF/ZBpP2DXh0jAS BA97glrpnXeXXeAs+bRvg6tsvlxOYGnwNMIQOa46F5Lc4NbAXosMZaRws71317hVcGh8pOEidtGN nMhuMAFi9t0tJ+dd0NJll0xGqlpT8p6XYaPJQWNsDcspVpk1X3nLVz9xoAhxtq1cLC1dPpa0jCko tlC5Btny2vj7CUy1vox09V0QzD8BBgBFlOIyCmVuZHN0cmVhbQ1lbmRvYmoNMjggMCBvYmoNPDwg DS9UeXBlIC9QYWdlIA0vUGFyZW50IDU1IDAgUiANL1Jlc291cmNlcyAyOSAwIFIgDS9Db250ZW50 cyAzMCAwIFIgDS9NZWRpYUJveCBbIDAgMCA1OTUgODQyIF0gDS9Dcm9wQm94IFsgMCAwIDU5NSA4 NDIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTI5IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYg L1RleHQgXSANL0ZvbnQgPDwgL1RUMSA2MyAwIFIgL1RUMiA2NyAwIFIgL1RUMyA3MCAwIFIgPj4g DS9FeHRHU3RhdGUgPDwgL0dTMSA4NyAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczYgNjIgMCBS ID4+IA0+PiANZW5kb2JqDTMwIDAgb2JqDTw8IC9MZW5ndGggNDMzMCAvRmlsdGVyIC9GbGF0ZURl Y29kZSA+PiANc3RyZWFtDQpIicxXTY8juQ2996/wOUB79K0qwPAhCRAg1/g2yKFc3Q6wwOYyh/z9 SBQfRdXHbs8ih2DgsVsiKYrieyT//Hj79njYi708Xm/WXUz5V76Sv4bpkr2/xuny+PXt219+pMv6 g7bN5cf677dvf/uHvfzrx5u5PNb633/ebsbYuXysMcYb45Ix0ZVP+TuU3+FVfk/lU3+vfS+m++OX 6oRnJ8zVsB/0K8drLv+b+TqRK2XRFA/Lqd/LiT4Xa8/ymeqp93cbTVmN5fwY2xkh1rPv/ppuTaz8 rUVd+XWd6t7MQn0zsL8xQ3/lH9FUNVeXwuE+304fdHxElvOn5jh916Bl9bs6sQ56kXdxdFzKj8h2 mt79n4+/v1U3nU2X8m1TzpfHXymEZkYI6QIz68T2d1h6SJNpZtPdtjuG9pj1o/czv29ETMZ3JtHU REO/oVqmSPt+Acqa5yhSb+tv6hTLeoZPS/sM0/qhOSl3WJujcaVYPf7U0itLbJ58TGpmnJ/p+BDr q/kh2huJLBLrPVwt3Q8RTB0K5OzUYmFhI0TS9Plu4cQ0bomtEhG2HvX74Ex6yKcSKynI8g4OElKW e8DLxP4ycpznBH5Be+XYO8Qe9oPc+4WYvlNQJwnqrAKPLLH399BgsOAXJXsgo2t/grYSJ0hJAGe9 iuRU+vbAbqrOwm3Yq2vzTXFKyISvGkmxP+0tkpSs1fhud2tSQB8nUwTk9OopJeakpZWFMVazPofe 0Qx3EQzKih0SfdIkEJgx48T54vhoV8qBQ4plzYsTp4S7nakoAgPBiGDLFQeMOI6fHc0VbDoCr7ar FLY+8kFAugjGA6ClmfYq0K47qPGmsFXQl131PXBGyScnDLfJfyM1i9x79ioVNBUMlbE5Ms1zy8e5 WHcoLrFtzibSZk1bI4wEdcCMvjXs1lG7ON5YnEDOaAJOAxsSw3mjvKFzWcdhaSQCCUSDK54dIdSJ gmR2Q+q723gL7xrxzXdOHSdSwtNKriHcw6SpLyGHcFGQuwsO3WhEqkf3fNLe4n0gnobN1NMMTi1I QdRQ7E/sNOhnc0PodUeUlorezPEk85oEnJXErHkc2ZZpaZWxFO9IPVT6lhei0ooNUZXPTG3YLNXl GlhdS0ivsSiALgZNVdPuZ+imKvh2hjHog1j6qbxMHetQcGFvBIikY01DJkG99VMFdp2FvVRPA1Rq RpW2anDMbxwjfpkywOPVkdIyeBAKinq3hG0dkGaOIt251d46jbDAhnQ6qGF8wpHVz9egm/W5TvEo bbtwF/rns8QH9JXp6BrDLTttUnKmLWtu3ohfyDPIdUz6/kpfpWc34GtuJgft9jCyXjO+kzmr2PFn S/jqry2MEmdfxhZusF0Uz7N6PxBmQAMrVMABYTJ3hBdaXfTO3J8Mk9Y4A5nW4s03rRUN5pg2ErCz aiZo1Owle3VdIpr2THox95TyTgKqSQj9rzwzM5twoL91MtJ2Yq/Doq0UeLNppLOT9TYd0m1Nfdfi Ok7sL3vdvjvslOHPSyOkb6qDhTkTp8V+k2l/u69MI3ro0ROazY2fnvdIWeMNqpGiuibjHSNHhhK7 n1PcXi0xdt2YGm3iaaEYRqI+lvBgsRuTSMkGXZ9hadNPQLaeV57bMjJko882untjW0CSdG/t4XWA TdZI/b0ZNrhrb8Q5KlHFO43RYXGaHtCMPTeW7lxTzsytZiivMJn4KTm0BK/R9Pm427k7TCTaSWQI TdiXs30ls8p/OKNYgrfbgGZ6Z8evhU4JVua+PHRijT2Ya6domGs3zfX2yZQTeZvbc4+jULSRYRO/ 28EcwJeRrhPqM7fOOsihEy15qoh27BJ8qDWOa7YrJ/rIJK6Lhj8pGq2/oaO+PR72Ujq511vpr035 V77KSBSmS5jz1ZV3/LW9KJWlCqdFVRBknI79dnJL98cv9RjXjpnplBmH5NIsxSniGCtNpf+sMC82 zD0Lcm2OVPArU0mDhrUF5QvJYlWivEZh98nFe2vlUEj3DpQYG2t+UoYmh9nwvVFOGyd79OtjiwWW dh/lqHTbm3HLwVq8N8vCjjruWfm4OcV7eXdDuZW9l9ySGu5nvnGkkvJuqTtjUw31T19KhiWLoMag 6M+U3UkYvftY77HNRZAB00kC/3N7VJrl6Bmy39WVNWu1mcUHDuExc90rqObboGGKBjIGPkUdz6TF aU6UQgf2iZQhbuHDPUApxp+hRo9xzdfZxN5Iz+eYtXrnxc2Aby2EW1tRdalNJHqvZpzj+7cmRLEh x4PkA88l8/i3V7eWiMQx1CK76Ja+Cn2yInN8hYpW0ASKNYcyk9VDOUk8XU8G4jt9YNeJws2YtzBu jRs1iEpHiHvi9MWiYI/1XOCqK/S+0zr2pMZDiktuWHBqkAJDCGZ9w5BbFKPhDLQ6+qxXef1+KrTh rsxvq25jKuFUXHr+yPlGhktwPcmtze8qZ3Pl9UIj7upD6iUqDAQemcAz+5UaBuvLI7JY+mQESdq9 qHh4TDb8A3n0GrRL+wG2zeMG50k9zX4MW0RiDokfVB660TOkmW1prraI/hw35Hy+JsG9a7pzScwr wohCR9AAObKkkEthx7ECNIweM3vvU38HPFL/Qvvt1gKegA4Nzj9HoScAEmYihAos6k5WUN+4X9fd 1D+DbmWVCNhmRPOEWqA19GbKi7MmVzxJd7C5vDzaZY2QWjWFlmb+7TpShLMtR1XPISxTOxlCD32O kTO2PmnT+iTnegXI3HOY9lvvS0+myEv2PGcYoeHZgS9oYsGn514KI+G2fUdlhEKo3azwfNwc69BH Vd8+un/SNnP/2JQmAW6L4j6rv+OFp6/ZtC6BdYjoVRtMnwrViH7Fdg5hPbq01I/S82W0Gyi3J4Dy tw0GoEzIyrd+2tCzHkyQPIaqpMy9mZSrV2HDH1VWUKr2Y2lLIyk/A7eq0oNGmhvDw6Sev1IO8qYc uBiFFI6SGvtHSS174ODtBiX43IoQre94X9gbPR8Sw/MzqqfVFhwRtEydLAHpfZi7pk4lrClW/xqh 2/glQrcEyCH/5sgcUsqH++n0G42cZ+CdunD++lIeKqun+VgCZiy3RAV6WeF1TE5pHDGx6g4n1DR1 ZbKts+d1mlVUh0ydOFM9amLpQX8jUXn7KE+xVbl3AvdOnJr6cYqjGK5CuycXlWpIOIuLkMRzOrDg LbjJdQsoUZQfkV8mabI8ybZJAmO46e/zEqYAPTSVhxcpzaYxTC37snoxfQ0lg64Cf3uuu2fyhKGE 3ul2Eiet8MfvIpLPMd1qrJwMciraP4WuOLk2L/xPCJ4MTm1k+w1kiRBBK/w+tIAXFOJFcc+HItSv tEPHlcNMAx5nxqNF5XBUsU8LR9s+rBu85XneGPAYFdvMvRVK6B7Ua3GNj5hOKE0wxHX9OhmAatHO 89ZhjmBOQ9N1VlBmAbjUE1gtvQXd0Lb+zR10UPSAfS44QFcjHSmQUvBOcOXDHAErt4WVO4KVO4KV 21QsNksFC5PIz/dLvb3+f+mcdEnyx/mfh/xfWv5z9suAdpz9eghCG7Mf81gqLGrWootwB6RkCK8K G7xM2IiMjZpu5FBoDtXhzn4M8g5dUjK76gCfc38VGjgsp+aLv5lp0L+b5SS5pZzLG2KIXfkb74oh IWHwqLlO7cWrnYeZBgxHftWZAZG0uf0OcxfW66ddA+9LGebxE6lpjUojBOZA93TShcx5m6gQYpKE 7HRQ2r+bN65ljzEyHQJeA5JZzmn4BUnKzCzD42QzXp2rCZsu5vhdgTv0NPS26G0OWNOb9sbVCeL9 wGPC4CjLLCD181L43rzTuXfUdKZjhMcB4U9CeKIy3OqUky7wuMS1/ROUb80QzOMJzF2pHfEA51gn oLdhSxV3le2UGQCZKgswMNQprGUB2nOvQfXZc32ud6x8QjxjjhFvvPReqXMG0izE7uwhoy/391aT UL9DogsfpPUoofOrrbhPZO5cn1ty18zwEKxW+6auO1OFdZqb2HMAEmDUwBr09sAKUr6J3LLkLfl2 yJp/CFwbUC06kX6yIB7DxfoBLmsriMLBhV+4EFmrV/xSiNredsvg8+eI/NyamD6qDRt+v+aeRVhS HBmHChX31l1ghZ+yTi/7yTScex5r4Va54qbZFFMfB+YX8WUPKoISGmjdvbFx6nprUvVm7b+cl0mO 4zAMRfd9lwKsMTYQZNc36F2tMnTd/wgtkfwUJdnuVC0MJJpM0eTj50qfo9AicZMVRNLV3A3QdyHO WyoLFuaUYQFmqZ/NQPG9n/RPzTapE5/XRkysZFLeSEMiwVBVo9zt0i+PWyHmhgxPw1kejVLd+Wq1 VzNjo7zTbMtTrmm5DVJWteyOUtkNUpk46TisO7LKGPldu7jUkNwMa9fVTVk2pVDENrw9SgpdHSVH DnTFh2O0t0riJMhhGgWrR0G69MtcFBu6waUMhmEwUOQQ256duzrx74Vr3lgaBb6TqoFyCTZppAEU x4F9NI6cuLe1gRhWfJBS+eIUlfhWaEWFfAm911fbTe1oOKCjoWqSR/fdZa9IBfpf29pLteYD5oxg dR1YI7+H4BohcFfRRC9JRIBEJ+47Y0matmOAtPjQTXE+iKTAtvfWxwkYp4ONnqCJjcVxuO+Mqeko EWayNQgWs7p12TmuXeBAu6yqXR7/rySxyPoNqixL5WDE9nTFQjQt4CrGA6rxvR+3krNbD76d0BNr iZ6oi6CnHlTo+R47kcDxTVjKywdYpuyU5IAlxrRIvQNL3YRiRrC0QW5hqaujpM0JLG0hnU2jkIsD LFNetb2sjx1zS+c+6LpOv0NQBtNAiHFElx3p+z02goGrVcGs465H3Pw5JXdpuA00rM9DaVgNMzTs GBiFgRcUHHF2HBAo46QzPee4iG07W4FysUD56k+14iwRp0ib2Rdh/FSSGWnFyy2PMISwGk9+gz1Y OnpBj9451Yi3fVLva89ZRr4XucX9kT+Ap76HVNLWVmD13MO0nRYUGDM5v5/uDnL13XQ3e5bHzTXt 5jvjjXKWg5dnv7tab/+jM1CLFPSWCsukQFEokPZElCCKautZjnFK2QOPpOhZpMWbP1eLXvMMe7zu yfyQgfKbSL8ni7G7Iz2suCAzgTMEEe7M7WlHTnWRay6q9RKuQERzMm8K63XQBzzn89IzVe6jMCmK 4QKkr+0Z53BlZAS9aSembVbo/mzmtx2Q5KYUsIfXd8GjFZk0Nc7ENxI7cD/Fh8vMido7nuUSFlZn eq58tqf1XgWJlfL2uromiIu8AQdC6tlKkN2zPOQTZL4eCavMZ1Huje/IBi+XLn40x/yXrPkL9/L5 h02TpGXsp8Z2IAKeg6j3k6hPUtCSQc8qeLG6GMOhhQQ98F8979WvpXJAKijLN0dMITY4x93w6uRv 3AM21srEoFgno96qAmIcgTR8qwrAvGrZgWRvDj4BYI6BIVlhFs8AGNQ52FNKQuls3Z6+f/Yrtau1 XHoanC+lgHBglZg1L9rYqctNkCvvoJCP0ge4fvHcix4KTQ2Au9x7baFdI19bjCMBV+bdU8TbBuE2 hfqSplDPFOqZDKa+o9Qqqqmvm20BddgIHzI0tRDHmuDESV3DhMmF+5mdEoragKXUF/nr0vdFOCdL k3oUT7qwlDJ/bS6mBJW6SCpTW1RLugbxKZwNL+JJlJoUzvy7Xl39ctiUqeOkbsErOIVrZh4wr+8w NChXqxco+RJWbio+r82RLgNILZxUyub9jLf1Sfc/xAGSSdYR8xlk0QebNPoV+WCuoN8jt9j/Sb50 qZhrbvz+8+vfALHlxvYKZW5kc3RyZWFtDWVuZG9iag0zMSAwIG9iag08PCANL1R5cGUgL0ZvbnQg DS9TdWJ0eXBlIC9UeXBlMCANL0Jhc2VGb250IC9CREtCS0MrQXJpYWwsQm9sZCANL0VuY29kaW5n IC9JZGVudGl0eS1IIA0vRGVzY2VuZGFudEZvbnRzIFsgNDUgMCBSIF0gDS9Ub1VuaWNvZGUgNDYg MCBSIA0+PiANZW5kb2JqDTMyIDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUw IA0vQmFzZUZvbnQgL0JES0RCUCtBcmlhbCxJdGFsaWMgDS9FbmNvZGluZyAvSWRlbnRpdHktSCAN L0Rlc2NlbmRhbnRGb250cyBbIDQ3IDAgUiBdIA0vVG9Vbmljb2RlIDQ4IDAgUiANPj4gDWVuZG9i ag0zMyAwIG9iag1bIA0vSW5kZXhlZCA2MiAwIFIgMjU1IDM0IDAgUiANXQ1lbmRvYmoNMzQgMCBv YmoNPDwgL0xlbmd0aCA3ODMgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSIkAAAP/ /AAAAAEBAQICAgMDAwQEBAUFBQYGBgcHBwgICAkJCQoKCgsLCwwMDA0NDQ4ODg8PDxAQEBERERIS EhMTExQUFBUVFRYWFhcXFxgYGBkZGRoaGhsbGxwcHB0dHR4eHh8fHyAgICEhISIiIiMjIyQkJCUl JSYmJicnJygoKCkpKSoqKisrKywsLC0tLS4uLi8vLzAwMDExMTIyMjMzMzQ0NDU1NTY2Njc3Nzg4 ODk5OTo6Ojs7Ozw8PD09PT4+Pj8/P0BAQEFBQUJCQkNDQ0REREVFRUZGRkdHR0hISElJSUpKSktL S0xMTE1NTU5OTk9PT1BQUFFRUVJSUlNTU1RUVFVVVVZWVldXV1hYWFlZWVpaWltbW1xcXF1dXV5e Xl9fX2BgYGFhYWJiYmNjY2RkZGVlZWZmZmdnZ2hoaGlpaWpqamtra2xsbG1tbW5ubm9vb3BwcHFx cXJycnNzc3R0dHV1dXZ2dnd3d3h4eHl5eXp6ent7e3x8fH19fX5+fn9/f4CAgIGBgYKCgoODg4SE hIWFhYaGhoeHh4iIiImJiYqKiouLi4yMjI2NjY6Ojo+Pj5CQkJGRkZKSkpOTk5SUlJWVlZaWlpeX l5iYmJmZmZqampubm5ycnJ2dnZ6enp+fn6CgoKGhoaKioqOjo6SkpKWlpaampqenp6ioqKmpqaqq qqurq6ysrK2tra6urq+vr7CwsLGxsbKysrOzs7S0tLW1tba2tre3t7i4uLm5ubq6uru7u7y8vL29 vb6+vr+/v8DAwMHBwcLCwsPDw8TExMXFxcbGxsfHx8jIyMnJycrKysvLy8zMzM3Nzc7Ozs/Pz9DQ 0NHR0dLS0tPT09TU1NXV1dbW1tfX19jY2NnZ2dra2tvb29zc3N3d3d7e3t/f3+Dg4OHh4eLi4uPj 4+Tk5OXl5ebm5ufn5+jo6Onp6erq6uvr6+zs7O3t7e7u7u/v7/Dw8PHx8fLy8vPz8/T09PX19fb2 9vf39/j4+Pn5+fr6+vv7+/z8/P39/f7+/v///wIMAJlifpAKZW5kc3RyZWFtDWVuZG9iag0zNSAw IG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMCANL0Jhc2VGb250IC9CREtFSUsr QXJpYWwsQm9sZEl0YWxpYyANL0VuY29kaW5nIC9JZGVudGl0eS1IIA0vRGVzY2VuZGFudEZvbnRz IFsgNDkgMCBSIF0gDS9Ub1VuaWNvZGUgNTAgMCBSIA0+PiANZW5kb2JqDTM2IDAgb2JqDTw8IA0v VHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUwIA0vQmFzZUZvbnQgL0JES0lCUCtTeW1ib2xNVCAN L0VuY29kaW5nIC9JZGVudGl0eS1IIA0vRGVzY2VuZGFudEZvbnRzIFsgNTEgMCBSIF0gDS9Ub1Vu aWNvZGUgNTIgMCBSIA0+PiANZW5kb2JqDTM3IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0 b3IgDS9Bc2NlbnQgOTA1IA0vQ2FwSGVpZ2h0IDcxOCANL0Rlc2NlbnQgLTIxMSANL0ZsYWdzIDQg DS9Gb250QkJveCBbIC02MjggLTM3NiAyMDM0IDEwNDggXSANL0ZvbnROYW1lIC9CREtCS0MrQXJp YWwsQm9sZCANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAxMzMgDS9YSGVpZ2h0IDUxNSANL0ZvbnRG aWxlMiAzOCAwIFIgDT4+IA1lbmRvYmoNMzggMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUg L0xlbmd0aCAxODgwMCAvTGVuZ3RoMSAzMjU0MCA+PiANc3RyZWFtDQpIiXxVC3hNVxb+19773Ju3 ICQ3CT3JkdRIoo0pgiCSm5BREUmriUfnXkk08UwrNRiVCpqZS6eUGjPUVFSpR3tCppQidHRaQzUf Nara5lPqUelnPIZRuWfWvYxhvm969nfOXXvttdf61/OCAATiRUiEl0yv0n84sewQc1YB9rTxlc9M rpM/RDB9DNAGPzNp5viXHnp3P5B6HkhbUV7mLv3rqvHFwJwzfKdXOTPafdh2CxAay/su5ZOrZlzb X/Al7zOAiL6Tppa4qe3V7sCEF3nvnOyeURl8jWr5/l9YXq98rqxybceaDkDcbCB8krYTsf53PWJV IlindeY/r7fCOuM78/2KiwB1uvPefbZiM/5OXUnHNrqFSNwkB6UiFwo32NN30YrXEIEnsJzaoQs6 4knkkmKZJCyildZ06wL641XUWdupxtrI56/gI9xkBF8rQm/ksfyTKMMFeRbF1h8RgFoEox8KqCPc OM7rOmNYimXYQ7Otm2w1AjWsLx2DMMjaZ91GNyxSi7UTgX/GEuwim1ViVaAz4uERSdZx6xskohhr sZkxJVGjGoI4TMQCrCCH/Iip1/AmvBQixsosbS9bysVITMGv4MFGHKR2lK+d0C5bv7bOwYb26MqY KnCBetIwsU6FWAOskxiN9/Ex++tbjWq0Wq+N9g60Xrf2owO2UxB9QPu0HtrvWudaa6x3EMJ4Ujki eWxnHOZhHz7BP3BFVFvVGIJCtnyAOpFOiRzx48Ih5og58ii6s7djGe3z+BNMzshO7MJujs2XaMZZ iqAY+gWNoyV0RYSIUnFErpQN8pgi9TbH20ACx6gK6/AeDuEwjpDG+h+lfJpAU+n39Do1C1NcEjdU gJqnflStWqK32fujlWddRxSi8ThmoZpjuxbb0IBP8Tmu4Cr+SeGURuW0hkxqpksiUMSL4aJSLBfr xBaZJ5fIfaqnylQT1WF1UntJW2h327233/Iu9W7xNlnbrSaunTDWn4gcjuhcrop12IujrP0LfIXT vvph/f1oFD3NVqbRb2gZbaED1EQX2Uv4V7zoJ5xsdap4juNUI5aKZWz9CK/PxEnxlfheXJeajJe9 5LNyjTTlDvmZ/E6Fq0TVXaWq4WqUsjgzPbTBWqG2Qduk7dcu29JtpbZK23l7jX1+wKHWbq1fe+Et 95rebVy7AVxJszgSq1HHdd/AOTjIEf2UETfjGmchmuLoYcbdh3JoKA2jp2gMlVEN1dKrtIJWUh29 wx6wD8LO2JPEIFEo3KJMzBe14mXRwGun+EQcFydECyOPlIZMkqkyV46So+UU9qFKzpHzObJL5EZ5 RB6V5+R52cJZi1Sd1fNqlvqDWq8aVJP2uDaZV522V2vUmrTb2m2bsEXbYm2P2CbYNthO2232XvZ8 +2/tx+xXAyoplroxch33PcLBPdhZbBQRqppamNGJFNqw50mch0LuiqsYKL2clzDfOWPrIByqve+m LUOZfL+KdqEnHUC1TUieiqoZW+mUaFYfiv74nFzkUOvlFO2giMMmnkaLxQdiF2WiQaSLkWKVBJ2l DTjL9T4Dy2giTcMmaqG+9AL1pmocEx1lIc1HulUnFAVSLl0GI8BcVYqn8ZMP9cEpXPCuVqFqNs+n HVjOGd2Mb+ht3CLNusTTTfI0cvOUWcT1vgC+qTeW+6ya+9HBE2SS7QgayMZTvLdtgJqFy/gXLmg7 uaIyeZKe81ao1epbq7eVwh3GXYYN3HflGMwdc5arZDfvfbsx3OlBPEt6cFfnYxRK8QJPvSWWaa2y 5lkzran4G9+9Rcl0i97gjtjBN9LxMa9X8AUt5D4c/NN+/r/HW4pGXKQoSqAe3A8t2nRtsbZRa9D2 aIdtqRzt+VjJFX2aqzmIPShBEy7iBgVwbhxIxmOMN42xF2GSKJa7kUXRqOSe7cpzPPOuJ9NYSw1H bxX3827ujcs8J8ZgD06QoEj2qITtB7CeoRznX7L0W5zBebSNOaU8tbvhe/Y7jNJEFdvLYE3LeWo1 MqZT+I6jbflxJfNccNJI1nUDT6GULfRCPtUjx3qPJ1UenPIQx7sLhSOT4ulNvufiDg1DJ/TRviWB ZG+elSYq5G7+j7GY/wb/e8WgPz3LKNqwH63oQMPR01uA5IyMjIED+qf369snrXfPx37eI/XRR7qn JCd1+1nXhxMTuhjxcfpDnTvFxkQ7oiI7doho365teJuw0JDgoMAAu01TUhCSs40cl24mukyVaAwZ kuLbG25muO9juEydWTkPypi6yy+mPyiZwZLj/0cy445kxj1JCtfTkZ6SrGcbunnYaeg7aNSIIqZf dhrFutnip4f56cV+OpTpuDi+oGdHlTt1k1x6tpkzvdyT7XKyuvrgoCwjqywoJRn1QcFMBjNlRhqV 9RQ5gPyEiMzuWy8QEMqgzGjDmW06DKcPgSkTst2lZv6IomxnTFxccUqySVklxjgTRqbZJskvgiy/ GdOWZdr9ZvQKnzdYqNcnN3oW7QjHOFdSSKlR6h5TZEp3sc9G2yS26zQjZ52J+u+WlbfLKqq9/zRG erKjKnTf1uOp1c3GEUX3n8b5vsXFrIPvioQclyeHTS/iIA4t1NmaWFBcZNICNqn7PPF5dce/MiPb x3FN0M1AI9Mo90xwcWqiPSYKZsZtjY7OeN9qRnS27nmiyIgzB8YYxW5nbH0EPAUztzkydMeDJynJ 9eFt7wS2PqzNXSIk9H6i7N6Zn/KL+6ihBfciSz5ERi4XhKmX6IykyGCf0nyfsjR4StJYjJ9i4ltm KWekwgzMcnnC+/r4vvumlhBu6J7r4AowWi49yHHf5dgSwq/DR/6b+/KPqrK+4/jn+X0l07sZTPGk 1zgw5ccQ8kdi08s4MDcmgQICukKmlrCGiyMnd47oPC0JpERFEdG5Wllg6/rjj2vYdl07I2ysdorW cZ1O07mp5LZOtgqUZ+/P93me6+VRw9r2z4AXn+/vH5/v+/vjYZ2EpYZ8JxxISgokJrJEjCysKcY4 T8RnpiTXBuVZcWu8Phi4j/Lh2+WlGalw/5QpvMCNQT9VIBLYWFBixX1UMfEw+VOTSgNyOeeEnJzo Is7Z6OSEq5fHQclHid/j0QFPQvhvrDdmXPYDGQEp5jOyV1r5uYvjcgvKSnzZDeW2b3MLh8Ws/LvC eXYoMC6rRJko2yF5oiJyIcpl4cIcKRkdUOPxpwtRrwgoEKVIkHw5AW/5Aut/adSUKTesEzQ8EZWC 5j+5ljBXq9mjDGQkDY/PHRYfNrrRDQrGqybIuYVlDQ1Rw/JycAA1NOTE+XIayhuWB82NFXE+b1zD MfmAfKBhTXa5s6BB88XGiYGcLaWYxANSRgqxs415Q3mU5aWBgaECb7Zwf8SPdqtuJ8lzbDooqLxK a9Qa+jLIMW6nUq2byqS/0TLkVYEs5XZ8zxykIpRfi3gN7HZ5jnkF5YvBk+BOsBAkgKVgic1ikIk6 PaADbdzH7Qh7hiqNXvo6+iKwEywHO7RiakHeLn0OVXA6+tqCNuIQ3o30vXoHNSPcivxSLiss1y+m byM/GeHtWrFpGk1kII0QvoL0GPS/jccMm4D+a9Qa8yLCiWj7W8jfDFsEW2iPd7wIn+E6Yq48x8c4 DP/UIb0ZLAKNYCn8w/Wno95kxJsQvgXjGgU7GoxRie5AmbvxLgvApqD/LHveJOaNeYTnhPGLMV0f 9mlmJBgTz+s86AWvR4zNTdMwanCD3ynWj+d8K5gr99I34Jchnpd21vyY8RC9jXl1AQ1vvzQPmR0Y 53ztKLUing7uFtSQpLZTtXIJa3CUfqTvpJ8hneQ08C+Kl9+nWD2eZsN/JWh/CViJNl8WeljBYzDf h52snqVYtFUOKtF3j+Mn9g3iC7CuJSh7GWE8IOkRsBo+aAUP8fjQfyr7HOv+sVQ89BzKvod+chn0 OVmAuVvrSmtR/4doSxL9WOtgWYD8Svj0F+BX4ASPwUHozEa01UGK3GF+CDsOxIJe0Mx6A+VgP5dB /1EoHyX0Cs2wNlkfrA2tW2h1MY/dmoPYC432nnkQ9ZeCCWCqfpCW2UxFWfZPBWuW94vTNmuLde1Y oekq1r10gefJmoqwO7QQFfAYRL/QlmN536HddWzxDcBjalP6aCtrlvXmWPYLa433I+8J2+ZHzDXZ 3iPJqD9JaB1adKzji7B9jdrQZrHeDJ32U556ivLw6szT1sFuw/yOIQ3zUfF6V5LoHk+IpmEt70Hd 3S7byhh9UiX6ekLthC/6aK/wa598h9onaVqneV4jqUfrlOtE+BrrRgpZeWyZyLzPm/5FkN/SOmkV whe0PtPEfLbxnjD6penA51ikHwYbQaInSWr1VElBo4i8+Ly6BKpVP2Vofpqthmi+Gk1++Cke6UX6 N8W5uxXtd0v91IT1etSIpjjlPM5G9CW/hfsBcPuwCyN0NExzbi051tGr27Jm+NyF1WAnYN+9CLrA KZs/g9PQ4w/E/sXdwOezuB9wRoMmS6/mxbA+e6gd9nFHny6dJrr0abh16bZ8t/D5Lu4W7FOMo8mZ P5+PfMbxGcnnHN99Tnm3jajfgrPjj+Ic7qUye19PA9NBKto4bp8jXUrQvIQ9ek5/w+wy5ptdykmz S99tPmNUma/oR812zHta+E4NWWcZ7yfnLmU/8b3o3KNaAq2yz7M2URb9i3u0WJwDpK/D/qukCrT7 O75XeR8q7dh38Cfa26Q+S99XT9NWjH2s8oKVri6mPD4T1VqEkY4znfNvUbaK/EXqh1SrTkP4Wdg9 9CXdoFr911zH7BVpZ6w8TtPKaBd0l6o+Rj/XDlEJrxXPQ55pnuS1x56P9WykvQZBw6epTR3AnEOY Y7ewe4SeuO4Rc4DnZ8ylr2gK5sdlANfR9pLP9sdO4YuQ8FGL0DB8wW3qb4r3Bmlvo/xPab0nito8 X8X59BHFGjhLRF+HaInHL/yuivv6A+yPfmisiOq128xPhf4PmqYygD3Uj/3FSMiLpglaP+3BXqoX /rFsI+8fpZ+iWSOYX6F4T/RD40/TQ3onbdFD0F0f7oI+rFs/5lJFdyHcrHaagyibjTaI+0Z6gXif 8D3lN1/n/WKEaLzhR/8ow2MQ7z/0q5zFeLdTPc6STE8/PaX7+F0jSdDeJJBmIeIbQB3YYiHSvJaV pqCN9SJ9Jb0idygy9M35Pepz2Ht7KFM5QFHqKrwfLtAmOZU2K3nQ3UXcGQrqIa4m01TlIuUqn4j7 Z7MWRbNFuRjc4+coXy1F/RCtUA/TCsVEeDxogR5RTwtSmfY9vLPuRTs28izUGUX5eiPCqeZBLif6 +MSMYdR1lC7qRSDG6sBjfjJizC3w7Y+hBx4vwpHj5bGGx2mP8XrjE/PkdlFPlPkTZRKZ74B4yw4V yE3UCfbLp/AOD1GdtBOPlXbKkc6CdpvnaYGwh0AB5ah1Uj3IB6paR/tgU2AvgD7QDo6Dv6sz6Sdo +wTsEf4uYORf4uyCRf7T4CXwrpMXCfd1vfRI1L/SsLiWThsYORlvwmS6tvw+mqE+jHN4OvwJlFrK Z/QxVG14qFo+jXQ+k1xxbSrtUqtp0kjjGQnpNZoufGjhj5yjsx6wMTfBOxHWxxb7K4Xv5/90jJ8X rO8GcL/w/376mtDQOfjfoFHScbpXeg/6a6fvMHa8XPhzH/a9vU5IrxfprvWDVmYpi8jvTkd4E+PE 3es6UhztvhCJowMHIx1vEaC+i/LAHcd98Cijs8aSRXw948TD/d6IQpoBP+XAktCYK657aS0jr0G8 lVjnDzLheCHeVYWWPhn4djUDHxKDtPsZ+I4YlH2EifBrCfsVfXJdctbH0bl7fXhc6m9Q7i94MxdS rNuG9W2fF8M0X2DpPRzns+Ssq8zVPXF1b2Cv3KjN/yewd06CbvDb/3VffMrwGeHlc+INvDcCeKs+ hW/MV6mJ6Eo90eAJosv34RxKg30eaUUIJ8B+AMYjbTUsbqNBqOwy1Dj0JugF+9WJ9LD9rpyAeLZV 98ozdnvxVn2uN4DXzuAsq/7gZrAH4d8DqGzwZdgdsB+hfAD1SmHrkLYJdgbi+SAH8T8gPg/ICGeA 8wDjvIxnzOVU1N8Havk9cp3v0P+uvcH3x81ajLESfFe8OTFe9zfETVtnPUew7m8NZ/1Hss63xDXW 9gPefCeZiG+fz/zGcSzW81P8Xhr6B9FLShuNlSSabIaU1iPe29L9QWX3kbHj0v2ZXqUFZ3MLyRRQ FlIIyFStNNMGIKN47uGUtPRjHDgSNSbdi/KN5AP/Jr2MY5s67jh+d8/4OSGOnRCCSwj3grGdOHUx bjKDQPF7xqZa/UcMSSu7UNVAI7Wa1FoiKRu0SWBCIkGk0SpNmiot3qRFqLTN8/OgNgnCXVap2tRh bZqWTprmP9hfo6J/TPtvyr53dqGT+Kea4Xvfe3e/z/3u3V2en2chhRRQUnmtQyL+amlbtxj+x5ar Q3IXrPBQo1JyeyJpo0v5IaHKhPIG8RKuTMN3w8/Ae+GnlVeJU85TL7nckVnkiyE8pmwnA+g28HYW gSeUnaRHhk1Z7Y08U1Z/MGK0KkcUjwxxKU4yBHcoqhXh2qqiY6a6cqXUslXM74rl3h65o1xWVNKF qFlE7eCuO0or2QeJOxkvtTgji0abMo7bHMeycMyRkiVZ6sobFgZCvqSyi3Sj7wf4QbodflTZbW3n 1VW8R4uwn4hRkG/EcjwrrORsj1SNFmUEvaaygBVfkNkWS/4DEWL4lX4ShhgWdQa1GdTcyjxq89im eWzNPLZmHrOYx5OHKHPomUPMPuU8ySvnyCK0hLoNQ263sIIVWdnbH6koTykerIR7FWtH0bqz1NIu ZuaxOrfJME+prT0Su6OcJaMQw+QnSzs8kTdXlaC8ladLnh4B5K2WNizdjsZeAOwWe3BH2aXslivR K1fANDiuKX5cckLZ71hNrA77E/uz2F92D9fCf9/0L5r+h4ZvVlmthCx6mf1ReN3Yxf6BwV5hfyNL qDG2ytZJGMBfWVnMgn3JKiQG38D1q/AK/Fn4bavvc15m5RIMc3/fcnaLm2Xr1uC+ZoX7mpUdPc1K Z3fE8LHfsE/JLgzxF/he+KesSvbA78I98CqbJJ/Db7Jhcgj+66b/lq2JM80+YbfIAXjJahdTMC1V 2IplF/axRRpX6X18jX3MbpCdCP3I8u9E6/WSfy93rWI8yn7FJq1e3mm0sl/QDP0XggpkQzjpZL+0 omKQRWtN4xW2yBZ1T1T36SF9WQn7wqHwsqL5tJAW1ZY1w80WyBYsHv5g2VWUUaIxnB5IhxbZnGWL msZ/cE/ivhiZRVmQtRzKvKwRlO5HvV/LWoxdJqMQwxjT0Aw0C10kNpTnoQvQ29A7smUSmoLO4fGR B5EHkQeRl0QeRB5EHkReEnmZfQoSRA5EDkQORE4SORA5EDkQOUmI+eZA5CSRBpEGkQaRlkQaRBpE GkRaEmkQaRBpSeggdBA6CF0SOggdhA5Cl4QOQgehSyIMIgwiDCIsiTCIMIgwiLAkwiDCIMKS0EBo IDQQmiQ0EBoIDYQmCQ2EBkKThBuEG4QbhFsSbhBuEG4Qbkm45f5MQYKog6iDqIOoS6IOog6iDqIu iTqIOog6O1dUasZnQGpAakBqEqkBqQGpAalJpAakBqTWvPVJuRgMx2YamoFmIcFWwVbBVsFWJVuV x2sKEqwJwgRhgjAlYYIwQZggTEmYIEwQpiQKIAogCiAKkiiAKIAogChIoiAP7hQkiO9+KL/z1rCL NOPAlyubpQPSZ8gD6dNkQ/o7pCj9bbIs/QK5JP08iUo/R/zSMZ70ScId1OJRl9GNR8Ao9Ar0JrQE rUB3IVXW7kF/hzbZsL7H5lJH1SV1Rb2rbllR6ypz2UftS/YV+137lhV73c40o4c55XMUjxbyrixn UD6E8CWCMiZrMTaEvEN4zg7j3xAb0ju+0h4G6b0gvRukK0H6bpAaLew5apNPOo1EGSZOM3qbf4Rv QFF/YARPpoVbD3Zwy/89XqZrDRvQB+EPoCK0DF2ColAECkE+iMu2IOIz+p7mkGtQAOqDNJGCdHfj fbuzw6FXmJMulz5zkhaRJ9APbtUKhGFlKzAK+8QKnOZGC71FAuI1iN7Ezt2Ar1j8Pro/atiHFl+F Xbf4EOxlK/AM7IQV+IIbTvoC4TaBjjd9DPct/LjFX0TYMYsPwAatgF9EB5HIh94BmiH34b4mtbeR yWvxQ7A9Fj8ooh0kIDae2klITm8LJFwpYUIPKzRjo/pW/hV/jz8A/k8sLI7Hl1rZBrvnK9MX9Va+ Fvo5gg1uGa0iHt8Pxaabwm/yZd8cfx9jUd8t/jP+DF8IlR1ovoZ5z8kUFr+kldkNfRuf5WE+GbrP z/Ln+Sl+nL/sQ7vFT/I1MU2SpRl24xZPY8Dv4y58Fn/OV5ZTPMp/xHUe4Ae1NbG+5EBj3GhoTawA iTSyP431DfrK4oy/EC3TDj2ofq0uqifUuHpI9ap71N1qr9rl6HS4He2ONkerw+GwO2wO5iCOrvJm XR8kOLZddrcwu02UNll3M1GiED/IGHUw8jwxtykplhqL05RZPUNSpzXz32PeMm099pK5xRunZmeK pMbj5oHBVFndPG5GB1Ommj6RKVK6kEWrya6UKRnPlOmmaLrcY3YeQSe5fK2nQih96vK1bJZ4ut+K eWKdIx0HjyaeUOSa5eDjj+fb1V7zp6mxjPlBb9aMiMpmbzZlXhzTTmYqzMWcyUSFtQvLZiq2PHMl j4t2Wz6RRdh9GYbT3I4wEhCGMEecaCIMz5O4CMMeNeL8wBHXJwxxrU7il3H+VqeMs1ERV9zQkomi pskY/MDckDEbPvKtGJwYsImi3y+jvBrNiCia8WpyYgNyIM4REuIyhOK9Tg7EqUxm7nsc4muGDD8K GZa5FPo4hjdiuvq/ienqR8zg//mZiA/S0v6p6fXkhDeZ8yYnoJx59a3XPObsaU0rTk+JDs1U/LnT Z14TfmrCnPJOJMxpb0Ir7l9/Qve66N7vTRTJenI8U1zXJxLWfn1/0nsqkS3FDmeM/8k19yhX5vAT BjssBsuIXDHjCd2G6I6JXIbIZYhcMT0mcyVfF+c+nSk6SDx75GTDS2xrK85wrqcvG+9250fEga4c 6vNM99y2EXqdbB3Mmm3euOmERFfICBmiC39noqsdza5ml2f6UF/PbXq92eVGc4c3Tr5ZWiKCUubw sZTZN/ZSRhwVUz/15D07Kz6y20OSryfw/798V31wE8cV39370sl30p0snyVZZ0m2LENk8IdsCWVM fI5xgusKcEkNHhAwTcEESFJjG+iQhH+gkMlk7BkolMIEp21swoRAbGJcEhvT8hHoH4USUhOmU6bj hKQTpZ7GUAbwuW9lTJtppiftx+3e3r77vd97bx/ct6UL/P77SdT6nVfbd13t7e2ttGoPtyJUf/yx xfXHow0giSDAVqvmNcHY7OkxhkmPvSeKtQOTwzAZBiFwG92O9sI4DAgaVsi6BNLFdwmEpgptfR69 7MVBiODboEAeRzb3Fpems4jNfXkFNH9p6yuumGohP6VtrydQBjv0xWApbQumWkOdBZ3Ogs5ZnbGu gq5ZXTEeRvu7YdDXTUNpb3E3g9rCrdNAQLetCcAGseh+b/Z69fTGXbQTDjeFW3Ear/8FG0+D/gjY 1odvbU2/vm1aIVPjrWjq4anJcPv0ovaHS9KT7ekldD+IiggyDQ6yUzijPHmCYJMXBkiVkYk41mSQ VWBNjNwWnjMJ8yEOIREfxy7kCit3KicqFyjjlYmJSlQFfeUBVKUlATWgFkAFbh498DPDDwwO3Ud+ dphu0zR5jh/krqIMlAMBJgwJWK+xwOd90Yu91/Rcp67n6pKXd+b6feVF3hI9f3TO7ZJRPTxTHFVu u0Z9uQxGc5W5ZG52tgeF8FgIh5aXH0NFeKwIFy23+31+4h/AoqEjHo/xmF/uPIYkPCZhaflCtBJi jbsyUeMKg9TJxESy5Q4tyYedBbWr532ehC+pTKTGU8WjUKmOOIbiiKernbPDyZeVs6UlmeXRSJmW 5eTz80IxZ7YWKYtFK8oLQ/l5Ao/zcQT/n/mmo3v2H6XlRsBdNMvt97tnFbkDuPIyI18yTx/du+8/ k64ATELNLjo3NHgeykcdpcFgaUdHSUGw9N4tPuP+pnNDQ+fODw1dSA91pKdpNF1vNpC1gLKCnjJs M+w9DLGIGIkKclgGcR4SIRTmQcjdY1jFb6QDfraEJewA2dunvrWe6jWZmhhPKSlUVaVUKqBRnMT5 IVKhZEZjEUKynI5sjaw+s7/r2cbtw682z63INxtu4X9+iQOY3Bw0r5hLvv6NefjAGipJDUhipCWp M1yFpNDaTJqt+0gPOWwTRIuC4O9QqEwIeJWW6YTlG+6ARKVxrKuh0qQmRr8tTOYTTEU5YSKaI8sp EKZ28bzHvWtePb2v58n6d8yG3qG7f23/Gr+Ni/9s5t698g9z3LxPJanGO8lzpAtYXmYESrCBCY4B 5xXGz5QwLDOPU5AflcC0m31rA6XIaDKhAB+KU0nQOHC6mszAO7HbvEXfthuqd7AbHg8aWWQOspKQ HQhN38DCG5o3TZMMVSVSpSURWL8bu6dWE9Q4eYu1ccPIBgt2G/VbrLusPfiIcETssZ0UPxItjWqT 1uRp9DWra7W1nmafJU7ifFSMynWkjq8Vn5J7xD+Qi/xZ8ax8ndzgPxY/llXF5XcRF/VMBQ6t3NVt kX32YjuxG3Bn70acPrKQxawnzzmS4Q5c/V1avkRqgXKnJQHgpsIttFB4UTKJy7I1VRGAv0hVYtHs PF7gVUUDIkdjUVUJhUjZtS0dnZuvfWLegzqySNPLF0amGm74FyfMleaq/r24DnfjN/r3fln9zPMm XGeM6mc2AOzkTDUg+CsAPwQYiKjRENeTreQ1wgAL8cy+lRzmBsiKkxaRw0gS0QdwdiEIk6Qhc4j1 sX72OMuybusp3IO70BTQlQnqjcB4qyrHk6l4aQlKBgIqL1REg7EIEzJv/fLKC5iUjLL5nbWTwYs/ ozqMIMRKIIGO842V77v6Pb/NucRecF12XXZf9lhqcmq8NXqj+wD7c9cRtttr4T1+NIOPeeazNa4a d43HEnQF3UEPo4XYRnaX62DOQe9B/Yj3iG5xIF3R/Xqpvknfrnfqn+gWnepFc2aV60SR7DqlGqFc MYBANKiAjtAAebOPYMlO84N8n1QsEYnqTurO5MQRTcMLQWSPzz6ibCbu3GkFjqc1CC6LWshEuGUU HHE42VKZ9lyRcJJGG6RPDveqcSpDrz3dGDYlzlqUOGdRoVXjUwGiiWq/vmHpIMqZvIm8UPTJm3Pm zGnCLUnghBqIOmJR6snAkfFCQTQ45eQEnuUFVnpQqHR9NRR+fHXT0rUW8ws3tpy/fvfpRMS887SG OfP+HizeeK9qyQ9XrF631fvFpb+/+2zfj6rHF4WoJhJgDzmgiZnoilH8uvZ69sUsZqv3NS/pZt7m epz9zCmu3/mp6y9ui+bEATgGszg7Uwv4ZEWyDuCgIRpyh0xkGWsDmBh2X2ZxJsmk4GV253AYAH1f AdYAu+DTy2CY7S6Uj0vDgLCkKSPbfB2+Q75jvtM+zndTGFkYxEFPWBvJ3oxHkPuxR6Yy/tBYgF9q vDj5EG5a0dsUDRRqHKnpYAF/ABNgQ8nMgrTdpFETYtoj+J4gEbAy8GAaVCg/L5jAiryxYcnmjT+I 1vs2bllaN39NhjmR8/zvf/rHl5uvvrLP/PxPF8x7eEdg7Qvbf7LupazPmOeWfG/pj1cV7Ti0bPuG XWdacz7cccYc+wxsBUBl5wGeViSji0Zc8stxUXJLYWmxtF76m8SnZMyzGlvAzpDny8vkHvmkfF4W MWRsEi8LnDVDFpAkyfIAftfwMKyTAQdJJFZmZMJakWDIw/JluPkAz0AWOECc6EcsCwvQAF56guuw YitVg0MRDgmnBUbw2KvINkKI23YKfx/PT1vsaAuEmQTYLTXaKjhETCQrp0JtGkIIttzsMAvR1m63 U1oCkGE4U1TgiBrJylexiskrE4fJS1/195tj5jFceIf59YMV/zKvk1x828wATi0DTlVw3WDdijHT YvNLMUeto869X37Dts/xqU10qJmOgJrv2OEAp4JlK3yvQ1UHSJeh2WSnzSY7rE4/poGCWYQ7wW19 i0Yn0yzKkf/NdrUAN3Gc4du9O93tnSSfdLIly8aSbPzAAks44mknvraUMHVBgD0YwwibgHm1JYiJ LTAQSHk4TBhwpgHDDB2bqWNqlw6kroNtoKVMCUkJhRYGTFMCbUhJGAzujEt46dx/T4YhLdacdmdn df732+/7/++HQjVPs3ikgIQlSjipzUFJJjtSQl5H0KE5WEc3+pXmsNk8SkDBAaVECSusQrcq9H+p SUlWLkkB2l1wIs2JnG6PtRv5NLslho5fYJDGNDOHaVHKuNiDXh1OdpSEN4GMxoQmPcXQPCz4n3Ey ErUlQLQCiOgZMQ1WfouSuSrgKoBhYYCLkPFHzkcuc930ufVrF66tvtmIb8Xvjl7w2jHELd+lnx1i 0NoRVa/vamxo+JEPP9YfPgzoA1e7dp76G7CuAhDPB9Y5mSymRytaIdeKDWJT6kH+oNhu7VB7rB/a TqgnbedVSzI/3jZFqU/pwn9VLjiEY8x5+DmHBJddSfOm4TQKYRpAlNaWZPH4Aj7so4D52jRygQwR lnSjcOdhhBBFKtPDBeBONONCknnQbCyjLwyOz53t6rOnjvyfUjeYyJODEXA5iZpHaUfRiSSKH+Jz DIECInZDmFACGch0yPEMMxOXpA9I5d+rXKcs33/ksf7g/Of6P1H+3YOfxQ+8OWvGslXls1ZxZRnl M1vi6/XBS//QB1Al2o5+hhYfe/L19t317+zauhEYWgEqdQFDZWZbD8MN3dDGJtlCkuyWJ3MTpWn8 HLlD/p18Tr4qSz4ZyazAeOSAjANyiRyWWZkeWO6lhgYdOoox4gTRLIIAOwMCAv9erVlxmEWs2wLm 3TwMQjGtFaC6uFEolX6DNujp2f3gcpJNGDt9dvuECvYPsftvIf3fQv9H3AHEf1qr/0BXT6EgXvMQ +Fg29C/OCXftYkYyQeTrCoojPKGc7qEHWgwmZ2xn1Cv8FYFLlp3WZCXZUavUObYoQg6Tbx7PFJmn Mj80r+QWieBvkmO5DblNlr2uVku7q93dlnEwt210e7DHfTTDGVO3qdscDblcE1xnEyCWXrAXZn5C 59mspwAVUBRKCsIFuKAX74SadVJTU1yhVemb0nEL9BTpJruSh/IonwjsDOZpeTgPmjNNsVs8magk M5yJM+k7Mumi28R7+kjM3xdOQknuwtQ+Npbdl5I69v9LgOGYItGSeMQfVWj6j/r7IwkqRehj8MlA NRphohHo4XJyxj3tCoyMz2Vl5tIl9Tlasc/N0bSfLPry4l9uraiu36jHr3y89ed1PVXhmdVVM2ZV u2OVFavfqFxawzoLDlS3Xr7cuqQ5f+zxdWf15ev7YmfQrPIFVeXhqur4y2/8dEPd0g07qef8DtyY Y1idn2pzi2ylthq5XtwutvPtYpu1Te1ietgua7ftt+pp5k+2k6otpM6RKy1VttlqtWpK5WMp+5zX lOsOfpmKEmL1pAVArFpCqLzi84JQKdQWQ6xhcp0MDIu1JSHW58pwWkKvFldf2I7s7uyEbs3P6XXw mTl9sV6fgjuczSZA7sLjQiBVKljovJCBY7KBaQQpUvn3K+ptK5p//RiRc9dRhn753qFLeMGG2TOW gl5fR2UZZTNbnqxD8uXryKYf1Gv1lfr+o2z623vW7di5dRMwbuHQLX4B9DJu5pI2fRvZ7tie0szs NZ0hl9hL8n9Ykk3yzHmWUY5RKbV8LdnGi4IqOJ2q0zkK57PZvJDHl6Aw2sc3kU/Y07KAZisMusEM wN1QC2hzhYxRssCI5mlO1xhOtGpWe8haWpWEKCW1ZFcI7GGelmkfI7FJ96xzmHsMvBIjdxDInpzb IqAkwSMEoeh24x2daW+WPSsYMxRAcDj9DQJ1b/rpSCfUKyNq8HgTl+Wl4Pm8zhRnIg2C6wf4uBLk +a5+7o7+d/1tVI9CyPLLxYX6Z+73635x9uOWug6cNn/ga7QLzUMr0e7mBUemrt5yW3+k376zhzLv PYbhF/K90AN6mI3aS3l8nvSqs4arMfP5zknOaSmVKctS+EnO8WkNafv4PTLvsWUjBqv27CRFTM09 TNMZ4ELkED2Upm7yIa8vCFSz2b2MVwkqGCrpO53esWVPW4E42OFI9L7fIA84DPrQU0ahd/SB6TIa RxP9ZPnAJRdOeAWIk5OTm5P1Hh5xtPqt7uoxE5ZM3/xaa/wiyru2fsK0quLiH5e90sX3puec0m/9 uWtzy6LSfA936sk4q33O6Y6OD5fYrdTH7oaMPgAnlZlG7WWRh5ScbbJ7eBTkD/OY5wnLZUP7I5Fs mREFUymLp0kMpHa31xK0aGCoOOJFtC0ARsCJzM+fyLg/yN3FRsFPnMlIPIbD58Haj5jEdw9t+o3b GD5QqamvhE0srxQXGx1osm/42c2VPPka34h72Zf43gf6sW/06DcQfRNEvwWiJ8xqrQSiN/HZglcM ir8Xr4tcQGwUsSgyiSMQiL/EFDZh02wWDCB2e+WgjOVvxy+9KP5IokmLF9tp8C+Kr4ntjxfhxfH9 NLb3H8TfpcjCF6SgXsaMDmmyzOaIOTJ4UsTCUTWSPjkkeScXhUj30I3O4VFrTS+AVfgyEVH6gtyR OI5IkorTOYV4pCw8mvOSgLQUL+NqyAophtdwraRD6iK90n3ySEpp5hpJs/QR+US6gvu4y+SqdAt/ xX1JbkuWGFkjbcY7uM1kh9SIhblyDV7BLSXLpDq8lhOm4FJuCimVKsQKMlcSXFLAGsKTuRApkkqs ArXRJkKkZOzmnASIXaSNYSXi5URCChNOG8uSVMhimGJZZFkzh7FZkggRRI8VgTm0dAomnuvFE+mt d86PhHiaT51l5SG+UNCEjSIST2wEaE7IXtmMu/FEzY4YRoONjAabmEIP1FD6GsvYWpdfGYz2+/1K 8V2l2J2qxKPxaLHbBX7SDwvg0qm5hE9Jsd1puMmGDX9sKHDRwQ/5t/SIWgbsE4dufCB7aaMYMf6i q2k7yfijEbhVhOBabQiE9i46hiQkoON6v35N/0L/nO994mK/ejT1v2SXfVAU9xnH97e3t3u77O69 sLd7byt3tweHd4CAx+FVDJuiKIIgNRIu9gyTDG+mFnA0ghkRbTwgzYux1rdqpWliakwjmqrAaBJN a5v8E2uNSWodtXFixg7RyThTHWXps8dF0xZm9ze/vZub2ef3fb7fz0NsuterX6CbOHjsdfBYM+bG XlOX7jDuMO1kd/KECVG8yUw5go5ueq2NWmvttieJQdMgm+Q32waFAfuANOBIuljKZhIol93mElwO u4vKzOdoZz5lEIOHGIQxFsbLGBjdRbyFsio3yZ1ynzwkk175lozLluAQhsxgUoUAOLp/eno/fOCf KUdJpBxlvHw8NZJ0wXAXKY1GS6Mz07aJIcH2IMHjFcW/bx18F81Fm7Ve7aQ2qvWioq8OH/7y0vHj V/DzV3Z2Hgn/AEJmt7ZX6wDzbLurTU5O3r9zT/dM3UnugN71OqxVs0njqDDqMMw3olbjBSNus2Zz PI+5LXovmjGT+H8uKWbJhen3M8oW8/fb0vPfRvnAJ9NN+dAr4fAgCHRi0Z1SccLAGtXfDXzyl+gi 4n/U+9ZTO2pXfHTqtUPPVixfUDJkHBN9lw71j7Rb7ROfEae1poKnHl3cxjGpc11JToNztWO5kGPr k3K/bze2W9gj7pHIbst6aa03yST5AcuAMOg2kTKd7XILsuBzZj8jrcNMqzEUp9qobqrH1TOtx/sC NWgddCW9u6jdGdutB6hj4hnxgmgtdTda26l2Zh3WQ5EGVIP9GPsJRgREfzAYECnMQOI5nnyzITiC 1xzNqfPn07heMWBufAQtUc2G8zSdk5PlDOLVh0LIlq6mbUotITXUFOoM9YWGQqQ3dCuEh7KCQywy s1lsIWtgdbVM/1+1QF2vTYBHY+W3x8OWCQ10A+wipeAF6AXQJQEEk0hkixIFRQ2S36UvZoV4yo6m dWTXI7g0J1gqGotW9q2sUPnjWw5p72gbUR+qQpWotyRXG4vFrhw9evXq22rsicSSrWO1BX8VFOq5 cvQyakOt6BWtS9v13pafqhXvPafduz8BQrPP9h0o1pUGEW08AUqzYz7sjropZq4yP06tyFjBvkW/ yQ8px/jPaYY0kYxkEpkoX8lXmimThbYKvGAWLFE+ap5vXsP3WP7GZHTT3c5n5QF6wJmUSVoUaNbM L+HX8M/z2/jf8kbey7ECx7Fm1s5JYnamRUBNwpCACwLm9elCBknbMRM43Ak1iHEWDufOu4ND5DD5 AXmWJMj+TgV5lUIFV3z27+vZX/T0Qz2nunT8dkIXdMq3HgaNzo2x/oJwgl9v+SOyphkSS50BSL1Y TLO5lOkzFOCKYrU+1LuyHe/416d9p081rV/xrvbrC6seW95SdvHTFWV1CwJ/uG4cq/t40xufeWYl D8IcWH4w7pvYY6gNNP5w4TLWqKfXQmDvb0H9eWhYnTNqHZGP5Z7JIwAP7YCHdke42dicu5rs5lbn fsFeUNg4s5Rf6o8rbWyLrdXXntuat1ZOytt9rE3RE25aVkRf1WanK1Lvr1dO+U8pRJe/S9no36hc 9V9VyDAT4gL+gBLjIko1U83N9VcoK7hmpYdb5x/kXvDvZ97kfufPpBmaI/2k4mScnOin/ArDEUhq cKhOb6TDgToc+xy4YwxvxtwQMKwrluVG7nzBgC1AeuJUubyRQqSixagJbUFDaBh9gEzoG0J1xSwE IvJDtOPmpIQkNVOKSNVUMMdVAD1jGQZeq0Y3rVMH6Mw/l3aj6iWNhzF1VnyRfnpA/rCGV+m02hW+ nQhfm1pXha9BA00lTAp8/FAPt/wI1ONsev3ySGbMD+WBBXYfHbHpu7Oq2RbjvLYYk7rM+rOvVZ6F Z1yMcehXCpge/sW/A8ap6SIlA/0fRjawe2IKjykYLySRSClHZ+eFyOva1//Kq3NqIqPfNPVvuHkA CUiitM8z16/fWDUjbxYa/mTNi5PY+9oN7QK65Hl1oKc+UuW2Fcxu6Hmn88OWbz/mup4u8cci2TNa Vp78ee8/nkFI108epMEo9CgFZKbMoAuJQuNiupPuo7fQFImMeDZhwCnMREuSi9hgRMYRlK8yJOVF hdgGvUtgazXwi/FOvA/fghO40zTxdrrq9Y2Hcah6iswmyuA2r3nutXQa6FyGEhDfJTqXocvaIuIl rZY4fefOvUfgZ6smvyYKiEdgnixGtWob5TJ5jLLoWuhe4KnKvmi5bKWjzkrn4zktztacZM5W5y9c +12j7j+7/uJmSZKzi6RTDJLT7XHnWjyJ7yePkmdI9v3IFxZcDhQXWfO4gBouiARUfy7cnHKkI3A/ gAcqZV17hbw5MkdGmGyRh+W7MiHLeWgmpsJTPb9xbKlP9VjLfarbAjeHK+IbwVcfJSiWY/J0X4fP Uit8nFrhG3nwDVUVMqYV5Zim07lcPIvdx+KASpNASyovRlhXXQRFmuA0Xi6EaXbmdN+TErosoTrp SalDMkjOme2Ppv1/FWi3azyhI294andtArAXOCsMhQW2Sik65Uvh8QRswYkMvGWq3jDTgu6CoDLd kQyCKPlS4QDjbUp8pdHSqVxAeiynxlt4FC1BzZPhc5+cGKk2uLO1GxkWyrDg9cTrJxt+tfVPNYs7 qh9Dy6M3AqWNc2vmzbRk4P8s2L0tPnhcG3lxc42n1GmqrDwy8MRL1Z5sr6d+3mztnK3YESyb3VCc Uxpo1lOiH856W4pHPNjeUcw2eUctyoiVuue7cVsD2cA0iA2OuOffFFlCzOZmZ5a45xHVXHXmPPc2 ahfNsDzMqJgLSnzESAl6pTMzMswYI/lMrs5paJplOm7Igcl2usqiTqxP9wW5fKqaXWWLxifKvqoF TpmiFEjR8rJUeqJERaOa0UK2MC1ii6PdY0zEsUQYrNwKtbNBkkLFgvZM6NAHTNaPnJuOnNa0idFl h1VbpKon8bPnW5uTxrGJW9u069pd7Zb292XxPXjojbrOfQeP/Wav3n1L4d3LQedO7Kpa32iO22Bg Nbfb2v9Dd9XANnGe4fvuz3f2/fnsO985iRM3iS/GUBPsAIGALyRNKV2VUGiEU7KEbYVkmyDQImgn ICqMH6Hxs278NS2haxfaMZWFBhIYA7ENJm1TUSvYtK1rtdGFiEagKQJWYrP3OzswVC3S5b2fz3ff 937P+zzPq28wXjb3k/uFi8pF40/KVWOEHeFGfCPaXdY30zdTW6Au0BuMtNApuGapM/QZBrWOWSdv Y7bKO8yjap8+pJ7UecnBX0ESxwHVn5QSIr5jhpJi3p2IpxFNuCFnqtdD2DCUsGEckdgDKDwN/EDD o5KAC+G7KEzERXwihhuhWQgWuMJ+M7gkl8pnMK22PjMaAzsCvDrWeg3wmBmLxSDm2A5y6vBaDlbT ZzAYddiTABbpyuwN6ZuNnRs2fadpuYb8sbE/jmRvIH30wufkF9MWLd773tme51fFf3UBRRANLr+8 D+NmMeRuWR43e+wpappNu9NqDi0HABp3eb4r1B0iZ1FJYZaWNBdQ9cICrd48yPN+By4ejBpb8rgk GbbCHYhKYgRhpMgyEdyNsRPmzKIlNQ9WuPp2DjEOh+W8uqPxgBWxk+10d6o5tLCt6XC4Kr9AcO0B aFX+Fyr0suy92l+0nMrey17ofxWZGTVe/8qy7VtWfGtbz/NpZIHWScj8EamMd733tZXvvH3qyGFY by2s1wKs+IlC9JMhQoE6afBUH+QPifuUo0yf+wx/RhwMcpwfzSefZBvcjaGj4kn2ZPCS+3fCVfef hbuuO6JYKBdqdkFRUrMlb1LWzmkfapTmoCGUcqIUgEj+wAaDpTZJ7RIpGSrW5JNmQRIlVAKPKSpJ OvGxaC7GpuSiUehEWwayhH6HIBSYdpsKPvelE7RHNXC6yzwuIoziWg5E8VBbaFXocIgOyWHOFuUk JDzPdTGc8VYMqjHcGIEk237DrvCnDDskwz8gWAMzsaOoqYwj2SpMAkY4BhsGqXkixrF/YiiQqKPC zg8IeKBW40n3B3A4foJ3z3Uua8MpaDNh/DVMoa3O5yUbsiThj0r485INySKcl0JrE4uBcQAnmMDC Bv1bDGGIl4CsY4wTVNgRe19O2wPkl8iYPvJ+9sb3O5H/41GkshmbenXZvBaLWt+8tKYGoWfjh44M 7P0EsBDLXsqe3bBzPvruK5vq6l7EvGFAAfwLXJ9ODNrTptNoEl2ilHjTdLfBcPQ5g9R0L+lXda/k kwlF8iFCIf08J3tQm+e+h/TgjXCzyCvr6L6OdHwZUuC9t+DVrM/v5hMprpFr4iiuQol727ykdxDR tij5IqS/jejVz+ukjjHBC0ndDKwfIjuJ3J4BpY6Duo+3gtyb1wgDygQbZDhS8K96mgx/eSHyJRy/ Mw0aFMwKWkIrBXotNXqqD65d/2Kkbu6cqo8+yg730JGmrVsWlf1GqV749Cfjp6innNrPLqTbHX8Q R9Ps9nVF24pIVRC7KreK3ZV0CQInT01FCTJB2aiOrKPSctqfLm+ONsNW3fXe9Xlniwl9dkViMhhY /emK+sm3hEzAvQv02COInkmCaEl6QJsiCmDBjDKM/wEH/w7MJa8DkRMeIRcrJuXgX1qei5XJXBnw WoEj6m0Mppti2cJBck/B6fZoLsNkJ0U9kaCBKYc3zWBwdyWqBAIatN1EoiysmlMfcM9Ynn2UUSVz bUKqMmNrcobyWuxh84cP6KImZGy1w01yp7+zfEV0eawzzmIlCzB6YELcq4Cm8iANVIWh+SJLS8AN +PwP+eplVMsVVTSvnFHuEzeev7rhGwid+203cs3tOrM7++9/jG9uX7Fre8cLmxusmVoorFeWfv31 YwO7ryAPCv78x+NP/vL0t2uGdknk5nffOPLmO71vQEp+CK4zDdytE/12TEbFqBpvljIPzfP+Hf0H 8S5GZ8rIJd4OL4MQ6fN7VR/lJ5GMU1dEuXi326+5dYLwuCMcb5eUJd/n0X0e8ZBMSLz+WFlyj9Fr kF3GLYO8aSCD8Ed0zaEmGNuroVsa0sxAKpdecPy4vwO2gbPb+SuH43GbNwo5DTgeinM8KzA+NgEh UgO4Jh1JY/Ep+tn2s8t6GouywyUL5zSsTGShd8t8fnh+1/bdmb1kZV9LVf2OrZkvYNGA39eg2I7B KQW+e90QwcPMUl53yuabeLKbP86f5y/zN3mmmG/nN/G9cIOhWBfB0BQolU1cJj6DX7aC72EZ1kW7 SRfoooO4cFmSNrn8uh6uI+WUIMUoeEU5J7gm5sOThuM1ZGaHkUmfRHR2/N4COnLvL7BDD2e4aIhg 4N1RPD+miSG7mePMeeYyc5Nhipl2ZhPTCzcYmAwFVoKKIGJiJoRJf2Um+W8nct9lTn/ZAN/aSBDs AahmC80eIqLw61b4FrCnoLG6kKSSXNJIltaTT3BPGPWlQgkVjy7i26Pd0cPRt9k+10+FAXZAOB69 HP0sKhHReLQJHpyLfhplo3awMJmC627nIeMK065gEaa7frcr7LAe7VK8XqugsDBiuSGdshJRvXZL VbsXrYLkDJINthwsiBQVwr1Vhai9EBXCvQ/KIxELO4V+grAc8eRTONrTYd4WDLXsWjhq4CizkpY9 a04ybn1ofWpRslVsdVsUYZVYU637Fm2ZFf+smbD2+fYwV+U1t0GngEpvr27FYQKOigPJ1CgUvFPv kM81MUynKOYLa9jYBxx7H9AdeFoP4PkQqRsRtfP88n1TG95auvatCsBrkbVwdsfj2eFQanptx5Ts MB3Z++7i555b3La0/kAmTba9+XjN/J37siTZ8HrL5IYtBzPjsGd7cQXDnunEYdtw+QK+Fq6Dowdp BLul1HP18ojCsE65el2SyAoeD1gsEkV0wilXAt2Hl/y/cnV7IoKE8yuKwoOqFdAt4OdHq9bJ1FcK F+eo5oE7Cz9Spk6SoHjpdHa4bGH1Uy/FAPzMzo9bDzUWk6FjL8xs2tKfLaYjPR/UdWz5Hq7VZ8F3 HYKViuDS99vzr6Nh7o7vjkZfIq8zpGoyJk+mlWZfs5429pMH2APcfmGQv0L+lfkbf0UYZobZ66LS x/2e/AP7a+6iwKzldrBbOMrroNATwCny0y5/tSvYXtBVQBZIYeIRW51rTnJmc4LR+U7lv3xXe1BU 1xk/575272t37927e3cvj33BsrAgKLviIg3XFFFBA9GgokMxRrHEhEg7VprpNCa1QjSNrVPUGI1M mkmo6UQUUqGPGdo6Y9NMp5kmzlT/aJkO9uHEBjsUtRPu9jt3MXHstHd2zzkf3Dmz3+v3/X5dwDW7 AwwmcI47vCkV3EI+DYRJUbz4Puxef2j+1C2cst77+Kh1+xAOH+vpGRzs6TlGRV/C3CHr8ie3rF8d yA6/Njw8dGp4mPh72HqKOQ7+eoBXnzQXLfOu9lJqis7IGW8qr4FeI6/xNuTdzeOJNrvHt+ccd/Oc 0D/36zC/KHrcrns6TCl1udxxj8cm2OKDSmzdzTpIpGf6v7SYjbdkhhEtdh+/Bv4AmSQ+L4gxQrE/ 9/ow5qrfeXICU9anE5uPtECK/S93bX/h4BO7BiC1rTusP1rz1px1tbFt/u/0xOjbp0ffep1w7K3g +3bwXUEF6LRZo9ZRKTml1eU3UQ1yg9aU79wTwgVOn55qZ9uFTfJGb7vebmwseFN4M/8OPyff1iQF ufJIEBjRlxOjDreHC4CQKFRLQVHFFcUWo/wRD/YYodyAn7vP/9kH3E/2LgSgm+0WurzdenewqwAC gBXOHtw5BUUmN059Lq/oNTVvdL679xCmJ598tQ7T1sy3d3S9eODxx49aT1H+VRsGzmAPRji0Zevp fzfSYz848/rIuVffIcyyHyG6xs7+sJk4zmLehTewXexelq5UN7u+7NqjMgLvlkISdUTKSlS91CJR 0ji1zyx1OKDDaYoTEoj38FX8Hp7hjefUMyrVqT6nnlM/UBnVg+KYtiuAovbjIUzhoFI/gfNz9LH3 voae6wiuyxFICAb0d2ZJrhh6UfOIvqF5JP3ols3nhSXLoBIidld/RiU5BQ+Rnv7i7oZt7ZtWfWH5 +komfnx3Q/pfi1actW6Bj1XQ0R7wsYzqMV/jFC7mLNEVPXZCPaEdLxks4x1ao0apP5UnXJcj12N3 5LkoVyq3yTvlQfG4+lZ0QnKsiJlFDfFd0R3xfrVfOxj9VhFfE1/JNYpNcou7MfJw1BEtKonXSOlI OpqOpYscnMAqfCQgl0jRaDTmKIqa5V+V+rSv+75WurdswHeg7KRvsGwsOhaT9+Mj+kuBV8p+WDZS zkXHs+8TfhlZ2MGeGi0sIvbUaKgoZwcN2zbz4LBbxkujjdET8vejl6IfRblIVJIZxkALDBZVEy47 qlfU4wWxY9vR4hTZzQKYlwhXYRO3YmYb3o9nMI2gUlrxNszYb3r98CbG5h7E4E5mhqGYxoToN+Fq f7Vuwr26CZfqZrompZvJRbAUl8IC97r1kN6pP6MzepthAuK7DdxqZA3KaPQ69IjfjMRSfjM/lAr5 8Z9Ak1Q7I63FR4qpYjNQkCo2ysnP02G8tpbjqnJcWY7LCyNV0EPVOIIWRrC9wys5AsLLQECSfeOk sj6FsQokuvfmwqhI9hILBi70GjCj5GzHPSJNzNnkwjAm0k/PLOjFZE639MLT0WGLx6LseyYvqvXu BCyQgY9/LGckTcqQ4wUpA7m5cV7M2AIRg0YE9PYW+23anYbBXAIFAgqINC+bE4U+DdQGDG4NGjte hQ2154mna4o13xrrR1u/ee36tY8S1m2lc/MzVeH8OP5F++bZT67O48rk+rZEfmXYpynND2185dDP Xj68+KGHQ/5YoS+/q6n54NHfj0DFh7J/o77HnoYJ9luzNIxAIAml7lpXk6vd7Qj6UID2+5CuejWs q5SGAzTvEBxSgCTajfQhfUSnt8E2qdM6CMELPkwAfhT5OAfBOJck8pVCJQIt1gkdTaRiIkDHdbXN V6+d0c5p9DZtv/Zd7QNtRmOR5tHCWpXGaEGjb+ge9WkeqYGeXg49PYG07OSy9pyOnO2o88zaOhLQ EPARXp0G0qNUL+jIDgyiUbNjqpOgxSGkSixdnS5WqGcnxZL8kqbA9m+sfTYj8s8/jw0mPmU99kIy P+9aWfWjKxcP4t9NffiG9SLE5zuACBuYOLCZU6a+SdmlHGNpngtydVSd0kw1K3+lHLb2UBjRjwSf pgk859XiPh8iYOby25zGj7NQuP+H0/DOz8iME884sfN/S5DcQHiAy3RE0pztZhqIjO320qXkSD9S +/Pu3WfX4mBoff3qr5Th4Jm27V86e4wasgJTO5e37J3Gk0DqwU8RWNsW8FNE/zB9bMKoTDnIwpHF SRZ6PPuHUdhtORE2alMnGczRotMpSCJoJkqlDd4QoqhCvCxK0GgzZqIgnBIQK2ooKBajMjGFasV+ xItIYESB5ykKc3DmMzK5MZCfSIlySK6STZmRdd3wCPVCi0AL41SVKTJURmTqmRaGZn5CVQFF3G+6 pTTCYQAkGgelS1AvQVIwycC6mx0wKTqCj6zc2fAX27YZMqHHagarGUKMe5MwL0jrwRPBEa8OcrfG G8H4ovUYLvl1rc65PL/BEQsCMv/nd1f6KyqoQlv78KBHlkGUJHzdXIxELCCOEhwsn4f8VCGjsIZD 4wsFRZLUJJ3kYmKGznCr6dXcCfoEx7uIn33lqyAoIsOwDC8KjJSHDMbPanxQ8ElSDCWYEraCTwgl 0mJUwz7EN6JV1Cp2tWMNvw/1MfvYPr5P2Cf1owGmnx3gB4R+6Sq6ylxhr/BXhSvSDXSDmWan+RvC tHQX3WXm2DuOOf6uMCdVsOPZD00+rzbFxGHhx7PXbEsglnTvf4hYHAHLYC1J+KQpw0E0YfmlyLDh 8ey6UU7gYV9rLqGRFBY5mpYQhRmJZgXRwTs5p8PBsgxDkisJkGUkVLrqXZQLMupcwWMXCkPInkYi fE1EY9dYGAflSxPYyA16I7hu3gjMzxvB+UAugyiXu/oFieOpIwInAx/FXpGiZ2wIRjkwtTEVgBkR JB4TTTkD/ty5IGfAnTsAw6Ipkb/MAAzTuQ2sqQsisabugTJ52gmnIMXhJR8coWncbo1g5fJF7D7/ PvZZb1v/vDj2H/brJySKKI4D+PfNvJk382YXV/HPbn833LbVTa12MRGhDUnM1C5FCUlieioPKxQe kqKLRR0KRLZTIIGHLrGGmnRLoo4FholUEHQLJErEdO33XEE6FHUM3sDnvTfzfnOYee/35g1NkGZj SvkxbzxaO01zxEeZ1KUyiV1P3Y6Jl9zIiKdsgc2KRb/liG08aMfsw6hzmlkHu8ouCxllcVHL6kUT axEZb9leFu5eHhWVMsnrZSNvl8+50ypP8Q7Zw/vkABuUw3xETMtZviBXpd/kQriylId5pUzwI7KJ uyU8JOtlu7wox/gkfyWXuCvoaceLgip/58Zpn8rVxqDEV5hkXAquxpAqB65jqjcxUVGVXDeZaqYK SiNJM2q4xYbhWrbnbXYvekw1U2XU7UVhFQOWbVm0z3NcSnJryujL2gmXqpTn9J70P/B/9Jt+U102 Ep66XLRIr4v2k2EcAEfvVhanKWu/fQm1BTqXNlqoya92VAxZ1fF4Oj40ODNUHdxsMfUxhiry06Az ne5nqkiwjfFjavR87FruHjvz7AVryWXYrdzY3LxRbpi5BRbJuWuv2fHcJDaPS3/G3mwxzpHPvzKT pD+PXyHLtGrcAATFO28B2Qx4A4CP4vwUXxD7O4EuoLAFKHLIw98rvpNXMgyU9gBlOSDUDWwfBXbU /btdEWB3GAjTs+5pBcrPAhESDQL7lOktsShQQR+Uyhkg/gTY/xioygLVI8DBm8Ah+pFM3AWSE0At xdVlNE3TNE3TNE3TNE3TNO2/wgArgK9owAVYMBBADY4Cdtv6Okw6p34q8a7jfuP5gobvTsiBOkY/ NexUdfbEh/crK6trgWNON526FK/uwE8BBgDJiL86CmVuZHN0cmVhbQ1lbmRvYmoNMzkgMCBvYmoN PDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA5MDUgDS9DYXBIZWlnaHQgMCANL0Rl c2NlbnQgLTIxMSANL0ZsYWdzIDY4IA0vRm9udEJCb3ggWyAtNTE3IC0zMjUgMTA4MiAxMDI1IF0g DS9Gb250TmFtZSAvQkRLREJQK0FyaWFsLEl0YWxpYyANL0l0YWxpY0FuZ2xlIC0xNSANL1N0ZW1W IDAgDS9Gb250RmlsZTIgNDAgMCBSIA0+PiANZW5kb2JqDTQwIDAgb2JqDTw8IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlIC9MZW5ndGggOTQ3OCAvTGVuZ3RoMSAxNTY1MiA+PiANc3RyZWFtDQpIiYxWfXRU 1RH/zb1vP/JBsoGEfEl5yyMhslmxVEIIiNHNbgOBnATBbnKi3YV8bEAkEowJtYrSHtpHilBPPUKD ggSoB468hUADgh+tVitNteqpqFjQAxQroFA9lOPJvs7bhJj4R0/f3ft25s7Mm5nfzLxdEIAErIGE a0nbKnXmFfdxPukCbJWNLU3Lc3t/uILpC7xnN93b0Thxf+tJQA0CGQWRhnD9K/dfLAVmsRxFET5I TnXmAkmFzE+MLF/VvuXJmJP5KiBFv3fFkvDlsovHgGlrAMfc5eH2FnsTdbL9X1hfbVnZ0NK1ueEp IJt92H9iO4Ls+N6FHCUfWYD5T97nre9Ys3nJksVWmJ+KT9n64OAeuI7iJXTiAHbxisJFCurRgfW8 XsG/oONZbKIetGI1upl+gY6JFtQyCplowR9xM0nzbezFT2kU7BiNP6MPd2GT+TiNQRKy4cNKHJZv yPfNSxSg+yCQizIswCF5CSdIEbfasmytphc2RvZP6BPzOO40ZGA65qASdRzTbo71NXxEBTafeQpu lOJO9tyBDdiBN+lx0SAeEN3yDdsic4vJXvhJTuQjgGbWasWD2MJ5fEGJNIZeobMyS+mKXYldM7s5 80m4BbfDjwc4m1dxHB/gLP5Di6hReMRC2aLYlCZzrNnDMY/DVMzlNR+LEMJDeIQR24qo2CE7Y6/G roK4JyS8HPV0lHD+tYxVHz6kNMqmPJpE5XQnNdM2+kY4xAzxqOgWV6VNFvAqkjvkQfmxPCUvK+VK u3LOnmQWmBVmxGw3nzFfMj9hTMejAPP4mXW4B2HO6kE8irX4BVeri9dWPIOdOIReHMYRvItT+ARX cJVSaCrNpFnUSPdSOz1PB+n39Ba9I+4WYfGs6JOarGXf3QqUMqVKaVXeiSFWHOuMRWN/NVPM/ebr 5gWzn9Ecz5jnMaJeBNHAnn+OTdjMHvdgHwxeR/ARTuIzRi6Bl4vSKZMm0o3kpSlURFVUTbXURKuo gx6jDbSRNlMXGXSAo3mRXqMP6Tx9SVcYGYZZJIlUMV5MEIXCK24SlaJJrBMbxV5xUBzl9bZ4T5wQ H4mz4rK4JtNkOq8JMl+Wy7myTq6Q7bJDPiz3MJ7H5WlF4fqlKgVKofIzZaeyT3lL+Vy5ZkuybbA9 YXvKdtZ21g67y36rvcoesf/G3mv/wCEd1Y5Gx8OORxyPOQ454dSce7GfpyPKmQ67RB224116Ef+g XTJd7KEqsZuepBSZhWXyt/Q3WwV+KWYJg+aLsfLf1EZtyJDP0Vf4CoeEIk6QR9lN23CUJ6lTLBPt Sir9SHlO6adVyjuKFGewS1yy/NjTld3srQ2g5TSbqSYsx9MiHcdFN1fhfvwBT9sTxEau++PIF+WY RnOs2ogv8DlPRxrdhqU8J/20w7ZKbKfV8rxIxl3UL07RTNsqNNpdeJQOiEp5nM7w5B3lfqmgiJhB i9GPc/QsnROLMF+sxQ6lyfYefUweqrRFuP+gnJZzZKMYI17Ad6996OFJ6MM8+Qbq6Nc8/X3Cgzli BbbKY/QZeughpUlGOMp2odBanoW9OCDLlSTcgR7Zgxfpd/Lv5ME+pZ3uoydMf//d+Nq+S3leRm1F yg3mm7GTtJPeNo+Iy5huvikXxZqoS8nmuXyIp3clI5SEPWzfxW+MXXAylcfzuIH7NYPfbQk85QF+ c83DPXSFJ2Yto1REBagUE7BM3O5Q7en8tp0ElJaW3jb71lkzS2YUT592yw+mfv/mKTd5Cz2TbyyY lJ83UZvgVsd/b9wNuTnZWZljM9LHjE5zpaaMSk5KTHA67DYuIqHQrwVCqpEfMpR8rbzca/FamA/C ww5ChspHgZE6hhqKq6kjNUtZs/E7mqUDmqVDmuRSZ2GWt1D1a6rRV6apvVRbHWT6V2VajWpcjNPz 47SSH2dGMeN2s4Xqz4qUqQaFVL8RaIvo/lAZPy+alOjTfA2J3kJEE5OYTGLKyNRaopQ5m+KEyPSX RAWcozgqI0cr8xvZWpkVgiHz/OF6o6o66C/LdbtrvIUG+ZZoiw1odxipnrgKfHE3ht1nOOJu1GYr HaxXo4Uv6529LiwOeZLrtfpwXdCQ4RrLR5qH/ZYZmavPZH3L8sNH+4Lrhktzpe7PalYtVtfXqca2 6uBwqdu619TwM9hW5AVCeoBdd1ooZk3hQKzwrVQGkmrQ/NZJaKlqJGh3aBF9aYgLkqMbWNDh3p+T U3rYPI0cv6ovDGpu47ZcrSZcdkM0HfqCjgPZpWr2SIm3MOpKG0AzmpI6SCSPGk40DMniVFzdoioW DMFJVkTaHG4DQ12iciRBjRMptm4NxdCXFLMaXzXEVkY9l6HZSPCFdFeJdW7ZG7Y8l6bqX4PLrl28 MPIkPHhiz3N9DYu0mmOowVh+nTY8HmPyZKsvHD4uJMc4O85P8xa29YoircWl8hfDh6ogm9WUTGHM 3W6rqut7S7GYGWNNdXCAV7E4dz9Kp3hqDBGyJC9fl2QssiRrrkuGzEMat28PrH9nGYYzf+iT6ho7 xh8pMWjs/xA3DMgr7tQqqmuDql8PDWJbsXAENyAvHpINUsYYX1DmikFK5Mq4lDuxbkjZYoLJhpLH H3u8k+t7HU5uxfgJqQHDFSofuNckut3/p1Gv+aVlFf/61mwwTKPEM5KfOYIfEV6yLjlgJV9ULKzV 9cQRsgC/d3Q9oKkBPaSHe801izXVpemHxU6xU2/xh65XtNc8sj7XCHTWcBIRKvEy1Ay3Y3asEj7n y9983F/h3M3/IhzDfyjkdnu8Jvy7NmNot4r3KUlpxY95NzvG4XXbf1mvFqAqjyt89n+jIojP1DqL iVqLoAhR8JFyMWCMGIkvUNSYALWpj/igsRgVsbbV1tFctbGiaW2U2gom3oDRa7SRdJpSndiMaTDO xKaZUSMCSpIxUav49zt7HyI6ie107nz77Z7dPXt2/7Pn7M2hV8QavBMr6FWtwt2s96ImYy/5MXYw ZLPAS7Rh7laM32gUiUHgYmAhMBPYAFQC14Ay4JcY/zzPZR1hFAnDkbTAzHE/xHrTzFp6E5iO+gzj LM20hsGOWsrhuQZRBuTToWuiVUF5kBei/zBkU8F/Qvtp1L2Y56L+V9Rv2esFQfdR1JshT4KeSOA1 2L1Wfxtji9wSrULEQWcekIE1isDzgDkYx/sYwnJRS4+IWtdB/2jUh2L9R9X4IiqEjkY+M5wJzx/P Z4l2Keo7YccOg9wW1Anoj4w7F6+II9pedzL2Xx7YN1BLR3jP4T3B/qBNdyNg45zWwJorWuO2bXeh tA3e1JNFJ/A2wAN8TztB841x+H5naax5niYxHBI9cE552OMlo5CWO+S+CjtfM/djHtphFFGW8TJ1 0K9QKvpesLbQ55CTNhj4iv6gNdGLVl86DP/Khf4yYC90LlG+UEiTMX+g0nMe/6WK6BWA1+4XOic+ G/xRK7fX0yqc+02HfbiCTgOnRK1wAML8UqxfzGfO313ktNRDzwSMeQboDfkChSJqj7M6hO/6Ofz7 NHStDfrhjNtMM4J+GwbbEILysyDU2VfgzVVBNcAx4COc2QZgDOpPAD4AY4SDtXvAj/opf4XP4Bz6 Kf+Ab7D/87dSPhvYw1TlY+rOCBPzu0PPVmCPtZeWAZXAHoyp5/vCPst2hnTznWKfCbHy77n0hlah deZ9sk+Fme8e0cLwHYRvhZjvHfs+s+ahVHCOnkzD2GfZ30LM56Lsx33kOxHm23t1Yd8ziutoftDX S0PM95TPIsxeylXnXUX7UZ9tLKZ8/aeUafyDCrVb5DNT8S3nuiW8N62RfuzU0AP4ltlol7XhrQy7 Tswxa+iyOs86+g14kVGnPWjUCdOsdC+aJI6ZlVqJqt/FbSFqAn3MjNZ9/638f4F2yqyk2ag3mHWu i/1s4jthN4pEIDbEkFcBpUCcM0BsdeYKvz2Foi2iKxbfBQ8NNz2UYtRQmtEVcYCoL+RTzI/peX09 jTAa6fuiFLmgTrS3uyIHbKEHeC3tFK1msH7wwlZ+dIfPtfWlEIf8tS1zzA/6lOLg3VtxDx4GnxSc Gzg+q/yAGK2g/NV9Luyfxygf/HjIP+/0U7e2lX82QW+Ptn7ZllVuQXwP3VO+G6H9c3zkGMcxkuMc /tn1D41vy7fni2TckzIVh09QXvBu/wrYDBSgrx/s/AT3fxnHMqz1gZVNBdY79Kz+bcq38rBeEz1t JVNP7PtyOKc+5TYF82lSKJfyOaG/KZRHzURyVDx7l3JVvHmXElQehW2cP63fU4vVjezg3Ga+h+oO LqJMzo3GbNpibHIvYh+/1d/AeUNu5NJPVB/RSP0z94SR79ZzTtQ3qxhUaLzkntPPwfd47lPufPN9 etkaQYVhfTwGzDK233qLLhjYo7lH5XxvKB7zt3fWuA32Gez/bTpvHMSYXnTBPM57wRkMUXuapubu dFeyLjvHPWhcpALzEGSAmrPcbQyeR07rs1A+zGcBndYMlbOPmifRV0Af2TMp187Huovogt0dMl5r Pb7/QPCP3OMqX5civyVQof4FfGue8sU55ir3Hd1PMpSH9Vrcu9XuaXM5+AcA710x4j7uj3pvwEes fXif8XtiM3J8H/q1VU5LrfdoqXGNlppnMX4IpenNuEcG6qPd+mDcztQtyK8i5sK/A2+ZwHvGHuOe tnao9TKVDfxOKaIV+meUqx2kNMSSCU4FfGWGytPr4H//Ai4HQH8G0oJ4PACtA/pOwkdfQHuHHi0e QX2Llkx/1yqMbpBFcc41VtEPjRxK0gcjjnTCm+Ik7RTXabseRa5xnLYbfvpQXEee7Exf6j6apO+n m0r+Hi3AuAztfRppbEX8HokzXEv1xixaqb9ON/QPsIfZiPWYZ26gy2YfSsC5b9e/EA5DnKUGPYca rJ/Tdl6PxwFHoD+fYYyhBDWvFZStIbSxWcuiYn0s/Qz2fop62R32wtawnWvpU2XjPexTdrBezOMx xnZaTeSeAfoG+NaEVtztPnCmFccy45uWc16wShDzTiH2TcObJYZKofMKUUs6cBDjpoKbIBuB+kAg FfUIyJaAq8EdgdmQY4z7F8gyjJ64K4E4tQyyOej3Q34c/De08W+kpZbo5iWgYwAtXcAbgeXAJmA0 QAG+8c+APe6T4BLIoO/mS5hzFe1k1MuA60AzsANYhzkfoz8eyEK7GHiWffuud83/ne+dz+6XOW6x neBU3MP6tjnpvjn0Pb+B2+au0Pf/Jm71Bm3DgXMI7aNVLv3anBliqEgM/ig9hlZqu2kfcBRoBgxK RJkNzAJ08mi7q15M9vhBsxRVj5+QVMo87okk1faMCXC7yABHDA9wYjKPK6/OLOZ2eXXS8EA7bnCg 3adv0sr0aK2cBBbmMgrlICANWAkYWLy8umuvwLSILjxtV/W3eiZFHdV2YcQuzNulTNzlaYfumGwr 29aa01NEI7TtUOVKVc5SZZoqB6kyKtjbwKur8qgq96lykCrTVJmtygWqVOPFJfya8GvEr0E0eGIo XpAU0fEiWgpPvPBIcUhEiPZVD8uNftHek/KwHBj7qEwCkmMfk/FgCSyLGyMTgN5xGTJFQC9FCI0c 6t4dnyimk+Pxi70Hb62JbFkTSRF+kVYVN06mR4jhSIm83FBgG2BUxS2Wb2F2rGoSxWqVVfJGgl/k VMl/S78jquR16deEp7O8Js/Jq/Kw/FKOlcfiKuUhjNpWJf3Sb2DU7+L8WqUnSq6TE2HcOVks58nn YlXXvN4gT3tZgEl5cXlyaqyfVxkfq1Z5TELNAZmJzow4vxAHpEf+QiYnqKlJPPWAHCwXy4FSLRcf WO67Adv6Mx2Q38FiD6pVMuWUyIjIiBTvGdv7R9u72/aW2N502zvC9g61vUNsb6LtHWR7B9jevra3 l93FiXGinY5OB6ed4ziWYziaQ04Xv/uJZwBedtTFimZCWkZpqHq0xqXGDz/8hxWORmPJ11nP0rIm jRJZvpoCysqP9X016SG/aDchz2c+NEr4YrIoa/KoHr7UAVl+253oSxmQ5bOfnD71dSE2TIPUp631 C/oP41UfG8VxxefN3u7eeu293b2v9fns2+OCcXzY54/12Q6X3AG2ISaQONDEB7mWJEoli0bEBdIA SSioCNIG4cbUalWBnT8S0QjoGUNim9CY5qut0qgqiNJGfLQioVXlpE0MTRN73Tdr8xGplTp7N2/m zU/zZt5785vdVZ3DUMxUO0vy+uLOEYxq8c49JUxO79yTzZLAk2kjrd+lNbe1/Jdq7Wwdv1mM+FfK svs2j2CUO4fEyJ0idldit4d1e1jXKM33LVvZmX+lNJuvY43p0uyyfO9K86HOETgCh1pbRuAwE9nO EW4+HGm9n+m5+S3Z7DIMjYPDtD/CcEeYQJz7LEkzHL6RnHVwLpjBxRwcpt0MLmCSmIOLBcyv4Mrg MMNVMoG44CVS5uDKgpduwQ2OxlpbBmOx63ONOpjRmbnyKQcSiSAkGnEgeFQiDiQC1IG03YRUzUKq b0CqHUsc3MREZjBF5nVMEbMU/7/KY4vi8dYuliv3dQ66yaLs4odmZEB94i4n7kXFd71UMkp+z/2d yPFsviC2KC/HFpF02oirKUgIhXkBVSL+GXpB1Hi2BD/W4KCDLkR10exQ1cKqhWwIs5cNKaj2zA4Z zy6IlozCwdkhFdUa2rhlnRs3bsJCjNaulhu/DbNl06zcSJblK1cuy6c7VncOimJrPrO2JYu6mus6 WW4dnh6bUVajMsWUHHcDeEMnSbNA9Mar986HeyPQiEvIxjfgUtDQrR7cuIEdPHab4YMULpL2QQon MGICfuk0HiW8axiqj3GkQGSN40CK3QLPxinhYPGQtOYX6MlrqanUCnUitXwqRdLYViexqq2JalFt LlZ43MmkyY1NZnjyJTFdY+y8H7Y7uBX8aaKQZMazXzmsUFEleuEK6v5cHIarQ1T5nAzDxHFa7Hl8 ixHH6ZdPjKv4G8fo1dZADqhm6Y3JxnqBUL/qhfb923Y8cHLPJvvLJzfYHdAJ6z6FF9/bfe4Z+w67 /bz9qn2AwHSv3UEtx2pbRusqgF5lgAwonKIieX3FbqawcIWHRmiCcjSkDsPKwaVsEddyy8fZMqZm F5EDXfNRURBjSaI3qBz0Hdi248HX92wEYdMG/rR90O77zF77293nnoV34PgFaIeHce+j01f4c7iK EtI/1OcGL3LkkEezHK5UFM1STVWzNLNIswymqpU1y2X4DFruS6tt3FOqS1V8AX+xqnualRdkaO5h /OnSq2SuuMolka0wTB/O+DxblUBljQgJEUQrrCwutRazLXykTuS6l6MfJ9CT4+lxvTmRu6xOTWjN ejPoWDn7crKD5CAokJhJNNWbjNa5gmJ5ecwUBc0XqK9Luk7/8iF74AP7qv3ux2dgwd8gGnyt9Phe +7OXey4c/fE16iqx7Ulogxp4HrgrX5zW+vd/8r794V8+fgdzjqzBnDvKjxIPMckLmfagiZsMs4r4 TF+NL+9zecBjUry+wxEoCUfMBCRMcQkPpqqWEcBXaIiYUYAKSr3NarTCQ9yhSnfHHIyVmNE8JIE2 2qJPAIBK2jqMeCKeygFmEQYQw7gc956KT5HL6XhKnSIpfld1/Bn1rdoa3HIu1x2P10O0LlhG/T4q CKIQm1tfh6mGT7LBKp9XHouugToY7V/11CsPrDt8cvsje+0//HX/lnuSS+64Z83Ta5f02VP8aDDS //G+Qfv8+WfKgi+X6rGq9ke+HDj6RiSI0VqN3yFf4O4N6spk+kOQ5BrFRimpLhGXSG3q3XqWW6N/ i3vc1eVeJ3UVdhWt17u860Ob9W2h57id2vf1n+nn9Iuhkv7QxRD1YI4cVUzh9ekxwuPfNT2WiXEu nqeC6HbzhUWKIntUTVO8Pr9fDwQNw79bcUvm8PRjQ7yu4atDReZ+P1CT8nyZ7vfpvFv3u7GtKT6N p5oiFRSUyYpPlhVMszLD78MZeDD8q6mkbHVXuCkFaugVuqbJckFBBXFLUoHkHoZNx3n2MkWHYUFG RXrZakh+v2QYvbykKEhRQ7fHLUf65zoyk1JUS0nI/fLPZW69vE2+KHNyIpQO0dBvCnARWyVZ7pVM voena3ng+eKQIvsNVQ4awbZDzv2sppDVizWW0t3xLf8AIxHf8mdWq592b1Fz3acQA8WoVGfGxmY6 DFKsXmZXwi0NwnIjRdicqMB8YXI8hQSEBnbxTsLsqjYc4UbJ39pAQ7tU5a23/mdFmpqaoKkJD1t3 7tv1UO8NBJONUA8xb9IriBDjyucJIrca6v65r1S6cy+lV+33T/2k4dF0burCyV6fVGy8yY9Otp84 tG+Ke/6LNvrrf0H93pcmF3KHth861T2ZZWfsxPQVoRp5RiUR0pcJzaMVMt3s/Z6PGuyg3TxyDgHJ qlXG2KYMFYJXCge8JWFXBSw1HvRypVUc568qkkKVAovXbU2WI0vmODITDASt7wogdES1yhoCCUxw y7Q6HNZmXMN4Ex2yfIZwbvJLjuS8Kokiv/hE55jNuY02+gKMXJJ6g0Vjc8gJeBsWgw7ZBxe+0913 MG9f/NGpdWc2db/3Yu7qsY/sAfpN2A0f2j+1z5x97bl3k0sPQtXA9nNb1r0BwV0fgMv+DrtrepBv v4F+aCR/HCHzca/IrJVsrwY2Cs1CzdpYveN2mnQl3U1RTkqCiw1aOBhlJCyyam4iWbVP5jxFcuX8 aiHQUNocJs1QWhoAaIhVBTihqkGCrYTletG8SlOv0alHf0Kn+jCtH2qSKmuZowrQVO27pZWhtWHW VedUWGa4JkwT4d+FL4W58DD9wVDzr5Cm1auYwBNTE/FxdF33LVStNSfUy+plTQ86PD3jRCa8jeKM 5xqseeXsKW+wksn6ukDA7xNFa141elMU/L5A0HlQK7jQ3z1jdMWxp/MjtXUXD6cf/frTn/QNXVsP J2Xfqt41A9mWprutNw+k7nvgh9PkpX/bb8Of9Pqv/Yfrcg+Oqrrj+Dn33t27d+/ex77z2lf2kU02 YdO8NoGF3UCINDFEoFkW0k3CW0TJg4eBiA3WEhQsIGpEqeCMhZSOUvMgG7SD2FGSEYXOOHboH9TO ZKodhxIVOx2YLP2duwuW/rHnnHv3kZzv/X5/v895oem1dYtrqjsa/bXH1naf6+idbOXM0gL3/J+V Lwm1VrUU2mL1/srBjientl4jLlx992umilmAClAluhhd1lqCvVov79Z5i+dCP1QHNTWala5NLqai uIhngn6fQEvIa3f7A7RR0Jbl+AOBYq1g0moFi8dhxdblRkcO69OWOWjeGpcs2JLEf4rag061r0py 2lFcdne5Kfdde1RvqEB22d5pp+3vU73w8H0wKh0wEWj6dwI6IIGKWVgRcSM3ZhPTA+KcgAjpJQmv IS8MA9E6IzdI7VWDTRVtQ1WekKK2O1/NFhCtrURrGkS2un1GMLQI/UMxMy23vbPu6OiyfWvm45YG 85zIrp4jrvHq7yc+2hbPnpdnGZfm+1ZufOOZhZvXrD7V8eyyxrcHVj23wqATbQ0/iXjKNiTkN4ba 6rtaulL/ebq5rK0C/0OSOTHQVvPw2vYzxOHbQGMLaJyLDka1NfRm06bcQTWj0EMLsESN9oCe+nnu Zvkpbpd8TKNSmyymQm4RjlNxjVryiCt47ClFHegwICCAhINnsx0Mj+JOaN4UnhEtTtaXJ8WRKIuU 2GirbrzHQkRBwKHEAygxrSQ8kcaHtFoGDzjRTPAhX50RhXaN1d05+fZfnsf4t7+fHMbb2p442dob j7+Jf2m8dPHLqXfwI2cvntBt6Hk+9dUz+/fvAyc9DrucUpjBgYYmkA2SDJszkF22AzZxtFpkbNn0 Zl1SOCeyFtFkK2Td5ofElaLaZMVB7NIWm2PajVrVXFymDZsb8UJtg1mdJUk6njdxOpTr4FhJ1Joc FC9cFuO6y7LULnVKJyVGSmLPOZfsVPmcvgnsRWkgVQpb0/TsNNl9GF6k80B136OARAIqOyTTm1GA +MMI9R0rMSXOATFEipZf/93g1ImbvR9v6B1NfXY6VVr8WEPf+n3Prq/dsnnJa8N/+/xDXHvyAjXv dj3+Y2d/S/+Z20//eu6BL0iy5sPgAT2A23Ewqj1Nf0x/Rf9AMxwpLg8HqyuauX7uKkc7uCB3gjvL XeDucmpAegbTapZCmPZTLOtmsIncWUf5MVKr1Kyf0VIUx7JbGU4GfMKcgWHID2bBD/YzVxlAFl6q YHZoOCwz1tgC0nnDOLB7qTwT6A5A44RzxxgTbZoTUb7GRXwRJrrAq1yNNPrSd8VaF9w1+WEwuNNv 2UrTc14wPVszH+VM5KO2AuVqONsVeeAMuAr+djAR2N0kf0taOlyQvg3dmow3Mm06AA+GVYXDrBwO E3N2B7pxqJzFxnIaLw6MBlJ118euMzc+/fSOkfHd+StJVBVoa1O0TUVbADeaVf2qqypagx2qoOqE 6qzqguquiqVo2p2GUaIe7UdEOpreijhDWjp0AV1BVD+6Co8rykNFepQB2ZA11n5PNqJaT1o0FM0y RNA90RARTbkS80JwBWIhIha5NeIKpWcQCd0TCRGRlLsgEsqoTebxWvKm2/Cgcvel+z/lAuGMaopS hE1wFS4bS32mOn+7HpSpgxJRA7XGim5GH/GwlSzlpjyaKqpeE6NW6jZSuzS9+jP6C5r39Jc1U3qR tlgpRk1TVitRCkflGoByEIzT6dyCbJLhRo+MBUE2OgB4kjgV1QNQqv06qyAgLUayIHNJPD6siwPa j0eFiIBloVloFzoFRniP2oOy4QR7ftgax0l8PmqETaBm1A5HzlgWsgoZfyrgD0ElPAKTAooK0YUD kTAC5MuKEK9AXEn5h1UWLDONYABoLV38y43lrNJTSZkHUFMiDP903fW3CracX7P3aM7A2Avmny4+ cK18E+ObeGL9wR3zfjG7h3pzbbBy4eT3KQOYYD3UsOWgngjnnt4JpIfatQJqV64ThgIOd+R35VNq Va7ZZKdXmVabY/aYo9Pc4VAvUuHt8k5TX85u+yitynMwLJRpXnKiaEmwAvlc2U7EymwXS7Pb8n0b /qc+/4hdKNFNDjewM6McSm+DAgbw+UKkIC+g7tek9eODP3zwzUupm4NPfbJl7HDn3J61i82OI1tb DnZX4qM4dHlo5vJ46qOhxz488srrwY6+h9a1Hj6x7PgVlHYH3Qr7k9CtaB9H7+OOao5wjFqwCKc0 l5h/MrdptY/yM9W4ilqCd+HnMCtKFM1TkpQJEgctiQcrQKDUUjpQErSeKJwNEEciJYNypaRRyYjq QF0QrRl42unnTqOYrOTrkwkcRvcj9l0CHA5ehpBNIATBMLkysRGtkAzBko5LiVWZh+2ZpCgBga8H vs2cFrLuR0SRNJMTpHhEaXrd9yxiZYk1aLDGyZLlv1le1dwQrG6frFnN+K717SwYyv88dSMVI3ot BT/QoFcx+m6ML5L0FY7k3S9GYKZJW8uGxcvCcdfxfHonvTv7Ff5lHcMTqzgJssPsIp+qg8Wv6ANZ b/GnBKae3sXv5+kinceV767WMU4dT9vyNfkwM9jqsSw3Ig/GhTkOI6tyFPI2Z1TG8nZcnKRejHI4 7kzze5IyReUSwlszGifyyl7KO2Mhiuk9hRXIIluoLwG9Ls6JXUxbrTvQdCsxO52AZc8NiFn3fSIg QKC3AkmlIQopTTGAM9D6I7N60sgKtrSmOQEwSkFVIFVooQW+lrHSvbHeXo839Xf/orrJ0ck/M+8y /TvaHi2x77laFVtzaSC5dy/ewi/dWt9RGywq6ssu7Fzy9OjEoK6jK1ZW5supWl2x4snmV1tbWxVi +hf1omoI5aD90aIGaaO0UxqQXhWPGU9zf8j7IO9roxZhTKNsCRn4Yr1OnQ28Kc3ooT4Ny9sN53EK GancEVOc0yWp3GFhO/8+lQtmzUUciMR7isGsMneIo7kkdWgkt3oEmB4OQbemb4EeZEwzw2w4ArrU yFPEPV5W2WdlRcjoDpUbQ3Q56yY0CQrhb+y18x+PlubsPWQ7FLqybNj+bp/VWxQ++pK+0r/4v1Ou Y8rsYWSt/VfX83drgZiCEtB/DcB0VcaiBiwd/zmUSnJIck7l3sa+jeu56FMJdk4OTs4WnjaJqexT uVYzr2TjUOcylyhjL+Mq4SmVYNNh1BewFPQUZBGVlAAW2mKSImLAMroeGN1ikqBCm5VDhMMAWGhz MLKycjBwSIpxcoizafADG02SElysUhpikhysAuIRYqDimF8iwl6SUUDSXzJeMl+SRXIHU+1maWAO B5XkMjwKBqyMF1gfsH5gZdZntWdlYpUUZxVnleKyACYqYBENLLZBmdYX2P0BldtAClxuawscAFXv b4Elt40NpIAGFdysoIIbyJAAZUk+AXATDNQMhba/zIF1PRu0OW5uBuIpM0vuP1E9Xalha5+Qp7vP xExFMdmErfeWH7jRm+a8mCn1b2Sovo2zV12YeRfjaVCjgMEKKyxl2EE6ZLRi3IkOmd4wvWEugEAW fTzwIctD1hDWOzDI1gWC7OJAuI1DDQz3cVZxvuKaMgpH4SgchaNwFA4eyABq9zIwLwES9gxRDKzA XpEAsP3uyMDApPn/P7ANzwSSB5IMItGB/PH8Nl85JDkYQGBx0aH9IHqT9/2Xv+/+TedYzmEM5HKC 1QMBADOE11kKZW5kc3RyZWFtDWVuZG9iag00MSAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlw dG9yIA0vQXNjZW50IDkwNSANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAtMjExIA0vRmxhZ3MgNjgg DS9Gb250QkJveCBbIC01NjAgLTM3NiAxMTU3IDEwMzEgXSANL0ZvbnROYW1lIC9CREtFSUsrQXJp YWwsQm9sZEl0YWxpYyANL0l0YWxpY0FuZ2xlIC0xNSANL1N0ZW1WIDEzMyANL0ZvbnRGaWxlMiA0 MiAwIFIgDT4+IA1lbmRvYmoNNDIgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0 aCA3MzgzIC9MZW5ndGgxIDE1MjUyID4+IA1zdHJlYW0NCkiJXFYLdI1XFv72Oee/N4kkEkJeyh+/ RCo3HikaRBKSq+ottBJLuVciEoQo41WLopW6DVXMjPeq5bGUwR8pKx4lKcVY1KuUUqOtzGg9Flqs 0bj/7HsZw/xn/ffus88+Z+/97X2+e0EAAvE+JMLyp0zW+9YVLGXNasC2urB0dMmQaYGDAHsqoI0d PW564a4lG38FWn7E86ZFo9wFNct+GQx0GcZ7OhaxIjgn4DMgeAPPWxSVTJ6WmfB7Hc+PAaGecRPy 3QivHAA4NvN8WYl7WmlgLC3g/Wlsr5e+O6r0u7X5l4BYPjO4vbYXsf53E2JVAmIBq/a/r3esVetb 846zasW/AGry9H32zMAFaklReEANsINewXF8gYvUCjNxkgrQGJGoEy2gkwYbojAYW3Cc7MhDpfUL NmMIbinCp7hGDryNExTK6LyFNehHjaytuEnCusYndMYALKYIbYp2keZCIyk+tNoghHfOQwTSGcNz NDNwl3Uer+NL1ce6h+UUJVohFKX4J+5yfMkiVbxjlcCN2aghm8zSlloOjEednG+t50jsGMR+R2AW /spe06la7NAK0AQZ6IleeAcl2IRtolC7C4JAAsZx7Edxg7bRZXlD/lsFqOGqXIv3ZrDP5ngNqZzZ CIzEJJRjOQ4QqBnl0Aot5ckcxkTnE9qxzfuYiwWo5NVQCqdG9DatEbPEKXFHfa5dtE6xVXtM4Zjm oQZf4ybuk41aU1uaS3vojCAxXTyWugVrPxLxBnIwDFMxB4uxAjuxn9GsEX1llpwqTXVT/eE9jGAM 5ZjeQyX+jvNctwbURCSIWzJOfijXyxPyAWfSUM1j22ucRVuOsQ+PQZz/JK5zGRZhHbZiN/ZyPKdx BpdRy1Gn0liaSWtpHz2kxyJONBdpYoL4szDFXvGTbCwHysFyovyLXCmPyHMqXHVXvdUatVt9b0u2 3bC7vRu9P1v9rFxrjrXE2md9ZZ2z7vA9CeEIDDhQzFhP5LxmM5LbcYDHMXyHS/geV1DLXQcKpljq QL1oEL1F4+hdWkSf0DJaTl/TNyJIhItGor8YIEaL+eKYOCU7yS6ySiWqFOVUQ9VYNVnN11J49NXK tc3aFm2rdlerszWwbQlAwIknrZ5c9RZ5p3h/sIKsUKup1dYqth5AQ1OunhujGZNVjMkG7o6/oRqH cYJR+Zaju4IfcBX/4Ah/Qx1FUGOK4hFLDu6tfjSGptEcruJyWkXraTdV0X46RCfpNJ2hs3SRfqSf 6Fe6Q3eFFNGimTBEkhghisRsHvPFUrFCrBTHuU9OidPigrghbssw2Vy2kak80mQ32V165FZ5WjVS kYx2f/UnNYMR36SqVY06o37WoIVpDbUWmkPrrX2sVWtH/TmH2qJsCbbxtnm2D2wbbVV2ZW9s72if a19gX2VfZ/82ICLACPgsYB9nkUjRFIMXHsqlI9gh+1AeldFgCiEP5SFCJGGdmih6qdXiE9FKbPVZ 2jop0/ctP8ciSaK+Wiw/pWXYRYQu+IDSMZWWcKWPUCl3lwMr5UHpFT2IaYE2UCoeylPMSecZrfbU jt5AL3FMfaMdHVYmWojhdEkNtwWqI1gq9imX6qCIsZ3OtPuRXIiOuCMnyet8K0rUYr6RM0mhq+iC 3/n7AvdQGMWL1sigN2U0DZCFFMN5+vaeZ5YoFhUiA4dpmRgrE+k9SsEDeFGpHcIKLUedt/qpXZbO mhl+MLbwOZwjlUuXetUa4n1EZTJK1MgE0ZXuK7co9m6n/tRe1Mp2NElMpj+okhK5g46LvqIbxYgN 3PsPcIt7qA73sFMtlQutq3Krd6DYjxbaMJxlRrNhoNhLv+Ec8+kB7ooA5txtqiN2yfG4K12iSjyh R+IR1mI7s/AO0ZIui0zcto1Q16h2Qig1lYXMaQIbmZVHyjvoZv2IZjTZOmUdpFi+L3uZl+5ph8QE LGG+OMCMMot5zM3dPA7BNJ1vQCiPSu79+8wPkVwejTl0PN/TlcyXe5kvzjNr3OD1K3jId3cFLgvC ANtqjvwuvuL8HlMA9iCFfzNC+S5dtx6qs4zdF1ggCYfsDW3paj6+1A7a0zO7ZWakd03r0rlT6usd O7R/LaVd2zatkx1JrV5NbJkQ38JoHqc3a/pKk9iY6KjIxo0iGjYID6sfGhJcLygwwG7TlGS/DqfR w6WbCS5TJRg9eyb75oabFe4XFC5TZ1WPl21M3eU301+2zGTLwv+zzHxqmfncksL0NKQlO3SnoZsn sw29ioYOzGV5YbaRp5u3/XJfv6wS/JMQnsTF8Q7dGVWUrZvk0p1mjylFHqcrm8+rqBeUZWSNCkp2 oCKoHov1WDIjjdIKikwnvyAinZ0rBAJCOCozxsh2mtFGti8EU8Y73QXmgIG5zuzYuLi8ZIdJWfnG SBNGd7N+kt8EWX43pi3LtPvd6MW+dPCxXuGo9pRXhWGkKym4wChwD8s1pTvP5yM8if1mm5Ezrkf9 b8qHN8jKLXtxNVZ6nFHFum/q8ZTpZvXA3BdX43yfeXl8Bu8V8T1cnh7sutyHYlQbDsQXvi+Vp0mN Mpw+jWuMbgYa3Y0izxgXFyTGYyJnetzOmJjMPfy3IcapewbnGnFmRqyR585uUhEBT870yuhMPfrl lWRHRVj4UzQrQus/E4JDXhRGPV/zS35zn9Q75zmc5IvIeJPbwNTzdY4k1+BEUn0fo1LhyU9lM37y iHeZBVyGYjMwy+UJ6+zT+/abWnyYoXsegMtu3L71ssb9TGOL/w/r1QIU5XWFz/8GH4Gq0LTUdoES W1cLQn1hDMsiuIAKojJATN0YXw1tNaVj1DhiHg0NxITWamOiJXa0sWuMG9ammDSKtjPWGE07usq0 TPDRpOpqdRJjMwb5+537//+yYJPYToHvP+fec8+955577jmXxI+IWQ6OaIBB7vBBtzs4ciTHhVGA g4SN94j22NGjlrfJlenLEl0gcB+VV0GtOjcTPk9N5VNtavPQfDSCa2dWWW0XzU9pJU+muzoo+1nS 7kiS5rBkrSOJqvvTEb57iJ+6ScG4u6J/CYnJQwuX5Aal5M8QL7TkpbPSS2fWVLkKG/22b0tn92lZ 8glRmc1JlgAOD6oZ8FRxOiKuoqaKO/CnZRSlF37X78MNg43BoQVVSopcbXFyiiKmQtjOjc7MjapB PJeaoYuwXxBUELaiQ3IVBRP9PutbPSA19VN12oy4GKU28yprCdKrZm8pmOvu257Up93HukGNCuxV 75JLZ9c0Ng7oIytCjmpsLEp3FTX6G+9vM9fOT3clpjfuxWOwoHFZod85/Tbz9aaUYNHT1djEEil3 NPHJGPf0zKCCePcnT95cGJ9PqcjrMT/KVl0cH5E80UaA1ihHpEy1juYDNcZwel07RAHpH9I4yBrk gOlXhtNh9WXajvFJ6CsDrZEnmi9h/BPAh8BqYAkwAXgM+DVwAmjgNnSagVmYYzfPI+g56jaO0o+1 Q+YFrFcBHASqtUqaDVm5PpF+y22sNRVzTAI/E/1zdcwDfi7kIYydJeghqgG/BvLr4N8Af95YR1e1 SvMg+Aj6c7D+MMz1IvbzDNY/pdaZl+WANARzz4W8BPQR0JWgD2PsD8B7gEroVGCvLvRPB18O/xRz P7BaPWd+BLoK/vFCPhp6z6PdDH4T7FqPNY6DH6wSpWFMpTyZgspwswLrP4V9X7b3zjbOju4J9gub +mKKTVexfbGw7OtFr223oLkP6miXkkNnQFcAI4FR8lFxbjWQ+7T3cBZAHEnfgJ9WYG+71AW0PY7M fbCzRdtD59F+LIo6GqNuNvco12gJZG/pG/F6XID4GgNcpx3yJfq5nkEN8F8e5v8eMB5z3iniYQHO vM68BLpUfQ/219EO4FtxRPssH5kX2Ddor8O5Yt9mN3hSEcuAgX13ATfZDqz/FPucz12q7FHA8zqr +Pyx5sPAj6Dfg/HrOZ5xNgbmasIaH1jngPWYAhx7sWAbHIg4syF8H6A6mV9zAXqFfQWfzQC+Df4O YApQD5zG+l/F+MkiXhEzHJscHxwbmKuUz0rErLWHWYixy/adeRP6EWAHsFl/mV4B3gZewH6u8n3h mGU7nbk5tjiuHSriu5aelgNyIu+TY6qX4rwjtJJtEHcQseVQvncc+0wVN00HrVbCNI1jluPNoewX YT/uI9+JKO3d63XY/hOm0N8iYh2x6FDHF1F6hqqFv/EfhnodMXwWueoEVWlltFoppK3aVvTVwj9h 9LtpZVyYhuEsy6C7qR99jmGEpQexVljdCX9ifeHXsJymhiVN24lzJ+mwtlNeI/hbaH9I7ZaMKSNW 9t/2/y+QT2o7aRH4i1rYNLGfn/GdMCJSFuByKPpbgbXAyDi39FxcrdRmzKFEnegasFT1UK7mofFq O+5lEnIeUQb65+hekXfnYY1ZUkQap4SlTCOJ1qmpdD+vJZ9ETAA8P+iymDjqE3P9Y8mhTrz2pxyH dkxV2/l3qp3b+tME4MtcGzg/i/qAHA1UWPFqNkXj8zA9AFrhxGffODVPxcTnUcTnqP5x2Z9ybeH8 7txTvhvO/jk/co7jHMl5jnOAM74/7dWXuD79QuTho1Rj3+0tQAD4IWTDUbf+YOVhM8K1Qw9TnZFH dcphqtMP0GLjIXpCP0SLse+uaE2dZ75q19Mcp5ayn1AXX3XqqOalL4p8to/uFflmL40QdRS2cf3U t9J5PY+G2HklwveQ7yDGzBb15g3Y/S/zGmz/pXKFarlfXU4bhKxB5PX31ePmx1wTlU20TNSiDvOc 6qV6odti3qdnol7uosej8/EYUO5j+41kKU69APvaRc1f4+RjPvu4A+aJuErkiRN0Xb2BHFZLm7UD oOyDgIjHCqF7yFwk5qo1z2pfR+7iMYAaAa03/2r7Q+QbIasU7YPCF5gTPtgl3hNh+DUgxRthqjYu YHyYOnDv0Ae000a2BffxpKjX1/A+CqM2FuJ98IFVu7W/m2/jnn0lWofvQM6/YR5D7i3HWJ9dq8vE 2wL3R7w3ECPGMK6x5nHNjfwZoCPobzYeQUzuoCbYUIH7O1V9kEr1CPjXzA47b1cqBzDno/S4eJ9E 3wmmyzhgHkP8WO8FtoHfKWzP88jtv6cJ2NO0eDf20kpbEX9NiLsu4J8W6CDgAfKAYgvyIMj+ghjl WtuirJcywW+UF9JmOaAORh/keEf+hu5VX6AZyks0QF2EeniRnpEzqUGZgTO+TA2aQqfRjqij6KJy GeM+piuwq0EbQEvQn6Uk431yHu/HahqIPZ9UW2mpYtIl9U7sfwO5oRfR2uiM9gBqyHcoC4gw5HHU ocZTh96ENy3W4/mBg5g/laGupGyhFwNhqwO2+VcxNm+gFcqjyHts7wb4LcZetjVqZzudZRv/k33C Dp4XemLM32gdkdkJZFi0Z2YMTb4NdMZQF1N+g3Nd0EOI63nIfSvwZnmNmjHnh0TdGHeT18RL7eYW 9M0FPwnIBp+GvodAf4pxp8DXov8Y8Ef0edUUyrfz1A60eyDvAA2Afh9jvgCKsd2/I/rkioWbbrTz gXRgMaCgvwl0gkV73odeMajPknW3Qmc/8JaNZKuvewowAzpPoq8QmIx2HVDLsX3ru+b/TD+lnt0u 7a1f5g1G/5p029Q5z8+h/WuXc/6fR2PeoH2p7QdnHzG19DNrpkMRinn2L+0ljzI9lJmT7WlTprfe k8MkVFhsNctFs7XGIgtz1rIwJUUIQ0OGWXTg4OyE/CRlOtUDVwCF8vAtA54FTEClBFsuK9NCUtrX /G8qpWiXkozli0MFBdn1+5ViZKxi6gIU0ZsljCoOjR1r0cwxFh0xwqJpGVh4EIbnAfXAO7a6JtTj h2Zn5qcqJRCVYJ1n8d0PvAN0AVcADXaVUCZQBviBlmhvl9DyKCWhb+byeiX2hktCAxOzy/MTFR8m 9kHBB3P5K0HFh2l9Qs0Xik/MHrLXbJc7Wz352RYz8W7BvBu6Oz/7RP6X5HehlCV3Iot3UjngB/4M nAauAgb+b+ukZuBFIIgZ1PHN+WnyEeg1y3/C1yN4j+CzBJ8leJfgXfaY7SQBy6GzDTNtI1ne5smY d1o/bcj79f2GvFvfbcgteoshl+llhpygJ9h9Cfn3KV44yAsHebFLrzhKLzzupXn/ZrVqY6M4zvDM 7N5+3K7PZ+PaZxwzd9iwlz2w+TpshMFrYxOF49t8+EIsO01pY6l8GBsiGho3VaKEKomvitQqVImt SkgIS2V9R+yzUQrqRwppUSva/myDIoQKlRV+UKLy5T67cwYq8aM/OnfPPDPvPPvuu7OzMy9wBrgA zAAKqccGPwgwpIUrCQc8SzOwBRgChoHzgEbOoKa+blbTXbh6BlBImCXRS/q+ktAkMTFJzLRno/5o M7DFs0kb8GuVWlkDfivxS7IkZvkP2dgKf7p/P9v4fLZxabZx0WvkZy7k9s1t8vnG3KQ3QPdk0fAM xwp8pMA9Ba4TnLVXLPdpuaBlgpYKWiKoXpAt6FlBcUExQRWCygV9Q1CZoDmCSgUVCTIFGR7l7EIw lgjGEsFYIhhLBGOJYCwRjCWCsUQwlgjGEsFYIhhLBGOJYCwRjCWCsUQwlgjGEsFYIhirMEMxj/EW apM8j3fg0+eCLgm66BjgfbVN/IbXp3scDj4GHAF6gDrABiwg5mmk5uz7z4LW5qI1vLtFl9Yg9ViD L3ENPvA1RJZW5aIxzrEfNWLZNmKhNmLpNmLZDqM+A5wHpEdjTEqOw+9QcxPuXzmOUL72Q8n5EdJR QbsE7RRU5WwG3wVuAleAV4H9wG5gI7AOWAMkgQZKSq/SW5SVHqQ/oBkqUUp0yvAJVFRgIy4t0Zxz DMcq0dnxbO8c+P8kG/8OnoCeJXGZEk5ztNtnl/T6PEosugB8GrwL/POs/TEuG8bqA32EFQbam41X g76VjUdBL2fjS0AvZeMt3jxnrY95i053E0vzHO4iNj0B3pm1j2N4h6COrL0OxIWHedn4B7zFoNWk l41CW0UsnyuJzUaz/K6Vl2mW/9vKs9Fx/rW9hd+08xod5zfso/yv8TyjTjH/S91lfiV2mf86Xs9/ 1QulY/ALvZf5LyEfq/UdnLAx2zB/aDfyH9tYDHUwo/8qLj1ij/KDcIXbHeC+en8sT09gdJ/1Ad9r v8F7LPTHebdt8911ebogy7fjNhBuRG/XOE/h5s8XbvycneBtuPk6L84sb4n7Hh14oE4VXxO7xlcj hoa6czxpr+ZL667xGrudz++Fowm+s0gv0hsyeVrjrFQzf1Mzh9TMTjWzQs3Uq5mEmlmoZhaomXlq plot00q1sBbSTC2oaZqiyRrTiFaWn7nqLCLYysqUsEeK7NWy3w4zr0aFmjCqMbKBlLpzpBRLdbS6 jYlUXp3Z7jYkUq62dU/nGKXvpz2re+Flkvpm1L3TUZOnwW0vuIGaVuqWpkhqR2vEZe/kKdnRiVXu XfBWlVu6rnOSUFr51ntVBU6n13VOYY8uJ7Q/TcqPNEeaS9eWrFrf9pSqp1AnHpfIE+1EauvRSSyP UzmVr1TR7UA343UzXjdS7f4k1dHpnq5Ou8u8xkx1OuUe74i+2DnJIqy8vW2SVXiU7pyUcyzSvt2z y7m2dDqFV+zrcLpFoCO1HkEX0kjU05FoSPN1bFToOKvwdHGPoIucJNzX8chJXydTTzfWG21vG4tG fQ3S415f01tDntBM0m5SC1VtrVCN0G5PRbtrRjyVm/AdWRYkdZYvoc8Qy3dk0Wd8SfKxJFaQdD+S dPuSdx9LbCGRTs9KpNOQJP4PZW9re29HK01t7RzTSGt63YuCy8MH1/oro6hy7cmqKXJF+icxEmk3 WNPqGjU4+JsjiXATre/CBdlBSrvSfusrr6WYrgKZCngeVscir1dNyYSe8j2YMBcVhha3LG7xhrDm vaEQzMWFocjrq2NVU/RUYSgMcwnu+7RH6O8fSPQ/aXiq6n8rJNLe2yb+kQLg/rCPgf4Br/S3t+E/ QFKu3ZFyG7e90Dmmqu2u09OWhq1u1iZJvm1M18EvtaX7CyUxcHgAN8JsOUsdZA0OUgYH+YKDZMFB puAgTXBwgDs4vR0c3Q7ObQeHtoMTe6Ql6OdzI34+N+y3h3F8LqcOsgoHKYWDA93Bae4gTXBwOjvI Lxwc6w4SDMeuRgZt+VVs+X9Nkh/YEyVNEnhib2AAJIYOJ2j/rLkwWQz7EtLkAMFJqpKms4xOKGqe /cuJkIA8IZGgKk9QUqkpgQkmufr5v2PR3Gl60LQ5fLtp04Mm0ox2+D6qpUtiJbGSBaiw95H7UenC fSdA7pGofMHb/DoIUdXAFDHpPefLkKKrutZO2qX1wf3aEeUt8iP6pnJLN5eEnNCfQlKxqpsWW2Ru UNebg2pGPW/qlfpck4cWEltfZEZDqmRI5nVyU/uHeSukKMSgxUwL6KqiSUH1t+SP2u+CnxkXzcBP gz8zz5Jz2if6hKm8E3zX/AiZ8bD2oa68ph8zh5T31CHtuK68YvaEjpJBZVB9TVOe154zO/VO84Dy XVVZpTeaW5SNqmyyb2uqGiNmGSGmHgzON8wywzADsjxfYmWSxBiVTINJ4WKVq0z9lL2JeTXZD5EL tJ0NVVTMDebZG0682/jCYIPGjMGKDfqVx8MGHTLoIJ7AOOBZubHFkIwpmsWsZZ3yZtpNv6BSMR2k zKCcDtEZKtNPMSyRAGsjErzWD8nn5RlZWiI78lb5gDwoD8uKXFlkVEgVRUWyaRYxjQWYoVEcWY3f iyTw7aOUlK6qxz+RwLvs6ts0fS18p6vv0MM7XX7p6zv0YHP73rbrm25Ph6e7sFVgs8Alb9clvh/+ zdt1EZ9kcACNpUvokfrKeppyjW2duZBeJHv6NO16VEgXPdQXi0lSjMbmUFRUGn74ZfLGw1t0Gf3F Ynqb5h5efjhNY/Klew2BqXsPZOnuem/tMJKbua6sD/yZhEk1GXAqy+dEyivnVlTH5YXmK+WX5M8M XZcDBivzctMivQrkLFKkSJzoYf2qLulzHd7DR7jES+IETtgIoQ7ZSnqIdJXcgv88O5Gbt2qZt7IP 9fV1TW8O993p2jRNmqebp/FgfV1zVjSsLK1dHv2PGARFmFiUlVSYVEXEjI3MhExN1JSVGDarG19k tDvNKMDof+tf15uz/16VMGrtmFb1cPKuCXf/vWayb5pwkFFm6b91/16++Of3ahej8KTpZxYyus9e e/RfCihv1P1/zpoJ9J8Wo6BDthO7l4CnoK90Jm+GQK5wvmyy5gTG+RzzxeaLT5CZKLdKeqf0KZ4D giekD2mIMugwuvF4KnorM7txOnD7yfnL+ys06LCxyUtyicuJypsp+XL787rJOcg7KzooLZE7IXxU 9ZbcLQUBBlZG0XwxRrEdjJEO/Osl90uel2SWl9SXtJdklgS1/oUtJYFhuFWI+TwjIyNIkTCrg7Dl AtYNrAdYmQVYFVgNWJlZQaEso87JocGgIqDCpPJVTENAlFFUSkdGI5+fcT4/I/8OJh0HfkZwiCsA E6uk9jlgCIOSmu9bYHIDBvI3MAsYzH8LY7WfxNr/1S6M/RJrCUxjhgbA1FLIUMhYFCusKiYOCmtT E3U1FTU1UxNgNLCIs6oBA55NVERcDARFRRgUlVTUmhjl2TSdNk1pMVP7t3puFCPPP0YmRmm+f/e5 m+prsw0NV/x1TQcmsXd7/70uYrzN32ngl+XtqKs4JXle1s4vn07yZhZEONtrannmuqTMPfTvbf0j BjhIG9qYaREEMzehYla5UTyKR/EoHsWjeBSP4lE8ikfxKB7FgxgzAntvS4CEPUM4AysDE4MAgz6D IwMDy93//xmYgXygFJBkKOIvrY/nt/nKIckB7sQuDtxvBqI3ed9//Lvtz19ORw57IJcTqB6kgwEg wAC+CE35CmVuZHN0cmVhbQ1lbmRvYmoNNDMgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRv ciANL0FzY2VudCAxMDA1IA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IC0yMTkgDS9GbGFncyA0IA0v Rm9udEJCb3ggWyAwIC0yMjAgMTExMyAxMDA1IF0gDS9Gb250TmFtZSAvQkRLSUJQK1N5bWJvbE1U IA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDAgDS9Gb250RmlsZTIgNDQgMCBSIA0+PiANZW5kb2Jq DTQ0IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggODc5NSAvTGVuZ3RoMSAx MzE3MiA+PiANc3RyZWFtDQpIidxXCVQTZx6fnEAiVxN026X4AaUKJHECBuWyhhBwXAiYBIxWXZMw kNFcZAaQokKiImi11ANPKmorKlCP4rF9WxefrgcVildF12tl3Wo9qi2egO43UARt3X1v39t9+3bm fW/m///+x+/7H/lPEAaCIDykBGEhIFGDJV8qbJ4EOXUIIhQa8ykQdrhzAXxvRBAOO9ueY3mAHs5F kDcPQ9o7x1yYPfUJWY8gISYEGYSacH3Wn+un4AgSGQdtRJkgw1vMciJIwBlIv2OyULMK0rExkH6M IMwus82o/3xbHUAQ6WoEYbgs+ll2JotTA/X9oTywO3D7XO+D0F5gB4KwoF+E0XPTT0TQDZ9CpOcS PEBdgvtcj7DScaWPPBluzGqX4BpkXWYyGFIvdBDXvXeHyeEg6HQuL5zLYDNco5gMdrUaTUdFAzj+ mwJK/JG4njsNMSAkYkPMCI5QcI2hbxS8bI/ts6x24fVmXtfyuPPJtc/i5IerXd7voS5mI1yhTKGg vOHkohs1h7+SHV23pKxpaJMm82PU8wVWBhtCcn4iHYq+zWVlsHmCwZm4g9AQOVagdeSRFFDhVIHN MVM6BPWjBfgCrz4BEcCsRolUhIb1bgT3axIWHGgovcVOWHOABnfkE0YcqG02SjoSjeiVDlelgRRM noClYNpJQK5QKNO1ykQRGG4MjR4FXvaBBgzxjB6FyqQR6CgUXpMhGS2NiJT+TP7vH8C5YWDMGRyE 5VwC417OdDqR0xJwzzRbJJY4/Xdxd9fw9/l6TrygactrPx4ZtvvMQ4/3R/50s+KZx6DWv/x28h+a v3tYtquqcWHIrTk6H3LGrK9z/bqP6B6G1uqmVbK7xQZfndO/KXfF2SDdiLMnhJz5UV+u2N6QOv7m 3dig+sw1cwPXm0sbxyevmtGwJepsl4f4dEP0OiYLFvUrJcGCuGJ81y/gjDl1s6Sz6Oy2jrrCLk7X yvjc4G3hw698KMDLn4kWMj6avNbQ5FtT0rHvgHDfycw1M90NyiObPrsgK+YEXXaI2aWcmtkeg5cL FfceDU791m3pOh+z7hlPtqqpfMMVtn192Bz90oM3+Llrtx7NNiTEr1wRFLE6qHzR0yz3dx6cegrr txmuKKYf8pXv2guKO4GdSbr55U1JZRUhd4XT//+KuE46DA3pNRzwz2H0nZT/2pP+WxD74sP7RXx8 UW96w03gjlkp3GHFKdRZ9YuSXgyzsJAu6Vr9nYb6JRXJFRcbfKcRF3nFhgqutLnlednHSeewmBU3 z3Dfq6rfNGvy7SddRmXafr4V/WFTVK3Y48p927BazwnTObK04hZtWus+UUIbv3XJ/mnP95a0tlc2 FAdhCT7m06t3MjI3H/pGsiGmo3irbsu5IPz6h7Wz1v/xfHKC6X3xnO49TAbrVwraMr1zze8/Jb44 XWQPNwQHJIIJO4L9jlLMJ9iPw96aUleaK3MPf/jR5at7Km8srvldO3lsnEfVzguLL/gta2Jd9wjJ 5H6n+jT5s5MTk86MznwQ2Hzo3VhxSETLumt/Gpv8fZslOf96I7rZu6SluC12bvWTlWHScL+nx4R3 Lu28mSG3J4lFc1GXxxa4vKtZTAaT6VOYXWmdt7N1L+MNa1VjA547EDETFrT+V6L++gxFotLehIe9 qAiFzWLBHUZCbwYaWzZVoHfgID3PYCZIE+4ggULeU5Kj0ZHSKBR9UZI0GREpi5ZFT0ZdjKn/cRDS JDSxVym+oKBAkg8VSagoMdosI+AEtpEEZXMUjlCka2gfNoddAgyFQI1nS0R0XUtStIl0LUdJx6Bx vXZkiUQOQUGHWCJQmPUkCSKBGKQSRoeNhBD6cWTqzUSWniJsVpAfIeWjHrQ+V8DM0EgFqC9NuAt4 E/WkCbYeZbNKfVCv3lC4qfEsi82aJQ1A/WkOS+jXb14BMdocPWb79vmv2YcBBq92kYvhiUC+O9PF YCANFafe3Zr191t+h55biuRpvCe2sNwWyW80WyKirp4x/VXWjb3RVtmFf6MRggPs4x88OG63rLh9 4osdYejaCN3svdtmhuSsabxW8D3n+g/tlY/q+W9u+Txuvv3aY9uUtDk2b7Vykd85/GIs4LTHbzSv ivHihwjuBH4NlkZ/YJjHOR78Vpe6qq4qpfJcnEoX7yq66yHL3GNqTFBuipVu7mxb2ZlxVLR186HQ tJaO5fdYQ4vu+8Vse7w9fR7HYri3WFA2+ny7vxd5kDv2y+GHbjUvyz16IHv3Rm3Qt/yc2Y8XFpbX ZfO2T3ja7QjsKp16pGO8122dPji1dVdM1lXBJ9OOLbCkDN4R7wYbebOLcwl1cc73ZOdtAZuJIiif fvVms1lMTjXqLKMpBttZgs4t8Smq/NtJRbdp9U+jT1hjf+S7Nhr/C43k4jAb4FchGkgjYTMYz9lD UCFKf/n1f9kNZjHdShCYbSjCY3NRCJ47FnWxowbI8GhVFzsYsodWh5YMM1GUnYwZMeJfNMZGF2u/ 08Vq0JoIEhhxB0VkE0Y9hQOip2HoYsNJumsceDbuwK1GXAT01ixAUCTII6EYCUjKQRgpcyGPzDPM wI0UoGwiQJlw0B+EF3bpfkl36I0UPRDhaKJwC26lwHCIJJQHYZK0gFSCQif5esKsN5hpJC9b6z8A 0FMxvNcdNJZGrRRboBkoB6AHsQPPzcNJihz7spzNwYOifYIv51QEImTRkTCNejgh5fk4ZKTa8qyU HqLKJPACEUwhiB6JjozkZWjkUM5e6CByTBQ9JKXR0VGvmANAbjYDNS1Bwh8iEs5kPEsCFEq1Vo6p eBPlarVcpcWUGpCIaRQpcixVmQjkqsQBczgFS8XgGJbwaGkVpkqOAdpxSpChUYK0JPiKaXrMYUmY Qq5VAkhqtGpMoU2ZBDQZCeOVCi3QptEqvEylGoN/nFQD5LE0FUhXyxVaTKGEetBAqlKlhbBpF5hG kwH9AXmGdlyaGmLh9YHU9J0AYKnpKdjPmJW6dPU/mK/2uBrTPP57nud9z8lxSRK6DIdQYdqTSy7R 6HK6KJWOImE7nS6iC51qSmUqsRW6uDVTkUg2GWpmImaUzCpWlsW0JjGEsi3WzLiFzru/k0u23f18 9q/97Pvrrd7nfX7P8/t+f5fn98oVCmkvKiTBw8Hdx1G7Su+oBO2eL/d2cMHHdyg9vaVOrgs9tOpO +L+d1MsObXTwcbfzlnr5eHt5KuSTejZZ5OruLvXwXCixl/eQ5C7vUXDw9FDIF/ig8a527pNQxcN1 oavvW513xnoiKm+po918O2e5wlKqkMslWpza80K7hqMcZ7krkGmHKMz9SHRZVEjfWAwNU2NZCA6S RkZFasMqJCw4SPEmEexiMDMCYzGBJMHxqN8T3HHK8NhgqXqFEuMgMipGGhgsVUXhq6CeRZRqqVKl io1+k4EhUdERPTkjiXtz3OAMjFStBa52lpJ91ilT/5s0fzceHhUaZRkaFiJLPaKtJFIu9YAsRZYi 6h+w0YVsfCEnYkJwwFykg1WF57GCDjP5j+sjSbLA9zOpzFdmMKxPPZRhs0KM5rwbNFP3MBvWexK/ rynS8DBloKU0PAZz4Z+7S+i5ZMM+qHTGnI5MhNUOf/r0PdpObYf73gSflpilm8adLpM+Dq/5OtEp cXfx2hNrRC4GQ4Kbllm8WGCTuabqydAZ8S05h/unWOcuc8k/AzMkirq504UsfbMIcJ763MXdMvqX hivruh2jxuT8eWvxne0POwQ4d/pRtMmPRSzyaL0qcXK8o83uDVmv0jdON7fsKJsx3fbE61/TTK3S uDFYg0cidFns/+D8+DfN4ACRzhtSKM/DntRDMsP3LPVjVh8eLBz2GL1P/a36HDuyUb2KnNUQbjD/ O/XkpvmVNec7nx2KbBx4VOb1wfQBVvayuXtGpAwDBSRABARCFISDFELwbyTElIxNGaONprfBFPGu qemJppjo2OCYhNXBv+nT0nBpBJY06jeu7NiVqbx1YuTD3EpJdZGx7YMSu+FOIcEN2WfXH0tbZp+T 9SD3wpxb8zZ8tdbwyM9Fh9hLv9qiiDsxl9paHH4OMq+L7/JcuW34sfkDL9zNCtyy6svBu8asEP80 1DAhc6zfQ7P0QFPD+FjKzSh2m2tU9xe5r625xwjxRyqzyCUTdvx16cvEXd9Ej0wuP/BMoVf4tH1z 2pXM4vrRa3XbOm+GLQ6YUuBGa10Ofl6asfG+zU2NZ+HljpbGtvAJV08GfNuw4mqBmdL8bPIV5d08 34sG4UNcA+6SCFe1/he7AvRv7ze9srYhUVqjv7ZshABxmU3tebfP+2W3pc0+l3MgQ3P+ROK9Kdcm mpekkUvY1TX1+kJklUZO4tBxbZCl1vzff79SAzipV9Di8HD0K6fF6Zl/dMrIHfdoaECfQPWTjfgw Tvu/fxATDNP3b3grXe2nh5UMvzVkVtOmTF3yL2HamZc78OpeSdW6bcJz/R26bn2DKjVFnrguwj9i mn1i3I/3rq3uMtBzy/NrbkquF0I9bdVPk1pDpolXBcuHDjKGz4SXJwvKLYri2qsThMOzk68v3fHk UYq6WK+8n1HypnOj0yenDq2/eE+a3tI5OcM/4fY1wbh8e55tWpb/uK039j2VDbEvWTfGM72fy+sT 1oU23x284tG+uUKNNY1fBla8O4zC24RtB2MA4fbb+67GT3jIrwJTzUqh1UwXJ3/z9n5zKWEcLAcL mAen4THUkgngBaeES6CCxfRT+BjHc+AYnIKb4AhBQMGIJIFUKILNMB7Wwx6YyRkJ1eAO93V0YRiM hVkkCkRgAKGwm7SCK7jhGjbgDJkQjb8X4PhzMgPfEJDAMtx9OxRCLfwJfgJDXNESmtFFz4VvwQEz XwWJcBxu8vb8JtCHPDgA5VAP94glKSWd7JFQLTQJf0MtC7ACa/DHKhEIW6EE5x2A89SU7ROMhETh 98JZMEHrKxB1PZzBvZ4RKfElKlrGEjQvhUihAnkYgDaj9Sh2iMYDYmA/zmyGV6QfShqV0k+oSqMn DAcxjMJKNBHt88HKtA4yYAuiKIBiOAL3ySdkBblAHtGBNIXW8V5iD7FHv7ruHwRn4RnuMQBGo7WL YBXEo+ZW2AY7UbME9/oDymPoJtbEhtgSV+JNcshGsp+8oBPpdfqKDWK6bBLzYwEsibWxLh2+21OT r7kkeAnxyCVBziXoSQfEuRCWwmpQw6eQBCloXTZKLrJXgVKJfNahfA834A5KO9yHB4QSHjFKyAQU GYoNmUvmER/yWxJK1CSfHCU1pJacIZ3kCZ1KrelM6km9aShdTWNoLq2kVbSO3qW/opWzmJyp2Wes gp1mZ9ll1sIBN49TcmFcLLedq+R+4B5zTzgND7wpiiWv5Pd079W4afyF8YKNEChsEXJR7iPHIxHN eDBDPF7oVRVW/lBEtRrWoCQgdxsQ0U7Yjdxp2TsKNfAdRulp9G8DXIIWxHcD2uA5dCE5WnwGZDT5 mFghv3OIM8oS9FMcSSIpJJsUIM9VpBrlFGlFlBpE6Ev96HIaR5PoFppPC+lxeoo2oycEJkJPjGDO zI0tYv5sOYthO9nn7Au2mxWzGnaKNXCUm8V5cdHcei6X28sd4Rq5K1wrL+Nt+CyUSr6aP8m3i4aI jEVTRQpRjVikk6DToaOBr6ERqqAa+lwkgwwmVfAl6WAcS6FNdDHtT5tJGneRmKEHZhPgs/FU/AUt /IhcptPJIqYiS5C/NBJC/GEXM2F72Txo4iOJgnmRIFBw+fCa/x6UfBb9Cj9es1g36aIVsAKy6aru csGPDAIFKaVlGDHJMBssOCNopjO542QctaB14sOkBmzFIjaTzdLRxadSdgfNVOjokk5QsjbMn9uY W960DGtCO2kVe6J13ewIzkkGW1Kq0YNy3o8GEBNaSty713dfY4VCMTGkbQDdet121AEjzkc4SGvh 75Cv6eJuQS29Dj5YNVQ9mfMPxqs1to3jCM/eHe9OlGQfqRclWuYxZ1KPIy1LfoiSWOkokbJiWqpk yS7pR0rq4UpGa7twrNZVHDgJXKd0LDBIYwRFEQSF0QZOUSxlO6XctNWfNuiP9I/RFijQ1oHttj/s NggUBUhssrMnSpZSo+iR387szM7O7Ozu7e3HuPe+hW+aA/CQK8X9NIzvkZNGV1fnl4Id7W2B1p07 trc0b2va6vfpjQ31dV7PFu0pt+raXLvJWVPtqKqsKC+z25SNG0pLiq1FsiRaBPy6BF9E602o1Jug glfr6/OzupZEQXKNIEFVFPWub0PVhNlMXd/SwJZHv9DSWG5prLYkihqEoN+nRjSVfhDW1Cw5OBRD /lJYi6v0gcn3m7zgNSulWHG70UKNOCbDKiUJNUJ7pydTkUQY+8sUW3u0ngmr3wcZazGyxcjRKu1k hlR1EpPhqiLtGQ7kUoyK1mjhCK3WwiwEynsiyXE6OBSLhJ1ud9zvo6RnTBuloHXTjbrZBHpMN1Ts oZLpRp1iw4GLasa3kHolq8BoQi8Z18aTh2OUT8aZD5uOfsO06jt3HY+r2Lm9J3ZhrdbJpyKOKZVV U6kLKn1rKLZW62ZlPI59oC3n6U2ketH1K5jF6LCK3rjz8Rgl59GlykbCRrU8vgktwiSJYyot0rq1 ydSxBM5NTYrCvjPuuZoaYz5/G2oiamokprlpl1OLJ8ObMuWQ2nfmWrWhVq/X+H0Zxbac2MyGjQWm pHQtM7GqMzmzOeOi+1YzS1hE2tO4Iqg6pmIkMQ3HFGDFRABSYwFshk+coBUdxxmZokU9iZTSzuTM nlo8iqamPgFcAdqD++slyYJE9CifAGPZOllda6hf4amu08ZGtkSkHpxTjLHTrO/0+6azXEg7qahI MH0wiLlNxtubMP1uN5vgi1kDRrFCzw3FlusqjDrnwGjS45RLMM3CiqZiP9OcW9Gsmic0XMnX8fwC qKCyd/W/Uaksi0y2U1L5P9QTy/rosBYdOhhTI6lEIbfRkXW1ZX1gVVfgaFlPjHdyBY5z8qYWF+Xh 1casEiuhggf/ormox7OSjKvSlBC1lyqJvuUybnW7/0+jbP4jZmWSx2aFMGm7vr7esa6+LrySFI8B C14uOnIwlbKu1QFLmlyc68TyQO6dh1vlZ800rn1+JXyApyp7PgP8tENchbuW65AUADzCOAyJV2G3 2AZ9/EvQjroRhB91r6LOg+2PF+irXFs+j/I9iI8QPsQwQkWMIuKIvYjnEENcG/wUcRFtg8yeUf4S xBhveR/KLQfgKaR24R7UCHegTnRCn3ALNJR50f92SwkMIO+xnIVyqZbZ5P+J9b2iB9v8C2M4BV7h PQigbYflPFRi7LtRF7A0QLd4GP3dgUrs5yfiP8gxpHssYZRB/t8C8H/GvkcwjjOIXn4RImj7tKDD bn4Pju8W+LkfQQ/SCOorEM3CD3FMOtQjz+JvRT6OdArbDKCtjvrdmM8QxjrIfwyHkDZhv4f4P8Et 8gO4gvSP2H6HsARl5DPTb5DgbKHNLswViCLMiyLZhvRTxJJ8ABqkexDF/o+sUH47HGW5wxN+qpDT M2h/FP2E+J/BsUKOGbYwXzLA34VbXJsM+Us4dlW8jHN+FvyYm2eke+RFzNWAicuQRNrPgP0FEK2I jgLaLdeJFVGM+mGs7xH3wRiD5IIWtN2KvkbY2kDdNozTRCH+vYX4TYpxNmFeQyv24h5oRBudt8Pw GsAqFvF7YxHvOSYlV9DmNNp3cs14DzrL/XgZ0MPb86/xdu7IMgUN+RdMirbkCmwKVYCdq8Ofl/PC CVKJu+OrZvlls+wyyyZWck1zTS5Xlts69xYjvrnaBiRbjOIPa1zNdXZXsI7Vq4yOrze4bl+tdn2I eKeuxfVysMX1EqIJMY111q7uaoPrRN2Jb5z47okLQitUVuIs222ykSV33t1fXlRe1JrOkl8bbVL6 l1L6mpT+mpQel9JfkdK9UnqXlN4qpXUp7ZHSW6Ry2S4r8ga5RLbKsizKgszJIJdn87cNnW3+clFh RBRYKZi8wrGSbXR8E3BE5vB2R8v4KBcd7qYBPZqV8vtoqx6l0uChWIaQ2ThKKfdylsBILEvyTHTe yU7teSAkf/6Ss0DjcRKlC2MQHVXp0rCWJVZ8UVm0bkLtUYiOdDugcrrL0WXvtLX1hp9QJAql/vhx 6Guf6OCZ98BFTrPLF3n2muR6TWLSYZSmTWmaSdOm1FFLL0eHY/RqbZy2MCZfGyfXQjeMGfYdkNAi E4gEvTg96aDnRlU1Y9wofCB4E6Njk4wmJ+gNbSJMDS2sZkIzT1DPMHVIC2dgJjISy8wYE+G5kBGK aMlwfB4GyGimcXadu++tuJuHRjL63z1mySjrspF5HJh9gsdZph5gHmeZx1nmccAYMD1Gpoa7SXQw lpGhO46Hj0mvccVWnKqE0x3vrlROdprz1uF2PO+8KQB5G4rxLC7B77pSBFP5Q/4QU+GCYaoN7JOv oHI83+F23iRvF1QKim1aN+in9S88p9gDjshUmAEjmc8vcOfm7K4WPc7OGY4dQXj7w22Mk9ZhbBal MZRZhDEerKJljOe5miJJGCNQLTcEHPqAshjsfxQcUJaC/cqjIHQFHwUZmre5bW6bBwtc2/BQ5Rce Ghb4HE+cBba2c71cPd6JNoJhbO6z9m2YKpoqnir9tvVd7n22SYhkI2XseJSlLPH9vGRa+IXirnfo yuKjxaCCP+jqsrW1NW8jR0jFFrAp0FohilxFub2Sq899nvsLaVmaeXOg7/u5b+ovkk+JTlpJ/nhj +H7u9d/8LffGA7a//BjD/kIMznq+3hLgA5YYXhTfsEggS2XEJsn4KiYYwHUWgO0maeOeAQxi6XEQ yzGU7RRYDNLOXbvsO3dwXj9eZ7Xc75eee7N/9+uW8cYXckW5P+R+l4Pjevg+Ofbbv5KpB8tnvVCD N7di2I7blDt1nbfWCkVZ7pShSFY+RsRakGJF1SVqvZnn/kXM613oMgm63f4f3qs1NorrCt/H3Jld 73o9Y+/DXnsM48V2IJYXP9YWsLYHk1auEkNb0wRbuNXYQuBUDXKEEhAJJtSCUgohEBLAvFKQm6RF KXgTjEPlliDaSpAUJagolFZByE6Qpw2VecjpjHvujA12Eqk/qnavtLszu3Pud777feeeq2ghTYkp WkLD19rwVbuwzY7ha0LULjDsQnzVcKoIv0F0WM2o7kcqxVGGcgQ34g15CMUbrbK5PJAQ/WKI6O1O m4FnwDN3HQVU6SqcWamKmAr7HNSKLglLIgYNgAAmgCVh8VG8s9E0k7LJhxtxMqoT+a5hj7Tz2OOf CMvpy8B6Hlqnzyz3YDk3JGd+iHAyIyBml0u+3LgwiKL5oXhajprfjxf3aXOeg1qzeLTRBJU1jpqo zuQKG5qHlUzO/6J1+qysKEv3F2WlhwpRxANvOWJuIQ76Mgtx2JtdiKIM3hDIH3MPvPAC1sJwxhRj BShRWVVVobGiWIEYCoYryqsSlcJyW3/1wL0/XbU/2vC735PHrdtzwn3H39/+zF5iLb2wef9f8JwP u97veBUf2TX46RuHh9ys6FHQkobi6Ak9UOD1IMzIbFRQUlijvovPoiDy4t16Lkv6cUlN0FcWiURJ jbxtdjKSM7dsG7SDExla5uJvrHhkCNU1mnWmKVsmqBzSjHCZATQOU4oB4nLAL1OiFRQlKmspXEbC kSL+K3GyqK6ihv83B5/8WXVp48kNLb/s2P8r+86BU4u7tm5/pKm7JNdX3NPa8lbXU99bv/EoudjZ kDr/7SWHXmz7+F37sD1sn0v1rPzzvuaS2tK8naufft7+49416zf1Omoar2QGM1EIDZxBEt4B0vXh Xfp8T7WEYR8LScFQgBIqkKJAejAQSPenpxdTIUjTA1SAK0qYKJAATqeCz1+kiwzTflyrKzMzAm8i HNwQAVpCS6QGsR8v6xNywpF+vLxP4yrj5Fijow45jSaKw/pHc8zsumTUSs5T5oEQHJa2eEofZs/L 57YIpdkPe+ALcvnjf8iWzREk3y6by7QExgktKwaEaRhrwFZVdYRpY38jB612wc59SF7/lJVHyq1t tPybTfMezXnowixaR8sK7bd++oz1nX/dzc0yVkqcj6bxFtoldYCa5+h+b4OnHmUEEPYmPP2k4FRA xQOyVuEWDNMpGHELjBtR5KyqzGqYU6CwXkrTo/pnB57eHbGHeru39AI9lXj2ON7UbdSGztpfXLL6 71l/dedCKZiLIlX3kXoo0ComA4J2GrtFCShBcbBeJKZUpAyj15MxFaGfI0T1UoMHE+SXXIRE9Q+k a9unIbwBIbIqFDkTFCUVIaI0GW+8/tJnkVv21uNSh3XNPme9ef2914Ir8EWyCyddVbSQQZiDoRI9 IqiUMhXwCXRAYkglGItH6mAKiG65lcLidcIBChXCMMig9XNA2+ZGQoaTY/5pRMgi3cfThRDCorcn Q9xP0nCTnDp/qZ4tqAhkxgEwNCAJnCTyZQAmz9XkSlCgiML8Cw3yfYh177tOtGZ8E6KloTI93UOJ VxBRSVq9mIb68aEUE1RR6id1fb61BydYH3VScj0agPWMAXnV+OaelG6M2NKC2KGLI2N72QdYxrLm onXih9EavXifcJqeD44JQpS2ULKMrg1uzjqgjCtsiYIhDBWZL60eiQOkCzGi6wry+dO8cDzCIvOH vWGVDeBDsHXU9UXWpjicG6azM00OFB8dgl15ooB0tqLOVgbwiophp1Ig92CASPk0hG8aqcuXU0ay 45VNP35tVVkv7sX+O/MfW3AH+/Ex+1svXXmuMT9v6U/Ovwjd5LHxZroD8Ptgb8gEetI4P7he9F1B AhM5SScllXGK/C4m6wbHcuM+SSxURJzJ8wndYY8YM1oPryvVcAZW2Adje/dc3rlymhKKz3Al8L0S /+IkFJcBvBpQlPYJC7kk7phO6OmSgOdXg+57HN2X6xnVFEvcnA+kn+LSD/STJ0/UfcWf2OGIFBcV V4eh9ac9ba87BsDPHu8lBThJHr9+7khohV1urbbfg7no/Im5uDPTQHgEqxQNAAU/PHFpqjMhbAXt mVTtJMIM15lQPRDOCEypHYp26SvOBFFQQiRRKp4FNSQB4KB4HOzcHcHR3u7N4M9b9gX7yjiyN3Qb NcGzmF0iDfdIjDMSA5dcd1wS5yqGxobU6AoliHWJYBNCcJfESy3glSd8krSdTi7L6TJiZLDNOip1 3L0lHUfTVmgG2LSeIjcGpN1+4hBv1XgYJ29Y65hh8Ce/hIN3PTV6iAhM5Tgw2LZLokKXOImDr27S qfby392OJ6GRjW3WQtLKwzkdTt54MxEn9BjweGkabDKOIDHX4jsS5CpJoqPHman76U0xbVYinKlA hpWlJM8eactvPSwtKNXsW/Y/xsrYKlePoPoWR/Vh9CM9tk+6J5EnPM8GtmbtVk55/hC8Erzr+afi dR2LcL2PcceK4Fivz3WsyADMKQKmxUQN9z9wrJXk7hj9WsO2olbIWQ5HoLl1ENaS6lKawMem21Xq sJvtUcev9qjdit8Bvy5W1aVbzu+cwk8aqtD9wA+ZqGcOO4IoqYLA3IL2gJ0HZo3UkgSsn0ykvD2p urYRex2vZ2zVWJn9uf25BrYs/9qxBr0NYxgN4//0iv8fx/7/dpDA/3S8Qi6QYZpDa2kz3Uh/LcjC IqF92tgnpIQRFmRz2TK2jX0qZiPHi+i3aCU/tPETHJKhC9Xhm8kynDv8d7IRBT++evoHGcnbHtXj 3D7acGYB/zz52EefjI/btZ5hjw8ufe7JBKF/DwBBlq4aCmVuZHN0cmVhbQ1lbmRvYmoNNDUgMCBv YmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvQ0lERm9udFR5cGUyIA0vQmFzZUZvbnQgL0JE S0JLQytBcmlhbCxCb2xkIA0vRm9udERlc2NyaXB0b3IgMzcgMCBSIA0vQ0lEU3lzdGVtSW5mbyA8 PCAvUmVnaXN0cnkgKEFkb2JlKS9PcmRlcmluZyAoSWRlbnRpdHkpL1N1cHBsZW1lbnQgMCA+PiAN L0RXIDEwMDAgDS9XIFsgMyBbIDI3NyBdIDggWyA4ODkgXSAxMSAxMiAzMzMgMTYgWyAzMzMgMjc3 IF0gMTkgMjggNTU2IDM4IDM5IDcyMiANNDAgWyA2NjYgNjEwIF0gNDggWyA4MzMgXSA1MCBbIDc3 NyA2NjYgNzc3IDcyMiA2NjYgNjEwIF0gNjggWyA1NTYgNjEwIDU1NiA2MTAgNTU2IDMzMyA2MTAg XSANNzUgWyA2MTAgMjc3IF0gNzkgWyAyNzcgODg5IDYxMCBdIDgyIDg0IDYxMCA4NSBbIDM4OSA1 NTYgMzMzIDYxMCA1NTYgNzc3IDU1NiBdIA1dIA0+PiANZW5kb2JqDTQ2IDAgb2JqDTw8IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMzAyID4+IA1zdHJlYW0NCkiJVFHLboQwDLzzFT5utYck wD4qIQ4LqoRWfahLe4dgKFIJUYADf18SU7Y9AJrxjG3GLMnSTLUjsDfTyxuOULeqMjj0k5EIJTat AuFD1cpxRe4tu0IDW8y3eRixy1TdQxR57H0pDqOZYXdJr5drss/zcM8fgL2aCk2rGtjlof/xuTC3 Setv7FCNwCGOocLaY8lzoV+KDoH99d9r+awRfIfFuklf4aALiaZQDULEOQ9i+zmUMaCq/te9gFxl Lb8K493VPo8dOhM6OBRwh8I09pZOq+f024EaWlPpZFyS9+y8grxCEJkSScMEKQOa6R9J8kjDAhrt k+RE5JMjw5AQ2Y+CyHr7XUsm6660nQ3AnmrLVU7GLJG7e7pEbZatwu3kutc2Nvt4PwIMAOEqmokK ZW5kc3RyZWFtDWVuZG9iag00NyAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9DSURG b250VHlwZTIgDS9CYXNlRm9udCAvQkRLREJQK0FyaWFsLEl0YWxpYyANL0ZvbnREZXNjcmlwdG9y IDM5IDAgUiANL0NJRFN5c3RlbUluZm8gPDwgL1JlZ2lzdHJ5IChBZG9iZSkvT3JkZXJpbmcgKElk ZW50aXR5KS9TdXBwbGVtZW50IDAgPj4gDS9EVyAxMDAwIA0vVyBbIDMgWyAyNzcgXSAxMSAxMiAz MzMgMzggMzkgNzIyIDQ4IFsgODMzIF0gNTAgWyA3NzcgXSA1NCBbIDY2NiBdIDY4IA1bIDU1NiBd IDcwIFsgNTAwIDU1NiBdIDc2IFsgMjIyIF0gNzkgWyAyMjIgXSA4MSA4MiA1NTYgODUgWyAzMzMg NTAwIDI3NyA1NTYgXSANXSANPj4gDWVuZG9iag00OCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURl Y29kZSAvTGVuZ3RoIDMwOSA+PiANc3RyZWFtDQpIiVSSTW+DMAyG7/wKHzv1kBC+OqniUNgkNG2r VrY7DYYhjRAFeuDfj8SsXQ8keuw47xsblhV5oboJ2NEM8oQTNJ2qDY7DxUiEM7adAl9A3clpJbfK vtLAluLTPE7YF6oZYL/32MeSHCczw+aQv+SH47Ysoy1/APZuajSdamFThuLza4mcLlr/YI9qAg5p CjU2HsteK/1W9Qjsf/0tV84aQTj2VydDjaOuJJpKtQh7znmQ2i3apYCqvs97CVWdG/ldGe92WvDU UsAdhTmRIHomiunewFEYOop9Ikn0SNQQZam3OFi1oj9lMmKlz+4Yp1qxc7WCVERC0qsYBUMKxhSM fPJDJuMnCkbXxy9bIlYHpGnbYQd37bK8GLMMwE3X9dd2tlN4/QH0oG0T7ef9CjAAr+Sc1wplbmRz dHJlYW0NZW5kb2JqDTQ5IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL0NJREZvbnRU eXBlMiANL0Jhc2VGb250IC9CREtFSUsrQXJpYWwsQm9sZEl0YWxpYyANL0ZvbnREZXNjcmlwdG9y IDQxIDAgUiANL0NJRFN5c3RlbUluZm8gPDwgL1JlZ2lzdHJ5IChBZG9iZSkvT3JkZXJpbmcgKElk ZW50aXR5KS9TdXBwbGVtZW50IDAgPj4gDS9EVyAxMDAwIA0vVyBbIDQ4IFsgODMzIF0gNTAgWyA3 NzcgXSA1NCBbIDY2NiBdIF0gDT4+IA1lbmRvYmoNNTAgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgL0xlbmd0aCAyNDAgPj4gDXN0cmVhbQ0KSIlUkD9vwyAQxXc+xY2pMuDYqSeLIXErWVH/ qHa7Ezi7SDUgjAd/+wK2knYA9LvHO707em7qRisP9N0Z0aKHXmnpcDKzEwhXHJSGQw5SCb9RusXI LdBgbpfJ49jo3kBVEfoRxMm7BXan+vLUXPZdV+6zB6BvTqJTeoBdd8w/v0Klna39wRG1hwwYA4k9 oecXbl/5iED/+u9at1iEPPFhS2IkTpYLdFwPCFWWFRlLT8kAtfyvk2J1XXvxzR25/z7WLFG+0vNK ZaLHgpHQafPEnnH6W1QxOxemSCtKIWM8pfG2RWtsTBIP+RVgACpRc54KZW5kc3RyZWFtDWVuZG9i ag01MSAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9DSURGb250VHlwZTIgDS9CYXNl Rm9udCAvQkRLSUJQK1N5bWJvbE1UIA0vRm9udERlc2NyaXB0b3IgNDMgMCBSIA0vQ0lEU3lzdGVt SW5mbyA8PCAvUmVnaXN0cnkgKEFkb2JlKS9PcmRlcmluZyAoSWRlbnRpdHkpL1N1cHBsZW1lbnQg MCA+PiANL0RXIDEwMDAgDS9XIFsgMTEgMTIgMzMzIDE0IFsgNTQ4IF0gMTYgWyA1NDggXSAzMiBb IDU0OCBdIDg2IFsgNjAzIF0gMTE5IFsgNDk0IF0gDTE2NiBbIDcxMiAzODMgXSAxNjggMTcyIDM4 MyAxNzMgMTc2IDQ5NCAxODMgMTg4IDM4MyAxODkgMTkxIDQ5NCANXSANPj4gDWVuZG9iag01MiAw IG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDI4OSA+PiANc3RyZWFtDQpIiVRR u26EMBDs+YotE6WwMQlcgVyEy0kUeSiQ641ZCFIwloGCv48fhFMK25rdnZ3dMSnKc6mGBciHmWSF C3SDag3O02okQoP9oCBm0A5y2ZG/5Sg0EEuutnnBsVTdBHkekU+bnBezwV1dZw/0Hsi7adEMqreR R/Z1tZFq1foHR1QLUOAcWuwiUrwK/SZGBOKJt2C9aQTmcbxrTy3OWkg0QvUIOaW04e5pOg6o2v/5 KA2sppPfwkSuGn01e+YOxdQixmLmEaM+l5w9ekodSorEoyzzlTRUijTwYh5Zzb178qcVpG+jURk0 T4GbhXmd2OX0EgZpsmMJG7yke9/Qya3lLD9skqsx1kH/L94n59Cg8Pg6PWlnhjvRrwADACP9kCMK ZW5kc3RyZWFtDWVuZG9iag01MyAwIG9iag08PCANL1MgL0QgDT4+IA1lbmRvYmoNNTQgMCBvYmoN PDwgDS9OdW1zIFsgMCA1MyAwIFIgXSANPj4gDWVuZG9iag01NSAwIG9iag08PCANL1R5cGUgL1Bh Z2VzIA0vS2lkcyBbIDYwIDAgUiAxIDAgUiA0IDAgUiAxMSAwIFIgMTYgMCBSIDI1IDAgUiAyOCAw IFIgXSANL0NvdW50IDcgDT4+IA1lbmRvYmoNNTYgMCBvYmoNPDwgDS9DcmVhdGlvbkRhdGUgKEQ6 MjAwNDAxMjEwNzE4MDdaMDAnMDAnKQ0vTW9kRGF0ZSAoRDoyMDA0MDEyMTA3MTgwN1owMCcwMCcp DS9Qcm9kdWNlciAoQWNyb2JhdCBEaXN0aWxsZXIgNS4wIFwoV2luZG93c1wpKQ0vQXV0aG9yICho b2x1YmphbikNL0NyZWF0b3IgKEFET0JFUFM0LkRSViBWZXJzaW9uIDQuNTApDS9UaXRsZSAoTWlj cm9zb2Z0IFdvcmQgLSBDYWxsRHVyYXRpb25QYXBlcl92MTFfcGRmLmRvYykNPj4gDWVuZG9iag01 NyAwIG9iag08PCAvVHlwZSAvTWV0YWRhdGEgL1N1YnR5cGUgL1hNTCAvTGVuZ3RoIDExMjYgPj4g DXN0cmVhbQ0KPD94cGFja2V0IGJlZ2luPScnIGlkPSdXNU0wTXBDZWhpSHpyZVN6TlRjemtjOWQn IGJ5dGVzPScxMTI1Jz8+PHJkZjpSREYgeG1sbnM6cmRmPSdodHRwOi8vd3d3LnczLm9yZy8xOTk5 LzAyLzIyLXJkZi1zeW50YXgtbnMjJyB4bWxuczppWD0naHR0cDovL25zLmFkb2JlLmNvbS9pWC8x LjAvJz48cmRmOkRlc2NyaXB0aW9uIGFib3V0PScnIHhtbG5zPSdodHRwOi8vbnMuYWRvYmUuY29t L3BkZi8xLjMvJyB4bWxuczpwZGY9J2h0dHA6Ly9ucy5hZG9iZS5jb20vcGRmLzEuMy8nIHBkZjpD cmVhdGlvbkRhdGU9JzIwMDQtMDEtMjFUMDc6MTg6MDdaJyBwZGY6TW9kRGF0ZT0nMjAwNC0wMS0y MVQwNzoxODowN1onIHBkZjpQcm9kdWNlcj0nQWNyb2JhdCBEaXN0aWxsZXIgNS4wIChXaW5kb3dz KScgcGRmOkF1dGhvcj0naG9sdWJqYW4nIHBkZjpDcmVhdG9yPSdBRE9CRVBTNC5EUlYgVmVyc2lv biA0LjUwJyBwZGY6VGl0bGU9J01pY3Jvc29mdCBXb3JkIC0gQ2FsbER1cmF0aW9uUGFwZXJfdjEx X3BkZi5kb2MnLz4KPHJkZjpEZXNjcmlwdGlvbiBhYm91dD0nJyB4bWxucz0naHR0cDovL25zLmFk b2JlLmNvbS94YXAvMS4wLycgeG1sbnM6eGFwPSdodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAv JyB4YXA6Q3JlYXRlRGF0ZT0nMjAwNC0wMS0yMVQwNzoxODowN1onIHhhcDpNb2RpZnlEYXRlPScy MDA0LTAxLTIxVDA3OjE4OjA3WicgeGFwOkF1dGhvcj0naG9sdWJqYW4nIHhhcDpNZXRhZGF0YURh dGU9JzIwMDQtMDEtMjFUMDc6MTg6MDdaJz48eGFwOlRpdGxlPjxyZGY6QWx0PjxyZGY6bGkgeG1s Omxhbmc9J3gtZGVmYXVsdCc+TWljcm9zb2Z0IFdvcmQgLSBDYWxsRHVyYXRpb25QYXBlcl92MTFf cGRmLmRvYzwvcmRmOmxpPjwvcmRmOkFsdD48L3hhcDpUaXRsZT48L3JkZjpEZXNjcmlwdGlvbj4K PHJkZjpEZXNjcmlwdGlvbiBhYm91dD0nJyB4bWxucz0naHR0cDovL3B1cmwub3JnL2RjL2VsZW1l bnRzLzEuMS8nIHhtbG5zOmRjPSdodHRwOi8vcHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLycgZGM6 Y3JlYXRvcj0naG9sdWJqYW4nIGRjOnRpdGxlPSdNaWNyb3NvZnQgV29yZCAtIENhbGxEdXJhdGlv blBhcGVyX3YxMV9wZGYuZG9jJy8+CjwvcmRmOlJERj48P3hwYWNrZXQgZW5kPSdyJz8+CmVuZHN0 cmVhbQ1lbmRvYmoNeHJlZg0wIDU4IA0wMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwOTY2MTggMDAw MDAgbg0KMDAwMDA5Njc2OSAwMDAwMCBuDQowMDAwMDk2OTE1IDAwMDAwIG4NCjAwMDAxMDQ1OTIg MDAwMDAgbg0KMDAwMDEwNDc0MyAwMDAwMCBuDQowMDAwMTA1MDE0IDAwMDAwIG4NCjAwMDAxMDg2 MTAgMDAwMDAgbg0KMDAwMDExOTkzMiAwMDAwMCBuDQowMDAwMTIyMTA3IDAwMDAwIG4NCjAwMDAx MjQzMzYgMDAwMDAgbg0KMDAwMDEyNzkyNyAwMDAwMCBuDQowMDAwMTI4MDgxIDAwMDAwIG4NCjAw MDAxMjgzNDQgMDAwMDAgbg0KMDAwMDEzMzM2MSAwMDAwMCBuDQowMDAwMTM2OTY4IDAwMDAwIG4N CjAwMDAxNDA1NzIgMDAwMDAgbg0KMDAwMDE0MDcyNiAwMDAwMCBuDQowMDAwMTQwOTkyIDAwMDAw IG4NCjAwMDAxNDIwNjAgMDAwMDAgbg0KMDAwMDE0NjIyNiAwMDAwMCBuDQowMDAwMTUwNzAxIDAw MDAwIG4NCjAwMDAxNTYzOTMgMDAwMDAgbg0KMDAwMDE2MDQ4NCAwMDAwMCBuDQowMDAwMTYzOTg0 IDAwMDAwIG4NCjAwMDAxNjY5NjMgMDAwMDAgbg0KMDAwMDE2NzExNyAwMDAwMCBuDQowMDAwMTY3 Mjg4IDAwMDAwIG4NCjAwMDAxNzQzNTEgMDAwMDAgbg0KMDAwMDE3NDUwNSAwMDAwMCBuDQowMDAw MTc0NjY0IDAwMDAwIG4NCjAwMDAxNzkwNjkgMDAwMDAgbg0KMDAwMDE3OTIyNCAwMDAwMCBuDQow MDAwMTc5MzgxIDAwMDAwIG4NCjAwMDAxNzk0MzAgMDAwMDAgbg0KMDAwMDE4MDI4NyAwMDAwMCBu DQowMDAwMTgwNDQ4IDAwMDAwIG4NCjAwMDAxODA2MDEgMDAwMDAgbg0KMDAwMDE4MDgyOCAwMDAw MCBuDQowMDAwMTk5NzE5IDAwMDAwIG4NCjAwMDAxOTk5MzMgMDAwMDAgbg0KMDAwMDIwOTUwMSAw MDAwMCBuDQowMDAwMjA5NzIxIDAwMDAwIG4NCjAwMDAyMTcxOTQgMDAwMDAgbg0KMDAwMDIxNzM5 OSAwMDAwMCBuDQowMDAwMjI2Mjg0IDAwMDAwIG4NCjAwMDAyMjY3MjkgMDAwMDAgbg0KMDAwMDIy NzEwNSAwMDAwMCBuDQowMDAwMjI3NDU5IDAwMDAwIG4NCjAwMDAyMjc4NDIgMDAwMDAgbg0KMDAw MDIyODA4NyAwMDAwMCBuDQowMDAwMjI4NDAxIDAwMDAwIG4NCjAwMDAyMjg3MzcgMDAwMDAgbg0K MDAwMDIyOTEwMCAwMDAwMCBuDQowMDAwMjI5MTMxIDAwMDAwIG4NCjAwMDAyMjkxNzUgMDAwMDAg bg0KMDAwMDIyOTI4MSAwMDAwMCBuDQowMDAwMjI5NTM4IDAwMDAwIG4NCnRyYWlsZXINPDwNL1Np emUgNTgNL0lEWzw5ZGM3NDgwNDJmNTE0YjVmNDM2YjY2OWU5MmZlYTk5Mz48YzFiZDdlY2UwM2Nj ZDQ4N2VlNWZhYzM5OTc4NGIyMGQ+XQ0+Pg1zdGFydHhyZWYNMTczDSUlRU9GDQ== ------=_NextPart_000_0007_01CAFF19.ADC562E0-- From hoene@uni-tuebingen.de Mon May 31 02:28:29 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98CAA3A6A02 for ; Mon, 31 May 2010 02:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=-2.281, BAYES_99=3.5, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwrGf32IyqiW for ; Mon, 31 May 2010 02:28:18 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 9A5323A69EC for ; Mon, 31 May 2010 02:28:13 -0700 (PDT) Received: from hoeneT60 (eap111066.extern.uni-tuebingen.de [134.2.111.66]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4V9Ro85015299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 31 May 2010 11:27:51 +0200 From: "Christian Hoene" To: Date: Mon, 31 May 2010 11:27:48 +0200 Message-ID: <000b01cb00a3$8c9ab710$a5d02530$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01CB00B4.50238710" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsAo4RifaTQhJwsT5arhJbNjrLEKw== Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.242; VDF: 7.10.7.197; host: mx05); id=10533-LrXbFn Subject: [codec] Measuring the algorithmic efficiency of the IWAC X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 09:28:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000C_01CB00B4.50238710 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 in the last weeks we had a couple of discussion on the complexity or = algorithmic efficiency of the = codec. Knowing the algorithmic efficiency is important because: 1. the complexity has an impact on power consumption and system = costs,=20 2. the hardware can be selected to fit pre-known complexity = requirement, and 3. different codec proposals can be compared if they are show = similar performance in other aspects. Before any complexity comparisons can be made, we need an objective, = precise, reliable, and repeatable metric on how to measure the algorithmic efficiency. Let me describe three different approaches: =20 Classic Approach used in Codec Standardization =20 In the last 17 years, the ITU-T Study Group 16 measure the complexity of = codecs using a library called ITU-T Basic Operators (described in ITU-T = G.191), that counts the kind and number of operations and the amount of memory. The last version of the standard (03/10), not yet = publically available, supports - beside fix-point operations of different widths - also floating operations. Each operation can be = counted automatically and weighted accordingly. The following source code is an excerpt from baseop32.h =20 /*_______________________________________________________________________= ____ | = | | Prototypes for basic arithmetic operators = | = |________________________________________________________________________= ___| */ =20 Word16 add (Word16 var1, Word16 var2); /* Short add, 1 */ Word16 sub (Word16 var1, Word16 var2); /* Short sub, 1 */ Word16 abs_s (Word16 var1); /* Short abs, 1 */ Word16 shl (Word16 var1, Word16 var2); /* Short shift left, 1 */ Word16 shr (Word16 var1, Word16 var2); /* Short shift right, 1 */ =85 Word16 div_s (Word16 var1, Word16 var2); /* Short division, 18 */ Word16 norm_l (Word32 L_var1); /* Long norm, 1 */ =20 In the upcoming ITU-T G.GSAD standard another approach has been used as = shown in the following code example. For each operation, WMPOS function have been added, which count the number of operations. If = the algorithmic efficiency of an algorithm has to be measured, the program is run and the operations are counted.=20 =20 for (i=3D0; iband_enrg_long_fx[i] =3D 30; state_fx->band_enrg_fx[i] =3D 30; state_fx->band_enrg_bgd_fx[i] =3D 30; =20 state_fx->min_band_enrg_fx[i] =3D 30; } =20 These two similar examples worked well in the years and are an = established procedure to count operations and complexity. Still, it has some drawbacks a) Existing algorithm must be modified manually to address the = counting of operations. This is time consuming.=20 b) The CPU model is simplistic as it does not consider memory = access (e.g. cache), parallel executions, or other kind of optimization done in modern microprocessor and compilers. Thus, the = number of instruction might not correlated well with the actual execution time on modern CPUs. Profiling: The Classic Approach used in Software Engineering =20 Citing Wikipedia = : =84In = software engineering , program profiling, = software profiling or simply profiling, a form of dynamic program analysis = (as opposed tostatic code analysis ), is the = investigation of a program's behavior using information gathered as the program executes. The usual purpose of this analysis is to determine = which sections of a program to optimize - to = increase its overall speed, decrease its memory requirement or sometimes both. * A (code) profiler is a performance analysis tool that, most = commonly, measures only the frequency and duration of function calls, but there are other specific types of profilers (e.g. memory = profilers ) in addition to more comprehensive profilers, capable of gathering extensive performance data. * An instruction set simulator = which is also = =97 by necessity =97 a profiler, can measure the totality of a program's behaviour from = invocation to termination.=93 Thus, a typical profiler such as gprof can be used to measure and = understand the complexity of a codec implementation. It is precise because it is uses on modern computers. However, if used for = standardization, it has the following drawback. a) The execution times depend on the CPU architecture, the PC in = general, the OS and parallel running programs. As such it cannot produce reliable and repeatable results. The results are not = comparable if done under slightly changed conditions. Suggestion: Use a Cycle Accurate Simulator Wikipedia: =84A Cycle Accurate Simulator (CAS) is a computer program = that simulates a microarchitecture = cycle-accurate. In contrast an instruction set = simulator simulates an Instruction = Set Architecture usually faster but not cycle-accurate to a specific implementation of this architecture.=93 Then, the execution times are precise and they are repeatable. If two = parties make measurements using different CPUs, they still get the same results. Of course, a cycle accurate simulator is slower than = the real CPU at a factor of about 100. =20 Actually, there is an open-source Cycle accurate simulator called PTLsim = avaible that simulates an Pentium IV. =84PTLsim is a cycle accurate x86 microprocessor simulator and = virtual machine for the x86 and x86-64 instruction sets. PTLsim models a modern superscalar out of order x86-64 compatible processor = core at a configurable level of detail ranging from full-speed native execution on the host CPU all the way down to RTL level models of = all key pipeline structures. In addition, all microcode, the complete cache hierarchy, memory subsystem and supporting hardware = devices are modeled with true cycle accuracy. PTLsim supports the full x86-64 instruction set of the Pentium 4+, Athlon 64 and similar = machines with all extensions (x86-64, SSE/SSE2/SSE3, MMX, x87). It is currently the only tool available to the public to support = true cycle accurate modeling of real x86 microarchitectures. [=85] PTLsim is used extensively at hundreds of major universities, = industry research labs and the well known x86 microprocessor vendors Intel and AMD.=93 Thus, I would suggest to use the Cycle Accurate Simulator PTLsim to = measure the complexity of the IETF audio codec contributions because a) it makes precise performance measurements using a modern, = widely deployed CPU platform, b) the measurement are repeatable and can be made by everybody, c) existing source code can be used without significant changes, = and=20 d) it is time-saving and easy to use. With best regards, Christian Hoene =20 --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ =20 ------=_NextPart_000_000C_01CB00B4.50238710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

in the last weeks we had a couple of discussion on the = complexity or algorithmic efficiency of the codec. Knowing the algorithmic efficiency is = important because:

1.      the complexity has an impact = on power consumption and system costs,

2.      the hardware can be selected = to fit pre-known complexity requirement, and

3.      different codec proposals = can be compared if they are show similar performance in other = aspects.

Before any complexity comparisons can be made, we need an = objective, precise, reliable, and repeatable metric on how to measure the = algorithmic efficiency. Let me describe three different = approaches:

 

Classic Approach used in = Codec Standardization

 

In the last 17 years, the ITU-T Study Group 16 measure the = complexity of codecs using a library called ITU-T Basic Operators (described in = ITU-T G.191), that counts the kind and number of operations and the amount = of memory. The last version of the standard (03/10), not yet publically = available, supports - beside fix-point operations of different widths - also = floating operations.=A0 Each operation can be counted automatically and weighted accordingly. The following source code is an excerpt from = baseop32.h

 

/*_________________________________________________________________= __________

=A0|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0|

=A0|=A0=A0 = Prototypes for basic arithmetic = operators=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 |

=A0|_______________________________________________________________= ____________|

*/

 

Word16 add (Word16 = var1, Word16 var2);=A0=A0=A0 /* Short add,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 1=A0=A0 */

Word16 sub (Word16 = var1, Word16 var2);=A0=A0=A0 /* Short sub,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = 1=A0=A0 */

Word16 abs_s = (Word16 var1);=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* Short = abs,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0 = */

Word16 shl (Word16 = var1, Word16 var2);=A0=A0=A0 /* Short shift left,=A0=A0=A0 1=A0=A0 = */

Word16 shr (Word16 = var1, Word16 var2);=A0=A0=A0 /* Short shift right,=A0=A0 1=A0=A0 = */

…

Word16 div_s = (Word16 var1, Word16 var2); /* Short division,=A0=A0=A0=A0=A0=A0 18=A0 = */

Word16 norm_l = (Word32 L_var1);=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* Long = norm,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0 = */

 

In the upcoming ITU-T G.GSAD standard another approach has been = used as shown in the following code example. For each operation, WMPOS = function have been added, which count the number of operations. If the algorithmic = efficiency of an algorithm has to be measured, the program is run and the = operations are counted.

 

=A0=A0=A0 for (i=3D0; i<NUM_BAND; i++)

=A0=A0=A0 {

#ifdef = WMOPS_FX

=A0=A0=A0=A0=A0=A0=A0 move32();move32();

=A0=A0=A0=A0=A0=A0=A0 move32();move32();

#endif

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0 state_fx->band_enrg_long_fx[i] =3D 30;

=A0=A0=A0=A0=A0=A0=A0 state_fx->band_enrg_fx[i] =3D 30;

=A0=A0=A0=A0=A0=A0=A0 state_fx->band_enrg_bgd_fx[i] =3D 30;=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0 state_fx->min_band_enrg_fx[i] =3D 30;

=A0=A0=A0 }

 

These two similar examples worked well in the years and are an established procedure to count operations and complexity. Still, it has = some drawbacks

a)      = Existing algorithm must be modified manually to address the counting of = operations. This is time consuming.

b)      = The CPU model is simplistic as it does not consider memory access (e.g. cache), = parallel executions, or other kind of optimization done in modern microprocessor = and compilers. Thus, the number of instruction might not correlated well = with the actual execution time on modern CPUs.

Profiling: The Classic = Approach used in Software Engineering

 

Citing Wi= kipedia: „In software engineering, program = profiling, software profiling or simply profiling, a form of dynamic program analysis (as = opposed tostatic code analysis), is the = investigation of a program's behavior using information gathered as the program executes. = The usual purpose of this analysis is to determine which sections of a = program to optimize - to = increase its overall speed, decrease its memory requirement or sometimes = both.

=B7         A (code) = profiler is a performance analysis tool that, most commonly, measures only = the frequency and duration of function calls, but there are other specific = types of profilers (e.g. memory profilers) in = addition to more comprehensive profilers, capable of gathering extensive = performance data.

=B7         An instruction set = simulator which is also — by necessity — a profiler, can measure the totality = of a program's behaviour from invocation to = termination.“

Thus, a typical profiler such as gprof can be used to measure = and understand the complexity of a codec implementation. It is precise = because it is uses on modern computers. However, if used for standardization, it = has the following drawback.

a)      The execution times depend on the CPU = architecture, the PC in general, the OS and parallel running programs. As such it = cannot produce reliable and repeatable results. The results are not comparable = if done under slightly changed conditions.

Suggestion: Use a Cycle = Accurate Simulator

Wikipedia: „A Cycle Accurate = Simulator (CAS) is a computer program = that simulates a microarchitecture cycle-accurate. In contrast = an instruction set simulator simulates an Instruction Set = Architecture usually faster but not = cycle-accurate to a specific implementation of this = architecture.“

Then, the execution times are precise and they are repeatable. = If two parties make measurements using different CPUs, they still get the same = results. Of course, a cycle accurate simulator is slower than the real CPU at a = factor of about 100.

 

Actually, there is an open-source Cycle accurate simulator = called PTLsim avaible that simulates an = Pentium IV. „PTLsim is a cycle accurate x86 microprocessor = simulator and virtual machine for the x86 and x86-64 instruction sets. PTLsim models a modern superscalar out of order x86-64 compatible processor = core at a configurable level of detail ranging from full-speed native execution on = the host CPU all the way down to RTL level models of all key = pipeline structures. In addition, all microcode, the complete cache hierarchy, = memory subsystem and supporting hardware devices are modeled with true cycle = accuracy. PTLsim supports the full x86-64 instruction set of the Pentium = 4+, Athlon 64 and similar machines with all extensions (x86-64, = SSE/SSE2/SSE3, MMX, x87). It is currently the only tool available to the public to = support true cycle accurate modeling of real x86 microarchitectures. […] = PTLsim is used extensively at = hundreds of major universities, industry research labs and the well known x86 microprocessor vendors Intel and = AMD.“

Thus, I would suggest to use the Cycle Accurate = Simulator PTLsim to measure the complexity of = the IETF audio codec contributions because

a)        it makes = precise performance measurements using a modern, widely deployed CPU = platform,

b)        the measurement = are repeatable and can be made by = everybody,

c)        existing source = code can be used without significant changes, and =

d)        it is = time-saving and easy to use.

With best = regards,

=A0Christian Hoene

 

----------------------------------------------= -----------------

Dr.-Ing. Christian = Hoene

Interactive Communication Systems (ICS), = University of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 = 7071 2970532

http://www.net.uni-tuebingen.de/

 

------=_NextPart_000_000C_01CB00B4.50238710-- From stephen.botzko@gmail.com Mon May 31 03:54:39 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B15A3A67D7 for ; Mon, 31 May 2010 03:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSTixGGJ3TZf for ; Mon, 31 May 2010 03:54:37 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id F328E3A67D1 for ; Mon, 31 May 2010 03:54:36 -0700 (PDT) Received: by wye20 with SMTP id 20so2437025wye.31 for ; Mon, 31 May 2010 03:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=nDZab43UGjOgo14/wQipsXudsnDp0ZcnDr457ZPDeZw=; b=JdaVKDebAOjoVKLxkQOo0/HJs5fHDGV3nACNBwQEshHeHAXalAJqnCsJJuSdyk5hxS x6/mLhJnBNcJHdSrZUbLxhNxg513CVFaRT31mpTCpr6uFB50l4rk/aX+3tbsxJLtA9su e5Z1GK5DHaTRJKDgtqWnMBHj2gkyw58BTXaPU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=g38Z15o6oJNGbgHijhUqVemGFgMIC36an0yOoaJrTbTezhqWkxc54d9cFpXgxXXRyW kyTArTzh7KlPcMfFiV78bb14vyQ4Xcovyv5zNlCtg27Bh5nkuHJF21tEs+vNkoN2z4Gq iqurhXQ0Nxf8dQUERu4pQOGKkg1NYZ50VDk4g= MIME-Version: 1.0 Received: by 10.227.154.204 with SMTP id p12mr4108731wbw.141.1275303258595; Mon, 31 May 2010 03:54:18 -0700 (PDT) Received: by 10.216.23.5 with HTTP; Mon, 31 May 2010 03:54:18 -0700 (PDT) In-Reply-To: <000b01cb00a3$8c9ab710$a5d02530$@de> References: <000b01cb00a3$8c9ab710$a5d02530$@de> Date: Mon, 31 May 2010 06:54:18 -0400 Message-ID: From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=0016364165efb5a48f0487e1add1 Cc: codec@ietf.org Subject: Re: [codec] Measuring the algorithmic efficiency of the IWAC X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 10:54:39 -0000 --0016364165efb5a48f0487e1add1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Christian Are you implying that the complexity is only a requirement for x86 machines? >>> different codec proposals can be compared if they are show similar performance in other aspects. >>> There's been no discussion on this point. In my view, at some point in the process we set a complexity bound which all codecs proposals will have to meet. That is quite different from the above statement. Regards Stephen Botzko On Mon, May 31, 2010 at 5:27 AM, Christian Hoene wr= ote: > Hi, > > > > in the last weeks we had a couple of discussion on the complexity or algo= rithmic > efficiency of the > codec. Knowing the algorithmic efficiency is important because: > > 1. the complexity has an impact on power consumption and system > costs, > > 2. the hardware can be selected to fit pre-known complexity > requirement, and > > 3. different codec proposals can be compared if they are show simila= r > performance in other aspects. > > Before any complexity comparisons can be made, we need an objective, > precise, reliable, and repeatable metric on how to measure the algorithmi= c > efficiency. Let me describe three different approaches: > > > > *Classic Approach used in Codec Standardization* > > > > In the last 17 years, the ITU-T Study Group 16 measure the complexity of > codecs using a library called ITU-T Basic Operators (described in ITU-T > G.191), that counts the > kind and number of operations and the amount of memory. The last version = of > the standard (03/10), not yet publically available, supports - beside > fix-point operations of different widths - also floating operations. Eac= h > operation can be counted automatically and weighted accordingly. The > following source code is an excerpt from baseop32.h > > > > > /*_______________________________________________________________________= ____ > > | > | > > | Prototypes for basic arithmetic > operators | > > > |_______________________________________________________________________= ____| > > */ > > > > Word16 add (Word16 var1, Word16 var2); /* Short add, 1 */ > > Word16 sub (Word16 var1, Word16 var2); /* Short sub, 1 */ > > Word16 abs_s (Word16 var1); /* Short abs, 1 */ > > Word16 shl (Word16 var1, Word16 var2); /* Short shift left, 1 */ > > Word16 shr (Word16 var1, Word16 var2); /* Short shift right, 1 */ > > =85 > > Word16 div_s (Word16 var1, Word16 var2); /* Short division, 18 */ > > Word16 norm_l (Word32 L_var1); /* Long norm, 1 */ > > > > In the upcoming ITU-T G.GSAD standard another approach has been used as > shown in the following code example. For each operation, WMPOS function > have been added, which count the number of operations. If the algorithmic > efficiency of an algorithm has to be measured, the program is run and the > operations are counted. > > > > for (i=3D0; i > { > > #ifdef WMOPS_FX > > move32();move32(); > > move32();move32(); > > #endif > > > > state_fx->band_enrg_long_fx[i] =3D 30; > > state_fx->band_enrg_fx[i] =3D 30; > > state_fx->band_enrg_bgd_fx[i] =3D 30; > > state_fx->min_band_enrg_fx[i] =3D 30; > > } > > > > These two similar examples worked well in the years and are an establishe= d > procedure to count operations and complexity. Still, it has some drawback= s > > a) Existing algorithm must be modified manually to address the > counting of operations. This is time consuming. > > b) The CPU model is simplistic as it does not consider memory access > (e.g. cache), parallel executions, or other kind of optimization done in > modern microprocessor and compilers. Thus, the number of instruction migh= t > not correlated well with the actual execution time on modern CPUs. > > *Profiling: The Classic Approach used in Software Engineering* > > * * > > Citing Wikipedia: > =84In software engineering, program > profiling, software profiling or simply profiling, a form of dynamic > program analysis = (as > opposed tostatic code analysis), > is the investigation of a program's behavior using information gathered a= s > the program executes. The usual purpose of this analysis is to determine > which sections of a program to optimize - > to increase its overall speed, decrease its memory requirement or sometim= es > both. > > =B7 A (code) profiler is a performance analysis tool that, most > commonly, measures only the frequency and duration of function calls, but > there are other specific types of profilers (e.g. memory profilers) > in addition to more comprehensive profilers, capable of gathering extensi= ve > performance data. > > =B7 An instruction set simulator which > is also =97 by necessity =97 a profiler, can measure the totality of a pr= ogram's > behaviour from invocation to termination.=93 > > Thus, a typical profiler such as gprof can be used to measure and > understand the complexity of a codec implementation. It is precise becaus= e > it is uses on modern computers. However, if used for standardization, it = has > the following drawback. > > a) The execution times depend on the CPU architecture, the PC in > general, the OS and parallel running programs. As such it cannot produce > reliable and repeatable results. The results are not comparable if done > under slightly changed conditions. > > *Suggestion: Use a Cycle Accurate Simulator* > > Wikipedia: =84A Cycle Accurate Simulator (CAS) is a computer program that > simulates a microarchitecture > cycle-accurate. In contrast an instruction set simulator > simulates an Instruction Set Architecture > usually faster but not cycle-accurate to a specific implementation of > this architecture.=93 > > Then, the execution times are precise and they are repeatable. If two > parties make measurements using different CPUs, they still get the same > results. Of course, a cycle accurate simulator is slower than the real CP= U > at a factor of about 100. > > > > Actually, there is an open-source Cycle accurate simulator called PTLsim<= http://www.ptlsim.org/>avaible that simulates an Pentium IV. =84PTLsim is a= cycle accurate x86 > microprocessor simulator and virtual machine for the x86 and x86-64 > instruction sets. PTLsim models a modern superscalar out of order > x86-64 compatible processor core at a configurable level of detail rangin= g > from full-speed native execution on the host CPU all the way down to RTL > level models of all key pipeline structures. In addition, all microcode, = the > complete cache hierarchy, memory subsystem and supporting hardware device= s > are modeled with true cycle accuracy. PTLsim supports the full x86-64 > instruction set of the Pentium 4+, Athlon 64 and similar machines with al= l > extensions (x86-64, SSE/SSE2/SSE3, MMX, x87). It is currently the only to= ol > available to the public to support true cycle accurate modeling of real x= 86 > microarchitectures. [=85] PTLsim is used extensively at hundreds of major > universities, industry research labs and the well known x86 microprocesso= r > vendors Intel and AMD.=93 > > Thus, I would suggest to use the Cycle Accurate Simulator PTLsim to > measure the complexity of the IETF audio codec contributions because > > a) it makes precise performance measurements using a modern, widel= y > deployed CPU platform, > > b) the measurement are repeatable and can be made by everybody, > > c) existing source code can be used without significant changes, > and > > d) it is time-saving and easy to use. > > With best regards, > > Christian Hoene > > > > --------------------------------------------------------------- > > Dr.-Ing. Christian Hoene > > Interactive Communication Systems (ICS), University of T=FCbingen > > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > > http://www.net.uni-tuebingen.de/ > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > --0016364165efb5a48f0487e1add1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Christian

Are you implying that the complexity is only a requirem= ent for x86 machines?=A0

>>>
different codec proposals can be compared if they are show similar performance in other aspects.
<= /font>>>>
There's been no discussion on this point.=A0 In m= y view, at some point in the process we set a complexity bound which all co= decs proposals will have to meet.=A0 That is quite different from the above= statement.

Regards
Stephen Botzko



On = Mon, May 31, 2010 at 5:27 AM, Christian Hoene <hoene@uni-tuebingen.de> wr= ote:

Hi,

=A0

in the last weeks we had a couple of discussi= on on the complexity or algorithmic efficiency of the codec. Knowing the algorithmic efficiency is importan= t because:

1.=A0=A0=A0=A0=A0 the complexity has an impact on= power consumption and system costs,

2.=A0=A0=A0=A0=A0 the hardware can be selected to= fit pre-known complexity requirement, and

3.=A0=A0=A0=A0=A0 different codec proposals can b= e compared if they are show similar performance in other aspects.

Before any complexity comparisons can be made= , we need an objective, precise, reliable, and repeatable metric on how to measure the algorithmic efficiency. Let me describe three different approaches:

=A0

Classic Approach used i= n Codec Standardization

=A0

In the last 17 years, the ITU-T Study Group 1= 6 measure the complexity of codecs using a library called ITU-T Basic Operators (described in ITU-= T G.191), that counts the kind and number of operations and the amount of memory. The last version of the standard (03/10), not yet publically availa= ble, supports - beside fix-point operations of different widths - also floating operations.=A0 Each operation can be counted automatically and weighted accordingly. The following source code is an excerpt from baseop32.h=

=A0

/*_= __________________________________________________________________________<= /span>

=A0= |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0|

=A0= |=A0=A0 Prototypes for basic arithmetic operators=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |

=A0= |__________________________________________________________________________= _|

*/<= /span>

=A0=

Wor= d16 add (Word16 var1, Word16 var2);=A0=A0=A0 /* Short add,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0 = */

Wor= d16 sub (Word16 var1, Word16 var2);=A0=A0=A0 /* Short sub,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0 = */

Wor= d16 abs_s (Word16 var1);=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* Short abs,=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 1=A0=A0 */

Wor= d16 shl (Word16 var1, Word16 var2);=A0=A0=A0 /* Short shift left,=A0=A0=A0 1=A0=A0 */

Wor= d16 shr (Word16 var1, Word16 var2);=A0=A0=A0 /* Short shift right,=A0=A0 1=A0=A0 */=

=85=

Wor= d16 div_s (Word16 var1, Word16 var2); /* Short division,=A0=A0=A0=A0=A0=A0 18=A0 */

Wor= d16 norm_l (Word32 L_var1);=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* Long norm,=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 1=A0 */

=A0

In the upcoming ITU-T G.GSAD standard another= approach has been used as shown in the following code example. For each operation, WMPOS function= have been added, which count the number of operations. If the algorithmic effici= ency of an algorithm has to be measured, the program is run and the operations a= re counted.

=A0

=A0=A0=A0 for (i=3D0; i<NUM_BAND; i++)

=A0=A0=A0 {

#ifdef WMOPS_FX

=A0=A0=A0=A0=A0=A0=A0 move32();move32();

=A0=A0=A0=A0=A0=A0=A0 move32();move32();

#endif

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0=A0=A0=A0=A0=A0=A0 state_fx->band_enrg_long_fx[i] =3D 30;

=A0=A0=A0=A0=A0=A0=A0 state_fx->band_enrg_fx[i] =3D 30;

=A0=A0=A0=A0=A0=A0=A0 state_fx->band_enrg_bgd_fx[i] =3D 30;=A0=A0

=A0=A0=A0=A0=A0=A0=A0 state_fx->min_band_enrg_fx[i] =3D 30;

=A0=A0=A0 }

=A0

These two similar examples worked well in the= years and are an established procedure to count operations and complexity. Still, it has som= e drawbacks

a)=A0=A0=A0=A0=A0 = Existing algorithm must be modified manually to address the counting of operations. = This is time consuming.

b)=A0=A0=A0=A0=A0 = The CPU model is simplistic as it does not consider memory access (e.g. cache), parallel executions, or other kind of optimization done in modern microprocessor and compilers. Thus, the number of instruction might not correlated well with t= he actual execution time on modern CPUs.

Profiling: The Classic = Approach used in Software Engineering

=A0

Citing Wikipedia: =84In=A0software engineering,=A0pro= gram profiling,=A0software profiling=A0or simply=A0profiling, a form of=A0dynamic program analysis=A0(as opposed tostatic code analysis), is the inv= estigation of a program's behavior using information gathered as the program executes= . The usual purpose of this analysis is to determine which sections of a program to=A0optimize= =A0- to increase its overall speed, decrease its memory requirement or sometimes both.

=B7=A0=A0=A0=A0=A0=A0=A0=A0 A=A0(code) profiler=A0is a=A0performance analysis=A0tool that, most commonly, measures only the frequency and duration of function calls, but there are other specific type= s of profilers (e.g.=A0memory profilers) in addition to more comprehensive profilers, capable of gathering extensive performance data.

=B7=A0=A0=A0=A0=A0=A0=A0=A0 An=A0instruction set simulator=A0which is also =97 by necessity =97 a profiler, can measure the totality of a program's behaviour from invocation to termination.=93

Thus, a typical profiler such as gprof can be= used to measure and understand the complexity of a codec implementation. It is precise because = it is uses on modern computers. However, if used for standardization, it has t= he following drawback.

a)=A0= =A0=A0=A0=A0 The execution times depend on the CPU architecture= , the PC in general, the OS and parallel running programs. As such it cannot produce reliable and repeatable results. The results are not comparable if = done under slightly changed conditions.

Suggestion: Use a Cycle= Accurate Simulator

Wikipedia: =84A=A0Cycle Accurate Simulator=A0(CAS) is a comp= uter program that simulates a=A0microarchitecture=A0cycle-accurate. In contrast an=A0instruction set simulator=A0simulates an=A0Instruction Set Architecture=A0usuall= y faster but not cycle-accurate to a specific implementation of this architecture.=93

Then, the execution times are precise and the= y are repeatable. If two parties make measurements using different CPUs, they still get the same res= ults. Of course, a cycle accurate simulator is slower than the real CPU at a fact= or of about 100.

=A0

Actually, there is an open-source Cycle accur= ate simulator called P= TLsim avaible that simulates an Pentium IV. =84PTLsim=A0is a=A0cycle accurate x86 microprocessor simulator=A0and virtual machine for the x86 and x86-64 instruction sets. PTLsim models a modern=A0superscalar out of order x86-64=A0compatible processor core at a configurable level of detail ranging from full-speed native execution on th= e host CPU all the way down to=A0RTL level models=A0of all key pipeline structures. In addition, all microcode, the complete cache hierarchy, memor= y subsystem and supporting hardware devices are modeled with true cycle accur= acy. PTLsim supports the=A0full x86-64 instruction set=A0of the Pentium 4+, Athlon 64 and similar machines with all extensions (x86-64, SSE/SSE2/SSE3, = MMX, x87). It is currently the=A0only tool available to the public=A0to support true cycle accurate modeling of real x86 microarchitectures. [=85] PTLsim is used extensively at h= undreds of major universities, industry research labs and the well known x86 microprocessor vendors Intel and AMD.=93

Thus= , I would suggest to use the Cycle Accurate Simulator=A0PTLsim to mea= sure the complexity of the IETF audio codec contributions because

a)=A0=A0=A0=A0=A0=A0=A0 it makes precise performance measurements using a modern, widely deployed CPU platform,

b)=A0=A0=A0=A0=A0=A0=A0 the measurement a= re repeatable and can be made by everybody,

c)=A0=A0=A0=A0=A0=A0=A0 existing source c= ode can be used without significant changes, and

d)=A0=A0=A0=A0=A0=A0=A0 it is time-saving= and easy to use.

With best regards,

=A0C= hristian Hoene

=A0

--------------------------------------------------------------= -

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532

http://www.net.uni-tuebingen.de/

=A0


_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec


--0016364165efb5a48f0487e1add1-- From hoene@uni-tuebingen.de Mon May 31 04:50:30 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B046E3A69D7 for ; Mon, 31 May 2010 04:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=-1.825, BAYES_99=3.5, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LikIA95q1nIu for ; Mon, 31 May 2010 04:50:19 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id E27A43A6A21 for ; Mon, 31 May 2010 04:50:17 -0700 (PDT) Received: from hoeneT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o4VBnm1V026113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 31 May 2010 13:49:49 +0200 From: "Christian Hoene" To: "'stephen botzko'" References: <000b01cb00a3$8c9ab710$a5d02530$@de> In-Reply-To: Date: Mon, 31 May 2010 13:49:46 +0200 Message-ID: <000f01cb00b7$5f7ddb90$1e7992b0$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01CB00C8.2306AB90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsAr6SKeLufu6bqS2+nVo/3LEUOzgABaGFA Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] Measuring the algorithmic efficiency of the IWAC X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 11:50:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0010_01CB00C8.2306AB90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Stephen, =20 comments inline =20 Are you implying that the complexity is only a requirement for x86 = machines? =20 Hoene: No, complexity is a requirement for all machines. However, x86 = machines are distributed and used widely on PC, notebook and also sometimes also in embedded systems. Also, the contributed source = code is only available for PCs like system not for DSPs. Thus, any testing on DSP will not be possible. However, you are free to suggest other reference platforms such as * ARM: http://facsim.snu.ac.kr/ * C64x+ CPU Cycle Accurate Simulator: = http://processors.wiki.ti.com/index.php/C64x%2B_CPU_Cycle_Accurate_Simula= tor Just a matter of choice (and availability). >>> different codec proposals can be compared if they are show similar = performance in other aspects. >>> There's been no discussion on this point. In my view, at some point in = the process we set a complexity bound which all codecs proposals will have to meet. =20 Hoene: Agreed. However, before agreeing on bound, we have to agree on a = measure and metric. My last email is on suggestion on how to measure precise and time saving while covering the most typical usage = scenarios. Christian =20 That is quite different from the above statement. =20 Regards Stephen Botzko On Mon, May 31, 2010 at 5:27 AM, Christian Hoene = wrote: Hi, =20 in the last weeks we had a couple of discussion on the complexity or = algorithmic efficiency of the = codec. Knowing the algorithmic efficiency is important because: 1. the complexity has an impact on power consumption and system = costs,=20 2. the hardware can be selected to fit pre-known complexity = requirement, and 3. different codec proposals can be compared if they are show = similar performance in other aspects. Before any complexity comparisons can be made, we need an objective, = precise, reliable, and repeatable metric on how to measure the algorithmic efficiency. Let me describe three different approaches: =20 Classic Approach used in Codec Standardization =20 In the last 17 years, the ITU-T Study Group 16 measure the complexity of = codecs using a library called ITU-T Basic Operators (described in ITU-T = G.191), that counts the kind and number of operations and the amount of memory. The last version of the standard (03/10), not yet = publically available, supports - beside fix-point operations of different widths - also floating operations. Each operation can be = counted automatically and weighted accordingly. The following source code is an excerpt from baseop32.h =20 /*_______________________________________________________________________= ____ | = | | Prototypes for basic arithmetic operators = | = |________________________________________________________________________= ___| */ =20 Word16 add (Word16 var1, Word16 var2); /* Short add, 1 */ Word16 sub (Word16 var1, Word16 var2); /* Short sub, 1 */ Word16 abs_s (Word16 var1); /* Short abs, 1 */ Word16 shl (Word16 var1, Word16 var2); /* Short shift left, 1 */ Word16 shr (Word16 var1, Word16 var2); /* Short shift right, 1 */ =85 Word16 div_s (Word16 var1, Word16 var2); /* Short division, 18 */ Word16 norm_l (Word32 L_var1); /* Long norm, 1 */ =20 In the upcoming ITU-T G.GSAD standard another approach has been used as = shown in the following code example. For each operation, WMPOS function have been added, which count the number of operations. If = the algorithmic efficiency of an algorithm has to be measured, the program is run and the operations are counted.=20 =20 for (i=3D0; iband_enrg_long_fx[i] =3D 30; state_fx->band_enrg_fx[i] =3D 30; state_fx->band_enrg_bgd_fx[i] =3D 30; =20 state_fx->min_band_enrg_fx[i] =3D 30; } =20 These two similar examples worked well in the years and are an = established procedure to count operations and complexity. Still, it has some drawbacks a) Existing algorithm must be modified manually to address the = counting of operations. This is time consuming.=20 b) The CPU model is simplistic as it does not consider memory = access (e.g. cache), parallel executions, or other kind of optimization done in modern microprocessor and compilers. Thus, the = number of instruction might not correlated well with the actual execution time on modern CPUs. Profiling: The Classic Approach used in Software Engineering =20 Citing Wikipedia = : = =84In software engineering , program profiling, = software profiling or simply profiling, a form of dynamic program analysis = (as opposed tostatic code analysis ), is the = investigation of a program's behavior using information gathered as the program executes. The usual purpose of this analysis is to determine = which sections of a program to optimize - to = increase its overall speed, decrease its memory requirement or sometimes both. * A (code) profiler is a performance analysis tool that, most = commonly, measures only the frequency and duration of function calls, but there are other specific types of profilers (e.g. memory = profilers ) in addition to more comprehensive profilers, capable of gathering extensive performance data. * An instruction set simulator = which is also = =97 by necessity =97 a profiler, can measure the totality of a program's behaviour from = invocation to termination.=93 Thus, a typical profiler such as gprof can be used to measure and = understand the complexity of a codec implementation. It is precise because it is uses on modern computers. However, if used for = standardization, it has the following drawback. a) The execution times depend on the CPU architecture, the PC in = general, the OS and parallel running programs. As such it cannot produce reliable and repeatable results. The results are not = comparable if done under slightly changed conditions. Suggestion: Use a Cycle Accurate Simulator Wikipedia: =84A Cycle Accurate Simulator (CAS) is a computer program = that simulates a microarchitecture = cycle-accurate. In contrast an instruction set = simulator simulates an Instruction = Set Architecture usually faster but not cycle-accurate to a specific implementation of this architecture.=93 Then, the execution times are precise and they are repeatable. If two = parties make measurements using different CPUs, they still get the same results. Of course, a cycle accurate simulator is slower than = the real CPU at a factor of about 100. =20 Actually, there is an open-source Cycle accurate simulator called PTLsim = avaible that simulates an Pentium IV. =84PTLsim is a cycle accurate x86 microprocessor simulator and = virtual machine for the x86 and x86-64 instruction sets. PTLsim models a modern superscalar out of order x86-64 compatible processor = core at a configurable level of detail ranging from full-speed native execution on the host CPU all the way down to RTL level models of = all key pipeline structures. In addition, all microcode, the complete cache hierarchy, memory subsystem and supporting hardware = devices are modeled with true cycle accuracy. PTLsim supports the full x86-64 instruction set of the Pentium 4+, Athlon 64 and similar = machines with all extensions (x86-64, SSE/SSE2/SSE3, MMX, x87). It is currently the only tool available to the public to support = true cycle accurate modeling of real x86 microarchitectures. [=85] PTLsim is used extensively at hundreds of major universities, = industry research labs and the well known x86 microprocessor vendors Intel and AMD.=93 Thus, I would suggest to use the Cycle Accurate Simulator PTLsim to = measure the complexity of the IETF audio codec contributions because a) it makes precise performance measurements using a modern, = widely deployed CPU platform, b) the measurement are repeatable and can be made by everybody, c) existing source code can be used without significant changes, = and=20 d) it is time-saving and easy to use. With best regards, Christian Hoene =20 --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ =20 _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec =20 ------=_NextPart_000_0010_01CB00C8.2306AB90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Stephen,

 

comments inline

 

Are you implying that the complexity is only a requirement for x86 = machines? 

Hoene: No, complexity is a requirement for all machines. = However, x86 machines are distributed and used widely on PC, notebook and also = sometimes also in embedded systems. Also, the contributed source code is only = available for PCs like system not for DSPs. Thus, any testing on DSP will not be possible.

However, you are free to suggest other reference = platforms such as

=B7         ARM: http://facsim.snu.ac.kr/

=B7         C64x+ CPU Cycle Accurate = Simulator: http://processors.wiki.ti.com/index.php/C64x%2B_CPU_Cycle_Ac= curate_Simulator

Just a matter of choice (and = availability).

>>>
different codec proposals can be compared if they are show similar = performance in other aspects.
>>>
There's been no discussion on this point.  In my view, at some = point in the process we set a complexity bound which all codecs proposals will = have to meet. 

Hoene: Agreed. However, before agreeing on bound, we have = to agree on a measure and metric. My last email is on suggestion on how to = measure precise and time saving while covering the most typical usage = scenarios.

Christian

 

That is quite different from the above statement.

 


Regards
Stephen Botzko


On Mon, May 31, 2010 at 5:27 AM, Christian Hoene <hoene@uni-tuebingen.de> = wrote:

Hi,<= /font>

 

in the last weeks we had a couple of discussion on the complexity or algorithmic efficiency of the codec. Knowing the algorithmic efficiency is = important because:

1.      = the complexity has an impact on power consumption and = system costs,

2.      = the hardware can be selected to fit pre-known complexity requirement, and

3.      = different codec proposals can be compared if they are show = similar performance in other aspects.

Before any complexity comparisons can be made, we need an objective, precise, reliable, and repeatable metric on how to measure the algorithmic = efficiency. Let me describe three different approaches:

 

Classic Approach used in Codec = Standardization

 

In the last 17 years, the ITU-T Study Group 16 measure the complexity of = codecs using a library called ITU-T Basic Operators (described in ITU-T G.191), that counts the kind and number of operations and = the amount of memory. The last version of the standard (03/10), not yet = publically available, supports - beside fix-point operations of different widths - = also floating operations.  Each operation can be counted automatically and = weighted accordingly. The following source code is an excerpt from = baseop32.h

 

/*_________________________________________________________________= __________

 |          =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;                |

 |   Prototypes for basic arithmetic operators          &nbs= p;            = ;        |

 |____________________________________________________________= _______________|

*/

 

Word16 add (Word16 var1, Word16 var2);    = /* Short add,           1   */

Word16 sub (Word16 var1, Word16 var2);    = /* Short sub,           1   */

Word16 abs_s (Word16 var1);           &= nbsp;   /* Short = abs,           1   */

Word16 shl (Word16 var1, Word16 var2);    = /* Short shift left,    1   = */

Word16 shr (Word16 var1, Word16 var2);    = /* Short shift right,   1   = */

…

Word16 div_s (Word16 var1, Word16 var2); /* Short division,       18  = */

Word16 norm_l (Word32 L_var1);           /* = Long norm,           &n= bsp; 1  */

 

In the upcoming ITU-T G.GSAD standard another approach has been used as = shown in the following code example. For each = operation, WMPOS function have been added, which count the number of operations. If = the algorithmic efficiency of an algorithm has to be measured, the program = is run and the operations are counted.

 

    for (i=3D0; i<NUM_BAND; = i++)

    {

#ifdef WMOPS_FX

        = move32();move32();

        = move32();move32();

#endif

           

        state_fx->band_enrg_long_fx[i] =3D 30;

        = state_fx->band_enrg_fx[i] =3D 30;

        state_fx->band_enrg_bgd_fx[i] =3D 30;   =

        state_fx->min_band_enrg_fx[i] =3D 30;

    }

 

These two similar examples worked well in the years and are an established = procedure to count operations and complexity. Still, it has some = drawbacks

a)      = Existing algorithm must be modified manually to address the = counting of operations. This is time consuming.

b)      = The CPU model is simplistic as it does not consider memory = access (e.g. cache), parallel executions, or other kind of optimization done in = modern microprocessor and compilers. Thus, the number of instruction might not correlated well with the actual execution time on modern = CPUs.

Profiling: The Classic Approach used in Software = Engineering

 

Citing Wikipedia: „In software engineering, program profiling, software profiling or simply profiling, a form of dynamic program = analysis (as opposed tostatic code = analysis), is the investigation of a program's behavior using information gathered as the = program executes. The usual purpose of this analysis is to determine which = sections of a program to optimize - to increase its overall speed, decrease its memory requirement or sometimes = both.

=B7        = ; A (code) profiler is a performance = analysis tool that, most commonly, measures only the frequency and duration of = function calls, but there are other specific types of profilers (e.g. memory = profilers) in addition to more comprehensive profilers, capable of gathering = extensive performance data.

=B7        = ; An instruction set = simulator which is also — by necessity — a profiler, can measure the totality = of a program's behaviour from invocation to = termination.“

Thus, a typical profiler such as gprof can be used to measure and understand = the complexity of a codec implementation. It is precise because it is uses = on modern computers. However, if used for standardization, it has the = following drawback.

a)      = The execution times depend on the CPU architecture, the PC = in general, the OS and parallel running programs. As such it cannot produce reliable and repeatable results. The results are not comparable if done = under slightly changed conditions.

Suggestion: Use a Cycle Accurate = Simulator

Wikipedia: „A Cycle Accurate = Simulator (CAS) is a computer program that simulates a microarchitecture cycle-ac= curate. In contrast an instruction set simulator simulates = an Instruction Set = Architecture usually faster but not cycle-accurate to a specific implementation of this architecture.“

Then, the execution times are precise and they are repeatable. If two parties = make measurements using different CPUs, they still get the same results. Of = course, a cycle accurate simulator is slower than the real CPU at a factor of = about 100.

 

Actually, there is an open-source Cycle accurate simulator called PTLsim avaible = that simulates an Pentium IV. „PTLsim is a cycle accurate x86 = microprocessor simulator and virtual machine for the x86 and x86-64 instruction = sets. PTLsim models a modern superscalar out of order = x86-64 compatible processor core at a configurable level of detail ranging from full-speed = native execution on the host CPU all the way down to RTL level = models of all key pipeline structures. In addition, all microcode, the complete cache hierarchy, memory subsystem and supporting hardware devices are modeled = with true cycle accuracy. PTLsim supports the full x86-64 instruction set of the Pentium 4+, Athlon 64 and similar machines with all = extensions (x86-64, SSE/SSE2/SSE3, MMX, x87). It is currently the only tool = available to the public to support true cycle accurate modeling of real x86 = microarchitectures. […] PTLsim is used extensively at hundreds of major universities, industry research labs = and the well known x86 microprocessor vendors Intel and = AMD.“

Thus, I would suggest to use the Cycle Accurate Simulator PTLsim to measure the complexity of the IETF audio codec contributions because

a)      = ;  it makes precise performance measurements using a modern, = widely deployed CPU platform,

b)      = ;  the measurement are repeatable and can be made by = everybody,

c)      = ;  existing source code can be used without significant = changes, and

d)      = ;  it is time-saving and easy to = use.

With best = regards,

 Christian Hoene

 

---------------------------------------------------= ------------

Dr.-Ing. Christian = Hoene

Interactive Communication Systems (ICS), = University of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 = 2970532

http://www.net.uni-tuebingen.de/=

 


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

 

------=_NextPart_000_0010_01CB00C8.2306AB90-- From stephen.botzko@gmail.com Mon May 31 06:38:15 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 973003A6A5A for ; Mon, 31 May 2010 06:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yH7FhB82ehle for ; Mon, 31 May 2010 06:38:13 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 6D01B3A68F2 for ; Mon, 31 May 2010 06:37:44 -0700 (PDT) Received: by wwb39 with SMTP id 39so1059785wwb.31 for ; Mon, 31 May 2010 06:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=H7xtzpDWFfvphQHJIUZWBO60fHcpz7C8mhoWYFGELzU=; b=I8ibsEmwHdJ1mLSsTxhTO/Vvc7XgcopRCrUwlZXkqcCmdmtxoCLon8AtSQD55ND5MU tO/v/KRHbRajDB2Ugx5e823tUPmsg5CxuiupRvf6eZKLsuNh1dxfLIneCCqOe9mMrGIO EovhClJdlnsWR/762ZQfPLtyiEUnueVfS/8fU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Yvg/eSdE/zp0DEE1nPICrWignV+bt+LZL5+4dgshh/tYONsH5w1Gr4iYoypMLFBq35 TFwZbsmr+1kyeEd267+Tgo0f0EpKzYQBrjHrODILDntOH28stUJXA6a1jEnB1PQ4lRi3 spwe7XqGzr8fBTU3fCVMGqa+ao0TBaTdjQvwA= MIME-Version: 1.0 Received: by 10.227.134.194 with SMTP id k2mr4429657wbt.118.1275312697801; Mon, 31 May 2010 06:31:37 -0700 (PDT) Received: by 10.216.23.5 with HTTP; Mon, 31 May 2010 06:31:29 -0700 (PDT) In-Reply-To: <000f01cb00b7$5f7ddb90$1e7992b0$@de> References: <000b01cb00a3$8c9ab710$a5d02530$@de> <000f01cb00b7$5f7ddb90$1e7992b0$@de> Date: Mon, 31 May 2010 09:31:29 -0400 Message-ID: From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=001636831c62547d720487e3e011 Cc: codec@ietf.org Subject: Re: [codec] Measuring the algorithmic efficiency of the IWAC X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 May 2010 13:38:15 -0000 --001636831c62547d720487e3e011 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable One significant disadvantage of profiling is that it gives an unfair advantage to code which is optimized for the x86 platform. This may not be a problem at the end of the development process, however in the beginning it is best to stay focused on the core algorithm. Even at the end, more generic code may be the best reference, since the x86 optimizations don't have to be undone if you are re-optimizing for a non-x8= 6 platform. >>> Also, the contributed source code is only available for PCs like system not for DSPs. >>> Surely NOT! I think the contributed source code has to be portable, and need to compile (and deliver the right result) for a wide variety of platforms. Regards Stephen Botzko On Mon, May 31, 2010 at 7:49 AM, Christian Hoene wr= ote: > Hi Stephen, > > > > comments inline > > > > Are you implying that the complexity is only a requirement for x86 > machines? > > Hoene: No, complexity is a requirement for all machines. However, x86 > machines are distributed and used widely on PC, notebook and also sometim= es > also in embedded systems. Also, the contributed source code is only > available for PCs like system not for DSPs. Thus, any testing on DSP will > not be possible. > > However, you are free to suggest other reference platforms such as > > =B7 ARM: http://facsim.snu.ac.kr/ > > =B7 C64x+ CPU Cycle Accurate Simulator: > http://processors.wiki.ti.com/index.php/C64x%2B_CPU_Cycle_Accurate_Simula= tor > > Just a matter of choice (and availability). > > >>> > different codec proposals can be compared if they are show similar > performance in other aspects. > >>> > There's been no discussion on this point. In my view, at some point in t= he > process we set a complexity bound which all codecs proposals will have to > meet. > > Hoene: Agreed. However, before agreeing on bound, we have to agree on a > measure and metric. My last email is on suggestion on how to measure prec= ise > and time saving while covering the most typical usage scenarios. > > Christian > > > > That is quite different from the above statement. > > > > > Regards > Stephen Botzko > > > On Mon, May 31, 2010 at 5:27 AM, Christian Hoene > wrote: > > Hi, > > > > in the last weeks we had a couple of discussion on the complexity or algo= rithmic > efficiency of the > codec. Knowing the algorithmic efficiency is important because: > > 1. the complexity has an impact on power consumption and system > costs, > > 2. the hardware can be selected to fit pre-known complexity > requirement, and > > 3. different codec proposals can be compared if they are show simila= r > performance in other aspects. > > Before any complexity comparisons can be made, we need an objective, > precise, reliable, and repeatable metric on how to measure the algorithmi= c > efficiency. Let me describe three different approaches: > > > > *Classic Approach used in Codec Standardization* > > > > In the last 17 years, the ITU-T Study Group 16 measure the complexity of > codecs using a library called ITU-T Basic Operators (described in ITU-T > G.191), that counts the > kind and number of operations and the amount of memory. The last version = of > the standard (03/10), not yet publically available, supports - beside > fix-point operations of different widths - also floating operations. Eac= h > operation can be counted automatically and weighted accordingly. The > following source code is an excerpt from baseop32.h > > > > > /*_______________________________________________________________________= ____ > > | > | > > | Prototypes for basic arithmetic > operators | > > > |_______________________________________________________________________= ____| > > */ > > > > Word16 add (Word16 var1, Word16 var2); /* Short add, 1 */ > > Word16 sub (Word16 var1, Word16 var2); /* Short sub, 1 */ > > Word16 abs_s (Word16 var1); /* Short abs, 1 */ > > Word16 shl (Word16 var1, Word16 var2); /* Short shift left, 1 */ > > Word16 shr (Word16 var1, Word16 var2); /* Short shift right, 1 */ > > =85 > > Word16 div_s (Word16 var1, Word16 var2); /* Short division, 18 */ > > Word16 norm_l (Word32 L_var1); /* Long norm, 1 */ > > > > In the upcoming ITU-T G.GSAD standard another approach has been used as > shown in the following code example. For each operation, WMPOS function > have been added, which count the number of operations. If the algorithmic > efficiency of an algorithm has to be measured, the program is run and the > operations are counted. > > > > for (i=3D0; i > { > > #ifdef WMOPS_FX > > move32();move32(); > > move32();move32(); > > #endif > > > > state_fx->band_enrg_long_fx[i] =3D 30; > > state_fx->band_enrg_fx[i] =3D 30; > > state_fx->band_enrg_bgd_fx[i] =3D 30; > > state_fx->min_band_enrg_fx[i] =3D 30; > > } > > > > These two similar examples worked well in the years and are an establishe= d > procedure to count operations and complexity. Still, it has some drawback= s > > a) Existing algorithm must be modified manually to address the > counting of operations. This is time consuming. > > b) The CPU model is simplistic as it does not consider memory access > (e.g. cache), parallel executions, or other kind of optimization done in > modern microprocessor and compilers. Thus, the number of instruction migh= t > not correlated well with the actual execution time on modern CPUs. > > *Profiling: The Classic Approach used in Software Engineering* > > * * > > Citing Wikipedia: > =84In software engineering, program > profiling, software profiling or simply profiling, a form of dynamic > program analysis = (as > opposed tostatic code analysis), > is the investigation of a program's behavior using information gathered a= s > the program executes. The usual purpose of this analysis is to determine > which sections of a program to optimize - > to increase its overall speed, decrease its memory requirement or sometim= es > both. > > =B7 A (code) profiler is a performance analysis tool that, most > commonly, measures only the frequency and duration of function calls, but > there are other specific types of profilers (e.g. memory profilers) > in addition to more comprehensive profilers, capable of gathering extensi= ve > performance data. > > =B7 An instruction set simulator which > is also =97 by necessity =97 a profiler, can measure the totality of a pr= ogram's > behaviour from invocation to termination.=93 > > Thus, a typical profiler such as gprof can be used to measure and > understand the complexity of a codec implementation. It is precise becaus= e > it is uses on modern computers. However, if used for standardization, it = has > the following drawback. > > a) The execution times depend on the CPU architecture, the PC in > general, the OS and parallel running programs. As such it cannot produce > reliable and repeatable results. The results are not comparable if done > under slightly changed conditions. > > *Suggestion: Use a Cycle Accurate Simulator* > > Wikipedia: =84A Cycle Accurate Simulator (CAS) is a computer program that > simulates a microarchitecture cycle-accurate. > In contrast an instruction set simulator simulates > an Instruction Set Architecture usually > faster but not cycle-accurate to a specific implementation of this > architecture.=93 > > Then, the execution times are precise and they are repeatable. If two > parties make measurements using different CPUs, they still get the same > results. Of course, a cycle accurate simulator is slower than the real CP= U > at a factor of about 100. > > > > Actually, there is an open-source Cycle accurate simulator called PTLsim<= http://www.ptlsim.org/>avaible that simulates an Pentium IV. =84PTLsim is a= cycle accurate x86 > microprocessor simulator and virtual machine for the x86 and x86-64 > instruction sets. PTLsim models a modern superscalar out of order > x86-64 compatible processor core at a configurable level of detail rangin= g > from full-speed native execution on the host CPU all the way down to RTL > level models of all key pipeline structures. In addition, all microcode, = the > complete cache hierarchy, memory subsystem and supporting hardware device= s > are modeled with true cycle accuracy. PTLsim supports the full x86-64 > instruction set of the Pentium 4+, Athlon 64 and similar machines with al= l > extensions (x86-64, SSE/SSE2/SSE3, MMX, x87). It is currently the only to= ol > available to the public to support true cycle accurate modeling of real x= 86 > microarchitectures. [=85] PTLsim is used extensively at hundreds of major > universities, industry research labs and the well known x86 microprocesso= r > vendors Intel and AMD.=93 > > Thus, I would suggest to use the Cycle Accurate Simulator PTLsim to measu= re > the complexity of the IETF audio codec contributions because > > a) it makes precise performance measurements using a modern, widel= y > deployed CPU platform, > > b) the measurement are repeatable and can be made by everybody, > > c) existing source code can be used without significant changes, > and > > d) it is time-saving and easy to use. > > With best regards, > > Christian Hoene > > > > --------------------------------------------------------------- > > Dr.-Ing. Christian Hoene > > Interactive Communication Systems (ICS), University of T=FCbingen > > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > > http://www.net.uni-tuebingen.de/ > > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > --001636831c62547d720487e3e011 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable One significant disadvantage of profiling is that it gives an unfair advant= age to code which is optimized for the x86 platform.

This may not b= e a problem at the end of the development process, however in the beginning= it is best to stay focused on the core algorithm.=A0

Even at the end, more generic code may be the best reference, since the= x86 optimizations don't have to be undone if you are re-optimizing for= a non-x86 platform.=A0

>>>
Also, the contributed=20 source code is only available for PCs like system not for DSPs.
>>>
Surely N= OT!=A0 I think the contributed source code has to be portable, and need to = compile (and deliver the right result) for a wide variety of platforms.

Regards
Stephen Botzko

On Mon, May= 31, 2010 at 7:49 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote:
=

= Hi Stephen,

= =A0=

= comments inline

= =A0=

Are yo= u implying that the complexity is only a requirement for x86 machines?=A0

Hoene: No, complexity is a requirement f= or all machines. However, x86 machines are distributed and used widely on PC, notebook and also somet= imes also in embedded systems. Also, the contributed source code is only availab= le for PCs like system not for DSPs. Thus, any testing on DSP will not be possible.

However, you are free to suggest other referen= ce platforms such as

=B7=A0=A0=A0=A0=A0=A0=A0=A0 ARM: http://facsim.snu.ac.kr/

=B7=A0=A0=A0=A0=A0=A0=A0=A0 C64x+ CPU Cycle Accurate Simulator: h= ttp://processors.wiki.ti.com/index.php/C64x%2B_CPU_Cycle_Accurate_Simulator=

Just a matter of choice (and availability).

>&g= t;>
different codec proposals can be compared if they are show similar performa= nce in other aspects.
>>>
There's been no discussion on this point.=A0 In my view, at some point = in the process we set a complexity bound which all codecs proposals will have = to meet.=A0 <= /span>

Hoene: Agreed. However, before agreeing = on bound, we have to agree on a measure and metric. My last email is on suggestion on how to mea= sure precise and time saving while covering the most typical usage scenarios.

Christian

=A0

That i= s quite different from the above statement.

=A0


Regards
Stephen Botzko


On Mon, May 31, 2010 at 5:27 AM, Christian Hoene <= ;hoene@uni-tueb= ingen.de> wrote:

Hi,

=A0

in the last weeks we had a couple of discussion on the complexity or = algorithmic efficiency of the codec. Knowing the algorithmic efficiency is importan= t because:

1.=A0=A0=A0=A0=A0 <= span lang=3D"EN-US">the complexity has an impact on power consumption and s= ystem costs,

2.=A0=A0=A0=A0=A0 <= span lang=3D"EN-US">the hardware can be selected to fit pre-known complexit= y requirement, and

3.=A0=A0=A0=A0=A0 <= span lang=3D"EN-US">different codec proposals can be compared if they are s= how similar performance in other aspects.

Before any complexity comparisons can be made, we need an objective, precise, reliable, and repeatable metric on how to measure the algorithmic efficienc= y. Let me describe three different approaches:

=A0

Classic Approach used i= n Codec Standardization

=A0

In the last 17 years, the ITU-T Study Group 16 measure the complexity of codec= s using a library called ITU-T Basic Operators (described in ITU-T G.191), that counts the kind and number of operations and the amount of memory. The last version of the standard (03/10), not yet publica= lly available, supports - beside fix-point operations of different widths - als= o floating operations.=A0 Each operation can be counted automatically and weighted accordingly. The following source code is an excerpt from baseop32.h=

=A0

/*_= __________________________________________________________________________<= /span>

=A0= |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0|

=A0= |=A0=A0 Prototypes for basic arithmetic operators=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 |

=A0= |__________________________________________________________________________= _|

*/<= /span>

=A0=

Wor= d16 add (Word16 var1, Word16 var2);=A0=A0=A0 /* Short add,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0 */

Wor= d16 sub (Word16 var1, Word16 var2);=A0=A0=A0 /* Short sub,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0 */

Wor= d16 abs_s (Word16 var1);=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* Short abs,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0 */

Wor= d16 shl (Word16 var1, Word16 var2);=A0=A0=A0 /* Short shift left,=A0=A0=A0 1=A0=A0 */

Wor= d16 shr (Word16 var1, Word16 var2);=A0=A0=A0 /* Short shift right,=A0=A0 1=A0=A0 */

=85=

Wor= d16 div_s (Word16 var1, Word16 var2); /* Short division,=A0=A0=A0=A0=A0=A0 18=A0 */

Wor= d16 norm_l (Word32 L_var1);=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /* Long norm,=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0 */

=A0

In the upcoming ITU-T G.GSAD standard another approach has been used as shown = in the following code example. For each ope= ration, WMPOS function have been added, which count the number of operations. If th= e algorithmic efficiency of an algorithm has to be measured, the program is r= un and the operations are counted.

=A0=

=A0= =A0=A0 for (i=3D0; i<NUM_BAND; i++)

=A0= =A0=A0 {

#if= def WMOPS_FX

=A0= =A0=A0=A0=A0=A0=A0 move32();move32();

=A0= =A0=A0=A0=A0=A0=A0 move32();move32();

#en= dif

=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0

=A0= =A0=A0=A0=A0=A0=A0 state_fx->band_enrg_long_fx[i] =3D 30;

=A0= =A0=A0=A0=A0=A0=A0 state_fx->band_enrg_fx[i] =3D 30;

=A0= =A0=A0=A0=A0=A0=A0 state_fx->band_enrg_bgd_fx[i] =3D 30;=A0=A0

=A0= =A0=A0=A0=A0=A0=A0 state_fx->min_band_enrg_fx[i] =3D 30;

=A0= =A0=A0 }

=A0=

These two similar examples worked well in the years and are an established proced= ure to count operations and complexity. Still, it has some drawbacks

a)=A0=A0=A0=A0=A0 Existing= algorithm must be modified manually to address the counting of operations. This is time consuming.

b)=A0=A0=A0=A0=A0 The CPU = model is simplistic as it does not consider memory access (e.g. cache), parallel executions, or other kind of optimization done in mo= dern microprocessor and compilers. Thus, the number of instruction might not correlated well with the actual execution time on modern CPUs.

Profiling: The Classic = Approach used in Software Engineering

=A0

Citing Wikipedia: =84In=A0software engineering,=A0program profiling,=A0software profiling=A0or simply=A0profiling, a form of=A0dynamic program analysis=A0(as opposed tostatic code analysis), is= the investigation of a program's behavior using information gathered as the= program executes. The usual purpose of this analysis is to determine which sections= of a program to=A0optimize=A0- to increase its overall speed, decrease its memory requirement or sometimes bo= th.

=B7=A0=A0=A0=A0=A0=A0=A0=A0 = A=A0(code) profiler=A0is a=A0performance analysis=A0to= ol that, most commonly, measures only the frequency and duration of function calls, but there are other specific types of profilers (e.g.=A0memory profilers) in addition to more comprehensive profilers, capable of gathering extensive performance data.

=B7=A0=A0=A0=A0=A0=A0=A0=A0 = An=A0ins= truction set simulator=A0which is also =97 by necessity =97 a profiler, can measure the totality of a program's behaviour from invocation to termination.=93

Thus, a typical profiler such as gprof can be used to measure and understand the complexity of a codec implementation. It is precise because it is uses on modern computers. However, if used for standardization, it has the followin= g drawback.

a)=A0=A0=A0=A0=A0 The exec= ution times depend on the CPU architecture, the PC in general, the OS and parallel running programs. As such it cannot produce reliable and repeatable results. The results are not comparable if done und= er slightly changed conditions.

Suggestion: Use a Cycle= Accurate Simulator

Wikip= edia: =84A=A0Cycle Accurate Simulator=A0(CAS) is a computer program that simulates a=A0microarchitecture=A0cycle-accurate. In contrast an=A0instruction set simula= tor=A0simulates an=A0Instruction Set Architecture=A0usually faster but not cycle-accurate to a specific implementation of this architecture.=93

Then, the execution times are precise and they are repeatable. If two parties mak= e measurements using different CPUs, they still get the same results. Of cour= se, a cycle accurate simulator is slower than the real CPU at a factor of about 100.

=A0

Actually, there is an open-source Cycle accurate simulator called PTLsim avaible that simulates an Pentium IV. =84PTLsim=A0is a=A0cycle accurate x86 microprocessor simulator=A0and virtual machine for the x86 and x86-64 instruction sets. PTLsim models a modern=A0superscalar out of order x86-64=A0compatible processor core at a configurable level of detail ranging from full-speed na= tive execution on the host CPU all the way down to=A0RTL level models=A0of all key pipeline structures. In addition, all microcode, the complete cache hierarchy, memory subsystem and supporting hardware devices are modeled wit= h true cycle accuracy. PTLsim supports the=A0full x86-64 instruction set=A0of the Pentium 4+, Athlon 64 and similar machines with all extensions (x86-64, SSE/SSE2/SSE3, MMX, x87). It is currently the=A0only tool availabl= e to the public=A0to support true cycle accurate modeling of real x86 microar= chitectures. [=85] PTLsim is used extensively at hundreds of major universities, industry research labs and t= he well known x86 microprocessor vendors Intel and AMD.=93

Thus= , I would suggest to use the Cycle Accurate Simulator=A0PTLsim to measure the complexity of the IETF audio codec contributions because

a)=A0=A0=A0=A0=A0=A0=A0 it makes precise performance measurements using a moder= n, widely deployed CPU platform,

b)=A0=A0=A0=A0=A0=A0=A0 the measurement are repeatable and can be made by every= body,

c)=A0=A0=A0=A0=A0=A0=A0 existing source code can be used without significant ch= anges, and

d)=A0=A0=A0=A0=A0=A0=A0 it is time-saving and easy to use.

With best regards,

=A0C= hristian Hoene

=A0

---------------------------------------= ------------------------

Dr.-Ing. Christian Hoene<= /p>

Interactive Communication Systems (ICS)= , University of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Pho= ne +49 7071 2970532

http://www.net.uni-tuebingen.de/<= /p>

=A0


_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

=A0


--001636831c62547d720487e3e011--